Re: [tcpm] draft-eggert-tcpm-historicize-00

Joe Touch <touch@isi.edu> Sat, 26 June 2010 19:06 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC653A67E7 for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 12:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.079
X-Spam-Level:
X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw3JhJBbZrkg for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 12:06:39 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id F0FB43A6767 for <tcpm@ietf.org>; Sat, 26 Jun 2010 12:06:38 -0700 (PDT)
Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5QJ58kA029909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 12:05:19 -0700 (PDT)
Message-ID: <4C264F64.4010908@isi.edu>
Date: Sat, 26 Jun 2010 12:05:08 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: L.Wood@surrey.ac.uk
References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com><C304DB494AC0C04C87C6A6E2FF5603DB48105A5A82@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk>
In-Reply-To: <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB5BA7B3AA1731D326D3C7A2E"
X-MailScanner-ID: o5QJ58kA029909
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com
Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2010 19:06:40 -0000


L.Wood@surrey.ac.uk wrote:
>>From the abstract of Stone's SIGCOMM paper:
> 
> Traces of Internet packets from the past two years show that between 1 packet
> in 1,100 and 1 packet in 32,000 fails the TCP checksum, even on links where
> link-level CRCs should catch all but 1 in 4 billion errors.
> [..] Much of our time has been spent negotiating access to data.
> 
> s/*can*/*was observed to over two years in the wild*.

See Section 4.3.

End hosts that compute bad TCP checksums, or alter packets after the checksums
are validated aren't fixed by adding another checksum they can incorrectly
implement.

The only errors that appear to be happening due to paths were due to a faulty
router. Those errors were single bit errors, likely in memory of the router (as
per their observation, Sec 4.3.4). I.e., the authors believe the router was
accepting a valid CRC in, modifying the packet, and transmitting one with a
(different) valid CRC out. The end receiver thus saw a packet with a valid CRC
but would have seen an invalid TCP checksum.

Their methodology captured packets at the link layer, (Sec 3.1):

"For each complete packet, the software calculates
the checksum and if the checksum fails, the entire packet
is saved."

Later they note how they find out of the segment was faulty due to a
retransmission without the fault:

"If the IP datagram contains a TCP segment, the capture
program records what bytes were in the segment (on the as-
sumption that the sequence numbers are correct!) and then
looks for valid retransmissions of those bytes."

The do not seek, nor did they find in the wild, a single packet where the CRC
was valid and the TCP checksum was valid, but the packet had changed in
contents. That could have been attempted (perhaps with greater computational
power), but was not.

Joe