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

Joe Touch <touch@isi.edu> Tue, 29 June 2010 16:51 UTC

Return-Path: <touch@isi.edu>
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 043463A696B for <tcpm@core3.amsl.com>; Tue, 29 Jun 2010 09:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599]
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 aQcPjZSZhyww for <tcpm@core3.amsl.com>; Tue, 29 Jun 2010 09:51:36 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 936C63A6848 for <tcpm@ietf.org>; Tue, 29 Jun 2010 09:51:36 -0700 (PDT)
Received: from [75.213.82.102] (102.sub-75-213-82.myvzw.com [75.213.82.102]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5TGlw78025685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Jun 2010 09:48:09 -0700 (PDT)
Message-ID: <4C2A23BE.9020905@isi.edu>
Date: Tue, 29 Jun 2010 09:47:58 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: rick jones <perfgeek@mac.com>
References: <A3D02FB7C6883741952C425A59E261A50973253A@SACMVEXC2-PRD.hq.netapp.com> <4C27BBD2.4060002@isi.edu> <351D0AEF-4DA3-49DF-9CDB-2897C478BBE6@mac.com> <4C295E88.1060505@isi.edu> <E6F348CF-3D85-4F0B-9DD4-9B0614AF782C@mac.com>
In-Reply-To: <E6F348CF-3D85-4F0B-9DD4-9B0614AF782C@mac.com>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig1ED91298260CD57847A74F6E"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, ananth@cisco.com, L.Wood@surrey.ac.uk, "Biswas, Anumita" <Anumita.Biswas@netapp.com>
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: Tue, 29 Jun 2010 16:51:38 -0000


rick jones wrote:
> 
> On Jun 28, 2010, at 7:46 PM, Joe Touch wrote:
>>
>>     - 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 ;-)
> 
> I think that is a place where one should be careful what one wishes for.
> If the NIC vendors become too accustomed to going off the standard body
> reservation at the link-layer, chances are they and the other vendor
> types with which they interact won't make much of distinction for
> transport.

They already are going "off the reservation" with jumboframes. Those are either
useless (as you imply above, e.g., because of lack of interoperability), or
important to support properly.

If jumboframes aren't used, AFAICT there's no problem to solve. If they are
used, the problem lies in the jumboframes themselves using an insufficient CRC.

Joe