Re: [quicwg/base-drafts] Description of the use of Preferred Address is unclear (#3353)

Mike Bishop <> Fri, 17 January 2020 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF628120848 for <>; Fri, 17 Jan 2020 10:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Status: No, score=-2.999 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_32=0.001, 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 exSA3E3L3k8O for <>; Fri, 17 Jan 2020 10:21:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31FFB120851 for <>; Fri, 17 Jan 2020 10:21:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 93F7C8C05A7 for <>; Fri, 17 Jan 2020 10:21:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579285278; bh=r991+jPWcXcnLe77nNgfLgKfuXn4BsLRcxryAfbc/rg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=kowMbk9ow4gh1lUiRDu8d3tstWBVBp9RCKJhkYaz+xi/AWgCc7VOiizNEFlZWR7Ve igfkWpOcX6i5StY9ppZtpA2j0kTNb4rt69RyDnmr8xR5p0teuYsU4mZ9ZVWVnPreUz DDmPFP+ckdEsD97qkthH+slswvYw5/VYsQE+4u6I=
Date: Fri, 17 Jan 2020 10:21:18 -0800
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3353/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Description of the use of Preferred Address is unclear (#3353)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e21fb1e85e54_39ee3fbbf7ecd9641603af"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Fri, 17 Jan 2020 18:21:23 -0000

It's a little trickier for servers.  Let's say, hypothetically, that the server knows it's using a different CID pool on the alternative address; it picks one for the public address in the handshake, then gives one from the preferred address's CID pool in the TP.  It doesn't send NCID frames right away.  That's fine.

But let's say the client doesn't migrate successfully.  At some point, the server wants to start issuing the client new CIDs for one or the other of the paths, but QUICv1 doesn't have a way to identify path-bound CIDs.  So the server has to give up on the preferred address if it can't handle CIDs coming to either interface.  There isn't a defined cut-off for when the server should give up expecting the connection attempt, so the best way to do this is to put RPT=2 in the NCID frames.

It seems cleaner initially to special-case the CID from the Preferred Address, and say that you have to use that specific CID to do the migration.  But even with that code, the server has to do the same thing:  wait to see whether the client migrates or not before issuing new CIDs.

I think the piece we're missing is that when a client declares a migration unsuccessful, it MUST/SHOULD retire the CID it used to attempt the migration.  That gives the server a clear signal, succeed or fail; it can then proceed to issue CIDs for the surviving server address.

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