Minutes IETF119: moq: Tue 07:30
minutes-119-moq-202403190730-00
Meeting Minutes | Media Over QUIC (moq) WG | |
---|---|---|
Date and time | 2024-03-19 07:30 | |
Title | Minutes IETF119: moq: Tue 07:30 | |
State | Active | |
Other versions | markdown | |
Last updated | 2024-04-01 |
MoQ IETF 119
March 18, 2024 and March 19, 2024
Chairs: Alan Frindell and Ted Hardie
AD: Murray Kuchewary
Day 1 agenda:
Note taker: Magnus Westerlund
Administrivia (Chairs) - 10 minutes
The chairs presented the Note Well, Meeting Tips and Agenda.
There was no bashing of the agenda.
Readout from Hackathon - 10 minutes
Five implementations have updated to version 3.
Review moqt updates in draft-03 - 15 minutes
Ian went through the slides.
Area of future extensions raised some clarifying questions from the WG
members.
- How to transmit and what to not transmit
- Extension of MoQ
Subscribe and Fetch - 30 minutes
Speaking: Cullen Jennings
Going through issues around subscribe and the different interpretations.
Laying out a proposal for something that attempts to be clear for how to
refernce what media group in the timeline where delivery should start
when subscribe. Thus defeining: Last, Current or Next group. Stop
indicates when relay stops delivering to client. Subscribes exists until
control signalling removes it.
Fetch retrives an absolute range of objects. Using absolute enables
relay to track what is have requested, and what is overlapping. Will
also allow responds to indicate what it can't deliver.
Delivery order is not guaranteed.
- Mo asked if it was possible to subscribe with a start from a
particular object within a group. The WG will include this as a goal
for the design.
By doing two methods of Fetch and Subscribe it gets simpler to avoid
different rules and excemptions depending on context for the method.
Jonathan Lennox asked how can the client now what the absolute group and
objects that exist?
A Last-1 was not defined as one can subscribe to last and then fetch the
previous one. Which is fine as long as one are okay with concurrent
delivery.
Jonathan Lennox noted that one would desire something equivalent to HTTP
GET Head.
Martin Duke: This proposal with Fetch looks quite convincing.
Jana noted that the issue with concurrent delivery from subscribe +
fetch as well as two fetches both exist and should be treated as
seperate question.
Luke Curley was skeptical to Fetch as it appears to add complexities and
the need to handle both subscription and fetch.
Dirk Kutchner asked if rate controlling of the fetch requests are
expected. Yes what is being delivered will be rate controlled.
Prioritization is a future question.
Victor Vasiliev what are the semantic guarantee of subscribe. If caching
there are no impact. But if caching one need to have last, and current
forcing to cache two groups.
Martin Duke what matters is the application API. This proposal appears
to make it simple.
Luke Curley would be good to make it clear what are the issues with
existing solutions. One issue is the need to know the size of the group.
That was not intended, the client would not need to know.
Peter Thatcher asked what happens if there are very long groups? If the
TTL time is shorter than the group time the objects will be dropped from
the group. So the caching is not overriden by object.
A PR will be available after this meeting session for this proposal.
-
Chairs asked if anyone had major concerns with the proposal:
- Luke Curley responded that he has major concern.
Luke there are potential issues around TTL, Priority that interact with
Fetch
Jana, we will have to move forward to be able to work on this and figure
out if we can work out the issues.
A PR will be provided and the WG members will need to review this with
the issues from chat.
Catalog draft - Post-adoption changes 20 minutes
WARP draft Update 5 minutes
Low Overhead Container - 10 minutes
Mo Zanaty presenting the slides.
Luke and Suhas was both proposoning that it is split into a MoQ
streaming format and a package format. Luke was pushing back on this as
it anyway would need to be combined.
Chair summary of next steps: Figure out if the split results in two
sections of one draft, or two. After that there will be a call for
adoption.
Transport Issues - balance of time (~20 minutes)
When does a Group or Track End?
General agreement on explicit signal in the data layer is preferable.
One issue that can exist is that groups gets cut short.
Prioritization and what to send?
A lot of views on this topic and people have different use cases.
Several argue for more discussion and bringing in as many use cases as
possible. Implementation and experiences will be need to gathered.
Chairs: An Interim for this topic is likely. Please consider what basic
things would be needed to gather experience.
Chairs asked about interest for a Prioritization focused interim (2
days).
Yes: Before Vancouver (17)
No: After Vancouver (4)
No Opinion: Likes to press buttons (15)
Uncertainty what input and data can be provided. Please have discussion
in the hallways to figure out what could be provided.
Day 2 agenda:
Ian: Can we talk about what needs to go into the draft to have a
productive interim on priorities?
Ted: Maybe that will fall out from the first talk, but we don't have
time for a big discussion.
Lessons from implementation - Simulcast, Priorities and Congestion
Control - 15 minutes
Jana: Everyone should be doing priority in retransmissions. How do you
know how many priorities you have to drop?
Suhas: We implement the priority queue.
Ian: The priority is the publisher-driven send order stuff in the draft?
(Yes) Who's canceling? (The publisher) Thanks for your BBRv3
contributions.
Lucas: What do you mean by "just like HTTP priorities?" sequential?
(Yes)
Bandwidth measurement in MOQ - 15 minutes
**Catalog and WARP Updates - 10 minutes **
Lightweight Encryption for MoQ Objects (Cullen/Suhas) - 10 minutes
Jonathan: Maybe use GCM-SST? (Sure)
Subscribe and Fetch follow up - 5 minutes (no slides)
Ian: PR #421. Lots of spelling/design details in the PR. Not married to
details.
Luke: What do you do with HLS-DASH (reliable live). Maybe right that
down?
Cullen: HLS-DASH is dealt with easily, I can send an explanation to
list. Let's merge to unblock other things.
Will: I like the separation of FETCH. It meets the requirements of
real-time cases, but for other streaming you want to go back more than 1
group. A common use cases requires 2 messages. Please have SUBSCRIBE
that reaches further back.
Ian: Agree that it's important use case. Going back 1 full group is
esnough that you can fill the pipe for 1 RTT while you send the Fetch.
Will: but you need the earlier data to start
Jana: I don't think this is ugly, if you consider congestion control
plus priority.
Suhas: PR is in right direction, eliminates edge cases.
Cullen: If SUBSCRIBES go back arbitrary times, there's no easy way to
overlap requests.
Ian: Time does not exist.
Chairs - 5 min
Ted is done as chair, Murray done as AD.
Martin is new chair, Zahed new AD.