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

Joe Touch <> Sun, 27 June 2010 21:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 90B053A67B8 for <>; Sun, 27 Jun 2010 14:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id irqofnb1QtvB for <>; Sun, 27 Jun 2010 14:01:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BE2133A69F8 for <>; Sun, 27 Jun 2010 14:01:18 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o5RL03W2024285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 27 Jun 2010 14:00:13 -0700 (PDT)
Message-ID: <>
Date: Sun, 27 Jun 2010 14:00:02 -0700
From: Joe Touch <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: "Biswas, Anumita" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigFB6599D31048C70783087F36"
X-MailScanner-ID: o5RL03W2024285
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: Sun, 27 Jun 2010 21:01:19 -0000

Hi, Animita,

Biswas, Anumita wrote:
>> Everything so far points to the need for an application 
>> protocol check, i.e., a final, total transfer checksum on 
>> each large transaction (i.e., the whole file). That was one 
>> conclusion of the 2000 paper, FWIW.
> I mentioned the advantage of being able to offload a TCP based checksum
> to the NIC. If I were to extend your argument that end system software
> is more likely the problem - a checksum over the whole file could also
> be prone to error. 

That's true too, but it would catch errors at all other places in the stack,
e.g., even errors that would not be caught by errors actually seen (e.g., in the
2000 paper).

> I think we are only trying to deploy a "stronger" checksum - we are not
> making claims that it will find all problems in end to end software -
> and as such is not the strongest checksum.

My point above is that 'stronger' won't fix the flaws actually seen thus far.

> Please read why the Castagnoli polynomial based CRC checksum is stronger
> than the Ethernet CRC32 checksum carried by the Ethernet frame. 

I have no question about that. This is a great argument to raise to the Ethernet

> Your argument suggests 
>> that such data centers need different *ethernet* checksums, 
>> not different TCP ones. Then the data centers can leverage - 
>> and reuse - that where necessary.
> The ideal way to do this would be to have Ethernet frames include the
> CRC32C checksum instead of the CRC32 checksum. But changing the Ethernet
> standard across the board is impossible due to backward compatibility
> issues. 

That's no more true for ethernet than for TCP.

> But TCP options provides a much easier path to introducing a
> stronger checksum as it does not break backward compatibility and can be
> offloaded to the NIC as well. 

That may all be true, but as I've noted repeatedly, the errors *actually seen*
thus far would not be solved by a new, stronger TCP sum. Only an application sum
would have caught those errors.

> Data Centers are one place where Jumbo frames are deployed - but there
> could be others. So I don't understand what you mean by "data centers
> can leverage and reuse that where necessary".

I'm suggesting that this is a jumboframe problem. Fix it in the implementation
of jumboframes, and all users of jumboframes will eventually benefit - i.e., fix
this at the Ethernet vendor level, and it can be used in all data centers that
use jumboframes.

Note that those vendors *do* deploy new capabilities - e.g., see the IETF TRILL WG.