Skip to main content
  • Banishing the bane of bufferbloat

    Bufferbloat affects everyone who uses the Internet, resulting in frustratingly slow web browsing, laggy video calls, and overall poor quality of experience for Internet users and there's a lot of work underway in the IETF to address it.

    • Bjørn Ivar TeigenIETF Participant
    23 May 2023
  • IETF 116 post-meeting survey

    IETF 116 Yokohama was held 25-31 March 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

    • Jay DaleyIETF Executive Director
    26 Apr 2023
  • Catching up on IETF 116

    Recordings are now available for sessions held during the IETF 115 meeting and the IETF Hackathon, where more than 1500 participants gathered in London and online 5-11 November 2022.

      1 Apr 2023
    • Reducing IETF Meeting Scheduling Conflicts

      With many IETF participants active across a number of active working groups and limited time slots in an IETF meeting week, we aim to arrange sessions in the agenda to minimize conflicts that prevent participants from joining sessions that are of interest to them. In each post-meeting survey we ask meeting participants to comment on the scheduling conflicts they experienced in the meeting agenda and we then use this information to improve the meeting agenda.

      • Alexa MorrisIETF Managing Director
      31 Mar 2023
    • Messaging Layer Security: Secure and Usable End-to-End Encryption

      The IETF has approved publication of Messaging Layer Security (MLS), a new standard for end-to-end security that will make it easy for apps to provide the highest level of security to their users. End-to-end encryption is an increasingly important security feature in Internet applications. It keeps users’ information safe even if the cloud service they’re using has been breached.

      • Nick SullivanMLS Working Group Chair
      • Sean TurnerMLS Working Group Chair
      29 Mar 2023

    Filter by topic and date

    Filter by topic and date

    QUIC working group looks to bring more security to Internet traffic

    • Grant GrossIETF Blog Reporter

    14 Jun 2021

    Lucas Pardue serves as co-chair of the IETF QUIC Working Group, which focuses on a standards-track specification for a UDP-based, stream-multiplexing, encrypted transport protocol. The IETF blog recently asked Pardue about the QUIC standards project.

    Pardue, from London, also works as a senior software engineer at Cloudflare, a U.S. web infrastructure and website security company. An edited version of the conversation appears below.

    IETF blog: What is the QUIC working group? When did it start? 

    Pardue: The QUIC Working Group (WG) is a collection of talented researchers, practitioners, engineers, developers, policy makers, infrastructure operators, service providers ... you name it. Since 2016, we've been working on standardizing version 1 of the QUIC protocol, including transport behavior, loss detection, recovery, congestion control, security, and, in unison with the HTTP Working Group, an application mapping of HTTP to QUIC. 

    For those that might remember, the work on QUIC started long before 2016. We took that as a starting point and wrote a charter that would help us develop a set of documents that had the consensus of the working group and wider IETF community. And as we finish the work on version 1 with the publication of RFCs, we enter a new chapter for the working group. It focuses on maintenance and evolution of the protocol as well as becoming the home for new ideas that leverage the rich extensibility capabilities of QUIC. We have a bright future ahead. 

    IETF blog: How does QUIC improve the performance, privacy and security characteristics of services that use it? 

    Pardue: The QUIC transport protocol is secure by default, meaning it provides strong integrity, authenticity, and confidentiality for all that choose to use it. Services today that use TCP (with or without TLS) should treat QUIC as almost a drop-in replacement substitute. And with the Unreliable Datagram extension that the group is working on, we're on course to be a substitute for DTLS or other such protocols. The one key thing is that QUIC, unlike TCP, protects packet metadata – very little information is exposed to passive observers and no one in the middle is able to manipulate things like sequence numbers or options. This presents some challenges to conventional ways of managing traffic but it fixes a big problem – ossification. 

    When a third party tinkers with your traffic without coordinating with you, they make assumptions about the protocol and the systems the protocol traverses. Those assumptions can create friction when the first party (the endpoints) want to improve or experiment with things. And where the friction is extreme it renders extensions moot or even breaks the protocol, leading to a reluctance or inability to change or evolve. Securing QUIC prevents un-coordinated tinkering and gives us an excellent platform to move ahead with. Today QUIC provides fast handshakes, thanks to Zero Round-Trip time, and many implementers have smart congestion controllers. Tomorrow, the base performance of the protocol can only get better. 

    On the performance side of things, avoiding Head-of-Line blocking is the killer feature of QUIC. This is achieved via stream multiplexing which I'll talk about some more in a later question. This is less of a drop-in replacement than other parts of QUIC, and requires the application using QUIC to be smart about how it interacts with independent streams. 

    IETF blog: How widely is QUIC deployed? How did it come to be widely deployed?

    Pardue: As the QUIC working group has worked on developing the specifications we have seen many implementations of client and server code. Of those, a subset has made it into “production” deployments such as web browsers and public-facing services. Cloudflare made QUIC and HTTP/3 support publicly available to all in September 2019. We've been really happy to see people turning it on and testing with developer/canary/nightly channels of browsers such as Chrome, Firefox, and Safari. As the specifications near maturity, it’s very exciting to see client support start entering the stable channels and getting turned on by default. 

    End users should start to benefit from QUIC's improved security and performance without having to take any manual action. According to data from Cloudflare Radar, in mid-January 2021 the global share of HTTP versions was approximately: 24 percent of HTTP/1.1, 75 percent for HTTP/2, and less than 1 percent for HTTP/3. By mid-February, adoption in HTTP/3 had grown to just over 5.5 percent, with HTTP/2 falling to 69 percent, and HTTP/3 growth substituting for HTTP/2 usage. By mid-May, HTTP/3 represented 12 percent of HTTP traffic share.

    We expect the trend to continue as more browsers and websites get QUIC-enabled.

    IETF blog: What’s the importance of stream multiplexing and encrypted transport protocol?

    Pardue: I've explained how protection from tinkerers helps above in question 2, so won't repeat that here. But let’s not forget that private communications should be just that, private. Encrypted transports are a foundational building block to improving user security and privacy – they enable application developers a foundation on which to build additional security, such as the Web Origin model, same-origin policy, and restriction of web APIs to secure contexts. QUIC's stream multiplexing can help mitigate the phenomena of Head-of-Line (HoL) blocking, where a lost packet holds up everything behind it. This manifests in many ways that can affect end-user experiences. 

    If some critical website script is blocked behind less urgent data, you can be stuck looking at a blank page. If part of your video stream is dropped, you can't simply skip to the bits you do have, instead you might end up watching a spinning icon while it buffers or manually reload and hope things resume where you left them. QUIC has ways to mitigate HoL blocking that if used correctly, can improve the quality of experience, especially helping in networks that experience regular problems. 

    In TCP there is one logical bytestream; data sent in this stream is guaranteed to be received in-order. The TCP stream is split up into segments for transmission over the network using IP, and since the network is not guaranteed to be reliable, it might lose packets or reorder them. It's the job of TCP to handle such events and present the stream as expected. This usually works well but sometimes HoL blocking rears its ugly head. Imagine you sent the sequence A, B, C, D, E in separate packets and the third one was lost. The receiver gets the sequence A, B, D, E. It can't present all four values to the application, only the first contiguous range A, B.

    QUIC streams can fix this. Each stream, identified by a 62-bit integer, is independent and behaves like its own mini-TCP, all under a common protection. A sender could choose to split A, B, C, D, E over different streams and the sender could read them out in any order. If a packet with one of the values gets lost, no problem, you just read everything as it arrives! The challenge however is reading the sequence back in the order it was sent. The stream ID can be used to help here but how that actually happens is described by an application mapping like HTTP/3. Solving HoL blocking is possible, but tuning it for the best quality of experience is the next area of opportunity. 

    IETF blog: What’s next for QUIC?

    Pardue: I'm super excited for the next chapter of QUIC. As people deploy version 1, we'll learn and identify potential improvements. QUIC versioning and extensibility is rich and robust. We have updated the working group charter in order to broaden the scope of work that we can consider. Some of the new ideas, like smarter retransmissions have been adopted, and we are considering candidates like qlog for richer standardized endpoint logging. Personally, I'm excited about the application-layer possibilities that QUIC is enabling. The IETF has already formed the MASQUE and WebTransport working groups that build upon QUIC foundations. The future is bright.


    Share this page