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

Abstract

Quick UDP Internet (QUIC) protocol is a transport and application layer solution developed by Google, which is the strong competitor to popular and well established Transmission Control Protocol (TCP). The QUIC protocol is being updated faster resulting into many new versions of the protocol. In this paper, the performance of Modified QUIC (ModQUIC) protocol has been tested with respect to congestion control using India’s rapidly growing Internet service provider, the Reliance Jio 4G network (JioFi), which has captured 17% of the market share in a short time. This experimental study investigated ModQUIC protocol performance with congestion control mechanisms CUBIC and Bottleneck Bandwidth Round-trip-propagation-time (BBR) in the JioFi network. The experiment is conducted using a testbed, developed with JioFi and RaspberryPi-3 wireless router along with network emulator: Netem. The ModQUIC performance is verified using test video files stored on Google drive. The performance is tested in packet loss and packet reorder situations using metrics, Throughput and Retransmission Ratio (RTR). We observed that overall ModQUIC/BBR performance is better than ModQUIC/CUBIC in the current Internet. We observed that Reliance Jio is an economical solution for highly populated countries like India, but not a contemporary solution to fulfill India’s newly launched digitization project.

Keywords

Congestion control QUIC ModQUIC protocol technology JioFi high-speed networks transport layer

1. Introduction

The Quick UDP Internet Connections (QUIC) protocol is a transport and application layer protocol proposed by Google in 2013, which preserves most of the TCP properties. As shown in Fig. 1, QUIC is placed on top of UDP. The development of QUIC is very fast and at the present stage QUIC version 43 is at our service. The QUIC has been deployed by reputed companies such as Google and Akamai, whereas other companies like Microsoft, Mozilla, Verizon, and Facebook are in the process of deployment. The developer of QUIC is Google which has the highest deployment. Google has reported that 85% of requests go from Chrome browsers using QUIC to Google servers [14]. A QUIC is widely deployed and currently accounts for approximately 30% of aggregate traffic through Google services like YouTube, Google Cloud and Google Market and approximately equal to 7% of global Internet traffic [18,25]. According to Google-report QUIC improved Page Load Time (PLT) by 3% and reduced buffering time on YouTube by 18%. Other researchers also evaluated QUIC performance but due to limited investigation and testing environment, they fail to provide comprehensive root cause analysis to understand the performance [5,18]. Recently, the Government of India promoted the digitization of government services. This demands an improvement of online infrastructure and Internet connectivity to empower India digitally. Reliance Jio has brought digital empowerment to all Indians through connectivity with affordable data. The Reliance Jio has captured 16.02% of the market share of subscribers for a total of 160.09 million subscribers, as of now [9].

In this experimental study, the performance has been evaluated using emulated network conditions, against servers those run by Google using the current version of QUIC. The ModQUIC performance is tested with CUBIC and Bottleneck Bandwidth Round-trip-propagation-time (BBR) congestion control mechanisms for Throughput and packet Retransmission Ratio (RTR) and following are the key findings noticed through this experimental study.

For small file size ModQUIC/BBR Throughput suffers with increase in loss. This is due to insufficient time for BBR to calculate estimates of Bottleneck Bandwidth (BtlBw) and Round Trip propagation (RTprop) and converge to preemptively react to congestion.

For large file sizes with higher loss, ModQUIC/CUBIC Throughput drops significantly. This is because that CUBIC is loss-based congestion control and queue buildup creates bufferbloat.

In the case of packet retransmission; with an increase in loss the retransmission ratio decreases for both BBR and CUBIC. For smaller file sizes, BBR has fewer transmissions than it does for higher file sizes. This is because it has not had the convergence time necessary to correct the congestion.

In the case of Reliance Jio it is observed that this is an economical solution but not sufficient to fulfill the current nation needs in terms of bandwidth.

2. QUIC: Background with congestion control and related work

