Fix a race condition cause by out of band signaling #212
Conversation
| @@ -518,7 +518,20 @@ the same flow identifier (following the procedures defined in {{?RFC5761}}), or | |||
| they can use different flow identifiers. | |||
|
|
|||
There was a problem hiding this comment.
My comments below assume that buffering RoQ streams and RoQ datagrams carrying real-time RTP payloads is the Right Thing To Do. We can talk about whether that's desirable, because buffering real-time RTP will cause the RTP session to start out with an overestimated RTT and will introduce jitter as the RTP sender responds to the actual RTT after the RTP receiver starts to provide feedback, but we should at least think about that, because RTP is designed to tolerate packet loss, so admitting a burst of RTP packets to an application when the receiver finally knows what to do with the flow identifier might not be our best option.
My comments also assume that some RoQ receivers might buffer RoQ streams and datagrams while signaling completes, and others might not, so I introduced "buffering endpoint", to make that distinction.
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| @@ -518,7 +518,20 @@ the same flow identifier (following the procedures defined in {{?RFC5761}}), or | |||
| they can use different flow identifiers. | |||
|
|
|||
| The association between flow identifiers and RTP streams MUST be negotiated | |||
| using appropriate signaling. If a receiver cannot associate a flow identifier | |||
| using appropriate signaling. The signaling happens out of band and thus a stream | |||
| or datagram with a given flow identifer may arrive before the signaling | |||
There was a problem hiding this comment.
| or datagram with a given flow identifer may arrive before the signaling | |
| or datagram with a given flow identifier can arrive before the signaling |
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| using appropriate signaling. If a receiver cannot associate a flow identifier | ||
| using appropriate signaling. The signaling happens out of band and thus a stream | ||
| or datagram with a given flow identifer may arrive before the signaling | ||
| finished. In that case, an endpoint may not be able to associate the stream or |
There was a problem hiding this comment.
| finished. In that case, an endpoint may not be able to associate the stream or | |
| finished. In that case, an endpoint cannot associate the stream or |
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| using appropriate signaling. The signaling happens out of band and thus a stream | ||
| or datagram with a given flow identifer may arrive before the signaling | ||
| finished. In that case, an endpoint may not be able to associate the stream or | ||
| datagram with the corresponding RTP stream. The endpoint SHOULD buffer streams |
There was a problem hiding this comment.
| datagram with the corresponding RTP stream. The endpoint SHOULD buffer streams | |
| datagram with the corresponding RTP stream. The endpoint can buffer streams |
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| finished. In that case, an endpoint may not be able to associate the stream or | ||
| datagram with the corresponding RTP stream. The endpoint SHOULD buffer streams | ||
| and datagrams using an unknown flow identifier until they can be associated with | ||
| the corresponding RTP stream. To avoid resource exhaustion, the endpoint SHOULD |
There was a problem hiding this comment.
| the corresponding RTP stream. To avoid resource exhaustion, the endpoint SHOULD | |
| the corresponding RTP stream. To avoid resource exhaustion, the buffering endpoint MUST |
For this to be a normative SHOULD, we should have some situation in mind where it makes sense for a receiver to buffer streams and datagrams without setting a limit. Do we have such a situation in mind?
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| and datagrams using an unknown flow identifier until they can be associated with | ||
| the corresponding RTP stream. To avoid resource exhaustion, the endpoint SHOULD | ||
| limit the number of streams and datagrams to buffer. If the number of buffered | ||
| streams exceeds the limit, the endpoint SHOULD send a STOP_SENDING with the |
There was a problem hiding this comment.
| streams exceeds the limit, the endpoint SHOULD send a STOP_SENDING with the | |
| streams exceeds the limit on buffered streams, the endpoint MUST send a STOP_SENDING with the |
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| limit the number of streams and datagrams to buffer. If the number of buffered | ||
| streams exceeds the limit, the endpoint SHOULD send a STOP_SENDING with the | ||
| error code ROQ_UNKNOWN_FLOW_ID. It is an implementation's choice on which stream | ||
| to send STOP_SENDING. If the number of buffered datagrams exceeds the limit, the |
There was a problem hiding this comment.
| to send STOP_SENDING. If the number of buffered datagrams exceeds the limit, the | |
| to send STOP_SENDING. If the number of buffered datagrams exceeds the limit on buffered datagrams, the |
draft-ietf-avtcore-rtp-over-quic.md
Outdated
| streams exceeds the limit, the endpoint SHOULD send a STOP_SENDING with the | ||
| error code ROQ_UNKNOWN_FLOW_ID. It is an implementation's choice on which stream | ||
| to send STOP_SENDING. If the number of buffered datagrams exceeds the limit, the | ||
| endpoint SHOULD drop a datagram. It is an implementation's choice which datagram |
There was a problem hiding this comment.
| endpoint SHOULD drop a datagram. It is an implementation's choice which datagram | |
| endpoint MUST drop a datagram. It is an implementation's choice which datagram |
mengelbart
force-pushed
the
fix/unknown-flow-id-race-condition
branch
2 times, most recently
from
669407a
to
6197bf2
Compare
Signaling flow IDs may happen out of band and cause a race condition when flow IDs are received before signaling is complete.
mengelbart
force-pushed
the
fix/unknown-flow-id-race-condition
branch
from
6197bf2
to
0ad8e29
Compare
I think I introduced some new ones in this PR. I updated it and also applied the other suggestions you made. |
Signaling flow IDs may happen out-of-band and cause a race condition when flow IDs are received before signaling is complete.
The solution is modeled after WebTransport's handling of incoming streams and datagrams described in https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3-09#section-4.5