X-List-Received-Date: Tue, 01 Nov 2011 13:38:56 -0000 --Apple-Mail=_771F56BC-152B-4B00-B70C-F81CD93B9191 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Indeed, I suppose nothing prevents using HTTP/XML over UDP, as messages = typically fit in UDP datagrams and the methods used for requests are = POST. In the draft the transport protocol to be used for the signaling was not = specified and it is open to discussion. --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=A8=AAbal Cavaco Silva, IST-TagusPark, Office 1-5, = 2744-016 Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org=20 rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 01/11/2011, at 01:55, li.lichun1@zte.com.cn wrote: >=20 > I think XML over UDP is also a good option. >=20 > BR=20 > Lichun >=20 >=20 > ppsp-bounces@ietf.org =D0=B4=D3=DA 2011-11-01 09:21:28: >=20 > > Hi, > >=20 > > We have updated the PPSP Tracker Protocol draft, corresponding to=20 > > the merge of the former drafts from Gu and Cruz.=20 > >=20 > > This version mainly focus on the messages exchanged between peers,=20= > > but leave the encoding format into Appendix since using binary or=20 > > HTTP/XML as container is still under dispute. > >=20 > > Please let us know your comments and suggestions. > >=20 > > Thanks. > >=20 > > Jinwei > >=20 > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 > > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C231=C8=D5 19:04 > > =CA=D5=BC=FE=C8=CB: Xiajinwei > > =B3=AD=CB=CD: Xiajinwei; Yingjie Gu(yingjie); mario.nunes@inov.pt; = joao. > > silva@inov.pt; rui.cruz@ieee.org; dbryan@ethernot.org > > =D6=F7=CC=E2: New Version Notification for = draft-gu-ppsp-peer-protocol-03.txt > >=20 > > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been=20 > > successfully submitted by Jinwei Xia and posted to the IETF = repository. > >=20 > > Filename: draft-gu-ppsp-peer-protocol > > Revision: 03 > > Title: Peer Protocol > > Creation date: 2011-10-31 > > WG ID: Individual Submission > > Number of pages: 31 > >=20 > > Abstract: > > This document presents the architecture of the PPSP Peer protocol > > outlining the functional entities, message flows and message > > processing instructions, with the respective parameters. The = PPSP > > Peer Protocol proposed in this document extends the capabilities = of > > PPSP to support adaptive and scalable video and 3D video, for = Video > > On Demand (VoD) and Live video services. The protocol messages > > formal syntax and semantics, methods, and formats are presented = for > > both Binary and HTTP/XML encoded formats. > >=20 > > = =20 > >=20 > >=20 > > The IETF Secretariat > > _______________________________________________ > > ppsp mailing list > > ppsp@ietf.org > > https://www.ietf.org/mailman/listinfo/ppsp >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_771F56BC-152B-4B00-B70C-F81CD93B9191 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312

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

Best = Regards,

Chairman
IEEE Portugal Section
Av. Prof. Dr. = An=A8=AAbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 = 939 (mobile)
rui.cruz@ieee.org
rui.s.cruz@ist.utl.pt
sec.portugal@ieee.org
www.ieee-pt.org
Advancing = technology for humanity.

On 01/11/2011, at 01:55, li.lichun1@zte.com.cn = wrote:

I think XML over UDP is also a = good option.

BR
Lichun

ppsp-bounces@ietf.org =D0=B4=D3=DA= 2011-11-01 09:21:28: > Hi, > > We have updated the PPSP Tracker Protocol draft, corresponding to > the merge of the former drafts from Gu and Cruz. > > This version mainly focus on the messages exchanged between peers, > but leave the encoding format into Appendix since using binary or > HTTP/XML as container is still under dispute. > > Please let us know your comments and suggestions. > > Thanks. > > Jinwei > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C231=C8=D5 19:04 > =CA=D5=BC=FE=C8=CB: Xiajinwei > =B3=AD=CB=CD: Xiajinwei; Yingjie Gu(yingjie); mario.nunes@inov.pt; joao. > silva@inov.pt; rui.cruz@ieee.org; dbryan@ethernot.org > =D6=F7=CC=E2: New Version Notification for = draft-gu-ppsp-peer-protocol-03.txt > > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been > successfully submitted by Jinwei Xia and posted to the IETF = repository. > > Filename: draft-gu-ppsp-peer-protocol > Revision: 03 > Title: Peer Protocol > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 31 > > Abstract: > This document presents the architecture of the PPSP = Peer protocol > outlining the functional entities, message flows and message > processing instructions, with the respective = parameters. The PPSP > Peer Protocol proposed in this document extends the = capabilities of > PPSP to support adaptive and scalable video and 3D = video, for Video > On Demand (VoD) and Live video services. The = protocol messages > formal syntax and semantics, methods, and formats are presented for > both Binary and HTTP/XML encoded formats. > > = = = > > > The IETF Secretariat > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/m= ailman/listinfo/ppsp
--------------------------------------------------------
=
ZTE Information Security Notice: The information&=
nbsp;contained in this mail is solely proper=
ty of the sender's organization. This mail&n=
bsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy a=
nd are not permitted to disclose the co=
ntents of this communication to others.
=
This email and any files transmitted with&nb=
sp;it are confidential and intended solely f=
or the use of the individual or entity&=
nbsp;to whom they are addressed. If you =
;have received this email in error please&nb=
sp;notify the originator of the message. Any=
 views expressed in this message are th=
ose of the individual sender.
=
This message has been scanned for viruses&nb=
sp;and Spam by ZTE Anti-Spam system.
_______________________________________________
ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

= --Apple-Mail=_771F56BC-152B-4B00-B70C-F81CD93B9191-- From a.bakker@vu.nl Wed Nov 2 02:05:30 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C9A11E8113 for ; Wed, 2 Nov 2011 02:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcB1aOo1MrGk for ; Wed, 2 Nov 2011 02:05:29 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9F911E80D9 for ; Wed, 2 Nov 2011 02:05:28 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 2 Nov 2011 10:05:21 +0100 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 2 Nov 2011 10:05:24 +0100 Message-ID: <4EB1082F.7090205@cs.vu.nl> Date: Wed, 2 Nov 2011 10:06:55 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-gu-ppsp-peer-protocol-03=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:05:30 -0000 On 01/11/2011 02:21, Xiajinwei wrote: > Hi, > > We have updated the PPSP Tracker Protocol draft, corresponding to the merge of the former drafts from Gu and Cruz. > > This version mainly focus on the messages exchanged between peers, but leave the encoding format into Appendix since using binary or HTTP/XML as container is still under dispute. > > Please let us know your comments and suggestions. > Hi reading throught the sketch for the first time I have the following comments: * The draft is inconsistent on how the actual chunks are transported: on the one hand the draft states that data will be transported via existing media transport protocols, on the other hand it defines a GET_CHUNK request that is replied to with actual chunks. * Assuming existing media transports, I have some reservations about this design. It will mean that peers have to establish another communication path (e.g. HTTP connection) in addition to the signalling path. This means going through NAT firewall traversal procedures another time, and double resource usage (sockets+buffers). The former won't help in achieving a fast time-till-playback. * When HTTP is used this may lead to 4 HTTP connections between every 2 peers. One for signalling from A to B, one for data from A to B, one for signalling from B to A and one for data from B to A. These connections must also be established in the right direction, i.e., the client party must initiate the TCP connection. Assuming that peers should be contributing data to eachother as much as possible, having 4 connections will/should be a very common scenario. * The protocol currently is fully pull-based. I have reservations whether this will result in low latency for live streaming and VOD time-till-playback. The authors should explain how they do achieve low latency. The protocol also needs optimization, in Figure 2 a number of synchronous requests are on the critical path for playback-start that need not be there. * In addition, the protocol has only limited support for multiplexing and/or reducing communication round-trips. Ideally, peer A should be able to send its chunkmap to peer B on a GET_CHUNKMAP message. In the current sketch peer B has to send its own GET_CHUNKMAP. The binary encoding allows for multiplexing of multiple requests *or* replies into a single datagram, but not of requests *and* responses. The HTTP encoding doesn't cater for multiplexing at all. * The sketch is incomplete in many ways. There are several TODOs and TBDs, some of which could be easily resolved, e.g. the transport negotation part can be written down precisely with RTP and HTTP as transport protocols. Also critical security components such as content integrity protection should be described. * There are many technical quirks and undocumented design choices, especially in the binary encoding. For example, the encoding requires that all 8-bit data is encoded in the set of 94 ASCII printable characters. All packets starts with the key "PPSP" for reasons unknown. It allows just for IPv4 addresses (6.5-bit encoding issues apart). The swarm ID is apparently a 32-bit number. Peer IDs are 128 bits without explanation about their role and the size of their ID address space. Many fields take up much more bits than necessary, e.g. message-type (8 bits for 2 values) and message-body-length (24 bits) * As remarked before, I think HTTP is unsuited as the basis for a peer-to-peer protocol. This is even illustrated in the draft itself: the PEER_STATUS message is needed for a serving peer to tell a client peer it can no longer request data. As unsollicited communication from server to client is impossible in HTTP, this design is either impossible or requires 2 HTTP connections per pair of peers. Note this quirky design is not necesarry when simply TCP is used. I kindly request the authors to do better quality control on their documents, so we can focus on the complex design decisions and not be distracted by obvious flaws. Regards, Arno Bakker From njaal.borch@gmail.com Wed Nov 2 02:28:57 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F40911E8100 for ; Wed, 2 Nov 2011 02:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR2sp10CY7UJ for ; Wed, 2 Nov 2011 02:28:56 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 267C911E80F9 for ; Wed, 2 Nov 2011 02:28:55 -0700 (PDT) Received: by bkat8 with SMTP id t8so3628450bka.31 for ; Wed, 02 Nov 2011 02:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=J7un8X1O0z7jnLsq8zC1RmHNksjpGvJSOXyYUJ4WWxs=; b=dW2WLu7bL2E3dmJxByTM7ETLQUYUxZ54A2We8RoxpIB9T4JdKrsOPhOcc6hwCL3SlP mqTh/Bg9ZH+vW6vEykSmTFlpWryGT8Top06c+jiEkA0r0Dyou+rKO27nrTsz76VxXb/d eIJtNZtx+3px87esyOPONueofHnsWTTbFuyUg= MIME-Version: 1.0 Received: by 10.204.137.129 with SMTP id w1mr2841352bkt.73.1320226135125; Wed, 02 Nov 2011 02:28:55 -0700 (PDT) Sender: njaal.borch@gmail.com Received: by 10.205.81.201 with HTTP; Wed, 2 Nov 2011 02:28:55 -0700 (PDT) In-Reply-To: <4EB1082F.7090205@cs.vu.nl> References: <4EB1082F.7090205@cs.vu.nl> Date: Wed, 2 Nov 2011 10:28:55 +0100 X-Google-Sender-Auth: BxHVd5cytX7B_NDoIKLYHYs1HVg Message-ID: From: Njaal Borch To: arno@cs.vu.nl Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ppsp@ietf.org Subject: Re: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-gu-ppsp-peer-protocol-03=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 09:28:57 -0000 Hi, I find this proposal a study of overhead and incompleteness. It appears to fail in addressing pretty much all p2p issues, like nat traversal, incentives, flow control, integrity and efficiency and seems highly dependent on centralized services for tracking and registration. The fact that the suggested protocol does not open for proper two-way information sharing (such as states, bitmaps etc) shows that this is basically a client-server protocol with little understanding of the fact that peers in a p2p network are best treated as equals. The amount of small messages performed in a get/reply fashion is in direct conflict with short startup times and gives no other benefits over a minimal message exchange. Other suggestions, like using XML over HTTP (over UDP) is a sure way to explode both network overhead and processing time required by participating devices, and leaving data integrity to an external solution is a massive flaw - one cannot trust nodes in a p2p network, nor the links they are using. In my opinion this is a very incomplete proposal with little going for it, and even with a lot of refinement, it will still be dependent on a mass of other standards and systems, making it into a very complicated and most likely non working solution. Basically, the added benefits of utilizing this protocol over existing P2P protocols seems not only non-existing, but it rather is a proper step back from for example streaming BitTorrent (which in itself is not a particularly good protocol either). Other fundamental errors, like inflated numbers of connections required (4 vs 1) and lack of generic P2P properties are hardly easily addressed without a total rewrite of the protocol. Regards, Nj=C3=A5l --- Dr. Nj=C3=A5l Borch Northern Research Institute (NORUT) Troms=C3=B8, Norway On 2 November 2011 10:06, Arno Bakker wrote: > On 01/11/2011 02:21, Xiajinwei wrote: >> >> Hi, >> >> We have updated the PPSP Tracker Protocol draft, corresponding to the >> merge of the former drafts from Gu and Cruz. >> >> This version mainly focus on the messages exchanged between peers, but >> leave the encoding format into Appendix since using binary or HTTP/XML a= s >> container is still under dispute. >> >> Please let us know your comments and suggestions. >> > > Hi > > reading throught the sketch for the first time I have the following > comments: > > * The draft is inconsistent on how the actual chunks are transported: on = the > one hand the draft states that data will be transported via existing medi= a > transport protocols, on the other hand it defines a GET_CHUNK request tha= t > is replied to with actual chunks. > > * Assuming existing media transports, I have some reservations about this > design. It will mean that peers have to establish another communication p= ath > (e.g. HTTP connection) in addition to the signalling path. This means goi= ng > through NAT firewall traversal procedures another time, and double resour= ce > usage (sockets+buffers). The former won't help in achieving a fast > time-till-playback. > > * When HTTP is used this may lead to 4 HTTP connections between every 2 > peers. One for signalling from A to B, one for data from A to B, one for > signalling from B to A and one for data from B to A. These connections mu= st > also be established in the right direction, i.e., the client party must > initiate the TCP connection. Assuming that peers should be contributing d= ata > to eachother as much as possible, having 4 connections will/should be a v= ery > common scenario. > > * The protocol currently is fully pull-based. I have reservations whether > this will result in low latency for live streaming and VOD > time-till-playback. The authors should explain how they do achieve low > latency. The protocol also needs optimization, in Figure 2 a number of > synchronous requests are on the critical path for playback-start that nee= d > not be there. > > * In addition, the protocol has only limited support for multiplexing and= /or > reducing communication round-trips. Ideally, peer A should be able to sen= d > its chunkmap to peer B on a GET_CHUNKMAP message. In the current sketch p= eer > B has to send its own GET_CHUNKMAP. The binary encoding allows for > multiplexing of multiple requests *or* replies into a single datagram, bu= t > not of requests *and* responses. The HTTP encoding doesn't cater for > multiplexing at all. > > * The sketch is incomplete in many ways. There are several TODOs and TBDs= , > some of which could be easily resolved, e.g. the transport negotation par= t > can be written down precisely with RTP and HTTP as transport protocols. A= lso > critical security components such as content integrity protection should = be > described. > > * There are many technical quirks and undocumented design choices, > especially in the binary encoding. For example, the encoding requires > that all 8-bit data is encoded in the set of 94 ASCII printable character= s. > All packets starts with the key "PPSP" for reasons unknown. It allows jus= t > for IPv4 addresses (6.5-bit encoding issues apart). The swarm ID is > apparently a 32-bit number. Peer IDs are 128 bits without explanation abo= ut > their role and the size of their ID address space. Many fields take up mu= ch > more bits than necessary, e.g. message-type (8 bits for 2 values) and > message-body-length (24 bits) > > * As remarked before, I think HTTP is unsuited as the basis for > a peer-to-peer protocol. This is even illustrated in the draft itself: th= e > PEER_STATUS message is needed for a serving peer to tell a client peer it > can no longer request data. As unsollicited communication from server to > client is impossible in HTTP, this design is either impossible or require= s 2 > HTTP connections per pair of peers. Note this quirky design is not necesa= rry > when simply TCP is used. > > I kindly request the authors to do better quality control on their > documents, so we can focus on the complex design decisions and not be > distracted by obvious flaws. > > Regards, > =C2=A0 =C2=A0 =C2=A0Arno Bakker > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > From wes@mti-systems.com Thu Nov 3 18:00:57 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7811011E80E0 for ; Thu, 3 Nov 2011 18:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwMuSBR4-u1T for ; Thu, 3 Nov 2011 18:00:56 -0700 (PDT) Received: from omr6.networksolutionsemail.com (omr6.networksolutionsemail.com [205.178.146.56]) by ietfa.amsl.com (Postfix) with ESMTP id ED3A411E80DE for ; Thu, 3 Nov 2011 18:00:55 -0700 (PDT) Received: from cm-omr6 (mail.networksolutionsemail.com [205.178.146.50]) by omr6.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pA410qpw031626 for ; Thu, 3 Nov 2011 21:00:54 -0400 Authentication-Results: cm-omr6 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.108.31] ([174.130.108.31:33779] helo=[192.168.1.102]) by cm-omr6 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 7F/22-18059-44933BE4; Thu, 03 Nov 2011 21:00:52 -0400 Message-ID: <4EB33947.9010309@mti-systems.com> Date: Thu, 03 Nov 2011 21:00:55 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: zhangyunfei@chinamobile.com References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: stiemerling@netlab.nec.de, ppsp@ietf.org Subject: Re: [ppsp] Fw: New Version Notification for draft-ietf-ppsp-problem-statement-06.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 01:00:57 -0000 On 10/30/2011 9:13 AM, zhangyunfei@chinamobile.com wrote: > Hi folks, > We've updated the new version of PPSP problem statement draft replying all the comments in Wes' AD review.The main changes besides editorial problems are: > 1)The definition update on chunk in section2; > 2) Update of the description of how peers find the head node and how they find each other in push and hybrid mode compared to how they find the tracker in a pull-based mode in section 4; > 3)Update of the description of section 5.1 and 5.5. > Please let me know your comments and suggestions.Thanks. Hi; this is a big improvement and you pretty much addressed all my comments, but there are still a few very minor clean-ups that I think should be made before going to IETF Last Call and IESG Review. I know these seem petty and annoying since they're now just editorial comments and not at all technical, but as this is going to be the first PPSP document to go forward for publication, I think we should strive to make it as high-quality as possible. The directorate reviews and IESG reviews will be much easier to handle if we leave them less of these kinds of things to find. I hope you'll agree. The few items I noted in this version are: - I probably wasn't clear when I commented about this before, but section 9 (References) should be specifically named "Informative References". - There are two "Authors' Addresses" sections. The second one should be deleted; it looks like it's just a template. - In references, URLs should begin with "http://" - If you check idnits: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-ppsp-problem-statement-06.txt It would be good to fix the 2 "weird spacing" warnings. - I think the "missing reference" idnits comments are really just due to the lack of spaces between the reference labels and surrounding text (e.g. "foo[bar]" or "[foo]bar" is found in some places instead of "foo [bar] baz". These should be corrected by adding spaces. I'm sorry for sending this back a second time, but do think we're very close now! -- Wes Eddy MTI Systems From xiajinwei@huawei.com Thu Nov 3 18:23:10 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459C511E8102 for ; Thu, 3 Nov 2011 18:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-3.113, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XcWvjzNjv4a for ; Thu, 3 Nov 2011 18:23:09 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6AF11E80F0 for ; Thu, 3 Nov 2011 18:23:09 -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 <0LU400DZQ3UICM@szxga05-in.huawei.com> for ppsp@ietf.org; Fri, 04 Nov 2011 09:23:07 +0800 (CST) Received: from szxrg02-dlp.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 <0LU400F373UIL6@szxga05-in.huawei.com> for ppsp@ietf.org; Fri, 04 Nov 2011 09:23:06 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AET17385; Fri, 04 Nov 2011 09:23:05 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 09:22:58 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.245]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 09:22:59 +0800 Date: Fri, 04 Nov 2011 01:22:58 +0000 From: Xiajinwei In-reply-to: <4EB1082F.7090205@cs.vu.nl> X-Originating-IP: [10.138.41.52] To: "arno@cs.vu.nl" , "ppsp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?W3Bwc3BdINeqt6I6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh?= =?gb2312?Q?ft-gu-ppsp-peer-protocol-03.txt?= Thread-index: AQHMl7z9aWtcBWdsOU2XbMUCzMs7GJWXOP8QgAGO84CAAye94A== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EB1082F.7090205@cs.vu.nl> Subject: [ppsp] =?gb2312?b?tPC4tDogINeqt6I6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?gb2312?b?dGlvbiBmb3IgZHJhZnQtZ3UtcHBzcC1wZWVyLXByb3RvY29sLTAzLnR4dA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 01:23:10 -0000 Hi, Please see my answer inline. > reading throught the sketch for the first time I have the following > comments: > > * The draft is inconsistent on how the actual chunks are transported: on > the one hand the draft states that data will be transported via existing > media transport protocols, on the other hand it defines a GET_CHUNK > request that is replied to with actual chunks. > GET_CHUNK is signaling message sent by leech peer to ask sender peer to send the chunk requested by leech peer, sender peer responds GET_CHUNK with success or failure notification. If it succeed, sender peer send the concrete data (chunk) whose ID is requested in GET_CHUNK by existing media transport protocol decided by transport negotiation. > * Assuming existing media transports, I have some reservations about > this design. It will mean that peers have to establish another > communication path (e.g. HTTP connection) in addition to the signalling > path. This means going through NAT firewall traversal procedures another > time, and double resource usage (sockets+buffers). The former won't help > in achieving a fast time-till-playback. > It is a normal case that using different sessions to convey signaling and data, e.g., using SIP or RTSP to setup and control media session but using RTP to convey the media session data. > * When HTTP is used this may lead to 4 HTTP connections between every 2 > peers. One for signalling from A to B, one for data from A to B, one for > signalling from B to A and one for data from B to A. These connections > must also be established in the right direction, i.e., the client party > must initiate the TCP connection. Assuming that peers should be > contributing data to eachother as much as possible, having 4 connections > will/should be a very common scenario. > It may not be true, if A has not the chunks in which B is interested, there is not signaling HTTP connection in the direction from B to A. If B is interested in the chunks on A, the draft-ietf-hybi-thewebsocketprotocol has defined a mechanism that realize the bidirectional HTTP communication between peer ( this draft is in RFC Ed Queue), it can address your above concern. Additionally, the data transmission is out of scope, we don't mention that using HTTP as data transport protocol. > * The protocol currently is fully pull-based. I have reservations > whether this will result in low latency for live streaming and VOD > time-till-playback. The authors should explain how they do achieve low > latency. The protocol also needs optimization, in Figure 2 a number of > synchronous requests are on the critical path for playback-start that > need not be there. > The methods defined in the draft intends to provide a explicit description of information that needs to be exchanged between peers. But the methods can be combined in a single message, which can reduce the latency caused by synchronous requests. > * In addition, the protocol has only limited support for multiplexing > and/or reducing communication round-trips. Ideally, peer A should be > able to send its chunkmap to peer B on a GET_CHUNKMAP message. In the > current sketch peer B has to send its own GET_CHUNKMAP. The binary > encoding allows for multiplexing of multiple requests *or* replies into > a single datagram, but not of requests *and* responses. The HTTP > encoding doesn't cater for multiplexing at all. > See my previous response, it can also answer your next comment on multiplexing. For example, peer A can send a message with GET_CHUNKMAP with its PEER_STATUS and its CHUNKMAP within a single message. > * The sketch is incomplete in many ways. There are several TODOs and > TBDs, some of which could be easily resolved, e.g. the transport > negotation part can be written down precisely with RTP and HTTP as > transport protocols. Also critical security components such as content > integrity protection should be described. > Agree, we will complement it in next version. As for the transport protocols, we can list some candidates protocols for consideration but we need to get rough consensus on WG before we can make any precise decision. > * There are many technical quirks and undocumented design choices, > especially in the binary encoding. For example, the encoding requires > that all 8-bit data is encoded in the set of 94 ASCII printable > characters. All packets starts with the key "PPSP" for reasons unknown. > It allows just for IPv4 addresses (6.5-bit encoding issues apart). The > swarm ID is apparently a 32-bit number. Peer IDs are 128 bits without > explanation about their role and the size of their ID address space. > Many fields take up much more bits than necessary, e.g. message-type (8 > bits for 2 values) and message-body-length (24 bits) > These parts (e.g., the length of Peer ID etc) are undecided and need to be discussed with corresponding experts, that is why we leave them as TBD. > * As remarked before, I think HTTP is unsuited as the basis for > a peer-to-peer protocol. This is even illustrated in the draft itself: > the PEER_STATUS message is needed for a serving peer to tell a client > peer it can no longer request data. As unsollicited communication from > server to client is impossible in HTTP, this design is either impossible > or requires 2 HTTP connections per pair of peers. Note this quirky > design is not necesarry when simply TCP is used. > I agree the description is confusing. this message is sent from leech peer to sender peer, please refer figure 2. I will revise the description, change serving peer to leech peer, and change client to sender peer. > I kindly request the authors to do better quality control on their > documents, so we can focus on the complex design decisions and not be > distracted by obvious flaws. Thank your reminding, we will take care of it in future. Jinwei > > Regards, > Arno Bakker > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From zhangyunfei@chinamobile.com Sun Nov 6 20:19:37 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503011F0C35 for ; Sun, 6 Nov 2011 20:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.44 X-Spam-Level: X-Spam-Status: No, score=-96.44 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL1+SEN-5B4W for ; Sun, 6 Nov 2011 20:19:36 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A0B631F0C34 for ; Sun, 6 Nov 2011 20:19:36 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 25D5AE51A; Mon, 7 Nov 2011 12:19:29 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 1CF1EE4D8; Mon, 7 Nov 2011 12:19:29 +0800 (CST) Received: from ady-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011110712192696-8216 ; Mon, 7 Nov 2011 12:19:26 +0800 Date: Mon, 7 Nov 2011 12:19:27 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2011110712192768314158@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-07 12:19:26, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-07 12:19:28, Serialize complete at 2011-11-07 12:19:28 Content-Type: multipart/alternative; boundary="----=_001_NextPart036884443211_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18498.004 X-TM-AS-Result: No--14.905-7.0-31-10 X-imss-scan-details: No--14.905-7.0-31-10;No--14.905-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [ppsp] Time slot request for PPSP session in IETF 82 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 04:19:37 -0000 This is a multi-part message in MIME format. ------=_001_NextPart036884443211_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgYWxsLA0KICAgICBQUFNQIHNlc3Npb24gd2lsbCBiZSBoZWxkIG9uIFR1ZXNkYXkgbW9ybmlu ZyggTm92LiAxNSkuIEZvciB0aG9zZSB3aG8gYXJlIHdpbGxpbmcgdG8gcmVxdWVzdCB0aGUgdGlt ZSBzbG90IGZvciBwcmVzZW50YXRpb24sIHBsZWFzZSBzZW5kIHRoZSByZXF1ZXN0IHRvIE1hcnRp biBhbmQgbWUgYmVmb3JlIE5vdi4gOS4NCkFzIGRpc2N1c3NlZCBiZWZvcmUsIHdlIGFyZSBwbGFu bmluZyBmb3IgYSBQUFNQIGRlbW8gc2hvdyBhZnRlciB0aGUgUFBTUCBzZXNzaW9uLiBUaGUgYXBw bGljYXRpb24gZm9yIHRoZSBkZW1vIHNob3cgaXMgYWxzbyB3ZWxjb21lIHRvIHNlbmQgYmVmb3Jl IE5vdi4gOS4NCiAgICBMb29raW5nIGZvcndhcmQgdG8gbWVldGluZyBhbGwgb2YgeW91IGluIFRh aXBlaSBuZXh0IHdlZWsuDQoNCkJSDQpZdW5mZWkNCiAgICANCg0KDQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart036884443211_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Hi all,

PPSP session will be held on Tuesday morning= ( Nov.=20 15). For those who are willing to request the time slot for presentation, = please=20 send the request to Martin and me before Nov. 9.

As discussed before, we are planning for a PPSP demo show after the P= PSP=20 session. The application for the demo show is also welcome to send before = Nov.=20 9.

Looking forward to meeting all of you in Taipei ne= xt=20 week.

Yunfei

zhangyunfei

------=_001_NextPart036884443211_=------ From zhangyunfei@chinamobile.com Mon Nov 7 02:22:31 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8B621F8A91 for ; Mon, 7 Nov 2011 02:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.009 X-Spam-Level: X-Spam-Status: No, score=-94.009 tagged_above=-999 required=5 tests=[AWL=-2.681, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+4neLoGkOLb for ; Mon, 7 Nov 2011 02:22:30 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 41AF721F8801 for ; Mon, 7 Nov 2011 02:22:29 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 50B93E49C; Mon, 7 Nov 2011 18:22:27 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 285B7E3D1; Mon, 7 Nov 2011 18:22:27 +0800 (CST) Received: from ady-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011110718130624-151 ; Mon, 7 Nov 2011 18:13:06 +0800 Date: Mon, 7 Nov 2011 18:13:07 +0800 From: zhangyunfei To: "Wesley Eddy" References: , <4EB33947.9010309@mti-systems.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <20111107181306978157113@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-07 18:13:06, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-07 18:22:26 Content-Type: multipart/mixed; boundary="----=_001_NextPart868272284751_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18498.006 X-TM-AS-Result: No--43.456-7.0-31-10 X-imss-scan-details: No--43.456-7.0-31-10;No--43.456-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: stiemerling , ppsp Subject: [ppsp] =?gb2312?b?u9i4tDogUmU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv?= =?gb2312?b?biBmb3IgZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50?= =?gb2312?b?LTA2LnR4dA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 10:22:31 -0000 ------=_001_NextPart868272284751_=---- Content-Type: multipart/alternative; boundary="----=_002_NextPart073747700715_=----" ------=_002_NextPart073747700715_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgV2VzLA0KICAgVGhhbmtzIGZvciB5b3VyIGNhcmVmdWwgYW5kIHBhdGllbnQgQUQgcmV2aWV3 LiBJIGhhdmUgZG9uZSB0aGUgY2xlYW4tdXBzIGFjY29yZGluZyB0byB0aGUgZXJyb3JzIHlvdSBw b2ludGVkIG91dC4gSG93ZXZlciB0aGUgZHJhZnQgc3VibWlzc2lvbiBpcyBjbG9zZWQgZHVyaW5n IHRoZSBJRVRGIG1lZXRpbmcgdGltZSBhbmQgSXQgc2VlbXMgdGhhdCBJIGNhbm5vdCB1cGxvYWQg aXQgdG8gSUVURiBUU1YgYXJlYSBwcHNwIHdpa2kgcGFnZS4NCiAgIEF0dGFjaGVkIGlzIHRoZSBu ZXcgdmVyc2lvbiBvZiB0aGUgcHMgZHJhZnQuSSdsbCB1cGRhdGUgdGhpcyB0byB0aGUgSUVURiB3 ZWJzaXRlIG9uY2UgaXQncyByZS1vcGVuLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5neXVu ZmVpDQoNCreivP7Iy6O6IFdlc2xleSBFZGR5DQq3osvNyrG85KO6IDIwMTEtMTEtMDQgMDk6MDAN CsrVvP7Iy6O6IHpoYW5neXVuZmVpDQqzrcvNo7ogcHBzcDsgc3RpZW1lcmxpbmcNCtb3zOKjuiBS ZTogRnc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1wcHNwLXByb2Js ZW0tc3RhdGVtZW50LTA2LnR4dA0KT24gMTAvMzAvMjAxMSA5OjEzIEFNLCB6aGFuZ3l1bmZlaUBj aGluYW1vYmlsZS5jb20gd3JvdGU6DQo+IEhpIGZvbGtzLA0KPiAgIFdlJ3ZlIHVwZGF0ZWQgdGhl IG5ldyB2ZXJzaW9uIG9mIFBQU1AgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgcmVwbHlpbmcgYWxs IHRoZSBjb21tZW50cyBpbiBXZXMnIEFEIHJldmlldy5UaGUgbWFpbiBjaGFuZ2VzIGJlc2lkZXMg ZWRpdG9yaWFsIHByb2JsZW1zIGFyZToNCj4gMSlUaGUgZGVmaW5pdGlvbiB1cGRhdGUgb24gY2h1 bmsgaW4gc2VjdGlvbjI7DQo+IDIpIFVwZGF0ZSBvZiB0aGUgZGVzY3JpcHRpb24gb2YgaG93ICBw ZWVycyAgZmluZCAgdGhlICBoZWFkICBub2RlICBhbmQgIGhvdyAgdGhleSAgZmluZCAgZWFjaCAg b3RoZXIgaW4gcHVzaCBhbmQgaHlicmlkIG1vZGUgY29tcGFyZWQgIHRvICBob3cgIHRoZXkgIGZp bmQgIHRoZSAgdHJhY2tlciAgaW4gIGEgIHB1bGwtYmFzZWQgIG1vZGUgaW4gc2VjdGlvbiA0Ow0K PiAzKVVwZGF0ZSBvZiB0aGUgZGVzY3JpcHRpb24gb2Ygc2VjdGlvbiA1LjEgYW5kIDUuNS4NCj4g ICAgUGxlYXNlIGxldCBtZSBrbm93IHlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLlRoYW5r cy4NCg0KDQpIaTsgdGhpcyBpcyBhIGJpZyBpbXByb3ZlbWVudCBhbmQgeW91IHByZXR0eSBtdWNo IGFkZHJlc3NlZCBhbGwgbXkNCmNvbW1lbnRzLCBidXQgdGhlcmUgYXJlDQpzdGlsbCBhIGZldyB2 ZXJ5IG1pbm9yIGNsZWFuLXVwcyB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIG1hZGUgYmVmb3JlDQpn b2luZyB0byBJRVRGIExhc3QgQ2FsbA0KYW5kIElFU0cgUmV2aWV3LiAgSSBrbm93IHRoZXNlIHNl ZW0gcGV0dHkgYW5kIGFubm95aW5nIHNpbmNlIHRoZXkncmUgbm93DQpqdXN0IGVkaXRvcmlhbA0K Y29tbWVudHMgYW5kIG5vdCBhdCBhbGwgdGVjaG5pY2FsLCBidXQgYXMgdGhpcyBpcyBnb2luZyB0 byBiZSB0aGUgZmlyc3QNClBQU1AgZG9jdW1lbnQgdG8gZ28NCmZvcndhcmQgZm9yIHB1YmxpY2F0 aW9uLCBJIHRoaW5rIHdlIHNob3VsZCBzdHJpdmUgdG8gbWFrZSBpdCBhcw0KaGlnaC1xdWFsaXR5 IGFzIHBvc3NpYmxlLiAgVGhlDQpkaXJlY3RvcmF0ZSByZXZpZXdzIGFuZCBJRVNHIHJldmlld3Mg d2lsbCBiZSBtdWNoIGVhc2llciB0byBoYW5kbGUgaWYgd2UNCmxlYXZlIHRoZW0gbGVzcyBvZg0K dGhlc2Uga2luZHMgb2YgdGhpbmdzIHRvIGZpbmQuICBJIGhvcGUgeW91J2xsIGFncmVlLg0KDQpU aGUgZmV3IGl0ZW1zIEkgbm90ZWQgaW4gdGhpcyB2ZXJzaW9uIGFyZToNCg0KLSBJIHByb2JhYmx5 IHdhc24ndCBjbGVhciB3aGVuIEkgY29tbWVudGVkIGFib3V0IHRoaXMgYmVmb3JlLCBidXQNCnNl Y3Rpb24gOSAoUmVmZXJlbmNlcykNCiAgc2hvdWxkIGJlIHNwZWNpZmljYWxseSBuYW1lZCAiSW5m b3JtYXRpdmUgUmVmZXJlbmNlcyIuDQoNCi0gVGhlcmUgYXJlIHR3byAiQXV0aG9ycycgQWRkcmVz c2VzIiBzZWN0aW9ucy4gIFRoZSBzZWNvbmQgb25lIHNob3VsZCBiZQ0KZGVsZXRlZDsgaXQgbG9v a3MNCiAgbGlrZSBpdCdzIGp1c3QgYSB0ZW1wbGF0ZS4NCg0KLSBJbiByZWZlcmVuY2VzLCBVUkxz IHNob3VsZCBiZWdpbiB3aXRoICJodHRwOi8vIg0KDQotIElmIHlvdSBjaGVjayBpZG5pdHM6DQoN Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZG5pdHM/dXJsPWh0dHA6Ly90b29scy5pZXRmLm9yZy9p ZC9kcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDYudHh0DQogIEl0IHdvdWxkIGJl IGdvb2QgdG8gZml4IHRoZSAyICJ3ZWlyZCBzcGFjaW5nIiB3YXJuaW5ncy4NCg0KLSBJIHRoaW5r IHRoZSAibWlzc2luZyByZWZlcmVuY2UiIGlkbml0cyBjb21tZW50cyBhcmUgcmVhbGx5IGp1c3Qg ZHVlIHRvDQp0aGUgbGFjayBvZiBzcGFjZXMNCiAgYmV0d2VlbiB0aGUgICByZWZlcmVuY2UgbGFi ZWxzIGFuZCBzdXJyb3VuZGluZyB0ZXh0IChlLmcuICJmb29bYmFyXSINCm9yICJbZm9vXWJhciIg aXMgZm91bmQgaW4NCiAgc29tZSBwbGFjZXMgaW5zdGVhZCBvZiAiZm9vIFtiYXJdIGJheiIuICBU aGVzZSBzaG91bGQgYmUgY29ycmVjdGVkIGJ5DQphZGRpbmcgc3BhY2VzLg0KDQpJJ20gc29ycnkg Zm9yIHNlbmRpbmcgdGhpcyBiYWNrIGEgc2Vjb25kIHRpbWUsIGJ1dCBkbyB0aGluayB3ZSdyZSB2 ZXJ5DQpjbG9zZSBub3chDQoNCi0tIA0KV2VzIEVkZHkNCk1USSBTeXN0ZW1z ------=_002_NextPart073747700715_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi Wes,

Thanks for your careful and patient AD review. I=20 have done the clean-ups according to the errors you pointed out.= =20 However the draft submission is closed during the IETF meeting time and It= seems=20 that I cannot upload it to IETF TSV area ppsp wiki page.

Attached is the new version of the ps draft.I'll update = this=20 to the IETF website once it's re-open.

Yunfei

zhangyunfei

=B7=A2=BC=FE=C8=CB=A3=BA Wesley Eddy

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2011-11-04 09:00

=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei

=B3=AD=CB=CD=A3=BA ppsp<= /A>; stiemerling

=D6=F7=CC=E2=A3=BA Re: Fw: New Version Notification for=20 draft-ietf-ppsp-problem-statement-06.txt

On 10/30/2011 9:13 AM, zhangyunfei@chinamobile.co= m wrote:

> Hi folks,

> We've updated the new versi= on of PPSP problem statement draft replying&= nbsp;all the comments in Wes' AD review.The&= nbsp;main changes besides editorial problems are:=

> 1)The definition update on chunk i= n section2;

> 2) Update of the description of&nb= sp;how peers find the head&nbs= p; node and how they find= each other in push and hybrid&n= bsp;mode compared to how they &= nbsp;find the tracker in a&nbs= p; pull-based mode in section 4;

> 3)Update of the description of sec= tion 5.1 and 5.5.

> Please let me know yo= ur comments and suggestions.Thanks.

Hi; this is a big improvement and = you pretty much addressed all my

comments, but there are

still a few very minor clean-ups that&n= bsp;I think should be made before

going to IETF Last Call

and IESG Review. I know these see= m petty and annoying since they're now

just editorial

comments and not at all technical, but&= nbsp;as this is going to be the first

PPSP document to go

forward for publication, I think we sho= uld strive to make it as

high-quality as possible. The

directorate reviews and IESG reviews will&nb= sp;be much easier to handle if we

leave them less of

these kinds of things to find. I&= nbsp;hope you'll agree.

The few items I noted in this vers= ion are:

- I probably wasn't clear when I c= ommented about this before, but

section 9 (References)

should be specifically named "Informa= tive References".

- There are two "Authors' Addresses" se= ctions. The second one should be

deleted; it looks

like it's just a template.

- In references, URLs should begin with= "http://"

- If you check idnits:

http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-iet= f-ppsp-problem-statement-06.txt

It would be good to fix the= 2 "weird spacing" warnings.

- I think the "missing reference" idnit= s comments are really just due to

the lack of spaces

between the reference labels&n= bsp;and surrounding text (e.g. "foo[bar]"

or "[foo]bar" is found in

some places instead of "foo [bar= ] baz". These should be corrected by

adding spaces.

I'm sorry for sending this back a = second time, but do think we're very

close now!

Wes Eddy

MTI Systems

------=_002_NextPart073747700715_=------ ------=_001_NextPart868272284751_=---- Content-Type: application/octet-stream; name="draft-ietf-ppsp-problem-statement-07.txt" Content-Disposition: attachment; filename="draft-ietf-ppsp-problem-statement-07.txt" Content-Transfer-Encoding: base64 UFBTUCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgWS4gWmhhbmcNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ2hpbmEgTW9iaWxlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE4uWm9uZw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEh1YXdl aVRlY2gNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEcuQ2FtYXJpbGxvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFcmljc3Nvbg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKLnNlbmcNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUFBsaXZlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFIuWWFuZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBZYWxlIFVuaXZlcnNpdHkNCkludGVuZGVkIHN0 YXR1czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICBOb3ZlbWJlciA3LCAy MDExDQpFeHBpcmVzOiBNYXkgMjAxMg0KDQoNCg0KICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBv ZiBQZWVyLXRvLVBlZXIgU3RyZWFtaW5nIFByb3RvY29sIChQUFNQKQ0KICAgICAgICAgICAgICAg ICBkcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDcudHh0DQoNCg0KQWJzdHJhY3QN Cg0KICAgUGVlci10by1QZWVyKFAyUCBmb3Igc2hvcnQpIHN0cmVhbWluZyBzeXN0ZW1zIHNob3cg bW9yZSBhbmQgbW9yZQ0KICAgcG9wdWxhcml0eSBpbiBjdXJyZW50IEludGVybmV0IHdpdGggcHJv cHJpZXRhcnkgcHJvdG9jb2xzLiBUaGlzDQogICBkb2N1bWVudCBpZGVudGlmaWVzIHByb2JsZW1z IG9mIHRoZSBwcm9wcmlldGFyeSBwcm90b2NvbHMsIHByb3Bvc2VzIGENCiAgIFBlZXIgdG8gUGVl ciBTdHJlYW1pbmcgUHJvdG9jb2woUFBTUCkgaW5jbHVkaW5nIHRyYWNrZXIgYW5kIHBlZXINCiAg IHNpZ25hbGluZyBjb21wb25lbnRzLCBhbmQgZGlzY3Vzc2VzIHRoZSBzY29wZSBhbmQgdXNlcyBj YXNlcyBvZiBQUFNQLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KemhhbmcgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAgICAg ICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxlbSBTdGF0 ZW1lbnQgb2YgUFBTUCAgICAgICAgICBOb3ZlbWJlciAyMDExDQoNCg0KDQoNClN0YXR1cyBvZiB0 aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBj b25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBCQ1AgNzggYW5kIEJDUCA3OS4N Cg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJu ZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0 cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg bW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8g dXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9yIHRvIGNpdGUg dGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2Yg Y3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3 LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJu ZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDov L3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwg ZXhwaXJlIG9uIE1heSA3LCAyMDEyLg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdo dCAoYykgMjAxMSBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQ0K ICAgZG9jdW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1 bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdhbA0KICAg UHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90cnVzdGVl LmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQogICBwdWJs aWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cyBj YXJlZnVsbHksDQogICBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0cmljdGlv bnMgd2l0aCByZXNwZWN0IHRvIHRoaXMNCiAgIGRvY3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0 cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0IGluY2x1ZGUNCiAgIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YgdGhlIFRydXN0DQog ICBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcyBk ZXNjcmliZWQgaW4NCiAgIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0KDQoNCg0KDQoNCg0K DQoNCg0KDQp6aGFuZyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA3LCAyMDEyICAgICAg ICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQcm9ibGVtIFN0 YXRlbWVudCBvZiBQUFNQICAgICAgICAgIE5vdmVtYmVyIDIwMTENCg0KDQoNCg0KVGFibGUgb2Yg Q29udGVudHMNCg0KDQogICAxLiBJbnRyb2R1Y3Rpb24gLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDQNCiAgIDMuIFByb2JsZW0gc3RhdGVtZW50IC4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gOA0KICAgICAgMy4xLiBEaWZm aWN1bHRpZXMgZm9yIElTUHMgaW4gZGVwbG95aW5nIFAyUCBjYWNoZXMgLi4uLi4uLi4uLi44DQog ICAgICAzLjIuIERpZmZpY3VsdGllcyBpbiBidWlsZGluZyBvcGVuIHN0cmVhbWluZyBkZWxpdmVy eQ0KICAgICAgaW5mcmFzdHJ1Y3R1cmUgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLiA4DQogICAgICAzLjMuIERpZmZpY3VsdGllcyBpbiBtb2JpbGUgYW5kIHdp cmVsZXNzIGVudmlyb25tZW50Li4uLi4uLi4uLjkNCiAgICAgIDMuNC4gRGlmZmljdWx0aWVzIGZv ciByZXNvdXJjZS1jb25zdHJhaW5lZCB0ZXJtaW5hbHMgdG8gcnVuDQogICAgICBtdWx0aXBsZSBi YWNrZ3JvdW5kIHByb2dyYW1zIGF0IHRoZSBzYW1lIHRpbWUgLi4uLi4uLi4uLi4uLi4uIDEwDQog ICA0LiBQUFNQOlN0YW5kYXJkIHBlZXIgdG8gcGVlciBzdHJlYW1pbmcgcHJvdG9jb2xzIC4uLi4u Li4uLi4uLi4uIDExDQogICA1LiBVc2UgY2FzZXMgb2YgUFBTUCAuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDE0DQogICAgICA1LjEuIFdvcmxkd2lkZSBwcm92aXNp b24gb2Ygb3BlbiBQMlAgbGl2ZSBzdHJlYW1pbmcgc2VydmljZXMuIDE0DQogICAgICA1LjIuIENE TiBzdXBwb3J0aW5nIFAyUCBzdHJlYW1pbmcgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uIDE1 DQogICAgICA1LjMuIFBQU1Agc3VwcG9ydGluZyBjcm9zcy1zY3JlZW4gc3RyZWFtaW5nIGluIGhl dGVyb2dlbmVvdXMNCiAgICAgIGVudmlyb25tZW50IC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMTYNCiAgICAgIDUuNC4gU3VwcG9ydGluZyBQMlAgc3Ry ZWFtaW5nIGluIGNlbGx1bGFyIG1vYmlsZSBuZXR3b3JrLi4uLi4gMTYNCiAgICAgIDUuNS4gQ2Fj aGUgc2VydmljZSBzdXBwb3J0aW5nIFAyUCBzdHJlYW1pbmcgLi4uLi4uLi4uLi4uLi4uLi4gMTcN CiAgIDYuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4gMTkNCiAgIDcuIElBTkEgQ29uc2lkZXJhdGlvbnMgLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMjANCiAgIDguIEFja25vd2xlZGdtZW50cyAuLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4gMjENCiAgIDkuIEluZm9y bWF0aXZlIFJlZmVyZW5jZXMgLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4g MjINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQp6aGFuZyAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA3LCAyMDEyICAgICAgICAgICAgICAgICAgW1Bh Z2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBvZiBQUFNQ ICAgICAgICAgIE5vdmVtYmVyIDIwMTENCg0KDQoNCjEuIEludHJvZHVjdGlvbg0KDQogICBTdHJl YW1pbmcgdHJhZmZpYyBpcyBhbW9uZyB0aGUgZmFzdGVzdCBncm93aW5nIHRyYWZmaWMgb24gdGhl DQogICBJbnRlcm5ldC4gQXMgQ2lzY28gVmlzdWFsIE5ldHdvcmsgVHJhZmZpYyBpbmRleCBtZWFz dXJlZCwgdmlkZW8NCiAgIHN0cmVhbWluZyBhbHJlYWR5IGdlbmVyYXRlcyB0aGUgbGFyZ2VzdCB2 b2x1bWUgb2YgSW50ZXJuZXQgdHJhZmZpYyBpbg0KICAgdGhlIHllYXIgb2YgMjAxMCwgYW5kIHRo ZSBwZXJjZW50YWdlIGlzIGV4cGVjdGVkIHRvIHJpc2UgdG8gYXMgaGlnaA0KICAgYXMgOTElIG9m IHRoZSB0b3RhbCBJbnRlcm5ldCB0cmFmZmljIGJ5IDIwMTRbQ2lzY29dLg0KDQogICBUaGVyZSBh cmUgdHdvIGJhc2ljIGFyY2hpdGVjdHVyZXMgZm9yIGRlbGl2ZXJpbmcgc3RyZWFtaW5nIHRyYWZm aWMgb24NCiAgIHRoZSBJbnRlcm5ldDogdGhlIGNsaWVudC1zZXJ2ZXIgcGFyYWRpZ20gYW5kIHRo ZSBQZWVyLXRvLVBlZXIgKFAyUCkNCiAgIHBhcmFkaWdtIFtTdXJ2ZXldLiBUaGUgYmFzaWMgYWR2 YW50YWdlIG9mIHRoZSBQMlAgcGFyYWRpZ20gaXMgaXRzDQogICBzY2FsYWJpbGl0eSBhbmQgZmF1 bHQgdG9sZXJhbmNlIGFnYWluc3QgZmFpbHVyZXMgb2YgY2VudHJhbGl6ZWQNCiAgIGluZnJhc3Ry dWN0dXJlcy4gQXMgYW4gZXhhbXBsZSwgUFBMaXZlIFtQUExpdmVdLCBvbmUgb2YgdGhlIGxhcmdl c3QNCiAgIFAyUCBzdHJlYW1pbmcgdmVuZG9ycywgaXMgYWJsZSB0byBkaXN0cmlidXRlIGxhcmdl LXNjYWxlLCBsaXZlDQogICBzdHJlYW1pbmcgcHJvZ3JhbXMgc3VjaCBhcyB0aGUgQ0NUViBTcHJp bmcgRmVzdGl2YWwgR2FsYSB0byBtb3JlIHRoYW4NCiAgIDMgbWlsbGlvbiB1c2VycyB3aXRoIG9u bHkgYSBoYW5kZnVsIG9mIHNlcnZlcnMuIEl0IGNhbiBhbHNvIGRlbGl2ZXINCiAgIFZvRCBzdHJl YW1pbmcgdG8gYSBzY2FsZSBvZiBzb21lIGh1bmRyZWQgb2YgdGhvdXNhbmRzIHNpbXVsdGFuZW91 cw0KICAgdXNlcnMgdXNpbmcgdGhlIHNhbWUgc3RydWN0dXJlIGFuZCBzaW1pbGFyIHByb3RvY29s cyBbVm9EXS4gVGhlDQogICBlZmZlY3Qgb2YgUDJQIHRlY2hub2xvZ2llcyBpcyBhbHNvIHdlbGwg ZGVtb25zdHJhdGVkIGluIGRlbGl2ZXJpbmcNCiAgIHJlYWwgYW5kIFZvRCBzdHJlYW1pbmcgZWZm ZWN0aXZlbHkgaW4gY3VycmVudCBwcmFjdGljZSBsaWtlIENOTiBbQ05OXSwNCiAgIFBQc3RyZWFt IFtQUFN0cmVhbV0sVVVTZWUgW1VVU2VlXWFuZCBDTlRWW0NOVFZdLiBUaGUgbGF0ZXN0IHJlbGVh c2UNCiAgIG9mIEFkb2JlIEZsYXNoLCBhIG1ham9yIHBsYXRmb3JtIG9mIHN0cmVhbWluZyBkaXN0 cmlidXRpb24gaW4gdGhlDQogICBJbnRlcm5ldCwgaGFzIGFsc28gaW50cm9kdWNlZCBDaXJydXMg W0NpcnJ1c10sIGEgcGVlciBhc3Npc3RlZCBkYXRhDQogICBleGNoYW5nZSBtb2RlLiBPbmUgcG9p bnQgdGhhdCBzaG91bGQgYWxzbyBiZSBub3RlZCBpcyB0aGF0IFAyUA0KICAgYXBwcm9hY2ggcmVx dWlyZXMgbW9yZSByZXNvdXJjZXMgYW5kIGNvbXB1dGF0aW9uYWwgcG93ZXIgb24gdGhlDQogICBj bGllbnRzICh3aGVuIGNvbXBhcmVkIHRvIGNsaWVudC1zZXJ2ZXIgYXJjaGl0ZWN0dXJlKSwgYXMg d2VsbCBhcyBhDQogICBsb3Qgb2YgY2xpZW50cyB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgUDJQIG5l dHdvcmsgZm9yIGxvdy1sYW50ZW5jeSwNCiAgIGhpZ2ggdHJhbnNtaXNzaW9uIGVmZmljaWVuY3kg YW5kIGxvdyBsb2FkIG9uIHNlcnZlcnMuDQoNCiAgIFdoYXQncyBtb3JlLCBhbG9uZyB3aXRoIHRo ZSBuZXcgcGxheWVycyBsaWtlIENETiBwcm92aWRlcnMNCiAgIChlLmcuLEFrYW1haU5ldFNlc3Np b24gW0FrYW1haV0sIENoaW5hQ2FjaGVbQ2hpbmFDYWNoZV0pIGpvaW5pbmcgaW4NCiAgIHRoZSBl ZmZvcnQgb2YgdXNpbmcgUDJQIHN0cmVhbWluZyBkZWxpdmVyeSBpbiBwcm92aWRpbmcgdGhlaXIg Y29udGVudCwNCiAgIHRoZSBQMlAgc3RyZWFtaW5nIGVjb3N5c3RlbSBpcyBiZWNvbWluZyBtb3Jl IGNvbXBsZXggd2l0aCBkaXZlcnNlDQogICBwbGF5ZXJzIHZhcnlpbmcgZnJvbSB0aGUgbWVkaWEg c291cmNlLCBpbmZyYXN0cnVjdHVyZSBzaWRlLCBlZGdlDQogICBkZWxpdmVyeSBzaWRlIGV2ZW4g dG8gdGhlIGhldGVyb2dlbmVvdXMgdHlwZXMgb2YgcGVlciBvciBjbGllbnQNCiAgIGRldmljZSBw bGF0Zm9ybXMuLg0KDQogICBHaXZlbiB0aGUgaW5jcmVhc2luZyBpbnRlZ3JhdGlvbiBvZiBQMlAg c3RyZWFtaW5nIGludG8gdGhlIGdsb2JhbA0KICAgY29udGVudCBkZWxpdmVyeSBpbmZyYXN0cnVj dHVyZSwgdGhlIGxhY2sgb2YgYW4gb3Blbiwgc3RhbmRhcmQgUDJQDQogICBzdHJlYW1pbmcgc2ln bmFsaW5nIHByb3RvY29sIHN1aXRlIGJlY29tZXMgYSBtYWpvciBtaXNzaW5nIGNvbXBvbmVudA0K ICAgaW4gdGhlIHByb3RvY29sIHN0YWNrLiBBbG1vc3QgYWxsIG9mIHRoZXNlIHN5c3RlbXMgdXNl IHRoZWlyDQogICBwcm9wcmlldGFyeSBzaWduYWxpbmcgcHJvdG9jb2xzLiBNdWx0aXBsZSwgc2lt aWxhciBidXQgcHJvcHJpZXRhcnkNCiAgIHNpZ25hbGluZyBwcm90b2NvbHMgcmVzdWx0IGluIHJl cGV0aXRpb3VzIGRldmVsb3BtZW50IGVmZm9ydHMgZm9yIG5ldw0KICAgc3lzdGVtcywgYW5kIHRo ZSBsb2NrLWluIGVmZmVjdHMgbGVhZCB0byBzdWJzdGFudGlhbCBkaWZmaWN1bHRpZXMgaW4NCiAg IHRoZWlyIGludGVncmF0aW9uLiBGb3IgZXhhbXBsZSwgaW4gdGhlIGVuaGFuY2VtZW50IG9mIGV4 aXN0aW5nIGNhY2hlcw0KICAgYW5kIENETiBzeXN0ZW1zIHRvIHN1cHBvcnQgUDJQIHN0cmVhbWlu Zywgb3BlbiBwcm90b2NvbHMgbWF5IHJlZHVjZQ0KDQoNCnpoYW5nICAgICAgICAgICAgICAgICAg IEV4cGlyZXMgTWF5IDcsIDIwMTIgICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgIFByb2JsZW0gU3RhdGVtZW50IG9mIFBQU1AgICAgICAgICAgTm92ZW1i ZXIgMjAxMQ0KDQoNCiAgIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBpbnRlcmFjdGlvbiB3aXRoIGRp ZmZlcmVudCBQMlAgc3RyZWFtaW5nDQogICBhcHBsaWNhdGlvbnMuDQoNCiAgIEluIHRoaXMgZG9j dW1lbnQgd2UgcHJvcG9zZSBhbiBvcGVuIFAyUCBTdHJlYW1pbmcgUHJvdG9jb2wsIHdoaWNoIGlz DQogICBkZWZpbmVkIGFzIFBQU1AsIHRvIHN0YW5kYXJkaXplIHNpZ25hbGluZyBvcGVyYXRpb25z IG9uIHR3byBpbXBvcnRhbnQNCiAgIGNvbXBvbmVudHMsIHBlZXIgYW5kIHRyYWNrZXIgaW4gUDJQ IHN0cmVhbWluZyBzeXN0ZW1zIGZvciBpbmZvcm1hdGlvbg0KICAgZXhjaGFuZ2UuIFRoZSBwcm9i bGVtcyBvZiBwcm9wcmlldGFyeSBzaWduYWxpbmcgcHJvdG9jb2xzIGFuZCBiZW5lZml0DQogICBv ZiBQUFNQIGFyZSBleHBsYWluZWQgZnVydGhlciBpbiBzZWN0aW9uIDMuDQoNCiAgIFBQU1Agd2ls bCBzZXJ2ZSBhcyBhbiBlbmFibGluZyB0ZWNobm9sb2d5LCBidWlsZGluZyBvbiB0aGUNCiAgIGRl dmVsb3BtZW50IGV4cGVyaWVuY2VzIG9mIGV4aXN0aW5nIFAyUCBzdHJlYW1pbmcgc3lzdGVtcy4g SXRzIGRlc2lnbg0KICAgd2lsbCBhbGxvdyBpdCB0byBpbnRlZ3JhdGUgd2l0aCBJRVRGIHByb3Rv Y29scyBvbiBkaXN0cmlidXRlZA0KICAgcmVzb3VyY2UgbG9jYXRpb24sIHRyYWZmaWMgbG9jYWxp emF0aW9uLCBhbmQgc3RyZWFtaW5nIGNvbnRyb2wgYW5kDQogICBkYXRhIHRyYW5zZmVyIG1lY2hh bmlzbXMgZm9yIGJ1aWxkaW5nIGEgY29tcGxldGUgc3RyZWFtaW5nIHN5c3RlbSBvcg0KICAgdXBk YXRpbmcgL2ludGVncmF0aW5nIGV4aXN0aW5nIGNhY2hlL0NETiB0byBzdXBwb3J0IFAyUCBzdHJl YW1pbmcNCiAgIGRlbGl2ZXJ5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCnpoYW5nICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgTWF5IDcsIDIwMTIgICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgIFByb2JsZW0gU3RhdGVtZW50IG9mIFBQU1AgICAgICAgICAgTm92ZW1iZXIgMjAx MQ0KDQoNCg0KDQoyLiBUZXJtaW5vbG9neSBhbmQgY29uY2VwdHMNCg0KICAgQ2h1bms6IEEgY2h1 bmsgaXMgYSBiYXNpYyB1bml0IG9mIGRhdGEgYmxvY2sgb3JnYW5pemVkIGluIFAyUA0KICAgc3Ry ZWFtaW5nIGZvciBzdG9yYWdlLCBzY2hlZHVsaW5nLCBhZHZlcnRpc2VtZW50IGFuZCBleGNoYW5n ZSBhbW9uZw0KICAgcGVlcnMgW1ZvRF0uIEEgY2h1bmsgc2l6ZSB2YXJpZXMgZnJvbSBzZXZlcmFs IEtCIHRvIHNldmVyYWwgTUIgaW4NCiAgIGRpZmZlcmVudCBzeXN0ZW1zLiBJbiBjYXNlIG9mIE1C IHNpemUgY2h1bmsgc2NlbmFyaW8sIGEgc3ViLWNodW5rDQogICBzdHJ1Y3R1cmUgbmFtZWQgcGll Y2UgaXMgb2Z0ZW4gZGVmaW5lZCB0byBmaXQgaW4gYSBzaW5nbGUgdHJhbnNtaXR0ZWQNCiAgIHBh Y2tldC4gQSBzdHJlYW1pbmcgc3lzdGVtIG1heSB1c2UgZGlmZmVyZW50IGdyYW51bGFyaXRpZXMg Zm9yDQogICBkaWZmZXJlbnQgdXNhZ2UsIGUuZy4sIHVzaW5nIGNodW5rcyBkdXJpbmcgZGF0YSBl eGNoYW5nZSwgYW5kIHVzaW5nIGENCiAgIGxhcmdlciB1bml0IHN1Y2ggYXMgYSBzZXQgb2YgY2h1 bmtzIGR1cmluZyBhZHZlcnRpc2VtZW50Lg0KDQogICBDb250ZW50IERpc3RyaWJ1dGlvbiBOZXR3 b3JrIChDRE4pOiBBIENETiBub2RlIHJlZmVycyB0byBhIG5ldHdvcmsNCiAgIGVudGl0eSB0aGF0 IGlzIGRlcGxveWVkIGluIHRoZSBuZXR3b3JrIChlLmcuLCBhdCB0aGUgbmV0d29yayBlZGdlIG9y DQogICBkYXRhIGNlbnRlcnMpIHRvIHN0b3JlIGNvbnRlbnQgcHJvdmlkZWQgYnkgdGhlIG9yaWdp bmFsIHNlcnZlcnMsIGFuZA0KICAgc2VydmVzIGNvbnRlbnQgdG8gdGhlIGNsaWVudHMgbG9jYXRl ZCBuZWFyYnkgdG9wb2xvZ2ljYWxseS4NCg0KICAgQ2xpZW50OiBBIGNsaWVudCByZWZlcnMgdG8g dGhlIHNlcnZpY2UgcmVxdWVzdGVyIGluIGNsaWVudC9zZXJ2ZXINCiAgIGNvbXB1dGluZyBwYXJh ZGlnbS4gSW4gdGhpcyBkcmFmdCBhIGNsaWVudCByZWZlcnMgdG8gYSBwYXJ0aWNpcGFudCBpbg0K ICAgYSBQMlAgc3RyZWFtaW5nIHN5c3RlbSB0aGF0IG9ubHkgcmVjZWl2ZXMgc3RyZWFtaW5nIGNv bnRlbnQuIEluIHNvbWUNCiAgIGNhc2VzIHRoZSBub2RlIGlzIG5vdCBlbGlnaWJsZSB0byBiZSBh IHBlZXIgd2l0aG91dCBlbm91Z2ggY29tcHV0aW5nDQogICBhbmQgc3RvcmFnZSBjYXBhYmlsaXR5 IGlzIGFjdGluZyBhcyBhIGNsaWVudC4gSXQgY2FuIGJlIHZpZXdlZCBhcyBhDQogICBzcGVjaWZp YyBraW5kIG9mIHBlZXIuDQoNCiAgIExpdmUgc3RyZWFtaW5nOiBJdCByZWZlcnMgdG8gYSBzY2Vu YXJpbyB3aGVyZSBhbGwgY2xpZW50cyByZWNlaXZlDQogICBzdHJlYW1pbmcgY29udGVudCBmb3Ig dGhlIHNhbWUgb25nb2luZyBldmVudC4gSXQgaXMgZGVzaXJlZCB0aGF0IHRoZQ0KICAgbGFncyBi ZXR3ZWVuIHRoZSBwbGF5IHBvaW50cyBvZiB0aGUgY2xpZW50cyBhbmQgdGhhdCBvZiB0aGUgc3Ry ZWFtaW5nDQogICBzb3VyY2UgYmUgc21hbGwuDQoNCiAgIFAyUCBjYWNoZTogQSBQMlAgY2FjaGUg cmVmZXJzIHRvIGEgbmV0d29yayBlbnRpdHkgdGhhdCBjYWNoZXMgUDJQDQogICB0cmFmZmljIGlu IHRoZSBuZXR3b3JrLCBhbmQgZWl0aGVyIHRyYW5zcGFyZW50bHkgb3IgZXhwbGljaXRseSBhcyBh DQogICBwZWVyIGRpc3RyaWJ1dGVzIGNvbnRlbnQgdG8gb3RoZXIgcGVlcnMuDQoNCiAgIFBlZXI6 IEEgcGVlciByZWZlcnMgdG8gYSBwYXJ0aWNpcGFudCBpbiBhIFAyUCBzdHJlYW1pbmcgc3lzdGVt IHRoYXQNCiAgIG5vdCBvbmx5IHJlY2VpdmVzIHN0cmVhbWluZyBjb250ZW50LCBidXQgYWxzbyBz dG9yZXMgYW5kIHVwbG9hZHMNCiAgIHN0cmVhbWluZyBjb250ZW50IHRvIG90aGVyIHBhcnRpY2lw YW50cy4NCg0KICAgUFBTUDogVGhlIGFiYnJldmlhdGlvbiBvZiBQZWVyLXRvLVBlZXIgU3RyZWFt aW5nIFByb3RvY29scy4gUFBTUA0KICAgcmVmZXIgdG8gdGhlIGtleSBzaWduYWxpbmcgcHJvdG9j b2xzIGFtb25nIHZhcmlvdXMgUDJQIHN0cmVhbWluZw0KICAgc3lzdGVtIGNvbXBvbmVudHMsIGlu Y2x1ZGluZyB0aGUgdHJhY2tlciBhbmQgdGhlIHBlZXIuDQoNCiAgIFN3YXJtOiBBIHN3YXJtIHJl ZmVycyB0byBhIGdyb3VwIG9mIHBlZXJzIHdobyBleGNoYW5nZSBkYXRhIHRvDQogICBkaXN0cmli dXRlIGNodW5rcyBvZiB0aGUgc2FtZSBjb250ZW50KGUuZy4gdmlkZW8vYXVkaW8gcHJvZ3JhbSwN CiAgIGRpZ2l0YWwgZmlsZSwgZXRjKSBhdCBhIGdpdmVuIHRpbWUuDQoNCg0KDQoNCnpoYW5nICAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDcsIDIwMTIgICAgICAgICAgICAgICAgICBbUGFn ZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFByb2JsZW0gU3RhdGVtZW50IG9mIFBQU1Ag ICAgICAgICAgTm92ZW1iZXIgMjAxMQ0KDQoNCiAgIFRyYWNrZXI6IEEgdHJhY2tlciByZWZlcnMg dG8gYSBkaXJlY3Rvcnkgc2VydmVyIHdoaWNoIG1haW50YWlucyBhDQogICBsaXN0IG9mIHBlZXJz IHdoaWNoIHBhcnRpY2lwYXRlIGluIGEgc3BlY2lmaWMgdmlkZW8gY2hhbm5lbCBvciBpbiB0aGUN CiAgIGRpc3RyaWJ1dGlvbiBvZiBhIHN0cmVhbWluZyBmaWxlLCBhbmQgYW5zd2VycyBxdWVyaWVz IGZyb20gcGVlcnMgZm9yDQogICBwZWVyIGxpc3RzLiBUaGUgdHJhY2tlciBpcyBhIGxvZ2ljYWwg Y29tcG9uZW50IHdoaWNoIGNhbiBiZQ0KICAgY2VudHJhbGl6ZWQgb3IgZGlzdHJpYnV0ZWQuDQoN CiAgIFZpZGVvLW9uLWRlbWFuZCAoVm9EKTogSXQgcmVmZXJzIHRvIGEgc2NlbmFyaW8gd2hlcmUg ZGlmZmVyZW50DQogICBjbGllbnRzIG1heSB3YXRjaCBkaWZmZXJlbnQgcGFydHMgb2YgdGhlIHNh bWUgcmVjb3JkZWQgbWVkaWEgd2l0aA0KICAgZG93bmxvYWRlZCBjb250ZW50Lg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KemhhbmcgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAg ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxl bSBTdGF0ZW1lbnQgb2YgUFBTUCAgICAgICAgICBOb3ZlbWJlciAyMDExDQoNCg0KDQoNCjMuIFBy b2JsZW0gc3RhdGVtZW50DQoNCiAgIFRoZSBwcm9ibGVtcyBpbXBvc2VkIGJ5IHByb3ByaWV0YXJ5 IHNpZ25hbGluZyBmb3IgUDJQIHN0cmVhbWluZw0KICAgYXBwbGljYXRpb25zIGFyZSBsaXN0ZWQg YXMgZm9sbG93cy4NCg0KMy4xLiBEaWZmaWN1bHRpZXMgZm9yIElTUHMgaW4gZGVwbG95aW5nIFAy UCBjYWNoZXMNCg0KICAgRmFjaW5nIHdpdGggbWFueSBQMlAgc3RyZWFtaW5nIGFwcGxpY2F0aW9u cywgSVNQcyBhcmUgd2l0bmVzc2luZyBhDQogICBiaWcgdHJhZmZpYyB0ZW5zaW9uIG9uIHRoZWly IGJhY2tib25lIGFuZCBpbnRlci1uZXR3b3JraW5nIHBvaW50cy5QMlANCiAgIGNhY2hlcyBhcmUg dXNlZCB0byByZWR1Y2UgdGhlIHRyYWZmaWMgYnkgZHluYW1pY2FsbHkgc3RvcmluZyB0aGUNCiAg IGZyZXF1ZW50bHkgYWNjZXNzZWQgc3RyZWFtaW5nIGNvbnRlbnQgKG1heWJlIGluIGNodW5rIG9y IGluIGZpbGUNCiAgIGdyYW51bGFyaXR5KS4gSG93ZXZlciwgdGhlIGNhY2hlIG5vZGVzIG5lZWQg dG8gZXhlY3V0ZSBEUEkgKGRlZXANCiAgIHBhY2tldCBpbnNwZWN0aW9uKSBmb3IgaWRlbnRpZnlp bmcgZGlmZmVyZW50IFAyUCBzdHJlYW1pbmcgc3lzdGVtcy4NCiAgIE11bHRpcGxlIGV2ZXIgY2hh bmdpbmcgcHJvcHJpZXRhcnkgUDJQIHN0cmVhbWluZyBwcm90b2NvbHMgcmVxdWlyZQ0KICAgdGhl IFAyUCBjYWNoZSB1cGRhdGluZyBpdHMgbWF0Y2hpbmcgbGlicmFyeSBjb25zdGFudGx5IHdoaWNo DQogICBpbmNyZWFzZXMgdGhlIG9wZXJhdG9yJ3MgY29zdCBkcmFtYXRpY2FsbHkuDQoNCiAgIFdp dGggUFBTUCwgUDJQIGNhY2hlcyBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3QgUDJQIHN0cmVhbWlu Zw0KICAgYXBwbGljYXRpb25zIG11Y2ggZWFzaWVyIHdpdGhvdXQgbmVlZGluZyB0byB1cGRhdGUg aXRzIGxpYnJhcnksIGFzDQogICB0aGVyZSBzaG91bGQgYmUgb25seSBhIHNpbmdsZSBwcm90b2Nv bCB0byBiZSBkZXRlY3RlZCBhbmQgbm90IGENCiAgIHBvdGVudGlhbGx5IHVua25vd24gc2V0IG9m IHByb3ByaWV0YXJ5IFAyUCBwcm90b2NvbHMuIFRoaXMgd291bGQNCiAgIHJlZHVjZSB0aGUgSVNQ IHdvcmtsb2FkIHRvIGEgbGFyZ2UgZXh0ZW50LiBOb3RlIHRoYXQgdXNpbmcgc3RhbmRhcmQNCiAg IFBQU1Agd291bGQgbm90IGh1cnQgY3VycmVudCBQMlAgc3RyZWFtaW5nIHByb3ZpZGVyczogRmly c3RseSwgdGhlDQogICBvcGVubmVzcyBvZiBzaWduYWxpbmcgaW50ZXJhY3Rpb24gd291bGQgbWFr ZSBpdCBlYXN5IHRvIGludGVncmF0ZQ0KICAgdGhlbSB3aXRoIElTUCdzIGNhY2hlcyBmb3IgYmV0 dGVyIHVzZXIgZXhwZXJpZW5jZSwgc2F5LCBzbWFsbGVyIGRlbGF5DQogICBvZiB0aGUgcGxheS4g U2Vjb25kbHksIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgY291bGQgdXNlIFBQU1AgZm9yDQogICBz aWduYWxpbmcsIGJ1dCBpbXBsZW1lbnQgc29tZXRoaW5nIHN5c3RlbSBzcGVjaWZpYyBvbiB0b3Ag b2YgdGhhdC4NCiAgIFRoYXQgaXMgdG8gc2F5LCBkaWZmZXJlbnQgUDJQIHN0cmVhbWluZyBzeXN0 ZW1zIGNvbXBldGUgb24gIm9uIHRvcCINCiAgIHRoaW5ncywgbGlrZSBzY2hlZHVsaW5nIGFsZ29y aXRobXMsIHdoaWNoIGlzIGluZGVwZW5kZW50IG9mIGhvdyB0aGUNCiAgIHBlZXJzIGV4Y2hhbmdl IGNodW5rIGF2YWlsYWJpbGl0eS4gSW4gb3RoZXIgd29yZHMsIGRpZmZlcmVudCBzeXN0ZW1zDQog ICBzaG91bGQgYmUgYWJsZSB0byBoYXZlIHF1aXRlIGRpZmZlcmVudCBzY2hlZHVsaW5nIGFsZ29y aXRobXMgd2l0aA0KICAgc2FtZSB0cmFja2VyL3BlZXIgcHJvdG9jb2wsIHdoaWNoIGlzIGVhc2ll ciB0byBiZSBvcGVuLg0KDQozLjIuIERpZmZpY3VsdGllcyBpbiBidWlsZGluZyBvcGVuIHN0cmVh bWluZyBkZWxpdmVyeSBpbmZyYXN0cnVjdHVyZQ0KDQogICBNb3JlIGFuZCBtb3JlIGVmZm9ydHMg YXJlIHNlZWtpbmcgZm9yIGJ1aWxkaW5nIGFuIG9wZW4gZ2xvYmFsDQogICBzdHJlYW1pbmcgZGVs aXZlcnkgaW5mcmFzdHJ1Y3R1cmUsIHdoZXJlIHN5c3RlbXMgdXNpbmcgUDJQIGFjY291bnQNCiAg IGZvciBhIGxhcmdlIHBvcnRpb24uIEhvd2V2ZXIgaWYgY3VycmVudCBtdWx0aXBsZSBwcm9wcmll dGFyeQ0KICAgcHJvdG9jb2xzIGNvbnRpbnVlIHRvIHdvcmssIHRoZXJlIHdpbGwgZXhpc3QgbG90 cyBvZiBzcGVjaWZpYyBhbmQNCiAgIGluZGVwZW5kZW50IHN5c3RlbXMgdG8gZGVsaXZlciB2YXN0 bHl0aGUgc2FtZSBzdHJlYW1pbmcgY29udGVudC4gVGhpcw0KICAgYnJpbmdzIG1vcmUgYnVyZGVu cyBmb3IgaWRlbnRpZnlpbmcgYW5kIHNoYXJpbmcgdGhlIHNhbWUgY29udGVudHMsDQogICBhbmQg aW5jcmVhc2VzIHRoZSBzdG9yYWdlLCBmb3J3YXJkaW5nIGFuZCBtYWludGVuYW5jZSBjb3N0IGlu IHRoZQ0KICAgaW50ZXJtZWRpYXRlIG5vZGVzIGZvciByZXBlYXRlZCBjb250ZW50LiBUaGlzIHdp bGwgZGVmaW5pdGVseQ0KICAgaW5jcmVhc2UgdGhlIGNvc3Qgb2Ygc3RyZWFtaW5nIGRpc3RyaWJ1 dGlvbiBhbmQgY2F1c2VzIHBvc3NpYmxlDQogICBjb25nZXN0aW9uIGluIHRoZSBuZXR3b3JrLg0K DQoNCnpoYW5nICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWF5IDcsIDIwMTIgICAgICAgICAg ICAgICAgICBbUGFnZSA4XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFByb2JsZW0gU3RhdGVt ZW50IG9mIFBQU1AgICAgICAgICAgTm92ZW1iZXIgMjAxMQ0KDQoNCiAgIENvbnNpZGVyIGEgY2Fz ZSB3aGVyZSBzb3VyY2UgdmVuZG9ycyBjb29wZXJhdGUgd2l0aCAzcmQgcGFydHkgQ0RODQogICBw cm92aWRlcnMuIFN1Y2ggaW50ZWdyYXRpb24gaXMgYWxyZWFkeSBwcmFjdGljZWQgYnkgVVVTZWVb VVVTZWVdLA0KICAgUmF5VltSYXlWXSBhbmQgRm9yY2V0ZWNoW0ZvcmNldGVjaF0uIFRoZSBlZmZl Y3QgaGFzIGJlZW4gdmVyaWZpZWQgdG8NCiAgIGltcHJvdmUgdGhlIHRvdGFsIHBlcmZvcm1hbmNl IG9mIFAyUCBzdHJlYW1pbmcgKGUuZy4sIHdpdGggbG93ZXINCiAgIGxhdGVuY3kpIGJ5IHByb3Zp ZGluZyBtb3JlIHN0YWJsZSAic3VwZXIgcGVlcnMiIGFuZCByZWR1Y2UgdHJhZmZpYw0KICAgZm9y IElTUCBbQ0ROK1AyUF0gW1JGQyA1NjkzXS5Ib3dldmVyLCB0aGVyZSBhcmUgc3Vic3RhbnRpYWwg b2JzdGFjbGVzDQogICBmb3IgQ0ROIG5vZGVzIHN1cHBvcnRpbmcgcHJvcHJpZXRhcnkgUDJQIHN0 cmVhbWluZyBwcm90b2NvbHMgW0hQVFBdLg0KICAgVW5saWtlIHRoZSBXZWIgd2hlcmUgYWxsIGtp bmRzIG9mIHRoZSBpbmZyYXN0cnVjdHVyZSBkZXZpY2VzIGhhdmUNCiAgIGJlZW4gYWxyZWFkeSBl cXVpcHBlZCB3aXRoIHN0YW5kYXJkIEhUVFAgcHJvdG9jb2wsIGFuIG9wZW4gQ0RODQogICBzdXBw b3J0aW5nIHZhcmlvdXMgUDJQIHN0cmVhbWluZyBhcHBsaWNhdGlvbnMgbmVlZCB0byB1bmRlcnN0 YW5kIGFuZA0KICAga2VlcCB1cGRhdGVkIG9uIHZhcmlvdXMgcHJvdG9jb2xzLiBTaW1pbGFyIHRv IHRoZSBjYWNoaW5nIGNhc2UgaW4NCiAgIFNlY3Rpb24gMy4xLCB0aGlzIGludHJvZHVjZXMgY29t cGxleGl0eSBhbmQgZGVwbG95bWVudCBjb3N0Lg0KDQogICBXaXRoIFBQU1AsIENETiBub2RlcyBj YW4gYmUgZGVzaWduZWQgdG8gaW50ZXItb3BlcmF0ZSB3aXRoIG90aGVyDQogICBkZXZpY2VzIGJ5 IG9ubHkgc3RhbmRhcmQgcHJvdG9jb2xzLCByZWR1Y2luZyB0aGUgY2FzZSBieSBjYXNlDQogICBu ZWdvdGlhdGlvbiBiZXR3ZWVuIHRoZSBQMlAgc3RyZWFtaW5nIHByb3ZpZGVycyBhbmQgQ0ROIHBy b3ZpZGVycy5Pbg0KICAgdGhlIG90aGVyIHNpZGUsIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBDRE4g bm9kZXMgYW5kIHVzZXIgcGVlcnMgY291bGQNCiAgIGJlIHZpYSBzb21ldGhpbmcgbGlrZSB0cmFk aXRpb25hbCBIVFRQIHJlcXVlc3RzLCBvciBjb3VsZCBiZSB2aWEgUFBTUA0KICAgZm9yIHN0cmVh bWluZyBzZXR1cC4NCg0KMy4zLiBEaWZmaWN1bHRpZXMgaW4gbW9iaWxlIGFuZCB3aXJlbGVzcyBl bnZpcm9ubWVudA0KDQogICBNb2JpbGl0eSBhbmQgd2lyZWxlc3MgYXJlIGJlY29taW5nIGluY3Jl YXNpbmdseSBpbXBvcnRhbnQgZmVhdHVyZXMgaW4NCiAgIHRvZGF5J3MgSW50ZXJuZXQuIEl0IGlz IHByZWRpY3RlZCB0aGF0IGJ5IHRoZSBlbmQgb2YgMjAxMiwgdGhlIG51bWJlcg0KICAgb2YgbW9i aWxlIEludGVybmV0IHVzZXJzIHdpbGwgc3VycGFzcyB0aGF0IG9mIGZpeGVkIEludGVybmV0IHVz ZXJzIGluDQogICBDaGluYSBbU3RhdGlzdGljc10uIE1vYmlsZSBzdHJlYW1pbmcgaGFzIGJlY29t aW5nIGEga2V5IG9mZmVyaW5nLiBJbg0KICAgS29yZWEgdGhlIG51bWJlciBvZiBtb2JpbGUgVFYg c3Vic2NyaWJlciBoYXMgcmVhY2hlZCBzZXZlbnRlZW4NCiAgIG1pbGxpb24sIGFjY291bnRpbmcg Zm9yIG9uZSB0aGlyZCBvZiB0aGUgbW9iaWxlIHN1YnNjcmliZXJzLiBEdXJpbmcNCiAgIHRoZSAy MDA4IEJlaWppbmcgT2x5bXBpYyBHYW1lcywgbW9yZSB0aGFuIG9uZSBtaWxsaW9uIHVzZXJzIGVu am95ZWQNCiAgIG1vYmlsZSBUViBzZXJ2aWNlLiBUaGVyZSBhcmUgbXVsdGlwbGUgcHJpb3Igc3R1 ZGllcyBleHBsb3JpbmcgUDJQDQogICBzdHJlYW1pbmcgaW4gbW9iaWxlIGFuZCB3aXJlbGVzcyBu ZXR3b3JrcyBbTW9iaWxlIFN0cmVhbWluZzFdIFtNb2JpbGUNCiAgIFN0cmVhbWluZzJdLg0KDQog ICBIb3dldmVyIGl0J3MgZGlmZmljdWx0IHRvIGNvcHkgY3VycmVudCBQMlAgc3RyZWFtaW5nIHBy b3RvY29scyBpbg0KICAgbW9iaWxlIGFuZCB3aXJlbGVzcyBuZXR3b3Jrcy4gQ3VycmVudCBwcm90 b2NvbHMgYXJlIGRlc2lnbmVkIG1haW5seQ0KICAgZm9yIGZpeGVkIEludGVybmV0LiBBbHRob3Vn aCBzbWFydCBoYW5kc2V0cyBhcmUgbW9yZSBlbGlnaWJsZSB0byBiZQ0KICAgcGVlcnMgd2l0aCBt dWNoIGJldHRlciBiYW5kd2lkdGggYW5kIGhpZ2hlciBDUFUgZnJlcXVlbmN5LCBsYXJnZXINCiAg IHN0b3JhZ2UgYW5kIG1lbW9yeSB0aGFuIGJlZm9yZSwgcGVlciBzZWxlY3Rpb24gaXMgbW9yZSBj aGFsbGVuZ2luZw0KICAgd2hpY2ggbmVlZHMgbW9yZSBpbmZvcm1hdGlvbiB0byBleGNoYW5nZSBk dXJpbmcgdGhlIHRyYWNrZXIvcGVlciBhbmQNCiAgIHBlZXIvcGVlciBjb21tdW5pY2F0aW9uczog Rmlyc3QsIGluIG1vYmlsZSBhbmQgd2lyZWxlc3MgbmV0d29ya3MsIHRoZQ0KICAgY29ubmVjdGlv bnMgYXJlIHVuc3RlYWR5LCBsb3dlciByYXRlLCBhbmQgY29zdGx5IGluIHRlcm1zIG9mIGVuZXJn eQ0KICAgY29uc3VtcHRpb24gYW5kIHRyYW5zbWlzc2lvbihlc3AuIGluIHVwbGluaykuIFRoZSB0 cmFja2VycyBhbmQgcGVlcnMNCiAgIG1heSBuZWVkIG1vcmUgaW5mb3JtYXRpb24sIGNvbXBhcmVk IHRvIGZpeGVkIEludGVybmV0LCBsaWtlIHBhY2tldA0KICAgbG9zcyByYXRlLCBwZWVyIGJhdHRl cnkgc3RhdHVzIGFuZCBwcm9jZXNzaW5nIGNhcGFiaWxpdHkgZm9yIHBlZXINCiAgIHNlbGVjdGlv bi4gTm90ZSB0aGF0IG5vdCBhbGwgbW9iaWxlIG5vZGVzIGFyZSBlbGlnaWJsZSB0byBiZSBwZWVy cy4NCiAgIFNlY29uZCwgY3VycmVudCBwcmFjdGljZXMgb2Z0ZW4gdXNlIGEgImJpdG1hcCIgbWVz c2FnZSB0byBleGNoYW5nZQ0KICAgY2h1bmsgYXZhaWxhYmlsaXR5IGFtb25nIHBlZXJzL3RyYWNr ZXJzLiBUaGUgbWVzc2FnZSBpcyBvZnRlbiBvZiBzb21lDQoNCg0KemhhbmcgICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxlbSBTdGF0ZW1lbnQgb2YgUFBTUCAgICAgICAgICBO b3ZlbWJlciAyMDExDQoNCg0KICAga2lsb2J5dGVzIHNpemUgYW5kIGV4Y2hhbmdlZCByZWxhdGl2 ZWx5IGZyZXF1ZW50bHkuIEluIHRoZSBtb2JpbGUNCiAgIG5ldHdvcmtzLCB0aGUgYmFuZHdpZHRo IGlzIHNjYXJjZSBhbmQgYSByZWFzb25hYmxlIG9wdGltaXphdGlvbiBpcyB0bw0KICAgcmVkdWNl IHRoZSBtZXNzYWdlIHNpemUsIHdoaWNobWF5IHJlcXVpcmUgYWx0ZXJuYXRpdmUgbWV0aG9kcyBm b3INCiAgIGV4cHJlc3NpbmcgYW5kIGRpc3RyaWJ1dGluZyBiaXRtYXAgaW5mb3JtYXRpb24uIFRo aXJkLCBtb2JpbGl0eSBpc3N1ZS4NCiAgIFdoZW4gYSBwZWVyIGlzIG1vdmluZyBhbmQgdGhlIElQ IGFkZHJlc3MgY2hhbmdlcywgdGhlIG9uLWdvaW5nDQogICBjb25uZWN0aW9uIGFuZCB0cmFuc21p c3Npb24gYmV0d2VlbiBwZWVycyBtYXkgYmUgYWZmZWN0ZWQuIFRoZXJlZm9yZQ0KICAgc3VjaCBp bmZvcm1hdGlvbiBzaG91bGQgYmUgcmVwb3J0ZWQgaW4gdGltZSwgd2hpY2ggaXMgbm90IGFkZHJl c3NlZA0KICAgaW4gY3VycmVudCBwcmFjdGljZXMuDQoNCiAgIFBQU1Agc2hvdWxkIGludmVzdGln YXRlIHRoZXNlIGZhY3RvcnMgZm9yIGEgcHJhY3RpY2FsIGNvbnZlcmdlZA0KICAgbmV0d29yayBm cm9tIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGRlc2lnbi4NCg0KMy40LiBEaWZmaWN1bHRpZXMgZm9y IHJlc291cmNlLWNvbnN0cmFpbmVkIHRlcm1pbmFscyB0byBydW4gbXVsdGlwbGUNCiAgIGJhY2tn cm91bmQgcHJvZ3JhbXMgYXQgdGhlIHNhbWUgdGltZQ0KDQogICBQcml2YXRlIHByb3RvY29scyBt YXkgcmVxdWlyZSBhIHRlcm1pbmFsIHRvIGluc3RhbGwgZGlmZmVyZW50DQogICBzb2Z0d2FyZSBm b3IgZGlmZmVyZW50IGFwcGxpY2F0aW9ucy4gTm90ZSB0aGF0IGZvciBtYW55IGNsaWVudA0KICAg c29mdHdhcmUsIGV2ZW4gaXQncyBub3QgdXNlZCBieSB0aGUgdXNlcnMgcmlnaHQgbm93LCB0aGUg YmFja2dyb3VuZA0KICAgcHJvZ3JhbSBtYXkgYmUgaW52b2tlZCB0byBmYWNpbGl0YXRlIG90aGVy IHBlZXJzIGZvciBmcmVlIGRhdGENCiAgIGRlbGl2ZXJ5IGFzc2lzdGFuY2UuIEluIG90aGVyIHdv cmRzLCB0aGVyZSB3aWxsIGJlIG11bHRpcGxlDQogICBiYWNrZ3JvdW5kIHByb2dyYW1zIHJ1bm5p bmcgYXQgdGhlIHNhbWUgdGltZS4gSG93ZXZlciBpdCBtYXkgYmUNCiAgIGRpZmZpY3VsdCB0byBp bnZva2UgbXVsdGlwbGUgcHJvZ3JhbXMgaW4gYSByZXNvdXJjZSBjb25zdHJhaW50IHBlZXINCiAg IGxpa2UgbW9iaWxlIGhhbmRzZXRzIG9yIHNldHRvcCBib3hlcyAoU1RCcykuIFRoZSBsaW1pdGVk IENQVSwgc3RvcmFnZQ0KICAgYW5kIG1lbW9yeSBvZnRlbiBsaW1pdCB0aGUgdG90YWwgbnVtYmVy IG9mIGNvbmN1cnJlbnQgdGhyZWFkcyBhbmQNCiAgIHByb2Nlc3Nlcy4gVGFraW5nIHN0b3JhZ2Ug Zm9yIGV4YW1wbGUsIGFjY29yZGluZyB0bw0KICAgW1BQU3RyZWFtXVtVVVNlZV1bUFBMaXZlIERl c2lnbl0sIHRoZSBidWZmZXIgb2YgZWFjaCBwZWVyJ3MgaGFyZCBkaXNrDQogICBjb250cmlidXRl ZCB0byB0aGUgc3lzdGVtIGlzIGF0IGxlYXN0IDFHQi4gSWYgZWFjaCBtb2JpbGUgcGVlciwgbGlr ZQ0KICAgaVBob25lICh2ZXJzaW9uIDEpIHJ1bnMgdHdvIHN1Y2ggYmFja2dyb3VuZCBhcHBsaWNh dGlvbnMgYXQgdGhlIHNhbWUNCiAgIHRpbWUsIHRoZSBzdG9yYWdlIGNhbm5vdCBiZSBzaGFyZWQg Zm9yIGRpZmZlcmVudCBhcHBsaWNhdGlvbnMgYW5kIGl0DQogICB3aWxsIGNvbnN1bWUgb25lIGZv dXJ0aCBvZiBhbGwgaXRzIHN0b3JhZ2UgKDggR0IpLCBsZWF2aW5nIG90aGVyIGRhdGENCiAgIHdp dGggZmV3ZXIgc3RvcmFnZS4NCg0KICAgUFBTUCBjYW4gaGVscCB0byByZWR1Y2UgdGhlIHJlc291 cmNlIGNvbnN1bXB0aW9uIGxpa2UgUkFNIHVzYWdlIG9uDQogICByZXNvdXJjZSBjb25zdHJhaW50 IGRldmljZXMsIHN1Y2ggYXMgU1RCcyBvciBtb2JpbGUgcGhvbmVzLCBieQ0KICAgcmV1c2luZyBh IFBQU1AgYmFzZSBsaWJyYXJ5IGFuZCBwb3RlbnRpYWxseSBvdGhlciBvcHRpbWl6YXRpb25zLg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQp6aGFuZyAgICAgICAgICAgICAgICAgICBFeHBpcmVz IE1heSA3LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAxMF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBvZiBQUFNQICAgICAgICAgIE5vdmVtYmVyIDIwMTEN Cg0KDQoNCg0KNC4gUFBTUDpTdGFuZGFyZCBwZWVyIHRvIHBlZXIgc3RyZWFtaW5nIHByb3RvY29s cw0KDQogICBUaGUgb2JqZWN0aXZlIG9mIHRoZSBQUFNQIHdvcmtpbmcgZ3JvdXAgaXMgdG8gZGVz aWduIGEgdW5pZmllZCBwZWVyLQ0KICAgdG8tcGVlciBzdHJlYW1pbmcgcHJvdG9jb2wgKFBQU1Ap IHRvIGFkZHJlc3MgdGhlIHByb2JsZW1zIGRpc2N1c3NlZA0KICAgaW4gdGhlIHByZWNlZGluZyBz ZWN0aW9ucy4NCg0KICAgVGhlcmUgYXJlIGJhc2ljYWxseSB0d28ga2luZHMgb2YgUDJQIHN0cmVh bWluZyBzeXN0ZW1zLCBwdWxsLWJhc2VkDQogICBhbmQgcHVzaC1iYXNlZC4NCg0KICAgSW4gcHVs bC1iYXNlZCBQMlAgc3RyZWFtaW5nIHN5c3RlbXMsIGEgY2VudHJhbGl6ZWQgdHJhY2tlciBvcg0K ICAgZGlzdHJpYnV0ZWQgdHJhY2tlcnMgbWFpbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0IHdoaWNo IHBlZXJzIGFyZSBpbg0KICAgd2hpY2ggc3dhcm1zIGFuZCBhbnN3ZXJzIHRoZSBwZWVycycgcXVl cnkgb24gc3VjaCBpbmZvcm1hdGlvbiB3aXRoIGENCiAgIHBlZXItbGlzdC4gQWZ0ZXIgcmVjZWl2 aW5nIHRoZSBtZXNzYWdlLCB0aGUgcGVlciBjYW4gY29ubmVjdCB3aXRoIHRoZQ0KICAgY2FuZGlk YXRlcyBpbiBhIHN3YXJtLCBleGNoYW5nZSBpdHMgY29udGVudCBhdmFpbGFiaWxpdHkgaW4gaXRz DQogICBtZW1vcnkgb3Igc3RvcmFnZSAoZGVwZW5kaW5nIG9uIGl0J3MgcmVhbC10aW1lIG9yIFZv RCBzdHJlYW1pbmcpIHdpdGgNCiAgIG90aGVyIHBlZXJzIGFuZCB0aGVuIHJldHJpZXZlIHRoZSB3 YW50ZWQgc3RyZWFtaW5nIGRhdGEuIFRoZSBzd2FybSBpcw0KICAgYSBtZXNoIHRvcG9sb2d5LiBN b3N0IG9mIHRoZSBjdXJyZW50IHByYWN0aWNlcyBiZWxvbmcgdG8gdGhpcyBnZW5yZS4NCiAgIFRo ZSBhZHZhbnRhZ2VzIG9mIHB1bGwtYmFzZWQgbW9kZSBhcmUgaXRzIHJvYnVzdG5lc3MgdG8gdGhl IHBlZXINCiAgIGNodXJuIGFuZCBhY2NlcHRhYmxlIGxhdGVuY3kgZm9yIGEgc21vb3RoIHBsYXku DQoNCiAgIEluIHB1c2gtYmFzZWQgUDJQIHN0cmVhbWluZyBzeXN0ZW1zLCB0aGVyZSBpcyBhIGhl YWQgbm9kZSBtYWludGFpbmluZw0KICAgdGhlIHRvcG9sb2d5LCBlLmcuLCBhIHRyZWUuIFRoZSBw ZWVycyBpbiB0aGlzIHRvcG9sb2d5IHNoYXJlIHRoZSBzYW1lDQogICBpbnRlcmVzdCBvbiBjb250 ZW50LiBUaGUgc2lnbmFsaW5nIGFuZCBkYXRhIGRpc3RyaWJ1dGlvbiBhcmUgYm90aA0KICAgYmFz ZWQgb24gdGhpcyB0b3BvbG9neS4gRm9yIG9uZSBwcm9ncmFtIG9yIHZpZGVvIGZpbGUsIHRoZSBw ZWVyDQogICBxdWVyaWVzIHRoZSBoZWFkIG5vZGUgYnkgb2ZmbGluZSBvciBwcmUtc2V0IGhlYWQg bm9kZSBhZGRyZXNzDQogICBpbmZvcm1hdGlvbiBmb3IgaXRzIGxvY2F0aW9uIHRvIGpvaW4gYW5k IHRoZSBoZWFkIG5vZGUgcmVwbGllcyB3aXRoIGENCiAgIHBlZXItbGlzdChwb3RlbnRpYWxseSBp biBhIHJlY29tbWVuZGVkIG9yZGVyKS4gQWZ0ZXIgcmVjZWl2aW5nIHRoaXMNCiAgIHBlZXItbGlz dCwgdGhlIHBlZXIgY2FuIGNvbm5lY3Qgd2l0aCB0aGUgY2FuZGlkYXRlcyBmb3IgYmVpbmcgYSBu b2RlDQogICBpbiBjZXJ0YWluIHBsYWNlIG9mIHRoZSB0b3BvbG9neSBhbmQgcmVjZWl2ZSB0aGUg ZGF0YSBhbG9uZyB0aGlzDQogICB0b3BvbG9neSB3aXRob3V0IHRoZSBuZWVkIG9mIGV4Y2hhbmdp bmcgY29udGVudCBhdmFpbGFiaWxpdHkgd2l0aCBpdHMNCiAgIHNpYmxpbmdzLCBhcyBkb25lIGlu IHB1bGwtYmFzZWQgbW9kZS4gSW4gdGhpcyBzZW5zZSB0aGUgaGVhZCBub2RlIGlzDQogICBhY3Rp bmcgYXMgdGhlIHRyYWNrZXIgaW4gdGhlIHB1bGwtYmFzZWQgbW9kZS4gVGhlIHB1c2ggbW9kZSBo YXMgdGhlDQogICBhZHZhbnRhZ2VzIG9mIGxvd2VyIGxhdGVuY3kgYnV0IHRoZSB0b3BvbG9neSBp cyBmcmFnaWxlIHRvIHRoZSBwZWVyDQogICBjaHVybi4gRmV3IGNvbW1lcmNpYWxseSBkZXBsb3ll ZCBzeXN0ZW1zIHVzZSB0aGlzIG1vZGUuDQoNCiAgIEEgbW9yZSBwcmFjdGljYWwgbW9kZSBpcyBh IGh5YnJpZCBwdWxsLXB1c2ggbW9kZSB3aGVyZSB0aGUgcGVlcnMgam9pbg0KICAgdGhlIHN5c3Rl bSBpbiB0aGUgc2FtZSB3YXkgYXMgaW4gcHVzaC1iYXNlZCBtb2RlIHdoaWxlIGFsc28gZXhjaGFu Z2UNCiAgIGNvbnRlbnQgYXZhaWxhYmlsaXR5IHdpdGggaXRzIHNpYmxpbmdzIGZvciByZXRyaWV2 aW5nIHJlcXVzdGVkIGRhdGEsDQogICBqdXN0IGxpa2UgcHVsbC1iYXNlZCBtb2RlLg0KDQogICBJ biBsaXZlIHN0cmVhbWluZywgYWxsIHBlZXJzIGFyZSBpbnRlcmVzdGVkIGluIHRoZSBtZWRpYSBj b21pbmcgZnJvbQ0KICAgYW4gb25nb2luZyBldmVudCwgd2hpY2ggbWVhbnMgdGhhdCBhbGwgcGVl cnMgc2hhcmUgbmVhcmx5IHRoZSBzYW1lDQogICBzdHJlYW1pbmcgY29udGVudCBhdCBhIGdpdmVu IHBvaW50IG9mIHRpbWUuIEluIGxpdmUgc3RyZWFtaW5nLCBzb21lDQogICBwZWVycyBtYXkgc3Rv cmUgdGhlIGxpdmUgbWVkaWEgZm9yIGZ1cnRoZXIgZGlzdHJpYnV0aW9uLCB3aGljaCBpcw0KDQoN Cg0KemhhbmcgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAgICAgICAg ICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxlbSBTdGF0ZW1l bnQgb2YgUFBTUCAgICAgICAgICBOb3ZlbWJlciAyMDExDQoNCg0KICAga25vd24gYXMgVFNUViAo dGltZS1zaGlmdCBUViksIHdoZXJlIHRoZSBzdG9yZWQgbWVkaWEgYXJlIHNlcGFyYXRlZA0KICAg aW50byBjaHVua3MgYW5kIGRpc3RyaWJ1dGVkIGluIGEgVm9ELWxpa2UgbWFubmVyLg0KDQogICBJ biBWb0QsIGRpZmZlcmVudCBwZWVycyB3YXRjaCBkaWZmZXJlbnQgcGFydHMgb2YgdGhlIHJlY29y ZGVkIG1lZGlhDQogICBjb250ZW50IGR1cmluZyBhIHBhc3QgZXZlbnQuIEluIHRoaXMgY2FzZSwg ZWFjaCBwZWVyIGtlZXBzIGFza2luZw0KICAgb3RoZXIgcGVlcnMgd2hpY2ggbWVkaWEgY2h1bmtz IGFyZSBzdG9yZWQgaW4gd2hpY2ggcGVlcnMsIGFuZCB0aGVuDQogICBnZXRzIHRoZSByZXF1aXJl ZCBtZWRpYSBmcm9tIGNlcnRhaW4vc2VsZWN0ZWQgcGVlcnMuDQoNCiAgIFRvIHN1bSB1cCwgaW4g ZXNzZW5jZSwgdGhlcmUgYXJlIHR3byBpbXBvcnRhbnQgZW50aXRpZXMgaW4gUDJQDQogICBzdHJl YW1pbmcsIGkuZS4sIHRyYWNrZXJzIGFuZCBwZWVycyBpbiBQMlAgc3RyZWFtaW5nIHN5c3RlbXMu IFBQU1ANCiAgIGluY2x1ZGVzIHN0YW5kYXJkIHNpZ25hbGluZyBwcm90b2NvbHMgZm9yIHRyYWNr ZXItYmFzZWQgYXJjaGl0ZWN0dXJlcw0KICAgdGhhdCBzdXBwb3J0IGVpdGhlciBsaXZlIG9yIG9m ZmxpbmUgc3RyZWFtaW5nLg0KDQogICBUaGUgUFBTUCBkZXNpZ24gaW5jbHVkZXMgYSBwcm90b2Nv bCBmb3Igc2lnbmFsaW5nIGJldHdlZW4gdHJhY2tlcnMNCiAgIGFuZCBwZWVycyAodGhlIFBQU1Ag InRyYWNrZXIgcHJvdG9jb2wiKSBhbmQgYSBzaWduYWxpbmcgcHJvdG9jb2wgZm9yDQogICBjb21t dW5pY2F0aW9uIGFtb25nIHRoZSBwZWVycyAodGhlIFBQU1AgInBlZXIgcHJvdG9jb2wiKSBhcyBz aG93biBpbg0KICAgRmlndXJlIDEuVGhlIHR3byBwcm90b2NvbHMgZW5hYmxlIHBlZXJzIHRvIHJl Y2VpdmUgc3RyZWFtaW5nIGRhdGENCiAgIHdpdGhpbiB0aGUgdGltZSBjb25zdHJhaW50cyByZXF1 aXJlZCBieSBzcGVjaWZpYyBjb250ZW50IGl0ZW1zLiBUaGUNCiAgIHRyYWNrZXIgcHJvdG9jb2wg aGFuZGxlcyB0aGUgaW5pdGlhbCBhbmQgcGVyaW9kaWMgZXhjaGFuZ2Ugb2YgbWV0YQ0KICAgaW5m b3JtYXRpb24gYmV0d2VlbiB0cmFja2VycyBhbmQgcGVlcnMsIHN1Y2ggYXMgcGVlci1saXN0IGFu ZCBjb250ZW50DQogICBpbmZvcm1hdGlvbi4gVGhlIHBlZXIgcHJvdG9jb2wgY29udHJvbHMgdGhl IGFkdmVydGlzaW5nIGFuZCBleGNoYW5nZQ0KICAgb2YgbWVkaWEgZGF0YSBiZXR3ZWVuIHRoZSBw ZWVycy4NCg0KICAgTm90ZSB0aGF0IGluIHRoZSBwdWxsIG1vZGUgYW5kIGh5YnJpZCBwdWxsLXB1 c2ggbW9kZSwgYm90aCB0cmFja2VyDQogICBwcm90b2NvbCBhbmQgcGVlciBwcm90b2NvbCBjYW4g YmUgdXNlZDsgd2hpbGUgaW4gdGhlIHB1c2ggbW9kZSwgb25seQ0KICAgdHJhY2tlciBwcm90b2Nv bCBpcyB1c2VkLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQp6 aGFuZyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA3LCAyMDEyICAgICAgICAgICAgICAg ICBbUGFnZSAxMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBv ZiBQUFNQICAgICAgICAgIE5vdmVtYmVyIDIwMTENCg0KDQogICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAg ICAgICAgIHwgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICB8 DQogICAgICAgICAgICAgfCAgICAgfCAgICAgICAgICAgIFRyYWNrZXIoSGVhZCBOb2RlKSAgfCAg ICAgICAgIHwNCiAgICAgICAgICAgICB8ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rICAgICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgIHwgICAgIF4gICAgICAgICAg ICAgICAgICAgXiAgICAgICAgICAgICB8DQogICAgICAgICAgICAgfFRyYWNrZXIgfCAgICAgfCBU cmFja2VyICAgICAgICAgICB8VHJhY2tlciAgICAgIHwNCiAgICAgICAgICAgICB8UHJvdG9jb2x8 ICAgICB8IFByb2NvdG9sICAgICAgICAgIHxQcm90b2NvbCAgICAgfA0KICAgICAgICAgICAgIHwg ICAgICAgIHwgICAgIHwgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8DQogICAgICAg ICAgICAgfCAgICAgICAgViAgICAgfCAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICB8ICAgICArLS0tLS0tLS0tKyAgICBQZWVyICAgICArLS0tLS0tLS0tKyAg ICAgICAgfA0KICAgICAgICAgICAgIHwgICAgIHwgICBQZWVyICB8PC0tLS0tLS0tLS0tPnwgICBQ ZWVyICB8ICAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgKy0tLS0tLS0tLSsgICBQcm90b2Nv bCAgKy0tLS0tLS0tLSsgICAgICAgIHwNCiAgICAgICAgICAgICB8ICAgICAgIHwgXiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgfCB8 UGVlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgfCAg ICAgICB8IHxQcm90b2NvbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICB8ICAgICAgIFYgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgIHwgICAgICstLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICAgICAgfCAgICAgfCAgICAgIFBlZXIgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICB8ICAgICArLS0tLS0tLS0tLS0tLS0tKyAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAg ICAgICAgICAgICAgRmlndXJlIDEgUFBTUCBTeXN0ZW0gQXJjaGl0ZWN0dXJlDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQp6aGFuZyAgICAgICAgICAgICAg ICAgICBFeHBpcmVzIE1heSA3LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBvZiBQUFNQICAgICAgICAgIE5v dmVtYmVyIDIwMTENCg0KDQoNCg0KNS4gVXNlIGNhc2VzIG9mIFBQU1ANCg0KNS4xLiBXb3JsZHdp ZGUgcHJvdmlzaW9uIG9mIG9wZW4gUDJQIGxpdmUgc3RyZWFtaW5nIHNlcnZpY2VzDQoNCiAgIFRo ZSBjb29wZXJhdGl2ZSBjb250ZW50IHByb3ZpZGVycyBjYW4gZWFzaWx5IGV4cGFuZCB0aGUgYnJv YWRjYXN0aW5nDQogICBzY2FsZSB3aXRoIFBQU1AuIEluIGZpZ3VyZSAyIHNob3dzIHRoZSBjYXNl IHRoYXQgcHJvdmlkZXIgQQ0KICAgYnJvYWRjYXN0cyB0aGUgcHJvZ3JhbSB3aXRoIHRoZSBoZWxw IG9mIHByb3ZpZGVyIEIgYW5kIEMgZm9yIGEgd2lkZXINCiAgIGNvdmVyYWdlLiBUaGUgY29udGVu dCBwcm92aWRlcnMgb2Z0ZW4gZGVwbG95IGluLW5ldHdvcmsgcGVlcnMgY2FsbGVkDQogICBzdXBl ci1ub2RlcyAoU04gZm9yIHNob3J0KSB3aXRoIGJldHRlciBzdGFiaWxpdHkgYW5kIGhpZ2hlciBz dG9yYWdlDQogICBhbmQgYmFuZHdpZHRoIGNvbXBhcmVkIHdpdGggdXNlciBwZWVycyBmb3IgYmV0 dGVyIFFvUy4gIFRoZQ0KICAgaW50ZXJhY3Rpb24gYmV0d2VlbiBBJ3MgdHJhY2tlciBhbmQgdmVu ZG9yIEIgYW5kIHZlbmRvciBDJ3MgU05zIGNhbg0KICAgYmUgbm9ybWFsaXplZCB1c2luZyB0cmFj a2VyIHByb3RvY29sOyBhbmQgcGVlciBwcm90b2NvbCBjYW4gYmUgdXNlZA0KICAgYW1vbmcgU05z L3BlZXJzIHNwcmVhZCBpbiBkaWZmZXJlbnQgdmVuZG9ycy4NCg0KICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICstLS0tLS0t LS0tLS0+fCBBJ3MgICAgICBUcmFja2VyIHw8LS0tLS0tLS0tLSsgICAgICAgICB8DQogICB8ICAg ICAgICAgICAgfCAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgfCAg ICAgICAgIHwNCiAgIHwgICAgIFRyYWNrZXJ8ICAgICAgICAgICAgICAgIF4gICAgICAgICAgICAg IF4gICAgICAgICAgICB8ICAgICAgICAgfA0KICAgfCAgICBQcm90b2NvbHwgICAgICAgICBUcmFj a2VyfCAgICAgICAgICAgICAgfFRyYWNrZXIgICAgIHxUcmFja2VyICB8DQogICB8ICAgICAgICAg ICAgfCAgICAgICAgUHJvdG9jb2x8ICAgICAgICAgICAgICB8UHJvdG9jb2wgICAgfFByb3RvY29s IHwNCiAgIHwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAg ICAgICAgICB8ICAgICAgICAgfA0KICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICB8DQogICB8ICAgICAgICAgICAgdiAg ICAgICAgICAgICAgICB2ICAgICAgICAgICAgICB2ICAgICAgICAgICAgdiAgICAgICAgIHwNCiAg IHwgICAgICArLS0tLS0tKyBQZWVyICAgICstLS0tLS0rICAgICAgICAgICAgKy0tLS0tLSsgICAg Ky0tLS0tLSsgICAgfA0KICAgfCAgICAgIHwgQidzICB8PC0tLS0tLS0+fCBCJ3MgIHwgICAgICAg ICAgICB8IEMncyAgfCAgICB8IEMncyAgfCAgICB8DQogICB8ICAgICAgfCBTTjEgIHxQcm90b2Nv bCB8IFNOMiAgfCAgICAgICAgICAgIHwgU04xICB8ICAgIHwgU04yICB8ICAgIHwNCiAgIHwgICAg ICArLS0tLS0tKyAgICAgICAgICstLS0tLS0rICAgICAgICAgICAgKy0tLS0tLSsgICAgKy0tLS0t LSsgICAgfA0KICAgfCAgICAgICAgIF4gIF4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXiBeICAgICAgICB8DQogICB8ICAgICAgICAgfCAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgIHwNCiAgIHwgICAgICAgICB8 ICB8IFBlZXIgUHJvdG9jb2wgICAgICAgICAgICAgICAgUGVlciBQcm90b2NvbHwgfCAgICAgICAg fA0KICAgfCBQZWVyICAgIHwgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tLS0tKyB8UGVlciAgICB8DQogICB8IFByb2NvdG9sfCAgICAgICAgICAgICAgICB8ICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgIHxwcm90b2NvbHwNCiAgIHwgICAgICAgICB8ICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgfA0KICAg fCAgICAgICAgIHwgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg ICB8ICAgICAgICB8DQogICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgIHwgICAgICAgIHwNCiAgIHwgICAgICAgICB2ICAgICAgICAgICAg ICAgIHYgICAgICAgICAgICAgIHYgICAgICAgICAgICAgICAgdiAgICAgICAgfA0KICAgfCAgICAg ICstLS0tLS0rIFBlZXIgICAgKy0tLS0tLSsgICAgKy0tLS0tLS0tLSsgIFBlZXIgICArLS0tLS0t LS0tKyB8DQogICB8ICAgICAgfCBBJ3MgIHw8LS0tLS0tPiB8IEIncyAgfCAgICB8QSdzICAgICAg fDwtLS0tLS0+IHxDJ3MgICAgICB8IHwNCiAgIHwgICAgICB8IFVzZXIxfFByb3RvY29sIHwgVXNl cjJ8ICAgIHwgVXNlcjEgICB8UHJvdG9jb2wgfCBVc2VyMiAgIHwgfA0KICAgfCAgICAgICstLS0t LS0rICAgICAgICAgKy0tLS0tLSsgICAgKy0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tKyB8 DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICBGaWd1 cmUgMiBDb29wZXJhdGl2ZSBWZW5kb3JzIEludGVyYWN0aW9uDQoNCg0KemhhbmcgICAgICAgICAg ICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxlbSBTdGF0ZW1lbnQgb2YgUFBTUCAgICAgICAg ICBOb3ZlbWJlciAyMDExDQoNCg0KNS4yLiBDRE4gc3VwcG9ydGluZyBQMlAgc3RyZWFtaW5nDQoN CiAgIFRoaXMgc2NlbmFyaW8gaXMgc2ltaWxhciB0byB1c2UgY2FzZSAxIGV4Y2VwdCB0aGF0IHRo ZSBpbnRlcm1lZGlhdGUNCiAgIFNOcyBhcmUgcmVwbGFjZWQgYnkgM3JkIHBhcnR5IENETiBzdXJy b2dhdGVzIHdpdGggUFBTUC4gVGhlIFAyUA0KICAgc3RyZWFtaW5nIHZlbmRvcnMgQSBhbmQgQiBj YW4gcmVudCBDRE4gc3Vycm9nYXRlcyB0byBwcm92aWRlIGhpZ2hlcg0KICAgUW9TIHNlcnZpY2Vz IGZvciBWSVAgdXNlcnMgdGhhbiBzZXJ2aWNlcyBwcm92aWRlcyBieSBvbmx5IG9yZGluYXJ5DQog ICBwZWVycy4gVGhlIGludGVyYWN0aW9uIGFtb25nIHRoZXNlIG5ldHdvcmsgZW50aXRpZXMgYXJl IHNob3duIGluDQogICBGaWd1cmUgMy4gVGhlIENETiBub2RlcyB0YWxrIHdpdGggdGhlIGRpZmZl cmVudCB0cmFja2VycyBhbmQgcGVlcnMNCiAgIHdpdGggdGhlIHVuaWZvcm0gVHJhY2tlciBhbmQg cGVlciBwcm90b2NvbHMuIEl0IGNhbiBhbHNvIGNvbW11bmljYXRlDQogICB3aXRoIGVuZCB1c2Vy cyB1c2luZyBIVFRQIGZvciBsZWdhY3kgZXF1aXBtZW50cy4gVGhlIGludGVybmFsDQogICBpbnRl cmFjdGlvbiBvZiBDRE4gbm9kZXMgY2FuIGJlIGV4ZWN1dGVkIGJ5IGVpdGhlciBvcmlnaW5hbCBp bnRlcm5hbA0KICAgcHJvdG9jb2wgb3IgbmV3IHBlZXIgcHJvdG9jb2wuIFRoZSBsYXR0ZXIgaXMg dXNlZCB3aGVuIGJ1aWxkaW5nIGEgbmV3DQogICBDRE4gc3lzdGVtIHN1cHBvcnRpbmcgc3RyZWFt aW5nIGFwcGxpY2F0aW9ucyB3aXRoIGxvdyBjb3N0IGRlcGxveWluZw0KICAgUDJQIGRlbGl2ZXJ5 IGluc2lkZSB0aGUgbmV0d29yay4NCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgIHwgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0t LSsgICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICstLS0tLT58IEEncyBUcmFja2VyIHwg ICAgfCAgQidzIFRyYWNrZXIgfDwtLS0rICAgICAgICB8DQogICB8ICAgICAgICAgICAgfCAgICAg ICstLS0tLS0tLS0tLS0tKyAgICArLS0tLS0tLS0tLS0tLS0rICAgIHwgICAgICAgIHwNCiAgIHwg ICAgIFRyYWNrZXJ8ICAgICAgICAgICAgICBeICBeICAgICAgICBeICAgIF4gICAgICAgICAgICAg fCAgICAgICAgfA0KICAgfCAgICBQcm90b2NvbHwgICAgICAgVHJhY2tlcnwgIHxUcmFja2VyIHwg ICAgfFRyYWNrZXIgICAgICB8VHJhY2tlciB8DQogICB8ICAgICAgICAgICAgfCAgICAgIFByb3Rv Y29sfCAgfFByb3RvY29sfCAgICB8UHJvdG9jb2wgICAgIHxQcm90b2NvbHwNCiAgIHwgICAgICAg ICAgICB8ICAgICAgICAgICAgICB8ICB8ICAgICAgICB8ICAgIHwgICAgICAgICAgICAgfCAgICAg ICAgfA0KICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwgIHwgICAgICAgIHwgICAgfCAg ICAgICAgICAgICB8ICAgICAgICB8DQogICB8ICAgICAgICAgICAgdiAgICAgICAgICAgICAgdiAg fCAgICAgICAgfCAgICB2ICAgICAgICAgICAgIHYgICAgICAgIHwNCiAgIHwgICAgICArLS0tLS0t KyBQZWVyICAgKy0tLS0tLSt8ICAgICAgICB8ICArLS0tLS0tK0ludGVybmFsKy0tLS0tLSsgfA0K ICAgfCAgICAgIHwgQ0ROICB8PC0tLS0tLT58IENETiAgfHwgICAgICAgIHwgIHwgQ0ROICB8PC0t LS0tPiB8IENETiAgfCB8DQogICB8ICAgICAgfCBOb2RlMXxQcm90b2NvbHwgTm9kZTJ8fCAgICAg ICAgfCAgfCBOb2RlM3xQcm90b2NvbHwgTm9kZTR8IHwNCiAgIHwgICAgICArLS0tLS0tKyAgICAg ICAgKy0tLS0tLSt8ICAgICAgICB8ICArLS0tLS0tKyAgICAgICAgKy0tLS0tLSsgfA0KICAgfCAg ICAgICAgIF4gIF4gICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgIF4gICAgICAgICBe ICAgICAgICB8DQogICB8ICAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAg ICAgICAgfCAgICAgICAgIHwgICAgICAgIHwNCiAgIHwgICAgICAgICB8ICB8IFBlZXIgUHJvdG9j b2wgICB8ICAgICAgICB8ICAgSFRUUCB8ICAgICAgICAgfCAgICAgICAgfA0KICAgfCBQZWVyICAg IHwgICstLS0tLS0tLS0tLS0tKyAgIHwgICAgICAgIHwgKy0tLS0tLSsgICAgICAgICB8IFBlZXIg ICB8DQogICB8IFByb2NvdG9sfCAgICAgICAgICAgICAgICB8ICAgfCAgICAgICAgfCB8IFByb3Rv Y29sICAgICAgIHxwcm90b2NvbHwNCiAgIHwgICAgICAgICB8ICAgICAgICAgICAgICAgIHwgKy0r ICAgICAgICB8IHwgICAgICAgICAgICAgICAgfCAgICAgICAgfA0KICAgfCAgICAgICAgIHwgICAg ICAgICAgICAgICAgfCB8ICAgICAgICAgIHwgfCAgICAgICAgICAgICAgICB8ICAgICAgICB8DQog ICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICB8IHwgICAgICAgICAgfCB8ICAgICAgICAgICAg ICAgIHwgICAgICAgIHwNCiAgIHwgICAgICAgICB2ICAgICAgICAgICAgICAgIHYgdiAgICAgICAg ICB2IHYgICAgICAgICAgICAgICAgdiAgICAgICAgfA0KICAgfCAgICAgICstLS0tLS0rIFBlZXIg ICAgKy0tLS0tLSsgICAgKy0tLS0tLS0tLSsgIFBlZXIgICArLS0tLS0tLS0tKyB8DQogICB8ICAg ICAgfCBBJ3MgIHw8LS0tLS0tPiB8IEEncyAgfCAgICB8QidzICAgICAgfDwtLS0tLS0+IHxCJ3Mg ICAgICB8IHwNCiAgIHwgICAgICB8IFVzZXIxfFByb3RvY29sIHwgVXNlcjJ8ICAgIHwgVXNlcjMg ICB8UHJvdG9jb2wgfCBVc2VyNCAgIHwgfA0KICAgfCAgICAgICstLS0tLS0rICAgICAgICAgKy0t LS0tLSsgICAgKy0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tKyB8DQogICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzIENETiBTdXBw b3J0aW5nIFAyUCBTdHJlYW1pbmcNCg0KDQoNCnpoYW5nICAgICAgICAgICAgICAgICAgIEV4cGly ZXMgTWF5IDcsIDIwMTIgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgIFByb2JsZW0gU3RhdGVtZW50IG9mIFBQU1AgICAgICAgICAgTm92ZW1iZXIgMjAx MQ0KDQoNCg0KDQo1LjMuIFBQU1Agc3VwcG9ydGluZyBjcm9zcy1zY3JlZW4gc3RyZWFtaW5nIGlu IGhldGVyb2dlbmVvdXMgZW52aXJvbm1lbnQNCg0KICAgSW4gdGhpcyBzY2VuYXJpbyBQQywgU2V0 Ym94L1RWIGFuZCBtb2JpbGUgdGVybWluYWxzIGZyb20gYm90aCBmaXhlZA0KICAgbmV0d29yayBh bmQgbW9iaWxlIG5ldHdvcmsgc2hhcmUgdGhlIGNvbnRlbnQgdGhleSBzdG9yZS9jYWNoZS4gUGVl cnMNCiAgIGZyb20gaGV0ZXJvZ2VuZW91cyBuZXR3b3Jrcw0KDQogICBXaXRoIFBQU1AscGVlcnMg Y2FuIGlkZW50aWZ5IHRoZSB0eXBlcyBvZiBhY2Nlc3MgbmV0d29ya3MsIGF2ZXJhZ2UNCiAgIGxv YWQsIHBlZXIgYWJpbGl0aWVzIGFuZCBnZXQgdG8ga25vdyB3aGF0IGNvbnRlbnQgb3RoZXIgcGVl cnMgaGF2ZQ0KICAgKHBvdGVudGlhbGx5IHdpdGggdGhlIGNvbnZlcnNpb24gb2YgdGhlIGNvbnRl bnQgYXZhaWxhYmlsaXR5DQogICBleHByZXNzaW9uIGluIGRpZmZlcmVudCBuZXR3b3JrcykgZXZl biBpbiBkaWZmZXJlbnQgbmV0d29yaw0KICAgY29uZGl0aW9ucyBhcyBzaG93biBpbiBGaWd1cmUg NC4gVGhlc2UgaW5mb3JtYXRpb24gd2lsbCBwbGF5IGFuDQogICBpbXBvcnRhbnQgcm9sZSBvbiBz ZWxlY3Rpbmcgc3VpdGFibGUgcGVlcnMsIGUuZy4sIGEgUEMgb3IgU1RCIG5vZGUgaXMNCiAgIG1v cmUgbGlrZWx5IHRvIGJlIHNlbGVjdGVkIHRvIHByb3ZpZGUgc3RhYmxlIGNvbnRlbnQgZm9yIG1v YmlsZSBub2RlczsNCiAgIGEgbW9iaWxlIHBlZXIgd2l0aGluIGEgaGlnaC1sb2FkIGJhc2Ugc3Rh dGlvbiBpcyB1bmxpa2VseSB0byBiZQ0KICAgc2VsZWN0ZWQsIHdoaWNoIG1heSBsZWFkIHRvIGhp Z2hlciBsb2FkIG9uIHRoZSBiYXNlIHN0YXRpb24uDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICB8ICAgICAgVHJhY2tlciBQcm90b2NvbCAgKy0tLS0tLS0tLSsgICBUcmFj a2VyIFByb3RvY29sICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICstLS0tLS0tLS0tLS0tPiB8 IFRyYWNrZXIgfDwtLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgfA0KICAgfCAgICAgICAg fCAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICB8DQogICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICBeICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgIHwNCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgfA0KICAgfCAgICAgICAgfCAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8DQog ICB8ICAgICAgICBWICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ViAgICAgICAgICAgIHwNCiAgIHwgICAgKy0tLS0tLSsgICAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgfA0KICAgfCAgICB8ICBTVEIgfCAgICAgICAg ICAgVHJhY2tlciBQcm90b2NvbCAgICAgICB8TW9iaWxlIFBob25lfCAgICAgICB8DQogICB8ICAg ICstLS0tLS0rICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0r ICAgICAgIHwNCiAgIHwgICAgICAgIF4gICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICBeICAgICAgICAgICAgfA0KICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICB8ICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg IHwNCiAgIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgfA0KICAgfCAgICAgICAgfFBlZXIgUHJvdG9jb2wgICstLS0tLS0t LS0rICAgIFBlZXIgUHJvdG9jb2wgIHwgICAgICAgICAgICB8DQogICB8ICAgICAgICArLS0tLS0t LS0tLS0tLT4gfCAgICBQQyAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgIHwNCiAg IHwgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAg IEZpZ3VyZSA0IEhldGVyb2dlbmVvdXMgUDJQIFN0cmVhbWluZyBJbnRlcmFjdGlvbiB3aXRoIFBQ U1ANCg0KDQoNCjUuNC4gU3VwcG9ydGluZyBQMlAgc3RyZWFtaW5nIGluIGNlbGx1bGFyIG1vYmls ZSBuZXR3b3JrDQoNCiAgIEluIGEgY2VsbHVsYXIgbW9iaWxlIGVudmlyb25tZW50IGxpa2UgM0cg b3IgNEcsIHdpdGggdGhlIGluY3JlYXNlIGluDQogICBiYW5kd2lkdGggYW5kIHNtYXJ0IG1vYmls ZSB0ZXJtaW5hbCBjYXBhYmlsaXRpZXMsIFAyUCAoaW5jbHVkaW5nDQoNCg0KemhhbmcgICAgICAg ICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2UgMTZd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxlbSBTdGF0ZW1lbnQgb2YgUFBTUCAgICAg ICAgICBOb3ZlbWJlciAyMDExDQoNCg0KICAgUDJQc3RyZWFtaW5nICkgaXMgZWFzaWVyIHRvIGJl IHJlYWxpemVkIHRoYW4gYmVmb3JlLiBJbiBhIHByb3ZpbmNpYWwNCiAgIG5ldHdvcmsgb2YgQ2hp bmEgTW9iaWxlLCBQMlAgaGFzIGFjY291bnRlZCBmb3IgbW9yZSB0aGFuIDMwDQogICBwZXJjZW50 YWdlIG9mIHRoZSB0cmFmZmljLCByYW5rZWQgc2Vjb25kLg0KDQogICBOb3RlIHRoYXQgdGhlIG1v YmlsZSB0ZXJtaW5hbHMgYXJlIG5vdCBjb21wdWxzb3JpbHkgdG8gYmUgcGVlcnMuIEhlcmUNCiAg IHRoZXkgYWN0IGFzIGNsaWVudHMuIE5ldHdvcmsgcGVlcnMgd2hvIGFyZSBkZXBsb3llZCBieSB0 aGUgSVNQcyBvcg0KICAgb3BlcmF0b3JzIGFuZCBtb2JpbGUgcGVlcnMgd2l0aCBXaUZpIGNvbm5l Y3Rpb25zIGFyZSBtb3JlIGxpa2VseSB0bw0KICAgYmUgc2VsZWN0ZWQuIEZvciBleGFtcGxlLCBp biAzR1BQLCB0aGVyZSBpcyBhIFAyUCBDb250ZW50DQogICBEaXN0cmlidXRpb24gU2VydmljZSAo UDJQIENEUykgd29yayBpdGVtIHdvcmtpbmcgb24gdGhlIHJlcXVpcmVtZW50DQogICBvZiBtb2Jp bGUgb3BlcmF0b3JzIHRvIHByZWZlciB1c2UgZGVwbG95ZWQgbmV0d29yay1zaWRlIGVxdWlwbWVu dHMNCiAgIChlLmcuLCBzZXJ2aW5nIGdhdGV3YXlzIG9yIEdHU05zLCBvbmUgYWNjZXNzIHBvaW50 IGZyb20gY2VsbHVsYXINCiAgIG1vYmlsZSBuZXR3b3JrIHRvIHRoZSBJbnRlcm5ldCkgdG8gYWN0 IGFzIHN1cGVyLXBlZXJzIHdoZW4gdGhlcmUgYXJlDQogICBubyBlbm91Z2ggZWxpZ2libGUgcGVl cnMgdG8gcmVhbGl6ZSBQMlAgc3RyZWFtaW5nW1AyUCBDRFNdLiBCZWNhdXNlDQogICB0aGV5IGFy ZSBkZXBsb3llZCBieSB0aGUgb3BlcmF0b3JzLCB0aGUgc3RhYmlsaXR5IGFuZCBzdG9yYWdlIHNp emUNCiAgIGFyZSBiZXR0ZXIgZ3VhcmFudGVlZCB0aGFuIG9yZGluYXJ5IHBlZXJzLg0KDQogICBT aW1pbGFyIHdpdGggY2FzZSA1LjMsIFBQU1AgdHJhY2tlciBwcm90b2NvbCB3aWxsIGhlbHAgdG8g aWRlbnRpZnkNCiAgIGFuZCByZXR1cm4gdGhlIHN1cGVyLXBlZXJzIGluIHRoZSBwZWVyLWxpc3Qg d2l0aCBwcmVmZXJlbmNlLiBJZg0KICAgbW9iaWxlIHRlcm1pbmFscyBhcmUgbm90IGVsaWdpYmxl IHRvIGJlIHBlZXJzLCB0aGV5IGNhbiBzaW1wbHkNCiAgIHJlY2VpdmUgZGF0YSBmcm9tIHRoZXNl IHN1cGVyLXBlZXJzIHdpdGhvdXQgY29udHJpYnV0aW5nIGFueSBkYXRhIHRvDQogICBvdGhlcnMu DQoNCjUuNS4gQ2FjaGUgc2VydmljZSBzdXBwb3J0aW5nIFAyUCBzdHJlYW1pbmcNCg0KICAgVG8g Z3JlYXRseSBkZWNyZWFzZSB0aGUgaW50ZXItbmV0d29yayB0cmFmZmljIGFuZCBpbmNyZWFzZSB1 c2VyDQogICBleHBlcmllbmNlIGluIFAyUCBzdHJlYW1pbmcgc2VydmljZXMsIGFuIElTUCBtYXkg ZGVwbG95IGNhY2hlIHNlcnZpY2UNCiAgIGluIGl0cyBuZXR3b3JrLg0KDQogICBJbiBGaWd1cmUg NSwgV2hlbiBwZWVycyByZXF1ZXN0IHRoZSBQMlAgc3RyZWFtaW5nIGRhdGEsIHRoZSBjYWNoZQ0K ICAgbm9kZXMgaW50ZXJjZXB0IHRoZSByZXF1ZXN0cyBhbmQgYXNrIGZvciB0aGUgZnJlcXVlbnRs eSB2aXNpdGVkDQogICBjb250ZW50IChvciBwYXJ0IG9mKSBvbiBiZWhhbGYgb2YgdGhlIHVzZXIg cGVlcnMuIFRvIGRvIHRoaXMsIGl0DQogICByZXF1ZXN0cyBwZWVyLWxpc3QgdG8gdGhlIHRyYWNr ZXIgYW5kIHRoZSB0cmFja2VyIHJlcGxpZXMgd2l0aA0KICAgKG91dHdhcmQpIHBlZXJzLiBBZnRl ciB0aGUgY2FjaGUgbm9kZXMgZXhjaGFuZ2UgZGF0YSB3aXRoIHRoZXNlIHBlZXJzLA0KICAgaXQg Y2FuIHJlcG9ydCB3aGF0IGl0IGNhY2hlIHRvIHRoZSB0cmFja2VyIGxpa2UgYSBub3JtYWwgcGVl ciBhbmQNCiAgIHNlcnZlIG90aGVyIHJlcXVlc3RpbmcgcGVlcnMgaW5zaWRlLg0KDQogICBUaGUg Y2FjaGUgbm9kZXMgbmVlZG4ndCB1cGRhdGUgdGhlaXIgbGlicmFyeSB3aGVuIG5ldyBhcHBsaWNh dGlvbnMNCiAgIHN1cHBvcnRpbmcgUFBTUCBhcmUgaW50cm9kdWNlZCwgd2hpY2ggZW5hYmxlIHRo ZSBjYWNoZSBub2RlcyBzcGVuZA0KICAgbGVzcyBjb3N0IHRvIHN1cHBvcnQgbW9yZSBhcHBsaWNh dGlvbnMuDQoNCg0KDQoNCg0KDQoNCg0KDQp6aGFuZyAgICAgICAgICAgICAgICAgICBFeHBpcmVz IE1heSA3LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAxN10NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBvZiBQUFNQICAgICAgICAgIE5vdmVtYmVyIDIwMTEN Cg0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgMDpUcmFja2VyIFByb3RvY29s ICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICArLS0t LS0tLS0tLS0tLS0tLT4gfCBUcmFja2VyIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgIHwgIHwgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICAgXiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHwgICAg ICAgICAgICAgICAgICAgIDI6IHwgVHJhY2tlciBQcm90b2NvbCAgICAgICAgICAgICAgICAgICAg fA0KICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICB8ICB8ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHwgICAgICAgICAgICAgKy0tLS0t LS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgfCAgfCAgICAg ICAgICAgICB8ICAgICAgICAgViAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICB8ICB8ICAgICAgICAgICAgIHwgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgIHwgIHwgICstLS0tLS0tLS0tfC0tLT4gfCBDYWNoZSAgIHw8LS0t LS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgfA0KICAgfCAgfCAgfCAgICAgICAgICB8ICAgICAr LS0tLS0tLS0tKyAgIDEsNDogVHJhY2tlci9QZWVyfCAgICAgICAgICB8DQogICB8ICB8ICB8Mzog UGVlciAgIHwgICAgICAgICAgICAgICAgICAgICAgIFByb3RvY29sICAgICB8ICAgICAgICAgIHwN CiAgIHwgIHwgIHwgUHJvdG9jb2wgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgfA0KICAgfCAgfCAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICB8DQogICB8ICB8ICB8ICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIHwNCiAgIHwgIFYgIFYgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFYgICAgICAgICAgfA0K ICAgfCAgKy0tLS0tLS0tLS0tKyB8ICAgICAgICBJU1AgRG9tYWluICAgICAgICAgICAgICstLS0t LS0tLS0tLS0rICB8DQogICB8ICB8ICBPdXR3YXJkICB8IHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgIEluc2lkZSAgIHwgIHwNCiAgIHwgIHwgIFBlZXIgICAgIHwgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgUGVlciAgICAgfCAgfA0KICAgfCAgKy0tLS0tLS0t LS0tKyB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0rICB8DQog ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCg0KICAgICAgICAgICBGaWd1cmUgNSBDYWNoZSBTZXJ2aWNlIFN1cHBvcnRp bmcgU3RyZWFtaW5nIHdpdGggUFBTUA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KemhhbmcgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAg ICAgICAgICAgICAgW1BhZ2UgMThdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxlbSBT dGF0ZW1lbnQgb2YgUFBTUCAgICAgICAgICBOb3ZlbWJlciAyMDExDQoNCg0KDQoNCjYuIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoZSBwcm9i bGVtIHN0YXRlbWVudCBhcm91bmQgUGVlci10by1QZWVyDQogICBzdHJlYW1pbmcgcHJvdG9jb2xz IHdpdGhvdXQgc3BlY2lmeWluZyB0aGUgcHJvdG9jb2xzLiBUaGUgcHJvdG9jb2wNCiAgIHNwZWNp ZmljYXRpb24gaXMgZGVmZXJyZWQgdG8gb3RoZXIgZG9jdW1lbnRzIHVuZGVyIGRldmVsb3BtZW50 IGluIHRoZQ0KICAgUFBTUCB3b3JraW5nIGdyb3VwLiBIb3dldmVyIHdlIGJlbGlldmUgaXQgaXMg aW1wb3J0YW50IGZvciB0aGUgcmVhZGVyDQogICB0byB1bmRlcnN0YW5kIGFyZWFzIG9mIHNlY3Vy aXR5IGNhdXNlZCBieSB0aGUgUDJQIG5hdHVyZSBvZiB0aGUNCiAgIHByb3Bvc2VkIHNvbHV0aW9u LiBUaGUgbWFpbiBpc3N1ZSBpcyB0aGUgdXNhZ2Ugb2YgdW50cnVzdGVkIGVudGl0aWVzDQogICAo cGVlcnMpIGZvciBzZXJ2aWNlIHByb3Zpc2lvbmluZy4NCg0KICAgTWFsaWNpb3VzIHBlZXJzIG1h eSwgZm9yIGV4YW1wbGU6DQoNCiAgIC0gSXNzdWUgZGVuaWFsIG9mIHNlcnZpY2UgKERPUykgYXR0 YWNrcyB0byB0aGUgdHJhY2tlcnMgYnkgc2VuZGluZw0KICAgbGFyZ2UgYW1vdW50IG9mIHJlcXVl c3RzIHdpdGggdGhlIHRyYWNrZXIgcHJvdG9jb2w7DQoNCiAgIC0gSXNzdWUgZmFrZSBpbmZvcm1h dGlvbiBvbiBiZWhhbGYgb2Ygb3RoZXIgcGVlcnM7DQoNCiAgIC0gSXNzdWUgZmFrZSBpbmZvcm1h dGlvbiBhYm91dCBhdmFpbGFibGUgY29udGVudDsNCg0KICAgLSBJc3N1ZSBmYWtlIGluZm9ybWF0 aW9uIGFib3V0IGNodW5rIGF2YWlsYWJpbGl0eTsNCg0KICAgTWFsaWNpb3VzIHBlZXJzL3RyYWNr ZXJzIG1heSwgZm9yIGV4YW1wbGU6DQoNCiAgIC0gSXNzdWUgcmVwbHkgaW5zdGVhZCBvZiB0aGUg cmVndWxhciB0cmFja2VyIChtYW4gaW4gdGhlIG1pZGRsZQ0KICAgYXR0YWNrKS4NCg0KICAgVGhl IFBQU1AgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMsIGUuZy4sIHRoZSB0cmFja2VyIHByb3RvY29s IGFuZCB0aGUNCiAgIHBlZXIgcHJvdG9jb2wsIHdpbGwgZG9jdW1lbnQgdGhlIGV4cGVjdGVkIHRo cmVhdHMgYW5kIGhvdyB0aGV5IHdpbGwNCiAgIGJlIG1pdGlnYXRlZCBmb3IgZWFjaCBwcm90b2Nv bCwgYnV0IGFsc28gY29uc2lkZXJhdGlvbnMgb24gdGhyZWF0cw0KICAgYW5kIG1pdGlnYXRpb25z IHdoZW4gY29tYmluaW5nIGJvdGggcHJvdG9jb2xzIGluIGFuIGFwcGxpY2F0aW9uLiBUaGlzDQog ICB3aWxsIGluY2x1ZGUgcHJpdmFjeSBvZiB0aGUgdXNlcnMsIHByb3RlY3Rpb24gb2YgdGhlIGNv bnRlbnQNCiAgIGRpc3RyaWJ1dGlvbiwgYnV0IG5vdCBwcm90ZWN0aW9uIG9mIHRoZSBjb250ZW50 IGJ5IERpZ2l0YWwgUmlnaHRzDQogICBNYW5hZ2VtZW50IChEUk0pLg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQp6aGFuZyAgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1heSA3LCAyMDEyICAg ICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQcm9ibGVt IFN0YXRlbWVudCBvZiBQUFNQICAgICAgICAgIE5vdmVtYmVyIDIwMTENCg0KDQoNCg0KNy4gSUFO QSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGlzIGRvY3VtZW50IGhhcyBubyBhY3Rpb25zIGZvciBJ QU5BLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQp6aGFuZyAgICAgICAgICAgICAgICAg ICBFeHBpcmVzIE1heSA3LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAyMF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBvZiBQUFNQICAgICAgICAgIE5vdmVt YmVyIDIwMTENCg0KDQoNCg0KOC4gQWNrbm93bGVkZ21lbnRzDQoNCiAgIFdlIHdvdWxkIGxpa2Ug dG8gYWNrbm93bGVkZ2UgdGhlIGZvbGxvd2luZyBwZW9wbGUgd2hvIHByb3ZpZGVkIHJldmlldywN CiAgIGZlZWRiYWNrIGFuZCBzdWdnZXN0aW9ucyB0byB0aGlzIGRvY3VtZW50OiBNLiBTdGllbWVy bGluZzsgQy4gU2NobWlkdDsNCiAgIEQuIEJyeWFuOyBFLiBNYXJvY2NvOyBWLiBHdXJiYW5pOyBS LiBFdmVuOyBILiBaaGFuZzsgTC4gWGlhbzsgQy4NCiAgIFdpbGxpYW1zOyBWLiBQYXN1YWw7IEQu IFpoYW5nOyBKLiBMZWkuDQoNCiAgIFRoaXMgZG9jdW1lbnQgd2FzIHByZXBhcmVkIHVzaW5nIDIt V29yZC12Mi4wLnRlbXBsYXRlLmRvdC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQp6aGFuZyAgICAgICAg ICAgICAgICAgICBFeHBpcmVzIE1heSA3LCAyMDEyICAgICAgICAgICAgICAgICBbUGFnZSAyMV0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICBQcm9ibGVtIFN0YXRlbWVudCBvZiBQUFNQICAgICAg ICAgIE5vdmVtYmVyIDIwMTENCg0KDQoNCg0KOS4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0KDQog ICBbUkZDIDU2OTNdIEFwcGxpY2F0aW9uLUxheWVyIFRyYWZmaWMgT3B0aW1pemF0aW9uIChBTFRP KSBQcm9ibGVtDQogICAgICAgICAgICAgU3RhdGVtZW50LCBFLiBNYXJvY2NvIGV0IGFsLA0KICAg ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvcmZjNTY5My8NCg0KICAg W0Npc2NvXSBDaXNjbyBWaXN1YWwgTmV0d29ya2luZyBJbmRleDogRm9yZWNhc3QgYW5kIE1ldGhv ZG9sb2d5LA0KICAgICAgICAgICAgIDIwMDktMjAxNCwNCiAgICAgICAgICAgICBodHRwOi8vd3d3 LmNpc2NvLmNvbS9lbi9VUy9zb2x1dGlvbnMvY29sbGF0ZXJhbC9uczM0MS9uczUyNQ0KICAgICAg ICAgICAgIC9uczUzNy9uczcwNS9uczgyNy93aGl0ZV9wYXBlcl9jMTEtDQogICAgICAgICAgICAg NDgxMzYwX25zODI3X05ldHdvcmtpbmdfU29sdXRpb25zX1doaXRlX1BhcGVyLmh0bWwNCg0KICAg W1BQTGl2ZV0gaHR0cDovL3d3dy5wcGxpdmUuY29tDQoNCiAgIFtWb0RdIFlhbiBIdWFuZyBldCBh bCxDaGFsbGVuZ2VzLCAiRGVzaWduIGFuZCBBbmFseXNpcyBvZiBhIExhcmdlLQ0KICAgICAgICAg ICAgIHNjYWxlIFAyUC1Wb0QgU3lzdGVtIiwgU2lnY29tbTA4Lg0KDQogICBbQ05OXSBodHRwOi8v d3d3LmNubi5jb20NCg0KICAgW1BQU3RyZWFtXSBodHRwOi8vd3d3LnBwc3RyZWFtLmNvbQ0KDQog ICBbVVVTZWVdIGh0dHA6Ly93d3cudXVzZWUuY29tDQoNCiAgIFtDTlRWXSBodHRwOi8vd3d3LmNu dHYuY29tDQoNCiAgIFtDaXJydXNdIENpcnJ1cywgVXNlIFJUTUZQIGZvciBkZXZlbG9waW5nIHJl YWwtdGltZSBjb2xsYWJvcmF0aW9uDQogICAgICAgICAgICAgYXBwbGljYXRpb25zLGh0dHA6Ly9s YWJzLmFkb2JlLmNvbS90ZWNobm9sb2dpZXMvY2lycnVzLw0KDQogICBbQWthbWFpXSBQZWVyLXRv LVBlZXIgU3lzdGVtcywgUm9kcmlnbyBSb2RyaWd1ZXMgZXQgYWwsDQogICAgICAgICAgICAgQ29t bXVuaWNhdGlvbnMgb2YgdGhlIEFDTSxWb2wuIDUzLE5vLiAxMCwgUGFnZXMgNzItODIuDQogICAg ICAgICAgICAgaHR0cDovL2NhY20uYWNtLm9yZy9tYWdhemluZXMvMjAxMC8xMC85OTQ5OC1wZWVy LXRvLXBlZXItDQogICAgICAgICAgICAgc3lzdGVtcy9mdWxsdGV4dA0KDQogICBbQ2hpbmFDYWNo ZV0gUmF3RmxvdyBwYXJ0bmVycyB3aXRoIENoaW5hQ2FjaGU6IENyZWF0aW5nIEFzaWEncw0KICAg ICAgICAgICAgICAgICBsYXJnZXN0IFAyUCBwb3dlcmVkIGxpdmUgbWVkaWEgZGVsaXZlcnkgbmV0 d29yaywNCiAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5yZWRvcmJpdC5jb20vbmV3cy90ZWNo bm9sb2d5LzgxMzcyMi9yYXdmbG93Xw0KICAgICAgICAgICAgICAgICBwYXJ0bmVyc193aXRoX2No aW5hY2FjaGVfY3JlYXRpbmdfYXNpYXNfbGFyZ2VzdF9QMlBfDQogICAgICAgICAgICAgICAgIHBv d2VyZWRfbGl2ZS8NCg0KICAgW1N1cnZleV0gWW9uZyBMaXUgZXQgYWwsIkEgc3VydmV5IG9uIFBl ZXItdG8tUGVlciB2aWRlbyBzdHJlYW1pbmcNCiAgICAgICAgICAgICBzeXN0ZW1zIiwgUGVlciB0 byBQZWVyIE5ldHdvcmtpbmcgYW5kIEFwcGxpY2F0aW9ucyxWb2x1bWUgMSwNCiAgICAgICAgICAg ICBOdW1iZXIgMSwxOC0yOCxTcHJpbmdlciwyMDA4Lg0KDQogICBbUmF5Vl0gaHR0cDovL3d3dy5y YXl2LmNvbQ0KDQoNCg0KemhhbmcgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAx MiAgICAgICAgICAgICAgICAgW1BhZ2UgMjJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJv YmxlbSBTdGF0ZW1lbnQgb2YgUFBTUCAgICAgICAgICBOb3ZlbWJlciAyMDExDQoNCg0KICAgW0Zv cmNldGVjaF0gaHR0cDovL3d3dy5mb3JjZXRlY2gubmV0L2VuZ2xpc2gvc29sdXRpb25zDQoNCiAg IFtDRE4rUDJQXSBILiBKaWFuZyBldCBhbCwiRWZmaWNpZW50IExhcmdlLXNjYWxlIENvbnRlbnQg RGlzdHJpYnV0aW9uDQogICAgICAgICAgICAgd2l0aCBDb21iaW5hdGlvbiBvZiBDRE4gYW5kIFAy UCBOZXR3b3JrcyIsIEludGVybmF0aW9uYWwNCiAgICAgICAgICAgICBKb3VybmFsIG9mIEh5YnJp ZCBJbmZvcm1hdGlvbiBUZWNobm9sb2d5LCBWb2wuMiwgTm8uMiwNCiAgICAgICAgICAgICBBcHJp bCwgMjAwOS4NCg0KICAgW0hQVFBdIEhQVFA6IFJlbGlldmluZyB0aGUgVGVuc2lvbiBiZXR3ZWVu IElTUHMgYW5kIFAyUCwgR3VvYmluIFNoZW4NCiAgICAgICAgICAgICBldCBhbCwgSVBUUFMgMjAw Ny4NCg0KICAgW1N0YXRpc3RpY3NdIENoaW5hJ3MgbW9iaWxlIEludGVybmV0IHVzZXJzIHRvIHN1 cnBhc3MgSW50ZXJuZXQgdXNlcnMNCiAgICAgICAgICAgICAgICAgaW4gMjAxMiwgaHR0cDovL3d3 dy5tc3BuZXdzLmNvbS9uZXdzLzIwMTEvMDIvMTUvNTMxMjQ2MS5odG0NCg0KICAgW1AyUCBDRFNd IDNHUFAgVFIgMjIuOTA2LCBTdHVkeSBvbiBJTVMgYmFzZWQgUGVlci10by1QZWVyIGNvbnRlbnQN CiAgICAgICAgICAgICBkaXN0cmlidXRpb24gc2VydmljZXMsaHR0cDovL3d3dy4zZ3BwLm9yZy9m dHAvU3BlY3MvaHRtbC0NCiAgICAgICAgICAgICBpbmZvLzIyOTA2Lmh0bQ0KDQogICBbTW9iaWxl IFN0cmVhbWluZzFdIFN0cmVhbWluZyB0byBNb2JpbGUgVXNlcnMgaW4gYSBQZWVyLXRvLVBlZXIN CiAgICAgICAgICAgICAgICAgICAgICAgIE5ldHdvcmssSmVvbmdodW4gTm9oIGV0IGFsLE1PQklN RURJQSAnMDkuDQoNCiAgIFtNb2JpbGUgU3RyZWFtaW5nMl0gSi4gUGVsdG90YWxvZXQgYWwuLCJB IHJlYWwtdGltZSBQZWVyLXRvLVBlZXINCiAgICAgICAgICAgICAgICAgICAgICAgIHN0cmVhbWlu ZyBzeXN0ZW0gZm9yIG1vYmlsZSBuZXR3b3JraW5nIGVudmlyb25tZW50IiwNCiAgICAgICAgICAg ICAgICAgICAgICAgIE1vVklEICcwOS4NCiANCiAgIFtQUExpdmUgRGVzaWduXSBZLiBIdWFuZyBl dCBhbCAsIkNoYWxsZW5nZXMsIGRlc2lnbiBhbmQgYW5hbHlzaXMgb2YgYSANCiAgICAgICAgICAg ICAgICAgICAgbGFyZ2Utc2NhbGUgUDJQLXZvZCBzeXN0ZW0iLCBBQ00gU0lHQ09NTSBDb21wdXRl ciANCiAgICAgICAgICAgICAgICAgICAgQ29tbXVuaWNhdGlvbiBSZXZpZXcsMzgoNCk6Mzc1LTM4 OCwgMjAwOC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KemhhbmcgICAg ICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAgICAgICAgICAgICAgW1BhZ2Ug MjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgUHJvYmxlbSBTdGF0ZW1lbnQgb2YgUFBTUCAg ICAgICAgICBOb3ZlbWJlciAyMDExDQoNCg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBZ dW5mZWkgWmhhbmcNCiAgIENoaW5hIE1vYmlsZSBDb21tdW5pY2F0aW9uIENvcnBvcmF0aW9uDQog ICB6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb20NCg0KICAgTmluZ1pvbmcNCiAgIEh1YXdlaSBU ZWNobm9sb2dpZXMgQ28uLCBMdGQuDQogICB6b25nbmluZ0BodWF3ZWkuY29tDQoNCiAgIEdvbnph bG8gQ2FtYXJpbGxvDQogICBFcmljc3Nvbg0KICAgR29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24u Y29tDQoNCiAgIEphbWVzIFNlbmcNCiAgIFBQTGl2ZQ0KICAgamFtZXMuc2VuZ0BwcGxpdmUuY29t DQoNCiAgIFJpY2hhcmQgWWFuZw0KICAgWWFsZSBVbml2ZXJzaXR5DQogICB5cnlAY3MueWFsZS5l ZHUNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0Kemhh bmcgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXkgNywgMjAxMiAgICAgICAgICAgICAgICAg W1BhZ2UgMjRdDQoMDQoNCg== ------=_001_NextPart868272284751_=------ From a.bakker@vu.nl Mon Nov 7 04:20:15 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A8421F8B63 for ; Mon, 7 Nov 2011 04:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.471 X-Spam-Level: X-Spam-Status: No, score=-0.471 tagged_above=-999 required=5 tests=[AWL=-3.262, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icMiqHmNu1YT for ; Mon, 7 Nov 2011 04:20:15 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D05121F8B62 for ; Mon, 7 Nov 2011 04:20:14 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 7 Nov 2011 13:20:12 +0100 Received: from [192.168.0.105] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 7 Nov 2011 13:20:12 +0100 Message-ID: <4EB7CD5B.1090100@cs.vu.nl> Date: Mon, 7 Nov 2011 13:21:47 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Xiajinwei References: <4EB1082F.7090205@cs.vu.nl> In-Reply-To: Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?gb2312?b?tPC4tDogINeqt6I6IE5ldyBWZXJzaW9uIE5vdGlmaWNh?= =?gb2312?b?dGlvbiBmb3IgZHJhZnQtZ3UtcHBzcC1wZWVyLXByb3RvY29sLTAzLnR4dA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 12:20:15 -0000 Hi my remarks are inline: On 04/11/2011 02:22, Xiajinwei wrote: > If it succeed, sender > peer send the concrete data (chunk) whose ID is requested in > GET_CHUNK by existing media transport protocol decided by transport > negotiation. > Aha. Please make Figure 2 and the description of the GET_CHUNK message on p. 12 more clear. > It is a normal case that using different sessions to convey signaling > and data, e.g., using SIP or RTSP to setup and control media session > but using RTP to convey the media session data. > But in this case a client is potentially communicating with many peers (so resource usage matters) and, more importantly, the signalling and data transfer are tied together much more closely for PPSP. > It may not be true, if A has not the chunks in which B is interested, > there is not signaling HTTP connection in the direction from B to A. A peer-to-peer system should be designed such that the upload capacity of peers is exploited as much as possible. One method of doing so it to ensure that when two peers meets they have some chunks to exchange. BitTorrent, for example, achieves this by using the rarest-first economic model. In this model, peers download the chunk that the least number of peers have, such that it will have something that is of interest to a great many peers. For live streaming it will hold in general that peer A may have things that interest peer B because the window of interest is small, everybody is interested in the chunks recently generated by the live source. We have used this rarest-first model successfully for video-on-demand and live streaming [1,2]. Apparently you are not using "ensured mutual interest" as the mechanism to exploit peer upload capacity. Can you explain what mechanisms you do intend to use to make peers upload to eachother? > If B is interested in the chunks on A, the > draft-ietf-hybi-thewebsocketprotocol has defined a mechanism that > realize the bidirectional HTTP communication between peer ( this > draft is in RFC Ed Queue), it can address your above concern. Using bidirectional HTTP is a step not taken lightly, and a kludge IMHO. A design of a protocol in which one first establishes a symmetric TCP connection, then runs an asymmetric client/server protocol and finally, runs a complex framing protocol over that to make the connection symmetrical again needs a very strong justification. So unless there is strong evidence (measurements) that establishing an outgoing TCP connection is much harder in general than establishing an HTTP connection, HTTP should not be considered as a transport protocol for PPSP traffic, IMHO. If there is such evidence, the IETF should really scratch their collective heads as to how we wound up in a situation where we are basically redefining TCP as websockets-over-HTTP :-( > See my previous response, it can also answer your next comment on > multiplexing. For example, peer A can send a message with > GET_CHUNKMAP with its PEER_STATUS and its CHUNKMAP within a single > message. > Can you please elaborate on how your multiplexing works? When I look at the binary encoding a datagram on the wire consists of the main message header (p.16) followed by zero or more TLV (Type, Length, Value) elements (p.18). The main message header contains a "message type" field (p. 17) that is either "Request" or "Reply". The Type in the TLV elements can be GET_PEERLIST (value 1), GET_CHUNKMAP (value 2), GET_CHUNK (value 3), GET_PROPERTY (value 4, and I guess you mean GET_STATUS) and TRANSPORT_NEGOTIATION (value 5). I assume that a GET_CHUNKMAP request is sent as a TLV element with Type=GET_CHUNKMAP and length 0, the spec is not clear. In any case, this design suggests that you can send multiple requests in one datagram ("Message Type" = "Request"), and multiple replies, but not a mix. In other words, how do I distinguish a GET_CHUNKMAP request from peer A to B, from the actual chunkmap of A that it wants to send to B in the same datagram? The HTTP encoding does not discuss multiplexing at all, as far as I can tell. > Agree, we will complement it in next version. As for the transport > protocols, we can list some candidates protocols for consideration > but we need to get rough consensus on WG before we can make any > precise decision. > I think it is important to show how your design works with concrete media transport protocols, and HTTP and RTP are explicitly mentioned in the charter, and the obvious candidates. You are using HTTP already as data transport on p. 28 ;o) > These parts (e.g., the length of Peer ID etc) are undecided and need > to be discussed with corresponding experts, that is why we leave them > as TBD. > Then please modify the specification. It currently makes explicit choices without justification rather than leaving them TBD :-( >> * As remarked before, I think HTTP is unsuited as the basis for a >> peer-to-peer protocol. This is even illustrated in the draft >> itself: the PEER_STATUS message is needed for a serving peer to >> tell a client peer it can no longer request data. As unsollicited >> communication from server to client is impossible in HTTP, this >> design is either impossible or requires 2 HTTP connections per pair >> of peers. Note this quirky design is not necesarry when simply TCP >> is used. >> > > I agree the description is confusing. this message is sent from leech > peer to sender peer, please refer figure 2. I will revise the > description, change serving peer to leech peer, and change client to > sender peer. > Err... no. On page 29 a serving peer uses GET_STATUS to choke a leecher. That is, the server uses it to tell a client to stop requesting data from it. You cannot simply reverse the direction here, then you lose functionality. This is a strong example that peer-to-peer communication is by nature symmetrical and using an asymmetric protocol like HTTP will lead to an awkward design. Regards, Arno Bakker ========== References [1] J. Mol, J. Pouwelse, M. Meulpolder, D. Epema, and H. Sips, ��Give-to-Get: Free-riding Resilient Video-on-demand in P2P Systems,�� in Proceedings Multimedia Computing and Networking conference (Proceedings of SPIE Vol. 6818), San Jose, California, USA, Jan. 2008. [2] J. Mol, A. Bakker, J. Pouwelse, D. Epema, and H. Sips, ��The design and deployment of a bittorrent live video streaming solution,�� in Proceedings IEEE International Symposium on Multimedia 2009, San Diego, CA, USA, Dec. 2009. From zhangyunfei@chinamobile.com Tue Nov 8 02:10:42 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA4321F8C93 for ; Tue, 8 Nov 2011 02:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.91 X-Spam-Level: X-Spam-Status: No, score=-95.91 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3M-J7H5HCjo for ; Tue, 8 Nov 2011 02:10:41 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7580E21F8C97 for ; Tue, 8 Nov 2011 02:10:38 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 4F4B5E924; Tue, 8 Nov 2011 18:10:28 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id EDFA9E993; Tue, 8 Nov 2011 18:10:27 +0800 (CST) Received: from ady-PC ([10.2.2.70]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011110818102567-19374 ; Tue, 8 Nov 2011 18:10:25 +0800 Date: Tue, 8 Nov 2011 18:10:24 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2011110818102446604911@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-08 18:10:25, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-08 18:10:27, Serialize complete at 2011-11-08 18:10:27 Content-Type: multipart/alternative; boundary="----=_001_NextPart422506847731_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18500.006 X-TM-AS-Result: No--11.970-7.0-31-10 X-imss-scan-details: No--11.970-7.0-31-10;No--11.970-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [ppsp] PPSP draft agenda X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 10:10:42 -0000 This is a multi-part message in MIME format. ------=_001_NextPart422506847731_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgZm9sa3MsDQogICAgVGhlIFBQU1AgZHJhZnQgYWdlbmRhIGlzIGF2YWlsYWJsZSBhdCBodHRw Oi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgyL2FnZW5kYS9wcHNwLnR4dCBhY2NvcmRpbmcg dG8gdGhlIHRpbWUgc2xvdCByZXF1ZXN0LiBTZWUgeW91IGluIFRhaXBlaS4NCg0KQlINCll1bmZl aQ0KDQoNCg0KDQoNCnpoYW5neXVuZmVp ------=_001_NextPart422506847731_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Hi folks,

The PPSP draft agenda is available at http://www.iet= f.org/proceedings/82/agenda/ppsp.txt according=20 to the time slot request. See you in Taipei.

Yunfei

zhangyunfei

------=_001_NextPart422506847731_=------ From christian.1.schmidt@nsn.com Tue Nov 8 06:58:34 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1321F8CCD for ; Tue, 8 Nov 2011 06:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDyMaRWMQZQI for ; Tue, 8 Nov 2011 06:58:34 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF8D21F8C60 for ; Tue, 8 Nov 2011 06:58:33 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pA8EwOug011526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2011 15:58:24 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pA8EwNo3020312; Tue, 8 Nov 2011 15:58:23 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 15:58:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9E26.DC5BF071" Date: Tue, 8 Nov 2011 15:58:21 +0100 Message-ID: In-Reply-To: <22A3852D27EBD546A70413F89677CE3303BF01@CNBEEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Survey draft-ietf-ppsp-survey Thread-Index: AcyUJ7WJNrf6amvtQdG+0SMhLzddZwAJOIMgAnYlimA= References: <4E9D00AA.4060400@mti-systems.com><201110181408148242523@chinamobile.com><22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net><00bf01cc92c7$0edbe120$2c93a360$@com><22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net><00eb01cc92e9$64ec6130$2ec52390$@com><22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net><22A3852D27EBD546A70413F89677CE33019C32@CNBEEXC007.nsn-intra.net> <22A3852D27EBD546A70413F89677CE3303BF01@CNBEEXC007.nsn-intra.net> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: , , X-OriginalArrivalTime: 08 Nov 2011 14:58:23.0398 (UTC) FILETIME=[DC9ACC60:01CC9E26] Subject: [ppsp] Survey draft-ietf-ppsp-survey X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 14:58:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9E26.DC5BF071 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yunfei & Martin, =20 the survey document could be a good document to talk about general issues like - Relationship and cooperation with ALTO service - Relationship and cooperation with DECADE service - Relationship and cooperation with network caches =20 For this purpose a new section could be included between=20 - A common p2p streaming process model - "Interworking with other services (ALTO, DECADE and network caches)" - Security considerations =20 What do you think about this proposal? =20 Best Regards Christian Schmidt =20 ------_=_NextPart_001_01CC9E26.DC5BF071 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yunfei & = Martin,

the = survey document could be a good document to talk about general issues = like

- = Relationship and cooperation = with ALTO service

- = Relationship and cooperation = with DECADE service

- = Relationship and cooperation = with network caches

For = this purpose a new section could be included between =

- = A common p2p streaming process = model

- = “Interworking with other = services (ALTO, DECADE and network = caches)”

- = Security = considerations

What do = you think about this proposal?

Best = Regards

Christian = Schmidt

------_=_NextPart_001_01CC9E26.DC5BF071-- From zhangyunfei@chinamobile.com Tue Nov 8 22:04:12 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F380521F8B14 for ; Tue, 8 Nov 2011 22:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.019 X-Spam-Level: X-Spam-Status: No, score=-96.019 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS8G4RTwP1Ld for ; Tue, 8 Nov 2011 22:04:11 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7503521F8B11 for ; Tue, 8 Nov 2011 22:04:10 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 5C27BED1A; Wed, 9 Nov 2011 14:04:08 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id D276DEBFC; Wed, 9 Nov 2011 14:04:07 +0800 (CST) Received: from ady-PC ([10.2.2.166]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011110914040508-11274 ; Wed, 9 Nov 2011 14:04:05 +0800 Date: Wed, 9 Nov 2011 14:04:03 +0800 From: zhangyunfei To: =?gb2312?B?U2NobWlkdCwgQ2hyaXN0aWFuIDEuIChOU04gLSBERS9NdW5pY2gp?= , ppsp , stiemerling References: <4E9D00AA.4060400@mti-systems.com><201110181408148242523@chinamobile.com><22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net><00bf01cc92c7$0edbe120$2c93a360$@com><22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net><00eb01cc92e9$64ec6130$2ec52390$@com><22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net><22A3852D27EBD546A70413F89677CE33019C32@CNBEEXC007.nsn-intra.net> <22A3852D27EBD546A70413F89677CE3303BF01@CNBEEXC007.nsn-intra.net>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2011110914040359802357@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-09 14:04:05, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-09 14:04:07, Serialize complete at 2011-11-09 14:04:07 Content-Type: multipart/alternative; boundary="----=_001_NextPart721774521188_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18502.005 X-TM-AS-Result: No--31.710-7.0-31-10 X-imss-scan-details: No--31.710-7.0-31-10;No--31.710-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [ppsp] Survey draft-ietf-ppsp-survey X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 06:04:12 -0000 This is a multi-part message in MIME format. ------=_001_NextPart721774521188_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQ2hyaXN0aWFuLA0KICAgIFRoaXMgaXMgYSBnb29kIHByb3Bvc2FsIHRvIGludm9sdmUgdGhl c2UgaXNzdWVzIGluIHRoZSBkaXNjdXNzaW9uIG9mIFBQU1AgV0cuIEkgbGlrZSBpdDopDQogICBU aGUgcmVsYXRpb25zaGlwIHdpdGggb3RoZXIgc2VydmljZXMgbGlrZSBBTFRPIGFuZCBERUNBREUg d2FzIGV2ZXIgYWRkcmVzc2VkIGluIGFuZCByZW1vdmVkIGZyb20gZm9ybWVyIHByb2JsZW0gc3Rh dGVtZW50IGRyYWZ0LiBDb25zaWRlcmluZyB0d28gZmFjdHM6IDEpZXhpc3RpbmcgcDJwIHN0cmVh bWluZyBzeXN0ZW1zIGRvbid0IGRlYWwgd2l0aCBBTFRPIGFuZCBERUNBREUgaXNzdWU7IDIpIFRo ZSBtb3RpdmF0aW9uIG9mIHRoZSBzdXJ2ZXkgZHJhZnQgaXMgYmFzaWNhbGx5IGEgcmVmZXJlbmNl IGZvciB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sIG9wZXJhdGlvbiwgaW5zdGVhZCBvZiBkZWFs aW5nIHdpdGggdGhlIGludGVncmF0aW9uIG9mIEFMVE8gb3IgREVDQURFIGludG8gYSBQUFNQIHN5 c3RlbSwgSSB3b3VsZCBzdWdnZXN0IHRvIGhhdmUgYSBuZXcgYW5kIGluZGl2aWR1YWwgZHJhZnQg dG8gZGlzY3VzcyB0aGUgaW50ZWdyYXRpb24gb2YgdGhlc2Ugc2VydmljZXMuDQogICAgV2l0aCBz aW1pbGFyIHJlYXNvbiwgYWx0aG91Z2ggdGhlIHJlbGF0aW9uc2hpcCB3aXRoIG5ldHdvcmsgY2Fj aGUvQ0ROIGhhcyBiZWVuIHRvdWNoZWQgaW4gcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQoIHNjZW5h cmlvIHNlY3Rpb24pLCBJJ2xsIGJlIGhhcHB5IHRvIHNlZSBpZiBhIG5ldyBkcmFmdCBkaXNjdXNz ZXMgaW4gZGV0YWlsIGhvdyB0aGUgbmV0d29yayBjYWNoZS9DRE4gY2FuIHdvcmsgZm9yIGEgUFBT UCBzeXN0ZW0uDQogICAgTWFueSB0aGFua3MgZm9yIHRoZSBwcm9wb3NhbC4NCg0KQlINCll1bmZl aQ0KDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoNCkZyb206IFNjaG1pZHQsIENocmlzdGlhbiAxLiAo TlNOIC0gREUvTXVuaWNoKQ0KRGF0ZTogMjAxMS0xMS0wOCAyMjo1OA0KVG86IHBwc3BAaWV0Zi5v cmc7IHpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbTsgc3RpZW1lcmxpbmdAbmV0bGFiLm5lYy5k ZQ0KU3ViamVjdDogU3VydmV5IGRyYWZ0LWlldGYtcHBzcC1zdXJ2ZXkNCkhpIFl1bmZlaSAmIE1h cnRpbiwNCiANCnRoZSBzdXJ2ZXkgZG9jdW1lbnQgY291bGQgYmUgYSBnb29kIGRvY3VtZW50IHRv IHRhbGsgYWJvdXQgZ2VuZXJhbCBpc3N1ZXMgbGlrZQ0KLSAgICAgICAgICBSZWxhdGlvbnNoaXAg YW5kIGNvb3BlcmF0aW9uIHdpdGggQUxUTyBzZXJ2aWNlDQotICAgICAgICAgIFJlbGF0aW9uc2hp cCBhbmQgY29vcGVyYXRpb24gd2l0aCBERUNBREUgc2VydmljZQ0KLSAgICAgICAgICBSZWxhdGlv bnNoaXAgYW5kIGNvb3BlcmF0aW9uIHdpdGggbmV0d29yayBjYWNoZXMNCiANCkZvciB0aGlzIHB1 cnBvc2UgYSBuZXcgc2VjdGlvbiBjb3VsZCBiZSBpbmNsdWRlZCBiZXR3ZWVuIA0KLSAgICAgICAg ICBBIGNvbW1vbiBwMnAgc3RyZWFtaW5nIHByb2Nlc3MgbW9kZWwNCi0gICAgICAgICAgobBJbnRl cndvcmtpbmcgd2l0aCBvdGhlciBzZXJ2aWNlcyAoQUxUTywgREVDQURFIGFuZCBuZXR3b3JrIGNh Y2hlcymhsQ0KLSAgICAgICAgICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KIA0KV2hhdCBkbyB5 b3UgdGhpbmsgYWJvdXQgdGhpcyBwcm9wb3NhbD8NCiANCkJlc3QgUmVnYXJkcw0KQ2hyaXN0aWFu IFNjaG1pZHQNCiA= ------=_001_NextPart721774521188_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi Christian,

This is a good proposal to involve these issues in= the=20 discussion of PPSP WG. I like it:)

The relationship with other services like ALTO and DECAD= E was=20 ever addressed in and removed from former problem statement draft.=20 Considering two facts: 1)existing p2p streaming systems don't deal wi= th=20 ALTO and DECADE issue; 2) The motivation of the survey draft is basically = a=20 reference for tracker and peer protocol operation, instead of dealing= with=20 the integration of ALTO or DECADE into a PPSP system, I would suggest= to=20 have a new and individual draft to discuss the integration of these=20 services.

With similar reason, although the relationship wit= h=20 network cache/CDN has been touched in problem statement draft( scenario=20 section), I'll be happy to see if a new draft discusses in detail how= the=20 network cache/CDN can work for a PPSP system.

Many thanks for the proposal.

Yunfei

zhangyunfei

From: Schm= idt,=20 Christian 1. (NSN - DE/Munich)

Date: 2011-11-08 22:58

To: ppsp@ietf.org; <= A=20 href=3D"mailto:zhangyunfei@chinamobile.com">zhangyunfei@chinamobile.com; stiemerling@netlab.nec.de

Subject: Survey draft-ietf-ppsp-survey

Hi Yu= nfei &=20 Martin,

the s= urvey=20 document could be a good document to talk about general issues=20 like

- = =20 Relationship and cooperation wit= h ALTO=20 service

- = =20 Relationship and cooperation wit= h DECADE=20 service

- = =20 Relationship and cooperation wit= h=20 network caches

For t= his=20 purpose a new section could be included between

- = =20 A=20 common p2p streaming process model

- = =20 =A1=B0Interworking with other se= rvices (ALTO,=20 DECADE and network caches)=A1=B1

- = =20 Security=20 considerations

What = do you=20 think about this proposal?

Best=20 Regards

Chris= tian=20 Schmidt

------=_001_NextPart721774521188_=------ From zhangyunfei@chinamobile.com Tue Nov 8 22:18:57 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC891F0C79 for ; Tue, 8 Nov 2011 22:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.373 X-Spam-Level: X-Spam-Status: No, score=-92.373 tagged_above=-999 required=5 tests=[AWL=-3.504, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG3jC++f61M1 for ; Tue, 8 Nov 2011 22:18:57 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8D1F0C81 for ; Tue, 8 Nov 2011 22:18:56 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id B2869ED31; Wed, 9 Nov 2011 14:18:55 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 9D0BCED2A; Wed, 9 Nov 2011 14:18:55 +0800 (CST) Received: from ady-PC ([10.2.2.166]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011110914185280-11851 ; Wed, 9 Nov 2011 14:18:52 +0800 Date: Wed, 9 Nov 2011 14:18:51 +0800 From: zhangyunfei To: zhangyunfei , =?gb2312?B?U2NobWlkdCwgQ2hyaXN0aWFuIDEuIChOU04gLSBERS9NdW5pY2gp?= , ppsp , stiemerling References: <4E9D00AA.4060400@mti-systems.com><201110181408148242523@chinamobile.com><22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net><00bf01cc92c7$0edbe120$2c93a360$@com><22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net><00eb01cc92e9$64ec6130$2ec52390$@com><22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net><22A3852D27EBD546A70413F89677CE33019C32@CNBEEXC007.nsn-intra.net> <22A3852D27EBD546A70413F89677CE3303BF01@CNBEEXC007.nsn-intra.net>, , <2011110914040359802357@chinamobile.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2011110914185118686873@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-09 14:18:52, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-09 14:18:55, Serialize complete at 2011-11-09 14:18:55 Content-Type: multipart/alternative; boundary="----=_001_NextPart165253556465_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18502.005 X-TM-AS-Result: No--43.883-7.0-31-10 X-imss-scan-details: No--43.883-7.0-31-10;No--43.883-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [ppsp] =?gb2312?b?u9i4tDogUmU6ICBTdXJ2ZXkgZHJhZnQtaWV0Zi1wcHNw?= =?gb2312?b?LXN1cnZleQ==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 06:18:58 -0000 This is a multi-part message in MIME format. ------=_001_NextPart165253556465_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQ2hyaXN0aWFuLA0KICAgIEEgZm9sbG93LXVwIG9mIGxhc3QgZW1haWw6VGhlIERFQ0FERSBp bnRlZ3JhdGlvbiBpc3N1ZSBoYXMgYmVlbiBhZGRyZXNzZWQgaW4gZHJhZnQtbGUtcHBzcC1kZWNh ZGUtaW50ZXJvcGVyYXRpb24uIEhvcGUgdG8gc2VlIHRoZSB1cGRhdGUvbWVyZ2VuY2Ugb24gdGhp cyBkcmFmdC4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQq3orz+yMujuiB6 aGFuZ3l1bmZlaQ0Kt6LLzcqxvOSjuiAyMDExLTExLTA5IDE0OjA0DQrK1bz+yMujuiBTY2htaWR0 LCBDaHJpc3RpYW4gMS4gKE5TTiAtIERFL011bmljaCk7IHBwc3A7IHN0aWVtZXJsaW5nDQrW98zi o7ogUmU6IFtwcHNwXSBTdXJ2ZXkgZHJhZnQtaWV0Zi1wcHNwLXN1cnZleQ0KSGkgQ2hyaXN0aWFu LA0KICAgIFRoaXMgaXMgYSBnb29kIHByb3Bvc2FsIHRvIGludm9sdmUgdGhlc2UgaXNzdWVzIGlu IHRoZSBkaXNjdXNzaW9uIG9mIFBQU1AgV0cuIEkgbGlrZSBpdDopDQogICBUaGUgcmVsYXRpb25z aGlwIHdpdGggb3RoZXIgc2VydmljZXMgbGlrZSBBTFRPIGFuZCBERUNBREUgd2FzIGV2ZXIgYWRk cmVzc2VkIGluIGFuZCByZW1vdmVkIGZyb20gZm9ybWVyIHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0 LiBDb25zaWRlcmluZyB0d28gZmFjdHM6IDEpZXhpc3RpbmcgcDJwIHN0cmVhbWluZyBzeXN0ZW1z IGRvbid0IGRlYWwgd2l0aCBBTFRPIGFuZCBERUNBREUgaXNzdWU7IDIpIFRoZSBtb3RpdmF0aW9u IG9mIHRoZSBzdXJ2ZXkgZHJhZnQgaXMgYmFzaWNhbGx5IGEgcmVmZXJlbmNlIGZvciB0cmFja2Vy IGFuZCBwZWVyIHByb3RvY29sIG9wZXJhdGlvbiwgaW5zdGVhZCBvZiBkZWFsaW5nIHdpdGggdGhl IGludGVncmF0aW9uIG9mIEFMVE8gb3IgREVDQURFIGludG8gYSBQUFNQIHN5c3RlbSwgSSB3b3Vs ZCBzdWdnZXN0IHRvIGhhdmUgYSBuZXcgYW5kIGluZGl2aWR1YWwgZHJhZnQgdG8gZGlzY3VzcyB0 aGUgaW50ZWdyYXRpb24gb2YgdGhlc2Ugc2VydmljZXMuDQogICAgV2l0aCBzaW1pbGFyIHJlYXNv biwgYWx0aG91Z2ggdGhlIHJlbGF0aW9uc2hpcCB3aXRoIG5ldHdvcmsgY2FjaGUvQ0ROIGhhcyBi ZWVuIHRvdWNoZWQgaW4gcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQoIHNjZW5hcmlvIHNlY3Rpb24p LCBJJ2xsIGJlIGhhcHB5IHRvIHNlZSBpZiBhIG5ldyBkcmFmdCBkaXNjdXNzZXMgaW4gZGV0YWls IGhvdyB0aGUgbmV0d29yayBjYWNoZS9DRE4gY2FuIHdvcmsgZm9yIGEgUFBTUCBzeXN0ZW0uDQog ICAgTWFueSB0aGFua3MgZm9yIHRoZSBwcm9wb3NhbC4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQoN CnpoYW5neXVuZmVpDQoNCkZyb206IFNjaG1pZHQsIENocmlzdGlhbiAxLiAoTlNOIC0gREUvTXVu aWNoKQ0KRGF0ZTogMjAxMS0xMS0wOCAyMjo1OA0KVG86IHBwc3BAaWV0Zi5vcmc7IHpoYW5neXVu ZmVpQGNoaW5hbW9iaWxlLmNvbTsgc3RpZW1lcmxpbmdAbmV0bGFiLm5lYy5kZQ0KU3ViamVjdDog U3VydmV5IGRyYWZ0LWlldGYtcHBzcC1zdXJ2ZXkNCkhpIFl1bmZlaSAmIE1hcnRpbiwNCiANCnRo ZSBzdXJ2ZXkgZG9jdW1lbnQgY291bGQgYmUgYSBnb29kIGRvY3VtZW50IHRvIHRhbGsgYWJvdXQg Z2VuZXJhbCBpc3N1ZXMgbGlrZQ0KLSAgICAgICAgICBSZWxhdGlvbnNoaXAgYW5kIGNvb3BlcmF0 aW9uIHdpdGggQUxUTyBzZXJ2aWNlDQotICAgICAgICAgIFJlbGF0aW9uc2hpcCBhbmQgY29vcGVy YXRpb24gd2l0aCBERUNBREUgc2VydmljZQ0KLSAgICAgICAgICBSZWxhdGlvbnNoaXAgYW5kIGNv b3BlcmF0aW9uIHdpdGggbmV0d29yayBjYWNoZXMNCiANCkZvciB0aGlzIHB1cnBvc2UgYSBuZXcg c2VjdGlvbiBjb3VsZCBiZSBpbmNsdWRlZCBiZXR3ZWVuIA0KLSAgICAgICAgICBBIGNvbW1vbiBw MnAgc3RyZWFtaW5nIHByb2Nlc3MgbW9kZWwNCi0gICAgICAgICAgobBJbnRlcndvcmtpbmcgd2l0 aCBvdGhlciBzZXJ2aWNlcyAoQUxUTywgREVDQURFIGFuZCBuZXR3b3JrIGNhY2hlcymhsQ0KLSAg ICAgICAgICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KIA0KV2hhdCBkbyB5b3UgdGhpbmsgYWJv dXQgdGhpcyBwcm9wb3NhbD8NCiANCkJlc3QgUmVnYXJkcw0KQ2hyaXN0aWFuIFNjaG1pZHQNCiA= ------=_001_NextPart165253556465_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi Christian,

A follow-up of last email:The DECADE integration i= ssue=20 has been addressed in draft-le-ppsp-decade-interoperation. Hope to see the= =20 update/mergence on this draft.

Yunfei

zhangyunfei

=B7=A2=BC=FE=C8=CB=A3=BA zhangyunfei

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2011-11-09 14:04

=CA=D5=BC=FE=C8=CB=A3=BA Schmidt,=20 Christian 1. (NSN - DE/Munich); ppsp<= /A>; stiemerling

=D6=F7=CC=E2=A3=BA Re: [ppsp] Survey draft-ietf-ppsp-surv= ey

Hi Christian,

This is a good proposal to involve these issues in= the=20 discussion of PPSP WG. I like it:)

Many thanks for the proposal.

Yunfei

zhangyunfei

From: Schm= idt,=20 Christian 1. (NSN - DE/Munich)

Date: 2011-11-08 22:58

To: ppsp@ietf.org; <= A=20 href=3D"mailto:zhangyunfei@chinamobile.com">zhangyunfei@chinamobile.com; stiemerling@netlab.nec.de

Subject: Survey draft-ietf-ppsp-survey

Hi Yu= nfei &=20 Martin,

the s= urvey=20 document could be a good document to talk about general issues=20 like

- = =20 Relationship and cooperation wit= h ALTO=20 service

- = =20 Relationship and cooperation wit= h DECADE=20 service

- = =20 Relationship and cooperation wit= h=20 network caches

For t= his=20 purpose a new section could be included between

- = =20 A=20 common p2p streaming process model

- = =20 =A1=B0Interworking with other se= rvices (ALTO,=20 DECADE and network caches)=A1=B1

- = =20 Security=20 considerations

What = do you=20 think about this proposal?

Best=20 Regards

Chris= tian=20 Schmidt

------=_001_NextPart165253556465_=------ From Martin.Stiemerling@neclab.eu Wed Nov 9 06:46:30 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E91021F89B8 for ; Wed, 9 Nov 2011 06:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8YW0GjmidQU for ; Wed, 9 Nov 2011 06:46:26 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 41E1521F8922 for ; Wed, 9 Nov 2011 06:46:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 47D2C28000203; Wed, 9 Nov 2011 15:46:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb+-q4zbUpZe; Wed, 9 Nov 2011 15:46:24 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 22EEB28000101; Wed, 9 Nov 2011 15:46:14 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 9 Nov 2011 15:46:14 +0100 From: Martin Stiemerling To: Rui Cruz , ppsp Thread-Topic: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt Thread-Index: AQHMl+Tgz/dvQk6CsEytMJhmbjeDupWkanhw Date: Wed, 9 Nov 2011 14:46:13 +0000 Message-ID: References: <20111031112206.30317.90541.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E6EDB4Polydeucesoffic_" MIME-Version: 1.0 Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 14:46:30 -0000 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E6EDB4Polydeucesoffic_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Speaking as individual] Hi, I have read the merged version of the tracker protocol and it is for me on = the right technical track. I have some issues: - Section 3.7 deals with the media presentation description. I see= this orthogonal to the tracker protocol, though there can be dependencies = if the presentation description contains information about the trackers. Ho= wever, it is not the task of the tracker protocol draft to define how the a= ctual information about the location of trackers is conveyed to the peers. = I would remove it completely, or add an appendix where the potential depend= ency between presentation description and information about trackers is dis= cussed. This would give space to talk the many different presentation descr= iptions available out there. - The relationship between the tracker protocol and SVC/MDC/and fr= iends is not clear to me just from reading the draft. I see codec issues mo= re related to the presentation description but not the tracker protocol. Ho= wever, I'm happy to be convinced by you that there is a relationship. - Figure 2: Is this referring to a particular implementation or is= it meant to show the conceptual data structures? Anyhow, the relationships= between the different parameters are not clear and it may not be required = to flesh this completely out. I guess a purely textual description would be= better, without going into the detail what the conceptual data structures = of a tracker are. - Table1/Request Messages: o I see that the messages there are required on a semantically level, bu= t I'm not so sure that we need all those messages in the protocol. For inst= ance, the LEAVE and DISCONNECT messages are used in a combined way (or inte= rchangeable way) in Figure 3 (see the bottom). Thus LEAVE seems to have a s= imilar semantics like DISCONNECT. o KEEPALIVE is required on the semantically level, but it could be modele= d with another message. o The point I'm trying to make: In the bittorrent tracker protocol, there= is only a GET which pulls information about peers from the tracker to the = peer and updates the tracker about the peer issuing the GET. This is also u= sed as keep alive. This may be overloading a single message, but on the oth= er hand hints to the fact that only a very limited amount of messages on th= e wire are required. - HTTP error codes vs. protocol error codes: I do not see the clea= r separation in the draft between what the HTTP error codes indicate and wh= at the tracker protocol error codes are. For instance the HTTP error code 4= 00 is already overloaded with 2 meanings: invalid syntax (by the way of wha= t: HTTP or message body of HTTP) and version not supported. This does not l= ook very clean, easy to implement, and also future proof. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 From: ppsp-bounces@ietf.org [mailto:ppsp-boun= ces@ietf.org] On Behalf Of Rui Cruz Sent: Monday, October 31, 2011 4:50 PM To: ppsp Cc: Rui Cruz Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-prot= ocol-06.txt Hi, We have updated the PPSP Tracker Protocol draft, corresponding to the merge= of the former drafts from Gu and Cruz. The changes reflect the details and suggestions discussed in recent meeting= s and in the mailing list. Please let us know your comments and suggestions. Thanks. --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Po= rto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 31/10/2011, at 11:22, internet-drafts@ietf.org wrote: A new version of I-D, draft-gu-ppsp-tracker-protocol-06.txt has been succes= sfully submitted by Rui Cruz and posted to the IETF repository. Filename: draft-gu-ppsp-tracker-protocol Revision: 06 Title: PPSP Tracker Protocol Creation date: 2011-10-30 WG ID: Individual Submission Number of pages: 44 Abstract: This document outlines the functionality required for an HTTP-based P2P Streaming Tracker Protocol, including requirements, functional entities and architecture, components, message flows, with detailed message processing instructions using an HTTP/XML encoding, the respective parameters, methods, and message formats, formal syntax and semantics. The PPSP Tracker Protocol proposed in this document extends the capabilities of PPSP to support adaptive and scalable video and 3D video, for Video On Demand (VoD) and Live video services. The Tracker Protocol is an application-level protocol for peers to publish/request content, provide peer lists to peers and peer status to Trackers. The IETF Secretariat --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E6EDB4Polydeucesoffic_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[Speaking as individual]<= o:p>

<= /p>

Hi,

<= /p>

I have read the merged ve= rsion of the tracker protocol and it is for me on the right technical track= . I have some issues:

- = ; Section 3.7 deals= with the media presentation description. I see this orthogonal to the trac= ker protocol, though there can be dependencies if the presentation description contains information about the trackers. However,= it is not the task of the tracker protocol draft to define how the actual = information about the location of trackers is conveyed to the peers. I woul= d remove it completely, or add an appendix where the potential dependency between presentation description a= nd information about trackers is discussed. This would give space to talk t= he many different presentation descriptions available out there.=

- = ; The relationship = between the tracker protocol and SVC/MDC/and friends is not clear to me jus= t from reading the draft. I see codec issues more related to the presentation description but not the tracker protocol. However, I&#= 8217;m happy to be convinced by you that there is a relationship.

- = ; Figure 2: Is this= referring to a particular implementation or is it meant to show the concep= tual data structures? Anyhow, the relationships between the different parameters are not clear and it may not be required to flesh= this completely out. I guess a purely textual description would be better,= without going into the detail what the conceptual data structures of a tra= cker are.

- = ; Table1/Request Me= ssages:

o I see that = the messages there are required on a semantically level, but I’m not = so sure that we need all those messages in the protocol. For instance, the LEAVE and DISCONNECT messages are used in a combined way (or interchan= geable way) in Figure 3 (see the bottom). Thus LEAVE seems to have a simila= r semantics like DISCONNECT.

o KEEPALIVE is requ= ired on the semantically level, but it could be modeled with another messag= e.

o The point I’= ;m trying to make: In the bittorrent tracker protocol, there is only a GET = which pulls information about peers from the tracker to the peer and updates the tracker about the peer issuing the GET. This is also = used as keep alive. This may be overloading a single message, but on the ot= her hand hints to the fact that only a very limited amount of messages on t= he wire are required.

- = ; HTTP error codes = vs. protocol error codes: I do not see the clear separation in the draft be= tween what the HTTP error codes indicate and what the tracker protocol error codes are. For instance the HTTP error code 400 is = already overloaded with 2 meanings: invalid syntax (by the way of what: HTT= P or message body of HTTP) and version not supported. This does not look ve= ry clean, easy to implement, and also future proof.

<= /p>

Martin<= /span>

<= /p>

martin.stiemerling@neclab.eu=

<= /p>

NEC Laboratories Europe -= Network Research Division NEC Europe Limited | Registered Office: NEC Hous= e, 1 Victoria Road, London W3 6BL | Registered in England 2832014

<= /p>

From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui Cruz
Sent: Monday, October 31, 2011 4:50 PM
To: ppsp
Cc: Rui Cruz
Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-track= er-protocol-06.txt

Hi,

We have updated the PPSP Tracker Protocol draft, cor= responding to the merge of the former drafts from Gu and Cruz.

The changes reflect the details and suggestions disc= ussed in recent meetings and in the mailing list.

Please let us know your comments and suggestions.

Thanks.

---------------------------<= o:p>

Best R= egards,

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Av. Prof. Dr. An=ED= bal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Porto Salvo= , Portugal
+351 214 233 200 (ext 5044), += ;351.939 060 939 (mobile)
rui.cruz@ieee= .org <= /span>
rui.s.cru= z@ist.utl.pt
sec.portu= gal@ieee.org
www.ieee-pt.org
Advancin= g technology for humanity.

On 31/10/2011, at 11:22, internet-drafts@ietf.org wrote:

A new version of I-D, draft-gu-ppsp-tracker-protocol= -06.txt has been successfully submitted by Rui Cruz and posted to the IETF = repository.

Filename:      = ; draft-gu-ppsp-tracker-protocol
Revision:      = ; 06
Title:      &n= bsp;       PPSP Tracker Protocol
Creation date:     =        2011-10-30
WG ID:      &n= bsp;            = ; Individual Submission
Number of pages: 44

Abstract:
  This document outlines the functionality required for an HTTP-b= ased
  P2P Streaming Tracker Protocol, including requirements, functio= nal
  entities and architecture, components, message flows, with deta= iled
  message processing instructions using an HTTP/XML encoding, the=
  respective parameters, methods, and message formats, formal syn= tax
  and semantics. The PPSP Tracker Protocol proposed in this docum= ent
  extends the capabilities of PPSP to support adaptive and scalab= le
  video and 3D video, for Video On Demand (VoD) and Live video   services. The Tracker Protocol is an application-level protocol= for
  peers to publish/request content, provide peer lists to peers a= nd
  peer status to Trackers.

The IETF Secretariat

--_000_E84E7B8FF3F2314DA16E48EC89AB49F024E6EDB4Polydeucesoffic_-- From Martin.Stiemerling@neclab.eu Wed Nov 9 07:36:56 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8121F8C39; Wed, 9 Nov 2011 07:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.079 X-Spam-Level: X-Spam-Status: No, score=-100.079 tagged_above=-999 required=5 tests=[AWL=-2.023, BAYES_00=-2.599, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpQph4nul+Kr; Wed, 9 Nov 2011 07:36:51 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD7321F84B8; Wed, 9 Nov 2011 07:36:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5DBC828000201; Wed, 9 Nov 2011 16:36:50 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYoGZ83EUzcg; Wed, 9 Nov 2011 16:36:50 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 3163728000101; Wed, 9 Nov 2011 16:36:30 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 9 Nov 2011 16:36:30 +0100 From: Martin Stiemerling To: Rui Cruz , "li.lichun1@zte.com.cn" Thread-Topic: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt Thread-Index: AQHMmJuuOZ/byCPY8EO4EnksHxiq7pWktS5Q Date: Wed, 9 Nov 2011 15:36:29 +0000 Message-ID: References:

In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E70E43Polydeucesoffic_" MIME-Version: 1.0 Cc: "ppsp@ietf.org" , "ppsp-bounces@ietf.org" Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 15:36:56 -0000 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E70E43Polydeucesoffic_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 W1NwZWFraW5nIGFzIGluZGl2aWR1YWxdDQpIaSBhbGwsDQoNCkkgZ3Vlc3MgSFRUUCBpcyBvbmx5 IGRlZmluZWQgdG8gcnVuIG92ZXIgVENQIGFuZCBub3Qgb3ZlciBVRFAgZm9yIHZhcmlvdXMgcmVh c29ucywgZS5nLiwNCg0KLSAgICAgICAgICBIVFRQIG1lc3NhZ2VzIGV4Y2VlZCB0aGUgc2l6ZSBv ZiBhbiBVRFAgZGF0YWdyYW0sIGV4Y2VwdCBpbiBzb21lIGNvcm5lciBjYXNlczsNCg0KLSAgICAg ICAgICBUaGVyZSBpcyBubyByZWxpYWJsZSB0cmFuc3BvcnQsIGZsb3cgYW5kIGNvbmdlc3Rpb24g Y29udHJvbCBpbiBVRFA7DQoNCi0gICAgICAgICAgQSBIVFRQIEdFVCBjYW4gcmVzdWx0IGluIGEg dmVyeSBsYXJnZSAyMDAgT0sgbWVzc2FnZS4NCg0KVGhpcyBkZWZpbml0ZWx5IHJ1bGVzIG91dCBI VFRQIG92ZXIgVURQLg0KDQpUbyBiZSBob25lc3RseSwgSaGvbSBwdXp6bGVkIHdoeSBIVFRQIHNo b3VsZCB0aGUgY2hvaWNlIGZvciB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHBlZXJzPyBJdCBp czoNCg0KLSAgICAgICAgICBhIGNsaWVudCBzZXJ2ZXIgcHJvdG9jb2wsIHRob3VnaCB3ZSBuZWVk IGEgYmlkaXJlY3Rpb25hbCBwcm90b2NvbCB3aGljaCBubyBjbGVhciBjbGllbnQgYW5kIHNlcnZl ciByb2xlcy4gRXh0ZW5zaW9ucyB0byBIVFRQIHRvIGxldCBzZXJ2ZXJzIHNlbmQgYXN5bmNocm9u b3VzIG1lc3NhZ2VzIGFyZSBvbiB0aGUgd2F5LCBzZWUgdGhlIEJpRGlyZWN0aW9uYWwgb3IgU2Vy dmVyLUluaXRpYXRlZCBIVFRQIChoeWJpKSB3b3JraW5nIGdyb3VwIChodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvd2cvaHliaS9jaGFydGVyLykuIEhvd2V2ZXIsIHRoaXMgaXMgbm90IHlldCBm aW5pc2hlZDsNCg0KLSAgICAgICAgICBpdCBoYXMgYSBjb25zaWRlcmFibGUgb3ZlcmhlYWQgY2F1 c2VkIGJ5IHRoZSBIVFRQIGhlYWRlcnMgb24gdGhlIHdpcmUsIGNvbXBhcmVkIHRvIHRoZSBtZXNz YWdlIGNvbnRlbnQgKGUuZy4sIGNodW5rIG1hcHMpOyBBIGdvb2QgZXhhbXBsZSBpcyBnb29nbGWh r3Mgd29yayBvbiBzcGR5LCB3aGljaCBoYXMgdGhlIGdvYWwgdG8gcmVkdWNlIHRoZSBIVFRQIGhl YWRlcnMuIFNlZSB0aGlzIGxpbmsgKGh0dHA6Ly9kZXYuY2hyb21pdW0ub3JnL3NwZHkvc3BkeS13 aGl0ZXBhcGVyKTogobBVbmNvbXByZXNzZWQgcmVxdWVzdCBhbmQgcmVzcG9uc2UgaGVhZGVycy4g UmVxdWVzdCBoZWFkZXJzIHRvZGF5IHZhcnkgaW4gc2l6ZSBmcm9tIH4yMDAgYnl0ZXMgdG8gb3Zl ciAyS0IuobE7DQoNCi0gICAgICAgICAgaXQgaGFzIGEgY29uc2lkZXJhYmxlIG92ZXJoZWFkIHdo ZW4gaW1wbGVtZW50aW5nIGl0LCBlLmcuLCBjb2RlIHNpemUuIEkga25vdyB0aGF0IG1hbnkgcDJw IGNsaWVudHMgaGF2ZSBhIEhUVFAgc3RhY2ssIGJ1dCBpdCBzaG91bGQgbm90IGJlIG1hbmRhdG9y eSB0byBpbXBsZW1lbnQgSU1PLg0KDQpSZXVzaW5nIGV4aXN0aW5nIHByb3RvY29scyBpcyBhIGdv b2QgaWRlYSwgYnV0IEkgaGF2ZSB0aGUgZmVlbGluZyB0aGF0IHdlIGFyZSBzdHJldGNoaW5nIGl0 IGEgYml0IHRvbyBtdWNoIGluIHRoaXMgY2FzZS4NCg0KTXkgZmV3IGNlbnRzDQoNCiAgTWFydGlu DQoNCm1hcnRpbi5zdGllbWVybGluZ0BuZWNsYWIuZXU8bWFpbHRvOm1hcnRpbi5zdGllbWVybGlu Z0BuZWNsYWIuZXU+DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJj aCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhv dXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xh bmQgMjgzMjAxNA0KDQpGcm9tOiBwcHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwcHNwLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSdWkgQ3J1eg0KU2VudDogVHVlc2RheSwgTm92 ZW1iZXIgMDEsIDIwMTEgMjozOSBQTQ0KVG86IGxpLmxpY2h1bjFAenRlLmNvbS5jbg0KQ2M6IFJ1 aSBDcnV6OyBwcHNwQGlldGYub3JnOyBwcHNwLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbcHBzcF0gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ndS1wcHNwLXBlZXIt cHJvdG9jb2wtMDMudHh0DQoNCkluZGVlZCwgSSBzdXBwb3NlIG5vdGhpbmcgcHJldmVudHMgdXNp bmcgSFRUUC9YTUwgb3ZlciBVRFAsIGFzIG1lc3NhZ2VzIHR5cGljYWxseSBmaXQgaW4gVURQIGRh dGFncmFtcyBhbmQgdGhlIG1ldGhvZHMgdXNlZCBmb3IgcmVxdWVzdHMgYXJlIFBPU1QuDQpJbiB0 aGUgZHJhZnQgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCB0byBiZSB1c2VkIGZvciB0aGUgc2lnbmFs aW5nIHdhcyBub3Qgc3BlY2lmaWVkIGFuZCBpdCBpcyBvcGVuIHRvIGRpc2N1c3Npb24uDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQmVzdCBSZWdhcmRzLA0KDQpQcm9mLiBSdWkgU2Fu dG9zIENydXoNCkNoYWlybWFuDQpJRUVFIFBvcnR1Z2FsIFNlY3Rpb24NCkF2LiBQcm9mLiBEci4g QW6oqmJhbCBDYXZhY28gU2lsdmEsIElTVC1UYWd1c1BhcmssIE9mZmljZSAxLTUsIDI3NDQtMDE2 IFBvcnRvIFNhbHZvLCBQb3J0dWdhbA0KKzM1MSAyMTQgMjMzIDIwMCAoZXh0IDUwNDQpLCArMzUx LjkzOSAwNjAgOTM5IChtb2JpbGUpDQpydWkuY3J1ekBpZWVlLm9yZzx4LW1zZzovLzEyNy9ydWku Y3J1ekBpZWVlLm9yZz4NCnJ1aS5zLmNydXpAaXN0LnV0bC5wdDx4LW1zZzovLzEyNy9ydWkucy5j cnV6QGlzdC51dGwucHQ+DQpzZWMucG9ydHVnYWxAaWVlZS5vcmc8eC1tc2c6Ly8xMjcvc2VjLnBv cnR1Z2FsQGllZWUub3JnPg0Kd3d3LmllZWUtcHQub3JnPGh0dHA6Ly93d3cuaWVlZS1wdC5vcmcv Pg0KQWR2YW5jaW5nIHRlY2hub2xvZ3kgZm9yIGh1bWFuaXR5Lg0KDQpPbiAwMS8xMS8yMDExLCBh dCAwMTo1NSwgbGkubGljaHVuMUB6dGUuY29tLmNuPG1haWx0bzpsaS5saWNodW4xQHp0ZS5jb20u Y24+IHdyb3RlOg0KDQoNCg0KSSB0aGluayBYTUwgb3ZlciBVRFAgaXMgYWxzbyBhIGdvb2Qgb3B0 aW9uLg0KDQpCUg0KTGljaHVuDQoNCg0KcHBzcC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwcHNw LWJvdW5jZXNAaWV0Zi5vcmc+INC009ogMjAxMS0xMS0wMSAwOToyMToyODoNCg0KPiBIaSwNCj4N Cj4gV2UgaGF2ZSB1cGRhdGVkIHRoZSBQUFNQIFRyYWNrZXIgUHJvdG9jb2wgZHJhZnQsIGNvcnJl c3BvbmRpbmcgdG8NCj4gdGhlIG1lcmdlIG9mIHRoZSBmb3JtZXIgZHJhZnRzIGZyb20gR3UgYW5k IENydXouDQo+DQo+IFRoaXMgdmVyc2lvbiBtYWlubHkgZm9jdXMgb24gdGhlIG1lc3NhZ2VzIGV4 Y2hhbmdlZCBiZXR3ZWVuIHBlZXJzLA0KPiBidXQgbGVhdmUgdGhlIGVuY29kaW5nIGZvcm1hdCBp bnRvIEFwcGVuZGl4IHNpbmNlIHVzaW5nIGJpbmFyeSBvcg0KPiBIVFRQL1hNTCBhcyBjb250YWlu ZXIgaXMgc3RpbGwgdW5kZXIgZGlzcHV0ZS4NCj4NCj4gUGxlYXNlIGxldCB1cyBrbm93IHlvdXIg Y29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KPg0KPiBUaGFua3MuDQo+DQo+IEppbndlaQ0KPg0K PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz5dDQo+ILeiy83KsbzkOiAy MDExxOoxMNTCMzHI1SAxOTowNA0KPiDK1bz+yMs6IFhpYWppbndlaQ0KPiCzrcvNOiBYaWFqaW53 ZWk7IFlpbmdqaWUgR3UoeWluZ2ppZSk7IG1hcmlvLm51bmVzQGlub3YucHQ8bWFpbHRvOm1hcmlv Lm51bmVzQGlub3YucHQ+OyBqb2FvLg0KPiBzaWx2YUBpbm92LnB0PG1haWx0bzpzaWx2YUBpbm92 LnB0PjsgcnVpLmNydXpAaWVlZS5vcmc8bWFpbHRvOnJ1aS5jcnV6QGllZWUub3JnPjsgZGJyeWFu QGV0aGVybm90Lm9yZzxtYWlsdG86ZGJyeWFuQGV0aGVybm90Lm9yZz4NCj4g1vfM4jogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9jb2wtMDMudHh0 DQo+DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9jb2wt MDMudHh0IGhhcyBiZWVuDQo+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmlud2VpIFhpYSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+DQo+IEZpbGVuYW1lOiAgICBkcmFm dC1ndS1wcHNwLXBlZXItcHJvdG9jb2wNCj4gUmV2aXNpb246ICAgIDAzDQo+IFRpdGxlOiAgICAg ICBQZWVyIFByb3RvY29sDQo+IENyZWF0aW9uIGRhdGU6ICAgIDIwMTEtMTAtMzENCj4gV0cgSUQ6 ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDMxDQo+DQo+ IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIHRoZSBhcmNoaXRlY3R1cmUg b2YgdGhlIFBQU1AgUGVlciBwcm90b2NvbA0KPiAgICBvdXRsaW5pbmcgdGhlIGZ1bmN0aW9uYWwg ZW50aXRpZXMsIG1lc3NhZ2UgZmxvd3MgYW5kIG1lc3NhZ2UNCj4gICAgcHJvY2Vzc2luZyBpbnN0 cnVjdGlvbnMsIHdpdGggdGhlIHJlc3BlY3RpdmUgcGFyYW1ldGVycy4gIFRoZSBQUFNQDQo+ICAg IFBlZXIgUHJvdG9jb2wgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBjYXBh YmlsaXRpZXMgb2YNCj4gICAgUFBTUCB0byBzdXBwb3J0IGFkYXB0aXZlIGFuZCBzY2FsYWJsZSB2 aWRlbyBhbmQgM0QgdmlkZW8sIGZvciBWaWRlbw0KPiAgICBPbiBEZW1hbmQgKFZvRCkgYW5kIExp dmUgdmlkZW8gc2VydmljZXMuICBUaGUgcHJvdG9jb2wgbWVzc2FnZXMNCj4gICAgZm9ybWFsIHN5 bnRheCBhbmQgc2VtYW50aWNzLCBtZXRob2RzLCBhbmQgZm9ybWF0cyBhcmUgcHJlc2VudGVkIGZv cg0KPiAgICBib3RoIEJpbmFyeSBhbmQgSFRUUC9YTUwgZW5jb2RlZCBmb3JtYXRzLg0KPg0KPg0K Pg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBwcHNwIG1haWxpbmcgbGlzdA0KPiBwcHNwQGlldGYu b3JnPG1haWx0bzpwcHNwQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Bwc3ANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KDQpUaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhl eSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5k ZXIuDQoNClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnPG1haWx0 bzpwcHNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w cHNwDQoNCg== --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E70E43Polydeucesoffic_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

[Speaking as individual]<= o:p>

Hi all,=

<= /p>

I guess HTTP is only defi= ned to run over TCP and not over UDP for various reasons, e.g.,<= /span>

- = ; HTTP messages exc= eed the size of an UDP datagram, except in some corner cases;

- = ; There is no relia= ble transport, flow and congestion control in UDP;

- = ; A HTTP GET can re= sult in a very large 200 OK message.

<= /p>

This definitely rules out= HTTP over UDP.

<= /p>

To be honestly, I=A1=AFm = puzzled why HTTP should the choice for the communication between peers? It = is:

- = ; a client server p= rotocol, though we need a bidirectional protocol which no clear client and = server roles. Extensions to HTTP to let servers send asynchronous messages are on the way, see the BiDirectional or Server-Initiated HTTP (h= ybi) working group (http://datatracker.ietf.org/wg/hybi/charter/). However, this is not y= et finished;

- = ; it has a consider= able overhead caused by the HTTP headers on the wire, compared to the messa= ge content (e.g., chunk maps); A good example is google=A1=AFs work on spdy, which has the goal to reduce the HTTP headers. See this link= (http://dev.chromium.org/spdy/spdy-whitepaper): =A1=B0Uncompressed request= and response headers. Request headers today vary in size from ~200 bytes t= o over 2KB.=A1=B1;

- = ; it has a consider= able overhead when implementing it, e.g., code size. I know that many p2p c= lients have a HTTP stack, but it should not be mandatory to implement IMO.

<= /p>

Reusing existing protocol= s is a good idea, but I have the feeling that we are stretching it a bit to= o much in this case.

<= /p>

My few cents

<= /p>

Martin<= /span>

<= /p>

martin.stiemerling@neclab= .eu

<= /p>

From: ppsp-bou= nces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui Cruz
Sent: Tuesday, November 01, 2011 2:39 PM
To: li.lichun1@zte.com.cn
Cc: Rui Cruz; ppsp@ietf.org; ppsp-bounces@ietf.org
Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-= protocol-03.txt

Indeed, I suppose nothing prevents using HTTP/XML ov= er UDP, as messages typically fit in UDP datagrams and the methods used for= requests are POST.

In the draft the transport protocol to be used for t= he signaling was not specified and it is open to discussion.

---------------------------<= span style=3D"font-size:13.5pt;font-family:"Helvetica","sans= -serif";color:black">

Best Regards,

Prof. Rui Santos Cruz
Chairm= an
IEEE Portugal Section
Av. Pro= f. Dr. An=A8=AAbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-= 016 Porto Salvo, Portugal
+351 214 233 200 (ext 5044), += ;351.939 060 939 (mobile)
= rui.cruz@ieee.org
rui.s.cruz@ist.utl.pt
sec.portugal@ieee.org
www.ie= ee-pt.org
Advancin= g technology for humanity.

On 01/11/2011, at 01:55, li.lichun1@zte.com.cn wrote:

I think XML over UDP is also a good option.

BR
Lichun

ppsp-bounces@ietf.org =D0=B4=D3=DA 2011-11-01 09:21:28:

> Hi,
>
> We have updated the PPSP Tracker Protocol draft, corresponding to =
> the merge of the former drafts from Gu and Cruz.
>
> This version mainly focus on the messages exchanged between peers,=
> but leave the encoding format into Appendix since using binary or =
> HTTP/XML as container is still under dispute.
>
> Please let us know your comments and suggestions.
>
> Thanks.
>
> Jinwei
>
> -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C231=C8=D5 19:04 > =CA=D5=BC=FE=C8=CB: Xiajinwei > =B3=AD=CB=CD: Xiajinwei; Yingjie Gu(yi= ngjie); mario.nunes@inov.pt; joao. > silva@inov.pt; rui.cruz@ieee.org; dbryan@ethern= ot.org > =D6=F7=CC=E2: New Version Notification= for draft-gu-ppsp-peer-protocol-03.txt > > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been = > successfully submitted by Jinwei Xia and posted to the IETF reposi= tory. > > Filename: draft-gu-ppsp-peer-protocol > Revision: 03 > Title: Peer Protocol > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 31 > > Abstract: > This document presents the architecture of the PPSP P= eer protocol > outlining the functional entities, message flows and = message > processing instructions, with the respective paramete= rs. The PPSP > Peer Protocol proposed in this document extends the c= apabilities of > PPSP to support adaptive and scalable video and 3D vi= deo, for Video > On Demand (VoD) and Live video services. The pr= otocol messages > formal syntax and semantics, methods, and formats are= presented for > both Binary and HTTP/XML encoded formats. > > &nb= sp; &= nbsp; = > > > The IETF Secretariat > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www= .ietf.org/mailman/listinfo/ppsp

-------------------------------------------------------- ZTE Information Security Notice: The informat= ion contained in this mail is solely pro= perty of the sender's organization. This mail= communication is confidential. Recipients named&n= bsp;above are obligated to maintain secrecy a= nd are not permitted to disclose the con= tents of this communication to others.<= /pre> This email and any files transmitted wit= h it are confidential and intended solely&nbs= p;for the use of the individual or entit= y to whom they are addressed. If you&nbs= p;have received this email in error please&nb= sp;notify the originator of the message. Any&= nbsp;views expressed in this message are thos= e of the individual sender. This message has been scanned for viruse= s and Spam by ZTE Anti-Spam system. _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org= /mailman/listinfo/ppsp

--_000_E84E7B8FF3F2314DA16E48EC89AB49F024E70E43Polydeucesoffic_-- From wes@mti-systems.com Wed Nov 9 18:51:21 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07911E8081 for ; Wed, 9 Nov 2011 18:51:21 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE1txxTGgZEo for ; Wed, 9 Nov 2011 18:51:20 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id 861B721F86D0 for ; Wed, 9 Nov 2011 18:51:20 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id pAA2pFe4029239 for ; Wed, 9 Nov 2011 21:51:17 -0500 Authentication-Results: cm-omr7 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.43.190] ([174.130.43.190:32355] helo=[192.168.1.102]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 51/13-04871-32C3BBE4; Wed, 09 Nov 2011 21:51:15 -0500 Message-ID: <4EBB3C26.2010604@mti-systems.com> Date: Wed, 09 Nov 2011 21:51:18 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ppsp@ietf.org References: <2011110818102446604911@chinamobile.com> In-Reply-To: <2011110818102446604911@chinamobile.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [ppsp] PPSP draft agenda X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 02:51:21 -0000 On 11/8/2011 5:10 AM, zhangyunfei wrote: > Hi folks, > The PPSP draft agenda is available at > http://www.ietf.org/proceedings/82/agenda/ppsp.txt according to the time > slot request. See you in Taipei. > The "demo show" sounds very interesting; is there a room reserved for it since it's outside the meeting slot that shows up on the main agenda web page? -- Wes Eddy MTI Systems From zhangyunfei@chinamobile.com Wed Nov 9 19:12:21 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F3521F84B8 for ; Wed, 9 Nov 2011 19:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.56 X-Spam-Level: X-Spam-Status: No, score=-95.56 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USF9clZbp6NZ for ; Wed, 9 Nov 2011 19:12:21 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CE8B721F84B6 for ; Wed, 9 Nov 2011 19:12:20 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 40D0DEF06; Thu, 10 Nov 2011 11:12:12 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 17239EF02; Thu, 10 Nov 2011 11:12:12 +0800 (CST) Received: from ady-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011111011120940-6019 ; Thu, 10 Nov 2011 11:12:09 +0800 Date: Thu, 10 Nov 2011 11:12:06 +0800 From: zhangyunfei To: "Wesley Eddy" , ppsp References: <2011110818102446604911@chinamobile.com>, <4EBB3C26.2010604@mti-systems.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201111101112067362719@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-10 11:12:09, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-10 11:12:11, Serialize complete at 2011-11-10 11:12:11 Content-Type: multipart/alternative; boundary="----=_001_NextPart872150314604_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18506.003 X-TM-AS-Result: No--21.560-7.0-31-10 X-imss-scan-details: No--21.560-7.0-31-10;No--21.560-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [ppsp] PPSP draft agenda X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 03:12:21 -0000 This is a multi-part message in MIME format. ------=_001_NextPart872150314604_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgV2VzLA0KICAgICBXZSBwbGFuIHRvIHJlLXVzZSB0aGUgc2FtZSByb29tIGFmdGVyIFBQU1Ag c2Vzc2lvbiBzaW5jZSBpdCBzaG91bGQgYmUgdmFjYW50IGR1cmluZyAxMTMwLTEzMDAuIElmIElF VEYgcmVxdWlyZXMgYW4gZXhwbGljaXQgcmVxdWVzdCBmb3IgdGhlIHJlc2VydmF0aW9uLCBJJ2xs IGRvIGl0IHJpZ2h0IG5vdy4gVGhhbmtzIGZvciB0aGUgcmVtaW5kZXIuDQoNCkJSDQpZdW5mZWkg DQoNCg0KDQoNCnpoYW5neXVuZmVpDQoNCkZyb206IFdlc2xleSBFZGR5DQpEYXRlOiAyMDExLTEx LTEwIDEwOjUxDQpUbzogcHBzcA0KU3ViamVjdDogUmU6IFtwcHNwXSBQUFNQIGRyYWZ0IGFnZW5k YQ0KT24gMTEvOC8yMDExIDU6MTAgQU0sIHpoYW5neXVuZmVpIHdyb3RlOg0KPiBIaSBmb2xrcywN Cj4gICAgIFRoZSBQUFNQIGRyYWZ0IGFnZW5kYSBpcyBhdmFpbGFibGUgYXQNCj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84Mi9hZ2VuZGEvcHBzcC50eHQgYWNjb3JkaW5nIHRvIHRo ZSB0aW1lDQo+IHNsb3QgcmVxdWVzdC4gU2VlIHlvdSBpbiBUYWlwZWkuDQo+ICANCg0KDQpUaGUg ImRlbW8gc2hvdyIgc291bmRzIHZlcnkgaW50ZXJlc3Rpbmc7ICBpcyB0aGVyZSBhIHJvb20gcmVz ZXJ2ZWQgZm9yDQppdCBzaW5jZSBpdCdzIG91dHNpZGUgdGhlIG1lZXRpbmcgc2xvdCB0aGF0IHNo b3dzIHVwIG9uIHRoZSBtYWluIGFnZW5kYQ0Kd2ViIHBhZ2U/DQoNCi0tIA0KV2VzIEVkZHkNCk1U SSBTeXN0ZW1zDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcHBzcA== ------=_001_NextPart872150314604_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312" Hi Wes, We plan to re-use the same room after P= PSP=20 session since it should be vacant during 1130-1300. If IETF requires an ex= plicit=20 request for the reservation, I'll do it right now. Thanks for the=20 reminder. BR Yunfei zhangyunfei From: Wesley=20 Eddy Date: 2011-11-10 10:51 To: ppsp Subject: Re: [ppsp] PPSP draft agenda

On 11/8/2011 5:10 AM, zhangyunfei wrote: > Hi folks, > The PPSP draft agend= a is available at > http://www.ietf.org/proceedings/82/agenda/ppsp.txt acc= ording to the time > slot request. See you in Taipei. > The "demo show" sounds very interesting;&nbs= p; is there a room reserved for it since it's outside the meeting slot&= nbsp;that shows up on the main agenda web page? -- Wes Eddy MTI Systems _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp ------=_001_NextPart872150314604_=------ From zhangyunfei@chinamobile.com Wed Nov 9 23:58:41 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC1111E80A4 for ; Wed, 9 Nov 2011 23:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.607 X-Spam-Level: X-Spam-Status: No, score=-95.607 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDNP7yAU14-L for ; Wed, 9 Nov 2011 23:58:41 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5742511E808E for ; Wed, 9 Nov 2011 23:58:41 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 05EBDEFA4; Thu, 10 Nov 2011 15:58:40 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id F22F3EF99; Thu, 10 Nov 2011 15:58:39 +0800 (CST) Received: from ady-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011111015583720-14185 ; Thu, 10 Nov 2011 15:58:37 +0800 Date: Thu, 10 Nov 2011 15:58:34 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201111101558341966614@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-10 15:58:37, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-10 15:58:39, Serialize complete at 2011-11-10 15:58:39 Content-Type: multipart/alternative; boundary="----=_001_NextPart222224271286_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18506.003 X-TM-AS-Result: No--11.576-7.0-31-10 X-imss-scan-details: No--11.576-7.0-31-10;No--11.576-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [ppsp] Please send the slides for PPSP session before Sunday night 20:00 (Local Time) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 07:58:42 -0000 This is a multi-part message in MIME format. ------=_001_NextPart222224271286_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgZm9sa3MsDQogICAgRm9yIHRoZSBwcmVzZW50ZXJzIG9uIFBQU1Agc2Vzc2lvbiBhbmQgZGVt byBzaG93LCBwbGVhc2Ugc2VuZCB0aGUgc2xpZGVzIGZvciBQUFNQIHNlc3Npb24gYmVmb3JlIFN1 bmRheSBuaWdodCAyMDowMCAoTG9jYWwgVGltZSkuIFRoYW5rcy4NCg0KQlINCll1bmZlaQ0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ== ------=_001_NextPart222224271286_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Hi folks, For the presenters on PPSP session and demo s= how,=20 please=20 send the slides for PPSP session before = ;Sunday night 20:00 (Local Time).=20 Thanks. BR Yunfei zhangyunfei ------=_001_NextPart222224271286_=------ From Martin.Stiemerling@neclab.eu Thu Nov 10 00:56:37 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF1721F84A3 for ; Thu, 10 Nov 2011 00:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQUH8Utc0Gy5 for ; Thu, 10 Nov 2011 00:56:37 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2ED21F84A5 for ; Thu, 10 Nov 2011 00:56:37 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7A50F280000F7 for ; Thu, 10 Nov 2011 09:56:36 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZf-XfTQzgyP for ; Thu, 10 Nov 2011 09:56:36 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 5F5B628000084 for ; Thu, 10 Nov 2011 09:56:31 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 10 Nov 2011 09:56:31 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: Question about SVC/AVC support Thread-Index: Acyfhdbwh/ymyE6LS5m1toeGmfXyKQ== Date: Thu, 10 Nov 2011 08:56:30 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] Question about SVC/AVC support X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 08:56:37 -0000 Hi, I ran into SVC/AVC in the tracker draft and in draft-gu-ppsp-peer-protocol-= 03.txt.=20 For the tracker, I'm not sure what the implications are, whereas for the pe= er protocol I can see implications.=20 However, there has been no large scale discussion if the PPSP peer protocol= should actually support SVC/AVC and if it should support it, what the impl= ications are.=20 When writing about this, is there also the need to support MDC? Can somebody outline what the implications are if we support SVC/AVC codecs= in the peer protocol? Thank you, Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From christian.1.schmidt@nsn.com Thu Nov 10 01:04:53 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FD621F8B02 for ; Thu, 10 Nov 2011 01:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v835vN7Nn+4P for ; Thu, 10 Nov 2011 01:04:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC5B21F8ACE for ; Thu, 10 Nov 2011 01:04:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAA94jDi021976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Nov 2011 10:04:46 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAA94cFa013694; Thu, 10 Nov 2011 10:04:43 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Nov 2011 10:04:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9F87.C3FAA48B" Date: Thu, 10 Nov 2011 10:04:32 +0100 Message-ID: In-Reply-To: <201111101112067362719@chinamobile.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] PPSP draft agenda Thread-Index: AcyfVpd7euwtFVrCQOutyDdnP9M7fAAMB7OQ References: <2011110818102446604911@chinamobile.com>, <4EBB3C26.2010604@mti-systems.com> <201111101112067362719@chinamobile.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "zhangyunfei" , "Wesley Eddy" , "ppsp" X-OriginalArrivalTime: 10 Nov 2011 09:04:35.0155 (UTC) FILETIME=[C4697A30:01CC9F87] Subject: Re: [ppsp] PPSP draft agenda X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 09:04:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9F87.C3FAA48B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yunfei, Perhaps that is not a good idea. At the same time there is a ISCO panel discussion http://www.isoc.org/isoc/conferences/ietf82-briefing/ This could reduce the participants remarkable. Perhaps another date/time is better? For example Wednesday lunchtime? Best Regards Christian =20 =20 From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of ext zhangyunfei Sent: Thursday, November 10, 2011 4:12 AM To: Wesley Eddy; ppsp Subject: Re: [ppsp] PPSP draft agenda =20 Hi Wes, We plan to re-use the same room after PPSP session since it should be vacant during 1130-1300. If IETF requires an explicit request for the reservation, I'll do it right now. Thanks for the reminder. =20 BR Yunfei=20 =20 ________________________________ zhangyunfei =20 From: Wesley Eddy =20 Date: 2011-11-10 10:51 To: ppsp =20 Subject: Re: [ppsp] PPSP draft agenda On 11/8/2011 5:10 AM, zhangyunfei wrote: > Hi folks, > The PPSP draft agenda is available at > http://www.ietf.org/proceedings/82/agenda/ppsp.txt according to the time > slot request. See you in Taipei. > =20 =20 =20 The "demo show" sounds very interesting; is there a room reserved for it since it's outside the meeting slot that shows up on the main agenda web page? =20 --=20 Wes Eddy MTI Systems _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp ------_=_NextPart_001_01CC9F87.C3FAA48B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yunfei, Perhaps that is not a good idea. At the same time there is a ISCO = panel discussion http://www= .isoc.org/isoc/conferences/ietf82-briefing/ This could reduce the participants remarkable. Perhaps another = date/time is better? For example Wednesday = lunchtime? Best Regards Christian From:= = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of = ext zhangyunfei Sent: Thursday, November 10, 2011 4:12 = AM To: Wesley Eddy; ppsp Subject: Re: [ppsp] PPSP = draft agenda Hi Wes, We plan to re-use = the same room after PPSP session since it should be vacant during = 1130-1300. If IETF requires an explicit request for the reservation, = I'll do it right now. Thanks for the = reminder. BR Yunfei <= p class=3DMsoNormal style=3D'margin:0cm;margin-bottom:.0001pt'> zhangyunfei From: Wesley = Eddy Date: 2011-11-10 10:51= To: ppsp Subject: Re: [ppsp] PPSP draft = agenda On 11/8/2011 5:10 AM, zhan= gyunfei wrote: > Hi folks,= > The PPS= P draft agenda is available at= > http://www.ietf.org/proceedings/82/a= genda/ppsp.txt according to the time > slot request. See you= in Taipei. > The "demo show" sound= s very interesting; is there a room&n= bsp;reserved for it since it's outside the&= nbsp;meeting slot that shows up on the = ;main agenda web page? -- Wes Eddy = MTI Systems ______________________________________________= _ ppsp mailing list<= /p> ppsp@ietf.org = https://www.ietf.org/mailman/listinfo/ppsp

------_=_NextPart_001_01CC9F87.C3FAA48B-- From Martin.Stiemerling@neclab.eu Thu Nov 10 01:12:41 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E549F21F8B1B for ; Thu, 10 Nov 2011 01:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.181 X-Spam-Level: X-Spam-Status: No, score=-102.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5DEQigIB5RL for ; Thu, 10 Nov 2011 01:12:41 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 581F721F8B1A for ; Thu, 10 Nov 2011 01:12:41 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9D8CA280000F7 for ; Thu, 10 Nov 2011 10:12:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsrONFi1Kk1u for ; Thu, 10 Nov 2011 10:12:40 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 8308B28000084 for ; Thu, 10 Nov 2011 10:12:35 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 10 Nov 2011 10:12:35 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: Slides for the PPSP Session at IETF#82 Thread-Index: AcyfiIV2WSAUuyl+QB6yEdEUgBNSdQ== Date: Thu, 10 Nov 2011 09:12:34 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] Slides for the PPSP Session at IETF#82 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 09:12:42 -0000 Dear all who are presenting at the PPSP session in Taipei,=20 Please provide a first draft of your slide set to Yunfei and me by email un= til Sunday, November 13th 5pm Taipei local time.=20 We will upload the slides to the meeting materials manager, so that the att= endees can go through the slides before the actual session.=20 You can still update your slides until Tuesday 7am Taipei local time.=20 Thank you in advance Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From rui.cruz@ieee-pt.org Thu Nov 10 01:47:10 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D1721F888A for ; Thu, 10 Nov 2011 01:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=1.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0o6jkw3-vuy for ; Thu, 10 Nov 2011 01:47:09 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id CF2F621F84D8 for ; Thu, 10 Nov 2011 01:47:08 -0800 (PST) Received: by wwi18 with SMTP id 18so405297wwi.1 for ; Thu, 10 Nov 2011 01:47:06 -0800 (PST) Received: by 10.180.4.67 with SMTP id i3mr7677997wii.1.1320918425240; Thu, 10 Nov 2011 01:47:05 -0800 (PST) Received: from airia.casa ([89.180.45.156]) by mx.google.com with ESMTPS id k5sm4496870wiz.9.2011.11.10.01.47.02 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 01:47:04 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_0E803ECD-8FDB-4998-8FD5-8D85A87F0EDB" From: Rui Cruz In-Reply-To: Date: Thu, 10 Nov 2011 09:47:01 +0000 Message-Id: <54FB68CD-F68B-49E1-8FDB-30D263501849@ieee.org> References: <2011110818102446604911@chinamobile.com>, <4EBB3C26.2010604@mti-systems.com> <201111101112067362719@chinamobile.com> To: "Schmidt, Christian 1. (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , ppsp Subject: Re: [ppsp] PPSP draft agenda X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 09:47:10 -0000 --Apple-Mail=_0E803ECD-8FDB-4998-8FD5-8D85A87F0EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Yunfei, please note that I will have to leave Taipei on Wednesday the 16th, in = the afternoon (late). Regards, Rui Cruz On 10/11/2011, at 09:04, Schmidt, Christian 1. (NSN - DE/Munich) wrote: > Hi Yunfei, > Perhaps that is not a good idea. At the same time there is a ISCO = panel discussion > http://www.isoc.org/isoc/conferences/ietf82-briefing/ > This could reduce the participants remarkable. Perhaps another = date/time is better? For example Wednesday lunchtime? > Best Regards > Christian > =20 > =20 > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf = Of ext zhangyunfei > Sent: Thursday, November 10, 2011 4:12 AM > To: Wesley Eddy; ppsp > Subject: Re: [ppsp] PPSP draft agenda > =20 > Hi Wes, > We plan to re-use the same room after PPSP session since it = should be vacant during 1130-1300. If IETF requires an explicit request = for the reservation, I'll do it right now. Thanks for the reminder. > =20 > BR > Yunfei=20 > =20 > zhangyunfei > =20 > From: Wesley Eddy > Date: 2011-11-10 10:51 > To: ppsp > Subject: Re: [ppsp] PPSP draft agenda > On 11/8/2011 5:10 AM, zhangyunfei wrote: > > Hi folks, > > The PPSP draft agenda is available at > > http://www.ietf.org/proceedings/82/agenda/ppsp.txt according to the = time > > slot request. See you in Taipei. > > =20 > =20 > =20 > The "demo show" sounds very interesting; is there a room reserved for > it since it's outside the meeting slot that shows up on the main = agenda > web page? > =20 > --=20 > Wes Eddy > MTI Systems > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_0E803ECD-8FDB-4998-8FD5-8D85A87F0EDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi Yunfei, please note that I = will have to leave Taipei on Wednesday the 16th, in the afternoon = (late). Regards, Rui Cruz On 10/11/2011, at 09:04, Schmidt, Christian 1. (NSN - = DE/Munich) wrote: Hi Yunfei, Perhaps that is not a good idea. At the same = time there is a ISCO panel discussion This could reduce the participants remarkable. = Perhaps another date/time is better? For example Wednesday = lunchtime? Best = Regards Christian ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] On Behalf Of ext = zhangyunfei Sent: Thursday, November 10, 2011 = 4:12 AM To: Wesley Eddy; = ppsp Subject: Re: [ppsp] PPSP draft = agenda Hi Wes, We plan to re-use the same = room after PPSP session since it should be vacant during 1130-1300. If = IETF requires an explicit request for the reservation, I'll do it right = now. Thanks for the reminder. BR Yunfei zhangyunfei From: Wesley = Eddy Date:To: Subject: Re: [ppsp] = PPSP draft = agenda > http://www.iet= f.org/proceedings/82/agenda/ppsp.txt according to the&n= bsp;time -- Wes Eddy MTI Systems ppsp@ietf.org https://www.ietf.org/m= ailman/listinfo/ppsp________= _______________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/ma= ilman/listinfo/ppsp = --Apple-Mail=_0E803ECD-8FDB-4998-8FD5-8D85A87F0EDB-- From Martin.Stiemerling@neclab.eu Thu Nov 10 01:50:53 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDF521F8B3C for ; Thu, 10 Nov 2011 01:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.223 X-Spam-Level: X-Spam-Status: No, score=-102.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEYr8AYp5Zx4 for ; Thu, 10 Nov 2011 01:50:52 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A980021F8B15 for ; Thu, 10 Nov 2011 01:50:52 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0212D28000084 for ; Thu, 10 Nov 2011 10:50:52 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghWflPK5wEZ7 for ; Thu, 10 Nov 2011 10:50:51 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D6543280000FD for ; Thu, 10 Nov 2011 10:50:46 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 10 Nov 2011 10:50:46 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: Materials for the meeting and remote participation Thread-Index: AcyfjghiEOSn658pS/ynyXwAloeRvg== Date: Thu, 10 Nov 2011 09:50:46 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] Materials for the meeting and remote participation X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 09:50:53 -0000 Dear all, This may be well-known for many people, but anyhow: You can access the slides for any WG here: https://datatracker.ietf.org/meeting/82/materials.html The slides, minutes, etc of past meetings are available here: http://www.ietf.org/meeting/proceedings.html You can also participate in the session via jabber and audio: http://www.ietf.org/meeting/82/remote-participation.html Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From rui.cruz@ieee-pt.org Thu Nov 10 03:55:09 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6701D21F8AE1 for ; Thu, 10 Nov 2011 03:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9lgtSlHgW-9 for ; Thu, 10 Nov 2011 03:55:07 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD7821F8ADC for ; Thu, 10 Nov 2011 03:55:06 -0800 (PST) Received: by wyf28 with SMTP id 28so815328wyf.31 for ; Thu, 10 Nov 2011 03:55:06 -0800 (PST) Received: by 10.180.76.175 with SMTP id l15mr8044165wiw.67.1320926106284; Thu, 10 Nov 2011 03:55:06 -0800 (PST) Received: from airia.casa (89-180-45-156.net.novis.pt. [89.180.45.156]) by mx.google.com with ESMTPS id j5sm4698930wix.20.2011.11.10.03.55.01 (version=SSLv3 cipher=OTHER); Thu, 10 Nov 2011 03:55:04 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_6850AC7C-09FB-47E0-B3DA-E380E3465778" From: Rui Cruz In-Reply-To: Date: Thu, 10 Nov 2011 11:55:00 +0000 Message-Id: <9582A85E-E4E3-43B9-97C9-C46C17BA4B7D@ieee.org> References: <20111031112206.30317.90541.idtracker@ietfa.amsl.com> To: Martin Stiemerling X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , ppsp Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 11:55:09 -0000 --Apple-Mail=_6850AC7C-09FB-47E0-B3DA-E380E3465778 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Martin, Please read inline my comments. --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org=20 rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 09/11/2011, at 14:46, Martin Stiemerling wrote: > [Speaking as individual] > =20 > Hi, > =20 > I have read the merged version of the tracker protocol and it is for = me on the right technical track. I have some issues: > - Section 3.7 deals with the media presentation description. = I see this orthogonal to the tracker protocol, though there can be = dependencies if the presentation description contains information about = the trackers. However, it is not the task of the tracker protocol draft = to define how the actual information about the location of trackers is = conveyed to the peers. I would remove it completely, or add an appendix = where the potential dependency between presentation description and = information about trackers is discussed. This would give space to talk = the many different presentation descriptions available out there. I agree that the Media Presentation Description may be considered = orthogonal to the protocol. However, there are in fact dependencies = related to the identification of trackers for the media/stream (swarm) = described in the MPD, as well as for the structure of the media/stream. = This can be "compared" to a .torrent file, that plays somehow the role = of the MPD in the case of BitTorrent protocol, and as you know, the = .torrent file contains information about the trackers and the mapping of = the chunks/pieces of the content. I agree that description of the MPD can be moved, with the necessary = adaptions in the main text, to an Appendix. > - The relationship between the tracker protocol and = SVC/MDC/and friends is not clear to me just from reading the draft. I = see codec issues more related to the presentation description but not = the tracker protocol. However, I=92m happy to be convinced by you that = there is a relationship. The Tracker protocol (as well as the Peer protocol) are bound to "VoD or = Live streaming of multimedia" (with the necessary constraints), not for = simple file sharing. However, a very important principle should be observed, in my opinion, = related to the role these protocols play in the streaming process, as = they should be open to support both "Structured Media" = (SVC/MDC/MVC/multi-bitrate) and unstructured media, but not being = involved in the decoding/encoding processes of the "Structured Media".=20= It is the Media Player application, not the protocols associated with = the transport of the Media, the entity that should "know" (via a = requester/re-assembler module) how and what to request (to a "peer") and = decode the received "Structured Media" (from the "peer") in order to = "present" it to the User.=20 As far as I know, other implementations of P2P media streaming, either = do not support "Structured Media" or, to support it, are deeply involved = in the requester/re-assembler decoding process, for example, splitting = SVC layers or MDC descriptions in different "trees" (push mode), or = using specific "piece picking" strategies and peer selection strategies = for the selection of the SVC layers or MDC descriptions, but integrated = into the P2P protocols.=20 The Media Presentation Description just helps the processes (associated = with the protocol) to know which are the Trackers controlling it and how = to map the chunks in order to "inform" which Peer HAS which Chunk (and = corresponding layers/descriptions etc.), but not tacking decisions on = layer/description fetching priorities, unless "instructed" by the = external requester/re-assembler module of the Media Player. > - Figure 2: Is this referring to a particular implementation = or is it meant to show the conceptual data structures? Anyhow, the = relationships between the different parameters are not clear and it may = not be required to flesh this completely out. I guess a purely textual = description would be better, without going into the detail what the = conceptual data structures of a tracker are. Ok, I agree with that. We will revise it for next version > - Table1/Request Messages: > o I see that the messages there are required on a semantically = level, but I=92m not so sure that we need all those messages in the = protocol. For instance, the LEAVE and DISCONNECT messages are used in a = combined way (or interchangeable way) in Figure 3 (see the bottom). Thus = LEAVE seems to have a similar semantics like DISCONNECT. A Peer may have JOINed several swarms, and be just contributing to those = swarms, but the user may decide to LEAVE a specific swarm, not = DISCONNECT from the system, and continue contributing or JOINing a new = swarm to watch a content, while still contributing to other swarms. The = semantics may seem similar but the purpose is more granular with the = LEAVE. Eventually, the DISCONNECT message may play the same role as = LEAVE when specifying a Swarm-ID. Let's discuss this option in the = meeting and mailing list. Figure 3 just gives a typical example, although I recognize that it = should not raise these doubts. We will revise it. =20 > o KEEPALIVE is required on the semantically level, but it could be = modeled with another message. Agreed. > o The point I=92m trying to make: In the bittorrent tracker = protocol, there is only a GET which pulls information about peers from = the tracker to the peer and updates the tracker about the peer issuing = the GET. This is also used as keep alive. This may be overloading a = single message, but on the other hand hints to the fact that only a very = limited amount of messages on the wire are required. Agreed. The STAT_REPORT can be used for the same purpose. Let's discuss = this option in the meeting and mailing list. > - HTTP error codes vs. protocol error codes: I do not see the = clear separation in the draft between what the HTTP error codes indicate = and what the tracker protocol error codes are. For instance the HTTP = error code 400 is already overloaded with 2 meanings: invalid syntax (by = the way of what: HTTP or message body of HTTP) and version not = supported. This does not look very clean, easy to implement, and also = future proof. =20 Also agreed. Let's discuss if we can just use standard HTTP error codes = without overloading with multiple meaning, in the meeting and mailing = list. > =20 > Martin > =20 > martin.stiemerling@neclab.eu > =20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014 > =20 > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf = Of Rui Cruz > Sent: Monday, October 31, 2011 4:50 PM > To: ppsp > Cc: Rui Cruz > Subject: Re: [ppsp] New Version Notification for = draft-gu-ppsp-tracker-protocol-06.txt > =20 > Hi, > =20 > We have updated the PPSP Tracker Protocol draft, corresponding to the = merge of the former drafts from Gu and Cruz.=20 > =20 > The changes reflect the details and suggestions discussed in recent = meetings and in the mailing list. > =20 > Please let us know your comments and suggestions. > =20 > Thanks. >=20 > --------------------------- > Best Regards, >=20 > Prof. Rui Santos Cruz > Chairman > IEEE Portugal Section > Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, = 2744-016 Porto Salvo, Portugal > +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) > rui.cruz@ieee.org=20 > rui.s.cruz@ist.utl.pt > sec.portugal@ieee.org > www.ieee-pt.org > Advancing technology for humanity. > =20 > On 31/10/2011, at 11:22, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-gu-ppsp-tracker-protocol-06.txt has been = successfully submitted by Rui Cruz and posted to the IETF repository. >=20 > Filename: draft-gu-ppsp-tracker-protocol > Revision: 06 > Title: PPSP Tracker Protocol > Creation date: 2011-10-30 > WG ID: Individual Submission > Number of pages: 44 >=20 > Abstract: > This document outlines the functionality required for an HTTP-based > P2P Streaming Tracker Protocol, including requirements, functional > entities and architecture, components, message flows, with detailed > message processing instructions using an HTTP/XML encoding, the > respective parameters, methods, and message formats, formal syntax > and semantics. The PPSP Tracker Protocol proposed in this document > extends the capabilities of PPSP to support adaptive and scalable > video and 3D video, for Video On Demand (VoD) and Live video > services. The Tracker Protocol is an application-level protocol for > peers to publish/request content, provide peer lists to peers and > peer status to Trackers. >=20 >=20 >=20 >=20 > The IETF Secretariat > =20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_6850AC7C-09FB-47E0-B3DA-E380E3465778 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Martin, Please read inline my = comments. ---------------------------Best = Regards, Chairman IEEE Portugal Section Av. Prof. Dr. = An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 = 939 (mobile) rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing = technology for humanity. On 09/11/2011, at 14:46, Martin Stiemerling = wrote: I = have read the merged version of the tracker protocol and it is for me on = the right technical track. I have some = issues: - Section 3.7 deals with the media presentation = description. I see this orthogonal to the tracker protocol, though there = can be dependencies if the presentation description contains information = about the trackers. However, it is not the task of the tracker protocol = draft to define how the actual information about the location of = trackers is conveyed to the peers. I would remove it completely, or add = an appendix where the potential dependency between presentation = description and information about trackers is discussed. This would give = space to talk the many different presentation descriptions available out = there. I agree that = the Media Presentation Description may be considered orthogonal to the = protocol. However, there are in fact dependencies related to the = identification of trackers for the media/stream (swarm) described = in the MPD, as well as for the structure of the media/stream. This can = be "compared" to a .torrent file, that plays somehow the role of the MPD = in the case of BitTorrent protocol, and as you know, the .torrent file = contains information about the trackers and the mapping of the = chunks/pieces of the content. I agree that description of the = MPD can be moved, with the necessary adaptions in the main text, to an = Appendix. The relationship between the tracker protocol and = SVC/MDC/and friends is not clear to me just from reading the draft. I = see codec issues more related to the presentation description but not = the tracker protocol. However, I=92m happy to be convinced by you that = there is a = relationship. <= div>The Tracker protocol (as well as the Peer protocol) are bound to = "VoD or Live streaming of multimedia" (with the necessary constraints), = not for simple file sharing. However, a very important = principle should be observed, in my opinion, related to the role these = protocols play in the streaming process, as they should be open to = support both "Structured Media" (SVC/MDC/MVC/multi-bitrate) and = unstructured media, but not being involved in the decoding/encoding = processes of the "Structured Media". It is the = Media Player application, not the protocols associated with the = transport of the Media, the entity that should "know" (via a = requester/re-assembler module) how and what to request (to a "peer") and = decode the received "Structured Media" (from the "peer") in order = to "present" it to the User. As far as I know, other = implementations of P2P media streaming, either do not = support "Structured Media" or, to support it, are deeply involved = in the requester/re-assembler decoding process, for example, = splitting SVC layers or MDC descriptions in different "trees" (push = mode), or using specific "piece picking" strategies and peer = selection strategies for the selection of the SVC layers or MDC = descriptions, but integrated into the P2P = protocols. The Media Presentation Description just = helps the processes (associated with the protocol) to know which are the = Trackers controlling it and how to map the chunks in order to "inform" = which Peer HAS which Chunk (and corresponding layers/descriptions etc.), = but not tacking decisions on layer/description fetching priorities, = unless "instructed" by the external requester/re-assembler module = of the Media Player. Figure 2: Is this referring to a particular = implementation or is it meant to show the conceptual data structures? = Anyhow, the relationships between the different parameters are not clear = and it may not be required to flesh this completely out. I guess a = purely textual description would be better, without going into the = detail what the conceptual data structures of a tracker = are. Ok, = I agree with that. We will revise it for next = version Table1/Request Messages: o I see that the messages there are required on = a semantically level, but I=92m not so sure that we need all those = messages in the protocol. For instance, the LEAVE and DISCONNECT = messages are used in a combined way (or interchangeable way) in Figure 3 = (see the bottom). Thus LEAVE seems to have a similar semantics like = DISCONNECT. A Peer may have JOINed several swarms, and be just contributing to = those swarms, but the user may decide to LEAVE a specific swarm, not = DISCONNECT from the system, and continue contributing or JOINing a new = swarm to watch a content, while still contributing to other swarms. The = semantics may seem similar but the purpose is more granular with the = LEAVE. Eventually, the DISCONNECT message may play the same role as = LEAVE when specifying a Swarm-ID. Let's discuss this option in the = meeting and mailing list. Figure 3 just gives a typical = example, although I recognize that it should not raise these doubts. We = will revise it. o KEEPALIVE is required on the semantically level, but = it could be modeled with another = message. A= greed. o The point I=92m trying to make: In the bittorrent = tracker protocol, there is only a GET which pulls information about = peers from the tracker to the peer and updates the tracker about the = peer issuing the GET. This is also used as keep alive. This may be = overloading a single message, but on the other hand hints to the fact = that only a very limited amount of messages on the wire are = required. = Agreed. The STAT_REPORT can be used for the same purpose. Let's = discuss this option in the meeting and mailing = list. HTTP error codes vs. protocol error codes: I do not = see the clear separation in the draft between what the HTTP error codes = indicate and what the tracker protocol error codes are. For instance the = HTTP error code 400 is already overloaded with 2 meanings: invalid = syntax (by the way of what: HTTP or message body of HTTP) and version = not supported. This does not look very clean, easy to implement, and = also future proof. = Als= o agreed. Let's discuss if we can just use standard HTTP error = codes without overloading with multiple meaning, in the meeting and = mailing list. NEC = Laboratories Europe - Network Research Division NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014 ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui = Cruz Sent: Monday, October 31, 2011 = 4:50 PM To: ppsp Cc: Rui = Cruz Subject: Re: [ppsp] New Version = Notification for = draft-gu-ppsp-tracker-protocol-06.txt <= div style=3D"margin-top: 0mm; margin-right: 0mm; margin-left: 0mm; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; "> We have updated the PPSP = Tracker Protocol draft, corresponding to the merge of the former drafts = from Gu and Cruz. The changes reflect the details and suggestions = discussed in recent meetings and in the mailing = list. Please let us know your = comments and suggestions. Thanks. ---------------------------<= /o:p> Best = Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal = Section Av. = Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office = 1-5, 2744-016 Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 = 060 939 (mobile) rui.cruz@ieee.org www.ieee-pt.org Advancing technology for = humanity. On 31/10/2011, at 11:22, internet-drafts@ietf.org wrote: = A new version = of I-D, draft-gu-ppsp-tracker-protocol-06.txt has been successfully = submitted by Rui Cruz and posted to the IETF = repository. Filename: draft-gu-ppsp-tracker-= protocol Revision: 06 Title: &= nbsp; PPSP Tracker = Protocol Creation date: &= nbsp; 2011-10-30 WG = ID: &= nbsp; Individual = Submission Number of pages: 44 Abstract: This = document outlines the functionality required for an = HTTP-based P2P Streaming Tracker Protocol, including = requirements, functional entities and architecture, = components, message flows, with detailed message = processing instructions using an HTTP/XML encoding, = the respective parameters, methods, and message formats, = formal syntax and semantics. The PPSP Tracker Protocol = proposed in this document extends the capabilities of = PPSP to support adaptive and scalable video and 3D video, = for Video On Demand (VoD) and Live video services. The = Tracker Protocol is an application-level protocol = for peers to publish/request content, provide peer lists = to peers and peer status to = Trackers. The IETF = Secretariat In-Reply-To: Date: Thu, 10 Nov 2011 12:20:29 +0000 Message-Id: References: To: Martin Stiemerling X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , "ppsp@ietf.org" Subject: Re: [ppsp] Question about SVC/AVC support X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 12:20:34 -0000 --Apple-Mail=_00F746F4-EFBF-4C84-85A9-62364A94F4A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Martin, Perhaps, I my apologies for repeating here what I answered in a previous = message, that PPSP should support both "Structured Media" = (SVC/MDC/MVC/multi-bitrate) and unstructured media (AVC) or other = formats, although the trend in the Internet has been for H.264 = MPEG-4/AVC and its extensions SVC, MVC. In what respects MDC, it can be = seen as an option, combined or not with SVC, but can perfectly be = supported if the PPSP protocols are "codec agnostic" (not involved in = the decoding process) but just "aware", as, in my opinion, they should = be. =20 A very important principle should be observed, in my opinion, related to = the role the PPSP protocols play in the streaming process, as they = should be open to support both "Structured Media" = (SVC/MDC/MVC/multi-bitrate) and unstructured media (AVC or other), but = not being involved in the decoding/encoding processes of the "Structured = Media".=20 It is the Media Player application, not the protocols associated with = the transport of the Media, the entity that should "know" (via a = requester/re-assembler module) how and what to request (to a "peer") and = decode the received "Structured Media" (from the "peer") in order to = "present" it to the User.=20 Both latest draft-gu-ppsp-tracker-protocol and = draft-gu-ppsp-peer-protocol were designed with this principle in mind, = and able to support (but not involved in the decoding) video streams = transmitted at a suitable spacio-temporal resolution, adequate for the = user's display device and networking conditions. =20 --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org=20 rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 10/11/2011, at 08:56, Martin Stiemerling wrote: > Hi, >=20 > I ran into SVC/AVC in the tracker draft and in = draft-gu-ppsp-peer-protocol-03.txt.=20 >=20 > For the tracker, I'm not sure what the implications are, whereas for = the peer protocol I can see implications.=20 >=20 > However, there has been no large scale discussion if the PPSP peer = protocol should actually support SVC/AVC and if it should support it, = what the implications are.=20 >=20 > When writing about this, is there also the need to support MDC? >=20 > Can somebody outline what the implications are if we support SVC/AVC = codecs in the peer protocol? >=20 > Thank you, >=20 > Martin >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014=20 >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_00F746F4-EFBF-4C84-85A9-62364A94F4A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Martin, Perhaps, I my apologies for repeating here = what I answered in a previous message, that PPSP should = support both "Structured Media" (SVC/MDC/MVC/multi-bitrate) = and unstructured media (AVC) or other formats, although the trend in the = Internet has been for H.264 MPEG-4/AVC and its extensions SVC, MVC. In = what respects MDC, it can be seen as an option, combined or not with = SVC, but can perfectly be supported if the PPSP protocols are "codec = agnostic" (not involved in the decoding process) but just "aware", as, = in my opinion, they should be. A = very important principle should be observed, in my opinion, related to = the role the PPSP protocols play in the streaming process, as they = should be open to support both "Structured Media" = (SVC/MDC/MVC/multi-bitrate) and unstructured media (AVC or other), = but not being involved in the decoding/encoding processes of = the "Structured Media". It is the Media Player = application, not the protocols associated with the transport of the = Media, the entity that should "know" (via a requester/re-assembler = module) how and what to request (to a "peer") and decode the = received "Structured Media" (from the "peer") in order to "present" = it to the User. Both latest = draft-gu-ppsp-tracker-protocol = and draft-gu-ppsp-peer-protocol were designed with this = principle in mind, and able to support (but not involved in the = decoding) video streams transmitted at a suitable spacio-temporal = resolution, adequate for the user's display device and networking = conditions. ---------------------------Best = Regards, Chairman IEEE Portugal Section Av. Prof. Dr. = An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 = 939 (mobile) rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing = technology for humanity. On 10/11/2011, at 08:56, Martin Stiemerling = wrote: Hi, I ran into SVC/AVC in the tracker draft = and in draft-gu-ppsp-peer-protocol-03.txt. For the tracker, I'm = not sure what the implications are, whereas for the peer protocol I can = see implications. However, there has been no large scale = discussion if the PPSP peer protocol should actually support SVC/AVC and = if it should support it, what the implications are. When writing = about this, is there also the need to support MDC? Can somebody = outline what the implications are if we support SVC/AVC codecs in the = peer protocol? Thank you, Martin martin.stiemerling@neclab.eu<= /a> NEC Laboratories Europe - Network Research Division NEC = Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 = _______________________________________________ ppsp = mailing = list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp = --Apple-Mail=_00F746F4-EFBF-4C84-85A9-62364A94F4A3-- From rui.cruz@ieee-pt.org Sat Nov 12 10:10:54 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6938021F86D0; Sat, 12 Nov 2011 10:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IApHnhV4wpT7; Sat, 12 Nov 2011 10:10:49 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B804A21F84B4; Sat, 12 Nov 2011 10:10:48 -0800 (PST) Received: by wyf28 with SMTP id 28so3292860wyf.31 for ; Sat, 12 Nov 2011 10:10:47 -0800 (PST) Received: by 10.216.132.94 with SMTP id n72mr3007642wei.51.1321121447252; Sat, 12 Nov 2011 10:10:47 -0800 (PST) Received: from [192.168.1.210] (bl7-142-126.dsl.telepac.pt. [85.240.142.126]) by mx.google.com with ESMTPS id en13sm18085795wbb.22.2011.11.12.10.10.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Nov 2011 10:10:45 -0800 (PST) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-ADFBE0CC-A56E-4D5D-8E63-112C45E5BEE2 Message-Id: <203D03ED-A024-4403-AE8B-B02FF58F5550@ieee-pt.org> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (9A405) From: Rui Cruz Date: Sat, 12 Nov 2011 18:10:41 +0000 To: Martin Stiemerling Cc: Rui Cruz , "ppsp@ietf.org" , "ppsp-bounces@ietf.org" Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 18:10:54 -0000 --Apple-Mail-ADFBE0CC-A56E-4D5D-8E63-112C45E5BEE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, see my comments inline. Cumprimentos/Regards, Rui Cruz Sent from my iPad2 On 09/11/2011, at 15:36, Martin Stiemerling w= rote: > [Speaking as individual] > Hi all, > =20 > I guess HTTP is only defined to run over TCP and not over UDP for various r= easons, e.g., > - HTTP messages exceed the size of an UDP datagram, except in som= e corner cases; > - There is no reliable transport, flow and congestion control in U= DP; > - A HTTP GET can result in a very large 200 OK message. > =20 > This definitely rules out HTTP over UDP. Well, UPnP uses HTTP over UDP in discovery messages. Using HTTP/XML encoding for signaling, results mostly in small sized message= s, as the main information is in the body and not in the resource and header= , and the total is typically smaller than the size of a UDP datagram. About reliability and congestion control, that is correct, therefore the pre= ference on using TCP when reliability is required. The protocol we designed uses POST messages for requests and takes advantage= of getting the replies with the requested data as payload on the body of 20= 0 OK. The reply would have to be transported anyway, so why not on the body o= f a 200 OK? > =20 > To be honestly, I=E2=80=99m puzzled why HTTP should the choice for the com= munication between peers? It is: > - a client server protocol, though we need a bidirectional protoc= ol which no clear client and server roles. Extensions to HTTP to let servers= send asynchronous messages are on the way, see the BiDirectional or Server-= Initiated HTTP (hybi) working group (http://datatracker.ietf.org/wg/hybi/cha= rter/). However, this is not yet finished; > - it has a considerable overhead caused by the HTTP headers on th= e wire, compared to the message content (e.g., chunk maps); A good example i= s google=E2=80=99s work on spdy, which has the goal to reduce the HTTP heade= rs. See this link (http://dev.chromium.org/spdy/spdy-whitepaper): =E2=80=9CU= ncompressed request and response headers. Request headers today vary in size= from ~200 bytes to over 2KB.=E2=80=9D; > - it has a considerable overhead when implementing it, e.g., code= size. I know that many p2p clients have a HTTP stack, but it should not be m= andatory to implement IMO. I would say that HTTP is a request/reply protocol between hosts. Anyway, for= a Streaming environment, what a media Player interfaces is with "streaming s= erver nodes", and so, we may think of Peers as the Streaming servers for a C= lient Media Player. So, any Peer is in fact a provider (server) entity for other interested Peer= s, but also a consumer (client) of the media available in the other Peers. Considering streaming of segmented media, the chunks have quite a large size= , ranging from as low as 5KiB to ~200 KiB (typical in scalable coding) for m= edia chunk playout duration of ~2 seconds (for High Quality videos). The HTT= P header size (and request body) is then comparatively small. Additionally, for these media chunk sizes (200+ KiB), a high quality non sca= lable video needs around one request every 2 seconds (not considering any sp= ecial strategy for piece picking). This is quite different from the typical i= mplementations of streaming via BitTorrent-like techniques, that need a quit= e large amount of requests per second for the very same video playout durati= on. For scalable media, this is an advantage for the strategy of requesting the l= ayers of a chunk up to a certain quality (eventually the maximum) in the ver= y same time window. Additionally, and for scalable media, the probability of= smooth playout without rebuffering is very high. This is one of the reasons for the adoption of HTTP Adaptive Streaming techn= iques from 3GPP and ISO, in special for mobile environment. There are alread= y applications for Live Streaming using HTTP for smartphones and aTablets, o= ver 3G or Wi-Fi, providing a high quality of experience to the user. An exam= ple is the Bloomberg App for the iPad. > =20 > Reusing existing protocols is a good idea, but I have the feeling that we a= re stretching it a bit too much in this case. > =20 > My few cents > =20 > Martin > =20 > martin.stiemerling@neclab.eu > =20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited | R= egistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in E= ngland 2832014 > =20 > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Ru= i Cruz > Sent: Tuesday, November 01, 2011 2:39 PM > To: li.lichun1@zte.com.cn > Cc: Rui Cruz; ppsp@ietf.org; ppsp-bounces@ietf.org > Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protoc= ol-03.txt > =20 > Indeed, I suppose nothing prevents using HTTP/XML over UDP, as messages ty= pically fit in UDP datagrams and the methods used for requests are POST. > In the draft the transport protocol to be used for the signaling was not s= pecified and it is open to discussion. >=20 > --------------------------- > Best Regards, >=20 > Prof. Rui Santos Cruz > Chairman > IEEE Portugal Section > Av. Prof. Dr. An=C3=ADbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-01= 6 Porto Salvo, Portugal > +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) > rui.cruz@ieee.org=20 > rui.s.cruz@ist.utl.pt > sec.portugal@ieee.org > www.ieee-pt.org > Advancing technology for humanity. > =20 > On 01/11/2011, at 01:55, li.lichun1@zte.com.cn wrote: >=20 >=20 >=20 > I think XML over UDP is also a good option. >=20 > BR=20 > Lichun >=20 >=20 > ppsp-bounces@ietf.org =E5=86=99=E4=BA=8E 2011-11-01 09:21:28: >=20 > > Hi, > >=20 > > We have updated the PPSP Tracker Protocol draft, corresponding to=20 > > the merge of the former drafts from Gu and Cruz.=20 > >=20 > > This version mainly focus on the messages exchanged between peers,=20 > > but leave the encoding format into Appendix since using binary or=20 > > HTTP/XML as container is still under dispute. > >=20 > > Please let us know your comments and suggestions. > >=20 > > Thanks. > >=20 > > Jinwei > >=20 > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-d= rafts@ietf.org]=20 > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B410=E6=9C=8831=E6=97=A5= 19:04 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xiajinwei > > =E6=8A=84=E9=80=81: Xiajinwei; Yingjie Gu(yingjie); mario.nunes@inov.pt;= joao. > > silva@inov.pt; rui.cruz@ieee.org; dbryan@ethernot.org > > =E4=B8=BB=E9=A2=98: New Version Notification for draft-gu-ppsp-peer-prot= ocol-03.txt > >=20 > > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been=20 > > successfully submitted by Jinwei Xia and posted to the IETF repository. > >=20 > > Filename: draft-gu-ppsp-peer-protocol > > Revision: 03 > > Title: Peer Protocol > > Creation date: 2011-10-31 > > WG ID: Individual Submission > > Number of pages: 31 > >=20 > > Abstract: > > This document presents the architecture of the PPSP Peer protocol > > outlining the functional entities, message flows and message > > processing instructions, with the respective parameters. The PPSP > > Peer Protocol proposed in this document extends the capabilities of > > PPSP to support adaptive and scalable video and 3D video, for Video > > On Demand (VoD) and Live video services. The protocol messages > > formal syntax and semantics, methods, and formats are presented for > > both Binary and HTTP/XML encoded formats. > >=20 > > = =20 > >=20 > >=20 > > The IETF Secretariat > > _______________________________________________ > > ppsp mailing list > > ppsp@ietf.org > > https://www.ietf.org/mailman/listinfo/ppsp >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is= solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and are= not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to whom they are addressed. I= f you have received this email in error please notify the originator of the m= essage. Any views expressed in this message are those of the individual send= er. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system= . > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > =20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail-ADFBE0CC-A56E-4D5D-8E63-112C45E5BEE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Martin,see m= y comments inline. Cumprimentos/Regards, Rui Cruz Sent from my iPad2 On 09/11/2011, at 15:36, Ma= rtin Stiemerling <Martin.= Stiemerling@neclab.eu> wrote: [Speaking as individual] Hi all, I guess HTTP is only define= d to run over TCP and not over UDP for various reasons, e.g., - = ; HTTP messages e= xceed the size of an UDP datagram, except in some corner cases; - = ; There is no rel= iable transport, flow and congestion control in UDP; - = ; A HTTP GET can r= esult in a very large 200 OK message. This definitely rules out H= TTP over UDP. Well, UPnP uses HTTP= over UDP in discovery messages. Using HTTP/XML encoding for signa= ling, results mostly in small sized messages, as the main information is in t= he body and not in the resource and header, and the total is typically small= er than the size of a UDP datagram. About reliability and congesti= on control, that is correct, therefore the preference on using TCP when reli= ability is required. The protocol we designed uses POST messages f= or requests and takes advantage of getting the replies with the requested da= ta as payload on the body of 200 OK. The reply would have to be transported a= nyway, so why not on the body of a 200 OK? To be honestly, I=E2=80=99m= puzzled why HTTP should the choice for the communication between peers? It i= s: - = ; a client server= protocol, though we need a bidirectional protocol which no clear client and= server roles. Extensions to HTTP to let servers send asynchronous messages are on the way, see the BiDirectional or Server-Initiated HTTP (hy= bi) working group (= http://datatracker.ietf.org/wg/hybi/charter/). However, this is not yet f= inished; - = ; it has a consid= erable overhead caused by the HTTP headers on the wire, compared to the mess= age content (e.g., chunk maps); A good example is google=E2=80=99s work on spdy, which has the goal to reduce the HTTP headers. See this link (= http://dev.chromium= .org/spdy/spdy-whitepaper): =E2=80=9CUncompressed request and response h= eaders. Request headers today vary in size from ~200 bytes to over 2KB.=E2=80= =9D; - = ; it has a consid= erable overhead when implementing it, e.g., code size. I know that many p2p c= lients have a HTTP stack, but it should not be mandatory to implement IMO. I= would say that HTTP is a request/reply protocol between hosts. Anyway, for a= Streaming environment, what a media Player interfaces is with "streaming se= rver nodes", and so, we may think of Peers as the Streaming servers for a Cl= ient Media Player. So, any Peer is in fact a provider (server) = entity for other interested Peers, but also a consumer (client) of the media= available in the other Peers. Considering streaming of seg= mented media, the chunks have quite a large size, ranging from as low as 5Ki= B to ~200 KiB (typical in scalable coding) for media chunk playout duration o= f ~2 seconds (for High Quality videos). The HTTP header size (and request bo= dy) is then comparatively small. Additionally, for these med= ia chunk sizes (200+ KiB), a high quality non scalable video needs around on= e request every 2 seconds (not considering any special strategy for piece pi= cking). This is quite different from the typical implementations of streamin= g via BitTorrent-like techniques, that need a quite large amount of requests= per second for the very same video playout duration. For scalable= media, this is an advantage for the strategy of requesting the layers of a c= hunk up to a certain quality (eventually the maximum) in the very same time w= indow. Additionally, and for scalable media, the probability of smooth playo= ut without rebuffering is very high. This is one of the reasons fo= r the adoption of HTTP Adaptive Streaming techniques from 3GPP and ISO, in s= pecial for mobile environment. There are already applications for Live Strea= ming using HTTP for smartphones and aTablets, over 3G or Wi-Fi, providing a h= igh quality of experience to the user. An example is the Bloomberg App for t= he iPad. Reusing existing protocols i= s a good idea, but I have the feeling that we are stretching it a bit too mu= ch in this case. My few cents Martin = martin.stiemerling@neclab.eu= = = NEC Laboratories Europe - Network Research Division NEC Europe Limited | Reg= istered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 From: ppsp-bounces@ietf.org [mailto:ppsp-bounces= @ietf.org] On Behalf Of Rui Cruz Sent: Tuesday, November 01, 2011 2:39 PM To: li.lichun1@zte.com.cn Cc: Rui Cruz; ppsp@ietf.org; ppsp-bounces@ietf.org Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-p= rotocol-03.txt Indeed, I suppose nothing prevents using HTTP/XML ove= r UDP, as messages typically fit in UDP datagrams and the methods used for r= equests are POST. In the draft the transport protocol to be used for th= e signaling was not specified and it is open to discussion. --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman= IEEE Portugal Section= Av. Prof.= Dr. An=C3=ADbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016= Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 0= 60 939 (mobile) r= ui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.iee= e-pt.org Advancing t= echnology for humanity. On 01/11/2011, at 01:55, li.lichun1@zte.com.cn wrote: I think XML over UDP is also a good option. BR Lichun ppsp-bounces@ietf.org =E5=86=99=E4=BA=8E 2011-11-01 09:21:28: > Hi, > > We have updated the PPSP Tracker Protocol draft, corresponding to <= /tt> > the merge of the former drafts from Gu and Cruz. > > This version mainly focus on the messages exchanged between peers, <= /tt> > but leave the encoding format into Appendix since using binary or <= /tt> > HTTP/XML as container is still under dispute. > > Please let us know your comments and suggestions. > > Thanks. > > Jinwei > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2= 011=E5=B9=B410=E6=9C=8831=E6=97=A5 19:04 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xiajinwei<= /tt> > =E6=8A=84=E9=80=81: Xiajinwei; Yingjie G= u(yingjie); mario.nunes@inov.pt; joao. > silva@inov.pt; rui.cruz@ieee.org; dbryan@etherno= t.org > =E4=B8=BB=E9=A2=98: New Version Notific= ation for draft-gu-ppsp-peer-protocol-03.txt > > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been <= /tt> > successfully submitted by Jinwei Xia and posted to the IETF reposit= ory. > > Filename: draft-gu-ppsp-peer-protocol > Revision: 03 > Title: Peer Protocol > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 31 > > Abstract: > This document presents the architecture of the PPSP Pe= er protocol > outlining the functional entities, message flows and m= essage > processing instructions, with the respective parameter= s. The PPSP > Peer Protocol proposed in this document extends the ca= pabilities of > PPSP to support adaptive and scalable video and 3D vid= eo, for Video > On Demand (VoD) and Live video services. The pro= tocol messages > formal syntax and semantics, methods, and formats are p= resented for > both Binary and HTTP/XML encoded formats. > > &nbs= p; &nb= sp; &n= bsp; > > > The IETF Secretariat > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.= ietf.org/mailman/listinfo/ppsp -------------------------------------------------------- ZTE Information Security Notice: The informati= on contained in this mail is solely prope= rty of the sender's organization. This mail&nb= sp;communication is confidential. Recipients named = above are obligated to maintain secrecy and&nb= sp;are not permitted to disclose the contents&= nbsp;of this communication to others. This email and any files transmitted with= it are confidential and intended solely = for the use of the individual or entity&n= bsp;to whom they are addressed. If you ha= ve received this email in error please no= tify the originator of the message. Any v= iews expressed in this message are those = of the individual sender. This message has been scanned for viruses= and Spam by ZTE Anti-Spam system.<= /pre> _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/= mailman/listinfo/ppsp ____________________= ___________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman= /listinfo/ppsp = --Apple-Mail-ADFBE0CC-A56E-4D5D-8E63-112C45E5BEE2-- From njaal.borch@gmail.com Sat Nov 12 12:12:56 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7221F8A80; Sat, 12 Nov 2011 12:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, SUSPICIOUS_RECIPS=2.912] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0vpH2mL+P69; Sat, 12 Nov 2011 12:12:54 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC9FE21F8A7A; Sat, 12 Nov 2011 12:12:53 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so5438869bkb.31 for ; Sat, 12 Nov 2011 12:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=eiJ2s1kUg6B7GE7enyeV8bcEZfdvsCzwDvMhgLIkJYU=; b=ZX1b0hgacEtnQzZ3wR/pyM4FwasO4Bwa0reRYN8H29DWywWn7kf3EHLsqJiUPq45JS UHIzJpi7n/8vWnWCfS4+HhpNgAS0cza9nLYK8zFtQEH7X73FbZDBRPw9vvVPddCgvIGb eKSP+CQQz2cCNgcYutYA34jMcK4eI3CXPUdj0= MIME-Version: 1.0 Received: by 10.205.120.20 with SMTP id fw20mr13432109bkc.39.1321128772711; Sat, 12 Nov 2011 12:12:52 -0800 (PST) Sender: njaal.borch@gmail.com Received: by 10.204.151.196 with HTTP; Sat, 12 Nov 2011 12:12:52 -0800 (PST) Received: by 10.204.151.196 with HTTP; Sat, 12 Nov 2011 12:12:52 -0800 (PST) In-Reply-To: <203D03ED-A024-4403-AE8B-B02FF58F5550@ieee-pt.org> References: <203D03ED-A024-4403-AE8B-B02FF58F5550@ieee-pt.org> Date: Sat, 12 Nov 2011 21:12:52 +0100 X-Google-Sender-Auth: mgo-uc30Qdv2gOLGNoMbgjIMCxE Message-ID: From: Njaal Borch To: Rui Cruz Content-Type: multipart/alternative; boundary=000e0cdfce8c33352f04b18f4370 Cc: Rui Cruz , "ppsp-bounces@ietf.org" , "ppsp@ietf.org" Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Nov 2011 20:12:56 -0000 --000e0cdfce8c33352f04b18f4370 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rui, Martin and all, I most definately agree with Martin that HTTP is neither suited for UDP transport, nor is it a good choice for a P2P protocol. A peer in a P2P network does not act as a server to one node and a client of another, it is (or should be) a node with likely a partially overlapping interest of data with some resources to exchange. In other words, there is an exchange of data, not a (double) producer-consumer relationship. The difference in these two views of what a node is does account for a lot of the discussion I belive. You can't design for traffic to be largely one way. You must think about incentives, and if they are not integrated in the protocol (like tit-for-tat), it must be thought about. As nodes cannot be trusted, you must have integrity checking. If you can only check large blocks for integrity checks, you are making the protool very easy to attack. You also can't say that your solution makes fewer requests, because the chunk size is vastly bigger - it is a reason why chunk sizes in e.g. live BT protocols is small. Lots and lots of nodes have very slow uplinks - meaning that if you are a bit unlucky, a node can easily spend several minutes uploading 200kb of data. If you design only for fast nodes, you basically dismiss of all ADSL and a lot of cable users too, not to mention all types of mobile nodes which are so far all asynchronous as far as I've seen. Allowing slow nodes to participate by providing data for longer is a very nice way to allow them not to be a massive burden on the P2P network. In other words, a P2P protocol *must be designed as a P2P protocol*, even if it has a main focus on streaming. I feel strongly that you are starting from scratch in the design of this protocol instead of taking in all the knowledge that is now available after several years of various P2P protocols and even several distinct P2P streaming protocols. I frankly think this proposal is more in line with a streaming Napster than something that can power cost efficient media distribution to millions of people in the next decade. Regards, Njaal On Nov 12, 2011 7:11 PM, "Rui Cruz" wrote: > Hi Martin, > see my comments inline. > > Cumprimentos/Regards, > Rui Cruz > > Sent from my iPad2 > > On 09/11/2011, at 15:36, Martin Stiemerling > wrote: > > [Speaking as individual]**** > > Hi all,**** > > ** ** > > I guess HTTP is only defined to run over TCP and not over UDP for various > reasons, e.g.,**** > > - HTTP messages exceed the size of an UDP datagram, except in > some corner cases;**** > > - There is no reliable transport, flow and congestion control in > UDP;**** > > - A HTTP GET can result in a very large 200 OK message.**** > > ** ** > > This definitely rules out HTTP over UDP. > > > Well, UPnP uses HTTP over UDP in discovery messages. > Using HTTP/XML encoding for signaling, results mostly in small sized > messages, as the main information is in the body and not in the resource > and header, and the total is typically smaller than the size of a UDP > datagram. > About reliability and congestion control, that is correct, therefore the > preference on using TCP when reliability is required. > The protocol we designed uses POST messages for requests and takes > advantage of getting the replies with the requested data as payload on th= e > body of 200 OK. The reply would have to be transported anyway, so why not > on the body of a 200 OK? > > **** > > ** ** > > To be honestly, I=E2=80=99m puzzled why HTTP should the choice for the > communication between peers? It is:**** > > - a client server protocol, though we need a bidirectional > protocol which no clear client and server roles. Extensions to HTTP to le= t > servers send asynchronous messages are on the way, see the BiDirectional = or > Server-Initiated HTTP (hybi) working group ( > http://datatracker.ietf.org/wg/hybi/charter/). However, this is not yet > finished;**** > > - it has a considerable overhead caused by the HTTP headers on > the wire, compared to the message content (e.g., chunk maps); A good > example is google=E2=80=99s work on spdy, which has the goal to reduce th= e HTTP > headers. See this link (http://dev.chromium.org/spdy/spdy-whitepaper): > =E2=80=9CUncompressed request and response headers. Request headers today= vary in > size from ~200 bytes to over 2KB.=E2=80=9D;**** > > - it has a considerable overhead when implementing it, e.g., > code size. I know that many p2p clients have a HTTP stack, but it should > not be mandatory to implement IMO. > > > I would say that HTTP is a request/reply protocol between hosts. Anyway, > for a Streaming environment, what a media Player interfaces is with > "streaming server nodes", and so, we may think of Peers as the Streaming > servers for a Client Media Player. > So, any Peer is in fact a provider (server) entity for other interested > Peers, but also a consumer (client) of the media available in the other > Peers. > Considering streaming of segmented media, the chunks have quite a large > size, ranging from as low as 5KiB to ~200 KiB (typical in scalable coding= ) > for media chunk playout duration of ~2 seconds (for High Quality videos). > The HTTP header size (and request body) is then comparatively small. > Additionally, for these media chunk sizes (200+ KiB), a high quality non > scalable video needs around one request every 2 seconds (not considering > any special strategy for piece picking). This is quite different from the > typical implementations of streaming via BitTorrent-like techniques, that > need a quite large amount of requests per second for the very same video > playout duration. > For scalable media, this is an advantage for the strategy of requesting > the layers of a chunk up to a certain quality (eventually the maximum) in > the very same time window. Additionally, and for scalable media, the > probability of smooth playout without rebuffering is very high. > This is one of the reasons for the adoption of HTTP Adaptive Streaming > techniques from 3GPP and ISO, in special for mobile environment. There ar= e > already applications for Live Streaming using HTTP for smartphones and > aTablets, over 3G or Wi-Fi, providing a high quality of experience to the > user. An example is the Bloomberg App for the iPad. > > **** > > ** ** > > Reusing existing protocols is a good idea, but I have the feeling that we > are stretching it a bit too much in this case. **** > > ** ** > > My few cents**** > > ** ** > > Martin**** > > ** ** > > martin.stiemerling@neclab.eu**** > > ** ** > > NEC Laboratories Europe - Network Research Division NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered > in England 2832014 **** > > ** ** > > *From:* ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] *On Behalf > Of *Rui Cruz > *Sent:* Tuesday, November 01, 2011 2:39 PM > *To:* li.lichun1@zte.com.cn > *Cc:* Rui Cruz; ppsp@ietf.org; ppsp-bounces@ietf.org > *Subject:* Re: [ppsp] New Version Notification for > draft-gu-ppsp-peer-protocol-03.txt**** > > ** ** > > Indeed, I suppose nothing prevents using HTTP/XML over UDP, as messages > typically fit in UDP datagrams and the methods used for requests are POST= . > **** > > In the draft the transport protocol to be used for the signaling was not > specified and it is open to discussion.**** > > > ---------------------------**** > > Best Regards, > > *Prof. Rui Santos Cruz** > *Chairman > *IEEE Portugal Section** > *Av. Prof. Dr. An=C3=ADbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-= 016 > Porto Salvo, Portugal > +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) > rui.cruz@ieee.org > rui.s.cruz@ist.utl.pt > sec.portugal@ieee.org > www.ieee-pt.org > Advancing technology for humanity.**** > > ** ** > > On 01/11/2011, at 01:55, li.lichun1@zte.com.cn wrote:**** > > > > **** > > > I think XML over UDP is also a good option. > > BR > Lichun > > > ppsp-bounces@ietf.org =E5=86=99=E4=BA=8E 2011-11-01 09:21:28: > > > Hi, > > > > We have updated the PPSP Tracker Protocol draft, corresponding to > > the merge of the former drafts from Gu and Cruz. > > > > This version mainly focus on the messages exchanged between peers, > > but leave the encoding format into Appendix since using binary or > > HTTP/XML as container is still under dispute. > > > > Please let us know your comments and suggestions. > > > > Thanks. > > > > Jinwei > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org [mailto:internet-= drafts@ietf.org] > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B410=E6=9C=8831=E6=97= =A5 19:04 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xiajinwei > > =E6=8A=84=E9=80=81: Xiajinwei; Yingjie Gu(yingjie); mario.nunes@inov.pt= ; joao. > > silva@inov.pt; rui.cruz@ieee.org; dbryan@ethernot.org > > =E4=B8=BB=E9=A2=98: New Version Notification for draft-gu-ppsp-peer-pro= tocol-03.txt > > > > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been > > successfully submitted by Jinwei Xia and posted to the IETF repository. > > > > Filename: draft-gu-ppsp-peer-protocol > > Revision: 03 > > Title: Peer Protocol > > Creation date: 2011-10-31 > > WG ID: Individual Submission > > Number of pages: 31 > > > > Abstract: > > This document presents the architecture of the PPSP Peer protocol > > outlining the functional entities, message flows and message > > processing instructions, with the respective parameters. The PPSP > > Peer Protocol proposed in this document extends the capabilities of > > PPSP to support adaptive and scalable video and 3D video, for Video > > On Demand (VoD) and Live video services. The protocol messages > > formal syntax and semantics, methods, and formats are presented for > > both Binary and HTTP/XML encoded formats. > > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > ppsp mailing list > > ppsp@ietf.org > > https://www.ietf.org/mailman/listinfo/ppsp**** > > --------------------------------------------------------**** > > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others.= **** > > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender.**** > > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m.**** > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp**** > > ** ** > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > --000e0cdfce8c33352f04b18f4370 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Rui, Martin and all, I most definately agree with Martin that HTTP is neither suited for UDP = transport, nor is it a good choice for a P2P protocol.=C2=A0 A peer in a P2= P network does not act as a server to one node and a client of another, it = is (or should be) a node with likely a partially overlapping interest of da= ta with some resources to exchange.=C2=A0 In other words, there is an excha= nge of data, not a (double) producer-consumer relationship. The difference = in these two views of what a node is does account for a lot of the discussi= on I belive. You can't design for traffic to be largely one way.=C2=A0 You must t= hink about incentives, and if they are not integrated in the protocol (like= tit-for-tat), it must be thought about.=C2=A0 As nodes cannot be trusted, = you must have integrity checking.=C2=A0 If you can only check large blocks = for integrity checks, you are making the protool very easy to attack.=C2=A0= You also can't say that your solution makes fewer requests, because th= e chunk size is vastly bigger - it is a reason why chunk sizes in e.g. live= BT protocols is small.=C2=A0 Lots and lots of nodes have very slow uplinks= - meaning that if you are a bit unlucky, a node can easily spend several m= inutes uploading 200kb of data.=C2=A0 If you design only for fast nodes, yo= u basically dismiss of all ADSL and a lot of cable users too, not to mentio= n all types of mobile nodes which are so far all asynchronous as far as I&#= 39;ve seen.=C2=A0 Allowing slow nodes to participate by providing data for = longer is a very nice way to allow them not to be a massive burden on the P= 2P network. In other words, a P2P protocol *must be designed as a P2P protocol*, eve= n if it has a main focus on streaming.=C2=A0 I feel strongly that you are s= tarting from scratch in the design of this protocol instead of taking in al= l the knowledge that is now available after several years of various P2P pr= otocols and even several distinct P2P streaming protocols.=C2=A0 I frankly = think this proposal is more in line with a streaming Napster than something= that can power cost efficient media distribution to millions of people in = the next decade. Regards, Njaal On Nov 12, 2011 7:11 PM, "Rui Cruz" &l= t;rui.cruz@ieee-pt.org> wrot= e: Hi Martin, see my comments inline.<= br> Cumprimentos/Regards, Rui Cruz Se= nt from my iPad2 On 09/11/2011, at 15:36, Martin Stiemerling = <Marti= n.Stiemerling@neclab.eu> wrote: [Spea= king as individual] Hi al= l, =C2=A0 I gue= ss HTTP is only defined to run over TCP and not over UDP for various reason= s, e.g., -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 HTTP me= ssages exceed the size of an UDP datagram, except in some corner cases;<= /u> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 There i= s no reliable transport, flow and congestion control in UDP;<= /span> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 A HTTP = GET can result in a very large 200 OK message. =C2=A0 This = definitely rules out HTTP over UDP. Well, UPnP uses HTT= P over UDP in discovery messages. Using HTTP/XML encoding for sig= naling, results mostly in small sized messages, as the main information is = in the body and not in the resource and header, and the total is typically = smaller than the size of a UDP datagram. About reliability and congestion control, that is correct, therefore t= he preference on using TCP when reliability is required. The prot= ocol we designed uses POST messages for requests and takes advantage of get= ting the replies with the requested data as payload on the body of 200 OK. = The reply would have to be transported anyway, so why not on the body of a = 200 OK? =C2=A0 To be= honestly, I=E2=80=99m puzzled why HTTP should the choice for the communica= tion between peers? It is: -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 a clien= t server protocol, though we need a bidirectional protocol which no clear c= lient and server roles. Extensions to HTTP to let servers send asynchronous messages are on the way, see the BiDirectional or Server-Initiated HTTP (h= ybi) working group (http://datatracker.ietf.org/wg/hybi/charter/). Howe= ver, this is not yet finished; -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 it has = a considerable overhead caused by the HTTP headers on the wire, compared to= the message content (e.g., chunk maps); A good example is google=E2=80=99s work on spdy, which has the goal to reduce the HTTP headers. See this link= (http://dev.chromium.org/spdy/spdy-whitepaper): =E2=80=9CUncompressed = request and response headers. Request headers today vary in size from ~200 = bytes to over 2KB.=E2=80=9D; -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 it has = a considerable overhead when implementing it, e.g., code size. I know that = many p2p clients have a HTTP stack, but it should not be mandatory to implement IMO. = I would say that HTTP is a request/reply protocol between hosts. Anyway, fo= r a Streaming environment, what a media Player interfaces is with "str= eaming server nodes", and so, we may think of Peers as the Streaming s= ervers for a Client Media Player. So, any Peer is in fact a provider (server)=C2=A0entity for othe= r interested Peers, but also a consumer (client) of the media available in = the other Peers. Considering streaming of segmented media,= the chunks have quite a large size, ranging from as low as 5KiB to ~200 Ki= B (typical in scalable coding) for media chunk playout duration of ~2 secon= ds (for High Quality videos). The HTTP header size (and request body) =C2= =A0is then comparatively small. Additionally, for these media chunk sizes (200+ KiB), a high quality n= on scalable video needs around one request every 2 seconds (not considering= any special strategy for piece picking). This is quite different from the = typical implementations of streaming via BitTorrent-like techniques, that n= eed a quite large amount of requests per second for the very same video pla= yout duration. For scalable media, this is an advantage for the strategy of requestin= g the layers of a chunk up to a certain quality (eventually the maximum) in= the very same time window. Additionally, and for scalable media, the proba= bility of smooth playout without rebuffering is very high. This is one of the reasons for the adoption of HTTP Adaptive Streaming= techniques from 3GPP and ISO, in special for mobile environment. There are= already applications for Live Streaming using HTTP for smartphones and aTa= blets, over 3G or Wi-Fi, providing a high quality of experience to the user= . An example is the Bloomberg App for the iPad. =C2=A0 Reusi= ng existing protocols is a good idea, but I have the feeling that we are st= retching it a bit too much in this case. =C2=A0 My fe= w cents =C2=A0 =C2= =A0 Martin =C2=A0 martin.stiemer= ling@neclab.eu =C2=A0 NEC L= aboratories Europe - Network Research Division NEC Europe Limited | Registe= red Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 =C2=A0 From:= ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui Cruz Sent: Tuesday, November 01, 2011 2:39 PM To: li.li= chun1@zte.com.cn Cc: Rui Cruz; pps= p@ietf.org; = ppsp-bounces@ietf.org Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-= protocol-03.txt =C2=A0 Indeed, I suppose nothing prevents using HTTP/XML ov= er UDP, as messages typically fit in UDP datagrams and the methods used for= requests are POST. In the draft the transport protocol to be used for t= he signaling was not specified and it is open to discussion.<= /p> --------------------------- B= est Regards, Prof. Rui Santos Cruz Chairman IEEE=C2=A0Portugal Section Av. Prof. Dr. = An=C3=ADbal Cavaco Silva,=C2=A0IST-TagusPark, Office 1-5,=C2=A02744-016 Por= to Salvo, Portugal +351 214 233 200 (ext 5044),=C2=A0+351.939 060 939<= /a> (mobile) rui.cruz@ieee.org=C2=A0 rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org= Advancing techn= ology for humanity. =C2=A0 On 01/11/2011, at 01:55, li.lichun1@zte.com.cn wrote: I think XML over UDP is also a good option= . BR Lichun ppsp-bounces@ietf.org =E5=86=99=E4=BA=8E 2011-11-01 09:21:28:<= /tt> > Hi, > > We have updated the PPSP Tracker Protocol draft, corresponding to = > the merge of the former drafts from Gu and Cruz. > > This version mainly focus on the messages exchanged between peers,= > but leave the encoding format into Appendix since using binary or = > HTTP/XML as container is still under dispute. > > Please let us know your comments and suggestions. > > Thanks. > > Jinwei > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf= .org [mailto:internet-drafts@ietf.org] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2011=E5=B9=B410=E6=9C=8831=E6=97=A5 19:04 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xiajinwei= > =E6=8A=84=E9=80=81: Xiajinwei; Yingjie= Gu(yingjie); mario.nunes@inov.pt; joao. > silva@inov.pt; rui.cruz@ieee.org; dbryan@ethernot.org > =E4=B8=BB=E9=A2=98: New Version Notifi= cation for draft-gu-ppsp-peer-protocol-03.txt > > A new version of I-D, draft-gu-ppsp-peer-protocol-03.txt has been = > successfully submitted by Jinwei Xia and posted to the IETF reposi= tory. > > Filename: =C2=A0 =C2=A0draft-gu-ppsp-peer-protocol > Revision: =C2=A0 =C2=A003 > Title: =C2=A0 =C2=A0 =C2=A0 Peer Protocol > Creation date: =C2=A0 =C2=A02011-10-31 > WG ID: =C2=A0 =C2=A0 =C2=A0 Individual Submission > Number of pages: 31 > > Abstract: > =C2=A0 =C2=A0This document presents the architecture of the PPSP P= eer protocol > =C2=A0 =C2=A0outlining the functional entities, message flows and = message > =C2=A0 =C2=A0processing instructions, with the respective paramete= rs. =C2=A0The PPSP > =C2=A0 =C2=A0Peer Protocol proposed in this document extends the c= apabilities of > =C2=A0 =C2=A0PPSP to support adaptive and scalable video and 3D vi= deo, for Video > =C2=A0 =C2=A0On Demand (VoD) and Live video services. =C2=A0The pr= otocol messages > =C2=A0 =C2=A0formal syntax and semantics, methods, and formats are= presented for > =C2=A0 =C2=A0both Binary and HTTP/XML encoded formats. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > > > The IETF Secretariat > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp= --------------------------------------------------------= ZTE=C2=A0Information=C2=A0Security=C2=A0Notice:=C2=A0The=C2=A0informat= ion=C2=A0contained=C2=A0in=C2=A0this=C2=A0mail=C2=A0is=C2=A0solely=C2=A0pro= perty=C2=A0of=C2=A0the=C2=A0sender's=C2=A0organization.=C2=A0This=C2=A0= mail=C2=A0communication=C2=A0is=C2=A0confidential.=C2=A0Recipients=C2=A0nam= ed=C2=A0above=C2=A0are=C2=A0obligated=C2=A0to=C2=A0maintain=C2=A0secrecy=C2= =A0and=C2=A0are=C2=A0not=C2=A0permitted=C2=A0to=C2=A0disclose=C2=A0the=C2= =A0contents=C2=A0of=C2=A0this=C2=A0communication=C2=A0to=C2=A0others. This=C2=A0email=C2=A0and=C2=A0any=C2=A0files=C2=A0transmitted=C2=A0wit= h=C2=A0it=C2=A0are=C2=A0confidential=C2=A0and=C2=A0intended=C2=A0solely=C2= =A0for=C2=A0the=C2=A0use=C2=A0of=C2=A0the=C2=A0individual=C2=A0or=C2=A0enti= ty=C2=A0to=C2=A0whom=C2=A0they=C2=A0are=C2=A0addressed.=C2=A0If=C2=A0you=C2= =A0have=C2=A0received=C2=A0this=C2=A0email=C2=A0in=C2=A0error=C2=A0please= =C2=A0notify=C2=A0the=C2=A0originator=C2=A0of=C2=A0the=C2=A0message.=C2=A0A= ny=C2=A0views=C2=A0expressed=C2=A0in=C2=A0this=C2=A0message=C2=A0are=C2=A0t= hose=C2=A0of=C2=A0the=C2=A0individual=C2=A0sender. This=C2=A0message=C2=A0has=C2=A0been=C2=A0scanned=C2=A0for=C2=A0viruse= s=C2=A0and=C2=A0Spam=C2=A0by=C2=A0ZTE=C2=A0Anti-Spam=C2=A0system.= _______________________________________________ ppsp mailing list ppsp@ietf.org ht= tps://www.ietf.org/mailman/listinfo/ppsp =C2=A0 ___________________= ____________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org ht= tps://www.ietf.org/mailman/listinfo/ppsp --000e0cdfce8c33352f04b18f4370-- From kiraly@disi.unitn.it Sat Nov 12 17:18:11 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2233621F8A70 for ; Sat, 12 Nov 2011 17:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.718 X-Spam-Level: X-Spam-Status: No, score=-4.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2on9WtDuqD4i for ; Sat, 12 Nov 2011 17:18:07 -0800 (PST) Received: from mail2.unitn.it (mail2.unitn.it [193.205.206.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2543C21F8A69 for ; Sat, 12 Nov 2011 17:18:05 -0800 (PST) Received: from mail2.unitn.it (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DFC77501B7 for ; Sun, 13 Nov 2011 02:18:03 +0100 (CET) Received: from mailhub1.unitn.it (mailhub1.unitn.it [192.168.206.46]) by mail2.unitn.it (Postfix) with ESMTP id 4D642501AF for ; Sun, 13 Nov 2011 02:18:03 +0100 (CET) Received: from disi.unitn.it (dit.unitn.it [193.205.194.4]) by mailhub1.unitn.it (Postfix) with ESMTP id 3C462AE5466 for ; Sun, 13 Nov 2011 02:18:03 +0100 (CET) Received: from [192.168.1.100] (host65-109-dynamic.245-95-r.retail.telecomitalia.it [95.245.109.65]) (authenticated bits=0) by disi.unitn.it (8.13.8/8.13.8) with ESMTP id pAD1I1or015359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 13 Nov 2011 02:18:02 +0100 Message-ID: <4EBF1AC9.4000204@disi.unitn.it> Date: Sun, 13 Nov 2011 02:18:01 +0100 From: Csaba Kiraly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: ppsp@ietf.org References: <203D03ED-A024-4403-AE8B-B02FF58F5550@ieee-pt.org> In-Reply-To: <203D03ED-A024-4403-AE8B-B02FF58F5550@ieee-pt.org> Content-Type: multipart/alternative; boundary="------------000705080700050000030909" Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 01:18:11 -0000 This is a multi-part message in MIME format. --------------000705080700050000030909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Martin, Hi Rui, On 11/12/2011 07:10 PM, Rui Cruz wrote: > Hi Martin, > see my comments inline. > > Cumprimentos/Regards, > Rui Cruz > > Sent from my iPad2 > > On 09/11/2011, at 15:36, Martin Stiemerling > wrote: > >> [Speaking as individual] >> >> Hi all, >> >> I guess HTTP is only defined to run over TCP and not over UDP for various reasons, e.g., >> >> -HTTP messages exceed the size of an UDP datagram, except in some corner cases; >> >> -There is no reliable transport, flow and congestion control in UDP; >> >> -A HTTP GET can result in a very large 200 OK message. >> >> This definitely rules out HTTP over UDP. >> > > Well, UPnP uses HTTP over UDP in discovery messages. This can be done, although it is questionable what sense it makes. HTTP is defined in a reliable stream context. If you know for sure that you use only a very restricted subset of HTTP features (only a request and a response, only what fits in one packet, etc.), it can even work, but there are so many other things that work, why chose this specific one? I know it was just an example, but it sounds like a workaround. I did not read through the UPnP docs, but I think it is in fact a workaround that fakes HTTP, but one side is not a standards compliant HTTP server, and the other side is not a standards compliant HTTP client. These entities only use some HTTP like headers, but then they do not comply. I should emphasize that I did not check carefully, but if this is the case, this is really bad protocol design. Why one writes HTTP/1.1 in a header when in fact it can't comply with it? > Using HTTP/XML encoding for signaling, results mostly in small sized messages, as the main information is in the body and not in the resource and header, and the total is typically smaller than the size of a UDP datagram. Wait a second. You mean that putting contect encoded with XML over HTTP over UDP is smaller than content over UDP? I think I don't understand this statement. The overhead might be small, it might even be irrelevant in some use cases (like you say below), but it is an overhead. You will not spare bits on the wire by adding HTTP and XML. > About reliability and congestion control, that is correct, therefore the preference on using TCP when reliability is required. > The protocol we designed uses POST messages for requests and takes advantage of getting the replies with the requested data as payload on the body of 200 OK. The reply would have to be transported anyway, so why not on the body of a 200 OK? > >> To be honestly, I'm puzzled why HTTP should the choice for the communication between peers? It is: >> >> -a client server protocol, though we need a bidirectional protocol which no clear client and server roles. Extensions to HTTP to let servers send asynchronous messages are on the way, see the BiDirectional or Server-Initiated HTTP (hybi) working group (http://datatracker.ietf.org/wg/hybi/charter/). However, this is not yet finished; >> >> -it has a considerable overhead caused by the HTTP headers on the wire, compared to the message content (e.g., chunk maps); A good example is google's work on spdy, which has the goal to reduce the HTTP headers. See this link (http://dev.chromium.org/spdy/spdy-whitepaper): "Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB."; >> >> -it has a considerable overhead when implementing it, e.g., code size. I know that many p2p clients have a HTTP stack, but it should not be mandatory to implement IMO. >> > > I would say that HTTP is a request/reply protocol between hosts. Anyway, for a Streaming environment, what a media Player interfaces is with "streaming server nodes", and so, we may think of Peers as the Streaming servers for a Client Media Player. > So, any Peer is in fact a provider (server) entity for other interested Peers, but also a consumer (client) of the media available in the other Peers. > Considering streaming of segmented media, the chunks have quite a large size, ranging from as low as 5KiB to ~200 KiB (typical in scalable coding) for media chunk playout duration of ~2 seconds (for High Quality videos). The HTTP header size (and request body) is then comparatively small. > Additionally, for these media chunk sizes (200+ KiB), a high quality non scalable video needs around one request every 2 seconds (not considering any special strategy for piece picking). This is quite different from the typical implementations of streaming via BitTorrent-like techniques, that need a quite large amount of requests per second for the very same video playout duration. > For scalable media, this is an advantage for the strategy of requesting the layers of a chunk up to a certain quality (eventually the maximum) in the very same time window. Additionally, and for scalable media, the probability of smooth playout without rebuffering is very high. > This is one of the reasons for the adoption of HTTP Adaptive Streaming techniques from 3GPP and ISO, in special for mobile environment. There are already applications for Live Streaming using HTTP for smartphones and aTablets, over 3G or Wi-Fi, providing a high quality of experience to the user. An example is the Bloomberg App for the iPad. I do not exactly understand how scalable media comes in the picture, it can work with HTTP or without, it seems to be an orthogonal issue. From what you say here it seems that using HTTP is not such a big issue in your specific system design (which is largely different from many other P2P streaming system designs). It works, and it even works well. My question is: what do you gain by using HTTP and not something else? IMHO other systems that are not using HTTP are working well too. These systems might use different chunk sizes, large or small, and they are still not bottlenecked by HTTP, simply because they do not use it. There are also designs that are using one-way notification messages that doesn't require a response. I do not see how these could be mapped over HTTP without performance drawbacks. So, my second question is: does your design need any specific feature of HTTP such that a reuse of HTTP is necessary? Turning back to the previous point: if you look at these entities as HTTP servers and clients, you need to be sure to make a nice compliant implementation of an HTTP server and client. At first it sounds like a non-issue, but doing it well over UDP doesn't sound like something easy, especially if there are no benefits. Even over TCP, defining protocol behavior might get quite complicated if you have to think of all the corner cases HTTP offers. Having said all this, I'm not against the optional use of HTTP. However, I think it is better to differentiate encoding options for the messaging primitives from transport options. There might e.g. be 2 encoding options (binary and XML), and a number of transport options: reliable stream, like TCP; unreliable datagram, like UDP. There might even be a third one that maps the protocol over the more restrictive request/response model of HTTP. However, doing this latter correctly might get quite cumbersome, since it should detail the handling of various HTTP headers, HTTP options, etc. Just my 2c Csaba --------------000705080700050000030909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Martin, Hi Rui, On 11/12/2011 07:10 PM, Rui Cruz wrote: Hi Martin, see my comments inline. Cumprimentos/Regards, Rui Cruz Sent from my iPad2 On 09/11/2011, at 15:36, Martin Stiemerling <Martin.Stiemerling@neclab.eu> wrote: [Speaking as individual] Hi all, I guess HTTP is only defined to run over TCP and not over UDP for various reasons, e.g., - HTTP messages exceed the size of an UDP datagram, except in some corner cases; - There is no reliable transport, flow and congestion control in UDP; - A HTTP GET can result in a very large 200 OK message. This definitely rules out HTTP over UDP. Well, UPnP uses HTTP over UDP in discovery messages. This can be done, although it is questionable what sense it makes. HTTP is defined in a reliable stream context. If you know for sure that you use only a very restricted subset of HTTP features (only a request and a response, only what fits in one packet, etc.), it can even work, but there are so many other things that work, why chose this specific one? I know it was just an example, but it sounds like a workaround. I did not read through the UPnP docs, but I think it is in fact a workaround that fakes HTTP, but one side is not a standards compliant HTTP server, and the other side is not a standards compliant HTTP client. These entities only use some HTTP like headers, but then they do not comply. I should emphasize that I did not check carefully, but if this is the case, this is really bad protocol design. Why one writes HTTP/1.1 in a header when in fact it can't comply with it? Using HTTP/XML encoding for signaling, results mostly in small sized messages, as the main information is in the body and not in the resource and header, and the total is typically smaller than the size of a UDP datagram. Wait a second. You mean that putting contect encoded with XML over HTTP over UDP is smaller than content over UDP? I think I don't understand this statement. The overhead might be small, it might even be irrelevant in some use cases (like you say below), but it is an overhead. You will not spare bits on the wire by adding HTTP and XML. About reliability and congestion control, that is correct, therefore the preference on using TCP when reliability is required. The protocol we designed uses POST messages for requests and takes advantage of getting the replies with the requested data as payload on the body of 200 OK. The reply would have to be transported anyway, so why not on the body of a 200 OK? To be honestly, I’m puzzled why HTTP should the choice for the communication between peers? It is: - a client server protocol, though we need a bidirectional protocol which no clear client and server roles. Extensions to HTTP to let servers send asynchronous messages are on the way, see the BiDirectional or Server-Initiated HTTP (hybi) working group (http://datatracker.ietf.org/wg/hybi/charter/). However, this is not yet finished; - it has a considerable overhead caused by the HTTP headers on the wire, compared to the message content (e.g., chunk maps); A good example is google’s work on spdy, which has the goal to reduce the HTTP headers. See this link (http://dev.chromium.org/spdy/spdy-whitepaper): “Uncompressed request and response headers. Request headers today vary in size from ~200 bytes to over 2KB.”; - it has a considerable overhead when implementing it, e.g., code size. I know that many p2p clients have a HTTP stack, but it should not be mandatory to implement IMO. I would say that HTTP is a request/reply protocol between hosts. Anyway, for a Streaming environment, what a media Player interfaces is with "streaming server nodes", and so, we may think of Peers as the Streaming servers for a Client Media Player. So, any Peer is in fact a provider (server) entity for other interested Peers, but also a consumer (client) of the media available in the other Peers. Considering streaming of segmented media, the chunks have quite a large size, ranging from as low as 5KiB to ~200 KiB (typical in scalable coding) for media chunk playout duration of ~2 seconds (for High Quality videos). The HTTP header size (and request body) is then comparatively small. Additionally, for these media chunk sizes (200+ KiB), a high quality non scalable video needs around one request every 2 seconds (not considering any special strategy for piece picking). This is quite different from the typical implementations of streaming via BitTorrent-like techniques, that need a quite large amount of requests per second for the very same video playout duration. For scalable media, this is an advantage for the strategy of requesting the layers of a chunk up to a certain quality (eventually the maximum) in the very same time window. Additionally, and for scalable media, the probability of smooth playout without rebuffering is very high. This is one of the reasons for the adoption of HTTP Adaptive Streaming techniques from 3GPP and ISO, in special for mobile environment. There are already applications for Live Streaming using HTTP for smartphones and aTablets, over 3G or Wi-Fi, providing a high quality of experience to the user. An example is the Bloomberg App for the iPad. I do not exactly understand how scalable media comes in the picture, it can work with HTTP or without, it seems to be an orthogonal issue. From what you say here it seems that using HTTP is not such a big issue in your specific system design (which is largely different from many other P2P streaming system designs). It works, and it even works well. My question is: what do you gain by using HTTP and not something else? IMHO other systems that are not using HTTP are working well too. These systems might use different chunk sizes, large or small, and they are still not bottlenecked by HTTP, simply because they do not use it. There are also designs that are using one-way notification messages that doesn't require a response. I do not see how these could be mapped over HTTP without performance drawbacks. So, my second question is: does your design need any specific feature of HTTP such that a reuse of HTTP is necessary? Turning back to the previous point: if you look at these entities as HTTP servers and clients, you need to be sure to make a nice compliant implementation of an HTTP server and client. At first it sounds like a non-issue, but doing it well over UDP doesn't sound like something easy, especially if there are no benefits. Even over TCP, defining protocol behavior might get quite complicated if you have to think of all the corner cases HTTP offers. Having said all this, I'm not against the optional use of HTTP. However, I think it is better to differentiate encoding options for the messaging primitives from transport options. There might e.g. be 2 encoding options (binary and XML), and a number of transport options: reliable stream, like TCP; unreliable datagram, like UDP. There might even be a third one that maps the protocol over the more restrictive request/response model of HTTP. However, doing this latter correctly might get quite cumbersome, since it should detail the handling of various HTTP headers, HTTP options, etc. Just my 2c Csaba --------------000705080700050000030909-- From mls.ietf@googlemail.com Sat Nov 12 23:11:03 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2B21F8AFA for ; Sat, 12 Nov 2011 23:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+ZmRUvjVZ7U for ; Sat, 12 Nov 2011 23:11:02 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB04121F8AF9 for ; Sat, 12 Nov 2011 23:11:01 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so5810886bkb.31 for ; Sat, 12 Nov 2011 23:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QKiho0Ed2QbL+L8mb3OcT93fjQBIk0EIbDBdA6nuLuI=; b=DuXmqflva7Erw+PEipeKoZALpneyfSQSfpWUuYaTcpXOZzi5nlbs21FCJYbLyRrGhf JAOh8hOq3Di5f1/Jt2yUX9P0NeRbkhB3Pw9mJLzLgBOcwMpljo3exm67Hin5holvq/zc LXpCT+ovBXS5G/8MqrxM4rDJdr715UfPUQc5I= Received: by 10.204.156.68 with SMTP id v4mr14431830bkw.88.1321168260825; Sat, 12 Nov 2011 23:11:00 -0800 (PST) Received: from [0.0.0.0] (port-92-202-119-160.dynamic.qsc.de. [92.202.119.160]) by mx.google.com with ESMTPS id x14sm23256128bkf.10.2011.11.12.23.10.56 (version=SSLv3 cipher=OTHER); Sat, 12 Nov 2011 23:10:59 -0800 (PST) Message-ID: <4EBF2F33.80606@googlemail.com> Date: Sun, 13 Nov 2011 03:45:07 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rui Cruz References: <20111031112206.30317.90541.idtracker@ietfa.amsl.com> <9582A85E-E4E3-43B9-97C9-C46C17BA4B7D@ieee.org> In-Reply-To: <9582A85E-E4E3-43B9-97C9-C46C17BA4B7D@ieee.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: ppsp Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:11:03 -0000 Hi Rui, On 11/10/2011 12:55 PM, Rui Cruz wrote: [...] > > On 09/11/2011, at 14:46, Martin Stiemerling wrote: > >> [Speaking as individual] >> Hi, >> I have read the merged version of the tracker protocol and it is for >> me on the right technical track. I have some issues: >> -Section 3.7 deals with the media presentation description. I see this >> orthogonal to the tracker protocol, though there can be dependencies >> if the presentation description contains information about the >> trackers. However, it is not the task of the tracker protocol draft to >> define how the actual information about the location of trackers is >> conveyed to the peers. I would remove it completely, or add an >> appendix where the potential dependency between presentation >> description and information about trackers is discussed. This would >> give space to talk the many different presentation descriptions >> available out there. > > I agree that the Media Presentation Description may be considered > orthogonal to the protocol. However, there are in fact dependencies > related to the identification of trackers for the media/stream (swarm) > described in the MPD, as well as for the structure of the media/stream. > This can be "compared" to a .torrent file, that plays somehow the role > of the MPD in the case of BitTorrent protocol, and as you know, the > .torrent file contains information about the trackers and the mapping of > the chunks/pieces of the content. > I agree that description of the MPD can be moved, with the necessary > adaptions in the main text, to an Appendix. This would be good, but please check also for the IETF choice for presentation descriptions: SDP. > >> -The relationship between the tracker protocol and SVC/MDC/and friends >> is not clear to me just from reading the draft. I see codec issues >> more related to the presentation description but not the tracker >> protocol. However, I�m happy to be convinced by you that there is a >> relationship. > > The Tracker protocol (as well as the Peer protocol) are bound to "VoD or > Live streaming of multimedia" (with the necessary constraints), not for > simple file sharing. > However, a very important principle should be observed, in my opinion, > related to the role these protocols play in the streaming process, as > they should be open to support both "Structured Media" > (SVC/MDC/MVC/multi-bitrate) and unstructured media, but *not being > involved in the decoding/encoding processes of the "Structured Media"*. > It is the Media Player application, not the protocols associated with > the transport of the Media, the entity that should "know" (via a > requester/re-assembler module) how and what to request (to a "peer") and > decode the received "Structured Media" (from the "peer") in order to > "present" it to the User. I sense that you are saying that it is not necessary to capture the notion of structured or unstructured media in the tracker protocol. However, I might misunderstand your text. > As far as I know, other implementations of P2P media streaming, either > do not support "Structured Media" or, to support it, are deeply involved > in the requester/re-assembler decoding process, for example, splitting > SVC layers or MDC descriptions in different "trees" (push mode), or > using specific "piece picking" strategies and peer selection strategies > for the selection of the SVC layers or MDC descriptions, but integrated > into the P2P protocols. I'm in support of SVC/MDC/AVC, as the ppsp protocols should definitely support those type of codecs. I'm only not sure what the impact is the protocols, though I see the impact to the presentation description and the mapping of codec elements to the transport. > The Media Presentation Description just helps the processes (associated > with the protocol) to know which are the Trackers controlling it and how > to map the chunks in order to "inform" which Peer HAS which Chunk (and > corresponding layers/descriptions etc.), but not tacking decisions on > layer/description fetching priorities, unless "instructed" by the > external requester/re-assembler module of the Media Player. > >> -Figure 2: Is this referring to a particular implementation or is it >> meant to show the conceptual data structures? Anyhow, the >> relationships between the different parameters are not clear and it >> may not be required to flesh this completely out. I guess a purely >> textual description would be better, without going into the detail >> what the conceptual data structures of a tracker are. > > Ok, I agree with that. We will revise it for next version Thanks! > >> -Table1/Request Messages: >> oI see that the messages there are required on a semantically level, >> but I�m not so sure that we need all those messages in the protocol. >> For instance, the LEAVE and DISCONNECT messages are used in a combined >> way (or interchangeable way) in Figure 3 (see the bottom). Thus LEAVE >> seems to have a similar semantics like DISCONNECT. > > A Peer may have JOINed several swarms, and be just contributing to those > swarms, but the user may decide to LEAVE a specific swarm, not > DISCONNECT from the system, and continue contributing or JOINing a new > swarm to watch a content, while still contributing to other swarms. The > semantics may seem similar but the purpose is more granular with the > LEAVE. Eventually, the DISCONNECT message may play the same role as > LEAVE when specifying a Swarm-ID. Let's discuss this option in the > meeting and mailing list. Yes, let's discuss the messages at the meeting. > Figure 3 just gives a typical example, although I recognize that it > should not raise these doubts. We will revise it. > >> oKEEPALIVE is required on the semantically level, but it could be >> modeled with another message. > > Agreed. > >> oThe point I�m trying to make: In the bittorrent tracker protocol, >> there is only a GET which pulls information about peers from the >> tracker to the peer and updates the tracker about the peer issuing the >> GET. This is also used as keep alive. This may be overloading a single >> message, but on the other hand hints to the fact that only a very >> limited amount of messages on the wire are required. > > Agreed. The STAT_REPORT can be used for the same purpose. Let's discuss > this option in the meeting and mailing list. Potentially the tracker protocol needs only a few methods, but can have additional parameters which convey the information needed to implement, for example, the keepalive. > >> -HTTP error codes vs. protocol error codes: I do not see the clear >> separation in the draft between what the HTTP error codes indicate and >> what the tracker protocol error codes are. For instance the HTTP error >> code 400 is already overloaded with 2 meanings: invalid syntax (by the >> way of what: HTTP or message body of HTTP) and version not supported. >> This does not look very clean, easy to implement, and also future proof. > > Also agreed. Let's discuss if we can just use standard HTTP error codes > without overloading with multiple meaning, in the meeting and mailing list. > The ALTO working group had a similar issue, i.e., reusing the HTTP error codes for the actual ALTO protocol, and it turned out that there is the need to have two levels of error codes. The HTTP ones for the HTTP level (which is the actual transport) and ALTO (our in our case tracker) specific error codes. Both levels may not match in their error conditions. For instance, the HTTP request response pair may be completed successfully (no HTTP syntax errors, correct URIl, etc), but the tracker protocol itself may run into an error condition (e.g., swarm not found). Thanks and see you at the meeting Martin From mls.ietf@googlemail.com Sat Nov 12 23:11:15 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621E521F8AFE for ; Sat, 12 Nov 2011 23:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt8kRWXoyMIN for ; Sat, 12 Nov 2011 23:11:14 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E50021F8AFA for ; Sat, 12 Nov 2011 23:11:14 -0800 (PST) Received: by mail-bw0-f44.google.com with SMTP id zv15so5810886bkb.31 for ; Sat, 12 Nov 2011 23:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=FdVUdOAN8+xY+TZlGp66G3/QCnZJ5VAccDWm9It7DWo=; b=fo+5dOvoNz2jNeNSk7kb5M/zwmlAQFayG1JeD6N+d5rMjzBZl3yQvllLlNDRJFWmCF pRFOV3jpJwLJna+5aZ/i172gm6Sgw26GngI/WEkO+bRh6Pu1bhfWes0lYa2UAM7tCRhs MYRxCJJHFe+dgWiBJnfcqkV+53IuWjPJfXOEM= Received: by 10.204.41.66 with SMTP id n2mr14354906bke.77.1321168274135; Sat, 12 Nov 2011 23:11:14 -0800 (PST) Received: from [0.0.0.0] (port-92-202-119-160.dynamic.qsc.de. [92.202.119.160]) by mx.google.com with ESMTPS id dq2sm22657594bkb.11.2011.11.12.23.11.10 (version=SSLv3 cipher=OTHER); Sat, 12 Nov 2011 23:11:13 -0800 (PST) Message-ID: <4EBF3023.7020306@googlemail.com> Date: Sun, 13 Nov 2011 03:49:07 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rui Cruz References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Question about SVC/AVC support (peer proto) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 07:11:15 -0000 Rui, I should have written that this email was about the peer protocol, vs my earlier email which was about the tracker protocol. I would like to know if you have any supported for structured codecs in your implementation, since you stress the fact to support in PPSP; and what the implications to the peer protocol are. Is there any change required in the way how the "chunk maps" are treated or how the actual chunks are identified in the protocol, or how they are exchanged? Thanks, Martin On 11/10/2011 01:20 PM, Rui Cruz wrote: > Hi Martin, > > Perhaps, I my apologies for repeating here what I answered in a previous > message, that PPSP should support both "Structured Media" > (SVC/MDC/MVC/multi-bitrate) and unstructured media (AVC) or other > formats, although the trend in the Internet has been for H.264 > MPEG-4/AVC and its extensions SVC, MVC. In what respects MDC, it can be > seen as an option, combined or not with SVC, but can perfectly be > supported if the PPSP protocols are "codec agnostic" (not involved in > the decoding process) but just "aware", as, in my opinion, they should be. > > A very important principle should be observed, in my opinion, related to > the role the PPSP protocols play in the streaming process, as they > should be open to support both "Structured Media" > (SVC/MDC/MVC/multi-bitrate) and unstructured media (AVC or other), but > *not being involved in the decoding/encoding processes of the > "Structured Media"*. > It is the Media Player application, not the protocols associated with > the transport of the Media, the entity that should "know" (via a > requester/re-assembler module) how and what to request (to a "peer") and > decode the received "Structured Media" (from the "peer") in order to > "present" it to the User. > > Both latest *draft-gu-ppsp-tracker-protocol* and > *draft-gu-ppsp-peer-protocol *were designed with this principle in mind, > and able to support (but not involved in the decoding) video streams > transmitted at a suitable spacio-temporal resolution, adequate for the > user's display device and networking conditions. > > --------------------------- > Best Regards, > > *Prof. Rui Santos Cruz > *Chairman > *IEEE Portugal Section > *Av. Prof. Dr. An�bal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 > Porto Salvo, Portugal > +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) > rui.cruz@ieee.org > rui.s.cruz@ist.utl.pt > sec.portugal@ieee.org > www.ieee-pt.org > Advancing technology for humanity. > > On 10/11/2011, at 08:56, Martin Stiemerling wrote: > >> Hi, >> >> I ran into SVC/AVC in the tracker draft and in >> draft-gu-ppsp-peer-protocol-03.txt. >> >> For the tracker, I'm not sure what the implications are, whereas for >> the peer protocol I can see implications. >> >> However, there has been no large scale discussion if the PPSP peer >> protocol should actually support SVC/AVC and if it should support it, >> what the implications are. >> >> When writing about this, is there also the need to support MDC? >> >> Can somebody outline what the implications are if we support SVC/AVC >> codecs in the peer protocol? >> >> Thank you, >> >> Martin >> >> martin.stiemerling@neclab.eu >> >> NEC Laboratories Europe - Network Research Division NEC Europe Limited >> | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | >> Registered in England 2832014 >> >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From zhangyunfei@chinamobile.com Sun Nov 13 07:17:45 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9607121F8A7D for ; Sun, 13 Nov 2011 07:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.944 X-Spam-Level: X-Spam-Status: No, score=-96.944 tagged_above=-999 required=5 tests=[AWL=1.679, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69PWe9yNMnmq for ; Sun, 13 Nov 2011 07:17:45 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4919921F8AFE for ; Sun, 13 Nov 2011 07:17:44 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id E2E4AEE61 for ; Sun, 13 Nov 2011 23:17:42 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id D58E4EDD4 for ; Sun, 13 Nov 2011 23:17:42 +0800 (CST) Received: from ady-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011111323174058-3140 ; Sun, 13 Nov 2011 23:17:40 +0800 Date: Sun, 13 Nov 2011 23:17:38 +0800 From: zhangyunfei To: ppsp References: <2011110818102446604911@chinamobile.com>, <4EBB3C26.2010604@mti-systems.com> <201111101112067362719@chinamobile.com>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2011111323173827386824@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-13 23:17:41, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-13 23:17:42, Serialize complete at 2011-11-13 23:17:42 Content-Type: multipart/alternative; boundary="----=_001_NextPart862115248746_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18516.000 X-TM-AS-Result: No--36.981-7.0-31-10 X-imss-scan-details: No--36.981-7.0-31-10;No--36.981-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [ppsp] PPSP draft agenda X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2011 15:17:45 -0000 This is a multi-part message in MIME format. ------=_001_NextPart862115248746_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQ2hyaXN0aWFuLA0KICAgIFRoYW5rcyBmb3IgdGhlIGdvb2Qgc3VnZ2VzdGlvbi4gSG93ZXZl ciBhZnRlciBJIGRpc2N1c3NlZCB3aXRoIE1hcnRpbiAsIHdlIGp1c3QgZm91bmQgdGhhdCBpdCdz IGhhcmQgdG8gZmluZCBhIGJldHRlciB0aW1lIHNsb3QgdG8gZ2F0aGVyIGFsbCB0aGUgaW50ZXJl c3RlZCBhbmQgcmVsYXRlZCBwZW9wbGUgc2luY2UgcGVvcGxlIGFyZSBpbiBxdWl0ZSBkaWZmZXJl bnQgV0dzIGFsbCB0aGUgdGltZSBhbmQgQ3J1eiAod2hvJ2xsIGhhdmUgYSBkZW1vKSB3aWxsIGxl YXZlIG9uIFdlZG5lc2RheS4gDQogICBPdXIgbW90aXZhdGlvbiB0byBwbGFjZSB0aGUgZGVtbyBz aG93IGp1c3QgYWZ0ZXIgdGhlIFBQU1Agc2Vzc2lvbiBpcyB0byBrZWVwIHRoZSBjb250aW51aXR5 IG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBwZWVyIHByb3RvY29sIHdpdGggdGhlIGRlbW9zIG9m IGRpZmZlcmVudCBzeXN0ZW1zIHRvIGhlbHAgdGhlIFdHIGEgYmV0dGVyIGNvbnNpZGVyYXRpb24g b2YgdGhlIHByb3RvY29sIHNlbGVjdGlvbi4NCiAgIE91ciBwbGFubmVkIFBQU1Agc2Vzc2lvbiBz Y2hlZHVsZSBpcyBhYm91dCAxMDAgbWlucywgaS5lLiwgd2UgY2FuIGNvbmNsdWRlIG91ciBQUFNQ IHNlc3Npb24gYXQgYWJvdXQgMTExMCBhbmQgdGhlbiBzdGFydCBvdXIgZGVtbyBzaG93IGZyb20g MTExMC4gIElmIHdlIGNhbiBlbmQgb3VyIGRlbW8gc2hvdyBhdCAxMjAwLCBob3BlZnVsbHkgaXQg d29uJ3QgYWZmZWN0IHRoZSBJU09DIHBhbmVsIHRvbyBtdWNoLiAgUC5TLjogVGhlIHJlc2VydmF0 aW9uIGVtYWlsIGZvciB0aGUgcm9vbSB0byB0aGUgc2VjcmV0YXJ5IGlzIHNlbnQgYmVmb3JlIHlv dXIgcmVtaW5kZXIgZW1haWwgY29tZXM6KC4gIFRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9uIGFu ZCB1bmRlcnN0YW5kaW5nLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoNCkZy b206IFNjaG1pZHQsIENocmlzdGlhbiAxLiAoTlNOIC0gREUvTXVuaWNoKQ0KRGF0ZTogMjAxMS0x MS0xMCAxNzowNA0KVG86IHpoYW5neXVuZmVpOyBXZXNsZXkgRWRkeTsgcHBzcA0KU3ViamVjdDog UkU6IFtwcHNwXSBQUFNQIGRyYWZ0IGFnZW5kYQ0KSGkgWXVuZmVpLA0KUGVyaGFwcyB0aGF0IGlz IG5vdCBhIGdvb2QgaWRlYS4gQXQgdGhlIHNhbWUgdGltZSB0aGVyZSBpcyBhIElTQ08gcGFuZWwg ZGlzY3Vzc2lvbg0KaHR0cDovL3d3dy5pc29jLm9yZy9pc29jL2NvbmZlcmVuY2VzL2lldGY4Mi1i cmllZmluZy8NClRoaXMgY291bGQgcmVkdWNlIHRoZSBwYXJ0aWNpcGFudHMgcmVtYXJrYWJsZS4g UGVyaGFwcyBhbm90aGVyIGRhdGUvdGltZSBpcyBiZXR0ZXI/IEZvciBleGFtcGxlIFdlZG5lc2Rh eSBsdW5jaHRpbWU/DQpCZXN0IFJlZ2FyZHMNCkNocmlzdGlhbg0KIA0KIA0KRnJvbTogcHBzcC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgZXh0IHpoYW5neXVuZmVpDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTAsIDIwMTEgNDox MiBBTQ0KVG86IFdlc2xleSBFZGR5OyBwcHNwDQpTdWJqZWN0OiBSZTogW3Bwc3BdIFBQU1AgZHJh ZnQgYWdlbmRhDQogDQpIaSBXZXMsDQogICAgIFdlIHBsYW4gdG8gcmUtdXNlIHRoZSBzYW1lIHJv b20gYWZ0ZXIgUFBTUCBzZXNzaW9uIHNpbmNlIGl0IHNob3VsZCBiZSB2YWNhbnQgZHVyaW5nIDEx MzAtMTMwMC4gSWYgSUVURiByZXF1aXJlcyBhbiBleHBsaWNpdCByZXF1ZXN0IGZvciB0aGUgcmVz ZXJ2YXRpb24sIEknbGwgZG8gaXQgcmlnaHQgbm93LiBUaGFua3MgZm9yIHRoZSByZW1pbmRlci4N CiANCkJSDQpZdW5mZWkgDQogDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KIA0KRnJvbTogV2VzbGV5IEVk ZHkNCkRhdGU6IDIwMTEtMTEtMTAgMTA6NTENClRvOiBwcHNwDQpTdWJqZWN0OiBSZTogW3Bwc3Bd IFBQU1AgZHJhZnQgYWdlbmRhDQpPbiAxMS84LzIwMTEgNToxMCBBTSwgemhhbmd5dW5mZWkgd3Jv dGU6DQo+IEhpIGZvbGtzLA0KPiAgICAgVGhlIFBQU1AgZHJhZnQgYWdlbmRhIGlzIGF2YWlsYWJs ZSBhdA0KPiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzgyL2FnZW5kYS9wcHNwLnR4 dCBhY2NvcmRpbmcgdG8gdGhlIHRpbWUNCj4gc2xvdCByZXF1ZXN0LiBTZWUgeW91IGluIFRhaXBl aS4NCj4gIA0KIA0KIA0KVGhlICJkZW1vIHNob3ciIHNvdW5kcyB2ZXJ5IGludGVyZXN0aW5nOyAg aXMgdGhlcmUgYSByb29tIHJlc2VydmVkIGZvcg0KaXQgc2luY2UgaXQncyBvdXRzaWRlIHRoZSBt ZWV0aW5nIHNsb3QgdGhhdCBzaG93cyB1cCBvbiB0aGUgbWFpbiBhZ2VuZGENCndlYiBwYWdlPw0K IA0KLS0gDQpXZXMgRWRkeQ0KTVRJIFN5c3RlbXMNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart862115248746_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312" Hi Christian, Thanks for the good suggestion. However=20 after I discussed with Martin , we just found that it's hard to find = a=20 better time slot to gather all the interested and related people since peo= ple=20 are in quite different WGs all the time and Cruz (who'll have a demo)= will=20 leave on Wednesday. Our motivation to place the demo show just after the PPS= P=20 session is to keep the continuity of the discussion on the peer proto= col=20 with the demos of different systems to help the WG a better consideration = of the=20 protocol selection. Our planned PPSP session schedule is about 100 mins, i.e= ., we=20 can conclude our PPSP session at about 1110 and then start our demo show f= rom=20 1110. If we can end our demo show at 1200, hopefully it wo= n't=20 affect the ISOC panel too much. P.S.: The reservation email for = ;the=20 room to the secretary is sent before your reminder email comes:(. Th= anks=20 for your suggestion and understanding. BR Yunfei zhangyunfei From: Schm= idt,=20 Christian 1. (NSN - DE/Munich) Date: 2011-11-10 17:04 To: zhangyunfei; Wesley Eddy; ppsp Subject: RE: [ppsp] PPSP draft agenda Hi=20 Yunfei, Perhaps=20 that is not a good idea. At the same time there is a ISCO panel=20 discussion http://www.= isoc.org/isoc/conferences/ietf82-briefing/ This=20 could reduce the participants remarkable. Perhaps another date/time is bet= ter?=20 For example Wednesday lunchtime? Best=20 Regards Christian From:= =20 ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of e= xt=20 zhangyunfei Sent: Thursday, November 10, 2011 4:12 AM To:<= /B>=20 Wesley Eddy; ppsp Subject: Re: [ppsp] PPSP draft=20 agenda Hi=20 Wes, =20 We plan to re-use the same room after PPSP session since it should be= =20 vacant during 1130-1300. If IETF requires an explicit request for the=20 reservation, I'll do it right now. Thanks for the=20 reminder. BR Yunfei zhangyunfei From: Wesley Eddy<= /DIV> Date: 2011-11-10 10:51 To: ppsp Subject: Re:=20 [ppsp] PPSP draft agenda On 11/8/2011 5:10 AM, zhangyunfei wrote: > Hi folks, > The PPSP draft age= nda is available at > http://www.ietf.org/proceedings/82/agenda/ppsp.txt a= ccording to the time > slot request. See you in Taipei.= > The "demo show" sounds very interesting;&n= bsp; is there a room reserved for= it since it's outside the meeting slo= t that shows up on the main agenda= web page? -- Wes Eddy MTI Systems _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp ------=_001_NextPart862115248746_=------ From Martin.Stiemerling@neclab.eu Mon Nov 14 15:57:46 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D26C21F8E22 for ; Mon, 14 Nov 2011 15:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.285 X-Spam-Level: X-Spam-Status: No, score=-102.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEBt4Rmeg1Zb for ; Mon, 14 Nov 2011 15:57:45 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1664221F8E1D for ; Mon, 14 Nov 2011 15:57:45 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 26B0328000085 for ; Tue, 15 Nov 2011 00:57:44 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMIO5TBBBqoy for ; Tue, 15 Nov 2011 00:57:44 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 0A19E28000080 for ; Tue, 15 Nov 2011 00:57:39 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 15 Nov 2011 00:57:39 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: Updated draft agenda for PPSP session at IETF#82 Thread-Index: AcyjJ6o0KqvCFhp3TC6BTZmNbiTKfw== Date: Mon, 14 Nov 2011 23:57:37 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] Updated draft agenda for PPSP session at IETF#82 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 23:57:46 -0000 Hi all, Here is an updated draft agenda for our today's session. The time slots for= discussing the tracker and peer protocol proposals have been extended. Thi= s will give more time to progress the tracker protocol and the peer protoco= l(s).=20 PPSP Working Group Draft Agenda IETF 82,Taipei TUESDAY, November 15, 2011 0900-1130 --------------------------------------- 1. Administrivia (Chairs,5 min) Note takers, blue sheets, Note Well, Agenda 2. Current Status and Progress(Chairs, 10 min) 3. Tracker Protocol (Cruz, 40min)=20 draft-gu-ppsp-tracker-protocol=20 4. Peer Protocol draft-gu-ppsp-peer-protocol (Cruz, 40min) draft-grishchenko-ppsp-swift (Arno, 40min) 5. Tracker Usage for Reload (Lin, 10 min if time permits) draft-xiao-ppsp-reload-distributed-tracker PPSP Demo Show Agenda IETF 82,Taipei TUESDAY, November 15, 2011 1130-1300 Room 101C --------------------------------------- 1. Chair Introduction (Chairs,10 min) 2. Demo Show 2.1 HTML5 video delivered via swift (P2PNEXT) 2.2 P2P streaming demo with http encoding (Cruz) Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From Fabio.Picconi@technicolor.com Mon Nov 14 19:30:00 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C8C1F0DB5 for ; Mon, 14 Nov 2011 19:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb6l71hxji+W for ; Mon, 14 Nov 2011 19:29:59 -0800 (PST) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 57FA81F0DB2 for ; Mon, 14 Nov 2011 19:29:58 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKTsHctP9gi7cs9/arS6QY0eXD6XW+C2J7@postini.com; Mon, 14 Nov 2011 19:29:58 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 Nov 2011 04:29:52 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 Nov 2011 04:29:54 +0100 From: Picconi Fabio To: "ppsp@ietf.org" Date: Tue, 15 Nov 2011 04:29:50 +0100 Thread-Topic: chunk scheduling algorithm Thread-Index: AcyjRtVgdTFvUm3CSaOZLhwd4Jzszg== Message-ID: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_320C4182454E96478DC039F2C48198720471953887MOPESMBX01eut_" MIME-Version: 1.0 Subject: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 03:30:00 -0000 --_000_320C4182454E96478DC039F2C48198720471953887MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here are the references on alternatives to rarest first for live streaming.= The first study has theoretical/simulation results, while the second shows= results based on a real prototype. Thomas Bonald , Laurent Massouli=E9 , Fabien Mathieu , Diego Perino , Andre= w Twigg. Epidemic Live Streaming: Optimal Performance Trade-Offs. In Proc. = of SIGMETRICS, 2008. http://www.thlab.net/~lmassoul/sigmetrics_08.pdf F. Picconi and L. Massouli=E9. Is there a future for mesh-based live video = streaming? In Proc. of P2P, 2008. http://www.thlab.net/~picconi/p2p08.pdf The "latest useful" policy shows its benefits when the users' download wind= ows overlap (which is usually the case for live streaming). For time-shifte= d media (e.g., VoD/catch-up), it's a good idea to distinguish between the d= ownload window next to the playback deadline, and the rest. For the downloa= d window, the simplest choice is "earliest useful" (i.e., prefer the chunk= s closest to the deadline), although combining "earliest useful" with "lat= est useful" will probably give better results if you have users with overla= pping windows. For the remaining chunks (i.e., far from the playback deadli= ne), you probably want to use "rarest first". Fabio --_000_320C4182454E96478DC039F2C48198720471953887MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Here are the references on alternatives to rarest firs= t for live streaming. The first study has theoretical/simulation results, while t= he second shows results based on a real prototype. Thomas Bonald , Laurent Massouli=E9 , Fabien Mathieu ,= Diego Perino , Andrew Twigg. Epidemic Live Streaming: Optimal Performance Trade-O= ffs. In Proc. of SIGMETRICS, 2008. http://www.thlab.net/~lmassoul/sigmetrics_08.pdf F. Picconi and L. Massouli=E9. Is there a future for mesh-based live video streaming? In Proc. of P2P, 2008. ht= tp://www.thlab.net/~picconi/p2p08.pdf The “latest useful” policy shows its benef= its when the users’ download windows overlap (which is usually the case f= or live streaming). For time-shifted media (e.g., VoD/catch-up), it’s a = good idea to distinguish between the download window next to the playback deadli= ne, and the rest. For the download window, the simplest choice is “earlie= st useful” =A0(i.e., prefer the chunks closest to the deadline), althoug= h combining “earliest =A0useful” with “latest useful” will prob= ably give better results if you have users with overlapping windows. For the remainin= g chunks (i.e., far from the playback deadline), you probably want to use = 220;rarest first”. Fabio --_000_320C4182454E96478DC039F2C48198720471953887MOPESMBX01eut_-- From kiraly@disi.unitn.it Mon Nov 14 20:19:25 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A2F11E813A for ; Mon, 14 Nov 2011 20:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.718 X-Spam-Level: X-Spam-Status: No, score=-4.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOTtw76t0LL9 for ; Mon, 14 Nov 2011 20:19:22 -0800 (PST) Received: from mail1.unitn.it (mail1.unitn.it [193.205.206.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3D98311E80E5 for ; Mon, 14 Nov 2011 20:19:22 -0800 (PST) Received: from mail1.unitn.it (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 37B225419C; Tue, 15 Nov 2011 05:19:21 +0100 (CET) Received: from mailhub2.unitn.it (mailhub2.unitn.it [192.168.206.47]) by mail1.unitn.it (Postfix) with ESMTP id BE13454193; Tue, 15 Nov 2011 05:19:20 +0100 (CET) Received: from disi.unitn.it (disi.unitn.it [193.205.194.4]) by mailhub2.unitn.it (Postfix) with ESMTP id AE801B0D3D3; Tue, 15 Nov 2011 05:19:20 +0100 (CET) Received: from [192.168.1.100] (host102-20-dynamic.4-87-r.retail.telecomitalia.it [87.4.20.102]) (authenticated bits=0) by disi.unitn.it (8.13.8/8.13.8) with ESMTP id pAF4JJXj001718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2011 05:19:20 +0100 Message-ID: <4EC1E847.6040003@disi.unitn.it> Date: Tue, 15 Nov 2011 05:19:19 +0100 From: Csaba Kiraly User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Picconi Fabio References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> In-Reply-To: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> Content-Type: multipart/alternative; boundary="------------040004010307050803040408" Cc: "ppsp@ietf.org" Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 04:19:25 -0000 This is a multi-part message in MIME format. --------------040004010307050803040408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Fabio, hi all, Another alternative (for live streaming) is Deadline based chunk scheduling. You can find the description of the algorithm, theoretical background and some simulations here: Abeni, L., C. Kiraly, and R. Lo Cigno, "On the Optimal Scheduling of Streaming Applications in Unstructured Meshes", NETWORKING 2009, vol. 5550: Springer Berlin / Heidelberg, pp. 117-130, 2009. http://peerstreamer.org/content/optimal-scheduling-streaming-applications-unstructured-meshes http://napa-wine.eu/twiki/pub/Public/DocumentsOld/abeni_optimal_scheduling-final.pdf The paper presents a combination of a chunk selection and a peer selection algorithm (DLc and RLp, respectively), but the chunk selection algorithm can be used in itself as well. It shows nice behavior and good delivery properties where latest useful policies fail (chunk diffusion delay distribution tends to have a heavy tail with latest useful for many reasons, DLc tries to correct these shortcomings). An extension of the above to structured streams (SVC, MDC and alike) is described in the following paper: Kiraly, C., R. Lo Cigno, and L. Abeni, "Deadline-Based Differentiation in P2P Streaming", GLOBECOM 2010 - 2010 IEEE Global Communications Conference, Miami, FL, USA, IEEE, pp. 1 - 6, 2010. http://peerstreamer.org/content/deadline-based-differentiation-p2p-streaming http://disi.unitn.it/~kiraly/preprints/kiraly-globecom2010-extended.pdf Csaba On 11/15/2011 04:29 AM, Picconi Fabio wrote: > > Hi, > > Here are the references on alternatives to rarest first for live streaming. The first study has theoretical/simulation results, while the second shows results based on a real prototype. > > Thomas Bonald , Laurent Massouli� , Fabien Mathieu , Diego Perino , Andrew Twigg. Epidemic Live Streaming: Optimal Performance Trade-Offs. In Proc. of SIGMETRICS, 2008. > > http://www.thlab.net/~lmassoul/sigmetrics_08.pdf > > F. Picconi and L. Massouli�. Is there a future for mesh-based live video streaming? In Proc. of P2P, 2008. > > http://www.thlab.net/~picconi/p2p08.pdf > > The "latest useful" policy shows its benefits when the users' download windows overlap (which is usually the case for live streaming). For time-shifted media (e.g., VoD/catch-up), it's a good idea to distinguish between the download window next to the playback deadline, and the rest. For the download window, the simplest choice is "earliest useful" (i.e., prefer the chunks closest to the deadline), although combining "earliest useful" with "latest useful" will probably give better results if you have users with overlapping windows. For the remaining chunks (i.e., far from the playback deadline), you probably want to use "rarest first". > > Fabio > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --------------040004010307050803040408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Fabio, hi all, Another alternative (for live streaming) is Deadline based chunk scheduling. You can find the description of the algorithm, theoretical background and some simulations here: Abeni, L., C. Kiraly, and R. Lo Cigno, "On the Optimal Scheduling of Streaming Applications in Unstructured Meshes", NETWORKING 2009, vol. 5550: Springer Berlin / Heidelberg, pp. 117-130, 2009. http://peerstreamer.org/content/optimal-scheduling-streaming-applications-unstructured-meshes http://napa-wine.eu/twiki/pub/Public/DocumentsOld/abeni_optimal_scheduling-final.pdf The paper presents a combination of a chunk selection and a peer selection algorithm (DLc and RLp, respectively), but the chunk selection algorithm can be used in itself as well. It shows nice behavior and good delivery properties where latest useful policies fail (chunk diffusion delay distribution tends to have a heavy tail with latest useful for many reasons, DLc tries to correct these shortcomings). An extension of the above to structured streams (SVC, MDC and alike) is described in the following paper: Kiraly, C., R. Lo Cigno, and L. Abeni, "Deadline-Based Differentiation in P2P Streaming", GLOBECOM 2010 - 2010 IEEE Global Communications Conference, Miami, FL, USA, IEEE, pp. 1 - 6, 2010. http://peerstreamer.org/content/deadline-based-differentiation-p2p-streaming http://disi.unitn.it/~kiraly/preprints/kiraly-globecom2010-extended.pdf Csaba On 11/15/2011 04:29 AM, Picconi Fabio wrote: Hi, Here are the references on alternatives to rarest first for live streaming. The first study has theoretical/simulation results, while the second shows results based on a real prototype. Thomas Bonald , Laurent Massoulié , Fabien Mathieu , Diego Perino , Andrew Twigg. Epidemic Live Streaming: Optimal Performance Trade-Offs. In Proc. of SIGMETRICS, 2008. http://www.thlab.net/~lmassoul/sigmetrics_08.pdf F. Picconi and L. Massoulié. Is there a future for mesh-based live video streaming? In Proc. of P2P, 2008. http://www.thlab.net/~picconi/p2p08.pdf The “latest useful” policy shows its benefits when the users’ download windows overlap (which is usually the case for live streaming). For time-shifted media (e.g., VoD/catch-up), it’s a good idea to distinguish between the download window next to the playback deadline, and the rest. For the download window, the simplest choice is “earliest useful” (i.e., prefer the chunks closest to the deadline), although combining “earliest useful” with “latest useful” will probably give better results if you have users with overlapping windows. For the remaining chunks (i.e., far from the playback deadline), you probably want to use “rarest first”. Fabio _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --------------040004010307050803040408-- From gyuri@kth.se Tue Nov 15 00:55:37 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DDB21F900E for ; Tue, 15 Nov 2011 00:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HplnttKn8gAX for ; Tue, 15 Nov 2011 00:55:32 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2821F9009 for ; Tue, 15 Nov 2011 00:55:30 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 47DD014D7E0; Tue, 15 Nov 2011 09:54:59 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id dZxfMpQUlQ1l; Tue, 15 Nov 2011 09:54:57 +0100 (CET) X-KTH-Auth: gyuri [2001:6b0:1:12b0:221:70ff:feb8:b122] X-KTH-mail-from: gyuri@kth.se Received: from [IPv6:2001:6b0:1:12b0:221:70ff:feb8:b122] (unknown [IPv6:2001:6b0:1:12b0:221:70ff:feb8:b122]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 6C0E114D7D6; Tue, 15 Nov 2011 09:54:56 +0100 (CET) Message-ID: <4EC228E0.4060304@kth.se> Date: Tue, 15 Nov 2011 09:54:56 +0100 From: Gyorgy Dan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Csaba Kiraly References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> In-Reply-To: <4EC1E847.6040003@disi.unitn.it> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "ppsp@ietf.org" Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 08:55:38 -0000 Hi Csaba, Fabio, all, There are many alternatives for scheduling, but IMHO no extensive comparison of recent algorithms. It is also good to keep in mind that the performance of the algorithms depends significantly on the assumptions made for the evaluation. This study, for example, shows how the performance of random push policies deteriorates if the evaluation accounts for the delay needed to exchange signaling messages between the peers: I. Chatzidrossos, G. D�n and V. Fodor, ``Delay and playout probability trade-off in mesh-based peer-to-peer streaming with delayed buffer map updates,'' in Peer-to-peer Networking and Applications, vol. 3., num. 1., Mar. 2010 Gy�rgy On 11/15/2011 05:19 AM, Csaba Kiraly wrote: > Hi Fabio, hi all, > > Another alternative (for live streaming) is Deadline based chunk > scheduling. You can find the description of the algorithm, theoretical > background and some simulations here: > > Abeni, L., C. Kiraly, and R. Lo Cigno, "On the Optimal Scheduling of > Streaming Applications in Unstructured Meshes", NETWORKING 2009, vol. > 5550: Springer Berlin / Heidelberg, pp. 117-130, 2009. > http://peerstreamer.org/content/optimal-scheduling-streaming-applications-unstructured-meshes > http://napa-wine.eu/twiki/pub/Public/DocumentsOld/abeni_optimal_scheduling-final.pdf > > The paper presents a combination of a chunk selection and a peer > selection algorithm (DLc and RLp, respectively), but the chunk selection > algorithm can be used in itself as well. It shows nice behavior and good > delivery properties where latest useful policies fail (chunk diffusion > delay distribution tends to have a heavy tail with latest useful for > many reasons, DLc tries to correct these shortcomings). > > An extension of the above to structured streams (SVC, MDC and alike) is > described in the following paper: > > Kiraly, C., R. Lo Cigno, and L. Abeni, "Deadline-Based Differentiation > in P2P Streaming", GLOBECOM 2010 - 2010 IEEE Global Communications > Conference, Miami, FL, USA, IEEE, pp. 1 - 6, 2010. > http://peerstreamer.org/content/deadline-based-differentiation-p2p-streaming > http://disi.unitn.it/~kiraly/preprints/kiraly-globecom2010-extended.pdf > > Csaba > > > > On 11/15/2011 04:29 AM, Picconi Fabio wrote: >> >> Hi, >> >> >> >> Here are the references on alternatives to rarest first for live >> streaming. The first study has theoretical/simulation results, while >> the second shows results based on a real prototype. >> >> >> >> Thomas Bonald , Laurent Massouli� , Fabien Mathieu , Diego Perino , >> Andrew Twigg. Epidemic Live Streaming: Optimal Performance Trade-Offs. >> In Proc. of SIGMETRICS, 2008. >> >> http://www.thlab.net/~lmassoul/sigmetrics_08.pdf >> >> >> >> >> F. Picconi and L. Massouli�. Is there a future for mesh-based live >> video streaming? In Proc. of P2P, 2008. >> >> http://www.thlab.net/~picconi/p2p08.pdf >> >> >> >> >> The �latest useful� policy shows its benefits when the users� download >> windows overlap (which is usually the case for live streaming). For >> time-shifted media (e.g., VoD/catch-up), it�s a good idea to >> distinguish between the download window next to the playback deadline, >> and the rest. For the download window, the simplest choice is >> �earliest useful� (i.e., prefer the chunks closest to the deadline), >> although combining �earliest useful� with �latest useful� will >> probably give better results if you have users with overlapping >> windows. For the remaining chunks (i.e., far from the playback >> deadline), you probably want to use �rarest first�. >> >> >> >> Fabio >> >> >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp > > > > This body part will be downloaded on demand. -- Gy�rgy D�n School of Electrical Engineering KTH Royal Institute of Technology Stockholm, Sweden http://www.ee.kth.se/~gyuri From kiraly@disi.unitn.it Tue Nov 15 04:48:07 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A0121F8D73 for ; Tue, 15 Nov 2011 04:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlENErZ4HxpQ for ; Tue, 15 Nov 2011 04:48:03 -0800 (PST) Received: from mail0.unitn.it (mail0.unitn.it [193.205.206.51]) by ietfa.amsl.com (Postfix) with ESMTP id EF13C21F8D72 for ; Tue, 15 Nov 2011 04:48:02 -0800 (PST) Received: from mail0.unitn.it (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 93888441B2; Tue, 15 Nov 2011 13:48:01 +0100 (CET) Received: from mailhub2.unitn.it (mailhub.unitn.it [192.168.206.47]) by mail0.unitn.it (Postfix) with ESMTP id 3555C4416C; Tue, 15 Nov 2011 13:48:01 +0100 (CET) Received: from disi.unitn.it (dit.unitn.it [193.205.194.4]) by mailhub2.unitn.it (Postfix) with ESMTP id 2A6FFB0D3D3; Tue, 15 Nov 2011 13:48:01 +0100 (CET) Received: from [193.205.213.86] (gep.disi.unitn.it [193.205.213.86]) by disi.unitn.it (8.13.8/8.13.8) with ESMTP id pAFCm0jf006884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 15 Nov 2011 13:48:01 +0100 Message-ID: <4EC25F80.5000603@disi.unitn.it> Date: Tue, 15 Nov 2011 13:48:00 +0100 From: Csaba Kiraly User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: Gyorgy Dan References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> In-Reply-To: <4EC228E0.4060304@kth.se> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "ppsp@ietf.org" Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 12:48:07 -0000 Hi Gyorgy, nice paper! This is one of the reasons why we are working on some protocol changes to make it more delay tolerant, but this is still in the works. I fully agree that detailed comparison and evaluation is largely missing. There are some spot results but far from being exhaustive. Anyone interested in a joint study of scheduling algorithms? I can throw in a simulator, an emulator and an implementation with configurable schedulers. BTW, I hope the ppsp list does not mind that we jumped on the list with this discussion. I don't know how the topic came up (it was 3 a.m here while you had the discussion, so I wasn't able to follow it), but it seems there was some interest. >From our experience, scheduling issues does have some mild influence on the protocol. Namely: - simple buffer maps sent as bitmaps might not be enough, you might want to send some metadata associated with the chunk IDs as well. - different scheduling algorithms match well or not with different protocols (push, pull, offer, negotiation, etc.). IMHO the ppsp peer protocol should support these all through a careful selection of messaging primitives instead of choosing one, especially because studies are still not satisfying to decide which one is the best, not even to decide which one is better in what scenario. Csaba On 11/15/2011 09:54 AM, Gyorgy Dan wrote: > Hi Csaba, Fabio, all, > > There are many alternatives for scheduling, but IMHO no extensive > comparison of recent algorithms. > It is also good to keep in mind that the performance of the algorithms > depends significantly on the assumptions made for the evaluation. This > study, for example, shows how the performance of random push policies > deteriorates if the evaluation accounts for the delay needed to exchange > signaling messages between the peers: > > I. Chatzidrossos, G. D�n and V. Fodor, ``Delay and playout probability > trade-off in mesh-based peer-to-peer streaming with delayed buffer map > updates,'' in Peer-to-peer Networking and Applications, vol. 3., num. > 1., Mar. 2010 > > Gy�rgy > > > On 11/15/2011 05:19 AM, Csaba Kiraly wrote: >> Hi Fabio, hi all, >> >> Another alternative (for live streaming) is Deadline based chunk >> scheduling. You can find the description of the algorithm, theoretical >> background and some simulations here: >> >> Abeni, L., C. Kiraly, and R. Lo Cigno, "On the Optimal Scheduling of >> Streaming Applications in Unstructured Meshes", NETWORKING 2009, vol. >> 5550: Springer Berlin / Heidelberg, pp. 117-130, 2009. >> http://peerstreamer.org/content/optimal-scheduling-streaming-applications-unstructured-meshes >> http://napa-wine.eu/twiki/pub/Public/DocumentsOld/abeni_optimal_scheduling-final.pdf >> >> The paper presents a combination of a chunk selection and a peer >> selection algorithm (DLc and RLp, respectively), but the chunk selection >> algorithm can be used in itself as well. It shows nice behavior and good >> delivery properties where latest useful policies fail (chunk diffusion >> delay distribution tends to have a heavy tail with latest useful for >> many reasons, DLc tries to correct these shortcomings). >> >> An extension of the above to structured streams (SVC, MDC and alike) is >> described in the following paper: >> >> Kiraly, C., R. Lo Cigno, and L. Abeni, "Deadline-Based Differentiation >> in P2P Streaming", GLOBECOM 2010 - 2010 IEEE Global Communications >> Conference, Miami, FL, USA, IEEE, pp. 1 - 6, 2010. >> http://peerstreamer.org/content/deadline-based-differentiation-p2p-streaming >> http://disi.unitn.it/~kiraly/preprints/kiraly-globecom2010-extended.pdf >> >> Csaba >> >> >> >> On 11/15/2011 04:29 AM, Picconi Fabio wrote: >>> Hi, >>> >>> >>> >>> Here are the references on alternatives to rarest first for live >>> streaming. The first study has theoretical/simulation results, while >>> the second shows results based on a real prototype. >>> >>> >>> >>> Thomas Bonald , Laurent Massouli� , Fabien Mathieu , Diego Perino , >>> Andrew Twigg. Epidemic Live Streaming: Optimal Performance Trade-Offs. >>> In Proc. of SIGMETRICS, 2008. >>> >>> http://www.thlab.net/~lmassoul/sigmetrics_08.pdf >>> >>> >>> >>> >>> F. Picconi and L. Massouli�. Is there a future for mesh-based live >>> video streaming? In Proc. of P2P, 2008. >>> >>> http://www.thlab.net/~picconi/p2p08.pdf >>> >>> >>> >>> >>> The �latest useful� policy shows its benefits when the users� download >>> windows overlap (which is usually the case for live streaming). For >>> time-shifted media (e.g., VoD/catch-up), it�s a good idea to >>> distinguish between the download window next to the playback deadline, >>> and the rest. For the download window, the simplest choice is >>> �earliest useful� (i.e., prefer the chunks closest to the deadline), >>> although combining �earliest useful� with �latest useful� will >>> probably give better results if you have users with overlapping >>> windows. For the remaining chunks (i.e., far from the playback >>> deadline), you probably want to use �rarest first�. >>> >>> >>> >>> Fabio >>> >>> >>> >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >> >> >> This body part will be downloaded on demand. From Fabio.Picconi@technicolor.com Tue Nov 15 18:12:24 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E39511E818E for ; Tue, 15 Nov 2011 18:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ9tmzysVYrl for ; Tue, 15 Nov 2011 18:12:17 -0800 (PST) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3FA11E81A2 for ; Tue, 15 Nov 2011 18:12:14 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKTsMb/YTgm6dDk14dETLDyJMFUaefXqQ1@postini.com; Tue, 15 Nov 2011 18:12:17 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 Nov 2011 02:59:51 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Wed, 16 Nov 2011 02:59:55 +0100 From: Picconi Fabio To: "ppsp@ietf.org" Date: Wed, 16 Nov 2011 02:59:50 +0100 Thread-Topic: [ppsp] chunk scheduling algorithm Thread-Index: AcyjlNfmCSJvPy/HRse3tRZO237A/gAbUeRA Message-ID: <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it> In-Reply-To: <4EC25F80.5000603@disi.unitn.it> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:12:25 -0000 Interesting discussion. I agree that a lot of scheduling algorithms have be= en proposed, and that a detailed comparison is missing. Maybe a good subjec= t for the P2PRG? :-) Regarding PPSP, given the absence of a clear winner among scheduling algori= thms, I agree that PPSP should be as generic as possible to support the wid= est range of options. And that probably means supporting multiple forms of = signaling (e.g., different representations of buffer maps), multiple reques= t paradigms (push/pull/push-pull), multiple transports, etc.=20 Fabio -----Original Message----- From: Csaba Kiraly [mailto:kiraly@disi.unitn.it]=20 Sent: mardi 15 novembre 2011 20:48 To: Gyorgy Dan Cc: Picconi Fabio; ppsp@ietf.org Subject: Re: [ppsp] chunk scheduling algorithm Hi Gyorgy, nice paper! This is one of the reasons why we are working on some protocol = changes to make it more delay tolerant, but this is still in the works. I fully agree that detailed comparison and evaluation is largely missing. T= here are some spot results but far from being exhaustive. Anyone interested= in a joint study of scheduling algorithms? I can throw in a simulator, an = emulator and an implementation with configurable schedulers. BTW, I hope the ppsp list does not mind that we jumped on the list with thi= s discussion. I don't know how the topic came up (it was 3 a.m here while y= ou had the discussion, so I wasn't able to follow it), but it seems there w= as some interest. >From our experience, scheduling issues does have some mild influence on the= protocol. Namely: - simple buffer maps sent as bitmaps might not be enough, you might want to= send some metadata associated with the chunk IDs as well. - different scheduling algorithms match well or not with different protocol= s (push, pull, offer, negotiation, etc.). IMHO the ppsp peer protocol shoul= d support these all through a careful selection of messaging primitives ins= tead of choosing one, especially because studies are still not satisfying t= o decide which one is the best, not even to decide which one is better in w= hat scenario. Csaba On 11/15/2011 09:54 AM, Gyorgy Dan wrote: > Hi Csaba, Fabio, all, > > There are many alternatives for scheduling, but IMHO no extensive > comparison of recent algorithms. > It is also good to keep in mind that the performance of the algorithms > depends significantly on the assumptions made for the evaluation. This > study, for example, shows how the performance of random push policies > deteriorates if the evaluation accounts for the delay needed to exchange > signaling messages between the peers: > > I. Chatzidrossos, G. D=E1n and V. Fodor, ``Delay and playout probability > trade-off in mesh-based peer-to-peer streaming with delayed buffer map > updates,'' in Peer-to-peer Networking and Applications, vol. 3., num. > 1., Mar. 2010 > > Gy=F6rgy > > > On 11/15/2011 05:19 AM, Csaba Kiraly wrote: >> Hi Fabio, hi all, >> >> Another alternative (for live streaming) is Deadline based chunk >> scheduling. You can find the description of the algorithm, theoretical >> background and some simulations here: >> >> Abeni, L., C. Kiraly, and R. Lo Cigno, "On the Optimal Scheduling of >> Streaming Applications in Unstructured Meshes", NETWORKING 2009, vol. >> 5550: Springer Berlin / Heidelberg, pp. 117-130, 2009. >> http://peerstreamer.org/content/optimal-scheduling-streaming-application= s-unstructured-meshes >> http://napa-wine.eu/twiki/pub/Public/DocumentsOld/abeni_optimal_scheduli= ng-final.pdf >> >> The paper presents a combination of a chunk selection and a peer >> selection algorithm (DLc and RLp, respectively), but the chunk selection >> algorithm can be used in itself as well. It shows nice behavior and good >> delivery properties where latest useful policies fail (chunk diffusion >> delay distribution tends to have a heavy tail with latest useful for >> many reasons, DLc tries to correct these shortcomings). >> >> An extension of the above to structured streams (SVC, MDC and alike) is >> described in the following paper: >> >> Kiraly, C., R. Lo Cigno, and L. Abeni, "Deadline-Based Differentiation >> in P2P Streaming", GLOBECOM 2010 - 2010 IEEE Global Communications >> Conference, Miami, FL, USA, IEEE, pp. 1 - 6, 2010. >> http://peerstreamer.org/content/deadline-based-differentiation-p2p-strea= ming >> http://disi.unitn.it/~kiraly/preprints/kiraly-globecom2010-extended.pdf >> >> Csaba >> >> >> >> On 11/15/2011 04:29 AM, Picconi Fabio wrote: >>> Hi, >>> >>> =20 >>> >>> Here are the references on alternatives to rarest first for live >>> streaming. The first study has theoretical/simulation results, while >>> the second shows results based on a real prototype. >>> >>> =20 >>> >>> Thomas Bonald , Laurent Massouli=E9 , Fabien Mathieu , Diego Perino , >>> Andrew Twigg. Epidemic Live Streaming: Optimal Performance Trade-Offs. >>> In Proc. of SIGMETRICS, 2008. >>> >>> http://www.thlab.net/~lmassoul/sigmetrics_08.pdf >>> >>> >>> =20 >>> >>> F. Picconi and L. Massouli=E9. Is there a future for mesh-based live >>> video streaming? In Proc. of P2P, 2008. >>> >>> http://www.thlab.net/~picconi/p2p08.pdf >>> >>> >>> =20 >>> >>> The "latest useful" policy shows its benefits when the users' download >>> windows overlap (which is usually the case for live streaming). For >>> time-shifted media (e.g., VoD/catch-up), it's a good idea to >>> distinguish between the download window next to the playback deadline, >>> and the rest. For the download window, the simplest choice is >>> "earliest useful" (i.e., prefer the chunks closest to the deadline), >>> although combining "earliest useful" with "latest useful" will >>> probably give better results if you have users with overlapping >>> windows. For the remaining chunks (i.e., far from the playback >>> deadline), you probably want to use "rarest first". >>> >>> =20 >>> >>> Fabio >>> >>> >>> >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >> >> >> This body part will be downloaded on demand. From internet-drafts@ietf.org Tue Nov 15 21:14:46 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9481A21F8FFF; Tue, 15 Nov 2011 21:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDSYsQTSvrBb; Tue, 15 Nov 2011 21:14:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329EB21F8E86; Tue, 15 Nov 2011 21:14:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.63 Message-ID: <20111116051442.17662.26072.idtracker@ietfa.amsl.com> Date: Tue, 15 Nov 2011 21:14:42 -0800 X-Mailman-Approved-At: Tue, 15 Nov 2011 21:16:09 -0800 Cc: ppsp@ietf.org Subject: [ppsp] I-D Action: draft-ietf-ppsp-problem-statement-07.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:14:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer to Peer Streaming Protocol Worki= ng Group of the IETF. Title : Problem Statement of Peer-to-Peer Streaming Protocol (PP= SP) Author(s) : Yunfei Zhang Gonzalo Camarillo Richard Yang Filename : draft-ietf-ppsp-problem-statement-07.txt Pages : 24 Date : 2011-11-15 Peer-to-Peer(P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes a Peer to Peer Streaming Protocol(PPSP) including tracker and peer signaling components, and discusses the scope and uses cases of PPSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppsp-problem-statement-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ppsp-problem-statement-07.txt From zhangyunfei@chinamobile.com Tue Nov 15 21:20:27 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96B61F0C5E for ; Tue, 15 Nov 2011 21:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.961 X-Spam-Level: X-Spam-Status: No, score=-97.961 tagged_above=-999 required=5 tests=[AWL=2.415, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EstKkRNEqZ38 for ; Tue, 15 Nov 2011 21:20:26 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D795D21F90FF for ; Tue, 15 Nov 2011 21:20:25 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 92814F770; Wed, 16 Nov 2011 13:20:22 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 7F8B7F76C; Wed, 16 Nov 2011 13:20:22 +0800 (CST) Received: from ady-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011111613202054-9343 ; Wed, 16 Nov 2011 13:20:20 +0800 Date: Wed, 16 Nov 2011 13:20:16 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2011111613201602209223@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-16 13:20:20, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-16 13:20:22, Serialize complete at 2011-11-16 13:20:22 Content-Type: multipart/alternative; boundary="----=_001_NextPart538782070004_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18522.004 X-TM-AS-Result: No--5.405-7.0-31-10 X-imss-scan-details: No--5.405-7.0-31-10;No--5.405-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [ppsp] Fw: New Version Notification for draft-ietf-ppsp-problem-statement-07.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:20:28 -0000 This is a multi-part message in MIME format. ------=_001_NextPart538782070004_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGkgYWxsLA0KICAgIEFzIHByb21pc2VkIGluIHRoZSBwcmV2aW91cyBkcmFmdCwgd2UgaGF2ZSB1 cGxvYWRlZCB0aGUgdXBkYXRlZCB2ZXJzaW9uIGRyYWZ0IGFmdGVyIHRoZSBBRCByZXZpZXcgdG8g dGhlIElFVEYgd2Vic2l0ZS4gVGhlIGRyYWZ0IGhhcyBiZWVuIHNlbnQgdG8gdGhlIG1haWxpbmcg bGlzdCBvbiBOb3YgNyB3aGVuIHRoZSBzdWJtaXNzaW9uIGlzIGNsb3NlZC4NCg0KQlINCll1bmZl aQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHMNCkRhdGU6IDIw MTEtMTEtMTYgMTM6MTQNClRvOiB6aGFuZ3l1bmZlaQ0KQ0M6IHlyeTsgZ29uemFsby5jYW1hcmls bG87IHpoYW5neXVuZmVpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRy YWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0wNy50eHQNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDcudHh0IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWXVuZmVpIFpoYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICBkcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0 ZW1lbnQNClJldmlzaW9uOiAgMDcNClRpdGxlOiAgUHJvYmxlbSBTdGF0ZW1lbnQgb2YgUGVlci10 by1QZWVyIFN0cmVhbWluZyBQcm90b2NvbCAoUFBTUCkNCkNyZWF0aW9uIGRhdGU6ICAyMDExLTEx LTE0DQpXRyBJRDogIHBwc3ANCk51bWJlciBvZiBwYWdlczogMjQNCg0KQWJzdHJhY3Q6DQogICBQ ZWVyLXRvLVBlZXIoUDJQIGZvciBzaG9ydCkgc3RyZWFtaW5nIHN5c3RlbXMgc2hvdyBtb3JlIGFu ZCBtb3JlDQogICBwb3B1bGFyaXR5IGluIGN1cnJlbnQgSW50ZXJuZXQgd2l0aCBwcm9wcmlldGFy eSBwcm90b2NvbHMuIFRoaXMNCiAgIGRvY3VtZW50IGlkZW50aWZpZXMgcHJvYmxlbXMgb2YgdGhl IHByb3ByaWV0YXJ5IHByb3RvY29scywgcHJvcG9zZXMgYQ0KICAgUGVlciB0byBQZWVyIFN0cmVh bWluZyBQcm90b2NvbChQUFNQKSBpbmNsdWRpbmcgdHJhY2tlciBhbmQgcGVlcg0KICAgc2lnbmFs aW5nIGNvbXBvbmVudHMsIGFuZCBkaXNjdXNzZXMgdGhlIHNjb3BlIGFuZCB1c2VzIGNhc2VzIG9m IFBQU1AuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA== ------=_001_NextPart538782070004_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF Hi all, As promised in the previous draft, we have uploade= d=20 the updated version draft after the AD review to the IETF website. Th= e=20 draft has been sent to the mailing list on Nov 7 when the submission is=20 closed. BR Yunfei zhangyunfei From: internet-drafts Date: 2011-11-16 13:14 To: zhangyunfei CC: yry; gonzalo.camarillo; zhangyunfei Subject: New Version Notification for=20 draft-ietf-ppsp-problem-statement-07.txt A new version of I-D, draft-ietf-ppsp-proble= m-statement-07.txt has been successfully submitted&nbs= p;by Yunfei Zhang and posted to the IET= F repository. Filename: draft-ietf-ppsp-problem-statement Revision: 07 Title:=20 Problem Statement of Peer-to-Peer Streaming = ;Protocol (PPSP) Creation date: 2011-11-14 WG ID: ppsp Number of pages: 24 Abstract: Peer-to-Peer(P2P for short) streamin= g systems show more and more popularity in current Internet = with proprietary protocols. This document identifies problems of = ;the proprietary protocols, proposes a Peer to Peer Streaming Protocol= (PPSP) including tracker and peer signaling components, and discusses&= nbsp;the scope and uses cases of PPSP. &nb= sp; = ; &= nbsp; &nb= sp; = ; &= nbsp; The IETF Secretariat ------=_001_NextPart538782070004_=------ From zhangyunfei@chinamobile.com Tue Nov 15 21:45:22 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69621F91CC for ; Tue, 15 Nov 2011 21:45:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.847 X-Spam-Level: X-Spam-Status: No, score=-97.847 tagged_above=-999 required=5 tests=[AWL=1.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8rt6BZ2ImDj for ; Tue, 15 Nov 2011 21:45:13 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 857FA11E808D for ; Tue, 15 Nov 2011 21:45:12 -0800 (PST) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id E71A9F729; Wed, 16 Nov 2011 13:45:05 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id D2E7DF78E; Wed, 16 Nov 2011 13:45:05 +0800 (CST) Received: from ady-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011111613450391-9934 ; Wed, 16 Nov 2011 13:45:03 +0800 Date: Wed, 16 Nov 2011 13:44:59 +0800 From: zhangyunfei To: "Picconi Fabio" , ppsp , kiraly References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it>, <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2011111613445962661858@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-16 13:45:04, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-16 13:45:05, Serialize complete at 2011-11-16 13:45:05 Content-Type: multipart/alternative; boundary="----=_001_NextPart120174141644_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18522.005 X-TM-AS-Result: No--38.563-7.0-31-10 X-imss-scan-details: No--38.563-7.0-31-10;No--38.563-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:45:22 -0000 This is a multi-part message in MIME format. ------=_001_NextPart120174141644_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGkgRmFiaW8sQ3NhYmEgYW5kIGFsbO+8iHNwZWFrIGluZGl2aWR1YWxseSksDQogICAgQmVjYXN1 ZSBQUFNQIGRvZXNuJ3QgY292ZXIgdGhlIHNjaGVkdWxpbmcgc2VsZWN0aW9uICwgSSB0aGluayBQ UFNQIHBlZXIgcHJvdG9jb2wgc2hvdWxkIGJlIG9wZW4gdG8gbXVsdGlwbGUgcmVxdWVzdCBwYXJh ZGlnbXMgbGlrZSBwdXNoL3B1bGwvaHlicmlkIG1vZGUuICBGb3IgdGhlIGJpdG1hcCBleHByZXNz aW9uLCBJIGFtIG5vdCBzdXJlIGlmIGEgZ2VuZXJpYyBleHByZXNzaW9uIGNhbiB3b3JrKHN1cHBv cnRpbmcgYm90aCBzdHJ1Y3R1cmVkIGFuZCB1bnN0cnVjdHVyZWQgZGF0YSkuIEJ1dCBpZiBpdCB3 b3JrcywgaXQncyBiZXR0ZXIgdGhhbiBoYXZpbmcgZGlmZmVyZW50IGJpdG1hcCBleHByZXNzaW9u cy4NClRoZSBzZWxlY3Rpb24gb2YgdXNpbmcgd2hhdCBraW5kIG9mIFBQU1AgcmVxdWVzdCBtb2Rl IGFuZCBzY2hlZHVsaW5nIGFsZ29yaXRobXMsIHRyYW5zcG9ydCBjYW4gYmUgYWRkcmVzc2VkIGlu IHRoZSAidXNhZ2UgZ3VpZGUiIGRvY3VtZW50LCB3aGljaCBpcyBleHBsaWNpdCBpbiB0aGUgY2hh cnRlci4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoNCkZyb206IFBpY2Nv bmkgRmFiaW8NCkRhdGU6IDIwMTEtMTEtMTYgMDk6NTkNClRvOiBwcHNwQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW3Bwc3BdIGNodW5rIHNjaGVkdWxpbmcgYWxnb3JpdGhtDQpJbnRlcmVzdGluZyBk aXNjdXNzaW9uLiBJIGFncmVlIHRoYXQgYSBsb3Qgb2Ygc2NoZWR1bGluZyBhbGdvcml0aG1zIGhh dmUgYmVlbiBwcm9wb3NlZCwgYW5kIHRoYXQgYSBkZXRhaWxlZCBjb21wYXJpc29uIGlzIG1pc3Np bmcuIE1heWJlIGEgZ29vZCBzdWJqZWN0IGZvciB0aGUgUDJQUkc/IDotKQ0KDQpSZWdhcmRpbmcg UFBTUCwgZ2l2ZW4gdGhlIGFic2VuY2Ugb2YgYSBjbGVhciB3aW5uZXIgYW1vbmcgc2NoZWR1bGlu ZyBhbGdvcml0aG1zLCBJIGFncmVlIHRoYXQgUFBTUCBzaG91bGQgYmUgYXMgZ2VuZXJpYyBhcyBw b3NzaWJsZSB0byBzdXBwb3J0IHRoZSB3aWRlc3QgcmFuZ2Ugb2Ygb3B0aW9ucy4gQW5kIHRoYXQg cHJvYmFibHkgbWVhbnMgc3VwcG9ydGluZyBtdWx0aXBsZSBmb3JtcyBvZiBzaWduYWxpbmcgKGUu Zy4sIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgb2YgYnVmZmVyIG1hcHMpLCBtdWx0aXBsZSBy ZXF1ZXN0IHBhcmFkaWdtcyAocHVzaC9wdWxsL3B1c2gtcHVsbCksIG11bHRpcGxlIHRyYW5zcG9y dHMsIGV0Yy4gDQoNCkZhYmlvDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IENzYWJhIEtpcmFseSBbbWFpbHRvOmtpcmFseUBkaXNpLnVuaXRuLml0XSANClNlbnQ6IG1hcmRp IDE1IG5vdmVtYnJlIDIwMTEgMjA6NDgNClRvOiBHeW9yZ3kgRGFuDQpDYzogUGljY29uaSBGYWJp bzsgcHBzcEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtwcHNwXSBjaHVuayBzY2hlZHVsaW5nIGFs Z29yaXRobQ0KDQpIaSBHeW9yZ3ksDQoNCm5pY2UgcGFwZXIhIFRoaXMgaXMgb25lIG9mIHRoZSBy ZWFzb25zIHdoeSB3ZSBhcmUgd29ya2luZyBvbiBzb21lIHByb3RvY29sIGNoYW5nZXMgdG8gbWFr ZSBpdCBtb3JlIGRlbGF5IHRvbGVyYW50LCBidXQgdGhpcyBpcyBzdGlsbCBpbiB0aGUgd29ya3Mu DQpJIGZ1bGx5IGFncmVlIHRoYXQgZGV0YWlsZWQgY29tcGFyaXNvbiBhbmQgZXZhbHVhdGlvbiBp cyBsYXJnZWx5IG1pc3NpbmcuIFRoZXJlIGFyZSBzb21lIHNwb3QgcmVzdWx0cyBidXQgZmFyIGZy b20gYmVpbmcgZXhoYXVzdGl2ZS4gQW55b25lIGludGVyZXN0ZWQgaW4gYSBqb2ludCBzdHVkeSBv ZiBzY2hlZHVsaW5nIGFsZ29yaXRobXM/IEkgY2FuIHRocm93IGluIGEgc2ltdWxhdG9yLCBhbiBl bXVsYXRvciBhbmQgYW4gaW1wbGVtZW50YXRpb24gd2l0aCBjb25maWd1cmFibGUgc2NoZWR1bGVy cy4NCg0KQlRXLCBJIGhvcGUgdGhlIHBwc3AgbGlzdCBkb2VzIG5vdCBtaW5kIHRoYXQgd2UganVt cGVkIG9uIHRoZSBsaXN0IHdpdGggdGhpcyBkaXNjdXNzaW9uLiBJIGRvbid0IGtub3cgaG93IHRo ZSB0b3BpYyBjYW1lIHVwIChpdCB3YXMgMyBhLm0gaGVyZSB3aGlsZSB5b3UgaGFkIHRoZSBkaXNj dXNzaW9uLCBzbyBJIHdhc24ndCBhYmxlIHRvIGZvbGxvdyBpdCksIGJ1dCBpdCBzZWVtcyB0aGVy ZSB3YXMgc29tZSBpbnRlcmVzdC4NCg0KRnJvbSBvdXIgZXhwZXJpZW5jZSwgc2NoZWR1bGluZyBp c3N1ZXMgZG9lcyBoYXZlIHNvbWUgbWlsZCBpbmZsdWVuY2Ugb24gdGhlIHByb3RvY29sLiBOYW1l bHk6DQotIHNpbXBsZSBidWZmZXIgbWFwcyBzZW50IGFzIGJpdG1hcHMgbWlnaHQgbm90IGJlIGVu b3VnaCwgeW91IG1pZ2h0IHdhbnQgdG8gc2VuZCBzb21lIG1ldGFkYXRhIGFzc29jaWF0ZWQgd2l0 aCB0aGUgY2h1bmsgSURzIGFzIHdlbGwuDQotIGRpZmZlcmVudCBzY2hlZHVsaW5nIGFsZ29yaXRo bXMgbWF0Y2ggd2VsbCBvciBub3Qgd2l0aCBkaWZmZXJlbnQgcHJvdG9jb2xzIChwdXNoLCBwdWxs LCBvZmZlciwgbmVnb3RpYXRpb24sIGV0Yy4pLiBJTUhPIHRoZSBwcHNwIHBlZXIgcHJvdG9jb2wg c2hvdWxkIHN1cHBvcnQgdGhlc2UgYWxsIHRocm91Z2ggYSBjYXJlZnVsIHNlbGVjdGlvbiBvZiBt ZXNzYWdpbmcgcHJpbWl0aXZlcyBpbnN0ZWFkIG9mIGNob29zaW5nIG9uZSwgZXNwZWNpYWxseSBi ZWNhdXNlIHN0dWRpZXMgYXJlIHN0aWxsIG5vdCBzYXRpc2Z5aW5nIHRvIGRlY2lkZSB3aGljaCBv bmUgaXMgdGhlIGJlc3QsIG5vdCBldmVuIHRvIGRlY2lkZSB3aGljaCBvbmUgaXMgYmV0dGVyIGlu IHdoYXQgc2NlbmFyaW8uDQoNCkNzYWJhDQoNCk9uIDExLzE1LzIwMTEgMDk6NTQgQU0sIEd5b3Jn eSBEYW4gd3JvdGU6DQo+IEhpIENzYWJhLCBGYWJpbywgYWxsLA0KPg0KPiBUaGVyZSBhcmUgbWFu eSBhbHRlcm5hdGl2ZXMgZm9yIHNjaGVkdWxpbmcsIGJ1dCBJTUhPIG5vIGV4dGVuc2l2ZQ0KPiBj b21wYXJpc29uIG9mIHJlY2VudCBhbGdvcml0aG1zLg0KPiBJdCBpcyBhbHNvIGdvb2QgdG8ga2Vl cCBpbiBtaW5kIHRoYXQgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBhbGdvcml0aG1zDQo+IGRlcGVu ZHMgc2lnbmlmaWNhbnRseSBvbiB0aGUgYXNzdW1wdGlvbnMgbWFkZSBmb3IgdGhlIGV2YWx1YXRp b24uIFRoaXMNCj4gc3R1ZHksIGZvciBleGFtcGxlLCBzaG93cyBob3cgdGhlIHBlcmZvcm1hbmNl IG9mIHJhbmRvbSBwdXNoIHBvbGljaWVzDQo+IGRldGVyaW9yYXRlcyBpZiB0aGUgZXZhbHVhdGlv biBhY2NvdW50cyBmb3IgdGhlIGRlbGF5IG5lZWRlZCB0byBleGNoYW5nZQ0KPiBzaWduYWxpbmcg bWVzc2FnZXMgYmV0d2VlbiB0aGUgcGVlcnM6DQo+DQo+IEkuIENoYXR6aWRyb3Nzb3MsIEcuIETD oW4gYW5kIFYuIEZvZG9yLCBgYERlbGF5IGFuZCBwbGF5b3V0IHByb2JhYmlsaXR5DQo+IHRyYWRl LW9mZiBpbiBtZXNoLWJhc2VkIHBlZXItdG8tcGVlciBzdHJlYW1pbmcgd2l0aCBkZWxheWVkIGJ1 ZmZlciBtYXANCj4gdXBkYXRlcywnJyBpbiBQZWVyLXRvLXBlZXIgTmV0d29ya2luZyBhbmQgQXBw bGljYXRpb25zLCB2b2wuIDMuLCBudW0uDQo+IDEuLCBNYXIuIDIwMTANCj4NCj4gR3nDtnJneQ0K Pg0KPg0KPiBPbiAxMS8xNS8yMDExIDA1OjE5IEFNLCBDc2FiYSBLaXJhbHkgd3JvdGU6DQo+PiBI aSBGYWJpbywgaGkgYWxsLA0KPj4NCj4+IEFub3RoZXIgYWx0ZXJuYXRpdmUgKGZvciBsaXZlIHN0 cmVhbWluZykgaXMgRGVhZGxpbmUgYmFzZWQgY2h1bmsNCj4+IHNjaGVkdWxpbmcuIFlvdSBjYW4g ZmluZCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGFsZ29yaXRobSwgdGhlb3JldGljYWwNCj4+IGJh Y2tncm91bmQgYW5kIHNvbWUgc2ltdWxhdGlvbnMgaGVyZToNCj4+DQo+PiBBYmVuaSwgTC4sIEMu IEtpcmFseSwgYW5kIFIuIExvIENpZ25vLCAiT24gdGhlIE9wdGltYWwgU2NoZWR1bGluZyBvZg0K Pj4gU3RyZWFtaW5nIEFwcGxpY2F0aW9ucyBpbiBVbnN0cnVjdHVyZWQgTWVzaGVzIiwgTkVUV09S S0lORyAyMDA5LCB2b2wuDQo+PiA1NTUwOiBTcHJpbmdlciBCZXJsaW4gLyBIZWlkZWxiZXJnLCBw cC4gMTE3LTEzMCwgMjAwOS4NCj4+IGh0dHA6Ly9wZWVyc3RyZWFtZXIub3JnL2NvbnRlbnQvb3B0 aW1hbC1zY2hlZHVsaW5nLXN0cmVhbWluZy1hcHBsaWNhdGlvbnMtdW5zdHJ1Y3R1cmVkLW1lc2hl cw0KPj4gaHR0cDovL25hcGEtd2luZS5ldS90d2lraS9wdWIvUHVibGljL0RvY3VtZW50c09sZC9h YmVuaV9vcHRpbWFsX3NjaGVkdWxpbmctZmluYWwucGRmDQo+Pg0KPj4gVGhlIHBhcGVyIHByZXNl bnRzIGEgY29tYmluYXRpb24gb2YgYSBjaHVuayBzZWxlY3Rpb24gYW5kIGEgcGVlcg0KPj4gc2Vs ZWN0aW9uIGFsZ29yaXRobSAoRExjIGFuZCBSTHAsIHJlc3BlY3RpdmVseSksIGJ1dCB0aGUgY2h1 bmsgc2VsZWN0aW9uDQo+PiBhbGdvcml0aG0gY2FuIGJlIHVzZWQgaW4gaXRzZWxmIGFzIHdlbGwu IEl0IHNob3dzIG5pY2UgYmVoYXZpb3IgYW5kIGdvb2QNCj4+IGRlbGl2ZXJ5IHByb3BlcnRpZXMg d2hlcmUgbGF0ZXN0IHVzZWZ1bCBwb2xpY2llcyBmYWlsIChjaHVuayBkaWZmdXNpb24NCj4+IGRl bGF5IGRpc3RyaWJ1dGlvbiB0ZW5kcyB0byBoYXZlIGEgaGVhdnkgdGFpbCB3aXRoIGxhdGVzdCB1 c2VmdWwgZm9yDQo+PiBtYW55IHJlYXNvbnMsIERMYyB0cmllcyB0byBjb3JyZWN0IHRoZXNlIHNo b3J0Y29taW5ncykuDQo+Pg0KPj4gQW4gZXh0ZW5zaW9uIG9mIHRoZSBhYm92ZSB0byBzdHJ1Y3R1 cmVkIHN0cmVhbXMgKFNWQywgTURDIGFuZCBhbGlrZSkgaXMNCj4+IGRlc2NyaWJlZCBpbiB0aGUg Zm9sbG93aW5nIHBhcGVyOg0KPj4NCj4+IEtpcmFseSwgQy4sIFIuIExvIENpZ25vLCBhbmQgTC4g QWJlbmksICJEZWFkbGluZS1CYXNlZCBEaWZmZXJlbnRpYXRpb24NCj4+IGluIFAyUCBTdHJlYW1p bmciLCBHTE9CRUNPTSAyMDEwIC0gMjAxMCBJRUVFIEdsb2JhbCBDb21tdW5pY2F0aW9ucw0KPj4g Q29uZmVyZW5jZSwgTWlhbWksIEZMLCBVU0EsIElFRUUsIHBwLiAxIC0gNiwgMjAxMC4NCj4+IGh0 dHA6Ly9wZWVyc3RyZWFtZXIub3JnL2NvbnRlbnQvZGVhZGxpbmUtYmFzZWQtZGlmZmVyZW50aWF0 aW9uLXAycC1zdHJlYW1pbmcNCj4+IGh0dHA6Ly9kaXNpLnVuaXRuLml0L35raXJhbHkvcHJlcHJp bnRzL2tpcmFseS1nbG9iZWNvbTIwMTAtZXh0ZW5kZWQucGRmDQo+Pg0KPj4gQ3NhYmENCj4+DQo+ Pg0KPj4NCj4+IE9uIDExLzE1LzIwMTEgMDQ6MjkgQU0sIFBpY2NvbmkgRmFiaW8gd3JvdGU6DQo+ Pj4gSGksDQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiBIZXJlIGFyZSB0aGUgcmVmZXJlbmNlcyBvbiBh bHRlcm5hdGl2ZXMgdG8gcmFyZXN0IGZpcnN0IGZvciBsaXZlDQo+Pj4gc3RyZWFtaW5nLiBUaGUg Zmlyc3Qgc3R1ZHkgaGFzIHRoZW9yZXRpY2FsL3NpbXVsYXRpb24gcmVzdWx0cywgd2hpbGUNCj4+ PiB0aGUgc2Vjb25kIHNob3dzIHJlc3VsdHMgYmFzZWQgb24gYSByZWFsIHByb3RvdHlwZS4NCj4+ Pg0KPj4+ICANCj4+Pg0KPj4+IFRob21hcyBCb25hbGQgLCBMYXVyZW50IE1hc3NvdWxpw6kgLCBG YWJpZW4gTWF0aGlldSAsIERpZWdvIFBlcmlubyAsDQo+Pj4gQW5kcmV3IFR3aWdnLiBFcGlkZW1p YyBMaXZlIFN0cmVhbWluZzogT3B0aW1hbCBQZXJmb3JtYW5jZSBUcmFkZS1PZmZzLg0KPj4+IElu IFByb2MuIG9mIFNJR01FVFJJQ1MsIDIwMDguDQo+Pj4NCj4+PiBodHRwOi8vd3d3LnRobGFiLm5l dC9+bG1hc3NvdWwvc2lnbWV0cmljc18wOC5wZGYNCj4+PiA8aHR0cDovL3d3dy50aGxhYi5uZXQv JTdFbG1hc3NvdWwvc2lnbWV0cmljc18wOC5wZGY+DQo+Pj4NCj4+PiAgDQo+Pj4NCj4+PiBGLiBQ aWNjb25pIGFuZCBMLiBNYXNzb3VsacOpLiBJcyB0aGVyZSBhIGZ1dHVyZSBmb3IgbWVzaC1iYXNl ZCBsaXZlDQo+Pj4gdmlkZW8gc3RyZWFtaW5nPyBJbiBQcm9jLiBvZiBQMlAsIDIwMDguDQo+Pj4N Cj4+PiBodHRwOi8vd3d3LnRobGFiLm5ldC9+cGljY29uaS9wMnAwOC5wZGYNCj4+PiA8aHR0cDov L3d3dy50aGxhYi5uZXQvJTdFcGljY29uaS9wMnAwOC5wZGY+DQo+Pj4NCj4+PiAgDQo+Pj4NCj4+ PiBUaGUgImxhdGVzdCB1c2VmdWwiIHBvbGljeSBzaG93cyBpdHMgYmVuZWZpdHMgd2hlbiB0aGUg dXNlcnMnIGRvd25sb2FkDQo+Pj4gd2luZG93cyBvdmVybGFwICh3aGljaCBpcyB1c3VhbGx5IHRo ZSBjYXNlIGZvciBsaXZlIHN0cmVhbWluZykuIEZvcg0KPj4+IHRpbWUtc2hpZnRlZCBtZWRpYSAo ZS5nLiwgVm9EL2NhdGNoLXVwKSwgaXQncyBhIGdvb2QgaWRlYSB0bw0KPj4+IGRpc3Rpbmd1aXNo IGJldHdlZW4gdGhlIGRvd25sb2FkIHdpbmRvdyBuZXh0IHRvIHRoZSBwbGF5YmFjayBkZWFkbGlu ZSwNCj4+PiBhbmQgdGhlIHJlc3QuIEZvciB0aGUgZG93bmxvYWQgd2luZG93LCB0aGUgc2ltcGxl c3QgY2hvaWNlIGlzDQo+Pj4gImVhcmxpZXN0IHVzZWZ1bCIgIChpLmUuLCBwcmVmZXIgdGhlIGNo dW5rcyBjbG9zZXN0IHRvIHRoZSBkZWFkbGluZSksDQo+Pj4gYWx0aG91Z2ggY29tYmluaW5nICJl YXJsaWVzdCAgdXNlZnVsIiB3aXRoICJsYXRlc3QgdXNlZnVsIiB3aWxsDQo+Pj4gcHJvYmFibHkg Z2l2ZSBiZXR0ZXIgcmVzdWx0cyBpZiB5b3UgaGF2ZSB1c2VycyB3aXRoIG92ZXJsYXBwaW5nDQo+ Pj4gd2luZG93cy4gRm9yIHRoZSByZW1haW5pbmcgY2h1bmtzIChpLmUuLCBmYXIgZnJvbSB0aGUg cGxheWJhY2sNCj4+PiBkZWFkbGluZSksIHlvdSBwcm9iYWJseSB3YW50IHRvIHVzZSAicmFyZXN0 IGZpcnN0Ii4NCj4+Pg0KPj4+ICANCj4+Pg0KPj4+IEZhYmlvDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBwcHNw IG1haWxpbmcgbGlzdA0KPj4+IHBwc3BAaWV0Zi5vcmcgPG1haWx0bzpwcHNwQGlldGYub3JnPg0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0KPj4NCj4+DQo+ PiBUaGlzIGJvZHkgcGFydCB3aWxsIGJlIGRvd25sb2FkZWQgb24gZGVtYW5kLg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxp c3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cHBzcA== ------=_001_NextPart120174141644_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF Hi Fabio,Csaba and all=EF=BC=88speak individually), Becasue PPSP doesn't cover the scheduling=20 selection , I think PPSP peer protocol should be open to multiple=20 request paradigms like push/pull/hybrid mode. For the bitm= ap=20 expression, I am not sure if a generic expression can work(supporting both= =20 structured and unstructured data). But if it works, it's better than havin= g=20 different bitmap expressions. The selection of using what kind of PPSP request mode and scheduling=20 algorithms, transport can be addressed in the "usage guide" document, whic= h is=20 explicit in the charter. BR Yunfei zhangyunfei From: Pi= cconi=20 Fabio Date: 2011-11-16 09:59 To: ppsp@ietf.org Subject: Re: [ppsp] chunk scheduling=20 algorithm Interesting discussion. I agree that a = lot of scheduling algorithms have been propo= sed, and that a detailed comparison is = missing. Maybe a good subject for the P= 2PRG? :-) Regarding PPSP, given the absence of a&= nbsp;clear winner among scheduling algorithms, I&= nbsp;agree that PPSP should be as generic&nb= sp;as possible to support the widest range&n= bsp;of options. And that probably means supp= orting multiple forms of signaling (e.g., di= fferent representations of buffer maps), multiple= request paradigms (push/pull/push-pull), multiple&nbs= p;transports, etc. Fabio -----Original Message----- From: Csaba Kiraly [mailto:kiraly@disi.unitn.it] = Sent: mardi 15 novembre 2011 20:48 To: Gyorgy Dan Cc: Picconi Fabio; ppsp@ietf.org Subject: Re: [ppsp] chunk scheduling algorit= hm Hi Gyorgy, nice paper! This is one of the rea= sons why we are working on some protoco= l changes to make it more delay toleran= t, but this is still in the works. I fully agree that detailed comparison = and evaluation is largely missing. There are= some spot results but far from being&n= bsp;exhaustive. Anyone interested in a joint = ;study of scheduling algorithms? I can throw= in a simulator, an emulator and an&nbs= p;implementation with configurable schedulers. BTW, I hope the ppsp list does not= mind that we jumped on the list w= ith this discussion. I don't know how t= he topic came up (it was 3 a.m her= e while you had the discussion, so I&nb= sp;wasn't able to follow it), but it se= ems there was some interest. From our experience, scheduling issues does&= nbsp;have some mild influence on the protoco= l. Namely: - simple buffer maps sent as bitmaps&nb= sp;might not be enough, you might want = to send some metadata associated with the&nb= sp;chunk IDs as well. - different scheduling algorithms match well= or not with different protocols (push, = ;pull, offer, negotiation, etc.). IMHO the p= psp peer protocol should support these all&n= bsp;through a careful selection of messaging = ;primitives instead of choosing one, especially&n= bsp;because studies are still not satisfying = ;to decide which one is the best, not&n= bsp;even to decide which one is better = in what scenario. Csaba On 11/15/2011 09:54 AM, Gyorgy Dan wrot= e: > Hi Csaba, Fabio, all, > > There are many alternatives for sc= heduling, but IMHO no extensive > comparison of recent algorithms. > It is also good to keep in&nb= sp;mind that the performance of the algorith= ms > depends significantly on the assumption= s made for the evaluation. This > study, for example, shows how the&= nbsp;performance of random push policies > deteriorates if the evaluation accounts= for the delay needed to exchange > signaling messages between the peers: > > I. Chatzidrossos, G. D=C3=A1n and = V. Fodor, ``Delay and playout probability > trade-off in mesh-based peer-to-peer st= reaming with delayed buffer map > updates,'' in Peer-to-peer Networking a= nd Applications, vol. 3., num. > 1., Mar. 2010 > > Gy=C3=B6rgy > > > On 11/15/2011 05:19 AM, Csaba Kira= ly wrote: >> Hi Fabio, hi all, >> >> Another alternative (for live strea= ming) is Deadline based chunk >> scheduling. You can find the d= escription of the algorithm, theoretical >> background and some simulations her= e: >> >> Abeni, L., C. Kiraly, and R.&n= bsp;Lo Cigno, "On the Optimal Scheduling of<= /DIV> >> Streaming Applications in Unstructured&n= bsp;Meshes", NETWORKING 2009, vol. >> 5550: Springer Berlin / Heidelberg,= pp. 117-130, 2009. >> http://peerstreamer.org/content/optimal-scheduling-stre= aming-applications-unstructured-meshes >> http://napa-wine.eu/twiki/pub/Public/DocumentsOld/abeni= _optimal_scheduling-final.pdf >> >> The paper presents a combination&nb= sp;of a chunk selection and a peer >> selection algorithm (DLc and RLp,&n= bsp;respectively), but the chunk selection >> algorithm can be used in itsel= f as well. It shows nice behavior and&n= bsp;good >> delivery properties where latest us= eful policies fail (chunk diffusion >> delay distribution tends to have&nb= sp;a heavy tail with latest useful for >> many reasons, DLc tries to cor= rect these shortcomings). >> >> An extension of the above to&n= bsp;structured streams (SVC, MDC and alike) = is >> described in the following paper: >> >> Kiraly, C., R. Lo Cigno, and&n= bsp;L. Abeni, "Deadline-Based Differentiation >> in P2P Streaming", GLOBECOM 2010&nb= sp;- 2010 IEEE Global Communications >> Conference, Miami, FL, USA, IEEE,&n= bsp;pp. 1 - 6, 2010. >> http://peerstreamer.org/content/deadline-based-differen= tiation-p2p-streaming >> http://disi.unitn.it/~kiraly/preprints/kiraly-globecom2= 010-extended.pdf >> >> Csaba >> >> >> >> On 11/15/2011 04:29 AM, Picconi&nbs= p;Fabio wrote: >>> Hi, >>> >>> >>> >>> Here are the references on = ;alternatives to rarest first for live >>> streaming. The first study has&= nbsp;theoretical/simulation results, while >>> the second shows results based&= nbsp;on a real prototype. >>> >>> >>> >>> Thomas Bonald , Laurent Massoul= i=C3=A9 , Fabien Mathieu , Diego Perino = ;, >>> Andrew Twigg. Epidemic Live Str= eaming: Optimal Performance Trade-Offs. >>> In Proc. of SIGMETRICS, 2008. >>> >>> http://www.thlab.net/~lmassoul/sigmetrics_08.pdf >>> <http://www.thlab.net/%7Elmassoul/sigmetrics_08.= pdf> >>> >>> >>> >>> F. Picconi and L. Massouli=C3= =A9. Is there a future for mesh-based l= ive >>> video streaming? In Proc. of&nb= sp;P2P, 2008. >>> >>> http://www.thlab.net/~picconi/p2p08.pdf >>> <http://www.thlab.net/%7Epicconi/p2p08.pdf> >>> >>> >>> >>> The "latest useful" policy show= s its benefits when the users' download >>> windows overlap (which is usual= ly the case for live streaming). For >>> time-shifted media (e.g., VoD/catch-= up), it's a good idea to >>> distinguish between the download&nbs= p;window next to the playback deadline, >>> and the rest. For the down= load window, the simplest choice is >>> "earliest useful" (i.e., prefe= r the chunks closest to the deadline), >>> although combining "earliest u= seful" with "latest useful" will >>> probably give better results if= you have users with overlapping >>> windows. For the remaining chun= ks (i.e., far from the playback >>> deadline), you probably want to= use "rarest first". >>> >>> >>> >>> Fabio >>> >>> >>> >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org <mailto:ppsp@ietf.org> >>> https://www.ietf.org/mailman/listinfo/ppsp >> >> >> This body part will be downloa= ded on demand. _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp ------=_001_NextPart120174141644_=------ From iesg-secretary@ietf.org Wed Nov 16 01:07:16 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F400221F957D; Wed, 16 Nov 2011 01:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhVFGvCqQcBg; Wed, 16 Nov 2011 01:07:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D1921F9573; Wed, 16 Nov 2011 01:07:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64 Message-ID: <20111116090715.6387.96831.idtracker@ietfa.amsl.com> Date: Wed, 16 Nov 2011 01:07:15 -0800 Cc: ppsp@ietf.org Subject: [ppsp] Last Call: (Problem Statement of Peer-to-Peer Streaming Protocol (PPSP)) to Informational RFC X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 09:07:16 -0000 The IESG has received a request from the Peer to Peer Streaming Protocol WG (ppsp) to consider the following document: - 'Problem Statement of Peer-to-Peer Streaming Protocol (PPSP)' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-11-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Peer-to-Peer(P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes a Peer to Peer Streaming Protocol(PPSP) including tracker and peer signaling components, and discusses the scope and uses cases of PPSP. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement/ No IPR declarations have been submitted directly on this I-D. From Martin.Stiemerling@neclab.eu Mon Nov 21 07:36:05 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103A911E80BE for ; Mon, 21 Nov 2011 07:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OYEd59fmmRD for ; Mon, 21 Nov 2011 07:36:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D203711E8096 for ; Mon, 21 Nov 2011 07:36:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2A765280001C7 for ; Mon, 21 Nov 2011 16:36:00 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWDpt00COFFf for ; Mon, 21 Nov 2011 16:36:00 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 0A6A4280000F7 for ; Mon, 21 Nov 2011 16:35:55 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 21 Nov 2011 16:35:55 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: WGLC for draft-ietf-ppsp-survey-02 until Dec 5th Thread-Index: AcyoYtD91l5HovFhR1S1F/aRc7g/nQ== Date: Mon, 21 Nov 2011 15:35:54 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] WGLC for draft-ietf-ppsp-survey-02 until Dec 5th X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:36:05 -0000 Dear all, This is the Working Group Last Call (WGLC) for "Survey of P2P Streaming App= lications" (draft-ietf-ppsp-survey-02, http://www.ietf.org/id/draft-ietf-pp= sp-survey-02.txt).=20 Please review the draft and send your comments to the PPSP list. Any type o= f review is appreciated, even it is saying only "I have read the draft and = it is ok".=20 However, a thorough review is required by a number of PPSP WG members (whic= h is YOU!) The WGLC starts right now and will end December 5th, 6pm PT. =20 Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From Martin.Stiemerling@neclab.eu Mon Nov 21 07:39:47 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209DD21F8B25 for ; Mon, 21 Nov 2011 07:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.318 X-Spam-Level: X-Spam-Status: No, score=-102.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amYCO7NmKaTp for ; Mon, 21 Nov 2011 07:39:43 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C75DA11E80B0 for ; Mon, 21 Nov 2011 07:39:42 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 21C4B280000F7 for ; Mon, 21 Nov 2011 16:39:42 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUJ7HZeWyG7r for ; Mon, 21 Nov 2011 16:39:42 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 06D2E28000080 for ; Mon, 21 Nov 2011 16:39:37 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 21 Nov 2011 16:39:36 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: WGLC for draft-ietf-ppsp-survey-02 until Dec 5th Thread-Index: AcyoYtD91l5HovFhR1S1F/aRc7g/nQAAKePw Date: Mon, 21 Nov 2011 15:39:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] WGLC for draft-ietf-ppsp-survey-02 until Dec 5th X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 15:39:47 -0000 [Writing as an individual] Hi, A first comment about draft-ietf-ppsp-survey-02: The list of authors has more than 5 people on it. In my reading, the RFC ed= itor enforces a maximum of 5 authors on RFCs, unless there are really hard = reasons to go beyond 5 authors.=20 Can you limit the number of authors to 5 in total and move the remaining au= thors to a contributors section? Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Monday, November 21, 2011 4:36 PM > To: ppsp@ietf.org > Subject: [ppsp] WGLC for draft-ietf-ppsp-survey-02 until Dec 5th >=20 > Dear all, >=20 > This is the Working Group Last Call (WGLC) for "Survey of P2P Streaming > Applications" (draft-ietf-ppsp-survey-02, http://www.ietf.org/id/draft-ie= tf-ppsp- > survey-02.txt). >=20 > Please review the draft and send your comments to the PPSP list. Any type= of > review is appreciated, even it is saying only "I have read the draft and = it is ok". > However, a thorough review is required by a number of PPSP WG members > (which is YOU!) >=20 > The WGLC starts right now and will end December 5th, 6pm PT. >=20 > Martin >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited | > Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered= in > England 2832014 >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From a.bakker@vu.nl Tue Nov 22 00:04:40 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9C121F85B8 for ; Tue, 22 Nov 2011 00:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xDF2-ryWfNc for ; Tue, 22 Nov 2011 00:04:39 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34CD321F858D for ; Tue, 22 Nov 2011 00:04:38 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 22 Nov 2011 09:04:37 +0100 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 22 Nov 2011 09:04:36 +0100 Message-ID: <4ECB57FF.1000804@cs.vu.nl> Date: Tue, 22 Nov 2011 09:06:23 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it>, <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> <2011111613445962661858@chinamobile.com> In-Reply-To: <2011111613445962661858@chinamobile.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 08:04:40 -0000 On 16/11/2011 06:44, zhangyunfei wrote: > Hi Fabio,Csaba and all（speak individually), > Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer > protocol should be open to multiple request paradigms like > push/pull/hybrid mode. For the bitmap expression, I am not sure if a > generic expression can work(supporting both structured and unstructured > data). But if it works, it's better than having different bitmap > expressions. > The selection of using what kind of PPSP request mode and scheduling > algorithms, transport can be addressed in the "usage guide" document, > which is explicit in the charter. Hi all good input. The plan after Taipei is to make swift open to different chunk addressing methods and integrity protection mechanisms. With the former in mind, could you have a look at the swift proposal and see if there are things missing that you need to use the chunk+peer selection policies that you are currently using. I.e., determine the requirements that your selection policies put on the protocol, and if they are currently met? Thanks, Arno From r.petrocco@gmail.com Tue Nov 22 02:29:30 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31E521F8D20 for ; Tue, 22 Nov 2011 02:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=-1.503, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD1ZWsFJyrLc for ; Tue, 22 Nov 2011 02:29:26 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A068A21F8CFB for ; Tue, 22 Nov 2011 02:29:26 -0800 (PST) Received: by ghrr14 with SMTP id r14so4617260ghr.31 for ; Tue, 22 Nov 2011 02:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WkLywB0UIBam2wPUZNdmpJizaqy0cnhN52BgZ2Ctmf4=; b=I6HWoHjAS6vuDS1LfN+orQfvzkyMpBNNkAhMnJajPqUl8xxz54nQo+6fIzsquM1ff1 EZzrHX7bagAH1CWwo6ep8r0ZiA5kvb7FfLJFK3gWYf2YSclnmK4OA/FEHvp+AqMXcsfr aNT31TEcJlZD0L6ALjCRnKhZCN67jfakz+DsE= MIME-Version: 1.0 Received: by 10.236.77.98 with SMTP id c62mr26180860yhe.109.1321957766276; Tue, 22 Nov 2011 02:29:26 -0800 (PST) Received: by 10.236.105.131 with HTTP; Tue, 22 Nov 2011 02:29:26 -0800 (PST) In-Reply-To: <4ECB57FF.1000804@cs.vu.nl> References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it> <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> <2011111613445962661858@chinamobile.com> <4ECB57FF.1000804@cs.vu.nl> Date: Tue, 22 Nov 2011 11:29:26 +0100 Message-ID: From: Riccardo Petrocco To: arno@cs.vu.nl Content-Type: multipart/alternative; boundary=20cf300fb0b31124c304b2504711 Cc: ppsp@ietf.org Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 10:29:30 -0000 --20cf300fb0b31124c304b2504711 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I'm currently working on implementing the missing pieces in the swift proposal. The reference implementation will be modular enough to be able to plug different algorithms in a transparent way. Along with implementing important features, such as an availability tree for the swarm and statistics about peer's link capacity, I'm also designing a new VoD scheduling algorithm. As Arno mentioned in the previous mail, please let us know if some algorithms, you would like to integrate, have special requirements. Best regards, Riccardo Petrocco 2011/11/22 Arno Bakker > On 16/11/2011 06:44, zhangyunfei wrote: > >> Hi Fabio,Csaba and all=EF=BC=88speak individually), >> Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer >> protocol should be open to multiple request paradigms like >> push/pull/hybrid mode. For the bitmap expression, I am not sure if a >> generic expression can work(supporting both structured and unstructured >> data). But if it works, it's better than having different bitmap >> expressions. >> The selection of using what kind of PPSP request mode and scheduling >> algorithms, transport can be addressed in the "usage guide" document, >> which is explicit in the charter. >> > > Hi all > > good input. The plan after Taipei is to make swift open to different chun= k > addressing methods and integrity protection mechanisms. With the former i= n > mind, could you have a look at the swift proposal and see if there are > things missing that you need to use the chunk+peer selection policies tha= t > you are currently using. > > I.e., determine the requirements that your selection policies put on the > protocol, and if they are currently met? > > Thanks, > Arno > > ______________________________**_________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/**listinfo/ppsp > --20cf300fb0b31124c304b2504711 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I'm currently working on implementing the missing pieces= in the swift proposal. The reference implementation will be modular eno= ugh to be able to plug different algorithms in a transparent way. Along = with implementing important features, such as an availability tree for the = swarm and statistics about peer's link capacity, I'm also designing a new VoD scheduling algorithm. As Arno mentioned in the previous mail, please let us know if some algori= thms, you would like to integrate, have special requirements. Best regards, Riccardo Petrocco 2011/1= 1/22 Arno Bakker <arn= o@cs.vu.nl> On 16/11/2011 06:44, zhangyunfei wrote: Hi Fabio,Csaba and all=EF=BC=88speak individually), Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer= protocol should be open to multiple request paradigms like push/pull/hybrid mode. For the bitmap expression, I am not sure if a generic expression can work(supporting both structured and unstructured data). But if it works, it's better than having different bitmap expressions. The selection of using what kind of PPSP request mode and scheduling algorithms, transport can be addressed in the "usage guide" docum= ent, which is explicit in the charter. Hi all good input. The plan after Taipei is to make swift open to different chunk = addressing methods and integrity protection mechanisms. With the former in = mind, could you have a look at the swift proposal and see if there are thin= gs missing that you need to use the chunk+peer selection policies that you = are currently using. I.e., determine the requirements that your selection policies put on the pr= otocol, and if they are currently met? Thanks, =C2=A0 =C2=A0Arno _______________________________________________ ppsp mailing list ppsp@ietf.org ht= tps://www.ietf.org/mailman/listinfo/ppsp --20cf300fb0b31124c304b2504711-- From kiraly@disi.unitn.it Tue Nov 22 02:42:11 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597B621F8DF6 for ; Tue, 22 Nov 2011 02:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.119 X-Spam-Level: X-Spam-Status: No, score=-4.119 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJO6wlhVuAJi for ; Tue, 22 Nov 2011 02:42:10 -0800 (PST) Received: from mail1.unitn.it (mail1.unitn.it [193.205.206.53]) by ietfa.amsl.com (Postfix) with ESMTP id 346E221F8DEC for ; Tue, 22 Nov 2011 02:42:10 -0800 (PST) Received: from mail1.unitn.it (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1ABDD540EB for ; Tue, 22 Nov 2011 11:42:08 +0100 (CET) Received: from mailhub2.unitn.it (mailhub2.unitn.it [192.168.206.47]) by mail1.unitn.it (Postfix) with ESMTP id 0950654076 for ; Tue, 22 Nov 2011 11:41:56 +0100 (CET) Received: from disi.unitn.it (dit.unitn.it [193.205.194.4]) by mailhub2.unitn.it (Postfix) with ESMTP id E3196B0D3D5 for ; Tue, 22 Nov 2011 11:41:56 +0100 (CET) Received: from [193.205.213.86] (gep.disi.unitn.it [193.205.213.86]) by disi.unitn.it (8.13.8/8.13.8) with ESMTP id pAMAfuam032203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 Nov 2011 11:41:56 +0100 Message-ID: <4ECB7C74.6040406@disi.unitn.it> Date: Tue, 22 Nov 2011 11:41:56 +0100 From: Csaba Kiraly User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: ppsp@ietf.org References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it> <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> <2011111613445962661858@chinamobile.com> <4ECB57FF.1000804@cs.vu.nl> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/alternative; boundary="------------020102060900010206000104" Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 10:42:11 -0000 This is a multi-part message in MIME format. --------------020102060900010206000104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Arno, Riccardo, I will check the current version and let you know about changes that might be needed. Can you also send me the ppt of your slides from the meeting? It might be help exchanging some ideas. Best regards, Csaba On 11/22/2011 11:29 AM, Riccardo Petrocco wrote: > Hi all, > > I'm currently working on implementing the missing pieces in the swift proposal. > The reference implementation will be modular enough to be able to plug different algorithms in a transparent way. > Along with implementing important features, such as an availability tree for the swarm and statistics about peer's > link capacity, I'm also designing a new VoD scheduling algorithm. > > As Arno mentioned in the previous mail, please let us know if some algorithms, you would like to integrate, have > special requirements. > > Best regards, > Riccardo Petrocco > > 2011/11/22 Arno Bakker > > > On 16/11/2011 06:44, zhangyunfei wrote: > > Hi Fabio,Csaba and all（speak individually), > Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer > protocol should be open to multiple request paradigms like > push/pull/hybrid mode. For the bitmap expression, I am not sure if a > generic expression can work(supporting both structured and unstructured > data). But if it works, it's better than having different bitmap > expressions. > The selection of using what kind of PPSP request mode and scheduling > algorithms, transport can be addressed in the "usage guide" document, > which is explicit in the charter. > > > Hi all > > good input. The plan after Taipei is to make swift open to different chunk addressing methods and integrity protection mechanisms. With the former in mind, could you have a look at the swift proposal and see if there are things missing that you need to use the chunk+peer selection policies that you are currently using. > > I.e., determine the requirements that your selection policies put on the protocol, and if they are currently met? > > Thanks, > Arno > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --------------020102060900010206000104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Arno, Riccardo, I will check the current version and let you know about changes that might be needed. Can you also send me the ppt of your slides from the meeting? It might be help exchanging some ideas. Best regards, Csaba On 11/22/2011 11:29 AM, Riccardo Petrocco wrote: Hi all, I'm currently working on implementing the missing pieces in the swift proposal. The reference implementation will be modular enough to be able to plug different algorithms in a transparent way. Along with implementing important features, such as an availability tree for the swarm and statistics about peer's link capacity, I'm also designing a new VoD scheduling algorithm. As Arno mentioned in the previous mail, please let us know if some algorithms, you would like to integrate, have special requirements. Best regards, Riccardo Petrocco 2011/11/22 Arno Bakker <arno@cs.vu.nl> On 16/11/2011 06:44, zhangyunfei wrote: Hi Fabio,Csaba and all（speak individually), Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer protocol should be open to multiple request paradigms like push/pull/hybrid mode. For the bitmap expression, I am not sure if a generic expression can work(supporting both structured and unstructured data). But if it works, it's better than having different bitmap expressions. The selection of using what kind of PPSP request mode and scheduling algorithms, transport can be addressed in the "usage guide" document, which is explicit in the charter. Hi all good input. The plan after Taipei is to make swift open to different chunk addressing methods and integrity protection mechanisms. With the former in mind, could you have a look at the swift proposal and see if there are things missing that you need to use the chunk+peer selection policies that you are currently using. I.e., determine the requirements that your selection policies put on the protocol, and if they are currently met? Thanks, Arno _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --------------020102060900010206000104-- From gyuri@kth.se Tue Nov 22 03:13:16 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E708621F8CC6 for ; Tue, 22 Nov 2011 03:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDN5axdh-Ffd for ; Tue, 22 Nov 2011 03:13:13 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id 7264D21F8AEA for ; Tue, 22 Nov 2011 03:13:12 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id A663314DC8A; Tue, 22 Nov 2011 12:12:40 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id Ehf2693istXs; Tue, 22 Nov 2011 12:12:36 +0100 (CET) X-KTH-Auth: gyuri [130.237.50.122] X-KTH-mail-from: gyuri@kth.se Received: from [130.237.50.122] (gyuri-lcn-e6400.s3.kth.se [130.237.50.122]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 51F4614DC5F; Tue, 22 Nov 2011 12:12:36 +0100 (CET) Message-ID: <4ECB83A3.3000603@kth.se> Date: Tue, 22 Nov 2011 12:12:35 +0100 From: =?ISO-8859-1?Q?Gy=F6rgy_D=E1n?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Csaba Kiraly References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it> <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> <2011111613445962661858@chinamobile.com> <4ECB57FF.1000804@cs.vu.nl> <4ECB7C74.6040406@disi.unitn.it> In-Reply-To: <4ECB7C74.6040406@disi.unitn.it> Content-Type: multipart/alternative; boundary="------------090101040109010105060403" Cc: ppsp@ietf.org Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 11:13:17 -0000 This is a multi-part message in MIME format. --------------090101040109010105060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, Coming back to the issue of buffer map encoding, I would argue for creating a mandatory structure/encoding, but allow for alternatives to be defined later. A mandatory (or recommended) structure/encoding that satisfies the requirements of most of the existing (proposed) chunk scheduling algorithms is excellent for demonstrating PPSP. For example, based on state-of-the-art video coding, decoding and loss concealment technology, I could imagine information about the distortion, the interdependency between chunks (to reflect coding dependencies), the temporal vs. spatial scalability/layering to be conveyed by the buffer-map. With future development of video coding and decoding algorithms, the scheduling algorithms might want to make use of additional information, and new structures/encodings will have to be defined. Best regards, Gy�rgy On 2011.11.22. 11:41, Csaba Kiraly wrote: > Hi Arno, Riccardo, > > I will check the current version and let you know about changes that > might be needed. Can you also send me the ppt of your slides from the > meeting? It might be help exchanging some ideas. > > Best regards, > Csaba > > On 11/22/2011 11:29 AM, Riccardo Petrocco wrote: >> Hi all, >> >> I'm currently working on implementing the missing pieces in the swift >> proposal. >> The reference implementation will be modular enough to be able to >> plug different algorithms in a transparent way. >> Along with implementing important features, such as an availability >> tree for the swarm and statistics about peer's >> link capacity, I'm also designing a new VoD scheduling algorithm. >> >> As Arno mentioned in the previous mail, please let us know if some >> algorithms, you would like to integrate, have >> special requirements. >> >> Best regards, >> Riccardo Petrocco >> >> 2011/11/22 Arno Bakker > >> >> On 16/11/2011 06:44, zhangyunfei wrote: >> >> Hi Fabio,Csaba and all(speak individually), >> Becasue PPSP doesn't cover the scheduling selection , I think >> PPSP peer >> protocol should be open to multiple request paradigms like >> push/pull/hybrid mode. For the bitmap expression, I am not >> sure if a >> generic expression can work(supporting both structured and >> unstructured >> data). But if it works, it's better than having different bitmap >> expressions. >> The selection of using what kind of PPSP request mode and >> scheduling >> algorithms, transport can be addressed in the "usage guide" >> document, >> which is explicit in the charter. >> >> >> Hi all >> >> good input. The plan after Taipei is to make swift open to >> different chunk addressing methods and integrity protection >> mechanisms. With the former in mind, could you have a look at the >> swift proposal and see if there are things missing that you need >> to use the chunk+peer selection policies that you are currently >> using. >> >> I.e., determine the requirements that your selection policies put >> on the protocol, and if they are currently met? >> >> Thanks, >> Arno >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >> >> >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --------------090101040109010105060403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, Coming back to the issue of buffer map encoding, I would argue for creating a mandatory structure/encoding, but allow for alternatives to be defined later. A mandatory (or recommended) structure/encoding that satisfies the requirements of most of the existing (proposed) chunk scheduling algorithms is excellent for demonstrating PPSP. For example, based on state-of-the-art video coding, decoding and loss concealment technology, I could imagine information about the distortion, the interdependency between chunks (to reflect coding dependencies), the temporal vs. spatial scalability/layering to be conveyed by the buffer-map. With future development of video coding and decoding algorithms, the scheduling algorithms might want to make use of additional information, and new structures/encodings will have to be defined. Best regards, György On 2011.11.22. 11:41, Csaba Kiraly wrote: Hi Arno, Riccardo, I will check the current version and let you know about changes that might be needed. Can you also send me the ppt of your slides from the meeting? It might be help exchanging some ideas. Best regards, Csaba On 11/22/2011 11:29 AM, Riccardo Petrocco wrote: Hi all, I'm currently working on implementing the missing pieces in the swift proposal. The reference implementation will be modular enough to be able to plug different algorithms in a transparent way. Along with implementing important features, such as an availability tree for the swarm and statistics about peer's link capacity, I'm also designing a new VoD scheduling algorithm. As Arno mentioned in the previous mail, please let us know if some algorithms, you would like to integrate, have special requirements. Best regards, Riccardo Petrocco 2011/11/22 Arno Bakker <arno@cs.vu.nl> On 16/11/2011 06:44, zhangyunfei wrote: Hi Fabio,Csaba and all（speak individually), Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer protocol should be open to multiple request paradigms like push/pull/hybrid mode. For the bitmap expression, I am not sure if a generic expression can work(supporting both structured and unstructured data). But if it works, it's better than having different bitmap expressions. The selection of using what kind of PPSP request mode and scheduling algorithms, transport can be addressed in the "usage guide" document, which is explicit in the charter. Hi all good input. The plan after Taipei is to make swift open to different chunk addressing methods and integrity protection mechanisms. With the former in mind, could you have a look at the swift proposal and see if there are things missing that you need to use the chunk+peer selection policies that you are currently using. I.e., determine the requirements that your selection policies put on the protocol, and if they are currently met? Thanks, Arno _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --------------090101040109010105060403-- From r.petrocco@gmail.com Tue Nov 22 04:23:11 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6721F8B5E for ; Tue, 22 Nov 2011 04:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExKsyYks7-Jg for ; Tue, 22 Nov 2011 04:23:07 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25FB821F8B2A for ; Tue, 22 Nov 2011 04:23:07 -0800 (PST) Received: by ghrr14 with SMTP id r14so110151ghr.31 for ; Tue, 22 Nov 2011 04:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J6SzZXLlkhV+onsi9o4cqzbVbctcELbN9l4jgU/6y10=; b=bcEaegCRTN5e+9+VWHedruJpVhH/J6nXfqay2FVlSW21TCsCj/1XeSXmMP+GZdxeXx S0LwO4OHm0hzmKHCGe5jK7L5LCYeQjYQgg5ZG5t8LhvYQa3exKFxZaliF7qEOqg4Y1CF H2o6jYgYYECbh+W4mrbEwm6y6VOh/xeLPDrJo= MIME-Version: 1.0 Received: by 10.236.124.17 with SMTP id w17mr26023352yhh.126.1321964585606; Tue, 22 Nov 2011 04:23:05 -0800 (PST) Received: by 10.236.105.131 with HTTP; Tue, 22 Nov 2011 04:23:05 -0800 (PST) In-Reply-To: <4ECB83A3.3000603@kth.se> References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it> <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> <2011111613445962661858@chinamobile.com> <4ECB57FF.1000804@cs.vu.nl> <4ECB7C74.6040406@disi.unitn.it> <4ECB83A3.3000603@kth.se> Date: Tue, 22 Nov 2011 13:23:05 +0100 Message-ID: From: Riccardo Petrocco To: =?ISO-8859-1?Q?Gy=F6rgy_D=E1n?= Content-Type: multipart/alternative; boundary=20cf300e4fbf87de0004b251dd0e Cc: ppsp@ietf.org Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2011 12:23:11 -0000 --20cf300e4fbf87de0004b251dd0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gy=C3=B6rgy and all, In my personal opinion, at this stage, the proposal should be independent from the coding details of the video stream. It should be modular enough to provide an easy way of integrating different codec specific "extensions". The Swift proposal should not really care about what kind of stream will be retrieved, but just focus on retrieving "bits". Specific "extensions" can be added, that parse the data (or the metadata) to get infos needed by download algorithms (also specific to the type of stream). That said, I'm In favor of including a "reference coding solution" using state-of-the-art solutions as a proof of concept, and the details could be added to the appendix of the proposal. Just my 2 euro cents, Regards, Riccardo 2011/11/22 Gy=C3=B6rgy D=C3=A1n > Hi all, > > Coming back to the issue of buffer map encoding, I would argue for > creating a mandatory structure/encoding, but allow for alternatives to be > defined later. A mandatory (or recommended) structure/encoding that > satisfies the requirements of most of the existing (proposed) chunk > scheduling algorithms is excellent for demonstrating PPSP. For example, > based on state-of-the-art video coding, decoding and loss concealment > technology, I could imagine information about the distortion, the > interdependency between chunks (to reflect coding dependencies), the > temporal vs. spatial scalability/layering to be conveyed by the buffer-ma= p. > With future development of video coding and decoding algorithms, the > scheduling algorithms might want to make use of additional information, a= nd > new structures/encodings will have to be defined. > > Best regards, > Gy=C3=B6rgy > > > On 2011.11.22. 11:41, Csaba Kiraly wrote: > > Hi Arno, Riccardo, > > I will check the current version and let you know about changes that migh= t > be needed. Can you also send me the ppt of your slides from the meeting? = It > might be help exchanging some ideas. > > Best regards, > Csaba > > On 11/22/2011 11:29 AM, Riccardo Petrocco wrote: > > Hi all, > > I'm currently working on implementing the missing pieces in the swift > proposal. > The reference implementation will be modular enough to be able to plug > different algorithms in a transparent way. > Along with implementing important features, such as an availability tree > for the swarm and statistics about peer's > link capacity, I'm also designing a new VoD scheduling algorithm. > > As Arno mentioned in the previous mail, please let us know if some > algorithms, you would like to integrate, have > special requirements. > > Best regards, > Riccardo Petrocco > > 2011/11/22 Arno Bakker > >> On 16/11/2011 06:44, zhangyunfei wrote: >> >>> Hi Fabio,Csaba and all=EF=BC=88speak individually), >>> Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer >>> protocol should be open to multiple request paradigms like >>> push/pull/hybrid mode. For the bitmap expression, I am not sure if a >>> generic expression can work(supporting both structured and unstructured >>> data). But if it works, it's better than having different bitmap >>> expressions. >>> The selection of using what kind of PPSP request mode and scheduling >>> algorithms, transport can be addressed in the "usage guide" document, >>> which is explicit in the charter. >>> >> >> Hi all >> >> good input. The plan after Taipei is to make swift open to different >> chunk addressing methods and integrity protection mechanisms. With the >> former in mind, could you have a look at the swift proposal and see if >> there are things missing that you need to use the chunk+peer selection >> policies that you are currently using. >> >> I.e., determine the requirements that your selection policies put on the >> protocol, and if they are currently met? >> >> Thanks, >> Arno >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >> > > > _______________________________________________ > ppsp mailing listppsp@ietf.orghttps://www.ietf.org/mailman/listinfo/ppsp > > > > > _______________________________________________ > ppsp mailing listppsp@ietf.orghttps://www.ietf.org/mailman/listinfo/ppsp > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > --20cf300e4fbf87de0004b251dd0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Gy=C3=B6rgy and all, In my personal opinion, at this stage, the p= roposal should be independent from the coding details of the video stream.<= br>It should be modular enough to provide an easy way of integrating differ= ent codec specific "extensions". The Swift proposal should not really care about what kind of stream will be= retrieved, but just focus on retrieving "bits". Specific = "extensions" can be added, that parse the data (or the metadata) = to get infos needed by download algorithms (also specific to the type of stream). That said, I'm In favor of i= ncluding a "reference coding solution" using state-of-the-art sol= utions as a proof of concept, and the details could be added to the app= endix of the proposal. Just my 2 euro cents, Regards, Riccardo 2011/11/22 Gy=C3=B6rgy D=C3=A1n <gyuri@kth.se> =20 =20 =20 Hi all, Coming back to the issue of buffer map encoding, I would argue for creating a mandatory structure/encoding, but allow for alternatives to be defined later. A mandatory (or recommended) structure/encoding that satisfies the requirements of most of the existing (proposed) chunk scheduling algorithms is excellent for demonstrating PPSP.=C2=A0= =C2=A0 For example, based on state-of-the-art video coding, decoding and loss concealment technology, I could imagine information about the distortion, the interdependency between chunks (to reflect coding dependencies), the temporal vs. spatial scalability/layering to be conveyed by the buffer-map. With future development of video coding and decoding algorithms, the scheduling algorithms might want to make use of additional information, and new structures/encodings will have to be defined. Best regards, =C2=A0Gy=C3=B6rgy On 2011.11.22. 11:41, Csaba Kiraly wrote: =20 Hi Arno, Riccardo, I will check the current version and let you know about changes that might be needed. Can you also send me the ppt of your slides from the meeting? It might be help exchanging some ideas. Best regards, Csaba On 11/22/2011 11:29 AM, Riccardo Petrocco wrote: Hi all, I'm currently working on implementing the missing pieces in the swift proposal. The reference implementation will be modular enough to be able to plug different algorithms in a transparent way. Along with implementing important features, such as an availability tree for the swarm and statistics about peer's link capacity, I'm also designing a new VoD scheduling algorithm. As Arno mentioned in the previous mail, please let us know if some algorithms, you would like to integrate, have special requirements. Best regards, Riccardo Petrocco 2011/11/22 Arno Bakker <arno@cs.vu.nl&g= t; On 16/11/2011 06:44, zhangyunfei wrote: Hi Fabio,C= saba and all=EF=BC=88speak individually), Becasue PPSP doesn't cover the scheduling selection , I think PPSP peer protocol should be open to multiple request paradigms like push/pull/hybrid mode. For the bitmap expression, I am not sure if a generic expression can work(supporting both structured and unstructured data). But if it works, it's better than having different bitmap expressions. The selection of using what kind of PPSP request mode and scheduling algorithms, transport can be addressed in the "usage guide" document, which is explicit in the charter. Hi all good input. The plan after Taipei is to make swift open to different chunk addressing methods and integrity protection mechanisms. With the former in mind, could you have a look at the swift proposal and see if there are things missing that you need to use the chunk+peer selection policies that you are currently using. I.e., determine the requirements that your selection policies put on the protocol, and if they are currently met? Thanks, =C2=A0 =C2=A0Arno _______________________________________________ ppsp mailing list ppsp@iet= f.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org ht= tps://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org ht= tps://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org ht= tps://www.ietf.org/mailman/listinfo/ppsp --20cf300e4fbf87de0004b251dd0e-- From Martin.Stiemerling@neclab.eu Wed Nov 23 08:17:01 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9381F0C36 for ; Wed, 23 Nov 2011 08:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.333 X-Spam-Level: X-Spam-Status: No, score=-102.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5Iqh+XdJzJQ for ; Wed, 23 Nov 2011 08:17:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DE8191F0C3F for ; Wed, 23 Nov 2011 08:17:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EDCF7280001CB for ; Wed, 23 Nov 2011 17:16:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czu0glIQmHyT for ; Wed, 23 Nov 2011 17:16:59 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D071B280001C9 for ; Wed, 23 Nov 2011 17:16:54 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 23 Nov 2011 17:16:54 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: IETF Note-Well and IPR rules Thread-Index: Acyp+reQzTRPnR+cRoCgwVrBhY8kGg== Date: Wed, 23 Nov 2011 16:16:53 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] IETF Note-Well and IPR rules X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 16:17:01 -0000 Dear all, This is just a periodic reminder about the IETF Note Well and the IPR rules= .=20 Please read the latest, up to date Note-Well here: http://www.ietf.org/about/note-well.html Please read the latest, up to date IPR policy here: http://www.ietf.org/ipr/policy.html Thanks and with best regards, Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From Martin.Stiemerling@neclab.eu Thu Nov 24 06:34:21 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD7021F8C50 for ; Thu, 24 Nov 2011 06:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bKUk5NmENXr for ; Thu, 24 Nov 2011 06:34:20 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C6CFF21F8C2A for ; Thu, 24 Nov 2011 06:34:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CFE8D2800017C for ; Thu, 24 Nov 2011 15:34:18 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sol7oos3r9Xu for ; Thu, 24 Nov 2011 15:34:18 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B1990280000FA for ; Thu, 24 Nov 2011 15:34:13 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 24 Nov 2011 15:34:13 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: IETF-82 meeting minutes for PPSP Thread-Index: AcyqtfN7nkzpVRudSc2+9+PzCSmOhg== Date: Thu, 24 Nov 2011 14:34:12 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] IETF-82 meeting minutes for PPSP X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 14:34:21 -0000 Dear all, Please find below the meeting minutes of the PPSP session at the IETF-82 me= eting in Taipei.=20 You can also find the minutes here: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please check the minutes and the let chairs know any change request until D= ecember 1st, 5pm PT.=20 Thank you, Martin Minutes are here: IETF82 Taipei, 13.-18.11.2011=20 Tuesday 15.11.2011 9:00-11:30: PPSP=20 Minutes by Christian Schmidt Administriva (note takers, blue sheets, note well, agenda)=20 Announcement of a PPSP demo (after the PPSP session)=20 Current Status and progress Rui Cruz presented Tracker Protocol (draft-gu-ppsp-tracker-protocol) Martin Stiemerling (Floor): I am confused about the maturity of the ID, thi= ngs are missing or put into in a=20 rush. The slides do not reflect this status. You should focus on the basic = issue for the tracker protocol=20 and leave other topics for further versions. Or put these to the appendix, = to be considered in a later=20 version.=20 Rui Cruz: Accepted.=20 Martin Stiemerling (Floor): What is the semantically meaning of Disconnect?= =20 Rui Cruz: Leaving all swarms.=20 Martin Stiemerling (Floor): It is not written in the ID. It is perhaps some= how hidden in the text.=20 Rui Cruz: Perhaps. Using Leave could be an alternative.=20 Martin Stiemerling (Floor): What happen if the peer just vanishes?=20 Rui Cruz: On not receiving the tracker report, the tracker can clean up the= connection.=20 Martin Stiemerling (Floor): This all is not described in the ID in a proper= way, e.g. the state engine. It is=20 hard to understand the implication. An updated version is needed.=20 Rui Cruz: It is already addressed in the draft, how this all works.=20 Martin Stiemerling (Floor): I am not sure. Request Messages=20 Arno Bakker: For security layer SASL was chosen, not HTTPS?=20 Rui Cruz: HTTPS can be used. SASL is a very lightweight protocol. The sessi= on between peer and tracker=20 is not kept open. Therefore SASL is better.=20 Arno Bakker: Please explain this in the ID, why HTTPS is not taken into acc= ount. We have to be very clear,=20 how security works in this aspect. It is missing, it is very important. Yunfei Zhang (Floor): How does a Leech announce that it contributes to othe= r peers?=20 Rui Cruz: Announcement at the beginning. Peerlist contains all peers in a s= warm.=20 Yunfei Zhang (Floor): In live streaming, what is the difference of a peer t= o be a LEECH or a LIVE SEED?=20 Rui Cruz: LIVESEED is Source of live streaming content. Riccardo Petrocco: Are just helpers for a swarm included?=20 Rui Cruz: Not specified in the ID. E.g. superpeers are not included.=20 Riccardo Petrocco: A description for this is missing in the ID. =20 Martin Stiemerling: Clarify role of SEED and LEECH in live streaming.=20 Rui Cruz: There is a specific condition; there is neither start nor end. Arno Bakker: How to avoid malicious peers to act as LIVESEEDs?=20 Rui Cruz: Security aspects for swarms are not easy to achieve.=20 Arno Bakker: You have to add information to verify content, that's not in t= he ID now. How to protect=20 LIVESEED label?=20 Martin Stiemerling: Take this to the list. Martin Stiemerling: Privacy issues with ChunkMaps? Contain ChunkMaps for al= l the streaming contents=20 the peer is currently joined?=20 Rui Cruz: No, only the info related to a certain tracker. Arno Bakker: in interim meeting we agreed on a basic tracker with minimal f= unction. Are all of the=20 presented features mandatory?=20 Rui Cruz: No, most of them are optional. Riccardo Petrocco: Status messages are not clear, why do you need all this = information, e.g. ChunkMap?=20 Rui Cruz: The tracker should know, this is the structure and who has what.T= he protocol does not care=20 about the structure. It helps the tracker. Is this ID ready for WG item?=20 Ning Zong: This is in the right direction. Language has to be checked. I su= pport this as WG item.=20 Martin Stiemerling (Floor): ID is on the right track, but very important pa= rts are missing, e.g. syntax,=20 semantics and how it works. I would feel uneasy to take this as WI now. Ano= ther version is needed .=20 Arno Bakker: Agreed another round is needed.=20 Yunfei Zhang: We should have another round of modifications before taking t= his as a WI. Rui Cruz presented Peer Protocol (draft-gu-ppsp-peer-protocol) Arno Bakker: If you use pull based model for chunk maps, then you may be la= cking behind in information.=20 You need actual information about content you really can supply. How do you= ensure actuality?=20 Rui Cruz: Sequential method to fetch chunks. E.g. the rarest can be address= ed first. What chunk do I=20 need for immediate presentation?=20 Arno Bakker: There is an asymmetric situation. You can come into a situatio= n, where nobody has certain=20 chunks to provide, due to the delay in information.=20 Rui Cruz: This is not part of protocol primitives.=20 Arno Bakker: They can have influence.=20 Martin Stiemerling (Floor): This information is periodically distributed fr= om the system. I do not=20 understand why pull method is used here.=20 Rui Cruz: The name of the primitive is misleading here.=20 Martin Stiemerling (Floor): There is no GET for chunk map update.=20 Arno Bakker: Push Method is urgently needed.=20 Rui Cruz: Push mode could cause malicious attacks.=20 Yunfei Zhang: PPSP support both push and pull mode. Modify the ID to suppor= t both modes.=20 Martin Stiemerling (Floor): Very high level, crucial issues are missing. Ca= n we support both push and pull=20 in parallel?=20 Rui Cruz: Yes. In live streaming push may be more appropriate.=20 Martin Stiemerling (Floor): Hybrid mode could be possible. E.g. pull the ne= xt hundred chunks. That is=20 something we need. Arno Bakker presented Peer Protocol (draft-grishchenko-ppsp-swift) Yunfei Zhang: Normally the checksum is included in message. Checking data i= ntegrity with checksum=20 after downloading the data is common usage.=20 Arno Bakker: Hash message contains all info needed to check the data. Hash = info is combined with Data=20 message.=20 Martin Stiemerling (Floor): Is it only used for VoD or live streaming?=20 Arno Bakker: Both.=20 Yunfei Zhang: Different peers have different conditions. Perhaps with push = you waste bandwidth:=20 Arno Bakker: We do not push chunks:=20 Yunfei Zhang: That's valid for chunkmaps as well.=20 Arno Bakker: I always inform you, what chunks I have.=20 Yunfei Zhang: This could be optional.=20 Arno Bakker: I do not think this is very expensive. The overhead is small.= =20 Ming Song: Rarest first policy, maybe push is not the best solution.=20 Arno Bakker: If you use other policies, please provide this info to the mai= ling list.=20 Martin Stiemerling: List name and impact of policies to protocol. Martin Stiemerling (Floor): Is there a reason to go over RTP?=20 Arno Bakker: HTTP or RTP to be used in the charter.=20 Martin Stiemerling (Floor): I would prefer going over UDP. This needs furth= er discussion.=20 Yunfei Zhang: Charter says, we should reuse existing protocols, RTP is just= an example. It doesn't mean=20 we have to reuse RTP even it's not suitable.=20 Arno Bakker: We have to protect the content against malicious modifications= .=20 Enrico Marocco: Does HTTP here really make sense? Better explain why HTTP d= oes not make sense.=20 Arno Bakker: Agreed.=20 Martin Stiemerling (Floor): It was not Arno's idea, we should not do this.= =20 Enrico Marocco: Do you have scalability numbers?=20 Arno Bakker: We tested it with 200 peers.=20 Enrico Marocco: Question on hashtree: can roothash be used to validate the = complete stream?=20 Arno Bakker: In theory yes.=20 Enrico Marocco: Why not use individual hashes?=20 Arno Bakker: You can optimize the system; you do not have to send the compl= ete hash table.=20 Enrico Marocco: More efficient than sending a hash for every chunk.=20 Arno Bakker: As said, it can be optimized, included in the ID: Martin Stiemerling (Floor): ID fairly elaborated. Can you include tradition= al ways to handle chunks and=20 hashtables?=20 Arno Bakker: We can extent the ID for this purpose, we can add in a next re= vision. Martin Stiemerling: Two peer protocols presented here. It is hard to decide= , what the best way forward=20 is. What is the opinion of the people?=20 Yunfei Zhang: I would like to see a merger of both protocol, both of them h= ave some advantages. Let's=20 find consensus on message definition and then how to use these messages.=20 Enrico Marocco: I would really like to avoid the merger. Have beauty conten= t and decide. Some features=20 can be included into the other proposal.=20 Arno Bakker: Go forward with Swift.=20 Martin Stiemerling (Floor): Gu - lack of maturity in the ID. Swift looks mo= re as a workable solution. Let's=20 take swift as basis, this would make things a lot easier.=20 Shawn Shedy: as implementer - swift seems to me mature and complete. I woul= d like to see this as basis=20 for the peer protocol.=20 Enrico Marocco: Integration would not be a good solution.=20 Martin Stiemerling: Here a majority is more in favor of swift. Let's take t= his on the list to make a final=20 decision. Xiao Lin presented Distribured Tracker (draft-xiao-ppsp-relaod-distributed = tracker) Due to limited time, there has been no discussion on the distributed tracke= r presentation. It was=20 suggested to give comments on the list. martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From Martin.Stiemerling@neclab.eu Thu Nov 24 06:43:01 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1FC21F8B34 for ; Thu, 24 Nov 2011 06:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMfqfaNfo6WY for ; Thu, 24 Nov 2011 06:43:00 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAEC21F8B2D for ; Thu, 24 Nov 2011 06:43:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D643A280001C9 for ; Thu, 24 Nov 2011 15:42:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toDnvY5Cw3R0 for ; Thu, 24 Nov 2011 15:42:59 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id BBDDE2800017C for ; Thu, 24 Nov 2011 15:42:54 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 24 Nov 2011 15:42:33 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: Selection of PPSP peer protocol draft Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/Q== Date: Thu, 24 Nov 2011 14:42:32 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 14:43:01 -0000 Dear all,=20 The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol.=20 We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From ag@ag-projects.com Fri Nov 25 04:30:30 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A6121F8C9D for ; Fri, 25 Nov 2011 04:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pps8ViNA+29T for ; Fri, 25 Nov 2011 04:30:30 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E1EF521F8C9C for ; Fri, 25 Nov 2011 04:30:29 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id CE32DB01BB; Fri, 25 Nov 2011 13:30:27 +0100 (CET) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id D50BAB017D; Fri, 25 Nov 2011 13:30:26 +0100 (CET) From: Adrian Georgescu Content-Type: multipart/signed; boundary="Apple-Mail=_5F483CC1-13C9-4D1E-B5F4-20FD84D7D097"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Fri, 25 Nov 2011 13:30:26 +0100 To: ppsp@ietf.org Message-Id: <056330CA-F939-4201-B312-D9495628EFCB@ag-projects.com> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 12:30:30 -0000 --Apple-Mail=_5F483CC1-13C9-4D1E-B5F4-20FD84D7D097 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My vote goes to draft-grishchenko-ppsp-swift proposal Swift proposal has a better design with regards to key ingredients for = what a peer to peer network requires in order to properly operate. It is = IP transport agnostic, has NAT traversal capability and has built-in = detection for Man in the Middle Attacks by design to name a few critical = features of a p2p application relying on transient end-points over the = Internet. Using HTTP only as transport inherits most of its flaws, the = most relevant being impossibility of directly reach peer clients located = behind NAT. The limitations and assumptions made by = draft-gu-ppsp-peer-protocol are a bit out of date with reality about how = connectivity works on Internet today. Overall, Swift proposal looks more mature. I am a software developer and I have implemented working P2P real-time = communications systems deployed commercially over the public Internet = since 2005. http://ag-projects.com/sip-thor-products-291 Kind regards, Adrian Georgescu --Apple-Mail=_5F483CC1-13C9-4D1E-B5F4-20FD84D7D097 Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk7PimIACgkQBWdpqVEZtGfn7wCgn1ryfnQh1x62W2/0j8Fvk9eu EIoAoKCC7auVGHGLNplGuXEBciMZIN3J =56D4 -----END PGP SIGNATURE----- --Apple-Mail=_5F483CC1-13C9-4D1E-B5F4-20FD84D7D097-- From mark@pddresearch.com Fri Nov 25 04:56:15 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD7D21F8B86 for ; Fri, 25 Nov 2011 04:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd4xAzWe6p-I for ; Fri, 25 Nov 2011 04:56:15 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA721F8B81 for ; Fri, 25 Nov 2011 04:56:14 -0800 (PST) Received: by qyk32 with SMTP id 32so2921182qyk.31 for ; Fri, 25 Nov 2011 04:56:14 -0800 (PST) Received: by 10.229.241.146 with SMTP id le18mr3709340qcb.296.1322225774353; Fri, 25 Nov 2011 04:56:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.183.208 with HTTP; Fri, 25 Nov 2011 04:55:43 -0800 (PST) From: Mark Stuart Date: Fri, 25 Nov 2011 12:55:43 +0000 Message-ID: To: ppsp@ietf.org Content-Type: multipart/alternative; boundary=0016363b913a97de8004b28ead1a Subject: [ppsp] VOTE_BY_EMAIL for swift as technology for PPSP X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2011 12:56:15 -0000 --0016363b913a97de8004b28ead1a Content-Type: text/plain; charset=ISO-8859-1 Dear PPSP, I am please to participate in the voting and would like to submit Pioneer's vote for the *swift* technology (developed by TUDelft et al. as part of the P2P-Next project). My name is Mark Stuart and I represent Pioneer Digital Design in the UK. My team have been trialling both BitTorrent and swift-based P2P technology for Live and VoD streaming in the UK for the past 4 years - specifically as applied very low-cost and low-power consumer electronics devices. Swift represents a relatively efficient, elegant and lightweight transport that can be adapted to a number of use cases (CDN, VoD streaming etc...). In addition the modular, policy-based approach chosen by TUDelft for peer discovery and security considerations enables a wide variety of deployments whilst keeping the core technology light and agile. The metadata-less approach of referring to content via a single 40-byte root hash both anticipates future CCN requirements whilst being able to be deployed and operated on existing IPv4 and IPv6 environments using the UDP transport. All things considered, I am very impressed by swift and happy to lend my vote and support for its standardisation and broader adoption within the IETF community. Best regards, -Mark Stuart. --0016363b913a97de8004b28ead1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear PPSP,=A0 <= /div>I am please to participate in the voting and would like to s= ubmit Pioneer's vote for the=A0swift=A0technology (developed by = TUDelft et al. as part of the P2P-Next project).=A0 My name i= s Mark Stuart and I represent Pioneer Digital Design in the UK. My team hav= e been trialling both BitTorrent and swift-based P2P technology for Live an= d VoD streaming in the UK for the past 4 years - specifically as applied ve= ry low-cost and low-power consumer electronics devices.=A0 Swift re= presents a relatively efficient, elegant and lightweight transport that can= be adapted to a number of use cases (CDN, VoD streaming etc...). In additi= on the modular, policy-based approach chosen by TUDelft for peer discovery = and security considerations enables a wide variety of deployments whilst ke= eping the core technology light and agile. The metadata-less approach of re= ferring to content via a single 40-byte root hash both anticipates future C= CN requirements whilst being able to be deployed and operated on existing I= Pv4 and IPv6 environments using the UDP transport.=A0 All thin= gs considered, I am very impressed by swift and happy to lend my vote and s= upport for its standardisation and broader adoption within the IETF communi= ty.=A0 Best reg= ards,=A0 -Mark Stuart. =A0 --0016363b913a97de8004b28ead1a-- From a.bakker@vu.nl Mon Nov 28 01:26:55 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49621F8C78 for ; Mon, 28 Nov 2011 01:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P+bmNYPP2+Y for ; Mon, 28 Nov 2011 01:26:54 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2492921F8C58 for ; Mon, 28 Nov 2011 01:26:50 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 28 Nov 2011 10:26:41 +0100 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 28 Nov 2011 10:26:46 +0100 Message-ID: <4ED35447.2020708@cs.vu.nl> Date: Mon, 28 Nov 2011 10:28:39 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] IETF-82 meeting minutes for PPSP X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 09:26:55 -0000 Hi some corrections inline: > Arno Bakker: How to avoid malicious peers to act as LIVESEEDs? AB: "How to prevent malicious peers claiming to be LIVESEEDs?" > Rui Cruz: Security aspects for swarms are not easy to achieve. > Arno Bakker: You have to add information to verify content, that's not in the ID now. How to protect > LIVESEED label? AB: "You somehow need to say 'live source for this swarm has this public key'. Need to link swarm to real injector. How you do this should be in the draft as well." > > Rui Cruz presented Peer Protocol (draft-gu-ppsp-peer-protocol) > Arno Bakker: If you use pull based model for chunk maps, then you may be lacking behind in information. > You need actual information about content you really can supply. How do you ensure actuality? AB: "If you use pull based model for chunk maps, then you may be lagging behind on the real situation. You need actual information to be able to do rarest first. How do you ensure the peer's upload is utilized as much as possible?" > Rui Cruz: Sequential method to fetch chunks. E.g. the rarest can be addressed first. What chunk do I > need for immediate presentation? > Arno Bakker: There is an asymmetric situation. You can come into a situation, where nobody has certain > chunks to provide, due to the delay in information. AB: "The implication of this design is only people further in playback time can provide pieces. If these people leave the swarm because download is complete you can come into a situation where nobobdy has the last chunks to provide." > Rui Cruz: This is not part of protocol primitives. > Arno Bakker: They can have influence. AB: "They do influence how up to date the information is that you have to do piece picking with. In pull-based there is delay between what is known locally and what is happening in the system." > Arno Bakker: We have to protect the content against malicious modifications. AB: "We have to protect the RTP header against malicious modification too." > Enrico Marocco: Does HTTP here really make sense? Better explain why HTTP does not make sense. > Arno Bakker: Agreed. AB: "Yes please, no HTTP. We only discuss it because it is in the charter." Regards, Arno From zhangyunfei@chinamobile.com Mon Nov 28 02:10:34 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8E521F8C55 for ; Mon, 28 Nov 2011 02:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.023 X-Spam-Level: X-Spam-Status: No, score=-96.023 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgDZGY5TY9EZ for ; Mon, 28 Nov 2011 02:10:30 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 63BD821F8669 for ; Mon, 28 Nov 2011 02:10:30 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 89EFFF0D9; Mon, 28 Nov 2011 18:10:19 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 7F5C7F0CD; Mon, 28 Nov 2011 18:10:19 +0800 (CST) Received: from ady-PC ([10.2.2.31]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011112818101765-21573 ; Mon, 28 Nov 2011 18:10:17 +0800 Date: Mon, 28 Nov 2011 18:10:18 +0800 From: zhangyunfei To: "arno@cs.vu.nl" , ppsp References: , <4ED35447.2020708@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201111281810188668267@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-28 18:10:17, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-11-28 18:10:18, Serialize complete at 2011-11-28 18:10:18 Content-Type: multipart/alternative; boundary="----=_001_NextPart224228264558_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18546.006 X-TM-AS-Result: No--19.018-7.0-31-10 X-imss-scan-details: No--19.018-7.0-31-10;No--19.018-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: Re: [ppsp] IETF-82 meeting minutes for PPSP X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 10:10:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart224228264558_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" VGhhbmtzIEFybm8gZm9yIHRoZSBjb3JyZWN0aW9uLqPXaWxsIGNoZWNrIHRoZSBkZXRhaWxzIGFu ZCB1cGRhdGUgdGhlIG1pbnV0ZXMuDQoNCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpG cm9tOiBBcm5vIEJha2tlcg0KRGF0ZTogMjAxMS0xMS0yOCAxNzoyOA0KVG86IHBwc3BAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbcHBzcF0gSUVURi04MiBtZWV0aW5nIG1pbnV0ZXMgZm9yIFBQU1AN CkhpDQoNCnNvbWUgY29ycmVjdGlvbnMgaW5saW5lOg0KDQoNCj4gQXJubyBCYWtrZXI6IEhvdyB0 byBhdm9pZCBtYWxpY2lvdXMgcGVlcnMgdG8gYWN0IGFzIExJVkVTRUVEcz8NCg0KQUI6ICJIb3cg dG8gcHJldmVudCBtYWxpY2lvdXMgcGVlcnMgY2xhaW1pbmcgdG8gYmUgTElWRVNFRURzPyINCg0K PiBSdWkgQ3J1ejogU2VjdXJpdHkgYXNwZWN0cyBmb3Igc3dhcm1zIGFyZSBub3QgZWFzeSB0byBh Y2hpZXZlLg0KPiBBcm5vIEJha2tlcjogWW91IGhhdmUgdG8gYWRkIGluZm9ybWF0aW9uIHRvIHZl cmlmeSBjb250ZW50LCB0aGF0J3Mgbm90IGluIHRoZSBJRCBub3cuIEhvdyB0byBwcm90ZWN0DQo+ IExJVkVTRUVEIGxhYmVsPw0KDQpBQjogIllvdSBzb21laG93IG5lZWQgdG8gc2F5ICdsaXZlIHNv dXJjZSBmb3IgdGhpcyBzd2FybSBoYXMgdGhpcyBwdWJsaWMgDQprZXknLiBOZWVkIHRvIGxpbmsg c3dhcm0gdG8gcmVhbCBpbmplY3Rvci4gSG93IHlvdSBkbyB0aGlzIHNob3VsZCBiZSBpbiANCnRo ZSBkcmFmdCBhcyB3ZWxsLiINCg0KPg0KPiBSdWkgQ3J1eiBwcmVzZW50ZWQgUGVlciBQcm90b2Nv bCAoZHJhZnQtZ3UtcHBzcC1wZWVyLXByb3RvY29sKQ0KPiBBcm5vIEJha2tlcjogSWYgeW91IHVz ZSBwdWxsIGJhc2VkIG1vZGVsIGZvciBjaHVuayBtYXBzLCB0aGVuIHlvdSBtYXkgYmUgbGFja2lu ZyBiZWhpbmQgaW4gaW5mb3JtYXRpb24uDQogPiBZb3UgbmVlZCBhY3R1YWwgaW5mb3JtYXRpb24g YWJvdXQgY29udGVudCB5b3UgcmVhbGx5IGNhbiBzdXBwbHkuIEhvdyANCmRvIHlvdSBlbnN1cmUg YWN0dWFsaXR5Pw0KDQpBQjogIklmIHlvdSB1c2UgcHVsbCBiYXNlZCBtb2RlbCBmb3IgY2h1bmsg bWFwcywgdGhlbiB5b3UgbWF5IGJlIGxhZ2dpbmcgDQpiZWhpbmQgb24gdGhlIHJlYWwgc2l0dWF0 aW9uLiBZb3UgbmVlZCBhY3R1YWwgaW5mb3JtYXRpb24gdG8gYmUgYWJsZSB0byANCmRvIHJhcmVz dCBmaXJzdC4gSG93IGRvIHlvdSBlbnN1cmUgdGhlIHBlZXIncyB1cGxvYWQgaXMgdXRpbGl6ZWQg YXMgbXVjaCANCmFzIHBvc3NpYmxlPyINCg0KPiBSdWkgQ3J1ejogU2VxdWVudGlhbCBtZXRob2Qg dG8gZmV0Y2ggY2h1bmtzLiBFLmcuIHRoZSByYXJlc3QgY2FuIGJlIGFkZHJlc3NlZCBmaXJzdC4g V2hhdCBjaHVuayBkbyBJDQo+IG5lZWQgZm9yIGltbWVkaWF0ZSBwcmVzZW50YXRpb24/DQo+IEFy bm8gQmFra2VyOiBUaGVyZSBpcyBhbiBhc3ltbWV0cmljIHNpdHVhdGlvbi4gWW91IGNhbiBjb21l IGludG8gYSBzaXR1YXRpb24sIHdoZXJlIG5vYm9keSBoYXMgY2VydGFpbg0KPiBjaHVua3MgdG8g cHJvdmlkZSwgZHVlIHRvIHRoZSBkZWxheSBpbiBpbmZvcm1hdGlvbi4NCg0KQUI6ICJUaGUgaW1w bGljYXRpb24gb2YgdGhpcyBkZXNpZ24gaXMgb25seSBwZW9wbGUgZnVydGhlciBpbiBwbGF5YmFj ayANCnRpbWUgY2FuIHByb3ZpZGUgcGllY2VzLiBJZiB0aGVzZSBwZW9wbGUgbGVhdmUgdGhlIHN3 YXJtIGJlY2F1c2UgDQpkb3dubG9hZCBpcyBjb21wbGV0ZSB5b3UgY2FuIGNvbWUgaW50byBhIHNp dHVhdGlvbiB3aGVyZSBub2JvYmR5IGhhcyB0aGUgDQpsYXN0IGNodW5rcyB0byBwcm92aWRlLiIN Cg0KPiBSdWkgQ3J1ejogVGhpcyBpcyBub3QgcGFydCBvZiBwcm90b2NvbCBwcmltaXRpdmVzLg0K PiBBcm5vIEJha2tlcjogVGhleSBjYW4gaGF2ZSBpbmZsdWVuY2UuDQoNCkFCOiAiVGhleSBkbyBp bmZsdWVuY2UgaG93IHVwIHRvIGRhdGUgdGhlIGluZm9ybWF0aW9uIGlzIHRoYXQgeW91IGhhdmUg DQp0byBkbyBwaWVjZSBwaWNraW5nIHdpdGguIEluIHB1bGwtYmFzZWQgdGhlcmUgaXMgZGVsYXkg YmV0d2VlbiB3aGF0IGlzIA0Ka25vd24gbG9jYWxseSBhbmQgd2hhdCBpcyBoYXBwZW5pbmcgaW4g dGhlIHN5c3RlbS4iDQoNCg0KPiBBcm5vIEJha2tlcjogV2UgaGF2ZSB0byBwcm90ZWN0IHRoZSBj b250ZW50IGFnYWluc3QgbWFsaWNpb3VzIG1vZGlmaWNhdGlvbnMuDQoNCkFCOiAiV2UgaGF2ZSB0 byBwcm90ZWN0IHRoZSBSVFAgaGVhZGVyIGFnYWluc3QgbWFsaWNpb3VzIG1vZGlmaWNhdGlvbiB0 b28uIg0KDQo+IEVucmljbyBNYXJvY2NvOiBEb2VzIEhUVFAgaGVyZSByZWFsbHkgbWFrZSBzZW5z ZT8gQmV0dGVyIGV4cGxhaW4gd2h5IEhUVFAgZG9lcyBub3QgbWFrZSBzZW5zZS4NCj4gQXJubyBC YWtrZXI6IEFncmVlZC4NCg0KQUI6ICJZZXMgcGxlYXNlLCBubyBIVFRQLiBXZSBvbmx5IGRpc2N1 c3MgaXQgYmVjYXVzZSBpdCBpcyBpbiB0aGUgY2hhcnRlci4iDQoNClJlZ2FyZHMsDQogICAgICBB cm5vDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBz cCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcHBzcA== ------=_001_NextPart224228264558_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312" Thanks Arno for the correction.=A3=D7ill check the details and update= the=20 minutes. Yunfei zhangyunfei From: Arno Bakker Date: 2011-11-28 17:28 To: ppsp@ietf.org Subject: Re: [ppsp] IETF-82 meeting minutes for=20 PPSP Hi some corrections inline: > Arno Bakker: How to avoid maliciou= s peers to act as LIVESEEDs? AB: "How to prevent malicious peers cla= iming to be LIVESEEDs?" > Rui Cruz: Security aspects for swa= rms are not easy to achieve. > Arno Bakker: You have to add = information to verify content, that's not in= the ID now. How to protect > LIVESEED label? AB: "You somehow need to say 'live = ;source for this swarm has this public = key'. Need to link swarm to real i= njector. How you do this should be in&n= bsp; the draft as well." > > Rui Cruz presented Peer Protocol (= draft-gu-ppsp-peer-protocol) > Arno Bakker: If you use pull = based model for chunk maps, then you ma= y be lacking behind in information. > You need actual information about= content you really can supply. How do you ensure actuality? AB: "If you use pull based model f= or chunk maps, then you may be lagging&= nbsp; behind on the real situation. You need&= nbsp;actual information to be able to do rarest first. How do you ensure = ;the peer's upload is utilized as much = as possible?" > Rui Cruz: Sequential method to fet= ch chunks. E.g. the rarest can be addre= ssed first. What chunk do I > need for immediate presentation? > Arno Bakker: There is an asymmetri= c situation. You can come into a situat= ion, where nobody has certain > chunks to provide, due to the = ;delay in information. AB: "The implication of this design is&= nbsp;only people further in playback time can provide pieces. If these peopl= e leave the swarm because download is complete you can come into&= nbsp;a situation where nobobdy has the last chunks to provide." > Rui Cruz: This is not part of= protocol primitives. > Arno Bakker: They can have influen= ce. AB: "They do influence how up to d= ate the information is that you have to do piece picking with. In pull-based= there is delay between what is known locally and what is happening in&= nbsp;the system." > Arno Bakker: We have to protect&nb= sp;the content against malicious modifications. AB: "We have to protect the RTP he= ader against malicious modification too." > Enrico Marocco: Does HTTP here rea= lly make sense? Better explain why HTTP = ;does not make sense. > Arno Bakker: Agreed. AB: "Yes please, no HTTP. We only = discuss it because it is in the charter= ." Regards, Arno _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp ------=_001_NextPart224228264558_=------ From a.bakker@vu.nl Mon Nov 28 02:16:00 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0924921F8C9C for ; Mon, 28 Nov 2011 02:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.396 X-Spam-Level: ** X-Spam-Status: No, score=2.396 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUTxsjLpk9gm for ; Mon, 28 Nov 2011 02:15:59 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2707621F8C9A for ; Mon, 28 Nov 2011 02:15:58 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 28 Nov 2011 11:15:56 +0100 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 28 Nov 2011 11:15:57 +0100 Message-ID: <4ED35FCE.7090408@cs.vu.nl> Date: Mon, 28 Nov 2011 11:17:50 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 10:16:00 -0000 > > Please state your **technical** opinion about which peer protocol > proposal you would prefer on the PPSP mailing list until November > 30th. > Hi I prefer the swift proposal to be the basis for the peer protocol, obviously (if it is bad form to vote for you own proposal, I apologize). The Gu+Cruz proposal, IMHO contains some poor design choices, and is at present incomplete and inmature. The poor design choices are the preference for a pull-based model, e.g. for chunk availability and the preference for HTTP as a transport. As argued in the meeting, a pull-based model for getting the chunk availability of peers does not fit well with contemporary chunk selection policies. These policies commonly use rarest-first as an important element (VOD). Rarest-first is a simple way of ensuring that peers have chunks to upload to each other, so a simple way of ensuring the upload bandwidth of peers is exploited. For rarest-first, up-to-date information about chunk availability is needed, which is most easily achieved by pushing availability updates. I haven't gotten an answer to my questions of how peers' upload capacity is exploited in the Gu+Cruz system (they don't seem to use rarest-first), and how they avoid high latencies (a risk because they pull info). Furthermore, HTTP is not a good basis for a peer-to-peer protocol as it is asymmetric, leading to double TCP connections and NAT firewall complications, as well as a kludgy design. The other proposed encoding, dubbed binary, is inmature, making (inefficient) design choices without explanation and containing technical flaws (defining 8-bit encoding as 7-bit ASCII). The Gu+Cruz proposal is also incomplete. It hints at support for multiplexing of messages and piggybacking to reduce latency. But the specification is incomplete (some support in binary encoding, no in HTTP encoding) and broken (can only multiplex request or replies, not a mix). Regards, Arno From ofira@oversi.com Mon Nov 28 06:04:40 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421A521F8C66 for ; Mon, 28 Nov 2011 06:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7FI1Qxkk3A5 for ; Mon, 28 Nov 2011 06:04:39 -0800 (PST) Received: from mail.oversi.com (mail.oversi.com [209.88.189.2]) by ietfa.amsl.com (Postfix) with ESMTP id 11EEA21F8C5E for ; Mon, 28 Nov 2011 06:04:39 -0800 (PST) Received: from oversinb32 (unknown [10.2.2.209]) by mail.oversi.com (Postfix) with ESMTPA id 362F16B8948 for ; Mon, 28 Nov 2011 16:04:35 +0200 (IST) From: "Ofir Amir" To: Date: Mon, 28 Nov 2011 16:04:35 +0200 Message-ID: <01f501ccadd6$a8d43d70$fa7cb850$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acyt1qgmV550YkogS724e2w8SIpwjw== Content-Language: en-us Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 14:04:40 -0000 Hi, I'm representing Oversi Networks, a vendor of P2P and Video caches for ISPs. Over the last 6 years we have implemented several P2P protocols including Bit-Torrent, some HTTP based, and also swift. We favor Swift as the PPSP peer protocol for the following reasons: 1. Performance: Swift ability to work over UDP, in addition to other transport protocols, make it more efficient in high capacity server, in contrast to HTTP only based protocols (important feature when it comes to implementing P2P Caches as we do). 2. Implementation: although there are quite a lot HTTP implementations, not all of them are fully compliant, specifically when taking into consideration that you need both client & server for low end devices. This can cause quite a lot of interoperability issues later down the road. Swift existing open source implementation is relatively efficient and lightweight, and carry the most important functionality within a small and nimble core. This make it suitable for both high end servers and low end devices. 3. We really like the Merkel-hash with no additional metadata approach Best Regards, Ofir Amir, Chief Architect, Oversi From rui.cruz@ieee-pt.org Mon Nov 28 16:17:49 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA9911E80FB for ; Mon, 28 Nov 2011 16:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.998 X-Spam-Level: X-Spam-Status: No, score=-100.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2z-4BhLAQHl for ; Mon, 28 Nov 2011 16:17:47 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE0111E8097 for ; Mon, 28 Nov 2011 16:17:46 -0800 (PST) Received: by eabm6 with SMTP id m6so2752531eab.31 for ; Mon, 28 Nov 2011 16:17:46 -0800 (PST) Received: by 10.180.85.4 with SMTP id d4mr32531665wiz.19.1322525866099; Mon, 28 Nov 2011 16:17:46 -0800 (PST) Received: from [192.168.1.68] ([89.180.34.53]) by mx.google.com with ESMTPS id m25sm40763870wbp.6.2011.11.28.16.17.43 (version=SSLv3 cipher=OTHER); Mon, 28 Nov 2011 16:17:44 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_BBA07001-62D8-44AD-9657-564E0BAE5CD9" From: Rui Cruz In-Reply-To: Date: Tue, 29 Nov 2011 00:17:42 +0000 Message-Id: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> References: To: ppsp@ietf.org X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 00:17:49 -0000 --Apple-Mail=_BBA07001-62D8-44AD-9657-564E0BAE5CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I am in favor of Swift as a Wire Format and Message Transport candidate = for the PPSP Peer Protocol, although the Media Data Transport may need = further discussions (Data Transport is not in the scope of the signaling = protocol, although the design may determine it). However=85 I would reconsider if the situation is for either one or the other draft = to be voted as preferred in the WG.=20 Opinions have balanced from a "merger, as both have some advantages", = "some features can be included into the other proposal", "take swift as = basis" or "'extensions' can be added, that parse the data (or the = metadata) to get infos needed by download algorithms" because = "information about the distortion, the interdependency between chunks = (to reflect coding dependencies), the temporal vs. spatial = scalability/layering to be conveyed" may be needed for the scheduling = algorithms. Neither of the drafts presented a complete protocol architecture.=20 And so, I would propose the following alternatives (not in andy = preferred order) to the simple white/black voting: Alternative 1: one draft would proceed describing the Protocol = Architecture, Semantics, Syntax and Logic, and the other draft the way = to implement the Wire Format/Encoding layer and Message Transport layer, = suggesting and justifying Network Transport preferences. Alternative 2: "merging the efforts", not the "proposals" on defining = the Protocol Architecture, Semantics and Logic and refining the Wire = Format/encoding and Message Transport layers, in an orchestrated way. = Both teams could perfectly do their best to converge into a complete = specification.=20 The reasons behind this proposal are the following, for which some = responses and comments would enrich the discussion in the Mailing List: 1. Architecture The PPSP Peer Protocol design needs a very clear Architecture in order = to address Semantics, Syntax, Operation Logic and "services" provided, = as the "Peer Agent" interfaces and interacts with a Client Media Player = (in order to stream what the User requests, even if the User is playing = Tricks, like jumping forward in the movie or selecting a different audio = dubbing or subtitle language).=20 =20 The Architecture would describe, at least:=20 - Peer Selection criteria: based of location, capabilities, etc.,=20 - Streaming Modes support: live, on-demand, and how to obtain, ahead of = data, updates for the chunk IDs of the live media sliding window,=20 - Extensibility: in terms of the support/cooperation with diverse media = representations and media structures/encodings, as the "Peer Agent" = should not take decisions on interdependency between media chunks or = representations (coding dependencies) of Structured Media, and that role = should be performed at the Media Player application level. However it = should cooperate for the correct and adequate download scheduling of the = required (externally ordered) media chunks (where chunks correspond to = segments of media, with similar duration, divided at points that support = effective individual decoding, e.g., on packet and key frame = boundaries). - Interactions with: the Client Application (and Media Player) and = support of media Trick-Function requests, the Tracker(s)=20 - Operation Semantics: the "Peer Agent" is NOT the Media Player, = therefore does not take decisions on what to watch (presentation) or at = which media presentation time to start watching, at any moment. 2. Wire Protocol The Wire Protocol goal is to provide the adequate framework (not = concerned with implementation and semantics of operation) for the = invocation of operations on resources, considering: - "service-side" interface: with the Client Application, with the = Tracker processes components (in the Peer). - "transport-side" interface: object types/assets, methods/messages, = requests/replies/results operations, error codes/conditions either = explicit or implicit, integrity, addressing. 3. Message Transport The Message Transport addresses the efficient delivery of messages, = independently of their meaning or purpose: - message segmentation (message boundaries) - multiplexing, pipelining, channeling - flow and congestion control=20 =46rom what is written in the swift description draft, there is no = interaction with the Media Player apart from feeding it with the = downloaded media, meaning that, as soon as the "Peer" knows the root = Hash or Public key (Swarm-ID) immediately starts pulling all the media = to feed the Player, without any interaction. The method is, apparently, = similar to a multi-source "progressive download". One important aspect is that the signaling for bitmaps/hashes of swift = is push-mode, but the Media DATA streaming is always PULL-Mode, for = either Live or on-demand. =20 About the support of Structured Media, I could not see evidence of that, = nor how Swift deals with several representations of the media, i.e., = video (several clips, multiple bitrates, layers), audio (different audio = dubbing languages), text (different subtitle languages), unless all are = multiplexed in a container file, or "contained" in a directory of files, = in order to be hashed in byte ranges.=20 An example of such a structure is the following, for a 10 seconds video = encoded in SVC with two spacial resolutions (432x240 and 842x480) and 6 = layers for quality fidelity, with an associated Audio track. Each = segment (with chunks labelled .00, .01, .02, etc for the different = layers) corresponds to a duration of 2 seconds of media playout, and the = corresponding sizes are also indicated (example taken from a real test = video). For this example, I suppose that swift would have to hash independently = each chunk, am I right? But then, how would it address the scalability, = as the Client Player requester, would eventually not request all the = layers of a segment during those 10 seconds of duration (perhaps, = starting only up to layer L3 on the first segment, then raising to L4, = then L5 in the following segments, or, if bandwidth would allow up to L6 = for the remaining segments). +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER = CHUNKS=20 162 KiB 172 KiB 154 KiB 157 KiB 177 KiB=20 +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER = CHUNKS=20 117 KiB 121 KiB 113 KiB 120 KiB 117 KiB=20 +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER = CHUNKS 4 KiB 6 KiB 6 KiB 6 KiB 4 KiB=20 +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER = CHUNKS 3 KiB 5 KiB 5 KiB 6 KiB 4 KiB=20 +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER = CHUNKS 5 KiB 6 KiB 5 KiB 6 KiB 6 KiB=20 +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER = CHUNKS 54 KiB 55 KiB 49 KiB 53 KiB 58 KiB=20 +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER = CHUNKS 50 KiB 52 KiB 50 KiB 53 KiB 50 KiB =20 +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB 5 KiB 5 KiB 5 KiB =20 --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org=20 rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 24/11/2011, at 14:42, Martin Stiemerling wrote: > Dear all,=20 >=20 > The working group has to make a decision which peer protocol proposal = to choose as basis for the PPSP peer protocol.=20 >=20 > We have to independent proposals: > - draft-gu-ppsp-peer-protocol-03 > (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) > - draft-grishchenko-ppsp-swift-03 > (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) >=20 > Both proposals for a peer protocol have been presented at the IETF = meeting. The slides are available here: > - draft-gu-ppsp-peer-protocol-03: > http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx > - draft-grishchenko-ppsp-swift-03 > http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf >=20 > The feedback given at the IETF meeting about both proposals is = documented in the draft meeting minutes: > http://www.ietf.org/proceedings/82/minutes/ppsp.txt >=20 > Please state your **technical** opinion about which peer protocol = proposal you would prefer on the PPSP mailing list until November 30th. >=20 > With best regards >=20 > Yunfei and Martin > PPSP co-chairs >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014=20 >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_BBA07001-62D8-44AD-9657-564E0BAE5CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Neither of the = drafts presented a complete protocol = architecture. And so, I would propose = the following alternatives (not in andy preferred order) to the = simple white/black voting: Alternative = 1: one draft would proceed describing the Protocol Architecture, = Semantics, Syntax and Logic, and the other draft the way to implement = the Wire Format/Encoding layer and Message Transport layer, suggesting = and justifying Network Transport preferences. Alternative = 2: "merging the efforts", not the "proposals" on defining the = Protocol Architecture, Semantics and Logic and refining the Wire = Format/encoding and Message Transport layers, in an orchestrated way. = Both teams could perfectly do their best to converge into a complete = specification. The reasons behind this = proposal are the following, for which some responses and comments = would enrich the discussion in the Mailing = List: 1. Architecture The PPSP Peer = Protocol design needs a very clear Architecture in order to address = Semantics, Syntax, Operation Logic and "services" provided, as the "Peer = Agent" interfaces and interacts with a Client Media Player (in order to = stream what the User requests, even if the User is playing Tricks, like = jumping forward in the movie or selecting a different audio dubbing or = subtitle language). The Architecture = would describe, at least: - Peer Selection criteria: = based of location, capabilities, etc., - Streaming Modes = support: live, on-demand, and how to obtain, ahead of data, updates for = the chunk IDs of the live media sliding window, - = Extensibility: in terms of the support/cooperation with diverse media = representations and media structures/encodings, as the "Peer Agent" = should not take decisions on interdependency between media chunks or = representations (coding dependencies) of Structured Media, and that role = should be performed at the Media Player application level. However it = should cooperate for the correct and adequate download scheduling of the = required (externally ordered) media chunks (where chunks correspond to = segments of media, with similar duration, divided at points that support = effective individual decoding, e.g., on packet and key frame = boundaries). - Interactions with: the Client Application (and = Media Player) and support of media Trick-Function requests, the = Tracker(s) - Operation Semantics: the "Peer Agent" is = NOT the Media Player, therefore does not take decisions on what to watch = (presentation) or at which media presentation time to start watching, at = any moment. 2. Wire Protocol The Wire = Protocol goal is to provide the adequate framework (not concerned with = implementation and semantics of operation) for the invocation of = operations on resources, considering: - "service-side" = interface: with the Client Application, with the Tracker processes = components (in the Peer). - "transport-side" interface: object = types/assets, methods/messages, requests/replies/results operations, = error codes/conditions either explicit or implicit, integrity, = addressing. 3. Message Transport The = Message Transport addresses the efficient delivery of messages, = independently of their meaning or purpose: - message = segmentation (message boundaries) - multiplexing, pipelining, = channeling - flow and congestion = control =46rom what is written in the = swift description draft, there is no interaction with the Media Player = apart from feeding it with the downloaded media, meaning that, as soon = as the "Peer" knows the root Hash or Public key (Swarm-ID) immediately = starts pulling all the media to feed the Player, without any = interaction. The method is, apparently, similar to a multi-source = "progressive download". One important aspect is that the = signaling for bitmaps/hashes of swift is push-mode, but the Media DATA = streaming is always PULL-Mode, for either Live or on-demand. = About the support of Structured Media, I = could not see evidence of that, nor how Swift deals with several = representations of the media, i.e., video (several clips, multiple = bitrates, layers), audio (different audio dubbing languages), text = (different subtitle languages), unless all are multiplexed in a = container file, or "contained" in a directory of files, in order to be = hashed in byte ranges. An example of such a structure is = the following, for a 10 seconds video encoded in SVC with two spacial = resolutions (432x240 and 842x480) and 6 layers for quality fidelity, = with an associated Audio track. Each segment (with chunks labelled .00, = .01, .02, etc for the different layers) corresponds to a duration of 2 = seconds of media playout, and the corresponding sizes are also indicated = (example taken from a real test video). For = this example, I suppose that swift would have to hash independently each = chunk, am I right? But then, how would it address the scalability, as = the Client Player requester, would eventually not request all the layers = of a segment during those 10 seconds of duration (perhaps, starting only = up to layer L3 on the first segment, then raising to L4, then L5 in the = following segments, or, if bandwidth would allow up to L6 for the = remaining segments). +++L6.00+++ +++L6.01+++ = +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER = CHUNKS 162 KiB 172 KiB 154 KiB = 157 KiB 177 KiB +++L5.00+++ +++L5.01+++ = +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER = CHUNKS 117 KiB 121 KiB 113 KiB = 120 KiB 117 KiB +++L4.00+++ +++L4.01+++ = +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER = CHUNKS 4 KiB 6 KiB 6 = KiB 6 KiB 4 = KiB +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ = +++L3.O4+++ ENH3 LAYER = CHUNKS 3 KiB 5 KiB 5 = KiB 6 KiB 4 = KiB +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ = +++L2.O4+++ ENH2 LAYER = CHUNKS 5 KiB 6 KiB 5 = KiB 6 KiB 6 = KiB +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ = +++L1.O4+++ ENH1 LAYER = CHUNKS 54 KiB 55 KiB = 49 KiB 53 KiB 58 = KiB +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ = +++L0.O4+++ BASE LAYER = CHUNKS 50 KiB 52 KiB = 50 KiB 53 KiB 50 KiB = +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ = +++AA.O4+++ AUDIO Chunks 5 KiB 5 = KiB 5 KiB 5 KiB = 5 KiB ---------------------------Best = Regards, Chairman IEEE Portugal Section Av. Prof. Dr. = An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 = 939 (mobile) rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing = technology for humanity. On 24/11/2011, at 14:42, Martin Stiemerling = wrote: Dear all, The working group has to make a = decision which peer protocol proposal to choose as basis for the PPSP = peer protocol. We have to independent proposals: - = draft-gu-ppsp-peer-protocol-03 (http://= tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - = draft-grishchenko-ppsp-swift-03 (http:/= /tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both = proposals for a peer protocol have been presented at the IETF meeting. = The slides are available here: - draft-gu-ppsp-peer-protocol-03: = http://www.= ietf.org/proceedings/82/slides/ppsp-3.pptx - = draft-grishchenko-ppsp-swift-03 http://www.i= etf.org/proceedings/82/slides/ppsp-1.pdf The feedback given = at the IETF meeting about both proposals is documented in the draft = meeting minutes: http://www.ie= tf.org/proceedings/82/minutes/ppsp.txt Please state your = **technical** opinion about which peer protocol proposal you would = prefer on the PPSP mailing list until November 30th. With best = regards Yunfei and Martin PPSP = co-chairs martin.stiemerling@neclab.eu NEC Laboratories = Europe - Network Research Division NEC Europe Limited | Registered = Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 = _______________________________________________ ppsp = mailing = list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp = --Apple-Mail=_BBA07001-62D8-44AD-9657-564E0BAE5CD9-- From ye.wang@yale.edu Mon Nov 28 22:13:31 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8C021F8B76 for ; Mon, 28 Nov 2011 22:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXjQJ8Jldl6k for ; Mon, 28 Nov 2011 22:13:25 -0800 (PST) Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id 9746321F8B70 for ; Mon, 28 Nov 2011 22:13:24 -0800 (PST) Received: from sandoPC ([173.200.187.210]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id pAT6CoXA003269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Nov 2011 01:13:02 -0500 From: "Ye Wang" To: "'Rui Cruz'" , References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> In-Reply-To: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> Date: Tue, 29 Nov 2011 01:12:47 -0500 Organization: Yale University Computer Science Message-ID: <000901ccae5d$f49dde00$ddd99a00$@yale.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CCAE34.0BCF2900" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHLIDN93j+zAGirDTBhs34PcWQx0AJO+dbWlbP3ytA= Content-Language: en-us X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 06:13:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CCAE34.0BCF2900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rui, =20 I think you are making a very important point. The protocol(s) to be standardized should carefully define what system architecture it fits in, what media types it can handle, what interfaces = it can provide to streaming consumers (such as media player), etc. Specified protocols can be a great solution to some specific system = designs, but the WG may still need a more general standard. =20 For example, we encounter a similar problem as what Rui mentioned, when = we need to supporting dynamical multi-rate streaming (e.g., 240p, 360p, = 480p, 720p HD). We need to customize our protocols to make our system working more efficiently: in particular we decide to map different video chunks (from different sources, with different sizes) to the same id, based on corresponding video frame timestamp. Another example is regarding the debate on the push/pull of the bitmap. When our system works with low-capacity video source (e.g., a single = server) and small chunk size, we build an overlay network with multi-hop = diameter, and it turns out the push scheme performs better as it is an efficient = way for the peers to discover the newest/rarest chunks in the channel, even though it consumes around 10% of the peer upload capacity; but when we = have large-capacity source (e.g., a set of CDN access points) and large chunk size (e.g., to accommodate HTTP overhead when working with CDN), the = pull based scheme actually saves peer uplink resource, since the overlay structure is not =93deep=94, so each peer just need to request neighbors = about their chunk availability =93on demand=94 (as long as their neighbor=92s = capacity is already efficiently utilized) because it can always fetch from source = if it is not happy about the progress. =20 Thanks, Ye =20 From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of = Rui Cruz Sent: Monday, November 28, 2011 7:18 PM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selection of PPSP peer protocol draft =20 Hi, =20 I am in favor of Swift as a Wire Format and Message Transport candidate = for the PPSP Peer Protocol, although the Media Data Transport may need = further discussions (Data Transport is not in the scope of the signaling = protocol, although the design may determine it). =20 However=85 =20 I would reconsider if the situation is for either one or the other draft = to be voted as preferred in the WG.=20 =20 Opinions have balanced from a "merger, as both have some advantages", = "some features can be included into the other proposal", "take swift as basis" = or "'extensions' can be added, that parse the data (or the metadata) to get infos needed by download algorithms" because "information about the distortion, the interdependency between chunks (to reflect coding dependencies), the temporal vs. spatial scalability/layering to be = conveyed" may be needed for the scheduling algorithms. =20 Neither of the drafts presented a complete protocol architecture.=20 =20 And so, I would propose the following alternatives (not in andy = preferred order) to the simple white/black voting: =20 Alternative 1: one draft would proceed describing the Protocol = Architecture, Semantics, Syntax and Logic, and the other draft the way to implement = the Wire Format/Encoding layer and Message Transport layer, suggesting and justifying Network Transport preferences. Alternative 2: "merging the efforts", not the "proposals" on defining = the Protocol Architecture, Semantics and Logic and refining the Wire Format/encoding and Message Transport layers, in an orchestrated way. = Both teams could perfectly do their best to converge into a complete specification.=20 =20 The reasons behind this proposal are the following, for which some = responses and comments would enrich the discussion in the Mailing List: =20 1. Architecture The PPSP Peer Protocol design needs a very clear Architecture in order = to address Semantics, Syntax, Operation Logic and "services" provided, as = the "Peer Agent" interfaces and interacts with a Client Media Player (in = order to stream what the User requests, even if the User is playing Tricks, = like jumping forward in the movie or selecting a different audio dubbing or subtitle language).=20 =20 The Architecture would describe, at least:=20 - Peer Selection criteria: based of location, capabilities, etc.,=20 - Streaming Modes support: live, on-demand, and how to obtain, ahead of data, updates for the chunk IDs of the live media sliding window,=20 - Extensibility: in terms of the support/cooperation with diverse media representations and media structures/encodings, as the "Peer Agent" = should not take decisions on interdependency between media chunks or representations (coding dependencies) of Structured Media, and that role should be performed at the Media Player application level. However it = should cooperate for the correct and adequate download scheduling of the = required (externally ordered) media chunks (where chunks correspond to segments = of media, with similar duration, divided at points that support effective individual decoding, e.g., on packet and key frame boundaries). - Interactions with: the Client Application (and Media Player) and = support of media Trick-Function requests, the Tracker(s)=20 - Operation Semantics: the "Peer Agent" is NOT the Media Player, = therefore does not take decisions on what to watch (presentation) or at which = media presentation time to start watching, at any moment. =20 2. Wire Protocol The Wire Protocol goal is to provide the adequate framework (not = concerned with implementation and semantics of operation) for the invocation of operations on resources, considering: - "service-side" interface: with the Client Application, with the = Tracker processes components (in the Peer). - "transport-side" interface: object types/assets, methods/messages, requests/replies/results operations, error codes/conditions either = explicit or implicit, integrity, addressing. =20 3. Message Transport The Message Transport addresses the efficient delivery of messages, independently of their meaning or purpose: - message segmentation (message boundaries) - multiplexing, pipelining, channeling - flow and congestion control=20 =20 >From what is written in the swift description draft, there is no = interaction with the Media Player apart from feeding it with the downloaded media, meaning that, as soon as the "Peer" knows the root Hash or Public key (Swarm-ID) immediately starts pulling all the media to feed the Player, without any interaction. The method is, apparently, similar to a multi-source "progressive download". One important aspect is that the signaling for bitmaps/hashes of swift = is push-mode, but the Media DATA streaming is always PULL-Mode, for either = Live or on-demand. =20 =20 About the support of Structured Media, I could not see evidence of that, = nor how Swift deals with several representations of the media, i.e., video (several clips, multiple bitrates, layers), audio (different audio = dubbing languages), text (different subtitle languages), unless all are = multiplexed in a container file, or "contained" in a directory of files, in order to = be hashed in byte ranges.=20 An example of such a structure is the following, for a 10 seconds video encoded in SVC with two spacial resolutions (432x240 and 842x480) and 6 layers for quality fidelity, with an associated Audio track. Each = segment (with chunks labelled .00, .01, .02, etc for the different layers) corresponds to a duration of 2 seconds of media playout, and the corresponding sizes are also indicated (example taken from a real test video). =20 For this example, I suppose that swift would have to hash independently = each chunk, am I right? But then, how would it address the scalability, as = the Client Player requester, would eventually not request all the layers of = a segment during those 10 seconds of duration (perhaps, starting only up = to layer L3 on the first segment, then raising to L4, then L5 in the = following segments, or, if bandwidth would allow up to L6 for the remaining = segments). =20 +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER CHUNKS=20 162 KiB 172 KiB 154 KiB 157 KiB 177 KiB=20 =20 +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER CHUNKS=20 117 KiB 121 KiB 113 KiB 120 KiB 117 KiB=20 =20 +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER CHUNKS 4 KiB 6 KiB 6 KiB 6 KiB 4 KiB=20 =20 +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER CHUNKS 3 KiB 5 KiB 5 KiB 6 KiB 4 KiB=20 =20 +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER CHUNKS 5 KiB 6 KiB 5 KiB 6 KiB 6 KiB=20 =20 +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER CHUNKS 54 KiB 55 KiB 49 KiB 53 KiB 58 KiB=20 =20 +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER CHUNKS 50 KiB 52 KiB 50 KiB 53 KiB 50 KiB =20 =20 +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB 5 KiB 5 KiB 5 KiB =20 =20 --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org =20 rui.s.cruz@ist.utl.pt =20 sec.portugal@ieee.org =20 www.ieee-pt.org =20 Advancing technology for humanity. =20 On 24/11/2011, at 14:42, Martin Stiemerling wrote: Dear all,=20 The working group has to make a decision which peer protocol proposal to choose as basis for the PPSP peer protocol.=20 We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF = meeting. The slides are available here: - draft-gu-ppsp-peer-protocol-03: http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is = documented in the draft meeting minutes: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol = proposal you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014=20 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp =20 ------=_NextPart_000_000A_01CCAE34.0BCF2900 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rui, I think you are making a very important = point. The protocol(s) to be standardized should carefully define what = system architecture it fits in, what media types it can handle, what = interfaces it can provide to streaming consumers (such as media player), = etc. Specified protocols can be a great solution to some specific system = designs, but the WG may still need a more general = standard. For example, we encounter a similar problem as what Rui mentioned, = when we need to supporting dynamical multi-rate streaming (e.g., 240p, = 360p, 480p, 720p HD). =A0We need to customize our protocols to make our = system working more efficiently: in particular we decide to map = different video chunks (from different sources, with different sizes) to = the same id, based on corresponding video frame = timestamp. Another example is regarding the debate on the push/pull of the = bitmap. =A0When our system works with low-capacity video source (e.g., a = single server) and small chunk size, we build an overlay network with = multi-hop diameter, and it turns out the push scheme performs better as = it is an efficient way for the peers to discover the newest/rarest = chunks in the channel, even though it consumes around 10% of the peer = upload capacity; but when we have large-capacity source (e.g., a set of = CDN access points) and large chunk size (e.g., to accommodate HTTP = overhead when working with CDN), the pull based scheme actually saves = peer uplink resource, since the overlay structure is not = “deep”, so each peer just need to request neighbors about = their chunk availability “on demand” (as long as their = neighbor’s capacity is already efficiently utilized) because it = can always fetch from source if it is not happy about the = progress. Thanks, Ye From:= = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of = Rui Cruz Sent: Monday, November 28, 2011 7:18 = PM To: ppsp@ietf.org Cc: Rui Cruz Subject: = Re: [ppsp] Selection of PPSP peer protocol = draft Hi, I am in favor of Swift as a Wire Format and Message = Transport candidate for the PPSP Peer Protocol, although the Media = Data Transport may need further discussions (Data Transport is not in = the scope of the signaling protocol, although the design may determine = it). However… I = would reconsider if the situation is for either one or the other draft = to be voted as preferred in the WG. Opinions have balanced from a "merger, as both = have some advantages", "some features can be included into the = other proposal", "take swift as basis" or = "'extensions' can be added, that parse the data (or the metadata) = to get infos needed by download algorithms" because = "information about the distortion, the interdependency between = chunks (to reflect coding dependencies), the temporal vs. spatial = scalability/layering to be conveyed" may be needed for the = scheduling algorithms. Neither of the drafts presented a complete protocol = architecture. And so, I would propose the following = alternatives (not in andy preferred order) to the simple white/black = voting: Alternative 1: one draft would proceed = describing the Protocol Architecture, Semantics, Syntax and Logic, and = the other draft the way to implement the Wire Format/Encoding layer and = Message Transport layer, suggesting and justifying Network Transport = preferences. Alternative 2: "merging the = efforts", not the "proposals" on defining the Protocol = Architecture, Semantics and Logic and refining the Wire Format/encoding = and Message Transport layers, in an orchestrated way. Both teams could = perfectly do their best to converge into a complete = specification. The reasons behind this proposal are the = following, for which some responses and comments would enrich the = discussion in the Mailing List: 1. Architecture The PPSP Peer Protocol design needs a very clear = Architecture in order to address Semantics, Syntax, Operation Logic and = "services" provided, as the "Peer Agent" interfaces = and interacts with a Client Media Player (in order to stream what the = User requests, even if the User is playing Tricks, like jumping forward = in the movie or selecting a different audio dubbing or subtitle = language). The Architecture would describe, at = least: - Peer = Selection criteria: based of location, capabilities, = etc., - Streaming = Modes support: live, on-demand, and how to obtain, ahead of data, = updates for the chunk IDs of the live media sliding = window, - = Extensibility: in terms of the support/cooperation with diverse media = representations and media structures/encodings, as the "Peer = Agent" should not take decisions on interdependency between media = chunks or representations (coding dependencies) of Structured Media, and = that role should be performed at the Media Player application level. = However it should cooperate for the correct and adequate download = scheduling of the required (externally ordered) media chunks (where = chunks correspond to segments of media, with similar duration, divided = at points that support effective individual decoding, e.g., on packet = and key frame boundaries). - Interactions with: the Client Application (and Media = Player) and support of media Trick-Function requests, the = Tracker(s) - = Operation Semantics: the "Peer Agent" is NOT the Media Player, = therefore does not take decisions on what to watch (presentation) or at = which media presentation time to start watching, at any = moment. 2. Wire Protocol The Wire Protocol goal is to provide the adequate = framework (not concerned with implementation and semantics of operation) = for the invocation of operations on resources, = considering: - = "service-side" interface: with the Client Application, with = the Tracker processes components (in the = Peer). - = "transport-side" interface: object types/assets, = methods/messages, requests/replies/results operations, error = codes/conditions either explicit or implicit, integrity, = addressing. 3. Message Transport The Message Transport addresses the efficient delivery = of messages, independently of their meaning or = purpose: - message = segmentation (message boundaries) - multiplexing, pipelining, = channeling - flow and = congestion control From what is written in the swift description draft, = there is no interaction with the Media Player apart from feeding it with = the downloaded media, meaning that, as soon as the "Peer" = knows the root Hash or Public key (Swarm-ID) immediately starts pulling = all the media to feed the Player, without any interaction. The method = is, apparently, similar to a multi-source "progressive = download". One = important aspect is that the signaling for bitmaps/hashes of swift is = push-mode, but the Media DATA streaming is always PULL-Mode, for either = Live or on-demand. About the support of Structured Media, I could not see = evidence of that, nor how Swift deals with several representations of = the media, i.e., video (several clips, multiple bitrates, layers), audio = (different audio dubbing languages), text (different subtitle = languages), unless all are multiplexed in a container file, or = "contained" in a directory of files, in order to be hashed in = byte ranges. An = example of such a structure is the following, for a 10 seconds video = encoded in SVC with two spacial resolutions (432x240 and 842x480) and 6 = layers for quality fidelity, with an associated Audio track. Each = segment (with chunks labelled .00, .01, .02, etc for the different = layers) corresponds to a duration of 2 seconds of media playout, and the = corresponding sizes are also indicated (example taken from a real test = video). For this example, I suppose that swift would have to = hash independently each chunk, am I right? But then, how would it = address the scalability, as the Client Player requester, would = eventually not request all the layers of a segment during those 10 = seconds of duration (perhaps, starting only up to layer L3 on the first = segment, then raising to L4, then L5 in the following segments, or, if = bandwidth would allow up to L6 for the remaining = segments). +++L6.00+++ = +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER = CHUNKS 162 KiB = 172 KiB 154 KiB 157 KiB = 177 KiB +++L5.00+++ = +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER = CHUNKS 117 KiB = 121 KiB 113 KiB 120 KiB = 117 KiB +++L4.00+++ = +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER = CHUNKS 4 KiB 6 KiB = 6 KiB 6 KiB 4 = KiB +++L3.00+++ = +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER = CHUNKS 3 KiB 5 KiB = 5 KiB 6 KiB 4 = KiB +++L2.00+++ = +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER = CHUNKS 5 KiB 6 KiB = 5 KiB 6 KiB 6 = KiB +++L1.00+++ = +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER = CHUNKS 54 KiB 55 KiB = 49 KiB 53 KiB 58 = KiB +++L0.00+++ = +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER = CHUNKS 50 KiB 52 KiB = 50 KiB 53 KiB 50 = KiB +++AA.00+++ = +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO = Chunks 5 KiB 5 KiB = 5 KiB 5 KiB = 5 KiB --------------------------- Best = Regards, Prof. Rui Santos = Cruz Chairman IEEE Portugal = Section Av. Prof. = Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 = 939 (mobile) rui.cruz@ieee.org = rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for = humanity. On = 24/11/2011, at 14:42, Martin Stiemerling wrote: Dear = all, The working group has to make a decision which peer = protocol proposal to choose as basis for the PPSP peer protocol. = We have to independent proposals: - = draft-gu-ppsp-peer-protocol-03 (http:/= /tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - = draft-grishchenko-ppsp-swift-03 (http:= //tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both = proposals for a peer protocol have been presented at the IETF meeting. = The slides are available here: - = draft-gu-ppsp-peer-protocol-03: http://www= .ietf.org/proceedings/82/slides/ppsp-3.pptx - = draft-grishchenko-ppsp-swift-03 http://www.= ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given = at the IETF meeting about both proposals is documented in the draft = meeting minutes: http://www.i= etf.org/proceedings/82/minutes/ppsp.txt Please state your = **technical** opinion about which peer protocol proposal you would = prefer on the PPSP mailing list until November 30th. With best = regards Yunfei and Martin PPSP = co-chairs martin.stiemerling@neclab.eu= NEC Laboratories Europe - Network Research Division NEC = Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 = _______________________________________________ ppsp = mailing list ppsp@ietf.org https://www.ietf.org/= mailman/listinfo/ppsp ------=_NextPart_000_000A_01CCAE34.0BCF2900-- From yry@cs.yale.edu Mon Nov 28 23:13:28 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA28221F8B02 for ; Mon, 28 Nov 2011 23:13:28 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yndZIfSI3-Yw for ; Mon, 28 Nov 2011 23:13:27 -0800 (PST) Received: from vm-emlprdomr-03.its.yale.edu (vm-emlprdomr-03.its.yale.edu [130.132.50.144]) by ietfa.amsl.com (Postfix) with ESMTP id AF50F21F8B00 for ; Mon, 28 Nov 2011 23:13:27 -0800 (PST) Received: from Faculty-Supports-MacBook-Pro.local ([128.36.168.192]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id pAT7DN7H014456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Nov 2011 02:13:23 -0500 Message-ID: <4ED48613.6070408@cs.yale.edu> Date: Tue, 29 Nov 2011 02:13:23 -0500 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ppsp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 Cc: LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 07:13:28 -0000 Hi all, I read both specs, and the meeting minutes but missed this IETF at Taipei. So if I am repeating some discussions already happened, please let me know. First off, I got the feeling that multiple votes for swift over draft-gu-ppsp-peer were based on maturity, at this moment. I think this is not a good idea, as maturity can change in a relatively short time period, say between two IETFs, through some intensive engineering efforts, and we are designing a protocol that will last a much longer period. Hence it is important to consider the key technical design. I would personally prefer an HTTP based protocol, if we can show that it works, as HTTP is really the thin waist of the Internet now. It will be great if the authors of draft-gu-ppsp-peer would like to make their protocol complete, addressing the key concerns, for example, bi-directional HTTP communications, say using websocket, so that we can make a more informed decision. People mostly watch video using browsers. We should consider more browser-native protocols, if possible, for ppsp design. Since the swift protocol is more completely specified at this moment, let me comment more on this protocol. The swift protocol is a quite interesting protocol. I feel that using UDP as transport is one potential path, as Adobe P2P is based on UDP as well. My main comments on swift are the following: * Are there any experimental results of swift at large scale real experiments? * According to our experiences at building an experimental p2p streaming system at Yale, a real protocol quickly becomes complex as we continue to extend it to handle challenges in real settings. The extension scheme of the protocol needs careful thinking. * So far the draft contains many policies. I have not been convinced that they are necessary. For example, - page 4 top: "... peer connects to a random set of other peers ..." why random? - page 4 "... omits HAVE messages as a way of choking A." Also Page 7 on withholding HAVE. Also on Page 7 on withholding error messages. I typically do not like such information-hiding designs. Informed decisions often are better, faster decisions. - page 4 (also page 9) "... A sends a datagram containing HAVE messages for the chunks it just received to all its peers." Specifying such a push-just-received model may not be necessary. - The design is essentially pushing for an uploader centric design. This is unnecessary. - The idea of using a tree to introduce bins and compute hashes is interesting. Two comments: - I am wondering is the scheme is patented. CK Wong and Simon Lam presented such a design in 1998 (for disclosure, Simon Lam is my PhD advisor): http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf I am not sure if there is a patent on it. And if so, will it have impacts on the selection? - On the other hand, I am wondering if using such a binary tree based design is necessary, as elaborated schemes typically can have limit extensibility, compared with simple straightforward schemes . In particular, how much savings are we talking about, at the cost of choosing a particular binary tree based representation scheme? Such information can be helpful. To summarize, my vote is the following: - Give the draft-ppsp-gu-peer authors some time (chance) to give a more mature design, if the authors are willing, before we make a decision. - If swift is used, check the patent issue; optional, show some real experimental performance results; think about modular design (for example, more elaborate NAT/mobility handling handshake); make the protocol more policy neutral (e.g., by involving algorithmic designers to leave enough design space); make sure it is extensible in the message flows. Just some quick comments as input. Thanks! Richard On 11/24/11 9:42 AM, Martin Stiemerling wrote: > Dear all, > > The working group has to make a decision which peer protocol proposal to choose as basis for the PPSP peer protocol. > > We have to independent proposals: > - draft-gu-ppsp-peer-protocol-03 > (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) > - draft-grishchenko-ppsp-swift-03 > (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) > > Both proposals for a peer protocol have been presented at the IETF meeting. The slides are available here: > - draft-gu-ppsp-peer-protocol-03: > http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx > - draft-grishchenko-ppsp-swift-03 > http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf > > The feedback given at the IETF meeting about both proposals is documented in the draft meeting minutes: > http://www.ietf.org/proceedings/82/minutes/ppsp.txt > > Please state your **technical** opinion about which peer protocol proposal you would prefer on the PPSP mailing list until November 30th. > > With best regards > > Yunfei and Martin > PPSP co-chairs > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From njaal.borch@gmail.com Tue Nov 29 02:56:59 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428CB21F8BC5 for ; Tue, 29 Nov 2011 02:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 682qSmAv30hX for ; Tue, 29 Nov 2011 02:56:58 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 424CE21F8BB7 for ; Tue, 29 Nov 2011 02:56:58 -0800 (PST) Received: by ggnp4 with SMTP id p4so7708251ggn.31 for ; Tue, 29 Nov 2011 02:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=4VOcX/HjzOC+IOn1ZzgnI/cSdlP3uS7BSGfSpU+AmKU=; b=bzqBEdHXMkYrsMWHqrID/uPHzOk1WHMGylxBqL65SSgML0pkrM//oQM0DLlPp0lgRd V+QKVnKLv6YeoU3eRFfU0QL/cZDTTljO0QF5Z0ZROrNIL5NH9qQmJ/9aLfataBHpueWT h8CdpUr4MZd1fpVSwSk7yK/Pe6X+9/minbVLQ= MIME-Version: 1.0 Received: by 10.182.11.104 with SMTP id p8mr1680885obb.24.1322564217794; Tue, 29 Nov 2011 02:56:57 -0800 (PST) Sender: njaal.borch@gmail.com Received: by 10.182.37.6 with HTTP; Tue, 29 Nov 2011 02:56:55 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Nov 2011 11:56:55 +0100 X-Google-Sender-Auth: fybDu7Xa3c-a3TAs0aUPlgWlq94 Message-ID: From: Njaal Borch To: Martin Stiemerling Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 10:56:59 -0000 Hi, I work at the Northern Research Institute, where I have been working on design and development of P2P systems for a number of years. I have a PhD within P2P networks, designing and creating a fully decentralized social P2P network (the "Socialized.net", 2003-2007). I have later worked with a variety of protocols, including modifications to BitTorrent and some recent work on swift. My vote goes to the swift proposal. I find the design promising, as it is relatively concrete, rather easily implemented and covers the current fundamental issues of P2P networks (e.g. NAT traversal, efficient two-way communication, data integrity etc). It is also open for extensions and optimization as network characteristics and usage patterns evolve. As examples, the hash tree can allow requests/hash checks on larger chunks for larger connections, flow control can be adapted for the client's need and swift opens for a large variety in incentives. Incentives are very important in P2P networks, and while swift doesn't in itself address this directly, it is a design very open for addressing this through resource investments and so forth. The swift proposal is not only more mature, it is a proposal which is based on several years of experimental research carried out by lead researchers within P2P, in particular within P2P video streaming. It provides a rather elegant solution to actual real-world issues currently hindering P2P efficiency (specially NAT and asymmetric network connections). The simplicity of the protocol allows for a great deal of improvements on policies, which do not affect the wire protocol itself. This can again open for a protocol which can be adapted to the specific task at hand by the clients. I see it as a great benefit that the protocol does not try to be too generic or too adaptable at the lower level, as it makes implementations more difficult and makes it difficult for programmers and users to know what to expect from the system. It also opens for a time consuming de-facto standardization of what is actually usable and supported by different implementations. In my opinion, swift carries a lot of potential as a protocol for the next decade. It is rather easy to implement, it is flexible and it has already been shown to run on anything from large PCs to smart phones and low-power systems. Just looking at the discussions on the ppsp mailinglist, those based on the swift proposal are already interesting discussions about piece picking and other advanced technical challenges, while the other proposal(s) have seen basic discussions on how many connections too much is needed between each node pair (as one is the optimal), lacking basic functionality and so fort. Our time is best spent solving actual problems, of which there are plenty, not by creating new ones. Best regards, Dr. Nj=C3=A5l Borch Northern Research Institute (Norut) Troms=C3=B8, Norway On 24 November 2011 15:42, Martin Stiemerling wrote: > Dear all, > > The working group has to make a decision which peer protocol proposal to = choose as basis for the PPSP peer protocol. > > We have to independent proposals: > - draft-gu-ppsp-peer-protocol-03 > =C2=A0(http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) > - draft-grishchenko-ppsp-swift-03 > =C2=A0(http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) > > Both proposals for a peer protocol have been presented at the IETF meetin= g. The slides are available here: > - draft-gu-ppsp-peer-protocol-03: > =C2=A0http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx > - draft-grishchenko-ppsp-swift-03 > =C2=A0http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf > > The feedback given at the IETF meeting about both proposals is documented= in the draft meeting minutes: > http://www.ietf.org/proceedings/82/minutes/ppsp.txt > > Please state your **technical** opinion about which peer protocol proposa= l you would prefer on the PPSP mailing list until November 30th. > > With best regards > > =C2=A0Yunfei and Martin > =C2=A0 =C2=A0 PPSP co-chairs > > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division NEC Europe Limited | = Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered i= n England 2832014 > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > From rui.cruz@ieee-pt.org Tue Nov 29 04:28:20 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54C321F8678 for ; Tue, 29 Nov 2011 04:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NdZEsEPCbcd for ; Tue, 29 Nov 2011 04:28:18 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E673321F861E for ; Tue, 29 Nov 2011 04:28:17 -0800 (PST) Received: by faap14 with SMTP id p14so789625faa.31 for ; Tue, 29 Nov 2011 04:28:17 -0800 (PST) Received: by 10.180.84.33 with SMTP id v1mr49280715wiy.4.1322569695230; Tue, 29 Nov 2011 04:28:15 -0800 (PST) Received: from [172.20.46.66] (gw-ext.tagus.ist.utl.pt. [193.136.166.125]) by mx.google.com with ESMTPS id g29sm10468894wbp.2.2011.11.29.04.28.12 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 04:28:13 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_1AD8045A-E718-4B2F-8414-12D5A6561167" From: Rui Cruz In-Reply-To: <000901ccae5d$f49dde00$ddd99a00$@yale.edu> Date: Tue, 29 Nov 2011 12:28:11 +0000 Message-Id: <988EB900-9BC8-43A3-A892-E5AF1EE24EC7@ieee.org> References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> <000901ccae5d$f49dde00$ddd99a00$@yale.edu> To: Ye Wang X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 12:28:20 -0000 --Apple-Mail=_1AD8045A-E718-4B2F-8414-12D5A6561167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ye, I fully agree with you. And if the key technical design of the protocol architecture benefits = from accumulated experience (from implementations) while not restricting = the capabilities or extensibility, then a standard that will last for a = longer period can be achieved. Our group (EU Project SARACEN) is developing, and already has working = prototypes (including handheld devices, currently over Android OS), of = P2P Streaming distribution that supports adaptive dynamic streaming of = Structured Media (SVC views, MVC/3D views) as well as multi-rate media = representation switching, aimed to be compatible with CDNs and capable = of on-demand or Live streaming modes, with interactive functionality = (with the streaming consumer, e.g., media player) and Trick-Modes. The = current restrictions (not in the P2P distribution process) are related = with real-time encoding of Structured Media for Live streaming (namely = SVC and MVC/3D). But having a pre-encoded media, it can be prepared in = real-time for a Live streaming distribution. The structure of the = encoded media is identical for live or on-demand modes, and only the = method of distribution differs from a full content description mapping = (for on-demand) to a latest generated programme sliding-window = description mapping (for live, with the sliding window describing the = latest N chunks, e.g., a 10 seconds window if N=3D5 and chunk duration = is 2 seconds).=20 And your point on bitmaps push/pull is precisely one of the issues we = are also facing in terms of optimization as it may depend on the = streaming mode and on the distribution network topology (source = assisted, cached, or not, etc.) and the end node access link asymmetry. = A gossip type push of bitmaps with a high frequency although = representing a significant upload bandwidth slice may turn the scheme = more efficient in low-capacity systems, but in case of large chunk sizes = (a few seconds of media duration) an on-demand pull of chunkmaps, with a = relatively low update frequency (not far from the chunk duration) = typically does not represent a significant bandwidth consumption. Thanks, Rui ----------------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Vice-Chair IEEE Computer Society Portugal Chapter rui.cruz@ieee.org=20 rui.cruz@computer.org=20 On 29/11/2011, at 06:12, Ye Wang wrote: > Hi Rui, > =20 > I think you are making a very important point. > The protocol(s) to be standardized should carefully define what system = architecture it fits in, what media types it can handle, what interfaces = it can provide to streaming consumers (such as media player), etc. > Specified protocols can be a great solution to some specific system = designs, but the WG may still need a more general standard. > =20 > For example, we encounter a similar problem as what Rui mentioned, = when we need to supporting dynamical multi-rate streaming (e.g., 240p, = 360p, 480p, 720p HD). We need to customize our protocols to make our = system working more efficiently: in particular we decide to map = different video chunks (from different sources, with different sizes) to = the same id, based on corresponding video frame timestamp. > Another example is regarding the debate on the push/pull of the = bitmap. When our system works with low-capacity video source (e.g., a = single server) and small chunk size, we build an overlay network with = multi-hop diameter, and it turns out the push scheme performs better as = it is an efficient way for the peers to discover the newest/rarest = chunks in the channel, even though it consumes around 10% of the peer = upload capacity; but when we have large-capacity source (e.g., a set of = CDN access points) and large chunk size (e.g., to accommodate HTTP = overhead when working with CDN), the pull based scheme actually saves = peer uplink resource, since the overlay structure is not =93deep=94, so = each peer just need to request neighbors about their chunk availability = =93on demand=94 (as long as their neighbor=92s capacity is already = efficiently utilized) because it can always fetch from source if it is = not happy about the progress. > =20 > Thanks, > Ye > =20 > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf = Of Rui Cruz > Sent: Monday, November 28, 2011 7:18 PM > To: ppsp@ietf.org > Cc: Rui Cruz > Subject: Re: [ppsp] Selection of PPSP peer protocol draft > =20 > Hi, > =20 > I am in favor of Swift as a Wire Format and Message Transport = candidate for the PPSP Peer Protocol, although the Media Data Transport = may need further discussions (Data Transport is not in the scope of the = signaling protocol, although the design may determine it). > =20 > However=85 > =20 > I would reconsider if the situation is for either one or the other = draft to be voted as preferred in the WG.=20 > =20 > Opinions have balanced from a "merger, as both have some advantages", = "some features can be included into the other proposal", "take swift as = basis" or "'extensions' can be added, that parse the data (or the = metadata) to get infos needed by download algorithms" because = "information about the distortion, the interdependency between chunks = (to reflect coding dependencies), the temporal vs. spatial = scalability/layering to be conveyed" may be needed for the scheduling = algorithms. > =20 > Neither of the drafts presented a complete protocol architecture.=20 > =20 > And so, I would propose the following alternatives (not in andy = preferred order) to the simple white/black voting: > =20 > Alternative 1: one draft would proceed describing the Protocol = Architecture, Semantics, Syntax and Logic, and the other draft the way = to implement the Wire Format/Encoding layer and Message Transport layer, = suggesting and justifying Network Transport preferences. > Alternative 2: "merging the efforts", not the "proposals" on defining = the Protocol Architecture, Semantics and Logic and refining the Wire = Format/encoding and Message Transport layers, in an orchestrated way. = Both teams could perfectly do their best to converge into a complete = specification.=20 > =20 > The reasons behind this proposal are the following, for which some = responses and comments would enrich the discussion in the Mailing List: > =20 > 1. Architecture > The PPSP Peer Protocol design needs a very clear Architecture in order = to address Semantics, Syntax, Operation Logic and "services" provided, = as the "Peer Agent" interfaces and interacts with a Client Media Player = (in order to stream what the User requests, even if the User is playing = Tricks, like jumping forward in the movie or selecting a different audio = dubbing or subtitle language).=20 > =20 > The Architecture would describe, at least:=20 > - Peer Selection criteria: based of location, capabilities, etc.,=20 > - Streaming Modes support: live, on-demand, and how to obtain, ahead = of data, updates for the chunk IDs of the live media sliding window,=20 > - Extensibility: in terms of the support/cooperation with diverse = media representations and media structures/encodings, as the "Peer = Agent" should not take decisions on interdependency between media chunks = or representations (coding dependencies) of Structured Media, and that = role should be performed at the Media Player application level. However = it should cooperate for the correct and adequate download scheduling of = the required (externally ordered) media chunks (where chunks correspond = to segments of media, with similar duration, divided at points that = support effective individual decoding, e.g., on packet and key frame = boundaries). > - Interactions with: the Client Application (and Media Player) and = support of media Trick-Function requests, the Tracker(s)=20 > - Operation Semantics: the "Peer Agent" is NOT the Media Player, = therefore does not take decisions on what to watch (presentation) or at = which media presentation time to start watching, at any moment. > =20 > 2. Wire Protocol > The Wire Protocol goal is to provide the adequate framework (not = concerned with implementation and semantics of operation) for the = invocation of operations on resources, considering: > - "service-side" interface: with the Client Application, with the = Tracker processes components (in the Peer). > - "transport-side" interface: object types/assets, methods/messages, = requests/replies/results operations, error codes/conditions either = explicit or implicit, integrity, addressing. > =20 > 3. Message Transport > The Message Transport addresses the efficient delivery of messages, = independently of their meaning or purpose: > - message segmentation (message boundaries) > - multiplexing, pipelining, channeling > - flow and congestion control=20 > =20 > =46rom what is written in the swift description draft, there is no = interaction with the Media Player apart from feeding it with the = downloaded media, meaning that, as soon as the "Peer" knows the root = Hash or Public key (Swarm-ID) immediately starts pulling all the media = to feed the Player, without any interaction. The method is, apparently, = similar to a multi-source "progressive download". > One important aspect is that the signaling for bitmaps/hashes of swift = is push-mode, but the Media DATA streaming is always PULL-Mode, for = either Live or on-demand. =20 > =20 > About the support of Structured Media, I could not see evidence of = that, nor how Swift deals with several representations of the media, = i.e., video (several clips, multiple bitrates, layers), audio (different = audio dubbing languages), text (different subtitle languages), unless = all are multiplexed in a container file, or "contained" in a directory = of files, in order to be hashed in byte ranges.=20 > An example of such a structure is the following, for a 10 seconds = video encoded in SVC with two spacial resolutions (432x240 and 842x480) = and 6 layers for quality fidelity, with an associated Audio track. Each = segment (with chunks labelled .00, .01, .02, etc for the different = layers) corresponds to a duration of 2 seconds of media playout, and the = corresponding sizes are also indicated (example taken from a real test = video). > =20 > For this example, I suppose that swift would have to hash = independently each chunk, am I right? But then, how would it address the = scalability, as the Client Player requester, would eventually not = request all the layers of a segment during those 10 seconds of duration = (perhaps, starting only up to layer L3 on the first segment, then = raising to L4, then L5 in the following segments, or, if bandwidth would = allow up to L6 for the remaining segments). > =20 > +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER = CHUNKS=20 > 162 KiB 172 KiB 154 KiB 157 KiB 177 KiB=20 > =20 > +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER = CHUNKS=20 > 117 KiB 121 KiB 113 KiB 120 KiB 117 KiB=20 > =20 > +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER = CHUNKS > 4 KiB 6 KiB 6 KiB 6 KiB 4 KiB=20 > =20 > +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER = CHUNKS > 3 KiB 5 KiB 5 KiB 6 KiB 4 KiB=20 > =20 > +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER = CHUNKS > 5 KiB 6 KiB 5 KiB 6 KiB 6 KiB=20 > =20 > +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER = CHUNKS > 54 KiB 55 KiB 49 KiB 53 KiB 58 KiB=20 > =20 > +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER = CHUNKS > 50 KiB 52 KiB 50 KiB 53 KiB 50 KiB =20 > =20 > +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO = Chunks > 5 KiB 5 KiB 5 KiB 5 KiB 5 KiB =20 > =20 >=20 > --------------------------- > Best Regards, >=20 > Prof. Rui Santos Cruz > Chairman > IEEE Portugal Section > Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, = 2744-016 Porto Salvo, Portugal > +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) > rui.cruz@ieee.org=20 > rui.s.cruz@ist.utl.pt > sec.portugal@ieee.org > www.ieee-pt.org > Advancing technology for humanity. > =20 > On 24/11/2011, at 14:42, Martin Stiemerling wrote: >=20 >=20 > Dear all,=20 >=20 > The working group has to make a decision which peer protocol proposal = to choose as basis for the PPSP peer protocol.=20 >=20 > We have to independent proposals: > - draft-gu-ppsp-peer-protocol-03 > (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) > - draft-grishchenko-ppsp-swift-03 > (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) >=20 > Both proposals for a peer protocol have been presented at the IETF = meeting. The slides are available here: > - draft-gu-ppsp-peer-protocol-03: > http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx > - draft-grishchenko-ppsp-swift-03 > http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf >=20 > The feedback given at the IETF meeting about both proposals is = documented in the draft meeting minutes: > http://www.ietf.org/proceedings/82/minutes/ppsp.txt >=20 > Please state your **technical** opinion about which peer protocol = proposal you would prefer on the PPSP mailing list until November 30th. >=20 > With best regards >=20 > Yunfei and Martin > PPSP co-chairs >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014=20 >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_1AD8045A-E718-4B2F-8414-12D5A6561167 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Ye, I fully agree with = you. And if the key technical design of the = protocol architecture benefits from accumulated experience (from = implementations) while not restricting the capabilities or = extensibility, then a standard that will last for a longer period can be = achieved. Our group (EU Project SARACEN) is = developing, and already has working prototypes (including handheld = devices, currently over Android OS), of P2P Streaming distribution that = supports adaptive dynamic streaming of Structured Media (SVC views, = MVC/3D views) as well as multi-rate media representation switching, = aimed to be compatible with CDNs and capable of on-demand or Live = streaming modes, with interactive functionality (with the streaming = consumer, e.g., media player) and Trick-Modes. The current restrictions = (not in the P2P distribution process) are related with real-time = encoding of Structured Media for Live streaming (namely SVC and MVC/3D). = But having a pre-encoded media, it can be prepared in real-time for a = Live streaming distribution. The structure of the encoded media is = identical for live or on-demand modes, and only the method of = distribution differs from a full content description mapping (for = on-demand) to a latest generated programme sliding-window description = mapping (for live, with the sliding window describing the latest N = chunks, e.g., a 10 seconds window if N=3D5 and chunk duration is 2 = seconds). And your point on bitmaps = push/pull is precisely one of the issues we are also facing in terms of = optimization as it may depend on the streaming mode and on the = distribution network topology (source assisted, cached, or not, etc.) = and the end node access link asymmetry. A gossip type push of bitmaps = with a high frequency although representing a significant upload = bandwidth slice may turn the scheme more efficient in low-capacity = systems, but in case of large chunk sizes (a few seconds of media = duration) an on-demand pull of chunkmaps, with a relatively low update = frequency (not far from the chunk duration) typically does not represent = a significant bandwidth = consumption. Thanks, Rui -----------------------------------Best Regards, Prof. Rui Santos = Cruz Chapter= rui.cruz@ieee.org <= /span> rui.cruz@computer.org On 29/11/2011, at 06:12, Ye Wang wrote: Hi = Rui, I = think you are making a very important point. The protocol(s) to be = standardized should carefully define what system architecture it fits = in, what media types it can handle, what interfaces it can provide to = streaming consumers (such as media player), = etc. Specified = protocols can be a great solution to some specific system designs, but = the WG may still need a more general = standard. For = example, we encounter a similar problem as what Rui mentioned, when we = need to supporting dynamical multi-rate streaming (e.g., 240p, 360p, = 480p, 720p HD). We need to customize our protocols to make our = system working more efficiently: in particular we decide to map = different video chunks (from different sources, with different sizes) to = the same id, based on corresponding video frame = timestamp. From: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui = Cruz Sent: Monday, November 28, 2011 = 7:18 PM To: ppsp@ietf.org Cc: Rui = Cruz Subject: Re: [ppsp] Selection of = PPSP peer protocol draft I am in favor of Swift = as a Wire Format and Message Transport candidate for the PPSP Peer Protocol, = although the Media Data Transport may need further discussions (Data = Transport is not in the scope of the signaling protocol, although the = design may determine it). However=85 I would reconsider if the situation is for either one = or the other draft to be voted as preferred in the = WG. Opinions have balanced = from a "merger, as both have some advantages", "some features can be = included into the other proposal", "take swift as basis" or = "'extensions' can be added, that parse the data (or the metadata) to get = infos needed by download algorithms" because "information about the = distortion, the interdependency between chunks (to reflect coding = dependencies), the temporal vs. spatial scalability/layering to be = conveyed" may be needed for the scheduling = algorithms. Neither of the drafts = presented a complete protocol = architecture. And so, I would propose the = following alternatives (not in andy preferred = order) to the simple white/black voting: Alternative 1: one draft would proceed = describing the Protocol Architecture, Semantics, Syntax and Logic, and = the other draft the way to implement the Wire Format/Encoding layer and = Message Transport layer, suggesting and justifying Network Transport = preferences. Alternative 2: "merging the = efforts", not the "proposals" on defining the Protocol Architecture, = Semantics and Logic and refining the Wire Format/encoding and Message = Transport layers, in an orchestrated way. Both teams could perfectly do = their best to converge into a complete = specification. The reasons behind this = proposal are the following, for which some responses and comments = would enrich the discussion in the Mailing = List: 1. = Architecture The PPSP Peer Protocol = design needs a very clear Architecture in order to address Semantics, = Syntax, Operation Logic and "services" provided, as the "Peer Agent" = interfaces and interacts with a Client Media Player (in order to stream = what the User requests, even if the User is playing Tricks, like jumping = forward in the movie or selecting a different audio dubbing or subtitle = language). The Architecture would = describe, at least: - Peer Selection criteria: based of location, = capabilities, etc., - Streaming Modes support: live, on-demand, and how to = obtain, ahead of data, updates for the chunk IDs of the live media = sliding window, - = Extensibility: in terms of the support/cooperation with diverse media = representations and media structures/encodings, as the "Peer Agent" = should not take decisions on interdependency between media chunks or = representations (coding dependencies) of Structured Media, and that role = should be performed at the Media Player application level. However it = should cooperate for the correct and adequate download scheduling of the = required (externally ordered) media chunks (where chunks correspond to = segments of media, with similar duration, divided at points that support = effective individual decoding, e.g., on packet and key frame = boundaries). - Interactions with: the = Client Application (and Media Player) and support of media = Trick-Function requests, the = Tracker(s) - Operation = Semantics: the "Peer Agent" is NOT the Media Player, therefore does not = take decisions on what to watch (presentation) or at which media = presentation time to start watching, at any = moment. 2. Wire = Protocol The Wire Protocol goal is = to provide the adequate framework (not concerned with implementation and = semantics of operation) for the invocation of operations on resources, = considering: - "service-side" = interface: with the Client Application, with the Tracker processes = components (in the Peer). - "transport-side" interface: object types/assets, = methods/messages, requests/replies/results operations, error = codes/conditions either explicit or implicit, integrity, = addressing. 3. Message = Transport The Message Transport = addresses the efficient delivery of messages, independently of their = meaning or purpose: - message = segmentation (message boundaries) - multiplexing, pipelining, = channeling - flow and congestion = control =46rom what is written in = the swift description draft, there is no interaction with the Media = Player apart from feeding it with the downloaded media, meaning that, as = soon as the "Peer" knows the root Hash or Public key (Swarm-ID) = immediately starts pulling all the media to feed the Player, without any = interaction. The method is, apparently, similar to a multi-source = "progressive download". One important aspect is that the signaling for = bitmaps/hashes of swift is push-mode, but the Media DATA streaming is = always PULL-Mode, for either Live or on-demand. = About the support of = Structured Media, I could not see evidence of that, nor how Swift deals = with several representations of the media, i.e., video (several clips, = multiple bitrates, layers), audio (different audio dubbing languages), = text (different subtitle languages), unless all are multiplexed in a = container file, or "contained" in a directory of files, in order to be = hashed in byte ranges. An example of such a structure is the following, for a = 10 seconds video encoded in SVC with two spacial resolutions (432x240 = and 842x480) and 6 layers for quality fidelity, with an associated Audio = track. Each segment (with chunks labelled .00, .01, .02, etc for the = different layers) corresponds to a duration of 2 seconds of media = playout, and the corresponding sizes are also indicated (example taken = from a real test video). For this example, I suppose that swift would have to = hash independently each chunk, am I right? But then, how would it = address the scalability, as the Client Player requester, would = eventually not request all the layers of a segment during those 10 = seconds of duration (perhaps, starting only up to layer L3 on the first = segment, then raising to L4, then L5 in the following segments, or, if = bandwidth would allow up to L6 for the remaining = segments). +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ = +++L6.O4+++ ENH6 LAYER = CHUNKS 162 KiB = 172 KiB 154 KiB 157 KiB = 177 KiB +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ = +++L5.O4+++ ENH5 LAYER = CHUNKS 117 KiB = 121 KiB 113 KiB 120 KiB = 117 KiB +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ = +++L4.O4+++ ENH4 LAYER = CHUNKS 4 KiB 6 KiB = 6 KiB 6 KiB 4 = KiB +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ = +++L3.O4+++ ENH3 LAYER = CHUNKS 3 KiB 5 KiB = 5 KiB 6 KiB 4 = KiB +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ = +++L2.O4+++ ENH2 LAYER = CHUNKS 5 KiB 6 KiB = 5 KiB 6 KiB 6 = KiB +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ = +++L1.O4+++ ENH1 LAYER = CHUNKS 54 KiB 55 KiB = 49 KiB 53 KiB = 58 KiB +++L0.00+++ = +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER = CHUNKS 50 KiB 52 KiB = 50 KiB 53 KiB = 50 KiB +++AA.00+++ = +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO = Chunks 5 KiB 5 KiB = 5 KiB 5 KiB = 5 KiB ---------------------------<= /o:p> Best = Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal = Section Av. = Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office = 1-5, 2744-016 Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 = 060 939 (mobile) sec.portugal@ieee.org Advancing technology for = humanity. On 24/11/2011, at 14:42, Martin Stiemerling = wrote: Dear all, The working group = has to make a decision which peer protocol proposal to choose as basis = for the PPSP peer protocol. We have to = independent proposals: - draft-gu-ppsp-peer-protocol-03 ( _________________= ______________________________ ppsp mailing list ppsp@ietf.org In-reply-to: X-Originating-IP: [10.138.41.134] To: 'Martin Stiemerling' Message-id: <00ab01ccae96$97f0cd50$c7d267f0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyuhgM7Dd+q8hGgQD+5Qd/TrETlOwACr7Ug X-CFilter-Loop: Reflected References: Cc: ppsp@ietf.org Subject: [ppsp] =?utf-8?b?562U5aSNOiAgU2VsZWN0aW9uIG9mIFBQU1AgcGVlciBwcm90?= =?utf-8?q?ocol_draft?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 12:56:21 -0000 I would like to recall the history of peer protocol. We began to propose Tracker and Peer protocol at early 2010. Since the very beginning, we believe that Peer protocol should be consistent with Tracker Protocol. By consistence, I don't mean that they can co-exist, instead they should share the similar philosophy and should be able to interoperate. That's why we call them a system, not two single protocols. PPSP had spent a lot of time on discussion on whether the PPSP standards should use Tracker-based or Full-mesh architecture (finally, WG got consensus on tracker-based), and how the Tracker and Peer protocol should work, which is in the Requirements draft. We always regards the requirements draft as a guidance on Tracker and peer protocol. Based on the requirements draft, we proposed draft-gu-ppsp-tracker-protocol and peer-protocol. The WG has spent a lot of effort on PPSP Survey, because we want to extract common features on current PPSP system, instead of base on a single private protocol. I agree that Swift works, and it is a research project supported by many research groups, and I think those show support for swift are mostly involved in SWIFT project. It will be easier for PPSP to get to an RFC published if we defining a protocol based on a mature private protocol. But what about other private protocols? ANY ONE of the protocols introduced in Survey draft can work well and most of them have much huge number of users than SWIFT, and even much better performance. Shall we take them into consideration? I hate to make this selection as an attack on each other draft. And I hope those from SWIFT won't look at my email as an attack to their protocols. I just wonder what does PPSP WG want, a mature private protocol or a developing protocols based on widely survey? I agree with Cruz's opinion. This is not a selection of draft, we have more than one option. Best Regards Gu Yingjie From rui.cruz@ieee-pt.org Tue Nov 29 05:26:26 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B37521F8B92 for ; Tue, 29 Nov 2011 05:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwM-W2DnaNmr for ; Tue, 29 Nov 2011 05:26:24 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2719D21F8B77 for ; Tue, 29 Nov 2011 05:26:24 -0800 (PST) Received: by eabm6 with SMTP id m6so3534943eab.31 for ; Tue, 29 Nov 2011 05:26:23 -0800 (PST) Received: by 10.213.35.16 with SMTP id n16mr1152647ebd.59.1322573183061; Tue, 29 Nov 2011 05:26:23 -0800 (PST) Received: from [172.20.46.66] (gw-ext.tagus.ist.utl.pt. [193.136.166.125]) by mx.google.com with ESMTPS id f36sm105232422eef.4.2011.11.29.05.26.21 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 05:26:21 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_443F62C3-45CE-4CBC-90A7-A6E6A8AA590F" From: Rui Cruz In-Reply-To: <4ED48613.6070408@cs.yale.edu> Date: Tue, 29 Nov 2011 13:26:19 +0000 Message-Id: <77252AAF-8CC9-4831-8DF0-352A2E02352B@ieee.org> References: <4ED48613.6070408@cs.yale.edu> To: Y. Richard Yang X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , ppsp@ietf.org, LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 13:26:26 -0000 --Apple-Mail=_443F62C3-45CE-4CBC-90A7-A6E6A8AA590F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard, It is very interesting your point on a Web-based P2P Streaming protocol.=20= Bi-directional communications via Websocket is in fact the next step in = a design (draft-cruz-ppsp-http-peer-protocol) for the Messaging = Transport layer, together with a Wire Representation of messages, = compatible with HTTP methods, that our group (EU SARACEN project) is = developing. And we already have working prototypes for the P2P Web Streaming = Distribution, supporting Live and on-demand Structured Media Streaming = (SVC, MVC/3D, etc.), using a Client Media Player Application (with = special modules for the requester/re-assember of structured media, and = corresponding decoders), or currently as a Firefox Plug-in, but evolving = for a compatible HTML5 mechanism.=20 As co-author of draft-gu-ppsp-peer-protocol, I would also be very happy = to complete the key technical design of the PPSP Peer Protocol = Architecture, but in a very open approach, not biased for the possible = wire encoding and message transport formats and methods.=20 Swift is in fact interesting, but, in my opinion, should be addressed as = one of the Wire binary formats, currently the more mature.=20 However, I am still not yet convinced that swift can handle (and provide = interaction) with complex Structured Media, for example, allowing the = end User to switch between audio (dubbed languages or "Director = Commented") streams of a movie or switching between subtile languages, = or cooperate in the adaptation or scalability of the media (multi layer, = multi-rate switching). And if the encoded complex structured media is segmented in rather large = sized chunks (of 10x or 100x KiB) each chunk would have to be mapped, I = suppose, to a quite large Hash tree to split the data in byte ranges for = the datagrams. So, instead a a single Bin tree, a complex Structured = Media with a duration of an hour (3600 seconds) would require at least = 18000 Root hashes for chunks with 2 seconds encoded in 10 layers. Would = this not be overkill? But a Web-based Wire format, can be another option, if, as you say, "we = can show that it works".=20 And we (in the SARACEN project) can show that it works.=20 ----------------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Vice-Chair IEEE Computer Society Portugal Chapter rui.cruz@ieee.org=20 rui.cruz@computer.org=20 On 29/11/2011, at 07:13, Y. Richard Yang wrote: > Hi all, >=20 > I read both specs, and the meeting minutes but missed this IETF at = Taipei. So if I am repeating some discussions already happened, please = let me know. >=20 > First off, I got the feeling that multiple votes for swift over = draft-gu-ppsp-peer were based on maturity, at this moment. I think this = is not a good idea, as maturity can change in a relatively short time = period, say between two IETFs, through some intensive engineering = efforts, and we are designing a protocol that will last a much longer = period. Hence it is important to consider the key technical design. I = would personally prefer an HTTP based protocol, if we can show that it = works, as HTTP is really the thin waist of the Internet now. It will be = great if the authors of draft-gu-ppsp-peer would like to make their = protocol complete, addressing the key concerns, for example, = bi-directional HTTP communications, say using websocket, so that we can = make a more informed decision. People mostly watch video using browsers. = We should consider more browser-native protocols, if possible, for ppsp = design. >=20 > Since the swift protocol is more completely specified at this moment, = let me comment more on this protocol. The swift protocol is a quite = interesting protocol. I feel that using UDP as transport is one = potential path, as Adobe P2P is based on UDP as well. My main comments = on swift are the following: >=20 > * Are there any experimental results of swift at large scale real = experiments? >=20 > * According to our experiences at building an experimental p2p = streaming system at Yale, a real protocol quickly becomes complex as we = continue to extend it to handle challenges in real settings. The = extension scheme of the protocol needs careful thinking. >=20 > * So far the draft contains many policies. I have not been convinced = that they are necessary. For example, >=20 > - page 4 top: "... peer connects to a random set of other peers ..." = why random? >=20 > - page 4 "... omits HAVE messages as a way of choking A." >=20 > Also Page 7 on withholding HAVE. Also on Page 7 on withholding = error messages. >=20 > I typically do not like such information-hiding designs. Informed = decisions often are better, faster decisions. >=20 > - page 4 (also page 9) "... A sends a datagram containing HAVE = messages for the chunks it just received to all its peers." Specifying = such a push-just-received model may not be necessary. >=20 > - The design is essentially pushing for an uploader centric design. = This is unnecessary. >=20 > - The idea of using a tree to introduce bins and compute hashes is = interesting. Two comments: >=20 > - I am wondering is the scheme is patented. CK Wong and Simon Lam = presented such a design in 1998 (for disclosure, Simon Lam is my PhD = advisor): = http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf >=20 > I am not sure if there is a patent on it. And if so, will it = have impacts on the selection? >=20 > - On the other hand, I am wondering if using such a binary tree = based design is necessary, as elaborated schemes typically can have = limit extensibility, compared with simple straightforward schemes . In = particular, how much savings are we talking about, at the cost of = choosing a particular binary tree based representation scheme? Such = information can be helpful. >=20 > To summarize, my vote is the following: >=20 > - Give the draft-ppsp-gu-peer authors some time (chance) to give a = more mature design, if the authors are willing, before we make a = decision. >=20 > - If swift is used, check the patent issue; optional, show some real = experimental performance results; think about modular design (for = example, more elaborate NAT/mobility handling handshake); make the = protocol more policy neutral (e.g., by involving algorithmic designers = to leave enough design space); make sure it is extensible in the message = flows. >=20 > Just some quick comments as input. >=20 > Thanks! >=20 > Richard >=20 > On 11/24/11 9:42 AM, Martin Stiemerling wrote: >> Dear all, >>=20 >> The working group has to make a decision which peer protocol proposal = to choose as basis for the PPSP peer protocol. >>=20 >> We have to independent proposals: >> - draft-gu-ppsp-peer-protocol-03 >> (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) >> - draft-grishchenko-ppsp-swift-03 >> (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) >>=20 >> Both proposals for a peer protocol have been presented at the IETF = meeting. The slides are available here: >> - draft-gu-ppsp-peer-protocol-03: >> http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx >> - draft-grishchenko-ppsp-swift-03 >> http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf >>=20 >> The feedback given at the IETF meeting about both proposals is = documented in the draft meeting minutes: >> http://www.ietf.org/proceedings/82/minutes/ppsp.txt >>=20 >> Please state your **technical** opinion about which peer protocol = proposal you would prefer on the PPSP mailing list until November 30th. >>=20 >> With best regards >>=20 >> Yunfei and Martin >> PPSP co-chairs >>=20 >> martin.stiemerling@neclab.eu >>=20 >> NEC Laboratories Europe - Network Research Division NEC Europe = Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014 >>=20 >>=20 >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_443F62C3-45CE-4CBC-90A7-A6E6A8AA590F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Richard, It is very interesting your point on a = Web-based P2P Streaming = protocol. Bi-directional communications = via Websocket is in fact the next step in a design = (draft-cruz-ppsp-http-peer-protocol) for the Messaging Transport layer, = together with a Wire Representation of messages, compatible with HTTP = methods, that our group (EU SARACEN project) is = developing. And we already have working prototypes for the P2P = Web Streaming Distribution, supporting Live and on-demand Structured = Media Streaming (SVC, MVC/3D, etc.), using a Client Media Player = Application (with special modules for the requester/re-assember of = structured media, and corresponding decoders), or currently as a Firefox = Plug-in, but evolving for a compatible HTML5 = mechanism. As co-author of = draft-gu-ppsp-peer-protocol, I would also be very happy to complete the = key technical design of the PPSP Peer Protocol Architecture, but in a = very open approach, not biased for the possible wire encoding and = message transport formats and = methods. Swift is in fact = interesting, but, in my opinion, should be addressed as one of the = Wire binary formats, currently the more = mature. However, I am still not yet = convinced that swift can handle (and provide interaction) with complex = Structured Media, for example, allowing the end User to switch between = audio (dubbed languages or "Director Commented") streams of a movie or = switching between subtile languages, or cooperate in the adaptation or = scalability of the media (multi layer, multi-rate = switching). And if the encoded complex structured media is = segmented in rather large sized chunks (of 10x or 100x KiB) each = chunk would have to be mapped, I suppose, to a quite large Hash tree = to split the data in byte ranges for the datagrams. So, = instead a a single Bin tree, a complex Structured Media with a = duration of an hour (3600 seconds) would require at least 18000 Root = hashes for chunks with 2 seconds encoded in 10 layers. Would this = not be overkill? But a Web-based Wire format, = can be another option, if, as you say, "we can show that it = works". And we (in the SARACEN project) = can show that it works. ----------------------------------- Best Regards, Prof. Rui Santos = Cruz Chapter= rui.cruz@ieee.org <= /span> rui.cruz@computer.org On 29/11/2011, at 07:13, Y. Richard Yang wrote: Hi = all, I read both specs, and the meeting minutes but missed this = IETF at Taipei. So if I am repeating some discussions already happened, = please let me know. First off, I got the feeling that multiple = votes for swift over draft-gu-ppsp-peer were based on maturity, at this = moment. I think this is not a good idea, as maturity can change in = a relatively short time period, say between two IETFs, through some = intensive engineering efforts, and we are designing a protocol that will = last a much longer period. Hence it is important to consider the key = technical design. I would personally prefer an HTTP based protocol, if = we can show that it works, as HTTP is really the thin waist of the = Internet now. It will be great if the authors of draft-gu-ppsp-peer = would like to make their protocol complete, addressing the key concerns, = for example, bi-directional HTTP communications, say using websocket, so = that we can make a more informed decision. People mostly watch video = using browsers. We should consider more browser-native protocols, if = possible, for ppsp design. Since the swift protocol is more = completely specified at this moment, let me comment more on this = protocol. The swift protocol is a quite interesting protocol. I feel = that using UDP as transport is one potential path, as Adobe P2P is = based on UDP as well. My main comments on swift are the = following: * Are there any experimental results of swift at large = scale real experiments? * According to our experiences at = building an experimental p2p streaming system at Yale, a real protocol = quickly becomes complex as we continue to extend it to handle challenges = in real settings. The extension scheme of the protocol needs careful = thinking. * So far the draft contains many policies. I have not = been convinced that they are necessary. For example, = - page 4 top: "... peer connects to a random set of other = peers ..." why random? - page 4 "... omits HAVE = messages as a way of choking A." = Also Page 7 on withholding HAVE. Also on = Page 7 on withholding error messages. = I typically do not like such = information-hiding designs. Informed decisions often are better, faster = decisions. - page 4 (also page 9) "... A sends a = datagram containing HAVE messages for the chunks it just received to all = its peers." Specifying such a push-just-received model may not be = necessary. - The design is essentially pushing for = an uploader centric design. This is unnecessary. - = The idea of using a tree to introduce bins and compute hashes is = interesting. Two comments: - I am = wondering is the scheme is patented. CK Wong and Simon Lam presented = such a design in 1998 (for disclosure, Simon Lam is my PhD advisor): http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf= I am not sure = if there is a patent on it. And if so, will it have impacts on the = selection? - On the other hand, I = am wondering if using such a binary tree based design is necessary, as = elaborated schemes typically can have limit extensibility, compared with = simple straightforward schemes . In particular, how much savings are we = talking about, at the cost of choosing a particular binary tree based = representation scheme? Such information can be helpful. To = summarize, my vote is the following: - Give the = draft-ppsp-gu-peer authors some time (chance) to give a more mature = design, if the authors are willing, before we make a decision. - = If swift is used, check the patent issue; optional, show some real = experimental performance results; think about modular design (for = example, more elaborate NAT/mobility handling handshake); make the = protocol more policy neutral (e.g., by involving algorithmic designers = to leave enough design space); make sure it is extensible in the message = flows. Just some quick comments as = input. Thanks! Richard On 11/24/11 9:42 AM, Martin = Stiemerling wrote: Dear = all, The working = group has to make a decision which peer protocol proposal to choose as = basis for the PPSP peer protocol. We have to = independent proposals: - = draft-gu-ppsp-peer-protocol-03 = (http://= tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - = draft-grishchenko-ppsp-swift-03 = (http:/= /tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) = Both = proposals for a peer protocol have been presented at the IETF meeting. = The slides are available here: -= draft-gu-ppsp-peer-protocol-03: http://www.= ietf.org/proceedings/82/slides/ppsp-3.pptx - = draft-grishchenko-ppsp-swift-03 = http://www.i= etf.org/proceedings/82/slides/ppsp-1.pdf The feedback = given at the IETF meeting about both proposals is documented in the = draft meeting minutes: http://www.ie= tf.org/proceedings/82/minutes/ppsp.txt Please state = your **technical** opinion about which peer protocol proposal you would = prefer on the PPSP mailing list until November = 30th. With best = regards = Yunfei and Martin = PPSP co-chairs martin.stiemerling@neclab.eu<= /a> NEC Laboratories Europe - Network Research Division NEC = Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England 2832014 _______________________________________________ ppsp mailing = list ppsp@ietf.org https://www.ietf.org/m= ailman/listinfo/ppsp _____________________________= __________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/ma= ilman/listinfo/ppsp = --Apple-Mail=_443F62C3-45CE-4CBC-90A7-A6E6A8AA590F-- From yry@cs.yale.edu Tue Nov 29 06:06:25 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3200121F8797 for ; Tue, 29 Nov 2011 06:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.957 X-Spam-Level: *** X-Spam-Status: No, score=3.957 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNaTq-45IMDN for ; Tue, 29 Nov 2011 06:06:24 -0800 (PST) Received: from vm-emlprdomr-03.its.yale.edu (vm-emlprdomr-03.its.yale.edu [130.132.50.144]) by ietfa.amsl.com (Postfix) with ESMTP id 448FE21F85DB for ; Tue, 29 Nov 2011 06:06:24 -0800 (PST) Received: from [10.0.0.3] (adsl-71-139-148-15.dsl.mrdnct.sbcglobal.net [71.139.148.15]) (authenticated bits=0) by vm-emlprdomr-03.its.yale.edu (8.14.4/8.14.4) with ESMTP id pATE60ic008845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Nov 2011 09:06:03 -0500 References: <00ab01ccae96$97f0cd50$c7d267f0$@com> In-Reply-To: <00ab01ccae96$97f0cd50$c7d267f0$@com> Mime-Version: 1.0 (iPad Mail 8J3) Content-Type: text/plain; charset=us-ascii Message-Id: <16E4764B-EADF-4289-BA61-9A417B1DAF70@cs.yale.edu> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8J3) From: "Y. R. Yang" Date: Tue, 29 Nov 2011 09:08:12 -0500 To: "Yingjie Gu(yingjie)" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.144 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?gb2312?b?tPC4tDogIFNlbGVjdGlvbiBvZiBQUFNQIHBlZXIgcHJv?= =?gb2312?b?dG9jb2wgZHJhZnQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 14:06:25 -0000 On Nov 29, 2011, at 7:58 AM, "Yingjie Gu(yingjie)" wr= ote: > I would like to recall the history of peer protocol.=20 > We began to propose Tracker and Peer protocol at early 2010. Since the ver= y beginning, we believe that Peer protocol should be consistent with Tracker= Protocol. By consistence, I don't mean that they can co-exist, instead they= should share the similar philosophy and should be able to interoperate. Th= at's why we call them a system, not two single protocols. >=20 > PPSP had spent a lot of time on discussion on whether the PPSP standards s= hould use Tracker-based or Full-mesh architecture (finally, WG got consensus= on tracker-based), and how the Tracker and Peer protocol should work, which= is in the Requirements draft. We always regards the requirements draft as a= guidance on Tracker and peer protocol. Based on the requirements draft, we p= roposed draft-gu-ppsp-tracker-protocol and peer-protocol.=20 >=20 > The WG has spent a lot of effort on PPSP Survey, because we want to extrac= t common features on current PPSP system, instead of base on a single privat= e protocol.=20 >=20 > I agree that Swift works, and it is a research project supported by many r= esearch groups, and I think those show support for swift are mostly involved= in SWIFT project.=20 > It will be easier for PPSP to get to an RFC published if we defining a pro= tocol based on a mature private protocol. But what about other private proto= cols? ANY ONE of the protocols introduced in Survey draft can work well and m= ost of them have much huge number of users than SWIFT, and even much better p= erformance. Shall we take them into consideration? >=20 > I hate to make this selection as an attack on each other draft. And I hope= those from SWIFT won't look at my email as an attack to their protocols. I j= ust wonder what does PPSP WG want, a mature private protocol or a developing= protocols based on widely survey?=20 I would like to second Yingjie's question. It is important to discuss the ob= jective first. There are indeed other options, e.g., based on reverse engine= ering, ppsp could use as a base one of those extremely widely deployed (with= tens of millions of real users) protocols, as long as there is no IP issue.= Protocol design is not an optimization problem, i.e., pick the optimal proto= col. So what is the goal of ppsp? If time is the essence and the goal is to h= ave a peer protocol coming out of IETF quickly, then swift can be a starting= base. Tanenbaum talked about the timing of standardization based on a camel= shape. I feel that p2p streaming is already at the lower half of the body, i= .e., many commercial protocols already exist. I am wondering on the opinions= of the chairs and other seasoned IETFs on an approach that PPSP could take,= to make a difference. I understand that many want to discuss the specific t= echnical details, but then I see endless debates. Thanks! Richard >=20 > I agree with Cruz's opinion. This is not a selection of draft, we have mor= e than one option.=20 >=20 >=20 >=20 >=20 >=20 > Best Regards > Gu Yingjie >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From enrico.marocco@telecomitalia.it Tue Nov 29 06:29:29 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3C521F8B6D for ; Tue, 29 Nov 2011 06:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.719 X-Spam-Level: X-Spam-Status: No, score=-100.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DgvQIt1pPWP for ; Tue, 29 Nov 2011 06:29:29 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 676B021F8B67 for ; Tue, 29 Nov 2011 06:29:28 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Nov 2011 15:29:25 +0100 Received: from maclab.homenet.telecomitalia.it (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 29 Nov 2011 15:29:25 +0100 Message-ID: <4ED4EC5C.9070209@telecomitalia.it> Date: Tue, 29 Nov 2011 15:29:48 +0100 From: Enrico Marocco User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Y. Richard Yang" References: <4ED48613.6070408@cs.yale.edu> In-Reply-To: <4ED48613.6070408@cs.yale.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060204080406000808090202" Cc: "ppsp@ietf.org" , LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 14:29:29 -0000 --------------ms060204080406000808090202 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/29/11 8:13 AM, Y. Richard Yang wrote: > First off, I got the feeling that multiple votes for swift over=20 > draft-gu-ppsp-peer were based on maturity, at this moment. I think > this is not a good idea, as maturity can change in a relatively short > time period, say between two IETFs, through some intensive > engineering efforts, and we are designing a protocol that will last a > much longer period. Hence it is important to consider the key > technical design. I would personally prefer an HTTP based protocol, > if we can show that it works, as HTTP is really the thin waist of the > Internet now. It will be great if the authors of draft-gu-ppsp-peer > would like to make their protocol complete, addressing the key > concerns, for example, bi-directional HTTP communications, say using > websocket, so that we can make a more informed decision. People > mostly watch video using browsers. We should consider more > browser-native protocols, if possible, for ppsp design. To restate what I argued during the meeting, I would wholeheartedly discourage the idea of using HTTP as the transport for any peer-to-peer protocol. Considerations about overhead, encoding and bi-directionality aside, I just cannot see how people think they can make peers behind different NATs reach each other, without some sort of relay -- no, uPnP doesn't work with multiple levels of NAT, and yes, it'll be more quite soon, but that's a very common case already. Least on standard ports 80/443, which are the actual thin waist of the (client/server) Internet. --=20 Ciao, Enrico --------------ms060204080406000808090202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINfjCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHQjCCBiqgAwIBAgIDAt9AMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTEwODIyMDYyNDA2 WhcNMTIwODIyMDM0MDM3WjB8MSAwHgYDVQQNExc0OTAyNDItOU1QZVJYRnFlVVU0QUMybTEo MCYGA1UEAwwfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEuMCwGCSqGSIb3DQEJ ARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALl4L3Uj7TJrMbll5JAyphws2AMR67q3D2FH0JmRqQ5r+ujqaxyeHcrx Kclu2tz/D3SPtZAlcDOclxpEDbpxXlMpo+3DsbNweNgSF6mnyRDYU2ay3qO54ENz21GZ64bl ZRsMI6KsGnxm7sORWLUdx229ijARs3aQD1js9bidUJsnxg26UvnwpJ8eGoFiCLzzsQXUD+OL 3TXEGrTzt+B2RDb13TIOe085T8jzBh08wNKPTDmKjxy5m35Xn8QfRy8b93d0wUs98Fst5iND EgHEHc9CwurwLYrOd/1ZkbfAoRi7kRQ0Ih4wKkP+Lkww/0qHEIrrgW+aVmGjkQ0nidAaE+sC AwEAAaOCA7owggO2MAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUYgEiK9qxBHth8ziqydxV7QYZn1QwHwYDVR0jBBgw FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVs ZWNvbWl0YWxpYS5pdDCCAiEGA1UdIASCAhgwggIUMIICEAYLKwYBBAGBtTcBAgIwggH/MC4G CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUF BwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIH3BggrBgEF BQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhp cyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5j ZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSBy ZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjCBnAYIKwYBBQUHAgIwgY8wJxYgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBAhpkTGlhYmlsaXR5IGFuZCB3YXJyYW50aWVz IGFyZSBsaW1pdGVkISBTZWUgc2VjdGlvbiAiTGVnYWwgYW5kIExpbWl0YXRpb25zIiBvZiB0 aGUgU3RhcnRDb20gQ0EgcG9saWN5LjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0 YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzAB hi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYB BQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcN AQEFBQADggEBAF4gnxCzZVmINcZh7ZMB6G1+8/kV6pLqDxyUidalFSJ8KLwJxrxhESOb+E7d JHxZBuJFH1NBXuVn+MI7rqa/HI7PkLJjkHhMH8ay7jhR2VVMIFYAqRn9O22oDDw2iEigYkgo HcHP1vD5rtydbGr6mCcHOtWCk5B7FqEoMYTQRO1F6szoqORVaajVtZeSwtVAMufV20tohyUL hpOH5lZDblsej2XueyJVqD8RYSUJp7w4eMpr5CTP9QdNBS0cca83JA070JMudV+ozG6ADIBx mGPrWyPv7PmjBBGIXxPJJRxDsDyJBYhs+qh6fZWNl6WZkQNepkn7IAUB0+0ggds992kxggPQ MIIDzAIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30AwCQYF Kw4DAhoFAKCCAhAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTExMTI5MTQyOTQ4WjAjBgkqhkiG9w0BCQQxFgQUDYTE86xrDJSTMkTXNXc0LT77qREwXwYJ KoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQx gZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENv bSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAt9AMIGnBgsqhkiG 9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMC30Aw DQYJKoZIhvcNAQEBBQAEggEAc1fH41Bt069kev4VxEKpKLclr2PhNIxm0xVrHvnUc9MGEExQ JygC4PkhJ3EThMs1w59lAKgP+kSn8/TqXpTqjj66i/mtuVLeHMBRQtk7awA7uNz14L4eVlrr PKMiZ9wIiqJUH2k+M9V3T/O5yyzR2OvEvdkASlxCuFexIZIzBUSI+wQMqwe/A4mLqBPh7KNY naqjhHJrXJilcCUzA9sPZoaenSOHm0XC+qniXu1bc91xsBChw//vdifQkxhlHUy65ajQ49VV CwbZfjA5ljMktAvikArO7J6hYENLXX5NyNZnANX+tc1q9meAQI2aBV80iFW4Ct4yPjv3DcQz pOrn4gAAAAAAAA== --------------ms060204080406000808090202-- From george.milescu@gmail.com Tue Nov 29 06:55:02 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD5D21F8C20 for ; Tue, 29 Nov 2011 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+KuXS-unmHB for ; Tue, 29 Nov 2011 06:55:01 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8501D21F8C1F for ; Tue, 29 Nov 2011 06:55:01 -0800 (PST) Received: by ywm13 with SMTP id 13so5437630ywm.31 for ; Tue, 29 Nov 2011 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SWvqfWckHcLoubmQW7GwPC7mDEM0sje9Oq1sRLrunIE=; b=cnYj6LIfGPmDnqBJMehcaLox7Uwr9sO6ysdcBHJkzVvsgBl8N63tucy1OuPDD1bFUx kpsXL8DU9y42M+OUU0BRujrW8ivyf2TnuQZC5p0yaqZn+iNmQmfYTEWIyO6UFZne1Tw7 /6lKrQJr1HTjcnJYxdtLvrgQHBV+m3AZJU8hs= Received: by 10.68.62.136 with SMTP id y8mr63761297pbr.87.1322578500599; Tue, 29 Nov 2011 06:55:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.134.19 with HTTP; Tue, 29 Nov 2011 06:54:19 -0800 (PST) In-Reply-To: References: From: George Milescu Date: Tue, 29 Nov 2011 16:54:19 +0200 Message-ID: To: Martin Stiemerling Content-Type: text/plain; charset=ISO-8859-1 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 14:55:02 -0000 On Thu, Nov 24, 2011 at 16:42, Martin Stiemerling wrote: > Please state your **technical** opinion about which peer protocol proposal you would prefer on the PPSP mailing list until November 30th. Hello all. I represent University POLITEHNICA of Bucharest, the largest technical university in Romania. For the past few years we developed a research group studying P2P protocols. We focused on congestion problems, overlay enhancements, wire-protocol analysis. Our vote goes to the Swift proposal [1] for the following reasons: * Swift has a simple, elegant design. Complicated designs (like the one proposed by Cruz+Gu) are very likely to cause problems in the long term. * Cruz+Gu uses HTTP as a P2P protocol basis. This requires a double amount of connections to be created between peers and introduces a potential asymmetry in the design. Increasing the number of connections also creates problems regarding NAT traversal. Having the nodes run HTTP servers does not allow the creation of lightweight clients. * The Swift implementation was proven to work in various scenarios, both on mobile devices and STBs. * The Cruz+Gu lacks clarifications about multiplexing of data streams (in the current proposal the requests and replies can not be multiplexed simultaneously). [1] http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03 Best regards, George -- George Milescu Teaching Assistant University POLITEHNICA of Bucharest From Martin.Stiemerling@neclab.eu Tue Nov 29 06:56:24 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D9421F8BB0 for ; Tue, 29 Nov 2011 06:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-33MhcOi5ee for ; Tue, 29 Nov 2011 06:56:17 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9E21F8C20 for ; Tue, 29 Nov 2011 06:56:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1A54428000082; Tue, 29 Nov 2011 15:56:15 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuYsi6l0KUWm; Tue, 29 Nov 2011 15:56:14 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id DC29F28000080; Tue, 29 Nov 2011 15:56:04 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 15:56:04 +0100 From: Martin Stiemerling To: Rui Cruz , "ppsp@ietf.org" Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/QDbPCcAACBXE8A= Date: Tue, 29 Nov 2011 14:56:03 +0000 Message-ID: References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> In-Reply-To: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91319Polydeucesoffic_" MIME-Version: 1.0 Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 14:56:24 -0000 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91319Polydeucesoffic_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [speaking as individual contributor and not as chair of the PPSP WG] Hi there, Replying to the proposal of the 2 alternatives: Alternative 1: I do not see how this will make a good protocol specification at the end. T= here must be one draft that contains everything so that an implementer can = make a program out of this (or part of a program). This requires that seman= tics and syntax are in the same draft for the protocol. Furthermore, there = is no space for an architecture, as we do protocols. There can be considera= tions how the protocol would interact with the rest of the program, i.e., t= he actual media player. But this is not part of the protocol specification. Alternative 2: I do not see the common ground of the 2 proposals that would allow a merger= . As stated in the meeting: draft-gu-ppsp-peer-protocol lacks many crucial = details for specifying a peer protocol for PPSP. draft-grishchenko-ppsp-swift has much more technical meat in specifying the= basis of a PPSP peer protocol, though there are also some rough corners. I'm in clear favor of draft-grishchenko-ppsp-swift as being the PPSP peer p= rotocol. The protocol specification defines semantics and syntax. The defin= ed semantics and syntax are what I understand and would be able to start wo= rking on an early implementation, though there is the need to get more thin= gs nailed down. But a proposal must not be perfect at this point of time. The WG should consider elements of draft-gu-ppsp-peer-protocol as further i= nput to the peer protocol. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui= Cruz Sent: Tuesday, November 29, 2011 1:18 AM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selection of PPSP peer protocol draft Hi, I am in favor of Swift as a Wire Format and Message Transport candidate for= the PPSP Peer Protocol, although the Media Data Transport may need further= discussions (Data Transport is not in the scope of the signaling protocol,= although the design may determine it). However... I would reconsider if the situation is for either one or the other draft to= be voted as preferred in the WG. Opinions have balanced from a "merger, as both have some advantages", "some= features can be included into the other proposal", "take swift as basis" o= r "'extensions' can be added, that parse the data (or the metadata) to get = infos needed by download algorithms" because "information about the distort= ion, the interdependency between chunks (to reflect coding dependencies), t= he temporal vs. spatial scalability/layering to be conveyed" may be needed = for the scheduling algorithms. Neither of the drafts presented a complete protocol architecture. And so, I would propose the following alternatives (not in andy preferred o= rder) to the simple white/black voting: Alternative 1: one draft would proceed describing the Protocol Architecture= , Semantics, Syntax and Logic, and the other draft the way to implement the= Wire Format/Encoding layer and Message Transport layer, suggesting and jus= tifying Network Transport preferences. Alternative 2: "merging the efforts", not the "proposals" on defining the = Protocol Architecture, Semantics and Logic and refining the Wire Format/enc= oding and Message Transport layers, in an orchestrated way. Both teams coul= d perfectly do their best to converge into a complete specification. The reasons behind this proposal are the following, for which some response= s and comments would enrich the discussion in the Mailing List: 1. Architecture The PPSP Peer Protocol design needs a very clear Architecture in order to a= ddress Semantics, Syntax, Operation Logic and "services" provided, as the "= Peer Agent" interfaces and interacts with a Client Media Player (in order t= o stream what the User requests, even if the User is playing Tricks, like j= umping forward in the movie or selecting a different audio dubbing or subti= tle language). The Architecture would describe, at least: - Peer Selection criteria: based of location, capabilities, etc., - Streaming Modes support: live, on-demand, and how to obtain, ahead of dat= a, updates for the chunk IDs of the live media sliding window, - Extensibility: in terms of the support/cooperation with diverse media rep= resentations and media structures/encodings, as the "Peer Agent" should not= take decisions on interdependency between media chunks or representations = (coding dependencies) of Structured Media, and that role should be performe= d at the Media Player application level. However it should cooperate for th= e correct and adequate download scheduling of the required (externally orde= red) media chunks (where chunks correspond to segments of media, with simil= ar duration, divided at points that support effective individual decoding, = e.g., on packet and key frame boundaries). - Interactions with: the Client Application (and Media Player) and support = of media Trick-Function requests, the Tracker(s) - Operation Semantics: the "Peer Agent" is NOT the Media Player, therefore = does not take decisions on what to watch (presentation) or at which media p= resentation time to start watching, at any moment. 2. Wire Protocol The Wire Protocol goal is to provide the adequate framework (not concerned = with implementation and semantics of operation) for the invocation of opera= tions on resources, considering: - "service-side" interface: with the Client Application, with the Tracker p= rocesses components (in the Peer). - "transport-side" interface: object types/assets, methods/messages, reques= ts/replies/results operations, error codes/conditions either explicit or im= plicit, integrity, addressing. 3. Message Transport The Message Transport addresses the efficient delivery of messages, indepen= dently of their meaning or purpose: - message segmentation (message boundaries) - multiplexing, pipelining, channeling - flow and congestion control >From what is written in the swift description draft, there is no interactio= n with the Media Player apart from feeding it with the downloaded media, me= aning that, as soon as the "Peer" knows the root Hash or Public key (Swarm-= ID) immediately starts pulling all the media to feed the Player, without an= y interaction. The method is, apparently, similar to a multi-source "progre= ssive download". One important aspect is that the signaling for bitmaps/hashes of swift is p= ush-mode, but the Media DATA streaming is always PULL-Mode, for either Live= or on-demand. About the support of Structured Media, I could not see evidence of that, no= r how Swift deals with several representations of the media, i.e., video (s= everal clips, multiple bitrates, layers), audio (different audio dubbing la= nguages), text (different subtitle languages), unless all are multiplexed i= n a container file, or "contained" in a directory of files, in order to be = hashed in byte ranges. An example of such a structure is the following, for a 10 seconds video enc= oded in SVC with two spacial resolutions (432x240 and 842x480) and 6 layers= for quality fidelity, with an associated Audio track. Each segment (with c= hunks labelled .00, .01, .02, etc for the different layers) corresponds to = a duration of 2 seconds of media playout, and the corresponding sizes are a= lso indicated (example taken from a real test video). For this example, I suppose that swift would have to hash independently eac= h chunk, am I right? But then, how would it address the scalability, as the= Client Player requester, would eventually not request all the layers of a = segment during those 10 seconds of duration (perhaps, starting only up to l= ayer L3 on the first segment, then raising to L4, then L5 in the following = segments, or, if bandwidth would allow up to L6 for the remaining segments)= . +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER CHUN= KS 162 KiB 172 KiB 154 KiB 157 KiB 177 KiB +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER CHUN= KS 117 KiB 121 KiB 113 KiB 120 KiB 117 KiB +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER CHUN= KS 4 KiB 6 KiB 6 KiB 6 KiB 4 KiB +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER CHUN= KS 3 KiB 5 KiB 5 KiB 6 KiB 4 KiB +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER CHUN= KS 5 KiB 6 KiB 5 KiB 6 KiB 6 KiB +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER CHUN= KS 54 KiB 55 KiB 49 KiB 53 KiB 58 KiB +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER CHUN= KS 50 KiB 52 KiB 50 KiB 53 KiB 50 KiB +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB 5 KiB 5 KiB 5 KiB --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Po= rto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 24/11/2011, at 14:42, Martin Stiemerling wrote: Dear all, The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91319Polydeucesoffic_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = [speaking as individual contributor and not as chair of the PPSP WG]<= /o:p> = = Hi there, = = Replying to the proposal of the 2 alternatives: = Alternative 1: = I do not see how this will make a good protocol specification at the end. There must be one draft that contains everything so that an implementer ca= n make a program out of this (or part of a program). This requires that sem= antics and syntax are in the same draft for the protocol. Furthermore, ther= e is no space for an architecture, as we do protocols. There can be considerations how the protocol would int= eract with the rest of the program, i.e., the actual media player. But this= is not part of the protocol specification. = = Alternative 2: = I do not see the common ground of the 2 proposals that would allow a merge= r. As stated in the meeting: draft-gu-ppsp-peer-protocol lacks many crucial d= etails for specifying a peer protocol for PPSP. = draft-grishchenko-ppsp-swift has much more technical meat in specifying the basis of a PPSP peer protocol, though there are also some rough corner= s. = = I’m in clear favor of draft-grishchenko-ppsp-swift as being the PPSP= peer protocol. The protocol specification defines semantics and syntax. The def= ined semantics and syntax are what I understand and would be able to start = working on an early implementation, though there is the need to get more th= ings nailed down. But a proposal must not be perfect at this point of time. = = The WG should consider elements of draft-gu-ppsp-peer-protocol as further input to the peer protocol. = = = Martin = = martin.stiemerling@neclab.= eu = = NEC Laboratories Europe - Network Research Division NEC Europe Limited | Regis= tered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in Eng= land 2832014 = From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui Cruz Sent: Tuesday, November 29, = 2011 1:18 AM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selectio= n of PPSP peer protocol draft = Hi, = I am in favor of Swift as a Wire Format and Message Tra= nsport candidate for the PPSP Peer Protocol, although the Media Data Transport may need fur= ther discussions (Data Transport is not in the scope of the signaling proto= col, although the design may determine it). = However… = = I would reconsider if the situation is for either one or the other draft to= be voted as preferred in the WG. = = Opinions have balanced from a "merger, as both have some advantages&qu= ot;, "some features can be included into the other proposal", "take swift as basis" or "'extensions' can be added, that p= arse the data (or the metadata) to get infos needed by download algorithms&= quot; because "information about the distortion, the interdependency b= etween chunks (to reflect coding dependencies), the temporal vs. spatial scalability/layering to be conveyed" may be needed for th= e scheduling algorithms. = = Neither of the drafts presented a complete protocol architecture. = = And so, I would propose the following alternati= ves (not in andy preferred order) to the simple white/black voti= ng: = Alternative 1: one draft would proceed describing the Protocol Architecture, Semantics, Syntax and Logic,= and the other draft the way to implement the Wire Format/Encoding layer an= d Message Transport layer, suggesting and justifying Network Transport pref= erences. Alternative 2: "merging the efforts", not the "proposals&q= uot; on defining the Protocol Architecture, Semantics and Logic and refinin= g the Wire Format/encoding and Message Transport layers, in an orchestrated way. Both teams could perfectly do their best to converge into a complete = specification. = = The reasons behind this proposal are the fo= llowing, for which some responses and comments would enrich the = discussion in the Mailing List: = = 1. Architecture = The PPSP Peer Protocol design needs a very clear Architecture in order to a= ddress Semantics, Syntax, Operation Logic and "services" provided, as the "Peer Agent" interfaces and interacts with a Cl= ient Media Player (in order to stream what the User requests, even if the U= ser is playing Tricks, like jumping forward in the movie or selecting a dif= ferent audio dubbing or subtitle language). <= /p> = = The Architecture would describe, at least: = - Peer Selection criteria: based of location, capabilities, etc., = - Streaming Modes support: live, on-demand, and how to obtain, ahead of dat= a, updates for the chunk IDs of the live media sliding window, = - Extensibility: in terms of the support/cooperation with diverse media rep= resentations and media structures/encodings, as the "Peer Agent" should not take decisions on interdependency betwee= n media chunks or representations (coding dependencies) of Structured Media= , and that role should be performed at the Media Player application level. = However it should cooperate for the correct and adequate download scheduling of the required (externally ordered) medi= a chunks (where chunks correspond to segments of media, with similar durati= on, divided at points that support effective individual decoding, e.g., on = packet and key frame boundaries). = - Interactions with: the Client Application (and Media Player) and support = of media Trick-Function requests, the Tracker(s) = - Operation Semantics: the "Peer Agent" is NOT the Media Player, = therefore does not take decisions on what to watch (presentation) or at which media presentation time to start watching, at any moment.= = = 2. Wire Protocol = The Wire Protocol goal is to provide the adequate framework (not concerned = with implementation and semantics of operation) for the invocation of operations on resources, considering:<= /font> = - "service-side" interface: with the Client Application, with the= Tracker processes components (in the Peer). = - "transport-side" interface: object types/assets, methods/messag= es, requests/replies/results operations, error codes/conditions either explicit or implicit, integrity, addressing. = = 3. Message Transport = The Message Transport addresses the efficient delivery of messages, indepen= dently of their meaning or purpose: = - message segmentation (message boundaries) = - multiplexing, pipelining, channeling = - flow and congestion control = = >From what is written in the swift description draft, there is no interactio= n with the Media Player apart from feeding it with the downloaded media, meaning that, as soon as the "Peer" knows = the root Hash or Public key (Swarm-ID) immediately starts pulling all the m= edia to feed the Player, without any interaction. The method is, apparently= , similar to a multi-source "progressive download". = One important aspect is that the signaling for bitmaps/hashes of swift is p= ush-mode, but the Media DATA streaming is always PULL-Mode, for either Live or on-demand. = = About the support of Structured Media, I could not see evidence of that, no= r how Swift deals with several representations of the media, i.e., video (several clips, multiple bitrates, layers), audio (= different audio dubbing languages), text (different subtitle languages), un= less all are multiplexed in a container file, or "contained" in a= directory of files, in order to be hashed in byte ranges. = An example of such a structure is the following, for a 10 seconds video enc= oded in SVC with two spacial resolutions (432x240 and 842x480) and 6 layers for quality fidelity, with an associated Audio t= rack. Each segment (with chunks labelled .00, .01, .02, etc for the differe= nt layers) corresponds to a duration of 2 seconds of media playout, and the= corresponding sizes are also indicated (example taken from a real test video). = = For this example, I suppose that swift would have to hash independently eac= h chunk, am I right? But then, how would it address the scalability, as the Client Player requester, would eventually not requ= est all the layers of a segment during those 10 seconds of duration (perhap= s, starting only up to layer L3 on the first segment, then raising to L4, t= hen L5 in the following segments, or, if bandwidth would allow up to L6 for the remaining segments). = +++L6.00+++ +++L6.01+&#= 43;+ +++L6.02+++ +++L6.03++= + +++L6.O4+++ ENH6 LAYER CHUNKS 162 KiB 172 KiB 154 KiB &nbs= p; 157 KiB 177 KiB = +++L5.00+++ +++L5.01+&#= 43;+ +++L5.02+++ +++L5.03++= + +++L5.O4+++ ENH5 LAYER CHUNKS 117 KiB 121 KiB 113 KiB &nbs= p; 120 KiB 117 KiB = +++L4.00+++ +++L4.01+&#= 43;+ +++L4.02+++ +++L4.03++= + +++L4.O4+++ ENH4 LAYER CHUNKS 4 KiB 6 KiB 6 KiB &nb= sp; 6 KiB 4 KiB <= /span> = +++L3.00+++ +++L3.01+&#= 43;+ +++L3.02+++ +++L3.03++= + +++L3.O4+++ ENH3 LAYER CHUNKS 3 KiB 5 KiB 5 KiB &nb= sp; 6 KiB 4 KiB <= /span> = +++L2.00+++ +++L2.01+&#= 43;+ +++L2.02+++ +++L2.03++= + +++L2.O4+++ ENH2 LAYER CHUNKS 5 KiB 6 KiB 5 KiB &nb= sp; 6 KiB 6 KiB <= /span> = +++L1.00+++ +++L1.01+&#= 43;+ +++L1.02+++ +++L1.03++= + +++L1.O4+++ ENH1 LAYER CHUNKS 54 KiB 55 KiB 49 KiB &n= bsp; 53 KiB 58 KiB = = +++L0.00+++ +++L0.01+&#= 43;+ +++L0.02+++ +++L0.03++= + +++L0.O4+++ BASE LAYER CHUNKS 50 KiB 52 KiB 50 KiB &n= bsp; 53 KiB 50 KiB = +++AA.00+++ +++AA.01+&#= 43;+ +++AA.02+++ +++AA.03++= + +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB 5 K= iB 5 KiB 5 KiB = = ---------------------------<= /font><= o:p> Best Regards, Prof. Rui Sa= ntos Cruz = Chairman IEEE&n= bsp;Portugal Section<= br> Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5,&= nbsp;2744-016 Porto Salvo, Portugal +351 214 233 200 (ext 5044), += ;351.939 060 939 (mobile) = rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ie= ee-pt.org Advancing technology for humanity.<= /span> = = On 24/11/2011, at 14:42, Martin Stiemerling wrote:= = = Dear all, The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: htt= p://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http= ://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.= ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.e= u NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org= /mailman/listinfo/ppsp = --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91319Polydeucesoffic_-- From Martin.Stiemerling@neclab.eu Tue Nov 29 06:58:39 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCCC21F8551 for ; Tue, 29 Nov 2011 06:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjKgod6Y5FK8 for ; Tue, 29 Nov 2011 06:58:32 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A320F21F8513 for ; Tue, 29 Nov 2011 06:58:31 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id ED4A7280001C4; Tue, 29 Nov 2011 15:58:30 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G2MBYTnZ8C8; Tue, 29 Nov 2011 15:58:30 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id BA2E728000080; Tue, 29 Nov 2011 15:58:15 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 15:58:15 +0100 From: Martin Stiemerling To: Ye Wang , 'Rui Cruz' , "ppsp@ietf.org" Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/QDbPCcAAAxmsoAAFGCnMA== Date: Tue, 29 Nov 2011 14:58:14 +0000 Message-ID: References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> <000901ccae5d$f49dde00$ddd99a00$@yale.edu> In-Reply-To: <000901ccae5d$f49dde00$ddd99a00$@yale.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91340Polydeucesoffic_" MIME-Version: 1.0 Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 14:58:39 -0000 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91340Polydeucesoffic_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [speaking as individual contributor and not as chair of the PPSP WG] Hi, The PPSP protocols should fit a wide range of peer-to-peer TV architectures= and not only a very limited set or a single architecture. However, we are = not defining architectures in the IETF in general and in particular in PPSP= . Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Ye = Wang Sent: Tuesday, November 29, 2011 7:13 AM To: 'Rui Cruz'; ppsp@ietf.org Subject: Re: [ppsp] Selection of PPSP peer protocol draft Hi Rui, I think you are making a very important point. The protocol(s) to be standardized should carefully define what system arch= itecture it fits in, what media types it can handle, what interfaces it can= provide to streaming consumers (such as media player), etc. Specified protocols can be a great solution to some specific system designs= , but the WG may still need a more general standard. For example, we encounter a similar problem as what Rui mentioned, when we = need to supporting dynamical multi-rate streaming (e.g., 240p, 360p, 480p, = 720p HD). We need to customize our protocols to make our system working mo= re efficiently: in particular we decide to map different video chunks (from= different sources, with different sizes) to the same id, based on correspo= nding video frame timestamp. Another example is regarding the debate on the push/pull of the bitmap. Wh= en our system works with low-capacity video source (e.g., a single server) = and small chunk size, we build an overlay network with multi-hop diameter, = and it turns out the push scheme performs better as it is an efficient way = for the peers to discover the newest/rarest chunks in the channel, even tho= ugh it consumes around 10% of the peer upload capacity; but when we have la= rge-capacity source (e.g., a set of CDN access points) and large chunk size= (e.g., to accommodate HTTP overhead when working with CDN), the pull based= scheme actually saves peer uplink resource, since the overlay structure is= not "deep", so each peer just need to request neighbors about their chunk = availability "on demand" (as long as their neighbor's capacity is already e= fficiently utilized) because it can always fetch from source if it is not h= appy about the progress. Thanks, Ye From: ppsp-bounces@ietf.org [mailto:ppsp-boun= ces@ietf.org] On Behalf Of Rui Cruz Sent: Monday, November 28, 2011 7:18 PM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selection of PPSP peer protocol draft Hi, I am in favor of Swift as a Wire Format and Message Transport candidate for= the PPSP Peer Protocol, although the Media Data Transport may need further= discussions (Data Transport is not in the scope of the signaling protocol,= although the design may determine it). However... I would reconsider if the situation is for either one or the other draft to= be voted as preferred in the WG. Opinions have balanced from a "merger, as both have some advantages", "some= features can be included into the other proposal", "take swift as basis" o= r "'extensions' can be added, that parse the data (or the metadata) to get = infos needed by download algorithms" because "information about the distort= ion, the interdependency between chunks (to reflect coding dependencies), t= he temporal vs. spatial scalability/layering to be conveyed" may be needed = for the scheduling algorithms. Neither of the drafts presented a complete protocol architecture. And so, I would propose the following alternatives (not in andy preferred o= rder) to the simple white/black voting: Alternative 1: one draft would proceed describing the Protocol Architecture= , Semantics, Syntax and Logic, and the other draft the way to implement the= Wire Format/Encoding layer and Message Transport layer, suggesting and jus= tifying Network Transport preferences. Alternative 2: "merging the efforts", not the "proposals" on defining the = Protocol Architecture, Semantics and Logic and refining the Wire Format/enc= oding and Message Transport layers, in an orchestrated way. Both teams coul= d perfectly do their best to converge into a complete specification. The reasons behind this proposal are the following, for which some response= s and comments would enrich the discussion in the Mailing List: 1. Architecture The PPSP Peer Protocol design needs a very clear Architecture in order to a= ddress Semantics, Syntax, Operation Logic and "services" provided, as the "= Peer Agent" interfaces and interacts with a Client Media Player (in order t= o stream what the User requests, even if the User is playing Tricks, like j= umping forward in the movie or selecting a different audio dubbing or subti= tle language). The Architecture would describe, at least: - Peer Selection criteria: based of location, capabilities, etc., - Streaming Modes support: live, on-demand, and how to obtain, ahead of dat= a, updates for the chunk IDs of the live media sliding window, - Extensibility: in terms of the support/cooperation with diverse media rep= resentations and media structures/encodings, as the "Peer Agent" should not= take decisions on interdependency between media chunks or representations = (coding dependencies) of Structured Media, and that role should be performe= d at the Media Player application level. However it should cooperate for th= e correct and adequate download scheduling of the required (externally orde= red) media chunks (where chunks correspond to segments of media, with simil= ar duration, divided at points that support effective individual decoding, = e.g., on packet and key frame boundaries). - Interactions with: the Client Application (and Media Player) and support = of media Trick-Function requests, the Tracker(s) - Operation Semantics: the "Peer Agent" is NOT the Media Player, therefore = does not take decisions on what to watch (presentation) or at which media p= resentation time to start watching, at any moment. 2. Wire Protocol The Wire Protocol goal is to provide the adequate framework (not concerned = with implementation and semantics of operation) for the invocation of opera= tions on resources, considering: - "service-side" interface: with the Client Application, with the Tracker p= rocesses components (in the Peer). - "transport-side" interface: object types/assets, methods/messages, reques= ts/replies/results operations, error codes/conditions either explicit or im= plicit, integrity, addressing. 3. Message Transport The Message Transport addresses the efficient delivery of messages, indepen= dently of their meaning or purpose: - message segmentation (message boundaries) - multiplexing, pipelining, channeling - flow and congestion control >From what is written in the swift description draft, there is no interactio= n with the Media Player apart from feeding it with the downloaded media, me= aning that, as soon as the "Peer" knows the root Hash or Public key (Swarm-= ID) immediately starts pulling all the media to feed the Player, without an= y interaction. The method is, apparently, similar to a multi-source "progre= ssive download". One important aspect is that the signaling for bitmaps/hashes of swift is p= ush-mode, but the Media DATA streaming is always PULL-Mode, for either Live= or on-demand. About the support of Structured Media, I could not see evidence of that, no= r how Swift deals with several representations of the media, i.e., video (s= everal clips, multiple bitrates, layers), audio (different audio dubbing la= nguages), text (different subtitle languages), unless all are multiplexed i= n a container file, or "contained" in a directory of files, in order to be = hashed in byte ranges. An example of such a structure is the following, for a 10 seconds video enc= oded in SVC with two spacial resolutions (432x240 and 842x480) and 6 layers= for quality fidelity, with an associated Audio track. Each segment (with c= hunks labelled .00, .01, .02, etc for the different layers) corresponds to = a duration of 2 seconds of media playout, and the corresponding sizes are a= lso indicated (example taken from a real test video). For this example, I suppose that swift would have to hash independently eac= h chunk, am I right? But then, how would it address the scalability, as the= Client Player requester, would eventually not request all the layers of a = segment during those 10 seconds of duration (perhaps, starting only up to l= ayer L3 on the first segment, then raising to L4, then L5 in the following = segments, or, if bandwidth would allow up to L6 for the remaining segments)= . +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER CHUN= KS 162 KiB 172 KiB 154 KiB 157 KiB 177 KiB +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER CHUN= KS 117 KiB 121 KiB 113 KiB 120 KiB 117 KiB +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER CHUN= KS 4 KiB 6 KiB 6 KiB 6 KiB 4 KiB +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER CHUN= KS 3 KiB 5 KiB 5 KiB 6 KiB 4 KiB +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER CHUN= KS 5 KiB 6 KiB 5 KiB 6 KiB 6 KiB +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER CHUN= KS 54 KiB 55 KiB 49 KiB 53 KiB 58 KiB +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER CHUN= KS 50 KiB 52 KiB 50 KiB 53 KiB 50 KiB +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB 5 KiB 5 KiB 5 KiB --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Po= rto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 24/11/2011, at 14:42, Martin Stiemerling wrote: Dear all, The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91340Polydeucesoffic_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = [speaking as individual contributor and not as chair of the PPSP WG] = = Hi, = = The PPSP protocols should fit a wide range of peer-to-peer TV architecture= s and not only a very limited set or a single architecture. However, we are = not defining architectures in the IETF in general and in particular in PPSP= . = = Martin = = martin.stiemerling@neclab.= eu = = NEC Laboratories Europe - Network Research Division NEC Europe Limited | Regis= tered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in Eng= land 2832014 = From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Ye Wang Sent: Tuesday, November 29, = 2011 7:13 AM To: 'Rui Cruz'; ppsp@ietf.or= g Subject: Re: [ppsp] Selectio= n of PPSP peer protocol draft = Hi Rui, = = I think you are making a very important point. = The protocol(s) to be standardized should carefu= lly define what system architecture it fits in, what media types it can handle, what interfaces it can provide to streaming consumers (such= as media player), etc. = Specified protocols can be a great solution to s= ome specific system designs, but the WG may still need a more general standard. = = For example, we encounter a similar problem as w= hat Rui mentioned, when we need to supporting dynamical multi-rate streaming (e.g., 240p, 360p, 480p, 720p HD). We need to customize ou= r protocols to make our system working more efficiently: in particular we d= ecide to map different video chunks (from different sources, with different= sizes) to the same id, based on corresponding video frame timestamp. = Another example is regarding the debate on the p= ush/pull of the bitmap. When our system works with low-capacity video source (e.g., a single server) and small chunk size, we build an ove= rlay network with multi-hop diameter, and it turns out the push scheme perf= orms better as it is an efficient way for the peers to discover the newest/= rarest chunks in the channel, even though it consumes around 10% of the peer upload capacity; but when we hav= e large-capacity source (e.g., a set of CDN access points) and large chunk = size (e.g., to accommodate HTTP overhead when working with CDN), the pull b= ased scheme actually saves peer uplink resource, since the overlay structure is not “deep”, so= each peer just need to request neighbors about their chunk availability &#= 8220;on demand” (as long as their neighbor’s capacity is alread= y efficiently utilized) because it can always fetch from source if it is not happy about the progress. = = Thanks, = Ye = From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On B= ehalf Of Rui Cruz Sent: Monday, November 28, 2= 011 7:18 PM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selectio= n of PPSP peer protocol draft Hi, I am in favor of Swift as a Wire= Format and Message Transport candidate for the PPSP Peer= Protocol, although the Media Data Transport may need further discussions (Data Transport is not in the scope of the si= gnaling protocol, although the design may determine it). However…= I would reconsider if the situation is for either on= e or the other draft to be voted as preferred in the WG. Opinions have balanced from a "merger, as both = have some advantages", "some features can be included into the ot= her proposal", "take swift as basis" or "'extensions' c= an be added, that parse the data (or the metadata) to get infos needed by dow= nload algorithms" because "information about the distortion, the = interdependency between chunks (to reflect coding dependencies), the tempor= al vs. spatial scalability/layering to be conveyed" may be needed for the scheduling algorithms. Neither of the drafts presented a complete protocol = architecture. And so, I would propose the following alternati= ves (not in andy preferred order) to the simple white/black voti= ng: Alternative 1:= one draft would proceed describing the Protocol Architecture, Semantics, S= yntax and Logic, and the other draft the way to implement the Wire Format/Encoding layer and Message Transport laye= r, suggesting and justifying Network Transport preferences. Alternative 2: "merging the efforts", not the "prop= osals" on defining the Protocol Architecture, Semantics and Logic and = refining the Wire Format/encoding and Message Transport layers, in an orche= strated way. Both teams could perfectly do their best to converge into a complete specification. The reasons behind this proposal are the fo= llowing, for which some responses and comments would enrich the = discussion in the Mailing List: 1. Architecture The PPSP Peer Protocol design needs a very clear Arc= hitecture in order to address Semantics, Syntax, Operation Logic and "= services" provided, as the "Peer Agent" interfaces and interacts with a Client Media Player (in order to stream what the User= requests, even if the User is playing Tricks, like jumping forward in the = movie or selecting a different audio dubbing or subtitle language). The Architecture would describe, at least: - Peer Selection criteria: based of location, capabi= lities, etc., - Streaming Modes support: live, on-demand, and how = to obtain, ahead of data, updates for the chunk IDs of the live media slidi= ng window, - Extensibility: in terms of the support/cooperation= with diverse media representations and media structures/encodings, as the = "Peer Agent" should not take decisions on interdependency between media chunks or representations (coding dependenci= es) of Structured Media, and that role should be performed at the Media Pla= yer application level. However it should cooperate for the correct and adeq= uate download scheduling of the required (externally ordered) media chunks (where chunks correspond to seg= ments of media, with similar duration, divided at points that support effec= tive individual decoding, e.g., on packet and key frame boundaries). - Interactions with: the Client Application (and Med= ia Player) and support of media Trick-Function requests, the Tracker(s)&nbs= p; - Operation Semantics: the "Peer Agent" is= NOT the Media Player, therefore does not take decisions on what to watch (= presentation) or at which media presentation time to start watching, at any moment. 2. Wire Protocol The Wire Protocol goal is to provide the adequate fr= amework (not concerned with implementation and semantics of operation) for = the invocation of operations on resources, considering: - "service-side" interface: with the Clien= t Application, with the Tracker processes components (in the Peer). - "transport-side" interface: object types= /assets, methods/messages, requests/replies/results operations, error codes= /conditions either explicit or implicit, integrity, addressing. 3. Message Transport The Message Transport addresses the efficient delive= ry of messages, independently of their meaning or purpose: - message segmentation (message boundaries) - multiplexing, pipelining, channeling - flow and congestion control From what is written in the swift description draft,= there is no interaction with the Media Player apart from feeding it with t= he downloaded media, meaning that, as soon as the "Peer" knows the root Hash or Public key (Swarm-ID) immed= iately starts pulling all the media to feed the Player, without any interac= tion. The method is, apparently, similar to a multi-source "progressiv= e download". One important aspect is that the signaling for bitma= ps/hashes of swift is push-mode, but the Media DATA streaming is always PUL= L-Mode, for either Live or on-demand. About the support of Structured Media, I could not s= ee evidence of that, nor how Swift deals with several representations of th= e media, i.e., video (several clips, multiple bitrates, layers), audio (different audio dubbing languages), text (differ= ent subtitle languages), unless all are multiplexed in a container file, or= "contained" in a directory of files, in order to be hashed in by= te ranges. An example of such a structure is the following, for= a 10 seconds video encoded in SVC with two spacial resolutions (432x240 an= d 842x480) and 6 layers for quality fidelity, with an associated Audio track. Each segment (with chunks labelled .00, .0= 1, .02, etc for the different layers) corresponds to a duration of 2 second= s of media playout, and the corresponding sizes are also indicated (example= taken from a real test video). For this example, I suppose that swift would have to= hash independently each chunk, am I right? But then, how would it address = the scalability, as the Client Player requester, would eventually not request all the layers of a segment during those 10 s= econds of duration (perhaps, starting only up to layer L3 on the first segm= ent, then raising to L4, then L5 in the following segments, or, if bandwidt= h would allow up to L6 for the remaining segments). +++L6.00+++ += ;++L6.01+++ +++L6.02+++ +&#= 43;+L6.03+++ +++L6.O4+++ ENH6 LAYER CHUNKS 162 KiB 172 KiB &nb= sp; 154 KiB 157 KiB 177 KiB = +++L5.00+++ += ;++L5.01+++ +++L5.02+++ +&#= 43;+L5.03+++ +++L5.O4+++ ENH5 LAYER CHUNKS 117 KiB 121 KiB &nb= sp; 113 KiB 120 KiB 117 KiB = +++L4.00+++ += ;++L4.01+++ +++L4.02+++ +&#= 43;+L4.03+++ +++L4.O4+++ ENH4 LAYER CHUNKS 4 KiB 6 KiB = 6 KiB 6 KiB 4 KiB&n= bsp; +++L3.00+++ += ;++L3.01+++ +++L3.02+++ +&#= 43;+L3.03+++ +++L3.O4+++ ENH3 LAYER CHUNKS 3 KiB 5 KiB = 5 KiB 6 KiB 4 KiB&n= bsp; +++L2.00+++ += ;++L2.01+++ +++L2.02+++ +&#= 43;+L2.03+++ +++L2.O4+++ ENH2 LAYER CHUNKS 5 KiB 6 KiB = 5 KiB 6 KiB 6 KiB&n= bsp; +++L1.00+++ += ;++L1.01+++ +++L1.02+++ +&#= 43;+L1.03+++ +++L1.O4+++ ENH1 LAYER CHUNKS 54 KiB 55 KiB = 49 KiB 53 KiB 58 KiB&= nbsp; +++L0.00+++ += ;++L0.01+++ +++L0.02+++ +&#= 43;+L0.03+++ +++L0.O4+++ BASE LAYER CHUNKS 50 KiB 52 KiB = 50 KiB 53 KiB 50 KiB = +++AA.00+++ += ;++AA.01+++ +++AA.02+++ +&#= 43;+AA.03+++ +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB = 5 KiB 5 KiB &n= bsp; 5 KiB ---------------------------<= /font> Best Regards, Prof. Rui Santos Cruz Chairman IEEE&n= bsp;Portugal Section<= br> Av. Prof. Dr. An=EDbal Cavaco Silva, IST-= TagusPark, Office 1-5, 2744-016 Porto Salvo, Portugal +351 214 233 200 (ext 5044), += ;351.939 060 939 (mobile) = rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ie= ee-pt.org Advancing technology for humanity.<= /span> On 24/11/2011, at 14:42, Martin Stiemerling wrote: Dear all, The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: htt= p://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http= ://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.= ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.e= u NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org= /mailman/listinfo/ppsp --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91340Polydeucesoffic_-- From Martin.Stiemerling@neclab.eu Tue Nov 29 07:14:12 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513CF21F8B42 for ; Tue, 29 Nov 2011 07:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5mwXeF5tpBD for ; Tue, 29 Nov 2011 07:14:11 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9399121F8B3C for ; Tue, 29 Nov 2011 07:14:10 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E724B28000085; Tue, 29 Nov 2011 16:14:09 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajNMcxtTcUoc; Tue, 29 Nov 2011 16:14:09 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C81D628000080; Tue, 29 Nov 2011 16:13:54 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:13:54 +0100 From: Martin Stiemerling To: "Y. Richard Yang" , "ppsp@ietf.org" Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/QDpwKeAABJZUpA= Date: Tue, 29 Nov 2011 15:13:53 +0000 Message-ID: References: <4ED48613.6070408@cs.yale.edu> In-Reply-To: <4ED48613.6070408@cs.yale.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:14:12 -0000 [speaking as individual contributor and not as chair of the PPSP WG] Hi Richard,=20 > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Y= . > Richard Yang > Sent: Tuesday, November 29, 2011 8:13 AM > To: ppsp@ietf.org > Cc: LANS Yale > Subject: Re: [ppsp] Selection of PPSP peer protocol draft >=20 > Hi all, >=20 > I read both specs, and the meeting minutes but missed this IETF at > Taipei. So if I am repeating some discussions already happened, please > let me know. >=20 > First off, I got the feeling that multiple votes for swift over > draft-gu-ppsp-peer were based on maturity, at this moment. I think this Well, maturity is an indicator how far a proposal is. The discussions at th= e meeting have shown that there many fundamental questions which are not an= swered or addressed by draft-gu-ppsp-peer. For instance, if the protocol ai= ms at a low footprint on the wire which allows for instance piggy backing o= f chunk maps (whatever the flavor of the maps are). One discussion I remember well, was the discussion about how chunk maps are= acutally exchanged between two peers: - demand driven: a peer sends a chunk map request to the other chunk and wa= its for the response; - piggy backed without explicit request: the peers include periodically chu= nk maps in the messages exchanged to update the other peer.=20 The latter approach is clearly to be preferred, as speed matters, i.e., do = not waste time to figure out that you need an update of the chunk maps, but= let the peers to exchange that information on regular time basis.=20 > is not a good idea, as maturity can change in a relatively short time > period, say between two IETFs, through some intensive engineering > efforts, and we are designing a protocol that will last a much longer > period. Hence it is important to consider the key technical design. I I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol= proposals and the merged document raises even more questions than the pred= ecessor documents.=20 > would personally prefer an HTTP based protocol, if we can show that it > works, as HTTP is really the thin waist of the Internet now. It will be HTTP is a technical no go in time sensitive applications. It is also a no g= o for applications that require bi-directional communication.=20 > great if the authors of draft-gu-ppsp-peer would like to make their > protocol complete, addressing the key concerns, for example, > bi-directional HTTP communications, say using websocket, so that we can > make a more informed decision. People mostly watch video using browsers. > We should consider more browser-native protocols, if possible, for ppsp > design. RTCWEB is putting things in the browser, namely VoIP. However, they are hea= vily relying on RTP to exchange the time sensitive information, i.e., voice= and video. This is not supporting your argument at all.=20 >=20 > Since the swift protocol is more completely specified at this moment, > let me comment more on this protocol. The swift protocol is a quite > interesting protocol. I feel that using UDP as transport is one > potential path, as Adobe P2P is based on UDP as well. My main comments > on swift are the following: >=20 > * Are there any experimental results of swift at large scale real > experiments? To my understanding there are experimental results. You might argue about w= hat large scale is.=20 >=20 > * According to our experiences at building an experimental p2p streaming > system at Yale, a real protocol quickly becomes complex as we continue > to extend it to handle challenges in real settings. The extension scheme > of the protocol needs careful thinking. This has been part of the discussions at the meeting. For instance, the chu= nk trading mechanism must be extensible.=20 >=20 > * So far the draft contains many policies. I have not been convinced > that they are necessary. For example, The draft describes the swift implementation right now and needs definitely= work.=20 >=20 > - page 4 top: "... peer connects to a random set of other peers ..." > why random? >=20 > - page 4 "... omits HAVE messages as a way of choking A." >=20 > Also Page 7 on withholding HAVE. Also on Page 7 on withholding > error messages. >=20 > I typically do not like such information-hiding designs. Informed > decisions often are better, faster decisions. >=20 > - page 4 (also page 9) "... A sends a datagram containing HAVE > messages for the chunks it just received to all its peers." Specifying > such a push-just-received model may not be necessary. >=20 > - The design is essentially pushing for an uploader centric design. > This is unnecessary. >=20 > - The idea of using a tree to introduce bins and compute hashes is > interesting. Two comments: >=20 > - I am wondering is the scheme is patented. CK Wong and Simon Lam > presented such a design in 1998 (for disclosure, Simon Lam is my PhD > advisor): > http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf >=20 > I am not sure if there is a patent on it. And if so, will it > have impacts on the selection? If you know about IPR you must declare it. See the IETF IPR rules.=20 The usage of merkle trees or other mechanisms will be possible in the peer = protocol, but there will be also the possibility to use other mechanisms.=20 >=20 > - On the other hand, I am wondering if using such a binary tree > based design is necessary, as elaborated schemes typically can have > limit extensibility, compared with simple straightforward schemes . In > particular, how much savings are we talking about, at the cost of > choosing a particular binary tree based representation scheme? Such > information can be helpful. I think the swift guys have papers about it.=20 >=20 > To summarize, my vote is the following: >=20 > - Give the draft-ppsp-gu-peer authors some time (chance) to give a more > mature design, if the authors are willing, before we make a decision. Why? There has been time and we need to make a decision at some time point = about the peer protocol and also the tracker protocol.=20 We can of course wait until the next IETF meeting, but this sort of a bet t= owards the future.=20 >=20 > - If swift is used, check the patent issue; optional, show some real > experimental performance results; think about modular design (for > example, more elaborate NAT/mobility handling handshake); make the > protocol more policy neutral (e.g., by involving algorithmic designers > to leave enough design space); make sure it is extensible in the message > flows. I guess, it is up to you to raise technical details which be answered techn= ically by the swift guys.=20 Martin >=20 > Just some quick comments as input. >=20 > Thanks! >=20 > Richard >=20 > On 11/24/11 9:42 AM, Martin Stiemerling wrote: > > Dear all, > > > > The working group has to make a decision which peer protocol proposal t= o > choose as basis for the PPSP peer protocol. > > > > We have to independent proposals: > > - draft-gu-ppsp-peer-protocol-03 > > (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) > > - draft-grishchenko-ppsp-swift-03 > > (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) > > > > Both proposals for a peer protocol have been presented at the IETF meet= ing. > The slides are available here: > > - draft-gu-ppsp-peer-protocol-03: > > http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx > > - draft-grishchenko-ppsp-swift-03 > > http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf > > > > The feedback given at the IETF meeting about both proposals is document= ed > in the draft meeting minutes: > > http://www.ietf.org/proceedings/82/minutes/ppsp.txt > > > > Please state your **technical** opinion about which peer protocol propo= sal > you would prefer on the PPSP mailing list until November 30th. > > > > With best regards > > > > Yunfei and Martin > > PPSP co-chairs > > > > martin.stiemerling@neclab.eu > > martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 From a.bakker@vu.nl Tue Nov 29 07:17:22 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2823521F8B76 for ; Tue, 29 Nov 2011 07:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[AWL=1.450, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrR42LMk7I-b for ; Tue, 29 Nov 2011 07:17:21 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 429E821F8B67 for ; Tue, 29 Nov 2011 07:17:20 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 29 Nov 2011 16:17:10 +0100 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 29 Nov 2011 16:17:10 +0100 Message-ID: <4ED4F7E9.5090308@cs.vu.nl> Date: Tue, 29 Nov 2011 16:19:05 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> In-Reply-To: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:17:22 -0000 On 29/11/2011 01:17, Rui Cruz wrote: > > *Alternative 1:* one draft would proceed describing the Protocol > Architecture, Semantics, Syntax and Logic, and the other draft the way > to implement the Wire Format/Encoding layer and Message Transport layer, > suggesting and justifying Network Transport preferences. Hi the SARACEN project obviously has an architecture already specified, so by all means determine what things you need from the peer protocol to implement this architecture. I'll clarify a few points about swift below. > From what is written in the swift description draft, there is no > interaction with the Media Player apart from feeding it with the In Section 8 of the swift proposal, on Extensibility we discuss how we support different chunk/piece selection policies. So swift will support custom chunk selection algorithms that can be plugged into the base protocol and which determine what chunks are downloaded from whom. > > About the support of Structured Media, I could not see evidence of that, One such chunk selection algorithm can be one that understands SVC. In the simplest case there is a metadata specification that tells the SVC-aware algorithm what layers there are and how they map to chunk IDs. E.g. layer 0 is chunks 0..1000, layer 1 is chunks 1001...2001, etc. Then, based on information from the base protocol about bandwidth and chunk availability the SVC-aware algorithm will select the chunks for the layers it can support. We've been publishing on SVC/MDC and P2P since before 2004. As a matter of fact Riccardo is presenting a paper on chunk selection next week at IEEE ISM2011, so we know about structured media ;o) Riccardo Petrocco, Michael Eberhard, Johan Pouwelse and Dick Epema, "Deftpack: A Robust Piece Picking Algorithm for Scalable Video Coding", IEEE International Symposium on Multimedia (ISM2011), Dana Point, CA, USA, December 5-7, 2011. CU, Arno From Martin.Stiemerling@neclab.eu Tue Nov 29 07:25:48 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA2121F8BE4 for ; Tue, 29 Nov 2011 07:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsojnXHY9lZ2 for ; Tue, 29 Nov 2011 07:25:47 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 82BD221F8BF3 for ; Tue, 29 Nov 2011 07:25:47 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DCB71280001C4; Tue, 29 Nov 2011 16:25:46 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o7L8yTWo1KP; Tue, 29 Nov 2011 16:25:46 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id BDE7F28000085; Tue, 29 Nov 2011 16:25:36 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:25:36 +0100 From: Martin Stiemerling To: "Yingjie Gu(yingjie)" Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/QDxjzKAAAQ+5IAABuThgA== Date: Tue, 29 Nov 2011 15:25:36 +0000 Message-ID: References: <00ab01ccae96$97f0cd50$c7d267f0$@com> In-Reply-To: <00ab01ccae96$97f0cd50$c7d267f0$@com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:25:48 -0000 W3NwZWFraW5nIGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IgYW5kIG5vdCBhcyBjaGFpciBvZiB0 aGUgUFBTUCBXR10NCg0KSGkgWWluZ2ppZSwgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogWWluZ2ppZSBHdSh5aW5namllKSBbbWFpbHRvOmd1eWluZ2ppZUBodWF3ZWku Y29tXQ0KPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxMSAxOjU4IFBNDQo+IFRvOiBN YXJ0aW4gU3RpZW1lcmxpbmcNCj4gQ2M6IHBwc3BAaWV0Zi5vcmcNCj4gU3ViamVjdDog562U5aSN OiBbcHBzcF0gU2VsZWN0aW9uIG9mIFBQU1AgcGVlciBwcm90b2NvbCBkcmFmdA0KPiANCj4gSSB3 b3VsZCBsaWtlIHRvIHJlY2FsbCB0aGUgaGlzdG9yeSBvZiBwZWVyIHByb3RvY29sLg0KPiBXZSBi ZWdhbiB0byBwcm9wb3NlIFRyYWNrZXIgYW5kIFBlZXIgcHJvdG9jb2wgYXQgZWFybHkgMjAxMC4g U2luY2UgdGhlIHZlcnkNCj4gYmVnaW5uaW5nLCB3ZSBiZWxpZXZlIHRoYXQgUGVlciBwcm90b2Nv bCBzaG91bGQgYmUgY29uc2lzdGVudCB3aXRoIFRyYWNrZXINCj4gUHJvdG9jb2wuIEJ5IGNvbnNp c3RlbmNlLCBJIGRvbid0IG1lYW4gdGhhdCB0aGV5IGNhbiBjby1leGlzdCwgaW5zdGVhZCB0aGV5 DQo+IHNob3VsZCBzaGFyZSB0aGUgc2ltaWxhciBwaGlsb3NvcGh5IGFuZCBzaG91bGQgYmUgYWJs ZSB0byBpbnRlcm9wZXJhdGUuICBUaGF0J3MNCj4gd2h5IHdlIGNhbGwgdGhlbSBhIHN5c3RlbSwg bm90IHR3byBzaW5nbGUgcHJvdG9jb2xzLg0KDQpBZWhtLCB3ZSBkbyBub3QgZGVmaW5lIHN5c3Rl bXMgaGVyZS4gV2UgZG8gZGVmaW5lIHByb3RvY29scy4gDQoNCkFueWhvdywgdGhlcmUgaXMgbm90 aGluZyBhZ2FpbnN0IGhhdmluZyB0d28gZGlmZmVyZW50IHNldHMgb2YgY29yZSBwZW9wbGUgd29y a2luZyBvbiB0aGUgdHJhY2tlciBwcm90b2NvbCBhbmQgdGhlIHBlZXIgcHJvdG9jb2wuIFdlIGhh dmUgdGhlIHdvcmtpbmcgZ3JvdXAgd2hpY2ggd2lsbCB0YWtlIGNhcmUgdGhhdCB0aGUgYm90aCBj YW4gaW50ZXJhY3QuIA0KDQpGdXJ0aGVybW9yZToNCi0gdGhlIFBQU1AgdHJhY2tlciBwcm90b2Nv bCBpcyBvcHRpb25hbCB0byB0aGUgUFBTUCBwZWVyIHByb3RvY29sIGFuZA0KLSB0aGUgUFBTUCBw ZWVyIHByb3RvY29sIGlzIG9wdGlvbmFsIHRvIHRoZSBQUFNQIHRyYWNrZXIgcHJvdG9jb2wuIA0K DQpUaGUgcGVlciBwcm90b2NvbCBtdXN0IGJlIGFibGUgdG8gb3BlcmF0ZSB3aXRob3V0IHRoZSB0 cmFja2VyIHByb3RvY29sLCBhcyBhbiBhY3R1YWwgaW1wbGVtZW50ZXIgb2YgcDJwIHR2IHN5c3Rl bSBtYXkgY2hvc2UgYSBkaWZmZXJlbnQgd2F5IG9mIGRpc3RyaWJ1dGluZyB0aGUgaW5mb3JtYXRp b24gYWJvdXQgb3RoZXIgcGVlcnMsIGUuZy4sIHZpYSBhIERIVCBvciB2aWEgdGhlIHJlZ3VsYXIg Yml0dG9ycmVudCB0cmFja2VyIHByb3RvY29sLiANCg0KVGhlIHRyYWNrZXIgcHJvdG9jb2wgbXVz dCBiZSBhYmxlIHRvIG9wZXJhdGUgd2l0aG91dCB0aGUgcGVlciBwcm90b2NvbCwgYXMgc29tZWJv ZHkgbWlnaHQgY2hvc2UgdG8gdXNlIHRoZSBQUFNQIHRyYWNrZXIgcHJvdG9jb2wgd2l0aCBhIHBy b3ByaWV0YXJ5IHBlZXIgcHJvdG9jb2wuDQoNCj4gDQo+IFBQU1AgaGFkIHNwZW50IGEgbG90IG9m IHRpbWUgb24gZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHRoZSBQUFNQIHN0YW5kYXJkcw0KPiBzaG91 bGQgdXNlIFRyYWNrZXItYmFzZWQgb3IgRnVsbC1tZXNoIGFyY2hpdGVjdHVyZSAoZmluYWxseSwg V0cgZ290IGNvbnNlbnN1cw0KPiBvbiB0cmFja2VyLWJhc2VkKSwgYW5kIGhvdyB0aGUgVHJhY2tl ciBhbmQgUGVlciBwcm90b2NvbCBzaG91bGQgd29yaywgd2hpY2ggaXMNCj4gaW4gdGhlIFJlcXVp cmVtZW50cyBkcmFmdC4gV2UgYWx3YXlzIHJlZ2FyZHMgdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBh cyBhDQo+IGd1aWRhbmNlIG9uIFRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2wuIEJhc2VkIG9uIHRo ZSByZXF1aXJlbWVudHMgZHJhZnQsIHdlDQo+IHByb3Bvc2VkIGRyYWZ0LWd1LXBwc3AtdHJhY2tl ci1wcm90b2NvbCBhbmQgcGVlci1wcm90b2NvbC4NCg0KVGhpcyBzb3VuZHMgYXMgeW91ciBwcm9w b3NhbCBmb3IgYm90aCBwcm90b2NvbHMgaXMgYXV0aG9yYXRpdmUsIGJlY2F1c2UgeW91ciBwcm9w b3NhbCBpcyBiYXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0LiBJIHdvdWxkIHNheSB0aGF0 IGFueSBwcm90b2NvbCBwcm9wb3NhbCBpcyBhYm91dCB0byBmb2xsb3cgdGhlIHJlcXVpcmVtZW50 cy4gDQoNCj4gDQo+IFRoZSBXRyBoYXMgc3BlbnQgYSBsb3Qgb2YgZWZmb3J0IG9uIFBQU1AgU3Vy dmV5LCBiZWNhdXNlIHdlIHdhbnQgdG8gZXh0cmFjdA0KPiBjb21tb24gZmVhdHVyZXMgb24gY3Vy cmVudCBQUFNQIHN5c3RlbSwgaW5zdGVhZCBvZiBiYXNlIG9uIGEgc2luZ2xlIHByaXZhdGUNCj4g cHJvdG9jb2wuDQoNCldoYXQgaXMgdGhlIGNvbmNsdXNpb24/Pw0KDQo+IA0KPiBJIGFncmVlIHRo YXQgU3dpZnQgd29ya3MsIGFuZCBpdCBpcyBhIHJlc2VhcmNoIHByb2plY3Qgc3VwcG9ydGVkIGJ5 IG1hbnkNCj4gcmVzZWFyY2ggZ3JvdXBzLCBhbmQgSSB0aGluayB0aG9zZSBzaG93IHN1cHBvcnQg Zm9yIHN3aWZ0IGFyZSBtb3N0bHkgaW52b2x2ZWQgaW4NCj4gU1dJRlQgcHJvamVjdC4NCj4gSXQg d2lsbCBiZSBlYXNpZXIgZm9yIFBQU1AgdG8gZ2V0IHRvIGFuIFJGQyBwdWJsaXNoZWQgaWYgd2Ug ZGVmaW5pbmcgYSBwcm90b2NvbA0KPiBiYXNlZCBvbiBhIG1hdHVyZSBwcml2YXRlIHByb3RvY29s LiBCdXQgd2hhdCBhYm91dCBvdGhlciBwcml2YXRlIHByb3RvY29scz8NCj4gQU5ZIE9ORSBvZiB0 aGUgcHJvdG9jb2xzIGludHJvZHVjZWQgaW4gU3VydmV5IGRyYWZ0IGNhbiB3b3JrIHdlbGwgYW5k IG1vc3Qgb2YNCj4gdGhlbSBoYXZlIG11Y2ggaHVnZSBudW1iZXIgb2YgdXNlcnMgdGhhbiBTV0lG VCwgYW5kIGV2ZW4gbXVjaCBiZXR0ZXINCj4gcGVyZm9ybWFuY2UuIFNoYWxsIHdlIHRha2UgdGhl bSBpbnRvIGNvbnNpZGVyYXRpb24/DQoNCldlbGwsIHdlIHBvdGVudGlhbGx5IGNvdWxkIGdvIGFu ZCBleGFtaW5lIGFsbCBwcm9wcmlldGFyeSBwcm90b2NvbHMgb3V0IHRoZXJlLCBpbmNsdWRpbmcg dGhlIGF0dGFjaGVkIElQUiBhbmQgdGhlIHdpbGxpbmduZXNzIG9mIHRoZSBwcm90b2NvbCBvd25l cnMgdG8gdHJhbnNmZXIgdGhlIHByb3RvY29sIHRvIHRoZSBJRVRGLiANCg0KVGhpcyB3aWxsIGtl ZXAgdXMgYnVzeSBmb3IgYW5vdGhlciAxIG9yIDIgeWVhcnMgd2l0aG91dCBiZWluZyBhYmxlIHRv IHByb2dyZXNzIHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBwcm90b2NvbHMuIA0KDQo+IA0KPiBJ IGhhdGUgdG8gbWFrZSB0aGlzIHNlbGVjdGlvbiBhcyBhbiBhdHRhY2sgb24gZWFjaCBvdGhlciBk cmFmdC4gQW5kIEkgaG9wZSB0aG9zZQ0KPiBmcm9tIFNXSUZUIHdvbid0IGxvb2sgYXQgbXkgZW1h aWwgYXMgYW4gYXR0YWNrIHRvIHRoZWlyIHByb3RvY29scy4gSSBqdXN0IHdvbmRlcg0KPiB3aGF0 IGRvZXMgUFBTUCBXRyB3YW50LCBhIG1hdHVyZSBwcml2YXRlIHByb3RvY29sIG9yIGEgZGV2ZWxv cGluZyBwcm90b2NvbHMNCj4gYmFzZWQgb24gd2lkZWx5IHN1cnZleT8NCg0KVGhlIFdHIG11c3Qg ZG8gdGhlIHNlbGVjdGlvbiBiYXNlZCBvbiB0ZWNobmljYWwgYXJndW1lbnRzLiBJdCBpcyBub3Qg YWJvdXQgYXR0YWNraW5nIHRoZSBvdGhlciBkcmFmdHMsIGJ1dCB0byBmaW5kIG91dCB3aGF0IGlz IHRoZSBiZXN0IHRlY2huaWNhbCBzb2x1dGlvbi4gDQoNCkFuZCB0ZWNobmljYWxseSBzcGVha2lu ZywgeW91ciBwZWVyIHByb3RvY29sIGRyYWZ0IGxhY2tzIGEgbG90IG9mIGRldGFpbHMsIGFzIGNv bXBhcmVkIHRvIHRoZSBzd2lmdCBkcmFmdC4gDQoNCkhvd2V2ZXIsIHRvIHJlcGVhdCB0aGlzIGFn YWluOg0KSWYgdGhlcmUgYXJlIGZlYXR1cmVzIGluIHlvdXIgcHJvdG9jb2wgZHJhZnQgd2hpY2gg YXJlIG1pc3NpbmcgaW4gdGhlIHN3aWZ0IHByb3Bvc2FsLCB3cml0ZSB0aGVtIHVwIGFuZCBwb3N0 IHRoZW0gdG8gdGhlIGxpc3QuIA0KDQogIE1hcnRpbg0KDQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVj bGFiLmV1DQoNCk5FQyBMYWJvcmF0b3JpZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZp c2lvbiBORUMgRXVyb3BlIExpbWl0ZWQgfCBSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAx IFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwgfCBSZWdpc3RlcmVkIGluIEVuZ2xhbmQgMjgz MjAxNA0K From a.bakker@vu.nl Tue Nov 29 07:28:20 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE5221F8ACE for ; Tue, 29 Nov 2011 07:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=2.967, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qf3qRvyjY08x for ; Tue, 29 Nov 2011 07:28:20 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id CECA021F8ACC for ; Tue, 29 Nov 2011 07:28:19 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 29 Nov 2011 16:28:18 +0100 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 29 Nov 2011 16:28:18 +0100 Message-ID: <4ED4FA84.5080408@cs.vu.nl> Date: Tue, 29 Nov 2011 16:30:12 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> <000901ccae5d$f49dde00$ddd99a00$@yale.edu> In-Reply-To: <000901ccae5d$f49dde00$ddd99a00$@yale.edu> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:28:20 -0000 On 29/11/2011 07:12, Ye Wang wrote: > > Another example is regarding the debate on the push/pull of the bitmap. > When our system works with low-capacity video source (e.g., a single > server) and small chunk size, we build an overlay network with multi-hop > diameter, and it turns out the push scheme performs better as it is an > efficient way for the peers to discover the newest/rarest chunks in the > channel, even though it consumes around 10% of the peer upload capacity; > but when we have large-capacity source (e.g., a set of CDN access > points) and large chunk size (e.g., to accommodate HTTP overhead when > working with CDN), the pull based scheme actually saves peer uplink > resource, since the overlay structure is not �deep�, so each peer just > need to request neighbors about their chunk availability �on demand� (as > long as their neighbor�s capacity is already efficiently utilized) > because it can always fetch from source if it is not happy about the > progress. > Hi if you have the need for a GET_HAVE/GET_CHUNKMAP message we can add that to swift, no problem. A complex problem, however, is to determine when to switch from push to pull based, as capacity at the source will vary depending on the number of peers in the swarm. Did you already design a solution for that? CU, Arno From Martin.Stiemerling@neclab.eu Tue Nov 29 07:34:25 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4359521F8C3D for ; Tue, 29 Nov 2011 07:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjh7U4o9dvSw for ; Tue, 29 Nov 2011 07:34:24 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 970A121F8C3C for ; Tue, 29 Nov 2011 07:34:24 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D0D6E280001C8 for ; Tue, 29 Nov 2011 16:34:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4h4MfKyX-uXg for ; Tue, 29 Nov 2011 16:34:23 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id B5ADD28000085 for ; Tue, 29 Nov 2011 16:34:18 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:34:18 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: A word from the chair about the peer protocol discussion Thread-Index: Acyuqy7rs24inMrETNm3UdypfDd+oQ== Date: Tue, 29 Nov 2011 15:34:17 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] A word from the chair about the peer protocol discussion X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:34:25 -0000 [speaking as PPSP WG chair] Dear all,=20 I have read through the emails about the peer protocol discussion and have = the feeling that the discussions are turning a bit towards pure political d= iscussions.=20 Therefore, I would like to remind my original email in this respect and how= decisions about protocol proposals should be made: "Please state your **technical** opinion about which peer protocol proposal= you would prefer" (Cited from http://www.ietf.org/mail-archive/web/ppsp/current/msg01161.html= ) Another important point: We are hopefully about to select a PPSP peer protocol as basis. This PPSP peer protocol will potentially become the Working Group item and = therefore move under the change control of the WG.=20 The WG item allows the working group to add, change or remove semantics or = syntax form the protocol, given that there is rough consensus.=20 I'm saying this, as I have the feeling that a lot of people fear that prior= work will be lost if we chose a peer protocol based one of the proposals. = However, you can describe technical features by email or as an Internet dra= ft and suggest adding this feature to the peer protocol.=20 Kind regards, Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From Martin.Stiemerling@neclab.eu Tue Nov 29 07:38:33 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB90621F87E2 for ; Tue, 29 Nov 2011 07:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.917 X-Spam-Level: X-Spam-Status: No, score=-97.917 tagged_above=-999 required=5 tests=[AWL=-4.681, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_MILLIONSOF=0.315, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbvqjfwetzwK for ; Tue, 29 Nov 2011 07:38:33 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B86EA21F86EE for ; Tue, 29 Nov 2011 07:38:32 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0B13128000085; Tue, 29 Nov 2011 16:38:32 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47xxb0h58B5P; Tue, 29 Nov 2011 16:38:31 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E1D96280001C4; Tue, 29 Nov 2011 16:38:16 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:38:16 +0100 From: Martin Stiemerling To: "Y. R. Yang" , "Yingjie Gu(yingjie)" Thread-Topic: =?gb2312?B?W3Bwc3BdILTwuLQ6ICBTZWxlY3Rpb24gb2YgUFBTUCBwZWVyIHByb3RvY29s?= =?gb2312?Q?_draft?= Thread-Index: AQHMrqAZ0KHyHFg8m0q6bH/lt1gcJ5XD+61g Date: Tue, 29 Nov 2011 15:38:15 +0000 Message-ID: References: <00ab01ccae96$97f0cd50$c7d267f0$@com> <16E4764B-EADF-4289-BA61-9A417B1DAF70@cs.yale.edu> In-Reply-To: <16E4764B-EADF-4289-BA61-9A417B1DAF70@cs.yale.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?gb2312?b?tPC4tDogIFNlbGVjdGlvbiBvZiBQUFNQIHBlZXIgcHJv?= =?gb2312?b?dG9jb2wgZHJhZnQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:38:34 -0000 W3NwZWFraW5nIGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IgYW5kIG5vdCBhcyBjaGFpciBvZiB0 aGUgUFBTUCBXR10NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFku IFIuIFlhbmcgW21haWx0bzp5cnlAY3MueWFsZS5lZHVdDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDI5LCAyMDExIDM6MDggUE0NCj4gVG86IFlpbmdqaWUgR3UoeWluZ2ppZSkNCj4gQ2M6IE1h cnRpbiBTdGllbWVybGluZzsgcHBzcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Bwc3BdILTw uLQ6IFNlbGVjdGlvbiBvZiBQUFNQIHBlZXIgcHJvdG9jb2wgZHJhZnQNCj4gDQo+IA0KPiANCj4g T24gTm92IDI5LCAyMDExLCBhdCA3OjU4IEFNLCAiWWluZ2ppZSBHdSh5aW5namllKSIgPGd1eWlu Z2ppZUBodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gDQo+ID4gSSB3b3VsZCBsaWtlIHRvIHJlY2Fs bCB0aGUgaGlzdG9yeSBvZiBwZWVyIHByb3RvY29sLg0KPiA+IFdlIGJlZ2FuIHRvIHByb3Bvc2Ug VHJhY2tlciBhbmQgUGVlciBwcm90b2NvbCBhdCBlYXJseSAyMDEwLiBTaW5jZSB0aGUgdmVyeQ0K PiBiZWdpbm5pbmcsIHdlIGJlbGlldmUgdGhhdCBQZWVyIHByb3RvY29sIHNob3VsZCBiZSBjb25z aXN0ZW50IHdpdGggVHJhY2tlcg0KPiBQcm90b2NvbC4gQnkgY29uc2lzdGVuY2UsIEkgZG9uJ3Qg bWVhbiB0aGF0IHRoZXkgY2FuIGNvLWV4aXN0LCBpbnN0ZWFkIHRoZXkNCj4gc2hvdWxkIHNoYXJl IHRoZSBzaW1pbGFyIHBoaWxvc29waHkgYW5kIHNob3VsZCBiZSBhYmxlIHRvIGludGVyb3BlcmF0 ZS4gIFRoYXQncw0KPiB3aHkgd2UgY2FsbCB0aGVtIGEgc3lzdGVtLCBub3QgdHdvIHNpbmdsZSBw cm90b2NvbHMuDQo+ID4NCj4gPiBQUFNQIGhhZCBzcGVudCBhIGxvdCBvZiB0aW1lIG9uIGRpc2N1 c3Npb24gb24gd2hldGhlciB0aGUgUFBTUCBzdGFuZGFyZHMNCj4gc2hvdWxkIHVzZSBUcmFja2Vy LWJhc2VkIG9yIEZ1bGwtbWVzaCBhcmNoaXRlY3R1cmUgKGZpbmFsbHksIFdHIGdvdCBjb25zZW5z dXMNCj4gb24gdHJhY2tlci1iYXNlZCksIGFuZCBob3cgdGhlIFRyYWNrZXIgYW5kIFBlZXIgcHJv dG9jb2wgc2hvdWxkIHdvcmssIHdoaWNoIGlzDQo+IGluIHRoZSBSZXF1aXJlbWVudHMgZHJhZnQu IFdlIGFsd2F5cyByZWdhcmRzIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgYXMgYQ0KPiBndWlkYW5j ZSBvbiBUcmFja2VyIGFuZCBwZWVyIHByb3RvY29sLiBCYXNlZCBvbiB0aGUgcmVxdWlyZW1lbnRz IGRyYWZ0LCB3ZQ0KPiBwcm9wb3NlZCBkcmFmdC1ndS1wcHNwLXRyYWNrZXItcHJvdG9jb2wgYW5k IHBlZXItcHJvdG9jb2wuDQo+ID4NCj4gPiBUaGUgV0cgaGFzIHNwZW50IGEgbG90IG9mIGVmZm9y dCBvbiBQUFNQIFN1cnZleSwgYmVjYXVzZSB3ZSB3YW50IHRvIGV4dHJhY3QNCj4gY29tbW9uIGZl YXR1cmVzIG9uIGN1cnJlbnQgUFBTUCBzeXN0ZW0sIGluc3RlYWQgb2YgYmFzZSBvbiBhIHNpbmds ZSBwcml2YXRlDQo+IHByb3RvY29sLg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0IFN3aWZ0IHdvcmtz LCBhbmQgaXQgaXMgYSByZXNlYXJjaCBwcm9qZWN0IHN1cHBvcnRlZCBieSBtYW55DQo+IHJlc2Vh cmNoIGdyb3VwcywgYW5kIEkgdGhpbmsgdGhvc2Ugc2hvdyBzdXBwb3J0IGZvciBzd2lmdCBhcmUg bW9zdGx5IGludm9sdmVkIGluDQo+IFNXSUZUIHByb2plY3QuDQo+ID4gSXQgd2lsbCBiZSBlYXNp ZXIgZm9yIFBQU1AgdG8gZ2V0IHRvIGFuIFJGQyBwdWJsaXNoZWQgaWYgd2UgZGVmaW5pbmcgYSBw cm90b2NvbA0KPiBiYXNlZCBvbiBhIG1hdHVyZSBwcml2YXRlIHByb3RvY29sLiBCdXQgd2hhdCBh Ym91dCBvdGhlciBwcml2YXRlIHByb3RvY29scz8NCj4gQU5ZIE9ORSBvZiB0aGUgcHJvdG9jb2xz IGludHJvZHVjZWQgaW4gU3VydmV5IGRyYWZ0IGNhbiB3b3JrIHdlbGwgYW5kIG1vc3Qgb2YNCj4g dGhlbSBoYXZlIG11Y2ggaHVnZSBudW1iZXIgb2YgdXNlcnMgdGhhbiBTV0lGVCwgYW5kIGV2ZW4g bXVjaCBiZXR0ZXINCj4gcGVyZm9ybWFuY2UuIFNoYWxsIHdlIHRha2UgdGhlbSBpbnRvIGNvbnNp ZGVyYXRpb24/DQo+ID4NCj4gPiBJIGhhdGUgdG8gbWFrZSB0aGlzIHNlbGVjdGlvbiBhcyBhbiBh dHRhY2sgb24gZWFjaCBvdGhlciBkcmFmdC4gQW5kIEkgaG9wZQ0KPiB0aG9zZSBmcm9tIFNXSUZU IHdvbid0IGxvb2sgYXQgbXkgZW1haWwgYXMgYW4gYXR0YWNrIHRvIHRoZWlyIHByb3RvY29scy4g SSBqdXN0DQo+IHdvbmRlciB3aGF0IGRvZXMgUFBTUCBXRyB3YW50LCBhIG1hdHVyZSBwcml2YXRl IHByb3RvY29sIG9yIGEgZGV2ZWxvcGluZw0KPiBwcm90b2NvbHMgYmFzZWQgb24gd2lkZWx5IHN1 cnZleT8NCj4gDQo+IEkgd291bGQgbGlrZSB0byBzZWNvbmQgWWluZ2ppZSdzIHF1ZXN0aW9uLiBJ dCBpcyBpbXBvcnRhbnQgdG8gZGlzY3VzcyB0aGUgb2JqZWN0aXZlDQo+IGZpcnN0LiBUaGVyZSBh cmUgaW5kZWVkIG90aGVyIG9wdGlvbnMsIGUuZy4sIGJhc2VkIG9uIHJldmVyc2UgZW5naW5lZXJp bmcsIHBwc3ANCj4gY291bGQgdXNlIGFzIGEgYmFzZSBvbmUgb2YgdGhvc2UgZXh0cmVtZWx5IHdp ZGVseSBkZXBsb3llZCAod2l0aCB0ZW5zIG9mDQo+IG1pbGxpb25zIG9mIHJlYWwgdXNlcnMpIHBy b3RvY29scywgYXMgbG9uZyBhcyB0aGVyZSBpcyBubyBJUCBpc3N1ZS4NCg0KVGhpcyB3aWxsIGVm ZmVjdGl2ZWx5IHBvc3Rwb25lIHRoZSBQUFNQIHBlZXIgcHJvdG9jb2wgdW50aWwgaW5maW5pdHku IA0KDQpXZSBoYXZlIGFncmVlZCBpbiB0aGUgV0cgdG8gbWFrZSBhIGRlY2lzaW9uIGZvciBhIHBl ZXIgcHJvdG9jb2wgYXJvdW5kIHRoZSBJRVRGLTgyIG1lZXRpbmcsIGJhc2VkIG9uIHRoZSBwcm9w b3NhbHMgYXZhaWxhYmxlIGF0IHRoaXMgdGltZS4gDQoNCj4gDQo+IFByb3RvY29sIGRlc2lnbiBp cyBub3QgYW4gb3B0aW1pemF0aW9uIHByb2JsZW0sIGkuZS4sIHBpY2sgdGhlIG9wdGltYWwgcHJv dG9jb2wuDQo+IFNvIHdoYXQgaXMgdGhlIGdvYWwgb2YgcHBzcD8gSWYgdGltZSBpcyB0aGUgZXNz ZW5jZSBhbmQgdGhlIGdvYWwgaXMgdG8gaGF2ZSBhIHBlZXINCj4gcHJvdG9jb2wgY29taW5nIG91 dCBvZiBJRVRGIHF1aWNrbHksIHRoZW4gc3dpZnQgY2FuIGJlIGEgc3RhcnRpbmcgYmFzZS4NCg0K SSBwZXJzb25hbGx5IHdhbnQgYSBwcm90b2NvbCB0aGF0IEkgY2FuIGltcGxlbWVudCBpbiB0aGUg bmV4dCAxMiBtb250aHMuIEFuZCBzd2lmdCBtYWtlcyBtZSBmZWVsIHRoYXQgSSB3aWxsIGJlIGFi bGUgdG8gZG8gdGhpcy4gV2hlbiByZWFkaW5nIGRyYWZ0LWd1LXBwc3AtcGVlci4uLiBJJ20sIG5v dCBzdXJlIHRoYXQgSSB3aWxsIGJlIGFibGUgdG8gaW1wbGVtZW50IHRoaXMgaW4gdGhlIG5leHQg MTIgbW9udGhzLiBGb3IgaW5zdGFuY2UsIHdoZXJlIGlzIHRoZSBzdGFydCBvZiB0aGUgc3RhdGUg bWFjaGluZSBpbiB0aGUgZHJhZnQ/Pw0KDQogIE1hcnRpbg0KDQo+IFRhbmVuYmF1bSB0YWxrZWQg YWJvdXQgdGhlIHRpbWluZyBvZiBzdGFuZGFyZGl6YXRpb24gYmFzZWQgb24gYSBjYW1lbCBzaGFw ZS4NCj4gSSBmZWVsIHRoYXQgcDJwIHN0cmVhbWluZyBpcyBhbHJlYWR5IGF0IHRoZSBsb3dlciBo YWxmIG9mIHRoZSBib2R5LCBpLmUuLCBtYW55DQo+IGNvbW1lcmNpYWwgcHJvdG9jb2xzIGFscmVh ZHkgZXhpc3QuIEkgYW0gd29uZGVyaW5nIG9uIHRoZSBvcGluaW9ucyBvZiB0aGUNCj4gY2hhaXJz IGFuZCBvdGhlciBzZWFzb25lZCBJRVRGcyBvbiBhbiBhcHByb2FjaCB0aGF0IFBQU1AgY291bGQg dGFrZSwgdG8gbWFrZQ0KPiBhIGRpZmZlcmVuY2UuIEkgdW5kZXJzdGFuZCB0aGF0IG1hbnkgd2Fu dCB0byBkaXNjdXNzIHRoZSBzcGVjaWZpYyB0ZWNobmljYWwNCj4gZGV0YWlscywgYnV0IHRoZW4g SSBzZWUgZW5kbGVzcyBkZWJhdGVzLg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gUmljaGFyZA0KPiAN Cj4gPg0KPiA+IEkgYWdyZWUgd2l0aCBDcnV6J3Mgb3Bpbmlvbi4gVGhpcyBpcyBub3QgYSBzZWxl Y3Rpb24gb2YgZHJhZnQsIHdlIGhhdmUgbW9yZSB0aGFuDQo+IG9uZSBvcHRpb24uDQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPg0KPiA+IEJlc3QgUmVnYXJkcw0KPiA+IEd1IFlpbmdqaWUNCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g cHBzcCBtYWlsaW5nIGxpc3QNCj4gPiBwcHNwQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNwDQoNCm1hcnRpbi5zdGllbWVybGluZ0BuZWNsYWIu ZXUNCg0KTkVDIExhYm9yYXRvcmllcyBFdXJvcGUgLSBOZXR3b3JrIFJlc2VhcmNoIERpdmlzaW9u IE5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmlj dG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0 DQo= From Martin.Stiemerling@neclab.eu Tue Nov 29 07:41:26 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B47F421F8C60 for ; Tue, 29 Nov 2011 07:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.295 X-Spam-Level: X-Spam-Status: No, score=-97.295 tagged_above=-999 required=5 tests=[AWL=-3.744, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuQLKzBgPcTO for ; Tue, 29 Nov 2011 07:41:26 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 946BF21F8C57 for ; Tue, 29 Nov 2011 07:41:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D7E60280001C4; Tue, 29 Nov 2011 16:41:24 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naA6QPxDIEH0; Tue, 29 Nov 2011 16:41:24 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id B4E9128000085; Tue, 29 Nov 2011 16:41:09 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:41:09 +0100 From: Martin Stiemerling To: "Y. R. Yang" , "Yingjie Gu(yingjie)" Thread-Topic: =?gb2312?B?W3Bwc3BdILTwuLQ6ICBTZWxlY3Rpb24gb2YgUFBTUCBwZWVyIHByb3RvY29s?= =?gb2312?Q?_draft?= Thread-Index: AQHMrqAZ0KHyHFg8m0q6bH/lt1gcJ5XD/Jyw Date: Tue, 29 Nov 2011 15:41:08 +0000 Message-ID: References: <00ab01ccae96$97f0cd50$c7d267f0$@com> <16E4764B-EADF-4289-BA61-9A417B1DAF70@cs.yale.edu> In-Reply-To: <16E4764B-EADF-4289-BA61-9A417B1DAF70@cs.yale.edu> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?gb2312?b?tPC4tDogIFNlbGVjdGlvbiBvZiBQUFNQIHBlZXIgcHJv?= =?gb2312?b?dG9jb2wgZHJhZnQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:41:26 -0000 W3NwZWFraW5nIGFzIFBQU1AgV0cgY2hhaXJdDQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFkuIFIuIFlhbmcgW21haWx0bzp5cnlAY3MueWFsZS5lZHVdDQo+IFNl bnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI5LCAyMDExIDM6MDggUE0NCj4gVG86IFlpbmdqaWUgR3Uo eWluZ2ppZSkNCj4gQ2M6IE1hcnRpbiBTdGllbWVybGluZzsgcHBzcEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3Bwc3BdILTwuLQ6IFNlbGVjdGlvbiBvZiBQUFNQIHBlZXIgcHJvdG9jb2wgZHJh ZnQNCj4gDQoNClsuLi5dDQoNCj4gDQo+IFByb3RvY29sIGRlc2lnbiBpcyBub3QgYW4gb3B0aW1p emF0aW9uIHByb2JsZW0sIGkuZS4sIHBpY2sgdGhlIG9wdGltYWwgcHJvdG9jb2wuDQo+IFNvIHdo YXQgaXMgdGhlIGdvYWwgb2YgcHBzcD8gSWYgdGltZSBpcyB0aGUgZXNzZW5jZSBhbmQgdGhlIGdv YWwgaXMgdG8gaGF2ZSBhIHBlZXINCj4gcHJvdG9jb2wgY29taW5nIG91dCBvZiBJRVRGIHF1aWNr bHksIHRoZW4gc3dpZnQgY2FuIGJlIGEgc3RhcnRpbmcgYmFzZS4NCj4gVGFuZW5iYXVtIHRhbGtl ZCBhYm91dCB0aGUgdGltaW5nIG9mIHN0YW5kYXJkaXphdGlvbiBiYXNlZCBvbiBhIGNhbWVsIHNo YXBlLg0KPiBJIGZlZWwgdGhhdCBwMnAgc3RyZWFtaW5nIGlzIGFscmVhZHkgYXQgdGhlIGxvd2Vy IGhhbGYgb2YgdGhlIGJvZHksIGkuZS4sIG1hbnkNCj4gY29tbWVyY2lhbCBwcm90b2NvbHMgYWxy ZWFkeSBleGlzdC4gSSBhbSB3b25kZXJpbmcgb24gdGhlIG9waW5pb25zIG9mIHRoZQ0KPiBjaGFp cnMgYW5kIG90aGVyIHNlYXNvbmVkIElFVEZzIG9uIGFuIGFwcHJvYWNoIHRoYXQgUFBTUCBjb3Vs ZCB0YWtlLCB0byBtYWtlDQo+IGEgZGlmZmVyZW5jZS4gSSB1bmRlcnN0YW5kIHRoYXQgbWFueSB3 YW50IHRvIGRpc2N1c3MgdGhlIHNwZWNpZmljIHRlY2huaWNhbA0KPiBkZXRhaWxzLCBidXQgdGhl biBJIHNlZSBlbmRsZXNzIGRlYmF0ZXMuDQoNClRoZSB3b3JrIGluIHRoZSBJRVRGIGlzIHByb2dy ZXNzZWQgYWJvdXQgdGVjaG5pY2FsIGRpc2N1c3Npb25zLCBzaW5jZSB3ZSBhcmUgZW5naW5lZXJz LiBEaXNjdXNzaW9ucyBhYm91dCBjb21tZXJjaWFsIHZpYWJpbGl0eSBhcmUgb3V0c2lkZSBvZiB0 aGUgc2NvcGUgb2YgdGhlIElFVEYuIFRoZXJlIGlzIGFuIG9sZCBzYXlpbmcgaW4gdGhlIElFVEYg IkxldCB0aGUgbWFya2V0IGRlY2lkZSIuIA0KDQpXaXRoIHJlc3BlY3QgdG8gVGFuZW5iYXVtIGFu ZCBDYW1lbHM6IEknbSBub3Qgc3VyZSBpbiB3aGF0IHN0YWdlIHAycCBzdHJlYW1pbmcgaXMuIEkg a25vdyB0aGF0IHdlIGFyZSBoZXJlIHRvIHN0YW5kYXJkaXplIFBQU1AgYW5kIHRoYXQgd2UgYXJl IHN1cHBvc2VkIHRvIGdldCBpdCBkb25lIGluIGEgcmVhc29uYWJsZSB0aW1lIGZyYW1lLiANCg0K ICBNYXJ0aW4NCg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gUmljaGFyZA0KPiANCj4gPg0KPiA+IEkg YWdyZWUgd2l0aCBDcnV6J3Mgb3Bpbmlvbi4gVGhpcyBpcyBub3QgYSBzZWxlY3Rpb24gb2YgZHJh ZnQsIHdlIGhhdmUgbW9yZSB0aGFuDQo+IG9uZSBvcHRpb24uDQo+ID4NCj4gPg0KPiA+DQo+ID4N Cj4gPg0KPiA+IEJlc3QgUmVnYXJkcw0KPiA+IEd1IFlpbmdqaWUNCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gcHBzcCBtYWlsaW5n IGxpc3QNCj4gPiBwcHNwQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9wcHNwDQoNCm1hcnRpbi5zdGllbWVybGluZ0BuZWNsYWIuZXUNCg0KTkVDIExh Ym9yYXRvcmllcyBFdXJvcGUgLSBOZXR3b3JrIFJlc2VhcmNoIERpdmlzaW9uIE5FQyBFdXJvcGUg TGltaXRlZCB8IFJlZ2lzdGVyZWQgT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwg TG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo= From Martin.Stiemerling@neclab.eu Tue Nov 29 07:54:29 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DFB1F0C54; Tue, 29 Nov 2011 07:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.827 X-Spam-Level: X-Spam-Status: No, score=-99.827 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001, SUSPICIOUS_RECIPS=2.912, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1H5JpoK61WG; Tue, 29 Nov 2011 07:54:27 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B2BE521F8C09; Tue, 29 Nov 2011 07:54:23 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 06AFF28000085; Tue, 29 Nov 2011 16:54:23 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmGSRYMO7vem; Tue, 29 Nov 2011 16:54:22 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C45D728000082; Tue, 29 Nov 2011 16:53:57 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:53:57 +0100 From: Martin Stiemerling To: Rui Cruz Thread-Topic: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt Thread-Index: AQHMoWZrls5Ehw8wWEiQVWXTbNCVMZXEGGxQ Date: Tue, 29 Nov 2011 15:53:56 +0000 Message-ID: References: <203D03ED-A024-4403-AE8B-B02FF58F5550@ieee-pt.org> In-Reply-To: <203D03ED-A024-4403-AE8B-B02FF58F5550@ieee-pt.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91463Polydeucesoffic_" MIME-Version: 1.0 Cc: Rui Cruz , "ppsp@ietf.org" , "ppsp-bounces@ietf.org" Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-peer-protocol-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:54:29 -0000 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91463Polydeucesoffic_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W3NwZWFraW5nIGFzIGluZGl2aWR1YWwgY29udHJpYnV0b3IgYW5kIG5vdCBhcyBjaGFpciBvZiB0 aGUgUFBTUCBXR10NCg0KSGkgUnVpLA0KDQoNCkZyb206IFJ1aSBDcnV6IFttYWlsdG86cnVpLmNy dXpAaWVlZS1wdC5vcmddDQpTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgMTIsIDIwMTEgNzoxMSBQ TQ0KVG86IE1hcnRpbiBTdGllbWVybGluZw0KQ2M6IFJ1aSBDcnV6OyBsaS5saWNodW4xQHp0ZS5j b20uY247IHBwc3BAaWV0Zi5vcmc7IHBwc3AtYm91bmNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtwcHNwXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWd1LXBwc3AtcGVlci1w cm90b2NvbC0wMy50eHQNCg0KSGkgTWFydGluLA0Kc2VlIG15IGNvbW1lbnRzIGlubGluZS4NCkN1 bXByaW1lbnRvcy9SZWdhcmRzLA0KUnVpIENydXoNCg0KU2VudCBmcm9tIG15IGlQYWQyDQoNCk9u IDA5LzExLzIwMTEsIGF0IDE1OjM2LCBNYXJ0aW4gU3RpZW1lcmxpbmcgPE1hcnRpbi5TdGllbWVy bGluZ0BuZWNsYWIuZXU8bWFpbHRvOk1hcnRpbi5TdGllbWVybGluZ0BuZWNsYWIuZXU+PiB3cm90 ZToNCltTcGVha2luZyBhcyBpbmRpdmlkdWFsXQ0KSGkgYWxsLA0KDQpJIGd1ZXNzIEhUVFAgaXMg b25seSBkZWZpbmVkIHRvIHJ1biBvdmVyIFRDUCBhbmQgbm90IG92ZXIgVURQIGZvciB2YXJpb3Vz IHJlYXNvbnMsIGUuZy4sDQoNCi0gICAgICAgICAgSFRUUCBtZXNzYWdlcyBleGNlZWQgdGhlIHNp emUgb2YgYW4gVURQIGRhdGFncmFtLCBleGNlcHQgaW4gc29tZSBjb3JuZXIgY2FzZXM7DQoNCi0g ICAgICAgICAgVGhlcmUgaXMgbm8gcmVsaWFibGUgdHJhbnNwb3J0LCBmbG93IGFuZCBjb25nZXN0 aW9uIGNvbnRyb2wgaW4gVURQOw0KDQotICAgICAgICAgIEEgSFRUUCBHRVQgY2FuIHJlc3VsdCBp biBhIHZlcnkgbGFyZ2UgMjAwIE9LIG1lc3NhZ2UuDQoNClRoaXMgZGVmaW5pdGVseSBydWxlcyBv dXQgSFRUUCBvdmVyIFVEUC4NCg0KV2VsbCwgVVBuUCB1c2VzIEhUVFAgb3ZlciBVRFAgaW4gZGlz Y292ZXJ5IG1lc3NhZ2VzLg0KDQpUcnVlLCBhbmQgdGhpcyBpcyBub3QgdGhlIHN0YW5kYXJkaXpl ZCB3YXkgb2YgSFRUUCwgYnV0IGEgaGFjayBpbiB1cG5wLg0KDQpVc2luZyBIVFRQL1hNTCBlbmNv ZGluZyBmb3Igc2lnbmFsaW5nLCByZXN1bHRzIG1vc3RseSBpbiBzbWFsbCBzaXplZCBtZXNzYWdl cywgYXMgdGhlIG1haW4gaW5mb3JtYXRpb24gaXMgaW4gdGhlIGJvZHkgYW5kIG5vdCBpbiB0aGUg cmVzb3VyY2UgYW5kIGhlYWRlciwgYW5kIHRoZSB0b3RhbCBpcyB0eXBpY2FsbHkgc21hbGxlciB0 aGFuIHRoZSBzaXplIG9mIGEgVURQIGRhdGFncmFtLg0KDQpIVFRQIGlzIG5vdCBhbiBlbmNvZGlu ZyBzY2hlbWUuDQpIVFRQIGhlYWRlcnMgYXJlIHN0aWxsIHRoZXJlLCBldmVuIHRob3VnaCB5b3Ug anVzdCBzZW5kIGEgc2luZ2xlIGJpdCBpbiB0aGUgZW50aXR5IGJvZHkgb2YgdGhlIEhUVFAgbWVz c2FnZS4NClRoZXJlIGlzIG5vdGhpbmcgaW4gSFRUUCB3aGljaCBwcmV2ZW50cyBzZW5kaW5nIEhU VFAgbWVzc2FnZXMgd2hpY2ggYXJlIGxhcmdlciB0aGFuIGEgVURQIGRhdGFncmFtLiBQbGVhc2Ug bm90ZSBhbHNvIHRoYXQgdGhlIG1pbmltYWwgcmVxdWlyZW1lbnQgZm9yIHRoZSBNVFUgb2YgSVB2 NCBpcyDigJxFdmVyeSBpbnRlcm5ldCBtb2R1bGUgbXVzdCBiZSBhYmxlIHRvIGZvcndhcmQgYSBk YXRhZ3JhbSBvZiA2OA0KICAgIG9jdGV0cyB3aXRob3V0IGZ1cnRoZXIgZnJhZ21lbnRhdGlvbuKA nSBSRkMgNzkxLg0KSSBrbm93IHRoYXQgdGhlIGxpbmtzIHRvZGF5IGhhdmUgbGFyZ2VyIE1UVXMs IGJ1dCB0aGlzIHJhaXNlcyB0aGUgcG9pbnQgd2hhdCB0aGUgYXNzdW1wdGlvbiBvZiB0aGUgTVRV IG9uIGEgcGF0aCBpcyBhbmQgaG93IHRoaXMgaW1wYWN0cyB0aGUgYXNzdW1wdGlvbiBhYm91dCB0 aGUgc2l6ZSBvZiBhbiBVRFAgZGF0YWdyYW3igKYNCg0KQWJvdXQgcmVsaWFiaWxpdHkgYW5kIGNv bmdlc3Rpb24gY29udHJvbCwgdGhhdCBpcyBjb3JyZWN0LCB0aGVyZWZvcmUgdGhlIHByZWZlcmVu Y2Ugb24gdXNpbmcgVENQIHdoZW4gcmVsaWFiaWxpdHkgaXMgcmVxdWlyZWQuDQoNCkkgZG8gbm90 IHNlZSB0aGF0IHdlIG5lZWQgcmVsaWFibGUgdHJhbnNwb3J0IG9mIGNodW5rcyBiZXR3ZWVuIHR3 byBwZWVycywgYnV0IHdlIG5lZWQgY29uZ2VzdGlvbiBjb250cm9sLg0KDQpUaGUgcHJvdG9jb2wg d2UgZGVzaWduZWQgdXNlcyBQT1NUIG1lc3NhZ2VzIGZvciByZXF1ZXN0cyBhbmQgdGFrZXMgYWR2 YW50YWdlIG9mIGdldHRpbmcgdGhlIHJlcGxpZXMgd2l0aCB0aGUgcmVxdWVzdGVkIGRhdGEgYXMg cGF5bG9hZCBvbiB0aGUgYm9keSBvZiAyMDAgT0suIFRoZSByZXBseSB3b3VsZCBoYXZlIHRvIGJl IHRyYW5zcG9ydGVkIGFueXdheSwgc28gd2h5IG5vdCBvbiB0aGUgYm9keSBvZiBhIDIwMCBPSz8N Cg0KDQoNClRvIGJlIGhvbmVzdGx5LCBJ4oCZbSBwdXp6bGVkIHdoeSBIVFRQIHNob3VsZCB0aGUg Y2hvaWNlIGZvciB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIHBlZXJzPyBJdCBpczoNCg0KLSAg ICAgICAgICBhIGNsaWVudCBzZXJ2ZXIgcHJvdG9jb2wsIHRob3VnaCB3ZSBuZWVkIGEgYmlkaXJl Y3Rpb25hbCBwcm90b2NvbCB3aGljaCBubyBjbGVhciBjbGllbnQgYW5kIHNlcnZlciByb2xlcy4g RXh0ZW5zaW9ucyB0byBIVFRQIHRvIGxldCBzZXJ2ZXJzIHNlbmQgYXN5bmNocm9ub3VzIG1lc3Nh Z2VzIGFyZSBvbiB0aGUgd2F5LCBzZWUgdGhlIEJpRGlyZWN0aW9uYWwgb3IgU2VydmVyLUluaXRp YXRlZCBIVFRQIChoeWJpKSB3b3JraW5nIGdyb3VwIChodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvd2cvaHliaS9jaGFydGVyLykuIEhvd2V2ZXIsIHRoaXMgaXMgbm90IHlldCBmaW5pc2hlZDsN Cg0KLSAgICAgICAgICBpdCBoYXMgYSBjb25zaWRlcmFibGUgb3ZlcmhlYWQgY2F1c2VkIGJ5IHRo ZSBIVFRQIGhlYWRlcnMgb24gdGhlIHdpcmUsIGNvbXBhcmVkIHRvIHRoZSBtZXNzYWdlIGNvbnRl bnQgKGUuZy4sIGNodW5rIG1hcHMpOyBBIGdvb2QgZXhhbXBsZSBpcyBnb29nbGXigJlzIHdvcmsg b24gc3BkeSwgd2hpY2ggaGFzIHRoZSBnb2FsIHRvIHJlZHVjZSB0aGUgSFRUUCBoZWFkZXJzLiBT ZWUgdGhpcyBsaW5rIChodHRwOi8vZGV2LmNocm9taXVtLm9yZy9zcGR5L3NwZHktd2hpdGVwYXBl cik6IOKAnFVuY29tcHJlc3NlZCByZXF1ZXN0IGFuZCByZXNwb25zZSBoZWFkZXJzLiBSZXF1ZXN0 IGhlYWRlcnMgdG9kYXkgdmFyeSBpbiBzaXplIGZyb20gfjIwMCBieXRlcyB0byBvdmVyIDJLQi7i gJ07DQoNCi0gICAgICAgICAgaXQgaGFzIGEgY29uc2lkZXJhYmxlIG92ZXJoZWFkIHdoZW4gaW1w bGVtZW50aW5nIGl0LCBlLmcuLCBjb2RlIHNpemUuIEkga25vdyB0aGF0IG1hbnkgcDJwIGNsaWVu dHMgaGF2ZSBhIEhUVFAgc3RhY2ssIGJ1dCBpdCBzaG91bGQgbm90IGJlIG1hbmRhdG9yeSB0byBp bXBsZW1lbnQgSU1PLg0KDQpJIHdvdWxkIHNheSB0aGF0IEhUVFAgaXMgYSByZXF1ZXN0L3JlcGx5 IHByb3RvY29sIGJldHdlZW4gaG9zdHMuIEFueXdheSwgZm9yIGEgU3RyZWFtaW5nIGVudmlyb25t ZW50LCB3aGF0IGEgbWVkaWEgUGxheWVyIGludGVyZmFjZXMgaXMgd2l0aCAic3RyZWFtaW5nIHNl cnZlciBub2RlcyIsIGFuZCBzbywgd2UgbWF5IHRoaW5rIG9mIFBlZXJzIGFzIHRoZSBTdHJlYW1p bmcgc2VydmVycyBmb3IgYSBDbGllbnQgTWVkaWEgUGxheWVyLg0KDQpUaGF0IHZpZXcgaXMgY29y cmVjdCwgYnV0IGl0IGNvbmNlcm5zIG9ubHkgdGhlIHZpZXcgYmV0d2VlbiB0aGUgbWVkaWEgY2xp ZW50IGFuZCB0aGUgc2VydmluZyBwZWVycyBmb3IgdGhpcyBtZWRpYSBjbGllbnQuIEl0IGRvZXMg bm90IHJlbGF0ZWQgdG8gdGhlIGludGVybmFscyBvZiB0aGUgcDJwIHByb3RvY29sLg0KDQpTbywg YW55IFBlZXIgaXMgaW4gZmFjdCBhIHByb3ZpZGVyIChzZXJ2ZXIpIGVudGl0eSBmb3Igb3RoZXIg aW50ZXJlc3RlZCBQZWVycywgYnV0IGFsc28gYSBjb25zdW1lciAoY2xpZW50KSBvZiB0aGUgbWVk aWEgYXZhaWxhYmxlIGluIHRoZSBvdGhlciBQZWVycy4NCkNvbnNpZGVyaW5nIHN0cmVhbWluZyBv ZiBzZWdtZW50ZWQgbWVkaWEsIHRoZSBjaHVua3MgaGF2ZSBxdWl0ZSBhIGxhcmdlIHNpemUsIHJh bmdpbmcgZnJvbSBhcyBsb3cgYXMgNUtpQiB0byB+MjAwIEtpQiAodHlwaWNhbCBpbiBzY2FsYWJs ZSBjb2RpbmcpIGZvciBtZWRpYSBjaHVuayBwbGF5b3V0IGR1cmF0aW9uIG9mIH4yIHNlY29uZHMg KGZvciBIaWdoIFF1YWxpdHkgdmlkZW9zKS4gVGhlIEhUVFAgaGVhZGVyIHNpemUgKGFuZCByZXF1 ZXN0IGJvZHkpICBpcyB0aGVuIGNvbXBhcmF0aXZlbHkgc21hbGwuDQoNCldoYXQgaWYgSSBkZWNp ZGUgdG8gZ28gZm9yIDEgS2lsb2J5dGUgY2h1bmtzPw0KV2hhdCBpZiBJIGp1c3Qgc2VudCBjaHVu ayBtYXBzIG9yIGFueSBvdGhlciBzaWduYWxpbmcgbWVzc2FnZXMgYmFjayBhbmQgZm9ydGg/DQoN CkFkZGl0aW9uYWxseSwgZm9yIHRoZXNlIG1lZGlhIGNodW5rIHNpemVzICgyMDArIEtpQiksIGEg aGlnaCBxdWFsaXR5IG5vbiBzY2FsYWJsZSB2aWRlbyBuZWVkcyBhcm91bmQgb25lIHJlcXVlc3Qg ZXZlcnkgMiBzZWNvbmRzIChub3QgY29uc2lkZXJpbmcgYW55IHNwZWNpYWwgc3RyYXRlZ3kgZm9y IHBpZWNlIHBpY2tpbmcpLiBUaGlzIGlzIHF1aXRlIGRpZmZlcmVudCBmcm9tIHRoZSB0eXBpY2Fs IGltcGxlbWVudGF0aW9ucyBvZiBzdHJlYW1pbmcgdmlhIEJpdFRvcnJlbnQtbGlrZSB0ZWNobmlx dWVzLCB0aGF0IG5lZWQgYSBxdWl0ZSBsYXJnZSBhbW91bnQgb2YgcmVxdWVzdHMgcGVyIHNlY29u ZCBmb3IgdGhlIHZlcnkgc2FtZSB2aWRlbyBwbGF5b3V0IGR1cmF0aW9uLg0KRm9yIHNjYWxhYmxl IG1lZGlhLCB0aGlzIGlzIGFuIGFkdmFudGFnZSBmb3IgdGhlIHN0cmF0ZWd5IG9mIHJlcXVlc3Rp bmcgdGhlIGxheWVycyBvZiBhIGNodW5rIHVwIHRvIGEgY2VydGFpbiBxdWFsaXR5IChldmVudHVh bGx5IHRoZSBtYXhpbXVtKSBpbiB0aGUgdmVyeSBzYW1lIHRpbWUgd2luZG93LiBBZGRpdGlvbmFs bHksIGFuZCBmb3Igc2NhbGFibGUgbWVkaWEsIHRoZSBwcm9iYWJpbGl0eSBvZiBzbW9vdGggcGxh eW91dCB3aXRob3V0IHJlYnVmZmVyaW5nIGlzIHZlcnkgaGlnaC4NCg0KVGhlIHRyb3VibGUgSSBz ZWUgaXMgdGhhdCB5b3UgaGF2ZSBvbmx5IHlvdXIgc2NlbmFyaW8gaW4gbWluZC4gSeKAmW0gbm90 IHN1cmUgdGhhdCB5b3VyIGFzc3VtcHRpb25zIGhvbGQgdHJ1ZSBpZiB5b3Ugc3dpdGNoIHRvIE1E Qy4NCg0KVGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgZm9yIHRoZSBhZG9wdGlvbiBvZiBIVFRQ IEFkYXB0aXZlIFN0cmVhbWluZyB0ZWNobmlxdWVzIGZyb20gM0dQUCBhbmQgSVNPLCBpbiBzcGVj aWFsIGZvciBtb2JpbGUgZW52aXJvbm1lbnQuIFRoZXJlIGFyZSBhbHJlYWR5IGFwcGxpY2F0aW9u cyBmb3IgTGl2ZSBTdHJlYW1pbmcgdXNpbmcgSFRUUCBmb3Igc21hcnRwaG9uZXMgYW5kIGFUYWJs ZXRzLCBvdmVyIDNHIG9yIFdpLUZpLCBwcm92aWRpbmcgYSBoaWdoIHF1YWxpdHkgb2YgZXhwZXJp ZW5jZSB0byB0aGUgdXNlci4gQW4gZXhhbXBsZSBpcyB0aGUgQmxvb21iZXJnIEFwcCBmb3IgdGhl IGlQYWQuDQoNCkFuZD8gSSBkbyBub3QgZ2V0IHRoZSBwb2ludCB5b3UgdHJ5aW5nIHRvIHJhaXNl Lg0KDQogIE1hcnRpbg0KDQoNCg0KUmV1c2luZyBleGlzdGluZyBwcm90b2NvbHMgaXMgYSBnb29k IGlkZWEsIGJ1dCBJIGhhdmUgdGhlIGZlZWxpbmcgdGhhdCB3ZSBhcmUgc3RyZXRjaGluZyBpdCBh IGJpdCB0b28gbXVjaCBpbiB0aGlzIGNhc2UuDQoNCk15IGZldyBjZW50cw0KDQogIE1hcnRpbg0K DQptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1PG1haWx0bzptYXJ0aW4uc3RpZW1lcmxpbmdA bmVjbGFiLmV1Pg0KDQpORUMgTGFib3JhdG9yaWVzIEV1cm9wZSAtIE5ldHdvcmsgUmVzZWFyY2gg RGl2aXNpb24gTkVDIEV1cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3Vz ZSwgMSBWaWN0b3JpYSBSb2FkLCBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5k IDI4MzIwMTQNCg0KRnJvbTogcHBzcC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpwcHNwLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0 bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgUnVpIENydXoNClNlbnQ6IFR1 ZXNkYXksIE5vdmVtYmVyIDAxLCAyMDExIDI6MzkgUE0NClRvOiBsaS5saWNodW4xQHp0ZS5jb20u Y248bWFpbHRvOmxpLmxpY2h1bjFAenRlLmNvbS5jbj4NCkNjOiBSdWkgQ3J1ejsgcHBzcEBpZXRm Lm9yZzxtYWlsdG86cHBzcEBpZXRmLm9yZz47IHBwc3AtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 cHBzcC1ib3VuY2VzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtwcHNwXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbC0wMy50eHQNCg0KSW5k ZWVkLCBJIHN1cHBvc2Ugbm90aGluZyBwcmV2ZW50cyB1c2luZyBIVFRQL1hNTCBvdmVyIFVEUCwg YXMgbWVzc2FnZXMgdHlwaWNhbGx5IGZpdCBpbiBVRFAgZGF0YWdyYW1zIGFuZCB0aGUgbWV0aG9k cyB1c2VkIGZvciByZXF1ZXN0cyBhcmUgUE9TVC4NCkluIHRoZSBkcmFmdCB0aGUgdHJhbnNwb3J0 IHByb3RvY29sIHRvIGJlIHVzZWQgZm9yIHRoZSBzaWduYWxpbmcgd2FzIG5vdCBzcGVjaWZpZWQg YW5kIGl0IGlzIG9wZW4gdG8gZGlzY3Vzc2lvbi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpCZXN0IFJlZ2FyZHMsDQoNClByb2YuIFJ1aSBTYW50b3MgQ3J1eg0KQ2hhaXJtYW4NCklF RUUgUG9ydHVnYWwgU2VjdGlvbg0KQXYuIFByb2YuIERyLiBBbsOtYmFsIENhdmFjbyBTaWx2YSwg SVNULVRhZ3VzUGFyaywgT2ZmaWNlIDEtNSwgMjc0NC0wMTYgUG9ydG8gU2Fsdm8sIFBvcnR1Z2Fs DQorMzUxIDIxNCAyMzMgMjAwIChleHQgNTA0NCksICszNTEuOTM5IDA2MCA5MzkgKG1vYmlsZSkN CnJ1aS5jcnV6QGllZWUub3JnPHgtbXNnOi8vMTI3L3J1aS5jcnV6QGllZWUub3JnPg0KcnVpLnMu Y3J1ekBpc3QudXRsLnB0PHgtbXNnOi8vMTI3L3J1aS5zLmNydXpAaXN0LnV0bC5wdD4NCnNlYy5w b3J0dWdhbEBpZWVlLm9yZzx4LW1zZzovLzEyNy9zZWMucG9ydHVnYWxAaWVlZS5vcmc+DQp3d3cu aWVlZS1wdC5vcmc8aHR0cDovL3d3dy5pZWVlLXB0Lm9yZy8+DQpBZHZhbmNpbmcgdGVjaG5vbG9n eSBmb3IgaHVtYW5pdHkuDQoNCk9uIDAxLzExLzIwMTEsIGF0IDAxOjU1LCBsaS5saWNodW4xQHp0 ZS5jb20uY248bWFpbHRvOmxpLmxpY2h1bjFAenRlLmNvbS5jbj4gd3JvdGU6DQoNCg0KDQoNCkkg dGhpbmsgWE1MIG92ZXIgVURQIGlzIGFsc28gYSBnb29kIG9wdGlvbi4NCg0KQlINCkxpY2h1bg0K DQoNCnBwc3AtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnPiDl hpnkuo4gMjAxMS0xMS0wMSAwOToyMToyODoNCg0KPiBIaSwNCj4NCj4gV2UgaGF2ZSB1cGRhdGVk IHRoZSBQUFNQIFRyYWNrZXIgUHJvdG9jb2wgZHJhZnQsIGNvcnJlc3BvbmRpbmcgdG8NCj4gdGhl IG1lcmdlIG9mIHRoZSBmb3JtZXIgZHJhZnRzIGZyb20gR3UgYW5kIENydXouDQo+DQo+IFRoaXMg dmVyc2lvbiBtYWlubHkgZm9jdXMgb24gdGhlIG1lc3NhZ2VzIGV4Y2hhbmdlZCBiZXR3ZWVuIHBl ZXJzLA0KPiBidXQgbGVhdmUgdGhlIGVuY29kaW5nIGZvcm1hdCBpbnRvIEFwcGVuZGl4IHNpbmNl IHVzaW5nIGJpbmFyeSBvcg0KPiBIVFRQL1hNTCBhcyBjb250YWluZXIgaXMgc3RpbGwgdW5kZXIg ZGlzcHV0ZS4NCj4NCj4gUGxlYXNlIGxldCB1cyBrbm93IHlvdXIgY29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zLg0KPg0KPiBUaGFua3MuDQo+DQo+IEppbndlaQ0KPg0KPiAtLS0tLemCruS7tuWOn+S7 ti0tLS0tDQo+IOWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+XQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTHlubQx MOaciDMx5pelIDE5OjA0DQo+IOaUtuS7tuS6ujogWGlhamlud2VpDQo+IOaKhOmAgTogWGlhamlu d2VpOyBZaW5namllIEd1KHlpbmdqaWUpOyBtYXJpby5udW5lc0Bpbm92LnB0PG1haWx0bzptYXJp by5udW5lc0Bpbm92LnB0Pjsgam9hby4NCj4gc2lsdmFAaW5vdi5wdDxtYWlsdG86c2lsdmFAaW5v di5wdD47IHJ1aS5jcnV6QGllZWUub3JnPG1haWx0bzpydWkuY3J1ekBpZWVlLm9yZz47IGRicnlh bkBldGhlcm5vdC5vcmc8bWFpbHRvOmRicnlhbkBldGhlcm5vdC5vcmc+DQo+IOS4u+mimDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9jb2wtMDMu dHh0DQo+DQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9j b2wtMDMudHh0IGhhcyBiZWVuDQo+IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmlud2VpIFhp YSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQo+DQo+IEZpbGVuYW1lOiAgICBk cmFmdC1ndS1wcHNwLXBlZXItcHJvdG9jb2wNCj4gUmV2aXNpb246ICAgIDAzDQo+IFRpdGxlOiAg ICAgICBQZWVyIFByb3RvY29sDQo+IENyZWF0aW9uIGRhdGU6ICAgIDIwMTEtMTAtMzENCj4gV0cg SUQ6ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDMxDQo+ DQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIHRoZSBhcmNoaXRlY3R1 cmUgb2YgdGhlIFBQU1AgUGVlciBwcm90b2NvbA0KPiAgICBvdXRsaW5pbmcgdGhlIGZ1bmN0aW9u YWwgZW50aXRpZXMsIG1lc3NhZ2UgZmxvd3MgYW5kIG1lc3NhZ2UNCj4gICAgcHJvY2Vzc2luZyBp bnN0cnVjdGlvbnMsIHdpdGggdGhlIHJlc3BlY3RpdmUgcGFyYW1ldGVycy4gIFRoZSBQUFNQDQo+ ICAgIFBlZXIgUHJvdG9jb2wgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBj YXBhYmlsaXRpZXMgb2YNCj4gICAgUFBTUCB0byBzdXBwb3J0IGFkYXB0aXZlIGFuZCBzY2FsYWJs ZSB2aWRlbyBhbmQgM0QgdmlkZW8sIGZvciBWaWRlbw0KPiAgICBPbiBEZW1hbmQgKFZvRCkgYW5k IExpdmUgdmlkZW8gc2VydmljZXMuICBUaGUgcHJvdG9jb2wgbWVzc2FnZXMNCj4gICAgZm9ybWFs IHN5bnRheCBhbmQgc2VtYW50aWNzLCBtZXRob2RzLCBhbmQgZm9ybWF0cyBhcmUgcHJlc2VudGVk IGZvcg0KPiAgICBib3RoIEJpbmFyeSBhbmQgSFRUUC9YTUwgZW5jb2RlZCBmb3JtYXRzLg0KPg0K Pg0KPg0KPg0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBwcHNwIG1haWxpbmcgbGlzdA0KDQoNCm1hcnRp bi5zdGllbWVybGluZ0BuZWNsYWIuZXUNCg0KTkVDIExhYm9yYXRvcmllcyBFdXJvcGUgLSBOZXR3 b3JrIFJlc2VhcmNoIERpdmlzaW9uIE5FQyBFdXJvcGUgTGltaXRlZCB8IFJlZ2lzdGVyZWQgT2Zm aWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9uIFczIDZCTCB8IFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo= --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91463Polydeucesoffic_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE0Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE0Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxQ0NBRUI3LjdCOEUzRkYwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8bzpEb05vdFJlbHlPbkNTUy8+ DQo8L286T2ZmaWNlRG9jdW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPHc6V29yZERvY3VtZW50Pg0KPHc6Wm9vbT4xMTA8L3c6Wm9vbT4N Cjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OkdyYW1tYXJTdGF0 ZT5DbGVhbjwvdzpHcmFtbWFyU3RhdGU+DQo8dzpUcmFja01vdmVzLz4NCjx3OlRyYWNrRm9ybWF0 dGluZy8+DQo8dzpFbnZlbG9wZVZpcy8+DQo8dzpWYWxpZGF0ZUFnYWluc3RTY2hlbWFzLz4NCjx3 OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4NCjx3Oklnbm9yZU1p eGVkQ29udGVudD5mYWxzZTwvdzpJZ25vcmVNaXhlZENvbnRlbnQ+DQo8dzpBbHdheXNTaG93UGxh Y2Vob2xkZXJUZXh0PmZhbHNlPC93OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+DQo8dzpEb05v dFByb21vdGVRRi8+DQo8dzpMaWRUaGVtZU90aGVyPkVOLVVTPC93OkxpZFRoZW1lT3RoZXI+DQo8 dzpMaWRUaGVtZUFzaWFuPlgtTk9ORTwvdzpMaWRUaGVtZUFzaWFuPg0KPHc6TGlkVGhlbWVDb21w bGV4U2NyaXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNvbXBsZXhTY3JpcHQ+DQo8dzpDb21wYXRpYmls aXR5Pg0KPHc6RG9Ob3RFeHBhbmRTaGlmdFJldHVybi8+DQo8dzpCcmVha1dyYXBwZWRUYWJsZXMv Pg0KPHc6U3BsaXRQZ0JyZWFrQW5kUGFyYU1hcmsvPg0KPHc6RW5hYmxlT3BlblR5cGVLZXJuaW5n Lz4NCjwvdzpDb21wYXRpYmlsaXR5Pg0KPG06bWF0aFByPg0KPG06bWF0aEZvbnQgbTp2YWw9IkNh bWJyaWEgTWF0aCIvPg0KPG06YnJrQmluIG06dmFsPSJiZWZvcmUiLz4NCjxtOmJya0JpblN1YiBt OnZhbD0iJiM0NTstIi8+DQo8bTpzbWFsbEZyYWMgbTp2YWw9Im9mZiIvPg0KPG06ZGlzcERlZi8+ DQo8bTpsTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpyTWFyZ2luIG06dmFsPSIwIi8+DQo8bTpkZWZK YyBtOnZhbD0iY2VudGVyR3JvdXAiLz4NCjxtOndyYXBJbmRlbnQgbTp2YWw9IjE0NDAiLz4NCjxt OmludExpbSBtOnZhbD0ic3ViU3VwIi8+DQo8bTpuYXJ5TGltIG06dmFsPSJ1bmRPdnIiLz4NCjwv bTptYXRoUHI+PC93OldvcmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPHc6TGF0ZW50U3R5bGVzIERlZkxvY2tlZFN0YXRlPSJmYWxzZSIgRGVm VW5oaWRlV2hlblVzZWQ9InRydWUiIERlZlNlbWlIaWRkZW49InRydWUiIERlZlFGb3JtYXQ9ImZh bHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjI2NyI+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1 ZSIgTmFtZT0iaGVhZGluZyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFk aW5nIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBO YW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcg OSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgTmFtZT0i dG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5h bWU9InRvYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5 IiBOYW1lPSJ0b2MgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIzOSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iMzkiIE5hbWU9InRvYyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzOSIgTmFtZT0idG9jIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9InRvYyA4Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iY2FwdGlv biIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i VGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgTmFt ZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIxMSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN0cm9uZyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iRW1waGFzaXMiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTkiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IlBsYWNlaG9sZGVy IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iTm8gU3BhY2luZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGln aHQgU2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFs c2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJSZXZpc2lvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzNCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg UUZvcm1hdD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAx Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBT ZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRp dW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1l PSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDIiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBTaGFk aW5nIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1l ZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5h bWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNl ZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVX aGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgU2VtaUhpZGRl bj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2Nl bnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQg U2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TGlnaHQgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgU2VtaUhpZGRlbj0iZmFsc2Ui IFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgU2VtaUhp ZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIg U2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIEdy aWQgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iRGFy ayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJD b2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNl IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9 ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5o aWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBTZW1pSGlkZGVuPSJmYWxz ZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1 IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0g TGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY2IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJN ZWRpdW0gTGlzdCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBO YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY4IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZh bHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVz ZWQ9ImZhbHNlIiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRl V2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIFNlbWlIaWRkZW49ImZh bHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIFNlbWlIaWRk ZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNj ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIFNl bWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0IFNoYWRp bmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkxpZ2h0 IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjIiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ikxp Z2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjMiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFs c2UiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVu VXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhp ZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDUiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIFNlbWlIaWRkZW49ImZhbHNl IiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIFNlbWlIaWRkZW49 ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIFNlbWlI aWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9Ik1lZGl1bSBHcmlkIDMg QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAi IFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIE5hbWU9IkRhcmsgTGlz dCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI3MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFt ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxz ZSIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdo ZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlk ZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVu aGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgU2VtaUhpZGRlbj0i ZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2Nl bnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgU2Vt aUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVtIExpc3Qg MSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0iTWVkaXVt IExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NyIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgTmFtZT0i TWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2OCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIg TmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2OSIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5Vc2VkPSJm YWxzZSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgU2VtaUhpZGRlbj0iZmFsc2UiIFVuaGlkZVdoZW5V c2VkPSJmYWxzZSIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBTZW1pSGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hl blVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBTZW1pSGlkZGVuPSJmYWxzZSIg VW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBTZW1pSGlkZGVuPSJm YWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBTZW1pSGlk ZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJT dWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMjEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9 InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzEiIFNlbWlIaWRkZW49ImZhbHNlIiBVbmhpZGVXaGVuVXNlZD0i ZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzIiIFNlbWlIaWRkZW49ImZhbHNlIiBV bmhpZGVXaGVuVXNlZD0iZmFsc2UiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJl bmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBTZW1p SGlkZGVuPSJmYWxzZSIgVW5oaWRlV2hlblVzZWQ9ImZhbHNlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjM3IiBOYW1lPSJCaWJsaW9ncmFwaHkiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iMzkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8L3c6 TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVm aW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9z ZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7DQoJbXNvLWZvbnQtY2hhcnNldDoyOw0KCW1zby1nZW5l cmljLWZvbnQtZmFtaWx5OmF1dG87DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZv bnQtc2lnbmF0dXJlOjAgMjY4NDM1NDU2IDAgMCAtMjE0NzQ4MzY0OCAwO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJ bXNvLWZvbnQtYWx0OuWui+S9kzsNCgltc28tZm9udC1jaGFyc2V0OjEzNDsNCgltc28tZ2VuZXJp Yy1mb250LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250 LXNpZ25hdHVyZTozIDY4MDQ2MDI4OCAyMiAwIDI2MjE0NSAwO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZv bnQtYWx0OuWui+S9kzsNCgltc28tZm9udC1jaGFyc2V0OjEzNDsNCgltc28tZ2VuZXJpYy1mb250 LWZhbWlseTphdXRvOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25h dHVyZTozIDY4MDQ2MDI4OCAyMiAwIDI2MjE0NSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDsNCgltc28tZm9udC1j aGFyc2V0OjA7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7DQoJbXNvLWZvbnQtcGl0 Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5MjkgMTA3Mzc4NjExMSA5 IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7DQoJbXNvLWZvbnQtY2hhcnNldDowOw0KCW1zby1nZW5lcmlj LWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250 LXNpZ25hdHVyZTotNTIwMDgxNjY1IC0xMDczNzE3MTU3IDQxIDAgNjYwNDcgMDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMg MiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTptb2Rl cm47DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi01MjAwOTI5 MjkgMTA3MzgwNjU5MSA5IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBT aW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7DQoJbXNvLWZvbnQtY2hhcnNl dDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6YXV0bzsNCgltc28tZm9udC1waXRjaDp2 YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6MyA2ODA0NjAyODggMjIgMCAyNjIxNDUgMDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1xZm9ybWF0Onll czsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2luZ2xlO30NCnByZQ0KCXttc28tc3R5bGUtbm9z aG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OlNpbVN1bjsNCgltc28tYmlkaS1mb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnR0DQoJe21zby1zdHlsZS1ub3Nob3c6eWVz Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250LWZhbWlseTpTaW1TdW47DQoJbXNvLWFz Y2lpLWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpTaW1TdW47 DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OlNpbVN1bjsNCgltc28tYmlkaS1mb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBtbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6 ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVh c3QtZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJbXNv LXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1hcmdpbi10b3A6MG1tOw0KCW1hcmdpbi1yaWdodDowbW07 DQoJbWFyZ2luLWJvdHRvbTowbW07DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseTpTaW1TdW47DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ047fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tYXNjaWkt Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHls ZS1zcGFuOw0KCW1zby1zdHlsZS11bmhpZGU6bm87fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxl LXVuaGlkZTpubzsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1h c2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCgltc28tc3R5 bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMS4wcHQ7DQoJbXNvLWJpZGktZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJY29sb3I6 IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1sb2NrZWQ6eWVzOw0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTo4LjBwdDsN Cgltc28tYmlkaS1mb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpUYWhvbWE7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6U2ltU3VuOw0KCW1zby1oYW5zaS1mb250LWZhbWlseTpUYWhvbWE7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6VGFob21hOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOO30NCnNw YW4uU3BlbGxFDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0Kc3Bhbi5H cmFtRQ0KCXttc28tc3R5bGUtbmFtZToiIjsNCgltc28tZ3JhbS1lOnllczt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZGVmYXVsdC1wcm9wczp5 ZXM7DQoJZm9udC1zaXplOjEwLjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCW1z by1iaWRpLWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7DQoJbXNv LWhlYWRlci1tYXJnaW46MzYuMHB0Ow0KCW1zby1mb290ZXItbWFyZ2luOjM2LjBwdDsNCgltc28t cGFwZXItc291cmNlOjA7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjg2NTQ2 NzQzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyNTkx OTIwNTIgLTE3MjUwMzE0ODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MG1tO30NCnVsDQoJe21hcmdpbi1ib3R0b206MG1tO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRh YmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1z by10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCglt c28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MG1tIDUuNHB0IDBtbSA1LjRwdDsNCgltc28t cGFyYS1tYXJnaW46MG1tOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28t cGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIg c3R5bGU9InRhYi1pbnRlcnZhbDozNi4wcHQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDs7Y29sb3I6IzFGNDk3RCI+WzxzcGFuIGNsYXNzPSJHcmFtRSI+c3BlYWtpbmc8L3NwYW4+ IGFzDQogaW5kaXZpZHVhbCBjb250cmlidXRvciBhbmQgbm90IGFzIGNoYWlyIG9mIHRoZSBQUFNQ IFdHXTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhp IFJ1aSwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJp ZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9zcGFu PjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPg0KIFJ1aSBDcnV6IFttYWlsdG86cnVp LmNydXpAaWVlZS1wdC5vcmc8c3BhbiBjbGFzcz0iR3JhbUUiPl0gPGJyPg0KPGI+PHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ8L3NwYW4+PC9iPjwvc3Bhbj48Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Ojwvc3Bhbj48L2I+IFNhdHVyZGF5LCBOb3ZlbWJlciAxMiwg MjAxMSA3OjExIFBNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwv c3Bhbj48L2I+IE1hcnRpbiBTdGllbWVybGluZzxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5DYzo8L3NwYW4+PC9iPiBSdWkgQ3J1ejsgbGkubGljaHVuMUB6dGUuY29tLmNu OyBwcHNwQGlldGYub3JnOyBwcHNwLWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDo8L3NwYW4+PC9iPiBSZTogW3Bwc3BdIE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ3UtcHBzcC1wZWVyLXByb3RvY29sLTAzLnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJTaW1TdW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+SGkgTWFydGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxmb250IHNpemU9IjMiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij5zZWUgbXkgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i U2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1mb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkN1bXByaW1lbnRvcy9SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+UnVpIENydXo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iU2ltU3VuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlNpbVN1 biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5TZW50IGZyb20gbXkgaVBhZDI8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJTaW1TdW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PGJyPg0KT24gMDkvMTEvMjAxMSwgYXQgMTU6MzYs IE1hcnRpbiBTdGllbWVybGluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1hcnRpbi5TdGllbWVybGlu Z0BuZWNsYWIuZXUiPk1hcnRpbi5TdGllbWVybGluZ0BuZWNsYWIuZXU8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltTcGVha2luZyBhcyBp bmRpdmlkdWFsXTwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIGFsbCw8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGd1ZXNzIEhU VFAgaXMgb25seSBkZWZpbmVkIHRvIHJ1biBvdmVyIFRDUCBhbmQgbm90IG92ZXIgVURQIGZvciB2 YXJpb3VzIHJlYXNvbnMsIGUuZy4sPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMyIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXpl PSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250 PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhUVFAgbWVzc2FnZXMg ZXhjZWVkIHRoZSBzaXplIG9mIGFuIFVEUCBkYXRhZ3JhbSwgZXhjZXB0IGluIHNvbWUgY29ybmVy IGNhc2VzOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGVyZSBpcyBubyByZWxpYWJsZSB0cmFuc3Bv cnQsIGZsb3cgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBpbiBVRFA7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPi08Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwv c3Bhbj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkEgSFRUUCBHRVQgY2FuIHJlc3VsdCBpbiBhIHZlcnkgbGFyZ2UgMjAwIE9LIG1lc3NhZ2Uu PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+VGhpcyBkZWZpbml0ZWx5IHJ1bGVzIG91dCBIVFRQIG92ZXIgVURQLg0KPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2VsbCwgVVBuUCB1c2Vz IEhUVFAgb3ZlciBVRFAgaW4gZGlzY292ZXJ5IG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0iR3JhbUUiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VHJ1ZSw8L3Nw YW4+PC9mb250Pjwvc3Bhbj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPg0KIGFuZCB0aGlzIGlz IG5vdCB0aGUgc3RhbmRhcmRpemVkIHdheSBvZiBIVFRQLCBidXQgYSBoYWNrIGluIDxzcGFuIGNs YXNzPSJTcGVsbEUiPg0KdXBucDwvc3Bhbj4uIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlVzaW5nIEhUVFAvWE1M IGVuY29kaW5nIGZvciBzaWduYWxpbmcsIHJlc3VsdHMgbW9zdGx5IGluIHNtYWxsDQogc2l6ZWQg bWVzc2FnZXMsIGFzIHRoZSBtYWluIGluZm9ybWF0aW9uIGlzIGluIHRoZSBib2R5IGFuZCBub3Qg aW4gdGhlIHJlc291cmNlIGFuZCBoZWFkZXIsIGFuZCB0aGUgdG90YWwgaXMgdHlwaWNhbGx5IHNt YWxsZXIgdGhhbiB0aGUgc2l6ZSBvZiBhIFVEUCBkYXRhZ3JhbS48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO21zby1i aWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IVFRQIGlzIG5vdA0KIGFuIGVuY29kaW5nIHNj aGVtZS4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlk aS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SFRUUCBoZWFkZXJzDQogYXJlIHN0aWxsIHRoZXJl LCBldmVuIHRob3VnaCB5b3UganVzdCBzZW5kIGEgc2luZ2xlIGJpdCBpbiB0aGUgZW50aXR5IGJv ZHkgb2YgdGhlIEhUVFAgbWVzc2FnZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlRoZXJlDQogaXMgbm90aGluZyBpbiBIVFRQIHdoaWNoIHByZXZlbnRz IHNlbmRpbmcgSFRUUCBtZXNzYWdlcyB3aGljaCBhcmUgbGFyZ2VyIHRoYW4gYSBVRFAgZGF0YWdy YW0uIFBsZWFzZSBub3RlIGFsc28gdGhhdCB0aGUgbWluaW1hbCByZXF1aXJlbWVudCBmb3IgdGhl IE1UVSBvZiBJUHY0IGlzIOKAnEV2ZXJ5IGludGVybmV0IG1vZHVsZSBtdXN0IGJlIGFibGUgdG8g Zm9yd2FyZCBhIGRhdGFncmFtIG9mIDY4PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9 Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGNsYXNz PSJHcmFtRSI+b2N0ZXRzPC9zcGFuPiB3aXRob3V0IGZ1cnRoZXIgZnJhZ21lbnRhdGlvbuKAnSBS RkMgNzkxLiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNv LWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkga25vdyB0aGF0DQogdGhlIGxpbmtzIHRv ZGF5IGhhdmUgbGFyZ2VyIE1UVXMsIGJ1dCB0aGlzIHJhaXNlcyB0aGUgcG9pbnQgd2hhdCB0aGUg YXNzdW1wdGlvbiBvZiB0aGUgTVRVIG9uIGEgcGF0aCBpcyBhbmQgaG93IHRoaXMgaW1wYWN0cyB0 aGUgYXNzdW1wdGlvbiBhYm91dCB0aGUgc2l6ZSBvZiBhbiBVRFAgZGF0YWdyYW3igKY8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5BYm91dCByZWxpYWJpbGl0eSBhbmQgY29uZ2VzdGlvbiBjb250cm9sLCB0aGF0IGlz IGNvcnJlY3QsIHRoZXJlZm9yZQ0KIHRoZSBwcmVmZXJlbmNlIG9uIHVzaW5nIFRDUCB3aGVuIHJl bGlhYmlsaXR5IGlzIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkkgZG8gbm90IHNlZQ0KIHRoYXQgd2UgbmVlZCByZWxpYWJsZSB0cmFuc3Bv cnQgb2YgY2h1bmtzIGJldHdlZW4gdHdvIHBlZXJzLCBidXQgd2UgbmVlZCBjb25nZXN0aW9uIGNv bnRyb2wuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO21zby1i aWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGUgcHJvdG9jb2wgd2UgZGVzaWduZWQgdXNlcyBQT1NU IG1lc3NhZ2VzIGZvciByZXF1ZXN0cyBhbmQNCiB0YWtlcyBhZHZhbnRhZ2Ugb2YgZ2V0dGluZyB0 aGUgcmVwbGllcyB3aXRoIHRoZSByZXF1ZXN0ZWQgZGF0YSBhcyBwYXlsb2FkIG9uIHRoZSBib2R5 IG9mIDIwMCBPSy4gVGhlIHJlcGx5IHdvdWxkIGhhdmUgdG8gYmUgdHJhbnNwb3J0ZWQgYW55d2F5 LCBzbyB3aHkgbm90IG9uIHRoZSBib2R5IG9mIGEgMjAwIE9LPzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1i cmVhayI+DQo8IVtpZiAhc3VwcG9ydExpbmVCcmVha05ld0xpbmVdPjxiciBzdHlsZT0ibXNvLXNw ZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UbyBiZSBo b25lc3RseSwgSeKAmW0gcHV6emxlZCB3aHkgSFRUUCBzaG91bGQgdGhlIGNob2ljZSBmb3IgdGhl IGNvbW11bmljYXRpb24gYmV0d2VlbiBwZWVycz8gSXQgaXM6PC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bh bj48L3NwYW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PmEgY2xpZW50IHNlcnZlciBwcm90b2NvbCwgdGhvdWdoIHdlIG5lZWQgYSBiaWRpcmVjdGlvbmFs IHByb3RvY29sIHdoaWNoIG5vIGNsZWFyIGNsaWVudA0KIGFuZCBzZXJ2ZXIgcm9sZXMuIEV4dGVu c2lvbnMgdG8gSFRUUCB0byBsZXQgc2VydmVycyBzZW5kIGFzeW5jaHJvbm91cyBtZXNzYWdlcyBh cmUgb24gdGhlIHdheSwgc2VlIHRoZSBCaURpcmVjdGlvbmFsIG9yIFNlcnZlci1Jbml0aWF0ZWQg SFRUUCAoaHliaSkgd29ya2luZyBncm91cCAoPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL3dnL2h5YmkvY2hhcnRlci8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9o eWJpL2NoYXJ0ZXIvPC9hPikuDQogSG93ZXZlciwgdGhpcyBpcyBub3QgeWV0IGZpbmlzaGVkOzwv c3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxmb250IHNpemU9IjMiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPGZvbnQgc2l6ZT0iMSIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvZm9udD48L3NwYW4+PC9zcGFuPjwvZm9udD48IVtlbmRpZl0+PGZvbnQgc2l6ZT0i MiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5pdCBoYXMgYSBjb25zaWRlcmFibGUgb3ZlcmhlYWQgY2F1c2Vk IGJ5IHRoZSBIVFRQIGhlYWRlcnMgb24gdGhlIHdpcmUsIGNvbXBhcmVkIHRvIHRoZQ0KIG1lc3Nh Z2UgY29udGVudCAoZS5nLiwgY2h1bmsgbWFwcyk7IEEgZ29vZCBleGFtcGxlIGlzIGdvb2dsZeKA mXMgd29yayBvbiBzcGR5LCB3aGljaCBoYXMgdGhlIGdvYWwgdG8gcmVkdWNlIHRoZSBIVFRQIGhl YWRlcnMuIFNlZSB0aGlzIGxpbmsgKDxhIGhyZWY9Imh0dHA6Ly9kZXYuY2hyb21pdW0ub3JnL3Nw ZHkvc3BkeS13aGl0ZXBhcGVyIj5odHRwOi8vZGV2LmNocm9taXVtLm9yZy9zcGR5L3NwZHktd2hp dGVwYXBlcjwvYT4pOiDigJxVbmNvbXByZXNzZWQNCiByZXF1ZXN0IGFuZCByZXNwb25zZSBoZWFk ZXJzLiBSZXF1ZXN0IGhlYWRlcnMgdG9kYXkgdmFyeSBpbiBzaXplIGZyb20gfjIwMCBieXRlcyB0 byBvdmVyIDJLQi7igJ07PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmkiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08Zm9udCBzaXplPSIxIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3NwYW4+PC9mb250PjwhW2Vu ZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPml0IGhhcyBhIGNvbnNpZGVyYWJs ZSBvdmVyaGVhZCB3aGVuIGltcGxlbWVudGluZyBpdCwgZS5nLiwgY29kZSBzaXplLiBJIGtub3cg dGhhdCBtYW55DQogcDJwIGNsaWVudHMgaGF2ZSBhIEhUVFAgc3RhY2ssIGJ1dCBpdCBzaG91bGQg bm90IGJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQgSU1PLiA8L3NwYW4+DQo8L2ZvbnQ+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkkgd291bGQgc2F5IHRoYXQgSFRUUCBpcyBhIHJlcXVlc3QvcmVw bHkgcHJvdG9jb2wgYmV0d2VlbiBob3N0cy4NCiBBbnl3YXksIGZvciBhIFN0cmVhbWluZyBlbnZp cm9ubWVudCwgd2hhdCBhIG1lZGlhIFBsYXllciBpbnRlcmZhY2VzIGlzIHdpdGggJnF1b3Q7c3Ry ZWFtaW5nIHNlcnZlciBub2RlcyZxdW90OywgYW5kIHNvLCB3ZSBtYXkgdGhpbmsgb2YgUGVlcnMg YXMgdGhlIFN0cmVhbWluZyBzZXJ2ZXJzIGZvciBhIENsaWVudCBNZWRpYSBQbGF5ZXIuPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhdCB2aWV3IGlzDQog Y29ycmVjdCwgYnV0IGl0IGNvbmNlcm5zIG9ubHkgdGhlIHZpZXcgYmV0d2VlbiB0aGUgbWVkaWEg Y2xpZW50IGFuZCB0aGUgc2VydmluZyBwZWVycyBmb3IgdGhpcyBtZWRpYSBjbGllbnQuIEl0IGRv ZXMgbm90DQo8c3BhbiBjbGFzcz0iR3JhbUUiPnJlbGF0ZWQ8L3NwYW4+IHRvIHRoZSBpbnRlcm5h bHMgb2YgdGhlIHAycCBwcm90b2NvbC4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28sIGFueSBQZWVyIGlzIGlu IGZhY3QgYSBwcm92aWRlciAoc2VydmVyKTxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj4m bmJzcDtlbnRpdHkNCiBmb3Igb3RoZXIgaW50ZXJlc3RlZCBQZWVycywgYnV0IGFsc28gYSBjb25z dW1lciAoY2xpZW50KSBvZiB0aGUgbWVkaWEgYXZhaWxhYmxlIGluIHRoZSBvdGhlciBQZWVycy48 L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29uc2lk ZXJpbmcgc3RyZWFtaW5nIG9mIHNlZ21lbnRlZCBtZWRpYSwgdGhlIGNodW5rcyBoYXZlIHF1aXRl DQogYSBsYXJnZSBzaXplLCByYW5naW5nIGZyb20gYXMgbG93IGFzIDVLaUIgdG8gfjIwMCBLaUIg KHR5cGljYWwgaW4gc2NhbGFibGUgY29kaW5nKSBmb3IgbWVkaWEgY2h1bmsgcGxheW91dCBkdXJh dGlvbiBvZiB+MiBzZWNvbmRzIChmb3IgSGlnaCBRdWFsaXR5IHZpZGVvcykuIFRoZSBIVFRQIGhl YWRlciBzaXplIChhbmQgcmVxdWVzdCBib2R5PHNwYW4gY2xhc3M9IkdyYW1FIj4pICZuYnNwO2lz PC9zcGFuPiB0aGVuIGNvbXBhcmF0aXZlbHkgc21hbGwuPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCBpZiBJIGRlY2lkZQ0KIHRvIGdvIGZvciAxIEtp bG9ieXRlIGNodW5rcz8gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCBpZiBJIGp1c3QNCiBzZW50 IGNodW5rIG1hcHMgb3IgYW55IG90aGVyIHNpZ25hbGluZyBtZXNzYWdlcyBiYWNrIGFuZCBmb3J0 aD8gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJHcmFt RSI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BZGRpdGlvbmFsbHksIGZvciB0 aGVzZSBtZWRpYSBjaHVuayBzaXplcw0KICgyMDAmIzQzOyBLaUIpLCBhIGhpZ2ggcXVhbGl0eSBu b24gc2NhbGFibGUgdmlkZW8gbmVlZHMgYXJvdW5kIG9uZSByZXF1ZXN0IGV2ZXJ5IDIgc2Vjb25k cyAobm90IGNvbnNpZGVyaW5nIGFueSBzcGVjaWFsIHN0cmF0ZWd5IGZvciBwaWVjZSBwaWNraW5n KS48L3NwYW4+PC9mb250Pjwvc3Bhbj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4NCiBUaGlzIGlzIHF1aXRlIGRpZmZlcmVu dCBmcm9tIHRoZSB0eXBpY2FsIGltcGxlbWVudGF0aW9ucyBvZiBzdHJlYW1pbmcgdmlhIEJpdFRv cnJlbnQtbGlrZSB0ZWNobmlxdWVzLCB0aGF0IG5lZWQgYSBxdWl0ZSBsYXJnZSBhbW91bnQgb2Yg cmVxdWVzdHMgcGVyIHNlY29uZCBmb3IgdGhlIHZlcnkgc2FtZSB2aWRlbyBwbGF5b3V0IGR1cmF0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZvciBzY2Fs YWJsZSBtZWRpYSwgdGhpcyBpcyBhbiBhZHZhbnRhZ2UgZm9yIHRoZSBzdHJhdGVneSBvZg0KIHJl cXVlc3RpbmcgdGhlIGxheWVycyBvZiBhIGNodW5rIHVwIHRvIGEgY2VydGFpbiBxdWFsaXR5IChl dmVudHVhbGx5IHRoZSBtYXhpbXVtKSBpbiB0aGUgdmVyeSBzYW1lIHRpbWUgd2luZG93LiBBZGRp dGlvbmFsbHksIGFuZCBmb3Igc2NhbGFibGUgbWVkaWEsIHRoZSBwcm9iYWJpbGl0eSBvZiBzbW9v dGggcGxheW91dCB3aXRob3V0DQo8c3BhbiBjbGFzcz0iU3BlbGxFIj5yZWJ1ZmZlcmluZzwvc3Bh bj4gaXMgdmVyeSBoaWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPlRoZSB0cm91YmxlDQogSSBzZWUgaXMgdGhhdCB5b3UgaGF2ZSBvbmx5IHlvdXIgc2Nl bmFyaW8gaW4gbWluZC4gSeKAmW0gbm90IHN1cmUgdGhhdCB5b3VyIGFzc3VtcHRpb25zIGhvbGQg dHJ1ZSBpZiB5b3Ugc3dpdGNoIHRvIE1EQy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgaXMgb25lIG9m IHRoZSByZWFzb25zIGZvciB0aGUgYWRvcHRpb24gb2YgSFRUUCBBZGFwdGl2ZQ0KIFN0cmVhbWlu ZyB0ZWNobmlxdWVzIGZyb20gM0dQUCBhbmQgSVNPLCBpbiBzcGVjaWFsIGZvciBtb2JpbGUgZW52 aXJvbm1lbnQuIFRoZXJlIGFyZSBhbHJlYWR5IGFwcGxpY2F0aW9ucyBmb3IgTGl2ZSBTdHJlYW1p bmcgdXNpbmcgSFRUUCBmb3Igc21hcnRwaG9uZXMgYW5kIGFUYWJsZXRzLCBvdmVyIDNHIG9yIFdp LUZpLCBwcm92aWRpbmcgYSBoaWdoIHF1YWxpdHkgb2YgZXhwZXJpZW5jZSB0byB0aGUgdXNlci4g QW4gZXhhbXBsZSBpcyB0aGUgQmxvb21iZXJnDQogQXBwIGZvciB0aGUgPHNwYW4gY2xhc3M9IlNw ZWxsRSI+aVBhZDwvc3Bhbj4uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv bG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+QW5kPyBJIGRvIG5vdA0KIGdldCB0aGUgcG9pbnQgeW91IHRyeWluZyB0byByYWlz ZS4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBm YWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPk1hcnRpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0 ZXI6bGluZS1icmVhayI+DQo8IVtpZiAhc3VwcG9ydExpbmVCcmVha05ld0xpbmVdPjxiciBzdHls ZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFbZW5kaWZdPjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZXVzaW5nIGV4aXN0aW5nIHByb3RvY29scyBpcyBhIGdvb2QgaWRlYSwgYnV0IEkgaGF2ZSB0 aGUgZmVlbGluZyB0aGF0IHdlIGFyZSBzdHJldGNoaW5nIGl0IGEgYml0IHRvbyBtdWNoIGluDQog dGhpcyBjYXNlLiA8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5NeSBmZXcgY2VudHM8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgTWFydGluPC9zcGFuPjwvZm9udD48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Im1haWx0bzptYXJ0aW4uc3RpZW1lcmxpbmdA bmVjbGFiLmV1Ij5tYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1PC9hPjwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBj b2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5FQyBMYWJvcmF0b3Jp ZXMgRXVyb3BlIC0gTmV0d29yayBSZXNlYXJjaCBEaXZpc2lvbiBORUMgRXVyb3BlIExpbWl0ZWQg fCBSZWdpc3RlcmVkDQogT2ZmaWNlOiBORUMgSG91c2UsIDEgVmljdG9yaWEgUm9hZCwgTG9uZG9u IFczIDZCTCB8IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMyMDE0DQo8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MG1tIDBtbSAwbW0gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tb3V0bGluZS1sZXZlbDoxIj48Yj48Zm9u dCBzaXplPSIyIiBmYWNlPSJUYWhvbWEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2ZvbnQt d2VpZ2h0OmJvbGQiPkZyb206PC9zcGFuPjwvZm9udD48L2I+PGZvbnQgc2l6ZT0iMiIgZmFjZT0i VGFob21hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86cHBz cC1ib3VuY2VzQGlldGYub3JnIj5wcHNwLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1h aWx0bzpbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10iPg0KW21haWx0bzpwcHNwLWJvdW5j ZXNAaWV0Zi5vcmddPC9hPiA8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+T24gQmVo YWxmIE9mDQo8L3NwYW4+PC9iPlJ1aSBDcnV6PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlNlbnQ6PC9zcGFuPjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMDEsIDIwMTEgMjoz OSBQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Ubzo8L3NwYW4+PC9i PiA8YSBocmVmPSJtYWlsdG86bGkubGljaHVuMUB6dGUuY29tLmNuIj4NCmxpLmxpY2h1bjFAenRl LmNvbS5jbjwvYT48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6PC9z cGFuPjwvYj4gUnVpIENydXo7IDxhIGhyZWY9Im1haWx0bzpwcHNwQGlldGYub3JnIj4NCnBwc3BA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnIj5wcHNw LWJvdW5jZXNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtwcHNwXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbC0wMy50eHQ8L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5JbmRlZWQsIEkgc3VwcG9zZSBub3RoaW5nIHByZXZlbnRzIHVzaW5nIEhUVFAvWE1MIG92ZXIg VURQLCBhcyBtZXNzYWdlcyB0eXBpY2FsbHkgZml0IGluIFVEUCBkYXRhZ3JhbXMgYW5kIHRoZSBt ZXRob2RzIHVzZWQgZm9yIHJlcXVlc3RzIGFyZSBQT1NULjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i U2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SW4gdGhlIGRyYWZ0IHRoZSB0 cmFuc3BvcnQgcHJvdG9jb2wgdG8gYmUgdXNlZCBmb3IgdGhlIHNpZ25hbGluZyB3YXMgbm90IHNw ZWNpZmllZCBhbmQgaXQgaXMgb3BlbiB0byBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSJibGFjayIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJlc3QgUmVnYXJkcyw8 L3NwYW4+PC9mb250Pjwvc3Bhbj48Zm9udCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGJy Pg0KPC9zcGFuPjwvZm9udD48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PGZvbnQg Y29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO2ZvbnQt d2VpZ2h0OmJvbGQiPlByb2YuIFJ1aSBTYW50b3MgQ3J1ejwvc3Bhbj48L2ZvbnQ+PC9iPjwvc3Bh bj48Yj48Zm9udCBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2s7Zm9udC13ZWlnaHQ6Ym9sZCI+PGJyPg0KPC9zcGFuPjwvZm9udD48L2I+PHNwYW4gY2xh c3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGFpcm1h bjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxmb250IHNpemU9IjIiIGNvbG9yPSJibGFjayIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPklFRUUmbmJzcDtQb3J0dWdhbCBTZWN0aW9uPC9zcGFuPjwvYj48L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPjxicj4NCjwvc3Bhbj48L2I+PC9zcGFuPjwvZm9u dD48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9ImJs YWNrIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+QXYuIFByb2YuIERyLiBBbsOtYmFsIENhdmFjbyBTaWx2YSwmbmJzcDtJU1QtVGFndXNQYXJr LCBPZmZpY2UgMS01LCZuYnNwOzI3NDQtMDE2IFBvcnRvIFNhbHZvLA0KIFBvcnR1Z2FsPC9zcGFu PjwvZm9udD48L3NwYW4+PGZvbnQgc2l6ZT0iMSIgY29sb3I9ImJsYWNrIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPHNwYW4gY2xh c3M9ImFwcGxlLXN0eWxlLXNwYW4iPiYjNDM7MzUxIDIxNCAyMzMgMjAwIChleHQgNTA0NCksJm5i c3A7JiM0MzszNTEuOTM5IDA2MCA5MzkgKG1vYmlsZSk8L3NwYW4+PC9zcGFuPjwvZm9udD48Zm9u dCBzaXplPSIyIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNw YW4iPjxhIGhyZWY9IngtbXNnOi8vMTI3L3J1aS5jcnV6QGllZWUub3JnIj5ydWkuY3J1ekBpZWVl Lm9yZzwvYT4mbmJzcDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4i PjxhIGhyZWY9IngtbXNnOi8vMTI3L3J1aS5zLmNydXpAaXN0LnV0bC5wdCI+cnVpLnMuY3J1ekBp c3QudXRsLnB0PC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+ PGEgaHJlZj0ieC1tc2c6Ly8xMjcvc2VjLnBvcnR1Z2FsQGllZWUub3JnIj5zZWMucG9ydHVnYWxA aWVlZS5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48 YSBocmVmPSJodHRwOi8vd3d3LmllZWUtcHQub3JnLyI+d3d3LmllZWUtcHQub3JnPC9hPjwvc3Bh bj48L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjIiIGNvbG9yPSJibHVlIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PGJyPg0KPC9zcGFuPjwv Zm9udD48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9 IiMwMDAwZmUiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMDAwMEZFIj5BZHZhbmNpbmcgdGVjaG5vbG9neSBmb3IgaHVtYW5pdHkuPC9zcGFuPjwvZm9u dD48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iU2ltU3VuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gMDEvMTEvMjAxMSwgYXQgMDE6NTUsDQo8YSBo cmVmPSJtYWlsdG86bGkubGljaHVuMUB6dGUuY29tLmNuIj5saS5saWNodW4xQHp0ZS5jb20uY248 L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxicj4NCjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxp bmUtYnJlYWsiPg0KPCFbaWYgIXN1cHBvcnRMaW5lQnJlYWtOZXdMaW5lXT48YnIgc3R5bGU9Im1z by1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2VuZGlmXT48bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowbW07bWFyZ2luLXJpZ2h0OjBtbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDoxMC41cHQiPg0KPGZvbnQgc2l6ZT0iMyIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIyIiBmYWNl PSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SSB0aGluayBYTUwgb3ZlciBVRFAg aXMgYWxzbyBhIGdvb2Qgb3B0aW9uLjxicj4NCjxicj4NCkJSPC9zcGFuPjwvZm9udD4gPGJyPg0K PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkxp Y2h1bjxicj4NCjwvc3Bhbj48L2ZvbnQ+PGJyPg0KPGJyPg0KPHR0Pjxmb250IHNpemU9IjIiIGZh Y2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9Im1haWx0 bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmciPnBwc3AtYm91bmNlc0BpZXRmLm9yZzwvYT4NCjxzcGFu IGxhbmc9IlpILUNOIj7lhpnkuo48L3NwYW4+IDIwMTEtMTEtMDEgMDk6MjE6Mjg6PC9zcGFuPjwv Zm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 YnI+DQo8YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEhpLDwvc3Bhbj48L2ZvbnQ+PC90 dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9z cGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8L3NwYW4+DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+Jmd0OyBXZSBoYXZlIHVwZGF0ZWQgdGhlIFBQU1AgVHJhY2tlciBQcm90b2NvbCBkcmFmdCwg Y29ycmVzcG9uZGluZyB0bw0KPC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBz aXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7 IHRoZSBtZXJnZSBvZiB0aGUgZm9ybWVyIGRyYWZ0cyBmcm9tIEd1IGFuZCBDcnV6Lg0KPC9zcGFu PjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDwvc3Bhbj4NCjwvZm9udD48L3R0Pjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+ PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7IFRoaXMgdmVyc2lvbiBtYWlubHkgZm9jdXMgb24gdGhlIG1lc3Nh Z2VzIGV4Y2hhbmdlZCBiZXR3ZWVuIHBlZXJzLA0KPC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250 Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7IGJ1dCBsZWF2ZSB0aGUgZW5jb2RpbmcgZm9ybWF0IGludG8gQXBwZW5kaXgg c2luY2UgdXNpbmcgYmluYXJ5IG9yDQo8L3NwYW4+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0Pjxm b250IHNpemU9IjIiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZndDsgSFRUUC9YTUwgYXMgY29udGFpbmVyIGlzIHN0aWxsIHVuZGVyIGRpc3B1dGUuPC9zcGFu PjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDwvc3Bhbj4NCjwvZm9udD48L3R0Pjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+ PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyB5b3VyIGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucy48L3NwYW4+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250IHNpemU9IjIi IGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgPC9zcGFu Pg0KPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250IHNpemU9IjIiIGZhY2U9IlNpbVN1biI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgVGhhbmtzLjwvc3Bhbj48L2ZvbnQ+ PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0K PC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8L3NwYW4+DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48 dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyBKaW53ZWk8L3NwYW4+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250IHNp emU9IjIiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsg PC9zcGFuPg0KPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250IHNpemU9IjIiIGZhY2U9IlNp bVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgLS0tLS08c3BhbiBsYW5n PSJaSC1DTiI+6YKu5Lu25Y6f5Lu2PC9zcGFuPi0tLS0tPC9zcGFuPjwvZm9udD48L3R0Pjxmb250 IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9m b250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7IDxzcGFuIGxhbmc9IlpILUNOIj4NCuWPkeS7tuS6ujwvc3Bhbj46IDxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjwvZm9udD48L3R0Pjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+ PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7IDxzcGFuIGxhbmc9IlpILUNOIj4NCuWPkemAgeaXtumXtDwvc3Bh bj46IDIwMTE8c3BhbiBsYW5nPSJaSC1DTiI+5bm0PC9zcGFuPjEwPHNwYW4gbGFuZz0iWkgtQ04i PuaciDwvc3Bhbj4zMTxzcGFuIGxhbmc9IlpILUNOIj7ml6U8L3NwYW4+IDE5OjA0PC9zcGFuPjwv Zm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDxzcGFuIGxhbmc9IlpILUNOIj4NCuaUtuS7 tuS6ujwvc3Bhbj46IFhpYWppbndlaTwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ Jmd0OyA8c3BhbiBsYW5nPSJaSC1DTiI+DQrmioTpgIE8L3NwYW4+OiBYaWFqaW53ZWk7IFlpbmdq aWUgR3UoeWluZ2ppZSk7IDxhIGhyZWY9Im1haWx0bzptYXJpby5udW5lc0Bpbm92LnB0Ij5tYXJp by5udW5lc0Bpbm92LnB0PC9hPjsgam9hby48L3NwYW4+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0 Pjxmb250IHNpemU9IjIiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZndDsgPGEgaHJlZj0ibWFpbHRvOnNpbHZhQGlub3YucHQiPg0Kc2lsdmFAaW5vdi5wdDwv YT47IDxhIGhyZWY9Im1haWx0bzpydWkuY3J1ekBpZWVlLm9yZyI+cnVpLmNydXpAaWVlZS5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86ZGJyeWFuQGV0aGVybm90Lm9yZyI+DQpkYnJ5YW5AZXRoZXJu b3Qub3JnPC9hPjwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8c3BhbiBs YW5nPSJaSC1DTiI+DQrkuLvpopg8L3NwYW4+OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbC0wMy50eHQ8L3NwYW4+PC9mb250PjwvdHQ+PGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48 L2ZvbnQ+PHR0Pjxmb250IHNpemU9IjIiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsgPC9zcGFuPg0KPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250 IHNpemU9IjIiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZn dDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbC0wMy50 eHQgaGFzIGJlZW4NCjwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppbndlaSBYaWEgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Ljwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8L3NwYW4+ DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBGaWxlbmFtZTogJm5ic3A7ICZuYnNw O2RyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbDwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48 dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyBSZXZpc2lvbjogJm5ic3A7ICZuYnNwOzAzPC9zcGFuPjwvZm9udD48L3R0Pjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+ PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij4mZ3Q7IFRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQZWVyIFByb3Rv Y29sPC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJT aW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IENyZWF0aW9uIGRhdGU6 ICZuYnNwOyAmbmJzcDsyMDExLTEwLTMxPC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48 Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij4mZ3Q7IFdHIElEOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248 L3NwYW4+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHR0Pjxmb250IHNpemU9IjIiIGZhY2U9IlNpbVN1 biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgTnVtYmVyIG9mIHBhZ2VzOiAz MTwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2lt U3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyA8L3NwYW4+DQo8L2ZvbnQ+ PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0K PC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyBBYnN0cmFjdDo8L3NwYW4+PC9mb250PjwvdHQ+PGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bhbj48 L2ZvbnQ+PHR0Pjxmb250IHNpemU9IjIiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgcHJlc2VudHMgdGhl IGFyY2hpdGVjdHVyZSBvZiB0aGUgUFBTUCBQZWVyIHByb3RvY29sPC9zcGFuPjwvZm9udD48L3R0 Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3Nw YW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOyAmbmJzcDtvdXRsaW5pbmcgdGhlIGZ1bmN0aW9u YWwgZW50aXRpZXMsIG1lc3NhZ2UgZmxvd3MgYW5kIG1lc3NhZ2U8L3NwYW4+PC9mb250PjwvdHQ+ PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCjwvc3Bh bj48L2ZvbnQ+PHR0Pjxmb250IHNpemU9IjIiIGZhY2U9IlNpbVN1biI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiZndDsgJm5ic3A7ICZuYnNwO3Byb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25z LCB3aXRoIHRoZSByZXNwZWN0aXZlIHBhcmFtZXRlcnMuICZuYnNwO1RoZSBQUFNQPC9zcGFuPjwv Zm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOyAmbmJzcDtQZWVyIFByb3RvY29s IHByb3Bvc2VkIGluIHRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgY2FwYWJpbGl0aWVzIG9mPC9z cGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOyAmbmJzcDtQUFNQIHRv IHN1cHBvcnQgYWRhcHRpdmUgYW5kIHNjYWxhYmxlIHZpZGVvIGFuZCAzRCB2aWRlbywgZm9yIFZp ZGVvPC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJT aW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7ICZuYnNwOyAmbmJzcDtP biBEZW1hbmQgKFZvRCkgYW5kIExpdmUgdmlkZW8gc2VydmljZXMuICZuYnNwO1RoZSBwcm90b2Nv bCBtZXNzYWdlczwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAmbmJzcDsg Jm5ic3A7Zm9ybWFsIHN5bnRheCBhbmQgc2VtYW50aWNzLCBtZXRob2RzLCBhbmQgZm9ybWF0cyBh cmUgcHJlc2VudGVkIGZvcjwvc3Bhbj48L2ZvbnQ+PC90dD48Zm9udCBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPC9zcGFuPjwvZm9udD48dHQ+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0OyAm bmJzcDsgJm5ic3A7Ym90aCBCaW5hcnkgYW5kIEhUVFAvWE1MIGVuY29kZWQgZm9ybWF0cy48L3Nw YW4+PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PHNwYW4gY2xhc3M9IkdyYW1FIj48dHQ+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jmd0Ow0K PC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1T dW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7PC9zcGFuPjwvZm9udD48L3R0 Pjwvc3Bhbj48dHQ+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iU2ltU3VuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJT aW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDwvc3Bhbj4NCjwvZm9u dD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+ DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDwvc3Bhbj4NCjwvZm9udD48L3R0Pjxmb250IHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250 Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4mZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0PC9zcGFuPjwvZm9udD48L3R0Pjxmb250 IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9m b250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9zcGFuPjwvZm9udD48L3R0Pjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij48YnI+DQo8L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNl PSJTaW1TdW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDxzcGFuIGNsYXNz PSJHcmFtRSI+DQpwcHNwPC9zcGFuPiBtYWlsaW5nIGxpc3Q8L3NwYW4+PC9mb250PjwvdHQ+PGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxiciBzdHlsZT0ibXNv LXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFbaWYgIXN1cHBvcnRMaW5lQnJlYWtO ZXdMaW5lXT48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwh W2VuZGlmXT48L3NwYW4+PC9mb250Pjx0dD48Zm9udCBzaXplPSIyIiBmYWNlPSJTaW1TdW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC90 dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlk aS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MG1t O21hcmdpbi1yaWdodDowbW07bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MTAuNXB0 Ij4NCjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTttc28t YmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+bWFydGluLnN0aWVtZXJsaW5nQG5lY2xhYi5l dTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBtbTttYXJnaW4tcmlnaHQ6MG1tO21hcmdpbi1ib3R0b206 MTIuMHB0O21hcmdpbi1sZWZ0OjEwLjVwdCI+DQo8Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TkVD DQogTGFib3JhdG9yaWVzIEV1cm9wZSAtIE5ldHdvcmsgUmVzZWFyY2ggRGl2aXNpb24gTkVDIEV1 cm9wZSBMaW1pdGVkIHwgUmVnaXN0ZXJlZCBPZmZpY2U6IE5FQyBIb3VzZSwgMSBWaWN0b3JpYSBS b2FkLCBMb25kb24gVzMgNkJMIHwgUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIDI4MzIwMTQ8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E91463Polydeucesoffic_-- From Martin.Stiemerling@neclab.eu Tue Nov 29 07:57:29 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F881F0C64 for ; Tue, 29 Nov 2011 07:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.266 X-Spam-Level: X-Spam-Status: No, score=-101.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c+bqcAiRx2uQ for ; Tue, 29 Nov 2011 07:57:27 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 990941F0C61 for ; Tue, 29 Nov 2011 07:57:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0033B280001C4; Tue, 29 Nov 2011 16:57:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Zu5TvG3uAJ; Tue, 29 Nov 2011 16:57:25 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D613028000082; Tue, 29 Nov 2011 16:57:15 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 29 Nov 2011 16:57:15 +0100 From: Martin Stiemerling To: Picconi Fabio , "ppsp@ietf.org" Thread-Topic: [ppsp] chunk scheduling algorithm Thread-Index: AcyjRtVgdTFvUm3CSaOZLhwd4Jzszv///Q6AgABNAgCAAEEeAIAA3TwA/+qXdUA= Date: Tue, 29 Nov 2011 15:57:15 +0000 Message-ID: References: <320C4182454E96478DC039F2C48198720471953887@MOPESMBX01.eu.thmulti.com> <4EC1E847.6040003@disi.unitn.it> <4EC228E0.4060304@kth.se> <4EC25F80.5000603@disi.unitn.it> <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> In-Reply-To: <320C4182454E96478DC039F2C48198720471A79469@MOPESMBX01.eu.thmulti.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] chunk scheduling algorithm X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 15:57:31 -0000 Hi all chunk scheduling enthusiasts,=20 It might be indeed a good idea to go with this to the IRSG. I'm not trying = to turn you away guys, but this is of potential interest for the p2prg.=20 My take from this is that the PPSP peer protocol should support multiple ch= unk scheduling algorithms. The peer protocol would need a capability exchange where each peer can stat= e what algorithm it supports.=20 Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Picconi Fabio > Sent: Wednesday, November 16, 2011 3:00 AM > To: ppsp@ietf.org > Subject: Re: [ppsp] chunk scheduling algorithm >=20 > Interesting discussion. I agree that a lot of scheduling algorithms have = been > proposed, and that a detailed comparison is missing. Maybe a good subject= for > the P2PRG? :-) >=20 > Regarding PPSP, given the absence of a clear winner among scheduling > algorithms, I agree that PPSP should be as generic as possible to support= the > widest range of options. And that probably means supporting multiple form= s of > signaling (e.g., different representations of buffer maps), multiple requ= est > paradigms (push/pull/push-pull), multiple transports, etc. >=20 > Fabio >=20 >=20 > -----Original Message----- > From: Csaba Kiraly [mailto:kiraly@disi.unitn.it] > Sent: mardi 15 novembre 2011 20:48 > To: Gyorgy Dan > Cc: Picconi Fabio; ppsp@ietf.org > Subject: Re: [ppsp] chunk scheduling algorithm >=20 > Hi Gyorgy, >=20 > nice paper! This is one of the reasons why we are working on some protoco= l > changes to make it more delay tolerant, but this is still in the works. > I fully agree that detailed comparison and evaluation is largely missing.= There > are some spot results but far from being exhaustive. Anyone interested in= a > joint study of scheduling algorithms? I can throw in a simulator, an emul= ator > and an implementation with configurable schedulers. >=20 > BTW, I hope the ppsp list does not mind that we jumped on the list with t= his > discussion. I don't know how the topic came up (it was 3 a.m here while y= ou > had the discussion, so I wasn't able to follow it), but it seems there wa= s some > interest. >=20 > From our experience, scheduling issues does have some mild influence on t= he > protocol. Namely: > - simple buffer maps sent as bitmaps might not be enough, you might want = to > send some metadata associated with the chunk IDs as well. > - different scheduling algorithms match well or not with different protoc= ols > (push, pull, offer, negotiation, etc.). IMHO the ppsp peer protocol shoul= d > support these all through a careful selection of messaging primitives ins= tead of > choosing one, especially because studies are still not satisfying to deci= de which > one is the best, not even to decide which one is better in what scenario. >=20 > Csaba >=20 > On 11/15/2011 09:54 AM, Gyorgy Dan wrote: > > Hi Csaba, Fabio, all, > > > > There are many alternatives for scheduling, but IMHO no extensive > > comparison of recent algorithms. > > It is also good to keep in mind that the performance of the algorithms > > depends significantly on the assumptions made for the evaluation. This > > study, for example, shows how the performance of random push policies > > deteriorates if the evaluation accounts for the delay needed to exchang= e > > signaling messages between the peers: > > > > I. Chatzidrossos, G. D=E1n and V. Fodor, ``Delay and playout probabilit= y > > trade-off in mesh-based peer-to-peer streaming with delayed buffer map > > updates,'' in Peer-to-peer Networking and Applications, vol. 3., num. > > 1., Mar. 2010 > > > > Gy=F6rgy > > > > > > On 11/15/2011 05:19 AM, Csaba Kiraly wrote: > >> Hi Fabio, hi all, > >> > >> Another alternative (for live streaming) is Deadline based chunk > >> scheduling. You can find the description of the algorithm, theoretical > >> background and some simulations here: > >> > >> Abeni, L., C. Kiraly, and R. Lo Cigno, "On the Optimal Scheduling of > >> Streaming Applications in Unstructured Meshes", NETWORKING 2009, vol. > >> 5550: Springer Berlin / Heidelberg, pp. 117-130, 2009. > >> http://peerstreamer.org/content/optimal-scheduling-streaming- > applications-unstructured-meshes > >> http://napa- > wine.eu/twiki/pub/Public/DocumentsOld/abeni_optimal_scheduling-final.pdf > >> > >> The paper presents a combination of a chunk selection and a peer > >> selection algorithm (DLc and RLp, respectively), but the chunk selecti= on > >> algorithm can be used in itself as well. It shows nice behavior and go= od > >> delivery properties where latest useful policies fail (chunk diffusion > >> delay distribution tends to have a heavy tail with latest useful for > >> many reasons, DLc tries to correct these shortcomings). > >> > >> An extension of the above to structured streams (SVC, MDC and alike) i= s > >> described in the following paper: > >> > >> Kiraly, C., R. Lo Cigno, and L. Abeni, "Deadline-Based Differentiation > >> in P2P Streaming", GLOBECOM 2010 - 2010 IEEE Global Communications > >> Conference, Miami, FL, USA, IEEE, pp. 1 - 6, 2010. > >> http://peerstreamer.org/content/deadline-based-differentiation-p2p- > streaming > >> http://disi.unitn.it/~kiraly/preprints/kiraly-globecom2010-extended.pd= f > >> > >> Csaba > >> > >> > >> > >> On 11/15/2011 04:29 AM, Picconi Fabio wrote: > >>> Hi, > >>> > >>> > >>> > >>> Here are the references on alternatives to rarest first for live > >>> streaming. The first study has theoretical/simulation results, while > >>> the second shows results based on a real prototype. > >>> > >>> > >>> > >>> Thomas Bonald , Laurent Massouli=E9 , Fabien Mathieu , Diego Perino , > >>> Andrew Twigg. Epidemic Live Streaming: Optimal Performance Trade-Offs= . > >>> In Proc. of SIGMETRICS, 2008. > >>> > >>> http://www.thlab.net/~lmassoul/sigmetrics_08.pdf > >>> > >>> > >>> > >>> > >>> F. Picconi and L. Massouli=E9. Is there a future for mesh-based live > >>> video streaming? In Proc. of P2P, 2008. > >>> > >>> http://www.thlab.net/~picconi/p2p08.pdf > >>> > >>> > >>> > >>> > >>> The "latest useful" policy shows its benefits when the users' downloa= d > >>> windows overlap (which is usually the case for live streaming). For > >>> time-shifted media (e.g., VoD/catch-up), it's a good idea to > >>> distinguish between the download window next to the playback deadline= , > >>> and the rest. For the download window, the simplest choice is > >>> "earliest useful" (i.e., prefer the chunks closest to the deadline), > >>> although combining "earliest useful" with "latest useful" will > >>> probably give better results if you have users with overlapping > >>> windows. For the remaining chunks (i.e., far from the playback > >>> deadline), you probably want to use "rarest first". > >>> > >>> > >>> > >>> Fabio > >>> > >>> > >>> > >>> _______________________________________________ > >>> ppsp mailing list > >>> ppsp@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ppsp > >> > >> > >> This body part will be downloaded on demand. >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From Fabio.Picconi@technicolor.com Tue Nov 29 08:04:24 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4677D11E8088 for ; Tue, 29 Nov 2011 08:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIgO7p0OtbMV for ; Tue, 29 Nov 2011 08:04:23 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 3E45311E809C for ; Tue, 29 Nov 2011 08:04:16 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKTtUCeDkoETyc2P+cENium2bBeo3bLKxF@postini.com; Tue, 29 Nov 2011 08:04:23 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 29 Nov 2011 17:00:33 +0100 Received: from MOPESMBX01.eu.thmulti.com ([141.11.100.105]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 29 Nov 2011 17:00:38 +0100 From: Picconi Fabio To: Martin Stiemerling , "ppsp@ietf.org" Date: Tue, 29 Nov 2011 17:00:36 +0100 Thread-Topic: A word from the chair about the peer protocol discussion Thread-Index: Acyuqy7rs24inMrETNm3UdypfDd+oQAAkqkg Message-ID: <320C4182454E96478DC039F2C48198720481C89A3D@MOPESMBX01.eu.thmulti.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] A word from the chair about the peer protocol discussion X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 16:04:24 -0000 Hi, I share your impression that this discussion is not sufficiently technical.= Also, there's a sudden spike in activity on the list, so it's becoming dif= ficult to follow all comments and put them into perspective. Therefore, what I suggest, is that before the group/chair makes a decision = (and I hope the chair will give us more time to converge on this), we produ= ce a clear, synthetic summary of the features, praises and criticisms of bo= th proposals. Hopefully this will allow us to have a more clear debate.=20 I'm willing to write such a summary (at least the first draft of it) if you= think it's a good idea. Also, I will send my comments to the list on a later email today. Cheers, Fabio -----Original Message----- From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Mar= tin Stiemerling Sent: mardi 29 novembre 2011 16:34 To: ppsp@ietf.org Subject: [ppsp] A word from the chair about the peer protocol discussion [speaking as PPSP WG chair] Dear all,=20 I have read through the emails about the peer protocol discussion and have = the feeling that the discussions are turning a bit towards pure political d= iscussions.=20 Therefore, I would like to remind my original email in this respect and how= decisions about protocol proposals should be made: "Please state your **technical** opinion about which peer protocol proposal= you would prefer" (Cited from http://www.ietf.org/mail-archive/web/ppsp/current/msg01161.html= ) Another important point: We are hopefully about to select a PPSP peer protocol as basis. This PPSP peer protocol will potentially become the Working Group item and = therefore move under the change control of the WG.=20 The WG item allows the working group to add, change or remove semantics or = syntax form the protocol, given that there is rough consensus.=20 I'm saying this, as I have the feeling that a lot of people fear that prior= work will be lost if we chose a peer protocol based one of the proposals. = However, you can describe technical features by email or as an Internet dra= ft and suggest adding this feature to the peer protocol.=20 Kind regards, Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp From yry@cs.yale.edu Tue Nov 29 09:15:07 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC821F0C77 for ; Tue, 29 Nov 2011 09:15:07 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg0HqJxcNPj6 for ; Tue, 29 Nov 2011 09:15:05 -0800 (PST) Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id 4681E1F0C72 for ; Tue, 29 Nov 2011 09:15:05 -0800 (PST) Received: from Faculty-Supports-MacBook-Pro.local ([128.36.168.192]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id pATHEwq7008509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 29 Nov 2011 12:14:59 -0500 Message-ID: <4ED51312.9060004@cs.yale.edu> Date: Tue, 29 Nov 2011 12:14:58 -0500 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Martin Stiemerling References: <4ED48613.6070408@cs.yale.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 Cc: "ppsp@ietf.org" , LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:15:07 -0000 Hi Martin, On 11/29/11 10:13 AM, Martin Stiemerling wrote: > [speaking as individual contributor and not as chair of the PPSP WG] > > Hi Richard, > >> -----Original Message----- >> From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Y. >> Richard Yang >> Sent: Tuesday, November 29, 2011 8:13 AM >> To: ppsp@ietf.org >> Cc: LANS Yale >> Subject: Re: [ppsp] Selection of PPSP peer protocol draft >> >> Hi all, >> >> I read both specs, and the meeting minutes but missed this IETF at >> Taipei. So if I am repeating some discussions already happened, please >> let me know. >> >> First off, I got the feeling that multiple votes for swift over >> draft-gu-ppsp-peer were based on maturity, at this moment. I think this > Well, maturity is an indicator how far a proposal is. The discussions at the meeting have shown that there many fundamental questions which are not answered or addressed by draft-gu-ppsp-peer. For instance, if the protocol aims at a low footprint on the wire which allows for instance piggy backing of chunk maps (whatever the flavor of the maps are). > > One discussion I remember well, was the discussion about how chunk maps are acutally exchanged between two peers: > - demand driven: a peer sends a chunk map request to the other chunk and waits for the response; > - piggy backed without explicit request: the peers include periodically chunk maps in the messages exchanged to update the other peer. > > The latter approach is clearly to be preferred, as speed matters, i.e., do not waste time to figure out that you need an update of the chunk maps, but let the peers to exchange that information on regular time basis. Yes. Piggybacking recent chunk availability update is a good idea (with low overhead). We found that this is important when we were designing SplendorStream, an Adobe Flash browser based P2P streaming system that I am involved with. As a technical feature, I feel that it should be supported. But I do not think that the discussion at this stage is on specifying such individual, specific features. As examples, however, they are excellent examples. An important feature of the peer protocol, I think, is that it should support a multiplexing scheme between a single pair of IP/port (peer A <-> peer B). If we call this a session, a session is bidirectional, with multiple message types going through. In the general case the session can mark different priority, different reliability, in-out-of order delivery for the messages. Those are things that I would want. >> is not a good idea, as maturity can change in a relatively short time >> period, say between two IETFs, through some intensive engineering >> efforts, and we are designing a protocol that will last a much longer >> period. Hence it is important to consider the key technical design. I > I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol proposals and the merged document raises even more questions than the predecessor documents. I am not sure what view you are opposing... Maturity cannot change in a relatively short time period? Or you think that gu-peer has its chance already and hence it is time to make a decision to move on, now? But I guess this is non-technical. So we can skip, follow your order :-) > >> would personally prefer an HTTP based protocol, if we can show that it >> works, as HTTP is really the thin waist of the Internet now. It will be > HTTP is a technical no go in time sensitive applications. It is also a no go for applications that require bi-directional communication. >> great if the authors of draft-gu-ppsp-peer would like to make their >> protocol complete, addressing the key concerns, for example, >> bi-directional HTTP communications, say using websocket, so that we can >> make a more informed decision. People mostly watch video using browsers. >> We should consider more browser-native protocols, if possible, for ppsp >> design. > RTCWEB is putting things in the browser, namely VoIP. However, they are heavily relying on RTP to exchange the time sensitive information, i.e., voice and video. This is not supporting your argument at all. To clarify, what I prefer is a protocol that is easier to be put into browsers, as this is more likely a deployment case. Let's change the name HTTP to web based. Will PPSP peer protocol consider coordination with the RTCWEB effort? >> Since the swift protocol is more completely specified at this moment, >> let me comment more on this protocol. The swift protocol is a quite >> interesting protocol. I feel that using UDP as transport is one >> potential path, as Adobe P2P is based on UDP as well. My main comments >> on swift are the following: >> >> * Are there any experimental results of swift at large scale real >> experiments? > To my understanding there are experimental results. You might argue about what large scale is. > >> * According to our experiences at building an experimental p2p streaming >> system at Yale, a real protocol quickly becomes complex as we continue >> to extend it to handle challenges in real settings. The extension scheme >> of the protocol needs careful thinking. > This has been part of the discussions at the meeting. For instance, the chunk trading mechanism must be extensible. > >> * So far the draft contains many policies. I have not been convinced >> that they are necessary. For example, > The draft describes the swift implementation right now and needs definitely work. > >> - page 4 top: "... peer connects to a random set of other peers ..." >> why random? >> >> - page 4 "... omits HAVE messages as a way of choking A." >> >> Also Page 7 on withholding HAVE. Also on Page 7 on withholding >> error messages. >> >> I typically do not like such information-hiding designs. Informed >> decisions often are better, faster decisions. >> >> - page 4 (also page 9) "... A sends a datagram containing HAVE >> messages for the chunks it just received to all its peers." Specifying >> such a push-just-received model may not be necessary. >> >> - The design is essentially pushing for an uploader centric design. >> This is unnecessary. >> >> - The idea of using a tree to introduce bins and compute hashes is >> interesting. Two comments: >> >> - I am wondering is the scheme is patented. CK Wong and Simon Lam >> presented such a design in 1998 (for disclosure, Simon Lam is my PhD >> advisor): >> http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf >> >> I am not sure if there is a patent on it. And if so, will it >> have impacts on the selection? > If you know about IPR you must declare it. See the IETF IPR rules. you == I (Richard Y :-) or the swift authors? The IPR might be held by others. The idea of hash tree was used in multiple settings, at least starting from 1998. My question is if someone (e.g., CK Wong, Simon Lam) holds an IP on it, will it have any influence on its selection (at least the process)? Thanks. Richard > The usage of merkle trees or other mechanisms will be possible in the peer protocol, but there will be also the possibility to use other mechanisms. > >> - On the other hand, I am wondering if using such a binary tree >> based design is necessary, as elaborated schemes typically can have >> limit extensibility, compared with simple straightforward schemes . In >> particular, how much savings are we talking about, at the cost of >> choosing a particular binary tree based representation scheme? Such >> information can be helpful. > I think the swift guys have papers about it. > >> To summarize, my vote is the following: >> >> - Give the draft-ppsp-gu-peer authors some time (chance) to give a more >> mature design, if the authors are willing, before we make a decision. > Why? There has been time and we need to make a decision at some time point about the peer protocol and also the tracker protocol. > > We can of course wait until the next IETF meeting, but this sort of a bet towards the future. >> - If swift is used, check the patent issue; optional, show some real >> experimental performance results; think about modular design (for >> example, more elaborate NAT/mobility handling handshake); make the >> protocol more policy neutral (e.g., by involving algorithmic designers >> to leave enough design space); make sure it is extensible in the message >> flows. > I guess, it is up to you to raise technical details which be answered technically by the swift guys. > > Martin > >> Just some quick comments as input. >> >> Thanks! >> >> Richard >> >> On 11/24/11 9:42 AM, Martin Stiemerling wrote: >>> Dear all, >>> >>> The working group has to make a decision which peer protocol proposal to >> choose as basis for the PPSP peer protocol. >>> We have to independent proposals: >>> - draft-gu-ppsp-peer-protocol-03 >>> (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) >>> - draft-grishchenko-ppsp-swift-03 >>> (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) >>> >>> Both proposals for a peer protocol have been presented at the IETF meeting. >> The slides are available here: >>> - draft-gu-ppsp-peer-protocol-03: >>> http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx >>> - draft-grishchenko-ppsp-swift-03 >>> http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf >>> >>> The feedback given at the IETF meeting about both proposals is documented >> in the draft meeting minutes: >>> http://www.ietf.org/proceedings/82/minutes/ppsp.txt >>> >>> Please state your **technical** opinion about which peer protocol proposal >> you would prefer on the PPSP mailing list until November 30th. >>> With best regards >>> >>> Yunfei and Martin >>> PPSP co-chairs >>> >>> martin.stiemerling@neclab.eu >>> > martin.stiemerling@neclab.eu > > NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 From Fabio.Picconi@technicolor.com Tue Nov 29 10:11:08 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6058211E80B5 for ; Tue, 29 Nov 2011 10:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vf2lmhWxCGzx for ; Tue, 29 Nov 2011 10:11:01 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8246011E80C0 for ; Tue, 29 Nov 2011 10:10:56 -0800 (PST) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTtUgHOFUciLLCWSRR7ZimKI1KqjKXDs/@postini.com; Tue, 29 Nov 2011 10:11:00 PST Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 29 Nov 2011 19:09:47 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Tue, 29 Nov 2011 19:09:52 +0100 From: Picconi Fabio To: Rui Cruz , Y.Richard Yang Date: Tue, 29 Nov 2011 19:09:49 +0100 Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: AcyumoQCogNtifz3S1qzA+Q9zkk05gAGQNNA Message-ID: <320C4182454E96478DC039F2C48198720481C89DB1@MOPESMBX01.eu.thmulti.com> References: <4ED48613.6070408@cs.yale.edu> <77252AAF-8CC9-4831-8DF0-352A2E02352B@ieee.org> In-Reply-To: <77252AAF-8CC9-4831-8DF0-352A2E02352B@ieee.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_320C4182454E96478DC039F2C48198720481C89DB1MOPESMBX01eut_" MIME-Version: 1.0 Cc: "ppsp@ietf.org" , LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 18:11:08 -0000 --_000_320C4182454E96478DC039F2C48198720481C89DB1MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, It's difficult to chose which mail to reply to with so many mails in the li= st today. :-) Here are my comments. First, some important things which neither the Gu nor= the Swift protocol seem to support: 1) Pull-token [1] or pull-push [2] streaming. The former is an approximatio= n of push-based streaming, which works better than pull-based when the bott= leneck is the uploader's bandwidth (which is typically the case). The latte= r is a hybrid between pull and push which achieves very low video lag with = respect to the source. If PPSP is to support a wide range of chunk scheduli= ng algorithms, then I believe it should support pull, pull-token and pull-p= ush-based streaming. 2) View-Upload Decoupling [3]. VUD greatly reduces the impact of churn. Eve= n if PPSP does not make this mandatory, I think the protocol should support= this as an extension, or at least be designed such that the next version o= f the protocol can support VUD with much pain. 3) Substreams. This is a powerful feature. You can easily support SVC, MDC,= multiple audio tracks, etc. if your protocol supports substreams. I think = PPSP should support this. Now, regarding the Gu-vs-swift diatribe: 1) Swift strives to achieve low playback latency (by using tricks such as p= iggybacking HAVE messages during handshake, etc.). I don't think this is th= at important. In commercial applications we can expect peers to start playb= ack immediately by downloading from a CDN, and move to P2P connections once= they're established. In any case, the first requests of Figure 2 of the Gu= draft (before GET_CHUNK) could certainly be merged into a single request t= o save time. 2) Merkle trees are certainly a good choice for VoD, but I'm not convinced = they're always the best solution for live streaming. If source lag is criti= cal, then individually signing each chunk will give you the lowest lag (at = the cost of extra CPU load due to signatures). If bandwidth is critical, th= e "sign-and-correct" method [4] will consumes less bandwidth than Merkle tr= ees at the expense of a slight increase in lag. I guess what I'm saying her= e is that maybe we should not force a given integrity verification mechanis= m on PPSP. 3) I agree with Enrico that using HTTP is a bad idea. I only see disadvanta= ges: you're forced to use TCP (i.e., you cannot chose another congestion co= ntrol algorithm, in-order delivery increases delay, and retransmissions pro= bably waste bandwidth), no bi-directionality, difficult NAT traversal, no e= xisting HTTP cache or proxy infrastructure to leverage here. Conversely, UD= P brings you several advantages: chose your congestion control, ignore lost= packets, STUN-like NAT traversal. And I don't see any reason to use HTTP o= ver UDP. That's is for now. Fabio [1] F. Picconi and L. Massouli=E9. Is there a future for mesh-based live vi= deo streaming? In P2P, 2008. [2] M. Zhang, Q. Zhang, L. Sun, and S. Yang, Understanding the Power of Pul= l-based Streaming Protocol: Can We Do Better? In IEEE JSAC, special issue o= n Advances in Peer-to-peer Streaming Systems, 2007. [3] D. Wu, C. Liang, Y. Liu, and K. Ross. View-Upload Decoupling: A Redesig= n of Multi-Channel P2P Video Systems. In INFOCOM, 2009. [4] P. Dhungel, X. Hei, K. W. Ross, and N. Saxena. The pollution attack in = P2P live video streaming: measurement results and defenses. In P2P-TV, 2007= . From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui= Cruz Sent: mardi 29 novembre 2011 14:26 To: Y.Richard Yang Cc: Rui Cruz; ppsp@ietf.org; LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft Hi Richard, It is very interesting your point on a Web-based P2P Streaming protocol. Bi-directional communications via Websocket is in fact the next step in a d= esign (draft-cruz-ppsp-http-peer-protocol) for the Messaging Transport laye= r, together with a Wire Representation of messages, compatible with HTTP me= thods, that our group (EU SARACEN project) is developing. And we already have working prototypes for the P2P Web Streaming Distributi= on, supporting Live and on-demand Structured Media Streaming (SVC, MVC/3D, = etc.), using a Client Media Player Application (with special modules for th= e requester/re-assember of structured media, and corresponding decoders), o= r currently as a Firefox Plug-in, but evolving for a compatible HTML5 mecha= nism. As co-author of draft-gu-ppsp-peer-protocol, I would also be very happy to = complete the key technical design of the PPSP Peer Protocol Architecture, b= ut in a very open approach, not biased for the possible wire encoding and m= essage transport formats and methods. Swift is in fact interesting, but, in my opinion, should be addressed as on= e of the Wire binary formats, currently the more mature. However, I am still not yet convinced that swift can handle (and provide in= teraction) with complex Structured Media, for example, allowing the end Use= r to switch between audio (dubbed languages or "Director Commented") stream= s of a movie or switching between subtile languages, or cooperate in the ad= aptation or scalability of the media (multi layer, multi-rate switching). And if the encoded complex structured media is segmented in rather large si= zed chunks (of 10x or 100x KiB) each chunk would have to be mapped, I suppo= se, to a quite large Hash tree to split the data in byte ranges for the dat= agrams. So, instead a a single Bin tree, a complex Structured Media with a = duration of an hour (3600 seconds) would require at least 18000 Root hashes= for chunks with 2 seconds encoded in 10 layers. Would this not be overkil= l? But a Web-based Wire format, can be another option, if, as you say, "we can= show that it works". And we (in the SARACEN project) can show that it works. ----------------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Vice-Chair IEEE Computer Society Portugal Chapter rui.cruz@ieee.org rui.cruz@computer.org On 29/11/2011, at 07:13, Y. Richard Yang wrote: Hi all, I read both specs, and the meeting minutes but missed this IETF at Taipei. = So if I am repeating some discussions already happened, please let me know. First off, I got the feeling that multiple votes for swift over draft-gu-pp= sp-peer were based on maturity, at this moment. I think this is not a good= idea, as maturity can change in a relatively short time period, say betwee= n two IETFs, through some intensive engineering efforts, and we are designi= ng a protocol that will last a much longer period. Hence it is important to= consider the key technical design. I would personally prefer an HTTP based= protocol, if we can show that it works, as HTTP is really the thin waist o= f the Internet now. It will be great if the authors of draft-gu-ppsp-peer w= ould like to make their protocol complete, addressing the key concerns, for= example, bi-directional HTTP communications, say using websocket, so that = we can make a more informed decision. People mostly watch video using brows= ers. We should consider more browser-native protocols, if possible, for pps= p design. Since the swift protocol is more completely specified at this moment, let m= e comment more on this protocol. The swift protocol is a quite interesting = protocol. I feel that using UDP as transport is one potential path, as Ado= be P2P is based on UDP as well. My main comments on swift are the following= : * Are there any experimental results of swift at large scale real experimen= ts? * According to our experiences at building an experimental p2p streaming sy= stem at Yale, a real protocol quickly becomes complex as we continue to ext= end it to handle challenges in real settings. The extension scheme of the p= rotocol needs careful thinking. * So far the draft contains many policies. I have not been convinced that t= hey are necessary. For example, - page 4 top: "... peer connects to a random set of other peers ..." why = random? - page 4 "... omits HAVE messages as a way of choking A." Also Page 7 on withholding HAVE. Also on Page 7 on withholding error m= essages. I typically do not like such information-hiding designs. Informed deci= sions often are better, faster decisions. - page 4 (also page 9) "... A sends a datagram containing HAVE messages f= or the chunks it just received to all its peers." Specifying such a push-ju= st-received model may not be necessary. - The design is essentially pushing for an uploader centric design. This = is unnecessary. - The idea of using a tree to introduce bins and compute hashes is intere= sting. Two comments: - I am wondering is the scheme is patented. CK Wong and Simon Lam pres= ented such a design in 1998 (for disclosure, Simon Lam is my PhD advisor): = http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf I am not sure if there is a patent on it. And if so, will it have i= mpacts on the selection? - On the other hand, I am wondering if using such a binary tree based = design is necessary, as elaborated schemes typically can have limit extensi= bility, compared with simple straightforward schemes . In particular, how m= uch savings are we talking about, at the cost of choosing a particular bina= ry tree based representation scheme? Such information can be helpful. To summarize, my vote is the following: - Give the draft-ppsp-gu-peer authors some time (chance) to give a more mat= ure design, if the authors are willing, before we make a decision. - If swift is used, check the patent issue; optional, show some real experi= mental performance results; think about modular design (for example, more e= laborate NAT/mobility handling handshake); make the protocol more policy ne= utral (e.g., by involving algorithmic designers to leave enough design spac= e); make sure it is extensible in the message flows. Just some quick comments as input. Thanks! Richard On 11/24/11 9:42 AM, Martin Stiemerling wrote: Dear all, The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --_000_320C4182454E96478DC039F2C48198720481C89DB1MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, It’s difficult to chose which mail to reply to with so many mails in the list today. :-) Here are my comments. First, some important things which nei= ther the Gu nor the Swift protocol seem to support: 1) Pull-token [1] or pull-push [2] streaming. The former is = an approximation of push-based streaming, which works better than pull-based w= hen the bottleneck is the uploader’s bandwidth (which is typically the ca= se). The latter is a hybrid between pull and push which achieves very low video = lag with respect to the source. If PPSP is to support a wide range of chunk sch= eduling algorithms, then I believe it should support pull, pull-token and pull-push= -based streaming. 2) View-Upload Decoupling [3]. VUD greatly reduces the impac= t of churn. Even if PPSP does not make this mandatory, I think the protocol shou= ld support this as an extension, or at least be designed such that the next version of= the protocol can support VUD with much pain. 3) Substreams. This is a powerful feature. You can easily support SVC, MDC, multiple audio tracks, etc. if your protocol supports sub= streams. I think PPSP should support this. Now, regarding the Gu-vs-swift diatribe: 1) Swift strives to achieve low playback latency (by using tricks such as piggybacking HAVE messages during handshake, etc.). I don= 217;t think this is that important. In commercial applications we can expect peer= s to start playback immediately by downloading from a CDN, and move to P2P connections once they’re established. In any case, the first requests= of Figure 2 of the Gu draft (before GET_CHUNK) could certainly be merged into = a single request to save time. 2) Merkle trees are certainly a good choice for VoD, but I&#= 8217;m not convinced they’re always the best solution for live streaming. If= source lag is critical, then individually signing each chunk will give you the low= est lag (at the cost of extra CPU load due to signatures). If bandwidth is critical= , the “sign-and-correct” method [4] will consumes less bandwidth than Merkle trees at the expense of a slight increase in lag. I guess what IR= 17;m saying here is that maybe we should not force a given integrity verificatio= n mechanism on PPSP. 3) I agree with Enrico that using HTTP is a bad idea. I only= see disadvantages: you’re forced to use TCP (i.e., you cannot chose anoth= er congestion control algorithm, in-order delivery increases delay, and retransmissions probably waste bandwidth), no bi-directionality, difficult NAT traversal, n= o existing HTTP cache or proxy infrastructure to leverage here. Conversely, U= DP brings you several advantages: chose your congestion control, ignore lost p= ackets, STUN-like NAT traversal. And I don’t see any reason to use HTTP over = UDP. That’s is for now. Fabio [1] F. Picconi and L. Massouli=E9. Is there a future for mesh-based live video streaming? In P2P, 2008. [2] M. Zhang, Q. Zhang, L. Sun, and S. Yang, Understanding t= he Power of Pull-based Streaming Protocol: Can We Do Better? In IEEE JSAC, spe= cial issue on Advances in Peer-to-peer Streaming Systems, 2007. [3] D. Wu, C. Liang, Y. Liu, and K. Ross. View-Upload Decoupling: A Redesign of Multi-Channel P2P Video Systems. In INFOCOM, 2009= . [4] P. Dhungel, X. Hei, K. W. Ross, and N. Saxena. The pollu= tion attack in P2P live video streaming: measurement results and defenses. In P2P-TV, 2007. From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Ru= i Cruz Sent: mardi 29 novembre 2011 14:26 To: Y.Richard Yang Cc: Rui Cruz; ppsp@ietf.org; LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft= Hi Richard, It is very interesting your point on a Web-based P2P Streaming protocol. Bi-directional communications via Websocket is in fact= the next step in a design (draft-cruz-ppsp-http-peer-protocol) for the Messagin= g Transport layer, together with a Wire Representation of messages, compatibl= e with HTTP methods, that our group (EU SARACEN project) is developing.<= /o:p> And we already have working prototypes for the P2P Web Streaming Distribution, supporting Live and on-demand Structured Media Streaming (SVC, MVC/3D, etc.), using a Client Media Player Application (wit= h special modules for the requester/re-assember of structured media, and corresponding decoders), or currently as a Firefox Plug-in, but evolving fo= r a compatible HTML5 mechanism. As co-author of draft-gu-ppsp-peer-protocol, I would a= lso be very happy to complete the key technical design of the PPSP Peer Protocol Architecture, but in a very open approach, not biased for the possible wire encoding and message transport formats and methods. Swift is in fact interesting, but, in my opinio= n, should be addressed as one of the Wire binary formats, currently the more mature. However, I am still not yet convinced that swift can h= andle (and provide interaction) with complex Structured Media, for example, allow= ing the end User to switch between audio (dubbed languages or "Director Commented") streams of a movie or switching between subtile languages,= or cooperate in the adaptation or scalability of the media (multi layer, multi-rate switching). And if the encoded complex structured media is segment= ed in rather large sized chunks (of 10x or 100x KiB) each chunk would have= to be mapped, I suppose, to a quite large Hash tree to split the data in = byte ranges for the datagrams. So, instead a a single Bin tree, a complex Structured Media with a duration of an hour (3600 seconds) wou= ld require at least 18000 Root hashes for chunks with 2 seconds encoded in 10 layers. Would this not be overkill? But a Web-based Wire format, can be another option, if= , as you say, "we can show that it works". And we (in the SARACEN project) can show that it works. ----------------------------------- Best Regards,= <= br> Prof. Rui Santos Cruz Chairman<= br> IEEE Portugal Section Vice-Chair<= br> IEEE Computer Society Portugal Chapter rui.cruz@ieee.org rui.cruz@computer.org On 29/11/2011, at 07:13, Y. Richard Yang wrote: Hi all, I read both specs, and the meeting minutes but missed this IETF at Taipei. = So if I am repeating some discussions already happened, please let me know. First off, I got the feeling that multiple votes for swift over draft-gu-ppsp-peer were based on maturity, at this moment. I think th= is is not a good idea, as maturity can change in a relatively short time perio= d, say between two IETFs, through some intensive engineering efforts, and we a= re designing a protocol that will last a much longer period. Hence it is impor= tant to consider the key technical design. I would personally prefer an HTTP bas= ed protocol, if we can show that it works, as HTTP is really the thin waist of= the Internet now. It will be great if the authors of draft-gu-ppsp-peer would l= ike to make their protocol complete, addressing the key concerns, for example, bi-directional HTTP communications, say using websocket, so that we can mak= e a more informed decision. People mostly watch video using browsers. We should consider more browser-native protocols, if possible, for ppsp design. Since the swift protocol is more completely specified at this moment, let m= e comment more on this protocol. The swift protocol is a quite interesting protocol. I feel that using UDP as transport is one potential path, a= s Adobe P2P is based on UDP as well. My main comments on swift are the follow= ing: * Are there any experimental results of swift at large scale real experimen= ts? * According to our experiences at building an experimental p2p streaming sy= stem at Yale, a real protocol quickly becomes complex as we continue to extend i= t to handle challenges in real settings. The extension scheme of the protocol ne= eds careful thinking. * So far the draft contains many policies. I have not been convinced that t= hey are necessary. For example, - page 4 top: "... peer connects to a random set of other peers ..." why random? - page 4 "... omits HAVE messages as a way of choking A.&q= uot; Also Page 7 on withholding HAVE. Also on Page= 7 on withholding error messages. I typically do not like such information-hidi= ng designs. Informed decisions often are better, faster decisions. - page 4 (also page 9) "... A sends a datagram containing = HAVE messages for the chunks it just received to all its peers." Specifying such a push-just-received model may not be necessary. - The design is essentially pushing for an uploader centric des= ign. This is unnecessary. - The idea of using a tree to introduce bins and compute hashes= is interesting. Two comments: - I am wondering is the scheme is patented. C= K Wong and Simon Lam presented such a design in 1998 (for disclosure, Simon L= am is my PhD advisor): http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf I am not sure if there is a patent on it. And if so, will it have impacts on the selection? - On the other hand, I am wondering if using = such a binary tree based design is necessary, as elaborated schemes typically ca= n have limit extensibility, compared with simple straightforward schemes . In particular, how much savings are we talking about, at the cost of choosing = a particular binary tree based representation scheme? Such information can be helpful. To summarize, my vote is the following: - Give the draft-ppsp-gu-peer authors some time (chance) to give a more mat= ure design, if the authors are willing, before we make a decision. - If swift is used, check the patent issue; optional, show some real experimental performance results; think about modular design (for example, = more elaborate NAT/mobility handling handshake); make the protocol more policy neutral (e.g., by involving algorithmic designers to leave enough design space); make sure it is extensible in the message flows. Just some quick comments as input. Thanks! Richard On 11/24/11 9:42 AM, Martin Stiemerling wrote: Dear all, The working group has to make a decision which peer pr= otocol proposal to choose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://t= ools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://= tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented= at the IETF meeting. The slides are available here: - draft-gu-ppsp-peer-protocol-03: http://www.i= etf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http://www.ie= tf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both prop= osals is documented in the draft meeting minutes: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which pe= er protocol proposal you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin= .stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NE= C Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6= BL | Registered in England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --_000_320C4182454E96478DC039F2C48198720481C89DB1MOPESMBX01eut_-- From njaal.borch@gmail.com Tue Nov 29 10:16:37 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8614521F8B70 for ; Tue, 29 Nov 2011 10:16:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wv6wiip3FUdD for ; Tue, 29 Nov 2011 10:16:35 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B57721F891D for ; Tue, 29 Nov 2011 10:16:34 -0800 (PST) Received: by faap14 with SMTP id p14so1233112faa.31 for ; Tue, 29 Nov 2011 10:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=pW7HipZuAXq/4Y4RKy8TCp/XQ4LFsdZVOi9xrrNXSx0=; b=dOS+xaczXmWgyB/0k9XguKVmh2jRjveYZkEDNYA/wd4emDamIp+q5yyjxzPxMHqMpQ LvK/SuipfBV696yqcL+WKjG1XicSGcXZ9HZATuxaZzqfSTSgPjnhq9RecazjFl/UaFZF 36h6TFTG+p5Kzv9ZbqEqFpSNJXsU7OvmxRxp4= MIME-Version: 1.0 Received: by 10.204.157.156 with SMTP id b28mr50329619bkx.133.1322590588789; Tue, 29 Nov 2011 10:16:28 -0800 (PST) Sender: njaal.borch@gmail.com Received: by 10.204.185.132 with HTTP; Tue, 29 Nov 2011 10:16:28 -0800 (PST) Received: by 10.204.185.132 with HTTP; Tue, 29 Nov 2011 10:16:28 -0800 (PST) In-Reply-To: <4ED4FA84.5080408@cs.vu.nl> References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> <000901ccae5d$f49dde00$ddd99a00$@yale.edu> <4ED4FA84.5080408@cs.vu.nl> Date: Tue, 29 Nov 2011 19:16:28 +0100 X-Google-Sender-Auth: e_hwfSesbbZCdclLssHFG3haiN8 Message-ID: From: Njaal Borch To: arno@cs.vu.nl Content-Type: multipart/alternative; boundary=0015175df1703a621e04b2e39e81 Cc: ppsp@ietf.org Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 18:16:37 -0000 --0015175df1703a621e04b2e39e81 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As swift is based on a tree structure for hashes, requests and availability, high speed connections can move the exchanged messages to higher levels. In other words, peers can dynamically adjust both request, hash checks, acks and have messages pr connection as they see fit, reducing overhead when connections are good while keeping control when connectivity is less good. In my opinion, local decisions are king in p2p networks, and simple will almost always beat complex. Regards, N On Nov 29, 2011 4:28 PM, "Arno Bakker" wrote: > On 29/11/2011 07:12, Ye Wang wrote: > >> >> Another example is regarding the debate on the push/pull of the bitmap. >> When our system works with low-capacity video source (e.g., a single >> server) and small chunk size, we build an overlay network with multi-hop >> diameter, and it turns out the push scheme performs better as it is an >> efficient way for the peers to discover the newest/rarest chunks in the >> channel, even though it consumes around 10% of the peer upload capacity; >> but when we have large-capacity source (e.g., a set of CDN access >> points) and large chunk size (e.g., to accommodate HTTP overhead when >> working with CDN), the pull based scheme actually saves peer uplink >> resource, since the overlay structure is not =E2=80=9Cdeep=E2=80=9D, so = each peer just >> need to request neighbors about their chunk availability =E2=80=9Con dem= and=E2=80=9D (as >> long as their neighbor=E2=80=99s capacity is already efficiently utilize= d) >> because it can always fetch from source if it is not happy about the >> progress. >> >> > Hi > > if you have the need for a GET_HAVE/GET_CHUNKMAP message we can add that > to swift, no problem. A complex problem, however, is to determine when to > switch from push to pull based, as capacity at the source will vary > depending on the number of peers in the swarm. Did you already design a > solution for that? > > CU, > Arno > ______________________________**_________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/**listinfo/ppsp > --0015175df1703a621e04b2e39e81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As swift is based on a tree structure for hashes, requests and availabil= ity, high speed connections can move the exchanged messages to higher level= s. In other words, peers can dynamically adjust both request, hash checks, = acks and have messages pr connection as they see fit, reducing overhead whe= n connections are good while keeping control when connectivity is less good= . In my opinion, local decisions are king in p2p networks, and simple will = almost always beat complex. Regards, N On Nov 29, 2011 4:28 PM, "Arno Bakker"= <arno@cs.vu.nl> wrote: On 29/11/2011 07:12, Ye Wang wrote: Another example is regarding the debate on the push/pull of the bitmap. When our system works with low-capacity video source (e.g., a single server) and small chunk size, we build an overlay network with multi-hop diameter, and it turns out the push scheme performs better as it is an efficient way for the peers to discover the newest/rarest chunks in the channel, even though it consumes around 10% of the peer upload capacity; but when we have large-capacity source (e.g., a set of CDN access points) and large chunk size (e.g., to accommodate HTTP overhead when working with CDN), the pull based scheme actually saves peer uplink resource, since the overlay structure is not =E2=80=9Cdeep=E2=80=9D, so eac= h peer just need to request neighbors about their chunk availability =E2=80=9Con demand= =E2=80=9D (as long as their neighbor=E2=80=99s capacity is already efficiently utilized)<= br> because it can always fetch from source if it is not happy about the progress. Hi if you have the need for a GET_HAVE/GET_CHUNKMAP message we can add that to= swift, no problem. A complex problem, however, is to determine when to swi= tch from push to pull based, as capacity at the source will vary depending = on the number of peers in the swarm. Did you already design a solution for = that? CU, =C2=A0 =C2=A0Arno _______________________________________________ ppsp mailing list ppsp@ietf.org ht= tps://www.ietf.org/mailman/listinfo/ppsp --0015175df1703a621e04b2e39e81-- From peer2peer@gmail.com Tue Nov 29 10:56:29 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5250E21F8A7E for ; Tue, 29 Nov 2011 10:56:29 -0800 (PST) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD1FR9RpRuVx for ; Tue, 29 Nov 2011 10:56:28 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A51D21F8A71 for ; Tue, 29 Nov 2011 10:56:25 -0800 (PST) Received: by eear51 with SMTP id r51so1426660eea.31 for ; Tue, 29 Nov 2011 10:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=shYPhK3ZXPi+wP3DJvJ8d90ix15Xl5lNGSTHqxVsVPM=; b=R+ITC4lVYYp8dmKxKKi9fGlVuGn8PdfbasczhK/+WGEl+syuSOKL/x3izxqCvxPfGT x+Uk0/6r7btXDGK6hev/AU5Kwqi8UF/RpLA7+Nu26YVndtweCpNhU2XmiF335g4drhQG V4p9mPaVlOJdkl2SyXMPsXlJ0eCoseARvlTtw= MIME-Version: 1.0 Received: by 10.227.198.213 with SMTP id ep21mr31216161wbb.18.1322592983306; Tue, 29 Nov 2011 10:56:23 -0800 (PST) Received: by 10.180.100.170 with HTTP; Tue, 29 Nov 2011 10:56:23 -0800 (PST) In-Reply-To: <320C4182454E96478DC039F2C48198720481C89DB1@MOPESMBX01.eu.thmulti.com> References: <4ED48613.6070408@cs.yale.edu> <77252AAF-8CC9-4831-8DF0-352A2E02352B@ieee.org> <320C4182454E96478DC039F2C48198720481C89DB1@MOPESMBX01.eu.thmulti.com> Date: Tue, 29 Nov 2011 19:56:23 +0100 Message-ID: From: Johan Pouwelse To: "ppsp@ietf.org" , Picconi Fabio Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 18:56:29 -0000 Reply inline... On 29 November 2011 19:09, Picconi Fabio wr= ote: > 1) Pull-token [1] or pull-push [2] streaming. The former is an approximat= ion > of push-based streaming, which works better than pull-based when the > bottleneck is the uploader=92s bandwidth (which is typically the case). = [snip] Very true. At this stage we need to select one of the 2 peer protocols. Making it "better-then-perfect" is a job for 2012 I guess. With our real-world usage of streaming technology, we found that a solid implementation is at least as valuable as a sophisticated/(simple) algorithm. Hopefully we can start an organised venture test various approaches. In my opinion Libswift is push/pull agnostic and should support all. > 2) View-Upload Decoupling [3]. VUD greatly reduces the impact of churn. E= ven > if PPSP does not make this mandatory [snip] Yes, the Libswift architecture is implicitly designed for this important use-case. We (the people behind Libswift) are very aware of the View-Upload Decoupling work. In 2006 we got an implementation working called 2Fast: http://pds.twi.tudelft.nl/~pawel/pub/2fast_p2p.pdf > 3) Substreams. This is a powerful feature. You can easily support SVC, MD= C, > multiple audio tracks, etc. if your protocol supports substreams. I think > PPSP should support this. Yes, very true. Powerful stuff. Once we converged on a single peer protocol, it's time to create optional SVC/MDC expansions. This technology is now slowly getting a bit mature, for instance, the work on the ISO Standard (ISO/IEC 23009-1) . Greetings, johan. From Fabio.Picconi@technicolor.com Tue Nov 29 11:52:15 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990BC21F8AFF for ; Tue, 29 Nov 2011 11:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz3xKN+HI1P6 for ; Tue, 29 Nov 2011 11:52:12 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aob106.obsmtp.com [74.125.149.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9506E21F8AFB for ; Tue, 29 Nov 2011 11:52:10 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTtU348eixGEohN4V2mcL3vI2YW375HW/@postini.com; Tue, 29 Nov 2011 11:52:11 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 29 Nov 2011 20:47:55 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Tue, 29 Nov 2011 20:47:58 +0100 From: Picconi Fabio To: Johan Pouwelse , "ppsp@ietf.org" Date: Tue, 29 Nov 2011 20:47:56 +0100 Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: AcyuyJsrGY/goFkTTBSlxrwFrNVWVgAAPvoA Message-ID: <320C4182454E96478DC039F2C48198720481C89E6B@MOPESMBX01.eu.thmulti.com> References: <4ED48613.6070408@cs.yale.edu> <77252AAF-8CC9-4831-8DF0-352A2E02352B@ieee.org> <320C4182454E96478DC039F2C48198720481C89DB1@MOPESMBX01.eu.thmulti.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 19:52:15 -0000 I'm not sure that Swift is push/pull agnostic. Swift HINTs resemble download requests (as in pull-based systems), but they= 're not because the uploader is not forced to serve them. I would say Swift resembles more a push-based system, because the uploader = makes a peer/chunk scheduling decision based on some information it has abo= ut its neighbors (in this case, the HINTed chunks). In fact, HINTs resemble= the pull-token mechanism that I mentioned in my previous email, which is a= n approximation of a push-based system. The difference is that the pull-tok= en mechanism allows for a better-informed (and thus more useful) chunk sele= ction, at the cost of an additional RTT due to signaling. By the way, I find it weird that peers cannot UNHINT a HINTed chunk. Or may= be I missed something. UNHINTing chunks would be useful if the peer wants t= o request an already HINTed chunk from a different peer (e.g., if that chun= k is still missing and it is getting dangerously close to the deadline).=20 Fabio -----Original Message----- From: Johan Pouwelse [mailto:peer2peer@gmail.com]=20 Sent: mardi 29 novembre 2011 19:56 To: ppsp@ietf.org; Picconi Fabio Subject: Re: [ppsp] Selection of PPSP peer protocol draft Reply inline... On 29 November 2011 19:09, Picconi Fabio wr= ote: > 1) Pull-token [1] or pull-push [2] streaming. The former is an approximat= ion > of push-based streaming, which works better than pull-based when the > bottleneck is the uploader's bandwidth (which is typically the case). [s= nip] Very true. At this stage we need to select one of the 2 peer protocols. Making it "better-then-perfect" is a job for 2012 I guess. With our real-world usage of streaming technology, we found that a solid implementation is at least as valuable as a sophisticated/(simple) algorithm. Hopefully we can start an organised venture test various approaches. In my opinion Libswift is push/pull agnostic and should support all. > 2) View-Upload Decoupling [3]. VUD greatly reduces the impact of churn. E= ven > if PPSP does not make this mandatory [snip] Yes, the Libswift architecture is implicitly designed for this important use-case. We (the people behind Libswift) are very aware of the View-Upload Decoupling work. In 2006 we got an implementation working called 2Fast: http://pds.twi.tudelft.nl/~pawel/pub/2fast_p2p.pdf > 3) Substreams. This is a powerful feature. You can easily support SVC, MD= C, > multiple audio tracks, etc. if your protocol supports substreams. I think > PPSP should support this. Yes, very true. Powerful stuff. Once we converged on a single peer protocol, it's time to create optional SVC/MDC expansions. This technology is now slowly getting a bit mature, for instance, the work on the ISO Standard (ISO/IEC 23009-1) . Greetings, johan. From rui.cruz@ieee-pt.org Tue Nov 29 13:24:42 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99FB11E80D0 for ; Tue, 29 Nov 2011 13:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.298 X-Spam-Level: X-Spam-Status: No, score=-102.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3pa0Z1QLtfR for ; Tue, 29 Nov 2011 13:24:37 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 83CC311E80C4 for ; Tue, 29 Nov 2011 13:24:35 -0800 (PST) Received: by faap14 with SMTP id p14so147382faa.31 for ; Tue, 29 Nov 2011 13:24:35 -0800 (PST) Received: by 10.180.102.233 with SMTP id fr9mr793056wib.40.1322601875174; Tue, 29 Nov 2011 13:24:35 -0800 (PST) Received: from [192.168.1.68] (89-180-34-53.net.novis.pt. [89.180.34.53]) by mx.google.com with ESMTPS id ca18sm15998916wib.13.2011.11.29.13.24.32 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 13:24:33 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_7CA6BDCD-A11B-44CB-9D91-C2AAE1DEE67A" From: Rui Cruz In-Reply-To: Date: Tue, 29 Nov 2011 21:24:30 +0000 Message-Id: References: <4ED48613.6070408@cs.yale.edu> To: Martin Stiemerling X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , "ppsp@ietf.org" , LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 21:24:42 -0000 --Apple-Mail=_7CA6BDCD-A11B-44CB-9D91-C2AAE1DEE67A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, Read inline please.... On 29/11/2011, at 15:13, Martin Stiemerling wrote: > [speaking as individual contributor and not as chair of the PPSP WG] >=20 >=20 >> is not a good idea, as maturity can change in a relatively short time >> period, say between two IETFs, through some intensive engineering >> efforts, and we are designing a protocol that will last a much longer >> period. Hence it is important to consider the key technical design. I >=20 > I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 = protocol proposals and the merged document raises even more questions = than the predecessor documents.=20 >=20 The only explicit mention to a merger of 2 proposals are related to the = Tracker protocol, not to the Peer Protocol. Nowhere in the gu-ppsp-peer draft nor in the corresponding presentation = at the iETF meeting, is mentioned any merger of two previous peer = protocol proposals.=20 The only "merger" that happened related with the Peer Protocol was of = the people working on the draft.=20 Unfortunately, due to time limitations, it was not possible for us to = write all the details we were willing to write in that draft document, = hoping that the discussion during the WG meeting would allow us to = capture the "advantages", the "features", the "extensions", etc. = considered as suitable for the improvement of the design.=20 >=20 >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_7CA6BDCD-A11B-44CB-9D91-C2AAE1DEE67A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin, Read inline please.... On 29/11/2011, at 15:13, Martin Stiemerling = wrote: [speaking as individual contributor and not as chair = of the PPSP WG] is not a good idea, = as maturity can change in a relatively short = time period, say between two = IETFs, through some intensive engineering efforts, and we are designing a protocol that will last a = much longer period. Hence it = is important to consider the key technical design. = I I oppose this view, as draft-gu-ppsp-peer is = already a merger of 2 protocol proposals and the merged document raises = even more questions than the predecessor documents. = The only explicit mention = to a merger of 2 proposals are related to the Tracker protocol, not to = the Peer Protocol. Nowhere in the gu-ppsp-peer draft nor = in the corresponding presentation at the iETF meeting, is = mentioned any merger of two previous peer protocol = proposals. The only "merger" that happened related with = the Peer Protocol was of the people working on the = draft. Unfortunately, due to time = limitations, it was not possible for us to write all the details we were = willing to write in that draft document, hoping that the discussion = during the WG meeting would allow us to capture the "advantages", the = "features", the "extensions", etc. considered as suitable for the = improvement of the design. martin.stiemerling@neclab.eu<= /a> NEC Laboratories Europe - Network Research Division NEC = Europe Limited | Registered Office: NEC House, 1 Victoria Road, London = W3 6BL | Registered in England = 2832014 _______________________________________________ ppsp = mailing = list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp = --Apple-Mail=_7CA6BDCD-A11B-44CB-9D91-C2AAE1DEE67A-- From rui.cruz@ieee-pt.org Tue Nov 29 14:30:09 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B00021F8B26 for ; Tue, 29 Nov 2011 14:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OydjwlExpfn for ; Tue, 29 Nov 2011 14:30:05 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9991421F8B23 for ; Tue, 29 Nov 2011 14:30:04 -0800 (PST) Received: by faap14 with SMTP id p14so202062faa.31 for ; Tue, 29 Nov 2011 14:30:03 -0800 (PST) Received: by 10.180.0.100 with SMTP id 4mr48528278wid.48.1322605803637; Tue, 29 Nov 2011 14:30:03 -0800 (PST) Received: from [192.168.1.68] (89-180-34-53.net.novis.pt. [89.180.34.53]) by mx.google.com with ESMTPS id c2sm44174267wbo.3.2011.11.29.14.30.01 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 14:30:02 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B94AF0-C8CF-4631-8CDD-8F87A8296B84" From: Rui Cruz In-Reply-To: Date: Tue, 29 Nov 2011 22:29:59 +0000 Message-Id: <24F1F5ED-9D68-45C0-A455-7CBEAB86E227@ieee.org> References: To: George Milescu X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , "ppsp@ietf.org" Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 22:30:09 -0000 --Apple-Mail=_E3B94AF0-C8CF-4631-8CDD-8F87A8296B84 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi,=20 See comments inline. On 29/11/2011, at 14:54, George Milescu wrote: > On Thu, Nov 24, 2011 at 16:42, Martin Stiemerling > wrote: >> Please state your **technical** opinion about which peer protocol = proposal you would prefer on the PPSP mailing list until November 30th. >=20 > Hello all. >=20 > I represent University POLITEHNICA of Bucharest, the largest technical > university in Romania. For the past few years we developed a research > group studying P2P protocols. We focused on congestion problems, > overlay enhancements, wire-protocol analysis. >=20 > Our vote goes to the Swift proposal [1] for the following reasons: >=20 > * Cruz+Gu uses HTTP as a P2P protocol basis. This requires a double > amount of connections to be created between peers and introduces a > potential asymmetry in the design. Increasing the number of > connections also creates problems regarding NAT traversal. Having the > nodes run HTTP servers does not allow the creation of lightweight > clients. >=20 Sorry but that is not correct. The draft DOES NOT uses HTTP as P2P = protocol basis.=20 Quote from the draft text: "The encoding for the signaling messages is = not yet decided. Two encodings are proposed, a Text-based (HTTP/XML) = and a Binary-based described in Appendixes A and B. The authors will = raise more discussion on the encoding, and will move the one that gets = rough consensus of the PPSP WG to the draft text." >=20 > [1] http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03 >=20 > Best regards, > George >=20 > --=20 > George Milescu > Teaching Assistant > University POLITEHNICA of Bucharest > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp Best Regards, Rui Cruz= --Apple-Mail=_E3B94AF0-C8CF-4631-8CDD-8F87A8296B84 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 29/11/2011, at 14:54, George Milescu wrote: On = Thu, Nov 24, 2011 at 16:42, Martin Stiemerling <Martin.Stiemerling@neclab.eu<= /a>> wrote: Please state your = **technical** opinion about which peer protocol proposal you would = prefer on the PPSP mailing list until November = 30th. Hello all. I represent University = POLITEHNICA of Bucharest, the largest technical university in = Romania. For the past few years we developed a research group = studying P2P protocols. We focused on congestion problems, overlay = enhancements, wire-protocol analysis. Our vote goes to the Swift = proposal [1] for the following reasons: * Cruz+Gu uses HTTP as a = P2P protocol basis. This requires a double amount of connections to = be created between peers and introduces a potential asymmetry in the = design. Increasing the number of connections also creates problems = regarding NAT traversal. Having the nodes run HTTP servers does not = allow the creation of = lightweight clients. Sorr= y but that is not correct. The draft DOES NOT uses HTTP as P2P protocol = basis. Quote from the draft text: "The encoding = for the signaling messages is not yet decided. Two encodings are = proposed, a Text-based (HTTP/XML) and a Binary-based described in = Appendixes A and B. The authors will raise more discussion on = the encoding, and will move the one that gets rough consensus of the = PPSP WG to the draft text." [1] http:/= /tools.ietf.org/html/draft-grishchenko-ppsp-swift-03 Best = regards, George -- George Milescu Teaching = Assistant University POLITEHNICA of = Bucharest _______________________________________________ ppsp = mailing list ppsp@ietf.org https://www.ietf.org/ma= ilman/listinfo/ppsp Best = Regards, Rui Cruz = --Apple-Mail=_E3B94AF0-C8CF-4631-8CDD-8F87A8296B84-- From rui.cruz@ieee-pt.org Tue Nov 29 15:34:17 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9342F1F0C4C for ; Tue, 29 Nov 2011 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.065 X-Spam-Level: X-Spam-Status: No, score=-103.065 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+TQ62pf45fd for ; Tue, 29 Nov 2011 15:34:16 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF5A21F8BEE for ; Tue, 29 Nov 2011 15:34:16 -0800 (PST) Received: by eabm6 with SMTP id m6so4274731eab.31 for ; Tue, 29 Nov 2011 15:34:15 -0800 (PST) Received: by 10.180.83.129 with SMTP id q1mr43448260wiy.55.1322609655399; Tue, 29 Nov 2011 15:34:15 -0800 (PST) Received: from [192.168.1.68] ([89.180.34.53]) by mx.google.com with ESMTPS id c2sm39438wbo.3.2011.11.29.15.34.13 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 15:34:14 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_483D456A-6BAF-4807-B48F-A28CB02C8B1D" From: Rui Cruz In-Reply-To: <4ED4F7E9.5090308@cs.vu.nl> Date: Tue, 29 Nov 2011 23:34:12 +0000 Message-Id: References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> <4ED4F7E9.5090308@cs.vu.nl> To: arno@cs.vu.nl X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 23:34:17 -0000 --Apple-Mail=_483D456A-6BAF-4807-B48F-A28CB02C8B1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29/11/2011, at 15:19, Arno Bakker wrote: > On 29/11/2011 01:17, Rui Cruz wrote: >>=20 >> *Alternative 1:* one draft would proceed describing the Protocol >> Architecture, Semantics, Syntax and Logic, and the other draft the = way >> to implement the Wire Format/Encoding layer and Message Transport = layer, >> suggesting and justifying Network Transport preferences. >=20 > Hi >=20 > the SARACEN project obviously has an architecture already specified, = so by all means determine what things you need from the peer protocol to = implement this architecture. I'll clarify a few points about swift = below. Hi Arno, The SARACEN project System architecture may use P2P for Media streaming, = or not. And the SARACEN Platform architecture DID NOT determine the = design of the P2P Streaming Protocols. It is in fact quite the opposite, = as the P2P Streaming Protocols being developed have constrained the = design of the Distribution Network of SARACEN System. You could also say that the Swift protocol, was "determined" by/from the = design of P2PNext project solution, as an alternative or an evolved = mechanism.=20 But I clearly stated in my message that "I am in favor of Swift as a = Wire Format and Message Transport candidate for the PPSP Peer Protocol", = and justified it technically, not politically. >=20 >=20 >> =46rom what is written in the swift description draft, there is no >> interaction with the Media Player apart from feeding it with the >=20 > In Section 8 of the swift proposal, on Extensibility we discuss how we = support different chunk/piece selection policies. So swift will support = custom chunk selection algorithms that can be plugged into the base = protocol and which determine what chunks are downloaded from whom. Chunk/Piece selection policies, from your description, are algorithms at = the Peer Agent level, not related with interaction with external = applications like the Media Player, unless you consider the Media Player = as an integral component of the Peer Agent, and all gets mixed up, = protocols, policies, scheduling, media decoding, etc.=20 What I said, is: the Peer Agent should not decide by itself on starting = the streaming process, but should respect at any moment the orders = received from the Media Player to fetch the desired media (the chunks = from a specific interval in the media timeline) in the case of VoD. = Apparently, swift, without a future extension is not yet capable of that = interaction, meaning that a User, once triggered a stream has to watch = it since the very beginning and is not allowed to select a future = presentation time (go forward). >>=20 >> About the support of Structured Media, I could not see evidence of = that, >=20 > One such chunk selection algorithm can be one that understands SVC. In = the simplest case there is a metadata specification that tells the = SVC-aware algorithm what layers there are and how they map to chunk IDs. > E.g. layer 0 is chunks 0..1000, layer 1 is chunks 1001...2001, etc. That is considering a single media container file with all layers in = sequence in order to be split by byte ranges (chunks). That does not solve the multiple representations (audio, video, = subtitles), that should all be multiplexed in the container. And that would require LARGE Chunkmaps at all the Peers, eventually very = sparse (if Users were allowed to jump forward and backward in the media)=20= How could the User select at any moment the desired representation to = watch/hear/read? =20 > Then, based on information from the base protocol about bandwidth and = chunk availability the SVC-aware algorithm will select the chunks for = the layers it can support. So, the Peer is, once again, involved in media decoding process, not the = Media Player Application. > We've been publishing on SVC/MDC and P2P since before 2004. As a = matter of fact Riccardo is presenting a paper on chunk selection next = week at IEEE ISM2011, so we know about structured media ;o) I am not arguing about your knowledge on Structured media, but on how = the P2P Streaming Protocol supports (although not directly involved i = decoding processes) Structured Media.=20 But you did not answer my question for the example I gave of a content = with multiple playable segments of complex structured Media. How would swift stream such a content? =20 >=20 > CU, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_483D456A-6BAF-4807-B48F-A28CB02C8B1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 29/11/2011, at 15:19, Arno Bakker wrote: On = 29/11/2011 01:17, Rui Cruz wrote: *Alternative = 1:* one draft would proceed describing the = Protocol Architecture, = Semantics, Syntax and Logic, and the other draft the = way to implement the Wire = Format/Encoding layer and Message Transport = layer, suggesting and = justifying Network Transport = preferences. Hi the SARACEN project obviously = has an architecture already specified, so by all means determine what = things you need from the peer protocol to implement this architecture. = I'll clarify a few points about swift = below. Hi = Arno, The SARACEN project System architecture = may use P2P for Media streaming, or not. And the SARACEN Platform = architecture DID NOT determine the design of the P2P Streaming = Protocols. It is in fact quite the opposite, as the P2P Streaming = Protocols being developed have constrained the design of the = Distribution Network of SARACEN System. You = could also say that the Swift protocol, was "determined" by/from the = design of P2PNext project solution, as an alternative or an evolved = mechanism. But I clearly stated in = my message that "I am in favor of Swift as a Wire Format and Message = Transport candidate for the PPSP Peer Protocol", and = justified it technically, not politically. =46rom what is = written in the swift description draft, there is = no interaction with the Media = Player apart from feeding it with the In Section 8 = of the swift proposal, on Extensibility we discuss how we support = different chunk/piece selection policies. So swift will support custom = chunk selection algorithms that can be plugged into the base protocol = and which determine what chunks are downloaded from = whom. Chunk/Piece selection = policies, from your description, are algorithms at the Peer Agent level, = not related with interaction with external applications like the Media = Player, unless you consider the Media Player as an integral component of = the Peer Agent, and all gets mixed up, protocols, policies, scheduling, = media decoding, etc. What I said, is: = the Peer Agent should not decide by itself on starting the = streaming process, but should respect at any moment the orders received = from the Media Player to fetch the desired media (the chunks from a = specific interval in the media timeline) in the case of VoD. = Apparently, swift, without a future extension is not yet capable of that = interaction, meaning that a User, once triggered a stream has to watch = it since the very beginning and is not allowed to select a future = presentation time (go forward). About the support of Structured Media, I could not see = evidence of that, One such chunk selection algorithm = can be one that understands SVC. In the simplest case there is a = metadata specification that tells the SVC-aware algorithm what layers = there are and how they map to chunk IDs. E.g. layer 0 is chunks = 0..1000, layer 1 is chunks 1001...2001, = etc. That is considering a = single media container file with all layers in sequence in order to be = split by byte ranges (chunks). That does not solve the = multiple representations (audio, video, subtitles), that should all be = multiplexed in the container. And that would require LARGE = Chunkmaps at all the Peers, eventually very sparse (if Users were = allowed to jump forward and backward in the media) How = could the User select at any moment the desired representation to = watch/hear/read? Then, = based on information from the base protocol about bandwidth and chunk = availability the SVC-aware algorithm will select the chunks for the = layers it can support. So, the = Peer is, once again, involved in media decoding process, not the Media = Player Application. We've been = publishing on SVC/MDC and P2P since before 2004. As a matter of fact = Riccardo is presenting a paper on chunk selection next week at IEEE = ISM2011, so we know about structured media = ;o) I am not arguing about your = knowledge on Structured media, but on how the P2P Streaming Protocol = supports (although not directly involved i decoding processes) = Structured Media. But you did not answer = my question for the example I gave of a content with multiple playable = segments of complex structured Media. How would swift stream = such a content? CU, = Arno _______________________________________________<= br>ppsp mailing list ppsp@ietf.org https://www.ietf.org/ma= ilman/listinfo/ppsp = --Apple-Mail=_483D456A-6BAF-4807-B48F-A28CB02C8B1D-- From rui.cruz@ieee-pt.org Tue Nov 29 16:05:40 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D411F0C38 for ; Tue, 29 Nov 2011 16:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzXXzfi4SsXf for ; Tue, 29 Nov 2011 16:05:38 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3355F1F0C40 for ; Tue, 29 Nov 2011 16:05:36 -0800 (PST) Received: by eabm6 with SMTP id m6so4310118eab.31 for ; Tue, 29 Nov 2011 16:05:36 -0800 (PST) Received: by 10.227.199.16 with SMTP id eq16mr12554268wbb.26.1322611536114; Tue, 29 Nov 2011 16:05:36 -0800 (PST) Received: from [192.168.1.68] (89-180-34-53.net.novis.pt. [89.180.34.53]) by mx.google.com with ESMTPS id ej7sm33032wib.0.2011.11.29.16.05.32 (version=SSLv3 cipher=OTHER); Tue, 29 Nov 2011 16:05:34 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_BB351547-D9B2-4CC1-83C2-7A73B84F1C77" From: Rui Cruz In-Reply-To: Date: Wed, 30 Nov 2011 00:05:31 +0000 Message-Id: <57F3E545-C396-42E2-B40B-602A00C00C9A@ieee.org> References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> To: Martin Stiemerling X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , "ppsp@ietf.org" Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 00:05:40 -0000 --Apple-Mail=_BB351547-D9B2-4CC1-83C2-7A73B84F1C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Martin, Read inline please On 29/11/2011, at 14:56, Martin Stiemerling wrote: > [speaking as individual contributor and not as chair of the PPSP WG] > =20 > Hi there, > =20 > Replying to the proposal of the 2 alternatives: > Alternative 1: > I do not see how this will make a good protocol specification at the = end. There must be one draft that contains everything so that an = implementer can make a program out of this (or part of a program). There are IETF protocols being specified in parts, as is the case of = HTTPbis (7 parts). > This requires that semantics and syntax are in the same draft for the = protocol. Semantics and Syntax can be applied at different levels of a protocol = design. We may have Message semantics and syntax, well as = request/response semantics, etc. > Furthermore, there is no space for an architecture, as we do = protocols. I did not mention any system architecture, but the architecture of the = protocol, in layers. Lowest layer addressing Message Transport, = following layer addressing Wire Framework (service-side and = transport-side) and the upper layer on protocol operation logic and = semantics. > There can be considerations how the protocol would interact with the = rest of the program, i.e., the actual media player. But this is not part = of the protocol specification. Indeed there is the need for considerations on how the protocol might = interact with other components either the Peer program or other external = applications (not just the media player). Definitely these = considerations are not part of the protocol specification, but described = later, for instance, in usage guides and scenarios of application. However, these consideration if included in drafts of the design, may = serve initially as guidance. > =20 > Alternative 2: > I do not see the common ground of the 2 proposals that would allow a = merger. What I said was related to a joint effort that would, in my opinion, = accelerate the design.=20 That happened for the Tracker Protocol, which, as you said, is on the = right track for a WG draft. Two teams decided to combine their efforts = and jointly are producing the draft specification. > As stated in the meeting: draft-gu-ppsp-peer-protocol lacks many = crucial details for specifying a peer protocol for PPSP. > draft-grishchenko-ppsp-swift has much more technical meat in = specifying the basis of a PPSP peer protocol, though there are also some = rough corners. Indeed, both drafts have several rough corners.=20 > =20 > I=92m in clear favor of draft-grishchenko-ppsp-swift as being the PPSP = peer protocol. The protocol specification defines semantics and syntax. = The defined semantics and syntax are what I understand and would be able = to start working on an early implementation, though there is the need to = get more things nailed down. I also said that I am in favor of swift (not the draft) for the "Wire = Format and Message Transport candidate for the PPSP Peer Protocol". The = draft has several rough corners and constrains... > But a proposal must not be perfect at this point of time. Indeed! The draft-gu-ppsp-peer-protocol is not perfect but the authors = are willing to improve the design in message definition, operation logic = and semantics, extensibility, interactions, etc.=20 And can perfectly see swift as the base for the Wire format and Message = Transport of the Peer Protocol. Why not working together? > The WG should consider elements of draft-gu-ppsp-peer-protocol as = further input to the peer protocol. You recognize that there are elements of interest in = draft-gu-ppsp-peer-protocol.=20 As you said in other message "PPSP protocols should fit a wide range of = peer-to-peer TV architectures and not only a very limited set or a = single architecture" and I fully agree, as I can see some elements in = draft-grishenko-ppsp-swift that would constrain the peer protocol to a = limited set of P2P TV architectures.=20 > =20 > =20 > Martin > =20 > martin.stiemerling@neclab.eu > =20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014 > =20 > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf = Of Rui Cruz > Sent: Tuesday, November 29, 2011 1:18 AM > To: ppsp@ietf.org > Cc: Rui Cruz > Subject: Re: [ppsp] Selection of PPSP peer protocol draft > =20 > Hi, > =20 > I am in favor of Swift as a Wire Format and Message Transport = candidate for the PPSP Peer Protocol, although the Media Data Transport = may need further discussions (Data Transport is not in the scope of the = signaling protocol, although the design may determine it). > =20 > However=85 > =20 > I would reconsider if the situation is for either one or the other = draft to be voted as preferred in the WG.=20 > =20 > Opinions have balanced from a "merger, as both have some advantages", = "some features can be included into the other proposal", "take swift as = basis" or "'extensions' can be added, that parse the data (or the = metadata) to get infos needed by download algorithms" because = "information about the distortion, the interdependency between chunks = (to reflect coding dependencies), the temporal vs. spatial = scalability/layering to be conveyed" may be needed for the scheduling = algorithms. > =20 > Neither of the drafts presented a complete protocol architecture.=20 > =20 > And so, I would propose the following alternatives (not in andy = preferred order) to the simple white/black voting: > =20 > Alternative 1: one draft would proceed describing the Protocol = Architecture, Semantics, Syntax and Logic, and the other draft the way = to implement the Wire Format/Encoding layer and Message Transport layer, = suggesting and justifying Network Transport preferences. > Alternative 2: "merging the efforts", not the "proposals" on defining = the Protocol Architecture, Semantics and Logic and refining the Wire = Format/encoding and Message Transport layers, in an orchestrated way. = Both teams could perfectly do their best to converge into a complete = specification.=20 > =20 > The reasons behind this proposal are the following, for which some = responses and comments would enrich the discussion in the Mailing List: > =20 > 1. Architecture > The PPSP Peer Protocol design needs a very clear Architecture in order = to address Semantics, Syntax, Operation Logic and "services" provided, = as the "Peer Agent" interfaces and interacts with a Client Media Player = (in order to stream what the User requests, even if the User is playing = Tricks, like jumping forward in the movie or selecting a different audio = dubbing or subtitle language).=20 > =20 > The Architecture would describe, at least:=20 > - Peer Selection criteria: based of location, capabilities, etc.,=20 > - Streaming Modes support: live, on-demand, and how to obtain, ahead = of data, updates for the chunk IDs of the live media sliding window,=20 > - Extensibility: in terms of the support/cooperation with diverse = media representations and media structures/encodings, as the "Peer = Agent" should not take decisions on interdependency between media chunks = or representations (coding dependencies) of Structured Media, and that = role should be performed at the Media Player application level. However = it should cooperate for the correct and adequate download scheduling of = the required (externally ordered) media chunks (where chunks correspond = to segments of media, with similar duration, divided at points that = support effective individual decoding, e.g., on packet and key frame = boundaries). > - Interactions with: the Client Application (and Media Player) and = support of media Trick-Function requests, the Tracker(s)=20 > - Operation Semantics: the "Peer Agent" is NOT the Media Player, = therefore does not take decisions on what to watch (presentation) or at = which media presentation time to start watching, at any moment. > =20 > 2. Wire Protocol > The Wire Protocol goal is to provide the adequate framework (not = concerned with implementation and semantics of operation) for the = invocation of operations on resources, considering: > - "service-side" interface: with the Client Application, with the = Tracker processes components (in the Peer). > - "transport-side" interface: object types/assets, methods/messages, = requests/replies/results operations, error codes/conditions either = explicit or implicit, integrity, addressing. > =20 > 3. Message Transport > The Message Transport addresses the efficient delivery of messages, = independently of their meaning or purpose: > - message segmentation (message boundaries) > - multiplexing, pipelining, channeling > - flow and congestion control=20 > =20 > =46rom what is written in the swift description draft, there is no = interaction with the Media Player apart from feeding it with the = downloaded media, meaning that, as soon as the "Peer" knows the root = Hash or Public key (Swarm-ID) immediately starts pulling all the media = to feed the Player, without any interaction. The method is, apparently, = similar to a multi-source "progressive download". > One important aspect is that the signaling for bitmaps/hashes of swift = is push-mode, but the Media DATA streaming is always PULL-Mode, for = either Live or on-demand. =20 > =20 > About the support of Structured Media, I could not see evidence of = that, nor how Swift deals with several representations of the media, = i.e., video (several clips, multiple bitrates, layers), audio (different = audio dubbing languages), text (different subtitle languages), unless = all are multiplexed in a container file, or "contained" in a directory = of files, in order to be hashed in byte ranges.=20 > An example of such a structure is the following, for a 10 seconds = video encoded in SVC with two spacial resolutions (432x240 and 842x480) = and 6 layers for quality fidelity, with an associated Audio track. Each = segment (with chunks labelled .00, .01, .02, etc for the different = layers) corresponds to a duration of 2 seconds of media playout, and the = corresponding sizes are also indicated (example taken from a real test = video). > =20 > For this example, I suppose that swift would have to hash = independently each chunk, am I right? But then, how would it address the = scalability, as the Client Player requester, would eventually not = request all the layers of a segment during those 10 seconds of duration = (perhaps, starting only up to layer L3 on the first segment, then = raising to L4, then L5 in the following segments, or, if bandwidth would = allow up to L6 for the remaining segments). > =20 > +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER = CHUNKS=20 > 162 KiB 172 KiB 154 KiB 157 KiB 177 KiB=20 > =20 > +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER = CHUNKS=20 > 117 KiB 121 KiB 113 KiB 120 KiB 117 KiB=20 > =20 > +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER = CHUNKS > 4 KiB 6 KiB 6 KiB 6 KiB 4 KiB=20 > =20 > +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER = CHUNKS > 3 KiB 5 KiB 5 KiB 6 KiB 4 KiB=20 > =20 > +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER = CHUNKS > 5 KiB 6 KiB 5 KiB 6 KiB 6 KiB=20 > =20 > +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER = CHUNKS > 54 KiB 55 KiB 49 KiB 53 KiB 58 KiB=20 > =20 > +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER = CHUNKS > 50 KiB 52 KiB 50 KiB 53 KiB 50 KiB =20 > =20 > +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO = Chunks > 5 KiB 5 KiB 5 KiB 5 KiB 5 KiB =20 > =20 >=20 > --------------------------- > Best Regards, >=20 > Prof. Rui Santos Cruz > Chairman > IEEE Portugal Section > Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, = 2744-016 Porto Salvo, Portugal > +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) > rui.cruz@ieee.org=20 > rui.s.cruz@ist.utl.pt > sec.portugal@ieee.org > www.ieee-pt.org > Advancing technology for humanity. > =20 > On 24/11/2011, at 14:42, Martin Stiemerling wrote: >=20 >=20 > Dear all,=20 >=20 > The working group has to make a decision which peer protocol proposal = to choose as basis for the PPSP peer protocol.=20 >=20 > We have to independent proposals: > - draft-gu-ppsp-peer-protocol-03 > (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) > - draft-grishchenko-ppsp-swift-03 > (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) >=20 > Both proposals for a peer protocol have been presented at the IETF = meeting. The slides are available here: > - draft-gu-ppsp-peer-protocol-03: > http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx > - draft-grishchenko-ppsp-swift-03 > http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf >=20 > The feedback given at the IETF meeting about both proposals is = documented in the draft meeting minutes: > http://www.ietf.org/proceedings/82/minutes/ppsp.txt >=20 > Please state your **technical** opinion about which peer protocol = proposal you would prefer on the PPSP mailing list until November 30th. >=20 > With best regards >=20 > Yunfei and Martin > PPSP co-chairs >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014=20 >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > =20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_BB351547-D9B2-4CC1-83C2-7A73B84F1C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Martin, Read inline = please On= 29/11/2011, at 14:56, Martin Stiemerling wrote: [speaking = as individual contributor and not as chair of the PPSP = WG] Hi = there, Replying to = the proposal of the 2 alternatives: Alternative 1: I do not see how this will make a good protocol = specification at the end. There must be one draft that contains = everything so that an implementer can make a program out of this (or = part of a program). = Th= ere are IETF protocols being specified in parts, as is the case of = HTTPbis (7 parts). This = requires that semantics and syntax are in the same draft for the = protocol. = Se= mantics and Syntax can be applied at different levels of a protocol = design. We may have Message semantics and syntax, well as = request/response semantics, etc. There can = be considerations how the protocol would interact with the rest of the = program, i.e., the actual media player. But this is not part of the = protocol = specification. Indeed there is the need for considerations on how the = protocol might interact with other components either the Peer program or = other external applications (not just the media player). Definitely = these considerations are not part of the protocol specification, but = described later, for instance, in usage guides and scenarios of = application. However, these consideration if included in = drafts of the design, may serve initially as = guidance. Alternative = 2: I do not = see the common ground of the 2 proposals that would allow a merger. = Wh= at I said was related to a joint effort that would, in my opinion, = accelerate the design. That happened for the Tracker = Protocol, which, as you said, is on the right track for a WG draft. Two = teams decided to combine their efforts and jointly are producing the = draft specification. As stated = in the meeting: draft-gu-ppsp-peer-protocol lacks many crucial details = for specifying a peer protocol for = PPSP. I=92m in = clear favor of draft-grishchenko-ppsp-swift as being the PPSP peer = protocol. The protocol specification defines semantics and syntax. The = defined semantics and syntax are what I understand and would be able to = start working on an early implementation, though there is the need to = get more things nailed down. = I = also said that I am in favor of swift (not the draft) for the "Wire = Format and Message Transport candidate for the PPSP Peer = Protocol". The draft has several rough corners and = constrains... But a = proposal must not be perfect at this point of = time. Indeed! The draft-gu-ppsp-peer-protocol is not perfect but the = authors are willing to improve the design in message definition, = operation logic and semantics, extensibility, interactions, = etc. And can perfectly see swift as the base for the = Wire format and Message Transport of the Peer Protocol. Why not working = together? The WG = should consider elements of draft-gu-ppsp-peer-protocol as further input = to the peer protocol. PPSP = protocols should fit a wide range of peer-to-peer TV architectures and = not only a very limited set or a single architecture" and I fully = agree, as I can see some elements in draft-grishenko-ppsp-swift that = would constrain the peer protocol to a limited set of P2P TV = architectures. Martin NEC Laboratories Europe - Network Research Division = NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, = London W3 6BL | Registered in England = 2832014 From: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] On Behalf Of Rui = Cruz Sent: Tuesday, November 29, 2011 = 1:18 AM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selection of = PPSP peer protocol draft I am in favor of Swift as = a Wire Format and Message Transport = candidate for the PPSP Peer Protocol, = although the Media Data Transport may need further discussions (Data = Transport is not in the scope of the signaling protocol, although the = design may determine it). I would reconsider if the situation is for = either one or the other draft to be voted as preferred in the = WG. Opinions have balanced from a "merger, as = both have some advantages", "some features can be included into the = other proposal", "take swift as basis" or "'extensions' can be added, = that parse the data (or the metadata) to get infos needed by download = algorithms" because "information about the distortion, the = interdependency between chunks (to reflect coding dependencies), the = temporal vs. spatial scalability/layering to be conveyed" may be needed = for the scheduling = algorithms. Neither of the drafts presented a complete = protocol = architecture. And so, I would propose the following = alternatives (not in andy preferred = order) to the simple white/black = voting: Alternative = 1: one draft would proceed = describing the Protocol Architecture, Semantics, Syntax and Logic, and = the other draft the way to implement the Wire Format/Encoding layer and = Message Transport layer, suggesting and justifying Network Transport = preferences. Alternative 2: = ;"merging the efforts", not the "proposals" on defining the Protocol = Architecture, Semantics and Logic and refining the Wire Format/encoding = and Message Transport layers, in an orchestrated way. Both teams could = perfectly do their best to converge into a complete = specification. The reasons behind this proposal are the = following, for which some responses and comments would enrich = the discussion in the Mailing = List: 1. = Architecture The PPSP Peer Protocol design needs a very = clear Architecture in order to address Semantics, Syntax, Operation = Logic and "services" provided, as the "Peer Agent" interfaces and = interacts with a Client Media Player (in order to stream what the User = requests, even if the User is playing Tricks, like jumping forward in = the movie or selecting a different audio dubbing or subtitle = language). The Architecture would describe, at = least: - Peer Selection criteria: based of = location, capabilities, = etc., - Streaming Modes support: live, on-demand, = and how to obtain, ahead of data, updates for the chunk IDs of the live = media sliding = window, - Extensibility: in terms of the = support/cooperation with diverse media representations and media = structures/encodings, as the "Peer Agent" should not take decisions on = interdependency between media chunks or representations (coding = dependencies) of Structured Media, and that role should be performed at = the Media Player application level. However it should cooperate for the = correct and adequate download scheduling of the required (externally = ordered) media chunks (where chunks correspond to segments of media, = with similar duration, divided at points that support effective = individual decoding, e.g., on packet and key frame = boundaries). - Interactions with: the Client Application = (and Media Player) and support of media Trick-Function requests, the = Tracker(s) - Operation Semantics: the "Peer Agent" is = NOT the Media Player, therefore does not take decisions on what to watch = (presentation) or at which media presentation time to start watching, at = any moment. 2. Wire = Protocol The Wire Protocol goal is to provide the = adequate framework (not concerned with implementation and semantics of = operation) for the invocation of operations on resources, = considering: - "service-side" interface: with the Client = Application, with the Tracker processes components (in the = Peer). - = "transport-side" interface: object types/assets, methods/messages, = requests/replies/results operations, error codes/conditions either = explicit or implicit, integrity, = addressing. 3. Message = Transport The Message Transport addresses the = efficient delivery of messages, independently of their meaning or = purpose: - message segmentation (message = boundaries) - multiplexing, pipelining, = channeling - flow and congestion = control =46rom what is written in the swift = description draft, there is no interaction with the Media Player apart = from feeding it with the downloaded media, meaning that, as soon as the = "Peer" knows the root Hash or Public key (Swarm-ID) immediately starts = pulling all the media to feed the Player, without any interaction. The = method is, apparently, similar to a multi-source "progressive = download". One important aspect is that the signaling = for bitmaps/hashes of swift is push-mode, but the Media DATA streaming = is always PULL-Mode, for either Live or on-demand. = About the support of Structured Media, I = could not see evidence of that, nor how Swift deals with several = representations of the media, i.e., video (several clips, multiple = bitrates, layers), audio (different audio dubbing languages), text = (different subtitle languages), unless all are multiplexed in a = container file, or "contained" in a directory of files, in order to be = hashed in byte = ranges. An example of such a structure is the = following, for a 10 seconds video encoded in SVC with two spacial = resolutions (432x240 and 842x480) and 6 layers for quality fidelity, = with an associated Audio track. Each segment (with chunks labelled .00, = .01, .02, etc for the different layers) corresponds to a duration of 2 = seconds of media playout, and the corresponding sizes are also indicated = (example taken from a real test = video). For this example, I suppose that swift would = have to hash independently each chunk, am I right? But then, how would = it address the scalability, as the Client Player requester, would = eventually not request all the layers of a segment during those 10 = seconds of duration (perhaps, starting only up to layer L3 on the first = segment, then raising to L4, then L5 in the following segments, or, if = bandwidth would allow up to L6 for the remaining = segments). +++L6.00+++ = +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER = CHUNKS = 162 KiB = 172 KiB 154 KiB 157 KiB 177 = KiB +++L5.00+++ = +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER = CHUNKS = 117 KiB = 121 KiB 113 KiB 120 KiB 117 = KiB +++L4.00+++ = +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER = CHUNKS 4 KiB = 6 KiB 6 KiB 6 KiB = 4 = KiB +++L3.00+++ = +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER = CHUNKS 3 KiB = 5 KiB 5 KiB 6 KiB = 4 = KiB +++L2.00+++ = +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER = CHUNKS 5 KiB = 6 KiB 5 KiB 6 KiB = 6 = KiB +++L1.00+++ = +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER = CHUNKS 54 KiB = 55 KiB 49 KiB 53 KiB = 58 = KiB +++L0.00+++ = +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER = CHUNKS 50 KiB = 52 KiB 50 KiB 53 KiB = 50 KiB = +++AA.00+++ = +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO = Chunks 5 KiB = 5 KiB 5 KiB = 5 KiB 5 KiB = --------------------------- Best = Regards,Prof. Rui Santos = CruzChairman IEEE Portugal = SectionAv. Prof. Dr. An=EDbal Cavaco = Silva, IST-TagusPark, Office 1-5, 2744-016 Porto Salvo, = Portugal +351 214 233 200 (ext 5044), +351.939 = 060 939 (mobile) sec.portugal@ieee.org Advancing = technology for = humanity. = On = 24/11/2011, at 14:42, Martin Stiemerling = wrote: Dear = all, The = working group has to make a decision which peer protocol proposal to = choose as basis for the PPSP peer protocol. We have to = independent proposals: - draft-gu-ppsp-peer-protocol-03 ( _________________= ______________________________ ppsp mailing list ppsp@ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 08:39:16 -0000 On 29/11/2011 08:13, Y. Richard Yang wrote: > > * Are there any experimental results of swift at large scale real > experiments? > Hi Richard we test swift using manifold testing with up to 200 emulated peers, with varying network configurations. We have plans to conduct another experiment with the WikiMedia foundation, and Yunfei, the co-chair is willing to conduct experiments with the PPSP peer protocol with ChinaMobile customers. > * According to our experiences at building an experimental p2p streaming > system at Yale, a real protocol quickly becomes complex as we continue > to extend it to handle challenges in real settings. The extension scheme > of the protocol needs careful thinking. > IMHO, the protocol should provide the mechanisms that support many different policies (chunk selection, peer discovery & selection, etc.), without becoming overly generic. The latter is the complex bit ;o) > > - page 4 top: "... peer connects to a random set of other peers ..." > why random? > I think I wrote random to distinguish swift from strictly tree-based protocols. Peer selection is pluggable in swift, to also allow input from e.g. ALTO servers. > - page 4 "... omits HAVE messages as a way of choking A." > > Also Page 7 on withholding HAVE. Also on Page 7 on withholding > error messages. > > I typically do not like such information-hiding designs. Informed > decisions often are better, faster decisions. The reason why we don't have explicit CHOKE/UNCHOKE is because in practice they do not guarantee that a peer will actually send you data (the "snubbed" syndrome). Hence, we decided to go with observed behaviour (if a peer responds, fine, ask more, otherwise leave it). But apparently you feel differently? > - page 4 (also page 9) "... A sends a datagram containing HAVE > messages for the chunks it just received to all its peers." Specifying > such a push-just-received model may not be necessary. > We needed push-just-received in our current chunk-selection policies for live and VOD. We have to look into Fabio Picconi's remarks about lastest-useful policies for live that may not need it. In which situations does your system use another policy? > - The design is essentially pushing for an uploader centric design. > This is unnecessary. > Can you elaborate a bit on that, I'm not sure what you mean. Normally, receivers explicitly request chunks via HINTs. Swift allows for live streaming protocols which push chunks. > - I am wondering is the scheme is patented. CK Wong and Simon Lam > presented such a design in 1998 (for disclosure, Simon Lam is my PhD > advisor): > http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf > Wesley Eddy, the transport area director already contacted the SEC area directors about it. Apparently there was a patent that might have covered the hash tree as we use it (I am not a lawyer), but it expired, no. 4,309,569: http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F4309569 In any case, it is the desire of the working group to support multiple methods of chunk addressing and content integrity protection (and I am rewriting the draft to reflect this), so patents do not impact selection. > - On the other hand, I am wondering if using such a binary tree > based design is necessary, as elaborated schemes typically can have > limit extensibility, compared with simple straightforward schemes . In > particular, how much savings are we talking about, at the cost of > choosing a particular binary tree based representation scheme? Such > information can be helpful. > The binmap representation is described and compare to others in http://www.pds.ewi.tudelft.nl/fileadmin/pds/reports/2011/PDS-2011-005.pdf And, the new draft will allow different addressing methods, as just mentioned. CU, Arno From a.bakker@vu.nl Wed Nov 30 00:51:22 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888FE21F854D for ; Wed, 30 Nov 2011 00:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=1.780, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpQnDpARRYCt for ; Wed, 30 Nov 2011 00:51:21 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6F47621F84A6 for ; Wed, 30 Nov 2011 00:51:20 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 30 Nov 2011 09:51:17 +0100 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 30 Nov 2011 09:51:19 +0100 Message-ID: <4ED5EEFB.8020708@cs.vu.nl> Date: Wed, 30 Nov 2011 09:53:15 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <4ED48613.6070408@cs.yale.edu> <77252AAF-8CC9-4831-8DF0-352A2E02352B@ieee.org> In-Reply-To: <77252AAF-8CC9-4831-8DF0-352A2E02352B@ieee.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 08:51:22 -0000 On 29/11/2011 14:26, Rui Cruz wrote: > > And if the encoded complex structured media is segmented in rather large > sized chunks (of 10x or 100x KiB) *each chunk* would have to be mapped, > I suppose, to a quite large Hash tree to split the data in byte ranges > for the datagrams. So, instead a a single Bin tree, a complex Structured > Media with a duration of an hour (3600 seconds) would require at least > 18000 Root hashes for chunks with 2 seconds encoded in 10 layers. Would > this not be overkill? > Hi I don't quite follow what you mean here. If the content consists of 1800 intervals encoded in 10 layers, there will be 18,000 addressable chunks of content. In the simplest case in swift, these are mapped into a single tree with 18,000 hashes as leaves that is identified by a single root hash. As 18,000 hashes consume about 360 kilobytes with 20-byte SHA1 hashes, I'd hardly call that overkill. Please explain how you intend to do content integrity protection in this case. Regards, Arno From a.bakker@vu.nl Wed Nov 30 01:23:30 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA86021F86FF for ; Wed, 30 Nov 2011 01:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KIFC0wflwPZ for ; Wed, 30 Nov 2011 01:23:30 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C13521F86A1 for ; Wed, 30 Nov 2011 01:23:23 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 30 Nov 2011 10:23:21 +0100 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 30 Nov 2011 10:23:22 +0100 Message-ID: <4ED5F67E.9020305@cs.vu.nl> Date: Wed, 30 Nov 2011 10:25:18 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <4ED48613.6070408@cs.yale.edu> <4ED51312.9060004@cs.yale.edu> In-Reply-To: <4ED51312.9060004@cs.yale.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 09:23:30 -0000 On 29/11/2011 18:14, Y. Richard Yang wrote: > >> RTCWEB is putting things in the browser, namely VoIP. However, they are heavily relying on RTP to exchange the time sensitive information, i.e., voice and video. This is not supporting your argument at all. > To clarify, what I prefer is a protocol that is easier to be put into > browsers, as this is more likely a deployment case. Let's change the > name HTTP to web based. Will PPSP peer protocol consider coordination > with the RTCWEB effort? I've promoted PPSP at the Quebec IETF meeting of RTCWEB and the mailing list ("what if a client has insufficient upload to send his signal to all meeting participants") but the response I got was that they didn't want to look at that in the first iteration. More promotion needed at a later stage. In the mean time, Firefox, Safari and IE allow the definition of additional transports via plugins. We have currently added swift as a protocol to Firefox, e.g. = Hi Rui, = = = = martin.stiemerling@neclab.= eu = = NEC Laboratories Europe - Network Research Division NEC Europe Limited | Regis= tered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in Eng= land 2832014 = From: Rui Cruz [mailto:rui.cruz@ieee-pt.org] On Behalf Of Rui Cruz Sent: Tuesday, November 29, = 2011 10:25 PM To: Martin Stiemerling Cc: Rui Cruz; Y. Richard Yan= g; ppsp@ietf.org; LANS Yale Subject: Re: [ppsp] Selectio= n of PPSP peer protocol draft = Hi Martin, = Read inline please.... = On 29/11/2011, at 15:13, Martin Stiemerling wrote:= = = [speaking as individual contributor and not as chair of the PPSP WG] = is not a good idea, as maturity can change in a relatively short time<= /o:p> = period, say between two IETFs, through some intensive engineering = efforts, and we are designing a protocol that will last a much longer<= /o:p> = period. Hence it is important to consider the key technical design. I<= /o:p> I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol= proposals and the merged document raises even more questions than the pred= ecessor documents. = = The only explicit mention to a merger of 2 proposals are related to the Tra= cker protocol, not to the Peer Protocol. = Nowhere in the gu-ppsp-peer draft nor in the corresponding presentatio= n at the iETF meeting, is mentioned any merger of two previous peer protocol proposals. = The only "merger" that happened related with the Peer Protocol wa= s of the people working on the draft. = = Yes, indeed. I have mixed up the tracker and the peer protocol. Sorry for that. = = = Unfortunately, due to time limitations, it was not possible for us to write= all the details we were willing to write in that draft document, hoping that the discussion during the WG meeting would all= ow us to capture the "advantages", the "features", the = "extensions", etc. considered as suitable for the improvement of = the design. = = I would be delighted to see contributions on features on the mailing list or in an updated draft. = = Martin = = martin.stieme= rling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org= /mailman/listinfo/ppsp = --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E923C8Polydeucesoffic_-- From Martin.Stiemerling@neclab.eu Wed Nov 30 08:16:09 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DA121F84BD for ; Wed, 30 Nov 2011 08:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.778 X-Spam-Level: X-Spam-Status: No, score=-101.778 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX3YNnOyMs+V for ; Wed, 30 Nov 2011 08:16:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6213C21F8B6C for ; Wed, 30 Nov 2011 08:16:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BB0F9280000FC; Wed, 30 Nov 2011 17:15:59 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyhYQ9IpYKbe; Wed, 30 Nov 2011 17:15:59 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7F1CD28000082; Wed, 30 Nov 2011 17:15:49 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 30 Nov 2011 17:15:49 +0100 From: Martin Stiemerling To: Rui Cruz Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/QDbPCcAACBXE8AAEYaagAAj6/YA Date: Wed, 30 Nov 2011 16:15:48 +0000 Message-ID: References: <4901A0F3-5602-4DAB-A26A-A4B613A6491A@ieee.org> <57F3E545-C396-42E2-B40B-602A00C00C9A@ieee.org> In-Reply-To: <57F3E545-C396-42E2-B40B-602A00C00C9A@ieee.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E923F3Polydeucesoffic_" MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 16:16:09 -0000 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E923F3Polydeucesoffic_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rui, Now the email with text... I think we are on the same side, let's work together. What I would like to see, that people review both protocols and state what = they see is missing, so that this will be documented on the list. Martin From: Rui Cruz [mailto:rui.cruz@ieee-pt.org] On Behalf Of Rui Cruz Sent: Wednesday, November 30, 2011 1:06 AM To: Martin Stiemerling Cc: Rui Cruz; ppsp@ietf.org Subject: Re: [ppsp] Selection of PPSP peer protocol draft Hi Martin, Read inline please On 29/11/2011, at 14:56, Martin Stiemerling wrote: [speaking as individual contributor and not as chair of the PPSP WG] Hi there, Replying to the proposal of the 2 alternatives: Alternative 1: I do not see how this will make a good protocol specification at the end. T= here must be one draft that contains everything so that an implementer can = make a program out of this (or part of a program). There are IETF protocols being specified in parts, as is the case of HTTPbi= s (7 parts). This requires that semantics and syntax are in the same draft for the proto= col. Semantics and Syntax can be applied at different levels of a protocol desig= n. We may have Message semantics and syntax, well as request/response seman= tics, etc. Furthermore, there is no space for an architecture, as we do protocols. I did not mention any system architecture, but the architecture of the prot= ocol, in layers. Lowest layer addressing Message Transport, following layer= addressing Wire Framework (service-side and transport-side) and the upper = layer on protocol operation logic and semantics. There can be considerations how the protocol would interact with the rest o= f the program, i.e., the actual media player. But this is not part of the p= rotocol specification. Indeed there is the need for considerations on how the protocol might inter= act with other components either the Peer program or other external applica= tions (not just the media player). Definitely these considerations are not = part of the protocol specification, but described later, for instance, in u= sage guides and scenarios of application. However, these consideration if included in drafts of the design, may serve= initially as guidance. Alternative 2: I do not see the common ground of the 2 proposals that would allow a merger= . What I said was related to a joint effort that would, in my opinion, accele= rate the design. That happened for the Tracker Protocol, which, as you said, is on the right= track for a WG draft. Two teams decided to combine their efforts and joint= ly are producing the draft specification. As stated in the meeting: draft-gu-ppsp-peer-protocol lacks many crucial de= tails for specifying a peer protocol for PPSP. draft-grishchenko-ppsp-swift has much more technical meat in specifying the= basis of a PPSP peer protocol, though there are also some rough corners. Indeed, both drafts have several rough corners. I'm in clear favor of draft-grishchenko-ppsp-swift as being the PPSP peer p= rotocol. The protocol specification defines semantics and syntax. The defin= ed semantics and syntax are what I understand and would be able to start wo= rking on an early implementation, though there is the need to get more thin= gs nailed down. I also said that I am in favor of swift (not the draft) for the "Wire Forma= t and Message Transport candidate for the PPSP Peer Protocol". The draft ha= s several rough corners and constrains... But a proposal must not be perfect at this point of time. Indeed! The draft-gu-ppsp-peer-protocol is not perfect but the authors are = willing to improve the design in message definition, operation logic and se= mantics, extensibility, interactions, etc. And can perfectly see swift as the base for the Wire format and Message Tra= nsport of the Peer Protocol. Why not working together? The WG should consider elements of draft-gu-ppsp-peer-protocol as further i= nput to the peer protocol. You recognize that there are elements of interest in draft-gu-ppsp-peer-pro= tocol. As you said in other message "PPSP protocols should fit a wide range of pee= r-to-peer TV architectures and not only a very limited set or a single arch= itecture" and I fully agree, as I can see some elements in draft-grishenko-= ppsp-swift that would constrain the peer protocol to a limited set of P2P T= V architectures. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 From: ppsp-bounces@ietf.org [mailto:ppsp-boun= ces@ietf.org] On Behalf Of Rui Cruz Sent: Tuesday, November 29, 2011 1:18 AM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selection of PPSP peer protocol draft Hi, I am in favor of Swift as a Wire Format and Message Transport candidate for= the PPSP Peer Protocol, although the Media Data Transport may need further= discussions (Data Transport is not in the scope of the signaling protocol,= although the design may determine it). However... I would reconsider if the situation is for either one or the other draft to= be voted as preferred in the WG. Opinions have balanced from a "merger, as both have some advantages", "some= features can be included into the other proposal", "take swift as basis" o= r "'extensions' can be added, that parse the data (or the metadata) to get = infos needed by download algorithms" because "information about the distort= ion, the interdependency between chunks (to reflect coding dependencies), t= he temporal vs. spatial scalability/layering to be conveyed" may be needed = for the scheduling algorithms. Neither of the drafts presented a complete protocol architecture. And so, I would propose the following alternatives (not in andy preferred o= rder) to the simple white/black voting: Alternative 1: one draft would proceed describing the Protocol Architecture= , Semantics, Syntax and Logic, and the other draft the way to implement the= Wire Format/Encoding layer and Message Transport layer, suggesting and jus= tifying Network Transport preferences. Alternative 2: "merging the efforts", not the "proposals" on defining the = Protocol Architecture, Semantics and Logic and refining the Wire Format/enc= oding and Message Transport layers, in an orchestrated way. Both teams coul= d perfectly do their best to converge into a complete specification. The reasons behind this proposal are the following, for which some response= s and comments would enrich the discussion in the Mailing List: 1. Architecture The PPSP Peer Protocol design needs a very clear Architecture in order to a= ddress Semantics, Syntax, Operation Logic and "services" provided, as the "= Peer Agent" interfaces and interacts with a Client Media Player (in order t= o stream what the User requests, even if the User is playing Tricks, like j= umping forward in the movie or selecting a different audio dubbing or subti= tle language). The Architecture would describe, at least: - Peer Selection criteria: based of location, capabilities, etc., - Streaming Modes support: live, on-demand, and how to obtain, ahead of dat= a, updates for the chunk IDs of the live media sliding window, - Extensibility: in terms of the support/cooperation with diverse media rep= resentations and media structures/encodings, as the "Peer Agent" should not= take decisions on interdependency between media chunks or representations = (coding dependencies) of Structured Media, and that role should be performe= d at the Media Player application level. However it should cooperate for th= e correct and adequate download scheduling of the required (externally orde= red) media chunks (where chunks correspond to segments of media, with simil= ar duration, divided at points that support effective individual decoding, = e.g., on packet and key frame boundaries). - Interactions with: the Client Application (and Media Player) and support = of media Trick-Function requests, the Tracker(s) - Operation Semantics: the "Peer Agent" is NOT the Media Player, therefore = does not take decisions on what to watch (presentation) or at which media p= resentation time to start watching, at any moment. 2. Wire Protocol The Wire Protocol goal is to provide the adequate framework (not concerned = with implementation and semantics of operation) for the invocation of opera= tions on resources, considering: - "service-side" interface: with the Client Application, with the Tracker p= rocesses components (in the Peer). - "transport-side" interface: object types/assets, methods/messages, reques= ts/replies/results operations, error codes/conditions either explicit or im= plicit, integrity, addressing. 3. Message Transport The Message Transport addresses the efficient delivery of messages, indepen= dently of their meaning or purpose: - message segmentation (message boundaries) - multiplexing, pipelining, channeling - flow and congestion control >From what is written in the swift description draft, there is no interactio= n with the Media Player apart from feeding it with the downloaded media, me= aning that, as soon as the "Peer" knows the root Hash or Public key (Swarm-= ID) immediately starts pulling all the media to feed the Player, without an= y interaction. The method is, apparently, similar to a multi-source "progre= ssive download". One important aspect is that the signaling for bitmaps/hashes of swift is p= ush-mode, but the Media DATA streaming is always PULL-Mode, for either Live= or on-demand. About the support of Structured Media, I could not see evidence of that, no= r how Swift deals with several representations of the media, i.e., video (s= everal clips, multiple bitrates, layers), audio (different audio dubbing la= nguages), text (different subtitle languages), unless all are multiplexed i= n a container file, or "contained" in a directory of files, in order to be = hashed in byte ranges. An example of such a structure is the following, for a 10 seconds video enc= oded in SVC with two spacial resolutions (432x240 and 842x480) and 6 layers= for quality fidelity, with an associated Audio track. Each segment (with c= hunks labelled .00, .01, .02, etc for the different layers) corresponds to = a duration of 2 seconds of media playout, and the corresponding sizes are a= lso indicated (example taken from a real test video). For this example, I suppose that swift would have to hash independently eac= h chunk, am I right? But then, how would it address the scalability, as the= Client Player requester, would eventually not request all the layers of a = segment during those 10 seconds of duration (perhaps, starting only up to l= ayer L3 on the first segment, then raising to L4, then L5 in the following = segments, or, if bandwidth would allow up to L6 for the remaining segments)= . +++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER CHUN= KS 162 KiB 172 KiB 154 KiB 157 KiB 177 KiB +++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER CHUN= KS 117 KiB 121 KiB 113 KiB 120 KiB 117 KiB +++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER CHUN= KS 4 KiB 6 KiB 6 KiB 6 KiB 4 KiB +++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER CHUN= KS 3 KiB 5 KiB 5 KiB 6 KiB 4 KiB +++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER CHUN= KS 5 KiB 6 KiB 5 KiB 6 KiB 6 KiB +++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER CHUN= KS 54 KiB 55 KiB 49 KiB 53 KiB 58 KiB +++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER CHUN= KS 50 KiB 52 KiB 50 KiB 53 KiB 50 KiB +++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB 5 KiB 5 KiB 5 KiB --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Po= rto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 24/11/2011, at 14:42, Martin Stiemerling wrote: Dear all, The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E923F3Polydeucesoffic_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable = Hi Rui, = = Now the email with text… = = I think we are on the same side, let’s work together. = = What I would like to see, that people review both protocols and state what they see is missing, so that this will be documented on the list. = = Martin = = From: Rui Cruz [mailto:rui.cruz@ieee-pt.org] On Behalf Of Rui Cruz Sent: Wednesday, November 30= , 2011 1:06 AM To: Martin Stiemerling Cc: Rui Cruz; ppsp@ietf.org<= br> Subject: Re: [ppsp] Selectio= n of PPSP peer protocol draft = Hi Martin, = = Read inline please = = On 29/11/2011, at 14:56, Martin Stiemerling wrote:= = = [speaking as individual contributor and not as chair of the PPSP WG] = = Hi there, = = Replying to the proposal of the 2 alternatives: = Alternative 1: = I do not see how this will make a good protocol specification at the end. There must be one draft that contains everything so that an implement= er can make a program out of this (or part of a program). = = There are IETF protocols being specified in parts, as is the case of HTTPbi= s (7 parts). = = This requires that semantics and syntax are in the same draft for the protocol. = = Semantics and Syntax can be applied at different levels of a protocol desig= n. We may have Message semantics and syntax, well as request/response semantics, etc. = = Furthermore, there is no space for an architecture, as we do protocols. = = I did not mention any system architecture, but the architecture of the prot= ocol, in layers. Lowest layer addressing Message Transport, following layer addressing Wire Framework (service-side and transport-side= ) and the upper layer on protocol operation logic and semantics.= = = There can be considerations how the protocol would interact with the rest of the program, i.e., the actual media player. But this is not part o= f the protocol specification. = = Indeed there is the need for considerations on how the protocol might inter= act with other components either the Peer program or other external applications (not just the media player). Definitely the= se considerations are not part of the protocol specification, but described= later, for instance, in usage guides and scenarios of application. = However, these consideration if included in drafts of the design, may serve= initially as guidance. = = = Alternative 2: = I do not see the common ground of the 2 proposals that would allow a merger. = = What I said was related to a joint effort that would, in my opinion, accele= rate the design. = That happened for the Tracker Protocol, which, as you said, is on the right= track for a WG draft. Two teams decided to combine their efforts and jointly are producing the draft specification. = = As stated in the meeting: draft-gu-ppsp-peer-protocol lacks many crucia= l details for specifying a peer protocol for PPSP.= = draft-grishchenko-ppsp-swift has much more technical meat in specifying the basis of a PPSP peer protocol, though there are also some rough corner= s. = = Indeed, both drafts have several rough corners. = = = I’m in clear favor of draft-grishchenko-ppsp-swift as being the P= PSP peer protocol. The protocol specification defines semantics and syntax. Th= e defined semantics and syntax are what I understand and would be able to s= tart working on an early implementation, though there is the need to get mo= re things nailed down. = = I also said that I am in favor of swift (not the draft) for the "Wire Format and Message Transport candidate for the PPSP Peer Protocol". The draft has = several rough corners and constrains... = = But a proposal must not be perfect at this point of time.= = = Indeed! The draft-gu-ppsp-peer-protocol is not perfect but the authors are = willing to improve the design in message definition, operation logic and semantics, extensibility, interactions, etc. = And can perfectly see swift as the base for the Wire format and Message Tra= nsport of the Peer Protocol. Why not working together? = = The WG should consider elements of draft-gu-ppsp-peer-protocol as furth= er input to the peer protocol. = = You recognize that there are elements of interest in draft-gu-ppsp-peer-pro= tocol. = As you said in other message "PPSP protocols should fit a wide range of peer-to-peer TV architectures and not= only a very limited set or a single architecture" and I= fully agree, as I can see some elements in draft-grishenko-ppsp-swift that would constrain the peer protocol to a limited set of P2P TV architec= tures. = = = = Martin<= /font><= o:p> = = martin.stiemerling@necl= ab.eu = = NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registere= d in England 2832014 = From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf= .org] On Behalf Of&nb= sp;Rui Cruz Sent: Tuesday, November 29, 2011 1:18 AM To: ppsp@ietf.org Cc: Rui Cruz Subject: Re: [ppsp] Selection of PPSP peer protocol d= raft = = Hi, = I am in favor of Swift as a Wire Format and Message Tra= nsport candidate for the PPSP Peer Protocol, although the Media Data Transport may need further= discussions (Data Transport is not in the scope of the signaling protocol,= although the design may determine it). = However… = = I would reconsider if the situation is for either one or the other draft to= be voted as preferred in the WG. = = Opinions have balanced from a "merger, as both have some advantages&qu= ot;, "some features can be included into the other proposal", "take swift as basis" or "'extensions' can be added, that p= arse the data (or the metadata) to get infos needed by download algorithms&= quot; because "information about the distortion, the interdependency b= etween chunks (to reflect coding dependencies), the temporal vs. spatial scalability/layering to be conveyed" may be needed for th= e scheduling algorithms. = = Neither of the drafts presented a complete protocol architecture. = = And so, I would propose the following alternatives (not in andy preferred order) to the simple white/black voting: = Alternative 1: one draft would proceed describing the Protocol Architecture, Semantics, Synta= x and Logic, and the other draft the way to implement the Wire Format/Encod= ing layer and Message Transport layer, suggesting and justifying Network Tr= ansport preferences. Alternative 2:&nb= sp; "merging the efforts", not the "proposals" on defining the Protocol = Architecture, Semantics and Logic and refining the Wire Format/encoding and= Message Transport layers, in an orchestrated way. Both teams could perfect= ly do their best to converge into a complete specification. = = The reasons behind this proposal are the following, for which some responses and comments would enrich the discussion in the M= ailing List: = = 1. Architecture = The PPSP Peer Protocol design needs a very clear Architecture in order to a= ddress Semantics, Syntax, Operation Logic and "services" provided, as the "Peer Agent" interfaces and interacts with a Cl= ient Media Player (in order to stream what the User requests, even if the U= ser is playing Tricks, like jumping forward in the movie or selecting a dif= ferent audio dubbing or subtitle language). <= /p> = = The Architecture would describe, at least: = - Peer Selection criteria: based of location, capabilities, etc., = - Streaming Modes support: live, on-demand, and how to obtain, ahead of dat= a, updates for the chunk IDs of the live media sliding window, = - Extensibility: in terms of the support/cooperation with diverse media rep= resentations and media structures/encodings, as the "Peer Agent" should not take decisions on interdependency betwee= n media chunks or representations (coding dependencies) of Structured Media= , and that role should be performed at the Media Player application level. = However it should cooperate for the correct and adequate download scheduling of the required (externally ordered) medi= a chunks (where chunks correspond to segments of media, with similar durati= on, divided at points that support effective individual decoding, e.g., on = packet and key frame boundaries). = - Interactions with: the Client Application (and Media Player) and support = of media Trick-Function requests, the Tracker(s) = - Operation Semantics: the "Peer Agent" is NOT the Media Player, = therefore does not take decisions on what to watch (presentation) or at which media presentation time to start watching, at any moment.= = = 2. Wire Protocol = The Wire Protocol goal is to provide the adequate framework (not concerned = with implementation and semantics of operation) for the invocation of operations on resources, considering:<= /font> = - "service-side" interface: with the Client Application, with the= Tracker processes components (in the Peer). = - "transport-side" interface: object types/assets, methods/messag= es, requests/replies/results operations, error codes/conditions either explicit or implicit, integrity, addressing. = = 3. Message Transport = The Message Transport addresses the efficient delivery of messages, indepen= dently of their meaning or purpose: = - message segmentation (message boundaries) = - multiplexing, pipelining, channeling = - flow and congestion control = = >From what is written in the swift description draft, there is no interactio= n with the Media Player apart from feeding it with the downloaded media, meaning that, as soon as the "Peer" knows = the root Hash or Public key (Swarm-ID) immediately starts pulling all the m= edia to feed the Player, without any interaction. The method is, apparently= , similar to a multi-source "progressive download". = One important aspect is that the signaling for bitmaps/hashes of swift is p= ush-mode, but the Media DATA streaming is always PULL-Mode, for either Live or on-demand. = = About the support of Structured Media, I could not see evidence of that, no= r how Swift deals with several representations of the media, i.e., video (several clips, multiple bitrates, layers), audio (= different audio dubbing languages), text (different subtitle languages), un= less all are multiplexed in a container file, or "contained" in a= directory of files, in order to be hashed in byte ranges. = An example of such a structure is the following, for a 10 seconds video enc= oded in SVC with two spacial resolutions (432x240 and 842x480) and 6 layers for quality fidelity, with an associated Audio t= rack. Each segment (with chunks labelled .00, .01, .02, etc for the differe= nt layers) corresponds to a duration of 2 seconds of media playout, and the= corresponding sizes are also indicated (example taken from a real test video). = = For this example, I suppose that swift would have to hash independently eac= h chunk, am I right? But then, how would it address the scalability, as the Client Player requester, would eventually not requ= est all the layers of a segment during those 10 seconds of duration (perhap= s, starting only up to layer L3 on the first segment, then raising to L4, t= hen L5 in the following segments, or, if bandwidth would allow up to L6 for the remaining segments). = +++L6.00+++ +++L6.01+&#= 43;+ +++L6.02+++ +++L6.03++= + +++L6.O4+++ ENH6 LAYER CHUNKS 162 KiB 172 KiB 154 KiB &nbs= p; 157 KiB 177 KiB = +++L5.00+++ +++L5.01+&#= 43;+ +++L5.02+++ +++L5.03++= + +++L5.O4+++ ENH5 LAYER CHUNKS 117 KiB 121 KiB 113 KiB &nbs= p; 120 KiB 117 KiB = +++L4.00+++ +++L4.01+&#= 43;+ +++L4.02+++ +++L4.03++= + +++L4.O4+++ ENH4 LAYER CHUNKS 4 KiB 6 KiB 6 KiB &nb= sp; 6 KiB 4 KiB <= /span> = +++L3.00+++ +++L3.01+&#= 43;+ +++L3.02+++ +++L3.03++= + +++L3.O4+++ ENH3 LAYER CHUNKS 3 KiB 5 KiB 5 KiB &nb= sp; 6 KiB 4 KiB <= /span> = +++L2.00+++ +++L2.01+&#= 43;+ +++L2.02+++ +++L2.03++= + +++L2.O4+++ ENH2 LAYER CHUNKS 5 KiB 6 KiB 5 KiB &nb= sp; 6 KiB 6 KiB <= /span> = +++L1.00+++ +++L1.01+&#= 43;+ +++L1.02+++ +++L1.03++= + +++L1.O4+++ ENH1 LAYER CHUNKS 54 KiB 55 KiB 49 KiB &n= bsp; 53 KiB 58 KiB = = +++L0.00+++ +++L0.01+&#= 43;+ +++L0.02+++ +++L0.03++= + +++L0.O4+++ BASE LAYER CHUNKS 50 KiB 52 KiB 50 KiB &n= bsp; 53 KiB 50 KiB = +++AA.00+++ +++AA.01+&#= 43;+ +++AA.02+++ +++AA.03++= + +++AA.O4+++ AUDIO Chunks 5 KiB 5 KiB 5 K= iB 5 KiB 5 KiB = = ---------------------------<= /font><= o:p> Best Regards, Prof. Rui Sa= ntos Cruz = Chairman IEEE&n= bsp;Portugal Section<= br> Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5,&= nbsp;2744-016 Porto Salvo, Portugal +351 214 233 200 (ext 5044), += ;351.939 060 939 (mobile) = rui.cruz@ieee.org rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ie= ee-pt.org Advancing technology for humanity.<= /span> = = On 24/11/2011, at 14:42, Martin Stiemerling wrote:= = = Dear all, The working group has to make a decision which peer protocol proposal to ch= oose as basis for the PPSP peer protocol. We have to independent proposals: - draft-gu-ppsp-peer-protocol-03 (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03) - draft-grishchenko-ppsp-swift-03 (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03) Both proposals for a peer protocol have been presented at the IETF meeting.= The slides are available here: - draft-gu-ppsp-peer-protocol-03: htt= p://www.ietf.org/proceedings/82/slides/ppsp-3.pptx - draft-grishchenko-ppsp-swift-03 http= ://www.ietf.org/proceedings/82/slides/ppsp-1.pdf The feedback given at the IETF meeting about both proposals is documented i= n the draft meeting minutes: http://www.= ietf.org/proceedings/82/minutes/ppsp.txt Please state your **technical** opinion about which peer protocol proposal = you would prefer on the PPSP mailing list until November 30th. With best regards Yunfei and Martin PPSP co-chairs martin.stiemerling@neclab.e= u NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org= /mailman/listinfo/ppsp = = _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp = martin.stiemerling@neclab.eu = NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registere= d in England 2832014 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E923F3Polydeucesoffic_-- From Martin.Stiemerling@neclab.eu Wed Nov 30 08:55:59 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F0621F8BB9 for ; Wed, 30 Nov 2011 08:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.837 X-Spam-Level: X-Spam-Status: No, score=-101.837 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5imEEPIS5Vh for ; Wed, 30 Nov 2011 08:55:58 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 454D821F8BB6 for ; Wed, 30 Nov 2011 08:55:58 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 95F3C280001C8; Wed, 30 Nov 2011 17:55:57 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4L3fBKSG3oSw; Wed, 30 Nov 2011 17:55:57 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 72A0128000082; Wed, 30 Nov 2011 17:55:37 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 30 Nov 2011 17:55:37 +0100 From: Martin Stiemerling To: Rui Cruz Thread-Topic: [ppsp] Selection of PPSP peer protocol draft Thread-Index: Acyqtvz2/G1P2VwpQ/iSlUDvVTm3/QDpwKeAABJZUpAAC2BCAAAq/vxp Date: Wed, 30 Nov 2011 16:55:36 +0000 Message-ID: References: <4ED48613.6070408@cs.yale.edu> , In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C564C3E381AC444E9955DF82D1792B9Aneclabeu_" MIME-Version: 1.0 Cc: LANS Yale , "ppsp@ietf.org" Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 16:55:59 -0000 --_000_C564C3E381AC444E9955DF82D1792B9Aneclabeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, On 29.11.2011, at 22:24, "Rui Cruz" > wrote: Hi Martin, Read inline please.... On 29/11/2011, at 15:13, Martin Stiemerling wrote: [speaking as individual contributor and not as chair of the PPSP WG] is not a good idea, as maturity can change in a relatively short time period, say between two IETFs, through some intensive engineering efforts, and we are designing a protocol that will last a much longer period. Hence it is important to consider the key technical design. I I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol= proposals and the merged document raises even more questions than the pred= ecessor documents. The only explicit mention to a merger of 2 proposals are related to the Tra= cker protocol, not to the Peer Protocol. Not according to this message sent to the list: http://www.ietf.org/mail-archive/web/ppsp/current/msg01109.html Nowhere in the gu-ppsp-peer draft nor in the corresponding presentation at = the iETF meeting, is mentioned any merger of two previous peer protocol pro= posals. The only "merger" that happened related with the Peer Protocol was of the p= eople working on the draft. Unfortunately, due to time limitations, it was not possible for us to write= all the details we were willing to write in that draft document, hoping th= at the discussion during the WG meeting would allow us to capture the "adva= ntages", the "features", the "extensions", etc. considered as suitable for = the improvement of the design. martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --_000_C564C3E381AC444E9955DF82D1792B9Aneclabeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, On 29.11.2011, at 22:24, "Rui Cruz" <rui.cruz@ieee.org> wrote: Hi Martin, Read inline please.... On 29/11/2011, at 15:13, Martin Stiemerling wrote: [speaking as individual contributor and not as chair of the PPSP WG] is not a good idea, as maturity can change in a r= elatively short time period, say between two IETFs, through some inten= sive engineering efforts, and we are designing a protocol that wil= l last a much longer period. Hence it is important to consider the key= technical design. I I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol= proposals and the merged document raises even more questions than the pred= ecessor documents. The only explicit mention to a merger of 2 proposals are related to th= e Tracker protocol, not to the Peer Protocol. Not according to this message sent to the list: http://www.ietf.org/mail-archive/web/ppsp/current/msg01109.html Nowhere in the gu-ppsp-peer draft nor in the corresponding presen= tation at the iETF meeting, is mentioned any merger of two previous pe= er protocol proposals. The only "merger" that happened related with the Peer Protoc= ol was of the people working on the draft. Unfortunately, due to time limitations, it was not possible for us to = write all the details we were willing to write in that draft document, hopi= ng that the discussion during the WG meeting would allow us to capture the = "advantages", the "features", the "extensions", etc. considered as suitable for the improvement of= the design. martin.stiemerling@n= eclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org= /mailman/listinfo/ppsp --_000_C564C3E381AC444E9955DF82D1792B9Aneclabeu_-- From rui.cruz@ieee-pt.org Wed Nov 30 09:07:29 2011 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F021F8BB0 for ; Wed, 30 Nov 2011 09:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gyATWxzz+vg for ; Wed, 30 Nov 2011 09:07:29 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0547321F8BCB for ; Wed, 30 Nov 2011 09:07:28 -0800 (PST) Received: by eabm6 with SMTP id m6so1086888eab.31 for ; Wed, 30 Nov 2011 09:07:26 -0800 (PST) Received: by 10.216.134.209 with SMTP id s59mr354639wei.62.1322672846731; Wed, 30 Nov 2011 09:07:26 -0800 (PST) Received: from [172.20.46.63] (gw-ext.tagus.ist.utl.pt. [193.136.166.125]) by mx.google.com with ESMTPS id gg1sm2716452wbb.17.2011.11.30.09.07.24 (version=SSLv3 cipher=OTHER); Wed, 30 Nov 2011 09:07:25 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB8182A0-DE8A-4345-8586-83E23D279AC1" From: Rui Cruz In-Reply-To: Date: Wed, 30 Nov 2011 17:07:25 +0000 Message-Id: <20D95C8E-B355-4B8D-859E-364061ADBDF4@ieee.org> References: <4ED48613.6070408@cs.yale.edu> , To: Martin Stiemerling X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz , "ppsp@ietf.org" , LANS Yale Subject: Re: [ppsp] Selection of PPSP peer protocol draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 17:07:29 -0000 --Apple-Mail=_EB8182A0-DE8A-4345-8586-83E23D279AC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30/11/2011, at 16:55, Martin Stiemerling wrote: >=20 > On 29.11.2011, at 22:24, "Rui Cruz" wrote: >=20 >>=20 >> The only explicit mention to a merger of 2 proposals are related to = the Tracker protocol, not to the Peer Protocol. >=20 > Not according to this message sent to the list: > http://www.ietf.org/mail-archive/web/ppsp/current/msg01109.html >>=20 >>>=20 Indeed, that was a misleading sentence that does not correspond to the = intention of the team. Sometimes being in a hurry creates these = unfortunate situations. >>>=20 >>> martin.stiemerling@neclab.eu >>>=20 >>> NEC Laboratories Europe - Network Research Division NEC Europe = Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014 >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >>=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_EB8182A0-DE8A-4345-8586-83E23D279AC1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On 30/11/2011, at 16:55, Martin Stiemerling wrote: On 29.11.2011, at 22:24, "Rui Cruz" <rui.cruz@ieee.org> wrote: The only explicit mention to a merger of 2 proposals are related to the Tracker protocol, not to the Peer Protocol. Not according to this message sent to the list: http://www.ietf.org/mail-archive/web/ppsp/current/msg01109.html Indeed, that was a misleading sentence that does not correspond to the intention of the team. Sometimes being in a hurry creates these unfortunate situations. martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_EB8182A0-DE8A-4345-8586-83E23D279AC1--