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

[Rui Paulo <[e-mail]>]

rpaulo commented on this pull request.



> +|   Length (8)  |          Connection ID (32..144)            ...
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+The fields are:
+
+Length:
+
+: An 8-bit unsigned integer containing the length of the connection ID.
+
+Connection ID:
+
+: A connection ID of the specified length.
+
+Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was
+not previously sent to the peer MAY be treated as a connection error of type

I'm not sure how this works with packet loss / reordering.  If a new CID is retired shortly after it is issued, this problem will happen and I suppose that's why you wrote 'MAY' and not 'SHOULD'.
Can't we require implementations to wait for an ACK of the NEW_CONNECTION_ID before issuing a CONNECTION_ID_FINISHED?

> +
+
+### Issuing Connection IDs
+
+An endpoint issues connection IDs to its peer for the peer to use when sending
+packets. This allows the endpoint control over the strategy used to interpret
+connection IDs of packets that it receives.  These connection IDs are
+communicated to the peer using NEW_CONNECTION_ID frames
+({{frame-new-connection-id}}).
+
+The initial connection ID issued to the peer is sent by the endpoint as the
+Source Connection ID during the handshake, ensuring that the peer always begins
+the connection with at least one connection ID to use when sending.  An endpoint
+SHOULD supply its peer with additional connection IDs via NEW_CONNECTION_ID
+frames. While each endpoint can choose how many connection IDs to issue, a
+recommended number of outstanding connection IDs is eight.

I wonder if recommending a specific number is helpful.  Do we have any operation experience about suggesting 8?

> +({{frame-connection-id-finished}}).
+
+Implementations SHOULD ensure that peers have sufficient connection IDs
+available to reduce the possibility of peers exhausting their supply of
+available connection IDs.  An implementation could do this by always supplying a
+new connection ID for each connection ID retired with a CONNECTION_ID_FINISHED
+frame. When a receiver of a packet notices that its peer is now using a
+previously unused connection ID, it can choose to supply its peer with a new
+connection ID using a NEW_CONNECTION_ID frame to reduce the possibility of its
+peer running out of available connection IDs.
+
+An endpoint that receives a packet with a different remote address than
+previously used SHOULD also switch to sending with a different connection ID.
+This can help to ensure that different connection IDs will be used in both
+directions when an endpoint migrates to a new path or changes connection ID on
+an existing path.

I guess the problem is that this paragraph implies the remote peer did not change CID but the address changed (perhaps NAT binding).  If we switch CIDs, does it really require the remote end to switch CIDs?  The likability problem is still there, I think.

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