Subject: Re: [quicwg/base-drafts] Long Header Packets and Routing Connection IDs (#2834)

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jul 2019 00:22:29 -0700

Can someone summarize this discussion for me?  We've settled on the spin-off piece (I think), but I lost the thread here.

-- 
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/2834#issuecomment-509522900

---

From: mirjak <[email-masked]>
Date: Tue, 09 Jul 2019 00:42:42 -0700

We also have a section about CID and load balancing in the manageability draft. However it's pretty short and could definitely need more text. That's what it currently says:

"In the case of content distribution networking architectures including load balancers, the connection ID provides a way for the server to signal information about the desired treatment of a flow to the load balancers. Guidance on assigning connection IDs is given in {{?QUIC-APPLICABILITY=I-D.ietf-quic-applicability}}."

-- 
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/2834#issuecomment-509529283

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 22 Jul 2019 19:54:12 -0700

That's a long thread, but I believe I was pointing out this issue for at least a year now. Actually, we had "long headers have client's CID" for a while and then it changed.

I can see two real options ("identify that a CID is server's just by looking at it" I do not consider an option):

1. Make it explicit whose CID it is, for example by mandating that long header packets have client CID.  Then have LB keep "ClientCID -> backend" mapping for the duration of the handshake.

2. Keep it confusing whose CID is in a long header packet. Then have LB keep "4-tuple -> backend" mapping for the duration of the handshake. The implication is that no two concurrent handshakes are allowed on a single 4-tuple -- the statement that WG agreed to in NY in response to exactly this issue.

-- 
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/2834#issuecomment-514033039

---

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Jul 2019 08:29:16 -0700

Discussed in Montreal, proposal is to close with no action 

-- 
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/2834#issuecomment-514261186

---

From: martinduke <[email-masked]>
Date: Tue, 23 Jul 2019 14:15:20 -0700

@nibanks and I discussed in Montreal and agreed that we could handle this in QUIC-LB under the issue he filed there: https://github.com/martinduke/draft-duke-quic-load-balancers/issues/43

-- 
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/2834#issuecomment-514386591