IETF MoQ Working Group Interim 2023 Jan 31 - Feb 1

Day 1, Morning Session

Adminstrivia

Notes for the morning session: Martin Duke, Spencer Dawkins

We started with introductions, which was nice ...

Goals for this interim meeting (see chair slide)

• Feedback on requirements
• Learn from implementations
• Adopt drafts by Yokohama
• Begin work for interop
• Win

Also, apparently one unstated goal is to upgrade Alan's MAC ...

Results of real world experiments & discussion

WebTransport frame per stream transport performance, Bernard Aboba

Slides are here.

Jonathan: [referencing pipeline slide] You need to have a jitter buffer too?

Bernard: yes

Rajeev: Is the result Chrome-specific.

Bernard: Codecs differ between browsers, though they are all supported in Chromium.

Rajeev: It doesn't work in Firefox.

Victor: WebTransport is a work in progress in Firefox

Christian: Close is in a race condition with Reset

Will: Isn't need for datagrams a function of the bit rate?

Bernard: yes, as packet sizes expand, Datagram might become more valuable. The effects are at the 20 KB level (bigger P-frames).

Rajeev: Trying on Chrome 109...

Ted: Debug offline, please

Warp implementation and results, Ali Begen

Slides are here.

Kirill: Have you compared it with first chunk download time -- it's unique in terms of size

Ali: We can test that, but we like our metrics

Rajeev: Are active speed tests using a segment you've already downloaded? But then you're just hitting a cache! I worry that it's sitting in an edge cache, which is not the same as BW for subsequent segments.

Ali: It's a direct connection, there's no caching.

Rajeev: Server ETP changes in sync with the active speed test. Are they related?

Ali: Speed tests try to push cwnd larger.

Rajeev: So, the speed tests are affecting the measurement.

Buck: How is the active test so far below the cwnd?

Ali: It's a TCP test, not the same thing.

Rajeev: Consider tooling to roll active tests into the same connection.

Ali: There are pros and cons. We're looking into it.

Warp in QUICR, Datagrams and Congestion, Christian Huitema

Slides are here.

Rajeev: Why do you send the number of objects in the previous group? QUIC has ACKs

Christian: Because they are sent in parallel. You want to find out if more stuff is coming from the previous group.

Jordi: How is the decoder handling losses if it takes too many retransmissions?

Christian: Just close the media stream

Jordi: So why datagrams?

Christian: We can deal with fragments insetad of packets, so we can pipeline on a fragment basis and reduce latency.

Roberto: Isn't this just an API problem?

Christian: WebTransport lacks an interface for datagram success

Buck: latency is about forwarding through relays, which is not really a WebTransport thing?

Martin: Why not just use strict QUIC priorities instead of Datagram?

Christian: App can do better.

Rajeev: Priorities are based on timestamp, or statically set?

Christian: Two types: One is e.g. (audio > video) in QUIC, another is newer > older.

DTP, Chuan Ma

Slides are here.

Kirill: latency will be lower for DATAGRAM because there's loss!

Chuan: We're just trying to show that cancelling retransmission has some value:

Kirill: You can do that with RESET_STREAM too.

Christian: You can put lost datagrams in the control stream. This simplifies things.

Rajeev: you have metadata in headers. What if intermediaries act on this metadata to prune in-flight?

QUICR, Suhas Nandakumar

Slides are here.

Rajeev: On your slide that shows three subscribers, two are using the relay and one is using the origin server. Is that hardcoded? Is it hard for the subscriber to know where to subscribe/to know what to do?

Suhas: We can do a variety of things, but this is what the demo is doing now.

Jordi: Is this a lossy connection?

Suhas: We retry losses with a limit of X

Rajeev: How would I set this up on my infrastructure?

Suhas: the information is there. We can share the terraform scripts.

Base Protocol

Warp Draft Presentation and Open Discussion, Luke Curley, Victor Vasiliev

Issues list discussion, including open PRs

Day 1 Afternoon Session (MoQ-4)

Note Takers : R. K. Rajeev, Will Law

Spencer Dawkins - Requirements Draft Overview

No slides. Here's what Spencer is planning to say, while projecting GitHub issues.

• James and I have been working with Suhas to identify requirements that seem relevant for topics that have been discussed since IETF 115.
• Talking with Suhas has been very helpful, and we hope to hear from other working group participants as we move forward
• We've been creating issues in the GitHub repo, and we have a total of 14 open issues
• Of these, 5 depend on other, unresolved issues, so we're deferring them for now
• We have three issues we tagged as "priority for discussion"
• My suggestion is to start at the bottom, and talk about each of these issues, and answer questions
• 20 minutes now isn't enough to resolve these three, at an appropriate level of detail, and at least one topic is likely to come up during various presentations today, so I've asked the chairs to put some time on the agenda tomorrow, to come back to these issues, after people have had time to think about them

