[Iccrg] Separate header checksums and WiFi
michael.welzl at uibk.ac.at
Wed Jan 31 15:15:12 GMT 2007
A long time ago, at the San Diego IETF meeting in August 2004,
I presented an idea called "Corruption Notification Options"
(a proposal which is some sort of a refined specification of
the TCP HACK idea) to the TCPM group.
The group's feedback was that this is useless, as errors
occur in such a clustered fashion that you wouldn't see
any packets with an intact header but erroneous payload
(which is the only situation where the scheme would
yield any benefit). I think that it was Gorry Fairhurst
who said this.
I figured that the only convincing way to prove him
wrong is to actually do a real-life test. I did, and
proved him right :) that is, disabling checksums for
parts of packets doesn't yield much of a benefit in
WiFi networks, where it seems that frames are delivered
in an all-or-nothing fashion.
Doing this test requires patching the device driver (to
disable the link layer CRC), and above all, finding a good
student - all of this took quite some time, but now it's
over, and the documentation can be found at:
(bottom of the page)
I learned my lesson, and thought I'd share it with you -
but this result only concerns WiFi. I'll keep this as a
low-priority "background" project and may take a closer
look at other link layers one day... in any case, that
topic still interests me, and I can't believe that it
wouldn't be possible to get a benefit out of such a scheme.
I'm sending this note to TCPM, TSVWG and DCCP because there
are similar mechanisms there (DCCP: the Data Checksum option; SCTP:
although I just noticed that this is apparently not a WG item...
still, it's SCTP related).
This note also goes to ICCRG, because I think that this should
be the place for related discussions (in fact Lachlan Andrew
will give us a related talk at our upcoming meeting:
More information about the Iccrg