Is there a case for parallel connections with modern web protocols?

Modern web protocols like HTTP/2 and QUIC aim to make the web faster by addressing well-known problems of HTTP/1.1 running on top of TCP. Both HTTP/2 and QUIC are specified to run on a single connection, in contrast to the usage of multiple TCP connections in HTTP/1.1. Reducing the number of open connections brings a positive impact on the network infrastructure, besides improving fairness among applications. However, the usage of a single connection may result in poor application performance in common adverse scenarios, such as under high packet losses. In this paper we first investigate these scenarios, confirming that the use of a single connection sometimes impairs application performance. We then propose a practical solution (here called H2-Parallel) that implements multiple TCP connection mechanism for HTTP/2 in Chromium browser. We compare H2-Parallel with HTTP/1.1 over TCP, QUIC over UDP, as well as HTTP/2 over Multipath TCP, which creates parallel connections at the transport layer opaque to the application layer. Experiments with popular live websites as well as controlled emulations show that H2-Parallel is simple and effective. By opening only two connections to load a page with H2-Parallel, the page load time can be reduced substantially in adverse network conditions.Peer ReviewedPostprint (author's final draft

On the performance of QUIC over wireless mesh networks

The exponential growth in adoption of mobile phones and the widespread availability of wireless networks has caused a paradigm shift in the way we access the Internet. It has not only eased access to the Internet, but also increased users’ appetite for responsive services. New protocols to speed up Internet applications have naturally emerged. The QUIC transport protocol is one prominent case. Initially developed by Google as an experiment, the protocol has already made phenomenal strides, thanks to its support in Google’s servers and Chrome browser. Since QUIC is still a relatively new protocol, there is a lack of sufficient understanding about its behavior in real network scenarios, particularly in the case of wireless networks. In this paper we present a comprehensive study on the performance of QUIC in Wireless Mesh Networks (WMN). We perform a measurement campaign on a production WMN to compare the performance of QUIC against TCP when retrieving files from the Internet. Our results show that while QUIC outperforms TCP in wired networks, it exhibits significantly lower performance than TCP in the WMN. We investigate the reasons for this behavior and identify the root causes of the performance issues. We find that some design choices of QUIC may penalize the protocol in WiFi, e.g., uncovering sub-optimal interactions of QUIC with MAC layer features, such as frame aggregation. Finally, we implement and evaluate our solution and demonstrate up to 28% increase in throughput of QUIC.This work was supported by the Erasmus Mundus Joint Doctorate in Distributed Computing EMJD-DC program, the Spanish grant TIN2016-77836-C2-2-R, and Generalitat de Catalunya through 2017-SGR-990. This research was conducted as part of the PhD thesis which is available online at upcommons.upc.edu.Peer ReviewedPostprint (author's final draft

Is There a Case for Parallel Connections with Modern Web Protocols?

Modern web protocols like HTTP/2 and QUIC aim to make the web faster by addressing well-known problems of HTTP/1.1 running on top of TCP. Both HTTP/2 and QUIC are specified to run on a single connection, in contrast to the usage of multiple TCP connections in HTTP/1.1. Reducing the number of open connections brings a positive impact on the network infrastructure, besides improving fairness among applications. However, the usage of a single connection may result in poor application performance in common adverse scenarios, such as under high packet losses. In this paper we first investigate these scenarios, confirming that the use of a single connection sometimes impairs application performance. We then propose a practical solution (here called H2-Parallel) that implements multiple TCP connection mechanism for HTTP/2 in Chromium browser. We compare H2-Parallel with HTTP/1.1 over TCP, QUIC over UDP, as well as HTTP/2 over Multipath TCP, which creates parallel connections at the transport layer opaque to the application layer. Experiments with popular live websites as well as controlled emulations show that H2-Parallel is simple and effective. By opening only two connections to load a page with H2-Parallel, the page load time can be reduced substantially in adverse network conditions

Is there a case for parallel connections with modern web protocols?

Modern web protocols like HTTP/2 and QUIC aim to make the web faster by addressing well-known problems of HTTP/1.1 running on top of TCP. Both HTTP/2 and QUIC are specified to run on a single connection, in contrast to the usage of multiple TCP connections in HTTP/1.1. Reducing the number of open connections brings a positive impact on the network infrastructure, besides improving fairness among applications. However, the usage of a single connection may result in poor application performance in common adverse scenarios, such as under high packet losses. In this paper we first investigate these scenarios, confirming that the use of a single connection sometimes impairs application performance. We then propose a practical solution (here called H2-Parallel) that implements multiple TCP connection mechanism for HTTP/2 in Chromium browser. We compare H2-Parallel with HTTP/1.1 over TCP, QUIC over UDP, as well as HTTP/2 over Multipath TCP, which creates parallel connections at the transport layer opaque to the application layer. Experiments with popular live websites as well as controlled emulations show that H2-Parallel is simple and effective. By opening only two connections to load a page with H2-Parallel, the page load time can be reduced substantially in adverse network conditions.Peer Reviewe