On woensdag, jul 16, 2003, at 21:59 Europe/Amsterdam, Keith Moore wrote:
I'm not sure what the problem is here:
- UDP checksums are optional
Not in IPv6. If this is the only thing we need at the transport layer
then we might want to change this back to the IPv4 behavior.
- IPv6 could define an option for IP header checksum
(could be applicable to IPv4 also, if you want a stronger checksum
for the header)
It would make sense to make this more general. IIRC, GSM uses a scheme
where some bits must be transferred correct some bits may have errors
but are important enough to protect with forward error correction and
some other bits are not important so they don't get any protection at
all. Now obviously we don't want to carry FEC overhead over our 1 in
10^8 bit error links so there must be some way to map application
requirements to different link layers for the same packet so some links
will add the necessary FEC for the important part of the data on the
link and then strip it off again, but other links either simply turn
off the CRC or do nothing (as the bit error rate is so minimal that
implementing turning off the CRC on a per-packet basis isn't worth it).
This is what I was getting at (way too cryptically) at the microphone
yesterday.
Then an application-specific CRC over the uncorruptable part can happen
at the receiver. Such a mechanism could also address the problem that
our current checksums or even link CRCs aren't strong enough for much
larger packets.
- whether L2 drops packets whose checksum fails is an L2 matter;
the ability to turn this on or off is an L2 feature
Obviously not. If I'm doing A/V over wifi I would probably want the
802.11b MAC to adopt multicast behavior where it sends the packet at a
fixed rate without link layer retransmits and then have them delivered
to the other side if there are errors as well, but if I'm also doing
TCP over this link I would want this traffic to be treated as usual. So
this must be a per-packet mechanism.
so it seems like what we need is a bit in the IP header to indicate
that
L2 integrity checks are optional, and to specify for various kinds of
IP-over-FOO how to implement that bit in FOO. and maybe that bit could
go in the IP option to provide a stronger checksum than normally exists
in the IP header (so that the header, at least, is protected)
I think the best way to do this is using diffserv to enable/disable the
special link handling. If special link handling is required then the
packet can be further inspected to see how much of it should receive
additional FEC protection.
Yes, the IP header (but certainly not always just that) would be
uncorruptable. E2e dictates that the receiving host checks this but we
probably want to do it after special links too.
Interesting aspect: it should be possible to make this work with IPsec
encryption but not authentication, but not so well with ciphers in CBC
mode. A stream cipher would be better here.