Subject: [quicwg/base-drafts] When should server-chosen connection IDs be sent and how are they indicated? (#349)

From: Ryan Hamilton <[email-masked]>
Date: Mon, 27 Feb 2017 16:27:15 -0800

My sense is that we'd like the server to chose the "real" connection ID to be used for a connection. Among other things, this enables servers to embed routing/load balancing information into connection IDs.

I have heard two options for what the client should do before it has a server-chosen connection ID.

1) Send a random connection ID
2) Send a connection ID of 0

If we go with approach 1, then we need some mechanism that load balancers can use to detect if a packet's connection ID is server-chosen or not. It seems likely that all packets encrypted with 1-RTT keys could use server generated connection IDs. But other packets it's not so clear. Consider the case of a non-0-RTT handshake. The initial client handshake packet would include a client-chosen connection ID. When the server replies, it could use a server-chosen connection ID. If so then when the client sends the next handshake packet it could use the server-chosen connection ID as well. But that means that we'd need a mechanism to disambiguate client handshake packets with client-chosen connection IDs from client handshake packets with server-chosen connection IDs. We could devote bits or packet types to indicate this. I suspect the same argument might hold for server handshake packets. We might not want the server to chose a connection ID until it is ready to accept the handshake.

One benefit of this approach, however, is that a QUIC server could chose to simply use the client's connection ID for the duration of the connection. This would mean that it would not need to be able to generate a new connection ID that is guaranteed to be sent by the load balancer back to itself. In cases where the vendor of the load balancer and the server are not the same, this might be valuable.

If we go with approach 2, then it's obvious that any packet with a non-zero connection ID has a server-chosen connection ID (though the server still may want to verify that it's a "valid" connection ID according to the algorithm it uses). 

On the other hand, this requires QUIC servers which are behind load balancers to be able to generate connection IDs which the load balancer will route back to them. If the server and load balancers are from different vendors, this might be challenging.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 27 Feb 2017 17:13:50 -0800

>  We might not want the server to chose a connection ID until it is ready to accept the handshake.

Or maybe the opposite -- the server can choose the assign a connection ID to this connection at the first opportunity even if it is not yet ready to accept the connection.

An example of this is version negotiation. During new software rollout, backend servers may be running different versions of the software and hence supporting different QUIC versions. When the server is doing version negotiation, it may be _very_ interested in ensuring that the client comes back to this backend server using the QUIC version it requested. If ConnectionID is used by the load balancers to route to backend servers, the server will likely want to generate a new ConnectionID during version negotiation and before it is ready to accept the handshake.

Of course, there must be a way to look at a packet and know what it is using Server's Connection ID.

-- 
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/349#issuecomment-282910264