Re: [tcpm] WGLC for MSS document

David Borman <dab@weston.borman.com> Thu, 03 September 2009 15:56 UTC

Return-Path: <dab@weston.borman.com>
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 B945A3A6D8C for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 08:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
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 TZwrZMAZxs-Z for <tcpm@core3.amsl.com>; Thu, 3 Sep 2009 08:56:25 -0700 (PDT)
Received: from frantic.weston.borman.com (frantic-dmz.weston.BORMAN.COM [206.196.54.22]) by core3.amsl.com (Postfix) with ESMTP id 232AC3A696B for <tcpm@ietf.org>; Thu, 3 Sep 2009 08:56:24 -0700 (PDT)
Received: from [172.25.44.8] (weston-43.weston.borman.com [206.196.45.43]) by frantic.weston.borman.com (8.12.5/8.12.5) with ESMTP id n83F0hlm017218; Thu, 3 Sep 2009 10:00:44 -0500 (CDT)
Mime-Version: 1.0 (Apple Message framework v1075.2)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
From: David Borman <dab@weston.borman.com>
In-Reply-To: <275B75BC-634B-45A7-8F65-63870813A809@tcb.net>
Date: Thu, 3 Sep 2009 10:00:43 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <1A061317-E555-41AC-9040-571DFCB2C317@weston.borman.com>
References: <20090826135651.00EF23F8684@lawyers.icir.org> <275B75BC-634B-45A7-8F65-63870813A809@tcb.net>
To: Danny McPherson <danny@tcb.net>
X-Mailer: Apple Mail (2.1075.2)
Cc: tcpm@ietf.org
Subject: Re: [tcpm] WGLC for MSS document
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: Thu, 03 Sep 2009 15:56:26 -0000

Danny,

Thanks, I was unaware of this, and I'll add that in to the document.

For everyone else that has provided comments so far, they are all good  
and I have an updated version of the draft that just isn't quite done,  
but I hope to get it posted by the end of Friday.  The WG chairs are  
extending the WGLC for the revised version. :-)

			-David Borman

On Sep 3, 2009, at 9:37 AM, Danny McPherson wrote:

>
> I agree with Marks's comments - in general I like the document
> (my colleague Aaron Campbell and I asked for and offered to write)
> something similar quite a while back).
>
> It is worth noting that the confusion isn't universal, at least, the
> Linux, NetBSD, and OpenBSD people got it right (options are not
> subtracted from the advertised MSS on these systems from our past
> research).
>
> RFC2385 is wrong, though:
>
> ----------
> 4.3  TCP Header Size
>
>  As with other options that are added to every segment, the size of
>  the MD5 option must be factored into the MSS offered to the other
>  side during connection negotiation.  Specifically, the size of the
>  header to subtract from the MTU (whether it is the MTU of the
>  outgoing interface or IP's minimal MTU of 576 bytes) is now at least
>  18 bytes larger.
> ----------
>
> Perhaps the draft could cite RFC2385 as a bad example and point out  
> the
> error?  We saw this cause fragmentation with a Cisco GSR talking to  
> a BSD
> box.  The GSR was subtracting the size of the TCP MD5 option from the
> advertised MSS and assuming that the BSD box was doing the same.   
> Since the
> management interface on the GSR was POS, it ended up sending an MSS  
> of 4386,
> while the BSD box sent 1460 (Ethernet).  The lower of the two values  
> gets
> used, so the GSR assumed it could send 1460 bytes payload on top of  
> the fixed
> IP + fixed TCP + TCP MD5 option, so it was overrunning the 1500 byte  
> MTU by
> 18 bytes.  Note, this isn't a problem for Ethernet-to-Ethernet,  
> because the
> GSR would choose an MSS of 1442 (although Jumbo frames may be an  
> issue at
> some point), and being lower than 1460, would be the negotiated  
> maximum for
> both sides of the connection.
>
> -danny
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm