[GGIE] Minutes from the Chicago Bar Bof on Video Streaming

"Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com> Mon, 10 July 2017 22:48 UTC

Return-Path: <Glenn.Deen@nbcuni.com>
X-Original-To: ggie@ietfa.amsl.com
Delivered-To: ggie@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AE112EC1B for <ggie@ietfa.amsl.com>; Mon, 10 Jul 2017 15:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AT8mBVtTyz3r for <ggie@ietfa.amsl.com>; Mon, 10 Jul 2017 15:48:49 -0700 (PDT)
Received: from mx0a-00176a04.pphosted.com (mx0b-00176a04.pphosted.com [67.231.157.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0477F12EC32 for <ggie@ietf.org>; Mon, 10 Jul 2017 15:48:48 -0700 (PDT)
Received: from pps.filterd (m0048207.ppops.net [127.0.0.1]) by m0048207.ppops.net-00176a04. (8.16.0.21/8.16.0.21) with SMTP id v6AMmapk009403 for <ggie@ietf.org>; Mon, 10 Jul 2017 18:48:47 -0400
Received: from usaoamgip002.mail.tfayd.com ([173.213.212.136]) by m0048207.ppops.net-00176a04. with ESMTP id 2bmfcetcbd-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for <ggie@ietf.org>; Mon, 10 Jul 2017 18:48:45 -0400
Received: from unknown (HELO USUSHECWP004.mail.tfayd.com) ([10.40.78.204]) by usaoamgip002.mail.tfayd.com with ESMTP; 10 Jul 2017 18:48:44 -0400
Received: from potemwp00032.mail.tfayd.com (100.124.56.56) by USUSHECWP004.mail.tfayd.com (3.156.41.22) with Microsoft SMTP Server (TLS) id 14.3.266.1; Mon, 10 Jul 2017 15:48:29 -0700
Received: from potemwp00029.mail.tfayd.com (100.124.56.53) by potemwp00032.mail.tfayd.com (100.124.56.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.669.32; Mon, 10 Jul 2017 16:48:28 -0600
Received: from potemwp00029.mail.tfayd.com ([100.124.56.53]) by potemwp00029.mail.tfayd.com ([100.124.56.53]) with mapi id 15.01.0669.032; Mon, 10 Jul 2017 16:48:27 -0600
From: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
To: "ggie@ietf.org" <ggie@ietf.org>
Thread-Topic: Minutes from the Chicago Bar Bof on Video Streaming
Thread-Index: AQHS+c6lCPxz6vKXMUKvugolJmuPPw==
Date: Mon, 10 Jul 2017 22:48:27 +0000
Message-ID: <D589524A.DDC15%glenn.deen@nbcuni.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [100.126.25.33]
x-exclaimer-md-config: 47edc00f-f2d6-45ef-be83-8a353bd47e45
Content-Type: multipart/alternative; boundary="_000_D589524ADDC15glenndeennbcunicom_"
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-10_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707100390
Archived-At: <https://mailarchive.ietf.org/arch/msg/ggie/IL9hFYE01p-szBevgiu3ZKYVTFI>
Subject: [GGIE] Minutes from the Chicago Bar Bof on Video Streaming
X-BeenThere: ggie@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discuss IETF-related items surfaced in the W3C GGIE Task Force <ggie.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ggie>, <mailto:ggie-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ggie/>
List-Post: <mailto:ggie@ietf.org>
List-Help: <mailto:ggie-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ggie>, <mailto:ggie-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jul 2017 22:48:55 -0000

Hi everyone,


Here are some rough minutes of the Video Streaming bar-bof in Chicago at IETF98.


-glenn


----------------


Video Streaming Bar-BoF Meeting Minutes

Held on 3/27/2017 During IETF 98, Chicago, IL





Introduction

These are the rough minutes from the informal Video Streaming Bar-BoF held during IETF98.  As a barBoF it wasn't an official IETF event, instead it was an informal meet up of people interested in the topic of Internet video.



Call for Participation



Topic: Video Streaming eXtensions (V-SX)



Description:



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.  On the belief that addressing this scalability problem requires better integration between application transport and networking technologies and leveraging IPv6, this Bar BOF will solicit experiences of the scaling problem as perceived from different parts of the industry (network, producer, vendors).



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.



A target of any eventual work and product is to enable video and network routing / management to work more cooperatively and efficiently to transport video.  Successful approaches will need to do so in a backward compatible ways to permit exiting devices and players to take advantage of the improved network efficiencies.



One proposed approach to dealing with issues was outlined in the Glass to Glass Internet Ecosystem BoF proposal - related drafts and mailing list information is provided below.  A demonstration of GGIE will be provided during the BoF, for illustration purposes.  Discussion is expected and encouraged to range further than the specific GGIE proposal.



This will be an interactive discussion and we encourage anyone with an interest in this topic to come and share their ideas.



Agenda

Introduction

Context setting [5min]

Roundtable discussion of the issue(s) [30min]

Demo of GGIE prototype [10min]

Where from here? [15min]

Potential for IETF work - is there interest to pursue?

Work for other groups?



         Mailing List: https://www.ietf.org/mailman/listinfo/ggie



        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





The Bar BoF Session



Attendance:



Attendance was very good with 70 people counted in the room and a number of others that didn't get counted as they extended out into the hallway.



Unfortunately the session wasn't able to be held in an actual Bar.  After it's initial announcement the response level was going to be too large for the small bar we had picked for the Bar BoF and so the session was relocated to accommodate to large room to handle the attenence.  As it was even the large room was insufficient with many interested people spilling into the hall.



Notes about the BoF



One thing to note when reading the minutes is that while the organizers attempted to make the session discussion a more general discussion and sharing about problems in video streaming as well as exploiting IPv6 features, many attendees where interested in directly discussing the ideas in the GGIE Internet Drafts.  Hence the points raised in the session notes jump between being higher level and being specifically about the IDs.



Session Overview:

* Glenn Deen gave the background - why GGIE?

* Leslie Daigle provided additional info - scaling video; integrating applications at IETF - keeping levels separate but flowing between.

* Mark Townsley - Cisco: Provided some background on Cisco efforts.

* Q: How to extend the network to the higher layers? What can the network layer do to stop the "spinning disc" problem; help the higher layers to do their job.

Audience: [Lars Eggert] - Not clear on the problem statement? Streaming media is not new.

A: [Glenn Deen] - #1 use of the network today is video; growing exponentially... bandwidth/devices. Despite growth of infrastructure, can't keep up. Need to go beyond pipes, codecs, etc.

* Audience: [Jake Holland/Akamai] - See holes in the proposal. ICN looking at this too. What about Multicast?; Looks like large routing tables, etc.

A: [Glenn Deen] There isn't a simple one size fits all problem. We need multiple solutions because there are multiple problems and situations. ICN, Multicast, + others. Could do this in isolation alone but better to do in a public forum with multiple perspectives instead of waiting 5-10 years and then doing a harmonization exercise.





Leslie: Move to round table discussion on the topic.

* [Roni Even]: Differences between VOD and video running around the network. Service provider has a problem with carriage/delivery. Network solutions are being discussed in DVB, elsewhere. They have to buy the equipment, etc. File format is another issue. Major problem is the scope of the work is broad - includes video transport. Not much work in IETF on transport. 5G is addressing similar issues.

* Q: What about multicast? Simultaneous, on demand? AMT for offnet...

A: Addressing sports/live, TV shows, all content in general. YouTube 400 hours/minute upload. [Mark Townsley]- multicast keeps coming up. Not just distribution - G2G [?]. Cisco has an effort called "IP better than broadcast". Multicast is good for concurrency when it can be identified, filling buffers. ICN/CCN is pull-based. Push-based needs to be addressed too. Export some of the multicast from one network to another. Might look different when it looks like v6.

* [Glenn Deen]: Great that others are working on this. But there is one group that is not as active - IETF. IETF helped build the Internet and others look to IETF for expertise for knowledge and expertise.

* [Leslie Daigle] - raise your hands

o How many people came looking for the answer - [none raised].

o How many have the answer - [1 or 2].

o How many have part of the answer. [More hands raised]

* [?] - "ICN guys heads are exploding!". Need a problem statement. Have people start with their problem statements.

* [Greg Shepard] - Cisco: List problems and prioritize.

* Q: [Dave Oran] - how many people believe the problem is at the network layer? Others parts? Own transport, application, naming, other. If the problem scope is what to do in the network layer you need to look more broadly. Have not looked carefully at improving video streaming using QUIC [Google?]. Couple resource management of provider, with edge delivery, other. Microsoft - SDN provider, edge, transport but no network layer.

*  [Leslie Daigle] - How do we stop video from being a monolithic chunk of data,

* [?] - Need to improve the codec because it is linearized.

* [Allison Mankin] - Not much reference to the application - selecting among codecs, abilities of codec. [BITAG - Broadband Tech Advisory Group] looks at managing between video providers. Encourage looking at these.

*

Gaurav/Demo

* Explained and ran the demo

* Q: [Jake Holland] - can this be done by redirect?

A: [Gaurav Naik]: it can't be done unless all sources are aware of alternate sources to do the redirect to them.  That requires a high level of coherency and exterior knowledge and that adds to brittleness and complexity.

o Then why give v6 address. Network already knows how to find prefixes.

A: [Glenn Deen] - Part of the motivation is that today manifest tables are a kind of routing table of their own. But they can make poor choices because they are made by the application/cdn layer and not in cooperation with the network.

* [Jake Holland] - if the problem is mapping to the wrong place, then it could occur at network layer as well.

* [From person in "ICN corner"] - you will no longer have persistent connections? Where is the gain?

*  [Dave Oran]- Server load is a better measure of performance than distance to cache. Need QoS routing with server load metrics.

* [??] - Privacy issues. Passing boundaries causes security issues.

A: [Glenn Deen]- we have an answer to that.

Should provide some potential answers here.

* [Eric Vyncke] - 6CN solution video. Use some bits as a profile in the prefix. Other experiments being done. Matrix of metrics.

* [Alexander Pretrescu - CEA]: For the 3 videos on the demo can they be put on real encoding machines? IPV6 is insignificant compared to v4 today. Are the producers of video v6 ready?

o A: [Glenn Deen]- The encoders used are standard MPEG encoders. We pump out segments. Works with any encoder that produces segments. And the player used is off-the-shelf.

o A: [John Brzozowski] - we live with that every day but will get solved with time.

* Are there any equipment manufacturers that consider v6?

A: John - they will

* Jonathan Lennox - is this just for content from Comcast?

o A: [Glenn Deen] - No

* Jonathan Lennox - This gives Comcast full visibility to competitors' content.

A: [Glenn Deen] - You can assign session level address space as one solution. Looking for other solutions.

o [Mark Townsley] - One Use Case for bits in prefix with meaning is to protect lowest level traffic. Protect existing streams.



Leslie Daigle - wrap up.

* Are people interested in continuing the discussion to see what parts of this can be addressed by IETF? Please hmmm

* General response was hmmms for, none against.

* Provide links, contact info, more information on website, etc., here. Should be a continuously updated (curated?) space for Q&A.



Glenn Deen:

* Please come to bits and bytes on Thursday night [Mar 30, 2017].

* Go to ggie@ietf.org for discussion.











Attendees List



In attendance: ~62 on signup sheet. Total attendance: >70.

(Missing some standing in hallway, a few others that didn't sign up).





Name

Company

Email

Glenn Deen

NBCUniversal

glenn.deen@nbcuni.com

Bill Rose

WJRConsulting

brose@wjrconsulting.com

Leslie Daigle

Thinking Cat Enterprises

ldaigle@thinkingcat.com

Lenny Giulianio

Juniper

lenny@juniper.net

Jeffrey Zhang

Juniper

zzhang@juniper.net

Alex Afanasyev

UCLA

Matt Green

BT

Matt.green@bt.com

Craig Taylor

BBC

Craig.taylor@bbc.co.uk

Lucas Pardue

BBC R&D

Lucas.pardue@bbc.co.uk

Gaurav Naik

Drexel Univ.

gn@drexel.edu

Pierre Pfister

Cisco

ppfister@cisco.com

Kyle Larose

Sandvine

klarose@sandvine.com

Eric Vyncke

Cisco

evyncke@cisco.com

Dan Druta

AT&T

Dd5826@att.com

Natasha Rooney

GSMA

nrooney@gsma.com

Jon Hudson

Earth [Desnet Industries]

Jon.hudson@gmail.com

Al Morton

AT&T Labs

Almorton@att.com

Robert Kebler

Juniper

rkebler@juniper.net

Linda Dunbar

Huawei

Linda.dunbar@huawei.com

Lixia Zhang

UCLA

lixia@cs.ucla.edu

Alex Petrescu

CEA

Alexandre.petrescu@cea.fr



Luis M. Contreras

Telefonica

Luismiguel.contreasmurillo@telefoncia.com

Marvin Zheng

Huawei

Marvin.zhengui@huawei.com

Rachel Huang

Huawei

Rachel.huang@huawei.com

Boris Grozev

Atlassian, Jitsi

bgrozen@atlassian.com

Alex Deacon

MPAA

Alex_deacan@mpaa.org

Mike Wilkinson

NBCUniversal

Mile.wilkinson@nbcuni.com

Scott Mansfield

Ericsson

Scott.mansfield@ericsson.com

Ted Mooney

Internet Society

mooney@isoc.org

Greg Shepherd

Cisco

shep@cisco.com

David Lawrence

Akamai

tale@akamai.com

Allison Mankin

Salesforce



Thomas Schmidt

Hamburg Univ.

toschmidt@haw-hamburg.de

Phil Sorber

Comcast



Bryan Call

Yahoo



Alex Roscoe

Comcast

Alexander_roscoe@cable.comcast.com

Helen Chen

Jabil



Rong Gu

China Mobile



Dirk Kutscher

Huawei



JÜrg Ott

TUM



Sanjay Mishra

Verizon

Sanjay.mishra@verizon.com

Wes George

Neustar



Phil Hallam-Baker

Comodo



Jonathan Lennox

Vidyo



Roni Even

Huawei

 Even.roni@haiwei.com (from internet search)

Lars Eggert

NetApp

 lars@netapp.com (from Internet search)

Thomas Fossati

Nokia



Salvatore Lopez

Ericsson



Dan York

Internet Society



Magnus Westerlund

Ericsson



Christer Holmberg

Ericsson



Jake Holland

Akamia

jholland@akamai.com

Jeffry Handal

Cisco



Stephan Emile

Orange



HervÄ Ruellan

Canon CRF



Justin Cerdones

Arris



Tony Tauber

Comcast



Goran Djukic

Cisco



Daniel Migault

Ericsson