Re: [quicwg/base-drafts] Renumber packet types and invert Connection ID Flag (#956)

[ianswett <[e-mail]>]

I think this change doesn't change how difficult it is to support GQUIC and IETF QUIC at once.

The fact we're not moving the connection ID really helps, since we can always lookup by connection ID first, and then if nothing is found, try to parse it as a handshake packet that creates a new connection.

On the client side, the main issue would be version negotiation, since for every other packet, the client knows the version in use.  This VN codepoint is not used in GQUIC, so we should be all set.

But to pop the stack, I'm trying to walk through why the heuristics approach outlined in the draft isn't sufficient in practice.  The negatives like not being able to run DTLS and QUIC at the same time on the same 5-tuple seem like non-issues.  Can someone outline what the issues are that motivate this change?
https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-01#section-2.3

The issue of greasing is real.  Unfortunately, I think we may need a way to communicate codepoints not to grease for WebRTC, GQUIC, and other future use cases.

If a server is running GQUIC and IETF QUIC at once, then it is actually using all the codepoints, just for two different protocols, so the space is effectively being greased.


-- 
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/pull/956#issuecomment-347582777