Re: [GGIE] [Mops] [E] Updated proposed charter for a MOPS WG

"Deen, Glenn (NBCUniversal)" <> Thu, 05 September 2019 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9433120A72; Thu, 5 Sep 2019 10:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BQv3GkLbclkL; Thu, 5 Sep 2019 10:49:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF580120A38; Thu, 5 Sep 2019 10:49:04 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x85Hgv5n035601; Thu, 5 Sep 2019 13:49:04 -0400
Received: from ([]) by with ESMTP id 2uqmg5xf0t-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT); Thu, 05 Sep 2019 13:49:04 -0400
Received: from unknown (HELO ([]) by with ESMTP; 05 Sep 2019 10:49:03 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 5 Sep 2019 11:49:02 -0600
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Thu, 5 Sep 2019 11:49:01 -0600
Received: from ([]) by ([]) with mapi id 15.01.0669.032; Thu, 5 Sep 2019 11:49:01 -0600
From: "Deen, Glenn (NBCUniversal)" <>
To: "Holland, Jake" <>, "Eric Vyncke (evyncke)" <>, "" <>
CC: "" <>, Warren Kumari <>, "Deen, Glenn (NBCUniversal)" <>
Thread-Topic: [GGIE] [Mops] [E] Updated proposed charter for a MOPS WG
Thread-Index: AQHVZBIzGfbGlYn28UuyeS5zpwN3Fw==
Date: Thu, 5 Sep 2019 17:49:01 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1c.0.190812
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-exclaimer-md-config: 47edc00f-f2d6-45ef-be83-8a353bd47e45
Content-Type: text/plain; charset="utf-8"
Content-ID: <C49BC8964D547048AEE7485830B4A2AC@NBCUNI.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-05_05:2019-09-04,2019-09-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 lowpriorityscore=0 spamscore=0 malwarescore=0 phishscore=0 mlxscore=0 impostorscore=0 clxscore=1011 mlxlogscore=999 adultscore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1906280000 definitions=main-1909050168
Archived-At: <>
Subject: Re: [GGIE] [Mops] [E] Updated proposed charter for a MOPS WG
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discuss IETF-related items for Glass to Glass Internet Ecosystem of Video Content <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2019 17:49:15 -0000

On 9/5/19, 9:33 AM, "GGIE on behalf of Holland, Jake" < on behalf of> wrote:

    Sorry for the slow response, I've got several things going on, and my
    response is complicated.  But I do still care, and I do still support
    normalizing this group.
    (Also: sorry for not figuring this all out and making the case better
    back in February, but my current position was influenced by new
    information from feedback during 105.)
    I think we should revisit the idea of making mops a research group
    instead of a working group.

I arrived at the opposite conclusion having worked much the same line of reasoning that Jake raised.  

In respect to Jake, I'm not saying I think he is wrong.  I am saying that I think it's where one draws the line between
stuff in use TODAY on the network, and things being looked at for TOMORROW.  

I suggest we don't worry about creating a home for every cases of work, but for MOPS focus on the here and now stuff. 

What differentiates the work that I in MOPS is how close to real world problems, production and deployment it would be.  
The video and IP network problems that are hot topics right now with video creators, video distributors, and video viewers are
uses of IP networking being developed and deployed operationally and that fits best in a WG and not RG.

Certainly there are research topics on video things that are more experimental approaches, and for those MOPS might not be
the right fit.    The GGIE proposal might have fit better into an RG, but that's not what we are currently talking about. 

Perhaps down the road there may be enough experiment and research video activity that is looking for a home in the IRTF
that it would be right to create an additional group there, but that isn't this current MOPS discussion in my view.

Let's recall, that there have been 2 big motivators in the run up to MOPS on why this was being looked at in the IETF:  

(1) First, is the video industry migration to IP networks for both video creation, and video delivery and the current needs and 
issues this has created.

(2) Second, is the technical challenges that have come along with that migration/adoption which include dealing with latency 
and scalability of video on those IP networks.

Orgs like SMPTE and Streaming Video Alliance have been tackling these issues very well in the scope of their ability.  SMPTE
did their SMPTE 2110 on how to use IP network in professional video production.   The streaming video alliance has been working 
on things like CDN caching, location storage, security, privacy, geo etc.  BUT each aren't covering the IP Network aspects of this work that 
the IETF handles.     Both SMPTE and the Streaming Video Alliance in turn depend on the IP Network standards done in the IETF.

Groups like MPEG-DASH are working on the video player side of how to use IP Networks to deliver video, but they too 
depend on the IETF's IP networking standards to build on.

That's where I see MOPS filling an important role - ingesting and maturing the needs from the real world of 
video that is using IP Networking as its network and transport and then turning them in high qualify IETF documents that
are either eventually turned into RFCs via MOPS or are handed over to other WG when they've matured enough to be ready
for those other groups to look at.    This is would be things are in deployed production today, and things
that are being deployed now as new services, and offerings.

It's the timeliness of actual wide use that distinguishes things to me, as well as who is doing it.  

An RG is a great place to connect with academics and industry researchers.  

A WG is the place to connect with other doing-it-now industry practitioners that are already at the IETF, and a place to for new IETF
participants who want to join the IETF to work with others.

It's has long struck me as odd that we, meaning we the IETF, often talk about video on the Internet as if was some edge use case of the network 
and IP standards instead of seeing it as what is: The biggest, without any close second, use of the Internet globally.   I think it's because up to now
we've been able to semi-ignore it because it wasn't placing major new demands up the standards developed at the IETF.   

We’ve gotten away with it because until recently the video uses on the Internet have been the easy stuff.  Things like P2P downloads of movie files
which benefitted from high distribution of file sources.  Or things like streaming a recorded movie out to a few tens/hundreds of thousands of people who
wanted to watch it.     Those were the easy to solve use cases and not the really hard stuff like like streaming a live event to hundreds of millions of 
simultaneous viewers globally. 

You can scale delivery of a movie to tens or hundreds of thousands of viewers by distributing it on many many caches.   Throwing more 
servers at the problem isn’t enough when you want to live stream, with 6-8s of latency, a sports event to 500 million or more viewers.  That 
bigger use case is what is being sought today and it's at such as scale that any inefficiency or rough spot in the network or its technology 
gets stressed to the breaking point.    

That was an important point Jake's talk at the MOPS BoF highlighted.  The thing is though, that this problem isn't a theoretical research topic that
can linger through long discussions, experiments and academic papers exploring the perfect solution.   This stuff is what companies are trying to 
do as services to viewers today and are hitting the wall on doing it successfully at extreme scale. 

And that's just one example of where MOPS would play a role by being a WG that could pull together real world problems and the people who want to 
work on it.     The work my well spin out specific needs to other WG groups, but they would mature it and foster it to a point where it could fit into the 
IETF's way of working and could help solve those problems that video's stressing of the network bring out.