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

Kazuho Oku <notifications@github.com> Mon, 20 January 2020 11:50 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213C312010F for <quic-issues@ietfa.amsl.com>; Mon, 20 Jan 2020 03:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3
X-Spam-Level:
X-Spam-Status: No, score=-3 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeBOxtON_yrk for <quic-issues@ietfa.amsl.com>; Mon, 20 Jan 2020 03:49:55 -0800 (PST)
Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A68F120111 for <quic-issues@ietf.org>; Mon, 20 Jan 2020 03:49:55 -0800 (PST)
Date: Mon, 20 Jan 2020 03:49:54 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579520994; bh=JzWEKmju0TbRwe95MFtifUTscLHwpmPMw7l1AM1IX3A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UZWSpn7JzXT5Ms7u7rJUMqy0KNHYfHfRK9r9fPyT4H1cBRL9ANboYCVKQNDEqIn3O UYuDRSnFF0tkz3xyCSnvehGrNliEXYzMZrh0TW7K8mbVf0Pz8Fez3ZCKJPJr32WGML cFq/a8TqZREflObJwbe8pYl18nO05QCwIWK0Fzws=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYLHPBKWU7QZAD3Q5N4GLDGFEVBNHHCBWF2DE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3353/576240125@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3353@github.com>
References: <quicwg/base-drafts/issues/3353@github.com>
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_5e2593e26d485_54ee3f9f3d4cd96812256"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/RkfkeHCnIIr7V1tHYVVaaFokQsk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2020 11:50:00 -0000

@martinthomson 
>> Retirement of either of these connection IDs notifies the server of the address the client has chosen.
> 
> This implies a semantic to the retirement of connection IDs that is not already defined. It says that in addition to releasing the resource, the server can say definitively that those other network paths won't be used. But this is misleading because retiring CID 1 does not prevent CID 4 from being used on that path.

I think that the point being missed here is that under a given condition the server can determine the path being used for CID4.

If the CID4 is issued prior to the client choosing the path, it is true the server would not be able to determine the path on which CID4 will be used.

But if the server withholds NCID frames until the client chooses the path and notifies its choice by retiring one of the first two CIDs, then the server can tell for sure. Because either of the first or the second CID would be retired first, and that tells the server the path the client has chosen. As we agree, we already state that a client cannot come back to the original address, once it migrates to the preferred address.

The benefit of requiring such retirement is that the server can issue CIDs specific to the server address, as pointed out by https://github.com/quicwg/base-drafts/issues/3353#issuecomment-575384854. Assuming that such server deployment would be within our design scope, I think requiring such retirement is not a bad idea.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3353#issuecomment-576240125