As we have noted, many of the elements of PCP have been proposed elsewhere; our principal contribution is to assemble these ideas into a system that can emulate the efficiency of network-based congestion control.
Our work on PCP is inspired in many ways by Ethernet arbitration [8]. PCP, like Ethernet, is designed to perform well in the common case of low load, with high load stability and fairness an important but secondary concern. Ethernet's lack of stability and fairness in certain extreme cases yielded much followup work within the academic community, but Ethernet's common case performance and simplicity was sufficient for it to be wildly successful in practice.
Our work also closely parallels the effort to define algorithms for endpoint admission control [11,23,33,17,7]. In these systems, endpoints probe the network to determine if a fixed-rate real-time connection can be admitted into the system with reasonable QoS guarantees and without disrupting previously admitted connections. As with our work, this research demonstrated that endpoints can effectively emulate centralized resource management. Nevertheless, there are significant differences with our work. First, real-time connections have fixed bandwidth demands and are relatively long-running; hence, probes were run only at connection setup, and it was not necessary to make them particularly efficient. For example, Breslau et al. suggest that probes should use TCP-like slow start to determine if there is sufficient capacity for the connection [11]. Our system is designed to allow probes to be short and precise. With endpoint admission control, once the connection is started, no further adaptation is needed; by contrast, dynamic adaptation is clearly required for efficient and fair congestion control.
Another major area of related work is the various efforts to short-circuit TCP's slow start delay for moderate-sized connections. Typically, these systems use some form of rate pacing for the initial (large) window, but revert to TCP-like behavior for steady state. This allows these systems to be mostly backwardly compatible with existing TCP implementations. As we have argued, however, determining the available bandwidth along a network path is easiest when network traffic is designed to be smooth and well-conditioned. For example, TCP Swift Start [43] uses an initial burst of four packets to measure the physical (not available) capacity of the network path. The hosts then set their initial window to be a fixed fraction (e.g. 1/8th) of the physical capacity. If the bottleneck has significant unused bandwidth, this works great, but it can theoretically create persistent congestion if the rate of arriving flows is greater than the fixed fraction can support. TCP Fast Start [42] and the MIT Congestion Manager [6] use history to guide the selection of the initial congestion window and other TCP parameters; however, their approach only works for nearly simultaneous connections to the same destination.
Similarly, several previous efforts have proposed using delay information, rather than packet loss, to guide congestion control. An early example of this was the packet pair algorithm, using the delay spread from back to back packets to measure the bottleneck bandwidth through a fair-queued router [35]. Packet pair does not perform well with FIFO queues, however, as all endpoints would send at the maximum capacity of the link. Two more recent examples are TCP Vegas [10] and FastTCP [31]. The motivation in each case was to improve steady state TCP performance. As we have argued, many TCP transfers never reach steady state on today's networks.
Finally, we use many individual pieces of technology developed in other contexts. XCP was the first to show that separate mechanisms could be used to provide efficiency and eventual fairness in a congestion control algorithm [32]. In XCP, routers allocate resources to flows without keeping per-flow state. If there is idle capacity, flow rates are rapidly increased without regard to fairness; eventual fairness is provided as a background additive increase/multiplicative decrease process applied to all flows. We directly leverage their approach in our work; in fact, we initially started our effort to investigate whether we could achieve the efficiency of XCP without router support. Similarly, Jain and Dovrolis show how to efficiently measure the available bandwidth (capacity less utilization) of an Internet path, by successively probing the path with faster and faster rates until measured delays start increasing [29]. We use a version of their technique, with two principal differences. Their motivation was to measure Internet paths; ours is congestion control. Thus, we carefully meter our probe rates, to ensure that they usually succeed; Jain and Dovrolis attempt to drive the network to the point where the probe starts causing congestion. Their work is also complicated by the fact that TCP traffic is particularly bursty at short time-scales, requiring much longer measurements than in our system. By ensuring that all traffic is paced, we can use shorter and more precise probes. Finally, we note that rate pacing has been proposed as a way to speed TCP startup [42,43,28]; if the TCP congestion control variables can be measured or predicted, pacing can provide a way to smooth the initial flight of traffic. We build on this work by using rate pacing throughout the lifetime of a connection, to provide high resource utilization with low delay variance. Earlier work has shown that this form of complete rate pacing interacts poorly with TCP dynamics, by delaying the onset of congestion [1]. In our system, however, the fact that competing flows use rate pacing allows an endpoint to quickly and accurately find if there is available capacity, avoiding the need to drive the resource to overload to determine its resource limits.