Delay sensitive applications require not only congestion control but also minimization of queuing delays to provide interactivity.
This paper considers the case of real-time communication between web browsers (WebRTC) and we focus on 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.
For an increasingly important class of Internet applications – such as video conference and personalized live streaming – high delay, rather than limited bandwidth, is the main obstacle to improved performance. A common problem that impacts this class of applications is “bufferbloat”, where excess buffering in the network causes high latency and jitter. Solutions for persistently full buffer problems, 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 is not widely or consistently configured and enabled in routers and sometimes directly unavailable.
A recent focus on bufferbloat has brought a number of new AQM proposals, including PIE and CoDel, which explicitly control the queuing delay and have no knobs for operators, users or implementers to adjust. This paper considers the interplay between some of these AQM protocols and the new end-to-end delay-based congestion control algorithm, Google Congestion Control (GCC) part of the WebRTC framework.
The Figure above shows an essential view of the experimental testbed employed to evaluate the interaction. A WebRTC and a TCP sender on Node 1 and a WebRTC and a TCP receiver on Node 2. The bottleneck link buffer is governed by different queuing discipline with the goal of assessing the performance of the interaction between the end-to-end GCC algorithm and queuing discipline algorithm. Performances are 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.
| Algorithm | Parameter | Value |
|---|---|---|
| DropTail (DT/300) | queue size | 300 ms |
| PIE | tupdate | 30 ms |
| ttarget | 20 ms | |
| limit | 1000 pkts | |
| Codel | interval | 100 ms |
| target | 13 ms at 1 Mbps, 5 ms otherwise | |
| limit | 1000 pkts | |
| SFQ (DT/300) | queue size | 300 ms |
| FQ Codel | interval | 100 ms |
| target | 13 ms | |
| limit | 10240 pkts |
Delay sensitive applications require not only congestion control but also minimization of queuing delays to provide interactivity.
This paper considers the case of real-time communication between web browsers (WebRTC) and we focus on 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.
For an increasingly important class of Internet applications – such as video conference and personalized live streaming – high delay, rather than limited bandwidth, is the main obstacle to improved performance. A common problem that impacts this class of applications is “bufferbloat”, where excess buffering in the network causes high latency and jitter. Solutions for persistently full buffer problems, 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 is not widely or consistently configured and enabled in routers and sometimes directly unavailable.
A recent focus on bufferbloat has brought a number of new AQM proposals, including PIE and CoDel, which explicitly control the queuing delay and have no knobs for operators, users or implementers to adjust. This paper considers the interplay between some of these AQM protocols and the new end-to-end delay-based congestion control algorithm, Google Congestion Control (GCC) part of the WebRTC framework.
The Figure above shows an essential view of the experimental testbed employed to evaluate the interaction. A WebRTC and a TCP sender on Node 1 and a WebRTC and a TCP receiver on Node 2. The bottleneck link buffer is governed by different queuing discipline with the goal of assessing the performance of the interaction between the end-to-end GCC algorithm and queuing discipline algorithm. Performances are 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.
| Algorithm | Parameter | Value |
|---|---|---|
| DropTail (DT/300) | queue size | 300 ms |
| PIE | tupdate | 30 ms |
| ttarget | 20 ms | |
| limit | 1000 pkts | |
| Codel | interval | 100 ms |
| target | 13 ms at 1 Mbps, 5 ms otherwise | |
| limit | 1000 pkts | |
| SFQ (DT/300) | queue size | 300 ms |
| FQ Codel | interval | 100 ms |
| target | 13 ms | |
| limit | 10240 pkts |