From xiajinwei@huawei.com Mon Sep 10 00:52:43 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F98921F8498 for ; Mon, 10 Sep 2012 00:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epQoihaLXXii for ; Mon, 10 Sep 2012 00:52:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AC7DE21F848B for ; Mon, 10 Sep 2012 00:52:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKM96140; Mon, 10 Sep 2012 07:52:39 +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.1.323.3; Mon, 10 Sep 2012 08:52:31 +0100 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 15:52:35 +0800 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 15:51:52 +0800 From: Xiajinwei To: "ppsp@ietf.org" Thread-Topic: next step of tracker document Thread-Index: Ac2PKSK8zjA9Okn0RNa4q2/8XXbXvw== Date: Mon, 10 Sep 2012 07:51:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.75] Content-Type: multipart/alternative; boundary="_000_A8219E7785257C47B75B6DCE682F8D2F2BFC8660SZXEML511MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] next step of tracker document X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 07:52:43 -0000 --_000_A8219E7785257C47B75B6DCE682F8D2F2BFC8660SZXEML511MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I notice there are two concerns in tracker document from IETF 84 meeting mi= nutes, in order to accelerate the processing of this document, I'd like to = show my understanding firstly. Hope we can push this work forward and get c= onsensus as soon as possible. 1, Peer ID is global unique to identify the Peer, from this point of view, = the Peer IP address is optional to identify the Peer. IMO it could be usefu= l in a closed swarm scenario, in which the peers (both leech and seed) are = behind the NAT and they can share the media content in the local domain (e.= g., enterprise inside). If I am right, I suggest some text should be given = to describe this scenario. 2, Encoding xml or binary experiences a long discussion, different person h= ave different preference. One compromise is encoding and decoding XML in bi= nary, the related context is specified in W3C Efficient XML Interchange Wor= king Group or in ISO/IEC 23001-Part 1 "Binary MPEG format for XML". Therefo= re, encoding both XML and HTTP in binary format are implementation options.= The draft can have a couple of paragraphs providing those options in terms= of implementation notes. Any comments? Thank you! Jinwei --_000_A8219E7785257C47B75B6DCE682F8D2F2BFC8660SZXEML511MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I notice there are two concerns= in tracker document from IETF 84 meeting minutes, in order to accelerate t= he processing of this document, I’d like to show my understanding fir= stly. Hope we can push this work forward and get consensus as soon as possible.

 

1, Peer ID is global unique to = identify the Peer, from this point of view, the Peer IP address is optional= to identify the Peer. IMO it could be useful in a closed swarm scenario, i= n which the peers (both leech and seed) are behind the NAT and they can share the media content in the local domai= n (e.g., enterprise inside). If I am right, I suggest some text should be g= iven to describe this scenario.

 

2, Encoding xml or binary exper= iences a long discussion, different person have different preference. One c= ompromise is encoding and decoding XML in binary, the related context is sp= ecified in W3C Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 ”Binary MPEG format fo= r XML”. Therefore, encoding both XML and = HTTP in binary format are implementation options. The draft can have a coup= le of paragraphs providing those options in terms of implementation notes.

 

Any comments?=

 

Thank you!

 

 

Jinwei

--_000_A8219E7785257C47B75B6DCE682F8D2F2BFC8660SZXEML511MBSchi_-- From zhangyunfei@chinamobile.com Mon Sep 10 01:16:00 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CE921F8567 for ; Mon, 10 Sep 2012 01:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.623 X-Spam-Level: X-Spam-Status: No, score=-98.623 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLtOmKQmTfvs for ; Mon, 10 Sep 2012 01:15:59 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5A90321F84EF for ; Mon, 10 Sep 2012 01:15:57 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 378BBE50E; Mon, 10 Sep 2012 16:15:57 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 2CD04E520; Mon, 10 Sep 2012 16:15:57 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012091016155463-21745 ; Mon, 10 Sep 2012 16:15:54 +0800 Date: Mon, 10 Sep 2012 16:15:47 +0800 From: zhangyunfei To: 'Xiajinwei' , ppsp References: X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012091016154731655619@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-10 16:15:54, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-10 16:15:56, Serialize complete at 2012-09-10 16:15:56 Content-Type: multipart/alternative; boundary="----=_001_NextPart178628145136_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19174.005 X-TM-AS-Result: No--35.091-7.0-31-10 X-imss-scan-details: No--35.091-7.0-31-10;No--35.091-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] next step of tracker document X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 08:16:00 -0000 This is a multi-part message in MIME format. ------=_001_NextPart178628145136_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgSmlud2VpLA0KICAgIEZvciBwb2ludDEsIHdoZW4geW91IG1lbnRpb24gcGVlciBJUCBhZGRy ZXNzIGlzIG9wdGlvbmFsIHRvIGlkZW50aWZ5IHRoZSBwZWVyLiBEbyB5b3UgbWVhbiBpdCdzICpm ZWFzaWJsZSogb3IgYSAqc3VpdGFibGUgY2FuZGlkYXRlKj8gSWYgaXQgd2VyZSB0aGUgY2FzZSwg SSBhZ3JlZSB3aXRoIHlvdSBhdCB0aGlzIHBvaW50Lg0KICAgRm9yICBwb2ludDIsIHRoZSBjb25z ZW5zdXMgaW4gbGFzdCBJRVRGIG9uIHRoaXMgZHJhZnQgc2hvdWxkIGJlICJjb25jZW50cmF0aW5n IG9uIHRoZSBtZXNzYWdlKiBpZiBJIGRvbid0IHJlbWVtYmVyIHdyb25nLiBSZWdhcmRpbmcgdGhl IGVuY29kaW5nIHBhcnQsIHlvdSBjYW4gYXNrIFdlcyBhbmQgRmFiaW8gZm9yIG1vcmUgY29tbWVu dHMuDQoNClRoYW5rcy4NCkJSDQpZdW5mZWkgDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBY aWFqaW53ZWkNCkRhdGU6IDIwMTItMDktMTAgMTU6NTENClRvOiBwcHNwQGlldGYub3JnDQpTdWJq ZWN0OiBbcHBzcF0gbmV4dCBzdGVwIG9mIHRyYWNrZXIgZG9jdW1lbnQNCkhpIGFsbCwNCiANCkkg bm90aWNlIHRoZXJlIGFyZSB0d28gY29uY2VybnMgaW4gdHJhY2tlciBkb2N1bWVudCBmcm9tIElF VEYgODQgbWVldGluZyBtaW51dGVzLCBpbiBvcmRlciB0byBhY2NlbGVyYXRlIHRoZSBwcm9jZXNz aW5nIG9mIHRoaXMgZG9jdW1lbnQsIEmhr2QgbGlrZSB0byBzaG93IG15IHVuZGVyc3RhbmRpbmcg Zmlyc3RseS4gSG9wZSB3ZSBjYW4gcHVzaCB0aGlzIHdvcmsgZm9yd2FyZCBhbmQgZ2V0IGNvbnNl bnN1cyBhcyBzb29uIGFzIHBvc3NpYmxlLg0KIA0KMSwgUGVlciBJRCBpcyBnbG9iYWwgdW5pcXVl IHRvIGlkZW50aWZ5IHRoZSBQZWVyLCBmcm9tIHRoaXMgcG9pbnQgb2YgdmlldywgdGhlIFBlZXIg SVAgYWRkcmVzcyBpcyBvcHRpb25hbCB0byBpZGVudGlmeSB0aGUgUGVlci4gSU1PIGl0IGNvdWxk IGJlIHVzZWZ1bCBpbiBhIGNsb3NlZCBzd2FybSBzY2VuYXJpbywgaW4gd2hpY2ggdGhlIHBlZXJz IChib3RoIGxlZWNoIGFuZCBzZWVkKSBhcmUgYmVoaW5kIHRoZSBOQVQgYW5kIHRoZXkgY2FuIHNo YXJlIHRoZSBtZWRpYSBjb250ZW50IGluIHRoZSBsb2NhbCBkb21haW4gKGUuZy4sIGVudGVycHJp c2UgaW5zaWRlKS4gSWYgSSBhbSByaWdodCwgSSBzdWdnZXN0IHNvbWUgdGV4dCBzaG91bGQgYmUg Z2l2ZW4gdG8gZGVzY3JpYmUgdGhpcyBzY2VuYXJpby4NCiANCjIsIEVuY29kaW5nIHhtbCBvciBi aW5hcnkgZXhwZXJpZW5jZXMgYSBsb25nIGRpc2N1c3Npb24sIGRpZmZlcmVudCBwZXJzb24gaGF2 ZSBkaWZmZXJlbnQgcHJlZmVyZW5jZS4gT25lIGNvbXByb21pc2UgaXMgZW5jb2RpbmcgYW5kIGRl Y29kaW5nIFhNTCBpbiBiaW5hcnksIHRoZSByZWxhdGVkIGNvbnRleHQgaXMgc3BlY2lmaWVkIGlu IFczQyBFZmZpY2llbnQgWE1MIEludGVyY2hhbmdlIFdvcmtpbmcgR3JvdXAgb3IgaW4gSVNPL0lF QyAyMzAwMS1QYXJ0IDEgobFCaW5hcnkgTVBFRyBmb3JtYXQgZm9yIFhNTKGxLiBUaGVyZWZvcmUs IGVuY29kaW5nIGJvdGggWE1MIGFuZCBIVFRQIGluIGJpbmFyeSBmb3JtYXQgYXJlIGltcGxlbWVu dGF0aW9uIG9wdGlvbnMuIFRoZSBkcmFmdCBjYW4gaGF2ZSBhIGNvdXBsZSBvZiBwYXJhZ3JhcGhz IHByb3ZpZGluZyB0aG9zZSBvcHRpb25zIGluIHRlcm1zIG9mIGltcGxlbWVudGF0aW9uIG5vdGVz Lg0KIA0KQW55IGNvbW1lbnRzPw0KIA0KVGhhbmsgeW91IQ0KIA0KIA0KSmlud2Vp ------=_001_NextPart178628145136_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Jinwei,
    For point1, when you mention peer IP address = is=20 optional to identify the peer. Do you mean it's *feasible* or a *suitable=20 candidate*? If it were the case, I agree with you at this point.
   For  point2, the consensus in last IETF on this dra= ft=20 should be "concentrating on the message* if I don't remember wrong.=20 Regarding the encoding part, you can ask Wes and Fabio for more=20 comments.
 
Thanks.
BR
Yunfei 
zhangyunfei
 
From: Xiajinwei
Date: 2012-09-10 15:51
To: ppsp@ietf.org
Subject: [ppsp] next step of tracker document
=

Hi all,

 

I notice there are two concerns in= tracker=20 document from IETF 84 meeting minutes, in order to accelerate the processi= ng of=20 this document, I=A1=AFd like to show my understanding firstly. Hope we can= push this=20 work forward and get consensus as soon as possible.

 

1, Peer ID is global unique to ide= ntify the=20 Peer, from this point of view, the Peer IP address is optional to identify= the=20 Peer. IMO it could be useful in a closed swarm scenario, in which the peer= s=20 (both leech and seed) are behind the NAT and they can share the media cont= ent in=20 the local domain (e.g., enterprise inside). If I am right, I suggest some = text=20 should be given to describe this scenario.

 

2, Encoding xml or binary experien= ces a long=20 discussion, different person have different preference. One compromise is=20 encoding and decoding XML in binary, the related context is specified in W= 3C=20 Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 = =A1=B1Binary=20 MPEG format for XML=A1=B1. Therefore, encoding b= oth XML and=20 HTTP in binary format are implementation options. The draft can have a cou= ple of=20 paragraphs providing those options in terms of implementation=20 notes.

 

Any comments?

 

Thank you!

 

 

Jinwei

------=_001_NextPart178628145136_=------ From xiajinwei@huawei.com Mon Sep 10 01:37:13 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABA121F8581 for ; Mon, 10 Sep 2012 01:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.074 X-Spam-Level: X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEABYLSFK9WO for ; Mon, 10 Sep 2012 01:37:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ECCEB21F855F for ; Mon, 10 Sep 2012 01:37:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJM93151; Mon, 10 Sep 2012 08:37:08 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 09:35:47 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 10 Sep 2012 09:36:45 +0100 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Mon, 10 Sep 2012 16:36:42 +0800 From: Xiajinwei To: zhangyunfei , ppsp Thread-Topic: [ppsp] next step of tracker document Thread-Index: Ac2PKSK8zjA9Okn0RNa4q2/8XXbXvwAA2BiqAAAGgFA= Date: Mon, 10 Sep 2012 08:36:40 +0000 Message-ID: References: <2012091016154731655619@chinamobile.com> In-Reply-To: <2012091016154731655619@chinamobile.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.75] Content-Type: multipart/alternative; boundary="_000_A8219E7785257C47B75B6DCE682F8D2F2BFC868ESZXEML511MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] =?gb2312?b?tPC4tDogIG5leHQgc3RlcCBvZiB0cmFja2VyIGRvY3Vt?= =?gb2312?b?ZW50?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 08:37:13 -0000 --_000_A8219E7785257C47B75B6DCE682F8D2F2BFC868ESZXEML511MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWXVuZmVpLA0KDQpXb3csIHlvdXIgZmVlZGJhY2sgaXMgdmVyeSBwcm9tcHQhDQoNClllcywg dGhlIFBlZXIgSVAgaW5mb3JtYXRpb24gY2FuIGJlIHVzZWQgaW4gYSBsaW1pdGVkIHNjZW5hcmlv LCBmb3IgZXhhbXBsZSwgYWxsIHRoZSBwZWVycyBhcmUgaW4gYSBlbnRlcnByaXNlIG5ldHdvcmsg YW5kIGFyZSBiZWhpbmQgdGhlIGVudGVycHJpc2UgTkFULCB0aGV5IGNhbiB0cmFuc21pdCB0aGUg ZW50ZXJwcmlzZSBmaWxlcyBhbW9uZyB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrIHZpYSB0aGVpciBs b2NhbCBJUCBhZGRyZXNzZXMuIEJ1dCB0aGUgUGVlciBJRCBpcyBtYW5kYXRvcnkgYW5kIGNhbqGv dCBiZSByZXBsYWNlZCBieSBQZWVyIElQIGluZm9ybWF0aW9uIElNSE8uDQoNCkRvIHlvdSBtZWFu IHRoZSBjb25jbHVzaW9uIGlzIHJlbW92aW5nIGVuY29kaW5nIHR5cGUgcmVsYXRlZCB0ZXh0IGZy b20gdGhpcyBkb2N1bWVudD8gaWYgeWVzLCB3aWxsIHRoZSB0ZXh0IGJlIG1vdmVkIGludG8gYW5v dGhlciBkb2N1bWVudCwgZS5nLiwgdHJhY2tlciBleHRlbnNpb24gZHJhZnQ/DQoNClRoYW5rIHlv dSENCg0KDQpKaW53ZWkNCg0Kt6K8/sjLOiB6aGFuZ3l1bmZlaSBbbWFpbHRvOnpoYW5neXVuZmVp QGNoaW5hbW9iaWxlLmNvbV0NCreiy83KsbzkOiAyMDEyxOo51MIxMMjVIDE2OjE2DQrK1bz+yMs6 IFhpYWppbndlaTsgcHBzcA0K1vfM4jogUmU6IFtwcHNwXSBuZXh0IHN0ZXAgb2YgdHJhY2tlciBk b2N1bWVudA0KDQpIaSBKaW53ZWksDQogICAgRm9yIHBvaW50MSwgd2hlbiB5b3UgbWVudGlvbiBw ZWVyIElQIGFkZHJlc3MgaXMgb3B0aW9uYWwgdG8gaWRlbnRpZnkgdGhlIHBlZXIuIERvIHlvdSBt ZWFuIGl0J3MgKmZlYXNpYmxlKiBvciBhICpzdWl0YWJsZSBjYW5kaWRhdGUqPyBJZiBpdCB3ZXJl IHRoZSBjYXNlLCBJIGFncmVlIHdpdGggeW91IGF0IHRoaXMgcG9pbnQuDQogICBGb3IgIHBvaW50 MiwgdGhlIGNvbnNlbnN1cyBpbiBsYXN0IElFVEYgb24gdGhpcyBkcmFmdCBzaG91bGQgYmUgImNv bmNlbnRyYXRpbmcgb24gdGhlIG1lc3NhZ2UqIGlmIEkgZG9uJ3QgcmVtZW1iZXIgd3JvbmcuIFJl Z2FyZGluZyB0aGUgZW5jb2RpbmcgcGFydCwgeW91IGNhbiBhc2sgV2VzIGFuZCBGYWJpbyBmb3Ig bW9yZSBjb21tZW50cy4NCg0KVGhhbmtzLg0KQlINCll1bmZlaQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnpoYW5neXVuZmVpDQoNCkZyb206IFhpYWppbndlaTxtYWlsdG86eGlh amlud2VpQGh1YXdlaS5jb20+DQpEYXRlOiAyMDEyLTA5LTEwIDE1OjUxDQpUbzogcHBzcEBpZXRm Lm9yZzxtYWlsdG86cHBzcEBpZXRmLm9yZz4NClN1YmplY3Q6IFtwcHNwXSBuZXh0IHN0ZXAgb2Yg dHJhY2tlciBkb2N1bWVudA0KSGkgYWxsLA0KDQpJIG5vdGljZSB0aGVyZSBhcmUgdHdvIGNvbmNl cm5zIGluIHRyYWNrZXIgZG9jdW1lbnQgZnJvbSBJRVRGIDg0IG1lZXRpbmcgbWludXRlcywgaW4g b3JkZXIgdG8gYWNjZWxlcmF0ZSB0aGUgcHJvY2Vzc2luZyBvZiB0aGlzIGRvY3VtZW50LCBJoa9k IGxpa2UgdG8gc2hvdyBteSB1bmRlcnN0YW5kaW5nIGZpcnN0bHkuIEhvcGUgd2UgY2FuIHB1c2gg dGhpcyB3b3JrIGZvcndhcmQgYW5kIGdldCBjb25zZW5zdXMgYXMgc29vbiBhcyBwb3NzaWJsZS4N Cg0KMSwgUGVlciBJRCBpcyBnbG9iYWwgdW5pcXVlIHRvIGlkZW50aWZ5IHRoZSBQZWVyLCBmcm9t IHRoaXMgcG9pbnQgb2YgdmlldywgdGhlIFBlZXIgSVAgYWRkcmVzcyBpcyBvcHRpb25hbCB0byBp ZGVudGlmeSB0aGUgUGVlci4gSU1PIGl0IGNvdWxkIGJlIHVzZWZ1bCBpbiBhIGNsb3NlZCBzd2Fy bSBzY2VuYXJpbywgaW4gd2hpY2ggdGhlIHBlZXJzIChib3RoIGxlZWNoIGFuZCBzZWVkKSBhcmUg YmVoaW5kIHRoZSBOQVQgYW5kIHRoZXkgY2FuIHNoYXJlIHRoZSBtZWRpYSBjb250ZW50IGluIHRo ZSBsb2NhbCBkb21haW4gKGUuZy4sIGVudGVycHJpc2UgaW5zaWRlKS4gSWYgSSBhbSByaWdodCwg SSBzdWdnZXN0IHNvbWUgdGV4dCBzaG91bGQgYmUgZ2l2ZW4gdG8gZGVzY3JpYmUgdGhpcyBzY2Vu YXJpby4NCg0KMiwgRW5jb2RpbmcgeG1sIG9yIGJpbmFyeSBleHBlcmllbmNlcyBhIGxvbmcgZGlz Y3Vzc2lvbiwgZGlmZmVyZW50IHBlcnNvbiBoYXZlIGRpZmZlcmVudCBwcmVmZXJlbmNlLiBPbmUg Y29tcHJvbWlzZSBpcyBlbmNvZGluZyBhbmQgZGVjb2RpbmcgWE1MIGluIGJpbmFyeSwgdGhlIHJl bGF0ZWQgY29udGV4dCBpcyBzcGVjaWZpZWQgaW4gVzNDIEVmZmljaWVudCBYTUwgSW50ZXJjaGFu Z2UgV29ya2luZyBHcm91cCBvciBpbiBJU08vSUVDIDIzMDAxLVBhcnQgMSChsUJpbmFyeSBNUEVH IGZvcm1hdCBmb3IgWE1MobEuIFRoZXJlZm9yZSwgZW5jb2RpbmcgYm90aCBYTUwgYW5kIEhUVFAg aW4gYmluYXJ5IGZvcm1hdCBhcmUgaW1wbGVtZW50YXRpb24gb3B0aW9ucy4gVGhlIGRyYWZ0IGNh biBoYXZlIGEgY291cGxlIG9mIHBhcmFncmFwaHMgcHJvdmlkaW5nIHRob3NlIG9wdGlvbnMgaW4g dGVybXMgb2YgaW1wbGVtZW50YXRpb24gbm90ZXMuDQoNCkFueSBjb21tZW50cz8NCg0KVGhhbmsg eW91IQ0KDQoNCkppbndlaQ0K --_000_A8219E7785257C47B75B6DCE682F8D2F2BFC868ESZXEML511MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Yunf= ei,

&n= bsp;

Wow, yo= ur feedback is very prompt!  

&n= bsp;

Yes, th= e Peer IP information can be used in a limited scenario, for example, all t= he peers are in a enterprise network and are behind the enterprise NAT, the= y can transmit the enterprise files among the enterprise network via their local IP addresses. But the Peer ID is ma= ndatory and can=A1=AFt be replaced by Peer IP information IMHO.<= /span>

&n= bsp;

Do you = mean the conclusion is removing encoding type related text from this docume= nt? if yes, will the text be moved into another document, e.g., tracker ext= ension draft?

&n= bsp;

Thank y= ou!

&n= bsp;

&n= bsp;

Jinwei<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile= .com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C210=C8=D5 16:16
=CA=D5=BC=FE=C8=CB: Xiajinwei; ppsp
=D6=F7=CC=E2: Re: [ppsp] next step of tracker document

 

Hi Jinwei,

    For point1, when you m= ention peer IP address is optional to identify the peer. Do you mean it's *= feasible* or a *suitable candidate*? If it were the case, I agree with you at this point.

   For  point2, the consensus i= n last IETF on this draft should be "concentrating on the message* if = I don't remember wrong. Regarding the encoding part, you can ask Wes and Fabio for more comments.

 

Thanks.

BR

Yunfei 

zhangyunfei

 

From: Xiajinwei

Date: 2012-= 09-10 15:51

Subject:=  [p= psp] next step of tracker document

Hi all,

&nbs= p;

I notice = there are two concerns in tracker document from IETF 84 meeting minutes, in= order to accelerate the processing of this document, I=A1=AFd like to show= my understanding firstly. Hope we can push this work forward and get consensus as soon as possible.=

&nbs= p;

1, Peer I= D is global unique to identify the Peer, from this point of view, the Peer = IP address is optional to identify the Peer. IMO it could be useful in a cl= osed swarm scenario, in which the peers (both leech and seed) are behind the NAT and they can share the media cont= ent in the local domain (e.g., enterprise inside). If I am right, I suggest= some text should be given to describe this scenario.

&nbs= p;

2, Encodi= ng xml or binary experiences a long discussion, different person have diffe= rent preference. One compromise is encoding and decoding XML in binary, the= related context is specified in W3C Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 =A1=B1Binary= MPEG format for XML=A1=B1. Therefore, encoding both XML and HTTP in binary= format are implementation options. The draft can have a couple of paragrap= hs providing those options in terms of implementation notes.

&nbs= p;

Any comme= nts?

&nbs= p;

Thank you= !

&nbs= p;

&nbs= p;

Jinwei

--_000_A8219E7785257C47B75B6DCE682F8D2F2BFC868ESZXEML511MBSchi_-- From zhangyunfei@chinamobile.com Mon Sep 10 03:13:10 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0FA21F8600 for ; Mon, 10 Sep 2012 03:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.676 X-Spam-Level: X-Spam-Status: No, score=-94.676 tagged_above=-999 required=5 tests=[AWL=-3.948, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyN8SKuqr1SA for ; Mon, 10 Sep 2012 03:13:09 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DE49121F84F3 for ; Mon, 10 Sep 2012 03:13:05 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 53297E545; Mon, 10 Sep 2012 18:13:05 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 14829E53A; Mon, 10 Sep 2012 18:13:05 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012091018130226-26266 ; Mon, 10 Sep 2012 18:13:02 +0800 Date: Mon, 10 Sep 2012 18:12:58 +0800 From: zhangyunfei To: 'Xiajinwei' , ppsp References: <2012091016154731655619@chinamobile.com>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012091018125862401141@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-10 18:13:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-10 18:13:04, Serialize complete at 2012-09-10 18:13:04 Content-Type: multipart/alternative; boundary="----=_001_NextPart072676823206_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19174.005 X-TM-AS-Result: No--45.169-7.0-31-10 X-imss-scan-details: No--45.169-7.0-31-10;No--45.169-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] =?gb2312?b?u9i4tDogtPC4tDogIG5leHQgc3RlcCBvZiB0cmFja2Vy?= =?gb2312?b?IGRvY3VtZW50?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 10:13:10 -0000 This is a multi-part message in MIME format. ------=_001_NextPart072676823206_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgSmlud2VpIChTcGVha2luZyBpbmRpdmlkdWFsbHkpLA0KICAgICBNeSBzdWdnZXN0aW9uIGlz IHRvIGNvbnNpZGVyIHBlZXIgSVAocHJpdmF0ZSwgcHVibGljKStwb3J0KHByaXZhdGUsIHB1Ymxp YykgZm9yIHRoZSBwdXJwb3NlIG9mIGlkZW50aWZ5aW5nIHRoZSBwZWVyLiBJcyBpdCBlbm91Z2g/ IE9yIHdlIG1heSBuZWVkIG1vcmUgaW5mb3JtYXRpb24gZm9yIHRoZSBpZGVudGlmaWNhdGlvbi4N CiAgICAgSSBhbSBub3QgbWVhbmluZyB0b3RhbGx5IHJlbW92aW5nIHRoZSBlbmNvZGluZyBpbiB0 aGUgdHJhY2tlciBwcm90b2NvbC4gSG93ZXZlciBJIHN1Z2dlc3QgaW4gY3VycmVudCBzdGFnZSwg ZW5jb2RpbmcgcGFydCBtYXkgYmUgcGxhY2VkIGluIHRoZSBhcHBlbmRpeCBwYXJ0LCBhcyBhIHN0 ZXAgdG8gcmVhbGl6ZSB0aGUgY29uc2Vuc3VzIGluIGxhc3QgSUVURi4gDQogICAgUmVnYXJkaW5n IHRoZSBlbmNvZGluZyBwcm9wb3NhbCB5b3UgcmFpc2VkLCBteSBmZWVsaW5nIGlzIHRoYXQgd2Ug YXQgbGVhc3QgbmVlZCB0byBhc2sgdGhlIHBlb3BsZSB3aXRoIGNvbmNlcm5zIGluIGxhc3QgSUVU RiAoU2VlIHRoZSBtaW51dGVzKSBmb3IgdGhlaXIgY29tbWVudHMuDQoNCkJSDQpZdW5mZWkNCiAg ICAgDQoNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0Kt6K8/sjLo7ogWGlhamlud2VpDQq3osvNyrG8 5KO6IDIwMTItMDktMTAgMTY6MzYNCsrVvP7Iy6O6IHpoYW5neXVuZmVpOyBwcHNwDQrW98zio7og tPC4tDogW3Bwc3BdIG5leHQgc3RlcCBvZiB0cmFja2VyIGRvY3VtZW50DQpIaSBZdW5mZWksDQog DQpXb3csIHlvdXIgZmVlZGJhY2sgaXMgdmVyeSBwcm9tcHQhICANCiANClllcywgdGhlIFBlZXIg SVAgaW5mb3JtYXRpb24gY2FuIGJlIHVzZWQgaW4gYSBsaW1pdGVkIHNjZW5hcmlvLCBmb3IgZXhh bXBsZSwgYWxsIHRoZSBwZWVycyBhcmUgaW4gYSBlbnRlcnByaXNlIG5ldHdvcmsgYW5kIGFyZSBi ZWhpbmQgdGhlIGVudGVycHJpc2UgTkFULCB0aGV5IGNhbiB0cmFuc21pdCB0aGUgZW50ZXJwcmlz ZSBmaWxlcyBhbW9uZyB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrIHZpYSB0aGVpciBsb2NhbCBJUCBh ZGRyZXNzZXMuIEJ1dCB0aGUgUGVlciBJRCBpcyBtYW5kYXRvcnkgYW5kIGNhbqGvdCBiZSByZXBs YWNlZCBieSBQZWVyIElQIGluZm9ybWF0aW9uIElNSE8uDQogDQpEbyB5b3UgbWVhbiB0aGUgY29u Y2x1c2lvbiBpcyByZW1vdmluZyBlbmNvZGluZyB0eXBlIHJlbGF0ZWQgdGV4dCBmcm9tIHRoaXMg ZG9jdW1lbnQ/IGlmIHllcywgd2lsbCB0aGUgdGV4dCBiZSBtb3ZlZCBpbnRvIGFub3RoZXIgZG9j dW1lbnQsIGUuZy4sIHRyYWNrZXIgZXh0ZW5zaW9uIGRyYWZ0Pw0KIA0KVGhhbmsgeW91IQ0KIA0K IA0KSmlud2VpDQogDQq3orz+yMs6IHpoYW5neXVuZmVpIFttYWlsdG86emhhbmd5dW5mZWlAY2hp bmFtb2JpbGUuY29tXSANCreiy83KsbzkOiAyMDEyxOo51MIxMMjVIDE2OjE2DQrK1bz+yMs6IFhp YWppbndlaTsgcHBzcA0K1vfM4jogUmU6IFtwcHNwXSBuZXh0IHN0ZXAgb2YgdHJhY2tlciBkb2N1 bWVudA0KIA0KSGkgSmlud2VpLA0KICAgIEZvciBwb2ludDEsIHdoZW4geW91IG1lbnRpb24gcGVl ciBJUCBhZGRyZXNzIGlzIG9wdGlvbmFsIHRvIGlkZW50aWZ5IHRoZSBwZWVyLiBEbyB5b3UgbWVh biBpdCdzICpmZWFzaWJsZSogb3IgYSAqc3VpdGFibGUgY2FuZGlkYXRlKj8gSWYgaXQgd2VyZSB0 aGUgY2FzZSwgSSBhZ3JlZSB3aXRoIHlvdSBhdCB0aGlzIHBvaW50Lg0KICAgRm9yICBwb2ludDIs IHRoZSBjb25zZW5zdXMgaW4gbGFzdCBJRVRGIG9uIHRoaXMgZHJhZnQgc2hvdWxkIGJlICJjb25j ZW50cmF0aW5nIG9uIHRoZSBtZXNzYWdlKiBpZiBJIGRvbid0IHJlbWVtYmVyIHdyb25nLiBSZWdh cmRpbmcgdGhlIGVuY29kaW5nIHBhcnQsIHlvdSBjYW4gYXNrIFdlcyBhbmQgRmFiaW8gZm9yIG1v cmUgY29tbWVudHMuDQogDQpUaGFua3MuDQpCUg0KWXVuZmVpIA0KDQoNCg0Kemhhbmd5dW5mZWkN CiANCkZyb206IFhpYWppbndlaQ0KRGF0ZTogMjAxMi0wOS0xMCAxNTo1MQ0KVG86IHBwc3BAaWV0 Zi5vcmcNClN1YmplY3Q6IFtwcHNwXSBuZXh0IHN0ZXAgb2YgdHJhY2tlciBkb2N1bWVudA0KSGkg YWxsLA0KIA0KSSBub3RpY2UgdGhlcmUgYXJlIHR3byBjb25jZXJucyBpbiB0cmFja2VyIGRvY3Vt ZW50IGZyb20gSUVURiA4NCBtZWV0aW5nIG1pbnV0ZXMsIGluIG9yZGVyIHRvIGFjY2VsZXJhdGUg dGhlIHByb2Nlc3Npbmcgb2YgdGhpcyBkb2N1bWVudCwgSaGvZCBsaWtlIHRvIHNob3cgbXkgdW5k ZXJzdGFuZGluZyBmaXJzdGx5LiBIb3BlIHdlIGNhbiBwdXNoIHRoaXMgd29yayBmb3J3YXJkIGFu ZCBnZXQgY29uc2Vuc3VzIGFzIHNvb24gYXMgcG9zc2libGUuDQogDQoxLCBQZWVyIElEIGlzIGds b2JhbCB1bmlxdWUgdG8gaWRlbnRpZnkgdGhlIFBlZXIsIGZyb20gdGhpcyBwb2ludCBvZiB2aWV3 LCB0aGUgUGVlciBJUCBhZGRyZXNzIGlzIG9wdGlvbmFsIHRvIGlkZW50aWZ5IHRoZSBQZWVyLiBJ TU8gaXQgY291bGQgYmUgdXNlZnVsIGluIGEgY2xvc2VkIHN3YXJtIHNjZW5hcmlvLCBpbiB3aGlj aCB0aGUgcGVlcnMgKGJvdGggbGVlY2ggYW5kIHNlZWQpIGFyZSBiZWhpbmQgdGhlIE5BVCBhbmQg dGhleSBjYW4gc2hhcmUgdGhlIG1lZGlhIGNvbnRlbnQgaW4gdGhlIGxvY2FsIGRvbWFpbiAoZS5n LiwgZW50ZXJwcmlzZSBpbnNpZGUpLiBJZiBJIGFtIHJpZ2h0LCBJIHN1Z2dlc3Qgc29tZSB0ZXh0 IHNob3VsZCBiZSBnaXZlbiB0byBkZXNjcmliZSB0aGlzIHNjZW5hcmlvLg0KIA0KMiwgRW5jb2Rp bmcgeG1sIG9yIGJpbmFyeSBleHBlcmllbmNlcyBhIGxvbmcgZGlzY3Vzc2lvbiwgZGlmZmVyZW50 IHBlcnNvbiBoYXZlIGRpZmZlcmVudCBwcmVmZXJlbmNlLiBPbmUgY29tcHJvbWlzZSBpcyBlbmNv ZGluZyBhbmQgZGVjb2RpbmcgWE1MIGluIGJpbmFyeSwgdGhlIHJlbGF0ZWQgY29udGV4dCBpcyBz cGVjaWZpZWQgaW4gVzNDIEVmZmljaWVudCBYTUwgSW50ZXJjaGFuZ2UgV29ya2luZyBHcm91cCBv ciBpbiBJU08vSUVDIDIzMDAxLVBhcnQgMSChsUJpbmFyeSBNUEVHIGZvcm1hdCBmb3IgWE1MobEu IFRoZXJlZm9yZSwgZW5jb2RpbmcgYm90aCBYTUwgYW5kIEhUVFAgaW4gYmluYXJ5IGZvcm1hdCBh cmUgaW1wbGVtZW50YXRpb24gb3B0aW9ucy4gVGhlIGRyYWZ0IGNhbiBoYXZlIGEgY291cGxlIG9m IHBhcmFncmFwaHMgcHJvdmlkaW5nIHRob3NlIG9wdGlvbnMgaW4gdGVybXMgb2YgaW1wbGVtZW50 YXRpb24gbm90ZXMuDQogDQpBbnkgY29tbWVudHM/DQogDQpUaGFuayB5b3UhDQogDQogDQpKaW53 ZWk= ------=_001_NextPart072676823206_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Jinwei (Speaking individually),
     My suggestion is to consider peer IP(private= ,=20 public)+port(private, public) for the purpose of identifying the peer. Is = it=20 enough? Or we may need more information for the identification.
     I am not meaning totally removing the=20 encoding in the tracker protocol. However I suggest in current stage,= =20 encoding part may be placed in the appendix part, as a step to realize the= =20 consensus in last IETF.
    Regarding the encoding proposal you raised, my fee= ling=20 is that we at least need to ask the people with concerns in last IETF (See= the=20 minutes) for their comments.
 
BR
Yunfei
    
 
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Xiajinwei
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-09-10 16:36
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei; ppsp
=D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] next step of trac= ker document

