Re: [quicwg/base-drafts] Clarify text around preferred address (#3589)

Eric Kinnear <> Mon, 11 May 2020 17:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F7C83A0BA9 for <>; Mon, 11 May 2020 10:36:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.101
X-Spam-Status: No, score=-3.101 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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, 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 Kcrr2jQgslw0 for <>; Mon, 11 May 2020 10:35:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2B063A0B68 for <>; Mon, 11 May 2020 10:35:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EB3DE961787 for <>; Mon, 11 May 2020 10:35:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1589218553; bh=JycTkzBhMPMaZGWb4V1Shyth8PPxxuLP1ptI7o8pKIk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VaH1g3hY84mrSiGPzUpmp4WvCZSl+Mdqi6CiOMtVEvqYzdxCzU4qv8sgEsIIYiMkn 6OMiIw0iEP8npYvKcp0idcbubads67pUxYO5bAEJ0qrTT/pBgoIloSPkXk81gE732G 7/YoYqKWAZAt+uk44IzEhb0oOyqKHe25XTgTj98k=
Date: Mon, 11 May 2020 10:35:53 -0700
From: Eric Kinnear <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3589/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify text around preferred address (#3589)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eb98cf9de04f_1c253fc9740cd960350a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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: Mon, 11 May 2020 17:36:17 -0000

@erickinnear commented on this pull request.

> @@ -1084,10 +1084,10 @@ Sending a RETIRE_CONNECTION_ID frame indicates that the connection ID will not
 be used again and requests that the peer replace it with a new connection ID
 using a NEW_CONNECTION_ID frame.
-As discussed in {{migration-linkability}}, endpoints limit the use of a
-connection ID to a single network path where possible. Endpoints SHOULD retire
-connection IDs when no longer actively using the network path on which the
-connection ID was used.
+As discussed in {{migration-linkability}}, endpoints MUST limit the use of a
+connection ID to packets sent from a single local address.  Endpoints SHOULD
+retire connection IDs when they are no longer actively using the network path on
+which the connection ID was used.

> Perhaps the problem is the use of "network path".

I would agree, I think we've been trying to steer away from "network path" in favor of things from the perspective of each endpoint.

> The point about NAT rebinding/inadvertent migration here is not relevant and somewhat distracting.

The NAT rebinding is something that's been covered elsewhere already, I believe, but every review that we've had of this text has resulted in someone raising their hand to say "don't forget about NAT rebinding here", so have kept text in to settle that.

> The issue is that with NAT your perspective and others may different.

When we distilled this down, we went from the perspective of the requirements that are placed on each endpoint to help cope with this.

> This text is now contradictory, because I can send from A -> B and A->C

That shouldn't be the case: 
An endpoint MUST NOT reuse a connection ID when sending from more than one local
address, ...
Similarly, an endpoint MUST NOT reuse a connection ID when sending to more than
one destination address.

I think we can change the text above to not mention a "network path" and instead talk about the destination address, since that's what we really mean in this case.

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