From: Ethan Phelps-Goodman (ethanpg@cs.washington.edu)
Date: Tue Oct 19 2004 - 18:09:14 PDT
Congestion Control for High Bandwidth-Delay Product Networks
Katabi et al.
The authors argue that the interplay of increasing bandwidth and delay will inevitably cause TCP to become unstable. They ignore backwards compatibility and deployability, and ask what could be achieved if a new congestion control mechanism was built from scratch. Their solution, XCP, is based on explicit congestion feedback from routers to sources. Through extensive simulations they show that XCP gives much better convergence to the optimal flow rate than does TCP with advanced queue management. They also show analytically, by control theory, that XCP will converge to a stable rate under any network conditions, unlike TCP.
The key problem with TCP is that congestion must be inferred from lost packets, and packet loss must be inferred from an estimate of the delay. Jacobson, in Monday's paper argued that this was enough information, and indeed it is enough to run today's internet, but that might not be the case as the bandwidth-delay product increases. The lack of explicit feedback in TCP led to the odd design of congestion control and fairness being two sides of the same coin. In XCP, the two are orthogonal subsystems, leading to a cleaner design. The actual mechanisms of XCP are not complicated. In essence, the bottleneck router determines how much more capacity it can handle per flow, and sends that information in down in a packet header to be returned to the sender in the receiver's ACK. Careful account of average delay has to be made in order to make the system stable. I find it interesting that this system could easily have been designed and deployed 1980, but it just wasn't needed.
One potential problem, which they bring up at the end of the paper, is that the scheme could easily be game to gain more than your fair share of bandwidth. They advocate policing agents at the edge of the network recording packet behavior to watch for cheaters. The biggest problem of course is deployment. They argue that the scheme can be incrementally deployed, and coexist with TCP traffic. Still, considering the pace of change for fundamental protocols, this paper is probably more useful for the points it raises than as a practical architecture.
This archive was generated by hypermail 2.1.6 : Tue Oct 19 2004 - 18:09:19 PDT