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

Joe Touch <touch@isi.edu> Sat, 26 June 2010 19:17 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 B472F3A68F9 for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 12:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 zLvo3QTpIaqt for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 12:17:50 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id E029C3A6897 for <tcpm@ietf.org>; Sat, 26 Jun 2010 12:17:49 -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 o5QJGv15001804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 12:17:08 -0700 (PDT)
Message-ID: <4C265222.8030904@isi.edu>
Date: Sat, 26 Jun 2010 12:16:50 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
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> <4C25A9A1.3040302@gont.com.ar>
In-Reply-To: <4C25A9A1.3040302@gont.com.ar>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2BDEFD6A7553E809B67320DB"
X-MailScanner-ID: o5QJGv15001804
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, "Anantha Ramaiah \(ananth\)" <ananth@cisco.com>, "Biswas, Anumita" <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:17:50 -0000


Fernando Gont wrote:
> Joe Touch wrote:
> 
>>> Our expirience has shown, that TCP often runs over links with much
>>> higher error rates, than intended for the technology (ie. Design goal of
>>> BER <= 1E-12 over Ethernet often has an actual BER >> 1E-12). If such
>>> error-prone links are running at a high speed and with large segment
>>> sizes (jumbo / giant frames), there exists the real problem that within
>>> a short timeframe (weeks to months), TCP will deliver corrupted data, as
>>> CRC-16 was not able to catch the error.
>>
>> Just to confirm, is this a measured problem or a mathematical one? I.e., have
>> you seen this actually occur (i.e., TCP with invalid CRC-16 but valid checksum)
>> in the wild, in a lab, or have you never seen it but consider it important anyway?

To clarify, what I'm seeking is:

a TCP segment that:
	has a valid TCP checksum
	actually has been received in the lab or wild
	would have an invalid CRC-16 as proposed in the ID

i.e., this is a case where the ethernet or other link checksum would have
succeeded on all the hops, and the TCP checksum succeeds, so an error would NOT
have been caught.

That's the only case where we need to consider replacing the TCP checksum.

So far, it appears that the only reported evidence (the 2000 Sigcomm paper)
looked only for real packets where the TCP checksum already failed.

The case where both the link and TCP checks fail is in Sec 4.4 (I had mistyped
that as 5 previously), and is only a mathematical analysis of probability.

Joe