Subject: Differentiate between GQUIC and QUIC packets

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 31 Jul 2017 23:25:02 -0400

Hello,

I wonder whether supporting both GQUIC and QUIC on the same host and
port has been discussed.  I searched on GitHub and this mailing list,
but could not find anything.

Suppose an implementation wants to serve both GQUIC and QUIC.  How is
it to differentiate between GQUIC and QUIC packets?  There are two
cases to consider:

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.

2) GQUIC vs QUIC short-header format packet

    Now it gets more involved.  From [draft-ietf-quic-transport]:

 "  0                   1                   2                   3
 "  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 " +-+-+-+-+-+-+-+-+
 " |0|C|K| Type (5)|
 " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 " |                                                               |
 " +                     [Connection ID (64)]                      +
 " |                                                               |
 " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 " |                      Packet Number (8/16/32)                ...
 " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 " |                     Protected Payload (*)                   ...
 " +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 "
 "                     Figure 2: Short Header Format

	and

 " The packet type in a short header currently determines only the size
 " of the packet number field.  Additional types can be used to signal
 " the presence of other fields.
 "
 "                     +------+--------------------+
 "                     | Type | Packet Number Size |
 "                     +------+--------------------+
 "                     | 0x01 | 1 octet            |
 "                     |      |                    |
 "                     | 0x02 | 2 octets           |
 "                     |      |                    |
 "                     | 0x03 | 4 octets           |
 "                     +------+--------------------+
 "
 "                  Table 2: Short Header Packet Types

GQUIC's interpretation of the first byte is:

  0x80  unused, must be set to 0
  0x40  reserved for multipath use
  0x30  packet number size
  0x08  connection ID
  0x04  diversification nonce
  0x02  public reset
  0x01  version

Here is an ambguity:

  First     QUIC                    GQUIC
  byte      meaning                 meaning

  0x01      No connection ID,       No connection ID,
            1-byte packet           1-byte packet number,
            number.                 version bit set.

(A variation: OR 0x20 for Key Phrase Bit / 4-byte packet number
confusion).

One could use logic like this: "it does not make sense for a packet
to have a version bit set and not have a connection ID: therefore,
it must not be GQUIC."  Is this the recommended approach?  Note that
the ambiguities may get worse if QUIC decides to start using bits 0x1B
for its short-header format first byte.

  - Dmitri.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 31 Jul 2017 23:28:05 -0400

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