To be feasible to deploy, PCP must be able to share network resources with existing TCP connections. Naively, as TCP increases its window size, queues will build up, and any PCP endpoints will reduce their sending rate to compensate. The TCP host will proceed unimpeded, continuing to increase its window size, causing further rate reductions from the PCP hosts.
We do not believe it is essential for PCP to be strictly fair with respect to TCP hosts, since that might well require simulating TCP's precise semantics. Rather, our goal is for PCP to be incentive compatible when sharing resources with TCP, so that it outperforms TCP while avoiding starvation for TCP hosts. Since PCP does much better than TCP for the common case of short to moderate transfers, there is substantial room for PCP to outperform TCP without needing to actively penalize TCP senders.
Our design walks this delicate balancing act. First, we recognize when a bottleneck is being shared with TCP, by observing when PCP's rate compensation is ineffective at reducing the queue size over several consecutive round trips. Normally PCP would continue to decrease its rate in the hope of eliminating the queue, but instead we apply a ``tit for tat'' rule, decreasing the rate compensation by a factor of ten for as long as rate compensation is ineffective. While this might seem counter-intuitive - increasing aggressiveness precisely at the point when congestion is building - ``tit for tat'' is needed to counter TCP's overly aggressive behavior. Eventually, the TCP connection will over-drive the link, causing loss and backoff for the TCP sender; PCP can then increase its rate during these periods. Our measurements and simulation results indicate that the TCP backoff and reduced PCP rate compensation balance out in most cases. When the TCP flow completes, any remaining PCP flows will find that rate compensation again becomes effective, enabling them to revert to their normal behavior.
In all other respects, PCP is backwardly compatible with legacy TCP hosts. We re-use the TCP packet header, indicating whether PCP should be used as an option in the TCP SYN packet. If the PCP receiver acknowledges the option, the sender uses PCP; otherwise we use traditional TCP congestion control.
There is no fundamental reason we cannot design a PCP sender to interoperate with an unmodified TCP receiver. The principal difference between a PCP and a TCP receiver are in the precise semantics of timestamps and delayed acknowledgments. TCP timestamps are similar in theory to those used in PCP to measure one-way delay, but the TCP specification is tightly bound to the TCP retransmit timer logic. The TCP timestamp reflects the time that the data being acknowledged was received, not the time that the packet causing the acknowledgment was received. Instead, we plan to use round trip measurements to approximate one-way delay when interoperating with a TCP receiver. Similarly, PCP assumes that delayed acknowledgments are turned off; a PCP sender can disable the receiver's delayed acknowledgment logic by simply reordering every other packet or by sending all probe packets as doublets.
An interesting, and future, research question is whether we can design a PCP receiver to induce a TCP sender to use PCP congestion control. Savage et al. [49] have shown that a malicious receiver can abuse a sender's TCP control logic to cause it to send at an arbitrary rate; we believe we can leverage those ideas for inducing PCP compatibility with legacy TCP senders.