Subject: Using varints to encode the Transport Parameters

From: Marten Seemann <[email-masked]>
Date: Mon, 29 Oct 2018 18:13:50 +0700

This is based on issue https://github.com/quicwg/base-drafts/issues/1608.

The proposal is to change the encoding of the QUIC Transport Parameters
exchanged during the handshake, in order to achieve greater consistency
with how QUIC encodes values, and also to save a few bytes.

We have a few things that are called transport parameters. This proposal
only applies to the TransportParameter struct as defined in section 18 as:
*struct {*
*      TransportParameterId parameter;*
*      opaque value<0..2^16-1>;*
*} TransportParameter;*
According to the encoding defined by the TLS spec, every key-value pair
will be serialized as:
TransportParameterID (2 byte), length (2 byte), value (length byte)
where the length of the value is specified for each TransportParameterID.

We could switch to varint encoding, as follows:

1. for the TransportParameterID: Since we’re only using the code points 0
to 13, we could save one byte per ID by using a varint.
2. for the length: We would save one more byte, as long as the length of
the value is less than 16 byte (which will be the case for all values
except the preferred_address).
3. For numeric values: This would apply to the flow control offsets, the
maximum stream IDs, the ack delay exponent , the maximum packet size and
the max_ack_delay.

In addition to the byte-savings of 1. and 2., 3. has some more desirable
properties:
    1. It would allow us to encode the whole range of permitted values. For
example, initial_max_data is a 62-bit value, but the current encoding just
allows to send 4 bytes.
    2. Depending on the value sent, this might or might not save a byte
here and there.
    3. We’d be consistent with the encoding we use everywhere else.

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 29 Oct 2018 08:48:36 -0400

I see two problems with this proposal: timing and size.

This is rather late in the game.  If the Working Group is to follow
the plan Martin Thomson outlined in a recent email, this change would
have to be included into -17.

A hybrid of the TLS Presentation language and QUIC varints has to be
specified somewhere itself, thereby increasing the size of the already
hefty transport document.  This new specification, in turn, is likely
to engender some debate and further optimization proposals.  Allowed
to go unchecked, this work would slip our schedule further.

One way to approach this proposal is to have a ready-to-merge PR and
hum it at the upcoming meeting.

  - Dmitri.

---

From: Ian Swett <[email-masked]>
Date: Mon, 29 Oct 2018 13:45:38 -0400

I agree on both of Dmitri's points and if we're going to discuss this in
London, a PR is necessary.

If we were discussing this 6 months ago, I'd be in favor.  If it doesn't
make -17 drafts, I'd say it's QUIC v2.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 09:33:41 +1100

Marten has a week.  That's enough time.

FWIW, here's my grade regarding difficulty:

numeric values to varint - trivial
ID to varint - small change to the grammar
length to varint - major change to the grammar (I'm thinking that you
would signal it by dropping the top of the range like `opaque
x<0..>;`)

You might want to consider not touching the grammar.
On Tue, Oct 30, 2018 at 4:46 AM Ian Swett
<ianswett=[email-masked]> wrote:
>
> I agree on both of Dmitri's points and if we're going to discuss this in London, a PR is necessary.
>
> If we were discussing this 6 months ago, I'd be in favor.  If it doesn't make -17 drafts, I'd say it's QUIC v2.
>
> On Mon, Oct 29, 2018 at 8:48 AM Dmitri Tikhonov <[email-masked]> wrote:
>>