[e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic
dhavey at yahoo.com
Thu Feb 2 00:04:31 PST 2012
Haha ;^) Just gracious enough. Let me add, the pig-hearted service provider who silently drops non-TCP packets.
...No offence to pigs or service providers ;^)
Suppose we have three users, they have RTTs of .01, .1, and 1 seconds. User 1 can compete fairly and get it's fair share of the bottleneck capacity. Users 2 and 3 would have more difficulty. If there is a little packet loss from a poor connection then the situation is even worse.
Users 2 and especially 3 would have much improved chances of competing for their fair share if they used Cubic rather than Reno.
I understand that RTT fairness, and lossy connections aren't part of the TCP design and perhaps they shouldn't be. However, I think that Cubic is more fair to disadvantaged users. These users will get closer to their fair share of the bottleneck capacity with Cubic than with Reno.
> Hypothetical: "I am sharing throughput with others via
> a network I
> don't control. I am greedy and want all the throughput
> I can get,
> fairness and inefficiency be damned."
> Perhaps I'm missing something, or less gracious than I
> should be, but
> I've always assumed this is the motivation for Linux using
> aggressive TCP replacements.
> Dave Hart
More information about the end2end-interest