Re: [quicwg/base-drafts] Retire My Own CID (#2645)

Nick Banks <notifications@github.com> Tue, 11 June 2019 02:27 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 15A5F120026 for <quic-issues@ietfa.amsl.com>; Mon, 10 Jun 2019 19:27:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.008
X-Spam-Level:
X-Spam-Status: No, score=-8.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01] 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 oAfxjHqHpXvs for <quic-issues@ietfa.amsl.com>; Mon, 10 Jun 2019 19:27:47 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A395612000E for <quic-issues@ietf.org>; Mon, 10 Jun 2019 19:27:46 -0700 (PDT)
Date: Mon, 10 Jun 2019 19:27:44 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560220064; bh=z22ynoYGZsi+S4us50wUBnuAgHYUeAmMTqNoZ+udW6w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JE+qX5KpIa83a4LEVl6avHy3VUG7kw5XQsRARNGHEA1GeWu9DYyd94BRLcSEblWZD ndQBllR2GBGCmrM8uXkLG8Nx9KAazd6frvMXlKZKwGny9oGXodGlplgS+WVHB4Wasb PKw9AHXZYndiDSkpabEuQMJ4YoyN//+uwkzGtJhU=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6BWQ2EZH7KVKSF7SN3BRCCBEVBNHHBUAUCHA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2645/500662145@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2645@github.com>
References: <quicwg/base-drafts/issues/2645@github.com>
Subject: Re: [quicwg/base-drafts] Retire My Own CID (#2645)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cff11a0c6c5f_1f463fa8094cd95c1065f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/dLO4OfvVmtWGFhWy2LVnydt-YXs>
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: Tue, 11 Jun 2019 02:27:49 -0000

@erickinnear we have strengthened the text, so that it's no longer a request, but a requirement that the peer retire the CID. I also agree with @ianswett that this is very similar to key update, and if an implementation can synchronize keys and packet numbers, I see no reason why CIDs and packet numbers also cannot be synchronized. Practically, for every packet you send, you pick a CID, a key and a packet number to use at about the same time.

The only scenario that I've heard that gives me some pause is if the peer is currently trying to probe on a new path when you are trying to force the CIDs to be retired. It _might_ be easier for the probing logic to continue using the CID it started the probe with. But I'm still not completely convinced. For one, what if that new path has a MUCH bigger RTT than the old one? That would make it a lot more likely it could hit the 3 PTO timer on the primary path. Also, I see no reason why you couldn't immediately switch the CID used for probing as well.

-- 
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/2645#issuecomment-500662145