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

Joe Touch <> Sat, 26 June 2010 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B79233A694A for <>; Sat, 26 Jun 2010 11:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.974
X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WlHNalZm7UxS for <>; Sat, 26 Jun 2010 11:10:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 62E4E3A6978 for <>; Sat, 26 Jun 2010 11:10:08 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o5QI9JkT020198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 11:09:35 -0700 (PDT)
Message-ID: <>
Date: Sat, 26 Jun 2010 11:09:19 -0700
From: Joe Touch <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
References: <><><><> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig9E927AE6E8FE9E8A0F93003A"
X-MailScanner-ID: o5QI9JkT020198
X-ISI-4-69-MailScanner: Found to be clean
Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 26 Jun 2010 18:10:15 -0000 wrote:
> 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

*can*. The paper below did mathematical analyses, but didn't observe them either
in a lab or in the wild. I.e., that work didn't see places where it *did*. Thus
my question.

I'm not asking whether this is important to address, just what the current
motivation is. The work below suggests using application-layer checksums. That
seems prudent for large transfers, but I don't see a motivation for needing this
fixed at the TCP layer...


> 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?