search

moq-wg / moq-transport

draft-ietf-moq-transport
Other
70 stars 16 forks source link

Add availability limits to MoQ subscriptions #448

Open vasilvv opened 1 month ago

vasilvv commented 1 month ago

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.

fluffy commented 2 weeks ago

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

wilaw commented 2 weeks ago

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.

afrind commented 2 weeks ago

Individual Comment:

This is deeply in the case of what gets sent next which we said we would discuss at the interim.

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.