June 5th interim

Noter: Luke

Max Cache Duration #446 - Ian

Content you don't want to linger in the cache for too long.

When does the time start? Proposal is on the end of the stream. Objects
have strict dependency if placed on a stream.

Cullen: What does "complete subscription arrives" mean?

Issue is incomplete subscriptions, as you might not receive the end of a
track. Same applies to end of a group but that's less of a concern.

Mike: Hard to discuss without splitting out live/delayed use-cases.

Agree. But leave it as a separate issue.

Suhas: Clarify if this is object cache duration or stream cache
duration.

It's the stream cache duration. The granularity is on the forwarding
preference, not object.

Victor: Why is this in the stream header instead of the SUBSCRIBE?
It seems a bit excessive.

Mo: Agree with Victor, what's the use-case and how does this apply
to the Subscriber's Delivery Timeout.

Cullen: Focusing on directionality. Don't understand how subscriber
preferences flows upstream.

Cullen: Should talk about expiring within a stream, when expires is
smaller than the GoP size. On the fence with simpler vs advanced
solution.

Victor: Agreed and forgot what to say.

What if things arrive out of order? Does group 2 expire before group 1?

Mike: We're not talking about caching behavior, but delivery
preferences.

Luke: Maybe we should specify the max cache age based on the
distance from the live edge. For example, 100 groups max in the cache.

Martin: It's an optimization, as the relay can always go back to
origin to repopulate the cache.

Cullen: Out of order doesn't matter, and it should be common.

Mo: Weird to attach it to the end, especially when tail drop would
prevent the end being delivered.

Agree, can't depend on the end of group indicator alone.

Suhas: Notetaker zoned out.

Victor: Delivery timeout is important. Timeout for group N could
start when group N+1 is received.

Vincent: It's a content policy, so maybe it should be in the
subscribe_ok.

Is there a consensus on if this should be a subscription or
stream/object policy.

Alan: Are you saying if this should be a track property? Is there a
use-case where you need group X to have a separate expire than group Y?

Mo: Can you clarify the proposal?

It would be the same proposal, based on the forwarding preference (per
stream), but specified once in the subscribe_ok.

• {: .task-list-item} expires per OBJECT
• {: .task-list-item} expires per stream in header
• {: .task-list-item} expires per stream in TRACK_INFO
  

Cullen: I think this should follow the data. So you can update it.
Datagram use case would push this.

It's weird that this is an object property that changes on each hop.

Luke: Should be a track property. Just specify the maximum number of
groups a relay should cache, ex. 1.

• {: .task-list-item} expires per group in TRACK_INFO
  

Victor: Really weird if you expire the start of a group?

Cullen: Nobody wants to expire the start of a group. Thinking about
it being an immutable property of a group. So long as we don't break
variable group sizes.

Totally valid statement. Max groups or cache duration or an absolute
age.

Luke: Ideally we would have the presentation timestamp, and expire
based on teh group duration. Also, expires would be on a per group
basis, instead of delivery preference.

Mo: Would this prohibit delivery after expiration? Or is it just a
hint for efficiency?

Alan: I think we need to write down use-cases.

Thx Alan for blowing things up. Are we actually solving a problem?

Poll time.

Does some form of MaxCacheDuration valuable to add in the near future?

• {: .task-list-item} 7 yes
• {: .task-list-item} 3 no
  

Mo: Is this a hard requirement or just an optimization?

It's an optimization, on a cache miss you can always go back upstream.

Mike: Worried about adding features without addressing the larger
conceptual issues.

draft-04 is out. In person interim is going to be focused on priority.