Hi=20 Yunfei,

 

Wow, your= feedback is=20 very prompt!  

 

Yes, the = Peer IP=20 information can be used in a limited scenario, for example, all the peers = are in=20 a enterprise network and are behind the enterprise NAT, they can transmit = the=20 enterprise files among the enterprise network via their local IP addresses= . But=20 the Peer ID is mandatory and can=A1=AFt be replaced by Peer IP information= =20 IMHO.

 

Do you me= an the=20 conclusion is removing encoding type related text from this document? if y= es,=20 will the text be moved into another document, e.g., tracker extension=20 draft?

 

Thank=20 you!

 

 

Jinwei

 

=B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile.com]
= =B7=A2=CB=CD=CA=B1=BC= =E4: 2012=C4=EA9=D4=C210=C8=D5=20 16:16
=CA=D5=BC=FE=C8=CB: Xiajinwei;=20 ppsp
=D6=F7=CC=E2: Re: [ppsp]=20 next step of tracker document

 

From: Xiajinwei

Date: 2012-09-10 15:51

To: ppsp@ietf.org

Subject: [ppsp] next step of tracker=20 document

Hi=20 all,

 

I notice th= ere are two=20 concerns in tracker document from IETF 84 meeting minutes, in order to=20 accelerate the processing of this document, I=A1=AFd like to show my under= standing=20 firstly. Hope we can push this work forward and get consensus as soon as=20 possible.

 

1, Peer ID = is global=20 unique to identify the Peer, from this point of view, the Peer IP address = is=20 optional to identify the Peer. IMO it could be useful in a closed swarm=20 scenario, in which the peers (both leech and seed) are behind the NAT and = they=20 can share the media content in the local domain (e.g., enterprise inside).= If I=20 am right, I suggest some text should be given to describe this=20 scenario.

 

2, Encoding= xml or=20 binary experiences a long discussion, different person have different=20 preference. One compromise is encoding and decoding XML in binary, the rel= ated=20 context is specified in W3C Efficient XML Interchange Working Group or in=20 ISO/IEC 23001-Part 1 =A1=B1Binary MPEG format for XML=A1=B1. Therefor= e, encoding both=20 XML and HTTP in binary format are implementation options. The draft can ha= ve a=20 couple of paragraphs providing those options in terms of implementation=20 notes.

 

Any=20 comments?

 

Thank=20 you!

 

 

Jinwei

------=_001_NextPart072676823206_=------ From sprevidi@cisco.com Mon Sep 10 08:58:57 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3743921F86AB for ; Mon, 10 Sep 2012 08:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.097 X-Spam-Level: X-Spam-Status: No, score=-107.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_27=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PvHM5d+AZkJ for ; Mon, 10 Sep 2012 08:58:56 -0700 (PDT) Received: from av-tac-sj.cisco.com (av-tac-sj.cisco.com [171.68.227.119]) by ietfa.amsl.com (Postfix) with ESMTP id 545E021F853A for ; Mon, 10 Sep 2012 08:58:56 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AFwt9o013338 for ; Mon, 10 Sep 2012 08:58:55 -0700 (PDT) Received: from dhcp-171-71-146-228.cisco.com (dhcp-171-71-146-228.cisco.com [171.71.146.228]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AFwrGm012773; Mon, 10 Sep 2012 08:58:53 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=GB2312 From: stefano previdi X-Priority: 3 (Normal) In-Reply-To: <2012091018125862401141@chinamobile.com> Date: Mon, 10 Sep 2012 17:58:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2012091016154731655619@chinamobile.com>, <2012091018125862401141@chinamobile.com> To: zhangyunfei X-Mailer: Apple Mail (2.1278) Cc: ppsp Subject: Re: [ppsp] =?utf-8?b?5Zue5aSNOiDnrZTlpI06ICBuZXh0IHN0ZXAgb2YgdHJhY2tl?= =?utf-8?q?r_document?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:58:57 -0000 Jinwei, On Sep 10, 2012, at 12:12 PM, zhangyunfei wrote: > Hi Jinwei (Speaking individually), > My suggestion is to consider peer IP(private, = public)+port(private, public) for the purpose of identifying the peer. = Is it enough? Or we may need more information for the identification. I tent to agree. We need a mechanism that will work the _same_ for any kind of deployment = (private/public). s. > I am not meaning totally removing the encoding in the tracker = protocol. However I suggest in current stage, encoding part may be = placed in the appendix part, as a step to realize the consensus in last = IETF. > Regarding the encoding proposal you raised, my feeling is that we = at least need to ask the people with concerns in last IETF (See the = minutes) for their comments. > =20 > BR > Yunfei > =20 > =20 > =20 > zhangyunfei > =20 > =B7=A2=BC=FE=C8=CB=A3=BA Xiajinwei > =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-09-10 16:36 > =CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei; ppsp > =D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] next step of tracker document > Hi Yunfei, > =20 > Wow, your feedback is very prompt! =20 > =20 > Yes, the Peer IP information can be used in a limited scenario, for = example, all the peers are in a enterprise network and are behind the = enterprise NAT, they can transmit the enterprise files among the = enterprise network via their local IP addresses. But the Peer ID is = mandatory and can=A1=AFt be replaced by Peer IP information IMHO. > =20 > Do you mean the conclusion is removing encoding type related text from = this document? if yes, will the text be moved into another document, = e.g., tracker extension draft? > =20 > Thank you! > =20 > =20 > Jinwei > =20 > =B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile.com]=20= > =B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C210=C8=D5 16:16 > =CA=D5=BC=FE=C8=CB: Xiajinwei; ppsp > =D6=F7=CC=E2: Re: [ppsp] next step of tracker document > =20 > Hi Jinwei, > For point1, when you mention peer IP address is optional to = identify the peer. Do you mean it's *feasible* or a *suitable = candidate*? If it were the case, I agree with you at this point. > For point2, the consensus in last IETF on this draft should be = "concentrating on the message* if I don't remember wrong. Regarding the = encoding part, you can ask Wes and Fabio for more comments. > =20 > Thanks. > BR > Yunfei=20 > zhangyunfei > =20 > From: Xiajinwei > Date: 2012-09-10 15:51 > To: ppsp@ietf.org > Subject: [ppsp] next step of tracker document > Hi all, > =20 > I notice there are two concerns in tracker document from IETF 84 = meeting minutes, in order to accelerate the processing of this document, = I=A1=AFd like to show my understanding firstly. Hope we can push this = work forward and get consensus as soon as possible. > =20 > 1, Peer ID is global unique to identify the Peer, from this point of = view, the Peer IP address is optional to identify the Peer. IMO it could = be useful in a closed swarm scenario, in which the peers (both leech and = seed) are behind the NAT and they can share the media content in the = local domain (e.g., enterprise inside). If I am right, I suggest some = text should be given to describe this scenario. > =20 > 2, Encoding xml or binary experiences a long discussion, different = person have different preference. One compromise is encoding and = decoding XML in binary, the related context is specified in W3C = Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 = =A1=B1Binary MPEG format for XML=A1=B1. Therefore, encoding both XML and = HTTP in binary format are implementation options. The draft can have a = couple of paragraphs providing those options in terms of implementation = notes. > =20 > Any comments? > =20 > Thank you! > =20 > =20 > Jinwei > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From xiajinwei@huawei.com Mon Sep 10 19:07:36 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51CC21F84FE for ; Mon, 10 Sep 2012 19:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.657 X-Spam-Level: X-Spam-Status: No, score=0.657 tagged_above=-999 required=5 tests=[AWL=-2.731, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, J_CHICKENPOX_27=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 575YfOSIi1CK for ; Mon, 10 Sep 2012 19:07:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B0BDF21F84FA for ; Mon, 10 Sep 2012 19:07:34 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJN62503; Tue, 11 Sep 2012 02:07:33 +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.1.323.3; Tue, 11 Sep 2012 03:07:24 +0100 Received: from SZXEML429-HUB.china.huawei.com (10.72.61.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Sep 2012 03:07:30 +0100 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.129]) by SZXEML429-HUB.china.huawei.com ([10.72.61.37]) with mapi id 14.01.0323.003; Tue, 11 Sep 2012 10:07:24 +0800 From: Xiajinwei To: stefano previdi , zhangyunfei , Rui Cruz Thread-Topic: =?gb2312?B?W3Bwc3BdILvYuLQ6ILTwuLQ6ICBuZXh0IHN0ZXAgb2YgdHJhY2tlciBkb2N1?= =?gb2312?Q?ment?= Thread-Index: AQHNj200Lo9zY5fbuUWxgMxF+sq2PpeEXvIA Date: Tue, 11 Sep 2012 02:07:24 +0000 Message-ID: References: <2012091016154731655619@chinamobile.com>, <2012091018125862401141@chinamobile.com> 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.75] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: ppsp Subject: [ppsp] =?gb2312?b?tPC4tDogILvYuLQ6ILTwuLQ6ICBuZXh0IHN0ZXAgb2Yg?= =?gb2312?b?dHJhY2tlciBkb2N1bWVudA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 02:07:36 -0000 SGkgU3RlZmFubyBhbmQgWXVuZmVpLA0KDQpJZiB3ZSBjb25zaWRlciBhIGdlbmVyYWwgbWVjaGFu aXNtIHRvIGlkZW50aWZ5IFBlZXIsICJJUCtQb3J0IiB3aWxsIGJlIGEgZ29vZCBjYW5kaWRhdGUs IHdoaWNoIGNhbiBhcHBseSB0byBlaXRoZXIgZ2xvYmFsIG9yIGxvY2FsIHNjZW5hcmlvLiBDcnV6 LCBpZiB5b3UgYWdyZWUgdGhpcywgd2UgY2FuIHJlcGhyYXNlIG91ciBkb2N1bWVudC4NCg0KSSBh Z3JlZSB0byB5b3VyIHN1Z2dlc3Rpb24sIHdlIGNhbiByZW1vdmUgZW5jb2RpbmcgcGFydHMgaW50 byBhcHBlbmRpeCB0ZW1wb3JhcmlseSwgYWRvcHQgdHJhY2tlciBwcm90b2NvbCBhbmQgd29yayBv biBtZXNzYWdlIHBhcnRzIGF0IGZpcnN0LCBhbmQgdGhlbiBkZWNpZGUgdGhlIGVuY29kaW5nIHR5 cGUgbGF0ZXIuIFRoaXMgcHJvY2Vzc2luZyBsb29rcyBnb29kIGZvciBtZS4gDQoNCkFueSBvdGhl ciBjb21tZW50cz8gQ3J1ej8NCg0KQlINCkppbndlaQ0KDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiC3orz+yMs6IHN0ZWZhbm8gcHJldmlkaSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbV0NCj4g t6LLzcqxvOQ6IDIwMTLE6jnUwjEwyNUgMjM6NTkNCj4gytW8/sjLOiB6aGFuZ3l1bmZlaQ0KPiCz rcvNOiBYaWFqaW53ZWk7IHBwc3ANCj4g1vfM4jogUmU6IFtwcHNwXSC72Li0OiC08Li0OiBuZXh0 IHN0ZXAgb2YgdHJhY2tlciBkb2N1bWVudA0KPiANCj4gSmlud2VpLA0KPiANCj4gT24gU2VwIDEw LCAyMDEyLCBhdCAxMjoxMiBQTSwgemhhbmd5dW5mZWkgd3JvdGU6DQo+ID4gSGkgSmlud2VpIChT cGVha2luZyBpbmRpdmlkdWFsbHkpLA0KPiA+ICAgICAgTXkgc3VnZ2VzdGlvbiBpcyB0byBjb25z aWRlciBwZWVyIElQKHByaXZhdGUsIHB1YmxpYykrcG9ydChwcml2YXRlLA0KPiBwdWJsaWMpIGZv ciB0aGUgcHVycG9zZSBvZiBpZGVudGlmeWluZyB0aGUgcGVlci4gSXMgaXQgZW5vdWdoPyBPciB3 ZSBtYXkgbmVlZA0KPiBtb3JlIGluZm9ybWF0aW9uIGZvciB0aGUgaWRlbnRpZmljYXRpb24uDQo+ IA0KPiANCj4gSSB0ZW50IHRvIGFncmVlLg0KPiANCj4gV2UgbmVlZCBhIG1lY2hhbmlzbSB0aGF0 IHdpbGwgd29yayB0aGUgX3NhbWVfIGZvciBhbnkga2luZCBvZiBkZXBsb3ltZW50DQo+IChwcml2 YXRlL3B1YmxpYykuDQo+IA0KPiBzLg0KPiANCj4gDQo+IA0KPiANCj4gPiAgICAgIEkgYW0gbm90 IG1lYW5pbmcgdG90YWxseSByZW1vdmluZyB0aGUgZW5jb2RpbmcgaW4gdGhlIHRyYWNrZXIgcHJv dG9jb2wuDQo+IEhvd2V2ZXIgSSBzdWdnZXN0IGluIGN1cnJlbnQgc3RhZ2UsIGVuY29kaW5nIHBh cnQgbWF5IGJlIHBsYWNlZCBpbiB0aGUNCj4gYXBwZW5kaXggcGFydCwgYXMgYSBzdGVwIHRvIHJl YWxpemUgdGhlIGNvbnNlbnN1cyBpbiBsYXN0IElFVEYuDQo+ID4gICAgIFJlZ2FyZGluZyB0aGUg ZW5jb2RpbmcgcHJvcG9zYWwgeW91IHJhaXNlZCwgbXkgZmVlbGluZyBpcyB0aGF0IHdlIGF0DQo+ IGxlYXN0IG5lZWQgdG8gYXNrIHRoZSBwZW9wbGUgd2l0aCBjb25jZXJucyBpbiBsYXN0IElFVEYg KFNlZSB0aGUgbWludXRlcykgZm9yDQo+IHRoZWlyIGNvbW1lbnRzLg0KPiA+DQo+ID4gQlINCj4g PiBZdW5mZWkNCj4gPg0KPiA+DQo+ID4NCj4gPiB6aGFuZ3l1bmZlaQ0KPiA+DQo+ID4gt6K8/sjL o7ogWGlhamlud2VpDQo+ID4gt6LLzcqxvOSjuiAyMDEyLTA5LTEwIDE2OjM2DQo+ID4gytW8/sjL o7ogemhhbmd5dW5mZWk7IHBwc3ANCj4gPiDW98zio7ogtPC4tDogW3Bwc3BdIG5leHQgc3RlcCBv ZiB0cmFja2VyIGRvY3VtZW50DQo+ID4gSGkgWXVuZmVpLA0KPiA+DQo+ID4gV293LCB5b3VyIGZl ZWRiYWNrIGlzIHZlcnkgcHJvbXB0IQ0KPiA+DQo+ID4gWWVzLCB0aGUgUGVlciBJUCBpbmZvcm1h dGlvbiBjYW4gYmUgdXNlZCBpbiBhIGxpbWl0ZWQgc2NlbmFyaW8sIGZvciBleGFtcGxlLCBhbGwN Cj4gdGhlIHBlZXJzIGFyZSBpbiBhIGVudGVycHJpc2UgbmV0d29yayBhbmQgYXJlIGJlaGluZCB0 aGUgZW50ZXJwcmlzZSBOQVQsIHRoZXkNCj4gY2FuIHRyYW5zbWl0IHRoZSBlbnRlcnByaXNlIGZp bGVzIGFtb25nIHRoZSBlbnRlcnByaXNlIG5ldHdvcmsgdmlhIHRoZWlyIGxvY2FsDQo+IElQIGFk ZHJlc3Nlcy4gQnV0IHRoZSBQZWVyIElEIGlzIG1hbmRhdG9yeSBhbmQgY2Fuoa90IGJlIHJlcGxh Y2VkIGJ5IFBlZXIgSVANCj4gaW5mb3JtYXRpb24gSU1ITy4NCj4gPg0KPiA+IERvIHlvdSBtZWFu IHRoZSBjb25jbHVzaW9uIGlzIHJlbW92aW5nIGVuY29kaW5nIHR5cGUgcmVsYXRlZCB0ZXh0IGZy b20gdGhpcw0KPiBkb2N1bWVudD8gaWYgeWVzLCB3aWxsIHRoZSB0ZXh0IGJlIG1vdmVkIGludG8g YW5vdGhlciBkb2N1bWVudCwgZS5nLiwgdHJhY2tlcg0KPiBleHRlbnNpb24gZHJhZnQ/DQo+ID4N Cj4gPiBUaGFuayB5b3UhDQo+ID4NCj4gPg0KPiA+IEppbndlaQ0KPiA+DQo+ID4gt6K8/sjLOiB6 aGFuZ3l1bmZlaSBbbWFpbHRvOnpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbV0NCj4gPiC3osvN yrG85DogMjAxMsTqOdTCMTDI1SAxNjoxNg0KPiA+IMrVvP7IyzogWGlhamlud2VpOyBwcHNwDQo+ ID4g1vfM4jogUmU6IFtwcHNwXSBuZXh0IHN0ZXAgb2YgdHJhY2tlciBkb2N1bWVudA0KPiA+DQo+ ID4gSGkgSmlud2VpLA0KPiA+ICAgICBGb3IgcG9pbnQxLCB3aGVuIHlvdSBtZW50aW9uIHBlZXIg SVAgYWRkcmVzcyBpcyBvcHRpb25hbCB0byBpZGVudGlmeSB0aGUNCj4gcGVlci4gRG8geW91IG1l YW4gaXQncyAqZmVhc2libGUqIG9yIGEgKnN1aXRhYmxlIGNhbmRpZGF0ZSo/IElmIGl0IHdlcmUg dGhlIGNhc2UsDQo+IEkgYWdyZWUgd2l0aCB5b3UgYXQgdGhpcyBwb2ludC4NCj4gPiAgICBGb3Ig IHBvaW50MiwgdGhlIGNvbnNlbnN1cyBpbiBsYXN0IElFVEYgb24gdGhpcyBkcmFmdCBzaG91bGQg YmUNCj4gImNvbmNlbnRyYXRpbmcgb24gdGhlIG1lc3NhZ2UqIGlmIEkgZG9uJ3QgcmVtZW1iZXIg d3JvbmcuIFJlZ2FyZGluZyB0aGUNCj4gZW5jb2RpbmcgcGFydCwgeW91IGNhbiBhc2sgV2VzIGFu ZCBGYWJpbyBmb3IgbW9yZSBjb21tZW50cy4NCj4gPg0KPiA+IFRoYW5rcy4NCj4gPiBCUg0KPiA+ IFl1bmZlaQ0KPiA+IHpoYW5neXVuZmVpDQo+ID4NCj4gPiBGcm9tOiBYaWFqaW53ZWkNCj4gPiBE YXRlOiAyMDEyLTA5LTEwIDE1OjUxDQo+ID4gVG86IHBwc3BAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0 OiBbcHBzcF0gbmV4dCBzdGVwIG9mIHRyYWNrZXIgZG9jdW1lbnQNCj4gPiBIaSBhbGwsDQo+ID4N Cj4gPiBJIG5vdGljZSB0aGVyZSBhcmUgdHdvIGNvbmNlcm5zIGluIHRyYWNrZXIgZG9jdW1lbnQg ZnJvbSBJRVRGIDg0IG1lZXRpbmcNCj4gbWludXRlcywgaW4gb3JkZXIgdG8gYWNjZWxlcmF0ZSB0 aGUgcHJvY2Vzc2luZyBvZiB0aGlzIGRvY3VtZW50LCBJoa9kIGxpa2UgdG8NCj4gc2hvdyBteSB1 bmRlcnN0YW5kaW5nIGZpcnN0bHkuIEhvcGUgd2UgY2FuIHB1c2ggdGhpcyB3b3JrIGZvcndhcmQg YW5kIGdldA0KPiBjb25zZW5zdXMgYXMgc29vbiBhcyBwb3NzaWJsZS4NCj4gPg0KPiA+IDEsIFBl ZXIgSUQgaXMgZ2xvYmFsIHVuaXF1ZSB0byBpZGVudGlmeSB0aGUgUGVlciwgZnJvbSB0aGlzIHBv aW50IG9mIHZpZXcsIHRoZQ0KPiBQZWVyIElQIGFkZHJlc3MgaXMgb3B0aW9uYWwgdG8gaWRlbnRp ZnkgdGhlIFBlZXIuIElNTyBpdCBjb3VsZCBiZSB1c2VmdWwgaW4gYQ0KPiBjbG9zZWQgc3dhcm0g c2NlbmFyaW8sIGluIHdoaWNoIHRoZSBwZWVycyAoYm90aCBsZWVjaCBhbmQgc2VlZCkgYXJlIGJl aGluZCB0aGUNCj4gTkFUIGFuZCB0aGV5IGNhbiBzaGFyZSB0aGUgbWVkaWEgY29udGVudCBpbiB0 aGUgbG9jYWwgZG9tYWluIChlLmcuLCBlbnRlcnByaXNlDQo+IGluc2lkZSkuIElmIEkgYW0gcmln aHQsIEkgc3VnZ2VzdCBzb21lIHRleHQgc2hvdWxkIGJlIGdpdmVuIHRvIGRlc2NyaWJlIHRoaXMN Cj4gc2NlbmFyaW8uDQo+ID4NCj4gPiAyLCBFbmNvZGluZyB4bWwgb3IgYmluYXJ5IGV4cGVyaWVu Y2VzIGEgbG9uZyBkaXNjdXNzaW9uLCBkaWZmZXJlbnQgcGVyc29uIGhhdmUNCj4gZGlmZmVyZW50 IHByZWZlcmVuY2UuIE9uZSBjb21wcm9taXNlIGlzIGVuY29kaW5nIGFuZCBkZWNvZGluZyBYTUwg aW4gYmluYXJ5LA0KPiB0aGUgcmVsYXRlZCBjb250ZXh0IGlzIHNwZWNpZmllZCBpbiBXM0MgRWZm aWNpZW50IFhNTCBJbnRlcmNoYW5nZSBXb3JraW5nDQo+IEdyb3VwIG9yIGluIElTTy9JRUMgMjMw MDEtUGFydCAxIKGxQmluYXJ5IE1QRUcgZm9ybWF0IGZvciBYTUyhsS4gVGhlcmVmb3JlLA0KPiBl bmNvZGluZyBib3RoIFhNTCBhbmQgSFRUUCBpbiBiaW5hcnkgZm9ybWF0IGFyZSBpbXBsZW1lbnRh dGlvbiBvcHRpb25zLiBUaGUNCj4gZHJhZnQgY2FuIGhhdmUgYSBjb3VwbGUgb2YgcGFyYWdyYXBo cyBwcm92aWRpbmcgdGhvc2Ugb3B0aW9ucyBpbiB0ZXJtcyBvZg0KPiBpbXBsZW1lbnRhdGlvbiBu b3Rlcy4NCj4gPg0KPiA+IEFueSBjb21tZW50cz8NCj4gPg0KPiA+IFRoYW5rIHlvdSENCj4gPg0K PiA+DQo+ID4gSmlud2VpDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBwcHNwIG1haWxpbmcgbGlzdA0KPiA+IHBwc3BAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3ANCg0K From zongning@huawei.com Sun Sep 16 18:27:54 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1BA21F843A for ; Sun, 16 Sep 2012 18:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.774 X-Spam-Level: X-Spam-Status: No, score=-101.774 tagged_above=-999 required=5 tests=[AWL=-4.824, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_27=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKQrgxK+HaJt for ; Sun, 16 Sep 2012 18:27:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC021F842B for ; Sun, 16 Sep 2012 18:27:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKS52038; Mon, 17 Sep 2012 01:27:52 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 02:27:35 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 17 Sep 2012 02:27:50 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Mon, 17 Sep 2012 09:27:39 +0800 From: Zongning To: zhangyunfei , Xiajinwei , ppsp Thread-Topic: =?gb2312?B?W3Bwc3BdILvYuLQ6ILTwuLQ6ICBuZXh0IHN0ZXAgb2YgdHJhY2tlciBkb2N1?= =?gb2312?Q?ment?= Thread-Index: AQHNjzznQuldwh0uBkGWBhQ6MC8KnpeNx2Xw Date: Mon, 17 Sep 2012 01:27:38 +0000 Message-ID: References: <2012091016154731655619@chinamobile.com>, <2012091018125862401141@chinamobile.com> In-Reply-To: <2012091018125862401141@chinamobile.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.38] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677924AE6F94szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] =?gb2312?b?u9i4tDogtPC4tDogIG5leHQgc3RlcCBvZiB0cmFja2Vy?= =?gb2312?b?IGRvY3VtZW50?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Sep 2012 01:27:54 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677924AE6F94szxeml504mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Rm9yIHBvaW50IHR3bywgSSBhZ3JlZSB0aGF0IHdlIGNhbiBtb3ZlIHRoZSBlbmNvZGluZyBwYXJ0 IG9mIHRyYWNrZXIgcHJvdG9jb2wgdG8gYXBwZW5kaXgsIGFzIGJvdGggWE1MIGFuZCBiaW5hcnkg YXJlIGF0IGxlYXN0IGZlYXNpYmxlLg0KQnV0IEkgd291bGQgKnN0cm9uZ2x5KiB3YW50IHRvIGhl YXIgdGhlIGNvbW1lbnRzIGZyb20gdGhlIHBlb3BsZSByYWlzaW5nIHRoaXMgaXNzdWUgaW4gbGFz dCBQUFNQIHNlc3Npb24gYWJvdXQgZW5jb2RpbmcgqEMgZm9yIGV4YW1wbGUsIGVmZmljaWVuY3kg Y29uY2VybnM/DQpUaGFua3MuDQoNCi1OaW5nDQoNCkZyb206IHBwc3AtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIHpoYW5neXVuZmVp DQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAxMCwgMjAxMiA2OjEzIFBNDQpUbzogWGlhamlud2Vp OyBwcHNwDQpTdWJqZWN0OiBbcHBzcF0gu9i4tDogtPC4tDogbmV4dCBzdGVwIG9mIHRyYWNrZXIg ZG9jdW1lbnQNCg0KSGkgSmlud2VpIChTcGVha2luZyBpbmRpdmlkdWFsbHkpLA0KICAgICBNeSBz dWdnZXN0aW9uIGlzIHRvIGNvbnNpZGVyIHBlZXIgSVAocHJpdmF0ZSwgcHVibGljKStwb3J0KHBy aXZhdGUsIHB1YmxpYykgZm9yIHRoZSBwdXJwb3NlIG9mIGlkZW50aWZ5aW5nIHRoZSBwZWVyLiBJ cyBpdCBlbm91Z2g/IE9yIHdlIG1heSBuZWVkIG1vcmUgaW5mb3JtYXRpb24gZm9yIHRoZSBpZGVu dGlmaWNhdGlvbi4NCiAgICAgSSBhbSBub3QgbWVhbmluZyB0b3RhbGx5IHJlbW92aW5nIHRoZSBl bmNvZGluZyBpbiB0aGUgdHJhY2tlciBwcm90b2NvbC4gSG93ZXZlciBJIHN1Z2dlc3QgaW4gY3Vy cmVudCBzdGFnZSwgZW5jb2RpbmcgcGFydCBtYXkgYmUgcGxhY2VkIGluIHRoZSBhcHBlbmRpeCBw YXJ0LCBhcyBhIHN0ZXAgdG8gcmVhbGl6ZSB0aGUgY29uc2Vuc3VzIGluIGxhc3QgSUVURi4NCiAg ICBSZWdhcmRpbmcgdGhlIGVuY29kaW5nIHByb3Bvc2FsIHlvdSByYWlzZWQsIG15IGZlZWxpbmcg aXMgdGhhdCB3ZSBhdCBsZWFzdCBuZWVkIHRvIGFzayB0aGUgcGVvcGxlIHdpdGggY29uY2VybnMg aW4gbGFzdCBJRVRGIChTZWUgdGhlIG1pbnV0ZXMpIGZvciB0aGVpciBjb21tZW50cy4NCg0KQlIN Cll1bmZlaQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnpoYW5neXVu ZmVpDQoNCreivP7Iy6O6IFhpYWppbndlaTxtYWlsdG86eGlhamlud2VpQGh1YXdlaS5jb20+DQq3 osvNyrG85KO6IDIwMTItMDktMTAgMTY6MzYNCsrVvP7Iy6O6IHpoYW5neXVuZmVpPG1haWx0bzp6 aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb20+OyBwcHNwPG1haWx0bzpwcHNwQGlldGYub3JnPg0K 1vfM4qO6ILTwuLQ6IFtwcHNwXSBuZXh0IHN0ZXAgb2YgdHJhY2tlciBkb2N1bWVudA0KSGkgWXVu ZmVpLA0KDQpXb3csIHlvdXIgZmVlZGJhY2sgaXMgdmVyeSBwcm9tcHQhDQoNClllcywgdGhlIFBl ZXIgSVAgaW5mb3JtYXRpb24gY2FuIGJlIHVzZWQgaW4gYSBsaW1pdGVkIHNjZW5hcmlvLCBmb3Ig ZXhhbXBsZSwgYWxsIHRoZSBwZWVycyBhcmUgaW4gYSBlbnRlcnByaXNlIG5ldHdvcmsgYW5kIGFy ZSBiZWhpbmQgdGhlIGVudGVycHJpc2UgTkFULCB0aGV5IGNhbiB0cmFuc21pdCB0aGUgZW50ZXJw cmlzZSBmaWxlcyBhbW9uZyB0aGUgZW50ZXJwcmlzZSBuZXR3b3JrIHZpYSB0aGVpciBsb2NhbCBJ UCBhZGRyZXNzZXMuIEJ1dCB0aGUgUGVlciBJRCBpcyBtYW5kYXRvcnkgYW5kIGNhbqGvdCBiZSBy ZXBsYWNlZCBieSBQZWVyIElQIGluZm9ybWF0aW9uIElNSE8uDQoNCkRvIHlvdSBtZWFuIHRoZSBj b25jbHVzaW9uIGlzIHJlbW92aW5nIGVuY29kaW5nIHR5cGUgcmVsYXRlZCB0ZXh0IGZyb20gdGhp cyBkb2N1bWVudD8gaWYgeWVzLCB3aWxsIHRoZSB0ZXh0IGJlIG1vdmVkIGludG8gYW5vdGhlciBk b2N1bWVudCwgZS5nLiwgdHJhY2tlciBleHRlbnNpb24gZHJhZnQ/DQoNClRoYW5rIHlvdSENCg0K DQpKaW53ZWkNCg0Kt6K8/sjLOiB6aGFuZ3l1bmZlaSBbbWFpbHRvOnpoYW5neXVuZmVpQGNoaW5h bW9iaWxlLmNvbV0NCreiy83KsbzkOiAyMDEyxOo51MIxMMjVIDE2OjE2DQrK1bz+yMs6IFhpYWpp bndlaTsgcHBzcA0K1vfM4jogUmU6IFtwcHNwXSBuZXh0IHN0ZXAgb2YgdHJhY2tlciBkb2N1bWVu dA0KDQpIaSBKaW53ZWksDQogICAgRm9yIHBvaW50MSwgd2hlbiB5b3UgbWVudGlvbiBwZWVyIElQ IGFkZHJlc3MgaXMgb3B0aW9uYWwgdG8gaWRlbnRpZnkgdGhlIHBlZXIuIERvIHlvdSBtZWFuIGl0 J3MgKmZlYXNpYmxlKiBvciBhICpzdWl0YWJsZSBjYW5kaWRhdGUqPyBJZiBpdCB3ZXJlIHRoZSBj YXNlLCBJIGFncmVlIHdpdGggeW91IGF0IHRoaXMgcG9pbnQuDQogICBGb3IgIHBvaW50MiwgdGhl IGNvbnNlbnN1cyBpbiBsYXN0IElFVEYgb24gdGhpcyBkcmFmdCBzaG91bGQgYmUgImNvbmNlbnRy YXRpbmcgb24gdGhlIG1lc3NhZ2UqIGlmIEkgZG9uJ3QgcmVtZW1iZXIgd3JvbmcuIFJlZ2FyZGlu ZyB0aGUgZW5jb2RpbmcgcGFydCwgeW91IGNhbiBhc2sgV2VzIGFuZCBGYWJpbyBmb3IgbW9yZSBj b21tZW50cy4NCg0KVGhhbmtzLg0KQlINCll1bmZlaQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnpoYW5neXVuZmVpDQoNCkZyb206IFhpYWppbndlaTxtYWlsdG86eGlhamlud2Vp QGh1YXdlaS5jb20+DQpEYXRlOiAyMDEyLTA5LTEwIDE1OjUxDQpUbzogcHBzcEBpZXRmLm9yZzxt YWlsdG86cHBzcEBpZXRmLm9yZz4NClN1YmplY3Q6IFtwcHNwXSBuZXh0IHN0ZXAgb2YgdHJhY2tl ciBkb2N1bWVudA0KSGkgYWxsLA0KDQpJIG5vdGljZSB0aGVyZSBhcmUgdHdvIGNvbmNlcm5zIGlu IHRyYWNrZXIgZG9jdW1lbnQgZnJvbSBJRVRGIDg0IG1lZXRpbmcgbWludXRlcywgaW4gb3JkZXIg dG8gYWNjZWxlcmF0ZSB0aGUgcHJvY2Vzc2luZyBvZiB0aGlzIGRvY3VtZW50LCBJoa9kIGxpa2Ug dG8gc2hvdyBteSB1bmRlcnN0YW5kaW5nIGZpcnN0bHkuIEhvcGUgd2UgY2FuIHB1c2ggdGhpcyB3 b3JrIGZvcndhcmQgYW5kIGdldCBjb25zZW5zdXMgYXMgc29vbiBhcyBwb3NzaWJsZS4NCg0KMSwg UGVlciBJRCBpcyBnbG9iYWwgdW5pcXVlIHRvIGlkZW50aWZ5IHRoZSBQZWVyLCBmcm9tIHRoaXMg cG9pbnQgb2YgdmlldywgdGhlIFBlZXIgSVAgYWRkcmVzcyBpcyBvcHRpb25hbCB0byBpZGVudGlm eSB0aGUgUGVlci4gSU1PIGl0IGNvdWxkIGJlIHVzZWZ1bCBpbiBhIGNsb3NlZCBzd2FybSBzY2Vu YXJpbywgaW4gd2hpY2ggdGhlIHBlZXJzIChib3RoIGxlZWNoIGFuZCBzZWVkKSBhcmUgYmVoaW5k IHRoZSBOQVQgYW5kIHRoZXkgY2FuIHNoYXJlIHRoZSBtZWRpYSBjb250ZW50IGluIHRoZSBsb2Nh bCBkb21haW4gKGUuZy4sIGVudGVycHJpc2UgaW5zaWRlKS4gSWYgSSBhbSByaWdodCwgSSBzdWdn ZXN0IHNvbWUgdGV4dCBzaG91bGQgYmUgZ2l2ZW4gdG8gZGVzY3JpYmUgdGhpcyBzY2VuYXJpby4N Cg0KMiwgRW5jb2RpbmcgeG1sIG9yIGJpbmFyeSBleHBlcmllbmNlcyBhIGxvbmcgZGlzY3Vzc2lv biwgZGlmZmVyZW50IHBlcnNvbiBoYXZlIGRpZmZlcmVudCBwcmVmZXJlbmNlLiBPbmUgY29tcHJv bWlzZSBpcyBlbmNvZGluZyBhbmQgZGVjb2RpbmcgWE1MIGluIGJpbmFyeSwgdGhlIHJlbGF0ZWQg Y29udGV4dCBpcyBzcGVjaWZpZWQgaW4gVzNDIEVmZmljaWVudCBYTUwgSW50ZXJjaGFuZ2UgV29y a2luZyBHcm91cCBvciBpbiBJU08vSUVDIDIzMDAxLVBhcnQgMSChsUJpbmFyeSBNUEVHIGZvcm1h dCBmb3IgWE1MobEuIFRoZXJlZm9yZSwgZW5jb2RpbmcgYm90aCBYTUwgYW5kIEhUVFAgaW4gYmlu YXJ5IGZvcm1hdCBhcmUgaW1wbGVtZW50YXRpb24gb3B0aW9ucy4gVGhlIGRyYWZ0IGNhbiBoYXZl IGEgY291cGxlIG9mIHBhcmFncmFwaHMgcHJvdmlkaW5nIHRob3NlIG9wdGlvbnMgaW4gdGVybXMg b2YgaW1wbGVtZW50YXRpb24gbm90ZXMuDQoNCkFueSBjb21tZW50cz8NCg0KVGhhbmsgeW91IQ0K DQoNCkppbndlaQ0K --_000_B0D29E0424F2DE47A0B36779EC66677924AE6F94szxeml504mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

