Using varints to encode the Transport Parameters
Marten Seemann <martenseemann@gmail.com> Mon, 29 October 2018 11:14 UTC
Return-Path: <martenseemann@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86FB130E91 for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 04:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIShRZvl5rWD for <quic@ietfa.amsl.com>; Mon, 29 Oct 2018 04:14:03 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA22E130E90 for <quic@ietf.org>; Mon, 29 Oct 2018 04:14:02 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id f12-v6so1414710iog.0 for <quic@ietf.org>; Mon, 29 Oct 2018 04:14:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 <martenseemann@gmail.com>
Date: Mon, 29 Oct 2018 18:13:50 +0700
Message-ID: <CAOYVs2rKJMXO806Jp5CpCkH8T80zUHUAauUqdmwEQuTJUhPxnA@mail.gmail.com>
Subject: Using varints to encode the Transport Parameters
To: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000910b3d05795c2a32"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KMSoDdUGs-R7P_GfcBJTxvJARiw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2018 11:14:05 -0000
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.
- Using varints to encode the Transport Parameters Marten Seemann
- Re: Using varints to encode the Transport Paramet… Dmitri Tikhonov
- Re: Using varints to encode the Transport Paramet… Ian Swett
- Re: Using varints to encode the Transport Paramet… Martin Thomson