A First Look at QUIC in the Wild

Rüth, Jan; Poese, Ingmar; Dietzel, Christoph; Hohlfeld, Oliver

doi:10.1007/978-3-319-76481-8_19

Cited by 110 publications

(72 citation statements)

References 11 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…negotiation process and records the versions announced by the tested implementations. In a sense, this is similar to the measurements carried out by Rüth et al to identify the number of servers that support Google's version of QUIC (gQUIC) over the entire IPv4 addressing space [25]. Figure 3 summarises our results over the 6-month period.…”

Section: Measurementssupporting

confidence: 77%

Observing the Evolution of QUIC Implementations

Piraux

Coninck

Bonaventure

2018

Proceedings of the Workshop on the Evolution, Performance, and Interoperability of QUIC

View full text Add to dashboard Cite

The QUIC protocol combines features that were initially found inside the TCP, TLS and HTTP/2 protocols. The IETF is currently finalising a complete specification of this protocol. More than a dozen of independent implementations have been developed in parallel with these standardisation activities.We propose and implement a QUIC test suite that interacts with public QUIC servers to verify their conformance with key features of the IETF specification. Our measurements, gathered over a semester, provide a unique viewpoint on the evolution of the QUIC protocol and of its implementations. They highlight the introduction of new features and some regressions among the different implementations.

show abstract

Section: Measurementssupporting

confidence: 77%

Observing the Evolution of QUIC Implementations

Piraux

Coninck

Bonaventure

2018

Proceedings of the Workshop on the Evolution, Performance, and Interoperability of QUIC

View full text Add to dashboard Cite

show abstract

“…Unless otherwise specified, the level of redundancy is set to (30,20) for the Reed-Solomon code and (3,2,20) for the RLC FEC Scheme. This ensures a code rate of 2 3 and a burst recovery capability of 10 symbols per block.…”

Section: ) Experimental Designmentioning

confidence: 99%

QUIC-FEC: Bringing the benefits of forward erasure correction to QUIC

Michel

Coninck

Bonaventure

2019

2019 IFIP Networking Conference (IFIP Networking)

View full text Add to dashboard Cite

Originally implemented by Google, QUIC gathers a growing interest by providing, on top of UDP, the same service as the classical TCP/TLS/HTTP/2 stack. The IETF will finalise the QUIC specification in 2019.A key feature of QUIC is that almost all its packets, including most of its headers, are fully encrypted. This prevents eavesdropping and interferences caused by middleboxes. Thanks to this feature and its clean design, QUIC is easier to extend than TCP. In this paper, we revisit the reliable transmission mechanisms that are included in QUIC. More specifically, we design, implement and evaluate Forward Erasure Correction (FEC) extensions to QUIC. These extensions are mainly intended for high-delays and lossy communications such as In-Flight Communications. Our design includes a generic FEC frame and our implementation supports the XOR, Reed-Solomon and Convolutional RLC errorcorrecting codes. We also conservatively avoid hindering the lossbased congestion signal by distinguishing the packets that have been received from the packets that have been recovered by the FEC. We evaluate its performance by applying an experimental design covering a wide range of delay and packet loss conditions with reproducible experiments. These confirm that our modular design allows the protocol to adapt to the network conditions. For long data transfers or when the loss rate and delay are small, the FEC overhead negatively impacts the download completion time. However, with high packet loss rates and long delays or smaller files, FEC allows drastically reducing the download completion time by avoiding costly retransmission timeouts. These results show that there is a need to use FEC adaptively to the network conditions.

show abstract

“…w 2 already shows an improvement of 19.22 % when using a critical CSS in comparison to the no push strategy. In combination with the push all and push critical strategy, this yields the best performance, i.e., improvements of 33 the server starts pushing CSS after 12 KB of HTML, allowing to proceed with the construction of the DOM faster. However, other websites exhibit no major improvements or even detrimental effects.…”

Section: Interleaving Pushmentioning

confidence: 99%

Is the web ready for HTTP/2 server push?

Zimmermann

Wolters

Hohlfeld

et al. 2018

Proceedings of the 14th International Conference on Emerging Networking EXperiments and Technologies

Self Cite

View full text Add to dashboard Cite

HTTP/2 supersedes HTTP/1.1 to tackle the performance challenges of the modern Web. A highly anticipated feature is Server Push, enabling servers to send data without explicit client requests, thus potentially saving time. Although guidelines on how to use Server Push emerged, measurements have shown that it can easily be used in a suboptimal way and hurt instead of improving performance. We thus tackle the question if the current Web can make better use of Server Push. First, we enable real-world websites to be replayed in a testbed to study the effects of different Server Push strategies. Using this, we next revisit proposed guidelines to grasp their performance impact. Finally, based on our results, we propose a novel strategy using an alternative server scheduler that enables to interleave resources. This improves the visual progress for some websites, with minor modifications to the deployment. Still, our results highlight the limits of Server Push: a deep understanding of web engineering is required to make optimal use of it, and not every site will benefit.

show abstract

A First Look at QUIC in the Wild

Cited by 110 publications

References 11 publications

Observing the Evolution of QUIC Implementations

Observing the Evolution of QUIC Implementations

QUIC-FEC: Bringing the benefits of forward erasure correction to QUIC

Is the web ready for HTTP/2 server push?

Contact Info

Product

Resources

About