Discussing Issues List -- https://github.com/fiestajetsam/draft-gruessing-moq-requirements/issues

Focus on 3 issues :

• Supported media packaging #78

  • Jonathan : Should we support time sync between streams?
  • Suhas : we dont have something defined yet, but definitely see the use case for this
  • Spencer : possibility to reuse certian container formats?
  • Suhas : We cant use a raw es, need timestamping coming in somewhere.
  • Will Law : Do we go with open negotiation between pub-sub, and allow for fine grained parameter negotiation for containers like CMAF.
  • Ted : Should not limit codecs now, allow for future codecs to be used without maor changes. Negotation is happening at the application layer, and the transport is neutral for that. (Note : this is my personal opinion, and not the view of the chairs)
  • James : WARP Currently advertises multiple formats, and sub chooses from there.
  • James : Disagree with the specific CMAF focus of Will, May hamper our ability to be container agile.
  • Mo : Browsers already support web codecs, may not need to force CMAF, can just use the raw formats. Volunteer to add some text to the draft around this.
  • Roberto : Should support something other than CMAF, can the protocol support different manifests, can manifests chsange in the course of a session? Variation in Mux styles and priorities?

• Next level of details on "configurable latency" #80

  • Spencer : Ticket opens out possibilities on the configuration points that will impact latency
  • Cullen : Need clarity on buffer sizes as an example. What about configuring Buf Sizes impacts latency. Not sure we have an good idea yet of exactly what options will affect this.
  • Spencer : This may be a red herring, but implementations can have many config knobs that may impact this.
  • Will Law : Configurable latency may not mean what we think, and is usually a function of the stream parameters. What do we mean with potential configurable latency regimes. Is the target realtime/interactive latency, or live event type latency. Configure how we carry various components of the stream in different streams/datagrams, may change the latency characteristics.
  • Morton : Maybe configurable latency may be used as a means of hinting how long the client attempts stream recovery before giving up
  • Christian : Would like to see a clear description of what we are building and the scenarios , which in turn will have independent requirements like the latency range.
  • Suhas : We should allow tools that support the groups charter objectives, and allow as much application control as possible.
  • Jonathan : Who decides the latency range? Sender or Receiver? Receiver choosing the target latency is probably much harder.
  • Spencer: It's worth saying that the DTP over QUIC presentation earlier wasn't looking at relays (and cascades of relays, and cascades of relays that cross administrative domain boundaties)

• Add Definitions of Relays, Caches, Replication Points, and Media Translators #81

  • Spencer : Environments with relays also need to be considered more closely. Need to understand the dynamics of the path between the first pub To the endpoint Sub. Should this be a concern for the MoQ protocol itself?
  • Ted : (AfC) Privacy and Security Properties : Want to limit points of potential legal intercept. IETF general sentiment is to limit to the the extent possible. What do we want the path elements to be able to see, in order to provide the correct behaviour, and default everything else to be inside the encrypted payload.

14:31 Warp Draft Presentation and Open Discussion -- Luke Curley, Victor Vasiliev

Slides are here