This section provide background information about QUIC and a short survey on experimental work related to this 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.

Fig. 1.

QUIC placement in protocol stack.

The following are the properties of QUIC [11].

Multiplexed streaming: QUIC multiplex different streams over the same UDP connection, this solves Head Of Line (HOL) blocking as the impact of the lost packet for that specific stream.

Less connection establishment latency: The time taken to set-up connection by QUIC is at most one Round Trip Time (RTT) and if in case the client has already communicated with the server, it takes zero-RTT. This reduces connection establishment latency as compared to traditional TCP. Even in an authentic and secure connection, QUIC (QUIC-Crypto) will take one-RTT whereas TCP+TLS needs three-RTTs.

Authenticated and encrypted header and the payload: To secure data delivery in terms of avoiding third-party manipulation, QUIC packets are authenticated and payload part is encrypted. However, if the payload is partially encrypted, it still gets authenticated by the receiver.

Stream and connection flow control: QUIC consists of connection level (like TCP) and stream level (within connection different streams are present) flow control mechanism. Based on QUIC receiver capacity it will advertise the absolute bytes of data within each stream or connection (aggregate stream data). As data is sent and received successfully on a particular connection or stream, the receiver requests for window updates to increase the sending rate in terms of a number of packets. Like TCP, QUIC also has auto-tuning functionality which is helpful for flow control as per application demand.

Flexible congestion control: QUIC has flexible congestion control mechanism in terms of pluggable congestion control. Also, both original and retransmitted packets carry different sequence numbers. As their recognition is easy, QUIC can provide richer information to congestion control algorithms compare to TCP. At present QUIC uses CUBIC [10,30] as a default congestion control with packet pacing mechanism. The packet pacing mechanism is useful to handle busty data. In packet pacing technique transmission rate is computed based on an estimate of the relative forward delay. Relative forward delay defined as the difference between the inter-arrival time of two consecutive data packets at the receiver and the inter-departure time of the same packets at the sender. In QUIC, ACK frame support up to 256, Not an ACK (NACK) (duplicate ACK in TCP) ranges, so QUIC withstand more effectively in reordering situation than TCP with Selective-ACK (SACK).

Connection migration: QUIC connections are identified by a 64 bit connection ID (instead of four-tuple in TCP), randomly generated by the client. QUIC connection ID remains same throughout communication time so that it can survive for IP address changes and Network Address Translation (NAT) re-bindings. Also, the same session key is used so that automatic authentication and cryptographic verification of migrating client is possible.

2.2. Congestion control mechanism

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). $\begin{matrix} (1) & W_{CUBIC} = C {(t - \sqrt[3]{\frac{β . W_{\max}}{C}})}^{3} + W_{\max} \end{matrix}$ 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}$ .

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$ .

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.

2.3. Related work

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

¹
In 2016 FEC functionality is removed from QUIC due to lack of significant contribution.

QUIC performance was very poor. Also, they observed QUIC performance is poor in loss with multiple objects situation. Megyesi et al. [22] and Biswal [2] tested QUIC performance in an emulated environment with QUIC enabled desktop client and Google server. They both observed TCP/HTTP outperform QUIC for high BDP and more number of large objects, but there were controversial comments with each other in presence of packet loss.

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.

3. ModQUIC protocol

ModQUIC is our contribution to improved network performance in terms of throughput and delay [20]. ModQUIC is a transport layer solution to improve network performance by reducing control overhead and window update delay. In ModQUIC, the window update frame is attached with the ACK frame instead of being sent separately. This modification avoids the control signal required to trigger window update, which helps in reducing transport latency along with fine-tuning of $cwnd$ growth with every ACK, resulting in smooth variation in $cwnd$ growth, which prevents consecutive packet dropping and consequently reduces timeout events. This results in improvement in throughput and reduction in transport latency.

4. Experimentation and result analysis

