Dear all, 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: http://www.welzl.at/research/projects/corruption/ (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: http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-06.txt 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: http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda ) Cheers, Michael
