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

Nick Banks <notifications@github.com> Tue, 23 April 2019 20:20 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 5E1AC120340 for <quic-issues@ietfa.amsl.com>; Tue, 23 Apr 2019 13:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RvqbQcjHd9ow for <quic-issues@ietfa.amsl.com>; Tue, 23 Apr 2019 13:20:25 -0700 (PDT)
Received: from out-7.smtp.github.com (out-7.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB83612013D for <quic-issues@ietf.org>; Tue, 23 Apr 2019 13:20:24 -0700 (PDT)
Date: Tue, 23 Apr 2019 13:20:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1556050823; bh=eJUgZeH9r59G9gcYrTwH8xIepQ65IhiyghPHZVvalY4=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=hzKH9xzdcjC3uMTHPhpI3/fPVml6F7gbvVgrE1bVfUjZvR3HAff7u1iv2CychzRWU AoF81e/YhxCzYYqtBB9UPVkODgKCqOU0PDcagJ9zyRf22XeuZZNikLuDkOK8noAtGx h9IVjeqnC72EZW/imgisFkFaRGBVVgeeTEFy8loQ=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYTHCBIRNEAWMO3Y3V2ZSTAPEVBNHHBUAUCHA@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@github.com>
Subject: [quicwg/base-drafts] Retire My Own CID (#2645)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cbf7387bf445_5a973fc1b8ecd95c176163"; 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/vv-Qae_lJmMz8qWlAKy6Mi-ZbFM>
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, 23 Apr 2019 20:20:26 -0000

I think the protocol should allow for the originator of a CID to retire it and once that packet has been acknowledged by the peer, remove it from its lookup table.

I have a scenario where I want to move a connection from one "partition" to another "partition" on the same machine. I use some bits from the CID to indicate the partition ID. My problem is, I've already sent out a CID to the peer indicating the old partition ID. If I change, I'm going to get a cross-partition lookup perf-hit for the rest of time on this connection.

So, I'd like to be able to pick a new partition ID, generate a new CID and send out a NEW_CONN_ID and a RETIRE_CONN_ID for the old CID. Once the peer acknowledges this, I remove the old CID from my look up.

With this design, if I need to change partitions for any reason, I only pay a perf penalty for 1 or 2 RTT.

Another option instead of supporting RETIRE for my own, could be a REPLACE_CONN_ID [orignal_sequence_number]. That might be a little less disruptive for implementations to manage. Just copy over the old one with the new one and go about your business.

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