As Internet packets traverse wireless links, corruption can occur. Normally, if a corrupt packet makes it to the transport layer, it is dropped because the transport checksum fails, and no use is made even of the information that the packet arrived, but there were errors in it. As the checksums of these protocols cover the header as well as the payload, this information could not be used in standard TCP and UDP (what exactly are you going to do with a packet if you don't even know whether the port number is correct?). This can be fixed by changing the way checksums are handled at the transport layer - but then, new questions arise: do link layers hand over corrupt data? (When) should they?
I am interested in these questions and did some work in this area, which is documented on this page.
Changing transport checksum behavior
I suggested the Data Checksum option in the Datagram Congestion Control Protocol (DCCP) (RFC 4340).
Here's another attempt that I made in this field:
Michael Welzl: "TCP Corruption
Notification Options". Internet-draft draft-welzl-tcp-corruption-00.txt, June
I presented this draft at the 60th IETF meeting (TCPM WG, CA, USA, 1-6 August 2004). Slides:
Link layer interactions
By default, WiFi networks use a CRC checksum and drop frames if the checksum fails. Mattia Rossi evaluated the benefit of disabling this checksum (which he did by patching the card's driver) and then using the TCP Corruption Notification Options. These results are disappointing: it seems that errors occur in blocks, and thus a receiver almost never gets any packets with errors in the payload but not in the header - but this is only one out of many link layer technologies, of course...
The whole process is documented in his master thesis:
Mattia Rossi, "Evaluating TCP with Corruption Notification in an IEEE
802.11 Wireless LAN", University of Innsbruck, November 2006.
and in this paper:
Michael Welzl, Mattia Rossi, Andrea Fumagalli, Marco Tacca, "TCP/IP over
IEEE 802.11b WLAN: the Challenge of Harnessing Known-Corrupt Data", accepted
for publication, IEEE ICC 2008 (International Conference
on Communications), 19-23 May 2008, Beijing, China.
One way of coping with this is to change the MAC such that, upon an error, the TCP end points are notified using the TCP Corruption Notification Options. This is described in this paper:
Ayyappan Ravichandran, Marco Tacca, Michael Welzl, Andrea Fumagalli: "LN-MAC:
a Cross-layer Explicit Loss Notification Solution for TCP over IEEE 802.11",
IEEE Globecom 2008, 30 November - 4 December 2008, New Orleans, LA USA.