Internet Congestion Control for Future High Bandwidth-Delay Product Environments May 25, 2009

This paper discusses XCP, a proposed successor to TCP which provides much better behavior than TCP by increasing bandwidth utilization, reducing bottleneck queueing, and drastically reducing packet loss, especially over networks with high bandwidth-delay products.

The main points of the paper were as follows:

1. The most significant insight provided by this paper is that TCP tries to do too much at once. By separating efficiency and fairness, XCP is able to better serve both goals. This is primarily because optimizing efficiency and fairness require two different algorithms. Optimizing efficiency is best served by a multiplicative-increase multiplicative-decrease (MIMD) system, which allows XCP to quickly converge on maximum utilization of the available bandwidth by all flows. Optimizing fairness, on the other hand, it best served by an additive-increase multiplicative-decrease (AIMD) system, which converges to a fair solution. Since TCP only uses AIMD for all efficiency and fairness requirements, it is sluggish when trying to take advantage of all of the available bandwidth.
2. In addition to allowing different algorithms for efficiency and fairness, splitting the goals also allows modifying one system without affecting the other. This is useful in multiple contexts. For example, it is possible to modify the fairness controller to take advantage of pricing information to allow usage-based billing and bandwidth allocation. It is also possible to use a different fairness controller, like one based on a binomial law, in order to try to optimize fairness in different situations. This simplifies the design and testing of different algorithms because the amount of code that has to be modified is reduced and there is no risk of damaging efficiency while modifying fairness.
3. While XCP is a very effective system, it is all for naught if it cannot be deployed efficiently. The authors of the paper provide two different ways that XCP can be incrementally deployed. The first is as a cloud within a TCP network. This would allow an ISP to deploy XCP within their administrative domain while the rest of the Internet remained primarily TCP-based. This would benefit ISPs because of the fairness options allowed under XCP. Some ISPs are already trying to implement usage-based billing/allocation, and XCP would facilitate that through its fairness controller design. The other option is to modify XCP routers to handle TCP traffic as well, balancing TCP and XCP traffic using a weighted fair-queuing approach. This is somewhat similar to the dual-stack IP situation, where more and more routers are having to handle two similar, but distinct, classes of traffic fairly.

The biggest weakness of this paper is that many of the parameters seem to be based on theoretical results. Normally this is the thing lacking from papers, which tend to use “stochastic optimization” to pick algorithmic parameters. However, in the case of this paper, it might be nice to see a chart where they try their optimal parameters against others to verify that they are indeed optimal.

Future research on XCP should look at various fairness algorithms in order to determine which are best for deployment on the Internet at large, with its large number of traffic classes and diversity of users. Research could also examine all of the various control parameters to verify that they still apply on the Internet as well.

Congestion Control for High Bandwidth-Delay Product Networks May 25, 2009

(i) Three most important things

1. TCP becomes inefficient and susceptible to instability in high bandwidth delay product networks. The additive increase of 1 packet per RTT is too slow and the increase in link capacity does not improve the transfer delay of short flows. The paper proposes a new protocol known as XCP designed to be efficient, fair, scalable, and stable as the bandwidth-delay product increases.

2.  Packet loss is a poor signal of network congestion. Loss is bad because congestion is not the only source of loss and because a definite decision that a packet was lost cannot be made quickly. XCP has the routers inform senders about the degree of congestion instead of a single-bit congestion notification. Every router along the path can update the congestion header in the XCP packet and the sender can then use the feedback information to increase or decrease its send window.

3. Efficiency control (control of utilization or congestion) should be decoupled from fairness control. Robustness to congestion requires the behavior of aggregate traffic to be independent of the number of flows in it. XCP uses an efficiency controller (EC) to ensure that all spare bandwidth is being used and a separate fairness controller (FC) to set the feedback values proportionally to ensure that all flows are receiving equivalent bandwidth.

(ii) Most glaring problem

The most glaring problem would be that deploying XCP would require a makeover of both end systems and routers. All the routers along the path would need to be reimplemented so that routers can update the congestion header in the XCP packet and the end systems would need to be reimplemented to handle the feedback information from the congestion header.

(iii) Future Research Directions

