[Iccrg] What's wrong with TCP Congestion control
michael.welzl at uibk.ac.at
Tue Feb 7 15:57:52 GMT 2006
> 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.
More information about the Iccrg