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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

Yeah, this is a little tricky.

> @@ -1834,7 +1834,12 @@ new connection IDs using the NEW_CONNECTION_ID frame.
 An endpoint might need to send packets on multiple networks without receiving
 any response from its peer.  To ensure that the endpoint is not linkable across
 each of these changes, a new connection ID is needed for each network.  To
-support this, multiple NEW_CONNECTION_ID messages are needed.
+support this, multiple NEW_CONNECTION_ID messages are needed.  Each
+NEW_CONNECTION_ID is marked with a sequence number.  Connection IDs MUST be used
+on only one local address, and each local address MUST advance to a connection

Perhaps
... on only one local address.  An endpoint MUST use a connection ID with a higher sequence number if it changes to using a different local address or network interface.  Once an endpoint has used a connection ID for packets sent from a given local address, they MUST NOT use a connection ID with a lower sequence number with that address.

> @@ -2613,6 +2627,14 @@ The NEW_CONNECTION_ID is as follows:
 
 The fields are:
 
+Sequence:
+
+: A variable-length integer.  This value starts at 0 and increases by 1 for each
+  connection ID that is provided by the server.  The connection ID that is
+  assigned during the handshake is assumed to have a sequence of -1.  That is,

There can be very many connection IDs during the handshake with this new Retry packet, so it's all special casing here.  Start at 2^16-N if you feel compelled to track things this way.

>  endpoint MUST NOT send additional packets until a NEW_CONNECTION_ID frame is
-received.
+received.  However, an implementation need not stop sending packets due to a gap
+in sequence numbers; it simply advances to the next currently-available
+connection ID it has received.  Connection IDs with earlier sequence numbers
+which arrive later MAY be retained for use on other local addresses or
+discarded.

OMG wall of text :)

When this happens, it's probably cause to create a new section.

FWIW, I like the idea that once you use a connection ID on a given interface, you can't use a lower-numbered one.  That could extend to responses.  Once you see a connection ID on a given tuple, then you can't use a lower-numbered one.  That leads to some simple rules:

When you use a new interface/address you MUST use of a new connection ID.
When you use a new connection ID, you MUST use one with a higher sequence number than you have ever used before.
You MUST NOT use a connection ID with a lower sequence number than you have either sent or received on that path.

Formulating the text around that is what we need.

> @@ -1834,7 +1834,12 @@ new connection IDs using the NEW_CONNECTION_ID frame.
 An endpoint might need to send packets on multiple networks without receiving
 any response from its peer.  To ensure that the endpoint is not linkable across
 each of these changes, a new connection ID is needed for each network.  To
-support this, multiple NEW_CONNECTION_ID messages are needed.
+support this, multiple NEW_CONNECTION_ID messages are needed.  Each
+NEW_CONNECTION_ID is marked with a sequence number.  Connection IDs MUST be used
+on only one local address, and each local address MUST advance to a connection

Or, create a new section on connection ID use along the lines I describe below and cite that instead.

-- 
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#pullrequestreview-131035960