To verify the performance of the ModQUIC protocol a testbed setup shown in Fig. 4 has been prepared in a public domain and the performance is tested for parameter space given in Table 1. The BBR functionality is enabled by modifying the flag bit in the Chromium source code available at chromium/src/net/quic/core/quic_flags_list.h. The default status of this flag is set to false enables CUBIC as the default congestion control mechanism. Video files were uploaded on Google drive with sizes of 1 MB, 3 MB, and 5 MB. The net-internals tool of Chromium was used to monitor all network activities. This tool records network parameters like protocol used, packets sent, packets lost, packets received, throughput for all live connections serviced by ModQUIC.

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

²
WAN: LTE (2300/1800/850 MHz) IEEE 802.11b/g/n 2.4 G.

is used as an Internet Service Provider (ISP), whereas wireless router has been prepared with network emulator (Netem) enabled Raspberry Pi-3 board. A MacBook Pro laptop running chromium-browser built from source is used to carry out measurements.3

Intel Core i5 CPU @ 2.5 GHz with 4 GB RAM running MacOS Sierra 10.12.6 (64 bit) and Chromium version was 63.0.3229.0 (64 bit), whereas Darwin kernel version was 16.7.0.

The following tools and packages were used to set up the testbed:

Raspberry Pi-3 running Ubuntu MATE with Netem installed,

The dnsmasq and hostapd packages for DHCP allocation of incoming WLAN,

NAT input forwarding to WLAN for wireless broadcast.

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

⁴

Intel Core i5 CPU @ 2.5 GHz with 4 GB RAM running MacOS Sierra 10.12.6 (64 bit). A Chromium version is 63.0.3229.0 (64 bit) and Darwin kernel version is 16.7.0

from a Google drive storing video files of different sizes, as seen in Table 1.

Table 1

Parameter hyperspace used for experiment

Category	Parameter	Values
Server Side (Google Drive)	File Size	1 MB, 3 MB, 5 MB
Netem Router (Network)	Link Capacity	500 Kbit
	Loss	0%, 2%, 5%
	RTT	20 ms
	Packet Reorder	10%, 25% correlation

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.

Fig. 5.

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

4.2. Result analysis

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). $\begin{array}{l} (2) & RTR = \frac{Number of Packets Received}{Number of Packets Transmitted} \\ (3) & Goodput = \frac{Flie Size}{Downloaded Time} \end{array}$

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.

Table 2
Throughput and RTR performance of ModQUIC with CUBIC and BBR for 0% loss

BBR (0% Loss) CUBIC (0% Loss)

File Size Pkt¹ Tx² Pkt Loss Pkt Rx³ Pkt RTx⁴ RTR Time (s) Throughput (MB/s) File Size Pkt Tx Pkt Loss Pkt Rx Pkt RTx RTR Time (s) Throughput (MB/s)

1 MB 561 0 860 299 1.533 18.6 0.0538 1 MB 478 0 824 346 1.724 24.6 0.0406

510 0 826 316 1.630 18.4 0.0543 480 0 834 354 1.737 18.5 0.0540

549 0 846 297 1.541 34.7 0.0288 524 1 820 296 1.565 29.7 0.0336

555 0 837 282 1.508 18.6 0.0537 466 0 818 352 1.755 18.7 0.0534

537 0 839 302 1.562 17.7 0.0565 520 0 837 317 1.609 18.5 0.0540

Avg 542.4 0 841.6 299.2 1.552 21.6 0.0463 Avg 493.6 0.2 826.6 333 1.674 22 0.0454

3 MB 1688 0 2678 990 1.586 73.4 0.0436 3 MB 1629 0 2691 1062 1.651 65 0.0492

1607 0 2639 1032 1.642 59.2 0.0540 1704 1 2619 915 1.537 117.7 0.0271

1574 0 2625 1051 1.668 57.7 0.0554 1670 0 2619 949 1.568 67 0.0477

