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

[Colin Perkins <[e-mail]>]

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 <[e-mail]> 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.
> 
> [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 <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 <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)" <[e-mail]> wrote:
> 
> 
> 
> On 9/5/19, 9:33 AM, "GGIE on behalf of Holland, Jake" <[e-mail] on behalf of [e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ggie <https://www.ietf.org/mailman/listinfo/ggie>
> --
> 
> Leslie Daigle
> Principal, ThinkingCat Enterprises
> 
> [e-mail] <mailto:[e-mail]>-- 
> Mops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mops



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