Summary: Congestion Control for High Bandwidth-Delay Product Networks

In the light of the clean slate nature of the Katabi et al. paper, other attempts to address congestion control/avoidance within the framework of TCP seem severely constrained.  The holy grail is a fair and efficient scheme whose parameters are not dependent on either the delay bandwidth of the network or the number of simultaneous connections.  Networks with massive bandwidth and high delay like satellite networks are poorly served by slow-start, which is unlikely to fill the pipe especially with short sessions.  Worse still, the TCP protocol's use of packet dropping as a signal and AIMD as a windowing strategy plays poorly with high delay conditions: it is easy to see how this will cause oscillation.

These issues are addressed by starting from scratch and proposing a protocol spoken at the ends AND the core, that separates the controls for efficiency and fairness, and uses explicit feedback in packet annotations to achieve a core-stateless solution.  Basically, the senders request an optimal window based on the application's needs, which is adjusted in the packets enroute, such that the eventual acknowlegement represents the available resources at the bottleneck router on the network path: one round trip is sufficient to initialize the window to a reasonable value.  

The obvious criticism of this otherwise beautiful (and intuitive) system is the difficulty of implementation in the existing infrastructure.  That said, the author's concept of a TCP over XCP overlay is rather elegant: just as CSFQ used the concept of router "islands" in the core, islands of XCP with TCP-aware edges could be introduced piecemeal into the core.