Internet Congestion Control for Future High Bandwidth-Delay ProductEnvironmentsDina Katabi Mark Handley Charlie RohrsMIT-LCS ICSI [email protected] [email protected] [email protected] and experiments show that as the per-flow productof bandwidth and latency increases, TCP becomes inefficientand prone to instability, regardless of the queuing scheme.This failing becomes increasingly important as the Internetevolves to incorporate very high-bandwidth optical links andmore large-delay satellite links.To address this problem, we develop a novel approach toInternet congestion control that outperforms TCP in conven-tional environments, and remains efficient, fair, scalable, andstable as the bandwidth-delay product increases. This neweXplicit Control Protocol, XCP, generalizes the Explicit Con-gestion Notification proposal (ECN). In addition, XCP intro-duces the new concept of decoupling utilization control fromfairness control. This allows a more flexible and analyticallytractable protocol design and opens new avenues for servicedifferentiation.Using a control theory framework, we model XCP anddemonstrate it is stable and efficient regardless of the link ca-pacity, the round trip delay, and the number of sources. Ex-tensive packet-level simulations show that XCP outperformsTCP in both conventional and high bandwidth-delayenviron-ments. Further, XCP achieves fair bandwidth allocation, highutilization, small standing queue size, and near-zero packetdrops, with both steady and highly varying traffic. Addition-ally, the new protocol does not maintain any per-flow state inrouters and requires few CPU cycles per packet, which makesit implementable in high-speed routers.1 IntroductionFor the Internet to continue to thrive, its congestion controlmechanism must remain effective as the network evolves.Technology trends indicate that the future Internet will havea large number of very high-bandwidth links. Less ubiqui-tous but still commonplace will be satellite and wireless linkswith high latency. These trends are problematic because TCPreacts adversely to increases in bandwidth or delay.Mathematical analysis of current congestion control al-gorithms reveals that, regardless of the queuing scheme, asthe delay-bandwidth product increases, TCP becomes moreoscillatory and prone to instability. By casting the probleminto a control theory framework, Low et al. [22] show thatas capacity or delay increases, Random Early Discard (RED)[13], Random Early Marking (REM) [5], Proportional Inte-gral Controller [15], and Virtual Queue [14] all eventuallybecome prone to instability. They further argue that it is un-likely that any Active Queue Management scheme (AQM)can maintain stability over very high-capacity or large-delaylinks. Although their analysis uses Reno TCP, their argumentis valid for all current TCP implementations where through-put is inversely proportional to the round trip time (RTT) andthe square root of the drop rate. Furthermore, Katabi andBlake [19] show that AdaptiveVirtual Queue (AVQ) [21] alsobecomes prone to instability when the link capacity is largeenough (e.g., gigabit links).In addition to these mathematical models, intuitive rea-soning shows that “slow start” might also lead to instabilityin the future Internet. As capacity increases, the majorityof flows become “short” flows which never exit slow start.Flows in slow start increase their rate exponentially, a dra-matically unstable behavior. Currently, although the numberof short flows is large, most of the bytes are in long-livedflows. Consequently, the dynamics of the aggregate trafficare usually dominated by the additive-increasemultiplicative-decrease policy. However, as the fraction of flows in slowstart grows, exponential increase may dominate the dynamicsof the aggregate traffic, causing instability.Potential instability is not the only problem facing TCPin the future Internet. As the delay-bandwidth product in-creases, performance degrades. TCP’s additive increase pol-icy limits its ability to acquire spare bandwidth to one packetper RTT. Since the bandwidth-delay product of a single flowover future links may be many thousands of packets, TCPmight waste thousands of RTTs ramping up to full utilizationfollowing a burst of congestion.Further, since TCP’s throughput is inversely proportionalto the RTT, fairness too might become an issue as more flowsin the Internet traverse satellite links or wireless WANs [25].As users with substantially different RTTs compete for thesame bottleneck capacity, considerable unfairness will result.Although the full impact of large delay-bandwidth prod-ucts is yet to come, we can see the seeds of these problemsin the current Internet. For example, TCP over satellite links1has revealed network utilization issues and TCP’s undesirablebias against long RTT flows [4]. Currently, these problemsare mitigated using ad hoc mechanisms such as ack spacing,split connection [4], or performance enhancing proxies [8].Simulation results similar to those in §5 support the aboveargument showing that, regardless of the queuing scheme,TCP’s performance degrades significantly as either capacityor delay increases.This paper develops a novel protocol for congestion con-trol that outperforms TCP in conventional environments, andfurther remains efficient, fair, and stable as the link bandwidthor the round-trip delay increases. This new eXplicit ControlProtocol, XCP, generalizes the Explicit Congestion Notifica-tion proposal (ECN). Instead of the one bit congestion indi-cation used by ECN, our routers inform the senders about thedegree of congestion at the bottleneck. Another new conceptis the decoupling of utilization control from fairness control.To control utilization, the new protocol adjusts its aggressive-ness according to the spare bandwidth in the network and thefeedback delay. This prevents oscillations, provides stabilityin face of high bandwidth or large delay, and ensures efficientutilization of network resources. To control fairness, the pro-tocol reclaims bandwidth from flows whose rate is abovetheirfair share and reallocates it to other flows.By putting the control state in the packets, XCP needsno per-flow state in routers and can scale to any number offlows. Further, our implementation (Appendix A), requiresonly a few CPU cycles per packet, making it practical evenfor high-speed routers.Using a control theory framework motivated by previouswork [21, 15, 22], we show that
View Full Document
Unlocking...