Subject: Re: [quicwg/base-drafts] QUIC header format/demultiplexing (#426)

From: janaiyengar <[email-masked]>
Date: Wed, 29 Nov 2017 19:47:46 +0000 (UTC)

We're clearly not done with this discussion yet, per discussion in Singapore and #956. Re-opening this issue so that discussion happens on the issue and not on the PR.

-- 
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/426#issuecomment-347974976

---

From: janaiyengar <[email-masked]>
Date: Wed, 29 Nov 2017 19:47:46 +0000 (UTC)

Reopened #426.

-- 
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/426#event-1364276088

---

From: ianswett <[email-masked]>
Date: Wed, 29 Nov 2017 20:42:52 +0000 (UTC)

I have a few open questions and comments about this before we resolve it.

1) What are we trying to avoid overlapping with?  My previous understanding was that we only cared about STUN, since we could deal with the others overlapping.  Also, doesn't STUN have some large magic cookie to make it easy to identify when multiplexing?
2) Particularly given the cookie, why is Martin's heuristic solution in https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-01#section-2.3 insufficient?
3) Why do we need to flip the connection id bit to be omit connection id?  That removes flexibility for implementations supporting both elsewhere and might make greasing harder.
4) If we need two bits for spin bits or spin+loss(or just reserving them), as is being discussed, we can't put two adjacent bits anywhere and still use the nonce bit to distinguish IETF QUIC from GQUIC, because it will no longer always be 1, hence question 3.  I suspect this might make @britram  and others a bit unhappy?

-- 
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/426#issuecomment-347989914

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 22:17:10 -0800

Can we try not to lump all the issues together?  We don't have greasing yet and nor do we have a spin bit.  Though #956 was an attempt to avoid collisions, nor does it guarantee avoidance in future.  We can assess the impact on use with 7983, for which I recommend following the guidance [here](https://martinthomson.github.io/mux-principles/draft-thomson-mux-principles.html).  In other words, we aren't obligated to continue to make it work, though we might try.

That leaves the heuristics (which includes the STUN cookie).  As discussed, those can be used, but are inefficient and awkward.

-- 
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/426#issuecomment-348093217

---

From: janaiyengar <[email-masked]>
Date: Thu, 30 Nov 2017 07:37:15 +0000 (UTC)

Thank you for your draft on muxing principles -- I think that should have been part of the discussion here prior to committing #956.

I agree that we don't need to design for things that haven't been agreed upon yet (spin bit, greasing), but it's a conversation that may (yet again) have us changing packet types. I don't see harm in anticipating it, but I agree that we shouldn't hold up progress in anticipation of uncertain issues.

That said, AFAICT, we have not agreed on creating a scheme that muxes QUIC with everything in RFC 7983. From the interim, I took away that STUN was probably important, but we didn't care much about the rest of the protocols. That was what I heard @csperkins ask for, and it is what I agreed with -- that maybe we should allow muxing with STUN for now, and I had argued that we leave the rest out. I'm still of that opinion. Practically, if we're only muxing with STUN, we could use a different solution space altogether (basically reserve those 4 types and we're done), but we seem to be trying to accomodate all protocols in 7983. I'd like to see agreement on that.

And if we're only doing STUN, then I've missed the discussion on inefficiencies in using the STUN cookie -- it's not on this bug, where is that discussion?

-- 
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/426#issuecomment-348106690

---

From: Marten Seemann <[email-masked]>
Date: Thu, 30 Nov 2017 07:44:03 +0000 (UTC)

If we only care about STUN, we could revert the inversion of the connection ID flag in #956. This would make the transition from gQUIC to IETF QUIC easy, and it would give us freedom how we use the remaining short header bits (as long as we make sure that 0x0 - 0x3 are reserved for STUN), be it for measurability bits or for greasing.

-- 
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/426#issuecomment-348107983

---

From: ianswett <[email-masked]>
Date: Thu, 30 Nov 2017 15:50:56 +0000 (UTC)

I think it's worth considering all the relevant issues when making this change, because at some point in the near future, we need to stop changing the type byte for long enough to deploy some production code on the internet.  

As Marten said, switching back to "connection ID" from "omit connection ID" would leave us in a place where we can do anything we want with the remaining 6 bits, including greasing and/or spin and still be able to coexist easily with GQUIC, so I propose we do that unless there's a strong argument against it?

-- 
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/426#issuecomment-348229442