The next two papers we will be discussing are strategies that use explicit congestion signals. Routers along the path implement marking that enables responsive flows to discern levels of congestion in the network. The first paper Random Early Detection (RED) algorithm makes changes in the routers while retaining the behavior of the transport protocol. In the EXplicit Congestion Protocol (XCP), some changes in the core nodes and at the end-points are assumed.
The RED gateway implements a marking strategy based on observing the average queue length in a gateway. There are two parts in RED’s algorithm. The first part involves the computation of the average queue size. This value gives an indication of the level of burstiness allowed in the gateway. The second part involves the marking algorithm. Packets are marked with a probability proportional to their share of the bandwidth if the average queue size exceeds a specified threshold range. Once this range (the maximum threshold) is breached, all subsequent packets are marked. This explicit signal allows senders to throttle back their transmissions. This allows RED to avoid congestion by controlling the average queue size. Results show that the algorithm avoids global synchronization and is not biased towards bursty traffic. There are several discussion points here: first is the selection of the optimum operating point (average queue size, thresholds); next is the effect of linking several RED gateways with different configurations in a chain; lastly, is the use of several RED queues in a single gateway.
The XCP paper uses the idea that routers in the network provide, as the protocol is aptly called, explicit feedback to the endpoints. This is in contrast to the TCP practice of using drop packets as indicators of congestion. One of the motivations of XCP is the instability of TCP especially if the path includes both high-bandwidth and large-delay links. In XCP, the sender sends details of its congestion window and round trip time estimate in an XCP congestion header. Depending on the input traffic, routers in the path uses information in this header to explicitly transmit adjustments (increase or decrease) to a sender by modifying the feedback field. As this information is seen and can be changed by any routers in the path, it will contain the feedback from the bottleneck router. The receiver upon receipt of this header, copies and sends it back to the sender for its appropriate action. Since the sender receives this information explicitly. the convergence has been shown to occur quickly than TCP. In addition, XCP has been shown to work well under several different types of scenarios. However, I would have wanted to see how XCP performs when mixed with other types of transport traffic like TCP and even UDP. This would have probably given insights on how XCP and the network in general will work and would have been a nice step towards a possible incremental deployment rather than purely an academic result.
One of the key points in XCP is that it looks to minimize packet drops by preventing queues from building up. XCP also aims to decouple utilization from fairness control. The idea is that the efficiency controller uses all the spare bandwidth while the fairness controller sends the feedback values proportionally to ensure all flows are receiving the equivalent bandwidth. Potentially, with these additional capabilities, one can also include policies in place to allow for some sort of QoS differentiation in an XCP network.
1 response so far ↓
Randy Katz // September 17, 2008 at 2:30 am
Note that the XCP evaluations are based on sample network topologies and simulations, although there are control theoretic proofs in the paper’s appendix (and in Katabi’s dissertation). There is still fear in the operational community about the impact on stability should a new transport protocol ever get deployed.
Keep on blogging!