[Iccrg] Re: [tcpm] Separate header checksums and WiFi

[Francesco Vacirca]

Some link layers use a strongest FEC to protect header. E.g. in some 
UMTS coding scheme the link layer employs a 1/3 codification for RLC 
header, whereas the payload can use a different scheme (e.g. from 4/5 to 
1/3)... Maybe it could be applied also to TCP. Note that this can 
decrease the goodput in case of non lossy links... obviously it depends 
on the ratio between useful bits and transmitted bits.

In the 802.11 standard some part of the packet (MAC header) is sent with 
a different rate to be more protected against channel impairments and 
also for compatibility purposes. A cross layer approach could adopt low 
rate also for TCP header (also IP obviously)... but I do not think that 
the benefits are more than disadvantages.

One more thing... in case of Michael experiments, are the packet losses 
on the channel due to SNR fluctuations or due to MAC collisions?
In the second case, it is quite normal that the whole packet 
(header+payload) is corrupted.

Francesco

Michael Welzl wrote:
> I agree, and am happy to contribute what I have!!!!!
> 
> (which is: the results, but not the time)
> 
> 
> On Wed, 2007-01-31 at 18:14, Joe Touch wrote:
>> Beyond what Ethan is suggesting, this is useful to write up more fully
>> and publish, e.g., at Globecom or ICC. Negative results, as Ethan notes,
>> are critical to the community as a whole.
>>
>> Joe
>>
>> Ethan Blanton wrote:
>>> Michael Welzl spake unto us the following wisdom:
>>>> 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.
>>> I have to applaud this move.  All too often we only talk about the
>>> things we did that *worked*, and the same questions about things that
>>> any number of people would tell you doesn't work come up over and
>>> over.  For this particular topic, there is now a citation, so the next
>>> guy won't have to go try it himself.  Thank you.
>>>
>>> Ethan
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> tcpm at ietf.org
>>> https://www1.ietf.org/mailman/listinfo/tcpm