For poi= nt two, I agree that we can move the encoding part of tracker protocol to a= ppendix, as both XML and binary are at least feasible.

But I w= ould *strongly* want to hear the comments from the people raising th= is issue in last PPSP session about encoding =A8C for example, efficiency c= oncerns?

Thanks.=

&n= bsp;

-Ning

&n= bsp;

From: ppsp-bounces= @ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of zhangyunfei
Sent: Monday, September 10, 2012 6:13 PM
To: Xiajinwei; ppsp
Subject: [ppsp] =BB=D8=B8=B4: =B4=F0=B8= =B4: next step of tracker document

 

Hi Jinwei (S= peaking individually),

  =    My suggestion is to consider peer IP(private, public)+port= (private, public) for the purpose of identifying the peer. Is it enough? Or= we may need more information for the identification.

  =    I am not meaning totally removing the encoding in the tra= cker protocol. However I suggest in current stage, encoding part may b= e placed in the appendix part, as a step to realize the consensus in last IETF.

  =   Regarding the encoding proposal you raised, my feeling is that we at= least need to ask the people with concerns in last IETF (See the minutes) for their comments.

 <= /o:p>

BR

Yunfei<= /o:p>

  =   

 <= /o:p>

 <= /o:p>

zhangyunfei<= o:p>

 <= /o:p>

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

=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-09-10&nbs= p;16:36

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

=D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] next step of tracker document

Hi Yunf= ei,

&n= bsp;

Wow, yo= ur feedback is very prompt!  

&n= bsp;

Yes, th= e Peer IP information can be used in a limited scenario, for example, all t= he peers are in a enterprise network and are behind the enterprise NAT, the= y can transmit the enterprise files among the enterprise network via their local IP addresses. But the Peer ID is ma= ndatory and can=A1=AFt be replaced by Peer IP information IMHO.<= /span>

&n= bsp;

Do you = mean the conclusion is removing encoding type related text from this docume= nt? if yes, will the text be moved into another document, e.g., tracker ext= ension draft?

&n= bsp;

Thank y= ou!

&n= bsp;

&n= bsp;

Jinwei<= o:p>

&n= bsp;

=B7=A2=BC=FE=C8=CB: zhangyunfei [mailto:zhangyunfei@chinamobile= .com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2012=C4=EA9=D4=C210=C8=D5 16:16
=CA=D5=BC=FE=C8=CB: Xiajinwei; ppsp
=D6=F7=CC=E2: Re: [ppsp] next step of tracker document

 

Hi Jinwei,

    For point1, when you m= ention peer IP address is optional to identify the peer. Do you mean it's *= feasible* or a *suitable candidate*? If it were the case, I agree with you at this point.

   For  point2, the consensus i= n last IETF on this draft should be "concentrating on the message* if = I don't remember wrong. Regarding the encoding part, you can ask Wes and Fabio for more comments.

 

Thanks.

BR

Yunfei 

zhangyunfei

 

From: Xiajinwei

Date: 2012-= 09-10 15:51

Subject:=  [p= psp] next step of tracker document

Hi all,

&nbs= p;

I notice = there are two concerns in tracker document from IETF 84 meeting minutes, in= order to accelerate the processing of this document, I=A1=AFd like to show= my understanding firstly. Hope we can push this work forward and get consensus as soon as possible.=

&nbs= p;

1, Peer I= D is global unique to identify the Peer, from this point of view, the Peer = IP address is optional to identify the Peer. IMO it could be useful in a cl= osed swarm scenario, in which the peers (both leech and seed) are behind the NAT and they can share the media cont= ent in the local domain (e.g., enterprise inside). If I am right, I suggest= some text should be given to describe this scenario.

&nbs= p;

2, Encodi= ng xml or binary experiences a long discussion, different person have diffe= rent preference. One compromise is encoding and decoding XML in binary, the= related context is specified in W3C Efficient XML Interchange Working Group or in ISO/IEC 23001-Part 1 =A1=B1Binary= MPEG format for XML=A1=B1. Therefore, encoding both XML and HTTP in binary= format are implementation options. The draft can have a couple of paragrap= hs providing those options in terms of implementation notes.

&nbs= p;

Any comme= nts?

&nbs= p;

Thank you= !

&nbs= p;

&nbs= p;

Jinwei

--_000_B0D29E0424F2DE47A0B36779EC66677924AE6F94szxeml504mbschi_-- From internet-drafts@ietf.org Wed Sep 19 20:39:23 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42921E8048; Wed, 19 Sep 2012 20:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDU3bnwAhLl8; Wed, 19 Sep 2012 20:39:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDF321F8523; Wed, 19 Sep 2012 20:39:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120920033922.32315.85373.idtracker@ietfa.amsl.com> Date: Wed, 19 Sep 2012 20:39:22 -0700 X-Mailman-Approved-At: Wed, 19 Sep 2012 20:43:19 -0700 Cc: ppsp@ietf.org Subject: [ppsp] I-D Action: draft-ietf-ppsp-problem-statement-10.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 03:39:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer to Peer Streaming Protocol Working G= roup of the IETF. Title : Problem Statement and Requirements of Peer-to-Peer Strea= ming Protocol (PPSP) Author(s) : Yunfei Zhang Filename : draft-ietf-ppsp-problem-statement-10.txt Pages : 25 Date : 2012-09-19 Abstract: Peer-to-Peer (P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes a Peer to Peer Streaming Protocol (PPSP) including tracker and peer signaling components, and discusses the scope, requirements and uses cases of PPSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ppsp-problem-statement-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-problem-statement-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangyunfei@chinamobile.com Wed Sep 19 20:53:43 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EB811E808D for ; Wed, 19 Sep 2012 20:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.649 X-Spam-Level: X-Spam-Status: No, score=-96.649 tagged_above=-999 required=5 tests=[AWL=1.974, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfgcJ8OFy6K4 for ; Wed, 19 Sep 2012 20:53:41 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 31CA921F8470 for ; Wed, 19 Sep 2012 20:53:41 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id D9C58E404; Thu, 20 Sep 2012 11:53:38 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id CD77BE3E5; Thu, 20 Sep 2012 11:53:38 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092011533672-9610 ; Thu, 20 Sep 2012 11:53:36 +0800 Date: Thu, 20 Sep 2012 11:53:25 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012092011532517174120@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-20 11:53:36, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-20 11:53:37 Content-Type: multipart/related; boundary="----=_001_NextPart621431642105_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19194.004 X-TM-AS-Result: No--13.523-7.0-31-10 X-imss-scan-details: No--13.523-7.0-31-10;No--13.523-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Fw: I-D Action: draft-ietf-ppsp-problem-statement-10.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 03:53:43 -0000 ------=_001_NextPart621431642105_=---- Content-Type: multipart/alternative; boundary="----=_002_NextPart450433011852_=----" ------=_002_NextPart450433011852_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgYWxsLA0KICAgQWZ0ZXIgdGhlIDJuZCByb3VuZCBvZiBXR0xDIHdpdGggdGhlIGNvbnNpZGVy YXRpb25zIG9mIHRoZSB2YWx1YWJsZSBjb21tZW50cyBmcm9tIFJ1aSBhbmQgUmljaCwgd2UgaGF2 ZSB1cGRhdGVkIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgcmVxdWlyZW1lbnRzIGRyYWZ0LiBU aGUgbWFpbiBjaGFuZ2VzIGluY2x1ZGU6DQoxKSBBZGRpbmcgb25lIHVzZSBjYXNlIG9mIFByb3h5 IHNlcnZpY2Ugc3VwcG9ydGluZyBQMlAgc3RyZWFtaW5nIHN1Z2dlc3RlZCBieSBSdWkgYW5kIFJp Y2guIFRoYW5rcw0KMikgUmVzdHJ1Y3R1cmUgdGhlIHNlY3VyaXR5IHNlY3Rpb24gYnkgYWRkaW5n IHRoZSBzZWN1cml0eSByZXF1aXJlbWVudHMgcGFydCBzcGxpdCBmcm9tIHRoZSByZXF1aXJlbWVu dCBzZWN0aW9uKHNlY3Rpb24gNikuDQozKSBBIGxvdCBvZiBlZGl0b3JpYWwgIHVwZGF0ZS4gTWFu eSB0aGFua3MgdG8gU3RlZmFubyBmb3IgaGlzIGNhcmVmdWwgcmV2aWV3Lg0KICAgSWYgdGhlcmUg YXJlIG5vIG1vcmUgY29tbWVudHMgb24gdGhpcyBkcmFmdCwgd2Ugd291bGQgbGlrZSB0byByZXF1 ZXN0IGZvciB0aGUgMm5kIHJvdW5kIG9mIElFU0cgcmV2aWV3IGZvciB0aGlzIHZlcnNpb24uIFRo YW5rcy4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHMNCkRhdGU6IDIwMTItMDktMjAgMTE6MzkNClRvOiBpLWQtYW5ub3VuY2UNCkNDOiBw cHNwDQpTdWJqZWN0OiBbcHBzcF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0t c3RhdGVtZW50LTEwLnR4dA0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgUGVlciB0byBQZWVyIFN0cmVhbWluZyBQcm90b2NvbCBXb3Jr aW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KDQpUaXRsZSAgICAgICAgICAgOiBQcm9ibGVtIFN0YXRl bWVudCBhbmQgUmVxdWlyZW1lbnRzIG9mIFBlZXItdG8tUGVlciBTdHJlYW1pbmcgUHJvdG9jb2wg KFBQU1ApDQpBdXRob3IocykgICAgICAgOiBZdW5mZWkgWmhhbmcNCkZpbGVuYW1lICAgICAgICA6 IGRyYWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0xMC50eHQNClBhZ2VzICAgICAgICAg ICA6IDI1DQpEYXRlICAgICAgICAgICAgOiAyMDEyLTA5LTE5DQoNCkFic3RyYWN0Og0KICAgUGVl ci10by1QZWVyIChQMlAgZm9yIHNob3J0KSBzdHJlYW1pbmcgc3lzdGVtcyBzaG93IG1vcmUgYW5k IG1vcmUNCiAgIHBvcHVsYXJpdHkgaW4gY3VycmVudCBJbnRlcm5ldCB3aXRoIHByb3ByaWV0YXJ5 IHByb3RvY29scy4gVGhpcw0KICAgZG9jdW1lbnQgaWRlbnRpZmllcyBwcm9ibGVtcyBvZiB0aGUg cHJvcHJpZXRhcnkgcHJvdG9jb2xzLCBwcm9wb3NlcyBhDQogICBQZWVyIHRvIFBlZXIgU3RyZWFt aW5nIFByb3RvY29sIChQUFNQKSBpbmNsdWRpbmcgdHJhY2tlciBhbmQgcGVlcg0KICAgc2lnbmFs aW5nIGNvbXBvbmVudHMsIGFuZCBkaXNjdXNzZXMgdGhlIHNjb3BlLCByZXF1aXJlbWVudHMgYW5k IHVzZXMNCiAgIGNhc2VzIG9mIFBQU1AuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQNCg0KVGhlcmUncyBhbHNvIGEgaHRt bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMTANCg0KQSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTEwDQoNCg0KSW50ZXJu ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8v ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_002_NextPart450433011852_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi all,
   After the 2nd round of WGLC with the considerations of t= he=20 valuable comments from Rui and Rich, we have updated the problem statement= and=20 requirements draft. The main changes include:
1) Adding one use case of=20 Proxy service supporting P2P streaming suggested by Ru= i and=20 Rich. Thanks
2) Restructure the security section by adding the security requiremen= ts=20 part split from the requirement section(section 6).
3) A lot of editorial  update. Many thanks to Stefano for h= is=20 careful review.
   If there are no more comments on this draft, we wou= ld=20 like to request for the 2nd round of IESG review for this version. Thanks.=
 
BR
Yunfei
 
zhangyunfei
 
From: internet-drafts
Date: 2012-09-20 11:39
To: i-d-announce
CC: ppsp
Subject: [ppsp] I-D Action:=20 draft-ietf-ppsp-problem-statement-10.txt
 
A New Internet-Draft is available from = the on-line Internet-Drafts directories.
 This draft is a work item of = ;the Peer to Peer Streaming Protocol Working=  Group of the IETF.
 
Title          &nbs= p;: Problem Statement and Requirements of Pe= er-to-Peer Streaming Protocol (PPSP)
Author(s)       : Yunfei = ;Zhang
Filename        : draft-= ietf-ppsp-problem-statement-10.txt
Pages          &nbs= p;: 25
Date           = ; : 2012-09-19
 
Abstract:
   Peer-to-Peer (P2P for short) st= reaming systems show more and more
   popularity in current Internet = with proprietary protocols. This
   document identifies problems of = ;the proprietary protocols, proposes a
   Peer to Peer Streaming Protocol=  (PPSP) including tracker and peer
   signaling components, and discusses&= nbsp;the scope, requirements and uses
   cases of PPSP.
 
 
The IETF datatracker status page for th= is draft is:
https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement
 
There's also a htmlized version available&nb= sp;at:
http://tools.ietf.org/html/draft-ietf-ppsp-problem-statement-10
 
