QUIC is now RFC 9000

QUIC is a new latency-reducing, reliable, and secure internet transport protocol that is slated to replace TCP, the most commonly used transport today. We’ve talked before about how we love QUIC and are deeply invested in making it a success because it aligns with our mission to build a faster, more resilient, and more trusted internet. In fact, we believe so much in the promise of QUIC that our engineering team includes three core members of the group that built the protocol —  Mark Nottingham, a chair of the QUIC working group at the Internet Engineering Task Force (IETF); Kazuho Oku, a key contributor to the working group and author of quicly, our own implementation of this new protocol; and me, an editor of the core set of documents

The IETF just published QUIC as RFC 9000, supported by RFC 9001, RFC 9002, and RFC 8999. That means QUIC version 1 is officially formalized, and QUIC deployments will now move away from using temporary draft versions to the newly minted version 1. (HTTP/3, the version of HTTP that runs on QUIC, is following closely behind, and should be published soon.)

This news is a big deal, both for the IETF and for the internet ecosystem.

QUIC has been one of the IETF’s most high-profile activities in recent years. Starting as an experiment at Google, QUIC was developed through a collaborative and iterative standardization process at the IETF after almost five years, 26 face-to-face meetings, 1,749 issues, and many thousands of emails. The IETF should celebrate developing and delivering on such an ambitious undertaking — the protocol cut across the traditionally siloed transport, security, and application spaces in protocol design, and it evoked more than its fair share of controversial and heated discussions as it went through the IETF’s consensus processes.

The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification — or growing inflexible over time — through encryption, versioning, and a much richer and more performant set of services upon which technologies can now build. QUIC is poised to lead the charge on the next generation of internet innovations. This has already started to happen with extensions such as unreliable datagrams in QUIC — opening the door to realtime media and other applications that need less than fully reliable transport services — and with promising technologies such as MASQUE and WebTransport.

We are excited to continue leading and engaging deeply in all these conversations and spaces, toward realizing QUIC’s promise for the internet. QUIC has been available on our edge cloud platform for customers to use, and many of our customers are already experimenting and deploying live traffic on it.

But for now, those of us at Fastly and elsewhere who have been deeply engaged in this process over the past half decade or more should soak in the moment and rejoice in having played a part in internet history.

Jana Iyengar
VP, Product, Infrastructure Services
Published

2 min read

Want to continue the conversation?
Schedule time with an expert
Share this post
Jana Iyengar
VP, Product, Infrastructure Services

Jana Iyengar is VP of Product for Infrastructure Services at Fastly, where he is responsible for the core hardware, software, and networking systems that constitute Fastly’s platform. Prior to this, he was a Distinguished Engineer at Fastly, where he worked on transport and networking performance, building and deploying QUIC and HTTP/3, and serving as editor of the IETF’s QUIC specifications. He chairs the IRTF’s Internet Congestion Control Research Group (ICCRG). Prior to Fastly, he worked on QUIC and other networking projects at Google, before which he was an Associate Professor of Computer Science at Franklin & Marshall College.”

Ready to get started?

Get in touch or create an account.