Re: [quicwg/base-drafts] Request to Retire Locally Issued CIDs (#2769)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -994,6 +994,14 @@ packets sent from only one local address.  An endpoint that migrates away from a
 local address SHOULD retire all connection IDs used on that address once it no
 longer plans to use that address.
 
+The endpoint can explicitly request its peer to retire connection IDs by sending
+a NEW_CONNECTION_ID frame that contains a Retire Prior To field.  The peer is
+required to retire these connection IDs in a timely manner.  On receipt of the
+acknowledgement for the packet that contained the NEW_CONNECTION_ID frame, the
+endpoint may start a 3 PTO timer, which on expiring may close the connection

MAY and MAY here

> @@ -4984,6 +4994,12 @@ Sequence Number:
 : The sequence number assigned to the connection ID by the sender.  See
   {{issue-cid}}.
 
+Retire Prior To:
+
+: A variable-length integer specifying the limit, for which all connection IDs
+  assigned to the receiver that have a sequence number less this value should be
+  retired.  See {{retiring-cids}}.  This field is only present for type=0x19.

This doesn't say anything about what to do with the connection ID that is negotiated during the handshake, and the one attached to a server preferred address.

> @@ -5018,10 +5034,16 @@ sequence number, or if a sequence number is used for different connection
 IDs, the endpoint MAY treat that receipt as a connection error of type
 PROTOCOL_VIOLATION.
 
+If the Retire Prior To field is present it is a request for the peer to
+immediately retire all connection IDs with a sequence number less than the
+specified value.  For more information see {{retiring-cids}}.  This field
+should only ever increase, though reordering and retransmission of older packets

There's lots of vague 2119-lite language here.  The language on flow control can be used here: 

> A receiver cannot renege on an advertisement however. That is, once a receiver advertises an offset, it MAY advertise a smaller offset, but this has no effect.
> [...]
> A sender MUST ignore any MAX_STREAM_DATA or MAX_DATA frames that do not increase flow control limits.

-- 
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/2769#pullrequestreview-245819379