[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 SunOSuse 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