Minutes interim-2024-moq-07: Wed 16:00
minutes-interim-2024-moq-07-202406191600-00

Blue Sheets

1. Alan Frindell, Meta (chair)
2. Martin Duke, Google (chair)
3. Spencer Dawkins, Wonder Hamster
4. Daniel Fay, Meta
5. Mike English, id3as
6. Suhas Nandakumar, Cisco
7. Will Law, Akamai
8. Luke Curley, Discord
9. Mo Zanaty, Cisco
10. Ian Swett, Google
11. Jana Iyengar, Fastly
12. Victor Vassilev, Google
13. Zahed Sarkar, Nokia
14. Christian Huitema, Private Octopus
15. Mathis Engelbart, Technical University of Munich
16. Victor Pascual, Nokia
17. Spencer
18. Lucas

9:30 Administrivia and overview (10 min)

Administrivia
“Clarifying questions”
Agenda Bash
Goals for Today

9:40 Detailed proposal for priorities between tracks (Cullen/Will, 120 minutes)

Strawman propopsal - 2
Alan: What is fifo?
Cullen: track with the oldest objec not being forwasrede
Christian: If some tracks have sub-priorities or missing for some
Will + Fully: Should be provided for all or none or zero
Mo: default vs no priority ?
Lucas: how does stream flow control apply when dealing with multiple
connections
Christian: CC allows, flow control allows
Daniel: all/none vs publisher priority interaction
Cullen: Pulbisher must all be set or no preference (0 value). Larger
means less important
Luke+Alan: Ignore tracks that has nothing to send or flow control
credits doesn't allow
Mo: is this all strict priority ?
Alan: Do objects needs to be sent entirety or partly
Jana: aksing if we don't do funny things
Ian: says- you can mix subscriber overrides publisher priority ...
Jana: don't do partial subscriber priority
Victor: same as Jana
Cullen: Priorities are highly synchronized between publishers and
subscribers. Publisher shoudn't say no preference, subscribers specify
everything or except number spaces are same
Alan: Ok to publisher to mandate, subscriber can specify either
Ian: +1 to Alan. remove all or none , go with subscriber preference.
Clients are in control and they know what they want. Subscriber priority
can overide original priority and causes looses thr priority being
changed
Cullen: Subscriber Priority on high bits + Publisher on low bits.
Christian: Nuclear energy concerns Christian. We cannot use whole scheme

Jana: Thinks all or nothing might not be right way. We need this to be
more dynamic. Merging priorities. We need to have common number spaces.
We need a reason for subscribers to indicate partial priorities. This
should be perspective and error out.
Luke: Subscriber needs to be required , no null option.
Will: number space needs to be mergeable
Lucas: indicate vs signal on wire is different in http. default priority
example. Everything should have explicit value.
Ian: someting on the whitebaord .. scribe can't scribe
Victor: Ok with All or nothing and All or something. Need strict
ordering of priorities is better.
Cullen: +1 on christian's usecase of going from no pref to higher pref.
Publisher needs to always put in and subscriber can either say nothing (
get pub's) or something
Christian: Subscriber needs to set a default priorities.
Cullen: Asking for consensus
2. subscribers provide some number and publisher provides numbers, how
to express "no preference" or have subscriber set "same priority" when
publisher thinks otherwise ?
Scribe-in-Pain: Lots of cross discussions happened. Please check
recording for this part.

Cullen: Moving to selecting within the track discussion
Discussions: pick the group Id based on the ASC/DSC
Ian + Cullen + Luke: if the group is half done, new group comes , it
wull take prference due to DSC if set
Objects are always sent in ascending order of the object Is

Decisions from morning session

Decision: do we have agreement on publisher always set a value -> All Ok

Decision: if there is a subscriber priorties are equal then publisher
priority wins
Decision: For subscriber-priority and subscriber-delivery-pref, relays
SHOULD indicate "no preference" when making an upstream subscription for
the track -> All OK

11:40 Lunch (75 min)

Discuss FIFO if equal priority.
Will presenting an illustration.
Cullen: Is this relay outbound queue in the app or quic stack?
Alan: Some quic stacks can let apps set stream priority and queue data
to it.
Jana: No strong reason to dictate FIFO or round-robin so don't specify
either, just leave undefined.
Victor: +1 to Jana.

Decision: Subscriber priorities are equal -> rank by publisher prorities

Publisher priorities are equal -> implementation decides
==> choose the lowest/highest group Id if pref is ascending/descending,
then pick the smallest object ID

Expiration

Luke: when does the timer stop
Jana: We use timestamps. What does expiration mean ?
Victor: small buffer but large group on how to deal with this
Martin: Does expiration impact retransmission?
Christian + jana: No. it is a layer voilation.
Will: Publisher must set largest time any valid subscriber may want.
Jana: Quic stacks don't expose time.
Suhas: App decisions should be decoupled from quic stack.
Ian: youtube live needs subscriber driven priorties. Also fix
retransmitions ;)
Daniel, Mo : Expired objects must also cancel next objects on that
stream?
Alan: Yes.
Mike: Are times based on reception? That seems problematic.
To expand:
There seem to be three possibilities
1. Time relative to the absolute program start time (true
glass-to-glass latency), which would require time sync a la ntp
2. Time relative to when a particular subscriber began receiving or
relative to when the publisher started sending objects to that
particular subscriber. i.e. I want dropping behavior even if I'm
time-shifted 30 minutes behind other subscribers at the same relay.
(This is the case I was raising)
3. Relative to when a relay receives each object, which won't be in
sync with the absolute glass to glass latency. This depends on how many
hops there are, can't really do this without time sync, etc. It also can
vary for time-shifted subscribers and may not apply correct. Publishers
can set a large expiry time to try to cover all cases, but how long is
long enough. Rewatching a live stream later will depend heavily on when
other subscribers most recently pulled objects into a given relay. (This
is my understanding of the current proposal and its deficiencies /
tradeoffs)
Victor: Senders that fill buffers (e.g. javascript) would have trouble
knowing how to measure or expire their sent objects.
Cullen: if the object has expired, you fin or reset that stream. Start a
new stream when the next unexpired object in the same group , start a
new stream
Luke: Use case is max jitter buffer size. Arrival time may not always
work, we care about presentation time. Maybe use number of concurrent
groups instead.
Christian: Objects in a group may be dependent on prior objects in that
group, so expiring one breaks later ones.
Suhas: Only the app knows how to handle gaps in objects in a
stream/group, not up to relay or quic to decide this.
Ian: If you subscribe to current group (i.e. live edge), then expiration
applies but otherwise doesn't.
Victor: Prefer number of objects (delta in IDs) rather than absolute or
relative times.
Chairs: No consensus, many option questions/issues.
Alan: Do people want to see a PR based on this expiration design? Jana,
can you write it?
Jana: Yes.
Cullen: Can someone propose an alternative using object/group
numbers/deltas instead of time?

