Add availability limits to MoQ subscriptions #448
Conversation
Those are long-term limits on how long a relay can keep serving objects from cache, primarily meant to be used to enforce content-related policies, rather than be used as a technical measure for optimizing delivery.
|
|
||
| The following properties are defined in this document: | ||
|
|
||
| * AVAILABILITY_LIMIT_ABSOLUTE: an integer expressing an absolute time in the |
There was a problem hiding this comment.
This AVAILABILITY_LIMIT_ABSOLUTE is the same time for the whole subscription. What about the following use-cases:
- A 24x7 live linear stream, in which the broadcaster wants users to have access to the last 24 hrs?
- A sports game in which the allowed DVR window is 2 hrs. behind the live head?
In both these cases, the AVAILABILITY_LIMIT_ABSOLUTE varies depending on when the GROUP or OBJECT is published and is not a fixed property of the subscription.
AVAILABILITY_LIMIT_RELATIVE can be a property of the subscription. I'd suggest leaving that in the PR and then moving the AVAILABILITY_LIMIT_ABSOLUTE to an Object (Group) property. It can be efficiently communicated via our Stream header if it is the same for all objects within a Group.
There was a problem hiding this comment.
I feel this property AVAILABILITY_LIMIT_RELATIVE and DeliveryTimeout are very similar and should be scoped per object in general and not subscription.
There was a problem hiding this comment.
I don't think there's a good use-case for absolute end times in a live streaming protocol. If you already know the total length of the broadcast ahead of time, you can set a relative limit too.
|
|
||
| The following properties are defined in this document: | ||
|
|
||
| * AVAILABILITY_LIMIT_ABSOLUTE: an integer expressing an absolute time in the |
There was a problem hiding this comment.
I can see how it make sense to have both a relative and absolute time limits in much the way you have desired here but for reasons I listed in the other PR. I do not think they can be an subscriber attributes.
The specific use case Will brought forward required it to be be publisher based not subscriber.
There was a problem hiding this comment.
@fluffy : the properties in the PR are transmitted by the publisher in the SUBSCRIBE OK, so I read them as being set by the publisher.
There was a problem hiding this comment.
oh, crap , you are right. I was reading on github and without all the file context and thought they were on the subscribe message. thanks
There was a problem hiding this comment.
Yeah, conceptually these should be part of TRACK_INFO
| number of seconds since 1970-01-01T00:00Z in UTC. If present, the relay MUST | ||
| NOT start forwarding any objects received through this subscription after the | ||
| time point specified by this parameter is in the past. | ||
| * AVAILABILITY_LIMIT_RELATIVE: an integer expressing a number of seconds. If |
There was a problem hiding this comment.
I think relative would need to be in mili seconds not seconds.
| * AVAILABILITY_LIMIT_RELATIVE: an integer expressing a number of seconds. If | ||
| present, the relay MUST NOT start forwarding any individual object received | ||
| through this subscription after the specified number of seconds has elapsed | ||
| since the object in question has been fully received. |
There was a problem hiding this comment.
small nit and not critical, but I think this would be better expresses as since the start or receiving the object.
| @@ -1402,7 +1402,9 @@ SUBSCRIBE_OK | |||
| Expires (i), | |||
There was a problem hiding this comment.
What is the difference between AVAILABILITY_LIMIT_ABSOLUTE and Expires? Can we use Expires to enforce the content policy? Or, use AUTHORIZATION INFO to carry a token with the lifetime?
|
This is deeply in the case of what gets sent next which we said we would discuss at the interim. The problem in evaluating this is the questions of if this is the only mechanism but something added in addition to other approaches that solve the other use case. This needs more information about how relays handle it, how is it cached etc. We can discuss on call |
|
I have been thinking about this problem and have changed my mind a bit since my original comment. I think we should add only cache duration limits to objects|groups|tracks (and not availability limits). Once this cache limit has expired, the relay MUST go upstream to retrieve a fresh copy of the object. If the object is no longer available, then the origin will use our Object Status flag to indicate that the object is no longer available. Relays may cache this response, just like we cache origin 404s today. This not-available response may itself carry a suggested cache duration. |
|
Individual Comment:
The next interim is about priorities, and I view this as related but orthogonal. In my view, priorities help you decide what to send next when you have more than one thing to send. Anything related to cache duration, availability or delivery timeouts can only change how many choices you have. |
|
Closing this in favor of #469 |
A tweaked version of #448 Fixes #440 Fixes #249 Closes #450 Closes #448 I'll note that we might want to add params to TRACK_STATUS and allow this to be returned from that as well, which would allow a relay to keep it in its cache. Attempts to write down where we ended up at the end of the June 12th interim.
Those are long-term limits on how long a relay can keep serving objects from cache, primarily meant to be used to enforce content-related policies, rather than be used as a technical measure for optimizing delivery.