Subject: An Update about Chrome and IETF QUIC

From: David Schinazi <[email-masked]>
Date: Wed, 7 Oct 2020 09:49:45 -0700

Hi QUIC WG,

We would like to share an important announcement from Chrome:
https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

In particular, we'd like to highlight two points of interest to the WG:

1) Chrome now supports IETF QUIC by default (h3-29).

2) Since the subsequent IETF drafts 30 and 31 do not have
compatibility-breaking
changes, we currently are not planning to change the over-the-wire
identifier. What
this means is that while we'll keep tracking changes in the IETF
specification, we
will be deploying them under the h3-29/0xff00001d name. We therefore
recommend
that servers keep support for h3-29 until the final RFCs are complete if
they wish to
interoperate with Chrome. However, if the IETF were to make
compatibility-breaking
changes in a future draft, Chrome will revisit this decision.

Full details in the link above.

Cheers
David

---

From: Martin Duke <[email-masked]>
Date: Wed, 7 Oct 2020 14:42:12 -0700

Thanks David. I'm intrigued by your performance numbers. You say there's no
0RTT and I've always thought of you guys running a pretty state-of-the-art
TCP stack. Is this just HOL blocking, or is there something else?

---

From: Ian Swett <[email-masked]>
Date: Wed, 7 Oct 2020 18:25:34 -0400

Given TCP TFO is rarely enabled, IETF QUIC without 0-RTT still typically
saves a round trip vs TCP+TLS 1.3.

The YouTube improvements are believed to be due to the lack of
retransmission ambiguity and extra ACK blocks vs TCP w/SACK.  In the
presence of packet policers, both can be quite advantageous.

Note that these are controlled experiments, so they include the metrics
from users who had QUIC enabled, but ended up using TCP due to not yet
caching Alt-Svc, UDP blockage or some other reason.

On Wed, Oct 7, 2020 at 5:42 PM Martin Duke <[email-masked]> wrote:

> Thanks David. I'm intrigued by your performance numbers. You say there's
> no 0RTT and I've always thought of you guys running a pretty
> state-of-the-art TCP stack. Is this just HOL blocking, or is there
> something else?
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 7 Oct 2020 15:45:53 -0700

I'll generally note that the TCP stack in middleboxes, which frequently
terminate connections, may not be as state-of-the-art :-)

---

From: Matt Joras <[email-masked]>
Date: Wed, 7 Oct 2020 15:48:42 -0700

> saves a round trip vs TCP+TLS 1.3.
Even with TLS 1.3 resumption + early data? For us the vast majority of TCP
connections are resumed, meaning HTTP/2 clients can initiate its requests
after 1-RTT, the same as 1-RTT QUIC. It's actually somewhat of an issue in
networks with TCP PEPs since the app will think it's ready to write the
first request on the TCP connection sooner than the QUIC connection, since
the TCP handshake finished unnaturally early.

> FWIW we'll have a blog coming in the next couple weeks which also has
"wow!" numbers, using similar experimental setup (though obviously with our
apps instead of browsers + Alt-Svc). I would agree these are big
contributors, though elimination of HOLB does measurably help connections
with high degrees of multiplexing. The aforementioned PEPs are also often
really terrible for application performance, despite their name suggesting
otherwise. Simply bypassing these can be a big win for QUIC all by itself.

>> Matt Joras

---

From: Nick Harper <[email-masked]>
Date: Wed, 7 Oct 2020 15:50:39 -0700

On Wed, Oct 7, 2020 at 3:49 PM Matt Joras <[email-masked]> wrote:

> Even with TLS 1.3 resumption + early data?
>

Chrome doesn't have early data enabled in TLS 1.3 yet.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 7 Oct 2020 16:35:47 -0700

> otherwise. Simply bypassing these can be a big win for QUIC all by itself.

Yes, that. I continue to believe that the TCP "ecosystem" is broken, and
when you're looking at metrics from real traffic, you're going to be
comparing against all the broken TCP middleboxes.

There's some discussion in Google's SIGCOMM paper (section 6.5):
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/8b935debf13bd176a08326738f5f88ad115a071e.pdf

>>>> that servers keep support for h3-29 until the final RFCs are complete
>>>> if they wish to

---

From: David Schinazi <[email-masked]>
Date: Tue, 20 Oct 2020 10:40:17 -0700

Hi everyone,

To follow up on my previous email, I just wanted to let everyone
know that we've now ramped up h3-29 to over 90% of Chrome
users. (We always keep a few percent of users running other
versions of QUIC or TCP to compare performance.)

Cheers,
David

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 20 Oct 2020 10:44:15 -0700

This is excellent news -- thanks for sharing, David!

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 Oct 2020 10:03:13 -0500

> versions of QUIC or TCP to compare performance.)
Good. So no interoperability issues?
Maybe because both receiver and sender software from the same manufacturer?

Behcet

---

From: David Schinazi <[email-masked]>
Date: Wed, 21 Oct 2020 09:15:37 -0700

Hi Behcet,

As far as we know, we're interoperating really well with other
implementations.
For example, Cloudflare and Facebook have let us know that they're seeing
production levels of h3-29 traffic from Chrome and it's working.

David

---

From: David Schinazi <[email-masked]>
Date: Wed, 21 Oct 2020 10:03:45 -0700

Hi everyone,

One more followup: today drafts 32 came out.
We at Google reviewed the diffs, and came to
the conclusion that there aren't any serious
interoperability breaking changes, so we're
going to stick with h3-29/0xff00001d on the
wire and implement new changes under the
h3-29/0xff00001d identifiers. This applies to
both Chrome and Google servers.

Cheers,
David