Decisions is to write 2 PRs
PR-1: Cullen/Jana contents of expiration
PR-2: How can subscribers indicate to stop sending and how does it
decides to do so ?

12:40 Inside the track priorities (60 min)

Scope of the priorities

Will: Agrees with the proposal
Luke: We don't need to change the priorities ?
Ian: Per track basis is preferred and it causes DOS if not
Cullen: Active speaker policy needs change per group
Mo: Temporal scalability in a single video track, would be nice to mark
disposable layer as low priority.
Will: Use stream per object for that.

• Allow priority per objects
• Allow publisher priorities to change track priorities anytime

Martin: Does this work for all use cases? Should we ask for a PR for
this design? Yes, Ian will write one.

Wire encoding

Luke: Should go in track info (in subscribe OK or update, control
stream) with starting group number, not in stream header (data streams).

Jana: Stick with stream header unless there is good reason otherwise.
Chairs: Keep in stream header (as in current draft). Luke can write an
alternative PR if desired.

Do we need original-publisher-group-order?

Decision: New message from publisher for track info/status/update.
Ian/Suhas will write PR.

Tracks from different namespaces

Cullen: Advice in the spec about the problem and options, but nothing
normative. Mike/Cullen will write the PR.

Range of Priority Values

Mo: Why do we need more than H3?
Lucas: H3 only needs 0-7 because more becomes unmanageable. But quic
stacks often do more, like 0-255, for more things like control streams,
boosting header priority. Expanding the range from u8 to u16 or u32
would not change much of the implementation beyond the final mapping
from higher protocol to quic.
Victor: Want bigger number so each track can have its own.
Jana: Before, I've argued for 2 bits (4 levels), but that is for in
flight/transit. But if there are more queues beyond this, then more are
needed.
Luke: u8 should be enough.
Alan: Can anyone not live with u8 byte? Sold. Ian will write a PR for
u8.

1:40 Wrap up priority discussion (20 min)

2:00 Break (15 min)

2:15 Parking Lot / NO TIME TO DISCUSS

• Extensibility (Zahed, 10 min)
• Terminology (Alan, 10 min)
• Delivery Timeout/TTL (Ian, 30 min)
• Object Status experience (Luke)

3:45 Wrapup/Adjourn

• Next hybrid interim (10 min)
  Proposing Oct 1-3 NYC

• Plenary agenda (5 min)
  Martin: Bash stream mapping.