[wow, I clearly went to sleep to early]
(2) is a random distribution plus some spikes, plus some modality due to TCP's that can only generate packets of <= N bytes for different popular MSS's. So I think it still works (but will save more detailed analysis till later ....).
When Tony first posted his assertion I sent him a (!) message and then did a sanity check myself, with 1000 SYNs off a transit FDDI: I'll repeat it here; 935/1000 SYNs had MSS options, here they are. I just used tcpdump and didn't bother to pull off the wscale stuff since it seems like it might be interesting. Certainly my data shows a lot more 1460s than I would have expected, which makes me happy. 594 1460 128 512 90 536 23 4312 18 512,nop,wscale 15 1460,wscale 14 536,nop,wscale 10 1460,nop,wscale 8 966 6 4096 5 256 4 472 3 1024 2 212 2 1500 2 1464 2 1440 1 768 1 660 1 460 1 4378 1 216 1 1500,nop,wscale 1 1450 1 1420 1 1410 Certainly these numbers shouldn't be asssumed to be representative, however 512 is unfortunately a serious contender.
2) What OS is using a 512 MSS?
From a bunch of (~ 20,000) traces in my study, looks like
Irix 4.0/5.3, BSDI 1.1/2.0, OSF/1 3.0/3.2, and often but not always SunOS
use either 512 or 536, or sometimes 500, 524, or 548 (BSDI). Never anything higher. This doesn't mean they *can't* use anything higher, just that they never found an opportunity to do so.
Well, my SunOS machine offers an mss of 1460 because I decided that it as long as it wasn't going to use Path MTU Discovery, and the vast majority of links out there have MTU's >=1500. Under SunOS, this is controlled by tcp_default_mss, just change it in /sys/netinet/in_proto.c or adb your kernel. Of course, this means that you will may cause fragmentation at links with MTU's less than 1500. Hopefully that is isolated to high-latency dialup links with adequate buffering. This is not a problem/solution unique to SunOS, but it probably is one that hasn't been encouraged very much... Perhaps it should be? --jhawk