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