Subject: Re: Differentiate between GQUIC and QUIC packets

From: Ian Swett <[email-masked]>
Date: Tue, 1 Aug 2017 08:31:11 -0400

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

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

On Mon, Jul 31, 2017 at 11:28 PM, Dmitri Tikhonov <
[email-masked]> wrote:

> On Mon, Jul 31, 2017 at 11:25:02PM -0400, Dmitri Tikhonov wrote:
> > 1) GQUIC vs QUIC long-header format packet
> >
> >     This is straightforward: the first byte in GQUIC must be zero,
>                                ^^^^^^^^^^^^^^
> >     whereas in QUIC's long-header format packet it is set to one.
>
> This should read "the high bit of the first byte" -- sorry about
> that.
>
>   - Dmitri.
>
>

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 1 Aug 2017 08:50:32 -0400

On Tue, Aug 01, 2017 at 08:31:11AM -0400, Ian Swett wrote:
> 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

*nods*

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

  - Dmitri.

---

From: Ian Swett <[email-masked]>
Date: Tue, 1 Aug 2017 09:08:52 -0400

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

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

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

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

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 1 Aug 2017 06:43:15 -0700

On Tue, Aug 1, 2017 at 6:08 AM, Ian Swett <[email-masked]> wrote:

> On Tue, Aug 1, 2017 at 8:50 AM, Dmitri Tikhonov <

​Google QUIC is continuously evolving. For example, we recently enabled v39
which switched from little endian to big endian, and previously v38 changed
the behavior of the PADDING frame, all to match the IETF. We're working on
v40 at the moment which changes the layout of the ACK and STREAM frames. So
over time Google QUIC will become IETF QUIC.

Cheers,

Ryan

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 1 Aug 2017 14:33:21 -0400

> plan to support at least two versions during the transition.

Recent Chrome releases have not supported older versions:

- Chrome 60 dropped support for Q035 in favor of Q037.

- Chrome dev build 61.0.3163.25 only supports Q039: it does not use
  QUIC to connect to web sites that advertize Q035 or Q037.

Looking at the Chrome code, it does not seem that there is a reason
for it not to work with multiple versions: proto-quic server supports
multiple versions at the same time.

  - Dmitri.