Congestion control performance investigation of ModQUIC protocol using JioFi network: A case study

2.1. Background

A QUIC is an experimental transport layer protocol proposed in 2012 and publicly announced in 2013 by Jim Roskind from Google [24]. As shown in Fig. 1, QUIC is a secure and multiplexed protocol with UDP as a base protocol. A QUIC support flow and congestion control using bandwidth estimation technique with reduced connection and transport latency.

OPEN IN VIEWER

Fig. 1.

QUIC placement in protocol stack.

The following are the properties of QUIC [11].

There are several congestion control techniques available [1,15,20,29] of which QUIC is available with CUBIC and BBR. Right now QUIC/CUBIC is more stable and default present in stack, whereas QUIC/BBR is still experimental.

2.2.1. CUBIC

The Ha et al. [10] proposed an enhanced version of Binary Increase Congestion-control (BIC) as a CUBIC in which they have introduced RTT independent Congestion Window ( cwnd ) growth function. Basically CUBIC is using H-TCP [19] approach to calculate cwnd size, which is a cubic function of elapsed time, t since last congestion event is given in equation (1). (1) W CUBIC = C ( t − β . W max C 3 ) 3 + W max where, W CUBIC is cwnd size, W max is a cwnd just before last window reduction, C is a predefined constant used as a scaling factor, β is a decrease factor.

Window size reduction at the time of loss event is W ( t ) = W ( t ∗ ) ∗ ( 1 − β ) , where W ( t ∗ ) is the cwnd size at the time t ∗ of packet loss i.e. W max .

OPEN IN VIEWER

Fig. 2.

Congestion window growth with respect to cubic function.

Figure 2 shows the behavior of CUBIC for cubic function, where whenever packet dropping event occurs, the cwnd is reduced by β factor. With new epoch starting at t = 0 and for initial cwnd , α is set to zero. W max is the cwnd where packet loss occurred previously. However, Equation (1) preserve properties of BIC such as RTT fairness, limited slow start, and rapid convergence. As an additional precaution CUBIC has a mechanism to ensure performance isn’t worse than standard Reno with simultaneous checking and calculation of W reno parameter. With other experimental studies, it is seen that the performance and fairness property of CUBIC is very good. Also as this is available in Linux TCP suite (kernel version 2.6.16), currently this is the most widely used congestion control algorithm.

2.2.2. BBR

Today TCP’s loss-based congestion control including QUIC’s current default scheme, CUBIC, is the primary cause of major delay in modern fast networks, especially over large distances. This is due to CUBIC interpreting packet loss as congestion, an equivalence which was more or less valid at the time of the algorithm’s conception. As the Internet speed in the modern-day transitioning from Kbps to Gbps, the equivalence of packet loss with congestion is not quite so straightforward. A bottleneck in a QUIC connection, Internet Explorer the slowest link, is the rate-determining factor for information transfer. A bottleneck often goes hand in hand with a queue formed due to arrival rate exceeding departure rate. Thus solving the problem of bottleneck will go a long way towards increasing goodput and minimizing delay during information transfer. In the current CUBIC implementation, when bottleneck buffers are large, the loss-based nature of CUBIC keeps them full, causing bufferbloat. When bottleneck buffers are small, CUBIC misinterprets loss as a signal of congestion as per its design, leading to low throughput.

To overcome these demerits of CUBIC, Google suggested distributed congestion-control protocol which reacts to actual congestion, not packet loss or transient queue delay and converges to an optimal operating point. This distributed approach to control congestion based on measuring the two parameters that characterize a path: Bottleneck-Bandwidth (BtlBw) and Round-Trip-time-propagation (RTprop) as shown in Fig. 3.

The key features of BBR are as follows:

Considers RTprop and BtlBw as constraints for transport performance.

These can be thought of as length (RTprop) and minimum diameter (BtlBw) of network pipe.

Fewer data in pipe: RTprop determines, otherwise BtlBw, BBR measures these two parameters to accurately react to congestion, not loss or queuing effects.

A connection has maximum throughput and minimum delay when

Rate Balance: Bottleneck packet arrival rate = BtlBw .

Full Pipe: Total Data in Flight = BDP = BtlBw ∗ RTprop .

OPEN IN VIEWER

Fig. 3.

BBR response with respect to delivery rate and round trip time v/s amount of data in flight [3].

In Fig. 3 constraint lines intersect at inflight = BtlBw ∗ RTprop , as good as the pipe’s Bandwidth Delay Product (BDP). Since the pipe is full before this point, the ( inflight − BDP excess ) creates a queue at the bottleneck. Certainly, packets have been dropped once exceed buffer capacity. As seen if Fig. 3 congestion is carried by right side of the BDP line. However, congestion control is a mechanism which holds the connection to operate at an average level of bandwidth limited region. A loss-based congestion control (CUBIC) operates at the right edge of the bandwidth-limited region. This provides full BtlBw at the cost of high delay and frequent packet loss. At the time when memory was quite an expensive buffer size was slightly greater than the BDP, which minimizes congestion control’s excess delay. Larger buffer sizes create bufferbloat, which converts RTT value from milliseconds to second.

Thus, CUBIC assumes loss and buffer occupancy to capture the behavior of congestion, which is not realistic. However, BBR characterize congestion based on how it occurs through RTT based BtlBw and RTprop estimation. BBR maintains small queue size and optimum network utilization through distributed control loop with the help of packet pacing and control over the sending rate.

Most of the literature on QUIC is available in the form of Internet drafts [8,11–13,17,24,27,28] proposed by researchers from Google.

As the present work is an experimental study of the QUIC protocol, this related work section, is confined only to the experimental studies that have been undertaken. Carlucci et al. [4] made a first-time experimental investigation with QUIC in which they have employed two testbeds to investigate congestion control dynamics and web PLT. They verified QUIC performance using goodput, resource utilization, and PLT. They observed with Forwarding Error Correction (FEC)1

