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

Eric Kinnear <notifications@github.com> Thu, 23 May 2019 09:17 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 08FFD12017D for <quic-issues@ietfa.amsl.com>; Thu, 23 May 2019 02:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.009
X-Spam-Level:
X-Spam-Status: No, score=-3.009 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, 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 Ey79qULyadNf for <quic-issues@ietfa.amsl.com>; Thu, 23 May 2019 02:17:27 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9701B120175 for <quic-issues@ietf.org>; Thu, 23 May 2019 02:17:27 -0700 (PDT)
Date: Thu, 23 May 2019 02:17:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1558603046; bh=NYOb16ybOR9EdaajDG3RyyakrQn7Ec93fNUWuZisEog=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=WA+Ai6EM2kbQVF5kgLjkwKteFn+pghLP87vRQNXX1PXxpizjtgUjToHWhDQEnhVP+ uTHEW/2HDode2q/0uLdepUK6Q+ycEsHQqmIMPTYC1h4xKuFk8U+sSCBIDG+fbhZaES 9x7Iskdr12Dkey7fFidbfs0Y/7s4dQu1tyrukM6Q=
From: Eric Kinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5MBPCL36TCBDXRXBN26OL2NEVBNHHBUAUCHA@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/495136925@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_5ce6652685401_51ed3ff2652cd96c5738ad"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: erickinnear
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/jl9AzM8LX97ITstNFhJHUXZ4dz0>
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: Thu, 23 May 2019 09:17:29 -0000

Thanks for writing this up, @nibanks! I think this is going in a good direction.

Ideally, RetireSequenceNumber would either mean "SHOULD retire as soon as possible" or "MUST retire", we can debate that as necessary. 

To @ianswett's comment, there still needs to be a way to increase the number of CIDs that are active (especially at the beginning of a connection), but I think having the field always be present would be fine.

I think the key idea here is that, by asking the other side to retire the CIDs, we can manage to avoid any ACK-tracking or other draining scheme. Instead, we request the peer to use the existing mechanism to remove the old CIDs and all of the logic currently in place for that just works for this too.

Instead of asking the sender to track the ACK for NEW_CONN_ID, I'd rather have it just wait for the CID to be retired, and if it becomes untenable to do that, it can close the connection (either with no error, or we can define an error code saying "you didn't retire, please connect again").

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