MoQ Interim 18 Sep 2024 Bluesheets 1. Martin Duke (Google) 2. Victor Vasiliev (Google) 3. Ian Swett (Google) 4. Erik Herz (Vivoh) 5. Suhas Nandakumar (Cisco) 6. Cullen Jennings (Cisco) 7. Mike English (id3as) 8. Daniel Fay (Meta) 9. Mathis Engelbart (TUM) 10. Manish (Dyte) 11. Dinesh Adhithya (Zoho) Scribe: Mike English Bikeshedding "peeps" vs. "SubGroups" (Cullen's agenda bash) * Cullen thinks we need consensus on the name before we can merge * Martin pointed out that nobody voiced strong objections to name, but most offered their own alternative proposals * on the call nobody voiced any significant objections to "SubGroups" as a name * Martin to take to the list MoQT Issues * PR 525 Clarifying Subscribe & Announce https://github.com/moq-wg/moq-transport/pull/525 * Cullen: two things to talk about: * 1) Authentication part - let's ignore that for now * assumption that auth will be modeled after how auth works in CDNs today * let's not resolve those comments just yet, motion to defer * A couple thumbs up on deferring (Ian, Suhas) * 2) Normative behavior - handling of duplicate objects by relays * Duplicate is same track name, same group, object * There will be rare cases where relays will receive duplicate objects (reconnects, etc.) * Cullen's initial proposal was to drop the duplicate - now thinks this was misguided * New proposal: newer object should overwrite * Question: should we forward it? * Relay to relay protocol is out of scope, this is about what the relay network as a whole does * Ian: At a high level the proposals here seem implementable and straightforward * Cullen: will update to say later objects should overwrite, but not re-forward * Cullen: other comments on this PR we should discuss? * Ian: MUST should be a SHOULD because server/relay is gonna do what it's gonna do * Cullen: agree. Was more of a wish * Suhas: seconding this comment * Mo: great PR, make sure we schedule the deferred auth conversation * Mo: nervous about changing MUST vs SHOULD, gets strange to claim objects are immutable and then require relays update them * Martin: should we note this as undefined behavior to call out risk of depending on it? * Mo: yes. that seems like a good idea * Ian: Also thinking about abuse here... * Mo: yes, and even "legitimate abuse" to reduce my CDN bill :P * Ian: ... * Cullen: options are MUST ignore / MAY ignore / MUST replace? * Ian: MAY replace? Seems like we could say that, too * Martin: MAY seems fine. Things will come up. * "MUST replace" sets up situation where publisher can force relays to do things they probably shouldn't be able to * Cullen: has a path to update this based on feedback * Cullen: can work with Ian to make tweaks and it sounds like it should be ready to merge * Martin: has a few tweaks, but nothing major, seems fine * Ian: may be agenda time available to discuss auth at interim in Cambridge * Martin: auth is probably 3rd on the list after other things * Ian: would be good if someone else in the WG can make slides to speak to auth * Suhas: may be good to gather requirements * Martin: maybe an intro to auth for a timeboxed hour (but wants to check w/ Alan before committing) * Martin: Alan asked about agreement on use cases when we talked about Fetch and responses were mostly proposals... * we need to start by agreeing on problems we're solving * /PSA * PR 529 by Mike * Ian: small and straightforward - only question: What does timeout mean? * Mike: transcribed from original issue, don't actually know what all was meant by that * Cullen: seems to recall it has to do with relay needing to cleanup resources? * Might add some text to the relevant section to talk about when to timeout * Otherwise all thumbs up on this * Ian to merge * followup: someone can add more text in another PR * Ian: eventually we'll have text about when and why to use each error code, but we don't have that for anything here yet, so this is fine to start * Mike opened issue for Timeout clarifications so we don't forget: https://github.com/moq-wg/moq-transport/issues/531 * PR merged * PR 520 (Suhas) * Suhas: main question to get consensus on: when do we need this header? * Ian: yes, that's the main thing I'd like to discuss, too * Cullen: doing this only for control messages right now doesn't stop us doing it for data later, let's not let that stop us * Mo: need to be careful because this spans the whole message, including extensible tlv things * Mo: Clarifying that this always encompasses all of that, but not the type, right? * Suhas: yes * Martin: seems like gaining CPU effeciency at the cost of wire effeciency, not convinced this is an actual DoS vector * As an individual would probably not do this, but no major problem with it * Ian: if you get a message type you don't understand, what are you going to do? * if it's a connection close error, it's easy, but if you're going to skip the message, this is helpful * Martin: ... setup parameters imply.. ??? * Ian: ... * Mo: if we have relays that want some relay-to-relay control messages then we may end up with some MoQ implementations that don't understand every message * Victor: generally enthusiastic about lengths, most protocols do except QUIC and QUIC has fixed datagram sizes so you don't need it * Victor: ... * doesn't like adding to one, but not the other * but ok with proposal (not worth blocking for that reason) * Mo: important to keep low bandwidth cases like audio in mind, but this wouldn't apply to datagrams since you're already doing that * Cullen: fine with doing this for control, nervous about what it does for audio b/c hasn't done analysis yet, would like to be "less overhead than RTP" * Ian: would anyone object to adding a length for control messages now and then we could add lengths for other things later? * Ian: coming back to skip vs. error, we should probably define that * Martin: we should assume ... * Mo: * Martin: not too much to ask for a universal MoQ parser, should at least be able to parse everything even if you don't implement all behavior * Mo: still the number of message that are use case / role specific could grow to a large number * Martin: rule up to now has been that you kill the session if you get something you don't understand * Ian: coming back to why it's not clear what the motivation for adding this is if not to allow skippable messages * Martin: tradeoff network bytes vs. CPU. Instincts still against it * Suhas: leaning towards allowing skippable messages, some things could be DoS vectors * Ian: ok, for now we can add this and keep the current behavior about closing sessions * Last 10 minutes: Fetch problem statement * Ian: Alan put together and sent to list already * Cullen: relays don't need to know if there are gaps * Cullen: if there are gaps, go upstream * Martin: ... * Cullen: still don't see problem. Point 2 doesn't seem like a valid problem statement. * Cullen: also point 3 isn't a problem or true * Ian: as an individual, tend to agree, but maybe the draft isn't clear enough * Mo: never talked about dynamics of a relay - how does it see that something is live or that it's missing something, etc. * we don't describe how objects 10, 200, or more ms behind live might be delivered differently * what's the behavior of a relay when it goes to do an upstream fetch? does it aggregate? etc. * may also involve time dynamics * Suhas: fetch has to answer questions either from cache or source of truth * subscribe cannot solve this because if it's going back it's no longer live, it's in catchup mode * subscribe is live, you get what you get * Martin: why is stream flow control and id not backpressure? * Ian: it's terrible backpressure * Victor: also if you have two fetches in parallel * Mo: requires stuff from the QUIC stack, too, right? * Ian: hard to implement as a high availability relay * Martin: starvation is a question of priority... if the subscriber is overloaded it'll stop accepting data from the QUIC stack, hence queues fill up, etc. ... * Ian: ... * Martin: you set a higher priority for realtime * Mo: you'll always compete and clobber if you're doing gross flow control at the QUIC layer * Ian: if you can have infinite number of streams, you can solve a lot of problems, but most implementations are probably not willing to do that * Martin: encouragement to take this discussion to the list and have as much of it as possible there before we sit down at the hybrid interim in Cambridge