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