• Merged PR's

  • 46 - Basic Wire Format

  • 55 - Object Model

    • 3 hierarchical objects
      • Broadcast contains Tracks, URN
        • Christian : consider possibility of tracks may originate at different positions in the delivery workflow. Also, relay switching on mobile endpoints.
      • Track have ID, properties, container formats, contains multiple objects
      • Objects are the minimal unit, may be GoP/Frames etc. Can have timestsamps.
        • Roberto : VR Related - Different levels of detail for an object. How to handle discontinuities, potential breaks in the stream at source.
          • Not yet fully defined Need to identify use cases
        • RajeevRK : Relays that also append tracks use case
        • Suhas : Need to discuss RN mechanics, How do we indicate to the endpoint what the objects are, and if they have any interdependencies? Tracks carrying a container format, Init segments? For Multi Publisher scenarios, how do we handle track IDs? Entities handling compression cannot deal with encrypted streams, unless they reboradcast.
        • Jonathan : MUC - Single broadcast with track per participant OR broadcast per participant ?
          • Expect to be treated as separate broadcasts per participants - if we want to share a broadcast, the clients have to cooperate, which is non trivial. A higher abstraction layer should handle compositing of the various broadcasts.
        • Kirill : Do we have a way to say explicitly that we can hadle partial availability?
        • Roberto : SSAI question Vs. discontinuities.
          • Send tracks as separate tracks and implement switching.
          • Split of what is needed by the relay (stuff in the Network protocol) vs what the decoder needs(stuff in container).
      • Christian : Assume an encrypted container, opaque to the relay?
      • Default to everything being in the container, and carefully surface some items out, keep it minimal.
      • Jonathan : Receive Side Reassemble, may need similar data as a relay, but also depencency list? Relays also do not strip any bits.
      • Will Law : Can we abstract out timestamps, and use it to simplify non temporal seek use cases (For Eg VR FoV shifts).

  • 63 - Catalog and Subscribe

    • Jonathan : Broadcast Dynamic Tracks?
    • Ted : (AfC) Composition of broadcasts may be a better way to handle track addition/deletion, etc.
    • Roberto : Instead of container format, could it be a how to remux it into a container? Ad repetition?
    • Suhas : Multi Camera system, separate tracks?
    • Kirill : Manifest - Want to provide a list of resolutions, other options.
    • James : Will complicate things with DRM, init now needs to potentially be unenctypted?
    • Cullen : What parameters do you end up getting from the init segments.
    • Rajeev : Need more work to ensure manifests functionality is fully replaced
    • Christian : Catalog may have a lot of information leakage possibilities.
      • May also have support for current manifest formats at the catalog level.
    • Roberto : Catalog Vs. Manifest -- Manifests can be too verbose, not ideally suited for Live? Remux use cases can be costly?
    • Will Law : init's may not be a long term sustainable, adding boxes via ISO may be very inflexible. Some way of having catalog carry the base manifests.
    • Kirill : Keep a focus on making things work with 1 x RTT, avoid the need for multiple transactions.
    • RajeevRK : Independent manifest level metadata Va using the Init to carry everything?

Coffee Break

• Subscribe / Unsubscribe
  • Object
    • Christian : Control Stream Open/Close Vs Sub/UnSub ? Avoid the URI in every object, potentially reuse a control stream ID to remain unique.
    • Roberto : Turn the clock back, go back to the older version of Warp?
    • Suhas : Allow subscription at the broadcast level?
    • Cullen : Priorities ? We need to decide on a single format for the priorities value.
      • preference is to use a large value space, so that we need not restart or reprioritise.
    • Christian : apping between your large priority space to underlying quic priorities, current quic implementations have a much smaller priority space.
    • Lucas : Implicit ordering like h3 stream ID, may not apply here. Offer to write up additional text regarding ordering/priorties for the next IETF.
    • Mo : Incrementing time prority Vs. Explicit priority hierarchy -- time has not been successful in the past.
    • Jonathan : Priority levels Scoped to the Broadcast or Track?
    • Will Law : Globally Deterministic Broadcast URL -- current HTTP behaviour -- Could Leverage DNS to do this.
    • Ted : DNS hostnames are not ideal for URN if there is a requirement to be permanently unique.
    • Christian : GoB -> Object -> Track -- Where are the identifiers?
      • Most of these Questions need further contributions to be answered.
    • Roberto / Will Law : Identification of Uniqueness ? Cache Key ? In the Relay Broadcast Use case, do we even need to be unique?
    • Network Flow - 4xRTT from start to 1st object
      • Cullen : Catalog Description? list of catalog entries? needs to be refined. Also, should catalogs be immutable? Merging capabilities into the catalog?
        • Yes, there should be means to update/modify a catalog.
      • Suhas : Ingest Scenario -- Publish goes direct to the origin? Potential for server to reject a publish -- for eg, unsupported codec.
      • Kirill : Clarification only.
      • Christina : Can the client subscribe prior to the catalog becoming available?
        • This comes close to the HTTP Pull model, which may work better in some cases
      • Martin : Basically, Catalog URL == playback manifest url.
    • 1:n flow
      • Will Law : Do we blast catalogs to all relays? Content Prewarm to the edge can get expensive?
        • Agreed that it should be at least partiallly client initiated.
      • Roberto : Geo Distributed services? Discovery of best relay to connect to? Need to make this efficient to acheive low latency.
        • Catalog is distributed every for discovery reasons. Relay discovery isn't something that is standardized. May need to have this happen at the application layer.

Issue List Discussion

• Ted : Summary and overview of what we have to do. Transition of all of our existing mental individual use case models into a set of general abstractions that accomodate everyone's use cases. Discussion of what we need to discuss on Day-2
  • Christian : Vote for the Reconnect / network change issue, vote against Congestion Windows.
  • Spencer : Vote for Definition of Network entities (Relays, intermediaries etc)
  • Suhas : Identification of minial data set that the relay needs, interaction between client and edge relay.
  • Will : Object model should be nailed down, Abstract content requests - other than just the head of the live stream?
  • Alan : (AfC) What is the minimal set we need to define to make an initial standard that is implementable?
  • Spencer : Agenda for Day 2 Question

Chair wrap-up and agenda adjustments for Day 2