Re: Quic: the Elephant in the Room

[Eric Rescorla <[e-mail]>]

On Tue, Apr 20, 2021 at 6:10 PM Michael Thomas <[e-mail]> wrote:

>
> On 4/20/21 5:43 PM, Phillip Hallam-Baker wrote:
>
> On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <[e-mail]> wrote:
>
>> To follow up on what David Schinazi says, the primary determinant of
>> handshake latency for a protocol like TLS or QUIC is not the total number
>> of packets but rather the number of round trips. Of course these are not
>> unconnected because you don't have infinite congestion control window. This
>> is especially true for QUIC because the server is limited to 3x the
>> client's initial flight as an anti-amplification defense [0]. However, in
>> practice, most server certificate chains will fit within a single QUIC
>> flight, as documented in this post by Patrick McManus from Fastly [1]. And
>> if you use RFC 8879 certificate compression you should capture almost all
>> of the rest. For this reason, it seems unlikely that the TLSA approach you
>> propose would significantly decrease setup latency.
>>
>> This is not to say that there is no room for improving latency via keying
>> material in the DNS, but the purpose of that would be to allow the client
>> to send data in its first flight (aka "zero-RTT priming"), not to reduce
>> the size of the server's first flight
>>
>
> If you win at Pinball, you get to play again.
>
> I decided not to engage in QUIC fairly early on. Not because I didn't have
> any relevant ideas but because the scope was already large and my ideas
> would tend to make it larger when was needed was to make it narrower.
>
> As the work continued, I realized that QUIC is very different from TLS and
> TCP: We don't have to try to make one size fits all. We can have separate
> transports optimized for Browsing, RTC and transactional services.
>
> This is a picture perfect example of the power hungry working group chairs
> executing the infidels that have been the subject of many recent talks on
> the IETF list. this is exactly why nobody wants to work with the IETF.
>
There is a certain irony that you are saying this on the mailing list for a
protocol whose github repo has somewhere over 100 separate contributors
(i.e., people who actually submitted PRs and had them accepted). This seems
to me like a good example of a case where quite a few people wanted to work
with IETF.


> I predicated this on the IETF list with Keith Moore and turned out exactly
> as I expected. And it took less than 24 hours. Thanks for making my point
> Lucas Purdue. You are part of the problem, not part of the solution.
>
Having read the thread, I think the chairs handled this appropriately. You
made a suggestion, several people, most notably David Schinazi told you why
they didn't think that it was an improvement, and you responded by
complaining that David didn't want to run an experiment that he didn't see
value in. Lucas politely asked you to take it elsewhere. With that said, if
you in fact think that Lucas behaved inappropriately, I encourage you to
take it up with the ADs.

-Ekr