From nobody Thu Aug 4 13:04:02 2016 Return-Path: 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 070B012D151 for ; Thu, 4 Aug 2016 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] 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 EbJh5aOeU3mm for ; Thu, 4 Aug 2016 13:03:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD15812D7E7 for ; Thu, 4 Aug 2016 13:03:54 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTU24472; Thu, 04 Aug 2016 20:03:52 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 4 Aug 2016 21:03:51 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 4 Aug 2016 13:03:46 -0700 From: Linda Dunbar To: "rgd.ietf@gmail.com" Thread-Topic: Some questions on GGIE Thread-Index: AdHui07a5NQKCX88RDuv3ibbQ9kPAQ== Date: Thu, 4 Aug 2016 20:03:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F0F807@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.202] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F0F807dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57A39FA8.0337, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e90e87c758af748429af3536e156cb5f Archived-At: Cc: "ggie@ietf.org" , "ldaigle@thinkingcat.com" Subject: [GGIE] Some questions on GGIE X-BeenThere: ggie@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discuss IETF-related items surfaced in the W3C GGIE Task Force List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 20:04:01 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F0F807dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Glenn, I talked to you during the IETF 96 Bits & Bytes a couple of weeks ago. Really like the content in the draft-deen-daigle-ggie-01. Being a network p= erson, I see some elements of GGIE that network can provide. First a few questions: - Media Encoding Networks (MEN): o Does each instance of MEN represent one "manifest file" for a video con= tent (i.e. the complete set of Chunks for one video)? Like movie A can cons= ist of XX of chunks, and there is one MEN instance for Movie A? another ME= N instance for Movie B? Does the MEN instance for Movie A has XX number of chunks? Does each chunk = have an address (i.e. does each chunk of the video clip has an address)? o "Media Encoded Network" same as "Media Encoding Network"? o Does one instance of "Media Encoding Network" have one address? Or each= element of one MEN have one address? - You mentioned during our conversation in Bits& Bytes to use IPv6 a= ddresses. Are the IPv6 addresses used to represent MEN? Or the elements of = a MEN instance? - Is the "Shard" same as MEN instance? - Your saying of "networking routing the request for the shard" is a= bout find the location addresses for the elements of the Shard, correct? Thank you very much, Linda Dunbar Huawei USA IP Technology Lab 5340 Legacy Drive, Plano, TX 75024 Tel: +1 469-277 - 5840 Fax: +1 469 -277 - 5900 --_000_4A95BA014132FF49AE685FAB4B9F17F657F0F807dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Glenn,

 

I talked to you during the IETF 96 Bits & Bytes = a couple of weeks ago.

Really like the content in the draft-deen-daigle-ggi= e-01. Being a network person, I see some elements of GGIE that network can = provide.

 

First a few questions:

-     &= nbsp;  Media Encoding Networks (MEN):

o   Does each instance of MEN represent one R= 20;manifest file” for a video content (i.e. the complete set of Chunk= s for one video)? Like movie A can consist of XX of chunks, and there is on= e  MEN instance for Movie A? another MEN instance for Movie B?

Does the MEN inst= ance for Movie A has XX number of chunks? Does each chunk have an address (= i.e. does each chunk of the video clip has an address)?

 =

o   “Media Encoded Network” same as = “Media Encoding Network”?

o   Does one instance of “Media Encoding N= etwork” have one address? Or each element of one MEN have one address= ?

-     &= nbsp;  You mentioned during our conversation in Bits& = Bytes to use IPv6 addresses. Are the IPv6 addresses used to represent MEN? = Or the elements of a MEN instance?

-     &= nbsp;  Is the “Shard” same as MEN instance?

-     &= nbsp;  Your saying of “networking routing the reques= t for the shard” is about find the location addresses for the element= s of the Shard, correct?

 

Thank you very much,

 

Linda Dunbar

Huawei USA IP Te= chnology Lab

5340 Legacy Driv= e,

Plano, TX 75024<= o:p>

Tel: +1 469-= 277 - 5840

