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

On Wed, Oct 7, 2020 at 3:26 PM Ian Swett <ianswett=
[email protected]> wrote:

> 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 protected]>
> 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 <[email protected]>
>> 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
>>>
>>

Reply via email to