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

From: Marten Seemann <[email-masked]>
Date: Thu, 30 May 2019 03:45:11 -0700

Although we don't explicitly prohibit the client from sending NEW_TOKEN frames, the text strongly suggests that this frame is only sent by the server.

For the p2p use case, it would be valuable if the client could provide the server with tokens for future connections.

-- 
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

---

From: Dmitri Tikhonov <[email-masked]>
Date: Thu, 30 May 2019 05:16:09 -0700

Is this for the case when the server and client switch roles for a subsequent connection?

-- 
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-497309646

---

From: Marten Seemann <[email-masked]>
Date: Thu, 30 May 2019 05:58:02 -0700

> Is this for the case when the server and client switch roles for a subsequent connection?

Yes, exactly.

-- 
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-497320021

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 May 2019 16:13:55 -0700

The handshake is asymmetric in QUIC, and tokens are sent only by a client during the handshake. At the moment, there's no mechanism by which a token sent by a client can be used by a 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-497518251

---

From: Marten Seemann <[email-masked]>
Date: Thu, 30 May 2019 22:29:03 -0700

> The handshake is asymmetric in QUIC, and tokens are sent only by a client during the handshake. At the moment, there's no mechanism by which a token sent by a client can be used by a server.

I don't want to change any of that. I'm just talking about the case where the two peers reconnect, this time with switched roles. In a p2p setting, this frequently occurs, and the terms "client" and "server" have little meaning beyond identifying who initiated the connection.

-- 
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-497580828

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 30 May 2019 23:33:57 -0700

While I can understand the desire, I am wary of the complexity that it might introduce. I am not sure if we could consider (and continue to consider) the use-case during the development and the maintenance of the protocol.

Hence the question: how important is it? The only case you'd benefit a round trip from using a NEW_TOKEN token is when you can do 0-RTT. However, 0-RTT can only be used when a connection in the same direction has been established before. Considering that, I wonder what the benefit is.

-- 
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-497593367

---

From: Marten Seemann <[email-masked]>
Date: Thu, 30 May 2019 23:55:10 -0700

> While I can understand the desire, I am wary of the complexity that it might introduce. I am not sure if we could consider (and continue to consider) the use-case during the development and the mai…

I don't think there's a lot of complexity here. The token is literally just an opaque blob which is transferred on one connection and reused on another connection. All the complexity of issuing, encrypting, validating and using the tokens is born by the implementations, and if p2p isn't your use case, you don't need to do anything.

> The only case you'd benefit a round trip from using a NEW_TOKEN token is when you can do 0-RTT. However, 0-RTT can only be used when a connection in the same direction has been established before. 

There are two benefits here, that apply even if you don't do 0-RTT:

1. You save one round-trip for address validation.
2. You can encode additional information into the token. For example, an implementation could encode the RTT of the old connection into the token, and use that as an initial estimate when establishing a new connection.

-- 
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-497598215

---

From: MikkelFJ <[email-masked]>
Date: Fri, 31 May 2019 06:56:47 -0700

I believe the server p2p case is important and a lot of work has been put into making QUIC symmetric.

Background: Symmetry breaks down naturally in the handshake where one is the initiator, and later in migration where only the client can migrate. The handshake is natural, and migration is simply cost-benefit. There are use cases for server migration in ICE client p2p configuration. For server p2p migration is not important which is probably why it was easily agreed to move that to v2.

Conclusion: symmetry is desirable when feasible, but not at all cost.

So, is the token symmetry worthwhile? In the sense that server p2p is, then maybe. In this configuration peers are expected to be fairly static, so an initial extra roundtrip is probably not that big of a deal when roles reverse. But for v2 it certainly makes sense to include.

There are other case like mesh networking where configuration is much more dynamic and is neither cilent p2p nor server p2p. Here saving a roundtrip could be valuable but it might not matter because when it becomes relevant to use such a token, the configuration might have moved on to new pairs of peers.

-- 
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-497717983

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 31 May 2019 07:17:55 -0700

@marten-seemann 
> The token is literally just an opaque blob which is transferred on one connection and reused on another connection. All the complexity of issuing, encrypting, validating and using the tokens is born by the implementations, and if p2p isn't your use case, you don't need to do anything.

While I agree that tokens are just blobs, there are bunch of text explaining how a token is expected to be (or to not be) used, assuming that the roles between the endpoints do not change.

> 1. You save one round-trip for address validation.

The only difference will be the amount of 0.5-RTT data that the server can send. It's either 3 packets (without token) or more (with token, like 10 packets or the CWND remembered by the token). Regardless of the availability of the token, the server cannot send data that cannot be replayed, because until it cannot be certain that the Initial packets that it received came from a legitimate client until it receives a response from the client.

So it seems to me that there'd be some difference, the benefit depending on if P2P application protocols require the server to send several packets worth of data before receiving anything from the client, before validating the client's authenticity.

> 2. You can encode additional information into the token. For example, an implementation could encode the RTT of the old connection into the token, and use that as an initial estimate when establish…

I am not sure how much that is important, because in this scenario, the endpoint that is now acting as the client (i.e. the endpoint that offered the token) should have the knowledge of the RTT. Then, it would retransmit it's Initial at the correct moment, which would trigger the server to retransmit packets.

-- 
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-497725048