Subject: [GGIE] Summing up... Re: [Mops] [E] Updated proposed charter for a MOPS WG

From: "Leslie Daigle" <[email-masked]>
Date: Wed, 11 Sep 2019 16:19:36 -0400

Having chewed on this for a few days, I think (TL;DR — we probably are 
looking RG-ish, but a WG is what we really need):

Jake has a good point in saying that the topics and energy exposed so 
far on these mailing lists would give us reasonable grounds for a 
research group.  Assuming the IRTF Chair concurred with that, an RG 
would give us a stable meeting basis at IETF meetings to carry on with 
general discussions of points of interest between video and Internet 
protocols.

While I have only good things to say about research groups, I think 
Glenn also has a good point in saying that non-RG-like work is being 
done, protocols are being tinkered with, and operationally-critical work 
is happening to IETF-related protocols, just not at the IETF (I’ve 
quoted some of his text below [2]).  Nor are the people doing the work 
(currently) engaging in IETF work, for the most part ([1]).

As a result, either the work is going to just happen outside of the IETF 
(and suffer from a lack of general Internet engineering review that can 
be provided at the IETF), or the IETF has to find a way to attract that 
work/those engineers to come play.

I don’t believe an RG will do that last — attract the engineers or 
the work to the IETF.

If we want to go for the networking issues in the video industry, can we 
break the chicken and egg situation by at least articulating a small 
list of concrete work items that an OPS WG could tackle here?

Leslie.

[1] There are notable exceptions — but the bulk of the participation 
in these engineering activities is a disjoint set of engineers from IETF 
participation, at the moment.

[2] In his message of September 5, 2019, Glenn Deen wrote:
> 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.

On 5 Sep 2019, at 16:20, Holland, Jake wrote:

> Hi Glenn,
>
> Yay, healthy debate is so much better than a dead list. :)
>
>> 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.
>> ...
>> 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.
>
> I think this misunderstands the nature of a research group.
>
> I'll point to BBR as an interesting case in point.  Various versions 
> of it are
> deployed live today and at scale by major operators.  This is more or 
> less
> independent of the ongoing academic exploration about the way to get 
> ideal
> congestion control properties in networks.
>
> iccrg is the main IETF venue for discussing BBR, since it's clearly in 
> scope
> there, and nowhere else is right.  Just because it's technically 
> experimental
> (and still a work in progress, not even a bona-fide Experimental RFC) 
> doesn't
> mean anybody got stopped from deploying it unilaterally.
>
> During the time the deployment has happened, having the discussion 
> venue (as
> opposed to not having it) is just a pure win for the internet and for 
> the
> development of the CC algorithm, regardless that the venue happens to 
> be a
> research group (even though yes, iccrg occasionally includes 
> less-relevant
> things as well, at chair's discretion).
>
> I would anticipate the same for the hacks that video operators get 
> forced into
> to get their performance to work.  First you do what you have to in 
> order to
> solve your problem, and then you socialize and maybe standardize what 
> you've
> done so that more people avoid doing stuff that breaks you (and maybe 
> they can
> sometimes give you better suggestions along the way).
>
> Indeed, I think it would be worth adding to the charter that the 
> research
> group is focused on pressing operational problems observed in practice 
> and
> solution proposals with deployment experience, or at least viable 
> short-term
> deployment potential, as opposed to greenfield proposals that would 
> need
> major changes.
>
> In that sense, the suggestion to make it an RG is basically a 
> workaround for
> having the scope be unknown and fluid and broad.
>
> If there's a proposal with bits-on-wire level specificity, a bof for 
> the specific
> proposal would make lots of sense, but "learn about newly discovered 
> problems
> observed while attempting to scale SMTPE and try to think of what to 
> do about
> them" sounds like research to me even when it's about problems 
> happening today.
>
> Maybe there are some research groups that are too future-looking and 
> impractical,
> but I think that's driven by the problem space for the RG, rather than 
> being
> inherent to research groups in general.  If this group successfully 
> stays
> focused on stuff relevant to operators today, operators will want to 
> be here,
> and it doesn't matter what it's called.
>
> Also maybe worth looking again at the differences between the criteria 
> at
> the process level for forming a WG and an RG:
>
> WG: It seems to me we're missing on the top 2 points, due to scope 
> murkiness
> and a dearth of specific work items:
> https://tools.ietf.org/html/rfc2418#section-2.1
>     - Are the issues that the working group plans to address clear and
>       relevant to the Internet community?
>     - Are the goals specific and reasonably achievable, and achievable
>       within a reasonable time frame?
>
> RG: I think we're in much better shape in general, and the urgency 
> here that
> Glenn has described falls basically under the 2nd point, as I 
> understand it:
> https://tools.ietf.org/html/rfc2014#section-2.1
>    -  Will the formation of the Research Group foster work that would
>       not be done otherwise.
> (Answer: yes--this is a cry for help from video operators who got 
> stuck
> trying to migrate to IP for more things, and have no path or expertise
> in their existing standards bodies for improving the 
> networking-related
> issues they've encountered.)
>
> Where standardization is necessary or useful, I'd see a key part of 
> this RG's
> role as identifying the specific work to be done and spinning off WGs 
> for
> those specific protocols over the next few years, and then it can 
> close down
> as soon as media on the internet has been conclusively solved to 
> everyone's
> satisfaction and all the media requirements have become stable.  ;)
>
> Best,
> Jake
>
> On 2019-09-05, 10:49, "Deen, Glenn (NBCUniversal)" 
> <[email-masked]> wrote:
>
>
>
> On 9/5/19, 9:33 AM, "GGIE on behalf of Holland, Jake" 
> <[email-masked] on behalf of [email-masked]> wrote:
>
>     Hi,
>
>     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.)
>
>     TL/DR:
>     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.
>
>
> -glenn
>
>
>
>
> _______________________________________________
> GGIE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ggie

