Re: Differentiate between GQUIC and QUIC packets

[Dmitri Tikhonov <[e-mail]>]

On Tue, Aug 01, 2017 at 08:31:11AM -0400, Ian Swett wrote:
> Good question.  The plan is for Google to support both during a transition
> period and the general approach is similar to what you outlined above.

We at LiteSpeed plan to support both as well, hence my query. :)

> The key to resolving the ambiguity is that gQUIC always requires a
> connection ID from the client to the server, and the intent is to
> continue to require that for IETF QUIC.

AFAICT, this requirement is not documented in the latest
[draft-ietf-quic-transport].

> Google's server uses the connection ID to lookup the connection,
> so I believe we'd just discard an incoming packet with no connection ID.

I was hoping to avoid performing a hash lookup...  But what you're
saying is that this is necessary to resolve ambiguous packets.

> On the client side, it knows what version is being spoken, so there's no
> ambiguity.

*nods*

Speaking of clients: is it the plan for Chrome to support both GQUIC
and IETF QUIC during the transition period?

  - Dmitri.