Re: Quic: the Elephant in the Room

On Wed, Apr 21, 2021 at 12:56 PM Michael Thomas wrote: > > On 4/21/21 9:46 AM, Lars Eggert wrote: > > > > I also got told that signing a zone is tantamount to "boiling the ocean". > > You're misquoting David. He said: > > > > On 2021-4-20, at 20:20, David Schinazi wrote: > >> I'm not saying that

Re: Quic: the Elephant in the Room

On 4/21/21 9:46 AM, Lars Eggert wrote: I also got told that signing a zone is tantamount to "boiling the ocean". You're misquoting David. He said: On 2021-4-20, at 20:20, David Schinazi wrote: I'm not saying that a 3-packet handshake would be bad, I'm saying that it's not worth boiling the

Re: Quic: the Elephant in the Room

Hi, On 2021-4-21, at 19:11, Michael Thomas wrote: > I am a newcomer. I came here against my better judgement as I stated on the > IETF list. I have emails from you in my IETF mail archive at least as far back as 2006. But I assume you mean that you are a newcomer to the QUIC WG. > I immediate

Re: Quic: the Elephant in the Room

On 4/21/21 7:16 AM, Lars Eggert wrote: Hi, On 2021-4-21, at 16:57, Michael Thomas wrote: And that was apparently enough to cause the chairs to go ballistic. It was not polite whatsoever. It was a first class snarl. the message that was sent said: "This thread is not discussing a QUIC

Re: Quic: the Elephant in the Room

Hi, On 2021-4-21, at 16:57, Michael Thomas wrote: > And that was apparently enough to cause the chairs to go ballistic. It > was not polite whatsoever. It was a first class snarl. the message that was sent said: "This thread is not discussing a QUIC-specific issue. There are more appropr

Re: Quic: the Elephant in the Room

On 4/20/21 6:27 PM, Eric Rescorla wrote: 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 wan

Re: Quic: the Elephant in the Room

On 4/20/21 6:27 PM, Eric Rescorla wrote: 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

Re: Quic: the Elephant in the Room

On 4/20/21 6:31 PM, Lucas Pardue wrote: Michael, On Wed, 21 Apr 2021, 02:19 Michael Thomas, > wrote: [] if anybody is baffled by this, you should read the thread on the ietf list about "snarling". the wg chairs are a classic example. their fiefdom was ch

Re: Quic: the Elephant in the Room

Michael, On Wed, 21 Apr 2021, 02:19 Michael Thomas, wrote: > [] > > if anybody is baffled by this, you should read the thread on the ietf > list about "snarling". the wg chairs are a classic example. their > fiefdom was challenged. it was utterly predictable, and I called it > before hand. > Yo

Re: Quic: the Elephant in the Room

On Tue, Apr 20, 2021 at 6:10 PM Michael Thomas wrote: > > On 4/20/21 5:43 PM, Phillip Hallam-Baker wrote: > > On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla wrote: > >> To follow up on what David Schinazi says, the primary determinant of >> handshake latency for a protocol like TLS or QUIC is not

Re: Quic: the Elephant in the Room

[] if anybody is baffled by this, you should read the thread on the ietf list about "snarling". the wg chairs are a classic example. their fiefdom was challenged. it was utterly predictable, and I called it before hand. Mike

Re: Quic: the Elephant in the Room

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

Re: Quic: the Elephant in the Room

On Tue, Apr 20, 2021 at 4:18 PM Eric Rescorla 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

Re: Quic: the Elephant in the Room

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 espe

Re: Quic: the Elephant in the Room

On 4/20/21 10:57 AM, Lucas Pardue wrote: Hi, Chair hat on. This thread is not discussing a QUIC-specific issue. There are more appropriate venues to discuss the merits of TLS, DANE and PKIs. Please take it there. Typical, and predictable. This also confirms exactly why people don't want

Re: Quic: the Elephant in the Room

Hi, Chair hat on. This thread is not discussing a QUIC-specific issue. There are more appropriate venues to discuss the merits of TLS, DANE and PKIs. Please take it there. Regards, Lucas QUIC WG Co-chair

Re: Quic: the Elephant in the Room

On 4/20/21 10:20 AM, David Schinazi wrote: 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

Re: Quic: the Elephant in the Room

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-

Re: Quic: the Elephant in the Room

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 everythi

Re: Quic: the Elephant in the Room

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 impactfu

Re: Quic: the Elephant in the Room

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

Re: Quic: the Elephant in the Room

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

Re: Quic: the Elephant in the Room

On 4/19/21 1:45 PM, Matt Joras wrote: Hi, Note that there is a TLS feature which reduces the crypto (TLS) data needed to be sent during the handshake considerably, resumption. The vast majority of QUIC connections in our deployment (and TCP + TLS for that matter) are resumed. In a typical resu

Re: Quic: the Elephant in the Room

On 4/19/21 2:32 PM, Matt Joras wrote: Hi Paul, On Mon, Apr 19, 2021 at 2:13 PM Paul Vixie wrote: hello. can you explain how you get from: On Mon, Apr 19, 2021 at 01:45:48PM -0700, Matt Joras wrote: ... The vast majority of QUIC connections in our deployment (and TCP + TLS for that matter)

Re: Quic: the Elephant in the Room

Connecting to the wrong place costs more than slightly longer handshake, and I suspect often happens because our name mapping solution is a host mapping solution, whereas for many use-cases today we need object mapping, since it is impractical to host every object in every place the service exis

Re: Quic: the Elephant in the Room

Hi Paul, On Mon, Apr 19, 2021 at 2:13 PM Paul Vixie wrote: > > hello. can you explain how you get from: > > On Mon, Apr 19, 2021 at 01:45:48PM -0700, Matt Joras wrote: > > ... The > > vast majority of QUIC connections in our deployment (and TCP + TLS for > > that matter) are resumed. > > to: > >

Re: Quic: the Elephant in the Room

hello. can you explain how you get from: On Mon, Apr 19, 2021 at 01:45:48PM -0700, Matt Joras wrote: > ... The > vast majority of QUIC connections in our deployment (and TCP + TLS for > that matter) are resumed. to: > ... Resumption makes > this particular concern a non-issue for most real world

Re: Quic: the Elephant in the Room

On 4/19/21 1:45 PM, Matt Joras wrote: Hi, Note that there is a TLS feature which reduces the crypto (TLS) data needed to be sent during the handshake considerably, resumption. The vast majority of QUIC connections in our deployment (and TCP + TLS for that matter) are resumed. In a typical resu

Re: Quic: the Elephant in the Room

19, 2021 at 11:34 AM Michael Thomas wrote: > > Hi all, > > I wrote a blog post called Quic: the Elephant in the Room and posted it > to the ietf list which generated a lot of comments, so maybe it's > worthwhile for this list to consider as well. The jist is getting the

Quic: the Elephant in the Room

Hi all, I wrote a blog post called Quic: the Elephant in the Room and posted it to the ietf list which generated a lot of comments, so maybe it's worthwhile for this list to consider as well. The jist is getting the Quic startup exchange back down to a 3 way handshake and very analogou