1613 0 2609 996 1.617 61.5 0.0520 1625 0 2641 1016 1.625 64.7 0.0494

1609 1 2649 1040 1.646 65.7 0.0487 1495 0 2588 1093 1.731 60.8 0.0526

Avg 1618.2 0.2 2640 1021.8 1.631 63.5 0.0503 Avg 1624.6 0.2 2631.6 1007 1.619 75.04 0.0426

5 MB 2605 0 4445 1840 1.706 103.7 0.0530 5 MB 2677 0 4446 1769 1.660 109.4 0.0502

2752 0 4508 1756 1.638 101.6 0.0541 2723 0 4478 1755 1.644 105.8 0.0519

2837 0 4487 1650 1.581 103.4 0.0532 2719 0 4489 1770 1.651 124.1 0.0443

2814 1 4460 1646 1.585 108 0.0509 2720 0 4487 1767 1.649 106.1 0.0518

2820 0 4491 1671 1.592 107.6 0.0511 2785 0 4471 1686 1.605 109 0.0504

Avg 2765.6 0.2 4478.2 1712.6 1.619 104.9 0.0524 Avg 2724.8 0 4474.2 1749.4 1.642 110.8 0.0496

BBR (0% Loss)	CUBIC (0% Loss)
1 MB	561	0	860	299	1.533	18.6	0.0538	1 MB	478	0	824	346	1.724	24.6	0.0406
510	0	826	316	1.630	18.4	0.0543	480	0	834	354	1.737	18.5	0.0540
549	0	846	297	1.541	34.7	0.0288	524	1	820	296	1.565	29.7	0.0336
555	0	837	282	1.508	18.6	0.0537	466	0	818	352	1.755	18.7	0.0534
537	0	839	302	1.562	17.7	0.0565	520	0	837	317	1.609	18.5	0.0540
Avg	542.4	0	841.6	299.2	1.552	21.6	0.0463	Avg	493.6	0.2	826.6	333	1.674	22	0.0454
3 MB	1688	0	2678	990	1.586	73.4	0.0436	3 MB	1629	0	2691	1062	1.651	65	0.0492
1607	0	2639	1032	1.642	59.2	0.0540	1704	1	2619	915	1.537	117.7	0.0271
1574	0	2625	1051	1.668	57.7	0.0554	1670	0	2619	949	1.568	67	0.0477
1613	0	2609	996	1.617	61.5	0.0520	1625	0	2641	1016	1.625	64.7	0.0494
1609	1	2649	1040	1.646	65.7	0.0487	1495	0	2588	1093	1.731	60.8	0.0526
Avg	1618.2	0.2	2640	1021.8	1.631	63.5	0.0503	Avg	1624.6	0.2	2631.6	1007	1.619	75.04	0.0426
5 MB	2605	0	4445	1840	1.706	103.7	0.0530	5 MB	2677	0	4446	1769	1.660	109.4	0.0502
2752	0	4508	1756	1.638	101.6	0.0541	2723	0	4478	1755	1.644	105.8	0.0519
2837	0	4487	1650	1.581	103.4	0.0532	2719	0	4489	1770	1.651	124.1	0.0443
2814	1	4460	1646	1.585	108	0.0509	2720	0	4487	1767	1.649	106.1	0.0518
2820	0	4491	1671	1.592	107.6	0.0511	2785	0	4471	1686	1.605	109	0.0504
Avg	2765.6	0.2	4478.2	1712.6	1.619	104.9	0.0524	Avg	2724.8	0	4474.2	1749.4	1.642	110.8	0.0496

Table 3

Throughput and RTR performance of ModQUIC with CUBIC and BBR for 2% loss

BBR (2% Loss)								CUBIC (2% Loss)

