Subject: [quicwg/base-drafts] Connection ID on a version negotiation packet (#295)

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Feb 2017 16:11:22 -0800

Given that we have opted to go with #119 universally, it might be reasonable to think that the server could make a proposal for the connection ID on a version negotiation packet.  However, it probably isn't a good idea.  Since version negotiation is stateless, there is less need to have stable routing for this packet.  Echoing the connection ID gives the client better assurance that its initial packet was what generated the response.

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 12 Feb 2017 16:14:21 -0800

Hmm, not sure if this is a duplicate of #244.

-- 
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/295#issuecomment-279268064

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Feb 2017 16:07:55 -0800

The first part ("should a version negotiation packet from the server -- a proposal to the client to change its version -- contain a Server-generated Connection ID?") is a new issue.  On one hand, I agree with you that this seems a bit like a kludge.  On the other hand, stable routing may actually be required by some systems.

Imagine a pop with a load balancer and a number of backends behind it.  One may want to roll out a new experimental version of QUIC on a subset of backends. To do that, the system should ensure that the same server that send a version negotiation packet proposing a new QUIC protocol version actually receives packets using the new version (if the client accepts that new version).  Our mechanism to make sure this happens is to encode the backend ID in the Server-proposed Connection ID.

The second part (proving that the sender of the version negotiation packet is on-path) is a dup of #244.

-- 
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/295#issuecomment-279565080