A diff from the previous version is&nbs= p;available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-problem-statement-= 10
 
 
Internet-Drafts are also available by anonym= ous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_002_NextPart450433011852_=------ ------=_001_NextPart621431642105_=---- Content-Type: image/gif; name="14.gif" Content-ID: <_Foxmail.0@19281121-5AF0-498A-98AF-7AFDC309836F> Content-Transfer-Encoding: base64 R0lGODlhFAAUAPfkAOrq6rCQZeq6KMi7qPfv1vDw8OWgCsCGIPnaX9jW1ZRKEJ1bGPfdiO/PTv77 TLqlgkIpCEIhCMyZM/PdQP7HQf3NFdeoKf75T+feQv/wUv/hRcatKf/oH8yzTf/tJf//5//GP//n IP/7PsaUGL2EEOfGGJlmM//bR9alEP7mUqVjEP/RQuLQpv/9SP/7Sf/xLP/VRP/65f/7Of79Qf/8 Rv/9Qr2tQqWUe5yESv/lM3tjGM6lGPzMFf3rUu/GMf/9TPzLG//PPszMzPz4P/++CK1rGP35Sf3j bfz5Q//cP//HJ/roMf79Rey/J//vLv/hSu/OKfz2RoRjGOfGId7OrfzzTP/tT/PVNvrvSf/kSf/f QYx7GP/qTP/MM//+Rf/zKs6lIfntRK1rEP/rMf/pKPvvNP/GQf/uJfXdN0opCMa1IWNCEK2UIfbk Rf/8PefeOd61Id6tIebMMLWcIfjfLf/jTv/ERP/eRf3rJf/IQ//xTf/0Uv+7Cf6/C//4MP7ACf/l O/nvPv/XO/73Nf7zUv3wLPzsLZxaEMzMmcyZZv/jIvf39/778//XRPjrO/30MuiwM/7xKvzzOP/j Tf+/B/z2PP/INP/NQNbOKf/yLP76T++zE//rUf/TRP/3Tf/2T//7R//0UP/GRP73MfzwTv/dScaM If/5Tc69KfPPMv/rJvfnOPnRJP/kKv/cRvfVLfnwQv/1M96tKf/VQ5R7MffvMa2ca4RrQrWlOf31 Mf37Rf/0Qf/0Sv33Nv/mSP/0NP/qRf/5Sv37Qv36Pv/3N//uSq2UQqWMOf/6RP/wSP76Pf/2Rf/4 P//xRv/xRLWlUv/1R86tQoxrKf75OdbGrf/zPv/oRpyMWqWMWs69QtbGpf//MbWcUv/3Mf//OaWM a72thL2tSv/vQP/7Q////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05FVFNDQVBFMi4wAwEA AAAh+QQFyADkACwAAAAAFAAUAAAI/wDJCRzIgMERBAiOMBjIkKHBDHtChcrAKcWThQ0FHiFE6sIF TRc+hbJSp1GDjAx+aNLkwMEPB6c86eHypFMHhz2wGDmGg1YLFy7CSTM2qdSKmwLrtImCwdYHbdlo YMD2AVw0VyskCGTQJgwSG1Q+EHhWA6xYbncuQTpGjoEmLENsXLtx45YIXN9uUMOhAQYIthsDVXqz JkIEHTIwpDEsRcMsOybIIcjgSNK2ORAgoBrkbUsECBu0PC7SlsuqMo+6qcHkZ1SsWmw2AEqyQlRk Bly4LDFU6EWkL5leOBmTw4cgtbQEouFCpwgYPB7OeFBFphUUBbJEmQogsIGGV1MU7GQIwYFDCEVw FJiyREEFQyha7rg6pGJEiREqFMRR0uXAN4Y++EDHLDygQIIYJKBQQQVKHBBZQ3HEAcQrffxBCRF8 VGDAAcllRI4EEhhgAB98QCLiAiR4yNAB2HBYBDbYqCjjjAEBACH5BAUKAOQALAIAAQARABAAAAiV AMkJzLBHEzk9VsjVWSGwYcNPn/Y4nOjwE8WGGk405CIQVIsWDYPxKpbFoUFdTJh48UKOBihoyXxV JCdshs0a5MYhW9bMmsM9SIYpE+HGDTkRzHY5AybQDjlCDafJcFhNnMBGechlINdrIjGKomglJJdr 4q+JTi+qpaC2rduJIN42tBRXbkMSarsECWLJkpJNRXA0DAgAIfkEBcgA5AAsAgACABEADwAACI0A yQkkdeGCwIMIEWpKiPAJwh4X9hzDQetgOGnGyDWygxCDrQ/aspHDgO0DuGiNuiC0QeUDgWfkWLrk JiihjWs3btwih+vbDWo4BIJIGCECwqICZ3EUuC2hN4Z2ihzslrBWQlECuTDcCkmgr61gyX0NS85H QlYlwCoBO4uhJYEVGfb5Q4kInwoGDpg4GBAAIfkEBQoA5AAsAQACABAAEAAACIMAyQkk9+lTKEJ6 rFjh4mugw4cONUAE1aLFwGC8ipErtULgnj1MmHjxQo4GKGjJfLnqKFDYjJc1yI1DtqyZtTsOhykT 4cYNORHMdjkDBpHcNBkOq4mD2OshMYgarZDL9fCXwzxFs2otamerQ0sO77jS2gUij6wHTEAMApEE La8DDwgMCAA7 ------=_001_NextPart621431642105_=------ From Martin.Stiemerling@neclab.eu Fri Sep 21 06:52:12 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CACF21F875C for ; Fri, 21 Sep 2012 06:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.959 X-Spam-Level: X-Spam-Status: No, score=-101.959 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLwPwnlV7+YO for ; Fri, 21 Sep 2012 06:52:11 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id BF88921F8768 for ; Fri, 21 Sep 2012 06:52:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C1251101EE1 for ; Fri, 21 Sep 2012 15:52:09 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6diVDU0HJCSM for ; Fri, 21 Sep 2012 15:52:09 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 9EEF7101EDF for ; Fri, 21 Sep 2012 15:52:04 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 15:51:49 +0200 Message-ID: <505C70EF.6040000@neclab.eu> Date: Fri, 21 Sep 2012 15:51:43 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:52:12 -0000 Dear all, I have seen the update of the draft draft-ietf-ppsp-problem-statement-10.txt. I did a first round of my review that you can find below. It is up to Section 6.3, but not including this section. There are a number of editorials, but also some more technical questions. I guess we need to discuss some of them here on the list. The first half of the review: INTRODUCTION, paragraph 4: > Peer-to-Peer (P2P for short) streaming systems show more and more > popularity in current Internet with proprietary protocols. This > document identifies problems of the proprietary protocols, proposes a > Peer to Peer Streaming Protocol (PPSP) including tracker and peer > signaling components, and discusses the scope, requirements and uses > cases of PPSP. s/and uses cases/and use cases/ Status of this Memo Section 1., paragraph 1: > Streaming traffic is among the largest and fastest growing traffic on > the Internet [Cisco], where peer-to-peer (P2P) streaming contribute > substantially. With the advantage of high scalability and fault s/streaming contribute/streaming contributes/ Section 1., paragraph 2: > tolerance against single point of failure, P2P streaming applications > are able to distribute large-scale, live and video on demand (VoD) > streaming programs to millions of audience with only a handful of "millions of audience" doesn't sound right. How about "to a large audience"? Section 1., paragraph 3: > servers. What's more, along with the new players like CDN providers CDN providers are not really new players in the content distribution market anymore. They are in the market much longer than p2p... Section 1., paragraph 5: > Given the increasing integration of P2P streaming into the global > content delivery infrastructure, the lack of an open, standard P2P > streaming signaling protocol suite becomes a major missing component > in the protocol stack. Almost all of existing systems use their just delete "in the protocol stack", as it does not add to the sentence, but it add confusion. Section 1., paragraph 7: > In this document we propose an open P2P Streaming Protocol, which is > defined as PPSP, to standardize signaling operations in P2P streaming s/defined as PPSP/abbreviated as PPSP/. Section 2., paragraph 7: > Peer: A peer refers to a participant in a P2P streaming system that > not only receives streaming content, but also stores and streams > streaming content to other participants. A peer does not need to store content. Section 2., paragraph 11: > Tracker: A tracker refers to a directory server that maintains a list Wouldn't it be better to say 'directory service' instead of 'directory server'? Below you say that the tracker is a logical entity that can be centralized (indeed a server ) or distributed (not a server). Service would match better here. Section 2., paragraph 13: > Video-on-demand (VoD): It refers to a scenario where different > clients may watch different parts of the same recorded media with > downloaded content. You use sometimes media and sometimes content. Choose one and stick to it throughout the whole draft. Section 3.1., paragraph 1: > ISPs are faced to different P2P streaming application introducing s/are faced to/are faced with/ Section 3.1., paragraph 3: > However, unlike Web traffic that is represented by HTTP packets and s/HTTP packets/HTTP requests/repsonses/ 'HTTP packets' isn't the right term. Section 3.2., paragraph 2: > In the Hybrid CDN/P2P approach, the CDN takes two roles: media > streaming server and P2P tracker. Similarly to what described in s/to what described /to what is described/ Section 3.2., paragraph 3: > section 3.1, proprietary P2P protocols introduce complexity between > peers and CDN trackers because the CDN trackers need to identify each > different P2P streaming protocol. This increases the deployment cost > of CDN. I do not understand the issue here. First of all, all the different p2p streaming systems could use a common tracker protocol. Second, how does the above text relate to latency issues? Third, even if there are multiple, different tracker protocols what is this related to in this section? Section 3.3., paragraph 3: > However it's difficult to apply current P2P streaming protocols (even > assuming we can re-use some of the proprietary ones) in mobile and > wireless networks. Although smart handsets are more eligible to > become peers with much higher bandwidth, CPU frequency, larger > storage and memory than before, peer selection will become more > challenging due to the increase and complexity of exchange between > peers and trackers. Current P2P protocols are not well suited for > these new requirements in the context of mobile and wireless > networks. I do know what you are targetting at, but I cannot understand it from the above text. The interactions between mobile terminals and trackers are not different to fixed terminals and trackers. The issue is more that p2p assumes a stable Internet connection in downlink and uplink direction, with decent capacity and peers that can run for hours. This isn't the typical setting for mobile terminals. Your examples should some of the challenges but the text above is confusing at best. Section 3.3., paragraph 5: > Second, current practices often use a "bitmap" message in order to > exchange chunk availability. The message is of kilobytes in size and > exchanged frequently, for example, several seconds. In a mobile 'several seconds' isn't correct here. You probably mean 'several times in a second'. Section 4., paragraph 0: > Third, for a resource constraint peer like mobile handsets or set-top > boxes (STB), there are severe contentions on limited resource when > using proprietary protocols. The peer has to install many different > streaming applications for different usages, e.g., some for movies > and others for sports and each of these applications will compete for > the same set of memories, flashes or hard disks(some may run in the > background even they are not invoked by the users). Open protocols creat > an opportunity to use one client software accommodating different P2P systems. > This may alleviate this problem. What 'may alleviate this problem'? 4. PPSP: Standard peer to peer streaming protocols Section 4., paragraph 1: > PPSP is targeted to standardize signaling protocols for tracker-based > architectures to solve the above problems that support either live or > VoD streaming. I do not think that the above statement is compeletly right, as the peer protocol, as I know it, can operate with tracker based systems, but also without a tracker. Section 4.1., paragraph 0: 4.1. Tracker protocol candidates discussion and design issues Why is there the need to discuss the candidates in this draft? Wouldn't it be better to roughly sketch the task of the tracker protocol? I.e., to give a reasoning why it is required? Section 4.1., paragraph 1: > Tracker protocol: The tracker protocol is best modeled as a > request/response protocol between peers and trackers, and will carry Remove the first part of the sentence, i.e., 'Tracker protocol:'. > information needed for the selection of peers suitable for real- > time/VoD streaming. Section 4.1., paragraph 5: > PPSP tracker protocol will select the best of the above options This sentence is not correct, as the tracker will not select any option, but the WG will select something, isn't it? Section 4.2., paragraph 0: 4.2. Peer protocol candidates discussion and design issues Why is there the need to discuss the candidates in this draft? Wouldn't it be better to roughly sketch the task of the peer protocol? I.e., to give a reasoning why it is required? Section 4.2., paragraph 1: > Peer Protocol: The peer protocol is modeled as a gossip-like protocol > with periodic exchanges of neighbor and media chunk availability > information. Namely, the peer protocol is a content-centric protocol > built around the abstraction of a cloud of participants disseminating > the same data in ways and orders that are convenient to the > participants [I-D.ietf-ppsp-peer-protocol]. In that respect and in > light of the above requirements, typical HTTP is neither suitable nor > efficient. what does this paragraph add to the discussion? Section 4.2., paragraph 5: > The PPSP peer protocol will discuss the protocol design rationales in > detail. This section does not help in terms of problem statement nor for the requirements listed later on. It would be much better to explain briefly what the peer protocol is expected to do and how the earlier mentioned problems are addressed by a standardized peer protocol. Section 5.1., paragraph 1: > The content provider can efficiently increase live streaming coverage > by introducing PPSP in between different providers. 'in' or 'between' or 'in-between'? Section 5.1., paragraph 2: > Figure 2 shows the case of provider A broadcasting a TV program with > the help of provider B and C for a wider coverage by introducing PPSP. > Without PPSP, when users outside A requests TV program@A, the > returned peer-list may include few local peers. This may affect the > user experience. With PPSP, B and C can involve in the broadcasting. Honestly, I do not understand the case you are describing. Neither the text nor the figure help me in explaining what it is about. Section 5.1., paragraph 3: > The providers often deploy in-network peers called super-nodes (SN 'Super-node' is not mentioned in the terminology. Section 5.1., paragraph 5: > Figure 3 shows the case of cooperative VoD provision by introducing > PPSP inside CDN overlays and in between different CDNs. It is similar > to Figure 2 except that the intermediate SNs are replaced by 3rd > party CDN surrogates. The CDN nodes talk with the different streaming > systems with the same PPSP protocols. Note that for compatibility > reason both HTTP streaming and P2P streaming can be supported by CDN. I would suggest to move the hybrid cdn/p2p case in a new section and not to be part of section 5.1 Section 5.3., paragraph 1: > In Figure 5, when peers request the P2P streaming data, the cache > nodes intercept the requests and ask for the frequently visited > content (or part of) on behalf of the peers. To do this, it asks the > tracker for the peer-list and the tracker replies with external peers > in the peer-list. After the cache nodes exchange data with these > peers, it can also act as a peer and report what it caches to the > tracker and serve requesting peers inside afterward. This operation > greatly decreases the inter-network traffic and increases user I would add 'can greatly decrease', as in some situations it wouldn't. E.g., when each peer is asking for a different content. Section 6., paragraph 1: > This section enumerates the requirements that should be considered > when designing PPSP. The requirements use normative language according RFC 2119. However, RFC 2119 is never mentioned in the draft at all. Section 6.1., paragraph 0: 6.1. Basic Requirements Many of the requirements listed here are not basic requirements but already very specific requirements that belong in other sections. E.g., the peer ID belongs IMHO into the peer section. Section 6.1., paragraph 1: > PPSP.REQ-1: The tracker and the peer protocol SHOULD allow peers to > receive streaming content within the required time constraints. This not a protocol requirement, as it is not specifying something we can qualify later on. Section 6.1., paragraph 7: > A key characteristic of P2P streaming system is allowing the data > fetching from different peers concurrently. Therefore, the whole > streaming content must allow to be partitioned into small pieces or > chunks for transmission between peers. This seems to be more a prerequisite instead of a protocol requirement. Section 6.1., paragraph 10: > PPSP.REQ-6: The tracker protocol and peer protocol are recommended to > be carried over TCP or UDP. No 'MUST' or 'SHOULD' like the other requirements? Why is there only a single requirements for both protocols, i.e., for the peer protocol and the tracker protocol? Shouldn't this at least be 2 separated requirements? Section 6.1., paragraph 11: > PPSP.REQ-7: The tracker and peer protocol together MUST facilitate > acceptable QoS (e.g. low startup delay, low channel/content switching > time and minimal end-to-end delay) for both live and VoD streaming > even for very popular content. The tracker and peer protocol do not > include the algorithm required for scalable streaming. However, the > tracker and peer protocol SHALL NOT restrict or place limits on any > such algorithm. This requirement is at least listing 2 requirements. Something about QoS and the limits of the algorithm. QoS is again hard to qualify and if you want to say something about this, I would suggest to not make a requirement, but to add explanatory text about this, like you have below this. Section 6.2., paragraph 3: > PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for > sending queries and periodical peer status reports/updates to the > tracker and receiving the corresponding replies. How about instead of 'The peer' 'A PPSP peer'? This seems to be not a requirement for the tracker (i.e., wrong section), but a requirement for a peer. Section 6.2., paragraph 9: > PPSP.TP.REQ-7: The chunk availability information of the peer SHOULD > be reported to tracker when tracker needs such information to steer > peer selection. The chunk information MUST at least contain the > chunk ID. This requirement is misleading, as it does not exactly state what the requirement for the tracker protocol is. It could read that the tracker protocol should support the reporting of about chunk availability. Section 6.2., paragraph 10: > PPSP.TP.REQ-8: The chunk availability information between peer and > tracker MUST be expressed as compact as possible. What is as compact as possible? A 10th of the original size? This is not a good requirement. Section 6.2., paragraph 12: > PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the > tracker when tracker needs such information in order to steer peer > selection. This implies that the tracker protocol is not a pure request/response protocol from the peer's perspective, isn't it? -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From zhangyunfei@chinamobile.com Mon Sep 24 03:28:07 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4321F8487 for ; Mon, 24 Sep 2012 03:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.646 X-Spam-Level: X-Spam-Status: No, score=-95.646 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GprUsLHwj662 for ; Mon, 24 Sep 2012 03:28:05 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DE14B21F8464 for ; Mon, 24 Sep 2012 03:28:03 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3D933E512; Mon, 24 Sep 2012 18:28:03 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 1A400E40A; Mon, 24 Sep 2012 18:28:03 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092418275993-25620 ; Mon, 24 Sep 2012 18:27:59 +0800 Date: Mon, 24 Sep 2012 18:27:56 +0800 From: zhangyunfei To: "Martin Stiemerling" , ppsp References: <505C70EF.6040000@neclab.eu> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012092411122153407042@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-24 18:27:59, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-24 18:28:02 Content-Type: multipart/alternative; boundary="----=_001_NextPart605386236211_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19206.006 X-TM-AS-Result: No--37.502-7.0-31-10 X-imss-scan-details: No--37.502-7.0-31-10;No--37.502-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 10:28:07 -0000 ------=_001_NextPart605386236211_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgTWFydGluLA0KICAgIEZpcnN0IG9mIGFsbCwgdGhhbmtzIHNvIG11Y2ggZm9yIHlvdXIgdmFs dWFibGUgY29tbWVudHMsIHN1Z2dlc3Rpb25zIGFuZCBxdWVzdGlvbnMgb24gdGhlIGRyYWZ0LiBI ZXJlIGFyZSBzb21lIGluaXRpYWwgcmVzcG9uc2UuIEZ1cnRoZXIgY29tbWVudHMsIGVzcC4gZm9y IHNlY3Rpb24gNCBhcmUgaGlnaCBhcHByZWNpYXRlZC4gVGhhbmtzLg0KDQpCUg0KeXVuZmVpIA0K DQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBNYXJ0aW4gU3RpZW1lcmxpbmcNCkRhdGU6IDIw MTItMDktMjEgMjE6NTENClRvOiBwcHNwQGlldGYub3JnDQpTdWJqZWN0OiBbcHBzcF0gQW4gZWFy bHkgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0xMC50eHQN CkRlYXIgYWxsLA0KDQpJIGhhdmUgc2VlbiB0aGUgdXBkYXRlIG9mIHRoZSBkcmFmdCANCmRyYWZ0 LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0xMC50eHQuDQoNCkkgZGlkIGEgZmlyc3Qgcm91 bmQgb2YgbXkgcmV2aWV3IHRoYXQgeW91IGNhbiBmaW5kIGJlbG93LiBJdCBpcyB1cCB0byANClNl Y3Rpb24gNi4zLCBidXQgbm90IGluY2x1ZGluZyB0aGlzIHNlY3Rpb24uDQoNClRoZXJlIGFyZSBh IG51bWJlciBvZiBlZGl0b3JpYWxzLCBidXQgYWxzbyBzb21lIG1vcmUgdGVjaG5pY2FsIA0KcXVl c3Rpb25zLiBJIGd1ZXNzIHdlIG5lZWQgdG8gZGlzY3VzcyBzb21lIG9mIHRoZW0gaGVyZSBvbiB0 aGUgbGlzdC4NCg0KVGhlIGZpcnN0IGhhbGYgb2YgdGhlIHJldmlldzoNCg0KDQpJTlRST0RVQ1RJ T04sIHBhcmFncmFwaCA0Og0KDQogPiAgICBQZWVyLXRvLVBlZXIgKFAyUCBmb3Igc2hvcnQpIHN0 cmVhbWluZyBzeXN0ZW1zIHNob3cgbW9yZSBhbmQgbW9yZQ0KID4gICAgcG9wdWxhcml0eSBpbiBj dXJyZW50IEludGVybmV0IHdpdGggcHJvcHJpZXRhcnkgcHJvdG9jb2xzLiBUaGlzDQogPiAgICBk b2N1bWVudCBpZGVudGlmaWVzIHByb2JsZW1zIG9mIHRoZSBwcm9wcmlldGFyeSBwcm90b2NvbHMs IHByb3Bvc2VzIGENCiA+ICAgIFBlZXIgdG8gUGVlciBTdHJlYW1pbmcgUHJvdG9jb2wgKFBQU1Ap IGluY2x1ZGluZyB0cmFja2VyIGFuZCBwZWVyDQogPiAgICBzaWduYWxpbmcgY29tcG9uZW50cywg YW5kIGRpc2N1c3NlcyB0aGUgc2NvcGUsIHJlcXVpcmVtZW50cyBhbmQgdXNlcw0KID4gICAgY2Fz ZXMgb2YgUFBTUC4NCg0KICAgcy9hbmQgdXNlcyBjYXNlcy9hbmQgdXNlIGNhc2VzLw0KDQpbWXVu ZmVpXSBPa2F5Lg0KICBTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCg0KU2VjdGlvbiAxLiwgcGFyYWdy YXBoIDE6DQoNCiA+ICAgIFN0cmVhbWluZyB0cmFmZmljIGlzIGFtb25nIHRoZSBsYXJnZXN0IGFu ZCBmYXN0ZXN0IGdyb3dpbmcgdHJhZmZpYyBvbg0KID4gICAgdGhlIEludGVybmV0IFtDaXNjb10s IHdoZXJlIHBlZXItdG8tcGVlciAoUDJQKSBzdHJlYW1pbmcgY29udHJpYnV0ZQ0KID4gICAgc3Vi c3RhbnRpYWxseS4gV2l0aCB0aGUgYWR2YW50YWdlIG9mIGhpZ2ggc2NhbGFiaWxpdHkgYW5kIGZh dWx0DQoNCiAgIHMvc3RyZWFtaW5nIGNvbnRyaWJ1dGUvc3RyZWFtaW5nIGNvbnRyaWJ1dGVzLw0K DQpbWXVuZmVpXSBPa2F5Lg0KDQpTZWN0aW9uIDEuLCBwYXJhZ3JhcGggMjoNCg0KID4gICAgdG9s ZXJhbmNlIGFnYWluc3Qgc2luZ2xlIHBvaW50IG9mIGZhaWx1cmUsIFAyUCBzdHJlYW1pbmcgYXBw bGljYXRpb25zDQogPiAgICBhcmUgYWJsZSB0byBkaXN0cmlidXRlIGxhcmdlLXNjYWxlLCBsaXZl IGFuZCB2aWRlbyBvbiBkZW1hbmQgKFZvRCkNCiA+ICAgIHN0cmVhbWluZyBwcm9ncmFtcyB0byBt aWxsaW9ucyBvZiBhdWRpZW5jZSB3aXRoIG9ubHkgYSBoYW5kZnVsIG9mDQoNCiAgICJtaWxsaW9u cyBvZiBhdWRpZW5jZSIgZG9lc24ndCBzb3VuZCByaWdodC4gSG93IGFib3V0ICJ0byBhIGxhcmdl DQogICBhdWRpZW5jZSI/DQpbWXVuZmVpXSBBY3R1YWxseSB0aGVyZSBhcmUgcmVwb3J0cyBvbiBz b21lIG1lYXN1cmVtZW50cyBwYXBlciB0byBzaG93IFBQTGl2ZSBoYXMgbW9yZSB0aGFuIDEgbWls bGlvbiBjb25jdXJyZW50IHVzZXJzIC4gIEJ1dCBJIGFtIGZpbmUgb24geW91ciBzdWdnZXN0aW9u Lg0KDQpTZWN0aW9uIDEuLCBwYXJhZ3JhcGggMzoNCg0KID4gICAgc2VydmVycy4gV2hhdCdzIG1v cmUsIGFsb25nIHdpdGggdGhlIG5ldyBwbGF5ZXJzIGxpa2UgQ0ROIHByb3ZpZGVycw0KDQogICBD RE4gcHJvdmlkZXJzIGFyZSBub3QgcmVhbGx5IG5ldyBwbGF5ZXJzIGluIHRoZSBjb250ZW50IGRp c3RyaWJ1dGlvbg0KICAgbWFya2V0IGFueW1vcmUuIFRoZXkgYXJlIGluIHRoZSBtYXJrZXQgbXVj aCBsb25nZXIgdGhhbiBwMnAuLi4NCg0KW1l1bmZlaV0gTGV0IG1lIGNsYXJpZnkgbXkgcG9pbnQu IEhlcmUgSSBtZWFuIHRoZSBuZXcgcGxheWVycyBvbiAqcDJwIHN0cmVhbWluZw0KZGVsaXZlcnkq LCBpbnN0ZWFkIG9mIGNvbW1vbiBjb250ZW50IGRlbGl2ZXJ5LiBXZSBrbm93IHRoYXQgQWthbWFp IHN1cHBvcnRlZA0KcDJwIHN0cmVhbWluZyBtdWNoIGxhdGVyIHRoYW4gdGhlIHAycCBzdHJlYW1p bmcgcHJvdmlkZXJzLg0KU2VjdGlvbiAxLiwgcGFyYWdyYXBoIDU6DQoNCiA+ICAgIEdpdmVuIHRo ZSBpbmNyZWFzaW5nIGludGVncmF0aW9uIG9mIFAyUCBzdHJlYW1pbmcgaW50byB0aGUgZ2xvYmFs DQogPiAgICBjb250ZW50IGRlbGl2ZXJ5IGluZnJhc3RydWN0dXJlLCB0aGUgbGFjayBvZiBhbiBv cGVuLCBzdGFuZGFyZCBQMlANCiA+ICAgIHN0cmVhbWluZyBzaWduYWxpbmcgcHJvdG9jb2wgc3Vp dGUgYmVjb21lcyBhIG1ham9yIG1pc3NpbmcgY29tcG9uZW50DQogPiAgICBpbiB0aGUgcHJvdG9j b2wgc3RhY2suIEFsbW9zdCBhbGwgb2YgZXhpc3Rpbmcgc3lzdGVtcyB1c2UgdGhlaXINCg0KICAg anVzdCBkZWxldGUgImluIHRoZSBwcm90b2NvbCBzdGFjayIsIGFzIGl0IGRvZXMgbm90IGFkZCB0 byB0aGUNCiAgIHNlbnRlbmNlLCBidXQgaXQgYWRkIGNvbmZ1c2lvbi4NCltZdW5mZWldIE9rYXku DQoNClNlY3Rpb24gMS4sIHBhcmFncmFwaCA3Og0KDQogPiAgICBJbiB0aGlzIGRvY3VtZW50IHdl IHByb3Bvc2UgYW4gb3BlbiBQMlAgU3RyZWFtaW5nIFByb3RvY29sLCB3aGljaCBpcw0KID4gICAg ZGVmaW5lZCBhcyBQUFNQLCB0byBzdGFuZGFyZGl6ZSBzaWduYWxpbmcgb3BlcmF0aW9ucyBpbiBQ MlAgc3RyZWFtaW5nDQoNCiAgIHMvZGVmaW5lZCBhcyBQUFNQL2FiYnJldmlhdGVkIGFzIFBQU1Av Lg0KW1l1bmZlaV0gT2theS4NCg0KU2VjdGlvbiAyLiwgcGFyYWdyYXBoIDc6DQoNCiA+ICAgIFBl ZXI6IEEgcGVlciByZWZlcnMgdG8gYSBwYXJ0aWNpcGFudCBpbiBhIFAyUCBzdHJlYW1pbmcgc3lz dGVtIHRoYXQNCiA+ICAgIG5vdCBvbmx5IHJlY2VpdmVzIHN0cmVhbWluZyBjb250ZW50LCBidXQg YWxzbyBzdG9yZXMgYW5kIHN0cmVhbXMNCiA+ICAgIHN0cmVhbWluZyBjb250ZW50IHRvIG90aGVy IHBhcnRpY2lwYW50cy4NCg0KICAgQSBwZWVyIGRvZXMgbm90IG5lZWQgdG8gc3RvcmUgY29udGVu dC4NCltZdW5mZWldIEhvdyBhYm91dCB1c2luZyAqY2FjaGVzKiB0byByZXBsYWNlKiBzdG9yZXMq Pw0KDQoNClNlY3Rpb24gMi4sIHBhcmFncmFwaCAxMToNCg0KID4gICAgVHJhY2tlcjogQSB0cmFj a2VyIHJlZmVycyB0byBhIGRpcmVjdG9yeSBzZXJ2ZXIgdGhhdCBtYWludGFpbnMgYSBsaXN0DQoN CiAgIFdvdWxkbid0IGl0IGJlIGJldHRlciB0byBzYXkgJ2RpcmVjdG9yeSBzZXJ2aWNlJyBpbnN0 ZWFkIG9mDQogICAnZGlyZWN0b3J5IHNlcnZlcic/IEJlbG93IHlvdSBzYXkgdGhhdCB0aGUgdHJh Y2tlciBpcyBhIGxvZ2ljYWwNCiAgIGVudGl0eSB0aGF0IGNhbiBiZSBjZW50cmFsaXplZCAoaW5k ZWVkIGEgc2VydmVyICkgb3IgZGlzdHJpYnV0ZWQNCiAgIChub3QgYSBzZXJ2ZXIpLiBTZXJ2aWNl IHdvdWxkIG1hdGNoIGJldHRlciBoZXJlLg0KDQpbWXVuZmVpXUdvb2QgcHJvcG9zYWwuDQoNCg0K U2VjdGlvbiAyLiwgcGFyYWdyYXBoIDEzOg0KDQogPiAgICBWaWRlby1vbi1kZW1hbmQgKFZvRCk6 IEl0IHJlZmVycyB0byBhIHNjZW5hcmlvIHdoZXJlIGRpZmZlcmVudA0KID4gICAgY2xpZW50cyBt YXkgd2F0Y2ggZGlmZmVyZW50IHBhcnRzIG9mIHRoZSBzYW1lIHJlY29yZGVkIG1lZGlhIHdpdGgN CiA+ICAgIGRvd25sb2FkZWQgY29udGVudC4NCg0KICAgWW91IHVzZSBzb21ldGltZXMgbWVkaWEg YW5kIHNvbWV0aW1lcyBjb250ZW50LiBDaG9vc2Ugb25lIGFuZCBzdGljaw0KICAgdG8gaXQgdGhy b3VnaG91dCB0aGUgd2hvbGUgZHJhZnQuDQpbWXVuZmVpXSBPa2F5Lg0KDQpTZWN0aW9uIDMuMS4s IHBhcmFncmFwaCAxOg0KDQogPiAgICBJU1BzIGFyZSBmYWNlZCB0byBkaWZmZXJlbnQgUDJQIHN0 cmVhbWluZyBhcHBsaWNhdGlvbiBpbnRyb2R1Y2luZw0KDQogICBzL2FyZSBmYWNlZCB0by9hcmUg ZmFjZWQgd2l0aC8NCltZdW5mZWldIE9rYXkuDQoNCg0KU2VjdGlvbiAzLjEuLCBwYXJhZ3JhcGgg MzoNCg0KID4gICAgSG93ZXZlciwgdW5saWtlIFdlYiB0cmFmZmljIHRoYXQgaXMgcmVwcmVzZW50 ZWQgYnkgSFRUUCBwYWNrZXRzIGFuZA0KDQogICBzL0hUVFAgcGFja2V0cy9IVFRQIHJlcXVlc3Rz L3JlcHNvbnNlcy8NCiAgJ0hUVFAgcGFja2V0cycgaXNuJ3QgdGhlIHJpZ2h0IHRlcm0uDQpbWXVu ZmVpXSBPa2F5Lg0KDQpTZWN0aW9uIDMuMi4sIHBhcmFncmFwaCAyOg0KDQogPiAgICBJbiB0aGUg SHlicmlkIENETi9QMlAgYXBwcm9hY2gsIHRoZSBDRE4gdGFrZXMgdHdvIHJvbGVzOiBtZWRpYQ0K ID4gICAgc3RyZWFtaW5nIHNlcnZlciBhbmQgUDJQIHRyYWNrZXIuIFNpbWlsYXJseSB0byB3aGF0 IGRlc2NyaWJlZCBpbg0KDQogICBzL3RvIHdoYXQgZGVzY3JpYmVkIC90byB3aGF0IGlzIGRlc2Ny aWJlZC8NCg0KW1l1bmZlaV0gT2theS4NClNlY3Rpb24gMy4yLiwgcGFyYWdyYXBoIDM6DQoNCiA+ ICAgIHNlY3Rpb24gMy4xLCBwcm9wcmlldGFyeSBQMlAgcHJvdG9jb2xzIGludHJvZHVjZSBjb21w bGV4aXR5IGJldHdlZW4NCiA+ICAgIHBlZXJzIGFuZCBDRE4gdHJhY2tlcnMgYmVjYXVzZSB0aGUg Q0ROIHRyYWNrZXJzIG5lZWQgdG8gaWRlbnRpZnkgZWFjaA0KID4gICAgZGlmZmVyZW50IFAyUCBz dHJlYW1pbmcgcHJvdG9jb2wuIFRoaXMgaW5jcmVhc2VzIHRoZSBkZXBsb3ltZW50IGNvc3QNCiA+ ICAgIG9mIENETi4NCg0KICAgSSBkbyBub3QgdW5kZXJzdGFuZCB0aGUgaXNzdWUgaGVyZS4gRmly c3Qgb2YgYWxsLCBhbGwgdGhlIGRpZmZlcmVudA0KICAgcDJwIHN0cmVhbWluZyBzeXN0ZW1zIGNv dWxkIHVzZSBhIGNvbW1vbiB0cmFja2VyIHByb3RvY29sLiBTZWNvbmQsDQogICBob3cgZG9lcyB0 aGUgYWJvdmUgdGV4dCByZWxhdGUgdG8gbGF0ZW5jeSBpc3N1ZXM/IFRoaXJkLCBldmVuIGlmDQog ICB0aGVyZSBhcmUgbXVsdGlwbGUsIGRpZmZlcmVudCB0cmFja2VyIHByb3RvY29scyB3aGF0IGlz IHRoaXMgcmVsYXRlZA0KICAgdG8gaW4gdGhpcyBzZWN0aW9uPw0KW1l1bmZlaV0gV2hhdCBJIG1l YW4gaXMgdGhhdCAqYmVmb3JlKiB3ZSBkZXNpZ24gYW5kIGltcGxlbWVudCBQUFNQLCBkaWZmZXJl bnQgUDJQIHN0cmVhbWluZw0Kc3lzdGVtcyBoYXZlIHRvIHVzZSBkaWZmZXJlbnQgcHJvdG9jb2xz LiBTZWNvbmQsIGZvciB0aGUgbGF0ZW5jeSBpc3N1ZSwgaXQgaXMgYmVjYXVzZSB0aGUgaW50cm9k dWN0aW9uIG9mICpDRE4qIG5vZGVzIA0KaW5zaWRlIHRoZSBwMnAgc3RyZWFtaW5nIGRlbGl2ZXJ5 IHJlZHVjZSB0aGUgbGF0ZW5jeSAoc2VlIGluIHRoZSByZWZlcmVuY2UgaW4gdGhlIHRleHQgZm9y IGRldGFpbCkuIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIENETiBtdXN0IGJlIGF3YXJlIG9mIHRo ZSBzcGVjaWZpYyBwMnAgc3RyZWFtaW5nIHByb3RvY29sIGluIG9yZGVyIHRvIGZvcm0gdGhlIGh5 YnJpZCBwMnArY2RuIGFyY2hpdGVjdHVyZSwgd2hpY2ggY2FuIGxlYWQgdG8gYSBzaG9ydGVyIGxh dGVuY3kgZnJvbSB0aGUgdXNlcnMnIHBlcnNwZWN0aXZlLg0KDQoNCg0KU2VjdGlvbiAzLjMuLCBw YXJhZ3JhcGggMzoNCg0KID4gICAgSG93ZXZlciBpdCdzIGRpZmZpY3VsdCB0byBhcHBseSBjdXJy ZW50IFAyUCBzdHJlYW1pbmcgcHJvdG9jb2xzIChldmVuDQogPiAgICBhc3N1bWluZyB3ZSBjYW4g cmUtdXNlIHNvbWUgb2YgdGhlIHByb3ByaWV0YXJ5IG9uZXMpIGluIG1vYmlsZSBhbmQNCiA+ICAg IHdpcmVsZXNzIG5ldHdvcmtzLiBBbHRob3VnaCBzbWFydCBoYW5kc2V0cyBhcmUgbW9yZSBlbGln aWJsZSB0bw0KID4gICAgYmVjb21lIHBlZXJzIHdpdGggbXVjaCBoaWdoZXIgYmFuZHdpZHRoLCBD UFUgZnJlcXVlbmN5LCBsYXJnZXINCiA+ICAgIHN0b3JhZ2UgYW5kIG1lbW9yeSB0aGFuIGJlZm9y ZSwgcGVlciBzZWxlY3Rpb24gd2lsbCBiZWNvbWUgbW9yZQ0KID4gICAgY2hhbGxlbmdpbmcgZHVl IHRvIHRoZSBpbmNyZWFzZSBhbmQgY29tcGxleGl0eSBvZiBleGNoYW5nZSBiZXR3ZWVuDQogPiAg ICBwZWVycyBhbmQgdHJhY2tlcnMuIEN1cnJlbnQgUDJQIHByb3RvY29scyBhcmUgbm90IHdlbGwg c3VpdGVkIGZvcg0KID4gICAgdGhlc2UgbmV3IHJlcXVpcmVtZW50cyBpbiB0aGUgY29udGV4dCBv ZiBtb2JpbGUgYW5kIHdpcmVsZXNzDQogPiAgICBuZXR3b3Jrcy4NCg0KICAgSSBkbyBrbm93IHdo YXQgeW91IGFyZSB0YXJnZXR0aW5nIGF0LCBidXQgSSBjYW5ub3QgdW5kZXJzdGFuZCBpdA0KICAg ZnJvbSB0aGUgYWJvdmUgdGV4dC4gVGhlIGludGVyYWN0aW9ucyBiZXR3ZWVuIG1vYmlsZSB0ZXJt aW5hbHMgYW5kDQogICB0cmFja2VycyBhcmUgbm90IGRpZmZlcmVudCB0byBmaXhlZCB0ZXJtaW5h bHMgYW5kIHRyYWNrZXJzLiBUaGUNCiAgIGlzc3VlIGlzIG1vcmUgdGhhdCBwMnAgYXNzdW1lcyBh IHN0YWJsZSBJbnRlcm5ldCBjb25uZWN0aW9uIGluDQogICBkb3dubGluayBhbmQgdXBsaW5rIGRp cmVjdGlvbiwgd2l0aCBkZWNlbnQgY2FwYWNpdHkgYW5kIHBlZXJzDQogICB0aGF0IGNhbiBydW4g Zm9yIGhvdXJzLiBUaGlzIGlzbid0IHRoZSB0eXBpY2FsIHNldHRpbmcgZm9yIG1vYmlsZQ0KICAg dGVybWluYWxzLiBZb3VyIGV4YW1wbGVzIHNob3VsZCBzb21lIG9mIHRoZSBjaGFsbGVuZ2VzIGJ1 dCB0aGUgdGV4dA0KICAgYWJvdmUgaXMgY29uZnVzaW5nIGF0IGJlc3QuDQpbWXVuZmVpXSBJIHRv dGFsbHkgYWdyZWUgd2l0aCB5b3VyIGp1ZGdlbWVudCBvbiB0aGUgbW9iaWxlIHRlcm1pbmFsIHBy b2JsZW1zLCBiYXNpY2FsbHkgYXMgaWRlbnRpZmllZCBpbiBuZXh0IHBhcmFncmFwaC4gSWYgcGVv cGxlIHRoaW5rIHRoaXMgcGFyYWdyYXBoIGlzIGNvbmZ1c2luZyBpbiB0ZXh0LCBJIHdvdWxkIHBy b3Bvc2UgdG8gbW92ZSBtb3N0IG9mIHRoZSBjb25mdXNlZCB0ZXh0Lg0KDQpTZWN0aW9uIDMuMy4s IHBhcmFncmFwaCA1Og0KDQogPiAgICBTZWNvbmQsIGN1cnJlbnQgcHJhY3RpY2VzIG9mdGVuIHVz ZSBhICJiaXRtYXAiIG1lc3NhZ2UgaW4gb3JkZXIgdG8NCiA+ICAgIGV4Y2hhbmdlIGNodW5rIGF2 YWlsYWJpbGl0eS4gVGhlIG1lc3NhZ2UgaXMgb2Yga2lsb2J5dGVzIGluIHNpemUgYW5kDQogPiAg ICBleGNoYW5nZWQgZnJlcXVlbnRseSwgZm9yIGV4YW1wbGUsIHNldmVyYWwgc2Vjb25kcy4gSW4g YSBtb2JpbGUNCg0KICAgJ3NldmVyYWwgc2Vjb25kcycgaXNuJ3QgY29ycmVjdCBoZXJlLiBZb3Ug cHJvYmFibHkgbWVhbiAnc2V2ZXJhbA0KICAgdGltZXMgaW4gYSBzZWNvbmQnLg0KW1l1bmZlaV0q J1NldmVyYWwgc2Vjb25kcyogaXMgdGhlIGNvbmRpdGlvbiBpbiBzb21lIHByYWN0aWNhbCBwMnAg c3RyZWFtaW5nIHN5c3RlbXMuIEkgd2lsbCBjaGVjayB0aGUNCmN1cnJlbnQgcHJhY3RpY2UgdG8g c2VlIGlmIGl0IGlzIG1vcmUgZnJlcXVlbnQgdGhhbiBiZWZvcmUuDQoNClNlY3Rpb24gNC4sIHBh cmFncmFwaCAwOg0KDQogPiAgICBUaGlyZCwgZm9yIGEgcmVzb3VyY2UgY29uc3RyYWludCBwZWVy IGxpa2UgbW9iaWxlIGhhbmRzZXRzIG9yIHNldC10b3ANCiA+ICAgIGJveGVzIChTVEIpLCB0aGVy ZSBhcmUgc2V2ZXJlIGNvbnRlbnRpb25zIG9uIGxpbWl0ZWQgcmVzb3VyY2Ugd2hlbg0KID4gICAg dXNpbmcgcHJvcHJpZXRhcnkgcHJvdG9jb2xzLiBUaGUgcGVlciBoYXMgdG8gaW5zdGFsbCBtYW55 IGRpZmZlcmVudA0KID4gICAgc3RyZWFtaW5nIGFwcGxpY2F0aW9ucyBmb3IgZGlmZmVyZW50IHVz YWdlcywgZS5nLiwgc29tZSBmb3IgbW92aWVzDQogPiAgICBhbmQgb3RoZXJzIGZvciBzcG9ydHMg YW5kIGVhY2ggb2YgdGhlc2UgYXBwbGljYXRpb25zIHdpbGwgY29tcGV0ZSBmb3INCiA+ICAgIHRo ZSBzYW1lIHNldCBvZiBtZW1vcmllcywgZmxhc2hlcyBvciBoYXJkIGRpc2tzKHNvbWUgbWF5IHJ1 biBpbiB0aGUNCiA+ICAgIGJhY2tncm91bmQgZXZlbiB0aGV5IGFyZSBub3QgaW52b2tlZCBieSB0 aGUgdXNlcnMpLiBPcGVuIHByb3RvY29scyANCmNyZWF0DQogPiAgICBhbiBvcHBvcnR1bml0eSB0 byB1c2Ugb25lIGNsaWVudCBzb2Z0d2FyZSBhY2NvbW1vZGF0aW5nIGRpZmZlcmVudCANClAyUCBz eXN0ZW1zLg0KID4gICAgVGhpcyBtYXkgYWxsZXZpYXRlIHRoaXMgcHJvYmxlbS4NCg0KICAgV2hh dCAnbWF5IGFsbGV2aWF0ZSB0aGlzIHByb2JsZW0nPw0KDQpbWXVuZmVpXSBUaGUgYmFzaWMgaWRl YSBpcyB0aGF0IHRoZSAib25lIGNsaWVudCBzb2Z0d2FyZStkaWZmZXJlbnQgc2NoZWR1bGluZyBw bHVnLWlucyINCmlzIGJldHRlciB0aGFuICJkaWZmZXJlbnQgY2xpZW50IHNvZnR3YXJlcyBydW5u aW5nIGF0IHRoZSBzYW1lIHRpbWUiIGluIG1lbW9yeSBhbmQgZGlzaw0Kcm9vbSBjb25zdW1wdGlv bi4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQogIDQuIFBQU1A6IFN0YW5kYXJkIHBlZXIgdG8gcGVl ciBzdHJlYW1pbmcgcHJvdG9jb2xzDQoNCg0KU2VjdGlvbiA0LiwgcGFyYWdyYXBoIDE6DQoNCiA+ ICAgIFBQU1AgaXMgdGFyZ2V0ZWQgdG8gc3RhbmRhcmRpemUgc2lnbmFsaW5nIHByb3RvY29scyBm b3IgdHJhY2tlci1iYXNlZA0KID4gICAgYXJjaGl0ZWN0dXJlcyB0byBzb2x2ZSB0aGUgYWJvdmUg cHJvYmxlbXMgdGhhdCBzdXBwb3J0IGVpdGhlciBsaXZlIG9yDQogPiAgICBWb0Qgc3RyZWFtaW5n Lg0KDQogICBJIGRvIG5vdCB0aGluayB0aGF0IHRoZSBhYm92ZSBzdGF0ZW1lbnQgaXMgY29tcGVs ZXRseSByaWdodCwgYXMgdGhlDQogICBwZWVyIHByb3RvY29sLCBhcyBJIGtub3cgaXQsIGNhbiBv cGVyYXRlIHdpdGggdHJhY2tlciBiYXNlZCBzeXN0ZW1zLA0KICAgYnV0IGFsc28gd2l0aG91dCBh IHRyYWNrZXIuDQpbWXVuZmVpXSBJIHdvdWxkIGRlbGV0ZSAiZm9yIHRyYWNrZXItYmFzZWQgYXJj aGl0ZWN0dXJlcyIgYXZvaWRpbmcgdGhlIGNvbmZ1c2lvbi4NCg0KU2VjdGlvbiA0LjEuLCBwYXJh Z3JhcGggMDoNCg0KICA0LjEuIFRyYWNrZXIgcHJvdG9jb2wgY2FuZGlkYXRlcyBkaXNjdXNzaW9u IGFuZCBkZXNpZ24gaXNzdWVzDQoNCiAgIFdoeSBpcyB0aGVyZSB0aGUgbmVlZCB0byBkaXNjdXNz IHRoZSBjYW5kaWRhdGVzIGluIHRoaXMNCiAgIGRyYWZ0PyBXb3VsZG4ndCBpdCBiZSBiZXR0ZXIg dG8gcm91Z2hseSBza2V0Y2ggdGhlIHRhc2sgb2YgdGhlDQogICB0cmFja2VyIHByb3RvY29sPyBJ LmUuLCB0byBnaXZlIGEgcmVhc29uaW5nIHdoeSBpdCBpcyByZXF1aXJlZD8NCltZdW5mZWldIE15 IGludGVudGlvbiB0byBkaXNjdXNzIHRoZSBjYW5kaWRhdGVzIGluIHRoaXMNCiAgIGRyYWZ0IGlz IHRvIHJlcGx5IERhdmlkIEhhcnJpbmd0b24ncyBJRVNHIHJldmlldyBvbiB0aGUgdGFza3Mgb2Yg dGhlIHRyYWNrZXIgcHJvdG9jb2wsIGFzIHlvdSBhbHNvIG1lbnRpb25lZC4NCiAgU2luY2Ugd2Ug aGF2ZSBwb2ludGVkIG91dCB0aGUgcHJvYmxlbXMgY3VycmVudCBwcm90b2NvbHMgaGF2ZSwgaW4g bXkgaW5pdGlhbCB0aG91Z2h0cyAobWF5YmUgSSBhbSB3cm9uZyksIEkgdGhpbmsgaW4gdGhpcw0K c2VjdGlvbiB3ZSBtYXkgbmVlZCB0aGUgZGlzY3VzcyB0aGUgY2FuZGlkYXRlcyBvZiB0aGUgcHJv dG9jb2xzLCBzaW5jZSB0aGUgcHJvdG9jb2wgZGVzaWduIGlzIHRoZSBtYWluIHRhc2tzIG9mIA0K dGhlIFdHLiBNYXkgSSBmdXJ0aGVyIGFzayB5b3VyIGltYWdpbmF0aW9ucyBvbiB0aGUgY29udGVu dCBvZiB0aGlzIHBhcnQgaW4gZGV0YWlsPyBJdCB3b3VsZCBiZSBtdWNoIGhlbHBmdWwgZm9yIHdy aXRpbmcgdGhpcyBwYXJ0LiANCg0KU2VjdGlvbiA0LjEuLCBwYXJhZ3JhcGggMToNCg0KID4gICAg VHJhY2tlciBwcm90b2NvbDogVGhlIHRyYWNrZXIgcHJvdG9jb2wgaXMgYmVzdCBtb2RlbGVkIGFz IGENCiA+ICAgIHJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wgYmV0d2VlbiBwZWVycyBhbmQgdHJh Y2tlcnMsIGFuZCB3aWxsIGNhcnJ5DQoNCiAgIFJlbW92ZSB0aGUgZmlyc3QgcGFydCBvZiB0aGUg c2VudGVuY2UsIGkuZS4sICdUcmFja2VyIHByb3RvY29sOicuDQoNCltZdW5mZWldIEZpbmUuDQoN CiA+ICAgIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhlIHNlbGVjdGlvbiBvZiBwZWVycyBzdWl0 YWJsZSBmb3IgcmVhbC0NCiA+ICAgIHRpbWUvVm9EIHN0cmVhbWluZy4NCg0KDQpTZWN0aW9uIDQu MS4sIHBhcmFncmFwaCA1Og0KDQogPiAgICBQUFNQIHRyYWNrZXIgcHJvdG9jb2wgd2lsbCBzZWxl Y3QgdGhlIGJlc3Qgb2YgdGhlIGFib3ZlIG9wdGlvbnMNCg0KICAgVGhpcyBzZW50ZW5jZSBpcyBu b3QgY29ycmVjdCwgYXMgdGhlIHRyYWNrZXIgd2lsbCBub3Qgc2VsZWN0IGFueQ0KICAgb3B0aW9u LCBidXQgdGhlIFdHIHdpbGwgc2VsZWN0IHNvbWV0aGluZywgaXNuJ3QgaXQ/DQpbWXVuZmVpXSBZ b3UgYXJlIHJpZ2h0Lg0KDQpTZWN0aW9uIDQuMi4sIHBhcmFncmFwaCAwOg0KDQogIDQuMi4gUGVl ciBwcm90b2NvbCBjYW5kaWRhdGVzIGRpc2N1c3Npb24gYW5kIGRlc2lnbiBpc3N1ZXMNCg0KICAg V2h5IGlzIHRoZXJlIHRoZSBuZWVkIHRvIGRpc2N1c3MgdGhlIGNhbmRpZGF0ZXMgaW4gdGhpcw0K ICAgZHJhZnQ/IFdvdWxkbid0IGl0IGJlIGJldHRlciB0byByb3VnaGx5IHNrZXRjaCB0aGUgdGFz ayBvZiB0aGUgcGVlcg0KICAgcHJvdG9jb2w/IEkuZS4sIHRvIGdpdmUgYSByZWFzb25pbmcgd2h5 IGl0IGlzIHJlcXVpcmVkPw0KDQpbWXVuZmVpXSBTYW1lIGFzIHRoZSB0cmFrZXIgcHJvdG9jb2wu DQpTZWN0aW9uIDQuMi4sIHBhcmFncmFwaCAxOg0KDQogPiAgICBQZWVyIFByb3RvY29sOiBUaGUg cGVlciBwcm90b2NvbCBpcyBtb2RlbGVkIGFzIGEgZ29zc2lwLWxpa2UgcHJvdG9jb2wNCiA+ICAg IHdpdGggcGVyaW9kaWMgZXhjaGFuZ2VzIG9mIG5laWdoYm9yIGFuZCBtZWRpYSBjaHVuayBhdmFp bGFiaWxpdHkNCiA+ICAgIGluZm9ybWF0aW9uLiBOYW1lbHksIHRoZSBwZWVyIHByb3RvY29sIGlz IGEgY29udGVudC1jZW50cmljIHByb3RvY29sDQogPiAgICBidWlsdCBhcm91bmQgdGhlIGFic3Ry YWN0aW9uIG9mIGEgY2xvdWQgb2YgcGFydGljaXBhbnRzIGRpc3NlbWluYXRpbmcNCiA+ICAgIHRo ZSBzYW1lIGRhdGEgaW4gd2F5cyBhbmQgb3JkZXJzIHRoYXQgYXJlIGNvbnZlbmllbnQgdG8gdGhl DQogPiAgICBwYXJ0aWNpcGFudHMgW0ktRC5pZXRmLXBwc3AtcGVlci1wcm90b2NvbF0uIEluIHRo YXQgcmVzcGVjdCBhbmQgaW4NCiA+ICAgIGxpZ2h0IG9mIHRoZSBhYm92ZSByZXF1aXJlbWVudHMs IHR5cGljYWwgSFRUUCBpcyBuZWl0aGVyIHN1aXRhYmxlIG5vcg0KID4gICAgZWZmaWNpZW50Lg0K DQogICB3aGF0IGRvZXMgdGhpcyBwYXJhZ3JhcGggYWRkIHRvIHRoZSBkaXNjdXNzaW9uPw0KW1l1 bmZlaV0gVGhlIGludGVudGlvbiB0byBhZGQgdGhpcyBkZXNjcmlwdGlvbiBvbiB0aGUgcGVlciBw cm90b2NvbCBpcyB0byANCm1ha2UgdGhlIHBlZXIgcHJvdG9jb2wgZGVzaWduZXJzIGJldHRlciB1 bmRlcnN0YW5kIHRoZSBiYXNpYyBwcmluY2lwbGUgb2YgdGhlIHBlZXIgcHJvdG9jb2wuDQpNb3Jl IGRldGFpbGVkIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KU2VjdGlvbiA0LjIuLCBwYXJh Z3JhcGggNToNCg0KID4gICAgVGhlIFBQU1AgcGVlciBwcm90b2NvbCB3aWxsIGRpc2N1c3MgdGhl IHByb3RvY29sIGRlc2lnbiByYXRpb25hbGVzIGluDQogPiAgICBkZXRhaWwuDQoNCiAgIFRoaXMg c2VjdGlvbiBkb2VzIG5vdCBoZWxwIGluIHRlcm1zIG9mIHByb2JsZW0gc3RhdGVtZW50IG5vciBm b3INCiAgIHRoZSByZXF1aXJlbWVudHMgbGlzdGVkIGxhdGVyIG9uLiBJdCB3b3VsZCBiZSBtdWNo IGJldHRlciB0byBleHBsYWluDQogICBicmllZmx5IHdoYXQgdGhlIHBlZXIgcHJvdG9jb2wgaXMg ZXhwZWN0ZWQgdG8gZG8gYW5kIGhvdyB0aGUgZWFybGllcg0KICAgbWVudGlvbmVkIHByb2JsZW1z IGFyZSBhZGRyZXNzZWQgYnkgYSBzdGFuZGFyZGl6ZWQgcGVlciBwcm90b2NvbC4NCg0KW1l1bmZl aV0gQWN0dWFsbHkgd2Ugd2FudCB0byBleHBsYWluIGluIHRoaXMgc2VjdGlvbiB3aGF0IHRoZSBw ZWVyIGFuZCB0cmFja2VyIHByb3RvY29sIA0Kc2hvdWxkIGRvIGFuZCBsZWF2ZSB0aGUgZXhwbGFp bmF0aW9uIG9mICJob3cgdGhlIGVhcmxpZXIgbWVudGlvbmVkIHByb2JsZW1zIGFyZSBhZGRyZXNz ZWQgYnkgYSBzdGFuZGFyZGl6ZWQgcGVlci90cmFja2VyIHByb3RvY29sIg0KaW4gc2VjdGlvbiA1 LCB0aGUgdXNlIGNhc2VzIHNlY3Rpb24uIEJ1dCB3ZSBtYXkgbm90IGZ1bGZpbCB0aGUgZm9ybWVy IHRhc2sgcGVyZmVjdGx5IG5vdy4NCkkgZ3Vlc3Mgd2UgbWF5IGFkZCBzb21lIGRlc2NpcHRpb25z IG9uLCBlLmcuLCB0aGUgaW5mb3JtYXRpb24gZmxvd3MgYW5kIHJlbGF0ZWQNCnBhcmFtZXRlcnMg aW4gdGhlIHR3byBwcm90b2NvbHMgaW4gYSBoaWdoLWxldmVsPyBUbyBiZSBob25lc3QsIHdlIGFy ZSBub3Qgc3VyZSBhYm91dCANCndoYXQgdGhlIHNwZWNpZmljIGNvbnRlbnQgd2UgbmVlZCB0byB3 cml0ZS4gU28gdGhlIGRldGFpbGVkIGd1aWRhbmNlIGlzIGhpZ2hseSBoZWxwZnVsLg0KDQoNClNl Y3Rpb24gNS4xLiwgcGFyYWdyYXBoIDE6DQoNCiA+ICAgIFRoZSBjb250ZW50IHByb3ZpZGVyIGNh biBlZmZpY2llbnRseSBpbmNyZWFzZSBsaXZlIHN0cmVhbWluZyBjb3ZlcmFnZQ0KID4gICAgYnkg aW50cm9kdWNpbmcgUFBTUCBpbiBiZXR3ZWVuIGRpZmZlcmVudCBwcm92aWRlcnMuDQoNCiAgICdp bicgb3IgJ2JldHdlZW4nIG9yICdpbi1iZXR3ZWVuJz8NCltZdW5mZWldIEkgdGhpbmsgaXQncyBp bi1iZXR3ZWVuLg0KDQpTZWN0aW9uIDUuMS4sIHBhcmFncmFwaCAyOg0KDQogPiAgICBGaWd1cmUg MiBzaG93cyB0aGUgY2FzZSBvZiBwcm92aWRlciBBIGJyb2FkY2FzdGluZyBhIFRWIHByb2dyYW0g d2l0aA0KID4gICAgdGhlIGhlbHAgb2YgcHJvdmlkZXIgQiBhbmQgQyBmb3IgYSB3aWRlciBjb3Zl cmFnZSBieSBpbnRyb2R1Y2luZyBQUFNQLg0KID4gICAgV2l0aG91dCBQUFNQLCB3aGVuIHVzZXJz IG91dHNpZGUgQSByZXF1ZXN0cyBUViBwcm9ncmFtQEEsIHRoZQ0KID4gICAgcmV0dXJuZWQgcGVl ci1saXN0IG1heSBpbmNsdWRlIGZldyBsb2NhbCBwZWVycy4gVGhpcyBtYXkgYWZmZWN0IHRoZQ0K ID4gICAgdXNlciBleHBlcmllbmNlLiBXaXRoIFBQU1AsIEIgYW5kIEMgY2FuIGludm9sdmUgaW4g dGhlIGJyb2FkY2FzdGluZy4NCg0KICAgSG9uZXN0bHksIEkgZG8gbm90IHVuZGVyc3RhbmQgdGhl IGNhc2UgeW91IGFyZSBkZXNjcmliaW5nLiBOZWl0aGVyDQogICB0aGUgdGV4dCBub3IgdGhlIGZp Z3VyZSBoZWxwIG1lIGluIGV4cGxhaW5pbmcgd2hhdCBpdCBpcyBhYm91dC4NCg0KW1l1bmZlaV0g VGhlIGJhc2ljIGlkZWEgaXMgdGhhdCBjb25zaWRlcmluZyB0aGVyZSBpcyBvbmx5ICBBo6hlLmcs LCBpbiBDaGluYSkgcHJvdmlkaW5nIHRoZSBsaXZlIHN0cmVhbWluZw0KaW4gcHJvdmlkZXIgQihl LmcuLCBpbiBVU0EpIGFuZCBDKGUuZy4sIGluIEV1cm9wZSkncyBjb3ZlcmFnZS4gV2hlbiBhIHVz ZXKjqGUuZy6jrGEgY2hpbmVzZSBhbWVyaWNhbikgaW4gVVNBIHJlcXVlc3RzIHRoZSBwcm9ncmFt IHRvIHRoZSB0cmFja2VyKCBpdCBpcyBsb2NhdGVkIGluIEEncyBjb3ZlcmFnZSksIHRoZSB0cmFj a2VyIGNhbiByZXR1cm4gdG8gdGhlIHVzZXIgd2l0aCBhIHBlZXItbGlzdCBpbmNsdWRpbmcgbW9z dCBvZiBwZWVycyBpbiBDaGluYaOoQmVjYXVzZSBnZW5lcmFsbHkgbW9zdCB1c2VycyBhcmUgaW4g Q2hpbmEgYW5kIHRoZXJlIGFyZSBvbmx5IGZldyB1c2VycyBpbiBVU0EpLiBCdXQgaWYgd2UgY2Fu IHVzZSBQUFNQIHRvIA0KaW52b2x2ZSBCIGFuZCBDIGluIHRoZSBwcm92aXNpb24sIGV2ZW4gd2hl biB0aGUgc3RyZWFtaW5nIGlzIG5vdCBob3QgdG8gYXR0cmFjdCBtYW55IHVzZXJzIGluIFVTQSBh bmQgRXVyb3BlIHRvIHZpZXcsIHRoZSANCnRyYWNrZXIgaW4gQSBjYW4gcmV0dXJuIHRoZSB1c2Vy IHdpdGggYSBwZWVyLWxpc3QgaW5jbHVkaW5nIEIncyBTTiBhbmQgQydzIFNOLiANCg0KDQpTZWN0 aW9uIDUuMS4sIHBhcmFncmFwaCAzOg0KDQogPiAgICBUaGUgcHJvdmlkZXJzIG9mdGVuIGRlcGxv eSBpbi1uZXR3b3JrIHBlZXJzIGNhbGxlZCBzdXBlci1ub2RlcyAoU04NCg0KICAgJ1N1cGVyLW5v ZGUnIGlzIG5vdCBtZW50aW9uZWQgaW4gdGhlIHRlcm1pbm9sb2d5Lg0KDQpbWXVuZmVpXSBJJ2xs IGFkZCB0aGlzIGluIHRoZSB0ZXJtaW5vbG9neS4NClNlY3Rpb24gNS4xLiwgcGFyYWdyYXBoIDU6 DQoNCiA+ICAgIEZpZ3VyZSAzIHNob3dzIHRoZSBjYXNlIG9mIGNvb3BlcmF0aXZlIFZvRCBwcm92 aXNpb24gYnkgaW50cm9kdWNpbmcNCiA+ICAgIFBQU1AgaW5zaWRlIENETiBvdmVybGF5cyBhbmQg aW4gYmV0d2VlbiBkaWZmZXJlbnQgQ0ROcy4gSXQgaXMgc2ltaWxhcg0KID4gICAgdG8gRmlndXJl IDIgZXhjZXB0IHRoYXQgdGhlIGludGVybWVkaWF0ZSBTTnMgYXJlIHJlcGxhY2VkIGJ5IDNyZA0K ID4gICAgcGFydHkgQ0ROIHN1cnJvZ2F0ZXMuIFRoZSBDRE4gbm9kZXMgdGFsayB3aXRoIHRoZSBk aWZmZXJlbnQgc3RyZWFtaW5nDQogPiAgICBzeXN0ZW1zIHdpdGggdGhlIHNhbWUgUFBTUCBwcm90 b2NvbHMuIE5vdGUgdGhhdCBmb3IgY29tcGF0aWJpbGl0eQ0KID4gICAgcmVhc29uIGJvdGggSFRU UCBzdHJlYW1pbmcgYW5kIFAyUCBzdHJlYW1pbmcgY2FuIGJlIHN1cHBvcnRlZCBieSBDRE4uDQoN CiAgIEkgd291bGQgc3VnZ2VzdCB0byBtb3ZlIHRoZSBoeWJyaWQgY2RuL3AycCBjYXNlIGluIGEg bmV3IHNlY3Rpb24NCiAgIGFuZCBub3QgdG8gYmUgcGFydCBvZiBzZWN0aW9uIDUuMQ0KDQpbWXVu ZmVpXSBUaGF0J3MgZmluZS4NCg0KDQpTZWN0aW9uIDUuMy4sIHBhcmFncmFwaCAxOg0KDQogPiAg ICBJbiBGaWd1cmUgNSwgd2hlbiBwZWVycyByZXF1ZXN0IHRoZSBQMlAgc3RyZWFtaW5nIGRhdGEs IHRoZSBjYWNoZQ0KID4gICAgbm9kZXMgaW50ZXJjZXB0IHRoZSByZXF1ZXN0cyBhbmQgYXNrIGZv ciB0aGUgZnJlcXVlbnRseSB2aXNpdGVkDQogPiAgICBjb250ZW50IChvciBwYXJ0IG9mKSBvbiBi ZWhhbGYgb2YgdGhlIHBlZXJzLiBUbyBkbyB0aGlzLCBpdCBhc2tzIHRoZQ0KID4gICAgdHJhY2tl ciBmb3IgdGhlIHBlZXItbGlzdCBhbmQgdGhlIHRyYWNrZXIgcmVwbGllcyB3aXRoIGV4dGVybmFs IHBlZXJzDQogPiAgICBpbiB0aGUgcGVlci1saXN0LiBBZnRlciB0aGUgY2FjaGUgbm9kZXMgZXhj aGFuZ2UgZGF0YSB3aXRoIHRoZXNlDQogPiAgICBwZWVycywgaXQgY2FuIGFsc28gYWN0IGFzIGEg cGVlciBhbmQgcmVwb3J0IHdoYXQgaXQgY2FjaGVzIHRvIHRoZQ0KID4gICAgdHJhY2tlciBhbmQg c2VydmUgcmVxdWVzdGluZyBwZWVycyBpbnNpZGUgYWZ0ZXJ3YXJkLiBUaGlzIG9wZXJhdGlvbg0K ID4gICAgZ3JlYXRseSBkZWNyZWFzZXMgdGhlIGludGVyLW5ldHdvcmsgdHJhZmZpYyBhbmQgaW5j cmVhc2VzIHVzZXINCg0KICAgSSB3b3VsZCBhZGQgJ2NhbiBncmVhdGx5IGRlY3JlYXNlJywgYXMg aW4gc29tZSBzaXR1YXRpb25zIGl0DQogICB3b3VsZG4ndC4gRS5nLiwgd2hlbiBlYWNoIHBlZXIg aXMgYXNraW5nIGZvciBhIGRpZmZlcmVudCBjb250ZW50Lg0KW1l1bmZlaV0gVGhlIGhpdCByYXRp byBvZiBwMnAgY2FjaGUgaW4gcHJhY3RpY2FsIG5ldHdvcmtzIGlzIGFib3V0IDkwJSsgaW4gc3Rh dGlzdGljcy4NCklzIGl0IGJldHRlciB0byBzYXkiIGNhbiBncmVhdGx5IGRlY2VyZWFzZSBpbiBt YW55IGNvbmRpdGlvbnMiPw0KDQoNClNlY3Rpb24gNi4sIHBhcmFncmFwaCAxOg0KW1l1bmZlaV0g TmluZyB3aWxsIHJlcGx5IHRoZSByZXF1aXJlbWVudHMgcGFydCBpbiB0aGUgZm9sbG93aW5nIGRh eXMuDQogPiAgICBUaGlzIHNlY3Rpb24gZW51bWVyYXRlcyB0aGUgcmVxdWlyZW1lbnRzIHRoYXQg c2hvdWxkIGJlIGNvbnNpZGVyZWQNCiA+ICAgIHdoZW4gZGVzaWduaW5nIFBQU1AuDQoNCiAgIFRo ZSByZXF1aXJlbWVudHMgdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSBhY2NvcmRpbmcgUkZDIDIxMTku IEhvd2V2ZXIsDQogICBSRkMgMjExOSBpcyBuZXZlciBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0IGF0 IGFsbC4NCg0KDQpTZWN0aW9uIDYuMS4sIHBhcmFncmFwaCAwOg0KDQogIDYuMS4gQmFzaWMgUmVx dWlyZW1lbnRzDQoNCiAgIE1hbnkgb2YgdGhlIHJlcXVpcmVtZW50cyBsaXN0ZWQgaGVyZSBhcmUg bm90IGJhc2ljIHJlcXVpcmVtZW50cw0KICAgYnV0IGFscmVhZHkgdmVyeSBzcGVjaWZpYyByZXF1 aXJlbWVudHMgdGhhdCBiZWxvbmcgaW4gb3RoZXINCiAgIHNlY3Rpb25zLiBFLmcuLCB0aGUgcGVl ciBJRCBiZWxvbmdzIElNSE8gaW50byB0aGUgcGVlciBzZWN0aW9uLg0KDQoNClNlY3Rpb24gNi4x LiwgcGFyYWdyYXBoIDE6DQoNCiA+ICAgIFBQU1AuUkVRLTE6IFRoZSB0cmFja2VyIGFuZCB0aGUg cGVlciBwcm90b2NvbCBTSE9VTEQgYWxsb3cgcGVlcnMgdG8NCiA+ICAgIHJlY2VpdmUgc3RyZWFt aW5nIGNvbnRlbnQgd2l0aGluIHRoZSByZXF1aXJlZCB0aW1lIGNvbnN0cmFpbnRzLg0KDQogICBU aGlzIG5vdCBhIHByb3RvY29sIHJlcXVpcmVtZW50LCBhcyBpdCBpcyBub3Qgc3BlY2lmeWluZyBz b21ldGhpbmcNCiAgIHdlIGNhbiBxdWFsaWZ5IGxhdGVyIG9uLg0KDQoNClNlY3Rpb24gNi4xLiwg cGFyYWdyYXBoIDc6DQoNCiA+ICAgIEEga2V5IGNoYXJhY3RlcmlzdGljIG9mIFAyUCBzdHJlYW1p bmcgc3lzdGVtIGlzIGFsbG93aW5nIHRoZSBkYXRhDQogPiAgICBmZXRjaGluZyBmcm9tIGRpZmZl cmVudCBwZWVycyBjb25jdXJyZW50bHkuIFRoZXJlZm9yZSwgdGhlIHdob2xlDQogPiAgICBzdHJl YW1pbmcgY29udGVudCBtdXN0IGFsbG93IHRvIGJlIHBhcnRpdGlvbmVkIGludG8gc21hbGwgcGll Y2VzIG9yDQogPiAgICBjaHVua3MgZm9yIHRyYW5zbWlzc2lvbiBiZXR3ZWVuIHBlZXJzLg0KDQog ICBUaGlzIHNlZW1zIHRvIGJlIG1vcmUgYSBwcmVyZXF1aXNpdGUgaW5zdGVhZCBvZiBhIHByb3Rv Y29sDQogICByZXF1aXJlbWVudC4NCg0KDQpTZWN0aW9uIDYuMS4sIHBhcmFncmFwaCAxMDoNCg0K ID4gICAgUFBTUC5SRVEtNjogVGhlIHRyYWNrZXIgcHJvdG9jb2wgYW5kIHBlZXIgcHJvdG9jb2wg YXJlIHJlY29tbWVuZGVkIHRvDQogPiAgICBiZSBjYXJyaWVkIG92ZXIgVENQIG9yIFVEUC4NCg0K ICAgTm8gJ01VU1QnIG9yICdTSE9VTEQnIGxpa2UgdGhlIG90aGVyIHJlcXVpcmVtZW50cz8gV2h5 IGlzIHRoZXJlDQogICBvbmx5IGEgc2luZ2xlIHJlcXVpcmVtZW50cyBmb3IgYm90aCBwcm90b2Nv bHMsIGkuZS4sIGZvciB0aGUgcGVlcg0KICAgcHJvdG9jb2wgYW5kIHRoZSB0cmFja2VyIHByb3Rv Y29sPyBTaG91bGRuJ3QgdGhpcyBhdCBsZWFzdCBiZSAyDQogICBzZXBhcmF0ZWQgcmVxdWlyZW1l bnRzPw0KDQoNClNlY3Rpb24gNi4xLiwgcGFyYWdyYXBoIDExOg0KDQogPiAgICBQUFNQLlJFUS03 OiBUaGUgdHJhY2tlciBhbmQgcGVlciBwcm90b2NvbCB0b2dldGhlciBNVVNUIGZhY2lsaXRhdGUN CiA+ICAgIGFjY2VwdGFibGUgUW9TIChlLmcuIGxvdyBzdGFydHVwIGRlbGF5LCBsb3cgY2hhbm5l bC9jb250ZW50IHN3aXRjaGluZw0KID4gICAgdGltZSBhbmQgbWluaW1hbCBlbmQtdG8tZW5kIGRl bGF5KSBmb3IgYm90aCBsaXZlIGFuZCBWb0Qgc3RyZWFtaW5nDQogPiAgICBldmVuIGZvciB2ZXJ5 IHBvcHVsYXIgY29udGVudC4gVGhlIHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2wgZG8gbm90DQog PiAgICBpbmNsdWRlIHRoZSBhbGdvcml0aG0gcmVxdWlyZWQgZm9yIHNjYWxhYmxlIHN0cmVhbWlu Zy4gSG93ZXZlciwgdGhlDQogPiAgICB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sIFNIQUxMIE5P VCByZXN0cmljdCBvciBwbGFjZSBsaW1pdHMgb24gYW55DQogPiAgICBzdWNoIGFsZ29yaXRobS4N Cg0KICAgVGhpcyByZXF1aXJlbWVudCBpcyBhdCBsZWFzdCBsaXN0aW5nIDIgcmVxdWlyZW1lbnRz LiBTb21ldGhpbmcgYWJvdXQNCiAgIFFvUyBhbmQgdGhlIGxpbWl0cyBvZiB0aGUgYWxnb3JpdGht LiBRb1MgaXMgYWdhaW4gaGFyZCB0byBxdWFsaWZ5DQogICBhbmQgaWYgeW91IHdhbnQgdG8gc2F5 IHNvbWV0aGluZyBhYm91dCB0aGlzLCBJIHdvdWxkIHN1Z2dlc3QgdG8NCiAgIG5vdCBtYWtlIGEg cmVxdWlyZW1lbnQsIGJ1dCB0byBhZGQgZXhwbGFuYXRvcnkgdGV4dCBhYm91dCB0aGlzLA0KICAg bGlrZSB5b3UgaGF2ZSBiZWxvdyB0aGlzLg0KDQoNClNlY3Rpb24gNi4yLiwgcGFyYWdyYXBoIDM6 DQoNCiA+ICAgIFBQU1AuVFAuUkVRLTI6IFRoZSBwZWVyIE1VU1QgaW1wbGVtZW50IHRoZSB0cmFj a2VyIHByb3RvY29sIGZvcg0KID4gICAgc2VuZGluZyBxdWVyaWVzIGFuZCBwZXJpb2RpY2FsIHBl ZXIgc3RhdHVzIHJlcG9ydHMvdXBkYXRlcyB0byB0aGUNCiA+ICAgIHRyYWNrZXIgYW5kIHJlY2Vp dmluZyB0aGUgY29ycmVzcG9uZGluZyByZXBsaWVzLg0KDQogICBIb3cgYWJvdXQgaW5zdGVhZCBv ZiAnVGhlIHBlZXInICdBIFBQU1AgcGVlcic/IFRoaXMgc2VlbXMgdG8gYmUNCiAgIG5vdCBhIHJl cXVpcmVtZW50IGZvciB0aGUgdHJhY2tlciAoaS5lLiwgd3Jvbmcgc2VjdGlvbiksIGJ1dCBhDQog ICByZXF1aXJlbWVudCBmb3IgYSBwZWVyLg0KDQoNClNlY3Rpb24gNi4yLiwgcGFyYWdyYXBoIDk6 DQoNCiA+ICAgIFBQU1AuVFAuUkVRLTc6IFRoZSBjaHVuayBhdmFpbGFiaWxpdHkgaW5mb3JtYXRp b24gb2YgdGhlIHBlZXIgU0hPVUxEDQogPiAgICBiZSByZXBvcnRlZCB0byB0cmFja2VyIHdoZW4g dHJhY2tlciBuZWVkcyBzdWNoIGluZm9ybWF0aW9uIHRvIHN0ZWVyDQogPiAgICBwZWVyIHNlbGVj dGlvbi4gVGhlIGNodW5rIGluZm9ybWF0aW9uIE1VU1QgYXQgbGVhc3QgY29udGFpbiB0aGUNCiA+ ICAgIGNodW5rIElELg0KDQogICBUaGlzIHJlcXVpcmVtZW50IGlzIG1pc2xlYWRpbmcsIGFzIGl0 IGRvZXMgbm90IGV4YWN0bHkgc3RhdGUgd2hhdA0KICAgdGhlIHJlcXVpcmVtZW50IGZvciB0aGUg dHJhY2tlciBwcm90b2NvbCBpcy4gSXQgY291bGQgcmVhZCB0aGF0DQogICB0aGUgdHJhY2tlciBw cm90b2NvbCBzaG91bGQgc3VwcG9ydCB0aGUgcmVwb3J0aW5nIG9mIGFib3V0IGNodW5rDQogICBh dmFpbGFiaWxpdHkuDQoNCg0KU2VjdGlvbiA2LjIuLCBwYXJhZ3JhcGggMTA6DQoNCiA+ICAgIFBQ U1AuVFAuUkVRLTg6IFRoZSBjaHVuayBhdmFpbGFiaWxpdHkgaW5mb3JtYXRpb24gYmV0d2VlbiBw ZWVyIGFuZA0KID4gICAgdHJhY2tlciBNVVNUIGJlIGV4cHJlc3NlZCBhcyBjb21wYWN0IGFzIHBv c3NpYmxlLg0KDQogICBXaGF0IGlzIGFzIGNvbXBhY3QgYXMgcG9zc2libGU/IEEgMTB0aCBvZiB0 aGUgb3JpZ2luYWwgc2l6ZT8gVGhpcw0KICAgaXMgbm90IGEgZ29vZCByZXF1aXJlbWVudC4NCg0K DQpTZWN0aW9uIDYuMi4sIHBhcmFncmFwaCAxMjoNCg0KID4gICAgUFBTUC5UUC5SRVEtOTogVGhl IHN0YXR1cyBvZiB0aGUgcGVlciBTSE9VTEQgYmUgcmVwb3J0ZWQgdG8gdGhlDQogPiAgICB0cmFj a2VyIHdoZW4gdHJhY2tlciBuZWVkcyBzdWNoIGluZm9ybWF0aW9uIGluIG9yZGVyIHRvIHN0ZWVy IHBlZXINCiA+ICAgIHNlbGVjdGlvbi4NCg0KICAgVGhpcyBpbXBsaWVzIHRoYXQgdGhlIHRyYWNr ZXIgcHJvdG9jb2wgaXMgbm90IGEgcHVyZSByZXF1ZXN0L3Jlc3BvbnNlDQogICBwcm90b2NvbCBm cm9tIHRoZSBwZWVyJ3MgcGVyc3BlY3RpdmUsIGlzbid0IGl0Pw0KDQoNCg0KDQotLSANCklFVEYg VHJhbnNwb3J0IEFyZWEgRGlyZWN0b3INCg0KbWFydGluLnN0aWVtZXJsaW5nQG5lY2xhYi5ldQ0K DQpORUMgTGFib3JhdG9yaWVzIEV1cm9wZSAtIE5ldHdvcmsgUmVzZWFyY2ggRGl2aXNpb24gTkVD IEV1cm9wZSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3Rvcmlh IFJvYWQsIExvbmRvbiBXMyA2QkwNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlz dA0KcHBzcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w cHNw ------=_001_NextPart605386236211_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Martin,
    First of all, thanks so much for your valuable comm= ents,=20 suggestions and questions on the draft. Here are some initial=20 response. Further comments, esp. for section 4 are high appreciat= ed.=20 Thanks.
 
