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

ianswett <> Wed, 01 April 2020 14:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8FEA3A106E for <>; Wed, 1 Apr 2020 07:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.482
X-Spam-Status: No, score=-1.482 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_24=1.618, 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 ptp2k6_wLJz9 for <>; Wed, 1 Apr 2020 07:43:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2E8F3A106C for <>; Wed, 1 Apr 2020 07:43:46 -0700 (PDT)
Date: Wed, 01 Apr 2020 07:43:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1585752225; bh=9tIrjJpJ2apz7bKibbFJqacbQEMYCchlPaTaoh5R1Oc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=b4z3doOR+RuIvCcYEanU9ClKUnDUDDqs40EAeir825lW6OfucWI6TKa06o8577GVD lJfdT6jRoE0sqDyJBsRR5qBEKf6UD7ItTtdKaBcgtekIfESNSUAF4+FzDnxk98wFVz uKFUaKx43boefuZejesA0yA6N4JjntVVTRCCLP8s=
From: ianswett <>
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_5e84a8a18a8a8_462e3ff3640cd96473293"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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:43:49 -0000

I'll note that prohibiting a 0 length CID doesn't actually ensure the server's IP isn't unique, though it does remove an incentive to make it unique.

I'd like to leave the option to switch to a zero-length CID later in the connection, and I think I'd be fine with 4 if we allowed that.

An easy example is a large upload.  I mostly don't care about the CID, but if I'm uploading a 10GB file, maybe saving some bytes matters.  Also, if you're constantly filling the pipe, NAT rebinds are extremely unlikely.

Another example is an environment like a datacenter where there are no NATs and routes are very stable, unless a peer intentionally changes it, so the 5-tuple is sufficient.  In that case, the ideal operating condition is to typically use a 0 byte CID and switch to a non-0 length anytime a peer changes IP or port.  Changing port has some clear benefits in some cases, so it's in no way a threoretical use case.  @nibanks may have thoughts on this range of use case as well.

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