Subject: [Mops] So, what is streaming media, anyway? :-)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 21 Apr 2020 21:31:40 -0500

Dear MOPS,

We have an issue in
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/  that
proposes a "low-latency" section in draft-ietf-mops-streaming-opcons, and
discussion on that PR is starting to poke at what I understood the limits
of MOPS scope to be, bringing in (checks notes) "RTMP, RTSP 2.0, WebRTC and
globally all kinds of RTP-based streaming techs", STADIA, and SRT as
possible topics.

This is, I think, the kind of conversation that we should be having on the
working group mailing list ("when a topic is bigger than a conversation on
an issue in Github ought to be").

Could people take a look at
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/3,
and let the working group know your thoughts?

Do The Right Thing, of course.

Best,

Spencer

---

From: Kyle Rose <[email-masked]>
Date: Wed, 22 Apr 2020 08:43:12 -0400

> and let the working group know your thoughts?

<chair hat=on>
I've added a comment asking people to take further discussion of that issue
to the mailing list prior to merging any related changes.
</chair>

>From my reading of the charter, there's nothing disqualifying MOPS from
addressing realtime media delivery issues, so long as we:

 * Restrict our scope to the interaction of media-related protocols with
the network and not move higher in the technology stack; and
 * Focus on development of informational documents related to issues that
affect operations for use by other working groups and SDOs, and not get
into the business of developing protocols ourselves.

Clearly, realtime use cases (such as for interactive applications such as
Stadia and for hand-wave latency minimization on live broadcasts) impose
requirements on networks, protocols, and their interactions. I see MOPS as
having been chartered for the express purpose of sussing out such
requirements by leveraging the expertise and experience of a broad range of
SMEs who would otherwise not have had a natural forum in the IETF for such
collaboration.

Kyle

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 22 Apr 2020 14:30:59 +0100

Hey Spencer,

Looking at the issue, there is clearly a benefit to defining what is
streaming and what is latency.

Rereading the Introduction, the statement "The focus is on capturing
characteristics of video delivery that have surprised network designers or
transport experts without specific video expertise" is taken by me to
include streaming media of any protocol as long as it focuses on the
delivery and network aspects.

Cheers
Lucas

On Wed, Apr 22, 2020 at 1:43 PM Kyle Rose <[email-masked]> wrote:

>> This is, I think, the kind of conversation that we should be having on
>> the working group mailing list ("when a topic is bigger than a conversation
>> on an issue in Github ought to be").
>>
> I've added a comment asking people to take further discussion of that
> issue to the mailing list prior to merging any related changes.
> </chair>
>
> requirements on networks, protocols, and their interactions. I see MOPS
> as having been chartered for the express purpose of sussing out such
> --
> Mops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mops
>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Wed, 22 Apr 2020 21:25:30 +0200

As participating in the GitHub ticket, the usages of webrtc specifically I
had in mind that I believe fit the scope (and it is naive, i can be
completely wrong) are:

- usage a p2p data channel for extension of CDN delivery
  (webrtc examples: peer5, peerCDN, ....)
  (flash example:
http://tv.adobe.com/watch/max-2009-develop/p2p-on-the-flash-platform-with-rtmfp/
)

- one-to-many, streaming only, flash-replacement use cases:
  - servers: red5, ant media, medooze, ....
  - PaaS: http://millicast.com/, PhenixRTS <https://phenixrts.com/en-us/>,
limelight Network, ...

- Specifically cloud gaming
 - Stadia

note that webrtc, srt, rtmp, http/3, QUIC with datagrams
<https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/>, are all
pretty much interchangeable for those use cases.

for your kind attention.

On Wed, Apr 22, 2020 at 3:31 PM Lucas Pardue <[email-masked]>
wrote:

>> Clearly, realtime use cases (such as for interactive applications such
>> as Stadia and for hand-wave latency minimization on live broadcasts) impose

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 23 Apr 2020 11:58:27 +1200

IMHO, the MOPS charter is already too broad/fuzzy.  We should restrict it to covering two use cases only:
	1/ On-demand streaming of pre-recorded media (e.g., watching movies at home), and
	2/ Streaming/viewing (one way) of live events - e.g., football matches, presidential announcements

In contrast, I see
	3/ face-to-face video chat (or telephony), video conferencing, and cloud gaming
as being out of scope.

Re. latency: While it is an issue for 1/ (playback startup time) and 2/ (startup time, lag from ‘real time’), latency requirements are not nearly as stringent as they would be for 3/

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Thu, 23 Apr 2020 11:17:25 +0200

> matches, presidential announcements

IMHO that makes sense, and we feel it is aligned with what we proposed
before, i.e. to draw boundaries based on use case, and not on latency
(sorry, too fast), or underlying tech (sorry, we only entertain file-based,
HTTP-based protocols like HLS and MPEG-DASH, and without CMAF, the later
making those protocols too fast to fall in scope).

We believe the point number two, as it is proposed above, could be too
restrictive. Would there be any reason to segregate based on content? For
example, is sport, and live events in scope, but news being streamed live
from the field would not be? An argument could be made that  a definition
of Streaming as  sending media, one way (*unidirectiona*l, or send-only),
*1-to-many*, with many being a relatively large number, large enough to
rule out say video conferencing or webinars, could be a sufficient
definition.

Restricting the use case based on media content is difficult. After all,
when it comes to VOD, the point #1, one does not differentiate based on
whether the original content is a recorded LoL game, a documentary, a
cartoon, a movie, news, ..... Why making such a distinction for point #2?

> In contrast, I see
>         3/ face-to-face video chat (or telephony), video conferencing,

We agree. We don't remember anybody really proposing this.

> and cloud gaming

We think this could be argued one way or the other. I do not have horse in
the race but in my opinion, the reason why one might want to entertain
cloud gaming is that, apart from the content itself, it is much closer to a
one-to-many, unidirectionnal use case than to video conferencing. Also
there is the precedent of Stadia being presented in the scope of the group.
I think it's right on the boundary :-) We do not feel strongly about cloud
gaming.

We are just expressing our opinion in this thread. we might be naive and
totally off topic. We would love to get feedback from the chairs on the
matter.

Best regards,

Dr. Alex.

   -

---

From: "Ali C. Begen" <[email-masked]>
Date: Thu, 23 Apr 2020 20:07:29 +0300

On Thu, Apr 23, 2020 at 2:58 AM Ross Finlayson <[email-masked]>
wrote:

> IMHO, the MOPS charter is already too broad/fuzzy.

I agree with this, although I am not sure whether that means we should
exclude 3) below.

> We should restrict it to covering two use cases only:

1) and 2) are non-interactive and 3) is interactive. They can be all
considered under the umbrella of media ops if need be. But then most of the
folks in this WG are concerned about the bw consumption from 1) and 2), not
that much from 3). So, I suppose most of our energy will be spent on the
first two.

