Re: [quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)

Eric Kinnear <notifications@github.com> Thu, 19 March 2020 23:45 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 95C443A1276 for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 16:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixozwMStCyr0 for <quic-issues@ietfa.amsl.com>; Thu, 19 Mar 2020 16:45:22 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C8E3A12AF for <quic-issues@ietf.org>; Thu, 19 Mar 2020 16:45:21 -0700 (PDT)
Received: from github-lowworker-28f8021.ac4-iad.github.net (github-lowworker-28f8021.ac4-iad.github.net [10.52.25.98]) by smtp.github.com (Postfix) with ESMTP id 04E7B1C068F for <quic-issues@ietf.org>; Thu, 19 Mar 2020 16:45:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584661520; bh=0TcDtUjVp9lr2uMCT+4mC3MAPLMU+7xit57ddR1fS5c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=D0ADDkKZVu8xUWukuD3gybewxHWbAbTvFs+ooh5Yz2ACRu4Q3z4ERsbrQxJfEatW/ ZbWM5NiC9/RcQEuBd925mpV5W3T5rOun2J7x5UBrPMvmZvKmtXxJQd9OhPAsbbaMXB thxaU+gRSLWVXdRXYJvCU9jXjT5O3KKFtLXxwwtM=
Date: Thu, 19 Mar 2020 16:45:19 -0700
From: Eric Kinnear <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYVAYJJ266HINEZQTV4P7SQ7EVBNHHCFWJJQQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3534/601466583@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3534@github.com>
References: <quicwg/base-drafts/issues/3534@github.com>
Subject: Re: [quicwg/base-drafts] NEW_CONNECTION_ID text is too restrictive on receivers (#3534)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e74040fea723_31053f8a0e2cd968687aa"; 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/xBSKe3iGe2vn-Fn8FIyeOfLN1Vk>
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, 19 Mar 2020 23:45:31 -0000

Taking a look at the PR, I'm finding the proposed text to be a bit unclear, too. 

Based on the discussion on the list, this seems to be a misreading of the text itself. 
>From the list:
> I MUST send RCID for everything below retire-prior-to, whether or not I've seen the NCID for it.

I don't believe that this is actually what the text says. The text says: 
```
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number 
smaller than the Retire Prior To field of a previously received NEW_CONNECTION_ID 
frame MUST immediately send a corresponding RETIRE_CONNECTION_ID frame 
that retires the newly received connection ID. 
```

This to me reads as "If you said everything below CID 10 is done, and then you send me CID 8, I must immediately send a RCID frame for 8 since I can't use it". 

>  CID handling that doesn't require potentially large amounts of state to keep track of long-retired CIDs

> If the receiver has already sent an RCID frame for the sequence number and that RCID has been acked, it may have thrown away state for that sequence number and shouldn't have to resend a frame the peer has received. In particular, a buggy or malicious peer might send a very old sequence number, or the NCID receiver might have preemptively retired a sequence number it hadn't seen when it got the retire-prior-to field.

I don't believe that there is any CID-specific state required at all for this. You do need to store the current highest value that you've ever seen for RPT, which is a single integer, I'll call it `currentRPT`. 

Beyond that, when you get a NCID frame, you check the sequence number. If it's less than `currentRPT`, you should immediately *enqueue* (which I think might be a reasonable wording change to make, since immediately seems to have caused concern when the intent was that you put it on the tracks leaving the station, not that you force the train out the door before it's allowed) a RCID frame for that sequence number. 

Note that a RCID frame contains a single value, the sequence number of the connection ID being retired, which incidentally is contained by the NCID frame you're responding to. 

We can argue as to whether or not you should bother to send RCID again when the same frame has been acked, but (a) storing that is actually _more_ state and (b) we're working pretty hard to avoid tracking ACKs of packets.

I might be missing something here -- can you help me understand the concern about storing state in order to meet the requirements of this text?

-- 
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/3534#issuecomment-601466583