Re: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)

Nick Banks <> Wed, 01 April 2020 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F95C3A109B for <>; Wed, 1 Apr 2020 07:58:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Status: No, score=-1.554 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oOzz7XpUNXAG for <>; Wed, 1 Apr 2020 07:58:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E00A63A1098 for <>; Wed, 1 Apr 2020 07:58:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 40D0A6E11E3 for <>; Wed, 1 Apr 2020 07:58:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585753109; bh=ucGFTfcpB0oTiueaciODUi4eLCUZvsYqCtzRB7iMvok=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=c3rZPiFH0yeQwS/wVuHuJiUbBTiagPG06sjwvKF9fnPUr2RohyI64owtkgAVImTfF CzX8q93za8pikBG80BtoNjmXKdoQUk8yXj34GB1PKipkU/iKeF19x+9cu7+uRc0AFI 9X9A6EjPOz2b3LKuq+4c44Z0gZ9pJHr57IVYlPtE=
Date: Wed, 01 Apr 2020 07:58:29 -0700
From: Nick Banks <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3560/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Equivalence of preferred_address and NEW_CONNECTION_ID (#3560)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e84ac15310bd_575c3fa5e68cd96412523b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Apr 2020 14:58:31 -0000

In our implementation, we plan to do all routing based purely on the CID. IMO, the couple of byte overhead in a 1500 MTU (at least; in datacenter) packet isn't going to make much difference, so it's just simpler to have a common CID routing scheme.

That being said, I personally am not against allowing for others to do something different. I've never understood why we make any restrictions on changing between 0-length and non-0-length CIDs at all. IMO, the complexity is that it can change length at all, not that it's zero or not.

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