Re: Differentiate between GQUIC and QUIC packets

[Ian Swett <[e-mail]>]

On Tue, Aug 1, 2017 at 8:50 AM, Dmitri Tikhonov <[e-mail]
> wrote:

> 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].
>

The decision about whether to require a connection ID is something
negotiated during the handshake, so client and server get to choose whether
they require it.  Particularly during the transition, it's much easier to
require it from the client to server.

See the truncate_connection_id transport parameter in 7.3.1
<https://tools.ietf.org/html/draft-ietf-quic-transport-04#section-7.3.1>.


>
> > 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.
>

You can rely on 5-tuple once the connection is established, but it wouldn't
handle NAT rebinding by itself.

>
> > 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?
>
>
Chrome is in the process of migrating towards IETF QUIC, but there is a
plan to support at least two versions during the transition.

  - Dmitri.
>