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

Joe Touch <> Tue, 29 June 2010 02:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B51A3A684E for <>; Mon, 28 Jun 2010 19:47:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.209
X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KOrcok41TRAj for <>; Mon, 28 Jun 2010 19:46:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 500283A657C for <>; Mon, 28 Jun 2010 19:46:55 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o5T2kXuR010765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jun 2010 19:46:43 -0700 (PDT)
Message-ID: <>
Date: Mon, 28 Jun 2010 19:46:32 -0700
From: Joe Touch <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: rick jones <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig45B0C0C96CFBDCBFEE8C2726"
X-ISI-4-43-8-MailScanner: Found to be clean
Cc:,,, "Biswas, Anumita" <>
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: Tue, 29 Jun 2010 02:47:15 -0000

rick jones wrote:
> On Jun 27, 2010, at 2:00 PM, Joe Touch wrote:
>> 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.
> JumboFrames (9000 bytes or better) in "Ethernet" appeared back in the
> mid to late 1990's with the Alteon AceNIC right? (at least that is my
> first conscious memory of them) They are still outside the IEEE
> framework.  Frame sizes going extra-IEEE is one thing, I'm rather more
> skeptical of CRC's being able to go extra-IEEE.  Given there is perhaps
> a snowball's chance of the IEEE blessing JumboFrames, I suspect there is
> less than a snowball's chance of them blessing another CRC to address
> anything presented as "a jumboframe problem."  So, to push a fix down to
> the link-layer is to effectively assert it is something that need never
> be fixed.

I'm claiming there are only two issues that have been raised:

	- a real, measured problem with intermediate devices
		which won't be fixed with a link or transport solution
		but could be addressed with an L7 transfer sum

	- a hypothetical link problem for some links (i.e., jumboframes)
		which ought to be fixed by the vendors who support jumboframes

		Note that I didn't say "IEEE" here. The same vendors that have
		a de-facto standard for jumboframes are the ones who can fix
		their mess with a jumboframe CRC ;-)

Neither one warrants a TCP solution, IMO.