Yeah, but I doubt that they're in the majority. Recent stats indicate that
about 9% of the packets out there are using an MSS of 512. Another 1% are
using an MSS of 256. Only 6% are using 536, and 7% are using 1460. This
indicates to me that there are a whole lot of broken boxes out there still.
I believe you're misinterpreting the numbers. The raw data for those
numbers (if they're the same ones I'm thinking of) indicate that 9% of the
packets had a 512 byte *payload*. This is quite different than whether the
TCP sending the packet had a 512 byte MSS, because often the TCP doesn't
*have* 512 bytes to send. Crunching through the 340,000 HTTP connections
in and out of LBNL last Friday, less than 10% had requests exceeding 512
bytes. Even 35% of the replies were <= 512 bytes. Toss in SYN/FIN and
pure acks and you rapidly dilute the relationship between measured packet
size and MSS.
A much more solid way to estimate MSS's is to look at MSS options in SYN
packets. Rich Stevens did this in TCP/IP Illustrated Vol 3. I don't have
it here at home for precise figures, but he found that the large majority
of the MSS's were from a few standard sizes. He also found an immense range
of bizarre values (my personal favorite: 17,520 bytes), but they were rare.
All that said, at the next NANOG I'll talk about some findings from a TCP
behavior study I've been doing (it's part of the packet dynamics study).
One of my main findings is that independently-written (i.e., non-BSD-derived)
TCP's are much more likely to have serious performance and congestion problems.
Vern
