Paul A Vixie <paul@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% loss.

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 "regular" packets.

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."

Indeed. --vadim