Media over QUIC

2024-10-03 Cambridge

Blue sheet

1. Magnus Westerlund (Ericsson)
2. Martin Duke (Google)
3. Gwendal Simon (Synamedia)
4. Alan Frindell (Meta)
5. Giovanni Marzot (Vivoh)
6. Jonathan Lennox (8x8/ Jitsi)
7. Sebastian Rust (TU Darmstadt)
8. Mathis Engelbart (TUM)
9. Daniel Fay (Meta)
10. Phill Hallam-Baker
11. Mike English (id3as)
12. Suhas Nandakumar (Cisco)
13. Cullen Jennings (Cisco)
14. Mo Zanaty (Cisco)
15. Will Law (Akamai)
16. Yenda Li (Meta)
17. Zafer Gurel (Ozyegin University)
18. Ali Begen (OzU)
19. Xavier de Foy (InterDigital)
20. Ian Swett (Google)
21. Spencer Dawkins (WonderHamster)
22. Tim Evens (Cisco)

Notes

9:30 Administrivia - Chairs, ending early at 3:45pm

Future interims:

• Feb 24-26 in Denver (after Mile High Video)
• Summer (May/June) in Europe

9:45 Fetch Proposal - Suhas

Gwendal: Does fetch error happen at the time of the fetch request not
when sending objects?
Suhas: Yes.
Will: An alternative design could be start sending objects and only send
fetch error after sending all old objects and catching up to the live
edge.
Christian: Prefer atomic transaction rather than a potential cycle of
speculative fetch/subscribe at the live edge transition.
Martin: Instead of unsubscribe, the initial subscribe can remain with a
single fetch, if the client is willing to buffer the live edge.
Alan: Instead of the initial subscribe, get track status is another
option.
Alan: Can Fetch_OK also contain live edge group/object ID?
Will: No, since relay can serve fetch from cache without knowing live
edge or fetching upstream.
Gwendal: Does Fetch_OK come immediately after a live edge check or
after upstream fetches?
Cullen: Immediately, like Subscribe_OK, unless the relay needs to go
upstream to determine the live edge before replying.
Will: Remove track alias, not needed.
Alan: Will Fetch_Complete use Object_Status?
Suhas: Possibly, other options will also be discussed.
Will: Fetch should return error if the request exceeds the end of a
stored (not live) track.
Jonathan: Any distinction for end of track case versus beyond live edge?

Alan: We need to discuss this deterministic end of track signal.
Ian: Can relays reply to fetch beyond limits with ok and its current
limits rather than error?
Martin: Let's defer this discussion.
Will: Missing objects should be signaled with empty object status, not
just omitted.
Jana: Gaps implicitly signal missing object IDs.
Ian: It makes more sense if Fetch_OK when at least one object can be
returned, Fetch_Error if no objects can be returned.

Alan: List of aspects to discuss:

• atomic fetch/subscribe (Christian) - covered below
• partial fetch error (Daniel) - covered below
• partial fetch ok not error (Ian/Cullen/Will) - covered below
• wire fields, including fetch ID and track alias (Martin) - deferred
• errors (Jana) - covered below
• separate fetch/subscribe messages (Ian) - keep separate for now

Atomic fetch/subscribe (Christian)
Cullen: Subscribe & Fetch can be done atomically (at 1 RTT cost)
Daniel: easy to add optimization after the fact
Ian: +1 Cullen, and I think this will be complex for relays
Mo: The goal is deterministic not atomic transactions. Allowing partial
fetch ok not error can help determinism.
Will: Prefer clients to be in control, not force relay to perform atomic
transition.
Victor/Suhas/Christian/Martin: This can work as is, any combined
fetch/subscribe can be explored later if desired.
Luke: Most clients must do this combo fetch and subscribe, seems
onerous. Current subscribe at past group works better.
Chairs: ==Rough consensus that current proposal can work as is, any
optimizations can come later.==