File Size	Pkt¹ Tx²	Pkt Loss	Pkt Rx³	Pkt RTx⁴	RTR	Time (s)	Throughput (MB/s)	File Size	Pkt Tx	Pkt Loss	Pkt Rx	Pkt RTx	RTR	Time (s)	Throughput (MB/s)
1 MB	570	1	854	284	1.498	27.2	0.0367	1 MB	600	0	829	229	1.382	38.9	0.0257
	571	0	851	280	1.490	18.6	0.0537		577	0	836	259	1.448	21.3	0.0469
	588	0	859	271	1.460	18.8	0.0531		536	0	820	284	1.529	19.9	0.0502
	626	0	901	275	1.439	20.9	0.047		555	0	844	289	1.520	20.9	0.0478
	530	0	831	301	1.567	18.3	0.0546		539	0	831	292	1.541	19.6	0.0510
Avg	577	0.2	859.2	282.2	1.489	20.76	0.0481	Avg	561.4	0	832	270.6	1.482	24.12	0.0414
3 MB	1583	1	2612	1029	1.650	64.8	0.0493	3 MB	1721	0	2625	904	1.525	69.4	0.0461
	1661	0	2616	955	1.575	61.1	0.0523		1648	0	2608	960	1.582	61.3	0.0523
	1749	0	2628	879	1.502	87.6	0.0365		1656	0	2593	937	1.565	61.1	0.0523
	1649	0	2615	966	1.585	61.5	0.0520		1629	0	2606	977	1.600	58.0	0.0551
	1618	0	2609	991	1.612	61.1	0.0523		1678	0	2615	937	1.558	62.0	0.0516
Avg	1652	0.2	2616	964	1.583	67.22	0.0476	Avg	1666.4	0	2609.4	943	1.565	62.3	0.0513
5 MB	2945	1	4643	1698	1.576	115.2	0.0477	5 MB	2717	0	4436	1719	1.632	102.7	0.0535
	3071	1	4802	1731	1.563	137.3	0.0407		2896	0	4491	1595	1.550	115.3	0.0477
	3004	0	4696	1692	1.563	120.2	0.0407		2804	0	4461	1657	1.591	114.4	0.0480
	3005	0	4521	1516	1.504	135.1	0.0407		2979	0	4588	1559	1.523	138.7	138.7
	2916	0	4491	1575	1.540	110.1	0.0499		2756	0	4466	1710	1.620	105.6	0.0520
Avg	2988.2	0.4	4630.6	1642.4	1.550	123.6	0.0445	Avg	2830.4	0	4478.4	1648	1.582	115.3	0.0476

Table 4

Throughput and RTR performance of ModQUIC with CUBIC and BBR for 5% loss

BBR (5% Loss)								CUBIC (5% Loss)

File Size	Pkt¹ Tx²	Pkt Loss	Pkt Rx³	Pkt RTx⁴	RTR	Time (s)	Throughput (MB/s)	File Size	Pkt Tx	Pkt Loss	Pkt Rx	Pkt RTx	RTR	Time (s)	Throughput (MB/s)
1 MB	609	0	859	250	1.410	21.0	0.0476	1 MB	578	0	836	258	1.446	19.4	0.0515
	551	0	819	268	1.486	20.5	0.0487		570	0	837	267	1.485	19.0	0.0502
	571	0	828	257	1.450	21.7	0.0460		562	0	835	273	1.485	19.0	0.026
	703	0	962	259	1.368	37.4	0.0267		619	0	845	226	1.365	22.7	0.044
	604	0	852	248	1.410	19.3	0.0518		555	0	820	265	1.477	19.3	0.0518
Avg	608	0	864	256.4	1.422	23.98	0.0417	Avg	576.8	0	834.6	257.8	1.446	20.1	0.0498
3 MB	1773	0	2641	868	1.489	63.4	0.050	3 MB	1875	0	2652	777	1.414	73.5	0.0435
	1834	0	2615	781	1.425	67.2	0.0476		1852	0	2626	774	1.417	79.4	0.0403
	1875	0	2705	830	1.442	66.5	0.0481		1836	0	2622	786	1.428	72.7	0.0440
	1724	0	2637	913	1.529	63.8	0.0501		1966	0	2620	654	1.332	102	0.0313
	1732	0	2616	884	1.510	61.8	0.0517		1982	0	2622	640	1.322	82.1	0.0389
