[quicwg/base-drafts] Connection ID Length changes (#2473)

martinduke <notifications@github.com> Fri, 15 February 2019 17:33 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB45A130FFF for <quic-issues@ietfa.amsl.com>; Fri, 15 Feb 2019 09:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level:
X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfHMmP2qmVIk for <quic-issues@ietfa.amsl.com>; Fri, 15 Feb 2019 09:33:15 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDDA130FE2 for <quic-issues@ietf.org>; Fri, 15 Feb 2019 09:33:15 -0800 (PST)
Date: Fri, 15 Feb 2019 09:33:13 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1550251993; bh=Btk1Bmc9hCRrlsGmQF3xDKN8fXKTqegRpYcoUqKNfVs=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=XZ7NEGQcDZavdZ4D1N7Yg5ctmKb64MIrna+wiRm5kNyQmiPwakYEPUAy/kkZF/I5U 5mVtTDMa4D0qV24MHwE80SUAKb2Z7U/ZCqSe8P5UN5bZuUDtWGnqzZ+K8eWi4NCJp4 jyWduMrNfMI0BKP0LnuJALFCg9C/oQDF6l3Jh9bM=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7d9b90e0317a13bb668ac7fb430404202ad4809992cf00000001187eb9d992a169ce187d68e1@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2473@github.com>
Subject: [quicwg/base-drafts] Connection ID Length changes (#2473)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c66f7d9c378f_3fe93fa0146d45b8114822"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/8kKAOXxAzqFK5kamCNvdT8Xnsz0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 15 Feb 2019 17:33:17 -0000

There's nothing in the spec that prohibits this, except from zero to not zero. But should there be?

1) For the receiver, it's a bit annoying to have to store the length of each additional connection ID
2) We could eliminate the length field from the frame
3) If we're concerned about changes from zero-length being detectable, we should also be concerned about length changes being detectable. Ultimately, the complexity of handling this is the problem of the endpoint generating the connection ID, so if you want to do this to yourself, go for it. The use case for going from zero to not-zero (unexpectedly needing migration) is as relevant as changing between non-zero lengths (migrating existing connections when the routing scheme totally changes)

I would recommend one of the following:
A) New CIDs must retain the same length
B) Remove all restrictions on CID length changes - I sorta lean towards this one,  but I think both are better than the status quo.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2473