From internet-drafts@ietf.org Sun Jul 1 19:37: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 8B7E011E814F; Sun, 1 Jul 2012 19:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 0bqrOZGNbhU8; Sun, 1 Jul 2012 19:37:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC16211E8134; Sun, 1 Jul 2012 19:37:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120702023727.13326.50344.idtracker@ietfa.amsl.com> Date: Sun, 01 Jul 2012 19:37:27 -0700 X-Mailman-Approved-At: Sun, 01 Jul 2012 19:41:10 -0700 Cc: ppsp@ietf.org Subject: [ppsp] I-D Action: draft-ietf-ppsp-problem-statement-09.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 02:37:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer to Peer Streaming Protocol Working G= roup of the IETF. Title : Problem Statement and Requirements of Peer-to-Peer Strea= ming Protocol (PPSP) Author(s) : Yunfei Zhang Ning Zong Filename : draft-ietf-ppsp-problem-statement-09.txt Pages : 26 Date : 2012-07-01 Abstract: Peer-to-Peer (P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes a Peer to Peer Streaming Protocol (PPSP) including tracker and peer signaling, and discusses the design scope, requirements and uses cases of PPSP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ppsp-problem-statement-09 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-problem-statement-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangyunfei@chinamobile.com Sun Jul 1 19:49:33 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 2548021F886F for ; Sun, 1 Jul 2012 19:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.479 X-Spam-Level: X-Spam-Status: No, score=-98.479 tagged_above=-999 required=5 tests=[AWL=0.144, 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 8DvzjQJfWXaD for ; Sun, 1 Jul 2012 19:49:32 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3473421F886A for ; Sun, 1 Jul 2012 19:49:32 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 4447BF017; Mon, 2 Jul 2012 10:49:35 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 3A2C0F016; Mon, 2 Jul 2012 10:49:35 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012070210493284-16969 ; Mon, 2 Jul 2012 10:49:32 +0800 Date: Mon, 2 Jul 2012 10:49:31 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012070210493120580239@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-02 10:49:32, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-02 10:49:34, Serialize complete at 2012-07-02 10:49:34 Content-Type: multipart/alternative; boundary="----=_001_NextPart021350865753_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19012.004 X-TM-AS-Result: No--12.735-7.0-31-10 X-imss-scan-details: No--12.735-7.0-31-10;No--12.735-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] reqeusting review and comments on draft-ietf-ppsp-problem-statement-09.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 02:49:33 -0000 This is a multi-part message in MIME format. ------=_001_NextPart021350865753_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgZm9sa3MsDQogICAgQWNjb3JkaW5nIHRvIHRoZSBJRVNHIHJldmlldyBjb21tZW50cyBieSBE YXZpZCwgd2UgdXBkYXRlIGEgbmV3IHZlcnNpb24gb2YgdGhlIHByb2JsZW0gc3RhdGVtZW50cyBh bmQgcmVxdWVzdCByZXZpZXcgYW5kIGNvbW1lbnRzLiBQbGVhc2UgY2hlY2sgdGhlIGZvbGxvd2lu ZyBsaW5rIGZvciB0aGUgZGV0YWlsczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC4NClRoZSBtYWluIGNoYW5nZXMgYXJl Og0KMSkgTGFyZ2VseSBzaG9ydGVuIHRoZSBwYWdlcyBvbiB0aGUgZXhwbGFuYXRvcnkgZGVzY3Jp cHRpb25zIG9uIHRoZSBwcmluY2lwbGVzIG9mIHAycCBzdHJlYW1pbmcgYWxsIHRoZSBkb2N1bWVu dCwgZXNwLiBpbiBzZWN0aW9uIDEgYW5kICA0Lg0KMikgUmVjb25zdHJ1Y3Qgc2VjdGlvbiAzIHdp dGggbW9yZSBjbGVhciBhbmQgZXhwbGljaXQgcHJvYmxlbXMuDQozKSBBZGQgYSBuZXcgc3Vic2Vj dGlvbiA0LjEgYWNjb3JkaW5nIHRvIERhdmlkJ3MgY29tbWVudHMgdG8gZWxhYm9yYXRlIHRoZSB0 cmFja2VyIHByb3RvY29sIGFuZCBwZWVyIHByb3RvY29sJ3MgcHJvYmxlbXMoIGkuZS4sIGRlc2ln biBzcGFjZSkuIA0KDQpUaGFua3MuDQoNCkJSDQpZdW5mZWkgDQoNCg0KDQoNCnpoYW5neXVuZmVp DQoNCkZyb206IGludGVybmV0LWRyYWZ0cw0KRGF0ZTogMjAxMi0wNy0wMiAxMDozNw0KVG86IGkt ZC1hbm5vdW5jZQ0KQ0M6IHBwc3ANClN1YmplY3Q6IFtwcHNwXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQtMDkudHh0DQoNCkEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBQZWVyIHRvIFBlZXIgU3RyZWFt aW5nIFByb3RvY29sIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNClRpdGxlICAgICAgICAg ICA6IFByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJlbWVudHMgb2YgUGVlci10by1QZWVyIFN0 cmVhbWluZyBQcm90b2NvbCAoUFBTUCkNCkF1dGhvcihzKSAgICAgICA6IFl1bmZlaSBaaGFuZw0K ICAgICAgICAgICAgICAgICAgICAgICAgICBOaW5nIFpvbmcNCkZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0wOS50eHQNClBhZ2VzICAgICAgICAgICA6 IDI2DQpEYXRlICAgICAgICAgICAgOiAyMDEyLTA3LTAxDQoNCkFic3RyYWN0Og0KICAgUGVlci10 by1QZWVyIChQMlAgZm9yIHNob3J0KSBzdHJlYW1pbmcgc3lzdGVtcyBzaG93IG1vcmUgYW5kIG1v cmUNCiAgIHBvcHVsYXJpdHkgaW4gY3VycmVudCBJbnRlcm5ldCB3aXRoIHByb3ByaWV0YXJ5IHBy b3RvY29scy4gVGhpcw0KICAgZG9jdW1lbnQgaWRlbnRpZmllcyBwcm9ibGVtcyBvZiB0aGUgcHJv cHJpZXRhcnkgcHJvdG9jb2xzLCBwcm9wb3NlcyBhDQogICBQZWVyIHRvIFBlZXIgU3RyZWFtaW5n IFByb3RvY29sIChQUFNQKSBpbmNsdWRpbmcgdHJhY2tlciBhbmQgcGVlcg0KICAgc2lnbmFsaW5n LCBhbmQgZGlzY3Vzc2VzIHRoZSBkZXNpZ24gc2NvcGUsIHJlcXVpcmVtZW50cyBhbmQgdXNlcw0K ICAgY2FzZXMgb2YgUFBTUC4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudA0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2 ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0wOQ0KDQpBIGRpZmYgZnJvbSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTA5DQoNCg0KSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart021350865753_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi folks,
    According to the IESG review comments by David, we= =20 update a new version of the problem statements and=20 request review and comments. Please check the following lin= k for=20 the details:
https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement.<= /DIV>
The main changes are:
1) Largely shorten the pages on the explanatory description= s on=20 the principles of p2p streaming all the document, esp. in section 1 a= nd=20  4.
2) Reconstruct section 3 with more clear and explicit problems.<= /DIV>
3) Add a new subsection 4.1 according to David's comments to elaborat= e the=20 tracker protocol and peer protocol's problems( i.e., design=20 space). 
 
Thanks.
 
BR
Yunfei 
 
zhangyunfei
 
From: internet-drafts
Date: 2012-07-02 10:37
To: i-d-announce
CC: ppsp
Subject: [ppsp] I-D Action:=20 draft-ietf-ppsp-problem-statement-09.txt
 
A New Internet-Draft is available from = the on-line Internet-Drafts directories.
 This draft is a work item of = ;the Peer to Peer Streaming Protocol Working=  Group of the IETF.
 
Title          &nbs= p;: Problem Statement and Requirements of Pe= er-to-Peer Streaming Protocol (PPSP)
Author(s)       : Yunfei = ;Zhang
           &nb= sp;            = ;  Ning Zong
Filename        : draft-= ietf-ppsp-problem-statement-09.txt
Pages          &nbs= p;: 26
Date           = ; : 2012-07-01
 
Abstract:
   Peer-to-Peer (P2P for short) st= reaming systems show more and more
   popularity in current Internet = with proprietary protocols. This
   document identifies problems of = ;the proprietary protocols, proposes a
   Peer to Peer Streaming Protocol=  (PPSP) including tracker and peer
   signaling, and discusses the de= sign scope, requirements and uses
   cases of PPSP.
 
 
The IETF datatracker status page for th= is draft is:
https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement
 
There's also a htmlized version available&nb= sp;at:
http://tools.ietf.org/html/draft-ietf-ppsp-problem-statement-09
 
