Subject: [quicwg/base-drafts] Define a mechanism whereby the server can propose a different connection ID (#119)

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Jan 2017 02:15:53 -0800

QUIC currently has the ability to embed this in the source address token.  I guess that this is primarily because they both happen at the same time (during a stateless reject).

We could turn this into a transport parameter, I guess, but that doesn't work for HelloRetryRequest.

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

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 23 Jan 2017 06:45:53 -0800

When a client is using a Server-proposed connection ID, it would be best for the client to indicate that it is doing so in Version Negotiation packets. That can affect a decision by some servers to perform a Stateless Reject with a new Server-proposed connection ID again.

-- 
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/119#issuecomment-274506099

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Jan 2017 18:07:30 -0800

We'd like to have this feature go into the spec for the following reason.

We have an anycast IP mapped to multiple POPs, and want to continue serving requests if the packets start arriving at a different POP.

With QUIC, since the source address changes, it is much more likely than TCP/IP that packets will start arriving at a different POP. In such case, we'd want to forward packets between the POPs.

For the purpose it would be beneficial if we generate connection ID on the server side, with the POP ID included as part of the 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/119#issuecomment-274680186

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 18:22:15 -0800

@igorlord the normal order of operations is version negotiation THEN stateless reject.  If you want to allow a server to redirect to another node, THEN do version negotiation, things are going to get crazy at the client.  The client has just seen a server accept its selected version, but then it sees it reject that version.

BTW, I am assuming that stateless reject has to come after version negotiation, as it does in the current design.

-- 
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/119#issuecomment-274682342

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 23 Jan 2017 18:44:33 -0800

@kazuho This is a part of our use case as well.  In fact, to help with anycast routing, I opened another issue #205 to allow for more bits for this routing information (I am worried about running out of entropy).

@martinthomson The idea would be that the server accepts the client's Version AND (in the same packet) tells the client to go away and come back with a given ConnectionID.

-- 
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/119#issuecomment-274685651

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 17:39:30 -0800

Discussed in Tokyo; clients will not include a connection ID in the first flight of packets until it receives one from the server, i.e., we're moving to server-generated connection IDs

-- 
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/119#issuecomment-275286972