Minutes interim-2024-moq-23: Wed 16:00
minutes-interim-2024-moq-23-202409181600-00

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