Re: Using varints to encode the Transport Parameters

[Ian Swett <[e-mail]>]

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