Avg	1788	0	2642.8	855.2	1.478	64.54	0.0495	Avg	1902.2	0	2628.4	726.2	1.381	81.94	0.0390
5 MB	3019	0	4465	1446	1.479	129.3	0.0425	5 MB	3306	0	4481	1175	1.355	160.4	0.0342
	3046	0	4445	1399	1.459	115	0.0478		3482	0	4529	1047	1.300	175.7	0.0313
	2889	0	4452	1563	1.541	104.3	0.0527		3319	1	4459	1140	1.343	281.9	0.0237
	3038	0	4493	1455	1.478	109.8	0.0500		3224	0	4507	1283	1.398	145.7	0.0387
	2822	0	4426	1604	1.568	102.1	0.0538		3262	0	4485	1223	1.374	142.1	0.0387
Avg	2963	0	4456.2	1493.2	1.504	112.1	0.0490	Avg	3318	0.2	4492	1173.6	1.353	171.2	0.0321

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.

5. Conclusion

As the experimental analysis was carried out in a wireless environment, it realizes that packet loss becomes an incredibly significant measure of importance for the quality of a connection. The FEC feature would aid in minimizing local loss due to bit error. However, due to inconclusive results as to its efficiency [17], the FEC functionality of QUIC was removed from Chromium by Google in 2016. This is the reason that focus has shifted to a more efficient congestion control to correct losses, as is reflected in our attempts to analyze BBR. The result analysis shows a clear advantage in terms of Throughput and as verified by RTR for BBR over CUBIC in situations of congestion in live wireless networks. This study recommends the use of BBR in ModQUIC as a measure, to more accurately model and predict congestion in middleboxes as opposed to reacting to packet loss, once there is a buffer overflow. However, there were limitations in JioFi, like limited data rate else the results would have been far better as reported here.

References

Afanasyev,

Tilley,

Reiher and

Kleinrock, Host-to-host congestion control for TCP, IEEE Communications Surveys & Tutorials 12(3) (2010), 304–342. doi:10.1109/SURV.2010.042710.00114.

Biswal and

Gnawali, Does QUIC make the web faster?, in: Global Communications Conference (GLOBECOM), 2016, pp. 1–6.

Cardwell,

Cheng,

Yeganeh and

Jacobson, BBR Congestion Control, 2017 Working Draft, IETF Secretariat, Internet-Draft draftcardwell-iccrg-bbr-congestion-control-00.

Carlucci,

De Cicco and

Mascolo, HTTP over UDP: An experimental investigation of QUIC, Annual ACM Symposium on Applied Computing 30 (2015), 609–614. doi:10.1145/2695664.2695706.

Chromium Blog, A QUIC Update on Google’s Experimental Transport, 2015.

Cook,

Mathieu,

Truong and

Hamchaoui, Quic: Better for what and for whom?, in: IEEE International Conference on Communications (ICC), 2017, pp. 1–6.

Das, Evaluation of QUIC on Web Page Performance, 2014, Ph.D. Dissertation Report, Massachusetts Institute of Technology.

Gizis, Taking Google’s QUIC for a Test Drive, 2016.

Gupta and

Mukherjee, The empirical study on the impact of social media marketing on brand loyalty: Case study of reliance Jio Infocomm Limited (with reference to silchar region), International Journal of Recent Advances in Information Technology & Management 2(1) (2018).

10.

Ha,

Rhee and

Xu, Cubic: A new TCP-friendly high-speed TCP variant, ACM SIGOPS Operating Systems Review 42(5) (2008), 64–74.

11.

Hamilton,

Iyengar,

