Re: [tcpm] Separate header checksums and WiFi

Francesco Vacirca <> Thu, 01 February 2007 10:45 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1HCZR9-00079M-Gl; Thu, 01 Feb 2007 05:45:03 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1HCZR7-00079C-Sg for; Thu, 01 Feb 2007 05:45:01 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1HCZR3-0000yt-I6 for; Thu, 01 Feb 2007 05:45:01 -0500
Received: from unknown (HELO []) ([]) by with ESMTP; 01 Feb 2007 11:44:56 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAANTwUWXZGUE/2dsb2JhbAANnkcBAQEB
X-IronPort-AV: i="4.13,266,1167606000"; d="scan'208"; a="11324126:sNHT18779173"
Message-ID: <>
Date: Thu, 01 Feb 2007 11:45:05 +0100
From: Francesco Vacirca <>
User-Agent: Thunderbird (X11/20060921)
MIME-Version: 1.0
Subject: Re: [tcpm] Separate header checksums and WiFi
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Michael Welzl <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

below the answer from Michael:

On Thu, 2007-02-01 at 11:24, Francesco Vacirca wrote:
> 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.

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:


tcpm mailing list