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

Eric Kinnear <notifications@github.com> Wed, 05 June 2019 17:21 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.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 D49B61201EC for <quic-issues@ietfa.amsl.com>; Wed, 5 Jun 2019 10:21:57 -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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, 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 gBwnrgRHdkVn for <quic-issues@ietfa.amsl.com>; Wed, 5 Jun 2019 10:21:55 -0700 (PDT)
Received: from o10.sgmail.github.com (o10.sgmail.github.com [167.89.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB671201ED for <quic-issues@ietf.org>; Wed, 5 Jun 2019 10:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=OstAey0RqrXyfS0EI1BDqWSNZYs=; b=PNZGMR3456gc8B3K OdoE0YY4o6B7TWym2GH5MbND28e2/G4L021TqR7WWSXNXwK8xUHgh6pw27haocsX MaPVJfUrQ1sWdNheOOanLOJcSaFJUFBOA0J2JEehDmIV8zRyrXiU30dv8lubYoH8 MkG2pQMexFivHwFqD2DpipjhPNU=
Received: by filter1736p1mdw1.sendgrid.net with SMTP id filter1736p1mdw1-8820-5CF7FA0E-76 2019-06-05 17:21:18.993313814 +0000 UTC m=+170814.934297659
Received: from github-lowworker-e55e3e3.cp1-iad.github.net (unknown [140.82.115.70]) by ismtpd0029p1iad2.sendgrid.net (SG) with ESMTP id T4fezSHhSpegsPjpxIez_w for <quic-issues@ietf.org>; Wed, 05 Jun 2019 17:21:19.001 +0000 (UTC)
Received: from github.com (localhost [127.0.0.1]) by github-lowworker-e55e3e3.cp1-iad.github.net (Postfix) with ESMTP id E5B2B1808CF for <quic-issues@ietf.org>; Wed, 5 Jun 2019 10:21:18 -0700 (PDT)
Date: Wed, 05 Jun 2019 17:21:19 +0000
From: Eric Kinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK34DZDUV4XHMYB7RDN3AUWI5EVBNHHBUAUCHA@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/499176700@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_5cf7fa0ee3693_5cf63f8f218cd968176761"; 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
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3aPWtopKva4jyfO0tV2fNNf7W9mBAvw5XQ38 S3g6rMpV25zleCqR8dD5XmuwJSQsD3t4gkrJzLIVP+MptvU4QFyLOWfFN4JLK/UF1RTnS/UB9UBBEM YGYv7wqSElA6E1JND/CGpqqV+2w2FvpFziEDK4IPOXslYHvrr54W8ys5wYCmkJBfrzBn330OvJA4W9 s=
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/htXQAJ6yPh0xMFPuSWA37FAgsHs>
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: Wed, 05 Jun 2019 17:21:58 -0000

Thanks for writing up #2769 @nibanks! 
I think either of the following two approaches could be a good path forward (discussing here rather than on the PR): 

1. The current PR, each new connection ID comes with a "retire CIDs before sequence number X", which keeps us from having issues around holes in the set of valid sequence numbers for a CID. 
This is kind of nice, because we can be a little looser with how we handle being at the max number of CIDs and needing to send some more/add new ones. 

Example: 
I want to retire all the CIDs that are outstanding. I've issued 1, 2, 3, 4 in NCID frames and we've got the handshake at 0. I send a single packet with: 
```
NCID(retireBefore: 1, CID: 5)
NCID(retireBefore: 2, CID: 6)
NCID(retireBefore: 3, CID: 7)
NCID(retireBefore: 4, CID: 8)
NCID(retireBefore: 5, CID: 9)
```
Note that sending `retireBefore: 5` for all could be specified as valid or invalid, although if valid it doesn't really help with requiring replacement. We'd also then want to consider writing a bunch of other somewhat messy text to require retiring them in order from oldest to newest, which seems somewhat icky.

2. A new frame for just the retire side, called something like `PLEASE_RETIRE_CONNECTION_ID`. 
- This would be a request, and an endpoint receiving it SHOULD retire immediately, along with a warning that the other endpoint may choose to close the connection if it doesn't. 
- The endpoint also SHOULD move to a new CID if the one it's currently using is requested to be retired.
- It's probably worth being a little bit careful about how strongly we make not moving a protocol violation, because it seems like it wouldn't be too difficult for an endpoint whose peer had to migrate off the one it was currently using to end up receiving packets from the old CID for a good while/draining period.

If we do (2), in order to have the guarantee that they're replaced, we should just include that all `PLEASE_RETIRE_CONNECTION_ID` frames MUST also be accompanied by a `NEW_CONNECTION_ID` frame, and have the receiver close the connection if that's not the case. (Timing/[not] keeping things in the same packet strikes me as a part of the text here that needs to be written carefully.)


Same example from above: 
```
PRCID(retireAllBefore: 5)
NCID(5)
NCID(6)
NCID(7)
NCID(8)
NCID(9) 
```

In my mind, the common text between both approaches is: 
- The endpoint being asked to retire CIDs SHOULD retire them immediately, and move to a new CID if necessary. If not, the other end MAY close the connection (plus note about not being *too* aggressive here to handle draining).
- The endpoint asking to retire them MUST replace them. If not, the other end closes.
- How we handle "bad" sequence numbers being sent (too low, also a little weird to send a number higher than the peer's limit away from what's active).
- How you handle when you're at the max specified by the peer's limit
- Any preferred address and handshake CIDs should probably explicitly be called out as affected, although they do have sequence numbers
- If someone requests to retire CIDs that you haven't seen yet, you respond to `NEW_CONNECTION_ID` frames containing them by immediately retiring them. This doesn't add too much state since you just need to keep a single counter of the highest invalid/lowest valid sequence number.

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