What happens when someone says they want a TCP MSS=0?

[Jeffrey Mogul]

In article <2809 at mace.cc.purdue.edu> dls at mace.cc.purdue.edu (David L Stevens) writes:
>	IP says that any Internet host must be able to receive packets of at
>least 576 octets. So any technology using TCP/IP has to allow packets of at
>least 576 - 60 (IP headers, max) - 20 (TCP headers, no opts) = 496 octets of
>TCP data. Without IP options, it's 516, or 512 to pick a nicer number.

Although any IP host has to be able to receive 576-byte datagrams, I
believe it is legal for a TCP to ask the sender to send smaller ones.
However, I think there is a lower limit on the MSS, because it makes
no sense to set it smaller than 1 byte.

>	Though I don't believe RFC 793 says so, packets with MSS of 0, or
>really anything less than 496, should be dropped along with implementations
>that generate them.

If the MSS is > 0 (and not too large), then the packet is legal and it
should be obeyed.  Owners of implementations that send tiny MSS values
will find out soon enough (as I did a few years ago when we forgot to
byteswap the MSS value before sending it!); the performance impact is
too obvious to overlook.  If the MSS is 0, then this is probably
worth doing something about.  The robustness principle implies that
the TCP receiving this option should do something close to what the
sender means ... so I would probably interpret this as asking for
the minimal "reasonable" MSS, which is 1 byte.  Alternatively, one
could treat this as a bogus value, and use the default.  Perhaps the
"Host Requirements" RFC will say.  Anyway, it does look like it is
wrong to simply accept the MSS=0.

>	Note that small MSS's reduce the data/header ratio and thus the
>effective throughput, so choosing the largest MSS that IP requires (496)
>as the minimum is the best you can do without knowing that the underlying
>hardware on the other end can do more.

On the contrary; there are situations when setting the MSS too large
is counterproductive.  There are still links in the Internet with
MTUs < 256 bytes (!), and over such links it is probably optimal
to use a rather small MSS if there is a high chance that fragments
might be dropped.  4.3BSD-derived systems include code to do this
if the small-MTU network is directly attached to the host.

>	Silently enforcing it is a simple "mss = MAX(mss, 496)" in tcp_mss();
>sending a RST segment and dropping the packet would be better, though.

This almost certainly violates the robustness principle.  Unfortunately,
there is no way for TCP to indicate "bogus value in packet" analogous
to the ICMP parameter problem message (which I don't believe can be
used here).

-Jeff