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

[Eric Kinnear <[e-mail]>]

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