This paper defines a new protocol in which routers and end nodes cooperate in order to achieve optimal flow and fairness. The router simply computes the difference between its current use and its optimal use, and then sends messages to nodes telling them how much to increase or decrease their window sizes by. Similarly, the end nodes must tell the routers their current congestion window size and estimated round trip time. By using information returned by the router (piggybacking on an ACK), the end nodes can reach optimal utilization in one round trip, as opposed to the many needed by TCP.
This system is especially useful in that it allows for efficient communications across mediums such as satellite links, which have high bandwidth, but also high round trip times. The high round trip times mean that algorithms such as TCP take an enormous amount of time to use all of the available bandwidth (since the congestion window is adjusted by 1 per round trip). In contrast, XCP allows it to be done in just one round trip, which should (hopefully) yield desirable results in such situations.
The only flaw is the obvious inability to control misbehaving users. Users who simply transmit too many packets are likely to get away with it, because the only thing the router does is ask them to slow down. It won't start dropping their packets until its queues are full, so a misbehaving client can really steal a lot of bandwidth from other users. Even when you try to push this responsibility to the edge routers, there is a problem: the Tier 2 ASs may try to "cheat" their Tier 1 providers to get more bandwidth for their own customers.
However, this proves the point that the internet could be much more efficient if only we were able to trust the end users. It also introduces a very important notion of the separation between fairness and efficiency control. By using a single algorithm to determine by how much the flow needs to change, and using a completely separate algorithm to determine how to distribute the adjustment between different nodes, they have essentially turned the router into 2 components which can be modified separately. This is important for future updates.
Speaking of updates, this paper glosses over the distribution issue. While it is true that it can probably coexist with TCP, separate queues for each is probably not ideal. Neither is sending a TCP packet to check for the existence of XCP, especially if that packet has to go through many routers to perform the check properly. And lastly, the installation of XCP one AS at a time is known as a "forklift upgrade", and is generally considered to be one of the worst ways to do an upgrade.
1 comment:
I agree with most of your comments here. While not addressed directly paper, I see that there is a way to sample flows, and verify that their cwnd and rtt reported in congestion header are consistent with rate observed at the given router. If they are not, XCP can do what RED does in terms of a penalty box mechanism. I admit that the details aren't there, but there is only so much you can put in any given paper.
Post a Comment