I'm glad you tried this!
I think this could be an example of how the original design philosophy
of the PHY made an assumption, if you were to design the modulation and
coding differently, you could get a different result, but many PHYs are
designed for "all or nothing". Michael Welzl wrote:
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
