Re: Questions about Internet Packet Losses
So you'll note that there are very clear spikes at 552 and 576 total packet size. Further, note that the curve falls off _extremely_ rapidly. From that, I argue that case (2) _cannot_ be the case because any type of random distribution would be much smoother.
(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 ....).
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. 512 is far and away the most common MSS in the traces. (All the TCP's in the traces are BSD variants except for Solaris and Linux.)
256?
My best guess is SLIP links.
4) 41 bytes is pretty obviously interactive traffic. Is the intuition correct?
That's my guess too.
What's so special about 44, 52, 48 and 56?
Ack/SYN/FIN's with options.
What do people do with 4, 8, 12 and 16 bytes of data? And why not any of the odd values?
Because option sizes are rounded up to multiples of 4 bytes. Vern
[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
participants (2)
-
John Hawkinson -
Vern Paxson