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

Kazuho Oku <> Sat, 18 January 2020 13:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9471F120020 for <>; Sat, 18 Jan 2020 05:33:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.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, RCVD_IN_DNSWL_HI=-5, 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 So71EWKJUYum for <>; Sat, 18 Jan 2020 05:33:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F17812001B for <>; Sat, 18 Jan 2020 05:33:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E142D8C049B for <>; Sat, 18 Jan 2020 05:33:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579354380; bh=mXOchfkiCQr90cBP6S+6jXho0A6OVHO39iZbPmDDX0c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=If8xkN2FdHp5ZJDZsMwndcQ19XKybjAbw9zCOg37m58s8YzkxA6IkEvXvhMnuqr78 NFpa0Ery75Re+Ojm3FG8GVMiuE1qb/ifRRblEqgARxesIGIXhWtFmhi2NpTpVnSO58 Ps2MIBPMwULD2iiOYqqDPIMSzRFchMjUguTI/bYA=
Date: Sat, 18 Jan 2020 05:33:00 -0800
From: Kazuho Oku <>
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_5e23090cd1d63_3bc83fab782cd9643702cf"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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: Sat, 18 Jan 2020 13:33:03 -0000

> 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.

That's a keen observation. I personally favor the idea of using the RETIRE_CONNECTION_ID frame to indicate if the client has finished migration to the preferred address or if it would continue using the original address.

However, such change would require every client to recognize TP.preferred_address, in sense that even a client lacking support intentional migration would be required to signal the retirement of the CID associated to TP.preferred_address. I _think_ we have considered until now that a client that does not implement migration (or migration to preferred address) to simply ignore this transport parameter.

We need to be clear about that.

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