Fax: +1 469 = -277 - 5900

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657F0F807dfweml501mbb_-- From nobody Thu Aug 4 16:56:08 2016 Return-Path: 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 B0D8C12D531 for ; Thu, 4 Aug 2016 16:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 g__mIC8UN5sj for ; Thu, 4 Aug 2016 16:56:04 -0700 (PDT) Received: from mx0b-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 AA92112D125 for ; Thu, 4 Aug 2016 16:56:04 -0700 (PDT) Received: from pps.filterd (m0048208.ppops.net [127.0.0.1]) by m0048208.ppops.net-00176a04. (8.16.0.11/8.16.0.11) with SMTP id u74NhoVL020052 for ; Thu, 4 Aug 2016 19:56:03 -0400 Received: from usaoamgip001.mail.tfayd.com ([173.213.212.135]) by m0048208.ppops.net-00176a04. with ESMTP id 24ma7qmfnf-1 (version=TLSv1.2 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 04 Aug 2016 19:56:03 -0400 Received: from unknown (HELO USUSHECWP005.mail.tfayd.com) ([10.40.78.204]) by usaoamgip001.mail.tfayd.com with ESMTP; 04 Aug 2016 19:56:01 -0400 Received: from USUSHEMWP012.mail.tfayd.com ([169.254.4.20]) by usushecwp005.mail.tfayd.com ([3.156.41.23]) with mapi id 14.03.0195.001; Thu, 4 Aug 2016 16:56:01 -0700 From: "Deen, Glenn (NBCUniversal)" To: Linda Dunbar , "rgd.ietf@gmail.com" Thread-Topic: [GGIE] Some questions on GGIE Thread-Index: AdHui07a5NQKCX88RDuv3ibbQ9kPAQAIFsuA Date: Thu, 4 Aug 2016 23:56:00 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657F0F807@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F0F807@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.23.192.140] x-exclaimer-md-config: 47edc00f-f2d6-45ef-be83-8a353bd47e45 Content-Type: multipart/alternative; boundary="_000_D3C91B33A7E2Eglenndeennbcunicom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-04_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 impostorscore=0 lowpriorityscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1608040252 Archived-At: Cc: "ggie@ietf.org" , "ldaigle@thinkingcat.com" Subject: Re: [GGIE] Some questions on GGIE X-BeenThere: ggie@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discuss IETF-related items surfaced in the W3C GGIE Task Force List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 23:56:08 -0000 --_000_D3C91B33A7E2Eglenndeennbcunicom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Linda, >> Does each instance of MEN represent one =93manifest file=94 for a video = content (i.e. the complete set of Chunks for one video)? Like movie A can c= onsist of XX of chunks, and there is one MEN instance for Movie A? another= MEN instance for Movie B? Each MEN is defined for a specific type of encode/transport. Think of it li= ke a template for the addresses allocation scheme in the subnetwork addres= ses the video elements/chunks is defined. For instance you could defined a= MEN layout for MPEG-DASH, and assign in the layout that say a particular a= ddress in the network returns the DASH manifest for the player to use. If= you had a different type of encoding/transport that used a different type = of manifest, you would define a different MEN scheme for that encoding/tran= sport. In our demo we defined that address Prefix::0 returned a DASH mani= fest, which is but one way it can be done. The MEN is abstraction/scheme that is defined for different codec/transport= s in a way that is appropriate for the way the particular codec/transport w= orks. This permits GGIE to support essentially any codec/transport since= you just need to define the MEN scheme appropriate for the application. = We defined as an example such a scheme for MEPG-DASH, and we=92ve discuss= ed creating others as examples too. The nice part of this, is that this would let you define new future video t= ransports and they can be added to the GGIE ecosystem by defining an approp= riate MEN. Meaning we don=92t have to have all the answers upfront, and th= e system is easily extensible without changing any of the previous GGIE cho= ices. >> Does the MEN instance for Movie A has XX number of chunks? Does each chu= nk have an address (i.e. does each chunk of the video clip has an address)? Yes, at least for the MEN we defined for MPEG DASH because DASH partitions = the video into chunks. The way you would do it for other transports would = depend on the nature of the transport, but in general yes. II our example= we did give each chunk does have a distinct address, and we also organized= them into a address assignment scheme that reflected the MPEG-DASH iFrame = alignments. >> Media Encoded Network=94 same as =93Media Encoding Network=94? Yes. Forgive us, we are trying to settle down on the terminology and there = are some consistency edits that need to be made in the IDs. >> Does one instance of =93Media Encoding Network=94 have one address? Or e= ach element of one MEN have one address? A MEN instance will have a distinct prefix, and the chunks under it will ha= ve addresses allocated in a format appropriate scheme. Together they are = basically an IPv6 subnet. To introduce a new format, you would define a ne= w MEN for it, and then follow theatMEN scheme when you assign addresses to = the media elements. >>- You mentioned during our conversation in Bits& Bytes to use IPv6= addresses. Are the IPv6 addresses used to represent MEN? Or the elements o= f a MEN instance? An MPEG-DASH MEN is an IPv6 subnet with a common prefix and then each chunk= is allocated an IPv6 address. The layout is in the MEN for MPEG-DASH ID, = but a big part of it is that we organized the chunk with aligned iFrames so= that their shard addresses where all the same, except for the encode ID bi= ts. The layout was of the 128 bits: Prefix N bits : Encoding ID= M bits: Shard ID 128-N-M bits. This lets the MPEG-DASH player chan= ge bit rate encodings by just changing the Encoding ID bits and leaving eve= rything else the same. >> - Is the =93Shard=94 same as MEN instance? MPEG-DASH uses the term Chunk for a block of frames of video with a startin= g iFrame. Since we are trying to make GGIE support a wide variety of enc= odings/transports we use the generic Shard instead of Chunk. Chunk =3D=3D Shard >> Your saying of =93networking routing the request for the shard=94 is ab= out find the location addresses for the elements of the Shard, correct? Yes, but like any routing request it also is about the path to the shard. = This gets to part of the reason why we are proposing addresses for shards= in GGIE, so that the network can be involved in helping make path choices = between the requestor and an instance of the shard. Today it=92s entirely= done by the manifest creator with some interaction with the DNS in many c= ases when it creates the URL=92s that it populates the manifest with. -g -glenn From: GGIE > on behalf = of Linda Dunbar > Date: Thursday, August 4, 2016 at 1:03 PM To: "rgd.ietf@gmail.com" > Cc: "ggie@ietf.org" >, "Leslie Daigle (TCE)" > Subject: [GGIE] Some questions on GGIE Glenn, I talked to you during the IETF 96 Bits & Bytes a couple of weeks ago. Really like the content in the draft-deen-daigle-ggie-01. Being a network p= erson, I see some elements of GGIE that network can provide. First a few questions: - Media Encoding Networks (MEN): o Does each instance of MEN represent one =93manifest file=94 for a video= content (i.e. the complete set of Chunks for one video)? Like movie A can = consist of XX of chunks, and there is one MEN instance for Movie A? anothe= r MEN instance for Movie B? Does the MEN instance for Movie A has XX number of chunks? Does each chunk = have an address (i.e. does each chunk of the video clip has an address)? o =93Media Encoded Network=94 same as =93Media Encoding Network=94? o Does one instance of =93Media Encoding Network=94 have one address? Or = each element of one MEN have one address? - You mentioned during our conversation in Bits& Bytes to use IPv6 a= ddresses. Are the IPv6 addresses used to represent MEN? Or the elements of = a MEN instance? - Is the =93Shard=94 same as MEN instance? - Your saying of =93networking routing the request for the shard=94 = is about find the location addresses for the elements of the Shard, correct= ? Thank you very much, Linda Dunbar Huawei USA IP Technology Lab 5340 Legacy Drive, Plano, TX 75024 Tel: +1 469-277 - 5840 Fax: +1 469 -277 - 5900 --_000_D3C91B33A7E2Eglenndeennbcunicom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0945CAF06FBBEE438CD76B646F1A4FC5@NBCUNI.COM> Content-Transfer-Encoding: quoted-printable
Hi Linda,


