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, 03 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
- [tcpm] WGLC for MSS document Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] WGLC for MSS document Alexander Zimmermann
- Re: [tcpm] WGLC for MSS document Joe Touch
- Re: [tcpm] WGLC for MSS document L.Wood
- Re: [tcpm] WGLC for MSS document Joe Touch
- Re: [tcpm] WGLC for MSS document Mark Allman
- Re: [tcpm] WGLC for MSS document Danny McPherson
- Re: [tcpm] WGLC for MSS document David Borman
- Re: [tcpm] WGLC for MSS document David Borman
- Re: [tcpm] WGLC for MSS document Alexander Zimmermann
- [tcpm] Fwd: WGLC for MSS document David Borman
- Re: [tcpm] WGLC for MSS document David Borman
- Re: [tcpm] WGLC for MSS document Xiangsong Cui
- Re: [tcpm] Fwd: WGLC for MSS document Danny McPherson
- Re: [tcpm] Fwd: WGLC for MSS document Joe Touch
- Re: [tcpm] WGLC for MSS document Mark Allman
- Re: [tcpm] WGLC for MSS document Alexander Zimmermann