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

Kazuho Oku <> Thu, 16 January 2020 23:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12CDF1200D6 for <>; Thu, 16 Jan 2020 15:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 6kYH_brB4pbl for <>; Thu, 16 Jan 2020 15:32:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DB121200BA for <>; Thu, 16 Jan 2020 15:32:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6BD8F6A11E0 for <>; Thu, 16 Jan 2020 15:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579217526; bh=0jpHC/VH7x7F0fEwUg9DKyCDgugq2hCReKrBMMVYptU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sIyDJ8rIPfEyOF24HRD0bZYDtSn80Jajlck0JuYfSRvtZXyvU4+FbxW4f28ZBK9di xy4vqH0NtFCo/uU6G4uygHLkQp+mZuik0zm748yUkFO9hyIh/t3MXRtvOJzScIzoFe Y2hpmPLkN+8lVEhJECpoyR+hIA7U8fyXCvlObEnw=
Date: Thu, 16 Jan 2020 15:32:06 -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_5e20f2765cc3a_24ac3f81a82cd968101887"; 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: Thu, 16 Jan 2020 23:32:09 -0000

@ianswett Thank you for your comments.

> I can imagine cases when the CID should be based on the path, so I'm less clear on the correct behavior for the second point. By definition, if the CID provided in the transport param has been retired it should not be used to initiate path validation. But I'm unclear if the preferred behavior is don't migrate if you haven't already initiated migration or to use one of the newer CIDs.

First of all, let me state that we do not need to forbid such a design.

However, in a design that expects CIDs to be specific to the server address being used, a server cannot issue a new CID until the migration to the preferred address completes. This is because if a server sends a NCID frame from the original server address before the client completes migration to the preferred address, the server cannot tell if the client would use that issued CID on the original path (this happen when the client fails to migrate to the preferred address), or if it uses that CID on the migrated path.

Therefore, this issue does not have any effect on such a design.

The question at stake is the client behavior we want to recommend, when the server sends a new CID (or retires CIDs) before migration to the preferred address completes.

My view is that TP.preferred_address is a mechanism of specifying an alternative IP address, that "happens" to also carry a new CID, so that the client can always have an unused CID in hand when it initiates migration to the preferred address.

It is actually simple to implement in such way. What you would do is this:
* When receiving TP.preferred_address, store preferred_address.CID exactly the same way as you would do when receiving an NCID frame, and separately store preferred_address.IP_address.
* When handshake is confirmed, if preferred_address.IP_address is stored, initiate a migration to that address, using a CID from a bucket that holds the unused CIDs.

As stated above, such a design would work perfectly fine with servers issuing CIDs specific to server addresses, because a client would have only one unused CID to pick from when talking with such a server. 

The design is also simpler than having special case code that associates preferred_address.IP_address and preferred_address.CID, and handles retirement cleanly.

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