Re: [quicwg/base-drafts] Restore CID sequence numbers (#1465)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.



> +selected during the handshake coming first.  Additional connection IDs are
+provided using the NEW_CONNECTION_ID frame ({{frame-new-connection-id}}), each
+with a specified sequence number.  The series of connection IDs issued SHOULD be
+contiguous, but might not appear to be upon receipt due to reordering or loss.
+
+Each connection ID MUST be used on only one local address. When packets are sent
+for the first time on a new local address, a new connection ID MUST be used with
+a higher sequence number than any connection ID previously used on any local
+address.  At any time, an endpoint MAY change to a new connection ID on a local
+address already in use.
+
+An endpoint MUST NOT send packets with a connection ID which has a lower
+sequence number than the highest sequence number of any connection ID ever sent
+or received on that local address.
+
+Implementations SHOULD ensure that peers have a connection ID with a matching

But the trade-off is that lost packets can cause a peer to appear to violate this temporarily, so it's not realistically enforceable by a peer.  You can't "MUST ensure" something has arrived on the other side, only detect whether it has or not.  And the connection doesn't actually break; the peer will have to advance to a higher-order CID, which will force the endpoint to move off of the one that doesn't have a match (assuming it still hasn't arrived).

Actually, what a smart implementation could do is to bundle the NEW_CONNECTION_ID frame with the corresponding CID in every packet between when it changes to a new CID until *something* gets ACK'd.

-- 
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/1465#discussion_r198244528