Re. latency: While it is an issue for 1/ (playback startup time) and 2/
> (startup time, lag from ‘real time’), latency requirements are not nearly
> as stringent as they would be for 3/
>

Latency and startup delay are different and independent from each other.
Latency only applies to live (from capture to playback) as well as gaming.
Startup delay (or time to first frame) applies to all streaming apps.

---

From: "Leslie Daigle" <[email-masked]>
Date: Mon, 27 Apr 2020 17:05:14 -0400

Hi,

Trying to see if we can sum up where we are at.

I think we agree that these are in:
	1/ On-demand streaming of pre-recorded media (e.g., watching movies at 
home), and
	2/ Streaming/viewing (one way) of live events - e.g., football matches, 
presidential announcements

I think we agree that these are out:
	3/ face-to-face video chat (or telephony), video conferencing

And we haven’t concluded on:
	4/ cloud gaming

I think the point to keep in mind for “4/“ is that we had the input 
from Stadia because of the delivery of high-quality pre-developed video 
as an integral part of the gaming experience.   So, we’re not trying 
to keep up with the full gamut of interactive gaming, but rather focus 
on the degree to which it provides another case of shipping video over 
the Internet where the video (quality) is the thing.  (Video chat and 
teleconferencing are, hopefully, about realtime interchange, not 
pre-canned video).

Thoughts?

Leslie.

On 21 Apr 2020, at 22:31, Spencer Dawkins at IETF wrote:

> the

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------