>> Does each ins= tance of MEN represent one =93manifest file=94 for a video content (i.e. th= e complete set of Chunks for one video)? Like movie A can consist of XX of = chunks, and there is one  MEN instance for Movie A? another MEN instance for Movie B?

Each MEN is defined for a specific type of encode/transport. Think of it li= ke a template for the  addresses allocation scheme in the subnetwork a= ddresses the video elements/chunks is defined.  For instance you could= defined a MEN layout for MPEG-DASH, and assign in the layout that say a particular address in the network returns the DAS= H manifest for the player to use.   If you had a different type of enc= oding/transport that used a different type of manifest, you would define a = different MEN scheme for that encoding/transport.  In our demo we defined that address  Prefix::0 returned a DASH = manifest, which is but one way it can be done.

The MEN is abstraction/scheme that is defined for different codec/transport= s in a way that is appropriate for the way the particular codec/transport w= orks.    This permits GGIE to support essentially any codec/trans= port since you just need to define the MEN scheme appropriate for the application.     We defined as an exa= mple such a scheme for MEPG-DASH, and we=92ve discussed creating others as = examples too.   

The nice part of this, is that this would let you define new future video t= ransports and they can be added to the GGIE ecosystem by defining an approp= riate MEN.  Meaning we don=92t have to have all the answers upfront, a= nd the system is easily extensible without changing any of the previous GGIE choices.


>> Does the MEN instance for Mo= vie A has XX number of chunks? Does each chunk have an address (i.e. does e= ach chunk of the video clip has an address)?

