MOQ Hybrid Interim Meeting 2025-02-26 Day 2 Location: Comcast Office in Denver # Attendance {#attendance} Gwendal Simon (Synamedia) Remote Will Law (Akamai) Magnus Westerlund (Ericsson) Remote Mo Zanaty (Cisco) Suhas Nandakumar (Cisco) Cullen Jennings (Cisco) Christian Huitema (Private Octopus Inc) Martin Duke (Google) Giovanni Marzot (Vivoh) Remote Tim Evens (Cisco) Remote Daniel Fay (Meta) Ian Swett (Google) Alan Frindell (Meta) Jordi Cenzano (Meta) Victor Vasiliev (Google) Mike English (Modal Dynamics) Zafer Gurel (Ozyegin University/Constructor Tech) Ali Begen (Ozyegin University) Mathis Englebert (TUM) Remote Lucas Pardue (Cloudflare) Mike Bishop (Akamai) Remote # Agenda {#agenda} 0900 Doors Open 0930 Administrivia/Rebash 0945 Interop Report (Mike) 1000 SWITCH, second try (Will/Gwendal) 1050 Break 1105 Group ID ordering PRs (Will/Cullen) 1200 Lunch 1300 Next Interim Planning 1330 Bangkok Agenda Bash 1345 Document reorg (Ian) 1415 Break 1430 Group Order & Delivery Timeout (Victor) 1500 Track Alias (Alan) 1600 Adjourn # Notes {#notes} ## Bashing of Agenda {#bashing-of-agenda} (Scribe: Zafer Gurel) Checking temperature on header extensions. Cullen want to ensure that we understand the overhead for audio before we conclude. Can do an anylises to Bangkok. Short term plan is to keep as it is. The conclusion is the debate about the extension headers will be in Bangkok. The chairs will decide a deadline for the review of the draft (Alan). Ian will drop a new draft on Monday (3rd of March) for Bangkok. The WG will have a long consensus call about the entire draft. The review period will be about four weeks. ## MoQ Interop Results (Mike) {#moq-interop-results-mike} Mike shared the results of the interop. Please have a look at the MoQ Interop Spreadsheet. Mike is working on a fork of QUIC interop runner, which will be MoQ Interop Runner to have rigidly defined tests. Zafer and Daniel will help Mike in the development of the tests. Martin asked whether the tool measures the performance. Will asks for a cleaner representation of the implementations in the spreadsheet: a seperation between clients that just publish but not subscribe, relays, etc.. Martin asks for two matrixes: endpoint relays, pub/sub clients. Alan: One-day duration may not be enough the interop. Jordi: He needs a relay with the fetch ability to test his client. Cullen will try and work on providing some test data to be used in the interop process. Jordi will also provide some data. Christian: The QLog format can be used. ## SWITCH, second try (Will/Gwendal) {#switch-second-try-willgwendal} Will starts his [presentation][1]. The proposal is to use a SWITCH message instead of a solution on the client-side, to automate the actions on the client-side. Christian: With two different connections, we cannot have an atomic operation. Will: As a response to Christian's question: The idea is using a single relay. This solution is not about switching to a different relay. Mo: Switch is never forwarded? Will: Yes Christian: Because of the necessity of the alignment of the group boundaries between the tracks, the proposal is not generic. Will: All the criticism made by Christian is handled by the proposal. Gwendal: With the existing APIs, there is no perfect solution. Cullen: Unlimited bandwidth from the original publisher to the last mile relay is a great assumption. I'm not against the idea of relay's handling the switch instead of the client. Mo: You're close to something that can be a general solution for also non-aligned tracks. Suhas: I suggest that joining fetch to have a starting point. This is a good starting point. Alan: What's the missing point if we have joining fetch? Martin: I liked the SWITCH proposal. You will have never object duplication, that's what I liked most. Ian: Stick with Joining fetch and use server-side ABR instead of implementing SWITCH. Zafer: We implemented a [similar solution][2] and got good results (decreased bandwidth usage and stalling on the subscriber side). Martin (as Chair): People want to relax some assumptions on the proposal. Action items: * Will will prepare a joining-based PR. * Another draft will authored, including best practices for track switching. It will be added as a section to WARP. * Try to test this. **BREAK** ## Group ID ordering PRs (Will/Cullen) {#group-id-ordering-prs-willcullen} **PR 727 - Add language to define how Group IDs increment (Will)** The discussion is about [PR 727][3]. Will proposes Group IDs to increase with time. Magnus: Which time? Will: Any time. In the reference of the publisher. Suhas: What are the legacy applications? Will: A legacy application example: two publishers publishing on the same track. Alan: There is an implicit assumption that there is a single publisher here. Martin: Is that possible this PR is also valid for multiple publishers? Will: "MUST" in the PR should be tested (in response to Mo). Ian: It seems like ab unenforceable MUST. **PR 587 - Clarify gaps in object/group IDs at relay (Cullen)** The slides can be found at [here][4]. Cullen proposes [PR 587][5]. Cullen: The concern is the necessity of using sequential group ids in FETCH. Applications use non-sequential group ids must not use range requests. Mo: Are we talking about the Group IDs, not subgroup or object ids? Answer: Yes Gwendal: It helps a lot to know if there is a gap or not. If there is a gap, I won't do anything, don't cache. Cullen: No rejection to this. Cullen proposes to put all of the text (four concerns) into the draft to clarify that these cases exist. Mo: Will's proposal should be changed from MUST to SHOULD and the texts Cullen presented should be put into the draft. Martin: Cullen's explanations are a good starting point but I don't agree to put them in the draft. Gwendal: We need FETCH for different use cases. It can be signaled in the track. Add a flag to somewhere. Ian: I don't want to put a flag. The text describing the problems should be put in the draft. Will: I agree MUST is to be replaced by SHOULD in my proposal. I support Gwendal's approach. It would be much easier to add a flag to a track, to signal that it's not cacheable. We have a Jitter buffer to re-order the data arriving out-of-order. Cullen: I'm not keen on the flag. We need better designs to say "this range is very large". Using a flag puts complexity on relays. People will block tracks that do not have this flag. Mo: The problem is it's not known which tracks are cached and fetchable. Who should decide this? Mike: We need to address Gwendal's concern. Victor: Two kind of classes of saying. Use MOQ to deliver video that implies ordering, expectations of liveliness, etc.. Second is pub-sub architecture. Relays even don't need group numbers when the group ids are not incremented sequantially. We are trying to find a solution for two different two use cases. Wang: Time-sequencing groups makes perfect sense. Otherwise we need timestamps. What Will proposes makes perfect sense. We should have an obligation to have time-sequencing group ids. Suhas: There are two types of applications. Those that need ordered group ids based on time and those that don't need. To put a constraint about group ordering hinders innovation. Cullen: We need to write down the consequences of using non-incremental group ids. The flag idea should be a seperate PR. We need to work on the notion of DDoS attacks on relays. Ian can go over the text and take the minimal/optimum amount that will help people to understand. Will, Cullen, Mo, and Ian will work on Group Id PRs. **LUNCH BREAK** People in room think that we probably do need an in person after IETF 122. Proposal to do next meeting in Stockholm. May and June is idea. Streaming Tech Sweden is May 21 Tentative looking May 5,6,7 in Stockholm. Things on topics for IETF 122 * Announce issue * LOC Extensions * Absolute Join Fetch * Auth * Should we talk about DDoS * Demo of interop stuff * Sub publish frist ## Group ID Ordering Discussion {#group-id-ordering-discussion} (Scribe: Mike English) Proposed text under discussion (edited as discussed): 1) Within a track, the original publisher SHOULD produce Group IDs which increase with time. Subscribers to tracks that do not follow this requirement SHOULD NOT use range filters which span multiple groups in FETCH or SUBSCRIBE. 2) Within a track, the original publisher MAY produce unique Group IDs which do not increase with time. Subscribers to such tracks SHOULD NOT use range filters which span multiple groups in FETCH or SUBSCRIBE. Martin: Part of the issue we need to resolve is ambiguity about the interpretation of current Subscribe behavior - some understand it to have an implicit range filter (e.g. Latest Object onwards, nothing before that) whereas others did not share that understanding. So this text alone may not resolve everything. Ye-Kui: (expressed concern about how Subscribers would know they are constrained by these requirements) Victor: the SHOULD NOT seems to apply to all of Cullen's weird use cases which I think we should not do, but may not be what Cullen really wants. Maybe rephrase as: "If you do this... then..." or "MAY" 8 people liked option 1 5 people liked option 2 Nobody cannot live with the first option. 12 people are in favor of adding this text to the next version of the draft. 1 person is opposed to adding this text to the next version of the draft. Victor: objection is because we're making explicit that we support mainly one set of use cases, but also allow for some other weird use cases to be shoehorned in Mike Bishop: QUIC side-steps this issue by defining what happens when they arrive out-of-order, and let applications deal with it. Editor given green light to add something like this text for now. We have noted other ideas to keep in mind for the future. ## Victor: Delivery Timeouts and Ordering {#victor-delivery-timeouts-and-ordering} Slides: https://datatracker.ietf.org/meeting/interim-2025-moq-04/materials/slides-interim-2025-moq-04-sessa-delivery-timeouts-and-ordering-00 Two related mechanisms: Delivery Timeouts, Delivery Order (Group Order) This discussion is focused on Subscribe, not Fetch. Martin: Google quiche MoQT implementation treats delivery timeout as described (ingress to app to egress from app) with one addition: a timer is started after stream FIN to timeout any retransmission at some point. Deadline != delivery timeout. Deadline is the application goal for good QoE. (Slide 5) 70% on time delivery under this 80% BW case is relatively good. Best result was 75%. (Slide 7) 1s GoP size, 2s deadline (slide 8) Timings are per object "This one is very fun, it is my favorite graph" ~ Victor (Slide 9) Vertical lines are error bars 5s GoP, 30s buffer lost objects are always from the tail of groups, didn't skip whole groups Christian: have you tested a case where all groups have equal priority? (i.e. neither ascending nor descending) Victor: yes, previously (Jumping ahead to slide 16: "Alternative Design") Delivery timeout applies only if you actually have the next group Christian has also run similar simulations and found that a design like the one Victor describes here works quite well (Slide 17) (Slide 18, 19) Not entirely clear that the proposed "Alternative Design" makes much of a difference Mo summarized Victor's alternative design as: "If you have nothing else don't give up" Christian's simulation also included simulation of small network outages (like WiFi) which led to accumulation of queuing, and found that when the network returned you can recover quite quickly Mo and Christian speculate about how well this may or may not work with many tracks in flight, possibly on different QUIC connections so they cannot be in the same prioritization domain. Cullen clarifies this problem: imagine thousands of downstream subscribers for a relay of which 1000 of them share the same bottleneck link. If everyone sends these "useless" group tails, it may lead to more congestion in aggregate even if on an individual level it seems like we may as well send what we have. Mike: clarifying question about when the timer starts Victor: delivery timeout timer does not start until Group N+1 arrives Mike: a different way I could see this done would be to still start the timer at Group N arrival, but only reset if timer has expired AND Group N+1 is present. It sounds like this implementation effectively extends the delivery timeout because it waits to start the timer. Mo: seems useful for original publisher optimization (with only a few tracks), more skeptical about applying this to relays due to issues that may arise at scale / in aggregate Christian: reseting streams too soon leads to a seesaw effect in the video playback that is not ideal, possibly usability studies point to this being bad. Could use a usability study to see what's actually best at that level. Mo: changed mind. No longer thinks this is ever safe. Delivery Timeout is a way for a subscriber to say "don't waste my bandwidth on this" which may be especially applicable in the case where an end subscriber has a bunch of other streams coming in occupying bandwidth that the original publisher can't know about Victor: doesn't seem like delivery timeout is really about preserving bandwidth, but more about being able to discard objects that are not useful Mo: main takeaway is how good descending is. We might want to do more with descending Victor: yes, descending does seem useful Mo: idea - what if you instead changed the priority of the Group N stream to lowest when Group N+1 arrives (rather than reseting) Victor: I did not try that, but it's an interesting idea - I'll look at it Code is open source: https://github.com/google/quiche/blob/main/quiche/quic/moqt/tools/moqt\_simulator\_bin.cc ## Ian: Draft Reorganization {#ian-draft-reorganization} Slides not yet on the datatracker, but will be proposal: merge "Data Streams (sec. 8)" and "Object Data Model (sec. 2)" Alan: there is a bit of describing the abstract context for MoQT that's nice to do before jumping into the details Ian: Could just port over the bits that aren't framing? Cullen: leaving the details of on the wire framing in 8 makes sense, not that much text Some discussion about where to put subgroup and stream info... new section 3? Ian has direction: section 8 should be much more focused on just framing and related details Some discussion about top-down vs. bottom-up ordering, people feel like either approach can be a helpful organizing principle. Current draft mixes both approaches. Also some references are complicated to order no matter what (e.g. subgroups, groups, objects) Next slide: Swap Track Discovery / Retrieval and Sessions? Next slide: Stream Cancellation isn't in "8. Data Streams" Where to move Streams (8.4)? Maybe to 2.5? Or... after 3.1? Should probably be called "Data Streams" since it doesn't really talk about the control stream Should also highlight wherever this goes that there are also Datagrams Next slide: Connection URL is in Track, not Session Next slide: Stream Cancellation isn't in "8. Data Streams" Next slide: Add a single section for Error codes after 7? Martin: recently reorganized Cullen: nice to read right in something like Subscribe what the errors are for it and what they mean Martin: we can't put this under Control Messages because not all errors are. Probably want this to be 9. Next slide: 7. Frames 🤣 Martin: thought all these numbers were random Next slide: 7. Frames - Cullen's email Grouping and lifecycle ordering Cullen: proposed an order close to what an implementer would likely start to increment them Mo: also seems like timing diagram order Ian will try to land outstanding PRs and cut a draft-09 and then make these editorial changes and cut a draft-10 all by Monday. If anything major comes up to prevent that, we'll call it off and regroup after the next IETF. Reviewing outstanding PRs... Merged: * https://github.com/moq-wg/moq-transport/pull/713 * https://github.com/moq-wg/moq-transport/pull/723 * https://github.com/moq-wg/moq-transport/pull/717 * https://github.com/moq-wg/moq-transport/pull/702 * https://github.com/moq-wg/moq-transport/pull/686 * https://github.com/moq-wg/moq-transport/pull/687 Lucas has other stuff to do tomorrow. (Closing stale PR to revisit again later: https://github.com/moq-wg/moq-transport/pull/546 ) Alan will reapply datagram stuff that was lost in merge [1]: https://datatracker.ietf.org/meeting/interim-2025-moq-03/materials/slides-interim-2025-moq-03-sessa-update-to-switch-slides-00 [2]: https://datatracker.ietf.org/doc/html/draft-gurel-moq-track-switching-01 [3]: https://github.com/moq-wg/moq-transport/pull/727 [4]: https://datatracker.ietf.org/doc/slides-interim-2025-moq-03-sessa-group-id-order-and-gaps/ [5]: https://github.com/moq-wg/moq-transport/pull/587