Media OPerationS (MOPS)  
IETF 114  
10-noon EDT, July 26, 2022  
Chairs: Leslie Daigle, Kyle Rose

## Admin   {#admin}

*   Note well
*   Agenda bash
*   Jabber scribe
*   Minutes taker https://notes.ietf.org/notes-ietf-114-mops#

## WG Docs   {#wg-docs}

### Ops Cons — last follow up from IETF last call and IESG review   {#ops-cons--last-follow-up-from-ietf-last-call-and-iesg-review}

*Spencer Dawkins*

*(Spencer asked the working group who had reviewed the changes since
-10, and very few people in the room raised their hands, so we didn't
review the diffs in detail)*

Jake Holland: I cornered Roman after the plenary to discuss his DISCUSS.
Roman has some text they hope to contribute in the nearish future.  
*(Spencer led the working group in a round of applause for Erik,
prodding Roman about his DISCUSS)*

Leslie Daigle, as chair: Are there any objections to the editor's plan
on the last slide?  
Room: *no response*  
Leslie: There will be another chance to review on the mailing list.

Eric Vyncke, as AD: As there have been numerous changes (mainly
editorial, clarifications -- no technical changes, hence no need for a
last call), I would strongly encourage the working group to review the
document while we can still change it.

Spencer: We are working on responding to comments rather than attempting
to evolve the document, and almost all the text changes are tagged to
issues from reviewers, so the changes have been constrained by that.
What we want to make sure is that the working group agrees with revised
text.

### Media Operations Use Case for an Augmented Reality Application on Edge Computing Infrastructure   {#media-operations-use-case-for-an-augmented-reality-application-on-edge-computing-infrastructure}

*Renan Krishna*  
https://datatracker.ietf.org/doc/draft-ietf-mops-ar-use-case/

Joerg Ott: I would have loved to have seen some numbers: ranges, typical
characteristics. I think it would be helpful to be more specific.

On the second-to-last bullet (migrating state) I think weould like to
have a careful distinction between

Cullen Jennings: The webex hollogram transmits a lightfield and presents
it in a photorealistic AR setting. In that context, I think this draft
would benefit from talking about more details on how this work. There
are three ways we see this XR image/data comong cacross the netowk. Many
vendors do texture-map polygons. Another representation we see is point
clouds where each point has a color. Those have very different bw
characteristics. The last approach is light-field: 5d video. Sends the
color of every ray of light going through the video. You take existing
video codec and extend it into another dimension.

Lightfields don't have a huge amount of data because it comrpesses so
well. About 10x standard video. Cisco uses 30mbps upstream. On
downstream, you need much less data because the headset is localised and
has a much reduced view. Downlink is 6mbps, 2x reguylar video. This
draft get power and latencies very right, but often confuses the issue
of updates with how much time the update take.s So latencies are not as
bad as they sound because you can overlap them. The e2e latencies are
similar to conferences. It'll run over LTE. Some of the latencies wrt
motion sickness (12ms) are the reason for compute on the head. But with
better headsets, it has much, much better characteristics.

One detail that seemed wrong: Some of the 3gpp specs say 5 9s over
150ms. I think those numbers were in the specs at one time but were
removed. I think some of these things came from thign 5g hoped were
true, but some may have been removed.

Renan: We will check the numbers again. Have these devices been tested
outside?

Cullen: They have not been tested outdoor, but in office rooms with
windows and lots of light changes. It works very well. Buyt that's a
lightfield approacha dvanceage. I think your depth-map recovery is much
harderr on outdoor scenes. Lightfield approach is less dependent on
clouds or fans.

Leslie: Are you suggesting the doc tease out the various kinds of
approaches in the numbers?

Cullen: Yes. 95% of companies working in this space are using one of
those three approaches. Talking about them specifically will help
explain why we see so different numbers.

Spencer: I agree with Cullen. I want to thank the authors for their
sense of humor hanging with this draft. What we're trying to describe is
getting much more mature. This is a good time to push further. You see
that in the opscon draft, one of the bigger changes is the description
of bitrates and characterizing them. That's a great model for this draft
as well. There is nothing that will help people contribute numbers as
well as putting in some numbers and let others correct them.

Mo Zanaty: I'm confused about the use case that was presented: it seems
to be derived from what it claims the most popular use case. But IU
don't think that this is actually the most popular way this is done. We
should look at the way game developers handle this on device, in the
cloud, and on the server. Msot edge cases will not allow 8ms round trip.
I think we need more realistic use cases than the contrived use case in
the doc. I'm argying the draft should look at trends in XR and what
matters in real experience.

## Related IETF work   {#related-ietf-work}

### Report from Hackathon project on quic-multicast work   {#report-from-hackathon-project-on-quic-multicast-work}

*Kyle \| Jake \| Max*

Jake: Work continues apace, it isn't quite running, but it's making
progress. We expect to have this at the next Hackathon as well. Anyone
who wants to work on it, the dev team is meeting weekly in the [W3C
multicast community group][1] and contributing as time permits.

