Re: Quic: the Elephant in the Room

[Michael Thomas <[e-mail]>]

On 4/20/21 5:43 PM, Phillip Hallam-Baker wrote:
> On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla <[e-mail] 
> <mailto:[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. 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.

Mike