XCP - Congestion Control for High Bandwidth-Delay Product Networks

This paper presents a clean-slate router-assisted transport protocol that overcomes some deficiencies of TCP. In a nutshell, XCP asks end-hosts to state their congestion window and RTT estimate in packet headers, and uses this information to provide exact feedback about how they should change their window. This can be done without per-flow state. The main selling point for XCP is better performance on high bandwidth-delay product networks, where TCP is known to perform poorly and to become unstable (partly due to having to use additive increase of 1 packet, partly due to using losses as congestion signals). However, XCP also provides other advantages, such as fast convergence to efficiency and fairness, very low queue sizes, virtually nonexistent drops, separation of the efficiency and fairness controllers, and support for differentiated services. Simulations show that XCP performs as well as TCP or better in a variety of common scenarios (not just high delay-bandwidth product networks). All of this evaluation is necessary to motivate of XCP because it requires significant changes to the network: support in every router and end-host, and the architectural change of performing congestion control based on fields in the packet headers.

My main criticism of the paper is against keeping per-flow state in packet headers. The issue with this is that it's very easy to cheat at an endpoint, or to have a misconfigured router overwhelm a link. In a TCP-based network, congestion due to any reason causes packet drops, which are a signal to every host to reduce their rate. The drops can also be arranged to affect the misbehaving sender more than the others through something like RED. However, in an XCP network, there is plenty of capacity in the queues, so a misbehaving sender may get most of their packets through just fine, while still degrading performance for other users. The authors suggest policing at the edge of the network, but this is difficult to deploy, and there are few incentives for ISPs to do it. Even worse, an attacker may attack XCP *without* creating a large flow by simply requesting capacity as if they were to start a large flow. The network has to grant this capacity and reduce that of other flows, but there is no way to detect that the flow isn't actually going to use the bandwidth until some time later. This is like a SYN flood against routers. In contrast, TCP will utilize links pretty well even when many small flows are open. In summary, it seems that TCP should inherently be more robust to misbehaving users on a large network than XCP.

The work is nonetheless very interesting because of the magnitude of improvement that can be achieved, and it's one of those papers that makes us question the TCP-IP model. However, the main deployment challenge for these schemes is still to provide a compelling reason to switch from the existing IP infrastructure (which is rapidly improving in performance over time) while maintaining backwards compatibility with as many of the useful services built on TCP/IP as possible. In the end, higher performance on high bandwidth-delay product networks may be a good reason to switch away from TCP, but we're far from a point where this matters for most users in the Internet yet (Comcast, if you're deep-packet-inspecting this, it is meant at you!).