[tcpm] Separate header checksums and WiFi

Michael Welzl <michael.welzl@uibk.ac.at> Wed, 31 January 2007 15:14 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHA9-0002Ue-SK; Wed, 31 Jan 2007 10:14:17 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCHA9-0002UZ-8m for tcpm@ietf.org; Wed, 31 Jan 2007 10:14:17 -0500
Received: from lmr1.uibk.ac.at ([] helo=smtp.uibk.ac.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCHA3-0005GG-MU for tcpm@ietf.org; Wed, 31 Jan 2007 10:14:17 -0500
Received: from lap10-c703.uibk.ac.at (lap10-c703.uibk.ac.at [] michael.welzl@uibk.ac.at) by smtp.uibk.ac.at (8.13.8/8.13.1/F1) with ESMTP id l0VFE3kM011347 for <tcpm@ietf.org>; Wed, 31 Jan 2007 16:14:03 +0100
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: tcpm@ietf.org
Content-Type: text/plain
Organization: University of Innsbruck
Message-Id: <1170256423.4805.611.camel@lap10-c703.uibk.ac.at>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
Date: Wed, 31 Jan 2007 16:13:43 +0100
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.58 at uibk.ac.at on
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Subject: [tcpm] Separate header checksums and WiFi
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

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 this 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:
(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:
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 )


tcpm mailing list