A diff from previous version is availab= le at:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ppsp-problem-statemen= t-09
 
 
Internet-Drafts are also available by anonym= ous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart021350865753_=------ From rachel.huang@huawei.com Sun Jul 8 17:51: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 53CB621F87EE for ; Sun, 8 Jul 2012 17:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 tagged_above=-999 required=5 tests=[AWL=1.051, 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 Sa1Uz4BxB2kf for ; Sun, 8 Jul 2012 17:51:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1B93321F87ED for ; Sun, 8 Jul 2012 17:51:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHO78991; Sun, 08 Jul 2012 20:51:29 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 17:51:28 -0700 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 17:51:13 -0700 Received: from SZXEML539-MBX.china.huawei.com ([169.254.6.214]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 08:51:07 +0800 From: "Huangyihong (Rachel)" To: "ppsp@ietf.org" Thread-Topic: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-00.txt Thread-Index: AQHNXLTc1YrvO9fQQU+INGj7lKcFGpcgICSg Date: Mon, 9 Jul 2012 00:51:07 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB3AF5DACD@szxeml539-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-00.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 00:51:08 -0000 SGkgZm9sa3MsDQoNClRoZSBmaXJzdCB2ZXJzaW9uIG9mIFBQU1AgZXh0ZW5kZWQgdHJhY2tlciBw cm90b2NvbCBoYXMganVzdCBiZWVuIHVwbG9hZGVkLiBUaGlzIGRyYWZ0IGlzIGNyZWF0ZWQgYmFz ZWQgb24gdGhlIGNvbnNlbnN1cyBvZiBsYXN0IG1lZXRpbmcgb24gdGhlIHNwbGl0IG9mIHRyYWNr ZXIgcHJvdG9jb2wuIFBsZWFzZSByZXZpZXcgdGhpcyBkb2N1bWVudCBhbmQgZHJvcCB5b3VyIGNv bW1lbnRzIGhlcmUuDQpNYW55IHRoYW5rcyENCg0KUmFjaGVsDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBKdWx5IDA4LCAyMDEyIDEwOjUzIEFN DQpUbzogSHVhbmd5aWhvbmcgKFJhY2hlbCkNCkNjOiBydWkuY3J1ekBpZWVlLm9yZzsgbWFyaW8u bnVuZXNAaW5vdi5wdDsgam9hby5zaWx2YUBpbm92LnB0DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90b2Nv bC0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaHVhbmctcHBzcC1leHRl bmRlZC10cmFja2VyLXByb3RvY29sLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBSYWNoZWwgSHVhbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4N Cg0KRmlsZW5hbWU6CSBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wN ClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFBQU1AgVHJhY2tlciBQcm90b2NvbC0tRXh0ZW5kZWQg UHJvdG9jb2wgKFBQU1AtVFAvMS4xKQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDctMDgNCldHIElE OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAzNQ0KVVJMOiAgICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1odWFuZy1w cHNwLWV4dGVuZGVkLXRyYWNrZXItcHJvdG9jb2wtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVhbmctcHBzcC1leHRlbmRlZC10 cmFja2VyLXByb3RvY29sDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMA0KDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIGV4dGVuZGVkIFBlZXItdG8t UGVlciBTdHJlYW1pbmcgUHJvdG9jb2wNCiAgIC0gVHJhY2tlciBQcm90b2NvbCAoUFBTUC1UUC8x LjEpLCBhIG5ldyBleHRlbnNpb24gcHJvdG9jb2wNCiAgIGNvbXBsZW1lbnRpbmcgdGhlIGJhc2lj IGNvcmUgbWVzc2FnZXMgYW5kIHVzYWdlcyBzcGVjaWZpZWQgaW4NCiAgIFBQU1A9VFAvMS4wICBm b3IgdGhlIGV4Y2hhbmdlIG9mIG1ldGEgaW5mb3JtYXRpb24gYmV0d2VlbiB0cmFja2Vycw0KICAg YW5kIHBlZXJzLCBzdWNoIGFzIGluaXRpYWwgb2ZmZXIvcmVxdWVzdCBvZiBwYXJ0aWNpcGF0aW9u IGluDQogICBtdWx0aW1lZGlhIGNvbnRlbnQgc3RyZWFtaW5nLCBjb250ZW50IGluZm9ybWF0aW9u LCBwZWVyIGxpc3RzIGFuZA0KICAgcmVwb3J0cyBvZiBhY3Rpdml0eSBhbmQgc3RhdHVzLiBJdCBl eHRlbmRzIFBQU1AtVFAvMS4wIHRvIGluY2x1ZGUgbmV3DQogICBvcHRpb25hbCBtZXNzYWdlcyBw cm92aWRpbmcgZ3JhbnVsYXIgY29udHJvbHMgYW5kIHVzYWdlcyBpbiB0aGUNCiAgIGNvbW11bmlj YXRpb25zIGJldHdlZW4gcGVlciBhbmQgdHJhY2tlci4gVGhlIGV4dGVuc2lvbiBwcm90b2NvbCBp cw0KICAgcmV0cm8tY29tcGF0aWJsZSB3aXRoIFBQU1AtVFAvMS4wLg0KDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From rachel.huang@huawei.com Sun Jul 8 17:54: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 59BBB21F875D for ; Sun, 8 Jul 2012 17:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=0.701, 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 fJ-IxXDzERr3 for ; Sun, 8 Jul 2012 17:54:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A513B21F873E for ; Sun, 8 Jul 2012 17:54:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHV78969; Sun, 08 Jul 2012 20:55:15 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 17:55:14 -0700 Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 17:55:14 -0700 Received: from SZXEML539-MBX.china.huawei.com ([169.254.6.214]) by szxeml418-hub.china.huawei.com ([10.82.67.157]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 08:55:10 +0800 From: "Huangyihong (Rachel)" To: "ppsp@ietf.org" Thread-Topic: [ppsp] New Version Notification for draft-huang-ppsp-extended-tracker-protocol-00.txt Thread-Index: AQHNXLTc1YrvO9fQQU+INGj7lKcFGpcgICSggAAAhYA= Date: Mon, 9 Jul 2012 00:55:10 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB3AF5DADD@szxeml539-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.163] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-00.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 00:54:52 -0000 SGkgZm9sa3MsDQoNClNvcnJ5IGZvciByZXNlbmRpbmcgdGhpcyBtYWlsLiBJIGZvcmdvdCB0byBp bmNsdWRlIHRoZSAiW3Bwc3BdIiB0YWcgaW4gdGhlIHN1YmplY3QuIA0KDQpCZXN0IFJlZ2FyZHMh DQpSYWNoZWwNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSHVhbmd5aWhv bmcgKFJhY2hlbCkgDQpTZW50OiBNb25kYXksIEp1bHkgMDksIDIwMTIgODo1MSBBTQ0KVG86ICdw cHNwQGlldGYub3JnJw0KU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtaHVhbmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29sLTAwLnR4dA0KDQpIaSBm b2xrcywNCg0KVGhlIGZpcnN0IHZlcnNpb24gb2YgUFBTUCBleHRlbmRlZCB0cmFja2VyIHByb3Rv Y29sIGhhcyBqdXN0IGJlZW4gdXBsb2FkZWQuIFRoaXMgZHJhZnQgaXMgY3JlYXRlZCBiYXNlZCBv biB0aGUgY29uc2Vuc3VzIG9mIGxhc3QgbWVldGluZyBvbiB0aGUgc3BsaXQgb2YgdHJhY2tlciBw cm90b2NvbC4gUGxlYXNlIHJldmlldyB0aGlzIGRvY3VtZW50IGFuZCBkcm9wIHlvdXIgY29tbWVu dHMgaGVyZS4NCk1hbnkgdGhhbmtzIQ0KDQpSYWNoZWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBTdW5kYXksIEp1bHkgMDgsIDIwMTIgMTA6NTMgQU0NClRv OiBIdWFuZ3lpaG9uZyAoUmFjaGVsKQ0KQ2M6IHJ1aS5jcnV6QGllZWUub3JnOyBtYXJpby5udW5l c0Bpbm92LnB0OyBqb2FvLnNpbHZhQGlub3YucHQNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtaHVhbmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29sLTAw LnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVk LXRyYWNrZXItcHJvdG9jb2wtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFJhY2hlbCBIdWFuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpG aWxlbmFtZToJIGRyYWZ0LWh1YW5nLXBwc3AtZXh0ZW5kZWQtdHJhY2tlci1wcm90b2NvbA0KUmV2 aXNpb246CSAwMA0KVGl0bGU6CQkgUFBTUCBUcmFja2VyIFByb3RvY29sLS1FeHRlbmRlZCBQcm90 b2NvbCAoUFBTUC1UUC8xLjEpDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wNy0wOA0KV0cgSUQ6CQkg SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDM1DQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1YW5nLXBwc3At ZXh0ZW5kZWQtdHJhY2tlci1wcm90b2NvbC0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1odWFuZy1wcHNwLWV4dGVuZGVkLXRyYWNr ZXItcHJvdG9jb2wNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaHVhbmctcHBzcC1leHRlbmRlZC10cmFja2VyLXByb3RvY29sLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgZXh0ZW5kZWQgUGVlci10by1QZWVy IFN0cmVhbWluZyBQcm90b2NvbA0KICAgLSBUcmFja2VyIFByb3RvY29sIChQUFNQLVRQLzEuMSks IGEgbmV3IGV4dGVuc2lvbiBwcm90b2NvbA0KICAgY29tcGxlbWVudGluZyB0aGUgYmFzaWMgY29y ZSBtZXNzYWdlcyBhbmQgdXNhZ2VzIHNwZWNpZmllZCBpbg0KICAgUFBTUD1UUC8xLjAgIGZvciB0 aGUgZXhjaGFuZ2Ugb2YgbWV0YSBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRyYWNrZXJzDQogICBhbmQg cGVlcnMsIHN1Y2ggYXMgaW5pdGlhbCBvZmZlci9yZXF1ZXN0IG9mIHBhcnRpY2lwYXRpb24gaW4N CiAgIG11bHRpbWVkaWEgY29udGVudCBzdHJlYW1pbmcsIGNvbnRlbnQgaW5mb3JtYXRpb24sIHBl ZXIgbGlzdHMgYW5kDQogICByZXBvcnRzIG9mIGFjdGl2aXR5IGFuZCBzdGF0dXMuIEl0IGV4dGVu ZHMgUFBTUC1UUC8xLjAgdG8gaW5jbHVkZSBuZXcNCiAgIG9wdGlvbmFsIG1lc3NhZ2VzIHByb3Zp ZGluZyBncmFudWxhciBjb250cm9scyBhbmQgdXNhZ2VzIGluIHRoZQ0KICAgY29tbXVuaWNhdGlv bnMgYmV0d2VlbiBwZWVyIGFuZCB0cmFja2VyLiBUaGUgZXh0ZW5zaW9uIHByb3RvY29sIGlzDQog ICByZXRyby1jb21wYXRpYmxlIHdpdGggUFBTUC1UUC8xLjAuDQoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From zhangyunfei@chinamobile.com Mon Jul 9 00:09:20 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 ED40E11E808F for ; Mon, 9 Jul 2012 00:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.324 X-Spam-Level: X-Spam-Status: No, score=-97.324 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj2Rm5+sPm5w for ; Mon, 9 Jul 2012 00:09:20 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53511E8095 for ; Mon, 9 Jul 2012 00:09:12 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 30918E6DD; Mon, 9 Jul 2012 15:09:35 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 28480E6AD; Mon, 9 Jul 2012 15:09:35 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012070915093405-36249 ; Mon, 9 Jul 2012 15:09:34 +0800 Date: Mon, 9 Jul 2012 15:09:30 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012070915093065758058@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-09 15:09:34, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-09 15:09:35, Serialize complete at 2012-07-09 15:09:35 Content-Type: multipart/alternative; boundary="----=_001_NextPart200441814056_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19028.005 X-TM-AS-Result: No--11.720-7.0-31-10 X-imss-scan-details: No--11.720-7.0-31-10;No--11.720-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Call for request of time slot in IETF 84 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 07:09:21 -0000 This is a multi-part message in MIME format. ------=_001_NextPart200441814056_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgYWxsLA0KICAgIEZvciB0aGUgYXV0aG9ycyB3aG8gYXJlIGludGVyZXN0ZWQgaW4gcHJlc2Vu dGluZyB0aGUgZHJhZnRzIGluIElFVEYgODQsIHBsZWFzZSBsZXQgU3RlZmFubyBhbmQgbWUga25v dyBhYm91dCB0aGUgdGltZSBzbG90cyB5b3UgcmVxdWVzdCBhbmQgdGhlIHRpdGxlL3ByZXNlbnRl ciBpbmZvcm1hdGlvbiBiZWZvcmUgSnVseSAxNXRoIGFuZCBzZW5kIHlvdXIgc2xpZGVzIGJlZm9y ZSBKdWx5IDI3dGguIFRoYW5rcy4NCg0KQlINClN0ZWZhbm8gYW5kIFl1bmZlaQ0KDQoNCg0KDQp6 aGFuZ3l1bmZlaQ== ------=_001_NextPart200441814056_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi all,
    For the authors who are interested in presenting t= he=20 drafts in IETF 84, please let Stefano and me know about the time slot= s you=20 request and the title/presenter information before=20 July 15th and send your slides before July=20 27th. Thanks.
 
BR
Stefano and Yunfei
 
zhangyunfei
------=_001_NextPart200441814056_=------ From guyingjie@huawei.com Mon Jul 9 02:04:50 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 DE91121F87D3 for ; Mon, 9 Jul 2012 02:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.885 X-Spam-Level: X-Spam-Status: No, score=-100.885 tagged_above=-999 required=5 tests=[AWL=-3.335, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, 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 wXH-Sksw3hlb for ; Mon, 9 Jul 2012 02:04:50 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 48C7A21F87C9 for ; Mon, 9 Jul 2012 02:04:50 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW01696; Mon, 09 Jul 2012 05:05:14 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 02:03:05 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 02:03:05 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.86]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Mon, 9 Jul 2012 17:03:02 +0800 From: "Guyingjie (Yingjie)" To: zhangyunfei , ppsp Thread-Topic: [ppsp] Call for request of time slot in IETF 84 Thread-Index: AQHNXaH84+LcSSxzsUmYezrKKsxlepcgp/ZQ Date: Mon, 9 Jul 2012 09:03:01 +0000 Message-ID: References: <2012070915093065758058@chinamobile.com> In-Reply-To: <2012070915093065758058@chinamobile.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.122.45] Content-Type: multipart/alternative; boundary="_000_A27496C192613C44A82D819E1B98DB57340304E4SZXEML511MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] =?gb2312?b?tPC4tDogIENhbGwgZm9yIHJlcXVlc3Qgb2YgdGltZSBz?= =?gb2312?b?bG90IGluIElFVEYgODQ=?= 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, 09 Jul 2012 09:04:51 -0000 --_000_A27496C192613C44A82D819E1B98DB57340304E4SZXEML511MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgZm9yIGEgdGltZSBzbG90IGZvcg0KVGl0bGU6IGRyYWZ0 LWNydXotcHBzcC1iYXNlLXRyYWNrZXItcHJvdG9jb2wuDQpQcmVzZW50ZXI6IFlpbmdqaWUgR3UN ClRpbWU6IDIwIG1pbnMuDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkJlc3QgUmVnYXJkcw0KR3UgWWluZ2ppZQ0KDQq3orz+yMs6IHBwc3AtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SB6aGFuZ3l1bmZlaQ0Kt6LL zcqxvOQ6IDIwMTLE6jfUwjnI1SDA1sDWMTU6MDkNCsrVvP7IyzogcHBzcA0K1vfM4jogW3Bwc3Bd IENhbGwgZm9yIHJlcXVlc3Qgb2YgdGltZSBzbG90IGluIElFVEYgODQNCg0KSGkgYWxsLA0KICAg IEZvciB0aGUgYXV0aG9ycyB3aG8gYXJlIGludGVyZXN0ZWQgaW4gcHJlc2VudGluZyB0aGUgZHJh ZnRzIGluIElFVEYgODQsIHBsZWFzZSBsZXQgU3RlZmFubyBhbmQgbWUga25vdyBhYm91dCB0aGUg dGltZSBzbG90cyB5b3UgcmVxdWVzdCBhbmQgdGhlIHRpdGxlL3ByZXNlbnRlciBpbmZvcm1hdGlv biBiZWZvcmUgSnVseSAxNXRoIGFuZCBzZW5kIHlvdXIgc2xpZGVzIGJlZm9yZSBKdWx5IDI3dGgu IFRoYW5rcy4NCg0KQlINClN0ZWZhbm8gYW5kIFl1bmZlaQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kemhhbmd5dW5mZWkNCg== --_000_A27496C192613C44A82D819E1B98DB57340304E4SZXEML511MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I would like to request for a ti= me slot for

Title: draft-cruz-ppsp-base-trac= ker-protocol.

Presenter: Yingjie Gu=

Time: 20 mins.

 

 

 <= /p>

 

 

Best Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED = zhangyunfei
=B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA7=D4=C2<= span lang=3D"EN-US">9=C8=D5 =C0=D6=C0=D615:09
=CA=D5=BC=FE=C8=CB: ppsp
=D6=F7=CC=E2: [ppsp] Call for request of time slot in IETF 84<= /p>

 

Hi all,

    For the authors who are interested in prese= nting the drafts in IETF 84, please let Stefano and me know about the time slots you request and the title/presenter information before July 15th and send your slides before July 27th. Thanks.

 

BR

Stefano and Yunfei

 

zhangyunfei

--_000_A27496C192613C44A82D819E1B98DB57340304E4SZXEML511MBSchi_-- From zhangyunfei@chinamobile.com Mon Jul 9 02:23: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 9C8D121F85B8 for ; Mon, 9 Jul 2012 02:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.903 X-Spam-Level: X-Spam-Status: No, score=-93.903 tagged_above=-999 required=5 tests=[AWL=-4.434, BAYES_20=-0.74, 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 9c1xeXkJxELc for ; Mon, 9 Jul 2012 02:23:03 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EF47021F8804 for ; Mon, 9 Jul 2012 02:23:01 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A23C8E762; Mon, 9 Jul 2012 17:23:26 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 93383E760; Mon, 9 Jul 2012 17:23:26 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012070917232448-41354 ; Mon, 9 Jul 2012 17:23:24 +0800 Date: Mon, 9 Jul 2012 17:23:21 +0800 From: zhangyunfei To: "Yingjie Gu(yingjie)" , ppsp References: <2012070915093065758058@chinamobile.com>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012070917232155908174@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-09 17:23:24, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-09 17:23:26, Serialize complete at 2012-07-09 17:23:26 Content-Type: multipart/alternative; boundary="----=_001_NextPart400825437074_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19028.005 X-TM-AS-Result: No--26.971-7.0-31-10 X-imss-scan-details: No--26.971-7.0-31-10;No--26.971-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] =?gb2312?b?u9i4tDogtPC4tDogIENhbGwgZm9yIHJlcXVlc3Qgb2Yg?= =?gb2312?b?dGltZSBzbG90IGluIElFVEYgODQ=?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 09:23:04 -0000 This is a multi-part message in MIME format. ------=_001_NextPart400825437074_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgWWluZ2ppZSwNCiAgICBXZSBoYXZlIHJlY2VpdmVkIHRoZSByZXF1ZXN0LiBUaGFua3MuDQoN CkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0Kt6K8/sjLo7ogR3V5aW5namllIChZ aW5namllKQ0Kt6LLzcqxvOSjuiAyMDEyLTA3LTA5IDE3OjAzDQrK1bz+yMujuiB6aGFuZ3l1bmZl aTsgcHBzcA0K1vfM4qO6ILTwuLQ6IFtwcHNwXSBDYWxsIGZvciByZXF1ZXN0IG9mIHRpbWUgc2xv dCBpbiBJRVRGIDg0DQpJIHdvdWxkIGxpa2UgdG8gcmVxdWVzdCBmb3IgYSB0aW1lIHNsb3QgZm9y IA0KVGl0bGU6IGRyYWZ0LWNydXotcHBzcC1iYXNlLXRyYWNrZXItcHJvdG9jb2wuDQpQcmVzZW50 ZXI6IFlpbmdqaWUgR3UNClRpbWU6IDIwIG1pbnMuIA0KIA0KIA0KIA0KIA0KIA0KDQoNCg0KQmVz dCBSZWdhcmRzDQpHdSBZaW5namllDQogDQq3orz+yMs6IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SB6aGFuZ3l1bmZlaQ0Kt6LLzcqxvOQ6 IDIwMTLE6jfUwjnI1SDA1sDWMTU6MDkNCsrVvP7IyzogcHBzcA0K1vfM4jogW3Bwc3BdIENhbGwg Zm9yIHJlcXVlc3Qgb2YgdGltZSBzbG90IGluIElFVEYgODQNCiANCkhpIGFsbCwNCiAgICBGb3Ig dGhlIGF1dGhvcnMgd2hvIGFyZSBpbnRlcmVzdGVkIGluIHByZXNlbnRpbmcgdGhlIGRyYWZ0cyBp biBJRVRGIDg0LCBwbGVhc2UgbGV0IFN0ZWZhbm8gYW5kIG1lIGtub3cgYWJvdXQgdGhlIHRpbWUg c2xvdHMgeW91IHJlcXVlc3QgYW5kIHRoZSB0aXRsZS9wcmVzZW50ZXIgaW5mb3JtYXRpb24gYmVm b3JlIEp1bHkgMTV0aCBhbmQgc2VuZCB5b3VyIHNsaWRlcyBiZWZvcmUgSnVseSAyN3RoLiBUaGFu a3MuDQogDQpCUg0KU3RlZmFubyBhbmQgWXVuZmVpDQogDQoNCg0KDQp6aGFuZ3l1bmZlaQ== ------=_001_NextPart400825437074_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Yingjie,
    We have received the request. Thanks.
 
BR
Yunfei
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Guyingjie=20 (Yingjie)
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-07-09 17:03
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei; ppsp
=D6=F7=CC=E2=A3=BA =B4=F0=B8=B4: [ppsp] Call for request = of time slot in IETF=20 84

I would like to request for a time slot for

Title: draft-cruz-ppsp-base-tracker-protocol.

Presenter: Yingjie Gu

Time: 20 mins.

 

 

 

 

 

Best Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED zhangyunfei
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C29=C8=D5 =C0=D6=C0=D6<= SPAN=20 lang=3DEN-US>15:09
=CA=D5=BC=FE=C8=CB:=20 ppsp
=D6=F7=CC=E2: [ppsp] Call=20 for request of time slot in IETF 84

 

Hi=20 all,

    For the authors who are interested in pres= enting=20 the drafts in IETF 84, please let Stefano and me know about the time = slots=20 you request and the title/presenter information before July=20 15th and=20 send your slides before July=20 27th. Thanks.

 

BR

Stefano and Yunfei

 

zhangyunfei

------=_001_NextPart400825437074_=------ From yang.r.yang@gmail.com Mon Jul 9 22:22:39 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 C3DD411E8117; Mon, 9 Jul 2012 22:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D43dnHE1Env; Mon, 9 Jul 2012 22:22:39 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C43C011E80F6; Mon, 9 Jul 2012 22:22:38 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1707301obb.31 for ; Mon, 09 Jul 2012 22:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=D87iwea/XVb4pasH2W9pia4sx0awppRYHWa2iwgYUgc=; b=Fno9HxOlEdPXANB3HYEe5K6q1o+sEypIjB5WpjDy+cGiEbdQsDPkZVnU/xnxPjlY0e TVz6+SesQ5ABaJZEAb8mC3Ud9NlxProSZ9KlUVnymU10u5/DFupOYKC3e/9s5+hJTsMT UDDTsRPyyITTy0kzpHzloJkDPhc4B6J6e3ASVHwPSgOgeQ6GgTAjrTnnH9Beh7qpXscc im5pRvcMyMwjUDupn2lUjzDoPgIsUL/EvD0Ud4A6Sc3NGM/ChsqeXK+ysJT62dBZLdaI h2WNZZXLvdXZaSq5jukVUjT3JOOEd+7WU8Isz/s6V4PfkslWbwN0XQxT5ecQpTYTWAiV HQEQ== MIME-Version: 1.0 Received: by 10.182.85.8 with SMTP id d8mr12228009obz.70.1341897785291; Mon, 09 Jul 2012 22:23:05 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Mon, 9 Jul 2012 22:23:05 -0700 (PDT) In-Reply-To: <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com> References: <20120703003402663560214@gmail.com> <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com> <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com> <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com> <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> <4FF82C0E.5020809@cs.tcd.ie> <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd> <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com> Date: Tue, 10 Jul 2012 13:23:05 +0800 X-Google-Sender-Auth: XHtBnwLIxGBVn17PzxTx3VEvnZs Message-ID: From: "Y. Richard Yang" To: Peng Zhang Content-Type: multipart/alternative; boundary=f46d04479559d1356104c472ec52 Cc: "ppsp@ietf.org" , "DECADE@ietf.org" , Dirk Kutscher Subject: Re: [ppsp] [decade] Object naming in -req and -arch 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, 10 Jul 2012 05:22:39 -0000 --f46d04479559d1356104c472ec52 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peng, Dirk, I am cc'ing the ppsp list as well. You raised a good point on the distinction between one object and a sequence of objects. To generalize, we can discuss even a set of objects (no ordering), and a set of equivalence objects (dynamic streaming that interleaves different resolutions). Your arguement against MTH is higher overhead in the general case (end to end arguements). How much exactly is the overhead? Decade may benefit from the analysis from ppsp. Since streaming is considered as the main app, how much overhead if decade has to build on top? Thanks! Richard On Tuesday, July 10, 2012, Peng Zhang wrote: > Hi Dirk and all, > > I agree that the NI specification meets the basic requirement of DECADE > (without optimization on "early name generation"). > > As for the Merkle Hash Tree, or MTH, it is a integrity-assurance method > for a sequence of objects. It is critical to the PPSP protocol. But i > wonder wether we should incorporate it in our design: > > First, DECADE is targeted at general content distribution applications, > and for applications other than P2P streaming, there is no great value of > using Merkle Hash Tree. It may cause high overhead to these applications > due "meta data" including signatures and full hashes should be exchanged. > > Still, we can discuss more on how to better incorporate PPSP based on NI > without hurting the general application of DECADE. Thanks. > > B, > > Peng. > > > On Jul 9, 2012, at 12:35 PM, Dirk Kutscher wrote: > > Hi Peng and all,**** > ** ** > Thanks for the discussion.**** > ** ** > So, I think it=92s good to check the requirements and assess > draft-farrell-decade-ni accordingly. I personally that it meets the ones > you listed in your earlier message.**** > ** ** > One of the interesting features is that the NI specification defines a > common format that enables the integration of hashes (or other > cryptographic functions=92 output) into names and corresponding validatio= n > steps on nodes. The explicit signaling of the function that is actually > used allows for application-specific usage (if so needed) and for some > agility regarding crypto algorithms. A DECADE protocol specification coul= d > specify the usage of the scheme, MANDATORY to implement algorithms etc mo= re > specifically.**** > ** ** > One of the, IMO, important things that have not been discussed > sufficiently is the question about PPSP compatibility that Richard Yang > brought up.**** > ** ** > My view on this is as follows: the PPSP Merkle Hash Tree approach for > static and live content has requirements on the **object** and **meta-dat= a > ** format. For example, chunks have to carry sibling and uncle hashes. > Specifically, for live streaming with dynamic trees, chunks have to provi= de > chunk signatures (block signature, chunk position in the block, and the > digests of the sibling to the way to the root).**** > ** ** > For both static object and live streaming with > > --f46d04479559d1356104c472ec52 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peng, Dirk,

I am cc'ing the ppsp list as well. Yo= u raised a good point on the distinction between one object and a sequence = of objects. To generalize, we can discuss even a set of objects (no orderin= g), and a set of equivalence objects (dynamic streaming that interleaves di= fferent resolutions). Your arguement against MTH is higher overhead in the = general case (end to end arguements). How much exactly is the overhead? Dec= ade may benefit from the analysis from ppsp. Since streaming is considered = as the main app, how much overhead if decade has to build on top?

Thanks!

Richard

On= Tuesday, July 10, 2012, Peng Zhang wrote:
Hi Dirk and all,

I agree that the NI specification= meets the basic requirement of DECADE (without optimization on "early= name generation").=A0

As for the= Merkle Hash Tree, or MTH, it is a integrity-assurance method for a sequenc= e of objects. It is critical to the PPSP protocol. But i wonder wether we s= hould incorporate it in our design:

First, DEC= ADE is targeted at general content distribution applications, and for appli= cations other than P2P streaming, there is no great value of using Merkle H= ash Tree. It may cause high overhead to these applications due "meta d= ata" including signatures and full hashes should be exchanged.=A0

Still, we = can discuss more on how to better incorporate PPSP based on NI without hurt= ing the general application of DECADE. Thanks.

B,<= /div>

Peng.


On Jul 9, = 2012, at 12:35 PM, Dirk Kutscher wrote:

=
Hi Peng and all,
=A0
Thanks for the discussion.
=A0
So, I think it=92s good to check the requirements an= d assess draft-farrell-decade-ni accordingly. I personally that it meets th= e ones you listed in your earlier message.
=A0
One of the interesting features is that the NI specificat= ion defines a common format that enables the integration of hashes (or othe= r cryptographic functions=92 output) into names and corresponding validatio= n steps on nodes. The explicit signaling of the function that is actually u= sed allows for application-specific usage (if so needed) and for some agili= ty regarding crypto algorithms. A DECADE protocol specification could speci= fy the usage of the scheme, MANDATORY to implement algorithms etc more spec= ifically.
=A0
One of the, IMO, important things that have not been disc= ussed sufficiently is the question about PPSP compatibility that Richard Ya= ng brought up.
=A0
My view on this is as follows: the PPSP Merkle Hash Tree = approach for static and live content has requirements on the *object= * and *meta-data* format. =A0For example, chunks have to carry sibli= ng and uncle hashes. Specifically, for live streaming with dynamic trees, c= hunks have to provide chunk signatures (block signature, chunk position in = the block, and the digests of the sibling to the way to the root).
=A0
For both static object and live streaming with
--f46d04479559d1356104c472ec52-- From a.bakker@vu.nl Tue Jul 10 00:48: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 B8FE811E80C7 for ; Tue, 10 Jul 2012 00:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ha-62bU1aH+0 for ; Tue, 10 Jul 2012 00:48:42 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id B21B411E808A for ; Tue, 10 Jul 2012 00:48:41 -0700 (PDT) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 10 Jul 2012 09:49:05 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 10 Jul 2012 09:49:06 +0200 Message-ID: <4FFBDE7C.8090807@cs.vu.nl> Date: Tue, 10 Jul 2012 09:49:16 +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: <20120703003402663560214@gmail.com> <4FF2ACC3.1020004@cs.tcd.ie> <20120704160541638826251@gmail.com> <4FF4B0D5.40906@cs.tcd.ie> <20120704174022735010267@gmail.com> <4FF4B8C2.7090702@cs.tcd.ie> <20120704175739679926274@gmail.com> <4FF4BD39.7050907@cs.tcd.ie> <20120706223508854218405@gmail.com> <4FF82C0E.5020809@cs.tcd.ie> <82AB329A76E2484D934BBCA77E9F524924D0ECB1@PALLENE.office.hd> <4651C731-C630-4E8F-8FF2-697F32EBA86F@gmail.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] [decade] Object naming in -req and -arch 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, 10 Jul 2012 07:48:42 -0000 Hi all I'll try to clarify the rationale and practical overhead of the Merkle Hash Trees in PPSP. For static content, MHTs enable content integrity protection using self-certified naming. Using a hash tree instead of a single hash is useful in all situations where the content is distributed in parts (=a sequence of objects as you mention it) that are immediately used. In particular, when the parts are delivered to a higher level app upon receipt they must be integrity checked beforehand. This applies to streaming, but perhaps also to other P2P apps using DECADE. Even if parts are not immediately used, an integrity check on parts can help to improve efficiency in a P2P context. An end-to-end integrity check when the content is completely downloaded is sufficient, but for efficiency it would be nice to know if the individual parts are correct instead of finding out at the end, especially for large content. Note that Merkle Hash Trees support both partial and end-to-end integrity checks. When a peer has a copy of the content and the name of the object (=its root hash in the MHT) he can calculate the MHT from the content and compare the calculated root hash to the name. He does not need to receive any of the intermediary hashes from others, if that is not required. Which brings us to the topic of overhead. As discussed in Sec. 5.5 of http://www.ietf.org/id/draft-ietf-ppsp-peer-protocol-02.txt the size of the MHT depends on the number of chunks (objects) at the base of the tree. That number depends on the size of the chunks that are processed immediately in the P2P application. For PPSP over UDP over Ethernet these chunks are small. For other P2P apps the chunks may be bigger. How much of the MHT tree actually needs to be sent over the wire to a receiving peer depends on the download policy used. For a linear download only part of the tree needs to be transmitted, as the other part of the tree is calculated by the receiving peer while downloading. In the example in Sec. 5.5, only 7 of the 16 hashes in the tree are actually transmitted. Note that swift, the protocol on which the PPSP peer protocol is based was actually designed as a generic transport protocol, unifying regular downloads, VOD and live streaming. So it still supports efficient non-streaming download policies like BitTorrent's rarest first. In other words, its origins fits the general distribution nature of DECADE. Regards, Arno On 10/07/2012 07:23, Y. Richard Yang wrote: > Hi Peng, Dirk, > > I am cc'ing the ppsp list as well. You raised a good point on the > distinction between one object and a sequence of objects. To generalize, > we can discuss even a set of objects (no ordering), and a set of > equivalence objects (dynamic streaming that interleaves different > resolutions). Your arguement against MTH is higher overhead in the > general case (end to end arguements). How much exactly is the overhead? > Decade may benefit from the analysis from ppsp. Since streaming is > considered as the main app, how much overhead if decade has to build on top? > > Thanks! > > Richard > > On Tuesday, July 10, 2012, Peng Zhang wrote: > > Hi Dirk and all, > > I agree that the NI specification meets the basic requirement of > DECADE (without optimization on "early name generation"). > > As for the Merkle Hash Tree, or MTH, it is a integrity-assurance > method for a sequence of objects. It is critical to the PPSP > protocol. But i wonder wether we should incorporate it in our design: > > First, DECADE is targeted at general content distribution > applications, and for applications other than P2P streaming, there > is no great value of using Merkle Hash Tree. It may cause high > overhead to these applications due "meta data" including signatures > and full hashes should be exchanged. > > Still, we can discuss more on how to better incorporate PPSP based > on NI without hurting the general application of DECADE. Thanks. > From a.bakker@vu.nl Tue Jul 10 06:34:39 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 4BB1121F86C2 for ; Tue, 10 Jul 2012 06:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_05=-1.11, 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 OQSh2d1mgsES for ; Tue, 10 Jul 2012 06:34:38 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9A41E21F86BD for ; Tue, 10 Jul 2012 06:34:38 -0700 (PDT) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 10 Jul 2012 15:35:00 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 10 Jul 2012 15:35:02 +0200 Message-ID: <4FFC2F8F.1020701@cs.vu.nl> Date: Tue, 10 Jul 2012 15:35:11 +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: , <2012062809463963273025@chinamobile.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Progress on core tracker protocol? 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, 10 Jul 2012 13:34:39 -0000 Hi Rui et al after reading the base protocol -00 I have the following comments: * General: basic design now nice and simple, description still verbose. * p. 14: The Terminated state does not make much sense, IMHO and is equivalent to INIT. * p. 24: In a PeerGroup in a CONNECT a peer may provide a list of IP addresses. How to you intend to protect against malicious peers registering victim IP addresses as part of an amplification attack (see draft-ietf-ppsp-peer-protocol-02, p. 13.2.3). For IP addresses (other than the one from which the request comes from) some form of return routability check is needed. * p. 31: Seeders will need to be able to retrieve peer lists from the tracker too, in particular when the seeder is behind a NAT itself. Please adjust the spec to allow this. * p. 35: For the peer protocol's security we need the tracker to return a true random sample of the list of registered peers in a swarm (see peer draft Sec. 13.2.3). Could you make this the default behaviour, or allow a peer to request this explicitly? Regards, Arno From peer2peer@gmail.com Tue Jul 10 10:25:00 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5790021F85E3 for ; Tue, 10 Jul 2012 10:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-1.149, BAYES_00=-2.599, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mG-haPYPVe3 for ; Tue, 10 Jul 2012 10:24:59 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBCB921F85E0 for ; Tue, 10 Jul 2012 10:24:54 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so148661wgb.13 for ; Tue, 10 Jul 2012 10:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=lzqvPIJWdsUQztCvaZicJdE1g5lVV9TYh0fvUwwynFw=; b=ilNLLYZfpRURp1XBFVRx1efD4qn7G3wPImHHn+3pq+/FpaZKoEJt4P4ONfSOYzlZdn qdcfY0CixdnaNw+4bqDIAkjYRPjjFeKFzIhGHBAJrWBUXno5/xnEoyAZ7JpES7xSeI17 76xPLFPgKYllfUlGjc7JT+Cv0WOwfLVPlMRDz4SxoOAG8y3jMgBgBD0eTUh5iZx+hedJ b51RUDBfAf75qcnBPMbmjCE9BiQ98kmPrHWZ97aDs2KoCgMmT+YsCnGdZNpefyb+SXr4 iYbrTxkpM0zcAm3zCo7ZY9j/LqTX9MSaAfMfVU4Uiv5XD9fZ/cq5aHElfJmSWvqHoTD4 4zIA== MIME-Version: 1.0 Received: by 10.216.134.11 with SMTP id r11mr9459362wei.177.1341941122157; Tue, 10 Jul 2012 10:25:22 -0700 (PDT) Received: by 10.180.14.70 with HTTP; Tue, 10 Jul 2012 10:25:22 -0700 (PDT) In-Reply-To: References: <2012062809463963273025@chinamobile.com> Date: Tue, 10 Jul 2012 19:25:22 +0200 Message-ID: From: Johan Pouwelse To: ppsp Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [ppsp] Progress on core tracker protocol? 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, 10 Jul 2012 17:25:00 -0000 > Filename: draft-cruz-ppsp-base-tracker-protocol > Title: PPSP Tracker Protocol--Base Protocol (PPSP-TP/1.0) > Number of pages: 41 Excellent to see progress on the Tracker protocol front. I've reviewed this document, see below. >From draft-cruz-ppsp-base-tracker-protocol : 2) In PEER REGISTERED state, if Peer-ID is valid, the tracker processes the requested action(s) for the valid swarm information. I would argue against putting this complexity and registration process in the base protocol. It's not needed for a basic implementation, right? The base protocol now requires full xml parsing and generation. >From draft-cruz-ppsp-base-tracker-protocol : The generic format of a Request is the following: I would argue against this lack of (bandwidth) efficiency. The tracker protocol from Bittorrent has been around for 10+ years now. A few years ago they gave it an efficiency upgrade: http://bittorrent.org/beps/bep_0015.html This improvement now yields: "The protocol proposed here uses 4 packets and about 618 bytes". What is the cost in bytes of a single session for this protocol? This base protocol definition is a good step forward, but the above (non-IETF) tracker specification is 5 pages in length, the current draft is 41 pages. Trimming down to 8 pages is probably doable by both simplification (e.g. no registration, timer admin, fully stateless) of this base protocol and text reduction. For instance, the following example section should be omitted I believe, which should not reduce the value of the document. ======== The process used for media streaming distribution assumes a segment (chunk) transfer scheme whereby the original content (that can be encoded using adaptive or scalable techniques) is chopped into small segments having the following representations: 1. Adaptive - alternate representations with different qualities and bitrates; a single representation is non-adaptive; 2. Scalable description levels - multiple additive descriptions (i.e., addition of descriptions refine the quality of the video); 3. Scalable layered levels - nested dependent layers corresponding to several hierarchical levels of quality, i.e., higher enhancement layers refine the quality of the video of lower layers. 4. Scalable multiple views - views correspond to mono (2D) and stereoscopic (3D) videos, with several hierarchical levels of quality. -johan. On 29 June 2012 18:45, Rui Cruz wrote: > Hi, > > Just to inform you that the Base Tracker Protocol was published a while ago. > > A new version of I-D, draft-cruz-ppsp-base-tracker-protocol-00.txt > has been successfully submitted by Rui Santos Cruz and posted to the > IETF repository. > > Filename: draft-cruz-ppsp-base-tracker-protocol > Revision: 00 > Title: PPSP Tracker Protocol--Base Protocol (PPSP-TP/1.0) > Creation date: 2012-06-29 > WG ID: Individual Submission > Number of pages: 41 > URL: > http://www.ietf.org/internet-drafts/draft-cruz-ppsp-base-tracker-protocol-00.txt > Status: > http://datatracker.ietf.org/doc/draft-cruz-ppsp-base-tracker-protocol > Htmlized: > http://tools.ietf.org/html/draft-cruz-ppsp-base-tracker-protocol-00 > > > Abstract: > This document specifies the base Peer-to-Peer Streaming Protocol- > Tracker Protocol (PPSP-TP/1.0), an application-layer control > (signaling) protocol for the exchange of meta information between > trackers and peers. The specification outlines the architecture of > the protocol and its functionality, and describes message flows, > message processing instructions, message formats, formal syntax and > semantics. The PPSP Tracker Protocol enables cooperating peers to > form content streaming overlay networks to support near real-time > Structured Media content (audio, video, associated timed text and > metadata) delivery, such as adaptive multi-rate, layered (scalable) > and multi-view (3D), in live, time-shifted and on-demand modes. > > > 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 28/06/2012, at 02:46, zhangyunfei wrote: > > Thank Rui for the information. > P.S.: For the WG, Arno has published a new version of the peer protocol. > Please review it and publish your comments. Thanks. > > BR > Yunfei > > ________________________________ > zhangyunfei > > From: Rui Cruz > Date: 2012-06-28 00:41 > To: Johan Pouwelse > CC: Rui Cruz; ppsp > Subject: Re: [ppsp] Progress on core tracker protocol? > The PPSP-TP base Tracker Protocol draft will be published before the end of > June. > It does essentially what we had discussed during IETF 83. > The PPSP-TP Extended Tracker Protocol will bring all those more > sophisticated features, and will be published afterwards (during July) > > Cumprimentos/Regards, > Rui Cruz > > Sent from my iPad2 > > On 27/06/2012, at 16:52, Johan Pouwelse wrote: > > There was agreement for the need to create a core tracker protocol. Any > progress to report, since last month? > What do you think of my proposal below for the focus of this > really-limited-to-the-core protocol? > > > This document specifies the Peer-to-Peer Streaming Protocol--Core Tracker > Protocol (PPSP-CTP), an application-layer control protocol for facilitating > Peer-2-Peer streaming. This core protocol is limited to a peer discovery > request message and reply message. > The PPSP-CTP protocol is limited to the GET-PEERS message and subsequent > reply with a peer list. This core protocol is the only requirement for a > simple streaming service, along with the PPSP peer protocol. We refer to an > upcoming Extended Tracker Protocol for more sophisticated features. For > instance, the exchange of meta information, content information, statistics > reporting, etc. > > > -johan. > On Tuesday, June 5, 2012, Rui Cruz wrote: >> >> Hi, >> >> The Tracker Protocol is being split to a base specification draft and to >> extensions. >> We hope to have the base specification submitted in a couple of weeks. >> >> >> 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 04/06/2012, at 10:39, stefano previdi wrote: >> >> All, >> >> here are some notes i preparation of the next PPSP meeting we're >> going to have in Vancouver (http://www.ietf.org/meeting/84/index.html) >> >> 1. Peer Protocol - chunk addressing mechanism >> We currently have two proposals that I'd try to name as: >> . Bin Notation >> . Ranges >> Both proposals have been discussed in the mailing list and it >> looks to me we're NOT achieving agreement/consensus on any of >> them also due to lack of participation of the WG into the >> discussion (other than the authors of each proposal). >> >> Therefore, as of today, we can reasonably explore the >> following options: >> Option-1: We propose both solutions in the peer protocol >> specification and we define them both MANDATORY so >> to cope with interoperability issues. >> Option-2: we select one option through a WG vote (this is my >> least preferred option). >> >> Since I'd really prefer to avoid Option-2, I can only consider >> the "dual" specification. WG opinion on this is requested. >> >> Again, it would be very beneficial to the WG if current >> implementors of streaming protocols would/could speak-up and >> give their opinion (see point 4 below). >> >> 2. Peer Protocol - Security Section >> The IESG will not accept any protocol specification without a >> consistent security section (IOW: way more than what we >> currently have) although there are some arguments on whether >> we need the security mechanisms in the base spec. >> >> Arno and Zong Ning proposed some text and we need to agree/amend >> it asap so to update the draft. I'd like to close this one and >> have a new version of the draft for next meeting. >> >> 3. Tracker Protocol >> After IETF83 we agreed to split into two distinct drafts: base >> specification and optional extensions. >> >> Authors, it would be good to have a first submission before next >> meeting. >> >> 4. Survey draft. >> We need to refresh/re-submit and the chairs proposed the >> authors/editors to include a section on deployment experiences >> and more precisely on chunk addressing and security mechanisms. >> Hopefully this will also feed ongoing discussions. >> >> 5. Meeting during IETF84. >> We have requested a slot for Vancouver meeting. Anyone >> interested, please request an agenda slot asap to Yunfei or >> myself. >> >> Let us know if anything is missing. >> >> Thanks. >> >> Stefano & Yunfei >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >> >> > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > > From rui.cruz@ieee-pt.org Tue Jul 10 13:54: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 1E51C11E80D9 for ; Tue, 10 Jul 2012 13:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LOAN=2.3, 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 HYDDZgqbK1Ik for ; Tue, 10 Jul 2012 13:54:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5169D11E80BC for ; Tue, 10 Jul 2012 13:54:07 -0700 (PDT) Received: by weyu54 with SMTP id u54so55982wey.31 for ; Tue, 10 Jul 2012 13:54:36 -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:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=M6061VgTXKwr42BlBBrYjrMKJ4SGu0S3StdCkuuAjtQ=; b=AC9V+ZFyst713l9m9+MS/Qy6goM48Z9qDWbiXxtMU1yspOduGRTXGOTMpBKR85mh/Q EMso+GCeRxMN2dOoVJCmNZrpfDkI649XxorC0K5sdwx/EYwGN7Y4Da19NVkBVu5r4myw tQAQ8JKBPPGXQOVLvIpZKSnAquOmDCDcA3p1WCIFWZgL51YLLmzysE2SK8/VwZaCYfii 8Ac+EfiZxdJjzysOP7+VWOalXVn/MXXs3iaoRgoaLfIruvF9xWTrdzrCqknvhqlE+aqW HYcPgDpcF+Viu0RJ4SIWGGHcNg4+AWJnd0C0m/kYk1/GUnFzkA66tUuysAbBVW2+jpOt r6jA== Received: by 10.216.235.81 with SMTP id t59mr20430632weq.156.1341953675793; Tue, 10 Jul 2012 13:54:35 -0700 (PDT) Received: from airia.casa ([89.180.24.72]) by mx.google.com with ESMTPS id b7sm20764397wiz.9.2012.07.10.13.54.28 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 13:54:34 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_11FC74A1-6C30-476C-BB70-C76A8976006C" From: Rui Cruz In-Reply-To: Date: Tue, 10 Jul 2012 21:54:25 +0100 Message-Id: <20ED4BE8-28B1-4EAB-81DE-EAEBC5607200@ieee.org> References: <2012062809463963273025@chinamobile.com> To: Johan Pouwelse X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl18wfQnH46lmVJqu+QmfcQ4xzZeOOb5ZqI3Dzle9RkJ10r3kr4MtAvfGpREkFPt1s6Tlqm Cc: Rui Cruz , ppsp Subject: Re: [ppsp] Progress on core tracker protocol? 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, 10 Jul 2012 20:54:11 -0000 --Apple-Mail=_11FC74A1-6C30-476C-BB70-C76A8976006C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks for the comments. The PPSP protocols are for Media Streaming, not simple file sharing. The = requirements are different and so, any comparison with BitTorrent should = take that in consideration. Besides that, Media Streaming "sessions" are typically limited in time = (even a "live program" may not take longer than 24 hours?), while file = downloads in BitTorrents may take "months" to complete. > I would argue against putting this complexity and registration process > in the base protocol. > It's not needed for a basic implementation, right? Where is the complexity of registration? The peer just sends a peer-ID = that needs to be validated. If valid, the tracker registers that peer as = active. Only ONE request message is sent. In BitTorrent, besides the peer_id it also needs a connection_id to be = validated before the tracker accepts the peer, and this requires = exchanging at least two requests (connect and announce). =20 > What is the cost in bytes of a single session for this protocol? This protocol uses ONE request message (CONNECT) to get the peer = "connected", "announced" in several swarms, and, if leech, receive the = peer lists for the corresponding swarms.=20 It supports IPv4 and IPv6. The responses can be as rich as desired in = terms of information for the peer. The BitTorrent protocol over UDP does not support IPv6 (yet) and besides = the connect requires one "announce" per swarm. For a seeder joining the same number of swarms, for example 10, perhaps = the cost is not so different as each BitTorrent "announce" uses around = 64 bytes for the request.=20 BitTorrent: "connect" + 10x"announce" =3D ~656 bytes = (and 11xRTT) PPSP Tracker/1.0: CONNECT (with 10 swarms) =3D ~640 bytes (using = gzip content encoding) and 1xRTT. The same reasoning could be made for the responses, as BitTorrent would = use one response with peer list for each announce. For the same 10 = swarms, it would be 10 requests and 10 responses, while for our = protocol all that would be included in the response to the single = CONNECT request.=20 Additionally, for the same effect, it would take much longer for = BitTorrent in terms of transit time to achieve the same result. =20 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 10/07/2012, at 18:25, Johan Pouwelse wrote: >> Filename: draft-cruz-ppsp-base-tracker-protocol >> Title: PPSP Tracker Protocol--Base Protocol (PPSP-TP/1.0) >> Number of pages: 41 >=20 > Excellent to see progress on the Tracker protocol front. I've reviewed > this document, see below. >=20 > =46rom draft-cruz-ppsp-base-tracker-protocol : > 2) In PEER REGISTERED state, if Peer-ID is valid, the tracker > processes the requested action(s) for the valid swarm = information. >=20 > I would argue against putting this complexity and registration process > in the base protocol. > It's not needed for a basic implementation, right? >=20 > The base protocol now requires full xml parsing and generation. > =46rom draft-cruz-ppsp-base-tracker-protocol : > The generic format of a Request is the following: > > > > > > > > > > >=20 > I would argue against this lack of (bandwidth) efficiency. > The tracker protocol from Bittorrent has been around for 10+ years = now. > A few years ago they gave it an efficiency upgrade: > http://bittorrent.org/beps/bep_0015.html > This improvement now yields: "The protocol proposed here uses 4 > packets and about 618 bytes". >=20 > What is the cost in bytes of a single session for this protocol? >=20 > This base protocol definition is a good step forward, but the above > (non-IETF) tracker specification is 5 pages in length, the current > draft is 41 pages. > Trimming down to 8 pages is probably doable by both simplification > (e.g. no registration, timer admin, fully stateless) of this base > protocol and text reduction. > For instance, the following example section should be omitted I > believe, which should not reduce the value of the document. > =3D=3D=3D=3D=3D=3D=3D=3D > The process used for media streaming distribution assumes a segment > (chunk) transfer scheme whereby the original content (that can be > encoded using adaptive or scalable techniques) is chopped into small > segments having the following representations: >=20 > 1. Adaptive - alternate representations with different qualities and > bitrates; a single representation is non-adaptive; > 2. Scalable description levels - multiple additive descriptions > (i.e., addition of descriptions refine the quality of the video); > 3. Scalable layered levels - nested dependent layers corresponding = to > several hierarchical levels of quality, i.e., higher enhancement > layers refine the quality of the video of lower layers. > 4. Scalable multiple views - views correspond to mono (2D) and > stereoscopic (3D) videos, with several hierarchical levels of > quality. >=20 >=20 > -johan. >=20 > On 29 June 2012 18:45, Rui Cruz wrote: >> Hi, >>=20 >> Just to inform you that the Base Tracker Protocol was published a = while ago. >>=20 >> A new version of I-D, draft-cruz-ppsp-base-tracker-protocol-00.txt >> has been successfully submitted by Rui Santos Cruz and posted to the >> IETF repository. >>=20 >> Filename: draft-cruz-ppsp-base-tracker-protocol >> Revision: 00 >> Title: PPSP Tracker Protocol--Base Protocol (PPSP-TP/1.0) >> Creation date: 2012-06-29 >> WG ID: Individual Submission >> Number of pages: 41 >> URL: >> = http://www.ietf.org/internet-drafts/draft-cruz-ppsp-base-tracker-protocol-= 00.txt >> Status: >> http://datatracker.ietf.org/doc/draft-cruz-ppsp-base-tracker-protocol >> Htmlized: >> http://tools.ietf.org/html/draft-cruz-ppsp-base-tracker-protocol-00 >>=20 >>=20 >> Abstract: >> This document specifies the base Peer-to-Peer Streaming Protocol- >> Tracker Protocol (PPSP-TP/1.0), an application-layer control >> (signaling) protocol for the exchange of meta information between >> trackers and peers. The specification outlines the architecture of >> the protocol and its functionality, and describes message flows, >> message processing instructions, message formats, formal syntax and >> semantics. The PPSP Tracker Protocol enables cooperating peers to >> form content streaming overlay networks to support near real-time >> Structured Media content (audio, video, associated timed text and >> metadata) delivery, such as adaptive multi-rate, layered (scalable) >> and multi-view (3D), in live, time-shifted and on-demand modes. >>=20 >>=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 28/06/2012, at 02:46, zhangyunfei wrote: >>=20 >> Thank Rui for the information. >> P.S.: For the WG, Arno has published a new version of the peer = protocol. >> Please review it and publish your comments. Thanks. >>=20 >> BR >> Yunfei >>=20 >> ________________________________ >> zhangyunfei >>=20 >> From: Rui Cruz >> Date: 2012-06-28 00:41 >> To: Johan Pouwelse >> CC: Rui Cruz; ppsp >> Subject: Re: [ppsp] Progress on core tracker protocol? >> The PPSP-TP base Tracker Protocol draft will be published before the = end of >> June. >> It does essentially what we had discussed during IETF 83. >> The PPSP-TP Extended Tracker Protocol will bring all those more >> sophisticated features, and will be published afterwards (during = July) >>=20 >> Cumprimentos/Regards, >> Rui Cruz >>=20 >> Sent from my iPad2 >>=20 >> On 27/06/2012, at 16:52, Johan Pouwelse wrote: >>=20 >> There was agreement for the need to create a core tracker protocol. = Any >> progress to report, since last month? >> What do you think of my proposal below for the focus of this >> really-limited-to-the-core protocol? >>=20 >>=20 >> This document specifies the Peer-to-Peer Streaming Protocol--Core = Tracker >> Protocol (PPSP-CTP), an application-layer control protocol for = facilitating >> Peer-2-Peer streaming. This core protocol is limited to a peer = discovery >> request message and reply message. >> The PPSP-CTP protocol is limited to the GET-PEERS message and = subsequent >> reply with a peer list. This core protocol is the only requirement = for a >> simple streaming service, along with the PPSP peer protocol. We refer = to an >> upcoming Extended Tracker Protocol for more sophisticated features. = For >> instance, the exchange of meta information, content information, = statistics >> reporting, etc. >>=20 >>=20 >> -johan. >> On Tuesday, June 5, 2012, Rui Cruz wrote: >>>=20 >>> Hi, >>>=20 >>> The Tracker Protocol is being split to a base specification draft = and to >>> extensions. >>> We hope to have the base specification submitted in a couple of = weeks. >>>=20 >>>=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 04/06/2012, at 10:39, stefano previdi wrote: >>>=20 >>> All, >>>=20 >>> here are some notes i preparation of the next PPSP meeting we're >>> going to have in Vancouver = (http://www.ietf.org/meeting/84/index.html) >>>=20 >>> 1. Peer Protocol - chunk addressing mechanism >>> We currently have two proposals that I'd try to name as: >>> . Bin Notation >>> . Ranges >>> Both proposals have been discussed in the mailing list and it >>> looks to me we're NOT achieving agreement/consensus on any of >>> them also due to lack of participation of the WG into the >>> discussion (other than the authors of each proposal). >>>=20 >>> Therefore, as of today, we can reasonably explore the >>> following options: >>> Option-1: We propose both solutions in the peer protocol >>> specification and we define them both MANDATORY so >>> to cope with interoperability issues. >>> Option-2: we select one option through a WG vote (this is my >>> least preferred option). >>>=20 >>> Since I'd really prefer to avoid Option-2, I can only consider >>> the "dual" specification. WG opinion on this is requested. >>>=20 >>> Again, it would be very beneficial to the WG if current >>> implementors of streaming protocols would/could speak-up and >>> give their opinion (see point 4 below). >>>=20 >>> 2. Peer Protocol - Security Section >>> The IESG will not accept any protocol specification without a >>> consistent security section (IOW: way more than what we >>> currently have) although there are some arguments on whether >>> we need the security mechanisms in the base spec. >>>=20 >>> Arno and Zong Ning proposed some text and we need to agree/amend >>> it asap so to update the draft. I'd like to close this one and >>> have a new version of the draft for next meeting. >>>=20 >>> 3. Tracker Protocol >>> After IETF83 we agreed to split into two distinct drafts: base >>> specification and optional extensions. >>>=20 >>> Authors, it would be good to have a first submission before next >>> meeting. >>>=20 >>> 4. Survey draft. >>> We need to refresh/re-submit and the chairs proposed the >>> authors/editors to include a section on deployment experiences >>> and more precisely on chunk addressing and security mechanisms. >>> Hopefully this will also feed ongoing discussions. >>>=20 >>> 5. Meeting during IETF84. >>> We have requested a slot for Vancouver meeting. Anyone >>> interested, please request an agenda slot asap to Yunfei or >>> myself. >>>=20 >>> Let us know if anything is missing. >>>=20 >>> Thanks. >>>=20 >>> Stefano & Yunfei >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >>>=20 >>>=20 >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >>=20 >>=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_11FC74A1-6C30-476C-BB70-C76A8976006C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I would argue against putting this complexity and = registration process
in the base protocol.
It's not needed for a = basic implementation, right?

Where is = the complexity of registration? The peer just sends a peer-ID that needs = to be validated. If valid, the tracker registers that peer as active. = Only ONE request message is sent.
In BitTorrent, besides the = peer_id it also needs a connection_id to be validated before the tracker = accepts the peer, and this requires exchanging at least two requests = (connect and announce).  

What is the cost in bytes of a single session for = this protocol?

This protocol uses ONE = request message (CONNECT) to get the peer "connected", = "announced" in several swarms, and, if leech, receive the peer lists for = the corresponding swarms. 
It supports IPv4 and IPv6. The = responses can be as rich as desired in terms of information for the = peer.

The BitTorrent protocol over UDP does not = support IPv6 (yet) and besides the connect requires one "announce" per = swarm.

For a seeder joining the same number of = swarms, for example 10,  perhaps the cost is not so = different as each BitTorrent "announce" uses around 64 bytes for the = request. 

BitTorrent:   = "connect" + 10x"announce" =3D ~656 bytes (and = 11xRTT)
PPSP Tracker/1.0: CONNECT (with 10 swarms) =3D ~640 = bytes (using gzip content encoding) and = 1xRTT.

The same reasoning could be made for the = responses, as BitTorrent would use one response with peer list for each = announce. For the same 10 swarms,  it would be 10 requests and 10 = responses, while for our protocol all that would be included in the = response to the single CONNECT request. 
Additionally, = for the same effect, it would take much longer for BitTorrent in terms = of transit time to achieve the same result. =  


Regards,

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

On 10/07/2012, at 18:25, Johan Pouwelse wrote:

Filename: =  draft-cruz-ppsp-base-tracker-protocol
Title:  PPSP Tracker Protocol--Base Protocol = (PPSP-TP/1.0)
Number of pages: = 41

Excellent to see progress on the Tracker protocol = front. I've reviewed
this document, see below.

=46rom = draft-cruz-ppsp-base-tracker-protocol :
=       2) In PEER REGISTERED state, if = Peer-ID is valid, the tracker
=          processes the = requested action(s) for the valid swarm information.

