A QUIC chat with Jana Iyengar: Rebuilding fundamental standards of the web

Since I joined Fastly a few months ago, one of the most exciting parts of my experience has been getting to see how Fastly fights for the good of the internet, as well as having the opportunity to dig a little deeper with some of the folks who have been leading the charge. One such improvement is QUIC, a ground-breaking transport layer network protocol that replaced TCP as we know it. In fact, over a billion people use QUIC everyday as part of doing what they do on the web.

One of the key team members leading this effort at Fastly is Jana Iyengar, our VP of Product for Infrastructure Services. Jana is a longtime veteran in the transport standards and networking world, and over the years he has worked on (among other things) building and deploying QUIC and HTTP/3, and serving as editor of the IETF’s QUIC specifications. 

Given his background, I couldn’t miss the chance to chat with Jana about his experiences getting his hands dirty among a whole community of brilliant people who have been busy rebuilding the fundamental standards that underpin the internet that we all use every day. And, honestly, you just have to love a story about how an ordinary person can make such a huge difference in making the entire internet better!

Anil Dash: Let’s start at the beginning. In 2010, I gave Vint Cerf—one of the “fathers of the Internet”—a lifetime achievement award at the Webbys for creating TCP/IP. QUIC has now replaced TCP, which is a massive undertaking! How did it happen? What does it look like in the room?

Jana Iyengar: Let me begin by wearing the hat of someone who has worked in transport for 23 years. This is not just limited to QUIC, but this is a problem we have tried to solve for twenty years.

Since the “turn of the century.” 

Right. We wanted to solve this problem. If you look at some of the early work: next generation HTTP, or HTTPNG as it was called, that all happened in the late 90’s. But after the dot-com bust, the industry didn’t follow through. 

It’s worth noting here that the industry took from the commons and didn’t give back. No one was investing in the fundamental underpinnings of the web.

No one really understood what the real potential of the web was. People thought it was in web portals. Everyone and their uncle was setting up a portal. Once that all died away, the real substance was there and that started to pick up. More and more businesses started to rely on the web. People went from wanting to have a nice website to needing one. Eventually we needed the web to work. By 2010, it was understood that security and speed were both important, but privacy wasn’t really a concern yet. However, there was a turning point around 2013, perhaps incited by Edward Snowden’s revelations about government surveillance of internet traffic.

Let’s talk about that. 

First, we have to clarify the difference between security and privacy. When we talk about security, we mean encryption on the wire. Privacy is keeping PII (personally identifiable information) safe. The Snowden revelations, where we learned that exchange point traffic was being constantly surveilled, made clear that no communications were secure. Outsiders could observe any user data. There were concerns because security to this point had not been considered performant and it could tax your server resources. Infrastructure carried a lot of the inefficient security burden, and it was considered expensive.

The conversation shifted. There was a massive shift to secure communications. End-to-end encryption became the only way to ensure security and became the standard for everything, even within data centers, between services. Meanwhile, the desire to reduce latency persisted. People wanted communications that were fast and secure.

So at this point, people are used to using TCP, but the availability of new devices and widespread growth push it to the limits. What happens next?

QUIC came out of that. TCP’s performance issues for web traffic have been known issue since 1995.

QUIC came out of the need for security, low latency and rapid deployment. It had to move quickly. A significant amount of interesting work had happened already, but the timing wasn’t right until then. QUIC came at a moment where the opportunity opened up.  The driving force for QUIC at its inception was the desire to eliminate the latency overheads of the TCP and TLS handshakes that were part of all web communications.

QUIC was a vehicle for existing advancements to come together. It’s 2015, and HTTP/2 had already shipped. Everyone had tried to reduce latency at the top of the stack, but the real opportunity was much lower in the stack. The conversation began at Google, where I was working at the time. We  worked on it internally , iterated, and shipped it. Then the job of getting other people to use it began. Enter the IETF standards body, and fortunately many other companies like Mozilla, Apple, Microsoft, and Fastly came together based on Google’s proof of concept.

So a prototype really is worth a thousand meetings.

Oh, one hundred percent. The prototype we had was live and working, which helped people jump aboard.

Was there any pushback? Standards setting can be contentious, so I have to think someone had a beef.

We had people come up to the mic and say, “I’m not going to let this happen on my network.”

And we basically told them, “It’s already happening on your network.”

If it hadn’t been working, we would have heard about it as we deployed it. It was already working so that let us deflect a lot of hot air.

We wanted to make more and more things secure and encrypted in the QUIC transport itself. We had a lot of arguments. 

Can you rehash any of that for us? What were the arguments about?

We’d had a hard time deploying new transport technologies on the network. A lot of mechanisms interpose themselves, reading and manipulating your TCP headers, which makes it impossible to deploy new transports.

The QUIC protocol headers were almost entirely encrypted. Many network operators complained about this (and still do). But we protected the protocol so it was possible to iterate and refine it. No one can mess around inside it. Now we retain control of the protocol going forward because the headers are opaque to the systems relaying the content.

There’s a lot more in the annals of QUIC history, recorded in GitHub, in mailing list archives, and in people’s memories of dinner table conversations. I wrote about some of QUIC’s story in an earlier article about the Maturing of QUIC.

Bringing us to today, QUIC is the invisible protocol serving us all, what’s next?We have a new TCP, what can you do with it?

QUIC was built for the web. Almost all browsers now support QUIC natively. iOS and Microsoft support it at the platform level. Most CDN platform vendors support it.

However, web was just the vehicle to get QUIC into these server and client stacks. QUIC is a platform as much as a protocol. MASQUE provides tunnels that allow you to hide your identity. This is the foundation of iCloud Private Relay, for instance, and of the Relay product on which we partnered with INVISV.

You’re in a tradition with pioneers of the internet. But they cast a long shadow. How do you see yourself in this legacy?

I don’t know how to respond to that. I’ve spoken to some of them, and no one ever planned to have the impact they did. IPv4 was supposed to be an experiment. It was never supposed to be the production internet. I don’t think you do your best work when you’re thinking about your impact; you do your best work when you’re doing your best. QUIC has been a huge community effort. There have been several leaders in this community.

I couldn’t tell you that I have personal aspirations in terms of impact; this was just a super interesting challenge. I’ve been working in transport for 23 years and I’ve tried to deploy things in the past. I used to call myself the “patron saint of failed transports.” It took many hands to make QUIC possible and take it to the level of deployment it is at today. I am excited about what we’ll do with it next.

This post is part of Privacy Week, where Fastly is bringing you stories about how we’re integrating privacy practices and technology into the very fabric of the internet.