Source-linked AI summary
PCC: Re-architecting Congestion Control for Consistent High Performance
Mo Dong, Qingxi Li, Doron Zarchy, Brighten Godfrey, Michael Schapira
TL;DR
TCP’s packet-level event responses perform poorly across diverse real-world conditions because they do not directly assess resulting performance. PCC instead links sending-rate actions to empirically measured utility, achieving strong performance across challenging environments and convergence to a stable, fair equilibrium.
Problem
TCP variants address specific network conditions but remain far from optimal broadly, reflecting an architecture that hardwires packet events to predefined responses.
Method
PCC aggregates packet-level outcomes into performance metrics and utility, then compares sending rates to select actions aligned with transfer objectives.
Results
PCC achieves consistent high performance across real-world environments, often exceeding specialized TCP variants by up to 45×, while converging to a stable and fair equilibrium.
Takeaways & Limitations
PCC offers a congestion-control architecture that can express objectives such as throughput and latency without router hardware or protocol changes.
Takeaways & Limitations
Real-world deployment remains an open question, particularly where PCC interacts unfriendly with TCP in the public Internet.
Abstract
from arXiv · showhide
TCP and its variants have suffered from surprisingly poor performance for decades. We argue the TCP family has little hope to achieve consistent high performance due to a fundamental architectural deficiency: hardwiring packet-level events to control responses without understanding the real performance result of its actions. We propose Performance-oriented Congestion Control (PCC), a new congestion control architecture in which each sender continuously observes the connection between its actions and empirically experienced performance, enabling it to consistently adopt actions that result in high performance. We prove that PCC converges to a stable and fair equilibrium. Across many real-world and challenging environments, PCC shows consistent and often 10x performance improvement, with better fairness and stability than TCP. PCC requires no router hardware support or new packet format.
1 Introduction
TCP’s hardwired event-to-response architecture performs poorly across complex network conditions because it cannot observe whether its control actions improve actual performance. PCC instead learns from measured performance and achieves strong results across diverse environments without router or protocol changes.
- Motivation: TCP variants address specific network conditions but can perform poorly when conditions differ from their design assumptions.The paper describes this pattern as a collection of point solutions rather than a consistently effective architecture.
- Motivation: TCP maps packet-level events such as loss to predefined control responses based on assumptions about network state.For example, TCP may interpret one packet loss as congestion and halve its congestion window.
- Motivation: Complex production networks routinely violate the assumptions embedded in TCP-like hardwired mappings, yet TCP still executes the mismatched response.The listed sources of complexity include unreliable links, changing paths, AQMs, virtualization, and middleboxes.
- PCC Architecture: PCC associates sending-rate changes with observed throughput, loss, and latency, then learns which rates produce higher utility.Its utility function can encode objectives such as high throughput and low loss.
- Evaluation: More than 10× throughput over TCP CUBIC was reported on the global commercial Internet, while other environments showed gains up to 45×.Reported comparisons include 5.23× versus TCP Illinois, 17× versus TCP Hybla, and 14× versus CUBIC on rapidly changing networks.
- Deployment: PCC can replace only TCP’s sender-side rate control and can deliver real data through a user-space implementation.The architecture does not require router hardware support or a new packet format.
2 PCC Architecture
PCC makes congestion-control decisions by experimentally linking sending rates to measured utility rather than applying fixed responses to packet events. Its architecture supports online adaptation, fairness analysis, and application-specific objectives.
- 2.1 The Key Idea: A packet loss can reflect congestion, shallow buffers, competing flows, or random non-congestion loss, so a fixed response may be inappropriate.PCC uses observed performance to decide whether to decrease, maintain, or increase its sending rate.
- 2.1 The Key Idea: PCC tests sending rates over monitor intervals and aggregates acknowledgments into throughput, loss-rate, and latency metrics.Each tested action is associated with a resulting utility derived from those metrics.
- 2.1 The Key Idea: PCC continuously compares nearby rates with an online gradient-ascent algorithm and moves toward rates with higher utility.It tests (1 + ε)r and (1 − ε)r, continuing in a direction while utility increases.
- 2.1 The Key Idea: Randomized controlled trials reduce rate variance by up to 65% while preserving a favorable stability/convergence-speed tradeoff.PCC accepts a rate as the winner only when it produces higher utility in both randomized trials.
- 2.2 Fairness and Convergence: With a suitable utility function, selfish PCC senders converge to a fair equilibrium, with all senders reaching the same stable sending rate.The analysis assumes concurrent updates and establishes convergence to a neighborhood around the unique stable state.
- 2.2 Fairness and Convergence: PCC’s utility function combines throughput and loss with a sigmoid cutoff that caps worst-case overall loss at about 5%.The cutoff makes utility negative when loss exceeds the target region.
- 2.3 Deployment: PCC can operate without resource isolation, but deployment alongside TCP may involve unfriendly interaction comparable to other selfish practices.The paper notes that the ecosystem is unlikely to become dramatically worse for TCP, based on experiments discussed later.
- 2.4 Alternate utility functions: With flow-level fair queuing, applications can select different utility functions for objectives such as latency versus throughput.This provides flexibility beyond TCP’s architecture, which is blind to application objectives.
3 Prototype Design
PCC is implemented as a user-space prototype that continuously monitors packet outcomes and uses utility comparisons to adjust sending rate. Its control algorithm progresses from startup through randomized rate-direction tests and utility-guided rate adjustment.
- Prototype: The prototype implements PCC in user space on top of the UDT TCP skeleton.Figure 2 depicts the prototype’s software components.
- Performance Monitoring Process: Each monitor interval records sent packets and uses returning SACKs to measure delivery, loss, and RTT outcomes.The monitor associates packets sent during an interval with their subsequent receiver observations.
- Performance Monitoring Process: PCC continuously transfers data while measuring performance, rather than pausing transmission to await results.Monitor intervals are sized to include at least 10 packets and typically last 1.7–2.2 RTTs.
- Control Algorithm: During startup, PCC doubles its rate until utility decreases, then returns to the previous higher-utility rate and enters decision making.Unlike TCP, packet loss alone does not end startup.
- Control Algorithm: PCC tests rates r(1 + ε) and r(1 −ε) in randomized controlled trials, increasing ε from 0.01 up to 0.05 when results remain inconclusive.The algorithm compares higher- and lower-rate utilities before selecting a direction.
- Control Algorithm: After selecting a direction, PCC accelerates rate changes and reverts to the previous rate whenever utility falls.It then returns to decision making to choose a new direction.
4 Evaluation
The evaluation examines PCC’s architectural advantages through diversified, large-scale experiments. It reports performance, fairness, stability, deployment practicality, and application-objective flexibility across varied environments.
- Evaluation Scope: PCC’s evaluation covers diversified, large-scale, real-world experiments targeting consistent high performance, fairness, and convergence stability.The evaluation explicitly frames these properties as architectural advantages over the TCP family.
- Deployment: The study also assesses practical deployment through short-flow completion time and TCP friendliness.These criteria are presented alongside the performance and fairness evaluation.
- Application Objectives: PCC is evaluated for flexible optimization of heterogeneous application objectives with fair queuing rather than more complicated active queue management.This is identified as a potential use of PCC’s utility-based design.
4.1 Consistent High Performance
Across challenging Internet, inter-data-center, satellite, and lossy-link settings, PCC uses one untuned utility function and generally outperforms specialized TCP variants. Its gains include a 5.52× median throughput improvement over CUBIC and 5.2× average improvement over TCP Illinois.
- Evaluation Setup: PCC significantly outperforms specially engineered TCP variants in the first 7 of 8 evaluated real-world challenging scenarios without algorithm tweaking.All experiments use the same “safe” utility function.
- Public Internet: The Internet experiment spans 510 sender-receiver pairs across globally distributed PlanetLab nodes, with BDP ranging from 14.3 KB to 18 MB.Receivers are deployed on 85 nodes and senders at 6 locations.
- Public Internet: 5.52× higher median throughput is achieved by PCC than TCP CUBIC; improvement exceeds 10× on 41% of pairs and reaches up to 300×.The result is described as conservative because four GENI sites had 100 Mbps Internet-uplink limits.
- Alternative Transports: PCC outperforms PCP by 4.58× at the median and 15.03× at the 90th percentile, while outperforming SABUL by 1.41× and 3.39×.The corresponding percentile pairs are median and 90th percentile, respectively.
- Alternative Transports: SABUL averages 11.5% loss versus PCC’s 3.1% loss, while PCC stably tracks the optimal rate and SABUL’s control loop overshoots and falls back.The passage connects the loss comparison with the observed stability difference.
- Inter-Data Center Environment: In dedicated inter-data-center links, PCC outperforms TCP Illinois by 5.2× on average and up to 7.5×.The experiment uses nine GENI site pairs with 800 Mbps reserved end-to-end bandwidth.
4.1.3 Satellite Links
PCC maintains high throughput on satellite links with excessive latency and random loss, outperforming specialized TCP variants under emulated real-world conditions.
- PCC reaches 90% of optimal throughput with only 7.5KB of bottleneck buffer on an 800ms RTT, 42Mbps satellite link with 0.74% random loss.
- 17×: TCP Hybla achieves 2.03Mbps with a 1MB buffer, compared with PCC under the same satellite-link conditions.
- 54×: TCP Illinois performs worse than PCC with a 1MB buffer on the emulated satellite link.
- PCC exceeds 95% of achievable capacity through 1% random loss and degrades to 74% of capacity at 2% loss.
- At 2% random loss, CUBIC is 37× smaller and Illinois is 16× smaller than PCC in throughput.
- At 6% loss, PCC falls to 3% of optimal throughput because the safe utility function caps loss rate at 5%.
4.1.7 Rapidly Changing Networks
PCC is evaluated in networks whose bandwidth, loss rate, and RTT change every five seconds, including data-center incast conditions with many concurrent senders.
- Rapidly Changing Networks: In the rapidly changing-network experiment, available bandwidth, loss rate, and RTT independently vary every five seconds.Bandwidth ranges from 10Mbps to 100Mbps, latency from 10ms to 100ms, and loss rate from 0% to 1%.
- Incast: With roughly ≥10 senders during incast, PCC achieves 60–80% of maximum possible goodput, or 7–8× TCP’s goodput.
- Incast: PCC’s incast goodput remains stable as the number of senders increases, whereas DCTCP’s goodput degrades.
- Incast: PCC achieves roughly the same 60–80% goodput as ICTCP in a similar incast environment.
4.2 Dynamic Behavior of Competing Flows
PCC flows converge fairly and stably, while parameter settings expose a stability–reactiveness trade-off that remains better than TCP’s; RCT further reduces variance.
- Dynamic Behavior: PCC is proved to converge to a fair equilibrium from any initial state and experimentally shows greater stability and fairness than TCP.
- Convergence and Fairness: PCC flows converge more stably than CUBIC, with better Jain’s-index fairness at all measured time scales.
- Stability–Reactiveness Trade-off: Higher εmin and lower Tm produce faster convergence but higher throughput variance for PCC.
- Stability–Reactiveness Trade-off: PCC with Tm = 1.0 · RTT and εmin = 0.02 achieves the same convergence time and 4.2× smaller rate variance than CUBIC.
- RCT: With Tm = 1.0 · RTT and εmin = 0.01, RCT increases convergence time by 3% while reducing rate variance by 35%.
4.3 PCC is Deployable
PCC is evaluated against selfish parallel TCP behavior and for short-flow completion time, with results indicating improved TCP friendliness and little fundamental short-flow harm.
- TCP Friendliness: A single PCC flow is more friendly to normal TCP than a selfish bundle of 10 parallel TCP flows.
- TCP Friendliness: PCC’s parameter trade-off evaluation is not a full exploration, so other settings may achieve better points.
- TCP Friendliness: PCC achieves better fairness in convergence than TCP CUBIC.
- Short-Flow Completion Time: Across 5%–75% network load, PCC achieves similar median and 95th-percentile FCT to TCP for 100KB flows.
- Short-Flow Completion Time: At 75% utilization, PCC’s 95th-percentile FCT is 20% longer than TCP.
- Short-Flow Completion Time: Fast-start optimization is outside the paper’s scope, and the authors identify room for improvement in startup algorithms.
4.4 Alternate Utility Functions with FQ
PCC uses utility functions to express different application objectives, and with fair queuing can achieve these objectives without complex AQM. Experiments show PCC maintains high power for interactive flows while avoiding the TCP–AQM trade-off.
- Alternate Utility Functions: PCC expresses heterogeneous data-transfer objectives by plugging in different utility functions.The evaluated objectives include throughput and latency.
- Latency-Sensitive Applications: 10.5× more power is achieved by FQ + CoDel than by FQ + Bufferbloat for TCP CUBIC with two simultaneous interactive flows.This experiment replicated a prior simulation result using a 40Mbps, 20ms RTT transmission pair.
- Latency-Sensitive Applications: Bufferbloat + FQ and CoDel + FQ achieve essentially the same power for interactive flows using PCC.PCC kept buffers very small and observed no packet drops, making CoDel ineffective in this setting.
- Latency-Sensitive Applications: 55% higher power is achieved by FQ + Bufferbloat + PCC than by FQ + CoDel + TCP.The result indicates that TCP remains limited in expressing application transmission objectives even with AQM.
- Scope: AQMs can improve objective expression in some settings, such as LTE, so PCC reduces rather than eliminates the need for complicated AQMs.The paper limits this conclusion to a wide range of network scenarios.
- Alternate Utility Functions: With FQ, PCC can pursue each sender’s performance goal independently, including resilience to random loss.A loss-resilient utility can theoretically tolerate random loss close to 100%.
5 Related work
Prior approaches address TCP’s information or adaptability limits through network feedback, specialized variants, or bandwidth probing, but retain deployment barriers or hardwired assumptions. PCC additionally supports different sending objectives through utility functions.
- Network Feedback: Explicit-feedback designs such as XCP and RCP require new protocols, router hardware, and packet-header formats, hindering incremental adoption.These designs directly set end-host rates using network feedback.
- TCP Variants: TCP modifications improve performance in specially assumed scenarios but degrade when their network assumptions are violated.The paper identifies this limitation across variants targeting high BDP, satellite, data-center, wireless, and lossy links.
- TCP Variants: Remy searches hardwired mappings under assumed network parameters, but performance degrades when real networks deviate from those assumptions.Real networks may also contain more parameters than Remy’s model includes.
- Bandwidth Probing: Bandwidth-probing protocols make network assumptions and do not observe real performance as PCC does.Packet inter-arrival latency assumptions can be violated by jitter and middleboxes.
- PCC’s Distinction: Unlike the cited prior work, PCC allows different sending objectives through interchangeable utility functions.This capability is identified as a distinct feature of PCC’s architecture.
6 Conclusion and Future Work
The paper presents PCC as a promising architecture for consistent high-performance congestion control. It identifies better learning algorithms, FIFO utility interactions, and real-world deployment as future work.
- Conclusion: PCC is presented as a promising architecture toward consistent high-performance congestion control.The conclusion frames this as demonstrated potential rather than a completed solution.
- Future Work: Future work includes better learning algorithms, analysis of utility-function interactions under FIFO queuing, and real-world deployment.These questions remain open beyond the paper’s current evaluation.