Subject: Re: [quicwg/base-drafts] NEW_TOKEN should be symmetric (#2760)

From: ekr <[email-masked]>
Date: Sat, 01 Jun 2019 16:05:37 -0700

I'm skeptical of the value of this change.

Any P2P application where the peers are end-user machines is unlikely to need NEW_TOKEN because it will need ICE or something similar for NAT hole punching and that already gives you a liveness check (as well as an RTT estimate) so you don't need NEW_TOKEN. So, this is then limited to P2P protocols where the peers are actually Internet servers that can adopt either role (e.g., SMTP). Those protocols generally don't seem to have super-high latency concerns, so this doesn't seem like it's going to add a lot of value.

I agree with Kazuho that it would be better to not do this in v1.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2760#issuecomment-497984204

---

From: Martin Thomson <[email-masked]>
Date: Sun, 02 Jun 2019 17:19:22 -0700

Chairs, my assessment is that this is design for sure and maybe quicv2 (on the basis that this isn't needed for h3).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2760#issuecomment-498077934

---

From: Marten Seemann <[email-masked]>
Date: Mon, 03 Jun 2019 01:40:36 -0700

When establishing a new connection, how a token was obtained doesn't play any role. Endpoints can distribute tokens by any way they want. NEW_TOKEN frames are just one way to do so, but tokens might as well be distributed out-of-band.

We made a lot of effort to make QUIC as symmetric as possible. The only exceptions are the 0-RTT feature of the handshake (we inherited this from TLS), and connection migration (which would cause a lot of corner cases). I don't understand why the NEW_TOKEN mechanism fits any of these criteria. Conceptionally, if at all, it seems to be less complexity to allow this frame in both directions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2760#issuecomment-498166706

---

From: MikkelFJ <[email-masked]>
Date: Mon, 03 Jun 2019 02:15:58 -0700

@marten-seemann while I mostly agree, history suggests that there are subtle details to understand for even the most benign features so adding this not very important feature at this stage for the sake of symmetry may not be the best option. I'd like to see it in v2 though. 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2760#issuecomment-498178727

---

From: Martin Thomson <[email-masked]>
Date: Mon, 03 Jun 2019 04:22:50 -0700

Here's how you might start to think about the problem:

Client: if I were a server, you could use this token (NEW_TOKEN)
Server: if you were which server?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2760#issuecomment-498217611