-- 

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 17 Sep 2019 23:27:20 +0100

Hi Leslie,

I don’t disagree that there’s research here – but I also tend to think that what you need is an OPS working group. You’re trying to deploy stuff and figure out:

1) what works today → produce drafts giving operational guidance

2) what doesn’t work today, but we (think we) know how to build it → send requirements to an existing WG or other standards body, or spin-up an IETF BoF

3) what doesn’t work today, and we don’t know how to build it → input to IRTF

To me, that seems like a good focus for a media operations working group that acts as a focus for discussion, experience, and requirements gathering, and spins-off new work to IETF or IRTF as appropriate. 

I also somewhat wonder if an IRTF group might end-up too far into the research side, and not operational enough to address the actual problems you’re seeing. Getting the balance of the community right is not easy… 

Colin

> On 11 Sep 2019, at 21:19, Leslie Daigle <[email-masked]> wrote:
> 
> Having chewed on this for a few days, I think (TL;DR — we probably are looking RG-ish, but a WG is what we really need):
> 
> Jake has a good point in saying that the topics and energy exposed so far on these mailing lists would give us reasonable grounds for a research group. Assuming the IRTF Chair concurred with that, an RG would give us a stable meeting basis at IETF meetings to carry on with general discussions of points of interest between video and Internet protocols.
> 
> While I have only good things to say about research groups, I think Glenn also has a good point in saying that non-RG-like work is being done, protocols are being tinkered with, and operationally-critical work is happening to IETF-related protocols, just not at the IETF (I’ve quoted some of his text below [2]). Nor are the people doing the work (currently) engaging in IETF work, for the most part ([1]).
> 
> As a result, either the work is going to just happen outside of the IETF (and suffer from a lack of general Internet engineering review that can be provided at the IETF), or the IETF has to find a way to attract that work/those engineers to come play.
> 
> I don’t believe an RG will do that last — attract the engineers or the work to the IETF.
> 
> If we want to go for the networking issues in the video industry, can we break the chicken and egg situation by at least articulating a small list of concrete work items that an OPS WG could tackle here?
> 
> Leslie.
> 
> [1] There are notable exceptions — but the bulk of the participation in these engineering activities is a disjoint set of engineers from IETF participation, at the moment.
> 
> 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
> 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
> stuff in use TODAY on the network, and things being looked at for TOMORROW.
> ...
> 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.
> 
> I'll point to BBR as an interesting case in point. Various versions of it are
> deployed live today and at scale by major operators. This is more or less
> independent of the ongoing academic exploration about the way to get ideal
> iccrg is the main IETF venue for discussing BBR, since it's clearly in scope
> there, and nowhere else is right. Just because it's technically experimental
> (and still a work in progress, not even a bona-fide Experimental RFC) doesn't
> During the time the deployment has happened, having the discussion venue (as
> opposed to not having it) is just a pure win for the internet and for the
> development of the CC algorithm, regardless that the venue happens to be a
> research group (even though yes, iccrg occasionally includes less-relevant
> I would anticipate the same for the hacks that video operators get forced into
> to get their performance to work. First you do what you have to in order to
> solve your problem, and then you socialize and maybe standardize what you've
> done so that more people avoid doing stuff that breaks you (and maybe they can
> Indeed, I think it would be worth adding to the charter that the research
> group is focused on pressing operational problems observed in practice and
> solution proposals with deployment experience, or at least viable short-term
> deployment potential, as opposed to greenfield proposals that would need
> major changes.
> 
> In that sense, the suggestion to make it an RG is basically a workaround for
> If there's a proposal with bits-on-wire level specificity, a bof for the specific
> proposal would make lots of sense, but "learn about newly discovered problems
> observed while attempting to scale SMTPE and try to think of what to do about
> them" sounds like research to me even when it's about problems happening today.
> 
> Maybe there are some research groups that are too future-looking and impractical,
> but I think that's driven by the problem space for the RG, rather than being
> inherent to research groups in general. If this group successfully stays
> focused on stuff relevant to operators today, operators will want to be here,
> Also maybe worth looking again at the differences between the criteria at
> WG: It seems to me we're missing on the top 2 points, due to scope murkiness
> https://tools.ietf.org/html/rfc2418#section-2.1 <https://tools.ietf.org/html/rfc2418#section-2.1>
> RG: I think we're in much better shape in general, and the urgency here that
> Glenn has described falls basically under the 2nd point, as I understand it:
> https://tools.ietf.org/html/rfc2014#section-2.1 <https://tools.ietf.org/html/rfc2014#section-2.1>
> (Answer: yes--this is a cry for help from video operators who got stuck
> in their existing standards bodies for improving the networking-related
> Where standardization is necessary or useful, I'd see a key part of this RG's
> role as identifying the specific work to be done and spinning off WGs for
> those specific protocols over the next few years, and then it can close down
> as soon as media on the internet has been conclusively solved to everyone's
> On 2019-09-05, 10:49, "Deen, Glenn (NBCUniversal)" <[email-masked]> wrote:
> 
> 
> 
> On 9/5/19, 9:33 AM, "GGIE on behalf of Holland, Jake" <[email-masked] on behalf of [email-masked]> wrote:
> 
> Hi,
> 
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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.
> 
> 
> -glenn
> 
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/ggie <https://www.ietf.org/mailman/listinfo/ggie>
> --
> 
> Leslie Daigle
> [email-masked] <mailto:[email-masked]>-- 
> Mops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mops

-- 
Colin Perkins
https://csperkins.org/

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Tue, 17 Sep 2019 23:03:00 +0000

It seems as if we need something in between. Neither a RG or a WG but an Topic Group or Interest Group.

On Sep 17, 2019, at 11:27 PM, Colin Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Hi Leslie,

Colin

On 11 Sep 2019, at 21:19, Leslie Daigle <[email-masked]<mailto:[email-masked]>> wrote:

Leslie.

Hi Glenn,

....

https://tools.ietf.org/html/rfc2418#section-2.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc2418-23section-2D2.1&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=cftjcrKRw6Kfpk9xKsM8EasjVYrBOSac6C24KbTCgyU&e=>

https://tools.ietf.org/html/rfc2014#section-2.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc2014-23section-2D2.1&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=QdZyhdVSYKNWYAmzf-jFDZRCzM3qj7HyRmd_BH6D3aw&e=>

Best,
Jake

On 2019-09-05, 10:49, "Deen, Glenn (NBCUniversal)" <[email-masked]<mailto:[email-masked]>> wrote:

On 9/5/19, 9:33 AM, "GGIE on behalf of Holland, Jake" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi,

TL/DR:

-glenn

_______________________________________________
GGIE mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ggie<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ggie&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=SUDJkVgLWKedtli8yiLMm-ZpM1X7W3KAlONM1nZD5Z0&e=>

--

________________________________

Leslie Daigle

[email-masked]<mailto:[email-masked]>
--
Mops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mops<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mops&d=DwQFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=eTa3CVhRIIBnu9Gzp7LSEmd57EGSXUG0uDyR88x4W9w&e=>

--
Colin Perkins
https://csperkins.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__csperkins.org_&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=gkvM4e-RR57zol0yaoIOpYd7KI3cFfHaeSu2YPm-v9g&e=>

--
Mops mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mops&d=DwICAg&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=eTa3CVhRIIBnu9Gzp7LSEmd57EGSXUG0uDyR88x4W9w&e=

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 20 Sep 2019 19:12:18 +0100

ETSI provides a useful structure for exactly what Colin describes - 
called an Industrial Specification Group.
An example was the Network Functions Virtualization ISG, which was 
primarily about identifying management standards work and research work 
needed. It led to the creation of a number of IETF WGs and and IRTF RG, 
as well as open source implementation groups.

One of the main features of an ETSI ISG is the ability to publish 
documents without going through the full publication approval process 
needed for ETSI standards. ETSI provides a secretariat for each ISG.

In previous discussions about how the IETF could reverse a recent 
tendency to declining involvement, it has been suggested that this type 
of group would be a useful addition to the IETF's set of types of 
groups. It might be possible to squeeze such a group into the IETF's 
existing structures (e.g. as an RG that isn't just about research), but 
it would be better if the need was recognized and dealt with 'officially'.

Cheers

Bob

On 18/09/2019 00:03, Deen, Glenn (NBCUniversal) wrote:
>> I don’t disagree that there’s research here – but I also tend to 
>> think that what you need is an OPS working group. You’re trying to 
>> deploy stuff and figure out:
>>
>> 2) what doesn’t work today, but we (think we) know how to build it → 
>> send requirements to an existing WG or other standards body, or 
>> spin-up an IETF BoF
>>
>> To me, that seems like a good focus for a media operations working 
>> group that acts as a focus for discussion, experience, and 
>> requirements gathering, and spins-off new work to IETF or IRTF as 
>> appropriate.
>>
>> I also somewhat wonder if an IRTF group might end-up too far into the 
>> research side, and not operational enough to address the actual 
>> problems you’re seeing. Getting the balance of the community right is 
>> not easy…
>>
>> Colin
>>
>>
>>
>>> Having chewed on this for a few days, I think (TL;DR — we probably 
>>> are looking RG-ish, but a WG is what we really need):
>>>
>>> Jake has a good point in saying that the topics and energy exposed 
>>> so far on these mailing lists would give us reasonable grounds for a 
>>> would give us a stable meeting basis at IETF meetings to carry on 
>>> with general discussions of points of interest between video and 
>>> Internet protocols.
>>>
>>> done, protocols are being tinkered with, and operationally-critical 
>>> work is happening to IETF-related protocols, just not at the IETF 
>>> (I’ve quoted some of his text below [2]). Nor are the people doing 
>>> the work (currently) engaging in IETF work, for the most part ([1]).
>>>
>>> As a result, either the work is going to just happen outside of the 
>>> IETF (and suffer from a lack of general Internet engineering review 
>>> that can be provided at the IETF), or the IETF has to find a way to 
>>> attract that work/those engineers to come play.
>>>
>>> If we want to go for the networking issues in the video industry, 
>>> can we break the chicken and egg situation by at least articulating 
>>> a small list of concrete work items that an OPS WG could tackle here?
>>>
>>> Leslie.
>>>
>>> in these engineering activities is a disjoint set of engineers from 
>>> IETF participation, at the moment.
>>>
>>>     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
>>>     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
>>>     Groups like MPEG-DASH are working on the video player side of
>>>     how to use IP Networks to deliver video, but they too
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc2418-23section-2D2.1&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=cftjcrKRw6Kfpk9xKsM8EasjVYrBOSac6C24KbTCgyU&e=>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc2014-23section-2D2.1&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=QdZyhdVSYKNWYAmzf-jFDZRCzM3qj7HyRmd_BH6D3aw&e=>
>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>
>>>
>>>     <[email-masked] <mailto:[email-masked]> on behalf
>>>     of [email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     Hi,
>>>
>>>     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
>>>     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
>>>     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
>>>     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
>>>     Groups like MPEG-DASH are working on the video player side of
>>>     how to use IP Networks to deliver video, but they too
>>>     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
>>>     practitioners that are already at the IETF, and a place to for
>>>     new IETF
>>>     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
>>>     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
>>>     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
>>>     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
>>>     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.
>>>
>>>
>>>     -glenn
>>>
>>>
>>>
>>>
>>>     [email-masked] <mailto:[email-masked]>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ggie&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=SUDJkVgLWKedtli8yiLMm-ZpM1X7W3KAlONM1nZD5Z0&e=>
>>>
>>> -- 
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Leslie Daigle
>>>     [email-masked] <mailto:[email-masked]>
>>>
>>> -- 
>>> Mops mailing list
>>> [email-masked] <mailto:[email-masked]>
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mops&d=DwQFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=eTa3CVhRIIBnu9Gzp7LSEmd57EGSXUG0uDyR88x4W9w&e=>
>>
>>
>>
>> -- 
>> Colin Perkins
>> https://csperkins.org/ 
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__csperkins.org_&d=DwMFaQ&c=LO_8KzsOlAGvgA6hdGI4v02U_XLiES0sR51Zca0yIy4&r=5pfwIkE53AZ16icPhUNATkw3VgfICDWYuWCM0O3mxM4&m=wKWm5iU_LQ4PpPFDXflGzPICJ8mbl2t6xstFP3RDRz0&s=gkvM4e-RR57zol0yaoIOpYd7KI3cFfHaeSu2YPm-v9g&e=>
>>
>>
>>
>>
>> -- 
>> Mops mailing list
>> [email-masked] <mailto:[email-masked]>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 20 Sep 2019 19:17:21 +0100

Deen, Colin,

Cheers

Bob

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 23 Sep 2019 17:49:19 +0000

Bob,

You are right to the spot. Most of MOPS proponents want indeed to morph into a ‘special interest group’, being practical let’s first start with a ‘normal’ IETF WG then let’s try to add this kind of groups within the IETF framework.

-éric

From: Bob Briscoe <[email-masked]>
Date: Friday, 20 September 2019 at 20:12
To: "Deen, Glenn (NBCUniversal)" <[email-masked]>, Colin Perkins <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Leslie Daigle <[email-masked]>, Warren Kumari <[email-masked]>, Eric Vyncke <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [GGIE] [EXTERNAL] Re: [Mops] Summing up... Re: [E] Updated proposed charter for a MOPS WG

ETSI provides a useful structure for exactly what Colin describes - called an Industrial Specification Group.
An example was the Network Functions Virtualization ISG, which was primarily about identifying management standards work and research work needed. It led to the creation of a number of IETF WGs and and IRTF RG, as well as open source implementation groups.

One of the main features of an ETSI ISG is the ability to publish documents without going through the full publication approval process needed for ETSI standards. ETSI provides a secretariat for each ISG.

In previous discussions about how the IETF could reverse a recent tendency to declining involvement, it has been suggested that this type of group would be a useful addition to the IETF's set of types of groups. It might be possible to squeeze such a group into the IETF's existing structures (e.g. as an RG that isn't just about research), but it would be better if the need was recognized and dealt with 'officially'.

Cheers

Bob

Colin

Best,
Jake

Hi,

TL/DR:

-glenn

GGIE mailing list

--