Minutes interim-2024-moq-13: Wed 16:00
minutes-interim-2024-moq-13-202406121600-00

MOQ interim 12.06.24
Scribe: Will Law

Martin - two use cases - cache suggestion, and contractual limit to not
serve content.
Alan - wants other people's opinions on his proposal.
Ian - reviewingmax cache duration v2. #448. propose we add to objects
rather than on subscribe_OK. Prefer seconds to milliseconds since
reflects real-world precision. May also remove absolute time.
Cullen - agree not accurate to milliseconds. In real-time media
delivery, milliseconds matter.
Ian - addressing cache, not delivery
Alan - separates how long in cache versus mechanism for optimizing
delivery queue.
Luke - priorities will address the queuing. How does priority versus
deadline work? This PR tries to solve something else.
Will - prefer seconds over milliseconds, reflects real-world cache
clearing intervals at CDNs. Could make things work with a cache hint.
MO - we should talk about use-cases. This is about policy and caching.
Is this normative that client's cannot be served content that is out of
suggested cache duration.
Alan - caching is an optimization. In VC world, if cache does not have
it, it is gone.
Ian - we could add a revalidation mechanism like HTTP.
Sebastien - any harm in using ms?
Mike - this will not help us solve policy issues. Since it is an
optimizaiton, we don't need it now and should move on.
Ian - proposal, make maxCacheDuration an object granularity, not based
on forwarding preference.
Suhas - this is an object property. For never ending groups in a chat
application, want to expire at smaller boundaries.
Ian - forewarding preferences make my head hurt.
Cullen - if someone sends a never ending group, you can DOS relays.
Luke - confusion around why caching. Why would you evict newer stuff in
group?
Ian - different values cause CDNs to behave differently.
Alan - when does timer start - beginning or end of object?
Ian - end of object.
Alan - object status is cachable.
Suhas - each object has its own granularity. Beginning of object is
better than end.
Ian - for begining, what if time expire before the end? Can you foward?
Suhas - if its expired, you don't send it.
Cullen - in a real-time system data not useful after a certain period of
time. Want something closer to S3 than a cache. Should be possible to
build relays like that. Lean towards beginning.
Will - bit constraining to be subscription based only.
Luke - we stopped making progress on separating expiration and caching.
This is just a hint. Would get rid of word "max". Don't bill me for
longer than this. Expiration is a separate conversation.
Mo - agree there are 2 use cases. Don't belive a hint is useful. You may
be jumping relays. Relays may have non-contiguous objects in cache.
Doing anything at the end will cause problems.
Ian - people agree on beginning of object, removing absolute time,
object granularity. Not agreeing on hint component. Can you send after
this time? When this time is it - not deliverable or not cachable.
Cullen - support as long as we add soemhting on delivery.
Ian puts google meet poll together

1. Is this a useful addition to MoQT - 8 useful, 3 not.
   No time for terminology discussion.
   Alan - I wrote a PR for terminology. Please review.
   Alan - for next week. Published draft agenda. People should
   articulate order they want to receive things. Also wrote some
   use-cases (that may sound like solutions but aren't). Please review
   before interim.
   Ian - we need to allocate some time for delivery time-outs, stuff we
   don't want to send.