### MOQ meeting   {#moq-meeting}

*Ted Hardie*

This was our second BoF. Almost all the time was taken going through the
[charter][2]. One of the changes adopted in the room was a liason with
MOPS. We went through the BoF questions and there was very strong
agreement that forming a WG based on the charter, once the issues are
resolved, was a good idea. We anticipate forming a WG once we go through
the processes.

Glenn Deen: I'm glad we have the MoQ-MOPS connection. Any idea how to
make that move toward reality and work really well? MOPS is for industry
engagement. We have some, but I would like to see more industry
engagement in MoQ. How do we do it even better?

Ted: It's easier to do that once the group is formed. I'm hopeful that
an approved charter will increase engagement. A lot of what we have
right now is people familiar with networking and less familiar with
operations and media creations. I hope folks with connections can "bring
a friend". I expect that we will have a regular cadence of making sure
MOPS is invited to MoQ interims and such. That's the typical mechanics
when there is a lot of shared membership. I don't expect a big push into
the broader industry.

Glenn: Part of the mission of MOPS is that industry linkage. The first
opportunity is the use case of MoQ (??).

Ted: We may hold an interim to make sure that people working on the
technical aspects of MoQ get to share their experience. We'll make sure
that MOPS people get invited. If the IESG + community agree, we may hold
a hybrid interim in perhaps September. But any such meeting will have a
remote component. If the timeline pushes out some, though, we'd be
looking at remote for sure.

Glenn: In order to help connect with industry, be sensitive to industry
events. [IBC][3] happens in September, so if there is overlap, industry
engagement may be very difficult. People do sometimes run things either
before or after.

Ted: Definitely send me the details.

Spencer: I want to say clearly, at the mic, that the MoQ BoF went very
well. And Glenn, as you are thinking through the pathway to other
operator forums, the charter has a requirements draft. And that might be
interesting for the operator community to take a look at.

Cullen: It would be great to see people operating large video networks
involved. I'm not sure this is all that relevant to that class of user.
There are three proposals in that WG, one from WebEx, one from Meta, and
one from Twitch, all of which are huge operators with lots of
operational experince.

Leslie: Not everyone who uses IP protocols is part of the IETF. There is
a lot of video being shipped over IP, even if it's not Internet-oriented
companies. And some of those companies should look at IETF protocols.
This is in the interests of the Internet that it be used well. They may
benefit from technologies like MoQ.

Cullen: Many of those companies have existing solutions, so they may
simply not need what we have to offer.

Glenn: While there are use cases that this doesn't satisfy, media
companies are often branching out into new areas. There are connections
that could be made here. I think having them invoved in IETF will help
them and also help the IETF. This is a good opportiunity to get them
engaged and this is one step in that.

Cullen: Agree, let me know how I can help.

## Industry News/Experiences   {#industry-newsexperiences}

### Updates from SVA/CTA Common Access Token, Streaming Media Tracing WGs   {#updates-from-svacta-common-access-token-streaming-media-tracing-wgs}

*Chris Lemmons*

Chris presents slides on behalf of the CTA WAVE project.

Erik Nygren: about the Common Access Token, please do not bind it to an
IP address as it would prevent some switch IPv4 - IPv6 or privacy
proxies.

Chris: indeed, IP addresses are a weak id, same compromise as CDNI WG
"any address /24 or /56 must be in the encrypted claim" (??)

There might be room for MOPS (IETF) to offer some concrete guidance here
to industry ("Don't use IP addresses for identifier tokens", for eg)

### Exposure of Telefonica network topology through ALTO for integration with Telefonica CDN   {#exposure-of-telefonica-network-topology-through-alto-for-integration-with-telefonica-cdn}

*Luis M. Contreras*

Rajeev RK: (scribe cannot understand question)

Luis: This is standard output of ALTO. So it's not relevant to keep
track of cost maps between customers. So that data is filtered.

Rajeev: Are you allotting the (??) to each customer?

Eric: How often are those maps computed?

Luis: We don't have a frequency specified. This isn't continuously
updated. Right now, it is a manual procedure, so we do it every six
months. It would be a significant improvement to do it every day even.

Eric: It assumes the network is the same MTU everywhere?

Luis: Yes.

Rajeev: With alloting the PIDs for the end user, are you doing a PID per
user or for PID prefix.

Luis: So you group a bunch of prefixes into one PID.

Rajeev: Do you have plans to eventually make some of this information
available outside your CDN?

Luis: The answer is yes, the intent is to make this information
available to optimize the use of the network in general.

Sanjay Mishra: How important is that relationship with the CDN
streamers?

Luis: The streamers may have different content.

Sanjay: So for a request, you have logic to force a client to go to a
particular streamer.

Luis: The logic on the CDN has to take into account a lot of things.

## Any Other Business?   {#any-other-business}

Leslie: *declares victory*



[1]: https://www.w3.org/community/multicast/
[2]: https://github.com/moq-wg/moq-charter/blob/main/charter.md
[3]: https://www.ibc.org/