This paper sets out to re-create congestion control from scratch. A big point made by the authors is that congestion not binary, so why should feedback to the endhosts be? Every packet has a congestion header which has a feedback field that routers along the path modify to let the sender know how much to change its window size. An ack is sent from the receiver that contains the feedback value.
An interesting decoupling the authors choose is to separate efficiency from fairness. While this may seem somewhat strange in that they both have to do with how a link is utilized, the paper's argument that the number of flows is constantly changing is a valid one. An efficiency controller attempts to allocate all bandwidth on the level of bytes through the use of a feedback function which takes into account spare bandwidth and persistent queue size as well as roundtrip time. The efficiency controller doesn't concern itself with which senders get the feedback just as long as the total result is more efficient bandwidth usage; the fairness controller does the allocation.
Based on the paper's simulations, XCP drops very few packets and attains high utilization of bottleneck resources; the authors chose maintaining a small queue size to be of higher importance than obtaining highest possible utilization. It also handles sudden changes in traffic much better than TCP does. However, XCP does not inherently have protections against misbehaving users, but because of the additional information stored in the congestion headers, if a router is willing to keep some per-connection state, it can check to ensure a user is actually responding to given feedback.
No comments:
Post a Comment