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

[Joe Touch <[e-mail]>]

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.

Joe