Congestion Control for High Bandwidth-Delay Product Networks


Dina Katabi (MIT-LCS), Mark Handley (ICSI) and Charlie Rohrs (Tellabs)
SIGCOMM 2002

Summary:
In this paper, the authors propose and investigate a new congestion control algorithm, eXplicit Congestion Control (XCP), for best-effort traffic in the Internet.  They argue that TCP becomes inefficient and prone to instability in high bandwidth-delay product environments, thus requiring a new protocol to handle traffic in the future Internet which will incorporate high-bandwidth optical links and more large-delay satellite links.

Key components of XCP:
  1. Congestion header
    Every packet has an extra congestion header which carries the sender's cwnd and Round Trip Time (RTT) values, along with a congestion feedback value.  This congestion feedback value is initialized by the sender and modified along the path by routers to provide explicit congestion feedback.

  2. Routers decouple efficiency and fairness control while calculating feedback
    • Efficiency controller
      This controller calculates an aggregate feedback value for maximizing link utilization.
    • Fairness controller
      This controller distributes the aggregate feedback value among individual packets to ensure fairness amongst flows.
Through analysis and simulations, the authors show that XCP maintains good utilization and fairness, has low queueing delay and drops very few packets even for high bandwidth-delay network configurations.

Critique:
  1. In their simulations, it appears that the authors do not scale the RED and REM parameters when scaling the bandwidth or propagation delay.  They claim that the buffer size is set to the bandwidth-delay product, but in their graphs, RED maintains an average queue size of 1-2% of the bandwidth-delay product and is flat!  If the RED thresholds are scaled along with the buffer size, we should see RED's average queue size linearly increasing when bandwidth or delay increases.  Thus, their comparison with RED, REM etc. is not a fair comparison.
  2. There is no comparison against TCP Vegas.  The authors propose a completely new algorithm for congestion control which requires changes in both the end-systems and routers.  TCP Vegas only changes the end-system protocol and has been shown to perform well and remain stable in high bandwidth-delay network configurations.
  3. The authors also do not consider per-flow AQM policies.  Prior work has shown that Deficit Round Robin (DRR) variants such as Queue State DRR and Throughput DRR can achieve the same efficiency and fairness for TCP Reno flows using queues that are a fraction of the bandwidth-delay product.
  4. For the parking lot topology, it would be interesting to see whether the fairness criteria is still met, i.e. the flows traversing multiple hops are able to achieve the same throughput as the single-hop flows.
  5. The authors mention using XCP to throttle misbehaving flows, but to identify misbehaving flows, the routers have to maintain per-flow state.

In summary, although the authors present an interesting congestion control protocol, their comparisons against other AQM policies are biased.  They do not consider per-flow AQM policies at all and they do not compare against other TCP variants such as TCP Vegas.

Anshul Kantawala