[quicwg/base-drafts] Connection ID lengths 1, 2 and 3 bytes can't be encoded (#1570)

Marten Seemann <notifications@github.com> Sun, 15 July 2018 18:36 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CF9C2130DE2 for <quic-issues@ietfa.amsl.com>; Sun, 15 Jul 2018 11:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id GdhvNzdwTzSS for <quic-issues@ietfa.amsl.com>; Sun, 15 Jul 2018 11:36:39 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C63127598 for <quic-issues@ietf.org>; Sun, 15 Jul 2018 11:36:39 -0700 (PDT)
Date: Sun, 15 Jul 2018 11:36:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1531679798; bh=sSNpnpwHkCDa0t/2axy6qn1NCv9qhqeeZcMRNPl7yMw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=gCQWeVFOW6v4aIVgEQAsEiJl27gALI3aC3xwJqgH9hoAUGc4GeeC85yRfyqDlrpGw XKZmxxOUuD2eu4+VVX/effiQfEexAXJst7E5TTcS/ywxkKq0akI1cAozElg+Y1wyxI S//k4HR3pxM/lbMC+aIJBwnJVn5DYxKnHr61rG24=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb178e6c84ffffbd5d5c56ee5173e62b5f389bbc292cf000000011763563692a169ce14587666@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1570@github.com>
Subject: [quicwg/base-drafts] Connection ID lengths 1, 2 and 3 bytes can't be encoded (#1570)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b4b9436d1e5b_69c43fe3bd27af8462976e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/TmJICF1bpd3ROQpQb1tbvViLzU8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jul 2018 18:36:42 -0000

The connection IDs can be either 0 bytes or anything between 4 and 18 bytes (inclusive). Lengths of 1, 2 and 3 bytes are not possible.

There are several use cases that would benefit from using shorter connection IDs, especially in p2p applications. An endpoint could encode the length of the connection ID into the first few bits, and then starts using 1 byte connection IDs first, and successively moves to longer lengths only when handling more connections. For p2p hosts, in many cases 2 bytes would be sufficient for all use cases.

In the connection ID length field in the Long Header, we only have 4 bits to encode a range of 19 values (we want 0 byte connection IDs, and we want to support 18 byte connection IDs), so *some* values have to be left out. It seems there are few use cases for 13, 14 and 15 bytes.

We could achieve this by changing the definition of the length to:

>  An encoded length between 0 and 12 inclusive indicates that the connection ID is also 0 to 12 octets in length. Any larger value is increased by 3 to get the full length of the connection ID, producing a length between 16 and 18 octets inclusive. 

If people are supportive of this change, I'd be happy to write a PR.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: