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

Nick Banks <notifications@github.com> Tue, 11 June 2019 18:55 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 9B1A0120152 for <quic-issues@ietfa.amsl.com>; Tue, 11 Jun 2019 11:55:10 -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_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 Pomp1StTh1fA for <quic-issues@ietfa.amsl.com>; Tue, 11 Jun 2019 11:55:08 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7860F120141 for <quic-issues@ietf.org>; Tue, 11 Jun 2019 11:55:08 -0700 (PDT)
Date: Tue, 11 Jun 2019 11:55:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560279307; bh=r6DIgIFh+KBiRb8LSEqyaMGX484bUYTbMy2oLmmQjPo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=vu9O6TWKf8EnZiLmR95HzrL84XFgn6pB4QGW3Ku3ATLM3q9y1/aYUy5LT2TVRE2Au eYRtuHUly4fuDPlnFHtWUb0pzhxto/IrYMOwsTd6SsjS8bjKvu45qu06hN5z6BIUQ3 h5+5vEJVF4PzNvS4nUsHXKdCqI/CRdL4ywTkDPKw=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3UIHCAGQD2YXTPNTF3BUVYXEVBNHHBUAUCHA@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/500976670@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_5cfff90b420e6_2c643f98a58cd96c18187c"; 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/fL55r0Rufu0S9KoS9UN4g5vTFuA>
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 18:55:10 -0000

@mikkelfj I think we're all agreed now that explicitly closing the connection is not the answer, because of the security concerns with a delayed packet. But a stateless reset doesn't have those security concerns. Receiving a stateless reset sent in response to a packet using the retired CID only effects the peer if they haven't actually retired the CID yet.

@ianswett STOP_SENDING isn't quite the same. When I send a STOP_SENDING frame, I've already made the decision to start dropping everything else I receive for that stream on the floor. So by the time the peer receives the frame, a whole flight of data might have been dropped. And we're all OK with that, because it doesn't effect the overall connection state.

That's definitely not the case with connection IDs. If I were to start dropping all packets with those retired CIDs first, then best case I lose an entire flight of packets. Much worse if my packet was lost as well.

In my scenario, I need to dump these CIDs right now, but the peer is still using them, so I need to give them some time to make the change. I keep the CIDs in my lookup/routing tables and send the frame out telling them to retire. Eventually they acknowledge the frame, so I know they got the new CIDs and the requirement to retire the old ones.

This is where we seem to start having differing views. I cannot allow a peer to go on forever using the CIDs I told them to retire. Continued usage of those CIDs is causing all kinds of performance issues, with cross processor locking/contention, for all connections on the effected processors. Since this scenario should be infrequent, I'm OK to accept the perf hit for a while, but eventually enough is enough. I want the text to be clear that if a peer doesn't switch CIDs, then the connection will go away eventually.

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