IETF Logo Mail Archive

Re: [quicwg/base-drafts] Connection ID Garbage Collection (#1729)

Christian Huitema <notifications@github.com> Tue, 11 September 2018 02:36 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 A8AA713104C for <quic-issues@ietfa.amsl.com>; Mon, 10 Sep 2018 19:36:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 Dfd4p7b4qj5F for <quic-issues@ietfa.amsl.com>; Mon, 10 Sep 2018 19:36:30 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B26131052 for <quic-issues@ietf.org>; Mon, 10 Sep 2018 19:36:23 -0700 (PDT)
Date: Mon, 10 Sep 2018 19:36:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1536633382; bh=xjjd2QL4yfKIZIpCDHJ1NgjeOMBioieAdnloyO2NbZM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=dnpa8gfv5S0oIR1a0CHHQwBVuvzW8E/vpT8a/t8GtzDxxOpktFEhJINscUlYv0x1k FL1gJYTUUgs7iuy8JzhtYbPXPqeiiCRHon29UgJ57ti7EWOXAdIb7C8xi6ri7qkMTn OUwDGWj92uc4uqVCIPiaFDAANYkovqikqBGMPJWs=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab6f7e392a34619ad03ecea0dcf0cf1e09db85f76992cf0000000117aeec2592a169ce155ca63e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1729/420126670@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1729@github.com>
References: <quicwg/base-drafts/issues/1729@github.com>
Subject: Re: [quicwg/base-drafts] Connection ID Garbage Collection (#1729)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b972a258389a_550a3fd164cd45b88198f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/e9YAFw0bVOugVQszqjhOoXJrZGs>
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 Sep 2018 02:36:32 -0000

@erickinnear Yes. I would like to keep it very simple: just say "I have burned this connection ID", without specifying how and why. Then, the peer can do its own accounting of how many connection ID are outstanding, etc.

There is a parallel issue, how does a node delete a path? How does it say that "I used to send packets with sourceCID=X and destCID = Y, but I am not going to send anymore packets to destCID=Y, and I would like you to stop sending anything to the CID=X" ?

And yet another complication. Suppose that a node actually removes all resource attached to that old path. That would include the capability to send a packet to CID=X in the example above. Now suppose that despite timers and best efforts an errant packet arrives after that deletion. Since X cannot be routed, this is going to trigger a stateless reset. Does this reset cause the entire connection to crash?

-- 
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/1729#issuecomment-420126670

v2.23.0 | Report a Bug | By Email