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

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.

Obviously, I think that this is a good balance of the concerns, because I was involved with the decision.  I do have some editorial concerns that.

I'm willing to help address these. I suggest that we start with a round of discussion, during which we might decide to split off some new issues.

> +
+
+### 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 think that 8 is the right recommendation, but we should contextualize it more.  The primary consideration being that it is important to support a number of failed connection migrations on the way to a successful migration.

That context is later, so I think we should just move this recommendation.

> +({{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.

It's not always the case that use of an existing path implies linkability.  Though it might be a strong signal, if I'm behind a NAT with a large number of other people, I can imagine the NAT being used as an mixing point.  Changing connection ID in that context might re-establish anonymity within that set.  Especially if the NAT understands connection IDs and I am able to use one for packets I receive as well.  In many cases we think about, the NAT is small and the value of re-mixing low, but you can imagine building that sort of aggregator for privacy purposes.

> +({{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.

A recent PR highlighted the risks associated with that.  That text now belongs here.  See [this caution](https://github.com/quicwg/base-drafts/commit/17ccc69ecd0c652bc8f35c5db5fb3a37b0f7c67c#diff-db016291106766877c4921a79f8596e0R2380), which suggests that this change adds duplicated text...

> +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.
+
+
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no

I don't like this name (never have).  But until I read this text again and saw it use "retire", I didn't have an alternative I liked enough to suggest.  RETIRE_CONNECTION_ID is better (not awesome, but certainly better).

Yes, that's opinion.  Also, don't bother changing it.  I am prepared to do that.

> +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.
+
+
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no
+longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.

from "and serves as a request ..." is a new concept and doesn't belong to this paragraph.  It needs a new paragraph explaining things more fully.

Rather than frame this as an implicit request, I would say that you address the text at the endpoint that issues the connection IDs.  That is, rely on the text in the previous section and don't mention that function here at all.

> +
+
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no
+longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.
+
+An endpoint that retires a connection ID should retain knowledge of that
+connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED

s/reasonable time/period/

I think we can leave the use of the word "reasonable" to lawyers.  It implies judgment.

> +
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no
+longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.
+
+An endpoint that retires a connection ID should retain knowledge of that
+connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED
+frame, or until that frame is acknowledged.  A recommended time is three times

The acknowledgment point here is a tricky one.  The risk you describe is that a retransmission of NEW_CONNECTION_ID(X) arrives after RETIRE_CONNECTION_ID(X) is sent, which makes it appear as though X is a wholly new connection ID.  If it is then used, it might trigger stateless reset.  Defense against that is to wait for the ACK of the ACK for NEW_CONNECTION_ID, or to start the timer from when NEW_CONNECTION_ID is received, not when RETIRE_CONNECTION_ID is sent.

However, based on comments below, I think that we should recommend retention of the connection ID at the peer that uses it for 3xRTO as well and NOT short that timer when the RETIRE_CONNECTION_ID frame is acknowledged.  The reason for that is not use of the ID (that should have stopped before sending the frame), but acceptance of the stateless reset.  Packets in flight before the connection ID is retired might generate a stateless reset.

The risk I'm more concerned about is the receipt of delayed packets with X after RETIRE_CONNECTION_ID(X) is *received*.  In which case the recipient of RETIRE_CONNECTION_ID needs to remember X and not generate a stateless reset for some period.

That keeps it simple: remember a connection ID (and its associated reset token) from the time of sending or receiving RETIRE_CONNECTION_ID plus 3xRTO.

> +longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.
+
+An endpoint that retires a connection ID should retain knowledge of that
+connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED
+frame, or until that frame is acknowledged.  A recommended time is three times
+the current Retransmission Timeout (RTO) interval as defined in
+{{QUIC-RECOVERY}}.  This prevents potential retransmissions of a
+NEW_CONNECTION_ID frame from overlapping with the CONNECTION_ID_FINISHED frame
+for the same connection ID.
+
+Additionally, each connection ID MUST be used on packets sent from only one
+local address.  At any time, an endpoint MAY change to a new connection ID on a
+local address already in use.  An endpoint that migrates to a new local address
+SHOULD retire all connection IDs that were used on the previous address
+using the CONNECTION_ID_FINISHED frame.

This isn't quite right.  The point here is that you should retire connection IDs when you stop using the path, not when you move to a new one.  This text doesn't set us up very well for multipath, for instance.  

Also, an endpoint might decide to retain the connection ID for a period in case it has to switch back.  Think about a mobile device that hits a wifi access point.  It might keep the connection ID it used on the cellular path for a time in case it remains mobile.  Switching connection ID on each network change might be better, but maybe only if significant time passes.

> @@ -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.

This implies that there are multiple tokens.

"Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates the stateless reset token associated with that connection ID."

> @@ -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.

As an open issue, we should decide how long to allow the old token to be effective.  I would suggest that we use the same 3xRTO timer for that as well.  Then we have 3xRTO everywhere in this.

> +|   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

Yeah, @mikkelfj got it.  You can retire a connection ID before NEW_CONNECTION_ID is acknowledged even.

As for the short connection IDs, I think that's a reason not to allow shorter values more than an argument against this text.  Yes, over time, you might cycle really old IDs back into circulation such that they get re-issued to a connection that had it in the past.  That would be valid, but allowing it would complicate the protocol.  The protocol here uses the connection ID as its own identifier, so for that to work properly, we need it to be unique.

> +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
+PROTOCOL_VIOLATION.
+
+An endpoint MUST NOT send this frame if it is currently sending packets with a
+zero-length Destination Connection ID.  Changing the length of a connection ID

It cannot send this frame because it won't have any connection IDs to put in it.  I think that we can shorten this paragraph to: "An endpoint cannot send this frame if it was provided with a zero-length connection ID by its peer.  An endpoint that provides a zero-length connection ID MUST treat receipt [...]"

> +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
+PROTOCOL_VIOLATION.
+
+An endpoint MUST NOT send this frame if it is currently sending packets with a
+zero-length Destination Connection ID.  Changing the length of a connection ID
+to or from zero-length makes it difficult to identify when the value of the
+connection ID changed.  An endpoint that is receiving packets with a zero-length
+Destination Connection ID MUST treat receipt of a CONNECTION_ID_FINISHED frame
+as a connection error of type PROTOCOL_VIOLATION.
+
+

We want to point out, purely for the purpose of completeness, that the connection ID provided during the handshake can be retired with this frame.

> +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.
+
+When an endpoint issues a connection ID, it MUST accept packets using this
+connection ID for the duration of the connection or until its peer invalidates
+the connection ID via a CONNECTION_ID_FINISHED frame
+({{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

s/can choose to/can/

-- 
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-154889508