MOPS IETF 109 Virtual Agenda

Admin (5 min)

Note well
Agenda bash
Jabber scribe: Chris Lemmons
Minutes taker: Mike English

Experiences (30 min)

MeetEcho reporting on their experiences from IETF 108 (Lorenzo Miniero)

• Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-mops-meetecho/

• Presentation (Lorenzo):

  • overview of previous setup (for remote participation at in person meetings)
    • audio mixed
    • dedicated laptop for streaming from the room
  • architecture overview
  • platform based on Janus open source WebRTC server
  • WebRTC is a good fit for the conversation portion of a virtual meeting
  • challenge: how to enable audio mixing?
  • Audio
    • AudioBridge plugin enables mixing active participants into stream (only those who are unmuted, to optimize CPU load)
    • when a participant presses the mic button they switch from receiving audio from the mixed stream to becoming an active participant on the audiobridge
  • Video
    • Unlike audio, there is no video mixing
    • Mostly a one-to-many scenario (one presenter, multiple viewers)
    • VideoRoom plugin (a WebRTC SFU)
      • supports RTP forwarding (could forward video stream elsewhere for post-processing)
      • forwards to Streaming plugin which is used to broadcast stream to support many passive viewers
        • can also further forward to multiple instances of the Streaming plugin for horizontal scalability
  • Summary
    • active participants connect to AudioBridge and VideoRoom plugins
    • audio and video streams forwarded to Streaming plugin instances for broadcast to passive participants
  • multicast
    • enables efficient distribution from AudioBridge and VideoRoom to fan out Streaming plugin instances
  • pre-recorded presentations can be sent as RTP streams (e.g. with ffmpeg or gstreamer)
    • issue: volume slider does not work because there is no AudioBridge to allow for mixing
  • now pre-recorded presentations can be sent as WebRTC streams to the AudioBridge and VideoRoom plugins, which allows for mixing
  • broadcasting to YouTube Live
    • starts with same RTP forwarding functionality as before
    • mixed via MixerBroadcaster (MCU) and then sent on to the CDN

• Discussion:

  • Cullen: how many participants are reasonable to combine in this way?
    • L: 20-30 people have been acheived in some other contexts
  • Jake: suggests testing by all 40 people unmuting :)
  • Éric: single Azure DC or world-wide?
    • Alessandro: single DC in Europe
  • Leslie: question about reusability(?)
    • L: A/V setup is reusable in other contexts, some functionality like raising hands/queue is more specific
  • Jake: write-up multicast in Azure?
    • L: no write up, but it works (?)
  • Éric: thank you for the IPv6 streaming
    • L: yes, thanks to open source Janus
    • Alessandro: The weird thing about Azure IMHO is that they’re NATting IPv6 though! But it works

Related IETF work (60 min)

Media Operations Use Case for an Augmented Reality Application on Edge Computing Infrastructure Renan Krishna draft-krishna-mops-ar-use-case-01. (Renan Krishna)

• Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-mops-media-operations-use-case-for-an-augmented-reality-application-on-edge-computing-infrastructure/

• Presentation (Renan):

  • InterDigital develops technology for AR/VR products (e.g. 360 streaming video)
  • draft: draft-krishna-mops-ar-use-case-01
  • Proposed Use Case: AR tour of Tower of London
  • How?
    • AR app processes scene, identifies objects, generates high res images to overlay over scene
    • hard timing constraints
    • requires adaptive bit rate (ABR) to achieve timing constraints (trade off QoE for low latency)
  • requirements for ABR algorithms for this use case
    • offloading computationally intensive tasks to Edge devices
    • AI/ML models can help achieve better results
    • dynamically changing ABR parameters
    • handling conflicting QoE requirements
    • side effects of particular bit rates
  • references

