Re: Questions about Internet Packet Losses
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
I believe you're misinterpreting the numbers. The raw data for those numbers (if they're the same ones I'm thinking of) I doubt it, it's relatively new data. Like last Thursday. ;-) indicate that 9% of the packets had a 512 byte *payload*. I already subtracted off the 40 bytes for the headers. I meant MSS. You're correct, of course, that the percentage of packets at that size does not directly reflect the percentage of hosts with that as an MSS. However, the spikes in the packet percentages are clearly due to hosts using that MSS. You would otherwise expect to see a "smooth" distribution across packet sizes, which is not at ALL what's happening. 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. Wow. Imagine that. ;-) Tony
Warning: this isn't about north american network operations! Hit "D" now. I wish I had a background in "fractal mathematics" or whatever, but instead I've just got my gut feelings to go by. They say that 30% loss translates loosely to 30% overcommitment. As Tony and others have remarked here today, TCP does not overcommit enough once it's up and running to account for 30% loss. And given slow start, I'm not sure it could overcommit that much even given HTTP 1.0's tendancy to start a lot of new connections. So if we are seeing 30% overcommit, my gut feeling is that most TCP endpoints aren't using slow start. Even given blasty UCP-based multimedia protocols, a bunch of TCPs sharing an exchange point with such traffic would back off and be polite. 30% overcommit doesn't jibe with cooperating slow-start TCPs no matter how many new connections start up. I mention this only because the IETF had a huge flame war over whether slow start should be a recommended standard or not since it was just an implementation detail or so said some. TCP creates a prisoner's dilemma problem for implementors, and it's sad that more than one has said "let's not cooperate so that we can get more bit times." I saw an ad for one company who advertised that their TCP stack was 200% faster than the rest of them. Given that "the rest of them" start from BSD and virtually all try to cooperate and virtually all run at wire speed if there is no contention, I am guessing that this TCP stack went "faster" by being more aggressive. As a good friend likes to tell me: "The world is full of clowns."
participants (3)
-
Paul A Vixie -
Tony Li -
Vern Paxson