Low Delay Transport Protocols

The Bufferbloat Problem

Bufferbloat is a pervasive issue in modern networks: routers and switches maintain excessively large packet buffers to handle burst traffic, but this approach dramatically increases latency during congestion. Instead of dropping packets early (which would signal congestion to the sender), these devices queue packets indefinitely, leading to:

Increased latency (100ms+ on broadband, 500ms+ on satellite)
Unfair resource allocation (aggressive flows starve gentle flows)
Poor real-time communication quality (video conferencing lag, gaming jitter)
Reduced TCP responsiveness (congestion signal delayed)

Motivation

High delay, rather than limited bandwidth, is the main obstacle to improved performance for an increasingly important class of Internet applications – such as video conferences and personalized live streaming. A common problem impacting this class of applications is "buffer bloat", where excess buffering in the network causes high latency and jitter. Solutions for persistently full buffer problems and active queue management (AQM) schemes such as the original RED, have been known for two decades. Yet, while RED is simple and effective at reducing persistent queues, it is not widely or consistently configured and enabled in routers and is sometimes directly unavailable.

Focus on buffer bloat has brought several new AQM proposals, including PIE and CoDel, which explicitly control queuing delay and have no knobs for operators, users, or implementers to adjust. This research work considers the interplay between some of these AQM protocols and a new end-to-end delay-based congestion control algorithm, Google Congestion Control (GCC), part of the WebRTC framework.

Testbed

A TCP sender and WebRTC/GCC sender on the left, and a WebRTC/GCC receiver and TCP receiver on the right. The bottleneck link buffer is governed by different queuing disciplines to assess the interaction performance between the end-to-end GCC algorithm and the queuing discipline algorithm. Performance is assessed in terms of metrics such as packet loss ratio, average bitrate, and queuing delay, which are known to be well correlated with QoE metrics.

Testbed Example: Set a Capacity Constraint on Incoming Traffic

Example of how to use the testbed (available on GitHub):

IP address of sender machine: 192.168.0.10
Bottleneck buffer size in KB (1000 bytes): 30 (30KB)
Device interface that receives traffic: eth0
Capacity constraint: 125 KBps (equivalent to 1Mbps)

./wan_emulation.sh tc_ingress 192.168.0.10 30 eth0 125

(Wan-Emulation-TC-and-Netem on GitHub)

We investigate how the performance of real-time video flows is impacted by the interaction of the GCC congestion control algorithm employed at the endpoints, and several queuing disciplines employed at the bottleneck queue.

Results Summary

In a nutshell, our analysis has shown that, if only real-time video traffic is considered, end-to-end congestion control can contain queuing delay with zero losses. On the other hand, PIE and CoDel provide the same queuing delay as DropTail but with the drawback of introducing packet losses. When concurrent TCP traffic is considered, both PIE and CoDel can effectively reduce queuing delays compared to DropTail, but they provoke packet losses on the video flow that increase with the number of TCP flows.

Moreover, we show that flow queuing schedulers offer a better solution since they provide flow isolation. The best interplay is obtained with SFQ, which achieves the best performance in terms of queuing delay and packet losses.

References

Following paper contains details on research considering the case of real-time communication between web browsers (WebRTC) and the interplay of an end-to-end delay-based congestion control algorithm with delay-based AQM algorithms, namely CoDel and PIE, and flow queuing schedulers, i.e. SFQ and Fq_Codel:

G. Carlucci, L. De Cicco, S. Mascolo — Controlling Queuing Delays for Real-Time Communication: Interplay of E2E and AQM Algorithms — ACM SIGCOMM Computer Communication Review, July 2016 (see also the ACM SIGCOMM Newsletter announcement)