An Empirical View on Content Provider Fairness

Abstract

Congestion control is an indispensable component of transport protocols to prevent congestion collapse. As such, it distributes the available bandwidth among all competing flows, ideally in a fair manner. However, there exists a constantly evolving set of congestion control algorithms, each addressing different performance needs and providing the potential for custom parametrizations. In particular, content providers such as CDNs are known to tune TCP stacks for performance gains. In this paper, we thus empirically investigate if current Internet traffic generated by content providers still adheres to the conventional understanding of fairness. Our study compares fairness properties of testbed hosts to actual traffic of six major content providers subject to different bandwidths, RTTs, queue sizes, and queueing disciplines in a home-user setting. We find that some employed congestion control algorithms lead to significantly asymmetric bandwidth shares, however, AQMs such as FQ_CoDel are able to alleviate such unfairness.

DiffPerf: Towards Performance Differentiation and Optimization with SDN Implementation

“…As demonstrated by our experiments (and also other works, e.g., [50]) CUBIC exhibits such behavior, and so does BBR [20], [51]. This unfairness in achieved throughput worsens when flows with different CC algorithms compete [22]. Another interesting observation from literature is that the relative performance degradation in throughput can be due to more than the single factor of RTT, particularly with the introduction of 5G and FTTH technologies that result in a much higher load of heterogeneous traffic.…”

“…This can adversely affect the QoE that the corresponding user perceives, particularly if x f is less than the lowest bitrate requested by the video player in case of ABR video streaming. At the last-mile bottleneck, parameters such as RTT, TCP congestion control algorithm (e.g., CUBIC v/s BBR), and buffer size affect the performance of flows [20], [21], [22]. The heterogeneity of RTTs experienced by the flows as well as the interaction of the TCP-based congestion control mechanisms that respond to the RTTs and network buffer size differently, lead to multiple competing flows achieving different throughput.…”

Video Conferencing and Flow-Rate Fairness: A First Look at Zoom and the Impact of Flow-Queuing AQM

“…Equality Metric. We measure flow-rate equality using the metric of our prior work [25]. In contrast to, e.g., Jain's fairness index [19], this metric shows which flow over-utilizes the bottleneck by how much.…”

“…In the center, one machine serves as the configurable bottleneck link over which Zoom Client 1 (ZC 1) connects to the Zoom backend to Shaping the Bottleneck. We configure our bottleneck using Linux's traffic control (TC) subsystem similar to [25] to create network settings with different bandwidths, delays, queue sizes, and queue management mechanisms. For ratelimiting, we use token bucket filters with a bucket size of one MTU (to minimize bursts) on the egress queues in both directions.…”

Debugging QUIC and HTTP/3 with qlog and qvis

“…Even after decades of evolution, congestion control approaches (CCs) are still a topic of active research and innovation [13,85]. Bugs are still being found (e.g., Google found a decade-old bug in the Cubic CC when implementing QUIC [49]), CCs are still being fine tuned [70] and new CCs are being developed (e.g., COPA, BBRv2 [14,20]). This is only expected to continue and even increase with QUIC, which is more open to experimentation than TCP due to its user-space implementations [49].…”