Re: Quic: the Elephant in the Room

[David Schinazi <[e-mail]>]

Cutting down the number of packets was never a goal for QUIC.
The goal was to save round trips in connection establishment,
as that significantly impacts user-visible latency. The number of
packets only slightly increases the probability of loss during the
handshake which can be correlated to user-visible latency, but
much less.

I'm not saying that a 3-packet handshake would be bad, I'm saying
that it's not worth boiling the ocean to remove 2 packets. I'll also
note that your proposal doesn't fully reduce the number of packets
because you still need a DNS TLSA request and response, and loss
of those is much worse as DNS retransmissions are less optimized.

David

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

>
> On 4/20/21 10:07 AM, David Schinazi wrote:
>
> Hi Mike,
>
> I read your blog post, and I failed to find what problem you're trying to
> solve.
> The fact that some handshakes spend a couple packets on certificates?
> We can actually quantify the user-visible impact of the handshake size, and
> from everything I've seen this particular topic isn't impactful enough to
> solve,
> apart from ensuring support for RFC 8879. It's even less realistic if the
> solution involves the minor task of switching PKIs and roots of trust.
> Speaking as one of the QUIC tech leads at a "Google-like company", I can
> ensure you that we don't spend time on experiments that don't benefit
> users.
> It seems that you have a solution in search of a problem here.
>
> I thought the entire point of QUIC (aside from HoL blocking) was to cut
> down the number of packets needed to start a connection. From what I can
> tell, it takes it from an 8 packet exchange to a 5 packet exchange. If you
> were to use a DANE-like solution that would be a 3 packet exchange most of
> the time. Why is a 5 packet exchange good but a 3 packet exchange not?
>
> Mike
>
>
>
> David
>
> On Mon, Apr 19, 2021 at 3:39 PM Michael Thomas <[e-mail]> wrote:
>
>>
>> On 4/19/21 3:33 PM, Lucas Pardue wrote:
>> > I'm struggling to see what the problem statement that is unique to the
>> > QUIC protocol is.
>> >
>> > That certificates can be large is not new information, it was a prime
>> > motivator for RFC 7924 [1] and RFC 8879 [2].
>> >
>> > Operators can, of course, experiment with new optimal ways of doing
>> > things. The broader IETF community is likely interested in the outcome
>> > of such experiments. Since QUIC version 1 uses TLS, any changes that
>> > stand to improve a QUIC handshake would likely be applicable to TLS
>> > too. So the concept of replacing current TLS mechanisms with the DNS
>> > doesn't seem to be something the QUIC WG should be leading. Should
>> > such work identify QUIC protocol design evolution or extension, then
>> > it could be suitable for WG consideration.
>> >
>> I'm not asking this working group to do anything. Just socializing
>> something that generated a lot of discussion on the IETF list that might
>> be of interest to the Quic community.
>>
>> Mike
>>
>>