From henry.sinnreich@gmail.com Fri Oct 1 11:43:11 2010 Return-Path: X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 527A53A6D08 for ; Fri, 1 Oct 2010 11:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.157 X-Spam-Level: X-Spam-Status: No, score=-0.157 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZG9V3JUWZy4 for ; Fri, 1 Oct 2010 11:43:03 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 9BBE43A6DF7 for ; Fri, 1 Oct 2010 11:43:03 -0700 (PDT) Received: by pvg7 with SMTP id 7so1097600pvg.31 for ; Fri, 01 Oct 2010 11:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type; bh=WF0eF08VrrFR2vPltchRzUCZQ2p1zTBbJC/Z+RmYETg=; b=SNuPBVCp1wNvg66asXPhCoOVaz5H/IZcPkUWGxvcREStu0G8vqP9Ys6Wc05RbtOVqQ +wqKxYLq6vPUKWhchlbkzvajfGC3mn7/+eMFmMCpwOX04Vh5kg9CEqv3VeHT+N9KtqSA 6Nce7SN3lDyRzbpJ7WJRxQ+TRSCJhfJgulRg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; b=U+dKi5+UW0LfJXJYd7ntp66+Ycw1vHjuQTCoCLJ0iOHeXOKgCMJCwVIxNMUWlVPO5R iPAqnIioLu7Ba0O0LwCTLRlIXD2FjACzRe+MKmBrikLlMM36Qa5wubaTu0NtS1xn8Exx 7iOMU0XjeOxuxd4vw/5aGPs+cpAfDf8hSCdjQ= Received: by 10.114.57.13 with SMTP id f13mr6759288waa.101.1285958632382; Fri, 01 Oct 2010 11:43:52 -0700 (PDT) Received: from [192.168.0.34] (cpe-76-184-249-116.tx.res.rr.com [76.184.249.116]) by mx.google.com with ESMTPS id x2sm1128874ybh.17.2010.10.01.11.43.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 01 Oct 2010 11:43:50 -0700 (PDT) User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Fri, 01 Oct 2010 13:43:48 -0500 From: Henry Sinnreich To: "Luby, Michael" , "httpstreaming@ietf.org" Message-ID: Thread-Topic: [httpstreaming] Why a new standard for streaming HTTP? Thread-Index: ActedoYknOR/8PjHQbi3vQUrdgGyBAADOkWEAMVJjWM= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3368785430_1429648" Subject: Re: [httpstreaming] Why a new standard for streaming HTTP? X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 18:43:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3368785430_1429648 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable This is not an issue of duplicating work in other SDO, but rather why would an IETF standard be different? Obviously, the business models and the resulting standards of the other SDO stake holders may be, legitimately so, different from the global, open Internet. An informational RFC discussing both the =B3why=B2 and the =B3how=B2 would be no doubt very useful and interesting. Qin Wu has already mentioned some items. But since I have no idea how to access the documents of the other SDO, thei= r discussions, meeting slides, the decision process, etc., or even find out who the authors and contributors are, such an RFC may not be doable by individual IETF contributors. Example: Some SDO documents have come to my notice where the word =B3Internet= =B2 was studiously avoided. How can one follow the discussions on how and who came to this editorial direction? Quite troubling in the IETF it would seem. Na=EFve question: If the =B3Internet=B2 does not exist, why have liaison people? The IETF has individual contributors. Never mind the above, there are plenty of reasons to have an Internet standard for streaming HTTP that may differ quite substantially from other SDO. Just think of IPR-free codecs that can be plugged in, vs. the single, heavily licensed video codec I have seen. Which reminds me of similar discussions, meant to avoid an IETF WG for an Internet audio codec. http://datatracker.ietf.org/wg/codec/ Henry On 9/27/10 3:34 PM, "Luby, Michael" wrote: > A few comments/thoughts. >=20 > (1) The SDOs that are already deeply involved in standardizing OTT HTTP > streaming have worked hard to stay aligned, e.g., 3GPP, MPEG, OIPF. Ther= e is > a lot of ongoing coordination between these organizations on HTTP streami= ng > (DASH =8B dynamic adaptive streaming over HTTP), many of the people involve= d are > working across these organizations, and liaisons are being sent back and = forth > to coordinate, etc. For example, they have all adopted the same baseline > standard that was initiated in 3GPP, and features that were developed by = MPEG > are being rolled back into 3GPP, etc. It is not clear what the IETF adds= in > this sense (or perhaps may subtract?) The attempt is to create one stand= ard > across the different organizations, and not disparate competing standards= . >=20 > (2) If there is any effort in this area by the IETF, it would be good to = align > with the goal of one common standard. If there is fragmentation, it will= not > be good for deployment. For example, I=B9ve seen emails on this list that > suggest that the IETF might go in a different direction and use a differe= nt > basis other than HTTP, or do something that is based on HTTP but is contr= ary > to these other standards, and it seems that these directions will only > confuse/slow down any adoption. >=20 > (3) If the IETF decides to go off in a different direction and not use HT= TP > 1.1 as the basis, to avoid confusion it would be really helpful not to ca= ll > this HTTP streaming, but instead call it some other name that is suitable= for > whatever is being standardized. >=20 > Mike Luby >=20 >=20 >=20 > On 9/27/10 12:00 PM, "httpstreaming-request@ietf.org" > wrote: >=20 >> If you have received this digest without all the individual message >> attachments you will need to update your digest options in your list >> subscription. To do so, go to >>=20 >> https://www.ietf.org/mailman/listinfo/httpstreaming >>=20 >> Click the 'Unsubscribe or edit options' button, log in, and set "Get >> MIME or Plain Text Digests?" to MIME. You can set this option >> globally for all the list digests you receive at this point. >>=20 >>=20 >>=20 >> Send httpstreaming mailing list submissions to >> httpstreaming@ietf.org >>=20 >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/httpstreaming >> or, via email, send a message with subject or body 'help' to >> httpstreaming-request@ietf.org >>=20 >> You can reach the person managing the list at >> httpstreaming-owner@ietf.org >>=20 >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of httpstreaming digest..." >=20 >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming --B_3368785430_1429648 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [httpstreaming]  Why a new standard for streaming HTTP?</TI= TLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:14pt= '>This is not an issue of duplicating work in other SDO, but rather why woul= d an IETF standard be different?<BR> <BR> Obviously, the business models and the resulting standards of the other SDO= stake holders may be, legitimately so, different from the global, open Inte= rnet.<BR> <BR> An informational RFC discussing both the “why” and the “h= ow” would be no doubt very useful and interesting. Qin Wu has already = mentioned some items.<BR> But since I have no idea how to access the documents of the other SDO, thei= r discussions, meeting slides, the decision process, etc., or even find out = who the authors and contributors are, such an RFC may not be doable by <I><U= >individual IETF contributors</U></I>.<BR> <BR> Example: Some SDO documents have come to my notice where the word “In= ternet” was studiously avoided.<BR> How can one follow the discussions on how and who came to this editorial di= rection? Quite troubling in the IETF it would seem.<BR> Naïve question: If the “Internet” does not exist, why have= liaison people? The IETF has individual contributors.<BR> <BR> Never mind the above, there are plenty of reasons to have an Internet stand= ard for streaming HTTP that may differ quite substantially from other SDO.<B= R> Just think of IPR-free codecs that can be plugged in, vs. the single, heavi= ly licensed video codec I have seen.<BR> Which reminds me of similar discussions, meant to avoid an IETF WG for an I= nternet audio codec.<BR> <a href=3D"http://datatracker.ietf.org/wg/codec/">http://datatracker.ietf.org= /wg/codec/</a><BR> <BR> Henry<BR> </SPAN><SPAN STYLE=3D'font-size:13pt'><BR> <BR> On 9/27/10 3:34 PM, "Luby, Michael" <<a href=3D"luby@qualcomm.co= m">luby@qualcomm.com</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><= FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:11pt'>A few comments/thoughts.<BR> <BR> (1) The SDOs that are already deeply involved in standardizing OTT HTTP str= eaming have worked hard to stay aligned, e.g., 3GPP, MPEG, OIPF.  There= is a lot of ongoing coordination between these organizations on HTTP stream= ing (DASH — dynamic adaptive streaming over HTTP), many of the people = involved are working across these organizations, and liaisons are being sent= back and forth to coordinate, etc.  For example, they have all adopted= the same baseline standard that was initiated in 3GPP, and features that we= re developed by MPEG are being rolled back into 3GPP, etc.  It is not c= lear what the IETF adds in this sense (or perhaps may subtract?)  The a= ttempt is to create one standard across the different organizations, and not= disparate competing standards.<BR> <BR> (2) If there is any effort in this area by the IETF, it would be good to al= ign with the goal of one common standard.  If there is fragmentation, i= t will not be good for deployment.  For example, I’ve seen emails= on this list that suggest that the IETF might go in a different direction a= nd use a different basis other than HTTP, or do something that is based on H= TTP but is contrary to these other standards, and it seems that these direct= ions will only confuse/slow down any adoption.<BR> <BR> (3) If the IETF decides to go off in a different direction and not use HTTP= 1.1 as the basis, to avoid confusion it would be really helpful not to call= this HTTP streaming, but instead call it some other name that is suitable f= or whatever is being standardized.<BR> <BR> Mike Luby<BR> <BR> <BR> <BR> On 9/27/10 12:00 PM, "<a href=3D"httpstreaming-request@ietf.org">httpstr= eaming-request@ietf.org</a>" <<a href=3D"httpstreaming-request@ietf.or= g">httpstreaming-request@ietf.org</a>> wrote:<BR> <BR> </SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE=3D"1"><FONT FACE=3D"Consolas, Couri= er New, Courier"><SPAN STYLE=3D'font-size:10pt'>If you have received this dige= st without all the individual message<BR> attachments you will need to update your digest options in your list<BR> subscription.  To do so, go to <BR> <BR> <a href=3D"https://www.ietf.org/mailman/listinfo/httpstreaming">https://www.i= etf.org/mailman/listinfo/httpstreaming</a><BR> <BR> Click the 'Unsubscribe or edit options' button, log in, and set "Get<B= R> MIME or Plain Text Digests?" to MIME.  You can set this option<BR= > globally for all the list digests you receive at this point.<BR> <BR> <BR> <BR> Send httpstreaming mailing list submissions to<BR>  <a href=3D"httpstreaming@ietf.org">httpstreaming@ietf.org</a><BR> <BR> To subscribe or unsubscribe via the World Wide Web, visit<BR>  <a href=3D"https://www.ietf.org/mailman/listinfo/httpstreaming">https:/= /www.ietf.org/mailman/listinfo/httpstreaming</a><BR> or, via email, send a message with subject or body 'help' to<BR>  <a href=3D"httpstreaming-request@ietf.org">httpstreaming-request@ietf.o= rg</a><BR> <BR> You can reach the person managing the list at<BR>  <a href=3D"httpstreaming-owner@ietf.org">httpstreaming-owner@ietf.org</= a><BR> <BR> When replying, please edit your Subject line so it is more specific<BR> than "Re: Contents of httpstreaming digest..."<BR> </SPAN></FONT></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, = Arial"><SPAN STYLE=3D'font-size:13pt'><BR> <HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"95%"></SPAN></FONT><SPAN STYLE=3D'font-size:= 13pt'><FONT FACE=3D"Consolas, Courier New, Courier">__________________________= _____________________<BR> httpstreaming mailing list<BR> <a href=3D"httpstreaming@ietf.org">httpstreaming@ietf.org</a><BR> <a href=3D"https://www.ietf.org/mailman/listinfo/httpstreaming">https://www.i= etf.org/mailman/listinfo/httpstreaming</a><BR> </FONT></SPAN></BLOCKQUOTE> </BODY> </HTML> --B_3368785430_1429648-- From Even.roni@huawei.com Wed Oct 6 14:57:59 2010 Return-Path: <Even.roni@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BBCA3A7053 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 14:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.785 X-Spam-Level: X-Spam-Status: No, score=-99.785 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXdrebNBRurJ for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 14:57:57 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9AA693A6FA2 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 14:57:57 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9W00FEV2E0B2@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 07 Oct 2010 05:58:48 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9W0073I2DZDZ@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 07 Oct 2010 05:58:48 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-35-90.red.bezeqint.net [79.183.35.90]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9W000JX2DQ1L@szxml02-in.huawei.com>; Thu, 07 Oct 2010 05:58:47 +0800 (CST) Date: Wed, 06 Oct 2010 23:56:12 +0200 From: Roni Even <Even.roni@huawei.com> In-reply-to: <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> To: "'David A. Bryan'" <dbryan@ethernot.org>, 'Qin Wu' <sunseawq@huawei.com> Message-id: <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4Pw References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 21:57:59 -0000 Hi, I think that David first question is important and here is my view Roni Even > So the two big questions: > > 1) On the topic of this list/HTTP streaming, what do you think is the > problem/problems/scenario we should be looking at? My view is that we are trying to address the transport of media in HTTP both pre-recorded and live. The major issues I see are 1. Address the issue of allowing both push and pull models (addressing the use cases and concerns from Qin draft) 2. Address the startup issue, we have worked in AVT on fast channel/content change and I think this is relevant also in this case. 3. Look at the scaling problem when there is no multicast or broadcast support. In general I think that by having a use cases document that covers the scenarios that look important to the group we can achieve a better understanding of what is the charter of the work. > > 2) What other standards body work in this space are you aware of > (including IETF work), and how do you think any new work would fit in > (or not!) with the answer above? > > Yep, these are really broad, but to me, they seem to be at the heart > of what we need to figure out to move forward. I think that at the > beginning of this thread these were the basic questions Qin was > looking to answer, and I think they are a great place to start. > > David > From abegen@cisco.com Wed Oct 6 15:14:56 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC4E3A71D6 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsTR3eGeODp2 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:14:55 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7C49F3A715B for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 15:14:55 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHaSrExAaMHG/2dsb2JhbACiUXGpXZw2hUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,293,1283731200"; d="scan'208";a="196915619" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 06 Oct 2010 22:15:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o96MFHas003626; Wed, 6 Oct 2010 22:15:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 15:15:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 15:14:54 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> In-Reply-To: <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUA= References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com><AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org>, "Qin Wu" <sunseawq@huawei.com> X-OriginalArrivalTime: 06 Oct 2010 22:15:42.0222 (UTC) FILETIME=[03C11AE0:01CB65A4] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 22:14:56 -0000 > 2. Address the startup issue, we have worked in AVT on fast = channel/content > change and I think this is relevant also in this case. Are you assuming a multicast environment for http streaming? Ow, the = startup issue is not an issue in unicast connections. -acbegen From Even.roni@huawei.com Wed Oct 6 15:27:53 2010 Return-Path: <Even.roni@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51863A71E2 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.432 X-Spam-Level: X-Spam-Status: No, score=-100.432 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COYZA0f+nznA for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:27:52 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id B5C453A71D7 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 15:27:52 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9W00FDT3RVFY@szxga04-in.huawei.com> for httpstreaming@ietf.org; Thu, 07 Oct 2010 06:28:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9W00F8X3RV4B@szxga04-in.huawei.com> for httpstreaming@ietf.org; Thu, 07 Oct 2010 06:28:43 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-35-90.red.bezeqint.net [79.183.35.90]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9W000LZ3RO1L@szxml02-in.huawei.com>; Thu, 07 Oct 2010 06:28:43 +0800 (CST) Date: Thu, 07 Oct 2010 00:26:11 +0200 From: Roni Even <Even.roni@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, "'David A. Bryan'" <dbryan@ethernot.org>, 'Qin Wu' <sunseawq@huawei.com> Message-id: <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUAAACrh4A== References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 22:27:53 -0000 Ali, It is not the same as multicast but is still a problem for live streaming when buffering is used on the server that may delay the data and there is also a need for video synchronization to start rendering. For pre-recorded video this may be due to distance between synchronization points and the size of a chunk sent. Roni Even > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Thursday, October 07, 2010 12:15 AM > To: Roni Even; David A. Bryan; Qin Wu > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal > > > 2. Address the startup issue, we have worked in AVT on fast > channel/content > > change and I think this is relevant also in this case. > > Are you assuming a multicast environment for http streaming? Ow, the > startup issue is not an issue in unicast connections. > > -acbegen From abegen@cisco.com Wed Oct 6 15:39:34 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51DF3A715B for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e5vI3tmpS93 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:39:33 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 01C173A6D8A for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 15:39:32 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ+XrEyrRN+J/2dsb2JhbACiUXGpb5w3hUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,293,1283731200"; d="scan'208";a="283270028" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 06 Oct 2010 22:40:33 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o96MeXTF028135; Wed, 6 Oct 2010 22:40:33 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 15:40:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 15:40:08 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> In-Reply-To: <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUAAACrh4AAAp4ug References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org>, "Qin Wu" <sunseawq@huawei.com> X-OriginalArrivalTime: 06 Oct 2010 22:40:33.0287 (UTC) FILETIME=[7C7F9170:01CB65A7] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 22:39:34 -0000 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Thursday, October 07, 2010 6:26 AM > To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu' > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 > Ali, > It is not the same as multicast but is still a problem for live = streaming > when buffering is used on the server that may delay the data and = there is Sure, http streaming or streaming over another protocol will always be = delayed. The content generation, pushing it to the source servers and = CDN and then getting them to the clients plus the playout buffers will = add up a delay of 20-30 seconds compared to regular over-the-air = broadcast.=20 I don't think there is much we can do about this, especially in the = IETF. > also a need for video synchronization to start rendering. Synchronization among the viewers you mean? That could be a concern but = seriously, since client implementations will differ, network capacities = will differ, i.e., pretty much everything will differ for different = clients, I don't think there is a solution to this. Better said, I don't = think there is a problem. > For pre-recorded video this may be due to distance between = synchronization > points and the size of a chunk sent. Those things are all implementation specific IMO, they are not protocol = issues. -acbegen > Roni Even >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Thursday, October 07, 2010 12:15 AM > > To: Roni Even; David A. Bryan; Qin Wu > > Cc: httpstreaming@ietf.org > > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > > 2. Address the startup issue, we have worked in AVT on fast > > channel/content > > > change and I think this is relevant also in this case. > > > > Are you assuming a multicast environment for http streaming? Ow, the > > startup issue is not an issue in unicast connections. > > > > -acbegen From kathy@iridescentnetworks.com Wed Oct 6 15:47:28 2010 Return-Path: <kathy@iridescentnetworks.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 946913A6F50 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcGixg8RFJYc for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:47:27 -0700 (PDT) Received: from smtp104-mob.biz.mail.gq1.yahoo.com (smtp104-mob.biz.mail.gq1.yahoo.com [98.136.185.195]) by core3.amsl.com (Postfix) with SMTP id AD9903A6D8A for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 15:47:27 -0700 (PDT) Received: (qmail 89674 invoked from network); 6 Oct 2010 22:48:28 -0000 Received: from [10.77.158.135] (kathy@166.205.137.87 with xymcookie) by smtp104-mob.biz.mail.gq1.yahoo.com with SMTP; 06 Oct 2010 15:48:27 -0700 PDT X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: 4vpxCT0VM1nK_mdkdfYveJPMTKiR49nGvGuu0Y42hlnePBH iAgKBk3YUh489F1Sv8Fvbw8NoqB1Me05oFKNs1AWMn8mhL.JcpS.v4CyN1ES hgkNbEax3QuU4_xb9nfJ1u41TunEluirgyrWKu.fkEqa3mtFAYaQlDFJdF_N 48hlspya7cJYvGLf9pjqEoPfMGJJiFiztS2LGzvJWOFSdE5dCmmPiOpI049q dhXvsQFezkS_YQwvNNqOU_hsAyqayNruCGP1rzuPllIFYgtRDD9ouz9U.J1Q B..mmJ2HoyVMVUg33CMiAd3WXy2oS3MMdeNOni7BRMISBpZLSMSg0krcRzA- - X-Yahoo-Newman-Property: ymail-3 References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (iPhone Mail 8B117) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> X-Apple-Yahoo-Original-Message-Folder: Inbox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <21A8E503-D640-4947-BFF1-EE5A5D3643E9@iridescentnetworks.com> X-Mailer: iPhone Mail (8B117) From: Kathy McEwen <kathy@iridescentnetworks.com> X-Apple-Yahoo-Replied-Msgid: 1_329534_ALjHjkQAANX0TKz66gClYz+sSTQ Date: Wed, 6 Oct 2010 15:47:50 -0700 To: "Ali C. Begen \(abegen\)" <abegen@cisco.com> Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 22:47:28 -0000 Content does not have to be pushed from broadcaster to a source server and t= hen to a CDN to make it out to users devices. We are working directly with v= ery large national broadcasters in north america and Europe who want to push= multicast broadcast real time event content on to the web directly from the= ir sites to users much like they do with content pushed to cable and satelli= te distribution networks.=20 .../Kathy=20 Sent from my mobile On Oct 6, 2010, at 3:40 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote= : >=20 >=20 >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Thursday, October 07, 2010 6:26 AM >> To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu' >> Cc: httpstreaming@ietf.org >> Subject: RE: [httpstreaming] Current Status and Our Goal >>=20 >> Ali, >> It is not the same as multicast but is still a problem for live streaming= >> when buffering is used on the server that may delay the data and there i= s >=20 > Sure, http streaming or streaming over another protocol will always be del= ayed. The content generation, pushing it to the source servers and CDN and t= hen getting them to the clients plus the playout buffers will add up a delay= of 20-30 seconds compared to regular over-the-air broadcast.=20 >=20 > I don't think there is much we can do about this, especially in the IETF. >=20 >> also a need for video synchronization to start rendering. >=20 > Synchronization among the viewers you mean? That could be a concern but se= riously, since client implementations will differ, network capacities will d= iffer, i.e., pretty much everything will differ for different clients, I don= 't think there is a solution to this. Better said, I don't think there is a p= roblem. >=20 >> For pre-recorded video this may be due to distance between synchronizatio= n >> points and the size of a chunk sent. >=20 > Those things are all implementation specific IMO, they are not protocol is= sues. >=20 > -acbegen >=20 >> Roni Even >>=20 >>> -----Original Message----- >>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>> Sent: Thursday, October 07, 2010 12:15 AM >>> To: Roni Even; David A. Bryan; Qin Wu >>> Cc: httpstreaming@ietf.org >>> Subject: RE: [httpstreaming] Current Status and Our Goal >>>=20 >>>> 2. Address the startup issue, we have worked in AVT on fast >>> channel/content >>>> change and I think this is relevant also in this case. >>>=20 >>> Are you assuming a multicast environment for http streaming? Ow, the >>> startup issue is not an issue in unicast connections. >>>=20 >>> -acbegen >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From tme@americafree.tv Wed Oct 6 15:49:32 2010 Return-Path: <tme@americafree.tv> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D663A7206 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNSjvk1Oyq9v for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 15:49:31 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 6B2B23A71FF for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 15:49:31 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 07EA68FA9612; Wed, 6 Oct 2010 18:50:32 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks <tme@americafree.tv> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> Date: Wed, 6 Oct 2010 18:50:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <B465C6C1-E24A-4555-90B0-FE86AF9647BC@americafree.tv> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com> X-Mailer: Apple Mail (2.1081) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 22:49:32 -0000 On Oct 6, 2010, at 6:40 PM, Ali C. Begen (abegen) wrote: >=20 >=20 >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Thursday, October 07, 2010 6:26 AM >> To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu' >> Cc: httpstreaming@ietf.org >> Subject: RE: [httpstreaming] Current Status and Our Goal >>=20 >> Ali, >> It is not the same as multicast but is still a problem for live = streaming >> when buffering is used on the server that may delay the data and = there is >=20 > Sure, http streaming or streaming over another protocol will always be = delayed. The content generation, pushing it to the source servers and = CDN and then getting them to the clients plus the playout buffers will = add up a delay of 20-30 seconds compared to regular over-the-air = broadcast.=20 >=20 Are you talking about start times, or latency behind real time ? If it = takes you a minimum of 20 seconds to start your video, you might as well = not bother from a business standpoint, IMHO. Even small differences in video start times are viewed as a powerful = competitive advantage in this business, and so there is going to be a strong push to shorten start = times. Regards Marshall > I don't think there is much we can do about this, especially in the = IETF. >=20 >> also a need for video synchronization to start rendering. >=20 > Synchronization among the viewers you mean? That could be a concern = but seriously, since client implementations will differ, network = capacities will differ, i.e., pretty much everything will differ for = different clients, I don't think there is a solution to this. Better = said, I don't think there is a problem. >=20 >> For pre-recorded video this may be due to distance between = synchronization >> points and the size of a chunk sent. >=20 > Those things are all implementation specific IMO, they are not = protocol issues. >=20 > -acbegen >=20 >> Roni Even >>=20 >>> -----Original Message----- >>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>> Sent: Thursday, October 07, 2010 12:15 AM >>> To: Roni Even; David A. Bryan; Qin Wu >>> Cc: httpstreaming@ietf.org >>> Subject: RE: [httpstreaming] Current Status and Our Goal >>>=20 >>>> 2. Address the startup issue, we have worked in AVT on fast >>> channel/content >>>> change and I think this is relevant also in this case. >>>=20 >>> Are you assuming a multicast environment for http streaming? Ow, the >>> startup issue is not an issue in unicast connections. >>>=20 >>> -acbegen >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From abegen@cisco.com Wed Oct 6 16:34:30 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E8FC3A7220 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqPyTvAEuvC1 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:34:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3D6D13A7208 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 16:34:29 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAWlrEyrR7H+/2dsb2JhbACiUXGqCJwthUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,294,1283731200"; d="scan'208";a="241674207" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2010 23:35:21 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o96NZLcj017581; Wed, 6 Oct 2010 23:35:22 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 16:35:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 16:35:16 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <21A8E503-D640-4947-BFF1-EE5A5D3643E9@iridescentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActlqKTduOenwtz1StmHDs9PGIzXZAABnwkR From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: <kathy@iridescentnetworks.com> X-OriginalArrivalTime: 06 Oct 2010 23:35:17.0052 (UTC) FILETIME=[21C657C0:01CB65AF] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 23:34:30 -0000 Sure but preparing that content for multicast does not happen right = away. If you want adaptive streaming style delivery over the web, you = will incur delays. And there is wrong with that.=20 However, if you are saying they first prepare the content for web = delivery and then push it to iptv or cable networks, the delay diff will = be less between them, although relative delay wrt OTA will not change = much.=20 -acbegen ----- Original Message ----- From: Kathy McEwen <kathy@iridescentnetworks.com> To: Ali C. Begen (abegen) Cc: Roni Even <Even.roni@huawei.com>; David A. Bryan = <dbryan@ethernot.org>; Qin Wu <sunseawq@huawei.com>; = httpstreaming@ietf.org <httpstreaming@ietf.org> Sent: Wed Oct 06 15:47:50 2010 Subject: Re: [httpstreaming] Current Status and Our Goal Content does not have to be pushed from broadcaster to a source server = and then to a CDN to make it out to users devices. We are working = directly with very large national broadcasters in north america and = Europe who want to push multicast broadcast real time event content on = to the web directly from their sites to users much like they do with = content pushed to cable and satellite distribution networks.=20 .../Kathy=20 Sent from my mobile On Oct 6, 2010, at 3:40 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> = wrote: >=20 >=20 >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Thursday, October 07, 2010 6:26 AM >> To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu' >> Cc: httpstreaming@ietf.org >> Subject: RE: [httpstreaming] Current Status and Our Goal >>=20 >> Ali, >> It is not the same as multicast but is still a problem for live = streaming >> when buffering is used on the server that may delay the data and = there is >=20 > Sure, http streaming or streaming over another protocol will always be = delayed. The content generation, pushing it to the source servers and = CDN and then getting them to the clients plus the playout buffers will = add up a delay of 20-30 seconds compared to regular over-the-air = broadcast.=20 >=20 > I don't think there is much we can do about this, especially in the = IETF. >=20 >> also a need for video synchronization to start rendering. >=20 > Synchronization among the viewers you mean? That could be a concern = but seriously, since client implementations will differ, network = capacities will differ, i.e., pretty much everything will differ for = different clients, I don't think there is a solution to this. Better = said, I don't think there is a problem. >=20 >> For pre-recorded video this may be due to distance between = synchronization >> points and the size of a chunk sent. >=20 > Those things are all implementation specific IMO, they are not = protocol issues. >=20 > -acbegen >=20 >> Roni Even >>=20 >>> -----Original Message----- >>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>> Sent: Thursday, October 07, 2010 12:15 AM >>> To: Roni Even; David A. Bryan; Qin Wu >>> Cc: httpstreaming@ietf.org >>> Subject: RE: [httpstreaming] Current Status and Our Goal >>>=20 >>>> 2. Address the startup issue, we have worked in AVT on fast >>> channel/content >>>> change and I think this is relevant also in this case. >>>=20 >>> Are you assuming a multicast environment for http streaming? Ow, the >>> startup issue is not an issue in unicast connections. >>>=20 >>> -acbegen >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From abegen@cisco.com Wed Oct 6 16:37:58 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59C7B3A7235 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asY1vr1YdN7K for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:37:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 235413A7224 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 16:37:56 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAWlrEyrR7H+/2dsb2JhbACiUXGqCJwthUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,294,1283731200"; d="scan'208";a="241674593" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 06 Oct 2010 23:38:57 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o96NcvNE019893; Wed, 6 Oct 2010 23:38:57 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 16:38:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 16:38:56 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A5@xmb-sjc-215.amer.cisco.com> In-Reply-To: <B465C6C1-E24A-4555-90B0-FE86AF9647BC@americafree.tv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActlqOIpQ8yAro4YSeKlswkj9Plw8wABsJA2 From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: <tme@americafree.tv> X-OriginalArrivalTime: 06 Oct 2010 23:38:57.0443 (UTC) FILETIME=[A5235730:01CB65AF] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 23:37:58 -0000 I was referring to latecy wrt real time. That is what Roni was talking = about from what I can tell.=20 As for the startup delay, nobody is saying the opposite. But tricks to = make it faster are secret sauce to each implementation. And in unicast = (as opposed to multicast), there more available tools at our disposal.=20 -acbegen ----- Original Message ----- From: Marshall Eubanks <tme@americafree.tv> To: Ali C. Begen (abegen) Cc: Roni Even <Even.roni@huawei.com>; David A. Bryan = <dbryan@ethernot.org>; Qin Wu <sunseawq@huawei.com>; = httpstreaming@ietf.org <httpstreaming@ietf.org> Sent: Wed Oct 06 15:50:31 2010 Subject: Re: [httpstreaming] Current Status and Our Goal On Oct 6, 2010, at 6:40 PM, Ali C. Begen (abegen) wrote: >=20 >=20 >> -----Original Message----- >> From: Roni Even [mailto:Even.roni@huawei.com] >> Sent: Thursday, October 07, 2010 6:26 AM >> To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu' >> Cc: httpstreaming@ietf.org >> Subject: RE: [httpstreaming] Current Status and Our Goal >>=20 >> Ali, >> It is not the same as multicast but is still a problem for live = streaming >> when buffering is used on the server that may delay the data and = there is >=20 > Sure, http streaming or streaming over another protocol will always be = delayed. The content generation, pushing it to the source servers and = CDN and then getting them to the clients plus the playout buffers will = add up a delay of 20-30 seconds compared to regular over-the-air = broadcast.=20 >=20 Are you talking about start times, or latency behind real time ? If it = takes you a minimum of 20 seconds to start your video, you might as well = not bother from a business standpoint, IMHO. Even small differences in video start times are viewed as a powerful = competitive advantage in this business, and so there is going to be a strong push to shorten start = times. Regards Marshall > I don't think there is much we can do about this, especially in the = IETF. >=20 >> also a need for video synchronization to start rendering. >=20 > Synchronization among the viewers you mean? That could be a concern = but seriously, since client implementations will differ, network = capacities will differ, i.e., pretty much everything will differ for = different clients, I don't think there is a solution to this. Better = said, I don't think there is a problem. >=20 >> For pre-recorded video this may be due to distance between = synchronization >> points and the size of a chunk sent. >=20 > Those things are all implementation specific IMO, they are not = protocol issues. >=20 > -acbegen >=20 >> Roni Even >>=20 >>> -----Original Message----- >>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>> Sent: Thursday, October 07, 2010 12:15 AM >>> To: Roni Even; David A. Bryan; Qin Wu >>> Cc: httpstreaming@ietf.org >>> Subject: RE: [httpstreaming] Current Status and Our Goal >>>=20 >>>> 2. Address the startup issue, we have worked in AVT on fast >>> channel/content >>>> change and I think this is relevant also in this case. >>>=20 >>> Are you assuming a multicast environment for http streaming? Ow, the >>> startup issue is not an issue in unicast connections. >>>=20 >>> -acbegen >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From kathy@iridescentnetworks.com Wed Oct 6 16:47:39 2010 Return-Path: <kathy@iridescentnetworks.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B793A7237 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6A18O5hpyft for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 16:47:38 -0700 (PDT) Received: from smtp107-mob.biz.mail.gq1.yahoo.com (smtp107-mob.biz.mail.gq1.yahoo.com [98.136.185.198]) by core3.amsl.com (Postfix) with SMTP id 301453A6EA0 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 16:47:38 -0700 (PDT) Received: (qmail 91360 invoked from network); 6 Oct 2010 23:48:36 -0000 Received: from [10.77.158.135] (kathy@166.205.137.87 with xymcookie) by smtp107-mob.biz.mail.gq1.yahoo.com with SMTP; 06 Oct 2010 16:48:35 -0700 PDT X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: VpkhRg8VM1nmPOqOPMrb6p6AA4DoO3miBKZN6Lu5ziAL2nD oh5lY__lIHpJVPl1GAHteLGjdcxy2jFCBdaNy0.u92kkmvf9Cjss_oQQEVKn zXiVAjpoYP6bD3oTEtjYYOKEs1NX11WzYIapsE0jENzsymfxSRBrjVdWgV_. whL35tCGc.KxbBi9JFT6jxn8mammCrgKC4xsiiGMCjrqcD4humiHaAg4e4Ee 7.J6v14GUGFfkklONPHazWg8RtThG5QC7ggErEck69ljUNCbMo6Bqb1ERbnn yvbxceWVNHbAiqA5ZdauvHg-- X-Yahoo-Newman-Property: ymail-3 References: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A4@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (iPhone Mail 8B117) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A4@xmb-sjc-215.amer.cisco.com> X-Apple-Yahoo-Original-Message-Folder: Inbox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <C968BE22-93C9-4BB1-AB93-15AE1D861A8F@iridescentnetworks.com> X-Mailer: iPhone Mail (8B117) From: Kathy McEwen <kathy@iridescentnetworks.com> X-Apple-Yahoo-Replied-Msgid: 1_331895_ALTHjkQAAXnYTK0HwgS9QHA3fYA Date: Wed, 6 Oct 2010 16:47:58 -0700 To: "Ali C. Begen \(abegen\)" <abegen@cisco.com> Cc: "<httpstreaming@ietf.org>" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 06 Oct 2010 23:47:39 -0000 There are ways to reduce and eliminate the delays to set up the multicast as= well. Adaptive streaming over the web does not preclude improvements to mu= lticast efficiencies. Rather, a co operative implementation of adaptive str= eaming and highly efficient multicasting is perhaps the needed secret sauce.= .. To be made not so secret thru open industry standardization. .../Kathy Sent from my mobile On Oct 6, 2010, at 4:35 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote= : > Sure but preparing that content for multicast does not happen right away. I= f you want adaptive streaming style delivery over the web, you will incur de= lays. And there is wrong with that.=20 >=20 > However, if you are saying they first prepare the content for web delivery= and then push it to iptv or cable networks, the delay diff will be less bet= ween them, although relative delay wrt OTA will not change much.=20 >=20 > -acbegen >=20 > ----- Original Message ----- > From: Kathy McEwen <kathy@iridescentnetworks.com> > To: Ali C. Begen (abegen) > Cc: Roni Even <Even.roni@huawei.com>; David A. Bryan <dbryan@ethernot.org>= ; Qin Wu <sunseawq@huawei.com>; httpstreaming@ietf.org <httpstreaming@ietf.o= rg> > Sent: Wed Oct 06 15:47:50 2010 > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > Content does not have to be pushed from broadcaster to a source server and= then to a CDN to make it out to users devices. We are working directly wit= h very large national broadcasters in north america and Europe who want to p= ush multicast broadcast real time event content on to the web directly from t= heir sites to users much like they do with content pushed to cable and satel= lite distribution networks.=20 >=20 > .../Kathy=20 >=20 > Sent from my mobile >=20 > On Oct 6, 2010, at 3:40 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wro= te: >=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Roni Even [mailto:Even.roni@huawei.com] >>> Sent: Thursday, October 07, 2010 6:26 AM >>> To: Ali C. Begen (abegen); 'David A. Bryan'; 'Qin Wu' >>> Cc: httpstreaming@ietf.org >>> Subject: RE: [httpstreaming] Current Status and Our Goal >>>=20 >>> Ali, >>> It is not the same as multicast but is still a problem for live streamin= g >>> when buffering is used on the server that may delay the data and there i= s >>=20 >> Sure, http streaming or streaming over another protocol will always be de= layed. The content generation, pushing it to the source servers and CDN and t= hen getting them to the clients plus the playout buffers will add up a delay= of 20-30 seconds compared to regular over-the-air broadcast.=20 >>=20 >> I don't think there is much we can do about this, especially in the IETF.= >>=20 >>> also a need for video synchronization to start rendering. >>=20 >> Synchronization among the viewers you mean? That could be a concern but s= eriously, since client implementations will differ, network capacities will d= iffer, i.e., pretty much everything will differ for different clients, I don= 't think there is a solution to this. Better said, I don't think there is a p= roblem. >>=20 >>> For pre-recorded video this may be due to distance between synchronizati= on >>> points and the size of a chunk sent. >>=20 >> Those things are all implementation specific IMO, they are not protocol i= ssues. >>=20 >> -acbegen >>=20 >>> Roni Even >>>=20 >>>> -----Original Message----- >>>> From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >>>> Sent: Thursday, October 07, 2010 12:15 AM >>>> To: Roni Even; David A. Bryan; Qin Wu >>>> Cc: httpstreaming@ietf.org >>>> Subject: RE: [httpstreaming] Current Status and Our Goal >>>>=20 >>>>> 2. Address the startup issue, we have worked in AVT on fast >>>> channel/content >>>>> change and I think this is relevant also in this case. >>>>=20 >>>> Are you assuming a multicast environment for http streaming? Ow, the >>>> startup issue is not an issue in unicast connections. >>>>=20 >>>> -acbegen >>=20 >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming From abegen@cisco.com Wed Oct 6 17:28:16 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFAB3A6EB3 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 17:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcBudWVuW-fO for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 17:28:15 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3980D3A6D97 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 17:28:15 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGexrEyrR7H+/2dsb2JhbACiUXGpc5wuhUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,294,1283731200"; d="scan'208";a="600270514" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 07 Oct 2010 00:29:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o970TGeL019390; Thu, 7 Oct 2010 00:29:16 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Oct 2010 17:29:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Oct 2010 17:28:02 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB86@xmb-sjc-215.amer.cisco.com> In-Reply-To: <C968BE22-93C9-4BB1-AB93-15AE1D861A8F@iridescentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActlsP/zDuFljiezTF+wIMUWJXZmnAABLBig References: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A4@xmb-sjc-215.amer.cisco.com> <C968BE22-93C9-4BB1-AB93-15AE1D861A8F@iridescentnetworks.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Kathy McEwen" <kathy@iridescentnetworks.com> X-OriginalArrivalTime: 07 Oct 2010 00:29:16.0425 (UTC) FILETIME=[AC976F90:01CB65B6] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 00:28:16 -0000 > > Sure but preparing that content for multicast does not happen right = away. If you want adaptive streaming style delivery > over the web, you will incur delays. And there is wrong with that. Sorry for the missing word. I meant there is *nothing* wrong with that. > -----Original Message----- > From: Kathy McEwen [mailto:kathy@iridescentnetworks.com] > Sent: Thursday, October 07, 2010 7:48 AM > To: Ali C. Begen (abegen) > Cc: <Even.roni@huawei.com>; <dbryan@ethernot.org>; = <sunseawq@huawei.com>; <httpstreaming@ietf.org> > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > There are ways to reduce and eliminate the delays to set up the = multicast as well. Adaptive streaming over the web does not > preclude improvements to multicast efficiencies. Rather, a co = operative implementation of adaptive streaming and highly > efficient multicasting is perhaps the needed secret sauce... To be = made not so secret thru open industry standardization. Oh well, I don't disagree with the above except the fact that some = things are meant to stay as secret sauce. Furthermore, viewers are = becoming more and more non-live content consumers even for the live = events (for different reasons). -acbegen =20 > .../Kathy From kathy@iridescentnetworks.com Wed Oct 6 17:44:30 2010 Return-Path: <kathy@iridescentnetworks.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AD73A7015 for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 17:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiFOO+Iur6iT for <httpstreaming@core3.amsl.com>; Wed, 6 Oct 2010 17:44:29 -0700 (PDT) Received: from smtp110-mob.biz.mail.ac4.yahoo.com (smtp110-mob.biz.mail.ac4.yahoo.com [76.13.13.231]) by core3.amsl.com (Postfix) with SMTP id 353663A6EB3 for <httpstreaming@ietf.org>; Wed, 6 Oct 2010 17:44:29 -0700 (PDT) Received: (qmail 21751 invoked from network); 7 Oct 2010 00:45:25 -0000 Received: from [10.77.158.135] (kathy@166.205.137.87 with xymcookie) by smtp110-mob.biz.mail.ac4.yahoo.com with SMTP; 06 Oct 2010 17:45:24 -0700 PDT X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: nfZxJdEVM1kWgIJS6pcruaTRQJNRQU50U1SWpywVNrHmrmD VhvxnjqlPHBYX5KanFXWGMyTYkF7fmKQM9Ztfh7XgxXhTHrN2ASfjyBhwUY_ UCcQHwh7jlFkMmbyZeE2bwngNeunsnglAOez4_eJttMiznkjYSKQH8.uw6c2 trYQZXQOcTZ0pXmdIefK8bAHNWC1.2vh.0RZ3e9.5EaO_BC9HArlr7ceOEl. uGXGd7RZ8P._3YYQ1UaF1BT0EmI47DMQBkG4Yh7vlx4fG7vvCWljnKwO_MYH epfb7i3ouFvVnrebpxcz0gA-- X-Yahoo-Newman-Property: ymail-3 References: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1A4@xmb-sjc-215.amer.cisco.com> <C968BE22-93C9-4BB1-AB93-15AE1D861A8F@iridescentnetworks.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB86@xmb-sjc-215.amer.cisco.com> Mime-Version: 1.0 (iPhone Mail 8B117) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB86@xmb-sjc-215.amer.cisco.com> X-Apple-Yahoo-Original-Message-Folder: Inbox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <CD447E6B-8B4E-4407-8E8C-FCD4C7587986@iridescentnetworks.com> X-Mailer: iPhone Mail (8B117) From: Kathy McEwen <kathy@iridescentnetworks.com> X-Apple-Yahoo-Replied-Msgid: 1_334739_ALTHjkQAALD1TK0UXQPmr0zTNPk Date: Wed, 6 Oct 2010 17:44:47 -0700 To: "Ali C. Begen \(abegen\)" <abegen@cisco.com> Cc: "<httpstreaming@ietf.org>" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 00:44:30 -0000 There is a problem with delay over the web if a service provider wants to pr= ovide a service with the absolute minimal delays giving consumers of broadca= st tv an experience they have come to expect on delivery setup times. Perha= ps physics will preclude us from ever being as fast as delivering all conten= t down a pipe to consumers homes...we may still find ways to be supremely be= tter than 20 seconds or even 1 to 2 seconds.=20 Sent from my mobile On Oct 6, 2010, at 5:28 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote= : >>> Sure but preparing that content for multicast does not happen right away= . If you want adaptive streaming style delivery >> over the web, you will incur delays. And there is wrong with that. >=20 > Sorry for the missing word. I meant there is *nothing* wrong with that. >=20 >> -----Original Message----- >> From: Kathy McEwen [mailto:kathy@iridescentnetworks.com] >> Sent: Thursday, October 07, 2010 7:48 AM >> To: Ali C. Begen (abegen) >> Cc: <Even.roni@huawei.com>; <dbryan@ethernot.org>; <sunseawq@huawei.com>;= <httpstreaming@ietf.org> >> Subject: Re: [httpstreaming] Current Status and Our Goal >>=20 >> There are ways to reduce and eliminate the delays to set up the multicast= as well. Adaptive streaming over the web does not >> preclude improvements to multicast efficiencies. Rather, a co operative i= mplementation of adaptive streaming and highly >> efficient multicasting is perhaps the needed secret sauce... To be made n= ot so secret thru open industry standardization. >=20 > Oh well, I don't disagree with the above except the fact that some things a= re meant to stay as secret sauce. Furthermore, viewers are becoming more and= more non-live content consumers even for the live events (for different rea= sons). >=20 > -acbegen >=20 >> .../Kathy >=20 From csp@csperkins.org Thu Oct 7 04:16:09 2010 Return-Path: <csp@csperkins.org> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA0583A70D4 for <httpstreaming@core3.amsl.com>; Thu, 7 Oct 2010 04:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.376 X-Spam-Level: X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OL7H412zxudd for <httpstreaming@core3.amsl.com>; Thu, 7 Oct 2010 04:16:05 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 89E993A721D for <httpstreaming@ietf.org>; Thu, 7 Oct 2010 04:15:59 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P3oT6-0001m6-gN; Thu, 07 Oct 2010 11:17:00 +0000 Message-Id: <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> From: Colin Perkins <csp@csperkins.org> To: Roni Even <Even.roni@huawei.com> In-Reply-To: <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 7 Oct 2010 12:16:58 +0100 References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> X-Mailer: Apple Mail (2.936) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 07 Oct 2010 11:16:09 -0000 On 6 Oct 2010, at 22:56, Roni Even wrote: > I think that David first question is important and here is my view > > Roni Even > >> So the two big questions: >> >> 1) On the topic of this list/HTTP streaming, what do you think is the >> problem/problems/scenario we should be looking at? > > My view is that we are trying to address the transport of media in > HTTP both pre-recorded and live. The major issues I see are > > 1. Address the issue of allowing both push and pull models > (addressing the use cases and concerns from Qin draft) > 2. Address the startup issue, we have worked in AVT on fast channel/ > content change and I think this is relevant also in this case. > 3. Look at the scaling problem when there is no multicast or broadcast > support. > > In general I think that by having a use cases document that covers the > scenarios that look important to the group we can achieve a better > understanding of what is the charter of the work. There are clearly some issues to consider here. What seems to be missing from the discussion to me though, is some identification of the concrete problems. What protocol pieces do we need, but not have? What protocols are problematic, and need enhancement? Is there protocol work to do in IETF, or should we be documenting best current practices for using the existing protocols and/or relying on other bodies to fill the gaps? The draft-wu-http-streaming-optimization-ps is a good start at such an analysis, but doesn't go deep enough to let us decide what work IETF should do. -- Colin Perkins http://csperkins.org/ From sunseawq@huawei.com Fri Oct 8 00:21:09 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE993A680E for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 00:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9JUm4KeWc6s for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 00:21:08 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4AB3A3A6828 for <httpstreaming@ietf.org>; Fri, 8 Oct 2010 00:21:07 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y0007RN4ON8@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 15:22:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y00510N4O6X@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 15:22:00 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9Y003OWN4NYE@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 15:22:00 +0800 (CST) Date: Fri, 08 Oct 2010 15:21:59 +0800 From: Qin Wu <sunseawq@huawei.com> To: Roni Even <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org> Message-id: <069301cb66b9$7f2141e0$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Oct 2010 07:21:09 -0000 > In general I think that by having a use cases document that covers the > scenarios that look important to the group we can achieve a better > understanding of what is the charter of the work. [Qin]: Good point, we do have some use cases which hasn't been taken out from HTTP Streaming Problem Statement draft (http://www.ietf.org/id/draft-wu-http-streaming-optimization-ps-02.txt). Four typical use cases in my mind would be: case 1: Live Streaming Media broadcast case 2: RTP to HTTP Gateway, which is possible case to address multicast support. case 3: "Multi-Screen" Service Delivery case 4: Heterogeneous Handover Hope it helps get a better understanding what the scenarios may may look like. If anybody would like to contribute to use case document or provide more input, that will be great. From sunseawq@huawei.com Fri Oct 8 00:59:02 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FB693A67A6 for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 00:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY9iaM+Zz8MP for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 00:59:01 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E59913A67A3 for <httpstreaming@ietf.org>; Fri, 8 Oct 2010 00:59:00 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y00G5ZOVUWD@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 15:59:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y00HGWOVU2S@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 15:59:54 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9Y00793OVTAY@szxml06-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 15:59:54 +0800 (CST) Date: Fri, 08 Oct 2010 15:59:52 +0800 From: Qin Wu <sunseawq@huawei.com> To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <06f801cb66be$ca3a7840$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <18429BFD-5C5F-4513-85B7-8B91F6D28C97@niven-jenkins.co.uk> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Oct 2010 07:59:02 -0000 > 1) On the topic of this list/HTTP streaming, what do you think is the > problem/problems/scenario we should be looking at? > I do not feel I am in a position just yet to start making statements about what problems I think a HTTP streaming group (if formed) should look at, however one area that I think may be interesting to study and that I am not aware of other bodies looking at is "chunk hints". A lot of streaming media today is delivered via CDNs that operate as more than just a dumb (inline) proxy cache. HTTP naturally supports the insertion of caches transparently to the end points so one could argue that nothing more needs to be done for HTTP streaming than for regular HTTP. As adaptive bit rate combined with HTTP delivery relies on throughput measurements to determine the appropriate bit rate to download for subsequent chunks, variation in latency (e.g. the difference between a request for a chunk being a cache hit Vs a cache miss) is likely to affect the throughput perceived by the client and therefore may cause bit rate switch on a cache miss that wouldn't have occurred had the request actually been a cache hit. If there was some way to provide a "hint" to the server/cache as to which chunk the client is likely to request next then a CDN could elect to retrieve that chunk ahead of it actually being requested to keep the response latency (or some other factor) more consistent and avoid additional bit rate switches. [Qin]: Good input, that's one issue we are addressing in the problem statement draft, i.e., Lacking Streaming Monitoring and Feedback Support. I think the chunk hint will be also very useful in case chunks loss or any exception as regarding to sever and network condition happens. Another advantage is with such chunk hints, we may not rely on manifest and playlist to fetch the chunks one by one. The problem is do we have approach to provide such hint to the server/cache? From sunseawq@huawei.com Fri Oct 8 01:15:36 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9B83A6855 for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 01:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[AWL=0.584, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+99WjqKapdG for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 01:15:34 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E1EDD3A6853 for <httpstreaming@ietf.org>; Fri, 8 Oct 2010 01:15:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y00F1FPNFVW@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 16:16:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L9Y00FUBPNFZD@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 16:16:27 +0800 (CST) Received: from w53375 ([10.138.84.79]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L9Y00A41PNE1G@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 08 Oct 2010 16:16:27 +0800 (CST) Date: Fri, 08 Oct 2010 16:16:25 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Oct 2010 08:15:36 -0000 > also a need for video synchronization to start rendering. Synchronization among the viewers you mean? That could be a concern but seriously, since client implementations will differ, network capacities will differ, i.e., pretty much everything will differ for different clients, I don't think there is a solution to this. Better said, I don't think there is a problem. [Qin] I think Synchronization between the server and the client is one issue we may look at. Since the server has buffer for encoding, the client has a buffer for playout, we definitely need one streaming media synchronization mechanism which may help reduce delay. > For pre-recorded video this may be due to distance between synchronization > points and the size of a chunk sent. Those things are all implementation specific IMO, they are not protocol issues. [Qin] I think two synchronizaton points are refering to the server and client rather than two clients as viewers. -acbegen > Roni Even > > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Thursday, October 07, 2010 12:15 AM > > To: Roni Even; David A. Bryan; Qin Wu > > Cc: httpstreaming@ietf.org > > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > > 2. Address the startup issue, we have worked in AVT on fast > > channel/content > > > change and I think this is relevant also in this case. > > > > Are you assuming a multicast environment for http streaming? Ow, the > > startup issue is not an issue in unicast connections. > > > > -acbegen From lars.eggert@nokia.com Fri Oct 8 01:16:04 2010 Return-Path: <lars.eggert@nokia.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242813A6860 for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 01:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoEWRC-nyuU0 for <httpstreaming@core3.amsl.com>; Fri, 8 Oct 2010 01:16:02 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 8EC143A6866 for <httpstreaming@ietf.org>; Fri, 8 Oct 2010 01:16:02 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o988Gf3m018810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Oct 2010 11:16:42 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-157--1019049800; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert <lars.eggert@nokia.com> In-Reply-To: <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> Date: Fri, 8 Oct 2010 11:16:35 +0300 Message-Id: <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> To: Colin Perkins <csp@csperkins.org> X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Fri, 08 Oct 2010 11:16:35 +0300 (EEST) X-Nokia-AV: Clean Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 08 Oct 2010 08:16:04 -0000 --Apple-Mail-157--1019049800 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2010-10-7, at 14:16, Colin Perkins wrote: > There are clearly some issues to consider here. What seems to be > missing from the discussion to me though, is some identification of > the concrete problems. What protocol pieces do we need, but not have? > What protocols are problematic, and need enhancement? Is there > protocol work to do in IETF, or should we be documenting best current > practices for using the existing protocols and/or relying on other > bodies to fill the gaps? > > The draft-wu-http-streaming-optimization-ps is a good start at such an > analysis, but doesn't go deep enough to let us decide what work IETF > should do. +1 The key question really is "what do you think the IETF needs to do?" Lars --Apple-Mail-157--1019049800 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAwODA4 MTYzNVowIwYJKoZIhvcNAQkEMRYEFFel09lyuQkgtNXJx2RPFLbn/JQlMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAD4dB9lQEg+IUpRxT3L4LMORxjDPmwuxcU9W+D+ncZdPLcz/i6C8 kz2yetOS44T1CzZ7ym4bkQblptMwVVI43J8LJLCVz0hSnrp1p9AvGXd5VjEz+egEP5CbAUmLqXBW DFzIZ35/ti3k8u8mGQzZDZtoG1nyaVEwJZxF/C8vNFkuNh92H39+i7M/jUUA1RTPlkIcFBeXKf9B /BShAgr6kpHtbb2lHyzg1oa3Uvk6eFg8ILNvT1qmvPpocCWcf/JNUzMNNXcWPWXHvsXnp+KvlZLT H6P3wi3MVQkMIs10Pbuv55Okips9RC7oCsah0sO62Nhrpj29Hk8bsZgJ+tj0nlIAAAAAAAA= --Apple-Mail-157--1019049800-- From abegen@cisco.com Sat Oct 9 09:43:06 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC7D3A689F for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klazgFq1Nkan for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 09:43:05 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0A73F3A6874 for <httpstreaming@ietf.org>; Sat, 9 Oct 2010 09:43:05 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHM4sEyrR7Hu/2dsb2JhbACiRHGecpwphUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,308,1283731200"; d="scan'208";a="198313911" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2010 16:44:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o99GiCqu007677; Sat, 9 Oct 2010 16:44:12 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Oct 2010 09:44:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Oct 2010 09:43:40 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActmwTgan48Na+ciRYiI95TewO+0dQBD5E6Q References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com><AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com><03f501cb65a1$50699d70$f13cd850$%roni@huawei.com><B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Lars Eggert" <lars.eggert@nokia.com>, "Colin Perkins" <csp@csperkins.org> X-OriginalArrivalTime: 09 Oct 2010 16:44:12.0533 (UTC) FILETIME=[33D0AA50:01CB67D1] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 09 Oct 2010 16:43:06 -0000 > -----Original Message----- > From: httpstreaming-bounces@ietf.org = [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert > Sent: Friday, October 08, 2010 4:17 PM > To: Colin Perkins > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > On 2010-10-7, at 14:16, Colin Perkins wrote: > > There are clearly some issues to consider here. What seems to be > > missing from the discussion to me though, is some identification of > > the concrete problems. What protocol pieces do we need, but not = have? > > What protocols are problematic, and need enhancement? Is there > > protocol work to do in IETF, or should we be documenting best = current > > practices for using the existing protocols and/or relying on other > > bodies to fill the gaps? > > > > The draft-wu-http-streaming-optimization-ps is a good start at such = an > > analysis, but doesn't go deep enough to let us decide what work IETF > > should do. >=20 > +1 >=20 > The key question really is "what do you think the IETF needs to do?" I imagine the only work the IETF should do (if we decide to) is the = transport and HTTP-layer optimization for better streaming performance. -acbegen =20 > Lars From abegen@cisco.com Sat Oct 9 09:45:25 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF233A68C6 for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 09:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3tIbIwJLMxK for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 09:45:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0C72E3A68BD for <httpstreaming@ietf.org>; Sat, 9 Oct 2010 09:45:25 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ85sEyrR7Hu/2dsb2JhbACiRHGefZwqhUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,308,1283731200"; d="scan'208";a="198314226" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 09 Oct 2010 16:46:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o99GkWDR008431; Sat, 9 Oct 2010 16:46:32 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Oct 2010 09:46:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Oct 2010 09:46:14 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> In-Reply-To: <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActmwSEG8epbrh8FQHaQmkhz/JG9hgBECgfg References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Qin Wu" <sunseawq@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> X-OriginalArrivalTime: 09 Oct 2010 16:46:32.0591 (UTC) FILETIME=[874BD1F0:01CB67D1] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 09 Oct 2010 16:45:26 -0000 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, October 08, 2010 4:16 PM > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > > also a need for video synchronization to start rendering. >=20 > Synchronization among the viewers you mean? That could be a concern = but seriously, since client implementations will > differ, network capacities will differ, i.e., pretty much everything = will differ for different clients, I don't think there is a > solution to this. Better said, I don't think there is a problem. >=20 > [Qin] I think Synchronization between the server and the client is one = issue we may look at. Since the server has buffer for > encoding, the client has a buffer for playout, we definitely need one = streaming media synchronization mechanism which may > help reduce delay. Sorry, I don=92t get this. Server or someone else advertises what is = available to the client and client fetches whatever it wants (and is = available). Why is there a need for synchronization here? -acbegen From watsonm@netflix.com Sat Oct 9 16:13:09 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4873A3A6942 for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 16:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2vprWDP2pwj for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 16:13:06 -0700 (PDT) Received: from mx2.netflix.com (mx2.netflix.com [208.75.77.145]) by core3.amsl.com (Postfix) with ESMTP id 2F6DF3A6941 for <httpstreaming@ietf.org>; Sat, 9 Oct 2010 16:13:06 -0700 (PDT) Received: from ExchFE101.netflix.com (exchfe101.netflix.com [10.64.32.101]) by mx2.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o99NDqgR001570; Sat, 9 Oct 2010 16:13:52 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE101.netflix.com ([fe80::6861:6a26:831f:e8c9%14]) with mapi; Sat, 9 Oct 2010 16:13:51 -0700 From: Mark Watson <watsonm@netflix.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com> Date: Sat, 9 Oct 2010 16:13:53 -0700 Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActoB6KTQt8wxSAHQwaUMCQ3smuYnA== Message-ID: <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com><AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com><03f501cb65a1$50699d70$f13cd850$%roni@huawei.com><B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4FFB33049F44454D9AF36194045F1030netflixcom_" MIME-Version: 1.0 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org>, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 09 Oct 2010 23:23:58 -0000 --_000_4FFB33049F44454D9AF36194045F1030netflixcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I would like to add my support to the comments below. Specifically, I think= if the IETF considers work in this area it should focus on the HTTP and TC= P protocols. Any such work may not be specific to HTTP-streaming (i.e. enha= ncements that are at first motivated by HTTP Streaming may have broader app= licability, and this should be carefully considered). In the draft I do not see a clear or correct identification of the problems= . For example in the introduction the following are stated as issues: - Client polling for each new data in chunks using HTTP requests is not efficient to deliver high-quality video content across the Internet MW: Several companies, including my employer, are successfully operating la= rge scale HTTP streaming systems that do efficiently deliver high-quality v= ideo content across the Internet, so reality seems to refute this statement= . - Segmentation capability requires over-utilizing CPU and bandwidth resources, which may not be a desirable and effective way to improve the quality of streaming media delivery MW: It is not clear that segmentation per se is CPU-intensive or has any no= n-negligable effect on bandwidth usage. - Lack of QoS guarantee on the packet switching based Internet , the quality of Internet media streaming may significant degrade due to rising usage MW: An alternative view is that where quality is degraded due to congestion= this is due to lack of bandwidth, rather than a lack of QoS guarantees. Ad= aptive HTTP streaming systems adjust the video quality to the available ban= dwidth in order to avoid rebuffering events. It is the available bandwidth = that needs to be improved to improve quality. - Experience burstiness or other dynamics changes due to bandwidth fluctuations and heterogeneous handover. MW: We have found that adaptive HTTP streaming algorithms are well able to = cope with bandwidth fluctuations. - Impossible to fast-forward through any part of a streaming contents until it is stored on the user's device MW: This is simply not correct, since there are hundreds of examples of dev= ices which support trick-play using HTTP streaming techniques without stori= ng the whole content on the users device. A first step in considering what, if any, work should be done here might be= to contact those organizations which are standardizing the higher layers o= f HTTP streaming systems (e.g. manifest and file formats) and ask whether t= here are deficiencies they see in IETF protocols that could be usefully add= ressed by the IETF. What I think we should avoid in the IETF is duplicating= the work of these other bodies. Best, Mark Watson Netflix Inc. On Oct 10, 2010, at 12:43 AM, Ali C. Begen (abegen) wrote: -----Original Message----- From: httpstreaming-bounces@ietf.org<mailto:httpstreaming-bounces@ietf.org>= [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Friday, October 08, 2010 4:17 PM To: Colin Perkins Cc: httpstreaming@ietf.org<mailto:httpstreaming@ietf.org> Subject: Re: [httpstreaming] Current Status and Our Goal On 2010-10-7, at 14:16, Colin Perkins wrote: There are clearly some issues to consider here. What seems to be missing from the discussion to me though, is some identification of the concrete problems. What protocol pieces do we need, but not have? What protocols are problematic, and need enhancement? Is there protocol work to do in IETF, or should we be documenting best current practices for using the existing protocols and/or relying on other bodies to fill the gaps? The draft-wu-http-streaming-optimization-ps is a good start at such an analysis, but doesn't go deep enough to let us decide what work IETF should do. +1 The key question really is "what do you think the IETF needs to do?" I imagine the only work the IETF should do (if we decide to) is the transpo= rt and HTTP-layer optimization for better streaming performance. -acbegen Lars _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org<mailto:httpstreaming@ietf.org> https://www.ietf.org/mailman/listinfo/httpstreaming --_000_4FFB33049F44454D9AF36194045F1030netflixcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:= space; -webkit-line-break: after-white-space; ">All,<div><br></div><div>I = would like to add my support to the comments below. Specifically, I think i= f the IETF considers work in this area it should focus on the HTTP and TCP = protocols. Any such work may not be specific to HTTP-streaming (i.e. enhanc= ements that are at first motivated by HTTP Streaming may have broader appli= cability, and this should be carefully considered).</div><div><br></div><di= v>In the draft I do not see a clear or correct identification of the proble= ms. For example in the introduction the following are stated as issues:</di= v><div><pre class=3D"newpage"> - Client polling for each new data in chun= ks using HTTP requests is not efficient to deliver high-quality video content across the Internet<br></pre><pre class=3D"newpage"><font class=3D"Apple-style-span= " face=3D"Helvetica">MW: Several companies, including my employer, are succ= essfully operating large scale HTTP streaming systems that do efficiently d= eliver high-quality video content across the Internet, so reality seems to = refute this statement.</font></pre><pre class=3D"newpage"> - Segmentation= capability requires over-utilizing CPU and bandwidth resources, which may not be a desirable and effective way to improve the quality of streaming media delivery</pre><pre class=3D"newpage"><fon= t class=3D"Apple-style-span" face=3D"Helvetica">MW: It is not clear that se= gmentation per se is CPU-intensive or has any non-negligable effect on band= width usage.</font></pre><pre class=3D"newpage"> - Lack of QoS guarantee = on the packet switching based Internet , the quality of Internet media streaming may significant degrade due to rising usage</pre><pre class=3D"newpage"><font class=3D"Apple-style-span= " face=3D"Helvetica">MW: An alternative view is that where quality is degra= ded due to congestion this is due to lack of bandwidth, rather than a lack = of QoS guarantees. Adaptive HTTP streaming systems adjust the video quality= to the available bandwidth in order to avoid rebuffering events. It is the= available bandwidth that needs to be improved to improve quality.</font></= pre><pre class=3D"newpage"> - Experience burstiness or other dynamics cha= nges due to bandwidth fluctuations and heterogeneous handover.</pre><pre class=3D"newpage"><fo= nt class=3D"Apple-style-span" face=3D"Helvetica">MW: We have found that ada= ptive HTTP streaming algorithms are well able to cope with bandwidth fluctu= ations. </font></pre><pre class=3D"newpage"> - Impossible to fast-forward= through any part of a streaming contents until it is stored on the user's device</pre><pre class=3D"newp= age"><span class=3D"Apple-style-span" style=3D"font-family: Helvetica; whit= e-space: normal; ">MW: This is simply not correct, since there are hundreds= of examples of devices which support trick-play using HTTP streaming techn= iques without storing the whole content on the users device.</span></pre><p= re class=3D"newpage"><span class=3D"Apple-style-span" style=3D"font-family:= Helvetica; white-space: normal; ">A first step in considering what, if any= , work should be done here might be to contact those organizations which ar= e standardizing the higher layers of HTTP streaming systems (e.g. manifest = and file formats) and ask whether there are deficiencies they see in IETF p= rotocols that could be usefully addressed by the IETF. What I think we shou= ld avoid in the IETF is duplicating the work of these other bodies.</span><= /pre><pre class=3D"newpage"><span class=3D"Apple-style-span" style=3D"font-= family: Helvetica; white-space: normal; ">Best,</span></pre><pre class=3D"n= ewpage"><span class=3D"Apple-style-span" style=3D"font-family: Helvetica; w= hite-space: normal; "><br></span></pre><pre class=3D"newpage"><span class= =3D"Apple-style-span" style=3D"font-family: Helvetica; white-space: normal;= ">Mark Watson</span></pre><pre class=3D"newpage"><font class=3D"Apple-styl= e-span" face=3D"Helvetica"><span class=3D"Apple-style-span" style=3D"white-= space: normal;">Netflix Inc.</span></font></pre><pre class=3D"newpage"><spa= n class=3D"Apple-style-span" style=3D"font-family: Helvetica; white-space: = normal; "><br></span></pre></div><div><br></div><div><br></div><div><br><di= v><div>On Oct 10, 2010, at 12:43 AM, Ali C. Begen (abegen) wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div><br><br>= <blockquote type=3D"cite">-----Original Message-----<br></blockquote><block= quote type=3D"cite">From: <a href=3D"mailto:httpstreaming-bounces@ietf.org"= >httpstreaming-bounces@ietf.org</a> [mailto:httpstreaming-bounces@ietf.org]= On Behalf Of Lars Eggert<br></blockquote><blockquote type=3D"cite">Sent: F= riday, October 08, 2010 4:17 PM<br></blockquote><blockquote type=3D"cite">T= o: Colin Perkins<br></blockquote><blockquote type=3D"cite">Cc: <a href=3D"m= ailto:httpstreaming@ietf.org">httpstreaming@ietf.org</a><br></blockquote><b= lockquote type=3D"cite">Subject: Re: [httpstreaming] Current Status and Our= Goal<br></blockquote><blockquote type=3D"cite"><br></blockquote><blockquot= e type=3D"cite">On 2010-10-7, at 14:16, Colin Perkins wrote:<br></blockquot= e><blockquote type=3D"cite"><blockquote type=3D"cite">There are clearly som= e issues to consider here. What seems to be<br></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite">missing from the discussi= on to me though, is some identification of<br></blockquote></blockquote><bl= ockquote type=3D"cite"><blockquote type=3D"cite">the concrete problems. Wha= t protocol pieces do we need, but not have?<br></blockquote></blockquote><b= lockquote type=3D"cite"><blockquote type=3D"cite">What protocols are proble= matic, and need enhancement? Is there<br></blockquote></blockquote><blockqu= ote type=3D"cite"><blockquote type=3D"cite">protocol work to do in IETF, or= should we be documenting best current<br></blockquote></blockquote><blockq= uote type=3D"cite"><blockquote type=3D"cite">practices for using the existi= ng protocols and/or relying on other<br></blockquote></blockquote><blockquo= te type=3D"cite"><blockquote type=3D"cite">bodies to fill the gaps?<br></bl= ockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><= br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type=3D"= cite">The draft-wu-http-streaming-optimization-ps is a good start at such a= n<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type= =3D"cite">analysis, but doesn't go deep enough to let us decide what work I= ETF<br></blockquote></blockquote><blockquote type=3D"cite"><blockquote type= =3D"cite">should do.<br></blockquote></blockquote><blockquote type=3D"cite"= ><br></blockquote><blockquote type=3D"cite">+1<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">The key question r= eally is "what do you think the IETF needs to do?"<br></blockquote><br>I im= agine the only work the IETF should do (if we decide to) is the transport a= nd HTTP-layer optimization for better streaming performance.<br><br>-acbege= n<br><br><blockquote type=3D"cite">Lars<br></blockquote>___________________= ____________________________<br>httpstreaming mailing list<br><a href=3D"ma= ilto:httpstreaming@ietf.org">httpstreaming@ietf.org</a><br>https://www.ietf= .org/mailman/listinfo/httpstreaming<br><br></div></blockquote></div><br></d= iv></body></html>= --_000_4FFB33049F44454D9AF36194045F1030netflixcom_-- From yekuiwang@huawei.com Sat Oct 9 16:27:26 2010 Return-Path: <yekuiwang@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5B4E3A6941 for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 16:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTjccXP7u0pg for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 16:27:25 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id D49C53A693E for <httpstreaming@ietf.org>; Sat, 9 Oct 2010 16:27:25 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA10078XQJLS0@usaga03-in.huawei.com> for httpstreaming@ietf.org; Sat, 09 Oct 2010 18:28:33 -0500 (CDT) Received: from W90946 ([58.249.80.208]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA100HDUQJ9N1@usaga03-in.huawei.com> for httpstreaming@ietf.org; Sat, 09 Oct 2010 18:28:33 -0500 (CDT) Date: Sat, 09 Oct 2010 19:28:10 -0400 From: Ye-Kui Wang <yekuiwang@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Lars Eggert' <lars.eggert@nokia.com>, 'Colin Perkins' <csp@csperkins.org> Message-id: <93771AF96E344580A0ECCCFB32324E5D@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActmwTgan48Na+ciRYiI95TewO+0dQBD5E6QAA4gzzA= References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 09 Oct 2010 23:27:26 -0000 > I imagine the only work the IETF should do (if we decide to) > is the transport and HTTP-layer optimization for better > streaming performance. I second, as one who has been heavily involved HTTP streaming standardization in 3GPP, MPEG and OIPF. BR, YK > -----Original Message----- > From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. > Begen (abegen) > Sent: Saturday, October 09, 2010 12:44 PM > To: Lars Eggert; Colin Perkins > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > -----Original Message----- > > From: httpstreaming-bounces@ietf.org > > [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert > > Sent: Friday, October 08, 2010 4:17 PM > > To: Colin Perkins > > Cc: httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > On 2010-10-7, at 14:16, Colin Perkins wrote: > > > There are clearly some issues to consider here. What seems to be > > > missing from the discussion to me though, is some > identification of > > > the concrete problems. What protocol pieces do we need, > but not have? > > > What protocols are problematic, and need enhancement? Is there > > > protocol work to do in IETF, or should we be documenting best > > > current practices for using the existing protocols and/or > relying on > > > other bodies to fill the gaps? > > > > > > The draft-wu-http-streaming-optimization-ps is a good > start at such > > > an analysis, but doesn't go deep enough to let us decide > what work > > > IETF should do. > > > > +1 > > > > The key question really is "what do you think the IETF needs to do?" > > I imagine the only work the IETF should do (if we decide to) > is the transport and HTTP-layer optimization for better > streaming performance. > > -acbegen > > > Lars > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > From abegen@cisco.com Sat Oct 9 17:03:19 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4809C3A68D1 for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 17:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDcPdYGri9a1 for <httpstreaming@core3.amsl.com>; Sat, 9 Oct 2010 17:03:17 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5F1613A67B8 for <httpstreaming@ietf.org>; Sat, 9 Oct 2010 17:03:17 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM+fsEyrR7H+/2dsb2JhbACiQnGgPZtwhUcEhFGIdw X-IronPort-AV: E=Sophos;i="4.57,309,1283731200"; d="scan'208";a="601669877" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2010 00:04:25 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9A04Pdx018288; Sun, 10 Oct 2010 00:04:25 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Oct 2010 17:04:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sat, 9 Oct 2010 17:04:15 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF37C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <93771AF96E344580A0ECCCFB32324E5D@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActmwTgan48Na+ciRYiI95TewO+0dQBD5E6QAA4gzzAAAVAsQA== References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <93771AF96E344580A0ECCCFB32324E5D@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Ye-Kui Wang" <yekuiwang@huawei.com>, "Lars Eggert" <lars.eggert@nokia.com>, "Colin Perkins" <csp@csperkins.org> X-OriginalArrivalTime: 10 Oct 2010 00:04:25.0532 (UTC) FILETIME=[B33077C0:01CB680E] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 00:03:20 -0000 > -----Original Message----- > From: Ye-Kui Wang [mailto:yekuiwang@huawei.com] > Sent: Sunday, October 10, 2010 7:28 AM > To: Ali C. Begen (abegen); 'Lars Eggert'; 'Colin Perkins' > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 >=20 > > I imagine the only work the IETF should do (if we decide to) > > is the transport and HTTP-layer optimization for better > > streaming performance. Actually for one, I don=92t like the word "optimization" myself which is = not very meaningful here. So, I should rather say "any marginal = improvement is welcome". -acbegen =20 > I second, as one who has been heavily involved HTTP streaming > standardization in 3GPP, MPEG and OIPF. >=20 > BR, YK >=20 > > -----Original Message----- > > From: httpstreaming-bounces@ietf.org > > [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. > > Begen (abegen) > > Sent: Saturday, October 09, 2010 12:44 PM > > To: Lars Eggert; Colin Perkins > > Cc: httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > > > > > -----Original Message----- > > > From: httpstreaming-bounces@ietf.org > > > [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert > > > Sent: Friday, October 08, 2010 4:17 PM > > > To: Colin Perkins > > > Cc: httpstreaming@ietf.org > > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > > On 2010-10-7, at 14:16, Colin Perkins wrote: > > > > There are clearly some issues to consider here. What seems to be > > > > missing from the discussion to me though, is some > > identification of > > > > the concrete problems. What protocol pieces do we need, > > but not have? > > > > What protocols are problematic, and need enhancement? Is there > > > > protocol work to do in IETF, or should we be documenting best > > > > current practices for using the existing protocols and/or > > relying on > > > > other bodies to fill the gaps? > > > > > > > > The draft-wu-http-streaming-optimization-ps is a good > > start at such > > > > an analysis, but doesn't go deep enough to let us decide > > what work > > > > IETF should do. > > > > > > +1 > > > > > > The key question really is "what do you think the IETF needs to = do?" > > > > I imagine the only work the IETF should do (if we decide to) > > is the transport and HTTP-layer optimization for better > > streaming performance. > > > > -acbegen > > > > > Lars > > _______________________________________________ > > httpstreaming mailing list > > httpstreaming@ietf.org > > https://www.ietf.org/mailman/listinfo/httpstreaming > > >=20 From wenboz@google.com Sun Oct 10 00:26:12 2010 Return-Path: <wenboz@google.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183013A67D6 for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.977 X-Spam-Level: X-Spam-Status: No, score=-107.977 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0gBRqY2CA05 for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:26:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 0E8EE3A67D3 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:26:10 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id o9A7RIsR011405 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:27:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286695639; bh=FvLlOyGYQKcIf2Qtd7VNc4PI5Is=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GIBMlUq/LamIEEiZO8tnkALLzoXDnOkiWrxLdzCYJPD/G0p+wQva3LO67gsrESVBR ToPtBC6XwmNu6NUiW+SzA== Received: from gxk22 (gxk22.prod.google.com [10.202.11.22]) by hpaq13.eem.corp.google.com with ESMTP id o9A7Qn7Q004684 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:27:17 -0700 Received: by gxk22 with SMTP id 22so908747gxk.18 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mpZACpYUl/Z45IO9k6aoXZxHcGiO0NO+GiY+R/Ghua8=; b=D/O4C7208H+8MYgmmhNhbBqmwZl8KMZLGKCIwUYMeotm8q0pJcsXLHQ1QYg4dtUIlH P2Yuzoy8HiFGzQlcm7BA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ddVegWVl/tsBCE/dieV1Ct0/k3Mkg1U9uVQrHaSiHeHS94aSyla7NS6DezsXQTpcv2 Lojf5NieHK+utIv+Wwlg== MIME-Version: 1.0 Received: by 10.90.82.2 with SMTP id f2mr2428060agb.52.1286695635247; Sun, 10 Oct 2010 00:27:15 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Sun, 10 Oct 2010 00:27:15 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> Date: Sun, 10 Oct 2010 00:27:15 -0700 Message-ID: <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> From: Wenbo Zhu <wenboz@google.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 07:26:12 -0000 On Sat, Oct 9, 2010 at 9:43 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote: > > >> -----Original Message----- >> From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert >> Sent: Friday, October 08, 2010 4:17 PM >> To: Colin Perkins >> Cc: httpstreaming@ietf.org >> Subject: Re: [httpstreaming] Current Status and Our Goal >> >> On 2010-10-7, at 14:16, Colin Perkins wrote: >> > There are clearly some issues to consider here. What seems to be >> > missing from the discussion to me though, is some identification of >> > the concrete problems. What protocol pieces do we need, but not have? >> > What protocols are problematic, and need enhancement? Is there >> > protocol work to do in IETF, or should we be documenting best current >> > practices for using the existing protocols and/or relying on other >> > bodies to fill the gaps? >> > >> > The draft-wu-http-streaming-optimization-ps is a good start at such an >> > analysis, but doesn't go deep enough to let us decide what work IETF >> > should do. >> >> +1 >> >> The key question really is "what do you think the IETF needs to do?" > > I imagine the only work the IETF should do (if we decide to) is the transport and HTTP-layer optimization for better streaming performance. Or more importantly to standardize existing or proposed optimizations for improved interoperability, with which intermediaries will be able to offer direct support for streaming traffic, and different client platforms will also be able to improve end-user experience independently of vendor or media-protocol specific solutions. - Wenbo > > -acbegen > >> Lars > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > From abegen@cisco.com Sun Oct 10 00:31:10 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EC33A67DB for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oam53cS-icBA for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:31:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C88543A67D6 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:31:00 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABsIsUyrR7Ht/2dsb2JhbACiKXGbfptbhUgEhFKIeA X-IronPort-AV: E=Sophos;i="4.57,309,1283731200"; d="scan'208";a="601758664" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 10 Oct 2010 07:32:09 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9A7W9X0026449; Sun, 10 Oct 2010 07:32:09 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Oct 2010 00:32:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Oct 2010 00:32:02 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActoTJP0iXuYdOESQ2KRq5sZbp1NRQAAF1ZA References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com><AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com><03f501cb65a1$50699d70$f13cd850$%roni@huawei.com><B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org><9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com><04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Wenbo Zhu" <wenboz@google.com> X-OriginalArrivalTime: 10 Oct 2010 07:32:09.0566 (UTC) FILETIME=[3F66BFE0:01CB684D] Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 07:31:10 -0000 > -----Original Message----- > From: Wenbo Zhu [mailto:wenboz@google.com] > Sent: Sunday, October 10, 2010 3:27 PM > To: Ali C. Begen (abegen) > Cc: Lars Eggert; Colin Perkins; httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > On Sat, Oct 9, 2010 at 9:43 AM, Ali C. Begen (abegen) = <abegen@cisco.com> wrote: > > > > > >> -----Original Message----- > >> From: httpstreaming-bounces@ietf.org = [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert > >> Sent: Friday, October 08, 2010 4:17 PM > >> To: Colin Perkins > >> Cc: httpstreaming@ietf.org > >> Subject: Re: [httpstreaming] Current Status and Our Goal > >> > >> On 2010-10-7, at 14:16, Colin Perkins wrote: > >> > There are clearly some issues to consider here. What seems to be > >> > missing from the discussion to me though, is some identification = of > >> > the concrete problems. What protocol pieces do we need, but not = have? > >> > What protocols are problematic, and need enhancement? Is there > >> > protocol work to do in IETF, or should we be documenting best = current > >> > practices for using the existing protocols and/or relying on = other > >> > bodies to fill the gaps? > >> > > >> > The draft-wu-http-streaming-optimization-ps is a good start at = such an > >> > analysis, but doesn't go deep enough to let us decide what work = IETF > >> > should do. > >> > >> +1 > >> > >> The key question really is "what do you think the IETF needs to = do?" > > > > I imagine the only work the IETF should do (if we decide to) is the = transport and HTTP-layer optimization for better > streaming performance. > Or more importantly to standardize existing or proposed optimizations > for improved interoperability, with which intermediaries will be able Wanna give a specific example for "intermediaries"? I think you are = referring to something besides the http caches. > to offer direct support for streaming traffic, and different client > platforms will also be able to improve end-user experience > independently of vendor or media-protocol specific solutions. Sure but is not that all client implementation, which is mostly left for = product differentiation? -acbegen =20 > - Wenbo >=20 >=20 > > > > -acbegen > > > >> Lars > > _______________________________________________ > > httpstreaming mailing list > > httpstreaming@ietf.org > > https://www.ietf.org/mailman/listinfo/httpstreaming > > From wenboz@google.com Sun Oct 10 00:37:57 2010 Return-Path: <wenboz@google.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92693A67D9 for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.31 X-Spam-Level: X-Spam-Status: No, score=-107.31 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mWwAWR7DYpk for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:37:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 83BAF3A67D6 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:37:56 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id o9A7d5p0021617 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:39:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286696345; bh=eRTKPl6vPQt+QupeMc7p0Lfj1pk=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ReCDOc12eBF8MYtv3uJkUXDi3FvXm2Bp047ygrGz/aGpNOEf6sIsOqPn/xl3gVZTr IG0I3c04f26VCiCL/J7tw== Received: from gxk19 (gxk19.prod.google.com [10.202.11.19]) by kpbe19.cbf.corp.google.com with ESMTP id o9A7d3fg032058 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:39:04 -0700 Received: by gxk19 with SMTP id 19so215972gxk.36 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Rvs9naadIB3+KgHNl9bqhYlWJiNOnnrq4zIbpQXm0/k=; b=w8wamUk8ap3bzvA15sjXCnxdRUNydXRhGkbqrYFOzYxHwJOu21h2An1XIRP0fD++aL mtxJGm2hHhLYLgoYe7fQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gar+xB3w64/7jYb/h8kwv+EPqtrcobJb1s1OvSstzkUBC6V+x6i0ne38MWYsoyBKh7 vhBtHQLBdHJlUadigKnw== MIME-Version: 1.0 Received: by 10.90.83.13 with SMTP id g13mr2429263agb.34.1286696340984; Sun, 10 Oct 2010 00:39:00 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Sun, 10 Oct 2010 00:39:00 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A0@xmb-sjc-215.amer.cisco.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A0@xmb-sjc-215.amer.cisco.com> Date: Sun, 10 Oct 2010 00:39:00 -0700 Message-ID: <AANLkTim1dPg-TtQ6Jm0y+pKdvvLbU1Xq4Q4d7w+aMeG9@mail.gmail.com> From: Wenbo Zhu <wenboz@google.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 07:37:58 -0000 On Sun, Oct 10, 2010 at 12:32 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote: > > >> -----Original Message----- >> From: Wenbo Zhu [mailto:wenboz@google.com] >> Sent: Sunday, October 10, 2010 3:27 PM >> To: Ali C. Begen (abegen) >> Cc: Lars Eggert; Colin Perkins; httpstreaming@ietf.org >> Subject: Re: [httpstreaming] Current Status and Our Goal >> >> On Sat, Oct 9, 2010 at 9:43 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote: >> > >> > >> >> -----Original Message----- >> >> From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert >> >> Sent: Friday, October 08, 2010 4:17 PM >> >> To: Colin Perkins >> >> Cc: httpstreaming@ietf.org >> >> Subject: Re: [httpstreaming] Current Status and Our Goal >> >> >> >> On 2010-10-7, at 14:16, Colin Perkins wrote: >> >> > There are clearly some issues to consider here. What seems to be >> >> > missing from the discussion to me though, is some identification of >> >> > the concrete problems. What protocol pieces do we need, but not have? >> >> > What protocols are problematic, and need enhancement? Is there >> >> > protocol work to do in IETF, or should we be documenting best current >> >> > practices for using the existing protocols and/or relying on other >> >> > bodies to fill the gaps? >> >> > >> >> > The draft-wu-http-streaming-optimization-ps is a good start at such an >> >> > analysis, but doesn't go deep enough to let us decide what work IETF >> >> > should do. >> >> >> >> +1 >> >> >> >> The key question really is "what do you think the IETF needs to do?" >> > >> > I imagine the only work the IETF should do (if we decide to) is the transport and HTTP-layer optimization for better >> streaming performance. >> Or more importantly to standardize existing or proposed optimizations >> for improved interoperability, with which intermediaries will be able > > Wanna give a specific example for "intermediaries"? I think you are referring to something besides the http caches. proxies. > >> to offer direct support for streaming traffic, and different client >> platforms will also be able to improve end-user experience >> independently of vendor or media-protocol specific solutions. > > Sure but is not that all client implementation, which is mostly left for product differentiation? I am interested to find out whether existing implementations (that have successfully deployed HTTP-based streaming over internet) expose streaming resource via open protocols or API's? - Wenbo > > -acbegen > >> - Wenbo >> >> >> > >> > -acbegen >> > >> >> Lars >> > _______________________________________________ >> > httpstreaming mailing list >> > httpstreaming@ietf.org >> > https://www.ietf.org/mailman/listinfo/httpstreaming >> > > From abegen@cisco.com Sun Oct 10 00:45:00 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B955E3A67D6 for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaIi3Ob1BKTi for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 00:44:59 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AE96D3A6452 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 00:44:59 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOQLsUytJV2b/2dsb2JhbACiKXGbdZtfhUgEhFKIeA X-IronPort-AV: E=Sophos;i="4.57,309,1283731200"; d="scan'208";a="168803763" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 10 Oct 2010 07:46:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9A7k7Sr026621; Sun, 10 Oct 2010 07:46:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Oct 2010 00:46:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Oct 2010 00:45:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A1@xmb-sjc-215.amer.cisco.com> In-Reply-To: <AANLkTim1dPg-TtQ6Jm0y+pKdvvLbU1Xq4Q4d7w+aMeG9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActoTje8GDcc7Y7rSD231p1u3Gy75gAAEWZA References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com><AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com><03f501cb65a1$50699d70$f13cd850$%roni@huawei.com><B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org><9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com><04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com><AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com><04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A0@xmb-sjc-215.amer.cisco.com> <AANLkTim1dPg-TtQ6Jm0y+pKdvvLbU1Xq4Q4d7w+aMeG9@mail.gmail.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Wenbo Zhu" <wenboz@google.com> X-OriginalArrivalTime: 10 Oct 2010 07:46:07.0571 (UTC) FILETIME=[32E42A30:01CB684F] Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 07:45:00 -0000 > > Wanna give a specific example for "intermediaries"? I think you are = referring to something besides the http caches. > proxies. What should a proxy support for streaming? =20 > > > >> to offer direct support for streaming traffic, and different client > >> platforms will also be able to improve end-user experience > >> independently of vendor or media-protocol specific solutions. > > > > Sure but is not that all client implementation, which is mostly left = for product differentiation? > I am interested to find out whether existing implementations (that > have successfully deployed HTTP-based streaming over internet) expose > streaming resource via open protocols or API's? There are source codes floating around (with different licenses of = course). Have you looked at OSMF and OVP? http://openvideoplayer.sourceforge.net/ http://opensource.adobe.com/wiki/display/osmf/Open+Source+Media+Framework= =20 -acbegen From wenboz@google.com Sun Oct 10 02:16:20 2010 Return-Path: <wenboz@google.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAAE3A67A6 for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 02:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.977 X-Spam-Level: X-Spam-Status: No, score=-106.977 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Grt23oMpDNnS for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 02:16:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 6D0C43A672F for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 02:16:06 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o9A9HEc8004112 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 02:17:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286702234; bh=GzJfVVAvUFykEw/p9YeLQq6+Qmg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=n2DnJStxCVJoi91IyhnlXyRMQfw+E5dOzI4WxH5S98euzSW+nF0xHa23/DV4i/a6C MBU8Jg9JqY525TayPR+Vg== Received: from gwb10 (gwb10.prod.google.com [10.200.2.10]) by kpbe12.cbf.corp.google.com with ESMTP id o9A9HDhM014239 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 02:17:13 -0700 Received: by gwb10 with SMTP id 10so18924gwb.14 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 02:17:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=WuuSaaMWLSOE06hosb479H9lSWo+tVo1P/ZBz1u36kI=; b=BjaUWvmLOI+r6+taf+F0gJqolK+4SQxetbjZX33bn3dDRZJgAm3kSB6RToKRNN5wnd fMSRNrJKREFf8EkVTLyw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Exc6ae+bAT4MdbDHR2YdJ70a1W15dwOcvD37GzhQ/9VaspquxfeNMcdDxFVgGWEOFB nyVWx0CL76kLnUzrGG7g== MIME-Version: 1.0 Received: by 10.90.36.6 with SMTP id j6mr2422952agj.28.1286702232787; Sun, 10 Oct 2010 02:17:12 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Sun, 10 Oct 2010 02:17:12 -0700 (PDT) In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A1@xmb-sjc-215.amer.cisco.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A0@xmb-sjc-215.amer.cisco.com> <AANLkTim1dPg-TtQ6Jm0y+pKdvvLbU1Xq4Q4d7w+aMeG9@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A1@xmb-sjc-215.amer.cisco.com> Date: Sun, 10 Oct 2010 02:17:12 -0700 Message-ID: <AANLkTi=bPEOQku1bLLLEfOKb81dM3PWFeSmuURANP5sU@mail.gmail.com> From: Wenbo Zhu <wenboz@google.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 09:16:20 -0000 On Sun, Oct 10, 2010 at 12:45 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote: >> > Wanna give a specific example for "intermediaries"? I think you are referring to something besides the http caches. >> proxies. > > What should a proxy support for streaming? Proxies don't know anything about streaming, and they only understand HTTP. If the goal is to optimize the transport, then clearly defined protocol semantics would be necessary for proxies to distinguish streaming traffic from regular HTTP traffic. > >> > >> >> to offer direct support for streaming traffic, and different client >> >> platforms will also be able to improve end-user experience >> >> independently of vendor or media-protocol specific solutions. >> > >> > Sure but is not that all client implementation, which is mostly left for product differentiation? >> I am interested to find out whether existing implementations (that >> have successfully deployed HTTP-based streaming over internet) expose >> streaming resource via open protocols or API's? > > There are source codes floating around (with different licenses of course). Have you looked at OSMF and OVP? > http://openvideoplayer.sourceforge.net/ > http://opensource.adobe.com/wiki/display/osmf/Open+Source+Media+Framework Thanks for the info. - Wenbo > > -acbegen > > From watsonm@netflix.com Sun Oct 10 02:37:25 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4DCB3A67A8 for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 02:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toCnxXMgxuot for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 02:37:23 -0700 (PDT) Received: from mx2.netflix.com (mx2.netflix.com [208.75.77.145]) by core3.amsl.com (Postfix) with ESMTP id 3889A3A67A6 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 02:37:23 -0700 (PDT) Received: from ExchFE102.netflix.com (exchfe102.netflix.com [10.64.32.102]) by mx2.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o9A9c3v5012103; Sun, 10 Oct 2010 02:38:03 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE102.netflix.com ([fe80::416e:22e0:ebdf:14b0%14]) with mapi; Sun, 10 Oct 2010 02:38:02 -0700 From: Mark Watson <watsonm@netflix.com> To: Wenbo Zhu <wenboz@google.com> Date: Sun, 10 Oct 2010 02:38:00 -0700 Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActoXtSrlSdaGnzWTHOGXpIMITVk8w== Message-ID: <E7071E49-4ED8-472A-87D7-B9BB2D8226E2@netflix.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A0@xmb-sjc-215.amer.cisco.com> <AANLkTim1dPg-TtQ6Jm0y+pKdvvLbU1Xq4Q4d7w+aMeG9@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A1@xmb-sjc-215.amer.cisco.com> <AANLkTi=bPEOQku1bLLLEfOKb81dM3PWFeSmuURANP5sU@mail.gmail.com> In-Reply-To: <AANLkTi=bPEOQku1bLLLEfOKb81dM3PWFeSmuURANP5sU@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org>, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 09:37:26 -0000 On Oct 10, 2010, at 5:17 PM, Wenbo Zhu wrote: > On Sun, Oct 10, 2010 at 12:45 AM, Ali C. Begen (abegen) > <abegen@cisco.com> wrote: >>>> Wanna give a specific example for "intermediaries"? I think you are re= ferring to something besides the http caches. >>> proxies. >>=20 >> What should a proxy support for streaming? > Proxies don't know anything about streaming, and they only understand > HTTP. If the goal is to optimize the transport, then clearly defined > protocol semantics would be necessary for proxies to distinguish > streaming traffic from regular HTTP traffic. One of the great advantages of HTTP streaming as a technique is that the in= frastructure is exactly common with that of the web. Requiring proxies to d= istinguish between "streaming" and "regular" traffic would break that. Instead, if there are different behaviors which are considered advantageous= for streaming, then these should be considered as general-purpose HTTP enh= ancements. >=20 >>=20 >>>>=20 >>>>> to offer direct support for streaming traffic, and different client >>>>> platforms will also be able to improve end-user experience >>>>> independently of vendor or media-protocol specific solutions. >>>>=20 >>>> Sure but is not that all client implementation, which is mostly left f= or product differentiation? >>> I am interested to find out whether existing implementations (that >>> have successfully deployed HTTP-based streaming over internet) expose >>> streaming resource via open protocols or API's? >>=20 >> There are source codes floating around (with different licenses of cours= e). Have you looked at OSMF and OVP? >> http://openvideoplayer.sourceforge.net/ >> http://opensource.adobe.com/wiki/display/osmf/Open+Source+Media+Framewor= k > Thanks for the info. >=20 > - Wenbo >=20 >>=20 >> -acbegen >>=20 >>=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From abegen@cisco.com Sun Oct 10 03:08:00 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA3F3A67A8 for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 03:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.558 X-Spam-Level: X-Spam-Status: No, score=-10.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGHnfXsAOMii for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 03:07:59 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id A67C03A67A6 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 03:07:59 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGAF8tsUyrR7Ht/2dsb2JhbACULo17cZwUm16FSASEUoh4 X-IronPort-AV: E=Sophos;i="4.57,309,1283731200"; d="scan'208";a="198444639" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 10 Oct 2010 10:09:08 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9AA981D022781; Sun, 10 Oct 2010 10:09:08 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 10 Oct 2010 03:09:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 10 Oct 2010 03:09:06 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B8AA1B6@xmb-sjc-215.amer.cisco.com> In-Reply-To: <AANLkTi=bPEOQku1bLLLEfOKb81dM3PWFeSmuURANP5sU@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActoW/5eVCCpdWQORpSYHdqRytvleQABy3d+ From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: <wenboz@google.com> X-OriginalArrivalTime: 10 Oct 2010 10:09:08.0003 (UTC) FILETIME=[2D3A2F30:01CB6863] Cc: httpstreaming@ietf.org, csp@csperkins.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 10 Oct 2010 10:08:01 -0000 But then that is not a proxy anymore. You probably do not wanna replace = all those proxies or introduce new ones with heavier tasks. =20 -acbegen ----- Original Message ----- From: Wenbo Zhu [mailto:wenboz@google.com] Sent: Sunday, October 10, 2010 02:17 AM To: Ali C. Begen (abegen) Cc: Lars Eggert <lars.eggert@nokia.com>; Colin Perkins = <csp@csperkins.org>; httpstreaming@ietf.org <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Current Status and Our Goal On Sun, Oct 10, 2010 at 12:45 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote: >> > Wanna give a specific example for "intermediaries"? I think you are = referring to something besides the http caches. >> proxies. > > What should a proxy support for streaming? Proxies don't know anything about streaming, and they only understand HTTP. If the goal is to optimize the transport, then clearly defined protocol semantics would be necessary for proxies to distinguish streaming traffic from regular HTTP traffic. > >> > >> >> to offer direct support for streaming traffic, and different = client >> >> platforms will also be able to improve end-user experience >> >> independently of vendor or media-protocol specific solutions. >> > >> > Sure but is not that all client implementation, which is mostly = left for product differentiation? >> I am interested to find out whether existing implementations (that >> have successfully deployed HTTP-based streaming over internet) expose >> streaming resource via open protocols or API's? > > There are source codes floating around (with different licenses of = course). Have you looked at OSMF and OVP? > http://openvideoplayer.sourceforge.net/ > = http://opensource.adobe.com/wiki/display/osmf/Open+Source+Media+Framework= Thanks for the info. - Wenbo > > -acbegen > > From wenboz@google.com Sun Oct 10 20:58:46 2010 Return-Path: <wenboz@google.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EFA53A68BD for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 20:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.777 X-Spam-Level: X-Spam-Status: No, score=-106.777 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnAU0zKhkpjy for <httpstreaming@core3.amsl.com>; Sun, 10 Oct 2010 20:58:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DAB933A68C7 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 20:58:40 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id o9B3xpl8004905 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 20:59:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1286769591; bh=m7+sEa3gSUvykqTFVHvQE8F9v40=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FAN18zXr4sug93mszK2Uovei4wmhlyUmeZ3Vc7n9asXG6qym0LtAW+PZBMpVfBXR9 X1lKK+0Cn35cklpCILTLg== Received: from gxk10 (gxk10.prod.google.com [10.202.11.10]) by wpaz17.hot.corp.google.com with ESMTP id o9B3xoH0018797 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 20:59:50 -0700 Received: by gxk10 with SMTP id 10so633989gxk.12 for <httpstreaming@ietf.org>; Sun, 10 Oct 2010 20:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VCuQotEBqS5opiDzyibUsTp87TFBYe8mK1YBdUj4U1I=; b=rfoHUetzPnvcwpXcT4vlq8hdPnVlSntdrU0upltSRTn/v1B18cfvPl0uPLQpTv9Z+j IAgOnSwCTQt8Vp0xebYA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RynS1r9gf68zdaVzTh/ziUr7Dkwdck/1eL96Qg9wTT14xwSZi1bx/LJaPnKmoTGpil Pq5rCXcTEBEvHF8M5AhQ== MIME-Version: 1.0 Received: by 10.90.103.5 with SMTP id a5mr2960558agc.97.1286769588143; Sun, 10 Oct 2010 20:59:48 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Sun, 10 Oct 2010 20:59:48 -0700 (PDT) In-Reply-To: <E7071E49-4ED8-472A-87D7-B9BB2D8226E2@netflix.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A0@xmb-sjc-215.amer.cisco.com> <AANLkTim1dPg-TtQ6Jm0y+pKdvvLbU1Xq4Q4d7w+aMeG9@mail.gmail.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF3A1@xmb-sjc-215.amer.cisco.com> <AANLkTi=bPEOQku1bLLLEfOKb81dM3PWFeSmuURANP5sU@mail.gmail.com> <E7071E49-4ED8-472A-87D7-B9BB2D8226E2@netflix.com> Date: Sun, 10 Oct 2010 20:59:48 -0700 Message-ID: <AANLkTi=Rnq0cnOOcVQXyeDdKBKvAoApeZidVjQT1=yPU@mail.gmail.com> From: Wenbo Zhu <wenboz@google.com> To: Mark Watson <watsonm@netflix.com> Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org>, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Oct 2010 03:58:46 -0000 On Sun, Oct 10, 2010 at 2:38 AM, Mark Watson <watsonm@netflix.com> wrote: > > On Oct 10, 2010, at 5:17 PM, Wenbo Zhu wrote: > >> On Sun, Oct 10, 2010 at 12:45 AM, Ali C. Begen (abegen) >> <abegen@cisco.com> wrote: >>>>> Wanna give a specific example for "intermediaries"? I think you are referring to something besides the http caches. >>>> proxies. >>> >>> What should a proxy support for streaming? >> Proxies don't know anything about streaming, and they only understand >> HTTP. If the goal is to optimize the transport, then clearly defined >> protocol semantics would be necessary for proxies to distinguish >> streaming traffic from regular HTTP traffic. > > One of the great advantages of HTTP streaming as a technique is that the infrastructure is exactly common with that of the web. Requiring proxies to distinguish between "streaming" and "regular" traffic would break that. Agreed. I could have worded this differently. > > Instead, if there are different behaviors which are considered advantageous for streaming, then these should be considered as general-purpose HTTP enhancements. There is no need to enhance HTTP! It's about the ability to advise streaming capabilities so that proxies that do choose to understand streaming will be able to optimize and honor the streaming behaviors that are specified on top of HTTP. > >> >>> >>>>> >>>>>> to offer direct support for streaming traffic, and different client >>>>>> platforms will also be able to improve end-user experience >>>>>> independently of vendor or media-protocol specific solutions. >>>>> >>>>> Sure but is not that all client implementation, which is mostly left for product differentiation? >>>> I am interested to find out whether existing implementations (that >>>> have successfully deployed HTTP-based streaming over internet) expose >>>> streaming resource via open protocols or API's? >>> >>> There are source codes floating around (with different licenses of course). Have you looked at OSMF and OVP? >>> http://openvideoplayer.sourceforge.net/ >>> http://opensource.adobe.com/wiki/display/osmf/Open+Source+Media+Framework >> Thanks for the info. >> >> - Wenbo >> >>> >>> -acbegen >>> >>> >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >> > > From lars.eggert@nokia.com Mon Oct 11 00:18:48 2010 Return-Path: <lars.eggert@nokia.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33E483A692B for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 00:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.184 X-Spam-Level: X-Spam-Status: No, score=-103.184 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZkyDDRfQZqy for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 00:18:47 -0700 (PDT) Received: from mgw-sa02.nokia.com (mgw-sa02.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 04F5A3A6903 for <httpstreaming@ietf.org>; Mon, 11 Oct 2010 00:18:46 -0700 (PDT) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9B7JTc5023518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Oct 2010 10:19:29 +0300 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.3 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-10--763282776; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert <lars.eggert@nokia.com> In-Reply-To: <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> Date: Mon, 11 Oct 2010 10:19:22 +0300 Message-Id: <FFD5556C-57B1-4632-AB00-AC43B6A1B2C0@nokia.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <AANLkTimc=72t59x-N+xDzL+AYc_g8Noa0=H8cHYZsrFs@mail.gmail.com> To: Wenbo Zhu <wenboz@google.com> X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Mon, 11 Oct 2010 10:19:23 +0300 (EEST) X-Nokia-AV: Clean Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org>, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Oct 2010 07:18:48 -0000 --Apple-Mail-10--763282776 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2010-10-10, at 10:27, Wenbo Zhu wrote: > On Sat, Oct 9, 2010 at 9:43 AM, Ali C. Begen (abegen) = <abegen@cisco.com> wrote: >>>=20 >>> The key question really is "what do you think the IETF needs to do?" >>=20 >> I imagine the only work the IETF should do (if we decide to) is the = transport and HTTP-layer optimization for better streaming performance. >=20 > Or more importantly to standardize existing or proposed optimizations > for improved interoperability, with which intermediaries will be able > to offer direct support for streaming traffic, and different client > platforms will also be able to improve end-user experience > independently of vendor or media-protocol specific solutions. so this discussion goes into the right direction. For a chartering = discussion, however, we'd want to see arguments for which specific = protocols the IETF (rather than, say, the W3C) should extend in which = specific way, to address which specific deficiencies. (Then we can = discuss whether the complexity is worth the improvement.) Lars= --Apple-Mail-10--763282776 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQM/3DDmRp5mxHvrbX tRvSsDANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTA5MTAxNDAwMDAwMFoXDTEwMTAxNDIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC0xhcnMgRWdn ZXJ0MSQwIgYJKoZIhvcNAQkBFhVsYXJzLmVnZ2VydEBub2tpYS5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQCrTp9sa04QO3gKan1sQGFAZ91BKjFdECaw29ZXHYOZSFW7JC/oyuAO x7pucJp9qDLYlv60I8zLJ1eocDn3bsjBWwAS65GGVT9NLiblzCd5DeWTkn9UD7OMvLL+Z1Z17sE0 jlmluQSCLjv0P7d6ZCpwVD2hWvuZu37fIQresIEYQLbZHXogwoCMhqwo8k8/WuwDbNcB9RiLq3JW FRjZILMmf5qFdExz1AZyG3OdFXe1F0vcxfHhbrGU5cVklV9XI3TfxVZciFNqnTuWsaHFxU0ZrwI0 njVtpLko1TW1vC5qS2ZIpWq7iDkIke+XL4IYTHlOdH7sM502qEE8JqadXjuTAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAJraU8e1Ss8a Uj33lweT8ibOcmNLTNn2pnSi7p5BwNCFtrLNp9AdhcGYJfEQMOlanxc7dpQ7OWUbpub4jAYKyP47 hPQayKMJ73KcKmiN4Czj9g/uCTRwW3kiyhTo22Yl2MWGTM7WI39xTEQo4DOGs9EK6Ldb9zZU4oRl ZbaD1G/Lo33LYmuI8MfCLzTBtmT5MybyEnK17457+8bMLXoSFJfFGk5LPCn38SWdiAG/YH2A4had 3wvpd9Mpx38fxw/RZqlifRSTT8zlOwkq/u/+il9D4o2ruwMEMC1ZwPN3/w/u+QCw4o78wm24BOwU KyA6H4H1r9BoUZ1To1zXxwvuI+sxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9KwMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAxMTA3 MTkyMlowIwYJKoZIhvcNAQkEMRYEFB/qV7sBiKe5vrCqQCqQBfXpQyxEMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEDP9ww5kaeZsR76217Ub0rAwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAz/cMOZGnmbEe+tte1G9Kw MA0GCSqGSIb3DQEBAQUABIIBAECQRocEPOGxwvaaE+46+dmF3jc1uoXSDRs3FjLqXo0Idjeaag/l LRyHtd7RvdqZDtp/cFJxxln9Wr8ZUv37HSZSC5pgshVDZDNPEi0SJipZP4bNyVJOan+Y7f7WWAdn x6v52oiM+Zy+JWkRvHv1Dp31DldCx9c2JewGpHr6dWqM1d5EIUemcUePWHjEXM2XFzMVoCFNntRR qjmfTD0sUD2eKYER1uBog2oXscxPR3bGVb7rUeLmAGtgQWH2gbO3V5qDcIwqYm0E5MBZqNQ3Jof3 6gzq0rPRmc5JzRzyipyBf+plFkwR0RdHQDNFxMdDgzVxX7BOcxUQT83P/ahooXcAAAAAAAA= --Apple-Mail-10--763282776-- From sunseawq@huawei.com Mon Oct 11 01:55:43 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 873653A6911 for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 01:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.929 X-Spam-Level: X-Spam-Status: No, score=0.929 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WaeOkUXrJsZ for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 01:55:42 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 131F93A67C2 for <httpstreaming@ietf.org>; Mon, 11 Oct 2010 01:55:42 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA4005LKBII06@szxga02-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 16:56:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA4000DGBIIPH@szxga02-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 16:56:42 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA400A36BIIBP@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 16:56:42 +0800 (CST) Date: Mon, 11 Oct 2010 16:56:41 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Ye-Kui Wang <yekuiwang@huawei.com>, Lars Eggert <lars.eggert@nokia.com>, Colin Perkins <csp@csperkins.org> Message-id: <015e01cb6922$39326680$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <93771AF96E344580A0ECCCFB32324E5D@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF37C@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Oct 2010 08:55:43 -0000 SG93IGFib3V0ICB3ZSBzYXk6DQpUbyBwcm92aWRlIGJldHRlciB0cmFuc3BvcnQgdG8gc2F0aXNm eSByZWFsIHRpbWUgc3RyZWFtaW5nIHJlcXVpcmVtZW50cy4NCi0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0gDQpGcm9tOiAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNpc2NvLmNv bT4NClRvOiAiWWUtS3VpIFdhbmciIDx5ZWt1aXdhbmdAaHVhd2VpLmNvbT47ICJMYXJzIEVnZ2Vy dCIgPGxhcnMuZWdnZXJ0QG5va2lhLmNvbT47ICJDb2xpbiBQZXJraW5zIiA8Y3NwQGNzcGVya2lu cy5vcmc+DQpDYzogPGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+DQpTZW50OiBTdW5kYXksIE9jdG9i ZXIgMTAsIDIwMTAgODowNCBBTQ0KU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50 IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBZZS1LdWkgV2FuZyBbbWFpbHRvOnlla3Vpd2FuZ0BodWF3ZWkuY29tXQ0KPiBT ZW50OiBTdW5kYXksIE9jdG9iZXIgMTAsIDIwMTAgNzoyOCBBTQ0KPiBUbzogQWxpIEMuIEJlZ2Vu IChhYmVnZW4pOyAnTGFycyBFZ2dlcnQnOyAnQ29saW4gUGVya2lucycNCj4gQ2M6IGh0dHBzdHJl YW1pbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0 YXR1cyBhbmQgT3VyIEdvYWwNCj4gDQo+IA0KPiA+IEkgaW1hZ2luZSB0aGUgb25seSB3b3JrIHRo ZSBJRVRGIHNob3VsZCBkbyAoaWYgd2UgZGVjaWRlIHRvKQ0KPiA+IGlzIHRoZSB0cmFuc3BvcnQg YW5kIEhUVFAtbGF5ZXIgb3B0aW1pemF0aW9uIGZvciBiZXR0ZXINCj4gPiBzdHJlYW1pbmcgcGVy Zm9ybWFuY2UuDQoNCkFjdHVhbGx5IGZvciBvbmUsIEkgZG9uknQgbGlrZSB0aGUgd29yZCAib3B0 aW1pemF0aW9uIiBteXNlbGYgd2hpY2ggaXMgbm90IHZlcnkgbWVhbmluZ2Z1bCBoZXJlLiBTbywg SSBzaG91bGQgcmF0aGVyIHNheSAiYW55IG1hcmdpbmFsIGltcHJvdmVtZW50IGlzIHdlbGNvbWUi Lg0KDQotYWNiZWdlbg0KIA0KPiBJIHNlY29uZCwgYXMgb25lIHdobyBoYXMgYmVlbiBoZWF2aWx5 IGludm9sdmVkIEhUVFAgc3RyZWFtaW5nDQo+IHN0YW5kYXJkaXphdGlvbiBpbiAzR1BQLCBNUEVH IGFuZCBPSVBGLg0KPiANCj4gQlIsIFlLDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gRnJvbTogaHR0cHN0cmVhbWluZy1ib3VuY2VzQGlldGYub3JnDQo+ID4gW21haWx0 bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGkgQy4NCj4g PiBCZWdlbiAoYWJlZ2VuKQ0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDA5LCAyMDEwIDEy OjQ0IFBNDQo+ID4gVG86IExhcnMgRWdnZXJ0OyBDb2xpbiBQZXJraW5zDQo+ID4gQ2M6IGh0dHBz dHJlYW1pbmdAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1cnJl bnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IGh0dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9y Zw0KPiA+ID4gW21haWx0bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBMYXJzIEVnZ2VydA0KPiA+ID4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDA4LCAyMDEwIDQ6 MTcgUE0NCj4gPiA+IFRvOiBDb2xpbiBQZXJraW5zDQo+ID4gPiBDYzogaHR0cHN0cmVhbWluZ0Bp ZXRmLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1 cyBhbmQgT3VyIEdvYWwNCj4gPiA+DQo+ID4gPiBPbiAyMDEwLTEwLTcsIGF0IDE0OjE2LCBDb2xp biBQZXJraW5zIHdyb3RlOg0KPiA+ID4gPiBUaGVyZSBhcmUgY2xlYXJseSBzb21lIGlzc3VlcyB0 byBjb25zaWRlciBoZXJlLiBXaGF0IHNlZW1zIHRvIGJlDQo+ID4gPiA+IG1pc3NpbmcgZnJvbSB0 aGUgZGlzY3Vzc2lvbiB0byBtZSB0aG91Z2gsIGlzIHNvbWUNCj4gPiBpZGVudGlmaWNhdGlvbiBv Zg0KPiA+ID4gPiB0aGUgY29uY3JldGUgcHJvYmxlbXMuIFdoYXQgcHJvdG9jb2wgcGllY2VzIGRv IHdlIG5lZWQsDQo+ID4gYnV0IG5vdCBoYXZlPw0KPiA+ID4gPiBXaGF0IHByb3RvY29scyBhcmUg cHJvYmxlbWF0aWMsIGFuZCBuZWVkIGVuaGFuY2VtZW50PyBJcyB0aGVyZQ0KPiA+ID4gPiBwcm90 b2NvbCB3b3JrIHRvIGRvIGluIElFVEYsIG9yIHNob3VsZCB3ZSBiZSBkb2N1bWVudGluZyBiZXN0 DQo+ID4gPiA+IGN1cnJlbnQgcHJhY3RpY2VzIGZvciB1c2luZyB0aGUgZXhpc3RpbmcgcHJvdG9j b2xzIGFuZC9vcg0KPiA+IHJlbHlpbmcgb24NCj4gPiA+ID4gb3RoZXIgYm9kaWVzIHRvIGZpbGwg dGhlIGdhcHM/DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBkcmFmdC13dS1odHRwLXN0cmVhbWluZy1v cHRpbWl6YXRpb24tcHMgaXMgYSBnb29kDQo+ID4gc3RhcnQgYXQgc3VjaA0KPiA+ID4gPiBhbiBh bmFseXNpcywgYnV0IGRvZXNuJ3QgZ28gZGVlcCBlbm91Z2ggdG8gbGV0IHVzIGRlY2lkZQ0KPiA+ IHdoYXQgd29yaw0KPiA+ID4gPiBJRVRGIHNob3VsZCBkby4NCj4gPiA+DQo+ID4gPiArMQ0KPiA+ ID4NCj4gPiA+IFRoZSBrZXkgcXVlc3Rpb24gcmVhbGx5IGlzICJ3aGF0IGRvIHlvdSB0aGluayB0 aGUgSUVURiBuZWVkcyB0byBkbz8iDQo+ID4NCj4gPiBJIGltYWdpbmUgdGhlIG9ubHkgd29yayB0 aGUgSUVURiBzaG91bGQgZG8gKGlmIHdlIGRlY2lkZSB0bykNCj4gPiBpcyB0aGUgdHJhbnNwb3J0 IGFuZCBIVFRQLWxheWVyIG9wdGltaXphdGlvbiBmb3IgYmV0dGVyDQo+ID4gc3RyZWFtaW5nIHBl cmZvcm1hbmNlLg0KPiA+DQo+ID4gLWFjYmVnZW4NCj4gPg0KPiA+ID4gTGFycw0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gaHR0cHN0cmVh bWluZyBtYWlsaW5nIGxpc3QNCj4gPiBodHRwc3RyZWFtaW5nQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5nDQo+ID4NCj4gDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpodHRwc3Ry ZWFtaW5nIG1haWxpbmcgbGlzdA0KaHR0cHN0cmVhbWluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5n From sunseawq@huawei.com Mon Oct 11 02:14:52 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B83393A692D for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 02:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.936 X-Spam-Level: X-Spam-Status: No, score=0.936 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok63OBF9RyDr for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 02:14:52 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CFB0B3A690D for <httpstreaming@ietf.org>; Mon, 11 Oct 2010 02:14:51 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA400JPCCCI36@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 17:14:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA400M9ACCGYS@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 17:14:41 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA400I8GCCGEZ@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 17:14:40 +0800 (CST) Date: Mon, 11 Oct 2010 17:14:40 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <017101cb6924$bc093410$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Oct 2010 09:14:53 -0000 SGksOg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBbGkgQy4gQmVnZW4g KGFiZWdlbikiIDxhYmVnZW5AY2lzY28uY29tPg0KVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3 ZWkuY29tPjsgIlJvbmkgRXZlbiIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJy eWFuIiA8ZGJyeWFuQGV0aGVybm90Lm9yZz4NCkNjOiA8aHR0cHN0cmVhbWluZ0BpZXRmLm9yZz4N ClNlbnQ6IFN1bmRheSwgT2N0b2JlciAxMCwgMjAxMCAxMjo0NiBBTQ0KU3ViamVjdDogUkU6IFto dHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KDQoNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBRaW4gV3UgW21haWx0bzpzdW5zZWF3cUBo dWF3ZWkuY29tXQ0KPiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMDgsIDIwMTAgNDoxNiBQTQ0KPiBU bzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pOyBSb25pIEV2ZW47IERhdmlkIEEuIEJyeWFuDQo+IENj OiBodHRwc3RyZWFtaW5nQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10g Q3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQo+IA0KPiA+IGFsc28gYSBuZWVkIGZvciB2aWRl byBzeW5jaHJvbml6YXRpb24gdG8gc3RhcnQgcmVuZGVyaW5nLg0KPiANCj4gU3luY2hyb25pemF0 aW9uIGFtb25nIHRoZSB2aWV3ZXJzIHlvdSBtZWFuPyBUaGF0IGNvdWxkIGJlIGEgY29uY2VybiBi dXQgc2VyaW91c2x5LCBzaW5jZSBjbGllbnQgaW1wbGVtZW50YXRpb25zIHdpbGwNCj4gZGlmZmVy LCBuZXR3b3JrIGNhcGFjaXRpZXMgd2lsbCBkaWZmZXIsIGkuZS4sIHByZXR0eSBtdWNoIGV2ZXJ5 dGhpbmcgd2lsbCBkaWZmZXIgZm9yIGRpZmZlcmVudCBjbGllbnRzLCBJIGRvbid0IHRoaW5rIHRo ZXJlIGlzIGENCj4gc29sdXRpb24gdG8gdGhpcy4gQmV0dGVyIHNhaWQsIEkgZG9uJ3QgdGhpbmsg dGhlcmUgaXMgYSBwcm9ibGVtLg0KPiANCj4gW1Fpbl0gSSB0aGluayBTeW5jaHJvbml6YXRpb24g YmV0d2VlbiB0aGUgc2VydmVyIGFuZCB0aGUgY2xpZW50IGlzIG9uZSBpc3N1ZSB3ZSBtYXkgbG9v ayBhdC4gU2luY2UgdGhlIHNlcnZlciBoYXMgYnVmZmVyIGZvcg0KPiBlbmNvZGluZywgdGhlIGNs aWVudCBoYXMgYSBidWZmZXIgZm9yIHBsYXlvdXQsIHdlIGRlZmluaXRlbHkgbmVlZCBvbmUgc3Ry ZWFtaW5nIG1lZGlhIHN5bmNocm9uaXphdGlvbiBtZWNoYW5pc20gd2hpY2ggbWF5DQo+IGhlbHAg cmVkdWNlIGRlbGF5Lg0KDQpTb3JyeSwgSSBkb26SdCBnZXQgdGhpcy4gU2VydmVyIG9yIHNvbWVv bmUgZWxzZSBhZHZlcnRpc2VzIHdoYXQgaXMgYXZhaWxhYmxlIHRvIHRoZSBjbGllbnQgYW5kIGNs aWVudCBmZXRjaGVzIHdoYXRldmVyIGl0IHdhbnRzIChhbmQgaXMgYXZhaWxhYmxlKS4gV2h5IGlz IHRoZXJlIGEgbmVlZCBmb3Igc3luY2hyb25pemF0aW9uIGhlcmU/DQoNCltRaW5dOiBXZSBtYXkg bG9vayBhdCB0d28gZGlmZmVyZW50ICB1c2UgY2FzZXM6IHB1c2ggbW9kZWwgYW5kIHB1bGwgbW9k ZWwNCkluIHRoZSBwdWxsIG1vZGVsLCB5b3UgYXJlIHJpZ2h0LiBUaGUgY2xpZW50ICBjb250cm9s IHRoZSB0aW1pbmcgb2YgZmV0Y2hpbmcgdGhlIGNodW5rcyBieSBkcml2aW5nIHRoZSBIVFRQIHJl cXVlc3QuIEl0IG9ubHkgcmVxdWVzdCBpdCBuZWVkcyBhbmQgY2FuIGhhbmRsZS4gSG93ZXZlciAg Y2xpZW50IGJhc2VkIHB1bGwgaXMgY2hhcmFjdGVyaXplZA0KYXMgcG9sbGluZyBmb3IgbmV3IGRh dGEgZWFjaCB0aW1lIGFuZCBpcyBub3QgZWZmaWNpZW50IHdheSB0byBkZWxpdmVyIHRoZSByZWFs IHRpbWUgc3RyZWFtaW5nIGNvbnRlbnRzLg0KSW4gdGhlIHB1c2ggbW9kZWwsIHRoZSBjbGllbnQg ZG9lcyBub3Qga25vdyB3aGVuIHRoZSBjb25lbnRzIGlzIGF2YWlsYWJsZSBhdCB0aGUgc2VydmVy LiBGb3IgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIHJlcXVlc3QgZm9yIGVhY2ggY2h1bmtzLiB0 aGUgY2xpZW50IGNsb2NrIGlzIGVhc3kgdG8gYXN5bmNocm9uaXplIHdpdGggZW5jb2RlciBjbG9j ay4= From sunseawq@huawei.com Mon Oct 11 04:49:29 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CE83A69AE for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 04:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.4 X-Spam-Level: * X-Spam-Status: No, score=1.4 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yed2MHV2BUA7 for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 04:49:28 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A74C03A6931 for <httpstreaming@ietf.org>; Mon, 11 Oct 2010 04:49:27 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA400JC5JK4VC@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 19:50:29 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA400FUXJK38V@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 19:50:28 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA400KE4JK3F2@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 11 Oct 2010 19:50:27 +0800 (CST) Date: Mon, 11 Oct 2010 19:50:27 +0800 From: Qin Wu <sunseawq@huawei.com> To: Mark Watson <watsonm@netflix.com>, "Ali C. Begen (abegen)" <abegen@cisco.com> Message-id: <029d01cb693a$7f515f50$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_VH3oDLYkI7UgpRjiPESEFA)" X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Oct 2010 11:49:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_VH3oDLYkI7UgpRjiPESEFA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: base64 SGksDQpUaGlzIGlzIHdoYXQgd2UgaGFkIGRpc2N1c3NlZCAgaW4gdGhlIERJU1BBVENIIG1haWxp bmcgbGlzdCBiZWZvcmUgd2UgbW92ZSB0byB0aGlzIGRpc2N1c3MgbGlzdC4NCklmIHlvdSBsb29r IGF0IHRoZSBkZXNjcmlwdGlvbiBvZiBkaXNjdXNzIGxpc3QsICINCm9mZmVycyBtb3JlIGVmZmlj aWVudCB0cmFuc3BvcnQgDQphbmQgYmV0dGVyIG5ldHdvcmsgY2FwYWJpbGl0eSBmb3IgcmVhbCB0 aW1lIHN0cmVhbWluZyBtZWRpYQ0KYW5kIGFsbG93cyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggb3Ro ZXIgc3RyZWFtaW5nIHRlY2huaXF1ZXMgYW5kIGV4aXN0aW5nIFByb2dyZXNzaXZlIGRvd2xvYWRl ZCBiYXNlZA0KSFRUUCBzdHJlYW1pbmcgaW1wbGVtZW50YXRpb24uDQoiDQp5b3Ugd2lsbCBzZWUg d2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UuDQpUaGVyZWZvcmUgb25lIGltcG9ydGFudCBnb2FsIGRp c2N1c3NlZCBpbiB0aGUgZHJhZnQgYWltcyBhdCBkZXZlbG9waW5nIGludGVyb3BlcmFibGUgc29s dXRpb24gdG8gDQpwcm92aWRlIGJldHRlciB0cmFuc3BvcnQgdG8gc2F0aXNmeSB0aGUgcmVhbCB0 aW1lIHN0cmVhbWluZyBRT0UgcmVxdWlyZW1lbnQuIEVzcGVjaWFsbHkgc2VydmVyYWwNCmNoYW5s bGVuZ2VzL3Byb2JsZW1zIHdlIGV4cGxvcmVkIGluIHRoZSBkcmFmdCBsaXN0ZWQgYmVsb3cuDQoN ClJlZ2FyZHMhDQotUWluDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206 IE1hcmsgV2F0c29uIA0KICBUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pIA0KICBDYzogaHR0cHN0 cmVhbWluZ0BpZXRmLm9yZyA7IENvbGluIFBlcmtpbnMgDQogIFNlbnQ6IFN1bmRheSwgT2N0b2Jl ciAxMCwgMjAxMCA3OjEzIEFNDQogIFN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10gQ3VycmVu dCBTdGF0dXMgYW5kIE91ciBHb2FsDQoNCg0KICBBbGwsDQoNCg0KICBJIHdvdWxkIGxpa2UgdG8g YWRkIG15IHN1cHBvcnQgdG8gdGhlIGNvbW1lbnRzIGJlbG93LiBTcGVjaWZpY2FsbHksIEkgdGhp bmsgaWYgdGhlIElFVEYgY29uc2lkZXJzIHdvcmsgaW4gdGhpcyBhcmVhIGl0IHNob3VsZCBmb2N1 cyBvbiB0aGUgSFRUUCBhbmQgVENQIHByb3RvY29scy4gQW55IHN1Y2ggd29yayBtYXkgbm90IGJl IHNwZWNpZmljIHRvIEhUVFAtc3RyZWFtaW5nIChpLmUuIGVuaGFuY2VtZW50cyB0aGF0IGFyZSBh dCBmaXJzdCBtb3RpdmF0ZWQgYnkgSFRUUCBTdHJlYW1pbmcgbWF5IGhhdmUgYnJvYWRlciBhcHBs aWNhYmlsaXR5LCBhbmQgdGhpcyBzaG91bGQgYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQpLg0KDQoN CiAgSW4gdGhlIGRyYWZ0IEkgZG8gbm90IHNlZSBhIGNsZWFyIG9yIGNvcnJlY3QgaWRlbnRpZmlj YXRpb24gb2YgdGhlIHByb2JsZW1zLiBGb3IgZXhhbXBsZSBpbiB0aGUgaW50cm9kdWN0aW9uIHRo ZSBmb2xsb3dpbmcgYXJlIHN0YXRlZCBhcyBpc3N1ZXM6DQogICAtIENsaWVudCBwb2xsaW5nIGZv ciBlYWNoIG5ldyBkYXRhIGluIGNodW5rcyB1c2luZyBIVFRQIHJlcXVlc3RzIGlzDQogICBub3Qg ZWZmaWNpZW50IHRvIGRlbGl2ZXIgaGlnaC1xdWFsaXR5IHZpZGVvIGNvbnRlbnQgYWNyb3NzIHRo ZQ0KICAgSW50ZXJuZXRNVzogU2V2ZXJhbCBjb21wYW5pZXMsIGluY2x1ZGluZyBteSBlbXBsb3ll ciwgYXJlIHN1Y2Nlc3NmdWxseSBvcGVyYXRpbmcgbGFyZ2Ugc2NhbGUgSFRUUCBzdHJlYW1pbmcg c3lzdGVtcyB0aGF0IGRvIGVmZmljaWVudGx5IGRlbGl2ZXIgaGlnaC1xdWFsaXR5IHZpZGVvIGNv bnRlbnQgYWNyb3NzIHRoZSBJbnRlcm5ldCwgc28gcmVhbGl0eSBzZWVtcyB0byByZWZ1dGUgdGhp cyBzdGF0ZW1lbnQuW1Fpbl06IE5vdCBzdXJlIHRoZXkgY2FuIHByb3ZpZGUgdGhlIFRWIGV4cGVy aWVuY2UgZm9yIGFsbCB0aGUgY29ubmVjdGVkIGRldmljZXMgbGlrZSBzbWFydHBob25lcywgUENz IGFuZCB0YWJsZXRzLiBBbHNvIG5vdCBzdXJlIHRoZXkgY2FuIHByb3ZpZGUgdGhlIHNhbWUgcXVh bGl0eSBvZiBleHBlcmVuY2UgZm9yIGFsbCB0aGUgYWxsIHRoZSBjb25uZWN0ZWQgZGV2aWNlcy4g QXMgd2UgZGlzY3Vzc2VkIGluIHRoaXMgdGhyZWFkLCBhIG1pbmltdW0gb2YgMjAgc2Vjb25kcyB0 byBzdGFydCB5b3VyIHZpZGVvIG9mdGVuIGZydXN0cmF0ZWQgdXNlcnMgdG8ga2VlcCBvbiB3YXRj aGluZyBhbmQgcHJvdmlkZSB2ZXJ5IGxpbWl0ZWQgdXNlciBleHBlcmllbmNlLk9uIHRoZSBvdGhl ciBoYW5kLCBJIHRoaW5rIHdlIHNob3VsZCBiZWFyIGluIG1pbmQgSFRUUCBpcyBmb3JtZXJseSBk ZXNpZ25lZCBmb3IgYnJvd3Npbmcgd2VicGFnZSwgdHJhbnNwb3J0IHN0YXRpYyBjb250ZW50cyBs aWtlIEhUTUwgcGFnZSwgcGx1Z2luLCBwaWN0dXJlLCB3aGVuIHdlIGFyZSBnb2luZyB0byB1c2Ug SFRUUCB0byBkZWxpdmVyIHJlYWwgdGltZSBzdHJlYW1pbmcgY29udGVudHMsIHdlIGNhbiBub3Qg ZXhwZWN0IHRvIGdldCBoaWdoZXIgdXNlciBleHBlcmllbmNlLiBUaGVyZWZvcmUgdGhlIGN1cnJl bnQgc3RyZWFtaW5nIHNjaGVtZXMgY2FuIG9ubHkgb2ZmZXIgYSBiZXR0ZXIgZXhwZXJpZW5jZSBv dmVyIHNsb3dlciBjb25uZWN0aW9ucy4gICAtIFNlZ21lbnRhdGlvbiBjYXBhYmlsaXR5IHJlcXVp cmVzIG92ZXItdXRpbGl6aW5nIENQVSBhbmQgYmFuZHdpZHRoDQogICByZXNvdXJjZXMsIHdoaWNo IG1heSBub3QgYmUgYSBkZXNpcmFibGUgYW5kIGVmZmVjdGl2ZSB3YXkgdG8gaW1wcm92ZQ0KICAg dGhlIHF1YWxpdHkgb2Ygc3RyZWFtaW5nIG1lZGlhIGRlbGl2ZXJ5TVc6IEl0IGlzIG5vdCBjbGVh ciB0aGF0IHNlZ21lbnRhdGlvbiBwZXIgc2UgaXMgQ1BVLWludGVuc2l2ZSBvciBoYXMgYW55IG5v bi1uZWdsaWdhYmxlIGVmZmVjdCBvbiBiYW5kd2lkdGggdXNhZ2UuW1Fpbl06IFNpbmNlIEhUVFAg c3RyZWFtaW5nIHNlcnZlciBpcyB0aGUgY29tYmluYXRpb24gb2Ygc3RyZWFtaW5nIHNlcnZlciBh bmQgcmVndWxhciB3ZWIgc2VydmVyLCBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMgYm90aC4gICAtIExh Y2sgb2YgUW9TIGd1YXJhbnRlZSBvbiB0aGUgcGFja2V0IHN3aXRjaGluZyBiYXNlZCBJbnRlcm5l dCAsIHRoZQ0KICAgcXVhbGl0eSBvZiBJbnRlcm5ldCBtZWRpYSBzdHJlYW1pbmcgbWF5IHNpZ25p ZmljYW50IGRlZ3JhZGUgZHVlIHRvDQogICByaXNpbmcgdXNhZ2VNVzogQW4gYWx0ZXJuYXRpdmUg dmlldyBpcyB0aGF0IHdoZXJlIHF1YWxpdHkgaXMgZGVncmFkZWQgZHVlIHRvIGNvbmdlc3Rpb24g dGhpcyBpcyBkdWUgdG8gbGFjayBvZiBiYW5kd2lkdGgsIHJhdGhlciB0aGFuIGEgbGFjayBvZiBR b1MgZ3VhcmFudGVlcy4gQWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyBhZGp1c3QgdGhl IHZpZGVvIHF1YWxpdHkgdG8gdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggaW4gb3JkZXIgdG8gYXZv aWQgcmVidWZmZXJpbmcgZXZlbnRzLiBJdCBpcyB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCB0aGF0 IG5lZWRzIHRvIGJlIGltcHJvdmVkIHRvIGltcHJvdmUgcXVhbGl0eS5bUWluXTogV2hhdCBJIGVt cGhhc2l6ZSBoZXJlIGlzIHdpdGggZ3Jvd2luZyBwb3B1bGFyaXR5IG9mIEhUVFAgc3RyZWFtaW5n IHRyYWZmaWMsIHdoZW4gdGhvdXNhbmRzIG9yIG1pbGxpb25zIG9mIHBlb3BsZSBhcmUgYWNjZXNz aW5nIHRoZSBzYW1lIG1lZGlhIGNvbnRlbnRzLCB0aGUgYmlnIHByb2JsZW0gd2UgYXJlIGZhY2lu ZyBpcyBzZXJpb3VzIGhpZ2ggY29uY3VycmVuY2UgYWNjZXNzIGlzc3VlLiBUaGUgdXNlciBleHBl cmllbmNlIHdpbGwgYmUgZ3JlYXRseSBhZmZlY3RlZCBldmVuIHlvdSBoYXZlIGVub3VnaCBhdmFp bGFibGUgYmFuZHdpZHRoLiBTbyB0aGlzIGlzIG5vdCBwdXJlIGJhbmR3aWR0aCBpc3N1ZS4gICAt IEV4cGVyaWVuY2UgYnVyc3RpbmVzcyBvciBvdGhlciBkeW5hbWljcyBjaGFuZ2VzIGR1ZSB0byBi YW5kd2lkdGgNCiAgIGZsdWN0dWF0aW9ucyBhbmQgaGV0ZXJvZ2VuZW91cyBoYW5kb3Zlci5NVzog V2UgaGF2ZSBmb3VuZCB0aGF0IGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRobXMgYXJl IHdlbGwgYWJsZSB0byBjb3BlIHdpdGggYmFuZHdpZHRoIGZsdWN0dWF0aW9ucy4gW1Fpbl06IEkg ZG9uJ3QgZG91YnQgdGhhdCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyBhbGdvcml0aG1zIGNhbiBj b3BlIHdpdGggYmFuZHdpZHRoIGZsdWN0YXRpb24uIEJ1dCBJIGhvcGUgd2UgY2FuIGRvIGJldHRl ci5lLmcuLCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyBhbGdvcml0aG1zIG9ubHkgc3VwcG9ydCBk ZWxpdmVyeSBvZiBtdWx0aXBsZSBzdHJlYW1zIG9mIHRoZSBzYW1lIGNvbnRlbnQgd2l0aCB2YXJ5 aW5nIHF1YWxpdHkgbGV2ZWxzIGZvciBkaWZmZXJlbnQgYmFuZHdpZHRoIG9yIGRldmljZXMuIEhv d2V2ZSBob3cgdGhlIHNlcnZlciBpbiBwdXNoIG1vZGVsIG9yIGNsaWVudCBpbiBwdWxsIG1vZGVs IGNhbiBxdWljayByZXNwb25zZSB0byB0aGUgYml0cmF0ZSBjaGFuZ2VzIGlzIGEgcHJvYmxlbSB3 ZSBtYXkgbG9vayBhdCxlc3BlY2lhbGx5IHdoZW4gc3dpdGNoaW5nIGJld2VlbiBzdHJlYW1zIG9j Y3VycyB2ZXJ5IGZyZXF1ZW50bHkuICAgLSBJbXBvc3NpYmxlIHRvIGZhc3QtZm9yd2FyZCB0aHJv dWdoIGFueSBwYXJ0IG9mIGEgc3RyZWFtaW5nDQogICBjb250ZW50cyB1bnRpbCBpdCBpcyBzdG9y ZWQgb24gdGhlIHVzZXIncyBkZXZpY2VNVzogVGhpcyBpcyBzaW1wbHkgbm90IGNvcnJlY3QsIHNp bmNlIHRoZXJlIGFyZSBodW5kcmVkcyBvZiBleGFtcGxlcyBvZiBkZXZpY2VzIHdoaWNoIHN1cHBv cnQgdHJpY2stcGxheSB1c2luZyBIVFRQIHN0cmVhbWluZyB0ZWNobmlxdWVzIHdpdGhvdXQgc3Rv cmluZyB0aGUgd2hvbGUgY29udGVudCBvbiB0aGUgdXNlcnMgZGV2aWNlLltRaW5dOiBGYXN0IGZv cndhcmQgY2FwYWJpbHR5IGlzIG5vdCB0aGUgbW9zdCBpbXBvcnRhbnQgZmVhdHVyZSB3ZSBhcmUg bG9va2luZyBmb3IuIEhvd2V2ZXIgSSBhbSBoYXJkIHRvIGJlbGlldmUgZXhpc3RpbmcgSFRUUCBz dHJlYW1pbmcgdGVjaG5pcXVlcyBjYW4gcHJvdmlkZSB0aGUgc2FtZSBkZWdyZWUgb2YgcGxheWJh Y2tjb250cm9sIHRoYXQgRFZEIHBsYXllciBjYW4gcHJvdmlkZXMgb3IgUlRTUCBwcm90b2NvbCBw cm92aWRlcy4gRS5nLiwgSW4gdGhlIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRobXMs IHRoZSB0cmljayBwbGF5IGlzIGxpbWl0ZWQgdG8gcGF1c2UvcmVzdW1lL3N0b3AgYnkgZHJpdmlu ZyB0aGUgSFRUUCByZXF1ZXN0LiBJZiB0aGUgY29udGVudHMgaGFzbid0IGJlZW4gZG93bG9hZGVk ICBhbmQgdGhlIGNvbnN1bWUgd2FudCBmYXN0IGZvcndhcmQsIHRoZSBIVFRQIGNsaWVudCBuZWVk cyB0byBpc3N1ZSBhbm90aGVyIG5ldyBIVFRQIHJlcXVlc3QgdG8gZmV0Y2ggdGhlIGNvbnRlbnRz IHdoaWNoIHdpbGxjYXVzZSB1bmFjY2VwdGFibGUgbGF0ZW5jeSB0byB0aGUgY29uc3VtZXIuQSBm aXJzdCBzdGVwIGluIGNvbnNpZGVyaW5nIHdoYXQsIGlmIGFueSwgd29yayBzaG91bGQgYmUgZG9u ZSBoZXJlIG1pZ2h0IGJlIHRvIGNvbnRhY3QgdGhvc2Ugb3JnYW5pemF0aW9ucyB3aGljaCBhcmUg c3RhbmRhcmRpemluZyB0aGUgaGlnaGVyIGxheWVycyBvZiBIVFRQIHN0cmVhbWluZyBzeXN0ZW1z IChlLmcuIG1hbmlmZXN0IGFuZCBmaWxlIGZvcm1hdHMpIGFuZCBhc2sgd2hldGhlciB0aGVyZSBh cmUgZGVmaWNpZW5jaWVzIHRoZXkgc2VlIGluIElFVEYgcHJvdG9jb2xzIHRoYXQgY291bGQgYmUg dXNlZnVsbHkgYWRkcmVzc2VkIGJ5IHRoZSBJRVRGLiBXaGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGF2 b2lkIGluIHRoZSBJRVRGIGlzIGR1cGxpY2F0aW5nIHRoZSB3b3JrIG9mIHRoZXNlIG90aGVyIGJv ZGllcy5CZXN0LE1hcmsgV2F0c29uTmV0ZmxpeCBJbmMuDQoNCg0KDQoNCg0KICBPbiBPY3QgMTAs IDIwMTAsIGF0IDEyOjQzIEFNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQoNCg0KDQoN Cg0KICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KICAgICAgRnJvbTogaHR0cHN0 cmVhbWluZy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aHR0cHN0cmVhbWluZy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTGFycyBFZ2dlcnQNCg0KICAgICAgU2VudDogRnJpZGF5LCBP Y3RvYmVyIDA4LCAyMDEwIDQ6MTcgUE0NCg0KICAgICAgVG86IENvbGluIFBlcmtpbnMNCg0KICAg ICAgQ2M6IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcNCg0KICAgICAgU3ViamVjdDogUmU6IFtodHRw c3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KDQoNCiAgICAgIE9uIDIw MTAtMTAtNywgYXQgMTQ6MTYsIENvbGluIFBlcmtpbnMgd3JvdGU6DQoNCiAgICAgICAgVGhlcmUg YXJlIGNsZWFybHkgc29tZSBpc3N1ZXMgdG8gY29uc2lkZXIgaGVyZS4gV2hhdCBzZWVtcyB0byBi ZQ0KDQogICAgICAgIG1pc3NpbmcgZnJvbSB0aGUgZGlzY3Vzc2lvbiB0byBtZSB0aG91Z2gsIGlz IHNvbWUgaWRlbnRpZmljYXRpb24gb2YNCg0KICAgICAgICB0aGUgY29uY3JldGUgcHJvYmxlbXMu IFdoYXQgcHJvdG9jb2wgcGllY2VzIGRvIHdlIG5lZWQsIGJ1dCBub3QgaGF2ZT8NCg0KICAgICAg ICBXaGF0IHByb3RvY29scyBhcmUgcHJvYmxlbWF0aWMsIGFuZCBuZWVkIGVuaGFuY2VtZW50PyBJ cyB0aGVyZQ0KDQogICAgICAgIHByb3RvY29sIHdvcmsgdG8gZG8gaW4gSUVURiwgb3Igc2hvdWxk IHdlIGJlIGRvY3VtZW50aW5nIGJlc3QgY3VycmVudA0KDQogICAgICAgIHByYWN0aWNlcyBmb3Ig dXNpbmcgdGhlIGV4aXN0aW5nIHByb3RvY29scyBhbmQvb3IgcmVseWluZyBvbiBvdGhlcg0KDQog ICAgICAgIGJvZGllcyB0byBmaWxsIHRoZSBnYXBzPw0KDQoNCg0KICAgICAgICBUaGUgZHJhZnQt d3UtaHR0cC1zdHJlYW1pbmctb3B0aW1pemF0aW9uLXBzIGlzIGEgZ29vZCBzdGFydCBhdCBzdWNo IGFuDQoNCiAgICAgICAgYW5hbHlzaXMsIGJ1dCBkb2Vzbid0IGdvIGRlZXAgZW5vdWdoIHRvIGxl dCB1cyBkZWNpZGUgd2hhdCB3b3JrIElFVEYNCg0KICAgICAgICBzaG91bGQgZG8uDQoNCg0KDQog ICAgICArMQ0KDQoNCg0KICAgICAgVGhlIGtleSBxdWVzdGlvbiByZWFsbHkgaXMgIndoYXQgZG8g eW91IHRoaW5rIHRoZSBJRVRGIG5lZWRzIHRvIGRvPyINCg0KDQogICAgSSBpbWFnaW5lIHRoZSBv bmx5IHdvcmsgdGhlIElFVEYgc2hvdWxkIGRvIChpZiB3ZSBkZWNpZGUgdG8pIGlzIHRoZSB0cmFu c3BvcnQgYW5kIEhUVFAtbGF5ZXIgb3B0aW1pemF0aW9uIGZvciBiZXR0ZXIgc3RyZWFtaW5nIHBl cmZvcm1hbmNlLg0KDQogICAgLWFjYmVnZW4NCg0KDQogICAgICBMYXJzDQoNCiAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIGh0dHBzdHJlYW1p bmcgbWFpbGluZyBsaXN0DQogICAgaHR0cHN0cmVhbWluZ0BpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cHN0cmVhbWluZw0KDQoNCg0KDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICBodHRwc3RyZWFtaW5nIG1haWxpbmcgbGlzdA0KICBodHRw c3RyZWFtaW5nQGlldGYub3JnDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaHR0cHN0cmVhbWluZw0K --Boundary_(ID_VH3oDLYkI7UgpRjiPESEFA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODkyOCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIA0Kc3R5bGU9IldPUkQtV1JBUDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIiANCmJnQ29s b3I9I2NjZThjZj4NCjxESVY+SGksPC9ESVY+DQo8RElWPlRoaXMgaXMgd2hhdCB3ZSBoYWQgZGlz Y3Vzc2VkJm5ic3A7IGluIHRoZSBESVNQQVRDSCBtYWlsaW5nIGxpc3QgYmVmb3JlIHdlIA0KbW92 ZSB0byB0aGlzIGRpc2N1c3MgbGlzdC48L0RJVj4NCjxESVY+SWYgeW91IGxvb2sgYXQgdGhlIGRl c2NyaXB0aW9uIG9mIGRpc2N1c3MgbGlzdCwgIjwvRElWPg0KPERJVj5vZmZlcnMgbW9yZSBlZmZp Y2llbnQgdHJhbnNwb3J0IDxCUj5hbmQgYmV0dGVyIG5ldHdvcmsgY2FwYWJpbGl0eSBmb3IgcmVh bCANCnRpbWUgc3RyZWFtaW5nIG1lZGlhPEJSPmFuZCBhbGxvd3MgaW50ZXJvcGVyYWJpbGl0eSB3 aXRoIG90aGVyIHN0cmVhbWluZyANCnRlY2huaXF1ZXMgYW5kIGV4aXN0aW5nIFByb2dyZXNzaXZl IGRvd2xvYWRlZCBiYXNlZDxCUj5IVFRQIHN0cmVhbWluZyANCmltcGxlbWVudGF0aW9uLjwvRElW Pg0KPERJVj4iPC9ESVY+DQo8RElWPnlvdSB3aWxsJm5ic3A7c2VlIHdlIGFyZSBvbiB0aGUgc2Ft ZSBwYWdlLjwvRElWPg0KPERJVj5UaGVyZWZvcmUgb25lJm5ic3A7aW1wb3J0YW50IGdvYWwgZGlz Y3Vzc2VkIGluIHRoZSBkcmFmdCZuYnNwO2FpbXMgDQphdCZuYnNwO2RldmVsb3BpbmcgaW50ZXJv cGVyYWJsZSBzb2x1dGlvbiB0byA8L0RJVj4NCjxESVY+cHJvdmlkZSBiZXR0ZXIgdHJhbnNwb3J0 IHRvIHNhdGlzZnkgdGhlIHJlYWwgdGltZSBzdHJlYW1pbmcgUU9FIA0KcmVxdWlyZW1lbnQuIEVz cGVjaWFsbHkmbmJzcDtzZXJ2ZXJhbDwvRElWPg0KPERJVj5jaGFubGxlbmdlcy9wcm9ibGVtcyZu YnNwO3dlIGV4cGxvcmVkIGluIHRoZSBkcmFmdCBsaXN0ZWQgYmVsb3cuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj5SZWdhcmRzITwvRElWPg0KPERJVj4tUWluPC9ESVY+DQo8QkxPQ0tR VU9URSANCnN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVG VDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdI VDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAm IzIzNDM1OyYjMjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+ PEI+RnJvbTo8L0I+IA0KICA8QSB0aXRsZT13YXRzb25tQG5ldGZsaXguY29tIGhyZWY9Im1haWx0 bzp3YXRzb25tQG5ldGZsaXguY29tIj5NYXJrIFdhdHNvbjwvQT4gDQogIDwvRElWPg0KICA8RElW IHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1h YmVnZW5AY2lzY28uY29tIA0KICBocmVmPSJtYWlsdG86YWJlZ2VuQGNpc2NvLmNvbSI+QWxpIEMu IEJlZ2VuIChhYmVnZW4pPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0 MzU7JiMyMDMwNzsiPjxCPkNjOjwvQj4gPEEgdGl0bGU9aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyAN CiAgaHJlZj0ibWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmciPmh0dHBzdHJlYW1pbmdAaWV0 Zi5vcmc8L0E+IDsgPEEgDQogIHRpdGxlPWNzcEBjc3BlcmtpbnMub3JnIGhyZWY9Im1haWx0bzpj c3BAY3NwZXJraW5zLm9yZyI+Q29saW4gUGVya2luczwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFN1bmRheSwgT2N0 b2JlciAxMCwgMjAxMCA3OjEzIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIz NDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50 IFN0YXR1cyANCiAgYW5kIE91ciBHb2FsPC9ESVY+DQogIDxESVY+PEJSPjwvRElWPkFsbCwNCiAg PERJVj48QlI+PC9ESVY+DQogIDxESVY+SSB3b3VsZCBsaWtlIHRvIGFkZCBteSBzdXBwb3J0IHRv IHRoZSBjb21tZW50cyBiZWxvdy4gU3BlY2lmaWNhbGx5LCBJIA0KICB0aGluayBpZiB0aGUgSUVU RiBjb25zaWRlcnMgd29yayBpbiB0aGlzIGFyZWEgaXQgc2hvdWxkIGZvY3VzIG9uIHRoZSBIVFRQ IGFuZCANCiAgVENQIHByb3RvY29scy4gQW55IHN1Y2ggd29yayBtYXkgbm90IGJlIHNwZWNpZmlj IHRvIEhUVFAtc3RyZWFtaW5nIChpLmUuIA0KICBlbmhhbmNlbWVudHMgdGhhdCBhcmUgYXQgZmly c3QgbW90aXZhdGVkIGJ5IEhUVFAgU3RyZWFtaW5nIG1heSBoYXZlIGJyb2FkZXIgDQogIGFwcGxp Y2FiaWxpdHksIGFuZCB0aGlzIHNob3VsZCBiZSBjYXJlZnVsbHkgY29uc2lkZXJlZCkuPC9ESVY+ DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPkluIHRoZSBkcmFmdCBJIGRvIG5vdCBzZWUgYSBj bGVhciBvciBjb3JyZWN0IGlkZW50aWZpY2F0aW9uIG9mIHRoZSANCiAgcHJvYmxlbXMuIEZvciBl eGFtcGxlIGluIHRoZSBpbnRyb2R1Y3Rpb24gdGhlIGZvbGxvd2luZyBhcmUgc3RhdGVkIGFzIA0K ICBpc3N1ZXM6PC9ESVY+DQogIDxESVY+PFBSRSBjbGFzcz1uZXdwYWdlPiAgIC0gQ2xpZW50IHBv bGxpbmcgZm9yIGVhY2ggbmV3IGRhdGEgaW4gY2h1bmtzIHVzaW5nIEhUVFAgcmVxdWVzdHMgaXMN CiAgIG5vdCBlZmZpY2llbnQgdG8gZGVsaXZlciBoaWdoLXF1YWxpdHkgdmlkZW8gY29udGVudCBh Y3Jvc3MgdGhlDQogICBJbnRlcm5ldDxCUj48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PEZPTlQg Y2xhc3M9QXBwbGUtc3R5bGUtc3BhbiBmYWNlPUhlbHZldGljYT5NVzogU2V2ZXJhbCBjb21wYW5p ZXMsIGluY2x1ZGluZyBteSBlbXBsb3llciwgYXJlIHN1Y2Nlc3NmdWxseSBvcGVyYXRpbmcgbGFy Z2Ugc2NhbGUgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyB0aGF0IGRvIGVmZmljaWVudGx5IGRlbGl2 ZXIgaGlnaC1xdWFsaXR5IHZpZGVvIGNvbnRlbnQgYWNyb3NzIHRoZSBJbnRlcm5ldCwgc28gcmVh bGl0eSBzZWVtcyB0byByZWZ1dGUgdGhpcyBzdGF0ZW1lbnQuPC9GT05UPjwvUFJFPjxQUkUgY2xh c3M9bmV3cGFnZT48Rk9OVCBzaXplPTQ+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bUWlu XTogTm90IHN1cmUgdGhleSBjYW4gcHJvdmlkZSB0aGUgVFYgZXhwZXJpZW5jZSBmb3IgYWxsIHRo ZSBjb25uZWN0ZWQgZGV2aWNlcyBsaWtlIHNtYXJ0cGhvbmVzLCBQQ3MgYW5kIHRhYmxldHMuIEFs c28gbm90IHN1cmUgdGhleSBjYW4gcHJvdmlkZSB0aGUgc2FtZSBxdWFsaXR5IG9mIGV4cGVyZW5j ZSBmb3IgYWxsIHRoZSBhbGwgdGhlIGNvbm5lY3RlZCBkZXZpY2VzLiBBcyB3ZSBkaXNjdXNzZWQg aW4gdGhpcyB0aHJlYWQsIGEgbWluaW11bSBvZiAyMCBzZWNvbmRzIHRvIHN0YXJ0IHlvdXIgdmlk ZW8gb2Z0ZW4gZnJ1c3RyYXRlZCB1c2VycyB0byBrZWVwIG9uIHdhdGNoaW5nIGFuZCBwcm92aWRl IHZlcnkgbGltaXRlZCB1c2VyIGV4cGVyaWVuY2UuPC9GT05UPjwvRk9OVD48L1BSRT48UFJFIGNs YXNzPW5ld3BhZ2U+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48Rk9OVCBzaXplPTQ+T24g dGhlIG90aGVyIGhhbmQsIEkgdGhpbmsgd2Ugc2hvdWxkIGJlYXIgaW4gbWluZCBIVFRQIGlzIGZv cm1lcmx5IGRlc2lnbmVkIGZvciBicm93c2luZyB3ZWJwYWdlLCB0cmFuc3BvcnQgc3RhdGljIGNv bnRlbnRzIGxpa2UgSFRNTCBwYWdlLCBwbHVnaW4sIHBpY3R1cmUsIHdoZW4gd2UgYXJlIGdvaW5n IHRvIHVzZSA8L0ZPTlQ+PEZPTlQgc2l6ZT00PkhUVFAgdG8gZGVsaXZlciByZWFsIHRpbWUgc3Ry ZWFtaW5nIGNvbnRlbnRzLCB3ZSBjYW4gbm90IGV4cGVjdCB0byBnZXQgaGlnaGVyIHVzZXIgZXhw ZXJpZW5jZS4gPC9GT05UPjxGT05UIHNpemU9Mz48U1RST05HPlRoZXJlZm9yZSB0aGUgY3VycmVu dDwvU1RST05HPiA8U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IEZPTlQt U0laRTogMTJwdDsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6ICYjMjM0MzU7JiMyMDMwNzs7IG1z by1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IFpILUNOOyBtc28t YmlkaS1sYW5ndWFnZTogQVItU0EiIGxhbmc9RU4tVVM+PFNUUk9ORz5zdHJlYW1pbmcgc2NoZW1l cyBjYW4gb25seSBvZmZlciBhIGJldHRlciBleHBlcmllbmNlIG92ZXIgc2xvd2VyIGNvbm5lY3Rp b25zLjwvU1RST05HPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFn ZT4gICAtIFNlZ21lbnRhdGlvbiBjYXBhYmlsaXR5IHJlcXVpcmVzIG92ZXItdXRpbGl6aW5nIENQ VSBhbmQgYmFuZHdpZHRoDQogICByZXNvdXJjZXMsIHdoaWNoIG1heSBub3QgYmUgYSBkZXNpcmFi bGUgYW5kIGVmZmVjdGl2ZSB3YXkgdG8gaW1wcm92ZQ0KICAgdGhlIHF1YWxpdHkgb2Ygc3RyZWFt aW5nIG1lZGlhIGRlbGl2ZXJ5PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIGNsYXNzPUFw cGxlLXN0eWxlLXNwYW4gZmFjZT1IZWx2ZXRpY2E+TVc6IEl0IGlzIG5vdCBjbGVhciB0aGF0IHNl Z21lbnRhdGlvbiBwZXIgc2UgaXMgQ1BVLWludGVuc2l2ZSBvciBoYXMgYW55IG5vbi1uZWdsaWdh YmxlIGVmZmVjdCBvbiBiYW5kd2lkdGggdXNhZ2UuPC9GT05UPjwvUFJFPjxQUkUgY2xhc3M9bmV3 cGFnZT48Rk9OVCBzaXplPTQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bUWluXTogU2luY2UgSFRU UCBzdHJlYW1pbmcgc2VydmVyIGlzIHRoZSBjb21iaW5hdGlvbiBvZiBzdHJlYW1pbmcgc2VydmVy IGFuZCByZWd1bGFyIHdlYiBzZXJ2ZXIsIEkgdGhpbmsgdGhlIGFuc3dlciBpcyBib3RoLjwvRk9O VD48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+ICAgLSBMYWNrIG9mIFFvUyBndWFyYW50ZWUgb24g dGhlIHBhY2tldCBzd2l0Y2hpbmcgYmFzZWQgSW50ZXJuZXQgLCB0aGUNCiAgIHF1YWxpdHkgb2Yg SW50ZXJuZXQgbWVkaWEgc3RyZWFtaW5nIG1heSBzaWduaWZpY2FudCBkZWdyYWRlIGR1ZSB0bw0K ICAgcmlzaW5nIHVzYWdlPC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIGNsYXNzPUFwcGxl LXN0eWxlLXNwYW4gZmFjZT1IZWx2ZXRpY2E+TVc6IEFuIGFsdGVybmF0aXZlIHZpZXcgaXMgdGhh dCB3aGVyZSBxdWFsaXR5IGlzIGRlZ3JhZGVkIGR1ZSB0byBjb25nZXN0aW9uIHRoaXMgaXMgZHVl IHRvIGxhY2sgb2YgYmFuZHdpZHRoLCByYXRoZXIgdGhhbiBhIGxhY2sgb2YgUW9TIGd1YXJhbnRl ZXMuIEFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIHN5c3RlbXMgYWRqdXN0IHRoZSB2aWRlbyBxdWFs aXR5IHRvIHRoZSBhdmFpbGFibGUgYmFuZHdpZHRoIGluIG9yZGVyIHRvIGF2b2lkIHJlYnVmZmVy aW5nIGV2ZW50cy4gSXQgaXMgdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggdGhhdCBuZWVkcyB0byBi ZSBpbXByb3ZlZCB0byBpbXByb3ZlIHF1YWxpdHkuPC9GT05UPjwvUFJFPjxQUkUgY2xhc3M9bmV3 cGFnZT48Rk9OVCBmYWNlPUhlbHZldGljYT48Rk9OVCBzaXplPTQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj5bUWluXTogV2hhdCBJIGVtcGhhc2l6ZSBoZXJlIGlzIHdpdGggZ3Jvd2luZyBwb3B1bGFy aXR5IG9mIEhUVFAgc3RyZWFtaW5nIHRyYWZmaWMsIHdoZW4gdGhvdXNhbmRzIG9yIG1pbGxpb25z IG9mIHBlb3BsZSBhcmUgYWNjZXNzaW5nIHRoZSBzYW1lIG1lZGlhIGNvbnRlbnRzLCB0aGUgYmln IHByb2JsZW0gd2UgYXJlIGZhY2luZyBpcyBzZXJpb3VzIGhpZ2ggY29uY3VycmVuY2UgYWNjZXNz IGlzc3VlLiBUaGUgdXNlciBleHBlcmllbmNlIHdpbGwgYmUgZ3JlYXRseSBhZmZlY3RlZCBldmVu IHlvdSBoYXZlIGVub3VnaCBhdmFpbGFibGUgYmFuZHdpZHRoLiBTbyB0aGlzIGlzIG5vdCBwdXJl IGJhbmR3aWR0aCBpc3N1ZS48L0ZPTlQ+PC9GT05UPjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT4g ICAtIEV4cGVyaWVuY2UgYnVyc3RpbmVzcyBvciBvdGhlciBkeW5hbWljcyBjaGFuZ2VzIGR1ZSB0 byBiYW5kd2lkdGgNCiAgIGZsdWN0dWF0aW9ucyBhbmQgaGV0ZXJvZ2VuZW91cyBoYW5kb3Zlci48 L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PEZPTlQgY2xhc3M9QXBwbGUtc3R5bGUtc3BhbiBmYWNl PUhlbHZldGljYT5NVzogV2UgaGF2ZSBmb3VuZCB0aGF0IGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5n IGFsZ29yaXRobXMgYXJlIHdlbGwgYWJsZSB0byBjb3BlIHdpdGggYmFuZHdpZHRoIGZsdWN0dWF0 aW9ucy4gPC9GT05UPjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48Rk9OVCBzaXplPTQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj5bUWluXTogSSBkb24ndCBkb3VidCB0aGF0IGFkYXB0aXZlIEhUVFAg c3RyZWFtaW5nIGFsZ29yaXRobXMgY2FuIGNvcGUgd2l0aCBiYW5kd2lkdGggZmx1Y3RhdGlvbi4g QnV0IEkgaG9wZSB3ZSBjYW4gZG8gYmV0dGVyLjwvRk9OVD48Rk9OVCBzaXplPTQgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj5lLmcuLCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyBhbGdvcml0aG1zIG9u bHkgc3VwcG9ydCBkZWxpdmVyeSBvZiBtdWx0aXBsZSBzdHJlYW1zIG9mIHRoZSBzYW1lIGNvbnRl bnQgd2l0aCB2YXJ5aW5nIHF1YWxpdHkgbGV2ZWxzIGZvciBkaWZmZXJlbnQgYmFuZHdpZHRoIG9y IGRldmljZXMuIEhvd2V2ZSBob3cgdGhlIHNlcnZlciBpbiBwdXNoIG1vZGVsIG9yIGNsaWVudCBp biBwdWxsIG1vZGVsIGNhbiBxdWljayByZXNwb25zZSB0byB0aGUgPC9GT05UPjxGT05UIHNpemU9 NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmJpdHJhdGUgY2hhbmdlcyBpcyBhIHByb2JsZW0gd2Ug bWF5IGxvb2sgYXQsZXNwZWNpYWxseSB3aGVuIHN3aXRjaGluZyBiZXdlZW4gc3RyZWFtcyBvY2N1 cnMgdmVyeSBmcmVxdWVudGx5LjwvRk9OVD48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+ICAgLSBJ bXBvc3NpYmxlIHRvIGZhc3QtZm9yd2FyZCB0aHJvdWdoIGFueSBwYXJ0IG9mIGEgc3RyZWFtaW5n DQogICBjb250ZW50cyB1bnRpbCBpdCBpcyBzdG9yZWQgb24gdGhlIHVzZXIncyBkZXZpY2U8L1BS RT48UFJFIGNsYXNzPW5ld3BhZ2U+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2ZXRpY2E7 IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+TVc6IFRoaXMgaXMg c2ltcGx5IG5vdCBjb3JyZWN0LCBzaW5jZSB0aGVyZSBhcmUgaHVuZHJlZHMgb2YgZXhhbXBsZXMg b2YgZGV2aWNlcyB3aGljaCBzdXBwb3J0IHRyaWNrLXBsYXkgdXNpbmcgSFRUUCBzdHJlYW1pbmcg dGVjaG5pcXVlcyB3aXRob3V0IHN0b3JpbmcgdGhlIHdob2xlIGNvbnRlbnQgb24gdGhlIHVzZXJz IGRldmljZS48L1NQQU4+PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxTUEFOIHN0eWxlPSJGT05U LUZBTUlMWTogSGVsdmV0aWNhOyBXSElURS1TUEFDRTogbm9ybWFsIiBjbGFzcz1BcHBsZS1zdHls ZS1zcGFuPjxGT05UIHNpemU9NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBGYXN0IGZv cndhcmQgY2FwYWJpbHR5IGlzIG5vdCB0aGUgbW9zdCBpbXBvcnRhbnQgZmVhdHVyZSB3ZSBhcmUg bG9va2luZyBmb3IuIEhvd2V2ZXIgSSBhbSBoYXJkIHRvIGJlbGlldmUgZXhpc3RpbmcgSFRUUCBz dHJlYW1pbmcgdGVjaG5pcXVlcyBjYW4gcHJvdmlkZSB0aGUgc2FtZSBkZWdyZWUgb2YgcGxheWJh Y2s8L0ZPTlQ+PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogSGVsdmV0aWNhOyBXSElU RS1TUEFDRTogbm9ybWFsIiBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPjxGT05UIHNpemU9NCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPmNvbnRyb2wgdGhhdCBEVkQgcGxheWVyIGNhbiBwcm92aWRlcyBv ciBSVFNQIHByb3RvY29sIHByb3ZpZGVzLiBFLmcuLCBJbiB0aGUgYWRhcHRpdmUgSFRUUCBzdHJl YW1pbmcgYWxnb3JpdGhtcywgdGhlIHRyaWNrIHBsYXkgaXMgbGltaXRlZCB0byBwYXVzZS9yZXN1 bWUvc3RvcCBieSBkcml2aW5nIHRoZSBIVFRQIHJlcXVlc3QuIElmIHRoZSBjb250ZW50cyBoYXNu J3QgYmVlbiBkb3dsb2FkZWQgIGFuZCB0aGUgY29uc3VtZSB3YW50IGZhc3QgZm9yd2FyZCwgdGhl IEhUVFAgY2xpZW50IG5lZWRzIHRvIGlzc3VlIGFub3RoZXIgbmV3IEhUVFAgcmVxdWVzdCB0byBm ZXRjaCB0aGUgY29udGVudHMgd2hpY2ggd2lsbDwvRk9OVD48L1NQQU4+PFNQQU4gc3R5bGU9IkZP TlQtRkFNSUxZOiBIZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0 eWxlLXNwYW4+PEZPTlQgc2l6ZT00IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Y2F1c2UgdW5hY2Nl cHRhYmxlIGxhdGVuY3kgdG8gdGhlIGNvbnN1bWVyLjwvRk9OVD48L1NQQU4+PC9QUkU+PFBSRSBj bGFzcz1uZXdwYWdlPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogSGVsdmV0aWNhOyBXSElURS1T UEFDRTogbm9ybWFsIiBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPkEgZmlyc3Qgc3RlcCBpbiBjb25z aWRlcmluZyB3aGF0LCBpZiBhbnksIHdvcmsgc2hvdWxkIGJlIGRvbmUgaGVyZSBtaWdodCBiZSB0 byBjb250YWN0IHRob3NlIG9yZ2FuaXphdGlvbnMgd2hpY2ggYXJlIHN0YW5kYXJkaXppbmcgdGhl IGhpZ2hlciBsYXllcnMgb2YgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyAoZS5nLiBtYW5pZmVzdCBh bmQgZmlsZSBmb3JtYXRzKSBhbmQgYXNrIHdoZXRoZXIgdGhlcmUgYXJlIGRlZmljaWVuY2llcyB0 aGV5IHNlZSBpbiBJRVRGIHByb3RvY29scyB0aGF0IGNvdWxkIGJlIHVzZWZ1bGx5IGFkZHJlc3Nl ZCBieSB0aGUgSUVURi4gV2hhdCBJIHRoaW5rIHdlIHNob3VsZCBhdm9pZCBpbiB0aGUgSUVURiBp cyBkdXBsaWNhdGluZyB0aGUgd29yayBvZiB0aGVzZSBvdGhlciBib2RpZXMuPC9TUEFOPjwvUFJF PjxQUkUgY2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhlbHZldGljYTsg V0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj5CZXN0LDwvU1BBTj48 L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2ZXRp Y2E7IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+PEJSPjwvU1BB Tj48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2 ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+TWFyayBX YXRzb248L1NQQU4+PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIGNsYXNzPUFwcGxlLXN0 eWxlLXNwYW4gZmFjZT1IZWx2ZXRpY2E+PFNQQU4gc3R5bGU9IldISVRFLVNQQUNFOiBub3JtYWwi IGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+TmV0ZmxpeCBJbmMuPC9TUEFOPjwvRk9OVD48L1BSRT48 UFJFIGNsYXNzPW5ld3BhZ2U+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2ZXRpY2E7IFdI SVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+PEJSPjwvU1BBTj48L1BS RT48L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPjxC Uj4NCiAgPERJVj4NCiAgPERJVj5PbiBPY3QgMTAsIDIwMTAsIGF0IDEyOjQzIEFNLCBBbGkgQy4g QmVnZW4gKGFiZWdlbikgd3JvdGU6PC9ESVY+PEJSIA0KICBjbGFzcz1BcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lPg0KICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICA8RElWPjxCUj48QlI+ DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 QlI+PC9CTE9DS1FVT1RFPg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPkZyb206IDxBIA0K ICAgICAgaHJlZj0ibWFpbHRvOmh0dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9yZyI+aHR0cHN0 cmVhbWluZy1ib3VuY2VzQGlldGYub3JnPC9BPiANCiAgICAgIFttYWlsdG86aHR0cHN0cmVhbWlu Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFycyANCiAgICBFZ2dlcnQ8QlI+PC9C TE9DS1FVT1RFPg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPlNlbnQ6IEZyaWRheSwgT2N0 b2JlciAwOCwgMjAxMCA0OjE3IA0KICAgIFBNPEJSPjwvQkxPQ0tRVU9URT4NCiAgICA8QkxPQ0tR VU9URSB0eXBlPSJjaXRlIj5UbzogQ29saW4gUGVya2luczxCUj48L0JMT0NLUVVPVEU+DQogICAg PEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+Q2M6IDxBIA0KICAgICAgaHJlZj0ibWFpbHRvOmh0dHBz dHJlYW1pbmdAaWV0Zi5vcmciPmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8L0E+PEJSPjwvQkxPQ0tR VU9URT4NCiAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5TdWJqZWN0OiBSZTogW2h0dHBzdHJl YW1pbmddIEN1cnJlbnQgU3RhdHVzIGFuZCANCiAgICAgIE91ciBHb2FsPEJSPjwvQkxPQ0tRVU9U RT4NCiAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48QlI+PC9CTE9DS1FVT1RFPg0KICAgIDxC TE9DS1FVT1RFIHR5cGU9ImNpdGUiPk9uIDIwMTAtMTAtNywgYXQgMTQ6MTYsIENvbGluIFBlcmtp bnMgDQogICAgd3JvdGU6PEJSPjwvQkxPQ0tRVU9URT4NCiAgICA8QkxPQ0tRVU9URSB0eXBlPSJj aXRlIj4NCiAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPlRoZXJlIGFyZSBjbGVhcmx5IHNv bWUgaXNzdWVzIHRvIGNvbnNpZGVyIGhlcmUuIA0KICAgICAgICBXaGF0IHNlZW1zIHRvIGJlPEJS PjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+ DQogICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5taXNzaW5nIGZyb20gdGhlIGRpc2N1c3Np b24gdG8gbWUgdGhvdWdoLCBpcyANCiAgICAgICAgc29tZSBpZGVudGlmaWNhdGlvbiBvZjxCUj48 L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0K ICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+dGhlIGNvbmNyZXRlIHByb2JsZW1zLiBXaGF0 IHByb3RvY29sIHBpZWNlcyBkbyANCiAgICAgICAgd2UgbmVlZCwgYnV0IG5vdCBoYXZlPzxCUj48 L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0K ICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+V2hhdCBwcm90b2NvbHMgYXJlIHByb2JsZW1h dGljLCBhbmQgbmVlZCANCiAgICAgICAgZW5oYW5jZW1lbnQ/IElzIHRoZXJlPEJSPjwvQkxPQ0tR VU9URT48L0JMT0NLUVVPVEU+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICA8 QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5wcm90b2NvbCB3b3JrIHRvIGRvIGluIElFVEYsIG9yIHNo b3VsZCB3ZSBiZSANCiAgICAgICAgZG9jdW1lbnRpbmcgYmVzdCBjdXJyZW50PEJSPjwvQkxPQ0tR VU9URT48L0JMT0NLUVVPVEU+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICA8 QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5wcmFjdGljZXMgZm9yIHVzaW5nIHRoZSBleGlzdGluZyBw cm90b2NvbHMgDQogICAgICAgIGFuZC9vciByZWx5aW5nIG9uIG90aGVyPEJSPjwvQkxPQ0tRVU9U RT48L0JMT0NLUVVPVEU+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICA8QkxP Q0tRVU9URSB0eXBlPSJjaXRlIj5ib2RpZXMgdG8gZmlsbCB0aGUgDQogICAgZ2Fwcz88QlI+PC9C TE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAg ICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPjxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RF Pg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0i Y2l0ZSI+VGhlIGRyYWZ0LXd1LWh0dHAtc3RyZWFtaW5nLW9wdGltaXphdGlvbi1wcyBpcyBhIA0K ICAgICAgICBnb29kIHN0YXJ0IGF0IHN1Y2ggYW48QlI+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9U RT4NCiAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICAgIDxCTE9DS1FVT1RFIHR5cGU9 ImNpdGUiPmFuYWx5c2lzLCBidXQgZG9lc24ndCBnbyBkZWVwIGVub3VnaCB0byBsZXQgdXMgDQog ICAgICAgIGRlY2lkZSB3aGF0IHdvcmsgSUVURjxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RF Pg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0i Y2l0ZSI+c2hvdWxkIGRvLjxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgIDxCTE9D S1FVT1RFIHR5cGU9ImNpdGUiPjxCUj48L0JMT0NLUVVPVEU+DQogICAgPEJMT0NLUVVPVEUgdHlw ZT0iY2l0ZSI+KzE8QlI+PC9CTE9DS1FVT1RFPg0KICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUi PjxCUj48L0JMT0NLUVVPVEU+DQogICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+VGhlIGtleSBx dWVzdGlvbiByZWFsbHkgaXMgIndoYXQgZG8geW91IHRoaW5rIHRoZSANCiAgICAgIElFVEYgbmVl ZHMgdG8gZG8/IjxCUj48L0JMT0NLUVVPVEU+PEJSPkkgaW1hZ2luZSB0aGUgb25seSB3b3JrIHRo ZSBJRVRGIA0KICAgIHNob3VsZCBkbyAoaWYgd2UgZGVjaWRlIHRvKSBpcyB0aGUgdHJhbnNwb3J0 IGFuZCBIVFRQLWxheWVyIG9wdGltaXphdGlvbiBmb3IgDQogICAgYmV0dGVyIHN0cmVhbWluZyBw ZXJmb3JtYW5jZS48QlI+PEJSPi1hY2JlZ2VuPEJSPjxCUj4NCiAgICA8QkxPQ0tRVU9URSANCiAg ICB0eXBlPSJjaXRlIj5MYXJzPEJSPjwvQkxPQ0tRVU9URT5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5odHRwc3RyZWFtaW5nIA0KICAgIG1haWxpbmcg bGlzdDxCUj48QSANCiAgICBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+aHR0 cHN0cmVhbWluZ0BpZXRmLm9yZzwvQT48QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9odHRwc3RyZWFtaW5nPEJSPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PEJS PjwvRElWPg0KICA8UD4NCiAgPEhSPg0KDQogIDxQPjwvUD5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5odHRwc3RyZWFtaW5nIA0KICBtYWlsaW5nIA0K ICBsaXN0PEJSPmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5nPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9I VE1MPg0K --Boundary_(ID_VH3oDLYkI7UgpRjiPESEFA)-- From watsonm@netflix.com Mon Oct 11 09:50:31 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1D83A6867 for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 09:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.141 X-Spam-Level: X-Spam-Status: No, score=-3.141 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8nPwkOMsK2h for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 09:50:29 -0700 (PDT) Received: from mx1.netflix.com (mx1.netflix.com [208.75.77.144]) by core3.amsl.com (Postfix) with ESMTP id 325723A6822 for <httpstreaming@ietf.org>; Mon, 11 Oct 2010 09:50:29 -0700 (PDT) Received: from ExchFE101.netflix.com (exchfe101.netflix.com [10.64.32.101]) by mx1.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o9BGpTUY011995; Mon, 11 Oct 2010 09:51:29 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE101.netflix.com ([fe80::6861:6a26:831f:e8c9%14]) with mapi; Mon, 11 Oct 2010 09:51:23 -0700 From: Mark Watson <watsonm@netflix.com> To: Qin Wu <sunseawq@huawei.com> Date: Mon, 11 Oct 2010 09:50:35 -0700 Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActpZIjWeHkV9C7ES3aHpcCwmA7Nsw== Message-ID: <9062141B-82B8-4FF0-98C2-EB803BCA3DD7@netflix.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> <029d01cb693a$7f515f50$30298a0a@china.huawei.com> In-Reply-To: <029d01cb693a$7f515f50$30298a0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9062141B82B84FF098C2EB803BCA3DD7netflixcom_" MIME-Version: 1.0 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org>, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Oct 2010 16:50:31 -0000 --_000_9062141B82B84FF098C2EB803BCA3DD7netflixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSBjb21tZW50cyBvbmxpbmUgLi4uDQoNClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gT2N0 IDExLCAyMDEwLCBhdCA3OjUwIFBNLCAiUWluIFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbTxtYWls dG86c3Vuc2Vhd3FAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSwNClRoaXMgaXMgd2hhdCB3ZSBo YWQgZGlzY3Vzc2VkICBpbiB0aGUgRElTUEFUQ0ggbWFpbGluZyBsaXN0IGJlZm9yZSB3ZSBtb3Zl IHRvIHRoaXMgZGlzY3VzcyBsaXN0Lg0KSWYgeW91IGxvb2sgYXQgdGhlIGRlc2NyaXB0aW9uIG9m IGRpc2N1c3MgbGlzdCwgIg0Kb2ZmZXJzIG1vcmUgZWZmaWNpZW50IHRyYW5zcG9ydA0KYW5kIGJl dHRlciBuZXR3b3JrIGNhcGFiaWxpdHkgZm9yIHJlYWwgdGltZSBzdHJlYW1pbmcgbWVkaWENCmFu ZCBhbGxvd3MgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIG90aGVyIHN0cmVhbWluZyB0ZWNobmlxdWVz IGFuZCBleGlzdGluZyBQcm9ncmVzc2l2ZSBkb3dsb2FkZWQgYmFzZWQNCkhUVFAgc3RyZWFtaW5n IGltcGxlbWVudGF0aW9uLg0KIg0KeW91IHdpbGwgc2VlIHdlIGFyZSBvbiB0aGUgc2FtZSBwYWdl Lg0KVGhlcmVmb3JlIG9uZSBpbXBvcnRhbnQgZ29hbCBkaXNjdXNzZWQgaW4gdGhlIGRyYWZ0IGFp bXMgYXQgZGV2ZWxvcGluZyBpbnRlcm9wZXJhYmxlIHNvbHV0aW9uIHRvDQpwcm92aWRlIGJldHRl ciB0cmFuc3BvcnQgdG8gc2F0aXNmeSB0aGUgcmVhbCB0aW1lIHN0cmVhbWluZyBRT0UgcmVxdWly ZW1lbnQuIEVzcGVjaWFsbHkgc2VydmVyYWwNCmNoYW5sbGVuZ2VzL3Byb2JsZW1zIHdlIGV4cGxv cmVkIGluIHRoZSBkcmFmdCBsaXN0ZWQgYmVsb3cuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBNYXJrIFdhdHNvbjxtYWlsdG86d2F0c29ubUBu ZXRmbGl4LmNvbT4NClRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbik8bWFpbHRvOmFiZWdlbkBjaXNj by5jb20+DQpDYzogPG1haWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnPiBodHRwc3RyZWFtaW5n QGlldGYub3JnPG1haWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnPiA7IENvbGluIFBlcmtpbnM8 bWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnPg0KU2VudDogU3VuZGF5LCBPY3RvYmVyIDEwLCAyMDEw IDc6MTMgQU0NClN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5k IE91ciBHb2FsDQoNCkFsbCwNCg0KSSB3b3VsZCBsaWtlIHRvIGFkZCBteSBzdXBwb3J0IHRvIHRo ZSBjb21tZW50cyBiZWxvdy4gU3BlY2lmaWNhbGx5LCBJIHRoaW5rIGlmIHRoZSBJRVRGIGNvbnNp ZGVycyB3b3JrIGluIHRoaXMgYXJlYSBpdCBzaG91bGQgZm9jdXMgb24gdGhlIEhUVFAgYW5kIFRD UCBwcm90b2NvbHMuIEFueSBzdWNoIHdvcmsgbWF5IG5vdCBiZSBzcGVjaWZpYyB0byBIVFRQLXN0 cmVhbWluZyAoaS5lLiBlbmhhbmNlbWVudHMgdGhhdCBhcmUgYXQgZmlyc3QgbW90aXZhdGVkIGJ5 IEhUVFAgU3RyZWFtaW5nIG1heSBoYXZlIGJyb2FkZXIgYXBwbGljYWJpbGl0eSwgYW5kIHRoaXMg c2hvdWxkIGJlIGNhcmVmdWxseSBjb25zaWRlcmVkKS4NCg0KSW4gdGhlIGRyYWZ0IEkgZG8gbm90 IHNlZSBhIGNsZWFyIG9yIGNvcnJlY3QgaWRlbnRpZmljYXRpb24gb2YgdGhlIHByb2JsZW1zLiBG b3IgZXhhbXBsZSBpbiB0aGUgaW50cm9kdWN0aW9uIHRoZSBmb2xsb3dpbmcgYXJlIHN0YXRlZCBh cyBpc3N1ZXM6DQoNCiAgIC0gQ2xpZW50IHBvbGxpbmcgZm9yIGVhY2ggbmV3IGRhdGEgaW4gY2h1 bmtzIHVzaW5nIEhUVFAgcmVxdWVzdHMgaXMNCiAgIG5vdCBlZmZpY2llbnQgdG8gZGVsaXZlciBo aWdoLXF1YWxpdHkgdmlkZW8gY29udGVudCBhY3Jvc3MgdGhlDQogICBJbnRlcm5ldA0KDQpNVzog U2V2ZXJhbCBjb21wYW5pZXMsIGluY2x1ZGluZyBteSBlbXBsb3llciwgYXJlIHN1Y2Nlc3NmdWxs eSBvcGVyYXRpbmcgbGFyZ2Ugc2NhbGUgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyB0aGF0IGRvIGVm ZmljaWVudGx5IGRlbGl2ZXIgaGlnaC1xdWFsaXR5IHZpZGVvIGNvbnRlbnQgYWNyb3NzIHRoZSBJ bnRlcm5ldCwgc28gcmVhbGl0eSBzZWVtcyB0byByZWZ1dGUgdGhpcyBzdGF0ZW1lbnQuDQoNCltR aW5dOiBOb3Qgc3VyZSB0aGV5IGNhbiBwcm92aWRlIHRoZSBUViBleHBlcmllbmNlIGZvciBhbGwg dGhlIGNvbm5lY3RlZCBkZXZpY2VzIGxpa2Ugc21hcnRwaG9uZXMsIFBDcyBhbmQgdGFibGV0cy4g QWxzbyBub3Qgc3VyZSB0aGV5IGNhbiBwcm92aWRlIHRoZSBzYW1lIHF1YWxpdHkgb2YgZXhwZXJl bmNlIGZvciBhbGwgdGhlIGFsbCB0aGUgY29ubmVjdGVkIGRldmljZXMuIEFzIHdlIGRpc2N1c3Nl ZCBpbiB0aGlzIHRocmVhZCwgYSBtaW5pbXVtIG9mIDIwIHNlY29uZHMgdG8gc3RhcnQgeW91ciB2 aWRlbyBvZnRlbiBmcnVzdHJhdGVkIHVzZXJzIHRvIGtlZXAgb24gd2F0Y2hpbmcgYW5kIHByb3Zp ZGUgdmVyeSBsaW1pdGVkIHVzZXIgZXhwZXJpZW5jZS4NCg0KQ2FuIHlvdSBiZSBtb3JlIGV4cGxp Y2l0IGFib3V0IHRoZSBwcm9ibGVtcyB0aGF0IHlvdSBzZWU/IEknbSBub3Qgc3VyZSB3aGVyZSB0 aGUgMjBzIGZpZ3VyZSBjb21lcyBmcm9tLiBJIGRvIG5vdCBzZWUgYW55IHByb2JsZW0gaW4gc3Vw cG9ydGluZyBzdGFydHVwIHRpbWVzIGNvbXBhcmFibGUgdG8gVFYgY2hhbm5lbCBjaGFuZ2Ugd2l0 aCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZy4NCg0KSSBhbSBub3Qgc2F5aW5nIHRoZXJlIGlzIG5v IHJvb20gZm9yIGltcHJvdmVtZW50IGluIHRoZSB2YXJpb3VzIGRlcGxveWVkIHN5c3RlbXMsIGJ1 dCBJIGRvIG5vdCBzZWUgbWFqb3IgdGVjaG5pY2FsIGltcGVkaW1lbnRzIHRvIGVmZmljaWVudCBk ZWxpdmVyeSBvZiBoaWdoIHF1YWxpdHkgdmlkZW8gdXNpbmcgSFRUUCBTdHJlYW1pbmcuDQoNCk9u IHRoZSBvdGhlciBoYW5kLCBJIHRoaW5rIHdlIHNob3VsZCBiZWFyIGluIG1pbmQgSFRUUCBpcyBm b3JtZXJseSBkZXNpZ25lZCBmb3IgYnJvd3Npbmcgd2VicGFnZSwgdHJhbnNwb3J0IHN0YXRpYyBj b250ZW50cyBsaWtlIEhUTUwgcGFnZSwgcGx1Z2luLCBwaWN0dXJlLCB3aGVuIHdlIGFyZSBnb2lu ZyB0byB1c2UgSFRUUCB0byBkZWxpdmVyIHJlYWwgdGltZSBzdHJlYW1pbmcgY29udGVudHMsIHdl IGNhbiBub3QgZXhwZWN0IHRvIGdldCBoaWdoZXIgdXNlciBleHBlcmllbmNlLiBUaGVyZWZvcmUg dGhlIGN1cnJlbnQgc3RyZWFtaW5nIHNjaGVtZXMgY2FuIG9ubHkgb2ZmZXIgYSBiZXR0ZXIgZXhw ZXJpZW5jZSBvdmVyIHNsb3dlciBjb25uZWN0aW9ucy4NCg0KICAgLSBTZWdtZW50YXRpb24gY2Fw YWJpbGl0eSByZXF1aXJlcyBvdmVyLXV0aWxpemluZyBDUFUgYW5kIGJhbmR3aWR0aA0KICAgcmVz b3VyY2VzLCB3aGljaCBtYXkgbm90IGJlIGEgZGVzaXJhYmxlIGFuZCBlZmZlY3RpdmUgd2F5IHRv IGltcHJvdmUNCiAgIHRoZSBxdWFsaXR5IG9mIHN0cmVhbWluZyBtZWRpYSBkZWxpdmVyeQ0KDQpN VzogSXQgaXMgbm90IGNsZWFyIHRoYXQgc2VnbWVudGF0aW9uIHBlciBzZSBpcyBDUFUtaW50ZW5z aXZlIG9yIGhhcyBhbnkgbm9uLW5lZ2xpZ2FibGUgZWZmZWN0IG9uIGJhbmR3aWR0aCB1c2FnZS4N Cg0KW1Fpbl06IFNpbmNlIEhUVFAgc3RyZWFtaW5nIHNlcnZlciBpcyB0aGUgY29tYmluYXRpb24g b2Ygc3RyZWFtaW5nIHNlcnZlciBhbmQgcmVndWxhciB3ZWIgc2VydmVyLCBJIHRoaW5rIHRoZSBh bnN3ZXIgaXMgYm90aC4NCg0KW01XXSB3aGF0IGRvIHlvdSBtZWFuIGJ5JyBodHRwIHN0cmVhbWlu ZyBzZXJ2ZXInID8NCg0KICAgLSBMYWNrIG9mIFFvUyBndWFyYW50ZWUgb24gdGhlIHBhY2tldCBz d2l0Y2hpbmcgYmFzZWQgSW50ZXJuZXQgLCB0aGUNCiAgIHF1YWxpdHkgb2YgSW50ZXJuZXQgbWVk aWEgc3RyZWFtaW5nIG1heSBzaWduaWZpY2FudCBkZWdyYWRlIGR1ZSB0bw0KICAgcmlzaW5nIHVz YWdlDQoNCk1XOiBBbiBhbHRlcm5hdGl2ZSB2aWV3IGlzIHRoYXQgd2hlcmUgcXVhbGl0eSBpcyBk ZWdyYWRlZCBkdWUgdG8gY29uZ2VzdGlvbiB0aGlzIGlzIGR1ZSB0byBsYWNrIG9mIGJhbmR3aWR0 aCwgcmF0aGVyIHRoYW4gYSBsYWNrIG9mIFFvUyBndWFyYW50ZWVzLiBBZGFwdGl2ZSBIVFRQIHN0 cmVhbWluZyBzeXN0ZW1zIGFkanVzdCB0aGUgdmlkZW8gcXVhbGl0eSB0byB0aGUgYXZhaWxhYmxl IGJhbmR3aWR0aCBpbiBvcmRlciB0byBhdm9pZCByZWJ1ZmZlcmluZyBldmVudHMuIEl0IGlzIHRo ZSBhdmFpbGFibGUgYmFuZHdpZHRoIHRoYXQgbmVlZHMgdG8gYmUgaW1wcm92ZWQgdG8gaW1wcm92 ZSBxdWFsaXR5Lg0KDQpbUWluXTogV2hhdCBJIGVtcGhhc2l6ZSBoZXJlIGlzIHdpdGggZ3Jvd2lu ZyBwb3B1bGFyaXR5IG9mIEhUVFAgc3RyZWFtaW5nIHRyYWZmaWMsIHdoZW4gdGhvdXNhbmRzIG9y IG1pbGxpb25zIG9mIHBlb3BsZSBhcmUgYWNjZXNzaW5nIHRoZSBzYW1lIG1lZGlhIGNvbnRlbnRz LCB0aGUgYmlnIHByb2JsZW0gd2UgYXJlIGZhY2luZyBpcyBzZXJpb3VzIGhpZ2ggY29uY3VycmVu Y2UgYWNjZXNzIGlzc3VlLiBUaGUgdXNlciBleHBlcmllbmNlIHdpbGwgYmUgZ3JlYXRseSBhZmZl Y3RlZCBldmVuIHlvdSBoYXZlIGVub3VnaCBhdmFpbGFibGUgYmFuZHdpZHRoLiBTbyB0aGlzIGlz IG5vdCBwdXJlIGJhbmR3aWR0aCBpc3N1ZS4NCg0KW01XXSBtYXliZSB3ZSBtZWFuIGRpZmZlcmVu dCB0aGluZ3MgYnkgJ2F2YWlsYWJsZSBiYW5kd2lkdGgnLiBEbyB5b3UgdGhpbmsgaXQgaXMgYSBz ZXJ2ZXIgc2NhbGFiaWxpdHkgcHJvYmxlbSwgb3IgYSBuZXR3b3JrIHByb2JsZW0gPw0KDQogICAt IEV4cGVyaWVuY2UgYnVyc3RpbmVzcyBvciBvdGhlciBkeW5hbWljcyBjaGFuZ2VzIGR1ZSB0byBi YW5kd2lkdGgNCiAgIGZsdWN0dWF0aW9ucyBhbmQgaGV0ZXJvZ2VuZW91cyBoYW5kb3Zlci4NCg0K TVc6IFdlIGhhdmUgZm91bmQgdGhhdCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyBhbGdvcml0aG1z IGFyZSB3ZWxsIGFibGUgdG8gY29wZSB3aXRoIGJhbmR3aWR0aCBmbHVjdHVhdGlvbnMuDQoNCltR aW5dOiBJIGRvbid0IGRvdWJ0IHRoYXQgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGht cyBjYW4gY29wZSB3aXRoIGJhbmR3aWR0aCBmbHVjdGF0aW9uLiBCdXQgSSBob3BlIHdlIGNhbiBk byBiZXR0ZXIuZS5nLiwgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBvbmx5IHN1 cHBvcnQgZGVsaXZlcnkgb2YgbXVsdGlwbGUgc3RyZWFtcyBvZiB0aGUgc2FtZSBjb250ZW50IHdp dGggdmFyeWluZyBxdWFsaXR5IGxldmVscyBmb3IgZGlmZmVyZW50IGJhbmR3aWR0aCBvciBkZXZp Y2VzLiBIb3dldmUgaG93IHRoZSBzZXJ2ZXIgaW4gcHVzaCBtb2RlbCBvciBjbGllbnQgaW4gcHVs bCBtb2RlbCBjYW4gcXVpY2sgcmVzcG9uc2UgdG8gdGhlIGJpdHJhdGUgY2hhbmdlcyBpcyBhIHBy b2JsZW0gd2UgbWF5IGxvb2sgYXQsZXNwZWNpYWxseSB3aGVuIHN3aXRjaGluZyBiZXdlZW4gc3Ry ZWFtcyBvY2N1cnMgdmVyeSBmcmVxdWVudGx5Lg0KDQpbTVddIFllcywgYnV0IG5vdCBhIHByb2Js ZW0gZm9yIHRoZSBJRVRGLCBJIHRoaW5rLg0KDQogICAtIEltcG9zc2libGUgdG8gZmFzdC1mb3J3 YXJkIHRocm91Z2ggYW55IHBhcnQgb2YgYSBzdHJlYW1pbmcNCiAgIGNvbnRlbnRzIHVudGlsIGl0 IGlzIHN0b3JlZCBvbiB0aGUgdXNlcidzIGRldmljZQ0KDQpNVzogVGhpcyBpcyBzaW1wbHkgbm90 IGNvcnJlY3QsIHNpbmNlIHRoZXJlIGFyZSBodW5kcmVkcyBvZiBleGFtcGxlcyBvZiBkZXZpY2Vz IHdoaWNoIHN1cHBvcnQgdHJpY2stcGxheSB1c2luZyBIVFRQIHN0cmVhbWluZyB0ZWNobmlxdWVz IHdpdGhvdXQgc3RvcmluZyB0aGUgd2hvbGUgY29udGVudCBvbiB0aGUgdXNlcnMgZGV2aWNlLg0K DQpbUWluXTogRmFzdCBmb3J3YXJkIGNhcGFiaWx0eSBpcyBub3QgdGhlIG1vc3QgaW1wb3J0YW50 IGZlYXR1cmUgd2UgYXJlIGxvb2tpbmcgZm9yLiBIb3dldmVyIEkgYW0gaGFyZCB0byBiZWxpZXZl IGV4aXN0aW5nIEhUVFAgc3RyZWFtaW5nIHRlY2huaXF1ZXMgY2FuIHByb3ZpZGUgdGhlIHNhbWUg ZGVncmVlIG9mIHBsYXliYWNrY29udHJvbCB0aGF0IERWRCBwbGF5ZXIgY2FuIHByb3ZpZGVzIG9y IFJUU1AgcHJvdG9jb2wgcHJvdmlkZXMuIEUuZy4sIEluIHRoZSBhZGFwdGl2ZSBIVFRQIHN0cmVh bWluZyBhbGdvcml0aG1zLCB0aGUgdHJpY2sgcGxheSBpcyBsaW1pdGVkIHRvIHBhdXNlL3Jlc3Vt ZS9zdG9wIGJ5IGRyaXZpbmcgdGhlIEhUVFAgcmVxdWVzdC4gSWYgdGhlIGNvbnRlbnRzIGhhc24n dCBiZWVuIGRvd2xvYWRlZCAgYW5kIHRoZSBjb25zdW1lIHdhbnQgZmFzdCBmb3J3YXJkLCB0aGUg SFRUUCBjbGllbnQgbmVlZHMgdG8gaXNzdWUgYW5vdGhlciBuZXcgSFRUUCByZXF1ZXN0IHRvIGZl dGNoIHRoZSBjb250ZW50cyB3aGljaCB3aWxsY2F1c2UgdW5hY2NlcHRhYmxlIGxhdGVuY3kgdG8g dGhlIGNvbnN1bWVyLg0KDQpbTVddIEFnYWluLCB0aGUgZXhwZXJpZW5jZSBvZiBtaWxsaW9ucyBv ZiBleGlzdGluZyBjdXN0b21lcnMgcmVmdXRlcyB3aGF0IHlvdSBjbGFpbS4gV2h5IGRvIHlvdSB0 aGluayBpdCBpcyBuZWNlc3NhcmlseSBzbyBzbG93IHRvIGlzc3VlIGEgbmV3IEhUVFAgcmVxdWVz dCBmb3IgYSBkaWZmZXJlbnQgcGFydCBvZiB0aGUgY29udGVudD8NCg0KDQpBIGZpcnN0IHN0ZXAg aW4gY29uc2lkZXJpbmcgd2hhdCwgaWYgYW55LCB3b3JrIHNob3VsZCBiZSBkb25lIGhlcmUgbWln aHQgYmUgdG8gY29udGFjdCB0aG9zZSBvcmdhbml6YXRpb25zIHdoaWNoIGFyZSBzdGFuZGFyZGl6 aW5nIHRoZSBoaWdoZXIgbGF5ZXJzIG9mIEhUVFAgc3RyZWFtaW5nIHN5c3RlbXMgKGUuZy4gbWFu aWZlc3QgYW5kIGZpbGUgZm9ybWF0cykgYW5kIGFzayB3aGV0aGVyIHRoZXJlIGFyZSBkZWZpY2ll bmNpZXMgdGhleSBzZWUgaW4gSUVURiBwcm90b2NvbHMgdGhhdCBjb3VsZCBiZSB1c2VmdWxseSBh ZGRyZXNzZWQgYnkgdGhlIElFVEYuIFdoYXQgSSB0aGluayB3ZSBzaG91bGQgYXZvaWQgaW4gdGhl IElFVEYgaXMgZHVwbGljYXRpbmcgdGhlIHdvcmsgb2YgdGhlc2Ugb3RoZXIgYm9kaWVzLg0KDQpC ZXN0LA0KDQoNCk1hcmsgV2F0c29uDQoNCk5ldGZsaXggSW5jLg0KDQoNCg0KDQpPbiBPY3QgMTAs IDIwMTAsIGF0IDEyOjQzIEFNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogPG1haWx0bzpodHRwc3RyZWFtaW5nLWJv dW5jZXNAaWV0Zi5vcmc+IGh0dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aHR0 cHN0cmVhbWluZy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmh0dHBzdHJlYW1pbmctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhcnMgRWdnZXJ0DQpTZW50OiBGcmlkYXksIE9jdG9i ZXIgMDgsIDIwMTAgNDoxNyBQTQ0KVG86IENvbGluIFBlcmtpbnMNCkNjOiA8bWFpbHRvOmh0dHBz dHJlYW1pbmdAaWV0Zi5vcmc+IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8bWFpbHRvOmh0dHBzdHJl YW1pbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQgU3Rh dHVzIGFuZCBPdXIgR29hbA0KDQpPbiAyMDEwLTEwLTcsIGF0IDE0OjE2LCBDb2xpbiBQZXJraW5z IHdyb3RlOg0KVGhlcmUgYXJlIGNsZWFybHkgc29tZSBpc3N1ZXMgdG8gY29uc2lkZXIgaGVyZS4g V2hhdCBzZWVtcyB0byBiZQ0KbWlzc2luZyBmcm9tIHRoZSBkaXNjdXNzaW9uIHRvIG1lIHRob3Vn aCwgaXMgc29tZSBpZGVudGlmaWNhdGlvbiBvZg0KdGhlIGNvbmNyZXRlIHByb2JsZW1zLiBXaGF0 IHByb3RvY29sIHBpZWNlcyBkbyB3ZSBuZWVkLCBidXQgbm90IGhhdmU/DQpXaGF0IHByb3RvY29s cyBhcmUgcHJvYmxlbWF0aWMsIGFuZCBuZWVkIGVuaGFuY2VtZW50PyBJcyB0aGVyZQ0KcHJvdG9j b2wgd29yayB0byBkbyBpbiBJRVRGLCBvciBzaG91bGQgd2UgYmUgZG9jdW1lbnRpbmcgYmVzdCBj dXJyZW50DQpwcmFjdGljZXMgZm9yIHVzaW5nIHRoZSBleGlzdGluZyBwcm90b2NvbHMgYW5kL29y IHJlbHlpbmcgb24gb3RoZXINCmJvZGllcyB0byBmaWxsIHRoZSBnYXBzPw0KDQpUaGUgZHJhZnQt d3UtaHR0cC1zdHJlYW1pbmctb3B0aW1pemF0aW9uLXBzIGlzIGEgZ29vZCBzdGFydCBhdCBzdWNo IGFuDQphbmFseXNpcywgYnV0IGRvZXNuJ3QgZ28gZGVlcCBlbm91Z2ggdG8gbGV0IHVzIGRlY2lk ZSB3aGF0IHdvcmsgSUVURg0Kc2hvdWxkIGRvLg0KDQorMQ0KDQpUaGUga2V5IHF1ZXN0aW9uIHJl YWxseSBpcyAid2hhdCBkbyB5b3UgdGhpbmsgdGhlIElFVEYgbmVlZHMgdG8gZG8/Ig0KDQpJIGlt YWdpbmUgdGhlIG9ubHkgd29yayB0aGUgSUVURiBzaG91bGQgZG8gKGlmIHdlIGRlY2lkZSB0bykg aXMgdGhlIHRyYW5zcG9ydCBhbmQgSFRUUC1sYXllciBvcHRpbWl6YXRpb24gZm9yIGJldHRlciBz dHJlYW1pbmcgcGVyZm9ybWFuY2UuDQoNCi1hY2JlZ2VuDQoNCkxhcnMNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpodHRwc3RyZWFtaW5nIG1haWxpbmcg bGlzdA0KPG1haWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnPmh0dHBzdHJlYW1pbmdAaWV0Zi5v cmc8bWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmcNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpodHRwc3RyZWFtaW5nIG1haWxpbmcgbGlzdA0KaHR0cHN0cmVhbWluZ0BpZXRmLm9y ZzxtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaHR0cHN0cmVhbWluZw0K --_000_9062141B82B84FF098C2EB803BCA3DD7netflixcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5Tb21lIGNvbW1lbnRzIG9ubGluZSAu Li48YnI+PGJyPlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48ZGl2Pjxicj5PbiBPY3QgMTEsIDIw MTAsIGF0IDc6NTAgUE0sICJRaW4gV3UiICZsdDs8YSBocmVmPSJtYWlsdG86c3Vuc2Vhd3FAaHVh d2VpLmNvbSI+c3Vuc2Vhd3FAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+ PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KDQo8ZGl2PkhpLDwvZGl2 Pg0KPGRpdj5UaGlzIGlzIHdoYXQgd2UgaGFkIGRpc2N1c3NlZCZuYnNwOyBpbiB0aGUgRElTUEFU Q0ggbWFpbGluZyBsaXN0IGJlZm9yZSB3ZSANCm1vdmUgdG8gdGhpcyBkaXNjdXNzIGxpc3QuPC9k aXY+DQo8ZGl2PklmIHlvdSBsb29rIGF0IHRoZSBkZXNjcmlwdGlvbiBvZiBkaXNjdXNzIGxpc3Qs ICI8L2Rpdj4NCjxkaXY+b2ZmZXJzIG1vcmUgZWZmaWNpZW50IHRyYW5zcG9ydCA8YnI+YW5kIGJl dHRlciBuZXR3b3JrIGNhcGFiaWxpdHkgZm9yIHJlYWwgDQp0aW1lIHN0cmVhbWluZyBtZWRpYTxi cj5hbmQgYWxsb3dzIGludGVyb3BlcmFiaWxpdHkgd2l0aCBvdGhlciBzdHJlYW1pbmcgDQp0ZWNo bmlxdWVzIGFuZCBleGlzdGluZyBQcm9ncmVzc2l2ZSBkb3dsb2FkZWQgYmFzZWQ8YnI+SFRUUCBz dHJlYW1pbmcgDQppbXBsZW1lbnRhdGlvbi48L2Rpdj4NCjxkaXY+IjwvZGl2Pg0KPGRpdj55b3Ug d2lsbCZuYnNwO3NlZSB3ZSBhcmUgb24gdGhlIHNhbWUgcGFnZS48L2Rpdj4NCjxkaXY+VGhlcmVm b3JlIG9uZSZuYnNwO2ltcG9ydGFudCBnb2FsIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQmbmJzcDth aW1zIA0KYXQmbmJzcDtkZXZlbG9waW5nIGludGVyb3BlcmFibGUgc29sdXRpb24gdG8gPC9kaXY+ DQo8ZGl2PnByb3ZpZGUgYmV0dGVyIHRyYW5zcG9ydCB0byBzYXRpc2Z5IHRoZSByZWFsIHRpbWUg c3RyZWFtaW5nIFFPRSANCnJlcXVpcmVtZW50LiBFc3BlY2lhbGx5Jm5ic3A7c2VydmVyYWw8L2Rp dj4NCjxkaXY+Y2hhbmxsZW5nZXMvcHJvYmxlbXMmbmJzcDt3ZSBleHBsb3JlZCBpbiB0aGUgZHJh ZnQgbGlzdGVkIGJlbG93LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+UmVnYXJkcyE8 L2Rpdj4NCjxkaXY+LVFpbjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiAj MDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsg TUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8ZGl2IHN0eWxlPSJGT05U OiA5cHQg5a6L5L2TIj4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvZGl2Pg0KICA8ZGl2 IHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TOyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9y OiBibGFjayI+PGI+RnJvbTo8L2I+IA0KICA8YSB0aXRsZT0id2F0c29ubUBuZXRmbGl4LmNvbSIg aHJlZj0ibWFpbHRvOndhdHNvbm1AbmV0ZmxpeC5jb20iPk1hcmsgV2F0c29uPC9hPiANCiAgPC9k aXY+DQogIDxkaXYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxiPlRvOjwvYj4gPGEgdGl0bGU9 ImFiZWdlbkBjaXNjby5jb20iIGhyZWY9Im1haWx0bzphYmVnZW5AY2lzY28uY29tIj5BbGkgQy4g QmVnZW4gKGFiZWdlbik8L2E+IDwvZGl2Pg0KICA8ZGl2IHN0eWxlPSJGT05UOiA5cHQg5a6L5L2T Ij48Yj5DYzo8L2I+IDxhIHRpdGxlPSJodHRwc3RyZWFtaW5nQGlldGYub3JnIiBocmVmPSJtYWls dG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOmh0dHBzdHJlYW1pbmdA aWV0Zi5vcmciPmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8L2E+PC9hPiA7IDxhIHRpdGxlPSJjc3BA Y3NwZXJraW5zLm9yZyIgaHJlZj0ibWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnIj5Db2xpbiBQZXJr aW5zPC9hPiANCiAgPC9kaXY+DQogIDxkaXYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxiPlNl bnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMTAsIDIwMTAgNzoxMyBBTTwvZGl2Pg0KICA8ZGl2IHN0 eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtodHRwc3RyZWFtaW5n XSBDdXJyZW50IFN0YXR1cyANCiAgYW5kIE91ciBHb2FsPC9kaXY+DQogIDxkaXY+PGJyPjwvZGl2 PkFsbCwNCiAgPGRpdj48YnI+PC9kaXY+DQogIDxkaXY+SSB3b3VsZCBsaWtlIHRvIGFkZCBteSBz dXBwb3J0IHRvIHRoZSBjb21tZW50cyBiZWxvdy4gU3BlY2lmaWNhbGx5LCBJIA0KICB0aGluayBp ZiB0aGUgSUVURiBjb25zaWRlcnMgd29yayBpbiB0aGlzIGFyZWEgaXQgc2hvdWxkIGZvY3VzIG9u IHRoZSBIVFRQIGFuZCANCiAgVENQIHByb3RvY29scy4gQW55IHN1Y2ggd29yayBtYXkgbm90IGJl IHNwZWNpZmljIHRvIEhUVFAtc3RyZWFtaW5nIChpLmUuIA0KICBlbmhhbmNlbWVudHMgdGhhdCBh cmUgYXQgZmlyc3QgbW90aXZhdGVkIGJ5IEhUVFAgU3RyZWFtaW5nIG1heSBoYXZlIGJyb2FkZXIg DQogIGFwcGxpY2FiaWxpdHksIGFuZCB0aGlzIHNob3VsZCBiZSBjYXJlZnVsbHkgY29uc2lkZXJl ZCkuPC9kaXY+DQogIDxkaXY+PGJyPjwvZGl2Pg0KICA8ZGl2PkluIHRoZSBkcmFmdCBJIGRvIG5v dCBzZWUgYSBjbGVhciBvciBjb3JyZWN0IGlkZW50aWZpY2F0aW9uIG9mIHRoZSANCiAgcHJvYmxl bXMuIEZvciBleGFtcGxlIGluIHRoZSBpbnRyb2R1Y3Rpb24gdGhlIGZvbGxvd2luZyBhcmUgc3Rh dGVkIGFzIA0KICBpc3N1ZXM6PC9kaXY+DQogIDxkaXY+PHByZSBjbGFzcz0ibmV3cGFnZSI+ICAg LSBDbGllbnQgcG9sbGluZyBmb3IgZWFjaCBuZXcgZGF0YSBpbiBjaHVua3MgdXNpbmcgSFRUUCBy ZXF1ZXN0cyBpcw0KICAgbm90IGVmZmljaWVudCB0byBkZWxpdmVyIGhpZ2gtcXVhbGl0eSB2aWRl byBjb250ZW50IGFjcm9zcyB0aGUNCiAgIEludGVybmV0PGJyPjwvcHJlPjxwcmUgY2xhc3M9Im5l d3BhZ2UiPjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJIZWx2ZXRpY2EiPk1X OiBTZXZlcmFsIGNvbXBhbmllcywgaW5jbHVkaW5nIG15IGVtcGxveWVyLCBhcmUgc3VjY2Vzc2Z1 bGx5IG9wZXJhdGluZyBsYXJnZSBzY2FsZSBIVFRQIHN0cmVhbWluZyBzeXN0ZW1zIHRoYXQgZG8g ZWZmaWNpZW50bHkgZGVsaXZlciBoaWdoLXF1YWxpdHkgdmlkZW8gY29udGVudCBhY3Jvc3MgdGhl IEludGVybmV0LCBzbyByZWFsaXR5IHNlZW1zIHRvIHJlZnV0ZSB0aGlzIHN0YXRlbWVudC48L2Zv bnQ+PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+PGZvbnQgc2l6ZT0iNCI+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj5bUWluXTogTm90IHN1cmUgdGhleSBjYW4gcHJvdmlkZSB0aGUgVFYg ZXhwZXJpZW5jZSBmb3IgYWxsIHRoZSBjb25uZWN0ZWQgZGV2aWNlcyBsaWtlIHNtYXJ0cGhvbmVz LCBQQ3MgYW5kIHRhYmxldHMuIEFsc28gbm90IHN1cmUgdGhleSBjYW4gcHJvdmlkZSB0aGUgc2Ft ZSBxdWFsaXR5IG9mIGV4cGVyZW5jZSBmb3IgYWxsIHRoZSBhbGwgdGhlIGNvbm5lY3RlZCBkZXZp Y2VzLiBBcyB3ZSBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQsIGEgbWluaW11bSBvZiAyMCBzZWNv bmRzIHRvIHN0YXJ0IHlvdXIgdmlkZW8gb2Z0ZW4gZnJ1c3RyYXRlZCB1c2VycyB0byBrZWVwIG9u IHdhdGNoaW5nIGFuZCBwcm92aWRlIHZlcnkgbGltaXRlZCB1c2VyIGV4cGVyaWVuY2UuPC9mb250 PjwvZm9udD48L3ByZT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+ Q2FuIHlvdSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRoZSBwcm9ibGVtcyB0aGF0IHlvdSBzZWU/ IEknbSZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iLXdlYmtpdC10 YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdlYmtpdC1j b21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdl YmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5 KTsgIj5ub3Qgc3VyZSB3aGVyZSB0aGUgMjBzIGZpZ3VyZSBjb21lcyBmcm9tLiBJIGRvIG5vdCBz ZWUgYW55IHByb2JsZW0gaW4gc3VwcG9ydGluZyBzdGFydHVwIHRpbWVzIGNvbXBhcmFibGUgdG8g VFYgY2hhbm5lbCBjaGFuZ2Ugd2l0aCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZy48L3NwYW4+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGFtIG5vdCBzYXlpbmcgdGhlcmUgaXMgbm8gcm9vbSBm b3IgaW1wcm92ZW1lbnQgaW4gdGhlIHZhcmlvdXMgZGVwbG95ZWQgc3lzdGVtcywgYnV0IEkgZG8g bm90IHNlZSBtYWpvciB0ZWNobmljYWwgaW1wZWRpbWVudHMgdG8gZWZmaWNpZW50IGRlbGl2ZXJ5 IG9mIGhpZ2ggcXVhbGl0eSB2aWRlbyB1c2luZyBIVFRQIFN0cmVhbWluZy48YnI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+PGRpdj48YmxvY2txdW90ZSBzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAw MDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJH SU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+PGRpdj48cHJlIGNsYXNzPSJuZXdwYWdl Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxmb250IHNpemU9IjQiPk9uIHRoZSBvdGhl ciBoYW5kLCBJIHRoaW5rIHdlIHNob3VsZCBiZWFyIGluIG1pbmQgSFRUUCBpcyBmb3JtZXJseSBk ZXNpZ25lZCBmb3IgYnJvd3Npbmcgd2VicGFnZSwgdHJhbnNwb3J0IHN0YXRpYyBjb250ZW50cyBs aWtlIEhUTUwgcGFnZSwgcGx1Z2luLCBwaWN0dXJlLCB3aGVuIHdlIGFyZSBnb2luZyB0byB1c2Ug PC9mb250Pjxmb250IHNpemU9IjQiPkhUVFAgdG8gZGVsaXZlciByZWFsIHRpbWUgc3RyZWFtaW5n IGNvbnRlbnRzLCB3ZSBjYW4gbm90IGV4cGVjdCB0byBnZXQgaGlnaGVyIHVzZXIgZXhwZXJpZW5j ZS4gPC9mb250Pjxmb250IHNpemU9IjMiPjxzdHJvbmc+VGhlcmVmb3JlIHRoZSBjdXJyZW50PC9z dHJvbmc+IDxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpF OiAxMnB0OyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog5a6L5L2TOyBtc28tYW5zaS1sYW5ndWFn ZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6 IEFSLVNBIiBsYW5nPSJFTi1VUyI+PHN0cm9uZz5zdHJlYW1pbmcgc2NoZW1lcyBjYW4gb25seSBv ZmZlciBhIGJldHRlciBleHBlcmllbmNlIG92ZXIgc2xvd2VyIGNvbm5lY3Rpb25zLjwvc3Ryb25n Pjwvc3Bhbj48L2ZvbnQ+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPiAgIC0gU2Vn bWVudGF0aW9uIGNhcGFiaWxpdHkgcmVxdWlyZXMgb3Zlci11dGlsaXppbmcgQ1BVIGFuZCBiYW5k d2lkdGgNCiAgIHJlc291cmNlcywgd2hpY2ggbWF5IG5vdCBiZSBhIGRlc2lyYWJsZSBhbmQgZWZm ZWN0aXZlIHdheSB0byBpbXByb3ZlDQogICB0aGUgcXVhbGl0eSBvZiBzdHJlYW1pbmcgbWVkaWEg ZGVsaXZlcnk8L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5 bGUtc3BhbiIgZmFjZT0iSGVsdmV0aWNhIj5NVzogSXQgaXMgbm90IGNsZWFyIHRoYXQgc2VnbWVu dGF0aW9uIHBlciBzZSBpcyBDUFUtaW50ZW5zaXZlIG9yIGhhcyBhbnkgbm9uLW5lZ2xpZ2FibGUg ZWZmZWN0IG9uIGJhbmR3aWR0aCB1c2FnZS48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFn ZSI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bUWluXTogU2luY2UgSFRU UCBzdHJlYW1pbmcgc2VydmVyIGlzIHRoZSBjb21iaW5hdGlvbiBvZiBzdHJlYW1pbmcgc2VydmVy IGFuZCByZWd1bGFyIHdlYiBzZXJ2ZXIsIEkgdGhpbmsgdGhlIGFuc3dlciBpcyBib3RoLjwvZm9u dD48L3ByZT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv ZGl2PltNV10gd2hhdCBkbyB5b3UgbWVhbiBieScgaHR0cCBzdHJlYW1pbmcgc2VydmVyJyA/PGJy PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1M RUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6 IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPjxkaXY+PHByZSBjbGFz cz0ibmV3cGFnZSI+ICAgLSBMYWNrIG9mIFFvUyBndWFyYW50ZWUgb24gdGhlIHBhY2tldCBzd2l0 Y2hpbmcgYmFzZWQgSW50ZXJuZXQgLCB0aGUNCiAgIHF1YWxpdHkgb2YgSW50ZXJuZXQgbWVkaWEg c3RyZWFtaW5nIG1heSBzaWduaWZpY2FudCBkZWdyYWRlIGR1ZSB0bw0KICAgcmlzaW5nIHVzYWdl PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4i IGZhY2U9IkhlbHZldGljYSI+TVc6IEFuIGFsdGVybmF0aXZlIHZpZXcgaXMgdGhhdCB3aGVyZSBx dWFsaXR5IGlzIGRlZ3JhZGVkIGR1ZSB0byBjb25nZXN0aW9uIHRoaXMgaXMgZHVlIHRvIGxhY2sg b2YgYmFuZHdpZHRoLCByYXRoZXIgdGhhbiBhIGxhY2sgb2YgUW9TIGd1YXJhbnRlZXMuIEFkYXB0 aXZlIEhUVFAgc3RyZWFtaW5nIHN5c3RlbXMgYWRqdXN0IHRoZSB2aWRlbyBxdWFsaXR5IHRvIHRo ZSBhdmFpbGFibGUgYmFuZHdpZHRoIGluIG9yZGVyIHRvIGF2b2lkIHJlYnVmZmVyaW5nIGV2ZW50 cy4gSXQgaXMgdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggdGhhdCBuZWVkcyB0byBiZSBpbXByb3Zl ZCB0byBpbXByb3ZlIHF1YWxpdHkuPC9mb250PjwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxm b250IGZhY2U9IkhlbHZldGljYSI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij5bUWluXTogV2hhdCBJIGVtcGhhc2l6ZSBoZXJlIGlzIHdpdGggZ3Jvd2luZyBwb3B1bGFyaXR5 IG9mIEhUVFAgc3RyZWFtaW5nIHRyYWZmaWMsIHdoZW4gdGhvdXNhbmRzIG9yIG1pbGxpb25zIG9m IHBlb3BsZSBhcmUgYWNjZXNzaW5nIHRoZSBzYW1lIG1lZGlhIGNvbnRlbnRzLCB0aGUgYmlnIHBy b2JsZW0gd2UgYXJlIGZhY2luZyBpcyBzZXJpb3VzIGhpZ2ggY29uY3VycmVuY2UgYWNjZXNzIGlz c3VlLiBUaGUgdXNlciBleHBlcmllbmNlIHdpbGwgYmUgZ3JlYXRseSBhZmZlY3RlZCBldmVuIHlv dSBoYXZlIGVub3VnaCBhdmFpbGFibGUgYmFuZHdpZHRoLiBTbyB0aGlzIGlzIG5vdCBwdXJlIGJh bmR3aWR0aCBpc3N1ZS48L2ZvbnQ+PC9mb250PjwvcHJlPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+W01XXSBtYXliZSB3ZSBtZWFuIGRpZmZlcmVu dCB0aGluZ3MgYnkgJ2F2YWlsYWJsZSBiYW5kd2lkdGgnLiBEbyB5b3UgdGhpbmsgaXQgaXMgYSBz ZXJ2ZXIgc2NhbGFiaWxpdHkgcHJvYmxlbSwgb3IgYSBuZXR3b3JrIHByb2JsZW0gPzxicj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDog IzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7 IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij48ZGl2PjxwcmUgY2xhc3M9Im5l d3BhZ2UiPiAgIC0gRXhwZXJpZW5jZSBidXJzdGluZXNzIG9yIG90aGVyIGR5bmFtaWNzIGNoYW5n ZXMgZHVlIHRvIGJhbmR3aWR0aA0KICAgZmx1Y3R1YXRpb25zIGFuZCBoZXRlcm9nZW5lb3VzIGhh bmRvdmVyLjwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxmb250IGNsYXNzPSJBcHBsZS1zdHls ZS1zcGFuIiBmYWNlPSJIZWx2ZXRpY2EiPk1XOiBXZSBoYXZlIGZvdW5kIHRoYXQgYWRhcHRpdmUg SFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBhcmUgd2VsbCBhYmxlIHRvIGNvcGUgd2l0aCBiYW5k d2lkdGggZmx1Y3R1YXRpb25zLiA8L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+PGZv bnQgc2l6ZT0iNCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bUWluXTogSSBkb24ndCBkb3VidCB0 aGF0IGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRobXMgY2FuIGNvcGUgd2l0aCBiYW5k d2lkdGggZmx1Y3RhdGlvbi4gQnV0IEkgaG9wZSB3ZSBjYW4gZG8gYmV0dGVyLjwvZm9udD48Zm9u dCBzaXplPSI0IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmUuZy4sIGFkYXB0aXZlIEhUVFAgc3Ry ZWFtaW5nIGFsZ29yaXRobXMgb25seSBzdXBwb3J0IGRlbGl2ZXJ5IG9mIG11bHRpcGxlIHN0cmVh bXMgb2YgdGhlIHNhbWUgY29udGVudCB3aXRoIHZhcnlpbmcgcXVhbGl0eSBsZXZlbHMgZm9yIGRp ZmZlcmVudCBiYW5kd2lkdGggb3IgZGV2aWNlcy4gSG93ZXZlIGhvdyB0aGUgc2VydmVyIGluIHB1 c2ggbW9kZWwgb3IgY2xpZW50IGluIHB1bGwgbW9kZWwgY2FuIHF1aWNrIHJlc3BvbnNlIHRvIHRo ZSA8L2ZvbnQ+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5iaXRyYXRlIGNo YW5nZXMgaXMgYSBwcm9ibGVtIHdlIG1heSBsb29rIGF0LGVzcGVjaWFsbHkgd2hlbiBzd2l0Y2hp bmcgYmV3ZWVuIHN0cmVhbXMgb2NjdXJzIHZlcnkgZnJlcXVlbnRseS48L2ZvbnQ+PC9wcmU+PC9k aXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj5bTVddIFll cywgYnV0IG5vdCBhIHByb2JsZW0gZm9yIHRoZSBJRVRGLCBJIHRoaW5rLjxicj48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAw MCAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJ Ti1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij48ZGl2PjxwcmUgY2xhc3M9Im5ld3BhZ2Ui PiAgIC0gSW1wb3NzaWJsZSB0byBmYXN0LWZvcndhcmQgdGhyb3VnaCBhbnkgcGFydCBvZiBhIHN0 cmVhbWluZw0KICAgY29udGVudHMgdW50aWwgaXQgaXMgc3RvcmVkIG9uIHRoZSB1c2VyJ3MgZGV2 aWNlPC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+TVc6IFRoaXMgaXMgc2ltcGx5IG5vdCBjb3Jy ZWN0LCBzaW5jZSB0aGVyZSBhcmUgaHVuZHJlZHMgb2YgZXhhbXBsZXMgb2YgZGV2aWNlcyB3aGlj aCBzdXBwb3J0IHRyaWNrLXBsYXkgdXNpbmcgSFRUUCBzdHJlYW1pbmcgdGVjaG5pcXVlcyB3aXRo b3V0IHN0b3JpbmcgdGhlIHdob2xlIGNvbnRlbnQgb24gdGhlIHVzZXJzIGRldmljZS48L3ByZT48 cHJlIGNsYXNzPSJuZXdwYWdlIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhlbHZldGljYTsg V0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iPjxmb250IHNpemU9 IjQiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W1Fpbl06IEZhc3QgZm9yd2FyZCBjYXBhYmlsdHkg aXMgbm90IHRoZSBtb3N0IGltcG9ydGFudCBmZWF0dXJlIHdlIGFyZSBsb29raW5nIGZvci4gSG93 ZXZlciBJIGFtIGhhcmQgdG8gYmVsaWV2ZSBleGlzdGluZyBIVFRQIHN0cmVhbWluZyB0ZWNobmlx dWVzIGNhbiBwcm92aWRlIHRoZSBzYW1lIGRlZ3JlZSBvZiBwbGF5YmFjazwvZm9udD48L3NwYW4+ PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWwi IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIj48Zm9udCBzaXplPSI0IiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPmNvbnRyb2wgdGhhdCBEVkQgcGxheWVyIGNhbiBwcm92aWRlcyBvciBSVFNQIHByb3Rv Y29sIHByb3ZpZGVzLiBFLmcuLCBJbiB0aGUgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3Jp dGhtcywgdGhlIHRyaWNrIHBsYXkgaXMgbGltaXRlZCB0byBwYXVzZS9yZXN1bWUvc3RvcCBieSBk cml2aW5nIHRoZSBIVFRQIHJlcXVlc3QuIElmIHRoZSBjb250ZW50cyBoYXNuJ3QgYmVlbiBkb3ds b2FkZWQgIGFuZCB0aGUgY29uc3VtZSB3YW50IGZhc3QgZm9yd2FyZCwgdGhlIEhUVFAgY2xpZW50 IG5lZWRzIHRvIGlzc3VlIGFub3RoZXIgbmV3IEhUVFAgcmVxdWVzdCB0byBmZXRjaCB0aGUgY29u dGVudHMgd2hpY2ggd2lsbDwvZm9udD48L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiBI ZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIj48 Zm9udCBzaXplPSI0IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmNhdXNlIHVuYWNjZXB0YWJsZSBs YXRlbmN5IHRvIHRoZSBjb25zdW1lci48L2ZvbnQ+PC9zcGFuPjwvcHJlPjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj5bTVddIEFnYWluLCB0aGUgZXhwZXJpZW5jZSBv ZiBtaWxsaW9ucyBvZiBleGlzdGluZyBjdXN0b21lcnMgcmVmdXRlcyB3aGF0IHlvdSBjbGFpbS4g V2h5IGRvIHlvdSB0aGluayBpdCBpcyBuZWNlc3NhcmlseSBzbyBzbG93IHRvIGlzc3VlIGEgbmV3 IEhUVFAgcmVxdWVzdCBmb3IgYSBkaWZmZXJlbnQgcGFydCBvZiB0aGUgY29udGVudD88L2Rpdj48 YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48YmxvY2txdW90ZSBzdHlsZT0iQk9SREVS LUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdI VDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+PGRpdj48cHJlIGNs YXNzPSJuZXdwYWdlIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhlbHZldGljYTsgV0hJVEUt U1BBQ0U6IG5vcm1hbCIgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iPkEgZmlyc3Qgc3RlcCBpbiBj b25zaWRlcmluZyB3aGF0LCBpZiBhbnksIHdvcmsgc2hvdWxkIGJlIGRvbmUgaGVyZSBtaWdodCBi ZSB0byBjb250YWN0IHRob3NlIG9yZ2FuaXphdGlvbnMgd2hpY2ggYXJlIHN0YW5kYXJkaXppbmcg dGhlIGhpZ2hlciBsYXllcnMgb2YgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyAoZS5nLiBtYW5pZmVz dCBhbmQgZmlsZSBmb3JtYXRzKSBhbmQgYXNrIHdoZXRoZXIgdGhlcmUgYXJlIGRlZmljaWVuY2ll cyB0aGV5IHNlZSBpbiBJRVRGIHByb3RvY29scyB0aGF0IGNvdWxkIGJlIHVzZWZ1bGx5IGFkZHJl c3NlZCBieSB0aGUgSUVURi4gV2hhdCBJIHRoaW5rIHdlIHNob3VsZCBhdm9pZCBpbiB0aGUgSUVU RiBpcyBkdXBsaWNhdGluZyB0aGUgd29yayBvZiB0aGVzZSBvdGhlciBib2RpZXMuPC9zcGFuPjwv cHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogSGVsdmV0 aWNhOyBXSElURS1TUEFDRTogbm9ybWFsIiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiI+QmVzdCw8 L3NwYW4+PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ OiBIZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu Ij48YnI+PC9zcGFuPjwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxzcGFuIHN0eWxlPSJGT05U LUZBTUlMWTogSGVsdmV0aWNhOyBXSElURS1TUEFDRTogbm9ybWFsIiBjbGFzcz0iQXBwbGUtc3R5 bGUtc3BhbiI+TWFyayBXYXRzb248L3NwYW4+PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+PGZv bnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkhlbHZldGljYSI+PHNwYW4gc3R5bGU9 IldISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIj5OZXRmbGl4IElu Yy48L3NwYW4+PC9mb250PjwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxzcGFuIHN0eWxlPSJG T05ULUZBTUlMWTogSGVsdmV0aWNhOyBXSElURS1TUEFDRTogbm9ybWFsIiBjbGFzcz0iQXBwbGUt c3R5bGUtc3BhbiI+PGJyPjwvc3Bhbj48L3ByZT48L2Rpdj4NCiAgPGRpdj48YnI+PC9kaXY+DQog IDxkaXY+PGJyPjwvZGl2Pg0KICA8ZGl2Pjxicj4NCiAgPGRpdj4NCiAgPGRpdj5PbiBPY3QgMTAs IDIwMTAsIGF0IDEyOjQzIEFNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6PC9kaXY+PGJy IGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCiAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQogICAgPGRpdj48YnI+PGJyPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPjwvYmxvY2txdW90ZT4NCiAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5Gcm9tOiA8YSBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZy1ib3VuY2Vz QGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZy1ib3VuY2VzQGlldGYub3Jn Ij5odHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PC9hPiANCiAgICAgIFttYWlsdG86 aHR0cHN0cmVhbWluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFycyANCiAgICBF Z2dlcnQ8YnI+PC9ibG9ja3F1b3RlPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlNlbnQ6 IEZyaWRheSwgT2N0b2JlciAwOCwgMjAxMCA0OjE3IA0KICAgIFBNPGJyPjwvYmxvY2txdW90ZT4N CiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5UbzogQ29saW4gUGVya2luczxicj48L2Jsb2Nr cXVvdGU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+Q2M6IDxhIGhyZWY9Im1haWx0bzpo dHRwc3RyZWFtaW5nQGlldGYub3JnIj48YSBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRm Lm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvYT48L2E+PGJyPjwvYmxvY2txdW90ZT4NCiAg ICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5TdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1 cnJlbnQgU3RhdHVzIGFuZCANCiAgICAgIE91ciBHb2FsPGJyPjwvYmxvY2txdW90ZT4NCiAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3RlPg0KICAgIDxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPk9uIDIwMTAtMTAtNywgYXQgMTQ6MTYsIENvbGluIFBlcmtpbnMgDQogICAg d3JvdGU6PGJyPjwvYmxvY2txdW90ZT4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAg ICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlRoZXJlIGFyZSBjbGVhcmx5IHNvbWUgaXNzdWVz IHRvIGNvbnNpZGVyIGhlcmUuIA0KICAgICAgICBXaGF0IHNlZW1zIHRvIGJlPGJyPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5taXNzaW5nIGZyb20gdGhlIGRpc2N1c3Npb24gdG8gbWUg dGhvdWdoLCBpcyANCiAgICAgICAgc29tZSBpZGVudGlmaWNhdGlvbiBvZjxicj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+dGhlIGNvbmNyZXRlIHByb2JsZW1zLiBXaGF0IHByb3RvY29s IHBpZWNlcyBkbyANCiAgICAgICAgd2UgbmVlZCwgYnV0IG5vdCBoYXZlPzxicj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+V2hhdCBwcm90b2NvbHMgYXJlIHByb2JsZW1hdGljLCBhbmQg bmVlZCANCiAgICAgICAgZW5oYW5jZW1lbnQ/IElzIHRoZXJlPGJyPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5wcm90b2NvbCB3b3JrIHRvIGRvIGluIElFVEYsIG9yIHNob3VsZCB3ZSBi ZSANCiAgICAgICAgZG9jdW1lbnRpbmcgYmVzdCBjdXJyZW50PGJyPjwvYmxvY2txdW90ZT48L2Js b2NrcXVvdGU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj5wcmFjdGljZXMgZm9yIHVzaW5nIHRoZSBleGlzdGluZyBwcm90b2NvbHMg DQogICAgICAgIGFuZC9vciByZWx5aW5nIG9uIG90aGVyPGJyPjwvYmxvY2txdW90ZT48L2Jsb2Nr cXVvdGU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQogICAgICA8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj5ib2RpZXMgdG8gZmlsbCB0aGUgDQogICAgZ2Fwcz88YnI+PC9ibG9ja3F1b3Rl PjwvYmxvY2txdW90ZT4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgIDxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPg0KICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGhl IGRyYWZ0LXd1LWh0dHAtc3RyZWFtaW5nLW9wdGltaXphdGlvbi1wcyBpcyBhIA0KICAgICAgICBn b29kIHN0YXJ0IGF0IHN1Y2ggYW48YnI+PC9ibG9ja3F1b3RlPjwvYmxvY2txdW90ZT4NCiAgICA8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPmFu YWx5c2lzLCBidXQgZG9lc24ndCBnbyBkZWVwIGVub3VnaCB0byBsZXQgdXMgDQogICAgICAgIGRl Y2lkZSB3aGF0IHdvcmsgSUVURjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPg0KICAgIDxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+c2hv dWxkIGRvLjxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPg0KICAgIDxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ KzE8YnI+PC9ibG9ja3F1b3RlPg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Js b2NrcXVvdGU+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGhlIGtleSBxdWVzdGlvbiBy ZWFsbHkgaXMgIndoYXQgZG8geW91IHRoaW5rIHRoZSANCiAgICAgIElFVEYgbmVlZHMgdG8gZG8/ Ijxicj48L2Jsb2NrcXVvdGU+PGJyPkkgaW1hZ2luZSB0aGUgb25seSB3b3JrIHRoZSBJRVRGIA0K ICAgIHNob3VsZCBkbyAoaWYgd2UgZGVjaWRlIHRvKSBpcyB0aGUgdHJhbnNwb3J0IGFuZCBIVFRQ LWxheWVyIG9wdGltaXphdGlvbiBmb3IgDQogICAgYmV0dGVyIHN0cmVhbWluZyBwZXJmb3JtYW5j ZS48YnI+PGJyPi1hY2JlZ2VuPGJyPjxicj4NCiAgICA8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5M YXJzPGJyPjwvYmxvY2txdW90ZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj5odHRwc3RyZWFtaW5nIA0KICAgIG1haWxpbmcgbGlzdDxicj48YSBocmVm PSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+PGEgaHJlZj0ibWFpbHRvOmh0dHBzdHJl YW1pbmdAaWV0Zi5vcmciPmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8L2E+PC9hPjxicj48YSBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmciPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cHN0cmVhbWluZzwvYT48YnI+ PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+DQogIDxwPg0KICA8L3A+PGhy Pg0KDQogIDxwPjwvcD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj5odHRwc3RyZWFtaW5nIA0KICBtYWlsaW5nIA0KICBsaXN0PGJyPjxhIGhyZWY9Im1h aWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnIj5odHRwc3RyZWFtaW5nQGlldGYub3JnPC9hPjxi cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmc8YnI+ PC9ibG9ja3F1b3RlPg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_9062141B82B84FF098C2EB803BCA3DD7netflixcom_-- From abegen@cisco.com Mon Oct 11 17:08:24 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8763A689A for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 17:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fnrilb0dCif for <httpstreaming@core3.amsl.com>; Mon, 11 Oct 2010 17:08:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 459593A6877 for <httpstreaming@ietf.org>; Mon, 11 Oct 2010 17:08:23 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADZEs0yrR7Ht/2dsb2JhbACiDnGmVJ0ChUgEhFKIeA X-IronPort-AV: E=Sophos;i="4.57,317,1283731200"; d="scan'208";a="602503836" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 12 Oct 2010 00:09:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9C09aT7015006; Tue, 12 Oct 2010 00:09:36 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Oct 2010 17:09:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Oct 2010 17:09:30 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> In-Reply-To: <017101cb6924$bc093410$30298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActpJMHG2Gw62HaITA2VhStIs4LzGAAfFfxA References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Qin Wu" <sunseawq@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> X-OriginalArrivalTime: 12 Oct 2010 00:09:36.0156 (UTC) FILETIME=[C1296DC0:01CB69A1] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Oct 2010 00:08:24 -0000 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Monday, October 11, 2010 5:15 AM > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > Hi,: > ----- Original Message ----- > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> > Cc: <httpstreaming@ietf.org> > Sent: Sunday, October 10, 2010 12:46 AM > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Friday, October 08, 2010 4:16 PM > > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > > Cc: httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > also a need for video synchronization to start rendering. > > > > Synchronization among the viewers you mean? That could be a concern = but seriously, since client implementations will > > differ, network capacities will differ, i.e., pretty much everything = will differ for different clients, I don't think there is a > > solution to this. Better said, I don't think there is a problem. > > > > [Qin] I think Synchronization between the server and the client is = one issue we may look at. Since the server has buffer for > > encoding, the client has a buffer for playout, we definitely need = one streaming media synchronization mechanism which > may > > help reduce delay. >=20 > Sorry, I don=92t get this. Server or someone else advertises what is = available to the client and client fetches whatever it wants > (and is available). Why is there a need for synchronization here? >=20 > [Qin]: We may look at two different use cases: push model and pull = model > In the pull model, you are right. The client control the timing of = fetching the chunks by driving the HTTP request. It only > request it needs and can handle. However client based pull is = characterized > as polling for new data each time and is not efficient way to deliver = the real time streaming contents. By polling I suppose you mean sending HTTP requests. Well, that is = pretty much implied by using HTTP, which is a request-response protocol = and this makes HTTP as stateless as possible. And IMO sending individual = requests offer more advantages than disadvantages. > In the push model, the client does not know when the conents is = available at the server. For the client will not send request > for each chunks. the client clock is easy to asynchronize with encoder = clock. Well the server can push the content (in a push model) but it still is = dependent on the client implementation to determine what to do with that = content. One implementation, if it wants, can start playing it 10 hours = later for all we care. I still don't get what you are trying to do here. -acbegen From zongning@huawei.com Tue Oct 12 05:15:29 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4833A690C for <httpstreaming@core3.amsl.com>; Tue, 12 Oct 2010 05:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG7prwKFNwrM for <httpstreaming@core3.amsl.com>; Tue, 12 Oct 2010 05:15:28 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A60EC3A6909 for <httpstreaming@ietf.org>; Tue, 12 Oct 2010 05:15:23 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA6008RSFCIYG@szxga04-in.huawei.com> for httpstreaming@ietf.org; Tue, 12 Oct 2010 20:14:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA6006RDFCI9U@szxga04-in.huawei.com> for httpstreaming@ietf.org; Tue, 12 Oct 2010 20:14:42 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA6007QRFCIR7@szxml04-in.huawei.com> for httpstreaming@ietf.org; Tue, 12 Oct 2010 20:14:42 +0800 (CST) Date: Tue, 12 Oct 2010 20:14:42 +0800 From: Ning Zong <zongning@huawei.com> To: httpstreaming@ietf.org Message-id: <00bc01cb6a07$0d1079d0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: ActqBwyp7S2suN5cREK2hslyPgUK0g== Subject: [httpstreaming] HTTP streaming bar BoF poll X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 12 Oct 2010 12:15:29 -0000 Hi, folks, We are planning to hold a non-official-IETF workshop (a.k.a. bar BoF) during the incoming Beijing meeting to discuss HTTP streaming. Main purpose will be to discuss the potential work in IETF about HTTP streaming, review the current arts in various SDOs, Web application providers, software vendors in this area. We will try to work out a concrete working scope of HTTP streaming in IETF. As well as enjoy food and drink, and have fun... If you are interested in participating this workshop, please feed back your available time in the following Doodle poll link: http://doodle.com/86ifrv5i9i9g7trp Your quick response is highly appreciated so that we can have more time to sort out the logistic things. Note that the evening time in the poll is normally from 7:30PM to 9:00PM since Monday, Wednesday, and Thursday afternoon are all occupied by sessions and plenary until 7:30PM according to current IETF agenda. And I suspect the Tuesday evening might be reserved for social. If you have any better idea about the bar BoF arrangement, please send to the list. Thanks! BR, Ning Zong From sunseawq@huawei.com Wed Oct 13 23:20:14 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D47793A68C4 for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.944 X-Spam-Level: X-Spam-Status: No, score=0.944 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVFz9eYCriBl for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:20:06 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 998573A685B for <httpstreaming@ietf.org>; Wed, 13 Oct 2010 23:20:01 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA900B0YOB9MY@szxga04-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:21:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA900JHXOB9Z0@szxga04-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:21:09 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA900JH4OB81Y@szxml06-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:21:09 +0800 (CST) Date: Thu, 14 Oct 2010 14:21:08 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 06:20:15 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsaSBDLiBCZWdlbiAo YWJlZ2VuKSIgPGFiZWdlbkBjaXNjby5jb20+DQpUbzogIlFpbiBXdSIgPHN1bnNlYXdxQGh1YXdl aS5jb20+OyAiUm9uaSBFdmVuIiA8RXZlbi5yb25pQGh1YXdlaS5jb20+OyAiRGF2aWQgQS4gQnJ5 YW4iIDxkYnJ5YW5AZXRoZXJub3Qub3JnPg0KQ2M6IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0K U2VudDogVHVlc2RheSwgT2N0b2JlciAxMiwgMjAxMCA4OjA5IEFNDQpTdWJqZWN0OiBSRTogW2h0 dHBzdHJlYW1pbmddIEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFpbiBXdSBbbWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5j b21dDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMSwgMjAxMCA1OjE1IEFNDQo+IFRvOiBBbGkg Qy4gQmVnZW4gKGFiZWdlbik7IFJvbmkgRXZlbjsgRGF2aWQgQS4gQnJ5YW4NCj4gQ2M6IGh0dHBz dHJlYW1pbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50 IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4gDQo+IEhpLDoNCj4gLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQ0KPiBGcm9tOiAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNpc2NvLmNv bT4NCj4gVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPjsgIlJvbmkgRXZlbiIgPEV2 ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJyeWFuIiA8ZGJyeWFuQGV0aGVybm90Lm9y Zz4NCj4gQ2M6IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0KPiBTZW50OiBTdW5kYXksIE9jdG9i ZXIgMTAsIDIwMTAgMTI6NDYgQU0NCj4gU3ViamVjdDogUkU6IFtodHRwc3RyZWFtaW5nXSBDdXJy ZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4gDQo+IA0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBRaW4gV3UgW21haWx0bzpzdW5zZWF3cUBodWF3ZWku Y29tXQ0KPiA+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAwOCwgMjAxMCA0OjE2IFBNDQo+ID4gVG86 IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTsgUm9uaSBFdmVuOyBEYXZpZCBBLiBCcnlhbg0KPiA+IENj OiBodHRwc3RyZWFtaW5nQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5n XSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4gPg0KPiA+ID4gYWxzbyBhIG5lZWQgZm9y IHZpZGVvIHN5bmNocm9uaXphdGlvbiB0byBzdGFydCByZW5kZXJpbmcuDQo+ID4NCj4gPiBTeW5j aHJvbml6YXRpb24gYW1vbmcgdGhlIHZpZXdlcnMgeW91IG1lYW4/IFRoYXQgY291bGQgYmUgYSBj b25jZXJuIGJ1dCBzZXJpb3VzbHksIHNpbmNlIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgd2lsbA0K PiA+IGRpZmZlciwgbmV0d29yayBjYXBhY2l0aWVzIHdpbGwgZGlmZmVyLCBpLmUuLCBwcmV0dHkg bXVjaCBldmVyeXRoaW5nIHdpbGwgZGlmZmVyIGZvciBkaWZmZXJlbnQgY2xpZW50cywgSSBkb24n dCB0aGluayB0aGVyZSBpcyBhDQo+ID4gc29sdXRpb24gdG8gdGhpcy4gQmV0dGVyIHNhaWQsIEkg ZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSBwcm9ibGVtLg0KPiA+DQo+ID4gW1Fpbl0gSSB0aGluayBT eW5jaHJvbml6YXRpb24gYmV0d2VlbiB0aGUgc2VydmVyIGFuZCB0aGUgY2xpZW50IGlzIG9uZSBp c3N1ZSB3ZSBtYXkgbG9vayBhdC4gU2luY2UgdGhlIHNlcnZlciBoYXMgYnVmZmVyIGZvcg0KPiA+ IGVuY29kaW5nLCB0aGUgY2xpZW50IGhhcyBhIGJ1ZmZlciBmb3IgcGxheW91dCwgd2UgZGVmaW5p dGVseSBuZWVkIG9uZSBzdHJlYW1pbmcgbWVkaWEgc3luY2hyb25pemF0aW9uIG1lY2hhbmlzbSB3 aGljaA0KPiBtYXkNCj4gPiBoZWxwIHJlZHVjZSBkZWxheS4NCj4gDQo+IFNvcnJ5LCBJIGRvbpJ0 IGdldCB0aGlzLiBTZXJ2ZXIgb3Igc29tZW9uZSBlbHNlIGFkdmVydGlzZXMgd2hhdCBpcyBhdmFp bGFibGUgdG8gdGhlIGNsaWVudCBhbmQgY2xpZW50IGZldGNoZXMgd2hhdGV2ZXIgaXQgd2FudHMN Cj4gKGFuZCBpcyBhdmFpbGFibGUpLiBXaHkgaXMgdGhlcmUgYSBuZWVkIGZvciBzeW5jaHJvbml6 YXRpb24gaGVyZT8NCj4gDQo+IFtRaW5dOiBXZSBtYXkgbG9vayBhdCB0d28gZGlmZmVyZW50ICB1 c2UgY2FzZXM6IHB1c2ggbW9kZWwgYW5kIHB1bGwgbW9kZWwNCj4gSW4gdGhlIHB1bGwgbW9kZWws IHlvdSBhcmUgcmlnaHQuIFRoZSBjbGllbnQgIGNvbnRyb2wgdGhlIHRpbWluZyBvZiBmZXRjaGlu ZyB0aGUgY2h1bmtzIGJ5IGRyaXZpbmcgdGhlIEhUVFAgcmVxdWVzdC4gSXQgb25seQ0KPiByZXF1 ZXN0IGl0IG5lZWRzIGFuZCBjYW4gaGFuZGxlLiBIb3dldmVyICBjbGllbnQgYmFzZWQgcHVsbCBp cyBjaGFyYWN0ZXJpemVkDQo+IGFzIHBvbGxpbmcgZm9yIG5ldyBkYXRhIGVhY2ggdGltZSBhbmQg aXMgbm90IGVmZmljaWVudCB3YXkgdG8gZGVsaXZlciB0aGUgcmVhbCB0aW1lIHN0cmVhbWluZyBj b250ZW50cy4NCg0KQnkgcG9sbGluZyBJIHN1cHBvc2UgeW91IG1lYW4gc2VuZGluZyBIVFRQIHJl cXVlc3RzLiBXZWxsLCB0aGF0IGlzIHByZXR0eSBtdWNoIGltcGxpZWQgYnkgdXNpbmcgSFRUUCwg d2hpY2ggaXMgYSByZXF1ZXN0LXJlc3BvbnNlIHByb3RvY29sIGFuZCB0aGlzIG1ha2VzIEhUVFAg YXMgc3RhdGVsZXNzIGFzIHBvc3NpYmxlLiBBbmQgSU1PIHNlbmRpbmcgaW5kaXZpZHVhbCByZXF1 ZXN0cyBvZmZlciBtb3JlIGFkdmFudGFnZXMgdGhhbiBkaXNhZHZhbnRhZ2VzLg0KDQpbUWluXTog U3VwcG9zZSB0ZW4gY2h1bmtzIGFyZSBhdmFpbGFibGUgYXQgdGhlIHNlcnZlciwgdGhlIGNsaWVu dCBpbiBwdWxsIG1vZGVsIE1VU1Qgc2VuZCB0ZW4gcmVxdWVzdHMgdG8gZmV0Y2ggYWxsIHRoZSBj aHVua3MgYW5kIHNlcnZlciBzaG91bGQgYW5zd2VyIHdpdGggdGVuIHJlc3BvbnNlIHdpdGggZWFj aCBjaHVuay4NCmhvd2V2ZXIgaW4gdGhlIHB1c2ggbW9kZWwsIEkgdGhpbmsgdGhlIGNsaWVudCBv bmx5IG5lZWQgdG8gaW5pdGlhdGUgb25lIHJlcXVlc3QgYW5kIHRoZW4gdGhlIHNlcnZlciBjb250 cm9sIHRlbiBjaHVua3MgZGVsaXZlcnkgYW5kIHB1c2ggdGVuIGNodW5rcyB0byB0aGUgY2xpZW50 IG9uZSBieSBvbmUuDQogSXNuJ3QgdGhlIHB1c2ggbW9kZWwgbW9yZSBlZmZpY2llbnQgdGhhbiBw dWxsIG1vZGVsIGZyb20gdHJhbnNwb3J0IHBlcnNwZWN0aXZlPw0KDQo+IEluIHRoZSBwdXNoIG1v ZGVsLCB0aGUgY2xpZW50IGRvZXMgbm90IGtub3cgd2hlbiB0aGUgY29uZW50cyBpcyBhdmFpbGFi bGUgYXQgdGhlIHNlcnZlci4gRm9yIHRoZSBjbGllbnQgd2lsbCBub3Qgc2VuZCByZXF1ZXN0DQo+ IGZvciBlYWNoIGNodW5rcy4gdGhlIGNsaWVudCBjbG9jayBpcyBlYXN5IHRvIGFzeW5jaHJvbml6 ZSB3aXRoIGVuY29kZXIgY2xvY2suDQoNCldlbGwgdGhlIHNlcnZlciBjYW4gcHVzaCB0aGUgY29u dGVudCAoaW4gYSBwdXNoIG1vZGVsKSBidXQgaXQgc3RpbGwgaXMgZGVwZW5kZW50IG9uIHRoZSBj bGllbnQgaW1wbGVtZW50YXRpb24gdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gd2l0aCB0aGF0IGNv bnRlbnQuIE9uZSBpbXBsZW1lbnRhdGlvbiwgaWYgaXQgd2FudHMsIGNhbiBzdGFydCBwbGF5aW5n IGl0IDEwIGhvdXJzIGxhdGVyIGZvciBhbGwgd2UgY2FyZS4gSSBzdGlsbCBkb24ndCBnZXQgd2hh dCB5b3UgYXJlIHRyeWluZyB0byBkbyBoZXJlLg0KDQpbUWluXTogSW4gdGhlIHB1c2ggbW9kZWws IHRoZSBzZXJ2ZXIgZGlkbid0IGtub3cgdGhlIGNsaWVudCBjYXBhYmlsaXR5IHRvIGNvbnN1bWUg c3RyZWFtaW5nIGRhdGEsIGkuZS4sIHRoZSBzZXJ2ZXIgZGlkbid0IGtub3cgaG93IGZhc3QgdGhl IGNsaWVudCBwcm9jZXNzIGxpdmUgc3RyZWFtaW5nLiBJZiB0aGUgZW5jb2RpbmcgcmF0ZSBhdCB0 aGUgc2VydmVyIGlzIGZhc3RlciB0aGFuIGNvbXN1aW5nIHJhdGUgYXQgdGhlIGNsaWVudCwgdGhl IGJ1ZmZlciB3aWxsIG92ZXJmbG93LiBJZiB0aGUgZW5jb2RpbmcgcmF0ZSBhdCB0aGUgc2VydmVy IGlzIHNsb3dlciB0aGFuIGNvbXN1aW5nIHJhdGUgYXQgdGhlIGNsaWVudCwgdGhlIGJ1ZmZlciB3 aWxsIHVuZGVyZmxvdy4NCg0KLWFjYmVnZW4= From sunseawq@huawei.com Wed Oct 13 23:40:36 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DA1D3A6822 for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.973 X-Spam-Level: X-Spam-Status: No, score=0.973 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh-+2708+FSX for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:40:33 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 16E593A6774 for <httpstreaming@ietf.org>; Wed, 13 Oct 2010 23:40:33 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA9002I5P9GUG@szxga03-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:41:40 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA900JVVP9GXZ@szxga03-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:41:40 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA900F50P9FM2@szxml06-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:41:40 +0800 (CST) Date: Thu, 14 Oct 2010 14:41:39 +0800 From: Qin Wu <sunseawq@huawei.com> To: Mark Watson <watsonm@netflix.com> Message-id: <03e201cb6b6a$db1ae770$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_ExWOXQtFeP9X3i6XsmGg6w)" X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> <029d01cb693a$7f515f50$30298a0a@china.huawei.com> <9062141B-82B8-4FF0-98C2-EB803BCA3DD7@netflix.com> Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 06:40:36 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ExWOXQtFeP9X3i6XsmGg6w) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 SGksDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IE1hcmsgV2F0c29u IA0KICBUbzogUWluIFd1IA0KICBDYzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pIDsgaHR0cHN0cmVh bWluZ0BpZXRmLm9yZyA7IENvbGluIFBlcmtpbnMgDQogIFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIg MTIsIDIwMTAgMTI6NTAgQU0NCiAgU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50 IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KDQogIFNvbWUgY29tbWVudHMgb25saW5lIC4uLg0KDQog IFNlbnQgZnJvbSBteSBpUGhvbmUNCg0KICBPbiBPY3QgMTEsIDIwMTAsIGF0IDc6NTAgUE0sICJR aW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPiB3cm90ZToNCg0KDQogICAgSGksDQogICAgVGhp cyBpcyB3aGF0IHdlIGhhZCBkaXNjdXNzZWQgIGluIHRoZSBESVNQQVRDSCBtYWlsaW5nIGxpc3Qg YmVmb3JlIHdlIG1vdmUgdG8gdGhpcyBkaXNjdXNzIGxpc3QuDQogICAgSWYgeW91IGxvb2sgYXQg dGhlIGRlc2NyaXB0aW9uIG9mIGRpc2N1c3MgbGlzdCwgIg0KICAgIG9mZmVycyBtb3JlIGVmZmlj aWVudCB0cmFuc3BvcnQgDQogICAgYW5kIGJldHRlciBuZXR3b3JrIGNhcGFiaWxpdHkgZm9yIHJl YWwgdGltZSBzdHJlYW1pbmcgbWVkaWENCiAgICBhbmQgYWxsb3dzIGludGVyb3BlcmFiaWxpdHkg d2l0aCBvdGhlciBzdHJlYW1pbmcgdGVjaG5pcXVlcyBhbmQgZXhpc3RpbmcgUHJvZ3Jlc3NpdmUg ZG93bG9hZGVkIGJhc2VkDQogICAgSFRUUCBzdHJlYW1pbmcgaW1wbGVtZW50YXRpb24uDQogICAg Ig0KICAgIHlvdSB3aWxsIHNlZSB3ZSBhcmUgb24gdGhlIHNhbWUgcGFnZS4NCiAgICBUaGVyZWZv cmUgb25lIGltcG9ydGFudCBnb2FsIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQgYWltcyBhdCBkZXZl bG9waW5nIGludGVyb3BlcmFibGUgc29sdXRpb24gdG8gDQogICAgcHJvdmlkZSBiZXR0ZXIgdHJh bnNwb3J0IHRvIHNhdGlzZnkgdGhlIHJlYWwgdGltZSBzdHJlYW1pbmcgUU9FIHJlcXVpcmVtZW50 LiBFc3BlY2lhbGx5IHNlcnZlcmFsDQogICAgY2hhbmxsZW5nZXMvcHJvYmxlbXMgd2UgZXhwbG9y ZWQgaW4gdGhlIGRyYWZ0IGxpc3RlZCBiZWxvdy4NCg0KICAgIFJlZ2FyZHMhDQogICAgLVFpbg0K ICAgICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgICAgIEZyb206IE1hcmsgV2F0 c29uIA0KICAgICAgVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSANCiAgICAgIENjOiBodHRwc3Ry ZWFtaW5nQGlldGYub3JnIDsgQ29saW4gUGVya2lucyANCiAgICAgIFNlbnQ6IFN1bmRheSwgT2N0 b2JlciAxMCwgMjAxMCA3OjEzIEFNDQogICAgICBTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmdd IEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KDQoNCiAgICAgIEFsbCwgDQoNCg0KICAgICAg SSB3b3VsZCBsaWtlIHRvIGFkZCBteSBzdXBwb3J0IHRvIHRoZSBjb21tZW50cyBiZWxvdy4gU3Bl Y2lmaWNhbGx5LCBJIHRoaW5rIGlmIHRoZSBJRVRGIGNvbnNpZGVycyB3b3JrIGluIHRoaXMgYXJl YSBpdCBzaG91bGQgZm9jdXMgb24gdGhlIEhUVFAgYW5kIFRDUCBwcm90b2NvbHMuIEFueSBzdWNo IHdvcmsgbWF5IG5vdCBiZSBzcGVjaWZpYyB0byBIVFRQLXN0cmVhbWluZyAoaS5lLiBlbmhhbmNl bWVudHMgdGhhdCBhcmUgYXQgZmlyc3QgbW90aXZhdGVkIGJ5IEhUVFAgU3RyZWFtaW5nIG1heSBo YXZlIGJyb2FkZXIgYXBwbGljYWJpbGl0eSwgYW5kIHRoaXMgc2hvdWxkIGJlIGNhcmVmdWxseSBj b25zaWRlcmVkKS4NCg0KDQogICAgICBJbiB0aGUgZHJhZnQgSSBkbyBub3Qgc2VlIGEgY2xlYXIg b3IgY29ycmVjdCBpZGVudGlmaWNhdGlvbiBvZiB0aGUgcHJvYmxlbXMuIEZvciBleGFtcGxlIGlu IHRoZSBpbnRyb2R1Y3Rpb24gdGhlIGZvbGxvd2luZyBhcmUgc3RhdGVkIGFzIGlzc3VlczoNCiAg IC0gQ2xpZW50IHBvbGxpbmcgZm9yIGVhY2ggbmV3IGRhdGEgaW4gY2h1bmtzIHVzaW5nIEhUVFAg cmVxdWVzdHMgaXMNCiAgIG5vdCBlZmZpY2llbnQgdG8gZGVsaXZlciBoaWdoLXF1YWxpdHkgdmlk ZW8gY29udGVudCBhY3Jvc3MgdGhlDQogICBJbnRlcm5ldE1XOiBTZXZlcmFsIGNvbXBhbmllcywg aW5jbHVkaW5nIG15IGVtcGxveWVyLCBhcmUgc3VjY2Vzc2Z1bGx5IG9wZXJhdGluZyBsYXJnZSBz Y2FsZSBIVFRQIHN0cmVhbWluZyBzeXN0ZW1zIHRoYXQgZG8gZWZmaWNpZW50bHkgZGVsaXZlciBo aWdoLXF1YWxpdHkgdmlkZW8gY29udGVudCBhY3Jvc3MgdGhlIEludGVybmV0LCBzbyByZWFsaXR5 IHNlZW1zIHRvIHJlZnV0ZSB0aGlzIHN0YXRlbWVudC5bUWluXTogTm90IHN1cmUgdGhleSBjYW4g cHJvdmlkZSB0aGUgVFYgZXhwZXJpZW5jZSBmb3IgYWxsIHRoZSBjb25uZWN0ZWQgZGV2aWNlcyBs aWtlIHNtYXJ0cGhvbmVzLCBQQ3MgYW5kIHRhYmxldHMuIEFsc28gbm90IHN1cmUgdGhleSBjYW4g cHJvdmlkZSB0aGUgc2FtZSBxdWFsaXR5IG9mIGV4cGVyZW5jZSBmb3IgYWxsIHRoZSBhbGwgdGhl IGNvbm5lY3RlZCBkZXZpY2VzLiBBcyB3ZSBkaXNjdXNzZWQgaW4gdGhpcyB0aHJlYWQsIGEgbWlu aW11bSBvZiAyMCBzZWNvbmRzIHRvIHN0YXJ0IHlvdXIgdmlkZW8gb2Z0ZW4gZnJ1c3RyYXRlZCB1 c2VycyB0byBrZWVwIG9uIHdhdGNoaW5nIGFuZCBwcm92aWRlIHZlcnkgbGltaXRlZCB1c2VyIGV4 cGVyaWVuY2UuQ2FuIHlvdSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRoZSBwcm9ibGVtcyB0aGF0 IHlvdSBzZWU/IEknbSBub3Qgc3VyZSB3aGVyZSB0aGUgMjBzIGZpZ3VyZSBjb21lcyBmcm9tLiBJ IGRvIG5vdCBzZWUgYW55IHByb2JsZW0gaW4gc3VwcG9ydGluZyBzdGFydHVwIHRpbWVzIGNvbXBh cmFibGUgdG8gVFYgY2hhbm5lbCBjaGFuZ2Ugd2l0aCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZy4N Cg0KDQogIEkgYW0gbm90IHNheWluZyB0aGVyZSBpcyBubyByb29tIGZvciBpbXByb3ZlbWVudCBp biB0aGUgdmFyaW91cyBkZXBsb3llZCBzeXN0ZW1zLCBidXQgSSBkbyBub3Qgc2VlIG1ham9yIHRl Y2huaWNhbCBpbXBlZGltZW50cyB0byBlZmZpY2llbnQgZGVsaXZlcnkgb2YgaGlnaCBxdWFsaXR5 IHZpZGVvIHVzaW5nIEhUVFAgU3RyZWFtaW5nLg0KDQogIFtRaW5dOk5vdCBvbmx5IHN0YXJ1cCBs YXRlbmN5IGJ1dCBhbHNvIGRlbGF5IHcuci50LiByZWFsIHRpbWUgc3RyZWFtaW5nLiBJIHRoaW5r IHlvdSBuZWdlY3QgaXQgYmVjb3MgWW91IGRpZG4ndCBnZXQgaW50byB0aGUgZGlzY3Vzc2lvbiBs aXN0LiANCg0KT24gdGhlIG90aGVyIGhhbmQsIEkgdGhpbmsgd2Ugc2hvdWxkIGJlYXIgaW4gbWlu ZCBIVFRQIGlzIGZvcm1lcmx5IGRlc2lnbmVkIGZvciBicm93c2luZyB3ZWJwYWdlLCB0cmFuc3Bv cnQgc3RhdGljIGNvbnRlbnRzIGxpa2UgSFRNTCBwYWdlLCBwbHVnaW4sIHBpY3R1cmUsIHdoZW4g d2UgYXJlIGdvaW5nIHRvIHVzZSBIVFRQIHRvIGRlbGl2ZXIgcmVhbCB0aW1lIHN0cmVhbWluZyBj b250ZW50cywgd2UgY2FuIG5vdCBleHBlY3QgdG8gZ2V0IGhpZ2hlciB1c2VyIGV4cGVyaWVuY2Uu IFRoZXJlZm9yZSB0aGUgY3VycmVudCBzdHJlYW1pbmcgc2NoZW1lcyBjYW4gb25seSBvZmZlciBh IGJldHRlciBleHBlcmllbmNlIG92ZXIgc2xvd2VyIGNvbm5lY3Rpb25zLiAgIC0gU2VnbWVudGF0 aW9uIGNhcGFiaWxpdHkgcmVxdWlyZXMgb3Zlci11dGlsaXppbmcgQ1BVIGFuZCBiYW5kd2lkdGgN CiAgIHJlc291cmNlcywgd2hpY2ggbWF5IG5vdCBiZSBhIGRlc2lyYWJsZSBhbmQgZWZmZWN0aXZl IHdheSB0byBpbXByb3ZlDQogICB0aGUgcXVhbGl0eSBvZiBzdHJlYW1pbmcgbWVkaWEgZGVsaXZl cnlNVzogSXQgaXMgbm90IGNsZWFyIHRoYXQgc2VnbWVudGF0aW9uIHBlciBzZSBpcyBDUFUtaW50 ZW5zaXZlIG9yIGhhcyBhbnkgbm9uLW5lZ2xpZ2FibGUgZWZmZWN0IG9uIGJhbmR3aWR0aCB1c2Fn ZS5bUWluXTogU2luY2UgSFRUUCBzdHJlYW1pbmcgc2VydmVyIGlzIHRoZSBjb21iaW5hdGlvbiBv ZiBzdHJlYW1pbmcgc2VydmVyIGFuZCByZWd1bGFyIHdlYiBzZXJ2ZXIsIEkgdGhpbmsgdGhlIGFu c3dlciBpcyBib3RoLg0KDQogIFtNV10gd2hhdCBkbyB5b3UgbWVhbiBieScgaHR0cCBzdHJlYW1p bmcgc2VydmVyJyA/DQoNCiAgW1Fpbl06IFdpdGggc3RyZWFtaW5nIGNhcGFiaWxpdHkgYW5kIGZ1 bmN0aW9uYWxpdHkgdG8gcmVzcG9uZCB0byBIVFRQIGNvbm5lY3Rpb24uDQoNCiAgIC0gTGFjayBv ZiBRb1MgZ3VhcmFudGVlIG9uIHRoZSBwYWNrZXQgc3dpdGNoaW5nIGJhc2VkIEludGVybmV0ICwg dGhlDQogICBxdWFsaXR5IG9mIEludGVybmV0IG1lZGlhIHN0cmVhbWluZyBtYXkgc2lnbmlmaWNh bnQgZGVncmFkZSBkdWUgdG8NCiAgIHJpc2luZyB1c2FnZU1XOiBBbiBhbHRlcm5hdGl2ZSB2aWV3 IGlzIHRoYXQgd2hlcmUgcXVhbGl0eSBpcyBkZWdyYWRlZCBkdWUgdG8gY29uZ2VzdGlvbiB0aGlz IGlzIGR1ZSB0byBsYWNrIG9mIGJhbmR3aWR0aCwgcmF0aGVyIHRoYW4gYSBsYWNrIG9mIFFvUyBn dWFyYW50ZWVzLiBBZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyBzeXN0ZW1zIGFkanVzdCB0aGUgdmlk ZW8gcXVhbGl0eSB0byB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCBpbiBvcmRlciB0byBhdm9pZCBy ZWJ1ZmZlcmluZyBldmVudHMuIEl0IGlzIHRoZSBhdmFpbGFibGUgYmFuZHdpZHRoIHRoYXQgbmVl ZHMgdG8gYmUgaW1wcm92ZWQgdG8gaW1wcm92ZSBxdWFsaXR5LltRaW5dOiBXaGF0IEkgZW1waGFz aXplIGhlcmUgaXMgd2l0aCBncm93aW5nIHBvcHVsYXJpdHkgb2YgSFRUUCBzdHJlYW1pbmcgdHJh ZmZpYywgd2hlbiB0aG91c2FuZHMgb3IgbWlsbGlvbnMgb2YgcGVvcGxlIGFyZSBhY2Nlc3Npbmcg dGhlIHNhbWUgbWVkaWEgY29udGVudHMsIHRoZSBiaWcgcHJvYmxlbSB3ZSBhcmUgZmFjaW5nIGlz IHNlcmlvdXMgaGlnaCBjb25jdXJyZW5jZSBhY2Nlc3MgaXNzdWUuIFRoZSB1c2VyIGV4cGVyaWVu Y2Ugd2lsbCBiZSBncmVhdGx5IGFmZmVjdGVkIGV2ZW4geW91IGhhdmUgZW5vdWdoIGF2YWlsYWJs ZSBiYW5kd2lkdGguIFNvIHRoaXMgaXMgbm90IHB1cmUgYmFuZHdpZHRoIGlzc3VlLg0KDQogIFtN V10gbWF5YmUgd2UgbWVhbiBkaWZmZXJlbnQgdGhpbmdzIGJ5ICdhdmFpbGFibGUgYmFuZHdpZHRo Jy4gRG8geW91IHRoaW5rIGl0IGlzIGEgc2VydmVyIHNjYWxhYmlsaXR5IHByb2JsZW0sIG9yIGEg bmV0d29yayBwcm9ibGVtID8NCg0KICBbUWluXTogcGxlYXNlIHJlYWQgaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2h0dHBzdHJlYW1pbmcvY3VycmVudC9tc2cwMDAxMS5odG1s DQoNCiAgIC0gRXhwZXJpZW5jZSBidXJzdGluZXNzIG9yIG90aGVyIGR5bmFtaWNzIGNoYW5nZXMg ZHVlIHRvIGJhbmR3aWR0aA0KICAgZmx1Y3R1YXRpb25zIGFuZCBoZXRlcm9nZW5lb3VzIGhhbmRv dmVyLk1XOiBXZSBoYXZlIGZvdW5kIHRoYXQgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3Jp dGhtcyBhcmUgd2VsbCBhYmxlIHRvIGNvcGUgd2l0aCBiYW5kd2lkdGggZmx1Y3R1YXRpb25zLiBb UWluXTogSSBkb24ndCBkb3VidCB0aGF0IGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRo bXMgY2FuIGNvcGUgd2l0aCBiYW5kd2lkdGggZmx1Y3RhdGlvbi4gQnV0IEkgaG9wZSB3ZSBjYW4g ZG8gYmV0dGVyLmUuZy4sIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRobXMgb25seSBz dXBwb3J0IGRlbGl2ZXJ5IG9mIG11bHRpcGxlIHN0cmVhbXMgb2YgdGhlIHNhbWUgY29udGVudCB3 aXRoIHZhcnlpbmcgcXVhbGl0eSBsZXZlbHMgZm9yIGRpZmZlcmVudCBiYW5kd2lkdGggb3IgZGV2 aWNlcy4gSG93ZXZlIGhvdyB0aGUgc2VydmVyIGluIHB1c2ggbW9kZWwgb3IgY2xpZW50IGluIHB1 bGwgbW9kZWwgY2FuIHF1aWNrIHJlc3BvbnNlIHRvIHRoZSBiaXRyYXRlIGNoYW5nZXMgaXMgYSBw cm9ibGVtIHdlIG1heSBsb29rIGF0LGVzcGVjaWFsbHkgd2hlbiBzd2l0Y2hpbmcgYmV3ZWVuIHN0 cmVhbXMgb2NjdXJzIHZlcnkgZnJlcXVlbnRseS4NCg0KICBbTVddIFllcywgYnV0IG5vdCBhIHBy b2JsZW0gZm9yIHRoZSBJRVRGLCBJIHRoaW5rLg0KDQogIFtRaW5dOiBJIGRpZG4ndCBnZXQgd2hh dCB5b3Ugc2FpZC4gYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBpcyBjaGFyYWN0 ZXJpemVkIGFzICBjbGllbnQgaW5pdGlhdGVkIHB1bGwgbW9kZWwuIFdlIGFyZSBkaXNjdXNzaW5n IHB1c2ggbW9kZWwgb3IgaG93IHRvIHVzZSBwdWxsIG1vZGVsIHdpdGggcHVzaCBtb2RlbC5XZSBh cmUgdGFsa2luZyBhYm91dCBkaWZmZXJlbnQgbW9kZWwuIFRoZXJlIGFyZSBwbGVudHkgcm9vbSBm b3IgSUVURiB0byBkbyBmb3IgdGhpcy4NCg0KICAgLSBJbXBvc3NpYmxlIHRvIGZhc3QtZm9yd2Fy ZCB0aHJvdWdoIGFueSBwYXJ0IG9mIGEgc3RyZWFtaW5nDQogICBjb250ZW50cyB1bnRpbCBpdCBp cyBzdG9yZWQgb24gdGhlIHVzZXIncyBkZXZpY2VNVzogVGhpcyBpcyBzaW1wbHkgbm90IGNvcnJl Y3QsIHNpbmNlIHRoZXJlIGFyZSBodW5kcmVkcyBvZiBleGFtcGxlcyBvZiBkZXZpY2VzIHdoaWNo IHN1cHBvcnQgdHJpY2stcGxheSB1c2luZyBIVFRQIHN0cmVhbWluZyB0ZWNobmlxdWVzIHdpdGhv dXQgc3RvcmluZyB0aGUgd2hvbGUgY29udGVudCBvbiB0aGUgdXNlcnMgZGV2aWNlLltRaW5dOiBG YXN0IGZvcndhcmQgY2FwYWJpbHR5IGlzIG5vdCB0aGUgbW9zdCBpbXBvcnRhbnQgZmVhdHVyZSB3 ZSBhcmUgbG9va2luZyBmb3IuIEhvd2V2ZXIgSSBhbSBoYXJkIHRvIGJlbGlldmUgZXhpc3Rpbmcg SFRUUCBzdHJlYW1pbmcgdGVjaG5pcXVlcyBjYW4gcHJvdmlkZSB0aGUgc2FtZSBkZWdyZWUgb2Yg cGxheWJhY2tjb250cm9sIHRoYXQgRFZEIHBsYXllciBjYW4gcHJvdmlkZXMgb3IgUlRTUCBwcm90 b2NvbCBwcm92aWRlcy4gRS5nLiwgSW4gdGhlIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29y aXRobXMsIHRoZSB0cmljayBwbGF5IGlzIGxpbWl0ZWQgdG8gcGF1c2UvcmVzdW1lL3N0b3AgYnkg ZHJpdmluZyB0aGUgSFRUUCByZXF1ZXN0LiBJZiB0aGUgY29udGVudHMgaGFzbid0IGJlZW4gZG93 bG9hZGVkICBhbmQgdGhlIGNvbnN1bWUgd2FudCBmYXN0IGZvcndhcmQsIHRoZSBIVFRQIGNsaWVu dCBuZWVkcyB0byBpc3N1ZSBhbm90aGVyIG5ldyBIVFRQIHJlcXVlc3QgdG8gZmV0Y2ggdGhlIGNv bnRlbnRzIHdoaWNoIHdpbGxjYXVzZSB1bmFjY2VwdGFibGUgbGF0ZW5jeSB0byB0aGUgY29uc3Vt ZXIuW01XXSBBZ2FpbiwgdGhlIGV4cGVyaWVuY2Ugb2YgbWlsbGlvbnMgb2YgZXhpc3RpbmcgY3Vz dG9tZXJzIHJlZnV0ZXMgd2hhdCB5b3UgY2xhaW0uIFdoeSBkbyB5b3UgdGhpbmsgaXQgaXMgbmVj ZXNzYXJpbHkgc28gc2xvdyB0byBpc3N1ZSBhIG5ldyBIVFRQIHJlcXVlc3QgZm9yIGEgZGlmZmVy ZW50IHBhcnQgb2YgdGhlIGNvbnRlbnQ/DQoNCiAgW1Fpbl06IFlvdSBkaWRuJ3Qgc2VlIHRoZSBy ZWFvbiBiZWhpbmQgdGhpcywgYmVjb3MgdGhlIGV4aXN0aW5nIGN1c3RvbWVycyBoYXMgbm8gY2hv aWNlIHdoZW4gdGhleSB2aWV3IGxpdmUgc3RyZWFtaW5nLCB3aGF0IHRoZXkgY2FuIGdldCBpcyBj bG9zZSB0byBsaXZlIGV4cGVyaWVuY2UgcmF0aGVyIHRoYW4gcmVhbCB0aW1lIHVzZXIgZXhwZXJp ZW5jZS4gT3BlcmF0b2VyIGRvIG5vdGhpbmcgZm9yIHRoZWlyIG5ldHdvcmsgdG8gbWFrZSBodHRw IHN0cmVhbWluZyBtb3JlIGNvbnRyb2xsYWJsZSBhbmQgbWFuYWdhYmxlLiBUaGVyZWZvcmUgbW9y ZSBhbmQgbW9yZSBjb25zdW1lciB0ZW5kIHRvIGNob29zZSBub24tbGl2ZSBjb250ZW50LiB0aGF0 J3Mgd2h5IHdlIHNlZSBtb3JlIGFuZCBtb3JlIG5vbi1saXZlIGNvbnRlbnQgY29uc3VtZXJzIHJh dGhlciB0aGFuIGxpdmUgY29udGVudHMgY29uc3VtZXJzLiANCg0KDQpBIGZpcnN0IHN0ZXAgaW4g Y29uc2lkZXJpbmcgd2hhdCwgaWYgYW55LCB3b3JrIHNob3VsZCBiZSBkb25lIGhlcmUgbWlnaHQg YmUgdG8gY29udGFjdCB0aG9zZSBvcmdhbml6YXRpb25zIHdoaWNoIGFyZSBzdGFuZGFyZGl6aW5n IHRoZSBoaWdoZXIgbGF5ZXJzIG9mIEhUVFAgc3RyZWFtaW5nIHN5c3RlbXMgKGUuZy4gbWFuaWZl c3QgYW5kIGZpbGUgZm9ybWF0cykgYW5kIGFzayB3aGV0aGVyIHRoZXJlIGFyZSBkZWZpY2llbmNp ZXMgdGhleSBzZWUgaW4gSUVURiBwcm90b2NvbHMgdGhhdCBjb3VsZCBiZSB1c2VmdWxseSBhZGRy ZXNzZWQgYnkgdGhlIElFVEYuIFdoYXQgSSB0aGluayB3ZSBzaG91bGQgYXZvaWQgaW4gdGhlIElF VEYgaXMgZHVwbGljYXRpbmcgdGhlIHdvcmsgb2YgdGhlc2Ugb3RoZXIgYm9kaWVzLkJlc3QsTWFy ayBXYXRzb25OZXRmbGl4IEluYy4NCg0KDQoNCg0KDQogICAgICBPbiBPY3QgMTAsIDIwMTAsIGF0 IDEyOjQzIEFNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQoNCg0KDQoNCg0KICAgICAg ICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCiAgICAgICAgICBGcm9tOiBodHRwc3Ry ZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBMYXJzIEVnZ2VydA0KDQogICAgICAgICAgU2VudDogRnJpZGF5 LCBPY3RvYmVyIDA4LCAyMDEwIDQ6MTcgUE0NCg0KICAgICAgICAgIFRvOiBDb2xpbiBQZXJraW5z DQoNCiAgICAgICAgICBDYzogaHR0cHN0cmVhbWluZ0BpZXRmLm9yZw0KDQogICAgICAgICAgU3Vi amVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0K DQoNCiAgICAgICAgICBPbiAyMDEwLTEwLTcsIGF0IDE0OjE2LCBDb2xpbiBQZXJraW5zIHdyb3Rl Og0KDQogICAgICAgICAgICBUaGVyZSBhcmUgY2xlYXJseSBzb21lIGlzc3VlcyB0byBjb25zaWRl ciBoZXJlLiBXaGF0IHNlZW1zIHRvIGJlDQoNCiAgICAgICAgICAgIG1pc3NpbmcgZnJvbSB0aGUg ZGlzY3Vzc2lvbiB0byBtZSB0aG91Z2gsIGlzIHNvbWUgaWRlbnRpZmljYXRpb24gb2YNCg0KICAg ICAgICAgICAgdGhlIGNvbmNyZXRlIHByb2JsZW1zLiBXaGF0IHByb3RvY29sIHBpZWNlcyBkbyB3 ZSBuZWVkLCBidXQgbm90IGhhdmU/DQoNCiAgICAgICAgICAgIFdoYXQgcHJvdG9jb2xzIGFyZSBw cm9ibGVtYXRpYywgYW5kIG5lZWQgZW5oYW5jZW1lbnQ/IElzIHRoZXJlDQoNCiAgICAgICAgICAg IHByb3RvY29sIHdvcmsgdG8gZG8gaW4gSUVURiwgb3Igc2hvdWxkIHdlIGJlIGRvY3VtZW50aW5n IGJlc3QgY3VycmVudA0KDQogICAgICAgICAgICBwcmFjdGljZXMgZm9yIHVzaW5nIHRoZSBleGlz dGluZyBwcm90b2NvbHMgYW5kL29yIHJlbHlpbmcgb24gb3RoZXINCg0KICAgICAgICAgICAgYm9k aWVzIHRvIGZpbGwgdGhlIGdhcHM/DQoNCg0KDQogICAgICAgICAgICBUaGUgZHJhZnQtd3UtaHR0 cC1zdHJlYW1pbmctb3B0aW1pemF0aW9uLXBzIGlzIGEgZ29vZCBzdGFydCBhdCBzdWNoIGFuDQoN CiAgICAgICAgICAgIGFuYWx5c2lzLCBidXQgZG9lc24ndCBnbyBkZWVwIGVub3VnaCB0byBsZXQg dXMgZGVjaWRlIHdoYXQgd29yayBJRVRGDQoNCiAgICAgICAgICAgIHNob3VsZCBkby4NCg0KDQoN CiAgICAgICAgICArMQ0KDQoNCg0KICAgICAgICAgIFRoZSBrZXkgcXVlc3Rpb24gcmVhbGx5IGlz ICJ3aGF0IGRvIHlvdSB0aGluayB0aGUgSUVURiBuZWVkcyB0byBkbz8iDQoNCg0KICAgICAgICBJ IGltYWdpbmUgdGhlIG9ubHkgd29yayB0aGUgSUVURiBzaG91bGQgZG8gKGlmIHdlIGRlY2lkZSB0 bykgaXMgdGhlIHRyYW5zcG9ydCBhbmQgSFRUUC1sYXllciBvcHRpbWl6YXRpb24gZm9yIGJldHRl ciBzdHJlYW1pbmcgcGVyZm9ybWFuY2UuDQoNCiAgICAgICAgLWFjYmVnZW4NCg0KDQogICAgICAg ICAgTGFycw0KDQogICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgICAgIGh0dHBzdHJlYW1pbmcgbWFpbGluZyBsaXN0DQogICAgICAgIGh0 dHBzdHJlYW1pbmdAaWV0Zi5vcmcNCiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9odHRwc3RyZWFtaW5nDQoNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQoNCiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgICBodHRwc3RyZWFtaW5nIG1haWxpbmcgbGlzdA0KICAgICAgaHR0cHN0cmVhbWluZ0Bp ZXRmLm9yZw0KICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRw c3RyZWFtaW5nDQo= --Boundary_(ID_ExWOXQtFeP9X3i6XsmGg6w) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIG5hbWU9R0VORVJBVE9SIGNv bnRlbnQ9Ik1TSFRNTCA4LjAwLjYwMDEuMTg5MjgiPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPkhpLDwvRElWPg0KPEJMT0NLUVVPVEUgDQpz dHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsg UEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCIg DQpkaXI9bHRyPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj4tLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TOyBC QUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8 QSB0aXRsZT13YXRzb25tQG5ldGZsaXguY29tIGhyZWY9Im1haWx0bzp3YXRzb25tQG5ldGZsaXgu Y29tIj5NYXJrIFdhdHNvbjwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg 5a6L5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXN1bnNlYXdxQGh1YXdlaS5jb20gDQogIGhyZWY9 Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8L0E+IDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5DYzo8L0I+IDxBIHRpdGxlPWFiZWdlbkBjaXNjby5j b20gDQogIGhyZWY9Im1haWx0bzphYmVnZW5AY2lzY28uY29tIj5BbGkgQy4gQmVnZW4gKGFiZWdl bik8L0E+IDsgPEEgDQogIHRpdGxlPWh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcgDQogIGhyZWY9Im1h aWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnIj5odHRwc3RyZWFtaW5nQGlldGYub3JnPC9BPiA7 IDxBIA0KICB0aXRsZT1jc3BAY3NwZXJraW5zLm9yZyBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lu cy5vcmciPkNvbGluIFBlcmtpbnM8L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDog OXB0IOWui+S9kyI+PEI+U2VudDo8L0I+IFR1ZXNkYXksIE9jdG9iZXIgMTIsIDIwMTAgMTI6NTAg DQpBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0Ojwv Qj4gUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyANCiAgYW5kIE91ciBHb2FsPC9E SVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWPlNvbWUgY29tbWVudHMgb25saW5lIC4uLjxC Uj48QlI+U2VudCBmcm9tIG15IGlQaG9uZTwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNl PeWui+S9kz48L0ZPTlQ+PEJSPk9uIE9jdCAxMSwgMjAxMCwgYXQgNzo1MCBQTSwgIlFpbiBXdSIg DQogICZsdDs8QSBocmVmPSJtYWlsdG86c3Vuc2Vhd3FAaHVhd2VpLmNvbSI+c3Vuc2Vhd3FAaHVh d2VpLmNvbTwvQT4mZ3Q7IA0KICB3cm90ZTo8QlI+PEJSPjwvRElWPg0KICA8RElWPjwvRElWPg0K ICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICA8RElWPg0KICAgIDxESVY+SGksPC9ESVY+ DQogICAgPERJVj5UaGlzIGlzIHdoYXQgd2UgaGFkIGRpc2N1c3NlZCZuYnNwOyBpbiB0aGUgRElT UEFUQ0ggbWFpbGluZyBsaXN0IGJlZm9yZSANCiAgICB3ZSBtb3ZlIHRvIHRoaXMgZGlzY3VzcyBs aXN0LjwvRElWPg0KICAgIDxESVY+SWYgeW91IGxvb2sgYXQgdGhlIGRlc2NyaXB0aW9uIG9mIGRp c2N1c3MgbGlzdCwgIjwvRElWPg0KICAgIDxESVY+b2ZmZXJzIG1vcmUgZWZmaWNpZW50IHRyYW5z cG9ydCA8QlI+YW5kIGJldHRlciBuZXR3b3JrIGNhcGFiaWxpdHkgZm9yIA0KICAgIHJlYWwgdGlt ZSBzdHJlYW1pbmcgbWVkaWE8QlI+YW5kIGFsbG93cyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggb3Ro ZXIgDQogICAgc3RyZWFtaW5nIHRlY2huaXF1ZXMgYW5kIGV4aXN0aW5nIFByb2dyZXNzaXZlIGRv d2xvYWRlZCBiYXNlZDxCUj5IVFRQIA0KICAgIHN0cmVhbWluZyBpbXBsZW1lbnRhdGlvbi48L0RJ Vj4NCiAgICA8RElWPiI8L0RJVj4NCiAgICA8RElWPnlvdSB3aWxsJm5ic3A7c2VlIHdlIGFyZSBv biB0aGUgc2FtZSBwYWdlLjwvRElWPg0KICAgIDxESVY+VGhlcmVmb3JlIG9uZSZuYnNwO2ltcG9y dGFudCBnb2FsIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQmbmJzcDthaW1zIA0KICAgIGF0Jm5ic3A7 ZGV2ZWxvcGluZyBpbnRlcm9wZXJhYmxlIHNvbHV0aW9uIHRvIDwvRElWPg0KICAgIDxESVY+cHJv dmlkZSBiZXR0ZXIgdHJhbnNwb3J0IHRvIHNhdGlzZnkgdGhlIHJlYWwgdGltZSBzdHJlYW1pbmcg UU9FIA0KICAgIHJlcXVpcmVtZW50LiBFc3BlY2lhbGx5Jm5ic3A7c2VydmVyYWw8L0RJVj4NCiAg ICA8RElWPmNoYW5sbGVuZ2VzL3Byb2JsZW1zJm5ic3A7d2UgZXhwbG9yZWQgaW4gdGhlIGRyYWZ0 IGxpc3RlZCBiZWxvdy48L0RJVj4NCiAgICA8RElWPiZuYnNwOzwvRElWPg0KICAgIDxESVY+UmVn YXJkcyE8L0RJVj4NCiAgICA8RElWPi1RaW48L0RJVj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBz dHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsg UEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+ DQogICAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj4tLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tIDwvRElWPg0KICAgICAgPERJViANCiAgICAgIHN0eWxlPSJGT05UOiA5cHQg5a6L 5L2TOyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+ IA0KICAgICAgPEEgdGl0bGU9d2F0c29ubUBuZXRmbGl4LmNvbSBocmVmPSJtYWlsdG86d2F0c29u bUBuZXRmbGl4LmNvbSI+TWFyayANCiAgICAgIFdhdHNvbjwvQT4gPC9ESVY+DQogICAgICA8RElW IHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPWFiZWdlbkBjaXNj by5jb20gDQogICAgICBocmVmPSJtYWlsdG86YWJlZ2VuQGNpc2NvLmNvbSI+QWxpIEMuIEJlZ2Vu IChhYmVnZW4pPC9BPiA8L0RJVj4NCiAgICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMi PjxCPkNjOjwvQj4gPEEgdGl0bGU9aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyANCiAgICAgIGhyZWY9 Im1haWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnIj48QSANCiAgICAgIGhyZWY9Im1haWx0bzpo dHRwc3RyZWFtaW5nQGlldGYub3JnIj5odHRwc3RyZWFtaW5nQGlldGYub3JnPC9BPjwvQT4gOyA8 QSANCiAgICAgIHRpdGxlPWNzcEBjc3BlcmtpbnMub3JnIGhyZWY9Im1haWx0bzpjc3BAY3NwZXJr aW5zLm9yZyI+Q29saW4gUGVya2luczwvQT4gDQogICAgICA8L0RJVj4NCiAgICAgIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlNlbnQ6PC9CPiBTdW5kYXksIE9jdG9iZXIgMTAsIDIw MTAgNzoxMyANCiAgICAgIEFNPC9ESVY+DQogICAgICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L 5L2TIj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IA0KICAgICAg U3RhdHVzIGFuZCBPdXIgR29hbDwvRElWPg0KICAgICAgPERJVj48QlI+PC9ESVY+QWxsLCANCiAg ICAgIDxESVY+PEJSPjwvRElWPg0KICAgICAgPERJVj5JIHdvdWxkIGxpa2UgdG8gYWRkIG15IHN1 cHBvcnQgdG8gdGhlIGNvbW1lbnRzIGJlbG93LiBTcGVjaWZpY2FsbHksIEkgDQogICAgICB0aGlu ayBpZiB0aGUgSUVURiBjb25zaWRlcnMgd29yayBpbiB0aGlzIGFyZWEgaXQgc2hvdWxkIGZvY3Vz IG9uIHRoZSBIVFRQIA0KICAgICAgYW5kIFRDUCBwcm90b2NvbHMuIEFueSBzdWNoIHdvcmsgbWF5 IG5vdCBiZSBzcGVjaWZpYyB0byBIVFRQLXN0cmVhbWluZyANCiAgICAgIChpLmUuIGVuaGFuY2Vt ZW50cyB0aGF0IGFyZSBhdCBmaXJzdCBtb3RpdmF0ZWQgYnkgSFRUUCBTdHJlYW1pbmcgbWF5IGhh dmUgDQogICAgICBicm9hZGVyIGFwcGxpY2FiaWxpdHksIGFuZCB0aGlzIHNob3VsZCBiZSBjYXJl ZnVsbHkgY29uc2lkZXJlZCkuPC9ESVY+DQogICAgICA8RElWPjxCUj48L0RJVj4NCiAgICAgIDxE SVY+SW4gdGhlIGRyYWZ0IEkgZG8gbm90IHNlZSBhIGNsZWFyIG9yIGNvcnJlY3QgaWRlbnRpZmlj YXRpb24gb2YgdGhlIA0KICAgICAgcHJvYmxlbXMuIEZvciBleGFtcGxlIGluIHRoZSBpbnRyb2R1 Y3Rpb24gdGhlIGZvbGxvd2luZyBhcmUgc3RhdGVkIGFzIA0KICAgICAgaXNzdWVzOjwvRElWPg0K ICAgICAgPERJVj48UFJFIGNsYXNzPW5ld3BhZ2U+ICAgLSBDbGllbnQgcG9sbGluZyBmb3IgZWFj aCBuZXcgZGF0YSBpbiBjaHVua3MgdXNpbmcgSFRUUCByZXF1ZXN0cyBpcw0KICAgbm90IGVmZmlj aWVudCB0byBkZWxpdmVyIGhpZ2gtcXVhbGl0eSB2aWRlbyBjb250ZW50IGFjcm9zcyB0aGUNCiAg IEludGVybmV0PEJSPjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48Rk9OVCBjbGFzcz1BcHBsZS1z dHlsZS1zcGFuIGZhY2U9SGVsdmV0aWNhPk1XOiBTZXZlcmFsIGNvbXBhbmllcywgaW5jbHVkaW5n IG15IGVtcGxveWVyLCBhcmUgc3VjY2Vzc2Z1bGx5IG9wZXJhdGluZyBsYXJnZSBzY2FsZSBIVFRQ IHN0cmVhbWluZyBzeXN0ZW1zIHRoYXQgZG8gZWZmaWNpZW50bHkgZGVsaXZlciBoaWdoLXF1YWxp dHkgdmlkZW8gY29udGVudCBhY3Jvc3MgdGhlIEludGVybmV0LCBzbyByZWFsaXR5IHNlZW1zIHRv IHJlZnV0ZSB0aGlzIHN0YXRlbWVudC48L0ZPTlQ+PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxG T05UIHNpemU9ND48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBOb3Qgc3VyZSB0 aGV5IGNhbiBwcm92aWRlIHRoZSBUViBleHBlcmllbmNlIGZvciBhbGwgdGhlIGNvbm5lY3RlZCBk ZXZpY2VzIGxpa2Ugc21hcnRwaG9uZXMsIFBDcyBhbmQgdGFibGV0cy4gQWxzbyBub3Qgc3VyZSB0 aGV5IGNhbiBwcm92aWRlIHRoZSBzYW1lIHF1YWxpdHkgb2YgZXhwZXJlbmNlIGZvciBhbGwgdGhl IGFsbCB0aGUgY29ubmVjdGVkIGRldmljZXMuIEFzIHdlIGRpc2N1c3NlZCBpbiB0aGlzIHRocmVh ZCwgYSBtaW5pbXVtIG9mIDIwIHNlY29uZHMgdG8gc3RhcnQgeW91ciB2aWRlbyBvZnRlbiBmcnVz dHJhdGVkIHVzZXJzIHRvIGtlZXAgb24gd2F0Y2hpbmcgYW5kIHByb3ZpZGUgdmVyeSBsaW1pdGVk IHVzZXIgZXhwZXJpZW5jZS48L0ZPTlQ+PC9GT05UPjwvUFJFPjwvRElWPjwvQkxPQ0tRVU9URT48 L0RJVj48L0JMT0NLUVVPVEU+DQogIDxESVY+Q2FuIHlvdSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0 IHRoZSBwcm9ibGVtcyB0aGF0IHlvdSBzZWU/IEknbSZuYnNwOzxTUEFOIA0KICBzdHlsZT0iLXdl YmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdl YmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5 KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAu MjMwNDY5KSIgDQogIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+bm90IHN1cmUgd2hlcmUgdGhlIDIw cyBmaWd1cmUgY29tZXMgZnJvbS4gSSBkbyBub3Qgc2VlIA0KICBhbnkgcHJvYmxlbSBpbiBzdXBw b3J0aW5nIHN0YXJ0dXAgdGltZXMgY29tcGFyYWJsZSB0byBUViBjaGFubmVsIGNoYW5nZSB3aXRo IA0KICBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZy48L1NQQU4+PC9ESVY+DQogIDxESVY+PEJSPjwv RElWPg0KICA8RElWPkkgYW0gbm90IHNheWluZyB0aGVyZSBpcyBubyByb29tIGZvciBpbXByb3Zl bWVudCBpbiB0aGUgdmFyaW91cyBkZXBsb3llZCANCiAgc3lzdGVtcywgYnV0IEkgZG8gbm90IHNl ZSBtYWpvciB0ZWNobmljYWwgaW1wZWRpbWVudHMgdG8gZWZmaWNpZW50IGRlbGl2ZXJ5IG9mIA0K ICBoaWdoIHF1YWxpdHkgdmlkZW8gdXNpbmcgSFRUUCBTdHJlYW1pbmcuPC9ESVY+DQogIDxESVY+ Jm5ic3A7PC9ESVY+DQogIDxESVY+W1Fpbl06Tm90IG9ubHkgc3RhcnVwIGxhdGVuY3kgYnV0IGFs c28gZGVsYXkgdy5yLnQuIHJlYWwgdGltZSBzdHJlYW1pbmcuIA0KICBJIHRoaW5rIHlvdSBuZWdl Y3QgaXQgYmVjb3MgWW91IGRpZG4ndCBnZXQgaW50byB0aGUgZGlzY3Vzc2lvbiBsaXN0LiANCjxC Uj48L0RJVj4NCiAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgPERJVj4NCiAgICA8QkxP Q0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURE SU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJH SU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWPjxQUkUgY2xhc3M9bmV3cGFnZT48Rk9OVCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxGT05UIHNpemU9ND5PbiB0aGUgb3RoZXIgaGFuZCwgSSB0aGlu ayB3ZSBzaG91bGQgYmVhciBpbiBtaW5kIEhUVFAgaXMgZm9ybWVybHkgZGVzaWduZWQgZm9yIGJy b3dzaW5nIHdlYnBhZ2UsIHRyYW5zcG9ydCBzdGF0aWMgY29udGVudHMgbGlrZSBIVE1MIHBhZ2Us IHBsdWdpbiwgcGljdHVyZSwgd2hlbiB3ZSBhcmUgZ29pbmcgdG8gdXNlIDwvRk9OVD48Rk9OVCBz aXplPTQ+SFRUUCB0byBkZWxpdmVyIHJlYWwgdGltZSBzdHJlYW1pbmcgY29udGVudHMsIHdlIGNh biBub3QgZXhwZWN0IHRvIGdldCBoaWdoZXIgdXNlciBleHBlcmllbmNlLiA8L0ZPTlQ+PEZPTlQg c2l6ZT0zPjxTVFJPTkc+VGhlcmVmb3JlIHRoZSBjdXJyZW50PC9TVFJPTkc+IDxTUEFOIHN0eWxl PSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgRk9OVC1TSVpFOiAxMnB0OyBtc28tZmFyZWFz dC1mb250LWZhbWlseTog5a6L5L2TOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJl YXN0LWxhbmd1YWdlOiBaSC1DTjsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIiBsYW5nPUVOLVVT PjxTVFJPTkc+c3RyZWFtaW5nIHNjaGVtZXMgY2FuIG9ubHkgb2ZmZXIgYSBiZXR0ZXIgZXhwZXJp ZW5jZSBvdmVyIHNsb3dlciBjb25uZWN0aW9ucy48L1NUUk9ORz48L1NQQU4+PC9GT05UPjwvRk9O VD48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+ICAgLSBTZWdtZW50YXRpb24gY2FwYWJpbGl0eSBy ZXF1aXJlcyBvdmVyLXV0aWxpemluZyBDUFUgYW5kIGJhbmR3aWR0aA0KICAgcmVzb3VyY2VzLCB3 aGljaCBtYXkgbm90IGJlIGEgZGVzaXJhYmxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIGltcHJvdmUN CiAgIHRoZSBxdWFsaXR5IG9mIHN0cmVhbWluZyBtZWRpYSBkZWxpdmVyeTwvUFJFPjxQUkUgY2xh c3M9bmV3cGFnZT48Rk9OVCBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuIGZhY2U9SGVsdmV0aWNhPk1X OiBJdCBpcyBub3QgY2xlYXIgdGhhdCBzZWdtZW50YXRpb24gcGVyIHNlIGlzIENQVS1pbnRlbnNp dmUgb3IgaGFzIGFueSBub24tbmVnbGlnYWJsZSBlZmZlY3Qgb24gYmFuZHdpZHRoIHVzYWdlLjwv Rk9OVD48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PEZPTlQgc2l6ZT00IGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+W1Fpbl06IFNpbmNlIEhUVFAgc3RyZWFtaW5nIHNlcnZlciBpcyB0aGUgY29tYmlu YXRpb24gb2Ygc3RyZWFtaW5nIHNlcnZlciBhbmQgcmVndWxhciB3ZWIgc2VydmVyLCBJIHRoaW5r IHRoZSBhbnN3ZXIgaXMgYm90aC48L0ZPTlQ+PC9QUkU+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElW PjwvQkxPQ0tRVU9URT4NCiAgPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovkvZM+PC9GT05UPjxC Uj48L0RJVj4NCiAgPERJVj5bTVddIHdoYXQgZG8geW91IG1lYW4gYnknIGh0dHAgc3RyZWFtaW5n IHNlcnZlcicgPzwvRElWPg0KICA8RElWPjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQogIDxESVY+W1Fpbl06IFdpdGggc3RyZWFtaW5nIGNhcGFiaWxpdHkgYW5k IGZ1bmN0aW9uYWxpdHkgdG8gcmVzcG9uZCB0byBIVFRQIA0KICBjb25uZWN0aW9uLjxCUj48L0RJ Vj4NCiAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgPERJVj4NCiAgICA8QkxPQ0tRVU9U RSANCiAgICBzdHlsZT0iQk9SREVSLUxFRlQ6ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxF RlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklH SFQ6IDBweCI+DQogICAgICA8RElWPjxQUkUgY2xhc3M9bmV3cGFnZT4gICAtIExhY2sgb2YgUW9T IGd1YXJhbnRlZSBvbiB0aGUgcGFja2V0IHN3aXRjaGluZyBiYXNlZCBJbnRlcm5ldCAsIHRoZQ0K ICAgcXVhbGl0eSBvZiBJbnRlcm5ldCBtZWRpYSBzdHJlYW1pbmcgbWF5IHNpZ25pZmljYW50IGRl Z3JhZGUgZHVlIHRvDQogICByaXNpbmcgdXNhZ2U8L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PEZP TlQgY2xhc3M9QXBwbGUtc3R5bGUtc3BhbiBmYWNlPUhlbHZldGljYT5NVzogQW4gYWx0ZXJuYXRp dmUgdmlldyBpcyB0aGF0IHdoZXJlIHF1YWxpdHkgaXMgZGVncmFkZWQgZHVlIHRvIGNvbmdlc3Rp b24gdGhpcyBpcyBkdWUgdG8gbGFjayBvZiBiYW5kd2lkdGgsIHJhdGhlciB0aGFuIGEgbGFjayBv ZiBRb1MgZ3VhcmFudGVlcy4gQWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyBhZGp1c3Qg dGhlIHZpZGVvIHF1YWxpdHkgdG8gdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggaW4gb3JkZXIgdG8g YXZvaWQgcmVidWZmZXJpbmcgZXZlbnRzLiBJdCBpcyB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCB0 aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIHRvIGltcHJvdmUgcXVhbGl0eS48L0ZPTlQ+PC9QUkU+ PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIGZhY2U9SGVsdmV0aWNhPjxGT05UIHNpemU9NCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBXaGF0IEkgZW1waGFzaXplIGhlcmUgaXMgd2l0aCBn cm93aW5nIHBvcHVsYXJpdHkgb2YgSFRUUCBzdHJlYW1pbmcgdHJhZmZpYywgd2hlbiB0aG91c2Fu ZHMgb3IgbWlsbGlvbnMgb2YgcGVvcGxlIGFyZSBhY2Nlc3NpbmcgdGhlIHNhbWUgbWVkaWEgY29u dGVudHMsIHRoZSBiaWcgcHJvYmxlbSB3ZSBhcmUgZmFjaW5nIGlzIHNlcmlvdXMgaGlnaCBjb25j dXJyZW5jZSBhY2Nlc3MgaXNzdWUuIFRoZSB1c2VyIGV4cGVyaWVuY2Ugd2lsbCBiZSBncmVhdGx5 IGFmZmVjdGVkIGV2ZW4geW91IGhhdmUgZW5vdWdoIGF2YWlsYWJsZSBiYW5kd2lkdGguIFNvIHRo aXMgaXMgbm90IHB1cmUgYmFuZHdpZHRoIGlzc3VlLjwvRk9OVD48L0ZPTlQ+PC9QUkU+PC9ESVY+ PC9CTE9DS1FVT1RFPjwvRElWPjwvQkxPQ0tRVU9URT4NCiAgPERJVj48Rk9OVCBzaXplPTIgZmFj ZT3lrovkvZM+PC9GT05UPjxCUj48L0RJVj4NCiAgPERJVj5bTVddIG1heWJlIHdlIG1lYW4gZGlm ZmVyZW50IHRoaW5ncyBieSAnYXZhaWxhYmxlIGJhbmR3aWR0aCcuIERvIHlvdSANCiAgdGhpbmsg aXQgaXMgYSBzZXJ2ZXIgc2NhbGFiaWxpdHkgcHJvYmxlbSwgb3IgYSBuZXR3b3JrIHByb2JsZW0g PzwvRElWPg0KICA8RElWPiZuYnNwOzwvRElWPg0KICA8RElWPltRaW5dOiBwbGVhc2UgcmVhZCA8 QSANCiAgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2h0dHBzdHJl YW1pbmcvY3VycmVudC9tc2cwMDAxMS5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvaHR0cHN0cmVhbWluZy9jdXJyZW50L21zZzAwMDExLmh0bWw8L0E+PEJSPjwvRElW Pg0KICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICA8RElWPg0KICAgIDxCTE9DS1FVT1RF IA0KICAgIHN0eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVG VDogNXB4OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdI VDogMHB4Ij4NCiAgICAgIDxESVY+PFBSRSBjbGFzcz1uZXdwYWdlPiAgIC0gRXhwZXJpZW5jZSBi dXJzdGluZXNzIG9yIG90aGVyIGR5bmFtaWNzIGNoYW5nZXMgZHVlIHRvIGJhbmR3aWR0aA0KICAg Zmx1Y3R1YXRpb25zIGFuZCBoZXRlcm9nZW5lb3VzIGhhbmRvdmVyLjwvUFJFPjxQUkUgY2xhc3M9 bmV3cGFnZT48Rk9OVCBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuIGZhY2U9SGVsdmV0aWNhPk1XOiBX ZSBoYXZlIGZvdW5kIHRoYXQgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBhcmUg d2VsbCBhYmxlIHRvIGNvcGUgd2l0aCBiYW5kd2lkdGggZmx1Y3R1YXRpb25zLiA8L0ZPTlQ+PC9Q UkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIHNpemU9NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PltRaW5dOiBJIGRvbid0IGRvdWJ0IHRoYXQgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3Jp dGhtcyBjYW4gY29wZSB3aXRoIGJhbmR3aWR0aCBmbHVjdGF0aW9uLiBCdXQgSSBob3BlIHdlIGNh biBkbyBiZXR0ZXIuPC9GT05UPjxGT05UIHNpemU9NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmUu Zy4sIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRobXMgb25seSBzdXBwb3J0IGRlbGl2 ZXJ5IG9mIG11bHRpcGxlIHN0cmVhbXMgb2YgdGhlIHNhbWUgY29udGVudCB3aXRoIHZhcnlpbmcg cXVhbGl0eSBsZXZlbHMgZm9yIGRpZmZlcmVudCBiYW5kd2lkdGggb3IgZGV2aWNlcy4gSG93ZXZl IGhvdyB0aGUgc2VydmVyIGluIHB1c2ggbW9kZWwgb3IgY2xpZW50IGluIHB1bGwgbW9kZWwgY2Fu IHF1aWNrIHJlc3BvbnNlIHRvIHRoZSA8L0ZPTlQ+PEZPTlQgc2l6ZT00IGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+Yml0cmF0ZSBjaGFuZ2VzIGlzIGEgcHJvYmxlbSB3ZSBtYXkgbG9vayBhdCxlc3Bl Y2lhbGx5IHdoZW4gc3dpdGNoaW5nIGJld2VlbiBzdHJlYW1zIG9jY3VycyB2ZXJ5IGZyZXF1ZW50 bHkuPC9GT05UPjwvUFJFPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48L0JMT0NLUVVPVEU+DQog IDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPjwvRk9OVD48QlI+PC9ESVY+DQogIDxESVY+ W01XXSBZZXMsIGJ1dCBub3QgYSBwcm9ibGVtIGZvciB0aGUgSUVURiwgSSB0aGluay48L0RJVj4N CiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5bUWluXTogSSBkaWRuJ3QgZ2V0IHdoYXQgeW91 IHNhaWQuIDxGT05UIHNpemU9ND5hZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyANCiAgYWxnb3JpdGht cyA8L0ZPTlQ+PEZPTlQgc2l6ZT0zPmlzIGNoYXJhY3Rlcml6ZWQgYXMmbmJzcDsgY2xpZW50IGlu aXRpYXRlZCBwdWxsIA0KICBtb2RlbC4gV2UgYXJlIGRpc2N1c3NpbmcgcHVzaCBtb2RlbCBvciBo b3cgdG8gdXNlIHB1bGwgbW9kZWwgd2l0aCBwdXNoIA0KICBtb2RlbC5XZSBhcmUgdGFsa2luZyBh Ym91dCBkaWZmZXJlbnQgbW9kZWwuIFRoZXJlIGFyZSBwbGVudHkgcm9vbSBmb3IgSUVURiB0byAN CiAgZG8gZm9yIHRoaXMuPEJSPjwvRk9OVD48L0RJVj4NCiAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0 ZSI+DQogICAgPERJVj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLUxFRlQ6 ICMwMDAwMDAgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4 OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICA8RElWPjxQUkUg Y2xhc3M9bmV3cGFnZT4gICAtIEltcG9zc2libGUgdG8gZmFzdC1mb3J3YXJkIHRocm91Z2ggYW55 IHBhcnQgb2YgYSBzdHJlYW1pbmcNCiAgIGNvbnRlbnRzIHVudGlsIGl0IGlzIHN0b3JlZCBvbiB0 aGUgdXNlcidzIGRldmljZTwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT5NVzogVGhpcyBpcyBzaW1w bHkgbm90IGNvcnJlY3QsIHNpbmNlIHRoZXJlIGFyZSBodW5kcmVkcyBvZiBleGFtcGxlcyBvZiBk ZXZpY2VzIHdoaWNoIHN1cHBvcnQgdHJpY2stcGxheSB1c2luZyBIVFRQIHN0cmVhbWluZyB0ZWNo bmlxdWVzIHdpdGhvdXQgc3RvcmluZyB0aGUgd2hvbGUgY29udGVudCBvbiB0aGUgdXNlcnMgZGV2 aWNlLjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhl bHZldGljYTsgV0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj48Rk9O VCBzaXplPTQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5bUWluXTogRmFzdCBmb3J3YXJkIGNhcGFi aWx0eSBpcyBub3QgdGhlIG1vc3QgaW1wb3J0YW50IGZlYXR1cmUgd2UgYXJlIGxvb2tpbmcgZm9y LiBIb3dldmVyIEkgYW0gaGFyZCB0byBiZWxpZXZlIGV4aXN0aW5nIEhUVFAgc3RyZWFtaW5nIHRl Y2huaXF1ZXMgY2FuIHByb3ZpZGUgdGhlIHNhbWUgZGVncmVlIG9mIHBsYXliYWNrPC9GT05UPjwv U1BBTj48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhlbHZldGljYTsgV0hJVEUtU1BBQ0U6IG5v cm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj48Rk9OVCBzaXplPTQgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj5jb250cm9sIHRoYXQgRFZEIHBsYXllciBjYW4gcHJvdmlkZXMgb3IgUlRTUCBwcm90 b2NvbCBwcm92aWRlcy4gRS5nLiwgSW4gdGhlIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29y aXRobXMsIHRoZSB0cmljayBwbGF5IGlzIGxpbWl0ZWQgdG8gcGF1c2UvcmVzdW1lL3N0b3AgYnkg ZHJpdmluZyB0aGUgSFRUUCByZXF1ZXN0LiBJZiB0aGUgY29udGVudHMgaGFzbid0IGJlZW4gZG93 bG9hZGVkICBhbmQgdGhlIGNvbnN1bWUgd2FudCBmYXN0IGZvcndhcmQsIHRoZSBIVFRQIGNsaWVu dCBuZWVkcyB0byBpc3N1ZSBhbm90aGVyIG5ldyBIVFRQIHJlcXVlc3QgdG8gZmV0Y2ggdGhlIGNv bnRlbnRzIHdoaWNoIHdpbGw8L0ZPTlQ+PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTog SGVsdmV0aWNhOyBXSElURS1TUEFDRTogbm9ybWFsIiBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPjxG T05UIHNpemU9NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmNhdXNlIHVuYWNjZXB0YWJsZSBsYXRl bmN5IHRvIHRoZSBjb25zdW1lci48L0ZPTlQ+PC9TUEFOPjwvUFJFPjwvRElWPjwvQkxPQ0tRVU9U RT48L0RJVj48L0JMT0NLUVVPVEU+DQogIDxESVY+W01XXSBBZ2FpbiwgdGhlIGV4cGVyaWVuY2Ug b2YgbWlsbGlvbnMgb2YgZXhpc3RpbmcgY3VzdG9tZXJzIHJlZnV0ZXMgd2hhdCANCiAgeW91IGNs YWltLiBXaHkgZG8geW91IHRoaW5rIGl0IGlzIG5lY2Vzc2FyaWx5IHNvIHNsb3cgdG8gaXNzdWUg YSBuZXcgSFRUUCANCiAgcmVxdWVzdCBmb3IgYSBkaWZmZXJlbnQgcGFydCBvZiB0aGUgY29udGVu dD88L0RJVj4NCiAgPERJVj4mbmJzcDs8L0RJVj4NCiAgPERJVj5bUWluXTogWW91IGRpZG4ndCBz ZWUgdGhlIHJlYW9uIGJlaGluZCB0aGlzLCBiZWNvcyB0aGUgZXhpc3RpbmcgY3VzdG9tZXJzIA0K ICBoYXMgbm8gY2hvaWNlIHdoZW4gdGhleSB2aWV3IGxpdmUgc3RyZWFtaW5nLCB3aGF0IHRoZXkg Y2FuIGdldCBpcyBjbG9zZSB0byANCiAgbGl2ZSBleHBlcmllbmNlIHJhdGhlciB0aGFuIHJlYWwg dGltZSB1c2VyIGV4cGVyaWVuY2UuIE9wZXJhdG9lciBkbyBub3RoaW5nIA0KICBmb3IgdGhlaXIg bmV0d29yayB0byBtYWtlIGh0dHAgc3RyZWFtaW5nIG1vcmUgY29udHJvbGxhYmxlIGFuZCBtYW5h Z2FibGUuIA0KICBUaGVyZWZvcmUgbW9yZSBhbmQgbW9yZSBjb25zdW1lciZuYnNwO3RlbmQgdG8m bmJzcDtjaG9vc2Ugbm9uLWxpdmUgY29udGVudC4gDQogIHRoYXQncyB3aHkgd2Ugc2VlIG1vcmUg YW5kIG1vcmUgbm9uLWxpdmUgY29udGVudCBjb25zdW1lcnMgcmF0aGVyIHRoYW4gbGl2ZSANCiAg Y29udGVudHMgY29uc3VtZXJzLiA8L0RJVj4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxCTE9DS1FV T1RFIHR5cGU9ImNpdGUiPg0KICAgIDxESVY+DQogICAgPEJMT0NLUVVPVEUgDQogICAgc3R5bGU9 IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJ TkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAg ICAgPERJVj48UFJFIGNsYXNzPW5ld3BhZ2U+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2 ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+QSBmaXJz dCBzdGVwIGluIGNvbnNpZGVyaW5nIHdoYXQsIGlmIGFueSwgd29yayBzaG91bGQgYmUgZG9uZSBo ZXJlIG1pZ2h0IGJlIHRvIGNvbnRhY3QgdGhvc2Ugb3JnYW5pemF0aW9ucyB3aGljaCBhcmUgc3Rh bmRhcmRpemluZyB0aGUgaGlnaGVyIGxheWVycyBvZiBIVFRQIHN0cmVhbWluZyBzeXN0ZW1zIChl LmcuIG1hbmlmZXN0IGFuZCBmaWxlIGZvcm1hdHMpIGFuZCBhc2sgd2hldGhlciB0aGVyZSBhcmUg ZGVmaWNpZW5jaWVzIHRoZXkgc2VlIGluIElFVEYgcHJvdG9jb2xzIHRoYXQgY291bGQgYmUgdXNl ZnVsbHkgYWRkcmVzc2VkIGJ5IHRoZSBJRVRGLiBXaGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGF2b2lk IGluIHRoZSBJRVRGIGlzIGR1cGxpY2F0aW5nIHRoZSB3b3JrIG9mIHRoZXNlIG90aGVyIGJvZGll cy48L1NQQU4+PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlM WTogSGVsdmV0aWNhOyBXSElURS1TUEFDRTogbm9ybWFsIiBjbGFzcz1BcHBsZS1zdHlsZS1zcGFu PkJlc3QsPC9TUEFOPjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9OVC1G QU1JTFk6IEhlbHZldGljYTsgV0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUt c3Bhbj48QlI+PC9TUEFOPjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9O VC1GQU1JTFk6IEhlbHZldGljYTsgV0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5 bGUtc3Bhbj5NYXJrIFdhdHNvbjwvU1BBTj48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PEZPTlQg Y2xhc3M9QXBwbGUtc3R5bGUtc3BhbiBmYWNlPUhlbHZldGljYT48U1BBTiBzdHlsZT0iV0hJVEUt U1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj5OZXRmbGl4IEluYy48L1NQQU4+ PC9GT05UPjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6 IEhlbHZldGljYTsgV0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj48 QlI+PC9TUEFOPjwvUFJFPjwvRElWPg0KICAgICAgPERJVj48QlI+PC9ESVY+DQogICAgICA8RElW PjxCUj48L0RJVj4NCiAgICAgIDxESVY+PEJSPg0KICAgICAgPERJVj4NCiAgICAgIDxESVY+T24g T2N0IDEwLCAyMDEwLCBhdCAxMjo0MyBBTSwgQWxpIEMuIEJlZ2VuIChhYmVnZW4pIHdyb3RlOjwv RElWPjxCUiANCiAgICAgIGNsYXNzPUFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmU+DQogICAgICA8 QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICAgICAgPERJVj48QlI+PEJSPg0KICAgICAgICA8 QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48L0JM T0NLUVVPVEU+DQogICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPkZyb206IDxBIA0KICAg ICAgICAgIGhyZWY9Im1haWx0bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmciPjxBIA0K ICAgICAgICAgIGhyZWY9Im1haWx0bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmciPmh0 dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9yZzwvQT48L0E+IA0KICAgICAgICAgIFttYWlsdG86 aHR0cHN0cmVhbWluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGFycyANCiAgICAg ICAgRWdnZXJ0PEJSPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0 ZSI+U2VudDogRnJpZGF5LCBPY3RvYmVyIDA4LCAyMDEwIDQ6MTcgDQogICAgICAgIFBNPEJSPjwv QkxPQ0tRVU9URT4NCiAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+VG86IENvbGluIFBl cmtpbnM8QlI+PC9CTE9DS1FVT1RFPg0KICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5D YzogPEEgaHJlZj0ibWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmciPjxBIA0KICAgICAgICAg IGhyZWY9Im1haWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnIj5odHRwc3RyZWFtaW5nQGlldGYu b3JnPC9BPjwvQT48QlI+PC9CTE9DS1FVT1RFPg0KICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJj aXRlIj5TdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQgU3RhdHVzIA0KICAgICAg ICAgIGFuZCBPdXIgR29hbDxCUj48L0JMT0NLUVVPVEU+DQogICAgICAgIDxCTE9DS1FVT1RFIHR5 cGU9ImNpdGUiPjxCUj48L0JMT0NLUVVPVEU+DQogICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNp dGUiPk9uIDIwMTAtMTAtNywgYXQgMTQ6MTYsIENvbGluIFBlcmtpbnMgDQogICAgICAgICAgd3Jv dGU6PEJSPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQog ICAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+VGhlcmUgYXJlIGNsZWFybHkgc29tZSBp c3N1ZXMgdG8gY29uc2lkZXIgDQogICAgICAgICAgICBoZXJlLiBXaGF0IHNlZW1zIHRvIGJlPEJS PjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQogICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNp dGUiPg0KICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPm1pc3NpbmcgZnJvbSB0aGUg ZGlzY3Vzc2lvbiB0byBtZSB0aG91Z2gsIGlzIA0KICAgICAgICAgICAgc29tZSBpZGVudGlmaWNh dGlvbiBvZjxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgICAgICA8QkxPQ0tRVU9U RSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj50aGUgY29u Y3JldGUgcHJvYmxlbXMuIFdoYXQgcHJvdG9jb2wgcGllY2VzIA0KICAgICAgICAgICAgZG8gd2Ug bmVlZCwgYnV0IG5vdCBoYXZlPzxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgICAg ICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJj aXRlIj5XaGF0IHByb3RvY29scyBhcmUgcHJvYmxlbWF0aWMsIGFuZCBuZWVkIA0KICAgICAgICAg ICAgZW5oYW5jZW1lbnQ/IElzIHRoZXJlPEJSPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQog ICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgICAgICAgIDxCTE9DS1FVT1RFIHR5 cGU9ImNpdGUiPnByb3RvY29sIHdvcmsgdG8gZG8gaW4gSUVURiwgb3Igc2hvdWxkIHdlIGJlIA0K ICAgICAgICAgICAgZG9jdW1lbnRpbmcgYmVzdCBjdXJyZW50PEJSPjwvQkxPQ0tRVU9URT48L0JM T0NLUVVPVEU+DQogICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgICAgICAgIDxC TE9DS1FVT1RFIHR5cGU9ImNpdGUiPnByYWN0aWNlcyBmb3IgdXNpbmcgdGhlIGV4aXN0aW5nIHBy b3RvY29scyANCiAgICAgICAgICAgIGFuZC9vciByZWx5aW5nIG9uIG90aGVyPEJSPjwvQkxPQ0tR VU9URT48L0JMT0NLUVVPVEU+DQogICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAg ICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPmJvZGllcyB0byBmaWxsIHRoZSANCiAgICAg ICAgZ2Fwcz88QlI+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgPEJMT0NLUVVP VEUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+PEJSPjwv QkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQogICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUi Pg0KICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPlRoZSBkcmFmdC13dS1odHRwLXN0 cmVhbWluZy1vcHRpbWl6YXRpb24tcHMgDQogICAgICAgICAgICBpcyBhIGdvb2Qgc3RhcnQgYXQg c3VjaCBhbjxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgICAgICA8QkxPQ0tRVU9U RSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5hbmFseXNp cywgYnV0IGRvZXNuJ3QgZ28gZGVlcCBlbm91Z2ggdG8gbGV0IA0KICAgICAgICAgICAgdXMgZGVj aWRlIHdoYXQgd29yayBJRVRGPEJSPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQogICAgICAg IDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNp dGUiPnNob3VsZCBkby48QlI+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgPEJM T0NLUVVPVEUgdHlwZT0iY2l0ZSI+PEJSPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgPEJMT0NLUVVP VEUgdHlwZT0iY2l0ZSI+KzE8QlI+PC9CTE9DS1FVT1RFPg0KICAgICAgICA8QkxPQ0tRVU9URSB0 eXBlPSJjaXRlIj48QlI+PC9CTE9DS1FVT1RFPg0KICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJj aXRlIj5UaGUga2V5IHF1ZXN0aW9uIHJlYWxseSBpcyAid2hhdCBkbyB5b3UgdGhpbmsgDQogICAg ICAgICAgdGhlIElFVEYgbmVlZHMgdG8gZG8/IjxCUj48L0JMT0NLUVVPVEU+PEJSPkkgaW1hZ2lu ZSB0aGUgb25seSB3b3JrIHRoZSANCiAgICAgICAgSUVURiBzaG91bGQgZG8gKGlmIHdlIGRlY2lk ZSB0bykgaXMgdGhlIHRyYW5zcG9ydCBhbmQgSFRUUC1sYXllciANCiAgICAgICAgb3B0aW1pemF0 aW9uIGZvciBiZXR0ZXIgc3RyZWFtaW5nIHBlcmZvcm1hbmNlLjxCUj48QlI+LWFjYmVnZW48QlI+ PEJSPg0KICAgICAgICA8QkxPQ0tRVU9URSANCiAgICAgICAgdHlwZT0iY2l0ZSI+TGFyczxCUj48 L0JMT0NLUVVPVEU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188QlI+aHR0cHN0cmVhbWluZyANCiAgICAgICAgbWFpbGluZyBsaXN0PEJSPjxBIGhyZWY9Im1h aWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnIj48QSANCiAgICAgICAgaHJlZj0ibWFpbHRvOmh0 dHBzdHJlYW1pbmdAaWV0Zi5vcmciPmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8L0E+PC9BPjxCUj48 QSANCiAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9o dHRwc3RyZWFtaW5nIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBz dHJlYW1pbmc8L0E+PEJSPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjwvRElWPg0K ICAgICAgPFA+PC9QPg0KICAgICAgPEhSPg0KDQogICAgICA8UD48L1A+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+aHR0cHN0cmVhbWluZyANCiAgICAg IG1haWxpbmcgbGlzdDxCUj48QSANCiAgICAgIGhyZWY9Im1haWx0bzpodHRwc3RyZWFtaW5nQGll dGYub3JnIj5odHRwc3RyZWFtaW5nQGlldGYub3JnPC9BPjxCUj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmc8QlI+PC9CTE9DS1FVT1RFPjwvRElWPjwv QkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== --Boundary_(ID_ExWOXQtFeP9X3i6XsmGg6w)-- From sunseawq@huawei.com Wed Oct 13 23:48:52 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F783A6822 for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.48 X-Spam-Level: *** X-Spam-Status: No, score=3.48 tagged_above=-999 required=5 tests=[AWL=-2.828, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPar+GQQza64 for <httpstreaming@core3.amsl.com>; Wed, 13 Oct 2010 23:48:48 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 81C5B3A6868 for <httpstreaming@ietf.org>; Wed, 13 Oct 2010 23:48:48 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA900GI0PKH3Z@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:48:17 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA900DCKPKGMM@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:48:16 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA900JK3PKF1Y@szxml06-in.huawei.com> for httpstreaming@ietf.org; Thu, 14 Oct 2010 14:48:16 +0800 (CST) Date: Thu, 14 Oct 2010 14:48:15 +0800 From: Qin Wu <sunseawq@huawei.com> To: luzhihui <lzh@fudan.edu.cn>, Roni Even <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org> Message-id: <03f801cb6b6b$c75e7480$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <201010121253579157105@fudan.edu.cn> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 06:48:52 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogImx1emhpaHVpIiA8bHpo QGZ1ZGFuLmVkdS5jbj4NClRvOiAiUWluIFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT47ICJSb25p IEV2ZW4iIDxFdmVuLnJvbmlAaHVhd2VpLmNvbT47ICInRGF2aWQgQS4gQnJ5YW4nIiA8ZGJyeWFu QGV0aGVybm90Lm9yZz4NCkNjOiA8aHR0cHN0cmVhbWluZ0BpZXRmLm9yZz4NClNlbnQ6IFdlZG5l c2RheSwgT2N0b2JlciAxMywgMjAxMCAxMjo1NCBBTQ0KU3ViamVjdDogUmU6IFJlOiBbaHR0cHN0 cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQoNCg0KPiANCj4gDQo+ID09PT09 PT0gMjAxMC0xMC0wOCAwMzoyMzowNCDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KPiANCj4+PiBJ biBnZW5lcmFsIEkgdGhpbmsgdGhhdCBieSBoYXZpbmcgYSB1c2UgY2FzZXMgZG9jdW1lbnQgdGhh dCBjb3ZlcnMgdGhlDQo+Pj4gc2NlbmFyaW9zIHRoYXQgbG9vayBpbXBvcnRhbnQgdG8gdGhlIGdy b3VwIHdlIGNhbiBhY2hpZXZlIGEgYmV0dGVyDQo+Pj4gdW5kZXJzdGFuZGluZyBvZiB3aGF0IGlz IHRoZSBjaGFydGVyIG9mIHRoZSB3b3JrLiANCj4+DQo+PltRaW5dOiBHb29kIHBvaW50LCB3ZSBk byBoYXZlIHNvbWUgdXNlIGNhc2VzIHdoaWNoIGhhc24ndCBiZWVuIHRha2VuIG91dCBmcm9tIA0K Pj5IVFRQIFN0cmVhbWluZyBQcm9ibGVtIFN0YXRlbWVudCBkcmFmdCAoaHR0cDovL3d3dy5pZXRm Lm9yZy9pZC9kcmFmdC13dS1odHRwLXN0cmVhbWluZy1vcHRpbWl6YXRpb24tcHMtMDIudHh0KS4N Cj4+Rm91ciB0eXBpY2FsIHVzZSBjYXNlcyBpbiBteSBtaW5kIHdvdWxkIGJlOg0KPj5jYXNlIDE6 IExpdmUgU3RyZWFtaW5nIE1lZGlhIGJyb2FkY2FzdA0KPj5jYXNlIDI6IFJUUCB0byBIVFRQIEdh dGV3YXksIHdoaWNoIGlzIHBvc3NpYmxlIGNhc2UgdG8gYWRkcmVzcyBtdWx0aWNhc3Qgc3VwcG9y dC4NCj4gW1poaUh1aV0gUWluLCB3ZSBrbm93IGh0dHAgaXMgd2ViIGNvbnRlbnQtb3JpZW50ZWQg YXQgYmVnaW5pbmcsIHNvIHdlIGhhdmUgUmVhbCBUaW1lIFN0cmVhbWluZyBQcm90b2NvbCAoUlRT UCkgYW5kIE1NUyAoTWljcm9zb2Z0IE1lZGlhIFNlcnZlciBwcm90b2NvbCkgDQo+IG9yaWVudGVk IGZvciBzdHJlYW1pbmcsUlRTUCBhbmQgTU1TIGFyZSBiYXNlZCBvbiBSVFAsIHRoZXkgYXJlIHBv cHVsYXIgZm9yIHN0cmVhbWluZyBjb250ZW50IGRlbGl2ZXJ5LiBCdXQgbm93IGJlY2F1c2Ugb2Yg c2ltcGxpY2l0eSBvZiBIVFRQLCBIVFRQIGNvbWUgDQo+IGFnYWluIGZvciBzdHJlYW1pbmcuICBX ZSBrbm93IHRoaXMgaXMgSFRUUCAiU2Vjb25kIFNwcmluZyINCj4gU28gRmxhc2ggcGxheWVyIG5v dyBiZWNvbWUgbW9yZSBwb3B1bGFyIHRoYW4gUmVhbCBwbGF5ZXIgYW5kIE1lZGlhIFBsYXllci4g IEJ1dCB3ZSBrbm93IFJUUCBwcm90b2NvbCBpcyB2ZXJ5IGZyaWVuZGx5IHRvIHN0cmVhbWluZyBj b250ZW50IGNodW5rLg0KPiBTbywgSWYgd2UgZGVzaWduICBSVFAgdG8gSFRUUCBHYXRld2F5LCB3 ZSBzaG91bGQgY29uc2lkZXIgaG93IHRvIHV0aWxpemUgdGhlIGV4aXN0aW5nIGFkdmFudGFnZXMg b2YgUlRQIG92ZXIgVENQLg0KDQpbUWluXTogSSBhbSBub3Qgc3VyZSB3ZSBuZWVkIHRvIGJ1aWxk IHN1Y2ggR2F0ZXdheS4gVGhlIG1vdGl2YXRpb24gdG8gbG9vayBkZWVwIGludG8gaXQgaXMgaG93 IHRvIGludHJvZHVjZSBtdWx0aWNhc3Qgc3VwcG9ydCBmb3IgSFRUUCBzdHJlYW1pbmcuDQpPbmUg ZXhpc3RpbmcgcHJvdG9jb2wgd2UgbWF5IGxvb2sgYXQgaXMgUlRNUCwgb25lIG9mIGZlYXR1cmVz IGluIFJUTVAgaXMgbXVsdGljYXN0IHN1cHBvcnQuDQoNCj4+Y2FzZSAzOiAiTXVsdGktU2NyZWVu IiBTZXJ2aWNlIERlbGl2ZXJ5DQo+PmNhc2UgNDogIEhldGVyb2dlbmVvdXMgSGFuZG92ZXINCj4+ SG9wZSBpdCBoZWxwcyBnZXQgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyB3aGF0IHRoZSBzY2VuYXJp b3MgbWF5IG1heSBsb29rIGxpa2UuIElmIGFueWJvZHkgd291bGQgbGlrZSB0byBjb250cmlidXRl IHRvIHVzZSBjYXNlIGRvY3VtZW50DQo+Pm9yIHByb3ZpZGUgbW9yZSBpbnB1dCwgdGhhdCB3aWxs IGJlIGdyZWF0Lg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5odHRwc3RyZWFtaW5nIG1haWxpbmcgbGlzdA0KPj5odHRwc3RyZWFtaW5nQGlldGYu b3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cHN0cmVhbWlu Zw0KPiANCj4gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9DQo+IA0KPiAN Cj4gDQo+IKGhoaGhoaGhoaFaaGlIdWkNCj4gICAgDQo+IFRlbKO6MDIxLTY1MTA3NjA3o6w2NTY0 MzE4Nw0KPiBGYXijujAyMS02NTY0Nzg5NA0KPiBNb2KjujEzODE4MTY4OTE5DQo+IKGhoaGhoaGh oaGhoaGhoaGhoaGhMjAxMC0xMC0xMg0KPg== From watsonm@netflix.com Thu Oct 14 09:25:22 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDB63A6B17 for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 09:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avt8c516OwMw for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 09:25:20 -0700 (PDT) Received: from mx2.netflix.com (mx2.netflix.com [208.75.77.145]) by core3.amsl.com (Postfix) with ESMTP id E17DD3A6A9F for <httpstreaming@ietf.org>; Thu, 14 Oct 2010 09:25:19 -0700 (PDT) Received: from ExchFE102.netflix.com (exchfe102.netflix.com [10.64.32.102]) by mx2.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o9EGQ3ek003464; Thu, 14 Oct 2010 09:26:03 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE102.netflix.com ([fe80::416e:22e0:ebdf:14b0%14]) with mapi; Thu, 14 Oct 2010 09:26:02 -0700 From: Mark Watson <watsonm@netflix.com> To: Qin Wu <sunseawq@huawei.com> Date: Thu, 14 Oct 2010 09:26:01 -0700 Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActrvH2F1Bv6wBRwQ2e5HHqHZrGAUw== Message-ID: <B9E38A06-8392-4CCF-9160-D55F43BD75D8@netflix.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> <029d01cb693a$7f515f50$30298a0a@china.huawei.com> <9062141B-82B8-4FF0-98C2-EB803BCA3DD7@netflix.com> <03e201cb6b6a$db1ae770$30298a0a@china.huawei.com> In-Reply-To: <03e201cb6b6a$db1ae770$30298a0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B9E38A0683924CCF9160D55F43BD75D8netflixcom_" MIME-Version: 1.0 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org>, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 16:25:22 -0000 --_000_B9E38A0683924CCF9160D55F43BD75D8netflixcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBPY3QgMTQsIDIwMTAsIGF0IDI6NDEgUE0sIFFpbiBXdSB3cm90ZToNCg0KSGksDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBNYXJrIFdhdHNvbjxtYWlsdG86d2F0c29u bUBuZXRmbGl4LmNvbT4NClRvOiBRaW4gV3U8bWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb20+DQpD YzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pPG1haWx0bzphYmVnZW5AY2lzY28uY29tPiA7IGh0dHBz dHJlYW1pbmdAaWV0Zi5vcmc8bWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+IDsgQ29saW4g UGVya2luczxtYWlsdG86Y3NwQGNzcGVya2lucy5vcmc+DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVy IDEyLCAyMDEwIDEyOjUwIEFNDQpTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQg U3RhdHVzIGFuZCBPdXIgR29hbA0KDQpTb21lIGNvbW1lbnRzIG9ubGluZSAuLi4NCg0KU2VudCBm cm9tIG15IGlQaG9uZQ0KDQpPbiBPY3QgMTEsIDIwMTAsIGF0IDc6NTAgUE0sICJRaW4gV3UiIDxz dW5zZWF3cUBodWF3ZWkuY29tPG1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tPj4gd3JvdGU6DQoN CkhpLA0KVGhpcyBpcyB3aGF0IHdlIGhhZCBkaXNjdXNzZWQgIGluIHRoZSBESVNQQVRDSCBtYWls aW5nIGxpc3QgYmVmb3JlIHdlIG1vdmUgdG8gdGhpcyBkaXNjdXNzIGxpc3QuDQpJZiB5b3UgbG9v ayBhdCB0aGUgZGVzY3JpcHRpb24gb2YgZGlzY3VzcyBsaXN0LCAiDQpvZmZlcnMgbW9yZSBlZmZp Y2llbnQgdHJhbnNwb3J0DQphbmQgYmV0dGVyIG5ldHdvcmsgY2FwYWJpbGl0eSBmb3IgcmVhbCB0 aW1lIHN0cmVhbWluZyBtZWRpYQ0KYW5kIGFsbG93cyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggb3Ro ZXIgc3RyZWFtaW5nIHRlY2huaXF1ZXMgYW5kIGV4aXN0aW5nIFByb2dyZXNzaXZlIGRvd2xvYWRl ZCBiYXNlZA0KSFRUUCBzdHJlYW1pbmcgaW1wbGVtZW50YXRpb24uDQoiDQp5b3Ugd2lsbCBzZWUg d2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UuDQpUaGVyZWZvcmUgb25lIGltcG9ydGFudCBnb2FsIGRp c2N1c3NlZCBpbiB0aGUgZHJhZnQgYWltcyBhdCBkZXZlbG9waW5nIGludGVyb3BlcmFibGUgc29s dXRpb24gdG8NCnByb3ZpZGUgYmV0dGVyIHRyYW5zcG9ydCB0byBzYXRpc2Z5IHRoZSByZWFsIHRp bWUgc3RyZWFtaW5nIFFPRSByZXF1aXJlbWVudC4gRXNwZWNpYWxseSBzZXJ2ZXJhbA0KY2hhbmxs ZW5nZXMvcHJvYmxlbXMgd2UgZXhwbG9yZWQgaW4gdGhlIGRyYWZ0IGxpc3RlZCBiZWxvdy4NCg0K UmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IE1hcmsg V2F0c29uPG1haWx0bzp3YXRzb25tQG5ldGZsaXguY29tPg0KVG86IEFsaSBDLiBCZWdlbiAoYWJl Z2VuKTxtYWlsdG86YWJlZ2VuQGNpc2NvLmNvbT4NCkNjOiA8bWFpbHRvOmh0dHBzdHJlYW1pbmdA aWV0Zi5vcmc+IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8bWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0 Zi5vcmc+IDsgQ29saW4gUGVya2luczxtYWlsdG86Y3NwQGNzcGVya2lucy5vcmc+DQpTZW50OiBT dW5kYXksIE9jdG9iZXIgMTAsIDIwMTAgNzoxMyBBTQ0KU3ViamVjdDogUmU6IFtodHRwc3RyZWFt aW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KQWxsLA0KDQpJIHdvdWxkIGxpa2Ug dG8gYWRkIG15IHN1cHBvcnQgdG8gdGhlIGNvbW1lbnRzIGJlbG93LiBTcGVjaWZpY2FsbHksIEkg dGhpbmsgaWYgdGhlIElFVEYgY29uc2lkZXJzIHdvcmsgaW4gdGhpcyBhcmVhIGl0IHNob3VsZCBm b2N1cyBvbiB0aGUgSFRUUCBhbmQgVENQIHByb3RvY29scy4gQW55IHN1Y2ggd29yayBtYXkgbm90 IGJlIHNwZWNpZmljIHRvIEhUVFAtc3RyZWFtaW5nIChpLmUuIGVuaGFuY2VtZW50cyB0aGF0IGFy ZSBhdCBmaXJzdCBtb3RpdmF0ZWQgYnkgSFRUUCBTdHJlYW1pbmcgbWF5IGhhdmUgYnJvYWRlciBh cHBsaWNhYmlsaXR5LCBhbmQgdGhpcyBzaG91bGQgYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQpLg0K DQpJbiB0aGUgZHJhZnQgSSBkbyBub3Qgc2VlIGEgY2xlYXIgb3IgY29ycmVjdCBpZGVudGlmaWNh dGlvbiBvZiB0aGUgcHJvYmxlbXMuIEZvciBleGFtcGxlIGluIHRoZSBpbnRyb2R1Y3Rpb24gdGhl IGZvbGxvd2luZyBhcmUgc3RhdGVkIGFzIGlzc3VlczoNCg0KICAgLSBDbGllbnQgcG9sbGluZyBm b3IgZWFjaCBuZXcgZGF0YSBpbiBjaHVua3MgdXNpbmcgSFRUUCByZXF1ZXN0cyBpcw0KICAgbm90 IGVmZmljaWVudCB0byBkZWxpdmVyIGhpZ2gtcXVhbGl0eSB2aWRlbyBjb250ZW50IGFjcm9zcyB0 aGUNCiAgIEludGVybmV0DQoNCk1XOiBTZXZlcmFsIGNvbXBhbmllcywgaW5jbHVkaW5nIG15IGVt cGxveWVyLCBhcmUgc3VjY2Vzc2Z1bGx5IG9wZXJhdGluZyBsYXJnZSBzY2FsZSBIVFRQIHN0cmVh bWluZyBzeXN0ZW1zIHRoYXQgZG8gZWZmaWNpZW50bHkgZGVsaXZlciBoaWdoLXF1YWxpdHkgdmlk ZW8gY29udGVudCBhY3Jvc3MgdGhlIEludGVybmV0LCBzbyByZWFsaXR5IHNlZW1zIHRvIHJlZnV0 ZSB0aGlzIHN0YXRlbWVudC4NCg0KW1Fpbl06IE5vdCBzdXJlIHRoZXkgY2FuIHByb3ZpZGUgdGhl IFRWIGV4cGVyaWVuY2UgZm9yIGFsbCB0aGUgY29ubmVjdGVkIGRldmljZXMgbGlrZSBzbWFydHBo b25lcywgUENzIGFuZCB0YWJsZXRzLiBBbHNvIG5vdCBzdXJlIHRoZXkgY2FuIHByb3ZpZGUgdGhl IHNhbWUgcXVhbGl0eSBvZiBleHBlcmVuY2UgZm9yIGFsbCB0aGUgYWxsIHRoZSBjb25uZWN0ZWQg ZGV2aWNlcy4gQXMgd2UgZGlzY3Vzc2VkIGluIHRoaXMgdGhyZWFkLCBhIG1pbmltdW0gb2YgMjAg c2Vjb25kcyB0byBzdGFydCB5b3VyIHZpZGVvIG9mdGVuIGZydXN0cmF0ZWQgdXNlcnMgdG8ga2Vl cCBvbiB3YXRjaGluZyBhbmQgcHJvdmlkZSB2ZXJ5IGxpbWl0ZWQgdXNlciBleHBlcmllbmNlLg0K DQpDYW4geW91IGJlIG1vcmUgZXhwbGljaXQgYWJvdXQgdGhlIHByb2JsZW1zIHRoYXQgeW91IHNl ZT8gSSdtIG5vdCBzdXJlIHdoZXJlIHRoZSAyMHMgZmlndXJlIGNvbWVzIGZyb20uIEkgZG8gbm90 IHNlZSBhbnkgcHJvYmxlbSBpbiBzdXBwb3J0aW5nIHN0YXJ0dXAgdGltZXMgY29tcGFyYWJsZSB0 byBUViBjaGFubmVsIGNoYW5nZSB3aXRoIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nLg0KDQpJIGFt IG5vdCBzYXlpbmcgdGhlcmUgaXMgbm8gcm9vbSBmb3IgaW1wcm92ZW1lbnQgaW4gdGhlIHZhcmlv dXMgZGVwbG95ZWQgc3lzdGVtcywgYnV0IEkgZG8gbm90IHNlZSBtYWpvciB0ZWNobmljYWwgaW1w ZWRpbWVudHMgdG8gZWZmaWNpZW50IGRlbGl2ZXJ5IG9mIGhpZ2ggcXVhbGl0eSB2aWRlbyB1c2lu ZyBIVFRQIFN0cmVhbWluZy4NCg0KW1Fpbl06Tm90IG9ubHkgc3RhcnVwIGxhdGVuY3kgYnV0IGFs c28gZGVsYXkgdy5yLnQuIHJlYWwgdGltZSBzdHJlYW1pbmcuIEkgdGhpbmsgeW91IG5lZ2VjdCBp dCBiZWNvcyBZb3UgZGlkbid0IGdldCBpbnRvIHRoZSBkaXNjdXNzaW9uIGxpc3QuDQoNCk9uIHRo ZSBvdGhlciBoYW5kLCBJIHRoaW5rIHdlIHNob3VsZCBiZWFyIGluIG1pbmQgSFRUUCBpcyBmb3Jt ZXJseSBkZXNpZ25lZCBmb3IgYnJvd3Npbmcgd2VicGFnZSwgdHJhbnNwb3J0IHN0YXRpYyBjb250 ZW50cyBsaWtlIEhUTUwgcGFnZSwgcGx1Z2luLCBwaWN0dXJlLCB3aGVuIHdlIGFyZSBnb2luZyB0 byB1c2UgSFRUUCB0byBkZWxpdmVyIHJlYWwgdGltZSBzdHJlYW1pbmcgY29udGVudHMsIHdlIGNh biBub3QgZXhwZWN0IHRvIGdldCBoaWdoZXIgdXNlciBleHBlcmllbmNlLiBUaGVyZWZvcmUgdGhl IGN1cnJlbnQgc3RyZWFtaW5nIHNjaGVtZXMgY2FuIG9ubHkgb2ZmZXIgYSBiZXR0ZXIgZXhwZXJp ZW5jZSBvdmVyIHNsb3dlciBjb25uZWN0aW9ucy4NCg0KICAgLSBTZWdtZW50YXRpb24gY2FwYWJp bGl0eSByZXF1aXJlcyBvdmVyLXV0aWxpemluZyBDUFUgYW5kIGJhbmR3aWR0aA0KICAgcmVzb3Vy Y2VzLCB3aGljaCBtYXkgbm90IGJlIGEgZGVzaXJhYmxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIGlt cHJvdmUNCiAgIHRoZSBxdWFsaXR5IG9mIHN0cmVhbWluZyBtZWRpYSBkZWxpdmVyeQ0KDQpNVzog SXQgaXMgbm90IGNsZWFyIHRoYXQgc2VnbWVudGF0aW9uIHBlciBzZSBpcyBDUFUtaW50ZW5zaXZl IG9yIGhhcyBhbnkgbm9uLW5lZ2xpZ2FibGUgZWZmZWN0IG9uIGJhbmR3aWR0aCB1c2FnZS4NCg0K W1Fpbl06IFNpbmNlIEhUVFAgc3RyZWFtaW5nIHNlcnZlciBpcyB0aGUgY29tYmluYXRpb24gb2Yg c3RyZWFtaW5nIHNlcnZlciBhbmQgcmVndWxhciB3ZWIgc2VydmVyLCBJIHRoaW5rIHRoZSBhbnN3 ZXIgaXMgYm90aC4NCg0KW01XXSB3aGF0IGRvIHlvdSBtZWFuIGJ5JyBodHRwIHN0cmVhbWluZyBz ZXJ2ZXInID8NCg0KW1Fpbl06IFdpdGggc3RyZWFtaW5nIGNhcGFiaWxpdHkgYW5kIGZ1bmN0aW9u YWxpdHkgdG8gcmVzcG9uZCB0byBIVFRQIGNvbm5lY3Rpb24uDQoNCltNV10gSSdtIG5vdCBzdXJl IHdoYXQgb25lIG9mIHRob3NlIGlzLiBJdCBzb3VuZHMgbGlrZSBpdCBpcyBub3QgYSByZWd1bGFy IHdlYiBzZXJ2ZXIuIEkgdGhpbmsgaXQncyBhbiBlc3NlbnRpYWwgZmVhdHVyZSBvZiBtb2Rlcm4g SFRUUCBzdHJlYW1pbmcgdGhhdCBpdCB3b3JrcyB3aXRoIHJlZ3VsYXIgd2ViIGluZnJhc3RydWN0 dXJlLg0KDQoNCiAgIC0gTGFjayBvZiBRb1MgZ3VhcmFudGVlIG9uIHRoZSBwYWNrZXQgc3dpdGNo aW5nIGJhc2VkIEludGVybmV0ICwgdGhlDQogICBxdWFsaXR5IG9mIEludGVybmV0IG1lZGlhIHN0 cmVhbWluZyBtYXkgc2lnbmlmaWNhbnQgZGVncmFkZSBkdWUgdG8NCiAgIHJpc2luZyB1c2FnZQ0K DQpNVzogQW4gYWx0ZXJuYXRpdmUgdmlldyBpcyB0aGF0IHdoZXJlIHF1YWxpdHkgaXMgZGVncmFk ZWQgZHVlIHRvIGNvbmdlc3Rpb24gdGhpcyBpcyBkdWUgdG8gbGFjayBvZiBiYW5kd2lkdGgsIHJh dGhlciB0aGFuIGEgbGFjayBvZiBRb1MgZ3VhcmFudGVlcy4gQWRhcHRpdmUgSFRUUCBzdHJlYW1p bmcgc3lzdGVtcyBhZGp1c3QgdGhlIHZpZGVvIHF1YWxpdHkgdG8gdGhlIGF2YWlsYWJsZSBiYW5k d2lkdGggaW4gb3JkZXIgdG8gYXZvaWQgcmVidWZmZXJpbmcgZXZlbnRzLiBJdCBpcyB0aGUgYXZh aWxhYmxlIGJhbmR3aWR0aCB0aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIHRvIGltcHJvdmUgcXVh bGl0eS4NCg0KW1Fpbl06IFdoYXQgSSBlbXBoYXNpemUgaGVyZSBpcyB3aXRoIGdyb3dpbmcgcG9w dWxhcml0eSBvZiBIVFRQIHN0cmVhbWluZyB0cmFmZmljLCB3aGVuIHRob3VzYW5kcyBvciBtaWxs aW9ucyBvZiBwZW9wbGUgYXJlIGFjY2Vzc2luZyB0aGUgc2FtZSBtZWRpYSBjb250ZW50cywgdGhl IGJpZyBwcm9ibGVtIHdlIGFyZSBmYWNpbmcgaXMgc2VyaW91cyBoaWdoIGNvbmN1cnJlbmNlIGFj Y2VzcyBpc3N1ZS4gVGhlIHVzZXIgZXhwZXJpZW5jZSB3aWxsIGJlIGdyZWF0bHkgYWZmZWN0ZWQg ZXZlbiB5b3UgaGF2ZSBlbm91Z2ggYXZhaWxhYmxlIGJhbmR3aWR0aC4gU28gdGhpcyBpcyBub3Qg cHVyZSBiYW5kd2lkdGggaXNzdWUuDQoNCltNV10gbWF5YmUgd2UgbWVhbiBkaWZmZXJlbnQgdGhp bmdzIGJ5ICdhdmFpbGFibGUgYmFuZHdpZHRoJy4gRG8geW91IHRoaW5rIGl0IGlzIGEgc2VydmVy IHNjYWxhYmlsaXR5IHByb2JsZW0sIG9yIGEgbmV0d29yayBwcm9ibGVtID8NCg0KW1Fpbl06IHBs ZWFzZSByZWFkIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9odHRwc3RyZWFt aW5nL2N1cnJlbnQvbXNnMDAwMTEuaHRtbA0KDQpbTVddIFN0aWxsIG5vdCBzdXJlIHdoYXQgeW91 J3JlIHJlZmVycmluZyB0byBvdGhlciB0aGFuIGF2YWlsYWJsZSBiYW5kd2lkdGguIFRoZSB0aHJl YWQgbWVudGlvbnMgbXVsdGljYXN0IC0gZG8geW91IHRoaW5rIHRoZXJlIHJlbWFpbnMgd29yayB0 byBkZWxpdmVyIEhUVFAgb2JqZWN0cyBvdmVyIG11bHRpY2FzdCBnaXZlbiB0aGUgd29yayBpbiBS TVQgb3ZlciB0aGUgeWVhcnMgPw0KDQoNCiAgIC0gRXhwZXJpZW5jZSBidXJzdGluZXNzIG9yIG90 aGVyIGR5bmFtaWNzIGNoYW5nZXMgZHVlIHRvIGJhbmR3aWR0aA0KICAgZmx1Y3R1YXRpb25zIGFu ZCBoZXRlcm9nZW5lb3VzIGhhbmRvdmVyLg0KDQpNVzogV2UgaGF2ZSBmb3VuZCB0aGF0IGFkYXB0 aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRobXMgYXJlIHdlbGwgYWJsZSB0byBjb3BlIHdpdGgg YmFuZHdpZHRoIGZsdWN0dWF0aW9ucy4NCg0KW1Fpbl06IEkgZG9uJ3QgZG91YnQgdGhhdCBhZGFw dGl2ZSBIVFRQIHN0cmVhbWluZyBhbGdvcml0aG1zIGNhbiBjb3BlIHdpdGggYmFuZHdpZHRoIGZs dWN0YXRpb24uIEJ1dCBJIGhvcGUgd2UgY2FuIGRvIGJldHRlci5lLmcuLCBhZGFwdGl2ZSBIVFRQ IHN0cmVhbWluZyBhbGdvcml0aG1zIG9ubHkgc3VwcG9ydCBkZWxpdmVyeSBvZiBtdWx0aXBsZSBz dHJlYW1zIG9mIHRoZSBzYW1lIGNvbnRlbnQgd2l0aCB2YXJ5aW5nIHF1YWxpdHkgbGV2ZWxzIGZv ciBkaWZmZXJlbnQgYmFuZHdpZHRoIG9yIGRldmljZXMuIEhvd2V2ZSBob3cgdGhlIHNlcnZlciBp biBwdXNoIG1vZGVsIG9yIGNsaWVudCBpbiBwdWxsIG1vZGVsIGNhbiBxdWljayByZXNwb25zZSB0 byB0aGUgYml0cmF0ZSBjaGFuZ2VzIGlzIGEgcHJvYmxlbSB3ZSBtYXkgbG9vayBhdCxlc3BlY2lh bGx5IHdoZW4gc3dpdGNoaW5nIGJld2VlbiBzdHJlYW1zIG9jY3VycyB2ZXJ5IGZyZXF1ZW50bHku DQoNCltNV10gWWVzLCBidXQgbm90IGEgcHJvYmxlbSBmb3IgdGhlIElFVEYsIEkgdGhpbmsuDQoN CltRaW5dOiBJIGRpZG4ndCBnZXQgd2hhdCB5b3Ugc2FpZC4gYWRhcHRpdmUgSFRUUCBzdHJlYW1p bmcgYWxnb3JpdGhtcyBpcyBjaGFyYWN0ZXJpemVkIGFzICBjbGllbnQgaW5pdGlhdGVkIHB1bGwg bW9kZWwuIFdlIGFyZSBkaXNjdXNzaW5nIHB1c2ggbW9kZWwgb3IgaG93IHRvIHVzZSBwdWxsIG1v ZGVsIHdpdGggcHVzaCBtb2RlbC5XZSBhcmUgdGFsa2luZyBhYm91dCBkaWZmZXJlbnQgbW9kZWwu IFRoZXJlIGFyZSBwbGVudHkgcm9vbSBmb3IgSUVURiB0byBkbyBmb3IgdGhpcy4NCg0KW01XXSBT b3JyeSwgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhlICJwdXNoIiBtb2RlbCBoYXMgdG8gZG8g d2l0aCBIVFRQIFN0cmVhbWluZy4gQXJlIHlvdSB0YWxraW5nIGFib3V0IHNlcnZlcnMgd2hpY2gg YXJlIG5vdCByZWd1bGFyIEhUVFAgc2VydmVycyA/IEkgdGhpbmsgdGhpcyBpcyBub3Qgd2hhdCBw ZW9wbGUgdXN1YWxseSBtZWFuIHdoZW4gdGhleSBzYXkgIkhUVFAgc3RyZWFtaW5nIiAtIHlvdSBz aG91bGQgcmVuYW1lIHRoZSB3b3JrIGlmIHRoYXQgaXMgdGhlIGNhc2UuDQoNCiAgIC0gSW1wb3Nz aWJsZSB0byBmYXN0LWZvcndhcmQgdGhyb3VnaCBhbnkgcGFydCBvZiBhIHN0cmVhbWluZw0KICAg Y29udGVudHMgdW50aWwgaXQgaXMgc3RvcmVkIG9uIHRoZSB1c2VyJ3MgZGV2aWNlDQoNCk1XOiBU aGlzIGlzIHNpbXBseSBub3QgY29ycmVjdCwgc2luY2UgdGhlcmUgYXJlIGh1bmRyZWRzIG9mIGV4 YW1wbGVzIG9mIGRldmljZXMgd2hpY2ggc3VwcG9ydCB0cmljay1wbGF5IHVzaW5nIEhUVFAgc3Ry ZWFtaW5nIHRlY2huaXF1ZXMgd2l0aG91dCBzdG9yaW5nIHRoZSB3aG9sZSBjb250ZW50IG9uIHRo ZSB1c2VycyBkZXZpY2UuDQoNCltRaW5dOiBGYXN0IGZvcndhcmQgY2FwYWJpbHR5IGlzIG5vdCB0 aGUgbW9zdCBpbXBvcnRhbnQgZmVhdHVyZSB3ZSBhcmUgbG9va2luZyBmb3IuIEhvd2V2ZXIgSSBh bSBoYXJkIHRvIGJlbGlldmUgZXhpc3RpbmcgSFRUUCBzdHJlYW1pbmcgdGVjaG5pcXVlcyBjYW4g cHJvdmlkZSB0aGUgc2FtZSBkZWdyZWUgb2YgcGxheWJhY2tjb250cm9sIHRoYXQgRFZEIHBsYXll ciBjYW4gcHJvdmlkZXMgb3IgUlRTUCBwcm90b2NvbCBwcm92aWRlcy4gRS5nLiwgSW4gdGhlIGFk YXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFsZ29yaXRobXMsIHRoZSB0cmljayBwbGF5IGlzIGxpbWl0 ZWQgdG8gcGF1c2UvcmVzdW1lL3N0b3AgYnkgZHJpdmluZyB0aGUgSFRUUCByZXF1ZXN0LiBJZiB0 aGUgY29udGVudHMgaGFzbid0IGJlZW4gZG93bG9hZGVkIGFuZCB0aGUgY29uc3VtZSB3YW50IGZh c3QgZm9yd2FyZCwgdGhlIEhUVFAgY2xpZW50IG5lZWRzIHRvIGlzc3VlIGFub3RoZXIgbmV3IEhU VFAgcmVxdWVzdCB0byBmZXRjaCB0aGUgY29udGVudHMgd2hpY2ggd2lsbGNhdXNlIHVuYWNjZXB0 YWJsZSBsYXRlbmN5IHRvIHRoZSBjb25zdW1lci4NCg0KW01XXSBBZ2FpbiwgdGhlIGV4cGVyaWVu Y2Ugb2YgbWlsbGlvbnMgb2YgZXhpc3RpbmcgY3VzdG9tZXJzIHJlZnV0ZXMgd2hhdCB5b3UgY2xh aW0uIFdoeSBkbyB5b3UgdGhpbmsgaXQgaXMgbmVjZXNzYXJpbHkgc28gc2xvdyB0byBpc3N1ZSBh IG5ldyBIVFRQIHJlcXVlc3QgZm9yIGEgZGlmZmVyZW50IHBhcnQgb2YgdGhlIGNvbnRlbnQ/DQoN CltRaW5dOiBZb3UgZGlkbid0IHNlZSB0aGUgcmVhb24gYmVoaW5kIHRoaXMsIGJlY29zIHRoZSBl eGlzdGluZyBjdXN0b21lcnMgaGFzIG5vIGNob2ljZSB3aGVuIHRoZXkgdmlldyBsaXZlIHN0cmVh bWluZywgd2hhdCB0aGV5IGNhbiBnZXQgaXMgY2xvc2UgdG8gbGl2ZSBleHBlcmllbmNlIHJhdGhl ciB0aGFuIHJlYWwgdGltZSB1c2VyIGV4cGVyaWVuY2UuIE9wZXJhdG9lciBkbyBub3RoaW5nIGZv ciB0aGVpciBuZXR3b3JrIHRvIG1ha2UgaHR0cCBzdHJlYW1pbmcgbW9yZSBjb250cm9sbGFibGUg YW5kIG1hbmFnYWJsZS4gVGhlcmVmb3JlIG1vcmUgYW5kIG1vcmUgY29uc3VtZXIgdGVuZCB0byBj aG9vc2Ugbm9uLWxpdmUgY29udGVudC4gdGhhdCdzIHdoeSB3ZSBzZWUgbW9yZSBhbmQgbW9yZSBu b24tbGl2ZSBjb250ZW50IGNvbnN1bWVycyByYXRoZXIgdGhhbiBsaXZlIGNvbnRlbnRzIGNvbnN1 bWVycy4NCg0KDQpbTVddIFdlbGwsIEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIHBvaW50 LiBCdXQgc3RpbGwgdGhlIHN0YXRlbWVudCBpbiB0aGUgZHJhZnQgaXMgbm90IHRydWUuDQoNCi4u Lk1hcmsNCg0KDQpBIGZpcnN0IHN0ZXAgaW4gY29uc2lkZXJpbmcgd2hhdCwgaWYgYW55LCB3b3Jr IHNob3VsZCBiZSBkb25lIGhlcmUgbWlnaHQgYmUgdG8gY29udGFjdCB0aG9zZSBvcmdhbml6YXRp b25zIHdoaWNoIGFyZSBzdGFuZGFyZGl6aW5nIHRoZSBoaWdoZXIgbGF5ZXJzIG9mIEhUVFAgc3Ry ZWFtaW5nIHN5c3RlbXMgKGUuZy4gbWFuaWZlc3QgYW5kIGZpbGUgZm9ybWF0cykgYW5kIGFzayB3 aGV0aGVyIHRoZXJlIGFyZSBkZWZpY2llbmNpZXMgdGhleSBzZWUgaW4gSUVURiBwcm90b2NvbHMg dGhhdCBjb3VsZCBiZSB1c2VmdWxseSBhZGRyZXNzZWQgYnkgdGhlIElFVEYuIFdoYXQgSSB0aGlu ayB3ZSBzaG91bGQgYXZvaWQgaW4gdGhlIElFVEYgaXMgZHVwbGljYXRpbmcgdGhlIHdvcmsgb2Yg dGhlc2Ugb3RoZXIgYm9kaWVzLg0KDQpCZXN0LA0KDQoNCk1hcmsgV2F0c29uDQoNCk5ldGZsaXgg SW5jLg0KDQoNCg0KDQpPbiBPY3QgMTAsIDIwMTAsIGF0IDEyOjQzIEFNLCBBbGkgQy4gQmVnZW4g KGFiZWdlbikgd3JvdGU6DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog PG1haWx0bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IGh0dHBzdHJlYW1pbmctYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86aHR0cHN0cmVhbWluZy1ib3VuY2VzQGlldGYub3JnPiBbbWFp bHRvOmh0dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhcnMgRWdn ZXJ0DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMDgsIDIwMTAgNDoxNyBQTQ0KVG86IENvbGluIFBl cmtpbnMNCkNjOiA8bWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+IGh0dHBzdHJlYW1pbmdA aWV0Zi5vcmc8bWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2h0 dHBzdHJlYW1pbmddIEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KDQpPbiAyMDEwLTEwLTcs IGF0IDE0OjE2LCBDb2xpbiBQZXJraW5zIHdyb3RlOg0KVGhlcmUgYXJlIGNsZWFybHkgc29tZSBp c3N1ZXMgdG8gY29uc2lkZXIgaGVyZS4gV2hhdCBzZWVtcyB0byBiZQ0KbWlzc2luZyBmcm9tIHRo ZSBkaXNjdXNzaW9uIHRvIG1lIHRob3VnaCwgaXMgc29tZSBpZGVudGlmaWNhdGlvbiBvZg0KdGhl IGNvbmNyZXRlIHByb2JsZW1zLiBXaGF0IHByb3RvY29sIHBpZWNlcyBkbyB3ZSBuZWVkLCBidXQg bm90IGhhdmU/DQpXaGF0IHByb3RvY29scyBhcmUgcHJvYmxlbWF0aWMsIGFuZCBuZWVkIGVuaGFu Y2VtZW50PyBJcyB0aGVyZQ0KcHJvdG9jb2wgd29yayB0byBkbyBpbiBJRVRGLCBvciBzaG91bGQg d2UgYmUgZG9jdW1lbnRpbmcgYmVzdCBjdXJyZW50DQpwcmFjdGljZXMgZm9yIHVzaW5nIHRoZSBl eGlzdGluZyBwcm90b2NvbHMgYW5kL29yIHJlbHlpbmcgb24gb3RoZXINCmJvZGllcyB0byBmaWxs IHRoZSBnYXBzPw0KDQpUaGUgZHJhZnQtd3UtaHR0cC1zdHJlYW1pbmctb3B0aW1pemF0aW9uLXBz IGlzIGEgZ29vZCBzdGFydCBhdCBzdWNoIGFuDQphbmFseXNpcywgYnV0IGRvZXNuJ3QgZ28gZGVl cCBlbm91Z2ggdG8gbGV0IHVzIGRlY2lkZSB3aGF0IHdvcmsgSUVURg0Kc2hvdWxkIGRvLg0KDQor MQ0KDQpUaGUga2V5IHF1ZXN0aW9uIHJlYWxseSBpcyAid2hhdCBkbyB5b3UgdGhpbmsgdGhlIElF VEYgbmVlZHMgdG8gZG8/Ig0KDQpJIGltYWdpbmUgdGhlIG9ubHkgd29yayB0aGUgSUVURiBzaG91 bGQgZG8gKGlmIHdlIGRlY2lkZSB0bykgaXMgdGhlIHRyYW5zcG9ydCBhbmQgSFRUUC1sYXllciBv cHRpbWl6YXRpb24gZm9yIGJldHRlciBzdHJlYW1pbmcgcGVyZm9ybWFuY2UuDQoNCi1hY2JlZ2Vu DQoNCkxhcnMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpodHRwc3RyZWFtaW5nIG1haWxpbmcgbGlzdA0KPG1haWx0bzpodHRwc3RyZWFtaW5nQGlldGYu b3JnPmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8bWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmcNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpodHRwc3RyZWFtaW5nIG1haWxpbmcgbGlz dA0KaHR0cHN0cmVhbWluZ0BpZXRmLm9yZzxtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cHN0cmVhbWluZw0KDQo= --_000_B9E38A0683924CCF9160D55F43BD75D8netflixcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PGJhc2UgaHJlZj0ieC1tc2c6Ly81LyI+PC9oZWFkPjxib2R5IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj48YnI+PGRpdj48ZGl2Pk9uIE9jdCAxNCwg MjAxMCwgYXQgMjo0MSBQTSwgUWluIFd1IHdyb3RlOjwvZGl2PjxiciBjbGFzcz0iQXBwbGUtaW50 ZXJjaGFuZ2UtbmV3bGluZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4gY2xhc3M9IkFw cGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdo dDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZl cnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDog bm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPjxkaXYgYmdjb2xvcj0iI2ZmZmZmZiI+ PGRpdj5IaSw8L2Rpdj48YmxvY2txdW90ZSBkaXI9Imx0ciIgc3R5bGU9ImJvcmRlci1sZWZ0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAycHg7IGJvcmRlci1sZWZ0LXN0 eWxlOiBzb2xpZDsgcGFkZGluZy1sZWZ0OiA1cHg7IHBhZGRpbmctcmlnaHQ6IDBweDsgbWFyZ2lu LWxlZnQ6IDVweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IHBvc2l0aW9uOiBzdGF0aWM7IHotaW5kZXg6 IGF1dG87ICI+PGRpdiBzdHlsZT0iZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgOXB0L25vcm1h bCDlrovkvZM7ICI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQ6IG5vcm1hbCBub3JtYWwgbm9ybWFsIDlwdC9ub3JtYWwg5a6L5L2TOyBiYWNrZ3JvdW5k LWltYWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91 bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQt Y29sb3I6IHJnYigyMjgsIDIyOCwgMjI4KTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBp bml0aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyAiPjxiPkZyb206PC9i PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSB0aXRs ZT0id2F0c29ubUBuZXRmbGl4LmNvbSIgaHJlZj0ibWFpbHRvOndhdHNvbm1AbmV0ZmxpeC5jb20i Pk1hcmsgV2F0c29uPC9hPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQ6IG5vcm1hbCBub3JtYWwgbm9y bWFsIDlwdC9ub3JtYWwg5a6L5L2TOyAiPjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgdGl0bGU9InN1bnNlYXdxQGh1YXdlaS5jb20i IGhyZWY9Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8L2E+PC9kaXY+PGRpdiBz dHlsZT0iZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgOXB0L25vcm1hbCDlrovkvZM7ICI+PGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSB0aXRsZT0iYWJlZ2VuQGNpc2NvLmNvbSIgaHJlZj0ibWFpbHRvOmFiZWdlbkBjaXNjby5jb20i PkFsaSBDLiBCZWdlbiAoYWJlZ2VuKTwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSB0aXRsZT0iaHR0cHN0cmVhbWluZ0BpZXRmLm9yZyIgaHJlZj0ibWFpbHRv Omh0dHBzdHJlYW1pbmdAaWV0Zi5vcmciPmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc8L2E+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjs8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgdGl0bGU9ImNzcEBjc3Blcmtp bnMub3JnIiBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmciPkNvbGluIFBlcmtpbnM8L2E+ PC9kaXY+PGRpdiBzdHlsZT0iZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgOXB0L25vcm1hbCDl rovkvZM7ICI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIE9jdG9iZXIgMTIsIDIwMTAgMTI6NTAgQU08L2Rpdj48ZGl2 IHN0eWxlPSJmb250OiBub3JtYWwgbm9ybWFsIG5vcm1hbCA5cHQvbm9ybWFsIOWui+S9kzsgIj48 Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+UmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWw8L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNvbWUgY29tbWVudHMgb25saW5lIC4uLjxicj48YnI+U2Vu dCBmcm9tIG15IGlQaG9uZTwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i5a6L5L2TIj48 L2ZvbnQ+PGJyPk9uIE9jdCAxMSwgMjAxMCwgYXQgNzo1MCBQTSwgIlFpbiBXdSIgJmx0OzxhIGhy ZWY9Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5zdW5zZWF3cUBodWF3ZWkuY29tPC9hPiZn dDsgd3JvdGU6PGJyPjxicj48L2Rpdj48ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxkaXY+PGRpdj5IaSw8L2Rpdj48ZGl2PlRoaXMgaXMgd2hhdCB3ZSBoYWQgZGlzY3Vzc2VkJm5i c3A7IGluIHRoZSBESVNQQVRDSCBtYWlsaW5nIGxpc3QgYmVmb3JlIHdlIG1vdmUgdG8gdGhpcyBk aXNjdXNzIGxpc3QuPC9kaXY+PGRpdj5JZiB5b3UgbG9vayBhdCB0aGUgZGVzY3JpcHRpb24gb2Yg ZGlzY3VzcyBsaXN0LCAiPC9kaXY+PGRpdj5vZmZlcnMgbW9yZSBlZmZpY2llbnQgdHJhbnNwb3J0 PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj5hbmQg YmV0dGVyIG5ldHdvcmsgY2FwYWJpbGl0eSBmb3IgcmVhbCB0aW1lIHN0cmVhbWluZyBtZWRpYTxi cj5hbmQgYWxsb3dzIGludGVyb3BlcmFiaWxpdHkgd2l0aCBvdGhlciBzdHJlYW1pbmcgdGVjaG5p cXVlcyBhbmQgZXhpc3RpbmcgUHJvZ3Jlc3NpdmUgZG93bG9hZGVkIGJhc2VkPGJyPkhUVFAgc3Ry ZWFtaW5nIGltcGxlbWVudGF0aW9uLjwvZGl2PjxkaXY+IjwvZGl2PjxkaXY+eW91IHdpbGwmbmJz cDtzZWUgd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UuPC9kaXY+PGRpdj5UaGVyZWZvcmUgb25lJm5i c3A7aW1wb3J0YW50IGdvYWwgZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCZuYnNwO2FpbXMgYXQmbmJz cDtkZXZlbG9waW5nIGludGVyb3BlcmFibGUgc29sdXRpb24gdG88L2Rpdj48ZGl2PnByb3ZpZGUg YmV0dGVyIHRyYW5zcG9ydCB0byBzYXRpc2Z5IHRoZSByZWFsIHRpbWUgc3RyZWFtaW5nIFFPRSBy ZXF1aXJlbWVudC4gRXNwZWNpYWxseSZuYnNwO3NlcnZlcmFsPC9kaXY+PGRpdj5jaGFubGxlbmdl cy9wcm9ibGVtcyZuYnNwO3dlIGV4cGxvcmVkIGluIHRoZSBkcmFmdCBsaXN0ZWQgYmVsb3cuPC9k aXY+PGRpdj4mbmJzcDs8L2Rpdj48ZGl2PlJlZ2FyZHMhPC9kaXY+PGRpdj4tUWluPC9kaXY+PGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGJvcmRlci1s ZWZ0LXdpZHRoOiAycHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZy1sZWZ0OiA1 cHg7IHBhZGRpbmctcmlnaHQ6IDBweDsgbWFyZ2luLWxlZnQ6IDVweDsgbWFyZ2luLXJpZ2h0OiAw cHg7ICI+PGRpdiBzdHlsZT0iZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgOXB0L25vcm1hbCDl rovkvZM7ICI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTwvZGl2PjxkaXYgc3R5bGU9ImZv bnQ6IG5vcm1hbCBub3JtYWwgbm9ybWFsIDlwdC9ub3JtYWwg5a6L5L2TOyBiYWNrZ3JvdW5kLWlt YWdlOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6IGluaXRpYWw7IGJhY2tncm91bmQt b3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7IGJhY2tncm91bmQtY29s b3I6IHJnYigyMjgsIDIyOCwgMjI4KTsgYmFja2dyb3VuZC1wb3NpdGlvbjogaW5pdGlhbCBpbml0 aWFsOyBiYWNrZ3JvdW5kLXJlcGVhdDogaW5pdGlhbCBpbml0aWFsOyAiPjxiPkZyb206PC9iPjxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSB0aXRsZT0i d2F0c29ubUBuZXRmbGl4LmNvbSIgaHJlZj0ibWFpbHRvOndhdHNvbm1AbmV0ZmxpeC5jb20iPk1h cmsgV2F0c29uPC9hPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQ6IG5vcm1hbCBub3JtYWwgbm9ybWFs IDlwdC9ub3JtYWwg5a6L5L2TOyAiPjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgdGl0bGU9ImFiZWdlbkBjaXNjby5jb20iIGhyZWY9 Im1haWx0bzphYmVnZW5AY2lzY28uY29tIj5BbGkgQy4gQmVnZW4gKGFiZWdlbik8L2E+PC9kaXY+ PGRpdiBzdHlsZT0iZm9udDogbm9ybWFsIG5vcm1hbCBub3JtYWwgOXB0L25vcm1hbCDlrovkvZM7 ICI+PGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSB0aXRsZT0iaHR0cHN0cmVhbWluZ0BpZXRmLm9yZyIgaHJlZj0ibWFpbHRvOmh0dHBz dHJlYW1pbmdAaWV0Zi5vcmciPjwvYT48YSBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRm Lm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSB0aXRsZT0iY3NwQGNzcGVya2lucy5vcmciIGhyZWY9Im1haWx0 bzpjc3BAY3NwZXJraW5zLm9yZyI+Q29saW4gUGVya2luczwvYT48L2Rpdj48ZGl2IHN0eWxlPSJm b250OiBub3JtYWwgbm9ybWFsIG5vcm1hbCA5cHQvbm9ybWFsIOWui+S9kzsgIj48Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U3VuZGF5 LCBPY3RvYmVyIDEwLCAyMDEwIDc6MTMgQU08L2Rpdj48ZGl2IHN0eWxlPSJmb250OiBub3JtYWwg bm9ybWFsIG5vcm1hbCA5cHQvbm9ybWFsIOWui+S9kzsgIj48Yj5TdWJqZWN0OjwvYj48c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtodHRwc3RyZWFt aW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWw8L2Rpdj48ZGl2Pjxicj48L2Rpdj5BbGws PGRpdj48YnI+PC9kaXY+PGRpdj5JIHdvdWxkIGxpa2UgdG8gYWRkIG15IHN1cHBvcnQgdG8gdGhl IGNvbW1lbnRzIGJlbG93LiBTcGVjaWZpY2FsbHksIEkgdGhpbmsgaWYgdGhlIElFVEYgY29uc2lk ZXJzIHdvcmsgaW4gdGhpcyBhcmVhIGl0IHNob3VsZCBmb2N1cyBvbiB0aGUgSFRUUCBhbmQgVENQ IHByb3RvY29scy4gQW55IHN1Y2ggd29yayBtYXkgbm90IGJlIHNwZWNpZmljIHRvIEhUVFAtc3Ry ZWFtaW5nIChpLmUuIGVuaGFuY2VtZW50cyB0aGF0IGFyZSBhdCBmaXJzdCBtb3RpdmF0ZWQgYnkg SFRUUCBTdHJlYW1pbmcgbWF5IGhhdmUgYnJvYWRlciBhcHBsaWNhYmlsaXR5LCBhbmQgdGhpcyBz aG91bGQgYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQpLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ SW4gdGhlIGRyYWZ0IEkgZG8gbm90IHNlZSBhIGNsZWFyIG9yIGNvcnJlY3QgaWRlbnRpZmljYXRp b24gb2YgdGhlIHByb2JsZW1zLiBGb3IgZXhhbXBsZSBpbiB0aGUgaW50cm9kdWN0aW9uIHRoZSBm b2xsb3dpbmcgYXJlIHN0YXRlZCBhcyBpc3N1ZXM6PC9kaXY+PGRpdj48cHJlIGNsYXNzPSJuZXdw YWdlIj4gICAtIENsaWVudCBwb2xsaW5nIGZvciBlYWNoIG5ldyBkYXRhIGluIGNodW5rcyB1c2lu ZyBIVFRQIHJlcXVlc3RzIGlzDQogICBub3QgZWZmaWNpZW50IHRvIGRlbGl2ZXIgaGlnaC1xdWFs aXR5IHZpZGVvIGNvbnRlbnQgYWNyb3NzIHRoZQ0KICAgSW50ZXJuZXQ8YnI+PC9wcmU+PHByZSBj bGFzcz0ibmV3cGFnZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkhlbHZl dGljYSI+TVc6IFNldmVyYWwgY29tcGFuaWVzLCBpbmNsdWRpbmcgbXkgZW1wbG95ZXIsIGFyZSBz dWNjZXNzZnVsbHkgb3BlcmF0aW5nIGxhcmdlIHNjYWxlIEhUVFAgc3RyZWFtaW5nIHN5c3RlbXMg dGhhdCBkbyBlZmZpY2llbnRseSBkZWxpdmVyIGhpZ2gtcXVhbGl0eSB2aWRlbyBjb250ZW50IGFj cm9zcyB0aGUgSW50ZXJuZXQsIHNvIHJlYWxpdHkgc2VlbXMgdG8gcmVmdXRlIHRoaXMgc3RhdGVt ZW50LjwvZm9udD48L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj48Zm9udCBzaXplPSI0Ij48Zm9u dCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBOb3Qgc3VyZSB0aGV5IGNhbiBwcm92aWRl IHRoZSBUViBleHBlcmllbmNlIGZvciBhbGwgdGhlIGNvbm5lY3RlZCBkZXZpY2VzIGxpa2Ugc21h cnRwaG9uZXMsIFBDcyBhbmQgdGFibGV0cy4gQWxzbyBub3Qgc3VyZSB0aGV5IGNhbiBwcm92aWRl IHRoZSBzYW1lIHF1YWxpdHkgb2YgZXhwZXJlbmNlIGZvciBhbGwgdGhlIGFsbCB0aGUgY29ubmVj dGVkIGRldmljZXMuIEFzIHdlIGRpc2N1c3NlZCBpbiB0aGlzIHRocmVhZCwgYSBtaW5pbXVtIG9m IDIwIHNlY29uZHMgdG8gc3RhcnQgeW91ciB2aWRlbyBvZnRlbiBmcnVzdHJhdGVkIHVzZXJzIHRv IGtlZXAgb24gd2F0Y2hpbmcgYW5kIHByb3ZpZGUgdmVyeSBsaW1pdGVkIHVzZXIgZXhwZXJpZW5j ZS48L2ZvbnQ+PC9mb250PjwvcHJlPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2Jsb2NrcXVv dGU+PGRpdj5DYW4geW91IGJlIG1vcmUgZXhwbGljaXQgYWJvdXQgdGhlIHByb2JsZW1zIHRoYXQg eW91IHNlZT8gSSdtJm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iPm5vdCBzdXJl IHdoZXJlIHRoZSAyMHMgZmlndXJlIGNvbWVzIGZyb20uIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxl bSBpbiBzdXBwb3J0aW5nIHN0YXJ0dXAgdGltZXMgY29tcGFyYWJsZSB0byBUViBjaGFubmVsIGNo YW5nZSB3aXRoIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nLjwvc3Bhbj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PkkgYW0gbm90IHNheWluZyB0aGVyZSBpcyBubyByb29tIGZvciBpbXByb3ZlbWVu dCBpbiB0aGUgdmFyaW91cyBkZXBsb3llZCBzeXN0ZW1zLCBidXQgSSBkbyBub3Qgc2VlIG1ham9y IHRlY2huaWNhbCBpbXBlZGltZW50cyB0byBlZmZpY2llbnQgZGVsaXZlcnkgb2YgaGlnaCBxdWFs aXR5IHZpZGVvIHVzaW5nIEhUVFAgU3RyZWFtaW5nLjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGRp dj5bUWluXTpOb3Qgb25seSBzdGFydXAgbGF0ZW5jeSBidXQgYWxzbyBkZWxheSB3LnIudC4gcmVh bCB0aW1lIHN0cmVhbWluZy4gSSB0aGluayB5b3UgbmVnZWN0IGl0IGJlY29zIFlvdSBkaWRuJ3Qg Z2V0IGludG8gdGhlIGRpc2N1c3Npb24gbGlzdC48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXY+PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGJv cmRlci1sZWZ0LXdpZHRoOiAycHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZy1s ZWZ0OiA1cHg7IHBhZGRpbmctcmlnaHQ6IDBweDsgbWFyZ2luLWxlZnQ6IDVweDsgbWFyZ2luLXJp Z2h0OiAwcHg7ICI+PGRpdj48cHJlIGNsYXNzPSJuZXdwYWdlIj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxmb250IHNpemU9IjQiPk9uIHRoZSBvdGhlciBoYW5kLCBJIHRoaW5rIHdlIHNo b3VsZCBiZWFyIGluIG1pbmQgSFRUUCBpcyBmb3JtZXJseSBkZXNpZ25lZCBmb3IgYnJvd3Npbmcg d2VicGFnZSwgdHJhbnNwb3J0IHN0YXRpYyBjb250ZW50cyBsaWtlIEhUTUwgcGFnZSwgcGx1Z2lu LCBwaWN0dXJlLCB3aGVuIHdlIGFyZSBnb2luZyB0byB1c2UgPC9mb250Pjxmb250IHNpemU9IjQi PkhUVFAgdG8gZGVsaXZlciByZWFsIHRpbWUgc3RyZWFtaW5nIGNvbnRlbnRzLCB3ZSBjYW4gbm90 IGV4cGVjdCB0byBnZXQgaGlnaGVyIHVzZXIgZXhwZXJpZW5jZS4gPC9mb250Pjxmb250IHNpemU9 IjMiPjxzdHJvbmc+VGhlcmVmb3JlIHRoZSBjdXJyZW50PC9zdHJvbmc+IDxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGZvbnQtc2l6ZTogMTJwdDsg Ij48c3Ryb25nPnN0cmVhbWluZyBzY2hlbWVzIGNhbiBvbmx5IG9mZmVyIGEgYmV0dGVyIGV4cGVy aWVuY2Ugb3ZlciBzbG93ZXIgY29ubmVjdGlvbnMuPC9zdHJvbmc+PC9zcGFuPjwvZm9udD48L2Zv bnQ+PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+ICAgLSBTZWdtZW50YXRpb24gY2FwYWJpbGl0 eSByZXF1aXJlcyBvdmVyLXV0aWxpemluZyBDUFUgYW5kIGJhbmR3aWR0aA0KICAgcmVzb3VyY2Vz LCB3aGljaCBtYXkgbm90IGJlIGEgZGVzaXJhYmxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIGltcHJv dmUNCiAgIHRoZSBxdWFsaXR5IG9mIHN0cmVhbWluZyBtZWRpYSBkZWxpdmVyeTwvcHJlPjxwcmUg Y2xhc3M9Im5ld3BhZ2UiPjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBmYWNlPSJIZWx2 ZXRpY2EiPk1XOiBJdCBpcyBub3QgY2xlYXIgdGhhdCBzZWdtZW50YXRpb24gcGVyIHNlIGlzIENQ VS1pbnRlbnNpdmUgb3IgaGFzIGFueSBub24tbmVnbGlnYWJsZSBlZmZlY3Qgb24gYmFuZHdpZHRo IHVzYWdlLjwvZm9udD48L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj48Zm9udCBzaXplPSI0IiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBTaW5jZSBIVFRQIHN0cmVhbWluZyBzZXJ2ZXIg aXMgdGhlIGNvbWJpbmF0aW9uIG9mIHN0cmVhbWluZyBzZXJ2ZXIgYW5kIHJlZ3VsYXIgd2ViIHNl cnZlciwgSSB0aGluayB0aGUgYW5zd2VyIGlzIGJvdGguPC9mb250PjwvcHJlPjwvZGl2PjwvYmxv Y2txdW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48Zm9udCBzaXplPSIyIiBmYWNlPSLlrovk vZMiPjwvZm9udD48YnI+PC9kaXY+PGRpdj5bTVddIHdoYXQgZG8geW91IG1lYW4gYnknIGh0dHAg c3RyZWFtaW5nIHNlcnZlcicgPzwvZGl2PjxkaXY+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i5a6L5L2T Ij48L2ZvbnQ+Jm5ic3A7PC9kaXY+PGRpdj5bUWluXTogV2l0aCBzdHJlYW1pbmcgY2FwYWJpbGl0 eSBhbmQgZnVuY3Rpb25hbGl0eSB0byByZXNwb25kIHRvIEhUVFAgY29ubmVjdGlvbi48YnI+PC9k aXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+ PGRpdj5bTVddIEknbSBub3Qgc3VyZSB3aGF0IG9uZSBvZiB0aG9zZSBpcy4gSXQgc291bmRzIGxp a2UgaXQgaXMgbm90IGEgcmVndWxhciB3ZWIgc2VydmVyLiBJIHRoaW5rIGl0J3MgYW4gZXNzZW50 aWFsIGZlYXR1cmUgb2YgbW9kZXJuIEhUVFAgc3RyZWFtaW5nIHRoYXQgaXQgd29ya3Mgd2l0aCBy ZWd1bGFyIHdlYiBpbmZyYXN0cnVjdHVyZS48L2Rpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJib3JkZXItY29sbGFwc2U6 IHNlcGFyYXRlOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29y YXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPjxkaXYg Ymdjb2xvcj0iI2ZmZmZmZiI+PGJsb2NrcXVvdGUgZGlyPSJsdHIiIHN0eWxlPSJib3JkZXItbGVm dC1jb2xvcjogcmdiKDAsIDAsIDApOyBib3JkZXItbGVmdC13aWR0aDogMnB4OyBib3JkZXItbGVm dC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogNXB4OyBwYWRkaW5nLXJpZ2h0OiAwcHg7IG1h cmdpbi1sZWZ0OiA1cHg7IG1hcmdpbi1yaWdodDogMHB4OyBwb3NpdGlvbjogc3RhdGljOyB6LWlu ZGV4OiBhdXRvOyAiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAy cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgcGFkZGluZy1sZWZ0OiA1cHg7IHBhZGRpbmct cmlnaHQ6IDBweDsgbWFyZ2luLWxlZnQ6IDVweDsgbWFyZ2luLXJpZ2h0OiAwcHg7ICI+PGRpdj48 cHJlIGNsYXNzPSJuZXdwYWdlIj4gICAtIExhY2sgb2YgUW9TIGd1YXJhbnRlZSBvbiB0aGUgcGFj a2V0IHN3aXRjaGluZyBiYXNlZCBJbnRlcm5ldCAsIHRoZQ0KICAgcXVhbGl0eSBvZiBJbnRlcm5l dCBtZWRpYSBzdHJlYW1pbmcgbWF5IHNpZ25pZmljYW50IGRlZ3JhZGUgZHVlIHRvDQogICByaXNp bmcgdXNhZ2U8L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj48Zm9udCBjbGFzcz0iQXBwbGUtc3R5 bGUtc3BhbiIgZmFjZT0iSGVsdmV0aWNhIj5NVzogQW4gYWx0ZXJuYXRpdmUgdmlldyBpcyB0aGF0 IHdoZXJlIHF1YWxpdHkgaXMgZGVncmFkZWQgZHVlIHRvIGNvbmdlc3Rpb24gdGhpcyBpcyBkdWUg dG8gbGFjayBvZiBiYW5kd2lkdGgsIHJhdGhlciB0aGFuIGEgbGFjayBvZiBRb1MgZ3VhcmFudGVl cy4gQWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyBhZGp1c3QgdGhlIHZpZGVvIHF1YWxp dHkgdG8gdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggaW4gb3JkZXIgdG8gYXZvaWQgcmVidWZmZXJp bmcgZXZlbnRzLiBJdCBpcyB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCB0aGF0IG5lZWRzIHRvIGJl IGltcHJvdmVkIHRvIGltcHJvdmUgcXVhbGl0eS48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0ibmV3 cGFnZSI+PGZvbnQgZmFjZT0iSGVsdmV0aWNhIj48Zm9udCBzaXplPSI0IiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPltRaW5dOiBXaGF0IEkgZW1waGFzaXplIGhlcmUgaXMgd2l0aCBncm93aW5nIHBv cHVsYXJpdHkgb2YgSFRUUCBzdHJlYW1pbmcgdHJhZmZpYywgd2hlbiB0aG91c2FuZHMgb3IgbWls bGlvbnMgb2YgcGVvcGxlIGFyZSBhY2Nlc3NpbmcgdGhlIHNhbWUgbWVkaWEgY29udGVudHMsIHRo ZSBiaWcgcHJvYmxlbSB3ZSBhcmUgZmFjaW5nIGlzIHNlcmlvdXMgaGlnaCBjb25jdXJyZW5jZSBh Y2Nlc3MgaXNzdWUuIFRoZSB1c2VyIGV4cGVyaWVuY2Ugd2lsbCBiZSBncmVhdGx5IGFmZmVjdGVk IGV2ZW4geW91IGhhdmUgZW5vdWdoIGF2YWlsYWJsZSBiYW5kd2lkdGguIFNvIHRoaXMgaXMgbm90 IHB1cmUgYmFuZHdpZHRoIGlzc3VlLjwvZm9udD48L2ZvbnQ+PC9wcmU+PC9kaXY+PC9ibG9ja3F1 b3RlPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxmb250IHNpemU9IjIiIGZhY2U9IuWui+S9kyI+ PC9mb250Pjxicj48L2Rpdj48ZGl2PltNV10gbWF5YmUgd2UgbWVhbiBkaWZmZXJlbnQgdGhpbmdz IGJ5ICdhdmFpbGFibGUgYmFuZHdpZHRoJy4gRG8geW91IHRoaW5rIGl0IGlzIGEgc2VydmVyIHNj YWxhYmlsaXR5IHByb2JsZW0sIG9yIGEgbmV0d29yayBwcm9ibGVtID88L2Rpdj48ZGl2PiZuYnNw OzwvZGl2PjxkaXY+W1Fpbl06IHBsZWFzZSByZWFkPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9odHRwc3RyZWFtaW5nL2N1cnJlbnQvbXNnMDAwMTEuaHRtbCI+aHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2h0dHBzdHJlYW1pbmcvY3VycmVudC9tc2cwMDAx MS5odG1sPC9hPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9zcGFuPjwvYmxvY2txdW90 ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PltNV10gU3RpbGwgbm90IHN1cmUgd2hhdCB5b3UncmUgcmVm ZXJyaW5nIHRvIG90aGVyIHRoYW4gYXZhaWxhYmxlIGJhbmR3aWR0aC4gVGhlIHRocmVhZCBtZW50 aW9ucyBtdWx0aWNhc3QgLSBkbyB5b3UgdGhpbmsgdGhlcmUgcmVtYWlucyB3b3JrIHRvIGRlbGl2 ZXIgSFRUUCBvYmplY3RzIG92ZXIgbXVsdGljYXN0IGdpdmVuIHRoZSB3b3JrIGluIFJNVCBvdmVy IHRoZSB5ZWFycyA/PC9kaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNz PSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRl ci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZl Y3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmb250LXNpemU6IG1lZGl1bTsgIj48ZGl2IGJnY29sb3I9IiNmZmZm ZmYiPjxibG9ja3F1b3RlIGRpcj0ibHRyIiBzdHlsZT0iYm9yZGVyLWxlZnQtY29sb3I6IHJnYigw LCAwLCAwKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDJweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlk OyBwYWRkaW5nLWxlZnQ6IDVweDsgcGFkZGluZy1yaWdodDogMHB4OyBtYXJnaW4tbGVmdDogNXB4 OyBtYXJnaW4tcmlnaHQ6IDBweDsgcG9zaXRpb246IHN0YXRpYzsgei1pbmRleDogYXV0bzsgIj48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVm dC1jb2xvcjogcmdiKDAsIDAsIDApOyBib3JkZXItbGVmdC13aWR0aDogMnB4OyBib3JkZXItbGVm dC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogNXB4OyBwYWRkaW5nLXJpZ2h0OiAwcHg7IG1h cmdpbi1sZWZ0OiA1cHg7IG1hcmdpbi1yaWdodDogMHB4OyAiPjxkaXY+PHByZSBjbGFzcz0ibmV3 cGFnZSI+ICAgLSBFeHBlcmllbmNlIGJ1cnN0aW5lc3Mgb3Igb3RoZXIgZHluYW1pY3MgY2hhbmdl cyBkdWUgdG8gYmFuZHdpZHRoDQogICBmbHVjdHVhdGlvbnMgYW5kIGhldGVyb2dlbmVvdXMgaGFu ZG92ZXIuPC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxl LXNwYW4iIGZhY2U9IkhlbHZldGljYSI+TVc6IFdlIGhhdmUgZm91bmQgdGhhdCBhZGFwdGl2ZSBI VFRQIHN0cmVhbWluZyBhbGdvcml0aG1zIGFyZSB3ZWxsIGFibGUgdG8gY29wZSB3aXRoIGJhbmR3 aWR0aCBmbHVjdHVhdGlvbnMuIDwvZm9udD48L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj48Zm9u dCBzaXplPSI0IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBJIGRvbid0IGRvdWJ0IHRo YXQgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBjYW4gY29wZSB3aXRoIGJhbmR3 aWR0aCBmbHVjdGF0aW9uLiBCdXQgSSBob3BlIHdlIGNhbiBkbyBiZXR0ZXIuPC9mb250Pjxmb250 IHNpemU9IjQiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ZS5nLiwgYWRhcHRpdmUgSFRUUCBzdHJl YW1pbmcgYWxnb3JpdGhtcyBvbmx5IHN1cHBvcnQgZGVsaXZlcnkgb2YgbXVsdGlwbGUgc3RyZWFt cyBvZiB0aGUgc2FtZSBjb250ZW50IHdpdGggdmFyeWluZyBxdWFsaXR5IGxldmVscyBmb3IgZGlm ZmVyZW50IGJhbmR3aWR0aCBvciBkZXZpY2VzLiBIb3dldmUgaG93IHRoZSBzZXJ2ZXIgaW4gcHVz aCBtb2RlbCBvciBjbGllbnQgaW4gcHVsbCBtb2RlbCBjYW4gcXVpY2sgcmVzcG9uc2UgdG8gdGhl IDwvZm9udD48Zm9udCBzaXplPSI0IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmJpdHJhdGUgY2hh bmdlcyBpcyBhIHByb2JsZW0gd2UgbWF5IGxvb2sgYXQsZXNwZWNpYWxseSB3aGVuIHN3aXRjaGlu ZyBiZXdlZW4gc3RyZWFtcyBvY2N1cnMgdmVyeSBmcmVxdWVudGx5LjwvZm9udD48L3ByZT48L2Rp dj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0i5a6L5L2TIj48L2ZvbnQ+PGJyPjwvZGl2PjxkaXY+W01XXSBZZXMsIGJ1dCBub3QgYSBwcm9i bGVtIGZvciB0aGUgSUVURiwgSSB0aGluay48L2Rpdj48ZGl2PiZuYnNwOzwvZGl2PjxkaXY+W1Fp bl06IEkgZGlkbid0IGdldCB3aGF0IHlvdSBzYWlkLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Zm9udCBzaXplPSI0Ij5hZGFwdGl2ZSBIVFRQIHN0cmVh bWluZyBhbGdvcml0aG1zPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIzIj5pcyBjaGFyYWN0ZXJpemVkIGFzJm5ic3A7IGNs aWVudCBpbml0aWF0ZWQgcHVsbCBtb2RlbC4gV2UgYXJlIGRpc2N1c3NpbmcgcHVzaCBtb2RlbCBv ciBob3cgdG8gdXNlIHB1bGwgbW9kZWwgd2l0aCBwdXNoIG1vZGVsLldlIGFyZSB0YWxraW5nIGFi b3V0IGRpZmZlcmVudCBtb2RlbC4gVGhlcmUgYXJlIHBsZW50eSByb29tIGZvciBJRVRGIHRvIGRv IGZvciB0aGlzLjxicj48L2ZvbnQ+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjwvc3Bhbj48L2Js b2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+W01XXSBTb3JyeSwgSSBkb24ndCB1bmRlcnN0YW5kIHdo YXQgdGhlICJwdXNoIiBtb2RlbCBoYXMgdG8gZG8gd2l0aCBIVFRQIFN0cmVhbWluZy4gQXJlIHlv dSB0YWxraW5nIGFib3V0IHNlcnZlcnMgd2hpY2ggYXJlIG5vdCByZWd1bGFyIEhUVFAgc2VydmVy cyA/IEkgdGhpbmsgdGhpcyBpcyBub3Qgd2hhdCBwZW9wbGUgdXN1YWxseSBtZWFuIHdoZW4gdGhl eSBzYXkgIkhUVFAgc3RyZWFtaW5nIiAtIHlvdSBzaG91bGQgcmVuYW1lIHRoZSB3b3JrIGlmIHRo YXQgaXMgdGhlIGNhc2UuPGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWln aHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRlci12 ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6 IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmb250LXNpemU6IG1lZGl1bTsgIj48ZGl2IGJnY29sb3I9IiNmZmZmZmYi PjxibG9ja3F1b3RlIGRpcj0ibHRyIiBzdHlsZT0iYm9yZGVyLWxlZnQtY29sb3I6IHJnYigwLCAw LCAwKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDJweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlkOyBw YWRkaW5nLWxlZnQ6IDVweDsgcGFkZGluZy1yaWdodDogMHB4OyBtYXJnaW4tbGVmdDogNXB4OyBt YXJnaW4tcmlnaHQ6IDBweDsgcG9zaXRpb246IHN0YXRpYzsgei1pbmRleDogYXV0bzsgIj48Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItbGVmdC1j b2xvcjogcmdiKDAsIDAsIDApOyBib3JkZXItbGVmdC13aWR0aDogMnB4OyBib3JkZXItbGVmdC1z dHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogNXB4OyBwYWRkaW5nLXJpZ2h0OiAwcHg7IG1hcmdp bi1sZWZ0OiA1cHg7IG1hcmdpbi1yaWdodDogMHB4OyAiPjxkaXY+PHByZSBjbGFzcz0ibmV3cGFn ZSI+ICAgLSBJbXBvc3NpYmxlIHRvIGZhc3QtZm9yd2FyZCB0aHJvdWdoIGFueSBwYXJ0IG9mIGEg c3RyZWFtaW5nDQogICBjb250ZW50cyB1bnRpbCBpdCBpcyBzdG9yZWQgb24gdGhlIHVzZXIncyBk ZXZpY2U8L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj5NVzogVGhpcyBpcyBzaW1wbHkgbm90IGNv cnJlY3QsIHNpbmNlIHRoZXJlIGFyZSBodW5kcmVkcyBvZiBleGFtcGxlcyBvZiBkZXZpY2VzIHdo aWNoIHN1cHBvcnQgdHJpY2stcGxheSB1c2luZyBIVFRQIHN0cmVhbWluZyB0ZWNobmlxdWVzIHdp dGhvdXQgc3RvcmluZyB0aGUgd2hvbGUgY29udGVudCBvbiB0aGUgdXNlcnMgZGV2aWNlLjwvcHJl PjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgIj48Zm9udCBz aXplPSI0IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBGYXN0IGZvcndhcmQgY2FwYWJp bHR5IGlzIG5vdCB0aGUgbW9zdCBpbXBvcnRhbnQgZmVhdHVyZSB3ZSBhcmUgbG9va2luZyBmb3Iu IEhvd2V2ZXIgSSBhbSBoYXJkIHRvIGJlbGlldmUgZXhpc3RpbmcgSFRUUCBzdHJlYW1pbmcgdGVj aG5pcXVlcyBjYW4gcHJvdmlkZSB0aGUgc2FtZSBkZWdyZWUgb2YgcGxheWJhY2s8L2ZvbnQ+PC9z cGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgIj48Zm9udCBzaXplPSI0IiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPmNvbnRyb2wgdGhhdCBEVkQgcGxheWVyIGNhbiBwcm92aWRlcyBvciBSVFNQ IHByb3RvY29sIHByb3ZpZGVzLiBFLmcuLCBJbiB0aGUgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcg YWxnb3JpdGhtcywgdGhlIHRyaWNrIHBsYXkgaXMgbGltaXRlZCB0byBwYXVzZS9yZXN1bWUvc3Rv cCBieSBkcml2aW5nIHRoZSBIVFRQIHJlcXVlc3QuIElmIHRoZSBjb250ZW50cyBoYXNuJ3QgYmVl biBkb3dsb2FkZWQgYW5kIHRoZSBjb25zdW1lIHdhbnQgZmFzdCBmb3J3YXJkLCB0aGUgSFRUUCBj bGllbnQgbmVlZHMgdG8gaXNzdWUgYW5vdGhlciBuZXcgSFRUUCByZXF1ZXN0IHRvIGZldGNoIHRo ZSBjb250ZW50cyB3aGljaCB3aWxsPC9mb250Pjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5 bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IHdoaXRlLXNwYWNlOiBub3Jt YWw7ICI+PGZvbnQgc2l6ZT0iNCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5jYXVzZSB1bmFjY2Vw dGFibGUgbGF0ZW5jeSB0byB0aGUgY29uc3VtZXIuPC9mb250Pjwvc3Bhbj48L3ByZT48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+W01XXSBBZ2FpbiwgdGhlIGV4cGVy aWVuY2Ugb2YgbWlsbGlvbnMgb2YgZXhpc3RpbmcgY3VzdG9tZXJzIHJlZnV0ZXMgd2hhdCB5b3Ug Y2xhaW0uIFdoeSBkbyB5b3UgdGhpbmsgaXQgaXMgbmVjZXNzYXJpbHkgc28gc2xvdyB0byBpc3N1 ZSBhIG5ldyBIVFRQIHJlcXVlc3QgZm9yIGEgZGlmZmVyZW50IHBhcnQgb2YgdGhlIGNvbnRlbnQ/ PC9kaXY+PGRpdj4mbmJzcDs8L2Rpdj48ZGl2PltRaW5dOiBZb3UgZGlkbid0IHNlZSB0aGUgcmVh b24gYmVoaW5kIHRoaXMsIGJlY29zIHRoZSBleGlzdGluZyBjdXN0b21lcnMgaGFzIG5vIGNob2lj ZSB3aGVuIHRoZXkgdmlldyBsaXZlIHN0cmVhbWluZywgd2hhdCB0aGV5IGNhbiBnZXQgaXMgY2xv c2UgdG8gbGl2ZSBleHBlcmllbmNlIHJhdGhlciB0aGFuIHJlYWwgdGltZSB1c2VyIGV4cGVyaWVu Y2UuIE9wZXJhdG9lciBkbyBub3RoaW5nIGZvciB0aGVpciBuZXR3b3JrIHRvIG1ha2UgaHR0cCBz dHJlYW1pbmcgbW9yZSBjb250cm9sbGFibGUgYW5kIG1hbmFnYWJsZS4gVGhlcmVmb3JlIG1vcmUg YW5kIG1vcmUgY29uc3VtZXImbmJzcDt0ZW5kIHRvJm5ic3A7Y2hvb3NlIG5vbi1saXZlIGNvbnRl bnQuIHRoYXQncyB3aHkgd2Ugc2VlIG1vcmUgYW5kIG1vcmUgbm9uLWxpdmUgY29udGVudCBjb25z dW1lcnMgcmF0aGVyIHRoYW4gbGl2ZSBjb250ZW50cyBjb25zdW1lcnMuPC9kaXY+PGRpdj48YnI+ PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjwvc3Bhbj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9k aXY+PGRpdj5bTVddIFdlbGwsIEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIHBvaW50LiBC dXQgc3RpbGwgdGhlIHN0YXRlbWVudCBpbiB0aGUgZHJhZnQgaXMgbm90IHRydWUuPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj4uLi5NYXJrPC9kaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9yZGVyLWNvbGxhcHNlOiBz ZXBhcmF0ZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogMjsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAt d2Via2l0LWJvcmRlci12ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0 aW9ucy1pbi1lZmZlY3Q6IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmb250LXNpemU6IG1lZGl1bTsgIj48ZGl2IGJn Y29sb3I9IiNmZmZmZmYiPjxibG9ja3F1b3RlIGRpcj0ibHRyIiBzdHlsZT0iYm9yZGVyLWxlZnQt Y29sb3I6IHJnYigwLCAwLCAwKTsgYm9yZGVyLWxlZnQtd2lkdGg6IDJweDsgYm9yZGVyLWxlZnQt c3R5bGU6IHNvbGlkOyBwYWRkaW5nLWxlZnQ6IDVweDsgcGFkZGluZy1yaWdodDogMHB4OyBtYXJn aW4tbGVmdDogNXB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgcG9zaXRpb246IHN0YXRpYzsgei1pbmRl eDogYXV0bzsgIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXItbGVmdC1jb2xvcjogcmdiKDAsIDAsIDApOyBib3JkZXItbGVmdC13aWR0aDogMnB4 OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IHBhZGRpbmctbGVmdDogNXB4OyBwYWRkaW5nLXJp Z2h0OiAwcHg7IG1hcmdpbi1sZWZ0OiA1cHg7IG1hcmdpbi1yaWdodDogMHB4OyAiPjxkaXY+PHBy ZSBjbGFzcz0ibmV3cGFnZSI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyAiPkEgZmlyc3Qgc3Rl cCBpbiBjb25zaWRlcmluZyB3aGF0LCBpZiBhbnksIHdvcmsgc2hvdWxkIGJlIGRvbmUgaGVyZSBt aWdodCBiZSB0byBjb250YWN0IHRob3NlIG9yZ2FuaXphdGlvbnMgd2hpY2ggYXJlIHN0YW5kYXJk aXppbmcgdGhlIGhpZ2hlciBsYXllcnMgb2YgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyAoZS5nLiBt YW5pZmVzdCBhbmQgZmlsZSBmb3JtYXRzKSBhbmQgYXNrIHdoZXRoZXIgdGhlcmUgYXJlIGRlZmlj aWVuY2llcyB0aGV5IHNlZSBpbiBJRVRGIHByb3RvY29scyB0aGF0IGNvdWxkIGJlIHVzZWZ1bGx5 IGFkZHJlc3NlZCBieSB0aGUgSUVURi4gV2hhdCBJIHRoaW5rIHdlIHNob3VsZCBhdm9pZCBpbiB0 aGUgSUVURiBpcyBkdXBsaWNhdGluZyB0aGUgd29yayBvZiB0aGVzZSBvdGhlciBib2RpZXMuPC9z cGFuPjwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1z cGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg Ij5CZXN0LDwvc3Bhbj48L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj48c3BhbiBjbGFzcz0iQXBw bGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IHdoaXRlLXNwYWNl OiBub3JtYWw7ICI+PGJyPjwvc3Bhbj48L3ByZT48cHJlIGNsYXNzPSJuZXdwYWdlIj48c3BhbiBj bGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IHdo aXRlLXNwYWNlOiBub3JtYWw7ICI+TWFyayBXYXRzb248L3NwYW4+PC9wcmU+PHByZSBjbGFzcz0i bmV3cGFnZSI+PGZvbnQgY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIGZhY2U9IkhlbHZldGljYSI+ PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogbm9ybWFs OyAiPk5ldGZsaXggSW5jLjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZSBjbGFzcz0ibmV3cGFnZSI+ PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyAiPjxicj48L3NwYW4+PC9wcmU+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PGRpdj48ZGl2Pk9uIE9jdCAxMCwgMjAx MCwgYXQgMTI6NDMgQU0sIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZTo8L2Rpdj48YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXY+PGJyPjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+RnJvbTo8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv Omh0dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9yZyI+PC9hPjxhIGhyZWY9Im1haWx0bzpodHRw c3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmciPmh0dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9y ZzwvYT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W21h aWx0bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMYXJzIEVn Z2VydDxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+U2VudDogRnJpZGF5 LCBPY3RvYmVyIDA4LCAyMDEwIDQ6MTcgUE08YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPlRvOiBDb2xpbiBQZXJraW5zPGJyPjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj5DYzo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmh0dHBzdHJlYW1pbmdAaWV0Zi5vcmciPjwvYT48YSBocmVm PSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwv YT48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlN1YmplY3Q6IFJlOiBb aHR0cHN0cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsPGJyPjwvYmxvY2txdW90 ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPk9uIDIwMTAtMTAtNywgYXQgMTQ6MTYsIENvbGluIFBlcmtpbnMgd3JvdGU6PGJy PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48YmxvY2txdW90ZSB0eXBlPSJj aXRlIj5UaGVyZSBhcmUgY2xlYXJseSBzb21lIGlzc3VlcyB0byBjb25zaWRlciBoZXJlLiBXaGF0 IHNlZW1zIHRvIGJlPGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+bWlzc2luZyBmcm9tIHRoZSBkaXNjdXNz aW9uIHRvIG1lIHRob3VnaCwgaXMgc29tZSBpZGVudGlmaWNhdGlvbiBvZjxicj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPnRoZSBjb25jcmV0ZSBwcm9ibGVtcy4gV2hhdCBwcm90b2NvbCBwaWVjZXMgZG8gd2Ug bmVlZCwgYnV0IG5vdCBoYXZlPzxicj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPldoYXQgcHJvdG9jb2xzIGFy ZSBwcm9ibGVtYXRpYywgYW5kIG5lZWQgZW5oYW5jZW1lbnQ/IElzIHRoZXJlPGJyPjwvYmxvY2tx dW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+cHJvdG9jb2wgd29yayB0byBkbyBpbiBJRVRGLCBvciBzaG91bGQgd2UgYmUgZG9j dW1lbnRpbmcgYmVzdCBjdXJyZW50PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+cHJhY3RpY2VzIGZvciB1 c2luZyB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZC9vciByZWx5aW5nIG9uIG90aGVyPGJyPjwv YmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+Ym9kaWVzIHRvIGZpbGwgdGhlIGdhcHM/PGJyPjwvYmxvY2txdW90ZT48 L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGhlIGRyYWZ0LXd1LWh0dHAtc3RyZWFtaW5nLW9wdGlt aXphdGlvbi1wcyBpcyBhIGdvb2Qgc3RhcnQgYXQgc3VjaCBhbjxicj48L2Jsb2NrcXVvdGU+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PmFuYWx5c2lzLCBidXQgZG9lc24ndCBnbyBkZWVwIGVub3VnaCB0byBsZXQgdXMgZGVjaWRlIHdo YXQgd29yayBJRVRGPGJyPjwvYmxvY2txdW90ZT48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+c2hvdWxkIGRvLjxicj48L2Jsb2NrcXVv dGU+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+ PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+KzE8YnI+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGhlIGtl eSBxdWVzdGlvbiByZWFsbHkgaXMgIndoYXQgZG8geW91IHRoaW5rIHRoZSBJRVRGIG5lZWRzIHRv IGRvPyI8YnI+PC9ibG9ja3F1b3RlPjxicj5JIGltYWdpbmUgdGhlIG9ubHkgd29yayB0aGUgSUVU RiBzaG91bGQgZG8gKGlmIHdlIGRlY2lkZSB0bykgaXMgdGhlIHRyYW5zcG9ydCBhbmQgSFRUUC1s YXllciBvcHRpbWl6YXRpb24gZm9yIGJldHRlciBzdHJlYW1pbmcgcGVyZm9ybWFuY2UuPGJyPjxi cj4tYWNiZWdlbjxicj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+TGFyczxicj48L2Jsb2Nr cXVvdGU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ aHR0cHN0cmVhbWluZyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOmh0dHBzdHJlYW1p bmdAaWV0Zi5vcmciPjwvYT48YSBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+ aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5nIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmc8L2E+PGJyPjxicj48L2Rpdj48L2Jsb2NrcXVv dGU+PC9kaXY+PGJyPjwvZGl2PjxkaXY+PGJyIGNsYXNzPSJ3ZWJraXQtYmxvY2stcGxhY2Vob2xk ZXIiPjwvZGl2Pjxocj48ZGl2PjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj48 L2Rpdj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5o dHRwc3RyZWFtaW5nIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWlu Z0BpZXRmLm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5nIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmc8L2E+PGJyPjwvYmxvY2tx dW90ZT48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ibG9ja3F1b3RlPjwvZGl2Pjwvc3Bhbj48L2Jsb2Nr cXVvdGU+PC9kaXY+PGJyPjwvYm9keT48L2h0bWw+ --_000_B9E38A0683924CCF9160D55F43BD75D8netflixcom_-- From abegen@cisco.com Thu Oct 14 15:49:35 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BCF13A6AF5 for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 15:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc9PupxIvk2L for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 15:49:34 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 363233A6A8B for <httpstreaming@ietf.org>; Thu, 14 Oct 2010 15:49:34 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG8mt0yrRN+K/2dsb2JhbAChI3GkZ5xxhUgEhFOIfA X-IronPort-AV: E=Sophos;i="4.57,333,1283731200"; d="scan'208";a="269791315" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 14 Oct 2010 22:50:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9EMos4Q005579; Thu, 14 Oct 2010 22:50:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 15:50:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 15:49:59 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> In-Reply-To: <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActraAPbUaG8jIgKSG2T9dtUBvoHzwAiQgmQ References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Qin Wu" <sunseawq@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> X-OriginalArrivalTime: 14 Oct 2010 22:50:54.0077 (UTC) FILETIME=[41D29AD0:01CB6BF2] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Oct 2010 22:49:35 -0000 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Thursday, October 14, 2010 2:21 AM > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > Hi, > ----- Original Message ----- > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> > Cc: <httpstreaming@ietf.org> > Sent: Tuesday, October 12, 2010 8:09 AM > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Monday, October 11, 2010 5:15 AM > > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > > Cc: httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > Hi,: > > ----- Original Message ----- > > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> > > Cc: <httpstreaming@ietf.org> > > Sent: Sunday, October 10, 2010 12:46 AM > > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > > > > > > > > -----Original Message----- > > > From: Qin Wu [mailto:sunseawq@huawei.com] > > > Sent: Friday, October 08, 2010 4:16 PM > > > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > > > Cc: httpstreaming@ietf.org > > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > > > also a need for video synchronization to start rendering. > > > > > > Synchronization among the viewers you mean? That could be a = concern but seriously, since client implementations will > > > differ, network capacities will differ, i.e., pretty much = everything will differ for different clients, I don't think there is a > > > solution to this. Better said, I don't think there is a problem. > > > > > > [Qin] I think Synchronization between the server and the client is = one issue we may look at. Since the server has buffer for > > > encoding, the client has a buffer for playout, we definitely need = one streaming media synchronization mechanism which > > may > > > help reduce delay. > > > > Sorry, I don=92t get this. Server or someone else advertises what is = available to the client and client fetches whatever it wants > > (and is available). Why is there a need for synchronization here? > > > > [Qin]: We may look at two different use cases: push model and pull = model > > In the pull model, you are right. The client control the timing of = fetching the chunks by driving the HTTP request. It only > > request it needs and can handle. However client based pull is = characterized > > as polling for new data each time and is not efficient way to = deliver the real time streaming contents. >=20 > By polling I suppose you mean sending HTTP requests. Well, that is = pretty much implied by using HTTP, which is a request- > response protocol and this makes HTTP as stateless as possible. And = IMO sending individual requests offer more advantages > than disadvantages. >=20 > [Qin]: Suppose ten chunks are available at the server, the client in = pull model MUST send ten requests to fetch all the chunks > and server should answer with ten response with each chunk. > however in the push model, I think the client only need to initiate = one request and then the server control ten chunks delivery > and push ten chunks to the client one by one. > Isn't the push model more efficient than pull model from transport = perspective? Depends. Just because in the push model there are less request messages, = it does not mean it is more efficient. That would be a bad definition = for efficiency. The pull model brings many advantages that the push = model cannot offer (at the same flexibility). I am not saying one is = better than the other, but your scope for determining efficiency is = rather limited. =20 > > In the push model, the client does not know when the conents is = available at the server. For the client will not send request > > for each chunks. the client clock is easy to asynchronize with = encoder clock. >=20 > Well the server can push the content (in a push model) but it still is = dependent on the client implementation to determine > what to do with that content. One implementation, if it wants, can = start playing it 10 hours later for all we care. I still don't > get what you are trying to do here. >=20 > [Qin]: In the push model, the server didn't know the client capability = to consume streaming data, i.e., the server didn't know > how fast the client process live streaming. If the encoding rate at = the server is faster than comsuing rate at the client, the > buffer will overflow. If the encoding rate at the server is slower = than comsuing rate at the client, the buffer will underflow. For both on-demand and live streaming, the encoding rate is supposed to = be equal to consumption rate (which sounds to me as the rate the decoder = is consuming). What you are referring to as buffer overflow or underflow = is related to streaming or transmission rate. On the long-term average, = all these need to be equal anyway. But, I will just repeat myself. = Neither has anything to do with clock synchronization between the server = and client. The client can choose the buffer duration and the actual = playback time. -acbegen From sunseawq@huawei.com Thu Oct 14 17:56:25 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5733A69FA for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 17:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.991 X-Spam-Level: X-Spam-Status: No, score=0.991 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj64xfcUEKSl for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 17:56:22 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id CB04D3A68D5 for <httpstreaming@ietf.org>; Thu, 14 Oct 2010 17:56:21 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00KW03ZVOF@szxga04-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 08:57:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB001VR3ZVT1@szxga04-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 08:57:31 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB009L23ZUW1@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 08:57:31 +0800 (CST) Date: Fri, 15 Oct 2010 08:57:30 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <009c01cb6c03$f2125320$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 00:56:25 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsaSBDLiBCZWdlbiAo YWJlZ2VuKSIgPGFiZWdlbkBjaXNjby5jb20+DQpUbzogIlFpbiBXdSIgPHN1bnNlYXdxQGh1YXdl aS5jb20+OyAiUm9uaSBFdmVuIiA8RXZlbi5yb25pQGh1YXdlaS5jb20+OyAiRGF2aWQgQS4gQnJ5 YW4iIDxkYnJ5YW5AZXRoZXJub3Qub3JnPg0KQ2M6IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0K U2VudDogRnJpZGF5LCBPY3RvYmVyIDE1LCAyMDEwIDY6NDkgQU0NClN1YmplY3Q6IFJFOiBbaHR0 cHN0cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQoNCg0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUWluIFd1IFttYWlsdG86c3Vuc2Vhd3FAaHVh d2VpLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTQsIDIwMTAgMjoyMSBBTQ0KPiBU bzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pOyBSb25pIEV2ZW47IERhdmlkIEEuIEJyeWFuDQo+IENj OiBodHRwc3RyZWFtaW5nQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10g Q3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQo+IA0KPiBIaSwNCj4gLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNp c2NvLmNvbT4NCj4gVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPjsgIlJvbmkgRXZl biIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJyeWFuIiA8ZGJyeWFuQGV0aGVy bm90Lm9yZz4NCj4gQ2M6IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0KPiBTZW50OiBUdWVzZGF5 LCBPY3RvYmVyIDEyLCAyMDEwIDg6MDkgQU0NCj4gU3ViamVjdDogUkU6IFtodHRwc3RyZWFtaW5n XSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiBGcm9tOiBRaW4gV3UgW21haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tXQ0K PiA+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMSwgMjAxMCA1OjE1IEFNDQo+ID4gVG86IEFsaSBD LiBCZWdlbiAoYWJlZ2VuKTsgUm9uaSBFdmVuOyBEYXZpZCBBLiBCcnlhbg0KPiA+IENjOiBodHRw c3RyZWFtaW5nQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJy ZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4gPg0KPiA+IEhpLDoNCj4gPiAtLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogIkFsaSBDLiBCZWdlbiAoYWJlZ2VuKSIgPGFiZWdl bkBjaXNjby5jb20+DQo+ID4gVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPjsgIlJv bmkgRXZlbiIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJyeWFuIiA8ZGJyeWFu QGV0aGVybm90Lm9yZz4NCj4gPiBDYzogPGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+DQo+ID4gU2Vu dDogU3VuZGF5LCBPY3RvYmVyIDEwLCAyMDEwIDEyOjQ2IEFNDQo+ID4gU3ViamVjdDogUkU6IFto dHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4gPg0KPiA+DQo+ID4N Cj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFFpbiBX dSBbbWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiBGcmlkYXksIE9jdG9i ZXIgMDgsIDIwMTAgNDoxNiBQTQ0KPiA+ID4gVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTsgUm9u aSBFdmVuOyBEYXZpZCBBLiBCcnlhbg0KPiA+ID4gQ2M6IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcN Cj4gPiA+IFN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91 ciBHb2FsDQo+ID4gPg0KPiA+ID4gPiBhbHNvIGEgbmVlZCBmb3IgdmlkZW8gc3luY2hyb25pemF0 aW9uIHRvIHN0YXJ0IHJlbmRlcmluZy4NCj4gPiA+DQo+ID4gPiBTeW5jaHJvbml6YXRpb24gYW1v bmcgdGhlIHZpZXdlcnMgeW91IG1lYW4/IFRoYXQgY291bGQgYmUgYSBjb25jZXJuIGJ1dCBzZXJp b3VzbHksIHNpbmNlIGNsaWVudCBpbXBsZW1lbnRhdGlvbnMgd2lsbA0KPiA+ID4gZGlmZmVyLCBu ZXR3b3JrIGNhcGFjaXRpZXMgd2lsbCBkaWZmZXIsIGkuZS4sIHByZXR0eSBtdWNoIGV2ZXJ5dGhp bmcgd2lsbCBkaWZmZXIgZm9yIGRpZmZlcmVudCBjbGllbnRzLCBJIGRvbid0IHRoaW5rIHRoZXJl IGlzIGENCj4gPiA+IHNvbHV0aW9uIHRvIHRoaXMuIEJldHRlciBzYWlkLCBJIGRvbid0IHRoaW5r IHRoZXJlIGlzIGEgcHJvYmxlbS4NCj4gPiA+DQo+ID4gPiBbUWluXSBJIHRoaW5rIFN5bmNocm9u aXphdGlvbiBiZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQgaXMgb25lIGlzc3VlIHdl IG1heSBsb29rIGF0LiBTaW5jZSB0aGUgc2VydmVyIGhhcyBidWZmZXIgZm9yDQo+ID4gPiBlbmNv ZGluZywgdGhlIGNsaWVudCBoYXMgYSBidWZmZXIgZm9yIHBsYXlvdXQsIHdlIGRlZmluaXRlbHkg bmVlZCBvbmUgc3RyZWFtaW5nIG1lZGlhIHN5bmNocm9uaXphdGlvbiBtZWNoYW5pc20gd2hpY2gN Cj4gPiBtYXkNCj4gPiA+IGhlbHAgcmVkdWNlIGRlbGF5Lg0KPiA+DQo+ID4gU29ycnksIEkgZG9u knQgZ2V0IHRoaXMuIFNlcnZlciBvciBzb21lb25lIGVsc2UgYWR2ZXJ0aXNlcyB3aGF0IGlzIGF2 YWlsYWJsZSB0byB0aGUgY2xpZW50IGFuZCBjbGllbnQgZmV0Y2hlcyB3aGF0ZXZlciBpdCB3YW50 cw0KPiA+IChhbmQgaXMgYXZhaWxhYmxlKS4gV2h5IGlzIHRoZXJlIGEgbmVlZCBmb3Igc3luY2hy b25pemF0aW9uIGhlcmU/DQo+ID4NCj4gPiBbUWluXTogV2UgbWF5IGxvb2sgYXQgdHdvIGRpZmZl cmVudCAgdXNlIGNhc2VzOiBwdXNoIG1vZGVsIGFuZCBwdWxsIG1vZGVsDQo+ID4gSW4gdGhlIHB1 bGwgbW9kZWwsIHlvdSBhcmUgcmlnaHQuIFRoZSBjbGllbnQgIGNvbnRyb2wgdGhlIHRpbWluZyBv ZiBmZXRjaGluZyB0aGUgY2h1bmtzIGJ5IGRyaXZpbmcgdGhlIEhUVFAgcmVxdWVzdC4gSXQgb25s eQ0KPiA+IHJlcXVlc3QgaXQgbmVlZHMgYW5kIGNhbiBoYW5kbGUuIEhvd2V2ZXIgIGNsaWVudCBi YXNlZCBwdWxsIGlzIGNoYXJhY3Rlcml6ZWQNCj4gPiBhcyBwb2xsaW5nIGZvciBuZXcgZGF0YSBl YWNoIHRpbWUgYW5kIGlzIG5vdCBlZmZpY2llbnQgd2F5IHRvIGRlbGl2ZXIgdGhlIHJlYWwgdGlt ZSBzdHJlYW1pbmcgY29udGVudHMuDQo+IA0KPiBCeSBwb2xsaW5nIEkgc3VwcG9zZSB5b3UgbWVh biBzZW5kaW5nIEhUVFAgcmVxdWVzdHMuIFdlbGwsIHRoYXQgaXMgcHJldHR5IG11Y2ggaW1wbGll ZCBieSB1c2luZyBIVFRQLCB3aGljaCBpcyBhIHJlcXVlc3QtDQo+IHJlc3BvbnNlIHByb3RvY29s IGFuZCB0aGlzIG1ha2VzIEhUVFAgYXMgc3RhdGVsZXNzIGFzIHBvc3NpYmxlLiBBbmQgSU1PIHNl bmRpbmcgaW5kaXZpZHVhbCByZXF1ZXN0cyBvZmZlciBtb3JlIGFkdmFudGFnZXMNCj4gdGhhbiBk aXNhZHZhbnRhZ2VzLg0KPiANCj4gW1Fpbl06IFN1cHBvc2UgdGVuIGNodW5rcyBhcmUgYXZhaWxh YmxlIGF0IHRoZSBzZXJ2ZXIsIHRoZSBjbGllbnQgaW4gcHVsbCBtb2RlbCBNVVNUIHNlbmQgdGVu IHJlcXVlc3RzIHRvIGZldGNoIGFsbCB0aGUgY2h1bmtzDQo+IGFuZCBzZXJ2ZXIgc2hvdWxkIGFu c3dlciB3aXRoIHRlbiByZXNwb25zZSB3aXRoIGVhY2ggY2h1bmsuDQo+IGhvd2V2ZXIgaW4gdGhl IHB1c2ggbW9kZWwsIEkgdGhpbmsgdGhlIGNsaWVudCBvbmx5IG5lZWQgdG8gaW5pdGlhdGUgb25l IHJlcXVlc3QgYW5kIHRoZW4gdGhlIHNlcnZlciBjb250cm9sIHRlbiBjaHVua3MgZGVsaXZlcnkN Cj4gYW5kIHB1c2ggdGVuIGNodW5rcyB0byB0aGUgY2xpZW50IG9uZSBieSBvbmUuDQo+ICBJc24n dCB0aGUgcHVzaCBtb2RlbCBtb3JlIGVmZmljaWVudCB0aGFuIHB1bGwgbW9kZWwgZnJvbSB0cmFu c3BvcnQgcGVyc3BlY3RpdmU/DQoNCkRlcGVuZHMuIEp1c3QgYmVjYXVzZSBpbiB0aGUgcHVzaCBt b2RlbCB0aGVyZSBhcmUgbGVzcyByZXF1ZXN0IG1lc3NhZ2VzLCBpdCBkb2VzIG5vdCBtZWFuIGl0 IGlzIG1vcmUgZWZmaWNpZW50LiBUaGF0IHdvdWxkIGJlIGEgYmFkIGRlZmluaXRpb24gZm9yIGVm ZmljaWVuY3kuIFRoZSBwdWxsIG1vZGVsIGJyaW5ncyBtYW55IGFkdmFudGFnZXMgdGhhdCB0aGUg cHVzaCBtb2RlbCBjYW5ub3Qgb2ZmZXIgKGF0IHRoZSBzYW1lIGZsZXhpYmlsaXR5KS4gSSBhbSBu b3Qgc2F5aW5nIG9uZSBpcyBiZXR0ZXIgdGhhbiB0aGUgb3RoZXIsIGJ1dCB5b3VyIHNjb3BlIGZv ciBkZXRlcm1pbmluZyBlZmZpY2llbmN5IGlzIHJhdGhlciBsaW1pdGVkLg0KDQpbUWluXTogT2th eS4gQnV0IElmIHlvdSBsb29rIGF0IHdlYnNvY2tldCBwcm90b2NvbCBhcyBwdXNoIG1vZGVsLCBw cm9iYWJseSB5b3Ugd2lsbCBmaW5kIHRoZXkgY2FuIGJlIHVzZWQgYWNjZWxlcmF0ZSBicm93c2Vy IGFuZCBpbXByb3ZlIGVmZmljaWVuY3kuDQogDQo+ID4gSW4gdGhlIHB1c2ggbW9kZWwsIHRoZSBj bGllbnQgZG9lcyBub3Qga25vdyB3aGVuIHRoZSBjb25lbnRzIGlzIGF2YWlsYWJsZSBhdCB0aGUg c2VydmVyLiBGb3IgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kIHJlcXVlc3QNCj4gPiBmb3IgZWFj aCBjaHVua3MuIHRoZSBjbGllbnQgY2xvY2sgaXMgZWFzeSB0byBhc3luY2hyb25pemUgd2l0aCBl bmNvZGVyIGNsb2NrLg0KPiANCj4gV2VsbCB0aGUgc2VydmVyIGNhbiBwdXNoIHRoZSBjb250ZW50 IChpbiBhIHB1c2ggbW9kZWwpIGJ1dCBpdCBzdGlsbCBpcyBkZXBlbmRlbnQgb24gdGhlIGNsaWVu dCBpbXBsZW1lbnRhdGlvbiB0byBkZXRlcm1pbmUNCj4gd2hhdCB0byBkbyB3aXRoIHRoYXQgY29u dGVudC4gT25lIGltcGxlbWVudGF0aW9uLCBpZiBpdCB3YW50cywgY2FuIHN0YXJ0IHBsYXlpbmcg aXQgMTAgaG91cnMgbGF0ZXIgZm9yIGFsbCB3ZSBjYXJlLiBJIHN0aWxsIGRvbid0DQo+IGdldCB3 aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGRvIGhlcmUuDQo+IA0KPiBbUWluXTogSW4gdGhlIHB1c2gg bW9kZWwsIHRoZSBzZXJ2ZXIgZGlkbid0IGtub3cgdGhlIGNsaWVudCBjYXBhYmlsaXR5IHRvIGNv bnN1bWUgc3RyZWFtaW5nIGRhdGEsIGkuZS4sIHRoZSBzZXJ2ZXIgZGlkbid0IGtub3cNCj4gaG93 IGZhc3QgdGhlIGNsaWVudCBwcm9jZXNzIGxpdmUgc3RyZWFtaW5nLiBJZiB0aGUgZW5jb2Rpbmcg cmF0ZSBhdCB0aGUgc2VydmVyIGlzIGZhc3RlciB0aGFuIGNvbXN1aW5nIHJhdGUgYXQgdGhlIGNs aWVudCwgdGhlDQo+IGJ1ZmZlciB3aWxsIG92ZXJmbG93LiBJZiB0aGUgZW5jb2RpbmcgcmF0ZSBh dCB0aGUgc2VydmVyIGlzIHNsb3dlciB0aGFuIGNvbXN1aW5nIHJhdGUgYXQgdGhlIGNsaWVudCwg dGhlIGJ1ZmZlciB3aWxsIHVuZGVyZmxvdy4NCg0KRm9yIGJvdGggb24tZGVtYW5kIGFuZCBsaXZl IHN0cmVhbWluZywgdGhlIGVuY29kaW5nIHJhdGUgaXMgc3VwcG9zZWQgdG8gYmUgZXF1YWwgdG8g Y29uc3VtcHRpb24gcmF0ZSAod2hpY2ggc291bmRzIHRvIG1lIGFzIHRoZSByYXRlIHRoZSBkZWNv ZGVyIGlzIGNvbnN1bWluZykuIFdoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gYXMgYnVmZmVyIG92 ZXJmbG93IG9yIHVuZGVyZmxvdyBpcyByZWxhdGVkIHRvIHN0cmVhbWluZyBvciB0cmFuc21pc3Np b24gcmF0ZS4gT24gdGhlIGxvbmctdGVybSBhdmVyYWdlLCBhbGwgdGhlc2UgbmVlZCB0byBiZSBl cXVhbCBhbnl3YXkuIA0KDQpbUWluXTogQnV0IEhvdywgaXMgdGhlcmUgYW55IHdheSB0byBkbyB0 aGlzPyBvciB0aGV5IGp1c3Qgd2FpdCBmb3IgcmVidWZmZXJpbmcgYW5kIHRoZW4gcmVjb3ZlciBi eSBpdHNlbGYuDQoNCkJ1dCwgSSB3aWxsIGp1c3QgcmVwZWF0IG15c2VsZi4gTmVpdGhlciBoYXMg YW55dGhpbmcgdG8gZG8gd2l0aCBjbG9jayBzeW5jaHJvbml6YXRpb24gYmV0d2VlbiB0aGUgc2Vy dmVyIGFuZCBjbGllbnQuIA0KDQpbUWluXTogT2theS4NCg0KVGhlIGNsaWVudCBjYW4gY2hvb3Nl IHRoZSBidWZmZXIgZHVyYXRpb24gYW5kIHRoZSBhY3R1YWwgcGxheWJhY2sgdGltZS4NCg0KW1Fp bl06IFN1cHBvc2UgdGhlIGNodW5rcyBpcyBub3QgcmVhZHkgaW4gdGhlIHBsYXlvdXQgYnVmZmVy IGF0IHRoZSBjbGllbnQsIGRvZXMgaXQgbWVhbiB0aGF0IHRoZSBjbGllbnQganVzdCBzbG93IGRv d24gcGxheWJhY2sgc3BlZWQgYW5kIHdhaXQgZm9yIHN1YnNlcXVlbnQgY2h1bmtzIGlzIGFycml2 aW5nIGF0IHRoZSBwbGF5YmFjayBidWZmZXIgYW5kIHRoZW4gY2xpZW50IHJlc3VtZSB0aGUgbm9y bWFsDQpwbGF5YmFjayBzcGVlZD8NCg0KLWFjYmVnZW4NCg== From abegen@cisco.com Thu Oct 14 18:09:56 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18BF3A68D5 for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 18:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R55pryzc1TBu for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 18:09:53 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4DC2E3A686B for <httpstreaming@ietf.org>; Thu, 14 Oct 2010 18:09:53 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAItGt0yrR7Ht/2dsb2JhbAChI3GkIpxahUgEhFOIfA X-IronPort-AV: E=Sophos;i="4.57,333,1283731200"; d="scan'208";a="201157988" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 15 Oct 2010 01:11:12 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9F1BCoO020339; Fri, 15 Oct 2010 01:11:12 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 18:11:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 18:11:12 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> In-Reply-To: <009c01cb6c03$f2125320$30298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActsA/OrUGIwuEiGTuKEzGfd++dUlAAAEeHw References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Qin Wu" <sunseawq@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> X-OriginalArrivalTime: 15 Oct 2010 01:11:12.0304 (UTC) FILETIME=[DB7A1B00:01CB6C05] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 01:09:56 -0000 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Thursday, October 14, 2010 8:58 PM > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > Hi, > ----- Original Message ----- > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> > Cc: <httpstreaming@ietf.org> > Sent: Friday, October 15, 2010 6:49 AM > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Qin Wu [mailto:sunseawq@huawei.com] > > Sent: Thursday, October 14, 2010 2:21 AM > > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > > Cc: httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > Hi, > > ----- Original Message ----- > > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> > > Cc: <httpstreaming@ietf.org> > > Sent: Tuesday, October 12, 2010 8:09 AM > > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > > -----Original Message----- > > > From: Qin Wu [mailto:sunseawq@huawei.com] > > > Sent: Monday, October 11, 2010 5:15 AM > > > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > > > Cc: httpstreaming@ietf.org > > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > > Hi,: > > > ----- Original Message ----- > > > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > > > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" > <dbryan@ethernot.org> > > > Cc: <httpstreaming@ietf.org> > > > Sent: Sunday, October 10, 2010 12:46 AM > > > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Qin Wu [mailto:sunseawq@huawei.com] > > > > Sent: Friday, October 08, 2010 4:16 PM > > > > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > > > > Cc: httpstreaming@ietf.org > > > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > > > > > also a need for video synchronization to start rendering. > > > > > > > > Synchronization among the viewers you mean? That could be a = concern but seriously, since client implementations will > > > > differ, network capacities will differ, i.e., pretty much = everything will differ for different clients, I don't think there is a > > > > solution to this. Better said, I don't think there is a problem. > > > > > > > > [Qin] I think Synchronization between the server and the client = is one issue we may look at. Since the server has buffer > for > > > > encoding, the client has a buffer for playout, we definitely = need one streaming media synchronization mechanism > which > > > may > > > > help reduce delay. > > > > > > Sorry, I don=92t get this. Server or someone else advertises what = is available to the client and client fetches whatever it > wants > > > (and is available). Why is there a need for synchronization here? > > > > > > [Qin]: We may look at two different use cases: push model and = pull model > > > In the pull model, you are right. The client control the timing = of fetching the chunks by driving the HTTP request. It only > > > request it needs and can handle. However client based pull is = characterized > > > as polling for new data each time and is not efficient way to = deliver the real time streaming contents. > > > > By polling I suppose you mean sending HTTP requests. Well, that is = pretty much implied by using HTTP, which is a request- > > response protocol and this makes HTTP as stateless as possible. And = IMO sending individual requests offer more > advantages > > than disadvantages. > > > > [Qin]: Suppose ten chunks are available at the server, the client in = pull model MUST send ten requests to fetch all the > chunks > > and server should answer with ten response with each chunk. > > however in the push model, I think the client only need to initiate = one request and then the server control ten chunks > delivery > > and push ten chunks to the client one by one. > > Isn't the push model more efficient than pull model from transport = perspective? >=20 > Depends. Just because in the push model there are less request = messages, it does not mean it is more efficient. That would > be a bad definition for efficiency. The pull model brings many = advantages that the push model cannot offer (at the same > flexibility). I am not saying one is better than the other, but your = scope for determining efficiency is rather limited. >=20 > [Qin]: Okay. But If you look at websocket protocol as push model, = probably you will find they can be used accelerate browser > and improve efficiency. But, in http streaming scenario, the ratio of download/upload (from the = client's perspective) is much larger than 1. BTW, if you keep your chunk = duration relatively longer, the amount of requests that you will end up = sending will be almost nil compared to what you will receive. =20 > > > In the push model, the client does not know when the conents is = available at the server. For the client will not send > request > > > for each chunks. the client clock is easy to asynchronize with = encoder clock. > > > > Well the server can push the content (in a push model) but it still = is dependent on the client implementation to determine > > what to do with that content. One implementation, if it wants, can = start playing it 10 hours later for all we care. I still don't > > get what you are trying to do here. > > > > [Qin]: In the push model, the server didn't know the client = capability to consume streaming data, i.e., the server didn't > know > > how fast the client process live streaming. If the encoding rate at = the server is faster than comsuing rate at the client, the > > buffer will overflow. If the encoding rate at the server is slower = than comsuing rate at the client, the buffer will underflow. >=20 > For both on-demand and live streaming, the encoding rate is supposed = to be equal to consumption rate (which sounds to me > as the rate the decoder is consuming). What you are referring to as = buffer overflow or underflow is related to streaming or > transmission rate. On the long-term average, all these need to be = equal anyway. >=20 > [Qin]: But How, is there any way to do this? or they just wait for = rebuffering and then recover by itself. > > But, I will just repeat myself. Neither has anything to do with clock = synchronization between the server and client. >=20 > [Qin]: Okay. >=20 > The client can choose the buffer duration and the actual playback = time. >=20 > [Qin]: Suppose the chunks is not ready in the playout buffer at the = client, does it mean that the client just slow down playback > speed and wait for subsequent chunks is arriving at the playback = buffer and then client resume the normal > playback speed? Sorry if "playback time" meant the duration of the playback. I rather = meant the start time of the playback. So, if a client keeps a larger = buffer hoping that it will avoid buffer underruns, this may delay the = playback start time. Or, the client can start the playback quickly and = build the buffer over time by requesting lower-bitrate chunks. Whether it paces the presentation speed down or not in order to avoid = buffer underruns is something up to the client. Most implementations I = have seen simply switch to a lower-bitrate profile well before the = buffer is fully drained. So, they don't experience buffer underruns and = they don=92t need to pace the video presentation speed down. -acbegen From sunseawq@huawei.com Thu Oct 14 18:49:34 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE343A6956 for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 18:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQAbkqa0N17c for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 18:49:33 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 920DA3A67E2 for <httpstreaming@ietf.org>; Thu, 14 Oct 2010 18:49:32 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00EBG6GI1N@szxga02-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 09:50:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00B1W6GIRU@szxga02-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 09:50:42 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB00C896GH2B@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 09:50:41 +0800 (CST) Date: Fri, 15 Oct 2010 09:50:41 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 01:49:34 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkFsaSBDLiBCZWdlbiAo YWJlZ2VuKSIgPGFiZWdlbkBjaXNjby5jb20+DQpUbzogIlFpbiBXdSIgPHN1bnNlYXdxQGh1YXdl aS5jb20+OyAiUm9uaSBFdmVuIiA8RXZlbi5yb25pQGh1YXdlaS5jb20+OyAiRGF2aWQgQS4gQnJ5 YW4iIDxkYnJ5YW5AZXRoZXJub3Qub3JnPg0KQ2M6IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0K U2VudDogRnJpZGF5LCBPY3RvYmVyIDE1LCAyMDEwIDk6MTEgQU0NClN1YmplY3Q6IFJFOiBbaHR0 cHN0cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQoNCg0KDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUWluIFd1IFttYWlsdG86c3Vuc2Vhd3FAaHVh d2VpLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTQsIDIwMTAgODo1OCBQTQ0KPiBU bzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pOyBSb25pIEV2ZW47IERhdmlkIEEuIEJyeWFuDQo+IENj OiBodHRwc3RyZWFtaW5nQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10g Q3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQo+IA0KPiBIaSwNCj4gLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLQ0KPiBGcm9tOiAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNp c2NvLmNvbT4NCj4gVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPjsgIlJvbmkgRXZl biIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJyeWFuIiA8ZGJyeWFuQGV0aGVy bm90Lm9yZz4NCj4gQ2M6IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0KPiBTZW50OiBGcmlkYXks IE9jdG9iZXIgMTUsIDIwMTAgNjo0OSBBTQ0KPiBTdWJqZWN0OiBSRTogW2h0dHBzdHJlYW1pbmdd IEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KPiANCj4gDQo+IA0KPiANCj4gPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFFpbiBXdSBbbWFpbHRvOnN1bnNlYXdxQGh1 YXdlaS5jb21dDQo+ID4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMTQsIDIwMTAgMjoyMSBBTQ0K PiA+IFRvOiBBbGkgQy4gQmVnZW4gKGFiZWdlbik7IFJvbmkgRXZlbjsgRGF2aWQgQS4gQnJ5YW4N Cj4gPiBDYzogaHR0cHN0cmVhbWluZ0BpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFJlOiBbaHR0cHN0 cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQo+ID4NCj4gPiBIaSwNCj4gPiAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogIkFsaSBDLiBCZWdlbiAoYWJl Z2VuKSIgPGFiZWdlbkBjaXNjby5jb20+DQo+ID4gVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3 ZWkuY29tPjsgIlJvbmkgRXZlbiIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJy eWFuIiA8ZGJyeWFuQGV0aGVybm90Lm9yZz4NCj4gPiBDYzogPGh0dHBzdHJlYW1pbmdAaWV0Zi5v cmc+DQo+ID4gU2VudDogVHVlc2RheSwgT2N0b2JlciAxMiwgMjAxMCA4OjA5IEFNDQo+ID4gU3Vi amVjdDogUkU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4g Pg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFFpbiBXdSBb bWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb21dDQo+ID4gPiBTZW50OiBNb25kYXksIE9jdG9iZXIg MTEsIDIwMTAgNToxNSBBTQ0KPiA+ID4gVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKTsgUm9uaSBF dmVuOyBEYXZpZCBBLiBCcnlhbg0KPiA+ID4gQ2M6IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcNCj4g PiA+IFN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91ciBH b2FsDQo+ID4gPg0KPiA+ID4gSGksOg0KPiA+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LQ0KPiA+ID4gRnJvbTogIkFsaSBDLiBCZWdlbiAoYWJlZ2VuKSIgPGFiZWdlbkBjaXNjby5jb20+ DQo+ID4gPiBUbzogIlFpbiBXdSIgPHN1bnNlYXdxQGh1YXdlaS5jb20+OyAiUm9uaSBFdmVuIiA8 RXZlbi5yb25pQGh1YXdlaS5jb20+OyAiRGF2aWQgQS4gQnJ5YW4iDQo+IDxkYnJ5YW5AZXRoZXJu b3Qub3JnPg0KPiA+ID4gQ2M6IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0KPiA+ID4gU2VudDog U3VuZGF5LCBPY3RvYmVyIDEwLCAyMDEwIDEyOjQ2IEFNDQo+ID4gPiBTdWJqZWN0OiBSRTogW2h0 dHBzdHJlYW1pbmddIEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KPiA+ID4NCj4gPiA+DQo+ ID4gPg0KPiA+ID4NCj4gPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g RnJvbTogUWluIFd1IFttYWlsdG86c3Vuc2Vhd3FAaHVhd2VpLmNvbV0NCj4gPiA+ID4gU2VudDog RnJpZGF5LCBPY3RvYmVyIDA4LCAyMDEwIDQ6MTYgUE0NCj4gPiA+ID4gVG86IEFsaSBDLiBCZWdl biAoYWJlZ2VuKTsgUm9uaSBFdmVuOyBEYXZpZCBBLiBCcnlhbg0KPiA+ID4gPiBDYzogaHR0cHN0 cmVhbWluZ0BpZXRmLm9yZw0KPiA+ID4gPiBTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1 cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KPiA+ID4gPg0KPiA+ID4gPiA+IGFsc28gYSBuZWVk IGZvciB2aWRlbyBzeW5jaHJvbml6YXRpb24gdG8gc3RhcnQgcmVuZGVyaW5nLg0KPiA+ID4gPg0K PiA+ID4gPiBTeW5jaHJvbml6YXRpb24gYW1vbmcgdGhlIHZpZXdlcnMgeW91IG1lYW4/IFRoYXQg Y291bGQgYmUgYSBjb25jZXJuIGJ1dCBzZXJpb3VzbHksIHNpbmNlIGNsaWVudCBpbXBsZW1lbnRh dGlvbnMgd2lsbA0KPiA+ID4gPiBkaWZmZXIsIG5ldHdvcmsgY2FwYWNpdGllcyB3aWxsIGRpZmZl ciwgaS5lLiwgcHJldHR5IG11Y2ggZXZlcnl0aGluZyB3aWxsIGRpZmZlciBmb3IgZGlmZmVyZW50 IGNsaWVudHMsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYQ0KPiA+ID4gPiBzb2x1dGlvbiB0byB0 aGlzLiBCZXR0ZXIgc2FpZCwgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIHByb2JsZW0uDQo+ID4g PiA+DQo+ID4gPiA+IFtRaW5dIEkgdGhpbmsgU3luY2hyb25pemF0aW9uIGJldHdlZW4gdGhlIHNl cnZlciBhbmQgdGhlIGNsaWVudCBpcyBvbmUgaXNzdWUgd2UgbWF5IGxvb2sgYXQuIFNpbmNlIHRo ZSBzZXJ2ZXIgaGFzIGJ1ZmZlcg0KPiBmb3INCj4gPiA+ID4gZW5jb2RpbmcsIHRoZSBjbGllbnQg aGFzIGEgYnVmZmVyIGZvciBwbGF5b3V0LCB3ZSBkZWZpbml0ZWx5IG5lZWQgb25lIHN0cmVhbWlu ZyBtZWRpYSBzeW5jaHJvbml6YXRpb24gbWVjaGFuaXNtDQo+IHdoaWNoDQo+ID4gPiBtYXkNCj4g PiA+ID4gaGVscCByZWR1Y2UgZGVsYXkuDQo+ID4gPg0KPiA+ID4gU29ycnksIEkgZG9uknQgZ2V0 IHRoaXMuIFNlcnZlciBvciBzb21lb25lIGVsc2UgYWR2ZXJ0aXNlcyB3aGF0IGlzIGF2YWlsYWJs ZSB0byB0aGUgY2xpZW50IGFuZCBjbGllbnQgZmV0Y2hlcyB3aGF0ZXZlciBpdA0KPiB3YW50cw0K PiA+ID4gKGFuZCBpcyBhdmFpbGFibGUpLiBXaHkgaXMgdGhlcmUgYSBuZWVkIGZvciBzeW5jaHJv bml6YXRpb24gaGVyZT8NCj4gPiA+DQo+ID4gPiBbUWluXTogV2UgbWF5IGxvb2sgYXQgdHdvIGRp ZmZlcmVudCAgdXNlIGNhc2VzOiBwdXNoIG1vZGVsIGFuZCBwdWxsIG1vZGVsDQo+ID4gPiBJbiB0 aGUgcHVsbCBtb2RlbCwgeW91IGFyZSByaWdodC4gVGhlIGNsaWVudCAgY29udHJvbCB0aGUgdGlt aW5nIG9mIGZldGNoaW5nIHRoZSBjaHVua3MgYnkgZHJpdmluZyB0aGUgSFRUUCByZXF1ZXN0LiBJ dCBvbmx5DQo+ID4gPiByZXF1ZXN0IGl0IG5lZWRzIGFuZCBjYW4gaGFuZGxlLiBIb3dldmVyICBj bGllbnQgYmFzZWQgcHVsbCBpcyBjaGFyYWN0ZXJpemVkDQo+ID4gPiBhcyBwb2xsaW5nIGZvciBu ZXcgZGF0YSBlYWNoIHRpbWUgYW5kIGlzIG5vdCBlZmZpY2llbnQgd2F5IHRvIGRlbGl2ZXIgdGhl IHJlYWwgdGltZSBzdHJlYW1pbmcgY29udGVudHMuDQo+ID4NCj4gPiBCeSBwb2xsaW5nIEkgc3Vw cG9zZSB5b3UgbWVhbiBzZW5kaW5nIEhUVFAgcmVxdWVzdHMuIFdlbGwsIHRoYXQgaXMgcHJldHR5 IG11Y2ggaW1wbGllZCBieSB1c2luZyBIVFRQLCB3aGljaCBpcyBhIHJlcXVlc3QtDQo+ID4gcmVz cG9uc2UgcHJvdG9jb2wgYW5kIHRoaXMgbWFrZXMgSFRUUCBhcyBzdGF0ZWxlc3MgYXMgcG9zc2li bGUuIEFuZCBJTU8gc2VuZGluZyBpbmRpdmlkdWFsIHJlcXVlc3RzIG9mZmVyIG1vcmUNCj4gYWR2 YW50YWdlcw0KPiA+IHRoYW4gZGlzYWR2YW50YWdlcy4NCj4gPg0KPiA+IFtRaW5dOiBTdXBwb3Nl IHRlbiBjaHVua3MgYXJlIGF2YWlsYWJsZSBhdCB0aGUgc2VydmVyLCB0aGUgY2xpZW50IGluIHB1 bGwgbW9kZWwgTVVTVCBzZW5kIHRlbiByZXF1ZXN0cyB0byBmZXRjaCBhbGwgdGhlDQo+IGNodW5r cw0KPiA+IGFuZCBzZXJ2ZXIgc2hvdWxkIGFuc3dlciB3aXRoIHRlbiByZXNwb25zZSB3aXRoIGVh Y2ggY2h1bmsuDQo+ID4gaG93ZXZlciBpbiB0aGUgcHVzaCBtb2RlbCwgSSB0aGluayB0aGUgY2xp ZW50IG9ubHkgbmVlZCB0byBpbml0aWF0ZSBvbmUgcmVxdWVzdCBhbmQgdGhlbiB0aGUgc2VydmVy IGNvbnRyb2wgdGVuIGNodW5rcw0KPiBkZWxpdmVyeQ0KPiA+IGFuZCBwdXNoIHRlbiBjaHVua3Mg dG8gdGhlIGNsaWVudCBvbmUgYnkgb25lLg0KPiA+ICBJc24ndCB0aGUgcHVzaCBtb2RlbCBtb3Jl IGVmZmljaWVudCB0aGFuIHB1bGwgbW9kZWwgZnJvbSB0cmFuc3BvcnQgcGVyc3BlY3RpdmU/DQo+ IA0KPiBEZXBlbmRzLiBKdXN0IGJlY2F1c2UgaW4gdGhlIHB1c2ggbW9kZWwgdGhlcmUgYXJlIGxl c3MgcmVxdWVzdCBtZXNzYWdlcywgaXQgZG9lcyBub3QgbWVhbiBpdCBpcyBtb3JlIGVmZmljaWVu dC4gVGhhdCB3b3VsZA0KPiBiZSBhIGJhZCBkZWZpbml0aW9uIGZvciBlZmZpY2llbmN5LiBUaGUg cHVsbCBtb2RlbCBicmluZ3MgbWFueSBhZHZhbnRhZ2VzIHRoYXQgdGhlIHB1c2ggbW9kZWwgY2Fu bm90IG9mZmVyIChhdCB0aGUgc2FtZQ0KPiBmbGV4aWJpbGl0eSkuIEkgYW0gbm90IHNheWluZyBv bmUgaXMgYmV0dGVyIHRoYW4gdGhlIG90aGVyLCBidXQgeW91ciBzY29wZSBmb3IgZGV0ZXJtaW5p bmcgZWZmaWNpZW5jeSBpcyByYXRoZXIgbGltaXRlZC4NCj4gDQo+IFtRaW5dOiBPa2F5LiBCdXQg SWYgeW91IGxvb2sgYXQgd2Vic29ja2V0IHByb3RvY29sIGFzIHB1c2ggbW9kZWwsIHByb2JhYmx5 IHlvdSB3aWxsIGZpbmQgdGhleSBjYW4gYmUgdXNlZCBhY2NlbGVyYXRlIGJyb3dzZXINCj4gYW5k IGltcHJvdmUgZWZmaWNpZW5jeS4NCg0KQnV0LCBpbiBodHRwIHN0cmVhbWluZyBzY2VuYXJpbywg dGhlIHJhdGlvIG9mIGRvd25sb2FkL3VwbG9hZCAoZnJvbSB0aGUgY2xpZW50J3MgcGVyc3BlY3Rp dmUpIGlzIG11Y2ggbGFyZ2VyIHRoYW4gMS4gQlRXLCBpZiB5b3Uga2VlcCB5b3VyIGNodW5rIGR1 cmF0aW9uIHJlbGF0aXZlbHkgbG9uZ2VyLCB0aGUgYW1vdW50IG9mIHJlcXVlc3RzIHRoYXQgeW91 IHdpbGwgZW5kIHVwIHNlbmRpbmcgd2lsbCBiZSBhbG1vc3QgbmlsIGNvbXBhcmVkIHRvIHdoYXQg eW91IHdpbGwgcmVjZWl2ZS4NCg0KW1Fpbl06IE5vLCBJIGp1c3QgY29tcGFyZSBwdWxsIGFuZCBw dXNoIHdpdGggdGhlIHNhbWUgY2h1bmsgZHVyYXRpb24uIA0KIA0KPiA+ID4gSW4gdGhlIHB1c2gg bW9kZWwsIHRoZSBjbGllbnQgZG9lcyBub3Qga25vdyB3aGVuIHRoZSBjb25lbnRzIGlzIGF2YWls YWJsZSBhdCB0aGUgc2VydmVyLiBGb3IgdGhlIGNsaWVudCB3aWxsIG5vdCBzZW5kDQo+IHJlcXVl c3QNCj4gPiA+IGZvciBlYWNoIGNodW5rcy4gdGhlIGNsaWVudCBjbG9jayBpcyBlYXN5IHRvIGFz eW5jaHJvbml6ZSB3aXRoIGVuY29kZXIgY2xvY2suDQo+ID4NCj4gPiBXZWxsIHRoZSBzZXJ2ZXIg Y2FuIHB1c2ggdGhlIGNvbnRlbnQgKGluIGEgcHVzaCBtb2RlbCkgYnV0IGl0IHN0aWxsIGlzIGRl cGVuZGVudCBvbiB0aGUgY2xpZW50IGltcGxlbWVudGF0aW9uIHRvIGRldGVybWluZQ0KPiA+IHdo YXQgdG8gZG8gd2l0aCB0aGF0IGNvbnRlbnQuIE9uZSBpbXBsZW1lbnRhdGlvbiwgaWYgaXQgd2Fu dHMsIGNhbiBzdGFydCBwbGF5aW5nIGl0IDEwIGhvdXJzIGxhdGVyIGZvciBhbGwgd2UgY2FyZS4g SSBzdGlsbCBkb24ndA0KPiA+IGdldCB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIGRvIGhlcmUuDQo+ ID4NCj4gPiBbUWluXTogSW4gdGhlIHB1c2ggbW9kZWwsIHRoZSBzZXJ2ZXIgZGlkbid0IGtub3cg dGhlIGNsaWVudCBjYXBhYmlsaXR5IHRvIGNvbnN1bWUgc3RyZWFtaW5nIGRhdGEsIGkuZS4sIHRo ZSBzZXJ2ZXIgZGlkbid0DQo+IGtub3cNCj4gPiBob3cgZmFzdCB0aGUgY2xpZW50IHByb2Nlc3Mg bGl2ZSBzdHJlYW1pbmcuIElmIHRoZSBlbmNvZGluZyByYXRlIGF0IHRoZSBzZXJ2ZXIgaXMgZmFz dGVyIHRoYW4gY29tc3VpbmcgcmF0ZSBhdCB0aGUgY2xpZW50LCB0aGUNCj4gPiBidWZmZXIgd2ls bCBvdmVyZmxvdy4gSWYgdGhlIGVuY29kaW5nIHJhdGUgYXQgdGhlIHNlcnZlciBpcyBzbG93ZXIg dGhhbiBjb21zdWluZyByYXRlIGF0IHRoZSBjbGllbnQsIHRoZSBidWZmZXIgd2lsbCB1bmRlcmZs b3cuDQo+IA0KPiBGb3IgYm90aCBvbi1kZW1hbmQgYW5kIGxpdmUgc3RyZWFtaW5nLCB0aGUgZW5j b2RpbmcgcmF0ZSBpcyBzdXBwb3NlZCB0byBiZSBlcXVhbCB0byBjb25zdW1wdGlvbiByYXRlICh3 aGljaCBzb3VuZHMgdG8gbWUNCj4gYXMgdGhlIHJhdGUgdGhlIGRlY29kZXIgaXMgY29uc3VtaW5n KS4gV2hhdCB5b3UgYXJlIHJlZmVycmluZyB0byBhcyBidWZmZXIgb3ZlcmZsb3cgb3IgdW5kZXJm bG93IGlzIHJlbGF0ZWQgdG8gc3RyZWFtaW5nIG9yDQo+IHRyYW5zbWlzc2lvbiByYXRlLiBPbiB0 aGUgbG9uZy10ZXJtIGF2ZXJhZ2UsIGFsbCB0aGVzZSBuZWVkIHRvIGJlIGVxdWFsIGFueXdheS4N Cj4gDQo+IFtRaW5dOiBCdXQgSG93LCBpcyB0aGVyZSBhbnkgd2F5IHRvIGRvIHRoaXM/IG9yIHRo ZXkganVzdCB3YWl0IGZvciByZWJ1ZmZlcmluZyBhbmQgdGhlbiByZWNvdmVyIGJ5IGl0c2VsZi4N Cj4NCj4gQnV0LCBJIHdpbGwganVzdCByZXBlYXQgbXlzZWxmLiBOZWl0aGVyIGhhcyBhbnl0aGlu ZyB0byBkbyB3aXRoIGNsb2NrIHN5bmNocm9uaXphdGlvbiBiZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5k IGNsaWVudC4NCj4gDQo+IFtRaW5dOiBPa2F5Lg0KPiANCj4gVGhlIGNsaWVudCBjYW4gY2hvb3Nl IHRoZSBidWZmZXIgZHVyYXRpb24gYW5kIHRoZSBhY3R1YWwgcGxheWJhY2sgdGltZS4NCj4gDQo+ IFtRaW5dOiBTdXBwb3NlIHRoZSBjaHVua3MgaXMgbm90IHJlYWR5IGluIHRoZSBwbGF5b3V0IGJ1 ZmZlciBhdCB0aGUgY2xpZW50LCBkb2VzIGl0IG1lYW4gdGhhdCB0aGUgY2xpZW50IGp1c3Qgc2xv dyBkb3duIHBsYXliYWNrDQo+IHNwZWVkIGFuZCB3YWl0IGZvciBzdWJzZXF1ZW50IGNodW5rcyBp cyBhcnJpdmluZyBhdCB0aGUgcGxheWJhY2sgYnVmZmVyIGFuZCB0aGVuIGNsaWVudCByZXN1bWUg dGhlIG5vcm1hbA0KPiBwbGF5YmFjayBzcGVlZD8NCg0KU29ycnkgaWYgInBsYXliYWNrIHRpbWUi IG1lYW50IHRoZSBkdXJhdGlvbiBvZiB0aGUgcGxheWJhY2suIEkgcmF0aGVyIG1lYW50IHRoZSBz dGFydCB0aW1lIG9mIHRoZSBwbGF5YmFjay4gU28sIGlmIGEgY2xpZW50IGtlZXBzIGEgbGFyZ2Vy IGJ1ZmZlciBob3BpbmcgdGhhdCBpdCB3aWxsIGF2b2lkIGJ1ZmZlciB1bmRlcnJ1bnMsIHRoaXMg bWF5IGRlbGF5IHRoZSBwbGF5YmFjayBzdGFydCB0aW1lLiANCg0KW1Fpbl06IFJpZ2h0LiBTbyB3 ZSBuZWVkIHRvIGNob29zZSBhcHByb3BvcmlhdGUgYnVmZmVyIHNpemUgdG8gc2VlayBiYWxhbmNl IGJldHdlZW4gYnVmZmVyIHVuZGVyZmxvdyBhbmQgc3RhcnR1cCB0aW1lIGRlbGF5LiBUaGUgYnVm ZmVyIHNpemUgY2FuIGJlIGNoYW5nZWQgYXQgYW55IHRpbWUuDQoNCk9yLCB0aGUgY2xpZW50IGNh biBzdGFydCB0aGUgcGxheWJhY2sgcXVpY2tseSBhbmQgYnVpbGQgdGhlIGJ1ZmZlciBvdmVyIHRp bWUgYnkgcmVxdWVzdGluZyBsb3dlci1iaXRyYXRlIGNodW5rcy4NCg0KW1Fpbl06IEkgdGhpbmsg dGhlIHByZXN1bXB0aW9uIGlzIHRoZSBzZXJ2ZXIgc2hvdWxkIHByZXBhcmUgbXVsdGlwbGUgc3Ry ZWFtcyBvZiB0aGUgc2FtZSBjb250ZW50IHdpdGggZGlmZmVyZW50IGJpdHJhdGVzLiB0aGUgc2Vy dmVyIG1heSBoYXZlIGEgYmlnIGxvYWQgaWYgdGhlIGNvbnRlbnQgaXMgbGl2ZSBjb250ZW50cy4N Cg0KV2hldGhlciBpdCBwYWNlcyB0aGUgcHJlc2VudGF0aW9uIHNwZWVkIGRvd24gb3Igbm90IGlu IG9yZGVyIHRvIGF2b2lkIGJ1ZmZlciB1bmRlcnJ1bnMgaXMgc29tZXRoaW5nIHVwIHRvIHRoZSBj bGllbnQuIE1vc3QgaW1wbGVtZW50YXRpb25zIEkgaGF2ZSBzZWVuIHNpbXBseSBzd2l0Y2ggdG8g YSBsb3dlci1iaXRyYXRlIHByb2ZpbGUgd2VsbCBiZWZvcmUgdGhlIGJ1ZmZlciBpcyBmdWxseSBk cmFpbmVkLiBTbywgdGhleSBkb24ndCBleHBlcmllbmNlIGJ1ZmZlciB1bmRlcnJ1bnMgYW5kIHRo ZXkgZG9uknQgbmVlZCB0byBwYWNlIHRoZSB2aWRlbyBwcmVzZW50YXRpb24gc3BlZWQgZG93bi4N Cg0KW1Fpbl06IEkgZG9uJ3QgZG91YnQgZ2l2aW5nIG1vcmUgY29udHJvbCB0byBjbGllbnQgaGFz IGl0cyBhZHZhbnRhZ2VzLiBCdXQgSSB0aGluayBnaXZpbmcgc29tZSBjb250cm9sIHRvIHRoZSBz ZXJ2ZXIgYWxzbyBoYXMgaXRzIGFkdmFudGFnZS4gZS5nLiwgIHlvdSBtYXkgbm90IG5lZWQgdG8g cHJlcGFyZSBtdWx0aXBsZSBzdHJlYW0gb2YgdGhlIHNhbWUgY29udGVudCB3aXRoIGRpZmZlcmVu dCBiaXRyYXRlLg0KdGhlIHNlcnZlciBjb250cm9sIHRoZSB0cmFuc21pc3Npb24gcmF0ZSBiYXNl ZCBvbiB0aGUgbmV0d29yayBjb25kaXRpb24gYW5kIGNsaWVudCByZXF1aXJlbWVudHMuDQoNCi1h Y2JlZ2VuDQo= From sunseawq@huawei.com Thu Oct 14 20:21:16 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F9F3A6A82 for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 20:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.014 X-Spam-Level: * X-Spam-Status: No, score=1.014 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7oeeeXozTTX for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 20:21:13 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 391A83A6A11 for <httpstreaming@ietf.org>; Thu, 14 Oct 2010 20:21:13 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00MQVAPBOH@szxga05-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 11:22:23 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00HV7APARR@szxga05-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 11:22:22 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB0009MAP96B@szxml06-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 11:22:22 +0800 (CST) Date: Fri, 15 Oct 2010 11:22:21 +0800 From: Qin Wu <sunseawq@huawei.com> To: Mark Watson <watsonm@netflix.com> Message-id: <02e301cb6c18$2dda7ea0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_K+H0hZSVKhV3MGkfhXgeRA)" X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> <029d01cb693a$7f515f50$30298a0a@china.huawei.com> <9062141B-82B8-4FF0-98C2-EB803BCA3DD7@netflix.com> <03e201cb6b6a$db1ae770$30298a0a@china.huawei.com> <B9E38A06-8392-4CCF-9160-D55F43BD75D8@netflix.com> Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 03:21:16 -0000 This is a multi-part message in MIME format. --Boundary_(ID_K+H0hZSVKhV3MGkfhXgeRA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SSByZXNwZWN0IHlvdXIgb3Bpb25pb24gYWx0aG91Z2ggSSBjYW4ndCBhZ3JlZSB3aXRoIHlvdS4g SSB3b3VsZCBsaWtlIHRvIGhlYXIgd2hhdCBvdGhlciBwZW9wbGUgdGhpbmtzLiBUaGFua3MhDQog IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IE1hcmsgV2F0c29uIA0KICBU bzogUWluIFd1IA0KICBDYzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pIDsgaHR0cHN0cmVhbWluZ0Bp ZXRmLm9yZyA7IENvbGluIFBlcmtpbnMgDQogIFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNSwgMjAx MCAxMjoyNiBBTQ0KICBTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQgU3RhdHVz IGFuZCBPdXIgR29hbA0KDQoNCg0KDQogIE9uIE9jdCAxNCwgMjAxMCwgYXQgMjo0MSBQTSwgUWlu IFd1IHdyb3RlOg0KDQoNCiAgICBIaSwNCiAgICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCiAgICAgIEZyb206IE1hcmsgV2F0c29uDQogICAgICBUbzogUWluIFd1DQogICAgICBDYzog QWxpIEMuIEJlZ2VuIChhYmVnZW4pIDsgaHR0cHN0cmVhbWluZ0BpZXRmLm9yZyA7IENvbGluIFBl cmtpbnMNCiAgICAgIFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTIsIDIwMTAgMTI6NTAgQU0NCiAg ICAgIFN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10gQ3VycmVudCBTdGF0dXMgYW5kIE91ciBH b2FsDQoNCg0KICAgICAgU29tZSBjb21tZW50cyBvbmxpbmUgLi4uDQoNCiAgICAgIFNlbnQgZnJv bSBteSBpUGhvbmUNCg0KICAgICAgT24gT2N0IDExLCAyMDEwLCBhdCA3OjUwIFBNLCAiUWluIFd1 IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCg0KICAgICAgICBIaSwNCiAgICAgICAg VGhpcyBpcyB3aGF0IHdlIGhhZCBkaXNjdXNzZWQgIGluIHRoZSBESVNQQVRDSCBtYWlsaW5nIGxp c3QgYmVmb3JlIHdlIG1vdmUgdG8gdGhpcyBkaXNjdXNzIGxpc3QuDQogICAgICAgIElmIHlvdSBs b29rIGF0IHRoZSBkZXNjcmlwdGlvbiBvZiBkaXNjdXNzIGxpc3QsICINCiAgICAgICAgb2ZmZXJz IG1vcmUgZWZmaWNpZW50IHRyYW5zcG9ydCANCiAgICAgICAgYW5kIGJldHRlciBuZXR3b3JrIGNh cGFiaWxpdHkgZm9yIHJlYWwgdGltZSBzdHJlYW1pbmcgbWVkaWENCiAgICAgICAgYW5kIGFsbG93 cyBpbnRlcm9wZXJhYmlsaXR5IHdpdGggb3RoZXIgc3RyZWFtaW5nIHRlY2huaXF1ZXMgYW5kIGV4 aXN0aW5nIFByb2dyZXNzaXZlIGRvd2xvYWRlZCBiYXNlZA0KICAgICAgICBIVFRQIHN0cmVhbWlu ZyBpbXBsZW1lbnRhdGlvbi4NCiAgICAgICAgIg0KICAgICAgICB5b3Ugd2lsbCBzZWUgd2UgYXJl IG9uIHRoZSBzYW1lIHBhZ2UuDQogICAgICAgIFRoZXJlZm9yZSBvbmUgaW1wb3J0YW50IGdvYWwg ZGlzY3Vzc2VkIGluIHRoZSBkcmFmdCBhaW1zIGF0IGRldmVsb3BpbmcgaW50ZXJvcGVyYWJsZSBz b2x1dGlvbiB0bw0KICAgICAgICBwcm92aWRlIGJldHRlciB0cmFuc3BvcnQgdG8gc2F0aXNmeSB0 aGUgcmVhbCB0aW1lIHN0cmVhbWluZyBRT0UgcmVxdWlyZW1lbnQuIEVzcGVjaWFsbHkgc2VydmVy YWwNCiAgICAgICAgY2hhbmxsZW5nZXMvcHJvYmxlbXMgd2UgZXhwbG9yZWQgaW4gdGhlIGRyYWZ0 IGxpc3RlZCBiZWxvdy4NCg0KICAgICAgICBSZWdhcmRzIQ0KICAgICAgICAtUWluDQogICAgICAg ICAgLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KICAgICAgICAgIEZyb206IE1hcmsgV2F0 c29uDQogICAgICAgICAgVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKQ0KICAgICAgICAgIENjOiBo dHRwc3RyZWFtaW5nQGlldGYub3JnIDsgQ29saW4gUGVya2lucw0KICAgICAgICAgIFNlbnQ6IFN1 bmRheSwgT2N0b2JlciAxMCwgMjAxMCA3OjEzIEFNDQogICAgICAgICAgU3ViamVjdDogUmU6IFto dHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KDQogICAgICAgICAg QWxsLA0KDQoNCiAgICAgICAgICBJIHdvdWxkIGxpa2UgdG8gYWRkIG15IHN1cHBvcnQgdG8gdGhl IGNvbW1lbnRzIGJlbG93LiBTcGVjaWZpY2FsbHksIEkgdGhpbmsgaWYgdGhlIElFVEYgY29uc2lk ZXJzIHdvcmsgaW4gdGhpcyBhcmVhIGl0IHNob3VsZCBmb2N1cyBvbiB0aGUgSFRUUCBhbmQgVENQ IHByb3RvY29scy4gQW55IHN1Y2ggd29yayBtYXkgbm90IGJlIHNwZWNpZmljIHRvIEhUVFAtc3Ry ZWFtaW5nIChpLmUuIGVuaGFuY2VtZW50cyB0aGF0IGFyZSBhdCBmaXJzdCBtb3RpdmF0ZWQgYnkg SFRUUCBTdHJlYW1pbmcgbWF5IGhhdmUgYnJvYWRlciBhcHBsaWNhYmlsaXR5LCBhbmQgdGhpcyBz aG91bGQgYmUgY2FyZWZ1bGx5IGNvbnNpZGVyZWQpLg0KDQoNCiAgICAgICAgICBJbiB0aGUgZHJh ZnQgSSBkbyBub3Qgc2VlIGEgY2xlYXIgb3IgY29ycmVjdCBpZGVudGlmaWNhdGlvbiBvZiB0aGUg cHJvYmxlbXMuIEZvciBleGFtcGxlIGluIHRoZSBpbnRyb2R1Y3Rpb24gdGhlIGZvbGxvd2luZyBh cmUgc3RhdGVkIGFzIGlzc3VlczoNCiAgIC0gQ2xpZW50IHBvbGxpbmcgZm9yIGVhY2ggbmV3IGRh dGEgaW4gY2h1bmtzIHVzaW5nIEhUVFAgcmVxdWVzdHMgaXMNCiAgIG5vdCBlZmZpY2llbnQgdG8g ZGVsaXZlciBoaWdoLXF1YWxpdHkgdmlkZW8gY29udGVudCBhY3Jvc3MgdGhlDQogICBJbnRlcm5l dE1XOiBTZXZlcmFsIGNvbXBhbmllcywgaW5jbHVkaW5nIG15IGVtcGxveWVyLCBhcmUgc3VjY2Vz c2Z1bGx5IG9wZXJhdGluZyBsYXJnZSBzY2FsZSBIVFRQIHN0cmVhbWluZyBzeXN0ZW1zIHRoYXQg ZG8gZWZmaWNpZW50bHkgZGVsaXZlciBoaWdoLXF1YWxpdHkgdmlkZW8gY29udGVudCBhY3Jvc3Mg dGhlIEludGVybmV0LCBzbyByZWFsaXR5IHNlZW1zIHRvIHJlZnV0ZSB0aGlzIHN0YXRlbWVudC5b UWluXTogTm90IHN1cmUgdGhleSBjYW4gcHJvdmlkZSB0aGUgVFYgZXhwZXJpZW5jZSBmb3IgYWxs IHRoZSBjb25uZWN0ZWQgZGV2aWNlcyBsaWtlIHNtYXJ0cGhvbmVzLCBQQ3MgYW5kIHRhYmxldHMu IEFsc28gbm90IHN1cmUgdGhleSBjYW4gcHJvdmlkZSB0aGUgc2FtZSBxdWFsaXR5IG9mIGV4cGVy ZW5jZSBmb3IgYWxsIHRoZSBhbGwgdGhlIGNvbm5lY3RlZCBkZXZpY2VzLiBBcyB3ZSBkaXNjdXNz ZWQgaW4gdGhpcyB0aHJlYWQsIGEgbWluaW11bSBvZiAyMCBzZWNvbmRzIHRvIHN0YXJ0IHlvdXIg dmlkZW8gb2Z0ZW4gZnJ1c3RyYXRlZCB1c2VycyB0byBrZWVwIG9uIHdhdGNoaW5nIGFuZCBwcm92 aWRlIHZlcnkgbGltaXRlZCB1c2VyIGV4cGVyaWVuY2UuQ2FuIHlvdSBiZSBtb3JlIGV4cGxpY2l0 IGFib3V0IHRoZSBwcm9ibGVtcyB0aGF0IHlvdSBzZWU/IEknbSBub3Qgc3VyZSB3aGVyZSB0aGUg MjBzIGZpZ3VyZSBjb21lcyBmcm9tLiBJIGRvIG5vdCBzZWUgYW55IHByb2JsZW0gaW4gc3VwcG9y dGluZyBzdGFydHVwIHRpbWVzIGNvbXBhcmFibGUgdG8gVFYgY2hhbm5lbCBjaGFuZ2Ugd2l0aCBh ZGFwdGl2ZSBIVFRQIHN0cmVhbWluZy4NCg0KDQogICAgICBJIGFtIG5vdCBzYXlpbmcgdGhlcmUg aXMgbm8gcm9vbSBmb3IgaW1wcm92ZW1lbnQgaW4gdGhlIHZhcmlvdXMgZGVwbG95ZWQgc3lzdGVt cywgYnV0IEkgZG8gbm90IHNlZSBtYWpvciB0ZWNobmljYWwgaW1wZWRpbWVudHMgdG8gZWZmaWNp ZW50IGRlbGl2ZXJ5IG9mIGhpZ2ggcXVhbGl0eSB2aWRlbyB1c2luZyBIVFRQIFN0cmVhbWluZy4N Cg0KICAgICAgW1Fpbl06Tm90IG9ubHkgc3RhcnVwIGxhdGVuY3kgYnV0IGFsc28gZGVsYXkgdy5y LnQuIHJlYWwgdGltZSBzdHJlYW1pbmcuIEkgdGhpbmsgeW91IG5lZ2VjdCBpdCBiZWNvcyBZb3Ug ZGlkbid0IGdldCBpbnRvIHRoZSBkaXNjdXNzaW9uIGxpc3QuIA0KDQpPbiB0aGUgb3RoZXIgaGFu ZCwgSSB0aGluayB3ZSBzaG91bGQgYmVhciBpbiBtaW5kIEhUVFAgaXMgZm9ybWVybHkgZGVzaWdu ZWQgZm9yIGJyb3dzaW5nIHdlYnBhZ2UsIHRyYW5zcG9ydCBzdGF0aWMgY29udGVudHMgbGlrZSBI VE1MIHBhZ2UsIHBsdWdpbiwgcGljdHVyZSwgd2hlbiB3ZSBhcmUgZ29pbmcgdG8gdXNlIEhUVFAg dG8gZGVsaXZlciByZWFsIHRpbWUgc3RyZWFtaW5nIGNvbnRlbnRzLCB3ZSBjYW4gbm90IGV4cGVj dCB0byBnZXQgaGlnaGVyIHVzZXIgZXhwZXJpZW5jZS4gVGhlcmVmb3JlIHRoZSBjdXJyZW50IHN0 cmVhbWluZyBzY2hlbWVzIGNhbiBvbmx5IG9mZmVyIGEgYmV0dGVyIGV4cGVyaWVuY2Ugb3ZlciBz bG93ZXIgY29ubmVjdGlvbnMuICAgLSBTZWdtZW50YXRpb24gY2FwYWJpbGl0eSByZXF1aXJlcyBv dmVyLXV0aWxpemluZyBDUFUgYW5kIGJhbmR3aWR0aA0KICAgcmVzb3VyY2VzLCB3aGljaCBtYXkg bm90IGJlIGEgZGVzaXJhYmxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIGltcHJvdmUNCiAgIHRoZSBx dWFsaXR5IG9mIHN0cmVhbWluZyBtZWRpYSBkZWxpdmVyeU1XOiBJdCBpcyBub3QgY2xlYXIgdGhh dCBzZWdtZW50YXRpb24gcGVyIHNlIGlzIENQVS1pbnRlbnNpdmUgb3IgaGFzIGFueSBub24tbmVn bGlnYWJsZSBlZmZlY3Qgb24gYmFuZHdpZHRoIHVzYWdlLltRaW5dOiBTaW5jZSBIVFRQIHN0cmVh bWluZyBzZXJ2ZXIgaXMgdGhlIGNvbWJpbmF0aW9uIG9mIHN0cmVhbWluZyBzZXJ2ZXIgYW5kIHJl Z3VsYXIgd2ViIHNlcnZlciwgSSB0aGluayB0aGUgYW5zd2VyIGlzIGJvdGguDQoNCiAgICAgIFtN V10gd2hhdCBkbyB5b3UgbWVhbiBieScgaHR0cCBzdHJlYW1pbmcgc2VydmVyJyA/DQoNCiAgICAg IFtRaW5dOiBXaXRoIHN0cmVhbWluZyBjYXBhYmlsaXR5IGFuZCBmdW5jdGlvbmFsaXR5IHRvIHJl c3BvbmQgdG8gSFRUUCBjb25uZWN0aW9uLg0KDQoNCg0KICBbTVddIEknbSBub3Qgc3VyZSB3aGF0 IG9uZSBvZiB0aG9zZSBpcy4gSXQgc291bmRzIGxpa2UgaXQgaXMgbm90IGEgcmVndWxhciB3ZWIg c2VydmVyLiBJIHRoaW5rIGl0J3MgYW4gZXNzZW50aWFsIGZlYXR1cmUgb2YgbW9kZXJuIEhUVFAg c3RyZWFtaW5nIHRoYXQgaXQgd29ya3Mgd2l0aCByZWd1bGFyIHdlYiBpbmZyYXN0cnVjdHVyZS4N Cg0KDQogICAtIExhY2sgb2YgUW9TIGd1YXJhbnRlZSBvbiB0aGUgcGFja2V0IHN3aXRjaGluZyBi YXNlZCBJbnRlcm5ldCAsIHRoZQ0KICAgcXVhbGl0eSBvZiBJbnRlcm5ldCBtZWRpYSBzdHJlYW1p bmcgbWF5IHNpZ25pZmljYW50IGRlZ3JhZGUgZHVlIHRvDQogICByaXNpbmcgdXNhZ2VNVzogQW4g YWx0ZXJuYXRpdmUgdmlldyBpcyB0aGF0IHdoZXJlIHF1YWxpdHkgaXMgZGVncmFkZWQgZHVlIHRv IGNvbmdlc3Rpb24gdGhpcyBpcyBkdWUgdG8gbGFjayBvZiBiYW5kd2lkdGgsIHJhdGhlciB0aGFu IGEgbGFjayBvZiBRb1MgZ3VhcmFudGVlcy4gQWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgc3lzdGVt cyBhZGp1c3QgdGhlIHZpZGVvIHF1YWxpdHkgdG8gdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggaW4g b3JkZXIgdG8gYXZvaWQgcmVidWZmZXJpbmcgZXZlbnRzLiBJdCBpcyB0aGUgYXZhaWxhYmxlIGJh bmR3aWR0aCB0aGF0IG5lZWRzIHRvIGJlIGltcHJvdmVkIHRvIGltcHJvdmUgcXVhbGl0eS5bUWlu XTogV2hhdCBJIGVtcGhhc2l6ZSBoZXJlIGlzIHdpdGggZ3Jvd2luZyBwb3B1bGFyaXR5IG9mIEhU VFAgc3RyZWFtaW5nIHRyYWZmaWMsIHdoZW4gdGhvdXNhbmRzIG9yIG1pbGxpb25zIG9mIHBlb3Bs ZSBhcmUgYWNjZXNzaW5nIHRoZSBzYW1lIG1lZGlhIGNvbnRlbnRzLCB0aGUgYmlnIHByb2JsZW0g d2UgYXJlIGZhY2luZyBpcyBzZXJpb3VzIGhpZ2ggY29uY3VycmVuY2UgYWNjZXNzIGlzc3VlLiBU aGUgdXNlciBleHBlcmllbmNlIHdpbGwgYmUgZ3JlYXRseSBhZmZlY3RlZCBldmVuIHlvdSBoYXZl IGVub3VnaCBhdmFpbGFibGUgYmFuZHdpZHRoLiBTbyB0aGlzIGlzIG5vdCBwdXJlIGJhbmR3aWR0 aCBpc3N1ZS4NCg0KICAgICAgW01XXSBtYXliZSB3ZSBtZWFuIGRpZmZlcmVudCB0aGluZ3MgYnkg J2F2YWlsYWJsZSBiYW5kd2lkdGgnLiBEbyB5b3UgdGhpbmsgaXQgaXMgYSBzZXJ2ZXIgc2NhbGFi aWxpdHkgcHJvYmxlbSwgb3IgYSBuZXR3b3JrIHByb2JsZW0gPw0KDQogICAgICBbUWluXTogcGxl YXNlIHJlYWQgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2h0dHBzdHJlYW1p bmcvY3VycmVudC9tc2cwMDAxMS5odG1sDQoNCg0KDQogIFtNV10gU3RpbGwgbm90IHN1cmUgd2hh dCB5b3UncmUgcmVmZXJyaW5nIHRvIG90aGVyIHRoYW4gYXZhaWxhYmxlIGJhbmR3aWR0aC4gVGhl IHRocmVhZCBtZW50aW9ucyBtdWx0aWNhc3QgLSBkbyB5b3UgdGhpbmsgdGhlcmUgcmVtYWlucyB3 b3JrIHRvIGRlbGl2ZXIgSFRUUCBvYmplY3RzIG92ZXIgbXVsdGljYXN0IGdpdmVuIHRoZSB3b3Jr IGluIFJNVCBvdmVyIHRoZSB5ZWFycyA/DQoNCg0KICAgLSBFeHBlcmllbmNlIGJ1cnN0aW5lc3Mg b3Igb3RoZXIgZHluYW1pY3MgY2hhbmdlcyBkdWUgdG8gYmFuZHdpZHRoDQogICBmbHVjdHVhdGlv bnMgYW5kIGhldGVyb2dlbmVvdXMgaGFuZG92ZXIuTVc6IFdlIGhhdmUgZm91bmQgdGhhdCBhZGFw dGl2ZSBIVFRQIHN0cmVhbWluZyBhbGdvcml0aG1zIGFyZSB3ZWxsIGFibGUgdG8gY29wZSB3aXRo IGJhbmR3aWR0aCBmbHVjdHVhdGlvbnMuIFtRaW5dOiBJIGRvbid0IGRvdWJ0IHRoYXQgYWRhcHRp dmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBjYW4gY29wZSB3aXRoIGJhbmR3aWR0aCBmbHVj dGF0aW9uLiBCdXQgSSBob3BlIHdlIGNhbiBkbyBiZXR0ZXIuZS5nLiwgYWRhcHRpdmUgSFRUUCBz dHJlYW1pbmcgYWxnb3JpdGhtcyBvbmx5IHN1cHBvcnQgZGVsaXZlcnkgb2YgbXVsdGlwbGUgc3Ry ZWFtcyBvZiB0aGUgc2FtZSBjb250ZW50IHdpdGggdmFyeWluZyBxdWFsaXR5IGxldmVscyBmb3Ig ZGlmZmVyZW50IGJhbmR3aWR0aCBvciBkZXZpY2VzLiBIb3dldmUgaG93IHRoZSBzZXJ2ZXIgaW4g cHVzaCBtb2RlbCBvciBjbGllbnQgaW4gcHVsbCBtb2RlbCBjYW4gcXVpY2sgcmVzcG9uc2UgdG8g dGhlIGJpdHJhdGUgY2hhbmdlcyBpcyBhIHByb2JsZW0gd2UgbWF5IGxvb2sgYXQsZXNwZWNpYWxs eSB3aGVuIHN3aXRjaGluZyBiZXdlZW4gc3RyZWFtcyBvY2N1cnMgdmVyeSBmcmVxdWVudGx5Lg0K DQogICAgICBbTVddIFllcywgYnV0IG5vdCBhIHByb2JsZW0gZm9yIHRoZSBJRVRGLCBJIHRoaW5r Lg0KDQogICAgICBbUWluXTogSSBkaWRuJ3QgZ2V0IHdoYXQgeW91IHNhaWQuIGFkYXB0aXZlIEhU VFAgc3RyZWFtaW5nIGFsZ29yaXRobXMgaXMgY2hhcmFjdGVyaXplZCBhcyAgY2xpZW50IGluaXRp YXRlZCBwdWxsIG1vZGVsLiBXZSBhcmUgZGlzY3Vzc2luZyBwdXNoIG1vZGVsIG9yIGhvdyB0byB1 c2UgcHVsbCBtb2RlbCB3aXRoIHB1c2ggbW9kZWwuV2UgYXJlIHRhbGtpbmcgYWJvdXQgZGlmZmVy ZW50IG1vZGVsLiBUaGVyZSBhcmUgcGxlbnR5IHJvb20gZm9yIElFVEYgdG8gZG8gZm9yIHRoaXMu DQoNCg0KDQogIFtNV10gU29ycnksIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHRoZSAicHVzaCIg bW9kZWwgaGFzIHRvIGRvIHdpdGggSFRUUCBTdHJlYW1pbmcuIEFyZSB5b3UgdGFsa2luZyBhYm91 dCBzZXJ2ZXJzIHdoaWNoIGFyZSBub3QgcmVndWxhciBIVFRQIHNlcnZlcnMgPyBJIHRoaW5rIHRo aXMgaXMgbm90IHdoYXQgcGVvcGxlIHVzdWFsbHkgbWVhbiB3aGVuIHRoZXkgc2F5ICJIVFRQIHN0 cmVhbWluZyIgLSB5b3Ugc2hvdWxkIHJlbmFtZSB0aGUgd29yayBpZiB0aGF0IGlzIHRoZSBjYXNl Lg0KDQogICAtIEltcG9zc2libGUgdG8gZmFzdC1mb3J3YXJkIHRocm91Z2ggYW55IHBhcnQgb2Yg YSBzdHJlYW1pbmcNCiAgIGNvbnRlbnRzIHVudGlsIGl0IGlzIHN0b3JlZCBvbiB0aGUgdXNlcidz IGRldmljZU1XOiBUaGlzIGlzIHNpbXBseSBub3QgY29ycmVjdCwgc2luY2UgdGhlcmUgYXJlIGh1 bmRyZWRzIG9mIGV4YW1wbGVzIG9mIGRldmljZXMgd2hpY2ggc3VwcG9ydCB0cmljay1wbGF5IHVz aW5nIEhUVFAgc3RyZWFtaW5nIHRlY2huaXF1ZXMgd2l0aG91dCBzdG9yaW5nIHRoZSB3aG9sZSBj b250ZW50IG9uIHRoZSB1c2VycyBkZXZpY2UuW1Fpbl06IEZhc3QgZm9yd2FyZCBjYXBhYmlsdHkg aXMgbm90IHRoZSBtb3N0IGltcG9ydGFudCBmZWF0dXJlIHdlIGFyZSBsb29raW5nIGZvci4gSG93 ZXZlciBJIGFtIGhhcmQgdG8gYmVsaWV2ZSBleGlzdGluZyBIVFRQIHN0cmVhbWluZyB0ZWNobmlx dWVzIGNhbiBwcm92aWRlIHRoZSBzYW1lIGRlZ3JlZSBvZiBwbGF5YmFja2NvbnRyb2wgdGhhdCBE VkQgcGxheWVyIGNhbiBwcm92aWRlcyBvciBSVFNQIHByb3RvY29sIHByb3ZpZGVzLiBFLmcuLCBJ biB0aGUgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcywgdGhlIHRyaWNrIHBsYXkg aXMgbGltaXRlZCB0byBwYXVzZS9yZXN1bWUvc3RvcCBieSBkcml2aW5nIHRoZSBIVFRQIHJlcXVl c3QuIElmIHRoZSBjb250ZW50cyBoYXNuJ3QgYmVlbiBkb3dsb2FkZWQgYW5kIHRoZSBjb25zdW1l IHdhbnQgZmFzdCBmb3J3YXJkLCB0aGUgSFRUUCBjbGllbnQgbmVlZHMgdG8gaXNzdWUgYW5vdGhl ciBuZXcgSFRUUCByZXF1ZXN0IHRvIGZldGNoIHRoZSBjb250ZW50cyB3aGljaCB3aWxsY2F1c2Ug dW5hY2NlcHRhYmxlIGxhdGVuY3kgdG8gdGhlIGNvbnN1bWVyLltNV10gQWdhaW4sIHRoZSBleHBl cmllbmNlIG9mIG1pbGxpb25zIG9mIGV4aXN0aW5nIGN1c3RvbWVycyByZWZ1dGVzIHdoYXQgeW91 IGNsYWltLiBXaHkgZG8geW91IHRoaW5rIGl0IGlzIG5lY2Vzc2FyaWx5IHNvIHNsb3cgdG8gaXNz dWUgYSBuZXcgSFRUUCByZXF1ZXN0IGZvciBhIGRpZmZlcmVudCBwYXJ0IG9mIHRoZSBjb250ZW50 Pw0KDQogICAgICBbUWluXTogWW91IGRpZG4ndCBzZWUgdGhlIHJlYW9uIGJlaGluZCB0aGlzLCBi ZWNvcyB0aGUgZXhpc3RpbmcgY3VzdG9tZXJzIGhhcyBubyBjaG9pY2Ugd2hlbiB0aGV5IHZpZXcg bGl2ZSBzdHJlYW1pbmcsIHdoYXQgdGhleSBjYW4gZ2V0IGlzIGNsb3NlIHRvIGxpdmUgZXhwZXJp ZW5jZSByYXRoZXIgdGhhbiByZWFsIHRpbWUgdXNlciBleHBlcmllbmNlLiBPcGVyYXRvZXIgZG8g bm90aGluZyBmb3IgdGhlaXIgbmV0d29yayB0byBtYWtlIGh0dHAgc3RyZWFtaW5nIG1vcmUgY29u dHJvbGxhYmxlIGFuZCBtYW5hZ2FibGUuIFRoZXJlZm9yZSBtb3JlIGFuZCBtb3JlIGNvbnN1bWVy IHRlbmQgdG8gY2hvb3NlIG5vbi1saXZlIGNvbnRlbnQuIHRoYXQncyB3aHkgd2Ugc2VlIG1vcmUg YW5kIG1vcmUgbm9uLWxpdmUgY29udGVudCBjb25zdW1lcnMgcmF0aGVyIHRoYW4gbGl2ZSBjb250 ZW50cyBjb25zdW1lcnMuDQoNCg0KDQoNCiAgW01XXSBXZWxsLCBJJ20gbm90IHN1cmUgSSB1bmRl cnN0YW5kIHRoZSBwb2ludC4gQnV0IHN0aWxsIHRoZSBzdGF0ZW1lbnQgaW4gdGhlIGRyYWZ0IGlz IG5vdCB0cnVlLg0KDQoNCiAgLi4uTWFyaw0KDQoNCkEgZmlyc3Qgc3RlcCBpbiBjb25zaWRlcmlu ZyB3aGF0LCBpZiBhbnksIHdvcmsgc2hvdWxkIGJlIGRvbmUgaGVyZSBtaWdodCBiZSB0byBjb250 YWN0IHRob3NlIG9yZ2FuaXphdGlvbnMgd2hpY2ggYXJlIHN0YW5kYXJkaXppbmcgdGhlIGhpZ2hl ciBsYXllcnMgb2YgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyAoZS5nLiBtYW5pZmVzdCBhbmQgZmls ZSBmb3JtYXRzKSBhbmQgYXNrIHdoZXRoZXIgdGhlcmUgYXJlIGRlZmljaWVuY2llcyB0aGV5IHNl ZSBpbiBJRVRGIHByb3RvY29scyB0aGF0IGNvdWxkIGJlIHVzZWZ1bGx5IGFkZHJlc3NlZCBieSB0 aGUgSUVURi4gV2hhdCBJIHRoaW5rIHdlIHNob3VsZCBhdm9pZCBpbiB0aGUgSUVURiBpcyBkdXBs aWNhdGluZyB0aGUgd29yayBvZiB0aGVzZSBvdGhlciBib2RpZXMuQmVzdCxNYXJrIFdhdHNvbk5l dGZsaXggSW5jLg0KDQoNCg0KDQoNCiAgICAgICAgICBPbiBPY3QgMTAsIDIwMTAsIGF0IDEyOjQz IEFNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgd3JvdGU6DQoNCg0KDQoNCg0KICAgICAgICAgICAg ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQogICAgICAgICAgICAgIEZyb206IGh0dHBz dHJlYW1pbmctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh0dHBzdHJlYW1pbmctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIExhcnMgRWdnZXJ0DQoNCiAgICAgICAgICAgICAgU2VudDog RnJpZGF5LCBPY3RvYmVyIDA4LCAyMDEwIDQ6MTcgUE0NCg0KICAgICAgICAgICAgICBUbzogQ29s aW4gUGVya2lucw0KDQogICAgICAgICAgICAgIENjOiBodHRwc3RyZWFtaW5nQGlldGYub3JnDQoN CiAgICAgICAgICAgICAgU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1 cyBhbmQgT3VyIEdvYWwNCg0KDQoNCiAgICAgICAgICAgICAgT24gMjAxMC0xMC03LCBhdCAxNDox NiwgQ29saW4gUGVya2lucyB3cm90ZToNCg0KICAgICAgICAgICAgICAgIFRoZXJlIGFyZSBjbGVh cmx5IHNvbWUgaXNzdWVzIHRvIGNvbnNpZGVyIGhlcmUuIFdoYXQgc2VlbXMgdG8gYmUNCg0KICAg ICAgICAgICAgICAgIG1pc3NpbmcgZnJvbSB0aGUgZGlzY3Vzc2lvbiB0byBtZSB0aG91Z2gsIGlz IHNvbWUgaWRlbnRpZmljYXRpb24gb2YNCg0KICAgICAgICAgICAgICAgIHRoZSBjb25jcmV0ZSBw cm9ibGVtcy4gV2hhdCBwcm90b2NvbCBwaWVjZXMgZG8gd2UgbmVlZCwgYnV0IG5vdCBoYXZlPw0K DQogICAgICAgICAgICAgICAgV2hhdCBwcm90b2NvbHMgYXJlIHByb2JsZW1hdGljLCBhbmQgbmVl ZCBlbmhhbmNlbWVudD8gSXMgdGhlcmUNCg0KICAgICAgICAgICAgICAgIHByb3RvY29sIHdvcmsg dG8gZG8gaW4gSUVURiwgb3Igc2hvdWxkIHdlIGJlIGRvY3VtZW50aW5nIGJlc3QgY3VycmVudA0K DQogICAgICAgICAgICAgICAgcHJhY3RpY2VzIGZvciB1c2luZyB0aGUgZXhpc3RpbmcgcHJvdG9j b2xzIGFuZC9vciByZWx5aW5nIG9uIG90aGVyDQoNCiAgICAgICAgICAgICAgICBib2RpZXMgdG8g ZmlsbCB0aGUgZ2Fwcz8NCg0KDQoNCiAgICAgICAgICAgICAgICBUaGUgZHJhZnQtd3UtaHR0cC1z dHJlYW1pbmctb3B0aW1pemF0aW9uLXBzIGlzIGEgZ29vZCBzdGFydCBhdCBzdWNoIGFuDQoNCiAg ICAgICAgICAgICAgICBhbmFseXNpcywgYnV0IGRvZXNuJ3QgZ28gZGVlcCBlbm91Z2ggdG8gbGV0 IHVzIGRlY2lkZSB3aGF0IHdvcmsgSUVURg0KDQogICAgICAgICAgICAgICAgc2hvdWxkIGRvLg0K DQoNCg0KICAgICAgICAgICAgICArMQ0KDQoNCg0KICAgICAgICAgICAgICBUaGUga2V5IHF1ZXN0 aW9uIHJlYWxseSBpcyAid2hhdCBkbyB5b3UgdGhpbmsgdGhlIElFVEYgbmVlZHMgdG8gZG8/Ig0K DQoNCiAgICAgICAgICAgIEkgaW1hZ2luZSB0aGUgb25seSB3b3JrIHRoZSBJRVRGIHNob3VsZCBk byAoaWYgd2UgZGVjaWRlIHRvKSBpcyB0aGUgdHJhbnNwb3J0IGFuZCBIVFRQLWxheWVyIG9wdGlt aXphdGlvbiBmb3IgYmV0dGVyIHN0cmVhbWluZyBwZXJmb3JtYW5jZS4NCg0KICAgICAgICAgICAg LWFjYmVnZW4NCg0KDQogICAgICAgICAgICAgIExhcnMNCg0KICAgICAgICAgICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICAgICAgICAgIGh0dHBz dHJlYW1pbmcgbWFpbGluZyBsaXN0DQogICAgICAgICAgICBodHRwc3RyZWFtaW5nQGlldGYub3Jn DQogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBz dHJlYW1pbmcNCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KICAgICAgICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAg aHR0cHN0cmVhbWluZyBtYWlsaW5nIGxpc3QNCiAgICAgICAgICBodHRwc3RyZWFtaW5nQGlldGYu b3JnDQogICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRw c3RyZWFtaW5nDQoNCg0K --Boundary_(ID_K+H0hZSVKhV3MGkfhXgeRA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PXV0Zi04IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT48QkFTRSANCmhyZWY9IngtbXNnOi8vNS8i Pg0KPE1FVEEgbmFtZT1HRU5FUkFUT1IgY29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xODkyOCI+ DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIA0Kc3R5bGU9IldPUkQtV1JBUDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlIiANCmJnQ29sb3I9I2NjZThjZj4NCjxESVY+SSByZXNwZWN0IHlvdXIg b3Bpb25pb24gYWx0aG91Z2ggSSBjYW4ndCBhZ3JlZSB3aXRoIHlvdS4gSSB3b3VsZCBsaWtlIHRv IA0KaGVhciB3aGF0IG90aGVyIHBlb3BsZSB0aGlua3MuIFRoYW5rcyE8L0RJVj4NCjxCTE9DS1FV T1RFIA0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgUEFERElORy1MRUZU OiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hU OiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj4tLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TOyBCQUNL R1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IA0KICA8QSB0 aXRsZT13YXRzb25tQG5ldGZsaXguY29tIGhyZWY9Im1haWx0bzp3YXRzb25tQG5ldGZsaXguY29t Ij5NYXJrIFdhdHNvbjwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L 5L2TIj48Qj5Ubzo8L0I+IDxBIHRpdGxlPXN1bnNlYXdxQGh1YXdlaS5jb20gDQogIGhyZWY9Im1h aWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQg5a6L5L2TIj48Qj5DYzo8L0I+IDxBIHRpdGxlPWFiZWdlbkBjaXNjby5jb20g DQogIGhyZWY9Im1haWx0bzphYmVnZW5AY2lzY28uY29tIj5BbGkgQy4gQmVnZW4gKGFiZWdlbik8 L0E+IDsgPEEgDQogIHRpdGxlPWh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcgDQogIGhyZWY9Im1haWx0 bzpodHRwc3RyZWFtaW5nQGlldGYub3JnIj5odHRwc3RyZWFtaW5nQGlldGYub3JnPC9BPiA7IDxB IA0KICB0aXRsZT1jc3BAY3NwZXJraW5zLm9yZyBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5v cmciPkNvbGluIFBlcmtpbnM8L0E+IA0KICA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0 IOWui+S9kyI+PEI+U2VudDo8L0I+IEZyaWRheSwgT2N0b2JlciAxNSwgMjAxMCAxMjoyNiBBTTwv RElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TdWJqZWN0OjwvQj4gUmU6 IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyANCiAgYW5kIE91ciBHb2FsPC9ESVY+DQog IDxESVY+PEJSPjwvRElWPjxCUj4NCiAgPERJVj4NCiAgPERJVj5PbiBPY3QgMTQsIDIwMTAsIGF0 IDI6NDEgUE0sIFFpbiBXdSB3cm90ZTo8L0RJVj48QlIgDQogIGNsYXNzPUFwcGxlLWludGVyY2hh bmdlLW5ld2xpbmU+DQogIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPjxTUEFOIA0KICAgIHN0eWxl PSJXSURPV1M6IDI7IFRFWFQtVFJBTlNGT1JNOiBub25lOyBURVhULUlOREVOVDogMHB4OyBCT1JE RVItQ09MTEFQU0U6IHNlcGFyYXRlOyBGT05UOiBtZWRpdW0gSGVsdmV0aWNhOyBXSElURS1TUEFD RTogbm9ybWFsOyBPUlBIQU5TOiAyOyBMRVRURVItU1BBQ0lORzogbm9ybWFsOyBXT1JELVNQQUNJ Tkc6IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt Ym9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWlu LWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHgiIA0KICAgIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+DQogICAg PERJViBiZ2NvbG9yPSIjZmZmZmZmIj4NCiAgICA8RElWPkhpLDwvRElWPg0KICAgIDxCTE9DS1FV T1RFIA0KICAgIHN0eWxlPSJaLUlOREVYOiBhdXRvOyBQT1NJVElPTjogc3RhdGljOyBCT1JERVIt TEVGVDogcmdiKDAsMCwwKSAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJ R0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4IiANCiAgICBkaXI9 bHRyPg0KICAgICAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+LS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLTwvRElWPg0KICAgICAgPERJViANCiAgICAgIHN0eWxlPSJCQUNLR1JPVU5E LUNPTE9SOiByZ2IoMjI4LDIyOCwyMjgpOyBGT05UOiA5cHQg5a6L5L2TOyBiYWNrZ3JvdW5kLW9y aWdpbjogaW5pdGlhbDsgYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsIj48Qj5Gcm9tOjwvQj48U1BB TiANCiAgICAgIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L1NQQU4+PEEgdGl0 bGU9d2F0c29ubUBuZXRmbGl4LmNvbSANCiAgICAgIGhyZWY9Im1haWx0bzp3YXRzb25tQG5ldGZs aXguY29tIj5NYXJrIFdhdHNvbjwvQT48L0RJVj4NCiAgICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCDlrovkvZMiPjxCPlRvOjwvQj48U1BBTiANCiAgICAgIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1z cGFjZT4mbmJzcDs8L1NQQU4+PEEgdGl0bGU9c3Vuc2Vhd3FAaHVhd2VpLmNvbSANCiAgICAgIGhy ZWY9Im1haWx0bzpzdW5zZWF3cUBodWF3ZWkuY29tIj5RaW4gV3U8L0E+PC9ESVY+DQogICAgICA8 RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5DYzo8L0I+PFNQQU4gDQogICAgICBjbGFz cz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxBIHRpdGxlPWFiZWdlbkBjaXNj by5jb20gDQogICAgICBocmVmPSJtYWlsdG86YWJlZ2VuQGNpc2NvLmNvbSI+QWxpIEMuIEJlZ2Vu IChhYmVnZW4pPC9BPjxTUEFOIA0KICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvU1BBTj47PFNQQU4gDQogICAgICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i c3A7PC9TUEFOPjxBIHRpdGxlPWh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcgDQogICAgICBocmVmPSJt YWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvQT48 U1BBTiANCiAgICAgIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L1NQQU4+OzxT UEFOIA0KICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48QSB0 aXRsZT1jc3BAY3NwZXJraW5zLm9yZyANCiAgICAgIGhyZWY9Im1haWx0bzpjc3BAY3NwZXJraW5z Lm9yZyI+Q29saW4gUGVya2luczwvQT48L0RJVj4NCiAgICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCDlrovkvZMiPjxCPlNlbnQ6PC9CPjxTUEFOIA0KICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVk LXNwYWNlPiZuYnNwOzwvU1BBTj5UdWVzZGF5LCBPY3RvYmVyIDEyLCAyMDEwIDEyOjUwIA0KICAg ICAgQU08L0RJVj4NCiAgICAgIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlN1Ympl Y3Q6PC9CPjxTUEFOIA0KICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv U1BBTj5SZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQgDQogICAgICBTdGF0dXMgYW5kIE91ciBH b2FsPC9ESVY+DQogICAgICA8RElWPjxCUj48L0RJVj4NCiAgICAgIDxESVY+U29tZSBjb21tZW50 cyBvbmxpbmUgLi4uPEJSPjxCUj5TZW50IGZyb20gbXkgaVBob25lPC9ESVY+DQogICAgICA8RElW PjxGT05UIHNpemU9MiBmYWNlPeWui+S9kz48L0ZPTlQ+PEJSPk9uIE9jdCAxMSwgMjAxMCwgYXQg Nzo1MCBQTSwgIlFpbiBXdSIgDQogICAgICAmbHQ7PEEgaHJlZj0ibWFpbHRvOnN1bnNlYXdxQGh1 YXdlaS5jb20iPnN1bnNlYXdxQGh1YXdlaS5jb208L0E+Jmd0OyANCiAgICAgIHdyb3RlOjxCUj48 QlI+PC9ESVY+DQogICAgICA8RElWPjwvRElWPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0 ZSI+DQogICAgICAgIDxESVY+DQogICAgICAgIDxESVY+SGksPC9ESVY+DQogICAgICAgIDxESVY+ VGhpcyBpcyB3aGF0IHdlIGhhZCBkaXNjdXNzZWQmbmJzcDsgaW4gdGhlIERJU1BBVENIIG1haWxp bmcgbGlzdCANCiAgICAgICAgYmVmb3JlIHdlIG1vdmUgdG8gdGhpcyBkaXNjdXNzIGxpc3QuPC9E SVY+DQogICAgICAgIDxESVY+SWYgeW91IGxvb2sgYXQgdGhlIGRlc2NyaXB0aW9uIG9mIGRpc2N1 c3MgbGlzdCwgIjwvRElWPg0KICAgICAgICA8RElWPm9mZmVycyBtb3JlIGVmZmljaWVudCB0cmFu c3BvcnQ8U1BBTiANCiAgICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv U1BBTj48QlI+YW5kIGJldHRlciBuZXR3b3JrIA0KICAgICAgICBjYXBhYmlsaXR5IGZvciByZWFs IHRpbWUgc3RyZWFtaW5nIG1lZGlhPEJSPmFuZCBhbGxvd3MgaW50ZXJvcGVyYWJpbGl0eSANCiAg ICAgICAgd2l0aCBvdGhlciBzdHJlYW1pbmcgdGVjaG5pcXVlcyBhbmQgZXhpc3RpbmcgUHJvZ3Jl c3NpdmUgZG93bG9hZGVkIA0KICAgICAgICBiYXNlZDxCUj5IVFRQIHN0cmVhbWluZyBpbXBsZW1l bnRhdGlvbi48L0RJVj4NCiAgICAgICAgPERJVj4iPC9ESVY+DQogICAgICAgIDxESVY+eW91IHdp bGwmbmJzcDtzZWUgd2UgYXJlIG9uIHRoZSBzYW1lIHBhZ2UuPC9ESVY+DQogICAgICAgIDxESVY+ VGhlcmVmb3JlIG9uZSZuYnNwO2ltcG9ydGFudCBnb2FsIGRpc2N1c3NlZCBpbiB0aGUgZHJhZnQm bmJzcDthaW1zIA0KICAgICAgICBhdCZuYnNwO2RldmVsb3BpbmcgaW50ZXJvcGVyYWJsZSBzb2x1 dGlvbiB0bzwvRElWPg0KICAgICAgICA8RElWPnByb3ZpZGUgYmV0dGVyIHRyYW5zcG9ydCB0byBz YXRpc2Z5IHRoZSByZWFsIHRpbWUgc3RyZWFtaW5nIFFPRSANCiAgICAgICAgcmVxdWlyZW1lbnQu IEVzcGVjaWFsbHkmbmJzcDtzZXJ2ZXJhbDwvRElWPg0KICAgICAgICA8RElWPmNoYW5sbGVuZ2Vz L3Byb2JsZW1zJm5ic3A7d2UgZXhwbG9yZWQgaW4gdGhlIGRyYWZ0IGxpc3RlZCANCiAgICAgICAg YmVsb3cuPC9ESVY+DQogICAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICAgIDxESVY+UmVn YXJkcyE8L0RJVj4NCiAgICAgICAgPERJVj4tUWluPC9ESVY+DQogICAgICAgIDxCTE9DS1FVT1RF IA0KICAgICAgICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigwLDAsMCkgMnB4IHNvbGlkOyBQQURE SU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJH SU4tUklHSFQ6IDBweCI+DQogICAgICAgICAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+ LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTwvRElWPg0KICAgICAgICAgIDxESVYgDQogICAg ICAgICAgc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyMjgsMjI4LDIyOCk7IEZPTlQ6IDlw dCDlrovkvZM7IGJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsOyBiYWNrZ3JvdW5kLWNsaXA6IGlu aXRpYWwiPjxCPkZyb206PC9CPjxTUEFOIA0KICAgICAgICAgIGNsYXNzPUFwcGxlLWNvbnZlcnRl ZC1zcGFjZT4mbmJzcDs8L1NQQU4+PEEgdGl0bGU9d2F0c29ubUBuZXRmbGl4LmNvbSANCiAgICAg ICAgICBocmVmPSJtYWlsdG86d2F0c29ubUBuZXRmbGl4LmNvbSI+TWFyayBXYXRzb248L0E+PC9E SVY+DQogICAgICAgICAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+PEI+VG86PC9CPjxT UEFOIA0KICAgICAgICAgIGNsYXNzPUFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L1NQQU4+ PEEgdGl0bGU9YWJlZ2VuQGNpc2NvLmNvbSANCiAgICAgICAgICBocmVmPSJtYWlsdG86YWJlZ2Vu QGNpc2NvLmNvbSI+QWxpIEMuIEJlZ2VuIChhYmVnZW4pPC9BPjwvRElWPg0KICAgICAgICAgIDxE SVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPkNjOjwvQj48U1BBTiANCiAgICAgICAgICBj bGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxBIA0KICAgICAgICAgIHRp dGxlPWh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcgDQogICAgICAgICAgaHJlZj0ibWFpbHRvOmh0dHBz dHJlYW1pbmdAaWV0Zi5vcmciPjwvQT48QSANCiAgICAgICAgICBocmVmPSJtYWlsdG86aHR0cHN0 cmVhbWluZ0BpZXRmLm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvQT48U1BBTiANCiAgICAg ICAgICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjs8U1BBTiANCiAg ICAgICAgICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxBIHRpdGxl PWNzcEBjc3BlcmtpbnMub3JnIA0KICAgICAgICAgIGhyZWY9Im1haWx0bzpjc3BAY3NwZXJraW5z Lm9yZyI+Q29saW4gUGVya2luczwvQT48L0RJVj4NCiAgICAgICAgICA8RElWIHN0eWxlPSJGT05U OiA5cHQg5a6L5L2TIj48Qj5TZW50OjwvQj48U1BBTiANCiAgICAgICAgICBjbGFzcz1BcHBsZS1j b252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPlN1bmRheSwgT2N0b2JlciAxMCwgMjAxMCA3OjEz IA0KICAgICAgICAgIEFNPC9ESVY+DQogICAgICAgICAgPERJViBzdHlsZT0iRk9OVDogOXB0IOWu i+S9kyI+PEI+U3ViamVjdDo8L0I+PFNQQU4gDQogICAgICAgICAgY2xhc3M9QXBwbGUtY29udmVy dGVkLXNwYWNlPiZuYnNwOzwvU1BBTj5SZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQgDQogICAg ICAgICAgU3RhdHVzIGFuZCBPdXIgR29hbDwvRElWPg0KICAgICAgICAgIDxESVY+PEJSPjwvRElW PkFsbCwNCiAgICAgICAgICA8RElWPjxCUj48L0RJVj4NCiAgICAgICAgICA8RElWPkkgd291bGQg bGlrZSB0byBhZGQgbXkgc3VwcG9ydCB0byB0aGUgY29tbWVudHMgYmVsb3cuIA0KICAgICAgICAg IFNwZWNpZmljYWxseSwgSSB0aGluayBpZiB0aGUgSUVURiBjb25zaWRlcnMgd29yayBpbiB0aGlz IGFyZWEgaXQgDQogICAgICAgICAgc2hvdWxkIGZvY3VzIG9uIHRoZSBIVFRQIGFuZCBUQ1AgcHJv dG9jb2xzLiBBbnkgc3VjaCB3b3JrIG1heSBub3QgYmUgDQogICAgICAgICAgc3BlY2lmaWMgdG8g SFRUUC1zdHJlYW1pbmcgKGkuZS4gZW5oYW5jZW1lbnRzIHRoYXQgYXJlIGF0IGZpcnN0IA0KICAg ICAgICAgIG1vdGl2YXRlZCBieSBIVFRQIFN0cmVhbWluZyBtYXkgaGF2ZSBicm9hZGVyIGFwcGxp Y2FiaWxpdHksIGFuZCB0aGlzIA0KICAgICAgICAgIHNob3VsZCBiZSBjYXJlZnVsbHkgY29uc2lk ZXJlZCkuPC9ESVY+DQogICAgICAgICAgPERJVj48QlI+PC9ESVY+DQogICAgICAgICAgPERJVj5J biB0aGUgZHJhZnQgSSBkbyBub3Qgc2VlIGEgY2xlYXIgb3IgY29ycmVjdCBpZGVudGlmaWNhdGlv biBvZiANCiAgICAgICAgICB0aGUgcHJvYmxlbXMuIEZvciBleGFtcGxlIGluIHRoZSBpbnRyb2R1 Y3Rpb24gdGhlIGZvbGxvd2luZyBhcmUgc3RhdGVkIA0KICAgICAgICAgIGFzIGlzc3Vlczo8L0RJ Vj4NCiAgICAgICAgICA8RElWPjxQUkUgY2xhc3M9bmV3cGFnZT4gICAtIENsaWVudCBwb2xsaW5n IGZvciBlYWNoIG5ldyBkYXRhIGluIGNodW5rcyB1c2luZyBIVFRQIHJlcXVlc3RzIGlzDQogICBu b3QgZWZmaWNpZW50IHRvIGRlbGl2ZXIgaGlnaC1xdWFsaXR5IHZpZGVvIGNvbnRlbnQgYWNyb3Nz IHRoZQ0KICAgSW50ZXJuZXQ8QlI+PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIGNsYXNz PUFwcGxlLXN0eWxlLXNwYW4gZmFjZT1IZWx2ZXRpY2E+TVc6IFNldmVyYWwgY29tcGFuaWVzLCBp bmNsdWRpbmcgbXkgZW1wbG95ZXIsIGFyZSBzdWNjZXNzZnVsbHkgb3BlcmF0aW5nIGxhcmdlIHNj YWxlIEhUVFAgc3RyZWFtaW5nIHN5c3RlbXMgdGhhdCBkbyBlZmZpY2llbnRseSBkZWxpdmVyIGhp Z2gtcXVhbGl0eSB2aWRlbyBjb250ZW50IGFjcm9zcyB0aGUgSW50ZXJuZXQsIHNvIHJlYWxpdHkg c2VlbXMgdG8gcmVmdXRlIHRoaXMgc3RhdGVtZW50LjwvRk9OVD48L1BSRT48UFJFIGNsYXNzPW5l d3BhZ2U+PEZPTlQgc2l6ZT00PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W1Fpbl06IE5v dCBzdXJlIHRoZXkgY2FuIHByb3ZpZGUgdGhlIFRWIGV4cGVyaWVuY2UgZm9yIGFsbCB0aGUgY29u bmVjdGVkIGRldmljZXMgbGlrZSBzbWFydHBob25lcywgUENzIGFuZCB0YWJsZXRzLiBBbHNvIG5v dCBzdXJlIHRoZXkgY2FuIHByb3ZpZGUgdGhlIHNhbWUgcXVhbGl0eSBvZiBleHBlcmVuY2UgZm9y IGFsbCB0aGUgYWxsIHRoZSBjb25uZWN0ZWQgZGV2aWNlcy4gQXMgd2UgZGlzY3Vzc2VkIGluIHRo aXMgdGhyZWFkLCBhIG1pbmltdW0gb2YgMjAgc2Vjb25kcyB0byBzdGFydCB5b3VyIHZpZGVvIG9m dGVuIGZydXN0cmF0ZWQgdXNlcnMgdG8ga2VlcCBvbiB3YXRjaGluZyBhbmQgcHJvdmlkZSB2ZXJ5 IGxpbWl0ZWQgdXNlciBleHBlcmllbmNlLjwvRk9OVD48L0ZPTlQ+PC9QUkU+PC9ESVY+PC9CTE9D S1FVT1RFPjwvRElWPjwvQkxPQ0tRVU9URT4NCiAgICAgIDxESVY+Q2FuIHlvdSBiZSBtb3JlIGV4 cGxpY2l0IGFib3V0IHRoZSBwcm9ibGVtcyB0aGF0IHlvdSBzZWU/IA0KICAgICAgSSdtJm5ic3A7 PFNQQU4gY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj5ub3Qgc3VyZSB3aGVyZSB0aGUgMjBzIGZpZ3Vy ZSBjb21lcyANCiAgICAgIGZyb20uIEkgZG8gbm90IHNlZSBhbnkgcHJvYmxlbSBpbiBzdXBwb3J0 aW5nIHN0YXJ0dXAgdGltZXMgY29tcGFyYWJsZSB0byANCiAgICAgIFRWIGNoYW5uZWwgY2hhbmdl IHdpdGggYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcuPC9TUEFOPjwvRElWPg0KICAgICAgPERJVj48 QlI+PC9ESVY+DQogICAgICA8RElWPkkgYW0gbm90IHNheWluZyB0aGVyZSBpcyBubyByb29tIGZv ciBpbXByb3ZlbWVudCBpbiB0aGUgdmFyaW91cyANCiAgICAgIGRlcGxveWVkIHN5c3RlbXMsIGJ1 dCBJIGRvIG5vdCBzZWUgbWFqb3IgdGVjaG5pY2FsIGltcGVkaW1lbnRzIHRvIA0KICAgICAgZWZm aWNpZW50IGRlbGl2ZXJ5IG9mIGhpZ2ggcXVhbGl0eSB2aWRlbyB1c2luZyBIVFRQIFN0cmVhbWlu Zy48L0RJVj4NCiAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgICA8RElWPltRaW5dOk5vdCBv bmx5IHN0YXJ1cCBsYXRlbmN5IGJ1dCBhbHNvIGRlbGF5IHcuci50LiByZWFsIHRpbWUgDQogICAg ICBzdHJlYW1pbmcuIEkgdGhpbmsgeW91IG5lZ2VjdCBpdCBiZWNvcyBZb3UgZGlkbid0IGdldCBp bnRvIHRoZSBkaXNjdXNzaW9uIA0KICAgICAgbGlzdC48U1BBTiBjbGFzcz1BcHBsZS1jb252ZXJ0 ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjxCUj48L0RJVj4NCiAgICAgIDxCTE9DS1FVT1RFIHR5cGU9 ImNpdGUiPg0KICAgICAgICA8RElWPg0KICAgICAgICA8QkxPQ0tRVU9URSANCiAgICAgICAgc3R5 bGU9IkJPUkRFUi1MRUZUOiByZ2IoMCwwLDApIDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7 IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgi Pg0KICAgICAgICAgIDxESVY+PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PEZPTlQgc2l6ZT00Pk9uIHRoZSBvdGhlciBoYW5kLCBJIHRoaW5rIHdlIHNob3Vs ZCBiZWFyIGluIG1pbmQgSFRUUCBpcyBmb3JtZXJseSBkZXNpZ25lZCBmb3IgYnJvd3Npbmcgd2Vi cGFnZSwgdHJhbnNwb3J0IHN0YXRpYyBjb250ZW50cyBsaWtlIEhUTUwgcGFnZSwgcGx1Z2luLCBw aWN0dXJlLCB3aGVuIHdlIGFyZSBnb2luZyB0byB1c2UgPC9GT05UPjxGT05UIHNpemU9ND5IVFRQ IHRvIGRlbGl2ZXIgcmVhbCB0aW1lIHN0cmVhbWluZyBjb250ZW50cywgd2UgY2FuIG5vdCBleHBl Y3QgdG8gZ2V0IGhpZ2hlciB1c2VyIGV4cGVyaWVuY2UuIDwvRk9OVD48Rk9OVCBzaXplPTM+PFNU Uk9ORz5UaGVyZWZvcmUgdGhlIGN1cnJlbnQ8L1NUUk9ORz4gPFNQQU4gc3R5bGU9IkZPTlQtRkFN SUxZOiAnQ291cmllciBOZXcnOyBGT05ULVNJWkU6IDEycHQiIGxhbmc9RU4tVVM+PFNUUk9ORz5z dHJlYW1pbmcgc2NoZW1lcyBjYW4gb25seSBvZmZlciBhIGJldHRlciBleHBlcmllbmNlIG92ZXIg c2xvd2VyIGNvbm5lY3Rpb25zLjwvU1RST05HPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvUFJFPjxQ UkUgY2xhc3M9bmV3cGFnZT4gICAtIFNlZ21lbnRhdGlvbiBjYXBhYmlsaXR5IHJlcXVpcmVzIG92 ZXItdXRpbGl6aW5nIENQVSBhbmQgYmFuZHdpZHRoDQogICByZXNvdXJjZXMsIHdoaWNoIG1heSBu b3QgYmUgYSBkZXNpcmFibGUgYW5kIGVmZmVjdGl2ZSB3YXkgdG8gaW1wcm92ZQ0KICAgdGhlIHF1 YWxpdHkgb2Ygc3RyZWFtaW5nIG1lZGlhIGRlbGl2ZXJ5PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdl PjxGT05UIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4gZmFjZT1IZWx2ZXRpY2E+TVc6IEl0IGlzIG5v dCBjbGVhciB0aGF0IHNlZ21lbnRhdGlvbiBwZXIgc2UgaXMgQ1BVLWludGVuc2l2ZSBvciBoYXMg YW55IG5vbi1uZWdsaWdhYmxlIGVmZmVjdCBvbiBiYW5kd2lkdGggdXNhZ2UuPC9GT05UPjwvUFJF PjxQUkUgY2xhc3M9bmV3cGFnZT48Rk9OVCBzaXplPTQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5b UWluXTogU2luY2UgSFRUUCBzdHJlYW1pbmcgc2VydmVyIGlzIHRoZSBjb21iaW5hdGlvbiBvZiBz dHJlYW1pbmcgc2VydmVyIGFuZCByZWd1bGFyIHdlYiBzZXJ2ZXIsIEkgdGhpbmsgdGhlIGFuc3dl ciBpcyBib3RoLjwvRk9OVD48L1BSRT48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9CTE9DS1FV T1RFPg0KICAgICAgPERJVj48Rk9OVCBzaXplPTIgZmFjZT3lrovkvZM+PC9GT05UPjxCUj48L0RJ Vj4NCiAgICAgIDxESVY+W01XXSB3aGF0IGRvIHlvdSBtZWFuIGJ5JyBodHRwIHN0cmVhbWluZyBz ZXJ2ZXInID88L0RJVj4NCiAgICAgIDxESVY+PEZPTlQgc2l6ZT0yIGZhY2U95a6L5L2TPjwvRk9O VD4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+W1Fpbl06IFdpdGggc3RyZWFtaW5nIGNhcGFiaWxp dHkgYW5kIGZ1bmN0aW9uYWxpdHkgdG8gcmVzcG9uZCB0byBIVFRQIA0KICAgICAgY29ubmVjdGlv bi48QlI+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjwvU1BBTj48L0JMT0NLUVVPVEU+DQogIDxE SVY+PEJSPjwvRElWPg0KICA8RElWPltNV10gSSdtIG5vdCBzdXJlIHdoYXQgb25lIG9mIHRob3Nl IGlzLiBJdCBzb3VuZHMgbGlrZSBpdCBpcyBub3QgYSANCiAgcmVndWxhciB3ZWIgc2VydmVyLiBJ IHRoaW5rIGl0J3MgYW4gZXNzZW50aWFsIGZlYXR1cmUgb2YgbW9kZXJuIEhUVFAgc3RyZWFtaW5n IA0KICB0aGF0IGl0IHdvcmtzIHdpdGggcmVndWxhciB3ZWIgaW5mcmFzdHJ1Y3R1cmUuPC9ESVY+ PEJSPg0KICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48U1BBTiANCiAgICBzdHlsZT0iV0lET1dT OiAyOyBURVhULVRSQU5TRk9STTogbm9uZTsgVEVYVC1JTkRFTlQ6IDBweDsgQk9SREVSLUNPTExB UFNFOiBzZXBhcmF0ZTsgRk9OVDogbWVkaXVtIEhlbHZldGljYTsgV0hJVEUtU1BBQ0U6IG5vcm1h bDsgT1JQSEFOUzogMjsgTEVUVEVSLVNQQUNJTkc6IG5vcm1hbDsgV09SRC1TUEFDSU5HOiAwcHg7 IC13ZWJraXQtYm9yZGVyLWhvcml6b250YWwtc3BhY2luZzogMHB4OyAtd2Via2l0LWJvcmRlci12 ZXJ0aWNhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1kZWNvcmF0aW9ucy1pbi1lZmZlY3Q6 IG5vbmU7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4IiANCiAgICBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPg0KICAgIDxESVYgYmdj b2xvcj0iI2ZmZmZmZiI+DQogICAgPEJMT0NLUVVPVEUgDQogICAgc3R5bGU9IlotSU5ERVg6IGF1 dG87IFBPU0lUSU9OOiBzdGF0aWM7IEJPUkRFUi1MRUZUOiByZ2IoMCwwLDApIDJweCBzb2xpZDsg UEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lOLUxFRlQ6IDVweDsg TUFSR0lOLVJJR0hUOiAwcHgiIA0KICAgIGRpcj1sdHI+DQogICAgICA8QkxPQ0tRVU9URSB0eXBl PSJjaXRlIj4NCiAgICAgICAgPERJVj4NCiAgICAgICAgPEJMT0NLUVVPVEUgDQogICAgICAgIHN0 eWxlPSJCT1JERVItTEVGVDogcmdiKDAsMCwwKSAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4 OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4 Ij4NCiAgICAgICAgICA8RElWPjxQUkUgY2xhc3M9bmV3cGFnZT4gICAtIExhY2sgb2YgUW9TIGd1 YXJhbnRlZSBvbiB0aGUgcGFja2V0IHN3aXRjaGluZyBiYXNlZCBJbnRlcm5ldCAsIHRoZQ0KICAg cXVhbGl0eSBvZiBJbnRlcm5ldCBtZWRpYSBzdHJlYW1pbmcgbWF5IHNpZ25pZmljYW50IGRlZ3Jh ZGUgZHVlIHRvDQogICByaXNpbmcgdXNhZ2U8L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PEZPTlQg Y2xhc3M9QXBwbGUtc3R5bGUtc3BhbiBmYWNlPUhlbHZldGljYT5NVzogQW4gYWx0ZXJuYXRpdmUg dmlldyBpcyB0aGF0IHdoZXJlIHF1YWxpdHkgaXMgZGVncmFkZWQgZHVlIHRvIGNvbmdlc3Rpb24g dGhpcyBpcyBkdWUgdG8gbGFjayBvZiBiYW5kd2lkdGgsIHJhdGhlciB0aGFuIGEgbGFjayBvZiBR b1MgZ3VhcmFudGVlcy4gQWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyBhZGp1c3QgdGhl IHZpZGVvIHF1YWxpdHkgdG8gdGhlIGF2YWlsYWJsZSBiYW5kd2lkdGggaW4gb3JkZXIgdG8gYXZv aWQgcmVidWZmZXJpbmcgZXZlbnRzLiBJdCBpcyB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aCB0aGF0 IG5lZWRzIHRvIGJlIGltcHJvdmVkIHRvIGltcHJvdmUgcXVhbGl0eS48L0ZPTlQ+PC9QUkU+PFBS RSBjbGFzcz1uZXdwYWdlPjxGT05UIGZhY2U9SGVsdmV0aWNhPjxGT05UIHNpemU9NCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPltRaW5dOiBXaGF0IEkgZW1waGFzaXplIGhlcmUgaXMgd2l0aCBncm93 aW5nIHBvcHVsYXJpdHkgb2YgSFRUUCBzdHJlYW1pbmcgdHJhZmZpYywgd2hlbiB0aG91c2FuZHMg b3IgbWlsbGlvbnMgb2YgcGVvcGxlIGFyZSBhY2Nlc3NpbmcgdGhlIHNhbWUgbWVkaWEgY29udGVu dHMsIHRoZSBiaWcgcHJvYmxlbSB3ZSBhcmUgZmFjaW5nIGlzIHNlcmlvdXMgaGlnaCBjb25jdXJy ZW5jZSBhY2Nlc3MgaXNzdWUuIFRoZSB1c2VyIGV4cGVyaWVuY2Ugd2lsbCBiZSBncmVhdGx5IGFm ZmVjdGVkIGV2ZW4geW91IGhhdmUgZW5vdWdoIGF2YWlsYWJsZSBiYW5kd2lkdGguIFNvIHRoaXMg aXMgbm90IHB1cmUgYmFuZHdpZHRoIGlzc3VlLjwvRk9OVD48L0ZPTlQ+PC9QUkU+PC9ESVY+PC9C TE9DS1FVT1RFPjwvRElWPjwvQkxPQ0tRVU9URT4NCiAgICAgIDxESVY+PEZPTlQgc2l6ZT0yIGZh Y2U95a6L5L2TPjwvRk9OVD48QlI+PC9ESVY+DQogICAgICA8RElWPltNV10gbWF5YmUgd2UgbWVh biBkaWZmZXJlbnQgdGhpbmdzIGJ5ICdhdmFpbGFibGUgYmFuZHdpZHRoJy4gRG8geW91IA0KICAg ICAgdGhpbmsgaXQgaXMgYSBzZXJ2ZXIgc2NhbGFiaWxpdHkgcHJvYmxlbSwgb3IgYSBuZXR3b3Jr IHByb2JsZW0gPzwvRElWPg0KICAgICAgPERJVj4mbmJzcDs8L0RJVj4NCiAgICAgIDxESVY+W1Fp bl06IHBsZWFzZSByZWFkPFNQQU4gY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv U1BBTj48QSANCiAgICAgIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9odHRwc3RyZWFtaW5nL2N1cnJlbnQvbXNnMDAwMTEuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL2h0dHBzdHJlYW1pbmcvY3VycmVudC9tc2cwMDAxMS5odG1sPC9B PjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9ESVY+PC9TUEFOPjwvQkxPQ0tRVU9URT4NCiAgPERJ Vj48QlI+PC9ESVY+DQogIDxESVY+W01XXSBTdGlsbCBub3Qgc3VyZSB3aGF0IHlvdSdyZSByZWZl cnJpbmcgdG8gb3RoZXIgdGhhbiBhdmFpbGFibGUgDQogIGJhbmR3aWR0aC4gVGhlIHRocmVhZCBt ZW50aW9ucyBtdWx0aWNhc3QgLSBkbyB5b3UgdGhpbmsgdGhlcmUgcmVtYWlucyB3b3JrIHRvIA0K ICBkZWxpdmVyIEhUVFAgb2JqZWN0cyBvdmVyIG11bHRpY2FzdCBnaXZlbiB0aGUgd29yayBpbiBS TVQgb3ZlciB0aGUgeWVhcnMgDQogID88L0RJVj48QlI+DQogIDxCTE9DS1FVT1RFIHR5cGU9ImNp dGUiPjxTUEFOIA0KICAgIHN0eWxlPSJXSURPV1M6IDI7IFRFWFQtVFJBTlNGT1JNOiBub25lOyBU RVhULUlOREVOVDogMHB4OyBCT1JERVItQ09MTEFQU0U6IHNlcGFyYXRlOyBGT05UOiBtZWRpdW0g SGVsdmV0aWNhOyBXSElURS1TUEFDRTogbm9ybWFsOyBPUlBIQU5TOiAyOyBMRVRURVItU1BBQ0lO Rzogbm9ybWFsOyBXT1JELVNQQUNJTkc6IDBweDsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHgiIA0KICAgIGNsYXNzPUFw cGxlLXN0eWxlLXNwYW4+DQogICAgPERJViBiZ2NvbG9yPSIjZmZmZmZmIj4NCiAgICA8QkxPQ0tR VU9URSANCiAgICBzdHlsZT0iWi1JTkRFWDogYXV0bzsgUE9TSVRJT046IHN0YXRpYzsgQk9SREVS LUxFRlQ6IHJnYigwLDAsMCkgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1S SUdIVDogMHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCIgDQogICAgZGly PWx0cj4NCiAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgICAgICA8RElWPg0KICAg ICAgICA8QkxPQ0tRVU9URSANCiAgICAgICAgc3R5bGU9IkJPUkRFUi1MRUZUOiByZ2IoMCwwLDAp IDJweCBzb2xpZDsgUEFERElORy1MRUZUOiA1cHg7IFBBRERJTkctUklHSFQ6IDBweDsgTUFSR0lO LUxFRlQ6IDVweDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgICAgICAgIDxESVY+PFBSRSBjbGFz cz1uZXdwYWdlPiAgIC0gRXhwZXJpZW5jZSBidXJzdGluZXNzIG9yIG90aGVyIGR5bmFtaWNzIGNo YW5nZXMgZHVlIHRvIGJhbmR3aWR0aA0KICAgZmx1Y3R1YXRpb25zIGFuZCBoZXRlcm9nZW5lb3Vz IGhhbmRvdmVyLjwvUFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48Rk9OVCBjbGFzcz1BcHBsZS1zdHls ZS1zcGFuIGZhY2U9SGVsdmV0aWNhPk1XOiBXZSBoYXZlIGZvdW5kIHRoYXQgYWRhcHRpdmUgSFRU UCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBhcmUgd2VsbCBhYmxlIHRvIGNvcGUgd2l0aCBiYW5kd2lk dGggZmx1Y3R1YXRpb25zLiA8L0ZPTlQ+PC9QUkU+PFBSRSBjbGFzcz1uZXdwYWdlPjxGT05UIHNp emU9NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPltRaW5dOiBJIGRvbid0IGRvdWJ0IHRoYXQgYWRh cHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGhtcyBjYW4gY29wZSB3aXRoIGJhbmR3aWR0aCBm bHVjdGF0aW9uLiBCdXQgSSBob3BlIHdlIGNhbiBkbyBiZXR0ZXIuPC9GT05UPjxGT05UIHNpemU9 NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmUuZy4sIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFs Z29yaXRobXMgb25seSBzdXBwb3J0IGRlbGl2ZXJ5IG9mIG11bHRpcGxlIHN0cmVhbXMgb2YgdGhl IHNhbWUgY29udGVudCB3aXRoIHZhcnlpbmcgcXVhbGl0eSBsZXZlbHMgZm9yIGRpZmZlcmVudCBi YW5kd2lkdGggb3IgZGV2aWNlcy4gSG93ZXZlIGhvdyB0aGUgc2VydmVyIGluIHB1c2ggbW9kZWwg b3IgY2xpZW50IGluIHB1bGwgbW9kZWwgY2FuIHF1aWNrIHJlc3BvbnNlIHRvIHRoZSA8L0ZPTlQ+ PEZPTlQgc2l6ZT00IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Yml0cmF0ZSBjaGFuZ2VzIGlzIGEg cHJvYmxlbSB3ZSBtYXkgbG9vayBhdCxlc3BlY2lhbGx5IHdoZW4gc3dpdGNoaW5nIGJld2VlbiBz dHJlYW1zIG9jY3VycyB2ZXJ5IGZyZXF1ZW50bHkuPC9GT05UPjwvUFJFPjwvRElWPjwvQkxPQ0tR VU9URT48L0RJVj48L0JMT0NLUVVPVEU+DQogICAgICA8RElWPjxGT05UIHNpemU9MiBmYWNlPeWu i+S9kz48L0ZPTlQ+PEJSPjwvRElWPg0KICAgICAgPERJVj5bTVddIFllcywgYnV0IG5vdCBhIHBy b2JsZW0gZm9yIHRoZSBJRVRGLCBJIHRoaW5rLjwvRElWPg0KICAgICAgPERJVj4mbmJzcDs8L0RJ Vj4NCiAgICAgIDxESVY+W1Fpbl06IEkgZGlkbid0IGdldCB3aGF0IHlvdSBzYWlkLjxTUEFOIA0K ICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvU1BBTj48Rk9OVCBzaXpl PTQ+YWRhcHRpdmUgSFRUUCANCiAgICAgIHN0cmVhbWluZyBhbGdvcml0aG1zPFNQQU4gDQogICAg ICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFOPjwvRk9OVD48Rk9OVCBz aXplPTM+aXMgDQogICAgICBjaGFyYWN0ZXJpemVkIGFzJm5ic3A7IGNsaWVudCBpbml0aWF0ZWQg cHVsbCBtb2RlbC4gV2UgYXJlIGRpc2N1c3NpbmcgcHVzaCANCiAgICAgIG1vZGVsIG9yIGhvdyB0 byB1c2UgcHVsbCBtb2RlbCB3aXRoIHB1c2ggbW9kZWwuV2UgYXJlIHRhbGtpbmcgYWJvdXQgDQog ICAgICBkaWZmZXJlbnQgbW9kZWwuIFRoZXJlIGFyZSBwbGVudHkgcm9vbSBmb3IgSUVURiB0byBk byBmb3IgDQogICAgICB0aGlzLjxCUj48L0ZPTlQ+PC9ESVY+PC9CTE9DS1FVT1RFPjwvRElWPjwv U1BBTj48L0JMT0NLUVVPVEU+DQogIDxESVY+PEJSPjwvRElWPltNV10gU29ycnksIEkgZG9uJ3Qg dW5kZXJzdGFuZCB3aGF0IHRoZSAicHVzaCIgbW9kZWwgaGFzIHRvIGRvIA0KICB3aXRoIEhUVFAg U3RyZWFtaW5nLiBBcmUgeW91IHRhbGtpbmcgYWJvdXQgc2VydmVycyB3aGljaCBhcmUgbm90IHJl Z3VsYXIgSFRUUCANCiAgc2VydmVycyA/IEkgdGhpbmsgdGhpcyBpcyBub3Qgd2hhdCBwZW9wbGUg dXN1YWxseSBtZWFuIHdoZW4gdGhleSBzYXkgIkhUVFAgDQogIHN0cmVhbWluZyIgLSB5b3Ugc2hv dWxkIHJlbmFtZSB0aGUgd29yayBpZiB0aGF0IGlzIHRoZSBjYXNlLjxCUj4NCiAgPEJMT0NLUVVP VEUgdHlwZT0iY2l0ZSI+PFNQQU4gDQogICAgc3R5bGU9IldJRE9XUzogMjsgVEVYVC1UUkFOU0ZP Uk06IG5vbmU7IFRFWFQtSU5ERU5UOiAwcHg7IEJPUkRFUi1DT0xMQVBTRTogc2VwYXJhdGU7IEZP TlQ6IG1lZGl1bSBIZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWw7IE9SUEhBTlM6IDI7IExF VFRFUi1TUEFDSU5HOiBub3JtYWw7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LWJvcmRlci1o b3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgDQog ICAgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj4NCiAgICA8RElWIGJnY29sb3I9IiNmZmZmZmYiPg0K ICAgIDxCTE9DS1FVT1RFIA0KICAgIHN0eWxlPSJaLUlOREVYOiBhdXRvOyBQT1NJVElPTjogc3Rh dGljOyBCT1JERVItTEVGVDogcmdiKDAsMCwwKSAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4 OyBQQURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4 IiANCiAgICBkaXI9bHRyPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICAg IDxESVY+DQogICAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAgICBzdHlsZT0iQk9SREVSLUxFRlQ6 IHJnYigwLDAsMCkgMnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDog MHB4OyBNQVJHSU4tTEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICAgICAgPERJ Vj48UFJFIGNsYXNzPW5ld3BhZ2U+ICAgLSBJbXBvc3NpYmxlIHRvIGZhc3QtZm9yd2FyZCB0aHJv dWdoIGFueSBwYXJ0IG9mIGEgc3RyZWFtaW5nDQogICBjb250ZW50cyB1bnRpbCBpdCBpcyBzdG9y ZWQgb24gdGhlIHVzZXIncyBkZXZpY2U8L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+TVc6IFRoaXMg aXMgc2ltcGx5IG5vdCBjb3JyZWN0LCBzaW5jZSB0aGVyZSBhcmUgaHVuZHJlZHMgb2YgZXhhbXBs ZXMgb2YgZGV2aWNlcyB3aGljaCBzdXBwb3J0IHRyaWNrLXBsYXkgdXNpbmcgSFRUUCBzdHJlYW1p bmcgdGVjaG5pcXVlcyB3aXRob3V0IHN0b3JpbmcgdGhlIHdob2xlIGNvbnRlbnQgb24gdGhlIHVz ZXJzIGRldmljZS48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PFNQQU4gc3R5bGU9IkZPTlQtRkFN SUxZOiBIZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNw YW4+PEZPTlQgc2l6ZT00IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+W1Fpbl06IEZhc3QgZm9yd2Fy ZCBjYXBhYmlsdHkgaXMgbm90IHRoZSBtb3N0IGltcG9ydGFudCBmZWF0dXJlIHdlIGFyZSBsb29r aW5nIGZvci4gSG93ZXZlciBJIGFtIGhhcmQgdG8gYmVsaWV2ZSBleGlzdGluZyBIVFRQIHN0cmVh bWluZyB0ZWNobmlxdWVzIGNhbiBwcm92aWRlIHRoZSBzYW1lIGRlZ3JlZSBvZiBwbGF5YmFjazwv Rk9OVD48L1NQQU4+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2ZXRpY2E7IFdISVRFLVNQ QUNFOiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+PEZPTlQgc2l6ZT00IGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+Y29udHJvbCB0aGF0IERWRCBwbGF5ZXIgY2FuIHByb3ZpZGVzIG9yIFJU U1AgcHJvdG9jb2wgcHJvdmlkZXMuIEUuZy4sIEluIHRoZSBhZGFwdGl2ZSBIVFRQIHN0cmVhbWlu ZyBhbGdvcml0aG1zLCB0aGUgdHJpY2sgcGxheSBpcyBsaW1pdGVkIHRvIHBhdXNlL3Jlc3VtZS9z dG9wIGJ5IGRyaXZpbmcgdGhlIEhUVFAgcmVxdWVzdC4gSWYgdGhlIGNvbnRlbnRzIGhhc24ndCBi ZWVuIGRvd2xvYWRlZCBhbmQgdGhlIGNvbnN1bWUgd2FudCBmYXN0IGZvcndhcmQsIHRoZSBIVFRQ IGNsaWVudCBuZWVkcyB0byBpc3N1ZSBhbm90aGVyIG5ldyBIVFRQIHJlcXVlc3QgdG8gZmV0Y2gg dGhlIGNvbnRlbnRzIHdoaWNoIHdpbGw8L0ZPTlQ+PC9TUEFOPjxTUEFOIHN0eWxlPSJGT05ULUZB TUlMWTogSGVsdmV0aWNhOyBXSElURS1TUEFDRTogbm9ybWFsIiBjbGFzcz1BcHBsZS1zdHlsZS1z cGFuPjxGT05UIHNpemU9NCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmNhdXNlIHVuYWNjZXB0YWJs ZSBsYXRlbmN5IHRvIHRoZSBjb25zdW1lci48L0ZPTlQ+PC9TUEFOPjwvUFJFPjwvRElWPjwvQkxP Q0tRVU9URT48L0RJVj48L0JMT0NLUVVPVEU+DQogICAgICA8RElWPltNV10gQWdhaW4sIHRoZSBl eHBlcmllbmNlIG9mIG1pbGxpb25zIG9mIGV4aXN0aW5nIGN1c3RvbWVycyByZWZ1dGVzIA0KICAg ICAgd2hhdCB5b3UgY2xhaW0uIFdoeSBkbyB5b3UgdGhpbmsgaXQgaXMgbmVjZXNzYXJpbHkgc28g c2xvdyB0byBpc3N1ZSBhIG5ldyANCiAgICAgIEhUVFAgcmVxdWVzdCBmb3IgYSBkaWZmZXJlbnQg cGFydCBvZiB0aGUgY29udGVudD88L0RJVj4NCiAgICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAg ICA8RElWPltRaW5dOiBZb3UgZGlkbid0IHNlZSB0aGUgcmVhb24gYmVoaW5kIHRoaXMsIGJlY29z IHRoZSBleGlzdGluZyANCiAgICAgIGN1c3RvbWVycyBoYXMgbm8gY2hvaWNlIHdoZW4gdGhleSB2 aWV3IGxpdmUgc3RyZWFtaW5nLCB3aGF0IHRoZXkgY2FuIGdldCANCiAgICAgIGlzIGNsb3NlIHRv IGxpdmUgZXhwZXJpZW5jZSByYXRoZXIgdGhhbiByZWFsIHRpbWUgdXNlciBleHBlcmllbmNlLiAN CiAgICAgIE9wZXJhdG9lciBkbyBub3RoaW5nIGZvciB0aGVpciBuZXR3b3JrIHRvIG1ha2UgaHR0 cCBzdHJlYW1pbmcgbW9yZSANCiAgICAgIGNvbnRyb2xsYWJsZSBhbmQgbWFuYWdhYmxlLiBUaGVy ZWZvcmUgbW9yZSBhbmQgbW9yZSBjb25zdW1lciZuYnNwO3RlbmQgDQogICAgICB0byZuYnNwO2No b29zZSBub24tbGl2ZSBjb250ZW50LiB0aGF0J3Mgd2h5IHdlIHNlZSBtb3JlIGFuZCBtb3JlIG5v bi1saXZlIA0KICAgICAgY29udGVudCBjb25zdW1lcnMgcmF0aGVyIHRoYW4gbGl2ZSBjb250ZW50 cyBjb25zdW1lcnMuPC9ESVY+DQogICAgICA8RElWPjxCUj48L0RJVj48L0JMT0NLUVVPVEU+PC9E SVY+PC9TUEFOPjwvQkxPQ0tRVU9URT4NCiAgPERJVj48QlI+PC9ESVY+DQogIDxESVY+W01XXSBX ZWxsLCBJJ20gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBwb2ludC4gQnV0IHN0aWxsIHRoZSBz dGF0ZW1lbnQgDQogIGluIHRoZSBkcmFmdCBpcyBub3QgdHJ1ZS48L0RJVj4NCiAgPERJVj48QlI+ PC9ESVY+DQogIDxESVY+Li4uTWFyazwvRElWPjxCUj4NCiAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0 ZSI+PFNQQU4gDQogICAgc3R5bGU9IldJRE9XUzogMjsgVEVYVC1UUkFOU0ZPUk06IG5vbmU7IFRF WFQtSU5ERU5UOiAwcHg7IEJPUkRFUi1DT0xMQVBTRTogc2VwYXJhdGU7IEZPTlQ6IG1lZGl1bSBI ZWx2ZXRpY2E7IFdISVRFLVNQQUNFOiBub3JtYWw7IE9SUEhBTlM6IDI7IExFVFRFUi1TUEFDSU5H OiBub3JtYWw7IFdPUkQtU1BBQ0lORzogMHB4OyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNw YWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweCIgDQogICAgY2xhc3M9QXBw bGUtc3R5bGUtc3Bhbj4NCiAgICA8RElWIGJnY29sb3I9IiNmZmZmZmYiPg0KICAgIDxCTE9DS1FV T1RFIA0KICAgIHN0eWxlPSJaLUlOREVYOiBhdXRvOyBQT1NJVElPTjogc3RhdGljOyBCT1JERVIt TEVGVDogcmdiKDAsMCwwKSAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQQURESU5HLVJJ R0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4IiANCiAgICBkaXI9 bHRyPg0KICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICAgIDxESVY+DQogICAg ICAgIDxCTE9DS1FVT1RFIA0KICAgICAgICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigwLDAsMCkg MnB4IHNvbGlkOyBQQURESU5HLUxFRlQ6IDVweDsgUEFERElORy1SSUdIVDogMHB4OyBNQVJHSU4t TEVGVDogNXB4OyBNQVJHSU4tUklHSFQ6IDBweCI+DQogICAgICAgICAgPERJVj48UFJFIGNsYXNz PW5ld3BhZ2U+PFNQQU4gc3R5bGU9IkZPTlQtRkFNSUxZOiBIZWx2ZXRpY2E7IFdISVRFLVNQQUNF OiBub3JtYWwiIGNsYXNzPUFwcGxlLXN0eWxlLXNwYW4+QSBmaXJzdCBzdGVwIGluIGNvbnNpZGVy aW5nIHdoYXQsIGlmIGFueSwgd29yayBzaG91bGQgYmUgZG9uZSBoZXJlIG1pZ2h0IGJlIHRvIGNv bnRhY3QgdGhvc2Ugb3JnYW5pemF0aW9ucyB3aGljaCBhcmUgc3RhbmRhcmRpemluZyB0aGUgaGln aGVyIGxheWVycyBvZiBIVFRQIHN0cmVhbWluZyBzeXN0ZW1zIChlLmcuIG1hbmlmZXN0IGFuZCBm aWxlIGZvcm1hdHMpIGFuZCBhc2sgd2hldGhlciB0aGVyZSBhcmUgZGVmaWNpZW5jaWVzIHRoZXkg c2VlIGluIElFVEYgcHJvdG9jb2xzIHRoYXQgY291bGQgYmUgdXNlZnVsbHkgYWRkcmVzc2VkIGJ5 IHRoZSBJRVRGLiBXaGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGF2b2lkIGluIHRoZSBJRVRGIGlzIGR1 cGxpY2F0aW5nIHRoZSB3b3JrIG9mIHRoZXNlIG90aGVyIGJvZGllcy48L1NQQU4+PC9QUkU+PFBS RSBjbGFzcz1uZXdwYWdlPjxTUEFOIHN0eWxlPSJGT05ULUZBTUlMWTogSGVsdmV0aWNhOyBXSElU RS1TUEFDRTogbm9ybWFsIiBjbGFzcz1BcHBsZS1zdHlsZS1zcGFuPkJlc3QsPC9TUEFOPjwvUFJF PjxQUkUgY2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhlbHZldGljYTsg V0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj48QlI+PC9TUEFOPjwv UFJFPjxQUkUgY2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhlbHZldGlj YTsgV0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj5NYXJrIFdhdHNv bjwvU1BBTj48L1BSRT48UFJFIGNsYXNzPW5ld3BhZ2U+PEZPTlQgY2xhc3M9QXBwbGUtc3R5bGUt c3BhbiBmYWNlPUhlbHZldGljYT48U1BBTiBzdHlsZT0iV0hJVEUtU1BBQ0U6IG5vcm1hbCIgY2xh c3M9QXBwbGUtc3R5bGUtc3Bhbj5OZXRmbGl4IEluYy48L1NQQU4+PC9GT05UPjwvUFJFPjxQUkUg Y2xhc3M9bmV3cGFnZT48U1BBTiBzdHlsZT0iRk9OVC1GQU1JTFk6IEhlbHZldGljYTsgV0hJVEUt U1BBQ0U6IG5vcm1hbCIgY2xhc3M9QXBwbGUtc3R5bGUtc3Bhbj48QlI+PC9TUEFOPjwvUFJFPjwv RElWPg0KICAgICAgICAgIDxESVY+PEJSPjwvRElWPg0KICAgICAgICAgIDxESVY+PEJSPjwvRElW Pg0KICAgICAgICAgIDxESVY+PEJSPg0KICAgICAgICAgIDxESVY+DQogICAgICAgICAgPERJVj5P biBPY3QgMTAsIDIwMTAsIGF0IDEyOjQzIEFNLCBBbGkgQy4gQmVnZW4gKGFiZWdlbikgDQogICAg ICAgICAgd3JvdGU6PC9ESVY+PEJSIGNsYXNzPUFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmU+DQog ICAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICA8RElWPjxCUj48 QlI+DQogICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxCUj48L0JMT0NLUVVPVEU+DQogICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBl PSJjaXRlIj5Gcm9tOjxTUEFOIA0KICAgICAgICAgICAgICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQt c3BhY2U+Jm5ic3A7PC9TUEFOPjxBIA0KICAgICAgICAgICAgICBocmVmPSJtYWlsdG86aHR0cHN0 cmVhbWluZy1ib3VuY2VzQGlldGYub3JnIj48L0E+PEEgDQogICAgICAgICAgICAgIGhyZWY9Im1h aWx0bzpodHRwc3RyZWFtaW5nLWJvdW5jZXNAaWV0Zi5vcmciPmh0dHBzdHJlYW1pbmctYm91bmNl c0BpZXRmLm9yZzwvQT48U1BBTiANCiAgICAgICAgICAgICAgY2xhc3M9QXBwbGUtY29udmVydGVk LXNwYWNlPiZuYnNwOzwvU1BBTj5bbWFpbHRvOmh0dHBzdHJlYW1pbmctYm91bmNlc0BpZXRmLm9y Z10gDQogICAgICAgICAgICAgIE9uIEJlaGFsZiBPZiBMYXJzIEVnZ2VydDxCUj48L0JMT0NLUVVP VEU+DQogICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5TZW50OiBGcmlkYXksIE9j dG9iZXIgMDgsIDIwMTAgNDoxNyANCiAgICAgICAgICAgIFBNPEJSPjwvQkxPQ0tRVU9URT4NCiAg ICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPlRvOiBDb2xpbiBQZXJraW5zPEJSPjwv QkxPQ0tRVU9URT4NCiAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPkNjOjxTUEFO IA0KICAgICAgICAgICAgICBjbGFzcz1BcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9TUEFO PjxBIA0KICAgICAgICAgICAgICBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+ PC9BPjxBIA0KICAgICAgICAgICAgICBocmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9y ZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvQT48QlI+PC9CTE9DS1FVT1RFPg0KICAgICAgICAg ICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+U3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBD dXJyZW50IA0KICAgICAgICAgICAgICBTdGF0dXMgYW5kIE91ciBHb2FsPEJSPjwvQkxPQ0tRVU9U RT4NCiAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPjxCUj48L0JMT0NLUVVPVEU+ DQogICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5PbiAyMDEwLTEwLTcsIGF0IDE0 OjE2LCBDb2xpbiBQZXJraW5zIA0KICAgICAgICAgICAgICB3cm90ZTo8QlI+PC9CTE9DS1FVT1RF Pg0KICAgICAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgIDxC TE9DS1FVT1RFIHR5cGU9ImNpdGUiPlRoZXJlIGFyZSBjbGVhcmx5IHNvbWUgaXNzdWVzIHRvIA0K ICAgICAgICAgICAgICAgIGNvbnNpZGVyIGhlcmUuIFdoYXQgc2VlbXMgdG8gYmU8QlI+PC9CTE9D S1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUi Pg0KICAgICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5taXNzaW5nIGZyb20gdGhl IGRpc2N1c3Npb24gdG8gbWUgDQogICAgICAgICAgICAgICAgdGhvdWdoLCBpcyBzb21lIGlkZW50 aWZpY2F0aW9uIG9mPEJSPjwvQkxPQ0tRVU9URT48L0JMT0NLUVVPVEU+DQogICAgICAgICAgICA8 QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICAgICAgICAgICAgPEJMT0NLUVVPVEUgdHlwZT0i Y2l0ZSI+dGhlIGNvbmNyZXRlIHByb2JsZW1zLiBXaGF0IHByb3RvY29sIA0KICAgICAgICAgICAg ICAgIHBpZWNlcyBkbyB3ZSBuZWVkLCBidXQgbm90IGhhdmU/PEJSPjwvQkxPQ0tRVU9URT48L0JM T0NLUVVPVEU+DQogICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4NCiAgICAgICAg ICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+V2hhdCBwcm90b2NvbHMgYXJlIHByb2JsZW1h dGljLCBhbmQgbmVlZCANCiAgICAgICAgICAgICAgICBlbmhhbmNlbWVudD8gSXMgdGhlcmU8QlI+ PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9 ImNpdGUiPg0KICAgICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5wcm90b2NvbCB3 b3JrIHRvIGRvIGluIElFVEYsIG9yIHNob3VsZCANCiAgICAgICAgICAgICAgICB3ZSBiZSBkb2N1 bWVudGluZyBiZXN0IGN1cnJlbnQ8QlI+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAg ICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAgICAgICAgICAgICA8QkxPQ0tRVU9U RSB0eXBlPSJjaXRlIj5wcmFjdGljZXMgZm9yIHVzaW5nIHRoZSBleGlzdGluZyANCiAgICAgICAg ICAgICAgICBwcm90b2NvbHMgYW5kL29yIHJlbHlpbmcgb24gb3RoZXI8QlI+PC9CTE9DS1FVT1RF PjwvQkxPQ0tRVU9URT4NCiAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPg0KICAg ICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5ib2RpZXMgdG8gZmlsbCB0aGUgDQog ICAgICAgICAgICBnYXBzPzxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgICAgICAg ICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5 cGU9ImNpdGUiPjxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgICAgICAgICAgPEJM T0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNp dGUiPlRoZSANCiAgICAgICAgICAgICAgICBkcmFmdC13dS1odHRwLXN0cmVhbWluZy1vcHRpbWl6 YXRpb24tcHMgaXMgYSBnb29kIHN0YXJ0IGF0IHN1Y2ggDQogICAgICAgICAgICAgICAgYW48QlI+ PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAgICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9 ImNpdGUiPg0KICAgICAgICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj5hbmFseXNpcywg YnV0IGRvZXNuJ3QgZ28gZGVlcCBlbm91Z2ggdG8gDQogICAgICAgICAgICAgICAgbGV0IHVzIGRl Y2lkZSB3aGF0IHdvcmsgSUVURjxCUj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPg0KICAgICAg ICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+DQogICAgICAgICAgICAgIDxCTE9DS1FVT1RF IHR5cGU9ImNpdGUiPnNob3VsZCBkby48QlI+PC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT4NCiAg ICAgICAgICAgIDxCTE9DS1FVT1RFIHR5cGU9ImNpdGUiPjxCUj48L0JMT0NLUVVPVEU+DQogICAg ICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj4rMTxCUj48L0JMT0NLUVVPVEU+DQogICAg ICAgICAgICA8QkxPQ0tRVU9URSB0eXBlPSJjaXRlIj48QlI+PC9CTE9DS1FVT1RFPg0KICAgICAg ICAgICAgPEJMT0NLUVVPVEUgdHlwZT0iY2l0ZSI+VGhlIGtleSBxdWVzdGlvbiByZWFsbHkgaXMg IndoYXQgZG8geW91IA0KICAgICAgICAgICAgICB0aGluayB0aGUgSUVURiBuZWVkcyB0byBkbz8i PEJSPjwvQkxPQ0tRVU9URT48QlI+SSBpbWFnaW5lIHRoZSBvbmx5IA0KICAgICAgICAgICAgd29y ayB0aGUgSUVURiBzaG91bGQgZG8gKGlmIHdlIGRlY2lkZSB0bykgaXMgdGhlIHRyYW5zcG9ydCBh bmQgDQogICAgICAgICAgICBIVFRQLWxheWVyIG9wdGltaXphdGlvbiBmb3IgYmV0dGVyIHN0cmVh bWluZyANCiAgICAgICAgICAgIHBlcmZvcm1hbmNlLjxCUj48QlI+LWFjYmVnZW48QlI+PEJSPg0K ICAgICAgICAgICAgPEJMT0NLUVVPVEUgDQogICAgICAgICAgICB0eXBlPSJjaXRlIj5MYXJzPEJS PjwvQkxPQ0tRVU9URT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxCUj5odHRwc3RyZWFtaW5nIA0KICAgICAgICAgICAgbWFpbGluZyBsaXN0PEJSPjxBIGhy ZWY9Im1haWx0bzpodHRwc3RyZWFtaW5nQGlldGYub3JnIj48L0E+PEEgDQogICAgICAgICAgICBo cmVmPSJtYWlsdG86aHR0cHN0cmVhbWluZ0BpZXRmLm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9y ZzwvQT48QlI+PEEgDQogICAgICAgICAgICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmciPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaHR0cHN0cmVhbWluZzwvQT48QlI+PEJSPjwvRElWPjwvQkxPQ0tRVU9URT48L0RJ Vj48QlI+PC9ESVY+DQogICAgICAgICAgPERJVj48QlIgY2xhc3M9d2Via2l0LWJsb2NrLXBsYWNl aG9sZGVyPjwvRElWPg0KICAgICAgICAgIDxIUj4NCg0KICAgICAgICAgIDxESVY+PEJSIA0KICAg ICAgICAgIGNsYXNzPXdlYmtpdC1ibG9jay1wbGFjZWhvbGRlcj48L0RJVj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5odHRwc3RyZWFtaW5nIA0KICAg ICAgICAgIG1haWxpbmcgbGlzdDxCUj48QSANCiAgICAgICAgICBocmVmPSJtYWlsdG86aHR0cHN0 cmVhbWluZ0BpZXRmLm9yZyI+aHR0cHN0cmVhbWluZ0BpZXRmLm9yZzwvQT48QlI+PEEgDQogICAg ICAgICAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3Ry ZWFtaW5nIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1p bmc8L0E+PEJSPjwvQkxPQ0tRVU9URT48L0RJVj48L0JMT0NLUVVPVEU+PC9CTE9DS1FVT1RFPjwv RElWPjwvU1BBTj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9I VE1MPg0K --Boundary_(ID_K+H0hZSVKhV3MGkfhXgeRA)-- From abegen@cisco.com Thu Oct 14 22:13:30 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FEAE3A6A77 for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 22:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UllJpqsGjj6D for <httpstreaming@core3.amsl.com>; Thu, 14 Oct 2010 22:13:20 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F01713A699A for <httpstreaming@ietf.org>; Thu, 14 Oct 2010 22:13:19 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADOAt0yrR7Hu/2dsb2JhbAChInGiFJxchUgEhFOIfA X-IronPort-AV: E=Sophos;i="4.57,334,1283731200"; d="scan'208";a="371214425" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2010 05:14:40 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9F5EeeZ024702; Fri, 15 Oct 2010 05:14:40 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 22:14:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Oct 2010 22:14:26 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> In-Reply-To: <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActsC2HFkm67FlBqTa+P0/kZt6Fv3AAGuVuA References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Qin Wu" <sunseawq@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> X-OriginalArrivalTime: 15 Oct 2010 05:14:40.0286 (UTC) FILETIME=[DE8343E0:01CB6C27] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 05:13:30 -0000 > But, in http streaming scenario, the ratio of download/upload (from = the client's perspective) is much larger than 1. BTW, if > you keep your chunk duration relatively longer, the amount of requests = that you will end up sending will be almost nil > compared to what you will receive. >=20 > [Qin]: No, I just compare pull and push with the same chunk duration. You can choose whatever chunk size you wanna use. Does not matter. The = fact remains the same. Unless someone uses chunks of a few hundreds of = ms, it won't matter. =20 ... > Sorry if "playback time" meant the duration of the playback. I rather = meant the start time of the playback. So, if a client > keeps a larger buffer hoping that it will avoid buffer underruns, this = may delay the playback start time. >=20 > [Qin]: Right. So we need to choose approporiate buffer size to seek = balance between buffer underflow and startup time > delay. The buffer size can be changed at any time. It is not up to me or you. Any implementation (depending on the device, = scenario, network type, etc.) can choose any size for the buffer. =20 > Or, the client can start the playback quickly and build the buffer = over time by requesting lower-bitrate chunks. >=20 > [Qin]: I think the presumption is the server should prepare multiple = streams of the same content with different bitrates. the > server may have a big load if the content is live contents. It is not the server who prepares the content. Not necessarily and not = often. So, serving the same content at different bitrates does not pose = any extra load on the server (except where the caching comes into play). =20 > Whether it paces the presentation speed down or not in order to avoid = buffer underruns is something up to the client. Most > implementations I have seen simply switch to a lower-bitrate profile = well before the buffer is fully drained. So, they don't > experience buffer underruns and they don=92t need to pace the video = presentation speed down. >=20 > [Qin]: I don't doubt giving more control to client has its advantages. = But I think giving some control to the server also has its > advantage. e.g., you may not need to prepare multiple stream of the = same content with different bitrate. Well, AFAICT the method in which people (including me) are interested in = is this so-called multi-bitrate streaming, which implies the same = content being encoded at multiple bitrates. > the server control the transmission rate based on the network = condition and client requirements. How would this work if you have only one bitrate on the server? Is your = approach as follows: Rather than offering the same content encoded at multiple bitrates and = serving them based on what the client wants, you wanna serve the content = encoded at a single bitrate and by manipulating the transmission rate on = the server (based on server's knowledge of network and client), you = "adaptively" send it. Is that the scenario you have in mind? -acbegen From sunseawq@huawei.com Fri Oct 15 00:14:03 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112083A6A94 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 00:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.995 X-Spam-Level: X-Spam-Status: No, score=0.995 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgwUsVV-P659 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 00:14:02 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id EF7383A6A83 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 00:14:00 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00C86LFESR@szxga05-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 15:14:02 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB003PZLFDK0@szxga05-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 15:14:02 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB0043RLFC5G@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 15:14:01 +0800 (CST) Date: Fri, 15 Oct 2010 15:14:01 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <051901cb6c38$8b640f30$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 07:14:03 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBbGkgQy4gQmVnZW4gKGFiZWdl bikiIDxhYmVnZW5AY2lzY28uY29tPg0KVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29t PjsgIlJvbmkgRXZlbiIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJyeWFuIiA8 ZGJyeWFuQGV0aGVybm90Lm9yZz4NCkNjOiA8aHR0cHN0cmVhbWluZ0BpZXRmLm9yZz4NClNlbnQ6 IEZyaWRheSwgT2N0b2JlciAxNSwgMjAxMCAxOjE0IFBNDQpTdWJqZWN0OiBSRTogW2h0dHBzdHJl YW1pbmddIEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KDQoNCj4gQnV0LCBpbiBodHRwIHN0 cmVhbWluZyBzY2VuYXJpbywgdGhlIHJhdGlvIG9mIGRvd25sb2FkL3VwbG9hZCAoZnJvbSB0aGUg Y2xpZW50J3MgcGVyc3BlY3RpdmUpIGlzIG11Y2ggbGFyZ2VyIHRoYW4gMS4gQlRXLCBpZg0KPiB5 b3Uga2VlcCB5b3VyIGNodW5rIGR1cmF0aW9uIHJlbGF0aXZlbHkgbG9uZ2VyLCB0aGUgYW1vdW50 IG9mIHJlcXVlc3RzIHRoYXQgeW91IHdpbGwgZW5kIHVwIHNlbmRpbmcgd2lsbCBiZSBhbG1vc3Qg bmlsDQo+IGNvbXBhcmVkIHRvIHdoYXQgeW91IHdpbGwgcmVjZWl2ZS4NCj4gDQo+IFtRaW5dOiBO bywgSSBqdXN0IGNvbXBhcmUgcHVsbCBhbmQgcHVzaCB3aXRoIHRoZSBzYW1lIGNodW5rIGR1cmF0 aW9uLg0KDQpZb3UgY2FuIGNob29zZSB3aGF0ZXZlciBjaHVuayBzaXplIHlvdSB3YW5uYSB1c2Uu IERvZXMgbm90IG1hdHRlci4gVGhlIGZhY3QgcmVtYWlucyB0aGUgc2FtZS4gVW5sZXNzIHNvbWVv bmUgdXNlcyBjaHVua3Mgb2YgYSBmZXcgaHVuZHJlZHMgb2YgbXMsIGl0IHdvbid0IG1hdHRlci4N Cg0KIFtRaW5dOiBTdXBwb3NlIDEwIGNodW5rcyBpcyBhdmFpbGFibGUgYXQgdGhlIHNlcnZlciBz aWRlLCBpbiB0aGUgcHVsbCBtb2RlbCwgdGhlIGNsaWVudCBuZWVkIHRvIHNlbmQgYXQgbGVhc3Qg MTAgcmVxdWVzdHMgYW5kIHJlY2VpdmUgMTAgcmVzcG9uc2VzLg0KICAgICAgICAgIGluIHRoZSBw dXNoIG1vZGVsLCB0aGUgY2xpZW50IG1heSBvbmx5IG5lZWQgdG8gc2VuZCBvbmUgcmVxdWVzdCBh bmQgdGhlbiByZWNlaXZlIDEwIHJlc3BvbnNlcy4NCiAgICAgICAgICBjb21wYXJpbmcgd2l0aCBw dWxsLCBwdXNoIG1vZGVsIHNhdmUgOSByZXF1ZXN0cy4NCiAgICAgICAgICBhbHNvIGlmIHlvdSBs b29rIGF0IHdlYnNvY2tldCwgcHVzaCBoYXMgbW9yZSBsaWdodHdlaWdodCBoZWFkZXIgdGhhbiBw dWxsLg0KICAgICAgICAgIEhvd2V2ZXIgYXMgeW91IHNhaWQ6DQogICAgICAgICAgIg0KICAgICAg ICAgIGlmICB5b3Uga2VlcCB5b3VyIGNodW5rIGR1cmF0aW9uIHJlbGF0aXZlbHkgbG9uZ2VyLCB0 aGUgYW1vdW50IG9mIHJlcXVlc3RzIHRoYXQgeW91IHdpbGwgZW5kIHVwIHNlbmRpbmcgd2lsbCBi ZSBhbG1vc3QgbmlsDQogICAgICAgICBjb21wYXJlZCB0byB3aGF0IHlvdSB3aWxsIHJlY2VpdmUu DQogICAgICAgICAgIg0KICAgICAgICAgIGJhc2VkIG9uIHlvdXIgdW5kZXJzdGFuZGluZywgc3Vw cG9zZSBzdGlsbCAxMGNodW5rcyBpcyBhdmFpYmxlIGF0IHRoZSBzZXJ2ZXIgc2lkZSwgIGluIHRo ZSBwdWxsIG1vZGVsLCB0aGUgY2xpZW50IHNlbmQgMTAgcmVxdWVzdCB0byBmZXRjaCB0aGVtIGFu ZCANCiAgICAgICAgICBtYXkgcmVjZWl2ZSB0aG91c2FuZHMgb2YgcmVzcG9uc2UuIElzIGl0IHdo YXQgeW91IHNhaWQgaGVyZT8NCi4uLg0KPiBTb3JyeSBpZiAicGxheWJhY2sgdGltZSIgbWVhbnQg dGhlIGR1cmF0aW9uIG9mIHRoZSBwbGF5YmFjay4gSSByYXRoZXIgbWVhbnQgdGhlIHN0YXJ0IHRp bWUgb2YgdGhlIHBsYXliYWNrLiBTbywgaWYgYSBjbGllbnQNCj4ga2VlcHMgYSBsYXJnZXIgYnVm ZmVyIGhvcGluZyB0aGF0IGl0IHdpbGwgYXZvaWQgYnVmZmVyIHVuZGVycnVucywgdGhpcyBtYXkg ZGVsYXkgdGhlIHBsYXliYWNrIHN0YXJ0IHRpbWUuDQo+IA0KPiBbUWluXTogUmlnaHQuIFNvIHdl IG5lZWQgdG8gY2hvb3NlIGFwcHJvcG9yaWF0ZSBidWZmZXIgc2l6ZSB0byBzZWVrIGJhbGFuY2Ug YmV0d2VlbiBidWZmZXIgdW5kZXJmbG93IGFuZCBzdGFydHVwIHRpbWUNCj4gZGVsYXkuIFRoZSBi dWZmZXIgc2l6ZSBjYW4gYmUgY2hhbmdlZCBhdCBhbnkgdGltZS4NCg0KSXQgaXMgbm90IHVwIHRv IG1lIG9yIHlvdS4gQW55IGltcGxlbWVudGF0aW9uIChkZXBlbmRpbmcgb24gdGhlIGRldmljZSwg c2NlbmFyaW8sIG5ldHdvcmsgdHlwZSwgZXRjLikgY2FuIGNob29zZSBhbnkgc2l6ZSBmb3IgdGhl IGJ1ZmZlci4NCg0KW1Fpbl06IEkgdGhpbmsgaXQgaXMgb25lIGlzc3VlIHBlcnRhaW4gdG8gQnVm ZmVyIG1hbmFnZW1lbnQuIFNpbmNlIFJUUCBjYW4gaGFuZGxlIHRoaXMgc21vb3RobHksIHdoeSBu b3QgSFRUUCBzdHJlYW1pbmc/DQogDQo+IE9yLCB0aGUgY2xpZW50IGNhbiBzdGFydCB0aGUgcGxh eWJhY2sgcXVpY2tseSBhbmQgYnVpbGQgdGhlIGJ1ZmZlciBvdmVyIHRpbWUgYnkgcmVxdWVzdGlu ZyBsb3dlci1iaXRyYXRlIGNodW5rcy4NCj4gDQo+IFtRaW5dOiBJIHRoaW5rIHRoZSBwcmVzdW1w dGlvbiBpcyB0aGUgc2VydmVyIHNob3VsZCBwcmVwYXJlIG11bHRpcGxlIHN0cmVhbXMgb2YgdGhl IHNhbWUgY29udGVudCB3aXRoIGRpZmZlcmVudCBiaXRyYXRlcy4gdGhlDQo+IHNlcnZlciBtYXkg aGF2ZSBhIGJpZyBsb2FkIGlmIHRoZSBjb250ZW50IGlzIGxpdmUgY29udGVudHMuDQoNCkl0IGlz IG5vdCB0aGUgc2VydmVyIHdobyBwcmVwYXJlcyB0aGUgY29udGVudC4gTm90IG5lY2Vzc2FyaWx5 IGFuZCBub3Qgb2Z0ZW4uIFNvLCBzZXJ2aW5nIHRoZSBzYW1lIGNvbnRlbnQgYXQgZGlmZmVyZW50 IGJpdHJhdGVzIGRvZXMgbm90IHBvc2UgYW55IGV4dHJhIGxvYWQgb24gdGhlIHNlcnZlciAoZXhj ZXB0IHdoZXJlIHRoZSBjYWNoaW5nIGNvbWVzIGludG8gcGxheSkuDQoNCltRaW5dOiBZZXMsIGl0 IGRvZXMgbm90IG1hdHRlciB3aGV0aGVyIHN0cmVhbWluZyBjb21wb25lbnQgaXMgY29sbG9jYXRl ZCB3aXRoIHdlYiBzZXJ2ZXIgb3Igc2VwYXJhdGVkLg0KIA0KPiBXaGV0aGVyIGl0IHBhY2VzIHRo ZSBwcmVzZW50YXRpb24gc3BlZWQgZG93biBvciBub3QgaW4gb3JkZXIgdG8gYXZvaWQgYnVmZmVy IHVuZGVycnVucyBpcyBzb21ldGhpbmcgdXAgdG8gdGhlIGNsaWVudC4gTW9zdA0KPiBpbXBsZW1l bnRhdGlvbnMgSSBoYXZlIHNlZW4gc2ltcGx5IHN3aXRjaCB0byBhIGxvd2VyLWJpdHJhdGUgcHJv ZmlsZSB3ZWxsIGJlZm9yZSB0aGUgYnVmZmVyIGlzIGZ1bGx5IGRyYWluZWQuIFNvLCB0aGV5IGRv bid0DQo+IGV4cGVyaWVuY2UgYnVmZmVyIHVuZGVycnVucyBhbmQgdGhleSBkb26SdCBuZWVkIHRv IHBhY2UgdGhlIHZpZGVvIHByZXNlbnRhdGlvbiBzcGVlZCBkb3duLg0KPiANCj4gW1Fpbl06IEkg ZG9uJ3QgZG91YnQgZ2l2aW5nIG1vcmUgY29udHJvbCB0byBjbGllbnQgaGFzIGl0cyBhZHZhbnRh Z2VzLiBCdXQgSSB0aGluayBnaXZpbmcgc29tZSBjb250cm9sIHRvIHRoZSBzZXJ2ZXIgYWxzbyBo YXMgaXRzDQo+IGFkdmFudGFnZS4gZS5nLiwgIHlvdSBtYXkgbm90IG5lZWQgdG8gcHJlcGFyZSBt dWx0aXBsZSBzdHJlYW0gb2YgdGhlIHNhbWUgY29udGVudCB3aXRoIGRpZmZlcmVudCBiaXRyYXRl Lg0KDQpXZWxsLCBBRkFJQ1QgdGhlIG1ldGhvZCBpbiB3aGljaCBwZW9wbGUgKGluY2x1ZGluZyBt ZSkgYXJlIGludGVyZXN0ZWQgaW4gaXMgdGhpcyBzby1jYWxsZWQgbXVsdGktYml0cmF0ZSBzdHJl YW1pbmcsIHdoaWNoIGltcGxpZXMgdGhlIHNhbWUgY29udGVudCBiZWluZyBlbmNvZGVkIGF0IG11 bHRpcGxlIGJpdHJhdGVzLg0KDQpbUWluXTogSSBhbSBpbnRlcmVzdGVkIHRvby4gQnV0IEkgc3Vz cGVjdCB0aGVyZSBhcmUgb3RoZXIgd2F5cyB0byBkZWNyZWFzZSBzdWNoIG92ZXJoZWFkLiBlLmcu LCB0cmFuY29kaW5nIG1heSBiZSBiZXN0IGNob2ljZSBmb3IgbGl2ZSBjb250ZW50Lg0KDQo+IHRo ZSBzZXJ2ZXIgY29udHJvbCB0aGUgdHJhbnNtaXNzaW9uIHJhdGUgYmFzZWQgb24gdGhlIG5ldHdv cmsgY29uZGl0aW9uIGFuZCBjbGllbnQgcmVxdWlyZW1lbnRzLg0KDQpIb3cgd291bGQgdGhpcyB3 b3JrIGlmIHlvdSBoYXZlIG9ubHkgb25lIGJpdHJhdGUgb24gdGhlIHNlcnZlcj8gSXMgeW91ciBh cHByb2FjaCBhcyBmb2xsb3dzOg0KDQpSYXRoZXIgdGhhbiBvZmZlcmluZyB0aGUgc2FtZSBjb250 ZW50IGVuY29kZWQgYXQgbXVsdGlwbGUgYml0cmF0ZXMgYW5kIHNlcnZpbmcgdGhlbSBiYXNlZCBv biB3aGF0IHRoZSBjbGllbnQgd2FudHMsIHlvdSB3YW5uYSBzZXJ2ZSB0aGUgY29udGVudCBlbmNv ZGVkIGF0IGEgc2luZ2xlIGJpdHJhdGUgYW5kIGJ5IG1hbmlwdWxhdGluZyB0aGUgdHJhbnNtaXNz aW9uIHJhdGUgb24gdGhlIHNlcnZlciAoYmFzZWQgb24gc2VydmVyJ3Mga25vd2xlZGdlIG9mIG5l dHdvcmsgYW5kIGNsaWVudCksIHlvdSAiYWRhcHRpdmVseSIgc2VuZCBpdC4gSXMgdGhhdCB0aGUg c2NlbmFyaW8geW91IGhhdmUgaW4gbWluZD8NCg0KW1Fpbl06IFBlcnNvbmFsbHkgdGhhdCBpcyB3 aGF0IEkgYW0gdHJ5aW5nIHRvIGxvb2sgZm9yLiBhIHNpbmdsZSBiaXJhdGUgZm9yIGxpdmUgY29u dGVudCBtYXkgY2hhbmdlIGF0IHRpbWUgd2hpY2ggY2FuIGJlIHJlYWxpemVkIGJ5IHRyYW5zY29k aW5nLg0KDQotYWNiZWdlbg== From wenboz@google.com Fri Oct 15 00:22:04 2010 Return-Path: <wenboz@google.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956313A6C5C for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 00:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.186 X-Spam-Level: X-Spam-Status: No, score=-106.186 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cjly7KVg3By for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 00:22:02 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 53B7A3A6C57 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 00:22:01 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o9F7NLJD024303 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 00:23:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287127401; bh=Fc8FvuYcan18ijmtn8oux2P6AEg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Vs1xOF8Eku6RJosZHrs8OKCdMmJCbvgaSO2QLPhW46z31RIaGuLyd9rWX7WrqpAOm hKKFrcJABHT9hTlWl7nBQ== Received: from ywc21 (ywc21.prod.google.com [10.192.3.21]) by wpaz13.hot.corp.google.com with ESMTP id o9F7MwHb029411 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 00:23:20 -0700 Received: by ywc21 with SMTP id 21so406672ywc.2 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 00:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4WLmJJ/CfLug5/Nc2g+3JAy9G93e8V/vp1zhnrK1G8U=; b=pEsMb1Um7W/rhcqvoaCZccn5MQ/J21az6YR533ogEIFNrK8ktJmUhOIccZF7j6BAZl rkE4njcUf57q+3jG7ZXg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MN+sgVJfKRHRpXNTePh8o0k9Ie2y759Ssh3GPKGuTkJAWLRi7p0Mqve+tRgwZCdMVr xAReqstFJlr0JS/p4xbQ== MIME-Version: 1.0 Received: by 10.90.78.20 with SMTP id a20mr5431032agb.93.1287127398489; Fri, 15 Oct 2010 00:23:18 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Fri, 15 Oct 2010 00:23:18 -0700 (PDT) In-Reply-To: <02e301cb6c18$2dda7ea0$30298a0a@china.huawei.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> <029d01cb693a$7f515f50$30298a0a@china.huawei.com> <9062141B-82B8-4FF0-98C2-EB803BCA3DD7@netflix.com> <03e201cb6b6a$db1ae770$30298a0a@china.huawei.com> <B9E38A06-8392-4CCF-9160-D55F43BD75D8@netflix.com> <02e301cb6c18$2dda7ea0$30298a0a@china.huawei.com> Date: Fri, 15 Oct 2010 00:23:18 -0700 Message-ID: <AANLkTimWMndpVr1RbS70rW6WmVDe7DvhwW0Rb2RbU=kq@mail.gmail.com> From: Wenbo Zhu <wenboz@google.com> To: Qin Wu <sunseawq@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 07:22:04 -0000 Seems we are starting to talk about very specific issues here. Probably a good idea to start a separate thread, with the existing arguments summarized? On Thu, Oct 14, 2010 at 8:22 PM, Qin Wu <sunseawq@huawei.com> wrote: > =EF=BB=BF > I respect your opionion although I can't agree with you. I would like to > hear what other people thinks. Thanks! > > ----- Original Message ----- > From: Mark Watson > To: Qin Wu > Cc: Ali C. Begen (abegen) ; httpstreaming@ietf.org ; Colin Perkins > Sent: Friday, October 15, 2010 12:26 AM > Subject: Re: [httpstreaming] Current Status and Our Goal > > On Oct 14, 2010, at 2:41 PM, Qin Wu wrote: > > Hi, > > ----- Original Message ----- > From:=C2=A0Mark Watson > To:=C2=A0Qin Wu > Cc:=C2=A0Ali C. Begen (abegen)=C2=A0;=C2=A0httpstreaming@ietf.org=C2=A0;= =C2=A0Colin Perkins > Sent:=C2=A0Tuesday, October 12, 2010 12:50 AM > Subject:=C2=A0Re: [httpstreaming] Current Status and Our Goal > Some comments online ... > > Sent from my iPhone > On Oct 11, 2010, at 7:50 PM, "Qin Wu" <sunseawq@huawei.com> wrote: > > Hi, > This is what we had discussed=C2=A0 in the DISPATCH mailing list before w= e move > to this discuss list. > If you look at the description of discuss list, " > offers more efficient transport > and better network capability for real time streaming media > and allows interoperability with other streaming techniques and existing > Progressive dowloaded based > HTTP streaming implementation. > " > you will=C2=A0see we are on the same page. > Therefore one=C2=A0important goal discussed in the draft=C2=A0aims at=C2= =A0developing > interoperable solution to > provide better transport to satisfy the real time streaming QOE requireme= nt. > Especially=C2=A0serveral > chanllenges/problems=C2=A0we explored in the draft listed below. > > Regards! > -Qin > > ----- Original Message ----- > From:=C2=A0Mark Watson > To:=C2=A0Ali C. Begen (abegen) > Cc:=C2=A0httpstreaming@ietf.org=C2=A0;=C2=A0Colin Perkins > Sent:=C2=A0Sunday, October 10, 2010 7:13 AM > Subject:=C2=A0Re: [httpstreaming] Current Status and Our Goal > All, > I would like to add my support to the comments below. Specifically, I thi= nk > if the IETF considers work in this area it should focus on the HTTP and T= CP > protocols. Any such work may not be specific to HTTP-streaming (i.e. > enhancements that are at first motivated by HTTP Streaming may have broad= er > applicability, and this should be carefully considered). > In the draft I do not see a clear or correct identification of the proble= ms. > For example in the introduction the following are stated as issues: > > - Client polling for each new data in chunks using HTTP requests is > not efficient to deliver high-quality video content across the > Internet > > MW: Several companies, including my employer, are successfully operating > large scale HTTP streaming systems that do efficiently deliver high-quali= ty > video content across the Internet, so reality seems to refute this > statement. > > [Qin]: Not sure they can provide the TV experience for all the connected > devices like smartphones, PCs and tablets. Also not sure they can provide > the same quality of experence for all the all the connected devices. As w= e > discussed in this thread, a minimum of 20 seconds to start your video oft= en > frustrated users to keep on watching and provide very limited user > experience. > > Can you be more explicit about the problems that you see? I'm=C2=A0not su= re where > the 20s figure comes from. I do not see any problem in supporting startup > times comparable to TV channel change with adaptive HTTP streaming. > I am not saying there is no room for improvement in the various deployed > systems, but I do not see major technical impediments to efficient delive= ry > of high quality video using HTTP Streaming. > > [Qin]:Not only starup latency but also delay w.r.t. real time streaming. = I > think you negect it becos You didn't get into the discussion list. > > On the other hand, I think we should bear in mind HTTP is formerly design= ed > for browsing webpage, transport static contents like HTML page, plugin, > picture, when we are going to use HTTP to deliver real time streaming > contents, we can not expect to get higher user experience. Therefore the > current streaming schemes can only offer a better experience over slower > connections. > > - Segmentation capability requires over-utilizing CPU and bandwidth > resources, which may not be a desirable and effective way to improve > the quality of streaming media delivery > > MW: It is not clear that segmentation per se is CPU-intensive or has any > non-negligable effect on bandwidth usage. > > [Qin]: Since HTTP streaming server is the combination of streaming server > and regular web server, I think the answer is both. > > [MW] what do you mean by' http streaming server' ? > > [Qin]: With streaming capability and functionality to respond to HTTP > connection. > > [MW] I'm not sure what one of those is. It sounds like it is not a regula= r > web server. I think it's an essential feature of modern HTTP streaming th= at > it works with regular web infrastructure. > > - Lack of QoS guarantee on the packet switching based Internet , the > quality of Internet media streaming may significant degrade due to > rising usage > > MW: An alternative view is that where quality is degraded due to congesti= on > this is due to lack of bandwidth, rather than a lack of QoS guarantees. > Adaptive HTTP streaming systems adjust the video quality to the available > bandwidth in order to avoid rebuffering events. It is the available > bandwidth that needs to be improved to improve quality. > > [Qin]: What I emphasize here is with growing popularity of HTTP streaming > traffic, when thousands or millions of people are accessing the same medi= a > contents, the big problem we are facing is serious high concurrence acces= s > issue. The user experience will be greatly affected even you have enough > available bandwidth. So this is not pure bandwidth issue. > > [MW] maybe we mean different things by 'available bandwidth'. Do you thin= k > it is a server scalability problem, or a network problem ? > > [Qin]: please > read=C2=A0http://www.ietf.org/mail-archive/web/httpstreaming/current/msg0= 0011.html > > [MW] Still not sure what you're referring to other than available bandwid= th. > The thread mentions multicast - do you think there remains work to delive= r > HTTP objects over multicast given the work in RMT over the years ? > > - Experience burstiness or other dynamics changes due to bandwidth > fluctuations and heterogeneous handover. > > MW: We have found that adaptive HTTP streaming algorithms are well able t= o > cope with bandwidth fluctuations. > > [Qin]: I don't doubt that adaptive HTTP streaming algorithms can cope wit= h > bandwidth fluctation. But I hope we can do better.e.g., adaptive HTTP > streaming algorithms only support delivery of multiple streams of the sam= e > content with varying quality levels for different bandwidth or devices. > Howeve how the server in push model or client in pull model can quick > response to the bitrate changes is a problem we may look at,especially wh= en > switching beween streams occurs very frequently. > > [MW] Yes, but not a problem for the IETF, I think. > > [Qin]: I didn't get what you said.=C2=A0adaptive HTTP streaming algorithm= s=C2=A0is > characterized as=C2=A0 client initiated pull model. We are discussing pus= h model > or how to use pull model with push model.We are talking about different > model. There are plenty room for IETF to do for this. > > [MW] Sorry, I don't understand what the "push" model has to do with HTTP > Streaming. Are you talking about servers which are not regular HTTP serve= rs > ? I think this is not what people usually mean when they say "HTTP > streaming" - you should rename the work if that is the case. > > - Impossible to fast-forward through any part of a streaming > contents until it is stored on the user's device > > MW: This is simply not correct, since there are hundreds of examples of > devices which support trick-play using HTTP streaming techniques without > storing the whole content on the users device. > > [Qin]: Fast forward capabilty is not the most important feature we are > looking for. However I am hard to believe existing HTTP streaming techniq= ues > can provide the same degree of playbackcontrol that DVD player can provid= es > or RTSP protocol provides. E.g., In the adaptive HTTP streaming algorithm= s, > the trick play is limited to pause/resume/stop by driving the HTTP reques= t. > If the contents hasn't been dowloaded and the consume want fast forward, = the > HTTP client needs to issue another new HTTP request to fetch the contents > which willcause unacceptable latency to the consumer. > > [MW] Again, the experience of millions of existing customers refutes what > you claim. Why do you think it is necessarily so slow to issue a new HTTP > request for a different part of the content? > > [Qin]: You didn't see the reaon behind this, becos the existing customers > has no choice when they view live streaming, what they can get is close t= o > live experience rather than real time user experience. Operatoer do nothi= ng > for their network to make http streaming more controllable and managable. > Therefore more and more consumer=C2=A0tend to=C2=A0choose non-live conten= t. that's why > we see more and more non-live content consumers rather than live contents > consumers. > > [MW] Well, I'm not sure I understand the point. But still the statement i= n > the draft is not true. > ...Mark > > A first step in considering what, if any, work should be done here might = be > to contact those organizations which are standardizing the higher layers = of > HTTP streaming systems (e.g. manifest and file formats) and ask whether > there are deficiencies they see in IETF protocols that could be usefully > addressed by the IETF. What I think we should avoid in the IETF is > duplicating the work of these other bodies. > > Best, > > Mark Watson > > Netflix Inc. > > > > On Oct 10, 2010, at 12:43 AM, Ali C. Begen (abegen) wrote: > > > -----Original Message----- > > From:=C2=A0httpstreaming-bounces@ietf.org=C2=A0[mailto:httpstreaming-boun= ces@ietf.org] > On Behalf Of Lars Eggert > > Sent: Friday, October 08, 2010 4:17 PM > > To: Colin Perkins > > Cc:=C2=A0httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > On 2010-10-7, at 14:16, Colin Perkins wrote: > > There are clearly some issues to consider here. What seems to be > > missing from the discussion to me though, is some identification of > > the concrete problems. What protocol pieces do we need, but not have? > > What protocols are problematic, and need enhancement? Is there > > protocol work to do in IETF, or should we be documenting best current > > practices for using the existing protocols and/or relying on other > > bodies to fill the gaps? > > The draft-wu-http-streaming-optimization-ps is a good start at such an > > analysis, but doesn't go deep enough to let us decide what work IETF > > should do. > > +1 > > The key question really is "what do you think the IETF needs to do?" > > I imagine the only work the IETF should do (if we decide to) is the > transport and HTTP-layer optimization for better streaming performance. > > -acbegen > > Lars > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > > > > ________________________________ > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > > From yekuiwang@huawei.com Fri Oct 15 00:31:45 2010 Return-Path: <yekuiwang@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95D233A6A56 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 00:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TcjHS2508++f for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 00:31:43 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 906D63A68B9 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 00:31:43 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB006QJMB3G0@usaga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 02:33:04 -0500 (CDT) Received: from W90946 ([120.196.78.108]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB00BT6MAANF@usaga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 02:33:03 -0500 (CDT) Date: Fri, 15 Oct 2010 03:32:33 -0400 From: Ye-Kui Wang <yekuiwang@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Qin Wu' <sunseawq@huawei.com>, 'Roni Even' <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org> Message-id: <F838F912276B4CE7B5BE50E4E1460D23@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActsC2HFkm67FlBqTa+P0/kZt6Fv3AAGuVuAAARvpkA= References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 07:31:45 -0000 > > [Qin]: I don't doubt giving more control to client has its > advantages. > > But I think giving some control to the server also has its > advantage. e.g., you may not need to prepare multiple stream > of the same content with different bitrate. > > Well, AFAICT the method in which people (including me) are > interested in is this so-called multi-bitrate streaming, > which implies the same content being encoded at multiple bitrates. > > > the server control the transmission rate based on the > network condition and client requirements. > > How would this work if you have only one bitrate on the > server? Is your approach as follows: > > Rather than offering the same content encoded at multiple > bitrates and serving them based on what the client wants, you > wanna serve the content encoded at a single bitrate and by > manipulating the transmission rate on the server (based on > server's knowledge of network and client), you "adaptively" > send it. Is that the scenario you have in mind? I guess what Qin had in mind is something called "dynamic mode" of HTTP streaming, wherein there can be just one file containing all alternatives (i.e. multiple bitrates, resolutions, frame rates, etc.), as what can be stored in ISO base media file format, but the Media Presentation Description (MPD, i.e. manifest) describes the content as if it was fragmented, segmented and stored in multiple files/URLs. Upon receiving a request of a segment, the server creates the segment on-the-fly. Thus, caches and clients work as determined by the HTTP streaming spec (e.g. MPEG DASH or 3GPP AHS), but the server needs enhanced capability (and thus the mode can also be called server-enhancing mode). However, there seems no need to specify anything (as a standard) to do this. BR, YK > -----Original Message----- > From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. > Begen (abegen) > Sent: Friday, October 15, 2010 1:14 AM > To: Qin Wu; Roni Even; David A. Bryan > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal > > > But, in http streaming scenario, the ratio of download/upload (from > > the client's perspective) is much larger than 1. BTW, if > you keep your > > chunk duration relatively longer, the amount of requests > that you will end up sending will be almost nil compared to > what you will receive. > > > > [Qin]: No, I just compare pull and push with the same chunk > duration. > > You can choose whatever chunk size you wanna use. Does not > matter. The fact remains the same. Unless someone uses chunks > of a few hundreds of ms, it won't matter. > > ... > > Sorry if "playback time" meant the duration of the > playback. I rather > > meant the start time of the playback. So, if a client keeps > a larger buffer hoping that it will avoid buffer underruns, > this may delay the playback start time. > > > > [Qin]: Right. So we need to choose approporiate buffer size to seek > > balance between buffer underflow and startup time delay. > The buffer size can be changed at any time. > > It is not up to me or you. Any implementation (depending on > the device, scenario, network type, etc.) can choose any size > for the buffer. > > > Or, the client can start the playback quickly and build the > buffer over time by requesting lower-bitrate chunks. > > > > [Qin]: I think the presumption is the server should prepare > multiple > > streams of the same content with different bitrates. the > server may have a big load if the content is live contents. > > It is not the server who prepares the content. Not > necessarily and not often. So, serving the same content at > different bitrates does not pose any extra load on the server > (except where the caching comes into play). > > > Whether it paces the presentation speed down or not in > order to avoid > > buffer underruns is something up to the client. Most > implementations I > > have seen simply switch to a lower-bitrate profile well > before the buffer is fully drained. So, they don't experience > buffer underruns and they don't need to pace the video > presentation speed down. > > > > [Qin]: I don't doubt giving more control to client has its > advantages. > > But I think giving some control to the server also has its > advantage. e.g., you may not need to prepare multiple stream > of the same content with different bitrate. > > Well, AFAICT the method in which people (including me) are > interested in is this so-called multi-bitrate streaming, > which implies the same content being encoded at multiple bitrates. > > > the server control the transmission rate based on the > network condition and client requirements. > > How would this work if you have only one bitrate on the > server? Is your approach as follows: > > Rather than offering the same content encoded at multiple > bitrates and serving them based on what the client wants, you > wanna serve the content encoded at a single bitrate and by > manipulating the transmission rate on the server (based on > server's knowledge of network and client), you "adaptively" > send it. Is that the scenario you have in mind? > > -acbegen > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > From sunseawq@huawei.com Fri Oct 15 01:08:58 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE103A6A3C for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 01:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.128 X-Spam-Level: X-Spam-Status: No, score=0.128 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOrsQGjevoNL for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 01:08:43 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2BACB3A6C67 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 01:07:44 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00IZFNYSS5@szxga02-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 16:08:53 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00LUNNYS6K@szxga02-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 16:08:52 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB007PHNYREP@szxml06-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 16:08:52 +0800 (CST) Date: Fri, 15 Oct 2010 16:08:51 +0800 From: Qin Wu <sunseawq@huawei.com> To: Ye-Kui Wang <yekuiwang@huawei.com>, "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Roni Even' <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org> Message-id: <061d01cb6c40$34a89000$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <F838F912276B4CE7B5BE50E4E1460D23@china.huawei.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 08:08:58 -0000 No, we are talking about difference between pull model and push model and their advantage, disavantages. The model specified in 3GPP is just client based pull model which gives client the whole control to handle playout. Another model we need to look at is push model. The technolgoies related to this model are server push technology, websocket protcol. The difference between them is: pull model is client based solution, rely on existing web infrastructure including cache behavior, require nothing from network. push model network based solution, network should be enhanced to provide better transport and satisfy better QOE. Also I would like to point out what 3GPP is doing for this pull model is just standardizing manifest component, which is similar to Apple's draft-pantos-http-live-streaming-04 and specify how these component work in the pull model. However in the push model, this component is not neccessary. Also in the push model, the cache may be enhanced as pointed out by Wenbo Zhu. Regards! -Qin ----- Original Message ----- From: "Ye-Kui Wang" <yekuiwang@huawei.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>; "'Qin Wu'" <sunseawq@huawei.com>; "'Roni Even'" <Even.roni@huawei.com>; "'David A. Bryan'" <dbryan@ethernot.org> Cc: <httpstreaming@ietf.org> Sent: Friday, October 15, 2010 3:32 PM Subject: RE: [httpstreaming] Current Status and Our Goal > >> > [Qin]: I don't doubt giving more control to client has its >> advantages. >> > But I think giving some control to the server also has its >> advantage. e.g., you may not need to prepare multiple stream >> of the same content with different bitrate. >> >> Well, AFAICT the method in which people (including me) are >> interested in is this so-called multi-bitrate streaming, >> which implies the same content being encoded at multiple bitrates. >> >> > the server control the transmission rate based on the >> network condition and client requirements. >> >> How would this work if you have only one bitrate on the >> server? Is your approach as follows: >> >> Rather than offering the same content encoded at multiple >> bitrates and serving them based on what the client wants, you >> wanna serve the content encoded at a single bitrate and by >> manipulating the transmission rate on the server (based on >> server's knowledge of network and client), you "adaptively" >> send it. Is that the scenario you have in mind? > > I guess what Qin had in mind is something called "dynamic mode" of HTTP > streaming, wherein there can be just one file containing all alternatives > (i.e. multiple bitrates, resolutions, frame rates, etc.), as what can be > stored in ISO base media file format, but the Media Presentation Description > (MPD, i.e. manifest) describes the content as if it was fragmented, > segmented and stored in multiple files/URLs. Upon receiving a request of a > segment, the server creates the segment on-the-fly. Thus, caches and clients > work as determined by the HTTP streaming spec (e.g. MPEG DASH or 3GPP AHS), > but the server needs enhanced capability (and thus the mode can also be > called server-enhancing mode). However, there seems no need to specify > anything (as a standard) to do this. > > BR, YK > > >> -----Original Message----- >> From: httpstreaming-bounces@ietf.org >> [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. >> Begen (abegen) >> Sent: Friday, October 15, 2010 1:14 AM >> To: Qin Wu; Roni Even; David A. Bryan >> Cc: httpstreaming@ietf.org >> Subject: Re: [httpstreaming] Current Status and Our Goal >> >> > But, in http streaming scenario, the ratio of download/upload (from >> > the client's perspective) is much larger than 1. BTW, if >> you keep your >> > chunk duration relatively longer, the amount of requests >> that you will end up sending will be almost nil compared to >> what you will receive. >> > >> > [Qin]: No, I just compare pull and push with the same chunk >> duration. >> >> You can choose whatever chunk size you wanna use. Does not >> matter. The fact remains the same. Unless someone uses chunks >> of a few hundreds of ms, it won't matter. >> >> ... >> > Sorry if "playback time" meant the duration of the >> playback. I rather >> > meant the start time of the playback. So, if a client keeps >> a larger buffer hoping that it will avoid buffer underruns, >> this may delay the playback start time. >> > >> > [Qin]: Right. So we need to choose approporiate buffer size to seek >> > balance between buffer underflow and startup time delay. >> The buffer size can be changed at any time. >> >> It is not up to me or you. Any implementation (depending on >> the device, scenario, network type, etc.) can choose any size >> for the buffer. >> >> > Or, the client can start the playback quickly and build the >> buffer over time by requesting lower-bitrate chunks. >> > >> > [Qin]: I think the presumption is the server should prepare >> multiple >> > streams of the same content with different bitrates. the >> server may have a big load if the content is live contents. >> >> It is not the server who prepares the content. Not >> necessarily and not often. So, serving the same content at >> different bitrates does not pose any extra load on the server >> (except where the caching comes into play). >> >> > Whether it paces the presentation speed down or not in >> order to avoid >> > buffer underruns is something up to the client. Most >> implementations I >> > have seen simply switch to a lower-bitrate profile well >> before the buffer is fully drained. So, they don't experience >> buffer underruns and they don't need to pace the video >> presentation speed down. >> > >> > [Qin]: I don't doubt giving more control to client has its >> advantages. >> > But I think giving some control to the server also has its >> advantage. e.g., you may not need to prepare multiple stream >> of the same content with different bitrate. >> >> Well, AFAICT the method in which people (including me) are >> interested in is this so-called multi-bitrate streaming, >> which implies the same content being encoded at multiple bitrates. >> >> > the server control the transmission rate based on the >> network condition and client requirements. >> >> How would this work if you have only one bitrate on the >> server? Is your approach as follows: >> >> Rather than offering the same content encoded at multiple >> bitrates and serving them based on what the client wants, you >> wanna serve the content encoded at a single bitrate and by >> manipulating the transmission rate on the server (based on >> server's knowledge of network and client), you "adaptively" >> send it. Is that the scenario you have in mind? >> >> -acbegen >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >> > > From sunseawq@huawei.com Fri Oct 15 01:46:44 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED8D13A6C79 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 01:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_210=0.6, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj6e5dsSg3HF for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 01:46:42 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id EF7A63A6C80 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 01:46:41 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00BCHPRS30@szxga02-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 16:47:52 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00BDPPRS4S@szxga02-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 16:47:52 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB00EWYPRRU5@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 16:47:52 +0800 (CST) Date: Fri, 15 Oct 2010 16:47:51 +0800 From: Qin Wu <sunseawq@huawei.com> To: Wenbo Zhu <wenboz@google.com> Message-id: <06f001cb6c45$a6c3bca0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <B1C30D3B-6D5C-46B9-848D-3AE0C8B6058C@csperkins.org> <9690AB8A-315E-4730-ABD8-78F4BB3E4CB6@nokia.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF35F@xmb-sjc-215.amer.cisco.com> <4FFB3304-9F44-454D-9AF3-6194045F1030@netflix.com> <029d01cb693a$7f515f50$30298a0a@china.huawei.com> <9062141B-82B8-4FF0-98C2-EB803BCA3DD7@netflix.com> <03e201cb6b6a$db1ae770$30298a0a@china.huawei.com> <B9E38A06-8392-4CCF-9160-D55F43BD75D8@netflix.com> <02e301cb6c18$2dda7ea0$30298a0a@china.huawei.com> <AANLkTimWMndpVr1RbS70rW6WmVDe7DvhwW0Rb2RbU=kq@mail.gmail.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 08:46:44 -0000 U291bmRzIGxpa2UgYSBnb29kIGlkZWEgdG8gbWUsIGl0IHNlZW1zIHdlIGFyZSBidXJpZWQgaW50 byB0aGlzIHNpbmdsZSB0aHJlYWQgYW5kIGhhcmQgZm9yIHVzIHRvIGZvbGxvdyB0aGlzIGRpc2N1 c3Npb24uDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIldlbmJvIFpodSIg PHdlbmJvekBnb29nbGUuY29tPg0KVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29tPg0K Q2M6ICJNYXJrIFdhdHNvbiIgPHdhdHNvbm1AbmV0ZmxpeC5jb20+OyA8aHR0cHN0cmVhbWluZ0Bp ZXRmLm9yZz47ICJDb2xpbiBQZXJraW5zIiA8Y3NwQGNzcGVya2lucy5vcmc+DQpTZW50OiBGcmlk YXksIE9jdG9iZXIgMTUsIDIwMTAgMzoyMyBQTQ0KU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5n XSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KDQpTZWVtcyB3ZSBhcmUgc3RhcnRpbmcg dG8gdGFsayBhYm91dCB2ZXJ5IHNwZWNpZmljIGlzc3VlcyBoZXJlLg0KUHJvYmFibHkgYSBnb29k IGlkZWEgdG8gc3RhcnQgYSBzZXBhcmF0ZSB0aHJlYWQsIHdpdGggdGhlIGV4aXN0aW5nDQphcmd1 bWVudHMgc3VtbWFyaXplZD8NCg0KT24gVGh1LCBPY3QgMTQsIDIwMTAgYXQgODoyMiBQTSwgUWlu IFd1IDxzdW5zZWF3cUBodWF3ZWkuY29tPiB3cm90ZToNCj4g77u/DQo+IEkgcmVzcGVjdCB5b3Vy IG9waW9uaW9uIGFsdGhvdWdoIEkgY2FuJ3QgYWdyZWUgd2l0aCB5b3UuIEkgd291bGQgbGlrZSB0 bw0KPiBoZWFyIHdoYXQgb3RoZXIgcGVvcGxlIHRoaW5rcy4gVGhhbmtzIQ0KPg0KPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+IEZyb206IE1hcmsgV2F0c29uDQo+IFRvOiBRaW4gV3UN Cj4gQ2M6IEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSA7IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcgOyBD b2xpbiBQZXJraW5zDQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNSwgMjAxMCAxMjoyNiBBTQ0K PiBTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29h bA0KPg0KPiBPbiBPY3QgMTQsIDIwMTAsIGF0IDI6NDEgUE0sIFFpbiBXdSB3cm90ZToNCj4NCj4g SGksDQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogTWFyayBXYXRz b24NCj4gVG86IFFpbiBXdQ0KPiBDYzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pIDsgaHR0cHN0cmVh bWluZ0BpZXRmLm9yZyA7IENvbGluIFBlcmtpbnMNCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAx MiwgMjAxMCAxMjo1MCBBTQ0KPiBTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIEN1cnJlbnQg U3RhdHVzIGFuZCBPdXIgR29hbA0KPiBTb21lIGNvbW1lbnRzIG9ubGluZSAuLi4NCj4NCj4gU2Vu dCBmcm9tIG15IGlQaG9uZQ0KPiBPbiBPY3QgMTEsIDIwMTAsIGF0IDc6NTAgUE0sICJRaW4gV3Ui IDxzdW5zZWF3cUBodWF3ZWkuY29tPiB3cm90ZToNCj4NCj4gSGksDQo+IFRoaXMgaXMgd2hhdCB3 ZSBoYWQgZGlzY3Vzc2VkIGluIHRoZSBESVNQQVRDSCBtYWlsaW5nIGxpc3QgYmVmb3JlIHdlIG1v dmUNCj4gdG8gdGhpcyBkaXNjdXNzIGxpc3QuDQo+IElmIHlvdSBsb29rIGF0IHRoZSBkZXNjcmlw dGlvbiBvZiBkaXNjdXNzIGxpc3QsICINCj4gb2ZmZXJzIG1vcmUgZWZmaWNpZW50IHRyYW5zcG9y dA0KPiBhbmQgYmV0dGVyIG5ldHdvcmsgY2FwYWJpbGl0eSBmb3IgcmVhbCB0aW1lIHN0cmVhbWlu ZyBtZWRpYQ0KPiBhbmQgYWxsb3dzIGludGVyb3BlcmFiaWxpdHkgd2l0aCBvdGhlciBzdHJlYW1p bmcgdGVjaG5pcXVlcyBhbmQgZXhpc3RpbmcNCj4gUHJvZ3Jlc3NpdmUgZG93bG9hZGVkIGJhc2Vk DQo+IEhUVFAgc3RyZWFtaW5nIGltcGxlbWVudGF0aW9uLg0KPiAiDQo+IHlvdSB3aWxsIHNlZSB3 ZSBhcmUgb24gdGhlIHNhbWUgcGFnZS4NCj4gVGhlcmVmb3JlIG9uZSBpbXBvcnRhbnQgZ29hbCBk aXNjdXNzZWQgaW4gdGhlIGRyYWZ0IGFpbXMgYXQgZGV2ZWxvcGluZw0KPiBpbnRlcm9wZXJhYmxl IHNvbHV0aW9uIHRvDQo+IHByb3ZpZGUgYmV0dGVyIHRyYW5zcG9ydCB0byBzYXRpc2Z5IHRoZSBy ZWFsIHRpbWUgc3RyZWFtaW5nIFFPRSByZXF1aXJlbWVudC4NCj4gRXNwZWNpYWxseSBzZXJ2ZXJh bA0KPiBjaGFubGxlbmdlcy9wcm9ibGVtcyB3ZSBleHBsb3JlZCBpbiB0aGUgZHJhZnQgbGlzdGVk IGJlbG93Lg0KPg0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3Nh Z2UgLS0tLS0NCj4gRnJvbTogTWFyayBXYXRzb24NCj4gVG86IEFsaSBDLiBCZWdlbiAoYWJlZ2Vu KQ0KPiBDYzogaHR0cHN0cmVhbWluZ0BpZXRmLm9yZyA7IENvbGluIFBlcmtpbnMNCj4gU2VudDog U3VuZGF5LCBPY3RvYmVyIDEwLCAyMDEwIDc6MTMgQU0NCj4gU3ViamVjdDogUmU6IFtodHRwc3Ry ZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4gQWxsLA0KPiBJIHdvdWxkIGxp a2UgdG8gYWRkIG15IHN1cHBvcnQgdG8gdGhlIGNvbW1lbnRzIGJlbG93LiBTcGVjaWZpY2FsbHks IEkgdGhpbmsNCj4gaWYgdGhlIElFVEYgY29uc2lkZXJzIHdvcmsgaW4gdGhpcyBhcmVhIGl0IHNo b3VsZCBmb2N1cyBvbiB0aGUgSFRUUCBhbmQgVENQDQo+IHByb3RvY29scy4gQW55IHN1Y2ggd29y ayBtYXkgbm90IGJlIHNwZWNpZmljIHRvIEhUVFAtc3RyZWFtaW5nIChpLmUuDQo+IGVuaGFuY2Vt ZW50cyB0aGF0IGFyZSBhdCBmaXJzdCBtb3RpdmF0ZWQgYnkgSFRUUCBTdHJlYW1pbmcgbWF5IGhh dmUgYnJvYWRlcg0KPiBhcHBsaWNhYmlsaXR5LCBhbmQgdGhpcyBzaG91bGQgYmUgY2FyZWZ1bGx5 IGNvbnNpZGVyZWQpLg0KPiBJbiB0aGUgZHJhZnQgSSBkbyBub3Qgc2VlIGEgY2xlYXIgb3IgY29y cmVjdCBpZGVudGlmaWNhdGlvbiBvZiB0aGUgcHJvYmxlbXMuDQo+IEZvciBleGFtcGxlIGluIHRo ZSBpbnRyb2R1Y3Rpb24gdGhlIGZvbGxvd2luZyBhcmUgc3RhdGVkIGFzIGlzc3VlczoNCj4NCj4g ICAgLSBDbGllbnQgcG9sbGluZyBmb3IgZWFjaCBuZXcgZGF0YSBpbiBjaHVua3MgdXNpbmcgSFRU UCByZXF1ZXN0cyBpcw0KPiAgICBub3QgZWZmaWNpZW50IHRvIGRlbGl2ZXIgaGlnaC1xdWFsaXR5 IHZpZGVvIGNvbnRlbnQgYWNyb3NzIHRoZQ0KPiAgICBJbnRlcm5ldA0KPg0KPiBNVzogU2V2ZXJh bCBjb21wYW5pZXMsIGluY2x1ZGluZyBteSBlbXBsb3llciwgYXJlIHN1Y2Nlc3NmdWxseSBvcGVy YXRpbmcNCj4gbGFyZ2Ugc2NhbGUgSFRUUCBzdHJlYW1pbmcgc3lzdGVtcyB0aGF0IGRvIGVmZmlj aWVudGx5IGRlbGl2ZXIgaGlnaC1xdWFsaXR5DQo+IHZpZGVvIGNvbnRlbnQgYWNyb3NzIHRoZSBJ bnRlcm5ldCwgc28gcmVhbGl0eSBzZWVtcyB0byByZWZ1dGUgdGhpcw0KPiBzdGF0ZW1lbnQuDQo+ DQo+IFtRaW5dOiBOb3Qgc3VyZSB0aGV5IGNhbiBwcm92aWRlIHRoZSBUViBleHBlcmllbmNlIGZv ciBhbGwgdGhlIGNvbm5lY3RlZA0KPiBkZXZpY2VzIGxpa2Ugc21hcnRwaG9uZXMsIFBDcyBhbmQg dGFibGV0cy4gQWxzbyBub3Qgc3VyZSB0aGV5IGNhbiBwcm92aWRlDQo+IHRoZSBzYW1lIHF1YWxp dHkgb2YgZXhwZXJlbmNlIGZvciBhbGwgdGhlIGFsbCB0aGUgY29ubmVjdGVkIGRldmljZXMuIEFz IHdlDQo+IGRpc2N1c3NlZCBpbiB0aGlzIHRocmVhZCwgYSBtaW5pbXVtIG9mIDIwIHNlY29uZHMg dG8gc3RhcnQgeW91ciB2aWRlbyBvZnRlbg0KPiBmcnVzdHJhdGVkIHVzZXJzIHRvIGtlZXAgb24g d2F0Y2hpbmcgYW5kIHByb3ZpZGUgdmVyeSBsaW1pdGVkIHVzZXINCj4gZXhwZXJpZW5jZS4NCj4N Cj4gQ2FuIHlvdSBiZSBtb3JlIGV4cGxpY2l0IGFib3V0IHRoZSBwcm9ibGVtcyB0aGF0IHlvdSBz ZWU/IEknbSBub3Qgc3VyZSB3aGVyZQ0KPiB0aGUgMjBzIGZpZ3VyZSBjb21lcyBmcm9tLiBJIGRv IG5vdCBzZWUgYW55IHByb2JsZW0gaW4gc3VwcG9ydGluZyBzdGFydHVwDQo+IHRpbWVzIGNvbXBh cmFibGUgdG8gVFYgY2hhbm5lbCBjaGFuZ2Ugd2l0aCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZy4N Cj4gSSBhbSBub3Qgc2F5aW5nIHRoZXJlIGlzIG5vIHJvb20gZm9yIGltcHJvdmVtZW50IGluIHRo ZSB2YXJpb3VzIGRlcGxveWVkDQo+IHN5c3RlbXMsIGJ1dCBJIGRvIG5vdCBzZWUgbWFqb3IgdGVj aG5pY2FsIGltcGVkaW1lbnRzIHRvIGVmZmljaWVudCBkZWxpdmVyeQ0KPiBvZiBoaWdoIHF1YWxp dHkgdmlkZW8gdXNpbmcgSFRUUCBTdHJlYW1pbmcuDQo+DQo+IFtRaW5dOk5vdCBvbmx5IHN0YXJ1 cCBsYXRlbmN5IGJ1dCBhbHNvIGRlbGF5IHcuci50LiByZWFsIHRpbWUgc3RyZWFtaW5nLiBJDQo+ IHRoaW5rIHlvdSBuZWdlY3QgaXQgYmVjb3MgWW91IGRpZG4ndCBnZXQgaW50byB0aGUgZGlzY3Vz c2lvbiBsaXN0Lg0KPg0KPiBPbiB0aGUgb3RoZXIgaGFuZCwgSSB0aGluayB3ZSBzaG91bGQgYmVh ciBpbiBtaW5kIEhUVFAgaXMgZm9ybWVybHkgZGVzaWduZWQNCj4gZm9yIGJyb3dzaW5nIHdlYnBh Z2UsIHRyYW5zcG9ydCBzdGF0aWMgY29udGVudHMgbGlrZSBIVE1MIHBhZ2UsIHBsdWdpbiwNCj4g cGljdHVyZSwgd2hlbiB3ZSBhcmUgZ29pbmcgdG8gdXNlIEhUVFAgdG8gZGVsaXZlciByZWFsIHRp bWUgc3RyZWFtaW5nDQo+IGNvbnRlbnRzLCB3ZSBjYW4gbm90IGV4cGVjdCB0byBnZXQgaGlnaGVy IHVzZXIgZXhwZXJpZW5jZS4gVGhlcmVmb3JlIHRoZQ0KPiBjdXJyZW50IHN0cmVhbWluZyBzY2hl bWVzIGNhbiBvbmx5IG9mZmVyIGEgYmV0dGVyIGV4cGVyaWVuY2Ugb3ZlciBzbG93ZXINCj4gY29u bmVjdGlvbnMuDQo+DQo+ICAgIC0gU2VnbWVudGF0aW9uIGNhcGFiaWxpdHkgcmVxdWlyZXMgb3Zl ci11dGlsaXppbmcgQ1BVIGFuZCBiYW5kd2lkdGgNCj4gICAgcmVzb3VyY2VzLCB3aGljaCBtYXkg bm90IGJlIGEgZGVzaXJhYmxlIGFuZCBlZmZlY3RpdmUgd2F5IHRvIGltcHJvdmUNCj4gICAgdGhl IHF1YWxpdHkgb2Ygc3RyZWFtaW5nIG1lZGlhIGRlbGl2ZXJ5DQo+DQo+IE1XOiBJdCBpcyBub3Qg Y2xlYXIgdGhhdCBzZWdtZW50YXRpb24gcGVyIHNlIGlzIENQVS1pbnRlbnNpdmUgb3IgaGFzIGFu eQ0KPiBub24tbmVnbGlnYWJsZSBlZmZlY3Qgb24gYmFuZHdpZHRoIHVzYWdlLg0KPg0KPiBbUWlu XTogU2luY2UgSFRUUCBzdHJlYW1pbmcgc2VydmVyIGlzIHRoZSBjb21iaW5hdGlvbiBvZiBzdHJl YW1pbmcgc2VydmVyDQo+IGFuZCByZWd1bGFyIHdlYiBzZXJ2ZXIsIEkgdGhpbmsgdGhlIGFuc3dl ciBpcyBib3RoLg0KPg0KPiBbTVddIHdoYXQgZG8geW91IG1lYW4gYnknIGh0dHAgc3RyZWFtaW5n IHNlcnZlcicgPw0KPg0KPiBbUWluXTogV2l0aCBzdHJlYW1pbmcgY2FwYWJpbGl0eSBhbmQgZnVu Y3Rpb25hbGl0eSB0byByZXNwb25kIHRvIEhUVFANCj4gY29ubmVjdGlvbi4NCj4NCj4gW01XXSBJ J20gbm90IHN1cmUgd2hhdCBvbmUgb2YgdGhvc2UgaXMuIEl0IHNvdW5kcyBsaWtlIGl0IGlzIG5v dCBhIHJlZ3VsYXINCj4gd2ViIHNlcnZlci4gSSB0aGluayBpdCdzIGFuIGVzc2VudGlhbCBmZWF0 dXJlIG9mIG1vZGVybiBIVFRQIHN0cmVhbWluZyB0aGF0DQo+IGl0IHdvcmtzIHdpdGggcmVndWxh ciB3ZWIgaW5mcmFzdHJ1Y3R1cmUuDQo+DQo+ICAgIC0gTGFjayBvZiBRb1MgZ3VhcmFudGVlIG9u IHRoZSBwYWNrZXQgc3dpdGNoaW5nIGJhc2VkIEludGVybmV0ICwgdGhlDQo+ICAgIHF1YWxpdHkg b2YgSW50ZXJuZXQgbWVkaWEgc3RyZWFtaW5nIG1heSBzaWduaWZpY2FudCBkZWdyYWRlIGR1ZSB0 bw0KPiAgICByaXNpbmcgdXNhZ2UNCj4NCj4gTVc6IEFuIGFsdGVybmF0aXZlIHZpZXcgaXMgdGhh dCB3aGVyZSBxdWFsaXR5IGlzIGRlZ3JhZGVkIGR1ZSB0byBjb25nZXN0aW9uDQo+IHRoaXMgaXMg ZHVlIHRvIGxhY2sgb2YgYmFuZHdpZHRoLCByYXRoZXIgdGhhbiBhIGxhY2sgb2YgUW9TIGd1YXJh bnRlZXMuDQo+IEFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIHN5c3RlbXMgYWRqdXN0IHRoZSB2aWRl byBxdWFsaXR5IHRvIHRoZSBhdmFpbGFibGUNCj4gYmFuZHdpZHRoIGluIG9yZGVyIHRvIGF2b2lk IHJlYnVmZmVyaW5nIGV2ZW50cy4gSXQgaXMgdGhlIGF2YWlsYWJsZQ0KPiBiYW5kd2lkdGggdGhh dCBuZWVkcyB0byBiZSBpbXByb3ZlZCB0byBpbXByb3ZlIHF1YWxpdHkuDQo+DQo+IFtRaW5dOiBX aGF0IEkgZW1waGFzaXplIGhlcmUgaXMgd2l0aCBncm93aW5nIHBvcHVsYXJpdHkgb2YgSFRUUCBz dHJlYW1pbmcNCj4gdHJhZmZpYywgd2hlbiB0aG91c2FuZHMgb3IgbWlsbGlvbnMgb2YgcGVvcGxl IGFyZSBhY2Nlc3NpbmcgdGhlIHNhbWUgbWVkaWENCj4gY29udGVudHMsIHRoZSBiaWcgcHJvYmxl bSB3ZSBhcmUgZmFjaW5nIGlzIHNlcmlvdXMgaGlnaCBjb25jdXJyZW5jZSBhY2Nlc3MNCj4gaXNz dWUuIFRoZSB1c2VyIGV4cGVyaWVuY2Ugd2lsbCBiZSBncmVhdGx5IGFmZmVjdGVkIGV2ZW4geW91 IGhhdmUgZW5vdWdoDQo+IGF2YWlsYWJsZSBiYW5kd2lkdGguIFNvIHRoaXMgaXMgbm90IHB1cmUg YmFuZHdpZHRoIGlzc3VlLg0KPg0KPiBbTVddIG1heWJlIHdlIG1lYW4gZGlmZmVyZW50IHRoaW5n cyBieSAnYXZhaWxhYmxlIGJhbmR3aWR0aCcuIERvIHlvdSB0aGluaw0KPiBpdCBpcyBhIHNlcnZl ciBzY2FsYWJpbGl0eSBwcm9ibGVtLCBvciBhIG5ldHdvcmsgcHJvYmxlbSA/DQo+DQo+IFtRaW5d OiBwbGVhc2UNCj4gcmVhZCBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaHR0 cHN0cmVhbWluZy9jdXJyZW50L21zZzAwMDExLmh0bWwNCj4NCj4gW01XXSBTdGlsbCBub3Qgc3Vy ZSB3aGF0IHlvdSdyZSByZWZlcnJpbmcgdG8gb3RoZXIgdGhhbiBhdmFpbGFibGUgYmFuZHdpZHRo Lg0KPiBUaGUgdGhyZWFkIG1lbnRpb25zIG11bHRpY2FzdCAtIGRvIHlvdSB0aGluayB0aGVyZSBy ZW1haW5zIHdvcmsgdG8gZGVsaXZlcg0KPiBIVFRQIG9iamVjdHMgb3ZlciBtdWx0aWNhc3QgZ2l2 ZW4gdGhlIHdvcmsgaW4gUk1UIG92ZXIgdGhlIHllYXJzID8NCj4NCj4gICAgLSBFeHBlcmllbmNl IGJ1cnN0aW5lc3Mgb3Igb3RoZXIgZHluYW1pY3MgY2hhbmdlcyBkdWUgdG8gYmFuZHdpZHRoDQo+ ICAgIGZsdWN0dWF0aW9ucyBhbmQgaGV0ZXJvZ2VuZW91cyBoYW5kb3Zlci4NCj4NCj4gTVc6IFdl IGhhdmUgZm91bmQgdGhhdCBhZGFwdGl2ZSBIVFRQIHN0cmVhbWluZyBhbGdvcml0aG1zIGFyZSB3 ZWxsIGFibGUgdG8NCj4gY29wZSB3aXRoIGJhbmR3aWR0aCBmbHVjdHVhdGlvbnMuDQo+DQo+IFtR aW5dOiBJIGRvbid0IGRvdWJ0IHRoYXQgYWRhcHRpdmUgSFRUUCBzdHJlYW1pbmcgYWxnb3JpdGht cyBjYW4gY29wZSB3aXRoDQo+IGJhbmR3aWR0aCBmbHVjdGF0aW9uLiBCdXQgSSBob3BlIHdlIGNh biBkbyBiZXR0ZXIuZS5nLiwgYWRhcHRpdmUgSFRUUA0KPiBzdHJlYW1pbmcgYWxnb3JpdGhtcyBv bmx5IHN1cHBvcnQgZGVsaXZlcnkgb2YgbXVsdGlwbGUgc3RyZWFtcyBvZiB0aGUgc2FtZQ0KPiBj b250ZW50IHdpdGggdmFyeWluZyBxdWFsaXR5IGxldmVscyBmb3IgZGlmZmVyZW50IGJhbmR3aWR0 aCBvciBkZXZpY2VzLg0KPiBIb3dldmUgaG93IHRoZSBzZXJ2ZXIgaW4gcHVzaCBtb2RlbCBvciBj bGllbnQgaW4gcHVsbCBtb2RlbCBjYW4gcXVpY2sNCj4gcmVzcG9uc2UgdG8gdGhlIGJpdHJhdGUg Y2hhbmdlcyBpcyBhIHByb2JsZW0gd2UgbWF5IGxvb2sgYXQsZXNwZWNpYWxseSB3aGVuDQo+IHN3 aXRjaGluZyBiZXdlZW4gc3RyZWFtcyBvY2N1cnMgdmVyeSBmcmVxdWVudGx5Lg0KPg0KPiBbTVdd IFllcywgYnV0IG5vdCBhIHByb2JsZW0gZm9yIHRoZSBJRVRGLCBJIHRoaW5rLg0KPg0KPiBbUWlu XTogSSBkaWRuJ3QgZ2V0IHdoYXQgeW91IHNhaWQuIGFkYXB0aXZlIEhUVFAgc3RyZWFtaW5nIGFs Z29yaXRobXMgaXMNCj4gY2hhcmFjdGVyaXplZCBhcyBjbGllbnQgaW5pdGlhdGVkIHB1bGwgbW9k ZWwuIFdlIGFyZSBkaXNjdXNzaW5nIHB1c2ggbW9kZWwNCj4gb3IgaG93IHRvIHVzZSBwdWxsIG1v ZGVsIHdpdGggcHVzaCBtb2RlbC5XZSBhcmUgdGFsa2luZyBhYm91dCBkaWZmZXJlbnQNCj4gbW9k ZWwuIFRoZXJlIGFyZSBwbGVudHkgcm9vbSBmb3IgSUVURiB0byBkbyBmb3IgdGhpcy4NCj4NCj4g W01XXSBTb3JyeSwgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQgdGhlICJwdXNoIiBtb2RlbCBoYXMg dG8gZG8gd2l0aCBIVFRQDQo+IFN0cmVhbWluZy4gQXJlIHlvdSB0YWxraW5nIGFib3V0IHNlcnZl cnMgd2hpY2ggYXJlIG5vdCByZWd1bGFyIEhUVFAgc2VydmVycw0KPiA/IEkgdGhpbmsgdGhpcyBp cyBub3Qgd2hhdCBwZW9wbGUgdXN1YWxseSBtZWFuIHdoZW4gdGhleSBzYXkgIkhUVFANCj4gc3Ry ZWFtaW5nIiAtIHlvdSBzaG91bGQgcmVuYW1lIHRoZSB3b3JrIGlmIHRoYXQgaXMgdGhlIGNhc2Uu DQo+DQo+ICAgIC0gSW1wb3NzaWJsZSB0byBmYXN0LWZvcndhcmQgdGhyb3VnaCBhbnkgcGFydCBv ZiBhIHN0cmVhbWluZw0KPiAgICBjb250ZW50cyB1bnRpbCBpdCBpcyBzdG9yZWQgb24gdGhlIHVz ZXIncyBkZXZpY2UNCj4NCj4gTVc6IFRoaXMgaXMgc2ltcGx5IG5vdCBjb3JyZWN0LCBzaW5jZSB0 aGVyZSBhcmUgaHVuZHJlZHMgb2YgZXhhbXBsZXMgb2YNCj4gZGV2aWNlcyB3aGljaCBzdXBwb3J0 IHRyaWNrLXBsYXkgdXNpbmcgSFRUUCBzdHJlYW1pbmcgdGVjaG5pcXVlcyB3aXRob3V0DQo+IHN0 b3JpbmcgdGhlIHdob2xlIGNvbnRlbnQgb24gdGhlIHVzZXJzIGRldmljZS4NCj4NCj4gW1Fpbl06 IEZhc3QgZm9yd2FyZCBjYXBhYmlsdHkgaXMgbm90IHRoZSBtb3N0IGltcG9ydGFudCBmZWF0dXJl IHdlIGFyZQ0KPiBsb29raW5nIGZvci4gSG93ZXZlciBJIGFtIGhhcmQgdG8gYmVsaWV2ZSBleGlz dGluZyBIVFRQIHN0cmVhbWluZyB0ZWNobmlxdWVzDQo+IGNhbiBwcm92aWRlIHRoZSBzYW1lIGRl Z3JlZSBvZiBwbGF5YmFja2NvbnRyb2wgdGhhdCBEVkQgcGxheWVyIGNhbiBwcm92aWRlcw0KPiBv ciBSVFNQIHByb3RvY29sIHByb3ZpZGVzLiBFLmcuLCBJbiB0aGUgYWRhcHRpdmUgSFRUUCBzdHJl YW1pbmcgYWxnb3JpdGhtcywNCj4gdGhlIHRyaWNrIHBsYXkgaXMgbGltaXRlZCB0byBwYXVzZS9y ZXN1bWUvc3RvcCBieSBkcml2aW5nIHRoZSBIVFRQIHJlcXVlc3QuDQo+IElmIHRoZSBjb250ZW50 cyBoYXNuJ3QgYmVlbiBkb3dsb2FkZWQgYW5kIHRoZSBjb25zdW1lIHdhbnQgZmFzdCBmb3J3YXJk LCB0aGUNCj4gSFRUUCBjbGllbnQgbmVlZHMgdG8gaXNzdWUgYW5vdGhlciBuZXcgSFRUUCByZXF1 ZXN0IHRvIGZldGNoIHRoZSBjb250ZW50cw0KPiB3aGljaCB3aWxsY2F1c2UgdW5hY2NlcHRhYmxl IGxhdGVuY3kgdG8gdGhlIGNvbnN1bWVyLg0KPg0KPiBbTVddIEFnYWluLCB0aGUgZXhwZXJpZW5j ZSBvZiBtaWxsaW9ucyBvZiBleGlzdGluZyBjdXN0b21lcnMgcmVmdXRlcyB3aGF0DQo+IHlvdSBj bGFpbS4gV2h5IGRvIHlvdSB0aGluayBpdCBpcyBuZWNlc3NhcmlseSBzbyBzbG93IHRvIGlzc3Vl IGEgbmV3IEhUVFANCj4gcmVxdWVzdCBmb3IgYSBkaWZmZXJlbnQgcGFydCBvZiB0aGUgY29udGVu dD8NCj4NCj4gW1Fpbl06IFlvdSBkaWRuJ3Qgc2VlIHRoZSByZWFvbiBiZWhpbmQgdGhpcywgYmVj b3MgdGhlIGV4aXN0aW5nIGN1c3RvbWVycw0KPiBoYXMgbm8gY2hvaWNlIHdoZW4gdGhleSB2aWV3 IGxpdmUgc3RyZWFtaW5nLCB3aGF0IHRoZXkgY2FuIGdldCBpcyBjbG9zZSB0bw0KPiBsaXZlIGV4 cGVyaWVuY2UgcmF0aGVyIHRoYW4gcmVhbCB0aW1lIHVzZXIgZXhwZXJpZW5jZS4gT3BlcmF0b2Vy IGRvIG5vdGhpbmcNCj4gZm9yIHRoZWlyIG5ldHdvcmsgdG8gbWFrZSBodHRwIHN0cmVhbWluZyBt b3JlIGNvbnRyb2xsYWJsZSBhbmQgbWFuYWdhYmxlLg0KPiBUaGVyZWZvcmUgbW9yZSBhbmQgbW9y ZSBjb25zdW1lciB0ZW5kIHRvIGNob29zZSBub24tbGl2ZSBjb250ZW50LiB0aGF0J3Mgd2h5DQo+ IHdlIHNlZSBtb3JlIGFuZCBtb3JlIG5vbi1saXZlIGNvbnRlbnQgY29uc3VtZXJzIHJhdGhlciB0 aGFuIGxpdmUgY29udGVudHMNCj4gY29uc3VtZXJzLg0KPg0KPiBbTVddIFdlbGwsIEknbSBub3Qg c3VyZSBJIHVuZGVyc3RhbmQgdGhlIHBvaW50LiBCdXQgc3RpbGwgdGhlIHN0YXRlbWVudCBpbg0K PiB0aGUgZHJhZnQgaXMgbm90IHRydWUuDQo+IC4uLk1hcmsNCj4NCj4gQSBmaXJzdCBzdGVwIGlu IGNvbnNpZGVyaW5nIHdoYXQsIGlmIGFueSwgd29yayBzaG91bGQgYmUgZG9uZSBoZXJlIG1pZ2h0 IGJlDQo+IHRvIGNvbnRhY3QgdGhvc2Ugb3JnYW5pemF0aW9ucyB3aGljaCBhcmUgc3RhbmRhcmRp emluZyB0aGUgaGlnaGVyIGxheWVycyBvZg0KPiBIVFRQIHN0cmVhbWluZyBzeXN0ZW1zIChlLmcu IG1hbmlmZXN0IGFuZCBmaWxlIGZvcm1hdHMpIGFuZCBhc2sgd2hldGhlcg0KPiB0aGVyZSBhcmUg ZGVmaWNpZW5jaWVzIHRoZXkgc2VlIGluIElFVEYgcHJvdG9jb2xzIHRoYXQgY291bGQgYmUgdXNl ZnVsbHkNCj4gYWRkcmVzc2VkIGJ5IHRoZSBJRVRGLiBXaGF0IEkgdGhpbmsgd2Ugc2hvdWxkIGF2 b2lkIGluIHRoZSBJRVRGIGlzDQo+IGR1cGxpY2F0aW5nIHRoZSB3b3JrIG9mIHRoZXNlIG90aGVy IGJvZGllcy4NCj4NCj4gQmVzdCwNCj4NCj4gTWFyayBXYXRzb24NCj4NCj4gTmV0ZmxpeCBJbmMu DQo+DQo+DQo+DQo+IE9uIE9jdCAxMCwgMjAxMCwgYXQgMTI6NDMgQU0sIEFsaSBDLiBCZWdlbiAo YWJlZ2VuKSB3cm90ZToNCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4NCj4g RnJvbTogaHR0cHN0cmVhbWluZy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aHR0cHN0cmVhbWlu Zy1ib3VuY2VzQGlldGYub3JnXQ0KPiBPbiBCZWhhbGYgT2YgTGFycyBFZ2dlcnQNCj4NCj4gU2Vu dDogRnJpZGF5LCBPY3RvYmVyIDA4LCAyMDEwIDQ6MTcgUE0NCj4NCj4gVG86IENvbGluIFBlcmtp bnMNCj4NCj4gQ2M6IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcNCj4NCj4gU3ViamVjdDogUmU6IFto dHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCj4NCj4gT24gMjAxMC0x MC03LCBhdCAxNDoxNiwgQ29saW4gUGVya2lucyB3cm90ZToNCj4NCj4gVGhlcmUgYXJlIGNsZWFy bHkgc29tZSBpc3N1ZXMgdG8gY29uc2lkZXIgaGVyZS4gV2hhdCBzZWVtcyB0byBiZQ0KPg0KPiBt aXNzaW5nIGZyb20gdGhlIGRpc2N1c3Npb24gdG8gbWUgdGhvdWdoLCBpcyBzb21lIGlkZW50aWZp Y2F0aW9uIG9mDQo+DQo+IHRoZSBjb25jcmV0ZSBwcm9ibGVtcy4gV2hhdCBwcm90b2NvbCBwaWVj ZXMgZG8gd2UgbmVlZCwgYnV0IG5vdCBoYXZlPw0KPg0KPiBXaGF0IHByb3RvY29scyBhcmUgcHJv YmxlbWF0aWMsIGFuZCBuZWVkIGVuaGFuY2VtZW50PyBJcyB0aGVyZQ0KPg0KPiBwcm90b2NvbCB3 b3JrIHRvIGRvIGluIElFVEYsIG9yIHNob3VsZCB3ZSBiZSBkb2N1bWVudGluZyBiZXN0IGN1cnJl bnQNCj4NCj4gcHJhY3RpY2VzIGZvciB1c2luZyB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZC9v ciByZWx5aW5nIG9uIG90aGVyDQo+DQo+IGJvZGllcyB0byBmaWxsIHRoZSBnYXBzPw0KPg0KPiBU aGUgZHJhZnQtd3UtaHR0cC1zdHJlYW1pbmctb3B0aW1pemF0aW9uLXBzIGlzIGEgZ29vZCBzdGFy dCBhdCBzdWNoIGFuDQo+DQo+IGFuYWx5c2lzLCBidXQgZG9lc24ndCBnbyBkZWVwIGVub3VnaCB0 byBsZXQgdXMgZGVjaWRlIHdoYXQgd29yayBJRVRGDQo+DQo+IHNob3VsZCBkby4NCj4NCj4gKzEN Cj4NCj4gVGhlIGtleSBxdWVzdGlvbiByZWFsbHkgaXMgIndoYXQgZG8geW91IHRoaW5rIHRoZSBJ RVRGIG5lZWRzIHRvIGRvPyINCj4NCj4gSSBpbWFnaW5lIHRoZSBvbmx5IHdvcmsgdGhlIElFVEYg c2hvdWxkIGRvIChpZiB3ZSBkZWNpZGUgdG8pIGlzIHRoZQ0KPiB0cmFuc3BvcnQgYW5kIEhUVFAt bGF5ZXIgb3B0aW1pemF0aW9uIGZvciBiZXR0ZXIgc3RyZWFtaW5nIHBlcmZvcm1hbmNlLg0KPg0K PiAtYWNiZWdlbg0KPg0KPiBMYXJzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IGh0dHBzdHJlYW1pbmcgbWFpbGluZyBsaXN0DQo+IGh0dHBz dHJlYW1pbmdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9odHRwc3RyZWFtaW5nDQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IGh0dHBzdHJlYW1pbmcgbWFpbGluZyBsaXN0DQo+IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcNCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5nDQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGh0 dHBzdHJlYW1pbmcgbWFpbGluZyBsaXN0DQo+IGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5nDQo+DQo+ From ben@niven-jenkins.co.uk Fri Oct 15 01:56:02 2010 Return-Path: <ben@niven-jenkins.co.uk> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9BEA3A6C67 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 01:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.278 X-Spam-Level: X-Spam-Status: No, score=-103.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DpJi1o382pd for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 01:56:02 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id A8AC03A6C4C for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 01:56:01 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=[172.16.18.188]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1P6g6L-0007lp-AM; Fri, 15 Oct 2010 09:57:21 +0100 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk> X-Priority: 3 In-Reply-To: <051901cb6c38$8b640f30$30298a0a@china.huawei.com> Date: Fri, 15 Oct 2010 09:57:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <DAB5D58F-58D0-41EE-BBB3-A3CDBF4A23B9@niven-jenkins.co.uk> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <051901cb6c38$8b640f30$30 298a0a@china.huawei.com> To: Qin Wu <sunseawq@huawei.com> X-Mailer: Apple Mail (2.1081) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: httpstreaming@ietf.org Subject: [httpstreaming] Push Vs Pull (was Re: Current Status and Our Goal) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 08:56:03 -0000 On 15 Oct 2010, at 08:14, Qin Wu wrote: > From: "Ali C. Begen (abegen)" <abegen@cisco.com> >=20 >> But, in http streaming scenario, the ratio of download/upload (from = the client's perspective) is much larger than 1. BTW, if >> you keep your chunk duration relatively longer, the amount of = requests that you will end up sending will be almost nil >> compared to what you will receive. >>=20 >> [Qin]: No, I just compare pull and push with the same chunk duration. >=20 > You can choose whatever chunk size you wanna use. Does not matter. The = fact remains the same. Unless someone uses chunks of a few hundreds of = ms, it won't matter. >=20 > [Qin]: Suppose 10 chunks is available at the server side, in the pull = model, the client need to send at least 10 requests and receive 10 = responses. > in the push model, the client may only need to send one = request and then receive 10 responses. > comparing with pull, push model save 9 requests. > also if you look at websocket, push has more lightweight = header than pull. However, unless the request/response time or the volume of requests per = server is a significant bottleneck in the system then saving some = requests doesn't provide any advantages. Ben From sunseawq@huawei.com Fri Oct 15 02:01:51 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D8C33A6C52 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 02:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-h+aFdaNHaO for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 02:01:50 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3B0C13A6C4C for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 02:01:50 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00AC3QGX8S@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 17:02:59 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAB00GBKQGUUY@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 17:02:55 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAB00FUJQGUEQ@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 15 Oct 2010 17:02:54 +0800 (CST) Date: Fri, 15 Oct 2010 17:02:54 +0800 From: Qin Wu <sunseawq@huawei.com> To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Message-id: <076d01cb6c47$c0e10000$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <"051901cb6c38$8b640f30$3 0298a0a"@china.huawei.com> <DAB5D58F-58D0-41EE-BBB3-A3CDBF4A23B9@niven-jenkins.co.uk> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull (was Re: Current Status and Our Goal) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 09:01:51 -0000 Thank you for separate this issue out. ----- Original Message ----- From: "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk> To: "Qin Wu" <sunseawq@huawei.com> Cc: <httpstreaming@ietf.org> Sent: Friday, October 15, 2010 4:57 PM Subject: Push Vs Pull (was Re: [httpstreaming] Current Status and Our Goal) On 15 Oct 2010, at 08:14, Qin Wu wrote: > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > >> But, in http streaming scenario, the ratio of download/upload (from the client's perspective) is much larger than 1. BTW, if >> you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil >> compared to what you will receive. >> >> [Qin]: No, I just compare pull and push with the same chunk duration. > > You can choose whatever chunk size you wanna use. Does not matter. The fact remains the same. Unless someone uses chunks of a few hundreds of ms, it won't matter. > > [Qin]: Suppose 10 chunks is available at the server side, in the pull model, the client need to send at least 10 requests and receive 10 responses. > in the push model, the client may only need to send one request and then receive 10 responses. > comparing with pull, push model save 9 requests. > also if you look at websocket, push has more lightweight header than pull. However, unless the request/response time or the volume of requests per server is a significant bottleneck in the system then saving some requests doesn't provide any advantages. [Qin]: Good point. Such bottleneck could happen in case of concurrence of thousands of consumers accessing the same content. Ben From watsonm@netflix.com Fri Oct 15 02:42:34 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69BC93A68AE for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 02:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjhUewL+lZDV for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 02:42:33 -0700 (PDT) Received: from mx1.netflix.com (mx1.netflix.com [208.75.77.144]) by core3.amsl.com (Postfix) with ESMTP id 436C33A6877 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 02:42:33 -0700 (PDT) Received: from ExchFE102.netflix.com (exchfe102.netflix.com [10.64.32.102]) by mx1.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o9F9hoNx003537; Fri, 15 Oct 2010 02:43:50 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE102.netflix.com ([fe80::416e:22e0:ebdf:14b0%14]) with mapi; Fri, 15 Oct 2010 02:43:49 -0700 From: Mark Watson <watsonm@netflix.com> To: Qin Wu <sunseawq@huawei.com> Date: Fri, 15 Oct 2010 02:43:55 -0700 Thread-Topic: [httpstreaming] Push Vs Pull (was Re: Current Status and Our Goal) Thread-Index: ActsTXfgU4a1v9UVQ/ya9HkqGb4kFw== Message-ID: <8769C2D5-AC91-4DD0-A90F-88A766AB5C03@netflix.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <"051901cb6c38$8b640f30$3 0298a0a"@china.huawei.com> <DAB5D58F-58D0-41EE-BBB3-A3CDBF4A23B9@niven-jenkins.co.uk> <076d01cb6c47$c0e10000$30298a0a@china.huawei.com> In-Reply-To: <076d01cb6c47$c0e10000$30298a0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Push Vs Pull (was Re: Current Status and Our Goal) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 09:42:34 -0000 All, Now that it is clearer what technology some of the participants here would = like to consider (namely the so-called "push model"), I think it would be r= easonable to ask what specific standards they think are missing to implemen= t and deploy this technology ? What work should the IETF do ? Is it propose= d to restrict the scope to this "push model" ? (which might be reasonable, = since I do not think additional standards work is required in IETF to suppo= rt so-called "pull model"). Whatever work is proposed it is worth noting that the industry trend is ver= y much towards the "pull model". Far more media is being delivered in an ad= aptive way with that model than with the "push model". This point might be = considered when priortising this work. Neverthless, for the push model there are already multiple standards for me= dia delivery over a single HTTP connection and multiple deployed products w= hich do this, including adaptation of the video rate, by transcoding, switc= hing or otherwise. You could look at Adobe Flash for example. For real-time= adaptation from a single source you could look at Ortiva or Vantrix. I'm s= ure there are others. ...Mark On Oct 15, 2010, at 5:02 PM, Qin Wu wrote: > Thank you for separate this issue out. > ----- Original Message -----=20 > From: "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk> > To: "Qin Wu" <sunseawq@huawei.com> > Cc: <httpstreaming@ietf.org> > Sent: Friday, October 15, 2010 4:57 PM > Subject: Push Vs Pull (was Re: [httpstreaming] Current Status and Our Goa= l) >=20 >=20 >=20 > On 15 Oct 2010, at 08:14, Qin Wu wrote: >=20 >> From: "Ali C. Begen (abegen)" <abegen@cisco.com> >>=20 >>> But, in http streaming scenario, the ratio of download/upload (from the= client's perspective) is much larger than 1. BTW, if >>> you keep your chunk duration relatively longer, the amount of requests = that you will end up sending will be almost nil >>> compared to what you will receive. >>>=20 >>> [Qin]: No, I just compare pull and push with the same chunk duration. >>=20 >> You can choose whatever chunk size you wanna use. Does not matter. The f= act remains the same. Unless someone uses chunks of a few hundreds of ms, i= t won't matter. >>=20 >> [Qin]: Suppose 10 chunks is available at the server side, in the pull mo= del, the client need to send at least 10 requests and receive 10 responses. >> in the push model, the client may only need to send one request = and then receive 10 responses. >> comparing with pull, push model save 9 requests. >> also if you look at websocket, push has more lightweight header = than pull. >=20 > However, unless the request/response time or the volume of requests per s= erver is a significant bottleneck in the system then saving some requests d= oesn't provide any advantages. >=20 > [Qin]: Good point. Such bottleneck could happen in case of concurrence of= thousands of consumers accessing the same content.=20 >=20 > Ben > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From abegen@cisco.com Fri Oct 15 03:40:47 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A28CC3A6832 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 03:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTBzjJctTw8Q for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 03:40:46 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7945B3A689A for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 03:40:46 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJvMt0yrR7Hu/2dsb2JhbAChIXGgTZw+hUkEhFSJAA X-IronPort-AV: E=Sophos;i="4.57,335,1283731200"; d="scan'208";a="604444551" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2010 10:42:07 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9FAg7Do019954; Fri, 15 Oct 2010 10:42:07 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Oct 2010 03:42:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Oct 2010 03:37:13 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <051901cb6c38$8b640f30$30298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActsOI2ZTGksLTUYQ7uupUcOpwZCsgAGiwdA References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <051901cb6c38$8b640f30$30 298a0a@c hina.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Qin Wu" <sunseawq@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> X-OriginalArrivalTime: 15 Oct 2010 10:42:07.0480 (UTC) FILETIME=[9D272780:01CB6C55] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 15 Oct 2010 10:40:48 -0000 > -----Original Message----- > From: Qin Wu [mailto:sunseawq@huawei.com] > Sent: Friday, October 15, 2010 3:14 AM > To: Ali C. Begen (abegen); Roni Even; David A. Bryan > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > ----- Original Message ----- > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> > Cc: <httpstreaming@ietf.org> > Sent: Friday, October 15, 2010 1:14 PM > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 >=20 > > But, in http streaming scenario, the ratio of download/upload (from = the client's perspective) is much larger than 1. BTW, if > > you keep your chunk duration relatively longer, the amount of = requests that you will end up sending will be almost nil > > compared to what you will receive. > > > > [Qin]: No, I just compare pull and push with the same chunk = duration. >=20 > You can choose whatever chunk size you wanna use. Does not matter. The = fact remains the same. Unless someone uses > chunks of a few hundreds of ms, it won't matter. >=20 > [Qin]: Suppose 10 chunks is available at the server side, in the pull = model, the client need to send at least 10 requests and > receive 10 responses. > in the push model, the client may only need to send one = request and then receive 10 responses. > comparing with pull, push model save 9 requests. > also if you look at websocket, push has more lightweight = header than pull. > However as you said: > " > if you keep your chunk duration relatively longer, the = amount of requests that you will end up sending will be almost > nil > compared to what you will receive. > " > based on your understanding, suppose still 10chunks is = avaible at the server side, in the pull model, the client send 10 > request to fetch them and > may receive thousands of response. Is it what you said here? You missed my point. The size of the 10 request messages you sent in the = example above is not much compared to the size of the 10 chunks you = receive. And if the chunk duration gets larger, the difference will be = even bigger. > ... > > Sorry if "playback time" meant the duration of the playback. I = rather meant the start time of the playback. So, if a client > > keeps a larger buffer hoping that it will avoid buffer underruns, = this may delay the playback start time. > > > > [Qin]: Right. So we need to choose approporiate buffer size to seek = balance between buffer underflow and startup time > > delay. The buffer size can be changed at any time. >=20 > It is not up to me or you. Any implementation (depending on the = device, scenario, network type, etc.) can choose any size for > the buffer. >=20 > [Qin]: I think it is one issue pertain to Buffer management. Since RTP = can handle this smoothly, why not HTTP streaming? Sorry I am not following. RTP does not deal with this. Maybe you are = referring to RTSP streaming and then buffer duration is again something = chosen by the client not the protocol. =20 > > Or, the client can start the playback quickly and build the buffer = over time by requesting lower-bitrate chunks. > > > > [Qin]: I think the presumption is the server should prepare multiple = streams of the same content with different bitrates. the > > server may have a big load if the content is live contents. >=20 > It is not the server who prepares the content. Not necessarily and not = often. So, serving the same content at different bitrates > does not pose any extra load on the server (except where the caching = comes into play). >=20 > [Qin]: Yes, it does not matter whether streaming component is = collocated with web server or separated. >=20 > > Whether it paces the presentation speed down or not in order to = avoid buffer underruns is something up to the client. Most > > implementations I have seen simply switch to a lower-bitrate profile = well before the buffer is fully drained. So, they don't > > experience buffer underruns and they don=92t need to pace the video = presentation speed down. > > > > [Qin]: I don't doubt giving more control to client has its = advantages. But I think giving some control to the server also has its > > advantage. e.g., you may not need to prepare multiple stream of the = same content with different bitrate. >=20 > Well, AFAICT the method in which people (including me) are interested = in is this so-called multi-bitrate streaming, which > implies the same content being encoded at multiple bitrates. >=20 > [Qin]: I am interested too. But I suspect there are other ways to = decrease such overhead. e.g., trancoding may be best choice > for live content. >=20 > > the server control the transmission rate based on the network = condition and client requirements. >=20 > How would this work if you have only one bitrate on the server? Is = your approach as follows: >=20 > Rather than offering the same content encoded at multiple bitrates and = serving them based on what the client wants, you > wanna serve the content encoded at a single bitrate and by = manipulating the transmission rate on the server (based on > server's knowledge of network and client), you "adaptively" send it. = Is that the scenario you have in mind? >=20 > [Qin]: Personally that is what I am trying to look for. a single = birate for live content may change at time which can be > realized by transcoding. If you are saying a server doing transcoding for adaptation scales = better than an http server serving client requests for different chunks, = then I think you should make your arguments clear enough in the problem = statement draft and see whether others think. To me, it is a losing = proposition.=20 -acbegen From zongning@huawei.com Fri Oct 15 17:31:03 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B203A69D7 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 17:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.259 X-Spam-Level: X-Spam-Status: No, score=-100.259 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fG20XLOzP3M for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 17:30:45 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 340263A6A1D for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 17:29:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAC003RRXFMU7@szxga04-in.huawei.com> for httpstreaming@ietf.org; Sat, 16 Oct 2010 08:30:58 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAC00KSIXFMED@szxga04-in.huawei.com> for httpstreaming@ietf.org; Sat, 16 Oct 2010 08:30:58 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAC003HEXFLJ1@szxml06-in.huawei.com> for httpstreaming@ietf.org; Sat, 16 Oct 2010 08:30:58 +0800 (CST) Date: Sat, 16 Oct 2010 08:31:02 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <8769C2D5-AC91-4DD0-A90F-88A766AB5C03@netflix.com> To: 'Mark Watson' <watsonm@netflix.com>, 'Qin Wu' <sunseawq@huawei.com> Message-id: <003c01cb6cc9$69cd4e40$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActsTXfgU4a1v9UVQ/ya9HkqGb4kFwAep7+Q Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull (was Re: Current Status and Our Goal) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 16 Oct 2010 00:31:03 -0000 Hi, Mark, Please see in-line... -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Mark Watson Sent: Friday, October 15, 2010 5:44 PM To: Qin Wu Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull (was Re: Current Status and Our Goal) All, Now that it is clearer what technology some of the participants here would like to consider (namely the so-called "push model"), I think it would be reasonable to ask what specific standards they think are missing to implement and deploy this technology ? What work should the IETF do ? Is it proposed to restrict the scope to this "push model" ? (which might be reasonable, since I do not think additional standards work is required in IETF to support so-called "pull model"). [ZN] Although I agree that restricting to "push mode" might be good, I can not agree that there is no additional work to do in IETF around "pull mode". We are also talking about if there is any issue related to network transport need to be improved in the scenario of HTTP streaming - which is not push or pull problem. Whatever work is proposed it is worth noting that the industry trend is very much towards the "pull model". Far more media is being delivered in an adaptive way with that model than with the "push model". This point might be considered when priortising this work. [ZN] Again, I don't think the adaptive way has any "stronger" relation with pull mode. Neverthless, for the push model there are already multiple standards for media delivery over a single HTTP connection and multiple deployed products which do this, including adaptation of the video rate, by transcoding, switching or otherwise. You could look at Adobe Flash for example. For real-time adaptation from a single source you could look at Ortiva or Vantrix. I'm sure there are others. [ZN] Thank you for providing these pointers... ...Mark On Oct 15, 2010, at 5:02 PM, Qin Wu wrote: > Thank you for separate this issue out. > ----- Original Message ----- > From: "Ben Niven-Jenkins" <ben@niven-jenkins.co.uk> > To: "Qin Wu" <sunseawq@huawei.com> > Cc: <httpstreaming@ietf.org> > Sent: Friday, October 15, 2010 4:57 PM > Subject: Push Vs Pull (was Re: [httpstreaming] Current Status and Our Goal) > > > > On 15 Oct 2010, at 08:14, Qin Wu wrote: > >> From: "Ali C. Begen (abegen)" <abegen@cisco.com> >> >>> But, in http streaming scenario, the ratio of download/upload (from the client's perspective) is much larger than 1. BTW, if >>> you keep your chunk duration relatively longer, the amount of requests that you will end up sending will be almost nil >>> compared to what you will receive. >>> >>> [Qin]: No, I just compare pull and push with the same chunk duration. >> >> You can choose whatever chunk size you wanna use. Does not matter. The fact remains the same. Unless someone uses chunks of a few hundreds of ms, it won't matter. >> >> [Qin]: Suppose 10 chunks is available at the server side, in the pull model, the client need to send at least 10 requests and receive 10 responses. >> in the push model, the client may only need to send one request and then receive 10 responses. >> comparing with pull, push model save 9 requests. >> also if you look at websocket, push has more lightweight header than pull. > > However, unless the request/response time or the volume of requests per server is a significant bottleneck in the system then saving some requests doesn't provide any advantages. > > [Qin]: Good point. Such bottleneck could happen in case of concurrence of thousands of consumers accessing the same content. > > Ben > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From zongning@huawei.com Fri Oct 15 17:44:28 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0844A3A6983 for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 17:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.462 X-Spam-Level: X-Spam-Status: No, score=-96.462 tagged_above=-999 required=5 tests=[AWL=-3.656, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, GB_SUMOF=5, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_54=0.6, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuhNrdYGXCrs for <httpstreaming@core3.amsl.com>; Fri, 15 Oct 2010 17:44:23 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0E37E3A6981 for <httpstreaming@ietf.org>; Fri, 15 Oct 2010 17:44:23 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAC00K5EY3Y0C@szxga04-in.huawei.com> for httpstreaming@ietf.org; Sat, 16 Oct 2010 08:45:35 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAC007CLY3Y5B@szxga04-in.huawei.com> for httpstreaming@ietf.org; Sat, 16 Oct 2010 08:45:34 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAC0037WY3YJ1@szxml06-in.huawei.com> for httpstreaming@ietf.org; Sat, 16 Oct 2010 08:45:34 +0800 (CST) Date: Sat, 16 Oct 2010 08:45:33 +0800 From: Ning Zong <zongning@huawei.com> To: httpstreaming@ietf.org Message-id: <003d01cb6ccb$70a6eda0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_iOZfe3zyt8oyb1Pj9k8ErQ)" Thread-index: Actsx8wtVdITg8CTSR+IiOVhjYIipwAAcA4w Subject: [httpstreaming] Survey and Gap Analysis Draft // FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-00 X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 16 Oct 2010 00:44:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_iOZfe3zyt8oyb1Pj9k8ErQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Folks, Please check the attached -00 draft on "Survey and Gap Analysis for HTTP Streaming Standards and Implementations". Also, URI is as below: http://www.ietf.org/id/draft-zong-httpstreaming-gap-analysis-00.txt The goal of this draft is two folded: 1) give a brief survey to clarify the scope of existing HTTP streaming standards (3GPP/OIPF/etc) and implementations (MS/Adobe/Apple); 2) analyze the potential challenge to HTTP streaming, especially from the network perspective and tends to outline the possible work in IETF. For those who are not very familiar with the current standard work in 3GPP/OIPF/MPEG, I hope this draft would help to clarify. For those who are still confused about the possible overlap between existing work and potential work in IETF, I hope we can discuss the gap here... BR, Ning Zong -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Saturday, October 16, 2010 8:18 AM To: zongning@huawei.com Subject: New Version Notification for draft-zong-httpstreaming-gap-analysis-00 A new version of I-D, draft-zong-httpstreaming-gap-analysis-00.txt has been successfully submitted by Ning Zong and posted to the IETF repository. Filename: draft-zong-httpstreaming-gap-analysis Revision: 00 Title: Survey and Gap Analysis for HTTP Streaming Standards and Implementations Creation_date: 2010-10-15 WG ID: Independent Submission Number_of_pages: 23 Abstract: With the explosive growth of the Internet usage and increasing demand for multimedia information on the web, media delivery over Internet attract substantial attention from media industry. To meet above requirements, HTTP Streaming technology is designed and gradually plays an important role in recent years. Several leading Standard Development Organizations (SDOs) have been producing a series of technical specifications to define streaming over HTTP. Moreover, several companies have devoted to developing private HTTP-based media delivery platform to provide high quality, adaptive viewing experience to customers. Following a brief survey of existing HTTP streaming standards and implementations, this document gives a brief summary on these related work, analyzes the potential challenges especially from the network point of view, and lists the gap between existing work and possible working scope on the topic of HTTP streaming in IETF. The IETF Secretariat. --Boundary_(ID_iOZfe3zyt8oyb1Pj9k8ErQ) Content-type: text/plain; name=draft-zong-httpstreaming-gap-analysis-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-zong-httpstreaming-gap-analysis-00.txt Network Working Group N. Zong Internet-Draft Huawei Technologies Intended status: Informational October 15, 2010 Expires: April 18, 2011 Survey and Gap Analysis for HTTP Streaming Standards and Implementations draft-zong-httpstreaming-gap-analysis-00 Abstract With the explosive growth of the Internet usage and increasing demand for multimedia information on the web, media delivery over Internet attract substantial attention from media industry. To meet above requirements, HTTP Streaming technology is designed and gradually plays an important role in recent years. Several leading Standard Development Organizations (SDOs) have been producing a series of technical specifications to define streaming over HTTP. Moreover, several companies have devoted to developing private HTTP-based media delivery platform to provide high quality, adaptive viewing experience to customers. Following a brief survey of existing HTTP streaming standards and implementations, this document gives a brief summary on these related work, analyzes the potential challenges especially from the network point of view, and lists the gap between existing work and possible working scope on the topic of HTTP streaming in IETF. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Zong Expires April 18, 2011 [Page 1] Internet-Draft Survey and Gap Analysis October 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Zong Expires April 18, 2011 [Page 2] Internet-Draft Survey and Gap Analysis October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. HTTP Streaming Standards . . . . . . . . . . . . . . . . . . . 6 3.1. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Media Presentation Components . . . . . . . . . . . . 6 3.1.2. Media Presentation Description . . . . . . . . . . . . 8 3.1.3. Streaming Procedure . . . . . . . . . . . . . . . . . 9 3.1.3.1. Overview . . . . . . . . . . . . . . . . . . . . . 9 3.1.3.2. Segment list generation . . . . . . . . . . . . . 10 3.1.3.3. Seeking, trick mode and adaptation support . . . . 10 3.2. OIPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. MPD . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Segmentation . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Media formats for MPEG2-TS . . . . . . . . . . . . . . 11 3.2.4. Use cases . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4.1. Live streaming . . . . . . . . . . . . . . . . . . 12 3.2.4.2. Trick mode and seeking . . . . . . . . . . . . . . 12 3.3. MPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Objectives . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. Requirements for proposal . . . . . . . . . . . . . . 13 4. HTTP Streaming Implementations . . . . . . . . . . . . . . . . 14 4.1. Microsoft Smooth Streaming . . . . . . . . . . . . . . . . 14 4.1.1. On-disk MP4 file format . . . . . . . . . . . . . . . 15 4.1.2. On-wire segments transmission . . . . . . . . . . . . 15 4.1.3. Adaptative support . . . . . . . . . . . . . . . . . . 16 4.2. Adobe . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Components . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Top features . . . . . . . . . . . . . . . . . . . . . 17 4.3. Apple . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.1. Basic process . . . . . . . . . . . . . . . . . . . . 18 5. Gap Analysys . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Brief Summary of Exitsting Work . . . . . . . . . . . . . 19 5.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Gap List and Potential Working Scope in IETF . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Zong Expires April 18, 2011 [Page 3] Internet-Draft Survey and Gap Analysis October 2010 1. Introduction Media streaming have played increasingly important role in Internet content deliveries, and are becoming indispensable in many applications (e.g., distance learning, digital libraries, home shopping, and video-on-demand). Currently, several streaming protocols are commonly used to deliver media content on Internet, such as HTTP, RTSP/RTP, RTMP, MMS, etc. HTTP streaming, one of above listed protocols, is rapidly becoming one of the most commonly used approach for media content distribution on the Internet. HTTP streaming is a mechanism for sending media data/file, which is divided into several chunks/fragments and supply them in order to user through port 80/8080. HTTP streaming includes various streaming media formats/codec including MP4, MPEG2-TS, H.264/ AAC, etc., and streaming services over HTTP, such as Windows Media/ Silver Light Streaming, Flash Video, QuickTime Streaming Server, Real Media Streaming and others. HTTP streaming offers two advantages as below: 1) Media protocols often have difficulty getting around firewalls and routers because they are commonly based on UDP sockets over unusual port numbers. HTTP-based media delivery has no such problems because firewalls and routers know to pass HTTP downloads through port 80. 2) HTTP media delivery has the ability to use standard HTTP servers and standard HTTP caches (or cheap servers in general) to deliver the content, so that it doesn't require special proxies or caches. Additionally, most Content Delivery Network (CDN) make use of HTTP to redirect request, retrieve cached multimedia object, and communicate policy servers. Several leading Standard Development Organizations (SDOs) have been producing a series of technical specifications to define streaming over HTTP. 3GPP introduces adaptive HTTP streaming in Technical Specification (TS) 26.234 [3GPP], where HTTP streaming is introduced in detail including Media Presentation Description (MPD), Media Segmentation Format, HTTP server and client behavior, etc., as an alternative approach to the RTSP/RTP based media delivery. Open IPTV Forum (OIPF) introduces HTTP adaptive streaming in its technical Specification [OIPF], which defines the usage of and extensions to 3GPP HTTP streaming to enable HTTP based Adaptive Streaming for OIPF compliant services and devices. Recently, ISO/IEC JTC1/SC29/WG11 (MPEG) launched a new standard on HTTP streaming. A bunch of documents [MPEG-1][MPEG-2][MPEG-3][MPEG-4] have been proposed to address the backgroud, objectives, use cases and requriements of the transport of MPEG media over HTTP. Zong Expires April 18, 2011 [Page 4] Internet-Draft Survey and Gap Analysis October 2010 Several companies have devoted to developing private HTTP-based media delivery platform to provide high quality, adaptive viewing experience to customers. Microsoft has implemented its Smooth Streaming technology, which is a web-base, adaptive media content delivery approach that uses standard HTTP [MS-IIS]. Instead of delivering media as full-file download, in Smooth Streaming, the content is delivered to client as a series of small file chunks that can be easily cached at edge servers, closer to client. Adobe HTTP Dynamic Streaming is a new Adobe-defined delivery method for enabling on-demand and live adaptive bitrate video streaming over regular HTTP connections [Adobe]. Adobe HTTP Dynamic Streaming packages media files into fragments that Flash Player clients can access instantly without downloading the entire file. Apple HTTP Live Streaming [Apple] allows to send live or prerecorded audio and video to iPhone or other devices, such as desktop computers, using an ordinary Web server, with support of adaptive bitrate. Following a brief survey of the above mentioned existing HTTP streaming standards and implementations, this document gives a brief summary on these related work, analyzes the potential challenges especially from the network point of view, and lists the gap between existing work and possible working scope on the topic of HTTP streaming in IETF. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. Live Streaming: Live events can be streamed over the Internet with the help of broadcast software which encodes the live source - from a microphone, video camera, or other recording device and delivers the resulting stream to the server. The server then transfers the stream. So the user experiences the event as it happens. On-Demand Streaming: To provide "anytime" access to media content, client is allowed to select and playback on demand. Progressive Download: A mode that allow client playback the media file while the file is downloading, after only a few seconds wait for buffering, the process of collecting the first part of a media file before playing. Adaptive Streaming: Adaptive streaming is a process that adjusts the quality of a video delivered to a client based on the changing Zong Expires April 18, 2011 [Page 5] Internet-Draft Survey and Gap Analysis October 2010 network conditions to ensure the best possible viewer experience. 3. HTTP Streaming Standards 3.1. 3GPP 3GPP introduces adaptive HTTP streaming in Technical Specification (TS) 26.234 [3GPP]. TS 26.234 specifies the protocols and codecs for the Packet-Switched Steaming Service (PSS) within the 3GPP system. Protocols for control signalling, capability exchange, media transport, rate adaptation and protection are specified. Codecs for speech, natural and synthetic audio, video, still images, bitmap graphics, vector graphics, timed text and text are specified. The delivery of media over HTTP provides an alternative delivery mechanism to the RTSP/RTP based media delivery. It is assumed that the HTTP-Streaming Client has access to a Media Presentation Description (MPD). An MPD provides sufficient information for the HTTP-Streaming Client to provide a streaming service to the user by sequentially downloading media data from an HTTP server and rendering the included media appropriately. 3.1.1. Media Presentation Components A media presentation is a structured collection of data that is accessible to the HTTP-Streaming Client, which is described in a MPD. The media presentation structure is shown in the following figure. Zong Expires April 18, 2011 [Page 6] Internet-Draft Survey and Gap Analysis October 2010 ^ resultion / bit-rate / language / etc | | representation | +------------------------------------------------+ | | segment segment | | | +----------------------------+ +-----+ | | | | +----------+ +----------+ | | | | | | | | meta | | media | | | | | | | | | data | | data | | | | ... ...| | | | +----------+ +----------+ | | | | | | +----------------------------+ +-----+ | | +------------------------------------------------+ | | +------------------------------------------------+ | | representation | | +------------------------------------------------+ | ... ... | +------------------------------------------------+ | | representation | | +------------------------------------------------+ | period 1 period2 ... +-------------------------------------------------------------------> time A media presentation consists of: 1) A sequence of Periods. 2) Each Period contains one or more Representations from the same media content. Different Representations usually have different attributes on media resolution, bit-rate, language, etc. 3) Each Representation consists of one or more segments. 4) Segments contain media data and/or metadata to decode and present the included media data and is defined as a unit that can be uniquely referenced by an http-URL element in the MPD. The Initialisation Segment contains initialisation information (no media data) for accessing the Representation. A Media Segment contains media data that are described either within this Media Segment or by the Initialisation Segment. The segment has a start time relative to the start time of the representation (period) such that the client can download a specific segment. The segment provides random access information, namely if and how you can randomly access the media within this segment. There is no requirement that a segment starts with a random access point (RAP). But it is possible that all segments start with a RAP. Zong Expires April 18, 2011 [Page 7] Internet-Draft Survey and Gap Analysis October 2010 3.1.2. Media Presentation Description The logic structure of media presentation is actually described as the data structure (e.g. xml schema) in MPD file. That is, the MDP contains metadata required by the client to construct appropriate URIs to access segments and to provide the streaming service to the user. Several important attributes and elements contained in a MPD are listed as below: 1) "type" attribute: type of the media presentation, i.e. VOD or live. 2) "availabilityStartTime" attribute: media presentation start time if "type"=live. If "type"=VoD, media presentation start time is 0. 3) "duration" attribute: duration/length of the media presentation. For live presentation, the sum of "duration" and "availabilityStart" specifies the end time of the media presentation. If "duration" is not provided, then the MPD does not describe an entire media presentation and the MPD may be updated during live presentation. 4) "minimumUpdatePeriodMPD" attribute: minimum MPD update period. 5) "timeShiftBufferDepth" attribute: duration of time shifting buffer maintained at the server for live presentation. This attribute will be used in the case of trick mode. 6) "minBufferTime" attribute: minimum buffer time for the stream. 7) Multiple "Period" element: describe a period. A "Period" element contains the following important attributes and elements: 7.1) "start" attribute: start time of this period. 7.2) Multiple "Representation" element: describe a representation with different bit-rate, resolution, language, etc. A "Representation" element contains the following important attributes and elements: 7.2.1) "bandwidth" attribute: maximum bit-rate of the representation averaged over any interval of "minBufferTime" duration. 7.2.2) "startWithRAP" attribute: When True, indicates that all segments in the representation start with a random access point (RAP). Zong Expires April 18, 2011 [Page 8] Internet-Draft Survey and Gap Analysis October 2010 7.2.3) "qualityRanking" attribute: quality ranking of the representation. 7.2.4) "TrickMode" element: provides the information for trick mode. In this element, "AlternatePlayoutRate" attribute denotes the playout speed as a multiple of the regular playout speed. 7.2.5) "SegmentInfo" element: describe all segments in a representation. Each "SegmentInfo" element permits generating a list of Media Segment URLs (possibly with a byte range) and Media Segment start times relative to the start time of the Representation. A "SegmentInfo" element contains the following important attributes and elements: 7.2.5.1) "duration" attribute: gives the constant approximate segment duration. 7.2.5.2) at most one "InitialisationSegmentURL" element. If not present, then each media segment within this representation shall be self-initialising. 7.2.5.3) either a URLtemplate" element that specifies a default segment URL template for all segments, or one or more "Url" elements that provides a set of explicit URL(s) for segments. Note that a client derives the request-for-MPD-update time as the sum of the time of its last requested update of the MPD and the "minimumUpdatePeriodMPD" attribute. 3.1.3. Streaming Procedure 3.1.3.1. Overview Initially, the client parses the MPD and creates an segment list for each representation. Then the client selects one representation based on the information in the representation attributes and other information, e.g. available bandwidth, client capabilities. Client acquires initialisation segments and the media segments of the selected representation by using the generated segment list. Client continues consuming the media content by continuously requesting media segments taking into account the MPD update. Client may change representations taking into account updated MPD information and/or updated information from its environment, e.g. access bit-rate changes. Zong Expires April 18, 2011 [Page 9] Internet-Draft Survey and Gap Analysis October 2010 3.1.3.2. Segment list generation A list contains: 1) URL to initialization segment; 2) URLs to media segments; 3) start times to media segments in the period. There are two approaches for generating segment list. One is template based generation, that is to utilize the "URLtemplate" and "duration" attributes in "SegmentInfo" element in MPD. Another is play-list based generation, that is to utilize the "URLs" and "duration" in "SegmentInfo" element in MPD. 3.1.3.3. Seeking, trick mode and adaptation support Suppose that the client wants to seek to time "tp", the corresponding segment can be searched by the server through: Target_segment_index = max { i | MediaSegment[i].StartTime <= tp- Period.start }. For accurate seeking to time "tp", client needs to access a RAP. Client may use the information in the 'sidx' to locate the RAP and the corresponding presentation time in the media presentation. For fast start-up, client may initially request the 'sidx' box from the beginning of the media segment using byte range requests. Trick mode can be implemented by utilizing the "AlternatePlayoutRate" attribute in "TrickMode" element in MPD. Switching to a new representation is equivalent to seeking to the new representation. Client should seek to a RAP in the new representation at a desired presentation time "tp" later than current presentation time. 3.2. OIPF Open IPTV Forum (OIPF) introduces HTTP adaptive streaming in its technical Specification [OIPF]. This specification defines the usage of and, where necessary, extensions to the technologies defined in 3GPP TS 26.234 to enable HTTP based Adaptive Streaming for Release 2 OIPF compliant services and devices. Most details on HTTP adaptive streaming in this specification is based on 3GPP TS 26.234. The extensions and designs speficic to OIPF are introduced in this document. 3.2.1. MPD A Representation may be made up of multiple components, for example audio, video. A partial Representation may only contain some of these components and a terminal may need to download (and play) multiple partial Representations to build up a complete Representation, with the appropriate components according to the preferences and wishes of the user. Accordingly, in MPD, the Zong Expires April 18, 2011 [Page 10] Internet-Draft Survey and Gap Analysis October 2010 "Representation" element may consist of one or more Components which may be downloaded and provided to the terminal in addition to content being downloaded from other "Representation" elements. In this case the "Representation" element in MPD SHALL contain one or more "Component" elements. The "Representation" element in MPD may carry a "group" attribute. The value of the "group" attribute SHALL be the same for Representations that contain at least one same Component. Two Representations with completely different Components (e.g. audio at two different languages) SHALL have different values for the "group" attribute. To provide nPVR functionality, when the Segments of the live Content are stored on the nPVR server, the URLs indicating the Segments on the nPVR server SHOULD be provided to the OIPF to enable it to access these Segments by the MPD update mechanism defined in 3GPP TS 26.234. 3.2.2. Segmentation Each Segment SHALL start with a random access point (RAP). Moreover, to enable seamless switching: 1) Different Component Streams of the same Component SHALL be encoded in the same media format but MAY be different in the profile of that format. (e.g., if a Representation contains a Component Stream of a certain video Component that is encoded using H.264/AVC using the HD profile, then all other Representations that have a Component Stream of that Component must use H.264/AVC but may use different configurations within the HD profile.) 2) Segments of Representations with the same value for the "group" attribute SHALL be time aligned. 3.2.3. Media formats for MPEG2-TS Component Streams of the same Component (e.g. "video angle 1 in H.264 at 720x576" and "video angle 1 in H.264 at 320x288") SHALL be carried in transport stream packets that have the same PID. When the Segments of a Representation contain MPEG-2 TS packets, the value of the "id" attribute in each Component element, if present, SHALL be the PID of the Transport Stream packets which carry the Component. For all Representations, the PAT and PMT are either contained in the initialisation Segments or in the media Segments. The Representations with zero "group" attribute will have the same PAT/ PMT as Representations with non-zero "group" attribute. Zong Expires April 18, 2011 [Page 11] Internet-Draft Survey and Gap Analysis October 2010 A media Segment SHALL contain the concatenation of one or several contiguous (and complete) PES packets which are split and encapsulated into TS packets. When packetizing video elementary streams, up to one frame SHALL be included into one PES packet. The PES packet where a frame starts SHALL always contain a PTS/DTS header fields in the PES header. 3.2.4. Use cases 3.2.4.1. Live streaming If the "timeShiftBufferDepth" attribute is present in the MPD, it may be used by the terminal to know at any moment which Segments are effectively available for downloading with the current MPD. If this timeshift information is not present in the MPD, the terminal may assume that all Segments described in the MPD which are already in the past are available for downloading. Periods may be used in the live streaming scenario to appropriately describe successive live events with different encoding or adaptive streaming properties. 3.2.4.2. Trick mode and seeking Basic implementation of trick modes is based on the processing of Segments by the terminal software: downloaded Segments may be provided to the decoder at a speed lower or higher than normal. The playback of Segments in fast forward and fast rewind has an immediate effect on the bitrate, because the Segments also need to be downloaded at a faster rate than normal. Dedicated streams may be used to implement efficient trick modes: it is recommended to produce the streams with a lower frame rate, longer Segments or a lower resolution to ensure that the bitrate is kept at a reasonable level even when the Segment is downloaded at a faster rate. The dedicated stream is described as Representation with a "TrickMode" element in the MPD. It is also recommended that if there are dedicated fast forward Representations, the normal Representations do not contain the "TrickMode" element in the MPD. To determine the random access point in a media Segment, the client should download and search RAP one by one till the required RAP is found. 3.3. MPEG Recently, ISO/IEC JTC1/SC29/WG11 (MPEG) launched a new standard on HTTP streaming. A series of proposals [MPEG-1][MPEG-2][MPEG-3][MPEG-4] have been proposed to address the backgroud, objectives, use cases and requriements of the transport of MPEG media over HTTP, as well as call-for-propsal on this topic. Zong Expires April 18, 2011 [Page 12] Internet-Draft Survey and Gap Analysis October 2010 3.3.1. Objectives The main objectives of this new standard are: 1) Efficient delivery of MPEG media over HTTP in an adaptive, progressive, download/streaming fashion. 2) Support of live streaming of multimedia content. 3) Efficient and ease of use of existing content distribution infrastructure components such as CDNs, proxies, caches, NATs and firewalls. 4) Support of integrated services with multiple components. 5) Support for signaling, delivery, utilization of multiple content protection and rights management schemes, and support for efficient content forwarding and relay. 3.3.2. Requirements for proposal A list of requirements on HTTP streaming are ecouraged by MPEG. Only those related to media delivery are introduced as follows. 1) This standard shall support streaming of content and content components over HTTP 1.1. 2) The media files prepared for this standard should be deliverable using progressive download with minimal changes. 3) This standard shall support streaming of live content of possibly indefinite length, including PVR functionalities such as pause and time-shifted play. 4) The standard shall support random access (seeking). 5) The standard shall support trick modes at least to the extent that the underlying formats support them in local playback. 6) The standard shall not require any extension to HTTP 1.1. It shall support the efficient use of HTTP optimized infrastructures such as Content Delivery Networks (CDNs), caches and proxies. 7) The standard shall allow segmentation of the content. The standard shall not require fixed size or fixed duration segments during delivery of content. Zong Expires April 18, 2011 [Page 13] Internet-Draft Survey and Gap Analysis October 2010 8) The standard should introduce minimal transport overhead and should incur minimal presentation startup delay. 9) The standard shall support description of media components for delivery and presentation. 10) The standard shall support interactive selection of media components for delivery and presentation, for example view selection in multi-view content. 11) This standard shall support prioritization of content and content components. 12) This standard shall support signaling the relationship among content components. 13) The standard should support network transition during delivery of the content. 14) The standard shall enable adaptation of content along axes such as bitrate, temporal resolution, spatial resolution, quality/ fidelity or view perspective. 15) The standard shall support initial selection, and dynamic adaptation of the content without presentation interruption during delivery. 4. HTTP Streaming Implementations 4.1. Microsoft Smooth Streaming Smooth Streaming is Microsoft implementation of adaptive streaming technology, which is a web-base media content delivery that uses standard HTTP [MS-IIS]. Instead of delivering media as full-file download, or as progressive download, the content is delivered to client as a series of small file chunks that can be easily and cheaply cached at edge servers, closer to client. Smooth Streaming defines each chunk/GOP as an MPEG-4 Movie Fragment and stores it within a contiguous MP4 file for easy random access. One MP4 file is expected for each bit rate. Because the media is "virtually" split into fragment files, the server must translate sequential URL requests into exact byte range offsets within the MP4 file. Server extracts the fragment box and sends it over the wire to the client as a standalone file. Zong Expires April 18, 2011 [Page 14] Internet-Draft Survey and Gap Analysis October 2010 4.1.1. On-disk MP4 file format +-------------------------------------------------------------------+ | +----+ +---------------------+ +--------------+ +------+ +------+ | | | | | Movie Metadata(moov)| |Movie Fragment| |Media | |Movie | | | |file| |+-----++-----++-----+| | (moof) | |Data | |Frag | | | |type| ||Movie||Track||Movie|| |+----+ +-----+| |(mdat)| |Random| | | | | ||hdr || ||Ext. || ||Frag| |Track|| | | |Access| | | | | || || || || ||hdr | |Frag || | | |(mfra)| | | | | || || || || || | | || | | | | | | | | |+-----++-----++-----+| |+----+ +-----+| | | | | | | +----+ +---------------------+ +--------------+ +------+ +------+ | +-------------------------------------------------------------------+ In a nutshell, the MP4 file starts with file-level metadata ('moov') that generically describes the file, but the bulk of the payload is actually contained in the fragment boxes that also carry more accurate fragment-level metadata ('moof') and media data ('mdat'). Closing the file is an 'mfra' index box that allows easy and accurate seeking within the file. In Smooth Streaming, the MP4 files are classified into two kinds. One is *.ismv file containing video and audio. Another is *.isma containing audio only. Beside media files, there are manifest files. Server manifest file (*.ism) describes the relationships between the media tracks, bit rates and files on disk. Client manifest file (*.ismc) describes the available streams to the client: the codecs used, bit rates encoded, video resolutions, markers, captions, etc. 4.1.2. On-wire segments transmission Initially, the client requests the *.ismc client manifest from the server. Client then requests fragments in the form of a URL, e.g., h ttp://video.foo.com/NBA.ism/QualityLevels(400000)/ Fragments(video=610275114). Server then looks up the quality level (bit rate) in the corresponding *.ism server manifest and maps it to a physical *.ismv or *.isma file on disk. Server reads the appropriate MP4 file, and based on its 'tfra' index box, figures out which fragment box ('moof' + 'mdat') corresponds to the requested start time offset. Server extracts the fragment box and sends it over the wire to the client as a standalone file. The sent fragment/ file can now be automatically cached further down the network, potentially saving the origin server from sending the same fragment/ file again to another client that requests the same URL. Zong Expires April 18, 2011 [Page 15] Internet-Draft Survey and Gap Analysis October 2010 4.1.3. Adaptative support Smooth Streaming provides multiple encoded bit rates of the same media source and thus allow client to seamlessly switch between bit rates. As client plays chunks, network condition may change or media processing may be impacted by other applications. Client can immediately request the next chunk come from stream that is encoded at a different bit rate to accommodate changing conditions. This enables client to play media without any stuttering, buffering and freezing, thereby providing fittest-quality playback to client. 4.2. Adobe Adobe HTTP Dynamic Streaming is a new Adobe-defined delivery method for enabling on-demand and live adaptive bitrate video streaming over regular HTTP connections [Adobe]. HTTP Dynamic Streaming packages media files into fragments that Flash Player clients can access instantly without downloading the entire file. Adobe HTTP Dynamic Streaming contains several components that work together to package media and stream it over HTTP to Flash Player. 4.2.1. Components File Packagers include Live Packager and VoD Packager. VoD Packager translates on-demand media files into fragments and writes the fragments to F4F files. Live Packager translates ingested live streams over Real Time Messaging Protocol (RTMP) into F4F files in real-time. HTTP Origin Module is an Apache HTTP Server module that serves the F4F files created by the File Packagers. The F4F file format describes how to divide media content into segments and fragments. Each fragment has its own bootstrap information that provides cache management and fast seeking. The F4M Manifest file format contains information about a package of files that the HTTP Origin Module can serve. Manifest information includes codecs, resolutions, and the availability of files encoded at multiple bit rates. 4.2.2. Workflow HTTP Dynamic Streaming workflow includes content preparation which write media fragments into files, distribution of files over HTTP, media consumption and protection, etc. Zong Expires April 18, 2011 [Page 16] Internet-Draft Survey and Gap Analysis October 2010 +--------+ +-------+ +-------+ +------+ | | | | | | | | Live | |F4F/F4M | | | | | | streaming|File |Files | HTTP |HTTP | HTTP |HTTP |Client| -------->|Packager|------->| Origin|Delivery| Cache/|Delivery|Appl. | | | | Module|------->| CDN |------->| | VoD | | | | | | | | content | | | | | | | | -------->| | | | | | | | +--------+ +-------+ +-------+ +------+ 4.2.3. Top features HTTP Dynamic Streaming supports features like adaptive bitrate, DVR functionality, etc. 1) Adaptive bitrate. To stream multi-bitrate content, the server encodes a piece of media at multiple bitrates, creating multiple files. The media files share a manifest file that lists information about each media file. With this information, the client detects the client's bandwidth, computer resources, etc and requests content fragments encoded at the most appropriate bitrate for the best viewing experience. 2) DVR functionality. Add interactivity to live streams by enabling DVR functionality, allowing viewers to pause, rewind, and skip forward to real time. 3) Support for standard HTTP caching systems. Leverage existing standard server hardware and caching infrastructures to maximize capacity and reach. 4.3. Apple Apple HTTP Live Streaming [Apple] allows to send live or prerecorded audio and video to iPhone or other devices, such as desktop computers, using an ordinary Web server. Playback requires iPhone OS 3.0 or later on iPhone or iPod touch; QuickTime X or later is required on the desktop. Zong Expires April 18, 2011 [Page 17] Internet-Draft Survey and Gap Analysis October 2010 4.3.1. Basic process +-------+ +---------+ +------+ +------+ | | | | | | | | Live | |MPEG2 | |Index/ | | | | streaming|Media |TS |Stream |.ts Files|HTTP |HTTP |Client| -------->|Encoder|----->|Segmenter|-------->|Server|Delivery|Appl. | | | | | | |------->| | VoD | | | | | | | | content | | | | | | | | -------->| | | | | | | | +-------+ +---------+ +------+ +------+ Media Encoder takes audio-video input and turns it into an MPEG-2 Transport Stream. Currently, the supported format is MPEG-2 Transport Streams (with H.264 video and AAC audio) for audio-video, or MPEG elementary streams for audio. Stream segmenter reads the Transport Stream from the local network and divides it into a series of small media files (.ts files) of equal duration, and creates an index file containing a playlist of the media files, as well as meta-data information. The index file is in .M3U8 format. In the case of a live stream, each time the segmenter completes a new media file, the index file is updated. The index is used to track the availability and location of the media files. Both .ts and .M3U8 files are placed on a HTTP server. A HTTP server or a web caching system that delivers the media files and index files to the client over HTTP. A client begins by fetching the index file, based on a URL identifying the stream. The index file in turn specifies the location of the available media files, decryption keys, and any alternate streams available. For the selected stream, the client downloads each available media file in sequence. Each file contains a consecutive segment of the stream. Once it has a sufficient amount of data downloaded, the client begins presenting the reassembled stream to the user. In addition, HTTP Live Streaming technology supports adaptive bitrate and automatically switches to the optimal bitrate based on the network conditions for a smooth quality playback experience. 5. Gap Analysys Zong Expires April 18, 2011 [Page 18] Internet-Draft Survey and Gap Analysis October 2010 5.1. Brief Summary of Exitsting Work It can be observed that 3GPP, OIPF, MS Smooth Streaming, Adobe Dynamic Streaming and Apple HTTP Live Streaming all follow a similar design scope, that is: 1) Streaming server utilizes a stream encoder/segmenter to write the media content into a series of small files, as well as produce a manifest file to describe these media files. See below summary of existing defined media and menifest files for HTTP streaming, regardless the codec and media container type. | Media File | Menifest File | ========================================================= 3GPP/OIPF | .3GP file | .3GP file | --------------------------------------------------------- MS Smooth HTTP | .ismv/.isma file | .ism/.ismc file | --------------------------------------------------------- Adobe Dynamic HTTP | .F4F file | .F4M file | --------------------------------------------------------- Apple Live HTTP | .ts file | .M3U8 file | 2) HTTP client firstly obtains the menifest file, then construct a series of URIs pointing to the media files. Based on the condition of client (e.g. network, device type, etc), or in the situation when the user operates trick mode, the client choose to request certain media file using HTTP request with the corresponding URI. 3) Upon receiving the HTTP request, the HTTP server send the media file corresponding to the URI in the request to the client. Apparently, the above design leave the network transport out of scope, that is, the media (both live streaming and VoD content) is encrypted into files and further transmitted by standard HTTP as payload. From the network transport point of view, there is no difference between transmission of such media data and normal text file. All the main features of media streaming, such as meta- information of media, PVR funtion, seeking, trick mode, adaptation between different viewing quality, etc, are implemented (or can be implemented) by the negotiation between server and client by flexible MPD, or menifest file. Another word, all the intelligence in current HTTP streaming design resides on the server and client software, rather than the network transport. Zong Expires April 18, 2011 [Page 19] Internet-Draft Survey and Gap Analysis October 2010 5.2. Challenges A good streaming system should be characterised by providing media service to users with satisfied viewing quality, adaptation to changing conditions, good scalability, as well as network-friendly media transport - flexible responses to network congestion, efficient bandwidth utilization, etc. However existing related works on HTTP streaming are still subject to these challenges, mainly due to excluding the network design out of the scope, in addition to some non-network issues such as streaming quality feedback, which is important for streaming service providers. The first challenge is the potential network degrade such as congestion caused by many concurrent HTTP streaming connections. The reason is that in the current HTTP streaming system, the transmission rate is completely controlled by HTTP client. When the HTTP client detect a better network condition - usually on access link, or a high resolution required by the user, the HTTP client tends to fully utilize the network bandwidth to fulfill the best viewing experience. However, consider the case where a huge number of HTTP clients require more bandwidth at the same time (e.g. a live event is available with HD content), the network resource will soon be used up. This scenario means that the network needs to be involved in HTTP adaptation through some negotiation mechanisms between network layer and HTTP streaming applications. The second challenge resides on the HTTP/TCP stack. While the reliable transmission capability provided by TCP works perfectly fine for file transmission and thus greatly helps the success of web industry, TCP is not born for media transmission. It is much more likely to cause greater delay due to the TCP characteristic of trying to resend the lost packet before sending anything further. Thus HTTP streaming suffers from the inefficient communication established by TCP's design and they are not well suited for delivering nearly the same amount of streams as UDP transmission. Another potential problem of HTTP is the poor scalabilty and efficiency due to the fact that TCP doesn't support multicast, which is regarded as a scalable and efficient way for media transmission. The third challenge is that there is no such transmission quality monitoring mechanisms like RTCP in current HTTP streaming system. To provide a high-quality service for the user, monitoring and analyzing the system's overall performance is extremely important, since offering the performance monitoring capability can help diagnose the potential network impairment, facilitate in root cause analysis and verify compliance of service level agreements (SLAs) between service providers and users. Zong Expires April 18, 2011 [Page 20] Internet-Draft Survey and Gap Analysis October 2010 The fouth challenge is that the current HTTP streaming is based on pull mode, that is, the HTTP client pulls the chunk one after another by issuing HTTP requests, one for each chunk. Although the pull mode gives better control of content delivery to the client and provides the capabiltiy of better handling of chunk scheduling, buffer management on the client's side, a potential problem is that there will be too many HTTP requests during the long presentation. Consider the case that hundreds of million people watch a popular live event (e.g. Olympic game) through the HTTP streaming sessions, there will be a huge number of concurrent (or nearly concurrent) HTTP requests, which in turn occupy a large portion of bandwidth. HTTP server push, on the other hand, enable the client to continuously push chunks to the HTTP client without waiting for the later request, once it receives an initial request. In this sence, push mode could be more efficient in transmission of a long sequence of media chunk. 5.3. Gap List and Potential Working Scope in IETF The following table list the gaps in exisiting works on HTTP streaming including 3GPP, MS, Adobe, and Apple. | If satisfied by | Characteristic | existing work | ========================================================== Live streaming with PVR | Yes | | ---------------------------------------------------------- Seeking (random access) | Yes | | ---------------------------------------------------------- Trick mode | Yes | | ---------------------------------------------------------- Use existing cache, CDN | Yes | | ---------------------------------------------------------- Application-layer adaptation | Yes | | ---------------------------------------------------------- Network-layer adaptation | | No | ---------------------------------------------------------- Reliable transmission by TCP | Yes | | ---------------------------------------------------------- Delay-guarantee by TCP | | No | ---------------------------------------------------------- Multicast support | | No | ---------------------------------------------------------- Streaming quality feedback | | No | ---------------------------------------------------------- HTTP server push | | No | As the leading SDO on making the network work better, IETF is a suitable place to address the above mentioned gaps when building a Zong Expires April 18, 2011 [Page 21] Internet-Draft Survey and Gap Analysis October 2010 network-efficient HTTP streaming system. A potential working scope can be: 1) provide a mechanism to allow the underlying network to be involved in HTTP streaming adaptation through some negotiation mechanisms between network layer and HTTP streaming applications; 2) introduce some transmission quality monitoring mechanisms like RTCP in current HTTP streaming system, including monitoring architecture, feedback message coding, QoE metrics for HTTP streaming, etc; 3) investigate the usage of push mode in HTTP streaming, which would refer to the work of websocket protocol in IETF Hybi WG. Please refer to [HTTPStreamingPS], for more details on the problem statement of building a network-efficient HTTP streaming system and the complete working scope description. 6. IANA Considerations This document presently raises no IANA considerations. 7. Security Considerations This document presently raises no security considerations. 8. Acknowledgements The authors would like to thank many people who give valuable comments on this draft. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [3GPP] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS) - Protocols and codecs (Release 9)", March 2010. [OIPF] OIPF, "HTTP Adaptive Streaming (Release 2)", September 2010. [MPEG-1] ISO/IEC JTC1/SC29/WG11, "HTTP Streaming of MPEG Media Context and Objectives (N11337)", April 2010. Zong Expires April 18, 2011 [Page 22] Internet-Draft Survey and Gap Analysis October 2010 [MPEG-2] ISO/IEC JTC1/SC29/WG11, "Call for Proposals on HTTP Streaming of MPEG Media (N11338)", April 2010. [MPEG-3] ISO/IEC JTC1/SC29/WG11, "Use Cases for HTTP Streaming of MPEG Media (N11339)", April 2010. [MPEG-4] ISO/IEC JTC1/SC29/WG11, "Requirements on HTTP Streaming of MPEG Media (N11340)", April 2010. [MS-IIS] Microsoft Corporation, "IIS Smooth Streaming Technical Overview", March 2009. [Adobe] Adobe, "Using ADOBE HTTP DYNAMIC STREAMING", 2010. [Apple] Apple, "HTTP Live Streaming Overview", November 2009. [HTTPStreamingPS] Wu, Q., "Problem Statement for HTTP Streaming", draft-wu-http-streaming-optimization-ps-02.txt (work in progress), September 2010. Author's Address Ning Zong Huawei Technologies Phone: +86 25 56624760 Email: zongning@huawei.com Zong Expires April 18, 2011 [Page 23] --Boundary_(ID_iOZfe3zyt8oyb1Pj9k8ErQ)-- From sunseawq@huawei.com Sun Oct 17 22:43:52 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C4D3A6A8E for <httpstreaming@core3.amsl.com>; Sun, 17 Oct 2010 22:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trqLDpYP69iN for <httpstreaming@core3.amsl.com>; Sun, 17 Oct 2010 22:43:50 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2CA263A6A87 for <httpstreaming@ietf.org>; Sun, 17 Oct 2010 22:43:50 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH003XB1B756@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 13:45:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH00CPI1B56J@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 13:45:06 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAH00GV81B5TK@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 13:45:05 +0800 (CST) Date: Mon, 18 Oct 2010 13:45:04 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> Cc: httpstreaming@ietf.org Subject: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 05:43:52 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJBbGkgQy4gQmVnZW4gKGFiZWdl bikiIDxhYmVnZW5AY2lzY28uY29tPg0KVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWkuY29t PjsgIlJvbmkgRXZlbiIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJyeWFuIiA8 ZGJyeWFuQGV0aGVybm90Lm9yZz4NCkNjOiA8aHR0cHN0cmVhbWluZ0BpZXRmLm9yZz4NClNlbnQ6 IEZyaWRheSwgT2N0b2JlciAxNSwgMjAxMCA2OjM3IFBNDQpTdWJqZWN0OiBSRTogW2h0dHBzdHJl YW1pbmddIEN1cnJlbnQgU3RhdHVzIGFuZCBPdXIgR29hbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFFpbiBXdSBbbWFpbHRvOnN1bnNlYXdxQGh1YXdlaS5jb21dDQo+ IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAxNSwgMjAxMCAzOjE0IEFNDQo+IFRvOiBBbGkgQy4gQmVn ZW4gKGFiZWdlbik7IFJvbmkgRXZlbjsgRGF2aWQgQS4gQnJ5YW4NCj4gQ2M6IGh0dHBzdHJlYW1p bmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1 cyBhbmQgT3VyIEdvYWwNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJv bTogIkFsaSBDLiBCZWdlbiAoYWJlZ2VuKSIgPGFiZWdlbkBjaXNjby5jb20+DQo+IFRvOiAiUWlu IFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNvbT47ICJSb25pIEV2ZW4iIDxFdmVuLnJvbmlAaHVhd2Vp LmNvbT47ICJEYXZpZCBBLiBCcnlhbiIgPGRicnlhbkBldGhlcm5vdC5vcmc+DQo+IENjOiA8aHR0 cHN0cmVhbWluZ0BpZXRmLm9yZz4NCj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDE1LCAyMDEwIDE6 MTQgUE0NCj4gU3ViamVjdDogUkU6IFtodHRwc3RyZWFtaW5nXSBDdXJyZW50IFN0YXR1cyBhbmQg T3VyIEdvYWwNCj4gDQo+IA0KPiA+IEJ1dCwgaW4gaHR0cCBzdHJlYW1pbmcgc2NlbmFyaW8sIHRo ZSByYXRpbyBvZiBkb3dubG9hZC91cGxvYWQgKGZyb20gdGhlIGNsaWVudCdzIHBlcnNwZWN0aXZl KSBpcyBtdWNoIGxhcmdlciB0aGFuIDEuIEJUVywgaWYNCj4gPiB5b3Uga2VlcCB5b3VyIGNodW5r IGR1cmF0aW9uIHJlbGF0aXZlbHkgbG9uZ2VyLCB0aGUgYW1vdW50IG9mIHJlcXVlc3RzIHRoYXQg eW91IHdpbGwgZW5kIHVwIHNlbmRpbmcgd2lsbCBiZSBhbG1vc3QgbmlsDQo+ID4gY29tcGFyZWQg dG8gd2hhdCB5b3Ugd2lsbCByZWNlaXZlLg0KPiA+DQo+ID4gW1Fpbl06IE5vLCBJIGp1c3QgY29t cGFyZSBwdWxsIGFuZCBwdXNoIHdpdGggdGhlIHNhbWUgY2h1bmsgZHVyYXRpb24uDQo+IA0KPiBZ b3UgY2FuIGNob29zZSB3aGF0ZXZlciBjaHVuayBzaXplIHlvdSB3YW5uYSB1c2UuIERvZXMgbm90 IG1hdHRlci4gVGhlIGZhY3QgcmVtYWlucyB0aGUgc2FtZS4gVW5sZXNzIHNvbWVvbmUgdXNlcw0K PiBjaHVua3Mgb2YgYSBmZXcgaHVuZHJlZHMgb2YgbXMsIGl0IHdvbid0IG1hdHRlci4NCj4gDQo+ ICBbUWluXTogU3VwcG9zZSAxMCBjaHVua3MgaXMgYXZhaWxhYmxlIGF0IHRoZSBzZXJ2ZXIgc2lk ZSwgaW4gdGhlIHB1bGwgbW9kZWwsIHRoZSBjbGllbnQgbmVlZCB0byBzZW5kIGF0IGxlYXN0IDEw IHJlcXVlc3RzIGFuZA0KPiByZWNlaXZlIDEwIHJlc3BvbnNlcy4NCj4gICAgICAgICAgIGluIHRo ZSBwdXNoIG1vZGVsLCB0aGUgY2xpZW50IG1heSBvbmx5IG5lZWQgdG8gc2VuZCBvbmUgcmVxdWVz dCBhbmQgdGhlbiByZWNlaXZlIDEwIHJlc3BvbnNlcy4NCj4gICAgICAgICAgIGNvbXBhcmluZyB3 aXRoIHB1bGwsIHB1c2ggbW9kZWwgc2F2ZSA5IHJlcXVlc3RzLg0KPiAgICAgICAgICAgYWxzbyBp ZiB5b3UgbG9vayBhdCB3ZWJzb2NrZXQsIHB1c2ggaGFzIG1vcmUgbGlnaHR3ZWlnaHQgaGVhZGVy IHRoYW4gcHVsbC4NCj4gICAgICAgICAgIEhvd2V2ZXIgYXMgeW91IHNhaWQ6DQo+ICAgICAgICAg ICAiDQo+ICAgICAgICAgICBpZiAgeW91IGtlZXAgeW91ciBjaHVuayBkdXJhdGlvbiByZWxhdGl2 ZWx5IGxvbmdlciwgdGhlIGFtb3VudCBvZiByZXF1ZXN0cyB0aGF0IHlvdSB3aWxsIGVuZCB1cCBz ZW5kaW5nIHdpbGwgYmUgYWxtb3N0DQo+IG5pbA0KPiAgICAgICAgICBjb21wYXJlZCB0byB3aGF0 IHlvdSB3aWxsIHJlY2VpdmUuDQo+ICAgICAgICAgICAiDQo+ICAgICAgICAgICBiYXNlZCBvbiB5 b3VyIHVuZGVyc3RhbmRpbmcsIHN1cHBvc2Ugc3RpbGwgMTBjaHVua3MgaXMgYXZhaWJsZSBhdCB0 aGUgc2VydmVyIHNpZGUsICBpbiB0aGUgcHVsbCBtb2RlbCwgdGhlIGNsaWVudCBzZW5kIDEwDQo+ IHJlcXVlc3QgdG8gZmV0Y2ggdGhlbSBhbmQNCj4gICAgICAgICAgIG1heSByZWNlaXZlIHRob3Vz YW5kcyBvZiByZXNwb25zZS4gSXMgaXQgd2hhdCB5b3Ugc2FpZCBoZXJlPw0KDQpZb3UgbWlzc2Vk IG15IHBvaW50LiBUaGUgc2l6ZSBvZiB0aGUgMTAgcmVxdWVzdCBtZXNzYWdlcyB5b3Ugc2VudCBp biB0aGUgZXhhbXBsZSBhYm92ZSBpcyBub3QgbXVjaCBjb21wYXJlZCB0byB0aGUgc2l6ZSBvZiB0 aGUgMTAgY2h1bmtzIHlvdSByZWNlaXZlLiBBbmQgaWYgdGhlIGNodW5rIGR1cmF0aW9uIGdldHMg bGFyZ2VyLCB0aGUgZGlmZmVyZW5jZSB3aWxsIGJlIGV2ZW4gYmlnZ2VyLg0KDQpbUWluXTogIEdv b2QgcG9pbnQsIGJ1dCBJIHRoaW5rIHRoZSBzaXplIG9mIDEwIHJlcXVlc3QgbWVzc2FnZXMgbWF5 IGJlIG5vdCAgY291bnQsIGJ1dCB0aGUgdGltaW5nIG9mIHJlc3BvbnNlIGlzIGNvbnRyb2xsZWQg YnkgdGhlc2UgMTAgcmVxdWVzdCBtZXNzYWdlIHdoaWNoIG1heSBiZSBoYXJkIHRvIHNhdGlzZnkg dGhlIHJlYWwgdGltZSBzdHJlYW1pbmcgcmVxdWlyZW1lbnRzIGZvciANCmxhdGVuY3kuDQoNCj4g Li4uDQo+ID4gU29ycnkgaWYgInBsYXliYWNrIHRpbWUiIG1lYW50IHRoZSBkdXJhdGlvbiBvZiB0 aGUgcGxheWJhY2suIEkgcmF0aGVyIG1lYW50IHRoZSBzdGFydCB0aW1lIG9mIHRoZSBwbGF5YmFj ay4gU28sIGlmIGEgY2xpZW50DQo+ID4ga2VlcHMgYSBsYXJnZXIgYnVmZmVyIGhvcGluZyB0aGF0 IGl0IHdpbGwgYXZvaWQgYnVmZmVyIHVuZGVycnVucywgdGhpcyBtYXkgZGVsYXkgdGhlIHBsYXli YWNrIHN0YXJ0IHRpbWUuDQo+ID4NCj4gPiBbUWluXTogUmlnaHQuIFNvIHdlIG5lZWQgdG8gY2hv b3NlIGFwcHJvcG9yaWF0ZSBidWZmZXIgc2l6ZSB0byBzZWVrIGJhbGFuY2UgYmV0d2VlbiBidWZm ZXIgdW5kZXJmbG93IGFuZCBzdGFydHVwIHRpbWUNCj4gPiBkZWxheS4gVGhlIGJ1ZmZlciBzaXpl IGNhbiBiZSBjaGFuZ2VkIGF0IGFueSB0aW1lLg0KPiANCj4gSXQgaXMgbm90IHVwIHRvIG1lIG9y IHlvdS4gQW55IGltcGxlbWVudGF0aW9uIChkZXBlbmRpbmcgb24gdGhlIGRldmljZSwgc2NlbmFy aW8sIG5ldHdvcmsgdHlwZSwgZXRjLikgY2FuIGNob29zZSBhbnkgc2l6ZSBmb3INCj4gdGhlIGJ1 ZmZlci4NCj4gDQo+IFtRaW5dOiBJIHRoaW5rIGl0IGlzIG9uZSBpc3N1ZSBwZXJ0YWluIHRvIEJ1 ZmZlciBtYW5hZ2VtZW50LiBTaW5jZSBSVFAgY2FuIGhhbmRsZSB0aGlzIHNtb290aGx5LCB3aHkg bm90IEhUVFAgc3RyZWFtaW5nPw0KDQpTb3JyeSBJIGFtIG5vdCBmb2xsb3dpbmcuIFJUUCBkb2Vz IG5vdCBkZWFsIHdpdGggdGhpcy4gTWF5YmUgeW91IGFyZSByZWZlcnJpbmcgdG8gUlRTUCBzdHJl YW1pbmcgYW5kIHRoZW4gYnVmZmVyIGR1cmF0aW9uIGlzIGFnYWluIHNvbWV0aGluZyBjaG9zZW4g YnkgdGhlIGNsaWVudCBub3QgdGhlIHByb3RvY29sLg0KDQpbUWluXTpBbCB0aG91Z2ggdGhlIGNs aWVudCBjb250cm9sIHRoZSBidWZmZXIgZHVyYXRpb24gZm9yIHBsYXlvdXQgYXQgdGhlIGNsaWVu dCBzaWRlLCB0aGUgY2xpZW50IGNhbiBub3QgY29udHJvbCB0aGUgYnVmZmVyIGZvciBlbmNvZGlu ZyBhdCB0aGUgc2VydmVyIHNpZGUuDQogDQo+ID4gT3IsIHRoZSBjbGllbnQgY2FuIHN0YXJ0IHRo ZSBwbGF5YmFjayBxdWlja2x5IGFuZCBidWlsZCB0aGUgYnVmZmVyIG92ZXIgdGltZSBieSByZXF1 ZXN0aW5nIGxvd2VyLWJpdHJhdGUgY2h1bmtzLg0KPiA+DQo+ID4gW1Fpbl06IEkgdGhpbmsgdGhl IHByZXN1bXB0aW9uIGlzIHRoZSBzZXJ2ZXIgc2hvdWxkIHByZXBhcmUgbXVsdGlwbGUgc3RyZWFt cyBvZiB0aGUgc2FtZSBjb250ZW50IHdpdGggZGlmZmVyZW50IGJpdHJhdGVzLiB0aGUNCj4gPiBz ZXJ2ZXIgbWF5IGhhdmUgYSBiaWcgbG9hZCBpZiB0aGUgY29udGVudCBpcyBsaXZlIGNvbnRlbnRz Lg0KPiANCj4gSXQgaXMgbm90IHRoZSBzZXJ2ZXIgd2hvIHByZXBhcmVzIHRoZSBjb250ZW50LiBO b3QgbmVjZXNzYXJpbHkgYW5kIG5vdCBvZnRlbi4gU28sIHNlcnZpbmcgdGhlIHNhbWUgY29udGVu dCBhdCBkaWZmZXJlbnQgYml0cmF0ZXMNCj4gZG9lcyBub3QgcG9zZSBhbnkgZXh0cmEgbG9hZCBv biB0aGUgc2VydmVyIChleGNlcHQgd2hlcmUgdGhlIGNhY2hpbmcgY29tZXMgaW50byBwbGF5KS4N Cj4gDQo+IFtRaW5dOiBZZXMsIGl0IGRvZXMgbm90IG1hdHRlciB3aGV0aGVyIHN0cmVhbWluZyBj b21wb25lbnQgaXMgY29sbG9jYXRlZCB3aXRoIHdlYiBzZXJ2ZXIgb3Igc2VwYXJhdGVkLg0KPiAN Cj4gPiBXaGV0aGVyIGl0IHBhY2VzIHRoZSBwcmVzZW50YXRpb24gc3BlZWQgZG93biBvciBub3Qg aW4gb3JkZXIgdG8gYXZvaWQgYnVmZmVyIHVuZGVycnVucyBpcyBzb21ldGhpbmcgdXAgdG8gdGhl IGNsaWVudC4gTW9zdA0KPiA+IGltcGxlbWVudGF0aW9ucyBJIGhhdmUgc2VlbiBzaW1wbHkgc3dp dGNoIHRvIGEgbG93ZXItYml0cmF0ZSBwcm9maWxlIHdlbGwgYmVmb3JlIHRoZSBidWZmZXIgaXMg ZnVsbHkgZHJhaW5lZC4gU28sIHRoZXkgZG9uJ3QNCj4gPiBleHBlcmllbmNlIGJ1ZmZlciB1bmRl cnJ1bnMgYW5kIHRoZXkgZG9uknQgbmVlZCB0byBwYWNlIHRoZSB2aWRlbyBwcmVzZW50YXRpb24g c3BlZWQgZG93bi4NCj4gPg0KPiA+IFtRaW5dOiBJIGRvbid0IGRvdWJ0IGdpdmluZyBtb3JlIGNv bnRyb2wgdG8gY2xpZW50IGhhcyBpdHMgYWR2YW50YWdlcy4gQnV0IEkgdGhpbmsgZ2l2aW5nIHNv bWUgY29udHJvbCB0byB0aGUgc2VydmVyIGFsc28gaGFzIGl0cw0KPiA+IGFkdmFudGFnZS4gZS5n LiwgIHlvdSBtYXkgbm90IG5lZWQgdG8gcHJlcGFyZSBtdWx0aXBsZSBzdHJlYW0gb2YgdGhlIHNh bWUgY29udGVudCB3aXRoIGRpZmZlcmVudCBiaXRyYXRlLg0KPiANCj4gV2VsbCwgQUZBSUNUIHRo ZSBtZXRob2QgaW4gd2hpY2ggcGVvcGxlIChpbmNsdWRpbmcgbWUpIGFyZSBpbnRlcmVzdGVkIGlu IGlzIHRoaXMgc28tY2FsbGVkIG11bHRpLWJpdHJhdGUgc3RyZWFtaW5nLCB3aGljaA0KPiBpbXBs aWVzIHRoZSBzYW1lIGNvbnRlbnQgYmVpbmcgZW5jb2RlZCBhdCBtdWx0aXBsZSBiaXRyYXRlcy4N Cj4gDQo+IFtRaW5dOiBJIGFtIGludGVyZXN0ZWQgdG9vLiBCdXQgSSBzdXNwZWN0IHRoZXJlIGFy ZSBvdGhlciB3YXlzIHRvIGRlY3JlYXNlIHN1Y2ggb3ZlcmhlYWQuIGUuZy4sIHRyYW5jb2Rpbmcg bWF5IGJlIGJlc3QgY2hvaWNlDQo+IGZvciBsaXZlIGNvbnRlbnQuDQo+IA0KPiA+IHRoZSBzZXJ2 ZXIgY29udHJvbCB0aGUgdHJhbnNtaXNzaW9uIHJhdGUgYmFzZWQgb24gdGhlIG5ldHdvcmsgY29u ZGl0aW9uIGFuZCBjbGllbnQgcmVxdWlyZW1lbnRzLg0KPiANCj4gSG93IHdvdWxkIHRoaXMgd29y ayBpZiB5b3UgaGF2ZSBvbmx5IG9uZSBiaXRyYXRlIG9uIHRoZSBzZXJ2ZXI/IElzIHlvdXIgYXBw cm9hY2ggYXMgZm9sbG93czoNCj4gDQo+IFJhdGhlciB0aGFuIG9mZmVyaW5nIHRoZSBzYW1lIGNv bnRlbnQgZW5jb2RlZCBhdCBtdWx0aXBsZSBiaXRyYXRlcyBhbmQgc2VydmluZyB0aGVtIGJhc2Vk IG9uIHdoYXQgdGhlIGNsaWVudCB3YW50cywgeW91DQo+IHdhbm5hIHNlcnZlIHRoZSBjb250ZW50 IGVuY29kZWQgYXQgYSBzaW5nbGUgYml0cmF0ZSBhbmQgYnkgbWFuaXB1bGF0aW5nIHRoZSB0cmFu c21pc3Npb24gcmF0ZSBvbiB0aGUgc2VydmVyIChiYXNlZCBvbg0KPiBzZXJ2ZXIncyBrbm93bGVk Z2Ugb2YgbmV0d29yayBhbmQgY2xpZW50KSwgeW91ICJhZGFwdGl2ZWx5IiBzZW5kIGl0LiBJcyB0 aGF0IHRoZSBzY2VuYXJpbyB5b3UgaGF2ZSBpbiBtaW5kPw0KPiANCj4gW1Fpbl06IFBlcnNvbmFs bHkgdGhhdCBpcyB3aGF0IEkgYW0gdHJ5aW5nIHRvIGxvb2sgZm9yLiBhIHNpbmdsZSBiaXJhdGUg Zm9yIGxpdmUgY29udGVudCBtYXkgY2hhbmdlIGF0IHRpbWUgd2hpY2ggY2FuIGJlDQo+IHJlYWxp emVkIGJ5IHRyYW5zY29kaW5nLg0KDQpJZiB5b3UgYXJlIHNheWluZyBhIHNlcnZlciBkb2luZyB0 cmFuc2NvZGluZyBmb3IgYWRhcHRhdGlvbiBzY2FsZXMgYmV0dGVyIHRoYW4gYW4gaHR0cCBzZXJ2 ZXIgc2VydmluZyBjbGllbnQgcmVxdWVzdHMgZm9yIGRpZmZlcmVudCBjaHVua3MsIHRoZW4gSSB0 aGluayB5b3Ugc2hvdWxkIG1ha2UgeW91ciBhcmd1bWVudHMgY2xlYXIgZW5vdWdoIGluIHRoZSBw cm9ibGVtIHN0YXRlbWVudCBkcmFmdCBhbmQgc2VlIHdoZXRoZXIgb3RoZXJzIHRoaW5rLiBUbyBt ZSwgaXQgaXMgYSBsb3NpbmcgcHJvcG9zaXRpb24uIA0KDQpbUWluXTogT2theS4gdGhhbmsgZm9y IHBvaW50aW5nIG91dCB0aGlzLg0KDQotYWNiZWdlbg0K From sunseawq@huawei.com Mon Oct 18 00:21:26 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50F543A6CAE for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.817 X-Spam-Level: X-Spam-Status: No, score=0.817 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phiw8X2TtOvI for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:21:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 61D9A3A6C86 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 00:21:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH005L05TTZV@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:22:42 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH00ELX5TT1Y@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:22:41 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAH000JL5TSWG@szxml06-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:22:41 +0800 (CST) Date: Mon, 18 Oct 2010 15:22:38 +0800 From: Qin Wu <sunseawq@huawei.com> To: "Ali C. Begen (abegen)" <abegen@cisco.com>, Roni Even <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org> Message-id: <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 07:21:26 -0000 > How would this work if you have only one bitrate on the server? Is your approach as follows: > > Rather than offering the same content encoded at multiple bitrates and serving them based on what the client wants, you > wanna serve the content encoded at a single bitrate and by manipulating the transmission rate on the server (based on > server's knowledge of network and client), you "adaptively" send it. Is that the scenario you have in mind? > > [Qin]: Personally that is what I am trying to look for. a single birate for live content may change at time which can be > realized by transcoding. If you are saying a server doing transcoding for adaptation scales better than an http server serving client requests for different chunks, then I think you should make your arguments clear enough in the problem statement draft and see whether others think. To me, it is a losing proposition. [Qin]; for the live content consuming with thousands of consumers viewing at the same time, in my opinion, it may be a successful propsotion. _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From stockhammer@nomor.de Mon Oct 18 00:28:48 2010 Return-Path: <stockhammer@nomor.de> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920C83A6B1C for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOWqr+Vh+hZt for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:28:39 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.162]) by core3.amsl.com (Postfix) with ESMTP id 7738D3A68A7 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 00:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1287386998; l=1566; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=IO7NZvkI6kg+iaU8gm9BkM/YDRY=; b=aP5vfoMTNjtds5kUM5eUk9IdWY3Zc/vbIJO3XTQgEVUjc0R/VgiSGPTI/YzgecWAWMr Vq48Ml/nWFTkQ1gOP5ewvh5SEo61ptxmcFhIpzpsUjTU8q7xlZa26JpQgDRHB9b2z3TG/ E87yCrpu9F4Xq4O4/rESYLIzEYTmYB280VQ= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [172.16.1.2] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (klopstock mo54) (RZmta 23.5) with ESMTP id N00939m9I78ADA ; Mon, 18 Oct 2010 09:29:55 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer <stockhammer@nomor.de> X-Priority: 3 In-Reply-To: <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> Date: Mon, 18 Oct 2010 09:29:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <588B9C79-E23E-4900-B2FC-6E6B034AD473@nomor.de> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> To: Qin Wu <sunseawq@huawei.com> X-Mailer: Apple Mail (2.1081) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 07:28:48 -0000 On Oct 18, 2010, at 9:22 AM, Qin Wu wrote: >> How would this work if you have only one bitrate on the server? Is = your approach as follows: >>=20 >> Rather than offering the same content encoded at multiple bitrates = and serving them based on what the client wants, you >> wanna serve the content encoded at a single bitrate and by = manipulating the transmission rate on the server (based on >> server's knowledge of network and client), you "adaptively" send it. = Is that the scenario you have in mind? >>=20 >> [Qin]: Personally that is what I am trying to look for. a single = birate for live content may change at time which can be >> realized by transcoding. >=20 > If you are saying a server doing transcoding for adaptation scales = better than an http server serving client requests for different chunks, = then I think you should make your arguments clear enough in the problem = statement draft and see whether others think. To me, it is a losing = proposition.=20 >=20 > [Qin]; for the live content consuming with thousands of consumers = viewing at the same time, in my opinion, it may be a successful = propsotion. [T] Adaptation for each of the thousands of users!? [\T] --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From sunseawq@huawei.com Mon Oct 18 00:40:58 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8763A6C10 for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.158 X-Spam-Level: ** X-Spam-Status: No, score=2.158 tagged_above=-999 required=5 tests=[AWL=-1.514, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvlzbFbo+jy2 for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:40:50 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 81A613A6A65 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 00:40:50 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH006TR6Q70T@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:42:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH007CL6Q7AX@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:42:07 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAH002GY6Q6NN@szxml06-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 15:42:07 +0800 (CST) Date: Mon, 18 Oct 2010 15:42:04 +0800 From: Qin Wu <sunseawq@huawei.com> To: Thomas Stockhammer <stockhammer@nomor.de> Message-id: <03f101cb6e97$f582acd0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 07:40:58 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlRob21hcyBTdG9ja2hhbW1l ciIgPHN0b2NraGFtbWVyQG5vbW9yLmRlPg0KVG86ICJRaW4gV3UiIDxzdW5zZWF3cUBodWF3ZWku Y29tPg0KQ2M6ICJBbGkgQy4gQmVnZW4gKGFiZWdlbikiIDxhYmVnZW5AY2lzY28uY29tPjsgIlJv bmkgRXZlbiIgPEV2ZW4ucm9uaUBodWF3ZWkuY29tPjsgIkRhdmlkIEEuIEJyeWFuIiA8ZGJyeWFu QGV0aGVybm90Lm9yZz47IDxodHRwc3RyZWFtaW5nQGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBP Y3RvYmVyIDE4LCAyMDEwIDM6MjkgUE0NClN1YmplY3Q6IFJlOiBbaHR0cHN0cmVhbWluZ10gUHVz aCBWcyBQdWxsIFJlOiBDdXJyZW50IFN0YXR1cyBhbmQgT3VyIEdvYWwNCg0KDQoNCk9uIE9jdCAx OCwgMjAxMCwgYXQgOToyMiBBTSwgUWluIFd1IHdyb3RlOg0KDQo+PiBIb3cgd291bGQgdGhpcyB3 b3JrIGlmIHlvdSBoYXZlIG9ubHkgb25lIGJpdHJhdGUgb24gdGhlIHNlcnZlcj8gSXMgeW91ciBh cHByb2FjaCBhcyBmb2xsb3dzOg0KPj4gDQo+PiBSYXRoZXIgdGhhbiBvZmZlcmluZyB0aGUgc2Ft ZSBjb250ZW50IGVuY29kZWQgYXQgbXVsdGlwbGUgYml0cmF0ZXMgYW5kIHNlcnZpbmcgdGhlbSBi YXNlZCBvbiB3aGF0IHRoZSBjbGllbnQgd2FudHMsIHlvdQ0KPj4gd2FubmEgc2VydmUgdGhlIGNv bnRlbnQgZW5jb2RlZCBhdCBhIHNpbmdsZSBiaXRyYXRlIGFuZCBieSBtYW5pcHVsYXRpbmcgdGhl IHRyYW5zbWlzc2lvbiByYXRlIG9uIHRoZSBzZXJ2ZXIgKGJhc2VkIG9uDQo+PiBzZXJ2ZXIncyBr bm93bGVkZ2Ugb2YgbmV0d29yayBhbmQgY2xpZW50KSwgeW91ICJhZGFwdGl2ZWx5IiBzZW5kIGl0 LiBJcyB0aGF0IHRoZSBzY2VuYXJpbyB5b3UgaGF2ZSBpbiBtaW5kPw0KPj4gDQo+PiBbUWluXTog UGVyc29uYWxseSB0aGF0IGlzIHdoYXQgSSBhbSB0cnlpbmcgdG8gbG9vayBmb3IuIGEgc2luZ2xl IGJpcmF0ZSBmb3IgbGl2ZSBjb250ZW50IG1heSBjaGFuZ2UgYXQgdGltZSB3aGljaCBjYW4gYmUN Cj4+IHJlYWxpemVkIGJ5IHRyYW5zY29kaW5nLg0KPiANCj4gSWYgeW91IGFyZSBzYXlpbmcgYSBz ZXJ2ZXIgZG9pbmcgdHJhbnNjb2RpbmcgZm9yIGFkYXB0YXRpb24gc2NhbGVzIGJldHRlciB0aGFu IGFuIGh0dHAgc2VydmVyIHNlcnZpbmcgY2xpZW50IHJlcXVlc3RzIGZvciBkaWZmZXJlbnQgY2h1 bmtzLCB0aGVuIEkgdGhpbmsgeW91IHNob3VsZCBtYWtlIHlvdXIgYXJndW1lbnRzIGNsZWFyIGVu b3VnaCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgYW5kIHNlZSB3aGV0aGVyIG90aGVy cyB0aGluay4gVG8gbWUsIGl0IGlzIGEgbG9zaW5nIHByb3Bvc2l0aW9uLiANCj4gDQo+IFtRaW5d OyBmb3IgdGhlIGxpdmUgY29udGVudCBjb25zdW1pbmcgd2l0aCB0aG91c2FuZHMgb2YgY29uc3Vt ZXJzIHZpZXdpbmcgYXQgdGhlIHNhbWUgdGltZSwgaW4gbXkgb3BpbmlvbiwgaXQgbWF5IGJlIGEg c3VjY2Vzc2Z1bCBwcm9wc290aW9uLg0KDQpbVF0gQWRhcHRhdGlvbiBmb3IgZWFjaCBvZiB0aGUg dGhvdXNhbmRzIG9mIHVzZXJzIT8gIFtcVF0NCg0KW1Fpbl06IFRoZSBzY2VuYXJpbyB3ZSBhcmUg dGFsa2luZyBhYm91dCBpcyBtb3JlIGFuZCBtb3JlIHBlb3BsZSB3YXRjaGluZyBvbmUgcG9wdWFy IGdsb2JhbCBldmVudCBhdCB0aGUgc2FtZSB0aW1lLCBlLmcuLCB3b3JsZCBjdXAgZmluYWxzLCBV UyBwcmVzaWRlbnQgZWxlY3Rpb24sIE9seW1waWMgZ2FtZXMuDQoNCi0tLQ0KRHIuIFRob21hcyBT dG9ja2hhbW1lciAoQ0VPKSB8fCBzdG9ja2hhbW1lckBub21vci5kZSB8fCBwaG9uZSArNDkgODkg OTc4OTgwIDAyIHx8IGNlbGwgKzQ5MTcyNTcwMjY2NyB8fCBodHRwOi8vd3d3Lm5vbW9yLXJlc2Vh cmNoLmNvbQ0KTm9tb3IgUmVzZWFyY2ggR21iSCAgLSAgU2l0eiBkZXIgR2VzZWxsc2NoYWZ0OiBN /G5jaGVuIC0gUmVnaXN0ZXJnZXJpY2h0OiBN/G5jaGVuLCBIUkIgMTY1ODU2IJYgVW1zYXR6c3Rl dWVyLUlEOiBERTIzODA0NzYzNyAtIEdlc2No5GZ0c2b8aHJlcjogRHIuIFRob21hcyBTdG9ja2hh bW1lciwgRHIuIEluZ28gVmllcmluZy4NCg0KDQoNCg== From stockhammer@nomor.de Mon Oct 18 00:56:59 2010 Return-Path: <stockhammer@nomor.de> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B26B43A6CB0 for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.416 X-Spam-Level: X-Spam-Status: No, score=0.416 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_50=0.001, HELO_EQ_DE=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD8JvpEhmjhu for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 00:56:58 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id AD1103A67AD for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 00:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1287388704; l=2170; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=nnzRH/IMmejOno2pvRLoC3RPdIc=; b=r/E6Wa2Q5wYUszI/E0hBEiSDU/zNq9gCRRFR7YRAyQZzdeTDQFPMOxlJ4k4v1tHYUpC bzsLqiy7C4i6vxk7A8v4LLnyCUOaq12h8pq/u8dHCBj3knedzNTGyGZ6PDhLo+vCGizc8 +g7hMg6bOEjfyfUKI4C9vB0F5J+AVOZUjn4= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [172.16.1.2] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (klopstock mo35) (RZmta 23.5) with ESMTP id a06e60m9I7ltac ; Mon, 18 Oct 2010 09:58:24 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer <stockhammer@nomor.de> X-Priority: 3 In-Reply-To: <03f101cb6e97$f582acd0$30298a0a@china.huawei.com> Date: Mon, 18 Oct 2010 09:58:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <F06A5E53-C615-40FE-BE9E-F13AADAAD13A@nomor.de> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> <03f101cb6e97$f582acd0$30298a0a@china.huawei.com> To: Qin Wu <sunseawq@huawei.com> X-Mailer: Apple Mail (2.1081) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 07:56:59 -0000 >>> How would this work if you have only one bitrate on the server? Is = your approach as follows: >>>=20 >>> Rather than offering the same content encoded at multiple bitrates = and serving them based on what the client wants, you >>> wanna serve the content encoded at a single bitrate and by = manipulating the transmission rate on the server (based on >>> server's knowledge of network and client), you "adaptively" send it. = Is that the scenario you have in mind? >>>=20 >>> [Qin]: Personally that is what I am trying to look for. a single = birate for live content may change at time which can be >>> realized by transcoding. >>=20 >> If you are saying a server doing transcoding for adaptation scales = better than an http server serving client requests for different chunks, = then I think you should make your arguments clear enough in the problem = statement draft and see whether others think. To me, it is a losing = proposition.=20 >>=20 >> [Qin]; for the live content consuming with thousands of consumers = viewing at the same time, in my opinion, it may be a successful = propsotion. >=20 > [T] Adaptation for each of the thousands of users!? [\T] >=20 > [Qin]: The scenario we are talking about is more and more people = watching one popuar global event at the same time, e.g., world cup = finals, US president election, Olympic games. [T]=20 Exactly! And therefore individual server side adaptation is worst ...=20 To maintain a 1-1 relationship between the client and the server breaks = scalability.=20 Just offer a couple of bitrate choices and the millions of clients will = pick the one that suits them. Clients are extremely intelligent and = capable nowadays.=20 Network-initiated individual QoS control is not a subject in HTTP = streaming.=20 [\T]=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From sunseawq@huawei.com Mon Oct 18 01:14:58 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557F33A6CD9 for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.335 X-Spam-Level: ** X-Spam-Status: No, score=2.335 tagged_above=-999 required=5 tests=[AWL=-1.652, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2T5hSJHk4nl for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:14:02 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5D9143A6C58 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 01:13:47 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH007G6877EA@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 16:13:55 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAH00JBM87633@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 16:13:54 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAH0067R876XQ@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 18 Oct 2010 16:13:54 +0800 (CST) Date: Mon, 18 Oct 2010 16:13:52 +0800 From: Qin Wu <sunseawq@huawei.com> To: Thomas Stockhammer <stockhammer@nomor.de> Message-id: <043601cb6e9c$6719f8e0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> <03f101cb6e97$f582acd0$30298a0a@china.huawei.com> Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 08:15:01 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJUaG9tYXMgU3RvY2toYW1tZXIi IDxzdG9ja2hhbW1lckBub21vci5kZT4NClRvOiAiUWluIFd1IiA8c3Vuc2Vhd3FAaHVhd2VpLmNv bT4NCkNjOiAiQWxpIEMuIEJlZ2VuIChhYmVnZW4pIiA8YWJlZ2VuQGNpc2NvLmNvbT47ICJSb25p IEV2ZW4iIDxFdmVuLnJvbmlAaHVhd2VpLmNvbT47ICJEYXZpZCBBLiBCcnlhbiIgPGRicnlhbkBl dGhlcm5vdC5vcmc+OyA8aHR0cHN0cmVhbWluZ0BpZXRmLm9yZz4NClNlbnQ6IE1vbmRheSwgT2N0 b2JlciAxOCwgMjAxMCAzOjU4IFBNDQpTdWJqZWN0OiBSZTogW2h0dHBzdHJlYW1pbmddIFB1c2gg VnMgUHVsbCBSZTogQ3VycmVudCBTdGF0dXMgYW5kIE91ciBHb2FsDQoNCg0KPj4+IEhvdyB3b3Vs ZCB0aGlzIHdvcmsgaWYgeW91IGhhdmUgb25seSBvbmUgYml0cmF0ZSBvbiB0aGUgc2VydmVyPyBJ cyB5b3VyIGFwcHJvYWNoIGFzIGZvbGxvd3M6DQo+Pj4gDQo+Pj4gUmF0aGVyIHRoYW4gb2ZmZXJp bmcgdGhlIHNhbWUgY29udGVudCBlbmNvZGVkIGF0IG11bHRpcGxlIGJpdHJhdGVzIGFuZCBzZXJ2 aW5nIHRoZW0gYmFzZWQgb24gd2hhdCB0aGUgY2xpZW50IHdhbnRzLCB5b3UNCj4+PiB3YW5uYSBz ZXJ2ZSB0aGUgY29udGVudCBlbmNvZGVkIGF0IGEgc2luZ2xlIGJpdHJhdGUgYW5kIGJ5IG1hbmlw dWxhdGluZyB0aGUgdHJhbnNtaXNzaW9uIHJhdGUgb24gdGhlIHNlcnZlciAoYmFzZWQgb24NCj4+ PiBzZXJ2ZXIncyBrbm93bGVkZ2Ugb2YgbmV0d29yayBhbmQgY2xpZW50KSwgeW91ICJhZGFwdGl2 ZWx5IiBzZW5kIGl0LiBJcyB0aGF0IHRoZSBzY2VuYXJpbyB5b3UgaGF2ZSBpbiBtaW5kPw0KPj4+ IA0KPj4+IFtRaW5dOiBQZXJzb25hbGx5IHRoYXQgaXMgd2hhdCBJIGFtIHRyeWluZyB0byBsb29r IGZvci4gYSBzaW5nbGUgYmlyYXRlIGZvciBsaXZlIGNvbnRlbnQgbWF5IGNoYW5nZSBhdCB0aW1l IHdoaWNoIGNhbiBiZQ0KPj4+IHJlYWxpemVkIGJ5IHRyYW5zY29kaW5nLg0KPj4gDQo+PiBJZiB5 b3UgYXJlIHNheWluZyBhIHNlcnZlciBkb2luZyB0cmFuc2NvZGluZyBmb3IgYWRhcHRhdGlvbiBz Y2FsZXMgYmV0dGVyIHRoYW4gYW4gaHR0cCBzZXJ2ZXIgc2VydmluZyBjbGllbnQgcmVxdWVzdHMg Zm9yIGRpZmZlcmVudCBjaHVua3MsIHRoZW4gSSB0aGluayB5b3Ugc2hvdWxkIG1ha2UgeW91ciBh cmd1bWVudHMgY2xlYXIgZW5vdWdoIGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkcmFmdCBhbmQg c2VlIHdoZXRoZXIgb3RoZXJzIHRoaW5rLiBUbyBtZSwgaXQgaXMgYSBsb3NpbmcgcHJvcG9zaXRp b24uIA0KPj4gDQo+PiBbUWluXTsgZm9yIHRoZSBsaXZlIGNvbnRlbnQgY29uc3VtaW5nIHdpdGgg dGhvdXNhbmRzIG9mIGNvbnN1bWVycyB2aWV3aW5nIGF0IHRoZSBzYW1lIHRpbWUsIGluIG15IG9w aW5pb24sIGl0IG1heSBiZSBhIHN1Y2Nlc3NmdWwgcHJvcHNvdGlvbi4NCj4gDQo+IFtUXSBBZGFw dGF0aW9uIGZvciBlYWNoIG9mIHRoZSB0aG91c2FuZHMgb2YgdXNlcnMhPyAgW1xUXQ0KPiANCj4g W1Fpbl06IFRoZSBzY2VuYXJpbyB3ZSBhcmUgdGFsa2luZyBhYm91dCBpcyBtb3JlIGFuZCBtb3Jl IHBlb3BsZSB3YXRjaGluZyBvbmUgcG9wdWFyIGdsb2JhbCBldmVudCBhdCB0aGUgc2FtZSB0aW1l LCBlLmcuLCB3b3JsZCBjdXAgZmluYWxzLCBVUyBwcmVzaWRlbnQgZWxlY3Rpb24sIE9seW1waWMg Z2FtZXMuDQoNCg0KW1RdIA0KRXhhY3RseSEgQW5kIHRoZXJlZm9yZSBpbmRpdmlkdWFsIHNlcnZl ciBzaWRlIGFkYXB0YXRpb24gaXMgd29yc3QgLi4uIA0KVG8gbWFpbnRhaW4gYSAxLTEgcmVsYXRp b25zaGlwIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBicmVha3Mgc2NhbGFiaWxp dHkuIA0KSnVzdCBvZmZlciBhIGNvdXBsZSBvZiBiaXRyYXRlIGNob2ljZXMgYW5kIHRoZSBtaWxs aW9ucyBvZiBjbGllbnRzIHdpbGwgcGljayB0aGUgb25lIHRoYXQgc3VpdHMgdGhlbS4gQ2xpZW50 cyBhcmUgZXh0cmVtZWx5IGludGVsbGlnZW50IGFuZCBjYXBhYmxlIG5vd2FkYXlzLiANCk5ldHdv cmstaW5pdGlhdGVkIGluZGl2aWR1YWwgUW9TIGNvbnRyb2wgaXMgbm90IGEgc3ViamVjdCBpbiBI VFRQIHN0cmVhbWluZy4gDQpbXFRdIA0KDQpbUWluXTogSXQgc2VlbXMgeW91IHRhbGsgYWJvdXQg c2VydmVyIGJhc2VkIHNvbHV0aW9uIGluIHlvdXIgdmlzaW9uIHdoaWNoIEkgY2FuJ3QgZm9sbG93 LiBJbiBteSB1bmRlcnN0YW5kaW5nLCBjbGllbnQgYmFzZWQgc29sdXRpb24gbW9yZSBmaXQgZm9y IHJlY29yZGVkIGNvbnRlbnQgY29uc3VtaW5nIHRoYW4gbGl2ZSBjb250ZW50IGNvbnN1bWluZy4N ClRoZSBiaWcgcHJvYmxlbSBvZiBjdXJyZW50IGV4aXN0aW5nIGNsaWVudCBiYXNlZCBzb2x1dGlv biBjYW4gbm90IHdlbGwgc2F0aXNmeSByZWFsIHRpbWUgc3RyZWFtaW5nIHJlcXVpcmVtZW50cyBk dXJpbmcgbGl2ZSBjb250ZW50IGNvbnN1bWluZy4NCg0KLS0tDQpEci4gVGhvbWFzIFN0b2NraGFt bWVyIChDRU8pIHx8IHN0b2NraGFtbWVyQG5vbW9yLmRlIHx8IHBob25lICs0OSA4OSA5Nzg5ODAg MDIgfHwgY2VsbCArNDkxNzI1NzAyNjY3IHx8IGh0dHA6Ly93d3cubm9tb3ItcmVzZWFyY2guY29t DQpOb21vciBSZXNlYXJjaCBHbWJIICAtICBTaXR6IGRlciBHZXNlbGxzY2hhZnQ6IE38bmNoZW4g LSBSZWdpc3RlcmdlcmljaHQ6IE38bmNoZW4sIEhSQiAxNjU4NTYgliBVbXNhdHpzdGV1ZXItSUQ6 IERFMjM4MDQ3NjM3IC0gR2VzY2jkZnRzZvxocmVyOiBEci4gVGhvbWFzIFN0b2NraGFtbWVyLCBE ci4gSW5nbyBWaWVyaW5nLg0KDQoNCg0K From stockhammer@nomor.de Mon Oct 18 01:33:15 2010 Return-Path: <stockhammer@nomor.de> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B4083A6CE3 for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.541 X-Spam-Level: X-Spam-Status: No, score=0.541 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_50=0.001, HELO_EQ_DE=0.35, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUeGxA+ALUJc for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:33:13 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id 1A9DD3A6CC4 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 01:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1287390878; l=3467; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=Uvg4x2My0c338Eo67iZk+42Ee+A=; b=wbKfKMgCQcANE48+x1TMSLnbwd8odLmC3vZX1zPHNtT+oADWaXWwGswSiOFkQNH66zU 8lmLDOQEs6g2n13OxN6Tl5UjNlufpkl9/F6FHKMk+0c0XBlOYSJI/H3yfBdkRuzAMN4DZ Q5LG9533Xk88Abc7m/IlnrxyX+OszJmkqfU= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [172.16.1.2] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (mrclete mo11) (RZmta 23.5) with ESMTP id 001bb4m9I7uasc ; Mon, 18 Oct 2010 10:34:09 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer <stockhammer@nomor.de> X-Priority: 3 In-Reply-To: <043601cb6e9c$6719f8e0$30298a0a@china.huawei.com> Date: Mon, 18 Oct 2010 10:34:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <087F87BB-C6C1-4B1A-8032-660CC251C180@nomor.de> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> <03f101cb6e97$f582acd0$30298a0a@china.huawei.com> <043601cb6e9c$6719f8e0$30298a0a@china.huawei.com> To: Qin Wu <sunseawq@huawei.com> X-Mailer: Apple Mail (2.1081) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 08:33:15 -0000 >>>> How would this work if you have only one bitrate on the server? Is = your approach as follows: >>>>=20 >>>> Rather than offering the same content encoded at multiple bitrates = and serving them based on what the client wants, you >>>> wanna serve the content encoded at a single bitrate and by = manipulating the transmission rate on the server (based on >>>> server's knowledge of network and client), you "adaptively" send = it. Is that the scenario you have in mind? >>>>=20 >>>> [Qin]: Personally that is what I am trying to look for. a single = birate for live content may change at time which can be >>>> realized by transcoding. >>>=20 >>> If you are saying a server doing transcoding for adaptation scales = better than an http server serving client requests for different chunks, = then I think you should make your arguments clear enough in the problem = statement draft and see whether others think. To me, it is a losing = proposition.=20 >>>=20 >>> [Qin]; for the live content consuming with thousands of consumers = viewing at the same time, in my opinion, it may be a successful = propsotion. >>=20 >> [T] Adaptation for each of the thousands of users!? [\T] >>=20 >> [Qin]: The scenario we are talking about is more and more people = watching one popuar global event at the same time, e.g., world cup = finals, US president election, Olympic games. >=20 >=20 > [T]=20 > Exactly! And therefore individual server side adaptation is worst ...=20= > To maintain a 1-1 relationship between the client and the server = breaks scalability.=20 > Just offer a couple of bitrate choices and the millions of clients = will pick the one that suits them. Clients are extremely intelligent and = capable nowadays.=20 > Network-initiated individual QoS control is not a subject in HTTP = streaming.=20 > [\T]=20 >=20 > [Qin]: It seems you talk about server based solution in your vision = which I can't follow. In my understanding, client based solution more = fit for recorded content consuming than live content consuming. > The big problem of current existing client based solution can not well = satisfy real time streaming requirements during live content consuming. [T] If I summarize your proposition from the above e-mails, this is what it = says: "[Qin:] Rather than offering the same content encoded at multiple = bitrates and serving them based on what the client wants, you wanna = serve the content encoded at a single bitrate and by manipulating the = transmission rate on the server (based on server's knowledge of network = and client), you "adaptively" send it. That is what I am trying to look = for. a single birate for live content may change at time which can be realized by transcoding. This is a successful propsotion for the live = content consuming with thousands of consumers viewing at the same time" This is server-controlled: "... by manipulating the transmission rate on = the server ..." And in my opinion this is no successful proposition. The only problem in live that may exist is end-to-end latency.=20 [\T] --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From wenboz@google.com Mon Oct 18 01:40:01 2010 Return-Path: <wenboz@google.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465D23A6CDE for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.325 X-Spam-Level: X-Spam-Status: No, score=-106.325 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svvjr1QX8M7L for <httpstreaming@core3.amsl.com>; Mon, 18 Oct 2010 01:39:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 8BF713A68A3 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 01:39:59 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o9I8fQHL012865 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 01:41:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287391286; bh=RG/tItx7wSUl0Kr6nPbhzBMxtAM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=juk1XT3AnE1Bq++0BvJmEbXeFFtlWBr6eIkkzMcVZMCvpC74IVDCzBeJ3fo8+SwiC mzy2KvYr/S2vZyRfs+SBQ== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by wpaz5.hot.corp.google.com with ESMTP id o9I8fPJO019569 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 01:41:25 -0700 Received: by gwb11 with SMTP id 11so256588gwb.16 for <httpstreaming@ietf.org>; Mon, 18 Oct 2010 01:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=COXWDxaDdsYgSIwhc8SZpISISXdf/+r9rFCZzkHVmag=; b=poqJSwi5jPaqiHpvaF95kAeapcyU7xhg79XOAo9W7jDuM2cBs75L8x2DJy2CEvHZYG 2+nBA9xD/ZaSsGbJMJbA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=HL23S22toCdf1Eqh8aPL9GKCi1STM/Y/gIo0TTKLXBDfxzIvJySgKsSWyNXABHGzDn D4mc0ACUixY9duBDKxDw== MIME-Version: 1.0 Received: by 10.90.52.6 with SMTP id z6mr1232051agz.145.1287391283768; Mon, 18 Oct 2010 01:41:23 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Mon, 18 Oct 2010 01:41:23 -0700 (PDT) In-Reply-To: <043601cb6e9c$6719f8e0$30298a0a@china.huawei.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540D6894A4@xmb-sjc-215.amer.cisco.com> <02d501cb6e87$9dc75dc0$30298a0a@china.huawei.com> <03c001cb6e95$3edf86d0$30298a0a@china.huawei.com> <03f101cb6e97$f582acd0$30298a0a@china.huawei.com> <043601cb6e9c$6719f8e0$30298a0a@china.huawei.com> Date: Mon, 18 Oct 2010 01:41:23 -0700 Message-ID: <AANLkTimok+Gi7tayPJhPhwO4uxzhWs8Fk+a6reH+N0mQ@mail.gmail.com> From: Wenbo Zhu <wenboz@google.com> To: Qin Wu <sunseawq@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 18 Oct 2010 08:40:01 -0000 On Mon, Oct 18, 2010 at 1:13 AM, Qin Wu <sunseawq@huawei.com> wrote: > ----- Original Message ----- > From: "Thomas Stockhammer" <stockhammer@nomor.de> > To: "Qin Wu" <sunseawq@huawei.com> > Cc: "Ali C. Begen (abegen)" <abegen@cisco.com>; "Roni Even" <Even.roni@hu= awei.com>; "David A. Bryan" <dbryan@ethernot.org>; <httpstreaming@ietf.org> > Sent: Monday, October 18, 2010 3:58 PM > Subject: Re: [httpstreaming] Push Vs Pull Re: Current Status and Our Goal > > >>>> How would this work if you have only one bitrate on the server? Is you= r approach as follows: >>>> >>>> Rather than offering the same content encoded at multiple bitrates and= serving them based on what the client wants, you >>>> wanna serve the content encoded at a single bitrate and by manipulatin= g the transmission rate on the server (based on >>>> server's knowledge of network and client), you "adaptively" send it. I= s that the scenario you have in mind? >>>> >>>> [Qin]: Personally that is what I am trying to look for. a single birat= e for live content may change at time which can be >>>> realized by transcoding. >>> >>> If you are saying a server doing transcoding for adaptation scales bett= er than an http server serving client requests for different chunks, then I= think you should make your arguments clear enough in the problem statement= draft and see whether others think. To me, it is a losing proposition. >>> >>> [Qin]; for the live content consuming with thousands of consumers viewi= ng at the same time, in my opinion, it may be a successful propsotion. >> >> [T] Adaptation for each of the thousands of users!? =A0[\T] >> >> [Qin]: The scenario we are talking about is more and more people watchin= g one popuar global event at the same time, e.g., world cup finals, US pres= ident election, Olympic games. > > > [T] > Exactly! And therefore individual server side adaptation is worst ... > To maintain a 1-1 relationship between the client and the server breaks s= calability. > Just offer a couple of bitrate choices and the millions of clients will p= ick the one that suits them. Clients are extremely intelligent and capable = nowadays. > Network-initiated individual QoS control is not a subject in HTTP streami= ng. > [\T] > > [Qin]: It seems you talk about server based solution in your vision which= I can't follow. In my understanding, client based solution more fit for re= corded content consuming than live content consuming. > The big problem of current existing client based solution can not well sa= tisfy real time streaming requirements during live content consuming. I'd suggest we focus on the unique challenges that HTTP brings, i.e. as a transport protocol, such as it enforces strict client-server RPC and has to live with intermediaries such as proxy. Discussions on specific client, network, or server designs in the general context of media streaming over Internet, IMO, are mostly irrelevant. - Wenbo > > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 9789= 80 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH =A0- =A0Sitz der Gesellschaft: M=FCnchen - Registerge= richt: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 - Gesch=E4fts= f=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. > > > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > From csp@csperkins.org Tue Oct 19 10:15:25 2010 Return-Path: <csp@csperkins.org> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C503D3A68F1 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 10:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.45 X-Spam-Level: X-Spam-Status: No, score=-103.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SQCRskOnOXm for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 10:15:21 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 5028F3A68C2 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 10:15:18 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8Fns-0002ie-j3; Tue, 19 Oct 2010 17:16:49 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Colin Perkins <csp@csperkins.org> X-Priority: 3 In-Reply-To: <051901cb6c38$8b640f30$30298a0a@china.huawei.com> Date: Tue, 19 Oct 2010 18:16:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <051901cb6c38$8b640f30$30 298a0a@china.huawei.com> To: Qin Wu <sunseawq@huawei.com> X-Mailer: Apple Mail (2.1081) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Oct 2010 17:15:25 -0000 On 15 Oct 2010, at 08:14, Qin Wu wrote: > ----- Original Message -----=20 > From: "Ali C. Begen (abegen)" <abegen@cisco.com> > To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> > Cc: <httpstreaming@ietf.org> > Sent: Friday, October 15, 2010 1:14 PM > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 >=20 >> But, in http streaming scenario, the ratio of download/upload (from = the client's perspective) is much larger than 1. BTW, if you keep your = chunk duration relatively longer, the amount of requests that you will = end up sending will be almost nil compared to what you will receive. >>=20 >> [Qin]: No, I just compare pull and push with the same chunk duration. >=20 > You can choose whatever chunk size you wanna use. Does not matter. The = fact remains the same. Unless someone uses chunks of a few hundreds of = ms, it won't matter. >=20 > [Qin]: Suppose 10 chunks is available at the server side, in the pull = model, the client need to send at least 10 requests and receive 10 = responses. in the push model, the client may only need to send one = request and then receive 10 responses. comparing with pull, push model = save 9 requests. also if you look at websocket, push has more = lightweight header than pull. This is true. However, by changing to a push model, you also move the = responsibility for maintaining state for rate adaptation to the server, = rather than the client. The extra state, and the complexity of running = the rate adaptation algorithm, almost certainly outweighs the savings = from reduced request processing. --=20 Colin Perkins http://csperkins.org/ From oran@cisco.com Tue Oct 19 10:45:32 2010 Return-Path: <oran@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E71E93A67C2 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 10:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.301 X-Spam-Level: X-Spam-Status: No, score=-110.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JyRN9IT3THf for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 10:45:31 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 23D903A67AB for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 10:45:31 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: PGP.sig : 194 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK52vUxAZnwN/2dsb2JhbAChaXGmcZxZhUoEikuDBA X-IronPort-AV: E=Sophos;i="4.57,351,1283731200"; d="sig'?scan'208";a="172582435" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Oct 2010 17:47:01 +0000 Received: from OranMBP.local (stealth-10-32-245-153.cisco.com [10.32.245.153]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9JHkf5I000491 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 17:47:00 GMT Received: from [127.0.0.1] by OranMBP.local (PGP Universal service); Tue, 19 Oct 2010 13:47:01 -0400 X-PGP-Universal: processed; by OranMBP.local on Tue, 19 Oct 2010 13:47:01 -0400 Mime-Version: 1.0 (Apple Message framework v1081) From: David R Oran <oran@cisco.com> X-Priority: 3 In-Reply-To: <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org> Date: Tue, 19 Oct 2010 13:46:35 -0400 Message-Id: <51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <051901cb6c38$8b640f30$30 298a0a@china.huawei.com> <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org> To: Colin Perkins <csp@csperkins.org> X-Mailer: Apple Mail (2.1081) X-PGP-Encoding-Format: MIME X-PGP-Encoding-Version: 2.0.2 Content-Type: multipart/signed; boundary="PGP_Universal_367ADC9D_F21080C8_96AE7A95_453E1CBA"; protocol="application/pgp-signature"; micalg="pgp-sha1" Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Oct 2010 17:45:33 -0000 --PGP_Universal_367ADC9D_F21080C8_96AE7A95_453E1CBA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote: > On 15 Oct 2010, at 08:14, Qin Wu wrote: >> ----- Original Message -----=20 >> From: "Ali C. Begen (abegen)" <abegen@cisco.com> >> To: "Qin Wu" <sunseawq@huawei.com>; "Roni Even" = <Even.roni@huawei.com>; "David A. Bryan" <dbryan@ethernot.org> >> Cc: <httpstreaming@ietf.org> >> Sent: Friday, October 15, 2010 1:14 PM >> Subject: RE: [httpstreaming] Current Status and Our Goal >>=20 >>=20 >>> But, in http streaming scenario, the ratio of download/upload (from = the client's perspective) is much larger than 1. BTW, if you keep your = chunk duration relatively longer, the amount of requests that you will = end up sending will be almost nil compared to what you will receive. >>>=20 >>> [Qin]: No, I just compare pull and push with the same chunk = duration. >>=20 >> You can choose whatever chunk size you wanna use. Does not matter. = The fact remains the same. Unless someone uses chunks of a few hundreds = of ms, it won't matter. >>=20 >> [Qin]: Suppose 10 chunks is available at the server side, in the pull = model, the client need to send at least 10 requests and receive 10 = responses. in the push model, the client may only need to send one = request and then receive 10 responses. comparing with pull, push model = save 9 requests. also if you look at websocket, push has more = lightweight header than pull. >=20 >=20 > This is true. However, by changing to a push model, you also move the = responsibility for maintaining state for rate adaptation to the server, = rather than the client. The extra state, and the complexity of running = the rate adaptation algorithm, almost certainly outweighs the savings = from reduced request processing. >=20 That is debatable. I personally side with Colin in such a debate, but = there are people who do make credible arguments on the other side, and = people who ship cost-effective and arguably scalable systems that work = that way. What I wonder is if the IETF is a productive venue to hold that debate. = I suspect not. The IETF never was able to stop IMS, and the ITU was never able to stop = the Internet, hard as both tried. Cheers, DaveO. > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming --PGP_Universal_367ADC9D_F21080C8_96AE7A95_453E1CBA Content-Type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig Content-Disposition: attachment; filename=PGP.sig -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.0.2 (Build 13) iQA/AwUBTL3ZjI1mhLZU3SrmEQL1mwCg5c2TrBq1ho/CCT2CpZrjL1aOVcoAoJ6S RcQELLFn8lqgxxcRk8jikJni =eEJS -----END PGP SIGNATURE----- --PGP_Universal_367ADC9D_F21080C8_96AE7A95_453E1CBA-- From luby@qualcomm.com Tue Oct 19 14:23:10 2010 Return-Path: <luby@qualcomm.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 171343A694C for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 14:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCDLs68HlhGD for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 14:23:09 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id F38FB3A6925 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 14:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1287523480; x=1319059480; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20<luby@qualcomm.com>|To:=20"h ttpstreaming@ietf.org"=20<httpstreaming@ietf.org>|Date: =20Tue,=2019=20Oct=202010=2014:24:38=20-0700|Subject:=20B AR=20BOF=20at=20IETF=20for=20HTTP=20Streaming |Thread-Topic:=20BAR=20BOF=20at=20IETF=20for=20HTTP=20Str eaming|Thread-Index:=20ActqQCT6JAn3DlvXSDmGxPbhxkQQbgFk+O 4I|Message-ID:=20<C8E35AA6.5A42%luby@qualcomm.com> |In-Reply-To:=20<mailman.80.1286910020.32638.httpstreamin g@ietf.org>|Accept-Language:=20en-US|Content-Language:=20 en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent: =20Microsoft-Entourage/13.6.0.100712|acceptlanguage:=20en -US|Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=q2Ivcb3pXOoT0dAaaGVQoth13HswsM1uIhnCL1YSCxA=; b=VZBGHiQvas/B9CYiYA+jSmf0GHqTOXA3SRa8S5Z03Q2zO0r7bY7EboDD t3BkLAvzn1K0I8t+Bci/GThuBL0bjh+jlqjnbJd3jol68a9YdYgwud9RL JfvVVitIbfhSF0UhP1xFDlWrMhWwVDCG9U2chyvmbgSZSkqhcGfqNVAZS 8=; X-IronPort-AV: E=McAfee;i="5400,1158,6141"; a="58451740" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 19 Oct 2010 14:24:40 -0700 X-IronPort-AV: E=Sophos;i="4.57,350,1283756400"; d="scan'208";a="89761254" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 19 Oct 2010 14:24:40 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 19 Oct 2010 14:24:39 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Tue, 19 Oct 2010 14:24:28 -0700 From: "Luby, Michael" <luby@qualcomm.com> To: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Date: Tue, 19 Oct 2010 14:24:38 -0700 Thread-Topic: BAR BOF at IETF for HTTP Streaming Thread-Index: ActqQCT6JAn3DlvXSDmGxPbhxkQQbgFk+O4I Message-ID: <C8E35AA6.5A42%luby@qualcomm.com> In-Reply-To: <mailman.80.1286910020.32638.httpstreaming@ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.6.0.100712 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Oct 2010 21:23:10 -0000 I will not be going to the upcoming IETF, so it would be good to summarize any important discussions that occur at the BAR BOF and get comments from people on the list who can't make it to the BAR BOF as well. (I'm sure ther= e are many others in the same situation as I) On 10/12/10 12:00 PM, "httpstreaming-request@ietf.org" <httpstreaming-request@ietf.org> wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to >=20 > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. >=20 >=20 >=20 > Send httpstreaming mailing list submissions to > httpstreaming@ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/httpstreaming > or, via email, send a message with subject or body 'help' to > httpstreaming-request@ietf.org >=20 > You can reach the person managing the list at > httpstreaming-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of httpstreaming digest..." From ben@niven-jenkins.co.uk Tue Oct 19 15:07:11 2010 Return-Path: <ben@niven-jenkins.co.uk> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E22B3A693C for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 15:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4689JTJfiyhL for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 15:07:06 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by core3.amsl.com (Postfix) with ESMTP id 984103A68E3 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 15:06:56 -0700 (PDT) Received: from host86-170-51-184.range86-170.btcentralplus.com ([86.170.51.184] helo=unknown-00-22-43-25-f9-66.home) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <ben@niven-jenkins.co.uk>) id 1P8KLz-0005qv-C4; Tue, 19 Oct 2010 23:08:19 +0100 References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <051901cb6c38$8b640f30$30 298a0a@china.huawei.com> <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org> <51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com> In-Reply-To: <51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com> Mime-Version: 1.0 (Apple Message framework v1078) X-Priority: 3 Content-Type: text/plain; charset=us-ascii Message-Id: <A3727C89-8DF3-48A7-9B5D-9D11A94930F0@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk> Date: Tue, 19 Oct 2010 23:08:17 +0100 To: David R Oran <oran@cisco.com> X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Oct 2010 22:07:11 -0000 On 19 Oct 2010, at 18:46, David R Oran wrote: >=20 > On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote: >=20 >> On 15 Oct 2010, at 08:14, Qin Wu wrote: >>> ----- Original Message -----=20 >>> From: "Ali C. Begen (abegen)" <abegen@cisco.com> >>>=20 >>>> But, in http streaming scenario, the ratio of download/upload (from = the client's perspective) is much larger than 1. BTW, if you keep your = chunk duration relatively longer, the amount of requests that you will = end up sending will be almost nil compared to what you will receive. >>>>=20 >>>> [Qin]: No, I just compare pull and push with the same chunk = duration. >>>=20 >>> You can choose whatever chunk size you wanna use. Does not matter. = The fact remains the same. Unless someone uses chunks of a few hundreds = of ms, it won't matter. >>>=20 >>> [Qin]: Suppose 10 chunks is available at the server side, in the = pull model, the client need to send at least 10 requests and receive 10 = responses. in the push model, the client may only need to send one = request and then receive 10 responses. comparing with pull, push model = save 9 requests. also if you look at websocket, push has more = lightweight header than pull. >>=20 >> This is true. However, by changing to a push model, you also move = the responsibility for maintaining state for rate adaptation to the = server, rather than the client. The extra state, and the complexity of = running the rate adaptation algorithm, almost certainly outweighs the = savings from reduced request processing. >>=20 > That is debatable. I personally side with Colin in such a debate, but = there are people who do make credible arguments on the other side, and = people who ship cost-effective and arguably scalable systems that work = that way. While that may be true, I doubt they're based on HTTP. I thought the pretence of creating this list was to discuss if there was = work that IETF could do to improve "HTTP streaming". Changing the = fundamental model from pull to push is not improving HTTP streaming it's = creating a whole new streaming protocol, which might be a valid thing to = do but is a completely different discussion IMO. Ben From stockhammer@nomor.de Tue Oct 19 15:08:32 2010 Return-Path: <stockhammer@nomor.de> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3F73A68E3 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 15:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[AWL=1.374, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHe8wy78sU6h for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 15:08:30 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id B5E8D3A68A8 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 15:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1287526200; l=2838; s=domk; d=nomor.de; h=To:References:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From: Content-Type:Mime-Version:Subject:X-RZG-CLASS-ID:X-RZG-AUTH; bh=QjQkTkhZU0Qgp+0Jhb6U31rITL4=; b=Qae9WBCCv/9IIwsX07XV7LS8csoXocuBSaxfSqvRd+yRycJLA0PLOnMELX7vA/o0M8G awj8jTcII4Nf8iRNjpAqZO0Q7WckWL66xwOWrJmtmKjgviLmEoqvQgDzz7GRuQE6Ty/Ex 8MSOzbbuFgZOK9aLhsRjPS4WzzGCjkcGelU= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu13+0wBefkJA5cHz4sK4A== X-RZG-CLASS-ID: mo00 Received: from [172.16.1.2] (91-67-202-136-dynip.superkabel.de [91.67.202.136]) by post.strato.de (jimi mo62) (RZmta 23.5) with ESMTP id v04e74m9JIwfNA ; Wed, 20 Oct 2010 00:09:54 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Thomas Stockhammer <stockhammer@nomor.de> X-Priority: 3 In-Reply-To: <A3727C89-8DF3-48A7-9B5D-9D11A94930F0@niven-jenkins.co.uk> Date: Wed, 20 Oct 2010 00:09:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F840E8B-3605-4F2B-A797-A8873257C140@nomor.de> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <051901cb6c38$8b640f30$30 298a0a@china.huawei.com> <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org> <51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com> <A3727C89-8DF3-48A7-9B5D-9D11A94930F0@niven-jenkins.co.uk> To: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk> X-Mailer: Apple Mail (2.1081) Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Oct 2010 22:08:32 -0000 +1 On Oct 20, 2010, at 12:08 AM, Benjamin Niven-Jenkins wrote: >=20 > On 19 Oct 2010, at 18:46, David R Oran wrote: >>=20 >> On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote: >>=20 >>> On 15 Oct 2010, at 08:14, Qin Wu wrote: >>>> ----- Original Message -----=20 >>>> From: "Ali C. Begen (abegen)" <abegen@cisco.com> >>>>=20 >>>>> But, in http streaming scenario, the ratio of download/upload = (from the client's perspective) is much larger than 1. BTW, if you keep = your chunk duration relatively longer, the amount of requests that you = will end up sending will be almost nil compared to what you will = receive. >>>>>=20 >>>>> [Qin]: No, I just compare pull and push with the same chunk = duration. >>>>=20 >>>> You can choose whatever chunk size you wanna use. Does not matter. = The fact remains the same. Unless someone uses chunks of a few hundreds = of ms, it won't matter. >>>>=20 >>>> [Qin]: Suppose 10 chunks is available at the server side, in the = pull model, the client need to send at least 10 requests and receive 10 = responses. in the push model, the client may only need to send one = request and then receive 10 responses. comparing with pull, push model = save 9 requests. also if you look at websocket, push has more = lightweight header than pull. >>>=20 >>> This is true. However, by changing to a push model, you also move = the responsibility for maintaining state for rate adaptation to the = server, rather than the client. The extra state, and the complexity of = running the rate adaptation algorithm, almost certainly outweighs the = savings from reduced request processing. >>>=20 >> That is debatable. I personally side with Colin in such a debate, but = there are people who do make credible arguments on the other side, and = people who ship cost-effective and arguably scalable systems that work = that way. >=20 > While that may be true, I doubt they're based on HTTP. >=20 > I thought the pretence of creating this list was to discuss if there = was work that IETF could do to improve "HTTP streaming". Changing the = fundamental model from pull to push is not improving HTTP streaming it's = creating a whole new streaming protocol, which might be a valid thing to = do but is a completely different discussion IMO. >=20 > Ben >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From csp@csperkins.org Tue Oct 19 15:46:15 2010 Return-Path: <csp@csperkins.org> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF29A3A6868 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 15:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.393 X-Spam-Level: X-Spam-Status: No, score=-103.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYFUxCW820l6 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 15:46:14 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by core3.amsl.com (Postfix) with ESMTP id 785593A6846 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 15:46:14 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.22]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1P8Ky9-0005Z6-Yt; Tue, 19 Oct 2010 22:47:45 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Colin Perkins <csp@csperkins.org> X-Priority: 3 In-Reply-To: <A3727C89-8DF3-48A7-9B5D-9D11A94930F0@niven-jenkins.co.uk> Date: Tue, 19 Oct 2010 23:47:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <BE65A0D2-9294-4576-B3C9-A8E674BF734E@csperkins.org> References: <00df01cb5de2$2ac49730$4f548a0a@china.huawei.com> <AANLkTimB3-=zWGnT=uq9Qcb-N8Pq+-RR0WMN12BZ9pr4@mail.gmail.com> <03f501cb65a1$50699d70$f13cd850$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <03f901cb65a5$7ee4bc80$7cae3580$%roni@huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BEB08@xmb-sjc-215.amer.cisco.com> <074201cb66c1$1a192d50$4f548a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF360@xmb-sjc-215.amer.cisco.com> <017101cb6924$bc093410$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D5BF70B@xmb-sjc-215.amer.cisco.com> <03ce01cb6b67$fdb9d910$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689385@xmb-sjc-215.amer.cisco.com> <009c01cb6c03$f2125320$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D689412@xmb-sjc-215.amer.cisco.com> <022c01cb6c0b$5fc75490$30298a0a@china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540D68946C@xmb-sjc-215.amer.cisco.com> <051901cb6c38$8b640f30$30 298a0a@china.huawei.com> <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org> <51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com> <A3727C89-8DF3-48A7-9B5D-9D11A94930F0@niven-jenkins.co.uk> To: Benjamin Niven-Jenkins <ben@niven-jenkins.co.uk> X-Mailer: Apple Mail (2.1081) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 19 Oct 2010 22:46:15 -0000 On 19 Oct 2010, at 23:08, Benjamin Niven-Jenkins wrote: > On 19 Oct 2010, at 18:46, David R Oran wrote: >>=20 >> On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote: >>> On 15 Oct 2010, at 08:14, Qin Wu wrote: >>>> ----- Original Message -----=20 >>>> From: "Ali C. Begen (abegen)" <abegen@cisco.com> >>>>=20 >>>>> But, in http streaming scenario, the ratio of download/upload = (from the client's perspective) is much larger than 1. BTW, if you keep = your chunk duration relatively longer, the amount of requests that you = will end up sending will be almost nil compared to what you will = receive. >>>>>=20 >>>>> [Qin]: No, I just compare pull and push with the same chunk = duration. >>>>=20 >>>> You can choose whatever chunk size you wanna use. Does not matter. = The fact remains the same. Unless someone uses chunks of a few hundreds = of ms, it won't matter. >>>>=20 >>>> [Qin]: Suppose 10 chunks is available at the server side, in the = pull model, the client need to send at least 10 requests and receive 10 = responses. in the push model, the client may only need to send one = request and then receive 10 responses. comparing with pull, push model = save 9 requests. also if you look at websocket, push has more = lightweight header than pull. >>>=20 >>> This is true. However, by changing to a push model, you also move = the responsibility for maintaining state for rate adaptation to the = server, rather than the client. The extra state, and the complexity of = running the rate adaptation algorithm, almost certainly outweighs the = savings from reduced request processing. >>>=20 >> That is debatable. I personally side with Colin in such a debate, but = there are people who do make credible arguments on the other side, and = people who ship cost-effective and arguably scalable systems that work = that way. >=20 > While that may be true, I doubt they're based on HTTP. >=20 > I thought the pretence of creating this list was to discuss if there = was work that IETF could do to improve "HTTP streaming". Changing the = fundamental model from pull to push is not improving HTTP streaming it's = creating a whole new streaming protocol, which might be a valid thing to = do but is a completely different discussion IMO. That depends on how narrow a view you take of "HTTP streaming". There = are certainly ways in which one can building adaptive streaming video = systems that push media data over a single HTTP connection with sender = controlled rate switching. Is the aim of this list to discuss HTTP = streaming in the general case, or only one particular, pull-based, = incarnation of it?=20 --=20 Colin Perkins http://csperkins.org/ From spencer@wonderhamster.org Tue Oct 19 23:16:11 2010 Return-Path: <spencer@wonderhamster.org> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059C73A69D0 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 23:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.274 X-Spam-Level: X-Spam-Status: No, score=-101.274 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, LONGWORDS=1.803, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ok0qZtWM2yzI for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 23:16:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id E0B4C3A69D5 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 23:16:02 -0700 (PDT) Received: from S73602b ([12.172.14.11]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M2387-1OoIhw3QhH-00tLkj; Wed, 20 Oct 2010 02:17:31 -0400 Message-ID: <DA6680C8B68A4F06B812E9A7FF8357A6@china.huawei.com> From: "Spencer Dawkins" <spencer@wonderhamster.org> To: "Colin Perkins" <csp@csperkins.org>, "Benjamin Niven-Jenkins" <ben@niven-jenkins.co.uk> References: 298a0a@china.huawei.com><62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org><51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com><A3727C89-8DF3-48A7-9B5D-9D11A94930F0@niven-jenkins.co.uk> <BE65A0D2-9294-4576-B3C9-A8E674BF734E@csperkins.org> Date: Wed, 20 Oct 2010 01:17:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Provags-ID: V02:K0:Ss5zfLfUgCJE+d6oG/RaVKtqW8GP11Cv1VDF7VeAVEA 7AD3aWJm7a0ANRe+nQ9uf+/QrKTtUkt9ZDNydCr6ZOU4qWyGBL ab6A9YcVpRFv4w+DbJIduXqGIGO2rC6K7Ea/8CwRSbKJ+z52II h5LT9gJPlvtld5UN5uhYZPgqhkcqaBiWOPVwC3N2FYe0oavWaQ FvBOLv+kpki8AehPrTLU6mWRgGeEVA3zpG173n2eU4= Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Oct 2010 06:16:11 -0000 ----- Original Message ----- From: "Colin Perkins" <csp@csperkins.org> To: "Benjamin Niven-Jenkins" <ben@niven-jenkins.co.uk> Cc: <httpstreaming@ietf.org> Sent: Tuesday, October 19, 2010 5:47 PM Subject: Re: [httpstreaming] Current Status and Our Goal > On 19 Oct 2010, at 23:08, Benjamin Niven-Jenkins wrote: >> On 19 Oct 2010, at 18:46, David R Oran wrote: >>> >>> On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote: >>>> On 15 Oct 2010, at 08:14, Qin Wu wrote: >>>>> ----- Original Message ----- >>>>> From: "Ali C. Begen (abegen)" <abegen@cisco.com> >>>>> >>>>>> But, in http streaming scenario, the ratio of download/upload (from >>>>>> the client's perspective) is much larger than 1. BTW, if you keep >>>>>> your chunk duration relatively longer, the amount of requests that >>>>>> you will end up sending will be almost nil compared to what you will >>>>>> receive. >>>>>> >>>>>> [Qin]: No, I just compare pull and push with the same chunk duration. >>>>> >>>>> You can choose whatever chunk size you wanna use. Does not matter. The >>>>> fact remains the same. Unless someone uses chunks of a few hundreds of >>>>> ms, it won't matter. >>>>> >>>>> [Qin]: Suppose 10 chunks is available at the server side, in the pull >>>>> model, the client need to send at least 10 requests and receive 10 >>>>> responses. in the push model, the client may only need to send one >>>>> request and then receive 10 responses. comparing with pull, push model >>>>> save 9 requests. also if you look at websocket, push has more >>>>> lightweight header than pull. >>>> >>>> This is true. However, by changing to a push model, you also move the >>>> responsibility for maintaining state for rate adaptation to the server, >>>> rather than the client. The extra state, and the complexity of running >>>> the rate adaptation algorithm, almost certainly outweighs the savings >>>> from reduced request processing. >>>> >>> That is debatable. I personally side with Colin in such a debate, but >>> there are people who do make credible arguments on the other side, and >>> people who ship cost-effective and arguably scalable systems that work >>> that way. >> >> While that may be true, I doubt they're based on HTTP. >> >> I thought the pretence of creating this list was to discuss if there was >> work that IETF could do to improve "HTTP streaming". Changing the >> fundamental model from pull to push is not improving HTTP streaming it's >> creating a whole new streaming protocol, which might be a valid thing to >> do but is a completely different discussion IMO. > > > That depends on how narrow a view you take of "HTTP streaming". There are > certainly ways in which one can building adaptive streaming video systems > that push media data over a single HTTP connection with sender controlled > rate switching. Is the aim of this list to discuss HTTP streaming in the > general case, or only one particular, pull-based, incarnation of it? To land somewhere between Colin and Ben, it would be helpful to decide how much the general-case HTTP model can change before it is no longer HTTP, but some other protocol. If I'm understanding the discussion to date, we're somewhere close to Normal HTTP Also under discussion on this list ================================================================ client-initiated (pull) server-initiated (push) unicast multicast unmodified proxies modified proxies unmodified servers modified servers Is this the way other people think the discussion has gone? What else did I miss? Thanks, Spencer From wenboz@google.com Tue Oct 19 23:27:29 2010 Return-Path: <wenboz@google.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06FFB3A69B9 for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 23:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUfZ6eyhDl2T for <httpstreaming@core3.amsl.com>; Tue, 19 Oct 2010 23:27:28 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 84E513A69AA for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 23:27:27 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id o9K6SwdD012748 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 23:28:58 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1287556139; bh=lPOEez3dFBqnP6K1Up5LyyFAPDE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Rq1aV93YJjtvQN+kp042j4GRVEnKBCNrKyQkdg5kGd9GvtTgBdn4S/s1f2zj+ID+b D8oswj9tmvmEi1cuPAlCw== Received: from gxk27 (gxk27.prod.google.com [10.202.11.27]) by hpaq1.eem.corp.google.com with ESMTP id o9K6St1H017442 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 23:28:57 -0700 Received: by gxk27 with SMTP id 27so1960734gxk.14 for <httpstreaming@ietf.org>; Tue, 19 Oct 2010 23:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=X8HshMbPKIDKy6U3NJMQSMHMXdk7YWe7uBP0P0V4bfI=; b=WrDabZ90mLCsoZ5pTJbBnan3BIiaZsp/+xWCERIDYDRzbL5JL2X1EG2+2irZMH4rhN J7IdTip0Qka3RtWH9xBQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gtZHwKnIxuLurelT0ZQBvs/qzbIjH1WoK5AJulfGOJN9THcg5GFw3lIplsTW+yQ4nG hYNAfOwcJI7rWqY1yX+w== MIME-Version: 1.0 Received: by 10.90.36.14 with SMTP id j14mr215673agj.80.1287556135637; Tue, 19 Oct 2010 23:28:55 -0700 (PDT) Received: by 10.91.213.18 with HTTP; Tue, 19 Oct 2010 23:28:55 -0700 (PDT) In-Reply-To: <DA6680C8B68A4F06B812E9A7FF8357A6@china.huawei.com> References: <62FF99A9-9B06-459F-87B4-416007E80983@csperkins.org> <51D0062B-D4D8-4495-8FC6-E50E5D67086E@cisco.com> <A3727C89-8DF3-48A7-9B5D-9D11A94930F0@niven-jenkins.co.uk> <BE65A0D2-9294-4576-B3C9-A8E674BF734E@csperkins.org> <DA6680C8B68A4F06B812E9A7FF8357A6@china.huawei.com> Date: Tue, 19 Oct 2010 23:28:55 -0700 Message-ID: <AANLkTi=WtPXVSrH8-oMG4B_NjX-qeL3P=fwyGJfYgPOC@mail.gmail.com> From: Wenbo Zhu <wenboz@google.com> To: Spencer Dawkins <spencer@wonderhamster.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: httpstreaming@ietf.org, Colin Perkins <csp@csperkins.org> Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Oct 2010 06:27:29 -0000 Nice call .. as I had found it difficult to follow this thread. > Normal HTTP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Also under discussion on = this list > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > client-initiated (pull) =A0 =A0 =A0 server-initiated (push) HTTP never has problems to support push (as efficient as you can possibly do with TCP), out of its native semantics. Most known issues are related to browsers or proxies. Unless you are talking about p2p style of push, which requires the client to expose its own end-point, then there is not much to explore at the transport level. Or if we are talking about pull vs push at the application level, then we need make sure the transport is involved, as otherwise it's simply becoming a design/system issue. On Tue, Oct 19, 2010 at 11:17 PM, Spencer Dawkins <spencer@wonderhamster.org> wrote: > > ----- Original Message ----- From: "Colin Perkins" <csp@csperkins.org> > To: "Benjamin Niven-Jenkins" <ben@niven-jenkins.co.uk> > Cc: <httpstreaming@ietf.org> > Sent: Tuesday, October 19, 2010 5:47 PM > Subject: Re: [httpstreaming] Current Status and Our Goal > > >> On 19 Oct 2010, at 23:08, Benjamin Niven-Jenkins wrote: >>> >>> On 19 Oct 2010, at 18:46, David R Oran wrote: >>>> >>>> On Oct 19, 2010, at 1:16 PM, Colin Perkins wrote: >>>>> >>>>> On 15 Oct 2010, at 08:14, Qin Wu wrote: >>>>>> >>>>>> ----- Original Message ----- From: "Ali C. Begen (abegen)" >>>>>> <abegen@cisco.com> >>>>>> >>>>>>> But, in http streaming scenario, the ratio of download/upload (from >>>>>>> the client's perspective) is much larger than 1. BTW, if you keep y= our chunk >>>>>>> duration relatively longer, the amount of requests that you will en= d up >>>>>>> sending will be almost nil compared to what you will receive. >>>>>>> >>>>>>> [Qin]: No, I just compare pull and push with the same chunk duratio= n. >>>>>> >>>>>> You can choose whatever chunk size you wanna use. Does not matter. T= he >>>>>> fact remains the same. Unless someone uses chunks of a few hundreds = of ms, >>>>>> it won't matter. >>>>>> >>>>>> [Qin]: Suppose 10 chunks is available at the server side, in the pul= l >>>>>> model, the client need to send at least 10 requests and receive 10 >>>>>> responses. in the push model, the client may only need to send one r= equest >>>>>> and then receive 10 responses. comparing with pull, push model save = 9 >>>>>> requests. also if you look at websocket, push has more lightweight h= eader >>>>>> than pull. >>>>> >>>>> This is true. =A0However, by changing to a push model, you also move = the >>>>> responsibility for maintaining state for rate adaptation to the serve= r, >>>>> rather than the client. =A0The extra state, and the complexity of run= ning the >>>>> rate adaptation algorithm, almost certainly outweighs the savings fro= m >>>>> reduced request processing. >>>>> >>>> That is debatable. I personally side with Colin in such a debate, but >>>> there are people who do make credible arguments on the other side, and >>>> people who ship cost-effective and arguably scalable systems that work= that >>>> way. >>> >>> While that may be true, I doubt they're based on HTTP. >>> >>> I thought the pretence of creating this list was to discuss if there wa= s >>> work that IETF could do to improve "HTTP streaming". Changing the >>> fundamental model from pull to push is not improving HTTP streaming it'= s >>> creating a whole new streaming protocol, which might be a valid thing t= o do >>> but is a completely different discussion IMO. >> >> >> That depends on how narrow a view you take of "HTTP streaming". There ar= e >> certainly ways in which one can building adaptive streaming video system= s >> that push media data over a single HTTP connection with sender controlle= d >> rate switching. Is the aim of this list to discuss HTTP streaming in the >> general case, or only one particular, pull-based, incarnation of it? > > To land somewhere between Colin and Ben, it would be helpful to decide ho= w > much the general-case HTTP model can change before it is no longer HTTP, = but > some other protocol. > > If I'm understanding the discussion to date, we're somewhere close to > > Normal HTTP =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Also under discussion on = this list > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > client-initiated (pull) =A0 =A0 =A0 server-initiated (push) > unicast =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multicast > unmodified proxies =A0 =A0 =A0 =A0 =A0 =A0modified proxies > unmodified servers =A0 =A0 =A0 =A0 =A0 =A0modified servers > > Is this the way other people think the discussion has gone? > > What else did I miss? > > Thanks, > > Spencer > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > From zongning@huawei.com Wed Oct 20 01:48:28 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF5723A6403 for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 01:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.697 X-Spam-Level: X-Spam-Status: No, score=-99.697 tagged_above=-999 required=5 tests=[AWL=0.798, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGcf5S6Mr-Xi for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 01:48:27 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8CC4F3A6808 for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 01:48:27 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK00728Z71WS@szxga05-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 16:49:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAK00JNUZ70HH@szxga05-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 16:49:49 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAK00EAYZ700N@szxml06-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 16:49:48 +0800 (CST) Date: Wed, 20 Oct 2010 16:49:47 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Roni Even' <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org>, 'Qin Wu' <sunseawq@huawei.com> Message-id: <009e01cb7033$c0607120$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUACo40kUA== Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Oct 2010 08:48:29 -0000 IMO, the issue may not only related to multicast or unicast, but the QoE improvement (e.g. reduce the startup time after user change the channel). If I remember correctly, in the motivation of FCC in AVT, one important concern is that the Retransmission server can store the most recent GoPs and feed them to the client with faster rate than playback to effectively fill the gap between the time point of user channel zapping and next complete GoP. This improvement also applies to unicast based HTTP streaming, right? The above concern also implies that adding some intelligence to intermediaries would improve the streaming performance of HTTP streaming system. To be more specific, having a deep look at the mechanisms of distinguish different types of HTTP traffic (e.g. live streaming with higher timing requirement v.s. normal packet, streaming packet containing I-frame worthy of caching for further usage v.s. normal streaming packet) would be a possible direction for consideration in this list. My two cents. BR, Ning Zong -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Thursday, October 07, 2010 6:15 AM To: Roni Even; David A. Bryan; Qin Wu Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal > 2. Address the startup issue, we have worked in AVT on fast channel/content > change and I think this is relevant also in this case. Are you assuming a multicast environment for http streaming? Ow, the startup issue is not an issue in unicast connections. -acbegen _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From zongning@huawei.com Wed Oct 20 02:44:48 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E4F3A63CB for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 02:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.811 X-Spam-Level: X-Spam-Status: No, score=-99.811 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63j1uH2DtPOB for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 02:44:46 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9F3F43A6359 for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 02:44:46 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAL00BDX1SWBZ@szxga05-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 17:46:09 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAL00CHG1SV69@szxga05-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 17:46:08 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAL007T41SUKU@szxml04-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 17:46:07 +0800 (CST) Date: Wed, 20 Oct 2010 17:46:06 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <009e01cb7033$c0607120$3a298a0a@china.huawei.com> To: 'Ning Zong' <zongning@huawei.com>, "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Roni Even' <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org>, 'Qin Wu' <sunseawq@huawei.com> Message-id: <00b101cb703b$9e5827f0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUACo40kUAACaL4w Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Oct 2010 09:44:48 -0000 Sorry, to be clear, the FCC concern I consider here is limited to live streaming scenario. -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ning Zong Sent: Wednesday, October 20, 2010 4:50 PM To: 'Ali C. Begen (abegen)'; 'Roni Even'; 'David A. Bryan'; 'Qin Wu' Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal IMO, the issue may not only related to multicast or unicast, but the QoE improvement (e.g. reduce the startup time after user change the channel). If I remember correctly, in the motivation of FCC in AVT, one important concern is that the Retransmission server can store the most recent GoPs and feed them to the client with faster rate than playback to effectively fill the gap between the time point of user channel zapping and next complete GoP. This improvement also applies to unicast based HTTP streaming, right? The above concern also implies that adding some intelligence to intermediaries would improve the streaming performance of HTTP streaming system. To be more specific, having a deep look at the mechanisms of distinguish different types of HTTP traffic (e.g. live streaming with higher timing requirement v.s. normal packet, streaming packet containing I-frame worthy of caching for further usage v.s. normal streaming packet) would be a possible direction for consideration in this list. My two cents. BR, Ning Zong -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: Thursday, October 07, 2010 6:15 AM To: Roni Even; David A. Bryan; Qin Wu Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal > 2. Address the startup issue, we have worked in AVT on fast channel/content > change and I think this is relevant also in this case. Are you assuming a multicast environment for http streaming? Ow, the startup issue is not an issue in unicast connections. -acbegen _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From abegen@cisco.com Wed Oct 20 04:21:35 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137D53A67A7 for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 04:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVlotfSeDx5r for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 04:21:33 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BD7B73A679F for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 04:21:21 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC9uvkyrR7Hu/2dsb2JhbAChWHGhKZxIhUoEhFWJAA X-IronPort-AV: E=Sophos;i="4.57,355,1283731200"; d="scan'208";a="272473171" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Oct 2010 11:22:54 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9KBMsr4028179; Wed, 20 Oct 2010 11:22:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 04:22:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 04:21:58 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D758E3E@xmb-sjc-215.amer.cisco.com> In-Reply-To: <009e01cb7033$c0607120$3a298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUACo40kUAAFthCg References: <04CAD96D4C5A3D48B1919248A8FE0D540D5BEADB@xmb-sjc-215.amer.cisco.com> <009e01cb7033$c0607120$3a298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Ning Zong" <zongning@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org>, "Qin Wu" <sunseawq@huawei.com> X-OriginalArrivalTime: 20 Oct 2010 11:22:54.0704 (UTC) FILETIME=[23E0A700:01CB7049] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Oct 2010 11:21:35 -0000 When the traffic is unicast, you don't have the problems we have in a = multicast environment. The unicast traffic will naturally start from a = random access point. You might need some initialization data to start = decoding or whatever, but all that comes from the server over unicast = anyway. The same applies to both on-demand and live content.=20 -acbegen > -----Original Message----- > From: Ning Zong [mailto:zongning@huawei.com] > Sent: Wednesday, October 20, 2010 11:50 AM > To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu' > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 > IMO, the issue may not only related to multicast or unicast, but the = QoE > improvement (e.g. reduce the startup time after user change the = channel). If > I remember correctly, in the motivation of FCC in AVT, one important = concern > is that the Retransmission server can store the most recent GoPs and = feed > them to the client with faster rate than playback to effectively fill = the > gap between the time point of user channel zapping and next complete = GoP. > This improvement also applies to unicast based HTTP streaming, right? > The above concern also implies that adding some intelligence to > intermediaries would improve the streaming performance of HTTP = streaming > system. To be more specific, having a deep look at the mechanisms of > distinguish different types of HTTP traffic (e.g. live streaming with = higher > timing requirement v.s. normal packet, streaming packet containing = I-frame > worthy of caching for further usage v.s. normal streaming packet) = would be a > possible direction for consideration in this list. >=20 > My two cents. >=20 > BR, > Ning Zong >=20 > -----Original Message----- > From: httpstreaming-bounces@ietf.org = [mailto:httpstreaming-bounces@ietf.org] > On Behalf Of Ali C. Begen (abegen) > Sent: Thursday, October 07, 2010 6:15 AM > To: Roni Even; David A. Bryan; Qin Wu > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal >=20 > > 2. Address the startup issue, we have worked in AVT on fast > channel/content > > change and I think this is relevant also in this case. >=20 > Are you assuming a multicast environment for http streaming? Ow, the = startup > issue is not an issue in unicast connections. >=20 > -acbegen > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From zongning@huawei.com Wed Oct 20 05:17:26 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED6F3A67E7 for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 05:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.897 X-Spam-Level: X-Spam-Status: No, score=-99.897 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAn1hg-+Vr6x for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 05:17:25 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2B4FA3A677C for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 05:17:25 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAL00F6T8VBGI@szxga04-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 20:18:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAL00F1C8VBH1@szxga04-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 20:18:47 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAL0077T8VBNK@szxml04-in.huawei.com> for httpstreaming@ietf.org; Wed, 20 Oct 2010 20:18:47 +0800 (CST) Date: Wed, 20 Oct 2010 20:18:46 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D758E3E@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Roni Even' <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org>, 'Qin Wu' <sunseawq@huawei.com> Message-id: <00c701cb7050$f24035a0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUACo40kUAAFthCgAAGf3FA= Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Oct 2010 12:17:26 -0000 -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Wednesday, October 20, 2010 7:22 PM To: Ning Zong; Roni Even; David A. Bryan; Qin Wu Cc: httpstreaming@ietf.org Subject: RE: [httpstreaming] Current Status and Our Goal When the traffic is unicast, you don't have the problems we have in a multicast environment. The unicast traffic will naturally start from a random access point. [ZN]: I am a little bit confused by the word "naturally". Do you mean the unicast server will adjust the timing such that the starting packet/segment will always begin with RAP? In fact, not all the HTTP streaming system mandates that the segmentation should align with RAP. You might need some initialization data to start decoding or whatever, but all that comes from the server over unicast anyway. [ZN]: right, but the reference information is not always available to be transmitted at any time point even using unicast, unless there is a cache point. The same applies to both on-demand and live content. -acbegen > -----Original Message----- > From: Ning Zong [mailto:zongning@huawei.com] > Sent: Wednesday, October 20, 2010 11:50 AM > To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu' > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal > > IMO, the issue may not only related to multicast or unicast, but the QoE > improvement (e.g. reduce the startup time after user change the channel). If > I remember correctly, in the motivation of FCC in AVT, one important concern > is that the Retransmission server can store the most recent GoPs and feed > them to the client with faster rate than playback to effectively fill the > gap between the time point of user channel zapping and next complete GoP. > This improvement also applies to unicast based HTTP streaming, right? > The above concern also implies that adding some intelligence to > intermediaries would improve the streaming performance of HTTP streaming > system. To be more specific, having a deep look at the mechanisms of > distinguish different types of HTTP traffic (e.g. live streaming with higher > timing requirement v.s. normal packet, streaming packet containing I-frame > worthy of caching for further usage v.s. normal streaming packet) would be a > possible direction for consideration in this list. > > My two cents. > > BR, > Ning Zong > > -----Original Message----- > From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] > On Behalf Of Ali C. Begen (abegen) > Sent: Thursday, October 07, 2010 6:15 AM > To: Roni Even; David A. Bryan; Qin Wu > Cc: httpstreaming@ietf.org > Subject: Re: [httpstreaming] Current Status and Our Goal > > > 2. Address the startup issue, we have worked in AVT on fast > channel/content > > change and I think this is relevant also in this case. > > Are you assuming a multicast environment for http streaming? Ow, the startup > issue is not an issue in unicast connections. > > -acbegen > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From abegen@cisco.com Wed Oct 20 05:40:30 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93FD53A677D for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 05:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97EX9CAWcJee for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 05:40:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id A53873A694C for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 05:40:22 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADuAvkyrRN+J/2dsb2JhbAChWXGhM5xMhUoEhFWJAA X-IronPort-AV: E=Sophos;i="4.57,355,1283731200"; d="scan'208";a="372715456" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 20 Oct 2010 12:41:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o9KCft6C004845; Wed, 20 Oct 2010 12:41:55 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Oct 2010 05:41:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Oct 2010 05:41:49 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D758E44@xmb-sjc-215.amer.cisco.com> In-Reply-To: <00c701cb7050$f24035a0$3a298a0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] Current Status and Our Goal Thread-Index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUACo40kUAAFthCgAAGf3FAAARH7gA== References: <04CAD96D4C5A3D48B1919248A8FE0D540D758E3E@xmb-sjc-215.amer.cisco.com> <00c701cb7050$f24035a0$3a298a0a@china.huawei.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Ning Zong" <zongning@huawei.com>, "Roni Even" <Even.roni@huawei.com>, "David A. Bryan" <dbryan@ethernot.org>, "Qin Wu" <sunseawq@huawei.com> X-OriginalArrivalTime: 20 Oct 2010 12:41:55.0750 (UTC) FILETIME=[2DC2DC60:01CB7054] Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 20 Oct 2010 12:40:30 -0000 > -----Original Message----- > From: Ning Zong [mailto:zongning@huawei.com] > Sent: Wednesday, October 20, 2010 3:19 PM > To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu' > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 >=20 >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Wednesday, October 20, 2010 7:22 PM > To: Ning Zong; Roni Even; David A. Bryan; Qin Wu > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal >=20 > When the traffic is unicast, you don't have the problems we have in a > multicast environment. The unicast traffic will naturally start from a > random access point. > [ZN]: I am a little bit confused by the word "naturally". Do you mean = the > unicast server will adjust the timing such that the starting = packet/segment > will always begin with RAP? In fact, not all the HTTP streaming system > mandates that the segmentation should align with RAP. Then, that's a pretty poor segmentation or the client simply downloads = data that it will discard. The point is the connection is unicast so the = client gets what it needs. =20 > You might need some initialization data to start decoding or = whatever, but > all that comes from the server over unicast anyway. > [ZN]: right, but the reference information is not always available to = be > transmitted at any time point even using unicast, unless there is a = cache > point. ? That reference information is part of the data the client gets. A = cache cannot produce that data by itself, it needs to see it from = upstream, which means it previously came from the origin server.=20 My point is that the ret. server we had in RAMS is not needed here since = all the servers that can serve the client is one such entity here. They = provide what the client wants, and if they don't have it, they redirect = the client or fetch it for the client. -acbegen =20 > The same applies to both on-demand and live content. >=20 > -acbegen >=20 > > -----Original Message----- > > From: Ning Zong [mailto:zongning@huawei.com] > > Sent: Wednesday, October 20, 2010 11:50 AM > > To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu' > > Cc: httpstreaming@ietf.org > > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > IMO, the issue may not only related to multicast or unicast, but the = QoE > > improvement (e.g. reduce the startup time after user change the = channel). > If > > I remember correctly, in the motivation of FCC in AVT, one important > concern > > is that the Retransmission server can store the most recent GoPs and = feed > > them to the client with faster rate than playback to effectively = fill the > > gap between the time point of user channel zapping and next complete = GoP. > > This improvement also applies to unicast based HTTP streaming, = right? > > The above concern also implies that adding some intelligence to > > intermediaries would improve the streaming performance of HTTP = streaming > > system. To be more specific, having a deep look at the mechanisms of > > distinguish different types of HTTP traffic (e.g. live streaming = with > higher > > timing requirement v.s. normal packet, streaming packet containing = I-frame > > worthy of caching for further usage v.s. normal streaming packet) = would be > a > > possible direction for consideration in this list. > > > > My two cents. > > > > BR, > > Ning Zong > > > > -----Original Message----- > > From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] > > On Behalf Of Ali C. Begen (abegen) > > Sent: Thursday, October 07, 2010 6:15 AM > > To: Roni Even; David A. Bryan; Qin Wu > > Cc: httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > 2. Address the startup issue, we have worked in AVT on fast > > channel/content > > > change and I think this is relevant also in this case. > > > > Are you assuming a multicast environment for http streaming? Ow, the > startup > > issue is not an issue in unicast connections. > > > > -acbegen > > _______________________________________________ > > httpstreaming mailing list > > httpstreaming@ietf.org > > https://www.ietf.org/mailman/listinfo/httpstreaming From zongning@huawei.com Wed Oct 20 17:37:20 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F10C3A68A2 for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 17:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.963 X-Spam-Level: X-Spam-Status: No, score=-99.963 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQZEoRJUYFOX for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 17:37:19 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 485203A657C for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 17:37:19 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00DYF74JNV@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 08:38:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00JPY74HII@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 08:38:42 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAM007Z774HL0@szxml04-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 08:38:41 +0800 (CST) Date: Thu, 21 Oct 2010 08:38:44 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540D758E44@xmb-sjc-215.amer.cisco.com> To: "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'Roni Even' <Even.roni@huawei.com>, "'David A. Bryan'" <dbryan@ethernot.org>, 'Qin Wu' <sunseawq@huawei.com> Message-id: <002101cb70b8$518587b0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActgCGuD1NnF29rfRjaXK8fG462/2gFlt4PwAAEVLUACo40kUAAFthCgAAGf3FAAARH7gAAY7iTQ Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] Current Status and Our Goal X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 21 Oct 2010 00:37:20 -0000 -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Wednesday, October 20, 2010 8:42 PM To: Ning Zong; Roni Even; David A. Bryan; Qin Wu Cc: httpstreaming@ietf.org Subject: RE: [httpstreaming] Current Status and Our Goal > -----Original Message----- > From: Ning Zong [mailto:zongning@huawei.com] > Sent: Wednesday, October 20, 2010 3:19 PM > To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu' > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Wednesday, October 20, 2010 7:22 PM > To: Ning Zong; Roni Even; David A. Bryan; Qin Wu > Cc: httpstreaming@ietf.org > Subject: RE: [httpstreaming] Current Status and Our Goal > > When the traffic is unicast, you don't have the problems we have in a > multicast environment. The unicast traffic will naturally start from a > random access point. > [ZN]: I am a little bit confused by the word "naturally". Do you mean the > unicast server will adjust the timing such that the starting packet/segment > will always begin with RAP? In fact, not all the HTTP streaming system > mandates that the segmentation should align with RAP. Then, that's a pretty poor segmentation or the client simply downloads data that it will discard. The point is the connection is unicast so the client gets what it needs. > You might need some initialization data to start decoding or whatever, but > all that comes from the server over unicast anyway. > [ZN]: right, but the reference information is not always available to be > transmitted at any time point even using unicast, unless there is a cache > point. ? That reference information is part of the data the client gets. A cache cannot produce that data by itself, it needs to see it from upstream, which means it previously came from the origin server. [ZN]: I agree that the RI is part of the data acquired by the client, but the point is - if every segment carries all the necessary RI? I guess no. So I am just wondering if there is space to reduce the startup delay in client side. My point is that the ret. server we had in RAMS is not needed here since all the servers that can serve the client is one such entity here. They provide what the client wants, and if they don't have it, they redirect the client or fetch it for the client. [ZN]: The last sentence implies some architecture concerns, and interesting... -acbegen > The same applies to both on-demand and live content. > > -acbegen > > > -----Original Message----- > > From: Ning Zong [mailto:zongning@huawei.com] > > Sent: Wednesday, October 20, 2010 11:50 AM > > To: Ali C. Begen (abegen); 'Roni Even'; 'David A. Bryan'; 'Qin Wu' > > Cc: httpstreaming@ietf.org > > Subject: RE: [httpstreaming] Current Status and Our Goal > > > > IMO, the issue may not only related to multicast or unicast, but the QoE > > improvement (e.g. reduce the startup time after user change the channel). > If > > I remember correctly, in the motivation of FCC in AVT, one important > concern > > is that the Retransmission server can store the most recent GoPs and feed > > them to the client with faster rate than playback to effectively fill the > > gap between the time point of user channel zapping and next complete GoP. > > This improvement also applies to unicast based HTTP streaming, right? > > The above concern also implies that adding some intelligence to > > intermediaries would improve the streaming performance of HTTP streaming > > system. To be more specific, having a deep look at the mechanisms of > > distinguish different types of HTTP traffic (e.g. live streaming with > higher > > timing requirement v.s. normal packet, streaming packet containing I-frame > > worthy of caching for further usage v.s. normal streaming packet) would be > a > > possible direction for consideration in this list. > > > > My two cents. > > > > BR, > > Ning Zong > > > > -----Original Message----- > > From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] > > On Behalf Of Ali C. Begen (abegen) > > Sent: Thursday, October 07, 2010 6:15 AM > > To: Roni Even; David A. Bryan; Qin Wu > > Cc: httpstreaming@ietf.org > > Subject: Re: [httpstreaming] Current Status and Our Goal > > > > > 2. Address the startup issue, we have worked in AVT on fast > > channel/content > > > change and I think this is relevant also in this case. > > > > Are you assuming a multicast environment for http streaming? Ow, the > startup > > issue is not an issue in unicast connections. > > > > -acbegen > > _______________________________________________ > > httpstreaming mailing list > > httpstreaming@ietf.org > > https://www.ietf.org/mailman/listinfo/httpstreaming From zongning@huawei.com Wed Oct 20 17:45:44 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BF2D3A6926 for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.016 X-Spam-Level: X-Spam-Status: No, score=-100.016 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67ay6zn+Wlpd for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 17:45:43 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 25DB33A68A2 for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 17:45:43 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00HWN7IIOT@szxga02-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 08:47:07 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00FI27IIBP@szxga02-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 08:47:06 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAM00EH57II3Y@szxml06-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 08:47:06 +0800 (CST) Date: Thu, 21 Oct 2010 08:47:11 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <C8E35AA6.5A42%luby@qualcomm.com> To: "'Luby, Michael'" <luby@qualcomm.com>, httpstreaming@ietf.org Message-id: <002201cb70b9$7f3324f0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActqQCT6JAn3DlvXSDmGxPbhxkQQbgFk+O4IADlRf7A= Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 21 Oct 2010 00:45:44 -0000 Hi, Luby, Sure, we will do. Thank you for your interest. BR, Ning Zong -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Luby, Michael Sent: Wednesday, October 20, 2010 5:25 AM To: httpstreaming@ietf.org Subject: [httpstreaming] BAR BOF at IETF for HTTP Streaming I will not be going to the upcoming IETF, so it would be good to summarize any important discussions that occur at the BAR BOF and get comments from people on the list who can't make it to the BAR BOF as well. (I'm sure there are many others in the same situation as I) On 10/12/10 12:00 PM, "httpstreaming-request@ietf.org" <httpstreaming-request@ietf.org> wrote: > If you have received this digest without all the individual message > attachments you will need to update your digest options in your list > subscription. To do so, go to > > https://www.ietf.org/mailman/listinfo/httpstreaming > > Click the 'Unsubscribe or edit options' button, log in, and set "Get > MIME or Plain Text Digests?" to MIME. You can set this option > globally for all the list digests you receive at this point. > > > > Send httpstreaming mailing list submissions to > httpstreaming@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/httpstreaming > or, via email, send a message with subject or body 'help' to > httpstreaming-request@ietf.org > > You can reach the person managing the list at > httpstreaming-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of httpstreaming digest..." _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From zongning@huawei.com Wed Oct 20 18:12:22 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1A03A657C for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 18:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.06 X-Spam-Level: X-Spam-Status: No, score=-100.06 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkvwVHEb5Wkd for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 18:12:21 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 2C5EA3A68AC for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 18:12:20 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM003RQ8QTOC@szxga01-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 09:13:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00LGV8QT4B@szxga01-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 09:13:41 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAM007KF8QQNT@szxml04-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 09:13:40 +0800 (CST) Date: Thu, 21 Oct 2010 09:13:43 +0800 From: Ning Zong <zongning@huawei.com> To: httpstreaming@ietf.org Message-id: <002401cb70bd$344c0c00$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActwvTQKUuYulCV5SZqMEEC1TCuw/A== Subject: [httpstreaming] Date and time for HTTP streaming bar BoF X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 21 Oct 2010 01:12:22 -0000 Hi, Folks, According to the Doodle voting, we decide to have HTTP streaming bar BoF on Wednesday (10th, Nov.) evening from 19:30PM to 21:00PM. We are now arranging the meeting logistics (e.g. meeting room), and will keep you updated. Thank you for your interests to this work and hope to see you guys in Beijing. BR, Ning Zong From sunseawq@huawei.com Wed Oct 20 19:18:19 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1F2E3A69BD for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 19:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.264 X-Spam-Level: X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Wtet48O2mH9 for <httpstreaming@core3.amsl.com>; Wed, 20 Oct 2010 19:18:18 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0F6C63A6979 for <httpstreaming@ietf.org>; Wed, 20 Oct 2010 19:18:18 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00APXBSTMB@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 10:19:41 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAM00BWLBSTT7@szxga05-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 10:19:41 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAM00EI1BST1Z@szxml06-in.huawei.com> for httpstreaming@ietf.org; Thu, 21 Oct 2010 10:19:41 +0800 (CST) Date: Thu, 21 Oct 2010 10:19:40 +0800 From: Qin Wu <sunseawq@huawei.com> To: httpstreaming@ietf.org Message-id: <024301cb70c6$6b138cf0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002401cb70bd$344c0c00$3a298a0a@china.huawei.com> Subject: Re: [httpstreaming] Date and time for HTTP streaming bar BoF X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 21 Oct 2010 02:18:19 -0000 Hi, As for the meeting logistics, I have some proposals. If you have any topics which you think relevant to this bar BOF and that needs to be covered, please let us know. That will be helpful to schedule meeting agenda, focus on priority issue and have one effetive meeting. If you have any contribution and input you would like to share and discuss, please also send to us. Thanks! Regards! -Qin ----- Original Message ----- From: "Ning Zong" <zongning@huawei.com> To: <httpstreaming@ietf.org> Sent: Thursday, October 21, 2010 9:13 AM Subject: [httpstreaming] Date and time for HTTP streaming bar BoF > Hi, Folks, > According to the Doodle voting, we decide to have HTTP streaming bar BoF on > Wednesday (10th, Nov.) evening from 19:30PM to 21:00PM. We are now arranging > the meeting logistics (e.g. meeting room), and will keep you updated. > Thank you for your interests to this work and hope to see you guys in > Beijing. > > BR, > Ning Zong > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From salvatore.loreto@ericsson.com Sun Oct 24 23:22:05 2010 Return-Path: <salvatore.loreto@ericsson.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E49C3A6936 for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.802 X-Spam-Level: X-Spam-Status: No, score=-105.802 tagged_above=-999 required=5 tests=[AWL=0.797, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIiJk87FJ++W for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:22:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 633BA3A672F for <httpstreaming@ietf.org>; Sun, 24 Oct 2010 23:22:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-64-4cc52273980c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D3.D2.04955.37225CC4; Mon, 25 Oct 2010 08:23:47 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Oct 2010 08:23:46 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Oct 2010 08:23:46 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6F4FC254C for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 09:23:46 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 39D5F5013D for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 09:23:46 +0300 (EEST) Received: from n202.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F06F550121 for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 09:23:45 +0300 (EEST) Message-ID: <4CC52271.7040702@ericsson.com> Date: Mon, 25 Oct 2010 09:23:45 +0300 From: Salvatore Loreto <salvatore.loreto@ericsson.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: httpstreaming@ietf.org References: <C8E35AA6.5A42%luby@qualcomm.com> In-Reply-To: <C8E35AA6.5A42%luby@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 25 Oct 2010 06:23:46.0647 (UTC) FILETIME=[2E113E70:01CB740D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 06:22:05 -0000 On 10/20/10 12:24 AM, Luby, Michael wrote: > I will not be going to the upcoming IETF, so it would be good to summarize > any important discussions that occur at the BAR BOF and get comments from > people on the list who can't make it to the BAR BOF as well. (I'm sure there > are many others in the same situation as I) +1 -- Salvatore Loreto www.sloreto.com From abegen@cisco.com Sun Oct 24 23:36:47 2010 Return-Path: <abegen@cisco.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998723A6964 for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDdYY1cdhdnz for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:36:45 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 140853A6936 for <httpstreaming@ietf.org>; Sun, 24 Oct 2010 23:36:45 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOLCxEyrR7Ht/2dsb2JhbAChXXGfFJtQhUgEhFSJBQ X-IronPort-AV: E=Sophos;i="4.58,235,1286150400"; d="scan'208";a="275016068" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2010 06:38:29 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9P6cThe010408; Mon, 25 Oct 2010 06:38:29 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 23:38:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Oct 2010 23:38:32 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540D8168D4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <4CC52271.7040702@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] BAR BOF at IETF for HTTP Streaming Thread-Index: Act0DTK0P38f1NYURcu6++CXBsyQ0wAAf3Ew References: <C8E35AA6.5A42%luby@qualcomm.com> <4CC52271.7040702@ericsson.com> From: "Ali C. Begen (abegen)" <abegen@cisco.com> To: "Salvatore Loreto" <salvatore.loreto@ericsson.com>, <httpstreaming@ietf.org> X-OriginalArrivalTime: 25 Oct 2010 06:38:29.0358 (UTC) FILETIME=[3C3440E0:01CB740F] Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 06:36:48 -0000 Would people be interested in joining a bridge (i.e., webex)? -acbegen > -----Original Message----- > From: httpstreaming-bounces@ietf.org = [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Salvatore Loreto > Sent: Monday, October 25, 2010 8:24 AM > To: httpstreaming@ietf.org > Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming >=20 > On 10/20/10 12:24 AM, Luby, Michael wrote: > > I will not be going to the upcoming IETF, so it would be good to = summarize > > any important discussions that occur at the BAR BOF and get comments = from > > people on the list who can't make it to the BAR BOF as well. (I'm = sure there > > are many others in the same situation as I) > +1 >=20 >=20 > -- > Salvatore Loreto > www.sloreto.com >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From salvatore.loreto@ericsson.com Sun Oct 24 23:41:40 2010 Return-Path: <salvatore.loreto@ericsson.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF28C3A6966 for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.817 X-Spam-Level: X-Spam-Status: No, score=-105.817 tagged_above=-999 required=5 tests=[AWL=0.782, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjv6WLR7dFbl for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:41:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BF50C3A6936 for <httpstreaming@ietf.org>; Sun, 24 Oct 2010 23:41:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7b28ae00000135b-c2-4cc5270a060c Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id ED.75.04955.A0725CC4; Mon, 25 Oct 2010 08:43:22 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Oct 2010 08:43:22 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Oct 2010 08:43:21 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5BD37254C; Mon, 25 Oct 2010 09:43:21 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 24DE45013D; Mon, 25 Oct 2010 09:43:21 +0300 (EEST) Received: from n202.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CAEC950121; Mon, 25 Oct 2010 09:43:20 +0300 (EEST) Message-ID: <4CC52708.1070502@ericsson.com> Date: Mon, 25 Oct 2010 09:43:20 +0300 From: Salvatore Loreto <salvatore.loreto@ericsson.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" <abegen@cisco.com> References: <C8E35AA6.5A42%luby@qualcomm.com> <4CC52271.7040702@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D8168D4@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540D8168D4@xmb-sjc-215.amer.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 25 Oct 2010 06:43:21.0754 (UTC) FILETIME=[EA7C57A0:01CB740F] X-Brightmail-Tracker: AAAAAA== Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 06:41:40 -0000 having the possibility to participate remotely would be great /Sal On 10/25/10 9:38 AM, Ali C. Begen (abegen) wrote: > Would people be interested in joining a bridge (i.e., webex)? > > -acbegen > >> -----Original Message----- >> From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Salvatore Loreto >> Sent: Monday, October 25, 2010 8:24 AM >> To: httpstreaming@ietf.org >> Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming >> >> On 10/20/10 12:24 AM, Luby, Michael wrote: >>> I will not be going to the upcoming IETF, so it would be good to summarize >>> any important discussions that occur at the BAR BOF and get comments from >>> people on the list who can't make it to the BAR BOF as well. (I'm sure there >>> are many others in the same situation as I) >> +1 >> >> >> -- >> Salvatore Loreto >> www.sloreto.com >> >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming From stockhammer@nomor.de Sun Oct 24 23:42:43 2010 Return-Path: <stockhammer@nomor.de> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B543A672F for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKFoNUrNV2Eu for <httpstreaming@core3.amsl.com>; Sun, 24 Oct 2010 23:42:42 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id 1115A3A6936 for <httpstreaming@ietf.org>; Sun, 24 Oct 2010 23:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1287989063; l=1626; s=domk; d=nomor.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: Subject:CC:To:MIME-Version:From:Date:X-RZG-CLASS-ID:X-RZG-AUTH; bh=aCFHOWzh3OC1aHZGya8eDN6WC18=; b=ycHziNLT6iHe7zNd1tkmdsME+bMdXnk8cKwspiAG2WoCg52pYfPuFFm17pkjrx2trC6 YzzBZDAAaFbJXRpBBAtHoA5MPbHhC2fhqgPq2I3mdWNqfuLU5buElSQOHs8eodZS7uG6m Ivz5pirLrE6mANvJ1q1BBbPBSMy6032dGuo= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu18+1EZfOQVAS4z6gUSvLg= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.178] (business-213-023-252-114.static.arcor-ip.net [213.23.252.114]) by post.strato.de (klopstock mo8) (RZmta 23.5) with ESMTP id f014bbm9P6HZHG ; Mon, 25 Oct 2010 08:44:20 +0200 (MEST) Message-ID: <4CC52745.7070602@nomor.de> Date: Mon, 25 Oct 2010 08:44:21 +0200 From: Thomas Stockhammer <stockhammer@nomor.de> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Salvatore Loreto <salvatore.loreto@ericsson.com> References: <C8E35AA6.5A42%luby@qualcomm.com> <4CC52271.7040702@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D8168D4@xmb-sjc-215.amer.cisco.com> <4CC52708.1070502@ericsson.com> In-Reply-To: <4CC52708.1070502@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 06:42:43 -0000 > having the possibility to participate remotely would be great +1 > > /Sal > > On 10/25/10 9:38 AM, Ali C. Begen (abegen) wrote: >> Would people be interested in joining a bridge (i.e., webex)? >> >> -acbegen >> >>> -----Original Message----- >>> From: httpstreaming-bounces@ietf.org >>> [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Salvatore Loreto >>> Sent: Monday, October 25, 2010 8:24 AM >>> To: httpstreaming@ietf.org >>> Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming >>> >>> On 10/20/10 12:24 AM, Luby, Michael wrote: >>>> I will not be going to the upcoming IETF, so it would be good to >>>> summarize >>>> any important discussions that occur at the BAR BOF and get >>>> comments from >>>> people on the list who can't make it to the BAR BOF as well. (I'm >>>> sure there >>>> are many others in the same situation as I) >>> +1 >>> >>> >>> -- >>> Salvatore Loreto >>> www.sloreto.com >>> >>> _______________________________________________ >>> httpstreaming mailing list >>> httpstreaming@ietf.org >>> https://www.ietf.org/mailman/listinfo/httpstreaming > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming -- --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From zongning@huawei.com Mon Oct 25 00:06:01 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C0543A680A for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 00:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.096 X-Spam-Level: X-Spam-Status: No, score=-100.096 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KsBVPJh3BOdM for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 00:06:00 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 594F73A67C3 for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 00:06:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU00F823SMVG@szxga02-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 15:07:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU00EWS3SMOS@szxga02-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 15:07:34 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAU00BFT3SLA7@szxml06-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 15:07:33 +0800 (CST) Date: Mon, 25 Oct 2010 15:07:33 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <4CC52745.7070602@nomor.de> To: 'Thomas Stockhammer' <stockhammer@nomor.de>, 'Salvatore Loreto' <salvatore.loreto@ericsson.com> Message-id: <008601cb7413$4c0a86b0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Thread-index: Act0EDW7f33xTM/wR7iivzkBHG4tTQAAvWqg Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 07:06:01 -0000 Good suggestion, we will see how to setup a WebEx meeting and let you = know the following details. Thanks! BR, Ning Zong -----Original Message----- From: httpstreaming-bounces@ietf.org = [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Thomas Stockhammer Sent: Monday, October 25, 2010 2:44 PM To: Salvatore Loreto Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming > having the possibility to participate remotely would be great +1 > > /Sal > > On 10/25/10 9:38 AM, Ali C. Begen (abegen) wrote: >> Would people be interested in joining a bridge (i.e., webex)? >> >> -acbegen >> >>> -----Original Message----- >>> From: httpstreaming-bounces@ietf.org=20 >>> [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Salvatore = Loreto >>> Sent: Monday, October 25, 2010 8:24 AM >>> To: httpstreaming@ietf.org >>> Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming >>> >>> On 10/20/10 12:24 AM, Luby, Michael wrote: >>>> I will not be going to the upcoming IETF, so it would be good to=20 >>>> summarize >>>> any important discussions that occur at the BAR BOF and get=20 >>>> comments from >>>> people on the list who can't make it to the BAR BOF as well. (I'm=20 >>>> sure there >>>> are many others in the same situation as I) >>> +1 >>> >>> >>> --=20 >>> Salvatore Loreto >>> www.sloreto.com >>> >>> _______________________________________________ >>> httpstreaming mailing list >>> httpstreaming@ietf.org >>> https://www.ietf.org/mailman/listinfo/httpstreaming > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming --=20 --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 = 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - = Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 - = Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From soohongp@gmail.com Mon Oct 25 00:56:49 2010 Return-Path: <soohongp@gmail.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C747A3A67E1 for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 00:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-0.896, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUVbpD8RrhDj for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 00:56:47 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 664433A6824 for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 00:56:46 -0700 (PDT) Received: by iwn40 with SMTP id 40so3492814iwn.31 for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 00:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=+ikf8+LIYPFgD4hJU9B32VTraVm2Q7lADqP/HCJ1ukQ=; b=fZyie6yjuA+DGawgq7NdViAjn+2GBQjJ/hRQDRm7fCBusyPQJBDxlKuQjsxdci41IS ANGGQnyjDkwxI+SPBizwIlrEZ1KXr3mx73qi+cjCm2HdEVrIGazV2XYBfLnv1oy2c6Xf JgwumFMiNpYJf9lqBlgfKrdGgOHV74K+zZe/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=t6HIIuH9tazcd7YdHE/KjlbCdtC0qhK9lQgRdIOgliatJr63G8bw1ex1BSW2v9GWog sb08kjqtmAhkjKWop7DR0RwMlS4v+/uFhNlTT6GozyB+0qYEZY00lwkJjtzw5fXX5+Vt Rd6hgEuaNEbk6LgnzxGZb88DqYJFkPnYbvZ24= MIME-Version: 1.0 Received: by 10.231.35.194 with SMTP id q2mr5189009ibd.26.1287993510240; Mon, 25 Oct 2010 00:58:30 -0700 (PDT) Received: by 10.231.195.91 with HTTP; Mon, 25 Oct 2010 00:58:30 -0700 (PDT) Received: by 10.231.195.91 with HTTP; Mon, 25 Oct 2010 00:58:30 -0700 (PDT) In-Reply-To: <4CC52708.1070502@ericsson.com> References: <C8E35AA6.5A42%luby@qualcomm.com> <4CC52271.7040702@ericsson.com> <04CAD96D4C5A3D48B1919248A8FE0D540D8168D4@xmb-sjc-215.amer.cisco.com> <4CC52708.1070502@ericsson.com> Date: Mon, 25 Oct 2010 16:58:30 +0900 Message-ID: <AANLkTimdEeYO5-VgRkkbHvk6wUCTLOi56oGiYWv=yuJ_@mail.gmail.com> From: Daniel Park <soohongp@gmail.com> To: Salvatore Loreto <salvatore.loreto@ericsson.com> Content-Type: multipart/alternative; boundary=0022152d5cd9a6a3e804936c5b38 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] BAR BOF at IETF for HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 07:56:49 -0000 --0022152d5cd9a6a3e804936c5b38 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Cool...+1 Soohong Daniel Park from Galaxy S, twitter: @natpt 2010. 10. 25. =BF=C0=C8=C4 3:43=BF=A1 "Salvatore Loreto" <salvatore.loreto@= ericsson.com>=B4=D4=C0=CC =C0=DB=BC=BA: having the possibility to participate remotely would be great /Sal On 10/25/10 9:38 AM, Ali C. Begen (abegen) wrote: > > Would people be interested in joining a brid... --0022152d5cd9a6a3e804936c5b38 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable <p>Cool...+1</p> <p>Soohong Daniel Park<br> from Galaxy S, twitter: @natpt</p> <p><blockquote type=3D"cite">2010. 10. 25. =BF=C0=C8=C4 3:43=BF=A1 "Sa= lvatore Loreto" <<a href=3D"mailto:salvatore.loreto@ericsson.com">s= alvatore.loreto@ericsson.com</a>>=B4=D4=C0=CC =C0=DB=BC=BA:<br><br>havin= g the possibility to participate remotely would be great<br> <br> /Sal<p><font color=3D"#500050"><br><br>On 10/25/10 9:38 AM, Ali C. Begen (a= begen) wrote:<br>><br>> Would people be interested in joining a brid.= ..</font></p></blockquote></p> --0022152d5cd9a6a3e804936c5b38-- From zongning@huawei.com Mon Oct 25 04:29:40 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9583A680C for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 04:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.027 X-Spam-Level: X-Spam-Status: No, score=-97.027 tagged_above=-999 required=5 tests=[AWL=-2.732, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_SUMOF=5, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_54=0.6, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akU3djumlsmZ for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 04:29:36 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0D3223A69B1 for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 04:29:36 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU00L33FWIXG@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 19:29:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU00CGKFWIAL@szxga04-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 19:29:06 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAU0056JFWHWU@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 19:29:06 +0800 (CST) Date: Mon, 25 Oct 2010 19:29:05 +0800 From: Ning Zong <zongning@huawei.com> To: httpstreaming@ietf.org Message-id: <00d801cb7437$d50ddd30$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_3EVRUDPol9Rj8n0U6MxN6w)" Thread-index: Act0MkJRJM8KyDMsQNCoxjqVg2sxOAAADATg Subject: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01 X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 11:29:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3EVRUDPol9Rj8n0U6MxN6w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Folks, I have updated HTTP streaming survey and gap analysis draft and the new version is as attached. You can also check the URL below: http://www.ietf.org/id/draft-zong-httpstreaming-gap-analysis-01.txt BR, Ning Zong -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, October 25, 2010 6:47 PM To: zongning@huawei.com Subject: New Version Notification for draft-zong-httpstreaming-gap-analysis-01 A new version of I-D, draft-zong-httpstreaming-gap-analysis-01.txt has been successfully submitted by Ning Zong and posted to the IETF repository. Filename: draft-zong-httpstreaming-gap-analysis Revision: 01 Title: Survey and Gap Analysis for HTTP Streaming Standards and Implementations Creation_date: 2010-10-24 WG ID: Independent Submission Number_of_pages: 23 Abstract: With the explosive growth of the Internet usage and increasing demand for multimedia information on the web, media delivery over Internet attract substantial attention from media industry. To meet above requirements, HTTP Streaming technology is designed and gradually plays an important role in recent years. Several leading Standard Development Organizations (SDOs) have been producing a series of technical specifications to define streaming over HTTP. Moreover, several companies have devoted to developing private HTTP-based media delivery platform to provide high quality, adaptive viewing experience to customers. Following a brief survey of existing HTTP streaming standards and implementations, this document gives a brief summary on these related work, analyzes the potential challenges especially from the network point of view, and lists the gap between existing work and possible working scope on the topic of HTTP streaming in IETF. The IETF Secretariat. --Boundary_(ID_3EVRUDPol9Rj8n0U6MxN6w) Content-type: text/plain; name=draft-zong-httpstreaming-gap-analysis-01.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-zong-httpstreaming-gap-analysis-01.txt Network Working Group N. Zong Internet-Draft Huawei Technologies Intended status: Informational October 24, 2010 Expires: April 27, 2011 Survey and Gap Analysis for HTTP Streaming Standards and Implementations draft-zong-httpstreaming-gap-analysis-01 Abstract With the explosive growth of the Internet usage and increasing demand for multimedia information on the web, media delivery over Internet attract substantial attention from media industry. To meet above requirements, HTTP Streaming technology is designed and gradually plays an important role in recent years. Several leading Standard Development Organizations (SDOs) have been producing a series of technical specifications to define streaming over HTTP. Moreover, several companies have devoted to developing private HTTP-based media delivery platform to provide high quality, adaptive viewing experience to customers. Following a brief survey of existing HTTP streaming standards and implementations, this document gives a brief summary on these related work, analyzes the potential challenges especially from the network point of view, and lists the gap between existing work and possible working scope on the topic of HTTP streaming in IETF. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 27, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Zong Expires April 27, 2011 [Page 1] Internet-Draft Survey and Gap Analysis October 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Zong Expires April 27, 2011 [Page 2] Internet-Draft Survey and Gap Analysis October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. HTTP Streaming Standards . . . . . . . . . . . . . . . . . . . 6 3.1. 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Media Presentation Components . . . . . . . . . . . . 6 3.1.2. Media Presentation Description . . . . . . . . . . . . 8 3.1.3. Streaming Procedure . . . . . . . . . . . . . . . . . 9 3.1.3.1. Overview . . . . . . . . . . . . . . . . . . . . . 9 3.1.3.2. Segment list generation . . . . . . . . . . . . . 10 3.1.3.3. Seeking, trick mode and adaptation support . . . . 10 3.2. OIPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. MPD . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Segmentation . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. Media formats for MPEG2-TS . . . . . . . . . . . . . . 11 3.2.4. Use cases . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4.1. Live streaming . . . . . . . . . . . . . . . . . . 12 3.2.4.2. Trick mode and seeking . . . . . . . . . . . . . . 12 3.3. MPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3.1. Objectives . . . . . . . . . . . . . . . . . . . . . . 13 3.3.2. Requirements for proposal . . . . . . . . . . . . . . 13 4. HTTP Streaming Implementations . . . . . . . . . . . . . . . . 14 4.1. Microsoft Smooth Streaming . . . . . . . . . . . . . . . . 14 4.1.1. On-disk MP4 file format . . . . . . . . . . . . . . . 15 4.1.2. On-wire segments transmission . . . . . . . . . . . . 15 4.1.3. Adaptative support . . . . . . . . . . . . . . . . . . 16 4.2. Adobe . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Components . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Workflow . . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Top features . . . . . . . . . . . . . . . . . . . . . 17 4.3. Apple . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.3.1. Basic process . . . . . . . . . . . . . . . . . . . . 18 5. Gap Analysys . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Brief Summary of Exitsting Work . . . . . . . . . . . . . 19 5.2. Challenges . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3. Gap List and Potential Working Scope in IETF . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Zong Expires April 27, 2011 [Page 3] Internet-Draft Survey and Gap Analysis October 2010 1. Introduction Media streaming have played increasingly important role in Internet content deliveries, and are becoming indispensable in many applications (e.g., distance learning, digital libraries, home shopping, and video-on-demand). Currently, several streaming protocols are commonly used to deliver media content on Internet, such as HTTP, RTSP/RTP, RTMP, MMS, etc. HTTP streaming, one of above listed protocols, is rapidly becoming one of the most commonly used approach for media content distribution on the Internet. HTTP streaming is a mechanism for sending media data/file, which is divided into several chunks/fragments and supply them in order to user through port 80/8080. HTTP streaming includes various streaming media formats/codec including MP4, MPEG2-TS, H.264/ AAC, etc., and streaming services over HTTP, such as Windows Media/ Silver Light Streaming, Flash Video, QuickTime Streaming Server, Real Media Streaming and others. HTTP streaming offers two advantages as below: 1) Media protocols often have difficulty getting around firewalls and routers because they are commonly based on UDP sockets over unusual port numbers. HTTP-based media delivery has no such problems because firewalls and routers know to pass HTTP downloads through port 80. 2) HTTP media delivery has the ability to use standard HTTP servers and standard HTTP caches (or cheap servers in general) to deliver the content, so that it doesn't require special proxies or caches. Additionally, most Content Delivery Network (CDN) make use of HTTP to redirect request, retrieve cached multimedia object, and communicate policy servers. Several leading Standard Development Organizations (SDOs) have been producing a series of technical specifications to define streaming over HTTP. 3GPP introduces adaptive HTTP streaming in Technical Specification (TS) 26.234 [3GPP], where HTTP streaming is introduced in detail including Media Presentation Description (MPD), Media Segmentation Format, HTTP server and client behavior, etc., as an alternative approach to the RTSP/RTP based media delivery. Open IPTV Forum (OIPF) introduces HTTP adaptive streaming in its technical Specification [OIPF], which defines the usage of and extensions to 3GPP HTTP streaming to enable HTTP based Adaptive Streaming for OIPF compliant services and devices. Recently, ISO/IEC JTC1/SC29/WG11 (MPEG) launched a new standard on HTTP streaming. A bunch of documents [MPEG-1][MPEG-2][MPEG-3][MPEG-4] have been proposed to address the backgroud, objectives, use cases and requriements of the transport of MPEG media over HTTP. Zong Expires April 27, 2011 [Page 4] Internet-Draft Survey and Gap Analysis October 2010 Several companies have devoted to developing private HTTP-based media delivery platform to provide high quality, adaptive viewing experience to customers. Microsoft has implemented its Smooth Streaming technology, which is a web-base, adaptive media content delivery approach that uses standard HTTP [MS-IIS]. Instead of delivering media as full-file download, in Smooth Streaming, the content is delivered to client as a series of small file chunks that can be easily cached at edge servers, closer to client. Adobe HTTP Dynamic Streaming is a new Adobe-defined delivery method for enabling on-demand and live adaptive bitrate video streaming over regular HTTP connections [Adobe]. Adobe HTTP Dynamic Streaming packages media files into fragments that Flash Player clients can access instantly without downloading the entire file. Apple HTTP Live Streaming [Apple] allows to send live or prerecorded audio and video to iPhone or other devices, such as desktop computers, using an ordinary Web server, with support of adaptive bitrate. Following a brief survey of the above mentioned existing HTTP streaming standards and implementations, this document gives a brief summary on these related work, analyzes the potential challenges especially from the network point of view, and lists the gap between existing work and possible working scope on the topic of HTTP streaming in IETF. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. Live Streaming: Live events can be streamed over the Internet with the help of broadcast software which encodes the live source - from a microphone, video camera, or other recording device and delivers the resulting stream to the server. The server then transfers the stream. So the user experiences the event as it happens. On-Demand Streaming: To provide "anytime" access to media content, client is allowed to select and playback on demand. Progressive Download: A mode that allow client playback the media file while the file is downloading, after only a few seconds wait for buffering, the process of collecting the first part of a media file before playing. Adaptive Streaming: Adaptive streaming is a process that adjusts the quality of a video delivered to a client based on the changing Zong Expires April 27, 2011 [Page 5] Internet-Draft Survey and Gap Analysis October 2010 network conditions to ensure the best possible viewer experience. 3. HTTP Streaming Standards 3.1. 3GPP 3GPP introduces adaptive HTTP streaming in Technical Specification (TS) 26.234 [3GPP]. TS 26.234 specifies the protocols and codecs for the Packet-Switched Steaming Service (PSS) within the 3GPP system. Protocols for control signalling, capability exchange, media transport, rate adaptation and protection are specified. Codecs for speech, natural and synthetic audio, video, still images, bitmap graphics, vector graphics, timed text and text are specified. The delivery of media over HTTP provides an alternative delivery mechanism to the RTSP/RTP based media delivery. It is assumed that the HTTP-Streaming Client has access to a Media Presentation Description (MPD). An MPD provides sufficient information for the HTTP-Streaming Client to provide a streaming service to the user by sequentially downloading media data from an HTTP server and rendering the included media appropriately. 3.1.1. Media Presentation Components A media presentation is a structured collection of data that is accessible to the HTTP-Streaming Client, which is described in a MPD. The media presentation structure is shown in the following figure. Zong Expires April 27, 2011 [Page 6] Internet-Draft Survey and Gap Analysis October 2010 ^ resultion / bit-rate / language / etc | | representation | +------------------------------------------------+ | | segment segment | | | +----------------------------+ +-----+ | | | | +----------+ +----------+ | | | | | | | | meta | | media | | | | | | | | | data | | data | | | | ... ...| | | | +----------+ +----------+ | | | | | | +----------------------------+ +-----+ | | +------------------------------------------------+ | | +------------------------------------------------+ | | representation | | +------------------------------------------------+ | ... ... | +------------------------------------------------+ | | representation | | +------------------------------------------------+ | period 1 period2 ... +-------------------------------------------------------------------> time A media presentation consists of: 1) A sequence of Periods. 2) Each Period contains one or more Representations from the same media content. Different Representations usually have different attributes on media resolution, bit-rate, language, etc. 3) Each Representation consists of one or more segments. 4) Segments contain media data and/or metadata to decode and present the included media data and is defined as a unit that can be uniquely referenced by an http-URL element in the MPD. The Initialisation Segment contains initialisation information (no media data) for accessing the Representation. A Media Segment contains media data that are described either within this Media Segment or by the Initialisation Segment. The segment has a start time relative to the start time of the representation (period) such that the client can download a specific segment. The segment provides random access information, namely if and how you can randomly access the media within this segment. There is no requirement that a segment starts with a random access point (RAP). But it is possible that all segments start with a RAP. Zong Expires April 27, 2011 [Page 7] Internet-Draft Survey and Gap Analysis October 2010 3.1.2. Media Presentation Description The logic structure of media presentation is actually described as the data structure (e.g. xml schema) in MPD file. That is, the MDP contains metadata required by the client to construct appropriate URIs to access segments and to provide the streaming service to the user. Several important attributes and elements contained in a MPD are listed as below: 1) "type" attribute: type of the media presentation, i.e. VOD or live. 2) "availabilityStartTime" attribute: media presentation start time if "type"=live. If "type"=VoD, media presentation start time is 0. 3) "duration" attribute: duration/length of the media presentation. For live presentation, the sum of "duration" and "availabilityStart" specifies the end time of the media presentation. If "duration" is not provided, then the MPD does not describe an entire media presentation and the MPD may be updated during live presentation. 4) "minimumUpdatePeriodMPD" attribute: minimum MPD update period. 5) "timeShiftBufferDepth" attribute: duration of time shifting buffer maintained at the server for live presentation. This attribute will be used in the case of trick mode. 6) "minBufferTime" attribute: minimum buffer time for the stream. 7) Multiple "Period" element: describe a period. A "Period" element contains the following important attributes and elements: 7.1) "start" attribute: start time of this period. 7.2) Multiple "Representation" element: describe a representation with different bit-rate, resolution, language, etc. A "Representation" element contains the following important attributes and elements: 7.2.1) "bandwidth" attribute: maximum bit-rate of the representation averaged over any interval of "minBufferTime" duration. 7.2.2) "startWithRAP" attribute: When True, indicates that all segments in the representation start with a random access point (RAP). Zong Expires April 27, 2011 [Page 8] Internet-Draft Survey and Gap Analysis October 2010 7.2.3) "qualityRanking" attribute: quality ranking of the representation. 7.2.4) "TrickMode" element: provides the information for trick mode. In this element, "AlternatePlayoutRate" attribute denotes the playout speed as a multiple of the regular playout speed. 7.2.5) "SegmentInfo" element: describe all segments in a representation. Each "SegmentInfo" element permits generating a list of Media Segment URLs (possibly with a byte range) and Media Segment start times relative to the start time of the Representation. A "SegmentInfo" element contains the following important attributes and elements: 7.2.5.1) "duration" attribute: gives the constant approximate segment duration. 7.2.5.2) at most one "InitialisationSegmentURL" element. If not present, then each media segment within this representation shall be self-initialising. 7.2.5.3) either a URLtemplate" element that specifies a default segment URL template for all segments, or one or more "Url" elements that provides a set of explicit URL(s) for segments. Note that a client derives the request-for-MPD-update time as the sum of the time of its last requested update of the MPD and the "minimumUpdatePeriodMPD" attribute. 3.1.3. Streaming Procedure 3.1.3.1. Overview Initially, the client parses the MPD and creates an segment list for each representation. Then the client selects one representation based on the information in the representation attributes and other information, e.g. available bandwidth, client capabilities. Client acquires initialisation segments and the media segments of the selected representation by using the generated segment list. Client continues consuming the media content by continuously requesting media segments taking into account the MPD update. Client may change representations taking into account updated MPD information and/or updated information from its environment, e.g. access bit-rate changes. Zong Expires April 27, 2011 [Page 9] Internet-Draft Survey and Gap Analysis October 2010 3.1.3.2. Segment list generation A list contains: 1) URL to initialization segment; 2) URLs to media segments; 3) start times to media segments in the period. There are two approaches for generating segment list. One is template based generation, that is to utilize the "URLtemplate" and "duration" attributes in "SegmentInfo" element in MPD. Another is play-list based generation, that is to utilize the "URLs" and "duration" in "SegmentInfo" element in MPD. 3.1.3.3. Seeking, trick mode and adaptation support Suppose that the client wants to seek to time "tp", the corresponding segment can be searched by the server through: Target_segment_index = max { i | MediaSegment[i].StartTime <= tp- Period.start }. For accurate seeking to time "tp", client needs to access a RAP. Client may use the information in the 'sidx' to locate the RAP and the corresponding presentation time in the media presentation. For fast start-up, client may initially request the 'sidx' box from the beginning of the media segment using byte range requests. Trick mode can be implemented by utilizing the "AlternatePlayoutRate" attribute in "TrickMode" element in MPD. Switching to a new representation is equivalent to seeking to the new representation. Client should seek to a RAP in the new representation at a desired presentation time "tp" later than current presentation time. 3.2. OIPF Open IPTV Forum (OIPF) introduces HTTP adaptive streaming in its technical Specification [OIPF]. This specification defines the usage of and, where necessary, extensions to the technologies defined in 3GPP TS 26.234 to enable HTTP based Adaptive Streaming for Release 2 OIPF compliant services and devices. Most details on HTTP adaptive streaming in this specification is based on 3GPP TS 26.234. The extensions and designs speficic to OIPF are introduced in this document. 3.2.1. MPD A Representation may be made up of multiple components, for example audio, video. A partial Representation may only contain some of these components and a terminal may need to download (and play) multiple partial Representations to build up a complete Representation, with the appropriate components according to the preferences and wishes of the user. Accordingly, in MPD, the Zong Expires April 27, 2011 [Page 10] Internet-Draft Survey and Gap Analysis October 2010 "Representation" element may consist of one or more Components which may be downloaded and provided to the terminal in addition to content being downloaded from other "Representation" elements. In this case the "Representation" element in MPD SHALL contain one or more "Component" elements. The "Representation" element in MPD may carry a "group" attribute. The value of the "group" attribute SHALL be the same for Representations that contain at least one same Component. Two Representations with completely different Components (e.g. audio at two different languages) SHALL have different values for the "group" attribute. To provide nPVR functionality, when the Segments of the live Content are stored on the nPVR server, the URLs indicating the Segments on the nPVR server SHOULD be provided to the OIPF to enable it to access these Segments by the MPD update mechanism defined in 3GPP TS 26.234. 3.2.2. Segmentation Each Segment SHALL start with a random access point (RAP). Moreover, to enable seamless switching: 1) Different Component Streams of the same Component SHALL be encoded in the same media format but MAY be different in the profile of that format. (e.g., if a Representation contains a Component Stream of a certain video Component that is encoded using H.264/AVC using the HD profile, then all other Representations that have a Component Stream of that Component must use H.264/AVC but may use different configurations within the HD profile.) 2) Segments of Representations with the same value for the "group" attribute SHALL be time aligned. 3.2.3. Media formats for MPEG2-TS Component Streams of the same Component (e.g. "video angle 1 in H.264 at 720x576" and "video angle 1 in H.264 at 320x288") SHALL be carried in transport stream packets that have the same PID. When the Segments of a Representation contain MPEG-2 TS packets, the value of the "id" attribute in each Component element, if present, SHALL be the PID of the Transport Stream packets which carry the Component. For all Representations, the PAT and PMT are either contained in the initialisation Segments or in the media Segments. The Representations with zero "group" attribute will have the same PAT/ PMT as Representations with non-zero "group" attribute. Zong Expires April 27, 2011 [Page 11] Internet-Draft Survey and Gap Analysis October 2010 A media Segment SHALL contain the concatenation of one or several contiguous (and complete) PES packets which are split and encapsulated into TS packets. When packetizing video elementary streams, up to one frame SHALL be included into one PES packet. The PES packet where a frame starts SHALL always contain a PTS/DTS header fields in the PES header. 3.2.4. Use cases 3.2.4.1. Live streaming If the "timeShiftBufferDepth" attribute is present in the MPD, it may be used by the terminal to know at any moment which Segments are effectively available for downloading with the current MPD. If this timeshift information is not present in the MPD, the terminal may assume that all Segments described in the MPD which are already in the past are available for downloading. Periods may be used in the live streaming scenario to appropriately describe successive live events with different encoding or adaptive streaming properties. 3.2.4.2. Trick mode and seeking Basic implementation of trick modes is based on the processing of Segments by the terminal software: downloaded Segments may be provided to the decoder at a speed lower or higher than normal. The playback of Segments in fast forward and fast rewind has an immediate effect on the bitrate, because the Segments also need to be downloaded at a faster rate than normal. Dedicated streams may be used to implement efficient trick modes: it is recommended to produce the streams with a lower frame rate, longer Segments or a lower resolution to ensure that the bitrate is kept at a reasonable level even when the Segment is downloaded at a faster rate. The dedicated stream is described as Representation with a "TrickMode" element in the MPD. It is also recommended that if there are dedicated fast forward Representations, the normal Representations do not contain the "TrickMode" element in the MPD. To determine the random access point in a media Segment, the client should download and search RAP one by one till the required RAP is found. 3.3. MPEG Recently, ISO/IEC JTC1/SC29/WG11 (MPEG) launched a new standard on HTTP streaming. A series of proposals [MPEG-1][MPEG-2][MPEG-3][MPEG-4] have been proposed to address the backgroud, objectives, use cases and requriements of the transport of MPEG media over HTTP, as well as call-for-propsal on this topic. Zong Expires April 27, 2011 [Page 12] Internet-Draft Survey and Gap Analysis October 2010 3.3.1. Objectives The main objectives of this new standard are: 1) Efficient delivery of MPEG media over HTTP in an adaptive, progressive, download/streaming fashion. 2) Support of live streaming of multimedia content. 3) Efficient and ease of use of existing content distribution infrastructure components such as CDNs, proxies, caches, NATs and firewalls. 4) Support of integrated services with multiple components. 5) Support for signaling, delivery, utilization of multiple content protection and rights management schemes, and support for efficient content forwarding and relay. 3.3.2. Requirements for proposal A list of requirements on HTTP streaming are ecouraged by MPEG. Only those related to media delivery are introduced as follows. 1) This standard shall support streaming of content and content components over HTTP 1.1. 2) The media files prepared for this standard should be deliverable using progressive download with minimal changes. 3) This standard shall support streaming of live content of possibly indefinite length, including PVR functionalities such as pause and time-shifted play. 4) The standard shall support random access (seeking). 5) The standard shall support trick modes at least to the extent that the underlying formats support them in local playback. 6) The standard shall not require any extension to HTTP 1.1. It shall support the efficient use of HTTP optimized infrastructures such as Content Delivery Networks (CDNs), caches and proxies. 7) The standard shall allow segmentation of the content. The standard shall not require fixed size or fixed duration segments during delivery of content. Zong Expires April 27, 2011 [Page 13] Internet-Draft Survey and Gap Analysis October 2010 8) The standard should introduce minimal transport overhead and should incur minimal presentation startup delay. 9) The standard shall support description of media components for delivery and presentation. 10) The standard shall support interactive selection of media components for delivery and presentation, for example view selection in multi-view content. 11) This standard shall support prioritization of content and content components. 12) This standard shall support signaling the relationship among content components. 13) The standard should support network transition during delivery of the content. 14) The standard shall enable adaptation of content along axes such as bitrate, temporal resolution, spatial resolution, quality/ fidelity or view perspective. 15) The standard shall support initial selection, and dynamic adaptation of the content without presentation interruption during delivery. 4. HTTP Streaming Implementations 4.1. Microsoft Smooth Streaming Smooth Streaming is Microsoft implementation of adaptive streaming technology, which is a web-base media content delivery that uses standard HTTP [MS-IIS]. Instead of delivering media as full-file download, or as progressive download, the content is delivered to client as a series of small file chunks that can be easily and cheaply cached at edge servers, closer to client. Smooth Streaming defines each chunk/GOP as an MPEG-4 Movie Fragment and stores it within a contiguous MP4 file for easy random access. One MP4 file is expected for each bit rate. Because the media is "virtually" split into fragment files, the server must translate sequential URL requests into exact byte range offsets within the MP4 file. Server extracts the fragment box and sends it over the wire to the client as a standalone file. Zong Expires April 27, 2011 [Page 14] Internet-Draft Survey and Gap Analysis October 2010 4.1.1. On-disk MP4 file format +-------------------------------------------------------------------+ | +----+ +---------------------+ +--------------+ +------+ +------+ | | | | | Movie Metadata(moov)| |Movie Fragment| |Media | |Movie | | | |file| |+-----++-----++-----+| | (moof) | |Data | |Frag | | | |type| ||Movie||Track||Movie|| |+----+ +-----+| |(mdat)| |Random| | | | | ||hdr || ||Ext. || ||Frag| |Track|| | | |Access| | | | | || || || || ||hdr | |Frag || | | |(mfra)| | | | | || || || || || | | || | | | | | | | | |+-----++-----++-----+| |+----+ +-----+| | | | | | | +----+ +---------------------+ +--------------+ +------+ +------+ | +-------------------------------------------------------------------+ In a nutshell, the MP4 file starts with file-level metadata ('moov') that generically describes the file, but the bulk of the payload is actually contained in the fragment boxes that also carry more accurate fragment-level metadata ('moof') and media data ('mdat'). Closing the file is an 'mfra' index box that allows easy and accurate seeking within the file. In Smooth Streaming, the MP4 files are classified into two kinds. One is *.ismv file containing video and audio. Another is *.isma containing audio only. Beside media files, there are manifest files. Server manifest file (*.ism) describes the relationships between the media tracks, bit rates and files on disk. Client manifest file (*.ismc) describes the available streams to the client: the codecs used, bit rates encoded, video resolutions, markers, captions, etc. 4.1.2. On-wire segments transmission Initially, the client requests the *.ismc client manifest from the server. Client then requests fragments in the form of a URL, e.g., h ttp://video.foo.com/NBA.ism/QualityLevels(400000)/ Fragments(video=610275114). Server then looks up the quality level (bit rate) in the corresponding *.ism server manifest and maps it to a physical *.ismv or *.isma file on disk. Server reads the appropriate MP4 file, and based on its 'tfra' index box, figures out which fragment box ('moof' + 'mdat') corresponds to the requested start time offset. Server extracts the fragment box and sends it over the wire to the client as a standalone file. The sent fragment/ file can now be automatically cached further down the network, potentially saving the origin server from sending the same fragment/ file again to another client that requests the same URL. Zong Expires April 27, 2011 [Page 15] Internet-Draft Survey and Gap Analysis October 2010 4.1.3. Adaptative support Smooth Streaming provides multiple encoded bit rates of the same media source and thus allow client to seamlessly switch between bit rates. As client plays chunks, network condition may change or media processing may be impacted by other applications. Client can immediately request the next chunk come from stream that is encoded at a different bit rate to accommodate changing conditions. This enables client to play media without any stuttering, buffering and freezing, thereby providing fittest-quality playback to client. 4.2. Adobe Adobe HTTP Dynamic Streaming is a new Adobe-defined delivery method for enabling on-demand and live adaptive bitrate video streaming over regular HTTP connections [Adobe]. HTTP Dynamic Streaming packages media files into fragments that Flash Player clients can access instantly without downloading the entire file. Adobe HTTP Dynamic Streaming contains several components that work together to package media and stream it over HTTP to Flash Player. 4.2.1. Components File Packagers include Live Packager and VoD Packager. VoD Packager translates on-demand media files into fragments and writes the fragments to F4F files. Live Packager translates ingested live streams over Real Time Messaging Protocol (RTMP) into F4F files in real-time. HTTP Origin Module is an Apache HTTP Server module that serves the F4F files created by the File Packagers. The F4F file format describes how to divide media content into segments and fragments. Each fragment has its own bootstrap information that provides cache management and fast seeking. The F4M Manifest file format contains information about a package of files that the HTTP Origin Module can serve. Manifest information includes codecs, resolutions, and the availability of files encoded at multiple bit rates. 4.2.2. Workflow HTTP Dynamic Streaming workflow includes content preparation which write media fragments into files, distribution of files over HTTP, media consumption and protection, etc. Zong Expires April 27, 2011 [Page 16] Internet-Draft Survey and Gap Analysis October 2010 +--------+ +-------+ +-------+ +------+ | | | | | | | | Live | |F4F/F4M | | | | | | streaming|File |Files | HTTP |HTTP | HTTP |HTTP |Client| -------->|Packager|------->| Origin|Delivery| Cache/|Delivery|Appl. | | | | Module|------->| CDN |------->| | VoD | | | | | | | | content | | | | | | | | -------->| | | | | | | | +--------+ +-------+ +-------+ +------+ 4.2.3. Top features HTTP Dynamic Streaming supports features like adaptive bitrate, DVR functionality, etc. 1) Adaptive bitrate. To stream multi-bitrate content, the server encodes a piece of media at multiple bitrates, creating multiple files. The media files share a manifest file that lists information about each media file. With this information, the client detects the client's bandwidth, computer resources, etc and requests content fragments encoded at the most appropriate bitrate for the best viewing experience. 2) DVR functionality. Add interactivity to live streams by enabling DVR functionality, allowing viewers to pause, rewind, and skip forward to real time. 3) Support for standard HTTP caching systems. Leverage existing standard server hardware and caching infrastructures to maximize capacity and reach. 4.3. Apple Apple HTTP Live Streaming [Apple] allows to send live or prerecorded audio and video to iPhone or other devices, such as desktop computers, using an ordinary Web server. Playback requires iPhone OS 3.0 or later on iPhone or iPod touch; QuickTime X or later is required on the desktop. Zong Expires April 27, 2011 [Page 17] Internet-Draft Survey and Gap Analysis October 2010 4.3.1. Basic process +-------+ +---------+ +------+ +------+ | | | | | | | | Live | |MPEG2 | |Index/ | | | | streaming|Media |TS |Stream |.ts Files|HTTP |HTTP |Client| -------->|Encoder|----->|Segmenter|-------->|Server|Delivery|Appl. | | | | | | |------->| | VoD | | | | | | | | content | | | | | | | | -------->| | | | | | | | +-------+ +---------+ +------+ +------+ Media Encoder takes audio-video input and turns it into an MPEG-2 Transport Stream. Currently, the supported format is MPEG-2 Transport Streams (with H.264 video and AAC audio) for audio-video, or MPEG elementary streams for audio. Stream segmenter reads the Transport Stream from the local network and divides it into a series of small media files (.ts files) of equal duration, and creates an index file containing a playlist of the media files, as well as meta-data information. The index file is in .M3U8 format. In the case of a live stream, each time the segmenter completes a new media file, the index file is updated. The index is used to track the availability and location of the media files. Both .ts and .M3U8 files are placed on a HTTP server. A HTTP server or a web caching system that delivers the media files and index files to the client over HTTP. A client begins by fetching the index file, based on a URL identifying the stream. The index file in turn specifies the location of the available media files, decryption keys, and any alternate streams available. For the selected stream, the client downloads each available media file in sequence. Each file contains a consecutive segment of the stream. Once it has a sufficient amount of data downloaded, the client begins presenting the reassembled stream to the user. In addition, HTTP Live Streaming technology supports adaptive bitrate and automatically switches to the optimal bitrate based on the network conditions for a smooth quality playback experience. 5. Gap Analysys Zong Expires April 27, 2011 [Page 18] Internet-Draft Survey and Gap Analysis October 2010 5.1. Brief Summary of Exitsting Work It can be observed that 3GPP, OIPF, MS Smooth Streaming, Adobe Dynamic Streaming and Apple HTTP Live Streaming all follow a similar design scope, that is: 1) Streaming server utilizes a stream encoder/segmenter to write the media content into a series of small files, as well as produce a manifest file to describe these media files. See below summary of existing defined media and menifest files for HTTP streaming, regardless the codec and media container type. | Media File | Menifest File | ========================================================= 3GPP/OIPF | .3GP file | .3GP file | --------------------------------------------------------- MS Smooth HTTP | .ismv/.isma file | .ism/.ismc file | --------------------------------------------------------- Adobe Dynamic HTTP | .F4F file | .F4M file | --------------------------------------------------------- Apple Live HTTP | .ts file | .M3U8 file | 2) HTTP client firstly obtains the menifest file, then construct a series of URIs pointing to the media files. Based on the condition of client (e.g. network, device type, etc), or in the situation when the user operates trick mode, the client choose to request certain media file using HTTP request with the corresponding URI. 3) Upon receiving the HTTP request, the HTTP server send the media file corresponding to the URI in the request to the client. Apparently, the above design leave the network transport out of scope, that is, the media (both live streaming and VoD content) is encrypted into files and further transmitted by standard HTTP as payload. From the network transport point of view, there is no difference between transmission of such media data and normal text file. All the main features of media streaming, such as meta- information of media, PVR funtion, seeking, trick mode, adaptation between different viewing quality, etc, are implemented (or can be implemented) by the negotiation between server and client by flexible MPD, or menifest file. Another word, all the intelligence in current HTTP streaming design resides on the server and client software, rather than the network transport. Zong Expires April 27, 2011 [Page 19] Internet-Draft Survey and Gap Analysis October 2010 5.2. Challenges However streaming long duration and high quality media over the best- effort Internet to satisfy the real-time streaming requirements faces several challenges when there are no network capabilities support for HTTP Streaming. The first challenge is that the current HTTP streaming is based on pull mode where the HTTP client relies on the updated menifest file from the server to pull the chunk one after another through issuing a sequence of HTTP requests to the HTTP server. In the case of live streaming, the server will need to update the manifest file frequently once a new chunk of live media becomes available. Hence, a potential problem is that there will be additional round trips between the client and the server for manifest file update before the client can request each new chunk, which could risk the real-time feature of live streaming. HTTP server push model, on the other hand, enables the server to actively and continuously push chunks to the client once a new chunk is available on the server, without the round trips between the client and the server for manifest file update. In this sense, push model could be more efficient and a better candidate for time-sensitive scenario. The second challenge is the lack of QoE improvement and monitoring mechanisms in current HTTP streaming systems. Compared to the dedicated IPTV system, the HTTP streaming based on the best-effort Internet may suffer more from network transition. For example, when a user switches live channel, the current group of pictures (GoP) and initialization information for decoders (a.k.a. Reference Information (RI)) of the media content need to be acquired by the client ASAP to start playback. Unfortunately, there is no mechanism so far to improve the transmission of the important HTTP packets, hence may introduce a long delay to start the playback in the scenario of HTTP streaming. Additionally, some QoE metrics at session level, such as startup delay are important to the HTTP streaming system for monitoring or diagnostic purpose. Unfortunately, there is no such quality monitoring mechanisms (e.g. like RTCP report) in current HTTP streaming system. To provide a high-quality service for the user, monitoring and analyzing the system's overall performance is extremely important, since offering the performance monitoring capability can help diagnose the potential network impairment. With these above challenges, the typical user experience in the existing HTTP streaming schemes can be limited by delayed startups, poor quality, buffering delays, etc. Especially, in the case of "Multi-Screen" applications, the service provider intends to provide a common user experience when the user enjoys the media content Zong Expires April 27, 2011 [Page 20] Internet-Draft Survey and Gap Analysis October 2010 across PCs, TVs, and smart-phones. Therefore, HTTP streaming over the Internet without some optimization on network transport for QoE improvement may lead difficulty for the service provider to comply the service level agreements (SLAs) between service provider and users. 5.3. Gap List and Potential Working Scope in IETF The following table list the gaps in exisiting works on HTTP streaming including 3GPP, MS, Adobe, and Apple. | If satisfied by | Characteristic | existing work | ========================================================== Adaptation bir-rate | Yes | | ---------------------------------------------------------- Playback control | Yes | | ---------------------------------------------------------- Use existing cache, CDN | Yes | | ---------------------------------------------------------- client pull model | Yes | | ---------------------------------------------------------- server push model | | No | ---------------------------------------------------------- Reliable transmission in network | Yes | | ---------------------------------------------------------- Real-time support in network | | No | ---------------------------------------------------------- QoE improvement (e.g. startup) | | No | ---------------------------------------------------------- QoE monitoring | | No | ---------------------------------------------------------- Multicast support for scalability | | No | As the leading SDO on making the Internet work better, IETF is a suitable place to address the above mentioned gaps by studying and enhancing the network to meet the real-time requirement of HTTP streaming system. A potential working scope can be: 1) investigate the usage of server push model in HTTP streaming to find the better model for the more time-sensitive applications, such as live streaming; 2) study some QoE monitoring and feedback mechanisms (e.g. like RTCP report ) in HTTP streaming system, including monitoring architecture, feedback message coding, QoE metrics for HTTP streaming, etc; 3) define some mechanisms for QoE improvement for HTTP streaming, such as reducing startup delay in playback when user swithes live channel or starts VoD; 4) further improve the real-time streaming performance from the aspect of network transport functions. Please refer to [HTTPStreamingPS], for more details on the problem Zong Expires April 27, 2011 [Page 21] Internet-Draft Survey and Gap Analysis October 2010 statement and scope of work. 6. IANA Considerations This document presently raises no IANA considerations. 7. Security Considerations This document presently raises no security considerations. 8. Acknowledgements The authors would like to thank many people who give valuable comments on this draft. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [3GPP] 3GPP, "Transparent end-to-end Packet-switched Streaming Service (PSS) - Protocols and codecs (Release 9)", March 2010. [OIPF] OIPF, "HTTP Adaptive Streaming (Release 2)", September 2010. [MPEG-1] ISO/IEC JTC1/SC29/WG11, "HTTP Streaming of MPEG Media Context and Objectives (N11337)", April 2010. [MPEG-2] ISO/IEC JTC1/SC29/WG11, "Call for Proposals on HTTP Streaming of MPEG Media (N11338)", April 2010. [MPEG-3] ISO/IEC JTC1/SC29/WG11, "Use Cases for HTTP Streaming of MPEG Media (N11339)", April 2010. [MPEG-4] ISO/IEC JTC1/SC29/WG11, "Requirements on HTTP Streaming of MPEG Media (N11340)", April 2010. [MS-IIS] Microsoft Corporation, "IIS Smooth Streaming Technical Zong Expires April 27, 2011 [Page 22] Internet-Draft Survey and Gap Analysis October 2010 Overview", March 2009. [Adobe] Adobe, "Using ADOBE HTTP DYNAMIC STREAMING", 2010. [Apple] Apple, "HTTP Live Streaming Overview", November 2009. [HTTPStreamingPS] Wu, Q., "Problem Statement for HTTP Streaming", draft-wu-http-streaming-optimization-ps-02.txt (work in progress), September 2010. Author's Address Ning Zong Huawei Technologies Phone: +86 25 56624760 Email: zongning@huawei.com Zong Expires April 27, 2011 [Page 23] --Boundary_(ID_3EVRUDPol9Rj8n0U6MxN6w)-- From sunseawq@huawei.com Mon Oct 25 05:01:13 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58EB3A69E5 for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 05:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e10xnMF6a4qM for <httpstreaming@core3.amsl.com>; Mon, 25 Oct 2010 05:01:13 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3CD863A6992 for <httpstreaming@ietf.org>; Mon, 25 Oct 2010 05:01:12 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU0041HHGMY0@szxga01-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 20:02:46 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAU00BA5HGMB1@szxga01-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 20:02:46 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAU006BEHGL4V@szxml06-in.huawei.com> for httpstreaming@ietf.org; Mon, 25 Oct 2010 20:02:46 +0800 (CST) Date: Mon, 25 Oct 2010 20:02:45 +0800 From: Qin Wu <sunseawq@huawei.com> To: httpstreaming@ietf.org Message-id: <068b01cb743c$89646930$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20101025111502.27E173A697D@core3.amsl.com> Subject: [httpstreaming] HTTP Streaming Problem Statement Updating//Re: I-D Action:draft-wu-http-streaming-optimization-ps-03.txt X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 25 Oct 2010 12:01:13 -0000 Hi An updated version of http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-03.txt is submitted which * address lots of comments from this list * incorporate many concrete inputs from the list Many thanks to those people who have shared their ideas and proposals. Comparing with the previous version, the new version has been thoroughly restructured and organized based on the suggestions on the list. The concept would be to center around three typical HTTP Streaming use cases, explore couples of typical problems inherent in the existing HTTP streaming model and outline the potential scope of the problem including possible direction forward and possible two new models. Hopefully we can define more and more clear scope of the problem. If you have any other suggestions and good ideas/ inputs/proposals, please let us know or speakup on the list. Regards! -Qin ----- Original Message ----- From: <Internet-Drafts@ietf.org> To: <i-d-announce@ietf.org> Sent: Monday, October 25, 2010 7:15 PM Subject: I-D Action:draft-wu-http-streaming-optimization-ps-03.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Problem Statement for HTTP Streaming > Author(s) : Q. Wu, R. Huang > Filename : draft-wu-http-streaming-optimization-ps-03.txt > Pages : 22 > Date : 2010-10-25 > > HTTP Streaming allows breaking the live contents or stored contents > into several chunks/fragments and supplying them in order to the > client. However streaming long duration and high quality media over > the internet to satisfy the real time streaming requirements has > several Challenges when we require the client to access the same > media content with the common Quality experience at any device, > anytime, anywhere. This document explores problems inherent in HTTP > streaming. Several issues regarding network support for HTTP > Streaming have been raised, which include QoE improvement offering to > streaming video over Internet, efficient delivery, Playback control > and real time streaming media synchronization support. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From stockhammer@nomor.de Tue Oct 26 07:35:46 2010 Return-Path: <stockhammer@nomor.de> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 017F93A696A for <httpstreaming@core3.amsl.com>; Tue, 26 Oct 2010 07:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I75OhkNoQS35 for <httpstreaming@core3.amsl.com>; Tue, 26 Oct 2010 07:35:44 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id D03313A6959 for <httpstreaming@ietf.org>; Tue, 26 Oct 2010 07:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1288103848; l=7176; s=domk; d=nomor.de; h=To:Date:Subject:From:Cc:Content-Transfer-Encoding:Content-Type: Mime-Version:In-Reply-To:References:X-RZG-CLASS-ID:X-RZG-AUTH; bh=U0jw9d8QXCu/aonGkZPPfsw1PU8=; b=WBAdavbdXtYfPJAcLFRgdLtNNQA7mllHkagUgaP462sMODNlgNMDHdiCAl0Du5wl1/D 3GVXbM5dqvvK9/jxM86lTVBnHGv5EfMtX+7HVLfOajNy+ukeJGzkYwWDiKFP9rNcfbAJ+ fNbjVSkJmmedpvLtc1fx84Ikm8PR9A/MRjE= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu18+1EZfOQVAS4z6gUSvLg= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.159] (business-213-023-252-114.static.arcor-ip.net [213.23.252.114]) by post.strato.de (mrclete mo45) (RZmta 23.5) with ESMTP id 603997m9QDhIOO ; Tue, 26 Oct 2010 16:37:26 +0200 (MEST) References: <00d801cb7437$d50ddd30$3a298a0a@china.huawei.com> In-Reply-To: <00d801cb7437$d50ddd30$3a298a0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Message-Id: <9FB119A7-D30E-45E5-BD6C-453413DC89FA@nomor.de> Content-Transfer-Encoding: quoted-printable From: Thomas Stockhammer <stockhammer@nomor.de> Date: Tue, 26 Oct 2010 16:37:24 +0200 To: Ning Zong <zongning@huawei.com> X-Mailer: Apple Mail (2.1075.2) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01 X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 26 Oct 2010 14:35:46 -0000 Experts, Here are my initial comments: Abstract: - private -> proprietary Introduction: - The first sentence is messed, it mixes singular and plural - The list of codecs, formats, players, platforms in the first =20 sentence is quite arbitrary and more confusing than helpful - Advantages on Adaptive Streaming over HTTP had been listed many =20 times and a long time ago for example here: http://www.ietf.org/mail-archive/web/avt/current/msg11340.html - 3GPP defines formats for MPD and Segments, including the Media =20 Segment Format. Client behaviour is informative - The ISO/IEC JTC1/SC29/WG11 (MPEG) work has progressed significantly =20= to a committee draft. The committee draft is heavily based on 3GPP AHS =20= and has the same objectives, namely the definition of the formats for =20= MPD and segments. 3.1 3GPP - PSS is a stReaming services, it is hot, but not as hot as you make it. - A significant amount of the text in 3.1. is just copied from the =20 spec. It may be sufficient to point to the spec. It is public. - Some text in your document is sloppy, others is directly copied. I =20 do not see any value to copy text as I said. 3.2 OIPF - It is incorrect that your document introduces the extensions of the =20= OIPF to 3GPP. The OIPF spec does this. - The usage of normative text in your document seems inappropriate, =20 like the "SHALL" in 3.2.2 and 3.2.3. Again, the OIPF spec is public =20 and it is of no value to copy some text directly into this draft. 3.3 MPEG - Again this is a pure copy of existing MPEG documents. A reference is =20= sufficient. - The information is outdated, as mentioned. Significant progress =20 since MPEG#94 On 5) 5.1) - It would be good to fix the typos - 3GPP segments and MPD are defined by their MIME Types. The statement =20= in your table on file endings is wrong. Please refer to the specifications: for MPD: MIME Type is vnd.3gpp.mpd, file extension is = .3gm for Media Segment: MIME Type is vnd.3gpp.segment, file = extension =20 is .3gs - the steps in 1-3) are heavily simplified and this can only be an =20 example. A client can act much differently, such as using byte ranges, =20= parallel requests, etc. The server itself is also expected to be a CDN =20= and is completely unaware of the contained media. - I am not sure I understand the term "is encrypted into files" - What do you mean "normal text file"? - The intelligence in the Adaptive Streaming over HTTP is almost =20 exclusively in the client, there is no negotiation - The server software is typically considered standard HTTP/1.1, no =20 specific intelligence. Some intelligence is needed in the preparation =20= of the content, but this is typically no real-time process, at least =20 for On-Demand video. Also for live "serving" and "preparation" are =20 completely decoupled. 5.2) - It is not correct that the 3GPP MPD needs to be updated even for =20 live. If you use a template mode, the MPD stays static until some =20 "unforeseen" event occurs. Client and Content Preparation have agreed =20= on rules to construct URIs. - If necessary, the MPD update happens asynchronously to the media =20 decoding, so this is not considered to be a problem. - I still heavily disagree with the push scenario as being viable. =20 This assumes that there is a 1-1 relationship between the server and =20 the client and the server is aware of the client's state. This is not =20= in scope of any of the HTTP Streaming technologies that are referred =20 to in your document. What you are proposing is more like advanced =20 progressive download from dedicated servers. This had also been =20 discussed in 3GPP, but is a different technology. It is server-=20 enhanced progressive download and the client only issues a single HTTP =20= request. - There is for sure mechanisms to deliver important packets more =20 reliably in HTTP - you just request it earlier. In anticipation of =20 switching a smart client may also prepare such data. The client is =20 intelligent. - 3GPP defines QoE metrics that can reused also for HTTP Streaming. =20 there will also be efforts in MPEG in including QoE. 5.3) - The No in QoE monitoring seems to be wrong, the same on fast start-=20 up, see above! - The other 'No's seem to assume a different model on delivery and we =20= should really check, if this is still in the scope. It seems to =20 address generic HTTP delivery issues, not streaming specific aspects. Best regards Thomas On Oct 25, 2010, at 1:29 PM, Ning Zong wrote: > Hi, Folks, > > I have updated HTTP streaming survey and gap analysis draft and the =20= > new > version is as attached. You can also check the URL below: > http://www.ietf.org/id/draft-zong-httpstreaming-gap-analysis-01.txt > > BR, > Ning Zong > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, October 25, 2010 6:47 PM > To: zongning@huawei.com > Subject: New Version Notification for > draft-zong-httpstreaming-gap-analysis-01 > > > A new version of I-D, draft-zong-httpstreaming-gap-analysis-01.txt =20 > has been > successfully submitted by Ning Zong and posted to the IETF repository. > > Filename: draft-zong-httpstreaming-gap-analysis > Revision: 01 > Title: Survey and Gap Analysis for HTTP Streaming = Standards and > Implementations > Creation_date: 2010-10-24 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > With the explosive growth of the Internet usage and increasing demand > for multimedia information on the web, media delivery over Internet > attract substantial attention from media industry. To meet above > requirements, HTTP Streaming technology is designed and gradually > plays an important role in recent years. Several leading Standard > Development Organizations (SDOs) have been producing a series of > technical specifications to define streaming over HTTP. Moreover, > several companies have devoted to developing private HTTP-based media > delivery platform to provide high quality, adaptive viewing > experience to customers. Following a brief survey of existing HTTP > streaming standards and implementations, this document gives a brief > summary on these related work, analyzes the potential challenges > especially from the network point of view, and lists the gap between > existing work and possible working scope on the topic of HTTP > streaming in IETF. > > > > > The IETF Secretariat. > > <draft-zong-httpstreaming-gap-=20 > analysis-01.txt>_______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 =20 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - =20 Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - =20 Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From zongning@huawei.com Wed Oct 27 22:55:55 2010 Return-Path: <zongning@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1D03A682C for <httpstreaming@core3.amsl.com>; Wed, 27 Oct 2010 22:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.941 X-Spam-Level: X-Spam-Status: No, score=-99.941 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYbl8BFVLWNF for <httpstreaming@core3.amsl.com>; Wed, 27 Oct 2010 22:55:50 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 8161F3A67D7 for <httpstreaming@ietf.org>; Wed, 27 Oct 2010 22:55:49 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAZ00DFQKJU2N@szxga04-in.huawei.com> for httpstreaming@ietf.org; Thu, 28 Oct 2010 13:57:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LAZ00IJMKJULW@szxga04-in.huawei.com> for httpstreaming@ietf.org; Thu, 28 Oct 2010 13:57:30 +0800 (CST) Received: from z63316 ([10.138.41.58]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LAZ00K7EKJP5G@szxml04-in.huawei.com> for httpstreaming@ietf.org; Thu, 28 Oct 2010 13:57:27 +0800 (CST) Date: Thu, 28 Oct 2010 13:57:15 +0800 From: Ning Zong <zongning@huawei.com> In-reply-to: <9FB119A7-D30E-45E5-BD6C-453413DC89FA@nomor.de> To: 'Thomas Stockhammer' <stockhammer@nomor.de> Message-id: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Thread-index: Act1G1dVNshys64XQKWFs2wTBmL8iwAfuLgQ Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01 X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 Oct 2010 05:55:56 -0000 Hi, Thomas, Thank you very much for your detailed review. I think the comments are = also very helpful for improving the draft. Please see my response in-line starting with [ZN]. -----Original Message----- From: Thomas Stockhammer [mailto:stockhammer@nomor.de]=20 Sent: Tuesday, October 26, 2010 10:37 PM To: Ning Zong Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01 Experts, Here are my initial comments: Abstract: - private -> proprietary [ZN]: ok Introduction: - The first sentence is messed, it mixes singular and plural [ZN]: OK, thanks. - The list of codecs, formats, players, platforms in the first =20 sentence is quite arbitrary and more confusing than helpful [ZN]: I will clarify the text in next revision. - Advantages on Adaptive Streaming over HTTP had been listed many =20 times and a long time ago for example here: http://www.ietf.org/mail-archive/web/avt/current/msg11340.html [ZN]: I will refer to this discussion in next revision. - 3GPP defines formats for MPD and Segments, including the Media =20 Segment Format. Client behaviour is informative - The ISO/IEC JTC1/SC29/WG11 (MPEG) work has progressed significantly =20 to a committee draft. The committee draft is heavily based on 3GPP AHS =20 and has the same objectives, namely the definition of the formats for =20 MPD and segments. [ZN]: I will investigate more about recent progress on MPEG and OIPF = work. 3.1 3GPP - PSS is a stReaming services, it is hot, but not as hot as you make it. - A significant amount of the text in 3.1. is just copied from the =20 spec. It may be sufficient to point to the spec. It is public. [ZN]: Right, but this part of the draft is purely survey and should = mostly rely on the reference. The analysis part is on Section 5. But anyway, I = will modify the text to simplify the copied text and add summary text when needed, in the next revision. - Some text in your document is sloppy, others is directly copied. I =20 do not see any value to copy text as I said. 3.2 OIPF - It is incorrect that your document introduces the extensions of the =20 OIPF to 3GPP. The OIPF spec does this. - The usage of normative text in your document seems inappropriate, =20 like the "SHALL" in 3.2.2 and 3.2.3. Again, the OIPF spec is public =20 and it is of no value to copy some text directly into this draft. [ZN]: I will remove the normative term in next revision. 3.3 MPEG - Again this is a pure copy of existing MPEG documents. A reference is =20 sufficient. - The information is outdated, as mentioned. Significant progress =20 since MPEG#94 [ZN]: As noted, I will investigate more about recent progress on MPEG = and OIPF work. On 5) 5.1) - It would be good to fix the typos [ZN]: OK, thanks. - 3GPP segments and MPD are defined by their MIME Types. The statement =20 in your table on file endings is wrong. Please refer to the specifications: for MPD: MIME Type is vnd.3gpp.mpd, file extension is .3gm for Media Segment: MIME Type is vnd.3gpp.segment, file extension =20 is .3gs [ZN]: Thank you. - the steps in 1-3) are heavily simplified and this can only be an =20 example. A client can act much differently, such as using byte ranges, =20 parallel requests, etc. The server itself is also expected to be a CDN =20 and is completely unaware of the contained media. - I am not sure I understand the term "is encrypted into files" [ZN]: I mean "use file with media container" here. - What do you mean "normal text file"? [ZN]: traditional web page (e.g. html file). - The intelligence in the Adaptive Streaming over HTTP is almost =20 exclusively in the client, there is no negotiation [ZN]: Sorry for confusion, "negotiation" should be "massage exchange". - The server software is typically considered standard HTTP/1.1, no =20 specific intelligence. Some intelligence is needed in the preparation =20 of the content, but this is typically no real-time process, at least =20 for On-Demand video. Also for live "serving" and "preparation" are =20 completely decoupled. 5.2) - It is not correct that the 3GPP MPD needs to be updated even for =20 live. If you use a template mode, the MPD stays static until some =20 "unforeseen" event occurs. Client and Content Preparation have agreed =20 on rules to construct URIs. - If necessary, the MPD update happens asynchronously to the media =20 decoding, so this is not considered to be a problem. [ZN]: I didn't intend to state that pull model doesn't work. My point = is, why not investigating the possible usage of push model in certain cases without experiencing the above mentioned "unforeseen" event or = asynchronous updates? - I still heavily disagree with the push scenario as being viable. =20 This assumes that there is a 1-1 relationship between the server and =20 the client and the server is aware of the client's state. This is not =20 in scope of any of the HTTP Streaming technologies that are referred =20 to in your document. What you are proposing is more like advanced =20 progressive download from dedicated servers. This had also been =20 discussed in 3GPP, but is a different technology. It is server-=20 enhanced progressive download and the client only issues a single HTTP =20 request. - There is for sure mechanisms to deliver important packets more =20 reliably in HTTP - you just request it earlier. In anticipation of =20 switching a smart client may also prepare such data. The client is =20 intelligent. [ZN]: Well, I think this startup issue doesn't like the pre-fetch which = is of course still valuable to improve playback. IMO, it is hard to predict which channel the user will switch to in the next moment, hence it is = not reasonable to request important packets for other channels. Did I misunderstand you? - 3GPP defines QoE metrics that can reused also for HTTP Streaming. =20 there will also be efforts in MPEG in including QoE. [ZN]: I am not proposing to focus on defining QoE metrics, but looking = on the protocols to report such metrics, like RTCP. We will support the = work in 3GPP/MPEG and cooperate with them to see how to capsulate the metrics in = a series of messages. 5.3) - The No in QoE monitoring seems to be wrong, the same on fast start-=20 up, see above! - The other 'No's seem to assume a different model on delivery and we =20 should really check, if this is still in the scope. It seems to =20 address generic HTTP delivery issues, not streaming specific aspects. [ZN]: OK, we will check them again and see which can be potentially reasonable in our proposed work. Best regards Thomas On Oct 25, 2010, at 1:29 PM, Ning Zong wrote: > Hi, Folks, > > I have updated HTTP streaming survey and gap analysis draft and the =20 > new > version is as attached. You can also check the URL below: > http://www.ietf.org/id/draft-zong-httpstreaming-gap-analysis-01.txt > > BR, > Ning Zong > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, October 25, 2010 6:47 PM > To: zongning@huawei.com > Subject: New Version Notification for > draft-zong-httpstreaming-gap-analysis-01 > > > A new version of I-D, draft-zong-httpstreaming-gap-analysis-01.txt =20 > has been > successfully submitted by Ning Zong and posted to the IETF repository. > > Filename: draft-zong-httpstreaming-gap-analysis > Revision: 01 > Title: Survey and Gap Analysis for HTTP Streaming Standards and > Implementations > Creation_date: 2010-10-24 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > With the explosive growth of the Internet usage and increasing demand > for multimedia information on the web, media delivery over Internet > attract substantial attention from media industry. To meet above > requirements, HTTP Streaming technology is designed and gradually > plays an important role in recent years. Several leading Standard > Development Organizations (SDOs) have been producing a series of > technical specifications to define streaming over HTTP. Moreover, > several companies have devoted to developing private HTTP-based media > delivery platform to provide high quality, adaptive viewing > experience to customers. Following a brief survey of existing HTTP > streaming standards and implementations, this document gives a brief > summary on these related work, analyzes the potential challenges > especially from the network point of view, and lists the gap between > existing work and possible working scope on the topic of HTTP > streaming in IETF. > > > > > The IETF Secretariat. > > <draft-zong-httpstreaming-gap-=20 > analysis-01.txt>_______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 =20 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - =20 Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - =20 Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From stockhammer@nomor.de Wed Oct 27 23:49:27 2010 Return-Path: <stockhammer@nomor.de> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A0483A6856 for <httpstreaming@core3.amsl.com>; Wed, 27 Oct 2010 23:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOO2TC+2zSRK for <httpstreaming@core3.amsl.com>; Wed, 27 Oct 2010 23:49:25 -0700 (PDT) Received: from mo-p00-ob.rzone.de (mo-p00-ob.rzone.de [81.169.146.160]) by core3.amsl.com (Postfix) with ESMTP id 4F5183A683B for <httpstreaming@ietf.org>; Wed, 27 Oct 2010 23:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; t=1288248675; l=4585; s=domk; d=nomor.de; h=To:Date:Subject:From:Cc:Content-Transfer-Encoding:Content-Type: Mime-Version:In-Reply-To:References:X-RZG-CLASS-ID:X-RZG-AUTH; bh=h6/cVG2AmGbo/eTlKWs3SSZ4h4g=; b=fkpwrDVPYyQCaadlxzsvM2ll9gR/vPSCT1Si8okIUZyr7r+xk1pzNLREuhBnI33VKSW vOIOkNTSij5kh6G2EKRsuOxhGXzJ1tYzSurYx5ozWoLRcimcj5hvVXHPEjkCIp1YpF5au xIqCBRWiPhittUTCiOZ0W39KH1AsO44Ze7I= X-RZG-AUTH: :P3gLdkugevKirJkjH/RoTtk5THWq6nlFgKpnuMPeiu1/+lsZeuEVAt6MCUod3l0= X-RZG-CLASS-ID: mo00 Received: from ip-109-46-172-150.web.vodafone.de ([109.46.172.150]) by post.strato.de (jimi mo12) (RZmta 24.2) with ESMTP id N04774m9S2u4pY ; Thu, 28 Oct 2010 08:51:11 +0200 (MEST) References: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> In-Reply-To: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Message-Id: <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> Content-Transfer-Encoding: quoted-printable From: Thomas Stockhammer <stockhammer@nomor.de> Date: Thu, 28 Oct 2010 08:51:00 +0200 To: Ning Zong <zongning@huawei.com> X-Mailer: Apple Mail (2.1075.2) Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01 X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 Oct 2010 06:49:27 -0000 Ning, thanks .... I recognized that you only replied to some of my comments. Does this mean that you agree/disagree with the remaining ones? Inline some more with [T] ... [\T] Thomas > - I am not sure I understand the term "is encrypted into files" > [ZN]: I mean "use file with media container" here. [T] I do not understand this either! [\T] > - What do you mean "normal text file"? > [ZN]: traditional web page (e.g. html file). [T] we should be much more careful with terminology [\T] > - The intelligence in the Adaptive Streaming over HTTP is almost > exclusively in the client, there is no negotiation > [ZN]: Sorry for confusion, "negotiation" should be "massage exchange". [T] First I hope this is a typo, otherwise I get more curious ...! Secondly, I am still not clear what needs to be done beyond regular =20 http connections [\T] > 5.2) > - It is not correct that the 3GPP MPD needs to be updated even for > live. If you use a template mode, the MPD stays static until some > "unforeseen" event occurs. Client and Content Preparation have agreed > on rules to construct URIs. > - If necessary, the MPD update happens asynchronously to the media > decoding, so this is not considered to be a problem. > [ZN]: I didn't intend to state that pull model doesn't work. My =20 > point is, > why not investigating the possible usage of push model in certain =20 > cases > without experiencing the above mentioned "unforeseen" event or =20 > asynchronous > updates? [T] "Push" is a very very broad term. In Web applications you can for =20 example use AJAX or RSS/ATOM like techniques for push-like updates. If =20= you use conditional GET for regular polling, this is very efficient. =20 The MPD updates in 3GPP work in a similar manner. If you use polling, =20= conditional GETs and templates, you are extremely efficient. We should =20= really understand what we mean by push model? HTTP-based delivery is =20 rich and provides many successfully deployed options. Should you really refer to something completely different such as IP =20 multicast, then I would feel very very uncomfortable. [\T] > - There is for sure mechanisms to deliver important packets more > reliably in HTTP - you just request it earlier. In anticipation of > switching a smart client may also prepare such data. The client is > intelligent. > [ZN]: Well, I think this startup issue doesn't like the pre-fetch =20 > which is > of course still valuable to improve playback. IMO, it is hard to =20 > predict > which channel the user will switch to in the next moment, hence it =20 > is not > reasonable to request important packets for other channels. Did I > misunderstand you? [T] I would not be worried to have the MPD and the initialization segment =20= of the two neighboring channels ready in my device. Again, the client =20= can be very smart, especially as it does have access to all the =20 information. In general, I do not disagree that we can create more detailed use =20 cases for environments in which we envision that HTTP streaming will =20 be used. This may include live multi-channel environments. However, we =20= should not conclude per se that the existing technologies do have a =20 problem. [\T] > - 3GPP defines QoE metrics that can reused also for HTTP Streaming. > there will also be efforts in MPEG in including QoE. > [ZN]: I am not proposing to focus on defining QoE metrics, but =20 > looking on > the protocols to report such metrics, like RTCP. We will support the =20= > work in > 3GPP/MPEG and cooperate with them to see how to capsulate the =20 > metrics in a > series of messages. [T] What do you mean with "capsulate"? Also, can you be more specific what metrics there are in RTCP that can =20= also be used in HTTP Streaming. I consider that anything dealing with =20= packet loss is irrelevant. I also do not see the relevance of sending =20= regular 5 seconds receiver reports as the content is static and =20 adaptation will not happen. Some reporting on Media Presentation level =20= may be sufficient, for example when the presentation has been completed. [\T] --- Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 =20 978980 02 || cell +491725702667 || http://www.nomor-research.com Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - =20 Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - =20 Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. From watsonm@netflix.com Thu Oct 28 12:16:04 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E6A3A685B for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnQ0rFO2n68i for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 12:16:03 -0700 (PDT) Received: from mx1.netflix.com (mx1.netflix.com [208.75.77.144]) by core3.amsl.com (Postfix) with ESMTP id 24B0F3A6800 for <httpstreaming@ietf.org>; Thu, 28 Oct 2010 12:16:03 -0700 (PDT) Received: from ExchFE101.netflix.com (exchfe101.netflix.com [10.64.32.101]) by mx1.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o9SJHpRn023778; Thu, 28 Oct 2010 12:17:51 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE101.netflix.com ([fe80::6861:6a26:831f:e8c9%14]) with mapi; Thu, 28 Oct 2010 12:17:50 -0700 From: Mark Watson <watsonm@netflix.com> To: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Date: Thu, 28 Oct 2010 12:17:49 -0700 Thread-Topic: Efficient manifest push (Re: [httpstreaming] FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) Thread-Index: Act21M9w190H3jo3Skmdzb81ZAw9+A== Message-ID: <A0F798C3-2ECB-4150-8EC0-7A23118D057E@netflix.com> References: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> In-Reply-To: <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 28 Oct 2010 19:16:04 -0000 Here is an idea sparked by Thomas' mention below of AJAX and RSS push servi= ces. In these services the client establishes a long-lived HTTP connection to a = server on which it sends a single request. The response comes back in chunk= s, over time, enabling the server to "push" new content as it becomes avail= able. Generally caches and proxies are transparent to this, although I thin= k it does not work with some older proxies which expect to receive the whol= e response from upstream before returning anything to the client. Perhaps t= hese are all gone by now. But anyway, the "chunks" cannot really be cached = as the proxy has no idea what they are. In the case of a document, such as a manifest, which is being periodically = updated, or a sequence of different files, one could very simply expose the= se semantics in a standard way, which would enable caches to do their thing= . For example, suppose we define a new MIME type, multipart/versions, where e= ach part of the multipart MIME response is a different version of the origi= nally requested resource. A smart cache receiving a request for this resour= ce can cache the "parts" as they arrive, each replacing the previously cach= ed version. It can serve multiple incoming persistent connections with one = upstream persistent connection, providing scalability. It would be transpar= ent to existing caches. Clients would indicate their support in the Accept = header and clients which did not support this mode would just poll the reso= urce in the usual way with conditional GET requests. All that would be required from a standards perspective would be definition= of the multipart/versions MIME type. Maybe this is not new. I could easily imagine CDNs do this kind of thing in= ternally already. Similarly, one could imagine a multipart/sequence MIME type where the parts= form a sequence of objects. The client requests an object and (if it indic= ates support of the multipart/sequence MIME type) gets back that object and= subsequent ones in the sequence (with their file names). Again, smart cach= es could optimise for scalability, caching the parts as separate objects. T= his could help with delivery of segments in the live case, but again mainta= ining backwards-compatibility. Again, perhaps CDNs already do something lik= e this internally. I'm not proposing to progress these ideas, just thought they were interesti= ng. ...Mark On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote: > Ning, >=20 > thanks .... >=20 > I recognized that you only replied to some of my comments. > Does this mean that you agree/disagree with the remaining ones? >=20 > Inline some more with [T] ... [\T] >=20 > Thomas >=20 >> - I am not sure I understand the term "is encrypted into files" >> [ZN]: I mean "use file with media container" here. >=20 > [T] I do not understand this either! [\T] >=20 >> - What do you mean "normal text file"? >> [ZN]: traditional web page (e.g. html file). >=20 > [T] we should be much more careful with terminology [\T] >=20 >> - The intelligence in the Adaptive Streaming over HTTP is almost >> exclusively in the client, there is no negotiation >> [ZN]: Sorry for confusion, "negotiation" should be "massage exchange". >=20 > [T] > First I hope this is a typo, otherwise I get more curious ...! > Secondly, I am still not clear what needs to be done beyond regular =20 > http connections > [\T] >=20 >> 5.2) >> - It is not correct that the 3GPP MPD needs to be updated even for >> live. If you use a template mode, the MPD stays static until some >> "unforeseen" event occurs. Client and Content Preparation have agreed >> on rules to construct URIs. >> - If necessary, the MPD update happens asynchronously to the media >> decoding, so this is not considered to be a problem. >> [ZN]: I didn't intend to state that pull model doesn't work. My =20 >> point is, >> why not investigating the possible usage of push model in certain =20 >> cases >> without experiencing the above mentioned "unforeseen" event or =20 >> asynchronous >> updates? >=20 > [T] > "Push" is a very very broad term. In Web applications you can for =20 > example use AJAX or RSS/ATOM like techniques for push-like updates. If =20 > you use conditional GET for regular polling, this is very efficient. =20 > The MPD updates in 3GPP work in a similar manner. If you use polling, =20 > conditional GETs and templates, you are extremely efficient. We should =20 > really understand what we mean by push model? HTTP-based delivery is =20 > rich and provides many successfully deployed options. >=20 > Should you really refer to something completely different such as IP =20 > multicast, then I would feel very very uncomfortable. > [\T] >=20 >> - There is for sure mechanisms to deliver important packets more >> reliably in HTTP - you just request it earlier. In anticipation of >> switching a smart client may also prepare such data. The client is >> intelligent. >> [ZN]: Well, I think this startup issue doesn't like the pre-fetch =20 >> which is >> of course still valuable to improve playback. IMO, it is hard to =20 >> predict >> which channel the user will switch to in the next moment, hence it =20 >> is not >> reasonable to request important packets for other channels. Did I >> misunderstand you? >=20 > [T] > I would not be worried to have the MPD and the initialization segment =20 > of the two neighboring channels ready in my device. Again, the client =20 > can be very smart, especially as it does have access to all the =20 > information. >=20 > In general, I do not disagree that we can create more detailed use =20 > cases for environments in which we envision that HTTP streaming will =20 > be used. This may include live multi-channel environments. However, we =20 > should not conclude per se that the existing technologies do have a =20 > problem. > [\T] >=20 >> - 3GPP defines QoE metrics that can reused also for HTTP Streaming. >> there will also be efforts in MPEG in including QoE. >> [ZN]: I am not proposing to focus on defining QoE metrics, but =20 >> looking on >> the protocols to report such metrics, like RTCP. We will support the =20 >> work in >> 3GPP/MPEG and cooperate with them to see how to capsulate the =20 >> metrics in a >> series of messages. >=20 > [T] > What do you mean with "capsulate"? > Also, can you be more specific what metrics there are in RTCP that can =20 > also be used in HTTP Streaming. I consider that anything dealing with =20 > packet loss is irrelevant. I also do not see the relevance of sending =20 > regular 5 seconds receiver reports as the content is static and =20 > adaptation will not happen. Some reporting on Media Presentation level =20 > may be sufficient, for example when the presentation has been completed. > [\T] >=20 >=20 > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 =20 > 978980 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - =20 > Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 -= =20 > Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >=20 >=20 >=20 >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From sunseawq@huawei.com Thu Oct 28 20:00:54 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55DB3A69E7 for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 20:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.077 X-Spam-Level: * X-Spam-Status: No, score=1.077 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_BASE64_TEXT=1.753, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4mue+7d3VZY for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 20:00:53 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id E39A43A6804 for <httpstreaming@ietf.org>; Thu, 28 Oct 2010 20:00:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB100ILW74BLQ@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 29 Oct 2010 11:02:36 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB1003KI74BMU@szxga03-in.huawei.com> for httpstreaming@ietf.org; Fri, 29 Oct 2010 11:02:35 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB100EEN74B5H@szxml04-in.huawei.com> for httpstreaming@ietf.org; Fri, 29 Oct 2010 11:02:35 +0800 (CST) Date: Fri, 29 Oct 2010 11:02:35 +0800 From: Qin Wu <sunseawq@huawei.com> To: Mark Watson <watsonm@netflix.com>, httpstreaming@ietf.org Message-id: <02a801cb7715$bcd44e80$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: base64 X-Priority: 3 X-MSMail-priority: Normal References: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> <A0F798C3-2ECB-4150-8EC0-7A23118D057E@netflix.com> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Oct 2010 03:00:54 -0000 SGksIA0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJNYXJrIFdhdHNvbiIg PHdhdHNvbm1AbmV0ZmxpeC5jb20+DQpUbzogPGh0dHBzdHJlYW1pbmdAaWV0Zi5vcmc+DQpTZW50 OiBGcmlkYXksIE9jdG9iZXIgMjksIDIwMTAgMzoxNyBBTQ0KU3ViamVjdDogW2h0dHBzdHJlYW1p bmddIEVmZmljaWVudCBtYW5pZmVzdCBwdXNoIChSZTogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtem9uZy1odHRwc3RyZWFtaW5nLWdhcC1hbmFseXNpcy0wMSkNCg0KDQpI ZXJlIGlzIGFuIGlkZWEgc3BhcmtlZCBieSBUaG9tYXMnIG1lbnRpb24gYmVsb3cgb2YgQUpBWCBh bmQgUlNTIHB1c2ggc2VydmljZXMuDQoNCkluIHRoZXNlIHNlcnZpY2VzIHRoZSBjbGllbnQgZXN0 YWJsaXNoZXMgYSBsb25nLWxpdmVkIEhUVFAgY29ubmVjdGlvbiB0byBhIHNlcnZlciBvbiB3aGlj aCBpdCBzZW5kcyBhIHNpbmdsZSByZXF1ZXN0LiBUaGUgcmVzcG9uc2UgY29tZXMgYmFjayBpbiBj aHVua3MsIG92ZXIgdGltZSwgZW5hYmxpbmcgdGhlIHNlcnZlciB0byAicHVzaCIgbmV3IGNvbnRl bnQgYXMgaXQgYmVjb21lcyBhdmFpbGFibGUuIEdlbmVyYWxseSBjYWNoZXMgYW5kIHByb3hpZXMg YXJlIHRyYW5zcGFyZW50IHRvIHRoaXMsIGFsdGhvdWdoIEkgdGhpbmsgaXQgZG9lcyBub3Qgd29y ayB3aXRoIHNvbWUgb2xkZXIgcHJveGllcyB3aGljaCBleHBlY3QgdG8gcmVjZWl2ZSB0aGUgd2hv bGUgcmVzcG9uc2UgZnJvbSB1cHN0cmVhbSBiZWZvcmUgcmV0dXJuaW5nIGFueXRoaW5nIHRvIHRo ZSBjbGllbnQuIFBlcmhhcHMgdGhlc2UgYXJlIGFsbCBnb25lIGJ5IG5vdy4gQnV0IGFueXdheSwg dGhlICJjaHVua3MiIGNhbm5vdCByZWFsbHkgYmUgY2FjaGVkIGFzIHRoZSBwcm94eSBoYXMgbm8g aWRlYSB3aGF0IHRoZXkgYXJlLg0KDQpJbiB0aGUgY2FzZSBvZiBhIGRvY3VtZW50LCBzdWNoIGFz IGEgbWFuaWZlc3QsIHdoaWNoIGlzIGJlaW5nIHBlcmlvZGljYWxseSB1cGRhdGVkLCBvciBhIHNl cXVlbmNlIG9mIGRpZmZlcmVudCBmaWxlcywgb25lIGNvdWxkIHZlcnkgc2ltcGx5IGV4cG9zZSB0 aGVzZSBzZW1hbnRpY3MgaW4gYSBzdGFuZGFyZCB3YXksIHdoaWNoIHdvdWxkIGVuYWJsZSBjYWNo ZXMgdG8gZG8gdGhlaXIgdGhpbmcuDQoNCkZvciBleGFtcGxlLCBzdXBwb3NlIHdlIGRlZmluZSBh IG5ldyBNSU1FIHR5cGUsIG11bHRpcGFydC92ZXJzaW9ucywgd2hlcmUgZWFjaCBwYXJ0IG9mIHRo ZSBtdWx0aXBhcnQgTUlNRSByZXNwb25zZSBpcyBhIGRpZmZlcmVudCB2ZXJzaW9uIG9mIHRoZSBv cmlnaW5hbGx5IHJlcXVlc3RlZCByZXNvdXJjZS4gQSBzbWFydCBjYWNoZSByZWNlaXZpbmcgYSBy ZXF1ZXN0IGZvciB0aGlzIHJlc291cmNlIGNhbiBjYWNoZSB0aGUgInBhcnRzIiBhcyB0aGV5IGFy cml2ZSwgZWFjaCByZXBsYWNpbmcgdGhlIHByZXZpb3VzbHkgY2FjaGVkIHZlcnNpb24uIEl0IGNh biBzZXJ2ZSBtdWx0aXBsZSBpbmNvbWluZyBwZXJzaXN0ZW50IGNvbm5lY3Rpb25zIHdpdGggb25l IHVwc3RyZWFtIHBlcnNpc3RlbnQgY29ubmVjdGlvbiwgcHJvdmlkaW5nIHNjYWxhYmlsaXR5LiBJ dCB3b3VsZCBiZSB0cmFuc3BhcmVudCB0byBleGlzdGluZyBjYWNoZXMuIENsaWVudHMgd291bGQg aW5kaWNhdGUgdGhlaXIgc3VwcG9ydCBpbiB0aGUgQWNjZXB0IGhlYWRlciBhbmQgY2xpZW50cyB3 aGljaCBkaWQgbm90IHN1cHBvcnQgdGhpcyBtb2RlIHdvdWxkIGp1c3QgcG9sbCB0aGUgcmVzb3Vy Y2UgaW4gdGhlIHVzdWFsIHdheSB3aXRoIGNvbmRpdGlvbmFsIEdFVCByZXF1ZXN0cy4NCg0KQWxs IHRoYXQgd291bGQgYmUgcmVxdWlyZWQgZnJvbSBhIHN0YW5kYXJkcyBwZXJzcGVjdGl2ZSB3b3Vs ZCBiZSBkZWZpbml0aW9uIG9mIHRoZSBtdWx0aXBhcnQvdmVyc2lvbnMgTUlNRSB0eXBlLg0KDQpN YXliZSB0aGlzIGlzIG5vdCBuZXcuIEkgY291bGQgZWFzaWx5IGltYWdpbmUgQ0ROcyBkbyB0aGlz IGtpbmQgb2YgdGhpbmcgaW50ZXJuYWxseSBhbHJlYWR5Lg0KDQpTaW1pbGFybHksIG9uZSBjb3Vs ZCBpbWFnaW5lIGEgbXVsdGlwYXJ0L3NlcXVlbmNlIE1JTUUgdHlwZSB3aGVyZSB0aGUgcGFydHMg Zm9ybSBhIHNlcXVlbmNlIG9mIG9iamVjdHMuIFRoZSBjbGllbnQgcmVxdWVzdHMgYW4gb2JqZWN0 IGFuZCAoaWYgaXQgaW5kaWNhdGVzIHN1cHBvcnQgb2YgdGhlIG11bHRpcGFydC9zZXF1ZW5jZSBN SU1FIHR5cGUpIGdldHMgYmFjayB0aGF0IG9iamVjdCBhbmQgc3Vic2VxdWVudCBvbmVzIGluIHRo ZSBzZXF1ZW5jZSAod2l0aCB0aGVpciBmaWxlIG5hbWVzKS4gQWdhaW4sIHNtYXJ0IGNhY2hlcyBj b3VsZCBvcHRpbWlzZSBmb3Igc2NhbGFiaWxpdHksIGNhY2hpbmcgdGhlIHBhcnRzIGFzIHNlcGFy YXRlIG9iamVjdHMuIFRoaXMgY291bGQgaGVscCB3aXRoIGRlbGl2ZXJ5IG9mIHNlZ21lbnRzIGlu IHRoZSBsaXZlIGNhc2UsIGJ1dCBhZ2FpbiBtYWludGFpbmluZyBiYWNrd2FyZHMtY29tcGF0aWJp bGl0eS4gQWdhaW4sIHBlcmhhcHMgQ0ROcyBhbHJlYWR5IGRvIHNvbWV0aGluZyBsaWtlIHRoaXMg aW50ZXJuYWxseS4NCg0KSSdtIG5vdCBwcm9wb3NpbmcgdG8gcHJvZ3Jlc3MgdGhlc2UgaWRlYXMs IGp1c3QgdGhvdWdodCB0aGV5IHdlcmUgaW50ZXJlc3RpbmcuDQoNCltRaW5dOiBTb3VuZHMgbGlr ZSBhIGdvb2QgaWRlYSB0byBtZS4gSSB0aGluayB0aGlzIGlzIG9uZSB3YXkgdG8gYnVpbGQgdGhl IGludGVyb3BlcmFibGUgc29sdXRpb24gZm9yIGNvbmN1cnJlbnQgbGl2ZSBzdHJlYW1pbmcgdmll d2luZyB3aXRoIGJhY2t3YXJkcyBjb21wYWJpbGl0eSB0byBleGlzdGluZyBjYWNoZSBhbmQgY2xp ZW50LCB3aGljaCBtYXkgYnJpbmcgdGhlIGFkdmFudGFnZSBvZiBhbGxldmlhdGluZyBzZXJ2ZXIg bG9hZC4gIEJ1dCBJIGFtIG5vdCBzdXJlIHRoZSBNSU1FIHN1YnR5cGUgaGFzIHRoZSByaWdodCBz ZW1hbnRpYyB0byBkbyB0aGlzLiBXZSBtYXkgbmVlZCBzb21lIG5ldyBNSU1FIHN1YnR5cGUgYW5k IG5ldyBiZWhhdmlvcnMgb24gaG93IHRvIHByb2Nlc3MgaXQuDQoNCi4uLk1hcmsNCg0KDQoNCg0K T24gT2N0IDI3LCAyMDEwLCBhdCAxMTo1MSBQTSwgVGhvbWFzIFN0b2NraGFtbWVyIHdyb3RlOg0K DQo+IE5pbmcsDQo+IA0KPiB0aGFua3MgLi4uLg0KPiANCj4gSSByZWNvZ25pemVkIHRoYXQgeW91 IG9ubHkgcmVwbGllZCB0byBzb21lIG9mIG15IGNvbW1lbnRzLg0KPiBEb2VzIHRoaXMgbWVhbiB0 aGF0IHlvdSBhZ3JlZS9kaXNhZ3JlZSB3aXRoIHRoZSByZW1haW5pbmcgb25lcz8NCj4gDQo+IElu bGluZSBzb21lIG1vcmUgd2l0aCBbVF0gLi4uIFtcVF0NCj4gDQo+IFRob21hcw0KPiANCj4+IC0g SSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIHRlcm0gImlzIGVuY3J5cHRlZCBpbnRvIGZp bGVzIg0KPj4gW1pOXTogSSBtZWFuICJ1c2UgZmlsZSB3aXRoIG1lZGlhIGNvbnRhaW5lciIgaGVy ZS4NCj4gDQo+IFtUXSAgSSBkbyBub3QgdW5kZXJzdGFuZCB0aGlzIGVpdGhlciEgW1xUXQ0KPiAN Cj4+IC0gV2hhdCBkbyB5b3UgbWVhbiAibm9ybWFsIHRleHQgZmlsZSI/DQo+PiBbWk5dOiB0cmFk aXRpb25hbCB3ZWIgcGFnZSAoZS5nLiBodG1sIGZpbGUpLg0KPiANCj4gW1RdIHdlIHNob3VsZCBi ZSBtdWNoIG1vcmUgY2FyZWZ1bCB3aXRoIHRlcm1pbm9sb2d5IFtcVF0NCj4gDQo+PiAtIFRoZSBp bnRlbGxpZ2VuY2UgaW4gdGhlIEFkYXB0aXZlIFN0cmVhbWluZyBvdmVyIEhUVFAgaXMgYWxtb3N0 DQo+PiBleGNsdXNpdmVseSBpbiB0aGUgY2xpZW50LCB0aGVyZSBpcyBubyBuZWdvdGlhdGlvbg0K Pj4gW1pOXTogU29ycnkgZm9yIGNvbmZ1c2lvbiwgIm5lZ290aWF0aW9uIiBzaG91bGQgYmUgIm1h c3NhZ2UgZXhjaGFuZ2UiLg0KPiANCj4gW1RdDQo+IEZpcnN0IEkgaG9wZSB0aGlzIGlzIGEgdHlw bywgb3RoZXJ3aXNlIEkgZ2V0IG1vcmUgY3VyaW91cyAuLi4hDQo+IFNlY29uZGx5LCBJIGFtIHN0 aWxsIG5vdCBjbGVhciB3aGF0IG5lZWRzIHRvIGJlIGRvbmUgYmV5b25kIHJlZ3VsYXIgIA0KPiBo dHRwIGNvbm5lY3Rpb25zDQo+IFtcVF0NCj4gDQo+PiA1LjIpDQo+PiAtIEl0IGlzIG5vdCBjb3Jy ZWN0IHRoYXQgdGhlIDNHUFAgTVBEIG5lZWRzIHRvIGJlIHVwZGF0ZWQgZXZlbiBmb3INCj4+IGxp dmUuIElmIHlvdSB1c2UgYSB0ZW1wbGF0ZSBtb2RlLCB0aGUgTVBEIHN0YXlzIHN0YXRpYyB1bnRp bCBzb21lDQo+PiAidW5mb3Jlc2VlbiIgZXZlbnQgb2NjdXJzLiBDbGllbnQgYW5kIENvbnRlbnQg UHJlcGFyYXRpb24gaGF2ZSBhZ3JlZWQNCj4+IG9uIHJ1bGVzIHRvIGNvbnN0cnVjdCBVUklzLg0K Pj4gLSBJZiBuZWNlc3NhcnksIHRoZSBNUEQgdXBkYXRlIGhhcHBlbnMgYXN5bmNocm9ub3VzbHkg dG8gdGhlIG1lZGlhDQo+PiBkZWNvZGluZywgc28gdGhpcyBpcyBub3QgY29uc2lkZXJlZCB0byBi ZSBhIHByb2JsZW0uDQo+PiBbWk5dOiBJIGRpZG4ndCBpbnRlbmQgdG8gc3RhdGUgdGhhdCBwdWxs IG1vZGVsIGRvZXNuJ3Qgd29yay4gTXkgIA0KPj4gcG9pbnQgaXMsDQo+PiB3aHkgbm90IGludmVz dGlnYXRpbmcgdGhlIHBvc3NpYmxlIHVzYWdlIG9mIHB1c2ggbW9kZWwgaW4gY2VydGFpbiAgDQo+ PiBjYXNlcw0KPj4gd2l0aG91dCBleHBlcmllbmNpbmcgdGhlIGFib3ZlIG1lbnRpb25lZCAidW5m b3Jlc2VlbiIgZXZlbnQgb3IgIA0KPj4gYXN5bmNocm9ub3VzDQo+PiB1cGRhdGVzPw0KPiANCj4g W1RdDQo+ICJQdXNoIiBpcyBhIHZlcnkgdmVyeSBicm9hZCB0ZXJtLiBJbiBXZWIgYXBwbGljYXRp b25zIHlvdSBjYW4gZm9yICANCj4gZXhhbXBsZSB1c2UgQUpBWCBvciBSU1MvQVRPTSBsaWtlIHRl Y2huaXF1ZXMgZm9yIHB1c2gtbGlrZSB1cGRhdGVzLiBJZiAgDQo+IHlvdSB1c2UgY29uZGl0aW9u YWwgR0VUIGZvciByZWd1bGFyIHBvbGxpbmcsIHRoaXMgaXMgdmVyeSBlZmZpY2llbnQuICANCj4g VGhlIE1QRCB1cGRhdGVzIGluIDNHUFAgd29yayBpbiBhIHNpbWlsYXIgbWFubmVyLiBJZiB5b3Ug dXNlIHBvbGxpbmcsICANCj4gY29uZGl0aW9uYWwgR0VUcyBhbmQgdGVtcGxhdGVzLCB5b3UgYXJl IGV4dHJlbWVseSBlZmZpY2llbnQuIFdlIHNob3VsZCAgDQo+IHJlYWxseSB1bmRlcnN0YW5kIHdo YXQgd2UgbWVhbiBieSBwdXNoIG1vZGVsPyBIVFRQLWJhc2VkIGRlbGl2ZXJ5IGlzICANCj4gcmlj aCBhbmQgcHJvdmlkZXMgbWFueSBzdWNjZXNzZnVsbHkgZGVwbG95ZWQgb3B0aW9ucy4NCj4gDQo+ IFNob3VsZCB5b3UgcmVhbGx5IHJlZmVyIHRvIHNvbWV0aGluZyBjb21wbGV0ZWx5IGRpZmZlcmVu dCBzdWNoIGFzIElQICANCj4gbXVsdGljYXN0LCB0aGVuIEkgd291bGQgZmVlbCB2ZXJ5IHZlcnkg dW5jb21mb3J0YWJsZS4NCj4gW1xUXQ0KPiANCj4+IC0gVGhlcmUgaXMgZm9yIHN1cmUgbWVjaGFu aXNtcyB0byBkZWxpdmVyIGltcG9ydGFudCBwYWNrZXRzIG1vcmUNCj4+IHJlbGlhYmx5IGluIEhU VFAgLSB5b3UganVzdCByZXF1ZXN0IGl0IGVhcmxpZXIuIEluIGFudGljaXBhdGlvbiBvZg0KPj4g c3dpdGNoaW5nIGEgc21hcnQgY2xpZW50IG1heSBhbHNvIHByZXBhcmUgc3VjaCBkYXRhLiBUaGUg Y2xpZW50IGlzDQo+PiBpbnRlbGxpZ2VudC4NCj4+IFtaTl06IFdlbGwsIEkgdGhpbmsgdGhpcyBz dGFydHVwIGlzc3VlIGRvZXNuJ3QgbGlrZSB0aGUgcHJlLWZldGNoICANCj4+IHdoaWNoIGlzDQo+ PiBvZiBjb3Vyc2Ugc3RpbGwgdmFsdWFibGUgdG8gaW1wcm92ZSBwbGF5YmFjay4gSU1PLCBpdCBp cyBoYXJkIHRvICANCj4+IHByZWRpY3QNCj4+IHdoaWNoIGNoYW5uZWwgdGhlIHVzZXIgd2lsbCBz d2l0Y2ggdG8gaW4gdGhlIG5leHQgbW9tZW50LCBoZW5jZSBpdCAgDQo+PiBpcyBub3QNCj4+IHJl YXNvbmFibGUgdG8gcmVxdWVzdCBpbXBvcnRhbnQgcGFja2V0cyBmb3Igb3RoZXIgY2hhbm5lbHMu IERpZCBJDQo+PiBtaXN1bmRlcnN0YW5kIHlvdT8NCj4gDQo+IFtUXQ0KPiBJIHdvdWxkIG5vdCBi ZSB3b3JyaWVkIHRvIGhhdmUgdGhlIE1QRCBhbmQgdGhlIGluaXRpYWxpemF0aW9uIHNlZ21lbnQg IA0KPiBvZiB0aGUgdHdvIG5laWdoYm9yaW5nIGNoYW5uZWxzIHJlYWR5IGluIG15IGRldmljZS4g QWdhaW4sIHRoZSBjbGllbnQgIA0KPiBjYW4gYmUgdmVyeSBzbWFydCwgZXNwZWNpYWxseSBhcyBp dCBkb2VzIGhhdmUgYWNjZXNzIHRvIGFsbCB0aGUgIA0KPiBpbmZvcm1hdGlvbi4NCj4gDQo+IElu IGdlbmVyYWwsIEkgZG8gbm90IGRpc2FncmVlIHRoYXQgd2UgY2FuIGNyZWF0ZSBtb3JlIGRldGFp bGVkIHVzZSAgDQo+IGNhc2VzIGZvciBlbnZpcm9ubWVudHMgaW4gd2hpY2ggd2UgZW52aXNpb24g dGhhdCBIVFRQIHN0cmVhbWluZyB3aWxsICANCj4gYmUgdXNlZC4gVGhpcyBtYXkgaW5jbHVkZSBs aXZlIG11bHRpLWNoYW5uZWwgZW52aXJvbm1lbnRzLiBIb3dldmVyLCB3ZSAgDQo+IHNob3VsZCBu b3QgY29uY2x1ZGUgcGVyIHNlIHRoYXQgdGhlIGV4aXN0aW5nIHRlY2hub2xvZ2llcyBkbyBoYXZl IGEgIA0KPiBwcm9ibGVtLg0KPiBbXFRdDQo+IA0KPj4gLSAzR1BQIGRlZmluZXMgUW9FIG1ldHJp Y3MgdGhhdCBjYW4gcmV1c2VkIGFsc28gZm9yIEhUVFAgU3RyZWFtaW5nLg0KPj4gdGhlcmUgd2ls bCBhbHNvIGJlIGVmZm9ydHMgaW4gTVBFRyBpbiBpbmNsdWRpbmcgUW9FLg0KPj4gW1pOXTogSSBh bSBub3QgcHJvcG9zaW5nIHRvIGZvY3VzIG9uIGRlZmluaW5nIFFvRSBtZXRyaWNzLCBidXQgIA0K Pj4gbG9va2luZyBvbg0KPj4gdGhlIHByb3RvY29scyB0byByZXBvcnQgc3VjaCBtZXRyaWNzLCBs aWtlIFJUQ1AuIFdlIHdpbGwgc3VwcG9ydCB0aGUgIA0KPj4gd29yayBpbg0KPj4gM0dQUC9NUEVH IGFuZCBjb29wZXJhdGUgd2l0aCB0aGVtIHRvIHNlZSBob3cgdG8gY2Fwc3VsYXRlIHRoZSAgDQo+ PiBtZXRyaWNzIGluIGENCj4+IHNlcmllcyBvZiBtZXNzYWdlcy4NCj4gDQo+IFtUXQ0KPiBXaGF0 IGRvIHlvdSBtZWFuIHdpdGggImNhcHN1bGF0ZSI/DQo+IEFsc28sIGNhbiB5b3UgYmUgbW9yZSBz cGVjaWZpYyB3aGF0IG1ldHJpY3MgdGhlcmUgYXJlIGluIFJUQ1AgdGhhdCBjYW4gIA0KPiBhbHNv IGJlIHVzZWQgaW4gSFRUUCBTdHJlYW1pbmcuIEkgY29uc2lkZXIgdGhhdCBhbnl0aGluZyBkZWFs aW5nIHdpdGggIA0KPiBwYWNrZXQgbG9zcyBpcyBpcnJlbGV2YW50LiBJIGFsc28gZG8gbm90IHNl ZSB0aGUgcmVsZXZhbmNlIG9mIHNlbmRpbmcgIA0KPiByZWd1bGFyIDUgc2Vjb25kcyByZWNlaXZl ciByZXBvcnRzIGFzIHRoZSBjb250ZW50IGlzIHN0YXRpYyBhbmQgIA0KPiBhZGFwdGF0aW9uIHdp bGwgbm90IGhhcHBlbi4gU29tZSByZXBvcnRpbmcgb24gTWVkaWEgUHJlc2VudGF0aW9uIGxldmVs ICANCj4gbWF5IGJlIHN1ZmZpY2llbnQsIGZvciBleGFtcGxlIHdoZW4gdGhlIHByZXNlbnRhdGlv biBoYXMgYmVlbiBjb21wbGV0ZWQuDQo+IFtcVF0NCj4gDQo+IA0KPiAtLS0NCj4gRHIuIFRob21h cyBTdG9ja2hhbW1lciAoQ0VPKSB8fCBzdG9ja2hhbW1lckBub21vci5kZSB8fCBwaG9uZSArNDkg ODkgIA0KPiA5Nzg5ODAgMDIgfHwgY2VsbCArNDkxNzI1NzAyNjY3IHx8IGh0dHA6Ly93d3cubm9t b3ItcmVzZWFyY2guY29tDQo+IE5vbW9yIFJlc2VhcmNoIEdtYkggIC0gIFNpdHogZGVyIEdlc2Vs bHNjaGFmdDogTfxuY2hlbiAtICANCj4gUmVnaXN0ZXJnZXJpY2h0OiBN/G5jaGVuLCBIUkIgMTY1 ODU2IJYgVW1zYXR6c3RldWVyLUlEOiBERTIzODA0NzYzNyAtICANCj4gR2VzY2jkZnRzZvxocmVy OiBEci4gVGhvbWFzIFN0b2NraGFtbWVyLCBEci4gSW5nbyBWaWVyaW5nLg0KPiANCj4gDQo+IA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g aHR0cHN0cmVhbWluZyBtYWlsaW5nIGxpc3QNCj4gaHR0cHN0cmVhbWluZ0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h0dHBzdHJlYW1pbmcNCj4gDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpodHRwc3Ry ZWFtaW5nIG1haWxpbmcgbGlzdA0KaHR0cHN0cmVhbWluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9odHRwc3RyZWFtaW5n From mike.severa@alcatel-lucent.com Thu Oct 28 20:59:22 2010 Return-Path: <mike.severa@alcatel-lucent.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038683A69EA for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 20:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6la+sJKxGd2 for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 20:59:20 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1B3D13A680E for <httpstreaming@ietf.org>; Thu, 28 Oct 2010 20:59:20 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o9T415I4029502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Oct 2010 23:01:05 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o9T41525028780 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 28 Oct 2010 23:01:05 -0500 Received: from USNAVSXCHMBSC2.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Thu, 28 Oct 2010 23:01:05 -0500 From: "Severa, Michael J (Mike)" <mike.severa@alcatel-lucent.com> To: Qin Wu <sunseawq@huawei.com>, Mark Watson <watsonm@netflix.com>, "httpstreaming@ietf.org" <httpstreaming@ietf.org> Date: Thu, 28 Oct 2010 22:56:41 -0500 Thread-Topic: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) Thread-Index: Act3FciKmPhbA+n6R4qRCJAhUu19tAAB4LcB Message-ID: <DDF000BCD4FA4F43909CD45448BAE04E0ACA2F13B6@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> References: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> <A0F798C3-2ECB-4150-8EC0-7A23118D057E@netflix.com>, <02a801cb7715$bcd44e80$30298a0a@china.huawei.com> In-Reply-To: <02a801cb7715$bcd44e80$30298a0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Oct 2010 03:59:22 -0000 Hi. Check out server-sent events in HTML5. Essentially what is described he= re, though intended more for the application layer than the media layer. Wi= th a decoder interface at the application layer it would probably be possib= le to do this now by using that feature.=20 Mike =20 ________________________________________ From: httpstreaming-bounces@ietf.org [httpstreaming-bounces@ietf.org] On Be= half Of Qin Wu [sunseawq@huawei.com] Sent: Thursday, October 28, 2010 8:02 PM To: Mark Watson; httpstreaming@ietf.org Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version N= otification for draft-zong-httpstreaming-gap-analysis-01) Hi, ----- Original Message ----- From: "Mark Watson" <watsonm@netflix.com> To: <httpstreaming@ietf.org> Sent: Friday, October 29, 2010 3:17 AM Subject: [httpstreaming] Efficient manifest push (Re: FW: New Version Notif= ication for draft-zong-httpstreaming-gap-analysis-01) Here is an idea sparked by Thomas' mention below of AJAX and RSS push servi= ces. In these services the client establishes a long-lived HTTP connection to a = server on which it sends a single request. The response comes back in chunk= s, over time, enabling the server to "push" new content as it becomes avail= able. Generally caches and proxies are transparent to this, although I thin= k it does not work with some older proxies which expect to receive the whol= e response from upstream before returning anything to the client. Perhaps t= hese are all gone by now. But anyway, the "chunks" cannot really be cached = as the proxy has no idea what they are. In the case of a document, such as a manifest, which is being periodically = updated, or a sequence of different files, one could very simply expose the= se semantics in a standard way, which would enable caches to do their thing= . For example, suppose we define a new MIME type, multipart/versions, where e= ach part of the multipart MIME response is a different version of the origi= nally requested resource. A smart cache receiving a request for this resour= ce can cache the "parts" as they arrive, each replacing the previously cach= ed version. It can serve multiple incoming persistent connections with one = upstream persistent connection, providing scalability. It would be transpar= ent to existing caches. Clients would indicate their support in the Accept = header and clients which did not support this mode would just poll the reso= urce in the usual way with conditional GET requests. All that would be required from a standards perspective would be definition= of the multipart/versions MIME type. Maybe this is not new. I could easily imagine CDNs do this kind of thing in= ternally already. Similarly, one could imagine a multipart/sequence MIME type where the parts= form a sequence of objects. The client requests an object and (if it indic= ates support of the multipart/sequence MIME type) gets back that object and= subsequent ones in the sequence (with their file names). Again, smart cach= es could optimise for scalability, caching the parts as separate objects. T= his could help with delivery of segments in the live case, but again mainta= ining backwards-compatibility. Again, perhaps CDNs already do something lik= e this internally. I'm not proposing to progress these ideas, just thought they were interesti= ng. [Qin]: Sounds like a good idea to me. I think this is one way to build the = interoperable solution for concurrent live streaming viewing with backwards= compability to existing cache and client, which may bring the advantage of= alleviating server load. But I am not sure the MIME subtype has the right= semantic to do this. We may need some new MIME subtype and new behaviors o= n how to process it. ...Mark On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote: > Ning, > > thanks .... > > I recognized that you only replied to some of my comments. > Does this mean that you agree/disagree with the remaining ones? > > Inline some more with [T] ... [\T] > > Thomas > >> - I am not sure I understand the term "is encrypted into files" >> [ZN]: I mean "use file with media container" here. > > [T] I do not understand this either! [\T] > >> - What do you mean "normal text file"? >> [ZN]: traditional web page (e.g. html file). > > [T] we should be much more careful with terminology [\T] > >> - The intelligence in the Adaptive Streaming over HTTP is almost >> exclusively in the client, there is no negotiation >> [ZN]: Sorry for confusion, "negotiation" should be "massage exchange". > > [T] > First I hope this is a typo, otherwise I get more curious ...! > Secondly, I am still not clear what needs to be done beyond regular > http connections > [\T] > >> 5.2) >> - It is not correct that the 3GPP MPD needs to be updated even for >> live. If you use a template mode, the MPD stays static until some >> "unforeseen" event occurs. Client and Content Preparation have agreed >> on rules to construct URIs. >> - If necessary, the MPD update happens asynchronously to the media >> decoding, so this is not considered to be a problem. >> [ZN]: I didn't intend to state that pull model doesn't work. My >> point is, >> why not investigating the possible usage of push model in certain >> cases >> without experiencing the above mentioned "unforeseen" event or >> asynchronous >> updates? > > [T] > "Push" is a very very broad term. In Web applications you can for > example use AJAX or RSS/ATOM like techniques for push-like updates. If > you use conditional GET for regular polling, this is very efficient. > The MPD updates in 3GPP work in a similar manner. If you use polling, > conditional GETs and templates, you are extremely efficient. We should > really understand what we mean by push model? HTTP-based delivery is > rich and provides many successfully deployed options. > > Should you really refer to something completely different such as IP > multicast, then I would feel very very uncomfortable. > [\T] > >> - There is for sure mechanisms to deliver important packets more >> reliably in HTTP - you just request it earlier. In anticipation of >> switching a smart client may also prepare such data. The client is >> intelligent. >> [ZN]: Well, I think this startup issue doesn't like the pre-fetch >> which is >> of course still valuable to improve playback. IMO, it is hard to >> predict >> which channel the user will switch to in the next moment, hence it >> is not >> reasonable to request important packets for other channels. Did I >> misunderstand you? > > [T] > I would not be worried to have the MPD and the initialization segment > of the two neighboring channels ready in my device. Again, the client > can be very smart, especially as it does have access to all the > information. > > In general, I do not disagree that we can create more detailed use > cases for environments in which we envision that HTTP streaming will > be used. This may include live multi-channel environments. However, we > should not conclude per se that the existing technologies do have a > problem. > [\T] > >> - 3GPP defines QoE metrics that can reused also for HTTP Streaming. >> there will also be efforts in MPEG in including QoE. >> [ZN]: I am not proposing to focus on defining QoE metrics, but >> looking on >> the protocols to report such metrics, like RTCP. We will support the >> work in >> 3GPP/MPEG and cooperate with them to see how to capsulate the >> metrics in a >> series of messages. > > [T] > What do you mean with "capsulate"? > Also, can you be more specific what metrics there are in RTCP that can > also be used in HTTP Streaming. I consider that anything dealing with > packet loss is irrelevant. I also do not see the relevance of sending > regular 5 seconds receiver reports as the content is static and > adaptation will not happen. Some reporting on Media Presentation level > may be sufficient, for example when the presentation has been completed. > [\T] > > > --- > Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 > 978980 02 || cell +491725702667 || http://www.nomor-research.com > Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - > Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 - > Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. > > > > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From watsonm@netflix.com Thu Oct 28 21:28:16 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10333A680E for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 21:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.405 X-Spam-Level: X-Spam-Status: No, score=-3.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 622SY9sVNZX3 for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 21:28:15 -0700 (PDT) Received: from mx1.netflix.com (mx1.netflix.com [208.75.77.144]) by core3.amsl.com (Postfix) with ESMTP id 4699D3A67FE for <httpstreaming@ietf.org>; Thu, 28 Oct 2010 21:28:15 -0700 (PDT) Received: from ExchFE102.netflix.com (exchfe102.netflix.com [10.64.32.102]) by mx1.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o9T4U4GI013691; Thu, 28 Oct 2010 21:30:04 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE102.netflix.com ([fe80::416e:22e0:ebdf:14b0%14]) with mapi; Thu, 28 Oct 2010 21:30:03 -0700 From: Mark Watson <watsonm@netflix.com> To: Qin Wu <sunseawq@huawei.com> Date: Thu, 28 Oct 2010 21:30:01 -0700 Thread-Topic: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) Thread-Index: Act3IfRYMAcdUEZDRx2C/nOx6pelAA== Message-ID: <1476B391-7FEF-453C-8351-DEC536B2FCD7@netflix.com> References: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> <A0F798C3-2ECB-4150-8EC0-7A23118D057E@netflix.com> <02a801cb7715$bcd44e80$30298a0a@china.huawei.com> In-Reply-To: <02a801cb7715$bcd44e80$30298a0a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Oct 2010 04:28:17 -0000 On Oct 28, 2010, at 8:02 PM, Qin Wu wrote: >=20 > [Qin]: Sounds like a good idea to me. I think this is one way to build th= e interoperable solution for concurrent live streaming viewing with backwar= ds compability to existing cache and client, which may bring the advantage = of alleviating server load. But I am not sure the MIME subtype has the rig= ht semantic to do this. [MW] Can you elaborate ? > We may need some new MIME subtype and new behaviors on how to process it. >=20 > ...Mark >=20 >=20 >=20 >=20 > On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote: >=20 >> Ning, >>=20 >> thanks .... >>=20 >> I recognized that you only replied to some of my comments. >> Does this mean that you agree/disagree with the remaining ones? >>=20 >> Inline some more with [T] ... [\T] >>=20 >> Thomas >>=20 >>> - I am not sure I understand the term "is encrypted into files" >>> [ZN]: I mean "use file with media container" here. >>=20 >> [T] I do not understand this either! [\T] >>=20 >>> - What do you mean "normal text file"? >>> [ZN]: traditional web page (e.g. html file). >>=20 >> [T] we should be much more careful with terminology [\T] >>=20 >>> - The intelligence in the Adaptive Streaming over HTTP is almost >>> exclusively in the client, there is no negotiation >>> [ZN]: Sorry for confusion, "negotiation" should be "massage exchange". >>=20 >> [T] >> First I hope this is a typo, otherwise I get more curious ...! >> Secondly, I am still not clear what needs to be done beyond regular =20 >> http connections >> [\T] >>=20 >>> 5.2) >>> - It is not correct that the 3GPP MPD needs to be updated even for >>> live. If you use a template mode, the MPD stays static until some >>> "unforeseen" event occurs. Client and Content Preparation have agreed >>> on rules to construct URIs. >>> - If necessary, the MPD update happens asynchronously to the media >>> decoding, so this is not considered to be a problem. >>> [ZN]: I didn't intend to state that pull model doesn't work. My =20 >>> point is, >>> why not investigating the possible usage of push model in certain =20 >>> cases >>> without experiencing the above mentioned "unforeseen" event or =20 >>> asynchronous >>> updates? >>=20 >> [T] >> "Push" is a very very broad term. In Web applications you can for =20 >> example use AJAX or RSS/ATOM like techniques for push-like updates. If = =20 >> you use conditional GET for regular polling, this is very efficient. =20 >> The MPD updates in 3GPP work in a similar manner. If you use polling, =20 >> conditional GETs and templates, you are extremely efficient. We should = =20 >> really understand what we mean by push model? HTTP-based delivery is =20 >> rich and provides many successfully deployed options. >>=20 >> Should you really refer to something completely different such as IP =20 >> multicast, then I would feel very very uncomfortable. >> [\T] >>=20 >>> - There is for sure mechanisms to deliver important packets more >>> reliably in HTTP - you just request it earlier. In anticipation of >>> switching a smart client may also prepare such data. The client is >>> intelligent. >>> [ZN]: Well, I think this startup issue doesn't like the pre-fetch =20 >>> which is >>> of course still valuable to improve playback. IMO, it is hard to =20 >>> predict >>> which channel the user will switch to in the next moment, hence it =20 >>> is not >>> reasonable to request important packets for other channels. Did I >>> misunderstand you? >>=20 >> [T] >> I would not be worried to have the MPD and the initialization segment =20 >> of the two neighboring channels ready in my device. Again, the client =20 >> can be very smart, especially as it does have access to all the =20 >> information. >>=20 >> In general, I do not disagree that we can create more detailed use =20 >> cases for environments in which we envision that HTTP streaming will =20 >> be used. This may include live multi-channel environments. However, we = =20 >> should not conclude per se that the existing technologies do have a =20 >> problem. >> [\T] >>=20 >>> - 3GPP defines QoE metrics that can reused also for HTTP Streaming. >>> there will also be efforts in MPEG in including QoE. >>> [ZN]: I am not proposing to focus on defining QoE metrics, but =20 >>> looking on >>> the protocols to report such metrics, like RTCP. We will support the =20 >>> work in >>> 3GPP/MPEG and cooperate with them to see how to capsulate the =20 >>> metrics in a >>> series of messages. >>=20 >> [T] >> What do you mean with "capsulate"? >> Also, can you be more specific what metrics there are in RTCP that can = =20 >> also be used in HTTP Streaming. I consider that anything dealing with =20 >> packet loss is irrelevant. I also do not see the relevance of sending =20 >> regular 5 seconds receiver reports as the content is static and =20 >> adaptation will not happen. Some reporting on Media Presentation level = =20 >> may be sufficient, for example when the presentation has been completed. >> [\T] >>=20 >>=20 >> --- >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 =20 >> 978980 02 || cell +491725702667 || http://www.nomor-research.com >> Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - =20 >> Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - =20 >> Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >>=20 >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From watsonm@netflix.com Thu Oct 28 21:30:35 2010 Return-Path: <watsonm@netflix.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 831803A6820 for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 21:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcYCH8jRqcGM for <httpstreaming@core3.amsl.com>; Thu, 28 Oct 2010 21:30:33 -0700 (PDT) Received: from mx2.netflix.com (mx2.netflix.com [208.75.77.145]) by core3.amsl.com (Postfix) with ESMTP id DB8F93A67FF for <httpstreaming@ietf.org>; Thu, 28 Oct 2010 21:30:33 -0700 (PDT) Received: from ExchFE101.netflix.com (exchfe101.netflix.com [10.64.32.101]) by mx2.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id o9T4WNqH032372; Thu, 28 Oct 2010 21:32:23 -0700 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE101.netflix.com ([fe80::6861:6a26:831f:e8c9%14]) with mapi; Thu, 28 Oct 2010 21:32:22 -0700 From: Mark Watson <watsonm@netflix.com> To: "Severa, Michael J (Mike)" <mike.severa@alcatel-lucent.com> Date: Thu, 28 Oct 2010 21:32:20 -0700 Thread-Topic: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) Thread-Index: Act3IkbpB/Ev9wYwRpSHrmqv2W7zVA== Message-ID: <3528929E-378A-4551-AEAB-B02431712F12@netflix.com> References: <007201cb7664$ffb832e0$3a298a0a@china.huawei.com> <F30F9206-7BE4-4A76-B2B4-91B0EE32FD62@nomor.de> <A0F798C3-2ECB-4150-8EC0-7A23118D057E@netflix.com>, <02a801cb7715$bcd44e80$30298a0a@china.huawei.com> <DDF000BCD4FA4F43909CD45448BAE04E0ACA2F13B6@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> In-Reply-To: <DDF000BCD4FA4F43909CD45448BAE04E0ACA2F13B6@USNAVSXCHMBSC2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "httpstreaming@ietf.org" <httpstreaming@ietf.org> Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version Notification for draft-zong-httpstreaming-gap-analysis-01) X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Oct 2010 04:30:35 -0000 Server-sent events defines a stream format for a sequence of DOM events. Es= sentially each is a set of name/value pairs. It's a very simple text syntax= . Not really suitable for manifest updates or video stream segments. But ma= inly it does not carry any semantics that would enable cache optimizations. ...Mark On Oct 28, 2010, at 8:56 PM, Severa, Michael J (Mike) wrote: > Hi. Check out server-sent events in HTML5. Essentially what is described = here, though intended more for the application layer than the media layer. = With a decoder interface at the application layer it would probably be poss= ible to do this now by using that feature.=20 >=20 > Mike =20 > ________________________________________ > From: httpstreaming-bounces@ietf.org [httpstreaming-bounces@ietf.org] On = Behalf Of Qin Wu [sunseawq@huawei.com] > Sent: Thursday, October 28, 2010 8:02 PM > To: Mark Watson; httpstreaming@ietf.org > Subject: Re: [httpstreaming] Efficient manifest push (Re: FW: New Version= Notification for draft-zong-httpstreaming-gap-analysis-01) >=20 > Hi, > ----- Original Message ----- > From: "Mark Watson" <watsonm@netflix.com> > To: <httpstreaming@ietf.org> > Sent: Friday, October 29, 2010 3:17 AM > Subject: [httpstreaming] Efficient manifest push (Re: FW: New Version Not= ification for draft-zong-httpstreaming-gap-analysis-01) >=20 >=20 > Here is an idea sparked by Thomas' mention below of AJAX and RSS push ser= vices. >=20 > In these services the client establishes a long-lived HTTP connection to = a server on which it sends a single request. The response comes back in chu= nks, over time, enabling the server to "push" new content as it becomes ava= ilable. Generally caches and proxies are transparent to this, although I th= ink it does not work with some older proxies which expect to receive the wh= ole response from upstream before returning anything to the client. Perhaps= these are all gone by now. But anyway, the "chunks" cannot really be cache= d as the proxy has no idea what they are. >=20 > In the case of a document, such as a manifest, which is being periodicall= y updated, or a sequence of different files, one could very simply expose t= hese semantics in a standard way, which would enable caches to do their thi= ng. >=20 > For example, suppose we define a new MIME type, multipart/versions, where= each part of the multipart MIME response is a different version of the ori= ginally requested resource. A smart cache receiving a request for this reso= urce can cache the "parts" as they arrive, each replacing the previously ca= ched version. It can serve multiple incoming persistent connections with on= e upstream persistent connection, providing scalability. It would be transp= arent to existing caches. Clients would indicate their support in the Accep= t header and clients which did not support this mode would just poll the re= source in the usual way with conditional GET requests. >=20 > All that would be required from a standards perspective would be definiti= on of the multipart/versions MIME type. >=20 > Maybe this is not new. I could easily imagine CDNs do this kind of thing = internally already. >=20 > Similarly, one could imagine a multipart/sequence MIME type where the par= ts form a sequence of objects. The client requests an object and (if it ind= icates support of the multipart/sequence MIME type) gets back that object a= nd subsequent ones in the sequence (with their file names). Again, smart ca= ches could optimise for scalability, caching the parts as separate objects.= This could help with delivery of segments in the live case, but again main= taining backwards-compatibility. Again, perhaps CDNs already do something l= ike this internally. >=20 > I'm not proposing to progress these ideas, just thought they were interes= ting. >=20 > [Qin]: Sounds like a good idea to me. I think this is one way to build th= e interoperable solution for concurrent live streaming viewing with backwar= ds compability to existing cache and client, which may bring the advantage = of alleviating server load. But I am not sure the MIME subtype has the rig= ht semantic to do this. We may need some new MIME subtype and new behaviors= on how to process it. >=20 > ...Mark >=20 >=20 >=20 >=20 > On Oct 27, 2010, at 11:51 PM, Thomas Stockhammer wrote: >=20 >> Ning, >>=20 >> thanks .... >>=20 >> I recognized that you only replied to some of my comments. >> Does this mean that you agree/disagree with the remaining ones? >>=20 >> Inline some more with [T] ... [\T] >>=20 >> Thomas >>=20 >>> - I am not sure I understand the term "is encrypted into files" >>> [ZN]: I mean "use file with media container" here. >>=20 >> [T] I do not understand this either! [\T] >>=20 >>> - What do you mean "normal text file"? >>> [ZN]: traditional web page (e.g. html file). >>=20 >> [T] we should be much more careful with terminology [\T] >>=20 >>> - The intelligence in the Adaptive Streaming over HTTP is almost >>> exclusively in the client, there is no negotiation >>> [ZN]: Sorry for confusion, "negotiation" should be "massage exchange". >>=20 >> [T] >> First I hope this is a typo, otherwise I get more curious ...! >> Secondly, I am still not clear what needs to be done beyond regular >> http connections >> [\T] >>=20 >>> 5.2) >>> - It is not correct that the 3GPP MPD needs to be updated even for >>> live. If you use a template mode, the MPD stays static until some >>> "unforeseen" event occurs. Client and Content Preparation have agreed >>> on rules to construct URIs. >>> - If necessary, the MPD update happens asynchronously to the media >>> decoding, so this is not considered to be a problem. >>> [ZN]: I didn't intend to state that pull model doesn't work. My >>> point is, >>> why not investigating the possible usage of push model in certain >>> cases >>> without experiencing the above mentioned "unforeseen" event or >>> asynchronous >>> updates? >>=20 >> [T] >> "Push" is a very very broad term. In Web applications you can for >> example use AJAX or RSS/ATOM like techniques for push-like updates. If >> you use conditional GET for regular polling, this is very efficient. >> The MPD updates in 3GPP work in a similar manner. If you use polling, >> conditional GETs and templates, you are extremely efficient. We should >> really understand what we mean by push model? HTTP-based delivery is >> rich and provides many successfully deployed options. >>=20 >> Should you really refer to something completely different such as IP >> multicast, then I would feel very very uncomfortable. >> [\T] >>=20 >>> - There is for sure mechanisms to deliver important packets more >>> reliably in HTTP - you just request it earlier. In anticipation of >>> switching a smart client may also prepare such data. The client is >>> intelligent. >>> [ZN]: Well, I think this startup issue doesn't like the pre-fetch >>> which is >>> of course still valuable to improve playback. IMO, it is hard to >>> predict >>> which channel the user will switch to in the next moment, hence it >>> is not >>> reasonable to request important packets for other channels. Did I >>> misunderstand you? >>=20 >> [T] >> I would not be worried to have the MPD and the initialization segment >> of the two neighboring channels ready in my device. Again, the client >> can be very smart, especially as it does have access to all the >> information. >>=20 >> In general, I do not disagree that we can create more detailed use >> cases for environments in which we envision that HTTP streaming will >> be used. This may include live multi-channel environments. However, we >> should not conclude per se that the existing technologies do have a >> problem. >> [\T] >>=20 >>> - 3GPP defines QoE metrics that can reused also for HTTP Streaming. >>> there will also be efforts in MPEG in including QoE. >>> [ZN]: I am not proposing to focus on defining QoE metrics, but >>> looking on >>> the protocols to report such metrics, like RTCP. We will support the >>> work in >>> 3GPP/MPEG and cooperate with them to see how to capsulate the >>> metrics in a >>> series of messages. >>=20 >> [T] >> What do you mean with "capsulate"? >> Also, can you be more specific what metrics there are in RTCP that can >> also be used in HTTP Streaming. I consider that anything dealing with >> packet loss is irrelevant. I also do not see the relevance of sending >> regular 5 seconds receiver reports as the content is static and >> adaptation will not happen. Some reporting on Media Presentation level >> may be sufficient, for example when the presentation has been completed. >> [\T] >>=20 >>=20 >> --- >> Dr. Thomas Stockhammer (CEO) || stockhammer@nomor.de || phone +49 89 >> 978980 02 || cell +491725702667 || http://www.nomor-research.com >> Nomor Research GmbH - Sitz der Gesellschaft: M=FCnchen - >> Registergericht: M=FCnchen, HRB 165856 =96 Umsatzsteuer-ID: DE238047637 = - >> Gesch=E4ftsf=FChrer: Dr. Thomas Stockhammer, Dr. Ingo Viering. >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >>=20 >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From Even.roni@huawei.com Fri Oct 29 14:32:51 2010 Return-Path: <Even.roni@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CB533A67FD for <httpstreaming@core3.amsl.com>; Fri, 29 Oct 2010 14:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.096 X-Spam-Level: X-Spam-Status: No, score=-100.096 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LyA170LhwrA for <httpstreaming@core3.amsl.com>; Fri, 29 Oct 2010 14:32:49 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 745393A67A8 for <httpstreaming@ietf.org>; Fri, 29 Oct 2010 14:32:49 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB20020KMLMUW@szxga05-in.huawei.com> for httpstreaming@ietf.org; Sat, 30 Oct 2010 05:34:34 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB200ERNMLL5L@szxga05-in.huawei.com> for httpstreaming@ietf.org; Sat, 30 Oct 2010 05:34:34 +0800 (CST) Received: from windows8d787f9 ([109.66.6.220]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB200FAKMLC6M@szxml02-in.huawei.com> for httpstreaming@ietf.org; Sat, 30 Oct 2010 05:34:33 +0800 (CST) Date: Fri, 29 Oct 2010 23:33:54 +0200 From: Roni Even <Even.roni@huawei.com> To: httpstreaming@ietf.org Message-id: <082201cb77b1$024600d0$06d20270$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_FbGPz2X7CsGjxqDQV3cWbg)" Content-language: en-us Thread-index: Act3io8Wa2HDgOhCTU+tq90El+kLIQAJl0mw Subject: [httpstreaming] FW: [AVT] MPEG liaison statements received X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 29 Oct 2010 21:32:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_FbGPz2X7CsGjxqDQV3cWbg) Content-type: multipart/alternative; boundary="Boundary_(ID_0Nuj7t6IgbqJYqJfn3Jm5Q)" --Boundary_(ID_0Nuj7t6IgbqJYqJfn3Jm5Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT fyi From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: Friday, October 29, 2010 6:58 PM To: rai@ietf.org; fecframe@ietf.org; rmt@ietf.org; avt@ietf.org; mmusic@ietf.org Cc: ietfdbh@comcast.net; lars.eggert@nokia.com Subject: [AVT] MPEG liaison statements received Hi all, The IETF has received from MPEG two liaison statements for our information. No actions from the IETF side are requested or required. Both statements will appear shortly on the IETF's liaison website https://datatracker.ietf.org/liaison/ n11632 informs us that their http streaming project has reached the Committee Draft" (CD) approval level. n11633 informs us that the joint IPTV project with the ITU Q13/16 has also reached CD level. Some of you may remember those assorted IPTV workshops of the ITU and MPEG in 2008 and 2009; this is the outcome of the project started back then. In contrast to n11632, n11633 contains the CD text of four future standards in winword format. For those unaware of ISO's approval process, a CD is the first step in a five (?) step approval process that ultimately ends in an International Standard (IS). At CD level, the key architectural design decisions are frozen, but other technical input is still possible. In IETF terms, it's probably a maturity level that a WG I-D has after a couple of iterations. Regards, Stephan --Boundary_(ID_0Nuj7t6IgbqJYqJfn3Jm5Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" = xmlns:a=3D"urn:schemas-microsoft-com:office:access" = xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" = xmlns:s=3D"uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" = xmlns:rs=3D"urn:schemas-microsoft-com:rowset" xmlns:z=3D"#RowsetSchema" = xmlns:b=3D"urn:schemas-microsoft-com:office:publisher" = xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadsheet" = xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" = xmlns:odc=3D"urn:schemas-microsoft-com:office:odc" = xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" = xmlns:html=3D"http://www.w3.org/TR/REC-html40" = xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" = xmlns:rtc=3D"http://microsoft.com/officenet/conferencing" = xmlns:D=3D"DAV:" xmlns:Repl=3D"http://schemas.microsoft.com/repl/" = xmlns:mt=3D"http://schemas.microsoft.com/sharepoint/soap/meetings/" = xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2003/xml" = xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" = xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" = xmlns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" = xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#" = xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint/dsp" = xmlns:udc=3D"http://schemas.microsoft.com/data/udc" = xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" = xmlns:sub=3D"http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/"= xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#" = xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" = xmlns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" = xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" = xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/soap" = xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" = xmlns:udcp2p=3D"http://schemas.microsoft.com/data/udc/parttopart" = xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" = xmlns:dsss=3D"http://schemas.microsoft.com/office/2006/digsig-setup" = xmlns:dssi=3D"http://schemas.microsoft.com/office/2006/digsig" = xmlns:mdssi=3D"http://schemas.openxmlformats.org/package/2006/digital-sig= nature" = xmlns:mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006= " xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relationshi= ps" xmlns:spwp=3D"http://microsoft.com/sharepoint/webpartpages" = xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/types"= = xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/messag= es" = xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/= " = xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortalServer/Pub= lishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" = xmlns:st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.WordSection1 {page:WordSection1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dpurple style=3D'word-wrap: = break-word; -webkit-nbsp-mode: space;-webkit-line-break: after-white-space'> <div class=3DWordSection1> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>fyi<o:p></o:p></span></p> <p class=3DMsoNormal><span = style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'><o:p> </o:p></span></p> <div> <div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0in 0in 0in'> <p class=3DMsoNormal><b><span = style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span>= </b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] <b>On Behalf Of = </b>Stephan Wenger<br> <b>Sent:</b> Friday, October 29, 2010 6:58 PM<br> <b>To:</b> rai@ietf.org; fecframe@ietf.org; rmt@ietf.org; avt@ietf.org; mmusic@ietf.org<br> <b>Cc:</b> ietfdbh@comcast.net; lars.eggert@nokia.com<br> <b>Subject:</b> [AVT] MPEG liaison statements = received<o:p></o:p></span></p> </div> </div> <p class=3DMsoNormal><o:p> </o:p></p> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'>Hi all,<o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'><o:p> </o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'>The IETF has received from MPEG two liaison statements for = our information.  No actions from the IETF side are requested or = required.  Both statements will appear shortly on the IETF's liaison = website <a href=3D"https://datatracker.ietf.org/liaison">https://datatracker.ietf.or= g/liaison</a>/<o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'><o:p> </o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'>n11632 informs us that their http streaming project has = reached the Committee Draft" (CD) approval level. =  <o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'><o:p> </o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'>n11633 informs us that the joint IPTV project with the ITU = Q13/16 has also reached CD level.  Some of you may remember those assorted = IPTV workshops of the ITU and MPEG in 2008 and 2009; this is the outcome of = the project started back then.  In contrast to n11632, n11633 contains = the CD text of four future standards in winword format.<o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'><o:p> </o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'>For those unaware of ISO's approval process, a CD is the = first step in a five (?) step approval process that ultimately ends in an International Standard (IS).  At CD level, the key architectural = design decisions are frozen, but other technical input is still possible. =  In IETF terms, it's probably a maturity level that a WG I-D has after a = couple of iterations.<o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'><o:p> </o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'>Regards,<o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'>Stephan<o:p></o:p></span></p> </div> <div> <p class=3DMsoNormal><span = style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"; color:black'><o:p> </o:p></span></p> </div> </div> </body> </html> --Boundary_(ID_0Nuj7t6IgbqJYqJfn3Jm5Q)-- --Boundary_(ID_FbGPz2X7CsGjxqDQV3cWbg) Content-type: text/plain; name=ATT02038.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT02038.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --Boundary_(ID_FbGPz2X7CsGjxqDQV3cWbg)-- From davidbryan@gmail.com Sat Oct 30 17:59:02 2010 Return-Path: <davidbryan@gmail.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844AD3A697A for <httpstreaming@core3.amsl.com>; Sat, 30 Oct 2010 17:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.729 X-Spam-Level: X-Spam-Status: No, score=-101.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qh8wIrYeDDTd for <httpstreaming@core3.amsl.com>; Sat, 30 Oct 2010 17:59:01 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 505B03A6976 for <httpstreaming@ietf.org>; Sat, 30 Oct 2010 17:59:01 -0700 (PDT) Received: by wwe15 with SMTP id 15so4494173wwe.13 for <httpstreaming@ietf.org>; Sat, 30 Oct 2010 18:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=gg+SHsKBwpTxlkW9jPzaXy/dvO+ehT2Qz979GU3uPpM=; b=YgbjEhRFYmMpD+TIr5/eaLZAX84vCHjZRz+GHdL5sLP4T9+rMkm11ql9O52HqldK30 rjtw2NqZhc2KIMt/0wySlTQXMmWU45ogqUpeEJiKYHuTBIsBECEEwTRn+hnz54ASWVtE CcH83kIxWoGe4JKVnoVz8Xo96h7RNAs1umDoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=TmuDC/DsJQPc9v2Y0TDoiVUESTNekNsgUa02dWvkgNJmTt6ry3UxwhygAqwTvPd0Dm wXlHS14kZl4BCAntP4blXrEwqMfjAE/SFjpht6H5INVzF5DXXATsnas6bVmUP4IljV5t 3orhZj115zAmXjU456ttrPT8q4v01BaHTiKmU= MIME-Version: 1.0 Received: by 10.227.127.66 with SMTP id f2mr587559wbs.81.1288486858525; Sat, 30 Oct 2010 18:00:58 -0700 (PDT) Sender: davidbryan@gmail.com Received: by 10.227.207.195 with HTTP; Sat, 30 Oct 2010 18:00:58 -0700 (PDT) In-Reply-To: <082201cb77b1$024600d0$06d20270$%roni@huawei.com> References: <Act3io8Wa2HDgOhCTU+tq90El+kLIQAJl0mw> <082201cb77b1$024600d0$06d20270$%roni@huawei.com> Date: Sat, 30 Oct 2010 21:00:58 -0400 X-Google-Sender-Auth: 7eDwy1-QaUoDpYk_wUwxPqJ9wgo Message-ID: <AANLkTimMdx6DrZwZe3L-qe-i1VPeJGP+XhUV78gt9Eu0@mail.gmail.com> From: "David A. Bryan" <dbryan@ethernot.org> To: Roni Even <Even.roni@huawei.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: httpstreaming@ietf.org Subject: Re: [httpstreaming] FW: [AVT] MPEG liaison statements received X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 31 Oct 2010 00:59:02 -0000 Thanks for relaying this, Roni, and another in this thread from the RAI lis= t... From Gary Sullivan <garysull@microsoft.com> to Stephan Wenger <stewe@stewe.org>, "rai@ietf.org" <rai@ietf.org>, "fecframe@ietf.org" <fecframe@ietf.org>, "rmt@ietf.org" <rmt@ietf.org>, "avt@ietf.org" <avt@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org> cc "ietfdbh@comcast.net" <ietfdbh@comcast.net> date Fri, Oct 29, 2010 at 2:31 PM subject Re: [RAI] MPEG liaison statements received FYI (responding to the comment about the approval process steps): If you count producing a CD ballot text as being the first step, I would say that there are basically three main steps in the current ISO/IEC approval process =96 where the other two are the production of DIS and FDIS. (For those who may have been familiar with the way things were a couple years ago, the DIS stage was previously called an FCD.) After an FDIS is produced, there are no changes (other than such things as typo fixes or rephrasing a garbled sentence or two) =96 except, of course, by issuing subsequent amendments and corrigenda. There is a ballot of an FDIS before it is considered a fully-approved standard, but the only outcome of that ballot is "Yes" or "No", not "Let's change section 7" =96 and I have personally never witnessed a "No" outcome on such a ballot. So, for practical purposes, an FDIS is the final standard. The time between issuing a CD and issuing an FDIS takes a minimum of about 9 months, but would more typically take about one year (or longer). Best regards, Gary Sullivan On Fri, Oct 29, 2010 at 5:33 PM, Roni Even <Even.roni@huawei.com> wrote: > fyi > > > > From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of > Stephan Wenger > Sent: Friday, October 29, 2010 6:58 PM > To: rai@ietf.org; fecframe@ietf.org; rmt@ietf.org; avt@ietf.org; > mmusic@ietf.org > Cc: ietfdbh@comcast.net; lars.eggert@nokia.com > Subject: [AVT] MPEG liaison statements received > > > > Hi all, > > > > The IETF has received from MPEG two liaison statements for our informatio= n. > =A0No actions from the IETF side are requested or required. =A0Both state= ments > will appear shortly on the IETF's liaison > website=A0https://datatracker.ietf.org/liaison/ > > > > n11632 informs us that their http streaming project has reached the > Committee Draft" (CD) approval level. > > > > n11633 informs us that the joint IPTV project with the ITU Q13/16 has als= o > reached CD level. =A0Some of you may remember those assorted IPTV worksho= ps of > the ITU and MPEG in 2008 and 2009; this is the outcome of the project > started back then. =A0In contrast to n11632, n11633 contains the CD text = of > four future standards in winword format. > > > > For those unaware of ISO's approval process, a CD is the first step in a > five (?) step approval process that ultimately ends in an International > Standard (IS). =A0At CD level, the key architectural design decisions are > frozen, but other technical input is still possible. =A0In IETF terms, it= 's > probably a maturity level that a WG I-D has after a couple of iterations. > > > > Regards, > > Stephan > > > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming > > From sunseawq@huawei.com Sun Oct 31 18:01:04 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB1E3A682A for <httpstreaming@core3.amsl.com>; Sun, 31 Oct 2010 18:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.125 X-Spam-Level: * X-Spam-Status: No, score=1.125 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5noujhIcBFX for <httpstreaming@core3.amsl.com>; Sun, 31 Oct 2010 18:01:04 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0CBB93A682B for <httpstreaming@ietf.org>; Sun, 31 Oct 2010 18:01:04 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB600HAGLKTZY@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 09:02:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB6004PSLKTW5@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 09:02:53 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB600HPALKTBT@szxml06-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 09:02:53 +0800 (CST) Date: Mon, 01 Nov 2010 09:02:52 +0800 From: Qin Wu <sunseawq@huawei.com> To: httpstreaming@ietf.org Message-id: <007f01cb7960$8315dae0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <002401cb70bd$344c0c00$3a298a0a@china.huawei.com> Subject: [httpstreaming] Time and location for HTTP streaming bar BoF X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 01 Nov 2010 01:01:05 -0000 Hi, experts: We have got one IESG room for our Bar BOF with the AD's kind help. Thank Alex for arranging this for us. As we voted before through Doodle, the Bar BoF is scheduled on Wednesday(10th,Nov) evening from 19:30PM to 21:00PM. If you are interested in this work or would like to contribute, please join our discussion. If you have any other suggestions, please let us know. Regards! -Qin From sunseawq@huawei.com Sun Oct 31 20:20:21 2010 Return-Path: <sunseawq@huawei.com> X-Original-To: httpstreaming@core3.amsl.com Delivered-To: httpstreaming@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497313A6881 for <httpstreaming@core3.amsl.com>; Sun, 31 Oct 2010 20:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfAWJD1o1OjV for <httpstreaming@core3.amsl.com>; Sun, 31 Oct 2010 20:20:20 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 823CD3A6877 for <httpstreaming@ietf.org>; Sun, 31 Oct 2010 20:20:20 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB600FM5RXCWX@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 11:20:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB600HDRRXBCV@szxga05-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 11:20:00 +0800 (CST) Received: from w53375 ([10.138.41.48]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LB600G0MRXB0X@szxml04-in.huawei.com> for httpstreaming@ietf.org; Mon, 01 Nov 2010 11:19:59 +0800 (CST) Date: Mon, 01 Nov 2010 11:19:58 +0800 From: Qin Wu <sunseawq@huawei.com> To: httpstreaming@ietf.org Message-id: <018801cb7973$aa4994e0$30298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: multipart/alternative; boundary="Boundary_(ID_g0Rk/isdiieu9H2P+UGBYA)" X-Priority: 3 X-MSMail-priority: Normal Subject: [httpstreaming] Meeting Agenda preparation for Bar BOF of HTTP Streaming X-BeenThere: httpstreaming@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network based HTTP Streaming discussion list <httpstreaming.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/httpstreaming> List-Post: <mailto:httpstreaming@ietf.org> List-Help: <mailto:httpstreaming-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/httpstreaming>, <mailto:httpstreaming-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 01 Nov 2010 03:20:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_g0Rk/isdiieu9H2P+UGBYA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, Folks: This is just a quick note to let you know that preparations are proceeding for HTTP Streaming Bar BOF meeting. Based on what we have on the table and some suggestions from experts on this list, we think at least three topics should be covered in the meeting agenda: a. Goal and Scope Discussion b. Use Case discussion c. Gap Analysis if you have any questions or comments, please feel free to ping the list. We will soon create meeting agenda based on your feedbacks. Regards! -Qin --Boundary_(ID_g0Rk/isdiieu9H2P+UGBYA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=gb2312" http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.6001.18928"> <STYLE></STYLE> </HEAD> <BODY bgColor=#cce8cf> <DIV><FONT face="Times New Roman">Hi, Folks:</FONT></DIV> <DIV><FONT face="Times New Roman">This is just a quick note to let you know that preparations are proceeding for </FONT></DIV> <DIV><FONT face="Times New Roman">HTTP Streaming Bar BOF meeting.</FONT></DIV> <DIV><FONT face="Times New Roman">Based on what we have on the table and some suggestions from experts on this list, we think at least three topics should be covered in the meeting agenda:</FONT></DIV> <DIV><FONT face="Times New Roman">a. Goal and Scope Discussion </FONT></DIV> <DIV><FONT face="Times New Roman">b. Use Case discussion<BR>c. Gap Analysis</FONT></DIV> <DIV><FONT face="Times New Roman">if you have any questions or comments, please feel free to ping the list. We will soon create meeting agenda based on your feedbacks.</FONT></DIV> <DIV><FONT face="Times New Roman"></FONT> </DIV> <DIV><FONT face="Times New Roman">Regards!</FONT></DIV> <DIV><FONT face="Times New Roman">-Qin</FONT></DIV></BODY></HTML> --Boundary_(ID_g0Rk/isdiieu9H2P+UGBYA)--