Yes, at least for the MEN we defined for MPEG DASH because DASH partitions = the video into chunks.  The way you would do it for other transports w= ould depend on the nature of the transport, but in general yes.   II o= ur example we did give each chunk does have a distinct address, and we also organized them into a address assignment s= cheme that reflected the MPEG-DASH iFrame alignments.  


>> Media En= coded Network=94 same as =93Media Encoding Network=94?

= Yes. Forgive us, we are trying to settle d= own on the terminology and there are some consistency edits that need = to be made in the IDs.
=
=
= >> Does one instance of =93Media Encoding Network=94 have one address? Or each element of one MEN have one address?

= A MEN instance will have a distinct prefix= , and the chunks under it will have addresses allocated in a format appropr= iate scheme.   Together they are basically an IPv6 subnet.  To introduce a new format, you would defin= e a new MEN for it, and then follow theatMEN scheme when you assign address= es to the media elements.


>>-       = ; You mentioned during our conversation in Bits& Bytes to use IPv6 addresses= . Are the IPv6 addresses used to represent MEN? Or the elements of a MEN in= stance?

An MPEG-DASH MEN is an IPv6 subnet with a common prefix and then each = chunk is allocated an IPv6 address.  The layout is in the MEN for MPEG= -DASH ID, but a big part of it is that we organized the chunk with aligned = iFrames so that their shard addresses where all the same, except for the encode ID bits.       Th= e layout was  of the 128 bits:     Prefix N bits :  Enc= oding ID M bits:  Shard ID 128-N-M bits.        Th= is lets the MPEG-DASH player change bit rate encodings by just changing the= Encoding ID bits and leaving everything else the same.


>> -        Is the =93Shard=94 same as MEN instance?
MPEG-DASH uses the term Chunk for a block of frames of vid= eo with a starting iFrame.    Since we are trying to make GGIE su= pport a wide variety of encodings/transports we use the generic Shard instead of Chunk.   
Chunk =3D=3D Shard


>>  Your saying of =93networking routing the request for the shard=94 is about find= the location addresses for the elements of the Shard, correct?

= Yes, but like any routing request it also = is about the path to the shard.    This gets to part of the reaso= n why we are proposing addresses for shards in GGIE, so that the network can be involved in helping make path choices between t= he requestor and an instance of the shard.   Today it=92s entirely don= e by  the manifest creator with some interaction with the DNS in many = cases when it creates the URL=92s that it populates the manifest with.


-g   &= nbsp;-glenn

From: GGIE <ggie-bounces@ietf.org> on behalf of Linda Dunba= r <linda.dunbar@huawei.com>
Date: Thursday, August 4, 2016 at 1= :03 PM
To: "rgd.ietf@gmail.com" <rgd.ietf@gmail.com>
Cc: "ggie@ietf.org" <ggie@i= etf.org>, "Leslie Daigle (TCE)" <ldaigle@thinkingcat.com>
Subject: [GGIE] Some questions on G= GIE

Glenn,

 

I talked to you during the IETF 96 Bits & Bytes = a couple of weeks ago.

Really like the content in the draft-deen-daigle-ggi= e-01. Being a network person, I see some elements of GGIE that network can = provide.

 

First a few questions:

-  = ;      Media Encoding Networks (MEN):

o   Does each instance of MEN represent one = =93manifest file=94 for a video content (i.e. the complete set of Chunks fo= r one video)? Like movie A can consist of XX of chunks, and there is one &n= bsp;MEN instance for Movie A? another MEN instance for Movie B?

Does the MEN inst= ance for Movie A has XX number of chunks? Does each chunk have an address (= i.e. does each chunk of the video clip has an address)?

 =

o   =93Media Encoded Network=94 same as =93M= edia Encoding Network=94?

o   Does one instance of =93Media Encoding N= etwork=94 have one address? Or each element of one MEN have one address?

-  = ;      You mentioned during our conversation in Bits&a= mp; Bytes to use IPv6 addresses. Are the IPv6 addresses used to represent M= EN? Or the elements of a MEN instance?

-  = ;      Is the =93Shard=94 same as MEN instance?

-  = ;      Your saying of =93networking routing the reques= t for the shard=94 is about find the location addresses for the elements of= the Shard, correct?

 

Thank you very much,

 

Linda Dunbar

Huawei USA IP Te= chnology Lab

5340 Legacy Driv= e,

Plano, TX 75024<= o:p>

Tel: +1 469-= 277 - 5840

Fax: +1 469 = -277 - 5900

 

 --_000_D3C91B33A7E2Eglenndeennbcunicom_--