Are end-of-group messages mandatory?

[afrind]

429 introduced the Status field for Objects, which can have a value that signals the end of a group (0x3).

The draft states:

This is sent right after the last object in the group.

I read this to mean that whenever a publisher publishes the last object in a group, it also publishes the end-of-group marker (eg: it is mandatory). However, it seems like this might create high overhead - eg in an audio only track where every sample is its own group.

For a fanout relay handling group-per-stream tracks, the end of group marker is a signal that it can close the downstream streams. Yes, the relay needs a timeout as well, to catch malicious or buggy producers, but I'd prefer that be the rare, and proactively clean up the state since it could be quite large.

The other modes seem less critical for a relay, I think? However, I worry about interoperability between producers and consumers if we don't make it required in other stream modes. That could be part of a streaming format specification rather than the core transport.

Given that datagrams are inherently unreliable, I don't know that we need to mandate end-of-group markers there.

[ianswett]

I think the cleanest option is to require them and make them mandatory, unless something like an OBJECTS_DROPPED message is sent. We can make the wire encoding very efficient as long as the producer knows that an Object is the final Object in a group when it's published.

I think end of track is equally important, but there are no efficiency concerns there.

[fluffy]

I don't think even know what saying they are mandatory would even mean at the transport level. Can a producer wait forever before sending the end of group ? Can anyone else rely on receiving the end of group with a given window ? what would break if not sent.

I do see how a something like loc or warp would say how they have to be used but transport seems like the wrong level to say if they are used or not. If sending end of group increase the bandwidth of low bit rate audio by a non trivial amount, then I dont think they will be used in cases where the applications know that there is only one audio packet per group.

[afrind]

Individual Comment:

I don't think even know what saying they are mandatory would even mean at the transport level. Can a producer wait forever before sending the end of group ? Can anyone else rely on receiving the end of group with a given window ? what would break if not sent.

See the original post:

For a fanout relay handling group-per-stream tracks, the end of group marker is a signal that it can close the downstream streams. Yes, the relay needs a timeout as well, to catch malicious or buggy producers, but I'd prefer that be the rare, and proactively clean up the state since it could be quite large.

Could we have "publishers SHOULD send end-of-group markers when using group-per-stream", with text explaining why this is helpful for relay state management?

I'm assuming audio is datagrams so it's not impacted. Knowing the end of group in stream-per-track is obvious (the group number changes). In stream-per-object it might be useful to the receiver but I'm not sure it's critical at the relay right now, though a use case may emerge as we move forward.

[fluffy]

I guess the part I am missing is what does the relay do with this information and how it is useful.

[afrind]

I guess the part I am missing is what does the relay do with this information and how it is useful.

Assume a fan-out relay with one publishing track fanning out to 1 million subscribers.

publisher opens a stream for group 0, sends objects 0 relay opens a stream for each of 1 million downstream subscribers and pushes object 0 publisher sends a FIN for its group stream

Should the relay close the 1 million downstream streams now?

If the publisher sends the end-of-group marker, it is explicit that the relay can close these streams immediately (there is also a timer-based cleanup path for publisher crashes etc). I don't think we should infer end-of-group from QUIC FIN - I imagine there may be some high availability scenarios where a redundant publisher could take over, and hence prefer an explicit signal. I doubt the overhead of the end-of-group marker will make a difference in this scenario -- it's a handful of bytes that will either go in the packet with the final object or the packet that had the FIN.

[fluffy]

Just want to say that I find Alan's point above really convincing. However, this does make me want to have a very low bandwidth impact way to solve this. I also am wondering if better way of managing streams is just close ones that have not been used recently. I think we need some more thought on how relays close streams.