I would = argue against putting this complexity and registration process
in the = base protocol.
It's not needed for a basic implementation, = right?

The base protocol now requires full xml parsing and = generation.
=46rom draft-cruz-ppsp-base-tracker-protocol :
=   The generic format of a Request is the following:
=   <?xml version=3D"1.0" encoding=3D"UTF-8"?>
=   <PPSPTrackerProtocol xmlns=3D"TBD" schemaLocation=3D"TBD" = version=3D"1.0">
=     <Request></Request>
=     <TransactionID></TransactionID>
=     <PeerID></PeerID>
=     <SwarmID></SwarmID>
=     <PeerNum></PeerNum>
=     <PeerGroup></PeerGroup>
=     <StatisticsGroup></StatisticsGroup>   </PPSPTrackerProtocol>

I would argue against = this lack of (bandwidth) efficiency.
The tracker protocol from = Bittorrent has been around for 10+ years now.
A few years ago they = gave it an efficiency upgrade:
http://bittorrent.org/be= ps/bep_0015.html
This improvement now yields: "The protocol = proposed here uses 4
packets and about 618 bytes".

What is the = cost in bytes of a single session for this protocol?

This base = protocol definition is a good step forward, but the above
(non-IETF) = tracker specification is 5 pages in length, the current
draft is 41 = pages.
Trimming down to 8 pages is probably doable by both = simplification
(e.g. no registration, timer admin, fully stateless) = of this base
protocol and text reduction.
For instance, the = following example section should be omitted I
believe, which should = not reduce the value of the document.
=3D=3D=3D=3D=3D=3D=3D=3D
=   The process used for media streaming distribution assumes a = segment
  (chunk) transfer scheme whereby the original = content (that can be
  encoded using adaptive or scalable = techniques) is chopped into small
  segments having the = following representations:

  1. Adaptive - alternate = representations with different qualities and
=      bitrates; a single representation is = non-adaptive;
  2. Scalable description levels - multiple = additive descriptions
     (i.e., addition = of descriptions refine the quality of the video);
  3. = Scalable layered levels - nested dependent layers corresponding to
=      several hierarchical levels of quality, = i.e., higher enhancement
     layers refine = the quality of the video of lower layers.
  4. Scalable = multiple views - views correspond to mono (2D) and
=      stereoscopic (3D) videos, with several = hierarchical levels of
=      quality.


=  -johan.

On 29 June 2012 18:45, Rui Cruz = <rui.cruz@ieee-pt.org> wrote:
Hi,

Just to inform = you that the Base Tracker Protocol was published a while = ago.

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

Filename: =  draft-cruz-ppsp-base-tracker-protocol
Revision:  00
Title:  PPSP Tracker Protocol--Base Protocol = (PPSP-TP/1.0)
Creation date: =  2012-06-29
WG ID: =  Individual Submission
Number of pages: 41
URL:
http://www.ietf.org/internet-drafts/draft-cruz-ppsp-base-tra= cker-protocol-00.txt
Status:
http://datatracker.ietf.org/doc/draft-cruz-ppsp-base-tracker= -protocol
Htmlized:
http://tools.ietf.org/html/draft-cruz-ppsp-base-tracker-prot= ocol-00


Abstract:
=  This document specifies the base Peer-to-Peer Streaming = Protocol-
 Tracker = Protocol (PPSP-TP/1.0), an application-layer = control
 (signaling) = protocol for the exchange of meta information = between
 trackers and = peers.  The specification outlines the architecture = of
 the protocol and its = functionality, and describes message flows,
 message processing instructions, message formats, = formal syntax and
=  semantics.  The PPSP Tracker Protocol enables cooperating = peers to
 form content = streaming overlay networks to support near = real-time
 Structured = Media content (audio, video, associated timed text = and
 metadata) delivery, = such as adaptive multi-rate, layered = (scalable)
 and = multi-view (3D), in live, time-shifted and on-demand = modes.


Regards,

Rui = Cruz
rui.cruz@ieee.org

IST/INESC-ID/INOV= - Lisbon, Portugal
__________________________________________
<= blockquote type=3D"cite">ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
<= blockquote type=3D"cite">
On = 28/06/2012, at 02:46, zhangyunfei wrote:

Thank Rui for = the information.
P.S.: For the = WG, Arno has published a new version of the peer = protocol.
Please review it and = publish your comments. Thanks.

BR
Yunfei

________________________________
zhangyunfei

From: Rui = Cruz
Date: 2012-06-28 = 00:41
To: Johan = Pouwelse
CC: Rui Cruz; = ppsp
Subject: Re: [ppsp] = Progress on core tracker protocol?
The PPSP-TP base Tracker Protocol draft will be published = before the end of
June.
It does = essentially what we had discussed during IETF = 83.
The PPSP-TP Extended = Tracker Protocol will bring all those more
sophisticated features, and will be published afterwards = (during July)

Cumprimentos/Regards,
Rui Cruz

Sent from my = iPad2

On 27/06/2012, = at 16:52, Johan Pouwelse <peer2peer@gmail.com> = wrote:

There was = agreement for the need to create a core tracker protocol. = Any
progress to report, since = last month?
What do you think = of my proposal below for the focus of this
really-limited-to-the-core = protocol?


This document = specifies the Peer-to-Peer Streaming Protocol--Core = Tracker
Protocol (PPSP-CTP), = an application-layer control protocol for = facilitating
Peer-2-Peer = streaming. This core protocol is limited to a peer = discovery
request message and = reply message.
The PPSP-CTP = protocol is limited to the GET-PEERS message and = subsequent
reply with a peer = list. This core protocol is the only requirement for = a
simple streaming service, = along with the PPSP peer protocol. We refer to = an
upcoming Extended Tracker = Protocol for more sophisticated features. = For
instance,  the = exchange of meta information, content information, = statistics
reporting, = etc.


= -johan.
On Tuesday, June 5, = 2012, Rui Cruz wrote:

Hi,

The Tracker Protocol is =  being split to a base specification draft and = to
extensions.
We hope to have the base = specification submitted in a couple of = weeks.


Regards,

Rui = Cruz
rui.cruz@ieee.org

IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= /blockquote>
ppsp = mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
<= /blockquote>

On 04/06/2012, at 10:39, stefano = previdi wrote:

All,

