search

moq-wg / moq-transport

draft-ietf-moq-transport
Other
87 stars 22 forks source link

Simplify SUBSCRIBE as a follow-up to FETCH #510

Closed ianswett closed 4 weeks ago

ianswett commented 2 months ago

This is another effort at the SUBSCRIBE vs FETCH concept.

I've reduced the number of modes for SUBSCRIBE to 3, and only one of them subscribes to Objects in the future.

I removed Latest Group because the other two modes operate on the latest Object and I wasn't sure how practical it is to expect every relay to cache all of the latest group. And if they don't, implementations get complex.

This is an opinionated approach, but it has quite a bit of flexibility now that the new priority design has landed. In particular, it gives the subscriber lots of control over what order Objects on either side of the live head are delivered.

Fixes #368 Could be extended to fix #350

wilaw commented 2 months ago

This PR does not simplify subscription for non-real-time live stream clients (i.e live sports). These players need a variable buffer before start-up. To achieve this, they need to request several groups behind latest and then all future groups. The suggestion in the PR is for these clients to "it can send a SUBSCRIBE for the Latest Object followed by a SUBSCRIBE of type AbsoluteStart or AbsoluteRange.". The trouble with this is that it complicates the player's handling of the received data. It must first make a request for Latest Object. This will give it the latest and future objects and data will begin to flow immediately after it makes this request. However the player cannot place this data in a decode buffer. It must store it in a temporary buffer and hold it. Based the info it receives in the SUBSCRIBE_OK, it can then make a second request for the absolute range preceding this latest object. That data it can place it its decode buffer and begin decoding and it must then continuously copy data from the first receive buffer in to the decode buffer. This is unnecessarily messy, especially as the recommended workflow.

A cleaner and simpler approach would be for the player to be able to make a single SUBSCRIBE request and be able to pipe that response directly in to its decode buffer. This can be achieve by either modifying the proposed AbsoluteStart filter so that it doesn't stop at the Latest Object, or adding a new filter type which is "AbsoluteStart and carry on" (bikeshead away). So the player wanting to start behind live would first make a TRACK_STATUS_REQUEST, which would give it the latest Group and Object. With this information it could calculate where it wanted to start behind live and then make a SUBSCRIBE request with the "AbsoluteStart and carry on" filter. It could pipe the response of this request directly in to its decode buffer and begin playback.

suhasHere commented 2 months ago

Agree with @kixelated

My proposal would be:

  1. Keep LatestGroup and LatestObject in subscribe with the restriction that only one of each can be issued. Remove other filter types.
  2. Remove AbsoluteStart altogether.
  3. Define new Fetch API with just the AbsoluteRange.

Applications using Fetch and unaware of the group information can use TrackStatusRequest to find the range of groups to request for. They can optionally specify a control parameter for flow rate vs the network rate for delivery. Fetch api also will attempt fill holes by requesting upstream as needed, Also specifying group delivery order might still be useful.

This will allow players to use appropriate buffer for starting from history and at the right time ( when they know they have right amount of data in buffer to move onto live data, for example) shall issue Subscribe to continue from the live edge.

ianswett commented 4 weeks ago

I updated this PR, but it's changed enough I decided to create a new PR.