Rachel, <= /span>Roni Even and Lingli have = given some good comments.

There are some errors in the= survey draft which must be fixed.

when we written the survey draft, the RFC6972 is still in the dra= ft status. Now we can refer to RFC6972 for some definitions.

I will consider carefully so= me comments from Lingli and give the reply in the subsequent mail. --f46d0444ee6984ca0304ec8f703b-- From duanshihui1201@gmail.com Mon Dec 2 08:17:56 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578041AC499 for ; Mon, 2 Dec 2013 08:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_HQVCU0xPp3 for ; Mon, 2 Dec 2013 08:17:55 -0800 (PST) Received: from mail-oa0-x242.google.com (mail-oa0-x242.google.com [IPv6:2607:f8b0:4003:c02::242]) by ietfa.amsl.com (Postfix) with ESMTP id 51EEF1A8032 for ; Mon, 2 Dec 2013 08:17:55 -0800 (PST) Received: by mail-oa0-f66.google.com with SMTP id m1so3224898oag.5 for ; Mon, 02 Dec 2013 08:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BduNZqUm3XtVnFAHkt652NnOTJv70VWME/KWJixs+0k=; b=T+3vfBZQ9EU9nXweVDdChgD9VsOSfceVQOfScYM3clcWPnHnEOVXtmWnTwCvu8364U v2iKolKB7xFJzRST6BXDC37BbNa34MqeYd6Cw3nwE8lkCtZ+btz3njxneWvhUa94Rotv 3w7CLmehlxMp0nUTwVnWpidaLTlB4iPbjyAt6tqaJEvi1Ls1oDU3A2rM7sNNwwDgU8gn nO2mB+UXJsYBNv9KOtL5NVjitvrr+CG8nTkgnu2h3PFwkVXcWbXE+HhICTVwS7tjh14v BLOdD1myvtQF4jWZZmTC0lb5T+IBq1tlMaWCjknhnMRZJzzEbVfFFp4nP7fjOmikGvhh F2PA== MIME-Version: 1.0 X-Received: by 10.182.97.67 with SMTP id dy3mr183469obb.84.1386001071940; Mon, 02 Dec 2013 08:17:51 -0800 (PST) Received: by 10.60.43.69 with HTTP; Mon, 2 Dec 2013 08:17:51 -0800 (PST) Date: Tue, 3 Dec 2013 00:17:51 +0800 Message-ID: From: duan shihui To: ppsp@ietf.org Content-Type: multipart/alternative; boundary=047d7b2e4c028d2a3f04ec8f851b Subject: Re: [ppsp] WGLC for the survey draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2013 16:17:56 -0000 --047d7b2e4c028d2a3f04ec8f851b Content-Type: text/plain; charset=ISO-8859-1 Rachel, *Roni Even* and Lingli have given some good comments. There are some errors in the survey draft which must be fixed. when we written the survey draft, the RFC6972 is still in the draft status. Now we can refer to RFC6972 for some definitions. I will consider carefully some comments from Lingli and give the reply in the subsequent mail. --047d7b2e4c028d2a3f04ec8f851b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Rachel, <= /span>Roni Even and Lingli have = given some good comments.

There are some errors in the= survey draft which must be fixed.

when we written the survey draft, the RFC6972 is still in the dra= ft status. Now we can refer to RFC6972 for some definitions.

I will consider carefully so= me comments from Lingli and give the reply in the subsequent mail. --047d7b2e4c028d2a3f04ec8f851b-- From duanshihui1201@gmail.com Mon Dec 2 08:26:36 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8CA11AC7F1 for ; Mon, 2 Dec 2013 08:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_O-he6HuZeu for ; Mon, 2 Dec 2013 08:26:35 -0800 (PST) Received: from mail-ob0-x243.google.com (mail-ob0-x243.google.com [IPv6:2607:f8b0:4003:c01::243]) by ietfa.amsl.com (Postfix) with ESMTP id E53061ACC87 for ; Mon, 2 Dec 2013 08:26:18 -0800 (PST) Received: by mail-ob0-f195.google.com with SMTP id gq1so3164372obb.10 for ; Mon, 02 Dec 2013 08:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nAUMpqbbdShEsb9nNlwljTRbCkuLJTsUM1Y78bzlPEY=; b=sfoJs95iNDz9XddpvlkCbtbnlXIGR+5iVcAzHNNd8zpCmrSmPvDhKyAHAtDRcjtegH h+4FnvLfKG16VDVf973xm355TFDYpoe9P0Q0Kkn0Hdm7VppIm9Vwoaj5PDRzffAVJLKK Tx33QYpSfqINxHF2WeREyQB9q7KkTN5i5HPuW2Nb9DERgM/y3aoKpUxg80UdH3oMpp1C SJVgpkcTI/0inOibFJAUr+2SBvulMroLoik5LS2X2Vff3L+cdgNjNSXH/KMXJWwcmoiN t92Q0opyPkHKpsmjeGE1hVEVpmekBJdVEKqtsv8t32Yq/E+d8Bufnh6jhWLwGNfmw7MT Zwvg== MIME-Version: 1.0 X-Received: by 10.60.117.225 with SMTP id kh1mr55174471oeb.15.1386001576446; Mon, 02 Dec 2013 08:26:16 -0800 (PST) Received: by 10.60.43.69 with HTTP; Mon, 2 Dec 2013 08:26:16 -0800 (PST) Date: Tue, 3 Dec 2013 00:26:16 +0800 Message-ID: From: duan shihui To: ppsp@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a9a7c9f4ecd04ec8fa313 Subject: Re: [ppsp] WGLC for the survey draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 02 Dec 2013 16:26:37 -0000 --047d7b3a9a7c9f4ecd04ec8fa313 Content-Type: text/plain; charset=ISO-8859-1 Rachel, *Roni Even* and Lingli have given some good comments. There are some errors in the survey draft which must be fixed. when we written the survey draft, the RFC6972 is still in the draft status. Now we can refer to RFC6972 for some definitions. I will consider carefully some comments from Lingli and give the reply in the subsequent mail. --047d7b3a9a7c9f4ecd04ec8fa313 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Rachel, <= /span>Roni Even and Lingli have = given some good comments.

There are some errors in the= survey draft which must be fixed.

when we written the survey draft, the RFC6972 is still in the dra= ft status. Now we can refer to RFC6972 for some definitions.

I will consider carefully so= me comments from Lingli and give the reply in the subsequent mail. --047d7b3a9a7c9f4ecd04ec8fa313-- From flopicco@cisco.com Wed Dec 4 03:08:44 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE9E1AE220 for ; Wed, 4 Dec 2013 03:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Liey93z7yYRw for ; Wed, 4 Dec 2013 03:08:40 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 428601AE0FA for ; Wed, 4 Dec 2013 03:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=109141; q=dns/txt; s=iport; t=1386155316; x=1387364916; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=1bqHLE2fCnvzq1cxa0zQ2lrg93hleLeFDBvi22DeEAw=; b=Yc3+rgesFriPFvzC35bb8VW9q581MzsNWbqwKUBvdI6sUeLGbNanZFhA ifT5MlTRdsUGbiRvhqxiePT3djfhL9XRr80O5JCRffKl3nYoW35fA58Jj f8667Lixx2hNN1fQmGsvEQyDeKqbCWIdJsGTkpHVEwx3cmSEmEvrQecoU Y=; X-Files: PPSP survey figures.txt, Ppsp survey-flp0.4.docx : 4974, 52889 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAO8Ln1KtJXG9/2dsb2JhbABQAQmCQ0SBC7hpgSIWdIIlAQIEGAINUhIBCBEBAgECFgsHCR8RFAMGCAIEAQkEAwIODYdVAw+6Cg2HMReMbYE1AQoBATcHEQcKhCkDkDGBMYJPgXiBa4xahTmDKUCBKAYDFyI X-IronPort-AV: E=Sophos;i="4.93,824,1378857600"; d="xml'?rels'?docx'72,48?txt'72,48?scan'72,48,72,217,208,48";a="4222752" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-4.cisco.com with ESMTP; 04 Dec 2013 11:08:34 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB4B8YCp002647 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:08:34 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 05:08:34 -0600 From: "Francesca Lo Piccolo (flopicco)" To: Zongning , duan , "'yunfei zhang'" , Gu Yingjie , lingli deng Thread-Topic: [ppsp] WGLC for the survey draft Thread-Index: AQHO73s5GAAFU05hwEu4RkTzxrqSV5pEWLeA Date: Wed, 4 Dec 2013 11:08:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.147.74.75] Content-Type: multipart/mixed; boundary="_005_CEC4BA6718160flopiccociscocom_" MIME-Version: 1.0 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] WGLC for the survey draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2013 11:08:44 -0000 --_005_CEC4BA6718160flopiccociscocom_ Content-Type: multipart/alternative; boundary="_000_CEC4BA6718160flopiccociscocom_" --_000_CEC4BA6718160flopiccociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Duan and all, I absolutely agree with you on the good quality of received feedback and on= the necessity to fix some parts in the survey draft. To this end, I'm attaching a new revision of the survey (and also of the pi= ctures), where most of the comments from Rachel, Roni and Lingli have been = already taken into account. Here is a summary of all the received comments, with the ones still open hi= ghlighted in red. Lingli, you are among the "to" receivers, because there i= s some your comment I would like to further discuss with you. Rachel --------- + The description in the last paragraph of Section 1 is inconsistent with t= he organization of chapters . This should be fixed. --> Ning, is it possibl= e to turn section 3.1 (and subsections) into section 4 and 3.2 (and subsect= ions) in section 5 and 3.3 (and subsections) in section 6? + In section 2, some terminologies have already defined in RFC6972. It=92s = unnecessary to repeat the definition, e.g., chunk, live streaming=85 --> do= ne + Section 1 typo: =93we always try to identity tracker and peer protocols= =94 should be =93we always try to identify tracker and peer protocols=94 --= > done + Section 3.1, typo =93this may turn at end users into playback quality deg= radation=94 should be =93this may turn end users into playback quality degr= adation=94 --> done + It=92s better to adjust the order of types of P2P streaming applications = to be consistent with the order of subsections, which means =93mesh-based= =94 should be first, then =93tree-based=94. --> done Roni ------ + Figure 1 =93traker=94 should be =93tracker=94 --> done + In section 3.1.2 on PPLive change =93being the nature of PPLive protocols= and algorithm proprietary=94 to =93 Since the protocols and algorithm of P= PLIVE are proprietary=94 --> done + In section 3.1.3 =93 Authentication server is the first point of contact = for a peer the joins the system=94 to =93Authentication server is the first= point of contact for a peer that joins the system=94 --> done + In section 3.1.3 =93 can contact new more peers besides the ones indicate= d by the rendezvous server=94 to =93can contact new peers besides the ones = indicated by the rendezvous server=94 --> done + In section 3.1.5 =93Since children could lie regarding the number of chun= ks forwarded to others, Tribler peers do directly not ask their children, b= ut their grandchildren.=94 To =93Since children could lie regarding the num= ber of chunks forwarded to others, Tribler peers do not ask their children = directly, but their grandchildren.=94 --> done + In section 3.1.6 when first using CDN expand to Content Delivery Network = (CDN) --> done Lingli ------- + it states as a "standard track" document, is that accurate? --> Ning, we = already discussed about this. As per your comment, this document should be = =93informational=94, rather than =93standard track=94. I assume this is som= ething you can take into account as soon as you will submit the final revis= ion, right? + in terminoloy section, "push" is defined as "Transmission of multimedia c= ontent without any request from receiving peers.", which I think could be b= etter described as "Transmission of multimedia content that is not initiate= d by receiving peers." --> done + In section 3, "the topology that can be associated with overlay connectio= ns among peers" could be rephrased into "the topology of overlay connection= s among peers". --> done + Also in section 3, "pull-based data delivery calls for large size buffers= where to store chunks" could be rephrased into "pull-based data delivery c= alls for large size buffers to store chunks". --> done + "buffer-maps" are used to refer to "chunk availability information" (as u= sed by RFC 6972). For sake of consistency, I think it is better to use the = latter instead. --> I re-phrased "in some applications peers exchange chunk= availability information in form of buffer-maps (a sort of bit maps with a= bit "1" in correspondence of chunks stored in the local buffer)". Lingli, = have I got your point? + In Section 3.2.1 =93channel server, that provides the list of available c= hannels (live TV or VoD content) to a PPLive, as soon as the peer joins the= system;=94 should be =93channel server, that provides the list of availabl= e channels (live TV or VoD content) to a PPLive peer, as soon as the peer j= oins the system;=94 --> done + It seems to me that the content server may have played some sort of track= er=92s role in Octoshape, otherwise, how would a joining peer gets to know = the initial address book of other peers? --> done + In Section 3.2.3, =93a mechanism very similar to the one of TCP congestio= n window (double increase or linear increase depending on whether the estim= ate is below or a given threshold)=94, should be like =93a mechanism very s= imilar to the one of TCP congestion window (double increase or linear incre= ase depending on whether the estimate is below or above a given threshold)= =94 --> done + One may be curious about what is the difference between a =93repeater nod= e=94 and a =93simple peer=94, as the description of a =93repeater node=94 g= oes like =93Repeater nodes, that serve as bandwidth multiplier, are able to= forward any sub-stream and implement the same peer protocol as simple peer= s.=94 --> I re-phrased "simple peers, whose behavior has already been pres= ented, and repeater nodes, that implement the same peer protocol as simple = peers and in addition are high-bandwidth peers and are able to forward any = sub-stream. In such a way repeater nodes serve as bandwidth multiplier". L= ingli, have I got your point? + In Section 3.2.4, =93a PPStream peer selects peers to download sub-chunks= from according to a rate-based algorithm=94 should be change into =93a PPS= tream peer selects peers to download sub-chunks according to a rate-based a= lgorithm=94 --> done + In Section 3.1.5, =93As already said, Tribler supports video streaming in= two different forms: video on demand and live streaming.=94 Is better to b= e changed into =93Tribler supports video streaming in two different forms: = video on demand and live streaming.=94, since there is no prior statement i= n the draft. --> done + Also in Section 3.1.5, =93Such a mechanism allows Tribler peers to use th= e public key included in torrent file and verity the integrity of each chun= k.=94 should be changed into =93Such a mechanism allows Tribler peers to us= e the public key included in torrent file and verify the integrity of each = chunk.=94 --> Lingli, I think your comment after the subsequent one is corr= ect. So I completely removed this part. See my observation later on. Do you= agree? + There is considerable reference and comparison to the Bitorrent system/mo= del in the Tribler=92s subsection, one may wonder why not pose a separate s= ection for introduction of Bittorrent instead? Lingli, I don't think this i= s the case, because Bit Torrent is a P2P file sharing system and I have the= impression that a section devoted to a P2P file sharing system could appea= r somehow out of scope. In addition, every time Bit Torrent is cited, we al= ways tried to provide the necessary background info. Does it make sense? + It is noticeable that both the Tribler=92s peer selection algorithm and s= ecurity mechanisms are elaborated in such a detailed way? What about other = systems in terms of similar design issues? Since Section 3 is focus mainly = on the peer topology, maybe separate sections on algorithm/security are mor= e natural for better compression. --> Lingli, the main problem here is that= such a level of detail is often not available for all the applications. Re= garding this point I also added the following statement in "Introduction" s= ection "In addition, the provided descriptions may sometimes appear inhomog= eneous from the detail level point of view, but this always depends on the = amount of available information at writing time.". So the only solution se= ems to me to remove the reference to the security mechanisms. The peer sele= ction algorithm is full part of the peer protocol in my opinion and it has = to be kept. But i would like to hear from you. + In Section 3.1.6, what does it mean by =93not RTP/RTCP=94 in =93the clien= t use UDP to transfer the encrypted media streaming and not RTP/ RTCP.=94? = --> Duan, if I remember correctly, you provided this part. Can you please e= xplain? + In Section 3.3.1, =93Parent re-selection is also applied in case of leavi= ng of the previous parent.=94 Is better to be changed into =93Parent re-sel= ection is also triggered for a peer when its previous parent leaves.=94 -->= done + From the description in Section 3.3.1, it is not clear to me why the QQLi= ve=92s topology is a hybrid of mesh and tree. --> Lingli, this comment is = not completely clear for me. Probably you meant New Coolstreaming. If so, N= ew Coolstreaming may be regarded as hybrid, because on the one side you hav= e an overlay mesh, on the other side you have as many trees as substreams. = I also added the following statement "Hence, the overall overlay topology i= s mesh-based, but it is also possible to identify as many overlay trees as = sub-streams.". Is it clearer now? Please, let me know. Regards Francesca From: duan shihui > Date: Monday, December 2, 2013 5:26 PM To: "ppsp@ietf.org" > Subject: Re: [ppsp] WGLC for the survey draft Rachel, Roni Even and Lingli have given some good comments. There are some errors in the survey draft which must be fixed. when we written the survey draft, the RFC6972 is still in the draft status.= Now we can refer to RFC6972 for some definitions. I will consider carefully some comments from Lingli and give the reply in t= he subsequent mail. --_000_CEC4BA6718160flopiccociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Duan and all,

I absolutely agree with you on the good quality of received feedback and on= the necessity to fix some parts in the survey draft.

To this end, I'm attaching a new revision of the survey (and also of the pi= ctures), where most of the comments from Rachel, Roni and Lingli have = been already taken into account.

Here is a summary of all the received comments, with the ones still open hi= ghlighted in red. Lingli, you are among the "to" receivers, becau= se there is some your comment I would like to further discuss with you.

Rachel

---------

+ The description in the last paragraph of Sect= ion 1 is inconsistent with the organization of chapters . This should be fi= xed. --> Ning, is it possible to turn section 3.1 (and subsections) into= section 4 and 3.2 (and subsections) in section 5 and 3.3 (and subsections) in section 6?

+ In section 2, some terminologies have already defined in RFC6972. It= =92s unnecessary to repeat the definition, e.g., chunk, live streaming=85 -= -> done

+ Section 1 typo: =93we always try to identity tracker and peer protoco= ls=94 should be =93we always try to identify tracker and peer protocols=94 = --> done

+ Section 3.1, typo =93this may turn at end users into playback quality= degradation=94 should be =93this may turn end users into playback quality = degradation=94 --> done

+ It=92s better to adjust the order of types of P2P streaming appl= ications to be consistent with the order of subsections, which means =93mes= h-based=94 should be first, then =93tree-based=94. --> done

Roni

------

+ Figure 1 =93traker=94 should b= e =93tracker=94 --> done

+ In section 3.1.2 on PPLive cha= nge =93being the nature of PPLive protocols and algorithm proprietary=94 to= =93 Since the protocols and algorithm of PPLIVE are proprietary=94 &n= bsp;--> done

+ In section 3.1.3 =93 Authentic= ation server is the first point of contact for a peer the joins the system= =94 to =93Authentication server is the first point of contact for a peer th= at joins the system=94 --> done

+ In section 3.1.3 =93 can conta= ct new more peers besides the ones indicated by the rendezvous server=94 to= =93can contact new peers besides the ones indicated by the rendezvous serv= er=94 --> done

+ In section 3.1.5 =93Since chil= dren could lie regarding the number of chunks forwarded to others, Tribler = peers do directly not ask their children, but their grandchildren.=94 To = =93Since children could lie regarding the number of chunks forwarded to others, Tribler peers do not ask their children dir= ectly, but their grandchildren.=94 --> done

+ In section 3.= 1.6 when first using CDN expand to Content Delivery Network (CDN) --&g= t; done

Lingli<= /span>

-------=

+ it states as a "standard track" document, i= s that accurate? --> Ning, we already discussed about this. As per your = comment, this document should be =93informational=94, rather than =93standard track=94. I assume this is something you can take into ac= count as soon as you will submit the final revision, right?

+ in terminoloy section, "push" is defined as "Transmiss= ion of multimedia content without any request from receiving peers.", = which I think could be better described as "Transmission of multimedia= content that is not initiated by receiving peers." --> done

+ In section 3, "the topology that can be associated with overlay&= nbsp;connections among peers" could be rephrased into "the topolo= gy of overlay connections among peers". --> done

+ Also in section 3, "pull-based data delivery calls for large siz= e buffers where to store chunks" could be rephrased into "pull-ba= sed data delivery calls for large size buffers to store chunks". -->= ; done

+ "buffer-maps" are used to refer to "ch= unk availability information" (as used by RFC 6972). For sake of consi= stency, I think it is better to use the latter instead. --> I re-phrased "in some applications peers exchange chunk availability = information in form of buffer-maps (a sort of bit maps with a bit "1&q= uot; in correspondence of chunks stored in the local buffer)". Lingli,= have I got your point?

+ In Section 3.2.1 =93channel server, that provides the list of availab= le channels (live TV or VoD content) to a PPLive, as soon as the peer joins= the system;=94 should be =93channel server, that provides the list of avai= lable channels (live TV or VoD content) to a PPLive peer, as soon as the peer joins the system;=94 --> done

+ It seems to me that the content server may have played some sort of t= racker=92s role in Octoshape, otherwise, how would a joining peer gets to k= now the initial address book of other peers? --> done

+ In Section 3.2.3, =93a mechanism very similar to the one of TCP conge= stion window (double increase or linear increase depending on whether the e= stimate is below or a given threshold)=94, should be like =93a mechanism ve= ry similar to the one of TCP congestion window (double increase or linear increase depending on whether the estimate is b= elow or above a given threshold)=94 --> done

+ One may be curious about what is the difference betwe= en a =93repeater node=94 and a =93simple peer=94, as the description of a = =93repeater node=94 goes like =93Repeater nodes, that serve as bandwidth multiplier, are able to forward any sub-stream and implement = the same peer protocol as simple peers.=94 --> I re-phrased "= simple peers, whose behavior has already been presented, and repeater nodes= , that implement the same peer protocol as simple peers and in addition are high-bandwidth peers and are able to forward any= sub-stream. In such a way repeater nodes serve as bandwidth multiplier&quo= t;. Lingli, have I got your point?

+ In Section 3.2.4, =93a PPStream peer selects peers to download sub-ch= unks from according to a rate-based algorithm=94 should be change into =93a= PPStream peer selects peers to download sub-chunks according to a rate-bas= ed algorithm=94 --> done

+ In Section 3.1.5, =93As already said, Tribler supports video streamin= g in two different forms: video on demand and live streaming.=94 Is better = to be changed into =93Tribler supports video streaming in two different for= ms: video on demand and live streaming.=94, since there is no prior statement in the draft. --> done

+ Also in Section 3.1.5, =93Such a mechanism allows Tri= bler peers to use the public key included in torrent file and verity the in= tegrity of each chunk.=94 should be changed into =93Such a mechanism allows Tribler peers to use the public key includ= ed in torrent file and verify the integrity of each chunk.=94 --> Lingli= , I think your comment after the subsequent one is correct. So I completely= removed this part. See my observation later on. Do you agree?

+ There is considerable reference and comparison to the= Bitorrent system/model in the Tribler=92s subsection, one may wonder why n= ot pose a separate section for introduction of Bittorrent instead? Lingli, I don't think this is the case, because Bit= Torrent is a P2P file sharing system and I have the impression that a sect= ion devoted to a P2P file sharing system could appear somehow out of scope.= In addition, every time Bit Torrent is cited, we always tried to provide the necessary background info. Does i= t make sense?

+ It is noticeable that both the Tribler=92s peer selec= tion algorithm and security mechanisms are elaborated in such a detailed wa= y? What about other systems in terms of similar design issues? Since Section 3 is focus mainly on the peer topology, maybe= separate sections on algorithm/security are more natural for better compre= ssion. --> Lingli, the main problem here is that such a level of detail = is often not available for all the applications. Regarding this point I also added the following statement in= "Introduction" section "In addition, the provided descriptions may sometime= s appear inhomogeneous from the detail level point of view, but this always depends on the amount of available information at= writing time.". So the only solution see= ms to me to remove the reference to the security mechanisms. The peer selection algorithm is full part of the peer protocol= in my opinion and it has to be kept. But i would like to hear from you.

+ In Section 3.1.6, what does it mean by =93not RTP/RTC= P=94 in =93the client use UDP to transfer the encrypted media streaming and= not RTP/ RTCP.=94? --> Duan, if I remember correctly, you provided this part. Can you please explain?

+ In Section 3.3.1, =93Parent re-selection is also applied in case of l= eaving of the previous parent.=94 Is better to be changed into =93Parent re= -selection is also triggered for a peer when its previous parent leaves.=94= --> done

+ From the description in Section 3.3.1, it is not clea= r to me why the QQLive=92s topology is a hybrid of mesh and tree. --&= gt; Lingli, this comment is not completely clear for me. Probably you meant New Coolstreaming. If so, New Coolstreaming ma= y be regarded as hybrid, because on the one side you have an overlay mesh, = on the other side you have as many trees as substreams. I also added the fo= llowing statement "Hence, the overall overlay topology is mesh-based, but it is also possible to identify as man= y overlay trees as sub-streams.". Is it clearer now?

Please, let me know.

Regards

Francesca

From: duan shihui <duanshihui1201@gmail.com>
Date: Monday, December 2, 2013 5:26= PM
To: "ppsp@ietf.org" <ppsp@i= etf.org>
Subject: Re: [ppsp] WGLC for the su= rvey draft

Rachel, Roni Even and Lingli have given some go= od comments.

There are some errors in the survey draft which must be= fixed.

when we written the survey draft, the RFC6972 is still = in the draft status. Now we can refer to RFC6972 for some definitions.

I will consider carefully some comments from Lingli and= give the reply in the subsequent mail.

--_000_CEC4BA6718160flopiccociscocom_-- --_005_CEC4BA6718160flopiccociscocom_ Content-Type: text/plain; name="PPSP survey figures.txt" Content-Description: PPSP survey figures.txt Content-Disposition: attachment; filename="PPSP survey figures.txt"; size=4974; creation-date="Wed, 04 Dec 2013 11:08:33 GMT"; modification-date="Wed, 04 Dec 2013 11:08:33 GMT" Content-ID: Content-Transfer-Encoding: base64 DQoNCiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICB8ICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgfCAgICAgfCAgICAgICAgICAgIFRyYWNrZXIgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgIHwNCgkJICAgCQkgIHwJICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICB8ICAgICB8ICBJbmZv cm1hdGlvbiBvbiBtdWx0aW1lZGlhICAgICB8ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgfCAgICAgfCAgICAgY29udGVudCBhbmQgcGVlciBzZXQgICAgICAgfCAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgIHwgICAgICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICB8ICAg ICAgICBeICB8ICAgICAgICAgICAgICAgICAgICBeICB8ICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAgICAgfCAgfCAg ICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgIHwgIFRy YWNrZXIgICAgICAgICAgIHwgIHwgIFRyYWNrZXIgICAgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICB8ICAgICAgICB8ICB8IFByb3RvY29sICAgICAgICAgICB8ICB8IFByb3RvY29sICAgICAg ICAgICAgfA0KICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgfCAgICAgICAgICAgICAgICAg ICAgfCAgfCAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgIHwgICAgICAg IHwgIHwgICAgICAgICAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICAgICAgICAgICAgICAgICAgICB8ICB8ICAgICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgfCAgICAgICAgfCAgViAgICAgICAg ICAgICAgICAgICAgfCAgViAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg IHwgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICB8ICAgfCAgIFBlZXIgMSAgICB8PC0tLS0tLS0tfCAgIFBl ZXIgMiAgIHwgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgfCAgIHwgICAgICAg ICAgICAgfC0tLS0tLS0tPnwgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0tLSsgICAgICAgICArLS0tLS0tLS0tLS0tKyAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgIFBlZXIgUHJv dG9jb2wgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN CiAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KRmlndXJlIDEsIEhpZ2ggbGV2ZWwgbW9kZWwgb2Yg UDJQIHN0cmVhbWluZyBzeXN0ZW1zIGFzc3VtZWQgYXMgcmVmZXJlbmNlIG1vZGVsIHRocm91Z291 dCB0aGUgZG9jdW1lbnQNCg0KDQoNCiAgICAgICAgICAgICstLS0tLS0tLS0tLS0rICAgICstLS0t LS0tLS0tLS0rDQogICAgICAgICAgICB8ICAgUGVlciAyICAgfC0tLS18ICAgUGVlciAzICAgfA0K ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgICAgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAg ICAgIHwgICAgICB8ICAgICAgICAgIHwgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgIHwg ICAgICAgICAgfCAgICAgICB8DQogICAgICAgICAgICAgICB8ICAgICstLS0tLS0tLS0tLS0tLSsg ICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgfCAgICBQZWVyIDEgICAgfCAgICAgfA0KICAgICAg ICAgICAgICAgfCAgICArLS0tLS0tLS0tLS0tLS0rICAgICB8DQogICAgICAgICAgICAgICB8ICAg ICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHwgICAgICAgICAgICB8ICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICB8DQog ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgIHwgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsgICB8DQogICAgICAgICAgICB8ICAgfFZpZGVvIFN0cmVhbWluZyBT ZXJ2ZXJ8ICAgfA0KICAgICAgICAgICAgfCAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgIHwN CiAgICAgICAgICAgIHwgICB8ICAgIENoYW5uZWwgU2VydmVyICAgIHwgICB8DQogICAgICAgICAg ICB8ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgfA0KICAgICAgICAgICAgfCAgIHwgICAg VHJhY2tlciBTZXJ2ZXIgICAgfCAgIHwNCiAgICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsgICB8DQogICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQpGaWd1 cmUgMywgSGlnaCBsZXZlbCBvdmVydmlldyBvZiBQUExpdmUgc3lzdGVtIGFyY2hpdGVjdHVyZQ0K DQoNCg0KICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQog ICAgICB8ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAgICAgIHwgICAgICAgICAr LS0tLS0tKw0KICAgICAgfCAgIHwgICAgQnJvYWRjYXN0IFNlcnZlciAgICAgICAgIHwgICAgICB8 LS0tLS0tLS0tfFBlZXIgMXwtLS0tLS0tLS0tLXwNCiAgICAgIHwgICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tICAgICAgfCAgICAgICAgICstLS0tLS0rICAgICAgICAgICB8DQogICAg ICB8ICAgfCAgQXV0aGVudGljYXRpb24gU2VydmVyICAgICAgfCAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAgICAgfCAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0gICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgUmVwZWF0ZXIgbm9kZXwN CiAgICAgIHwgICB8ICAgIFJlbmRlenZvdXMgU2VydmVyICAgICAgICB8ICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0rDQogICAgICB8ICAgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSAgICAgIHwgICAgICAgICArLS0tLS0tKyAgICAgICAgICAgfA0KICAg ICAgfCAgIHwgQmFuZHdpZHRoIEVzdGltYXRpb24gU2VydmVyIHwgICAgICB8LS0tLS0tLS0tfFBl ZXIgMnwtLS0tLS0tLS0tLXwNCiAgICAgIHwgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tICAgICAgfCAgICAgICAgICstLS0tLS0rDQogICAgICB8ICAgfCAgICAgIE90aGVyIFNlcnZl cnMgICAgICAgICAgfCAgICAgIHwNCiAgICAgIHwgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tICAgICAgfA0KICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQoNCg0KRmlndXJlIDQsIEhpZ2ggbGV2ZWwgb3ZlcnZpZXcgb2YgWmF0dG9vIHN5c3Rl bSBhcmNoaXRlY3R1cmUNCg0KICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsNCiAg ICAgICAgICAgICAgICAgICAgIHwgU3VwZXJwZWVyICB8DQogICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIC8gICAgICAgICBcDQogICAgICAg ICAgICAgICAgICAgICAvICAgICAgICAgICBcDQogICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAg ICArLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgfCAgIFBlZXIgMiAgIHwtLS0tfCAgIFBlZXIg MyAgIHwNCiAgICAgICAgICAgICstLS0tLS0tLS0tLS0rICAgICstLS0tLS0tLS0tLS0rDQogICAg ICAgICAgICAgICAgICAvICAgfCAgICAgICAgICAgICAgICBcDQogICAgICAgICAgICAgICAgIC8g ICAgfCAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgICAgICAgIC8gICArLS0tLS0tLS0tLS0t LS0rICAgICBcDQogICAgICAgICAgICAgICAvICAgIHwgICAgUGVlciAxICAgIHwgICAgICBcDQog ICAgICAgICAgICAgIC8gICAgICstLS0tLS0tLS0tLS0tLSsgICAgICAgXA0KICAgICAgICAgICAg IC8gICAgICAgICAgICAvICAgICAgICBcICAgICAgICBcDQogICAgKy0tLS0tLS0tLS0tLSsgICAg ICAgLyAgICAgICAgKy0tLS0tLS0tLS0tLS0tKw0KICAgIHwgICBQZWVyIDQgICB8ICAgICAgLyAg ICAgICAgIHwgICAgUGVlciA1ICAgIHwNCiAgICArLS0tLS0tLS0tLS0tKyAgICAgLyAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgIFwgICAgICAgICAgLyAgICAgICAgICAgICAg ICAgICAvDQogICAgICAgICAgICBcICAgICAgICAvICAgICAgICAgICAgICAgICAgIC8NCiAgICAg ICAgICAgICBcICAgICAgLyAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLSsgICAgICAgIHwgU3VwZXJwZWVyICB8DQogICAgICAgICAgICB8IFN1cGVy cGVlciAgfCAgICAgICAgKy0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICstLS0tLS0tLS0tLS0r DQoNCg0KRmlndXJlIDUsIEhpZ2ggbGV2ZWwgb3ZlcnZpZXcgb2YgVHJpYmxlciBzeXN0ZW0gYXJj aGl0ZWN0dXJlDQoNCg0K --_005_CEC4BA6718160flopiccociscocom_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Ppsp survey-flp0.4.docx" Content-Description: Ppsp survey-flp0.4.docx Content-Disposition: attachment; filename="Ppsp survey-flp0.4.docx"; size=52889; creation-date="Wed, 04 Dec 2013 11:08:33 GMT"; modification-date="Wed, 04 Dec 2013 11:08:33 GMT" Content-ID: <555D707EA7561F4C9F49C243D2C11427@emea.cisco.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCGP1varwEAABoHAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VV1P2zAUfZ/Ef4j8OiUue0BoasrDBo+ARBF7dZ2b1pq/5HsL9N9znZaIQZV063iJlDjnw8f28fTi 2dniERKa4GtxWk1EAV6HxvhlLe7nV+W5KJCUb5QNHmqxARQXs5Mv0/kmAhaM9liLFVH8LiXqFTiF VYjgeaQNySni17SUUenfagny22RyJnXwBJ5KyhxiNv0JrVpbKi6f+fPWCcNF8WP7X5aqhYrRGq2I jco8KvfiElgcAD765p27cuesYmRHjisT8etO4YajSaaB4lYlulaOfcinkBrZBL12PIdq2OgevdC2 RkOPz2wxBQ2InLmzVT/ilPFDPvQaKbhfzkpD4G5TiHh6tJ2eNPNBIgPjWfi1W0Bi90erfwijpx4K olsQpI0F/P8OtrwHyj8YWl22LWje9eMbw2GZrVdbiTfYcTUg4rwPEfnzLJZjuw93zKMWnmBx92ku 3pCPGtHB5YP4CVm8Mo9aaLmn5mph4YBF/8v16KlHTRB3L8jueXwNdDRDktxSXeNwl6d/mPZr6WZ0 yfV3QNX0inwRHJ0z5JumgWaPtuxuttkLAAAA//8DAFBLAwQUAAYACAAAACEAwmCa8/QAAABOAgAA CwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySwUoDMRCG74LvEObenW0FEWm2FxF6E6kPMCTT3aW7SUhG bd/eQVRcWGuPSWa++eYn681xHMwb59LHYGFZ1WA4uOj70Fp42T0u7sAUoeBpiIEtnLjAprm+Wj/z QKJNpetTMUoJxUInku4Ri+t4pFLFxEFf9jGPJHrMLSZyB2oZV3V9i/k3A5oJ02y9hbz1SzC7U9LJ /7Pjft87fojudeQgMyNwWqFkyi2LhfeYPfqvxkqVAedtVpfb/L0pjizkSQhdzLxIWXPK0muyP0Lq 8qTX5bPinNDN5ULT5efi4aNw8OzPK1FK30Y4+QXNBwAAAP//AwBQSwMEFAAGAAgAAAAhAHcv6c19 AgAANA0AABwACAF3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzIKIEASigAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAvJdNb9pAEIbvlfofkO/eBZombRWSQ5tIOeRSiNpbtazH9ir7ld2x Cf31HcxHQQlugywfQPIsnn329Xje4fL62ehBDSEqZyfJiA2TAVjpMmWLSfIwu00/JYOIwmZCOwuT ZAkxub56/+7yO2iBdFMslY8DymLjJCkR/RfOoyzBiMicB0sruQtGIF2GgnshH0UBfDwcnvOwnyO5 Osg5uMsmSbjLPieD2dLTzv/O7fJcSfjmZGXA4itb8JIyBa3sIyUVoQDcpUXndGQKMG8wSzSaZ0Hk mK5iqffRp7EKNSzT4cft3fcuI7CbZ4RghU746ycYk6bdHQFJWtgCTJLmkjffI0ZaH4MYdQpxXMfF YsGktUw6s4X8P5VGoy5Vagf0HusVIX8j4rgfxN8CqRxPAfzQD+DqIdMbgQGEOeFJn/VDGWvLMKi5 htC803McpxlEVVjug0OXRg8yrazKFWQcQ2Uf9xdkFQK1Eeaz/I1lsuoPPbSsmj09naD+eT90TSNw tla1OAHyoh9IiFS/kUlTMcgqjiBL67QrluRT5BSRT1VhgIqIfvRVRLh14WZ6z8i8hifUBVlpH3VB do1KsiqCVc9N5UNNhRz5OjI8a87JC7AQhOZ5pfWvzXFlWXH6nHC2Tm06dxZngl5cEmxj07tQq8l1 KbCsIjrzkyx1B8EY30W5QjCtltupW9jKzCHQVPaXZhdqk6RTR4i41DT/7fRYX7dtf6zVGyWDiy7H xuXWg9tqYLs4nAn5eocfCsubPAeJLzbfW2rj6LQlR0CkJ7HPsom0IXTadxcwn76g2Au2gXTaW2mK Wg3be1psI20IPXXCjoZ6fvBf5+oPAAAA//8DAFBLAwQUAAYACAAAACEAZNmtQylxAADOGwIAEQAA AHdvcmQvZG9jdW1lbnQueG1s7H3ZktvIme79iTjvgKgLR3eESuICbvKIE1zdCvdSI8k+EdPRFygS VQWLJGgAVKn6yg8y83J+kvN9fyaARBJggWRVt9puRzskgUAuf/77lv/xn5/XK+eTH8VBuHlz0XzZ uHD8zSJcBpvbNxd/+TC/7F84ceJtlt4q3PhvLh78+OI/h//3//zH/etluNit/U3iYIhN/Pp+u3hz cZck29evXsWLO3/txS/XwSIK4/AmebkI16/Cm5tg4b+6D6Plq1aj2ZC/baNw4ccx5pt4m09efKGH W4f1Rlt7i3TgVqPRf7X2gk02xv6Kwq2/wXpvwmjtJfHLMLrFF9HH3fYSK9x6SXAdrILkAetrdLNh Pr252EWb13pXl9mu+M1rLOD1p/UqfRnLrn5XQeC1+iP9ItrbaMki1SdTDXJZ3qvIX2HB4Sa+C7Y5 3E4dDfC4S5d0cMPGZu+3TXdvvgw8dQ59Gnn3OPt04vvt3nAlwFiqj9YrBQciVI5G9ojNRo0T4RDZ GuosoThnuhIT+e5PA02OSfdbkOA5BPWnKNxts11tg/NGe7v5mI1FTnDEyhpdIXVza/FRA+zxivd3 3ta/cNaL129vN2HkXa+wIkDcIUZeDMGdrsPlA//cOnj8eutF3tvlm4uGO500J+35hTxN/M8Jn/b0 //D0NTjh8h1ebHRmbrM3zh5N/Rtvt0r2f7kyHsmEV5H88T55WPkY8JO3enPxje+RpbYuXg3/4xUW pd6RF5Ph6DpOIm+R8JdEfscPfGt//e1Bd9Jsu2BN3FW2/kZn2pu2Z9liZUmt7rQxzR5dgc1gU8WH 5qYKv6hNqUfGpiK17utJjH3cv155m9t0h/7m8k9jvT15zdhmCtbCGjjAMeMBNhQNr+Ott8BhbyM/ 9qNP/sXww10QO5kwkuebJHY8J97h9wcnvHHicO07BfBi7hMWMMRYyZ3vrMM4cbbhdrfyIufK96PL JLy0x3+qXQ85gfPVVevqa4jiyPfWwCTH225XwULxfyfcOEXsOW175fDFft9uEj/a+MlLx/nA7UPG OrG/8hcUP3uAfaqNly9nEQVYTOA5d94n37n2/U16EpDbDjSVvfWccNDlU3ufvGDlKQ2BaBVslB5B IDwjHIYQgZGctLP0EywByJ0494ADESEJbMR7sv2ufRz42w2ISyYCnb3Qx+7vQ/l5T72A7l7kO5sw cSL/U+DfYy0eyf3+Llz5L5zrXUIaBSrgreyN+yC5c/A/Qd0bqFGxEA2Q2YIeFInwZhZF2E7ysAWj ibf+avU+8aKE3A2E9VQbHcbB7cZbAbS1ljDbLJ94AeVILiS0CDdJFFrrOoVjls+xcgDmJFyEK2cX 4/yS0PFhZVyvgvjOPpAng3f5UsgwiBSgKxAxLKGV9+Bg+xvF3IBY6xBUtgUPxt+fk7sACN4SC0iC 2C+d6ckQbxneb1ahtzTECQ8cttzLwpGX6yDdeXM26s4mUC1MHeTX0qEsqCitjYSaDEG1CQmdQhs6 wnf+uojS5ftrdObdUafxrPuzmcxt5K1NHqPW//nz58J5QCUs+1BzhvLddFutbq897Xwhp6U2Ngm3 D1Fwe5c434cJfAKFXZbvo9dvd/uzNhXaI7FOa52nqvNlEH+eo+rM5+PRrG8r92cTVnPQngEBCHpt eGzrGCcHCOsDDS7S1USxjbjGAXY63XarN+8df4CmlVI4xT3T6xc8qz4cWLPGqMZu3G6j1yf9KdvS 2E3xF9mNfnTsWSmygpoehcudaOU1TqQ16s8HfdfaQ3fQazUno2a24BK7sWDIlWysaGYeNiafyog8 OA6lwWjj+BCvl8FmASOKHkdns1tfw7YCIq9h2wdrfwm7Irex4oc48ddxbmkUgFq0sR6bvlz7OFrZ eWyaobcMt2IXpGapYT3SC7IMbtfUt9QuzX17u2UAFQQqzqdg6YdUgqgSxM5NFK5pToe7aOHzW8+B 3XsLHTwDn4+voMlFsViIkLX4j4Zy5N/4ERzKvhMv/I0XYYJUGqcW+wso7sHiDhohDPpSw12+sI3u 1pVxUEXrQFlpZFAwi7GITXjvLb2HGKaMNmML51gubzqNQWc+HlueopY76jfbIzjFNTX/qxAHzXp9 AtDHtedkGfqxGFpeAARIYGyTaPzPd94uToJPtA7fZSaY6Y8Q0zzYLH2MJRa6chbgX1S1Vw/OtUe1 X51PENkGvD4307ze7mAcLPCltsHV6cIn4jxiHMOGLZy2YcDx7Cbg4wMlG7Uz6jEKqyBkmMnecgmT PNy8EKyDqkY6WsJmj+GzAFHCU4/9P4g3iswG9sR268ODFGzuwnV462/8EOqqkBvxVhn7zgpcCwYT bPCExEOTN7VyQWXe6p6ovfQR2FhmRi2Mlp16PYeXCc6C/4BmfgFG5RTR7synnY5LwWBoYJ3upNNv tynWc99pb9qb9Gzfo/XQkINforgoP+a9U84Qu8iCTnRQFL0ThTMp0f2P9kw8htrP5pF4bOJyYBue iNxhEGceA8gnCDFoO/JeZsOTcurY8XvmdmYVG7pAahY7znchzhQccgHrfPUAoQUbPY4RAAWxI85y excqv1PuieZCHjtC2+5LiaigYFG5q8mchnewqhTHqDN1fZ/SiSeoNCj4y5dgYZG/DaMEHBGelnlw uwNAm0XmXM54Oq3xpNeZukXGUxq0qeYxg07PHWfhHFFJ9csELwK5DGW/Q0DDF+MOBxEwXqRdbkq/ /jFdteLRNwGk0D//8T9XV++hjKhgw43sK36ZfE7++Y///ck6BHMawN6aJD18yqXBtDlDmMo4+qhg s030glP9yoy85NtJfzUnAozhyCuHtNvvNiZtyMMCiy+FdKPTbvTziJPBzYu/CKT1I9mNAuUozlDA ie/Ce3iWg4Ra4zZEMgCtS9AnxOcmCW4eiDBU3R8cCnxbP3eS+1D5demwFXcPP0seXhteOwbYPir9 lApxTGRUCifyHbTummqif4OodZYPGwRaFt4KOgcpWWMyNWd+QDUZzMCHFqQXROVG7AfNMzgadF+4 ptO5jTnv4VO+/LiBHw76FRSEdGr6rGM6QjMfJIbFnMYKOLPWLfT+xLe9RmRg6SVeISjhXadcSQEN g+nVyQZkVF+0CoQfuRVxc750RosFAuLi9OfcOBah4LIzWgZQBTe3O3pur/3knvEYHsgyuBHVP5EZ o3D1KnN3c/ni/I1fF+ijAiens05j2kZiiql2dN1GezaeDgpqRxHz3tXGyVKvyLfY2BUMJrDo7Z1i A7B3VAA0WH1agaYktKtZBH57S4KWZ4hBq0Cv/oI702Hhei4KnEwBNCXSn6Ij599CVRVi9EIjYAb3 C5wpNMDIv0UAMwHJEBGgXiLKJL6D/CA11Qi2EDf+WFhV+YH1pi23OWlZbgV31ut0Gh16VXM98fcD KwtoOxcE9fGnpYi3xgk13P5ovKfJtxtTdzCZFW3bU09IYkXJ8Bva/sIJN2TgGXfHI+hPynRJwNdN Zp9iqzA6ExAq/oIPU/ZHtAWjAh/fhhthVzo+Wkur6Hf6rV4tb+spQJBYYTH5pDPpjQeTBpUQw4Bq zSduq9vJHYQU/+6oPe21M1qpzck02IspEWDfyHPzNsHP4P+QRzfhagWJC+v9vY7gt0j94jokM/Aj ZBiEq/BWhdMhMRb+Fn4gFaoraruLHcAPS1OpPxwS7rVcAU/CrRroehesIGg2lAalobUA2XcLTCKp Gh5MG/6Dnh+yoAJOg3+YPKTXcWeDtmhKyRAoto82L7J9tu2BDrHNxQoKfnATACRFtaNo6hVF5f7W X0MtiO8uxeMBz0Dk+5fX9jIq9yNuEu7o7uE6CpYvmX4B/0J6bq490KH9aH1Hg7jMqZYv9MCOXz9q 1OzZpUrl+2GRhDHztqxFg5pLIu61RNuLU9dydfUt1J0vYCH/7SV7mTsmNkwn3WZP+aeSYVgMX5Yo BQL6HHRVI5UrCidAs2qCIWwiSVU6EsRV4z3/gj9EtDqi38x6/+u/TsDg48BreQUP8d1vg4/+PTwj OWvqWJBUkqn8HCHQte8fqOu8l6iL8x0jMgsPiXYQWf5nb72lz5cCgRxUGGOBLdvzmXs1ZUTFEkym /hK2KTJzYISljLZrj16L0X7v35/KoCZhuMoMXWvyMximBUslVZC8qKV0AaBmimEdharRmDYa85kV MSl1HjQnbnOcmwKGelP8RZwH+hEhnhpRBVdIRW5tev7KlWYMkgw/ZBoOhTvFa6rjFCBdbt40XETT 4UsqanGd6QQpuPI0N29miC00S7dZ/KXCR/IOScNQaKC+SRgtUq6Ad/NJYZUWWY5nzWlXq0MVqF71 uYKUXpqS2QwG268fQn373fQQqNOaKxv+WPPNIzOEh/Wgky5rb8fHTlcGn3Rwe8/lp/GTzSEOMUqk m2aouvdd1bzDeIfwqlfM0QDWHDrHxd1u8/GFs8rdW/DxvFCB4ctwc7lEeQ/I5qu//jD9+oV4jR5X Hmxft8Iwbe1Z6LDH4kq8HUMko9570Tr1nd0HqxU8F5AVCFvHWDn4d5nJkgae6/C09qzbGXUGlvOp 05mMOu6oldlnPOoiSZvOp+IvFcReiCzBbUjKX3gbRfrKBQhGEGuDjYhA61eZcnTUpRyszq4ag1m3 32vQe2sYoo3uYNDrGfyKu6o2fWvtavLN6PvvZ99ap1uw3/QMB7Bxz+I4hLojR8+JkChyhMnfD1KK Of3ww1+dxZ0HA3WlPPwqM6FIBYQ08yIkxSHyNvE6SHRQw6s2m+ocS3cwcxv9AX2axrG4YOiD2Zxi NZcspx7LHl3ZttreCzbVpquoYp0MQK0ktU/7Qh/g6g7vi/GJZLif2liGFE802YTczMLBvY0WTae9 n4sMKF1YCYmcCZjXzhi5SQtnt0E8RNy0ZkaSijCAESCVByEOpBRAKYDvJgQnUBxhu4sQQgHaQ1WO E5RG3UIpZ+XicsdU8xd5jrHUbpKL+5+J9MjnMVKd6+Bra4os2ZkE1Qx87TYhFDuTPPpfAiND4TvM RvaO4d8CX4+37Pbg9Auha7lOk4foXjujPC9Io7M4H1W2GOVaGkXzVlJVhdAbpN/qkgkyZnZaynWl 6FVpwvAmIjVfalPgXAZHJjJnga5C1po4zpC1dpuHNiA9t8z1l8QaSAmpGklXo3P9KWJBYtmvmUWW JsPdMbwXUuuI1zAY61BNdzCd98YNutkNqml1poPmoFXX+f471eyLlCvECn4zTJ6WNiO/iibMYLNw 9kWwlcAcqMFWKnQgmvVPIVPpDBLK0TOlFhZDeasYQVxmfDKFhTSy25ZXf/CtEDiPOA3FCxeBhMw6 SI18hcl8NrJSNNzpfNJuWKnEp6ouSukbXs1m75yrdz98+GHyw/PolcUpMjWSvGBh4VeZzqLMGuiI iHkrjpSWeWURPXXoefjVDL0eKYO7YxeGyNyuGZhMkbvafxpukgL+L98+F7wxcgHMBz3ipsJeLn6U Uo7YDQVEIbU7JYtDx9ibNHqt7oW2Thknh7oVQBsLQJHLQ18+vjLn+kFLGJpsteO1vVajM271rdIJ tzfrd5qzuikQh0VGdsjvvzlvi0cZa1d/ef9N4eQPzV08mBpvpkq60sgLnz+OIqJ64+TJZ7PTP/H8 2nN3MHVHlsuw6aKKbjwi6f5u2NFPSpLTDriaVuR7+n8sTNhThb8Yw27k3LIjB3mSkD4S31ARAUZA 0RJ70Hf3BTjYj+fcwpmFrCpoxHVkcWeA1MH+jAaYoWB2W6NxY/S7gpk56o7Htg8qG+o3g29FHVOn FWaaHV1j1eolNEEQEgsYgH/LAEYatEeULqDlBuo1yQfThGsisFlacA0NEpqpIDXRHN8oy0w/E9cy Inoea37kd+qltbRMZKZO3F7HUna67S4KE6yanDO1zA/vRpM/P7uiac9SEIW/rK4pmqr2xdc6i2Zn MptORhaX6XTHzf54zty/XKY1xy4qqrNHvzt/DnpG/8riu98IjzFDQbWWbBZOmyhikeuZPtS/htNa qylPlHnatXxdwwWmioiEBO+9BHyxUIBJZqribXWkf3s8d/uzOWNThvRvzN2OO7ViO4Nu2x3l5oNB l0WKlYiVfplS85goPN9HHl3yzkc1ICLYV/BHj+Hg+yj5kclwopPsVCcjqkaUWu+zNkeG+zCmZxye P4DjB+SS0nf3QScuFE67PGzfbE8n427H0sHb7mTSGMzzGD2d1c2GO8lLRcxIng5ha8wVuBhRbQ2X OqU6eUJ4lJKBwnljuDrjVDbFmko9IGUzwFUADxhzOiU3q82i9NGerXTWKqjYZsklONvquixriXtK fFUY6gm3MBSl3FpIBqtTj2f4whqxdGv7nOjU+cpdIiXFNWbhhnI68bTygDLLUSNv5WRFNSTM3EAx 86XqlHE03JnbhyJQ5EvNTnveHbeL9FeksqPpb1vIDjqnjKNdrOIAsXnXMTka/gTBSKnHyr9JsKfX CLq9uRg0u6pSpOqFZr8tPQCrh2j13P7hMdrdrpSXVI/hdvq6KqVqHR138MhKu27zkZX22rAmFRuv AEe/5T6yUgDskZU2waIeWWqzMRg8stZmc4CIy8HFNltY7iOvtHvuY8t1u7BPMBE4fIot7FhITnz/ 2rtJfPZhJMIgGovuYi0MqP/xbscmlt4uCfX3qZy186OreOEey0iGzOh+Iv6TDFXWZVZVh2BCXlYg lqQdflFOxXKOhDhEuC6UuaXCwVpvBPBIU86S7aElIRqxIlGJUY39sl2oTczdgN0aHJX9hL6OK7VZ xg3p/o0rZWjJqshHoeLEkLz3d1I9GMO1o3uJsMLPs7coPKUcTgzemOl/CDhesM7vchnRK3RRnaRb srLpTuoqsUA0Xdjp8undMccG/WuDploRkgqsagF7TweOrVSK2N8LTIZ751Y9bDn8HAJccABOhmBV Okv5lwFDylJbyQIjOEAYHhOPhT3IsWuCCyRCYA84e7tDhSHSifYqxbU/nn7Qc2dzNJUAjXQLl12C Jtc/S0dJe/ADmPjS+UF5dVSIEH1ygQT299WgGJIsFmycCjCmzqNMI0y1RHu8A+uRXhqrAOlXOJVI OnGy9AicyB7k0KKQCiy5MmAVHsr6eSg5+TtSUUsuYg95YF2CbCwcZqVVpFvlxCi+OmZd1zuWz0py gYrbKrdZnfpLtznq9wYDK8HAnffHna7oX4Zn5jxL53dN63dNC82tCyrwv6umxbIUi0mcaulV9Lk+ pH6BpVqTH9K9yCvh1pdKGqnIy9iwPcgBzplJlRBZtss0fyoX7SJr7PEOsE0Ikwotzh7kwKIMhQ9s HGWX9rcHFiA1RceoU+VqwxViGqyoR+TuiMlxJIhlolkUWzhQZaEAAVgRrqEaYo90AAS6n4QIsnwp OsvOHucAOOgyMBayuAtWS6xF9at46VCVtEc7sCogqNI6gSC7BRXIXJEUPBToO1f2kAcWWOmOOGJd 5UdYqZWVUnSZT7tE95a4WKrmKAUIHfGosQBTRGdAmrRSkHB2R8DBuQ1DdhmTZMZcEbJGKF167nY6 AGcUdZ+t+Klu3MylyFVx0a9TlRrqjbXgQwwskh5rgBvbqV1r/V5aH9mDHEDJLPjpbz4FUbhhPnQd /QrdMQeTZtPyZLUb7U6jKd3RKvWrAlakKzPc7kXHV4V7+RmVrjq+3txzXYpRtYihzjxwnwxVeaJ1 pKXT5oicgrUAa2J3zUnLOcJrcC84ARCl8G8ZB0eTg9UOfXuQXLnaYzdnz0ZLid5W08daLlHO3e0Q JUakStBQ1u4AshyFRujHAO8MbHwL/EKWZ8FS90KA88is5aW8sqc6e3dbmLwUn6hvYGsbXBuBZkUL sfeEHRsujFKfTM19DrF2Q4hpLEFtaZ2AnTtvt+c9ODALAbvyslnVyDkFi8E5euA9Uw4hvKcW56go mxVBMPwua1lRHY+rOi2GZKzQoiJGI4SYWI6diphdbzRFQVq7CJrOuD8buIM8oYATTmdNZDelAHin JmygTHfOiJ/iyCa8VJKnCS8jP/ApAnnGcHWx6O3G9qnl2rTBCtLkMX91c5k6YCWTxz6Qs/nQIwR5 whbh7Kpy+8Krvb1TPdOM5KA0NTpWnjh0HqbDB8pjvLtmYhGDimCXyFgXXfcrCwZ7wsKuH4pS5FAY c8KWNj58dNdhZDPK8qmrBNUJE38t9pL/mfcABQmYdeT/fefHaJujU6ygwG/QgTd2vjI8WuC6hvs4 85B/DS1PXN3JgwXCYxg+Qqg4EXuAc0FcLpKzOszM5tPKILr2hAtJ1lY4I3ohgwt3qKp9IQm9Ujhx 7S/Qx1j3vKOrDgEEyPccjFAQ0QUPuAUlNWsOqmELnHsQ6KpWvFJjkQ6I71QXo7z0CQV7gp9VoCEL aw1avWnj4myqzcr5ZKlpw2S51rCQqFe1llMpofyYAAxxN4BQqyY8bfND5SK9XHtbYHjV2KduZsh+ 55Hwl2vQkUwisQDP4b8vmhdkuXnzMelxjj1q9BCfLSszafU6qxDWPC4mokuXhJaaUxuEhcSLzpek 9y8ugEE4ADkyZGxUOe19nY0dladwKqTKj/0jun9zD4bcisG7Vc6pLmuVWErWYxyFfbirjfVObM2P Xi/yM3CncsWn4U35eiM/iQL0MkeYdj+O+JhT6ATmrRvj4eDBgUwgffkHPixG1GwzPtoYGI79IQFY cDwN76IGJ28AB0eXpPo/pP1WRabRIkFIJ4a2Tu39K9V3XgU8mXqclvGY97GhDQVNCDHT1t5HIFr6 FhNd0NwJQS9gl887aLHkxTlirhyFEFCFvbEMFoj7r+yW6lBBn0cMvgV/hWnzwmy4ynJ31Woedp3G bKhMn3C5Rd6WNfXfotDwDv1nDeA97FHcEVxnqAxH0K2Nyc+z/7x9r5TzXqNboPP3Ha5Vw2WASx9K JbQdHjw0z1tSt5QF09NGNo5b9YAoEO+43PgWyU2oerRXfczW97zN5255iGoRcezFdhbZMVpZBbpi 2zeiMoLEWAktoMMT/2cYrnsocO5WyhfBrupkDKqHjL5pBQvL4sPqohEjGqpvb2HhrDQCvTbuY4xx 1PHNA49Z6T6ZRqzd37iNYg+5y/X0aj/WCcz+VzMR6vgfeu15c96UC4qMhOFS/4NlZBv2dPEX8T9o 45v0kyYyFRLztP9BUq4OOBUfMdj0xJwlGZ7UYbLc9eB2W+hs0bJa5LhjND3vDfK254YKUiQQrcyn Dw1QFX8RUBma/0muh2NR2Jivrm/iJNDuCb3jJy5nG47dPuxfGALDn5h+proAbFe7W9xfBd6H2Ad7 T1yz3Tr7ZUhvXzA3cMUzJFgFtO0RU6xWJsPxhzrkdTebh7UzRVNi9I3HtQhbb6O6Datd4Qm4u75g mTaAUgGlnRd2Ofn+e3tNR8jpX2qXP2KZP1G7uI5w2eaTL1h6YyK/keIudxRqrXdPgD9OIUdA8DRO C3ZwxBwVp3Tnr2Dvq7ulbJCei5cVU+IYpfCRpZC4r+kj7do1e2mADGmvrtF4jiomYiboWeqpW5zk ZmKVCEBlnCZN2q6DmgvDO6UGCgL+ckeb4VcCBsXsng4fQoBozSdoObiqIXN7Jf7iTtp107rWvf6g 0MZsG4mMR2WfseB9C4cGFP2lh7uoeHW2VoCNR7QFcKEWKo11eqCYBdkXwKHPdL9Ss1aJtXUUDHc+ 7jY7c0uUNucTZKRJ2COPlw7cVqe8UlAzGX3CttS0bKvjOVL5yevrXlrY7hZmHbM6gAMRUiEAc+Yw KC/NXiLE47R2LqaeTIDnTlwOKJ3dXAsbmt1Ro9WE/8ysT3Obg3GvP7XqQNqtySRvj6Ckzbj40FCs ir9U6KB19J1cGz2GX+21NN3Dgqq8fSqRzU6vicKPI/jjUF01ZPHA0kn3gw6nTVlx+C1rDUdBrXhF UrkyjotDenO3Z+FMr9NsjHtWd6Ein9BxQOuhgTPFX2y2cpIyfi4vOlQtOYLkQzQbUgeOnZi6X3ZZ IBmUpOWDR4Ex0Ue3Qc6ValkA/RG+McibmCGiDYNF+Y95WyLomXDN+XHsRQ9FWjY0eaLObNydN54g VIGQE3PCVT9N9hZgIA+uiFTAC8NFHyXFaNVelKeK8gySSLFkG/9SJmcsNX10sspqtjiArFfhHOXI XkEBXz44vDYKXjbKCPZTRBPRGus6guArqK/GJE+w+SyIk90zdV9ZmGCA/YjtDYHNuRpLKFLFSLGj iI7lbMJFBtZ8ZN8UhXbYzcHI7UDg5IpGke5/i2wC9xlTwbtF0qgiAgmXgP3LzVovjBB66kujEalj WjbOHHFMR2LhyfQ2WiLbFDrsOAw/qjguUcKkwoxV0cQiE4EbvJAMcH+Hq4rBB6WmnlYSR5A+O5o+ 6yBVq9OejGddZpEY7jFc2NOf9rp58Txx/l8AqcpP952gGSH45IjDI7EHTQn1ZNxRVTtm2AeMhal7 Tx/0wZV4KsZrbWJPD9vzYx5Bcydr+0fMUX7yYBgrFTjDQVlbPFfRqShzQM5FgEgNjF0lDej9ipHj wjZsIHQvvXX8zzS+pOsqlAaoNegZyyIrnUKvvkVcSzpgpt987/zhNvmjI5+iwTJ0IZVwr98WbgEu grGgIVFdkmR1H1kjOGVlWoOb0MsG/xudAZhahRZIHHRhydBE6u/TxAsoL4KP6Rx05un7LaX/LF+2 towA6hw+rwDzM0EcszMZwHhNJKMaUDkH3UbDJqPHMfBsOvsIF4KFFOWz7hsgJ9P2K7TAh6flFgjy gkqJNf8xtkcFytsjng2mP79xRWn9/k2z9cJpttjbuxT1ChhHjV2jGNHNXtX5pG2PePY+0xwpWhsP jps6R7DhRwmACG2v5/wdKgrZc4WezbiGCLpLogF4galp8WZYKmU6DQ/8qbDxxG7r9CUiq2SuZbea i5mjkgPoLVQX3solveiH+sl/tYFmIM5EmGP3rHtS99CTG8JIMvMziA3Sd/jJjxmGrccOC3BLgitr 6EMOyNqf5/DheheT1N4+IKWEAtXRYINsTFjp6mbKDCt2+AWO3MS5gRM7hsCQdULFhROZOmqYtmcm x8dFjHAqr1P5ZWMU0ztpcvK63adPFdsXT4bceQbASv4pRC/upgQcb1b+Z7kImjma2Pg1GOJ9sISD GqcMoKoO8hCVIEaVAYO8sYXKC7DkqaVCpEqDSZzZyYloz5LS7jyYoLhHBPe7p8eSIRugDq1S3BBF 6Qy7A0Jfi2c6a7LXMuUF+ylbhVIsbujX4P+VKmJPXMdq6Y6m/V7TvkqkPe8PRn2rU+K/rNUCvMjS d+EqCsCpFHaoq0aJU6LAMVSCizlBbZ62Oa9pc1JPY/MNiTkS5bKGlSQ3lJIAM/gRXtG1msgZ2SwR nWTLofRSIovblatH1ckm+nCOEIUn2wrniv8KbUpxN9IwwIbtw3FpJuxTy8EjXB9LaALMAKkqFlRO NRIZsvmkQJlqMG5jSPWK7OpZMAOKnpUPYkVtT+Tc+iAesOBbZMP7yzr00hgNWogfsIDEsPKbLZSJ jJvFSpPWrN1qsyRFeZOUIjvAtyP2596rNCmS19NEJdJpTlWiy49K33kotk5GODoYiGhhxn6N7iF7 /T/+/fB7JZFZYFomx6EZMiqc5lcCg0WKswEIryaLaNoa0IyZ7U0ywIu6EaRIfnZKQU50IMYif7dY SabFirt11hvN1a1/dSJcSJYqx4GLBbghqOYCbG0XUZqGivGpcPYzCP23MKTJZhd3oVxbxL1fYwVI AUQnTDGrP3nBSqCwwIUZqN4jMKibgOgz1TQGD8YZpDFtyEx5jSYJxCjy9OV6cHIT8vlsxLe89B4n 9UvAtvIATyXjIVicTqWuw+OajdaoMR27RR5XmujXbTRbaGWX8hkjYFb8RdiZ2++486mELnXArFii /DSJfnpiSsIEtwt/u28wlvOe2WaZtlPjt8Ub2d0pkvnGM8u5685brX5XEhbyiMGk1WtKaMFk+9ZD A07FXwRO+pGs4qq26ZcHo8v3V607GPPV5AknwNUIDCo0Pn7Wck50dorf8Qv5krb/E/yM6B8VROCE S4iYVbiFoQfBYnGqXwApvtl5P99Bmao1sya350OLv2xA+SgNgbUPBf691HIo+fkhzYNieb7TajTc TDpAlzcUR9+LWIkEwQNBIpeOpZmGxRancXiToCmLtBSbQBR5MDY/hHIbAz51UNXina0A/bax1Ln3 r3EU0u6QVww6nUaaDSdF9p8C/IrSWDpqRfICizeU6QvkKDAFlGc49oO/8RlOrO/8sHpYI5VBC3YK azg4cA04S37T39LwOhwBzG/gT61W05rYhxMBaID+kFik/7FWKX7LbTYmE9e2AhrueDr/4sRBpv89 Ld+dyVUjd+LxqEXx/7ICiAwYDY9wL4vo5ldXuB1WGEuzAeteZSbQxwcPgTjugKvhil2NkLr87w25 5A733NwCh2jOg/cec+NyY9Jw3YFcH2pY4rg/aTKedkmZuUo26HYaYrLvGd2aq+qXf9e+dK9qf3P5 p7HWhrVKWGEH6oRO4Lvuc0NOnPcGl1plZu1DquKGwDr9v5vT6aTXajHD0zjXbnfaGA9avEUkP9fi 6Zn9v4u/VJxr0fo4p/93s6OBtdmtn0Rjr8oAPZWFD+WiiMeYDWd9dr1MubvJCFUeHz2qcOepbD5i T5rGpx0LEPzFWy6ojC2gH+hOH4ygsPgXNj8HDeIY0ZQ67bk68MW1u1OilIFojVZj1OmPizciFtFJ Z4FZD4+16f6dsI++3V8W+YZQ6cVbpLojyg2qUC0X0OethdQ2sCt9YRs48QWHIcGswR+3uo7x2B/v zQCzPGKCCgMb1EUrytpalHLiU3lS+WxpbgBpuUj3ksGsQgL2Us7eowo+kLOoK2/z2e2pzt01fXHC r+BiNOIbhWnKs1ZbA7c969iXe7Y7vUmv12GTwVwwznBhpNzsox4VTih973d+JddylKk6w/K07D1i /mXkpWS7p1JSXbWnEnn30sbPJgPEI2lo525vDYg9vvZMxP+V5A3AfAKrLlAE/LH25RZ7eZIpYhew /QiQDE+/DezUKctZICOSZBFfM6ji/QqAOEnOpOBnlGmA5PrmUUVKFZAoURyeCfWgLyAHJ2Qy0j62 H4NFVGG5bCnzUISqrvSwEDrbh4TlDjDsYyavo/e2kaiOZolWLKM9hoXF0GDhHIuGs0JzS7gYcqT4 i1hd+hH3UBrzOcfq6j2z0VUf8IdKseh5/His+lt/6kq7vFRsnMBNjljKaXGRIyY4wCXy0o+VlmKo okadlY62i35+sMaDdE/apf+ff7JKi2qg0DI0e2kwiWAAnHzBplYYtek2WjM06ivYl812azTojYqd QYoVqdq+tB4adFb8RehMPyIsNZ3VCeXlMcOMGykaN4arM06laaQLo9u2EDvfKkEW5A6uBNWXCccl zRuZY7FCiqNHzYyajMVzj1UijgfDaSSQ8tynBb72zVkwOAb0wzp43nAb7XHfDoZ0R3O3ZeM5LpPr N/IsqcMorb22p6P0EYzl+JrsYwY/pQD7iPEruGLbPvgUy6hwNNq9SX90cf4sNSdJhmK+3wRIeP3n P/7n6uo97ojcoY73AbHrWyT1xS+Tz8k///G/9nhHrHBYp0S8N++0et0xqzwNrx+6Coz6Tes6aq3F pmBTxGk9NFC4+ItwZUMPfgqubAx3FlceFQtCtYaSlXcXVOETNIZSgB1zjmfZH4VjOmLWCioqVeVV aplKwlNagzaUabFJFSmSI5mVJ71C4anOqu9TWOsadrapVjY35+FQcIUfVFPqcOQe7lyfzLtWCKXT nrbGrU6efGpYaqVHlj78wnH8kfpmnAPtaUQVkPUHj5tS6FAGsWA/QekldQbPqcAa1VWw0FAUugc7 JjyWGflUNM6GiSiH9BcB+piyTFF1TmT9h944dFqUhUsra2l36DlpL95bJLoH28tVgHzqNZJl2Hxr /dIZ8VLSFKmpGlNNTvEX6RVMdFdonBVSo5BcLyHLxVCkoFs0pCGgf3cu8+QYKGzLHjUl6KdlkaqY jTF8oDgyciUVOGZvW7ZsM/CCdJh29FUZV1JDBjU9uUNKr8YdNmcH45SLLxnBAZLhDlKm55aiGhgu O30JLm78+yJ1q+5bCieZ4wN8hVGXBEis3qJ/HHrvOhP2wCVV5K1/NaWysIPxa1T4qjun4BtS/UXx eIsUbRIGUrLppFuClSQBaxcwhQ32s4WQXR63QIUJzFDVQvyXYihvcekEecrST5BmfXY+2/F87ilM q+NnrWDwWcofI4qIPvN2hVDazCCPzGzjLuQgB6bPizcE7eHIsYbp8fv4oqAHD7/PLsvI4H9yYpHm +SpjEwmBKLOUAgBNuU9PLMMPOE1Jc9E3OV/7yABFIhgeL8MdC/g10wCHURfakbEI01CNS9Sb95sV ej9Ko2nnkxfhWgp0CkSKwx263WQx0ScHFoS44iJKQ7XGfxwrj2BtpyHgERNUUKour3n6ky+fD2xS FZlmnaQ1gKnVqzRthQ9g4Iw3E2tifw08oV8RaPE7dzC4gxDzH83QDMGDLKtraKJQHKBRoM0DCs3Y AEp1s4ecPxqNz1WMTsPtc2ctR0DHBp+URLJPLqxWqGgoBEdBObANyZe4vAuZqKqmFdmrNrfMGE92 U1Bmx/4OYi2/NIYCpMrIEoZNJC2DJ9xfsEJRcqbpnLX+AW84Fce1Ogddy61yXyi8rnlTAfTpKKmV m96YD1xUqdLMNxxc3RkCfK1xMezQn3bRcBUvmmkinT6SL/OHhvFf/OU5HFx6hiOY/vB9VssPaSUt zZRzxlvh/sUguZMwABxKb/86E8cK3triAheAc6/HUwqHx/wixyzvhdSNWNRyjAu+gsjtEZ9j7eCv Hzc0vJTKry9dkE7iT9+kWurkl0oNWUMmwiXMe1aB+LslL0i0mXoWsHrK03pf8JfAc4TWmWvllauT uozc0e582rDajzbarttpz/MqSa643+41eqWRkOIvQmX6EfHuyYPoaLD7akhs0qnLeUhwT/uzk5K5 nmSohLGFj6Xf5qnF8mUFZgPrlMEusub+LljAiWCf/t74e9lAanEneZIPrU4SSVN9fD9RxCTDGbyw KAY6MFqa7WQBT9hDgiQ0uZ1HwACLYbHXFKhqsuGmfEDIEBCUUjpxgR10Jrg20ERF+WIos3Dr9CUy j/QBiNuU9yEpHwesnL8hL2sLQUTVi++ngGDjEt6XpCIHd+QZUMN+RJXcWxTDfDcbFSMzkDfm2gfd Lqo2FKCGdTJYWuPmdDIRT7Yh4lqgvGZ/TOrLMyFBd5N2nsx9WJq5fbfXm8tCfk06+6VwmR1nQEjU NNDtEu4rGi68tBhXapU0TDPBakCqIgFlLTeWs5wvrZlMsZ0IaCHo4+RcNfkZSXtkw4/vA2aFtOgt kUAHKHuOfeOWL30vRbpza9cFInh8JelC6Mjn+SgI011qj6t4n1wFQBJXt1uhOyB0U5qbUmQpq7M/ rIJyOatG6OCMNE0b/L/cSYJ1gZ8C52B0ryuAF8FcB+jucOOev2GRKRstOTCXNGuzIHf3gDNButFH J3odLN9cRG+XwnRABHdhhH/7N5eT79+/I29KwnCVBNs3F3/4+y5M/vidoey8h7IjdxsqueWM4aNe IiMJXmpBQudKYRTS8dXHHA+bIdW+wVWTPPgMq5SX31CpkyGXUFg5pH22dPlYoc5PcIyPdvDKIyQJ Vm9fopN9ku9WGtz+5nZ7HL7/pEpKCgAEvAVk5RSyZO2yylIC0qmmRc59GH0UX9++pyI7O5s4yoeX knRrOb8FVkoH6L2/WpXTXvler70VJQqcFSYXSzlryhv3RjzuhKnTZMdTiAlZUFaHPsQ+dpt8ZZRs iHiu4QnIfVT2l8etSKtiqZiWE1euAXtcRblsVVcnRaDdbLvzftfyEpT2eKlWoSaNZreX5ROIqTIZ tQe4h52LKVWhTu3xonb33yjkD209uBzjD7ZzQfZTvzGRO2UMBbI3mI4HjU7RR6LlcnpqhgJZ/EV2 bwjx8lWZNfCnbukwy9lj1s+/EHXxGFtiCDmC3/keOlmhwPMB6bJrxflYJL/ydpCH4uh23uOS5J8h M0kzYIStRqPLPxfIul1AIWWDRrlGmSQ5+8t85Mx28Nz4UFnnYZiA5lYUimgBAQZ7F6gmTvj+BiHg B/TtAIPBhGn/ZN3/AfxbCKiZNZ+A+/0W4hNqkW4TyTWkdyhlMy7CHRJI6IUoEB1NZUF08bTBLvLe QvR3x2672ZAKdBO3NGlRYKMpyfKdweHTR7Vx65DI0Rm3LrS+/CoiIznWvpWosCNs6NEym2dCW4Ur L+WiDx1Ou8GxEA9oRBANzJ7+WCfZoOBOoXUAZcuPb7+bNAZQYgqbKz8uF5Xl4wmKVQru0kZ32u9O xsVqiBFek65Y6gSN4+q3Om7uM7VZgRYWP2ZHIyb946mQRaO5fPntgTtotCYs/zOwrdsYd5qTSfHW gSK/Mqvli7+ULv9AhUO5vB7zKju5eU6nuuFcSN93XoScCSiVaI+KJA+wCTRG3qjibflb9IBrxcA8 yBjSnrg8fYQ1tJRPveeF0/0VUTeLMI5Sqf89N7gKb5l5hTTX60vFEwEBNj5mR1Dt6eTGrB60yhuD PsUf2ZxSO1rkMgrVaxFA5FfmqAwt3qKTBjs/JSGaWvIy7SyYGIeXuu9o7N/SpwpTdoYMEkBX/inh aIaZ2TVPXf7sOe/QMPjyvbfi/YuOH0UgQbnDHllejBnjTeGUO3HO5Z3u0ahHB+c+On9YoYO+QCIL haa7SveQL0C3zkVcBC+LzoxYuWxUN8lVr9ZhwO1WvzXote3sx8lsWrgz7nwGPKSJBHiy65Bc66fu JcIZ84Ak1muhaEG/n3faDNMIPy2nIbhOcIpCLMhghHNGWOEjvd4r/DF75WgvnbdwBuY7QHjQWu2v JgvQBBYCXLRpJCLeIg0CAF0rfYAZs2jSC0RdBTc+LiCEczIgrYjo2IB6pN8zUFQgps7inY/Orz9/ Cndssy2XRwl3Ud5+ZqwV+QuILq32YdtogImJaAidgh+BJvm2mpMZlAtfyBntfPncAGiOEi+dq1Rc ZVagHo0UK8snFaIgOdDRWEg+a8UqJ44x3DQP7ks5LuWul51JG2xv/56rvNl6ysPldOV+BoAgfZie 5DeU+y8AXBsI+11CdEI1slPJLgBERTM8iyVCq6AZOUqmIYKTXfsJmnylDm4VVBVEg3MH3xbyYTmE pFGCDiSwWIf5NEfN0RQmUFEed6at/rwvgaHn1f4ggaAAfymIQTouEqJCFYXKOHdNNPvnDAGRdRam NZAEN8jUBvEKN0yvSacoUiNKSjP/yUO72cE40K+aYlJLnVyRYJs+7QpkaraSzriAFSvDu18KFP8G jQmoC3PmimXFU1zkGxOXv8MdssGWze+x76+upt99DRbILrw6DVXDLZVOYGp7cNN3UmheiW2n+E7d GqxG599mHIcJjvSAqrCwgF66QO/fePOloSGWyf3zFoS91NWCVG7OGj0jMKucqPqhMn0YNtEQE2pT GIjEZ4EZERAlpFR2lwT9ASy3EOyQVQdhTbt0BX7G01ZRUTUxVCYfjExlW2NdaYa1iEuKQzlTb4kG 3Up0LZAWAR0UGETlMtyGqaIqLZ2xdOiHH7AL8ydmtAoDxSd6RLDLpc4k+oKIBVTyFZajmAcWCzGr zciv5aYE8ANyBqWkskgHWL5Lwg30XCoHymGhVViKKL6gzH/e87SEUOJT6+T2FKXySLmSMXhZWa48 OKrhcj6H1Ic6s2l3V+obqle42R+0J/2BZfp2Jt3RaG50jzlHUd6DTEVs83jHXrrTKs2ZrDIV3PyL wdFwEXda1EJTcs1rA8A++ZaIgewaa3FAQeuDngjlAtez4+zVzSI3K5gnOyEJUMtcuu+SNFZIjNf0 QRYhRUfkCN5yjcZkmubIG01CzaoL5M2s5Tg6ETGglE1KqgTR4T/Qe4Cu52Atj6FGBbiDWt9ZOFUO 6a95y8o1vGgbqZYXkOVonRrwAO01U+JwYyw74AOW3Os4g+dM7YgAUgq6orMg+Jq8DjnU8AGhw650 eDNFOgYymijldRocnTe9IVB2Gd5ccsyAniQIAEmnK6rtWfEJtMiDnwH2NAHycj49DvxTakfcLxBP LnDPMgH1QlJbPps73wgP9Rqtm++BPLcwJ2ji6+RM6CjvQwov77GVpeMSA2ud7y/gjBbehl78KplL yR+NvZoY8l5DNr5rFGCmCcCzhPc3BZLQCRg2TiK/2Cjebbe4t17LuF0EpVIq/1J5KIRJF3KUuihA sCYZYhKRgEuA/AflZFG4RcGu9Iew7hloQ12fJY1UsUJg4H1xpwN/+ymnU7wswWSpUlUZw0hneoCm C91U+8PkiiDndSs8/nvoSMD5ryxsLehjrbbbHeXtXJU+ph8qfey8uXWNhkBBLuuKoO1uEEHAiQEw fFS4qgxUDfRTDumUDwv51tiEWq/QOfxp3jUKUPcJ3h5HffR1HeOzNefl513r4oZub9aGRcqnufFZ DN0d6QyucDGNIJxAclCPwevl0nExIKCOpZ5vyXCGsxI2SwyJilKpBRzLuEeEvNHaOERGeDOLiAwJ siveXFTIsidXHZjiF7+Ga2IN40rZlww6U0igtsf7FODsrLUWMHY0cRtp3t8QVYbQCoBHyOuQzNnM 76PYm90W85AR4CP8Bc0dN7Jjgboh3KGFTNwmbrQ+5GCULUqaLVmqOJmFYwP24vGQwgsDDspVAlt0 uUQVJSiYnmcGly4zLUUBrExLVlsb8hNvr+yrgJvGuoc4AvAQLf4x7IPh+VZWUe6DjgoQUpoEt5Av bq1s5sCP6tCTOx/NZn2kJhaCK6VB8mp6Kv4iwZXerNvpPEOQPAWiYpJ6YsU/0HBDwrIWvpQTmVb8 yiNOjZHbnYykQa4RcerMXPCZSTHJ2bKljYBZ8RcBimFjl69qX105ZVOP2A12qtOvt5SfKFU8R6Rp rVPbh4/OP7Q73pbvqZa27zxy8UXKIJCbiDw2EZRZ8Jw8fuaB74/ioF6OSr/Zd6fSKsvAtNZ81B/P JiTKXJz1wevmebizNqYJTzo6tvmBzFK5Cp4onP4MmAzsOaCJnYhRT51P/9L5f4w8nmywPAPcRACy +ZuyJNQ501OE6EDazoXSMo3C6NiF0eMljWbIG8qchUmhumfkPjyOkb4JCae7xnxxkMg3ndX+CYSM zYktn3qbGbkDofMdArC0nY34MeG90NvXhh6K6FM/JhRC0zLLhkFAAYFzw9tC3SBrxKDqai/RnAE+ GTpMC/0KviTISmkH+XsGtSwW8hhhlrsWGRdDIHH9KKvn5/U4fXhzQ0+pcjVjqZKkkXuzjSwvdQGg 8pZyU/BrLBGkgKudVi8uK0QChCpmeUlfhnFM+N1WpcuF075sewbKX3gRih9Il1/aIZiZT4QzdWgc AEIBQmy4zFDTWhp0kF3YbUP+P3tfutxGcq35Kgj9ue0YUSoUqrDohhHG2pJDrWaLtD22w3EDJEES bhKgsbRa/ctPME8w83J+kvm+k5lVmVlZQGFht7xE3KVFAFW5nP185xz7HkwvH2avTd7MvpiM2TUf 4i6FpbcnT7THYTSztkMtcz4cQzyANc0rGJze+VaUZ+9v/cK62Osl4a3JqcETYebGTP4ES2SFU/md +AEVtraEW0WJl9WyenSpPSp6p6ySe5z8iKjLT4yvgoZl+qoafqYja6QcebEbVnYeGrb5661me5j0 vJbBQUeo3mmMhsHyYfcTsfkHSbOvp5E+A1r4csmx4L6HHRYwW12eZj9pt+KI9qVliDZRltkZN3go uSGKHcXWlBrLEHU/Mdvnl+mhhVdVFHsH7OmZPB6In31Pd/tKtMPjkGP1g+nP1pcLCfpWekA1Haib +4j9YeOJ7xbKtn5k7OFq+nlRISdYEr56lnU/IkL0YNL3k/n3kAg6P6GC5BKepob2sfSOyGs1094g EvIsifjp2fVQIB7WdvtNv1M9uKQ0zUysRAJ0UlsDOE7rkUgrelYCA1vXhtOH23XNHeiYD3EsqKRf jpdsGpFeg5VoscjlJ87PESMFENuaQwUYtRPlrrzzjZmSCXS7OO+qbQVHdqHrn/4b03A6u5TD8HEd eJS5KYBugHcQIEp8fvYB86vlaQfu/7v3BDpgSHul31fjZVDFX6mEK0XS09Fo1In8yF88ajcaUeIN ITtQ4ivlHbYahrNbQS2swSJyWZXOoUhHzyFcdAEWuRVkhc72Ks4KoBeoa8kmKPDdZIw2DBhj8sDO V4N1Vq+N6SOWq65xp2WiPEaF2cMzDGpPoT4lo6wo1smtQmgwD8+Xqudnj4dzKeXz68VrOcH8CSYJ AU9lDqnobuJwh+T0mhmnAteYQUAY4Su0ilGoSBh3MP/V6pn+pMA0uwCRV4YqtoZx1K6jWMuxahqt URwnaW7B0cIe92KMBM8MncpWzTYaN2CGvJE7DV3gbHEFOl+UGsv2eWtZjri5SjibeNRLW5EfMQ9a z6Nxa2wF0a2Ddq9AzEf9ZTEfD5k6KLdTsZH0/g3SbasYLYVa6V7zYLq30hV8l9xzwxnHvTIsimup t4Z9Tq3kkaEnfjEN0pO000yQ9XLFwp7U6tKxT62ZlakCBBYdl9iZH6d3GvwjsUcj5cTEoK+7WN7B WvkpgyiyszMjYgAc3R9gHho6Ki6ve5isKH9gCYVcocYRAR60mcVeBZRGFYCkOXGl+BswBBMxt6SM WsFxParCD3fkz8tX1QWYZrrkWVd6aG6AlT+yZKPIJMOEJAJAQoVyvap9qvRMRdwdiLA8w6siwe5s liX05OIRFoCJshwRTgrc+M92FHDRTLAdKl/tKssyGAwB6xiyNtv4RRYyly5/3m1tU79kDzvGTuBe 0Ynb9z57tWDvcIBCHtjg0lvfUSTa39zcfB4gn1jpoceQ6AOAeQcUR5Wf3c8lRZRJTSrJelVLM23I D3EvgIhkGkdDSWBRQpai17ax0HFhLFJl9xPY53jM1WaGueUUuLvO3M9SbDmLVSEGIYiFEnmhCKnK 6/Mb3/a88/woBgBjT49nAbFrVcNnnKhkrHB0WPe1tNonrojIOE5Ula6PsO9RY2kKWfRJ67xQWWsf XgEsZc1VL9bgArYZBipnunoBl8E7n731rdyxoh4B9BLiA0ljrR0Jtkv0pDGRJew0x1Tn8F8WcqNb OFOpbIst+sskB9/sJKJCxGwLFe0bMdnyKCCaM7EriRU0RftQc84YjgqvTM5G8cy1Bpx6rKV5hwGU 7KH+5WwjT60F5Cr2Ic0u8mym8uMBmLE5TCNp95brSFG1KhKEPtz0IUFU6opIhEQyC56PR+DtCgKD FHdGigMV41pFQkz22ZlOhCOExHifqHAVAthnm2EhcYmN3C1QeW214oaqeZrcZQaiQIrNuAs7u6aE IEwOARNLnJTnAoQsysJwKIxKMtYFNbyQYlNGyh6ma9VnS4dAkIPhAcp3DfRcLBfbiIM7v/zMiJkv guQubI6mDZRVw6HRrBLB6PkkEGfpIwAQ5eIaPcPxXiFKYDAlgEKm5ReYD0f9E8Id+lfY5y0A1FLo JoeBGu5/SkuZNYac04BIkEPosCqBBt8pY6orqjCtQbTvQfUFy3SLZO5+ml7p/J+5tOsFrCi26ANx sYrZl/MFeyrsHheN3PDerDnAbMHh7bPwsn3E9cGByXK5XbIHlcKp1LkFcM+k2Wh6WU40c2l12kne Q5IBMde/teHT7ie+53vUof1MvmdWSCEJojzFQzFENX5jgtOUjo9ASqvvQZKj3RlVB//X7QRUBWwb jeJ6b9Dy4g7NcaMxTtpuT6ZeG7HLPO+q6Nn7oxU6C1yJ/nIxdHY1WKEd7qc3M/n/yIZLfIxZcR1h KydAew6VdySwoBUQwMEufT+doqRFaR8IbipaVuh6fLbNibu/Yoc+FBJg+A7VlI55A6sG3Pk+irQL nQl1hjvkY1itwaIXgt7QABETTgjqmbHIVL/jDL2FoD5htS4eZteM1ucaKndJ5VlLFkRNrtE9RAIW EJgKrYD/0F0B7KXj7Z/QpVYSlsYP2eNA9twztKDewGTGPs8wmlbsPI0VAbimT5Ot803+1Gnqnm2a BE/mwOIFQ6+6UvARDETB9VWPMvJ0xrI0BvANYAMVR5fMz+JPsLokP6F+4R9zxnpU9cZxoHGONuMz zXgoqEGDc/Y+h4OvciBOAQtWCR8vq/XNjNg9TllmqkgdXehHe8NpnxYrqSbY6/LeYteFjRIXlbea UMymLie00JJgoyCrkC8Vk2ufNYU1kABccehYGpcHG0xgiby1wvpznlAX6l+kuz+HqQqmRUHVVDd1 uux+ulqfyQF6Jxd8bO5rl4vH8Olo/oN9OvYnKHgHRgL3z8M+L1ZP+p//y54X04IM/eLcvtUymyQm Uvuf0oxXwYZbGLi4RgpSlk6erRdn6GZlZHQmb3HtuZJR2kS8WdPfApKRxMNnQa/mRGLk4VcO5+wi 8C/TrtVdQbC5q93huH22AN/2fvH91J/wUOB7eebhjI9mJQWItuhNKEEHQAzDCeoMsQgxLWUEpQ4w 8c8n9Up+JgNb07rA2MVJVSrZol7bWsKHHoVuswj989jiYIYFshRrT1a07VQbDBungbWwJzYSELog T7GXAmbItl4iqYC6bP5cgBpkZYPE4I/32Irpi4fMjiltzwrvH4/Xy+/QxUUKfhH5mqG+21tZmN5t iE25qvu54vskHhO0L6ceuGVSyMw7WS/WiIvp/iYIvNlXs/VeXQ8ObpHZPb1hy5sqs6m80w393DzR cee2BEfV5J9rtIdACpEteTZITsBXAbWYbDGpr7DZIukiSuutr/rtW/sv38CRBFHpHWF2NrCqBQxP OHOr76lcaf+bY7vxI+ehq9lyC2BNoNReIvsgLigeDTtzfmOefxI+/acOUD55pLXn+bKPjfeEg4hT rrCrlfvOwGGJcrcIcQtJiP3GBiaqNpyehLeD7AyqhiJBUjBJDj+I4nu6WmBudkdRSw6j+MwSFgQ7 CI4hi+Fj2MqG5R0as2jVp4edVVewWHAZDd66kpBVFroKBLDQQ6FkcdtvxpLs5l3BABkHQVHY5uEP ihuteBhOYSOFfGgJNA8rlRAlA3bThiG83L6cL3Tr4aNF8Ox2s8TWj2Dggi7ceQtHcvjeLwzvXbKd qk1rrn8zEwWmP8fTMzjmMYbOryHbcDUFXB29LhAQlSjnESp67z0dqa73fl/JGSo/QeVGM3gTTjYb c65jjozVmASuxz/VVcXeiz6VAN1DxJScE4UmuhsCV4G2QsREFNyM5zwGzXCVDr7MXT7+DCBspmAn lK8iQ6M9ZtdmL6nsq/fa46TBvh1WaVsjRblb2ndB4G4a5aNDMEZDVc66eBbAHgdgp1ncLNPLPDUF EhBog5eHqa2QoQf2ZqFi7LloMqF+TFmC3kJERUEqwWCTmx84dwYiq4cQBHWVQeLjXyv0a6ZbpRtZ Qa3dzn6EnaKaBCKSYeA/GZ5Hv0gUIOQbOPeNvjj5BJoSWYNb0DDcbp3U8V6CpwqMAGkVvAlfwsgX NjXF3wU4ia2j+AuIBJUPcL+OsKH5EAVXftDMNwuzS/Lsvl1KqIRPVcDSY5TsHQ490brc9ZYuPPjc M0BfLvaRkC3l3Rt0a36czhpoq8kSSCSVLdP3YHJuKpGGRASQqBJpKlvlaU4iIwcaRjKShBEOtnqf 70Sg7cMql7phJLNaSF0xapy3agQNisnm0jDIj3/lEZKyeZ6mCmMlM4gzeCA/puhVhTf8lz5UJ7rK h6FdFZrOQkIjvwhRTKb0w4sZGfCAh4NmvZW+qEIEJaRGvEIZ73suaVguxu36sNeoe8UxQRR8gi6q ozwbbYlA9xPBAugyDm7tGSqev/vuPcLmHu2GlZ9WReHd11uNeqc+9LRCkjTTqB65uXh9VwEF4H4i u7cuNrwqO74mHmZ3/y1trz09eD7S4QtR85GA+bybnq1gn0w1aV7lI1IWt2u0N2WXyOsHzDsGL+X9 NVTOeZrNSHHmkpEBs+fgd4yqIyaoC5fZi48JfGhDMAQARVCR09X36OxMPmRCEFlO3adpOv9htlzM ZUCI8LXmVErMzfyGo2NNTR4R6AYDx8R35tg+TpGtIcdLNxtuQ084V0+FxMky2DWi7yS2LAiuKrZK 0uwMhn2/KBOmymiIv78wJGhJEPMniye/UKrU/bk91s2kolKOFvuUuPMDNB2mHkHFNC4J5uAHDDzA vMHaV4Phh1/58ZNtiQQSFpt9OQ2ucrFaIELYGfndKlgpCCGf/uo2DhNUiWopzl493rZ/MdmQkbzS HTCRVqq5jcbbCV/gJDUiHoSuvgiDTI5d97582qzumXZUFjnC0VR8eBh+Ce7AoJ67exp3g3ukvMmw mLDDRuDqiwc4us8kKTVN8ubWaJg9Z6N4JUncXdu0UImPR/X6YCgD0S2fAxWCo9Egcn0Ol1ttnJ37 ia9dtlH2tzncWQaNCfSHlP2lUCFYCcQDsajsM+m/SYg1oMfo3I96ZygKfEETq3zpiiEAClKUetD7 g7agywIU+JeyqTW6rCOzSyyVYSbsIW9ASioTKLNDTawyMMgZerbmp1A6X8jG3tQwtHdeu8jHCl3q inL1J96C9QXcLZy+JxbzEUxHsvvQu2T9NsQ1s674vvsAOnb+T9TVU78ayaPr6KCN8Uj0hofE4ZOy w0NfcQ4I02EikhZOU61QzYPOH8kzRrN0ymX1eywAqKULlgSqESS/xOlXqrRO6mljiN6qsAUsyRK0 2lv9FmC9mdFQ2ULYJln+AE3LS7kliAXGzhdCotqqJPvRgwMV4P9jCB9VvDSOk39WkdzNenvYSVOv EVI8jAa9ZOD6BeXn634iklv/qdQreo/I3jnma8Jifbp/IfkNxG4UInf28MMD7Dy0Vofhl3327sb8 rcG/wc3RP6DDo6G8ojbDDqT4IdlBKasc5yeQhswKBhMzTG0NlOKJGu4lG4GlbS6aSAXd+gz887uP 72k5fykUov2FlfZDdFtOGHDGk9CUI7ERk7ARNcXvZFEW6wfAbQk0wZzHf+GnqtbXmEC14YcLoUEU zyDcxd+as+N/W5KMvMRIDUYPIYjhGB+VgP1RGvf6/UHPFQtJY9RB/4t6JgPoOLjEaRsc7ie/MNnu jbE9Z72vYvuMmncQsko/QEGp/yBtw4AFPX89nQuqGVl/68I/oZFHFhuSD5yLUvFYWsA3GzYulG8o hG4jgl6HIoM7yJfgmfOakI9Wbrq1qoUywiJQzrShroNuRfwTHi5+RgdadNUutvKhsMqAltihwAmr /D6P5W+RIyRZRdp6L8UjI8BRjlH7EOI78ZxQrjabV5HKdQTrB+OBV7eSsi3iuHka8t6m9RAXt8lg skYZrfqTEEBxxytUMCnbVlEI7EA+AJNh0Z9wtvpejZ+6md5O0K0dRLuA4IfV+DRBvTLul9UJuy6o AHhUN/z11ef1XuExE0vqKorjMgvr4bi54iZVmF02tnhA0EVmkdBJLMrWm0Xt94OPSGGBq1RZIca9 8FUuA2HrcnJSa5AdVvHNknlnGx3kF9gugGpKigItBmLYh8zsnGM4FoiQX5IO+p7Ob3VQlxM33S7c roisLjy3UddlZsLSYhWHDaaqNDmSXhjODqq3Czwimvem0G1JWVJE6pilCQlrK9v8DdINZM9qEFIM si+YA0wQCGUe/DXOPZZbVwNv9awkZT4U3whfb1X73RDxGSUxgZFGtSPdCRIO3Am7MxcoR/JSeNhY f0ORVhZkRIJEkZw2BDLtnX0jk98OwRkn9e3l5bkiMllHO5J1wWvQGwMR/nfFV1hUWngVN0xpgZz4 6hbHzb3qN8AwUIHSfMU8GjLDx8vz1x8xeqYKtTcGyRAE78X9G/1hv9ex2prSVBglUdrLp6pYHoTL B76psI3aodWwJ5IJ/jcbl4U7c0WBDBPj5GwegL4y0b/0suEtygGZiWOGQrw/i3yA1UyRCqAOczJm Hqe252jnqTkfmgp/dl4LG+ewMkD8vFnZLto2Z/XruHywFKJUTG6RSuxDUBnWXZsI2wZ5ufqJDQRK dTVhxZCrGZ0kMrt/CRfjekI+45Zw3TQNdIlmFYKOkN5vNSLP9g26xG6DXlt8j1pRXSozpdGtEHQ0 SkcDNb16WyIr1t6X43MBXzM1vY0Z97mQ0SQ0Ci8+o6/Ao5uHDqulxiBOO/2Y/Ge5+mm9PUri/tix 6fVSTTJAxdK9P1rc637ib3YZfIwyL94hIe3uzBJGSMPoUaymKSJo6vZMt66iv4P0tfx8dT95wnXD e6TRnjlXyHCD0JUxDpOB9E88L2U+kAhqlvW1ysEqOK7QVQaeZwpcbEsQEVC6VvuQJzDQfP0CT7xB 0PCC3Za0tUqwgMojPHpss02ISfNZkSpYo8o6MyKuitm97KuFJHfuZYtN/VFGbpNatGOCU7nB/Hj9 KoM81n0qkfJmKwt+XeYmiWS1vq42Tzf9Wxz4PQY1UcOYxiXZLehhqFK2uVmpjpMsL1oqnZvfesmN A9eBvqu4KrYk02X94a/m64Y9iF+gpJp2L0hrimprSgFcCugCB2wWErybrkLQ+Z9tIV+eASEVoD38 H1NMxn/fYYAVCk6B6FxOPknhpwgjLIGjubgmK6FDDL6YZoJlkcwGTx7LfsJF0H4XE57BTkRA+RHh GWAKIUPu1JA+ucFf/xbCgDpkTbEMZIepjDUT86BJ+Xi6u7zfoFDAYvDw/UE4s3mr4jVxKaF3lgA+ wK1F9HuO7UsBqFCERQ1wa0CFznbDki9tjus9dFl3JV/U6Q9bIzFc8m7kHbiAQ9oy6k+WkHM/8YXc NomeBCU6vGEtvNVcapTWrGtfjS6++VWFHSXj0TDpN70dxa1GnMQtN7HrCmcNQvP+aG3T/aRkmxpo 9DCBjNCBxOn87Ou+3qh8bIUNzWkW5FWV5xAoPVIDPpkGrJWcm3No2gmt+nicOf0QNjumkADPKctu jqA0bAz/0cdup8RGw9WDlW+XoIPlRuWssBgqrasphbFumAQ/yOSA/IWR06vuWWT//LOoSAjQgtR4 pk0auxlyR0fVqGUpq+8LZTV7bCd8pFBkG4SUVQYWpsKnBcplbyDwJisme/zje54tj63hOxTbQHqw PdTiCr0h1OwUFdOjMSvAttXsbj67heUDVALSWArgLZAE/IqV/6AFqhhi72ZXqjUC9IkhCqkklKl9 IlEM6kQm+3LyMKi7htGMUB9iP9GaRCcjaLILiSiyMomUmL1ZZcHwwwHAgEjMT2vfIPoMmWx1l79B 3v4B0RhYAliY2g8f7KJNzQQw0YRAvCyWD0Bhct+S5HycPl4h/A+dvxEGfIACPSDFfOwtdgcL4Hp+ 8Ftz4ewDzUEhjCjzttlkFRkyTMEHYK+O3j/U/y+wf0C+hFqQXlvThqvkqQ3rg3YfuEfHo2kN6hi3 GD+jR2NcM5UV+9m04CV4y4TzYOmiWwk4SbQGg8fgUAgXXJ5SHyqenMsBWmGK4yEGz+AzZo1ydahC ca18IPgODWvNHkhEDs1WscdNB0YkR2fXsycEYSGUxLnIjXGKApWlgGmJ1217KhDZk9x14lqRwkdH X/pCKsanTEeNLpJgIfpQMiquEcywhfVStCmN2CdNbbH/M18ErgEi4zK/NdOy6MckKHXOnqcRrHWv nOjdBjlUhIXxmNx1mjxAYGbz1rBEEaQ0TJU0w06c7ZQ/U74nkUPtNuqH5Qa9e4GVmKKBuTvNeuwy Rb2ettJ+THxqbuy6tt5Hxzwz3/vSTUMwBYggH48Ml3QlAXzFG1VODKOK+oO07gV8GsBWsZfWv9iJ 7Z0HpdRRskEfrZE6Drrqz5BD9b+IbQOJIQ7ljXjvnpFVUKN+8NDQnUOMe1iC3dUjEwaCGq7y7mfX 4MLBZxoVibOBp4sAPOWlFQFgNOWjU4RPcZJLcwrfJ3Qog+OvyzZY0qYsJhy6bv/FEgSxwMRmozBi tcvZ4hbhk/mNKrHJ+6Tn7WdxKYyWK5VhPxgdriEbpV0p2EmsNGUOaltNqw7rJ5CWfmvxW6zU+RWL KsTN33U/hZzk0cSRFUdWevVz04Y5vg0NX7KViplDCVRankBuTmR+mtrEI2u7tUbZg19L7N45kcDs wo1xLUgDSnMjIILpGpAFOLwP+l/NCKShkRM4jpF/IIEBQQOGm8OtJ//A5eQH75jlRYgYhz8ihlgo EeYUWuPoUsgpynD5TrwAXhCmBKLCifl0SS+g8zRyqXP9Vfiw9CbJzVmRm6qRM6uECw/2kk66NGau l/DaZB3C4OBXv1e/btWD3RMbnYVVczakeONGrLSfcqBhbkkyADv7Q17b5ZGShKGP80n8Jx7LlWES QPEZxlm9rE0hhHAYsG1x8PCLad7herxFFPRKQXbsQZMHM8Me7whvWrxhXq6N5Zq52Z3ncza3ECqY x9BdbmlbRj/i9P8R6dMXXTgxBJwLg0L2qGSw+E1Xyw3gCgjpE1BKvwVxj+zASd66ziETDtQOgveG dpbU9v1rceL+hlwKWlUWe4/yAkTiAbU25yA0viJTyHjXFQxlijwlOXilN8j3Qz0/YL7p6r+ZZ8gF C9uZvpRLlWfCw1M5HAjAGRsqi8lNCpAf+/x4vJiBaFRVUh6nL48VN11s/AYiWe0VOQT8B5xM5sQZ bIUq0OYrzJS7xeLmTB+42qjobAh1/M8NcVVMSpie/jhewAM2Wc/0STZS1kTh5ErobSLWb/5mNAUX kNvOWGTmfKoF8mpW9wCtMK1kEj4qs2UwtZM5QDIT5CqhBBU1YJnoxgqak060eCifghGGEhtUP5Zh Cv4hHy/J8KLH08dYu7mV7LrGPDrlaFu2sjqD5YaJYlZJMDF49gP4k+JKY6KE6gsTNQyREbbS6CUN oLn2OJKuKRuQ5JdcOvEIjGjO0ft317iJk1lRKGBQ4WDgW2bXIN13EmgHuo29690ohQq6sC08xER2 mLBZTAoc9hA9QIsIEffhMFeF59YejsgcgGOeUFGzroQ1ZtlwI4o9uFw9biXj1iivN+BN/AsELMJ6 /5K8LfF3IRa0c1Tm5JpTcxnPKHW645DTTccPckwEEfBKHnOD8t1Q9sl9cKnc/YJ8cJU5N0648QDy MuBaqYV1GP+HL1kb595tHK3Pwi/rsQaKXf0sbyPjaktEojkOoQZ5AwjlQxDYhq+vCYeFjhfdowo7 FYNDnkx/4Celc7fwa3peECCCIhHhI+AMccZA0WYwVxa4zcxJKlfj+OD3uYqFH8ikl4SuBdCKViBh Hw5NSBAhnxHzSTsnN4O+ABfbI4ACO4rr8tyxB5yJSBmYEhxzwugPZBCbuGQ1BdBXsDTYYhaa85GN 96VLPr5H3DnuUh2+NH7x9pQR9Sn5R5Z5epMizD+UyJJsMTXagBRJAICs4MZDQa1iQQqTKCFupHbG cepQDVErnizqX5VJoMFmBuTAaMHU+A3ZCLkLVJGAbazBALIYaQFN5kHLEMQ2ZpOjB0Xtb4B0/ez9 L0PVv1IkKSItP2ymlgDIQpRIBvhoN0dmCWwenXanujMqE2nQoTjqqfLZpgoPh18y9oD+LXCY8pgT 0voYV6UybMg3SWMtDjTiCuCGkVPy+BTlp1L1aKukPxVDXPl70p8Hr0P01uC7ciTt5OGOYwruH1Wr bnAkcHkIishUJDUUjRThMWP4Kv6Vo4c8BO2crXM3SnHdFd0nGEeii3ygoPbBn9BrgPeU3QueJ40a 8wsA08vsZQni465NmIoZUrhbuBa2T0IES+lO0f2sIUHVgFa5eEJWei6qDzPAnYV9xWi+gTBewWn3 qOiJJQt4DVQie4ND4z8spE8J7HQ1tj4L8SOMRj0pfKGGqMjieU52pCmfi5IhRPgVx87nHyxb38Ih 8ulV8m2NEdoENRKv+gqzhOIxBgf9i+Xb1l1pKaWNe2brwY5oKk0UaEZDLGyHmXINo10pGY3JXELX ggIWd6gf5HQS0uQTkTmkW+htFMK/hi6afkJsbqXcO0FKIgg1maHEaoLOOGgBAMmEvjV42/cUZyuG oOCJas/OrmuRF4hfDQVUu5qtz/hFXUqhHgOyR5wCC8BlS3LeooWsrQ71GF+C4VuMVQtuT3gSepFI XIpKUqwsT05BMup6GIUMg2OAw32xSq4rCLEJyajFb3mCDA1xvq2OScSseMHa3qW8v/k8nzzqyL4S usK8CpVlpvm452Ur4+zSXGFv1YbcQfbQ9pYxllhIuKen1GjY16yYUc/mc+5coWt5tSr2gcCiwBH8 pMLT5gpYeo37Yiii/JGSnRMBVsl7TwYNDvsi2saqKghWS7g1EU61xJiFl4bzBXQ6TJK0t7taouFh a03cRqWPR+q5jNysu28/Xy0xEYW4NEXKELqeptyG0XfStc7vwqDjqD/sAULg1UWFD8bZvn0wUT0e Ji3nYKw9qeUqAROAlYNVOaOJwCDkvODkZ66cGLbSp5FtDQQiw3SURtlTypBDzT+fILGgPQi2vmQA EdQmBoqJQWboGnzwKN0c5WF8hOJZOpJUiFCnujYCwkPKqKTK4QnFfVX0RrMTNdOhj2wJnqh7bjtO tCKphWDce6MpPiDa7hBP9QLMwWLxUEa4YRNP+5Bh+mzVBymgcqx2thg36g1Gab2VkdxHy4FzeUtH Rc0fLZyQ+4lwsxVCPQg8F95fuQlrva9irhOwzwOPt5CP2//lYRf0pfYzMbseOWYj2B8foRjjKEqU paDweHl9zEaQ4+C7JdIHRBgvp0qVUOFTB2uc3wa+zWqFulp4+XmbvSJoF1rqA+O++CkGWyMfC99I 1WsgsU2LVWxkx26l/BC9SwEh9UHopukMWxVjVCnSK7RgxYgFpKlM5aFR0EiRoaH1IywWWDp8FPxi 2slatz2ge/FaIpwvscIDuMpQrlIV+1/aF0gxR8OFDziFD6M/DL799v2FGJlFlRrmXC2ZTsA6wA3r rmuT2r3S8Jn2ybJkmXEkBm72RSqeM6ogCXW6Ggrt2ybz2aoSDrkBdRN3hh7kMhnVO/1xlJk1X4go XR5L92Fh9X6GOmo6rBAxLLLYW8kdu6xflB27ELjMpEPeMpIOUSuuNg0fhLlhg6lyU+RicvydfIOy kmXmiKbDDpPQwXqGrxnMnQ6S87uI9qjj1Sgf54TDOr7J+bCqaZel45tJO2qNh3kh/peh45+JMC9B kFK5z6OE7yVBXO8WYLgK3TJax7gRNK44yDpfDu0kzSEgyyTrAA3Fp8IRF930H+3Dxl3AvljHDFpG mMA6R0EHZQdYhXbjVqsZtwaufVqP0igZN780+/QZabcoVUCq6H+KnAx8+hU7BymxgeTA6h65MSFw gm4d2YF8ngty/JEK7o4GlR0BBIMYb23yA2JIE1VghiJ3o9+zz8E0MpBGGab/YYKMCWpTBpzOVohj 1cS8hYPN+WEbAIVssA/6cD1eze42i80Kcse3kT08KSUUPPnMmheBhWKpz6q4nDOjIZYGanwxeU+o RHDXNPwXzEI81rLYHnJ/KAJiXLBSlKfRifu9QeJZOClaGw5b7SFYNC8q0Sak+ZNjXZs/Pq+zeDQz do0xI5E/eB9OzCgPBDlSzLJlRZ+2W00Ef/YBDbHtVJgXy17kHO4erwqbcIVp24BfU0YoBhf6wVlc SbH+2ePkiRHnt+joANfsPy4YgvJKCVrno/t75wgqaT8hnAhWxlmCAyGAJf6GYDtgWaqYiaka/Dtn 9rL7P4zQwrevTCBb6HOFwCpSpOzKuu/vN4YXcYmqPYXPI3zlSVIdDF/eoAzApjz86d/Q6WdPPRqe Bn4gOEYckxlq6tcgCGFBDyggh1wkTtUqzjJ1Fbk20G/Q6SoNlYSmR85AtAgylkgkzIgu1mPjzQwT gQki6bMmSEGAl3jWO926QyWkoP24GvfhqGpiygHoBiAPyQT4R74e/MSvxM7E+2HU34XHBYOJvefU WdAEQp9Z8NsLBENn8zJmO7GwBYoD5P0EjLjJ5hVvg4kd1fxBHzYuIYNjmiY9shUoeDVVxlzHFQry lXknTgzkjXWouJkLlK4A55nbC8Wb5YwkF6Oi0aEKWIa14KokhnLF8CQemmkD92fYhQT65Wv8Eeca vUQXLy6B6gMZQaCMcAviE+Pr+Xb9jUkAUm0VpPLwUHZbhxFHWCr5wYyMAg8lia4+dyJDxKzL7wY6 gYA40GR20fRIOfwR0x9w5joI4MgACOqMr3P94+ZUPPsEplu9F+9jn1Q7G3jW3z9Olt9LbB723uzm 12QrdJNGb6Ffv/ifrxd9ONNe1Rov61QLekt2UoKGQWNWrQQTVVm+S7X+AvuD7rZRU3sQx+iIfLSZ JciLbS/a/yS6qheIQhEYTFAmVbPtIyHni1efRsz1IUCbXZ7qBv7EjcO7RCCJqf13uNdWvT9E6tfz CpoYVdFu1gnvyL2CTorWRKywVn/SjKNsZPPH7V5BPYmjnjKoD0ohHc20YfqHhsuG+aAFi9TqGLwB 2LIQi7aROPS0UVaj/D9dV6PMMOsJ2ovHd3Uho4oDGlzQ42YNZ1NnYTIsvuXdSeNnyZmYh7L4hXqF PfehCQEZmN5KzJITiFFhIl1Z/g3Nq/AFK52k4CDgnlqpfXBKIYbojTGlFKxPw6xoXMHtqiA9DFMp TttfpIQP41yAIVA2ZzkoEWJTgcmWs7s7FLcraLA2sSqsdA+B2pXidzkLFKPMwDgu1q7sbQfraVc8 hoPs0agXxz3oUieRHoQlbEHAFPuFWkAPLfCeLtafIeN1x7W36LwIO8HvF+pevH4jz3jdvZiihxhx ZAOEGqAmiAjBfzmnFt4j+uT1GuORF4xttlpJuz1wa3TK99hwxL3gAqzl+fI5j5+UTO4SXN3N4hpz GoEtcTYBLaN2nPW9XU5QC0DPQx3ADOMdgWdxfhTeeVRvN+Lh2Nv5L3a7alu9DUB1yxqHfFTYQtwc 9Xro8VqBQN0rsnEz7icK1JFfkT7ub+HeAaEuq9POJ6RDdkcMSzKxpTwHUUBVrqAe9zrgsOdcfzhL beFLCl/wa6bUxbzd7IuDl9+FhW3tT4y+IbQ2GtTeT65WtR6gH/AC3DMLAIi4tq3YnxgplOaowSyK lRdsoRCvl3aIWMsNN/feq1NEtQMLb/y3KNh8P529tFvMwZZySD2w7WDJ/7r79QKD0SEop/NKD8ih CepKjz/teqc9hKhkmNw67ahXTyKMBzrJaWv++3ox/2nysECrPrhgmC6Cqc0jUAzQN5XGYrTipN/p dGimWwttDBu99gCdq09BFrLQLai57h8RtYBg27ysnS8eMHsCU/QAXM17DbrXUSKz0048jPueRob3 0ML0Gi/t7eikI8i7hPiG6FhdCCkVeMOr+NomEyrRsCW4NGV8A1djM/fLnCstBNiGt5vJp+msytHH Ubs16PQ9WR2NWp3x0JtUuJehoMUQT6aw6KAoDksWSJVDxcj/nvk9UgsLCV1jyemVbGOr1MZUEZI1 JYbFnkFTJGknmL6QcazlWbufKCMsR0kfbmjq5yqZ2btmUeDD9OZOxtg6NBtm2aTd7HUGidfKscEB l41Y4kcog74RCJW7g+osqzghTBd/gFW92AC29EAYE2KOiFHpHUxrv52xz7GzicD1lQiAH6F5bqcF pHkl2gmvVerJ8HvgJxkmZIsK1oEhrKrCiZbFVYVjG4NxZ9SUSR1fAFUB40mS+ci0ox1CFC8nM+vf mZmNaIzycXorHdWmrh/z6Y39qDycZR5kK7P+CJO7nVzt0vG0BnpR5k06ejmGTEUs+81kdT2bIS/D +CYQqovl2x7cKzIfLmXdW80mwQ/v+a3gJ9cr2NHZ0/q4Z/XGKzzSntp3NeDr7b9cY+Ls0vwNdvhC l0doELQ5ErMRfJPxWeNCgkPC3Inkf6czbnotGpqNZNhptVzuHEWYg05vyQ70eX+0xJH7iYgjjd0X Ua/nDqr/h+1Kr92qDVf5hKro7z977C3CQv+40nvpX38cD/zHBM/BWljlZzc7rdh/uPWcrWeCtYVF yV98qUbaEUGrIib6dqz3VF4vzqK2Y82Vn/Wy9o+//19/87tWuutEuudoiPQwfQSyCXkViSEAjOm/ xdr6rgeGjxjy6W8blOiJImRG3X/D0fuArJAhs2frxdk505o5VAtbFMBi7avz84tzd7CAFqZVGeQf f/9/zsrDgiLt1TvNSHyFXcokjdJmmgsKSya4n/gyQRu0PsOGFWrREP4WSXMZF+Pspkyfe85g+IoL XFR1LT3W82yeTreSl7j7KcdmIMuACuaHVy9rL9DtZLm42VzTVqj0phOfWfdMkNH+QPSs6sRbUyaB JIFbb/T7SjGvu4h8KsQad8KcloAJsD1p5/jCeU6YOuuI0iLA4cXyon5/PB63Xf82bUUoUc7UmE2d zidh6gzTyZ8HHz78pYb/g/z3FbLfa6QpnVV/enOPsuClNBdYimZevrupR1wFiu7QtOozc6kikozU 4Cl1mmkU09m1Rbf+oyW/XJvmrXmTayGsu/fr9dOb168/ffr06no+fwWTwVkjTjZbZJm50Go0h60k 4cItKZAmaRsxD84sycNL3tqtc0aNOO9efzl8zt1DpcD5+XtUIjob+2VEwKkXsh9pien285EWaerp af0Dier1P/7+f5zzr0JYzeFgkEZN8qVFWHG7M+rE49zdJVM8CwMDB/ru/PL334x6B8v8C0zfRg4P LWSd3VekPkQTLu8XjxPAojIB/w28DGQ1IBQJU+X6zFC4Fy9rCKVOWS3Yct4WFo/NOO21kxF5zjrd ZDToDcZjn22bnWFQeXea9idhti0Vjxcf/4LYX0EqVtOn2pJZGrfMOF+/fnHJFkaS0P6Is5tTplyv in9WOAf9GFjzm9mPm8kh13TilYSPK6cA52q1Wbfu7jSZ9U1RQ5S4B4qylG18sd7csDjG11i778aI e+VS2G/tHiT9yp8XPqhaX4pnsfQB8inzaQEytuUEEIQGwA2x9PVnGMAva9+geUUc1evOkYe5KY0b aaSK9y1uQkArRdaU8dFcCR4sq8xD1NHqx8h2DtCMWx72J1TiLvYNHpc/L3xPB4jU8ld0f5Yl76dt xUTbpm3bvWYfc2sOttl+kmsS7eoT6E6bLe53Gn2MzXGFP2Ix7VGcDzKVAKxeZvDwzR8tQ879+l4a 4d03g6hToIuleYkie+vU1l2y+D5dPQ7QNVve/vbzZr6aLr53Tr+6ajcqfafotrccZiaat5a7ZPe7 QgyCIYNKa7R9wS37PgGz7d6SmevqLVzHA0Q8f4BbKLMUYPF0/O+Vrz98hO4JlQj5/rg5GPlzGCOk GjtJy6389oS8ot3eGBOscs/T4ppW2uxIVx1REz7XuAhIJ+qLLrnRmO143kgQecCI8K9fZPyvIskb fCxxY2CwMVPU9gG5UR12PVSTqN8h5CQFZt49hA2G5w20nH4p+0l+cWOfU/Irz0qFRw5y2eMmJrM3 Y/pQlrUSzC2OWs3+mIk6ZcBYNNvpRP0e0QNBmj00cFcgmGC+t8s+mQ/T5X7UFnz289Li5SHrVGdX IqfOTZT3Qo+01l1RfjtBy37UVlAYyrQABJZQZKHKehFNQ02Id1qZlKjl4ScJgpXRrpJi/agBM+Fw u2X1w/yVvr5XmO79+modn6HfAeZgvsYFIayN3Or1GbrWY/rHDYYgoCDN/gCYPvZbfPV0c+vsB5Is 21BpqCpK4nG/Q3m5i+6TTmMwyg13i+7dT3xZLXfnu4T3qJX/9Qvjotryl4mkw8Ja+73ju+++kBDY qReyn2gWQbadvJN23OpFFckbss8EILbfsY6z/vDqb387SGKnSb8/aqQ+GiTtt+JW2+2i6SEmFNN6 f/w5yXlpdAcDdW2Ehdt9Od11993g7MO7IYx+h5FxpvYv4iRtNFP1i7BILLgMBTlfQGuYF2i7DE0N m6rWZ90dnxS+sb/HUVi8rwDN2q3jNH8KbOf97K8b73gLb5DjyfWgeVqlF4SvxFc1zo06NPDSW5zI z3V36kKdA16VBXsFxYgRWrIWlRkLvWcvGRp++keUgnM2IoNlunhH1/YwRqtqIL1Xh8/fdr7smEA1 +XKwWD3BEaBABA0wpKbTbmjQu0YqHHkvtuG5kI7I3jnoq/Zzzfo2T7CwAvOVkmH4bjMHM7TwvdbX LbioYQ8zaUWoposqGeZuG1HF+imEqZUctMS8ri/RvF2wWgzPO4850CMs0HeZBAu8DIVv+4+jDr6w KM+Krwtfe0GfZHalZSiLu7/dktCXYTOzAzR7WyUpq87jIJuhORgO2sMh0367rF2XOmyUpfvJDrrp jWE9qZAmzFo1JHZwD3T3HxGnO/O4qHBru7S0/fD7jd8oIPy4MipwVmqSK94CtXyqgEdyntYDIB/V R4Rn4u1a9NW+2TxgYvXEK+Exmgv5G+QbTPouqn3lLSVEgRJI2k6BvSRK0+TFwRQ4XT2+ul69un7c vJrebF4LPh8RprvPr58mCDKuXl/MgPmFM4cvcdPjxRKX/grCLtrhn2Ubd2FKYanYTBodhiEqELJn 5yqW9/5YXSqKAAwLCVI3pjF595QpGPVihy7+HRihCdgHkOhKcYwmSzQOGf3ITmTS9UJ6laHzukHx 1PpoNX0jw+kuPvsnqZ6B8rHHPKX3LZLp7CifMVPGNi9Vk9wqfCM1OM/LNyu2qr1+hTYq89mPEuRA 3wvAh1+rv0SJsNJrNvpHy4LX6Mv78D+ao9Ar4jX+95TsE/VRkZSOGKrbpQc0wRprwOIUt8d2QQ+o 2zoskrHuHtlVdgubKoRBH6VRJt0CiByrYSUrclAbO7XVYxpIb1nvAcN81HrOgQnBHD50bfYYqaAX fWtM/f6llf7f+QjXYQy+IVe8W3YrDXrPreks7zALiZ1PWKgMPEvvCW3uoE3azp7CSqLeb7dHgzYj PLuoHF32k4bkZy30s/dHi/TdT4T09Z+4tZ1FNFB1KsOyFVLMTelEjOE+pUOsV1V5zqc32+rtVCnx 6r9qvZsbdH/AwLQKJ9tqjTpJp+OdbDxG7eCo5+KwDq0f1abWQctDZKw9HMUe/rCRDkYohBbMW1ZM dOjyChReMFUVE329b6hlG284NxMIgJSs4Y+IO/x1v+q1MEPFjVYj6RUKWQejYaOBaJmhUkaJDj1X fe2/m09ub2cPM3Y8cnYdXli9PR6i5tPza6J4CLyv5LRyrM2RCxthdMbDG8yU4sgtHOpv7viHkDMW 6JeT9NJ6HaxTQSAdskwpjvE69CSNpDNK6ZpaIjDCJI1ez8tPH/JGkXZLb5poCRX+CYW9zlWWEXA1 PVHpUX4EDXYFrq3ST6ut4qspJnwvllVclrje6yOq7AdymiNkFzyAzaFXoZlHVes6uwyzTRK16wkg CC51JA10+gCjn5KfPyxe1aN67WJxu/7ELhA9GL8bF38dXmKjHyeDceITcNpJ253+aTRNQZSHzaEP k/lfGcCtxfUIpq9zvAFStoLR4Z1Fo0akQSIWa6bJsD5MxhnuXQ0NeOYi9fNXH18NkK3aK4AS3lWT lsHYxxHUsdkUNHVKkjq/R1+8N7X/1W6exelZ2mzGQNxEzrWEl9gatMetuOMnzoa9fj2OcizOCbTY ePLjm1rNXWLkUk54iXEzHjRGdY/q4+ZwjIbLbm7vSFmh9dlPEM5zUPdvEEVjpX+g6iOgz6IeQErt aOTKjyBo5JBlBvRZI+qNQGHeG5uArbeiHqNBp1L04RCPNGTxIzwF+VGiAP+4md9OZw6BBuSG/Fgr nzBxoDAGRRCpZ9220lFjiD+f5Ayqboku79PEtdAO2lNrOB42osTjySRqRdEAPRdPd69dTfCI9nBE 0V7mW9xo9+Nmy4PIPie5x4ME/lRKwrZ0BMo0UHUtkxFORe7dMQYwYSDU9aT2flE7n2Gs4YOL9w7T YrOeDocNKdOyF9jod9JBg3bFyRY4mK2uK62oBele90UnatJj2AsS6Dva91NmVlhC/H7GYcMPh8qI C0T/bmfeRndwlAmchxfEYIkjc8IXiaEa6M/p1/6ga0u9VU9Pw4AFoRK2s1CiM63VYGIlrqYMnMJO GysdISYxFDSMRZ6NUafZ6iQnNXDfrScPbsA6fM5xbzhCPzmeqLWieNhvjoCiOyXDGPuo0TmLmmdp vZmk9UazAinE6AzcHkdEullLTIfNuDeQ3lAn42kti28fFk+UOL+5Jo9XtD2avVYKnLWvBbU0Pvog A7YHxG46QjNA91ziIWyPzvg0kqXAIiWmxPCwurSSMq+DhdX97H6/fndhnmi2B+g61vIILhklrXFn wOM+GcENepcfK3AAtUWESJd705hxkKad+imZNCyy4Syn8aGXAuf/j18EdfSns/d7BT9LiKOBkvGR 37wSYTSYhkhkn4I4ClwXVkzYkAoA0P/vuCWAhygnlAfWR/WxR/b1YZokcZty7XiyL+ysRJ6cMACQ tluNeuoP6U2SdmsMj/Yku9JhLqPgEACoR2fNuAGMQbNKXiitjwdxb+Q5G/GoB3x34zQxJb1EreBu wJBwNyAsf4NM1hJ9FaoIoQSh65Y/PzpuAM+l63syQ9ZNR310kAaGjCplr0TroUnu+nxpfscwyLbn Swj47uInfP8TulPEsbR9eHOP/07b+G+lSO++mfCJmBSNvyd1FWWB/wUMfL2uQo1XC9SYPub/fpje Wp9yjOwUdUwtyeq8uV0s0PYj++fdBpNi8U/9OjgvbIy1eppcoyUXfyKrQB/arzkBHAkxFEKcz9bX WGWjKZ9C+Kh9S6HA1eLms/yHaV3b/f8CAAAA//8DAFBLAwQUAAYACAAAACEAMN1DKagGAACkGwAA FQAAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5p iZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4f qavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLX cduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLi PQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2 tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52 t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWG izegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiH KO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6q bZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFH ZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4 fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5E HDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1 OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1L Tt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7 DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/gykbY2JKDRR1p1bHNPm7ws0oVG7L4eIKN5TKF18/rpD7 bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi/K44e//54rwony++JM+qMBRo3YvY Rtu03fHCrntMGRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFnMjBwcKHAZg0SXH1EVTSIcApNe93T REKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2cnzUKMkaq0Bxoc0YrmsBZma1cyYiC bq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw8iqc+TVrOOxgRgJtd+uj3C3GCxfp IhnhgGQ+0nrP+6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuLk8rsGgvY5d57Ey/lETzzElA7mY4s KScnS9BR22s1l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37U5PZZPnMm61cMTcJ6nD1Ye0+p7BT B1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9JAXZ0XUvGY+KrsrNLI9p29jUrpXyi iBhEwREasYnYx+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ryjZjB2XHM0ghn5VanaJ7JFm4KUiGD eSuJB7pVym6UO78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuMdKa0PS5UxKEKpRH1+wIaB1M7IFrg fhemIajggtr8F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ6DuFWD3buyxJlhEyEVUSV6ZW7BE5 JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH32hz4pzsfm8yglFuHTUOT278QsWgP ZruqXW+W53tvWRE9MWuzGnlWALPSVtDK0v41RTjnVmsr1pzGy81cOPDivMYwWDREKdwhIf0H9j8q fGa/dugNdcj3obYi+HihiUHYQFRfso0H0gXSDo6gcbKDNpg0KWvarHXSVss36wvudAu+J4ytJTuL v89p7KI5c9k5uXiRxs4s7Njaji00NXj2ZIrC0Dg/yBjHmM9k5S9ZfHQPHL0F3wwmTEkTTPCdSmDo oQcmDyD5LUezdOMvAAAA//8DAFBLAwQUAAYACAAAACEABoEUzi0DAACKCQAAEQAAAHdvcmQvY29t bWVudHMueG1szFVNc9owEL13pv9B43PBHyEEPIEMYOhkJgcmSS/t9CBsGTSxJY0k43DLD2n/XH5J V/4CQtpAcunJRt59+3b36XF59ZgmaE2kopwNLLftWIiwkEeULQfWt/tZq2chpTGLcMIZGVgboqyr 4edPl7kf8jQlTCsEEEz5uQgH1kpr4du2Clckxaqd0lByxWPdhmCbxzENiZ1zGdme4zrFm5A8JEpB vQlma6ysCi7lx6GlOKyBPcfp2SmmrME4ZMQFYcA35jLFWrW5XEKGfMhECxgKrOmCJlRvgJ/TbWDW AyuTzK+6ajVdmRwfCPjrNKmDgfbfY8sJ+OWjzpAHjb5CskwJeJiZmRf0bEkSIMyZWlGxndt70WAe q5rSPxveaTYXbuegXjOeY5YeSJzD7uvCuTiAe2UYUZmUJuUcjKC2MnqJ6DpHbMRANByOobBfs2ay K778faPZKikXcAU/cqG+Sp6JpitBP4Z2zR4aLOMEJzBzusVV321NnQRw4BV3KyyIhdLQv14yLvEi AUYwcWQUaQ237oRyn0YDC2wt93GmVxxu20xiBp4TYnTD0ZyGIU+4+R5hDSjgTGct12s53r3b972O 7zjfzVfKqKY4AeKzm6KCQFDQF1jia6jQGfXGvU73HELhVJNHXZzOpr2zSTA1AOCx0S1QcYL+uTvy mqOAxDhL9M4Xw1/MZfG405uEQPYaJwNrUlruPaBb9vDSbsKKWFmmyNdSbklMJDg7qfKqWMwY14WJ QECJWEKZ2no4o48kQhjpjeCIMjSjy0wS5LbRPCFYkS9IEYJiCgyfn34ZPrpgVWLUPc9h5o5z7nUD J7BK4Pn8bo5UJtdkA+kGVL3MLgPb+lE/P/3eFoS6awKUFglmDyihDH7EmsgKBoVYGE9s78GZQRXE wLCNfxrs6tVsFtZXrOM9Aul0jxSIexH0+5NeZ18g3ng6uQhmo0YNOzKo5/f/CsT8V/tK4BDujYAd ElioNRxFEahmbwGg/rqbUg3jqRt0zwo1VFKEfS4hptA5Ya2v432l6uGPUxEXEwWSzv03kW9nk27/ wjsV/03cn3uIhyKEk0qFavgHAAD//wMAUEsDBBQABgAIAAAAIQCzqeghjggAAMEfAAARAAAAd29y ZC9zZXR0aW5ncy54bWy0WduS27gRfU9V/mFKzxkLdxCqHW+BIJjYZWddkfcDKIkzw5gXFUmNPPv1 aVKSZyc+cm1lK0+i0ECjL6cbDfRPP39t6punsh+qrr1b8DdscVO2225XtQ93i18/57fJ4mYYi3ZX 1F1b3i2ey2Hx89u//uWn42oox5GmDTfEoh1WzfZu8TiO+9VyOWwfy6YY3nT7siXifdc3xUh/+4dl U/RfDvvbbdfsi7HaVHU1Pi8FY2ZxZtPdLQ59uzqzuG2qbd8N3f04LVl19/fVtjz/XFb0f2Tf08qs 2x6ash3nHZd9WZMMXTs8Vvvhwq35X7mRio8XJk8/UuKpqS/zjpz9aOZZ3WPX776t+CPiTQv2fbct h4Ec1NQndZuiar+x4eo7Rt9M/YZMvTztvZxY0XLO5q8XyYf6u/XA2ycvfqg2fdGf3EwAmKRotqt3 D23XF5uaQHXkavGWEPVb1zU3x9W+7LfkJIJjwhbLiUDKdPfrsRhLIg/7sq5nfG7rsiBmx9VDXzSE rLvFaWResyvvi0M9fi4267Hb06SngmS24sxy+1j0xXYs+/W+2BK30LVj39WXebvun90YCKU9GfEk xAmzkzinr/UJ/7SiLRrS4jR6xvTHbldOkh366jtDXTX0tGCWkuwx64A36ihe+2pXkmp1uR6f6zIn 4dfVb6Vvd+8Pw1hRlMzI/hMS/EiAsp12/oWi+/PzvszLYjyQmf5Pm82eyOtq/7Hq+65/1+4IG392 s+XFiZM7KfnthsvHv7puvLiBMae4yeTJFtO0FwrjIlMWUqQNiYcULVkSr1CUwGsMN1bANUYk8ozm /5LNqjRP4RrPjE4gJcjIHKREGRWWOuoYoA04UyGFEnCurQhoH64E89DWXDPprlGsh9ahbbiCmnKr DbYbtzZc4ZaILGJuTsZMQ31SlRvoUx5EvIT4a8/xoHiKrROZtZhb5DzlUIIo0gTbLSrl4BohtE2g BEIqg60jiFkK9xFKSwOtIxItbI6kFomN3ECKEzaDiBdOe4xe4azNIa4pfpWE2BFRCon1icqZDMkm uVAWRonkMsXWkUbyHO4jE64YxJtMrAl4jVcyhZrKYBmD0Sij0Q7rE22qA9Q0p2CE2JE5iQalVtzy BMqmpObmfNy9jgWllcM+VYbZBKJKJYrcjaQmiseaqkSrHNpAORkitBuhIGEwGid8cMzNy8xCz6lU aAaxozIlHLSoZtpg/2gqp7ENtDAZg7JpSVEPY44oAcecVizDeVQrLvBppi2TEnpbJ0IE6FPtBBPY BilX+GzUqdQ4TomSa+gFnSpmYHbRqfEGIl4H5gTMIToS5iF2dE5ZDEpgqKjAmc9w7TnEm6GgT6Hd jFZXYttYGTiWwGrhoA1MIiT2j0koGAOKOROYzmE0mqB9xFJnJsE1kok6RFht0EkfUii1VSLTmKIZ z6DnrFYRVxtWUyxAL1BJ4RTU1FKu0niN0T5g2RKKbhin1jFCNrI1lUGBYQm8TTneJ7UWZxcbmBUw H9igjIaxQEez8Vi2zAaL9aHzB0ejza/lxIQZFaEECTepgNmFkovFdW8itMK4TqSWOd5HWoZrsUTp JIFRT5QM59FEGxshQhJnWYb18aQp9HYSKI9iblRb4kooyQwlGISqJHLG8T5RWIy3hPKrhXZzTDAH reO4ETiPOqG8gtnFSTpkYD64fmtzSmhckzul0hTazSmT4UzutCTpkN2cpisY1tRIKkTgGqPZFRsY 4zJsAytSHFnOMS2gT4mSeiy1U1fqA+dsgu9mzkvG4ensUuUlzCEu41FCVDmqvPGt2nOTaKiPF8rl 0DpeaschEr2hbBWRF7xlicX7JDYT0Kc+8CSFceqDYjneJwqfQvT6nIfkCkUlOOp9bhi+z6Wcq1wg TVNug4H6pFKEAD2XOqkiPEtSTxdu6NM0MIOrwTTyzEgoW24MjvrA6D0EWicIy3E9SonPcBhzQWmP T1o65oSAZxZRUnxrC5oZXFMEskAOoyQYReczskFIGHcQicFLh++AIVUC18pUxKc494aMU1kBJcip Vsay5TrDOSTkVDjA7ELXbY3zNYHAK4i3jCpLBr2dOe5TaNGMUjl+p8ic5lcoXirsuSwYejBC1sno bLzCLecZrtYjuZTDXBWZSSXMFPTww69QuA44u0TFtIcZKRrOMUKiEQHfqqNlHJ8y0VIsQOvEhDSF MUeUK+dp9NrgOj56E3EWi6nJGURvDCxgz0V6f8MnEz3lOQuRGKP1OOpjzk2O1+RC4pt4zG2OM2zO rDIQ8Tk9V2XQorkyeQZjgUox7zA3Zzx+lco9vTTCrJx7qrhmW9P7+fRYQ6/mzWpqfH3qL19TK+Km ObUxQtFs+qq4+Ti1xqih0aw2/Ze0ai/0TUmtwfL3lPVhcyHe3p4IQ1PUdU69mgthFqBZ7aphn5X3 M9v6Y9E/vPA9z+jhKPWF3n/jNfWZyv7vfXfYn3Y79sX+1GK4bMeVOvOr2vFD1VzGh8NmfVnVUnvr d6RDu/vlqZ8YLl/Mc1yN1BWdWzUfivbh0kko29tf11PrpCyG0Q9Vcbf4d3H7/tO0mpoUdb+emqnl x2K/py4Vzds88LtFXT08jnxaNtK/HTVV5z+bB3GmiZlG/yba/KfYTsrS7PPHNOH0SbPOHy9j8jIm X8aoZXiap17G9GVMv4yZyxg1dY+rR2oR9dSv+0J9sMvnNH7f1XV3LHf/uAzeLb4bOhlh7gD5w9iF cz/uU7WdO06ziYbHYl8SEKZmH+GxW80D5+7fcPO0Kr9SK7HcVSN1svfVrim+UmeRiTkqzrPr4rk7 jK/mTpymyftXoze7YiQPzTXl8tVi8jW1Jl/Lclztym1F+F0/N5uX3uKbk1p1NYzrck9tyLHrySBz 5+9vM42r1a7bvqN2E32d+pb0TkqZdi6wpo3Ovfe3/wEAAP//AwBQSwMEFAAGAAgAAAAhALiCR9TD DAAAsGIAAA8AAAB3b3JkL3N0eWxlcy54bWzsXF2Tm7gSfb9V+x8ovydjDGOPU+tszecmVZNsNjOp +3gLYzxmg8EXcCbZX7+tlgDxIdQamE22avMysQAdqfvoqCVo/fzL131kfQnSLEzi1cR+OZ1YQewn mzB+WE0+3d+8OJtYWe7FGy9K4mA1+RZkk19e//Sfnx9fZfm3KMgsqCDOXu391WSX54dXJyeZvwv2 XvYyOQQxXNwm6d7L4Wf6cLL30s/Hwws/2R+8PFyHUZh/O5lNp/OJqCal1JJst6EfXCX+cR/EOT5/ kgYR1JjE2S48ZEVtj5TaHpN0c0gTP8gy6PQ+4vXtvTAuq7HdVkX70E+TLNnmL6EzJ7xFJ6wqeNye 4v/20cTa+6/ePsRJ6q0jMN6j7U5eg+U2iX8VbL1jlGfsZ/ohFT/FL/xzk8R5Zj2+8jI/DO/BpFDB PoS63pzHWTiBK4GX5edZ6HVe3LG7Oq/4WS7VdhFuwskJQ8z+hDq/eNFqMpsVJZesBbWyyIsfirIg fvHpTm7JalIWraHe1cRLX9yds8pOsJvFX6m7h1rn4Rc25eD54AzA8bZ5AKQAjjCcKGQcnC2AL/zH xyOzq3fMEwGCFQCYXC38bFgcuALMueMEhqvB9jbxPwebuxwurCaIBYWf3n5IwyQFkq4myyXDhMK7 YB++CTebgI0XUfYp3oWb4L+7IP6UBZuq/PcbJL+o0U+Occ6bzzoZZZvrr35wYLSFqmOPefg9ewCI A+6QcLBBx7BqDS9ooGLh/wtIm/uwE2UXeGyEW9j+XiDs9XEw0Iz1SO4A1mvUVmd4Fe7wKk6HV4Hk HWaLxfBWgK4P9QjnhsRKulPzxOfkk+3gLHsoy55osUj7RIs02idaHNE+0aKE9okWA7RPtByufaLl X+0TLXf2PuF7KFxNFjloDdLAvg/zKGDP9wqQPVDqxFRjffBS7yH1DjuLTazNZveJ5d1xndOainL6 dLG8y9MkftBaBGZnNnSfrMnX+8POy0KIkjSmnw00/T2Leqxf03CjhTrl5Gv1CQOTzinsQ+T5wS6J NkFq3QdfuUcNnn+fWHc8ytA2bqBbb8OHXW7d7XDK1YLNFUZXW4LXfxtmaIPewTRXdEVXOcmHcwUv 1ZW/CzbhcV+YhhCNzLmeG7i5AYFN7DeRy1zUHl3aXjAHULrApwvzLmD9hPbzycW8fuZjSvv5VPTE +gnt5xPXE+tHfvT711hprmDRapGG18J47F4mUZJuj1ExBrTysDAewSUErQvGg7isnyQSC+MRXJNP 69z3YeVG4amxLyodNUAxdgdHwcFG74uxUxqyZxv0yNhBDayZAdYwrTUAMhbdj8GXkO2JmU4GqNJl rKkdzo7CAjAFkWLo349Jro+hZwrNo6K8jWG7JAssGpqjGHlUNMEnPt8Z+HjYxGcANGwGNAAaNhUa ACn4oY55yjmRDjJ8cjTAMpblchZD2pGVeWGszCWQ2RQw0rxJiL8Uo1fNhfa8SUAxdlB73iSgGHun MZeV8yYBa7R5k4ClmDXUPpI11aRTxvOmDFRGAoQejSPeBKBxxJsANI54E4CGi7ceZDzxJmAZa0Op qbJ4E4DwFpOlfgkkizcByFgbuNqJPaNi3sNa+he3I4g3AcXYQW3xJqAYe0cl3gQsvMWECQ2sUuoI WOOINwFoHPEmAI0j3gSgccSbADSOeBOAhou3HmQ88SZgGWtDqamyeBOAjOWhBJLFmwCEt5hoQ6d4 46h/dvEmoBg7qC3eBBRj7zQEtQxSCVjGDmpgleJNwMJbTMggsJDcJp0aR7wJPRpHvAlA44g3AWgc 8SYADRdvPch44k3AMtaGUlNl8SYAGctDCSSLNwHIWBs6xRsH47OLNwHF2EFt8SagGHunIailzhGw jB3UwCrFm4CFfBks3gQgvOWpQCY9Gke8CT0aR7wJQOOINwFouHjrQcYTbwKWsTaUmiqLNwHIWB5K IFm8CUDG2tAp3jhGnl28CSjGDmqLNwHF2DsNQS3Fm4Bl7KAGVil1BKxxxJsAhMQcLN4EILzlCUA4 ikzcNI54E3o0jngTgIaLtx5kPPEmYBlrQ6mpsngTgIzloQSSxZsAZKwN7Dtb+F6U/HmqrSAB9TuD 4qsGMuBM4SQqoOjgx2AbpJBkFei/DhkIWPTQAFFBD2oXL5Lks0X7sNtREIQMFa6jMMFPur/hVzpS IoKz6MkkuP/t0nrDE2BazyGl6l/eQPaQnC6E6UkscQjamX87QMrOofiynNUGCUIsr0ukAGGK3FtI CBJpPexhlucDN2JSlSjG97YCFf4PiPigBqqsXHTGxtwyufoqzQcR1h4kJ/3Gco1a4DF8Qd1VDglX n4vyAuZy56XcvFXyRnGPyOCo+gJpXxl8Vyogp9Ola8+vHP64SPb6HASH94CPbWQ/biHLK8NfWZkH tg4gjxCM7Z7hKy6RFjblFSXHnGWG3X6JSiB2gaeBMStChh3+6cyp8/7oyaljF69Fnh3zby2trvZk lVbHiqu0ujW3/SXvkc8++Cxa6cxPb5Y4xjEjD5UWstnwE8eqmL0FhJ5f3PDOSml6Z0WJlKaHZdBz 7PITmTRTMkkkBo7DpBmBSfXwCE35fOQSWYY6cmGyyA9PLvfmzL64YpztIhcfXlXG57yDSlg2kEqO kkpCBMahkjM2leylc311yo3yFJ0iUgnH0z+fSgNJwrOiu2Yul3tgHJK4Y5NkOXfcczHlPSNJcKT8 iCQJUUXCrqlNqz56yvgQZ3g+pH/3xFUiu6/84Bpz+5pRliIFEBvfDmFEKmC1YcTvqyWkQBG0XxGk 5SztrafNmBbXGxBaeAunfruBkImOTdK1EIR/HfHAB/7zNmZRGJyIgPETj1w3Xz1eFVy/DKLonYdh Up4c1LdGwZZFilCRPcXlfqOqdZLnyV79fIrZcMoKwKxyY/hP1gm1vePjfh2kkM7eY/P3CVsmt+Yi SALEcgUVqJZWt63GYf+YgWnu2OKhuT6oxdZN/oqLlm1VAtZQxM5xgL3qiuCVzOIX1BH7v3G0GPXA b857QwfzkFfl4NlIDhZReod0/EMdrJ1NwC2jxLI1d1YLbFjnp2wgtQTkTXkFBxt5VHa4Rqh6x4Kn Ph7Pb9yzmVgLivFYW1RO4d/NTTPu39UbegQC4yYAO/MGZitoPYiYZs1YM45ezHhMruK6MxLXxTKi w6BdXJfD+h9UzLRc1zuqtiNVspjNdGWg1GIybiNXl7voLO9Wte0NqWz4kHp5frF03GuxZSPC5RCj EhZTrCYLOG8Aa/DhgAbYDzp6kcjQ5+zER0abavliQMVOdyR2Cpu0rSVGe31oy+uJH4edf2OU3yMq xyxIvRZrWen/RBBLFt+60WfuKezDCQVUhPTdA+pKnED2zju0GlZcs9hF3WCSY7TiQXiuivY6+ENe BNR7u3Tdi4tz3iIxBqtN1nLjC2YHtqEKZ1W5uFxgP7qP2lLsra4mt0c/3Hhw+gecHYerIdw57Sj3 s2Yhmkuaz8Ugyv6UtjmxTK+E1CmrafWmLhTXmTuHSkNRV8kMsnfVruxUi6Zdwavf3wnldHSZ7Nnx fdW7qabNvThO4Dw2djpaWr4y6xpK6sUP2bLaqGt5ZV879airYqjdsRHPy/QM7ZYWYRw82KbHLmya NFIXqd5nURfJSi11MVWUyr6zv0EBmpZpWl1cx7OGhiqAhMW9R+ZpQwEkcwsFGMdovaSE19h/BH57 M0Uar5m4pWu0tjovv3tsXZSnRnFR4D83f4VB17wPYo9TMq8IVmuzEpbpxzx1VurosIqWwihqZkqW rSyntu7YvHwOM3az9MKLoiSJO6VTXOMHhnWRU17iyMaRKq2sRx61RrNLSzd/zKhsyJxH5X/T6k3y y+5UM18dHig8PDb309pnB2NGZUOc0D163ty/u/0A4RaeW5sHm9bCht1g1e4wGUfN6p9jMLnnzhUc l4HNEoMJXsngScvwt9j4YnsObJPskMD6Y2mL99+qG+wzR2yqqu6YLVwRBarucOZzEceo7nBP4esW bLfqjlN3qWnp3LU1LV04M01Lz2aupqVgME1L7ekUjmnu7Yw9XS41bbXtJbxl6q9lBs3V3OIsYB3b X4s7P8XmwuwNxke2PM/C+DI5piF/qSlWY1IJWwwXP7G9lICDfaBWO5T71wvW2fHikM5R2xTjljAM VeQmKncgedKth8qyKCgWy4Xdq2WyVPIdHVOumJlBLkM476vT9HgFOUPeCCPbUh/AzE+nxanxwrzy tqGeit2zUXkKW7PH5QXsMBy+Dsex43/JXarT48xZTBcjbotBhxVbibXYp3TtTQJB62Owqd4nNXvc vuN7+frsfH7R9wLqDF5A8a805Q/Ptq0ecn8V83Hfi6jCmtnrvwAAAP//AwBQSwMEFAAGAAgAAAAh AImPyjv3CQAABp4AABIAAAB3b3JkL251bWJlcmluZy54bWzsXcuO6zYS3QeYf2gImMUsblvvhxHf wLaspAeZYJDcYNZqW90WoochyXZ6m5/JJ+Sz8gtTEmW1ZOpFqd1XQNcmtyOTFFmqIg8Pq4rffve7 792dnCh2w2DBCfc8d+cE23DnBs8L7tcv1iedu4sTO9jZXhg4C+7FibnvPv/jm2/P8+DoPzoRFLyD NoJ4fj5sF9w+SQ7z2Sze7h3fju99dxuFcfiU3G9DfxY+PblbZ3YOo91M5AU+++sQhVsnjqGdtR2c 7JjLm/PDfq359vbSsMjz+sy33aBog+5ReHAC6O9TGPl2Et+H0TPUiH47Hj5BDw924j66npu8QP94 tWjmtOCOUTDPR/WpGFVaZw4dmJ9871IYut1clkhgTv651IiogdZ0klQxw+3Rd4Ik694scjzocBjE e/fwKrehrYE89pcutQ64NNjzQZCp9xXi6fPRzcg+w7e/vPh8oJqrEcaOVPI9IodUoV7V6LpFge/x RdImij706UL1nZeelJXvPEw0r5p0PoANjjGo76PweChGdXDHtfYQ/Fa0lU4FDD3j1czUy0OLmRqg 5opf9vbB4e787fzhOQgj+9GDHoHE71KN5D7D9GQ/xklkb5Ofjv5d5f8edguOz4oEsbuD3062B08U baUZqsTN0sr+0UvcH52T4315OTiXMvuXx8jd/Sf9zUt/I2UT/+BdSvAmL6qWsSS/eKf0Bxf+Sd8I fyYHD2Ykda2KiimRbsIsavnJpf7j0fOcpKj9xfm9+OlT8fTf20txz3nKCx/+G6X9doN0QOnjBaeJ 2Tv3dvCczeaSyqdNzM7zvHBE6kRWGCQxVLPjrQs6srY9F8aZ9tex42QZu/YXmM1Bvr4Lov5hCWJL f9ynf1SKb+OkVHDl7kg5N4De7JwnGwSX9yB7NfQERJN2uywo4VVQvMwbPM9L2ROY9WCyO0E3hOzj waoUFcIRiHB6CzNkFaYgywOlGR4j14nufnLOZaFdPWUTkUiJSHl7Ef39x5+sQhIFULFUM1hV7n+g oCnkgEWs0KvqMzYBEY3JjC3XIaJVb6pDf//xF7OAdH2YgH558R9DgBiFdEoP2EQjZ5pSFs0UzAvm pmGCWV8ZUj4nXT1lExExprKIpmFesjRwRq+aEhFR9RmbgAAYX9aySZmXAr3JbIR1/ilZE5FO6QGb aDRKNFMwL0UbODHfwrxgR3mlPdMwL1UeODlXTWmIeQESKsHVTvRKAFAFva54Q5AElSxIQ9HrxhR0 yTTXxbIGH4pCr8Tihb4gbOdsXd/OoTLgvDKk/afwr+JVbwNqe0JKwch0kB0OeOHZiX50ksSJip5X RiTeF897jqgLWdYPiYKAwmrMkH4OfTsoel4ZkVQ3osh93jfvPCgcKIBllbYe9UOiQZs1cEitOifX jad1IyV2oLb64VBA63ZKpzAPqQtv1Q+JAkY3Uzq1bkTtSkeho15KR0OZmyidVjeeVqXrwjL1X4iC H7dTOp19SB0opH5IFFy4mdIZdSNqVzoKMzQoHQyNZYEXKXpK0Na8bFo5zzF0gVckVdasC0wosy4Z bib0lLxUxNVmRfpQYVlEskL0ZlmYKStDzL42M38whrKqMFh7NrT/EbmqLTC319sCNqlR2IWfxgaA gi19GdPxG4AqBUojIaSv8o0IhaomwQ53wanzvIlrvyKqaumr8RZHAbeJWByF2b6WxdEwcBoW14UC GxWrRGAho1U53Xofi6NQ60QsjgKs72dxjBhYojGwqVuSZKwICh2KgXlxvV5urD4kF2/1PGlsJRyE um1F696v4+S2fp9EYdHbbf2Q5IIDbQotNmz9uqDdTfgGJLngC3Whsno7orDSzfgGJLm64E39F0KS i7gs1Tq9ZCcULXT+dEiu3P+p5IMlWhtRlJbyuAXeWiq8quq9Fvi+p1gtflkD3EA61vd3APUUWJjE NrrrKKxRMNd8VO02mpHbQ5YqdRVscdRDlirKvClrfBg/IkvFaF4UzJrIBhkpqQXXujntwmyNkzRS UmNIYEbzQv6JWr1gNWM5g1Uo/kkSRFPR9M04eKqu9aUiKJlDTJUbKJ3B5m6VpA+VM9ha0N8KT5nd uIfC07c+BvuIIHX8WQ/iVsryq2aGuBVxaykiZ7zFIZTtsDg8XW20OIrLnAQRc9t4gfEWh+iWsjhG dKvS6FY0N5LMjzxd1SxJBxY3p3AbPAwR3UJA8EdEt4ybWISylJkjlO0ZRo4ULAm4aSHwEbd2mBfi VsStpZ0i4+qFIJUyL0aQqtEgdW1pvGZo4yjYJa/LirJu9xD4imEwQwlYDIMp579BbwLiJtR6mkd5 Mb6fPzBCWYSyrwltrl142ELKEMpSa23VvBDKIpRFKFvkuBt/VM0IZXUaypqyqWmWNQ7K6rq21iDt KWmlnW/FaJYstyMIqZLgBKNZMJqFZDmiOMPbhVBhyhZQOsrXslcIFQ1lrFvkCcKULfCFug6CYRWs cX+mmK+bhVBNJ5rFoBZ4WdJESRNGLvAQq7ox5M2yxwKPOdkKIeECf50NmiJ6es21tK/cTeZaDFfF cNXXVOm4wKfeIdlepZpqqzP7JOZkAzuiUlw0zHSMO3iBvjNAlgxTkMX8Ww1NSLExVvpKWfXawmO8 Kpc7j5GViT2Da0uoBF4KQA6MWkSElwKkd4W0CggvBWi4wITZvLrydzRGGl6fJb1FODieMOEJ0+sl HGynkx/RyR+dpcZeacOKT+lbAWRTNFRRz7mjofhUVmTeMqw87LX9iAkDVvM7vhCl1lPD6NLfsYzS jBsJFHnTnc6AnEVdlyA0grG3S/tAHc9NIlYOUWoPN0PqpO9ruRnS3OI0zAuzqqQHFjW3WHadQDbO O7fYBFIHmxNJWkRRnu9nXqwolb7aQlmpa17bjPTpX68secNL6NNfXN6ahVm/3uXKuCHD8NTO+DnE sohlh1JCiGU7zQsZ1w7zQiyLPv3o0//1fPoF+ooK1YLr1YyVQbw3hjKuFi/pSk+PAGRckXHN98DI uD7HqSc4404HGdfGZRRRKqLU2F1w1XA5tsNvRKmN5oV+AZ3mhYwrtQlkZVzpe1aAbJV5Xsyv8x2K Ug1TXupmh9+qYonqEk5/SHTM0bf8BFboU4cXHfPFwZgxJT0+uYpsZXa4u23GlPFpP5FwpSaDapYH hLKNa+1HhLLjLQ452A6LQ3TbaHEfEd2OtzgEvJTF0YAXwuIARcJ/H3ZpqFyKfUpXuzzsLhBTyPJQ Q30omhaq1COYtLaekvK3DdUI6VtbLQPUDdUICq+tlrHFDdUIvVtbLQs7a6hG0nvXVpNaxkYSLtZW U1uqkeQ2tdWENpmQmPnaelk0XMPg8ki82nqZF0lTvTZNaRMLDKJZxbKLfJre2KIsbaoJetv4wtb3 talLRV9Ihx+dyA2eP/8fAAD//wMAUEsDBBQABgAIAAAAIQD2KMFj4QAAAFUBAAAYACgAY3VzdG9t WG1sL2l0ZW1Qcm9wczEueG1sIKIkACigIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AJyQwWrDMAyG74O9g9HddZouTSlxSjNn0OvYYFfXURJDbAfbGRtj7z6HnbrjTuKTkL4fVacPM5F3 9EE7y2G7yYCgVa7TduDw+vJED0BClLaTk7PIwTo41fd3VReOnYwyROfxEtGQ1NCpXgSHr3Z3Ftuy aKgQ7SNtDg8tPbfFnoq8yMWuKYusbL+BJLVNZwKHMcb5yFhQIxoZNm5Gm4a980bGhH5gru+1QuHU YtBGlmfZnqkl6c2bmaBe8/xuP2MfbnGNtnj9X8tVXyftBi/n8RNYXbE/qpVvXlH/AAAA//8DAFBL AwQUAAYACAAAACEAdD85esIAAAAoAQAAHgAIAWN1c3RvbVhtbC9fcmVscy9pdGVtMS54bWwucmVs cyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITPwYoCMQwG4LvgO5Tcnc54EJHp eFkWvIm44LV0MjPFaVOaKPr2Fk8rLOwxCfn+pN0/wqzumNlTNNBUNSiMjnofRwM/5+/VFhSLjb2d KaKBJzLsu+WiPeFspSzx5BOrokQ2MImkndbsJgyWK0oYy2SgHKyUMo86WXe1I+p1XW90/m1A92Gq Q28gH/oG1PmZSvL/Ng2Dd/hF7hYwyh8R2t1YKFzCfMyUuMg2jygGvGB4t5qq3Au6a/XHf90LAAD/ /wMAUEsDBBQABgAIAAAAIQC0r75G+gEAAPcDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCiBAEooAAB AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJxTy27bMBC8F+g/CLrHlOU0dgyaQeGgyKFpDVhJ ziy1sohSJEFujLhf36UVy3LbU3WafWg5nB3yu7fOZHsIUTu7yqeTIs/AKldru1vlT9WXq0WeRZS2 lsZZWOUHiPmd+PiBb4LzEFBDzGiEjau8RfRLxqJqoZNxQmVLlcaFTiKFYcdc02gF9069dmCRlUVx w+ANwdZQX/lhYN5PXO7xf4fWTiV+8bk6eCIseAWdNxJBfEt0zKR22HE2ZHnlUJpKdyDKoqTCEPKN 3EEU02vOesRfXKij+LQop5z1mK9bGaRCUlHMZtPFjLNRhn/23mglkRQWj1oFF12D2aNU2qKLbZaG cDbu4iTRFtRr0HgQBWfjkH/VlgiV8xvOekgUg9wF6dso5vPEcwj5VkkDa5JCNNJE4Oyc4A8g05o3 UhNvvsflHhS6kEX9ixZd5tkPGSEJuMr3MmhpkYRMbX1wxMZHDKLSaGg21fr4CMdtY6yvBSlHvQQu G1Oy50CFS3bHE+L3hu6G/yA7HZM9cuipjuiM4HDGH1PXrvPSHsRaR+Wy7SEidJF2+Z5Oyv+MT75y 98lJ74JeJkdWeNHYbr1UtKzZ4rakxZxNMarxLZkHalrxaeI5wR9I/WDSsfSv3UF96vm7kGz23L9j cuukoO9oqlOOfDE8MPEbAAD//wMAUEsDBBQABgAIAAAAIQCNIdQWjAAAANoAAAATACgAY3VzdG9t WG1sL2l0ZW0xLnhtbCCiJAAooCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACySbIK zi8tSk4tVghOzUlNLklNCS6pzEm1VdJ3DHDUiwj2UVIAC/gl5gIFgWJKChW5OXnFVkm2ShklJQVW +vrFyRmpuYnFevkFqXlAubT8otzEEiC3KF0/Py0tMznVJT+5NDc1r0TfyMDATD8pMyknMz+9KLEg oxJqGFWMsrPRh3vGjpcLAAAA//8DAFBLAwQUAAYACAAAACEADCwHOOcCAADKDAAAEgAAAHdvcmQv Zm9udFRhYmxlLnhtbNxWQW/aMBS+T9p/iHxv44TQAmpaUQbTpKmHrdPOJhiwFtuRHcq4tvede9h+ wrTDJu3Sf4PUa//Cnh2HdiWdwlQ2qUEi8Bx/+H1873vv4OgjT70zqjSTIkbBLkYeFYkcMTGJ0bvT wU4LeTonYkRSKWiMFlSjo8Pnzw7mnbEUufZgv9AdnsRomudZx/d1MqWc6F2ZUQGLY6k4yeGrmvic qA+zbCeRPCM5G7KU5Qs/xHgPORhVB0WOxyyhL2Qy41Tkdr+vaAqIUugpy3SJNq+DNpdqlCmZUK0h Z54WeJwwsYIJojUgzhIltRznu5CMX5zIN1CwPcD2E0+Rx5POq4mQigxT4G4eROjQEefNO4JwCPZI yoaK2YWMCKlpAGtnJI0RDvEAN+HdvCLcMO/INwjJlChN89WDuAiPCWfpooySWS6LeMbyZFqGz4hi 5jzFkmYTWJjpIY5RP8AYh4MBKiJBjCIIdHurSAhnKq62e6axioBw4FwWxz4StC0ORADH7bLH9Avl rBFxyjjV3gmde28kJ+IBQkK8B0Q0gQ5DTGPLhMC5w+4qfUikB5H9VhS49DcipMCpT0hPzhSjylDy ABn7QEDbqsOQEf0nMhr/goz3UJzGlHQlFc1SYLf36kIJH6VQyl9xiYMuTOWYa42KMlJZKK1iU1k6 NQvl7YIPZVrJg8O7e3u6PPQIB+MklUSYamg6ozCGsW3nNIyvOSeOVtZxaxR/FIT94zZ2zpurrzdX 373l+Y/l+c/lxcXy/Jsl5V6XiPqPKf7SAo1oW3jfnPy++IMyUil+w1i5q74pvp4lbES8lwpGEmqz JGl+Ap20bG9dkERaJLreTo+he2DXO2xTra6OR2yn3f6ddmpsqhv8nSiON2ynrns8UB0YquO3a5tE uB8q+8RdmysmjU2qA2OrvPqKKQRhxo1qPUS2gboha5s09IGHymmiJOaWhhrj1abThDOJ68tP15+/ PB17cNOkPvwFAAD//wMAUEsDBBQABgAIAAAAIQBNi2NDLQkAACYJAQAUAAAAd29yZC93ZWJTZXR0 aW5ncy54bWzsXdtu40YSfQ+QfzD0nlFfq7uN8QSZBLNYIAiCTPYDZIm2iZVEQeRYO/n6PSTlxM7Y gB2M6Ho4T5YpiZb6uO6nqt5+/7/N+uy22rd1s72Y2TdmdlZtl82q3l5fzP7z+4fv8uys7Rbb1WLd bKuL2eeqnX3/7ttv3h7OD9Xlx6rr8Mr2DHfZtueb5cXsput25/N5u7ypNov2TbOrtnjyqtlvFh1+ 3V/PN4v9fz/tvls2m92iqy/rdd19njtjZHa8zf45d2murupl9VOz/LSptt3w/vm+WuOOzba9qXft 3d0Oz7nbodmvdvtmWbUtvs9mPd5vs6i3f97Ghi9utKmX+6Ztrro3+DLz8RPN+1vh7dYMjzbr2dlm ef7v622zX1yucYIHG2bvcHyr+rY9/jw7nNeri5kzxccY0/D0ZbP6/FN9i6duF2sgM5v3L8bZ/Vxd dXdXzZ9Xf6uvbx65/Huz+/K175uuazZ/u46P83617/9G99d7tsB8hhe2f1zM8J+BB7vFEt9heLxs 1g2gWnzqmvFjrO99spe98/LBJ3rZe/f3v/lL3jofMBi+9PjwIRohxxRjMETjJf8Dp0Ij+hRSDoVo qEBDrEuuEI0X6cdTyYYUl0rOREMFGtmKgWzQiutAI5mQs4+0GxrsRimSQ3aeaGhAw9riQ05OCIcK OJx32YZC6VBhOayTFLKhIX9JTH04P5WTa13J3sdA6dAhHbFkk6RY2g4VtgPxXxSbKB0qpMO5LDZI YkiuAw4Y8uR8YBQ4ORxjnePHm3q9+lt6PUX4uiWMeRLWNb6opnwNR+rJ07fZRB9ciWN5g8c/8fEX KbnY4kb3icc/8fG7XvfAYxorsTz+kxz/XVF1/NkebcA/uTqoMVSf+yK5jcGaLJIoOk+U4U9qOLyE WJKVMWdIyVEjOfdlxBVj+gItg/PJ/d079fYQDmdi8oklQSVwBOMkWEqHFji8dyFkZhI1ZBK9sbYn IZL3pkI6vJFoffRUVjrgsOApm0jm2/RFwSdzWc44sMfzXbadMclJYpKnjz+X7BwSWoP95ulPe/pg KSCL6yWN7hOPf+Lj97E4nySNpSUe/0mO/y6o/rqZROQQUww5MJX1KonElIwvmeW/Ex7+P5Gb+4kr b01EkeoIEjvSntkH9zUS8HfQPYQjFRcTCaLTBx+PwgGn14Dmw0yJjtAc/J7kXGCmRAccIqaUKGQk 6oAjg84ONjvhUAFHsKjOWmHPpg5THmwpMOTMsiuBwzkbgIdjSVBDSTD45H0xeWTLMQx85TAwBDEo eXBOjBJlJd6KC478BR2elfTkUBHCoQOOLD5mx7hDh7KKLoGJCH4PPSsNnlUMyWeTCycwqFBWMQUv 0TEqV6KsUgpo9hDGHTqkowS4urkwKlcBh5hgAgwI4dABh7c2gYnF8pMOOJDN7T0r9twogSNiLmJk ClGHZ4WeguxRgqJ06JAOCEfxKXJcjA44shcPVi+JPTrgKEhZCepPzFlpyFkli9ZyWwKjchXSgR0F Ht3MjDt0eFapFw9EHjTlOqQDY/FhyAuVlQ44ikWnP7QVTbkGU57R64+5upEpRBXSkUFARGmWDQU6 THk2glUFIVNZ6ZAOQZtzdJa1chVwlF5Voe+ftkMHHB7DRMFeIBw64IgGCUSfCYcSOMRm2A7S3lTA YY3tezVhPhgHaogDezww19V6urpK5KNfBYWVpyx5KMFDwJuWZFgv14JH7tk9kfpKCR5YzZUxN5Ty oQQPzIlBv6ZnFUoLHhAQbOeivtKBB6i60YHMzvhDCR4+hBCNIeNKCR6CVZtg+TBfogWPIOLA2WW+ REW+xGbpt+Ac90dxIsYrT8TAInMHgqhlPlFH5bxfLA9mCUJC6isd+qoESIgjhVqJfGD2W4lop6V/ pcO/ct4GsHYj9ZUSPLCeCws6SdvVoq/QKohZ4My3a8ED7KsQI7sM1OAB6pXBPFf6uyr83WEWAxhY 9K902HO4VwFtUcctOcyXvHa+BHikIqD9UF/p0Fce/KvkjquIKB+vLh8BxtxhYgnlQ4d8YFGXw+Ib +ldK7HkSixEylngowSNjUReazlk/14IH2pzBT6R/pQSPAuFwhvGgknwJgkGJKXnyRXXIRwgpScEu VPq7KvzdEDG1JLB9cKZFX2G5vIDOQPlQoq8wGTyKpb87vXwMC2nbH2/q9erd2/vbaYeBABjUx3Xa E2x0vn/w2Q/z+I7FWa6gP+kK+vsH3wcUyKKD6Da4TTz5k578uIL5TvM8tpDZhpydQaM/256UmOmc saMAqSmGFTrCCuwnkBTYVj692/SovorJeoOBoUyD6NBXmEliUjGOaXQteIQiBaOUaD9U2I+ImQvO Jpb9tNiPjKk9JifaDx36CoyqbOFf0X5owSNaTO1xpPFowaOU4LHSkfZchT0Xh7ZZyzFjWspM4oYp rozPlfhX4oLBEFfG59Pj8WSZKRdbxMlRRphzP2nO/X61w2L0usGUnqM3xZOf7ORdMagz5TCmQXjw Jz34Z5SZ0BnQ94sbhhVKwgrvTEyYsMewQkdY4UG3dcaw+1KJfCCLDo+psCyuBA+4sAaIsCyuA4/k TcQ8t6N/xe7L1+6+BB6gVZH9rCUtlXzBOgKh/Zg+DfIobSRhpynCcE4DVYJH33hpfWGaUAseNhkB NZfdGjr8q4zxrEgesgyrRT5cwngLlDaYL1GRL0EDR8gO/UzEQwceEkrKQZhPVGI/ZODlMj7XYj9S 9L6AvE59pUJfofMShVmkFImHDjwwSxqdHZxWNb2+epI2YlPKWNqR/BgUsoh+0iL6A95ILNhlGpwd y088+clOXlLEUkYkQga7wIM/6cE/gzfSD9iRhEHqtNM67DR2OBW0BzAPoiPOQ9GvxFgy8VCCRy49 IT0wj64ED6TRsSeTW7WmjysercOimQleLTQW7bkOe46sbbaGeRAd8oFRPN57CY7yocJ+gCRtAqYp cMuyFvmIwXhxhXl0JfKRAjpiTeK4ES14CFhVNrEOqwQPgIERe5n5Kx14WJNMPyWa8qEGj36HLLcG vZ5/dczC95OJm11Xb+o/qg/N/v2+ObTVft5fXqzXzeHXX/41/LJqfmm6j4vb6of2Y729Xlcf6nWF Z3CbQ3X5seo6XG3f/R8AAP//AwBQSwMEFAAGAAgAAAAhAILt/vZgDQAAEmYAABoAAAB3b3JkL3N0 eWxlc1dpdGhFZmZlY3RzLnhtbOxcW2/buBJ+P8D5D4Lf2/gWOw7WXeTaBki73SbFeTyQZSXWRpZ0 JDlu99fvcEhR1IXmMFK2XeD0JTUl8hvODL8ZUhr98uu3beg8+2kWxNFyMHo7HDh+5MXrIHpcDr7e X785GThZ7kZrN4wjfzn47meDX9/9+1+/7E+z/HvoZw4MEGWn+8RbDjZ5npweHWXext+62dtt4KVx Fj/kb714exQ/PASef7SP0/XReDga4v+SNPb8LAO0Czd6drOBGG4b00bbul4x8Hg4PDnaukEkx2hK FCd+BPI+xOnWzbO3cfoIPdKnXfIGJEzcPFgFYZB/B/mGMznM83KwS6NTMas3claszykIcPq8DYub QWz9vVwDp/xP0SNtTLRFSN7lMvZ2Wz/KUbyj1A9B4DjKNkFS6u2lo4E+NoVIByesTHafjKYNPKke itEvU3cPti+A90ljuBZlrHmnbcj1wByqdKP6iKMhwSJsCCkDRYQqZiGJ6nz7l6mm9KR9Aguwy4J6 n8a7RM4qCbqNdhM9ybEYD1hINpzhUlenllkN0OCKu42b+ANn653ePEZx6q5CkAg07jCPHLwDblrH 3qX/4O7CPGM/08+p+Cl+4Z/rOMozZ3/qZl4Q3ANnwSjbAAb8cBZlwQCu+G6Wn2WB23pxw+5qveJl uTLaebAOBkcMMfsTxnx2w+VgPC5aLpgElbbQjR6LNj968/VOlWQ5kE0rGHc5cNM3d2dssCOcZvFX mW5SmTz8QlES14OVBzjuQ+4DCQHlMZwwYNYdz4H++I8vO6Zcd5fHAgQHADB1WPhZ0zhwEzDVHQ8R cNV/uI29J399l8OF5QCxoPHrzec0iFPg3OVgsWCY0Hjnb4MPwXrts4gk2r5Gm2Dt/2fjR18zf122 /36NXC5G9OJdlHPx2STDbH31zfMTRpMwdOQyC39iHYCwwRwKDgq0C0ppeEMNFRv/V0COuA1bUTa+ y2Kog/IfBMJZ7zoDjdmM1AnguFayTroPMe0+xHH3IdB5u+li3l0KyJy6WoT7huKVdKPmscedT9XD ZHHAZVmPhhcZezScxtij4SPGHg2XMPZoeICxR8Pgxh4N+xp7NMx5sIfnInHVvWiC2iAt7PsgDyFO Gphu1JHqRKhxPrup+5i6ycZhgbUu9iGyvNutcpqoSKcvJ8u7PI1ZumnQCERntnRfzMlX22TjZgFk 5Sagjqq/Z6mP8z4NIH01QB1z52vMCROT1hD2OXQ9fxOHaz917v1v3KIW/T/Fzh3PMozCdTTrbfC4 yR3IClnINYLNNErXa4KPfxtkqIOD0XymmYppcJINZxq/1A/+0V8Hu22hGkI2MuN8bmHmGgSKeFhF U2ai5uoyzoIZgDIFHi7sp4DjE+TnwcV+fGZjivw8FL1wfIL8PHC9cHz0j8P2tWaaSziDcUjLa269 di/iME4fdmGxBoz0MLdewRKCNgXrRSzHJ5HE3HoFV+jTOfM82LlR/NTaFiWPWqBYm4Oj4GKjz8Xa KDXaG1nMyNpANayxBVY3rrUAsibdL/5zwE6dbYMBsrTMNY3LeaLRAIQgUg79+y7OzTn0WMN5VJSb CI5LMt+hoU00K4+KJvyJxzsLG3cLfBZA3SKgBVC3UGgBpPEPfc4jYyIdpHtwtMCypmUZxdDtyMw8 t2ZmCWQXAnqKm4T8S7N69b7QjJsEFGsDNeMmAcXaOrVYJuMmAau3uEnA0kQNvY1UTrWZlHXcVIFk JkCYUT/kTQDqh7wJQP2QNwGoO3mbQfojbwKWNTdITlXJmwCEt9hs9SWQSt4EIGtu4GwnzoyKuIej HN7c9kDeBBRrAzXJm4BibR0deROw8BYbT6hhSaojYPVD3gSgfsibANQPeROA+iFvAlA/5E0A6k7e ZpD+yJuAZc0NklNV8iYAWdODBFLJmwCEt9hwQyt546p/dfImoFgbqEneBBRr69QIVSapBCxrA9Ww JHkTsPAWG2cQWOjcNpPqh7wJM+qHvAlA/ZA3Aagf8iYAdSdvM0h/5E3AsuYGyakqeROArOlBAqnk TQCy5oZW8sbF+OrkTUCxNlCTvAko1tapEarkOQKWtYFqWJK8CVjoL53JmwCEt7wUyGZG/ZA3YUb9 kDcBqB/yJgB1J28zSH/kTcCy5gbJqSp5E4Cs6UECqeRNALLmhlbyxjXy6uRNQLE2UJO8CSjW1qkR qiRvApa1gWpYkuoIWP2QNwEIHbMzeROA8JYXAOEqsjFTP+RNmFE/5E0A6k7eZpD+yJuAZc0NklNV 8iYAWdODBFLJmwBkzQ3sPVt4X5T8eupI4wTU9wyKtxrIgGONkaiAYoJf/Ac/hTJG3/x2SEfAYoYW iBr3oE7xPI6fHNqL3RONg5ChglUYxPhK93d8S0cpRJjMD1QS3P924XzgBTCNfuhS1TdvoHpILRfC 8iRWOARy5t8TKNlJijfL2WhQIMTqukQJEBah3kBBkCjrYZ1ZnQ/ciEVVohmf2wpU+D8gYkcDlBxc TGaEtWXq8GWZDyKsXChO+o3VGjXAI3iDuq0dCq6eivYC5mLjply9ZfFGcY+o4CjnAmVfGbxXKiCH w8V0NLuc8O6i2OvJ95NPgI8ysh+3UOWV4a9M1oGtfCiLBWVPT/ARlygLG/KB4l3OKsNun0MJxC7w MjCmRaiwwz+tNXXuHwdq6tjFK1Fnx+xbKaur9CzL6lhzWVa34rq/4DPy2AufhZST2fH1Atc4VuQh 00I1G77iWDazp4Aw8/NrPlmlTO+kaFHK9LANZo5TfqEnjbWeJAoD+/GkMcGTqukRqvL1nEtUGZqc C4tFfnrnml6fjM4vmc+2ORdfXmXF56zFlbCtoytNtK4kSKAfV5r07UqjxeTq8pgr5SU8RXQlXE// fFfq6CS8Krotck25BfpxkmnfTrKYTaZnIuS9opPgSvkZnSRAFgnaQpuRfcwu40Ge4XpQ/n0grxLV ffKFa6ztq2dZmhJAFL6ZwohSwPLAiN9XKUiBJpBfk6TlrOztgMxYFncwIXTwFu76TQGhEh1FMkkI xL8KeeID/7mJWBa2F6XoPHNdf3P5UHD9wg/Djy6mSXmc6G8N/QeWKcJAoyFu92tDreI8j7f6/ilW w2kHALWqwvCfbBJ6fUe77cpPRW2dNv9m2+RGLIIiQGzXuAJV03rZKj7s7TJQzR3bPNT3B5Xcuu6/ 4qIzckoCqzFi6zrAWbVl8FrP4hf0Gfv/82ix6sG/ud9bGpinvDoDj3sysMjSW6jjH2pgYzQBs/SS y1bMWW6wYZ+fsoXUIJAP8gouNvKqbDGNYPWWDU91PZ5dT0/GYi8o1mNlUzmEf9fX9bx/UxV0Bw6M hwDs41YQrUB6IDHDnrGiHDOZ8Zxc5+uTnnxdbCNaFNrm62pa/5OSmdHXzYaqnEhJL2aRTiZKDU/G Y+Tycps7q6dVTX1DKRt20m/PzxeT6ZU4shHpcoBZCcsploP5WFzz4AMNcB60c0NRoc+9E7v0Fmr5 ZkDnndOevFPopKktsdqrS1vdT/w83vk3ZvkHSGWX+anb8FrW+l+RxJLJt6r08fQYzuEEA2pS+vYF dSm+ePfRTRqCFdccdtG0mNQcregI/cpsr8V/yJuA6mwX0+n5+RmXSKzB8pBVHnxBdGAHqvCtqike t7If7Z/a0pytLge3Oy9Yu/D1D/g6I+6G8OS0pd2Dz61Vb0Z1KfFcLKLsT+WYE9vMTEgNWXWt13mh uM7M2ZUairGkZ5CtqzdlK1vU9QpW/fFGkOHoIt6yz0WWz6bqOnejKIbvsbGvo6XykVnbUtJvfsia NWZdi8vR1aSadZUeOmo5iOdtZg9tpxahHPywzQG9sDBpxS7KuK/CLoqWGuxiyyilfsd/AwPUNVPX uriO3xrqygAKFrce2U9rDKCoWzBAP0o76JTwGPsP32sepijrNRO3tK3WxuTVZ4+Ni2poFBcF/mv7 r1Dois9BnHEq6hXJaiUqYZt5zVOjUsuEdW4plKL3TEWzpeb02u3bL19Dje1eeu6GYRxHrdQprvEP hrU5p7rFUZWjDFpqj7xqraJLgzd/zqysS8yj+n9d63XnV82p93x9eqCxcN++n1ZeO+gzK+tihPbV 8+H+4+1nSLfwu7W5v25sbNgNTuUOm3VUH/41FtP0bHIJn8tAscRigkcy+KVl+FscfLEzB3ZIlsSw /1iMxPNv3Q2jk4k4VNXdMZ5PRRaou2Mym4k8RnfH9BjebkG5dXccTxcGSWfTkUHS+WRskPRkPDVI CgozSDoaDuEzzQcnMxouFgZZR6MFPGU6PMoYxDXcMpnDPvbwKNPZMYoL0RuUj97yOhvji3iXBvyh ptiNKS1sM1z8RHkpCQd7Qa3yUe7352yy/eUhrau2TsYNYujKyHVUbkBy0K2myiopaDbLhd7LbbLS 8gMNI3fMTCEXAXzvq1X1eAV9hnwQRtalOYGZHQ+Lr8YL9arHhmZXbI9G8its9RnLCzhh+Pg6fI4d /0ueUtU9Tibz4bzHYzGYsOYosZL7SNNex5C07v11+TypPuPmHT/K1idns/NDD6BO4AEUf0tTffHs oTFDbq8iHh96EFVoM3v3FwAAAP//AwBQSwMEFAAGAAgAAAAhACEBrztaAQAAlgIAABEACAFkb2NQ cm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAISSUUvDMBSF 3wX/Q8l7m6TTOUrbgcqeNhg4UXwLyd0WbJKSxHX796btrB0qPt57z/045yb5/Kiq6ADWSaMLRBOC ItDcCKl3BXreLOIZipxnWrDKaCjQCRyal9dXOa8zbiysranBegkuCiTtMl4XaO99nWHs+B4Uc0lQ 6DDcGquYD6Xd4Zrxd7YDnBIyxQo8E8wz3ALjeiCiM1LwAVl/2KoDCI6hAgXaO0wTir+1Hqxyvy50 k5FSSX+qQ6az3TFb8H44qI9ODsKmaZJm0tkI/il+XS2fuqix1O2tOKAyFzzjFpg3tlzYtuc4i5Ym WkvOTWVyPBK0x6yY86tw960EcX/6Y+enrl21cJDt+5V0luNxHUx0mXsnIKKQIuszf01eJg+PmwUq U0InMZnG6d0mTTN6mxHy1nq82G9T9Q11dvofkaYxudlQmpH0kvgFKDvHlz+p/AQAAP//AwBQSwEC LQAUAAYACAAAACEAhj9b2q8BAAAaBwAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNd LnhtbFBLAQItABQABgAIAAAAIQDCYJrz9AAAAE4CAAALAAAAAAAAAAAAAAAAAOgDAABfcmVscy8u cmVsc1BLAQItABQABgAIAAAAIQB3L+nNfQIAADQNAAAcAAAAAAAAAAAAAAAAAA0HAAB3b3JkL19y ZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAGTZrUMpcQAAzhsCABEAAAAAAAAA AAAAAAAAzAoAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhADDdQymoBgAApBsAABUA AAAAAAAAAAAAAAAAJHwAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAGgRTO LQMAAIoJAAARAAAAAAAAAAAAAAAAAP+CAAB3b3JkL2NvbW1lbnRzLnhtbFBLAQItABQABgAIAAAA IQCzqeghjggAAMEfAAARAAAAAAAAAAAAAAAAAFuGAAB3b3JkL3NldHRpbmdzLnhtbFBLAQItABQA BgAIAAAAIQC4gkfUwwwAALBiAAAPAAAAAAAAAAAAAAAAABiPAAB3b3JkL3N0eWxlcy54bWxQSwEC LQAUAAYACAAAACEAiY/KO/cJAAAGngAAEgAAAAAAAAAAAAAAAAAInAAAd29yZC9udW1iZXJpbmcu eG1sUEsBAi0AFAAGAAgAAAAhAPYowWPhAAAAVQEAABgAAAAAAAAAAAAAAAAAL6YAAGN1c3RvbVht bC9pdGVtUHJvcHMxLnhtbFBLAQItABQABgAIAAAAIQB0Pzl6wgAAACgBAAAeAAAAAAAAAAAAAAAA AG6nAABjdXN0b21YbWwvX3JlbHMvaXRlbTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAtK++RvoB AAD3AwAAEAAAAAAAAAAAAAAAAAB0qQAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQCN IdQWjAAAANoAAAATAAAAAAAAAAAAAAAAAKSsAABjdXN0b21YbWwvaXRlbTEueG1sUEsBAi0AFAAG AAgAAAAhAAwsBzjnAgAAygwAABIAAAAAAAAAAAAAAAAAia0AAHdvcmQvZm9udFRhYmxlLnhtbFBL AQItABQABgAIAAAAIQBNi2NDLQkAACYJAQAUAAAAAAAAAAAAAAAAAKCwAAB3b3JkL3dlYlNldHRp bmdzLnhtbFBLAQItABQABgAIAAAAIQCC7f72YA0AABJmAAAaAAAAAAAAAAAAAAAAAP+5AAB3b3Jk L3N0eWxlc1dpdGhFZmZlY3RzLnhtbFBLAQItABQABgAIAAAAIQAhAa87WgEAAJYCAAARAAAAAAAA AAAAAAAAAJfHAABkb2NQcm9wcy9jb3JlLnhtbFBLBQYAAAAAEQARAFsEAAAoygAAAAA= --_005_CEC4BA6718160flopiccociscocom_-- From duanshihui1201@gmail.com Wed Dec 4 06:19:19 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC831AE216 for ; Wed, 4 Dec 2013 06:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_71=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZElVA1F5yDAg for ; Wed, 4 Dec 2013 06:19:14 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55E1AE14C for ; Wed, 4 Dec 2013 06:19:14 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id as1so26721874iec.27 for ; Wed, 04 Dec 2013 06:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Z5mfWQSK2m0IBMRoK9DlM4akzyn836myVqewpDQCENA=; b=lZQfnq/g5wmzsC/qZdFYb+io2Mhv50A5UPIx/qCI8Cu1VIgYAbyDOD/IEvsTgcH9Jt 5c1RNLdes7BhLnF/EdoXXD80kkcGVm3FvixChR1X5/ESjzh32KdMSuuUsFdlXR93jblN X5j1O3AEazh2fxxP/l7Dp5FOCXw79gpjZf1lqoGXtZ7bAqFWRcabIWB2LW4nun52FYmp 9tz5X+ZTX0kqIss6JJz5gbaSQx2dKt+0Y8GbKaryPw/+ejjEeuAqA5hugvZfHKLfwOmj BADbDYSOWaD7YVuCXLqfSERNJcYiVws3wrBII5vV1Kx0qyuIoXbnl4ckZyjKN1hXB5R4 XLMw== MIME-Version: 1.0 X-Received: by 10.43.132.137 with SMTP id hu9mr1479331icc.72.1386166751419; Wed, 04 Dec 2013 06:19:11 -0800 (PST) Received: by 10.64.238.39 with HTTP; Wed, 4 Dec 2013 06:19:11 -0800 (PST) In-Reply-To: References: Date: Wed, 4 Dec 2013 22:19:11 +0800 Message-ID: From: duan shihui To: ppsp@ietf.org Content-Type: multipart/alternative; boundary=20cf307f3adcd1626904ecb61806 Subject: Re: [ppsp] ppsp Digest, Vol 63, Issue 2 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 04 Dec 2013 14:19:19 -0000 --20cf307f3adcd1626904ecb61806 Content-Type: text/plain; charset=ISO-8859-1 + In Section 3.1.6, what does it mean by ?not RTP/RTCP? in ?the client use UDP to transfer the encrypted media streaming and not RTP/ RTCP.?? --> Duan, if I remember correctly, you provided this part. Can you please explain? yes, it's right. the media is carried directly on the UDP and QQLive doesn't use RTP/RTCP to carry the media. There is no RTP/RTCP in QQLive's protocols. On Wed, Dec 4, 2013 at 7:08 PM, wrote: > Send ppsp mailing list submissions to > ppsp@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ppsp > or, via email, send a message with subject or body 'help' to > ppsp-request@ietf.org > > You can reach the person managing the list at > ppsp-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ppsp digest..." > > > Today's Topics: > > 1. Re: WGLC for the survey draft (Francesca Lo Piccolo (flopicco)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 4 Dec 2013 11:08:33 +0000 > From: "Francesca Lo Piccolo (flopicco)" > To: Zongning , duan , > "'yunfei zhang'" , Gu Yingjie > , lingli deng > Cc: "ppsp@ietf.org" > Subject: Re: [ppsp] WGLC for the survey draft > Message-ID: > Content-Type: text/plain; charset="windows-1252" > > Duan and all, > > I absolutely agree with you on the good quality of received feedback and > on the necessity to fix some parts in the survey draft. > > To this end, I'm attaching a new revision of the survey (and also of the > pictures), where most of the comments from Rachel, Roni and Lingli have > been already taken into account. > > Here is a summary of all the received comments, with the ones still open > highlighted in red. Lingli, you are among the "to" receivers, because there > is some your comment I would like to further discuss with you. > > Rachel > --------- > + The description in the last paragraph of Section 1 is inconsistent with > the organization of chapters . This should be fixed. --> Ning, is it > possible to turn section 3.1 (and subsections) into section 4 and 3.2 (and > subsections) in section 5 and 3.3 (and subsections) in section 6? > + In section 2, some terminologies have already defined in RFC6972. It?s > unnecessary to repeat the definition, e.g., chunk, live streaming? --> done > + Section 1 typo: ?we always try to identity tracker and peer protocols? > should be ?we always try to identify tracker and peer protocols? --> done > + Section 3.1, typo ?this may turn at end users into playback quality > degradation? should be ?this may turn end users into playback quality > degradation? --> done > + It?s better to adjust the order of types of P2P streaming applications > to be consistent with the order of subsections, which means ?mesh-based? > should be first, then ?tree-based?. --> done > > Roni > ------ > + Figure 1 ?traker? should be ?tracker? --> done > + In section 3.1.2 on PPLive change ?being the nature of PPLive protocols > and algorithm proprietary? to ? Since the protocols and algorithm of PPLIVE > are proprietary? --> done > + In section 3.1.3 ? Authentication server is the first point of contact > for a peer the joins the system? to ?Authentication server is the first > point of contact for a peer that joins the system? --> done > + In section 3.1.3 ? can contact new more peers besides the ones indicated > by the rendezvous server? to ?can contact new peers besides the ones > indicated by the rendezvous server? --> done > + In section 3.1.5 ?Since children could lie regarding the number of > chunks forwarded to others, Tribler peers do directly not ask their > children, but their grandchildren.? To ?Since children could lie regarding > the number of chunks forwarded to others, Tribler peers do not ask their > children directly, but their grandchildren.? --> done > + In section 3.1.6 when first using CDN expand to Content Delivery Network > (CDN) --> done > > > Lingli > ------- > + it states as a "standard track" document, is that accurate? --> Ning, we > already discussed about this. As per your comment, this document should be > ?informational?, rather than ?standard track?. I assume this is something > you can take into account as soon as you will submit the final revision, > right? > + in terminoloy section, "push" is defined as "Transmission of multimedia > content without any request from receiving peers.", which I think could be > better described as "Transmission of multimedia content that is not > initiated by receiving peers." --> done > + In section 3, "the topology that can be associated with overlay > connections among peers" could be rephrased into "the topology of overlay > connections among peers". --> done > + Also in section 3, "pull-based data delivery calls for large size > buffers where to store chunks" could be rephrased into "pull-based data > delivery calls for large size buffers to store chunks". --> done > + "buffer-maps" are used to refer to "chunk availability information" (as > used by RFC 6972). For sake of consistency, I think it is better to use the > latter instead. --> I re-phrased "in some applications peers exchange chunk > availability information in form of buffer-maps (a sort of bit maps with a > bit "1" in correspondence of chunks stored in the local buffer)". Lingli, > have I got your point? > + In Section 3.2.1 ?channel server, that provides the list of available > channels (live TV or VoD content) to a PPLive, as soon as the peer joins > the system;? should be ?channel server, that provides the list of available > channels (live TV or VoD content) to a PPLive peer, as soon as the peer > joins the system;? --> done > + It seems to me that the content server may have played some sort of > tracker?s role in Octoshape, otherwise, how would a joining peer gets to > know the initial address book of other peers? --> done > + In Section 3.2.3, ?a mechanism very similar to the one of TCP congestion > window (double increase or linear increase depending on whether the > estimate is below or a given threshold)?, should be like ?a mechanism very > similar to the one of TCP congestion window (double increase or linear > increase depending on whether the estimate is below or above a given > threshold)? --> done > + One may be curious about what is the difference between a ?repeater > node? and a ?simple peer?, as the description of a ?repeater node? goes > like ?Repeater nodes, that serve as bandwidth multiplier, are able to > forward any sub-stream and implement the same peer protocol as simple > peers.? --> I re-phrased "simple peers, whose behavior has already been > presented, and repeater nodes, that implement the same peer protocol as > simple peers and in addition are high-bandwidth peers and are able to > forward any sub-stream. In such a way repeater nodes serve as bandwidth > multiplier". Lingli, have I got your point? > + In Section 3.2.4, ?a PPStream peer selects peers to download sub-chunks > from according to a rate-based algorithm? should be change into ?a PPStream > peer selects peers to download sub-chunks according to a rate-based > algorithm? --> done > + In Section 3.1.5, ?As already said, Tribler supports video streaming in > two different forms: video on demand and live streaming.? Is better to be > changed into ?Tribler supports video streaming in two different forms: > video on demand and live streaming.?, since there is no prior statement in > the draft. --> done > + Also in Section 3.1.5, ?Such a mechanism allows Tribler peers to use the > public key included in torrent file and verity the integrity of each > chunk.? should be changed into ?Such a mechanism allows Tribler peers to > use the public key included in torrent file and verify the integrity of > each chunk.? --> Lingli, I think your comment after the subsequent one is > correct. So I completely removed this part. See my observation later on. Do > you agree? > + There is considerable reference and comparison to the Bitorrent > system/model in the Tribler?s subsection, one may wonder why not pose a > separate section for introduction of Bittorrent instead? Lingli, I don't > think this is the case, because Bit Torrent is a P2P file sharing system > and I have the impression that a section devoted to a P2P file sharing > system could appear somehow out of scope. In addition, every time Bit > Torrent is cited, we always tried to provide the necessary background info. > Does it make sense? > + It is noticeable that both the Tribler?s peer selection algorithm and > security mechanisms are elaborated in such a detailed way? What about other > systems in terms of similar design issues? Since Section 3 is focus mainly > on the peer topology, maybe separate sections on algorithm/security are > more natural for better compression. --> Lingli, the main problem here is > that such a level of detail is often not available for all the > applications. Regarding this point I also added the following statement in > "Introduction" section "In addition, the provided descriptions may > sometimes appear inhomogeneous from the detail level point of view, but > this always depends on the amount of available information at writing > time.". So the only solution seems to me to remove the reference to the > security mechanisms. The peer selection algorithm is full part of the peer > protocol in my opinion and it has to be kept. But i would like to hear from > you. > + In Section 3.1.6, what does it mean by ?not RTP/RTCP? in ?the client use > UDP to transfer the encrypted media streaming and not RTP/ RTCP.?? --> > Duan, if I remember correctly, you provided this part. Can you please > explain? > + In Section 3.3.1, ?Parent re-selection is also applied in case of > leaving of the previous parent.? Is better to be changed into ?Parent > re-selection is also triggered for a peer when its previous parent leaves.? > --> done > + From the description in Section 3.3.1, it is not clear to me why the > QQLive?s topology is a hybrid of mesh and tree. --> Lingli, this comment > is not completely clear for me. Probably you meant New Coolstreaming. If > so, New Coolstreaming may be regarded as hybrid, because on the one side > you have an overlay mesh, on the other side you have as many trees as > substreams. I also added the following statement "Hence, the overall > overlay topology is mesh-based, but it is also possible to identify as many > overlay trees as sub-streams.". Is it clearer now? > > > Please, let me know. > > Regards > Francesca > > From: duan shihui duanshihui1201@gmail.com>> > Date: Monday, December 2, 2013 5:26 PM > To: "ppsp@ietf.org" ppsp@ietf.org>> > Subject: Re: [ppsp] WGLC for the survey draft > > Rachel, Roni Even and Lingli have given some good comments. > There are some errors in the survey draft which must be fixed. > when we written the survey draft, the RFC6972 is still in the draft > status. Now we can refer to RFC6972 for some definitions. > I will consider carefully some comments from Lingli and give the reply in > the subsequent mail. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/attachment.html > > > -------------- next part -------------- > An embedded and charset-unspecified text was scrubbed... > Name: PPSP survey figures.txt > URL: < > http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/attachment.txt > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Ppsp survey-flp0.4.docx > Type: > application/vnd.openxmlformats-officedocument.wordprocessingml.document > Size: 52889 bytes > Desc: Ppsp survey-flp0.4.docx > URL: < > http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/attachment.docx > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > > ------------------------------ > > End of ppsp Digest, Vol 63, Issue 2 > *********************************** > --20cf307f3adcd1626904ecb61806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+ In Section 3.1.6, what does i= t mean by ?not RTP/RTCP? in ?the client=20 use UDP to transfer the encrypted media streaming and not RTP/ RTCP.??=20 --> Duan, if I remember correctly, you provided this part. Can you=20 please explain?

yes, it's right= .
=A0the media is carried directly on the UDP and QQLive doesn't use= RTP/RTCP to carry the media. There is no RTP/RTCP in QQLive's protocol= s.

On Wed,= Dec 4, 2013 at 7:08 PM, <ppsp-request@ietf.org> wrote:=

Send ppsp mailing list submissions to
=A0 =A0 =A0 =A0 ppsp@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/ppsp
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0 ppsp-request@ietf.= org

You can reach the person managing the list at
=A0 =A0 =A0 =A0 ppsp-owner@ietf.org<= /a>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ppsp digest..."

Today's Topics:

=A0 =A01. Re: WGLC for the survey draft (Francesca Lo Piccolo (flopicco))

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

Message: 1
Date: Wed, 4 Dec 2013 11:08:33 +0000
From: "Francesca Lo Piccolo (flopicco)" <flopicco@cisco.com>
To: Zongning <zongning@huawei.com= >, duan <duanshihui@catr.cn= >,
=A0 =A0 =A0 =A0 "'yunfei zhang'" <hishigh@gmail.com>, Gu Yingjie
=A0 =A0 =A0 =A0 <guyingjie@gmail.= com>, lingli deng <dengli= ngli@gmail.com>
Cc: "ppsp@ietf.org" <ppsp@ietf.org>
Subject: Re: [ppsp] WGLC for the survey draft
Message-ID: <CEC4= BA67.18160%flopicco@cisco.com>
Content-Type: text/plain; charset=3D"windows-1252"

Duan and all,

I absolutely agree with you on the good quality of received feedback and on= the necessity to fix some parts in the survey draft.

To this end, I'm attaching a new revision of the survey (and also of th= e pictures), where most of the comments from Rachel, Roni and Lingli have b= een already taken into account.

Here is a summary of all the received comments, with the ones still open hi= ghlighted in red. Lingli, you are among the "to" receivers, becau= se there is some your comment I would like to further discuss with you.

Rachel
---------
+ The description in the last paragraph of Section 1 is inconsistent with t= he organization of chapters . This should be fixed. --> Ning, is it poss= ible to turn section 3.1 (and subsections) into section 4 and 3.2 (and subs= ections) in section 5 and 3.3 (and subsections) in section 6?
+ In section 2, some terminologies have already defined in RFC6972. It?s un= necessary to repeat the definition, e.g., chunk, live streaming? --> don= e
+ Section 1 typo: ?we always try to identity tracker and peer protocols? sh= ould be ?we always try to identify tracker and peer protocols? --> done<= br> + Section 3.1, typo ?this may turn at end users into playback quality degra= dation? should be ?this may turn end users into playback quality degradatio= n? --> done
+ It?s better to adjust the order of types of P2P streaming applications to= be consistent with the order of subsections, which means ?mesh-based? shou= ld be first, then ?tree-based?. --> done

Roni
------
+ Figure 1 ?traker? should be ?tracker? =A0--> done
+ In section 3.1.2 on PPLive change ?being the nature of PPLive protocols a= nd algorithm proprietary? to ? Since the protocols and algorithm of PPLIVE = are proprietary? =A0--> done
+ In section 3.1.3 ? Authentication server is the first point of contact fo= r a peer the joins the system? to ?Authentication server is the first point= of contact for a peer that joins the system? --> done
+ In section 3.1.3 ? can contact new more peers besides the ones indicated = by the rendezvous server? to ?can contact new peers besides the ones indica= ted by the rendezvous server? --> done
+ In section 3.1.5 ?Since children could lie regarding the number of chunks= forwarded to others, Tribler peers do directly not ask their children, but= their grandchildren.? To ?Since children could lie regarding the number of= chunks forwarded to others, Tribler peers do not ask their children direct= ly, but their grandchildren.? --> done
+ In section 3.1.6 when first using CDN expand to Content Delivery Network = (CDN) --> done

Lingli
-------
+ it states as a "standard track" document, is that accurate? --&= gt; Ning, we already discussed about this. As per your comment, this docume= nt should be ?informational?, rather than ?standard track?. I assume this i= s something you can take into account as soon as you will submit the final = revision, right?
+ in terminoloy section, "push" is defined as "Transmission = of multimedia content without any request from receiving peers.", whic= h I think could be better described as "Transmission of multimedia con= tent that is not initiated by receiving peers." --> done
+ In section 3, "the topology that can be associated with overlay conn= ections among peers" could be rephrased into "the topology of ove= rlay connections among peers". =A0--> done
+ Also in section 3, "pull-based data delivery calls for large size bu= ffers where to store chunks" could be rephrased into "pull-based = data delivery calls for large size buffers to store chunks". --> do= ne
+ "buffer-maps" are used to refer to "chunk availability inf= ormation" (as used by RFC 6972). For sake of consistency, I think it i= s better to use the latter instead. --> I re-phrased "in some appli= cations peers exchange chunk availability information in form of buffer-map= s (a sort of bit maps with a bit "1" in correspondence of chunks = stored in the local buffer)". Lingli, have I got your point?
+ In Section 3.2.1 ?channel server, that provides the list of available cha= nnels (live TV or VoD content) to a PPLive, as soon as the peer joins the s= ystem;? should be ?channel server, that provides the list of available chan= nels (live TV or VoD content) to a PPLive peer, as soon as the peer joins t= he system;? --> done
+ It seems to me that the content server may have played some sort of track= er?s role in Octoshape, otherwise, how would a joining peer gets to know th= e initial address book of other peers? --> done
+ In Section 3.2.3, ?a mechanism very similar to the one of TCP congestion = window (double increase or linear increase depending on whether the estimat= e is below or a given threshold)?, should be like ?a mechanism very similar= to the one of TCP congestion window (double increase or linear increase de= pending on whether the estimate is below or above a given threshold)? -->= ; done
+ One may be curious about what is the difference between a ?repeater node?= and a ?simple peer?, as the description of a ?repeater node? goes like ?Re= peater nodes, that serve as bandwidth multiplier, are able to forward any s= ub-stream and implement the same peer protocol as simple peers.? =A0--> = I re-phrased "simple peers, whose behavior has already been presented,= and repeater nodes, that implement the same peer protocol as simple peers = and in addition are high-bandwidth peers and are able to forward any sub-st= ream. In such a way repeater nodes serve as bandwidth multiplier". =A0= Lingli, have I got your point?
+ In Section 3.2.4, ?a PPStream peer selects peers to download sub-chunks f= rom according to a rate-based algorithm? should be change into ?a PPStream = peer selects peers to download sub-chunks according to a rate-based algorit= hm? =A0--> done
+ In Section 3.1.5, ?As already said, Tribler supports video streaming in t= wo different forms: video on demand and live streaming.? Is better to be ch= anged into ?Tribler supports video streaming in two different forms: video = on demand and live streaming.?, since there is no prior statement in the dr= aft. --> done
+ Also in Section 3.1.5, ?Such a mechanism allows Tribler peers to use the = public key included in torrent file and verity the integrity of each chunk.= ? should be changed into ?Such a mechanism allows Tribler peers to use the = public key included in torrent file and verify the integrity of each chunk.= ? --> Lingli, I think your comment after the subsequent one is correct. = So I completely removed this part. See my observation later on. Do you agre= e?
+ There is considerable reference and comparison to the Bitorrent system/mo= del in the Tribler?s subsection, one may wonder why not pose a separate sec= tion for introduction of Bittorrent instead? Lingli, I don't think this= is the case, because Bit Torrent is a P2P file sharing system and I have t= he impression that a section devoted to a P2P file sharing system could app= ear somehow out of scope. In addition, every time Bit Torrent is cited, we = always tried to provide the necessary background info. Does it make sense?<= br> + It is noticeable that both the Tribler?s peer selection algorithm and sec= urity mechanisms are elaborated in such a detailed way? What about other sy= stems in terms of similar design issues? Since Section 3 is focus mainly on= the peer topology, maybe separate sections on algorithm/security are more = natural for better compression. --> Lingli, the main problem here is tha= t such a level of detail is often not available for all the applications. R= egarding this point I also added the following statement in "Introduct= ion" section "In addition, the provided descriptions may sometime= s appear inhomogeneous from the detail level point of view, but this always= depends on the amount of available information at writing time.". =A0= So the only solution seems to me to remove the reference to the security me= chanisms. The peer selection algorithm is full part of the peer protocol in= my opinion and it has to be kept. But i would like to hear from you.
+ In Section 3.1.6, what does it mean by ?not RTP/RTCP? in ?the client use = UDP to transfer the encrypted media streaming and not RTP/ RTCP.?? --> D= uan, if I remember correctly, you provided this part. Can you please explai= n?
+ In Section 3.3.1, ?Parent re-selection is also applied in case of leaving= of the previous parent.? Is better to be changed into ?Parent re-selection= is also triggered for a peer when its previous parent leaves.? --> done=
+ From the description in Section 3.3.1, it is not clear to me why the QQLi= ve?s topology is a hybrid of mesh and tree. =A0--> Lingli, this comment = is not completely clear for me. Probably you meant New Coolstreaming. If so= , New Coolstreaming may be regarded as hybrid, because on the one side you = have an overlay mesh, on the other side you have as many trees as substream= s. I also added the following statement "Hence, the overall overlay to= pology is mesh-based, but it is also possible to identify as many overlay t= rees as sub-streams.". Is it clearer now?

Please, let me know.

Regards
Francesca

From: duan shihui <duanshihu= i1201@gmail.com<mailto:d= uanshihui1201@gmail.com>>
Date: Monday, December 2, 2013 5:26 PM
To: "ppsp@ietf.org<mailto:ppsp@ietf.org>" <ppsp@ietf.org<mailto:ppsp@ietf.org>>
Subject: Re: [ppsp] WGLC for the survey draft

Rachel, Roni Even and Lingli have given some good comments.
There are some errors in the survey draft which must be fixed.
when we written the survey draft, the RFC6972 is still in the draft status.= Now we can refer to RFC6972 for some definitions.
I will consider carefully some comments from Lingli and give the reply in t= he subsequent mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mai= l-archive/web/ppsp/attachments/20131204/71d03347/attachment.html> -------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PPSP survey figures.txt
URL: <http://www.ietf.org/mail= -archive/web/ppsp/attachments/20131204/71d03347/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ppsp survey-flp0.4.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.docume= nt
Size: 52889 bytes
Desc: Ppsp survey-flp0.4.docx
URL: <http://www.ietf.org/mai= l-archive/web/ppsp/attachments/20131204/71d03347/attachment.docx>
------------------------------

Subject: Digest Footer

_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

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

End of ppsp Digest, Vol 63, Issue 2
***********************************

--20cf307f3adcd1626904ecb61806-- From denglingli@gmail.com Wed Dec 4 18:50:32 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905471AE33E for ; Wed, 4 Dec 2013 18:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.151 X-Spam-Level: *** X-Spam-Status: No, score=3.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34dEQgn8c3U9 for ; Wed, 4 Dec 2013 18:50:24 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 1891C1AE32C for ; Wed, 4 Dec 2013 18:50:23 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id hz11so12433631vcb.31 for ; Wed, 04 Dec 2013 18:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sgUWoBwHo8Ofm2or1+o/ACXMC9jTbO0Um25Pf2jEtII=; b=zbRDUZGa82DZHObgBtauqssJEqVx/LFdN3RL+DfLbPCkPy9vcXYuv2Hfhdmqh4KOtE Ti6eiZO2ZOXoMShP+iZGR6KkHOyR7gRsog9oDkLrOtQo6OFoC4PdVWa46a+k0FGFXuU5 GfF5cjktEn7aZfXrJcf5IxtnAC72OGbjZS0qPvkNgxQ+PS1EVZZ4132Vn+1TqNBiEfx+ 7Taxsdere0kRtI1cHTidCrqkngfdJ3AxlZnv/p7UPYBjiUQShjVIY/4hk9EJKuOnVu+m ra1gzOlY5a1/sQEjsxCfDWmtqTNnZAza3OG7XwjOFsxNE/cvVTcawCj7ho6llLFaG3HJ JhxA== MIME-Version: 1.0 X-Received: by 10.58.246.136 with SMTP id xw8mr56938vec.41.1386211820626; Wed, 04 Dec 2013 18:50:20 -0800 (PST) Received: by 10.58.118.130 with HTTP; Wed, 4 Dec 2013 18:50:20 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Dec 2013 10:50:20 +0800 Message-ID: From: lingli deng To: "Francesca Lo Piccolo (flopicco)" Content-Type: multipart/alternative; boundary=047d7bdc869e275aaf04ecc0970f Cc: Gu Yingjie , duan , "ppsp@ietf.org" Subject: Re: [ppsp] WGLC for the survey draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2013 02:50:32 -0000 --047d7bdc869e275aaf04ecc0970f Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Francesca, Thank you for the quick response. I think most of the issues are addressed, except the security mechanisms. (Inline comments are also included below^^) The concern here is that I think security considerations is also important. Would it be possible to feed relevant content into =A1=B0security considerations=A1=B1 rather than simple removal? BR Lingli *=B7=A2=BC=FE=C8=CB:* ppsp [mailto:ppsp-bounces@ietf.org] *=B4=FA=B1=ED *Fr= ancesca Lo Piccolo (flopicco) *=B7=A2=CB=CD=CA=B1=BC=E4:* 2013=C4=EA12=D4=C24=C8=D5 19:09 *=CA=D5=BC=FE=C8=CB:* Zongning; duan; 'yunfei zhang'; Gu Yingjie; lingli de= ng *=B3=AD=CB=CD:* ppsp@ietf.org *=D6=F7=CC=E2:* Re: [ppsp] WGLC for the survey draft Duan and all, I absolutely agree with you on the good quality of received feedback and on the necessity to fix some parts in the survey draft. To this end, I'm attaching a new revision of the survey (and also of the pictures), where most of the comments from Rachel, Roni and Lingli have been already taken into account. Here is a summary of all the received comments, with the ones still open highlighted in red. Lingli, you are among the "to" receivers, because there is some your comment I would like to further discuss with you. Rachel --------- + The description in the last paragraph of Section 1 is inconsistent with the organization of chapters . This should be fixed. --> Ning, is it possible to turn section 3.1 (and subsections) into section 4 and 3.2 (and subsections) in section 5 and 3.3 (and subsections) in section 6? + In section 2, some terminologies have already defined in RFC6972. It=A1= =AFs unnecessary to repeat the definition, e.g., chunk, live streaming=A1=AD -->= done + Section 1 typo: =A1=B0we always try to identity tracker and peer protocol= s=A1=B1 should be =A1=B0we always try to identify tracker and peer protocols=A1=B1 = --> done + Section 3.1, typo =A1=B0this may turn at end users into playback quality degradation=A1=B1 should be =A1=B0this may turn end users into playback qua= lity degradation=A1=B1 --> done + It=A1=AFs better to adjust the order of types of P2P streaming applicatio= ns to be consistent with the order of subsections, which means =A1=B0mesh-based= =A1=B1 should be first, then =A1=B0tree-based=A1=B1. --> done Roni ------ + Figure 1 =A1=B0traker=A1=B1 should be =A1=B0tracker=A1=B1 --> done + In section 3.1.2 on PPLive change =A1=B0being the nature of PPLive protoc= ols and algorithm proprietary=A1=B1 to =A1=B0 Since the protocols and algorithm= of PPLIVE are proprietary=A1=B1 --> done + In section 3.1.3 =A1=B0 Authentication server is the first point of conta= ct for a peer the joins the system=A1=B1 to =A1=B0Authentication server is the= first point of contact for a peer that joins the system=A1=B1 --> done + In section 3.1.3 =A1=B0 can contact new more peers besides the ones indic= ated by the rendezvous server=A1=B1 to =A1=B0can contact new peers besides the o= nes indicated by the rendezvous server=A1=B1 --> done + In section 3.1.5 =A1=B0Since children could lie regarding the number of c= hunks forwarded to others, Tribler peers do directly not ask their children, but their grandchildren.=A1=B1 To =A1=B0Since children could lie regarding the = number of chunks forwarded to others, Tribler peers do not ask their children directly, but their grandchildren.=A1=B1 --> done + In section 3.1.6 when first using CDN expand to Content Delivery Network (CDN) --> done Lingli ------- + it states as a "standard track" document, is that accurate? --> Ning, we already discussed about this. As per your comment, this document should be =A1=B0informational=A1=B1, rather than =A1=B0standard track=A1=B1. I assume= this is something you can take into account as soon as you will submit the final revision, right? + in terminoloy section, "push" is defined as "Transmission of multimedia content without any request from receiving peers.", which I think could be better described as "Transmission of multimedia content that is not initiated by receiving peers." --> done + In section 3, "the topology that can be associated with overlay connections among peers" could be rephrased into "the topology of overlay connections among peers". --> done + Also in section 3, "pull-based data delivery calls for large size buffers where to store chunks" could be rephrased into "pull-based data delivery calls for large size buffers to store chunks". --> done + "buffer-maps" are used to refer to "chunk availability information" (as used by RFC 6972). For sake of consistency, I think it is better to use the latter instead. --> I re-phrased "in some applications peers exchange chunk availability information in form of buffer-maps (a sort of bit maps with a bit "1" in correspondence of chunks stored in the local buffer)". Lingli, have I got your point? [dll] Yes. I am OK with this. + In Section 3.2.1 =A1=B0channel server, that provides the list of availabl= e channels (live TV or VoD content) to a PPLive, as soon as the peer joins the system;=A1=B1 should be =A1=B0channel server, that provides the list of= available channels (live TV or VoD content) to a PPLive peer, as soon as the peer joins the system;=A1=B1 --> done + It seems to me that the content server may have played some sort of tracker=A1=AFs role in Octoshape, otherwise, how would a joining peer gets = to know the initial address book of other peers? --> done + In Section 3.2.3, =A1=B0a mechanism very similar to the one of TCP conges= tion window (double increase or linear increase depending on whether the estimate is below or a given threshold)=A1=B1, should be like =A1=B0a mecha= nism very similar to the one of TCP congestion window (double increase or linear increase depending on whether the estimate is below or above a given threshold)=A1=B1 --> done + One may be curious about what is the difference between a =A1=B0repeater = node=A1=B1 and a =A1=B0simple peer=A1=B1, as the description of a =A1=B0repeater node= =A1=B1 goes like =A1=B0Repeater nodes, that serve as bandwidth multiplier, are able to forwa= rd any sub-stream and implement the same peer protocol as simple peers.=A1=B1 = --> I re-phrased "simple peers, whose behavior has already been presented, and repeater nodes, that implement the same peer protocol as simple peers and in addition are high-bandwidth peers and are able to forward any sub-stream. In such a way repeater nodes serve as bandwidth multiplier". Lingli, have I got your point? [dll] Yes. It works for me. + In Section 3.2.4, =A1=B0a PPStream peer selects peers to download sub-chu= nks from according to a rate-based algorithm=A1=B1 should be change into =A1=B0= a PPStream peer selects peers to download sub-chunks according to a rate-based algorithm=A1=B1 --> done + In Section 3.1.5, =A1=B0As already said, Tribler supports video streaming= in two different forms: video on demand and live streaming.=A1=B1 Is better to= be changed into =A1=B0Tribler supports video streaming in two different forms: video on demand and live streaming.=A1=B1, since there is no prior statemen= t in the draft. --> done + Also in Section 3.1.5, =A1=B0Such a mechanism allows Tribler peers to use= the public key included in torrent file and verity the integrity of each chunk.=A1=B1 should be changed into =A1=B0Such a mechanism allows Tribler p= eers to use the public key included in torrent file and verify the integrity of each chunk.=A1=B1 --> Lingli, I think your comment after the subsequent one= is correct. So I completely removed this part. See my observation later on. Do you agree? [dll] Plz see my comment below. + There is considerable reference and comparison to the Bitorrent system/model in the Tribler=A1=AFs subsection, one may wonder why not pose = a separate section for introduction of Bittorrent instead? Lingli, I don't think this is the case, because Bit Torrent is a P2P file sharing system and I have the impression that a section devoted to a P2P file sharing system could appear somehow out of scope. In addition, every time Bit Torrent is cited, we always tried to provide the necessary background info. Does it make sense? [dll] You are right, since Bittorent is not a streaming system, it seems out of scope. It is a bad idea, forget it. + It is noticeable that both the Tribler=A1=AFs peer selection algorithm an= d security mechanisms are elaborated in such a detailed way? What about other systems in terms of similar design issues? Since Section 3 is focus mainly on the peer topology, maybe separate sections on algorithm/security are more natural for better compression. --> Lingli, the main problem here is that such a level of detail is often not available for all the applications. Regarding this point I also added the following statement in "Introduction" section "In addition, the provided descriptions may sometimes appear inhomogeneous from the detail level point of view, but this always depends on the amount of available information at writing time.= ". So the only solution seems to me to remove the reference to the security mechanisms. The peer selection algorithm is full part of the peer protocol in my opinion and it has to be kept. But i would like to hear from you. [dll] I see your point. However, I would not agree that security is not as important as peer selection algorithm. Would it be possible to feed it into =A1=B0security considerations=A1=B1? + In Section 3.1.6, what does it mean by =A1=B0not RTP/RTCP=A1=B1 in =A1=B0= the client use UDP to transfer the encrypted media streaming and not RTP/ RTCP.=A1=B1? --> Duan, if I remember correctly, you provided this part. Can you please explain? + In Section 3.3.1, =A1=B0Parent re-selection is also applied in case of le= aving of the previous parent.=A1=B1 Is better to be changed into =A1=B0Parent re-= selection is also triggered for a peer when its previous parent leaves.=A1=B1 --> don= e + From the description in Section 3.3.1, it is not clear to me why the QQLive=A1=AFs topology is a hybrid of mesh and tree. --> Lingli, this comm= ent is not completely clear for me. Probably you meant New Coolstreaming. If so, New Coolstreaming may be regarded as hybrid, because on the one side you have an overlay mesh, on the other side you have as many trees as substreams. I also added the following statement "Hence, the overall overlay topology is mesh-based, but it is also possible to identify as many overlay trees as sub-streams.". Is it clearer now? [dll] Sorry for the typo, I did mean New Coolstreaming. I am fine with the clarification. 2013/12/4 Francesca Lo Piccolo (flopicco) > Duan and all, > > I absolutely agree with you on the good quality of received feedback and > on the necessity to fix some parts in the survey draft. > > To this end, I'm attaching a new revision of the survey (and also of the > pictures), where most of the comments from Rachel, Roni and Lingli have > been already taken into account. > > Here is a summary of all the received comments, with the ones still open > highlighted in red. Lingli, you are among the "to" receivers, because the= re > is some your comment I would like to further discuss with you. > > Rachel > --------- > + The description in the last paragraph of Section 1 is inconsistent > with the organization of chapters . This should be fixed. --> Ning, is it > possible to turn section 3.1 (and subsections) into section 4 and 3.2 (an= d > subsections) in section 5 and 3.3 (and subsections) in section 6? > + In section 2, some terminologies have already defined in RFC6972. It= =A1=AFs > unnecessary to repeat the definition, e.g., chunk, live streaming=A1=AD -= -> done > + Section 1 typo: =A1=B0we always try to identity tracker and peer proto= cols=A1=B1 > should be =A1=B0we always try to identify tracker and peer protocols=A1= =B1 --> done > + Section 3.1, typo =A1=B0this may turn at end users into playback quali= ty > degradation=A1=B1 should be =A1=B0this may turn end users into playback q= uality > degradation=A1=B1 --> done > + It=A1=AFs better to adjust the order of types of P2P streaming applica= tions > to be consistent with the order of subsections, which means =A1=B0mesh-ba= sed=A1=B1 > should be first, then =A1=B0tree-based=A1=B1. --> done > > Roni > ------ > + Figure 1 =A1=B0traker=A1=B1 should be =A1=B0tracker=A1=B1 --> done > + In section 3.1.2 on PPLive change =A1=B0being the nature of PPLive prot= ocols > and algorithm proprietary=A1=B1 to =A1=B0 Since the protocols and algorit= hm of PPLIVE > are proprietary=A1=B1 --> done > + In section 3.1.3 =A1=B0 Authentication server is the first point of con= tact > for a peer the joins the system=A1=B1 to =A1=B0Authentication server is t= he first > point of contact for a peer that joins the system=A1=B1 --> done > + In section 3.1.3 =A1=B0 can contact new more peers besides the ones ind= icated > by the rendezvous server=A1=B1 to =A1=B0can contact new peers besides the= ones > indicated by the rendezvous server=A1=B1 --> done > + In section 3.1.5 =A1=B0Since children could lie regarding the number of > chunks forwarded to others, Tribler peers do directly not ask their > children, but their grandchildren.=A1=B1 To =A1=B0Since children could li= e regarding > the number of chunks forwarded to others, Tribler peers do not ask their > children directly, but their grandchildren.=A1=B1 --> done > + In section 3.1.6 when first using CDN expand to Content Delivery Networ= k > (CDN) --> done > > > Lingli > ------- > + it states as a "standard track" document, is that accurate? --> Ning, > we already discussed about this. As per your comment, this document shoul= d > be =A1=B0informational=A1=B1, rather than =A1=B0standard track=A1=B1. I a= ssume this is > something you can take into account as soon as you will submit the final > revision, right? > + in terminoloy section, "push" is defined as "Transmission of multimedi= a > content without any request from receiving peers.", which I think could b= e > better described as "Transmission of multimedia content that is not > initiated by receiving peers." --> done > + In section 3, "the topology that can be associated with > overlay connections among peers" could be rephrased into "the topology of > overlay connections among peers". --> done > + Also in section 3, "pull-based data delivery calls for large size > buffers where to store chunks" could be rephrased into "pull-based data > delivery calls for large size buffers to store chunks". --> done > + "buffer-maps" are used to refer to "chunk availability information" (as > used by RFC 6972). For sake of consistency, I think it is better to use t= he > latter instead. --> I re-phrased "in some applications peers exchange chu= nk > availability information in form of buffer-maps (a sort of bit maps with = a > bit "1" in correspondence of chunks stored in the local buffer)". Lingli, > have I got your point? > + In Section 3.2.1 =A1=B0channel server, that provides the list of avail= able > channels (live TV or VoD content) to a PPLive, as soon as the peer joins > the system;=A1=B1 should be =A1=B0channel server, that provides the list = of available > channels (live TV or VoD content) to a PPLive peer, as soon as the peer > joins the system;=A1=B1 --> done > + It seems to me that the content server may have played some sort of > tracker=A1=AFs role in Octoshape, otherwise, how would a joining peer get= s to > know the initial address book of other peers? --> done > + In Section 3.2.3, =A1=B0a mechanism very similar to the one of TCP > congestion window (double increase or linear increase depending on whethe= r > the estimate is below or a given threshold)=A1=B1, should be like =A1=B0a= mechanism > very similar to the one of TCP congestion window (double increase or line= ar > increase depending on whether the estimate is below or above a given > threshold)=A1=B1 --> done > + One may be curious about what is the difference between a =A1=B0repeate= r > node=A1=B1 and a =A1=B0simple peer=A1=B1, as the description of a =A1=B0r= epeater node=A1=B1 goes > like =A1=B0Repeater nodes, that serve as bandwidth multiplier, are able t= o > forward any sub-stream and implement the same peer protocol as simple > peers.=A1=B1 --> I re-phrased "simple peers, whose behavior has already = been > presented, and repeater nodes, that implement the same peer protocol as > simple peers and in addition are high-bandwidth peers and are able to > forward any sub-stream. In such a way repeater nodes serve as bandwidth > multiplier". Lingli, have I got your point? > + In Section 3.2.4, =A1=B0a PPStream peer selects peers to download sub-= chunks > from according to a rate-based algorithm=A1=B1 should be change into =A1= =B0a PPStream > peer selects peers to download sub-chunks according to a rate-based > algorithm=A1=B1 --> done > + In Section 3.1.5, =A1=B0As already said, Tribler supports video stream= ing in > two different forms: video on demand and live streaming.=A1=B1 Is better = to be > changed into =A1=B0Tribler supports video streaming in two different form= s: > video on demand and live streaming.=A1=B1, since there is no prior statem= ent in > the draft. --> done > + Also in Section 3.1.5, =A1=B0Such a mechanism allows Tribler peers to u= se the > public key included in torrent file and verity the integrity of each > chunk.=A1=B1 should be changed into =A1=B0Such a mechanism allows Tribler= peers to > use the public key included in torrent file and verify the integrity of > each chunk.=A1=B1 --> Lingli, I think your comment after the subsequent o= ne is > correct. So I completely removed this part. See my observation later on. = Do > you agree? > + There is considerable reference and comparison to the Bitorrent > system/model in the Tribler=A1=AFs subsection, one may wonder why not pos= e a > separate section for introduction of Bittorrent instead? Lingli, I don't > think this is the case, because Bit Torrent is a P2P file sharing system > and I have the impression that a section devoted to a P2P file sharing > system could appear somehow out of scope. In addition, every time Bit > Torrent is cited, we always tried to provide the necessary background inf= o. > Does it make sense? > + It is noticeable that both the Tribler=A1=AFs peer selection algorithm = and > security mechanisms are elaborated in such a detailed way? What about oth= er > systems in terms of similar design issues? Since Section 3 is focus mainl= y > on the peer topology, maybe separate sections on algorithm/security are > more natural for better compression. --> Lingli, the main problem here is > that such a level of detail is often not available for all the > applications. Regarding this point I also added the following statement i= n > "Introduction" section "In addition, the provided descriptions may > sometimes appear inhomogeneous from the detail level point of view, but > this always depends on the amount of available information at writing tim= e.". > So the only solution seems to me to remove the reference to the security > mechanisms. The peer selection algorithm is full part of the peer protoco= l > in my opinion and it has to be kept. But i would like to hear from you. > + In Section 3.1.6, what does it mean by =A1=B0not RTP/RTCP=A1=B1 in =A1= =B0the client use > UDP to transfer the encrypted media streaming and not RTP/ RTCP.=A1=B1? -= -> > Duan, if I remember correctly, you provided this part. Can you please > explain? > + In Section 3.3.1, =A1=B0Parent re-selection is also applied in case of > leaving of the previous parent.=A1=B1 Is better to be changed into =A1=B0= Parent > re-selection is also triggered for a peer when its previous parent leaves= .=A1=B1 > --> done > + From the description in Section 3.3.1, it is not clear to me why the > QQLive=A1=AFs topology is a hybrid of mesh and tree. --> Lingli, this co= mment > is not completely clear for me. Probably you meant New Coolstreaming. If > so, New Coolstreaming may be regarded as hybrid, because on the one side > you have an overlay mesh, on the other side you have as many trees as > substreams. I also added the following statement "Hence, the overall > overlay topology is mesh-based, but it is also possible to identify as ma= ny > overlay trees as sub-streams.". Is it clearer now? > > > Please, let me know. > > Regards > Francesca > > From: duan shihui > Date: Monday, December 2, 2013 5:26 PM > To: "ppsp@ietf.org" > > Subject: Re: [ppsp] WGLC for the survey draft > > Rachel, *Roni Even* and Lingli have given some good comments. > There are some errors in the survey draft which must be fixed. > when we written the survey draft, the RFC6972 is still in the draft > status. Now we can refer to RFC6972 for some definitions. > I will consider carefully some comments from Lingli and give the reply > in the subsequent mail. > --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --047d7bdc869e275aaf04ecc0970f Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi Francesca,

T= hank you for the quick response.

I think most of the issues are= addressed, except the security mechanisms. (Inline comments are also inclu= ded below^^)

The= concern here is that I think security considerations is also importan= t. Would it be possible to feed relevant content into “sec= urity considerations” rather than simple removal?

Lin= gli

=B7=A2=BC=FE=C8=CB: ppsp [m= ailto:ppsp-bounc= es@ietf.org] =B4=FA=B1=ED Francesca Lo Piccolo (flopicco)
=B7=A2=CB= =CD=CA=B1=BC=E4: 2013=C4=EA12<= /span>=D4=C24=C8=D5 19:09<= br> =CA=D5=BC=FE=C8=CB: Zongning; duan; 'yunfei zhang'; Gu Yingjie; lingli deng
= =B3=AD=CB=CD: ppsp@ietf.org
=D6=F7=CC=E2: Re: [ppsp] WGLC for the survey draft

Duan and all,

I absolutely agree with you on the good quality of received feedback a= nd on the necessity to fix some parts in the survey draft.

To this end, I'm attaching a new revision of the survey (and also = of the pictures), where most of the comments from Rachel, Roni and Lin= gli have been already taken into account.

Here is a summary of all the received comments, with the ones still op= en highlighted in red. Lingli, you are among the "to" receivers, = because there is some your comment I would like to further discuss with you= .

Rachel

---------<= /u>

+ The description in the last paragraph of = Section 1 is inconsistent with the organization of chapters . This should b= e fixed. --> Ning, is it possible to turn section 3.1 (and subsections) = into section 4 and 3.2 (and subsections) in section 5 and 3.= 3 (and subsections) in section 6?

+ In section = 2, some terminologies have already defined in RFC6972. It’s unnecessa= ry to repeat the definition, e.g., chunk, live streaming… --> don= e

+ Section 1 t= ypo: “we always try to identity tracker and peer protocols” sho= uld be “we always try to identify tracker and peer protocols” -= -> done

+ Section 3.1= , typo “this may turn at end users into playback quality degradation&= rdquo; should be “this may turn end users into playback quality degra= dation” --> done

+ It&rsq= uo;s better to adjust the order of types of P2P streaming applications to b= e consistent with the order of subsections, which means “mesh-based&r= dquo; should be first, then “tree-based”. --> done

Roni

------=

+ Figure 1 “traker” should be “tracker”&n= bsp; --> done

+ In section = 3.1.2 on PPLive change “being the nature of PPLive protocols and algo= rithm proprietary” to “ Since the protocols and algorithm of PP= LIVE are proprietary” --> done

+ In section = 3.1.3 “ Authentication server is the first point of contact for a pee= r the joins the system” to “Authentication server is the first = point of contact for a peer that joins the system” --> done

+ In section = 3.1.3 “ can contact new more peers besides the ones indicated by the = rendezvous server” to “can contact new peers besides the ones i= ndicated by the rendezvous server” --> done

+ In section = 3.1.5 “Since children could lie regarding the number of chunks forwar= ded to others, Tribler peers do directly not ask their children, but their = grandchildren.” To “Since children could lie regarding the numb= er of chunks forwarded to others, Tribler peers do not ask their children d= irectly, but their grandchildren.” --> done

+ In section = 3.1.6 when first using CDN expand to Content Delivery Network (CDN) --= > done

Lingli=

-------

+ it states as a "st= andard track" document, is that accurate? --> Ning, we already disc= ussed about this. As per your comment, this document should be “= informational”, rather than “standard track”. I assume th= is is something you can take into account as soon as you will submit the fi= nal revision, right?

+ in terminol= oy section, "push" is defined as "Transmission of multimedia= content without any request from receiving peers.", which I think cou= ld be better described as "Transmission of multimedia content that is = not initiated by receiving peers." --> done

+ In section = 3, "the topology that can be associated with overlay connections = among peers" could be rephrased into "the topology of overlay con= nections among peers". --> done

+ Also in sec= tion 3, "pull-based data delivery calls for large size buffers where t= o store chunks" could be rephrased into "pull-based data delivery= calls for large size buffers to store chunks". --> done<= /u>

+ "buffer-maps" are = used to refer to "chunk availability information" (as used by RFC= 6972). For sake of consistency, I think it is better to use the latter ins= tead. --> I re-phrased "in some applications peers exchange chunk a= vailability information in form of buffer-maps (a sort of bit maps with a b= it "1" in correspondence of chunks stored in the local buffer)&qu= ot;. Lingli, have I got your point?

[dll] Yes. I am OK with this.

+ In Section 3.2.1 = “channel server, that provides the list of available channels (live T= V or VoD content) to a PPLive, as soon as the peer joins the system;”= should be “channel server, that provides the list of available chann= els (live TV or VoD content) to a PPLive peer, as soon as the peer joins th= e system;” --> done

+ It seems to= me that the content server may have played some sort of tracker’s ro= le in Octoshape, otherwise, how would a joining peer gets to know the initi= al address book of other peers? --> done

+ In Section = 3.2.3, “a mechanism very similar to the one of TCP congestion window = (double increase or linear increase depending on whether the estimate is be= low or a given threshold)”, should be like “a mechanism very si= milar to the one of TCP congestion window (double increase or linear increa= se depending on whether the estimate is below or above a given threshold)&r= dquo; --> done

+ One may be curious about what is the difference betw= een a “repeater node” and a “simple peer”, as the d= escription of a “repeater node” goes like “Repeater nodes= , that serve as bandwidth multiplier, are able to forward any sub-stream an= d implement the same peer protocol as simple peers.” --> I r= e-phrased "simple peers, whose behavior has already been presented, an= d repeater nodes, that implement the same peer protocol as simple peers and= in addition are high-bandwidth peers and are able to forward any sub-strea= m. In such a way repeater nodes serve as bandwidth multiplier". = Lingli, have I got your point?=

[dll] Yes. It works for me.

+ In Section 3.2.4,= “a PPStream peer selects peers to download sub-chunks from according= to a rate-based algorithm” should be change into “a PPStream p= eer selects peers to download sub-chunks according to a rate-based algorith= m” --> done

+ In Section = 3.1.5, “As already said, Tribler supports video streaming in two diff= erent forms: video on demand and live streaming.” Is better to be cha= nged into “Tribler supports video streaming in two different forms: v= ideo on demand and live streaming.”, since there is no prior statemen= t in the draft. --> done

+ Also in Section 3.1.5, “Such a mechanism allow= s Tribler peers to use the public key included in torrent file and verity t= he integrity of each chunk.” should be changed into “Such a mec= hanism allows Tribler peers to use the public key included in torrent file = and verify the integrity of each chunk.” --> Lingli, I think your = comment after the subsequent one is correct. So I completely removed this p= art. See my observation later on. Do you agree?

[dll] Plz see my comment below.

+ There is con= siderable reference and comparison to the Bitorrent system/model in the Tri= bler’s subsection, one may wonder why not pose a separate section for= introduction of Bittorrent instead? Lingli, I don't think this is the = case, because Bit Torrent is a P2P file sharing system and I have the impre= ssion that a section devoted to a P2P file sharing system could appear some= how out of scope. In addition, every time Bit Torrent is cited, we always t= ried to provide the necessary background info. Does it make sense?

[dll] You are right, since Bittorent is not a streaming system, it seems= out of scope. It is a bad idea, forget it.

+ It is noticeable that both the Tribler’s peer select= ion algorithm and security mechanisms are elaborated in such a detailed way= ? What about other systems in terms of similar design issues? Since Section= 3 is focus mainly on the peer topology, maybe separate sections on algorit= hm/security are more natural for better compression. --> Lingli, the mai= n problem here is that such a level of detail is often not available for al= l the applications. Regarding this point I also added the following stateme= nt in "Introduction" section "In= addition, the provided descriptions may sometimes appear inhomogeneous fro= m the detail level point of view, but this always depends on the amount of = available information at writing time.". So the only solution seems to me to remove the refere= nce to the security mechanisms. The peer selection algorithm is full part o= f the peer protocol in my opinion and it has to be kept. But i would like t= o hear from you.

[dll] I see your point. However, I would not agree that security is not = as important as peer selection algorithm. Would it be possible to feed it i= nto “security considerations”?

+ In Section 3.1.6, what does it mean by “not RTP/RTCP= ” in “the client use UDP to transfer the encrypted media stream= ing and not RTP/ RTCP.”? --> Duan, if I remember correctly, you pr= ovided this part. Can you please explain?

+ In Section = 3.3.1, “Parent re-selection is also applied in case of leaving of the= previous parent.” Is better to be changed into “Parent re-sele= ction is also triggered for a peer when its previous parent leaves.” = --> done

+ F= rom the description in Section 3.3.1, it is not clear to me why the QQLive&= rsquo;s topology is a hybrid of mesh and tree. --> Lingli, this co= mment is not completely clear for me. Probably you meant New Coolstreaming.= If so, New Coolstreaming may be regarded as hybrid, because on the on= e side you have an overlay mesh, on the other side you have as many trees a= s substreams. I also added the following statement "Hence, the overall= overlay topology is mesh-based, but it is also possible to identify as man= y overlay trees as sub-streams.". Is it clearer now?

&= nbsp;[dll] Sorry fo= r the typo, I did mean New Coolstreaming. I am fine with the clarification.=

2013/12/4 Francesca Lo Piccolo (flopicco) <flopicco@cisco.com>= ;

Duan and all,

I absolutely agree with you on the good quality of received feedback and on= the necessity to fix some parts in the survey draft.

To this end, I'm attaching a new revision of the survey (and also of th= e pictures), where most of the comments from Rachel, Roni and Lingli h= ave been already taken into account.

Here is a summary of all the received comments, with the ones still open hi= ghlighted in red. Lingli, you are among the "to" receivers, becau= se there is some your comment I would like to further discuss with you.

Rachel

---------

+ The description in the last paragraph of Section = 1 is inconsistent with the organization of chapters . This should be fixed.= --> Ning, is it possible to turn section 3.1 (and subsections) into sec= tion 4 and 3.2 (and subsections) in section 5 and 3.3 (and subsections) in section 6?

+ In section 2, some terminologies have already defined in RFC6972. It&rsqu= o;s unnecessary to repeat the definition, e.g., chunk, live streaming&helli= p; --> done

+ Section 1 typo: “we always try to identity tracker and peer protoco= ls” should be “we always try to identify tracker and peer proto= cols” --> done

+ Section 3.1, typo “this may turn at end users into playback quality= degradation” should be “this may turn end users into playback = quality degradation” --> done

+ It’s better to adjust the order of types of P2P streaming appl= ications to be consistent with the order of subsections, which means &ldquo= ;mesh-based” should be first, then “tree-based”. --&= gt; done

Roni

------

+ Figure 1 “traker” shou= ld be “tracker” --> done

+ In section 3.1.2 on PPLive change = “being the nature of PPLive protocols and algorithm proprietary&rdquo= ; to “ Since the protocols and algorithm of PPLIVE are proprietary&rd= quo; --> done

+ In section 3.1.3 “ Authentic= ation server is the first point of contact for a peer the joins the system&= rdquo; to “Authentication server is the first point of contact for a = peer that joins the system” --> done

+ In section 3.1.3 “ can conta= ct new more peers besides the ones indicated by the rendezvous server&rdquo= ; to “can contact new peers besides the ones indicated by the rendezv= ous server” --> done

+ In section 3.1.5 “Since chil= dren could lie regarding the number of chunks forwarded to others, Tribler = peers do directly not ask their children, but their grandchildren.” T= o “Since children could lie regarding the number of chunks forwarded to others, Tribler peers do not ask their children dir= ectly, but their grandchildren.” --> done

+ In section 3.1.6 when= first using CDN expand to Content Delivery Network (CDN) --> done=

Lingli=

-------

+ it states as a "standard track" document, is that acc= urate? --> Ning, we already discussed about this. As per your comment,&n= bsp;this document should be “informational”, rather than “standard track”. I assume this is something you can take= into account as soon as you will submit the final revision, right?<= /div>
+ in terminoloy section, "push" is defined as "Transmission = of multimedia content without any request from receiving peers.", whic= h I think could be better described as "Transmission of multimedia con= tent that is not initiated by receiving peers." --> done

+ In section 3, "the topology that can be associated with overlay = ;connections among peers" could be rephrased into "the topology o= f overlay connections among peers". --> done

+ Also in section 3, "pull-based data delivery calls for large size bu= ffers where to store chunks" could be rephrased into "pull-based = data delivery calls for large size buffers to store chunks". --> do= ne

+ "buffer-maps" are used to refer to "chunk availa= bility information" (as used by RFC 6972). For sake of consistency, I = think it is better to use the latter instead. --> I re-phrased "in some applications peers exchange chunk availability = information in form of buffer-maps (a sort of bit maps with a bit "1&q= uot; in correspondence of chunks stored in the local buffer)". Lingli,= have I got your point?

+ In Section 3.2.1 “channel server, that provides the list of availab= le channels (live TV or VoD content) to a PPLive, as soon as the peer joins= the system;” should be “channel server, that provides the list= of available channels (live TV or VoD content) to a PPLive peer, as soon as the peer joins the system;” --> done
+ It seems to me that the content server may have played some sort of track= er’s role in Octoshape, otherwise, how would a joining peer gets to k= now the initial address book of other peers? --> done

+ In Section 3.2.3, “a mechanism very similar to the one of TCP conge= stion window (double increase or linear increase depending on whether the e= stimate is below or a given threshold)”, should be like “a mech= anism very similar to the one of TCP congestion window (double increase or linear increase depending on whether the estimate is b= elow or above a given threshold)” --> done

+ One may be curious about what is the difference between a &ldqu= o;repeater node” and a “simple peer”, as the description = of a “repeater node” goes like “Repeater nodes, that serv= e as bandwidth multiplier, are able to forward any sub-stream and implement = the same peer protocol as simple peers.” --> I re-phrased &q= uot;simple peers, whose behavior has already been presented, and repeater n= odes, that implement the same peer protocol as simple peers and in addition are high-bandwidth peers and are able to forward any= sub-stream. In such a way repeater nodes serve as bandwidth multiplier&quo= t;. Lingli, have I got your point?

+ In Section 3.2.4, “a PPStream peer selects peers to download sub-ch= unks from according to a rate-based algorithm” should be change into = “a PPStream peer selects peers to download sub-chunks according to a = rate-based algorithm” --> done

+ In Section 3.1.5, “As already said, Tribler supports video streamin= g in two different forms: video on demand and live streaming.” Is bet= ter to be changed into “Tribler supports video streaming in two diffe= rent forms: video on demand and live streaming.”, since there is no prior statement in the draft. --> done

+ Also in Section 3.1.5, “Such a mechanism allows Tribler p= eers to use the public key included in torrent file and verity the integrit= y of each chunk.” should be changed into “Such a mechanism allows Tribler peers to use the public key in= cluded in torrent file and verify the integrity of each chunk.” -->= ; Lingli, I think your comment after the subsequent one is correct. So I co= mpletely removed this part. See my observation later on. Do you agree?

+ There is considerable reference and comparison to the Bitorrent= system/model in the Tribler’s subsection, one may wonder why not pos= e a separate section for introduction of Bittorrent instead? Lingli, I don't think this is the case, because= Bit Torrent is a P2P file sharing system and I have the impression that a = section devoted to a P2P file sharing system could appear somehow out of sc= ope. In addition, every time Bit Torrent is cited, we always tried to provide the necessary background info. Does i= t make sense?

+ It is noticeable that both the Tribler’s peer selection a= lgorithm and security mechanisms are elaborated in such a detailed way? Wha= t about other systems in terms of similar design issues? Since Section 3 is focus mainly on the peer topology, maybe= separate sections on algorithm/security are more natural for better compre= ssion. --> Lingli, the main problem here is that such a level of detail = is often not available for all the applications. Regarding this point I also added the following statement in= "Introduction" section "In addition, the provided descriptions may sometime= s appear inhomogeneous from the detail level point of view, but this always depends on the amount of available information at= writing time.". So the only solution seems to me t= o remove the reference to the security mechanisms. The peer selection algorithm is full part of the peer protocol= in my opinion and it has to be kept. But i would like to hear from you.

+ In Section 3.1.6, what does it mean by “not RTP/RTCP&rdqu= o; in “the client use UDP to transfer the encrypted media streaming a= nd not RTP/ RTCP.”? --> Duan, if I remember correctly, you provided this part. Can you please explain?

+ In Section 3.3.1, “Parent re-selection is also applied in case of l= eaving of the previous parent.” Is better to be changed into “P= arent re-selection is also triggered for a peer when its previous parent le= aves.” --> done

+ From the description in Section 3.3.1, it is not clear to me wh= y the QQLive’s topology is a hybrid of mesh and tree. --> Li= ngli, this comment is not completely clear for me. Probably you meant New Coolstreaming. If so, New Coolstreaming ma= y be regarded as hybrid, because on the one side you have an overlay mesh, = on the other side you have as many trees as substreams. I also added the fo= llowing statement "Hence, the overall overlay topology is mesh-based, but it is also possible to identify as man= y overlay trees as sub-streams.". Is it clearer now?

Please, let me know.

Regards

Francesca

From: duan shihui <duanshihui1201@gmail.com>
Date: Monday, December 2, 2013 5:26= PM
To: "ppsp@ietf.org" <ppsp@ietf.org>

Subject: Re: [ppsp] WGLC for the su= rvey draft

Rachel, Roni Even and Lingli have given some good comment= s.

There are some errors in the survey draft which must be fixed.
when we written the survey draft, the RFC6972 is still in the dra= ft status. Now we can refer to RFC6972 for some definitions.

I will consider carefully some comments from Lingli and give the = reply in the subsequent mail.

--
=B5=CB=C1=E9=C0=F2/Ling= li Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mob= ile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148

--047d7bdc869e275aaf04ecc0970f-- From denglingli@gmail.com Wed Dec 4 18:56:45 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D2A1AE33D for ; Wed, 4 Dec 2013 18:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.251 X-Spam-Level: ** X-Spam-Status: No, score=2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_71=0.6, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OsM7EtMiQbG for ; Wed, 4 Dec 2013 18:56:42 -0800 (PST) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 572271AE324 for ; Wed, 4 Dec 2013 18:56:42 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id db12so12956396veb.36 for ; Wed, 04 Dec 2013 18:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7i9wheUPSFFT1Z8DfUid02ImUjSIRIdlmfzyH24sAZQ=; b=MsbKwE3eDjj6CDEgoIkMuqqH6JjelA6VbHO/w1e29f2Av6mZI5kYQtwFZl26WUNO2/ lNT6INisce3y2DAJzhxWnyF7I8ftTmt9oL0QytuQPvk8xdy6Je8lcEU8guHGRJ2TGsRY Qlf7AsWNwaJbQvVTulsw45xnu8ADgnfy+oLC0otznyUjepbNo2d/HkTybAetLhFE4pLv /umvLXA1nKvS71+2kWKV32CIfpMgQYMmMgmT/wEPF9YKd58CYLpxcgeuNtRjykUJg0XN HN4ZCEWlVwR0uwX/wmKXMKil52RjdEaSfKlzozWVlvDEQYDsRWco7N3UzOICraTCo2iX 4pLg== MIME-Version: 1.0 X-Received: by 10.221.51.206 with SMTP id vj14mr61714138vcb.17.1386212198972; Wed, 04 Dec 2013 18:56:38 -0800 (PST) Received: by 10.58.118.130 with HTTP; Wed, 4 Dec 2013 18:56:38 -0800 (PST) In-Reply-To: References: Date: Thu, 5 Dec 2013 10:56:38 +0800 Message-ID: From: lingli deng To: duan shihui Content-Type: multipart/alternative; boundary=001a11332252b42eaa04ecc0add8 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] ppsp Digest, Vol 63, Issue 2 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 05 Dec 2013 02:56:45 -0000 --001a11332252b42eaa04ecc0add8 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Duan and Francesca, Sorry for the confusion. I do understand that QQlive does not use RTP/RTCP protocols. But do we need to stress the fact here? It gives the impression that some referring systems are using RTP/RTCP. Is it the case? Otherwise, I would recommend simply removing "not RTP/RTCP" in the sentence= . BR Lingli 2013/12/4 duan shihui > + In Section 3.1.6, what does it mean by ?not RTP/RTCP? in ?the client us= e > UDP to transfer the encrypted media streaming and not RTP/ RTCP.?? --> > Duan, if I remember correctly, you provided this part. Can you please > explain? > > yes, it's right. > the media is carried directly on the UDP and QQLive doesn't use RTP/RTCP > to carry the media. There is no RTP/RTCP in QQLive's protocols. > > > On Wed, Dec 4, 2013 at 7:08 PM, wrote: > >> Send ppsp mailing list submissions to >> ppsp@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/ppsp >> or, via email, send a message with subject or body 'help' to >> ppsp-request@ietf.org >> >> You can reach the person managing the list at >> ppsp-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of ppsp digest..." >> >> >> Today's Topics: >> >> 1. Re: WGLC for the survey draft (Francesca Lo Piccolo (flopicco)) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 4 Dec 2013 11:08:33 +0000 >> From: "Francesca Lo Piccolo (flopicco)" >> To: Zongning , duan , >> "'yunfei zhang'" , Gu Yingjie >> , lingli deng >> Cc: "ppsp@ietf.org" >> Subject: Re: [ppsp] WGLC for the survey draft >> Message-ID: >> Content-Type: text/plain; charset=3D"windows-1252" >> >> Duan and all, >> >> I absolutely agree with you on the good quality of received feedback and >> on the necessity to fix some parts in the survey draft. >> >> To this end, I'm attaching a new revision of the survey (and also of the >> pictures), where most of the comments from Rachel, Roni and Lingli have >> been already taken into account. >> >> Here is a summary of all the received comments, with the ones still open >> highlighted in red. Lingli, you are among the "to" receivers, because th= ere >> is some your comment I would like to further discuss with you. >> >> Rachel >> --------- >> + The description in the last paragraph of Section 1 is inconsistent wit= h >> the organization of chapters . This should be fixed. --> Ning, is it >> possible to turn section 3.1 (and subsections) into section 4 and 3.2 (a= nd >> subsections) in section 5 and 3.3 (and subsections) in section 6? >> + In section 2, some terminologies have already defined in RFC6972. It?s >> unnecessary to repeat the definition, e.g., chunk, live streaming? --> d= one >> + Section 1 typo: ?we always try to identity tracker and peer protocols? >> should be ?we always try to identify tracker and peer protocols? --> don= e >> + Section 3.1, typo ?this may turn at end users into playback quality >> degradation? should be ?this may turn end users into playback quality >> degradation? --> done >> + It?s better to adjust the order of types of P2P streaming applications >> to be consistent with the order of subsections, which means ?mesh-based? >> should be first, then ?tree-based?. --> done >> >> Roni >> ------ >> + Figure 1 ?traker? should be ?tracker? --> done >> + In section 3.1.2 on PPLive change ?being the nature of PPLive protocol= s >> and algorithm proprietary? to ? Since the protocols and algorithm of PPL= IVE >> are proprietary? --> done >> + In section 3.1.3 ? Authentication server is the first point of contact >> for a peer the joins the system? to ?Authentication server is the first >> point of contact for a peer that joins the system? --> done >> + In section 3.1.3 ? can contact new more peers besides the ones >> indicated by the rendezvous server? to ?can contact new peers besides th= e >> ones indicated by the rendezvous server? --> done >> + In section 3.1.5 ?Since children could lie regarding the number of >> chunks forwarded to others, Tribler peers do directly not ask their >> children, but their grandchildren.? To ?Since children could lie regardi= ng >> the number of chunks forwarded to others, Tribler peers do not ask their >> children directly, but their grandchildren.? --> done >> + In section 3.1.6 when first using CDN expand to Content Delivery >> Network (CDN) --> done >> >> >> Lingli >> ------- >> + it states as a "standard track" document, is that accurate? --> Ning, >> we already discussed about this. As per your comment, this document shou= ld >> be ?informational?, rather than ?standard track?. I assume this is >> something you can take into account as soon as you will submit the final >> revision, right? >> + in terminoloy section, "push" is defined as "Transmission of multimedi= a >> content without any request from receiving peers.", which I think could = be >> better described as "Transmission of multimedia content that is not >> initiated by receiving peers." --> done >> + In section 3, "the topology that can be associated with overlay >> connections among peers" could be rephrased into "the topology of overla= y >> connections among peers". --> done >> + Also in section 3, "pull-based data delivery calls for large size >> buffers where to store chunks" could be rephrased into "pull-based data >> delivery calls for large size buffers to store chunks". --> done >> + "buffer-maps" are used to refer to "chunk availability information" (a= s >> used by RFC 6972). For sake of consistency, I think it is better to use = the >> latter instead. --> I re-phrased "in some applications peers exchange ch= unk >> availability information in form of buffer-maps (a sort of bit maps with= a >> bit "1" in correspondence of chunks stored in the local buffer)". Lingli= , >> have I got your point? >> + In Section 3.2.1 ?channel server, that provides the list of available >> channels (live TV or VoD content) to a PPLive, as soon as the peer joins >> the system;? should be ?channel server, that provides the list of availa= ble >> channels (live TV or VoD content) to a PPLive peer, as soon as the peer >> joins the system;? --> done >> + It seems to me that the content server may have played some sort of >> tracker?s role in Octoshape, otherwise, how would a joining peer gets to >> know the initial address book of other peers? --> done >> + In Section 3.2.3, ?a mechanism very similar to the one of TCP >> congestion window (double increase or linear increase depending on wheth= er >> the estimate is below or a given threshold)?, should be like ?a mechanis= m >> very similar to the one of TCP congestion window (double increase or lin= ear >> increase depending on whether the estimate is below or above a given >> threshold)? --> done >> + One may be curious about what is the difference between a ?repeater >> node? and a ?simple peer?, as the description of a ?repeater node? goes >> like ?Repeater nodes, that serve as bandwidth multiplier, are able to >> forward any sub-stream and implement the same peer protocol as simple >> peers.? --> I re-phrased "simple peers, whose behavior has already been >> presented, and repeater nodes, that implement the same peer protocol as >> simple peers and in addition are high-bandwidth peers and are able to >> forward any sub-stream. In such a way repeater nodes serve as bandwidth >> multiplier". Lingli, have I got your point? >> + In Section 3.2.4, ?a PPStream peer selects peers to download sub-chunk= s >> from according to a rate-based algorithm? should be change into ?a PPStr= eam >> peer selects peers to download sub-chunks according to a rate-based >> algorithm? --> done >> + In Section 3.1.5, ?As already said, Tribler supports video streaming i= n >> two different forms: video on demand and live streaming.? Is better to b= e >> changed into ?Tribler supports video streaming in two different forms: >> video on demand and live streaming.?, since there is no prior statement = in >> the draft. --> done >> + Also in Section 3.1.5, ?Such a mechanism allows Tribler peers to use >> the public key included in torrent file and verity the integrity of each >> chunk.? should be changed into ?Such a mechanism allows Tribler peers to >> use the public key included in torrent file and verify the integrity of >> each chunk.? --> Lingli, I think your comment after the subsequent one i= s >> correct. So I completely removed this part. See my observation later on.= Do >> you agree? >> + There is considerable reference and comparison to the Bitorrent >> system/model in the Tribler?s subsection, one may wonder why not pose a >> separate section for introduction of Bittorrent instead? Lingli, I don't >> think this is the case, because Bit Torrent is a P2P file sharing system >> and I have the impression that a section devoted to a P2P file sharing >> system could appear somehow out of scope. In addition, every time Bit >> Torrent is cited, we always tried to provide the necessary background in= fo. >> Does it make sense? >> + It is noticeable that both the Tribler?s peer selection algorithm and >> security mechanisms are elaborated in such a detailed way? What about ot= her >> systems in terms of similar design issues? Since Section 3 is focus main= ly >> on the peer topology, maybe separate sections on algorithm/security are >> more natural for better compression. --> Lingli, the main problem here i= s >> that such a level of detail is often not available for all the >> applications. Regarding this point I also added the following statement = in >> "Introduction" section "In addition, the provided descriptions may >> sometimes appear inhomogeneous from the detail level point of view, but >> this always depends on the amount of available information at writing >> time.". So the only solution seems to me to remove the reference to the >> security mechanisms. The peer selection algorithm is full part of the pe= er >> protocol in my opinion and it has to be kept. But i would like to hear f= rom >> you. >> + In Section 3.1.6, what does it mean by ?not RTP/RTCP? in ?the client >> use UDP to transfer the encrypted media streaming and not RTP/ RTCP.?? -= -> >> Duan, if I remember correctly, you provided this part. Can you please >> explain? >> + In Section 3.3.1, ?Parent re-selection is also applied in case of >> leaving of the previous parent.? Is better to be changed into ?Parent >> re-selection is also triggered for a peer when its previous parent leave= s.? >> --> done >> + From the description in Section 3.3.1, it is not clear to me why the >> QQLive?s topology is a hybrid of mesh and tree. --> Lingli, this commen= t >> is not completely clear for me. Probably you meant New Coolstreaming. If >> so, New Coolstreaming may be regarded as hybrid, because on the one side >> you have an overlay mesh, on the other side you have as many trees as >> substreams. I also added the following statement "Hence, the overall >> overlay topology is mesh-based, but it is also possible to identify as m= any >> overlay trees as sub-streams.". Is it clearer now? >> >> >> Please, let me know. >> >> Regards >> Francesca >> >> From: duan shihui > duanshihui1201@gmail.com>> >> Date: Monday, December 2, 2013 5:26 PM >> To: "ppsp@ietf.org" > ppsp@ietf.org>> >> Subject: Re: [ppsp] WGLC for the survey draft >> >> Rachel, Roni Even and Lingli have given some good comments. >> There are some errors in the survey draft which must be fixed. >> when we written the survey draft, the RFC6972 is still in the draft >> status. Now we can refer to RFC6972 for some definitions. >> I will consider carefully some comments from Lingli and give the reply i= n >> the subsequent mail. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/= attachment.html >> > >> -------------- next part -------------- >> An embedded and charset-unspecified text was scrubbed... >> Name: PPSP survey figures.txt >> URL: < >> http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/= attachment.txt >> > >> -------------- next part -------------- >> A non-text attachment was scrubbed... >> Name: Ppsp survey-flp0.4.docx >> Type: >> application/vnd.openxmlformats-officedocument.wordprocessingml.document >> Size: 52889 bytes >> Desc: Ppsp survey-flp0.4.docx >> URL: < >> http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/= attachment.docx >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >> >> >> ------------------------------ >> >> End of ppsp Digest, Vol 63, Issue 2 >> *********************************** >> > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --001a11332252b42eaa04ecc0add8 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi Duan and Francesca,

Sorry= for the confusion.

I do understand that QQlive does not us= e RTP/RTCP protocols.

But do we need to stress the fact here? It = gives the impression that some referring systems are using RTP/RTCP. Is it = the case?

Otherwise, I would recommend simply removing "not RTP/RTCP" = in the sentence.

Lingli

2013/12/4 duan = shihui <duanshihui1201@gmail.com>

= + In Section 3.1.6, what does it mean by ?not RTP/RTCP? in ?the client=20 use UDP to transfer the encrypted media streaming and not RTP/ RTCP.??=20 --> Duan, if I remember correctly, you provided this part. Can you=20 please explain?

yes, it's right= .
the media is carried directly on the UDP and QQLive doesn't = use RTP/RTCP to carry the media. There is no RTP/RTCP in QQLive's proto= cols.

On Wed,= Dec 4, 2013 at 7:08 PM, <ppsp-request@ietf.org> wrote:=
Send ppsp mailing list submissions to
ppsp@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/ppsp or, via email, send a message with subject or body 'help' to
ppsp-request@ietf.org

You can reach the person managing the list at
ppsp-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ppsp digest..."

Today's Topics:

1. Re: WGLC for the survey draft (Francesca Lo Piccolo (flopic= co))

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

Message: 1
Date: Wed, 4 Dec 2013 11:08:33 +0000
From: "Francesca Lo Piccolo (flopicco)" <flopicco@cisco.com>
To: Zongning <z= ongning@huawei.com>, duan <duanshihui@catr.cn>,
"'yunfei zhang'" <hishigh@gmail.com>, = Gu Yingjie
<guyingjie@gmail.com>, lingli deng <denglingli@gmail.com>
Cc: "ppsp@ietf.org<= /a>" <ppsp@ietf.= org>
Subject: Re: [ppsp] WGLC for the survey draft
Message-ID: <CEC4BA67.18160%flopicco@cisco.com>
Content-Type: text/plain; charset=3D"windows-1252"

Duan and all,

I absolutely agree with you on the good quality of received feedback and on= the necessity to fix some parts in the survey draft.

To this end, I'm attaching a new revision of the survey (and also of th= e pictures), where most of the comments from Rachel, Roni and Lingli have b= een already taken into account.

Here is a summary of all the received comments, with the ones still open hi= ghlighted in red. Lingli, you are among the "to" receivers, becau= se there is some your comment I would like to further discuss with you.

Rachel
---------
+ The description in the last paragraph of Section 1 is inconsistent with t= he organization of chapters . This should be fixed. --> Ning, is it poss= ible to turn section 3.1 (and subsections) into section 4 and 3.2 (and subs= ections) in section 5 and 3.3 (and subsections) in section 6?
+ In section 2, some terminologies have already defined in RFC6972. It?s un= necessary to repeat the definition, e.g., chunk, live streaming? --> don= e
+ Section 1 typo: ?we always try to identity tracker and peer protocols? sh= ould be ?we always try to identify tracker and peer protocols? --> done<= br> + Section 3.1, typo ?this may turn at end users into playback quality degra= dation? should be ?this may turn end users into playback quality degradatio= n? --> done
+ It?s better to adjust the order of types of P2P streaming applications to= be consistent with the order of subsections, which means ?mesh-based? shou= ld be first, then ?tree-based?. --> done

Roni
------
+ Figure 1 ?traker? should be ?tracker? --> done
+ In section 3.1.2 on PPLive change ?being the nature of PPLive protocols a= nd algorithm proprietary? to ? Since the protocols and algorithm of PPLIVE = are proprietary? --> done
+ In section 3.1.3 ? Authentication server is the first point of contact fo= r a peer the joins the system? to ?Authentication server is the first point= of contact for a peer that joins the system? --> done
+ In section 3.1.3 ? can contact new more peers besides the ones indicated = by the rendezvous server? to ?can contact new peers besides the ones indica= ted by the rendezvous server? --> done
+ In section 3.1.5 ?Since children could lie regarding the number of chunks= forwarded to others, Tribler peers do directly not ask their children, but= their grandchildren.? To ?Since children could lie regarding the number of= chunks forwarded to others, Tribler peers do not ask their children direct= ly, but their grandchildren.? --> done
+ In section 3.1.6 when first using CDN expand to Content Delivery Network = (CDN) --> done

Lingli
-------
+ it states as a "standard track" document, is that accurate? --&= gt; Ning, we already discussed about this. As per your comment, this docume= nt should be ?informational?, rather than ?standard track?. I assume this i= s something you can take into account as soon as you will submit the final = revision, right?
+ in terminoloy section, "push" is defined as "Transmission = of multimedia content without any request from receiving peers.", whic= h I think could be better described as "Transmission of multimedia con= tent that is not initiated by receiving peers." --> done
+ In section 3, "the topology that can be associated with overlay conn= ections among peers" could be rephrased into "the topology of ove= rlay connections among peers". --> done
+ Also in section 3, "pull-based data delivery calls for large size bu= ffers where to store chunks" could be rephrased into "pull-based = data delivery calls for large size buffers to store chunks". --> do= ne
+ "buffer-maps" are used to refer to "chunk availability inf= ormation" (as used by RFC 6972). For sake of consistency, I think it i= s better to use the latter instead. --> I re-phrased "in some appli= cations peers exchange chunk availability information in form of buffer-map= s (a sort of bit maps with a bit "1" in correspondence of chunks = stored in the local buffer)". Lingli, have I got your point?
+ In Section 3.2.1 ?channel server, that provides the list of available cha= nnels (live TV or VoD content) to a PPLive, as soon as the peer joins the s= ystem;? should be ?channel server, that provides the list of available chan= nels (live TV or VoD content) to a PPLive peer, as soon as the peer joins t= he system;? --> done
+ It seems to me that the content server may have played some sort of track= er?s role in Octoshape, otherwise, how would a joining peer gets to know th= e initial address book of other peers? --> done
+ In Section 3.2.3, ?a mechanism very similar to the one of TCP congestion = window (double increase or linear increase depending on whether the estimat= e is below or a given threshold)?, should be like ?a mechanism very similar= to the one of TCP congestion window (double increase or linear increase de= pending on whether the estimate is below or above a given threshold)? -->= ; done
+ One may be curious about what is the difference between a ?repeater node?= and a ?simple peer?, as the description of a ?repeater node? goes like ?Re= peater nodes, that serve as bandwidth multiplier, are able to forward any s= ub-stream and implement the same peer protocol as simple peers.? --&g= t; I re-phrased "simple peers, whose behavior has already been present= ed, and repeater nodes, that implement the same peer protocol as simple pee= rs and in addition are high-bandwidth peers and are able to forward any sub= -stream. In such a way repeater nodes serve as bandwidth multiplier". = Lingli, have I got your point?
+ In Section 3.2.4, ?a PPStream peer selects peers to download sub-chunks f= rom according to a rate-based algorithm? should be change into ?a PPStream = peer selects peers to download sub-chunks according to a rate-based algorit= hm? --> done
+ In Section 3.1.5, ?As already said, Tribler supports video streaming in t= wo different forms: video on demand and live streaming.? Is better to be ch= anged into ?Tribler supports video streaming in two different forms: video = on demand and live streaming.?, since there is no prior statement in the dr= aft. --> done
+ Also in Section 3.1.5, ?Such a mechanism allows Tribler peers to use the = public key included in torrent file and verity the integrity of each chunk.= ? should be changed into ?Such a mechanism allows Tribler peers to use the = public key included in torrent file and verify the integrity of each chunk.= ? --> Lingli, I think your comment after the subsequent one is correct. = So I completely removed this part. See my observation later on. Do you agre= e?
+ There is considerable reference and comparison to the Bitorrent system/mo= del in the Tribler?s subsection, one may wonder why not pose a separate sec= tion for introduction of Bittorrent instead? Lingli, I don't think this= is the case, because Bit Torrent is a P2P file sharing system and I have t= he impression that a section devoted to a P2P file sharing system could app= ear somehow out of scope. In addition, every time Bit Torrent is cited, we = always tried to provide the necessary background info. Does it make sense?<= br> + It is noticeable that both the Tribler?s peer selection algorithm and sec= urity mechanisms are elaborated in such a detailed way? What about other sy= stems in terms of similar design issues? Since Section 3 is focus mainly on= the peer topology, maybe separate sections on algorithm/security are more = natural for better compression. --> Lingli, the main problem here is tha= t such a level of detail is often not available for all the applications. R= egarding this point I also added the following statement in "Introduct= ion" section "In addition, the provided descriptions may sometime= s appear inhomogeneous from the detail level point of view, but this always= depends on the amount of available information at writing time.". &nb= sp;So the only solution seems to me to remove the reference to the security= mechanisms. The peer selection algorithm is full part of the peer protocol= in my opinion and it has to be kept. But i would like to hear from you. + In Section 3.1.6, what does it mean by ?not RTP/RTCP? in ?the client use = UDP to transfer the encrypted media streaming and not RTP/ RTCP.?? --> D= uan, if I remember correctly, you provided this part. Can you please explai= n?
+ In Section 3.3.1, ?Parent re-selection is also applied in case of leaving= of the previous parent.? Is better to be changed into ?Parent re-selection= is also triggered for a peer when its previous parent leaves.? --> done=
+ From the description in Section 3.3.1, it is not clear to me why the QQLi= ve?s topology is a hybrid of mesh and tree. --> Lingli, this comme= nt is not completely clear for me. Probably you meant New Coolstreaming. If= so, New Coolstreaming may be regarded as hybrid, because on the one side y= ou have an overlay mesh, on the other side you have as many trees as substr= eams. I also added the following statement "Hence, the overall overlay= topology is mesh-based, but it is also possible to identify as many overla= y trees as sub-streams.". Is it clearer now?

Please, let me know.

Regards
Francesca

From: duan shihui <duanshihui1201@gmail.com<mailto:duanshihui1201@gmail.com>>
Date: Monday, December 2, 2013 5:26 PM
To: "ppsp@ietf.org<= /a><mailto:ppsp@ietf.= org>" <pp= sp@ietf.org<mailto:ppsp@ietf.org>>
Subject: Re: [ppsp] WGLC for the survey draft

Rachel, Roni Even and Lingli have given some good comments.
There are some errors in the survey draft which must be fixed.
when we written the survey draft, the RFC6972 is still in the draft status.= Now we can refer to RFC6972 for some definitions.
I will consider carefully some comments from Lingli and give the reply in t= he subsequent mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mai= l-archive/web/ppsp/attachments/20131204/71d03347/attachment.html> -------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PPSP survey figures.txt
URL: <http://www.ietf.org/mail= -archive/web/ppsp/attachments/20131204/71d03347/attachment.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ppsp survey-flp0.4.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.docume= nt
Size: 52889 bytes
Desc: Ppsp survey-flp0.4.docx
URL: <http://www.ietf.org/mai= l-archive/web/ppsp/attachments/20131204/71d03347/attachment.docx>
------------------------------

Subject: Digest Footer

_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

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

End of ppsp Digest, Vol 63, Issue 2
***********************************

_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

--
=B5=CB=C1=E9=C0=F2/= Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China= Mobile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148

--001a11332252b42eaa04ecc0add8-- From flopicco@cisco.com Mon Dec 9 03:34:12 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0231ADF5E for ; Mon, 9 Dec 2013 03:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.351 X-Spam-Level: X-Spam-Status: No, score=-4.351 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnpNf8l7soRy for ; Mon, 9 Dec 2013 03:34:05 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 834351AE279 for ; Mon, 9 Dec 2013 03:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=73430; q=dns/txt; s=iport; t=1386588840; x=1387798440; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=hhtkxsEJLqOyXttxrrEr4YZpXZCTA9yAU1uLMqEWWw0=; b=IkM8cnowy5qQe9FKuheDiwnEFA/YgKvJp3DPeB8kdF4YkHTQcs8RRzP2 860md5xj4GyF0tWZpQfoc67blchgnq8QCFaLleINkusPrOQI9agjiiDJa dHaBBnZNoQRHLG57JrVanhQDZZsTLjidojt+n5+cdoPCSFaT6icEtO377 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAKuppVKtJV2a/2dsb2JhbABPAQmCQ0SBC4J/thUYgRMWdIIlAQIEGAIBDFISAQYCEQMBAhYLAQYFBB8RFAkIAgQKBAMCG4dVAw+WGJtbCIgoDYZnF4x9gTcBCgEBNAMHDAUGAQqCXYFMA5QxgXiBa4xahTmDKUCBKAYDFyI X-IronPort-AV: E=Sophos;i="4.93,857,1378857600"; d="scan'208,217";a="5348629" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 09 Dec 2013 11:33:58 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rB9BXvmC023600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 11:33:57 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 05:33:57 -0600 From: "Francesca Lo Piccolo (flopicco)" To: lingli deng Thread-Topic: [ppsp] WGLC for the survey draft Thread-Index: AQHO9NKLxZIMYG8VOEuDOxixbnCO9Q== Date: Mon, 9 Dec 2013 11:33:56 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.147.74.108] Content-Type: multipart/alternative; boundary="_000_CECB6642189FDflopiccociscocom_" MIME-Version: 1.0 Cc: Gu Yingjie , duan , "ppsp@ietf.org" Subject: Re: [ppsp] WGLC for the survey draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 09 Dec 2013 11:34:12 -0000 --_000_CECB6642189FDflopiccociscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTGluZ2xpLA0KDQpUaGUgYmVzdCB3ZSBjYW4gZG8gaXMgdG8gdHJ5IGFzIG11Y2ggc2VjdXJp dHktcmVsYXRlZCBpbmZvcm1hdGlvbiBhcyBwb3NzaWJsZSBmb3IgYWxsIHRoZSBwcmVzZW50ZWQg YWxnb3JpdGhtcy4NCg0KSSBoYXZlIG5vIGlkZWEgb24gaG93IG11Y2ggc2VjdXJpdHktcmVsYXRl ZCBpbmZvcm1hdGlvbiBpcyBjdXJyZW50bHkgYXZhaWxhYmxlLCBhbmQgSSB3aWxsIGdldCBiYWNr IHRvIHlvdSB2ZXJ5IHNvb24uIFdoYXQgaWYgaXQgd2lsbCBjb21lIG91dCB0aGF0IHRoZXJlIGlz IG5vIGF2YWlsYWJsZSBpbmZvcm1hdGlvbiBhdCBhbGw/DQoNCg0KVGhhbmtzIGFuZCByZWdhcmRz DQpGcmFuY2VzY2ENCg0KRnJvbTogbGluZ2xpIGRlbmcgPGRlbmdsaW5nbGlAZ21haWwuY29tPG1h aWx0bzpkZW5nbGluZ2xpQGdtYWlsLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgRGVjZW1iZXIgNSwg MjAxMyAzOjUwIEFNDQpUbzogRnJhbmNlc2NhIExvIFBpY2NvbG8gPGZsb3BpY2NvQGNpc2NvLmNv bTxtYWlsdG86ZmxvcGljY29AY2lzY28uY29tPj4NCkNjOiBab25nbmluZyA8em9uZ25pbmdAaHVh d2VpLmNvbTxtYWlsdG86em9uZ25pbmdAaHVhd2VpLmNvbT4+LCBkdWFuIDxkdWFuc2hpaHVpQGNh dHIuY248bWFpbHRvOmR1YW5zaGlodWlAY2F0ci5jbj4+LCB5dW5mZWkgemhhbmcgPGhpc2hpZ2hA Z21haWwuY29tPG1haWx0bzpoaXNoaWdoQGdtYWlsLmNvbT4+LCBHdSBZaW5namllIDxndXlpbmdq aWVAZ21haWwuY29tPG1haWx0bzpndXlpbmdqaWVAZ21haWwuY29tPj4sICJwcHNwQGlldGYub3Jn PG1haWx0bzpwcHNwQGlldGYub3JnPiIgPHBwc3BAaWV0Zi5vcmc8bWFpbHRvOnBwc3BAaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFtwcHNwXSBXR0xDIGZvciB0aGUgc3VydmV5IGRyYWZ0DQoNCkhp IEZyYW5jZXNjYSwNCg0KVGhhbmsgeW91IGZvciB0aGUgcXVpY2sgcmVzcG9uc2UuDQpJIHRoaW5r IG1vc3Qgb2YgdGhlIGlzc3VlcyBhcmUgYWRkcmVzc2VkLCBleGNlcHQgdGhlIHNlY3VyaXR5IG1l Y2hhbmlzbXMuIChJbmxpbmUgY29tbWVudHMgYXJlIGFsc28gaW5jbHVkZWQgYmVsb3deXikNClRo ZSBjb25jZXJuIGhlcmUgaXMgdGhhdCBJIHRoaW5rIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGlz IGFsc28gaW1wb3J0YW50LiAgV291bGQgaXQgYmUgcG9zc2libGUgdG8gZmVlZCByZWxldmFudCBj b250ZW50IGludG8gobBzZWN1cml0eSBjb25zaWRlcmF0aW9uc6GxIHJhdGhlciB0aGFuIHNpbXBs ZSByZW1vdmFsPw0KDQpCUg0KTGluZ2xpDQoNCreivP7IyzogcHBzcCBbbWFpbHRvOnBwc3AtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnPl0gtPqx7SBGcmFuY2Vz Y2EgTG8gUGljY29sbyAoZmxvcGljY28pDQq3osvNyrG85DogMjAxM8TqMTLUwjTI1SAxOTowOQ0K ytW8/sjLOiBab25nbmluZzsgZHVhbjsgJ3l1bmZlaSB6aGFuZyc7IEd1IFlpbmdqaWU7IGxpbmds aSBkZW5nDQqzrcvNOiBwcHNwQGlldGYub3JnPG1haWx0bzpwcHNwQGlldGYub3JnPg0K1vfM4jog UmU6IFtwcHNwXSBXR0xDIGZvciB0aGUgc3VydmV5IGRyYWZ0DQoNCkR1YW4gYW5kIGFsbCwNCg0K SSBhYnNvbHV0ZWx5IGFncmVlIHdpdGggeW91IG9uIHRoZSBnb29kIHF1YWxpdHkgb2YgcmVjZWl2 ZWQgZmVlZGJhY2sgYW5kIG9uIHRoZSBuZWNlc3NpdHkgdG8gZml4IHNvbWUgcGFydHMgaW4gdGhl IHN1cnZleSBkcmFmdC4NCg0KVG8gdGhpcyBlbmQsIEknbSBhdHRhY2hpbmcgYSBuZXcgcmV2aXNp b24gb2YgdGhlIHN1cnZleSAoYW5kIGFsc28gb2YgdGhlIHBpY3R1cmVzKSwgd2hlcmUgbW9zdCBv ZiB0aGUgY29tbWVudHMgZnJvbSBSYWNoZWwsIFJvbmkgYW5kIExpbmdsaSBoYXZlIGJlZW4gYWxy ZWFkeSB0YWtlbiBpbnRvIGFjY291bnQuDQoNCkhlcmUgaXMgYSBzdW1tYXJ5IG9mIGFsbCB0aGUg cmVjZWl2ZWQgY29tbWVudHMsIHdpdGggdGhlIG9uZXMgc3RpbGwgb3BlbiBoaWdobGlnaHRlZCBp biByZWQuIExpbmdsaSwgeW91IGFyZSBhbW9uZyB0aGUgInRvIiByZWNlaXZlcnMsIGJlY2F1c2Ug dGhlcmUgaXMgc29tZSB5b3VyIGNvbW1lbnQgSSB3b3VsZCBsaWtlIHRvIGZ1cnRoZXIgZGlzY3Vz cyB3aXRoIHlvdS4NCg0KUmFjaGVsDQotLS0tLS0tLS0NCisgVGhlIGRlc2NyaXB0aW9uIGluIHRo ZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDEgaXMgaW5jb25zaXN0ZW50IHdpdGggdGhlIG9y Z2FuaXphdGlvbiBvZiBjaGFwdGVycyAuIFRoaXMgc2hvdWxkIGJlIGZpeGVkLiAtLT4gTmluZywg aXMgaXQgcG9zc2libGUgdG8gdHVybiBzZWN0aW9uIDMuMSAoYW5kIHN1YnNlY3Rpb25zKSBpbnRv IHNlY3Rpb24gNCBhbmQgMy4yIChhbmQgc3Vic2VjdGlvbnMpIGluIHNlY3Rpb24gNSBhbmQgMy4z IChhbmQgc3Vic2VjdGlvbnMpIGluIHNlY3Rpb24gNj8NCisgSW4gc2VjdGlvbiAyLCBzb21lIHRl cm1pbm9sb2dpZXMgaGF2ZSBhbHJlYWR5IGRlZmluZWQgaW4gUkZDNjk3Mi4gSXShr3MgdW5uZWNl c3NhcnkgdG8gcmVwZWF0IHRoZSBkZWZpbml0aW9uLCBlLmcuLCBjaHVuaywgbGl2ZSBzdHJlYW1p bmehrSAtLT4gZG9uZQ0KKyBTZWN0aW9uIDEgdHlwbzogobB3ZSBhbHdheXMgdHJ5IHRvIGlkZW50 aXR5IHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2xzobEgc2hvdWxkIGJlIKGwd2UgYWx3YXlzIHRy eSB0byBpZGVudGlmeSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sc6GxIC0tPiBkb25lDQorIFNl Y3Rpb24gMy4xLCB0eXBvIKGwdGhpcyBtYXkgdHVybiBhdCBlbmQgdXNlcnMgaW50byBwbGF5YmFj ayBxdWFsaXR5IGRlZ3JhZGF0aW9uobEgc2hvdWxkIGJlIKGwdGhpcyBtYXkgdHVybiBlbmQgdXNl cnMgaW50byBwbGF5YmFjayBxdWFsaXR5IGRlZ3JhZGF0aW9uobEgLS0+IGRvbmUNCisgSXShr3Mg YmV0dGVyIHRvIGFkanVzdCB0aGUgb3JkZXIgb2YgdHlwZXMgb2YgUDJQIHN0cmVhbWluZyBhcHBs aWNhdGlvbnMgdG8gYmUgY29uc2lzdGVudCB3aXRoIHRoZSBvcmRlciBvZiBzdWJzZWN0aW9ucywg d2hpY2ggbWVhbnMgobBtZXNoLWJhc2VkobEgc2hvdWxkIGJlIGZpcnN0LCB0aGVuIKGwdHJlZS1i YXNlZKGxLiAtLT4gZG9uZQ0KDQpSb25pDQotLS0tLS0NCisgRmlndXJlIDEgobB0cmFrZXKhsSBz aG91bGQgYmUgobB0cmFja2VyobEgIC0tPiBkb25lDQorIEluIHNlY3Rpb24gMy4xLjIgb24gUFBM aXZlIGNoYW5nZSChsGJlaW5nIHRoZSBuYXR1cmUgb2YgUFBMaXZlIHByb3RvY29scyBhbmQgYWxn b3JpdGhtIHByb3ByaWV0YXJ5obEgdG8gobAgU2luY2UgdGhlIHByb3RvY29scyBhbmQgYWxnb3Jp dGhtIG9mIFBQTElWRSBhcmUgcHJvcHJpZXRhcnmhsSAgLS0+IGRvbmUNCisgSW4gc2VjdGlvbiAz LjEuMyChsCBBdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaXMgdGhlIGZpcnN0IHBvaW50IG9mIGNvbnRh Y3QgZm9yIGEgcGVlciB0aGUgam9pbnMgdGhlIHN5c3RlbaGxIHRvIKGwQXV0aGVudGljYXRpb24g c2VydmVyIGlzIHRoZSBmaXJzdCBwb2ludCBvZiBjb250YWN0IGZvciBhIHBlZXIgdGhhdCBqb2lu cyB0aGUgc3lzdGVtobEgLS0+IGRvbmUNCisgSW4gc2VjdGlvbiAzLjEuMyChsCBjYW4gY29udGFj dCBuZXcgbW9yZSBwZWVycyBiZXNpZGVzIHRoZSBvbmVzIGluZGljYXRlZCBieSB0aGUgcmVuZGV6 dm91cyBzZXJ2ZXKhsSB0byChsGNhbiBjb250YWN0IG5ldyBwZWVycyBiZXNpZGVzIHRoZSBvbmVz IGluZGljYXRlZCBieSB0aGUgcmVuZGV6dm91cyBzZXJ2ZXKhsSAtLT4gZG9uZQ0KKyBJbiBzZWN0 aW9uIDMuMS41IKGwU2luY2UgY2hpbGRyZW4gY291bGQgbGllIHJlZ2FyZGluZyB0aGUgbnVtYmVy IG9mIGNodW5rcyBmb3J3YXJkZWQgdG8gb3RoZXJzLCBUcmlibGVyIHBlZXJzIGRvIGRpcmVjdGx5 IG5vdCBhc2sgdGhlaXIgY2hpbGRyZW4sIGJ1dCB0aGVpciBncmFuZGNoaWxkcmVuLqGxIFRvIKGw U2luY2UgY2hpbGRyZW4gY291bGQgbGllIHJlZ2FyZGluZyB0aGUgbnVtYmVyIG9mIGNodW5rcyBm b3J3YXJkZWQgdG8gb3RoZXJzLCBUcmlibGVyIHBlZXJzIGRvIG5vdCBhc2sgdGhlaXIgY2hpbGRy ZW4gZGlyZWN0bHksIGJ1dCB0aGVpciBncmFuZGNoaWxkcmVuLqGxIC0tPiBkb25lDQorIEluIHNl Y3Rpb24gMy4xLjYgd2hlbiBmaXJzdCB1c2luZyBDRE4gZXhwYW5kIHRvIENvbnRlbnQgRGVsaXZl cnkgTmV0d29yayAoQ0ROKSAtLT4gZG9uZQ0KDQoNCkxpbmdsaQ0KLS0tLS0tLQ0KKyBpdCBzdGF0 ZXMgYXMgYSAic3RhbmRhcmQgdHJhY2siIGRvY3VtZW50LCBpcyB0aGF0IGFjY3VyYXRlPyAtLT4g TmluZywgd2UgYWxyZWFkeSBkaXNjdXNzZWQgYWJvdXQgdGhpcy4gQXMgcGVyIHlvdXIgY29tbWVu dCwgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgobBpbmZvcm1hdGlvbmFsobEsIHJhdGhlciB0aGFu IKGwc3RhbmRhcmQgdHJhY2uhsS4gSSBhc3N1bWUgdGhpcyBpcyBzb21ldGhpbmcgeW91IGNhbiB0 YWtlIGludG8gYWNjb3VudCBhcyBzb29uIGFzIHlvdSB3aWxsIHN1Ym1pdCB0aGUgZmluYWwgcmV2 aXNpb24sIHJpZ2h0Pw0KKyBpbiB0ZXJtaW5vbG95IHNlY3Rpb24sICJwdXNoIiBpcyBkZWZpbmVk IGFzICJUcmFuc21pc3Npb24gb2YgbXVsdGltZWRpYSBjb250ZW50IHdpdGhvdXQgYW55IHJlcXVl c3QgZnJvbSByZWNlaXZpbmcgcGVlcnMuIiwgd2hpY2ggSSB0aGluayBjb3VsZCBiZSBiZXR0ZXIg ZGVzY3JpYmVkIGFzICJUcmFuc21pc3Npb24gb2YgbXVsdGltZWRpYSBjb250ZW50IHRoYXQgaXMg bm90IGluaXRpYXRlZCBieSByZWNlaXZpbmcgcGVlcnMuIiAtLT4gZG9uZQ0KKyBJbiBzZWN0aW9u IDMsICJ0aGUgdG9wb2xvZ3kgdGhhdCBjYW4gYmUgYXNzb2NpYXRlZCB3aXRoIG92ZXJsYXkgY29u bmVjdGlvbnMgYW1vbmcgcGVlcnMiIGNvdWxkIGJlIHJlcGhyYXNlZCBpbnRvICJ0aGUgdG9wb2xv Z3kgb2Ygb3ZlcmxheSBjb25uZWN0aW9ucyBhbW9uZyBwZWVycyIuICAtLT4gZG9uZQ0KKyBBbHNv IGluIHNlY3Rpb24gMywgInB1bGwtYmFzZWQgZGF0YSBkZWxpdmVyeSBjYWxscyBmb3IgbGFyZ2Ug c2l6ZSBidWZmZXJzIHdoZXJlIHRvIHN0b3JlIGNodW5rcyIgY291bGQgYmUgcmVwaHJhc2VkIGlu dG8gInB1bGwtYmFzZWQgZGF0YSBkZWxpdmVyeSBjYWxscyBmb3IgbGFyZ2Ugc2l6ZSBidWZmZXJz IHRvIHN0b3JlIGNodW5rcyIuIC0tPiBkb25lDQorICJidWZmZXItbWFwcyIgYXJlIHVzZWQgdG8g cmVmZXIgdG8gImNodW5rIGF2YWlsYWJpbGl0eSBpbmZvcm1hdGlvbiIgKGFzIHVzZWQgYnkgUkZD IDY5NzIpLiBGb3Igc2FrZSBvZiBjb25zaXN0ZW5jeSwgSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8g dXNlIHRoZSBsYXR0ZXIgaW5zdGVhZC4gLS0+IEkgcmUtcGhyYXNlZCAiaW4gc29tZSBhcHBsaWNh dGlvbnMgcGVlcnMgZXhjaGFuZ2UgY2h1bmsgYXZhaWxhYmlsaXR5IGluZm9ybWF0aW9uIGluIGZv cm0gb2YgYnVmZmVyLW1hcHMgKGEgc29ydCBvZiBiaXQgbWFwcyB3aXRoIGEgYml0ICIxIiBpbiBj b3JyZXNwb25kZW5jZSBvZiBjaHVua3Mgc3RvcmVkIGluIHRoZSBsb2NhbCBidWZmZXIpIi4gTGlu Z2xpLCBoYXZlIEkgZ290IHlvdXIgcG9pbnQ/DQpbZGxsXSBZZXMuIEkgYW0gT0sgd2l0aCB0aGlz Lg0KKyBJbiBTZWN0aW9uIDMuMi4xIKGwY2hhbm5lbCBzZXJ2ZXIsIHRoYXQgcHJvdmlkZXMgdGhl IGxpc3Qgb2YgYXZhaWxhYmxlIGNoYW5uZWxzIChsaXZlIFRWIG9yIFZvRCBjb250ZW50KSB0byBh IFBQTGl2ZSwgYXMgc29vbiBhcyB0aGUgcGVlciBqb2lucyB0aGUgc3lzdGVtO6GxIHNob3VsZCBi ZSChsGNoYW5uZWwgc2VydmVyLCB0aGF0IHByb3ZpZGVzIHRoZSBsaXN0IG9mIGF2YWlsYWJsZSBj aGFubmVscyAobGl2ZSBUViBvciBWb0QgY29udGVudCkgdG8gYSBQUExpdmUgcGVlciwgYXMgc29v biBhcyB0aGUgcGVlciBqb2lucyB0aGUgc3lzdGVtO6GxIC0tPiBkb25lDQorIEl0IHNlZW1zIHRv IG1lIHRoYXQgdGhlIGNvbnRlbnQgc2VydmVyIG1heSBoYXZlIHBsYXllZCBzb21lIHNvcnQgb2Yg dHJhY2tlcqGvcyByb2xlIGluIE9jdG9zaGFwZSwgb3RoZXJ3aXNlLCBob3cgd291bGQgYSBqb2lu aW5nIHBlZXIgZ2V0cyB0byBrbm93IHRoZSBpbml0aWFsIGFkZHJlc3MgYm9vayBvZiBvdGhlciBw ZWVycz8gLS0+IGRvbmUNCisgSW4gU2VjdGlvbiAzLjIuMywgobBhIG1lY2hhbmlzbSB2ZXJ5IHNp bWlsYXIgdG8gdGhlIG9uZSBvZiBUQ1AgY29uZ2VzdGlvbiB3aW5kb3cgKGRvdWJsZSBpbmNyZWFz ZSBvciBsaW5lYXIgaW5jcmVhc2UgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlIGVzdGltYXRlIGlz IGJlbG93IG9yIGEgZ2l2ZW4gdGhyZXNob2xkKaGxLCBzaG91bGQgYmUgbGlrZSChsGEgbWVjaGFu aXNtIHZlcnkgc2ltaWxhciB0byB0aGUgb25lIG9mIFRDUCBjb25nZXN0aW9uIHdpbmRvdyAoZG91 YmxlIGluY3JlYXNlIG9yIGxpbmVhciBpbmNyZWFzZSBkZXBlbmRpbmcgb24gd2hldGhlciB0aGUg ZXN0aW1hdGUgaXMgYmVsb3cgb3IgYWJvdmUgYSBnaXZlbiB0aHJlc2hvbGQpobEgLS0+IGRvbmUN CisgT25lIG1heSBiZSBjdXJpb3VzIGFib3V0IHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2Vl biBhIKGwcmVwZWF0ZXIgbm9kZaGxIGFuZCBhIKGwc2ltcGxlIHBlZXKhsSwgYXMgdGhlIGRlc2Ny aXB0aW9uIG9mIGEgobByZXBlYXRlciBub2RlobEgZ29lcyBsaWtlIKGwUmVwZWF0ZXIgbm9kZXMs IHRoYXQgc2VydmUgYXMgYmFuZHdpZHRoIG11bHRpcGxpZXIsIGFyZSBhYmxlIHRvIGZvcndhcmQg YW55IHN1Yi1zdHJlYW0gYW5kIGltcGxlbWVudCB0aGUgc2FtZSBwZWVyIHByb3RvY29sIGFzIHNp bXBsZSBwZWVycy6hsSAgLS0+IEkgcmUtcGhyYXNlZCAic2ltcGxlIHBlZXJzLCB3aG9zZSBiZWhh dmlvciBoYXMgYWxyZWFkeSBiZWVuIHByZXNlbnRlZCwgYW5kIHJlcGVhdGVyIG5vZGVzLCB0aGF0 IGltcGxlbWVudCB0aGUgc2FtZSBwZWVyIHByb3RvY29sIGFzIHNpbXBsZSBwZWVycyBhbmQgaW4g YWRkaXRpb24gYXJlIGhpZ2gtYmFuZHdpZHRoIHBlZXJzIGFuZCBhcmUgYWJsZSB0byBmb3J3YXJk IGFueSBzdWItc3RyZWFtLiBJbiBzdWNoIGEgd2F5IHJlcGVhdGVyIG5vZGVzIHNlcnZlIGFzIGJh bmR3aWR0aCBtdWx0aXBsaWVyIi4gIExpbmdsaSwgaGF2ZSBJIGdvdCB5b3VyIHBvaW50Pw0KW2Rs bF0gWWVzLiBJdCB3b3JrcyBmb3IgbWUuDQorIEluIFNlY3Rpb24gMy4yLjQsIKGwYSBQUFN0cmVh bSBwZWVyIHNlbGVjdHMgcGVlcnMgdG8gZG93bmxvYWQgc3ViLWNodW5rcyBmcm9tIGFjY29yZGlu ZyB0byBhIHJhdGUtYmFzZWQgYWxnb3JpdGhtobEgc2hvdWxkIGJlIGNoYW5nZSBpbnRvIKGwYSBQ UFN0cmVhbSBwZWVyIHNlbGVjdHMgcGVlcnMgdG8gZG93bmxvYWQgc3ViLWNodW5rcyBhY2NvcmRp bmcgdG8gYSByYXRlLWJhc2VkIGFsZ29yaXRobaGxICAtLT4gZG9uZQ0KKyBJbiBTZWN0aW9uIDMu MS41LCChsEFzIGFscmVhZHkgc2FpZCwgVHJpYmxlciBzdXBwb3J0cyB2aWRlbyBzdHJlYW1pbmcg aW4gdHdvIGRpZmZlcmVudCBmb3JtczogdmlkZW8gb24gZGVtYW5kIGFuZCBsaXZlIHN0cmVhbWlu Zy6hsSBJcyBiZXR0ZXIgdG8gYmUgY2hhbmdlZCBpbnRvIKGwVHJpYmxlciBzdXBwb3J0cyB2aWRl byBzdHJlYW1pbmcgaW4gdHdvIGRpZmZlcmVudCBmb3JtczogdmlkZW8gb24gZGVtYW5kIGFuZCBs aXZlIHN0cmVhbWluZy6hsSwgc2luY2UgdGhlcmUgaXMgbm8gcHJpb3Igc3RhdGVtZW50IGluIHRo ZSBkcmFmdC4gLS0+IGRvbmUNCisgQWxzbyBpbiBTZWN0aW9uIDMuMS41LCChsFN1Y2ggYSBtZWNo YW5pc20gYWxsb3dzIFRyaWJsZXIgcGVlcnMgdG8gdXNlIHRoZSBwdWJsaWMga2V5IGluY2x1ZGVk IGluIHRvcnJlbnQgZmlsZSBhbmQgdmVyaXR5IHRoZSBpbnRlZ3JpdHkgb2YgZWFjaCBjaHVuay6h sSBzaG91bGQgYmUgY2hhbmdlZCBpbnRvIKGwU3VjaCBhIG1lY2hhbmlzbSBhbGxvd3MgVHJpYmxl ciBwZWVycyB0byB1c2UgdGhlIHB1YmxpYyBrZXkgaW5jbHVkZWQgaW4gdG9ycmVudCBmaWxlIGFu ZCB2ZXJpZnkgdGhlIGludGVncml0eSBvZiBlYWNoIGNodW5rLqGxIC0tPiBMaW5nbGksIEkgdGhp bmsgeW91ciBjb21tZW50IGFmdGVyIHRoZSBzdWJzZXF1ZW50IG9uZSBpcyBjb3JyZWN0LiBTbyBJ IGNvbXBsZXRlbHkgcmVtb3ZlZCB0aGlzIHBhcnQuIFNlZSBteSBvYnNlcnZhdGlvbiBsYXRlciBv bi4gRG8geW91IGFncmVlPw0KW2RsbF0gUGx6IHNlZSBteSBjb21tZW50IGJlbG93Lg0KKyBUaGVy ZSBpcyBjb25zaWRlcmFibGUgcmVmZXJlbmNlIGFuZCBjb21wYXJpc29uIHRvIHRoZSBCaXRvcnJl bnQgc3lzdGVtL21vZGVsIGluIHRoZSBUcmlibGVyoa9zIHN1YnNlY3Rpb24sIG9uZSBtYXkgd29u ZGVyIHdoeSBub3QgcG9zZSBhIHNlcGFyYXRlIHNlY3Rpb24gZm9yIGludHJvZHVjdGlvbiBvZiBC aXR0b3JyZW50IGluc3RlYWQ/IExpbmdsaSwgSSBkb24ndCB0aGluayB0aGlzIGlzIHRoZSBjYXNl LCBiZWNhdXNlIEJpdCBUb3JyZW50IGlzIGEgUDJQIGZpbGUgc2hhcmluZyBzeXN0ZW0gYW5kIEkg aGF2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IGEgc2VjdGlvbiBkZXZvdGVkIHRvIGEgUDJQIGZpbGUg c2hhcmluZyBzeXN0ZW0gY291bGQgYXBwZWFyIHNvbWVob3cgb3V0IG9mIHNjb3BlLiBJbiBhZGRp dGlvbiwgZXZlcnkgdGltZSBCaXQgVG9ycmVudCBpcyBjaXRlZCwgd2UgYWx3YXlzIHRyaWVkIHRv IHByb3ZpZGUgdGhlIG5lY2Vzc2FyeSBiYWNrZ3JvdW5kIGluZm8uIERvZXMgaXQgbWFrZSBzZW5z ZT8NCltkbGxdIFlvdSBhcmUgcmlnaHQsIHNpbmNlIEJpdHRvcmVudCBpcyBub3QgYSBzdHJlYW1p bmcgc3lzdGVtLCBpdCBzZWVtcyBvdXQgb2Ygc2NvcGUuIEl0IGlzIGEgYmFkIGlkZWEsIGZvcmdl dCBpdC4NCisgSXQgaXMgbm90aWNlYWJsZSB0aGF0IGJvdGggdGhlIFRyaWJsZXKhr3MgcGVlciBz ZWxlY3Rpb24gYWxnb3JpdGhtIGFuZCBzZWN1cml0eSBtZWNoYW5pc21zIGFyZSBlbGFib3JhdGVk IGluIHN1Y2ggYSBkZXRhaWxlZCB3YXk/IFdoYXQgYWJvdXQgb3RoZXIgc3lzdGVtcyBpbiB0ZXJt cyBvZiBzaW1pbGFyIGRlc2lnbiBpc3N1ZXM/IFNpbmNlIFNlY3Rpb24gMyBpcyBmb2N1cyBtYWlu bHkgb24gdGhlIHBlZXIgdG9wb2xvZ3ksIG1heWJlIHNlcGFyYXRlIHNlY3Rpb25zIG9uIGFsZ29y aXRobS9zZWN1cml0eSBhcmUgbW9yZSBuYXR1cmFsIGZvciBiZXR0ZXIgY29tcHJlc3Npb24uIC0t PiBMaW5nbGksIHRoZSBtYWluIHByb2JsZW0gaGVyZSBpcyB0aGF0IHN1Y2ggYSBsZXZlbCBvZiBk ZXRhaWwgaXMgb2Z0ZW4gbm90IGF2YWlsYWJsZSBmb3IgYWxsIHRoZSBhcHBsaWNhdGlvbnMuIFJl Z2FyZGluZyB0aGlzIHBvaW50IEkgYWxzbyBhZGRlZCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudCBp biAiSW50cm9kdWN0aW9uIiBzZWN0aW9uICJJbiBhZGRpdGlvbiwgdGhlIHByb3ZpZGVkIGRlc2Ny aXB0aW9ucyBtYXkgc29tZXRpbWVzIGFwcGVhciBpbmhvbW9nZW5lb3VzIGZyb20gdGhlIGRldGFp bCBsZXZlbCBwb2ludCBvZiB2aWV3LCBidXQgdGhpcyBhbHdheXMgZGVwZW5kcyBvbiB0aGUgYW1v dW50IG9mIGF2YWlsYWJsZSBpbmZvcm1hdGlvbiBhdCB3cml0aW5nIHRpbWUuIi4gIFNvIHRoZSBv bmx5IHNvbHV0aW9uIHNlZW1zIHRvIG1lIHRvIHJlbW92ZSB0aGUgcmVmZXJlbmNlIHRvIHRoZSBz ZWN1cml0eSBtZWNoYW5pc21zLiBUaGUgcGVlciBzZWxlY3Rpb24gYWxnb3JpdGhtIGlzIGZ1bGwg cGFydCBvZiB0aGUgcGVlciBwcm90b2NvbCBpbiBteSBvcGluaW9uIGFuZCBpdCBoYXMgdG8gYmUg a2VwdC4gQnV0IGkgd291bGQgbGlrZSB0byBoZWFyIGZyb20geW91Lg0KW2RsbF0gSSBzZWUgeW91 ciBwb2ludC4gSG93ZXZlciwgSSB3b3VsZCBub3QgYWdyZWUgdGhhdCBzZWN1cml0eSBpcyBub3Qg YXMgaW1wb3J0YW50IGFzIHBlZXIgc2VsZWN0aW9uIGFsZ29yaXRobS4gV291bGQgaXQgYmUgcG9z c2libGUgdG8gZmVlZCBpdCBpbnRvIKGwc2VjdXJpdHkgY29uc2lkZXJhdGlvbnOhsT8NCisgSW4g U2VjdGlvbiAzLjEuNiwgd2hhdCBkb2VzIGl0IG1lYW4gYnkgobBub3QgUlRQL1JUQ1ChsSBpbiCh sHRoZSBjbGllbnQgdXNlIFVEUCB0byB0cmFuc2ZlciB0aGUgZW5jcnlwdGVkIG1lZGlhIHN0cmVh bWluZyBhbmQgbm90IFJUUC8gUlRDUC6hsT8gLS0+IER1YW4sIGlmIEkgcmVtZW1iZXIgY29ycmVj dGx5LCB5b3UgcHJvdmlkZWQgdGhpcyBwYXJ0LiBDYW4geW91IHBsZWFzZSBleHBsYWluPw0KKyBJ biBTZWN0aW9uIDMuMy4xLCChsFBhcmVudCByZS1zZWxlY3Rpb24gaXMgYWxzbyBhcHBsaWVkIGlu IGNhc2Ugb2YgbGVhdmluZyBvZiB0aGUgcHJldmlvdXMgcGFyZW50LqGxIElzIGJldHRlciB0byBi ZSBjaGFuZ2VkIGludG8gobBQYXJlbnQgcmUtc2VsZWN0aW9uIGlzIGFsc28gdHJpZ2dlcmVkIGZv ciBhIHBlZXIgd2hlbiBpdHMgcHJldmlvdXMgcGFyZW50IGxlYXZlcy6hsSAtLT4gZG9uZQ0KKyBG cm9tIHRoZSBkZXNjcmlwdGlvbiBpbiBTZWN0aW9uIDMuMy4xLCBpdCBpcyBub3QgY2xlYXIgdG8g bWUgd2h5IHRoZSBRUUxpdmWhr3MgdG9wb2xvZ3kgaXMgYSBoeWJyaWQgb2YgbWVzaCBhbmQgdHJl ZS4gIC0tPiBMaW5nbGksIHRoaXMgY29tbWVudCBpcyBub3QgY29tcGxldGVseSBjbGVhciBmb3Ig bWUuIFByb2JhYmx5IHlvdSBtZWFudCBOZXcgQ29vbHN0cmVhbWluZy4gSWYgc28sIE5ldyBDb29s c3RyZWFtaW5nIG1heSBiZSByZWdhcmRlZCBhcyBoeWJyaWQsIGJlY2F1c2Ugb24gdGhlIG9uZSBz aWRlIHlvdSBoYXZlIGFuIG92ZXJsYXkgbWVzaCwgb24gdGhlIG90aGVyIHNpZGUgeW91IGhhdmUg YXMgbWFueSB0cmVlcyBhcyBzdWJzdHJlYW1zLiBJIGFsc28gYWRkZWQgdGhlIGZvbGxvd2luZyBz dGF0ZW1lbnQgIkhlbmNlLCB0aGUgb3ZlcmFsbCBvdmVybGF5IHRvcG9sb2d5IGlzIG1lc2gtYmFz ZWQsIGJ1dCBpdCBpcyBhbHNvIHBvc3NpYmxlIHRvIGlkZW50aWZ5IGFzIG1hbnkgb3ZlcmxheSB0 cmVlcyBhcyBzdWItc3RyZWFtcy4iLiBJcyBpdCBjbGVhcmVyIG5vdz8NCiBbZGxsXSBTb3JyeSBm b3IgdGhlIHR5cG8sIEkgZGlkIG1lYW4gTmV3IENvb2xzdHJlYW1pbmcuIEkgYW0gZmluZSB3aXRo IHRoZSBjbGFyaWZpY2F0aW9uLg0KDQoNCjIwMTMvMTIvNCBGcmFuY2VzY2EgTG8gUGljY29sbyAo ZmxvcGljY28pIDxmbG9waWNjb0BjaXNjby5jb208bWFpbHRvOmZsb3BpY2NvQGNpc2NvLmNvbT4+ DQpEdWFuIGFuZCBhbGwsDQoNCkkgYWJzb2x1dGVseSBhZ3JlZSB3aXRoIHlvdSBvbiB0aGUgZ29v ZCBxdWFsaXR5IG9mIHJlY2VpdmVkIGZlZWRiYWNrIGFuZCBvbiB0aGUgbmVjZXNzaXR5IHRvIGZp eCBzb21lIHBhcnRzIGluIHRoZSBzdXJ2ZXkgZHJhZnQuDQoNClRvIHRoaXMgZW5kLCBJJ20gYXR0 YWNoaW5nIGEgbmV3IHJldmlzaW9uIG9mIHRoZSBzdXJ2ZXkgKGFuZCBhbHNvIG9mIHRoZSBwaWN0 dXJlcyksIHdoZXJlIG1vc3Qgb2YgdGhlIGNvbW1lbnRzIGZyb20gUmFjaGVsLCBSb25pIGFuZCBM aW5nbGkgaGF2ZSBiZWVuIGFscmVhZHkgdGFrZW4gaW50byBhY2NvdW50Lg0KDQpIZXJlIGlzIGEg c3VtbWFyeSBvZiBhbGwgdGhlIHJlY2VpdmVkIGNvbW1lbnRzLCB3aXRoIHRoZSBvbmVzIHN0aWxs IG9wZW4gaGlnaGxpZ2h0ZWQgaW4gcmVkLiBMaW5nbGksIHlvdSBhcmUgYW1vbmcgdGhlICJ0byIg cmVjZWl2ZXJzLCBiZWNhdXNlIHRoZXJlIGlzIHNvbWUgeW91ciBjb21tZW50IEkgd291bGQgbGlr ZSB0byBmdXJ0aGVyIGRpc2N1c3Mgd2l0aCB5b3UuDQoNClJhY2hlbA0KLS0tLS0tLS0tDQorIFRo ZSBkZXNjcmlwdGlvbiBpbiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAxIGlzIGluY29u c2lzdGVudCB3aXRoIHRoZSBvcmdhbml6YXRpb24gb2YgY2hhcHRlcnMgLiBUaGlzIHNob3VsZCBi ZSBmaXhlZC4gLS0+IE5pbmcsIGlzIGl0IHBvc3NpYmxlIHRvIHR1cm4gc2VjdGlvbiAzLjEgKGFu ZCBzdWJzZWN0aW9ucykgaW50byBzZWN0aW9uIDQgYW5kIDMuMiAoYW5kIHN1YnNlY3Rpb25zKSBp biBzZWN0aW9uIDUgYW5kIDMuMyAoYW5kIHN1YnNlY3Rpb25zKSBpbiBzZWN0aW9uIDY/DQorIElu IHNlY3Rpb24gMiwgc29tZSB0ZXJtaW5vbG9naWVzIGhhdmUgYWxyZWFkeSBkZWZpbmVkIGluIFJG QzY5NzIuIEl0oa9zIHVubmVjZXNzYXJ5IHRvIHJlcGVhdCB0aGUgZGVmaW5pdGlvbiwgZS5nLiwg Y2h1bmssIGxpdmUgc3RyZWFtaW5noa0gLS0+IGRvbmUNCisgU2VjdGlvbiAxIHR5cG86IKGwd2Ug YWx3YXlzIHRyeSB0byBpZGVudGl0eSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sc6GxIHNob3Vs ZCBiZSChsHdlIGFsd2F5cyB0cnkgdG8gaWRlbnRpZnkgdHJhY2tlciBhbmQgcGVlciBwcm90b2Nv bHOhsSAtLT4gZG9uZQ0KKyBTZWN0aW9uIDMuMSwgdHlwbyChsHRoaXMgbWF5IHR1cm4gYXQgZW5k IHVzZXJzIGludG8gcGxheWJhY2sgcXVhbGl0eSBkZWdyYWRhdGlvbqGxIHNob3VsZCBiZSChsHRo aXMgbWF5IHR1cm4gZW5kIHVzZXJzIGludG8gcGxheWJhY2sgcXVhbGl0eSBkZWdyYWRhdGlvbqGx IC0tPiBkb25lDQorIEl0oa9zIGJldHRlciB0byBhZGp1c3QgdGhlIG9yZGVyIG9mIHR5cGVzIG9m IFAyUCBzdHJlYW1pbmcgYXBwbGljYXRpb25zIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgb3Jk ZXIgb2Ygc3Vic2VjdGlvbnMsIHdoaWNoIG1lYW5zIKGwbWVzaC1iYXNlZKGxIHNob3VsZCBiZSBm aXJzdCwgdGhlbiChsHRyZWUtYmFzZWShsS4gLS0+IGRvbmUNCg0KUm9uaQ0KLS0tLS0tDQorIEZp Z3VyZSAxIKGwdHJha2VyobEgc2hvdWxkIGJlIKGwdHJhY2tlcqGxICAtLT4gZG9uZQ0KKyBJbiBz ZWN0aW9uIDMuMS4yIG9uIFBQTGl2ZSBjaGFuZ2UgobBiZWluZyB0aGUgbmF0dXJlIG9mIFBQTGl2 ZSBwcm90b2NvbHMgYW5kIGFsZ29yaXRobSBwcm9wcmlldGFyeaGxIHRvIKGwIFNpbmNlIHRoZSBw cm90b2NvbHMgYW5kIGFsZ29yaXRobSBvZiBQUExJVkUgYXJlIHByb3ByaWV0YXJ5obEgIC0tPiBk b25lDQorIEluIHNlY3Rpb24gMy4xLjMgobAgQXV0aGVudGljYXRpb24gc2VydmVyIGlzIHRoZSBm aXJzdCBwb2ludCBvZiBjb250YWN0IGZvciBhIHBlZXIgdGhlIGpvaW5zIHRoZSBzeXN0ZW2hsSB0 byChsEF1dGhlbnRpY2F0aW9uIHNlcnZlciBpcyB0aGUgZmlyc3QgcG9pbnQgb2YgY29udGFjdCBm b3IgYSBwZWVyIHRoYXQgam9pbnMgdGhlIHN5c3RlbaGxIC0tPiBkb25lDQorIEluIHNlY3Rpb24g My4xLjMgobAgY2FuIGNvbnRhY3QgbmV3IG1vcmUgcGVlcnMgYmVzaWRlcyB0aGUgb25lcyBpbmRp Y2F0ZWQgYnkgdGhlIHJlbmRlenZvdXMgc2VydmVyobEgdG8gobBjYW4gY29udGFjdCBuZXcgcGVl cnMgYmVzaWRlcyB0aGUgb25lcyBpbmRpY2F0ZWQgYnkgdGhlIHJlbmRlenZvdXMgc2VydmVyobEg LS0+IGRvbmUNCisgSW4gc2VjdGlvbiAzLjEuNSChsFNpbmNlIGNoaWxkcmVuIGNvdWxkIGxpZSBy ZWdhcmRpbmcgdGhlIG51bWJlciBvZiBjaHVua3MgZm9yd2FyZGVkIHRvIG90aGVycywgVHJpYmxl ciBwZWVycyBkbyBkaXJlY3RseSBub3QgYXNrIHRoZWlyIGNoaWxkcmVuLCBidXQgdGhlaXIgZ3Jh bmRjaGlsZHJlbi6hsSBUbyChsFNpbmNlIGNoaWxkcmVuIGNvdWxkIGxpZSByZWdhcmRpbmcgdGhl IG51bWJlciBvZiBjaHVua3MgZm9yd2FyZGVkIHRvIG90aGVycywgVHJpYmxlciBwZWVycyBkbyBu b3QgYXNrIHRoZWlyIGNoaWxkcmVuIGRpcmVjdGx5LCBidXQgdGhlaXIgZ3JhbmRjaGlsZHJlbi6h sSAtLT4gZG9uZQ0KKyBJbiBzZWN0aW9uIDMuMS42IHdoZW4gZmlyc3QgdXNpbmcgQ0ROIGV4cGFu ZCB0byBDb250ZW50IERlbGl2ZXJ5IE5ldHdvcmsgKENETikgLS0+IGRvbmUNCg0KDQpMaW5nbGkN Ci0tLS0tLS0NCisgaXQgc3RhdGVzIGFzIGEgInN0YW5kYXJkIHRyYWNrIiBkb2N1bWVudCwgaXMg dGhhdCBhY2N1cmF0ZT8gLS0+IE5pbmcsIHdlIGFscmVhZHkgZGlzY3Vzc2VkIGFib3V0IHRoaXMu IEFzIHBlciB5b3VyIGNvbW1lbnQsIHRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIKGwaW5mb3JtYXRp b25hbKGxLCByYXRoZXIgdGhhbiChsHN0YW5kYXJkIHRyYWNrobEuIEkgYXNzdW1lIHRoaXMgaXMg c29tZXRoaW5nIHlvdSBjYW4gdGFrZSBpbnRvIGFjY291bnQgYXMgc29vbiBhcyB5b3Ugd2lsbCBz dWJtaXQgdGhlIGZpbmFsIHJldmlzaW9uLCByaWdodD8NCisgaW4gdGVybWlub2xveSBzZWN0aW9u LCAicHVzaCIgaXMgZGVmaW5lZCBhcyAiVHJhbnNtaXNzaW9uIG9mIG11bHRpbWVkaWEgY29udGVu dCB3aXRob3V0IGFueSByZXF1ZXN0IGZyb20gcmVjZWl2aW5nIHBlZXJzLiIsIHdoaWNoIEkgdGhp bmsgY291bGQgYmUgYmV0dGVyIGRlc2NyaWJlZCBhcyAiVHJhbnNtaXNzaW9uIG9mIG11bHRpbWVk aWEgY29udGVudCB0aGF0IGlzIG5vdCBpbml0aWF0ZWQgYnkgcmVjZWl2aW5nIHBlZXJzLiIgLS0+ IGRvbmUNCisgSW4gc2VjdGlvbiAzLCAidGhlIHRvcG9sb2d5IHRoYXQgY2FuIGJlIGFzc29jaWF0 ZWQgd2l0aCBvdmVybGF5IGNvbm5lY3Rpb25zIGFtb25nIHBlZXJzIiBjb3VsZCBiZSByZXBocmFz ZWQgaW50byAidGhlIHRvcG9sb2d5IG9mIG92ZXJsYXkgY29ubmVjdGlvbnMgYW1vbmcgcGVlcnMi LiAgLS0+IGRvbmUNCisgQWxzbyBpbiBzZWN0aW9uIDMsICJwdWxsLWJhc2VkIGRhdGEgZGVsaXZl cnkgY2FsbHMgZm9yIGxhcmdlIHNpemUgYnVmZmVycyB3aGVyZSB0byBzdG9yZSBjaHVua3MiIGNv dWxkIGJlIHJlcGhyYXNlZCBpbnRvICJwdWxsLWJhc2VkIGRhdGEgZGVsaXZlcnkgY2FsbHMgZm9y IGxhcmdlIHNpemUgYnVmZmVycyB0byBzdG9yZSBjaHVua3MiLiAtLT4gZG9uZQ0KKyAiYnVmZmVy LW1hcHMiIGFyZSB1c2VkIHRvIHJlZmVyIHRvICJjaHVuayBhdmFpbGFiaWxpdHkgaW5mb3JtYXRp b24iIChhcyB1c2VkIGJ5IFJGQyA2OTcyKS4gRm9yIHNha2Ugb2YgY29uc2lzdGVuY3ksIEkgdGhp bmsgaXQgaXMgYmV0dGVyIHRvIHVzZSB0aGUgbGF0dGVyIGluc3RlYWQuIC0tPiBJIHJlLXBocmFz ZWQgImluIHNvbWUgYXBwbGljYXRpb25zIHBlZXJzIGV4Y2hhbmdlIGNodW5rIGF2YWlsYWJpbGl0 eSBpbmZvcm1hdGlvbiBpbiBmb3JtIG9mIGJ1ZmZlci1tYXBzIChhIHNvcnQgb2YgYml0IG1hcHMg d2l0aCBhIGJpdCAiMSIgaW4gY29ycmVzcG9uZGVuY2Ugb2YgY2h1bmtzIHN0b3JlZCBpbiB0aGUg bG9jYWwgYnVmZmVyKSIuIExpbmdsaSwgaGF2ZSBJIGdvdCB5b3VyIHBvaW50Pw0KKyBJbiBTZWN0 aW9uIDMuMi4xIKGwY2hhbm5lbCBzZXJ2ZXIsIHRoYXQgcHJvdmlkZXMgdGhlIGxpc3Qgb2YgYXZh aWxhYmxlIGNoYW5uZWxzIChsaXZlIFRWIG9yIFZvRCBjb250ZW50KSB0byBhIFBQTGl2ZSwgYXMg c29vbiBhcyB0aGUgcGVlciBqb2lucyB0aGUgc3lzdGVtO6GxIHNob3VsZCBiZSChsGNoYW5uZWwg c2VydmVyLCB0aGF0IHByb3ZpZGVzIHRoZSBsaXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscyAobGl2 ZSBUViBvciBWb0QgY29udGVudCkgdG8gYSBQUExpdmUgcGVlciwgYXMgc29vbiBhcyB0aGUgcGVl ciBqb2lucyB0aGUgc3lzdGVtO6GxIC0tPiBkb25lDQorIEl0IHNlZW1zIHRvIG1lIHRoYXQgdGhl IGNvbnRlbnQgc2VydmVyIG1heSBoYXZlIHBsYXllZCBzb21lIHNvcnQgb2YgdHJhY2tlcqGvcyBy b2xlIGluIE9jdG9zaGFwZSwgb3RoZXJ3aXNlLCBob3cgd291bGQgYSBqb2luaW5nIHBlZXIgZ2V0 cyB0byBrbm93IHRoZSBpbml0aWFsIGFkZHJlc3MgYm9vayBvZiBvdGhlciBwZWVycz8gLS0+IGRv bmUNCisgSW4gU2VjdGlvbiAzLjIuMywgobBhIG1lY2hhbmlzbSB2ZXJ5IHNpbWlsYXIgdG8gdGhl IG9uZSBvZiBUQ1AgY29uZ2VzdGlvbiB3aW5kb3cgKGRvdWJsZSBpbmNyZWFzZSBvciBsaW5lYXIg aW5jcmVhc2UgZGVwZW5kaW5nIG9uIHdoZXRoZXIgdGhlIGVzdGltYXRlIGlzIGJlbG93IG9yIGEg Z2l2ZW4gdGhyZXNob2xkKaGxLCBzaG91bGQgYmUgbGlrZSChsGEgbWVjaGFuaXNtIHZlcnkgc2lt aWxhciB0byB0aGUgb25lIG9mIFRDUCBjb25nZXN0aW9uIHdpbmRvdyAoZG91YmxlIGluY3JlYXNl IG9yIGxpbmVhciBpbmNyZWFzZSBkZXBlbmRpbmcgb24gd2hldGhlciB0aGUgZXN0aW1hdGUgaXMg YmVsb3cgb3IgYWJvdmUgYSBnaXZlbiB0aHJlc2hvbGQpobEgLS0+IGRvbmUNCisgT25lIG1heSBi ZSBjdXJpb3VzIGFib3V0IHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhIKGwcmVwZWF0 ZXIgbm9kZaGxIGFuZCBhIKGwc2ltcGxlIHBlZXKhsSwgYXMgdGhlIGRlc2NyaXB0aW9uIG9mIGEg obByZXBlYXRlciBub2RlobEgZ29lcyBsaWtlIKGwUmVwZWF0ZXIgbm9kZXMsIHRoYXQgc2VydmUg YXMgYmFuZHdpZHRoIG11bHRpcGxpZXIsIGFyZSBhYmxlIHRvIGZvcndhcmQgYW55IHN1Yi1zdHJl YW0gYW5kIGltcGxlbWVudCB0aGUgc2FtZSBwZWVyIHByb3RvY29sIGFzIHNpbXBsZSBwZWVycy6h sSAgLS0+IEkgcmUtcGhyYXNlZCAic2ltcGxlIHBlZXJzLCB3aG9zZSBiZWhhdmlvciBoYXMgYWxy ZWFkeSBiZWVuIHByZXNlbnRlZCwgYW5kIHJlcGVhdGVyIG5vZGVzLCB0aGF0IGltcGxlbWVudCB0 aGUgc2FtZSBwZWVyIHByb3RvY29sIGFzIHNpbXBsZSBwZWVycyBhbmQgaW4gYWRkaXRpb24gYXJl IGhpZ2gtYmFuZHdpZHRoIHBlZXJzIGFuZCBhcmUgYWJsZSB0byBmb3J3YXJkIGFueSBzdWItc3Ry ZWFtLiBJbiBzdWNoIGEgd2F5IHJlcGVhdGVyIG5vZGVzIHNlcnZlIGFzIGJhbmR3aWR0aCBtdWx0 aXBsaWVyIi4gIExpbmdsaSwgaGF2ZSBJIGdvdCB5b3VyIHBvaW50Pw0KKyBJbiBTZWN0aW9uIDMu Mi40LCChsGEgUFBTdHJlYW0gcGVlciBzZWxlY3RzIHBlZXJzIHRvIGRvd25sb2FkIHN1Yi1jaHVu a3MgZnJvbSBhY2NvcmRpbmcgdG8gYSByYXRlLWJhc2VkIGFsZ29yaXRobaGxIHNob3VsZCBiZSBj aGFuZ2UgaW50byChsGEgUFBTdHJlYW0gcGVlciBzZWxlY3RzIHBlZXJzIHRvIGRvd25sb2FkIHN1 Yi1jaHVua3MgYWNjb3JkaW5nIHRvIGEgcmF0ZS1iYXNlZCBhbGdvcml0aG2hsSAgLS0+IGRvbmUN CisgSW4gU2VjdGlvbiAzLjEuNSwgobBBcyBhbHJlYWR5IHNhaWQsIFRyaWJsZXIgc3VwcG9ydHMg dmlkZW8gc3RyZWFtaW5nIGluIHR3byBkaWZmZXJlbnQgZm9ybXM6IHZpZGVvIG9uIGRlbWFuZCBh bmQgbGl2ZSBzdHJlYW1pbmcuobEgSXMgYmV0dGVyIHRvIGJlIGNoYW5nZWQgaW50byChsFRyaWJs ZXIgc3VwcG9ydHMgdmlkZW8gc3RyZWFtaW5nIGluIHR3byBkaWZmZXJlbnQgZm9ybXM6IHZpZGVv IG9uIGRlbWFuZCBhbmQgbGl2ZSBzdHJlYW1pbmcuobEsIHNpbmNlIHRoZXJlIGlzIG5vIHByaW9y IHN0YXRlbWVudCBpbiB0aGUgZHJhZnQuIC0tPiBkb25lDQorIEFsc28gaW4gU2VjdGlvbiAzLjEu NSwgobBTdWNoIGEgbWVjaGFuaXNtIGFsbG93cyBUcmlibGVyIHBlZXJzIHRvIHVzZSB0aGUgcHVi bGljIGtleSBpbmNsdWRlZCBpbiB0b3JyZW50IGZpbGUgYW5kIHZlcml0eSB0aGUgaW50ZWdyaXR5 IG9mIGVhY2ggY2h1bmsuobEgc2hvdWxkIGJlIGNoYW5nZWQgaW50byChsFN1Y2ggYSBtZWNoYW5p c20gYWxsb3dzIFRyaWJsZXIgcGVlcnMgdG8gdXNlIHRoZSBwdWJsaWMga2V5IGluY2x1ZGVkIGlu IHRvcnJlbnQgZmlsZSBhbmQgdmVyaWZ5IHRoZSBpbnRlZ3JpdHkgb2YgZWFjaCBjaHVuay6hsSAt LT4gTGluZ2xpLCBJIHRoaW5rIHlvdXIgY29tbWVudCBhZnRlciB0aGUgc3Vic2VxdWVudCBvbmUg aXMgY29ycmVjdC4gU28gSSBjb21wbGV0ZWx5IHJlbW92ZWQgdGhpcyBwYXJ0LiBTZWUgbXkgb2Jz ZXJ2YXRpb24gbGF0ZXIgb24uIERvIHlvdSBhZ3JlZT8NCisgVGhlcmUgaXMgY29uc2lkZXJhYmxl IHJlZmVyZW5jZSBhbmQgY29tcGFyaXNvbiB0byB0aGUgQml0b3JyZW50IHN5c3RlbS9tb2RlbCBp biB0aGUgVHJpYmxlcqGvcyBzdWJzZWN0aW9uLCBvbmUgbWF5IHdvbmRlciB3aHkgbm90IHBvc2Ug YSBzZXBhcmF0ZSBzZWN0aW9uIGZvciBpbnRyb2R1Y3Rpb24gb2YgQml0dG9ycmVudCBpbnN0ZWFk PyBMaW5nbGksIEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyB0aGUgY2FzZSwgYmVjYXVzZSBCaXQgVG9y cmVudCBpcyBhIFAyUCBmaWxlIHNoYXJpbmcgc3lzdGVtIGFuZCBJIGhhdmUgdGhlIGltcHJlc3Np b24gdGhhdCBhIHNlY3Rpb24gZGV2b3RlZCB0byBhIFAyUCBmaWxlIHNoYXJpbmcgc3lzdGVtIGNv dWxkIGFwcGVhciBzb21laG93IG91dCBvZiBzY29wZS4gSW4gYWRkaXRpb24sIGV2ZXJ5IHRpbWUg Qml0IFRvcnJlbnQgaXMgY2l0ZWQsIHdlIGFsd2F5cyB0cmllZCB0byBwcm92aWRlIHRoZSBuZWNl c3NhcnkgYmFja2dyb3VuZCBpbmZvLiBEb2VzIGl0IG1ha2Ugc2Vuc2U/DQorIEl0IGlzIG5vdGlj ZWFibGUgdGhhdCBib3RoIHRoZSBUcmlibGVyoa9zIHBlZXIgc2VsZWN0aW9uIGFsZ29yaXRobSBh bmQgc2VjdXJpdHkgbWVjaGFuaXNtcyBhcmUgZWxhYm9yYXRlZCBpbiBzdWNoIGEgZGV0YWlsZWQg d2F5PyBXaGF0IGFib3V0IG90aGVyIHN5c3RlbXMgaW4gdGVybXMgb2Ygc2ltaWxhciBkZXNpZ24g aXNzdWVzPyBTaW5jZSBTZWN0aW9uIDMgaXMgZm9jdXMgbWFpbmx5IG9uIHRoZSBwZWVyIHRvcG9s b2d5LCBtYXliZSBzZXBhcmF0ZSBzZWN0aW9ucyBvbiBhbGdvcml0aG0vc2VjdXJpdHkgYXJlIG1v cmUgbmF0dXJhbCBmb3IgYmV0dGVyIGNvbXByZXNzaW9uLiAtLT4gTGluZ2xpLCB0aGUgbWFpbiBw cm9ibGVtIGhlcmUgaXMgdGhhdCBzdWNoIGEgbGV2ZWwgb2YgZGV0YWlsIGlzIG9mdGVuIG5vdCBh dmFpbGFibGUgZm9yIGFsbCB0aGUgYXBwbGljYXRpb25zLiBSZWdhcmRpbmcgdGhpcyBwb2ludCBJ IGFsc28gYWRkZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgaW4gIkludHJvZHVjdGlvbiIgc2Vj dGlvbiAiSW4gYWRkaXRpb24sIHRoZSBwcm92aWRlZCBkZXNjcmlwdGlvbnMgbWF5IHNvbWV0aW1l cyBhcHBlYXIgaW5ob21vZ2VuZW91cyBmcm9tIHRoZSBkZXRhaWwgbGV2ZWwgcG9pbnQgb2Ygdmll dywgYnV0IHRoaXMgYWx3YXlzIGRlcGVuZHMgb24gdGhlIGFtb3VudCBvZiBhdmFpbGFibGUgaW5m b3JtYXRpb24gYXQgd3JpdGluZyB0aW1lLiIuICBTbyB0aGUgb25seSBzb2x1dGlvbiBzZWVtcyB0 byBtZSB0byByZW1vdmUgdGhlIHJlZmVyZW5jZSB0byB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtcy4g VGhlIHBlZXIgc2VsZWN0aW9uIGFsZ29yaXRobSBpcyBmdWxsIHBhcnQgb2YgdGhlIHBlZXIgcHJv dG9jb2wgaW4gbXkgb3BpbmlvbiBhbmQgaXQgaGFzIHRvIGJlIGtlcHQuIEJ1dCBpIHdvdWxkIGxp a2UgdG8gaGVhciBmcm9tIHlvdS4NCisgSW4gU2VjdGlvbiAzLjEuNiwgd2hhdCBkb2VzIGl0IG1l YW4gYnkgobBub3QgUlRQL1JUQ1ChsSBpbiChsHRoZSBjbGllbnQgdXNlIFVEUCB0byB0cmFuc2Zl ciB0aGUgZW5jcnlwdGVkIG1lZGlhIHN0cmVhbWluZyBhbmQgbm90IFJUUC8gUlRDUC6hsT8gLS0+ IER1YW4sIGlmIEkgcmVtZW1iZXIgY29ycmVjdGx5LCB5b3UgcHJvdmlkZWQgdGhpcyBwYXJ0LiBD YW4geW91IHBsZWFzZSBleHBsYWluPw0KKyBJbiBTZWN0aW9uIDMuMy4xLCChsFBhcmVudCByZS1z ZWxlY3Rpb24gaXMgYWxzbyBhcHBsaWVkIGluIGNhc2Ugb2YgbGVhdmluZyBvZiB0aGUgcHJldmlv dXMgcGFyZW50LqGxIElzIGJldHRlciB0byBiZSBjaGFuZ2VkIGludG8gobBQYXJlbnQgcmUtc2Vs ZWN0aW9uIGlzIGFsc28gdHJpZ2dlcmVkIGZvciBhIHBlZXIgd2hlbiBpdHMgcHJldmlvdXMgcGFy ZW50IGxlYXZlcy6hsSAtLT4gZG9uZQ0KKyBGcm9tIHRoZSBkZXNjcmlwdGlvbiBpbiBTZWN0aW9u IDMuMy4xLCBpdCBpcyBub3QgY2xlYXIgdG8gbWUgd2h5IHRoZSBRUUxpdmWhr3MgdG9wb2xvZ3kg aXMgYSBoeWJyaWQgb2YgbWVzaCBhbmQgdHJlZS4gIC0tPiBMaW5nbGksIHRoaXMgY29tbWVudCBp cyBub3QgY29tcGxldGVseSBjbGVhciBmb3IgbWUuIFByb2JhYmx5IHlvdSBtZWFudCBOZXcgQ29v bHN0cmVhbWluZy4gSWYgc28sIE5ldyBDb29sc3RyZWFtaW5nIG1heSBiZSByZWdhcmRlZCBhcyBo eWJyaWQsIGJlY2F1c2Ugb24gdGhlIG9uZSBzaWRlIHlvdSBoYXZlIGFuIG92ZXJsYXkgbWVzaCwg b24gdGhlIG90aGVyIHNpZGUgeW91IGhhdmUgYXMgbWFueSB0cmVlcyBhcyBzdWJzdHJlYW1zLiBJ IGFsc28gYWRkZWQgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgIkhlbmNlLCB0aGUgb3ZlcmFsbCBv dmVybGF5IHRvcG9sb2d5IGlzIG1lc2gtYmFzZWQsIGJ1dCBpdCBpcyBhbHNvIHBvc3NpYmxlIHRv IGlkZW50aWZ5IGFzIG1hbnkgb3ZlcmxheSB0cmVlcyBhcyBzdWItc3RyZWFtcy4iLiBJcyBpdCBj bGVhcmVyIG5vdz8NCg0KDQpQbGVhc2UsIGxldCBtZSBrbm93Lg0KDQpSZWdhcmRzDQpGcmFuY2Vz Y2ENCg0KRnJvbTogZHVhbiBzaGlodWkgPGR1YW5zaGlodWkxMjAxQGdtYWlsLmNvbTxtYWlsdG86 ZHVhbnNoaWh1aTEyMDFAZ21haWwuY29tPj4NCkRhdGU6IE1vbmRheSwgRGVjZW1iZXIgMiwgMjAx MyA1OjI2IFBNDQpUbzogInBwc3BAaWV0Zi5vcmc8bWFpbHRvOnBwc3BAaWV0Zi5vcmc+IiA8cHBz cEBpZXRmLm9yZzxtYWlsdG86cHBzcEBpZXRmLm9yZz4+DQoNClN1YmplY3Q6IFJlOiBbcHBzcF0g V0dMQyBmb3IgdGhlIHN1cnZleSBkcmFmdA0KDQpSYWNoZWwsIFJvbmkgRXZlbiBhbmQgTGluZ2xp IGhhdmUgZ2l2ZW4gc29tZSBnb29kIGNvbW1lbnRzLg0KVGhlcmUgYXJlIHNvbWUgZXJyb3JzIGlu IHRoZSBzdXJ2ZXkgZHJhZnQgd2hpY2ggbXVzdCBiZSBmaXhlZC4NCndoZW4gd2Ugd3JpdHRlbiB0 aGUgc3VydmV5IGRyYWZ0LCB0aGUgUkZDNjk3MiBpcyBzdGlsbCBpbiB0aGUgZHJhZnQgc3RhdHVz LiBOb3cgd2UgY2FuIHJlZmVyIHRvIFJGQzY5NzIgZm9yIHNvbWUgZGVmaW5pdGlvbnMuDQpJIHdp bGwgY29uc2lkZXIgY2FyZWZ1bGx5IHNvbWUgY29tbWVudHMgZnJvbSBMaW5nbGkgYW5kIGdpdmUg dGhlIHJlcGx5IGluIHRoZSBzdWJzZXF1ZW50IG1haWwuDQoNCg0KDQotLQ0KtcvB6cDyL0xpbmds aSBEZW5nDQrW0Ln60sa2r82o0MXR0L6/1LovQ2hpbmEgTW9iaWxlIFJlc2VhcmNoIEluc3RpdHV0 ZQ0KZS1tYWlsOiBkZW5nbGluZ2xpQGNoaW5hbW9iaWxlLmNvbTxtYWlsdG86ZGVuZ2xpbmdsaUBj aGluYW1vYmlsZS5jb20+DQp0ZWw6IDE1ODAxNjk2Njg4LTMzNjcNCm1vYmlsZTogMTM4MTA1OTcx NDgNCg== --_000_CECB6642189FDflopiccociscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <4742A6D5EEDBDC4B9AB9DB51DEC04380@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Lingli,

The best we can do is to try as much security-related information as p= ossible for all the presented algorithms.

I have no idea on how much security-related information is curren= tly available, and I will get back to you very soon. What if it will come o= ut that there is no available information at all?

Thanks and regards

Francesca

From: lingli deng <denglingli@gmail.com>
Date: Thursday, December 5, 2013 3:= 50 AM
To: Francesca Lo Piccolo <flopicco@cisco.com>
Cc: Zongning <zongning@huawei.com>, duan <duanshihui@catr.cn>, yunfei zhang <hishigh@gmail.com>, Gu Yingjie <guyingjie@gmail.com= >, "ppsp@ietf.org" <ppsp@ietf.org>
Subject: Re: [ppsp] WGLC for the su= rvey draft

Hi Francesca,<= /u>

<= /u>

Thank you for t= he quick response.

I think most of= the issues are addressed, except the security mechanisms. (Inline comments= are also included below^^)

The concern = here is that I think security considerations is also important. Would= it be possible to feed relevant content into =A1=B0security considerations=A1=B1 rather than simple removal?

<= /u>

BR<= /span>

Lingli<= /u>

<= /u>

=B7=A2=BC=FE=C8=CB: ppsp [mailto:= ppsp-bounces@iet= f.org] =B4=FA=B1= =ED Francesca Lo Piccolo (flopicco)
=B7=A2=CB= =CD=CA=B1=BC=E4: 2013=C4=EA12<= /span>=D4=C24=C8=D5 19:09
=CA=D5=BC=FE=C8=CB: Zongning; duan; 'yunfei zhang'; Gu Yingjie; lingli deng
=B3=AD=CB=CD: ppsp@ietf.org
=D6=F7=CC=E2: Re: [ppsp] WGLC for the survey draft

Duan and all,

I absolutely agree with you on the good qu= ality of received feedback and on the necessity to fix some parts in the su= rvey draft.

To this end, I'm attaching a new revision = of the survey (and also of the pictures), where most of the comments from&n= bsp;Rachel, Roni and Lingli have been already taken into account.

Here is a summary of all the received comm= ents, with the ones still open highlighted in red. Lingli, you are among th= e "to" receivers, because there is some your comment I would like to further discuss with you.

Rachel

---------

+ The description in the l= ast paragraph of Section 1 is inconsistent with the organization of chapter= s . This should be fixed. --> Ning, is it possible to turn section 3.1 (and subsections) into section 4 and 3.2= (and subsections) in section 5 and 3.3 (and subsections) in= section 6?

+ In section 2, some terminologies hav= e already defined in RFC6972. It=A1=AFs unnecessary to repeat the definitio= n, e.g., chunk, live streaming=A1=AD --> done

+ Section 1 typo: =A1=B0we always try = to identity tracker and peer protocols=A1=B1 should be =A1=B0we always try = to identify tracker and peer protocols=A1=B1 --> done

+ Section 3.1, typo =A1=B0this may tur= n at end users into playback quality degradation=A1=B1 should be =A1=B0this= may turn end users into playback quality degradation=A1=B1 --> done

+ It=A1=AFs better to adjust the = order of types of P2P streaming applications to be consistent with the orde= r of subsections, which means =A1=B0mesh-based=A1=B1 should be first, then =A1=B0tree-based=A1=B1. --> done<= /p>

Roni

------

+ Figure 1 =A1=B0traker=A1=B1 should b= e =A1=B0tracker=A1=B1 --> done

+ In section 3.1.2 on PPLive change = =A1=B0being the nature of PPLive protocols and algorithm proprietary=A1=B1 = to =A1=B0 Since the protocols and algorithm of PPLIVE are proprietary=A1=B1= --> done

+ In section 3.1.3 =A1=B0 Authenticati= on server is the first point of contact for a peer the joins the system=A1= =B1 to =A1=B0Authentication server is the first point of contact for a peer that joins the system=A1=B1 --> done

+ In section 3.1.3 =A1=B0 can contact = new more peers besides the ones indicated by the rendezvous server=A1=B1 to= =A1=B0can contact new peers besides the ones indicated by the rendezvous server=A1=B1 --> done

+ In section 3.1.5 =A1=B0Since childre= n could lie regarding the number of chunks forwarded to others, Tribler pee= rs do directly not ask their children, but their grandchildren.=A1=B1 To =A1=B0Since children could lie regarding the numbe= r of chunks forwarded to others, Tribler peers do not ask their children di= rectly, but their grandchildren.=A1=B1 --> done

+ In section 3.1.6 when first using CD= N expand to Content Delivery Network (CDN) --> done

Lingli

-------

+ it states as a "sta= ndard track" document, is that accurate? --> Ning, we already discu= ssed about this. As per your comment, this document should be =A1=B0informational=A1=B1, rather than =A1=B0standard track=A1=B1. I as= sume this is something you can take into account as soon as you will submit= the final revision, right?

+ in terminoloy section, "push&qu= ot; is defined as "Transmission of multimedia content without any requ= est from receiving peers.", which I think could be better described as "Transmission of multimedia content that is not initiate= d by receiving peers." --> done

+ In section 3, "the topology tha= t can be associated with overlay connections among peers" could b= e rephrased into "the topology of overlay connections among peers". --> done

+ Also in section 3, "pull-based = data delivery calls for large size buffers where to store chunks" coul= d be rephrased into "pull-based data delivery calls for large size buffers to store chunks". --> done

+ "buffer-maps" = are used to refer to "chunk availability information" (as used by= RFC 6972). For sake of consistency, I think it is better to use the latter instead. --> I re-phrased "in some applications peers e= xchange chunk availability information in form of buffer-maps (a sort of bi= t maps with a bit "1" in correspondence of chunks stored in the l= ocal buffer)". Lingli, have I got your point?<= u>

[dll] Yes. I am O= K with this.

+ In Section 3.2.1 =A1=B0channel serve= r, that provides the list of available channels (live TV or VoD content) to= a PPLive, as soon as the peer joins the system;=A1=B1 should be =A1=B0channel server, that provides the list of available channe= ls (live TV or VoD content) to a PPLive peer, as soon as the peer joins the= system;=A1=B1 --> done

+ It seems to me that the content serv= er may have played some sort of tracker=A1=AFs role in Octoshape, otherwise= , how would a joining peer gets to know the initial address book of other peers? --> done

+ In Section 3.2.3, =A1=B0a mechanism = very similar to the one of TCP congestion window (double increase or linear= increase depending on whether the estimate is below or a given threshold)=A1=B1, should be like =A1=B0a mechanism very s= imilar to the one of TCP congestion window (double increase or linear incre= ase depending on whether the estimate is below or above a given threshold)= =A1=B1 --> done

+ One may be curious about= what is the difference between a =A1=B0repeater node=A1=B1 and a =A1=B0sim= ple peer=A1=B1, as the description of a =A1=B0repeater node=A1=B1 goes like =A1=B0Repeater nodes, that serve as bandwidth multiplier, are able to forw= ard any sub-stream and implement the same peer protocol as simple peers.=A1= =B1 --> I re-phrased "simple peers, whose behavior has alread= y been presented, and repeater nodes, that implement the same peer protocol as simple peers and in addition are high-bandwidth peer= s and are able to forward any sub-stream. In such a way repeater nodes serv= e as bandwidth multiplier". Lingli, have I got your point?

[dll] Yes. It wor= ks for me.

+ In Section 3.2.4, =A1=B0a PPStream p= eer selects peers to download sub-chunks from according to a rate-based alg= orithm=A1=B1 should be change into =A1=B0a PPStream peer selects peers to download sub-chunks according to a rate-based algorithm= =A1=B1 --> done

+ In Section 3.1.5, =A1=B0As already s= aid, Tribler supports video streaming in two different forms: video on dema= nd and live streaming.=A1=B1 Is better to be changed into =A1=B0Tribler supports video streaming in two different forms: video = on demand and live streaming.=A1=B1, since there is no prior statement in t= he draft. --> done

+ Also in Section 3.1.5, = =A1=B0Such a mechanism allows Tribler peers to use the public key included = in torrent file and verity the integrity of each chunk.=A1=B1 should be changed into =A1=B0Such a mechanism allows Tribler = peers to use the public key included in torrent file and verify the integri= ty of each chunk.=A1=B1 --> Lingli, I think your comment after the subse= quent one is correct. So I completely removed this part. See my observation later on. Do you agree?

[dll] Plz see my = comment below.

+ There is considerable re= ference and comparison to the Bitorrent system/model in the Tribler=A1=AFs = subsection, one may wonder why not pose a separate section for introduction of Bittorrent instead? Lingli, I don't think this= is the case, because Bit Torrent is a P2P file sharing system and I have t= he impression that a section devoted to a P2P file sharing system could app= ear somehow out of scope. In addition, every time Bit Torrent is cited, we always tried to provide the necessary = background info. Does it make sense?

[dll] You are rig= ht, since Bittorent is not a streaming system, it seems out of scope. It is= a bad idea, forget it.

+ It is noticeable that bo= th the Tribler=A1=AFs peer selection algorithm and security mechanisms are = elaborated in such a detailed way? What about other systems in terms of similar design issues? Since Section 3 is focus mainly= on the peer topology, maybe separate sections on algorithm/security are mo= re natural for better compression. --> Lingli, the main problem here is = that such a level of detail is often not available for all the applications. Regarding this point I also added = the following statement in "Introduction" section "In addition, the provided descriptions may sometimes appear inhomogeneous from the detail level point of view, but this always = depends on the amount of available information at writing time.". So the only solution seems to me to remove the reference to the security mechanisms. The peer s= election algorithm is full part of the peer protocol in my opinion and it h= as to be kept. But i would like to hear from you.

[dll] I see your = point. However, I would not agree that security is not as important as peer= selection algorithm. Would it be possible to feed it into =A1=B0security considerations=A1=B1?<= /p>

+ In Section 3.1.6, what d= oes it mean by =A1=B0not RTP/RTCP=A1=B1 in =A1=B0the client use UDP to tran= sfer the encrypted media streaming and not RTP/ RTCP.=A1=B1? --> Duan, if I remember correctly, you provided this part. Can you please expl= ain?

+ In Section 3.3.1, =A1=B0Parent re-se= lection is also applied in case of leaving of the previous parent.=A1=B1 Is= better to be changed into =A1=B0Parent re-selection is also triggered for a peer when its previous parent leaves.=A1=B1 --> done=

+ From the description in = Section 3.3.1, it is not clear to me why the QQLive=A1=AFs topology is a hy= brid of mesh and tree. --> Lingli, this comment is not completely clear for me. Probably you meant New Coolstreaming. If s= o, New Coolstreaming may be regarded as hybrid, because on the one sid= e you have an overlay mesh, on the other side you have as many trees as sub= streams. I also added the following statement "Hence, the overall overlay topology is mesh-based, but it is also po= ssible to identify as many overlay trees as sub-streams.". Is it clear= er now?

[dll] Sorry for the typo, I did mean New Coolstreaming. I am fine with the clarification.

2013/12/4 Francesca Lo Piccolo (flopicco) <flopicco@cisco.= com>

Duan and all,&= nbsp;

I absolutely a= gree with you on the good quality of received feedback and on the necessity= to fix some parts in the survey draft.

To this end, I= 'm attaching a new revision of the survey (and also of the pictures), where= most of the comments from Rachel, Roni and Lingli have been already t= aken into account.

Here is a summ= ary of all the received comments, with the ones still open highlighted in r= ed. Lingli, you are among the "to" receivers, because there is so= me your comment I would like to further discuss with you.

Rachel

---------

+ The description in the last paragraph of Section 1 is incon= sistent with the organization of chapters . This should be fixed. --> Ni= ng, is it possible to turn section 3.1 (and subsections) into section 4 and 3.2 (and subsections) in section= 5 and 3.3 (and subsections) in section 6?

+ In secti= on 2, some terminologies have already defined in RFC6972. It=A1=AFs unneces= sary to repeat the definition, e.g., chunk, live streaming=A1=AD --> don= e

+ Section = 1 typo: =A1=B0we always try to identity tracker and peer protocols=A1=B1 sh= ould be =A1=B0we always try to identify tracker and peer protocols=A1=B1 --= > done

+ Section = 3.1, typo =A1=B0this may turn at end users into playback quality degradatio= n=A1=B1 should be =A1=B0this may turn end users into playback quality degra= dation=A1=B1 --> done

+ It= =A1=AFs better to adjust the order of types of P2P streaming applications t= o be consistent with the order of subsections, which means =A1=B0mesh-based= =A1=B1 should be first, then =A1=B0tree-based=A1=B1. --> done

Roni

------

+ Figure 1 =A1=B0traker=A1=B1 sh= ould be =A1=B0tracker=A1=B1 --> done

+ In section 3.1.2 on PPLive cha= nge =A1=B0being the nature of PPLive protocols and algorithm proprietary=A1= =B1 to =A1=B0 Since the protocols and algorithm of PPLIVE are proprietary= =A1=B1 --> done

+ In section 3.1.3 =A1=B0 Authen= tication server is the first point of contact for a peer the joins the syst= em=A1=B1 to =A1=B0Authentication server is the first point of contact for a= peer that joins the system=A1=B1 --> done

+ In section 3.1.3 =A1=B0 can co= ntact new more peers besides the ones indicated by the rendezvous server=A1= =B1 to =A1=B0can contact new peers besides the ones indicated by the rendez= vous server=A1=B1 --> done

+ In section 3.1.5 =A1=B0Since c= hildren could lie regarding the number of chunks forwarded to others, Tribl= er peers do directly not ask their children, but their grandchildren.=A1=B1= To =A1=B0Since children could lie regarding the number of chunks forwarded to others, Tribler peers do not ask their children dir= ectly, but their grandchildren.=A1=B1 --> done

+ In section 3.= 1.6 when first using CDN expand to Content Delivery Network (CDN) --&g= t; done

Lingli

-------

+ it states as a "standard track" document, is that= accurate? --> Ning, we already discussed about this. As per your commen= t, this document should be =A1=B0informational=A1=B1, rather than =A1=B0standard track=A1=B1. I assume this is something you can take into a= ccount as soon as you will submit the final revision, right?

+ in termi= noloy section, "push" is defined as "Transmission of multime= dia content without any request from receiving peers.", which I think = could be better described as "Transmission of multimedia content that is not initiated by receiving peers." --> done

+ In secti= on 3, "the topology that can be associated with overlay connectio= ns among peers" could be rephrased into "the topology of overlay = connections among peers". --> done

+ Also in = section 3, "pull-based data delivery calls for large size buffers wher= e to store chunks" could be rephrased into "pull-based data deliv= ery calls for large size buffers to store chunks". --> done

+ "buffer-maps" are used to refer to "chunk av= ailability information" (as used by RFC 6972). For sake of consistency= , I think it is better to use the latter instead. --> I re-phrased "in some applications peers exchange chunk availability information i= n form of buffer-maps (a sort of bit maps with a bit "1" in corre= spondence of chunks stored in the local buffer)". Lingli, have I got y= our point?

+ In Secti= on 3.2.1 =A1=B0channel server, that provides the list of available channels= (live TV or VoD content) to a PPLive, as soon as the peer joins the system= ;=A1=B1 should be =A1=B0channel server, that provides the list of available channels (live TV or VoD content) to a PPLive peer, = as soon as the peer joins the system;=A1=B1 --> done

+ It seems= to me that the content server may have played some sort of tracker=A1=AFs = role in Octoshape, otherwise, how would a joining peer gets to know the ini= tial address book of other peers? --> done

+ In Secti= on 3.2.3, =A1=B0a mechanism very similar to the one of TCP congestion windo= w (double increase or linear increase depending on whether the estimate is = below or a given threshold)=A1=B1, should be like =A1=B0a mechanism very similar to the one of TCP congestion window (double= increase or linear increase depending on whether the estimate is below or = above a given threshold)=A1=B1 --> done

+ One may be curious about what is the difference between a = =A1=B0repeater node=A1=B1 and a =A1=B0simple peer=A1=B1, as the description= of a =A1=B0repeater node=A1=B1 goes like =A1=B0Repeater nodes, that serve = as bandwidth multiplier, are able to forward any sub-stream and implement the= same peer protocol as simple peers.=A1=B1 --> I re-phrased "= simple peers, whose behavior has already been presented, and repeater nodes= , that implement the same peer protocol as simple peers and in addition are high-bandwidth peers and are able to forward any= sub-stream. In such a way repeater nodes serve as bandwidth multiplier&quo= t;. Lingli, have I got your point?

+ In Secti= on 3.2.4, =A1=B0a PPStream peer selects peers to download sub-chunks from a= ccording to a rate-based algorithm=A1=B1 should be change into =A1=B0a PPSt= ream peer selects peers to download sub-chunks according to a rate-based algorithm=A1=B1 --> done

+ In Secti= on 3.1.5, =A1=B0As already said, Tribler supports video streaming in two di= fferent forms: video on demand and live streaming.=A1=B1 Is better to be ch= anged into =A1=B0Tribler supports video streaming in two different forms: video on demand and live streaming.=A1=B1, since ther= e is no prior statement in the draft. --> done

+ Also in Section 3.1.5, =A1=B0Such a mechanism allows Trible= r peers to use the public key included in torrent file and verity the integ= rity of each chunk.=A1=B1 should be changed into =A1=B0Such a mechanism allows Tribler peers to use the public key included in torrent= file and verify the integrity of each chunk.=A1=B1 --> Lingli, I think = your comment after the subsequent one is correct. So I completely removed t= his part. See my observation later on. Do you agree?

+ There is considerable reference and comparison to the Bitor= rent system/model in the Tribler=A1=AFs subsection, one may wonder why not = pose a separate section for introduction of Bittorrent instead? Lingli, I don't think this is the case, because Bit Torrent is a = P2P file sharing system and I have the impression that a section devoted to= a P2P file sharing system could appear somehow out of scope. In addition, = every time Bit Torrent is cited, we always tried to provide the necessary background info. Does it make sen= se?

+ It is noticeable that both the Tribler=A1=AFs peer selectio= n algorithm and security mechanisms are elaborated in such a detailed way? = What about other systems in terms of similar design issues? Since Section 3 is focus mainly on the peer topology, maybe= separate sections on algorithm/security are more natural for better compre= ssion. --> Lingli, the main problem here is that such a level of detail = is often not available for all the applications. Regarding this point I also added the following statement in= "Introduction" section "In addition, the provided descriptions may sometime= s appear inhomogeneous from the detail level point of view, but this always depends on the amount of available information at= writing time.". So the only solution see= ms to me to remove the reference to the security mechanisms. The peer selection algorithm is full part of the peer protocol= in my opinion and it has to be kept. But i would like to hear from you.

+ In Section 3.1.6, what does it mean by =A1=B0not RTP/RTCP= =A1=B1 in =A1=B0the client use UDP to transfer the encrypted media streamin= g and not RTP/ RTCP.=A1=B1? --> Duan, if I remember correctly, you provided this part. Can you please explain?

+ In Secti= on 3.3.1, =A1=B0Parent re-selection is also applied in case of leaving of t= he previous parent.=A1=B1 Is better to be changed into =A1=B0Parent re-sele= ction is also triggered for a peer when its previous parent leaves.=A1=B1 --> done

+ From the description in Section 3.3.1, it is not clear to m= e why the QQLive=A1=AFs topology is a hybrid of mesh and tree. -->= Lingli, this comment is not completely clear for me. Probably you meant New Coolstreaming. If so, New Coolstreaming may be= regarded as hybrid, because on the one side you have an overlay mesh, on t= he other side you have as many trees as substreams. I also added the follow= ing statement "Hence, the overall overlay topology is mesh-based, but it is also possible to identify as many overla= y trees as sub-streams.". Is it clearer now?

Please, let me= know.

Regards

Francesca

From: duan shihui <duanshihui1201@gmail.com>
Date: Monday, December 2, 2013 5:26= PM
To: "ppsp@ietf.org" <ppsp@ietf.org>

Subject: Re: [ppsp] WGLC for the su= rvey draft

Rachel, Roni Even and Lingli have given some go= od comments.

There are some errors in the survey draft which must be= fixed.

when we written the survey draft, the RFC6972 is still = in the draft status. Now we can refer to RFC6972 for some definitions.

I will consider carefully some comments from Lingli and= give the reply in the subsequent mail.

--
=B5=CB=C1=E9=C0=F2/Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute
e-mail: denglingli@chinamobil= e.com
tel: 15801696688-3367
mobile: 13810597148

--_000_CECB6642189FDflopiccociscocom_-- From xiajinwei@huawei.com Tue Dec 10 22:46:22 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9A11AE36A for ; Tue, 10 Dec 2013 22:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzdNrJn__qaB for ; Tue, 10 Dec 2013 22:46:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCED1AD8E3 for ; Tue, 10 Dec 2013 22:46:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBG19490; Wed, 11 Dec 2013 06:46:13 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 06:45:57 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Dec 2013 06:46:06 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Wed, 11 Dec 2013 14:45:59 +0800 From: Xiajinwei To: "ppsp@ietf.org" Thread-Topic: Next Step Work on Base Tracker Draft Thread-Index: Ac72PKVWG2hfFKToS2ub/PSPu3bo5w== Date: Wed, 11 Dec 2013 06:45:58 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AP6t Apfi AvGH BK7W BcLo CH3Y C7wm EFEG ENTG ElZT FFKF FU1W FhXa GJkL G2M+ G4zB; 1; cABwAHMAcABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {50E86480-F6CD-4A7E-AB83-F61A24045F6F}; eABpAGEAagBpAG4AdwBlAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Wed, 11 Dec 2013 06:45:57 GMT; TgBlAHgAdAAgAFMAdABlAHAAIABXAG8AcgBrACAAbwBuACAAQgBhAHMAZQAgAFQAcgBhAGMAawBlAHIAIABEAHIAYQBmAHQA x-cr-puzzleid: {50E86480-F6CD-4A7E-AB83-F61A24045F6F} x-originating-ip: [10.138.41.146] Content-Type: multipart/alternative; boundary="_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6892nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] Next Step Work on Base Tracker Draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 11 Dec 2013 06:46:22 -0000 --_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6892nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, According to the last IETF meeting minutes, I have a few concerns about the= Base Tracker draft. 1, Is HTTP confirmed to be used to convey PPSP-TP message? Or take raw TCP = into account, or otherwise? 2, We plan to use a general syntax (like C, ASN.1) to define the PPSP-TP me= ssage structures while leaving the underlying encoding type into appendix, = does the PPSP agree this approach? 3, Requesting peer may support XML encoding, binary encoding or both. In su= ch case, how can the requesting peer negotiate the encoding type with an ap= propriate tracker? Our raw thought is to use the MPD to convey the appropri= ate tracker information to the peer during the bootstrap stage. Does the PP= SP agree this approach? IMHO these concerns needs to be confirmed by PPSP before we can push this d= raft forward in a correct direction. Thank you all! --_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6892nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

&n= bsp;

Accordi= ng to the last IETF meeting minutes, I have a few concerns about the Base T= racker draft.

&n= bsp;

1, Is H= TTP confirmed to be used to convey PPSP-TP message? Or take raw TCP into ac= count, or otherwise?

&n= bsp;

2, We p= lan to use a general syntax (like C, ASN.1) to define the PPSP-TP message s= tructures while leaving the underlying encoding type into appendix, does th= e PPSP agree this approach?

&n= bsp;

3, Requ= esting peer may support XML encoding, binary encoding or both. In such case= , how can the requesting peer negotiate the encoding type with an appropria= te tracker? Our raw thought is to use the MPD to convey the appropriate tracker information to the peer during t= he bootstrap stage. Does the PPSP agree this approach?

&n= bsp;

IMHO th= ese concerns needs to be confirmed by PPSP before we can push this draft fo= rward in a correct direction.

&n= bsp;

Thank y= ou all!

--_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6892nkgeml501mbschi_-- From hishigh@gmail.com Thu Dec 12 20:25:53 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C111AE63C for ; Thu, 12 Dec 2013 20:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSfJ4QUB_JlR for ; Thu, 12 Dec 2013 20:25:50 -0800 (PST) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE851A1F1B for ; Thu, 12 Dec 2013 20:25:50 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id i4so1525038oah.22 for ; Thu, 12 Dec 2013 20:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aLm3Sj1lonNHmaQ1ei3cR08NN4hnDSRNKGWEKCOXtks=; b=jQKUrxvP9j1AcEHaJ8dxUforY02lCjFyo0J2GpnM3VtDm9OEvp/lxELYZphM+ahbI/ rd7QS+ahsicMxglGM+LNBEQWaJ2xoVtZMtKkBoOLcM+6qTc1+90uLaTW2idjNsssLhec V0r4Sa63LwqyHHTo4OnYz2s7K+MpbOZ+lpICstBODPmR/hXPAM/eQ5aVz+yr3Ztfd8hY b+UpFnHTGWTZUlad7sG/i0pYhta5mnoO0AIgq4ime1oaUMeh8vSOikUud+fFmHE3ZF4S xFJQ0jUIKnnPJrlJc5gNw/IYdYKS930IzLnD/WLxPsYuAaKhBPSP8jy3KXV+K2DygTUy J6rg== MIME-Version: 1.0 X-Received: by 10.182.149.168 with SMTP id ub8mr288927obb.74.1386908744061; Thu, 12 Dec 2013 20:25:44 -0800 (PST) Received: by 10.76.8.104 with HTTP; Thu, 12 Dec 2013 20:25:43 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Dec 2013 12:25:43 +0800 Message-ID: From: yunfei zhang To: Xiajinwei Content-Type: multipart/alternative; boundary=001a113485000697ad04ed62db16 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Next Step Work on Base Tracker Draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2013 04:25:53 -0000 --001a113485000697ad04ed62db16 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Jinwei and all, Speaking individually: Point1=A3=AC personally I think HTTP model is well suited for request/respo= nse (without too frequent interaction), which is suitalbe for peer and tracker communication. Point2, I do think this is a good approach and has been achieved rough consensus in the mailing list before last IETF. Point3, one more issue is that do we enable peers supporting different encodings to communicate, or just leave them in different swarm. BR Yunfei 2013/12/11 Xiajinwei > Hi all, > > > > According to the last IETF meeting minutes, I have a few concerns about > the Base Tracker draft. > > > > 1, Is HTTP confirmed to be used to convey PPSP-TP message? Or take raw TC= P > into account, or otherwise? > > > > 2, We plan to use a general syntax (like C, ASN.1) to define the PPSP-TP > message structures while leaving the underlying encoding type into > appendix, does the PPSP agree this approach? > > > > 3, Requesting peer may support XML encoding, binary encoding or both. In > such case, how can the requesting peer negotiate the encoding type with a= n > appropriate tracker? Our raw thought is to use the MPD to convey the > appropriate tracker information to the peer during the bootstrap stage. > Does the PPSP agree this approach? > > > > IMHO these concerns needs to be confirmed by PPSP before we can push this > draft forward in a correct direction. > > > > Thank you all! > > > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > --001a113485000697ad04ed62db16 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi Jinwei and all,

= Speaking individually:

Point1=A3=AC personally I think HTTP mode= l is well suited for request/response (without too frequent interaction), w= hich is suitalbe for peer and tracker communication.

Point2, I do think this is a good approach and has been achieved = rough consensus in the mailing list before last IETF.

Point3, one= more issue is that do we enable peers supporting different encodings = to communicate, or just leave them in different swarm.

Yunfei

2013/12/11 Xiajinwei <xiajinwei= @huawei.com>

= Hi all,

=

= According to the last IETF meeting minutes, I have a few concerns about the= Base Tracker draft.

=

= 1, Is HTTP confirmed to be used to convey PPSP-TP message? Or take raw TCP = into account, or otherwise?

=

= 2, We plan to use a general syntax (like C, ASN.1) to define the PPSP-TP me= ssage structures while leaving the underlying encoding type into appendix, = does the PPSP agree this approach?

=

= 3, Requesting peer may support XML encoding, binary encoding or both. In su= ch case, how can the requesting peer negotiate the encoding type with an ap= propriate tracker? Our raw thought is to use the MPD to convey the appropriate tracker information to the peer during t= he bootstrap stage. Does the PPSP agree this approach?=

=

= IMHO these concerns needs to be confirmed by PPSP before we can push this d= raft forward in a correct direction.

=

= Thank you all!

_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

--001a113485000697ad04ed62db16-- From hishigh@gmail.com Thu Dec 12 20:28:47 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7209C1AE63F for ; Thu, 12 Dec 2013 20:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.151 X-Spam-Level: *** X-Spam-Status: No, score=3.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7H-gHwdQvDC for ; Thu, 12 Dec 2013 20:28:37 -0800 (PST) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4397E1A1F1B for ; Thu, 12 Dec 2013 20:28:37 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id o6so1533502oag.18 for ; Thu, 12 Dec 2013 20:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I0dgTI4hqGdJZDcOf5lfbPYsZ4IidhYppYDs7GeJU4Q=; b=KdeJpAZyKYLCl+ch9k3tx0MFPkK53aqBzc+hX0tGPLpKx5gu2M/JtR1nBcuYApKoN9 5OAOHOwIkn+4Z6pRKF7kawWnIk2lmKNs/XSBVspiwnTC2q9LEWWB37phi4XSTYk6/jZq TipmkPH6AAEMGfljEv6sRgciRNs4AXOXJ6bxcuwDp0jk88WFE/ZuXpENbPfeOeOcqgAf OIh/ZTjrfKCg7M2FienCni/gZjFBJBYKl4wMN0tlkzHC7P/lELsIAFqtOcbZMl5kQ/gt Abr0dabMWkVCVdOjR8WCwFgLVohmDuDYCJ4k/CBVlmvgKE9zsWDXrskmuNJcjzICT1sf Yxzg== MIME-Version: 1.0 X-Received: by 10.60.47.228 with SMTP id g4mr345805oen.10.1386908910966; Thu, 12 Dec 2013 20:28:30 -0800 (PST) Received: by 10.76.8.104 with HTTP; Thu, 12 Dec 2013 20:28:30 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Dec 2013 12:28:30 +0800 Message-ID: From: yunfei zhang To: "Francesca Lo Piccolo (flopicco)" Content-Type: multipart/alternative; boundary=001a11c2fcf6f95f8204ed62e42c Cc: Gu Yingjie , "ppsp@ietf.org" , duan Subject: Re: [ppsp] WGLC for the survey draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2013 04:28:47 -0000 --001a11c2fcf6f95f8204ed62e42c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi the authors of the survey draft, Please submit the new version of the draft according to the review comments in the mailing list before we go to the next step for submission. Thanks. BR Yunfei 2013/12/9 Francesca Lo Piccolo (flopicco) > Hi Lingli, > > The best we can do is to try as much security-related information as > possible for all the presented algorithms. > > I have no idea on how much security-related information is currently > available, and I will get back to you very soon. What if it will come out > that there is no available information at all? > > > Thanks and regards > Francesca > > From: lingli deng > Date: Thursday, December 5, 2013 3:50 AM > To: Francesca Lo Piccolo > Cc: Zongning , duan , yunfei > zhang , Gu Yingjie , " > ppsp@ietf.org" > > Subject: Re: [ppsp] WGLC for the survey draft > > Hi Francesca, > > > Thank you for the quick response. > I think most of the issues are addressed, except the security mechanisms. > (Inline comments are also included below^^) > > The concern here is that I think security considerations is also > important. Would it be possible to feed relevant content into =A1=B0secu= rity > considerations=A1=B1 rather than simple removal? > > > > BR > > Lingli > > > > *=B7=A2=BC=FE=C8=CB:* ppsp [mailto:ppsp-bounces@ietf.org] *=B4=FA=B1=ED *= Francesca Lo Piccolo > (flopicco) > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2013=C4=EA12=D4=C24=C8=D5 19:09 > *=CA=D5=BC=FE=C8=CB:* Zongning; duan; 'yunfei zhang'; Gu Yingjie; lingli = deng > *=B3=AD=CB=CD:* ppsp@ietf.org > *=D6=F7=CC=E2:* Re: [ppsp] WGLC for the survey draft > > > > Duan and all, > > > > I absolutely agree with you on the good quality of received feedback and > on the necessity to fix some parts in the survey draft. > > > > To this end, I'm attaching a new revision of the survey (and also of the > pictures), where most of the comments from Rachel, Roni and Lingli have > been already taken into account. > > > > Here is a summary of all the received comments, with the ones still open > highlighted in red. Lingli, you are among the "to" receivers, because the= re > is some your comment I would like to further discuss with you. > > > > Rachel > > --------- > > + The description in the last paragraph of Section 1 is inconsistent with > the organization of chapters . This should be fixed. --> Ning, is it > possible to turn section 3.1 (and subsections) into section 4 and 3.2 (an= d > subsections) in section 5 and 3.3 (and subsections) in section 6? > > + In section 2, some terminologies have already defined in RFC6972. It=A1= =AFs > unnecessary to repeat the definition, e.g., chunk, live streaming=A1=AD -= -> done > > + Section 1 typo: =A1=B0we always try to identity tracker and peer protoc= ols=A1=B1 > should be =A1=B0we always try to identify tracker and peer protocols=A1= =B1 --> done > > + Section 3.1, typo =A1=B0this may turn at end users into playback qualit= y > degradation=A1=B1 should be =A1=B0this may turn end users into playback q= uality > degradation=A1=B1 --> done > > + It=A1=AFs better to adjust the order of types of P2P streaming applicat= ions > to be consistent with the order of subsections, which means =A1=B0mesh-ba= sed=A1=B1 > should be first, then =A1=B0tree-based=A1=B1. --> done > > > > Roni > > ------ > > + Figure 1 =A1=B0traker=A1=B1 should be =A1=B0tracker=A1=B1 --> done > > + In section 3.1.2 on PPLive change =A1=B0being the nature of PPLive prot= ocols > and algorithm proprietary=A1=B1 to =A1=B0 Since the protocols and algorit= hm of PPLIVE > are proprietary=A1=B1 --> done > > + In section 3.1.3 =A1=B0 Authentication server is the first point of con= tact > for a peer the joins the system=A1=B1 to =A1=B0Authentication server is t= he first > point of contact for a peer that joins the system=A1=B1 --> done > > + In section 3.1.3 =A1=B0 can contact new more peers besides the ones ind= icated > by the rendezvous server=A1=B1 to =A1=B0can contact new peers besides the= ones > indicated by the rendezvous server=A1=B1 --> done > > + In section 3.1.5 =A1=B0Since children could lie regarding the number of > chunks forwarded to others, Tribler peers do directly not ask their > children, but their grandchildren.=A1=B1 To =A1=B0Since children could li= e regarding > the number of chunks forwarded to others, Tribler peers do not ask their > children directly, but their grandchildren.=A1=B1 --> done > > + In section 3.1.6 when first using CDN expand to Content Delivery Networ= k > (CDN) --> done > > > > > > Lingli > > ------- > > + it states as a "standard track" document, is that accurate? --> Ning, w= e > already discussed about this. As per your comment, this document should b= e > =A1=B0informational=A1=B1, rather than =A1=B0standard track=A1=B1. I assu= me this is something > you can take into account as soon as you will submit the final revision, > right? > > + in terminoloy section, "push" is defined as "Transmission of multimedia > content without any request from receiving peers.", which I think could b= e > better described as "Transmission of multimedia content that is not > initiated by receiving peers." --> done > > + In section 3, "the topology that can be associated with > overlay connections among peers" could be rephrased into "the topology of > overlay connections among peers". --> done > > + Also in section 3, "pull-based data delivery calls for large size > buffers where to store chunks" could be rephrased into "pull-based data > delivery calls for large size buffers to store chunks". --> done > > + "buffer-maps" are used to refer to "chunk availability information" (as > used by RFC 6972). For sake of consistency, I think it is better to use t= he > latter instead. --> I re-phrased "in some applications peers exchange chu= nk > availability information in form of buffer-maps (a sort of bit maps with = a > bit "1" in correspondence of chunks stored in the local buffer)". Lingli, > have I got your point? > > [dll] Yes. I am OK with this. > > + In Section 3.2.1 =A1=B0channel server, that provides the list of availa= ble > channels (live TV or VoD content) to a PPLive, as soon as the peer joins > the system;=A1=B1 should be =A1=B0channel server, that provides the list = of available > channels (live TV or VoD content) to a PPLive peer, as soon as the peer > joins the system;=A1=B1 --> done > > + It seems to me that the content server may have played some sort of > tracker=A1=AFs role in Octoshape, otherwise, how would a joining peer get= s to > know the initial address book of other peers? --> done > > + In Section 3.2.3, =A1=B0a mechanism very similar to the one of TCP cong= estion > window (double increase or linear increase depending on whether the > estimate is below or a given threshold)=A1=B1, should be like =A1=B0a mec= hanism very > similar to the one of TCP congestion window (double increase or linear > increase depending on whether the estimate is below or above a given > threshold)=A1=B1 --> done > > + One may be curious about what is the difference between a =A1=B0repeate= r > node=A1=B1 and a =A1=B0simple peer=A1=B1, as the description of a =A1=B0r= epeater node=A1=B1 goes > like =A1=B0Repeater nodes, that serve as bandwidth multiplier, are able t= o > forward any sub-stream and implement the same peer protocol as simple > peers.=A1=B1 --> I re-phrased "simple peers, whose behavior has already = been > presented, and repeater nodes, that implement the same peer protocol as > simple peers and in addition are high-bandwidth peers and are able to > forward any sub-stream. In such a way repeater nodes serve as bandwidth > multiplier". Lingli, have I got your point? > > [dll] Yes. It works for me. > > + In Section 3.2.4, =A1=B0a PPStream peer selects peers to download sub-c= hunks > from according to a rate-based algorithm=A1=B1 should be change into =A1= =B0a PPStream > peer selects peers to download sub-chunks according to a rate-based > algorithm=A1=B1 --> done > > + In Section 3.1.5, =A1=B0As already said, Tribler supports video streami= ng in > two different forms: video on demand and live streaming.=A1=B1 Is better = to be > changed into =A1=B0Tribler supports video streaming in two different form= s: > video on demand and live streaming.=A1=B1, since there is no prior statem= ent in > the draft. --> done > > + Also in Section 3.1.5, =A1=B0Such a mechanism allows Tribler peers to u= se the > public key included in torrent file and verity the integrity of each > chunk.=A1=B1 should be changed into =A1=B0Such a mechanism allows Tribler= peers to > use the public key included in torrent file and verify the integrity of > each chunk.=A1=B1 --> Lingli, I think your comment after the subsequent o= ne is > correct. So I completely removed this part. See my observation later on. = Do > you agree? > > [dll] Plz see my comment below. > > + There is considerable reference and comparison to the Bitorrent > system/model in the Tribler=A1=AFs subsection, one may wonder why not pos= e a > separate section for introduction of Bittorrent instead? Lingli, I don't > think this is the case, because Bit Torrent is a P2P file sharing system > and I have the impression that a section devoted to a P2P file sharing > system could appear somehow out of scope. In addition, every time Bit > Torrent is cited, we always tried to provide the necessary background inf= o. > Does it make sense? > > [dll] You are right, since Bittorent is not a streaming system, it seems > out of scope. It is a bad idea, forget it. > > + It is noticeable that both the Tribler=A1=AFs peer selection algorithm = and > security mechanisms are elaborated in such a detailed way? What about oth= er > systems in terms of similar design issues? Since Section 3 is focus mainl= y > on the peer topology, maybe separate sections on algorithm/security are > more natural for better compression. --> Lingli, the main problem here is > that such a level of detail is often not available for all the > applications. Regarding this point I also added the following statement i= n > "Introduction" section "In addition, the provided descriptions may > sometimes appear inhomogeneous from the detail level point of view, but > this always depends on the amount of available information at writing tim= e.". > So the only solution seems to me to remove the reference to the security > mechanisms. The peer selection algorithm is full part of the peer protoco= l > in my opinion and it has to be kept. But i would like to hear from you. > > [dll] I see your point. However, I would not agree that security is not a= s > important as peer selection algorithm. Would it be possible to feed it in= to > =A1=B0security considerations=A1=B1? > > + In Section 3.1.6, what does it mean by =A1=B0not RTP/RTCP=A1=B1 in =A1= =B0the client use > UDP to transfer the encrypted media streaming and not RTP/ RTCP.=A1=B1? -= -> > Duan, if I remember correctly, you provided this part. Can you please > explain? > > + In Section 3.3.1, =A1=B0Parent re-selection is also applied in case of > leaving of the previous parent.=A1=B1 Is better to be changed into =A1=B0= Parent > re-selection is also triggered for a peer when its previous parent leaves= .=A1=B1 > --> done > > + From the description in Section 3.3.1, it is not clear to me why the > QQLive=A1=AFs topology is a hybrid of mesh and tree. --> Lingli, this co= mment > is not completely clear for me. Probably you meant New Coolstreaming. If > so, New Coolstreaming may be regarded as hybrid, because on the one side > you have an overlay mesh, on the other side you have as many trees as > substreams. I also added the following statement "Hence, the overall > overlay topology is mesh-based, but it is also possible to identify as ma= ny > overlay trees as sub-streams.". Is it clearer now? > > [dll] Sorry for the typo, I did mean New Coolstreaming. I am fine with > the clarification. > > > 2013/12/4 Francesca Lo Piccolo (flopicco) > >> Duan and all, >> >> I absolutely agree with you on the good quality of received feedback >> and on the necessity to fix some parts in the survey draft. >> >> To this end, I'm attaching a new revision of the survey (and also of >> the pictures), where most of the comments from Rachel, Roni and Lingli h= ave >> been already taken into account. >> >> Here is a summary of all the received comments, with the ones still >> open highlighted in red. Lingli, you are among the "to" receivers, becau= se >> there is some your comment I would like to further discuss with you. >> >> Rachel >> --------- >> + The description in the last paragraph of Section 1 is inconsistent >> with the organization of chapters . This should be fixed. --> Ning, is i= t >> possible to turn section 3.1 (and subsections) into section 4 and 3.2 (a= nd >> subsections) in section 5 and 3.3 (and subsections) in section 6? >> + In section 2, some terminologies have already defined in RFC6972. It= =A1=AFs >> unnecessary to repeat the definition, e.g., chunk, live streaming=A1=AD = --> done >> + Section 1 typo: =A1=B0we always try to identity tracker and peer proto= cols=A1=B1 >> should be =A1=B0we always try to identify tracker and peer protocols=A1= =B1 --> done >> + Section 3.1, typo =A1=B0this may turn at end users into playback quali= ty >> degradation=A1=B1 should be =A1=B0this may turn end users into playback = quality >> degradation=A1=B1 --> done >> + It=A1=AFs better to adjust the order of types of P2P streaming applica= tions >> to be consistent with the order of subsections, which means =A1=B0mesh-b= ased=A1=B1 >> should be first, then =A1=B0tree-based=A1=B1. --> done >> >> Roni >> ------ >> + Figure 1 =A1=B0traker=A1=B1 should be =A1=B0tracker=A1=B1 --> done >> + In section 3.1.2 on PPLive change =A1=B0being the nature of PPLive pro= tocols >> and algorithm proprietary=A1=B1 to =A1=B0 Since the protocols and algori= thm of PPLIVE >> are proprietary=A1=B1 --> done >> + In section 3.1.3 =A1=B0 Authentication server is the first point of co= ntact >> for a peer the joins the system=A1=B1 to =A1=B0Authentication server is = the first >> point of contact for a peer that joins the system=A1=B1 --> done >> + In section 3.1.3 =A1=B0 can contact new more peers besides the ones >> indicated by the rendezvous server=A1=B1 to =A1=B0can contact new peers = besides the >> ones indicated by the rendezvous server=A1=B1 --> done >> + In section 3.1.5 =A1=B0Since children could lie regarding the number o= f >> chunks forwarded to others, Tribler peers do directly not ask their >> children, but their grandchildren.=A1=B1 To =A1=B0Since children could l= ie regarding >> the number of chunks forwarded to others, Tribler peers do not ask their >> children directly, but their grandchildren.=A1=B1 --> done >> + In section 3.1.6 when first using CDN expand to Content Delivery >> Network (CDN) --> done >> >> >> Lingli >> ------- >> + it states as a "standard track" document, is that accurate? --> Ning, >> we already discussed about this. As per your comment, this document shou= ld >> be =A1=B0informational=A1=B1, rather than =A1=B0standard track=A1=B1. I = assume this is >> something you can take into account as soon as you will submit the final >> revision, right? >> + in terminoloy section, "push" is defined as "Transmission of multimedi= a >> content without any request from receiving peers.", which I think could = be >> better described as "Transmission of multimedia content that is not >> initiated by receiving peers." --> done >> + In section 3, "the topology that can be associated with >> overlay connections among peers" could be rephrased into "the topology o= f >> overlay connections among peers". --> done >> + Also in section 3, "pull-based data delivery calls for large size >> buffers where to store chunks" could be rephrased into "pull-based data >> delivery calls for large size buffers to store chunks". --> done >> + "buffer-maps" are used to refer to "chunk availability information" (a= s >> used by RFC 6972). For sake of consistency, I think it is better to use = the >> latter instead. --> I re-phrased "in some applications peers exchange ch= unk >> availability information in form of buffer-maps (a sort of bit maps with= a >> bit "1" in correspondence of chunks stored in the local buffer)". Lingli= , >> have I got your point? >> + In Section 3.2.1 =A1=B0channel server, that provides the list of avail= able >> channels (live TV or VoD content) to a PPLive, as soon as the peer joins >> the system;=A1=B1 should be =A1=B0channel server, that provides the list= of available >> channels (live TV or VoD content) to a PPLive peer, as soon as the peer >> joins the system;=A1=B1 --> done >> + It seems to me that the content server may have played some sort of >> tracker=A1=AFs role in Octoshape, otherwise, how would a joining peer ge= ts to >> know the initial address book of other peers? --> done >> + In Section 3.2.3, =A1=B0a mechanism very similar to the one of TCP >> congestion window (double increase or linear increase depending on wheth= er >> the estimate is below or a given threshold)=A1=B1, should be like =A1=B0= a mechanism >> very similar to the one of TCP congestion window (double increase or lin= ear >> increase depending on whether the estimate is below or above a given >> threshold)=A1=B1 --> done >> + One may be curious about what is the difference between a =A1=B0repeat= er >> node=A1=B1 and a =A1=B0simple peer=A1=B1, as the description of a =A1=B0= repeater node=A1=B1 goes >> like =A1=B0Repeater nodes, that serve as bandwidth multiplier, are able = to >> forward any sub-stream and implement the same peer protocol as simple >> peers.=A1=B1 --> I re-phrased "simple peers, whose behavior has already= been >> presented, and repeater nodes, that implement the same peer protocol as >> simple peers and in addition are high-bandwidth peers and are able to >> forward any sub-stream. In such a way repeater nodes serve as bandwidth >> multiplier". Lingli, have I got your point? >> + In Section 3.2.4, =A1=B0a PPStream peer selects peers to download sub-= chunks >> from according to a rate-based algorithm=A1=B1 should be change into =A1= =B0a PPStream >> peer selects peers to download sub-chunks according to a rate-based >> algorithm=A1=B1 --> done >> + In Section 3.1.5, =A1=B0As already said, Tribler supports video stream= ing in >> two different forms: video on demand and live streaming.=A1=B1 Is better= to be >> changed into =A1=B0Tribler supports video streaming in two different for= ms: >> video on demand and live streaming.=A1=B1, since there is no prior state= ment in >> the draft. --> done >> + Also in Section 3.1.5, =A1=B0Such a mechanism allows Tribler peers to = use >> the public key included in torrent file and verity the integrity of each >> chunk.=A1=B1 should be changed into =A1=B0Such a mechanism allows Trible= r peers to >> use the public key included in torrent file and verify the integrity of >> each chunk.=A1=B1 --> Lingli, I think your comment after the subsequent = one is >> correct. So I completely removed this part. See my observation later on.= Do >> you agree? >> + There is considerable reference and comparison to the Bitorrent >> system/model in the Tribler=A1=AFs subsection, one may wonder why not po= se a >> separate section for introduction of Bittorrent instead? Lingli, I don't >> think this is the case, because Bit Torrent is a P2P file sharing system >> and I have the impression that a section devoted to a P2P file sharing >> system could appear somehow out of scope. In addition, every time Bit >> Torrent is cited, we always tried to provide the necessary background in= fo. >> Does it make sense? >> + It is noticeable that both the Tribler=A1=AFs peer selection algorithm= and >> security mechanisms are elaborated in such a detailed way? What about ot= her >> systems in terms of similar design issues? Since Section 3 is focus main= ly >> on the peer topology, maybe separate sections on algorithm/security are >> more natural for better compression. --> Lingli, the main problem here i= s >> that such a level of detail is often not available for all the >> applications. Regarding this point I also added the following statement = in >> "Introduction" section "In addition, the provided descriptions may >> sometimes appear inhomogeneous from the detail level point of view, but >> this always depends on the amount of available information at writing ti= me.". >> So the only solution seems to me to remove the reference to the securit= y >> mechanisms. The peer selection algorithm is full part of the peer protoc= ol >> in my opinion and it has to be kept. But i would like to hear from you. >> + In Section 3.1.6, what does it mean by =A1=B0not RTP/RTCP=A1=B1 in =A1= =B0the client >> use UDP to transfer the encrypted media streaming and not RTP/ RTCP.=A1= =B1? --> >> Duan, if I remember correctly, you provided this part. Can you please >> explain? >> + In Section 3.3.1, =A1=B0Parent re-selection is also applied in case of >> leaving of the previous parent.=A1=B1 Is better to be changed into =A1= =B0Parent >> re-selection is also triggered for a peer when its previous parent leave= s.=A1=B1 >> --> done >> + From the description in Section 3.3.1, it is not clear to me why the >> QQLive=A1=AFs topology is a hybrid of mesh and tree. --> Lingli, this c= omment >> is not completely clear for me. Probably you meant New Coolstreaming. If >> so, New Coolstreaming may be regarded as hybrid, because on the one side >> you have an overlay mesh, on the other side you have as many trees as >> substreams. I also added the following statement "Hence, the overall >> overlay topology is mesh-based, but it is also possible to identify as m= any >> overlay trees as sub-streams.". Is it clearer now? >> >> >> Please, let me know. >> >> Regards >> Francesca >> >> From: duan shihui >> Date: Monday, December 2, 2013 5:26 PM >> To: "ppsp@ietf.org" >> >> Subject: Re: [ppsp] WGLC for the survey draft >> >> Rachel, *Roni Even* and Lingli have given some good comments. >> There are some errors in the survey draft which must be fixed. >> when we written the survey draft, the RFC6972 is still in the draft >> status. Now we can refer to RFC6972 for some definitions. >> I will consider carefully some comments from Lingli and give the reply >> in the subsequent mail. >> > > > > -- > =B5=CB=C1=E9=C0=F2/Lingli Deng > =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Resea= rch Institute > e-mail: denglingli@chinamobile.com > tel: 15801696688-3367 > mobile: 13810597148 > --001a11c2fcf6f95f8204ed62e42c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi the authors of the survey draft,

&= nbsp; Please submit the new version of the draft according to the review co= mments in the mailing list before we go to the next step for submission. Th= anks.

Yunfei

2013/12/9 Francesca Lo Piccolo (flopi= cco) <flopicco@cisco.com>

Hi Lingli,

The best we can do is to try as much security-related information as p= ossible for all the presented algorithms.

I have no idea on how much security-related information is curren= tly available, and I will get back to you very soon. What if it will come o= ut that there is no available information at all?

Thanks and regards

Francesca

From: lingli deng <denglingli@gmail.com> Date: Thursday, December 5, 2013 3:= 50 AM
To: Francesca Lo Piccolo <flopicco@cisco.com>= ;
Cc: Zongning <zongning@huawei.com>, duan &l= t;duanshihui@catr.c= n>, yunfei zhang <hishigh@gmail.com>, Gu Yingjie <guyin= gjie@gmail.com>, "ppsp@ietf.org" <ppsp@ietf.org>

Subject: Re: [ppsp] WGLC for the su= rvey draft

Hi Francesca,=

=

Thank you for the quick r= esponse.

I think most of the issue= s are addressed, except the security mechanisms. (Inline comments are also = included below^^)

The concern here is th= at I think security considerations is also important. Would it be&nbs= p;possible to feed relevant content into “security considerations” rather than simple removal?

=

BR

Lingli=

=

=B7=A2=BC=FE=C8=CB: ppsp [mailto:= ppsp-bounces@iet= f.org] =B4=FA=B1= =ED Francesca Lo Piccolo (flopicco)
=B7=A2=CB= =CD=CA=B1=BC=E4: 2013=C4=EA12<= /span>=D4=C24=C8=D5 19:09
=CA=D5=BC=FE=C8=CB: Zongning; duan; 'yunfei zhang'; Gu Yingjie; lingli deng
=B3=AD=CB=CD: ppsp@ietf.org
=D6=F7=CC=E2: Re: [ppsp] WGLC for the survey draft

Duan and all,

I absolutely agree with you on the good quality = of received feedback and on the necessity to fix some parts in the survey d= raft.

To this end, I'm attaching a new revision of= the survey (and also of the pictures), where most of the comments from&nbs= p;Rachel, Roni and Lingli have been already taken into account.

Here is a summary of all the received comments, = with the ones still open highlighted in red. Lingli, you are among the &quo= t;to" receivers, because there is some your comment I would like to further discuss with you.

Rachel

---------

+ The description in the last paragrap= h of Section 1 is inconsistent with the organization of chapters . This sho= uld be fixed. --> Ning, is it possible to turn section 3.1 (and subsections) into section 4 and 3.2= (and subsections) in section 5 and 3.3 (and subsections) in= section 6?

+ In section 2, some terminologies have already = defined in RFC6972. It’s unnecessary to repeat the definition, e.g., = chunk, live streaming… --> done

+ Section 1 typo: “we always try to identi= ty tracker and peer protocols” should be “we always try to iden= tify tracker and peer protocols” --> done

+ Section 3.1, typo “this may turn at end = users into playback quality degradation” should be “this may tu= rn end users into playback quality degradation” --> done

+ It’s better to adjust the order of = types of P2P streaming applications to be consistent with the order of subs= ections, which means “mesh-based” should be first, then “tree-based”. --> done

Roni

------

+ Figure 1 “traker” should be &ldquo= ;tracker”  --> done

+ In section 3.1.2 on PPLive change “being= the nature of PPLive protocols and algorithm proprietary” to “= Since the protocols and algorithm of PPLIVE are proprietary” &n= bsp;--> done

+ In section 3.1.3 “ Authentication server= is the first point of contact for a peer the joins the system” to &l= dquo;Authentication server is the first point of contact for a peer that joins the system” --> done

+ In section 3.1.3 “ can contact new more = peers besides the ones indicated by the rendezvous server” to “= can contact new peers besides the ones indicated by the rendezvous server” --> done

+ In section 3.1.5 “Since children could l= ie regarding the number of chunks forwarded to others, Tribler peers do dir= ectly not ask their children, but their grandchildren.” To “Since children could lie regarding the num= ber of chunks forwarded to others, Tribler peers do not ask their children = directly, but their grandchildren.” --> done

+ In section 3.1.6 when first using CDN expand t= o Content Delivery Network (CDN) --> done

Lingli

-------

+ it states as a "standard track&= quot; document, is that accurate? --> Ning, we already discussed about t= his. As per your comment, this document should be “informational”, rather than “standard track”. = I assume this is something you can take into account as soon as you will su= bmit the final revision, right?

+ in terminoloy section, "push" is def= ined as "Transmission of multimedia content without any request from r= eceiving peers.", which I think could be better described as "Transmission of multimedia content that is not initiate= d by receiving peers." --> done

+ In section 3, "the topology that can be a= ssociated with overlay connections among peers" could be rephrase= d into "the topology of overlay connections among peers". --> done

+ Also in section 3, "pull-based data deliv= ery calls for large size buffers where to store chunks" could be rephr= ased into "pull-based data delivery calls for large size buffers to store chunks". --> done

+ "buffer-maps" are used to = refer to "chunk availability information" (as used by RFC 6972). = For sake of consistency, I think it is better to use the latter instead. --> I re-phrased "in some applications peers e= xchange chunk availability information in form of buffer-maps (a sort of bi= t maps with a bit "1" in correspondence of chunks stored in the l= ocal buffer)". Lingli, have I got your point?=

[dll] Yes. I am OK with thi= s.

+ In Section 3.2.1 “channel server, that p= rovides the list of available channels (live TV or VoD content) to a PPLive= , as soon as the peer joins the system;” should be “channel server, that provides the list of available chann= els (live TV or VoD content) to a PPLive peer, as soon as the peer joins th= e system;” --> done

+ It seems to me that the content server may hav= e played some sort of tracker’s role in Octoshape, otherwise, how wou= ld a joining peer gets to know the initial address book of other peers? --> done

+ In Section 3.2.3, “a mechanism very simi= lar to the one of TCP congestion window (double increase or linear increase= depending on whether the estimate is below or a given threshold)”, should be like “a mechanism very= similar to the one of TCP congestion window (double increase or linear inc= rease depending on whether the estimate is below or above a given threshold= )” --> done

+ One may be curious about what is the= difference between a “repeater node” and a “simple peer&= rdquo;, as the description of a “repeater node” goes like “Repeater nodes, that serve as bandwidth multiplier, are able to for= ward any sub-stream and implement the same peer protocol as simple peers.&r= dquo; --> I re-phrased "simple peers, whose behavior has alre= ady been presented, and repeater nodes, that implement the same peer protocol as simple peers and in addition are high-bandwidth peer= s and are able to forward any sub-stream. In such a way repeater nodes serv= e as bandwidth multiplier". Lingli, have I got your point?

[dll] Yes. It works for me.=

+ In Section 3.2.4, “a PPStream peer selec= ts peers to download sub-chunks from according to a rate-based algorithm&rd= quo; should be change into “a PPStream peer selects peers to download sub-chunks according to a rate-based algorithm&r= dquo; --> done

+ In Section 3.1.5, “As already said, Trib= ler supports video streaming in two different forms: video on demand and li= ve streaming.” Is better to be changed into “Tribler supports video streaming in two different forms: video= on demand and live streaming.”, since there is no prior statement in= the draft. --> done

+ Also in Section 3.1.5, “Such a= mechanism allows Tribler peers to use the public key included in torrent f= ile and verity the integrity of each chunk.” should be changed into “Such a mechanism allows Trible= r peers to use the public key included in torrent file and verify the integ= rity of each chunk.” --> Lingli, I think your comment after the su= bsequent one is correct. So I completely removed this part. See my observation later on. Do you agree?<= /span>

[dll] Plz see my comment be= low.

+ There is considerable reference and = comparison to the Bitorrent system/model in the Tribler’s subsection,= one may wonder why not pose a separate section for introduction of Bittorrent instead? Lingli, I don't think = this is the case, because Bit Torrent is a P2P file sharing system and I ha= ve the impression that a section devoted to a P2P file sharing system could= appear somehow out of scope. In addition, every time Bit Torrent is cited, we always tried to provide the necessary = background info. Does it make sense? <= /p>

[dll] You are right, since = Bittorent is not a streaming system, it seems out of scope. It is a bad ide= a, forget it.

+ It is noticeable that both the Tribl= er’s peer selection algorithm and security mechanisms are elaborated = in such a detailed way? What about other systems in terms of similar design issues? Since Section 3 is focus mainly= on the peer topology, maybe separate sections on algorithm/security are mo= re natural for better compression. --> Lingli, the main problem here is = that such a level of detail is often not available for all the applications. Regarding this point I also added = the following statement in "Introduction" section "In ad= dition, the provided descriptions may sometimes appear inhomogeneous from the detail level point of view, but this always = depends on the amount of available information at writing time.". So the only solution seems to me to remove the reference to the security mechanisms. The peer s= election algorithm is full part of the peer protocol in my opinion and it h= as to be kept. But i would like to hear from you.<= /span>

[dll] I see your point. How= ever, I would not agree that security is not as important as peer selection= algorithm. Would it be possible to feed it into “security considerations”?

+ In Section 3.1.6, what does it mean = by “not RTP/RTCP” in “the client use UDP to transfer the = encrypted media streaming and not RTP/ RTCP.”? --> Duan, if I remember correctly, you provided this part. Can you please expl= ain?

+ In Section 3.3.1, “Parent re-selection i= s also applied in case of leaving of the previous parent.” Is better = to be changed into “Parent re-selection is also triggered for a peer when its previous parent leaves.” --> done

+ From the description in Section 3.3.= 1, it is not clear to me why the QQLive’s topology is a hybrid of mes= h and tree. --> Lingli, this comment is not completely clear for me. Probably you meant New Coolstreaming. If s= o, New Coolstreaming may be regarded as hybrid, because on the one sid= e you have an overlay mesh, on the other side you have as many trees as sub= streams. I also added the following statement "Hence, the overall overlay topology is mesh-based, but it is also po= ssible to identify as many overlay trees as sub-streams.". Is it clear= er now?

[dll] Sorr= y for the typo, I did mean New Coolstreaming. I am fine with the clarification.

2013/12/4 Francesca Lo Piccolo (flopicco) <flopicco@cisco.= com>

Duan and all,&= nbsp;

I absolutely a= gree with you on the good quality of received feedback and on the necessity= to fix some parts in the survey draft.

To this end, I= 'm attaching a new revision of the survey (and also of the pictures), w= here most of the comments from Rachel, Roni and Lingli have been alrea= dy taken into account.

Here is a summ= ary of all the received comments, with the ones still open highlighted in r= ed. Lingli, you are among the "to" receivers, because there is so= me your comment I would like to further discuss with you.

Rachel

---------

+ The description in the last paragraph of Section 1 is inconsist= ent with the organization of chapters . This should be fixed. --> Ning, = is it possible to turn section 3.1 (and subsections) into section 4 and 3.2 (and subsections) in section= 5 and 3.3 (and subsections) in section 6?

+ In section 2= , some terminologies have already defined in RFC6972. It’s unnecessar= y to repeat the definition, e.g., chunk, live streaming… --> done=

+ Section 1 ty= po: “we always try to identity tracker and peer protocols” shou= ld be “we always try to identify tracker and peer protocols” --= > done

+ Section 3.1,= typo “this may turn at end users into playback quality degradation&r= dquo; should be “this may turn end users into playback quality degrad= ation” --> done

+ It&rsqu= o;s better to adjust the order of types of P2P streaming applications to be= consistent with the order of subsections, which means “mesh-based&rd= quo; should be first, then “tree-based”. --> done

Roni

------

+ Figure 1 “traker” shou= ld be “tracker”  --> done

+ In section 3.1.2 on PPLive change = “being the nature of PPLive protocols and algorithm proprietary&rdquo= ; to “ Since the protocols and algorithm of PPLIVE are proprietary&rd= quo;  --> done

+ In section 3.1.3 “ Authentic= ation server is the first point of contact for a peer the joins the system&= rdquo; to “Authentication server is the first point of contact for a = peer that joins the system” --> done

+ In section 3.1.3 “ can conta= ct new more peers besides the ones indicated by the rendezvous server&rdquo= ; to “can contact new peers besides the ones indicated by the rendezv= ous server” --> done

+ In section 3.1.5 “Since chil= dren could lie regarding the number of chunks forwarded to others, Tribler = peers do directly not ask their children, but their grandchildren.” T= o “Since children could lie regarding the number of chunks forwarded to others, Tribler peers do not ask their children dir= ectly, but their grandchildren.” --> done

+ In section 3.1.6 when= first using CDN expand to Content Delivery Network (CDN) --> done=

Lingli

-------

+ it states as a "standard track" document, is that acc= urate? --> Ning, we already discussed about this. As per your comment,&n= bsp;this document should be “informational”, rather than “standard track”. I assume this is something you can take into= account as soon as you will submit the final revision, right?

+ in terminolo= y section, "push" is defined as "Transmission of multimedia = content without any request from receiving peers.", which I think coul= d be better described as "Transmission of multimedia content that is not initiated by receiving peers." --> done

+ In section 3= , "the topology that can be associated with overlay connections a= mong peers" could be rephrased into "the topology of overlay conn= ections among peers". --> done

+ Also in sect= ion 3, "pull-based data delivery calls for large size buffers where to= store chunks" could be rephrased into "pull-based data delivery = calls for large size buffers to store chunks". --> done

+ "buffer-maps" are used to refer to "chunk availa= bility information" (as used by RFC 6972). For sake of consistency, I = think it is better to use the latter instead. --> I re-phrased "in some applications peers exchange chunk availability information i= n form of buffer-maps (a sort of bit maps with a bit "1" in corre= spondence of chunks stored in the local buffer)". Lingli, have I got y= our point?

+ In Section 3= .2.1 “channel server, that provides the list of available channels (l= ive TV or VoD content) to a PPLive, as soon as the peer joins the system;&r= dquo; should be “channel server, that provides the list of available channels (live TV or VoD content) to a PPLive peer, = as soon as the peer joins the system;” --> done

+ It seems to = me that the content server may have played some sort of tracker’s rol= e in Octoshape, otherwise, how would a joining peer gets to know the initia= l address book of other peers? --> done

+ In Section 3= .2.3, “a mechanism very similar to the one of TCP congestion window (= double increase or linear increase depending on whether the estimate is bel= ow or a given threshold)”, should be like “a mechanism very similar to the one of TCP congestion window (doubl= e increase or linear increase depending on whether the estimate is below or= above a given threshold)” --> done

+ One may be curious about what is the difference between a &ldqu= o;repeater node” and a “simple peer”, as the description = of a “repeater node” goes like “Repeater nodes, that serv= e as bandwidth multiplier, are able to forward any sub-stream and implement the= same peer protocol as simple peers.” --> I re-phrased "= ;simple peers, whose behavior has already been presented, and repeater node= s, that implement the same peer protocol as simple peers and in addition are high-bandwidth peers and are able to forward any= sub-stream. In such a way repeater nodes serve as bandwidth multiplier&quo= t;. Lingli, have I got your point?

+ In Section 3= .2.4, “a PPStream peer selects peers to download sub-chunks from acco= rding to a rate-based algorithm” should be change into “a PPStr= eam peer selects peers to download sub-chunks according to a rate-based algorithm” --> done

+ In Section 3= .1.5, “As already said, Tribler supports video streaming in two diffe= rent forms: video on demand and live streaming.” Is better to be chan= ged into “Tribler supports video streaming in two different forms: video on demand and live streaming.”, since the= re is no prior statement in the draft. --> done

+ Also in Section 3.1.5, “Such a mechanism allows Tribler p= eers to use the public key included in torrent file and verity the integrit= y of each chunk.” should be changed into “Such a mechanism allows Tribler peers to use the public key included in torrent= file and verify the integrity of each chunk.” --> Lingli, I think= your comment after the subsequent one is correct. So I completely removed = this part. See my observation later on. Do you agree?

+ There is considerable reference and comparison to the Bitorrent= system/model in the Tribler’s subsection, one may wonder why not pos= e a separate section for introduction of Bittorrent instead? Lingli, I don't think this is the case, because Bit Torrent i= s a P2P file sharing system and I have the impression that a section devote= d to a P2P file sharing system could appear somehow out of scope. In additi= on, every time Bit Torrent is cited, we always tried to provide the necessary background info. Does it make sen= se?

+ It is noticeable that both the Tribler’s peer selection a= lgorithm and security mechanisms are elaborated in such a detailed way? Wha= t about other systems in terms of similar design issues? Since Section 3 is focus mainly on the peer topology, maybe= separate sections on algorithm/security are more natural for better compre= ssion. --> Lingli, the main problem here is that such a level of detail = is often not available for all the applications. Regarding this point I also added the following statement in= "Introduction" section "In addition, the provided descriptions may sometime= s appear inhomogeneous from the detail level point of view, but this always depends on the amount of available information at= writing time.". So the only solution seems to me t= o remove the reference to the security mechanisms. The peer selection algorithm is full part of the peer protocol= in my opinion and it has to be kept. But i would like to hear from you.

+ In Section 3.1.6, what does it mean by “not RTP/RTCP&rdqu= o; in “the client use UDP to transfer the encrypted media streaming a= nd not RTP/ RTCP.”? --> Duan, if I remember correctly, you provided this part. Can you please explain?

+ In Section 3= .3.1, “Parent re-selection is also applied in case of leaving of the = previous parent.” Is better to be changed into “Parent re-selec= tion is also triggered for a peer when its previous parent leaves.” --> done

+ From the description in Section 3.3.1, it is not clear to me wh= y the QQLive’s topology is a hybrid of mesh and tree. --> Li= ngli, this comment is not completely clear for me. Probably you meant New Coolstreaming. If so, New Coolstreaming may be= regarded as hybrid, because on the one side you have an overlay mesh, on t= he other side you have as many trees as substreams. I also added the follow= ing statement "Hence, the overall overlay topology is mesh-based, but it is also possible to identify as many overla= y trees as sub-streams.". Is it clearer now?

Please, let me= know.

Regards

Francesca

From: duan shihui <duanshihui1201@gmail.com>
Date: Monday, December 2, 2013 5:26= PM
To: "ppsp@ietf.org" <ppsp@ietf.org>

Subject: Re: [ppsp] WGLC for the su= rvey draft

Rachel, Roni Even and Lingli have given some good comment= s.

There are some errors in the survey draft which must be fixed.
when we written the survey draft, the RFC6972 is still in the dra= ft status. Now we can refer to RFC6972 for some definitions.

I will consider carefully some comments from Lingli and give the = reply in the subsequent mail.

--
=B5=CB=C1=E9=C0=F2/Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute
e-mail: den= glingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148

--001a11c2fcf6f95f8204ed62e42c-- From xiajinwei@huawei.com Thu Dec 12 21:40:52 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC73F1AE659 for ; Thu, 12 Dec 2013 21:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbWzrDScClmm for ; Thu, 12 Dec 2013 21:40:51 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 723551AE658 for ; Thu, 12 Dec 2013 21:40:50 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYY11852; Fri, 13 Dec 2013 05:40:43 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 05:40:25 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 05:40:40 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 13:40:33 +0800 From: Xiajinwei To: yunfei zhang Thread-Topic: [ppsp] Next Step Work on Base Tracker Draft Thread-Index: Ac72PKVWG2hfFKToS2ub/PSPu3bo5wBO69mAABM5pHA= Date: Fri, 13 Dec 2013 05:40:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.146] Content-Type: multipart/alternative; boundary="_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6EA0nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ppsp@ietf.org" Subject: [ppsp] =?gb2312?b?tPC4tDogIE5leHQgU3RlcCBXb3JrIG9uIEJhc2UgVHJh?= =?gb2312?b?Y2tlciBEcmFmdA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2013 05:40:52 -0000 --_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6EA0nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 WXVuZmVpLA0KDQpGb3IgdGhlIFBvaW50IDMsIEkgcHJlc3VtZSB5b3UgYXJlIHN1Z2dlc3Rpbmcg dGhlIG5lZ290aWF0aW9uIGlzIG91dCBvZiBzY29wZSBvZiB0cmFja2VyIGRyYWZ0LCBzbyBubyBu ZWVkIHRvIGhpZ2hsaWdodCAobWF5YmUganVzdCBtZW50aW9uKSBpdCBpbiB0cmFja2VyIGRyYWZ0 Lg0KDQpXZSB3aWxsIGRvIGl0IGJhc2VkIG9uIHlvdXIgYWdyZWVtZW50Lg0KDQpUaGFuayB5b3Uh DQoNCkJSDQpKaW53ZWkNCg0Kt6K8/sjLOiB5dW5mZWkgemhhbmcgW21haWx0bzpoaXNoaWdoQGdt YWlsLmNvbV0NCreiy83KsbzkOiAyMDEzxOoxMtTCMTPI1SAxMjoyNg0KytW8/sjLOiBYaWFqaW53 ZWkNCrOty806IHBwc3BAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbcHBzcF0gTmV4dCBTdGVwIFdvcmsg b24gQmFzZSBUcmFja2VyIERyYWZ0DQoNCkhpIEppbndlaSBhbmQgYWxsLA0KICAgICBTcGVha2lu ZyBpbmRpdmlkdWFsbHk6DQpQb2ludDGjrCBwZXJzb25hbGx5IEkgdGhpbmsgSFRUUCBtb2RlbCBp cyB3ZWxsIHN1aXRlZCBmb3IgcmVxdWVzdC9yZXNwb25zZSAod2l0aG91dCB0b28gZnJlcXVlbnQg aW50ZXJhY3Rpb24pLCB3aGljaCBpcyBzdWl0YWxiZSBmb3IgcGVlciBhbmQgdHJhY2tlciBjb21t dW5pY2F0aW9uLg0KUG9pbnQyLCBJIGRvIHRoaW5rIHRoaXMgaXMgYSBnb29kIGFwcHJvYWNoIGFu ZCBoYXMgYmVlbiBhY2hpZXZlZCByb3VnaCBjb25zZW5zdXMgaW4gdGhlIG1haWxpbmcgbGlzdCBi ZWZvcmUgbGFzdCBJRVRGLg0KUG9pbnQzLCBvbmUgbW9yZSBpc3N1ZSBpcyB0aGF0IGRvIHdlIGVu YWJsZSBwZWVycyBzdXBwb3J0aW5nIGRpZmZlcmVudCBlbmNvZGluZ3MgdG8gY29tbXVuaWNhdGUs IG9yIGp1c3QgbGVhdmUgdGhlbSBpbiBkaWZmZXJlbnQgc3dhcm0uDQoNCkJSDQpZdW5mZWkNCg0K MjAxMy8xMi8xMSBYaWFqaW53ZWkgPHhpYWppbndlaUBodWF3ZWkuY29tPG1haWx0bzp4aWFqaW53 ZWlAaHVhd2VpLmNvbT4+DQpIaSBhbGwsDQoNCkFjY29yZGluZyB0byB0aGUgbGFzdCBJRVRGIG1l ZXRpbmcgbWludXRlcywgSSBoYXZlIGEgZmV3IGNvbmNlcm5zIGFib3V0IHRoZSBCYXNlIFRyYWNr ZXIgZHJhZnQuDQoNCjEsIElzIEhUVFAgY29uZmlybWVkIHRvIGJlIHVzZWQgdG8gY29udmV5IFBQ U1AtVFAgbWVzc2FnZT8gT3IgdGFrZSByYXcgVENQIGludG8gYWNjb3VudCwgb3Igb3RoZXJ3aXNl Pw0KDQoyLCBXZSBwbGFuIHRvIHVzZSBhIGdlbmVyYWwgc3ludGF4IChsaWtlIEMsIEFTTi4xKSB0 byBkZWZpbmUgdGhlIFBQU1AtVFAgbWVzc2FnZSBzdHJ1Y3R1cmVzIHdoaWxlIGxlYXZpbmcgdGhl IHVuZGVybHlpbmcgZW5jb2RpbmcgdHlwZSBpbnRvIGFwcGVuZGl4LCBkb2VzIHRoZSBQUFNQIGFn cmVlIHRoaXMgYXBwcm9hY2g/DQoNCjMsIFJlcXVlc3RpbmcgcGVlciBtYXkgc3VwcG9ydCBYTUwg ZW5jb2RpbmcsIGJpbmFyeSBlbmNvZGluZyBvciBib3RoLiBJbiBzdWNoIGNhc2UsIGhvdyBjYW4g dGhlIHJlcXVlc3RpbmcgcGVlciBuZWdvdGlhdGUgdGhlIGVuY29kaW5nIHR5cGUgd2l0aCBhbiBh cHByb3ByaWF0ZSB0cmFja2VyPyBPdXIgcmF3IHRob3VnaHQgaXMgdG8gdXNlIHRoZSBNUEQgdG8g Y29udmV5IHRoZSBhcHByb3ByaWF0ZSB0cmFja2VyIGluZm9ybWF0aW9uIHRvIHRoZSBwZWVyIGR1 cmluZyB0aGUgYm9vdHN0cmFwIHN0YWdlLiBEb2VzIHRoZSBQUFNQIGFncmVlIHRoaXMgYXBwcm9h Y2g/DQoNCklNSE8gdGhlc2UgY29uY2VybnMgbmVlZHMgdG8gYmUgY29uZmlybWVkIGJ5IFBQU1Ag YmVmb3JlIHdlIGNhbiBwdXNoIHRoaXMgZHJhZnQgZm9yd2FyZCBpbiBhIGNvcnJlY3QgZGlyZWN0 aW9uLg0KDQpUaGFuayB5b3UgYWxsIQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnPG1h aWx0bzpwcHNwQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9wcHNwDQoNCg== --_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6EA0nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Yunfei,

For the Point 3, I presume you are suggesting the negotiatio= n is out of scope of tracker draft, so no need to highlight (maybe just men= tion) it in tracker draft.

We will do it based on your agreement.

Thank you!

Jinwei

=B7=A2=BC=FE=C8= =CB: yunfei zhang [mailto:hishigh@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA12=D4=C213=C8=D5 = 12:26
=CA=D5=BC=FE=C8=CB: Xiajinwei
=B3=AD=CB=CD: ppsp@ietf.org
=D6=F7=CC=E2: Re: [ppsp] Next Step Work on Base Tracker Draft<= /p>

Hi Jinwei and all,

Speaki= ng individually:

Point1=A3=AC personally I think HTTP model is well suited for request/respon= se (without too frequent interaction), which is suitalbe for peer and track= er communication.

Point2, I do think this is = ;a good approach and has been achieved rough consensus in the mailing list = before last IETF.

Point3, one more issue is that = do we enable peers supporting different encodings to communicate, or j= ust leave them in different swarm.

Yunfei

2013/12/11 Xiajinwei <xiajinwei@huawei.com>

Hi all,

According to the last= IETF meeting minutes, I have a few concerns about the Base Tracker draft.<= /span>

1, Is HTTP confirmed = to be used to convey PPSP-TP message? Or take raw TCP into account, or othe= rwise?

2, We plan to use a g= eneral syntax (like C, ASN.1) to define the PPSP-TP message structures whil= e leaving the underlying encoding type into appendix, does the PPSP agree this approach?

3, Requesting peer ma= y support XML encoding, binary encoding or both. In such case, how can the = requesting peer negotiate the encoding type with an appropriate tracker? Our raw thought is to use the MPD to convey t= he appropriate tracker information to the peer during the bootstrap stage. = Does the PPSP agree this approach?

IMHO these concerns n= eeds to be confirmed by PPSP before we can push this draft forward in a cor= rect direction.

Thank you all!=

=
_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

--_000_A8219E7785257C47B75B6DCE682F8D2F4F7D6EA0nkgeml501mbschi_-- From rachel.huang@huawei.com Thu Dec 12 22:14:22 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A753A1AE687 for ; Thu, 12 Dec 2013 22:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZ-H_egNqZUs for ; Thu, 12 Dec 2013 22:14:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B6BFC1AE0CF for ; Thu, 12 Dec 2013 22:14:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYY13865; Fri, 13 Dec 2013 06:14:11 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 06:13:54 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 06:14:09 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 13 Dec 2013 14:13:58 +0800 From: "Huangyihong (Rachel)" To: yunfei zhang , Xiajinwei Thread-Topic: [ppsp] Next Step Work on Base Tracker Draft Thread-Index: Ac72PKVWG2hfFKToS2ub/PSPu3bo5wBO69mAABPxQ+A= Date: Fri, 13 Dec 2013 06:13:57 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB4591906D@nkgeml501-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.116] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB4591906Dnkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Next Step Work on Base Tracker Draft X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2013 06:14:22 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591906Dnkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWXVuZmVpLA0KDQpCZXN0IHJlZ2FyZHMsDQpSYWNoZWwNCg0KRnJvbTogcHBzcCBbbWFpbHRv OnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHl1bmZlaSB6aGFuZw0KU2VudDog RnJpZGF5LCBEZWNlbWJlciAxMywgMjAxMyAxMjoyNiBQTQ0KVG86IFhpYWppbndlaQ0KQ2M6IHBw c3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcHBzcF0gTmV4dCBTdGVwIFdvcmsgb24gQmFzZSBU cmFja2VyIERyYWZ0DQoNCkhpIEppbndlaSBhbmQgYWxsLA0KICAgICBTcGVha2luZyBpbmRpdmlk dWFsbHk6DQpQb2ludDGjrCBwZXJzb25hbGx5IEkgdGhpbmsgSFRUUCBtb2RlbCBpcyB3ZWxsIHN1 aXRlZCBmb3IgcmVxdWVzdC9yZXNwb25zZSAod2l0aG91dCB0b28gZnJlcXVlbnQgaW50ZXJhY3Rp b24pLCB3aGljaCBpcyBzdWl0YWxiZSBmb3IgcGVlciBhbmQgdHJhY2tlciBjb21tdW5pY2F0aW9u Lg0KUG9pbnQyLCBJIGRvIHRoaW5rIHRoaXMgaXMgYSBnb29kIGFwcHJvYWNoIGFuZCBoYXMgYmVl biBhY2hpZXZlZCByb3VnaCBjb25zZW5zdXMgaW4gdGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgbGFz dCBJRVRGLg0KUG9pbnQzLCBvbmUgbW9yZSBpc3N1ZSBpcyB0aGF0IGRvIHdlIGVuYWJsZSBwZWVy cyBzdXBwb3J0aW5nIGRpZmZlcmVudCBlbmNvZGluZ3MgdG8gY29tbXVuaWNhdGUsIG9yIGp1c3Qg bGVhdmUgdGhlbSBpbiBkaWZmZXJlbnQgc3dhcm0uDQpbUmFjaGVsXTogSSB0aGluayBwZWVycyBz aG91bGQgYmUgYWxsb3dlZCB0byBzdXBwb3J0IGRpZmZlcmVudCBlbmNvZGluZywgc28gdGhhdCB0 aGUgc2FtZSBwZWVyIGNvdWxkIHBhcnRpY2lwYW50IGluIGRpZmZlcmVudCBzd2FybXMgc3VwcG9y dGluZyBkaWZmZXJlbnQgZW5jb2RpbmdzLiBGb3IgdGhlIGNhc2Ugd2hlbiBib3RoIHRyYWNrZXIg YW5kIHBlZXIgc3VwcG9ydCAgYm90aCBlbmNvZGluZ3MsIHdlIGNvdWxkIG1hbmRhdGUgYSBkZWZh dWx0IGVuY29kaW5nIChlLmcuLCB0ZXh0IGJhc2VkKSB0byB1c2UuIFRvIG1lLCB0aGUgYXBwcm9h Y2ggYmVsb3cgcHJvcG9zZWQgYnkgSmlud2VpIGNvdWxkIHNvbHZlIHRoZSB3aG9sZSBwcm9ibGVt cy4NCg0KQlINCll1bmZlaQ0KDQoyMDEzLzEyLzExIFhpYWppbndlaSA8eGlhamlud2VpQGh1YXdl aS5jb208bWFpbHRvOnhpYWppbndlaUBodWF3ZWkuY29tPj4NCkhpIGFsbCwNCg0KQWNjb3JkaW5n IHRvIHRoZSBsYXN0IElFVEYgbWVldGluZyBtaW51dGVzLCBJIGhhdmUgYSBmZXcgY29uY2VybnMg YWJvdXQgdGhlIEJhc2UgVHJhY2tlciBkcmFmdC4NCg0KMSwgSXMgSFRUUCBjb25maXJtZWQgdG8g YmUgdXNlZCB0byBjb252ZXkgUFBTUC1UUCBtZXNzYWdlPyBPciB0YWtlIHJhdyBUQ1AgaW50byBh Y2NvdW50LCBvciBvdGhlcndpc2U/DQoNCjIsIFdlIHBsYW4gdG8gdXNlIGEgZ2VuZXJhbCBzeW50 YXggKGxpa2UgQywgQVNOLjEpIHRvIGRlZmluZSB0aGUgUFBTUC1UUCBtZXNzYWdlIHN0cnVjdHVy ZXMgd2hpbGUgbGVhdmluZyB0aGUgdW5kZXJseWluZyBlbmNvZGluZyB0eXBlIGludG8gYXBwZW5k aXgsIGRvZXMgdGhlIFBQU1AgYWdyZWUgdGhpcyBhcHByb2FjaD8NCg0KMywgUmVxdWVzdGluZyBw ZWVyIG1heSBzdXBwb3J0IFhNTCBlbmNvZGluZywgYmluYXJ5IGVuY29kaW5nIG9yIGJvdGguIElu IHN1Y2ggY2FzZSwgaG93IGNhbiB0aGUgcmVxdWVzdGluZyBwZWVyIG5lZ290aWF0ZSB0aGUgZW5j b2RpbmcgdHlwZSB3aXRoIGFuIGFwcHJvcHJpYXRlIHRyYWNrZXI/IE91ciByYXcgdGhvdWdodCBp cyB0byB1c2UgdGhlIE1QRCB0byBjb252ZXkgdGhlIGFwcHJvcHJpYXRlIHRyYWNrZXIgaW5mb3Jt YXRpb24gdG8gdGhlIHBlZXIgZHVyaW5nIHRoZSBib290c3RyYXAgc3RhZ2UuIERvZXMgdGhlIFBQ U1AgYWdyZWUgdGhpcyBhcHByb2FjaD8NCg0KSU1ITyB0aGVzZSBjb25jZXJucyBuZWVkcyB0byBi ZSBjb25maXJtZWQgYnkgUFBTUCBiZWZvcmUgd2UgY2FuIHB1c2ggdGhpcyBkcmFmdCBmb3J3YXJk IGluIGEgY29ycmVjdCBkaXJlY3Rpb24uDQoNClRoYW5rIHlvdSBhbGwhDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxp c3QNCnBwc3BAaWV0Zi5vcmc8bWFpbHRvOnBwc3BAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3ANCg0K --_000_51E6A56BD6A85142B9D172C87FC3ABBB4591906Dnkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Yunfei,

<= /p>

Best regards,

Rachel

<= /p>

From: ppsp [ma= ilto:ppsp-bounces@ietf.org] On Behalf Of yunfei zhang
Sent: Friday, December 13, 2013 12:26 PM
To: Xiajinwei
Cc: ppsp@ietf.org
Subject: Re: [ppsp] Next Step Work on Base Tracker Draft<= /span>

Hi Jinwei and all,

Speaking individually:=

Point1=A3=AC personally = I think HTTP model is well suited for request/response (without too frequen= t interaction), which is suitalbe for peer and tracker communication.<= /o:p>

Point2, I do think this is a good approach and = has been achieved rough consensus in the mailing list before last IETF.

Point3, one more issue is that do we enable pee= rs supporting different encodings to communicate, or just leave them in dif= ferent swarm.

[Rachel]: I think peers s= hould be allowed to support different encoding, so that the same peer could= participant in different swarms supporting different encodings. For the case when both tracker and peer support both encodings, we c= ould mandate a default encoding (e.g., text based) to use. To me, the appro= ach below proposed by Jinwei could solve the whole problems.

Yunfei

2013/12/11 Xiajinwei <xiajinwei@huawei.com>

Hi all,

According to the last IETF meeting m= inutes, I have a few concerns about the Base Tracker draft.

1, Is HTTP confirmed to be used to c= onvey PPSP-TP message? Or take raw TCP into account, or otherwise?

2, We plan to use a general syntax (= like C, ASN.1) to define the PPSP-TP message structures while leaving the u= nderlying encoding type into appendix, does the PPSP agree this approach?

3, Requesting peer may support XML e= ncoding, binary encoding or both. In such case, how can the requesting peer= negotiate the encoding type with an appropriate tracker? Our raw thought is to use the MPD to convey the appropriate track= er information to the peer during the bootstrap stage. Does the PPSP agree = this approach?

IMHO these concerns needs to be conf= irmed by PPSP before we can push this draft forward in a correct direction.=

Thank you all!

_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

--_000_51E6A56BD6A85142B9D172C87FC3ABBB4591906Dnkgeml501mbschi_-- From hishigh@gmail.com Fri Dec 13 22:28:17 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52971AE4EA for ; Fri, 13 Dec 2013 22:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.951 X-Spam-Level: *** X-Spam-Status: No, score=3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nupDyeQAjNJ for ; Fri, 13 Dec 2013 22:28:16 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id D0D2D1AE4B3 for ; Fri, 13 Dec 2013 22:28:15 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so3033623oag.37 for ; Fri, 13 Dec 2013 22:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hamXVfTDDKwe14YXmrbM7Ht0ormZM8oH8UX1rC+vfHk=; b=ARB03FRTNLqJ8h40cSM+Z0pqPzxOAIpngublvCLkQrKlASdEsa3uLm4o8whbjn+CBt RwEMQF1KwO39Je1CeDkgGUs4LOzlHo1MCz85w6v97SedaX9KkO+5pqgNsIj7UaRD9dTS iXbP/hfsSucVa3KAw93k79QyLvH0UJ946NalPv7hxLEQ4O0Ew7zXm2gWMkgOCxFvhZqs yJ+RZvHsMXnokprsblVMMb4ltYtyKD2VAteV0ty/kVY+K2rzlQHKi+qvvT+OBhTm+/vf 2lTXUS6c3okYhPkeW5tZn8n1po9ZiukUPC20Lzn9R3UU5HlmQY66XW0ygGO3NwAGW8tO Q1Xg== MIME-Version: 1.0 X-Received: by 10.60.17.70 with SMTP id m6mr4389087oed.59.1387002488851; Fri, 13 Dec 2013 22:28:08 -0800 (PST) Received: by 10.76.8.104 with HTTP; Fri, 13 Dec 2013 22:28:08 -0800 (PST) In-Reply-To: References:

Date: Sat, 14 Dec 2013 14:28:08 +0800 Message-ID: From: yunfei zhang To: Xiajinwei Content-Type: multipart/alternative; boundary=089e013cb900a693c904ed78ae68 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] =?gb2312?b?tPC4tDogIE5leHQgU3RlcCBXb3JrIG9uIEJhc2UgVHJh?= =?gb2312?b?Y2tlciBEcmFmdA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 14 Dec 2013 06:28:17 -0000 --089e013cb900a693c904ed78ae68 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi Jinwei, For my point3, it's a QUESTION instead of a suggestion. So maybe we need to analyze the pros and cons for the two options,i.e., negotiation or not first before making the decision. Br Yunfei 2013/12/13 Xiajinwei > Yunfei, > > > > For the Point 3, I presume you are suggesting the negotiation is out of > scope of tracker draft, so no need to highlight (maybe just mention) it i= n > tracker draft. > > > > We will do it based on your agreement. > > > > Thank you! > > > > BR > > Jinwei > > > > *=B7=A2=BC=FE=C8=CB:* yunfei zhang [mailto:hishigh@gmail.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2013=C4=EA12=D4=C213=C8=D5 12:26 > *=CA=D5=BC=FE=C8=CB:* Xiajinwei > *=B3=AD=CB=CD:* ppsp@ietf.org > *=D6=F7=CC=E2:* Re: [ppsp] Next Step Work on Base Tracker Draft > > > > Hi Jinwei and all, > > Speaking individually: > > Point1=A3=AC personally I think HTTP model is well suited for request/res= ponse > (without too frequent interaction), which is suitalbe for peer and tracke= r > communication. > > Point2, I do think this is a good approach and has been achieved rough > consensus in the mailing list before last IETF. > > Point3, one more issue is that do we enable peers supporting different > encodings to communicate, or just leave them in different swarm. > > > > BR > > Yunfei > > > > 2013/12/11 Xiajinwei > > Hi all, > > > > According to the last IETF meeting minutes, I have a few concerns about > the Base Tracker draft. > > > > 1, Is HTTP confirmed to be used to convey PPSP-TP message? Or take raw TC= P > into account, or otherwise? > > > > 2, We plan to use a general syntax (like C, ASN.1) to define the PPSP-TP > message structures while leaving the underlying encoding type into > appendix, does the PPSP agree this approach? > > > > 3, Requesting peer may support XML encoding, binary encoding or both. In > such case, how can the requesting peer negotiate the encoding type with a= n > appropriate tracker? Our raw thought is to use the MPD to convey the > appropriate tracker information to the peer during the bootstrap stage. > Does the PPSP agree this approach? > > > > IMHO these concerns needs to be confirmed by PPSP before we can push this > draft forward in a correct direction. > > > > Thank you all! > > > > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > > --089e013cb900a693c904ed78ae68 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable

Hi Jinwei,

For my po= int3, it's a QUESTION instead of a suggestion. So maybe we need to anal= yze the pros and cons for the two options,i.e., negotiation or not fi= rst before making the decision.

Yunfei

2013/12/13 Xiajinwei <xiajinwei@h= uawei.com>

Yun= fei,

=

For= the Point 3, I presume you are suggesting the negotiation is out of scope = of tracker draft, so no need to highlight (maybe just mention) it in tracker draft.

=

We = will do it based on your agreement.

=

Tha= nk you!

=

BR<= u>

Jin= wei

=

=B7=A2=BC=FE=C8=CB= : yunfei zhang [mailto:hishigh@gmail.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA12=D4=C213=C8=D5 12:26<= br> =CA=D5=BC=FE=C8=CB: Xiajinwei
=B3=AD=CB=CD: ppsp@ietf.org
=D6=F7=CC=E2: Re: [ppsp] Next Step Work on Base Tracker Draft

Hi Jinwei and all,

Speaki= ng individually:

Point1=A3=AC personally I think HTTP model is well suited for request/respon= se (without too frequent interaction), which is suitalbe for peer and track= er communication.

Point2, I do think this is = ;a good approach and has been achieved rough consensus in the mailing list = before last IETF.

Point3, one more issue is that = do we enable peers supporting different encodings to communicate, or j= ust leave them in different swarm.

BR

Yunfei

2013/12/11 Xiajinwei <xiajinwei@huawei.com>

= Hi all,

=

= According to the last IETF meeting minutes, I have a few concerns about the= Base Tracker draft.

=

= 1, Is HTTP confirmed to be used to convey PPSP-TP message? Or take raw TCP = into account, or otherwise?

=

= 2, We plan to use a general syntax (like C, ASN.1) to define the PPSP-TP me= ssage structures while leaving the underlying encoding type into appendix, does the PPSP agree this approach?

=

= 3, Requesting peer may support XML encoding, binary encoding or both. In su= ch case, how can the requesting peer negotiate the encoding type with an appropriate tracker? Our raw thought is to use the MPD to convey t= he appropriate tracker information to the peer during the bootstrap stage. = Does the PPSP agree this approach?

=

= IMHO these concerns needs to be confirmed by PPSP before we can push this d= raft forward in a correct direction.<= /u>

=

= Thank you all!

_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

--089e013cb900a693c904ed78ae68-- From xiajinwei@huawei.com Mon Dec 30 22:01:16 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3741AE3CD for ; Mon, 30 Dec 2013 22:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.439 X-Spam-Level: X-Spam-Status: No, score=-4.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toYP6nsjv9uM for ; Mon, 30 Dec 2013 22:01:14 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6625E1AE393 for ; Mon, 30 Dec 2013 22:01:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZM86903; Tue, 31 Dec 2013 06:01:07 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 06:01:03 +0000 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Dec 2013 06:01:05 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.56]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 31 Dec 2013 14:00:58 +0800 From: Xiajinwei To: "ppsp-chairs@tools.ietf.org" , "ppsp@ietf.org" Thread-Topic: New Version Notification - draft-ietf-ppsp-base-tracker-protocol-03.txt Thread-Index: AQHPBew+lLWm9t5ThECNj43jjMjWOpptzvVA Date: Tue, 31 Dec 2013 06:00:56 +0000 Message-ID: References: <20131231055021.13519.81298.idtracker@ietfa.amsl.com> In-Reply-To: <20131231055021.13519.81298.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] =?utf-8?b?562U5aSNOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gLSBk?= =?utf-8?q?raft-ietf-ppsp-base-tracker-protocol-03=2Etxt?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.15 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, 31 Dec 2013 06:01:16 -0000 SGkgYWxsLA0KDQpBY2NvcmRpbmcgdG8gdGhlIDg4dGggSUVURiBtZWV0aW5nLCBjaGFpcnMgYXNr IHRvIGZvY3VzIG9uIHRoZSBQUFNQLVRQIG1lc3NhZ2UgcmVnYXJkbGVzcyBvZiB0aGUgZW5jb2Rp bmcgdHlwZSwgc28gSSB1cGRhdGVkIHRoZSBkcmFmdCBhbmQgdXNlIEMgbGFuZ3VhZ2Ugc3ludGF4 IHRvIGRlc2NyaWJlIHRoZSBtZXNzYWdlcyBpbiBvcmRlciB0byBtYWtpbmcgdGhlIHdvcmsgcHJv Z3Jlc3NlcyBmYXN0LCBidXQgSSBrbm93IHRoZXJlIG11c3QgYmUgbG90cyBvZiBkcmF3YmFja3Mg aW5zaWRlIHRoaXMgMDMgdmVyc2lvbiBhbmQgaXQgbmVlZHMgbW9yZSBlbGFib3JhdGlvbi4gDQoN CkkgbG9vayBmb3J3YXJkIHRvIHNlZWluZyB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzIGFuZCBpZGVh cywgc28gd2UgY2FuIGJyaW5nIHVwIGEgbW9yZSBtYXR1cmUgdmVyc2lvbiBzb29uLg0KDQpUaGFu ayB5b3UhDQoNCkppbndlaQ0KDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g5Y+R5Lu25Lq6 OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQo+IOWPkemAgeaXtumXtDogMjAxM+W5tDEy5pyIMzHml6UgMTM6NTANCj4g5pS25Lu25Lq6 OiBwcHNwLWNoYWlyc0B0b29scy5pZXRmLm9yZzsNCj4gZHJhZnQtaWV0Zi1wcHNwLWJhc2UtdHJh Y2tlci1wcm90b2NvbEB0b29scy5pZXRmLm9yZzsgbWxzLmlldGZAZ21haWwuY29tDQo+IOS4u+mi mDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1wcHNwLWJhc2UtdHJhY2tl ci1wcm90b2NvbC0wMy50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uICgtMDMpIGhhcyBiZWVu IHN1Ym1pdHRlZCBmb3INCj4gZHJhZnQtaWV0Zi1wcHNwLWJhc2UtdHJhY2tlci1wcm90b2NvbDoN Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1wcHNwLWJh c2UtdHJhY2tlci1wcm90b2NvbC0wMy50eA0KPiB0DQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRy YWNrZXIgcGFnZSBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wcHNwLWJhc2UtdHJhY2tlci1wcm90b2NvbC8N Cj4gDQo+IERpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KPiBodHRwOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXBwc3AtYmFzZS10cmFja2VyLXByb3RvY29sLTAzDQo+ IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJRVRGIFNlY3Jl dGFyaWF0Lg0KDQo=