[Iccrg] What's wrong with TCP Congestion control

[Michael Welzl]

> 1. Unsustainable large equilibrium window sizes under high bandwidth-delay
> product environments; requires an unrealistically low loss probability.
> (Leads to limited dynamic range)
>  2. Low throughput under lossy environments because of using loss as an
> indication of congestion.
>  3. Slow additive increase: Takes a long time for flow to catch up with
> spare capacity and results in unnecessary long flow-completion times.
>  4. Inefficient Slow-start: Even when the flow is capable of completing
> within a round-trip time, slow-start makes flows last multiple round-trip
> times just to find their fair share rate. Often most flows complete
> before they exit slow-start phase.  
>  5. Large queueing delay: TCP fills up any amount of buffering available at
> the bottleneck links. Results in long latency. 
>  6. Unfair bandwidth sharing: shares bandwidth inversely proportional to
> flow RTTs
> 7. TCP builds a standing queue at the point of congestion, which increases
> the delay. 
> 
> Did I miss anything?

According to the Padhye equation, the throughput of a TCP sender
is directly related to the packet size - so, a sender with large
packets would get more throughput than a sender with small packets.
>From a fairness point of view, that's at least odd.

I can't think of any measurement studies which indicate whether
this is a problem or not right now, but there surely are some
(perhaps somewhere in the papers that were written on TFRC
with variable packet sizes, don't know).

In my previous email, I stated that looking at relatively
"safe" proposals like HighSpeed TCP might give us good hints
about things that are wrong with TCP. Based on this viewpoint,
I would say that the fact that TCP increases its rate at a
fixed value, irrespective of the current network conditions,
is one of the problems with this protocol.


Cheers,
Michael