Re: Using varints to encode the Transport Parameters

[Martin Thomson <[e-mail]>]

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=[e-mail]> 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 <[e-mail]> wrote:
>>
>> 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.
>>
>> On Mon, Oct 29, 2018 at 06:13:50PM +0700, Marten Seemann wrote:
>> > 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.
>>