Re: [GGIE] DRAFT bof proposal for IETF 98 in Chicago

["Ben Campbell" <[e-mail]>]

Hi Jason,

I recognize no one can be sure that the results of a working group will 
be something they will implement. But at the same time, we don't want to 
create a working group where we think it unlikely that the results will 
get used somewhere. So maybe a better question would have been "Do you 
think it likely that a wg on this subject would produce something you 
would be interested in implementing or deploying." Or more importantly 
"will you take the time to try to make that more likely".

I recognize there is working code. But for WG success, we need a 
critical mass of people other than the proponents to work on it. And for 
a work group forming BoF (which I assume is the goal here) to be 
approved, we need to believe there's a reasonable chance of finding that 
critical mass. There hasn't been much evidence of that prior to now. But 
a couple of people have expressed interest since this thread started, 
which is good. Hopefully more will comment in time for the IESG and IAB 
to consider their input when making the BoF approval decision.

Thanks!

Ben.



On 9 Feb 2017, at 11:59, Livingood, Jason wrote:

> I’ll add to what Glenn says with a somewhat different take. I agree 
> that no one can commit until you know what the standards look like.
> But the problem statement frames a real problem and the challenges 
> will grow more pronounced over time. If GGIE can deliver on some or 
> all of the expected benefits then it’ll be obvious to content 
> creators, distributors, network operators, and others to deploy it. 
> Ultimately this is about the IETF agreeing to permit interested 
> parties to come together to work on an interesting issue and tap the 
> expertise of others at the IETF in the process. But like any other 
> standards, no one can really predict adoption until the end of the 
> process. In addition, there was a working version demonstrated at BnB 
> last year and there is a plan for another demo at IETF-98 (assuming 
> BnB is not canceled), so it’s not theoretical – there is working 
> code. We’re also discussing the possibility of how to trial this 
> technically in the Comcast production network (TBD).
>
> Jason
>
> On 2/8/17, 6:10 PM, "GGIE on behalf of Deen, Glenn (NBCUniversal)" 
> <[e-mail] on behalf of [e-mail]> wrote:
>
>     Hi Ben
>
>     It seems awfully premature to ask if anyone would implement/deploy 
> the results.   If we used that litmus we would not have been able to 
> every work on either  IPv6 or dnssec.  (I mean that a little tongue in 
> cheek, so hopefully no one throws anything at me in Chicago)
>
>     The rest of questions seem fair, through more likely to get 
> answers in person at an actual BoF versus a mailing list where 
> discussion is often lower volume.
>
>     Could you send a note to the list promoting for the sort of 
> questions you are wondering about?
>
>     Regards
>     Glenn
>
>     Sent from my iPad
>
>     > On Feb 8, 2017, at 2:28 PM, Ben Campbell <[e-mail]> 
> wrote:
>     >
>     > Hi, Leslie, thanks for sending this.
>     >
>     > The ART ADs would like to see comments on the following:
>     >
>     > - Do you plan to work on this if it becomes a working group? 
> That is, would you expect to engage in discussion, review drafts, or 
> even possibly edit drafts?
>     >
>     > - Are you likely to implement and/or deploy the results?
>     >
>     > - Does the scope seem right? That is, does this all belong in 
> one WG and/or area, or are there aspects that might belong somewhere 
> else?
>     >
>     > Of course, discussion on other aspects is also welcome.
>     >
>     > Thanks!
>     >
>     > Ben.
>     >
>     >
>     >> On 8 Feb 2017, at 15:32, Leslie Daigle wrote:
>     >>
>     >> Hi,
>     >>
>     >> Please find below a proposal for a GGIE BoF (WG-forming) at 
> IETF 98 in Chicago.  We will be submitting the proposal by the 
> deadline this Friday, but would be happy to have suggestions to 
> improve the proposal before then.
>     >>
>     >> One of the things we’ve beed advised is that 
> GGIE-proponents-other-than-Glenn-and-Leslie are pretty invisible to 
> the IESG.  If there doesn’t seem to be other interest, there won’t 
> be much justification for a BoF.
>     >>
>     >> Now is the time, and here is the place, to voice your support 
> for furthering this discussion!
>     >>
>     >> Thanks,
>     >> Leslie.
>     >>
>     >> —8<——8<——8<——
>     >>
>     >> Name: Glass to Glass Internet Ecosystem (GGIE)
>     >>
>     >> Description:
>     >>
>     >> Video is without rival the top use of Internet bandwidth, and 
> its ever growing demand for more bandwidth easily out paces the new 
> capacity being added both globally and regionally with no let up in 
> sight.   Users are frustrated by quality, buffering, and stuttering 
> problems. Video providers and access networks are investing heavily to 
> keep up with demand.  Significant work has be done at the application 
> layer producing more efficient codecs and innovative adaptive bitrate 
> transports like MPEG-DASH.  These access investments and application 
> layer work have helped but they alone have not been enough.
>     >>
>     >> This BoF will introduce the Glass to Glass Internet Ecosystem 
> (GGIE) which focuses on network level innovations to compliment the 
> efforts at the application layer and access networks.  The proposed 
> GGIE work includes enabling adaptive bitrate transports like MPEG-DASH 
> to use IPv6 as their video segment addressing scheme which in turn 
> permits use of advanced IPv6 network features such as Segment Routing. 
>  A GGIE goal is to enabling video and network routing and management 
> to work more cooperatively and efficiently to transport video, and to 
> do so in a backward compatible ways to permit exiting devices and 
> players to take advantage of the improved network efficiencies.
>     >>
>     >>
>     >>
>     >>    Agenda
>     >>    Agenda bash, scribe, minute taker [10min]
>     >>
>     >>    Context setting [15min]
>     >>        Highlights of the Internet Video Scaling Problem
>     >>        Specific aims of the GGIE work
>     >>        Relationship to other IETF activity
>     >>        Relationship to work in other fora
>     >>
>     >>        Overview of existing GGIE work — Network level 
> proposals, demo  [50min]
>     >>             - IPv6 Prefix addressing of MPEG-DASH packaged 
> video
>     >>             - Content identifier to content address mapping 
> using MARS
>     >>         - GGIE prototype demo
>     >>
>     >>    Where from here? [45min]
>     >>        Known open questions
>     >>        Potential for IETF work — is there interest to pursue?
>     >>        If applicable: Discussion of draft charter for WG
>     >>
>     >>
>     >>        Demo of GGIE prototype
>     >>        Q&A & Discussion
>     >>
>     >>    Status: WG Forming
>     >>    Responsible AD: Ben Campbell
>     >>    BoF proponents: Glenn Deen / Leslie Daigle
>     >>    BoF chairs: TBD
>     >>    Number of people expected to attend: TBD
>     >>    Length of session (1, 1.5, 2, or 2.5 hours): 2 hours
>     >>    Conflicts to avoid (whole Areas and/or WGs): DISPATCH WG and 
> TBD
>     >>    Links to the mailing list, draft charter if any, relevant 
> Internet-Drafts, etc.
>     >>        Mailing List: 
> ​https://www.ietf.org/mailman/listinfo/ggie
>     >>        Draft charter: see below
>     >>        Relevant drafts:
>     >>            draft-deen-daigle-ggie-02 :  Glass to Glass Internet 
> Ecosystem Introduction
>     >>        draft-rose-deen-ggie-use-cases-00 : GGIE Internet Video 
> Use Cases
>     >>        draft-daigle-deen-ggie-uri-snaptr-00 :  Glass to Glass 
> Internet Ecosystem URI and S-NAPTR Use
>     >>        draft-deen-naik-ggie-men-mpeg-dash-00 : Using Media 
> Encoding Networks to address MPEG-DASH video (This is expired, but we 
> can easily re-spin, or wait for WG input).
>     >>
>     >>
>     >>
>     >>
>     >> Glass to Glass Internet Ecosystem (GGIE) -- Draft Charter
>     >>
>     >> Due to its size and sensitivity to network conditions, the 
> transport of video over the Internet has highlighted a significant 
> scalability problem for the Internet.  Addressing this scalability 
> problem requires better integration between application transport and 
> networking technologies and leveraging IPv6.  The GGIE working group 
> will define a set of fundamental building blocks bridging video 
> application use of the network and core network services of 
> addressing, routing, and naming. Through standardization, of such 
> fundamentals, a common base platform for new interoperable innovation 
> on video transport efficiency and scalability will be enabled.
>     >>
>     >> The scalability problem is driven by both professional and user 
> generated content, fortunately both types of content use the same 
> transport technologies which permits the working group’s output to 
> apply equally to them. Likewise, in addition to the use the network to 
> transport video for viewing, the network is extensively used in video 
> creation workflows of capture and editing, and distribution workflows 
> of encoding, packaging, and distribution to edge caches for playback.  
>  The working group will address both viewing and creation/distribution 
> workflows.
>     >>
>     >> To that end, the GGIE working group will define missing pieces 
> of Internet technology standards, as well as provide pointers to use 
> of existing standards.
>     >>
>     >> Specifically, the GGIE working group will:
>     >>
>     >> + complete an overview document outlining the GGIE problem 
> statement and general solution approach
>     >> + develop a set of use cases representative of GGIE problem 
> scope
>     >> + develop a standardized URI for referring to specific media 
> objects within a domain
>     >> + develop a standardized means for mapping IPv6 addresses to 
> video data
>     >> + develop a media address resolution service protocol (MARS) to 
> map URIs and addresses for video
>     >> + provide a mechanism for discovering media address resolution 
> services
>     >> + document integration methods with lower level fundamental 
> network services (eg. routing)
>     >> + develop media encoding network (MEN) definitions for video 
> packaging such as MPEG-DASH
>     >> + illustrate how these technologies address the use cases 
> already developed for GGIE
>     >>
>     >> Out of scope are:  video technologies including codecs, digital 
> rights management, and DRM enforcement technologies.
>     >>
>     >>
>     >>
>     >> --
>     >>
>     >> 
> -------------------------------------------------------------------
>     >> Leslie Daigle
>     >> Principal, ThinkingCat Enterprises LLC
>     >> [e-mail]
>     >> 
> -------------------------------------------------------------------_______________________________________________
>     >> GGIE mailing list
>     >> [e-mail]
>     >> https://www.ietf.org/mailman/listinfo/ggie
>     _______________________________________________
>     GGIE mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/ggie
>
>
> _______________________________________________
> GGIE mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ggie