[e2e] [Iccrg] Re: Reasons not to deply TCP BIC/Cubic

[Daniel Havey]

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.

...Daniel


> 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
> more
> aggressive TCP replacements.
> 
> Cheers,
> Dave Hart
>