Re: Using varints to encode the Transport Parameters

Dmitri Tikhonov <> Mon, 29 October 2018 12:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65A07130F12 for <>; Mon, 29 Oct 2018 05:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LF1MCmh5HcCo for <>; Mon, 29 Oct 2018 05:48:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B80E212D4F2 for <>; Mon, 29 Oct 2018 05:48:44 -0700 (PDT)
Received: by with SMTP id n18-v6so4832740ioa.9 for <>; Mon, 29 Oct 2018 05:48:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=LNtc3yWnRLAbAZ9NRYKFlNE3yFDkjm0etSVqppfH0MY=; b=0K3OpPIgxFq7Zf/zOxzC9kyXXKGsPF21AxvC2/JFuGyIL5056CUrX3vDqgYp+pQpR8 VnoDki6sG3oMHHkTa76RWiamL5nvDhDeagyoXv5keyx5b12FftAnLly10jADlltlzB06 +GVKqemhGKtOsqN1co98aPRzeTRse5UH5WRrRjaMrQ8sQ/D0SVxzuWEwJPJ1UJmJuGL1 Nsg6YoIEgBlVuefrg1sSayXZ40JzSC4G8cYfYF/kd4MHro+hcDDzYCFQl5AtyoE+8T1v G4xBFMln8mgQQRv5RaoIZ4gpeJaS7V8cux40fhv1rdixK+pI/NRKarr+MHnN+saKVx2U erWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=LNtc3yWnRLAbAZ9NRYKFlNE3yFDkjm0etSVqppfH0MY=; b=iku3BxKgVkr0d/8lP5nYsDVQ/ETYQ3W/NpkKKv1qm4fF2cCO+1GhMIYcU4M9hP6jL+ b15GIVhf/wRtCokn3KyDlO6Uv4hY93Lw7oms+BVIh7ga368hiKqbY14VB2AWqaxQFCci TmwcGfPS7ziqdlpWTTiNZm+iqXGXE4TOrmM3Fd5JGuCmBJ4ekvkbEeqOzKa1QLgzTkAA TjAUugHu/BI9WSw8Oau3+63MS4+H5nYFMehSzTCmtSwYwbZRBuc6iYurOiVc/Mff0mfF UjUJMrDILNrtyPe/s+1RPzKUfTphn+1W9sZU6ncZfLdccuhCXU7hvq238Zxi6puXVMxf qj8g==
X-Gm-Message-State: AGRZ1gKjKDwF7XvAABcmlrwDb8No6C5GdldSMCR1Ujcwx3Kz3G+q0Z3Z XgvP1OTJyDzBLzIHJmVQ0Ofglw==
X-Google-Smtp-Source: AJdET5eBwqTZplc9JPo3nvZgsqTtYJj8exMYUUtoRNe5NgdFmrLDHgJDp73zMc+7GWzSu5b491kvwQ==
X-Received: by 2002:a6b:1406:: with SMTP id 6-v6mr8042719iou.218.1540817323959; Mon, 29 Oct 2018 05:48:43 -0700 (PDT)
Received: from ubuntu-dmitri ( []) by with ESMTPSA id i71-v6sm6079297iti.15.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 05:48:43 -0700 (PDT)
Date: Mon, 29 Oct 2018 08:48:36 -0400
From: Dmitri Tikhonov <>
To: Marten Seemann <>
Cc: QUIC WG <>
Subject: Re: Using varints to encode the Transport Parameters
Message-ID: <20181029124835.GA7258@ubuntu-dmitri>
Mail-Followup-To: Marten Seemann <>, QUIC WG <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Oct 2018 12:48:46 -0000

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