BR
yunfei 
 
zhangyunfei
 
Date: 2012-09-21 21:51
To: ppsp@ietf.org
Subject: [ppsp] An early AD review of=20 draft-ietf-ppsp-problem-statement-10.txt
Dear all,
 
I have seen the update of the draft=  
draft-ietf-ppsp-problem-statement-10.txt.
 
I did a first round of my review&nb= sp;that you can find below. It is up&nbs= p;to 
Section 6.3, but not including this sect= ion.
 
There are a number of editorials, but&nb= sp;also some more technical 
questions. I guess we need to discuss&nb= sp;some of them here on the list.
 
The first half of the review:
 
 
INTRODUCTION, paragraph 4:
 
 >    Peer-to-Peer (P2P for = ;short) streaming systems show more and more<= /DIV>
 >    popularity in current = ;Internet with proprietary protocols. This
 >    document identifies proble= ms of the proprietary protocols, proposes a
 >    Peer to Peer Streamin= g Protocol (PPSP) including tracker and peer<= /DIV>
 >    signaling components, and&= nbsp;discusses the scope, requirements and uses
 >    cases of PPSP.
 
   s/and uses cases/and use cases/<= /DIV>
 
[Yunfei] Okay.
  Status of this Memo
 
 
Section 1., paragraph 1:
 
 >    Streaming traffic is = among the largest and fastest growing traffic=  on
 >    the Internet [Cisco], = ;where peer-to-peer (P2P) streaming contribute
 >    substantially. With the&nb= sp;advantage of high scalability and fault
 
   s/streaming contribute/streaming contribut= es/
 
