Re: An Update about Chrome and IETF QUIC

[Ian Swett <[e-mail]>]

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 <[e-mail]> 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?
>
> On Wed, Oct 7, 2020 at 9:50 AM David Schinazi <[e-mail]>
> wrote:
>
>> 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
>>
>