Lucas Pardue

@SimmerVigor
160 Followers
58 Following
99 Posts
Protocol nerd at Cloudflare. Co-chair IETF QUIC WG. Statements here are just mine.
Websitehttps://lucaspardue.com

To help find relevant RFCs no matter what your network connectivity, https://rfc.fyi now implements a service worker that caches the data locally for offline use, and can be installed as a Progressive Web app (PWA) -- i.e., you can install it to your iOS or Android home screen.

Note that it still points to online-only RFCs at the RFC Editor site.

rfc.fyi

Search for RFCs, fast

rfc.fyi

@KHoos @dbelson FWIW neither HTTP/2 or HTTP/3 define any means to emit a reason phrase. See e.g. https://datatracker.ietf.org/doc/html/rfc9114#section-4.3.2

The screenshot demonstrates the user-agent attempting to be helpful by mapping well known codes back to human-readable reason phrases. Any code they don't support, even standardized ones yet implemented, could not be mapped

RFC 9114: HTTP/3

The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3.

IETF Datatracker
When we look at the performance of QUIC, we often find that the limiting factor is CPU consumption of socket calls and crypto processing. It is, but congestion control also matters quite a big. In this blog (https://www.privateoctopus.com/2026/01/30/cpu_bound.html) I explain how fixing the "max RTT" measurement and the pacing algorithm for the C4 algorithm improved tests of picoquic on loopback from "worse than BBR" to "better than Cubic".
Performance of C4 when CPU bound

Back in November 2025, when doing tests of C4 on a loopback address, I observed that C4 achieved lower data rates than Cubic or even BBR. Since “performance under loopback” was not a high priority scenario, I filed that in the long pile of issues to deal with later. Then, in early January 2026, I read a preprint of a paper by Kathrin Elmenhorst and Nils Aschenbruck titled “2BRobust – Overcoming TCP BBR Performance Degradation in Virtual Machines under CPU Contention” (see: https://arxiv.org/abs/2601.05665). In that paper, they point out that BBR achieves lower than nominal performance when running on VMs under high CPU load, and trace that to pacing issues. Pacing in an application process involves periodically waiting until the pacing system acquires enough tokens. If the CPU is highly loaded, the system call can take longer than the specified maximum wait time, and pacing thus slows the connection more than expected. In such conditions, they suggest increasing the programmed pacing rate above the nominal rate, and show that it helps performance.

@icing @socketwench @vaurora it's a commonly held belief that Alien vs. Predator is canon only in the predator universe. Under that system, the next items in the sequence would be

Promehttpeus
Http: covenant

@pemensik disagree sorry. OpenSSL didn't hand roll a sub-par TCP stack. They could have used one of the many existing QUIC C implementations to provide the transport aspects for the applications they wanted to provide. A great chance to build a solid integration and desirable security API. Instead, initial focus was to implement a simple client that could open one stream, negating nearly all of the benefit of QUIC.

Curl's removal reasons seem justified. Is anyone else using this thing?
@pemensik a mess entirely of their own making by deciding to try and implement a transport protocol in a Cryptography and security library.
@icing @bagder it's always sent in order
@tdp_org can everyone stop getting PING'd

HTTP/2-based DoS attacks are here to stay. Many implementations are hardened to them. Quirky behaviour can trigger defenses and cause ENHANCE_YOUR_CALM.

Read one of my latest trips down a debugging rabbit hole.

https://blog.cloudflare.com/go-and-enhance-your-calm

Go and enhance your calm- demolishing an HTTP:2 interop problem

HTTP/2 implementations often respond to suspected attacks by closing the connection with an ENHANCE_YOUR_CALM error code. Learn how a common pattern of using Go's HTTP/2 client can lead to unintended errors and the solution to avoiding them.

The Cloudflare Blog

About 6 months ago Louis Navarre reached out to report some DoS-related vulnerabilities in quiche's ack processing. We fixed it up and saw no evidence that the vulnerabilities had been exploited. Check out the deep dive blog post:

https://blog.cloudflare.com/defending-quic-from-acknowledgement-based-ddos-attacks/

Defending QUIC from acknowledgement-based DDoS attacks

We identified and patched two DDoS vulnerabilities in our QUIC implementation related to packet acknowledgements. Cloudflare customers were not affected. We examine the "Optimistic ACK" attack vector and our solution, which dynamically skips packet numbers to validate client behavior.

The Cloudflare Blog