Minutes interim-2024-moq-10: Wed 16:00
minutes-interim-2024-moq-10-202405291600-00
| Meeting Minutes | Media Over QUIC (moq) WG | |
|---|---|---|
| Date and time | 2024-05-29 16:00 | |
| Title | Minutes interim-2024-moq-10: Wed 16:00 | |
| State | Active | |
| Other versions | markdown | |
| Last updated | 2024-05-29 |
MoQ Virtual Interim
5/29/24
- Chair Introduction (5 min)
Alan Scribing, but you should volunteer next week.
Also briefly discuss a proposal to add a priority field to SUBSCRIBE and
SUBSCRIBE_UPDATE
Ian: we probably want a subscriber driver priority system at some point.
Cullen: Agree we will probably have something like this. We don't agree
on the use cases, or the approach, and we're discussing the bits. Save
for the interim.
Ian: since we want something like this, let's add this piece
(incrementalism).
Cullen: concern that people will think this is the only bit.
Ian: Do people think this is sufficient?
Luke: Needs more than this.
Suhas: This requires more to clarify behavior. How sub and pub
priorities work. Want to understand use cases better, and ABR.
Alan: use cases are coming before the inteirm
Jordi: This doesn't seem to be enough for ABR. Focusing on use cases now
makes sense.
Agree to table this until the inteirm
Continue the conversation about Cache Duration, TTL, with slightly
updated PRs.
Victor: PR has flipped so the sub sends the timeout value.
Ian: Should the sub OK contain the value that will be used?
Victor: If there are multiple timeouts, the lowest applies.
Ian: Resource constraints will also apply
Victor: Subscriber gets to ask "do not send if someting is too old". Not
a guarnatee.
Luke: Max-age on the other side. This is good. This is based on the
"end" of the group, but different since timeouts usally start at
beginning.
Cullen: Does this replace the other timeouts?
Ian: no. This is complimentary.
Cullen: Only the server knows sometimes. How does this fit in the big
picture. Don't understand how these are aggregated.
Suhas: If this conflicts with cache duration, how do they resolve. Need
to explain what relays do upstream.
Ian: how much text do we need for relays? There are multiple approaches.
Victor: Depends on whether the relay is talking to another relay - don't
know. Relay talking to publisher, you don't need this value.
Alan: +1. How do you implement this?
Luke: timeout per "stream". This is bandwidth optimization. Should equal
jitter buffer max size.
Mo: framed in terms of relays. Don't we want something simlar for
contribution? The PR language doesn't make sense.
Ian: Probably yes, maybe editorial.
Victor: thinking of rewriting the PR in this way.
Suhas: Should be at object granularity
Cullen: 200ms delivery timeout and 30s GOP sequence, this doesn't work.
This doesn't solve the problem of not delivering old data.
Ian: why?
Cullen: Time based off end of the group doens't work.
Victor: Don't understand. If you put everything in one group, you need
to transmit everything. Timeout kicks in at an iframe. Does this make
sense?
Cullen: no.
Luke: agree with Victor. Use PLI?
Cullen: is that for everyone? That's not scalable.
Alan: if you want to drop in the middle of a group, you need datagram or
stream-per-object mode
Mo: at a relay if you need to drop instead of send. There's conflict
with the QUIC layer below you - how do you implement.
Ian: you can stop retransmissions quickly.
Mo: We should specify the interaction with the QUIC layer
Victor: Resetting a stream means aborting retransmission.
Ian: Subscribe OK too?
Victor:
Suhas: so if the group expires, you may have to wait for the next group?
Victor: yes, it's how YT live works.
How should we update it:
Cullen: If the group falls behind, you end the stream.
Luke: want to recover, use PLI?
Cullen: Don't think PLI will be used in moq.
Luke: Don't want to drop if there's a single group.
Suhas: This distinction is important.
Ian: Is this what people want instead (how long for old stuff)?
Victor: Ok to move timer start from end of current group to beginning of
next group. Both are fine.
Martin: Concerned about sending things the client said it can't use.
Cullen: two use cases:
1) once I'm on the next one, everything older is useless
2) This stream is far enough behind, don't send it
Victor:
Martin: express opinions in gh so we can try to land this before the
deadline
Wrap Up:
take notes!
email chairs re hybrid interim
email chairs feedback about these virtual interims
look at chat if you haven't
< 3 weeks from interop, when is new draft coming?
Ian: was hoping to ship today
Maybe people like 446?
Luke: should be on a stream basis, otherwise gaps
Cullen: seconds vs milliseconds