[Yunfei] Okay.
 
Section 1., paragraph 2:
 
 >    tolerance against single&n= bsp;point of failure, P2P streaming applications
 >    are able to distribut= e large-scale, live and video on demand = (VoD)
 >    streaming programs to = ;millions of audience with only a handful&nbs= p;of
 
   "millions of audience" doesn't s= ound right. How about "to a large
   audience"?
[Yunfei] Actually there are reports on some=20 measurements paper to show PPLive has more than 1 million concurrent=20 users .  But I am fine on your suggestion.
 
Section 1., paragraph 3:
 
 >    servers. What's more, = ;along with the new players like CDN pro= viders
 
   CDN providers are not really&nbs= p;new players in the content distribution
   market anymore. They are in = ;the market much longer than p2p...
 
[Yunfei] Let me clarify my point. Here I mean= the=20 new players on *p2p streaming
delivery*, instead of common content delivery= . We=20 know that Akamai supported
p2p streaming much later than the p2p streami= ng=20 providers.
Section 1., paragraph 5:
 
 >    Given the increasing = integration of P2P streaming into the global<= /DIV>
 >    content delivery infrastru= cture, the lack of an open, standard P2P=
 >    streaming signaling protoc= ol suite becomes a major missing component
 >    in the protocol stack= . Almost all of existing systems use the= ir
 
   just delete "in the protocol&nbs= p;stack", as it does not add to the
   sentence, but it add confusion.<= /DIV>
[Yunfei] Okay.
 
Section 1., paragraph 7:
 
 >    In this document we&n= bsp;propose an open P2P Streaming Protocol, w= hich is
 >    defined as PPSP, to&n= bsp;standardize signaling operations in P2P stream= ing
 
   s/defined as PPSP/abbreviated as = ;PPSP/.
[Yunfei] Okay.
 
Section 2., paragraph 7:
 
 >    Peer: A peer refers&n= bsp;to a participant in a P2P streaming = system that
 >    not only receives str= eaming content, but also stores and streams
 >    streaming content to = other participants.
 
   A peer does not need to&nbs= p;store content.
[Yunfei] How about using *caches* to replace*= =20 stores*?
 
 
Section 2., paragraph 11:
 
 >    Tracker: A tracker re= fers to a directory server that maintains&nbs= p;a list
 
   Wouldn't it be better to sa= y 'directory service' instead of
   'directory server'? Below you sa= y that the tracker is a logical
   entity that can be centralized&n= bsp;(indeed a server ) or distributed
   (not a server). Service would&nb= sp;match better here.
 
[Yunfei]Good proposal.
 
 
Section 2., paragraph 13:
 
 >    Video-on-demand (VoD): It&= nbsp;refers to a scenario where different
 >    clients may watch dif= ferent parts of the same recorded media = with
 >    downloaded content.
 
   You use sometimes media and = ;sometimes content. Choose one and stick
   to it throughout the whole = draft.
[Yunfei] Okay.
 
Section 3.1., paragraph 1:
 
 >    ISPs are faced to&nbs= p;different P2P streaming application introducing
 
   s/are faced to/are faced with/
[Yunfei] Okay.
 
 
Section 3.1., paragraph 3:
 
 >    However, unlike Web t= raffic that is represented by HTTP packets&nb= sp;and
 
   s/HTTP packets/HTTP requests/repsonses/
  'HTTP packets' isn't the right te= rm.
[Yunfei] Okay.
 
Section 3.2., paragraph 2:
 
 >    In the Hybrid CDN/P2P=  approach, the CDN takes two roles: medi= a
 >    streaming server and = P2P tracker. Similarly to what described in
 
   s/to what described /to what&nbs= p;is described/
 
[Yunfei] Okay.
Section 3.2., paragraph 3:
 
 >    section 3.1, proprietary&n= bsp;P2P protocols introduce complexity between
 >    peers and CDN tracker= s because the CDN trackers need to ident= ify each
 >    different P2P streaming&nb= sp;protocol. This increases the deployment cost
 >    of CDN.
 
   I do not understand the iss= ue here. First of all, all the different=
   p2p streaming systems could use&= nbsp;a common tracker protocol. Second,
   how does the above text rel= ate to latency issues? Third, even if
   there are multiple, different tr= acker protocols what is this related
   to in this section?
[Yunfei] What I mean is that *before* we desi= gn and=20 implement PPSP, different P2P streaming
systems have to use different protocols. Seco= nd, for=20 the latency issue, it is because the introduction of *CDN* nodes
inside the p2p streaming delivery reduce the = latency=20 (see in the reference in the text for detail). The problem is that the CDN = must=20 be aware of the specific p2p streaming protocol in order to form the hybrid= =20 p2p+cdn architecture, which can lead to a shorter latency from the users'=20 perspective.
 
 
 
Section 3.3., paragraph 3:
 
 >    However it's difficult&nbs= p;to apply current P2P streaming protocols (e= ven
 >    assuming we can re-us= e some of the proprietary ones) in mobil= e and
 >    wireless networks. Althoug= h smart handsets are more eligible to
 >    become peers with muc= h higher bandwidth, CPU frequency, larger
 >    storage and memory th= an before, peer selection will become more
 >    challenging due to th= e increase and complexity of exchange between=
 >    peers and trackers. C= urrent P2P protocols are not well suited = ;for
 >    these new requirements&nbs= p;in the context of mobile and wireless
 >    networks.
 
   I do know what you are = ;targetting at, but I cannot understand it
   from the above text. The in= teractions between mobile terminals and
   trackers are not different to&nb= sp;fixed terminals and trackers. The
   issue is more that p2p assu= mes a stable Internet connection in
   downlink and uplink direction, w= ith decent capacity and peers
   that can run for hours. Thi= s isn't the typical setting for mobile
   terminals. Your examples should = some of the challenges but the text
   above is confusing at best.
[Yunfei] I totally agree with your judgement = on the=20 mobile terminal problems, basically as identified in next paragraph. If peo= ple=20 think this paragraph is confusing in text, I would propose to mov= e=20 most of the confused text.
 
Section 3.3., paragraph 5:
 
 >    Second, current practices&= nbsp;often use a "bitmap" message in order&nb= sp;to
 >    exchange chunk availabilit= y. The message is of kilobytes in size&n= bsp;and
 >    exchanged frequently, for&= nbsp;example, several seconds. In a mobile
 
   'several seconds' isn't correct = here. You probably mean 'several
   times in a second'.
[Yunfei]*'Several seconds* is the condit= ion in=20 some practical p2p streaming systems. I will check the
current practice to see if it is more frequen= t than=20 before.
 
Section 4., paragraph 0:
 
 >    Third, for a resource=  constraint peer like mobile handsets or = ;set-top
 >    boxes (STB), there ar= e severe contentions on limited resource when=
 >    using proprietary protocol= s. The peer has to install many differen= t
 >    streaming applications for=  different usages, e.g., some for movies
 >    and others for sports=  and each of these applications will com= pete for
 >    the same set of = memories, flashes or hard disks(some may run&= nbsp;in the
 >    background even they = are not invoked by the users). Open prot= ocols 
creat
 >    an opportunity to use=  one client software accommodating different =
P2P systems.
 >    This may alleviate th= is problem.
 
   What 'may alleviate this problem= '?
 
[Yunfei] The basic idea is that the "one clie= nt=20 software+different scheduling plug-ins"
is better than "different client softwares ru= nning=20 at the same time" in memory and disk
room consumption. Does this make sense?
  4. PPSP: Standard peer to peer&nb= sp;streaming protocols
 
 
Section 4., paragraph 1:
 
 >    PPSP is targeted to&n= bsp;standardize signaling protocols for tracker-based
 >    architectures to solve&nbs= p;the above problems that support either live=  or
 >    VoD streaming.
 
   I do not think that the&nbs= p;above statement is compeletly right, as the=
   peer protocol, as I know it= , can operate with tracker based systems,
   but also without a tracker.
[Yunfei] I would delete "for tracker-based=20 architectures" avoiding the confusion.
 
Section 4.1., paragraph 0:
 
  4.1. Tracker protocol candidates discu= ssion and design issues
 
   Why is there the need to&nb= sp;discuss the candidates in this
   draft? Wouldn't it be better&nbs= p;to roughly sketch the task of the
   tracker protocol? I.e., to give&= nbsp;a reasoning why it is required?
[Yunfei] My intention to=20 discuss the candidates in this
   draft is to reply David=20 Harrington's IESG review on the tasks of the tracker protocol, as you also = mentioned.
  Since we have pointed out the problems= =20 current protocols have, in my initial thoughts (maybe I am wrong), I think = in=20 this
section we may need the discuss the candidate= s of=20 the protocols, since the protocol design is the main tasks of
the WG. May I further ask your imaginations o= n the=20 content of this part in detail? It would be much helpful for writing this=20 part. 
 
Section 4.1., paragraph 1:
 
 >    Tracker protocol: The = ;tracker protocol is best modeled as a
 >    request/response protocol = between peers and trackers, and will carry
 
   Remove the first part of th= e sentence, i.e., 'Tracker protocol:'.
 
[Yunfei] Fine.
 
 >    information needed for&nbs= p;the selection of peers suitable for real-
 >    time/VoD streaming.
 
 
Section 4.1., paragraph 5:
 
 >    PPSP tracker protocol = ;will select the best of the above optio= ns
 
   This sentence is not correct,&nb= sp;as the tracker will not select any
   option, but the WG will sel= ect something, isn't it?
[Yunfei] You are right.
 
Section 4.2., paragraph 0:
 
  4.2. Peer protocol candidates discussi= on and design issues
 
   Why is there the need to&nb= sp;discuss the candidates in this
   draft? Wouldn't it be better&nbs= p;to roughly sketch the task of the peer=
   protocol? I.e., to give a r= easoning why it is required?
 
[Yunfei] Same as the traker protocol.
Section 4.2., paragraph 1:
 
 >    Peer Protocol: The pe= er protocol is modeled as a gossip-like = protocol
 >    with periodic exchanges&nb= sp;of neighbor and media chunk availability
 >    information. Namely, the&n= bsp;peer protocol is a content-centric protocol
 >    built around the abst= raction of a cloud of participants disseminat= ing
 >    the same data in = ;ways and orders that are convenient to = the
 >    participants [I-D.ietf-ppsp-pee= r-protocol]. In that respect and in
 >    light of the above&nb= sp;requirements, typical HTTP is neither suitable&= nbsp;nor
 >    efficient.
 
   what does this paragraph add&nbs= p;to the discussion?
[Yunfei] The intention to add this descriptio= n on=20 the peer protocol is to
make the peer protocol designers better = understand the basic principle of the peer protocol.
More detailed comments are appreciated.
 
Section 4.2., paragraph 5:
 
 >    The PPSP peer protoco= l will discuss the protocol design rationales=  in
 >    detail.
 
   This section does not help = in terms of problem statement nor for
   the requirements listed later on= . It would be much better to explain
   briefly what the peer protocol&n= bsp;is expected to do and how the earlie= r
   mentioned problems are addressed = ;by a standardized peer protocol.
 
[Yunfei] Actually we want to explain in this = section=20 what the peer and tracker protocol 
should do and leave the explaination of=20 "how the earlier=20 mentioned problems are addressed by a standar= dized peer/tracker protocol"
in section 5, the use cases section. But we m= ay not=20 fulfil the former task perfectly now.
I guess we may add some desciptions on, e.g.,= the=20 information flows and related
parameters in the two protocols in a high-lev= el? To=20 be honest, we are not sure about
what the specific content we need to write.=20 So the detailed guidance is highly helpful.
 
 
Section 5.1., paragraph 1:
 
 >    The content provider = can efficiently increase live streaming coverage
 >    by introducing PPSP i= n between different providers.
 
   'in' or 'between' or 'in-between= '?
[Yunfei] I think it's in-between.
 
Section 5.1., paragraph 2:
 
 >    Figure 2 shows the&nb= sp;case of provider A broadcasting a TV = program with
 >    the help of provider&= nbsp;B and C for a wider coverage by&nbs= p;introducing PPSP.
 >    Without PPSP, when us= ers outside A requests TV program@A, the
 >    returned peer-list may&nbs= p;include few local peers. This may affect&nb= sp;the
 >    user experience. With = ;PPSP, B and C can involve in the b= roadcasting.
 
   Honestly, I do not understand&nb= sp;the case you are describing. Neither
   the text nor the figure hel= p me in explaining what it is about.
 
