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

<L.Wood@surrey.ac.uk> Sat, 26 June 2010 08:49 UTC

Return-Path: <L.Wood@surrey.ac.uk>
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 B05C93A67D4 for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 01:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.463
X-Spam-Level:
X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 r+Reqr7iTfXF for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 01:49:54 -0700 (PDT)
Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 7F3CA3A68E3 for <tcpm@ietf.org>; Sat, 26 Jun 2010 01:49:54 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-3.tower-72.messagelabs.com!1277542202!3697151!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.200.31]
Received: (qmail 8235 invoked from network); 26 Jun 2010 08:50:02 -0000
Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-3.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2010 08:50:02 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Sat, 26 Jun 2010 09:50:02 +0100
From: <L.Wood@surrey.ac.uk>
To: <touch@ISI.EDU>
Date: Sat, 26 Jun 2010 09:50:01 +0100
Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00
Thread-Index: AcsVDJCUoCwHTqT3Qp6HJZ8HhzlXfg==
Message-ID: <87877965-FBC4-4A67-917A-EB48BED2CBB1@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>
In-Reply-To: <4C24F73F.9060402@isi.edu>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com, L.Wood@surrey.ac.uk
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 08:49:55 -0000

Ethernet uses CRC-32, TCP's existing 16-bit checksum
isn't a CRC. So I'm a bit puzzled by the question.

The link CRC and TCP checksum can disagree. See

Stone, J., Greenwald, M., Hughes, J., and C. Partridge,
"Performance of checksums and CRCs over real data", IEEE
Transactions on Networks vol. 6 issue 5, pp. 529-543,
October 1998.

Stone, J. and C. Partridge, "When the CRC and TCP Checksum
Disagree", Proceedings of ACM SIGCOMM , September 2000.


On 25 Jun 2010, at 19:36, 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?