Using varints to encode the Transport Parameters

Marten Seemann <> Mon, 29 October 2018 11:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B86FB130E91 for <>; Mon, 29 Oct 2018 04:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zIShRZvl5rWD for <>; Mon, 29 Oct 2018 04:14:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA22E130E90 for <>; Mon, 29 Oct 2018 04:14:02 -0700 (PDT)
Received: by with SMTP id f12-v6so1414710iog.0 for <>; Mon, 29 Oct 2018 04:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=equF8Qf/AYwL3Q8ORL7TYqDvaqOdloj+QdAPqX3IFec=; b=l+1y3rjtyi54AOVyNGuN1S7CWoWCGYdNZtUJpH60urW15djnrqBL0cCkV3zpayX8hT GgguNec2K3Pd/Ri/kJftw52aBXS8IiYtgsHZDt7LVymZHEtF8oiSdOS7TBwN0YbYCnP+ +twv6oE9zzhZZWWsft53i2L07HBIVOOi99oojRXNlgdbnUBEKFXA/kOZaRDNLdjBn1hg Aa0EDrtRciAFSQVnHgFaPDSAWYEbN+Kd1jZMuM8CfWH16jCanrDmyqaHx85CWr9Kn4cV C0X8fjYYMAszchsxTaqeIsrh3wILPaSApkzzhmm0aW9rrafdBFGNNscF7M6H2MJGMUk7 TreA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=equF8Qf/AYwL3Q8ORL7TYqDvaqOdloj+QdAPqX3IFec=; b=aoeLp4aQgHyJs0CwBlTYEO+3InoC6YoyfpmwpUgSXIx9vwU+bZVeS+8O1KkX1y1zeG mJRc6ZOq73SsFX/mJfm3asXJJ3co4rt0pjRyBz/xDvKfFZl/K/TSAdVOmJ2HENwsJRgW uM06AUbJ2Rn3ctxIdtEK4thiPZjcC8NwNdi5ldDt92/KulqJy4eZ3H055+d53GyAET78 7hOVrBeltFeP/krlLi+S+u9e7r4MpJXyowXhc+moIkZ5uUWp6CLkxuEKhAWa9C3EEAlC 9FeAcoTPOM5DdOKKr+BtSYqzv6mCWZSYixp/+UeXzLvEkK3jEaS2liOl9u297g3pUzni czPQ==
X-Gm-Message-State: AGRZ1gKYzBvVuH1VpCrAuJcD9TWVm36PmMTAT5Kh2SmaKPi5mXC+tGG7 uHJomfoF/r2JFeS0ZccBUWivps4x55Wq1JP+ngnNPA==
X-Google-Smtp-Source: AJdET5frR94TiD8hoVk5RiwM2tp6cLxPa1gK7AT947hKtlRKgrURyohjJdDrNEiexu+KFPCohRcE2ScG+XyJLLuAG/c=
X-Received: by 2002:a5e:8e44:: with SMTP id r4-v6mr8343163ioo.100.1540811641652; Mon, 29 Oct 2018 04:14:01 -0700 (PDT)
MIME-Version: 1.0
From: Marten Seemann <>
Date: Mon, 29 Oct 2018 18:13:50 +0700
Message-ID: <>
Subject: Using varints to encode the Transport Parameters
To: QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000910b3d05795c2a32"
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 11:14:05 -0000

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