[Yunfei] The basic idea is that considering t= here is=20 only  A=A3=A8e.g,, in China) providing the live streaming
in provider B(e.g., in USA) and C(e.g., = in=20 Europe)'s coverage. When a user=A3=A8e.g.=A3=ACa chinese american)&nbs= p;in USA=20 requests the program to the tracker( it is located in A's coverage), the tr= acker=20 can return to the user with a peer-list including most of peers in China=A3= =A8Because=20 generally most users are in China and there are only few users in USA). But= if=20 we can use PPSP to
involve B and C in the provision, even when t= he=20 streaming is not hot to attract many users in USA and Europe to view, the <= /DIV>
tracker in A can return the user with a peer-= list=20 including B's SN and C's SN.
 
 
Section 5.1., paragraph 3:
 
 >    The providers often d= eploy in-network peers called super-nodes (SN
 
   'Super-node' is not mentioned in=  the terminology.
 
[Yunfei] I'll add this in the terminology.
Section 5.1., paragraph 5:
 
 >    Figure 3 shows the&nb= sp;case of cooperative VoD provision by intro= ducing
 >    PPSP inside CDN overl= ays and in between different CDNs. It is=  similar
 >    to Figure 2 except&nb= sp;that the intermediate SNs are replaced by&= nbsp;3rd
 >    party CDN surrogates. = ;The CDN nodes talk with the different s= treaming
 >    systems with the same=  PPSP protocols. Note that for compatibility<= /DIV>
 >    reason both HTTP stre= aming and P2P streaming can be supported = ;by CDN.
 
   I would suggest to move the=  hybrid cdn/p2p case in a new section
   and not to be part of = section 5.1
 
[Yunfei] That's fine.
 
 
Section 5.3., paragraph 1:
 
 >    In Figure 5, when&nbs= p;peers request the P2P streaming data, the&n= bsp;cache
 >    nodes intercept the r= equests and ask for the frequently visited
 >    content (or part of)&= nbsp;on behalf of the peers. To do this,=  it asks the
 >    tracker for the peer-= list and the tracker replies with external&nb= sp;peers
 >    in the peer-list. Aft= er the cache nodes exchange data with th= ese
 >    peers, it can also&nb= sp;act as a peer and report what it = ;caches to the
 >    tracker and serve req= uesting peers inside afterward. This operation
 >    greatly decreases the = ;inter-network traffic and increases user
 
   I would add 'can greatly de= crease', as in some situations it
   wouldn't. E.g., when each peer&n= bsp;is asking for a different content.
[Yunfei] The hit ratio of p2p cache in practi= cal=20 networks is about 90%+ in statistics.
Is it better to say" can greatly decerease in= many=20 conditions"?
 
 
Section 6., paragraph 1:
[Yunfei] Ning will reply the requirements par= t in=20 the following days.
 >    This section enumerates&nb= sp;the requirements that should be considered
 >    when designing PPSP.
 
   The requirements use normative l= anguage according RFC 2119. However,
   RFC 2119 is never mentioned = ;in the draft at all.
 
 
Section 6.1., paragraph 0:
 
  6.1. Basic Requirements
 
   Many of the requirements listed&= nbsp;here are not basic requirements
   but already very specific requir= ements that belong in other
   sections. E.g., the peer ID = ;belongs IMHO into the peer section.
 
 
Section 6.1., paragraph 1:
 
 >    PPSP.REQ-1: The tracker&nb= sp;and the peer protocol SHOULD allow peers&n= bsp;to
 >    receive streaming content&= nbsp;within the required time constraints.
 
   This not a protocol requirement,=  as it is not specifying something
   we can qualify later on.
 
 
Section 6.1., paragraph 7:
 
 >    A key characteristic = of P2P streaming system is allowing the = data
 >    fetching from different&nb= sp;peers concurrently. Therefore, the whole
 >    streaming content must&nbs= p;allow to be partitioned into small pieces&n= bsp;or
 >    chunks for transmission&nb= sp;between peers.
 
   This seems to be more a&nbs= p;prerequisite instead of a protocol
   requirement.
 
 
Section 6.1., paragraph 10:
 
 >    PPSP.REQ-6: The tracker&nb= sp;protocol and peer protocol are recommended = ;to
 >    be carried over TCP&n= bsp;or UDP.
 
   No 'MUST' or 'SHOULD' like = the other requirements? Why is there
   only a single requirements for&n= bsp;both protocols, i.e., for the peer
   protocol and the tracker protoco= l? Shouldn't this at least be 2
   separated requirements?
 
 
Section 6.1., paragraph 11:
 
 >    PPSP.REQ-7: The tracker&nb= sp;and peer protocol together MUST facilitate
 >    acceptable QoS (e.g. = low startup delay, low channel/content switching
 >    time and minimal end-= to-end delay) for both live and VoD stre= aming
 >    even for very popular=  content. The tracker and peer protocol = do not
 >    include the algorithm = ;required for scalable streaming. However, the
 >    tracker and peer prot= ocol SHALL NOT restrict or place limits = on any
 >    such algorithm.
 
   This requirement is at least&nbs= p;listing 2 requirements. Something about
   QoS and the limits of the&n= bsp;algorithm. QoS is again hard to qualify
   and if you want to say = ;something about this, I would suggest to
   not make a requirement, but = ;to add explanatory text about this,
   like you have below this.
 
 
Section 6.2., paragraph 3:
 
 >    PPSP.TP.REQ-2: The peer&nb= sp;MUST implement the tracker protocol for
 >    sending queries and p= eriodical peer status reports/updates to the
 >    tracker and receiving = ;the corresponding replies.
 
   How about instead of 'The p= eer' 'A PPSP peer'? This seems to be
   not a requirement for the t= racker (i.e., wrong section), but a
   requirement for a peer.
 
 
Section 6.2., paragraph 9:
 
 >    PPSP.TP.REQ-7: The chunk&n= bsp;availability information of the peer SHOULD
 >    be reported to tracke= r when tracker needs such information to = ;steer
 >    peer selection. The c= hunk information MUST at least contain the
 >    chunk ID.
 
   This requirement is misleading, = as it does not exactly state what
   the requirement for the tracker&= nbsp;protocol is. It could read that
   the tracker protocol should supp= ort the reporting of about chunk
   availability.
 
 
Section 6.2., paragraph 10:
 
 >    PPSP.TP.REQ-8: The chunk&n= bsp;availability information between peer and
 >    tracker MUST be expre= ssed as compact as possible.
 
   What is as compact as possi= ble? A 10th of the original size? This
   is not a good requirement.
 
 
Section 6.2., paragraph 12:
 
 >    PPSP.TP.REQ-9: The status&= nbsp;of the peer SHOULD be reported to t= he
 >    tracker when tracker = needs such information in order to steer = ;peer
 >    selection.
 
   This implies that the tracker&nb= sp;protocol is not a pure request/response
   protocol from the peer's perspec= tive, isn't it?
 
 
 
 
-- 
IETF Transport Area Director
 
martin.stiemerling@neclab.eu
 
NEC Laboratories Europe - Network Research&nb= sp;Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria = ;Road, London W3 6BL
Registered in England 283
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart605386236211_=------ From zongning@huawei.com Mon Sep 24 03:55:15 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1625421F861B for ; Mon, 24 Sep 2012 03:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.533 X-Spam-Level: X-Spam-Status: No, score=-104.533 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mErE8iSG8cGP for ; Mon, 24 Sep 2012 03:55:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC4721F861A for ; Mon, 24 Sep 2012 03:55:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJY71572; Mon, 24 Sep 2012 10:55:11 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 11:54:34 +0100 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 11:55:10 +0100 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.206]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Mon, 24 Sep 2012 18:54:57 +0800 From: Zongning To: Martin Stiemerling , "ppsp@ietf.org" Thread-Topic: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt Thread-Index: AQHNmABZSJ1/2bQg9kqwQhYHENbotZeZUm3A Date: Mon, 24 Sep 2012 10:54:56 +0000 Message-ID: References: <505C70EF.6040000@neclab.eu> In-Reply-To: <505C70EF.6040000@neclab.eu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 10:55:15 -0000 Hi, Martin, Thank you very much for your review. Please see my initial response in Sect= ion 6 (requirements). > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Martin Stiemerling > Sent: Friday, September 21, 2012 9:52 PM > To: ppsp@ietf.org > Subject: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-1= 0.txt >=20 > Dear all, >=20 > I have seen the update of the draft > draft-ietf-ppsp-problem-statement-10.txt. >=20 > I did a first round of my review that you can find below. It is up to > Section 6.3, but not including this section. >=20 > There are a number of editorials, but also some more technical > questions. I guess we need to discuss some of them here on the list. >=20 > The first half of the review: >=20 >=20 > INTRODUCTION, paragraph 4: >=20 > > Peer-to-Peer (P2P for short) streaming systems show more and more > > popularity in current Internet with proprietary protocols. This > > document identifies problems of the proprietary protocols, proposes= a > > Peer to Peer Streaming Protocol (PPSP) including tracker and peer > > signaling components, and discusses the scope, requirements and use= s > > cases of PPSP. >=20 > s/and uses cases/and use cases/ > Status of this Memo >=20 >=20 > Section 1., paragraph 1: >=20 > > Streaming traffic is among the largest and fastest growing traffic = on > > the Internet [Cisco], where peer-to-peer (P2P) streaming contribute > > substantially. With the advantage of high scalability and fault >=20 > s/streaming contribute/streaming contributes/ >=20 >=20 > Section 1., paragraph 2: >=20 > > tolerance against single point of failure, P2P streaming applicatio= ns > > are able to distribute large-scale, live and video on demand (VoD) > > streaming programs to millions of audience with only a handful of >=20 > "millions of audience" doesn't sound right. How about "to a large > audience"? >=20 >=20 > Section 1., paragraph 3: >=20 > > servers. What's more, along with the new players like CDN providers >=20 > CDN providers are not really new players in the content distribution > market anymore. They are in the market much longer than p2p... >=20 >=20 > Section 1., paragraph 5: >=20 > > Given the increasing integration of P2P streaming into the global > > content delivery infrastructure, the lack of an open, standard P2P > > streaming signaling protocol suite becomes a major missing componen= t > > in the protocol stack. Almost all of existing systems use their >=20 > just delete "in the protocol stack", as it does not add to the > sentence, but it add confusion. >=20 >=20 > Section 1., paragraph 7: >=20 > > In this document we propose an open P2P Streaming Protocol, which i= s > > defined as PPSP, to standardize signaling operations in P2P streami= ng >=20 > s/defined as PPSP/abbreviated as PPSP/. >=20 >=20 > Section 2., paragraph 7: >=20 > > Peer: A peer refers to a participant in a P2P streaming system that > > not only receives streaming content, but also stores and streams > > streaming content to other participants. >=20 > A peer does not need to store content. >=20 >=20 > Section 2., paragraph 11: >=20 > > Tracker: A tracker refers to a directory server that maintains a li= st >=20 > Wouldn't it be better to say 'directory service' instead of > 'directory server'? Below you say that the tracker is a logical > entity that can be centralized (indeed a server ) or distributed > (not a server). Service would match better here. >=20 >=20 > Section 2., paragraph 13: >=20 > > Video-on-demand (VoD): It refers to a scenario where different > > clients may watch different parts of the same recorded media with > > downloaded content. >=20 > You use sometimes media and sometimes content. Choose one and stick > to it throughout the whole draft. >=20 >=20 > Section 3.1., paragraph 1: >=20 > > ISPs are faced to different P2P streaming application introducing >=20 > s/are faced to/are faced with/ >=20 >=20 > Section 3.1., paragraph 3: >=20 > > However, unlike Web traffic that is represented by HTTP packets and >=20 > s/HTTP packets/HTTP requests/repsonses/ > 'HTTP packets' isn't the right term. >=20 >=20 > Section 3.2., paragraph 2: >=20 > > In the Hybrid CDN/P2P approach, the CDN takes two roles: media > > streaming server and P2P tracker. Similarly to what described in >=20 > s/to what described /to what is described/ >=20 >=20 > Section 3.2., paragraph 3: >=20 > > section 3.1, proprietary P2P protocols introduce complexity between > > peers and CDN trackers because the CDN trackers need to identify ea= ch > > different P2P streaming protocol. This increases the deployment cos= t > > of CDN. >=20 > I do not understand the issue here. First of all, all the different > p2p streaming systems could use a common tracker protocol. Second, > how does the above text relate to latency issues? Third, even if > there are multiple, different tracker protocols what is this related > to in this section? >=20 >=20 > Section 3.3., paragraph 3: >=20 > > However it's difficult to apply current P2P streaming protocols (ev= en > > assuming we can re-use some of the proprietary ones) in mobile and > > wireless networks. Although smart handsets are more eligible to > > become peers with much higher bandwidth, CPU frequency, larger > > storage and memory than before, peer selection will become more > > challenging due to the increase and complexity of exchange between > > peers and trackers. Current P2P protocols are not well suited for > > these new requirements in the context of mobile and wireless > > networks. >=20 > I do know what you are targetting at, but I cannot understand it > from the above text. The interactions between mobile terminals and > trackers are not different to fixed terminals and trackers. The > issue is more that p2p assumes a stable Internet connection in > downlink and uplink direction, with decent capacity and peers > that can run for hours. This isn't the typical setting for mobile > terminals. Your examples should some of the challenges but the text > above is confusing at best. >=20 >=20 > Section 3.3., paragraph 5: >=20 > > Second, current practices often use a "bitmap" message in order to > > exchange chunk availability. The message is of kilobytes in size an= d > > exchanged frequently, for example, several seconds. In a mobile >=20 > 'several seconds' isn't correct here. You probably mean 'several > times in a second'. >=20 >=20 > Section 4., paragraph 0: >=20 > > Third, for a resource constraint peer like mobile handsets or set-t= op > > boxes (STB), there are severe contentions on limited resource when > > using proprietary protocols. The peer has to install many different > > streaming applications for different usages, e.g., some for movies > > and others for sports and each of these applications will compete f= or > > the same set of memories, flashes or hard disks(some may run in the > > background even they are not invoked by the users). Open protocols > creat > > an opportunity to use one client software accommodating different > P2P systems. > > This may alleviate this problem. >=20 > What 'may alleviate this problem'? > 4. PPSP: Standard peer to peer streaming protocols >=20 >=20 > Section 4., paragraph 1: >=20 > > PPSP is targeted to standardize signaling protocols for tracker-bas= ed > > architectures to solve the above problems that support either live = or > > VoD streaming. >=20 > I do not think that the above statement is compeletly right, as the > peer protocol, as I know it, can operate with tracker based systems, > but also without a tracker. >=20 >=20 > Section 4.1., paragraph 0: >=20 > 4.1. Tracker protocol candidates discussion and design issues >=20 > Why is there the need to discuss the candidates in this > draft? Wouldn't it be better to roughly sketch the task of the > tracker protocol? I.e., to give a reasoning why it is required? >=20 >=20 > Section 4.1., paragraph 1: >=20 > > Tracker protocol: The tracker protocol is best modeled as a > > request/response protocol between peers and trackers, and will carr= y >=20 > Remove the first part of the sentence, i.e., 'Tracker protocol:'. >=20 > > information needed for the selection of peers suitable for real- > > time/VoD streaming. >=20 >=20 > Section 4.1., paragraph 5: >=20 > > PPSP tracker protocol will select the best of the above options >=20 > This sentence is not correct, as the tracker will not select any > option, but the WG will select something, isn't it? >=20 >=20 > Section 4.2., paragraph 0: >=20 > 4.2. Peer protocol candidates discussion and design issues >=20 > Why is there the need to discuss the candidates in this > draft? Wouldn't it be better to roughly sketch the task of the peer > protocol? I.e., to give a reasoning why it is required? >=20 >=20 > Section 4.2., paragraph 1: >=20 > > Peer Protocol: The peer protocol is modeled as a gossip-like protoc= ol > > with periodic exchanges of neighbor and media chunk availability > > information. Namely, the peer protocol is a content-centric protoco= l > > built around the abstraction of a cloud of participants disseminati= ng > > the same data in ways and orders that are convenient to the > > participants [I-D.ietf-ppsp-peer-protocol]. In that respect and in > > light of the above requirements, typical HTTP is neither suitable n= or > > efficient. >=20 > what does this paragraph add to the discussion? >=20 >=20 > Section 4.2., paragraph 5: >=20 > > The PPSP peer protocol will discuss the protocol design rationales = in > > detail. >=20 > This section does not help in terms of problem statement nor for > the requirements listed later on. It would be much better to explain > briefly what the peer protocol is expected to do and how the earlier > mentioned problems are addressed by a standardized peer protocol. >=20 >=20 > Section 5.1., paragraph 1: >=20 > > The content provider can efficiently increase live streaming covera= ge > > by introducing PPSP in between different providers. >=20 > 'in' or 'between' or 'in-between'? >=20 >=20 > Section 5.1., paragraph 2: >=20 > > Figure 2 shows the case of provider A broadcasting a TV program wit= h > > the help of provider B and C for a wider coverage by introducing PP= SP. > > Without PPSP, when users outside A requests TV program@A, the > > returned peer-list may include few local peers. This may affect the > > user experience. With PPSP, B and C can involve in the broadcasting= . >=20 > Honestly, I do not understand the case you are describing. Neither > the text nor the figure help me in explaining what it is about. >=20 >=20 > Section 5.1., paragraph 3: >=20 > > The providers often deploy in-network peers called super-nodes (SN >=20 > 'Super-node' is not mentioned in the terminology. >=20 >=20 > Section 5.1., paragraph 5: >=20 > > Figure 3 shows the case of cooperative VoD provision by introducing > > PPSP inside CDN overlays and in between different CDNs. It is simil= ar > > to Figure 2 except that the intermediate SNs are replaced by 3rd > > party CDN surrogates. The CDN nodes talk with the different streami= ng > > systems with the same PPSP protocols. Note that for compatibility > > reason both HTTP streaming and P2P streaming can be supported by > CDN. >=20 > I would suggest to move the hybrid cdn/p2p case in a new section > and not to be part of section 5.1 >=20 >=20 > Section 5.3., paragraph 1: >=20 > > In Figure 5, when peers request the P2P streaming data, the cache > > nodes intercept the requests and ask for the frequently visited > > content (or part of) on behalf of the peers. To do this, it asks th= e > > tracker for the peer-list and the tracker replies with external pee= rs > > in the peer-list. After the cache nodes exchange data with these > > peers, it can also act as a peer and report what it caches to the > > tracker and serve requesting peers inside afterward. This operation > > greatly decreases the inter-network traffic and increases user >=20 > I would add 'can greatly decrease', as in some situations it > wouldn't. E.g., when each peer is asking for a different content. >=20 >=20 > Section 6., paragraph 1: >=20 > > This section enumerates the requirements that should be considered > > when designing PPSP. >=20 > The requirements use normative language according RFC 2119. However, > RFC 2119 is never mentioned in the draft at all. [Ning] I will add reference in next revision. >=20 >=20 > Section 6.1., paragraph 0: >=20 > 6.1. Basic Requirements >=20 > Many of the requirements listed here are not basic requirements > but already very specific requirements that belong in other > sections. E.g., the peer ID belongs IMHO into the peer section. >=20 >=20 > Section 6.1., paragraph 1: >=20 > > PPSP.REQ-1: The tracker and the peer protocol SHOULD allow peers to > > receive streaming content within the required time constraints. >=20 > This not a protocol requirement, as it is not specifying something > we can qualify later on. [Ning] There was discuss about if we should include requirements not only t= o protocols, but also to P2P streaming system. The previous consensus was y= es. But anyway I can add clarification later on. >=20 >=20 > Section 6.1., paragraph 7: >=20 > > A key characteristic of P2P streaming system is allowing the data > > fetching from different peers concurrently. Therefore, the whole > > streaming content must allow to be partitioned into small pieces or > > chunks for transmission between peers. >=20 > This seems to be more a prerequisite instead of a protocol > requirement. >=20 [Ning] Same as above item. I can add clarification. >=20 > Section 6.1., paragraph 10: >=20 > > PPSP.REQ-6: The tracker protocol and peer protocol are recommended > to > > be carried over TCP or UDP. >=20 > No 'MUST' or 'SHOULD' like the other requirements? Why is there > only a single requirements for both protocols, i.e., for the peer > protocol and the tracker protocol? Shouldn't this at least be 2 > separated requirements? >=20 >=20 [Ning] I will separate it to two requirements. > Section 6.1., paragraph 11: >=20 > > PPSP.REQ-7: The tracker and peer protocol together MUST facilitate > > acceptable QoS (e.g. low startup delay, low channel/content switchi= ng > > time and minimal end-to-end delay) for both live and VoD streaming > > even for very popular content. The tracker and peer protocol do not > > include the algorithm required for scalable streaming. However, the > > tracker and peer protocol SHALL NOT restrict or place limits on any > > such algorithm. >=20 > This requirement is at least listing 2 requirements. Something about > QoS and the limits of the algorithm. QoS is again hard to qualify > and if you want to say something about this, I would suggest to > not make a requirement, but to add explanatory text about this, > like you have below this. >=20 [Ning] Again I think this belongs to P2P system requirements. I will add so= me clarification. >=20 > Section 6.2., paragraph 3: >=20 > > PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for > > sending queries and periodical peer status reports/updates to the > > tracker and receiving the corresponding replies. >=20 > How about instead of 'The peer' 'A PPSP peer'? This seems to be > not a requirement for the tracker (i.e., wrong section), but a > requirement for a peer. >=20 >=20 [Ning] This is requirement on the protocol between peer and tracker, which = include both peer and tracker (nodes). I can try to re-phrase the sentence = to make it more clear. > Section 6.2., paragraph 9: >=20 > > PPSP.TP.REQ-7: The chunk availability information of the peer SHOUL= D > > be reported to tracker when tracker needs such information to steer > > peer selection. The chunk information MUST at least contain the > > chunk ID. >=20 > This requirement is misleading, as it does not exactly state what > the requirement for the tracker protocol is. It could read that > the tracker protocol should support the reporting of about chunk > availability. [Ning] Agree. Will fix it later. >=20 >=20 > Section 6.2., paragraph 10: >=20 > > PPSP.TP.REQ-8: The chunk availability information between peer and > > tracker MUST be expressed as compact as possible. >=20 > What is as compact as possible? A 10th of the original size? This > is not a good requirement. >=20 [Ning] Agree. Will fix it later. >=20 > Section 6.2., paragraph 12: >=20 > > PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the > > tracker when tracker needs such information in order to steer peer > > selection. >=20 > This implies that the tracker protocol is not a pure request/response > protocol from the peer's perspective, isn't it? >=20 >=20 >=20 >=20 > -- > IETF Transport Area Director >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From Martin.Stiemerling@neclab.eu Mon Sep 24 06:24:00 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5487921F863B for ; Mon, 24 Sep 2012 06:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.996 X-Spam-Level: X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GK1tTu6tpVr for ; Mon, 24 Sep 2012 06:23:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DE44721F8697 for ; Mon, 24 Sep 2012 06:23:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 367E7101F22; Mon, 24 Sep 2012 15:23:58 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XRF5QULrU1p; Mon, 24 Sep 2012 15:23:58 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 1A5E7101EFA; Mon, 24 Sep 2012 15:23:43 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 24 Sep 2012 15:22:47 +0200 Message-ID: <50605EC9.4060507@neclab.eu> Date: Mon, 24 Sep 2012 15:23:21 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: zhangyunfei References: <505C70EF.6040000@neclab.eu> <2012092411122153407042@chinamobile.com> In-Reply-To: <2012092411122153407042@chinamobile.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.1.1.190] Cc: ppsp Subject: Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 13:24:00 -0000 Hi Yunfei, I'm just replying to the open items and I have removed the other items which are agreed. On 09/24/2012 12:27 PM, zhangyunfei wrote: > Hi Martin, > Section 1., paragraph 2: > > tolerance against single point of failure, P2P streaming applications > > are able to distribute large-scale, live and video on demand (VoD) > > streaming programs to millions of audience with only a handful of > "millions of audience" doesn't sound right. How about "to a large > audience"? > [Yunfei] Actually there are reports on some measurements paper to show > PPLive has more than 1 million concurrent users . But I am fine on your > suggestion. The number of users is a million right now, but could 10 million by tomorrow or 500,000 by tomorrow. Any number in that range is always a large audience. > Section 1., paragraph 3: > > servers. What's more, along with the new players like CDN providers > CDN providers are not really new players in the content distribution > market anymore. They are in the market much longer than p2p... > [Yunfei] Let me clarify my point. Here I mean the new players on *p2p > streaming > delivery*, instead of common content delivery. We know that Akamai supported > p2p streaming much later than the p2p streaming providers. I think if you write "along with the players like CDN providers joining" it is better to understand and also clear that they are new, since they are 'joining'. > Section 2., paragraph 7: > > Peer: A peer refers to a participant in a P2P streaming system that > > not only receives streaming content, but also stores and streams > > streaming content to other participants. > A peer does not need to store content. > [Yunfei] How about using *caches* to replace* stores*? Caches sounds good! > Section 3.2., paragraph 3: > > section 3.1, proprietary P2P protocols introduce complexity between > > peers and CDN trackers because the CDN trackers need to identify each > > different P2P streaming protocol. This increases the deployment cost > > of CDN. > I do not understand the issue here. First of all, all the different > p2p streaming systems could use a common tracker protocol. Second, > how does the above text relate to latency issues? Third, even if > there are multiple, different tracker protocols what is this related > to in this section? > [Yunfei] What I mean is that *before* we design and implement PPSP, > different P2P streaming > systems have to use different protocols. This I can easily understand and it would be good to separate it from the latency, e.g., making a new paragraph afterwards. Second, for the latency issue, > it is because the introduction of *CDN* nodes > inside the p2p streaming delivery reduce the latency (see in the > reference in the text for detail). The problem is that the CDN must be > aware of the specific p2p streaming protocol in order to form the hybrid > p2p+cdn architecture, which can lead to a shorter latency from the > users' perspective. Can you add this text, you just proposed here, of course adapted to the text flow? This helps a lot to understand the improvement of the latency. > Section 3.3., paragraph 3: > > However it's difficult to apply current P2P streaming protocols (even > > assuming we can re-use some of the proprietary ones) in mobile and > > wireless networks. Although smart handsets are more eligible to > > become peers with much higher bandwidth, CPU frequency, larger > > storage and memory than before, peer selection will become more > > challenging due to the increase and complexity of exchange between > > peers and trackers. Current P2P protocols are not well suited for > > these new requirements in the context of mobile and wireless > > networks. > I do know what you are targetting at, but I cannot understand it > from the above text. The interactions between mobile terminals and > trackers are not different to fixed terminals and trackers. The > issue is more that p2p assumes a stable Internet connection in > downlink and uplink direction, with decent capacity and peers > that can run for hours. This isn't the typical setting for mobile > terminals. Your examples should some of the challenges but the text > above is confusing at best. > [Yunfei] I totally agree with your judgement on the mobile terminal > problems, basically as identified in next paragraph. If people think > this paragraph is confusing in text, I would propose to move most of the > confused text. I would appreciate this! > Section 3.3., paragraph 5: > > Second, current practices often use a "bitmap" message in order to > > exchange chunk availability. The message is of kilobytes in size and > > exchanged frequently, for example, several seconds. In a mobile > 'several seconds' isn't correct here. You probably mean 'several > times in a second'. > [Yunfei]*'Several seconds* is the condition in some practical p2p > streaming systems. I will check the > current practice to see if it is more frequent than before. Yes, please check. I would reword it to 'exchanged frequently, e.g., every few seconds' or 'an interval of several seconds'. > Section 4., paragraph 0: > > Third, for a resource constraint peer like mobile handsets or set-top > > boxes (STB), there are severe contentions on limited resource when > > using proprietary protocols. The peer has to install many different > > streaming applications for different usages, e.g., some for movies > > and others for sports and each of these applications will compete for > > the same set of memories, flashes or hard disks(some may run in the > > background even they are not invoked by the users). Open protocols > creat > > an opportunity to use one client software accommodating different > P2P systems. > > This may alleviate this problem. > What 'may alleviate this problem'? > [Yunfei] The basic idea is that the "one client software+different > scheduling plug-ins" > is better than "different client softwares running at the same time" in > memory and disk > room consumption. Does this make sense? It makes perferctly sense, I would suggest to add you above text to the 'may alleviate'. > 4. PPSP: Standard peer to peer streaming protocols > Section 4., paragraph 1: > > PPSP is targeted to standardize signaling protocols for tracker-based > > architectures to solve the above problems that support either live or > > VoD streaming. > I do not think that the above statement is compeletly right, as the > peer protocol, as I know it, can operate with tracker based systems, > but also without a tracker. > [Yunfei] I would delete "for tracker-based architectures" avoiding the > confusion. Partially agree: I would remove 'or tracker-based architectures' in the sentence and make a separate one 'PPSP targets tracker-based architectures, as well as, architectures without tracker'. This is an important aspect to mention. > Section 4.1., paragraph 0: > 4.1. Tracker protocol candidates discussion and design issues > Why is there the need to discuss the candidates in this > draft? Wouldn't it be better to roughly sketch the task of the > tracker protocol? I.e., to give a reasoning why it is required? > [Yunfei] My intention to discuss the candidates in this > draft is to reply David Harrington's IESG review on the tasks of the > tracker protocol, as you also mentioned. > Since we have pointed out the problems current protocols have, in my > initial thoughts (maybe I am wrong), I think in this > section we may need the discuss the candidates of the protocols, since > the protocol design is the main tasks of > the WG. May I further ask your imaginations on the content of this part > in detail? It would be much helpful for writing this part. There can be various opinions about whether such section is useful in this draft or not. I do not find it useful here, but I do not object to keep it in, if the WG wants to have it. I am just wondering, if a high-level text about general functionality of the tracker protocol is probably linked to the requirements later on, would be useful? > Section 4.2., paragraph 0: > 4.2. Peer protocol candidates discussion and design issues > Why is there the need to discuss the candidates in this > draft? Wouldn't it be better to roughly sketch the task of the peer > protocol? I.e., to give a reasoning why it is required? > [Yunfei] Same as the traker protocol. My same reply as for the tracker protocol. > Section 4.2., paragraph 1: > > Peer Protocol: The peer protocol is modeled as a gossip-like protocol > > with periodic exchanges of neighbor and media chunk availability > > information. Namely, the peer protocol is a content-centric protocol > > built around the abstraction of a cloud of participants disseminating > > the same data in ways and orders that are convenient to the > > participants [I-D.ietf-ppsp-peer-protocol]. In that respect and in > > light of the above requirements, typical HTTP is neither suitable nor > > efficient. > what does this paragraph add to the discussion? > [Yunfei] The intention to add this description on the peer protocol is to > make the peer protocol designers better understand the basic principle > of the peer protocol. ok, what about replacing 'The peer protocol is modeled' with 'The peer protocol is expected to be modeled'? > More detailed comments are appreciated. > Section 4.2., paragraph 5: > > The PPSP peer protocol will discuss the protocol design rationales in > > detail. > This section does not help in terms of problem statement nor for > the requirements listed later on. It would be much better to explain > briefly what the peer protocol is expected to do and how the earlier > mentioned problems are addressed by a standardized peer protocol. > [Yunfei] Actually we want to explain in this section what the peer and > tracker protocol > should do and leave the explaination of "how the earlier > mentioned problems are addressed by a standardized peer/tracker protocol" > in section 5, the use cases section. But we may not fulfil the former > task perfectly now. > I guess we may add some desciptions on, e.g., the information flows and > related > parameters in the two protocols in a high-level? To be honest, we are > not sure about > what the specific content we need to write. So the detailed guidance is > highly helpful. I would suggest to remove this part of Section 4.2: " We list two peer protocol candidates: Websockets for bidirectional HTTP: WebSockets is basically a bidirectional TCP connection derived from a HTTP connection hence allowing a bidirectional P2P transport over HTTP. On the negative side, TCP is not ideally suited for multi-party transfers of the same content (see Rationale section in I-D.ietf-ppsp-peer-protocol) and therefore it introduces implementation (i.e., code) complexity. UDP based: Unlike TCP or HTTP, UDP is a datagram-based protocol without any sequential data stream abstraction which is, in most the cases, unnecessary for PPSP. Compared to the use of TCP, it reduces the per-connection footprint and complexity of TCP especially in resource constraint mobile cases. The PPSP peer protocol will discuss the protocol design rationales in detail. " > Section 5.1., paragraph 2: > > Figure 2 shows the case of provider A broadcasting a TV program with > > the help of provider B and C for a wider coverage by introducing PPSP. > > Without PPSP, when users outside A requests TV program@A, the > > returned peer-list may include few local peers. This may affect the > > user experience. With PPSP, B and C can involve in the broadcasting. > Honestly, I do not understand the case you are describing. Neither > the text nor the figure help me in explaining what it is about. > [Yunfei] The basic idea is that considering there is only A（e.g,, in > China) providing the live streaming > in provider B(e.g., in USA) and C(e.g., in Europe)'s coverage. When a > user（e.g.，a chinese american) in USA requests the program to the > tracker( it is located in A's coverage), the tracker can return to the > user with a peer-list including most of peers in China（Because > generally most users are in China and there are only few users in USA). > But if we can use PPSP to > involve B and C in the provision, even when the streaming is not hot to > attract many users in USA and Europe to view, the > tracker in A can return the user with a peer-list including B's SN and > C's SN. Just add this text and I am fine! :) > Section 5.3., paragraph 1: > > In Figure 5, when peers request the P2P streaming data, the cache > > nodes intercept the requests and ask for the frequently visited > > content (or part of) on behalf of the peers. To do this, it asks the > > tracker for the peer-list and the tracker replies with external peers > > in the peer-list. After the cache nodes exchange data with these > > peers, it can also act as a peer and report what it caches to the > > tracker and serve requesting peers inside afterward. This operation > > greatly decreases the inter-network traffic and increases user > I would add 'can greatly decrease', as in some situations it > wouldn't. E.g., when each peer is asking for a different content. > [Yunfei] The hit ratio of p2p cache in practical networks is about 90%+ > in statistics. > Is it better to say" can greatly decerease in many conditions"? Yes much better! > Section 6., paragraph 1: > [Yunfei] Ning will reply the requirements part in the following days. Ok, have seen his reply, though I still have to go through them. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From zhangyunfei@chinamobile.com Mon Sep 24 19:41:09 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FD921F88A3 for ; Mon, 24 Sep 2012 19:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.649 X-Spam-Level: X-Spam-Status: No, score=-93.649 tagged_above=-999 required=5 tests=[AWL=-2.321, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZJPPS-qeCvS for ; Mon, 24 Sep 2012 19:41:07 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF4821F84C5 for ; Mon, 24 Sep 2012 19:41:07 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3A0C1E5F8; Tue, 25 Sep 2012 10:41:08 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 2CF51E5F7; Tue, 25 Sep 2012 10:41:08 +0800 (CST) Received: from zyf-PC ([10.2.49.171]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092510410676-10203 ; Tue, 25 Sep 2012 10:41:06 +0800 Date: Tue, 25 Sep 2012 10:41:00 +0800 From: zhangyunfei To: "Martin Stiemerling" References: <505C70EF.6040000@neclab.eu> <2012092411122153407042@chinamobile.com>, <50605EC9.4060507@neclab.eu> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <20120925104100729123232@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-25 10:41:06, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-25 10:41:08, Serialize complete at 2012-09-25 10:41:08 Content-Type: multipart/alternative; boundary="----=_001_NextPart037678867412_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19208.003 X-TM-AS-Result: No--39.501-7.0-31-10 X-imss-scan-details: No--39.501-7.0-31-10;No--39.501-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: [ppsp] =?gb2312?b?u9i4tDogUmU6ICBBbiBlYXJseSBBRCByZXZpZXcgb2Yg?= =?gb2312?b?ZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTEwLnR4?= =?gb2312?b?dA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 02:41:10 -0000 This is a multi-part message in MIME format. ------=_001_NextPart037678867412_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgTWFydGluLA0KICAgIFRoYW5rcyBmb3IgdGhlIHF1aWNrIHJlc3BvbnNlLiBJdCdzIHJlYWxs eSBoZWxwZnVsIGZvciB1cyB0byB1bmRlcnN0YW5kIG1vcmUgdGhlIElFU0cgdGhvdWdodHMgaW4g Z2VuZXJhbCBmcm9tIHlvdXIgcmVwbHkuIEp1c3Qgc2FtZSBhcyB5b3UsIEkganVzdCB3YW50IHRv IGNvbmZpcm0gd2l0aCB5b3UgdGhlIG9wZW4gaXNzdWVzIGxlZnQuIFRoYW5rcyBhZ2Fpbi4NCg0K QlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQq3orz+yMujuiBNYXJ0aW4gU3RpZW1l cmxpbmcNCreiy83Ksbzko7ogMjAxMi0wOS0yNCAyMToyMw0KytW8/sjLo7ogemhhbmd5dW5mZWkN CrOty82juiBwcHNwOyBab25nTmluZw0K1vfM4qO6IFJlOiBbcHBzcF0gQW4gZWFybHkgQUQgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0xMC50eHQNCj4gU2VjdGlv biAzLjIuLCBwYXJhZ3JhcGggMzoNCj4gICA+ICAgIHNlY3Rpb24gMy4xLCBwcm9wcmlldGFyeSBQ MlAgcHJvdG9jb2xzIGludHJvZHVjZSBjb21wbGV4aXR5IGJldHdlZW4NCj4gICA+ICAgIHBlZXJz IGFuZCBDRE4gdHJhY2tlcnMgYmVjYXVzZSB0aGUgQ0ROIHRyYWNrZXJzIG5lZWQgdG8gaWRlbnRp ZnkgZWFjaA0KPiAgID4gICAgZGlmZmVyZW50IFAyUCBzdHJlYW1pbmcgcHJvdG9jb2wuIFRoaXMg aW5jcmVhc2VzIHRoZSBkZXBsb3ltZW50IGNvc3QNCj4gICA+ICAgIG9mIENETi4NCj4gICAgIEkg ZG8gbm90IHVuZGVyc3RhbmQgdGhlIGlzc3VlIGhlcmUuIEZpcnN0IG9mIGFsbCwgYWxsIHRoZSBk aWZmZXJlbnQNCj4gICAgIHAycCBzdHJlYW1pbmcgc3lzdGVtcyBjb3VsZCB1c2UgYSBjb21tb24g dHJhY2tlciBwcm90b2NvbC4gU2Vjb25kLA0KPiAgICAgaG93IGRvZXMgdGhlIGFib3ZlIHRleHQg cmVsYXRlIHRvIGxhdGVuY3kgaXNzdWVzPyBUaGlyZCwgZXZlbiBpZg0KPiAgICAgdGhlcmUgYXJl IG11bHRpcGxlLCBkaWZmZXJlbnQgdHJhY2tlciBwcm90b2NvbHMgd2hhdCBpcyB0aGlzIHJlbGF0 ZWQNCj4gICAgIHRvIGluIHRoaXMgc2VjdGlvbj8NCj4gW1l1bmZlaV0gV2hhdCBJIG1lYW4gaXMg dGhhdCAqYmVmb3JlKiB3ZSBkZXNpZ24gYW5kIGltcGxlbWVudCBQUFNQLCANCj4gZGlmZmVyZW50 IFAyUCBzdHJlYW1pbmcNCj4gc3lzdGVtcyBoYXZlIHRvIHVzZSBkaWZmZXJlbnQgcHJvdG9jb2xz LiANCg0KVGhpcyBJIGNhbiBlYXNpbHkgdW5kZXJzdGFuZCBhbmQgaXQgd291bGQgYmUgZ29vZCB0 byBzZXBhcmF0ZSBpdCBmcm9tDQp0aGUgbGF0ZW5jeSwgZS5nLiwgbWFraW5nIGEgbmV3IHBhcmFn cmFwaCBhZnRlcndhcmRzLg0KDQoNCg0KDQpTZWNvbmQsIGZvciB0aGUgbGF0ZW5jeSBpc3N1ZSwN Cj4gaXQgaXMgYmVjYXVzZSB0aGUgaW50cm9kdWN0aW9uIG9mICpDRE4qIG5vZGVzDQo+IGluc2lk ZSB0aGUgcDJwIHN0cmVhbWluZyBkZWxpdmVyeSByZWR1Y2UgdGhlIGxhdGVuY3kgKHNlZSBpbiB0 aGUgDQo+IHJlZmVyZW5jZSBpbiB0aGUgdGV4dCBmb3IgZGV0YWlsKS4gVGhlIHByb2JsZW0gaXMg dGhhdCB0aGUgQ0ROIG11c3QgYmUgDQo+IGF3YXJlIG9mIHRoZSBzcGVjaWZpYyBwMnAgc3RyZWFt aW5nIHByb3RvY29sIGluIG9yZGVyIHRvIGZvcm0gdGhlIGh5YnJpZCANCj4gcDJwK2NkbiBhcmNo aXRlY3R1cmUsIHdoaWNoIGNhbiBsZWFkIHRvIGEgc2hvcnRlciBsYXRlbmN5IGZyb20gdGhlIA0K PiB1c2VycycgcGVyc3BlY3RpdmUuDQoNCkNhbiB5b3UgYWRkIHRoaXMgdGV4dCwgeW91IGp1c3Qg cHJvcG9zZWQgaGVyZSwgb2YgY291cnNlIGFkYXB0ZWQgdG8gdGhlDQp0ZXh0IGZsb3c/IFRoaXMg aGVscHMgYSBsb3QgdG8gdW5kZXJzdGFuZCB0aGUgaW1wcm92ZW1lbnQgb2YgdGhlIGxhdGVuY3ku DQoNCltZdW5mZWldIERvZXMgaXQgbWFrZSBzZW5zZSB0aGF0IHdlIGRlc2NyaWJlIHRoZSBDRE4g cHJvYmxlbSBpbiBvbmx5IG9uZSBzdWJzZWN0aW9uLCBidXQgaW4gdGhlIGJlZ2lubmluZyBvZiB0 aGlzIHN1YnNlY3Rpb24sIHRvIGNsYXJpZnkgdGhhdCB0aGUgbWFpbiBwdXJwb3NlIG9mIHVzaW5n IENETiBpcyB0byByZWR1Y2UgdGhlIGxhdGVuY3koaS5lLiwgYWNjZWxlcmF0ZSB0aGUgc3BlZWQp P0FmdGVyIHRoYXQsDQp3ZSBzdGF0ZSB0aGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBDRE4gbXVzdCBi ZSBhd2FyZSBvZiB0aGUgc3BlY2lmaWMgcDJwIHN0cmVhbWluZyBwcm90b2NvbCBpbiBvcmRlciB0 byBmb3JtIHRoZSBoeWJyaWQgIHAycCtjZG4gYXJjaGl0ZWN0dXJlIGJ1dCB3ZSBkb24ndCBpbnZv bHZlIG11Y2ggb2YgdGhlIGRlc2NyaXB0aW9uIGFib3V0IHRoZSByb2xlcywgbGlrZSB0cmFja2Vy IG9yIHBlZXIuLi4uV2lsbCB0aGlzIGxvb2sgbW9yZQ0KY2xlYXI/DQoNCj4gU2VjdGlvbiA0LjEu LCBwYXJhZ3JhcGggMDoNCj4gICAgNC4xLiBUcmFja2VyIHByb3RvY29sIGNhbmRpZGF0ZXMgZGlz Y3Vzc2lvbiBhbmQgZGVzaWduIGlzc3Vlcw0KPiAgICAgV2h5IGlzIHRoZXJlIHRoZSBuZWVkIHRv IGRpc2N1c3MgdGhlIGNhbmRpZGF0ZXMgaW4gdGhpcw0KPiAgICAgZHJhZnQ/IFdvdWxkbid0IGl0 IGJlIGJldHRlciB0byByb3VnaGx5IHNrZXRjaCB0aGUgdGFzayBvZiB0aGUNCj4gICAgIHRyYWNr ZXIgcHJvdG9jb2w/IEkuZS4sIHRvIGdpdmUgYSByZWFzb25pbmcgd2h5IGl0IGlzIHJlcXVpcmVk Pw0KPiBbWXVuZmVpXSBNeSBpbnRlbnRpb24gdG8gZGlzY3VzcyB0aGUgY2FuZGlkYXRlcyBpbiB0 aGlzDQo+ICAgICBkcmFmdCBpcyB0byByZXBseSBEYXZpZCBIYXJyaW5ndG9uJ3MgSUVTRyByZXZp ZXcgb24gdGhlIHRhc2tzIG9mIHRoZSANCj4gdHJhY2tlciBwcm90b2NvbCwgYXMgeW91IGFsc28g bWVudGlvbmVkLg0KPiAgICBTaW5jZSB3ZSBoYXZlIHBvaW50ZWQgb3V0IHRoZSBwcm9ibGVtcyBj dXJyZW50IHByb3RvY29scyBoYXZlLCBpbiBteSANCj4gaW5pdGlhbCB0aG91Z2h0cyAobWF5YmUg SSBhbSB3cm9uZyksIEkgdGhpbmsgaW4gdGhpcw0KPiBzZWN0aW9uIHdlIG1heSBuZWVkIHRoZSBk aXNjdXNzIHRoZSBjYW5kaWRhdGVzIG9mIHRoZSBwcm90b2NvbHMsIHNpbmNlIA0KPiB0aGUgcHJv dG9jb2wgZGVzaWduIGlzIHRoZSBtYWluIHRhc2tzIG9mDQo+IHRoZSBXRy4gTWF5IEkgZnVydGhl ciBhc2sgeW91ciBpbWFnaW5hdGlvbnMgb24gdGhlIGNvbnRlbnQgb2YgdGhpcyBwYXJ0IA0KPiBp biBkZXRhaWw/IEl0IHdvdWxkIGJlIG11Y2ggaGVscGZ1bCBmb3Igd3JpdGluZyB0aGlzIHBhcnQu DQoNClRoZXJlIGNhbiBiZSB2YXJpb3VzIG9waW5pb25zIGFib3V0IHdoZXRoZXIgc3VjaCBzZWN0 aW9uIGlzIHVzZWZ1bCBpbg0KdGhpcyBkcmFmdCBvciBub3QuIEkgZG8gbm90IGZpbmQgaXQgdXNl ZnVsIGhlcmUsIGJ1dCBJIGRvIG5vdCBvYmplY3QgdG8NCmtlZXAgaXQgaW4sIGlmIHRoZSBXRyB3 YW50cyB0byBoYXZlIGl0Lg0KDQpJIGFtIGp1c3Qgd29uZGVyaW5nLCBpZiBhIGhpZ2gtbGV2ZWwg dGV4dCBhYm91dCBnZW5lcmFsIGZ1bmN0aW9uYWxpdHkgb2YNCnRoZSB0cmFja2VyIHByb3RvY29s IGlzICBwcm9iYWJseSBsaW5rZWQgdG8gdGhlIHJlcXVpcmVtZW50cyBsYXRlciBvbiwNCndvdWxk IGJlIHVzZWZ1bD8NCg0KW1l1bmZlaV0gSSBsaWtlIHRoaXMgcHJvcG9zYWwuIElzIGl0IGJldHRl ciB0byBzaG9ydGVuIHNlY3Rpb24gNCBtb3ZpbmcgYWxsIHRoZSBwcm90b2NvbCBjYW5kaWRhdGVz IGRpc2N1c3Npb24gYW5kIGp1c3QgbGVhdmluZyB0aGUgaGlnaC1sZXZlbCBmdW5jdGlvbmFsIGRl c2NyaXB0aW9ucyBvZiB0aGUgdHJhY2tlciBhbmQgcGVlciBwcm90b2NvbCggSSBhbSBub3Qgc3Vy ZSBpZiB3ZSBuZWVkIHNvbWUgZmluZSBncmFudWxhcml0eSBkZXNjcmlwdGlvbiwgc2F5LCBnZW5l cmFsIGluZm9ybWF0aW9uIGluIHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2wpIGFuZCBtb3ZlIHRo aXMgc2VjdGlvbiBhZnRlciB0aGUgdXNlIGNhc2VzLg== ------=_001_NextPart037678867412_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Martin,
    Thanks for the quick response. It's really helpful= for=20 us to understand more the IESG thoughts in general from your=20 reply. Just same as you, I just want to confirm with you the ope= n=20 issues left. Thanks again.
 
BR
Yunfei
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Martin=20 Stiemerling
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-09-24 21:23
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei
=B3=AD=CB=CD=A3=BA ppsp<= /A>; ZongNing
=D6=F7=CC=E2=A3=BA Re: [ppsp] An early AD review of=20 draft-ietf-ppsp-problem-statement-10.txt
> Section 3.2., paragraph 3:
>   >    section 3.1,&n= bsp;proprietary P2P protocols introduce complexity&nbs= p;between
>   >    peers and = ;CDN trackers because the CDN trackers need&= nbsp;to identify each
>   >    different P2P&= nbsp;streaming protocol. This increases the deplo= yment cost
>   >    of CDN.
>     I do not understand&= nbsp;the issue here. First of all, all = the different
>     p2p streaming systems&nbs= p;could use a common tracker protocol. Secon= d,
>     how does the above&n= bsp;text relate to latency issues? Third, ev= en if
>     there are multiple, = different tracker protocols what is this rel= ated
>     to in this section?<= /DIV>
> [Yunfei] What I mean is that = *before* we design and implement PPSP, 
> different P2P streaming
> systems have to use different prot= ocols. 
 
This I can easily understand and it&nbs= p;would be good to separate it from
the latency, e.g., making a new paragra= ph afterwards.
 
 
 
 
Second, for the latency issue,
> it is because the introduction of&= nbsp;*CDN* nodes
> inside the p2p streaming delivery = reduce the latency (see in the 
> reference in the text for detail).=  The problem is that the CDN must = be 
> aware of the specific p2p streamin= g protocol in order to form the hybrid&= nbsp;
> p2p+cdn architecture, which can lead&nb= sp;to a shorter latency from the 
> users' perspective.
 
Can you add this text, you just pr= oposed here, of course adapted to the
text flow? This helps a lot to und= erstand the improvement of the latency.
 
[Yunfei] Does it make sense that we describe= the CDN=20 problem in only one subsection, but in the beginning of this subsection, t= o=20 clarify that the main purpose of using CDN is to reduce the latency(i.e.,=20 accelerate the speed)?After that,
we state the problem is that=20 the CDN must be aware of the specific&n= bsp;p2p streaming protocol in order to form&= nbsp;the hybrid =20 p2p+cdn architecture but we don't involve much of the description abo= ut the=20 roles, like tracker or peer....Will this look more
clear?
 
> Section 4.1., paragraph 0:
>    4.1. Tracker protocol cand= idates discussion and design issues
>     Why is there the&nbs= p;need to discuss the candidates in this
>     draft? Wouldn't it b= e better to roughly sketch the task of&= nbsp;the
>     tracker protocol? I.e.,&n= bsp;to give a reasoning why it is requi= red?
> [Yunfei] My intention to discuss t= he candidates in this
>     draft is to reply&nb= sp;David Harrington's IESG review on the tas= ks of the 
> tracker protocol, as you also ment= ioned.
>    Since we have pointed = ;out the problems current protocols have, in=  my 
> initial thoughts (maybe I am wrong= ), I think in this
> section we may need the discuss&nb= sp;the candidates of the protocols, since 
> the protocol design is the main&nb= sp;tasks of
> the WG. May I further ask you= r imaginations on the content of this p= art 
> in detail? It would be much h= elpful for writing this part.
 
There can be various opinions about whe= ther such section is useful in
this draft or not. I do not find&n= bsp;it useful here, but I do not object=  to
keep it in, if the WG wants to&nbs= p;have it.
 
I am just wondering, if a high-level&nb= sp;text about general functionality of
the tracker protocol is  probably linke= d to the requirements later on,
would be useful?
 
[Yunfei] I like this proposal. Is it better = to=20 shorten section 4 moving all the protocol candidates discussion and just l= eaving=20 the high-level functional descriptions of the tracker and peer protocol( I= am=20 not sure if we need some fine granularity description, say, general=20 information in tracker and peer protocol) and move this section after the = use=20 cases.
 
 
------=_001_NextPart037678867412_=------ From Martin.Stiemerling@neclab.eu Wed Sep 26 23:53:43 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA9921F86A2 for ; Wed, 26 Sep 2012 23:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuirlgjmmAUG for ; Wed, 26 Sep 2012 23:53:43 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 01FC221F86A3 for ; Wed, 26 Sep 2012 23:53:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E052F101F36; Thu, 27 Sep 2012 08:53:41 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeSu8Qtu9hAv; Thu, 27 Sep 2012 08:53:41 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id C4D66101F3C; Thu, 27 Sep 2012 08:53:31 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 27 Sep 2012 08:53:31 +0200 Message-ID: <5063DA38.9020705@neclab.eu> Date: Thu, 27 Sep 2012 06:46:48 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Zongning References: <505C70EF.6040000@neclab.eu> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Cc: "ppsp@ietf.org" Subject: Re: [ppsp] An early AD review of draft-ietf-ppsp-problem-statement-10.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 06:53:44 -0000 Hi Ning, Replying only the open issues: On 09/24/2012 12:54 PM, Zongning wrote: [...] >> >> Section 6.1., paragraph 0: >> >> 6.1. Basic Requirements >> >> Many of the requirements listed here are not basic requirements >> but already very specific requirements that belong in other >> sections. E.g., the peer ID belongs IMHO into the peer section. >> >> >> Section 6.1., paragraph 1: >> >> > PPSP.REQ-1: The tracker and the peer protocol SHOULD allow peers to >> > receive streaming content within the required time constraints. >> >> This not a protocol requirement, as it is not specifying something >> we can qualify later on. > > [Ning] There was discuss about if we should include requirements not only to protocols, but also to P2P streaming system. The previous consensus was yes. But anyway I can add clarification later on. A clarification would help and if you go for such a requirement, I would replace the SHOULD by a MUST. > >> >> >> Section 6.1., paragraph 7: >> >> > A key characteristic of P2P streaming system is allowing the data >> > fetching from different peers concurrently. Therefore, the whole >> > streaming content must allow to be partitioned into small pieces or >> > chunks for transmission between peers. >> >> This seems to be more a prerequisite instead of a protocol >> requirement. >> > > [Ning] Same as above item. I can add clarification. Ok. > >> >> Section 6.1., paragraph 10: >> >> > PPSP.REQ-6: The tracker protocol and peer protocol are recommended >> to >> > be carried over TCP or UDP. >> >> No 'MUST' or 'SHOULD' like the other requirements? Why is there >> only a single requirements for both protocols, i.e., for the peer >> protocol and the tracker protocol? Shouldn't this at least be 2 >> separated requirements? >> >> > > [Ning] I will separate it to two requirements. Good and take care that you say what of this is MUST/SHOULD/etc. > >> Section 6.1., paragraph 11: >> >> > PPSP.REQ-7: The tracker and peer protocol together MUST facilitate >> > acceptable QoS (e.g. low startup delay, low channel/content switching >> > time and minimal end-to-end delay) for both live and VoD streaming >> > even for very popular content. The tracker and peer protocol do not >> > include the algorithm required for scalable streaming. However, the >> > tracker and peer protocol SHALL NOT restrict or place limits on any >> > such algorithm. >> >> This requirement is at least listing 2 requirements. Something about >> QoS and the limits of the algorithm. QoS is again hard to qualify >> and if you want to say something about this, I would suggest to >> not make a requirement, but to add explanatory text about this, >> like you have below this. >> > > [Ning] Again I think this belongs to P2P system requirements. I will add some clarification. Ok, but I am not sure about the QoS, as this requirement is hard to double-check, i.e., what is acceptable. It is good to state this in the draft, but I am not sure that this is a technically verifiable requirement. It would if you say that the startup delay must be under x seconds, etc. However, I do not see how we can set good values here at this stage. > >> >> Section 6.2., paragraph 3: >> >> > PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for >> > sending queries and periodical peer status reports/updates to the >> > tracker and receiving the corresponding replies. >> >> How about instead of 'The peer' 'A PPSP peer'? This seems to be >> not a requirement for the tracker (i.e., wrong section), but a >> requirement for a peer. >> >> > > [Ning] This is requirement on the protocol between peer and tracker, which include both peer and tracker (nodes). I can try to re-phrase the sentence to make it more clear. It is ok, I got confused on this one. I would only suggest to replace 'The peer' by 'A PPSP peer'. > >> >> Section 6.2., paragraph 12: >> >> > PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the >> > tracker when tracker needs such information in order to steer peer >> > selection. >> >> This implies that the tracker protocol is not a pure request/response >> protocol from the peer's perspective, isn't it? Any though about this one? Thanks, Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Martin.Stiemerling@neclab.eu Fri Sep 28 01:58:29 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26E621F849D for ; Fri, 28 Sep 2012 01:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.813 X-Spam-Level: X-Spam-Status: No, score=-98.813 tagged_above=-999 required=5 tests=[AWL=-3.509, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0oiuQ1+2HSF for ; Fri, 28 Sep 2012 01:58:29 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id DED7321F8496 for ; Fri, 28 Sep 2012 01:58:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0679D101F9B; Fri, 28 Sep 2012 10:58:27 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M3sf3ED9agQ; Fri, 28 Sep 2012 10:58:26 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id DEC97101F95; Fri, 28 Sep 2012 10:58:11 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 28 Sep 2012 10:57:48 +0200 Message-ID: <506566A3.3020005@neclab.eu> Date: Fri, 28 Sep 2012 10:58:11 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: zhangyunfei References: <505C70EF.6040000@neclab.eu> <2012092411122153407042@chinamobile.com>, <50605EC9.4060507@neclab.eu> <20120925104100729123232@chinamobile.com> In-Reply-To: <20120925104100729123232@chinamobile.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.1.1.190] Cc: ppsp Subject: Re: [ppsp] =?gb2312?b?u9i4tDogUmU6ICBBbiBlYXJseSBBRCByZXZpZXcgb2Yg?= =?gb2312?b?ZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTEwLnR4dA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 08:58:30 -0000 Hello Yunfei, On 09/25/2012 04:41 AM, zhangyunfei wrote: > Hi Martin, > Thanks for the quick response. It's really helpful for us to > understand more the IESG thoughts in general from your reply. Just same > as you, I just want to confirm with you the open issues left. Thanks again. > BR > Yunfei > ------------------------------------------------------------------------ > zhangyunfei > *发件人：* Martin Stiemerling > *发送时间：* 2012-09-24 21:23 > *收件人：* zhangyunfei > *抄送：* ppsp ; ZongNing > *主题：* Re: [ppsp] An early AD review of > draft-ietf-ppsp-problem-statement-10.txt > > Section 3.2., paragraph 3: > > > section 3.1, proprietary P2P protocols introduce complexity between > > > peers and CDN trackers because the CDN trackers need to identify each > > > different P2P streaming protocol. This increases the deployment cost > > > of CDN. > > I do not understand the issue here. First of all, all the different > > p2p streaming systems could use a common tracker protocol. Second, > > how does the above text relate to latency issues? Third, even if > > there are multiple, different tracker protocols what is this related > > to in this section? > > [Yunfei] What I mean is that *before* we design and implement PPSP, > > different P2P streaming > > systems have to use different protocols. > This I can easily understand and it would be good to separate it from > the latency, e.g., making a new paragraph afterwards. > Second, for the latency issue, > > it is because the introduction of *CDN* nodes > > inside the p2p streaming delivery reduce the latency (see in the > > reference in the text for detail). The problem is that the CDN must be > > aware of the specific p2p streaming protocol in order to form the hybrid > > p2p+cdn architecture, which can lead to a shorter latency from the > > users' perspective. > Can you add this text, you just proposed here, of course adapted to the > text flow? This helps a lot to understand the improvement of the latency. > [Yunfei] Does it make sense that we describe the CDN problem in only one > subsection, but in the beginning of this subsection, to clarify that the > main purpose of using CDN is to reduce the latency(i.e., accelerate the > speed)?After that, > we state the problem is that > the CDN must be aware of the specific p2p streaming protocol in order to form the hybrid > p2p+cdn architecture but we don't involve much of the description about > the roles, like tracker or peer....Will this look more > clear? This is a good proposal! > > Section 4.1., paragraph 0: > > 4.1. Tracker protocol candidates discussion and design issues > > Why is there the need to discuss the candidates in this > > draft? Wouldn't it be better to roughly sketch the task of the > > tracker protocol? I.e., to give a reasoning why it is required? > > [Yunfei] My intention to discuss the candidates in this > > draft is to reply David Harrington's IESG review on the tasks of the > > tracker protocol, as you also mentioned. > > Since we have pointed out the problems current protocols have, in my > > initial thoughts (maybe I am wrong), I think in this > > section we may need the discuss the candidates of the protocols, since > > the protocol design is the main tasks of > > the WG. May I further ask your imaginations on the content of this part > > in detail? It would be much helpful for writing this part. > There can be various opinions about whether such section is useful in > this draft or not. I do not find it useful here, but I do not object to > keep it in, if the WG wants to have it. > I am just wondering, if a high-level text about general functionality of > the tracker protocol is probably linked to the requirements later on, > would be useful? > [Yunfei] I like this proposal. Is it better to shorten section 4 moving > all the protocol candidates discussion and just leaving the high-level > functional descriptions of the tracker and peer protocol( I am not sure > if we need some fine granularity description, say, general information > in tracker and peer protocol) and move this section after the use cases. high-level description should do the job here in this draft. Regards, Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From zhangyunfei@chinamobile.com Fri Sep 28 02:17:02 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF2321F8516 for ; Fri, 28 Sep 2012 02:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.262 X-Spam-Level: X-Spam-Status: No, score=-93.262 tagged_above=-999 required=5 tests=[AWL=-1.934, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrpz2L2OG60x for ; Fri, 28 Sep 2012 02:17:01 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9B2C21F84F3 for ; Fri, 28 Sep 2012 02:17:00 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 8D80DE4A5; Fri, 28 Sep 2012 17:16:54 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 9CF2CE6E0; Fri, 28 Sep 2012 17:16:05 +0800 (CST) Received: from zyf-PC ([10.2.52.192]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012092817160366-20842 ; Fri, 28 Sep 2012 17:16:03 +0800 Date: Fri, 28 Sep 2012 17:15:52 +0800 From: zhangyunfei To: "Martin Stiemerling" References: <505C70EF.6040000@neclab.eu> <2012092411122153407042@chinamobile.com>, <50605EC9.4060507@neclab.eu> <20120925104100729123232@chinamobile.com>, <506566A3.3020005@neclab.eu> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012092817155199343216@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-28 17:16:03, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-09-28 17:16:05, Serialize complete at 2012-09-28 17:16:05 Content-Type: multipart/alternative; boundary="----=_001_NextPart156252446058_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19216.006 X-TM-AS-Result: No--47.250-7.0-31-10 X-imss-scan-details: No--47.250-7.0-31-10;No--47.250-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: [ppsp] =?gb2312?b?u9i4tDogUmU6ICBBbiBlYXJseSBBRCByZXZpZXcgb2Yg?= =?gb2312?b?ZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTEwLnR4?= =?gb2312?b?dA==?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2012 09:17:02 -0000 This is a multi-part message in MIME format. ------=_001_NextPart156252446058_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" VGhhbmtzIE1hcnRpbi4gSSdsbCB1cGRhdGUgdGhlIHRleHQgYWNjb3JkaW5nIHRvIHlvdXIgc3Vn Z2VzdGlvbnMuDQoNCkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0Kt6K8/sjLo7og TWFydGluIFN0aWVtZXJsaW5nDQq3osvNyrG85KO6IDIwMTItMDktMjggMTY6NTgNCsrVvP7Iy6O6 IHpoYW5neXVuZmVpDQqzrcvNo7ogcHBzcDsgWm9uZ05pbmcNCtb3zOKjuiBSZTq72Li0OiBSZTog W3Bwc3BdIEFuIGVhcmx5IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0 ZW1lbnQtMTAudHh0DQpIZWxsbyBZdW5mZWksDQoNCk9uIDA5LzI1LzIwMTIgMDQ6NDEgQU0sIHpo YW5neXVuZmVpIHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+ICAgICAgVGhhbmtzIGZvciB0aGUgcXVp Y2sgcmVzcG9uc2UuIEl0J3MgcmVhbGx5IGhlbHBmdWwgZm9yIHVzIHRvIA0KPiB1bmRlcnN0YW5k IG1vcmUgdGhlIElFU0cgdGhvdWdodHMgaW4gZ2VuZXJhbCBmcm9tIHlvdXIgcmVwbHkuIEp1c3Qg c2FtZSANCj4gYXMgeW91LCBJIGp1c3Qgd2FudCB0byBjb25maXJtIHdpdGggeW91IHRoZSBvcGVu IGlzc3VlcyBsZWZ0LiBUaGFua3MgYWdhaW4uDQo+IEJSDQo+IFl1bmZlaQ0KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gemhhbmd5dW5mZWkNCj4gKreivP7Iy6O6KiBNYXJ0aW4gU3RpZW1lcmxpbmcgPG1h aWx0bzptYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1Pg0KPiAqt6LLzcqxvOSjuiogMjAxMi0w OS0yNCAyMToyMw0KPiAqytW8/sjLo7oqIHpoYW5neXVuZmVpIDxtYWlsdG86emhhbmd5dW5mZWlA Y2hpbmFtb2JpbGUuY29tPg0KPiAqs63LzaO6KiBwcHNwIDxtYWlsdG86cHBzcEBpZXRmLm9yZz47 IFpvbmdOaW5nIDxtYWlsdG86em9uZ25pbmdAaHVhd2VpLmNvbT4NCj4gKtb3zOKjuiogUmU6IFtw cHNwXSBBbiBlYXJseSBBRCByZXZpZXcgb2YgDQo+IGRyYWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0 YXRlbWVudC0xMC50eHQNCj4gID4gU2VjdGlvbiAzLjIuLCBwYXJhZ3JhcGggMzoNCj4gID4gICA+ ICAgIHNlY3Rpb24gMy4xLCBwcm9wcmlldGFyeSBQMlAgcHJvdG9jb2xzIGludHJvZHVjZSBjb21w bGV4aXR5IGJldHdlZW4NCj4gID4gICA+ICAgIHBlZXJzIGFuZCBDRE4gdHJhY2tlcnMgYmVjYXVz ZSB0aGUgQ0ROIHRyYWNrZXJzIG5lZWQgdG8gaWRlbnRpZnkgZWFjaA0KPiAgPiAgID4gICAgZGlm ZmVyZW50IFAyUCBzdHJlYW1pbmcgcHJvdG9jb2wuIFRoaXMgaW5jcmVhc2VzIHRoZSBkZXBsb3lt ZW50IGNvc3QNCj4gID4gICA+ICAgIG9mIENETi4NCj4gID4gICAgIEkgZG8gbm90IHVuZGVyc3Rh bmQgdGhlIGlzc3VlIGhlcmUuIEZpcnN0IG9mIGFsbCwgYWxsIHRoZSBkaWZmZXJlbnQNCj4gID4g ICAgIHAycCBzdHJlYW1pbmcgc3lzdGVtcyBjb3VsZCB1c2UgYSBjb21tb24gdHJhY2tlciBwcm90 b2NvbC4gU2Vjb25kLA0KPiAgPiAgICAgaG93IGRvZXMgdGhlIGFib3ZlIHRleHQgcmVsYXRlIHRv IGxhdGVuY3kgaXNzdWVzPyBUaGlyZCwgZXZlbiBpZg0KPiAgPiAgICAgdGhlcmUgYXJlIG11bHRp cGxlLCBkaWZmZXJlbnQgdHJhY2tlciBwcm90b2NvbHMgd2hhdCBpcyB0aGlzIHJlbGF0ZWQNCj4g ID4gICAgIHRvIGluIHRoaXMgc2VjdGlvbj8NCj4gID4gW1l1bmZlaV0gV2hhdCBJIG1lYW4gaXMg dGhhdCAqYmVmb3JlKiB3ZSBkZXNpZ24gYW5kIGltcGxlbWVudCBQUFNQLA0KPiAgPiBkaWZmZXJl bnQgUDJQIHN0cmVhbWluZw0KPiAgPiBzeXN0ZW1zIGhhdmUgdG8gdXNlIGRpZmZlcmVudCBwcm90 b2NvbHMuDQo+IFRoaXMgSSBjYW4gZWFzaWx5IHVuZGVyc3RhbmQgYW5kIGl0IHdvdWxkIGJlIGdv b2QgdG8gc2VwYXJhdGUgaXQgZnJvbQ0KPiB0aGUgbGF0ZW5jeSwgZS5nLiwgbWFraW5nIGEgbmV3 IHBhcmFncmFwaCBhZnRlcndhcmRzLg0KPiBTZWNvbmQsIGZvciB0aGUgbGF0ZW5jeSBpc3N1ZSwN Cj4gID4gaXQgaXMgYmVjYXVzZSB0aGUgaW50cm9kdWN0aW9uIG9mICpDRE4qIG5vZGVzDQo+ICA+ IGluc2lkZSB0aGUgcDJwIHN0cmVhbWluZyBkZWxpdmVyeSByZWR1Y2UgdGhlIGxhdGVuY3kgKHNl ZSBpbiB0aGUNCj4gID4gcmVmZXJlbmNlIGluIHRoZSB0ZXh0IGZvciBkZXRhaWwpLiBUaGUgcHJv YmxlbSBpcyB0aGF0IHRoZSBDRE4gbXVzdCBiZQ0KPiAgPiBhd2FyZSBvZiB0aGUgc3BlY2lmaWMg cDJwIHN0cmVhbWluZyBwcm90b2NvbCBpbiBvcmRlciB0byBmb3JtIHRoZSBoeWJyaWQNCj4gID4g cDJwK2NkbiBhcmNoaXRlY3R1cmUsIHdoaWNoIGNhbiBsZWFkIHRvIGEgc2hvcnRlciBsYXRlbmN5 IGZyb20gdGhlDQo+ICA+IHVzZXJzJyBwZXJzcGVjdGl2ZS4NCj4gQ2FuIHlvdSBhZGQgdGhpcyB0 ZXh0LCB5b3UganVzdCBwcm9wb3NlZCBoZXJlLCBvZiBjb3Vyc2UgYWRhcHRlZCB0byB0aGUNCj4g dGV4dCBmbG93PyBUaGlzIGhlbHBzIGEgbG90IHRvIHVuZGVyc3RhbmQgdGhlIGltcHJvdmVtZW50 IG9mIHRoZSBsYXRlbmN5Lg0KPiBbWXVuZmVpXSBEb2VzIGl0IG1ha2Ugc2Vuc2UgdGhhdCB3ZSBk ZXNjcmliZSB0aGUgQ0ROIHByb2JsZW0gaW4gb25seSBvbmUgDQo+IHN1YnNlY3Rpb24sIGJ1dCBp biB0aGUgYmVnaW5uaW5nIG9mIHRoaXMgc3Vic2VjdGlvbiwgdG8gY2xhcmlmeSB0aGF0IHRoZSAN Cj4gbWFpbiBwdXJwb3NlIG9mIHVzaW5nIENETiBpcyB0byByZWR1Y2UgdGhlIGxhdGVuY3koaS5l LiwgYWNjZWxlcmF0ZSB0aGUgDQo+IHNwZWVkKT9BZnRlciB0aGF0LA0KPiB3ZSBzdGF0ZSB0aGUg cHJvYmxlbSBpcyB0aGF0IA0KPiB0aGUgQ0ROIG11c3QgYmUgYXdhcmUgb2YgdGhlIHNwZWNpZmlj IHAycCBzdHJlYW1pbmcgcHJvdG9jb2wgaW4gb3JkZXIgdG8gZm9ybSB0aGUgaHlicmlkIA0KPiBw MnArY2RuIGFyY2hpdGVjdHVyZSBidXQgd2UgZG9uJ3QgaW52b2x2ZSBtdWNoIG9mIHRoZSBkZXNj cmlwdGlvbiBhYm91dCANCj4gdGhlIHJvbGVzLCBsaWtlIHRyYWNrZXIgb3IgcGVlci4uLi5XaWxs IHRoaXMgbG9vayBtb3JlDQo+IGNsZWFyPw0KDQpUaGlzIGlzIGEgZ29vZCBwcm9wb3NhbCENCg0K PiAgPiBTZWN0aW9uIDQuMS4sIHBhcmFncmFwaCAwOg0KPiAgPiAgICA0LjEuIFRyYWNrZXIgcHJv dG9jb2wgY2FuZGlkYXRlcyBkaXNjdXNzaW9uIGFuZCBkZXNpZ24gaXNzdWVzDQo+ICA+ICAgICBX aHkgaXMgdGhlcmUgdGhlIG5lZWQgdG8gZGlzY3VzcyB0aGUgY2FuZGlkYXRlcyBpbiB0aGlzDQo+ ICA+ICAgICBkcmFmdD8gV291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIHJvdWdobHkgc2tldGNoIHRo ZSB0YXNrIG9mIHRoZQ0KPiAgPiAgICAgdHJhY2tlciBwcm90b2NvbD8gSS5lLiwgdG8gZ2l2ZSBh IHJlYXNvbmluZyB3aHkgaXQgaXMgcmVxdWlyZWQ/DQo+ICA+IFtZdW5mZWldIE15IGludGVudGlv biB0byBkaXNjdXNzIHRoZSBjYW5kaWRhdGVzIGluIHRoaXMNCj4gID4gICAgIGRyYWZ0IGlzIHRv IHJlcGx5IERhdmlkIEhhcnJpbmd0b24ncyBJRVNHIHJldmlldyBvbiB0aGUgdGFza3Mgb2YgdGhl DQo+ICA+IHRyYWNrZXIgcHJvdG9jb2wsIGFzIHlvdSBhbHNvIG1lbnRpb25lZC4NCj4gID4gICAg U2luY2Ugd2UgaGF2ZSBwb2ludGVkIG91dCB0aGUgcHJvYmxlbXMgY3VycmVudCBwcm90b2NvbHMg aGF2ZSwgaW4gbXkNCj4gID4gaW5pdGlhbCB0aG91Z2h0cyAobWF5YmUgSSBhbSB3cm9uZyksIEkg dGhpbmsgaW4gdGhpcw0KPiAgPiBzZWN0aW9uIHdlIG1heSBuZWVkIHRoZSBkaXNjdXNzIHRoZSBj YW5kaWRhdGVzIG9mIHRoZSBwcm90b2NvbHMsIHNpbmNlDQo+ICA+IHRoZSBwcm90b2NvbCBkZXNp Z24gaXMgdGhlIG1haW4gdGFza3Mgb2YNCj4gID4gdGhlIFdHLiBNYXkgSSBmdXJ0aGVyIGFzayB5 b3VyIGltYWdpbmF0aW9ucyBvbiB0aGUgY29udGVudCBvZiB0aGlzIHBhcnQNCj4gID4gaW4gZGV0 YWlsPyBJdCB3b3VsZCBiZSBtdWNoIGhlbHBmdWwgZm9yIHdyaXRpbmcgdGhpcyBwYXJ0Lg0KPiBU aGVyZSBjYW4gYmUgdmFyaW91cyBvcGluaW9ucyBhYm91dCB3aGV0aGVyIHN1Y2ggc2VjdGlvbiBp cyB1c2VmdWwgaW4NCj4gdGhpcyBkcmFmdCBvciBub3QuIEkgZG8gbm90IGZpbmQgaXQgdXNlZnVs IGhlcmUsIGJ1dCBJIGRvIG5vdCBvYmplY3QgdG8NCj4ga2VlcCBpdCBpbiwgaWYgdGhlIFdHIHdh bnRzIHRvIGhhdmUgaXQuDQo+IEkgYW0ganVzdCB3b25kZXJpbmcsIGlmIGEgaGlnaC1sZXZlbCB0 ZXh0IGFib3V0IGdlbmVyYWwgZnVuY3Rpb25hbGl0eSBvZg0KPiB0aGUgdHJhY2tlciBwcm90b2Nv bCBpcyAgcHJvYmFibHkgbGlua2VkIHRvIHRoZSByZXF1aXJlbWVudHMgbGF0ZXIgb24sDQo+IHdv dWxkIGJlIHVzZWZ1bD8NCj4gW1l1bmZlaV0gSSBsaWtlIHRoaXMgcHJvcG9zYWwuIElzIGl0IGJl dHRlciB0byBzaG9ydGVuIHNlY3Rpb24gNCBtb3ZpbmcgDQo+IGFsbCB0aGUgcHJvdG9jb2wgY2Fu ZGlkYXRlcyBkaXNjdXNzaW9uIGFuZCBqdXN0IGxlYXZpbmcgdGhlIGhpZ2gtbGV2ZWwgDQo+IGZ1 bmN0aW9uYWwgZGVzY3JpcHRpb25zIG9mIHRoZSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sKCBJ IGFtIG5vdCBzdXJlIA0KPiBpZiB3ZSBuZWVkIHNvbWUgZmluZSBncmFudWxhcml0eSBkZXNjcmlw dGlvbiwgc2F5LCBnZW5lcmFsIGluZm9ybWF0aW9uIA0KPiBpbiB0cmFja2VyIGFuZCBwZWVyIHBy b3RvY29sKSBhbmQgbW92ZSB0aGlzIHNlY3Rpb24gYWZ0ZXIgdGhlIHVzZSBjYXNlcy4NCg0KaGln aC1sZXZlbCBkZXNjcmlwdGlvbiBzaG91bGQgZG8gdGhlIGpvYiBoZXJlIGluIHRoaXMgZHJhZnQu DQoNClJlZ2FyZHMsDQoNCiAgTWFydGluDQoNCi0tIA0KbWFydGluLnN0aWVtZXJsaW5nQG5lY2xh Yi5ldQ0KDQpORUMgTGFib3JhdG9yaWVzIEV1cm9wZSAtIE5ldHdvcmsgUmVzZWFyY2ggRGl2aXNp b24gTkVDIEV1cm9wZSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZp Y3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODM= ------=_001_NextPart156252446058_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Thanks Martin. I'll update the text according to your suggestions.
 
BR
Yunfei
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Martin=20 Stiemerling
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-09-28 16:58
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei
=B3=AD=CB=CD=A3=BA ppsp<= /A>; ZongNing
=D6=F7=CC=E2=A3=BA Re:=BB=D8=B8=B4: Re: [ppsp] An early A= D review of=20 draft-ietf-ppsp-problem-statement-10.txt
Hello Yunfei,
 
On 09/25/2012 04:41 AM, zhangyunfei wrote:
> Hi Martin,
>      Thanks for the = ;quick response. It's really helpful for us&= nbsp;to 
> understand more the IESG thoughts = in general from your reply. Just same <= /DIV>
> as you, I just want to confir= m with you the open issues left. Thanks=  again.
> BR
> Yunfei
> -----------------------------------------------------------= -------------
> zhangyunfei
> *=B7=A2=BC=FE=C8=CB=A3=BA* Martin Stiemerling&nbs= p;<mailto:martin.stiemerling@neclab.eu>
> *=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA* 2012-09-24 21:23=
> *=CA=D5=BC=FE=C8=CB=A3=BA* zhangyunfei <mailto= :zhangyunfei@chinamobile.com>
> *=B3=AD=CB=CD=A3=BA* ppsp <mailto:ppsp@ietf.or= g>; ZongNing <mailto:zongning@huawei.com>
> *=D6=F7=CC=E2=A3=BA* Re: [ppsp] An earl= y AD review of 
> draft-ietf-ppsp-problem-statement-10.txt
>  > Section 3.2., paragraph 3:
>  >   >    sec= tion 3.1, proprietary P2P protocols introduce&nbs= p;complexity between
>  >   >    pee= rs and CDN trackers because the CDN tra= ckers need to identify each
>  >   >    dif= ferent P2P streaming protocol. This increases&nbs= p;the deployment cost
>  >   >    of&= nbsp;CDN.
>  >     I do not&= nbsp;understand the issue here. First of all= , all the different
>  >     p2p streaming&= nbsp;systems could use a common tracker prot= ocol. Second,
>  >     how does = the above text relate to latency issues?&nbs= p;Third, even if
>  >     there are = ;multiple, different tracker protocols what is&nb= sp;this related
>  >     to in thi= s section?
>  > [Yunfei] What I mean is=  that *before* we design and implement = PPSP,
>  > different P2P streaming
>  > systems have to use dif= ferent protocols.
> This I can easily understand and&n= bsp;it would be good to separate it fro= m
> the latency, e.g., making a new&nb= sp;paragraph afterwards.
> Second, for the latency issue,
>  > it is because the intro= duction of *CDN* nodes
>  > inside the p2p streaming&nbs= p;delivery reduce the latency (see in the
>  > reference in the text f= or detail). The problem is that the CDN=  must be
>  > aware of the specific p= 2p streaming protocol in order to form = the hybrid
>  > p2p+cdn architecture, which = can lead to a shorter latency from the<= /DIV>
>  > users' perspective.
> Can you add this text, you ju= st proposed here, of course adapted to = the
> text flow? This helps a lot t= o understand the improvement of the latency.=
> [Yunfei] Does it make sense that&n= bsp;we describe the CDN problem in only = ;one 
> subsection, but in the beginning o= f this subsection, to clarify that the =
> main purpose of using CDN is = to reduce the latency(i.e., accelerate the <= /DIV>
> speed)?After that,
> we state the problem is that =
> the CDN must be aware of the&= nbsp;specific p2p streaming protocol in order&nbs= p;to form the hybrid 
> p2p+cdn architecture but we don't = involve much of the description about 
> the roles, like tracker or peer...= .Will this look more
> clear?
 
This is a good proposal!
 
>  > Section 4.1., paragraph 0:
>  >    4.1. Tracker pr= otocol candidates discussion and design issues
>  >     Why is th= ere the need to discuss the candidates = in this
>  >     draft? Wouldn'= t it be better to roughly sketch the&nb= sp;task of the
>  >     tracker protoc= ol? I.e., to give a reasoning why it&nb= sp;is required?
>  > [Yunfei] My intention to&nbs= p;discuss the candidates in this
>  >     draft is = to reply David Harrington's IESG review on&n= bsp;the tasks of the
>  > tracker protocol, as you&nbs= p;also mentioned.
>  >    Since we have&n= bsp;pointed out the problems current protocols&nb= sp;have, in my
>  > initial thoughts (maybe I&nb= sp;am wrong), I think in this
>  > section we may need the=  discuss the candidates of the protocols,&nb= sp;since
>  > the protocol design is = the main tasks of
>  > the WG. May I further&n= bsp;ask your imaginations on the content of&= nbsp;this part
>  > in detail? It would be&= nbsp;much helpful for writing this part.
> There can be various opinions abou= t whether such section is useful in
> this draft or not. I do not&n= bsp;find it useful here, but I do not&n= bsp;object to
> keep it in, if the WG wants&n= bsp;to have it.
> I am just wondering, if a hig= h-level text about general functionality of
> the tracker protocol is  probably&= nbsp;linked to the requirements later on,
> would be useful?
> [Yunfei] I like this proposal. Is&= nbsp;it better to shorten section 4 moving&n= bsp;
> all the protocol candidates discussion&= nbsp;and just leaving the high-level 
> functional descriptions of the tracker&= nbsp;and peer protocol( I am not sure <= /DIV>
> if we need some fine granularity&n= bsp;description, say, general information 
> in tracker and peer protocol) and&= nbsp;move this section after the use cases.<= /DIV>
 
high-level description should do the job&nbs= p;here in this draft.
 
Regards,
 
  Martin
 
-- 
martin.stiemerling@neclab.eu
 
NEC Laboratories Europe - Network Research&n= bsp;Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria&nbs= p;Road, London W3 6BL
Registered in England 283
------=_001_NextPart156252446058_=------