Das [7] in his M.S. work evaluated QUIC performance in Mahimahi: a web performance measurement toolkit. He found QUIC performance was very good for low bandwidth and high RTT links. Cook et al. [6] used local and remote testbeds and tested QUIC performance in which scenario is most efficient. They have investigated QUIC performance for the type of access network in presence of packet loss and adding a delay in the link. They concluded that QUIC outperforms HTTP/2 over TCP/TLS in unstable networks such as wireless/mobile but in the case of stable and reliable networks there has been no significant contribution. Srivastava [26] in his M.Sc. thesis has been compared QUIC performance with TCP for throughput, delay, and fairness. He has found that for an added delay and loss QUIC outperform and in case of competing flows QUIC was unfair while comparing with TCP. Kakhki et al. [14] carried out extensive experimentation for a variety of network conditions. They found that QUIC outperforms TCP/HTTP in nearly every scenario, QUIC is very sensitive with out of order delivery and shows very poor performance. They found that QUIC is unfair when competing with TCP flows. In this work we have performed a comparative performance analysis of QUIC protocol concerning CUBIC and BBR congestion control mechanism. Also we have explored BBR congestion control mechanism investigation in terms of RTR and Goodput is not done in prior work.

4.1. Testbed setup with parameter space used for experiment

During experimental analysis, the main objectives are to examine the performance of ModQUIC in real network congestion for live streaming. As shown in Fig. 4, JioFi2

OPEN IN VIEWER

Fig. 4.

Testbed setup built with ModQUIC server provided as part of Chromium source code, Netem enabled Raspberry-Pi wireless router with Jio as a source with RTT of 20 ms.

To the serve-side, Google drive has been used to serve requests from the client due to the relative rarity of live ModQUIC enabled server. The Google services, such as Drive and YouTube, use ModQUIC as a native protocol, as opposed to other web servers where QUIC has limited deployment. It is also possible to build a ModQUIC server-client topology from the chromium code base as given in [23]. This implementation of a ModQUIC server has been used to test results from the laptop specified.

The Netem’s Traffic Control (Tc) was used to introduce latencies, packet loss, and packet reordering to all outgoing packets according to the parameter space in Table 1. This wireless router served the ModQUIC enabled Chromium Client4

The variation of data speeds observed through the Jio network during the experimentation process was noted using a Python script and graphically shown in Fig. 5 to reflect the real behavior.

OPEN IN VIEWER

Fig. 5.

24-hour time series analysis of Jio data rate variations.

Two parameters, RTR and Throughput has been analyzed across varying link capacity and loss for different file sizes, whereas calculated by using equations (2) and (3). (2) RTR = Number of Packets Received Number of Packets Transmitted (3) Goodput = Flie Size Downloaded Time

The performance of ModQUIC with CUBIC and BBR in presence of loss for various file sizes has been presented in Tables 2, 3 and 4. The RTR and Throughput values presented across 5 epochs for all file sizes. The values for packets transmitted, packet loss, packet received, packet retransmitted, retransmit ratio, download time and throughput is logged.

OPEN IN VIEWER

Fig. 6.

Throughput and RTR performance of ModQUIC with CUBIC and BBR for different loss rates and file sizes.

The net-internals tool is used to calculate RTR and Throughput over all permutations of the hyperspace detailed in Table 1. Figure 6 shows trend of the Throughput and packet retransmission. For small video files, BBR throughput suffers from increase in loss, as seen in Fig. 6(a). This is due to insufficient time for BBR to calculate estimates of BtlBw and RTprop and converge pre-emptively to react for congestion. In this case, loss based congestion control reacts to the loss, faster than BBR can build the model. However, as file sizes increases, BBR shows a clear improvement in throughput over CUBIC in all scenarios, as seen in Fig. 6(b). Even as the loss increases, due to an increase in convergence time BBR can accurately prevent congestion by modifying the transmission data rate. This effect is amplified for the large file size of 5 MB, where CUBIC throughput drops significantly for higher loss, whereas BBR reacts pre-emptively to prevent bufferbloat, as seen in Fig. 6(c).

The RTR analysis was relatively straightforward as the trends were consistent across all scenarios. For a given file size, as shown in Fig. 6, it is observed that there is a direct correlation between loss and RTR in all cases with an increase in loss the RTR decreases for both BBR and CUBIC. For smaller file sizes in Fig. 6(d), BBR has fewer transmissions than it does for higher file sizes as seen in Figs 6(e) and 6(f), as it has not had the convergence time necessary to correct the congestion. This behavior manifests itself in larger file sizes due to corrective measures being applied by BBR. A CUBIC shows constant behavior in its loss-based retransmission system for all file sizes, with a decrease from a higher starting RTR for the smallest file size, as seen in the Fig. 6(d).

There is a substantial improvement in BBR congestion control over CUBIC as BBR is not using loss as an indicator of congestion. To utilize the full bandwidth, currently existing loss-based congestion control schemes such as CUBIC require the loss rate to be less than the inverse square of the BDP [21]. The behavior with varying loss is examined by Google for 60-second flow on 100 Mbps/100 ms link with 0.001% to 50% of random loss serviced by HTTP/2 over TCP/IP [3]. A Google observed CUBIC’s throughput to decrease tenfold at 0.1% loss and totally stall above 1%. The maximum theoretical possible throughput for a network is the link rate times fraction delivered ( = 1 − LossRate ). Google observed BBR meet this limit asymptotically up to a 5% loss and reasonably close up to 15% loss. This performance has been verified on a live wireless 500 Kbps/20 ms link with 1% to 5% random loss serviced by QUIC protocol.