Subject: [quicwg/base-drafts] Variable-length connectionID/routing information in public header (#205)

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

This issue directly applies to the use of Server Proposed Connection ID (issue #119) / Stateless Rejects (issue #60).

"Origin servers" are often complex multi-server data centers with load balancers. Some "origin servers" are actually globally distributed load balancing and routing systems, possibly with multiple levels of load balancing (for example global and local).  Since packets may show up at any load balancer node (both for global and local load balancers), it is very difficult (if not prohibitive) for these load balancers to keep track of the load balancing decision for each active connection and share that state among all nodes.

To enable stateless load balancing, load balancers need every packet to include routing information for its connection. Server Proposed Connection ID (#119) with Stateless Rejects (#60) are the methods of choice, as they allow the "origin server system" to encode some information into the ConnectionID -- a part of the public header present in every packet.  However, depending on the complexity of the encoded routing information, 64 bits may not be enough to ensure a sufficient amount of entropy in the ConnectionID.

The proposal is to allow Server Proposed Connection ID to include additional information to be present in every packet. That additional information can take a form of an optional longer Connection ID (and therefore be immutable) or be a new mutable part of the public header.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 19:47:16 -0800

If the server were to provide the connection ID as part of a TLS HelloRetryRequest, then the cookie extension could carry this information adequately.

Generally, I think that this duplicates the stateless reject issue perfectly.

-- 
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/205#issuecomment-274698041

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 23 Jan 2017 19:59:02 -0800

Is that cookie available in every packet belonging to the connection?  Can it be read without access to the crypto secrets?  That's what would be needed for doing routing based on the information in the 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/205#issuecomment-274702605

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Jan 2017 21:56:15 -0800

I agree with @igorlord.

IIUC STK is something that can be used for correlating QUIC connections. What @igorlord and I are looking for (per https://github.com/quicwg/base-drafts/issues/119#issuecomment-274680186) is a way to correlate packets belonging to a single QUIC connection to a specific POP or 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/205#issuecomment-274716890

---

From: ianswett <[email-masked]>
Date: Tue, 24 Jan 2017 05:06:37 -0800

I agree that the ability to have a longer than 64 bit connection ID is potentially useful.  @martinthomson Are you saying that the HRR should inform the client of the new, longer connection ID?  If so, that seems reasonable, but it leaves us with a few more questions:

1) Does there need to be a public flag bit indicating a 128 bit connection ID?   (I suspect yes)
2) Is there a realistic need for anything longer than 128 bits?   (I suspect/hope no)
3) Is there a requirement it only be used once version negotiation is complete?   (I suspect no, since we may want to use it when resuming)

Thoughts?

-- 
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/205#issuecomment-274797863

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Jan 2017 15:49:50 -0800

HelloRetryRequest could provide a new connection ID.  We'd need a tweak to the transport parameters to permit it, but that's easy.

If we have a longer connection ID, I would suggest that we make all of them longer and we would only use a flag bit to "compress".  I don't think that we need more than 128.  However, 128 isn't enough to do something like encrypt a value and add an authentication tag, so maybe 128 isn't enough.

Yes, I think that connection IDs are hugely useful - if not necessary - during resumption.  To that end, I think that we might also want to put a connection ID in a session ticket so that a resumed connection can use the right routing information (without also creating a correlator).

-- 
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/205#issuecomment-274976775

---

From: Igor Lubashev <[email-masked]>
Date: Tue, 24 Jan 2017 16:12:56 -0800

While a longer ConnectionID would serve my needs nicely, certainly can be cases when this information is not needed. I would rather see "additional public header data" separate from the 64-bit ConnectionID.  That ExtraData could be set in session ticket. Then, the ExtraData would show up in the public header when the client is doing resumption.

This is just a thought; not a requirement...

-- 
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/205#issuecomment-274980943