TTL

Ian: Objects are immutable, as a result some of the meanings of TTL are
different from HTTP

Issue #440

Ian:

• You don't want to pollute cache for content that expires after a few
  100ms
• Usecase: Go back a few minutes
• First PR (#446) adds cache duration to every object
  • 0 indicates no preference, relay can decide
  • Not clear if we need it on per object basis

Victor:

• Two kinds of usecases
• one: PR 449: make sure we don't send data after it is no longer
  useful, e.g., in real-time
• second: PR 448: In a sports game of 3h, serve last 30 minutes, but
  no longer
  Hard expire all content after a particular time. This is about
  enforcing policy.
• both PRs use SUBSCRIBE_OK to set the parameters
• one concern about delivery timeouts is, that we are consistent in
  how to treat objects in terms of delivery preference

Ian: These two PRs also achieve the usescases I described
Suhas: Clarification question: If I read all PRs, object duration,
delivery timeout and relative, is my understanding correct, that they
are very similar? Who owns the decision making across all PRs?
Victor: Cache duration and timeout are really similar
Ian: I assume we would not land all three PRs. I don't have a strong
preference
Suhas: When we say per subscription, does it mean those values can
change across subscriptions?
Victor: Can imagine you might have different delivery timeout and
relative timeout for serving objects from the past, different for
real-time
Luke: Difference between delivery timeout and relative availability?
Victor: Different intent. One is in scale of many minutes and the other
is in scale of seconds at most.
Luke: Should be in track info in addition to subscribe_ok - it's a
track property not a subscribe proprerty.
Will: Agree that these are track properties instead of subscription.
Relative timeout makes sense as track property, absolute timeout not.
Absolute should be decoupled from relative cache hints. They should be
object properties, can be in stream header if same for all objects.
Relative should be track property, objects carry absolute timeouts.
Victor: I can see absolute is not as useful as relative.
Ian: Talk more about differences in delivery timeout?
Luke: Absolute ending is bizarre, you have to know when live stream
would end, which you don't. I don't see usecase for absolute cache
duration for entire track. Would be nice if subscriber could specify
when it is no longer interested, like max. jitterbuffer size. So you
have subscriber preference but alos publisher preference. Should
negotiate as a per subscription property.
Will: Reply to Lukes question, utility of absolute timeout is that
relative is dependent on when you got the object. Absolute time is going
on, but relative window can't be cached. If there is absolute
availability, like rights end at certain time, I see no way around
having that absolute timeout. Can't be fixed track property.
Victor: Why would you want to have different relative timeouts: One
thing in mind, if subscribe for real-time is different for subscribe to
some minutes in the past.
Luke: I think main issue is cahce ttl based on receipt time of group or
object. It is complicating with out of order groups or object. Proposed
are wallclock timestamps, but this is just for caching and we can expire
based on media timestamps.
Will: Cache hints should be relative. Availability is not performance
feature, it's a legal requirement. Consumers should not get content
after wallclock time. Relays should not have to go back to origin and
ask if object expired already.
Ian: Clarification: Should it be a per object property instead of per
track?
Will: Don't see usecase where it is the same for every object. First
object has certain timeout, next object expires later and so on. I think
it can still be efficient if it is in the object. It is only in usecases
where we care about availability.
Vincent: What's difference between availability limit and expires?
Victor: Expires is not related to caching or deliver. The idea is that
after some time the subscription goes away.
Vincent: Can we use it?
Ian: Intended to be different mechanisms.
Vincent: What happens after expiration? Behaviour is different?
Ian: Not as well described as I might hope. Keep it out of this
conversation, because it is trying to solve a different problem.
Victor: Once limit is passed, you cannot cache, but have to refetch from
origin.
Vincent: Legal requirement
Victor: Yes, publisher could reject
Mike: Have been against timestamps in the past and still want to
exercise caution. Think we should avoid using timestamps for anything
related to buffer filling or delivery properties. I Think the usecase of
not deliver after certain time for legal reasons is valid. Not sure what
is the best mechanism. Want to avoid timestamps for delivery cause it
will cause race condition and clock sync issues.
Mo: In prior meeting we floated idea of player licensing, may put it
into manifest or similar instead of in the protocol, especially if it
iflates object sizes.
Will: Malicious clients may still request it though. Delivery mechanism
should refuse to deliver after timeout.
Mo: Authorization issue, if not authorized, it cannot receive the
object.
Will: Requires auth token with time limit.
Ian: Goal: What subset of PRs should we land.
Luke: Agree with Mo, could be like DRM thing. Key server doesn't give
key if expired. Settign track timeout doesnt work for DVR usecases, just
gonna have a bigger cache. Putting it on per stream timeout makes more
sense instead of track wide property. You need to know how long object
will be in the cache. Agree with Mike, don't want timestamps.
Alan: Absolute timestamp is a new usecase. Maybe focus on caching. Maybe
we can learn from HTTP instead of reinvent everything (eg: max-age).
Suhas: Agree with Luke and Mo. Should not be dealt per track level.
Transport should not enforce it. Usecase: one subscriber real-time,
another DVR leads to Conflicting requirements. As publisher, I know how
long objects should stay in network before it is of no value or needs to
be delivered.
Will: Usecase of live and DVR in a same appplication is e.g., a soccer
event, some people watch live some watch 30 mins. behind. Relay don't
want to cache two, cause it's the same bits.
Suhas: In that case, if broadcaster sets cache duration on like 30 mins.
Wouldn't it hold for both subscribers?
Will: No, broadcaster window is constantly changing. Relative has to be
constantly adjusted.
Luke: That's like max age in http.
Will: Need to enforce subtraction in the spec.
Luke: Hard requirement that objects for real-time need max cache age,
producer should say "dont cache it longer than 2h". Subscriber can say
"Im real-time and don't need long caching"
Victor: Use cases where you have to, e.g., subscribe twice to same
stream with different jitterbuffer sizes. In a lot of cases this is a
feature but also a downside, e.g. cheering neighbours before you see it
live. Shoud not ty cache timeout to delivery timeout. Might want to give
up after 30seconds but there is no reason to also evict from cache. Try
to split availability and delivery timeout.
Mike: Learn from HTTP. Mutability of objects makes it very different.
Caching headers try to protect application from inconsistent view.
Maximize cache efficiency. Here we're doing something different as an
optimization. Question: Is there an obligation to hold things in cache
up to certain point or is it just a hint. I think it's the latter and we
should be specific about it.
Ian: If you are caching, you should cache for this long, but could be
more vague.
Suhas: Broadcaster is the one who has an idea of what kind of range of
subscribers his stream has. Based on that it will set the max age.
Real-time, live and DVR can be different. Agree that delivery timeout
can turn around to subscriber side optimization. As publisher I know how
long objects are valid. Can Subscriber influence how long to deliver
objects. Can be separate issues. Third thing is content policy.
Mike: If they can pay for it to stay in the network is diffrernt from
opportunistic caching objects. Trying to limit bandwidth cost or
whatever, sounds like idfferent set of behavours we expect. With
immutability, I can always go back to oritgin. Difference between
mutable and immutable content.
Luke: If we copy http and do max age, there is no guarantee to cache
that long, might go back to origin. Max age is simple, don't know if on
per track or group or stream basis. Leaning to per stream even though
verbose.
Victor: Not sure we want hard requirement that something stays in cache.

Ian: Max age equivalent has similar properties. Question is, where to
put it. Stream header is reasonable natural. Every object also works.
Could make it a subscription property. Thoughts?
Will: Is there a use case where it changes within the track? If we have
usecase where it can vary, we have to put it in group or stream headers.

Victor: In favour of trying to keep things that are same per track until
we have a reason not to because it adds overhead.
Suhas: I think it cannot be per track, it is to restrictive. Some of the
usecases it makes sense, we are experimenting with objects depending on
how far they are from I frame. These objects don't want to keep them for
too long. Having flexibility per object will give us sufficient leverage
for different applications without compromising on use cases.
Performance wise it does not hurt.
Luke: Comes down to if you need to subtract the age, i.e., if it matters
when you request the content. Then it needs to go in stream.
Mike: Might want to keep I frames longer than P frames which would be a
variation within a group. A lot of this is implementation detail.
Victor: Not sure how that use cases would even work. Want to understand
them so I can address them better.
Ian: I frame P frame; I think it is possible that would end up being
cleanly dealt with with a priority mechanism. Other thing: If we put it
in object, subtraction becomes weird. That means I have to modify every
single object as a relay as I fan it out. If I have one person at head
and one 30s behind, I have to send different objects. I think subscriber
giving preference for delivery timeout might have good usecases and
separate out a lot of them.
Martin: Thank you Ian and Scribes.

Martin: We're going to do these meetings at least until Wed, june 12.
Agenda for each is MoQT issues. Specific issues about two days before.
Please send feedback to chairs.
Suhas: Clarification question about PR
Ian: Will create PR similar to max age from HTTP
Will: Please use a different name
Martin: Back to admin. Who is going to attend Seattle interim, please
send email to the chairs.