Swett and

Wilk, QUIC: A UDP Based Secure and Reliable Transport for HTTP/2, 2016, IETF, draft-tsvwg-quicprotocol-02.

12.

Iyengar, QUIC: Redefining Internet Transport, 2016.

13.

Iyengar and

Thomson, Quic: A UDP-based Multiplexed and Secure Transport, 2017, draft-ietf-quic-transport-01.

14.

Kakhki,

Jero,

Choffnes,

Nita-Rotaru and

Mislove, Taking a long look at QUIC: An approach for rigorous evaluation of rapidly evolving transport protocols, in: ACM Internet Measurement Conference, 2017, pp. 290–303.

15.

Kharat and

Kulkarni, Congestion controlling schemes for high-speed data networks: A survey, Journal of High Speed Networks 25 (2019), 41–60. doi:10.3233/JHS-190602.

16.

Kharat and

Kulkarni, Modified QUIC protocol for improved network performance and comparison with QUIC and TCP, International Journal of Internet Protocol Technology 12(1) (2019), 35–43. doi:10.1504/IJIPT.2019.098489.

17.

Langley and

Chang, Quic Crypto, 2013.

18.

Langley,

Riddoch,

Wilk,

Vicente,

Krasic,

Zhang,

Yang,

Kouranov,

Swett and

Iyengar, The QUIC transport protocol: Design and Internet-scale deployment, in: ACM Conference on Special Interest Group on Data Communication, 2017, pp. 183–196. doi:10.1145/3098822.3098842.

19.

Leith and

Shorten, H-TCP: TCP for high-speed and long-distance networks, in: Proceedings of PFLDnet, 2004.

20.

Liu and

Silvester, Congestion control policies for wireless multimedia CDMA networks, Journal of High Speed Networks 8(2) (1999), 135–147.

21.

Mathis,

Semke,

Mahdavi and

Ott, The macroscopic behavior of the TCP congestion avoidance algorithm, ACM SIGCOMM Computer Communication Review 27(3) (1997), 67–82. doi:10.1145/263932.264023.

22.

Megyesi,

Kramer and

Molnar, How quick is QUIC?, in: International Conference on Communications (ICC), 2016, pp. 1–6.

23.

Quic Test Server Retrieved, 2017 Available: http://www.chromium.org/quic/playingwith-quic.

24.

Roskind, QUIC: Design Document and Specification Rational, 2015.

25.

Sandvine, Global Internet Phenomena Report, 2016.

26.

Srivastava, Performance Analysis of QUIC Protocol under Network Congestion, 2017, Ph.D. dissertation, Master Thesis, Worcester Polytechnic Institute.

27.

Swett, QUIC: Congestion Control and Loss Recovery, 2015.

28.

Swett and

Iyengar, QUIC Loss Recovery and Congestion Control, (2015) Internet-Draft, Intended status: Informational, IETF.

29.

Wang and

Shin, Robust TCP congestion recovery, Journal of High Speed Networks 13(2) (2004), 103–121.

30.

Xu,

Harfoush and

Rhee, Binary increase congestion-control (BIC) for fast long-distance networks, in: 23rd Annual Joint Conference of the IEEE Computer and Communications Societies INFOCOM, Vol. 4, 2004, pp. 2514–2524.

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

Abstract

Keywords

1. Introduction

2. QUIC: Background with congestion control and related work

2.1. Background

2.2.1. CUBIC

1 In 2016 FEC functionality is removed from QUIC due to lack of significant contribution.

4. Experimentation and result analysis

4.1. Testbed setup with parameter space used for experiment

2 WAN: LTE (2300/1800/850 MHz) IEEE 802.11b/g/n 2.4 G.

References

¹
In 2016 FEC functionality is removed from QUIC due to lack of significant contribution.

²
WAN: LTE (2300/1800/850 MHz) IEEE 802.11b/g/n 2.4 G.