Re: [tcpm] WGLC for MSS document

Danny McPherson <> Thu, 03 September 2009 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C85413A6985 for <>; Thu, 3 Sep 2009 07:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CMldABi7z3GN for <>; Thu, 3 Sep 2009 07:39:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 035573A68A8 for <>; Thu, 3 Sep 2009 07:39:11 -0700 (PDT)
Received: by (Postfix, from userid 0) id 3FC3B368046; Thu, 3 Sep 2009 08:37:35 -0600 (MDT)
Received: from ( []) (authenticated-user danny) (TLSv1/SSLv3 AES128-SHA 128/128) by with SMTP; Thu, 03 Sep 2009 08:37:35 -0600 (MDT) (envelope-from
X-Avenger: version=0.7.8;; client-ip=; client-port=58983; syn-fingerprint=65535:56:1:64:M1408,N,W1,N,N,T,S; data-bytes=0
Message-Id: <>
From: Danny McPherson <>
To: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <>,
In-Reply-To: <>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 03 Sep 2009 08:37:33 -0600
References: <>
X-Mailer: Apple Mail (2.936)
Subject: Re: [tcpm] WGLC for MSS document
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: Thu, 03 Sep 2009 14:39:11 -0000

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

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  
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  
while the BSD box sent 1460 (Ethernet).  The lower of the two values  
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  
some point), and being lower than 1460, would be the negotiated  
maximum for
both sides of the connection.