Further research on this:
> [If I understand the code correctly ... - expert intervention invited]
> More precisely, this sets the MSS option to the MTU of the outgoing
> link for this packet (so it must have already been routed) minus the
> minimal size of a TCP and IP header, which is typically but not
> necessarily the "right" value.
> [In particular, if tcp options such as timestamp might be used then
> you really want to lower MSS a bit more to make room for these,
> right? So to be on the safe side, if you're lowering MSS due to
> a link with MTU<1500 then you should probably use something like
> MTU - 60, or perhaps to be really safe, leave room for maximal IP
> and TCP headers with MTU - 120 ]
rfc879
To resolve the ambiguity in the TCP Maximum Segment Size option
definition the following rule is established:
THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS
FORTY.
It goes on to say that when tcp or ip options are used then the
MSS has to be effectively reduced. And in fact, this is what I
see going on in limited testing so far.
http://www.rfc-editor.org/cgi-bin/rfcsearch.pl lists the status of
rfc879 as UNKNOWN, but rfc1191 is listed as status DRAFT STANDARD and
it refers to above.
So, new wording for above should be
More precisely, this sets the MSS option to the MTU of the outgoing
link for this packet (so it must have already been routed) minus 40
which is supposed to tell the sender to limit packet size (including
TCP and IP headers, including any options they contain) to MSS+40.
For more details see RFC 879 and 1191.
