Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove signaling dependency #222

Merged
merged 1 commit into from
Jun 21, 2024
+28 −13
Merged

Remove signaling dependency #222

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 28 additions & 13 deletions draft-ietf-avtcore-rtp-over-quic.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -536,19 +536,34 @@ different flow identifiers. RTP and RTCP packets of a single RTP session can use
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. The signaling happens out of band and thus a stream
or DATAGRAM with a given flow identifer can arrive before the signaling
finished. In that case, an endpoint cannot associate the stream or DATAGRAM with
the corresponding RTP stream. The endpoint can buffer streams and DATAGRAMs
using an unknown flow identifier until they can be associated with the
corresponding RTP stream. To avoid resource exhaustion, the buffering endpoint
MUST limit the number of streams and DATAGRAMs to buffer. If the number of
buffered streams exceeds the limit on buffered streams, the endpoint MUST 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 on buffered DATAGRAMs, the endpoint MUST drop a DATAGRAMs. It
is an implementation's choice which DATAGRAMs to drop.
Endpoints need to associate flow identifiers with RTP streams. Depending on the
context of the application, the association can be statically configured,
signaled using an out-of-band signaling mechanism (e.g., SDP), or applications
might be able to identify the stream based on the RTP packets sent on the stream
(e.g., by inspecting the payload type).

If an endpoint receives a flow identifier that it cannot associate with an RTP
stream, the endpoint MAY close the connection using the ROQ_UNKNOWN_FLOW_ID
error code. Closing the connection can be a valid response if it is not expected
that out of band signaling is still ongoing and the application cannot handle
unknown flow identifiers.

If the association of flow identifiers with RTP streams depends on out-of-band
signaling, the signaling mechanism SHOULD be completed before the exchange of
RTP packets using the new flow identifiers starts.

In cases where it cannot be guaranteed that signaling is completed before RTP
packets are transmitted, streams or DATAGRAMs with a given flow identifer can
arrive before the signaling finished. In that case, an endpoint cannot associate
the stream or DATAGRAM with the corresponding RTP stream. The endpoint can
buffer streams and DATAGRAMs using an unknown flow identifier until they can be
Comment on lines +558 to +559
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use the correct RFC 2119 wording here:

Suggested change
the stream or DATAGRAM with the corresponding RTP stream. The endpoint can
buffer streams and DATAGRAMs using an unknown flow identifier until they can be
the stream or DATAGRAM with the corresponding RTP stream. The endpoint MAY
buffer streams and DATAGRAMs using an unknown flow identifier until they can be

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used non-RFC 2119 language here because it is nothing that a peer needs to be prepared for. Some time ago, we removed a lot of SHOULDs and some MAYs so I would like to avoid adding more new ones unless it is necessary. @SpencerDawkins and @joerg-ott, what do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with Mathis. This paragraph gives implementation guidance that does not affect normative protocol behavior. The actions are of local significance only.

Copy link
Collaborator

@SpencerDawkins SpencerDawkins Jun 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Warning, I'm a retired AD and still a BCP14 pedant ...

What @mengelbart and @joerg-ott are describing is a bunch of changes that we made based on my previous comments (trying to limit the use of BCP14 language to an absolute minimum), for two reasons.

  • As noted, the point of BCP14 language is to describe what a receiver MUST be prepared to deal with, and that includes when a sender does something besides what it SHOULD do. That's the difference between SHOULD and MAY - we are supposed to analyze the reasons behind a SHOULD, and the actions a receiver ought to take if the sender doesn't do that.

For some reason, RFC2119 also included MAY/OPTIONAL, which doesn't have much to do with interoperation (I can't remember which AD I'm paraphrasing, but "an implementation MAY do a LOT of things that a receiver has to deal with, and saying that using BCP14 language isn't helpful".

  • In the specific case of this draft, we're targeting Experimental, with a planned advance to Standards Track when we have more implementation (and perhaps even deployment) experience. We tried to minimize the use of normative language, just to focus on the bare minimum that an implementation needs to be prepared to deal with.

If a receiver buffers at least some media with surprising flow IDs, but doesn't buffer all media with surprising flow IDs for ever, the RTP sender probably can't figure that out. The receiving user can tell that, of course, but that's what we're trying to provide a warning about.

If we do create an issue about surprises for readers, the way we're using BCP14 language should probably be included in that list!

associated with the corresponding RTP stream. To avoid resource exhaustion, the
buffering endpoint MUST limit the number of streams and DATAGRAMs to buffer. If
the number of buffered streams exceeds the limit on buffered streams, the
endpoint MUST 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 on buffered DATAGRAMs, the endpoint MUST
drop a DATAGRAM. It is an implementation's choice which DATAGRAMs to drop.

Flow identifiers introduce some overhead in addition to the header overhead of
RTP and QUIC. QUIC variable-length integers require between one and eight
Expand Down
Loading