Re: [quicwg/base-drafts] Connection ID DT output (#1742)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> @@ -3257,6 +3287,49 @@ the Source Connection ID used by the peer during the initial
 handshake, it MUST treat that receipt as a connection error of type
 PROTOCOL_VIOLATION.
 
+## CONNECTION_ID_FINISHED Frame {#frame-connection-id-finished}
+
+An endpoint sends a CONNECTION_ID_FINISHED frame (type=0x1b) to indicate that it
+will no longer use a connection ID that was issued by its peer.  This also
+serves as a request to the peer to send additional connection IDs for future use
+(see {{connection-id}}).  New connection IDs can be delivered via the
+NEW_CONNECTION_ID frame ({{frame-new-connection-id}}).
+
+Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates any
+stateless reset tokens associated with that connection ID.

I think it's correct as written, actually, though we could make it more explicit if needed.  If a packet with the old CID was delayed and the recipient drops the CID immediately upon receipt, you'll get a SR that you ought to ignore.  So unless we're *also* adding a 3xRTO requirement on the server to continue accepting the retired CID, the sender needs to immediately stop recognizing the SRT associated with the CID.  You might miss a SR from an old packet if the race lands wrong.  But the packet being sent now has a new, still-valid CID and will presumably elicit a current SR of its own, so that's okay.

-- 
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/pull/1742#discussion_r217789739