Partial fetch ok not error (Ian/Cullen/Will)
Cullen: Propose Fetch_OK includes start/end range that can be
fulfilled.
Will: Can the end be signaled in the returned objects not the Fetch_OK
control message?
Mo: Fetch_OK should include the range that can be fulfilled instead of
waiting on the data plane objects to signal this range, because the
subscriber may need the signal early to do further fetch/subscribe
transactions.
Luke/Daniel: Don't block delivery from cache if request exceeds live
edge.
Alan: Fetch then subscribe is racy. To avoid the race, subscribe then
fetch.
Ian: Atomic fetch/subscribe is harmful. Group order and priority may
need to differ in fetch vs subscribe. Fetch response should include
range that can be returned in the header.
Christian: Need to know if the returned range is due to end of track or
at live edge.
Suhas: +1 to Ian, atomic is bad.
Victor: Fetch should return error if entire range can't be fulfilled.
Jonathan: Hearing tension between having range info up front in fetch ok
header, or later during object delivery. Should we have a fetch range
update message?
Will: We need a signal that this fetch range is shortened due to the
live edge versus end of track.
Christian: Live edge is local to each relay, not a global thing.
Suhas: Ok with range it can support, client can fill gaps later if it is
a live subscription.
Will: Looking up the closest range start/end that a relay can fulfill
may be an expensive relay operation.
Ian: Objects can flow before fetch/subscribe ok, because Youtube will.

Proposal 1. (0 hands) Status Quo: FETCH beyond live edge = ERROR no data
returned
Proposal 2. (9 hnads) FETCH beyond live edge = OK + what range are you
going to get, available data returned
Proposal 3. (0 hands) FETCH beyond live edge = ERROR, but there is a "to
the live edge" marker. FETCH_OK has what you will get

Chairs: ==Rough consensus that fetch will return OK if any objects can
be returned in the request range including the potentially smaller range
that can be fulfilled in the OK or header, error if none can be
returned.==

Fetch Priority:
Victor: Relays will prioritize what they want. Publishers will
prioritize what they want. No need for spec.
Martin: +1 to Victor.
Mo: +1 to Victor.

Subgroups in Fetch:
Luke: Is subgroup preserved in fetch / cache / data model?
Chairs: ==Subgroup ID is in the fetched objects (some header
somewhere).==

14:00 Priority issues PR#518 - Victor

4 hands for the PR.
1 hand against the PR.
6 hands for we need another PR, not this, not the status quo.
Chairs: ==Alan will write a new PR.==

14:30 Track Namespace + Name merge, and Wildcard Subscribe - Will

Cullen: Empty gaps in the middle of the name tuples should not be
allowed.
Luke: How does a relay know a name is a wildcard to avoid forwarding
upstream?
Will: Relays know what was announced and published, so they know
wildcard vs published track.
Mike: Sees value in wildcard in the middle.
Victor: Wary of wildcard subscribe due to track state.
Daniel: Also wary of wildcard subscribe.
Mo: Wildcard subscribe should be supported via subscribe announce, then
subsequent subscribes to each desired track after seeing each
announced/published track.
Ian: Sees a lot of work and complexity in wildcard subscribe.
Suhas: Details of how the wildcard subscribe mechanism work need to be
designed, but should not stop the need and progress.
Chairs: ==No consensus to merge track namespace and name into tuples or
wildcard subscribe.==

15:17 Object ID Proposal - Victor

Few comments that the summary of current status of how group di increace
might not exaclty match the current draft.

Tim: asked if could just use a marker instaed of this proposal.

Cullen: Raise that next generation codec are still encoding frames on
previous group before the next group.

Luke: How do we know opbject 5 is keyframe. Ans: would have an marker
that 5 is a join point and interesting.

Jana: May not matter because these are laabels and peopel will hash the
name and use.

Suhas: Group and Object ID are applilcation specific and the
applications can use as the identifiers as they want. Would want to see
what is problem we are really solving for.

Daniel: We just sort out in Fetch that gaps in group IDs indicates group
non-existence, makes gaps ambiguous.

Will: Like to decouple acceess from internal data structure.

Mike: like idea of elmiunating gaps. We could do things like object
filtering. As soon as you have objects continuously numbered for entire
tracks you need to be able to serialize everything at the original
publisher, which restricts some things that may be possible today.

Alan: Can see issue of needing to add to next group before finishing
prev group.

Chairs: ==There is some interest in object and group ID sequential (by
one). Can we get a clearer problem statement before a PR?==