Future research directions for this work would be to simulate the gradual deployment of XCP and report results and any issues that arise. The fairness between XCP and TCP competing on the same network should be included.

Congestion Control for Future High Bandwidth-Delay Product Environments May 25, 2009

1. Explicit rate control feedback to sender.

XCP explicitly lets the sender know how it needs to vary its rate to optimize utilization while avoiding congestion. This way it does not depend on packet drop as an indication of congestion hence avoiding packet drops. It uses the difference between available and utilized bandwidth and current queue length to compute rate change information.

2. Separate fairness and efficiency control.

It has separate mechanisms to handle fairness control and efficiency control. This gives the user the flexibility to implement different control laws for the two. It also means the user has flexibility to implement different fairness laws for different users depending on commercial incentives. It also means efficiency control can be optimized to maximize bandwidth utilization without being held down by fairness laws. In the implementation mentioned in the paper, MIMD is used for efficiency control which works a lot better than AIMD for short bursts of traffic.

3. Bandwidth shuffling

When the efficiency (a combination of queue length and bandwidth utilization) is near optimum, bandwidth shuffling ensures that throughput of individual flows  continue to converge towards their ideal fair-share values while aggregate throughput at the router remains constant. This ensures efficient decoupling of efficiency and fairness control.

Drawback

The XCP implementation comes at added cost. The routers piggyback congestion control information on packets returning to the sender. This adds to packet size and subsequently the amount of control data flowing in the network.

Future Work

XCP could be extended to distinguish between traffic requiring guaranteed delivery and traffic requiring bandwidth guarantees but can tolerate packet loss (eg. audio/video traffic). The control policies could be modified to handle the two types of traffic differently while maintaining optimized utilization and fair division of resources.

Internet Congestion Control for Future High Bandwidth-Delay Product Environments May 19, 2009

The XCP scheme uses explicit feedback to manage the congestion of a network. It does so using a header containing, among other things, a feedback value first initialized by the sending end-host, and modified by routers along the way according to the output of an “efficiency controller” and a “fairness controller” on each.

The idea of having these two controllers is the separation of congestion and fairness. The efficiency controller decides that the total traffic should change by a certain amount. The fairness controller then takes this amount and distributes the change among individual packets by changing the congestion header.

Internet Congestion Control for High Bandwidth Delay Product Networks May 19, 2009

(i) The three most important things the paper says:

 

1) The concept of decoupling utilization control from fairness control was a novel idea in this paper.  This stemmed some good points, for instance, opening up new avenues for service differentiation.  This was an important point from a business perspective, since ultimately what drives the deployment of new technology will hinge on large corporations adopting it.  Another good point is how this separation simplifies the design and analysis of each controller by reducing the requirements imposed. 

 

 

2) Since congestion is not a binary variable and requires a degree of values to truly measure it, the protocol must reflect this as well.  Because of this, Katabi et al ultimately decided to use a precise congestion signaling where the network tells the sender the state of congestion. From my perspective, this is the cusp of XCP since it allows them to have amazing results such as “rarely loosing packets” and “efficient use of bandwidth in a multitude of conditions”. 

 

3) The method in which they implemented XCP, a protocol based on network control of flows, with little overhead to routers.  By storing feedback information in a header, and making routers “stateless”, they estimated that a XCP router only performed a few additions and 3 multiplication per packet.  This is important as we are demanding faster routers and switches at the edge of our networks, any additional overhead may make a solution no longer viable.

 

(ii) The most glaring problem with the paper:

 

Although the paper considered security aspects and how to detect senders that do not honor XCP, they do not consider the cases of rouge routers.  Since this is a protocol that relies on the network (aka routers) from making the right choices, I believe that router security should be considered more.  Specifically, consideration of methods to avoid paths that routes through a router that you know is making poor or malicious decisions.  This is pivotal before XCP can be deployed in a commercial setting, since a single rouge router can trick the rest or the routers to believe that senders are misbehaving.

 

(iii) The future research directions of the work:

 

They seem to be very proud on the fact that in their tests, XCP rarely loose packets.  I believe this may have been a blind spot in their research.  A good direction for the research would be to analyze more dimensions of tests that involve XCP behavior in low reliability networks.  Since they aim to replace TCP, this is an important facet to cover the flexibility of this protocol.