MOPS IETF 111 Session

July 27, 2021

Admin [5 min]

• Note well
• Agenda bash
• Jabber scribe
  • Kyle will watch Jabber, but not clear how badly we need that with Jabber as part of Meetecho ...
• Minutes taker (https://codimd.ietf.org/notes-ietf-111-mops#)
  • Jake except his slot
  • And Spencer will kibitz

Industry News/Experiences [30 min]

• Streaming Video Alliance (SVA) 5G paper (Brian Stevenson) [20min + discussion]
  • 5G and the Edge Cloud for Streaming Video
  • "What does delivering content over 5G mean?"
  • Jake: is service providers picking congestion controllers that make their stuff look better at the expense of everyone else?
  • Brian: we're using PCC, which is highly configurable. PCC has utility functions that can be tailored in many different ways, and can provide multiple utility functions in parallel - even on a per-service basis. PCC is being deployed as part of the Linux kernel, so it really just replaces CUBIC and adds policy. Also, "edge" means a lot of different things to different people.
  • Jake: so this is like an AWS instance? Do people pick which locations you're going to be running on?
  • Brian: there will be a lot more data centers in the network. They're going to try to run as close to the user as possible, but you can also go "up the stack" if the edge is really busy.
  • Leslie: when will the SVA technical brief be available?
  • Brian: a couple of weeks.
  • Leslie - I'll send a pointer MOPS when it's released.

WG Docs [20 min]

• Ops Cons (Jake Holland) [10 min]
  • We do have one new issue, as of about 10 minutes ago, in the repo ...
  • PR #85 is important, but it's proceeding nicely, and you can follow that in Github (and please do).
  • Any comments here on Slide 5, proposal for next steps?
  • Glenn - I have been watching, and I think you're headed the right way here.
  • Leslie - are we still more or less on track for Working Group Last Call on this document? "In two weeks" qualifies as "more or less" ...
  • Any comments that you can make now, and not wait until WGLC? Leslie will be checking WGLC commenters against the IETF 111 blue sheet :-)
  • Jake - but of course doc-improving comments are welcome even during last call
• Media Operations Use Case for an Augmented Reality Application on Edge Computing Infrastructure (Renan Krishna) [10 min]
  • draft-ietf-mops-ar-use-case
  • Volunteers to review (within 2 weeks of the end of the IETF meeting)
    • Jake Holland
    • Spencer Dawkins
    • Chris Lemmons
    • Kyle Rose
    • Luis M. Contreras
  • Kyle to help the authors get this onto GitHub

Related IETF work [20 min]

• Packet Difference Significance for Media Scalability (Lijun Dong) [10 min]
  • Kirill: Is there a way the macroblocks are exposed? They're not visible in e.g. containers, right?
    • Lijun: This is something the codec would have to do
    • Kirill: But HTTP wouldn't have any such information even if it came in
    • Lijun: Yes, we think that's possible to do though at the application layer
  • Kirill2: Can we leverage what's already in transport, e.g. quic datagrams?
    • Lijun: Yes, at implementation level this is a good observation but I'm trying to bring this issue to your attention. This isn't an alternative, so much as complementary.
  • Jake: is there a proposed API or a paper or draft or something?
    • Lijun: No, this is the first draft, just raising for discussion
    • Jake: diffserv can do this in network, using sockopt, if this is for a use case where diffserv is applicable. different classes for the same flow is possible, since classes are per packet in the network.
  • Spencer: it's going to be hard for "the network" to do this in quic because QUIC internals are going to be hidden from network elements, unless you either (1) do the signaling outside QUIC, for example using DiffServ, or (2) add some kind of signaling to the QUIC public header, or (3) terminate the QUIC connection on a network device that does the processing and regenerates the packets on another QUIC connection.
    • Lijun: Thanks, we haven't looked into the pros and cons of how to address this with different higher level protocols yet.
  • Leslie: next steps are join mops and send a paper, hopefully we can get some discussion
  • Jake (in chat): check out SRT also, it has some features to support this kind of thing.

• RUSH Reliable (Unreliable) Streaming Protocol (Kirill Pugin) [10min]

  • Hesham: Is there a doc?
    • Yes, there's a draft:
  • Hesham2: What congestion control?
    • Whatever quic does, Rush is all inside quic
  • Jake: I did see this draft, can you make it more generic than audio/video-specific pieces? Like SRT?
    • anything can be sent in those blocks, it's just up to the app to specify
  • Shuai: New codec support? Which ones?
    • Thinking on our side is ingestion and delivery protocol similar, but not there yet. ingestion was first attempt.
  • Shuai2: Live streaming? Just HTTP or did you have another in mind like RTP?
    • HTTP is so ubiquitous it seems we have to use that, it's not bad and it's well-deployed.

  • Maxim: SRT raised in discussion, from SRT we wanted to say we have soemthing over datagrams. The advantage is about latency, we're presenting on friday's side meeting.

    • Kirill: streams are easier to work with, haven't dug into datagrams yet, but maybe. Will discuss more friday.

  • Notes: SRT over QUIC Datagram RFC draft preview: https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html. Other approaches also include RTP over QUIC Datagram.

MOPS onwards [15min]

• Milestones — revisit and review
  • [discussion cut due to time overrun]