Sending Media clarification

[TimEvens]

The draft currently indicates in two different sections how to send media. Reliable is via control channel/steam using FRAGMENT messages while unreliable are via DATAGRAM fragment messages.

It seems odd that sending reliable media is defined as a control message when it's a data stream and not control as the other messages are defined. Implementation of relays might benefit from having a different thread/event loop to process control messages instead of combining that with data (buffering/pacing/cc/...) processing. IMO, it would be more clear to define reliable and unreliable media sending/receiving under "Sending and Receiving Media".

It appears that FRAGMENT and DATAGRAM fragment messages are the published messages. These messages do not indicate published name anymore. Instead, they require state to be maintained using datagram_stream_id and assumed QUIC stream_id for reliable media streams. QUIC connections are hop-by-hop, resulting in the connection and stream IDs being locally significant. It is locally significant at least to the terminating server process and client. If there were two server processes, even behind the same IP (e.g., VIP), they could re-use the same connection/stream ids. datagram_stream_id is not indicated as being globally unique nor are there details for mapping and re-using QUIC stream_ids.

The PUBLISH_INTENT_OK message calls out that the server defines the datagram_stream_id, but nothing about reliable stream ids. It's unclear which server is the one that is defining that PUBLISH_INTENT_OK stream_id.

If stream ids are to be globally unique, then why not just use the published name in the fragment messages? Published names are globally unique and propagated to relays and subscribers.

It is unclear on the use of START_POINT and FIN messages.

START_POINT is indicated as optional and not used for media because media start is determined by group_id and object_Id being ZERO. This makes sense for media when media is conveyed via control FRAGMENTs and the stream ID defines the stream that starts and stops (FIN). How is this used for datagrams?

Both START_POINT and FIN messages do not have stream_id. As long as the they are sent via the same stream_id as fragments, then the QUIC stream_id can serve as the ID for the media stream that is starting or closing. In the case of datagram fragments, there is a datagram_stream_id that would need to be associated to the START_POINT and FIN messages. Even if both had stream_id, those are locally significant. Edge relays to subscribers would need to know which streams the START/FIN are associated to locally. How is that being done?