30%, huh? (Re: Questions about Internet Packet Losses )
avg at pluris.com
Tue Jan 14 09:59:38 UTC 1997
Paul A Vixie <paul at vix.com> wrote:
>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.
I wish it was as simple as that. My educated guess is that 30% packet
loss corresponds to about 1000% overcommitment. TCP actively reduces
packet loss by doing congestion avoidance, so the results are more
than a bit skewed.
Strictly speaking, your assumption would be correct if packet arrivals
were independent (i.e. Poisson).
>As Tony and others have remarked here today,
>TCP does not overcommit enough once it's up and running to account for 30%
Just a little bit to test water :) But that's steady state.
We're talking about the system where TCP doesn't really have a chance
to establich proper window, mostly because of HTTP silliness.
>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.
HTTP barf barf barf. That's the poster case of shortcomings of the
computer science education which prefers to neglect the gory details
of what happens in the hardware or "lower levels" in general.
>So if we are seeing 30% overcommit, my gut feeling is that most TCP endpoints
>aren't using slow start.
No, 30% loss can easily be caused by the initial TCP SYNs. The average
flow duration is something like 12 packets, yes?
TCP works well only when there's enough slack to handle initial SYNs.
Actually, that's one argument against RED. It is interesting to explore
how the network will behave if SYNs are given priority over 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.
I'd say IETF should be abolished. If there's an argument about _that_
there's a serious doubt about overall sanity of the organization.
>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."
Well, no. Non-compliant TCP implementation is like ping -f.
It should be a sufficient reason for disconnecting from the network.
>I saw an ad for one company who advertised that their TCP stack was 200%
>faster than the rest of them.
Yep. The big problem is the sad state of cluefulness of the general
user society. This ad sounds awfully like "buy our gun, earn $1000
in 30 minutes!".
>As a good friend likes to tell me: "The world is full of clowns."
More information about the NANOG