Re: [tcpm] WGLC for MSS document

[Danny McPherson <[e-mail]>]

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