Simplify SUBSCRIBE as a follow-up to FETCH

[ianswett]

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]

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.

[fluffy]

So most of this looks good but I ams strongly against removing Latest Group.

The alternative introduces too much unnecessary join time latency for the main case of people joining a conference call. Keep this as is does not complicate the protocol, We have spent extensive WG time getting to this consensus. I think we should direct are energy to more important things than redoing all the arguments about this.

[kixelated]

The LatestGroup mode is the reason why the concept of Groups even exists at all, and I don't see how the protocol can function without it. You could remove the other modes but absolutely not LatestGroup.

[suhasHere]

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]

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