here are some notes i = preparation of the next PPSP meeting = we're
going to have in Vancouver = (http://www.ietf.org/meeting/84/index.html)
<= blockquote type=3D"cite">

1. Peer Protocol - chunk = addressing mechanism
 We currently have two = proposals that I'd try to name = as:
. Bin Notation
. = Ranges
 Both proposals have been discussed in the mailing = list and it
 looks to me we're NOT = achieving agreement/consensus on any = of
 them also due to lack of participation of the WG = into the
 discussion (other than = the authors of each proposal).

 Therefore, as of today, = we can reasonably explore the
 following = options:
 Option-1: We propose both = solutions in the peer protocol
=            specific= ation and we define them both MANDATORY = so
=            to = cope with interoperability = issues.
 Option-2: we select one option through a WG vote = (this is my
=            least = preferred option).

 Since I'd really prefer = to avoid Option-2, I can only = consider
 the "dual" specification. = WG opinion on this is = requested.

 Again, it would be very = beneficial to the WG if current
 implementors of streaming = protocols would/could speak-up = and
 give their opinion (see point 4 = below).

2. Peer Protocol - Security = Section
 The IESG will not accept any protocol = specification without a
 consistent security = section (IOW: way more than what = we
 currently have) although there are some arguments = on whether
 we need the security = mechanisms in the base spec.

 Arno and Zong Ning = proposed some text and we need to = agree/amend
 it asap so to update the = draft. I'd like to close this one = and
 have a new version of the draft for next = meeting.

3. Tracker = Protocol
 After IETF83 we agreed to = split into two distinct drafts: = base
 specification and optional = extensions.

 Authors, it would be good = to have a first submission before = next
 meeting.

4. Survey = draft.
 We need to refresh/re-submit and the chairs = proposed the
 authors/editors to = include a section on deployment = experiences
 and more precisely on = chunk addressing and security = mechanisms.
 Hopefully this will also = feed ongoing discussions.

5. Meeting during = IETF84.
 We have requested a slot for Vancouver meeting. = Anyone
 interested, please request an agenda slot asap to = Yunfei or
=  myself.

Let us know if anything is = missing.

Thanks.

Stefano & = Yunfei
_______________________________________________
ppsp = mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
<= /blockquote>


_______________________________________________
ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
<= blockquote type=3D"cite">

___________________________________________= ____
ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

= --Apple-Mail=_11FC74A1-6C30-476C-BB70-C76A8976006C-- From rui.cruz@ieee-pt.org Tue Jul 10 14:44:19 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 8DF8E11E80F8 for ; Tue, 10 Jul 2012 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=1.150, 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 ph71hK0DprZi for ; Tue, 10 Jul 2012 14:44:18 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA67E11E80C4 for ; Tue, 10 Jul 2012 14:44:17 -0700 (PDT) Received: by wibhm11 with SMTP id hm11so3683021wib.13 for ; Tue, 10 Jul 2012 14:44:45 -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:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=AEuP5sTNwaJ3W6jVNUkkC6bJ6BjxhTkafkmrySdhHNc=; b=JfuxHIvLCXsicK2lugPZKecu8hyT9knS+ENn0vAMNcPUszdKOx4B1O1Yeda9yJybc6 DhSqStHPO8u2rnSTSsoG/Zc86bVPyOni5Lh/Iqf22r/qjXLdsQXUz3I/DL6UtU8i/wWU 6gMxCMvSdkq+u1dSRe9nqGJPwQBUfUzGfWWH/lC3jHPxWa7a0/6xYhR8XTkmwVIsS5cV ChMqAIe1xBjzqglgFE4w/GlqLH9TT0lp7T/CWSWQQ/0fDqP4zCemdZAvujHqTaXRFFdF fcUGEi98n1IAXtHY6I/33nh2NXpCttq4L5ZZvK64RVSchE3J5VvSoa8l2hkbjL+MuIgU FkIQ== Received: by 10.180.88.102 with SMTP id bf6mr36516132wib.4.1341956685834; Tue, 10 Jul 2012 14:44:45 -0700 (PDT) Received: from airia.casa (89-180-24-72.net.novis.pt. [89.180.24.72]) by mx.google.com with ESMTPS id dc3sm21977912wib.2.2012.07.10.14.44.43 (version=SSLv3 cipher=OTHER); Tue, 10 Jul 2012 14:44:44 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_3940F499-5944-4289-A9D0-CEB43DC1BC75" From: Rui Cruz In-Reply-To: <4FFC2F8F.1020701@cs.vu.nl> Date: Tue, 10 Jul 2012 22:44:40 +0100 Message-Id: References: , <2012062809463963273025@chinamobile.com> <4FFC2F8F.1020701@cs.vu.nl> To: arno@cs.vu.nl X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl5oIkZ6EnLMX0jepNGMo8Cq1IN4BKhD4iM/I19MXksLlIrlBJ7x8L+yLDdVPjMutiaqZ/z Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] Progress on core tracker protocol? 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, 10 Jul 2012 21:44:19 -0000 --Apple-Mail=_3940F499-5944-4289-A9D0-CEB43DC1BC75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Arno, Thanks for your comments. > * p. 14: The Terminated state does not make much sense, IMHO and is = equivalent to INIT. The "per-Peer-ID" state machine is destroyed when the peer is = de-registered and so it does not returns to an INIT state (that is = transient). > For IP addresses (other than the one from which the request comes = from) some form of return routability check is needed. The peer may inform the tracker of its IP addresses, but the peer = Transport Address (REFLEXIVE) "candidate", the one from which the = request comes from, is the one that is returned in peer lists by the = tracker.=20 A return routability check could be implemented, if required just by = mandating a STAT_REPORT after a successful CONNECT carrying a key = received in the response to the CONNECT. If the peer does not answer = with the key, then it would be de-registered from the tracker.=20 > * p. 31: Seeders will need to be able to retrieve peer lists from the = tracker too, in particular when the seeder is behind a NAT itself. = Please adjust the spec to allow this. I see. The spec can be adjusted to include that option. > * p. 35: For the peer protocol's security we need the tracker to = return a true random sample of the list of registered peers in a swarm = (see peer draft Sec. 13.2.3). Could you make this the default behaviour, = or allow a peer to request this explicitly? The "default behavior" is the tracker to return a randomly selected = subset of the peers in a swarm satisfying certain criteria (location, = status, special policies), not all the peers (unless their number is = even lower than the one requested by the peer). I suppose this satisfies = your concern, but we can stress it in the text.=20 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 10/07/2012, at 14:35, Arno Bakker wrote: > Hi Rui et al >=20 > after reading the base protocol -00 I have the following comments: >=20 > * General: basic design now nice and simple, description still = verbose. >=20 > * p. 14: The Terminated state does not make much sense, IMHO and is = equivalent to INIT. >=20 > * p. 24: In a PeerGroup in a CONNECT a peer may provide a list of IP = addresses. How to you intend to protect against malicious peers = registering victim IP addresses as part of an amplification attack (see > draft-ietf-ppsp-peer-protocol-02, p. 13.2.3). For IP addresses (other = than the one from which the request comes from) some form of return = routability check is needed. >=20 > * p. 31: Seeders will need to be able to retrieve peer lists from the = tracker too, in particular when the seeder is behind a NAT itself. = Please adjust the spec to allow this. >=20 > * p. 35: For the peer protocol's security we need the tracker to = return a true random sample of the list of registered peers in a swarm = (see peer draft Sec. 13.2.3). Could you make this the default behaviour, = or allow a peer to request this explicitly? >=20 > Regards, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_3940F499-5944-4289-A9D0-CEB43DC1BC75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Arno,

Thanks for your = comments.

* p. = 14: The Terminated state does not make much sense, IMHO and is = equivalent to INIT.

The = "per-Peer-ID" state machine is destroyed when the peer is de-registered = and so it does not returns to an INIT state (that is = transient).

 For IP addresses (other than the one from which = the request comes from) some form of return routability check is = needed.

The peer may inform the = tracker of its IP addresses, but the peer Transport Address (REFLEXIVE) = "candidate", the one from which the request comes from, is the = one that is returned in peer lists by the = tracker. 

A return routability check could = be implemented, if required just by mandating a STAT_REPORT after a = successful CONNECT carrying a key received in the response to the = CONNECT. If the peer does not answer with the key, then it would be = de-registered from the = tracker. 

* = p. 31: Seeders will need to be able to retrieve peer lists from the = tracker too, in particular when the seeder is behind a NAT itself. = Please adjust the spec to allow this.

I = see. The spec can be adjusted to include that = option.

* p. 35: = For the peer protocol's security we need the tracker to return a true = random sample of the list of registered peers in a swarm (see peer draft = Sec. 13.2.3). Could you make this the default behaviour, or allow a peer = to request this explicitly?

The = "default behavior" is the tracker to return a randomly selected subset = of the peers in a swarm satisfying certain criteria (location, = status, special policies), not all the peers (unless their number is = even lower than the one requested by the peer). I suppose this satisfies = your concern, but we can stress it in the text. 

Regards,

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

On 10/07/2012, at 14:35, Arno Bakker wrote:

Hi = Rui et al

after reading the base protocol -00 I have the = following comments:

* General: basic design now nice and simple, = description still verbose.

* p. 14: The Terminated state does not = make much sense, IMHO and is equivalent to INIT.

* p. 24: In a = PeerGroup in a CONNECT a peer may provide a list of IP addresses. How to = you intend to protect against malicious peers registering victim IP = addresses as part of an amplification attack = (see
draft-ietf-ppsp-peer-protocol-02, p. 13.2.3). For IP addresses = (other than the one from which the request comes from) some form of = return routability check is needed.

* p. 31: Seeders will need to = be able to retrieve peer lists from the tracker too, in particular when = the seeder is behind a NAT itself. Please adjust the spec to allow = this.

* p. 35: For the peer protocol's security we need the = tracker to return a true random sample of the list of registered peers = in a swarm (see peer draft Sec. 13.2.3). Could you make this the default = behaviour, or allow a peer to request this = explicitly?

Regards,
=     Arno
__________________________________________= _____
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

= --Apple-Mail=_3940F499-5944-4289-A9D0-CEB43DC1BC75-- From a.bakker@vu.nl Wed Jul 11 00:20: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 0DC2821F85A0 for ; Wed, 11 Jul 2012 00:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=1.548, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpdKxyXTj43H for ; Wed, 11 Jul 2012 00:20:35 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2D59D21F859E for ; Wed, 11 Jul 2012 00:20:34 -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.298.4; Wed, 11 Jul 2012 09:20:59 +0200 Received: from [192.168.0.104] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 11 Jul 2012 09:21:02 +0200 Message-ID: <4FFD2967.7080402@cs.vu.nl> Date: Wed, 11 Jul 2012 09:21:11 +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: ppsp References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> In-Reply-To: <2012062015092544515442@chinamobile.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt 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, 11 Jul 2012 07:20:36 -0000 Hi Yunfei (et al) Thanks for the feedback. Responses inline. On 20/06/2012 09:09, zhangyunfei wrote: > Hi Arno and Riccardo (Speaking individually), > > 2) bin numbers in 1^st paragraph: Since there are at least two schemes > introduced in section 4, the range scheme should be stated here as well. Sorry, forgot to update the introduction section in a vain effort to keep changes to a minimum. Scheduled for -03. > 3)Merkle hash tree in section 2.2：Occur for the first time without > explaining before.It's better to add the term in section 1.3. Done for -03. > 4)INTEGRITY in section 2.2: It should be stated that this message is not > used all the time. Clarified in -03. > 5)Section3.3： The sentence "it MUST send a ACK message containing a > chunk specification for C". MUST or SHOULD. Riccardo is looking into sending batched acknowledgements in relationship to the latest LEDBAT draft, so we may update this section. At present, it is a "MUST" when run over unreliable transports. > 6)Section 3.9, since TCP is abandoned by PPSPP, do we need to explain > the related case? Good that you mention transports, AFAIK that still needs to be discussed. Candidates are: * UDP with congestion control (e.g. LEDBAT) * RTP * Both UDP+cc and RTP I see no direct use case of TCP, but IMHO we should not exclude it either. Support for RTP may make the standard more appealing to the RTCWEB crowd. Perhaps we should ask them for an opinion on this issue. Yunfei/Stefano, do you know somebody we could ask? > 7)Section 4.3 PEX_ADD, no explanation before. PEX_ADD was renamed to PEX_RES except in this location :-( > 8)Section 6: I suggest to exclude this section because it involves a > over-strong limitation:fixed chunk size.Furthermore I am not clear of > the necessity of this scheme.Just as the background of section 7? IMHO, fixed-size chunks will be rather common with static content, and the ability to detect content size is a nice property to achieve minimal metadata (cf. info centric networking) In any case, the concept of peak hashes enhances security and eases implementation, therefore I think it should be explained in the draft. The peak hashes provide a secure method of determining (a) the height of the MHT and (b) more importantly, how many chunks there are at the base of the tree. This helps to protect against malicious peers sending confusing information, e.g. a HAVE for a chunk outside the actual chunk range. The ability to judge incoming information as being good or bad greatly eases implementation (otherwise you may need e.g. majority votes on how many chunks there are, etc.) Peak hashes also ease implementation in another respect. With the knowledge about the tree they provide, datastructures can be preallocated, such as the storage of the MHT and chunk availability bitmaps. Pre-allocated datastructures are easier to implement than data structures that have to dynamically adapt. > 9) Section 7:for the similar reason, remove the section 7.1.1 I don't quite follow this comment. Live streaming is not dependent on fixed-sized chunks and mini Merkle Hash Trees are already a common way of efficiently authenticating live data (Wong and Lam scheme). IMHO, it makes sense to extend to extend this mechanism to a big tree. This would enable people that tune in late to a show and want to watch it from the start to use the same swarm as the live watchers. > 10)Section 9.3.2, why placed here? I suggest to remove this section. I'd like to start the discussion on which transport to use (see above) and then update this part of the spec, if that's alright. Regards, Arno From wes@mti-systems.com Wed Jul 11 09:33:29 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C79B21F8564 for ; Wed, 11 Jul 2012 09:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+VTQAgyY+c6 for ; Wed, 11 Jul 2012 09:33:29 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id DE7FE21F8549 for ; Wed, 11 Jul 2012 09:33:28 -0700 (PDT) Received: from cm-omr11 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q6BGXx0g015304 for ; Wed, 11 Jul 2012 12:33:59 -0400 Authentication-Results: cm-omr11 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [63.226.32.150] ([63.226.32.150:23945] helo=[172.27.250.202]) by cm-omr11 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 81/BF-04565-6FAADFF4; Wed, 11 Jul 2012 12:33:59 -0400 Message-ID: <4FFDAAF6.20900@mti-systems.com> Date: Wed, 11 Jul 2012 12:33:58 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: arno@cs.vu.nl References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl> In-Reply-To: <4FFD2967.7080402@cs.vu.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ppsp Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:33:29 -0000 On 7/11/2012 3:21 AM, Arno Bakker wrote: > Good that you mention transports, AFAIK that still needs to be > discussed. Candidates are: > > * UDP with congestion control (e.g. LEDBAT) > * RTP > * Both UDP+cc and RTP > > I see no direct use case of TCP, but IMHO we should not exclude it either. > > Support for RTP may make the standard more appealing to the RTCWEB > crowd. Perhaps we should ask them for an opinion on this issue. > Yunfei/Stefano, do you know somebody we could ask? I would prefer to simply go with UDP+cc and keep it simple. The RTCWEB approach involves a stack of other crap that does not seem to be of much value for PPSP; they are not using purely RTP. -- Wes Eddy MTI Systems From wes@mti-systems.com Wed Jul 11 09:41: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 1A9D611E8088 for ; Wed, 11 Jul 2012 09:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JPI03CqXFLR for ; Wed, 11 Jul 2012 09:41:06 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 68B4821F85D8 for ; Wed, 11 Jul 2012 09:41:06 -0700 (PDT) Received: from cm-omr10 (mail.networksolutionsemail.com [205.178.146.50]) by omr5.networksolutionsemail.com (8.14.4/8.14.4) with ESMTP id q6BGfaUW006173 for ; Wed, 11 Jul 2012 12:41:36 -0400 Authentication-Results: cm-omr10 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [63.226.32.150] ([63.226.32.150:13207] helo=[172.27.250.202]) by cm-omr10 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 48/FD-04850-FBCADFF4; Wed, 11 Jul 2012 12:41:36 -0400 Message-ID: <4FFDACBF.3080908@mti-systems.com> Date: Wed, 11 Jul 2012 12:41:35 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: arno@cs.vu.nl References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl> In-Reply-To: <4FFD2967.7080402@cs.vu.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ppsp Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:41:07 -0000 On 7/11/2012 3:21 AM, Arno Bakker wrote: > Good that you mention transports, AFAIK that still needs to be > discussed. Candidates are: > > * UDP with congestion control (e.g. LEDBAT) I'm wondering if LEDBAT is the right choice, given that its design is to let itself get drowned out. LEDBAT made sense for BitTorrent streams running in the background, but I don't think it makes as much sense for live-streaming. It seems that TFRC might be more appropriate to me. -- Wes Eddy MTI Systems From zhangyunfei@chinamobile.com Wed Jul 11 18:52:34 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 3EB7211E8123; Wed, 11 Jul 2012 18:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.115 X-Spam-Level: X-Spam-Status: No, score=-94.115 tagged_above=-999 required=5 tests=[AWL=-3.387, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 fcsJis3oZP1E; Wed, 11 Jul 2012 18:52:33 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A336811E8120; Wed, 11 Jul 2012 18:52:32 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id DFC32E564; Thu, 12 Jul 2012 09:53:04 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id C89CCE3CA; Thu, 12 Jul 2012 09:53:04 +0800 (CST) Received: from zyf-PC ([10.2.53.144]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071209530277-23539 ; Thu, 12 Jul 2012 09:53:02 +0800 Date: Thu, 12 Jul 2012 09:52:57 +0800 From: zhangyunfei To: ppsp , pzhang.thu X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012071209525775716926@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-12 09:53:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-12 09:53:04, Serialize complete at 2012-07-12 09:53:04 Content-Type: multipart/alternative; boundary="----=_001_NextPart023273532476_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19034.003 X-TM-AS-Result: No--33.041-7.0-31-10 X-imss-scan-details: No--33.041-7.0-31-10;No--33.041-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: decade Subject: [ppsp] =?gb2312?b?16q3ojogUmU6IFtkZWNhZGVdICAgT2JqZWN0IG5hbWlu?= =?gb2312?b?ZyBpbiAtcmVxIGFuZCAtYXJjaA==?= 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, 12 Jul 2012 01:52:34 -0000 This is a multi-part message in MIME format. ------=_001_NextPart023273532476_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgUGVuZywNCiAgICBXb3VsZCB5b3UgcGxlYXNlIGFsc28gY2MgdGhlIGRpc2N1c3Npb24gdG8g cHBzcCBmb3Igc3luYywgYXMgUmljaGFyZCBzdWdnZXN0ZWQuIFRob3JvdWdoIERpc2N1c3Npb24g b24gdGhlIG5hbWluZyBvZiBNSFQgaW4gUFBTUCBpcyBhbHNvIG5lZWRlZCwgYXMgaW4gREVDQURF LiBUaGFua3MuDQoNCkJSDQp5dW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0Kt6K8/sjLo7og UGVuZyBaaGFuZw0Kt6LLzcqxvOSjuiAyMDEyLTA3LTEyIDA1OjI1DQrK1bz+yMujuiB6aGFuZ3l1 bmZlaQ0Ks63LzaO6IGRlY2FkZTsgYXJubw0K1vfM4qO6IFJlOiBbZGVjYWRlXSBbcHBzcF0gT2Jq ZWN0IG5hbWluZyBpbiAtcmVxIGFuZCAtYXJjaA0KSGkgQXJubywNCg0KDQpUaGFua3MgZm9yIHRo ZSBjbGFyaWZpY2F0aW9uLiBJbiBteSB1bmRlcnN0YW5kaW5nLCBNSFQgb3ZlciBzaW5nbGUgaGFz aCBjYW4gZW5hYmxlIGltbWVkaWF0ZSBpbnRlZ3JpdHkgY2hlY2sgYmVmb3JlIHRoZSB3aG9sZSBt ZWRpYSBmaWxlIGlzIHJlY2VpdmVkLCB3aGljaCBpcyBjcml0aWNhbCBmb3Igc3RyZWFtaW5nIGFw cGxpY2F0aW9ucy4gQnV0IHRoZSBjbGllbnQgY2FuIGFsc28gZG93bmxvYWQgaGFzaGVzIG9mIGV2 ZXJ5IHBpZWNlLCBqdXN0IGxpa2UgaW4gQml0VG9ycmVudC4gRG9lcyBpdCByZWR1Y2UgYSBsb3Qg c3RhcnR1cCBsYXRlbmN5IG9yIHNlcnZlciBsb2FkIGJ5IHVzaW5nIE1IVD8gVGhhbmtzLg0KDQoN CkZvciBERUNBREUsIEl0IHN1cHBvcnRzIGludGVncml0eSBjaGVjayBvbiBwaWVjZS9jaHVuayBs ZXZlbCwgc28gdGhhdCBjbGllbnQgY2FuIHZlcmlmeSB0aGF0IHRoZSByZWNlaXZlZCBwaWVjZSBj b3JyZXNwb25kcyB0byB0aGUgcGllY2UgbmFtZS4gREVDQURFIGlzIHVuYXdhcmUgb2Ygd2hhdCBm aWxlIHRoaXMgcGllY2UgYmVsb25ncyB0bywgYW5kIHRodXMgZG9lcyBub3QgcHJvdmlkZSBlbmQt dG8tZW5kIGludGVncml0eSBjaGVjay4gIEZvciBmaWxlIGxldmVsLCB3ZSBsZWF2ZSB0aGUgaW50 ZWdyaXR5IGNoZWNrIHRvIGFwcGxpY2F0aW9ucy4gVGh1cywgaW1vLCB3ZSBzaG91bGQgbm90IGlu Y2x1ZGUgTUhUIGluIHRoZSBkZXNpZ24gb2YgREVDQURFLiBCdXQgTUhUIGNhbiBiZSBidWlsdCBv biB0b3Agb2YgREVDQURFLCB3aGljaCBtZWFucyBhcHBsaWNhdGlvbnMgY2FuIHN0aWxsIHVzZSBN SFQgdG8gaW1wbGVtZW50IGludGVncml0eSBjaGVjayBmb3IgdGhlbXNlbHZlcy4NCg0KDQoNCg0K QiwNCg0KDQpQZW5nLg0KDQoNCk9uIEp1bCAxMCwgMjAxMiwgYXQgNDoyNiBBTSwgemhhbmd5dW5m ZWkgd3JvdGU6DQoNCg0KQXJubydzIHJlcGx5IG9uIE1IVC4NCg0KQlINCll1bmZlaQ0KDQoNCg0K DQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJha2tlcg0KRGF0ZTogMjAxMi0wNy0xMCAxNTo0 OQ0KVG86IHBwc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcHBzcF0gW2RlY2FkZV0gT2JqZWN0 IG5hbWluZyBpbiAtcmVxIGFuZCAtYXJjaA0KSGkgYWxsDQoNCkknbGwgdHJ5IHRvIGNsYXJpZnkg dGhlIHJhdGlvbmFsZSBhbmQgcHJhY3RpY2FsIG92ZXJoZWFkIG9mIHRoZSBNZXJrbGUgDQpIYXNo IFRyZWVzIGluIFBQU1AuIEZvciBzdGF0aWMgY29udGVudCwgTUhUcyBlbmFibGUgY29udGVudCBp bnRlZ3JpdHkgDQpwcm90ZWN0aW9uIHVzaW5nIHNlbGYtY2VydGlmaWVkIG5hbWluZy4gVXNpbmcg YSBoYXNoIHRyZWUgaW5zdGVhZCBvZiBhIA0Kc2luZ2xlIGhhc2ggaXMgdXNlZnVsIGluIGFsbCBz aXR1YXRpb25zIHdoZXJlIHRoZSBjb250ZW50IGlzIGRpc3RyaWJ1dGVkDQppbiBwYXJ0cyAoPWEg c2VxdWVuY2Ugb2Ygb2JqZWN0cyBhcyB5b3UgbWVudGlvbiBpdCkgdGhhdCBhcmUgaW1tZWRpYXRl bHkgDQp1c2VkLiBJbiBwYXJ0aWN1bGFyLCB3aGVuIHRoZSBwYXJ0cyBhcmUgZGVsaXZlcmVkIHRv IGEgaGlnaGVyIGxldmVsIGFwcCANCnVwb24gcmVjZWlwdCB0aGV5IG11c3QgYmUgaW50ZWdyaXR5 IGNoZWNrZWQgYmVmb3JlaGFuZC4gVGhpcyBhcHBsaWVzIHRvIA0Kc3RyZWFtaW5nLCBidXQgcGVy aGFwcyBhbHNvIHRvIG90aGVyIFAyUCBhcHBzIHVzaW5nIERFQ0FERQ0KRXZlbiBpZiBwYXJ0cyBh cmUgbm90IGltbWVkaWF0ZWx5IHVzZWQsIGFuIGludGVncml0eSBjaGVjayBvbiBwYXJ0cyBjYW4g DQpoZWxwIHRvIGltcHJvdmUgZWZmaWNpZW5jeSBpbiBhIFAyUCBjb250ZXh0LiBBbiBlbmQtdG8t ZW5kIGludGVncml0eSANCmNoZWNrIHdoZW4gdGhlIGNvbnRlbnQgaXMgY29tcGxldGVseSBkb3du bG9hZGVkIGlzIHN1ZmZpY2llbnQsIGJ1dCBmb3INCmVmZmljaWVuY3kgaXQgd291bGQgYmUgbmlj ZSB0byBrbm93IGlmIHRoZSBpbmRpdmlkdWFsIHBhcnRzIGFyZSBjb3JyZWN0DQppbnN0ZWFkIG9m IGZpbmRpbmcgb3V0IGF0IHRoZSBlbmQsIGVzcGVjaWFsbHkgZm9yIGxhcmdlIGNvbnRlbnQuDQoN Ck5vdGUgdGhhdCBNZXJrbGUgSGFzaCBUcmVlcyBzdXBwb3J0IGJvdGggcGFydGlhbCBhbmQgZW5k LXRvLWVuZCANCmludGVncml0eSBjaGVja3MuIFdoZW4gYSBwZWVyIGhhcyBhIGNvcHkgb2YgdGhl IGNvbnRlbnQgYW5kIHRoZSBuYW1lIG9mIA0KdGhlIG9iamVjdCAoPWl0cyByb290IGhhc2ggaW4g dGhlIE1IVCkgaGUgY2FuIGNhbGN1bGF0ZSB0aGUgTUhUIGZyb20gdGhlIA0KY29udGVudCBhbmQg Y29tcGFyZSB0aGUgY2FsY3VsYXRlZCByb290IGhhc2ggdG8gdGhlIG5hbWUuIEhlIGRvZXMgbm90 IA0KbmVlZCB0byByZWNlaXZlIGFueSBvZiB0aGUgaW50ZXJtZWRpYXJ5IGhhc2hlcyBmcm9tIG90 aGVycywgaWYgdGhhdCBpcyANCm5vdCByZXF1aXJlZC4NCg0KV2hpY2ggYnJpbmdzIHVzIHRvIHRo ZSB0b3BpYyBvZiBvdmVyaGVhZC4gQXMgZGlzY3Vzc2VkIGluIFNlYy4gNS41IG9mDQpodHRwOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtcHBzcC1wZWVyLXByb3RvY29sLTAyLnR4dA0KdGhl IHNpemUgb2YgdGhlIE1IVCBkZXBlbmRzIG9uIHRoZSBudW1iZXIgb2YgY2h1bmtzIChvYmplY3Rz KSBhdCB0aGUgDQpiYXNlIG9mIHRoZSB0cmVlLiBUaGF0IG51bWJlciBkZXBlbmRzIG9uIHRoZSBz aXplIG9mIHRoZSBjaHVua3MgdGhhdCBhcmUgDQpwcm9jZXNzZWQgaW1tZWRpYXRlbHkgaW4gdGhl IFAyUCBhcHBsaWNhdGlvbi4gRm9yIFBQU1Agb3ZlciBVRFAgb3ZlciANCkV0aGVybmV0IHRoZXNl IGNodW5rcyBhcmUgc21hbGwuIEZvciBvdGhlciBQMlAgYXBwcyB0aGUgY2h1bmtzIG1heSBiZSAN CmJpZ2dlci4NCg0KSG93IG11Y2ggb2YgdGhlIE1IVCB0cmVlIGFjdHVhbGx5IG5lZWRzIHRvIGJl IHNlbnQgb3ZlciB0aGUgd2lyZSB0byBhIA0KcmVjZWl2aW5nIHBlZXIgZGVwZW5kcyBvbiB0aGUg ZG93bmxvYWQgcG9saWN5IHVzZWQuIEZvciBhIGxpbmVhciANCmRvd25sb2FkIG9ubHkgcGFydCBv ZiB0aGUgdHJlZSBuZWVkcyB0byBiZSB0cmFuc21pdHRlZCwgYXMgdGhlIG90aGVyIA0KcGFydCBv ZiB0aGUgdHJlZSBpcyBjYWxjdWxhdGVkIGJ5IHRoZSByZWNlaXZpbmcgcGVlciB3aGlsZSBkb3du bG9hZGluZy4NCkluIHRoZSBleGFtcGxlIGluIFNlYy4gNS41LCBvbmx5IDcgb2YgdGhlIDE2IGhh c2hlcyBpbiB0aGUgdHJlZSBhcmUgDQphY3R1YWxseSB0cmFuc21pdHRlZC4NCg0KTm90ZSB0aGF0 IHN3aWZ0LCB0aGUgcHJvdG9jb2wgb24gd2hpY2ggdGhlIFBQU1AgcGVlciBwcm90b2NvbCBpcyBi YXNlZCANCndhcyBhY3R1YWxseSBkZXNpZ25lZCBhcyBhIGdlbmVyaWMgdHJhbnNwb3J0IHByb3Rv Y29sLCB1bmlmeWluZyByZWd1bGFyIA0KZG93bmxvYWRzLCBWT0QgYW5kIGxpdmUgc3RyZWFtaW5n LiBTbyBpdCBzdGlsbCBzdXBwb3J0cyBlZmZpY2llbnQgDQpub24tc3RyZWFtaW5nIGRvd25sb2Fk IHBvbGljaWVzIGxpa2UgQml0VG9ycmVudCdzIHJhcmVzdCBmaXJzdC4gSW4gb3RoZXIgDQp3b3Jk cywgaXRzIG9yaWdpbnMgZml0cyB0aGUgZ2VuZXJhbCBkaXN0cmlidXRpb24gbmF0dXJlIG9mIERF Q0FERS4NCg0KUmVnYXJkcywNCiAgICAgIEFybm8NCg0KDQpPbiAxMC8wNy8yMDEyIDA3OjIzLCBZ LiBSaWNoYXJkIFlhbmcgd3JvdGU6DQo+IEhpIFBlbmcsIERpcmssDQo+DQo+IEkgYW0gY2MnaW5n IHRoZSBwcHNwIGxpc3QgYXMgd2VsbC4gWW91IHJhaXNlZCBhIGdvb2QgcG9pbnQgb24gdGhlDQo+ IGRpc3RpbmN0aW9uIGJldHdlZW4gb25lIG9iamVjdCBhbmQgYSBzZXF1ZW5jZSBvZiBvYmplY3Rz LiBUbyBnZW5lcmFsaXplLA0KPiB3ZSBjYW4gZGlzY3VzcyBldmVuIGEgc2V0IG9mIG9iamVjdHMg KG5vIG9yZGVyaW5nKSwgYW5kIGEgc2V0IG9mDQo+IGVxdWl2YWxlbmNlIG9iamVjdHMgKGR5bmFt aWMgc3RyZWFtaW5nIHRoYXQgaW50ZXJsZWF2ZXMgZGlmZmVyZW50DQo+IHJlc29sdXRpb25zKS4g WW91ciBhcmd1ZW1lbnQgYWdhaW5zdCBNVEggaXMgaGlnaGVyIG92ZXJoZWFkIGluIHRoZQ0KPiBn ZW5lcmFsIGNhc2UgKGVuZCB0byBlbmQgYXJndWVtZW50cykuIEhvdyBtdWNoIGV4YWN0bHkgaXMg dGhlIG92ZXJoZWFkPw0KPiBEZWNhZGUgbWF5IGJlbmVmaXQgZnJvbSB0aGUgYW5hbHlzaXMgZnJv bSBwcHNwLiBTaW5jZSBzdHJlYW1pbmcgaXMNCj4gY29uc2lkZXJlZCBhcyB0aGUgbWFpbiBhcHAs IGhvdyBtdWNoIG92ZXJoZWFkIGlmIGRlY2FkZSBoYXMgdG8gYnVpbGQgb24gdG9wPw0KPg0KPiBU aGFua3MhDQo+DQo+IFJpY2hhcmQNCj4NCj4gT24gVHVlc2RheSwgSnVseSAxMCwgMjAxMiwgUGVu ZyBaaGFuZyB3cm90ZToNCj4NCj4gICAgIEhpIERpcmsgYW5kIGFsbCwNCj4NCj4gICAgIEkgYWdy ZWUgdGhhdCB0aGUgTkkgc3BlY2lmaWNhdGlvbiBtZWV0cyB0aGUgYmFzaWMgcmVxdWlyZW1lbnQg b2YNCj4gICAgIERFQ0FERSAod2l0aG91dCBvcHRpbWl6YXRpb24gb24gImVhcmx5IG5hbWUgZ2Vu ZXJhdGlvbiIpLg0KPg0KPiAgICAgQXMgZm9yIHRoZSBNZXJrbGUgSGFzaCBUcmVlLCBvciBNVEgs IGl0IGlzIGEgaW50ZWdyaXR5LWFzc3VyYW5jZQ0KPiAgICAgbWV0aG9kIGZvciBhIHNlcXVlbmNl IG9mIG9iamVjdHMuIEl0IGlzIGNyaXRpY2FsIHRvIHRoZSBQUFNQDQo+ICAgICBwcm90b2NvbC4g QnV0IGkgd29uZGVyIHdldGhlciB3ZSBzaG91bGQgaW5jb3Jwb3JhdGUgaXQgaW4gb3VyIGRlc2ln bjoNCj4NCj4gICAgIEZpcnN0LCBERUNBREUgaXMgdGFyZ2V0ZWQgYXQgZ2VuZXJhbCBjb250ZW50 IGRpc3RyaWJ1dGlvbg0KPiAgICAgYXBwbGljYXRpb25zLCBhbmQgZm9yIGFwcGxpY2F0aW9ucyBv dGhlciB0aGFuIFAyUCBzdHJlYW1pbmcsIHRoZXJlDQo+ICAgICBpcyBubyBncmVhdCB2YWx1ZSBv ZiB1c2luZyBNZXJrbGUgSGFzaCBUcmVlLiBJdCBtYXkgY2F1c2UgaGlnaA0KPiAgICAgb3Zlcmhl YWQgdG8gdGhlc2UgYXBwbGljYXRpb25zIGR1ZSAibWV0YSBkYXRhIiBpbmNsdWRpbmcgc2lnbmF0 dXJlcw0KPiAgICAgYW5kIGZ1bGwgaGFzaGVzIHNob3VsZCBiZSBleGNoYW5nZWQuDQo+DQo+ICAg ICBTdGlsbCwgd2UgY2FuIGRpc2N1c3MgbW9yZSBvbiBob3cgdG8gYmV0dGVyIGluY29ycG9yYXRl IFBQU1AgYmFzZWQNCj4gICAgIG9uIE5JIHdpdGhvdXQgaHVydGluZyB0aGUgZ2VuZXJhbCBhcHBs aWNhdGlvbiBvZiBERUNBREUuIFRoYW5rcy4NCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart023273532476_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Peng,
    Would you please also cc the discussion to ppsp fo= r=20 sync, as Richard suggested. Thorough Discussion on the naming of MHT = in=20 PPSP is also needed, as in DECADE. Thanks.
 
BR
yunfei
 
zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA Peng Zhang
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-07-12 05:25
=CA=D5=BC=FE=C8=CB=A3=BA zhangyunfei
=B3=AD=CB=CD=A3=BA dec= ade; arno
=D6=F7=CC=E2=A3=BA Re: [decade] [ppsp] Object naming in -= req and=20 -arch
Hi Arn= o,

Thanks= for the=20 clarification. In my understanding, MHT over single hash can enable=20 immediate integrity check before the whole media file is received, wh= ich is=20 critical for streaming applications. But the client can also download= =20 hashes of every piece, just like in BitTorrent. Does it reduce a lot start= up=20 latency or server load by using MHT? Thanks.

For DE= CADE, It=20 supports integrity check on piece/chunk level, so that client can verify t= hat=20 the received piece corresponds to the piece name. DECADE is unaware of wha= t file=20 this piece belongs to, and thus does not provide end-to-end integrity chec= k.=20  For file level, we leave the integrity check to applications. Thus, = imo,=20 we should not include MHT in the design of DECADE. But MHT can be built on= top=20 of DECADE, which means applications can still use MHT to implement integri= ty=20 check for themselves.


B,

Peng.

On Jul 10, 2012, at 4:26 AM, zhangyunfei wrote:
Arno's reply on MHT.
 
BR
Yunfei
 
zhangyunfei
 
From: Arno Bakker<= /DIV>
Date: 2012-07-10 15:49
To: ppsp@ietf.org<= /DIV>
Subject: Re: [ppsp] [decade] Object naming in -req and=20 -arch
Hi all
 
I'll try to clarify the rationale and=  practical overhead of the Merkle 
Hash Trees in PPSP. For static conten= t, MHTs enable content integrity 
protection using self-certified naming. Using&n= bsp;a hash tree instead of a 
single hash is useful in all situatio= ns where the content is distributed
in parts (=3Da sequence of objects as=  you mention it) that are immediately <= /DIV>
used. In particular, when the parts a= re delivered to a higher level app 
upon receipt they must be integrity c= hecked beforehand. This applies to 
streaming, but perhaps also to other = P2P apps using DECADE
=
Even if parts are not immediately use= d, an integrity check on parts can 
help to improve efficiency in a P2P&n= bsp;context. An end-to-end integrity 
check when the content is completely = downloaded is sufficient, but for
efficiency it would be nice to know&n= bsp;if the individual parts are correct
instead of finding out at the end,&nb= sp;especially for large content.
 
Note that Merkle Hash Trees support b= oth partial and end-to-end 
integrity checks. When a peer has a&n= bsp;copy of the content and the name of=  
the object (=3Dits root hash in the&n= bsp;MHT) he can calculate the MHT from = the 
content and compare the calculated root&nb= sp;hash to the name. He does not 
need to receive any of the intermedia= ry hashes from others, if that is 
not required.
 
Which brings us to the topic of = overhead. As discussed in Sec. 5.5 of
htt= p://www.ietf.org/id/draft-ietf-ppsp-peer-protocol-02.txt
the size of the MHT depends on t= he number of chunks (objects) at the 
base of the tree. That number depends=  on the size of the chunks that ar= e 
processed immediately in the P2P applicati= on. For PPSP over UDP over 
Ethernet these chunks are small. For = other P2P apps the chunks may be 
bigger.
 
How much of the MHT tree actually&nbs= p;needs to be sent over the wire to&nbs= p;a 
receiving peer depends on the download&nbs= p;policy used. For a linear 
download only part of the tree needs&= nbsp;to be transmitted, as the other 
part of the tree is calculated by&nbs= p;the receiving peer while downloading.
In the example in Sec. 5.5, only = ;7 of the 16 hashes in the tree ar= e 
actually transmitted.
 
Note that swift, the protocol on whic= h the PPSP peer protocol is based 
was actually designed as a generic tr= ansport protocol, unifying regular 
downloads, VOD and live streaming. So = ;it still supports efficient 
non-streaming download policies like BitTorrent= 's rarest first. In other 
words, its origins fits the general d= istribution nature of DECADE.
 
Regards,
      Arno
 
 
On 10/07/2012 07:23, Y. Richard Yang = wrote:
> Hi Peng, Dirk,
>
> I am cc'ing the ppsp list a= s well. You raised a good point on = ;the
> distinction between one object and&nb= sp;a sequence of objects. To generalize,
> we can discuss even a set o= f objects (no ordering), and a set of
> equivalence objects (dynamic streaming&nbs= p;that interleaves different
> resolutions). Your arguement against = MTH is higher overhead in the
> general case (end to end argueme= nts). How much exactly is the overhead?
> Decade may benefit from the anal= ysis from ppsp. Since streaming is
> considered as the main app, how&= nbsp;much overhead if decade has to build&nb= sp;on top?
>
> Thanks!
>
> Richard
>
> On Tuesday, July 10, 2012, Peng&= nbsp;Zhang wrote:
>
>     Hi Dirk and all,
>
>     I agree that the&n= bsp;NI specification meets the basic requirement&= nbsp;of
>     DECADE (without optimiz= ation on "early name generation").
>
>     As for the Merkle&= nbsp;Hash Tree, or MTH, it is a integri= ty-assurance
>     method for a seque= nce of objects. It is critical to the&n= bsp;PPSP
>     protocol. But i wo= nder wether we should incorporate it in = ;our design:
>
>     First, DECADE is t= argeted at general content distribution
>     applications, and for&n= bsp;applications other than P2P streaming, there<= /DIV>
>     is no great value&= nbsp;of using Merkle Hash Tree. It may = cause high
>     overhead to these = applications due "meta data" including signatures=
>     and full hashes sh= ould be exchanged.
>
>     Still, we can disc= uss more on how to better incorporate P= PSP based
>     on NI without hurt= ing the general application of DECADE. Thank= s.
>
_______________________________________________
ppsp mailing list
https://www.ietf.org= /mailman/listinfo/ppsp

=
------=_001_NextPart023273532476_=------ From a.bakker@vu.nl Wed Jul 11 23:23:09 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3968321F854E; Wed, 11 Jul 2012 23:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.543 X-Spam-Level: X-Spam-Status: No, score=-1.543 tagged_above=-999 required=5 tests=[AWL=-0.039, 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 IcVisQMk2yKO; Wed, 11 Jul 2012 23:23:08 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 70CEC21F8522; Wed, 11 Jul 2012 23:23:08 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 12 Jul 2012 08:23:38 +0200 Received: from [109.37.58.145] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.2.298.4; Thu, 12 Jul 2012 08:23:37 +0200 Message-ID: <4FFE6D67.80705@cs.vu.nl> Date: Thu, 12 Jul 2012 08:23:35 +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: Peng Zhang References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> In-Reply-To: <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp , decade Subject: Re: [ppsp] [decade] Object naming in -req and -arch 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: Thu, 12 Jul 2012 06:23:09 -0000 Hi Peng On 11/07/2012 23:25, Peng Zhang wrote: > Hi Arno, > > Thanks for the clarification. In my understanding, MHT over single hash > can enable immediate integrity check before the whole media file is > received, which is critical for streaming applications. But the client > can also download hashes of every piece, just like in BitTorrent. Does > it reduce a lot startup latency or server load by using MHT? Thanks. > The gains of using MHT depend on the chunk size. For PPSP we prefer chunks of 1K that fit in an UDP packet carried over Ethernet. In that case, for a 4 GB file, there are 4 M chunks, resulting in 80 MB of leaf hashes when SHA1 is used. Transferring that beforehand as in BitTorrent definitely increases latency ;o) > For DECADE, It supports integrity check on piece/chunk level, so that > client can verify that the received piece corresponds to the piece name. > DECADE is unaware of what file this piece belongs to, and thus does not > provide end-to-end integrity check. For file level, we leave the > integrity check to applications. Thus, imo, we should not include MHT in > the design of DECADE. But MHT can be built on top of DECADE, which means > applications can still use MHT to implement integrity check for themselves. > You are right, if DECADE doesn't provide "links" between chunks, MHTs at the DECADE level make no sense. Using MHTs at the app level instead as you say does make sense and is easy, just build all the piece names/piece hashes into a tree. Regards, Arno From sprevidi@cisco.com Thu Jul 12 02:00:21 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 5972F21F8607 for ; Thu, 12 Jul 2012 02:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 HVxHH6Cf2N0I for ; Thu, 12 Jul 2012 02:00:20 -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 456B421F8606 for ; Thu, 12 Jul 2012 02:00:20 -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 q6C8ktYK022452 for ; Thu, 12 Jul 2012 10:46:55 +0200 (CEST) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-31.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-31.cisco.com [10.147.74.31]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q6C8ksdD021653; Thu, 12 Jul 2012 10:46:54 +0200 (CEST) From: stefano previdi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2012 10:46:55 +0200 Message-Id: To: ppsp , zhangyunfei Zhang Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 09:00:21 -0000 All, =20 we're (re)spin the WG last call process for the problem statement and=20 requirements draft. Note that the doc (originally separated drafts)=20 went already through one cycle of WG and IESG review so we don't expect=20= massive/substantial updates. =20 Title : Problem Statement and Requirements of Peer-to-Peer = Streaming Protocol (PPSP) Author(s) : Yunfei Zhang Ning Zong Filename : draft-ietf-ppsp-problem-statement-09.txt =20 https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement =20 Thanks. =20 Yunfei & Stefano.= From rui.cruz@ieee-pt.org Thu Jul 12 02:18: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 2A1B521F875A for ; Thu, 12 Jul 2012 02:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.023 X-Spam-Level: X-Spam-Status: No, score=-103.023 tagged_above=-999 required=5 tests=[AWL=0.575, 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 GtBGztlZM0Dk for ; Thu, 12 Jul 2012 02:18:38 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0858421F8577 for ; Thu, 12 Jul 2012 02:18:37 -0700 (PDT) Received: by eekd4 with SMTP id d4so705396eek.31 for ; Thu, 12 Jul 2012 02:19:10 -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:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=mFz8MBDyNVekGz2Ery3cXreFbXwNge209BwoKZwRnh4=; b=lNQ67GDcjk6xN+FvyIT3wgfvAKklYiqUQg/N9VPeKc55dg6+dWeqrjKCcXCT++fc1X mn5ksMAMv+GU97tQxhirwIMjRR3u9+qxwejmMl68qitId5Ph1c295kdXZxJZh2oQXxmu CLQqIszkPPiqpzkxtDEOoPk8Qs+HfUF+cZgmcylLGnKqiFNo8rdoSly8/kbPX8CkiMnX qEGWVAPTdig4BOy8tXIdVC2ou3MTMbnqO/VLo1OLLmvuo3I5PN39SD4sgUirWqP30CSP 6wS7ROx3pAtY4HFbkcAMBoKf5OaIy83atWCs4CH3X0zomnssKmr+828UBsdUWfLorXgg LHfg== Received: by 10.14.28.11 with SMTP id f11mr3512561eea.136.1342084750070; Thu, 12 Jul 2012 02:19:10 -0700 (PDT) Received: from [192.168.1.222] ([89.180.11.223]) by mx.google.com with ESMTPS id t3sm13537466eeb.15.2012.07.12.02.19.06 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 02:19:09 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_9FF143F8-8C50-4251-98EA-70DDCDF6E791" From: Rui Cruz In-Reply-To: Date: Thu, 12 Jul 2012 10:19:04 +0100 Message-Id: <500D2A74-221C-4174-9E97-8007B8BF34FA@ieee.org> References: To: stefano previdi X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnMIB3stzKM9R/NtppCqMiX5hfEbOBrHt/wYmkhdbI1LGVVAWyd9eHURfpfpDXl3sc6dHro Cc: Rui Cruz , ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 09:18:40 -0000 --Apple-Mail=_9FF143F8-8C50-4251-98EA-70DDCDF6E791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, We would like to introduce a new Use Case that may be of interest. The description would be as follows: 5.4. Proxy service supporting P2P streaming=20 For applications where the Peer is not co-located with the Media Player = in the same device (e.g. the Peer is located in a Home Media Gateway), = we can use a P2P Proxy, as shown in figure 6. As shown in this figure 6, the P2P Proxy terminates the Tracker and Peer = protools, allowing the legacy presentation devices to access P2P = content. In this figure the DLNA protocol is used to communicate with = the presentation devices due to its wide deployement in the industry, = but of course other protocols can be used. +----------------------------------------------------------------+ | | | 0:Tracker Protocol +---------+ | | +----------------> | Tracker | | | | +---------+ | | | ^ | | | | | | | 2: | Tracker Protocol | | | | | | | +---------|-------------------------------------| | | | V | | | | +---------+ | | | +----------|---> | P2P |<-------------------+ | | | | | | Proxy | DLNA | | | | |3: Peer | +---------+ Protocol | | | | | Protocol | | | | | | | | | | V V | V | | +-----------+ | Home Domain +------------+ | | | Outward | | | DLNA Pres.| | | | Peer | | | Devices | | | +-----------+ | +------------+ | +----------------------------------------------------------------+ Figure 6 Proxy service Supporting P2P, with DLNA interface, for Home = application 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 12/07/2012, at 09:46, stefano previdi wrote: > All, >=20 > we're (re)spin the WG last call process for the problem statement and=20= > requirements draft. Note that the doc (originally separated drafts)=20 > went already through one cycle of WG and IESG review so we don't = expect=20 > massive/substantial updates. >=20 > Title : Problem Statement and Requirements of Peer-to-Peer = Streaming Protocol (PPSP) > Author(s) : Yunfei Zhang > Ning Zong > Filename : draft-ietf-ppsp-problem-statement-09.txt >=20 > https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement >=20 > Thanks. >=20 > Yunfei & Stefano. > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_9FF143F8-8C50-4251-98EA-70DDCDF6E791 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 5.4. Proxy = service supporting P2P streaming 

For applications where the Peer is = not co-located with the Media Player in the same = device (e.g. the Peer is located in a = Home Media Gateway), we can use a P2P Proxy, as shown in figure = 6.

As shown in this figure 6, the P2P = Proxy terminates the Tracker and Peer protools, allowing the legacy = presentation devices to access P2P content. In this figure the DLNA = protocol is used to communicate with the presentation devices due to its = wide deployement in the industry, but of course other protocols can be = used.

  =  +----------------------------------------------------------------+
   |           =                     =                     =              |
  =  |  0:Tracker Protocol +---------+         =                     =    |
   | =  +----------------> | Tracker |         =                     =    |
   |  |     =              +---------+   =                     =          |
  =  |  |                 =       ^               =                     =   |
   |  |     =                   |   =                     =               = |
   |  |         =            2: | Tracker Protocol   =                 =  |
   |  |         =               |       =                     =           |
  =  |  |             = +---------|-------------------------------------|
  =  |  |             |   =       V               =                     =   |
   |  |     =         |     +---------+     =                     =       |
   |  | =  +----------|---> |  P2P   =  |<-------------------+         =  |
   |  |  |       =    |     |  Proxy  |       = DLNA         |         =  |
   |  |  |3: Peer   |   =   +---------+       Protocol     |   =        |
  =  |  |  | Protocol |           =                     =      |         =  |
   |  |  |       =    |                 =                    | =          |
  =  |  V  V          |   =                     =              V       =    |
   |  +-----------+ | =        Home Domain         =    +------------+  |
  =  |  |  Outward  | |         =                     =   | DLNA  Pres.|  |
  =  |  |  Peer     | |         =                     =   | Devices    |  |
  =  |  +-----------+ |             =                   = +------------+  |
  =  +----------------------------------------------------------------+

Figure 6 Proxy service Supporting = P2P, with DLNA interface, for Home = application



Regards,

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

On 12/07/2012, at 09:46, stefano previdi wrote:

All,

we're (re)spin the WG last call process = for the problem statement and
requirements draft. Note that the doc = (originally separated drafts)
went already through one cycle of WG = and IESG review so we don't expect
massive/substantial = updates.

Title =           : Problem = Statement and Requirements of Peer-to-Peer Streaming Protocol = (PPSP)
Author(s)       : Yunfei = Zhang
=             &n= bsp;    Ning Zong
Filename =        : = draft-ietf-ppsp-problem-statement-09.txt

https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement
Thanks.

Yunfei & = Stefano.
_______________________________________________
ppsp = mailing = list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

= --Apple-Mail=_9FF143F8-8C50-4251-98EA-70DDCDF6E791-- From zhangyunfei@chinamobile.com Thu Jul 12 02:33:33 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 2456A21F857D for ; Thu, 12 Jul 2012 02:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.78 X-Spam-Level: X-Spam-Status: No, score=-97.78 tagged_above=-999 required=5 tests=[AWL=0.843, 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 h7ZPjoGMtDyR for ; Thu, 12 Jul 2012 02:33:32 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C8A8F21F8543 for ; Thu, 12 Jul 2012 02:33:31 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A3E00E502; Thu, 12 Jul 2012 17:34:04 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 938C7E3C1; Thu, 12 Jul 2012 17:34:04 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071217340285-50285 ; Thu, 12 Jul 2012 17:34:02 +0800 Date: Thu, 12 Jul 2012 17:33:57 +0800 From: zhangyunfei To: "'Rui Cruz'" , "stefano previdi" References: , <500D2A74-221C-4174-9E97-8007B8BF34FA@ieee.org> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012071217335750147860@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-12 17:34:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-12 17:34:04, Serialize complete at 2012-07-12 17:34:04 Content-Type: multipart/alternative; boundary="----=_001_NextPart846026424270_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19034.006 X-TM-AS-Result: No--37.401-7.0-31-10 X-imss-scan-details: No--37.401-7.0-31-10;No--37.401-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: 'Rui Cruz' , ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement 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, 12 Jul 2012 09:33:33 -0000 This is a multi-part message in MIME format. ------=_001_NextPart846026424270_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgUnVpLA0KICAgIFRoYW5rcyBmb3IgdGhlIGNvbnRyaWJ1dGlvbi4gSSBsaWtlIHRoaXMgdXNl IGNhc2UuDQogICAgSSBoYXBwZW4gdG8gdGhpbmsgb2Ygb25lIHNpbWlsYXIgb25lOiBQbHVnLWlu cyBzdXBwb3J0aW5nIFAyUCBzdHJlYW1pbmcgd2hlcmUgcGx1Zy1pbnMgYXJlIG9mdGVuIHVzZWQg aW4gYnJvd3Nlci1iYXNlZCBlbnZpcm9ubWVudCBhbmQgd2l0aCBwbHVnLWlucyBodHRwIGJhc2Vk IHN0cmVhbWluZyBjYW4gYmUgdHVybmVkIGludG8gYSBkZSBmYWN0byBQMlAgc3RyZWFtaW5nKCBG b3IgdGhlIHVzZXJzIGFuZCBicm93c2VycywgaXQncyBqdXN0IGh0dHAgYmFzZWQgc3RyZWFtaW5n IGJ1dCB0aGUgcGx1Zy1pbnMgYXJlIGVxdWlwcGVkIHdpdGggUFBTUCBjYW4gYWN0dWFsbHkgYWNj ZWxlcmF0ZSB0aGUgcHJvY2VzcyBmcm9tIG11bHRpcGxlIHNvdXJjZXMvcGVlcnMuIEluIHRoaXMg Y2FzZSB0aGUgcGx1Zy1pbnMgYXJlIGp1c3QgbGlrZSB0aGUgcHJveHkuDQogICBDYW4gd2UgbWVy Z2UgdGhlbSB0b2dldGhlcj8NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpG cm9tOiBSdWkgQ3J1eg0KRGF0ZTogMjAxMi0wNy0xMiAxNzoxOQ0KVG86IHN0ZWZhbm8gcHJldmlk aQ0KQ0M6IFJ1aSBDcnV6OyBwcHNwOyB6aGFuZ3l1bmZlaSBaaGFuZw0KU3ViamVjdDogUmU6IFtw cHNwXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudA0K SGksDQoNCg0KV2Ugd291bGQgbGlrZSB0byBpbnRyb2R1Y2UgYSBuZXcgVXNlIENhc2UgdGhhdCBt YXkgYmUgb2YgaW50ZXJlc3QuDQoNCg0KVGhlIGRlc2NyaXB0aW9uIHdvdWxkIGJlIGFzIGZvbGxv d3M6DQoNCg0KDQoNCjUuNC4gUHJveHkgc2VydmljZSBzdXBwb3J0aW5nIFAyUCBzdHJlYW1pbmcg DQoNCg0KRm9yIGFwcGxpY2F0aW9ucyB3aGVyZSB0aGUgUGVlciBpcyBub3QgY28tbG9jYXRlZCB3 aXRoIHRoZSBNZWRpYSBQbGF5ZXIgaW4gdGhlIHNhbWUgZGV2aWNlIChlLmcuIHRoZSBQZWVyIGlz IGxvY2F0ZWQgaW4gYSBIb21lIE1lZGlhIEdhdGV3YXkpLCB3ZSBjYW4gdXNlIGEgUDJQIFByb3h5 LCBhcyBzaG93biBpbiBmaWd1cmUgNi4NCg0KDQpBcyBzaG93biBpbiB0aGlzIGZpZ3VyZSA2LCB0 aGUgUDJQIFByb3h5IHRlcm1pbmF0ZXMgdGhlIFRyYWNrZXIgYW5kIFBlZXIgcHJvdG9vbHMsIGFs bG93aW5nIHRoZSBsZWdhY3kgcHJlc2VudGF0aW9uIGRldmljZXMgdG8gYWNjZXNzIFAyUCBjb250 ZW50LiBJbiB0aGlzIGZpZ3VyZSB0aGUgRExOQSBwcm90b2NvbCBpcyB1c2VkIHRvIGNvbW11bmlj YXRlIHdpdGggdGhlIHByZXNlbnRhdGlvbiBkZXZpY2VzIGR1ZSB0byBpdHMgd2lkZSBkZXBsb3ll bWVudCBpbiB0aGUgaW5kdXN0cnksIGJ1dCBvZiBjb3Vyc2Ugb3RoZXIgcHJvdG9jb2xzIGNhbiBi ZSB1c2VkLg0KDQoNCiAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICAwOlRyYWNrZXIg UHJvdG9jb2wgKy0tLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg IHwgICstLS0tLS0tLS0tLS0tLS0tPiB8IFRyYWNrZXIgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgfCAgfCAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0rICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICAgICAgICAgICAgICAgICAgICAgICBe ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHwgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg fCAgfCAgICAgICAgICAgICAgICAgICAgMjogfCBUcmFja2VyIFByb3RvY29sICAgICAgICAgICAg ICAgICAgICB8DQogICB8ICB8ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHwgICAgICAgICAgICAgKy0tLS0tLS0tLXwt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KICAgfCAgfCAgICAgICAgICAg ICB8ICAgICAgICAgViAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8 ICB8ICAgICAgICAgICAgIHwgICAgICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgIHwgIHwgICstLS0tLS0tLS0tfC0tLT4gfCAgUDJQICAgIHw8LS0tLS0tLS0t LS0tLS0tLS0tLSsgICAgICAgICAgfA0KICAgfCAgfCAgfCAgICAgICAgICB8ICAgICB8ICBQcm94 eSAgfCAgICAgICBETE5BICAgICAgICAgfCAgICAgICAgICB8DQogICB8ICB8ICB8MzogUGVlciAg IHwgICAgICstLS0tLS0tLS0rICAgICAgIFByb3RvY29sICAgICB8ICAgICAgICAgIHwNCiAgIHwg IHwgIHwgUHJvdG9jb2wgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgfA0KICAgfCAgfCAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICB8DQogICB8ICBWICBWICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgIHwNCiAgIHwgICstLS0tLS0tLS0tLSsg fCAgICAgICAgSG9tZSBEb21haW4gICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAgfA0KICAgfCAg fCAgT3V0d2FyZCAgfCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgRExOQSAgUHJl cy58ICB8DQogICB8ICB8ICBQZWVyICAgICB8IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCBEZXZpY2VzICAgIHwgIHwNCiAgIHwgICstLS0tLS0tLS0tLSsgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKyAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCg0KRmln dXJlIDYgUHJveHkgc2VydmljZSBTdXBwb3J0aW5nIFAyUCwgd2l0aCBETE5BIGludGVyZmFjZSwg Zm9yIEhvbWUgYXBwbGljYXRpb24NCg0KDQoNCg0KDQpSZWdhcmRzLA0KDQoNClJ1aSBDcnV6DQpy dWkuY3J1ekBpZWVlLm9yZw0KDQoNCklTVC9JTkVTQy1JRC9JTk9WIC0gTGlzYm9uLCBQb3J0dWdh bA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxp bmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wcHNwDQoNCg0KT24gMTIvMDcvMjAxMiwgYXQgMDk6NDYsIHN0ZWZhbm8gcHJldmlkaSB3 cm90ZToNCg0KDQpBbGwsDQoNCndlJ3JlIChyZSlzcGluIHRoZSBXRyBsYXN0IGNhbGwgcHJvY2Vz cyBmb3IgdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCANCnJlcXVpcmVtZW50cyBkcmFmdC4gTm90 ZSB0aGF0IHRoZSBkb2MgKG9yaWdpbmFsbHkgc2VwYXJhdGVkIGRyYWZ0cykgDQp3ZW50IGFscmVh ZHkgdGhyb3VnaCBvbmUgY3ljbGUgb2YgV0cgYW5kIElFU0cgcmV2aWV3IHNvIHdlIGRvbid0IGV4 cGVjdCANCm1hc3NpdmUvc3Vic3RhbnRpYWwgdXBkYXRlcy4NCg0KVGl0bGUgICAgICAgICAgIDog UHJvYmxlbSBTdGF0ZW1lbnQgYW5kIFJlcXVpcmVtZW50cyBvZiBQZWVyLXRvLVBlZXIgU3RyZWFt aW5nIFByb3RvY29sIChQUFNQKQ0KQXV0aG9yKHMpICAgICAgIDogWXVuZmVpIFpoYW5nDQogICAg ICAgICAgICAgICAgIE5pbmcgWm9uZw0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1wcHNw LXByb2JsZW0tc3RhdGVtZW50LTA5LnR4dA0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLXBwc3AtcHJvYmxlbS1zdGF0ZW1lbnQNCg0KVGhhbmtzLg0KDQpZdW5m ZWkgJiBTdGVmYW5vLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart846026424270_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Rui,
    Thanks for the contribution. I like this use case.=
    I happen to think of one similar one: Plug-ins=20 supporting P2P streaming where plug-ins are often used in browser-based=20 environment and with plug-ins http based streaming can be turned into a de facto P2P streaming( For the users and browsers, it's just http ba= sed=20 streaming but the plug-ins are equipped with PPSP can=20 actually accelerate the process from multiple sources/peers. In this = case=20 the plug-ins are just like the proxy.
   Can we merge them together?
 
BR
Yunfei
 
zhangyunfei
 
From: Rui Cruz
Date: 2012-07-12 17:19
CC: Rui Cruz; ppsp; zhangyunfei Zhang
Subject: Re: [ppsp] WG Last Call for=20 draft-ietf-ppsp-problem-statement
Hi,

We would like to introduce a new Use Case that may be of interest.

The description would be as follows:


5.4. Pr= oxy service=20 supporting P2P streaming 

For app= lications=20 where the Peer is not co-located with the Media Player in the same=20 device (e.g. the Peer is located in a Home Media Gateway= ), we=20 can use a P2P Proxy, as shown in figure 6.

As show= n in this=20 figure 6, the P2P Proxy terminates the Tracker and Peer protools, allowing= the=20 legacy presentation devices to access P2P content. In this figure the DLNA= =20 protocol is used to communicate with the presentation devices due to its w= ide=20 deployement in the industry, but of course other protocols can be=20 used.

 =20  +----------------------------------------------------------------+
  =  |=20                     &nbs= p;=20                     &nbs= p;=20                  =20  |
  =  |=20  0:Tracker Protocol +---------+           &n= bsp;=20                  =20  |
  =  |=20  +----------------> | Tracker |          = =20                    =20  |
  =  |=20  |                =20  +---------+                 =  =20              |
  =  |=20  |                   &nb= sp;=20   ^                   &n= bsp;=20                 |
  =  |=20  |                   &nb= sp;=20   |                   &n= bsp;=20                 |
  =  |=20  |                   &nb= sp;2:=20 | Tracker Protocol                = =20    |
  =  |=20  |                   &nb= sp;=20   |                   &n= bsp;=20                 |
  =  |=20  |            =20 +---------|-------------------------------------|
  =  |=20  |             |       &= nbsp;=20 V                     &n= bsp;=20               |
  =  |=20  |             |     +-------= --+=20                     &nbs= p;=20         |
  =  |=20  |  +----------|---> |  P2P  =20  |<-------------------+          |=
  =  |=20  |  |          |     |  = Proxy=20  |       DLNA         |   &nb= sp;=20      |
  =  |=20  |  |3: Peer   |     +---------+     &n= bsp;=20 Protocol     |          |
  =  |=20  |  | Protocol |              = ;=20                     &nbs= p;|=20          |
  =  |=20  |  |          |       &= nbsp;=20                     &nbs= p;=20      |          |
  =  |=20  V  V          |       &= nbsp;=20                     &nbs= p;=20      V          |
  =  |=20  +-----------+ |        Home Domain    = =20        +------------+  |
  =  |=20  |  Outward  | |             =  =20                 | DLNA  Pres.= |=20  |
  =  |=20  |  Peer     | |           &n= bsp;=20                   | Devices &= nbsp;=20  |  |
  =  |=20  +-----------+ |               &nb= sp;=20               +------------+=20  |
 =20  +----------------------------------------------------------------+

Figure = 6 Proxy=20 service Supporting P2P, with DLNA interface, for Home application


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 12/07/2012, at 09:46, stefano previdi wrote:
All,

we're (re)spin the WG last call process for the problem= =20 statement and
requirements draft. Note that the doc (originally sepa= rated=20 drafts)
went already through one cycle of WG and IESG review so we d= on't=20 expect
massive/substantial updates.

Title=20           : Problem=20 Statement and Requirements of Peer-to-Peer Streaming Protocol=20 (PPSP)
Author(s)       : Yunfei=20 Zhang
          &nb= sp;      Ning=20 Zong
Filename        :=20 draft-ietf-ppsp-problem-statement-09.txt

https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement=

Thanks.

Yunfei=20 & Stefano.
_______________________________________________
pps= p=20 mailing=20 list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
<= /DIV>

------=_001_NextPart846026424270_=------ From rui.cruz@ieee-pt.org Thu Jul 12 03:57:56 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 11BED21F881E for ; Thu, 12 Jul 2012 03:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.215 X-Spam-Level: X-Spam-Status: No, score=-103.215 tagged_above=-999 required=5 tests=[AWL=0.383, 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 MZEAXZ6SuS+4 for ; Thu, 12 Jul 2012 03:57:55 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE2921F881D for ; Thu, 12 Jul 2012 03:57:54 -0700 (PDT) Received: by eekd4 with SMTP id d4so748438eek.31 for ; Thu, 12 Jul 2012 03:58:26 -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=7WUyd4qrd7HzYSYgKygqjekbbZzh3Hy/KhJxrzGAl+8=; b=LJpj8Avof9hjr9Q6ukMFEK9uXxvIkzW3RMs9PuZbI0RuNwz2+IIZDojPzxqF6ce6Qy HDsDPZYpP3jleCR7gKyy0RqoAYym+lliddL6IfCjP/ishgND/Gw7n3YMIaOY8DqebXer bB9fdhMbgpfBmTzYA4jRjjVqSUmPrVDSBKsaBcgOliQDcIMH7tCqovmGJLeftKF4dNeN j527Wno2Z8Gyfz0AyjU2r4QOkXhAlhscMhpIEMNs4IVgvzgeIFRDWJuVOALDO4hoWaoi shWAy/xglv1lsZDVPtGDBwW5f9L1bnysZ1LcpvgqQH9KzcFFN81xFBea9f4WiApA4UOI RcfQ== Received: by 10.14.99.198 with SMTP id x46mr516950eef.222.1342090706405; Thu, 12 Jul 2012 03:58:26 -0700 (PDT) Received: from [192.168.1.222] ([89.180.11.223]) by mx.google.com with ESMTPS id e45sm14449119eeb.6.2012.07.12.03.58.22 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 03:58:25 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_E69A79AB-E6E4-44BE-B079-931FA780FD47" From: Rui Cruz X-Priority: 3 (Normal) In-Reply-To: <2012071217335750147860@chinamobile.com> Date: Thu, 12 Jul 2012 11:58:20 +0100 Message-Id: References: , <500D2A74-221C-4174-9E97-8007B8BF34FA@ieee.org> <2012071217335750147860@chinamobile.com> To: zhangyunfei X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk9LwUIXA0FN4T8QzsZuaY+O4yigrIthWsPodMVzBQpD4ZnlaNarLOkx0QMURx2d1HHC4gb Cc: Rui Cruz , ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 10:57:56 -0000 --Apple-Mail=_E69A79AB-E6E4-44BE-B079-931FA780FD47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi Yunfei, I am happy that you like the Use Case. =46rom your other description, it reminds me of an existing solution = that I have tested and works quite well: http://www.littleshoot.org/ It just requires a browser, and via a plugin, launches a P2P proxy = process to make P2P HTTP-based downloading. I also like your Use Case, but I think it deserves to be a new one (5.5 = Proxy service for Browser-based HTTP streaming). 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 12/07/2012, at 10:33, zhangyunfei wrote: > Hi Rui, > Thanks for the contribution. I like this use case. > I happen to think of one similar one: Plug-ins supporting P2P = streaming where plug-ins are often used in browser-based environment and = with plug-ins http based streaming can be turned into a de facto P2P = streaming( For the users and browsers, it's just http based streaming = but the plug-ins are equipped with PPSP can actually accelerate the = process from multiple sources/peers. In this case the plug-ins are just = like the proxy. > Can we merge them together? > =20 > BR > Yunfei > =20 > zhangyunfei > =20 > From: Rui Cruz > Date: 2012-07-12 17:19 > To: stefano previdi > CC: Rui Cruz; ppsp; zhangyunfei Zhang > Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement > Hi, >=20 > We would like to introduce a new Use Case that may be of interest. >=20 > The description would be as follows: >=20 >=20 > 5.4. Proxy service supporting P2P streaming=20 >=20 > For applications where the Peer is not co-located with the Media = Player in the same device (e.g. the Peer is located in a Home Media = Gateway), we can use a P2P Proxy, as shown in figure 6. >=20 > As shown in this figure 6, the P2P Proxy terminates the Tracker and = Peer protools, allowing the legacy presentation devices to access P2P = content. In this figure the DLNA protocol is used to communicate with = the presentation devices due to its wide deployement in the industry, = but of course other protocols can be used. >=20 > +----------------------------------------------------------------+ > | | > | 0:Tracker Protocol +---------+ | > | +----------------> | Tracker | | > | | +---------+ | > | | ^ | > | | | | > | | 2: | Tracker Protocol | > | | | | > | | +---------|-------------------------------------| > | | | V | > | | | +---------+ | > | | +----------|---> | P2P |<-------------------+ | > | | | | | Proxy | DLNA | | > | | |3: Peer | +---------+ Protocol | | > | | | Protocol | | | > | | | | | | > | V V | V | > | +-----------+ | Home Domain +------------+ | > | | Outward | | | DLNA Pres.| | > | | Peer | | | Devices | | > | +-----------+ | +------------+ | > +----------------------------------------------------------------+ >=20 > Figure 6 Proxy service Supporting P2P, with DLNA interface, for Home = application >=20 >=20 >=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 12/07/2012, at 09:46, stefano previdi wrote: >=20 >> All, >>=20 >> we're (re)spin the WG last call process for the problem statement and=20= >> requirements draft. Note that the doc (originally separated drafts)=20= >> went already through one cycle of WG and IESG review so we don't = expect=20 >> massive/substantial updates. >>=20 >> Title : Problem Statement and Requirements of Peer-to-Peer = Streaming Protocol (PPSP) >> Author(s) : Yunfei Zhang >> Ning Zong >> Filename : draft-ietf-ppsp-problem-statement-09.txt >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement >>=20 >> Thanks. >>=20 >> Yunfei & Stefano. >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_E69A79AB-E6E4-44BE-B079-931FA780FD47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=GB2312 Hi Yunfei,

I am happy that you = like the Use Case.

=46rom your other = description, it reminds me of an existing solution that I have tested = and works quite well: http://www.littleshoot.org/
=
It just requires a browser, and via a plugin, launches a P2P proxy = process to make P2P HTTP-based downloading.

I = also like your Use Case, but  I think it deserves to be a new one = (5.5 Proxy service for Browser-based HTTP streaming).

Regards,

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

On 12/07/2012, at 10:33, zhangyunfei wrote:

Hi = Rui,
    Thanks for the contribution. I like = this use case.
    I happen to think of one = similar one: Plug-ins supporting P2P streaming where plug-ins are often = used in browser-based environment and with plug-ins http based streaming = can be turned into a de facto P2P streaming( For the users and = browsers, it's just http based streaming but the plug-ins = are equipped with PPSP can actually accelerate the process = from multiple sources/peers. In this case the plug-ins are just like the = proxy.
   Can we merge them = together?
 
BR
Yunfei
 <= /div>
Date: 2012-07-12 17:19
Subject: Re: [ppsp] WG Last Call for = draft-ietf-ppsp-problem-statement
Hi,

We would like to introduce a = new Use Case that may be of interest.

The = description would be as = follows:


5.4. Proxy = service supporting P2P streaming 

For applications where the Peer is = not co-located with the Media Player in the same = device (e.g. the Peer is located in a Home = Media Gateway), we can use a P2P Proxy, as shown in figure = 6.

As shown in this figure 6, the P2P = Proxy terminates the Tracker and Peer protools, allowing the  legacy presentation = devices to access P2P content. In this figure the DLNA protocol is used = to communicate with the presentation devices due to its wide deployement = in the industry, but of course other protocols can be = used.

  =  +----------------------------------------------------------------+
   |           =                     =                     =              |
  =  |  0:Tracker Protocol +---------+         =                     =    |
   | =  +----------------> | Tracker |         =                     =    |
   |  |     =              +---------+   =                     =          |
  =  |  |                 =       ^               =                     =   |
   |  |     =                   |   =                     =               = |
   |  |         =            2: | Tracker Protocol   =                 =  |
   |  |     =                   |   =                     =               = |
   |  |         =     = +---------|-------------------------------------|
  =  |  |             |   =       V               =                     =   |
   |  |     =         |     +---------+     =                     =       |
   |  | =  +----------|---> |  P2P   =  |<-------------------+         =  |
   |  |  |   =        |     |  Proxy  |   =     DLNA         |       =    |
   |  |  |3: Peer =   |     +---------+       Protocol   =   |          |
  =  |  |  | Protocol |           =                     =      |         =  |
   |  |  |   =        |             =                     =    |         =  |
   |  V  V   =        |             =                     =    V         =  |
   |  +-----------+ | =        Home Domain         =    +------------+  |
  =  |  |  Outward  | |         =                     =   | DLNA  Pres.|  |
  =  |  |  Peer     | |         =                     =   | Devices    |  |
  =  |  +-----------+ |             =                   = +------------+  |
  =  +----------------------------------------------------------------+

Figure 6 Proxy service Supporting = P2P, with DLNA interface, for Home = application



Regards,

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

On 12/07/2012, = at 09:46, stefano previdi wrote:

 
requirements draft. = Note that the doc (originally separated drafts) 
went already through = one cycle of WG and IESG review so we don't expect 
massive/substantial = updates.

Title =           : Problem = Statement and Requirements of Peer-to-Peer Streaming Protocol = (PPSP)
Author(s)       : Yunfei = Zhang
           = ;      Ning Zong
Filename =        : = draft-ietf-ppsp-problem-statement-09.txt

https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement
Thanks.

Yunfei & = Stefano.
_______________________________________________
ppsp = mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

____= ___________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/m= ailman/listinfo/ppsp
<= /html>= --Apple-Mail=_E69A79AB-E6E4-44BE-B079-931FA780FD47-- From yry@cs.yale.edu Thu Jul 12 08:34: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 92DE311E808A for ; Thu, 12 Jul 2012 08:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0RVaGkhQNsm for ; Thu, 12 Jul 2012 08:34:29 -0700 (PDT) Received: from vm-emlprdomr-05.its.yale.edu (vm-emlprdomr-05.its.yale.edu [130.132.50.146]) by ietfa.amsl.com (Postfix) with ESMTP id ED08221F86F6 for ; Thu, 12 Jul 2012 08:34:28 -0700 (PDT) Received: from [192.168.1.108] ([221.221.18.192]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id q6CFYaBx015640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jul 2012 11:34:40 -0400 Message-ID: <4FFEEE88.6010504@cs.yale.edu> Date: Thu, 12 Jul 2012 23:34:32 +0800 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Rui Cruz References: , <500D2A74-221C-4174-9E97-8007B8BF34FA@ieee.org> <2012071217335750147860@chinamobile.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090400090105080407010206" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 Cc: ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 15:34:30 -0000 This is a multi-part message in MIME format. --------------090400090105080407010206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Yunfei and Rui, The idea of showing a use case of a proxy is good and helpful. One short comment is that I am not sure if it needs two sub sections 5.4/5.5. Maybe a single P2P proxy subsec is enough? Inside the subsec, it can mention multiple instances. Just a short suggestion that you may consider. Thanks! Richard On 7/12/12 6:58 PM, Rui Cruz wrote: > Hi Yunfei, > > I am happy that you like the Use Case. > > From your other description, it reminds me of an existing solution > that I have tested and works quite well: http://www.littleshoot.org/ > It just requires a browser, and via a plugin, launches a P2P proxy > process to make P2P HTTP-based downloading. > > I also like your Use Case, but I think it deserves to be a new one > (5.5 Proxy service for Browser-based HTTP streaming). > > 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 12/07/2012, at 10:33, zhangyunfei wrote: > >> Hi Rui, >> Thanks for the contribution. I like this use case. >> I happen to think of one similar one: Plug-ins supporting P2P >> streaming where plug-ins are often used in browser-based environment >> and with plug-ins http based streaming can be turned into a de facto >> P2P streaming( For the users and browsers, it's just http based >> streaming but the plug-ins are equipped with PPSP can >> actually accelerate the process from multiple sources/peers. In this >> case the plug-ins are just like the proxy. >> Can we merge them together? >> BR >> Yunfei >> ------------------------------------------------------------------------ >> zhangyunfei >> *From:* Rui Cruz >> *Date:* 2012-07-12 17:19 >> *To:* stefano previdi >> *CC:* Rui Cruz ;ppsp >> ;zhangyunfei Zhang >> >> *Subject:* Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement >> Hi, >> >> We would like to introduce a new Use Case that may be of interest. >> >> The description would be as follows: >> >> >> 5.4. Proxy service supporting P2P streaming >> >> For applications where the Peer is not co-located with the Media >> Player in the same device (e.g. the Peer is located in a Home Media >> Gateway), we can use a P2P Proxy, as shown in figure 6. >> >> As shown in this figure 6, the P2P Proxy terminates the Tracker and >> Peer protools, allowing thelegacy presentation devices to access P2P >> content. In this figure the DLNA protocol is used to communicate with >> the presentation devices due to its wide deployement in the industry, >> but of course other protocols can be used. >> >> +----------------------------------------------------------------+ >> | | >> | 0:Tracker Protocol +---------+ | >> | +----------------> | Tracker | | >> | | +---------+ | >> | | ^ | >> | | | | >> | | 2: | Tracker Protocol | >> | | | | >> | | +---------|-------------------------------------| >> | | | V | >> | | | +---------+ | >> | | +----------|---> | P2P |<-------------------+ | >> | | | | | Proxy | DLNA | | >> | | |3: Peer | +---------+ Protocol | | >> | | | Protocol | | | >> | | | | | | >> | V V | V | >> | +-----------+ | Home Domain +------------+ | >> | | Outward | | | DLNA Pres.| | >> | | Peer | | | Devices | | >> | +-----------+ | +------------+ | >> +----------------------------------------------------------------+ >> >> Figure 6 Proxy service Supporting P2P, with DLNA interface, for Home >> application >> >> >> >> 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 12/07/2012, at 09:46, stefano previdi wrote: >> >>> All, >>> >>> we're (re)spin the WG last call process for the problem statement and >>> requirements draft. Note that the doc (originally separated drafts) >>> went already through one cycle of WG and IESG review so we don't expect >>> massive/substantial updates. >>> >>> Title : Problem Statement and Requirements of Peer-to-Peer >>> Streaming Protocol (PPSP) >>> Author(s) : Yunfei Zhang >>> Ning Zong >>> Filename : draft-ietf-ppsp-problem-statement-09.txt >>> >>> https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement >>> >>> Thanks. >>> >>> Yunfei & Stefano. >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >> >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp > > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --------------090400090105080407010206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Yunfei and Rui,

The idea of showing a use case of a proxy is good and helpful. One short comment is that I am not sure if it needs two sub sections 5.4/5.5. Maybe a single P2P proxy subsec is enough? Inside the subsec, it can mention multiple instances. Just a short suggestion that you may consider.

Thanks!

Richard

On 7/12/12 6:58 PM, Rui Cruz wrote:
Hi Yunfei,

I am happy that you like the Use Case.

From your other description, it reminds me of an existing solution that I have tested and works quite well: http://www.littleshoot.org/
It just requires a browser, and via a plugin, launches a P2P proxy process to make P2P HTTP-based downloading.

I also like your Use Case, but  I think it deserves to be a new one (5.5 Proxy service for Browser-based HTTP streaming).

Regards,

Rui Cruz

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list

On 12/07/2012, at 10:33, zhangyunfei wrote:

Hi Rui,
    Thanks for the contribution. I like this use case.
    I happen to think of one similar one: Plug-ins supporting P2P streaming where plug-ins are often used in browser-based environment and with plug-ins http based streaming can be turned into a de facto P2P streaming( For the users and browsers, it's just http based streaming but the plug-ins are equipped with PPSP can actually accelerate the process from multiple sources/peers. In this case the plug-ins are just like the proxy.
   Can we merge them together?
 
BR
Yunfei
 
zhangyunfei
 
From: Rui Cruz
Date: 2012-07-12 17:19
Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement
Hi,

We would like to introduce a new Use Case that may be of interest.

The description would be as follows:


5.4. Proxy service supporting P2P streaming 

For applications where the Peer is not co-located with the Media Player in the same device (e.g. the Peer is located in a Home Media Gateway), we can use a P2P Proxy, as shown in figure 6.

As shown in this figure 6, the P2P Proxy terminates the Tracker and Peer protools, allowing the  legacy presentation devices to access P2P content. In this figure the DLNA protocol is used to communicate with the presentation devices due to its wide deployement in the industry, but of course other protocols can be used.

   +----------------------------------------------------------------+
   |                                                                |
   |  0:Tracker Protocol +---------+                                |
   |  +----------------> | Tracker |                                |
   |  |                  +---------+                                |
   |  |                       ^                                     |
   |  |                       |                                     |
   |  |                    2: | Tracker Protocol                    |
   |  |                       |                                     |
   |  |             +---------|-------------------------------------|
   |  |             |         V                                     |
   |  |             |     +---------+                               |
   |  |  +----------|---> |  P2P    |<-------------------+          |
   |  |  |          |     |  Proxy  |       DLNA         |          |
   |  |  |3: Peer   |     +---------+       Protocol     |          |
   |  |  | Protocol |                                    |          |
   |  |  |          |                                    |          |
   |  V  V          |                                    V          |
   |  +-----------+ |        Home Domain            +------------+  |
   |  |  Outward  | |                               | DLNA  Pres.|  |
   |  |  Peer     | |                               | Devices    |  |
   |  +-----------+ |                               +------------+  |
   +----------------------------------------------------------------+

Figure 6 Proxy service Supporting P2P, with DLNA interface, for Home application



Regards,

Rui Cruz

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list

On 12/07/2012, at 09:46, stefano previdi wrote:

All,

we're (re)spin the WG last call process for the problem statement and 
requirements draft. Note that the doc (originally separated drafts) 
went already through one cycle of WG and IESG review so we don't expect 
massive/substantial updates.

Title           : Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)
Author(s)       : Yunfei Zhang
                 Ning Zong
Filename        : draft-ietf-ppsp-problem-statement-09.txt

https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement

Thanks.

Yunfei & Stefano.
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp



_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

--------------090400090105080407010206-- From rui.cruz@ieee-pt.org Thu Jul 12 08:55:09 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9911E8073 for ; Thu, 12 Jul 2012 08:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwvxVg8pbEgr for ; Thu, 12 Jul 2012 08:55:08 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 74E3D21F85C6 for ; Thu, 12 Jul 2012 08:55:07 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1589041wgb.13 for ; Thu, 12 Jul 2012 08:55:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=oAORKlnYuwp6ve4tx5+1vA9tim8VZftgJ2CbXIPmQ4U=; b=S1I+MAUAYO4CVI1gPArwVr3g8MZzg4Nws74uJW/je0X1kS+XNm9NaDhsKFjESr5AeA 2wC8p/Sc5HtE47KIVTnt8t4kRj0da+APdil1/yabV6xC1+DiDvENQ1O2Y/PW9lVWNEnl ObQqpcY3c3W7KdPPeMRDO3hBFxJuSEY+4oDRB1/1FE2C1KdoQUWCJzSXLYk82TG8Xilc +TtaCvGrAOp7qo2zscVwZ0Oqge8Lb3aboVaNTB7g6ObeRQFTsPqgMmmEc9oBRsbx2W4l /UuDgiuMnXiXOs15ciC3n4tnYUT/WZeiEa1yC4+zBkr4ToHVEsqPIxIWiyovGahIXwI5 21VQ== Received: by 10.180.81.193 with SMTP id c1mr29620324wiy.12.1342108539443; Thu, 12 Jul 2012 08:55:39 -0700 (PDT) Received: from [192.168.1.101] (62.169.125.218.rev.optimus.pt. [62.169.125.218]) by mx.google.com with ESMTPS id t7sm14245159wix.6.2012.07.12.08.55.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 08:55:38 -0700 (PDT) References: <500D2A74-221C-4174-9E97-8007B8BF34FA@ieee.org> <2012071217335750147860@chinamobile.com> <4FFEEE88.6010504@cs.yale.edu> In-Reply-To: <4FFEEE88.6010504@cs.yale.edu> Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-8433DB63-DC4E-4776-A141-2678D4A1829C Message-Id: <43DD5F3C-FCA8-4EBB-9157-980F6E9A38A2@ieee-pt.org> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (9B206) From: Rui Cruz Date: Thu, 12 Jul 2012 16:56:48 +0100 To: "Y. Richard Yang" X-Gm-Message-State: ALoCoQnxILAU8oXoKo2UW01489mK9nwkF4/MEk+DsEiBOE7WYmlX//jmhmzul45A+iFtuAl/oj0n Cc: Rui Cruz , ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 15:55:09 -0000 --Apple-Mail-8433DB63-DC4E-4776-A141-2678D4A1829C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Richard and Yunfei, Sub-sections on P2P proxy use case seems a good idea. Cumprimentos/Regards, Rui Cruz Sent from my iPad2 On 12/07/2012, at 16:34, "Y. Richard Yang" wrote: > Hi Yunfei and Rui, >=20 > The idea of showing a use case of a proxy is good and helpful. One short c= omment is that I am not sure if it needs two sub sections 5.4/5.5. Maybe a s= ingle P2P proxy subsec is enough? Inside the subsec, it can mention multiple= instances. Just a short suggestion that you may consider. >=20 > Thanks! >=20 > Richard >=20 > On 7/12/12 6:58 PM, Rui Cruz wrote: >> Hi Yunfei, >>=20 >> I am happy that you like the Use Case. >>=20 >> =46rom your other description, it reminds me of an existing solution that= I have tested and works quite well: http://www.littleshoot.org/ >> It just requires a browser, and via a plugin, launches a P2P proxy proces= s to make P2P HTTP-based downloading. >>=20 >> I also like your Use Case, but I think it deserves to be a new one (5.5 P= roxy service for Browser-based HTTP streaming). >>=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 12/07/2012, at 10:33, zhangyunfei wrote: >>=20 >>> Hi Rui, >>> Thanks for the contribution. I like this use case. >>> I happen to think of one similar one: Plug-ins supporting P2P stream= ing where plug-ins are often used in browser-based environment and with plug= -ins http based streaming can be turned into a de facto P2P streaming( For t= he users and browsers, it's just http based streaming but the plug-ins are e= quipped with PPSP can actually accelerate the process from multiple sources/= peers. In this case the plug-ins are just like the proxy. >>> Can we merge them together? >>> =20 >>> BR >>> Yunfei >>> =20 >>> zhangyunfei >>> =20 >>> From: Rui Cruz >>> Date: 2012-07-12 17:19 >>> To: stefano previdi >>> CC: Rui Cruz; ppsp; zhangyunfei Zhang >>> Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement >>> Hi, >>>=20 >>> We would like to introduce a new Use Case that may be of interest. >>>=20 >>> The description would be as follows: >>>=20 >>>=20 >>> 5.4. Proxy service supporting P2P streaming=20 >>>=20 >>> For applications where the Peer is not co-located with the Media Player i= n the same device (e.g. the Peer is located in a Home Media Gateway), we can= use a P2P Proxy, as shown in figure 6. >>>=20 >>> As shown in this figure 6, the P2P Proxy terminates the Tracker and Peer= protools, allowing the legacy presentation devices to access P2P content. I= n this figure the DLNA protocol is used to communicate with the presentation= devices due to its wide deployement in the industry, but of course other pr= otocols can be used. >>>=20 >>> +----------------------------------------------------------------+ >>> | | >>> | 0:Tracker Protocol +---------+ | >>> | +----------------> | Tracker | | >>> | | +---------+ | >>> | | ^ | >>> | | | | >>> | | 2: | Tracker Protocol | >>> | | | | >>> | | +---------|-------------------------------------| >>> | | | V | >>> | | | +---------+ | >>> | | +----------|---> | P2P |<-------------------+ | >>> | | | | | Proxy | DLNA | | >>> | | |3: Peer | +---------+ Protocol | | >>> | | | Protocol | | | >>> | | | | | | >>> | V V | V | >>> | +-----------+ | Home Domain +------------+ | >>> | | Outward | | | DLNA Pres.| | >>> | | Peer | | | Devices | | >>> | +-----------+ | +------------+ | >>> +----------------------------------------------------------------+ >>>=20 >>> Figure 6 Proxy service Supporting P2P, with DLNA interface, for Home app= lication >>>=20 >>>=20 >>>=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 12/07/2012, at 09:46, stefano previdi wrote: >>>=20 >>>> All, >>>>=20 >>>> we're (re)spin the WG last call process for the problem statement and=20= >>>> requirements draft. Note that the doc (originally separated drafts)=20 >>>> went already through one cycle of WG and IESG review so we don't expect= =20 >>>> massive/substantial updates. >>>>=20 >>>> Title : Problem Statement and Requirements of Peer-to-Peer St= reaming Protocol (PPSP) >>>> Author(s) : Yunfei Zhang >>>> Ning Zong >>>> Filename : draft-ietf-ppsp-problem-statement-09.txt >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement >>>>=20 >>>> Thanks. >>>>=20 >>>> Yunfei & Stefano. >>>> _______________________________________________ >>>> ppsp mailing list >>>> ppsp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ppsp >>>=20 >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >>=20 >>=20 >>=20 >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail-8433DB63-DC4E-4776-A141-2678D4A1829C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Richard and Yunfei,

Sub-sections on P2P proxy use case  seems a good i= dea.

Cumprimentos/Regards,
Rui Cruz
<= br>
Sent from my iPad2

On 12/07/2012, at 16:34, "Y. Richa= rd Yang" <yry@cs.yale.edu> wrot= e:

=20 =20 =20
Hi Yunfei and Rui,

The idea of showing a use case of a proxy is good and helpful. One short comment is that I am not sure if it needs two sub sections 5.4/5.5. Maybe a single P2P proxy subsec is enough? Inside the subsec, it can mention multiple instances. Just a short suggestion that you may consider.

Thanks!

Richard

On 7/12/12 6:58 PM, Rui Cruz wrote:
Hi Yunfei,

I am happy that you like the Use Case.

=46rom your other description, it reminds me of an existing solution that I have tested and works quite well: http://www.littleshoot.o= rg/
It just requires a browser, and via a plugin, launches a P2P proxy process to make P2P HTTP-based downloading.

I also like your Use Case, but  I think it deserves to be a new one (5.5 Proxy service for Browser-based HTTP streaming).

Regards,

Rui Cruz=

IST/INES= C-ID/INOV - Lisbon, Portugal
________= __________________________________
ppsp mailing list

On 12/07/2012, at 10:33, zhangyunfei wrote:

Hi Rui,
    Thanks for the contribution. I like t= his use case.
    I happen to think of one similar one= : Plug-ins supporting P2P streaming where plug-ins are often used in browser-based environment and with plug-ins http based streaming can be turned into a de facto P2P streaming( For the users and browsers, it's just http based streaming but the plug-ins are equipped wi= th PPSP can actually accelerate the process from multipl= e sources/peers. In this case the plug-ins are just like the proxy.
   Can we merge them together?
 
BR
Yunfei
 
zhangyunfei
 
From: Rui Cruz
Date: 2012-07-12 17:19
Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement
Hi,

We would like to introduce a new Use Case that may be of interest.

The description would be as follows:


5.4. Proxy service supporting P2P streaming 

For applications where the Peer is not co-located with the Media Player in the same device (e.g. the Peer is located in a Home Media Gateway), we can use a P2P Proxy, as shown in figure 6.<= /div>

As shown in this figure 6, the P2P Proxy terminates the Tracker and Peer protools, allowing the  legacy presentation devices to access P2P content. In this figure the DLNA protocol is used to communicate with the presentation devices due to its wide deployement in the industry, but of course other protocols can be used.

   +-------------------------------------------= ---------------------+
   |                         &= nbsp;                     &= nbsp;                |
   |  0:Tracker Protocol +---------+         &= nbsp;                      |
   |  +----------------> | Tracker |   &nb= sp;                       &= nbsp;    |
   |  |                  +---------+ &nbs= p;                     &nb= sp;        |
   |  |                       ^=                      = ;               |
   |  |                       |=                      = ;               |
   |  |                    2: | Trac= ker Protocol                    |
   |  |                       |=                      = ;               |
   |  |             +---------|-------------------------------------|<= /font>
   |  |             |         V &nbs= p;                     &nb= sp;             |
   |  |             |     +---------+   &= nbsp;                           |
   |  |  +----------|---> |  P2P    |<-------------------+     &nbs= p;    |
   |  |  |          |     |  Proxy &= nbsp;|       DLNA         |          |
   |  |  |3: Peer   |     +---------+   &nb= sp;   Protocol     |          |
   |  |  | Protocol |           &nbs= p;                     &nb= sp;  |          |=
   |  |  |          |         &= nbsp;                     &= nbsp;    |          |
   |  V  V          |         &= nbsp;                     &= nbsp;    V          |
   |  +-----------+ |        H= ome Domain            +------------+  |
   |  |  Outward  | |        = ;                     &nbs= p; | DLNA  Pres.|  |
   |  |  Peer     | |           &nbs= p;                   | Devices    |  |
   |  +-----------+ |         &= nbsp;                     +------------+  |
   +-------------------------------------------= ---------------------+

Figure 6 Proxy service Supporting P2P, with DLNA interface, for Home application



Regards,

Rui Cruz

IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list

On 12/07/2012, at 09:46, stefano previdi wrote:

All,

we're (re)spin the WG last call process for the problem statement and 
requirements draft. Note that the doc (originally separated drafts) 
went already through one cycle of WG and IESG review so we don't expect 
massive/substantial updates.

Title        =    : Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)
Author(s)       : Y= unfei Zhang
        =          Ning Zong
Filename       &nb= sp;: draft-ietf-ppsp-problem-statement-09.txt

https://datatracker.= ietf.org/doc/draft-ietf-ppsp-problem-statement

Thanks.

Yunfei & Stefano.
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo= /ppsp

_______________________________________________
ppsp mailing list
pp= sp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp



_______________________________________________
ppsp mailing list
ppsp@iet=
f.org
https://www.ietf.org/mailman/listinfo/ppsp

=20
____________________= ___________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman= /listinfo/ppsp
= --Apple-Mail-8433DB63-DC4E-4776-A141-2678D4A1829C-- From zongning@huawei.com Thu Jul 12 17:59:26 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 32B6511E8095 for ; Thu, 12 Jul 2012 17:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.348 X-Spam-Level: X-Spam-Status: No, score=-105.348 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 uFEv1e8V7ypa for ; Thu, 12 Jul 2012 17:59:24 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 930A311E8087 for ; Thu, 12 Jul 2012 17:59:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHS11886; Thu, 12 Jul 2012 20:59:59 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 17:57:23 -0700 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Jul 2012 17:57:28 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.92]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 13 Jul 2012 08:57:21 +0800 From: Zongning To: "Y. Richard Yang" , Rui Cruz Thread-Topic: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement Thread-Index: AQHNYAzeMWsMDpVuSEaQdL26Y7bxBJclYvPV//+RVgCAAE0rAIABIvSQ Date: Fri, 13 Jul 2012 00:57:20 +0000 Message-ID: References: , <500D2A74-221C-4174-9E97-8007B8BF34FA@ieee.org> <2012071217335750147860@chinamobile.com> <4FFEEE88.6010504@cs.yale.edu> In-Reply-To: <4FFEEE88.6010504@cs.yale.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.35] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677924AB5B56szxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement 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, 13 Jul 2012 00:59:26 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677924AB5B56szxeml504mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I also support adding a subsection for P2P proxy use cases. -Ning From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of Y. = Richard Yang Sent: Thursday, July 12, 2012 11:35 PM To: Rui Cruz Cc: ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement Hi Yunfei and Rui, The idea of showing a use case of a proxy is good and helpful. One short co= mment is that I am not sure if it needs two sub sections 5.4/5.5. Maybe a s= ingle P2P proxy subsec is enough? Inside the subsec, it can mention multipl= e instances. Just a short suggestion that you may consider. Thanks! Richard On 7/12/12 6:58 PM, Rui Cruz wrote: Hi Yunfei, I am happy that you like the Use Case. >From your other description, it reminds me of an existing solution that I h= ave tested and works quite well: http://www.littleshoot.org/ It just requires a browser, and via a plugin, launches a P2P proxy process = to make P2P HTTP-based downloading. I also like your Use Case, but I think it deserves to be a new one (5.5 Pr= oxy service for Browser-based HTTP streaming). 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 12/07/2012, at 10:33, zhangyunfei wrote: Hi Rui, Thanks for the contribution. I like this use case. I happen to think of one similar one: Plug-ins supporting P2P streaming= where plug-ins are often used in browser-based environment and with plug-i= ns http based streaming can be turned into a de facto P2P streaming( For th= e users and browsers, it's just http based streaming but the plug-ins are e= quipped with PPSP can actually accelerate the process from multiple sources= /peers. In this case the plug-ins are just like the proxy. Can we merge them together? BR Yunfei ________________________________ zhangyunfei From: Rui Cruz Date: 2012-07-12 17:19 To: stefano previdi CC: Rui Cruz; ppsp; zhangyu= nfei Zhang Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement Hi, We would like to introduce a new Use Case that may be of interest. The description would be as follows: 5.4. Proxy service supporting P2P streaming For applications where the Peer is not co-located with the Media Player in = the same device (e.g. the Peer is located in a Home Media Gateway), we can = use a P2P Proxy, as shown in figure 6. As shown in this figure 6, the P2P Proxy terminates the Tracker and Peer pr= otools, allowing the legacy presentation devices to access P2P content. In= this figure the DLNA protocol is used to communicate with the presentation= devices due to its wide deployement in the industry, but of course other p= rotocols can be used. +----------------------------------------------------------------+ | | | 0:Tracker Protocol +---------+ | | +----------------> | Tracker | | | | +---------+ | | | ^ | | | | | | | 2: | Tracker Protocol | | | | | | | +---------|-------------------------------------| | | | V | | | | +---------+ | | | +----------|---> | P2P |<-------------------+ | | | | | | Proxy | DLNA | | | | |3: Peer | +---------+ Protocol | | | | | Protocol | | | | | | | | | | V V | V | | +-----------+ | Home Domain +------------+ | | | Outward | | | DLNA Pres.| | | | Peer | | | Devices | | | +-----------+ | +------------+ | +----------------------------------------------------------------+ Figure 6 Proxy service Supporting P2P, with DLNA interface, for Home applic= ation 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 12/07/2012, at 09:46, stefano previdi wrote: All, we're (re)spin the WG last call process for the problem statement and requirements draft. Note that the doc (originally separated drafts) went already through one cycle of WG and IESG review so we don't expect massive/substantial updates. Title : Problem Statement and Requirements of Peer-to-Peer Stream= ing Protocol (PPSP) Author(s) : Yunfei Zhang Ning Zong Filename : draft-ietf-ppsp-problem-statement-09.txt https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement Thanks. Yunfei & Stefano. _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp --_000_B0D29E0424F2DE47A0B36779EC66677924AB5B56szxeml504mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I also sup= port adding a subsection for P2P proxy use cases.

 = ;

-Ning=

 = ;

From:= ppsp-bounces@ietf.o= rg [mailto:ppsp-bounces@ietf.org] On Behalf Of Y. Richard Yang
Sent: Thursday, July 12, 2012 11:35 PM
To: Rui Cruz
Cc: ppsp
Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-stateme= nt

 

Hi Yunfei and Rui,

The idea of showing a use case of a proxy is good and helpful. One short co= mment is that I am not sure if it needs two sub sections 5.4/5.5. Maybe a s= ingle P2P proxy subsec is enough? Inside the subsec, it can mention multipl= e instances. Just a short suggestion that you may consider.

Thanks!

Richard

On 7/12/12 6:58 PM, Rui Cruz wrote:

Hi Yunfei,

 

I am happy that you like the Us= e Case.

 

From your other description, it= reminds me of an existing solution that I have tested and works quite well= : http://www.littleshoot.org/<= /a>

It just requires a browser, and= via a plugin, launches a P2P proxy process to make P2P HTTP-based download= ing.

 

I also like your Use Case, but =  I think it deserves to be a new one (5.5 Proxy service for Browser-ba= sed HTTP streaming).


Regards,

 

Rui Cruz=

 

IST/INES= C-ID/INOV - Lisbon, Portugal

________= __________________________________

ppsp mai= ling list

 

On 12/07/2012, at 10:33, zhangy= unfei wrote:



Hi Rui,

    Thanks for the contribution. I like this use= case.

    I happen to think of one similar one: Plug-i= ns supporting P2P streaming where plug-ins are often used in browser-based = environment and with plug-ins http based streaming can be turned into a de facto P2P streaming( For= the users and browsers, it's just http based streaming but the plug-i= ns are equipped with PPSP can actually accelerate the process fro= m multiple sources/peers. In this case the plug-ins are just like the proxy.

   Can we merge them together?

 

BR

Yunfei

 

zhangyunfei

 

From: Rui Cruz

Date: 2012-07-12 17:19

CC: Rui Cruz<= /a>; ppsp; zhangyunfei Zhang

Subject: Re: [ppsp] WG Last Call for draft-ietf-pp= sp-problem-statement

Hi,

 

We would like to introduce a new Use Case that may be of interest.

 

The description would be as follows:

 

 

5.4. Proxy service supporting P2P streaming&n= bsp;=

 

For applications where the Peer is not co-loc= ated with the Media Player in the same device (e.g. the Peer is located in a Home Media Gateway), we can use a P2P Proxy, as shown in figure 6.

 

As shown in this figure 6, the P2P Proxy term= inates the Tracker and Peer protools, allowing the  legacy presentation devices to access P2P content. In this figure the DLNA protocol is used to= communicate with the presentation devices due to its wide deployement in t= he industry, but of course other protocols can be used.

 

   +---------------------------= -------------------------------------+

   |         &n= bsp;                     =                      = ;            |

   |  0:Tracker Protocol += ---------+                 &nbs= p;              |

   |  +---------------->= ; | Tracker |                  = ;              |

   |  |       &= nbsp;          +---------+     &= nbsp;                    =      |

   |  |       &= nbsp;               ^     &nbs= p;                     &n= bsp;         |

   |  |       &= nbsp;               |     &nbs= p;                     &n= bsp;         |

   |  |       &= nbsp;            2: | Tracker Protocol  =                  |

   |  |       &= nbsp;               |     &nbs= p;                     &n= bsp;         |

   |  |       &= nbsp;     +---------|-------------------------------------|

   |  |       &= nbsp;     |         V       &n= bsp;                     =         |

   |  |       &= nbsp;     |     +---------+      = ;                     &nb= sp;   |

   |  |  +----------|= ---> |  P2P    |<-------------------+    = ;      |

   |  |  |     =      |     |  Proxy  |     &nb= sp; DLNA         |          |<= /span>

   |  |  |3: Peer   = |     +---------+       Protocol   &n= bsp; |          |

   |  |  | Protocol | &nb= sp;                     &= nbsp;            |        = ;  |<= /o:p>

   |  |  |     =      |               &nbs= p;                    | &= nbsp;        |

   |  V  V     =      |               &nbs= p;                    V &= nbsp;        |

   |  +-----------+ | =        Home Domain           &= nbsp;+------------+  |

   |  |  Outward  | = |                     &nb= sp;         | DLNA  Pres.|  |

   |  |  Peer   &nbs= p; | |                    = ;           | Devices    |  |

   |  +-----------+ | =                      = ;         +------------+  |

   +---------------------------= -------------------------------------+

 

Figure 6 Proxy service Supporting P2P, with D= LNA interface, for Home application

 

 


Regards,

 

Rui Cruz

 

IST/INESC-ID/INOV - Lisbon, Portugal

__________________________________________

ppsp mailing list

 

On 12/07/2012, at 09:46, stefano previdi wrote:



All,

we're (re)spin the WG last call process for the problem statement and 
requirements draft. Note that the doc (originally separated drafts) 
went already through one cycle of WG and IESG review so we don't expect 
massive/substantial updates.

Title           : Problem= Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP)
Author(s)       : Yunfei Zhang
            &nb= sp;    Ning Zong
Filename        : draft-ietf-ppsp-proble= m-statement-09.txt

https://datatracker.ietf.org/doc/draft-ietf-ppsp-problem-statement<= br>
Thanks.

Yunfei & Stefano.
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org= /mailman/listinfo/ppsp

 

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

 




_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

 

--_000_B0D29E0424F2DE47A0B36779EC66677924AB5B56szxeml504mbschi_-- From zhangyunfei@chinamobile.com Thu Jul 12 18:40:37 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 16E2321F85D8 for ; Thu, 12 Jul 2012 18:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.845 X-Spam-Level: X-Spam-Status: No, score=-97.845 tagged_above=-999 required=5 tests=[AWL=0.778, 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 5UPtod2WhAv3 for ; Thu, 12 Jul 2012 18:40:35 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3263D21F85D5 for ; Thu, 12 Jul 2012 18:40:35 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 52337E3C0; Fri, 13 Jul 2012 09:41:06 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 38CC9E661; Fri, 13 Jul 2012 09:41:06 +0800 (CST) Received: from zyf-PC ([10.2.53.144]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071309410419-2308 ; Fri, 13 Jul 2012 09:41:04 +0800 Date: Fri, 13 Jul 2012 09:40:58 +0800 From: zhangyunfei To: "Rui Cruz" , yry References: <500D2A74-221C-4174-9E97-8007B8BF34FA@ieee.org> <2012071217335750147860@chinamobile.com> <4FFEEE88.6010504@cs.yale.edu>, <43DD5F3C-FCA8-4EBB-9157-980F6E9A38A2@ieee-pt.org> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201207130940587726843@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-13 09:41:04, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-13 09:41:05, Serialize complete at 2012-07-13 09:41:05 Content-Type: multipart/alternative; boundary="----=_001_NextPart824084550387_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19036.003 X-TM-AS-Result: No--46.915-7.0-31-10 X-imss-scan-details: No--46.915-7.0-31-10;No--46.915-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: 'Rui Cruz' , ppsp Subject: Re: [ppsp] WG Last Call for draft-ietf-ppsp-problem-statement 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, 13 Jul 2012 01:40:37 -0000 This is a multi-part message in MIME format. ------=_001_NextPart824084550387_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgUmljaGFyZCBhbmQgUnVpLA0KICAgIFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24uIEkgYWdy ZWUgd2l0aCB0aGlzIHN1Yi1zZWN0aW9uIGlkZWEgYW5kIHBsYW4gdG8gYWRkIGl0IGluIG5leHQg dmVyc2lvbi4gDQoNCkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogUnVp IENydXoNCkRhdGU6IDIwMTItMDctMTIgMjM6NTYNClRvOiBZLiBSaWNoYXJkIFlhbmcNCkNDOiBS dWkgQ3J1ejsgcHBzcA0KU3ViamVjdDogUmU6IFtwcHNwXSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0 LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudA0KSGkgUmljaGFyZCBhbmQgWXVuZmVpLA0KDQoN ClN1Yi1zZWN0aW9ucyBvbiBQMlAgcHJveHkgdXNlIGNhc2UgIHNlZW1zIGEgZ29vZCBpZGVhLg0K DQoNCkN1bXByaW1lbnRvcy9SZWdhcmRzLA0KUnVpIENydXoNCg0KDQpTZW50IGZyb20gbXkgaVBh ZDINCg0KT24gMTIvMDcvMjAxMiwgYXQgMTY6MzQsICJZLiBSaWNoYXJkIFlhbmciIDx5cnlAY3Mu eWFsZS5lZHU+IHdyb3RlOg0KDQoNCkhpIFl1bmZlaSBhbmQgUnVpLA0KDQpUaGUgaWRlYSBvZiBz aG93aW5nIGEgdXNlIGNhc2Ugb2YgYSBwcm94eSBpcyBnb29kIGFuZCBoZWxwZnVsLiBPbmUgc2hv cnQgY29tbWVudCBpcyB0aGF0IEkgYW0gbm90IHN1cmUgaWYgaXQgbmVlZHMgdHdvIHN1YiBzZWN0 aW9ucyA1LjQvNS41LiBNYXliZSBhIHNpbmdsZSBQMlAgcHJveHkgc3Vic2VjIGlzIGVub3VnaD8g SW5zaWRlIHRoZSBzdWJzZWMsIGl0IGNhbiBtZW50aW9uIG11bHRpcGxlIGluc3RhbmNlcy4gSnVz dCBhIHNob3J0IHN1Z2dlc3Rpb24gdGhhdCB5b3UgbWF5IGNvbnNpZGVyLg0KDQpUaGFua3MhDQoN ClJpY2hhcmQNCg0KT24gNy8xMi8xMiA2OjU4IFBNLCBSdWkgQ3J1eiB3cm90ZToNCg0KSGkgWXVu ZmVpLCANCg0KDQpJIGFtIGhhcHB5IHRoYXQgeW91IGxpa2UgdGhlIFVzZSBDYXNlLg0KDQoNCkZy b20geW91ciBvdGhlciBkZXNjcmlwdGlvbiwgaXQgcmVtaW5kcyBtZSBvZiBhbiBleGlzdGluZyBz b2x1dGlvbiB0aGF0IEkgaGF2ZSB0ZXN0ZWQgYW5kIHdvcmtzIHF1aXRlIHdlbGw6IGh0dHA6Ly93 d3cubGl0dGxlc2hvb3Qub3JnLw0KSXQganVzdCByZXF1aXJlcyBhIGJyb3dzZXIsIGFuZCB2aWEg YSBwbHVnaW4sIGxhdW5jaGVzIGEgUDJQIHByb3h5IHByb2Nlc3MgdG8gbWFrZSBQMlAgSFRUUC1i YXNlZCBkb3dubG9hZGluZy4NCg0KDQpJIGFsc28gbGlrZSB5b3VyIFVzZSBDYXNlLCBidXQgIEkg dGhpbmsgaXQgZGVzZXJ2ZXMgdG8gYmUgYSBuZXcgb25lICg1LjUgUHJveHkgc2VydmljZSBmb3Ig QnJvd3Nlci1iYXNlZCBIVFRQIHN0cmVhbWluZykuDQoNCg0KUmVnYXJkcywNCg0KDQpSdWkgQ3J1 eg0KcnVpLmNydXpAaWVlZS5vcmcNCg0KDQpJU1QvSU5FU0MtSUQvSU5PViAtIExpc2JvbiwgUG9y dHVnYWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBt YWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcHBzcA0KDQoNCk9uIDEyLzA3LzIwMTIsIGF0IDEwOjMzLCB6aGFuZ3l1bmZlaSB3 cm90ZToNCg0KDQpIaSBSdWksDQogICAgVGhhbmtzIGZvciB0aGUgY29udHJpYnV0aW9uLiBJIGxp a2UgdGhpcyB1c2UgY2FzZS4NCiAgICBJIGhhcHBlbiB0byB0aGluayBvZiBvbmUgc2ltaWxhciBv bmU6IFBsdWctaW5zIHN1cHBvcnRpbmcgUDJQIHN0cmVhbWluZyB3aGVyZSBwbHVnLWlucyBhcmUg b2Z0ZW4gdXNlZCBpbiBicm93c2VyLWJhc2VkIGVudmlyb25tZW50IGFuZCB3aXRoIHBsdWctaW5z IGh0dHAgYmFzZWQgc3RyZWFtaW5nIGNhbiBiZSB0dXJuZWQgaW50byBhIGRlIGZhY3RvIFAyUCBz dHJlYW1pbmcoIEZvciB0aGUgdXNlcnMgYW5kIGJyb3dzZXJzLCBpdCdzIGp1c3QgaHR0cCBiYXNl ZCBzdHJlYW1pbmcgYnV0IHRoZSBwbHVnLWlucyBhcmUgZXF1aXBwZWQgd2l0aCBQUFNQIGNhbiBh Y3R1YWxseSBhY2NlbGVyYXRlIHRoZSBwcm9jZXNzIGZyb20gbXVsdGlwbGUgc291cmNlcy9wZWVy cy4gSW4gdGhpcyBjYXNlIHRoZSBwbHVnLWlucyBhcmUganVzdCBsaWtlIHRoZSBwcm94eS4NCiAg IENhbiB3ZSBtZXJnZSB0aGVtIHRvZ2V0aGVyPw0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5n eXVuZmVpDQoNCkZyb206IFJ1aSBDcnV6DQpEYXRlOiAyMDEyLTA3LTEyIDE3OjE5DQpUbzogc3Rl ZmFubyBwcmV2aWRpDQpDQzogUnVpIENydXo7IHBwc3A7IHpoYW5neXVuZmVpIFpoYW5nDQpTdWJq ZWN0OiBSZTogW3Bwc3BdIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0t c3RhdGVtZW50DQpIaSwgDQoNCg0KV2Ugd291bGQgbGlrZSB0byBpbnRyb2R1Y2UgYSBuZXcgVXNl IENhc2UgdGhhdCBtYXkgYmUgb2YgaW50ZXJlc3QuDQoNCg0KVGhlIGRlc2NyaXB0aW9uIHdvdWxk IGJlIGFzIGZvbGxvd3M6DQoNCg0KDQoNCjUuNC4gUHJveHkgc2VydmljZSBzdXBwb3J0aW5nIFAy UCBzdHJlYW1pbmcgDQoNCg0KRm9yIGFwcGxpY2F0aW9ucyB3aGVyZSB0aGUgUGVlciBpcyBub3Qg Y28tbG9jYXRlZCB3aXRoIHRoZSBNZWRpYSBQbGF5ZXIgaW4gdGhlIHNhbWUgZGV2aWNlIChlLmcu IHRoZSBQZWVyIGlzIGxvY2F0ZWQgaW4gYSBIb21lIE1lZGlhIEdhdGV3YXkpLCB3ZSBjYW4gdXNl IGEgUDJQIFByb3h5LCBhcyBzaG93biBpbiBmaWd1cmUgNi4NCg0KDQpBcyBzaG93biBpbiB0aGlz IGZpZ3VyZSA2LCB0aGUgUDJQIFByb3h5IHRlcm1pbmF0ZXMgdGhlIFRyYWNrZXIgYW5kIFBlZXIg cHJvdG9vbHMsIGFsbG93aW5nIHRoZSAgbGVnYWN5IHByZXNlbnRhdGlvbiBkZXZpY2VzIHRvIGFj Y2VzcyBQMlAgY29udGVudC4gSW4gdGhpcyBmaWd1cmUgdGhlIERMTkEgcHJvdG9jb2wgaXMgdXNl ZCB0byBjb21tdW5pY2F0ZSB3aXRoIHRoZSBwcmVzZW50YXRpb24gZGV2aWNlcyBkdWUgdG8gaXRz IHdpZGUgZGVwbG95ZW1lbnQgaW4gdGhlIGluZHVzdHJ5LCBidXQgb2YgY291cnNlIG90aGVyIHBy b3RvY29scyBjYW4gYmUgdXNlZC4NCg0KDQogICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg fCAgMDpUcmFja2VyIFByb3RvY29sICstLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICB8ICArLS0tLS0tLS0tLS0tLS0tLT4gfCBUcmFja2VyIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgIHwgIHwgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgfCAgICAgICAgICAg ICAgICAgICAgICAgXiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8 ICB8ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgIHwgIHwgICAgICAgICAgICAgICAgICAgIDI6IHwgVHJhY2tlciBQcm90b2Nv bCAgICAgICAgICAgICAgICAgICAgfA0KICAgfCAgfCAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICAgICAgICAgICAg ICstLS0tLS0tLS18LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwNCiAgIHwg IHwgICAgICAgICAgICAgfCAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgfCAgfCAgICAgICAgICAgICB8ICAgICArLS0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQogICB8ICB8ICArLS0tLS0tLS0tLXwtLS0+IHwgIFAyUCAg ICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgIHwNCiAgIHwgIHwgIHwgICAgICAgICAg fCAgICAgfCAgUHJveHkgIHwgICAgICAgRExOQSAgICAgICAgIHwgICAgICAgICAgfA0KICAgfCAg fCAgfDM6IFBlZXIgICB8ICAgICArLS0tLS0tLS0tKyAgICAgICBQcm90b2NvbCAgICAgfCAgICAg ICAgICB8DQogICB8ICB8ICB8IFByb3RvY29sIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgIHwNCiAgIHwgIHwgIHwgICAgICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgfA0KICAgfCAgViAgViAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgViAgICAgICAgICB8DQogICB8ICAr LS0tLS0tLS0tLS0rIHwgICAgICAgIEhvbWUgRG9tYWluICAgICAgICAgICAgKy0tLS0tLS0tLS0t LSsgIHwNCiAgIHwgIHwgIE91dHdhcmQgIHwgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IERMTkEgIFByZXMufCAgfA0KICAgfCAgfCAgUGVlciAgICAgfCB8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgRGV2aWNlcyAgICB8ICB8DQogICB8ICArLS0tLS0tLS0tLS0rIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSsgIHwNCiAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KDQoNCkZpZ3VyZSA2IFByb3h5IHNlcnZpY2UgU3VwcG9ydGluZyBQMlAsIHdpdGggRExO QSBpbnRlcmZhY2UsIGZvciBIb21lIGFwcGxpY2F0aW9uDQoNCg0KDQoNCg0KUmVnYXJkcywNCg0K DQpSdWkgQ3J1eg0KcnVpLmNydXpAaWVlZS5vcmcNCg0KDQpJU1QvSU5FU0MtSUQvSU5PViAtIExp c2JvbiwgUG9ydHVnYWwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcHBzcA0KDQoNCk9uIDEyLzA3LzIwMTIsIGF0IDA5OjQ2LCBzdGVm YW5vIHByZXZpZGkgd3JvdGU6DQoNCg0KQWxsLA0KDQp3ZSdyZSAocmUpc3BpbiB0aGUgV0cgbGFz dCBjYWxsIHByb2Nlc3MgZm9yIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgDQpyZXF1aXJlbWVu dHMgZHJhZnQuIE5vdGUgdGhhdCB0aGUgZG9jIChvcmlnaW5hbGx5IHNlcGFyYXRlZCBkcmFmdHMp IA0Kd2VudCBhbHJlYWR5IHRocm91Z2ggb25lIGN5Y2xlIG9mIFdHIGFuZCBJRVNHIHJldmlldyBz byB3ZSBkb24ndCBleHBlY3QgDQptYXNzaXZlL3N1YnN0YW50aWFsIHVwZGF0ZXMuDQoNClRpdGxl ICAgICAgICAgICA6IFByb2JsZW0gU3RhdGVtZW50IGFuZCBSZXF1aXJlbWVudHMgb2YgUGVlci10 by1QZWVyIFN0cmVhbWluZyBQcm90b2NvbCAoUFBTUCkNCkF1dGhvcihzKSAgICAgICA6IFl1bmZl aSBaaGFuZw0KICAgICAgICAgICAgICAgICBOaW5nIFpvbmcNCkZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudC0wOS50eHQNCg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50DQoNClRo YW5rcy4NCg0KWXVuZmVpICYgU3RlZmFuby4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNwDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QN CnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBz cA0KDQoNCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart824084550387_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Richard and Rui,
    Thanks for the suggestion. I agree with this sub-s= ection=20 idea and plan to add it in next version.
 
BR
Yunfei
 
zhangyunfei
 
From: Rui Cruz
Date: 2012-07-12 23:56
Subject: Re: [ppsp] WG Last Call for=20 draft-ietf-ppsp-problem-statement
Hi Richard and Yunfei,

Sub-sections on P2P proxy use case  seems a good idea.

Cumprimentos/Regards,
Rui Cruz

Sent from my iPad2

On 12/07/2012, at 16:34, "Y. Richard Yang" <yry@cs.yale.edu> wrote:

Hi Yunfei and Rui,

The idea of showi= ng a use=20 case of a proxy is good and helpful. One short comment is that I am not = sure=20 if it needs two sub sections 5.4/5.5. Maybe a single P2P proxy subsec is= =20 enough? Inside the subsec, it can mention multiple instances. Just a sho= rt=20 suggestion that you may consider.

Thanks!

Richard

O= n=20 7/12/12 6:58 PM, Rui Cruz wrote:
Hi Yunfei,=20

I am happy that you like the Use Case.

From your other description, it reminds me of an existing solutio= n that=20 I have tested and works quite well: http://www.littleshoot.org/
It just requires a browser, and via a plugin, launches a P2P prox= y=20 process to make P2P HTTP-based downloading.

I also like your Use Case, but  I think it deserves to be a = new=20 one (5.5 Proxy service for Browser-based HTTP streaming).
Regards,

Rui Cruz
rui.cruz@ieee.org

IST/INESC-ID/INOV = - Lisbon,=20 Portugal
__________________________________________
ppsp mailing=20 list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

On 12/07/2012, at 10:33, zhangyunfei wrote:
Hi Rui,
    Thanks for the contribution. I like this use= =20 case.
    I happen to think of one similar one: Plug-i= ns=20 supporting P2P streaming where plug-ins are often used in browser-ba= sed=20 environment and with plug-ins http based streaming can be turned int= o a de facto P2P streaming( For the users and browsers, it's just h= ttp=20 based streaming but the plug-ins are equipped with PPSP ca= n=20 actually accelerate the process from multiple sources/peers. In= this=20 case the plug-ins are just like the proxy.
   Can we merge them together?
 
BR
Yunfei
 
zhangyunfei
 
From: Rui Cruz
Date: 2012-07-12 17:19
CC: Rui Cruz; ppsp; zhangyunfei Zhang
Subject: Re: [ppsp] WG Last Call for=20 draft-ietf-ppsp-problem-statement
Hi,=20

We would like to introduce a new Use Case that may be of=20 interest.

The description would be as follows:


5= .4. Proxy=20 service supporting P2P streaming 

F= or=20 applications where the Peer is not co-located with the Media Player = in the=20 same device (e.g. the Peer is located in a Home Media G= ateway),=20 we can use a P2P Proxy, as shown in figure 6.

A= s shown in=20 this figure 6, the P2P Proxy terminates the Tracker and Peer protool= s,=20 allowing the  legacy= =20 presentation devices to access P2P content. In this figure the DLNA=20 protocol is used to communicate with the presentation devices due to= its=20 wide deployement in the industry, but of course other protocols can = be=20 used.

&= nbsp;=20  +-------------------------------------------------------------= ---+
&= nbsp;=20  |                 &nbs= p;=20                    = ;=20                    = ;=20      |
&= nbsp;=20  |  0:Tracker Protocol +---------+       &n= bsp;=20                    = ;=20    |
&= nbsp;=20  |  +----------------> | Tracker |      = =20                    = ;=20      |
&= nbsp;=20  |  |               &nb= sp;=20  +---------+               &= nbsp;=20                |
&= nbsp;=20  |  |               &nb= sp;=20       ^             &nb= sp;=20                    = ;=20   |
&= nbsp;=20  |  |               &nb= sp;=20       |             &nb= sp;=20                    = ;=20   |
&= nbsp;=20  |  |               &nb= sp;=20    2: | Tracker Protocol          = ;=20          |
&= nbsp;=20  |  |               &nb= sp;=20       |             &nb= sp;=20                    = ;=20   |
&= nbsp;=20  |  |            =20 +---------|-------------------------------------|
&= nbsp;=20  |  |             |   &= nbsp;=20     V               &nb= sp;=20                    = ;=20 |
&= nbsp;=20  |  |             |   &= nbsp;=20 +---------+                 =  =20             |
&= nbsp;=20  |  |  +----------|---> |  P2P  =20  |<-------------------+        =20  |
&= nbsp;=20  |  |  |          |   &= nbsp;=20 |  Proxy  |       DLNA      = =20   |          |
&= nbsp;=20  |  |  |3: Peer   |     +---------+ &n= bsp;=20     Protocol     |        =20  |
&= nbsp;=20  |  |  | Protocol |          = ;=20                    = ;=20      |          |
&= nbsp;=20  |  |  |          |   &= nbsp;=20                    = ;=20            |       &nbs= p;=20  |
&= nbsp;=20  |  V  V          |   &= nbsp;=20                    = ;=20            V       &nbs= p;=20  |
&= nbsp;=20  |  +-----------+ |        Home Domain= =20            +------------+=20  |
&= nbsp;=20  |  |  Outward  | |         =  =20                    = ; |=20 DLNA  Pres.|  |
&= nbsp;=20  |  |  Peer     | |       &n= bsp;=20                    = ;=20   | Devices    |  |
&= nbsp;=20  |  +-----------+ |           &nb= sp;=20                  =20 +------------+  |
&= nbsp;=20  +-------------------------------------------------------------= ---+

F= igure 6=20 Proxy service Supporting P2P, with DLNA interface, for Home=20 application


Regards,
Rui Cruz<= /DIV>
rui.cruz@ieee.org
IST/INESC-ID/INO= V -=20 Lisbon, Portugal
__________________________________________
ppsp mailing=20 list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp<= /A>

On 12/07/2012, at 09:46, stefano previdi wrote:
All,

we're (re)spin the WG last call process for the p= roblem=20 statement and 
requirements draft.= Note=20 that the doc (originally separated drafts) 
went already throug= h one=20 cycle of WG and IESG review so we don't expect 
massive/substantial= =20 updates.

Title=20           : Prob= lem=20 Statement and Requirements of Peer-to-Peer Streaming Protocol=20 (PPSP)
Author(s)       : Yunfei=20 Zhang
         &nb= sp;       Ning=20 Zong
Filename        :=20 draft-ietf-ppsp-problem-statement-09.txt

https://datatracker.ietf.org/doc/draft-ie= tf-ppsp-problem-statement

Thanks.

Yunfei=20 &=20 Stefano.
_______________________________________________
pps= p=20 mailing list
ppsp@ietf.org
https://www.ie= tf.org/mailman/listinfo/ppsp

_______________________________________________
ppsp=20 mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp<= /A>



=
_______________________________________________
ppsp mailing list
ppsp@iet=
f.org
https://www.ietf.org/mailman/listinfo/ppsp

_______________________________________________
ppsp=20 mailing list
ppsp@ietf.org
https://www.ietf.org= /mailman/listinfo/ppsp
------=_001_NextPart824084550387_=------ From a.bakker@vu.nl Fri Jul 13 00:12:01 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 7E4F421F8795; Fri, 13 Jul 2012 00:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.535 X-Spam-Level: X-Spam-Status: No, score=-1.535 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 2UasvDiPPu2y; Fri, 13 Jul 2012 00:12:00 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 870D021F8790; Fri, 13 Jul 2012 00:12:00 -0700 (PDT) Received: from PEXHB012A.vu.local (130.37.236.66) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 13 Jul 2012 09:12:32 +0200 Received: from [192.168.0.104] (130.37.238.20) by mails.vu.nl (130.37.236.66) with Microsoft SMTP Server (TLS) id 14.2.298.4; Fri, 13 Jul 2012 09:12:34 +0200 Message-ID: <4FFFCA6D.7060306@cs.vu.nl> Date: Fri, 13 Jul 2012 09:12:45 +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: Peng Zhang References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> <4FFE6D67.80705@cs.vu.nl> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp , decade Subject: Re: [ppsp] [decade] Object naming in -req and -arch 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: Fri, 13 Jul 2012 07:12:01 -0000 On 12/07/2012 22:28, Peng Zhang wrote: > > On Jul 12, 2012, at 2:23 AM, Arno Bakker wrote: > >> The gains of using MHT depend on the chunk size. For PPSP we prefer >> chunks of 1K that fit in an UDP packet carried over Ethernet. In >> that case, for a 4 GB file, there are 4 M chunks, resulting in 80 >> MB of leaf hashes when SHA1 is used. Transferring that beforehand >> as in BitTorrent definitely increases latency ;o) > Yes, if the chunk size is only 1KB, and each chunk is verified > individually, we cannot afford to send all hashes beforehand. While > in the worst case without optimization, almost 2*80M = 160M hashes > needs to be sent to the receiver, will that be a large overhead > compared to 4G? Do we really need such a small chunk size? Maybe I > miss some previous discussion on this. Hi For PPSP we want to use UDP as we don't need the in-order and reliability features of TCP, and want flexibility to use differnet congestion control algorithms and handle NATs. With Ethernet as the dominant MAC layer at present and an unreliable transport we don't want datagrams to exceed the Ethernet MTU, otherwise the chance of losing a datagram increases (an UDP packet taking N IP packets will not be delivered when only 1 IP packet is lost). Hence, we use chunks of ~1K. A good practice in P2P networks is to not forward data you have not verified. So to forward the 1K chunks directly we need to be able to verify their integrity at this granularity, enter Merkle Hash Trees. We think the resulting overhead due to the size of the tree is acceptable, as it is easy to optimize the number of hashes transmitted in our use cases. CU, Arno From pzhang.thu@gmail.com Thu Jul 12 13:28:20 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 2CBBE11E8096; Thu, 12 Jul 2012 13:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.304 X-Spam-Level: X-Spam-Status: No, score=-3.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edR6Ao8qCdjY; Thu, 12 Jul 2012 13:28:19 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9F11E8080; Thu, 12 Jul 2012 13:28:19 -0700 (PDT) Received: by qaea16 with SMTP id a16so1929456qae.10 for ; Thu, 12 Jul 2012 13:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=wT7m4tPFgv3SqXzFZ+I+dR7he8wP5J2g2KzPRXVw0KE=; b=eY4fKZurtz/hSkeKU40jPZB68EgyqoIkSDfJjbdEorJkjEIE0gSD+xLnK5fFe66YS9 PmALRsD7qKHNUYkf0MCbmaILKUsQp+AtCRsyeO3v5cvNg1f5W+phuFvVA6ssYZFZjRlA qrM6LYuRh2SsvQ/h7Qsf2XvUEkyW/0q0bTHVBfDadSi1exCaiEYEctBWF3A5HcCClfGL jgPmE/GGhHbQTvRgnxs2k2qA/EtXdMYviwC5YTHKbC6Oh3wY7+O3ktaa/tMvd4RJ6Byw K3bTgxHilX13u1gs4tn5x4k67rLL9DnuH5CFBcedDLNgaa+G4Yl2kQ1kapF+TYUe1/gL 9cjw== Received: by 10.229.135.75 with SMTP id m11mr28743911qct.74.1342124932891; Thu, 12 Jul 2012 13:28:52 -0700 (PDT) Received: from [128.36.160.220] ([128.36.160.220]) by mx.google.com with ESMTPS id w14sm3730489qaz.17.2012.07.12.13.28.51 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Jul 2012 13:28:52 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Peng Zhang In-Reply-To: <4FFE6D67.80705@cs.vu.nl> Date: Thu, 12 Jul 2012 16:28:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> <4FFE6D67.80705@cs.vu.nl> To: X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Sun, 15 Jul 2012 19:10:02 -0700 Cc: ppsp , decade Subject: Re: [ppsp] [decade] Object naming in -req and -arch X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 20:28:20 -0000 On Jul 12, 2012, at 2:23 AM, Arno Bakker wrote: > Hi Peng >=20 > On 11/07/2012 23:25, Peng Zhang wrote: >> Hi Arno, >>=20 >> Thanks for the clarification. In my understanding, MHT over single = hash >> can enable immediate integrity check before the whole media file is >> received, which is critical for streaming applications. But the = client >> can also download hashes of every piece, just like in BitTorrent. = Does >> it reduce a lot startup latency or server load by using MHT? Thanks. >>=20 >=20 > The gains of using MHT depend on the chunk size. For PPSP we prefer = chunks of 1K that fit in an UDP packet carried over Ethernet. In that = case, for a 4 GB file, there are 4 M chunks, resulting in 80 MB of leaf = hashes when SHA1 is used. Transferring that beforehand as in BitTorrent = definitely increases latency ;o) Yes, if the chunk size is only 1KB, and each chunk is verified = individually, we cannot afford to send all hashes beforehand. While in = the worst case without optimization, almost 2*80M =3D 160M hashes needs = to be sent to the receiver, will that be a large overhead compared to = 4G? Do we really need such a small chunk size? Maybe I miss some = previous discussion on this. >=20 >=20 >> For DECADE, It supports integrity check on piece/chunk level, so that >> client can verify that the received piece corresponds to the piece = name. >> DECADE is unaware of what file this piece belongs to, and thus does = not >> provide end-to-end integrity check. For file level, we leave the >> integrity check to applications. Thus, imo, we should not include MHT = in >> the design of DECADE. But MHT can be built on top of DECADE, which = means >> applications can still use MHT to implement integrity check for = themselves. >>=20 >=20 > You are right, if DECADE doesn't provide "links" between chunks, MHTs = at the DECADE level make no sense. Using MHTs at the app level instead = as you say does make sense and is easy, just build all the piece = names/piece hashes into a tree. Yes, Exactly. >=20 > Regards, > Arno From zhangyunfei@chinamobile.com Sun Jul 15 23:10: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 EA78221F85A3 for ; Sun, 15 Jul 2012 23:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.556 X-Spam-Level: X-Spam-Status: No, score=-96.556 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, J_CHICKENPOX_84=0.6, 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 MeW-3WMv3WkT for ; Sun, 15 Jul 2012 23:10:40 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17821F856F for ; Sun, 15 Jul 2012 23:10:37 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id C4C97E732; Mon, 16 Jul 2012 14:11:21 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id A271CE72E; Mon, 16 Jul 2012 14:11:21 +0800 (CST) Received: from zyf-PC ([10.2.52.214]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071614111912-12449 ; Mon, 16 Jul 2012 14:11:19 +0800 Date: Mon, 16 Jul 2012 14:11:15 +0800 From: zhangyunfei To: "Wesley Eddy" , "arno@cs.vu.nl" References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl>, <4FFDACBF.3080908@mti-systems.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012071614111568687511@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-16 14:11:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-16 14:11:20, Serialize complete at 2012-07-16 14:11:20 Content-Type: multipart/alternative; boundary="----=_001_NextPart052745570380_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19042.004 X-TM-AS-Result: No--19.299-7.0-31-10 X-imss-scan-details: No--19.299-7.0-31-10;No--19.299-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] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 06:10:41 -0000 This is a multi-part message in MIME format. ------=_001_NextPart052745570380_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" U2FtZSBpbXByZXNzaW9uIGFzIFdlcy4gVG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCBMRURC QVQgaXMgZGVzaWduZWQgdG8gYmUgZm9yICJsb3dlciBwcmlvcml0eSIgYXBwcywgd2hvIGlzIG1h aW5seSBydW5uaW5nIG9uIHRvcCBvZiBUQ1AgKGF0IGxlYXN0IFVEUCBhbmQgVENQIGFyZSBjby1m dW5jdGlvbmluZyBhbmQgY2FuIHN3aXRjaCBlYWNoIG90aGVyKS4gSXQgc2VlbXMgcHBzcCBhcHBz IGFyZSBuZWl0aGVyImxvd2VyIHByaW9yaXR5ImFwcHMgd2hlbiBjb21wZXRpbmcgd2l0aCBvdGhl ciB0cmFmZmljcyBub3IgcmVxdWlyaW5nIGJvdGggVURQIGFuZCBUQ1AgcnVubmluZyBhbmQgc3dp dGNoaW5nLg0KU28gYSBVRFArY2MobmVlZG4ndCBjb25zaWRlcmluZyB0aGUgVENQIGVmZmVjdCkg c29sdXRpb25zIHNlZW1zIGFwcHJvcHJpYXRlLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQp6aGFuZ3l1 bmZlaQ0KDQpGcm9tOiBXZXNsZXkgRWRkeQ0KRGF0ZTogMjAxMi0wNy0xMiAwMDo0MQ0KVG86IGFy bm8NCkNDOiBwcHNwDQpTdWJqZWN0OiBSZTogW3Bwc3BdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt cHBzcC1wZWVyLXByb3RvY29sLTAyLnR4dA0KT24gNy8xMS8yMDEyIDM6MjEgQU0sIEFybm8gQmFr a2VyIHdyb3RlOg0KPiBHb29kIHRoYXQgeW91IG1lbnRpb24gdHJhbnNwb3J0cywgQUZBSUsgdGhh dCBzdGlsbCBuZWVkcyB0byBiZQ0KPiBkaXNjdXNzZWQuIENhbmRpZGF0ZXMgYXJlOg0KPiANCj4g KiBVRFAgd2l0aCBjb25nZXN0aW9uIGNvbnRyb2wgKGUuZy4gTEVEQkFUKQ0KDQoNCkknbSB3b25k ZXJpbmcgaWYgTEVEQkFUIGlzIHRoZSByaWdodCBjaG9pY2UsIGdpdmVuIHRoYXQgaXRzDQpkZXNp Z24gaXMgdG8gbGV0IGl0c2VsZiBnZXQgZHJvd25lZCBvdXQuICBMRURCQVQgbWFkZSBzZW5zZQ0K Zm9yIEJpdFRvcnJlbnQgc3RyZWFtcyBydW5uaW5nIGluIHRoZSBiYWNrZ3JvdW5kLCBidXQgSSBk b24ndA0KdGhpbmsgaXQgbWFrZXMgYXMgbXVjaCBzZW5zZSBmb3IgbGl2ZS1zdHJlYW1pbmcuDQoN Ckl0IHNlZW1zIHRoYXQgVEZSQyBtaWdodCBiZSBtb3JlIGFwcHJvcHJpYXRlIHRvIG1lLg0KDQot LSANCldlcyBFZGR5DQpNVEkgU3lzdGVtcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart052745570380_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Same impression as Wes. To the best of my knowledge, LEDBAT is design= ed to=20 be for "lower priority" apps, who is mainly running on top of TCP (at= least=20 UDP and TCP are co-functioning and can switch each other). It seems ppsp a= pps=20 are neither"lower priority"apps when competing with other traffics nor req= uiring=20 both UDP and TCP running and switching.
So a UDP+cc(needn't considering the TCP effect) solutions seems=20 appropriate.
 
BR
Yunfei
zhangyunfei
 
Date: 2012-07-12 00:41
To: arno
CC: ppsp
Subject: Re: [ppsp] I-D Action:=20 draft-ietf-ppsp-peer-protocol-02.txt
On 7/11/2012 3:21 AM, Arno Bakker wrote= :
> Good that you mention transports, = AFAIK that still needs to be
> discussed. Candidates are:
> 
> * UDP with congestion control (e.g= . LEDBAT)
 
 
I'm wondering if LEDBAT is the right&nb= sp;choice, given that its
design is to let itself get drowned&nbs= p;out.  LEDBAT made sense
for BitTorrent streams running in the b= ackground, but I don't
think it makes as much sense for l= ive-streaming.
 
It seems that TFRC might be more a= ppropriate to me.
 
-- 
Wes Eddy
MTI Systems
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart052745570380_=------ From a.bakker@vu.nl Mon Jul 16 00:22:33 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 862A321F8549 for ; Mon, 16 Jul 2012 00:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_75=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x80fw2jP+kQS for ; Mon, 16 Jul 2012 00:22:32 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5441821F8551 for ; Mon, 16 Jul 2012 00:22:32 -0700 (PDT) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 16 Jul 2012 09:23:13 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.2.298.4; Mon, 16 Jul 2012 09:23:14 +0200 Message-ID: <5003C171.1050606@cs.vu.nl> Date: Mon, 16 Jul 2012 09:23:29 +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: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl>, <4FFDACBF.3080908@mti-systems.com> <2012071614111568687511@chinamobile.com> In-Reply-To: <2012071614111568687511@chinamobile.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt 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, 16 Jul 2012 07:22:33 -0000 On 16/07/2012 08:11, zhangyunfei wrote: > Same impression as Wes. To the best of my knowledge, LEDBAT is designed > to be for "lower priority" apps, who is mainly running on top of TCP (at > least UDP and TCP are co-functioning and can switch each other). It > seems ppsp apps are neither"lower priority"apps when competing with > other traffics nor requiring both UDP and TCP running and switching. > So a UDP+cc(needn't considering the TCP effect) solutions seems appropriate. > Hi I think LEDBAT is useful for seeding (VOD) peers. Once they have downloaded the content they should ideally contribute back to the P2P network, but without causing disturbance for their user. It can also be useful in networks which currently have overcapacity. In that case, downloading at higher than the bitrate is effective use of resources (a megabit/s not used is a megabit/s lost), but the faster-than-required download should not infere with other activities of the user. I.e. LEDBAT should limit it when required, whilst not dropping the speed below approx. bitrate. Riccardo knows more about this, so perhap he can comment. CU, Arno From r.petrocco@gmail.com Mon Jul 16 06:47: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 4070921F8858 for ; Mon, 16 Jul 2012 06:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWaJYNFebciB for ; Mon, 16 Jul 2012 06:47:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 807C521F8855 for ; Mon, 16 Jul 2012 06:47:53 -0700 (PDT) Received: by yhq56 with SMTP id 56so5662657yhq.31 for ; Mon, 16 Jul 2012 06:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EEzOBhRrm39wf/rOy+ZmUGPKFSXq3AKka2mIC+Zdn6o=; b=ZIV8Jzmw2ZnL4X91UsJvEMkZhPAdkHYpD4/Wz4Eckz5BwsGDQB5hsp8mSYHUP3A4ON DkqNuBStbv9DlJDT8fXVry+CEPNJMVmqK9P9QbDSRlTwrUzD6LeevUL0haMVymdwvp6+ Sb6pCXcLDqSIF+ZvqJ0HCqY/Ez6MMd6cjyIHkxeoNb1Qa8WtfSzXxFwy3UJDaGNwvjpf jCaQzUW6DTiVgLPUsBZvxp62wpRLVvDQLa1qzG2Rgp9KwCBfSdYVKSRg3fdVwRFh49TY O6mBG9feZD0jGWYpWXrIXwvGwHKSj7Ll+NKp2I2uKLyVHczhuddHfif7Yzzong97PfZD iZkA== MIME-Version: 1.0 Received: by 10.50.46.231 with SMTP id y7mr5183884igm.21.1342446512853; Mon, 16 Jul 2012 06:48:32 -0700 (PDT) Received: by 10.64.20.168 with HTTP; Mon, 16 Jul 2012 06:48:32 -0700 (PDT) In-Reply-To: <5003C171.1050606@cs.vu.nl> References: <20120620060416.20536.93957.idtracker@ietfa.amsl.com> <2012062015092544515442@chinamobile.com> <4FFD2967.7080402@cs.vu.nl> <4FFDACBF.3080908@mti-systems.com> <2012071614111568687511@chinamobile.com> <5003C171.1050606@cs.vu.nl> Date: Mon, 16 Jul 2012 15:48:32 +0200 Message-ID: From: Riccardo Petrocco To: arno@cs.vu.nl Content-Type: multipart/alternative; boundary=14dae9340be787513004c4f2af57 Cc: ppsp Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 13:47:54 -0000 --14dae9340be787513004c4f2af57 Content-Type: text/plain; charset=ISO-8859-1 Hi, As Arno explained in the previous mail, LEDBAT was chosen to increase the on-line time of seeders. The main problem with any P2P systems is the supply of bandwidth. With an oversupplied swarm, there is usually no problem in delivering the stream on time. If the users don't see any drop in performance by keeping on seeding content they already watched, they might stay longer in the swarm. Wesley is definitely right, as for live-streaming LEDBAT is not the best candidate. I wonder if we can keep LEDBAT, as it's the ideal cc for file sharing and VoD content, and adjust it's queuing target delay value, to act as TCP, in case of a live-streaming swarm. BR, Riccardo 2012/7/16 Arno Bakker > On 16/07/2012 08:11, zhangyunfei wrote: > > Same impression as Wes. To the best of my knowledge, LEDBAT is designed > > to be for "lower priority" apps, who is mainly running on top of TCP (at > > least UDP and TCP are co-functioning and can switch each other). It > > seems ppsp apps are neither"lower priority"apps when competing with > > other traffics nor requiring both UDP and TCP running and switching. > > So a UDP+cc(needn't considering the TCP effect) solutions seems > appropriate. > > > > Hi > > I think LEDBAT is useful for seeding (VOD) peers. Once they have > downloaded the content they should ideally contribute back to the P2P > network, but without causing disturbance for their user. > > It can also be useful in networks which currently have overcapacity. In > that case, downloading at higher than the bitrate is effective use of > resources (a megabit/s not used is a megabit/s lost), but the > faster-than-required download should not infere with other activities of > the user. I.e. LEDBAT should limit it when required, whilst not dropping > the speed below approx. bitrate. > > Riccardo knows more about this, so perhap he can comment. > > CU, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > --14dae9340be787513004c4f2af57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

As Arno explained in the previous mail, LEDBAT was chosen to inc= rease the on-line
time of seeders.
The main problem with any P2P syst= ems is the supply of bandwidth. With an oversupplied
swarm, there is usu= ally no problem in delivering the stream on time. If the users don't se= e
any drop in performance by keeping on seeding content they already watched,= they might
stay longer in the swarm.

Wesley is definitely right= , as for live-streaming LEDBAT is not the best candidate.
I wonder if we= can keep LEDBAT, as it's the ideal cc for file sharing and VoD content= , and
adjust it's queuing target delay value, to act as TCP, in case of a liv= e-streaming swarm.


BR,
Riccardo

2012/7/16 Arno Bakker <arno@cs.vu.nl>
On 16/07/2012 08:11, zhangyunfei wrote:=
> Same impression as Wes. To the best of my knowledge, LEDBAT is designe= d
> to be for "lower priority" apps, who is mainly running on to= p of TCP (at
> least UDP and TCP are co-functioning and can switch each other). It > seems ppsp apps are neither"lower priority"apps when competi= ng with
> other traffics nor requiring both UDP and TCP running and switching. > So a UDP+cc(needn't considering the TCP effect) solutions seems ap= propriate.
>

Hi

I think LEDBAT is useful for seeding (VOD) peers. Once they have
downloaded the content they should ideally contribute back to the P2P
network, but without causing disturbance for their user.

It can also be useful in networks which currently have overcapacity. In
that case, downloading at higher than the bitrate is effective use of
resources (a megabit/s not used is a megabit/s lost), but the
faster-than-required download should not infere with other activities of the user. I.e. LEDBAT should limit it when required, whilst not dropping the speed below approx. bitrate.

Riccardo knows more about this, so perhap he can comment.

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

--14dae9340be787513004c4f2af57-- From zhangyunfei@chinamobile.com Tue Jul 17 03:01:15 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B7321F8669 for ; Tue, 17 Jul 2012 03:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.559 X-Spam-Level: X-Spam-Status: No, score=-96.559 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UglDbspRCxw for ; Tue, 17 Jul 2012 03:01:14 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 84F9F21F859A for ; Tue, 17 Jul 2012 03:01:14 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id A1363E49C; Tue, 17 Jul 2012 18:02:01 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 8607EE4E9; Tue, 17 Jul 2012 18:02:01 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012071718020023-53748 ; Tue, 17 Jul 2012 18:02:00 +0800 Date: Tue, 17 Jul 2012 18:01:56 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012071718015686061438@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-17 18:02:00, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-17 18:02:01, Serialize complete at 2012-07-17 18:02:01 Content-Type: multipart/alternative; boundary="----=_001_NextPart723061284282_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19046.000 X-TM-AS-Result: No--15.451-7.0-31-10 X-imss-scan-details: No--15.451-7.0-31-10;No--15.451-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] ppsp draft agenda for IETF84 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, 17 Jul 2012 10:01:15 -0000 This is a multi-part message in MIME format. ------=_001_NextPart723061284282_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgYWxsLA0KICAgICBBY2NvcmRpbmcgdG8gdGhlIHJlY2VpdmVkIHJlcXVlc3RzLCB0aGUgcHBz cCBkcmFmdCBhZ2VuZGEgZm9yIElFVEYgODQgaXMgYXMgZm9sbG93czoNCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvODQvYWdlbmRhL2FnZW5kYS04NC1wcHNwIA0KICAgICAgUGxlYXNl IGxldCBTdGVmYW5vIGFuZCBtZSBrbm93IGlmIHlvdSBoYXZlIGFueSBmdXJ0aGVyIGNvbW1lbnRz IGFuZCBzdWdnZXN0aW9ucy5UaGFua3MuDQoNCkJSDQpTdGVmYW5vJll1bmZlaSANCg0KIA0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ== ------=_001_NextPart723061284282_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi all,
     According to the received requests, the=20 ppsp draft agenda for IETF 84 is as follows:
http://w= ww.ietf.org/proceedings/84/agenda/agenda-84-ppsp=20
      Please let Stefano and me know if you = have=20 any further comments and suggestions.Thanks.
 
BR
Stefano&Yunfei
 
 
 
zhangyunfei
------=_001_NextPart723061284282_=------ From haibin.song@huawei.com Wed Jul 18 19:37:56 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 D8DFE21F8680; Wed, 18 Jul 2012 19:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 INLHuw4t4Spa; Wed, 18 Jul 2012 19:37:56 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8A21F84EA; Wed, 18 Jul 2012 19:37:56 -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 AHW57758; Wed, 18 Jul 2012 22:38:48 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 19:35:47 -0700 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Jul 2012 19:35:46 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Thu, 19 Jul 2012 10:35:28 +0800 From: Songhaibin To: "arno@cs.vu.nl" , Peng Zhang Thread-Topic: [decade] [ppsp] Object naming in -req and -arch Thread-Index: AQHNYGz9SgP+UqsLmUq+tORnpn0WHZcmRtaAgAmX1jA= Date: Thu, 19 Jul 2012 02:35:29 +0000 Message-ID: References: <20120710162606039401143@chinamobile.com> <2039343B-5F6B-4777-864E-B4F00B5A258E@gmail.com> <4FFE6D67.80705@cs.vu.nl> <4FFFCA6D.7060306@cs.vu.nl> In-Reply-To: <4FFFCA6D.7060306@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.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Wed, 18 Jul 2012 19:51:06 -0700 Cc: ppsp , decade Subject: Re: [ppsp] [decade] Object naming in -req and -arch X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 02:37:57 -0000 I know little about Merkle Hash Tree. So I searched and learned some from t= he Internet. My feeling is MHT is useful for pre-stored objects. But it is = less useful for live contents. IMO, the co-relation of the objects besides = naming the object itself adds extra complexity in DECADE environment. Or is= there any good reason to use it? Just my 2 cents, -Haibin > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf = Of > Arno Bakker > Sent: Friday, July 13, 2012 3:13 PM > To: Peng Zhang > Cc: ppsp; decade > Subject: Re: [decade] [ppsp] Object naming in -req and -arch >=20 > On 12/07/2012 22:28, Peng Zhang wrote: > > > > On Jul 12, 2012, at 2:23 AM, Arno Bakker wrote: > > > >> The gains of using MHT depend on the chunk size. For PPSP we prefer > >> chunks of 1K that fit in an UDP packet carried over Ethernet. In > >> that case, for a 4 GB file, there are 4 M chunks, resulting in 80 > >> MB of leaf hashes when SHA1 is used. Transferring that beforehand > >> as in BitTorrent definitely increases latency ;o) > > Yes, if the chunk size is only 1KB, and each chunk is verified > > individually, we cannot afford to send all hashes beforehand. While > > in the worst case without optimization, almost 2*80M =3D 160M hashes > > needs to be sent to the receiver, will that be a large overhead > > compared to 4G? Do we really need such a small chunk size? Maybe I > > miss some previous discussion on this. >=20 > Hi >=20 > For PPSP we want to use UDP as we don't need the in-order and > reliability features of TCP, and want flexibility to use differnet > congestion control algorithms and handle NATs. With Ethernet as the > dominant MAC layer at present and an unreliable transport we don't want > datagrams to exceed the Ethernet MTU, otherwise the chance of losing a > datagram increases (an UDP packet taking N IP packets will not be > delivered when only 1 IP packet is lost). Hence, we use chunks of ~1K. >=20 > A good practice in P2P networks is to not forward data you have not > verified. So to forward the 1K chunks directly we need to be able to > verify their integrity at this granularity, enter Merkle Hash Trees. > We think the resulting overhead due to the size of the tree is > acceptable, as it is easy to optimize the number of hashes transmitted > in our use cases. >=20 > CU, > Arno From guyingjie@huawei.com Thu Jul 19 11:28:15 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A97821F84CF for ; Thu, 19 Jul 2012 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.367 X-Spam-Level: X-Spam-Status: No, score=-99.367 tagged_above=-999 required=5 tests=[AWL=-1.817, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, 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 pK-Wsoj+f1N8 for ; Thu, 19 Jul 2012 11:28:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C37D621F84B6 for ; Thu, 19 Jul 2012 11:28:11 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIE09120; Thu, 19 Jul 2012 14:29:05 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 11:27:51 -0700 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 11:27:57 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.86]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 02:27:51 +0800 From: "Guyingjie (Yingjie)" To: zhangyunfei , ppsp Thread-Topic: =?gb2312?B?W3Bwc3BdILTwuLQ6ICBDYWxsIGZvciByZXF1ZXN0IG9mIHRpbWUgc2xvdCBp?= =?gb2312?Q?n_IETF_84?= Thread-Index: AQHNZVMbYxhC3xCqhUmt6y95epHyrpcw7YwD Date: Thu, 19 Jul 2012 18:27:50 +0000 Message-ID: References: <2012070915093065758058@chinamobile.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.165] Content-Type: multipart/alternative; boundary="_000_A27496C192613C44A82D819E1B98DB5734036856SZXEML511MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [ppsp] =?gb2312?b?tPC4tDogILTwuLQ6ICBDYWxsIGZvciByZXF1ZXN0IG9m?= =?gb2312?b?IHRpbWUgc2xvdCBpbiBJRVRGIDg0?= X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 18:28:15 -0000 --_000_A27496C192613C44A82D819E1B98DB5734036856SZXEML511MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGxlYXNlIG9taXQgdGhpcyBlbWFpbCwgSSBndWVzcyBpdCdzIGJlY2F1c2Ugb2YgdGhlIG1pc29w ZXJhdGlvbiBvZiB0aGUgbWFpbCBzeXN0ZW0uIEkgYWxyZWFkeSBzZW50IGl0IGJlZm9yZSBhbmQg Z2V0IGNoYWlycycgcmVzcG9uc2UuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kt6K8/sjLOiBwcHNwLWJvdW5jZXNAaWV0Zi5vcmcgW3Bwc3AtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBHdXlpbmdqaWUgKFlpbmdqaWUpIFtndXlpbmdqaWVAaHVhd2VpLmNvbV0NCreiy83K sbzkOiAyMDEyxOo31MI5yNUgMTc6MDMNCrW9OiB6aGFuZ3l1bmZlaTsgcHBzcA0K1vfM4jogW3Bw c3BdILTwuLQ6IENhbGwgZm9yIHJlcXVlc3Qgb2YgdGltZSBzbG90IGluIElFVEYgODQNCg0KSSB3 b3VsZCBsaWtlIHRvIHJlcXVlc3QgZm9yIGEgdGltZSBzbG90IGZvcg0KVGl0bGU6IGRyYWZ0LWNy dXotcHBzcC1iYXNlLXRyYWNrZXItcHJvdG9jb2wuDQpQcmVzZW50ZXI6IFlpbmdqaWUgR3UNClRp bWU6IDIwIG1pbnMuDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkJlc3QgUmVnYXJkcw0KR3UgWWluZ2ppZQ0KDQq3orz+yMs6IHBwc3AtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnBwc3AtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SB6aGFuZ3l1bmZlaQ0Kt6LLzcqx vOQ6IDIwMTLE6jfUwjnI1SDA1sDWMTU6MDkNCsrVvP7IyzogcHBzcA0K1vfM4jogW3Bwc3BdIENh bGwgZm9yIHJlcXVlc3Qgb2YgdGltZSBzbG90IGluIElFVEYgODQNCg0KSGkgYWxsLA0KICAgIEZv ciB0aGUgYXV0aG9ycyB3aG8gYXJlIGludGVyZXN0ZWQgaW4gcHJlc2VudGluZyB0aGUgZHJhZnRz IGluIElFVEYgODQsIHBsZWFzZSBsZXQgU3RlZmFubyBhbmQgbWUga25vdyBhYm91dCB0aGUgdGlt ZSBzbG90cyB5b3UgcmVxdWVzdCBhbmQgdGhlIHRpdGxlL3ByZXNlbnRlciBpbmZvcm1hdGlvbiBi ZWZvcmUgSnVseSAxNXRoIGFuZCBzZW5kIHlvdXIgc2xpZGVzIGJlZm9yZSBKdWx5IDI3dGguIFRo YW5rcy4NCg0KQlINClN0ZWZhbm8gYW5kIFl1bmZlaQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kemhhbmd5dW5mZWkNCg== --_000_A27496C192613C44A82D819E1B98DB5734036856SZXEML511MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Please omit this email, I guess it's because of the misoperation of the = mail system. I already sent it before and get chairs' response.

 

=B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [= ppsp-bounces@ietf.org] =B4=FA=B1=ED Guyingjie (Yingjie) [guyingjie@huawei.c= om]
=B7=A2=CB=CD=CA=B1=BC=E4: 2012=C4=EA7=D4=C29=C8=D5 17:03
=B5=BD: zhangyunfei; ppsp
=D6=F7=CC=E2: [ppsp] =B4=F0=B8=B4: Call for request of time slot in = IETF 84

I would like to request for a time slot for

Title: draft-cruz-ppsp-base-tracker-protocol.

Presenter: Yingjie Gu

Time: 20 mins.

 

 

 

 

 

Best Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB:<= /span> ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED= zhangyunfei
=B7=A2=CB=CD= =CA=B1=BC=E4: 2012=C4=EA7=D4= =C29=C8=D5 =C0=D6=C0=D615:09
=CA=D5=BC=FE=C8=CB: ppsp
=D6=F7=CC=E2: [ppsp] Call for request of time slot in IETF 84

 

Hi all,

  = ;  For the authors who are interested in presenting the drafts in IETF= 84, please let Stefano and me know about the time slots you request and the title/presenter information before July 15= th and send your slides before July 27th. Thanks.

&nbs= p;

BR

Stefano and= Yunfei

&nbs= p;

zhangyunfei=

--_000_A27496C192613C44A82D819E1B98DB5734036856SZXEML511MBSchi_-- From a.bakker@vu.nl Wed Jul 25 04:39: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 406F021F85CC for ; Wed, 25 Jul 2012 04:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 K+5pIoFQpngv for ; Wed, 25 Jul 2012 04:39:40 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2539621F8559 for ; Wed, 25 Jul 2012 04:39:39 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 25 Jul 2012 13:39:36 +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.298.4; Wed, 25 Jul 2012 13:39:37 +0200 Message-ID: <500FDAFF.7000402@cs.vu.nl> Date: Wed, 25 Jul 2012 13:39: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: Karl Knutsson References: <20120722185419.GA69574@pad.knet> In-Reply-To: <20120722185419.GA69574@pad.knet> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp@ietf.org Subject: Re: [ppsp] I-D Action: draft-ietf-ppsp-peer-protocol-02.txt 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, 25 Jul 2012 11:39:41 -0000 Hi Karl thanks for the thorough read. On 22/07/2012 20:54, Karl Knutsson wrote: > > 1) Section 8. > I think it would be a good idea to add an End Option similar to rfc2132 to > make it easier to tell where the Handshake message ends and new messages > start. > Yes, will be added in -03. > 2) Section 9.1.4 > The text and the on the wire formats include the Version message from -01. > At to moment how Handshake options are sent isn't described anywhere in the > document. You are right, I wanted to wait for people's feedback before adjusting the binary notation. > 3) On the wire format for "MAY explicit close..." should start with > receiver's channel id. > Yes. Will be fixed in -03. > 4) Section 9.1.6 > Text mention a 64-bit microsecond time stamp but on wire format only > shows a 32 bit time stamp value. Well spotted. We are currently looking at the latest LEDBAT spec and where and what size timers are needed. CU, Arno From zhangyunfei@chinamobile.com Sun Jul 29 12:42:24 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 3702721F86B2 for ; Sun, 29 Jul 2012 12:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.717 X-Spam-Level: X-Spam-Status: No, score=-96.717 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0TCYJLzKeIV for ; Sun, 29 Jul 2012 12:42:23 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 838C821F86A7 for ; Sun, 29 Jul 2012 12:42:23 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 5A3A4E403; Mon, 30 Jul 2012 03:42:22 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 532B1E3BE; Mon, 30 Jul 2012 03:42:22 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012073003421927-4355 ; Mon, 30 Jul 2012 03:42:19 +0800 Date: Mon, 30 Jul 2012 03:42:06 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012073003420690606140@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-30 03:42:19, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-07-30 03:42:21, Serialize complete at 2012-07-30 03:42:21 Content-Type: multipart/alternative; boundary="----=_001_NextPart818878384043_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19072.001 X-TM-AS-Result: No--5.472-7.0-31-10 X-imss-scan-details: No--5.472-7.0-31-10;No--5.472-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Meeting slides have been uploaded X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 19:42:24 -0000 This is a multi-part message in MIME format. ------=_001_NextPart818878384043_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgYWxsLA0KICAgVGhlIG1lZXRpbmcgc2xpZGVzIGZvciB0aGlzIElFVEYgaGF2ZSBiZWVuIHVw bG9hZGVkLiAgWW91IGNhbiB2aXNpdCBhbmQgZG93bmxvYWQgdGhlbSBpbiB0aGUgZm9sbG93aW5n IGxpbms6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODQvbWF0ZXJpYWxz Lmh0bWwgDQogICAgIFNlZSB5b3UgaW4gVmFuY291dmVyLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoN CnpoYW5neXVuZmVp ------=_001_NextPart818878384043_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi all,
   The meeting slides for this IETF=20 have been uploaded.  You can visit and download them i= n the=20 following link:
https://da= tatracker.ietf.org/meeting/84/materials.html=20
     See you in Vancouver.
 
BR
Yunfei
 
zhangyunfei
------=_001_NextPart818878384043_=------ From zhangyunfei@chinamobile.com Tue Jul 31 09:37:53 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 631DD21F8671 for ; Tue, 31 Jul 2012 09:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.896 X-Spam-Level: X-Spam-Status: No, score=-98.896 tagged_above=-999 required=5 tests=[AWL=1.727, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 LOeMhLxmswfR for ; Tue, 31 Jul 2012 09:37:52 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBE021F867E for ; Tue, 31 Jul 2012 09:37:52 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 169EAE575; Wed, 1 Aug 2012 00:37:52 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 0AB7DE3EF; Wed, 1 Aug 2012 00:37:52 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012080100374927-22068 ; Wed, 1 Aug 2012 00:37:49 +0800 Date: Wed, 1 Aug 2012 00:37:43 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012080100374352607728@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-01 00:37:50, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-08-01 00:37:51, Serialize complete at 2012-08-01 00:37:51 Content-Type: multipart/alternative; boundary="----=_001_NextPart523111121053_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19074.007 X-TM-AS-Result: No--38.523-7.0-31-10 X-imss-scan-details: No--38.523-7.0-31-10;No--38.523-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Reminder about PPSP remote participation 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, 31 Jul 2012 16:37:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart523111121053_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgRm9sa3MsDQoNCiAgICBXZSBoYXZlIGFwcGxpZWQgZm9yIFdlYkV4IGFzIG91ciByZW1vdGUg cGFydGljaXBhdGlvbiB0b29sIGZvciB0b21vcnJvdyBtb3JuaW5nJ3MgbWVldGluZy4gUGxlYXNl IHNlZSBiZWxvdyBmb3IgZGV0YWlsLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5neXVuZmVp DQoNCkZyb206IENpbmR5IE1vcmdhbg0KRGF0ZTogMjAxMi0wOC0wMSAwMDozMA0KVG86IHpoYW5n eXVuZmVpDQpTdWJqZWN0OiBNZWV0aW5nIGludml0YXRpb246IHBwc3ANCg0KSGVsbG8gLCANCg0K Q2luZHkgTW9yZ2FuIGludml0ZXMgeW91IHRvIGF0dGVuZCB0aGlzIG9ubGluZSBtZWV0aW5nLiAN Cg0KVG9waWM6IHBwc3AgDQpEYXRlOiBXZWRuZXNkYXksIEF1Z3VzdCAxLCAyMDEyIA0KVGltZTog OTowMCBhbSwgUGFjaWZpYyBEYXlsaWdodCBUaW1lIChTYW4gRnJhbmNpc2NvLCBHTVQtMDc6MDAp IA0KTWVldGluZyBOdW1iZXI6IDY0MiAyNjUgNTMzIA0KTWVldGluZyBQYXNzd29yZDogMTIzNCAN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIA0KVG8gam9pbiB0aGUgb25saW5lIG1lZXRpbmcgKE5vdyBmcm9tIG1vYmlsZSBkZXZpY2Vz ISkgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIA0KMS4gR28gdG8gaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP0VEPTE1NzM3 MjQzNyZVSUQ9MTI2MzMxNDU4NyZQVz1OTkROa05HRXlaV0ZqJlJUPU1pTTAgDQoyLiBJZiByZXF1 ZXN0ZWQsIGVudGVyIHlvdXIgbmFtZSBhbmQgZW1haWwgYWRkcmVzcy4gDQozLiBJZiBhIHBhc3N3 b3JkIGlzIHJlcXVpcmVkLCBlbnRlciB0aGUgbWVldGluZyBwYXNzd29yZDogMTIzNCANCjQuIENs aWNrICJKb2luIi4gDQoNClRvIHZpZXcgaW4gb3RoZXIgdGltZSB6b25lcyBvciBsYW5ndWFnZXMs IHBsZWFzZSBjbGljayB0aGUgbGluazogDQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5w aHA/RUQ9MTU3MzcyNDM3JlVJRD0xMjYzMzE0NTg3JlBXPU5ORE5rTkdFeVpXRmomT1JUPU1pTTAg DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSANCkZvciBhc3Npc3RhbmNlIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCjEuIEdvIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9tYyANCjIuIE9uIHRoZSBsZWZ0IG5hdmlnYXRpb24gYmFyLCBjbGljayAiU3VwcG9ydCIu IA0KDQpZb3UgY2FuIGNvbnRhY3QgbWUgYXQ6IA0KY21vcmdhbkBhbXNsLmNvbSANCjEtNTEwLTQ5 Mi00MDg1IA0KDQpUbyBhZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXIgcHJvZ3JhbSAo Zm9yIGV4YW1wbGUgTWljcm9zb2Z0IE91dGxvb2spLCBjbGljayB0aGlzIGxpbms6IA0KaHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP0VEPTE1NzM3MjQzNyZVSUQ9MTI2MzMxNDU4NyZJ Q1M9TUkmTEQ9MSZSRD0yJlNUPTEmU0hBMj1yWncxNDBvLXc3ajA0M1EtZ0NmRU95dy9HWFFhRmZt WU5ydVpmRi9vbHRVPSZSVD1NaU0wIA0KDQpUaGUgcGxheWJhY2sgb2YgVUNGIChVbml2ZXJzYWwg Q29tbXVuaWNhdGlvbnMgRm9ybWF0KSByaWNoIG1lZGlhIGZpbGVzIHJlcXVpcmVzIGFwcHJvcHJp YXRlIHBsYXllcnMuIFRvIHZpZXcgdGhpcyB0eXBlIG9mIHJpY2ggbWVkaWEgZmlsZXMgaW4gdGhl IG1lZXRpbmcsIHBsZWFzZSBjaGVjayB3aGV0aGVyIHlvdSBoYXZlIHRoZSBwbGF5ZXJzIGluc3Rh bGxlZCBvbiB5b3VyIGNvbXB1dGVyIGJ5IGdvaW5nIHRvIGh0dHBzOi8vaWV0Zi53ZWJleC5jb20v aWV0Zi9zeXN0ZW1kaWFnbm9zaXMucGhwLiANCg0KU2lnbiB1cCBmb3IgYSBmcmVlIHRyaWFsIG9m IFdlYkV4IA0KaHR0cDovL3d3dy53ZWJleC5jb20vZ28vbWNlbWZyZWV0cmlhbCANCg0KaHR0cDov L3d3dy53ZWJleC5jb20gDQoNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZp Y2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRz IGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGlj YWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRv IHRoZSByZWNvcmRpbmcsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhv c3QgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mIHRoZSByZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uIFBsZWFzZSBub3RlIHRoYXQgYW55IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3Vi amVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2ZW50IG9mIGxpdGlnYXRpb24uIA== ------=_001_NextPart523111121053_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi Folks,

    We have applied for WebEx as our = remote=20 participation tool for tomorrow morning's meeting. Please see below for=20 detail.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-08-01 00:30
To: zhangyunfei
Subject: Meeting invitation: ppsp

Hello ,

= Cindy=20 Morgan invites you to attend this online meeting.

Topic: ppsp
= Date:=20 Wednesday, August 1, 2012
Time: 9:00 am, Pacific Daylight Time (San=20 Francisco, GMT-07:00)
Meeting Number: 642 265 533
Meeting Password= : 1234=20


-------------------------------------------------------
To= join=20 the online meeting (Now from mobile devices!)=20
-------------------------------------------------------
1. Go to <= A=20 href=3D"https://ietf.webex.com/ietf/j.php?ED=3D157372437&UID=3D1263314= 587&PW=3DNNDNkNGEyZWFj&RT=3DMiM0"=20 target=3D_blank>https://ietf.webex.com/ietf/j.php?ED=3D157372437&UID= =3D1263314587&PW=3DNNDNkNGEyZWFj&RT=3DMiM0=20
2. If requested, enter your name and email address.
3. If a passwo= rd is=20 required, enter the meeting password: 1234
4. Click "Join".

To= view=20 in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?ED=3D157372437&UID= =3D1263314587&PW=3DNNDNkNGEyZWFj&ORT=3DMiM0=20


-------------------------------------------------------
Fo= r=20 assistance
------------------------------------------------------- 1. Go=20 to https://ietf.webex.com/ietf/mc
2. On the left navi= gation=20 bar, click "Support".

You can contact me at:
cmorgan@amsl.com
1-510-492-4085=20

To add this meeting to your calendar program (for example Microsof= t=20 Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=3D157372437&UID= =3D1263314587&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DrZw= 140o-w7j043Q-gCfEOyw/GXQaFfmYNruZfF/oltU=3D&RT=3DMiM0=20

The playback of UCF (Universal Communications Format) rich media f= iles=20 requires appropriate players. To view this type of rich media files in the= =20 meeting, please check whether you have the players installed on your compu= ter by=20 going to https://ietf.webe= x.com/ietf/systemdiagnosis.php.=20

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial

http://www.webex.com=20



IMPORTANT NOTICE: This WebEx service includes a feature th= at=20 allows audio and any documents and other materials exchanged or viewed dur= ing=20 the session to be recorded. By joining this session, you automatically con= sent=20 to such recordings. If you do not consent to the recording, discuss your=20 concerns with the meeting host prior to the start of the recording or do n= ot=20 join the session. Please note that any such recordings may be subject to=20 discovery in the event of litigation.
------=_001_NextPart523111121053_=------