• Discussion:

  • Cullen Jennings: requirements question - where does few milliseconds requirement come from?
    • R: devices are quite fast, but problem is in synchronizing the overlaid objects
      • computing location AND generating the video
      • Cullen: headsets on the market today already do SLAM (Simultaneous localization and mapping) algorithm, so what is it the edge devices need to compute?
        • R: need to recognize objects and generate video
  • Jake: Is it defined whether you’re using point cloud, or rendering from a point of view, do the requirements differ between options like these?
    • R: Starting by looking at the general set of problems which would include both of those techniques, this doc is big picture, not looking at specific technique or algorithm
  • Jake: Are you looking for WG adoption of this draft, or sharing it for information/feedback?
    • R: Would like feedback from the WG, possible adoption at some point
  • Spencer: Does this work going forward look more at communications aspects, or more at deployment of edge computing?
    • R: Looking specifically at the adaptation aspects of ABR algorithms in this context, inputs to adaptation decisions
  • Shuai Zhao: Trying to understand algorithm differences for AR/VR/360
    • R: For AR/VR the bandwidth requirements change very rapidly. Problem is specific to AR/VR use cases becase the ABR parameters change very rapidly, whereas in other contexts ABR parameters change, but not as rapidly.
  • Leslie: Future of this document?
    • R: Would be looking for adoption by the WG at some point, if the WG agrees, but also looking for feedback on whether this is an appropriate approach.
      • L: With 40 people here, we’re not quorum. Maybe make some updates and take to the mailing list. Any objections? (none heard)
  • Spencer: Is the work here mostly looking at making recommendations in the operations recommendations space, or is there also protocol work that needs to be done?
    • R: Would be happy to identify issues with protocol gaps, as well as recommendations for operators (in line with MOPS)
    • Leslie: protocol work doesn’t get done here, but we can help identify issues and other groups

WebTransport (Victor Vasiliev)

• Slides: https://datatracker.ietf.org/meeting/109/materials/slides-109-mops-webtransport-ietf-109-mops-00

• Presentation:

  • WebTransport is a new combination of a protocol and an API being jointly developed by IETF and W3C
  • WebRTC data channel has “a lot of rough edges”
  • expose semantics of QUIC, etc.(?)
  • Target applications
    • “WebSockets for UDP”
    • “WebSockets without head-of-line blocking” (HoLB)
  • Domains:
    • Web games
    • Streaming
    • many others
  • features:
    • Streams
      • like connections, but cheap to create and cancel
    • Datagrams
      • can be used for unreliable transport
      • can be multiplexed
  • Requirements
    • TLS
    • Congestion Control
    • origin checks
    • consent to send data
    • URIs
  • Why use it for media?
    • oriented toward client-server (no need for ICE)
    • can use infrastructure built for QUIC, take advantages of improvements to stack made for HTTP/3
    • inherently bidirectional, no need to pull
    • more extensible than with strict HTTP semantics
  • status
    • WG in IETF & in WG in W3C
    • part of it (QuicTransport) is implemented in Chrome and available as an origin trial
  • status of media over WebTransport
    • currently no effort to standardize video over WebTransport
    • Twitch presented experience report implementing video streaming over WebTransport at webtrans wg meeting yesterday
    • multiple efforts to use WebTransport for streaming games

• Discussion:

  • Luke Curley: Twitch mostly looking at WebTransport as an HLS alternative to eliminate HoLB issues. May be interested in standardizing eventually, but it’s very early.
  • Mike English: Any open source examples of sending media over WT?
    • V: None known, but simple examples using media exensions should not be difficult.

MOPS onwards (15 min)

Milestones — revisit and review

• Leslie: Let’s launch a discussion of whether we have the right milestones for our working group
  • Discussion of current milestones:
    • Had discussed a SMPTE doc, SVA doc
    • …
• Jake:
  • First question: Do we have any insight into how milestones feed into evaluation 1 year from now as to whether the WG remains active?
    • Éric: will be eval 1yr from now. Documents are not the main goal of MOPS, so achieving document goals not required for WG survival
      • Leslie: Sounds like while we won’t be evaluated uniquely on documents, we should be clear about what we’re doing.
      • Éric: Yes. WG chairs can move milestones, etc.
      • Kyle: Seems to be just a matter of getting energy of activation to make some of these docs happen.
      • Leslie: Yes, partly some of these things we had planned were deferred just due to 2020 happening, …
      • Glenn: Should keep both SMPTE and SVA docs, too early to discard.
        • Leslie: Who should we contact to move these forward?
          • Glenn: Sanjay and myself should talk about SVA to see if we have suggestions on who can work on it.
• Spencer:
  • Two things:
    • Outreach to other groups
    • Recommendations
    • operational considerations draft
      • hasn’t talked much about edge compute, might end up in a different document (?)
        • is anyone else thinking about operational considerations for configuring edge computing?
          • Shuai: … goes to S6 work(?), current draft is too broad
          • Spencer: Maybe good to involve 3GPP liaison in this discussion? (Whether in MOPS or somewhere else)
• Leslie:
  • takeaway:
    • we should definitely update the milestones for the operations considerations document
    • keep on working on other two docs(?)
    • take to mailing list
• Leslie: Any other business?
  • (none heard)