From zhangyunfei@chinamobile.com Thu May 3 01:54:05 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 A9A0021F85D3 for ; Thu, 3 May 2012 01:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.474 X-Spam-Level: X-Spam-Status: No, score=-93.474 tagged_above=-999 required=5 tests=[AWL=1.665, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqhetlE+GJ-d for ; Thu, 3 May 2012 01:54:05 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89621F8474 for ; Thu, 3 May 2012 01:54:04 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 71309E550; Thu, 3 May 2012 16:53:46 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 72EFFE5BC; Thu, 3 May 2012 16:53:22 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012050316124095-15247 ; Thu, 3 May 2012 16:12:40 +0800 Date: Thu, 3 May 2012 16:12:38 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012050316123830359558@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-03 16:12:40, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-03 16:53:21, Serialize complete at 2012-05-03 16:53:21 Content-Type: multipart/alternative; boundary="----=_001_NextPart084653368635_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18880.006 X-TM-AS-Result: No--23.803-7.0-31-10 X-imss-scan-details: No--23.803-7.0-31-10;No--23.803-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] tickets for IETF 83 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, 03 May 2012 08:54:05 -0000 This is a multi-part message in MIME format. ------=_001_NextPart084653368635_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgYWxsLA0KICAgIEkgaGF2ZSBzdW1tYXJpemVkIGFuIGluaXRpYWwgdGlja2V0cyBsaXN0IGZv ciBJRVRGIDgzIG1lZXRpbmcuIFBsZWFzZSByZXZpZXcgaXQgYW5kIGFjdGlvbnMgb24gdGhlc2Ug dGlja2V0cyBhcmUgZXhwZWN0ZWQuIFRoYW5rcy4NCg0KQlINCll1bmZlaSAmU3RlZmFubw0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClBlZXIgcHJv dG9jb2w6DQpUaWNrZXQgIzGjulBvc3QgYW5kIGRpc2N1c3MgdGhlIGFsdGVybmF0aXZlIHByb3Bv c2FsIGJlc2lkZXMgTUhUIGluIHBlZXIgcHJvdG9jb2wgKFByb3Bvc2FsIDEwKzEzKSwgbGlzdCBp bnRlcnZhbHMgKFRyYWRlb2ZmIGFtb25nIGNvbXBsZXhpdHkgLyBvdmVyaGVhZCAvIGVmZmljaWVu Y3kgLyBpbXBsZW1lbnRhdGlvbikgYW5kIGNoZWNrIGdhcHMuIFtNYXJ0aW6jrCBZdW5mZWksIEZh YmlvLCBMaWNodW5dDQpUaGlzIHRpY2tldCBpcyBwYXJ0bHkgc29sdmVkLiBTaW1wbGUgbmF0dXJl IG51bWJlciBhZGRyZXNzaW5nIGFuZCByYW5nZWQgZXhwcmVzc2lvbiBvbiBjaHVuayBhdmFpbGFi aWxpdHkuIFRoZSBhbmFseXNpcyBhbmQgY29tcGFyaXNvbiBpcyBvbmdvaW5nLiBJJ2Qgc3VnZ2Vz dCB0byBoYXZlIGEgZGVhZGxpbmUgZm9yIHRoZSByZXNvbHV0aW9uIHRpbWUgYWZ0ZXIgZGlzY3Vz c2luZyB3aXRoIFN0ZWZhbm8sIGkuZS4sICBNYXkgMjZ0aCBmcm9tIG5vdyBvbiB0byBtYWtlIHRo ZSBkZWNpc2lvbiBpbiB0aGUgV0cgbGV2ZWwuDQoNClRpY2tldCAjMqO6RGlzY3VzcyB0aGUgcG9z c2libGUgobAic3RhdGUtYnVpbGRpbmcgYXR0YWNrcyIgYXR0YWNrIG9uIHBlZXJzLltNYXJ0aW5d KHJlbGF0ZWQgUHJvcG9zYWwgMjYpDQpNYXJ0aW4sIERvIHlvdSBzdGlsbCBoYXZlIGNvbmNlcm5z IG9uIHRoaXM/IElmIG5vYm9keSBzaG93cyB1cCwgd2UgcHJvcG9zZSB0byBjbG9zZSB0aGlzIHRp Y2tldC4NCg0KVGlja2V0ICMzOiBEaXNjdXNzIHRoZSBNZW1iZXJzaGlwIGNlcnRpZmljYXRlcyBp bXBhY3Qgb24gdGhlIHRyYWNrZXKhr3Mgd29ya2xvYWQuW0ZhYmlvXShyZWxhdGVkIHRvIFByb3Bv c2FsIDE3KzIwKQ0KDQpUcmFja2VyIHByb3RvY29sOg0KVGlja2V0IzQ6IFNwZWNpZnkgdGhlIEZJ TkQgdXNlIGNhc2UgYW5kIHJlZHVjZSB0aGUgb3ZlcmhlYWQgdG8gdGhlIHRyYWNrZXIuW01hcnRp bixZdW5mZWmjrEZhYmlvo6xSaWNoYXJkb10NClRpY2tldCM1OiBEaXNjdXNzIGNvbmNyZXRlIHVz ZSBjYXNlcyBvZiBhZGRpdGlvbmFsIG1lc3NhZ2VzIGlmIHRoZXJlIGFyZShlLmcuLHJlY29ubmVj dCBhbmQgcmVqb2luKSAsIGFuZCBjb25jbHVkZSB0aGUgYmFzaWMgbWVzc2FnZXMgYW5kIG9wdGlv bmFsIG9uZXMgaW4gdHJhY2tlciBwcm90b2NvbC4gW01hcmssIEZhYmlvXQ0KIFdlIHByb3Bvc2Ug dG8gdGhlIHRyYWNrZXIgcHJvdG9jb2wgYXV0aG9ycyB0byBhZGRyZXNzIHRoZWlyIHRpY2tldHMg d2l0aCBhIHNwbGl0dGluZyBvZiB0aGVpciBwcm9wb3NhbDoNCi4gYmFzZSBzcGVjDQouIGFkZGl0 aW9uYWwgb3B0aW9ucy4NCg0KU3VydmV5DQpUaWNrZXQjNjogQ2FsbCBmb3IgcmV2aWV3ZXJzIGZv ciBzdXJ2ZXkgZHJhZnQsIGFuZCBtYXliZSBQMlAgc3RyZWFtaW5nIHByb3ZpZGVyc6GvIGNvbnRy aWJ1dGlvbiBvbiB1cGRhdGluZyB0aGUgZHJhZnQuICAgDQoNCg0KDQoNCnpoYW5neXVuZmVp ------=_001_NextPart084653368635_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi all,

   =20 I have summarized an initial tickets list&nb= sp;for IETF 83 meeting.=20 Please review it and actions on these tickets are expected.=20 Thanks.

 

BR

Yunfei &Stefano

-----------------------------------------------------------= ------------------------------------------------

Peer protocol:

Ticket #1=A3=BAPost and discuss the alternative proposa= l besides=20 MHT in peer protocol (Proposal 10+13), list intervals (Tradeoff among comp= lexity=20 / overhead / efficiency / implementation) and check gaps.=20 [Martin=A3=AC Yunfei, Fabio, Lichun]

This ticket is partly solved. Simple nat= ure number=20 addressing and ranged expression on chunk availability. The analysis and=20 comparison is ongoing. I'd su= ggest to=20 have a deadline for the resolution time after discussing with Stefano= ,=20 i.e.,  May 26th from now on to = make the=20 decision in the WG level.

 

Ticket #2=A3=BADiscuss the possible =A1=B0"state-building attacks" attack on peers.[Martin](related Proposal 26)<= /P>

Martin, Do you still have concerns on this? If nobody shows u= p, we=20 propose to close this=20 ticket.

 

Ticket #3: Discuss the Membe= rship=20 certificates impact on the tracker=A1=AFs workload.[Fabio](related to Prop= osal=20 17+20)

 

Tracker protocol:

Ticket#4: Specify the= FIND use=20 case and reduce the overhead to the tracker.[Martin,Yunfei=A3=ACFabio=A3=ACRichardo]

Ticket#5: Discuss con= crete use=20 cases of additional messages if there are(e.g.,reconnect and rejoin) , and= =20 conclude the basic messages and optional ones in tracker protocol. [Mark,=20 Fabio]

 We=20 propose to the tracker protocol authors to&n= bsp;address their tickets with a splitting o= f their proposal:

. base sp= ec
. additional o= ptions.

 

Survey

Ticket#6: Call for revi= ewers for=20 survey draft, and maybe P2P streaming providers=A1=AF contribution on upda= ting the=20 draft.  
 
zhangyunfei
------=_001_NextPart084653368635_=------ From zongning@huawei.com Fri May 4 01:39:55 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 F162F21F8709 for ; Fri, 4 May 2012 01:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWmZHTfHuiHU for ; Fri, 4 May 2012 01:39:53 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9F521F8637 for ; Fri, 4 May 2012 01:39:53 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFM98204; Fri, 04 May 2012 04:39:52 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 01:37:39 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 4 May 2012 01:37:37 -0700 Received: from SZXEML504-MBX.china.huawei.com ([169.254.4.72]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 4 May 2012 16:37:32 +0800 From: Zongning To: "arno@cs.vu.nl" , ppsp Thread-Topic: [ppsp] New issues derived from PPSP requirements... Thread-Index: AQHM6xwR6ExA6fGEa0qKn9LwNA3UAJa5yyxQ Date: Fri, 4 May 2012 08:37:32 +0000 Message-ID: References: <4F3A60A8.6080800@cs.vu.nl> In-Reply-To: <4F3A60A8.6080800@cs.vu.nl> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.33] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] New issues derived from PPSP requirements... X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 08:39:55 -0000 SGksIEFybm8sDQoNClRoYW5rIHlvdSBmb3IgZXhwbGFpbmluZyBob3cgeW91ciB3b3JrIGlzIChv ciB3aWxsIGJlKSBhbGlnbmVkIHdpdGggUFBTUCByZXF1aXJlbWVudHMuDQpJIGFncmVlIHlvdXIg cHJvcG9zYWwgYW5kIGJlbGlldmUgdGhlIHByb3Bvc2VkIHRleHQgaW4gcGVlciBkcmFmdCBpcyB2 ZXJ5IHVzZWZ1bC4NCg0KLU5pbmcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEFybm8gQmFra2VyDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxMiA5 OjI1IFBNDQpUbzogcHBzcA0KU3ViamVjdDogW3Bwc3BdIE5ldyBpc3N1ZXMgZGVyaXZlZCBmcm9t IFBQU1AgcmVxdWlyZW1lbnRzLi4uDQoNCkhpDQoNCkkndmUgZ29uZSBvdmVyIHRoZSByZXF1aXJl bWVudHMgbGlzdCBpbiBkcmFmdC1pZXRmLXBwc3AtcmVxcy0wNQ0KYW5kIGlkZW50aWZpZWQgc29t ZSBpc3N1ZXMgKG1vc3RseSBzZWN1cml0eSByZWxhdGVkKSB0aGF0IG5lZWQgdG8gYmUgDQpkaXNj dXNzZWQgaW4gdGhlIFdHOg0KDQo+ICogIlBQU1AuUkVRLTg6IFRoZSB0cmFja2VyIGFuZCBwZWVy IHByb3RvY29sIHRvZ2V0aGVyIE1VU1QgZmFjaWxpdGF0ZQ0KPiAgIGFjY2VwdGFibGUgUW9TIChl LmcuIGxvdyBzdGFydHVwIGRlbGF5LCBsb3cgY2hhbm5lbC9jb250ZW50IHN3aXRjaGluZw0KPiAg IHRpbWUgYW5kIG1pbmltYWwgZW5kLXRvLWVuZCBkZWxheSkgZm9yIGJvdGggb24tZGVtYW5kIGFu ZCBsaXZlDQo+ICAgc3RyZWFtaW5nLCBldmVuIGZvciB2ZXJ5IHBvcHVsYXIgY29udGVudC4gIFRo ZSB0cmFja2VyIGFuZCBwZWVyDQo+ICAgcHJvdG9jb2wgZG8gbm90IGluY2x1ZGUgdGhlIGFsZ29y aXRobSByZXF1aXJlZCBmb3Igc2NhbGFibGUNCj4gICBzdHJlYW1pbmcuICBIb3dldmVyLCB0aGUg dHJhY2tlciBhbmQgcGVlciBwcm90b2NvbCBTSEFMTCBOT1QgcmVzdHJpY3QNCj4gICBvciBwbGFj ZSBsaW1pdHMgb24gYW55IHN1Y2ggYWxnb3JpdGhtLg0KPg0KPiAgIFRoZXJlIGFyZSBiYXNpYyBR b1MgcmVxdWlyZW1lbnRzIGZvciBzdHJlYW1pbmcgc3lzdGVtLiAgU2V0dXAgdGltZSB0bw0KPiAg IHJlY2VpdmUgYSBuZXcgc3RyZWFtaW5nIGNoYW5uZWwgb3IgdG8gc3dpdGNoIGJldHdlZW4gY2hh bm5lbHMgc2hvdWxkDQo+ICAgYmUgcmVhc29uYWJsZSBzbWFsbC4gIEVuZCB0byBlbmQgZGVsYXkg KHRpbWUgYmV0d2VlbiBjb250ZW50DQo+ICAgZ2VuZXJhdGlvbiwgZS5nLiBjYW1lcmEgYW5kIGNv bnRlbnQgY29uc3VtcHRpb24sIGUuZy4gdXNlciBzaWRlDQo+ICAgbW9uaXRvcikgd2lsbCBiZWNv bWUgY3JpdGljYWwgaW4gY2FzZSBvZiBsaXZlIHN0cmVhbWluZy4gIEVzcGVjaWFsbHkNCj4gICBp biBwcm92aXNpb25pbmcgb2Ygc3BvcnRzIGV2ZW50cywgZW5kIHRvIGVuZCBkZWxheSBvZiAxIG1p bnV0ZSBhbmQNCj4gICBtb3JlIGFyZSBub3QgYWNjZXB0YWJsZS4NCj4NCj4gICBGb3IgaW5zdGFu Y2UsIHRoZSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29scyBjYW4gc3VwcG9ydCBjYXJyeWluZyBR b1MNCj4gICByZWxhdGVkIHBhcmFtZXRlcnMgKGUuZy4gdmlkZW8gcXVhbGl0eSwgZGVsYXkgcmVx dWlyZW1lbnRzKSB0b2dldGhlcg0KPiAgIHdpdGggdGhlIHByaW9yaXRpZXMgb2YgdGhlc2UgcGFy YW1ldGVycywgYW5kIFFvUyBzaXR1YXRpb24gKGUuZy4NCj4gICBwZXJmb3JtYW5jZSwgYXZhaWxh YmxlIHVwbGluayBiYW5kd2lkdGgpIG9mIGNvbnRlbnQgcHJvdmlkaW5nIHBlZXJzLg0KPg0KPiAg IFRoZXJlIGFyZSBhbHNvIHNvbWUgb3RoZXIgcG9zc2libGUgbWVjaGFuaXNtcywgZS5nLiBhZGRp dGlvbiBvZiBzdXBlcg0KPiAgIHBlZXJzLCBpbi1uZXR3b3JrIHN0b3JhZ2UsIHJlcXVlc3Qgb2Yg YWx0ZXJuYXRpdmUgcGVlciBhZGRyZXNzZXMsIGFuZA0KPiAgIHRoZSB1c2FnZSBvZiBRb1MgaW5m b3JtYXRpb24gZm9yIGFuIGFkdmFuY2VkIHBlZXIgc2VsZWN0aW9uLiINCg0KVGhlIGN1cnJlbnQg cHJvdG9jb2wgaGFzIGJlZW4gZGVzaWduZWQgZm9yIHNob3J0LXRpbWUtdGlsbC1wbGF5YmFjaywN CnVubGVzcyBsaW1pdGVkIGJ5IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIChjZi4gSXNzdWUgIzI2 IHNlY3VyaXR5IG9mDQpoYW5kc2hha2VzKS4gT3RoZXJ3aXNlIGl0IG9wZXJhdGVzIGluIGEgYmVz dCBlZmZvcnQgbW9kZS4NCg0KQnV0IHBlcmhhcHMgbW9yZSBpcyBuZWVkZWQsIGFzIGluZGljYXRl ZCBpbiB0aGUgZGVzY3JpcHRpb24uIEFsc28NCnJlbGV2YW50IGlzIGlzc3VlIDEyICg9U3VwcG9y dCBmb3IgVU5ISU5UKSwgYXMgdGhhdCBoZWxwcyBpbiBtYWtpbmcNCnJlcXVlc3RpbmcgY2h1bmtz IGZyb20gbXVsdGlwbGUgcGVlcnMgYXQgdGhlIHNhbWUgdGltZSBlZmZpY2llbnQsDQphcyB5b3Ug Y2FuIGNhbmNlbCB0aGUgZHVwbGljYXRlcyB3aGVuIHlvdSByZWNlaXZlIGFuIGFuc3dlci4NCllv dSBtYXkgbmVlZCBkb3VibGUgcmVxdWVzdHMgd2hlbiBzb21lIHBlZXJzIGFyZSBzbG93IGFuZCBz dHJvbmcgUW9TDQppcyBuZWVkZWQuDQoNCkknZCBsaWtlIHRvIHJhaXNlIHRoaXMgYXMgSXNzdWUg IzM1Lg0KDQoNCj4gICAqIFBQU1AuUFAuUkVRLTM6IFRoZSBzdHJlYW1pbmcgY29udGVudCBhdmFp bGFiaWxpdHkgcmVxdWVzdCBtZXNzYWdlDQo+ICAgIFNIT1VMRCBhbGxvdyB0aGUgcGVlciB0byBz b2xpY2l0IGFuIGFkZGl0aW9uYWwgbGlzdCBvZiBwZWVycyB0byB0aGF0DQo+ICAgIHJlY2VpdmVk IGZyb20gdGhlIHRyYWNrZXIgLSB3aXRoIHRoZSBzYW1lIHN3YXJtIElELiAgVGhlIHJlcGx5DQo+ ICAgIG1lc3NhZ2UgTVVTVCBjb250YWluIHN3YXJtLW1lbWJlcnNoaXAgaW5mb3JtYXRpb24gb2Yg dGhlIHBlZXJzIHRoYXQNCj4gICAgaGF2ZSBleHBsaWNpdGx5IGluZGljYXRlZCB0aGV5IGFyZSBw YXJ0IG9mIHRoZSBzd2FybSwgdmVyaWZpYWJsZSBieQ0KPiAgICB0aGUgcmVjZWl2ZXIuICBUaGlz IGFkZGl0aW9uYWwgbGlzdCBvZiBwZWVycyBNVVNUIG9ubHkgY29udGFpbiBwZWVycw0KPiAgICB3 aGljaCBoYXZlIGJlZW4gY2hlY2tlZCB0byBiZSB2YWxpZCBhbmQgb25saW5lIHJlY2VudGx5IChl LmcuIHByZXZlbnQNCj4gICAgaGVhcnNheSBhbmQgRG9TKS4NCj4NCj4gICAgSXQgaXMgcG9zc2li bGUgdGhhdCBhIHBlZXIgbWF5IG5lZWQgYWRkaXRpb25hbCBwZWVycyBmb3IgY2VydGFpbg0KPiAg ICBzdHJlYW1pbmcgY29udGVudC4gIFRoZXJlZm9yZSwgaXQgaXMgYWxsb3dlZCB0aGF0IHRoZSBw ZWVyDQo+ICAgIGNvbW11bmljYXRlcyB3aXRoIHRoZSBwZWVycyBpbiB0aGUgY3VycmVudCBwZWVy IGxpc3QgdG8gb2J0YWluIGFuDQo+ICAgIGFkZGl0aW9uYWwgbGlzdCBvZiBwZWVycyBpbiB0aGUg c2FtZSBzd2FybS4NCg0KVGhlIGRyYWZ0IHVzZXMgUEVYXyogbWVzc2FnZXMgZm9yIHRoaXMsIGhl bmNlIEkgcHJvcG9zZSB0byByZXBocmFzZSB0aGlzIA0KcmVxdWlyZW1lbnQsIG9yIGRlY2xhcmUg UEVYIGFzIHN1ZmZpY2llbnQgdG8gc2F0aXNmeSB0aGlzIHJlcXVpcmVtZW50Lg0KDQoNCj4gICAg KiBQUFNQLlBQLlJFUS02OiBUaGUgcGVlciBzdGF0dXMgcmVwb3J0L3VwZGF0ZSBTSE9VTEQgYmUg YWR2ZXJ0aXNlZA0KPiAgICBhbW9uZyB0aGUgcGVlcnMgdG8gcmVmbGVjdCB0aGUgc3RhdHVzIG9m IHRoZSBwZWVyLg0KPg0KPiAgICBQZWVyIHN0YXR1cyBpbmZvcm1hdGlvbiBzaG91bGQgYmUgYWR2 ZXJ0aXNlZCBhbW9uZyB0aGUgcGVlcnMgdmlhIHRoZQ0KPiAgICBwZWVyIHN0YXR1cyByZXBvcnQv dXBkYXRlIG1lc3NhZ2UuICBGb3IgZXhhbXBsZSwgcGVlciBzdGF0dXMgY2FuIGJlDQo+ICAgIG9u bGluZSB0aW1lLCBwaHlzaWNhbCBsaW5rIHN0YXR1cyBpbmNsdWRpbmcgRFNML1dJRkkvZXRjLCBi YXR0ZXJ5DQo+ICAgIHN0YXR1cywgcHJvY2Vzc2luZyBjYXBhYmlsaXR5LCBhbmQgb3RoZXIgY2Fw YWJpbGl0aWVzIG9mIHRoZSBwZWVyLg0KPiAgICBXaXRoIHRoaXMgaW5mb3JtYXRpb24sIGEgcGVl ciBjYW4gc2VsZWN0IG1vcmUgYXBwcm9wcmlhdGUgcGVlcnMgZm9yDQo+ICAgIHN0cmVhbWluZy4N Cg0KSSdkIGxpa2UgdG8gcmFpc2UgdGhpcyBhcyBJc3N1ZSAjMzYuDQoNCg0KPiAgICAqIFBQU1Au U0VDLlJFUS0xOiBQUFNQIE1VU1Qgc3VwcG9ydCBjbG9zZWQgc3dhcm1zLCB3aGVyZSB0aGUgcGVl cnMgYXJlDQo+ICAgIGF1dGhlbnRpY2F0ZWQuDQo+DQo+ICAgIFRoaXMgZW5zdXJlcyB0aGF0IG9u bHkgdGhlIGF1dGhlbnRpY2F0ZWQgdXNlcnMgY2FuIGFjY2VzcyB0aGUNCj4gICAgb3JpZ2luYWwg bWVkaWEgaW4gdGhlIFAyUCBzdHJlYW1pbmcgc3lzdGVtLiAgVGhpcyBjYW4gYmUgYWNoaWV2ZWQg YnkNCj4gICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBzdWNoIGFzIHVzZXIgYXV0aGVudGljYXRpb24g YW5kL29yIGtleSBtYW5hZ2VtZW50DQo+ICAgIHNjaGVtZS4NCg0KSSdkIGxpa2UgdG8gcmFpc2Ug dGhpcyBhcyBJc3N1ZSAjMzcuDQoNCkluIGFkZGl0aW9uLCBJIHByb3Bvc2UgdGhlIGZvbGxvd2lu ZyBzb2x1dGlvbjogVGhlIENsb3NlZCBTd2FybXMgDQpbQ0xPU0VEXSBhbmQgRW5jaGFuY2VkIENs b3NlZCBTd2FybXMgW0VOSENMT1NFRF0gbWVjaGFuaXNtcyBkZXZlbG9wZWQgaW4gDQp0aGUgUDJQ LU5leHQgcHJvamVjdCBwcm92aWRlIHN3YXJtLWxldmVsIGFjY2VzcyBjb250cm9sLg0KVGhlIGJh c2ljIGlkZWEgaXMgdGhhdCBhIHBlZXIgY2Fubm90IGRvd25sb2FkIGZyb20gYW5vdGhlciBwZWVy IHVubGVzcyANCml0IHNob3dzIGEgUHJvb2Ytb2YtQWNjZXNzLiBFbmhhbmNlZCBDbG9zZWQgU3dh cm1zIGltcHJvdmUgb24gdGhlIA0Kb3JpZ2luYWwgQ2xvc2VkIFN3YXJtcyBieSBhZGRpbmcgb24t dGhlLXdpcmUgZW5jcnlwdGlvbiBhZ2FpbnN0IA0KbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcyBh bmQgbW9yZSBmbGV4aWJsZSBhY2Nlc3MgY29udHJvbCBydWxlcy4NCg0KSSBwcm9wb3NlIHRvIGRl c2NyaWJlIEVuaGFuY2VkIENsb3NlZCBTd2FybXMgYXMgb25lIG9mIHRoZSBtZWNoYW5pc21zIA0K KHBsZWFzZSBwdXQgZm9yd2FyZCBvdGhlcnMgaWYgeW91IGtub3cgYWJvdXQgdGhlbSkgdG8gc2F0 aXNmeSB0aGUgDQpyZXF1aXJlbWVudCBhbmQgaW5jbHVkZSBpdCBhcyBhIFNlY3Rpb24gaW4gdGhl IFdHIGRyYWZ0Lg0KDQoNCj4gICAqIFBQU1AuU0VDLlJFUS0yOiBDb25maWRlbnRpYWxpdHkgb2Yg dGhlIHN0cmVhbWluZyBjb250ZW50IGluIFBQU1ANCj4gICAgU0hPVUxEIGJlIHN1cHBvcnRlZCBh bmQgdGhlIGNvcnJlc3BvbmRpbmcga2V5IG1hbmFnZW1lbnQgc2NoZW1lDQo+ICAgIFNIT1VMRCBz Y2FsZSB3ZWxsIGluIFAyUCBzdHJlYW1pbmcgc3lzdGVtLg0KPg0KDQpObyBleHRyYSBtZWNoYW5p c20gaXMgbmVlZGVkIGluIHRvIHN1cHBvcnQgY29uZmlkZW50aWFsaXR5IGluIFBQU1BQLiBBDQpj b250ZW50IHB1Ymxpc2hlciB3aXNoaW5nIGNvbmZpZGVudGlhbGl0eSBzaG91bGQganVzdCBkaXN0 cmlidXRlIGNvbnRlbnQgDQppbiBjeXBoZXJ0ZXh0IC8gRFJNLWVkIGZvcm1hdC4gSSBhc3N1bWUg YSBoaWdoZXIgbGF5ZXIgaGFuZGxlcyBrZXkgDQptYW5hZ2VtZW50IG91dC1vZi1iYW5kLiBBbHRl cm5hdGl2ZWx5LCB0aGUgc3dhcm0gYWNjZXNzIGNvbnRyb2wgd2lsbCANCnBvaW50LXRvLXBvaW50 IGVuY3J5cHQgY29udGVudC4NCg0KSSdkIGxpa2UgdG8gcmFpc2UgdGhpcyBhcyBJc3N1ZSAjMzgs IGFuZCBwcm9wb3NlIHRvIGFkZCBhIHBhcmFncmFwaCB0bw0KU2VjdGlvbiA3IG9mIHRoZSBkcmFm dCB3aXRoIHRoZSBleHBsYW5hdGlvbiBJIGp1c3QgZ2F2ZS4NCg0KDQo+ICAgKiBQUFNQLlNFQy5S RVEtMzogUFBTUCBNVVNUIHByb3ZpZGUgYW4gb3B0aW9uIHRvIGVuY3J5cHQgdGhlIGRhdGENCj4g ICAgZXhjaGFuZ2UgYW1vbmcgdGhlIFBQU1AgZW50aXRpZXMuDQo+DQoNCklmIHRoaXMgcmVxdWly ZW1lbnQgbWVhbnMgdGhhdCBhbGwgUFBTUFAgbWVzc2FnZXMgc2hvdWxkIGJlIGVuY3J5cHRlZCAN CihhcyBvcHBvc2VkIHRvIGp1c3QgY29udGVudCBpbiBTRUMuUkVRLTIpLCBJUHNlYyBvciBEVExT IGlzIHRoZSBvYnZpb3VzIA0Kc29sdXRpb24uDQoNCkknZCBsaWtlIHRvIHJhaXNlIHRoaXMgYXMg SXNzdWUgIzM5LCBhbmQgcHJvcG9zZSB0byBhZGQgYSBwYXJhZ3JhcGggdG8NClNlY3Rpb24gNyBv ZiB0aGUgZHJhZnQgd2l0aCB0aGUgZXhwbGFuYXRpb24gSSBqdXN0IGdhdmUuIEZ1cnRoZXJtb3Jl LA0KYSBrZXkgZGlzdHJpYnV0aW9uIHNjaGVtZSB3b3VsZCBoYXZlIHRvIGJlIGFkZGVkLg0KDQoN Cj4gICAgKiBQUFNQLlNFQy5SRVEtNDogUFBTUCBNVVNUIGhhdmUgbWVjaGFuaXNtcyB0byBsaW1p dCBwb3RlbnRpYWwgZGFtYWdlDQo+ICAgIGNhdXNlZCBieSBtYWxmdW5jdGlvbmluZyBhbmQgYmFk bHkgYmVoYXZpbmcgcGVlcnMgaW4gdGhlIFAyUA0KPiAgICBzdHJlYW1pbmcgc3lzdGVtLg0KPg0K PiAgICBTdWNoIGFuIGF0dGFjayB3aWxsIGRlZ3JhZGUgdGhlIHF1YWxpdHkgb2YgdGhlIHJlbmRl cmVkIG1lZGlhIGF0IHRoZQ0KPiAgICByZWNlaXZlci4gIEZvciBleGFtcGxlLCBpbiBhIFAyUCBs aXZlIHZpZGVvIHN0cmVhbWluZyBzeXN0ZW0gYQ0KPiAgICBwb2xsdXRlciBjYW4gaW50cm9kdWNl IGNvcnJ1cHRlZCBjaHVua3MuICBFYWNoIHJlY2VpdmVyIGludGVncmF0ZXMNCj4gICAgaW50byBp dHMgcGxheWJhY2sgc3RyZWFtIHRoZSBwb2xsdXRlZCBjaHVua3MgaXQgcmVjZWl2ZXMgZnJvbSBp dHMNCj4gICAgb3RoZXIgbmVpZ2hib3JzLiAgU2luY2UgdGhlIHBlZXJzIGZvcndhcmRzIGNodW5r cyB0byBvdGhlciBwZWVycywgdGhlDQo+ICAgIHBvbGx1dGVkIGNvbnRlbnQgY2FuIHBvdGVudGlh bGx5IHNwcmVhZCB0aHJvdWdoIG11Y2ggb2YgdGhlIFAyUA0KPiAgICBzdHJlYW1pbmcgbmV0d29y ay4NCg0KQ29udGVudCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBoZWxwcyBoZXJlLiBJJ2QgbGlrZSB0 byByYWlzZSB0aGlzIGFzIElzc3VlIA0KIzQwIGFuZCB3aWxsIHByb3ZpZGUgYSBwZXItbWVzc2Fn ZSBhbmFseXNpcyBvZiBpc3N1ZXMgbGF0ZXIuDQoNCg0KPiAgICAqIFBQU1AuU0VDLlJFUS01OiBQ UFNQIFNIT1VMRCBzdXBwb3J0IGlkZW50aWZ5aW5nIGJhZGx5IGJlaGF2aW5nIHBlZXJzLA0KPiAg ICBhbmQgZXhjbHVkZSBvciByZWplY3QgdGhlbSBmcm9tIHRoZSBQMlAgc3RyZWFtaW5nIHN5c3Rl bS4NCg0KUXVvdGluZyBXRyBkcmFmdCA2LjMuMi4zOiAiVGhlIE1lcmtsZSB0cmVlIGhhc2hpbmcg c2NoZW1lIGFsbG93cyBhIA0KcmVjZWl2aW5nIHBlZXIgdG8gZGV0ZWN0IGEgbWFsaWNpb3VzIG9y IGZhdWx0eSBzZW5kZXIsIHdoaWNoIGl0IGNhbiANCnN1YnNlcXVlbnRseSBpZ25vcmUuIFNwcmVh ZGluZyB0aGlzIGtub3dsZWRnZSB0byBvdGhlciBwZWVycyBzdWNoIHRoYXQgDQp0aGV5IGtub3cg YWJvdXQgdGhpcyBiYWQgYmVoYXZpb3IgaXMgaGVhcnNheS4iDQoNClNvIHdlIGNhbiBwcm92aWRl IHByb3RlY3Rpb24sIGJ1dCB0byBhY3R1YWxseSBvdXN0IGJhZCBwZWVycyBwZXJtYW5lbnRseSAN CmZyb20gdGhlIHN5c3RlbSwgYWNjZXNzIGNvbnRyb2wgYW5kIGEgcmVsaWFibGUgYWNjdXNhdGlv biBzeXN0ZW0gaXMgDQpuZWVkZWQgdGhhdCBpcyBpdHNlbGYgcHJvdGVjdGVkIGFnYWluc3QgbWFs aWNpb3VzIHBlZXJzIHJlcG9ydGluZyBhYm91dCANCmdvb2QgcGVlcnMuIFN1Y2ggYSBzeXN0ZW0g aXMgY29tcGxleC4NCgkNCkknZCBsaWtlIHRvIHJhaXNlIHRoaXMgYXMgSXNzdWUgIzQxLCBhbmQg cHJvcG9zZSB0byBhZGQgYSBwYXJhZ3JhcGggdG8NClNlY3Rpb24gNyBvZiB0aGUgZHJhZnQgd2l0 aCB0aGUgZXhwbGFuYXRpb24gSSBqdXN0IGdhdmUuDQoNCg0KPiAgICogUFBTUC5TRUMuUkVRLTY6 IFBQU1AgTVVTVCBwcmV2ZW50IHBlZXJzIGZyb20gRG9TIGF0dGFja3Mgd2hpY2ggd2lsbA0KPiAg ICBleGhhdXN0IHRoZSBQMlAgc3RyZWFtaW5nIHN5c3RlbSdzIGF2YWlsYWJsZSByZXNvdXJjZS4N Cj4NCj4gICAgR2l2ZW4gdGhlIHByZXZhbGVuY2Ugb2YgRG9TIGF0dGFja3MgaW4gdGhlIEludGVy bmV0LCBpdCBpcyBpbXBvcnRhbnQNCj4gICAgdG8gcmVhbGl6ZSB0aGF0IGEgc2ltaWxhciB0aHJl YXQgY291bGQgZXhpc3QgaW4gYSBsYXJnZS1zY2FsZQ0KPiAgICBzdHJlYW1pbmcgc3lzdGVtIHdo ZXJlIGF0dGFja2VycyBhcmUgY2FwYWJsZSBvZiBjb25zdW1pbmcgYSBsb3Qgb2YNCj4gICAgcmVz b3VyY2VzIHdpdGgganVzdCBhIHNtYWxsIGFtb3VudCBvZiBlZmZvcnQuDQoNClF1b3RpbmcgV0cg ZHJhZnQgNi4zLjIuMzogIkEgcmlzayBpbiBwZWVyLXRvLXBlZXIgc3RyZWFtaW5nIHN5c3RlbXMg aXMgDQp0aGF0IG1hbGljaW91cyBwZWVycyBsYXVuY2ggYW4gRWNsaXBzZSBbRUNMSVBTRV0gYXR0 YWNrIG9uIHRoZSBpbml0aWFsDQppbmplY3RvcnMgb2YgdGhlIGNvbnRlbnQgKGluIHBhcnRpY3Vs YXIgaW4gbGl2ZSBzdHJlYW1pbmcpLiBUaGUgYXR0YWNrDQp0cmllcyB0byBsZXQgdGhlIGluamVj dG9yIHVwbG9hZCB0byBqdXN0IG1hbGljaW91cyBwZWVycyB3aGljaCB0aGVuIGRvDQpub3QgZm9y d2FyZCB0aGUgY29udGVudCB0byBvdGhlcnMsIHRodXMgc3RvcHBpbmcgdGhlIGRpc3RyaWJ1dGlv bi4gQW4NCkVjbGlwc2UgYXR0YWNrIGNvdWxkIGFsc28gYmUgbGF1bmNoZWQgb24gYW4gaW5kaXZp ZHVhbCBwZWVyLiBMZXR0aW5nDQp0aGVzZSBpbmplY3RvcnMgb25seSB1c2UgdHJ1c3RlZCB0cmFj a2VycyB0aGF0IHByb3ZpZGUgdHJ1ZSByYW5kb20NCnNhbXBsZXMgb2YgdGhlIHBvcHVsYXRpb24g b3IgdXNpbmcgYSBzZWN1cmUgcGVlciBzYW1wbGluZyBzZXJ2aWNlDQpbUFVQUEVUQ0FTVF0gY2Fu IGhlbHAgbmVnYXRlIHN1Y2ggYW4gYXR0YWNrLiINCg0KU28gd2UgbmVlZCBQRVggcHJvdGVjdGlv biBhcyBkaXNjdXNzZWQgaW4gdGhlIG1haWwgIlByb3Bvc2FsIHRvIHJlc29sdmUgDQpJc3N1ZSAx NysyMC4uLiIgb2YgRmViIDE0dGguIEluIGFkZGl0aW9uLCBhIHBlZXIgQSBtdXN0IG5vdA0KbGV0 IG90aGVyIHBlZXJzIFQxLi5UTiBmaWxsIGFsbCBpdHMgYXZhaWxhYmxlIGNvbm5lY3Rpb24gc2xv dHMsIGkuZS4sDQpBIG11c3QgaW5pdGlhdGUgY29ubmVjdGlvbnMgaXRzZWxmIHRvbywgdG8gcHJl dmVudCBpc29sYXRpb24uDQoNCkZ1cnRoZXJtb3JlLCB0byBwcmV2ZW50IG1hbGljaW91cyBwZWVy cyBjb25zdW1pbmcgYWxsIHVwbG9hZCBiYW5kd2lkdGggDQpvZiBhIHBlZXIsIHRoZXJlIHNob3Vs ZCBiZSBhIGxpbWl0IG9uIHRoZSB1cGxvYWQgY2FwYWNpdHkgYSBzaW5nbGUgcGVlcg0KY2FuIGNv bnN1bWUsIGUuZy4gdmlhIGEgbGltaXQgb24gdGhlIG51bWJlciBvZiByZXF1ZXN0cyBhcyBpbiAN ClNlY3VyZVN0cmVhbSBbU0VDU1RSRUFNXS4gQSBuYXR1cmFsIHVwcGVyIGxpbWl0IG9mIHRoaXMg dXBsb2FkIHF1b3R1bSBpcyANCnRoZSBiaXRyYXRlIG9mIHRoZSBjb250ZW50Lg0KDQpQcm90ZWN0 aW9uIGFnYWluc3QgYW1wbGlmY2F0aW9uIGF0dGFja3Mgc3VjaCBhcyBtZW50aW9uZWQgaW4gdGhl IG1haWwgDQoiUHJvcG9zYWwgdG8gc29sdmUgSXNzdWUgIzI2IiBvZiBKYW4gMjV0aCBhbHNvIGhl bHAgdG8gc2F0aXNmeSB0aGlzIA0KcmVxdWlyZW1lbnQuDQoNCklmIHlvdSBrbm93IGFueSBvdGhl ciByZXNvdXJjZSBleGhhdXN0aW9uIGF0dGFja3MgcG9zc2libGUsIHBsZWFzZSANCnN1Ym1pdCB0 aGVtIHdpdGggcHJvcG9zYWxzIG9uIGhvdyB0byBzb2x2ZSB0aGVtLg0KDQpJJ2QgbGlrZSB0byBy YWlzZSB0aGlzIGFzIElzc3VlICM0MiwgYW5kIHByb3Bvc2UgdG8gYWRkIHBhcmFncmFwaHMgdG8N ClNlY3Rpb24gNyBvZiB0aGUgZHJhZnQgd2l0aCB0aGUgZXhwbGFuYXRpb24gSSBqdXN0IGdhdmUu DQoNCg0KPiAgICAqIFBQU1AuU0VDLlJFUS03OiBQUFNQIFNIT1VMRCBiZSByb2J1c3QsIGkuZS4s IHdoZW4gY2VudHJhbGl6ZWQgdHJhY2tlcg0KPiAgICBmYWlscyB0aGUgUDJQIHN0cmVhbWluZyBz eXN0ZW0gU0hPVUxEIHN0aWxsIHdvcmsgYnkgc3VwcG9ydGluZw0KPiAgICBkaXN0cmlidXRlZCB0 cmFja2Vycy4NCg0KV2UgbmVlZCBQRVggcHJvdGVjdGlvbiBhcyBkaXNjdXNzZWQgaW4gdGhlIG1h aWwgIlByb3Bvc2FsIHRvIHJlc29sdmUgDQpJc3N1ZSAxNysyMC4uLiIgb2YgRmViIDE0dGguIEkg cHJvcG9zZSB0byB1cGRhdGUgSXNzdWUgMjAgdG8gaW5kaWNhdGUgDQp0aGF0IHRoaXMgcmVxdWly ZW1lbnQgaXMgcmVsYXRlZC4NCg0KDQo+ICAgICogUFBTUC5TRUMuUkVRLTk6IEludGVncml0eSBv ZiB0aGUgc3RyZWFtaW5nIGNvbnRlbnQgaW4gUFBTUCBNVVNUIGJlDQo+ICAgIHN1cHBvcnRlZCB0 byBwcm92aWRlIGEgcGVlciB3aXRoIHRoZSBwb3NzaWJpbGl0eSB0byBpZGVudGlmeQ0KPiAgICBp bmF1dGhlbnRpYyBtZWRpYSBjb250ZW50ICh1bmRlc2lyYWJsZSBtb2RpZmllZCBieSBvdGhlciBl bnRpdGllcw0KPiAgICByYXRoZXIgdGhhbiBpdHMgZ2VudWluZSBzb3VyY2UpLiAgVGhlIGNvcnJl c3BvbmRpbmcgY2hlY2tzdW0NCj4gICAgZGlzdHJpYnV0aW9uIGFuZCB2ZXJpZmljYXRpb24gc2No ZW1lIFNIT1VMRCBzY2FsZSB3ZWxsIGluIFAyUA0KPiAgICBzdHJlYW1pbmcgc3lzdGVtIGFuZCBi ZSByb2J1c3QgYWdhaW5zdCBkaXN0cnVzdGZ1bCB0cmFja2Vycy9wZWVycy4NCg0KVGhlIE1lcmts ZSBoYXNoIHRyZWVzIG1lY2hhbmlzbSBwcm92aWRlcyBjb250ZW50IGludGVncml0eSBwcm90ZWN0 aW9uDQphbmQgaXMgYWxyZWFkeSBleHBsYWluZWQgaW4gdGhlIGRyYWZ0LiBNZXJrbGUgaGFzaCB0 cmVlcyBjYW4gYWxzbyBiZSANCnVzZWQgZm9yIGxpdmUgc3RyZWFtaW5nLiBJbiB0aGF0IGNvbnRl eHQgd2Ugc2hvdWxkIHF1b3RlIFtESUdTSUdGTE9XXSwgDQp0aGUgc2lnbmF0dXJlIGFtb3J0aXph dGlvbiBzY2hlbWUgdGhhdCBhbHNvIHVzZXMgTWVya2xlIHRyZWVzLg0KDQpJJ2QgbGlrZSB0byBy YWlzZSBhZGRpbmcgdGhlIHJlZmVyZW5jZSBhcyBJc3N1ZSAjNDMuIFN1cHBvcnQgZm9yIA0KbXVs dGlwbGUgY29udGVudCBpbnRlZ3JpdHkgc2NoZW1lcyB3aWxsIGJlIGFkZGVkIHdoZW4gd2UgcmVh Y2ggY29uY2Vuc3VzIA0Kb24gSXNzdWUgIzEwKzEzIChzZWUgbXkgbWFpbCBkZC4gSmFuIDE4dGgp Lg0KDQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpDVSwNCiAgICAgQXJubw0KDQoNCg0KUmVmZXJl bmNlcw0KLS0tLS0tLS0tLQ0KW0NMT1NFRF0gTi4gQm9yY2gsIEsuIE1pY2hlbGwsIEkuIEFybnR6 ZW4sIGFuZCBELiBHYWJyaWplbGNpYzogIkFjY2Vzcw0KY29udHJvbCB0byBCaXRUb3JyZW50IHN3 YXJtcyB1c2luZyBjbG9zZWQgc3dhcm1zIi4gSW4gUHJvY2VlZGluZ3MNCm9mIHRoZSAyMDEwIEFD TSB3b3Jrc2hvcCBvbiBBZHZhbmNlZCB2aWRlbyBzdHJlYW1pbmcgdGVjaG5pcXVlcw0KZm9yIHBl ZXItdG8tcGVlciBuZXR3b3JrcyBhbmQgc29jaWFsIG5ldHdvcmtpbmcgKEFWU1RQMlAgJzEwKS4N CkFDTSwgTmV3IFlvcmssIE5ZLCBVU0EsIDI1LTMwLg0KaHR0cDovL2RvaS5hY20ub3JnLzEwLjEx NDUvMTg3Nzg5MS4xODc3ODk4DQoNCltFTkhDTE9TRURdIFYuIEpvdmFub3Zpa2osIEQuIEdhYnJp amVsxI1pxI0gYW5kIFQuIEtsb2J1xI1hci4gIkFjY2VzcyANCkNvbnRyb2wgaW4gQml0VG9ycmVu dCBQMlAgTmV0d29ya3MgVXNpbmcgdGhlIEVuaGFuY2VkIENsb3NlZCBTd2FybXMNClByb3RvY29s Ii4gSW4gUHJvY2VlZGluZ3Mgb2YgdGhlIEZpZnRoIEludGVybmF0aW9uYWwgQ29uZmVyZW5jZSBv biANCkVtZXJnaW5nIFNlY3VyaXR5IEluZm9ybWF0aW9uLCBTeXN0ZW1zIGFuZCBUZWNobm9sb2dp ZXMgKFNFQ1VSV0FSRQ0KMjAxMSksIHBwLiA5Ny0xMDIsIE5pY2UsIEZyYW5jZSwgQXVndXN0IDIw MTEuDQoNCltTRUNTVFJFQU1dIE1heWEgSGFyaWRhc2FuIGFuZCBSb2JiZXJ0IHZhbiBSZW5lc3Nl LiAiU2VjdXJlU3RyZWFtOiBBbiANCkludHJ1c2lvbi1Ub2xlcmFudCBQcm90b2NvbCBmb3IgTGl2 ZS1TdHJlYW1pbmcgRGlzc2VtaW5hdGlvbiIuIFRoZSANCkpvdXJuYWwgb2YgQ29tcHV0ZXIgQ29t bXVuaWNhdGlvbidzIFNwZWNpYWwgaXNzdWUgb24gRm91bmRhdGlvbiBvZiANClBlZXItdG8tUGVl ciBDb21wdXRpbmcuIFZvbHVtZSAzMSBOdW1iZXIgMiwgRWxzZXZpZXIsIDIwMDguDQoNCltESUdT SUdGTE9XXSBDaHVuZyBLZWkgV29uZyBhbmQgU2ltb24gUy4gTGFtLiAiRGlnaXRhbCBTaWduYXR1 cmVzIGZvciANCkZsb3dzIGFuZCBNdWx0aWNhc3RzIi4gSUVFRS9BQ00gVHJhbnNhY3Rpb25zIG9u IE5ldHdvcmtpbmcsDQpWb2x1bWUgNywgIElzc3VlIDQsIHBwLiA1MDItNTEzLCBBdWcgMTk5OS4N Cmh0dHA6Ly9keC5kb2kub3JnLzEwLjExMDkvOTAuNzkzMDA1DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0K From zhangyunfei@chinamobile.com Fri May 4 02:00:04 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 73F5121F8649 for ; Fri, 4 May 2012 02:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.301 X-Spam-Level: X-Spam-Status: No, score=-96.301 tagged_above=-999 required=5 tests=[AWL=4.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLW7zI2XPZLl for ; Fri, 4 May 2012 02:00:02 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2087421F85F2 for ; Fri, 4 May 2012 01:59:58 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 24297E5DE; Fri, 4 May 2012 16:59:56 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 0C14DE40A; Fri, 4 May 2012 16:59:56 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012050416595386-22741 ; Fri, 4 May 2012 16:59:53 +0800 Date: Fri, 4 May 2012 16:59:49 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <20120504165949894797116@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-04 16:59:53, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-04 16:59:55, Serialize complete at 2012-05-04 16:59:55 Content-Type: multipart/alternative; boundary="----=_001_NextPart826730411584_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18884.006 X-TM-AS-Result: No--5.852-7.0-31-10 X-imss-scan-details: No--5.852-7.0-31-10;No--5.852-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] One more ticket for Peer protocol security requirement issues 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, 04 May 2012 09:00:04 -0000 This is a multi-part message in MIME format. ------=_001_NextPart826730411584_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGkgYWxsLA0KICAgIEFybm8gcHJvcG9zZWQgc29tZSBuZXcgaXNzdWVzIGRlcml2ZWQgZnJvbSBQ UFNQIHJlcXVpcmVtZW50cyBhcyBiZWxvdy4gSXQgd291bGQgYmUgZ3JlYXQgdGhhdCBzb21lIGV4 cGVydHMgd291bGQgbG9vayBhdCB0aGUgbWFpbCBhbmQgc2F5IGlmIHlvdSBhZ3JlZSB3aXRoIHRo ZSBjaGFuZ2VzIA0KQXJubyB3YW50cyB0byBtYWtlIHRvIHRoZSBwZWVyIHByb3RvY29sIHRleHQu DQogICAgVGlja2V0ICM077yaUmV2aWV3IHRoZSBmb2xsb3dpbmcgcHJvcG9zYWxzIGFuZCBzYXkg aWYgeW91IGFncmVlIHdpdGggdGhlIGNoYW5nZXMuDQogICAgICBJZiBub2JvZHkgZXhwcmVzc2Vk IGFueSBjb25jZXJuIG9yIGFsdGVybmF0aXZlIHByb3Bvc2FsIHJlZ2FyZGluZyBzZWN1cml0eSBp c3N1ZXMgKHdpdGggdGhlIHNhbWUgZGVhZGxpbmUgYXMgdGlja2V0ICMx77yMIE1heSAyNnRo77yJ LCB3ZSBwcm9wb3NlIHRvIG1vdmUgb24gYW5kIHdvdWxkIGFzayBBcm5vIHRvIHByb2NlZWRzIHdp dGggdGhlIGNoYW5nZXMgaW4gdGhlIHBlZXIgcHJvdG9jb2wgZHJhZnQuDQoNCkJSDQpZdW5mZWkN CiAgICANCg0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJha2tlcg0KRGF0ZTog MjAxMi0wMi0xNCAyMToyNA0KVG86IHBwc3ANClN1YmplY3Q6IFtwcHNwXSBOZXcgaXNzdWVzIGRl cml2ZWQgZnJvbSBQUFNQIHJlcXVpcmVtZW50cy4uLg0KSGkNCg0KSSd2ZSBnb25lIG92ZXIgdGhl IHJlcXVpcmVtZW50cyBsaXN0IGluIGRyYWZ0LWlldGYtcHBzcC1yZXFzLTA1DQphbmQgaWRlbnRp ZmllZCBzb21lIGlzc3VlcyAobW9zdGx5IHNlY3VyaXR5IHJlbGF0ZWQpIHRoYXQgbmVlZCB0byBi ZSANCmRpc2N1c3NlZCBpbiB0aGUgV0c6DQoNCj4gKiAiUFBTUC5SRVEtODogVGhlIHRyYWNrZXIg YW5kIHBlZXIgcHJvdG9jb2wgdG9nZXRoZXIgTVVTVCBmYWNpbGl0YXRlDQo+ICAgYWNjZXB0YWJs ZSBRb1MgKGUuZy4gbG93IHN0YXJ0dXAgZGVsYXksIGxvdyBjaGFubmVsL2NvbnRlbnQgc3dpdGNo aW5nDQo+ICAgdGltZSBhbmQgbWluaW1hbCBlbmQtdG8tZW5kIGRlbGF5KSBmb3IgYm90aCBvbi1k ZW1hbmQgYW5kIGxpdmUNCj4gICBzdHJlYW1pbmcsIGV2ZW4gZm9yIHZlcnkgcG9wdWxhciBjb250 ZW50LiAgVGhlIHRyYWNrZXIgYW5kIHBlZXINCj4gICBwcm90b2NvbCBkbyBub3QgaW5jbHVkZSB0 aGUgYWxnb3JpdGhtIHJlcXVpcmVkIGZvciBzY2FsYWJsZQ0KPiAgIHN0cmVhbWluZy4gIEhvd2V2 ZXIsIHRoZSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sIFNIQUxMIE5PVCByZXN0cmljdA0KPiAg IG9yIHBsYWNlIGxpbWl0cyBvbiBhbnkgc3VjaCBhbGdvcml0aG0uDQo+DQo+ICAgVGhlcmUgYXJl IGJhc2ljIFFvUyByZXF1aXJlbWVudHMgZm9yIHN0cmVhbWluZyBzeXN0ZW0uICBTZXR1cCB0aW1l IHRvDQo+ICAgcmVjZWl2ZSBhIG5ldyBzdHJlYW1pbmcgY2hhbm5lbCBvciB0byBzd2l0Y2ggYmV0 d2VlbiBjaGFubmVscyBzaG91bGQNCj4gICBiZSByZWFzb25hYmxlIHNtYWxsLiAgRW5kIHRvIGVu ZCBkZWxheSAodGltZSBiZXR3ZWVuIGNvbnRlbnQNCj4gICBnZW5lcmF0aW9uLCBlLmcuIGNhbWVy YSBhbmQgY29udGVudCBjb25zdW1wdGlvbiwgZS5nLiB1c2VyIHNpZGUNCj4gICBtb25pdG9yKSB3 aWxsIGJlY29tZSBjcml0aWNhbCBpbiBjYXNlIG9mIGxpdmUgc3RyZWFtaW5nLiAgRXNwZWNpYWxs eQ0KPiAgIGluIHByb3Zpc2lvbmluZyBvZiBzcG9ydHMgZXZlbnRzLCBlbmQgdG8gZW5kIGRlbGF5 IG9mIDEgbWludXRlIGFuZA0KPiAgIG1vcmUgYXJlIG5vdCBhY2NlcHRhYmxlLg0KPg0KPiAgIEZv ciBpbnN0YW5jZSwgdGhlIHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2xzIGNhbiBzdXBwb3J0IGNh cnJ5aW5nIFFvUw0KPiAgIHJlbGF0ZWQgcGFyYW1ldGVycyAoZS5nLiB2aWRlbyBxdWFsaXR5LCBk ZWxheSByZXF1aXJlbWVudHMpIHRvZ2V0aGVyDQo+ICAgd2l0aCB0aGUgcHJpb3JpdGllcyBvZiB0 aGVzZSBwYXJhbWV0ZXJzLCBhbmQgUW9TIHNpdHVhdGlvbiAoZS5nLg0KPiAgIHBlcmZvcm1hbmNl LCBhdmFpbGFibGUgdXBsaW5rIGJhbmR3aWR0aCkgb2YgY29udGVudCBwcm92aWRpbmcgcGVlcnMu DQo+DQo+ICAgVGhlcmUgYXJlIGFsc28gc29tZSBvdGhlciBwb3NzaWJsZSBtZWNoYW5pc21zLCBl LmcuIGFkZGl0aW9uIG9mIHN1cGVyDQo+ICAgcGVlcnMsIGluLW5ldHdvcmsgc3RvcmFnZSwgcmVx dWVzdCBvZiBhbHRlcm5hdGl2ZSBwZWVyIGFkZHJlc3NlcywgYW5kDQo+ICAgdGhlIHVzYWdlIG9m IFFvUyBpbmZvcm1hdGlvbiBmb3IgYW4gYWR2YW5jZWQgcGVlciBzZWxlY3Rpb24uIg0KDQpUaGUg Y3VycmVudCBwcm90b2NvbCBoYXMgYmVlbiBkZXNpZ25lZCBmb3Igc2hvcnQtdGltZS10aWxsLXBs YXliYWNrLA0KdW5sZXNzIGxpbWl0ZWQgYnkgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgKGNmLiBJ c3N1ZSAjMjYgc2VjdXJpdHkgb2YNCmhhbmRzaGFrZXMpLiBPdGhlcndpc2UgaXQgb3BlcmF0ZXMg aW4gYSBiZXN0IGVmZm9ydCBtb2RlLg0KDQpCdXQgcGVyaGFwcyBtb3JlIGlzIG5lZWRlZCwgYXMg aW5kaWNhdGVkIGluIHRoZSBkZXNjcmlwdGlvbi4gQWxzbw0KcmVsZXZhbnQgaXMgaXNzdWUgMTIg KD1TdXBwb3J0IGZvciBVTkhJTlQpLCBhcyB0aGF0IGhlbHBzIGluIG1ha2luZw0KcmVxdWVzdGlu ZyBjaHVua3MgZnJvbSBtdWx0aXBsZSBwZWVycyBhdCB0aGUgc2FtZSB0aW1lIGVmZmljaWVudCwN CmFzIHlvdSBjYW4gY2FuY2VsIHRoZSBkdXBsaWNhdGVzIHdoZW4geW91IHJlY2VpdmUgYW4gYW5z d2VyLg0KWW91IG1heSBuZWVkIGRvdWJsZSByZXF1ZXN0cyB3aGVuIHNvbWUgcGVlcnMgYXJlIHNs b3cgYW5kIHN0cm9uZyBRb1MNCmlzIG5lZWRlZC4NCg0KSSdkIGxpa2UgdG8gcmFpc2UgdGhpcyBh cyBJc3N1ZSAjMzUuDQoNCg0KPiAgICogUFBTUC5QUC5SRVEtMzogVGhlIHN0cmVhbWluZyBjb250 ZW50IGF2YWlsYWJpbGl0eSByZXF1ZXN0IG1lc3NhZ2UNCj4gICAgU0hPVUxEIGFsbG93IHRoZSBw ZWVyIHRvIHNvbGljaXQgYW4gYWRkaXRpb25hbCBsaXN0IG9mIHBlZXJzIHRvIHRoYXQNCj4gICAg cmVjZWl2ZWQgZnJvbSB0aGUgdHJhY2tlciAtIHdpdGggdGhlIHNhbWUgc3dhcm0gSUQuICBUaGUg cmVwbHkNCj4gICAgbWVzc2FnZSBNVVNUIGNvbnRhaW4gc3dhcm0tbWVtYmVyc2hpcCBpbmZvcm1h dGlvbiBvZiB0aGUgcGVlcnMgdGhhdA0KPiAgICBoYXZlIGV4cGxpY2l0bHkgaW5kaWNhdGVkIHRo ZXkgYXJlIHBhcnQgb2YgdGhlIHN3YXJtLCB2ZXJpZmlhYmxlIGJ5DQo+ICAgIHRoZSByZWNlaXZl ci4gIFRoaXMgYWRkaXRpb25hbCBsaXN0IG9mIHBlZXJzIE1VU1Qgb25seSBjb250YWluIHBlZXJz DQo+ICAgIHdoaWNoIGhhdmUgYmVlbiBjaGVja2VkIHRvIGJlIHZhbGlkIGFuZCBvbmxpbmUgcmVj ZW50bHkgKGUuZy4gcHJldmVudA0KPiAgICBoZWFyc2F5IGFuZCBEb1MpLg0KPg0KPiAgICBJdCBp cyBwb3NzaWJsZSB0aGF0IGEgcGVlciBtYXkgbmVlZCBhZGRpdGlvbmFsIHBlZXJzIGZvciBjZXJ0 YWluDQo+ICAgIHN0cmVhbWluZyBjb250ZW50LiAgVGhlcmVmb3JlLCBpdCBpcyBhbGxvd2VkIHRo YXQgdGhlIHBlZXINCj4gICAgY29tbXVuaWNhdGVzIHdpdGggdGhlIHBlZXJzIGluIHRoZSBjdXJy ZW50IHBlZXIgbGlzdCB0byBvYnRhaW4gYW4NCj4gICAgYWRkaXRpb25hbCBsaXN0IG9mIHBlZXJz IGluIHRoZSBzYW1lIHN3YXJtLg0KDQpUaGUgZHJhZnQgdXNlcyBQRVhfKiBtZXNzYWdlcyBmb3Ig dGhpcywgaGVuY2UgSSBwcm9wb3NlIHRvIHJlcGhyYXNlIHRoaXMgDQpyZXF1aXJlbWVudCwgb3Ig ZGVjbGFyZSBQRVggYXMgc3VmZmljaWVudCB0byBzYXRpc2Z5IHRoaXMgcmVxdWlyZW1lbnQuDQoN Cg0KPiAgICAqIFBQU1AuUFAuUkVRLTY6IFRoZSBwZWVyIHN0YXR1cyByZXBvcnQvdXBkYXRlIFNI T1VMRCBiZSBhZHZlcnRpc2VkDQo+ICAgIGFtb25nIHRoZSBwZWVycyB0byByZWZsZWN0IHRoZSBz dGF0dXMgb2YgdGhlIHBlZXIuDQo+DQo+ICAgIFBlZXIgc3RhdHVzIGluZm9ybWF0aW9uIHNob3Vs ZCBiZSBhZHZlcnRpc2VkIGFtb25nIHRoZSBwZWVycyB2aWEgdGhlDQo+ICAgIHBlZXIgc3RhdHVz IHJlcG9ydC91cGRhdGUgbWVzc2FnZS4gIEZvciBleGFtcGxlLCBwZWVyIHN0YXR1cyBjYW4gYmUN Cj4gICAgb25saW5lIHRpbWUsIHBoeXNpY2FsIGxpbmsgc3RhdHVzIGluY2x1ZGluZyBEU0wvV0lG SS9ldGMsIGJhdHRlcnkNCj4gICAgc3RhdHVzLCBwcm9jZXNzaW5nIGNhcGFiaWxpdHksIGFuZCBv dGhlciBjYXBhYmlsaXRpZXMgb2YgdGhlIHBlZXIuDQo+ICAgIFdpdGggdGhpcyBpbmZvcm1hdGlv biwgYSBwZWVyIGNhbiBzZWxlY3QgbW9yZSBhcHByb3ByaWF0ZSBwZWVycyBmb3INCj4gICAgc3Ry ZWFtaW5nLg0KDQpJJ2QgbGlrZSB0byByYWlzZSB0aGlzIGFzIElzc3VlICMzNi4NCg0KDQo+ICAg ICogUFBTUC5TRUMuUkVRLTE6IFBQU1AgTVVTVCBzdXBwb3J0IGNsb3NlZCBzd2FybXMsIHdoZXJl IHRoZSBwZWVycyBhcmUNCj4gICAgYXV0aGVudGljYXRlZC4NCj4NCj4gICAgVGhpcyBlbnN1cmVz IHRoYXQgb25seSB0aGUgYXV0aGVudGljYXRlZCB1c2VycyBjYW4gYWNjZXNzIHRoZQ0KPiAgICBv cmlnaW5hbCBtZWRpYSBpbiB0aGUgUDJQIHN0cmVhbWluZyBzeXN0ZW0uICBUaGlzIGNhbiBiZSBh Y2hpZXZlZCBieQ0KPiAgICBzZWN1cml0eSBtZWNoYW5pc21zIHN1Y2ggYXMgdXNlciBhdXRoZW50 aWNhdGlvbiBhbmQvb3Iga2V5IG1hbmFnZW1lbnQNCj4gICAgc2NoZW1lLg0KDQpJJ2QgbGlrZSB0 byByYWlzZSB0aGlzIGFzIElzc3VlICMzNy4NCg0KSW4gYWRkaXRpb24sIEkgcHJvcG9zZSB0aGUg Zm9sbG93aW5nIHNvbHV0aW9uOiBUaGUgQ2xvc2VkIFN3YXJtcyANCltDTE9TRURdIGFuZCBFbmNo YW5jZWQgQ2xvc2VkIFN3YXJtcyBbRU5IQ0xPU0VEXSBtZWNoYW5pc21zIGRldmVsb3BlZCBpbiAN CnRoZSBQMlAtTmV4dCBwcm9qZWN0IHByb3ZpZGUgc3dhcm0tbGV2ZWwgYWNjZXNzIGNvbnRyb2wu DQpUaGUgYmFzaWMgaWRlYSBpcyB0aGF0IGEgcGVlciBjYW5ub3QgZG93bmxvYWQgZnJvbSBhbm90 aGVyIHBlZXIgdW5sZXNzIA0KaXQgc2hvd3MgYSBQcm9vZi1vZi1BY2Nlc3MuIEVuaGFuY2VkIENs b3NlZCBTd2FybXMgaW1wcm92ZSBvbiB0aGUgDQpvcmlnaW5hbCBDbG9zZWQgU3dhcm1zIGJ5IGFk ZGluZyBvbi10aGUtd2lyZSBlbmNyeXB0aW9uIGFnYWluc3QgDQptYW4taW4tdGhlLW1pZGRsZSBh dHRhY2tzIGFuZCBtb3JlIGZsZXhpYmxlIGFjY2VzcyBjb250cm9sIHJ1bGVzLg0KDQpJIHByb3Bv c2UgdG8gZGVzY3JpYmUgRW5oYW5jZWQgQ2xvc2VkIFN3YXJtcyBhcyBvbmUgb2YgdGhlIG1lY2hh bmlzbXMgDQoocGxlYXNlIHB1dCBmb3J3YXJkIG90aGVycyBpZiB5b3Uga25vdyBhYm91dCB0aGVt KSB0byBzYXRpc2Z5IHRoZSANCnJlcXVpcmVtZW50IGFuZCBpbmNsdWRlIGl0IGFzIGEgU2VjdGlv biBpbiB0aGUgV0cgZHJhZnQuDQoNCg0KPiAgICogUFBTUC5TRUMuUkVRLTI6IENvbmZpZGVudGlh bGl0eSBvZiB0aGUgc3RyZWFtaW5nIGNvbnRlbnQgaW4gUFBTUA0KPiAgICBTSE9VTEQgYmUgc3Vw cG9ydGVkIGFuZCB0aGUgY29ycmVzcG9uZGluZyBrZXkgbWFuYWdlbWVudCBzY2hlbWUNCj4gICAg U0hPVUxEIHNjYWxlIHdlbGwgaW4gUDJQIHN0cmVhbWluZyBzeXN0ZW0uDQo+DQoNCk5vIGV4dHJh IG1lY2hhbmlzbSBpcyBuZWVkZWQgaW4gdG8gc3VwcG9ydCBjb25maWRlbnRpYWxpdHkgaW4gUFBT UFAuIEENCmNvbnRlbnQgcHVibGlzaGVyIHdpc2hpbmcgY29uZmlkZW50aWFsaXR5IHNob3VsZCBq dXN0IGRpc3RyaWJ1dGUgY29udGVudCANCmluIGN5cGhlcnRleHQgLyBEUk0tZWQgZm9ybWF0LiBJ IGFzc3VtZSBhIGhpZ2hlciBsYXllciBoYW5kbGVzIGtleSANCm1hbmFnZW1lbnQgb3V0LW9mLWJh bmQuIEFsdGVybmF0aXZlbHksIHRoZSBzd2FybSBhY2Nlc3MgY29udHJvbCB3aWxsIA0KcG9pbnQt dG8tcG9pbnQgZW5jcnlwdCBjb250ZW50Lg0KDQpJJ2QgbGlrZSB0byByYWlzZSB0aGlzIGFzIElz c3VlICMzOCwgYW5kIHByb3Bvc2UgdG8gYWRkIGEgcGFyYWdyYXBoIHRvDQpTZWN0aW9uIDcgb2Yg dGhlIGRyYWZ0IHdpdGggdGhlIGV4cGxhbmF0aW9uIEkganVzdCBnYXZlLg0KDQoNCj4gICAqIFBQ U1AuU0VDLlJFUS0zOiBQUFNQIE1VU1QgcHJvdmlkZSBhbiBvcHRpb24gdG8gZW5jcnlwdCB0aGUg ZGF0YQ0KPiAgICBleGNoYW5nZSBhbW9uZyB0aGUgUFBTUCBlbnRpdGllcy4NCj4NCg0KSWYgdGhp cyByZXF1aXJlbWVudCBtZWFucyB0aGF0IGFsbCBQUFNQUCBtZXNzYWdlcyBzaG91bGQgYmUgZW5j cnlwdGVkIA0KKGFzIG9wcG9zZWQgdG8ganVzdCBjb250ZW50IGluIFNFQy5SRVEtMiksIElQc2Vj IG9yIERUTFMgaXMgdGhlIG9idmlvdXMgDQpzb2x1dGlvbi4NCg0KSSdkIGxpa2UgdG8gcmFpc2Ug dGhpcyBhcyBJc3N1ZSAjMzksIGFuZCBwcm9wb3NlIHRvIGFkZCBhIHBhcmFncmFwaCB0bw0KU2Vj dGlvbiA3IG9mIHRoZSBkcmFmdCB3aXRoIHRoZSBleHBsYW5hdGlvbiBJIGp1c3QgZ2F2ZS4gRnVy dGhlcm1vcmUsDQphIGtleSBkaXN0cmlidXRpb24gc2NoZW1lIHdvdWxkIGhhdmUgdG8gYmUgYWRk ZWQuDQoNCg0KPiAgICAqIFBQU1AuU0VDLlJFUS00OiBQUFNQIE1VU1QgaGF2ZSBtZWNoYW5pc21z IHRvIGxpbWl0IHBvdGVudGlhbCBkYW1hZ2UNCj4gICAgY2F1c2VkIGJ5IG1hbGZ1bmN0aW9uaW5n IGFuZCBiYWRseSBiZWhhdmluZyBwZWVycyBpbiB0aGUgUDJQDQo+ICAgIHN0cmVhbWluZyBzeXN0 ZW0uDQo+DQo+ICAgIFN1Y2ggYW4gYXR0YWNrIHdpbGwgZGVncmFkZSB0aGUgcXVhbGl0eSBvZiB0 aGUgcmVuZGVyZWQgbWVkaWEgYXQgdGhlDQo+ICAgIHJlY2VpdmVyLiAgRm9yIGV4YW1wbGUsIGlu IGEgUDJQIGxpdmUgdmlkZW8gc3RyZWFtaW5nIHN5c3RlbSBhDQo+ICAgIHBvbGx1dGVyIGNhbiBp bnRyb2R1Y2UgY29ycnVwdGVkIGNodW5rcy4gIEVhY2ggcmVjZWl2ZXIgaW50ZWdyYXRlcw0KPiAg ICBpbnRvIGl0cyBwbGF5YmFjayBzdHJlYW0gdGhlIHBvbGx1dGVkIGNodW5rcyBpdCByZWNlaXZl cyBmcm9tIGl0cw0KPiAgICBvdGhlciBuZWlnaGJvcnMuICBTaW5jZSB0aGUgcGVlcnMgZm9yd2Fy ZHMgY2h1bmtzIHRvIG90aGVyIHBlZXJzLCB0aGUNCj4gICAgcG9sbHV0ZWQgY29udGVudCBjYW4g cG90ZW50aWFsbHkgc3ByZWFkIHRocm91Z2ggbXVjaCBvZiB0aGUgUDJQDQo+ICAgIHN0cmVhbWlu ZyBuZXR3b3JrLg0KDQpDb250ZW50IGludGVncml0eSBwcm90ZWN0aW9uIGhlbHBzIGhlcmUuIEkn ZCBsaWtlIHRvIHJhaXNlIHRoaXMgYXMgSXNzdWUgDQojNDAgYW5kIHdpbGwgcHJvdmlkZSBhIHBl ci1tZXNzYWdlIGFuYWx5c2lzIG9mIGlzc3VlcyBsYXRlci4NCg0KDQo+ICAgICogUFBTUC5TRUMu UkVRLTU6IFBQU1AgU0hPVUxEIHN1cHBvcnQgaWRlbnRpZnlpbmcgYmFkbHkgYmVoYXZpbmcgcGVl cnMsDQo+ICAgIGFuZCBleGNsdWRlIG9yIHJlamVjdCB0aGVtIGZyb20gdGhlIFAyUCBzdHJlYW1p bmcgc3lzdGVtLg0KDQpRdW90aW5nIFdHIGRyYWZ0IDYuMy4yLjM6ICJUaGUgTWVya2xlIHRyZWUg aGFzaGluZyBzY2hlbWUgYWxsb3dzIGEgDQpyZWNlaXZpbmcgcGVlciB0byBkZXRlY3QgYSBtYWxp Y2lvdXMgb3IgZmF1bHR5IHNlbmRlciwgd2hpY2ggaXQgY2FuIA0Kc3Vic2VxdWVudGx5IGlnbm9y ZS4gU3ByZWFkaW5nIHRoaXMga25vd2xlZGdlIHRvIG90aGVyIHBlZXJzIHN1Y2ggdGhhdCANCnRo ZXkga25vdyBhYm91dCB0aGlzIGJhZCBiZWhhdmlvciBpcyBoZWFyc2F5LiINCg0KU28gd2UgY2Fu IHByb3ZpZGUgcHJvdGVjdGlvbiwgYnV0IHRvIGFjdHVhbGx5IG91c3QgYmFkIHBlZXJzIHBlcm1h bmVudGx5IA0KZnJvbSB0aGUgc3lzdGVtLCBhY2Nlc3MgY29udHJvbCBhbmQgYSByZWxpYWJsZSBh Y2N1c2F0aW9uIHN5c3RlbSBpcyANCm5lZWRlZCB0aGF0IGlzIGl0c2VsZiBwcm90ZWN0ZWQgYWdh aW5zdCBtYWxpY2lvdXMgcGVlcnMgcmVwb3J0aW5nIGFib3V0IA0KZ29vZCBwZWVycy4gU3VjaCBh IHN5c3RlbSBpcyBjb21wbGV4Lg0KSSdkIGxpa2UgdG8gcmFpc2UgdGhpcyBhcyBJc3N1ZSAjNDEs IGFuZCBwcm9wb3NlIHRvIGFkZCBhIHBhcmFncmFwaCB0bw0KU2VjdGlvbiA3IG9mIHRoZSBkcmFm dCB3aXRoIHRoZSBleHBsYW5hdGlvbiBJIGp1c3QgZ2F2ZS4NCg0KDQo+ICAgKiBQUFNQLlNFQy5S RVEtNjogUFBTUCBNVVNUIHByZXZlbnQgcGVlcnMgZnJvbSBEb1MgYXR0YWNrcyB3aGljaCB3aWxs DQo+ICAgIGV4aGF1c3QgdGhlIFAyUCBzdHJlYW1pbmcgc3lzdGVtJ3MgYXZhaWxhYmxlIHJlc291 cmNlLg0KPg0KPiAgICBHaXZlbiB0aGUgcHJldmFsZW5jZSBvZiBEb1MgYXR0YWNrcyBpbiB0aGUg SW50ZXJuZXQsIGl0IGlzIGltcG9ydGFudA0KPiAgICB0byByZWFsaXplIHRoYXQgYSBzaW1pbGFy IHRocmVhdCBjb3VsZCBleGlzdCBpbiBhIGxhcmdlLXNjYWxlDQo+ICAgIHN0cmVhbWluZyBzeXN0 ZW0gd2hlcmUgYXR0YWNrZXJzIGFyZSBjYXBhYmxlIG9mIGNvbnN1bWluZyBhIGxvdCBvZg0KPiAg ICByZXNvdXJjZXMgd2l0aCBqdXN0IGEgc21hbGwgYW1vdW50IG9mIGVmZm9ydC4NCg0KUXVvdGlu ZyBXRyBkcmFmdCA2LjMuMi4zOiAiQSByaXNrIGluIHBlZXItdG8tcGVlciBzdHJlYW1pbmcgc3lz dGVtcyBpcyANCnRoYXQgbWFsaWNpb3VzIHBlZXJzIGxhdW5jaCBhbiBFY2xpcHNlIFtFQ0xJUFNF XSBhdHRhY2sgb24gdGhlIGluaXRpYWwNCmluamVjdG9ycyBvZiB0aGUgY29udGVudCAoaW4gcGFy dGljdWxhciBpbiBsaXZlIHN0cmVhbWluZykuIFRoZSBhdHRhY2sNCnRyaWVzIHRvIGxldCB0aGUg aW5qZWN0b3IgdXBsb2FkIHRvIGp1c3QgbWFsaWNpb3VzIHBlZXJzIHdoaWNoIHRoZW4gZG8NCm5v dCBmb3J3YXJkIHRoZSBjb250ZW50IHRvIG90aGVycywgdGh1cyBzdG9wcGluZyB0aGUgZGlzdHJp YnV0aW9uLiBBbg0KRWNsaXBzZSBhdHRhY2sgY291bGQgYWxzbyBiZSBsYXVuY2hlZCBvbiBhbiBp bmRpdmlkdWFsIHBlZXIuIExldHRpbmcNCnRoZXNlIGluamVjdG9ycyBvbmx5IHVzZSB0cnVzdGVk IHRyYWNrZXJzIHRoYXQgcHJvdmlkZSB0cnVlIHJhbmRvbQ0Kc2FtcGxlcyBvZiB0aGUgcG9wdWxh dGlvbiBvciB1c2luZyBhIHNlY3VyZSBwZWVyIHNhbXBsaW5nIHNlcnZpY2UNCltQVVBQRVRDQVNU XSBjYW4gaGVscCBuZWdhdGUgc3VjaCBhbiBhdHRhY2suIg0KDQpTbyB3ZSBuZWVkIFBFWCBwcm90 ZWN0aW9uIGFzIGRpc2N1c3NlZCBpbiB0aGUgbWFpbCAiUHJvcG9zYWwgdG8gcmVzb2x2ZSANCklz c3VlIDE3KzIwLi4uIiBvZiBGZWIgMTR0aC4gSW4gYWRkaXRpb24sIGEgcGVlciBBIG11c3Qgbm90 DQpsZXQgb3RoZXIgcGVlcnMgVDEuLlROIGZpbGwgYWxsIGl0cyBhdmFpbGFibGUgY29ubmVjdGlv biBzbG90cywgaS5lLiwNCkEgbXVzdCBpbml0aWF0ZSBjb25uZWN0aW9ucyBpdHNlbGYgdG9vLCB0 byBwcmV2ZW50IGlzb2xhdGlvbi4NCg0KRnVydGhlcm1vcmUsIHRvIHByZXZlbnQgbWFsaWNpb3Vz IHBlZXJzIGNvbnN1bWluZyBhbGwgdXBsb2FkIGJhbmR3aWR0aCANCm9mIGEgcGVlciwgdGhlcmUg c2hvdWxkIGJlIGEgbGltaXQgb24gdGhlIHVwbG9hZCBjYXBhY2l0eSBhIHNpbmdsZSBwZWVyDQpj YW4gY29uc3VtZSwgZS5nLiB2aWEgYSBsaW1pdCBvbiB0aGUgbnVtYmVyIG9mIHJlcXVlc3RzIGFz IGluIA0KU2VjdXJlU3RyZWFtIFtTRUNTVFJFQU1dLiBBIG5hdHVyYWwgdXBwZXIgbGltaXQgb2Yg dGhpcyB1cGxvYWQgcXVvdHVtIGlzIA0KdGhlIGJpdHJhdGUgb2YgdGhlIGNvbnRlbnQuDQoNClBy b3RlY3Rpb24gYWdhaW5zdCBhbXBsaWZjYXRpb24gYXR0YWNrcyBzdWNoIGFzIG1lbnRpb25lZCBp biB0aGUgbWFpbCANCiJQcm9wb3NhbCB0byBzb2x2ZSBJc3N1ZSAjMjYiIG9mIEphbiAyNXRoIGFs c28gaGVscCB0byBzYXRpc2Z5IHRoaXMgDQpyZXF1aXJlbWVudC4NCg0KSWYgeW91IGtub3cgYW55 IG90aGVyIHJlc291cmNlIGV4aGF1c3Rpb24gYXR0YWNrcyBwb3NzaWJsZSwgcGxlYXNlIA0Kc3Vi bWl0IHRoZW0gd2l0aCBwcm9wb3NhbHMgb24gaG93IHRvIHNvbHZlIHRoZW0uDQoNCkknZCBsaWtl IHRvIHJhaXNlIHRoaXMgYXMgSXNzdWUgIzQyLCBhbmQgcHJvcG9zZSB0byBhZGQgcGFyYWdyYXBo cyB0bw0KU2VjdGlvbiA3IG9mIHRoZSBkcmFmdCB3aXRoIHRoZSBleHBsYW5hdGlvbiBJIGp1c3Qg Z2F2ZS4NCg0KDQo+ICAgICogUFBTUC5TRUMuUkVRLTc6IFBQU1AgU0hPVUxEIGJlIHJvYnVzdCwg aS5lLiwgd2hlbiBjZW50cmFsaXplZCB0cmFja2VyDQo+ICAgIGZhaWxzIHRoZSBQMlAgc3RyZWFt aW5nIHN5c3RlbSBTSE9VTEQgc3RpbGwgd29yayBieSBzdXBwb3J0aW5nDQo+ICAgIGRpc3RyaWJ1 dGVkIHRyYWNrZXJzLg0KDQpXZSBuZWVkIFBFWCBwcm90ZWN0aW9uIGFzIGRpc2N1c3NlZCBpbiB0 aGUgbWFpbCAiUHJvcG9zYWwgdG8gcmVzb2x2ZSANCklzc3VlIDE3KzIwLi4uIiBvZiBGZWIgMTR0 aC4gSSBwcm9wb3NlIHRvIHVwZGF0ZSBJc3N1ZSAyMCB0byBpbmRpY2F0ZSANCnRoYXQgdGhpcyBy ZXF1aXJlbWVudCBpcyByZWxhdGVkLg0KDQoNCj4gICAgKiBQUFNQLlNFQy5SRVEtOTogSW50ZWdy aXR5IG9mIHRoZSBzdHJlYW1pbmcgY29udGVudCBpbiBQUFNQIE1VU1QgYmUNCj4gICAgc3VwcG9y dGVkIHRvIHByb3ZpZGUgYSBwZWVyIHdpdGggdGhlIHBvc3NpYmlsaXR5IHRvIGlkZW50aWZ5DQo+ ICAgIGluYXV0aGVudGljIG1lZGlhIGNvbnRlbnQgKHVuZGVzaXJhYmxlIG1vZGlmaWVkIGJ5IG90 aGVyIGVudGl0aWVzDQo+ICAgIHJhdGhlciB0aGFuIGl0cyBnZW51aW5lIHNvdXJjZSkuICBUaGUg Y29ycmVzcG9uZGluZyBjaGVja3N1bQ0KPiAgICBkaXN0cmlidXRpb24gYW5kIHZlcmlmaWNhdGlv biBzY2hlbWUgU0hPVUxEIHNjYWxlIHdlbGwgaW4gUDJQDQo+ICAgIHN0cmVhbWluZyBzeXN0ZW0g YW5kIGJlIHJvYnVzdCBhZ2FpbnN0IGRpc3RydXN0ZnVsIHRyYWNrZXJzL3BlZXJzLg0KDQpUaGUg TWVya2xlIGhhc2ggdHJlZXMgbWVjaGFuaXNtIHByb3ZpZGVzIGNvbnRlbnQgaW50ZWdyaXR5IHBy b3RlY3Rpb24NCmFuZCBpcyBhbHJlYWR5IGV4cGxhaW5lZCBpbiB0aGUgZHJhZnQuIE1lcmtsZSBo YXNoIHRyZWVzIGNhbiBhbHNvIGJlIA0KdXNlZCBmb3IgbGl2ZSBzdHJlYW1pbmcuIEluIHRoYXQg Y29udGV4dCB3ZSBzaG91bGQgcXVvdGUgW0RJR1NJR0ZMT1ddLCANCnRoZSBzaWduYXR1cmUgYW1v cnRpemF0aW9uIHNjaGVtZSB0aGF0IGFsc28gdXNlcyBNZXJrbGUgdHJlZXMuDQoNCkknZCBsaWtl IHRvIHJhaXNlIGFkZGluZyB0aGUgcmVmZXJlbmNlIGFzIElzc3VlICM0My4gU3VwcG9ydCBmb3Ig DQptdWx0aXBsZSBjb250ZW50IGludGVncml0eSBzY2hlbWVzIHdpbGwgYmUgYWRkZWQgd2hlbiB3 ZSByZWFjaCBjb25jZW5zdXMgDQpvbiBJc3N1ZSAjMTArMTMgKHNlZSBteSBtYWlsIGRkLiBKYW4g MTh0aCkuDQoNCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoNCkNVLA0KICAgICBBcm5vDQoNCg0KDQpS ZWZlcmVuY2VzDQotLS0tLS0tLS0tDQpbQ0xPU0VEXSBOLiBCb3JjaCwgSy4gTWljaGVsbCwgSS4g QXJudHplbiwgYW5kIEQuIEdhYnJpamVsY2ljOiAiQWNjZXNzDQpjb250cm9sIHRvIEJpdFRvcnJl bnQgc3dhcm1zIHVzaW5nIGNsb3NlZCBzd2FybXMiLiBJbiBQcm9jZWVkaW5ncw0Kb2YgdGhlIDIw MTAgQUNNIHdvcmtzaG9wIG9uIEFkdmFuY2VkIHZpZGVvIHN0cmVhbWluZyB0ZWNobmlxdWVzDQpm b3IgcGVlci10by1wZWVyIG5ldHdvcmtzIGFuZCBzb2NpYWwgbmV0d29ya2luZyAoQVZTVFAyUCAn MTApLg0KQUNNLCBOZXcgWW9yaywgTlksIFVTQSwgMjUtMzAuDQpodHRwOi8vZG9pLmFjbS5vcmcv MTAuMTE0NS8xODc3ODkxLjE4Nzc4OTgNCg0KW0VOSENMT1NFRF0gVi4gSm92YW5vdmlraiwgRC4g R2FicmlqZWzEjWnEjSBhbmQgVC4gS2xvYnXEjWFyLiAiQWNjZXNzIA0KQ29udHJvbCBpbiBCaXRU b3JyZW50IFAyUCBOZXR3b3JrcyBVc2luZyB0aGUgRW5oYW5jZWQgQ2xvc2VkIFN3YXJtcw0KUHJv dG9jb2wiLiBJbiBQcm9jZWVkaW5ncyBvZiB0aGUgRmlmdGggSW50ZXJuYXRpb25hbCBDb25mZXJl bmNlIG9uIA0KRW1lcmdpbmcgU2VjdXJpdHkgSW5mb3JtYXRpb24sIFN5c3RlbXMgYW5kIFRlY2hu b2xvZ2llcyAoU0VDVVJXQVJFDQoyMDExKSwgcHAuIDk3LTEwMiwgTmljZSwgRnJhbmNlLCBBdWd1 c3QgMjAxMS4NCg0KW1NFQ1NUUkVBTV0gTWF5YSBIYXJpZGFzYW4gYW5kIFJvYmJlcnQgdmFuIFJl bmVzc2UuICJTZWN1cmVTdHJlYW06IEFuIA0KSW50cnVzaW9uLVRvbGVyYW50IFByb3RvY29sIGZv ciBMaXZlLVN0cmVhbWluZyBEaXNzZW1pbmF0aW9uIi4gVGhlIA0KSm91cm5hbCBvZiBDb21wdXRl ciBDb21tdW5pY2F0aW9uJ3MgU3BlY2lhbCBpc3N1ZSBvbiBGb3VuZGF0aW9uIG9mIA0KUGVlci10 by1QZWVyIENvbXB1dGluZy4gVm9sdW1lIDMxIE51bWJlciAyLCBFbHNldmllciwgMjAwOC4NCg0K W0RJR1NJR0ZMT1ddIENodW5nIEtlaSBXb25nIGFuZCBTaW1vbiBTLiBMYW0uICJEaWdpdGFsIFNp Z25hdHVyZXMgZm9yIA0KRmxvd3MgYW5kIE11bHRpY2FzdHMiLiBJRUVFL0FDTSBUcmFuc2FjdGlv bnMgb24gTmV0d29ya2luZywNClZvbHVtZSA3LCAgSXNzdWUgNCwgcHAuIDUwMi01MTMsIEF1ZyAx OTk5Lg0KaHR0cDovL2R4LmRvaS5vcmcvMTAuMTEwOS85MC43OTMwMDUNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBz cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart826730411584_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF
Hi all,
    Arno proposed some=20 new issues derived from PPSP requirements as belo= w. It=20 would be great that some experts would look at the=20 mail and say if you agree with the = ;changes 
Arno=20 wants to make to the peer protocol text= .
    Ticket #4=EF=BC=9AReview the following proposals a= nd say if you=20 agree with the changes.
      If nobody expressed&nbs= p;any concern or alternative proposal=20 regarding security issues (with the same deadline as ticket #1=EF=BC=8C Ma= y=20 26th=EF=BC=89, we propose to move on and would=20 ask Arno to proceeds with the changes i= n the peer protocol draft.
 
BR
Yunfei
   
 
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-02-14 21:24
To: ppsp
Subject: [ppsp] New issues derived from PPSP=20 requirements...
Hi
 
I've gone over the requirements list in=  draft-ietf-ppsp-reqs-05
and identified some issues (mostly security&= nbsp;related) that need to be 
discussed in the WG:
 
> * "PPSP.REQ-8: The tracker and pee= r protocol together MUST facilitate
>   acceptable QoS (e.g. low st= artup delay, low channel/content switching
>   time and minimal end-to-end = ;delay) for both on-demand and live
>   streaming, even for very po= pular content.  The tracker and peer
>   protocol do not include the=  algorithm required for scalable
>   streaming.  However, the tr= acker and peer protocol SHALL NOT restrict
>   or place limits on any = ;such algorithm.
>
>   There are basic QoS require= ments for streaming system.  Setup time = ;to
>   receive a new streaming cha= nnel or to switch between channels should
>   be reasonable small.  End&n= bsp;to end delay (time between content
>   generation, e.g. camera and = ;content consumption, e.g. user side
>   monitor) will become critical&nb= sp;in case of live streaming.  Especially
>   in provisioning of sports e= vents, end to end delay of 1 minute&nbs= p;and
>   more are not acceptable.
>
>   For instance, the tracker a= nd peer protocols can support carrying QoS
>   related parameters (e.g. video&n= bsp;quality, delay requirements) together
>   with the priorities of thes= e parameters, and QoS situation (e.g.
>   performance, available uplink ba= ndwidth) of content providing peers.
>
>   There are also some other&n= bsp;possible mechanisms, e.g. addition of super
>   peers, in-network storage, reque= st of alternative peer addresses, and
>   the usage of QoS informatio= n for an advanced peer selection."
 
The current protocol has been designed = for short-time-till-playback,
unless limited by security considerations (c= f. Issue #26 security of
handshakes). Otherwise it operates in a = ;best effort mode.
 
But perhaps more is needed, as indicate= d in the description. Also
relevant is issue 12 (=3DSupport for UN= HINT), as that helps in making
requesting chunks from multiple peers at&nbs= p;the same time efficient,
as you can cancel the duplicates when&n= bsp;you receive an answer.
You may need double requests when some&= nbsp;peers are slow and strong QoS
is needed.
 
I'd like to raise this as Issue #3= 5.
 
 
>   * PPSP.PP.REQ-3: The streaming&n= bsp;content availability request message
>    SHOULD allow the peer = ;to solicit an additional list of peers = ;to that
>    received from the tracker&= nbsp;- with the same swarm ID.  The&nbs= p;reply
>    message MUST contain swarm= -membership information of the peers that
>    have explicitly indicated = they are part of the swarm, verifiable = by
>    the receiver.  This a= dditional list of peers MUST only contain&nb= sp;peers
>    which have been checked&nb= sp;to be valid and online recently (e.g.&nbs= p;prevent
>    hearsay and DoS).
>
>    It is possible that a=  peer may need additional peers for cer= tain
>    streaming content.  Theref= ore, it is allowed that the peer
>    communicates with the peer= s in the current peer list to obtain&nb= sp;an
>    additional list of peers&n= bsp;in the same swarm.
 
The draft uses PEX_* messages for this,=  hence I propose to rephrase this 
requirement, or declare PEX as sufficient&nb= sp;to satisfy this requirement.
 
 
>    * PPSP.PP.REQ-6: The peer&= nbsp;status report/update SHOULD be advertised
>    among the peers to re= flect the status of the peer.
>
>    Peer status information sh= ould be advertised among the peers via = the
>    peer status report/update = message.  For example, peer status can = be
>    online time, physical link=  status including DSL/WIFI/etc, battery
>    status, processing capability,&= nbsp;and other capabilities of the peer.
>    With this information, a&n= bsp;peer can select more appropriate peers f= or
>    streaming.
 
I'd like to raise this as Issue #3= 6.
 
 
>    * PPSP.SEC.REQ-1: PPSP MUS= T support closed swarms, where the peers&nbs= p;are
>    authenticated.
>
>    This ensures that only&nbs= p;the authenticated users can access the
>    original media in the = ;P2P streaming system.  This can be ach= ieved by
>    security mechanisms such a= s user authentication and/or key management
>    scheme.
 
I'd like to raise this as Issue #3= 7.
 
In addition, I propose the following so= lution: The Closed Swarms 
[CLOSED] and Enchanced Closed Swarms [ENHCLO= SED] mechanisms developed in 
the P2P-Next project provide swarm-level acc= ess control.
The basic idea is that a peer cann= ot download from another peer unless 
it shows a Proof-of-Access. Enhanced Closed&= nbsp;Swarms improve on the 
original Closed Swarms by adding on-the-wire=  encryption against 
man-in-the-middle attacks and more flexible = access control rules.
 
I propose to describe Enhanced Closed S= warms as one of the mechanisms 
(please put forward others if you know&= nbsp;about them) to satisfy the 
requirement and include it as a Section=  in the WG draft.
 
 
>   * PPSP.SEC.REQ-2: Confidentiality&nbs= p;of the streaming content in PPSP
>    SHOULD be supported and&nb= sp;the corresponding key management scheme
>    SHOULD scale well in = P2P streaming system.
>
 
No extra mechanism is needed in to = ;support confidentiality in PPSPP. A
content publisher wishing confidentiality should&= nbsp;just distribute content 
in cyphertext / DRM-ed format. I assume=  a higher layer handles key 
management out-of-band. Alternatively, the swarm&= nbsp;access control will 
point-to-point encrypt content.
 
I'd like to raise this as Issue #3= 8, and propose to add a paragraph to
Section 7 of the draft with the ex= planation I just gave.
 
 
>   * PPSP.SEC.REQ-3: PPSP MUST = ;provide an option to encrypt the data
>    exchange among the PPSP&nb= sp;entities.
>
 
If this requirement means that all PPSP= P messages should be encrypted 
(as opposed to just content in SEC.REQ-= 2), IPsec or DTLS is the obvious 
solution.
 
I'd like to raise this as Issue #3= 9, and propose to add a paragraph to
Section 7 of the draft with the ex= planation I just gave. Furthermore,
a key distribution scheme would have to=  be added.
 
 
>    * PPSP.SEC.REQ-4: PPSP MUS= T have mechanisms to limit potential damage<= /DIV>
>    caused by malfunctioning a= nd badly behaving peers in the P2P
>    streaming system.
>
>    Such an attack will d= egrade the quality of the rendered media&nbs= p;at the
>    receiver.  For example,&nb= sp;in a P2P live video streaming system = ;a
>    polluter can introduce cor= rupted chunks.  Each receiver integrates
>    into its playback stream&n= bsp;the polluted chunks it receives from its=
>    other neighbors.  Since&nb= sp;the peers forwards chunks to other peers,=  the
>    polluted content can poten= tially spread through much of the P2P
>    streaming network.
 
Content integrity protection helps here. I'd=  like to raise this as Issue 
#40 and will provide a per-message anal= ysis of issues later.
 
 
>    * PPSP.SEC.REQ-5: PPSP SHO= ULD support identifying badly behaving peers,
>    and exclude or reject = ;them from the P2P streaming system.
 
Quoting WG draft 6.3.2.3: "The Merkle t= ree hashing scheme allows a 
receiving peer to detect a malicious or=  faulty sender, which it can 
subsequently ignore. Spreading this knowledge&nbs= p;to other peers such that 
they know about this bad behavior is&nb= sp;hearsay."
 
So we can provide protection, but to&nb= sp;actually oust bad peers permanently 
from the system, access control and a&n= bsp;reliable accusation system is 
needed that is itself protected against = ;malicious peers reporting about 
good peers. Such a system is complex.
I'd like to raise this as Issue #4= 1, and propose to add a paragraph to
Section 7 of the draft with the ex= planation I just gave.
 
 
>   * PPSP.SEC.REQ-6: PPSP MUST = ;prevent peers from DoS attacks which will
>    exhaust the P2P streaming&= nbsp;system's available resource.
>
>    Given the prevalence of&nb= sp;DoS attacks in the Internet, it is i= mportant
>    to realize that a sim= ilar threat could exist in a large-scale
>    streaming system where att= ackers are capable of consuming a lot o= f
>    resources with just a = ;small amount of effort.
 
Quoting WG draft 6.3.2.3: "A risk in&nb= sp;peer-to-peer streaming systems is 
that malicious peers launch an Eclipse = [ECLIPSE] attack on the initial
injectors of the content (in particular = ;in live streaming). The attack
tries to let the injector upload to&nbs= p;just malicious peers which then do
not forward the content to others, thus=  stopping the distribution. An
Eclipse attack could also be launched o= n an individual peer. Letting
these injectors only use trusted trackers&nb= sp;that provide true random
samples of the population or using a&nb= sp;secure peer sampling service
[PUPPETCAST] can help negate such an at= tack."
 
So we need PEX protection as discussed&= nbsp;in the mail "Proposal to resolve 
Issue 17+20..." of Feb 14th. In additio= n, a peer A must not
let other peers T1..TN fill all its&nbs= p;available connection slots, i.e.,
A must initiate connections itself too, = ;to prevent isolation.
 
Furthermore, to prevent malicious peers cons= uming all upload bandwidth 
of a peer, there should be a limit=  on the upload capacity a single peer
can consume, e.g. via a limit on t= he number of requests as in 
SecureStream [SECSTREAM]. A natural upper li= mit of this upload quotum is 
the bitrate of the content.
 
Protection against amplifcation attacks such = ;as mentioned in the mail 
"Proposal to solve Issue #26" of Jan&nb= sp;25th also help to satisfy this 
requirement.
 
If you know any other resource exhausti= on attacks possible, please 
submit them with proposals on how to&nb= sp;solve them.
 
I'd like to raise this as Issue #4= 2, and propose to add paragraphs to
Section 7 of the draft with the ex= planation I just gave.
 
 
>    * PPSP.SEC.REQ-7: PPSP SHO= ULD be robust, i.e., when centralized tracke= r
>    fails the P2P streaming&nb= sp;system SHOULD still work by supporting
>    distributed trackers.
 
We need PEX protection as discussed in&= nbsp;the mail "Proposal to resolve 
Issue 17+20..." of Feb 14th. I propose&= nbsp;to update Issue 20 to indicate 
that this requirement is related.
 
 
>    * PPSP.SEC.REQ-9: Integrity&nbs= p;of the streaming content in PPSP MUST = ;be
>    supported to provide a&nbs= p;peer with the possibility to identify
>    inauthentic media content = (undesirable modified by other entities
>    rather than its genuine&nb= sp;source).  The corresponding checksum
>    distribution and verification&n= bsp;scheme SHOULD scale well in P2P
>    streaming system and be&nb= sp;robust against distrustful trackers/peers.
 
The Merkle hash trees mechanism provides&nbs= p;content integrity protection
and is already explained in the draft.&= nbsp;Merkle hash trees can also be 
used for live streaming. In that contex= t we should quote [DIGSIGFLOW], 
the signature amortization scheme that also&= nbsp;uses Merkle trees.
 
I'd like to raise adding the reference&= nbsp;as Issue #43. Support for 
multiple content integrity schemes will be&n= bsp;added when we reach concensus 
on Issue #10+13 (see my mail dd. J= an 18th).
 
 
What do you think?
 
CU,
     Arno
 
 
 
References
----------
[CLOSED] N. Borch, K. Michell, I. Arntz= en, and D. Gabrijelcic: "Access
control to BitTorrent swarms using closed&nb= sp;swarms". In Proceedings
of the 2010 ACM workshop on Advanced&nb= sp;video streaming techniques
for peer-to-peer networks and social network= ing (AVSTP2P '10).
ACM, New York, NY, USA, 25-30.
http://doi.acm.org/10.1145/1877891.1877898
 
[ENHCLOSED] V. Jovanovikj, D. Gabrijel=C4=8Di=C4= =8D and T. Klobu=C4=8Dar. "Access 
Control in BitTorrent P2P Networks Using&nbs= p;the Enhanced Closed Swarms
Protocol". In Proceedings of the Fifth = International Conference on 
Emerging Security Information, Systems and T= echnologies (SECURWARE
2011), pp. 97-102, Nice, France, August = ;2011.
 
[SECSTREAM] Maya Haridasan and Robbert van&n= bsp;Renesse. "SecureStream: An 
Intrusion-Tolerant Protocol for Live-Streaming Di= ssemination". The 
Journal of Computer Communication's Special = issue on Foundation of 
Peer-to-Peer Computing. Volume 31 Number 2,&= nbsp;Elsevier, 2008.
 
[DIGSIGFLOW] Chung Kei Wong and Simon S= . Lam. "Digital Signatures for 
Flows and Multicasts". IEEE/ACM Transactions = ;on Networking,
Volume 7,  Issue 4, pp. 502-513, A= ug 1999.
http://dx.doi.org/10.1109/90.793005
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart826730411584_=------ From sprevidi@cisco.com Fri May 4 02:21: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 DBD3521F86C2 for ; Fri, 4 May 2012 02:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuZkI0alaq11 for ; Fri, 4 May 2012 02:21:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3099221F862F for ; Fri, 4 May 2012 02:21:05 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q449L4YK024516 for ; Fri, 4 May 2012 11:21:04 +0200 (CEST) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-21.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-21.cisco.com [10.147.74.21]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q449L3h9014579; Fri, 4 May 2012 11:21:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=utf-8 From: stefano previdi X-Priority: 3 (Normal) In-Reply-To: <20120504165949894797116@chinamobile.com> Date: Fri, 4 May 2012 11:21:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37F1319C-A181-4937-AA7B-1E44CA40FACC@cisco.com> References: <20120504165949894797116@chinamobile.com> To: zhangyunfei X-Mailer: Apple Mail (2.1257) Cc: ppsp Subject: Re: [ppsp] One more ticket for Peer protocol security requirement issues X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 09:21:07 -0000 Thanks Yunfei and Arno, I'd like to stress the fact that Arno's proposal has been sent out=20 on february this year so it's time for the WG to close the issue=20 reasonably soon. thanks. s. On May 4, 2012, at 10:59 AM, zhangyunfei wrote: > Hi all, > Arno proposed some new issues derived from PPSP requirements as = below. It would be great that some experts would look at the mail and = say if you agree with the changes=20 > Arno wants to make to the peer protocol text. > Ticket #4=EF=BC=9AReview the following proposals and say if you = agree with the changes. > If nobody expressed any concern or alternative proposal = regarding security issues (with the same deadline as ticket #1=EF=BC=8C = May 26th=EF=BC=89, we propose to move on and would ask Arno to proceeds = with the changes in the peer protocol draft. > =20 > BR > Yunfei > =20 > =20 > =20 > zhangyunfei > =20 > From: Arno Bakker > Date: 2012-02-14 21:24 > To: ppsp > Subject: [ppsp] New issues derived from PPSP requirements... > Hi > =20 > I've gone over the requirements list in draft-ietf-ppsp-reqs-05 > and identified some issues (mostly security related) that need to be=20= > discussed in the WG: > =20 > > * "PPSP.REQ-8: 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 on-demand and live > > 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. > > > > There are basic QoS requirements for streaming system. Setup time = to > > receive a new streaming channel or to switch between channels = should > > be reasonable small. End to end delay (time between content > > generation, e.g. camera and content consumption, e.g. user side > > monitor) will become critical in case of live streaming. = Especially > > in provisioning of sports events, end to end delay of 1 minute and > > more are not acceptable. > > > > For instance, the tracker and peer protocols can support carrying = QoS > > related parameters (e.g. video quality, delay requirements) = together > > with the priorities of these parameters, and QoS situation (e.g. > > performance, available uplink bandwidth) of content providing = peers. > > > > There are also some other possible mechanisms, e.g. addition of = super > > peers, in-network storage, request of alternative peer addresses, = and > > the usage of QoS information for an advanced peer selection." > =20 > The current protocol has been designed for short-time-till-playback, > unless limited by security considerations (cf. Issue #26 security of > handshakes). Otherwise it operates in a best effort mode. > =20 > But perhaps more is needed, as indicated in the description. Also > relevant is issue 12 (=3DSupport for UNHINT), as that helps in making > requesting chunks from multiple peers at the same time efficient, > as you can cancel the duplicates when you receive an answer. > You may need double requests when some peers are slow and strong QoS > is needed. > =20 > I'd like to raise this as Issue #35. > =20 > =20 > > * PPSP.PP.REQ-3: The streaming content availability request = message > > SHOULD allow the peer to solicit an additional list of peers to = that > > received from the tracker - with the same swarm ID. The reply > > message MUST contain swarm-membership information of the peers = that > > have explicitly indicated they are part of the swarm, verifiable = by > > the receiver. This additional list of peers MUST only contain = peers > > which have been checked to be valid and online recently (e.g. = prevent > > hearsay and DoS). > > > > It is possible that a peer may need additional peers for certain > > streaming content. Therefore, it is allowed that the peer > > communicates with the peers in the current peer list to obtain an > > additional list of peers in the same swarm. > =20 > The draft uses PEX_* messages for this, hence I propose to rephrase = this=20 > requirement, or declare PEX as sufficient to satisfy this requirement. > =20 > =20 > > * PPSP.PP.REQ-6: The peer status report/update SHOULD be = advertised > > among the peers to reflect the status of the peer. > > > > Peer status information should be advertised among the peers via = the > > peer status report/update message. For example, peer status can = be > > online time, physical link status including DSL/WIFI/etc, battery > > status, processing capability, and other capabilities of the = peer. > > With this information, a peer can select more appropriate peers = for > > streaming. > =20 > I'd like to raise this as Issue #36. > =20 > =20 > > * PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the = peers are > > authenticated. > > > > This ensures that only the authenticated users can access the > > original media in the P2P streaming system. This can be achieved = by > > security mechanisms such as user authentication and/or key = management > > scheme. > =20 > I'd like to raise this as Issue #37. > =20 > In addition, I propose the following solution: The Closed Swarms=20 > [CLOSED] and Enchanced Closed Swarms [ENHCLOSED] mechanisms developed = in=20 > the P2P-Next project provide swarm-level access control. > The basic idea is that a peer cannot download from another peer unless=20= > it shows a Proof-of-Access. Enhanced Closed Swarms improve on the=20 > original Closed Swarms by adding on-the-wire encryption against=20 > man-in-the-middle attacks and more flexible access control rules. > =20 > I propose to describe Enhanced Closed Swarms as one of the mechanisms=20= > (please put forward others if you know about them) to satisfy the=20 > requirement and include it as a Section in the WG draft. > =20 > =20 > > * PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP > > SHOULD be supported and the corresponding key management scheme > > SHOULD scale well in P2P streaming system. > > > =20 > No extra mechanism is needed in to support confidentiality in PPSPP. A > content publisher wishing confidentiality should just distribute = content=20 > in cyphertext / DRM-ed format. I assume a higher layer handles key=20 > management out-of-band. Alternatively, the swarm access control will=20= > point-to-point encrypt content. > =20 > I'd like to raise this as Issue #38, and propose to add a paragraph to > Section 7 of the draft with the explanation I just gave. > =20 > =20 > > * PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt the data > > exchange among the PPSP entities. > > > =20 > If this requirement means that all PPSPP messages should be encrypted=20= > (as opposed to just content in SEC.REQ-2), IPsec or DTLS is the = obvious=20 > solution. > =20 > I'd like to raise this as Issue #39, and propose to add a paragraph to > Section 7 of the draft with the explanation I just gave. Furthermore, > a key distribution scheme would have to be added. > =20 > =20 > > * PPSP.SEC.REQ-4: PPSP MUST have mechanisms to limit potential = damage > > caused by malfunctioning and badly behaving peers in the P2P > > streaming system. > > > > Such an attack will degrade the quality of the rendered media at = the > > receiver. For example, in a P2P live video streaming system a > > polluter can introduce corrupted chunks. Each receiver = integrates > > into its playback stream the polluted chunks it receives from its > > other neighbors. Since the peers forwards chunks to other peers, = the > > polluted content can potentially spread through much of the P2P > > streaming network. > =20 > Content integrity protection helps here. I'd like to raise this as = Issue=20 > #40 and will provide a per-message analysis of issues later. > =20 > =20 > > * PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving = peers, > > and exclude or reject them from the P2P streaming system. > =20 > Quoting WG draft 6.3.2.3: "The Merkle tree hashing scheme allows a=20 > receiving peer to detect a malicious or faulty sender, which it can=20 > subsequently ignore. Spreading this knowledge to other peers such that=20= > they know about this bad behavior is hearsay." > =20 > So we can provide protection, but to actually oust bad peers = permanently=20 > from the system, access control and a reliable accusation system is=20 > needed that is itself protected against malicious peers reporting = about=20 > good peers. Such a system is complex. > I'd like to raise this as Issue #41, and propose to add a paragraph to > Section 7 of the draft with the explanation I just gave. > =20 > =20 > > * PPSP.SEC.REQ-6: PPSP MUST prevent peers from DoS attacks which = will > > exhaust the P2P streaming system's available resource. > > > > Given the prevalence of DoS attacks in the Internet, it is = important > > to realize that a similar threat could exist in a large-scale > > streaming system where attackers are capable of consuming a lot = of > > resources with just a small amount of effort. > =20 > Quoting WG draft 6.3.2.3: "A risk in peer-to-peer streaming systems is=20= > that malicious peers launch an Eclipse [ECLIPSE] attack on the initial > injectors of the content (in particular in live streaming). The attack > tries to let the injector upload to just malicious peers which then do > not forward the content to others, thus stopping the distribution. An > Eclipse attack could also be launched on an individual peer. Letting > these injectors only use trusted trackers that provide true random > samples of the population or using a secure peer sampling service > [PUPPETCAST] can help negate such an attack." > =20 > So we need PEX protection as discussed in the mail "Proposal to = resolve=20 > Issue 17+20..." of Feb 14th. In addition, a peer A must not > let other peers T1..TN fill all its available connection slots, i.e., > A must initiate connections itself too, to prevent isolation. > =20 > Furthermore, to prevent malicious peers consuming all upload bandwidth=20= > of a peer, there should be a limit on the upload capacity a single = peer > can consume, e.g. via a limit on the number of requests as in=20 > SecureStream [SECSTREAM]. A natural upper limit of this upload quotum = is=20 > the bitrate of the content. > =20 > Protection against amplifcation attacks such as mentioned in the mail=20= > "Proposal to solve Issue #26" of Jan 25th also help to satisfy this=20 > requirement. > =20 > If you know any other resource exhaustion attacks possible, please=20 > submit them with proposals on how to solve them. > =20 > I'd like to raise this as Issue #42, and propose to add paragraphs to > Section 7 of the draft with the explanation I just gave. > =20 > =20 > > * PPSP.SEC.REQ-7: PPSP SHOULD be robust, i.e., when centralized = tracker > > fails the P2P streaming system SHOULD still work by supporting > > distributed trackers. > =20 > We need PEX protection as discussed in the mail "Proposal to resolve=20= > Issue 17+20..." of Feb 14th. I propose to update Issue 20 to indicate=20= > that this requirement is related. > =20 > =20 > > * PPSP.SEC.REQ-9: Integrity of the streaming content in PPSP MUST = be > > supported to provide a peer with the possibility to identify > > inauthentic media content (undesirable modified by other entities > > rather than its genuine source). The corresponding checksum > > distribution and verification scheme SHOULD scale well in P2P > > streaming system and be robust against distrustful = trackers/peers. > =20 > The Merkle hash trees mechanism provides content integrity protection > and is already explained in the draft. Merkle hash trees can also be=20= > used for live streaming. In that context we should quote [DIGSIGFLOW],=20= > the signature amortization scheme that also uses Merkle trees. > =20 > I'd like to raise adding the reference as Issue #43. Support for=20 > multiple content integrity schemes will be added when we reach = concensus=20 > on Issue #10+13 (see my mail dd. Jan 18th). > =20 > =20 > What do you think? > =20 > CU, > Arno > =20 > =20 > =20 > References > ---------- > [CLOSED] N. Borch, K. Michell, I. Arntzen, and D. Gabrijelcic: "Access > control to BitTorrent swarms using closed swarms". In Proceedings > of the 2010 ACM workshop on Advanced video streaming techniques > for peer-to-peer networks and social networking (AVSTP2P '10). > ACM, New York, NY, USA, 25-30. > http://doi.acm.org/10.1145/1877891.1877898 > =20 > [ENHCLOSED] V. Jovanovikj, D. Gabrijel=C4=8Di=C4=8D and T. Klobu=C4=8Dar= . "Access=20 > Control in BitTorrent P2P Networks Using the Enhanced Closed Swarms > Protocol". In Proceedings of the Fifth International Conference on=20 > Emerging Security Information, Systems and Technologies (SECURWARE > 2011), pp. 97-102, Nice, France, August 2011. > =20 > [SECSTREAM] Maya Haridasan and Robbert van Renesse. "SecureStream: An=20= > Intrusion-Tolerant Protocol for Live-Streaming Dissemination". The=20 > Journal of Computer Communication's Special issue on Foundation of=20 > Peer-to-Peer Computing. Volume 31 Number 2, Elsevier, 2008. > =20 > [DIGSIGFLOW] Chung Kei Wong and Simon S. Lam. "Digital Signatures for=20= > Flows and Multicasts". IEEE/ACM Transactions on Networking, > Volume 7, Issue 4, pp. 502-513, Aug 1999. > http://dx.doi.org/10.1109/90.793005 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From zhangyunfei@chinamobile.com Fri May 4 08:27:52 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 475E821F8760 for ; Fri, 4 May 2012 08:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.753 X-Spam-Level: X-Spam-Status: No, score=-96.753 tagged_above=-999 required=5 tests=[AWL=3.623, BAYES_00=-2.599, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6HvpnjPkRXV for ; Fri, 4 May 2012 08:27:50 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7939221F86D0 for ; Fri, 4 May 2012 08:27:49 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 57888E5D2; Fri, 4 May 2012 23:27:46 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 3E5FCE59B; Fri, 4 May 2012 23:27:46 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012050423274301-33316 ; Fri, 4 May 2012 23:27:43 +0800 Date: Fri, 4 May 2012 23:27:37 +0800 From: zhangyunfei To: "arno@cs.vu.nl" , ppsp References: <4F3A60A8.6080800@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <20120504232737840796151@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-04 23:27:44, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-04 23:27:45, Serialize complete at 2012-05-04 23:27:45 Content-Type: multipart/alternative; boundary="----=_001_NextPart820333372318_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18886.000 X-TM-AS-Result: No--3.701-7.0-31-10 X-imss-scan-details: No--3.701-7.0-31-10;No--3.701-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] New issues derived from PPSP requirements... 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, 04 May 2012 15:27:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart820333372318_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGkgQXJubyBhbmQgYWxsLA0KICAgUGxzIHNlZSBpbmxpbmUgZm9yIHRoZSBjb21tZW50cy4gIEJl Y2F1c2UgSSBhbSBub3QgYSBzZWN1cml0eSBleHBlcnQsIG1vcmUgZXhwZXJ0aXNlIGFyZSBleHBl Y3RlZC4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJh a2tlcg0KRGF0ZTogMjAxMi0wMi0xNCAyMToyNA0KVG86IHBwc3ANClN1YmplY3Q6IFtwcHNwXSBO ZXcgaXNzdWVzIGRlcml2ZWQgZnJvbSBQUFNQIHJlcXVpcmVtZW50cy4uLg0KSGkNCg0KSSd2ZSBn b25lIG92ZXIgdGhlIHJlcXVpcmVtZW50cyBsaXN0IGluIGRyYWZ0LWlldGYtcHBzcC1yZXFzLTA1 DQphbmQgaWRlbnRpZmllZCBzb21lIGlzc3VlcyAobW9zdGx5IHNlY3VyaXR5IHJlbGF0ZWQpIHRo YXQgbmVlZCB0byBiZSANCmRpc2N1c3NlZCBpbiB0aGUgV0c6DQoNCj4gKiAiUFBTUC5SRVEtODog VGhlIHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2wgdG9nZXRoZXIgTVVTVCBmYWNpbGl0YXRlDQo+ ICAgYWNjZXB0YWJsZSBRb1MgKGUuZy4gbG93IHN0YXJ0dXAgZGVsYXksIGxvdyBjaGFubmVsL2Nv bnRlbnQgc3dpdGNoaW5nDQo+ICAgdGltZSBhbmQgbWluaW1hbCBlbmQtdG8tZW5kIGRlbGF5KSBm b3IgYm90aCBvbi1kZW1hbmQgYW5kIGxpdmUNCj4gICBzdHJlYW1pbmcsIGV2ZW4gZm9yIHZlcnkg cG9wdWxhciBjb250ZW50LiAgVGhlIHRyYWNrZXIgYW5kIHBlZXINCj4gICBwcm90b2NvbCBkbyBu b3QgaW5jbHVkZSB0aGUgYWxnb3JpdGhtIHJlcXVpcmVkIGZvciBzY2FsYWJsZQ0KPiAgIHN0cmVh bWluZy4gIEhvd2V2ZXIsIHRoZSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29sIFNIQUxMIE5PVCBy ZXN0cmljdA0KPiAgIG9yIHBsYWNlIGxpbWl0cyBvbiBhbnkgc3VjaCBhbGdvcml0aG0uDQo+DQo+ ICAgVGhlcmUgYXJlIGJhc2ljIFFvUyByZXF1aXJlbWVudHMgZm9yIHN0cmVhbWluZyBzeXN0ZW0u ICBTZXR1cCB0aW1lIHRvDQo+ICAgcmVjZWl2ZSBhIG5ldyBzdHJlYW1pbmcgY2hhbm5lbCBvciB0 byBzd2l0Y2ggYmV0d2VlbiBjaGFubmVscyBzaG91bGQNCj4gICBiZSByZWFzb25hYmxlIHNtYWxs LiAgRW5kIHRvIGVuZCBkZWxheSAodGltZSBiZXR3ZWVuIGNvbnRlbnQNCj4gICBnZW5lcmF0aW9u LCBlLmcuIGNhbWVyYSBhbmQgY29udGVudCBjb25zdW1wdGlvbiwgZS5nLiB1c2VyIHNpZGUNCj4g ICBtb25pdG9yKSB3aWxsIGJlY29tZSBjcml0aWNhbCBpbiBjYXNlIG9mIGxpdmUgc3RyZWFtaW5n LiAgRXNwZWNpYWxseQ0KPiAgIGluIHByb3Zpc2lvbmluZyBvZiBzcG9ydHMgZXZlbnRzLCBlbmQg dG8gZW5kIGRlbGF5IG9mIDEgbWludXRlIGFuZA0KPiAgIG1vcmUgYXJlIG5vdCBhY2NlcHRhYmxl Lg0KPg0KPiAgIEZvciBpbnN0YW5jZSwgdGhlIHRyYWNrZXIgYW5kIHBlZXIgcHJvdG9jb2xzIGNh biBzdXBwb3J0IGNhcnJ5aW5nIFFvUw0KPiAgIHJlbGF0ZWQgcGFyYW1ldGVycyAoZS5nLiB2aWRl byBxdWFsaXR5LCBkZWxheSByZXF1aXJlbWVudHMpIHRvZ2V0aGVyDQo+ICAgd2l0aCB0aGUgcHJp b3JpdGllcyBvZiB0aGVzZSBwYXJhbWV0ZXJzLCBhbmQgUW9TIHNpdHVhdGlvbiAoZS5nLg0KPiAg IHBlcmZvcm1hbmNlLCBhdmFpbGFibGUgdXBsaW5rIGJhbmR3aWR0aCkgb2YgY29udGVudCBwcm92 aWRpbmcgcGVlcnMuDQo+DQo+ICAgVGhlcmUgYXJlIGFsc28gc29tZSBvdGhlciBwb3NzaWJsZSBt ZWNoYW5pc21zLCBlLmcuIGFkZGl0aW9uIG9mIHN1cGVyDQo+ICAgcGVlcnMsIGluLW5ldHdvcmsg c3RvcmFnZSwgcmVxdWVzdCBvZiBhbHRlcm5hdGl2ZSBwZWVyIGFkZHJlc3NlcywgYW5kDQo+ICAg dGhlIHVzYWdlIG9mIFFvUyBpbmZvcm1hdGlvbiBmb3IgYW4gYWR2YW5jZWQgcGVlciBzZWxlY3Rp b24uIg0KDQpUaGUgY3VycmVudCBwcm90b2NvbCBoYXMgYmVlbiBkZXNpZ25lZCBmb3Igc2hvcnQt dGltZS10aWxsLXBsYXliYWNrLA0KdW5sZXNzIGxpbWl0ZWQgYnkgc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgKGNmLiBJc3N1ZSAjMjYgc2VjdXJpdHkgb2YNCmhhbmRzaGFrZXMpLiBPdGhlcndpc2Ug aXQgb3BlcmF0ZXMgaW4gYSBiZXN0IGVmZm9ydCBtb2RlLg0KDQpCdXQgcGVyaGFwcyBtb3JlIGlz IG5lZWRlZCwgYXMgaW5kaWNhdGVkIGluIHRoZSBkZXNjcmlwdGlvbi4gQWxzbw0KcmVsZXZhbnQg aXMgaXNzdWUgMTIgKD1TdXBwb3J0IGZvciBVTkhJTlQpLCBhcyB0aGF0IGhlbHBzIGluIG1ha2lu Zw0KcmVxdWVzdGluZyBjaHVua3MgZnJvbSBtdWx0aXBsZSBwZWVycyBhdCB0aGUgc2FtZSB0aW1l IGVmZmljaWVudCwNCmFzIHlvdSBjYW4gY2FuY2VsIHRoZSBkdXBsaWNhdGVzIHdoZW4geW91IHJl Y2VpdmUgYW4gYW5zd2VyLg0KWW91IG1heSBuZWVkIGRvdWJsZSByZXF1ZXN0cyB3aGVuIHNvbWUg cGVlcnMgYXJlIHNsb3cgYW5kIHN0cm9uZyBRb1MNCmlzIG5lZWRlZC4NCg0KSSdkIGxpa2UgdG8g cmFpc2UgdGhpcyBhcyBJc3N1ZSAjMzUuDQoNCltZdW5mZWldIEkgdGhpbmsgdGhpcyBpcyBhIGZl YXNpYmxlIG1lY2hhbmlzbSBpbiB0aGUgcHJvdG9jb2wuDQoNCj4gICAqIFBQU1AuUFAuUkVRLTM6 IFRoZSBzdHJlYW1pbmcgY29udGVudCBhdmFpbGFiaWxpdHkgcmVxdWVzdCBtZXNzYWdlDQo+ICAg IFNIT1VMRCBhbGxvdyB0aGUgcGVlciB0byBzb2xpY2l0IGFuIGFkZGl0aW9uYWwgbGlzdCBvZiBw ZWVycyB0byB0aGF0DQo+ICAgIHJlY2VpdmVkIGZyb20gdGhlIHRyYWNrZXIgLSB3aXRoIHRoZSBz YW1lIHN3YXJtIElELiAgVGhlIHJlcGx5DQo+ICAgIG1lc3NhZ2UgTVVTVCBjb250YWluIHN3YXJt LW1lbWJlcnNoaXAgaW5mb3JtYXRpb24gb2YgdGhlIHBlZXJzIHRoYXQNCj4gICAgaGF2ZSBleHBs aWNpdGx5IGluZGljYXRlZCB0aGV5IGFyZSBwYXJ0IG9mIHRoZSBzd2FybSwgdmVyaWZpYWJsZSBi eQ0KPiAgICB0aGUgcmVjZWl2ZXIuICBUaGlzIGFkZGl0aW9uYWwgbGlzdCBvZiBwZWVycyBNVVNU IG9ubHkgY29udGFpbiBwZWVycw0KPiAgICB3aGljaCBoYXZlIGJlZW4gY2hlY2tlZCB0byBiZSB2 YWxpZCBhbmQgb25saW5lIHJlY2VudGx5IChlLmcuIHByZXZlbnQNCj4gICAgaGVhcnNheSBhbmQg RG9TKS4NCj4NCj4gICAgSXQgaXMgcG9zc2libGUgdGhhdCBhIHBlZXIgbWF5IG5lZWQgYWRkaXRp b25hbCBwZWVycyBmb3IgY2VydGFpbg0KPiAgICBzdHJlYW1pbmcgY29udGVudC4gIFRoZXJlZm9y ZSwgaXQgaXMgYWxsb3dlZCB0aGF0IHRoZSBwZWVyDQo+ICAgIGNvbW11bmljYXRlcyB3aXRoIHRo ZSBwZWVycyBpbiB0aGUgY3VycmVudCBwZWVyIGxpc3QgdG8gb2J0YWluIGFuDQo+ICAgIGFkZGl0 aW9uYWwgbGlzdCBvZiBwZWVycyBpbiB0aGUgc2FtZSBzd2FybS4NCg0KVGhlIGRyYWZ0IHVzZXMg UEVYXyogbWVzc2FnZXMgZm9yIHRoaXMsIGhlbmNlIEkgcHJvcG9zZSB0byByZXBocmFzZSB0aGlz IA0KcmVxdWlyZW1lbnQsIG9yIGRlY2xhcmUgUEVYIGFzIHN1ZmZpY2llbnQgdG8gc2F0aXNmeSB0 aGlzIHJlcXVpcmVtZW50Lg0KDQpbWXVuZmVpXSBEbyB5b3UgbWVhbiB0byByZXBocmFzZSB0aGlz IHJlcXVpcmVtZW50IGluIHdoaWNoIGRvY3VtZW50PyBQZWVyIHByb3RvY29sIG9yIG1lcmdlZCBy ZXF1aXJlbWVudHMgZHJhZnQ/DQpJIGFtIG9rYXkgdG8gc2VlIHRoZSBkZWNsYXJhdGlvbiBpbiB0 aGUgcGVlciBwcm90b2NvbC4NCg0KDQo+ICAgICogUFBTUC5QUC5SRVEtNjogVGhlIHBlZXIgc3Rh dHVzIHJlcG9ydC91cGRhdGUgU0hPVUxEIGJlIGFkdmVydGlzZWQNCj4gICAgYW1vbmcgdGhlIHBl ZXJzIHRvIHJlZmxlY3QgdGhlIHN0YXR1cyBvZiB0aGUgcGVlci4NCj4NCj4gICAgUGVlciBzdGF0 dXMgaW5mb3JtYXRpb24gc2hvdWxkIGJlIGFkdmVydGlzZWQgYW1vbmcgdGhlIHBlZXJzIHZpYSB0 aGUNCj4gICAgcGVlciBzdGF0dXMgcmVwb3J0L3VwZGF0ZSBtZXNzYWdlLiAgRm9yIGV4YW1wbGUs IHBlZXIgc3RhdHVzIGNhbiBiZQ0KPiAgICBvbmxpbmUgdGltZSwgcGh5c2ljYWwgbGluayBzdGF0 dXMgaW5jbHVkaW5nIERTTC9XSUZJL2V0YywgYmF0dGVyeQ0KPiAgICBzdGF0dXMsIHByb2Nlc3Np bmcgY2FwYWJpbGl0eSwgYW5kIG90aGVyIGNhcGFiaWxpdGllcyBvZiB0aGUgcGVlci4NCj4gICAg V2l0aCB0aGlzIGluZm9ybWF0aW9uLCBhIHBlZXIgY2FuIHNlbGVjdCBtb3JlIGFwcHJvcHJpYXRl IHBlZXJzIGZvcg0KPiAgICBzdHJlYW1pbmcuDQoNCkknZCBsaWtlIHRvIHJhaXNlIHRoaXMgYXMg SXNzdWUgIzM2Lg0KDQoNCj4gICAgKiBQUFNQLlNFQy5SRVEtMTogUFBTUCBNVVNUIHN1cHBvcnQg Y2xvc2VkIHN3YXJtcywgd2hlcmUgdGhlIHBlZXJzIGFyZQ0KPiAgICBhdXRoZW50aWNhdGVkLg0K Pg0KPiAgICBUaGlzIGVuc3VyZXMgdGhhdCBvbmx5IHRoZSBhdXRoZW50aWNhdGVkIHVzZXJzIGNh biBhY2Nlc3MgdGhlDQo+ICAgIG9yaWdpbmFsIG1lZGlhIGluIHRoZSBQMlAgc3RyZWFtaW5nIHN5 c3RlbS4gIFRoaXMgY2FuIGJlIGFjaGlldmVkIGJ5DQo+ICAgIHNlY3VyaXR5IG1lY2hhbmlzbXMg c3VjaCBhcyB1c2VyIGF1dGhlbnRpY2F0aW9uIGFuZC9vciBrZXkgbWFuYWdlbWVudA0KPiAgICBz Y2hlbWUuDQoNCkknZCBsaWtlIHRvIHJhaXNlIHRoaXMgYXMgSXNzdWUgIzM3Lg0KDQpJbiBhZGRp dGlvbiwgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgc29sdXRpb246IFRoZSBDbG9zZWQgU3dhcm1z IA0KW0NMT1NFRF0gYW5kIEVuY2hhbmNlZCBDbG9zZWQgU3dhcm1zIFtFTkhDTE9TRURdIG1lY2hh bmlzbXMgZGV2ZWxvcGVkIGluIA0KdGhlIFAyUC1OZXh0IHByb2plY3QgcHJvdmlkZSBzd2FybS1s ZXZlbCBhY2Nlc3MgY29udHJvbC4NClRoZSBiYXNpYyBpZGVhIGlzIHRoYXQgYSBwZWVyIGNhbm5v dCBkb3dubG9hZCBmcm9tIGFub3RoZXIgcGVlciB1bmxlc3MgDQppdCBzaG93cyBhIFByb29mLW9m LUFjY2Vzcy4gRW5oYW5jZWQgQ2xvc2VkIFN3YXJtcyBpbXByb3ZlIG9uIHRoZSANCm9yaWdpbmFs IENsb3NlZCBTd2FybXMgYnkgYWRkaW5nIG9uLXRoZS13aXJlIGVuY3J5cHRpb24gYWdhaW5zdCAN Cm1hbi1pbi10aGUtbWlkZGxlIGF0dGFja3MgYW5kIG1vcmUgZmxleGlibGUgYWNjZXNzIGNvbnRy b2wgcnVsZXMuDQoNCkkgcHJvcG9zZSB0byBkZXNjcmliZSBFbmhhbmNlZCBDbG9zZWQgU3dhcm1z IGFzIG9uZSBvZiB0aGUgbWVjaGFuaXNtcyANCihwbGVhc2UgcHV0IGZvcndhcmQgb3RoZXJzIGlm IHlvdSBrbm93IGFib3V0IHRoZW0pIHRvIHNhdGlzZnkgdGhlIA0KcmVxdWlyZW1lbnQgYW5kIGlu Y2x1ZGUgaXQgYXMgYSBTZWN0aW9uIGluIHRoZSBXRyBkcmFmdC4NCltZdW5mZWldIFNhbWUgcXVl c3Rpb24gYXMgYWJvdmUuIEluIHRoZSBwZWVyIHByb3RvY29sIGRyYWZ0PyBJZiBzbywgSSB0aGlu ayBpdCdzIG9rYXkuDQoNCg0KPiAgICogUFBTUC5TRUMuUkVRLTI6IENvbmZpZGVudGlhbGl0eSBv ZiB0aGUgc3RyZWFtaW5nIGNvbnRlbnQgaW4gUFBTUA0KPiAgICBTSE9VTEQgYmUgc3VwcG9ydGVk IGFuZCB0aGUgY29ycmVzcG9uZGluZyBrZXkgbWFuYWdlbWVudCBzY2hlbWUNCj4gICAgU0hPVUxE IHNjYWxlIHdlbGwgaW4gUDJQIHN0cmVhbWluZyBzeXN0ZW0uDQo+DQoNCk5vIGV4dHJhIG1lY2hh bmlzbSBpcyBuZWVkZWQgaW4gdG8gc3VwcG9ydCBjb25maWRlbnRpYWxpdHkgaW4gUFBTUFAuIEEN CmNvbnRlbnQgcHVibGlzaGVyIHdpc2hpbmcgY29uZmlkZW50aWFsaXR5IHNob3VsZCBqdXN0IGRp c3RyaWJ1dGUgY29udGVudCANCmluIGN5cGhlcnRleHQgLyBEUk0tZWQgZm9ybWF0LiBJIGFzc3Vt ZSBhIGhpZ2hlciBsYXllciBoYW5kbGVzIGtleSANCm1hbmFnZW1lbnQgb3V0LW9mLWJhbmQuIEFs dGVybmF0aXZlbHksIHRoZSBzd2FybSBhY2Nlc3MgY29udHJvbCB3aWxsIA0KcG9pbnQtdG8tcG9p bnQgZW5jcnlwdCBjb250ZW50Lg0KDQpJJ2QgbGlrZSB0byByYWlzZSB0aGlzIGFzIElzc3VlICMz OCwgYW5kIHByb3Bvc2UgdG8gYWRkIGEgcGFyYWdyYXBoIHRvDQpTZWN0aW9uIDcgb2YgdGhlIGRy YWZ0IHdpdGggdGhlIGV4cGxhbmF0aW9uIEkganVzdCBnYXZlLg0KW1l1bmZlaV0gSSBhbSBmaW5l IHdpdGggdGhpcy4NCg0KDQo+ICAgKiBQUFNQLlNFQy5SRVEtMzogUFBTUCBNVVNUIHByb3ZpZGUg YW4gb3B0aW9uIHRvIGVuY3J5cHQgdGhlIGRhdGENCj4gICAgZXhjaGFuZ2UgYW1vbmcgdGhlIFBQ U1AgZW50aXRpZXMuDQo+DQoNCklmIHRoaXMgcmVxdWlyZW1lbnQgbWVhbnMgdGhhdCBhbGwgUFBT UFAgbWVzc2FnZXMgc2hvdWxkIGJlIGVuY3J5cHRlZCANCihhcyBvcHBvc2VkIHRvIGp1c3QgY29u dGVudCBpbiBTRUMuUkVRLTIpLCBJUHNlYyBvciBEVExTIGlzIHRoZSBvYnZpb3VzIA0Kc29sdXRp b24uDQoNCkknZCBsaWtlIHRvIHJhaXNlIHRoaXMgYXMgSXNzdWUgIzM5LCBhbmQgcHJvcG9zZSB0 byBhZGQgYSBwYXJhZ3JhcGggdG8NClNlY3Rpb24gNyBvZiB0aGUgZHJhZnQgd2l0aCB0aGUgZXhw bGFuYXRpb24gSSBqdXN0IGdhdmUuIEZ1cnRoZXJtb3JlLA0KYSBrZXkgZGlzdHJpYnV0aW9uIHNj aGVtZSB3b3VsZCBoYXZlIHRvIGJlIGFkZGVkLg0KDQoNCj4gICAgKiBQUFNQLlNFQy5SRVEtNDog UFBTUCBNVVNUIGhhdmUgbWVjaGFuaXNtcyB0byBsaW1pdCBwb3RlbnRpYWwgZGFtYWdlDQo+ICAg IGNhdXNlZCBieSBtYWxmdW5jdGlvbmluZyBhbmQgYmFkbHkgYmVoYXZpbmcgcGVlcnMgaW4gdGhl IFAyUA0KPiAgICBzdHJlYW1pbmcgc3lzdGVtLg0KPg0KPiAgICBTdWNoIGFuIGF0dGFjayB3aWxs IGRlZ3JhZGUgdGhlIHF1YWxpdHkgb2YgdGhlIHJlbmRlcmVkIG1lZGlhIGF0IHRoZQ0KPiAgICBy ZWNlaXZlci4gIEZvciBleGFtcGxlLCBpbiBhIFAyUCBsaXZlIHZpZGVvIHN0cmVhbWluZyBzeXN0 ZW0gYQ0KPiAgICBwb2xsdXRlciBjYW4gaW50cm9kdWNlIGNvcnJ1cHRlZCBjaHVua3MuICBFYWNo IHJlY2VpdmVyIGludGVncmF0ZXMNCj4gICAgaW50byBpdHMgcGxheWJhY2sgc3RyZWFtIHRoZSBw b2xsdXRlZCBjaHVua3MgaXQgcmVjZWl2ZXMgZnJvbSBpdHMNCj4gICAgb3RoZXIgbmVpZ2hib3Jz LiAgU2luY2UgdGhlIHBlZXJzIGZvcndhcmRzIGNodW5rcyB0byBvdGhlciBwZWVycywgdGhlDQo+ ICAgIHBvbGx1dGVkIGNvbnRlbnQgY2FuIHBvdGVudGlhbGx5IHNwcmVhZCB0aHJvdWdoIG11Y2gg b2YgdGhlIFAyUA0KPiAgICBzdHJlYW1pbmcgbmV0d29yay4NCg0KQ29udGVudCBpbnRlZ3JpdHkg cHJvdGVjdGlvbiBoZWxwcyBoZXJlLiBJJ2QgbGlrZSB0byByYWlzZSB0aGlzIGFzIElzc3VlIA0K IzQwIGFuZCB3aWxsIHByb3ZpZGUgYSBwZXItbWVzc2FnZSBhbmFseXNpcyBvZiBpc3N1ZXMgbGF0 ZXIuDQpbWXVuZmVpXSBTb3VuZHMgZ29vZC4NCg0KDQo+ICAgICogUFBTUC5TRUMuUkVRLTU6IFBQ U1AgU0hPVUxEIHN1cHBvcnQgaWRlbnRpZnlpbmcgYmFkbHkgYmVoYXZpbmcgcGVlcnMsDQo+ICAg IGFuZCBleGNsdWRlIG9yIHJlamVjdCB0aGVtIGZyb20gdGhlIFAyUCBzdHJlYW1pbmcgc3lzdGVt Lg0KDQpRdW90aW5nIFdHIGRyYWZ0IDYuMy4yLjM6ICJUaGUgTWVya2xlIHRyZWUgaGFzaGluZyBz Y2hlbWUgYWxsb3dzIGEgDQpyZWNlaXZpbmcgcGVlciB0byBkZXRlY3QgYSBtYWxpY2lvdXMgb3Ig ZmF1bHR5IHNlbmRlciwgd2hpY2ggaXQgY2FuIA0Kc3Vic2VxdWVudGx5IGlnbm9yZS4gU3ByZWFk aW5nIHRoaXMga25vd2xlZGdlIHRvIG90aGVyIHBlZXJzIHN1Y2ggdGhhdCANCnRoZXkga25vdyBh Ym91dCB0aGlzIGJhZCBiZWhhdmlvciBpcyBoZWFyc2F5LiINCg0KU28gd2UgY2FuIHByb3ZpZGUg cHJvdGVjdGlvbiwgYnV0IHRvIGFjdHVhbGx5IG91c3QgYmFkIHBlZXJzIHBlcm1hbmVudGx5IA0K ZnJvbSB0aGUgc3lzdGVtLCBhY2Nlc3MgY29udHJvbCBhbmQgYSByZWxpYWJsZSBhY2N1c2F0aW9u IHN5c3RlbSBpcyANCm5lZWRlZCB0aGF0IGlzIGl0c2VsZiBwcm90ZWN0ZWQgYWdhaW5zdCBtYWxp Y2lvdXMgcGVlcnMgcmVwb3J0aW5nIGFib3V0IA0KZ29vZCBwZWVycy4gU3VjaCBhIHN5c3RlbSBp cyBjb21wbGV4Lg0KSSdkIGxpa2UgdG8gcmFpc2UgdGhpcyBhcyBJc3N1ZSAjNDEsIGFuZCBwcm9w b3NlIHRvIGFkZCBhIHBhcmFncmFwaCB0bw0KU2VjdGlvbiA3IG9mIHRoZSBkcmFmdCB3aXRoIHRo ZSBleHBsYW5hdGlvbiBJIGp1c3QgZ2F2ZS4NCltZdW5mZWldIEkgYWdyZWUgd2l0aCB0aGUgcmVx dWlyZW1lbnQgY2xhdXNlLiBKdXN0IGFzIGRpc2N1c3NlZCBpbiBsYXN0IElFVEYsDQpJIGJlbGll dmUgc3VjaCBmdW5jdGlvbmFsaXR5IGlzIGVzc2VudGlhbC4gSWYgd2UgY29uc2lkZXIgYSBzeXN0 ZW0gd2l0aCBzb21lIGRlZ3JlZSBvZiBtYWxpY291cyANCnBlZXJzLCB0aGUgbWVjaGFuaXNtIHRv IGlkZW50aWZ5IHRoZSBiYWRseSBwZWVycyBhbmQgZXhlY3V0ZSBhY2Nlc3MgY29udHJvbC4NClJl ZmVyZW5jZVtkZXRlY3RpbmcgbWFsaWNvdXMgcGVlcnNdIGNhbiBiZSBhIGdvb2Qgc3RhcnRpbmcg cG9pbnQuDQoNCltkZXRlY3RpbmcgbWFsaWNvdXMgcGVlcnNdIERldGVjdGluZyBNYWxpY2lvdXMg UGVlcnMgaW4gT3ZlcmxheSBNdWx0aWNhc3QgU3RyZWFtaW5nICwNClNhbWFydGggU2hldHR5LCBQ YXRyaWNpbyBHYWxkYW1lcywgV2FsbGFwYWsgVGF2YW5hcG9uZywgWWluZyBDYWksDQp3d3cuY3Mu aWFzdGF0ZS5lZHUvfnlpbmdjYWkvcHVibGljX2h0bWwvcHViL2xjbi5wZGYgIA0KDQoNCg0KPiAg ICogUFBTUC5TRUMuUkVRLTY6IFBQU1AgTVVTVCBwcmV2ZW50IHBlZXJzIGZyb20gRG9TIGF0dGFj a3Mgd2hpY2ggd2lsbA0KPiAgICBleGhhdXN0IHRoZSBQMlAgc3RyZWFtaW5nIHN5c3RlbSdzIGF2 YWlsYWJsZSByZXNvdXJjZS4NCj4NCj4gICAgR2l2ZW4gdGhlIHByZXZhbGVuY2Ugb2YgRG9TIGF0 dGFja3MgaW4gdGhlIEludGVybmV0LCBpdCBpcyBpbXBvcnRhbnQNCj4gICAgdG8gcmVhbGl6ZSB0 aGF0IGEgc2ltaWxhciB0aHJlYXQgY291bGQgZXhpc3QgaW4gYSBsYXJnZS1zY2FsZQ0KPiAgICBz dHJlYW1pbmcgc3lzdGVtIHdoZXJlIGF0dGFja2VycyBhcmUgY2FwYWJsZSBvZiBjb25zdW1pbmcg YSBsb3Qgb2YNCj4gICAgcmVzb3VyY2VzIHdpdGgganVzdCBhIHNtYWxsIGFtb3VudCBvZiBlZmZv cnQuDQoNClF1b3RpbmcgV0cgZHJhZnQgNi4zLjIuMzogIkEgcmlzayBpbiBwZWVyLXRvLXBlZXIg c3RyZWFtaW5nIHN5c3RlbXMgaXMgDQp0aGF0IG1hbGljaW91cyBwZWVycyBsYXVuY2ggYW4gRWNs aXBzZSBbRUNMSVBTRV0gYXR0YWNrIG9uIHRoZSBpbml0aWFsDQppbmplY3RvcnMgb2YgdGhlIGNv bnRlbnQgKGluIHBhcnRpY3VsYXIgaW4gbGl2ZSBzdHJlYW1pbmcpLiBUaGUgYXR0YWNrDQp0cmll cyB0byBsZXQgdGhlIGluamVjdG9yIHVwbG9hZCB0byBqdXN0IG1hbGljaW91cyBwZWVycyB3aGlj aCB0aGVuIGRvDQpub3QgZm9yd2FyZCB0aGUgY29udGVudCB0byBvdGhlcnMsIHRodXMgc3RvcHBp bmcgdGhlIGRpc3RyaWJ1dGlvbi4gQW4NCkVjbGlwc2UgYXR0YWNrIGNvdWxkIGFsc28gYmUgbGF1 bmNoZWQgb24gYW4gaW5kaXZpZHVhbCBwZWVyLiBMZXR0aW5nDQp0aGVzZSBpbmplY3RvcnMgb25s eSB1c2UgdHJ1c3RlZCB0cmFja2VycyB0aGF0IHByb3ZpZGUgdHJ1ZSByYW5kb20NCnNhbXBsZXMg b2YgdGhlIHBvcHVsYXRpb24gb3IgdXNpbmcgYSBzZWN1cmUgcGVlciBzYW1wbGluZyBzZXJ2aWNl DQpbUFVQUEVUQ0FTVF0gY2FuIGhlbHAgbmVnYXRlIHN1Y2ggYW4gYXR0YWNrLiINCg0KU28gd2Ug bmVlZCBQRVggcHJvdGVjdGlvbiBhcyBkaXNjdXNzZWQgaW4gdGhlIG1haWwgIlByb3Bvc2FsIHRv IHJlc29sdmUgDQpJc3N1ZSAxNysyMC4uLiIgb2YgRmViIDE0dGguIEluIGFkZGl0aW9uLCBhIHBl ZXIgQSBtdXN0IG5vdA0KbGV0IG90aGVyIHBlZXJzIFQxLi5UTiBmaWxsIGFsbCBpdHMgYXZhaWxh YmxlIGNvbm5lY3Rpb24gc2xvdHMsIGkuZS4sDQpBIG11c3QgaW5pdGlhdGUgY29ubmVjdGlvbnMg aXRzZWxmIHRvbywgdG8gcHJldmVudCBpc29sYXRpb24uDQoNCkZ1cnRoZXJtb3JlLCB0byBwcmV2 ZW50IG1hbGljaW91cyBwZWVycyBjb25zdW1pbmcgYWxsIHVwbG9hZCBiYW5kd2lkdGggDQpvZiBh IHBlZXIsIHRoZXJlIHNob3VsZCBiZSBhIGxpbWl0IG9uIHRoZSB1cGxvYWQgY2FwYWNpdHkgYSBz aW5nbGUgcGVlcg0KY2FuIGNvbnN1bWUsIGUuZy4gdmlhIGEgbGltaXQgb24gdGhlIG51bWJlciBv ZiByZXF1ZXN0cyBhcyBpbiANClNlY3VyZVN0cmVhbSBbU0VDU1RSRUFNXS4gQSBuYXR1cmFsIHVw cGVyIGxpbWl0IG9mIHRoaXMgdXBsb2FkIHF1b3R1bSBpcyANCnRoZSBiaXRyYXRlIG9mIHRoZSBj b250ZW50Lg0KDQpQcm90ZWN0aW9uIGFnYWluc3QgYW1wbGlmY2F0aW9uIGF0dGFja3Mgc3VjaCBh cyBtZW50aW9uZWQgaW4gdGhlIG1haWwgDQoiUHJvcG9zYWwgdG8gc29sdmUgSXNzdWUgIzI2IiBv ZiBKYW4gMjV0aCBhbHNvIGhlbHAgdG8gc2F0aXNmeSB0aGlzIA0KcmVxdWlyZW1lbnQuDQoNCklm IHlvdSBrbm93IGFueSBvdGhlciByZXNvdXJjZSBleGhhdXN0aW9uIGF0dGFja3MgcG9zc2libGUs IHBsZWFzZSANCnN1Ym1pdCB0aGVtIHdpdGggcHJvcG9zYWxzIG9uIGhvdyB0byBzb2x2ZSB0aGVt Lg0KDQpJJ2QgbGlrZSB0byByYWlzZSB0aGlzIGFzIElzc3VlICM0MiwgYW5kIHByb3Bvc2UgdG8g YWRkIHBhcmFncmFwaHMgdG8NClNlY3Rpb24gNyBvZiB0aGUgZHJhZnQgd2l0aCB0aGUgZXhwbGFu YXRpb24gSSBqdXN0IGdhdmUuDQoNCg0KPiAgICAqIFBQU1AuU0VDLlJFUS03OiBQUFNQIFNIT1VM RCBiZSByb2J1c3QsIGkuZS4sIHdoZW4gY2VudHJhbGl6ZWQgdHJhY2tlcg0KPiAgICBmYWlscyB0 aGUgUDJQIHN0cmVhbWluZyBzeXN0ZW0gU0hPVUxEIHN0aWxsIHdvcmsgYnkgc3VwcG9ydGluZw0K PiAgICBkaXN0cmlidXRlZCB0cmFja2Vycy4NCg0KV2UgbmVlZCBQRVggcHJvdGVjdGlvbiBhcyBk aXNjdXNzZWQgaW4gdGhlIG1haWwgIlByb3Bvc2FsIHRvIHJlc29sdmUgDQpJc3N1ZSAxNysyMC4u LiIgb2YgRmViIDE0dGguIEkgcHJvcG9zZSB0byB1cGRhdGUgSXNzdWUgMjAgdG8gaW5kaWNhdGUg DQp0aGF0IHRoaXMgcmVxdWlyZW1lbnQgaXMgcmVsYXRlZC4NCg0KDQo+ICAgICogUFBTUC5TRUMu UkVRLTk6IEludGVncml0eSBvZiB0aGUgc3RyZWFtaW5nIGNvbnRlbnQgaW4gUFBTUCBNVVNUIGJl DQo+ICAgIHN1cHBvcnRlZCB0byBwcm92aWRlIGEgcGVlciB3aXRoIHRoZSBwb3NzaWJpbGl0eSB0 byBpZGVudGlmeQ0KPiAgICBpbmF1dGhlbnRpYyBtZWRpYSBjb250ZW50ICh1bmRlc2lyYWJsZSBt b2RpZmllZCBieSBvdGhlciBlbnRpdGllcw0KPiAgICByYXRoZXIgdGhhbiBpdHMgZ2VudWluZSBz b3VyY2UpLiAgVGhlIGNvcnJlc3BvbmRpbmcgY2hlY2tzdW0NCj4gICAgZGlzdHJpYnV0aW9uIGFu ZCB2ZXJpZmljYXRpb24gc2NoZW1lIFNIT1VMRCBzY2FsZSB3ZWxsIGluIFAyUA0KPiAgICBzdHJl YW1pbmcgc3lzdGVtIGFuZCBiZSByb2J1c3QgYWdhaW5zdCBkaXN0cnVzdGZ1bCB0cmFja2Vycy9w ZWVycy4NCg0KVGhlIE1lcmtsZSBoYXNoIHRyZWVzIG1lY2hhbmlzbSBwcm92aWRlcyBjb250ZW50 IGludGVncml0eSBwcm90ZWN0aW9uDQphbmQgaXMgYWxyZWFkeSBleHBsYWluZWQgaW4gdGhlIGRy YWZ0LiBNZXJrbGUgaGFzaCB0cmVlcyBjYW4gYWxzbyBiZSANCnVzZWQgZm9yIGxpdmUgc3RyZWFt aW5nLiBJbiB0aGF0IGNvbnRleHQgd2Ugc2hvdWxkIHF1b3RlIFtESUdTSUdGTE9XXSwgDQp0aGUg c2lnbmF0dXJlIGFtb3J0aXphdGlvbiBzY2hlbWUgdGhhdCBhbHNvIHVzZXMgTWVya2xlIHRyZWVz Lg0KDQpJJ2QgbGlrZSB0byByYWlzZSBhZGRpbmcgdGhlIHJlZmVyZW5jZSBhcyBJc3N1ZSAjNDMu IFN1cHBvcnQgZm9yIA0KbXVsdGlwbGUgY29udGVudCBpbnRlZ3JpdHkgc2NoZW1lcyB3aWxsIGJl IGFkZGVkIHdoZW4gd2UgcmVhY2ggY29uY2Vuc3VzIA0Kb24gSXNzdWUgIzEwKzEzIChzZWUgbXkg bWFpbCBkZC4gSmFuIDE4dGgpLg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KQ1UsDQogICAgIEFy bm8NCg0KDQoNClJlZmVyZW5jZXMNCi0tLS0tLS0tLS0NCltDTE9TRURdIE4uIEJvcmNoLCBLLiBN aWNoZWxsLCBJLiBBcm50emVuLCBhbmQgRC4gR2FicmlqZWxjaWM6ICJBY2Nlc3MNCmNvbnRyb2wg dG8gQml0VG9ycmVudCBzd2FybXMgdXNpbmcgY2xvc2VkIHN3YXJtcyIuIEluIFByb2NlZWRpbmdz DQpvZiB0aGUgMjAxMCBBQ00gd29ya3Nob3Agb24gQWR2YW5jZWQgdmlkZW8gc3RyZWFtaW5nIHRl Y2huaXF1ZXMNCmZvciBwZWVyLXRvLXBlZXIgbmV0d29ya3MgYW5kIHNvY2lhbCBuZXR3b3JraW5n IChBVlNUUDJQICcxMCkuDQpBQ00sIE5ldyBZb3JrLCBOWSwgVVNBLCAyNS0zMC4NCmh0dHA6Ly9k b2kuYWNtLm9yZy8xMC4xMTQ1LzE4Nzc4OTEuMTg3Nzg5OA0KDQpbRU5IQ0xPU0VEXSBWLiBKb3Zh bm92aWtqLCBELiBHYWJyaWplbMSNacSNIGFuZCBULiBLbG9idcSNYXIuICJBY2Nlc3MgDQpDb250 cm9sIGluIEJpdFRvcnJlbnQgUDJQIE5ldHdvcmtzIFVzaW5nIHRoZSBFbmhhbmNlZCBDbG9zZWQg U3dhcm1zDQpQcm90b2NvbCIuIEluIFByb2NlZWRpbmdzIG9mIHRoZSBGaWZ0aCBJbnRlcm5hdGlv bmFsIENvbmZlcmVuY2Ugb24gDQpFbWVyZ2luZyBTZWN1cml0eSBJbmZvcm1hdGlvbiwgU3lzdGVt cyBhbmQgVGVjaG5vbG9naWVzIChTRUNVUldBUkUNCjIwMTEpLCBwcC4gOTctMTAyLCBOaWNlLCBG cmFuY2UsIEF1Z3VzdCAyMDExLg0KDQpbU0VDU1RSRUFNXSBNYXlhIEhhcmlkYXNhbiBhbmQgUm9i YmVydCB2YW4gUmVuZXNzZS4gIlNlY3VyZVN0cmVhbTogQW4gDQpJbnRydXNpb24tVG9sZXJhbnQg UHJvdG9jb2wgZm9yIExpdmUtU3RyZWFtaW5nIERpc3NlbWluYXRpb24iLiBUaGUgDQpKb3VybmFs IG9mIENvbXB1dGVyIENvbW11bmljYXRpb24ncyBTcGVjaWFsIGlzc3VlIG9uIEZvdW5kYXRpb24g b2YgDQpQZWVyLXRvLVBlZXIgQ29tcHV0aW5nLiBWb2x1bWUgMzEgTnVtYmVyIDIsIEVsc2V2aWVy LCAyMDA4Lg0KDQpbRElHU0lHRkxPV10gQ2h1bmcgS2VpIFdvbmcgYW5kIFNpbW9uIFMuIExhbS4g IkRpZ2l0YWwgU2lnbmF0dXJlcyBmb3IgDQpGbG93cyBhbmQgTXVsdGljYXN0cyIuIElFRUUvQUNN IFRyYW5zYWN0aW9ucyBvbiBOZXR3b3JraW5nLA0KVm9sdW1lIDcsICBJc3N1ZSA0LCBwcC4gNTAy LTUxMywgQXVnIDE5OTkuDQpodHRwOi8vZHguZG9pLm9yZy8xMC4xMTA5LzkwLjc5MzAwNQ0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGlu ZyBsaXN0DQpwcHNwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bwc3A= ------=_001_NextPart820333372318_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF
Hi Arno and all,
   Pls see inline for the comments.  Because I am not = a=20 security expert, more expertise are expected.
 
BR
Yunfei
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-02-14 21:24
To: ppsp
Subject: [ppsp] New issues derived from PPSP=20 requirements...
Hi
 
I've gone over the requirements list in=  draft-ietf-ppsp-reqs-05
and identified some issues (mostly security&= nbsp;related) that need to be 
discussed in the WG:
 
> * "PPSP.REQ-8: The tracker and pee= r protocol together MUST facilitate
>   acceptable QoS (e.g. low st= artup delay, low channel/content switching
>   time and minimal end-to-end = ;delay) for both on-demand and live
>   streaming, even for very po= pular content.  The tracker and peer
>   protocol do not include the=  algorithm required for scalable
>   streaming.  However, the tr= acker and peer protocol SHALL NOT restrict
>   or place limits on any = ;such algorithm.
>
>   There are basic QoS require= ments for streaming system.  Setup time = ;to
>   receive a new streaming cha= nnel or to switch between channels should
>   be reasonable small.  End&n= bsp;to end delay (time between content
>   generation, e.g. camera and = ;content consumption, e.g. user side
>   monitor) will become critical&nb= sp;in case of live streaming.  Especially
>   in provisioning of sports e= vents, end to end delay of 1 minute&nbs= p;and
>   more are not acceptable.
>
>   For instance, the tracker a= nd peer protocols can support carrying QoS
>   related parameters (e.g. video&n= bsp;quality, delay requirements) together
>   with the priorities of thes= e parameters, and QoS situation (e.g.
>   performance, available uplink ba= ndwidth) of content providing peers.
>
>   There are also some other&n= bsp;possible mechanisms, e.g. addition of super
>   peers, in-network storage, reque= st of alternative peer addresses, and
>   the usage of QoS informatio= n for an advanced peer selection."
 
The current protocol has been designed = for short-time-till-playback,
unless limited by security considerations (c= f. Issue #26 security of
handshakes). Otherwise it operates in a = ;best effort mode.
 
But perhaps more is needed, as indicate= d in the description. Also
relevant is issue 12 (=3DSupport for UN= HINT), as that helps in making
requesting chunks from multiple peers at&nbs= p;the same time efficient,
as you can cancel the duplicates when&n= bsp;you receive an answer.
You may need double requests when some&= nbsp;peers are slow and strong QoS
is needed.
 
I'd like to raise this as Issue #3= 5.
 
[Yunfei] I think this is a feasible mechanis= m in the=20 protocol.
 
>   * PPSP.PP.REQ-3: The streaming&n= bsp;content availability request message
>    SHOULD allow the peer = ;to solicit an additional list of peers = ;to that
>    received from the tracker&= nbsp;- with the same swarm ID.  The&nbs= p;reply
>    message MUST contain swarm= -membership information of the peers that
>    have explicitly indicated = they are part of the swarm, verifiable = by
>    the receiver.  This a= dditional list of peers MUST only contain&nb= sp;peers
>    which have been checked&nb= sp;to be valid and online recently (e.g.&nbs= p;prevent
>    hearsay and DoS).
>
>    It is possible that a=  peer may need additional peers for cer= tain
>    streaming content.  Theref= ore, it is allowed that the peer
>    communicates with the peer= s in the current peer list to obtain&nb= sp;an
>    additional list of peers&n= bsp;in the same swarm.
 
The draft uses PEX_* messages for this,=  hence I propose to rephrase this 
requirement, or declare PEX as sufficient&nb= sp;to satisfy this requirement.
 
[Yunfei] Do you mean to rephrase this requir= ement in=20 which document? Peer protocol or merged requirements draft?
I am okay to see the declaration in the peer= =20 protocol.
 
 
>    * PPSP.PP.REQ-6: The peer&= nbsp;status report/update SHOULD be advertised
>    among the peers to re= flect the status of the peer.
>
>    Peer status information sh= ould be advertised among the peers via = the
>    peer status report/update = message.  For example, peer status can = be
>    online time, physical link=  status including DSL/WIFI/etc, battery
>    status, processing capability,&= nbsp;and other capabilities of the peer.
>    With this information, a&n= bsp;peer can select more appropriate peers f= or
>    streaming.
 
I'd like to raise this as Issue #3= 6.
 
 
>    * PPSP.SEC.REQ-1: PPSP MUS= T support closed swarms, where the peers&nbs= p;are
>    authenticated.
>
>    This ensures that only&nbs= p;the authenticated users can access the
>    original media in the = ;P2P streaming system.  This can be ach= ieved by
>    security mechanisms such a= s user authentication and/or key management
>    scheme.
 
I'd like to raise this as Issue #3= 7.
 
In addition, I propose the following so= lution: The Closed Swarms 
[CLOSED] and Enchanced Closed Swarms [ENHCLO= SED] mechanisms developed in 
the P2P-Next project provide swarm-level acc= ess control.
The basic idea is that a peer cann= ot download from another peer unless 
it shows a Proof-of-Access. Enhanced Closed&= nbsp;Swarms improve on the 
original Closed Swarms by adding on-the-wire=  encryption against 
man-in-the-middle attacks and more flexible = access control rules.
 
I propose to describe Enhanced Closed S= warms as one of the mechanisms 
(please put forward others if you know&= nbsp;about them) to satisfy the 
requirement and include it as a Section=  in the WG draft.
[Yunfei] Same question as above. In the peer= =20 protocol draft? If so, I think it's okay.
 
 
>   * PPSP.SEC.REQ-2: Confidentiality&nbs= p;of the streaming content in PPSP
>    SHOULD be supported and&nb= sp;the corresponding key management scheme
>    SHOULD scale well in = P2P streaming system.
>
 
No extra mechanism is needed in to = ;support confidentiality in PPSPP. A
content publisher wishing confidentiality should&= nbsp;just distribute content 
in cyphertext / DRM-ed format. I assume=  a higher layer handles key 
management out-of-band. Alternatively, the swarm&= nbsp;access control will 
point-to-point encrypt content.
 
I'd like to raise this as Issue #3= 8, and propose to add a paragraph to
Section 7 of the draft with the ex= planation I just gave.
[Yunfei] I am fine with this.
 
 
>   * PPSP.SEC.REQ-3: PPSP MUST = ;provide an option to encrypt the data
>    exchange among the PPSP&nb= sp;entities.
>
 
If this requirement means that all PPSP= P messages should be encrypted 
(as opposed to just content in SEC.REQ-= 2), IPsec or DTLS is the obvious 
solution.
 
I'd like to raise this as Issue #3= 9, and propose to add a paragraph to
Section 7 of the draft with the ex= planation I just gave. Furthermore,
a key distribution scheme would have to=  be added.
 
 
>    * PPSP.SEC.REQ-4: PPSP MUS= T have mechanisms to limit potential damage<= /DIV>
>    caused by malfunctioning a= nd badly behaving peers in the P2P
>    streaming system.
>
>    Such an attack will d= egrade the quality of the rendered media&nbs= p;at the
>    receiver.  For example,&nb= sp;in a P2P live video streaming system = ;a
>    polluter can introduce cor= rupted chunks.  Each receiver integrates
>    into its playback stream&n= bsp;the polluted chunks it receives from its=
>    other neighbors.  Since&nb= sp;the peers forwards chunks to other peers,=  the
>    polluted content can poten= tially spread through much of the P2P
>    streaming network.
 
Content integrity protection helps here. I'd=  like to raise this as Issue 
#40 and will provide a per-message anal= ysis of issues later.
[Yunfei] Sounds good.
 
 
>    * PPSP.SEC.REQ-5: PPSP SHO= ULD support identifying badly behaving peers,
>    and exclude or reject = ;them from the P2P streaming system.
 
Quoting WG draft 6.3.2.3: "The Merkle t= ree hashing scheme allows a 
receiving peer to detect a malicious or=  faulty sender, which it can 
subsequently ignore. Spreading this knowledge&nbs= p;to other peers such that 
they know about this bad behavior is&nb= sp;hearsay."
 
So we can provide protection, but to&nb= sp;actually oust bad peers permanently 
from the system, access control and a&n= bsp;reliable accusation system is 
needed that is itself protected against = ;malicious peers reporting about 
good peers. Such a system is complex.
I'd like to raise this as Issue #4= 1, and propose to add a paragraph to
Section 7 of the draft with the ex= planation I just gave.
[Yunfei] I agree with the requirement clause= . Just=20 as discussed in last IETF,
I believe such functionality is essential. I= f we=20 consider a system with some degree of malicous
peers, the mechanism to identify the badly p= eers and=20 execute access control.
Reference[detecting malicous peers] can be a= good=20 starting point.
 
[detecting malicous peers]=20 Detecting Malicious Peers in Overlay Multicast&nb= sp;Streaming=20 ,
Samarth Shetty, Patricio Galdames,=  Wallapak Tavanapong, Ying Cai,
www.cs.iastate.edu/~yingcai/public_html/pub/lcn.pdf=  
 
 
 
>   * PPSP.SEC.REQ-6: PPSP MUST = ;prevent peers from DoS attacks which will
>    exhaust the P2P streaming&= nbsp;system's available resource.
>
>    Given the prevalence of&nb= sp;DoS attacks in the Internet, it is i= mportant
>    to realize that a sim= ilar threat could exist in a large-scale
>    streaming system where att= ackers are capable of consuming a lot o= f
>    resources with just a = ;small amount of effort.
 
Quoting WG draft 6.3.2.3: "A risk in&nb= sp;peer-to-peer streaming systems is 
that malicious peers launch an Eclipse = [ECLIPSE] attack on the initial
injectors of the content (in particular = ;in live streaming). The attack
tries to let the injector upload to&nbs= p;just malicious peers which then do
not forward the content to others, thus=  stopping the distribution. An
Eclipse attack could also be launched o= n an individual peer. Letting
these injectors only use trusted trackers&nb= sp;that provide true random
samples of the population or using a&nb= sp;secure peer sampling service
[PUPPETCAST] can help negate such an at= tack."
 
So we need PEX protection as discussed&= nbsp;in the mail "Proposal to resolve 
Issue 17+20..." of Feb 14th. In additio= n, a peer A must not
let other peers T1..TN fill all its&nbs= p;available connection slots, i.e.,
A must initiate connections itself too, = ;to prevent isolation.
 
Furthermore, to prevent malicious peers cons= uming all upload bandwidth 
of a peer, there should be a limit=  on the upload capacity a single peer
can consume, e.g. via a limit on t= he number of requests as in 
SecureStream [SECSTREAM]. A natural upper li= mit of this upload quotum is 
the bitrate of the content.
 
Protection against amplifcation attacks such = ;as mentioned in the mail 
"Proposal to solve Issue #26" of Jan&nb= sp;25th also help to satisfy this 
requirement.
 
If you know any other resource exhausti= on attacks possible, please 
submit them with proposals on how to&nb= sp;solve them.
 
I'd like to raise this as Issue #4= 2, and propose to add paragraphs to
Section 7 of the draft with the ex= planation I just gave.
 
 
>    * PPSP.SEC.REQ-7: PPSP SHO= ULD be robust, i.e., when centralized tracke= r
>    fails the P2P streaming&nb= sp;system SHOULD still work by supporting
>    distributed trackers.
 
We need PEX protection as discussed in&= nbsp;the mail "Proposal to resolve 
Issue 17+20..." of Feb 14th. I propose&= nbsp;to update Issue 20 to indicate 
that this requirement is related.
 
 
>    * PPSP.SEC.REQ-9: Integrity&nbs= p;of the streaming content in PPSP MUST = ;be
>    supported to provide a&nbs= p;peer with the possibility to identify
>    inauthentic media content = (undesirable modified by other entities
>    rather than its genuine&nb= sp;source).  The corresponding checksum
>    distribution and verification&n= bsp;scheme SHOULD scale well in P2P
>    streaming system and be&nb= sp;robust against distrustful trackers/peers.
 
The Merkle hash trees mechanism provides&nbs= p;content integrity protection
and is already explained in the draft.&= nbsp;Merkle hash trees can also be 
used for live streaming. In that contex= t we should quote [DIGSIGFLOW], 
the signature amortization scheme that also&= nbsp;uses Merkle trees.
 
I'd like to raise adding the reference&= nbsp;as Issue #43. Support for 
multiple content integrity schemes will be&n= bsp;added when we reach concensus 
on Issue #10+13 (see my mail dd. J= an 18th).
 
What do you think?
 
CU,
     Arno
 
 
 
References
----------
[CLOSED] N. Borch, K. Michell, I. Arntz= en, and D. Gabrijelcic: "Access
control to BitTorrent swarms using closed&nb= sp;swarms". In Proceedings
of the 2010 ACM workshop on Advanced&nb= sp;video streaming techniques
for peer-to-peer networks and social network= ing (AVSTP2P '10).
ACM, New York, NY, USA, 25-30.
http://doi.acm.org/10.1145/1877891.1877898
 
[ENHCLOSED] V. Jovanovikj, D. Gabrijel=C4=8Di=C4= =8D and T. Klobu=C4=8Dar. "Access 
Control in BitTorrent P2P Networks Using&nbs= p;the Enhanced Closed Swarms
Protocol". In Proceedings of the Fifth = International Conference on 
Emerging Security Information, Systems and T= echnologies (SECURWARE
2011), pp. 97-102, Nice, France, August = ;2011.
 
[SECSTREAM] Maya Haridasan and Robbert van&n= bsp;Renesse. "SecureStream: An 
Intrusion-Tolerant Protocol for Live-Streaming Di= ssemination". The 
Journal of Computer Communication's Special = issue on Foundation of 
Peer-to-Peer Computing. Volume 31 Number 2,&= nbsp;Elsevier, 2008.
 
[DIGSIGFLOW] Chung Kei Wong and Simon S= . Lam. "Digital Signatures for 
Flows and Multicasts". IEEE/ACM Transactions = ;on Networking,
Volume 7,  Issue 4, pp. 502-513, A= ug 1999.
http://dx.doi.org/10.1109/90.793005
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart820333372318_=------ From a.bakker@vu.nl Tue May 8 23:18:48 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 43AAE21F85D4 for ; Tue, 8 May 2012 23:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.581 X-Spam-Level: **** X-Spam-Status: No, score=4.581 tagged_above=-999 required=5 tests=[AWL=-3.810, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-BpVQB2Yopo for ; Tue, 8 May 2012 23:18:47 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1B121F85B5 for ; Tue, 8 May 2012 23:18:43 -0700 (PDT) Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 9 May 2012 08:18:41 +0200 Received: from [109.36.82.228] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 9 May 2012 08:18:41 +0200 Message-ID: <4FAA0C76.9010306@cs.vu.nl> Date: Wed, 9 May 2012 08:19:34 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: zhangyunfei References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> In-Reply-To: <20120418183444961415101@chinamobile.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] =?gb2312?b?W1NwYW1dILvYuLQ6IFJlOrvYuLQ6IFJlOiAgUHJvcG9z?= =?gb2312?b?YWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEz?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 06:18:48 -0000 On 18/04/2012 12:34, zhangyunfei wrote: > Hi Arno£¬ > Pls see inline.Thanks. Hi all this landed in my spam box, so sorry for the late reply. See inline. > [Yunfei] This is what I worry about. We cannot assure that each time we > can request > chunks in groups of powers of 2, as it's dependent on what the serving > peers have, which > is hard to ensure that the number of available chunks being powers of 2. IMHO, chunks will be requested in powers of 2. First, one will likely request more than 1 chunk at a time to be able to fill the pipeline from sender to receiver (cf. delay-bandwidth product). Requesting 1K and then waiting for it will not be efficient. Second, as we're computer scientists we'll use base 2 (32K, 64K, etc) when using multiples ;o) > In such cases, requsting > a range of chunks needs no more bits than bin number. What's worse, if > the chunks peer A has is > sparsely distributed, i.e., the chunkmap is likely to be 10001011110, > bin numbering needs more bits. Bins are actually more efficient than (start,end) in this example. With bin numbers, you'll in the worst case need an integer for every 1 in the bitmap, so 6 in this case. In a better case we might be able to address the 4 ones at the end as a single bin. However, if you use (start,end) addressing, you'll actually need 2 integers per 1 bit, or 12 integers. CU, Arno From a.bakker@vu.nl Wed May 9 00:01:30 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 0094321F85EF for ; Wed, 9 May 2012 00:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.134 X-Spam-Level: *** X-Spam-Status: No, score=3.134 tagged_above=-999 required=5 tests=[AWL=-1.516, BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGUnHcoV88bA for ; Wed, 9 May 2012 00:01:29 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2793C21F8559 for ; Wed, 9 May 2012 00:01:28 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 9 May 2012 09:01:29 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 9 May 2012 09:01:27 +0200 Message-ID: <4FAA1680.9080000@cs.vu.nl> Date: Wed, 9 May 2012 09:02:24 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <4FAA0C76.9010306@cs.vu.nl> In-Reply-To: <4FAA0C76.9010306@cs.vu.nl> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] =?gb2312?b?W1NwYW1dILvYuLQ6IFJlOrvYuLQ6IFJlOiAgUHJvcG9z?= =?gb2312?b?YWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEz?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 07:01:30 -0000 On 09/05/2012 08:19, Arno Bakker wrote: > >> In such cases, requsting >> a range of chunks needs no more bits than bin number. What's worse, if >> the chunks peer A has is >> sparsely distributed, i.e., the chunkmap is likely to be 10001011110, >> bin numbering needs more bits. > > Bins are actually more efficient than (start,end) in this example. With > bin numbers, you'll in the worst case need an integer for every 1 in the > bitmap, so 6 in this case. In a better case we might be able to address > the 4 ones at the end as a single bin. However, if you use (start,end) > addressing, you'll actually need 2 integers per 1 bit, or 12 integers. > Correction: bins are equally or more efficient. It will take 3 (start,end) byte range pairs to represent 10001011110, so 6 ints. It will take 3 to 6 bins to represent that, so 3-6 ints. CU, Arno From zhangyunfei@chinamobile.com Wed May 9 19:18:35 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 BF3B211E80AA for ; Wed, 9 May 2012 19:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.292 X-Spam-Level: X-Spam-Status: No, score=-91.292 tagged_above=-999 required=5 tests=[AWL=-2.564, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJZqgM6QWZdO for ; Wed, 9 May 2012 19:18:35 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6111E80AF for ; Wed, 9 May 2012 19:18:34 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 4D239E5D2; Thu, 10 May 2012 10:18:33 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 41CF6E5D0; Thu, 10 May 2012 10:18:33 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051010183147-6045 ; Thu, 10 May 2012 10:18:31 +0800 Date: Thu, 10 May 2012 10:18:26 +0800 From: zhangyunfei To: "arno@cs.vu.nl" References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com>, <4FAA0C76.9010306@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051010182675958722@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-10 10:18:31, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-10 10:18:32, Serialize complete at 2012-05-10 10:18:32 Content-Type: multipart/alternative; boundary="----=_001_NextPart320220147167_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18896.003 X-TM-AS-Result: No--41.609-7.0-31-10 X-imss-scan-details: No--41.609-7.0-31-10;No--41.609-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?u9i4tDogUmU6IFtTcGFtXbvYuLQ6IFJlOrvYuLQ6IFJl?= =?gb2312?b?OiAgUHJvcG9zYWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEz?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 02:18:35 -0000 This is a multi-part message in MIME format. ------=_001_NextPart320220147167_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQXJubywNCiAgICBJIGhhZCBhbiBlbWFpbCBvbiBkaXNjdXNzaW5nIHRoZSBuZXcgaXNzdWVz IGRlcml2ZWQgZnJvbSBQUFNQIHJlcXVpcmVtZW50cyB5b3UgcHJvcG9zZWQgaW4gdGhlIG1haWxp bmcgbGlzdCBzZXZlcmFsIGRheXMgYWdvLiBJIGFtIG5vdCBzdXJlIGlmIHlvdSByZWNlaXZlZCBp dCBjb3JyZWN0bHkuIElmIG5vdCwgcGxlYXNlIGNoZWNrIHRoZSBzcGFtIGJveCBhZ2Fpbi4NCg0K QlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQq3orz+yMujuiBBcm5vIEJha2tlcg0K t6LLzcqxvOSjuiAyMDEyLTA1LTA5IDE0OjE5DQrK1bz+yMujuiB6aGFuZ3l1bmZlaQ0Ks63LzaO6 IHBwc3ANCtb3zOKjuiBSZTogW1NwYW1du9i4tDogUmU6W3Bwc3Bdu9i4tDogUmU6IFByb3Bvc2Fs IHRvIHJlc29sdmUgSXNzdWUgMTAgKyAxMw0KT24gMTgvMDQvMjAxMiAxMjozNCwgemhhbmd5dW5m ZWkgd3JvdGU6DQo+IEhpIEFybm+jrA0KPiBQbHMgc2VlIGlubGluZS5UaGFua3MuDQoNCkhpIGFs bA0KDQp0aGlzIGxhbmRlZCBpbiBteSBzcGFtIGJveCwgc28gc29ycnkgZm9yIHRoZSBsYXRlIHJl cGx5LiBTZWUgaW5saW5lLg0KDQo+IFtZdW5mZWldIFRoaXMgaXMgd2hhdCBJIHdvcnJ5IGFib3V0 LiBXZSBjYW5ub3QgYXNzdXJlIHRoYXQgZWFjaCB0aW1lIHdlIA0KPiBjYW4gcmVxdWVzdA0KPiBj aHVua3MgaW4gZ3JvdXBzIG9mIHBvd2VycyBvZiAyLCBhcyBpdCdzIGRlcGVuZGVudCBvbiB3aGF0 IHRoZSBzZXJ2aW5nIA0KPiBwZWVycyBoYXZlLCB3aGljaA0KPiBpcyBoYXJkIHRvIGVuc3VyZSB0 aGF0IHRoZSBudW1iZXIgb2YgYXZhaWxhYmxlIGNodW5rcyBiZWluZyBwb3dlcnMgb2YgMi4gDQoN CklNSE8sIGNodW5rcyB3aWxsIGJlIHJlcXVlc3RlZCBpbiBwb3dlcnMgb2YgMi4gRmlyc3QsIG9u ZSB3aWxsIGxpa2VseQ0KcmVxdWVzdCBtb3JlIHRoYW4gMSBjaHVuayBhdCBhIHRpbWUgdG8gYmUg YWJsZSB0byBmaWxsIHRoZSBwaXBlbGluZSBmcm9tDQpzZW5kZXIgdG8gcmVjZWl2ZXIgKGNmLiBk ZWxheS1iYW5kd2lkdGggcHJvZHVjdCkuIFJlcXVlc3RpbmcgMUsgYW5kIHRoZW4NCndhaXRpbmcg Zm9yIGl0IHdpbGwgbm90IGJlIGVmZmljaWVudC4gU2Vjb25kLCBhcyB3ZSdyZSBjb21wdXRlcg0K c2NpZW50aXN0cyB3ZSdsbCB1c2UgYmFzZSAyICgzMkssIDY0SywgZXRjKSB3aGVuIHVzaW5nIG11 bHRpcGxlcyA7bykNCg0KDQo+IEluIHN1Y2ggY2FzZXMsIHJlcXVzdGluZw0KPiBhIHJhbmdlIG9m IGNodW5rcyBuZWVkcyBubyBtb3JlIGJpdHMgdGhhbiBiaW4gbnVtYmVyLiBXaGF0J3Mgd29yc2Us IGlmIA0KPiB0aGUgY2h1bmtzIHBlZXIgQSBoYXMgaXMNCj4gc3BhcnNlbHkgZGlzdHJpYnV0ZWQs IGkuZS4sIHRoZSBjaHVua21hcCBpcyBsaWtlbHkgdG8gYmUgMTAwMDEwMTExMTAsIA0KPiBiaW4g bnVtYmVyaW5nIG5lZWRzIG1vcmUgYml0cy4NCg0KQmlucyBhcmUgYWN0dWFsbHkgbW9yZSBlZmZp Y2llbnQgdGhhbiAoc3RhcnQsZW5kKSBpbiB0aGlzIGV4YW1wbGUuIFdpdGgNCmJpbiBudW1iZXJz LCB5b3UnbGwgaW4gdGhlIHdvcnN0IGNhc2UgbmVlZCBhbiBpbnRlZ2VyIGZvciBldmVyeSAxIGlu IHRoZQ0KYml0bWFwLCBzbyA2IGluIHRoaXMgY2FzZS4gSW4gYSBiZXR0ZXIgY2FzZSB3ZSBtaWdo dCBiZSBhYmxlIHRvIGFkZHJlc3MNCnRoZSA0IG9uZXMgYXQgdGhlIGVuZCBhcyBhIHNpbmdsZSBi aW4uIEhvd2V2ZXIsIGlmIHlvdSB1c2UgKHN0YXJ0LGVuZCkNCmFkZHJlc3NpbmcsIHlvdSdsbCBh Y3R1YWxseSBuZWVkIDIgaW50ZWdlcnMgcGVyIDEgYml0LCBvciAxMiBpbnRlZ2Vycy4NCg0KQ1Us DQogICAgQXJubw== ------=_001_NextPart320220147167_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Arno,
    I had an email on discussing=20 the new issues derived from PPSP requirement= s you=20 proposed in the mailing list several days ago. I am not sure if you receiv= ed it=20 correctly. If not, please check the spam box again.
 
BR
Yunfei
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Arno Bakker
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-05-09 14:19
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei
=B3=AD=CB=CD=A3=BA ppsp<= /A>
=D6=F7=CC=E2=A3=BA Re: [Spam]=BB=D8=B8=B4: Re:[ppsp]=BB= =D8=B8=B4: Re: Proposal to resolve Issue 10=20 + 13
On 18/04/2012 12:34, zhangyunfei wrote:
> Hi Arno=A3=AC
> Pls see inline.Thanks.
 
Hi all
 
this landed in my spam box, so sor= ry for the late reply. See inline.
 
> [Yunfei] This is what I worry = ;about. We cannot assure that each time = ;we 
> can request
> chunks in groups of powers of = ;2, as it's dependent on what the servi= ng 
> peers have, which
> is hard to ensure that the nu= mber of available chunks being powers of&nbs= p;2. 
 
IMHO, chunks will be requested in power= s of 2. First, one will likely
request more than 1 chunk at a tim= e to be able to fill the pipeline = from
sender to receiver (cf. delay-bandwidth prod= uct). Requesting 1K and then
waiting for it will not be efficient.&n= bsp;Second, as we're computer
scientists we'll use base 2 (32K, 64K,&= nbsp;etc) when using multiples ;o)
 
 
> In such cases, requsting
> a range of chunks needs no mo= re bits than bin number. What's worse, = if 
> the chunks peer A has is
> sparsely distributed, i.e., the chunkma= p is likely to be 10001011110, 
> bin numbering needs more bits.
 
Bins are actually more efficient than (= start,end) in this example. With
bin numbers, you'll in the worst case&n= bsp;need an integer for every 1 in the<= /DIV>
bitmap, so 6 in this case. In a&nb= sp;better case we might be able to addr= ess
the 4 ones at the end as a si= ngle bin. However, if you use (start,end)
addressing, you'll actually need 2 integers&= nbsp;per 1 bit, or 12 integers.
 
CU,
    Arno
------=_001_NextPart320220147167_=------ From Fabio.Picconi@technicolor.com Mon May 14 05:08:48 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 7735121F8551 for ; Mon, 14 May 2012 05:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.433 X-Spam-Level: X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[AWL=4.617, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+CxD8G+PvRD for ; Mon, 14 May 2012 05:08:47 -0700 (PDT) Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) by ietfa.amsl.com (Postfix) with ESMTP id 62BA521F8565 for ; Mon, 14 May 2012 05:08:42 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKT7D1ydsc4DxoO3H7Mh0JEeeB7Jo3z6xH@postini.com; Mon, 14 May 2012 05:08:45 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 14 May 2012 14:04:38 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 14 May 2012 14:04:39 +0200 From: Picconi Fabio To: zhangyunfei , ppsp Date: Mon, 14 May 2012 14:04:38 +0200 Thread-Topic: [ppsp] tickets for IETF 83 Thread-Index: Ac0pCk8oIQZxhAokQ0OzXYdJcItKZQIvJK8A Message-ID: <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> References: <2012050316123830359558@chinamobile.com> In-Reply-To: <2012050316123830359558@chinamobile.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_320C4182454E96478DC039F2C481987204EB1CD469MOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [ppsp] tickets for IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 12:08:48 -0000 --_000_320C4182454E96478DC039F2C481987204EB1CD469MOPESMBX01eut_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi, Somme comments: Ticket #1 (chunk addressing mechanism). See my email send today. Ticket #2. I can=1B$B!G=1B(Bt remember what this was about. :-) Ticket #3 (secure PEX): I think that we can stick to a simple PEX mechanism= that can be augmented by an optional secure algorithm. In addition to the = solution proposed by Arno, there is a simple mechanism described by Jesi et= al. [1]. Ticket #4 (FIND use case). I don=1B$B!G=1B(Bt recall exactly the details of= this issue. If it=1B$B!G=1B(Bs only motivating a request to the tracker to= find peers subject to attribute constraints, then finding peers with a sim= ilar upload capacity (to speed up the discovery phase) is already a good mo= tivation. Ticket #5 (additional messages). I think the proponents of these messages s= hould describe the use cases where these messages can be useful. Cheers, Fabio [1] G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. In Com= puter Networks, 2010. From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of zha= ngyunfei Sent: jeudi 3 mai 2012 10:13 To: ppsp Subject: [ppsp] tickets for IETF 83 Hi all, I have summarized an initial tickets list for IETF 83 meeting. Please r= eview it and actions on these tickets are expected. Thanks. BR Yunfei &Stefano ---------------------------------------------------------------------------= -------------------------------- Peer protocol: Ticket #1=1B$B!'=1B(BPost and discuss the alternative proposal besides MHT = in peer protocol (Proposal 10+13), list intervals (Tradeoff among complexit= y / overhead / efficiency / implementation) and check gaps. [Martin=1B$B!$= =1B(B Yunfei, Fabio, Lichun] This ticket is partly solved. Simple nature number addressing and ranged ex= pression on chunk availability. The analysis and comparison is ongoing. I'd= suggest to have a deadline for the resolution time after discussing with S= tefano, i.e., May 26th from now on to make the decision in the WG level. Ticket #2=1B$B!'=1B(BDiscuss the possible =1B$B!H=1B(B"state-building attac= ks" attack on peers.[Martin](related Proposal 26) Martin, Do you still have concerns on this? If nobody shows up, we propose = to close this ticket. Ticket #3: Discuss the Membership certificates impact on the tracker=1B$B!G= =1B(Bs workload.[Fabio](related to Proposal 17+20) Tracker protocol: Ticket#4: Specify the FIND use case and reduce the overhead to the tracker.= [Martin,Yunfei=1B$B!$=1B(BFabio=1B$B!$=1B(BRichardo] Ticket#5: Discuss concrete use cases of additional messages if there are(e.= g.,reconnect and rejoin) , and conclude the basic messages and optional one= s in tracker protocol. [Mark, Fabio] We propose to the tracker protocol authors to address their tickets with a= splitting of their proposal: . base spec . additional options. Survey Ticket#6: Call for reviewers for survey draft, and maybe P2P streaming prov= iders=1B$B!G=1B(B contribution on updating the draft. ________________________________ zhangyunfei --_000_320C4182454E96478DC039F2C481987204EB1CD469MOPESMBX01eut_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

= Hi,

Somme comments:

Ticket #1 (chunk addressing mech= anism). See my email send today.

= Ticket #2. I can=1B$B!G=1B(Bt remember what this was about. :-)=

Ticket #3 (secure PEX): I thin= k that we can stick to a simple PEX mechanism that can be augmented by an o= ptional secure algorithm. In addition to the solution proposed by Arno, the= re is a simple mechanism described by Jesi et al. [1].

Ticket #4 (FIND use case). I don=1B$B!G=1B(Bt = recall exactly the details of this issue. If it=1B$B!G=1B(Bs only motivatin= g a request to the tracker to find peers subject to attribute constraints, = then finding peers with a similar upload capacity (to speed up the discover= y phase) is already a good motivation.

Ticket #5 (additional messages). I think the proponents of the= se messages should describe the use cases where these messages can be usefu= l.

Cheers,

Fabio

[1] G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sa= mpling. In Computer Networks, 2010.

 

From: ppsp-bounces@ietf.org [= mailto:ppsp-bounces@ietf.org] On Behalf Of zhangyunfei
Sent: jeudi 3 mai 2012 10:13
To: ppsp
Subject: [ppsp] tick= ets for IETF 83

=  

Hi all,

    I have&= nbsp;summarized an initial tickets list for I= ETF 83 meeting. Please review it and actions on these tickets are= expected. Thanks.

=

 

BR=

Yunfei &Stefano=

-----------------------------------------= ------------------------------------------------------------------

Peer protocol:=

Tic= ket #1=1B$B!'=1B(BPost and discuss the alternative proposal besides MHT in peer pro= tocol (Proposal 10+13), list intervals (Tradeoff among complexity / overhea= d / efficiency / implementation) and check gaps. [Martin=1B$B!$=1B(B<= span style=3D'font-family:"Calibri","sans-serif";color:black'> Yunfei, Fabi= o, Lichun]

This ticket is partly solved. S= imple nature number addressing and ranged expression on chunk availability.= The analysis and comparison is ongoing. I'd suggest to have a deadlin= e for the resolution time after discussing with Stefano, i.e.,  <= /span>May 26th= from= now on to make the decision in the WG level.

 

Ticket #2=1B$B!'=1B(BDiscuss the possible =1B$B!H=1B(B"state-building attacks&q= uot; = attack on peers.[Martin](related Proposal 26)

Martin, Do you still have concerns on this? If nobody shows up, we prop= ose to = close this ticket.

=

 

Ticket #3: Discuss the Membership certificates impact on the t= racker=1B$B!G=1B(Bs workload.[Fa= bio](related to Proposal 17+20)

 <= /span>

Tracker protocol:

Ticket#4: Specify the FIND use case and reduce the overhead to the tracke= r.[Martin,Yunfei=1B$B!$=1B(BFabio=1B$B!$=1B(BRichardo]

Ticke= t#5: = Discuss concrete use cases of additional messages if there are(e.g.,reconne= ct and rejoin) , and conclude the basic messages and optional ones in track= er protocol. [Mark, Fabio]

 We propose to the tracker protocol authors=  to address their tickets with a splitti= ng of their proposal:

. base s= pec

. additional options.

 =

Survey=

Ticket#6: Call for reviewers for survey draft, an= d maybe P2P streaming providers=1B$B!G=1B(B contribution on updating the dr= aft.   

 

zhangyunfei

<= /div>
= --_000_320C4182454E96478DC039F2C481987204EB1CD469MOPESMBX01eut_-- From a.bakker@vu.nl Mon May 14 05:36:48 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 B75E921F8664 for ; Mon, 14 May 2012 05:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.53 X-Spam-Level: X-Spam-Status: No, score=0.53 tagged_above=-999 required=5 tests=[AWL=2.034, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjGg9jntnICU for ; Mon, 14 May 2012 05:36:48 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id D4EC621F865C for ; Mon, 14 May 2012 05:36:47 -0700 (PDT) Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 14 May 2012 14:36:42 +0200 Received: from [192.168.0.102] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 14 May 2012 14:36:41 +0200 Message-ID: <4FB0FC97.7020601@cs.vu.nl> Date: Mon, 14 May 2012 14:37:43 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: References: <2012050316123830359558@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> In-Reply-To: <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] tickets for IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 12:36:48 -0000 Hi Fabio and all On 14/05/2012 14:04, Picconi Fabio wrote: > > Ticket #3 (secure PEX): I think that we can stick to a simple PEX > mechanism that can be augmented by an optional secure algorithm. In > addition to the solution proposed by Arno, there is a simple mechanism > described by Jesi et al. [1]. > IMHO, leaving PEX unsecured will get us comments from the IESG. My proposal is actually compatible with Jesi, Montresor, van Steen (Maarten van Steen is my boss). My membership certificates correspond to their signed node descriptors. This mechanism alone will prevent the addresses of innocent hosts being spread. I add some extra security by exploiting the central tracker. They go fully decentralized by probing the graph for malicious structures. CU, Arno From Fabio.Picconi@technicolor.com Mon May 14 08:55:41 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 AF69C21F8805 for ; Mon, 14 May 2012 08:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.741 X-Spam-Level: * X-Spam-Status: No, score=1.741 tagged_above=-999 required=5 tests=[AWL=-1.308, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_53=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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrKJ5ca1r5cS for ; Mon, 14 May 2012 08:55:41 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id D335B21F87F8 for ; Mon, 14 May 2012 08:55:31 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT7Eq8xk5GlkMM1eusoaMHmQdWMkKmz/k@postini.com; Mon, 14 May 2012 08:55:40 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 14 May 2012 17:52:22 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 14 May 2012 17:52:28 +0200 From: Picconi Fabio To: "arno@cs.vu.nl" Date: Mon, 14 May 2012 17:52:27 +0200 Thread-Topic: =?gb2312?B?W3Bwc3BdILvYuLQ6IFJlOrvYuLQ6IFJlOiAgUHJvcG9zYWwgdG8gcmVzb2x2?= =?gb2312?B?ZSBJc3N1ZSAxMCArIDEz?= Thread-Index: Ac0xzTrPI9O802dFRs+P8R1FUTHbygABm3Uw Message-ID: <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl> In-Reply-To: <4FB0FAEA.8010504@cs.vu.nl> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: ppsp Subject: Re: [ppsp] =?gb2312?b?u9i4tDogUmU6u9i4tDogUmU6ICBQcm9wb3NhbCB0byBy?= =?gb2312?b?ZXNvbHZlIElzc3VlIDEwICsgMTM=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:55:41 -0000 SGVyZSdzIGEgYnJpZWYgY29tcGFyaXNvbjoNCg0KWzAtUF0NCkJpbnM6IDEgaW50ZWdlciBpZiBw b3dlciBvZiAyLCBtdWx0aXBsZSBpbnRlZ2VycyBvdGhlcndpc2UNClJhbmdlIGxpc3Q6IGFsd2F5 cyAyIGludGVnZXJzDQoNCltQKzEsUCtXXSB3b3JzdCBjYXNlDQpCaW5zOiBXLzIgaW50ZWdlcnMN ClJhbmdlIGxpc3Q6IFcvMiByYW5nZXMsIGkuZS4sIFcgaW50ZWdlcnMNCg0KW1ArMSxQK1ddIGF2 ZXJhZ2UgY2FzZQ0KQmluczogPw0KUmFuZ2UgbGlzdDogPw0KDQpbUCtXKzEsTl0gZW1wdHkgcmFu Z2UNCkJpbnM6IG5vIGludGVnZXJzDQpSYW5nZSBsaXN0OiBubyBpbnRlZ2Vycw0KDQpUYWtpbmcg Vz0zMCBzZWNvbmRzIGFuZCAzIGNodW5rcyBwZXIgc2Vjb25kLCA0IGJ5dGVzIHBlciBpbnRlZ2Vy LCBhbmQgMSBidWZmZXIgbWFwIHBlciBzZWNvbmQgdG8gMTAgbmVpZ2hib3JzLCByYW5nZSBsaXN0 IHJlcXVpcmVzIH4gMzAga2JwcyBpbiB0aGUgd29yc3QgY2FzZSB2cy4gfiAxNSBrYnBzIGZvciBi aW5zLiBGb3IgYSAxIE1icHMgc3RyZWFtLCB0aGF0J3MgYSAzJSBvdmVyaGVhZCBpbnN0ZWFkIG9m IDEuNSUsIHdoaWNoIEkgZG9uJ3QgdGhpbmsgaXMgdGhhdCBiaWcgYSBkZWFsLg0KDQpOb3csIHR3 byB0aGluZ3M6IDEpIGFuIG9wdGltaXplZCBpbXBsZW1lbnRhdGlvbiBvZiByYW5nZSBsaXN0cyB3 b3VsZCBlbmNvZGUgc2luZ2xlLWVsZW1lbnQgcmFuZ2VzIHdpdGggYSBzaW5nbGUgaW50ZWdlciwg c28gdGhlIG92ZXJoZWFkIHdvdWxkIGJlIGlkZW50aWNhbCB0byB0aGF0IG9mIGJpbnMgKGkuZS4s IDEuNSUpOyAyKSB3ZSdyZSB0YWxraW5nIGFib3V0IHRoZSB3b3JzdCBjYXNlIHdoaWNoIGlzIGV4 dHJlbWVseSB1bmxpa2VseSB0byBoYXBwZW4uLi4gaXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8g ZG8gdGhlIGF2ZXJhZ2UgY2FzZSBhbmFseXNpcyBmb3IgdGhlIFtQKzEsUCtXXSBpbnRlcnZhbC4N Cg0KRmFiaW8NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFybm8g QmFra2VyIFttYWlsdG86YXJub0Bjcy52dS5ubF0NCj4gU2VudDogbHVuZGkgMTQgbWFpIDIwMTIg MTQ6MzENCj4gVG86IFBpY2NvbmkgRmFiaW8NCj4gQ2M6IHpoYW5neXVuZmVpOyBwcHNwDQo+IFN1 YmplY3Q6IFJlOiBbcHBzcF0gu9i4tDogUmU6u9i4tDogUmU6IFByb3Bvc2FsIHRvIHJlc29sdmUg SXNzdWUgMTAgKyAxMw0KPiANCj4gT24gMTQvMDUvMjAxMiAxMzoxNywgUGljY29uaSBGYWJpbyB3 cm90ZToNCj4gPiBTb3JyeSBhYm91dCB0aGUgbGF0ZSByZXBseS4gSSBhZ3JlZSB3aXRoIFl1bmZl aS4gQXMgSSBtZW50aW9uZWQNCj4gZHVyaW5nDQo+ID4gdGhlIFBhcmlzIG1lZXRpbmcsIEkgdGhp bmsgdGhhdCBtb3N0IGV4Y2hhbmdlZCBidWZmZXIgbWFwIGFyZSBsaWtlbHkNCj4gPiB0byBsb29r IGxpa2UgdGhpczogMSkgYSBjb250aWd1b3VzIHJhbmdlIFswLVBdICh0aGUgcGVlciBoYXMgYWxs DQo+ID4gY2h1bmtzIGZyb20gMCB0byBQLCB3aGVyZSBQIGlzIHRoZSBwbGF5YmFjayBwb3NpdGlv biksIGEgc3BhcnNlbHkNCj4gPiBwb3B1bGF0ZWQgcmFuZ2UgW1ArMSxQK1ddIHdoaWNoIGNvcnJl c3BvbmRzIHRvIHRoZSBkb3dubG9hZCB3aW5kb3csDQo+ID4gYW5kIGFuIGVtcHR5IHJhbmdlIFtQ K1crMSxOXS4gU28gSaGvbSBub3Qgc3VyZSB0aGF0IGJpbiBudW1iZXJzIHdvdWxkDQo+ID4gY29u c3RpdHV0ZSBhIGJpZyBpbXByb3ZlbWVudCBvdmVyIHVzaW5nIGEgbGlzdCBvZiByYW5nZXMuDQo+ ID4NCj4gDQo+IEhpIEZhYmlvIGFuZCBhbGwNCj4gDQo+IGNhbiB5b3UgY2xhcmlmeSBob3cgeW91 IHdvdWxkIGV4cHJlc3MgdGhlIGFib3ZlIGV4YW1wbGUgaW4geW91cg0KPiBwcm9wb3NlZCBudW1i ZXJpbmcgc2NoZW1lLCB3aGljaCBpcyBbc3RhcnQgYnl0ZSByYW5nZSxlbmQgYnl0ZSByYW5nZV0s DQo+IHJpZ2h0Pw0KPiANCj4gSW4gYmluIG5vdGF0aW9uLCB0aGVyZSB3b3VsZCBiZSAxIG9yIG1v cmUgYmlucyB0byBleHByZXNzIFswLVBdIChtb3JlDQo+IHRoYW4gMSBpcyBuZWVkZWQgaWYgUCBp cyBub3QgYSBwb3dlciBvZiAyKS4gRm9yIFtQKzEsUCtXXSB0aGVyZSB3b3VsZA0KPiBiZSwgYXQg d29yc3QgY2FzZSAoPTAxMDEwMTAxMDEuLi4pIDEgYmluIHBlciAyIGNodW5rcywgc28gVy8yIGJp bnMuIFRoZQ0KPiBlbXB0eSByYW5nZSB3b3VsZCByZXF1aXJlIG5vIGJpbnMuIEFzIGVhY2ggYmlu IHJlcXVpcmVzIDEgaW50LCB0aGUgb24tDQo+IHRoZS13aXJlIGNvc3RzIG9mIHRyYW5zbWl0dGlu ZyB0aGlzIGNodW5rIGF2YWlsYWJpbGl0eSBtYXAgYXJlIH4gVy8yDQo+IGludGVnZXJzLg0KPiAN Cj4gVG8gc3VtbWVyaXplZCBteSBwb3NpdGlvbjogYmlucyBhcmUgbW9yZSBlZmZpY2llbnQgaW4g Y29tbW9uDQo+IHNpdHVhdGlvbnMsIGFuZCBsZWFkIHRvIGEgY2xlYW4gcHJvdG9jb2wgZGVzaWdu IHdoZW4gTWVya2xlIEhhc2ggdHJlZXMNCj4gYXJlIHVzZWQgZm9yIGNvbnRlbnQgaW50ZWdyaXR5 IHByb3RlY3Rpb24sIGF0IHRoZSBjb3N0IG9mIGEgc21hbGwNCj4gaW5jcmVhc2UgaW4gY29tcGxl eGl0eS4NCj4gDQo+IFJlZ2FyZHMsDQo+ICAgICBBcm5vDQoNCg== From zhangyunfei@chinamobile.com Mon May 14 19:55:08 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 250B021F8539 for ; Mon, 14 May 2012 19:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.614 X-Spam-Level: X-Spam-Status: No, score=-91.614 tagged_above=-999 required=5 tests=[AWL=-1.775, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXbF7zBaM1Rj for ; Mon, 14 May 2012 19:55:07 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 392EA21F851B for ; Mon, 14 May 2012 19:55:07 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 893A0E57D; Tue, 15 May 2012 10:55:04 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 8000BE571; Tue, 15 May 2012 10:55:04 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051510550222-7031 ; Tue, 15 May 2012 10:55:02 +0800 Date: Tue, 15 May 2012 10:54:59 +0800 From: zhangyunfei To: "arno@cs.vu.nl" , ppsp References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <4FAA0C76.9010306@cs.vu.nl>, <4FAA1680.9080000@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051510545944553531@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:55:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:55:04, Serialize complete at 2012-05-15 10:55:04 Content-Type: multipart/alternative; boundary="----=_001_NextPart477186012210_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003 X-TM-AS-Result: No--24.387-7.0-31-10 X-imss-scan-details: No--24.387-7.0-31-10;No--24.387-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] =?gb2312?b?W1NwYW1dILvYuLQ6IFJlOrvYuLQ6IFJlOiAgUHJvcG9z?= =?gb2312?b?YWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEz?= 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, 15 May 2012 02:55:08 -0000 This is a multi-part message in MIME format. ------=_001_NextPart477186012210_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQXJub6OsDQogICAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoN CkZyb206IEFybm8gQmFra2VyDQpEYXRlOiAyMDEyLTA1LTA5IDE1OjAyDQpUbzogcHBzcEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtwcHNwXVtTcGFtXSC72Li0OiBSZTq72Li0OiBSZTogUHJvcG9z YWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEzDQpPbiAwOS8wNS8yMDEyIDA4OjE5LCBBcm5vIEJh a2tlciB3cm90ZToNCj4gDQo+PiBJbiBzdWNoIGNhc2VzLCByZXF1c3RpbmcNCj4+IGEgcmFuZ2Ug b2YgY2h1bmtzIG5lZWRzIG5vIG1vcmUgYml0cyB0aGFuIGJpbiBudW1iZXIuIFdoYXQncyB3b3Jz ZSwgaWYNCj4+IHRoZSBjaHVua3MgcGVlciBBIGhhcyBpcw0KPj4gc3BhcnNlbHkgZGlzdHJpYnV0 ZWQsIGkuZS4sIHRoZSBjaHVua21hcCBpcyBsaWtlbHkgdG8gYmUgMTAwMDEwMTExMTAsDQo+PiBi aW4gbnVtYmVyaW5nIG5lZWRzIG1vcmUgYml0cy4NCj4gDQo+IEJpbnMgYXJlIGFjdHVhbGx5IG1v cmUgZWZmaWNpZW50IHRoYW4gKHN0YXJ0LGVuZCkgaW4gdGhpcyBleGFtcGxlLiBXaXRoDQo+IGJp biBudW1iZXJzLCB5b3UnbGwgaW4gdGhlIHdvcnN0IGNhc2UgbmVlZCBhbiBpbnRlZ2VyIGZvciBl dmVyeSAxIGluIHRoZQ0KPiBiaXRtYXAsIHNvIDYgaW4gdGhpcyBjYXNlLiBJbiBhIGJldHRlciBj YXNlIHdlIG1pZ2h0IGJlIGFibGUgdG8gYWRkcmVzcw0KPiB0aGUgNCBvbmVzIGF0IHRoZSBlbmQg YXMgYSBzaW5nbGUgYmluLiBIb3dldmVyLCBpZiB5b3UgdXNlIChzdGFydCxlbmQpDQo+IGFkZHJl c3NpbmcsIHlvdSdsbCBhY3R1YWxseSBuZWVkIDIgaW50ZWdlcnMgcGVyIDEgYml0LCBvciAxMiBp bnRlZ2Vycy4NCj4gDQoNCkNvcnJlY3Rpb246IGJpbnMgYXJlIGVxdWFsbHkgb3IgbW9yZSBlZmZp Y2llbnQuIEl0IHdpbGwgdGFrZSAzDQooc3RhcnQsZW5kKSBieXRlIHJhbmdlIHBhaXJzIHRvIHJl cHJlc2VudCAxMDAwMTAxMTExMCwgc28gNiBpbnRzLiBJdA0Kd2lsbCB0YWtlIDMgdG8gNiBiaW5z IHRvIHJlcHJlc2VudCB0aGF0LCBzbyAzLTYgaW50cy4NCg0KWXVuZmVpOiBGb3IgcmVwcmVzZW50 YXRpbmcgYSBzaW5nbGUgMSBmb2xsb3dlZCBieSAwLCB0aGUgcmFuZ2UgcGFpciBjYW4gYmUgc2hv cnRlbmVkIA0KZnJvbSAoc3RhcnQsZW5kKSB0byBqdXN0IChzdGFydCkuIFNvIDMgaW50cyBhcmUg ZWxpbWluYXRlZCBpbiB0aGlzIGNhc2UuDQpTbyBteSBwb2ludCBpcyB0aGF0Og0KMSkgaW4gYSB3 b3JzdCBjYXNlIGZvciBiaW4sIDEwMTAxMC4uLiwgdGhlIHNjaGVtZSBvZiBiaW4gYW5kIHJhbmdl IGFyZSBlcXVhbCBjb25zaWRlcmluZyBpbiBzdWNoIGNhc2UgcmFuZ2Ugc2NoZW1lIC4gb25seSAx IGludHMgaXMgbmVlZGVkIGZvciBhIHNpbmdsZSAxOw0KMikgaW4gYSBjb21tb24gY2FzZSB3aGVy ZSB0aGVyZSBhcmUgdGhlIGNvbnNlY3V0aXZlIDEgd2l0aCB0aGUgYW1vdW50IG5vdCB0aGUgb3Jk ZXIgb2YgcG93ZXIgb2YgMiwNCnRoZSBzY2hlbWUgb2YgYmluIGlzIG5vdCBtb3JlIGVmZmljaWNl bnQgdGhhbiByYW5nZS4NCjMpIE9ubHkgaW4gdGhlIGNhc2Ugd2hlcmUgdGhlIGNvbnNlY3V0aXZl IDEgYXJlIG9mIHRoZSBhbW91bnQgdGhlIG9yZGVyIG9mIHBvd2VyIG9mIDIsIG9uZSBpbnQgaXMg c2F2ZWQgaW4gYmluIHNjaGVtZS4NCkhvd2V2ZXIgdGhlIGNvbXBsZXhpdHkgaXMgYWxzbyBpbmNy ZWFzZWQgaW4gYWxsIDMgY2FzZXMuIFNvIHJhbmdlIHNjaGVtZSBpcyBhIHNpbXBsZSB3YXkgdG8g YWRkcmVzcyB0aGlzLiANCg0KQ1UsDQogICAgIEFybm8NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart477186012210_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Arno=A3=AC
    Please see inline.
 
zhangyunfei
 
On 09/05/2012 08:19, Arno Bakker wrote:
> 
>> In such cases, requsting
>> a range of chunks needs no&nbs= p;more bits than bin number. What's worse,&n= bsp;if
>> the chunks peer A has is
>> sparsely distributed, i.e., the chu= nkmap is likely to be 10001011110,
>> bin numbering needs more bits.
> 
> Bins are actually more efficient t= han (start,end) in this example. With
> bin numbers, you'll in the worst&n= bsp;case need an integer for every 1 in=  the
> bitmap, so 6 in this case. In=  a better case we might be able to=  address
> the 4 ones at the end as = ;a single bin. However, if you use (sta= rt,end)
> addressing, you'll actually need 2 = ;integers per 1 bit, or 12 integers.
> 
 
Correction: bins are equally or more ef= ficient. It will take 3
(start,end) byte range pairs to represent&nb= sp;10001011110, so 6 ints. It
will take 3 to 6 bins to represent=  that, so 3-6 ints.
 
Yunfei: For representating a single 1 follow= ed by 0,=20 the range pair can be shortened
from (start,end) to just (start). So 3 ints = are=20 eliminated in this case.
So my point is that:
1) in a worst case for bin, 101010..., the s= cheme of=20 bin and range are equal considering in such case range scheme . only 1 int= s is=20 needed for a single 1;
2) in a common case where there ar= e=20 the consecutive 1 with the amount not the order of power of 2,
the scheme of bin is not more efficicen= t than=20 range.
3) Only in the case=20 where the consecutive 1 are of the amount the order of powe= r of=20 2, one int is saved in bin scheme.
However the complexity is also increase= d in all=20 3 cases. So range scheme is a simple way to address this. <= /DIV>
 
CU,
     Arno
 
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart477186012210_=------ From zhangyunfei@chinamobile.com Mon May 14 19:55:25 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 267B121F85D8 for ; Mon, 14 May 2012 19:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.911 X-Spam-Level: X-Spam-Status: No, score=-90.911 tagged_above=-999 required=5 tests=[AWL=-2.183, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHowoPxBZfux for ; Mon, 14 May 2012 19:55:24 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1C721F851B for ; Mon, 14 May 2012 19:55:23 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3DCFDE580; Tue, 15 May 2012 10:55:21 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 1ADABE57D; Tue, 15 May 2012 10:55:21 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051510551972-7040 ; Tue, 15 May 2012 10:55:19 +0800 Date: Tue, 15 May 2012 10:55:16 +0800 From: zhangyunfei To: "Picconi Fabio" , "arno@cs.vu.nl" References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051510551681806632@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:55:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:55:20 Content-Type: multipart/alternative; boundary="----=_001_NextPart165312141558_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003 X-TM-AS-Result: No--41.393-7.0-31-10 X-imss-scan-details: No--41.393-7.0-31-10;No--41.393-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?u9i4tDogUkU6ICC72Li0OiBSZTq72Li0OiBSZTogIFBy?= =?gb2312?b?b3Bvc2FsIHRvIHJlc29sdmUgSXNzdWUgMTAgKyAxMw==?= 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, 15 May 2012 02:55:25 -0000 ------=_001_NextPart165312141558_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" KzEuDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoNCreivP7Iy6O6IFBpY2NvbmkgRmFiaW8NCreiy83K sbzko7ogMjAxMi0wNS0xNCAxOToxNw0KytW8/sjLo7ogemhhbmd5dW5mZWk7IGFybm9AY3MudnUu bmwNCrOty82juiBwcHNwDQrW98zio7ogUkU6IFtwcHNwXSC72Li0OiBSZTq72Li0OiBSZTogUHJv cG9zYWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEzDQpTb3JyeSBhYm91dCB0aGUgbGF0ZSByZXBs eS4gSSBhZ3JlZSB3aXRoIFl1bmZlaS4gQXMgSSBtZW50aW9uZWQgZHVyaW5nIHRoZSBQYXJpcyBt ZWV0aW5nLCBJIHRoaW5rIHRoYXQgbW9zdCBleGNoYW5nZWQgYnVmZmVyIG1hcCBhcmUgbGlrZWx5 IHRvIGxvb2sgbGlrZSB0aGlzOiAxKSBhIGNvbnRpZ3VvdXMgcmFuZ2UgWzAtUF0gKHRoZSBwZWVy IGhhcyBhbGwgY2h1bmtzIGZyb20gMCB0byBQLCB3aGVyZSBQIGlzIHRoZSBwbGF5YmFjayBwb3Np dGlvbiksIGEgc3BhcnNlbHkgcG9wdWxhdGVkIHJhbmdlIFtQKzEsUCtXXSB3aGljaCBjb3JyZXNw b25kcyB0byB0aGUgZG93bmxvYWQgd2luZG93LCBhbmQgYW4gZW1wdHkgcmFuZ2UgW1ArVysxLE5d LiBTbyBJoa9tIG5vdCBzdXJlIHRoYXQgYmluIG51bWJlcnMgd291bGQgY29uc3RpdHV0ZSBhIGJp ZyBpbXByb3ZlbWVudCBvdmVyIHVzaW5nIGEgbGlzdCBvZiByYW5nZXMuDQpGYWJpbw0KIA0KRnJv bTogcHBzcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2Ygemhhbmd5dW5mZWkNClNlbnQ6IG1lcmNyZWRpIDE4IGF2cmlsIDIwMTIgMTI6 MzUNClRvOiBhcm5vQGNzLnZ1Lm5sDQpDYzogcHBzcA0KU3ViamVjdDogW3Bwc3BdILvYuLQ6IFJl OrvYuLQ6IFJlOiBQcm9wb3NhbCB0byByZXNvbHZlIElzc3VlIDEwICsgMTMNCiANCkhpIEFybm+j rA0KICAgIFBscyBzZWUgaW5saW5lLlRoYW5rcy4NCiANCll1bmZlaQ0KIA0KDQoNCg0Kemhhbmd5 dW5mZWkNCiANCreivP7Iy6O6IEFybm8gQmFra2VyDQq3osvNyrG85KO6IDIwMTItMDQtMTggMTU6 MzENCsrVvP7Iy6O6IHpoYW5neXVuZmVpDQqzrcvNo7ogcHBzcA0K1vfM4qO6IFJlOltwcHNwXbvY uLQ6IFJlOiBQcm9wb3NhbCB0byByZXNvbHZlIElzc3VlIDEwICsgMTMNCk9uIDE4LzA0LzIwMTIg MDk6MDAsIHpoYW5neXVuZmVpIHdyb3RlOg0KPiBIaSBBcm5vLA0KPiBJIHRoaW5rIEkgdW5kZXJz dGFuZCB5b3VyIGV4YW1wbGUuIFNvIGlzIHRoZXJlIHNvbWUgZmlndXJlcyB0byBzaG93IHRoYXQg DQo+IHRoZSBjYXNlIEkgcmFpc2VkIGlzIGEgc21hbGwtcHJvYmFiaWxpdHkgY2FzZT8gVGhhdCB3 b3VsZCBiZSBjb252aW5jaW5nIA0KPiB0byBzaG93IHRoZSBlZmZpY2llbmN5IG9mIE1IVCBtZXRo b2QuDQogDQpIaSBZdW5mZWkgYW5kIGFsbA0KIA0KYmluIG51bWJlcnMgY2FuIGJlIG1vcmUgYmFu ZHdpZHRoIGVmZmljaWVudCBhbmQgbGVhZCB0byBhIG1vcmUgZWxlZ2FudA0KZGVzaWduIHdoZW4g dXNlZCBpbiBjb21iaW5hdGlvbiB3aXRoIGNvbnRlbnQgaW50ZWdyaXR5IHByb3RlY3Rpb24gdXNp bmcNCk1lcmtsZSBoYXNoIHRyZWVzLCBhcyB0aGVyZSBpcyBvbmUgdW5pdCBpbiB0aGUgc3lzdGVt IHRoZW4uIFRoZQ0KZWZmaWNpZW5jeSBnYWlucyBkZXBlbmQgb24gdXNhZ2UuIElmIHlvdSByZXF1 ZXN0IGNodW5rcyBpbiBncm91cHMgb2YNCnBvd2VycyBvZiAyIChlLmcuIDEyOCBLaUIsIDI1NiBL aUIpIGFzIGlzIGNvbW1vbiBpbiBjb21wdXRlciBuZXR3b3JrcywNCnlvdSBvbmx5IG5lZWQgc2lu Z2xlIGJpbiBudW1iZXJzLiBPbiB0aGUgb3RoZXIgaGFuZCwgaWYgeW91IHdhbnQgdG8NCmV4cHJl c3MgYSBzbGlkaW5nIHdpbmRvdyBvdmVyIHRoZSBjaHVuayBzcGFjZSwgZXNwZWNpYWxseSB3aGVu IHRoYXQgaXMNCm5vdCBhIHBvd2VyIG9mIDIgd2lkZSwgeW91IG5lZWQgbW9yZSB0aGFuIDEgYmlu IG51bWJlci4NCiANCltZdW5mZWldIFRoaXMgaXMgd2hhdCBJIHdvcnJ5IGFib3V0LiBXZSBjYW5u b3QgYXNzdXJlIHRoYXQgZWFjaCB0aW1lIHdlIGNhbiByZXF1ZXN0IA0KY2h1bmtzIGluIGdyb3Vw cyBvZiBwb3dlcnMgb2YgMiwgYXMgaXQncyBkZXBlbmRlbnQgb24gd2hhdCB0aGUgc2VydmluZyBw ZWVycyBoYXZlLCB3aGljaCANCmlzIGhhcmQgdG8gZW5zdXJlIHRoYXQgdGhlIG51bWJlciBvZiBh dmFpbGFibGUgY2h1bmtzIGJlaW5nIHBvd2VycyBvZiAyLiBJbiBzdWNoIGNhc2VzLCByZXF1c3Rp bmcgDQphIHJhbmdlIG9mIGNodW5rcyBuZWVkcyBubyBtb3JlIGJpdHMgdGhhbiBiaW4gbnVtYmVy LiBXaGF0J3Mgd29yc2UsIGlmIHRoZSBjaHVua3MgcGVlciBBIGhhcyBpcyANCnNwYXJzZWx5IGRp c3RyaWJ1dGVkLCBpLmUuLCB0aGUgY2h1bmttYXAgaXMgbGlrZWx5IHRvIGJlIDEwMDAxMDExMTEw LCBiaW4gbnVtYmVyaW5nIG5lZWRzIG1vcmUgYml0cy4NCiANCj4gQlRXLCBJIHJlbWVtYmVyIHRo YXQgaW4gbGFzdCBpbnRlcmltIG1lZXRpbmcsIHlvdSByZXBsaWVkIHRoYXQgdGhlIA0KPiBtYXBw aW5nIGJldHdlZW4gYmlubWFwIGFuZCByYW5nZSBleHByZXNzaW9uIGlzIHF1aXRlIGVhc3kuIENv dWxkIHlvdSANCj4gZWxhYm9yYXRlIHRoaXMgbWFwcGluZz8gVGhhbmtzLg0KIA0KQXNzdW1pbmcg cmFuZ2VzIGFyZSBpbnRlcnZhbHMgb2YgYSBsaXN0IG9mIGNodW5rcyBudW1iZXJlZCAwLi4uTjog Zm9yIGENCmdpdmVuIGJpbiBudW1iZXIgImJpbiI6DQogDQpzdGFydHJhbmdlID0gKGJpbiAmIChi aW4gKyAxKSkvMg0KZW5kcmFuZ2UgPSAoKGJpbiB8IChiaW4gKyAxKSkgLSAxKS8yDQpbWXVuZmVp XSBJIG5lZWQgbW9yZSB0aW1lIHRvIHJlcGx5IG9uIHRoaXM6KQ0KTm90ZSB0aGF0IGEgYmlubWFw IGlzIGEgbm92ZWwgZGF0YSBzdHJ1Y3R1cmUgdG8gZWZmaWNpZW50bHkgc3RvcmUgYQ0KYml0bWFw LCB3aGljaCBpcyBub3QgZGlyZWN0bHkgcmVsYXRlZCB0byBiaW4gbnVtYmVycy4NCiANClJlZ2Fy ZHMsDQogICAgQXJubw0KIA== ------=_001_NextPart165312141558_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
+1.
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Picconi=20 Fabio
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-05-14 19:17
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei; arno@cs.vu.nl
=B3=AD=CB=CD=A3=BA ppsp
=D6=F7=CC=E2=A3=BA RE: [ppsp] =BB=D8=B8=B4: Re:=BB=D8=B8= =B4: Re: Proposal to resolve Issue 10 +=20 13

Sorry=20 about the late reply. I agree with Yunfei. As I mentioned during the Paris = meeting, I think that most exchanged buffer map are likely to look like thi= s: 1)=20 a contiguous range [0-P] (the peer has all chunks from 0 to P, where P is t= he=20 playback position), a sparsely populated range [P+1,P+W] which corresponds = to=20 the download window, and an empty range [P+W+1,N]. So I=A1=AFm not sure tha= t bin=20 numbers would constitute a big improvement over using a list of=20 ranges.

Fabio

 

From:<= /B>=20 ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of=20 zhangyunfei
Sent: mercredi 18 avril 2012 12:35
To: = arno@cs.vu.nl
Cc: ppsp
Subject: [ppsp] =BB=D8=B8=B4: Re:<= SPAN=20 style=3D"FONT-SIZE: 10pt" lang=3DZH-CN>=BB=D8=B8=B4: Re: Proposa= l to=20 resolve Issue 10 + 13

 

Hi=20 Arno=A3=AC

   =20 Pls see inline.Thanks.

 

Yunfei

 

zhangyunfei

 

= =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-04-18 15:31

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

= =B3=AD=CB=CD=A3=BA ppsp

= =D6=F7=CC=E2=A3=BA Re:[ppsp]=BB=D8=B8=B4: Re: Proposal to resolve Issue 10 +=20 13

On 18/04/2012 09:00, zhangyunfei wrote:

> Hi Arno,

> I think I understand your example. So is there some figures to show that 

> the case I raised is a small-probability case? That would be convincing 

> to show the efficiency of MHT method.

 

Hi Yunfei and all

 

bin numbers can be more bandwidth efficient and lead to a more elegant

design when used in combination with content integrity protection using

Merkle hash trees, as there is one unit in the system then. The

efficiency gains depend on usage. If you request chunks in groups of

powers of 2 (e.g. 128 KiB, 256 KiB) as is common in computer networks,

you only need single bin numbers. On the other hand, if you want to

express a sliding window over the chunk space, especially when that is

not a power of 2 wide, you need more than 1 bin number.

 

[Yunfei]=20 This is what I worry about. We cannot assure that each time we can request =

chunks=20 in groups of powers of 2, as it's dependent on=20 what the serving peers have, which

is=20 hard to ensure that the number of available chunks being powers=20 of 2. In=20 such cases, requsting

a=20 range of chunks needs no more bits than bin number. What's worse, if the ch= unks=20 peer A has is

sparsely=20 distributed, i.e., the chunkmap is likely to be 10001011110, bin numbering = needs=20 more bits.

 

> BTW, I remember that in last interim meeting, you replied that the 

> mapping between binmap and range expression is quite easy. Could you 

> elaborate this mapping? Thanks.

 

Assuming ranges are intervals of a list of chunks numbered 0...N: for a

given bin number "bin":

 

startrange =3D (bin & (bin + 1))/2

endrange =3D ((bin | (bin + 1)) - 1)/2

[Yunfei]=20 I need more time to reply on this:)

Note that a binmap is a novel data structure to efficiently store a

bitmap, which is not directly related to bin numbers.

 

Regards,

    Arno

 

From: Arno Bakker
Date: 2012-05-09 15:02
To: ppsp@ietf.org
Subject: Re: [ppsp][Spam] =BB=D8=B8=B4: Re:=BB=D8=B8=B4: = Re: Proposal to resolve=20 Issue 10 + 13
------=_001_NextPart165312141558_=------ From zhangyunfei@chinamobile.com Mon May 14 19:57:03 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 882B721F85DF for ; Mon, 14 May 2012 19:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.536 X-Spam-Level: X-Spam-Status: No, score=-90.536 tagged_above=-999 required=5 tests=[AWL=-2.222, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUwaKGVHEXSd for ; Mon, 14 May 2012 19:57:02 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8125921F8539 for ; Mon, 14 May 2012 19:57:02 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 61787E59C; Tue, 15 May 2012 10:57:01 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 3D9BFE57D; Tue, 15 May 2012 10:57:01 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051510565914-7087 ; Tue, 15 May 2012 10:56:59 +0800 Date: Tue, 15 May 2012 10:56:56 +0800 From: zhangyunfei To: "Picconi Fabio" , "arno@cs.vu.nl" References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl>, <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051510565602133833@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:56:59, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 10:57:01, Serialize complete at 2012-05-15 10:57:01 Content-Type: multipart/alternative; boundary="----=_001_NextPart661060188025_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003 X-TM-AS-Result: No--33.507-7.0-31-10 X-imss-scan-details: No--33.507-7.0-31-10;No--33.507-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?u9i4tDogUkU6ICC72Li0OiBSZTq72Li0OiBSZTogIFBy?= =?gb2312?b?b3Bvc2FsIHRvIHJlc29sdmUgSXNzdWUgMTAgKyAxMw==?= 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, 15 May 2012 02:57:03 -0000 This is a multi-part message in MIME format. ------=_001_NextPart661060188025_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" U2FtZSBpZGVhIHdpdGggRmFiaW8uDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoNCreivP7Iy6O6IFBp Y2NvbmkgRmFiaW8NCreiy83Ksbzko7ogMjAxMi0wNS0xNCAyMzo1Mg0KytW8/sjLo7ogYXJub0Bj cy52dS5ubA0Ks63LzaO6IHpoYW5neXVuZmVpOyBwcHNwDQrW98zio7ogUkU6IFtwcHNwXSC72Li0 OiBSZTq72Li0OiBSZTogUHJvcG9zYWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEzDQpIZXJlJ3Mg YSBicmllZiBjb21wYXJpc29uOg0KDQpbMC1QXQ0KQmluczogMSBpbnRlZ2VyIGlmIHBvd2VyIG9m IDIsIG11bHRpcGxlIGludGVnZXJzIG90aGVyd2lzZQ0KUmFuZ2UgbGlzdDogYWx3YXlzIDIgaW50 ZWdlcnMNCg0KW1ArMSxQK1ddIHdvcnN0IGNhc2UNCkJpbnM6IFcvMiBpbnRlZ2Vycw0KUmFuZ2Ug bGlzdDogVy8yIHJhbmdlcywgaS5lLiwgVyBpbnRlZ2Vycw0KDQpbUCsxLFArV10gYXZlcmFnZSBj YXNlDQpCaW5zOiA/DQpSYW5nZSBsaXN0OiA/DQoNCltQK1crMSxOXSBlbXB0eSByYW5nZQ0KQmlu czogbm8gaW50ZWdlcnMNClJhbmdlIGxpc3Q6IG5vIGludGVnZXJzDQoNClRha2luZyBXPTMwIHNl Y29uZHMgYW5kIDMgY2h1bmtzIHBlciBzZWNvbmQsIDQgYnl0ZXMgcGVyIGludGVnZXIsIGFuZCAx IGJ1ZmZlciBtYXAgcGVyIHNlY29uZCB0byAxMCBuZWlnaGJvcnMsIHJhbmdlIGxpc3QgcmVxdWly ZXMgfiAzMCBrYnBzIGluIHRoZSB3b3JzdCBjYXNlIHZzLiB+IDE1IGticHMgZm9yIGJpbnMuIEZv ciBhIDEgTWJwcyBzdHJlYW0sIHRoYXQncyBhIDMlIG92ZXJoZWFkIGluc3RlYWQgb2YgMS41JSwg d2hpY2ggSSBkb24ndCB0aGluayBpcyB0aGF0IGJpZyBhIGRlYWwuDQoNCk5vdywgdHdvIHRoaW5n czogMSkgYW4gb3B0aW1pemVkIGltcGxlbWVudGF0aW9uIG9mIHJhbmdlIGxpc3RzIHdvdWxkIGVu Y29kZSBzaW5nbGUtZWxlbWVudCByYW5nZXMgd2l0aCBhIHNpbmdsZSBpbnRlZ2VyLCBzbyB0aGUg b3ZlcmhlYWQgd291bGQgYmUgaWRlbnRpY2FsIHRvIHRoYXQgb2YgYmlucyAoaS5lLiwgMS41JSk7 IDIpIHdlJ3JlIHRhbGtpbmcgYWJvdXQgdGhlIHdvcnN0IGNhc2Ugd2hpY2ggaXMgZXh0cmVtZWx5 IHVubGlrZWx5IHRvIGhhcHBlbi4uLiBpdCB3b3VsZCBiZSBpbnRlcmVzdGluZyB0byBkbyB0aGUg YXZlcmFnZSBjYXNlIGFuYWx5c2lzIGZvciB0aGUgW1ArMSxQK1ddIGludGVydmFsLg0KDQpGYWJp bw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQXJubyBCYWtrZXIg W21haWx0bzphcm5vQGNzLnZ1Lm5sXQ0KPiBTZW50OiBsdW5kaSAxNCBtYWkgMjAxMiAxNDozMQ0K PiBUbzogUGljY29uaSBGYWJpbw0KPiBDYzogemhhbmd5dW5mZWk7IHBwc3ANCj4gU3ViamVjdDog UmU6IFtwcHNwXSC72Li0OiBSZTq72Li0OiBSZTogUHJvcG9zYWwgdG8gcmVzb2x2ZSBJc3N1ZSAx MCArIDEzDQo+IA0KPiBPbiAxNC8wNS8yMDEyIDEzOjE3LCBQaWNjb25pIEZhYmlvIHdyb3RlOg0K PiA+IFNvcnJ5IGFib3V0IHRoZSBsYXRlIHJlcGx5LiBJIGFncmVlIHdpdGggWXVuZmVpLiBBcyBJ IG1lbnRpb25lZA0KPiBkdXJpbmcNCj4gPiB0aGUgUGFyaXMgbWVldGluZywgSSB0aGluayB0aGF0 IG1vc3QgZXhjaGFuZ2VkIGJ1ZmZlciBtYXAgYXJlIGxpa2VseQ0KPiA+IHRvIGxvb2sgbGlrZSB0 aGlzOiAxKSBhIGNvbnRpZ3VvdXMgcmFuZ2UgWzAtUF0gKHRoZSBwZWVyIGhhcyBhbGwNCj4gPiBj aHVua3MgZnJvbSAwIHRvIFAsIHdoZXJlIFAgaXMgdGhlIHBsYXliYWNrIHBvc2l0aW9uKSwgYSBz cGFyc2VseQ0KPiA+IHBvcHVsYXRlZCByYW5nZSBbUCsxLFArV10gd2hpY2ggY29ycmVzcG9uZHMg dG8gdGhlIGRvd25sb2FkIHdpbmRvdywNCj4gPiBhbmQgYW4gZW1wdHkgcmFuZ2UgW1ArVysxLE5d LiBTbyBJoa9tIG5vdCBzdXJlIHRoYXQgYmluIG51bWJlcnMgd291bGQNCj4gPiBjb25zdGl0dXRl IGEgYmlnIGltcHJvdmVtZW50IG92ZXIgdXNpbmcgYSBsaXN0IG9mIHJhbmdlcy4NCj4gPg0KPiAN Cj4gSGkgRmFiaW8gYW5kIGFsbA0KPiANCj4gY2FuIHlvdSBjbGFyaWZ5IGhvdyB5b3Ugd291bGQg ZXhwcmVzcyB0aGUgYWJvdmUgZXhhbXBsZSBpbiB5b3VyDQo+IHByb3Bvc2VkIG51bWJlcmluZyBz Y2hlbWUsIHdoaWNoIGlzIFtzdGFydCBieXRlIHJhbmdlLGVuZCBieXRlIHJhbmdlXSwNCj4gcmln aHQ/DQo+IA0KPiBJbiBiaW4gbm90YXRpb24sIHRoZXJlIHdvdWxkIGJlIDEgb3IgbW9yZSBiaW5z IHRvIGV4cHJlc3MgWzAtUF0gKG1vcmUNCj4gdGhhbiAxIGlzIG5lZWRlZCBpZiBQIGlzIG5vdCBh IHBvd2VyIG9mIDIpLiBGb3IgW1ArMSxQK1ddIHRoZXJlIHdvdWxkDQo+IGJlLCBhdCB3b3JzdCBj YXNlICg9MDEwMTAxMDEwMS4uLikgMSBiaW4gcGVyIDIgY2h1bmtzLCBzbyBXLzIgYmlucy4gVGhl DQo+IGVtcHR5IHJhbmdlIHdvdWxkIHJlcXVpcmUgbm8gYmlucy4gQXMgZWFjaCBiaW4gcmVxdWly ZXMgMSBpbnQsIHRoZSBvbi0NCj4gdGhlLXdpcmUgY29zdHMgb2YgdHJhbnNtaXR0aW5nIHRoaXMg Y2h1bmsgYXZhaWxhYmlsaXR5IG1hcCBhcmUgfiBXLzINCj4gaW50ZWdlcnMuDQo+IA0KPiBUbyBz dW1tZXJpemVkIG15IHBvc2l0aW9uOiBiaW5zIGFyZSBtb3JlIGVmZmljaWVudCBpbiBjb21tb24N Cj4gc2l0dWF0aW9ucywgYW5kIGxlYWQgdG8gYSBjbGVhbiBwcm90b2NvbCBkZXNpZ24gd2hlbiBN ZXJrbGUgSGFzaCB0cmVlcw0KPiBhcmUgdXNlZCBmb3IgY29udGVudCBpbnRlZ3JpdHkgcHJvdGVj dGlvbiwgYXQgdGhlIGNvc3Qgb2YgYSBzbWFsbA0KPiBpbmNyZWFzZSBpbiBjb21wbGV4aXR5Lg0K PiANCj4gUmVnYXJkcywNCj4gICAgIEFybm8= ------=_001_NextPart661060188025_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Same idea with Fabio.
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Picconi=20 Fabio
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-05-14 23:52
=CA=D5=BC=FE=C8=CB=A3=BA arno@cs.vu.nl
=B3=AD=CB=CD=A3=BA zhangyunfei; ppsp
=D6=F7=CC=E2=A3=BA RE: [ppsp] =BB=D8=B8=B4: Re:=BB=D8=B8= =B4: Re: Proposal to resolve Issue 10 +=20 13
Here's a brief comparison:
 
[0-P]
Bins: 1 integer if power of 2, mul= tiple integers otherwise
Range list: always 2 integers
 
[P+1,P+W] worst case
Bins: W/2 integers
Range list: W/2 ranges, i.e., W integer= s
 
[P+1,P+W] average case
Bins: ?
Range list: ?
 
[P+W+1,N] empty range
Bins: no integers
Range list: no integers
 
Taking W=3D30 seconds and 3 chunks per&= nbsp;second, 4 bytes per integer, and 1 = ;buffer map per second to 10 neighbors, = ;range list requires ~ 30 kbps in the&n= bsp;worst case vs. ~ 15 kbps for bins.&= nbsp;For a 1 Mbps stream, that's a 3%&n= bsp;overhead instead of 1.5%, which I don't&= nbsp;think is that big a deal.
 
Now, two things: 1) an optimized implem= entation of range lists would encode single-= element ranges with a single integer, so&nbs= p;the overhead would be identical to that&nb= sp;of bins (i.e., 1.5%); 2) we're talking&nb= sp;about the worst case which is extremely&n= bsp;unlikely to happen... it would be intere= sting to do the average case analysis f= or the [P+1,P+W] interval.
 
Fabio
 
 
> -----Original Message-----
> From: Arno Bakker [mailto:arno@cs.vu.nl]
> Sent: lundi 14 mai 2012 14:31
> To: Picconi Fabio
> Cc: zhangyunfei; ppsp
> Subject: Re: [ppsp] =BB=D8=B8=B4: Re:= =BB=D8=B8=B4: Re: Proposal to resolve Issue = 10 + 13
> 
> On 14/05/2012 13:17, Picconi Fabio = ;wrote:
> > Sorry about the late reply.&n= bsp;I agree with Yunfei. As I mentioned
> during
> > the Paris meeting, I think&nb= sp;that most exchanged buffer map are likely=
> > to look like this: 1) a&= nbsp;contiguous range [0-P] (the peer has al= l
> > chunks from 0 to P, wher= e P is the playback position), a sparse= ly
> > populated range [P+1,P+W] which&nb= sp;corresponds to the download window,
> > and an empty range [P+W+1,N].=  So I=A1=AFm not sure that bin numbers&= nbsp;would
> > constitute a big improvement = over using a list of ranges.
> >
> 
> Hi Fabio and all
> 
> can you clarify how you would = ;express the above example in your
> proposed numbering scheme, which is&nbs= p;[start byte range,end byte range],
> right?
> 
> In bin notation, there would be&nb= sp;1 or more bins to express [0-P] (mor= e
> than 1 is needed if P is = ;not a power of 2). For [P+1,P+W] there=  would
> be, at worst case (=3D0101010101...)&nb= sp;1 bin per 2 chunks, so W/2 bins.&nbs= p;The
> empty range would require no bins.=  As each bin requires 1 int, the o= n-
> the-wire costs of transmitting this&nbs= p;chunk availability map are ~ W/2
> integers.
> 
> To summerized my position: bins ar= e more efficient in common
> situations, and lead to a clean&nb= sp;protocol design when Merkle Hash trees
> are used for content integrity pro= tection, at the cost of a small
> increase in complexity.
> 
> Regards,
>     Arno
 
------=_001_NextPart661060188025_=------ From zhangyunfei@chinamobile.com Mon May 14 20:01:46 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 1AF8821F860E for ; Mon, 14 May 2012 20:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.532 X-Spam-Level: X-Spam-Status: No, score=-95.532 tagged_above=-999 required=5 tests=[AWL=3.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KptfvzS9EbC1 for ; Mon, 14 May 2012 20:01:45 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9E21F860D for ; Mon, 14 May 2012 20:01:44 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 578FAE659; Tue, 15 May 2012 11:01:43 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 48417E59F; Tue, 15 May 2012 11:01:43 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051511014059-7224 ; Tue, 15 May 2012 11:01:40 +0800 Date: Tue, 15 May 2012 11:01:37 +0800 From: zhangyunfei To: "Picconi Fabio" , ppsp , "Martin Stiemerling" References: <2012050316123830359558@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051511013761236636@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 11:01:40, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 11:01:43, Serialize complete at 2012-05-15 11:01:43 Content-Type: multipart/alternative; boundary="----=_001_NextPart685314100282_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003 X-TM-AS-Result: No--36.637-7.0-31-10 X-imss-scan-details: No--36.637-7.0-31-10;No--36.637-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] tickets for IETF 83 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, 15 May 2012 03:01:46 -0000 This is a multi-part message in MIME format. ------=_001_NextPart685314100282_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-2022-jp" SGkgRmFiaW8sDQogICAgVGlja2V0ICMyIHdhcyB3aGF0IE1hcnRpbiBwcm9wb3NlZCBpbiBQYXJp cyBtZWV0aW5nLiBNYXJ0aW4sIERvIHlvdSBzdGlsbCBoYXZlIGNvbmNlcm5zIG9uIHRoaXM/DQoN CkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogUGljY29uaSBGYWJpbw0K RGF0ZTogMjAxMi0wNS0xNCAyMDowNA0KVG86IHpoYW5neXVuZmVpOyBwcHNwDQpTdWJqZWN0OiBS RTogW3Bwc3BdIHRpY2tldHMgZm9yIElFVEYgODMNCkhpLA0KU29tbWUgY29tbWVudHM6DQpUaWNr ZXQgIzEgKGNodW5rIGFkZHJlc3NpbmcgbWVjaGFuaXNtKS4gU2VlIG15IGVtYWlsIHNlbmQgdG9k YXkuDQpUaWNrZXQgIzIuIEkgY2FuGyRCIUcbKEJ0IHJlbWVtYmVyIHdoYXQgdGhpcyB3YXMgYWJv dXQuIDotKQ0KVGlja2V0ICMzIChzZWN1cmUgUEVYKTogSSB0aGluayB0aGF0IHdlIGNhbiBzdGlj ayB0byBhIHNpbXBsZSBQRVggbWVjaGFuaXNtIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBieSBhbiBv cHRpb25hbCBzZWN1cmUgYWxnb3JpdGhtLiBJbiBhZGRpdGlvbiB0byB0aGUgc29sdXRpb24gcHJv cG9zZWQgYnkgQXJubywgdGhlcmUgaXMgYSBzaW1wbGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBieSBK ZXNpIGV0IGFsLiBbMV0uDQpUaWNrZXQgIzQgKEZJTkQgdXNlIGNhc2UpLiBJIGRvbhskQiFHGyhC dCByZWNhbGwgZXhhY3RseSB0aGUgZGV0YWlscyBvZiB0aGlzIGlzc3VlLiBJZiBpdBskQiFHGyhC cyBvbmx5IG1vdGl2YXRpbmcgYSByZXF1ZXN0IHRvIHRoZSB0cmFja2VyIHRvIGZpbmQgcGVlcnMg c3ViamVjdCB0byBhdHRyaWJ1dGUgY29uc3RyYWludHMsIHRoZW4gZmluZGluZyBwZWVycyB3aXRo IGEgc2ltaWxhciB1cGxvYWQgY2FwYWNpdHkgKHRvIHNwZWVkIHVwIHRoZSBkaXNjb3ZlcnkgcGhh c2UpIGlzIGFscmVhZHkgYSBnb29kIG1vdGl2YXRpb24uDQpUaWNrZXQgIzUgKGFkZGl0aW9uYWwg bWVzc2FnZXMpLiBJIHRoaW5rIHRoZSBwcm9wb25lbnRzIG9mIHRoZXNlIG1lc3NhZ2VzIHNob3Vs ZCBkZXNjcmliZSB0aGUgdXNlIGNhc2VzIHdoZXJlIHRoZXNlIG1lc3NhZ2VzIGNhbiBiZSB1c2Vm dWwuDQpDaGVlcnMsDQpGYWJpbw0KWzFdIEcuUC4gSmVzaSwgQS4gTW9udHJlc29yLCBhbmQgTS4g dmFuIFN0ZWVuLiBTZWN1cmUgUGVlciBTYW1wbGluZy4gSW4gQ29tcHV0ZXIgTmV0d29ya3MsIDIw MTAuDQogDQpGcm9tOiBwcHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwcHNwLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiB6aGFuZ3l1bmZlaQ0KU2VudDogamV1ZGkgMyBtYWkgMjAx MiAxMDoxMw0KVG86IHBwc3ANClN1YmplY3Q6IFtwcHNwXSB0aWNrZXRzIGZvciBJRVRGIDgzDQog DQpIaSBhbGwsDQogICAgSSBoYXZlIHN1bW1hcml6ZWQgYW4gaW5pdGlhbCB0aWNrZXRzIGxpc3Qg Zm9yIElFVEYgODMgbWVldGluZy4gUGxlYXNlIHJldmlldyBpdCBhbmQgYWN0aW9ucyBvbiB0aGVz ZSB0aWNrZXRzIGFyZSBleHBlY3RlZC4gVGhhbmtzLg0KIA0KQlINCll1bmZlaSAmU3RlZmFubw0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClBlZXIg cHJvdG9jb2w6DQpUaWNrZXQgIzEbJEIhJxsoQlBvc3QgYW5kIGRpc2N1c3MgdGhlIGFsdGVybmF0 aXZlIHByb3Bvc2FsIGJlc2lkZXMgTUhUIGluIHBlZXIgcHJvdG9jb2wgKFByb3Bvc2FsIDEwKzEz KSwgbGlzdCBpbnRlcnZhbHMgKFRyYWRlb2ZmIGFtb25nIGNvbXBsZXhpdHkgLyBvdmVyaGVhZCAv IGVmZmljaWVuY3kgLyBpbXBsZW1lbnRhdGlvbikgYW5kIGNoZWNrIGdhcHMuIFtNYXJ0aW4bJEIh JBsoQiBZdW5mZWksIEZhYmlvLCBMaWNodW5dDQpUaGlzIHRpY2tldCBpcyBwYXJ0bHkgc29sdmVk LiBTaW1wbGUgbmF0dXJlIG51bWJlciBhZGRyZXNzaW5nIGFuZCByYW5nZWQgZXhwcmVzc2lvbiBv biBjaHVuayBhdmFpbGFiaWxpdHkuIFRoZSBhbmFseXNpcyBhbmQgY29tcGFyaXNvbiBpcyBvbmdv aW5nLiBJJ2Qgc3VnZ2VzdCB0byBoYXZlIGEgZGVhZGxpbmUgZm9yIHRoZSByZXNvbHV0aW9uIHRp bWUgYWZ0ZXIgZGlzY3Vzc2luZyB3aXRoIFN0ZWZhbm8sIGkuZS4sICBNYXkgMjZ0aCBmcm9tIG5v dyBvbiB0byBtYWtlIHRoZSBkZWNpc2lvbiBpbiB0aGUgV0cgbGV2ZWwuDQogDQpUaWNrZXQgIzIb JEIhJxsoQkRpc2N1c3MgdGhlIHBvc3NpYmxlIBskQiFIGyhCInN0YXRlLWJ1aWxkaW5nIGF0dGFj a3MiIGF0dGFjayBvbiBwZWVycy5bTWFydGluXShyZWxhdGVkIFByb3Bvc2FsIDI2KQ0KTWFydGlu LCBEbyB5b3Ugc3RpbGwgaGF2ZSBjb25jZXJucyBvbiB0aGlzPyBJZiBub2JvZHkgc2hvd3MgdXAs IHdlIHByb3Bvc2UgdG8gY2xvc2UgdGhpcyB0aWNrZXQuDQogDQpUaWNrZXQgIzM6IERpc2N1c3Mg dGhlIE1lbWJlcnNoaXAgY2VydGlmaWNhdGVzIGltcGFjdCBvbiB0aGUgdHJhY2tlchskQiFHGyhC cyB3b3JrbG9hZC5bRmFiaW9dKHJlbGF0ZWQgdG8gUHJvcG9zYWwgMTcrMjApDQogDQpUcmFja2Vy IHByb3RvY29sOg0KVGlja2V0IzQ6IFNwZWNpZnkgdGhlIEZJTkQgdXNlIGNhc2UgYW5kIHJlZHVj ZSB0aGUgb3ZlcmhlYWQgdG8gdGhlIHRyYWNrZXIuW01hcnRpbixZdW5mZWkbJEIhJBsoQkZhYmlv GyRCISQbKEJSaWNoYXJkb10NClRpY2tldCM1OiBEaXNjdXNzIGNvbmNyZXRlIHVzZSBjYXNlcyBv ZiBhZGRpdGlvbmFsIG1lc3NhZ2VzIGlmIHRoZXJlIGFyZShlLmcuLHJlY29ubmVjdCBhbmQgcmVq b2luKSAsIGFuZCBjb25jbHVkZSB0aGUgYmFzaWMgbWVzc2FnZXMgYW5kIG9wdGlvbmFsIG9uZXMg aW4gdHJhY2tlciBwcm90b2NvbC4gW01hcmssIEZhYmlvXQ0KIFdlIHByb3Bvc2UgdG8gdGhlIHRy YWNrZXIgcHJvdG9jb2wgYXV0aG9ycyB0byBhZGRyZXNzIHRoZWlyIHRpY2tldHMgd2l0aCBhIHNw bGl0dGluZyBvZiB0aGVpciBwcm9wb3NhbDoNCi4gYmFzZSBzcGVjDQouIGFkZGl0aW9uYWwgb3B0 aW9ucy4NCiANClN1cnZleQ0KVGlja2V0IzY6IENhbGwgZm9yIHJldmlld2VycyBmb3Igc3VydmV5 IGRyYWZ0LCBhbmQgbWF5YmUgUDJQIHN0cmVhbWluZyBwcm92aWRlcnMbJEIhRxsoQiBjb250cmli dXRpb24gb24gdXBkYXRpbmcgdGhlIGRyYWZ0LiAgIA0KIA0KDQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart685314100282_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-2022-jp"
Hi Fabio,
    Ticket #2 was what Martin proposed in Paris meetin= g.=20 Martin= , Do you=20 still have concerns on this?
 = ;
BR
Yunfei
 
zhangyunfei
 
Date: 2012-05-14 20:04
To: zhangyunfei; ppsp
Subject: RE: [ppsp] tickets for IETF 83

Hi,

Somme=20 comments:

Ticket=20 #1 (chunk addressing mechanism). See my email send today.

Ticket=20 #2. I can=1B$B!G=1B(Bt remember what this was about. :-)=

Ticket=20 #3 (secure PEX): I think that we can stick to a simple PEX mechanism that = can be=20 augmented by an optional secure algorithm. In addition to the solution pro= posed=20 by Arno, there is a simple mechanism described by Jesi et al.=20 [1].

Ticket=20 #4 (FIND use case). I don=1B$B!G=1B(Bt recall exactly the details of this = issue. If it=1B$B!G=1B(Bs=20 only motivating a request to the tracker to find peers subject to attribut= e=20 constraints, then finding peers with a similar upload capacity (to speed u= p the=20 discovery phase) is already a good motivation.

Ticket=20 #5 (additional messages). I think the proponents of these messages should=20 describe the use cases where these messages can be useful.

Cheers,

Fabio

[1]=20 G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. In Comput= er=20 Networks, 2010.

 

From:= =20 ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of=20 zhangyunfei
Sent: jeudi 3 mai 2012 10:13
To:=20 ppsp
Subject: [ppsp] tickets for IETF=20 83

 

Hi all,=

  &n= bsp;=20 I have summarized an initial tickets list&nb= sp;for IETF 83 meeting.=20 Please review it and actions on these tickets are expected. Thanks.=

 

BR

Yunfei=20 &Stefano

--------------= --------------------------------------------------------------------------= -------------------

Peer=20 protocol:

Ticket #1= =1B$B!'=1B(B= Post and discu= ss the=20 alternative proposal besides MHT in peer protocol (Proposal 10+13), list=20 intervals (Tradeoff among complexity / overhead / efficiency / implementat= ion)=20 and check gaps. [Martin=1B$B!$=1B(B= Yunfei, Fabio= ,=20 Lichun]

This ticket is= partly=20 solved. Simple nature number addressing and ranged expression on chunk=20 availability. The analysis and comparison is ongoing. I'd suggest to = have a=20 deadline for the resolution time after discussing with Stefano, i.e.,= =20  May=20 26th from=20 now on to make the decision in the WG level.

 

Ticket #2= =1B$B!'=1B(B= Discuss the po= ssible=20 =1B$B!H=1B(B"state-building attacks" attack on=20 peers.[Martin](related Proposal 26)

Martin, Do you= still=20 have concerns on this? If nobody shows up, we propose to close this=20 ticket.

 

Ticket #3: Discuss the=20 Membership certificates impact on the tracker=1B$B!G=1B(Bs=20 workload.[Fabio](related to Proposal 17+20)

 

Tracker=20 protocol:

Ticket#4:= Specify the F= IND use=20 case and reduce the overhead to the tracker.[Martin,Yunfei=1B$B!$=1B(B= Fabio=1B$B!$=1B(B= Richardo]

Ticket#5:= Discuss concr= ete use=20 cases of additional messages if there are(e.g.,reconnect and rejoin) , and= =20 conclude the basic messages and optional ones in tracker protocol. [Mark,=20 Fabio]

 We=20 propose to the tracker protocol authors to&n= bsp;address their tickets with a splitting o= f their proposal:

. base spec

. additional options.

 

Survey<= SPAN=20 style=3D"COLOR: black">

Ticket#6:=20 Call for reviewers for survey draft, and maybe P2P streaming providers=1B$= B!G=1B(B=20 contribution on updating the draft.   

 

zhangyunfei

------=_001_NextPart685314100282_=------ From zhangyunfei@chinamobile.com Mon May 14 20:10:48 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 1E66B21F8657 for ; Mon, 14 May 2012 20:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.738 X-Spam-Level: X-Spam-Status: No, score=-95.738 tagged_above=-999 required=5 tests=[AWL=2.885, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T9kan-ff9ga for ; Mon, 14 May 2012 20:10:44 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0A04A21F8655 for ; Mon, 14 May 2012 20:10:44 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 15CD3E6E9; Tue, 15 May 2012 11:10:42 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 52918E6E4; Tue, 15 May 2012 11:10:41 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051511103923-7527 ; Tue, 15 May 2012 11:10:39 +0800 Date: Tue, 15 May 2012 11:10:36 +0800 From: zhangyunfei To: "Picconi Fabio" , ppsp , "'Rui Cruz'" , "Yingjie Gu(yingjie)" References: <2012050316123830359558@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051511103610737239@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 11:10:39, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 11:10:41, Serialize complete at 2012-05-15 11:10:41 Content-Type: multipart/alternative; boundary="----=_001_NextPart420237135354_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003 X-TM-AS-Result: No--37.753-7.0-31-10 X-imss-scan-details: No--37.753-7.0-31-10;No--37.753-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] tickets for IETF 83 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, 15 May 2012 03:10:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart420237135354_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-2022-jp" SGkgUnVpIGFuZCBZaW5namllLA0KICAgIFdvdWxkIHlvdSBwbGVhc2UgY29uZmlybSB0aGUgdGlj a2V0ICM0IGZvciBQYXJpcyBtZWV0aW5nPw0KICAgICBGb3IgdGlja2V0ICM1LCBJIGFtIGZpbmUg d2l0aCBGYWJpbydzIHByb3Bvc2FsLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5neXVuZmVp DQoNCkZyb206IFBpY2NvbmkgRmFiaW8NCkRhdGU6IDIwMTItMDUtMTQgMjA6MDQNClRvOiB6aGFu Z3l1bmZlaTsgcHBzcA0KU3ViamVjdDogUkU6IFtwcHNwXSB0aWNrZXRzIGZvciBJRVRGIDgzDQpI aSwNClNvbW1lIGNvbW1lbnRzOg0KVGlja2V0ICMxIChjaHVuayBhZGRyZXNzaW5nIG1lY2hhbmlz bSkuIFNlZSBteSBlbWFpbCBzZW5kIHRvZGF5Lg0KVGlja2V0ICMyLiBJIGNhbhskQiFHGyhCdCBy ZW1lbWJlciB3aGF0IHRoaXMgd2FzIGFib3V0LiA6LSkNClRpY2tldCAjMyAoc2VjdXJlIFBFWCk6 IEkgdGhpbmsgdGhhdCB3ZSBjYW4gc3RpY2sgdG8gYSBzaW1wbGUgUEVYIG1lY2hhbmlzbSB0aGF0 IGNhbiBiZSBhdWdtZW50ZWQgYnkgYW4gb3B0aW9uYWwgc2VjdXJlIGFsZ29yaXRobS4gSW4gYWRk aXRpb24gdG8gdGhlIHNvbHV0aW9uIHByb3Bvc2VkIGJ5IEFybm8sIHRoZXJlIGlzIGEgc2ltcGxl IG1lY2hhbmlzbSBkZXNjcmliZWQgYnkgSmVzaSBldCBhbC4gWzFdLg0KVGlja2V0ICM0IChGSU5E IHVzZSBjYXNlKS4gSSBkb24bJEIhRxsoQnQgcmVjYWxsIGV4YWN0bHkgdGhlIGRldGFpbHMgb2Yg dGhpcyBpc3N1ZS4gSWYgaXQbJEIhRxsoQnMgb25seSBtb3RpdmF0aW5nIGEgcmVxdWVzdCB0byB0 aGUgdHJhY2tlciB0byBmaW5kIHBlZXJzIHN1YmplY3QgdG8gYXR0cmlidXRlIGNvbnN0cmFpbnRz LCB0aGVuIGZpbmRpbmcgcGVlcnMgd2l0aCBhIHNpbWlsYXIgdXBsb2FkIGNhcGFjaXR5ICh0byBz cGVlZCB1cCB0aGUgZGlzY292ZXJ5IHBoYXNlKSBpcyBhbHJlYWR5IGEgZ29vZCBtb3RpdmF0aW9u Lg0KVGlja2V0ICM1IChhZGRpdGlvbmFsIG1lc3NhZ2VzKS4gSSB0aGluayB0aGUgcHJvcG9uZW50 cyBvZiB0aGVzZSBtZXNzYWdlcyBzaG91bGQgZGVzY3JpYmUgdGhlIHVzZSBjYXNlcyB3aGVyZSB0 aGVzZSBtZXNzYWdlcyBjYW4gYmUgdXNlZnVsLg0KQ2hlZXJzLA0KRmFiaW8NClsxXSBHLlAuIEpl c2ksIEEuIE1vbnRyZXNvciwgYW5kIE0uIHZhbiBTdGVlbi4gU2VjdXJlIFBlZXIgU2FtcGxpbmcu IEluIENvbXB1dGVyIE5ldHdvcmtzLCAyMDEwLg0KIA0KRnJvbTogcHBzcC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygemhhbmd5dW5m ZWkNClNlbnQ6IGpldWRpIDMgbWFpIDIwMTIgMTA6MTMNClRvOiBwcHNwDQpTdWJqZWN0OiBbcHBz cF0gdGlja2V0cyBmb3IgSUVURiA4Mw0KIA0KSGkgYWxsLA0KICAgIEkgaGF2ZSBzdW1tYXJpemVk IGFuIGluaXRpYWwgdGlja2V0cyBsaXN0IGZvciBJRVRGIDgzIG1lZXRpbmcuIFBsZWFzZSByZXZp ZXcgaXQgYW5kIGFjdGlvbnMgb24gdGhlc2UgdGlja2V0cyBhcmUgZXhwZWN0ZWQuIFRoYW5rcy4N CiANCkJSDQpZdW5mZWkgJlN0ZWZhbm8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpQZWVyIHByb3RvY29sOg0KVGlja2V0ICMxGyRCIScbKEJQb3N0 IGFuZCBkaXNjdXNzIHRoZSBhbHRlcm5hdGl2ZSBwcm9wb3NhbCBiZXNpZGVzIE1IVCBpbiBwZWVy IHByb3RvY29sIChQcm9wb3NhbCAxMCsxMyksIGxpc3QgaW50ZXJ2YWxzIChUcmFkZW9mZiBhbW9u ZyBjb21wbGV4aXR5IC8gb3ZlcmhlYWQgLyBlZmZpY2llbmN5IC8gaW1wbGVtZW50YXRpb24pIGFu ZCBjaGVjayBnYXBzLiBbTWFydGluGyRCISQbKEIgWXVuZmVpLCBGYWJpbywgTGljaHVuXQ0KVGhp cyB0aWNrZXQgaXMgcGFydGx5IHNvbHZlZC4gU2ltcGxlIG5hdHVyZSBudW1iZXIgYWRkcmVzc2lu ZyBhbmQgcmFuZ2VkIGV4cHJlc3Npb24gb24gY2h1bmsgYXZhaWxhYmlsaXR5LiBUaGUgYW5hbHlz aXMgYW5kIGNvbXBhcmlzb24gaXMgb25nb2luZy4gSSdkIHN1Z2dlc3QgdG8gaGF2ZSBhIGRlYWRs aW5lIGZvciB0aGUgcmVzb2x1dGlvbiB0aW1lIGFmdGVyIGRpc2N1c3Npbmcgd2l0aCBTdGVmYW5v LCBpLmUuLCAgTWF5IDI2dGggZnJvbSBub3cgb24gdG8gbWFrZSB0aGUgZGVjaXNpb24gaW4gdGhl IFdHIGxldmVsLg0KIA0KVGlja2V0ICMyGyRCIScbKEJEaXNjdXNzIHRoZSBwb3NzaWJsZSAbJEIh SBsoQiJzdGF0ZS1idWlsZGluZyBhdHRhY2tzIiBhdHRhY2sgb24gcGVlcnMuW01hcnRpbl0ocmVs YXRlZCBQcm9wb3NhbCAyNikNCk1hcnRpbiwgRG8geW91IHN0aWxsIGhhdmUgY29uY2VybnMgb24g dGhpcz8gSWYgbm9ib2R5IHNob3dzIHVwLCB3ZSBwcm9wb3NlIHRvIGNsb3NlIHRoaXMgdGlja2V0 Lg0KIA0KVGlja2V0ICMzOiBEaXNjdXNzIHRoZSBNZW1iZXJzaGlwIGNlcnRpZmljYXRlcyBpbXBh Y3Qgb24gdGhlIHRyYWNrZXIbJEIhRxsoQnMgd29ya2xvYWQuW0ZhYmlvXShyZWxhdGVkIHRvIFBy b3Bvc2FsIDE3KzIwKQ0KIA0KVHJhY2tlciBwcm90b2NvbDoNClRpY2tldCM0OiBTcGVjaWZ5IHRo ZSBGSU5EIHVzZSBjYXNlIGFuZCByZWR1Y2UgdGhlIG92ZXJoZWFkIHRvIHRoZSB0cmFja2VyLltN YXJ0aW4sWXVuZmVpGyRCISQbKEJGYWJpbxskQiEkGyhCUmljaGFyZG9dDQpUaWNrZXQjNTogRGlz Y3VzcyBjb25jcmV0ZSB1c2UgY2FzZXMgb2YgYWRkaXRpb25hbCBtZXNzYWdlcyBpZiB0aGVyZSBh cmUoZS5nLixyZWNvbm5lY3QgYW5kIHJlam9pbikgLCBhbmQgY29uY2x1ZGUgdGhlIGJhc2ljIG1l c3NhZ2VzIGFuZCBvcHRpb25hbCBvbmVzIGluIHRyYWNrZXIgcHJvdG9jb2wuIFtNYXJrLCBGYWJp b10NCiBXZSBwcm9wb3NlIHRvIHRoZSB0cmFja2VyIHByb3RvY29sIGF1dGhvcnMgdG8gYWRkcmVz cyB0aGVpciB0aWNrZXRzIHdpdGggYSBzcGxpdHRpbmcgb2YgdGhlaXIgcHJvcG9zYWw6DQouIGJh c2Ugc3BlYw0KLiBhZGRpdGlvbmFsIG9wdGlvbnMuDQogDQpTdXJ2ZXkNClRpY2tldCM2OiBDYWxs IGZvciByZXZpZXdlcnMgZm9yIHN1cnZleSBkcmFmdCwgYW5kIG1heWJlIFAyUCBzdHJlYW1pbmcg cHJvdmlkZXJzGyRCIUcbKEIgY29udHJpYnV0aW9uIG9uIHVwZGF0aW5nIHRoZSBkcmFmdC4gICAN CiANCg0KDQoNCnpoYW5neXVuZmVp ------=_001_NextPart420237135354_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-2022-jp"
Hi Rui and Yingjie,
    Would you please confirm the ticket #4 for Pa= ris=20 meeting?
     For ticket #5, I am fine with Fabio's=20 proposal.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-05-14 20:04
To: zhangyunfei; ppsp
Subject: RE: [ppsp] tickets for IETF 83

Hi,

Somme=20 comments:

Ticket=20 #1 (chunk addressing mechanism). See my email send today.

Ticket=20 #2. I can=1B$B!G=1B(Bt remember what this was about. :-)=

Ticket=20 #3 (secure PEX): I think that we can stick to a simple PEX mechanism that = can be=20 augmented by an optional secure algorithm. In addition to the solution pro= posed=20 by Arno, there is a simple mechanism described by Jesi et al.=20 [1].

Ticket=20 #4 (FIND use case). I don=1B$B!G=1B(Bt recall exactly the details of this = issue. If it=1B$B!G=1B(Bs=20 only motivating a request to the tracker to find peers subject to attribut= e=20 constraints, then finding peers with a similar upload capacity (to speed u= p the=20 discovery phase) is already a good motivation.

Ticket=20 #5 (additional messages). I think the proponents of these messages should=20 describe the use cases where these messages can be useful.

Cheers,

Fabio

[1]=20 G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. In Comput= er=20 Networks, 2010.

 

From:= =20 ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of=20 zhangyunfei
Sent: jeudi 3 mai 2012 10:13
To:=20 ppsp
Subject: [ppsp] tickets for IETF=20 83

 

Hi all,=

  &n= bsp;=20 I have summarized an initial tickets list&nb= sp;for IETF 83 meeting.=20 Please review it and actions on these tickets are expected. Thanks.=

 

BR

Yunfei=20 &Stefano

--------------= --------------------------------------------------------------------------= -------------------

Peer=20 protocol:

Ticket #1= =1B$B!'=1B(B= Post and discu= ss the=20 alternative proposal besides MHT in peer protocol (Proposal 10+13), list=20 intervals (Tradeoff among complexity / overhead / efficiency / implementat= ion)=20 and check gaps. [Martin=1B$B!$=1B(B= Yunfei, Fabio= ,=20 Lichun]

This ticket is= partly=20 solved. Simple nature number addressing and ranged expression on chunk=20 availability. The analysis and comparison is ongoing. I'd suggest to = have a=20 deadline for the resolution time after discussing with Stefano, i.e.,= =20  May=20 26th from=20 now on to make the decision in the WG level.

 

Ticket #2= =1B$B!'=1B(B= Discuss the po= ssible=20 =1B$B!H=1B(B"state-building attacks" attack on=20 peers.[Martin](related Proposal 26)

Martin, Do you= still=20 have concerns on this? If nobody shows up, we propose to close this=20 ticket.

 

Ticket #3: Discuss the=20 Membership certificates impact on the tracker=1B$B!G=1B(Bs=20 workload.[Fabio](related to Proposal 17+20)

 

Tracker=20 protocol:

Ticket#4:= Specify the F= IND use=20 case and reduce the overhead to the tracker.[Martin,Yunfei=1B$B!$=1B(B= Fabio=1B$B!$=1B(B= Richardo]

Ticket#5:= Discuss concr= ete use=20 cases of additional messages if there are(e.g.,reconnect and rejoin) , and= =20 conclude the basic messages and optional ones in tracker protocol. [Mark,=20 Fabio]

 We=20 propose to the tracker protocol authors to&n= bsp;address their tickets with a splitting o= f their proposal:

. base spec

. additional options.

 

Survey<= SPAN=20 style=3D"COLOR: black">

Ticket#6:=20 Call for reviewers for survey draft, and maybe P2P streaming providers=1B$= B!G=1B(B=20 contribution on updating the draft.   

 

zhangyunfei

------=_001_NextPart420237135354_=------ From zhangyunfei@chinamobile.com Mon May 14 20:13:40 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 6052821F872D for ; Mon, 14 May 2012 20:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.918 X-Spam-Level: X-Spam-Status: No, score=-95.918 tagged_above=-999 required=5 tests=[AWL=2.705, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gci-UqJ6GnyJ for ; Mon, 14 May 2012 20:13:39 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7C42521F865C for ; Mon, 14 May 2012 20:13:39 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 47D06E682; Tue, 15 May 2012 11:13:38 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 3E67BE57E; Tue, 15 May 2012 11:13:38 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051511133575-7647 ; Tue, 15 May 2012 11:13:35 +0800 Date: Tue, 15 May 2012 11:13:32 +0800 From: zhangyunfei To: "arno@cs.vu.nl" , ppsp , "Picconi Fabio" References: <2012050316123830359558@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com>, <4FB0FC97.7020601@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051511133262864742@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 11:13:35, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-15 11:13:38, Serialize complete at 2012-05-15 11:13:38 Content-Type: multipart/alternative; boundary="----=_001_NextPart430811314388_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18906.003 X-TM-AS-Result: No--18.666-7.0-31-10 X-imss-scan-details: No--18.666-7.0-31-10;No--18.666-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] tickets for IETF 83 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, 15 May 2012 03:13:40 -0000 This is a multi-part message in MIME format. ------=_001_NextPart430811314388_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQXJub6OsDQogICBJIGd1ZXNzIEZhYmlvJ3MgY29uY2VybiBpcyBtYWlubHkgb24gdGhlIGV4 dHJhIGJ1cmRlbiBldmFsdWF0aW9uIG9uIHRoZSB0cmFja2VyIGJ5IHRoZSBzZWN1cml0eSBtZWNo YW5pc20gaW4gUEVYLg0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJha2tlcg0K RGF0ZTogMjAxMi0wNS0xNCAyMDozNw0KVG86IHBwc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb cHBzcF0gdGlja2V0cyBmb3IgSUVURiA4Mw0KSGkgRmFiaW8gYW5kIGFsbA0KDQpPbiAxNC8wNS8y MDEyIDE0OjA0LCBQaWNjb25pIEZhYmlvIHdyb3RlOg0KPg0KPiBUaWNrZXQgIzMgKHNlY3VyZSBQ RVgpOiBJIHRoaW5rIHRoYXQgd2UgY2FuIHN0aWNrIHRvIGEgc2ltcGxlIFBFWA0KPiBtZWNoYW5p c20gdGhhdCBjYW4gYmUgYXVnbWVudGVkIGJ5IGFuIG9wdGlvbmFsIHNlY3VyZSBhbGdvcml0aG0u IEluDQo+IGFkZGl0aW9uIHRvIHRoZSBzb2x1dGlvbiBwcm9wb3NlZCBieSBBcm5vLCB0aGVyZSBp cyBhIHNpbXBsZSBtZWNoYW5pc20NCj4gZGVzY3JpYmVkIGJ5IEplc2kgZXQgYWwuIFsxXS4NCj4N Cg0KSU1ITywgbGVhdmluZyBQRVggdW5zZWN1cmVkIHdpbGwgZ2V0IHVzIGNvbW1lbnRzIGZyb20g dGhlIElFU0cuIE15IA0KcHJvcG9zYWwgaXMgYWN0dWFsbHkgY29tcGF0aWJsZSB3aXRoIEplc2ks IE1vbnRyZXNvciwgdmFuIFN0ZWVuIChNYWFydGVuIA0KdmFuIFN0ZWVuIGlzIG15IGJvc3MpLiBN eSBtZW1iZXJzaGlwIGNlcnRpZmljYXRlcyBjb3JyZXNwb25kIHRvIHRoZWlyIA0Kc2lnbmVkIG5v ZGUgZGVzY3JpcHRvcnMuIFRoaXMgbWVjaGFuaXNtIGFsb25lIHdpbGwgcHJldmVudCB0aGUgYWRk cmVzc2VzIA0Kb2YgaW5ub2NlbnQgaG9zdHMgYmVpbmcgc3ByZWFkLiBJIGFkZCBzb21lIGV4dHJh IHNlY3VyaXR5IGJ5IGV4cGxvaXRpbmcgDQp0aGUgY2VudHJhbCB0cmFja2VyLiBUaGV5IGdvIGZ1 bGx5IGRlY2VudHJhbGl6ZWQgYnkgcHJvYmluZyB0aGUgZ3JhcGggDQpmb3IgbWFsaWNpb3VzIHN0 cnVjdHVyZXMuDQoNCkNVLA0KICAgICBBcm5vDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA== ------=_001_NextPart430811314388_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Arno=A3=AC
   I guess Fabio's concern is mainly on the extra burden=20 evaluation on the tracker by the security mechanism in PEX.
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-05-14 20:37
To: ppsp@ietf.org
Subject: Re: [ppsp] tickets for IETF 83
Hi Fabio and all
 
On 14/05/2012 14:04, Picconi Fabio wrote:
>
> Ticket #3 (secure PEX): I think&nb= sp;that we can stick to a simple PEX
> mechanism that can be augmented by=  an optional secure algorithm. In
> addition to the solution proposed = by Arno, there is a simple mechanism
> described by Jesi et al. [1].
>
 
IMHO, leaving PEX unsecured will get us=  comments from the IESG. My 
proposal is actually compatible with Jesi,&n= bsp;Montresor, van Steen (Maarten 
van Steen is my boss). My membership&nb= sp;certificates correspond to their 
signed node descriptors. This mechanism alon= e will prevent the addresses 
of innocent hosts being spread. I add&n= bsp;some extra security by exploiting 
the central tracker. They go fully dece= ntralized by probing the graph 
for malicious structures.
 
CU,
     Arno
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart430811314388_=------ From a.bakker@vu.nl Tue May 15 00:54:03 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 86F9421F893C for ; Tue, 15 May 2012 00:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=3.364, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvGIW8JrZgIN for ; Tue, 15 May 2012 00:54:03 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 535A821F8934 for ; Tue, 15 May 2012 00:54:01 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 15 May 2012 09:54:04 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 15 May 2012 09:53:59 +0200 Message-ID: <4FB20BD5.6010607@cs.vu.nl> Date: Tue, 15 May 2012 09:55:01 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Picconi Fabio References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl> <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> In-Reply-To: <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 07:54:03 -0000 Hi Fabio and all On 14/05/2012 17:52, Picconi Fabio wrote: > > Taking W=30 seconds and 3 chunks per second, 4 bytes per integer, and > 1 buffer map per second to 10 neighbors, range list requires ~ 30 > kbps in the worst case vs. ~ 15 kbps for bins. For a 1 Mbps stream, > that's a 3% overhead instead of 1.5%, which I don't think is that big > a deal. > IMHO, the calculation should be somewhat different. It now assumes we send the complete 30 second map every second. I'd say it is more likely that we download at approx. the bitrate so we have only 1 seconds worth of updates to the map to send. I.e. 3 chunks in your example. This means less overhead. With UDP as a transport, chunk size is preferably 1K to keep the impact of the loss of a single IP packet low (on Ethernet). Then 3 chunks per second should be 100 chunks per second for 1 Mbps, implying we send either 800 bytes (2 ints per range) or 400 bytes (1 bin) as overhead, worst case. For 10 neighbours this means 64 and 32 kbps, or 6% and 3% respectively. > Now, two things: 1) an optimized implementation of range lists would > encode single-element ranges with a single integer, so the overhead > would be identical to that of bins (i.e., 1.5%); 2) we're talking > about the worst case which is extremely unlikely to happen... it > would be interesting to do the average case analysis for the > [P+1,P+W] interval. > As argued before, I assume data will be requested in blocks of chunks, in particular on UDP with 1K chunks, which are a power of 2, e.g. 32K. We can align these requests on power-2 boundaries such that we need just 1 bin to address them. With ranges we always need 2 ints, as we're denoting a block of chunks. With this block assumption, in the worst case, an update is (100K/block size) ranges. So e.g. 3 ranges for 32 K, taking either 2 or 1 int to encode, and thus implying 2 kbps and 1 kbps for 10 neighbours, or 0.2 and 0.1% overhead. Less for larger block sizes. In conclusion, if we send map updates instead of the full map, the absolute overhead of pushing chunk availability is low. Relative overhead can still be 100% and bins give a prettier one-unit design ;o) CU, Arno From rui.cruz@ieee-pt.org Tue May 15 03:59: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 2A17121F8848 for ; Tue, 15 May 2012 03:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEcYvvarNKAT for ; Tue, 15 May 2012 03:59:53 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C58421F883B for ; Tue, 15 May 2012 03:59:52 -0700 (PDT) Received: by eaaq13 with SMTP id q13so666656eaa.31 for ; Tue, 15 May 2012 03:59:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:message-id:references:to:x-mailer :x-gm-message-state; bh=JBbIlouaNkszgh8B4QuJPsAgs5vPTNiYs3YOoFDKqCA=; b=CEeVZzEFoJ2ogGpvtwk36OJ2b5C1HTFjFauTyywYWXu9x0A6Ktdi2eFdcLrNZvIm2i ZVDcBWkdz3XuOLUSEmr1Vp0VEHDh3XZKSZXZv7HlLwqOJsgJVHWDNza2j6y8yf0CaZWX SVMGwwuDBjzKDSpU3cYHN3emYCXTDQn/5FHKpg5UMK/7YMQ2uleT8jD9W6u41MUpJ1xL xMa93MiL9QzfdG3l7B6Zrbn0kqAEeVVgmnruGPdHMcFljyvca/ni5wIKTguaEpNEPcoi eNNxBctb1hjqvp9cGJbN8uQUKSK709mThwCdGlg7w939/IHBzlrj0+EYhRhz47zqMGZf SsQw== Received: by 10.14.95.138 with SMTP id p10mr344179eef.110.1337079591258; Tue, 15 May 2012 03:59:51 -0700 (PDT) Received: from airoso.lan ([89.180.107.80]) by mx.google.com with ESMTPS id n52sm104917034eeh.9.2012.05.15.03.59.47 (version=SSLv3 cipher=OTHER); Tue, 15 May 2012 03:59:49 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_1CB09E91-8367-405D-8653-1F0D6F0D51D6" From: Rui Cruz X-Priority: 3 (Normal) In-Reply-To: <2012051511103610737239@chinamobile.com> Date: Tue, 15 May 2012 11:59:48 +0100 Message-Id: <731E43BD-66FD-4306-88FA-A65518810FB4@ieee.org> References: <2012050316123830359558@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> <2012051511103610737239@chinamobile.com> To: ppsp X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk7dDsR+oT5FJ8tlG2dsT9hFX5gr2Xy5iSdrESdGKA8OWmoQg4aIuz6A0rQQBgimKG6zE3h Cc: Rui Cruz Subject: Re: [ppsp] tickets for IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 10:59:54 -0000 --Apple-Mail=_1CB09E91-8367-405D-8653-1F0D6F0D51D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-2022-jp Hi, On Ticket #4: The FIND use case can perfectly be seen as Fabio = described, i.e., "to find peers subject to attribute constraints" in = order to speed up discovery, i.e., may be used in special situations = only, therefore, the overhead to the tracker can be considered minimal. On Ticket #5: The tracker protocol proposal is being split in a base = specification and extensions. We do not see the need for "additional = messages e.g.,reconnect and rejoin)" as this type of "action" is = perfectly solved with the already proposed messages. This is the case = of the new semantic for the CONNECT message with implicit JOINs which = behaves as a re-CONNECT with re-JOINs. We would appreciate an advise from the chairs on splitting the tracker = protocol proposal in a base specification and extensions. Should it be = done with two different draft documents or with a single document where = the extensions are clearly separate to an Annex?? Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 15/05/2012, at 04:10, zhangyunfei wrote: > Hi Rui and Yingjie, > Would you please confirm the ticket #4 for Paris meeting? > For ticket #5, I am fine with Fabio's proposal. > =20 > BR > Yunfei > =20 > zhangyunfei > =20 > From: Picconi Fabio > Date: 2012-05-14 20:04 > To: zhangyunfei; ppsp > Subject: RE: [ppsp] tickets for IETF 83 > Hi, > Somme comments: > Ticket #1 (chunk addressing mechanism). See my email send today. > Ticket #2. I can=1B$B!G=1B(Bt remember what this was about. :-) > Ticket #3 (secure PEX): I think that we can stick to a simple PEX = mechanism that can be augmented by an optional secure algorithm. In = addition to the solution proposed by Arno, there is a simple mechanism = described by Jesi et al. [1]. > Ticket #4 (FIND use case). I don=1B$B!G=1B(Bt recall exactly the = details of this issue. If it=1B$B!G=1B(Bs only motivating a request to = the tracker to find peers subject to attribute constraints, then finding = peers with a similar upload capacity (to speed up the discovery phase) = is already a good motivation. > Ticket #5 (additional messages). I think the proponents of these = messages should describe the use cases where these messages can be = useful. > Cheers, > Fabio > [1] G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. = In Computer Networks, 2010. > =20 > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf = Of zhangyunfei > Sent: jeudi 3 mai 2012 10:13 > To: ppsp > Subject: [ppsp] tickets for IETF 83 > =20 > Hi all, > I have summarized an initial tickets list for IETF 83 meeting. = Please review it and actions on these tickets are expected. Thanks. > =20 > BR > Yunfei &Stefano > = --------------------------------------------------------------------------= --------------------------------- > Peer protocol: > Ticket #1=1B$B!'=1B(BPost and discuss the alternative proposal besides = MHT in peer protocol (Proposal 10+13), list intervals (Tradeoff among = complexity / overhead / efficiency / implementation) and check gaps. = [Martin=1B$B!$=1B(BYunfei, Fabio, Lichun] > This ticket is partly solved. Simple nature number addressing and = ranged expression on chunk availability. The analysis and comparison is = ongoing. I'd suggest to have a deadline for the resolution time after = discussing with Stefano, i.e., May 26th from now on to make the = decision in the WG level. > =20 > Ticket #2=1B$B!'=1B(BDiscuss the possible =1B$B!H=1B(B"state-building = attacks" attack on peers.[Martin](related Proposal 26) > Martin, Do you still have concerns on this? If nobody shows up, we = propose to close this ticket. > =20 > Ticket #3: Discuss the Membership certificates impact on the = tracker=1B$B!G=1B(Bs workload.[Fabio](related to Proposal 17+20) > =20 > Tracker protocol: > Ticket#4: Specify the FIND use case and reduce the overhead to the = tracker.[Martin,Yunfei=1B$B!$=1B(BFabio=1B$B!$=1B(BRichardo] > Ticket#5: Discuss concrete use cases of additional messages if there = are(e.g.,reconnect and rejoin) , and conclude the basic messages and = optional ones in tracker protocol. [Mark, Fabio] > We propose to the tracker protocol authors to address their tickets = with a splitting of their proposal: > . base spec > . additional options. > =20 > Survey > Ticket#6: Call for reviewers for survey draft, and maybe P2P streaming = providers=1B$B!G=1B(B contribution on updating the draft. =20 > =20 > zhangyunfei > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_1CB09E91-8367-405D-8653-1F0D6F0D51D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-2022-jp Hi,

On Ticket #4: The = FIND use case can perfectly be seen as Fabio described, i.e., "to find peers = subject to attribute constraints" in order to speed up discovery, = i.e., may be used in special situations only, therefore, the overhead to = the tracker can be considered minimal.

On = Ticket #5: The tracker protocol proposal is being split in a = base specification and extensions. We do not see the need = for "additional messages e.g.,reconnect and = rejoin)" as this type of "action" is perfectly solved with the = already proposed messages.  This is the case of the new semantic = for the CONNECT message with implicit JOINs which behaves as a = re-CONNECT with re-JOINs.

We would appreciate = an advise from the chairs on splitting the tracker protocol = proposal in a base = specification and extensions. Should it be = done with two different draft documents or with a single document where = the extensions are clearly separate to an Annex??

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 15/05/2012, at 04:10, zhangyunfei wrote:

Hi = Rui and Yingjie,
    Would you please confirm = the ticket #4 for Paris meeting?
     = For ticket #5, I am fine with Fabio's = proposal.
 
BR
Yunfei
 <= /div>
Date: 2012-05-14 20:04
T= o: zhangyunfei; ppsp
Subject: RE: [ppsp] tickets = for IETF 83
Somme = comments:
Ticket #1 (chunk = addressing mechanism). See my email send = today.
Ticket #2. I = can=1B$B!G=1B(Bt remember what this was about. = :-)
Ticket #3 (secure PEX): I = think that we can stick to a simple PEX mechanism that can be augmented = by an optional secure algorithm. In addition to the solution proposed by = Arno, there is a simple mechanism described by Jesi et al. = [1].
Ticket #4 (FIND use case). I = don=1B$B!G=1B(Bt recall exactly the details of this issue. If = it=1B$B!G=1B(Bs only motivating a request to the tracker to find peers = subject to attribute constraints, then finding peers with a similar = upload capacity (to speed up the discovery phase) is already a good = motivation.
Ticket #5 = (additional messages). I think the proponents of these messages should = describe the use cases where these messages can be = useful.
[1] G.P. Jesi, = A. Montresor, and M. van Steen. Secure Peer Sampling. In Computer = Networks, 2010.
 ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] On Behalf Of zhangyunfei
Sent: jeudi 3 mai 2012 = 10:13
To: ppsp
Subject: [ppsp] tickets for IETF = 83
 
Hi = all,
 BRYunfei &StefanoPeer protocol:Ticket #1=1B$B!'=1B(BPost and = discuss the alternative proposal besides MHT in peer protocol (Proposal = 10+13), list intervals (Tradeoff among complexity / overhead / = efficiency / implementation) and check gaps. [MartinYunfei, Fabio, Lichun]
This ticket is partly solved. Simple nature = number addressing and ranged expression on chunk availability. The = analysis and comparison is ongoing. I'd suggest to have a deadline = for the resolution time after discussing with Stefano, i.e., =  May 26th from now on = to make the decision in the WG level.
Ticket #2=1B$B!'=1B(BDiscuss the = possible =1B$B!H=1B(B"state-building attacks" attack on = peers.[Martin](related Proposal 26)Martin, Do you still have concerns on this? If nobody = shows up, we propose to close this = ticket. Ticket #3: Discuss the Membership = certificates impact on the tracker=1B$B!G=1B(Bs workload.[Fabio](related to = Proposal 17+20) Tracker protocol:Ticket#4: Specify the FIND use case = and reduce the overhead to the tracker.[Martin,YunfeiFabio=1B$B!$=1B(BTicket#5: Discuss concrete use cases = of additional messages if there are(e.g.,reconnect and rejoin) , and = conclude the basic messages and optional ones in tracker protocol. = [Mark, Fabio] We = propose to the tracker protocol authors to&n= bsp;address their tickets with a splitting o= f their proposal:
. base spec
. additional options.
SurveyTicket#6: Call for reviewers for survey draft, and maybe P2P streaming = providers=1B$B!G=1B(B contribution on updating the draft.   
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

= --Apple-Mail=_1CB09E91-8367-405D-8653-1F0D6F0D51D6-- From Fabio.Picconi@technicolor.com Tue May 15 05:47: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 8182B21F8546 for ; Tue, 15 May 2012 05:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=3.951, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1DbhFWh4ebC for ; Tue, 15 May 2012 05:47:35 -0700 (PDT) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id F084121F8549 for ; Tue, 15 May 2012 05:47:29 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKT7JQYXjcNvy1lhZSbIfmn9YW1NpunMvQ@postini.com; Tue, 15 May 2012 05:47:33 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 May 2012 14:45:39 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 15 May 2012 14:45:42 +0200 From: Picconi Fabio To: zhangyunfei , "arno@cs.vu.nl" , ppsp Date: Tue, 15 May 2012 14:45:38 +0200 Thread-Topic: Re: [ppsp] tickets for IETF 83 Thread-Index: Ac0ySLvplJZFbNRaQDaXEPphLMXfdAAT40HQ Message-ID: <320C4182454E96478DC039F2C481987204EB26E73A@MOPESMBX01.eu.thmulti.com> References: <2012050316123830359558@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com>, <4FB0FC97.7020601@cs.vu.nl> <2012051511133262864742@chinamobile.com> In-Reply-To: <2012051511133262864742@chinamobile.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_320C4182454E96478DC039F2C481987204EB26E73AMOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [ppsp] tickets for IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 12:47:36 -0000 --_000_320C4182454E96478DC039F2C481987204EB26E73AMOPESMBX01eut_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Indeed, I don=1B$B!G=1B(Bt think we should impose a security mechanism on t= he base protocol. There are existing systems that perform PEX without any s= ecurity. Even the BitTorrent tracker allows you to spoof somebody and regis= ter them in the swarm. There can be deployments where a secured PEX is not necessary (e.g., within= a company). In my view secure PEX can be left as an option. Fabio From: zhangyunfei [mailto:zhangyunfei@chinamobile.com] Sent: mardi 15 mai 2012 05:14 To: arno@cs.vu.nl; ppsp; Picconi Fabio Subject: Re: Re: [ppsp] tickets for IETF 83 Hi Arno=1B$B!$=1B(B I guess Fabio's concern is mainly on the extra burden evaluation on the = tracker by the security mechanism in PEX. ________________________________ zhangyunfei From: Arno Bakker Date: 2012-05-14 20:37 To: ppsp@ietf.org Subject: Re: [ppsp] tickets for IETF 83 Hi Fabio and all On 14/05/2012 14:04, Picconi Fabio wrote: > > Ticket #3 (secure PEX): I think that we can stick to a simple PEX > mechanism that can be augmented by an optional secure algorithm. In > addition to the solution proposed by Arno, there is a simple mechanism > described by Jesi et al. [1]. > IMHO, leaving PEX unsecured will get us comments from the IESG. My proposal is actually compatible with Jesi, Montresor, van Steen (Maarten van Steen is my boss). My membership certificates correspond to their signed node descriptors. This mechanism alone will prevent the addresses of innocent hosts being spread. I add some extra security by exploiting the central tracker. They go fully decentralized by probing the graph for malicious structures. CU, Arno _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --_000_320C4182454E96478DC039F2C481987204EB26E73AMOPESMBX01eut_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

= Indeed, I don=1B$B!G=1B(Jt think we should impose a security mechanism on t= he base protocol. There are existing systems that perform PEX without any s= ecurity. Even the BitTorrent tracker allows you to spoof somebody and regis= ter them in the swarm.

The= re can be deployments where a secured PEX is not necessary (e.g., within a = company).

In my view secur= e PEX can be left as an option.

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Fabio

 

From: zhangyunfei [mailto:zhangyunfei@chinamobile.com= ]
Sent: mardi 15 mai 2012 05:14
To: arno@cs.vu.nl; pps= p; Picconi Fabio
Subject: Re: Re: [ppsp] tickets for IETF 83=

 

Hi = Arno=1B$B!$=1B(J

=

&nbs= p;  I guess Fabio's concern is mainly on the extra burde= n evaluation on the tracker by the security mechanism in PEX.

 

zhangyunfei

 

Fr= om: A= rno Bakker

<=1B(Jp class=3DMsoNormal st= yle=3D'margin:0cm;margin-bottom:.0001pt;background:#EFEFEF'>Date= : 2012-05-14 20:37

To:<= /b> ppsp@ietf.or= g

Subject:=  Re: [ppsp] tickets for IETF 83=

Hi Fabio and all

 

=

On 14/05/2012 14:04, Picconi = Fabio wrote:

<= /div>

<= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>> 

> Ticket<=1B(Jspan style=3D'font-size:10.5pt;font-family:"Time= s New Roman","serif";color:navy'> #3&nbs= p;(secure PEX): I think=  that we&= nbsp;can stick=  to a&nbs= p;simple PEX

> mechanism&= nbsp;that can&= nbsp;be augmented by an=  optional<=1B(Jspan style=3D'font-size:10.5pt;fon= t-family:"Times New Roman","serif";color:navy'> secure algorithm. In

> addi= tion to t= he solution proposed by <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>Arno, there is a simple mechanism

> described&nbs= p;by Jesi&nbs= p;et al.<=1B(Jspan st= yle=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:navy'>&= nbsp;[1].

> 

 

IMHO, leaving PEX<= /span> unsecured will get us comments from the IESG. My 

proposal = is actually compatible with <=1B(Jspan style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","seri= f";color:navy'>Jesi, Montresor, van Steen (Maarten 

van Steen is my&n= bsp;boss). My&= nbsp;membership certificates= correspond to their 

signed nod= e descriptors. <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>This <=1B(Jspan style=3D'font-size:10.5pt;f= ont-family:"Microsoft YaHei","serif";color:navy'>mechanism&nb= sp;alone will&= nbsp;prevent theaddresses 

of innocenthosts being spread. I<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> add some<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> extra security by exploit= ing 

the central <=1B(Jspan st= yle=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:navy'>t= racker. They go fully decentralized by probing the&nbs= p;graph 

for malicious&nbs= p;structures.

 

CU,

  =    Arno

__________= _____________________________________

ppsp mailing list=

<=1B(Jp class=3DMsoNormal style=3D'mar= gin:0cm;margin-bottom:.0001pt'>https://www.ietf.org/mailman/listinfo/ppsp=

= --_000_320C4182454E96478DC039F2C481987204EB26E73AMOPESMBX01eut_-- From Fabio.Picconi@technicolor.com Tue May 15 06:07:28 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 7A7C621F8535 for ; Tue, 15 May 2012 06:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=2.964, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38Uar7Rk88bN for ; Tue, 15 May 2012 06:07:27 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id DF55721F852E for ; Tue, 15 May 2012 06:07:20 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKT7JVCCgrKH79MAXOCz5BsOcKmn3NSGCf@postini.com; Tue, 15 May 2012 06:07:27 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 15 May 2012 15:04:29 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Tue, 15 May 2012 15:04:38 +0200 From: Picconi Fabio To: "arno@cs.vu.nl" Date: Tue, 15 May 2012 15:04:36 +0200 Thread-Topic: Proposal to resolve Issue 10 + 13 Thread-Index: Ac0yb+ZfUb3TbuEwTn+UFq+b9IUB4wAKZP/Q Message-ID: <320C4182454E96478DC039F2C481987204EB26E7D4@MOPESMBX01.eu.thmulti.com> References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl> <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> <4FB20BD5.6010607@cs.vu.nl> In-Reply-To: <4FB20BD5.6010607@cs.vu.nl> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ppsp Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 13:07:28 -0000 I'm not sure I follow you. First, I assumed three chunks per second because there is a paper that sugg= ests that this is a good value [1]. But the actual chunk rate does not chan= ge the calculation (more chunks per seconds means both more bins and more r= anges). Second, if you use ranges, sending an update to inform the reception of an = entire 32K block (i.e., 32 1K chunks) takes two integers with range lists, = or one integer using bins. If you have three blocks per second, that means = 6 integers per second per neighbor, instead of 3 integers per second per ne= ighbor. In both cases the overhead is negligible. In the absence of an average case analysis (i.e., where the buffer contains= lots of holes) showing that bins are better than range lists, and given th= e negligible overhead of both solutions in the worst and best case, I would= go for the simpler solution, i.e., range lists. Fabio [1] Size Does Matter (in P2P Live Streaming). N. Hegde, F. Mathieu and D. P= erino. In Algotel'09 and also Inria Technical report #7032, 2009. > -----Original Message----- > From: Arno Bakker [mailto:arno@cs.vu.nl] > Sent: mardi 15 mai 2012 09:55 > To: Picconi Fabio > Cc: zhangyunfei; ppsp > Subject: Re: Proposal to resolve Issue 10 + 13 >=20 > Hi Fabio and all >=20 > On 14/05/2012 17:52, Picconi Fabio wrote: > > > > Taking W=3D30 seconds and 3 chunks per second, 4 bytes per integer, and > > 1 buffer map per second to 10 neighbors, range list requires ~ 30 > kbps > > in the worst case vs. ~ 15 kbps for bins. For a 1 Mbps stream, that's > > a 3% overhead instead of 1.5%, which I don't think is that big a > deal. > > >=20 > IMHO, the calculation should be somewhat different. It now assumes we > send the complete 30 second map every second. I'd say it is more likely > that we download at approx. the bitrate so we have only 1 seconds worth > of updates to the map to send. I.e. 3 chunks in your example. This > means less overhead. >=20 > With UDP as a transport, chunk size is preferably 1K to keep the impact > of the loss of a single IP packet low (on Ethernet). Then 3 chunks per > second should be 100 chunks per second for 1 Mbps, implying we send > either 800 bytes (2 ints per range) or 400 bytes (1 bin) as overhead, > worst case. For 10 neighbours this means 64 and 32 kbps, or 6% and 3% > respectively. >=20 >=20 > > Now, two things: 1) an optimized implementation of range lists would > > encode single-element ranges with a single integer, so the overhead > > would be identical to that of bins (i.e., 1.5%); 2) we're talking > > about the worst case which is extremely unlikely to happen... it > would > > be interesting to do the average case analysis for the [P+1,P+W] > > interval. > > >=20 > As argued before, I assume data will be requested in blocks of chunks, > in particular on UDP with 1K chunks, which are a power of 2, e.g. 32K. > We can align these requests on power-2 boundaries such that we need > just > 1 bin to address them. With ranges we always need 2 ints, as we're > denoting a block of chunks. >=20 > With this block assumption, in the worst case, an update is (100K/block > size) ranges. So e.g. 3 ranges for 32 K, taking either 2 or 1 int to > encode, and thus implying 2 kbps and 1 kbps for 10 neighbours, or 0.2 > and 0.1% overhead. Less for larger block sizes. >=20 > In conclusion, if we send map updates instead of the full map, the > absolute overhead of pushing chunk availability is low. Relative > overhead can still be 100% and bins give a prettier one-unit design ;o) >=20 > CU, > Arno From zhangyunfei@chinamobile.com Tue May 15 18:41:06 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 1EB3011E80B5 for ; Tue, 15 May 2012 18:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.077 X-Spam-Level: X-Spam-Status: No, score=-96.077 tagged_above=-999 required=5 tests=[AWL=2.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKPm82Iw9ifO for ; Tue, 15 May 2012 18:41:05 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 67F3411E8095 for ; Tue, 15 May 2012 18:41:04 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id D9F52E5DF; Wed, 16 May 2012 09:41:02 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id C12EFE5D9; Wed, 16 May 2012 09:41:02 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051609410032-3966 ; Wed, 16 May 2012 09:41:00 +0800 Date: Wed, 16 May 2012 09:40:56 +0800 From: zhangyunfei To: "'Rui Cruz'" , ppsp References: <2012050316123830359558@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> <2012051511103610737239@chinamobile.com>, <731E43BD-66FD-4306-88FA-A65518810FB4@ieee.org> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201205160940568032028@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-16 09:41:00, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-16 09:41:02, Serialize complete at 2012-05-16 09:41:02 Content-Type: multipart/alternative; boundary="----=_001_NextPart721728647661_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18908.001 X-TM-AS-Result: No--36.723-7.0-31-10 X-imss-scan-details: No--36.723-7.0-31-10;No--36.723-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: 'Rui Cruz' Subject: Re: [ppsp] tickets for IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 01:41:06 -0000 This is a multi-part message in MIME format. ------=_001_NextPart721728647661_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-2022-jp" VGhhbmtzIFJ1aSBmb3IgdGhlIGNsYXJpZmljYXRpb24uIEkgd291bGQgc3VnZ2VzdCB0byBzcGVy YXRlIHRoZSBiYXNlIHNwZWNpZmljYXRpb24gYW5kIHRoZSBleHRlbnNpb25zIHdpdGggdHdvIGRp ZmZlcmVudCBkcmFmdHMgZm9yIHR3byByZWFzb25zOg0KMSkgSXQgd291bGQgYmUgbXVjaCBlYXNp ZXIgdG8gZ2V0IGNvbnNlbnN1cyBvbiB0aGUgYmFzZSBkcmFmdCBzaW5jZSBpdHMgc2NvcGUgaXMg aGlnaGx5IGxpbWl0ZWQuIEluIHRoaXMgd2F5IHRoZSBwcm9ncmVzcyB3aWxsIGJlIGVhcmxpZXIg dG8gYWNoaWV2ZS4NCjIpIFdlIHNlZSBtYW55IHNpbWlsYXIgb3BlcmF0aW9ucyBpbiBJRVRGIGRy YWZ0cyBwcmFjdGljZXMgd2hpY2ggbWF5IGJlIHByb3ZlZCB0byBiZSBhbiBlZmZpY2llbnQgd2F5 IGluIElFVEYgY2lyY2xlLg0KDQpCUg0KWXVuZmVpIA0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpG cm9tOiBSdWkgQ3J1eg0KRGF0ZTogMjAxMi0wNS0xNSAxODo1OQ0KVG86IHBwc3ANCkNDOiBSdWkg Q3J1ejsgUGljY29uaSBGYWJpbzsgWWluZ2ppZSBHdSh5aW5namllKTsgemhhbmd5dW5mZWkgKHpo YW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbSkNClN1YmplY3Q6IFJlOiBbcHBzcF0gdGlja2V0cyBm b3IgSUVURiA4Mw0KSGksDQoNCg0KT24gVGlja2V0ICM0OiBUaGUgRklORCB1c2UgY2FzZSBjYW4g cGVyZmVjdGx5IGJlIHNlZW4gYXMgRmFiaW8gZGVzY3JpYmVkLCBpLmUuLCAidG8gZmluZCBwZWVy cyBzdWJqZWN0IHRvIGF0dHJpYnV0ZSBjb25zdHJhaW50cyIgaW4gb3JkZXIgdG8gc3BlZWQgdXAg ZGlzY292ZXJ5LCBpLmUuLCBtYXkgYmUgdXNlZCBpbiBzcGVjaWFsIHNpdHVhdGlvbnMgb25seSwg dGhlcmVmb3JlLCB0aGUgb3ZlcmhlYWQgdG8gdGhlIHRyYWNrZXIgY2FuIGJlIGNvbnNpZGVyZWQg bWluaW1hbC4NCg0KDQpPbiBUaWNrZXQgIzU6IFRoZSB0cmFja2VyIHByb3RvY29sIHByb3Bvc2Fs IGlzIGJlaW5nIHNwbGl0IGluIGEgYmFzZSBzcGVjaWZpY2F0aW9uIGFuZCBleHRlbnNpb25zLiBX ZSBkbyBub3Qgc2VlIHRoZSBuZWVkIGZvciAiYWRkaXRpb25hbCBtZXNzYWdlcyBlLmcuLHJlY29u bmVjdCBhbmQgcmVqb2luKSIgYXMgdGhpcyB0eXBlIG9mICJhY3Rpb24iIGlzIHBlcmZlY3RseSBz b2x2ZWQgd2l0aCB0aGUgYWxyZWFkeSBwcm9wb3NlZCBtZXNzYWdlcy4gIFRoaXMgaXMgdGhlIGNh c2Ugb2YgdGhlIG5ldyBzZW1hbnRpYyBmb3IgdGhlIENPTk5FQ1QgbWVzc2FnZSB3aXRoIGltcGxp Y2l0IEpPSU5zIHdoaWNoIGJlaGF2ZXMgYXMgYSByZS1DT05ORUNUIHdpdGggcmUtSk9JTnMuDQoN Cg0KV2Ugd291bGQgYXBwcmVjaWF0ZSBhbiBhZHZpc2UgZnJvbSB0aGUgY2hhaXJzIG9uIHNwbGl0 dGluZyB0aGUgdHJhY2tlciBwcm90b2NvbCBwcm9wb3NhbCBpbiBhIGJhc2Ugc3BlY2lmaWNhdGlv biBhbmQgZXh0ZW5zaW9ucy4gU2hvdWxkIGl0IGJlIGRvbmUgd2l0aCB0d28gZGlmZmVyZW50IGRy YWZ0IGRvY3VtZW50cyBvciB3aXRoIGEgc2luZ2xlIGRvY3VtZW50IHdoZXJlIHRoZSBleHRlbnNp b25zIGFyZSBjbGVhcmx5IHNlcGFyYXRlIHRvIGFuIEFubmV4Pz8NCg0KUmVnYXJkcywNCg0KDQpS dWkgQ3J1eg0KcnVpLmNydXpAaWVlZS5vcmcNCg0KDQpJU1QvSU5FU0MtSUQvSU5PViAtIExpc2Jv biwgUG9ydHVnYWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcHBzcA0KDQoNCk9uIDE1LzA1LzIwMTIsIGF0IDA0OjEwLCB6aGFuZ3l1 bmZlaSB3cm90ZToNCg0KDQpIaSBSdWkgYW5kIFlpbmdqaWUsDQogICAgV291bGQgeW91IHBsZWFz ZSBjb25maXJtIHRoZSB0aWNrZXQgIzQgZm9yIFBhcmlzIG1lZXRpbmc/DQogICAgIEZvciB0aWNr ZXQgIzUsIEkgYW0gZmluZSB3aXRoIEZhYmlvJ3MgcHJvcG9zYWwuDQoNCkJSDQpZdW5mZWkNCg0K DQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogUGljY29uaSBGYWJpbw0KRGF0ZTogMjAxMi0wNS0x NCAyMDowNA0KVG86IHpoYW5neXVuZmVpOyBwcHNwDQpTdWJqZWN0OiBSRTogW3Bwc3BdIHRpY2tl dHMgZm9yIElFVEYgODMNCkhpLA0KU29tbWUgY29tbWVudHM6DQpUaWNrZXQgIzEgKGNodW5rIGFk ZHJlc3NpbmcgbWVjaGFuaXNtKS4gU2VlIG15IGVtYWlsIHNlbmQgdG9kYXkuDQpUaWNrZXQgIzIu IEkgY2FuGyRCIUcbKEJ0IHJlbWVtYmVyIHdoYXQgdGhpcyB3YXMgYWJvdXQuIDotKQ0KVGlja2V0 ICMzIChzZWN1cmUgUEVYKTogSSB0aGluayB0aGF0IHdlIGNhbiBzdGljayB0byBhIHNpbXBsZSBQ RVggbWVjaGFuaXNtIHRoYXQgY2FuIGJlIGF1Z21lbnRlZCBieSBhbiBvcHRpb25hbCBzZWN1cmUg YWxnb3JpdGhtLiBJbiBhZGRpdGlvbiB0byB0aGUgc29sdXRpb24gcHJvcG9zZWQgYnkgQXJubywg dGhlcmUgaXMgYSBzaW1wbGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBieSBKZXNpIGV0IGFsLiBbMV0u DQpUaWNrZXQgIzQgKEZJTkQgdXNlIGNhc2UpLiBJIGRvbhskQiFHGyhCdCByZWNhbGwgZXhhY3Rs eSB0aGUgZGV0YWlscyBvZiB0aGlzIGlzc3VlLiBJZiBpdBskQiFHGyhCcyBvbmx5IG1vdGl2YXRp bmcgYSByZXF1ZXN0IHRvIHRoZSB0cmFja2VyIHRvIGZpbmQgcGVlcnMgc3ViamVjdCB0byBhdHRy aWJ1dGUgY29uc3RyYWludHMsIHRoZW4gZmluZGluZyBwZWVycyB3aXRoIGEgc2ltaWxhciB1cGxv YWQgY2FwYWNpdHkgKHRvIHNwZWVkIHVwIHRoZSBkaXNjb3ZlcnkgcGhhc2UpIGlzIGFscmVhZHkg YSBnb29kIG1vdGl2YXRpb24uDQpUaWNrZXQgIzUgKGFkZGl0aW9uYWwgbWVzc2FnZXMpLiBJIHRo aW5rIHRoZSBwcm9wb25lbnRzIG9mIHRoZXNlIG1lc3NhZ2VzIHNob3VsZCBkZXNjcmliZSB0aGUg dXNlIGNhc2VzIHdoZXJlIHRoZXNlIG1lc3NhZ2VzIGNhbiBiZSB1c2VmdWwuDQpDaGVlcnMsDQpG YWJpbw0KWzFdIEcuUC4gSmVzaSwgQS4gTW9udHJlc29yLCBhbmQgTS4gdmFuIFN0ZWVuLiBTZWN1 cmUgUGVlciBTYW1wbGluZy4gSW4gQ29tcHV0ZXIgTmV0d29ya3MsIDIwMTAuDQogDQpGcm9tOiBw cHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiB6aGFuZ3l1bmZlaQ0KU2VudDogamV1ZGkgMyBtYWkgMjAxMiAxMDoxMw0KVG86IHBw c3ANClN1YmplY3Q6IFtwcHNwXSB0aWNrZXRzIGZvciBJRVRGIDgzDQogDQpIaSBhbGwsDQogICAg SSBoYXZlIHN1bW1hcml6ZWQgYW4gaW5pdGlhbCB0aWNrZXRzIGxpc3QgZm9yIElFVEYgODMgbWVl dGluZy4gUGxlYXNlIHJldmlldyBpdCBhbmQgYWN0aW9ucyBvbiB0aGVzZSB0aWNrZXRzIGFyZSBl eHBlY3RlZC4gVGhhbmtzLg0KIA0KQlINCll1bmZlaSAmU3RlZmFubw0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClBlZXIgcHJvdG9jb2w6DQpUaWNr ZXQgIzEbJEIhJxsoQlBvc3QgYW5kIGRpc2N1c3MgdGhlIGFsdGVybmF0aXZlIHByb3Bvc2FsIGJl c2lkZXMgTUhUIGluIHBlZXIgcHJvdG9jb2wgKFByb3Bvc2FsIDEwKzEzKSwgbGlzdCBpbnRlcnZh bHMgKFRyYWRlb2ZmIGFtb25nIGNvbXBsZXhpdHkgLyBvdmVyaGVhZCAvIGVmZmljaWVuY3kgLyBp bXBsZW1lbnRhdGlvbikgYW5kIGNoZWNrIGdhcHMuIFtNYXJ0aW4bJEIhJBsoQll1bmZlaSwgRmFi aW8sIExpY2h1bl0NClRoaXMgdGlja2V0IGlzIHBhcnRseSBzb2x2ZWQuIFNpbXBsZSBuYXR1cmUg bnVtYmVyIGFkZHJlc3NpbmcgYW5kIHJhbmdlZCBleHByZXNzaW9uIG9uIGNodW5rIGF2YWlsYWJp bGl0eS4gVGhlIGFuYWx5c2lzIGFuZCBjb21wYXJpc29uIGlzIG9uZ29pbmcuIEknZCBzdWdnZXN0 IHRvIGhhdmUgYSBkZWFkbGluZSBmb3IgdGhlIHJlc29sdXRpb24gdGltZSBhZnRlciBkaXNjdXNz aW5nIHdpdGggU3RlZmFubywgaS5lLiwgIE1heSAyNnRoIGZyb20gbm93IG9uIHRvIG1ha2UgdGhl IGRlY2lzaW9uIGluIHRoZSBXRyBsZXZlbC4NCiANClRpY2tldCAjMhskQiEnGyhCRGlzY3VzcyB0 aGUgcG9zc2libGUgGyRCIUgbKEIic3RhdGUtYnVpbGRpbmcgYXR0YWNrcyIgYXR0YWNrIG9uIHBl ZXJzLltNYXJ0aW5dKHJlbGF0ZWQgUHJvcG9zYWwgMjYpDQpNYXJ0aW4sIERvIHlvdSBzdGlsbCBo YXZlIGNvbmNlcm5zIG9uIHRoaXM/IElmIG5vYm9keSBzaG93cyB1cCwgd2UgcHJvcG9zZSB0byBj bG9zZSB0aGlzIHRpY2tldC4NCiANClRpY2tldCAjMzogRGlzY3VzcyB0aGUgTWVtYmVyc2hpcCBj ZXJ0aWZpY2F0ZXMgaW1wYWN0IG9uIHRoZSB0cmFja2VyGyRCIUcbKEJzIHdvcmtsb2FkLltGYWJp b10ocmVsYXRlZCB0byBQcm9wb3NhbCAxNysyMCkNCiANClRyYWNrZXIgcHJvdG9jb2w6DQpUaWNr ZXQjNDogU3BlY2lmeSB0aGUgRklORCB1c2UgY2FzZSBhbmQgcmVkdWNlIHRoZSBvdmVyaGVhZCB0 byB0aGUgdHJhY2tlci5bTWFydGluLFl1bmZlaRskQiEkGyhCRmFiaW8bJEIhJBsoQlJpY2hhcmRv XQ0KVGlja2V0IzU6IERpc2N1c3MgY29uY3JldGUgdXNlIGNhc2VzIG9mIGFkZGl0aW9uYWwgbWVz c2FnZXMgaWYgdGhlcmUgYXJlKGUuZy4scmVjb25uZWN0IGFuZCByZWpvaW4pICwgYW5kIGNvbmNs dWRlIHRoZSBiYXNpYyBtZXNzYWdlcyBhbmQgb3B0aW9uYWwgb25lcyBpbiB0cmFja2VyIHByb3Rv Y29sLiBbTWFyaywgRmFiaW9dDQogV2UgcHJvcG9zZSB0byB0aGUgdHJhY2tlciBwcm90b2NvbCBh dXRob3JzIHRvIGFkZHJlc3MgdGhlaXIgdGlja2V0cyB3aXRoIGEgc3BsaXR0aW5nIG9mIHRoZWly IHByb3Bvc2FsOg0KLiBiYXNlIHNwZWMNCi4gYWRkaXRpb25hbCBvcHRpb25zLg0KIA0KU3VydmV5 DQpUaWNrZXQjNjogQ2FsbCBmb3IgcmV2aWV3ZXJzIGZvciBzdXJ2ZXkgZHJhZnQsIGFuZCBtYXli ZSBQMlAgc3RyZWFtaW5nIHByb3ZpZGVycxskQiFHGyhCIGNvbnRyaWJ1dGlvbiBvbiB1cGRhdGlu ZyB0aGUgZHJhZnQuICAgDQogDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart721728647661_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-2022-jp"
Thanks Rui for the clarification. I would suggest to sperate the base= =20 specification and the extensions with two different drafts for two=20 reasons:
1) It would be much easier to get consensus on the base draft since=20 its scope is highly limited. In this way the progress will be earlier= to=20 achieve.
2) We see many similar operations in IETF drafts practices = which=20 may be proved to be an efficient way in IETF circle.
 
BR
Yunfei 
 
zhangyunfei
 
From: Rui Cruz
Date: 2012-05-15 18:59
To: ppsp
CC: Rui Cruz; Picconi Fabio; Yingjie Gu(yingjie); zhangyunfei=20 (zhangyunfei@chinamobile.com)
Subject: Re: [ppsp] tickets for IETF 83
Hi,

On Ticket #4: The FIND use case can perfectly be seen as Fabio= =20 described, i.e., "to find peers subject to attribute constraints" in=20 order to speed up discovery, i.e., may be used in special situations only,= =20 therefore, the overhead to the tracker can be considered minimal.

On Ticket #5: The tracker protocol proposal is being split in = a=20 base specification and extensions. We do not see the need fo= r=20 "additional messages e.g.,reconnect and rejoin)" as=20 this type of "action" is perfectly solved with the already proposed messag= es.=20  This is the case of the new semantic for the CONNECT message with im= plicit=20 JOINs which behaves as a re-CONNECT with re-JOINs.

We would appreciate an advise from the chairs on splitting the tracke= r=20 protocol proposal in a base=20 specification and extensions. Should it be done = with=20 two different draft documents or with a single document where the extensio= ns are=20 clearly separate to an Annex??
Regards,

Rui Cruz
rui.cruz@ieee.org

IST/INESC-ID/INOV - Li= sbon,=20 Portugal
__________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/m= ailman/listinfo/ppsp

On 15/05/2012, at 04:10, zhangyunfei wrote:
Hi Rui and Yingjie,
    Would you please confirm the ticket #4 for = Paris=20 meeting?
     For ticket #5, I am fine with Fabio's=20 proposal.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-05-14 20:04
To: zhangyunfei; ppsp
Subject: RE: [ppsp] tickets for IETF 83
Hi,
Somme=20 comments:
Ticket=20 #1 (chunk addressing mechanism). See my email send=20 today.
Ticket=20 #2. I can=1B$B!G=1B(Bt remember what this was about. :-)
Ticket=20 #3 (secure PEX): I think that we can stick to a simple PEX mechanism tha= t can=20 be augmented by an optional secure algorithm. In addition to the solutio= n=20 proposed by Arno, there is a simple mechanism described by Jesi et al.=20 [1].
Ticket=20 #4 (FIND use case). I don=1B$B!G=1B(Bt recall exactly the details of thi= s issue. If it=1B$B!G=1B(Bs=20 only motivating a request to the tracker to find peers subject to attrib= ute=20 constraints, then finding peers with a similar upload capacity (to speed= up=20 the discovery phase) is already a good motivation. Ticket=20 #5 (additional messages). I think the proponents of these messages shoul= d=20 describe the use cases where these messages can be=20 useful.
Cheers,
Fabio
[1]=20 G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. In Comp= uter=20 Networks, 2010.
 
From:<= /B> ppsp-bounces@ietf.org=20 [mailto:ppsp-bounces@ietf.org] On Behalf Of zhangyunfei
Sent: jeudi 3 mai 2012=20 10:13
To: ppsp
Subject: [ppsp] tickets for IETF=20 83
 
Hi all,<= SPAN=20 style=3D"COLOR: black">
  &nb= sp;=20 I have summarized an initial tickets list&= nbsp;for IETF 83 meeting.=20 Please review it and actions on these tickets are expected.=20 Thanks.
 
BR
Yunfei=20 &Stefano
---------------= --------------------------------------------------------------------------= ------------------
Peer=20 protocol:
Ticket #1<= SPAN=20 style=3D"FONT-FAMILY: 'MS Mincho'; COLOR: black" lang=3DZH-CN>=1B$B!'=1B= (BPost and discus= s the=20 alternative proposal besides MHT in peer protocol (Proposal 10+13), list= =20 intervals (Tradeoff among complexity / overhead / efficiency / implement= ation)=20 and check gaps. [Martin=1B$B!$=1B= (BYunfei, Fabio,=20 Lichun]
This ticket is = partly=20 solved. Simple nature number addressing and ranged expression on chunk=20 availability. The analysis and comparison is ongoing. I'd suggest t= o have=20 a deadline for the resolution time after discussing with Stefano, i= .e.,=20  from now on to = make the=20 decision in the WG level.
 
Ticket #2<= SPAN=20 style=3D"FONT-FAMILY: 'MS Mincho'; COLOR: black" lang=3DZH-CN>=1B$B!'=1B= (BDiscuss the=20 possible =1B$B!H=1B(B"state-building attacks" attack on peers.[Martin](rela= ted=20 Proposal 26)
Martin, Do you = still=20 have concerns on this? If nobody shows up, we propose to close this=20 ticket.
 
Ticket #3:=  Discuss the Membership certif= icates=20 impact on the tracker=1B$B!G=1B(Bs=20 workload.[Fabio](related to Proposal 17+20)
 
Tracker=20 protocol:
Ticket#4:<= SPAN=20 style=3D"FONT-FAMILY: Calibri, sans-serif; COLOR: black"> Specify the FIND use case and= reduce=20 the overhead to the tracker.[Martin,Yunfei=1B$B!$=1B= (BFabio=1B$B!$=1B= (BRichardo]
Ticket#5:<= SPAN=20 style=3D"FONT-FAMILY: Calibri, sans-serif; COLOR: black"> Discuss concrete use cases of= =20 additional messages if there are(e.g.,reconnect and rejoin) , and conclu= de the=20 basic messages and optional ones in tracker protocol. [Mark,=20 Fabio]
 We=20 propose to the tracker protocol authors to=  address their tickets with a splitting = ;of their proposal:
. base spec
. additional options.
  Survey :=20 Call for reviewers for survey draft, and maybe P2P streaming providers= =1B$B!G=1B(B=20 contribution on updating the draft.   
 
zhangyunfei
= _______________________________________________
ppsp=20 mailing list
ppsp@ietf.org
https://www.ietf.org/= mailman/listinfo/ppsp
------=_001_NextPart721728647661_=------ From zhangyunfei@chinamobile.com Tue May 15 18:52: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 2024721F860B for ; Tue, 15 May 2012 18:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.219 X-Spam-Level: X-Spam-Status: No, score=-96.219 tagged_above=-999 required=5 tests=[AWL=2.404, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7k0E569RhZO for ; Tue, 15 May 2012 18:52:22 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A7A8621F861B for ; Tue, 15 May 2012 18:52:21 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 78BD3E5DD; Wed, 16 May 2012 09:52:20 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 6A118E5D5; Wed, 16 May 2012 09:52:20 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051609521899-4389 ; Wed, 16 May 2012 09:52:18 +0800 Date: Wed, 16 May 2012 09:52:15 +0800 From: zhangyunfei To: "Picconi Fabio" , "arno@cs.vu.nl" References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl> <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> <4FB20BD5.6010607@cs.vu.nl>, <320C4182454E96478DC039F2C481987204EB26E7D4@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051609521522582017@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-16 09:52:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-16 09:52:19, Serialize complete at 2012-05-16 09:52:19 Content-Type: multipart/alternative; boundary="----=_001_NextPart107758374237_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18908.001 X-TM-AS-Result: No--34.030-7.0-31-10 X-imss-scan-details: No--34.030-7.0-31-10;No--34.030-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 01:52:23 -0000 This is a multi-part message in MIME format. ------=_001_NextPart107758374237_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgRmFiaW8sIEFybm8gYW5kIGFsbCwNCiAgICAgSSBoYXZlIGEgdGhvdWdodCBvbiBob3cgdG8g ZGlzY3VzcyB0aGUgYXZlcmFnZSBjYXNlLiBQbGVhc2UgZGlzY3VzcyB0byBzZWUgaWYgaXQgd29y a3MuDQogICAgIFdlIG1heSBmaW5kIGluIHNvbWUgbWVhc3VyZW1lbnQgd29yayB0byBzZWUgdGhl IGRpc3RyaWJ1dGlvbiBvZiB0aGUgY2h1bmtzIGluIHRoZSBidWZmZXIgKG1heWJlIGluIGRpZmZl cmVudCBwaGFzZSwgdGhlcmUgYXJlIGRpZmZlcmVudCBkaXN0cmlidXRpb25zLCBlLmcuLCB0aGUg YmVnaW5uaW5nLCB0aGUgbm9ybWFsIHBsYXksIGFmdGVyIGRyYWdnaW5nLCBidXQgSSBhbSBub3Qg c3VyZSkuIEluIHRoaXMgY2FzZSwgdGhlIHByb2JsZW0gRmFiaW8gcHJvcG9zZWQgaXMgc29sdmVk IGFuZCB3ZSBjYW4gZ2V0IGFuIGFuYWx5c2lzIG9mIHRoZSB0d28gc2NoZW1lcy4NCg0KQlINCll1 bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBQaWNjb25pIEZhYmlvDQpEYXRlOiAy MDEyLTA1LTE1IDIxOjA0DQpUbzogYXJub0Bjcy52dS5ubA0KQ0M6IHpoYW5neXVuZmVpOyBwcHNw DQpTdWJqZWN0OiBSRTogUHJvcG9zYWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEzDQpJJ20gbm90 IHN1cmUgSSBmb2xsb3cgeW91Lg0KDQpGaXJzdCwgSSBhc3N1bWVkIHRocmVlIGNodW5rcyBwZXIg c2Vjb25kIGJlY2F1c2UgdGhlcmUgaXMgYSBwYXBlciB0aGF0IHN1Z2dlc3RzIHRoYXQgdGhpcyBp cyBhIGdvb2QgdmFsdWUgWzFdLiBCdXQgdGhlIGFjdHVhbCBjaHVuayByYXRlIGRvZXMgbm90IGNo YW5nZSB0aGUgY2FsY3VsYXRpb24gKG1vcmUgY2h1bmtzIHBlciBzZWNvbmRzIG1lYW5zIGJvdGgg bW9yZSBiaW5zIGFuZCBtb3JlIHJhbmdlcykuDQoNClNlY29uZCwgaWYgeW91IHVzZSByYW5nZXMs IHNlbmRpbmcgYW4gdXBkYXRlIHRvIGluZm9ybSB0aGUgcmVjZXB0aW9uIG9mIGFuIGVudGlyZSAz MksgYmxvY2sgKGkuZS4sIDMyIDFLIGNodW5rcykgdGFrZXMgdHdvIGludGVnZXJzIHdpdGggcmFu Z2UgbGlzdHMsIG9yIG9uZSBpbnRlZ2VyIHVzaW5nIGJpbnMuIElmIHlvdSBoYXZlIHRocmVlIGJs b2NrcyBwZXIgc2Vjb25kLCB0aGF0IG1lYW5zIDYgaW50ZWdlcnMgcGVyIHNlY29uZCBwZXIgbmVp Z2hib3IsIGluc3RlYWQgb2YgMyBpbnRlZ2VycyBwZXIgc2Vjb25kIHBlciBuZWlnaGJvci4gSW4g Ym90aCBjYXNlcyB0aGUgb3ZlcmhlYWQgaXMgbmVnbGlnaWJsZS4NCg0KSW4gdGhlIGFic2VuY2Ug b2YgYW4gYXZlcmFnZSBjYXNlIGFuYWx5c2lzIChpLmUuLCB3aGVyZSB0aGUgYnVmZmVyIGNvbnRh aW5zIGxvdHMgb2YgaG9sZXMpIHNob3dpbmcgdGhhdCBiaW5zIGFyZSBiZXR0ZXIgdGhhbiByYW5n ZSBsaXN0cywgYW5kIGdpdmVuIHRoZSBuZWdsaWdpYmxlIG92ZXJoZWFkIG9mIGJvdGggc29sdXRp b25zIGluIHRoZSB3b3JzdCBhbmQgYmVzdCBjYXNlLCBJIHdvdWxkIGdvIGZvciB0aGUgc2ltcGxl ciBzb2x1dGlvbiwgaS5lLiwgcmFuZ2UgbGlzdHMuDQoNCkZhYmlvDQoNClsxXSBTaXplIERvZXMg TWF0dGVyIChpbiBQMlAgTGl2ZSBTdHJlYW1pbmcpLiBOLiBIZWdkZSwgRi4gTWF0aGlldSBhbmQg RC4gUGVyaW5vLiBJbiBBbGdvdGVsJzA5IGFuZCBhbHNvIElucmlhIFRlY2huaWNhbCByZXBvcnQg IzcwMzIsIDIwMDkuDQoNCg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogQXJubyBCYWtrZXIgW21haWx0bzphcm5vQGNzLnZ1Lm5sXQ0KPiBTZW50OiBtYXJkaSAxNSBt YWkgMjAxMiAwOTo1NQ0KPiBUbzogUGljY29uaSBGYWJpbw0KPiBDYzogemhhbmd5dW5mZWk7IHBw c3ANCj4gU3ViamVjdDogUmU6IFByb3Bvc2FsIHRvIHJlc29sdmUgSXNzdWUgMTAgKyAxMw0KPiAN Cj4gSGkgRmFiaW8gYW5kIGFsbA0KPiANCj4gT24gMTQvMDUvMjAxMiAxNzo1MiwgUGljY29uaSBG YWJpbyB3cm90ZToNCj4gPg0KPiA+IFRha2luZyBXPTMwIHNlY29uZHMgYW5kIDMgY2h1bmtzIHBl ciBzZWNvbmQsIDQgYnl0ZXMgcGVyIGludGVnZXIsIGFuZA0KPiA+IDEgYnVmZmVyIG1hcCBwZXIg c2Vjb25kIHRvIDEwIG5laWdoYm9ycywgcmFuZ2UgbGlzdCByZXF1aXJlcyB+IDMwDQo+IGticHMN Cj4gPiBpbiB0aGUgd29yc3QgY2FzZSB2cy4gfiAxNSBrYnBzIGZvciBiaW5zLiBGb3IgYSAxIE1i cHMgc3RyZWFtLCB0aGF0J3MNCj4gPiBhIDMlIG92ZXJoZWFkIGluc3RlYWQgb2YgMS41JSwgd2hp Y2ggSSBkb24ndCB0aGluayBpcyB0aGF0IGJpZyBhDQo+IGRlYWwuDQo+ID4NCj4gDQo+IElNSE8s IHRoZSBjYWxjdWxhdGlvbiBzaG91bGQgYmUgc29tZXdoYXQgZGlmZmVyZW50LiBJdCBub3cgYXNz dW1lcyB3ZQ0KPiBzZW5kIHRoZSBjb21wbGV0ZSAzMCBzZWNvbmQgbWFwIGV2ZXJ5IHNlY29uZC4g SSdkIHNheSBpdCBpcyBtb3JlIGxpa2VseQ0KPiB0aGF0IHdlIGRvd25sb2FkIGF0IGFwcHJveC4g dGhlIGJpdHJhdGUgc28gd2UgaGF2ZSBvbmx5IDEgc2Vjb25kcyB3b3J0aA0KPiBvZiB1cGRhdGVz IHRvIHRoZSBtYXAgdG8gc2VuZC4gSS5lLiAzIGNodW5rcyBpbiB5b3VyIGV4YW1wbGUuIFRoaXMN Cj4gbWVhbnMgbGVzcyBvdmVyaGVhZC4NCj4gDQo+IFdpdGggVURQIGFzIGEgdHJhbnNwb3J0LCBj aHVuayBzaXplIGlzIHByZWZlcmFibHkgMUsgdG8ga2VlcCB0aGUgaW1wYWN0DQo+IG9mIHRoZSBs b3NzIG9mIGEgc2luZ2xlIElQIHBhY2tldCBsb3cgKG9uIEV0aGVybmV0KS4gVGhlbiAzIGNodW5r cyBwZXINCj4gc2Vjb25kIHNob3VsZCBiZSAxMDAgY2h1bmtzIHBlciBzZWNvbmQgZm9yIDEgTWJw cywgaW1wbHlpbmcgd2Ugc2VuZA0KPiBlaXRoZXIgODAwIGJ5dGVzICgyIGludHMgcGVyIHJhbmdl KSBvciA0MDAgYnl0ZXMgKDEgYmluKSBhcyBvdmVyaGVhZCwNCj4gd29yc3QgY2FzZS4gRm9yIDEw IG5laWdoYm91cnMgdGhpcyBtZWFucyA2NCBhbmQgMzIga2Jwcywgb3IgNiUgYW5kIDMlDQo+IHJl c3BlY3RpdmVseS4NCj4gDQo+IA0KPiA+IE5vdywgdHdvIHRoaW5nczogMSkgYW4gb3B0aW1pemVk IGltcGxlbWVudGF0aW9uIG9mIHJhbmdlIGxpc3RzIHdvdWxkDQo+ID4gZW5jb2RlIHNpbmdsZS1l bGVtZW50IHJhbmdlcyB3aXRoIGEgc2luZ2xlIGludGVnZXIsIHNvIHRoZSBvdmVyaGVhZA0KPiA+ IHdvdWxkIGJlIGlkZW50aWNhbCB0byB0aGF0IG9mIGJpbnMgKGkuZS4sIDEuNSUpOyAyKSB3ZSdy ZSB0YWxraW5nDQo+ID4gYWJvdXQgdGhlIHdvcnN0IGNhc2Ugd2hpY2ggaXMgZXh0cmVtZWx5IHVu bGlrZWx5IHRvIGhhcHBlbi4uLiBpdA0KPiB3b3VsZA0KPiA+IGJlIGludGVyZXN0aW5nIHRvIGRv IHRoZSBhdmVyYWdlIGNhc2UgYW5hbHlzaXMgZm9yIHRoZSBbUCsxLFArV10NCj4gPiBpbnRlcnZh bC4NCj4gPg0KPiANCj4gQXMgYXJndWVkIGJlZm9yZSwgSSBhc3N1bWUgZGF0YSB3aWxsIGJlIHJl cXVlc3RlZCBpbiBibG9ja3Mgb2YgY2h1bmtzLA0KPiBpbiBwYXJ0aWN1bGFyIG9uIFVEUCB3aXRo IDFLIGNodW5rcywgd2hpY2ggYXJlIGEgcG93ZXIgb2YgMiwgZS5nLiAzMksuDQo+IFdlIGNhbiBh bGlnbiB0aGVzZSByZXF1ZXN0cyBvbiBwb3dlci0yIGJvdW5kYXJpZXMgc3VjaCB0aGF0IHdlIG5l ZWQNCj4ganVzdA0KPiAxIGJpbiB0byBhZGRyZXNzIHRoZW0uIFdpdGggcmFuZ2VzIHdlIGFsd2F5 cyBuZWVkIDIgaW50cywgYXMgd2UncmUNCj4gZGVub3RpbmcgYSBibG9jayBvZiBjaHVua3MuDQo+ IA0KPiBXaXRoIHRoaXMgYmxvY2sgYXNzdW1wdGlvbiwgaW4gdGhlIHdvcnN0IGNhc2UsIGFuIHVw ZGF0ZSBpcyAoMTAwSy9ibG9jaw0KPiBzaXplKSByYW5nZXMuIFNvIGUuZy4gMyByYW5nZXMgZm9y IDMyIEssIHRha2luZyBlaXRoZXIgMiBvciAxIGludCB0bw0KPiBlbmNvZGUsIGFuZCB0aHVzIGlt cGx5aW5nIDIga2JwcyBhbmQgMSBrYnBzIGZvciAxMCBuZWlnaGJvdXJzLCBvciAwLjINCj4gYW5k IDAuMSUgb3ZlcmhlYWQuIExlc3MgZm9yIGxhcmdlciBibG9jayBzaXplcy4NCj4gDQo+IEluIGNv bmNsdXNpb24sIGlmIHdlIHNlbmQgbWFwIHVwZGF0ZXMgaW5zdGVhZCBvZiB0aGUgZnVsbCBtYXAs IHRoZQ0KPiBhYnNvbHV0ZSBvdmVyaGVhZCBvZiBwdXNoaW5nIGNodW5rIGF2YWlsYWJpbGl0eSBp cyBsb3cuIFJlbGF0aXZlDQo+IG92ZXJoZWFkIGNhbiBzdGlsbCBiZSAxMDAlIGFuZCBiaW5zIGdp dmUgYSBwcmV0dGllciBvbmUtdW5pdCBkZXNpZ24gO28pDQo+IA0KPiBDVSwNCj4gICAgICBBcm5v ------=_001_NextPart107758374237_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Fabio, Arno and all,
     I have a thought on how to discuss the=20 average case. Please discuss to see if it works.
     We may find in some measurement work to see = the=20 distribution of the chunks in the buffer (maybe in different phase, there = are=20 different distributions, e.g., the beginning, the normal play, after=20 dragging, but I am not sure). In this case, the problem Fabio proposed is = solved=20 and we can get an analysis of the two schemes.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-05-15 21:04
To: arno@cs.vu.nl
CC: zhangyunfei; ppsp
Subject: RE: Proposal to resolve Issue 10 +=20 13
I'm not sure I follow you.
 
First, I assumed three chunks per secon= d because there is a paper that suggest= s that this is a good value [1]. B= ut the actual chunk rate does not chang= e the calculation (more chunks per seconds&n= bsp;means both more bins and more ranges).
 
Second, if you use ranges, sending an&n= bsp;update to inform the reception of an&nbs= p;entire 32K block (i.e., 32 1K chunks) = ;takes two integers with range lists, or&nbs= p;one integer using bins. If you have t= hree blocks per second, that means 6 in= tegers per second per neighbor, instead of&n= bsp;3 integers per second per neighbor. In&n= bsp;both cases the overhead is negligible.
 
In the absence of an average case = analysis (i.e., where the buffer contains lo= ts of holes) showing that bins are bett= er than range lists, and given the negl= igible overhead of both solutions in the&nbs= p;worst and best case, I would go for&n= bsp;the simpler solution, i.e., range lists.
 
Fabio
 
[1] Size Does Matter (in P2P Live = Streaming). N. Hegde, F. Mathieu and D. = ;Perino. In Algotel'09 and also Inria Techni= cal report #7032, 2009.
 
 
 
 
> -----Original Message-----
> From: Arno Bakker [mailto:arno@cs.vu.nl]
> Sent: mardi 15 mai 2012 09:55
> To: Picconi Fabio
> Cc: zhangyunfei; ppsp
> Subject: Re: Proposal to resolve I= ssue 10 + 13
> 
> Hi Fabio and all
> 
> On 14/05/2012 17:52, Picconi Fabio = ;wrote:
> >
> > Taking W=3D30 seconds and 3&n= bsp;chunks per second, 4 bytes per integer,&= nbsp;and
> > 1 buffer map per second = to 10 neighbors, range list requires ~ = 30
> kbps
> > in the worst case vs. ~&= nbsp;15 kbps for bins. For a 1 Mbps&nbs= p;stream, that's
> > a 3% overhead instead of = ;1.5%, which I don't think is that big&= nbsp;a
> deal.
> >
> 
> IMHO, the calculation should be so= mewhat different. It now assumes we
> send the complete 30 second map&nb= sp;every second. I'd say it is more lik= ely
> that we download at approx. the&nb= sp;bitrate so we have only 1 seconds wo= rth
> of updates to the map to send= . I.e. 3 chunks in your example. This
> means less overhead.
> 
> With UDP as a transport, chunk&nbs= p;size is preferably 1K to keep the imp= act
> of the loss of a single IP&nb= sp;packet low (on Ethernet). Then 3 chunks&n= bsp;per
> second should be 100 chunks per&nb= sp;second for 1 Mbps, implying we send
> either 800 bytes (2 ints per = range) or 400 bytes (1 bin) as overhead= ,
> worst case. For 10 neighbours this=  means 64 and 32 kbps, or 6% and&n= bsp;3%
> respectively.
> 
> 
> > Now, two things: 1) an o= ptimized implementation of range lists would
> > encode single-element ranges with&= nbsp;a single integer, so the overhead
> > would be identical to that&nb= sp;of bins (i.e., 1.5%); 2) we're talking
> > about the worst case which&nb= sp;is extremely unlikely to happen... it
> would
> > be interesting to do the = ;average case analysis for the [P+1,P+W]
> > interval.
> >
> 
> As argued before, I assume data&nb= sp;will be requested in blocks of chunks,
> in particular on UDP with 1K = chunks, which are a power of 2, e.g.&nb= sp;32K.
> We can align these requests on&nbs= p;power-2 boundaries such that we need
> just
> 1 bin to address them. With r= anges we always need 2 ints, as we're
> denoting a block of chunks.
> 
> With this block assumption, in the=  worst case, an update is (100K/block
> size) ranges. So e.g. 3 ranges&nbs= p;for 32 K, taking either 2 or 1 i= nt to
> encode, and thus implying 2 kbps&n= bsp;and 1 kbps for 10 neighbours, or 0.= 2
> and 0.1% overhead. Less for larger=  block sizes.
> 
> In conclusion, if we send map = ;updates instead of the full map, the
> absolute overhead of pushing chunk = ;availability is low. Relative
> overhead can still be 100% and&nbs= p;bins give a prettier one-unit design ;o)
> 
> CU,
>      Arno
------=_001_NextPart107758374237_=------ From a.bakker@vu.nl Tue May 15 23:08:52 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 C4A6821F86A4 for ; Tue, 15 May 2012 23:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[AWL=3.106, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuDDWS8gbrxB for ; Tue, 15 May 2012 23:08:52 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id AC3FD21F86A2 for ; Tue, 15 May 2012 23:08:50 -0700 (PDT) Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 16 May 2012 08:08:56 +0200 Received: from [109.37.13.128] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 16 May 2012 08:08:49 +0200 Message-ID: <4FB344AE.50908@cs.vu.nl> Date: Wed, 16 May 2012 08:09:50 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Picconi Fabio References: <2012050316123830359558@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com>, <4FB0FC97.7020601@cs.vu.nl> <2012051511133262864742@chinamobile.com> <320C4182454E96478DC039F2C481987204EB26E73A@MOPESMBX01.eu.thmulti.com> In-Reply-To: <320C4182454E96478DC039F2C481987204EB26E73A@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] tickets for IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 06:08:52 -0000 On 15/05/2012 14:45, Picconi Fabio wrote: > Indeed, I don$B!G(Bt think we should impose a security mechanism on the base > protocol. There are existing systems that perform PEX without any > security. Even the BitTorrent tracker allows you to spoof somebody and > register them in the swarm. > Hi I agree that one must be able to turn it off, but in public networks one MUST either turn PEX off or use a secure version, IMHO. Hence, a secure version must be in the spec. I propose to use the membership certs which correspond to the signed descriptors from literature. We should then discuss how certification of peers can be done. BitTorrent wasn't designed by professionals, and it appears its PEX feature is currently being exploited by anti-piracy outfits to attack the health of swarms ;o) http://yro.slashdot.org/story/12/05/13/1928215/microsoft-funded-startup-aims-to-kill-bittorrent-traffic CU, Arno From Fabio.Picconi@technicolor.com Tue May 15 23:53:42 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 7E9AD9E8005 for ; Tue, 15 May 2012 23:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.227 X-Spam-Level: X-Spam-Status: No, score=-4.227 tagged_above=-999 required=5 tests=[AWL=2.371, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNcPv97CiNq7 for ; Tue, 15 May 2012 23:53:41 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 02A0F9E8006 for ; Tue, 15 May 2012 23:53:26 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT7NO5rj6jDRhVG5DDei3kAs2BTyj4+OM@postini.com; Tue, 15 May 2012 23:53:31 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 16 May 2012 08:52:58 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.225]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Wed, 16 May 2012 08:53:02 +0200 From: Picconi Fabio To: zhangyunfei , "arno@cs.vu.nl" Date: Wed, 16 May 2012 08:53:00 +0200 Thread-Topic: RE: Proposal to resolve Issue 10 + 13 Thread-Index: Ac0zBos6K0XNAN6QREKiE+K/Q2ECsgAKeKUg Message-ID: <320C4182454E96478DC039F2C481987204EB2FBE81@MOPESMBX01.eu.thmulti.com> References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl> <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> <4FB20BD5.6010607@cs.vu.nl>, <320C4182454E96478DC039F2C481987204EB26E7D4@MOPESMBX01.eu.thmulti.com> <2012051609521522582017@chinamobile.com> In-Reply-To: <2012051609521522582017@chinamobile.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_320C4182454E96478DC039F2C481987204EB2FBE81MOPESMBX01eut_" MIME-Version: 1.0 Cc: ppsp Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 06:53:42 -0000 --_000_320C4182454E96478DC039F2C481987204EB2FBE81MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, a quick simulation would shed some light on the average case. Now we n= eed to find the time to do it. :-) Fabio From: zhangyunfei [mailto:zhangyunfei@chinamobile.com] Sent: mercredi 16 mai 2012 03:52 To: Picconi Fabio; arno@cs.vu.nl Cc: ppsp Subject: Re: RE: Proposal to resolve Issue 10 + 13 Hi Fabio, Arno and all, I have a thought on how to discuss the average case. Please discuss to= see if it works. We may find in some measurement work to see the distribution of the ch= unks in the buffer (maybe in different phase, there are different distribut= ions, e.g., the beginning, the normal play, after dragging, but I am not su= re). In this case, the problem Fabio proposed is solved and we can get an a= nalysis of the two schemes. BR Yunfei ________________________________ zhangyunfei From: Picconi Fabio Date: 2012-05-15 21:04 To: arno@cs.vu.nl CC: zhangyunfei; ppsp Subject: RE: Proposal to resolve Issue 10 + 13 I'm not sure I follow you. First, I assumed three chunks per second because there is a paper that sugg= ests that this is a good value [1]. But the actual chunk rate does not chan= ge the calculation (more chunks per seconds means both more bins and more r= anges). Second, if you use ranges, sending an update to inform the reception of an = entire 32K block (i.e., 32 1K chunks) takes two integers with range lists, = or one integer using bins. If you have three blocks per second, that means = 6 integers per second per neighbor, instead of 3 integers per second per ne= ighbor. In both cases the overhead is negligible. In the absence of an average case analysis (i.e., where the buffer contains= lots of holes) showing that bins are better than range lists, and given th= e negligible overhead of both solutions in the worst and best case, I would= go for the simpler solution, i.e., range lists. Fabio [1] Size Does Matter (in P2P Live Streaming). N. Hegde, F. Mathieu and D. P= erino. In Algotel'09 and also Inria Technical report #7032, 2009. > -----Original Message----- > From: Arno Bakker [mailto:arno@cs.vu.nl] > Sent: mardi 15 mai 2012 09:55 > To: Picconi Fabio > Cc: zhangyunfei; ppsp > Subject: Re: Proposal to resolve Issue 10 + 13 > > Hi Fabio and all > > On 14/05/2012 17:52, Picconi Fabio wrote: > > > > Taking W=3D30 seconds and 3 chunks per second, 4 bytes per integer, and > > 1 buffer map per second to 10 neighbors, range list requires ~ 30 > kbps > > in the worst case vs. ~ 15 kbps for bins. For a 1 Mbps stream, that's > > a 3% overhead instead of 1.5%, which I don't think is that big a > deal. > > > > IMHO, the calculation should be somewhat different. It now assumes we > send the complete 30 second map every second. I'd say it is more likely > that we download at approx. the bitrate so we have only 1 seconds worth > of updates to the map to send. I.e. 3 chunks in your example. This > means less overhead. > > With UDP as a transport, chunk size is preferably 1K to keep the impact > of the loss of a single IP packet low (on Ethernet). Then 3 chunks per > second should be 100 chunks per second for 1 Mbps, implying we send > either 800 bytes (2 ints per range) or 400 bytes (1 bin) as overhead, > worst case. For 10 neighbours this means 64 and 32 kbps, or 6% and 3% > respectively. > > > > Now, two things: 1) an optimized implementation of range lists would > > encode single-element ranges with a single integer, so the overhead > > would be identical to that of bins (i.e., 1.5%); 2) we're talking > > about the worst case which is extremely unlikely to happen... it > would > > be interesting to do the average case analysis for the [P+1,P+W] > > interval. > > > > As argued before, I assume data will be requested in blocks of chunks, > in particular on UDP with 1K chunks, which are a power of 2, e.g. 32K. > We can align these requests on power-2 boundaries such that we need > just > 1 bin to address them. With ranges we always need 2 ints, as we're > denoting a block of chunks. > > With this block assumption, in the worst case, an update is (100K/block > size) ranges. So e.g. 3 ranges for 32 K, taking either 2 or 1 int to > encode, and thus implying 2 kbps and 1 kbps for 10 neighbours, or 0.2 > and 0.1% overhead. Less for larger block sizes. > > In conclusion, if we send map updates instead of the full map, the > absolute overhead of pushing chunk availability is low. Relative > overhead can still be 100% and bins give a prettier one-unit design ;o) > > CU, > Arno --_000_320C4182454E96478DC039F2C481987204EB2FBE81MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Yes, a quick simulation would shed some light on the average case. Now we n= eed to find the time to do it. :-)

Fabio

 =

From: zhangyunfei [mailto:zhangyunfei@chinamobile.= com]
Sent: mercredi 16 mai 2012 03:52
To: Picconi Fabi= o; arno@cs.vu.nl
Cc: ppsp
Subject: Re: RE: Proposal to = resolve Issue 10 + 13

 

Hi Fabio, Arno and all,

<= div>

=      I h= ave a thought on how to discuss the average case. Please discuss to see if = it works.

     We may find in some measurement work to see the distribution of the chunk= s in the buffer (maybe in different phase, there are different distribution= s, e.g., the beginning, the normal play, a= fter dragging, but I am not sure). In this case, the problem Fabio proposed= is solved and we can get an analysis of the two schemes.=

 

BR

Yunfei

 

zhangyunfei

 

From: Picconi Fabio=

Date: 2012-05-15 21:04=

To: <= a href=3D"mailto:arno@cs.vu.nl">arno@cs.vu.nl

S= ubject: RE: Proposal to resolve Issue = 10 + 13

I'm&nbs= p;not sure&nbs= p;I follow&nbs= p;you.

 

First, I assumed three chunks per<= /span> second be= cause there is a p= aper that suggests that <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>this is a good value [1]. But the actual chunk rate does not change the calculation&n= bsp;(more chunksper seconds means both=  more bins and more ranges).

 

Second, if you use ranges, <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>sending an update to inform the reception of&nbs= p;an entire&nb= sp;32K block&n= bsp;(i.e., 32&= nbsp;1K chunks) takes twointegers with=  range lists, or one integer usin= g bins. I= f you hav= e three b= locks per second, that means 6 integers per second per neighbor, instead&= nbsp;of 3&nbs= p;integers per=  second perneighbor. In<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> both cases the overhead is negligi= ble.

 

=

= In the absence of = an average case analysis&nbs= p;(i.e., where=  the buffercontains lots=  of holes) showing that= bins are= better t= han range lists, and given the negligible overhead&nbs= p;of both&nbs= p;solutions in=  the worst and best case, I=  would go=  for the&= nbsp;simpler solution, i.e., range lists.

 

Fabio

&= nbsp;

[1] Size Does Matter (in <= /span>P2P Live <= /span>Streaming). N.&= nbsp;Hegde, F.=  Mathieu and D. Perino. In Algotel'09 and also Inria Tech= nical report #7032, 2009.

 

 

 

<= div>

=  

> -----Original Message-----

> From:=  Arno Bakker [mailto:arno= @cs.vu.nl]

> Sent: mardi 15 mai 2012 09:55

<= /div>

<= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>> To: <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>Picconi Fabio

<= /div>

<= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>> Cc: <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>zhangyunfei; ppsp<= /p>

> Subject:&nbs= p;Re: Proposal=  to resolveIssue 10+ 13

> 

> Hi Fabio and all

> =

> On 14/05/2012 17:= 52, Picconi Fabio wrote:

 >

&g= t; > T= aking W=3D30 seconds and = 3 chunks = per second, 4 bytes per integer, <= /span>and

> > 1 <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>buffer map per second to 10 = neighbors, range&nbs= p;list requires ~ 30

> kbps

> > in the = worst case vs. ~ <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>15 kbps for bins. <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>For a 1 Mbps stream, that's

 > a 3% o= verhead instead = of 1.5%, = which I <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>don't think is that big a

<= div>

= > deal.

>= ; >

> 

> IMHO, the calculation shou= ld be som= ewhat different. It now <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>assumes we

> send the complete 30 second map every second. I'd <= /span>say it is more likely

> that we = download at approx. the <= /span>bitrate so&nbs= p;we have&nbs= p;only 1&nbs= p;seconds worth

> of&nbs= p;updates to&n= bsp;the map&nb= sp;to send.&nb= sp;I.e. 3&nbs= p;chunks in&nb= sp;your example.This

>&n= bsp;means less=  overhead.

> 

> <= /span>With UDP <= /span>as a transport, chunk&nb= sp;size is&nbs= p;preferably 1K to keep=  the impact<= /span>

> of&nbs= p;the loss&nbs= p;of a single IP <= /span>packet low&nbs= p;(on Ethernet).Then 3=  chunks per<= /span>

> second=  should be 100 chunks per second for 1Mbps, implying we send

> either 800 bytes<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> (2 ints per range)=  or 400 bytes (1 bin) as overhead,

><= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> worst case. For 10=  neighbours this= means 64= and 32 kbps, or 6% and 3%

><= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> respectively.

> 

> 

>&nbs= p;> Now,&nb= sp;two things:=  1) an&nb= sp;optimized implementation<= /span> of rang= e lists w= ould

> >= encode s= ingle-element ranges with a single integer,&nb= sp;so the&nbs= p;overhead

>&nbs= p;> would&n= bsp;be identicalto that of bins=  (i.e., 1.5%); 2) we're talking

><= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> > about the worst case which is extremel= y unlikely  happen... <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>it

> = would

> >= ; be inte= resting to  the = average case analysis for the [P+1,P+W]

> > interval.

> >

> 

> = As argued before, I  data will be requested in blocks of chunks,

> in particular <= /span>on UDP with 1K chunks, which&nbs= p;are a <= /span>power of <= /span>2, e.g. 32K.

> We can <= span style=3D'font-size:10.5pt;font-family:"Microsoft YaHei","serif";color:= navy'>align these requests on power-2 boundariessuch that we need<= /span>

> just

> 1 bin to address them.&nbs= p;With ranges&= nbsp;we always=  need 2&n= bsp;ints, as&n= bsp;we're

>&nbs= p;denoting a&n= bsp;block of&n= bsp;chunks.

>&nb= sp;

> With this block assumption,&= nbsp;in the&nb= sp;worst case,=  an update is (100K/block

> size) ranges. So<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> e.g. 3 ranges for<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> 32 K, taking either 2 or 1 int to

>&nbs= p;encode, and&= nbsp;thus implying 2 kbpsand 1&= nbsp;kbps for&= nbsp;10 neighbours, or 0.2=

> and&n= bsp;0.1% overhead. Less for larger block sizes.

><= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> 

>&n= bsp;In conclusion, if we send map updates instead of the<= span style=3D'font-size:10.5pt;font-family:"Times New Roman","serif";color:= navy'> full map,=  the

>absolute overhead of pushing<= /span> chunk ava= ilability is low. Relative

> overhead can still be 100% and bins give a = prettier one-unit&nbs= p;design ;o)

> 

> CU,

<= div>

= >      Arno

= --_000_320C4182454E96478DC039F2C481987204EB2FBE81MOPESMBX01eut_-- From a.bakker@vu.nl Wed May 16 00:13:46 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 BFF4621F85F1 for ; Wed, 16 May 2012 00:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[AWL=1.384, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU956QWLTAZE for ; Wed, 16 May 2012 00:13:46 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6AD21F8613 for ; Wed, 16 May 2012 00:13:45 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 16 May 2012 09:13:44 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.283.3; Wed, 16 May 2012 09:13:43 +0200 Message-ID: <4FB353E6.5060401@cs.vu.nl> Date: Wed, 16 May 2012 09:14:46 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Picconi Fabio References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl> <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> <4FB20BD5.6010607@cs.vu.nl> <320C4182454E96478DC039F2C481987204EB26E7D4@MOPESMBX01.eu.thmulti.com> In-Reply-To: <320C4182454E96478DC039F2C481987204EB26E7D4@MOPESMBX01.eu.thmulti.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 07:13:46 -0000 On 15/05/2012 15:04, Picconi Fabio wrote: > I'm not sure I follow you. > > First, I assumed three chunks per second because there is a paper > that suggests that this is a good value [1]. But the actual chunk > rate does not change the calculation (more chunks per seconds means > both more bins and more ranges). > Hi I think we agree that the overhead of both solutions is small even worst case. I just added a level of detail to make sure we didn't miss anything given UDP induces a chunksize of 1K, to be transmitted in groups for bandwidth utilization and optimal sharing (your ref). The only difference is that I prefer bins such that there is a single unit in the whole system that works conveniently with Merkle hash trees. CU, Arno From sprevidi@cisco.com Wed May 16 01:29:11 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 6695B21F86D7 for ; Wed, 16 May 2012 01:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.637 X-Spam-Level: X-Spam-Status: No, score=-106.637 tagged_above=-999 required=5 tests=[AWL=3.962, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBAmOoN4F8AK for ; Wed, 16 May 2012 01:29:10 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFD121F865E for ; Wed, 16 May 2012 01:29:10 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4G8S4Wk000999 for ; Wed, 16 May 2012 10:28:05 +0200 (CEST) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-163.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-163.cisco.com [10.147.74.163]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q4G8S0oZ006044; Wed, 16 May 2012 10:28:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-2022-jp From: stefano previdi X-Priority: 3 (Normal) In-Reply-To: <201205160940568032028@chinamobile.com> Date: Wed, 16 May 2012 10:28:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <411766FC-5937-4083-9807-26641CAFFAB3@cisco.com> References: <2012050316123830359558@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB1CD469@MOPESMBX01.eu.thmulti.com> <2012051511103610737239@chinamobile.com>, <731E43BD-66FD-4306-88FA-A65518810FB4@ieee.org> <201205160940568032028@chinamobile.com> To: zhangyunfei X-Mailer: Apple Mail (2.1257) Cc: 'Rui Cruz' , ppsp Subject: Re: [ppsp] tickets for IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 08:29:11 -0000 On May 16, 2012, at 3:40 AM, zhangyunfei wrote: > Thanks Rui for the clarification. I would suggest to sperate the base = specification and the extensions with two different drafts for two = reasons: > 1) It would be much easier to get consensus on the base draft since = its scope is highly limited. In this way the progress will be earlier to = achieve. > 2) We see many similar operations in IETF drafts practices which may = be proved to be an efficient way in IETF circle. yes, different drafts is the best choice so we can move them on=20 autonomously from each other. The goal, at this stage, is to reach=20 consensus on the base specification in a reasonable time. Extensions will go in separate documentS (i.e.: we may need more=20 than one extension document). It's a common IETF practice with proven efficiency. s. > =20 > BR > Yunfei=20 > =20 > zhangyunfei > =20 > From: Rui Cruz > Date: 2012-05-15 18:59 > To: ppsp > CC: Rui Cruz; Picconi Fabio; Yingjie Gu(yingjie); zhangyunfei = (zhangyunfei@chinamobile.com) > Subject: Re: [ppsp] tickets for IETF 83 > Hi, >=20 > On Ticket #4: The FIND use case can perfectly be seen as Fabio = described, i.e., "to find peers subject to attribute constraints" in = order to speed up discovery, i.e., may be used in special situations = only, therefore, the overhead to the tracker can be considered minimal. >=20 > On Ticket #5: The tracker protocol proposal is being split in a base = specification and extensions. We do not see the need for "additional = messages e.g.,reconnect and rejoin)" as this type of "action" is = perfectly solved with the already proposed messages. This is the case = of the new semantic for the CONNECT message with implicit JOINs which = behaves as a re-CONNECT with re-JOINs. >=20 > We would appreciate an advise from the chairs on splitting the tracker = protocol proposal in a base specification and extensions. Should it be = done with two different draft documents or with a single document where = the extensions are clearly separate to an Annex?? >=20 > Regards, >=20 > Rui Cruz > rui.cruz@ieee.org >=20 > IST/INESC-ID/INOV - Lisbon, Portugal > __________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp >=20 > On 15/05/2012, at 04:10, zhangyunfei wrote: >=20 >> Hi Rui and Yingjie, >> Would you please confirm the ticket #4 for Paris meeting? >> For ticket #5, I am fine with Fabio's proposal. >> =20 >> BR >> Yunfei >> =20 >> zhangyunfei >> =20 >> From: Picconi Fabio >> Date: 2012-05-14 20:04 >> To: zhangyunfei; ppsp >> Subject: RE: [ppsp] tickets for IETF 83 >> Hi, >> Somme comments: >> Ticket #1 (chunk addressing mechanism). See my email send today. >> Ticket #2. I can=1B$B!G=1B(Bt remember what this was about. :-) >> Ticket #3 (secure PEX): I think that we can stick to a simple PEX = mechanism that can be augmented by an optional secure algorithm. In = addition to the solution proposed by Arno, there is a simple mechanism = described by Jesi et al. [1]. >> Ticket #4 (FIND use case). I don=1B$B!G=1B(Bt recall exactly the = details of this issue. If it=1B$B!G=1B(Bs only motivating a request to = the tracker to find peers subject to attribute constraints, then finding = peers with a similar upload capacity (to speed up the discovery phase) = is already a good motivation. >> Ticket #5 (additional messages). I think the proponents of these = messages should describe the use cases where these messages can be = useful. >> Cheers, >> Fabio >> [1] G.P. Jesi, A. Montresor, and M. van Steen. Secure Peer Sampling. = In Computer Networks, 2010. >> =20 >> From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf = Of zhangyunfei >> Sent: jeudi 3 mai 2012 10:13 >> To: ppsp >> Subject: [ppsp] tickets for IETF 83 >> =20 >> Hi all, >> I have summarized an initial tickets list for IETF 83 meeting. = Please review it and actions on these tickets are expected. Thanks. >> =20 >> BR >> Yunfei &Stefano >> = --------------------------------------------------------------------------= --------------------------------- >> Peer protocol: >> Ticket #1=1B$B!'=1B(BPost and discuss the alternative proposal = besides MHT in peer protocol (Proposal 10+13), list intervals (Tradeoff = among complexity / overhead / efficiency / implementation) and check = gaps. [Martin=1B$B!$=1B(BYunfei, Fabio, Lichun] >> This ticket is partly solved. Simple nature number addressing and = ranged expression on chunk availability. The analysis and comparison is = ongoing. I'd suggest to have a deadline for the resolution time after = discussing with Stefano, i.e., May 26th from now on to make the = decision in the WG level. >> =20 >> Ticket #2=1B$B!'=1B(BDiscuss the possible =1B$B!H=1B(B"state-building = attacks" attack on peers.[Martin](related Proposal 26) >> Martin, Do you still have concerns on this? If nobody shows up, we = propose to close this ticket. >> =20 >> Ticket #3: Discuss the Membership certificates impact on the = tracker=1B$B!G=1B(Bs workload.[Fabio](related to Proposal 17+20) >> =20 >> Tracker protocol: >> Ticket#4: Specify the FIND use case and reduce the overhead to the = tracker.[Martin,Yunfei=1B$B!$=1B(BFabio=1B$B!$=1B(BRichardo] >> Ticket#5: Discuss concrete use cases of additional messages if there = are(e.g.,reconnect and rejoin) , and conclude the basic messages and = optional ones in tracker protocol. [Mark, Fabio] >> We propose to the tracker protocol authors to address their tickets = with a splitting of their proposal: >> . base spec >> . additional options. >> =20 >> Survey >> Ticket#6: Call for reviewers for survey draft, and maybe P2P = streaming providers=1B$B!G=1B(B contribution on updating the draft. =20 >> =20 >> zhangyunfei >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >=20 >=20 From zhangyunfei@chinamobile.com Wed May 16 20:30:52 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 A61AF11E808F for ; Wed, 16 May 2012 20:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.345 X-Spam-Level: X-Spam-Status: No, score=-96.345 tagged_above=-999 required=5 tests=[AWL=2.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hggUUnrg8GCY for ; Wed, 16 May 2012 20:30:51 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BCCBB11E8089 for ; Wed, 16 May 2012 20:30:49 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 9D42AE433; Thu, 17 May 2012 11:30:46 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 23148F3B6; Thu, 17 May 2012 11:30:44 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012051711304091-6735 ; Thu, 17 May 2012 11:30:40 +0800 Date: Thu, 17 May 2012 11:30:35 +0800 From: zhangyunfei To: "Picconi Fabio" , "arno@cs.vu.nl" References: <2012041216393612240745@chinamobile.com>, <4F869775.6010007@cs.vu.nl> <2012041815001581776052@chinamobile.com>, <4F8E6DCE.90101@cs.vu.nl> <20120418183444961415101@chinamobile.com> <320C4182454E96478DC039F2C481987204EB1CD37A@MOPESMBX01.eu.thmulti.com> <4FB0FAEA.8010504@cs.vu.nl> <320C4182454E96478DC039F2C481987204EB26DD39@MOPESMBX01.eu.thmulti.com> <4FB20BD5.6010607@cs.vu.nl>, <320C4182454E96478DC039F2C481987204EB26E7D4@MOPESMBX01.eu.thmulti.com> <2012051609521522582017@chinamobile.com>, <320C4182454E96478DC039F2C481987204EB2FBE81@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012051711303503621122@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-17 11:30:41, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-05-17 11:30:45 Content-Type: multipart/alternative; boundary="----=_001_NextPart874113331685_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18910.004 X-TM-AS-Result: No--41.394-7.0-31-10 X-imss-scan-details: No--41.394-7.0-31-10;No--41.394-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: ppsp Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 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, 17 May 2012 03:30:52 -0000 ------=_001_NextPart874113331685_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" WWVzLiBJdCB3b3VsZCBiZSBncmVhdCBpZiB3ZSBjYW4gaGF2ZSBhIGNvbmNsdXNpb24gYmVmb3Jl IG5leHQgbmV4dCB3ZWVrLCB3aGVuIGlzIG91ciBwcm9wb3NlZCBkZWFkbGluZSBmb3IgZGlzY3Vz c2luZyB0aGUgY2h1bmsgYWRkcmVzc2luZyBpc3N1ZS4gIA0KDQpCUg0KWXVuZmVpDQoNCg0KDQoN CnpoYW5neXVuZmVpDQoNCkZyb206IFBpY2NvbmkgRmFiaW8NCkRhdGU6IDIwMTItMDUtMTYgMTQ6 NTMNClRvOiB6aGFuZ3l1bmZlaTsgYXJub0Bjcy52dS5ubA0KQ0M6IHBwc3ANClN1YmplY3Q6IFJF OiBSRTogUHJvcG9zYWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEzDQpZZXMsIGEgcXVpY2sgc2lt dWxhdGlvbiB3b3VsZCBzaGVkIHNvbWUgbGlnaHQgb24gdGhlIGF2ZXJhZ2UgY2FzZS4gTm93IHdl IG5lZWQgdG8gZmluZCB0aGUgdGltZSB0byBkbyBpdC4gOi0pDQpGYWJpbw0KIA0KRnJvbTogemhh bmd5dW5mZWkgW21haWx0bzp6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb21dIA0KU2VudDogbWVy Y3JlZGkgMTYgbWFpIDIwMTIgMDM6NTINClRvOiBQaWNjb25pIEZhYmlvOyBhcm5vQGNzLnZ1Lm5s DQpDYzogcHBzcA0KU3ViamVjdDogUmU6IFJFOiBQcm9wb3NhbCB0byByZXNvbHZlIElzc3VlIDEw ICsgMTMNCiANCkhpIEZhYmlvLCBBcm5vIGFuZCBhbGwsDQogICAgIEkgaGF2ZSBhIHRob3VnaHQg b24gaG93IHRvIGRpc2N1c3MgdGhlIGF2ZXJhZ2UgY2FzZS4gUGxlYXNlIGRpc2N1c3MgdG8gc2Vl IGlmIGl0IHdvcmtzLg0KICAgICBXZSBtYXkgZmluZCBpbiBzb21lIG1lYXN1cmVtZW50IHdvcmsg dG8gc2VlIHRoZSBkaXN0cmlidXRpb24gb2YgdGhlIGNodW5rcyBpbiB0aGUgYnVmZmVyIChtYXli ZSBpbiBkaWZmZXJlbnQgcGhhc2UsIHRoZXJlIGFyZSBkaWZmZXJlbnQgZGlzdHJpYnV0aW9ucywg ZS5nLiwgdGhlIGJlZ2lubmluZywgdGhlIG5vcm1hbCBwbGF5LCBhZnRlciBkcmFnZ2luZywgYnV0 IEkgYW0gbm90IHN1cmUpLiBJbiB0aGlzIGNhc2UsIHRoZSBwcm9ibGVtIEZhYmlvIHByb3Bvc2Vk IGlzIHNvbHZlZCBhbmQgd2UgY2FuIGdldCBhbiBhbmFseXNpcyBvZiB0aGUgdHdvIHNjaGVtZXMu DQogDQpCUg0KWXVuZmVpDQogDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KIA0KRnJvbTogUGljY29uaSBG YWJpbw0KRGF0ZTogMjAxMi0wNS0xNSAyMTowNA0KVG86IGFybm9AY3MudnUubmwNCkNDOiB6aGFu Z3l1bmZlaTsgcHBzcA0KU3ViamVjdDogUkU6IFByb3Bvc2FsIHRvIHJlc29sdmUgSXNzdWUgMTAg KyAxMw0KSSdtIG5vdCBzdXJlIEkgZm9sbG93IHlvdS4NCiANCkZpcnN0LCBJIGFzc3VtZWQgdGhy ZWUgY2h1bmtzIHBlciBzZWNvbmQgYmVjYXVzZSB0aGVyZSBpcyBhIHBhcGVyIHRoYXQgc3VnZ2Vz dHMgdGhhdCB0aGlzIGlzIGEgZ29vZCB2YWx1ZSBbMV0uIEJ1dCB0aGUgYWN0dWFsIGNodW5rIHJh dGUgZG9lcyBub3QgY2hhbmdlIHRoZSBjYWxjdWxhdGlvbiAobW9yZSBjaHVua3MgcGVyIHNlY29u ZHMgbWVhbnMgYm90aCBtb3JlIGJpbnMgYW5kIG1vcmUgcmFuZ2VzKS4NCiANClNlY29uZCwgaWYg eW91IHVzZSByYW5nZXMsIHNlbmRpbmcgYW4gdXBkYXRlIHRvIGluZm9ybSB0aGUgcmVjZXB0aW9u IG9mIGFuIGVudGlyZSAzMksgYmxvY2sgKGkuZS4sIDMyIDFLIGNodW5rcykgdGFrZXMgdHdvIGlu dGVnZXJzIHdpdGggcmFuZ2UgbGlzdHMsIG9yIG9uZSBpbnRlZ2VyIHVzaW5nIGJpbnMuIElmIHlv dSBoYXZlIHRocmVlIGJsb2NrcyBwZXIgc2Vjb25kLCB0aGF0IG1lYW5zIDYgaW50ZWdlcnMgcGVy IHNlY29uZCBwZXIgbmVpZ2hib3IsIGluc3RlYWQgb2YgMyBpbnRlZ2VycyBwZXIgc2Vjb25kIHBl ciBuZWlnaGJvci4gSW4gYm90aCBjYXNlcyB0aGUgb3ZlcmhlYWQgaXMgbmVnbGlnaWJsZS4NCiAN CkluIHRoZSBhYnNlbmNlIG9mIGFuIGF2ZXJhZ2UgY2FzZSBhbmFseXNpcyAoaS5lLiwgd2hlcmUg dGhlIGJ1ZmZlciBjb250YWlucyBsb3RzIG9mIGhvbGVzKSBzaG93aW5nIHRoYXQgYmlucyBhcmUg YmV0dGVyIHRoYW4gcmFuZ2UgbGlzdHMsIGFuZCBnaXZlbiB0aGUgbmVnbGlnaWJsZSBvdmVyaGVh ZCBvZiBib3RoIHNvbHV0aW9ucyBpbiB0aGUgd29yc3QgYW5kIGJlc3QgY2FzZSwgSSB3b3VsZCBn byBmb3IgdGhlIHNpbXBsZXIgc29sdXRpb24sIGkuZS4sIHJhbmdlIGxpc3RzLg0KIA0KRmFiaW8N CiANClsxXSBTaXplIERvZXMgTWF0dGVyIChpbiBQMlAgTGl2ZSBTdHJlYW1pbmcpLiBOLiBIZWdk ZSwgRi4gTWF0aGlldSBhbmQgRC4gUGVyaW5vLiBJbiBBbGdvdGVsJzA5IGFuZCBhbHNvIElucmlh IFRlY2huaWNhbCByZXBvcnQgIzcwMzIsIDIwMDkuDQogDQogDQogDQogDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFybm8gQmFra2VyIFttYWlsdG86YXJub0Bjcy52dS5u bF0NCj4gU2VudDogbWFyZGkgMTUgbWFpIDIwMTIgMDk6NTUNCj4gVG86IFBpY2NvbmkgRmFiaW8N Cj4gQ2M6IHpoYW5neXVuZmVpOyBwcHNwDQo+IFN1YmplY3Q6IFJlOiBQcm9wb3NhbCB0byByZXNv bHZlIElzc3VlIDEwICsgMTMNCj4gDQo+IEhpIEZhYmlvIGFuZCBhbGwNCj4gDQo+IE9uIDE0LzA1 LzIwMTIgMTc6NTIsIFBpY2NvbmkgRmFiaW8gd3JvdGU6DQo+ID4NCj4gPiBUYWtpbmcgVz0zMCBz ZWNvbmRzIGFuZCAzIGNodW5rcyBwZXIgc2Vjb25kLCA0IGJ5dGVzIHBlciBpbnRlZ2VyLCBhbmQN Cj4gPiAxIGJ1ZmZlciBtYXAgcGVyIHNlY29uZCB0byAxMCBuZWlnaGJvcnMsIHJhbmdlIGxpc3Qg cmVxdWlyZXMgfiAzMA0KPiBrYnBzDQo+ID4gaW4gdGhlIHdvcnN0IGNhc2UgdnMuIH4gMTUga2Jw cyBmb3IgYmlucy4gRm9yIGEgMSBNYnBzIHN0cmVhbSwgdGhhdCdzDQo+ID4gYSAzJSBvdmVyaGVh ZCBpbnN0ZWFkIG9mIDEuNSUsIHdoaWNoIEkgZG9uJ3QgdGhpbmsgaXMgdGhhdCBiaWcgYQ0KPiBk ZWFsLg0KPiA+DQo+IA0KPiBJTUhPLCB0aGUgY2FsY3VsYXRpb24gc2hvdWxkIGJlIHNvbWV3aGF0 IGRpZmZlcmVudC4gSXQgbm93IGFzc3VtZXMgd2UNCj4gc2VuZCB0aGUgY29tcGxldGUgMzAgc2Vj b25kIG1hcCBldmVyeSBzZWNvbmQuIEknZCBzYXkgaXQgaXMgbW9yZSBsaWtlbHkNCj4gdGhhdCB3 ZSBkb3dubG9hZCBhdCBhcHByb3guIHRoZSBiaXRyYXRlIHNvIHdlIGhhdmUgb25seSAxIHNlY29u ZHMgd29ydGgNCj4gb2YgdXBkYXRlcyB0byB0aGUgbWFwIHRvIHNlbmQuIEkuZS4gMyBjaHVua3Mg aW4geW91ciBleGFtcGxlLiBUaGlzDQo+IG1lYW5zIGxlc3Mgb3ZlcmhlYWQuDQo+IA0KPiBXaXRo IFVEUCBhcyBhIHRyYW5zcG9ydCwgY2h1bmsgc2l6ZSBpcyBwcmVmZXJhYmx5IDFLIHRvIGtlZXAg dGhlIGltcGFjdA0KPiBvZiB0aGUgbG9zcyBvZiBhIHNpbmdsZSBJUCBwYWNrZXQgbG93IChvbiBF dGhlcm5ldCkuIFRoZW4gMyBjaHVua3MgcGVyDQo+IHNlY29uZCBzaG91bGQgYmUgMTAwIGNodW5r cyBwZXIgc2Vjb25kIGZvciAxIE1icHMsIGltcGx5aW5nIHdlIHNlbmQNCj4gZWl0aGVyIDgwMCBi eXRlcyAoMiBpbnRzIHBlciByYW5nZSkgb3IgNDAwIGJ5dGVzICgxIGJpbikgYXMgb3ZlcmhlYWQs DQo+IHdvcnN0IGNhc2UuIEZvciAxMCBuZWlnaGJvdXJzIHRoaXMgbWVhbnMgNjQgYW5kIDMyIGti cHMsIG9yIDYlIGFuZCAzJQ0KPiByZXNwZWN0aXZlbHkuDQo+IA0KPiANCj4gPiBOb3csIHR3byB0 aGluZ3M6IDEpIGFuIG9wdGltaXplZCBpbXBsZW1lbnRhdGlvbiBvZiByYW5nZSBsaXN0cyB3b3Vs ZA0KPiA+IGVuY29kZSBzaW5nbGUtZWxlbWVudCByYW5nZXMgd2l0aCBhIHNpbmdsZSBpbnRlZ2Vy LCBzbyB0aGUgb3ZlcmhlYWQNCj4gPiB3b3VsZCBiZSBpZGVudGljYWwgdG8gdGhhdCBvZiBiaW5z IChpLmUuLCAxLjUlKTsgMikgd2UncmUgdGFsa2luZw0KPiA+IGFib3V0IHRoZSB3b3JzdCBjYXNl IHdoaWNoIGlzIGV4dHJlbWVseSB1bmxpa2VseSB0byBoYXBwZW4uLi4gaXQNCj4gd291bGQNCj4g PiBiZSBpbnRlcmVzdGluZyB0byBkbyB0aGUgYXZlcmFnZSBjYXNlIGFuYWx5c2lzIGZvciB0aGUg W1ArMSxQK1ddDQo+ID4gaW50ZXJ2YWwuDQo+ID4NCj4gDQo+IEFzIGFyZ3VlZCBiZWZvcmUsIEkg YXNzdW1lIGRhdGEgd2lsbCBiZSByZXF1ZXN0ZWQgaW4gYmxvY2tzIG9mIGNodW5rcywNCj4gaW4g cGFydGljdWxhciBvbiBVRFAgd2l0aCAxSyBjaHVua3MsIHdoaWNoIGFyZSBhIHBvd2VyIG9mIDIs IGUuZy4gMzJLLg0KPiBXZSBjYW4gYWxpZ24gdGhlc2UgcmVxdWVzdHMgb24gcG93ZXItMiBib3Vu ZGFyaWVzIHN1Y2ggdGhhdCB3ZSBuZWVkDQo+IGp1c3QNCj4gMSBiaW4gdG8gYWRkcmVzcyB0aGVt LiBXaXRoIHJhbmdlcyB3ZSBhbHdheXMgbmVlZCAyIGludHMsIGFzIHdlJ3JlDQo+IGRlbm90aW5n IGEgYmxvY2sgb2YgY2h1bmtzLg0KPiANCj4gV2l0aCB0aGlzIGJsb2NrIGFzc3VtcHRpb24sIGlu IHRoZSB3b3JzdCBjYXNlLCBhbiB1cGRhdGUgaXMgKDEwMEsvYmxvY2sNCj4gc2l6ZSkgcmFuZ2Vz LiBTbyBlLmcuIDMgcmFuZ2VzIGZvciAzMiBLLCB0YWtpbmcgZWl0aGVyIDIgb3IgMSBpbnQgdG8N Cj4gZW5jb2RlLCBhbmQgdGh1cyBpbXBseWluZyAyIGticHMgYW5kIDEga2JwcyBmb3IgMTAgbmVp Z2hib3Vycywgb3IgMC4yDQo+IGFuZCAwLjElIG92ZXJoZWFkLiBMZXNzIGZvciBsYXJnZXIgYmxv Y2sgc2l6ZXMuDQo+IA0KPiBJbiBjb25jbHVzaW9uLCBpZiB3ZSBzZW5kIG1hcCB1cGRhdGVzIGlu c3RlYWQgb2YgdGhlIGZ1bGwgbWFwLCB0aGUNCj4gYWJzb2x1dGUgb3ZlcmhlYWQgb2YgcHVzaGlu ZyBjaHVuayBhdmFpbGFiaWxpdHkgaXMgbG93LiBSZWxhdGl2ZQ0KPiBvdmVyaGVhZCBjYW4gc3Rp bGwgYmUgMTAwJSBhbmQgYmlucyBnaXZlIGEgcHJldHRpZXIgb25lLXVuaXQgZGVzaWduIDtvKQ0K PiANCj4gQ1UsDQo+ICAgICAgQXJubw== ------=_001_NextPart874113331685_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Yes. It would be great if we can have a conclusion before next next we= ek,=20 when is our proposed deadline for discussing the chunk addressing issue.&nb= sp;=20
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-05-16 14:53
To: zhangyunfei; arno@cs.vu.nl
CC: ppsp
Subject: RE: RE: Proposal to resolve Issue 10 +=20 13

Yes,=20 a quick simulation would shed some light on the average case. Now we need t= o=20 find the time to do it. :-)

Fabio

 

From:<= /B> zhangyunfei = [mailto:zhangyunfei@chinamobile.com]
Sent: mercredi 16 mai 2012 = 03:52
To: Picconi Fabio; arno@cs.vu.nl
Cc:=20 ppsp
Subject: Re: RE: Proposal to resolve Issue 10 +=20 13

 

Hi=20 Fabio, Arno and all,

    =20 I have=20 a thought on how to discuss the average case. Please discuss to see if it=20 works.

    =20 We may find in some measurement work to see the distribution of the chunks = in=20 the buffer (maybe in different phase, there are different distributions, e.= g.,=20 the beginning, the normal play, after=20 dragging, but I am not sure). In this case, the problem Fabio proposed is s= olved=20 and we can get an analysis of the two schemes.

 

BR

Yunfei

 

zhangyunfei

 

= From: Picconi=20 Fabio

= Date: 2012-05-15 21:04

= To: arno@cs.vu.nl

= CC: zhangyunfei; ppsp

= Subject: RE:=20 Proposal to resolve Issue 10 + 13

I'm not sure I follow you.

 

First, I assumed three chunks per second because there is a paper that suggests that this is a good value [1]. But the actual chunk rate does not change the calculation (more chunks per seconds means both more bins and more ranges).

 

Second, if you use ranges, sending an update to inform the reception of an entire 32K block (i.e., 32 1K chunks) takes two integers with range lists, or one integer using bins. If you have three blocks per second, that means 6 integers per second per neighbor, instead of 3 integers per second per neighbor. In both cases the overhead is negligible.

 

In the absence of an average case analysis (i.e., where the buffer contains lots of holes) showing that bins are better than range lists, and given the negligible overhead of both solutions in the worst and best case, I would go for the simpler solution, i.e., range lists.

 

Fabio

 

[1] Size Does Matter (in P2P Live Streaming). N. Hegde, F. Mathieu and D. Perino. In Algotel'09 and also Inria Technical report #7032, 2009.

 

 

 

 

> -----Original Message-----

> From: Arno Bakker [mailto:arno@cs.vu.nl]

> Sent: mardi 15 mai 2012 09:55

> To: Picconi Fabio

> Cc: zhangyunfei; ppsp

> Subject: Re: Proposal to resolve Issue 10 + 13

> 

> Hi Fabio and all

> 

> On 14/05/2012 17:52, Picconi Fabio wrote:

> >

> > Taking W=3D30 seconds and 3 chunks per second, 4 bytes per integer, and

> > 1 buffer map per second to 10 neighbors, range list requires ~ 30

> kbps

> > in the worst case vs. ~ 15 kbps for bins. For a 1 Mbps stream, that's

> > a 3% overhead instead of 1.5%, which I don't think is that big a

> deal.

> >

> 

> IMHO, the calculation should be somewhat different. It now assumes we

> send the complete 30 second map every second. I'd say it is more likely

> that we download at approx. the bitrate so we have only 1 seconds worth

> of updates to the map to send. I.e. 3 chunks in your example. This

> means less overhead.

> 

> With UDP as a transport, chunk size is preferably 1K to keep the impact

> of the loss of a single IP packet low (on Ethernet). Then 3 chunks per

> second should be 100 chunks per second for 1 Mbps, implying we send

> either 800 bytes (2 ints per range) or 400 bytes (1 bin) as overhead,

> worst case. For 10 neighbours this means 64 and 32 kbps, or 6% and 3%

> respectively.

> 

> 

> > Now, two things: 1) an optimized implementation of range lists would

> > encode single-element ranges with a single integer, so the overhead

> > would be identical to that of bins (i.e., 1.5%); 2) we're talking

> > about the worst case which is extremely unlikely to happen... it

> would

> > be interesting to do the average case analysis for the [P+1,P+W]

> > interval.

> >

> 

> As argued before, I assume data will be requested in blocks of chunks,

> in particular on UDP with 1K chunks, which are a power of 2, e.g. 32K.

> We can align these requests on power-2 boundaries such that we need

> just

> 1 bin to address them. With ranges we always need 2 ints, as we're

> denoting a block of chunks.

> 

> With this block assumption, in the worst case, an update is (100K/block

> size) ranges. So e.g. 3 ranges for 32 K, taking either 2 or 1 int to

> encode, and thus implying 2 kbps and 1 kbps for 10 neighbours, or 0.2

> and 0.1% overhead. Less for larger block sizes.

> 

> In conclusion, if we send map updates instead of the full map, the

> absolute overhead of pushing chunk availability is low. Relative

> overhead can still be 100% and bins give a prettier one-unit design ;o)

> 

> CU,

>      Arno

= ------=_001_NextPart874113331685_=------