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

From: Francesco Vacirca <[email-masked]>
Date: Thu, 01 Feb 2007 11:44:04 +0100

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
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Francesco Vacirca <[email-masked]>
Date: Thu, 01 Feb 2007 11:45:05 +0100

below the answer from Michael:

> (header+payload) is corrupted.

They are generally due to SNR fluctuations, by transmitting
between two notebooks in ad hoc mode (the only way that
disabling the CRC worked for us). I remember that Mattia
also did a quick check with one more notebook, to see if
MAC influences the result, but it didn't seem to play a role
(I don't remember if this test made it into the document in
the end... I think not).

It would be interesting to know why errors occur in the
fashion that we saw; we measured, but don't really have
an explanation. Perhaps it's the PHY coding.

Anyway, for those of you in who didn't see my previous
email and are confused, this link should explain it:
http://www.welzl.at/research/projects/corruption/index.html

Cheers,
Michael