Re: [tcpm] WGLC for MSS document

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