From zhangyunfei@chinamobile.com Sun Mar 4 19:33: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 914E921F86BD for ; Sun, 4 Mar 2012 19:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.33 X-Spam-Level: X-Spam-Status: No, score=-98.33 tagged_above=-999 required=5 tests=[AWL=1.446, BAYES_50=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78YGgsRfht6c for ; Sun, 4 Mar 2012 19:33:51 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD3321F86B4 for ; Sun, 4 Mar 2012 19:33:51 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id EE340E50E; Mon, 5 Mar 2012 11:33:49 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id E29EAE50B; Mon, 5 Mar 2012 11:33:49 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012030511334728-7214 ; Mon, 5 Mar 2012 11:33:47 +0800 Date: Mon, 5 Mar 2012 11:33:47 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012030511334795071534@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-05 11:33:47, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-05 11:33:49, Serialize complete at 2012-03-05 11:33:49 Content-Type: multipart/alternative; boundary="----=_001_NextPart367374613325_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18752.004 X-TM-AS-Result: No--34.385-7.0-31-10 X-imss-scan-details: No--34.385-7.0-31-10;No--34.385-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] PPSP Phone Meeting invitation: Dial-in details via Webex 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, 05 Mar 2012 03:33:52 -0000 This is a multi-part message in MIME format. ------=_001_NextPart367374613325_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGVsbG8gZm9sa3MsIA0KDQpXZSB3aWxsIHVzZSBXZWJleCAoaHR0cDovL3d3dy53ZWJleC5jb20v KSB0byBob2xkIG91ciBQUFNQIG1lZXRpbmcgb24gTWFyY2ggN3RoIChUaGlzIGlzIG5vdCB0aGUg KmZvcm1hbCogaW50ZXJpbSBtZWV0aW5nIGJlY2F1c2UgdGhlIHRpbWUgc3VpdGFibGUgZm9yIG1v c3QgcGVvcGxlIGlzIG5vdCB0d28gd2Vla3MgZWFybGllciB0aGFuIHRoYXQgd2UgY2FuIGFubm91 bmNlIHRoZSBkYXRlKSAuIEJ1dCB3ZSBjYW4gaW5kZWVkIGRpc2N1c3MgdGhlIGxlZnQgdGVjaG5p Y2FsIGlzc3VlcyBhbmQgcG9zdCB0byB0aGUgbGlzdCB0byBnZXQgY29uc2Vuc3VzIG9uIHRoZSBs aXN0LiAgDQpTZWUgYmVsb3cgZm9yIHRoZSAiZGlhbC1pbiIgZGV0YWlscy4gUGVlciB0byBQZWVy IFN0cmVhbWluZyBQcm90b2NvbCBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGF0dGVuZCB0 aGlzIG9ubGluZSBtZWV0aW5nLiANCg0KVG9waWM6IFBQU1AgDQpEYXRlOiBXZWRuZXNkYXksIE1h cmNoIDcsIDIwMTIgDQpUaW1lOiAxMDowMCBhbSwgR01UIFRpbWUgKExvbmRvbiwgR01UKSANCk1l ZXRpbmcgTnVtYmVyOiA2NDYgNzE3IDg5MyANCk1lZXRpbmcgUGFzc3dvcmQ6IDEyMzQgDQoNCkxv b2tpbmcgZm9yd2FyZCB0byBkaXNjdXNzaW5nIHdpdGggeW91IG9ubGluZS4NCg0KQlINCll1bmZl aQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gDQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20gbW9iaWxlIGRldmlj ZXMhKSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0gDQoxLiBHbyB0byBodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/RUQ9MTUw NTUyNzk3JlVJRD0xMjM3MzE4NjI3JlBXPU5NR00wTVROak16aG0mUlQ9TWlNeU1RJTNEJTNEIA0K Mi4gSWYgcmVxdWVzdGVkLCBlbnRlciB5b3VyIG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuIA0KMy4g SWYgYSBwYXNzd29yZCBpcyByZXF1aXJlZCwgZW50ZXIgdGhlIG1lZXRpbmcgcGFzc3dvcmQ6IDEy MzQgDQo0LiBDbGljayAiSm9pbiIuIA0KDQpUbyB2aWV3IGluIG90aGVyIHRpbWUgem9uZXMgb3Ig bGFuZ3VhZ2VzLCBwbGVhc2UgY2xpY2sgdGhlIGxpbms6IA0KaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP0VEPTE1MDU1Mjc5NyZVSUQ9MTIzNzMxODYyNyZQVz1OTUdNME1UTmpNemht Jk9SVD1NaU15TVElM0QlM0QgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpUbyBqb2luIHRoZSBhdWRpbyBjb25mZXJlbmNlIG9ubHkg DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t IA0KQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTogKzEtNDA4LTYwMC0zNjAwIA0KDQpB Y2Nlc3MgY29kZTo2NDYgNzE3IDg5MyANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCkZvciBhc3Npc3RhbmNlIA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCjEuIEdvIHRvIGh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyANCjIuIE9uIHRoZSBsZWZ0IG5hdmlnYXRpb24g YmFyLCBjbGljayAiU3VwcG9ydCIuIA0KDQpZb3UgY2FuIGNvbnRhY3QgbWUgYXQ6IA0KY21vcmdh bkBhbXNsLmNvbSANCjEtNTEwLTQ5Mi00MDg1IA0KDQpUbyBhZGQgdGhpcyBtZWV0aW5nIHRvIHlv dXIgY2FsZW5kYXIgcHJvZ3JhbSAoZm9yIGV4YW1wbGUgTWljcm9zb2Z0IE91dGxvb2spLCBjbGlj ayB0aGlzIGxpbms6IA0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP0VEPTE1MDU1 Mjc5NyZVSUQ9MTIzNzMxODYyNyZJQ1M9TUkmTEQ9MSZSRD0yJlNUPTEmU0hBMj0yUGc4T1cwenl0 ZXpsVTJKMm9oZWc0YmtBQkdFRU1nS0xKS2RaL21OaDQwPSZSVD1NaU15TVElM0QlM0QgDQoNClRo ZSBwbGF5YmFjayBvZiBVQ0YgKFVuaXZlcnNhbCBDb21tdW5pY2F0aW9ucyBGb3JtYXQpIHJpY2gg bWVkaWEgZmlsZXMgcmVxdWlyZXMgYXBwcm9wcmlhdGUgcGxheWVycy4gVG8gdmlldyB0aGlzIHR5 cGUgb2YgcmljaCBtZWRpYSBmaWxlcyBpbiB0aGUgbWVldGluZywgcGxlYXNlIGNoZWNrIHdoZXRo ZXIgeW91IGhhdmUgdGhlIHBsYXllcnMgaW5zdGFsbGVkIG9uIHlvdXIgY29tcHV0ZXIgYnkgZ29p bmcgdG8gaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL3N5c3RlbWRpYWdub3Npcy5waHAuIA0K DQpTaWduIHVwIGZvciBhIGZyZWUgdHJpYWwgb2YgV2ViRXggDQpodHRwOi8vd3d3LndlYmV4LmNv bS9nby9tY2VtZnJlZXRyaWFsIA0KDQpodHRwOi8vd3d3LndlYmV4LmNvbSANCg0KQ0NQOisxNDA4 NjAwMzYwMHg2NDY3MTc4OTMjIA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNlcnZp Y2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1lbnRz IGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNlc3Np b24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGlj YWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRv IHRoZSByZWNvcmRpbmcsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5nIGhv c3QgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mIHRoZSByZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4gdGhl IHNlc3Npb24uIFBsZWFzZSBub3RlIHRoYXQgYW55IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUgc3Vi amVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2ZW50IG9mIGxpdGlnYXRpb24uIA== ------=_001_NextPart367374613325_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF
Hello folks,

We will use Webex (http://www.webex.com/) to hold our PPSP meeting on Marc= h 7th=20 (This is not the *formal* interim meeting because the time=20 suitable for most people is not two weeks earlier=20 than that we can announce the date) . But we can indeed discuss the left techni= cal issues=20 and post to the list to get consensus on the list.  
See below for the "dial-in" details. Peer t= o Peer=20 Streaming Protocol Working Group invites you to attend this online meeting= .=20

Topic: PPSP
Date: Wednesda= y, March 7,=20 2012
Time: 10:00 am, GMT Time (London, GMT)
Meeting Number: 646 71= 7 893=20
Meeting Password: 1234
 
Looking forward to discussing with you=20 online.
 
BR
Yunfei


----------------= ---------------------------------------=20
To join the online meeting (Now from mobile devices!)=20
-------------------------------------------------------
1. Go to <= A=20 style=3D"FONT-SIZE: 10pt"=20 href=3D"https://ietf.webex.com/ietf/j.php?ED=3D150552797&UID=3D1237318= 627&PW=3DNMGM0MTNjMzhm&RT=3DMiMyMQ%3D%3D"=20 target=3D_blank>https://ietf.webex.com/ietf/j.php?ED=3D150552797&UID= =3D1237318627&PW=3DNMGM0MTNjMzhm&RT=3DMiMyMQ%3D%3D=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=3D150552797&UID= =3D1237318627&PW=3DNMGM0MTNjMzhm&ORT=3DMiMyMQ%3D%3D=20

-------------------------------------------------------
To joi= n the=20 audio conference only=20
-------------------------------------------------------
Call-in to= ll=20 number (US/Canada): +1-408-600-3600

Access code:646 717 893=20

-------------------------------------------------------
For=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.co= m=20
1-510-492-4085

To add this meeting to your calendar program (f= or=20 example Microsoft Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=3D150552797&UID= =3D1237318627&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3D2Pg= 8OW0zytezlU2J2oheg4bkABGEEMgKLJKdZ/mNh40=3D&RT=3DMiMyMQ%3D%3D=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

CCP:+14086003600x64671789= 3#=20

IMPORTANT NOTICE: This WebEx service includes a feature that allow= s=20 audio and any documents and other materials exchanged or viewed during the= =20 session to be recorded. By joining this session, you automatically consent= to=20 such recordings. If you do not consent to the recording, discuss your conc= erns=20 with the meeting host prior to the start of the recording or do not join t= he=20 session. Please note that any such recordings may be subject to discovery = in the=20 event of litigation.
------=_001_NextPart367374613325_=------ From a.bakker@vu.nl Wed Mar 7 02:01: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 4D9CD21F86EB for ; Wed, 7 Mar 2012 02:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.213 X-Spam-Level: X-Spam-Status: No, score=-0.213 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_40=-0.185, GB_I_INVITATION=-2, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2rTKtV+lzXF for ; Wed, 7 Mar 2012 02:01:53 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4721F86E4 for ; Wed, 7 Mar 2012 02:01:50 -0800 (PST) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 7 Mar 2012 11:01:45 +0100 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.1.218.12; Wed, 7 Mar 2012 11:01:48 +0100 Message-ID: <4F573219.30904@cs.vu.nl> Date: Wed, 7 Mar 2012 11:02:01 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <2012030511334795071534@chinamobile.com> In-Reply-To: <2012030511334795071534@chinamobile.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] PPSP Phone Meeting invitation: Dial-in details via Webex 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, 07 Mar 2012 10:01:54 -0000 On 05/03/2012 04:33, zhangyunfei wrote: > Firefox says that the required software from ietf.webex.com is corrupt? Anyone else having this problem? CU, Arno From zhangyunfei@chinamobile.com Wed Mar 7 02:36:38 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 9F9A321F8797 for ; Wed, 7 Mar 2012 02:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.844 X-Spam-Level: X-Spam-Status: No, score=-97.844 tagged_above=-999 required=5 tests=[AWL=0.779, 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 jak-ulFnmXMk for ; Wed, 7 Mar 2012 02:36:36 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AFD1921F87C1 for ; Wed, 7 Mar 2012 02:36:36 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 1084BE57F for ; Wed, 7 Mar 2012 18:36:34 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id DEF91E48E for ; Wed, 7 Mar 2012 18:36:33 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012030718363265-17346 ; Wed, 7 Mar 2012 18:36:32 +0800 Date: Wed, 7 Mar 2012 18:36:28 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012030718362805471827@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-07 18:36:33, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-07 18:36:33, Serialize complete at 2012-03-07 18:36:33 Content-Type: multipart/alternative; boundary="----=_001_NextPart362457643032_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18758.005 X-TM-AS-Result: No--11.388-7.0-31-10 X-imss-scan-details: No--11.388-7.0-31-10;No--11.388-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Comments on peer protocol X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:36:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart362457643032_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" SGVyZSBpcyBteSBwZXJzb25hbCBjb21tZW50cyBvbiBwZWVyIHByb3RvY29sIGZvciB0b2RheSdz IGRpc2N1c3Npb246DQoxKWJpbiBudW1iZXJpbmc6IEhvdyB0byBhcHBseSBpbiBleGlzdGluZyBw MnAgc3RyZWFtaW5nIHN5c3RlbXM/IEFsbCBvZiB0aGVtKCB0byB0aGUgYmVzdCBvZiBteSBrbm93 bGVkZ2UpIHVzZSBhIHNhbWUgbGV2ZWwoIGluc3RlYWQgb2YgaGllcmFyY2hpY2FsKSBudW1iZXIg dG8gZGVub3RlIHRoZSBjaHVua0lEIChhbmQgc2NvcGUpOyANCjIpIE1lcmtsZSBoYXNoIHRyZWU6 IFRoZSB3YXkgaXMgZ29vZCBmb3IgY2hlY2tpbmcgY29udGVudCBpbnRlZ3JpdHkuIEhvd2V2ZXIg aXMgaXQgdXNpbmcgdG9vIG11Y2ggZWZmb3J0IHRvIHByZXZlbnQgbWFsaWNpb3VzIGF0dGFja3M/ KCBJdCdzIGRpZmZlcmVudCBmcm9tIGZpbGUgZG93bmxvYWRpbmcgY2FzZSwgd2hlcmUgdGhlIHVz ZXIgY2FuIGRldGVjdCByZWNlaXZpbmcgdGhlIHdyb25nIGZpbGUgb25seSBhZnRlciBpdCBkb3du bG9hZHMgYWxsIGNodW5rcyBvciB1c2luZyB0aGUgbWVya2xlIGhhc2ggdHJlZSBkZXRlY3Rpb24u IEJ1dCBmb3IgdGhlICJjbGljayBhbmQgcGxheSByaWdodCBub3ciIHN0cmVhbWluZywgdGhlIHVz ZXIgY2FuIGRpc2Nlcm4gdGhlIGF0dGFjayBtdWNoIGVhcmxpZXIsIHJpZ2h0Pw0KMylQRVggbWVz c2FnZSByZXVzZSBpbiB0cmFja2VyIHByb3RvY29sOiBTaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRy YWNrZXIgcHJvdG9jb2wgcHJvdG9jb2wgb3Igc2VwYXJhdGUgcHJvcG9zYWw7DQo0KSBTaWduYWxp bmcgYW5kIGRhdGEgY291cGxpbmc6IE9idmlvdXNseSB0aGVyZSBhcmUgYXJndW1lbnQgb24gdGhp cyBwb2ludC4gU2hvdWxkIGdpdmUgbW9yZSBldmlkZW5jZSBvbiB0aGUgYWR2YW50YWdlczsNCjUp IFJlcXVpcmVtZW50OiBTaG91bGQgYmUgbWVyZ2VkIGluIFBTIGRyYWZ0Pw0KDQpCUg0KWXVuZmVp ICANCg0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ== ------=_001_NextPart362457643032_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Here is my personal comments on peer protocol for today's discussion:=
1)bin numbering: How to apply in existing p2p streaming systems? All = of=20 them( to the best of my knowledge) use a same level( instead of hierarchic= al)=20 number to denote the chunkID (and scope); 
2) Merkle hash tree: The way is good for checking content integrity.=20 However is it using too much effort to prevent malicious attacks?( It= 's=20 different from file downloading case, where the user can=20 detect receiving the wrong file only after it downloads all chunks or= using=20 the merkle hash tree detection. But for the "click and play right now= "=20 streaming, the user can discern the attack much earlier, right?
3)PEX message reuse in tracker protocol: Should be discussed in=20 tracker protocol protocol or separate proposal;
4) Signaling and data coupling: Obviously there are argument on this = point.=20 Should give more evidence on the advantages;
5) Requirement: Should be merged in PS draft?
 
BR
Yunfei  
 
 
zhangyunfei
 
------=_001_NextPart362457643032_=------ From zhangyunfei@chinamobile.com Wed Mar 7 17:45: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 4DA7421E800F for ; Wed, 7 Mar 2012 17:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.559 X-Spam-Level: X-Spam-Status: No, score=-98.559 tagged_above=-999 required=5 tests=[AWL=1.403, BAYES_40=-0.185, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbt4BRxrneu2 for ; Wed, 7 Mar 2012 17:45:52 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6AC21F8565 for ; Wed, 7 Mar 2012 17:45:52 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 93D5EE4BB for ; Thu, 8 Mar 2012 09:45:47 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 71787E4A3 for ; Thu, 8 Mar 2012 09:45:47 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012030809454513-2344 ; Thu, 8 Mar 2012 09:45:45 +0800 Date: Thu, 8 Mar 2012 09:45:40 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201203080945408662583@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-08 09:45:45, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-08 09:45:47, Serialize complete at 2012-03-08 09:45:47 Content-Type: multipart/alternative; boundary="----=_001_NextPart323772875714_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18760.003 X-TM-AS-Result: No--16.162-7.0-31-10 X-imss-scan-details: No--16.162-7.0-31-10;No--16.162-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] WebEx recording "PPSP-20120307 1006-2" 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, 08 Mar 2012 01:45:54 -0000 This is a multi-part message in MIME format. ------=_001_NextPart323772875714_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGkgYWxsLA0KICAgVGhlIGZvbGxvd2luZyBsaW5rIGlzIHRoZSB3ZWJleCByZWNvcmRpbmcgZm9y IHllc3RlcmRheSdzIG1lZXRpbmcgZm9yIHlvdXIgcmVmZXJlbmNlLg0KDQpCUg0KWXVuZmVpDQoN Cg0KDQoNCnpoYW5neXVuZmVpDQoNCkZyb206IENpbmR5IE1vcmdhbg0KRGF0ZTogMjAxMi0wMy0w OCAwMDozNw0KVG86IHpoYW5neXVuZmVpDQpTdWJqZWN0OiBJbnZpdGF0aW9uIHRvIHZpZXcgV2Vi RXggcmVjb3JkaW5nICJQUFNQLTIwMTIwMzA3IDEwMDYtMiINCkkgd2FudCB0byBzaGFyZSB0aGUg Zm9sbG93aW5nIFdlYkV4IHJlY29yZGluZyB3aXRoIHlvdS4gQ2xpY2sgdGhlIGxpbmsgYmVsb3cg dG8gcGxheSBpdDogDQoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP0FUPXBi JlNQPU1DJnJJRD02MTM3NDg3JnJLZXk9ZWM0Y2RjMDBkNzAwOTAyNyANCg0KUFBTUC0yMDEyMDMw NyAxMDA2LTIgDQpNYXJjaCA3LCAyMDEyLCAzOjQ3IGFtIFNhbiBGcmFuY2lzY28gVGltZSANCjEg aG91ciAzNCBtaW5zIA0KDQoNCg0KSWYgeW91IG5lZWQgYXNzaXN0YW5jZSwgeW91IGNhbiBjb250 YWN0IG1lIGF0IGNtb3JnYW5AYW1zbC5jb20uIA0KDQpodHRwOi8vd3d3LndlYmV4LmNvbSA= ------=_001_NextPart323772875714_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF
Hi all,
   The following link is the webex recording for yesterday'= s=20 meeting for your reference.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-03-08 00:37
To: zhangyunfei
Subject: Invitation to view WebEx recording "PPSP-2012030= 7=20 1006-2"
I want to share the=20 following WebEx recording with you. Click the link below to play it:
<= BR>https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&SP=3DMC&am= p;rID=3D6137487&rKey=3Dec4cdc00d7009027=20

PPSP-20120307 1006-2
March 7, 2012, 3:47 am San Francisco Time=
1=20 hour 34 mins



If you need assistance, you can contact me at= cmorgan@amsl.com.

http://www.webex.com=20
------=_001_NextPart323772875714_=------ From xiajinwei@huawei.com Thu Mar 8 00:32:47 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 B653F21F8592 for ; Thu, 8 Mar 2012 00:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrasKPYkfWRU for ; Thu, 8 Mar 2012 00:32:46 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4577121F8594 for ; Thu, 8 Mar 2012 00:32:46 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0K00MN351WUG@szxga04-in.huawei.com> for ppsp@ietf.org; Thu, 08 Mar 2012 16:32:20 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0K008XY51WC1@szxga04-in.huawei.com> for ppsp@ietf.org; Thu, 08 Mar 2012 16:32:20 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHI19143; Thu, 08 Mar 2012 16:32:20 +0800 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 16:31:35 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.9]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 16:32:15 +0800 Date: Thu, 08 Mar 2012 08:32:15 +0000 From: Xiajinwei X-Originating-IP: [10.138.41.97] To: "ppsp@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_DoBhqz4kTvsD7D+b8d0m5g)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: comments on latency in tracker protocol Thread-index: Acz9BfakCd8HbLY9SdmBT5AwhiElbA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [ppsp] comments on latency in 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: Thu, 08 Mar 2012 08:32:47 -0000 --Boundary_(ID_DoBhqz4kTvsD7D+b8d0m5g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Let's push this work forward. According to the discussion in the conference call, IMHO this 07 version has significant enhancement on quality, and its structure is much clearer compared to last version. For the latency concern raised in the call, I think latency indeed is an important element which impacts the user experience. Actually, user usually can't tolerate much latency during multimedia playback, but be a little patient on the beginning of multimedia playback. The beginning latency is mainly induced by a set of components, such as multicast joining, data transferring, buffering, decoding and demultiplexing. The Information acquisition latency (the time it takes peer to acquire the information from tracker) should be also in the scope of beginning latency. Let's consider VoIP use case, SIP procedure is also necessary before the VoIP data transferring. Hope this explanation is useful. Thank you Jinwei --Boundary_(ID_DoBhqz4kTvsD7D+b8d0m5g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi all,

 

Let’s push this work forward.

 

According to the discussion in the conference call, IMHO this 07 version has significant enhancement on quality, and its structure is much clearer compared to last version. For the latency concern raised in the call, I think latency indeed is an important element which impacts the user experience. Actually, user usually can’t tolerate much latency during multimedia playback, but be a little patient on the beginning of multimedia playback. The beginning latency is mainly induced by a set of components, such as multicast joining, data transferring, buffering, decoding and demultiplexing. The Information acquisition latency (the time it takes peer to acquire the information from tracker) should be also in the scope of beginning latency. Let’s consider VoIP use case, SIP procedure is also necessary before the VoIP data transferring.

 

Hope this explanation is useful.

 

 

Thank you

 

Jinwei

--Boundary_(ID_DoBhqz4kTvsD7D+b8d0m5g)-- From zhangyunfei@chinamobile.com Thu Mar 8 23:42:22 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 2100B21F8663 for ; Thu, 8 Mar 2012 23:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.968 X-Spam-Level: X-Spam-Status: No, score=-97.968 tagged_above=-999 required=5 tests=[AWL=0.655, 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 qO-FsghZEcQ0 for ; Thu, 8 Mar 2012 23:42:21 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A57EB21F8664 for ; Thu, 8 Mar 2012 23:41:47 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id D4C2CE6C6; Fri, 9 Mar 2012 15:41:39 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id C797FE6BF; Fri, 9 Mar 2012 15:41:39 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012030915413787-13190 ; Fri, 9 Mar 2012 15:41:37 +0800 Date: Fri, 9 Mar 2012 15:41:32 +0800 From: zhangyunfei To: 'Xiajinwei' , ppsp References: X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012030915413217800633@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-09 15:41:37, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-09 15:41:39, Serialize complete at 2012-03-09 15:41:39 Content-Type: multipart/alternative; boundary="----=_001_NextPart251337061825_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18762.005 X-TM-AS-Result: No--34.944-7.0-31-10 X-imss-scan-details: No--34.944-7.0-31-10;No--34.944-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] comments on latency in tracker protocol 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, 09 Mar 2012 07:42:22 -0000 This is a multi-part message in MIME format. ------=_001_NextPart251337061825_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SSByZXZpZXdlZCB0aGUgZHJhZnQgYW5kIHJhaXNlZCB0aGUgY29tbWVudHMgaW4gdGhlIGNhbGwu IEkgd291bGQgc2F5IGJhc2ljYWxseSBJIGFncmVlIHdpdGggSmlhbndlaSdzIG9waW5pb24gb24g dGhlIGdlbmVyYWwgaW1wcmVzc2lvbiBvZiB0aGUgZHJhZnQgLg0KUmVnYXJkaW5nIHRoZSBwcm9w b3NhbCBvZiBtZXJnaW5nIHRoZSBtZXNzYWdlcywgbGlrZSBDT05ORUNUIGFuZCBKT0lOLCBzZXZl cmFsIGZhY3RvcnMgc2hvdWxkIGJlIGNvbnNpZGVyZWQgZmlyc3Q6DQoxKUFyZSB0aGVzZSBuZWNl c3NhcmlseSBpbmRlcGVuZGVudCBhY3Rpb25zIG9yIGNhbiBtZXJnZWQgaW50byBvbmUgYWN0aW9u IGZyb20gdGhlIHVzZXJzJyBwZXJzcGVjdGl2ZT8gT2J2aW91c2x5IHBlZXJzIGNhbiBDT05ORUNU IGEgc3lzdGVtIHdpdGhvdXQgSk9JTiBhY3Rpb24sIGkuZS4sIFRvbSBvcGVuZWQgdGhlIFBQTGl2 ZSBzb2Z0d2FyZSB3aXRob3V0IGNsaWNraW5nIG9uIEFOWSBwcm9ncmFtcy4NCjIpIFRoZSBlZmZl Y3Qgb2YgdGhlIG1lcmdlcjogIEFzIGEgc3RhbmRhcmQgcHJvdG9jb2wsIHdlIG5lZWQgdG8gYmFs YW5jZSBiZXR3ZWVuIHBlcmZvcm1hbmNlIGFuZCBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3Rpbmcg cHJvdG9jb2xzLiBXZSBhcmUgbm90IGZhY2luZyBhIG5ldyBwcm9ibGVtIGV2ZW4gd2l0aG91dCBw cm9wcmlldGFyeSBzb2x1dGlvbnMuIEluc3RlYWQgd2UgYXJlIGZhY2luZyBhIHByb2JsZW0gd2l0 aCBtYW55IGV4aXN0aW5nIHNvbHV0aW9ucy4gV2UgbmVlZCB0byBjb25zaWRlciBob3cgdG8gbWFr ZSBpdCBjb21wYXRpYmxlIHdpdGggdGhlbSB3aGlsZSBhdCB0aGUgc2FtZSB0aW1lIGtlZXBpbmcg aXQgZWZmaWNpZW50IGVub3VnaC4gV2UgY2Fubm90IGZvY3VzIG9uIG9uZSBzaWRlIGF0IHRoZSBy aXNrIG9mIG5lZ2xlY3RpbmcgdGhlIG9uZS4gSSB0aGluayB0aGlzIGlzIHRoZSBiYXNlbGluZSBw cmluY2lwbGUgaW4gdGhlIFBQU1AgcHJvdG9jb2wgZGVzaWduLg0KICAgU28gYmFjayB0byB0aGUg bGF0ZW5jeSBwcm9ibGVtLCBvZiBjb3Vyc2Ugd2UgbmVlZCB0byBjb25zaWRlciB0aGUgZWZmaWNp ZW5jeSBpc3N1ZS4gQ29udmluY2luZyBmaWd1cmVzIGZyb20gcmVmZXJlbmNlcyBtYXkgYmUgaGVs cGZ1bCB0byBtYWtlIHBlb3BsZSBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUgdmFsdWUgb2YgdGhlIG1l cmdlciBvciB2aWNlIHZlcnNhLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoN CkZyb206IFhpYWppbndlaQ0KRGF0ZTogMjAxMi0wMy0wOCAxNjozMg0KVG86IHBwc3BAaWV0Zi5v cmcNClN1YmplY3Q6IFtwcHNwXSBjb21tZW50cyBvbiBsYXRlbmN5IGluIHRyYWNrZXIgcHJvdG9j b2wNCkhpIGFsbCwNCiANCkxldKGvcyBwdXNoIHRoaXMgd29yayBmb3J3YXJkLg0KIA0KQWNjb3Jk aW5nIHRvIHRoZSBkaXNjdXNzaW9uIGluIHRoZSBjb25mZXJlbmNlIGNhbGwsIElNSE8gdGhpcyAw NyB2ZXJzaW9uIGhhcyBzaWduaWZpY2FudCBlbmhhbmNlbWVudCBvbiBxdWFsaXR5LCBhbmQgaXRz IHN0cnVjdHVyZSBpcyBtdWNoIGNsZWFyZXIgY29tcGFyZWQgdG8gbGFzdCB2ZXJzaW9uLiBGb3Ig dGhlIGxhdGVuY3kgY29uY2VybiByYWlzZWQgaW4gdGhlIGNhbGwsIEkgdGhpbmsgbGF0ZW5jeSBp bmRlZWQgaXMgYW4gaW1wb3J0YW50IGVsZW1lbnQgd2hpY2ggaW1wYWN0cyB0aGUgdXNlciBleHBl cmllbmNlLiBBY3R1YWxseSwgdXNlciB1c3VhbGx5IGNhbqGvdCB0b2xlcmF0ZSBtdWNoIGxhdGVu Y3kgZHVyaW5nIG11bHRpbWVkaWEgcGxheWJhY2ssIGJ1dCBiZSBhIGxpdHRsZSBwYXRpZW50IG9u IHRoZSBiZWdpbm5pbmcgb2YgbXVsdGltZWRpYSBwbGF5YmFjay4gVGhlIGJlZ2lubmluZyBsYXRl bmN5IGlzIG1haW5seSBpbmR1Y2VkIGJ5IGEgc2V0IG9mIGNvbXBvbmVudHMsIHN1Y2ggYXMgbXVs dGljYXN0IGpvaW5pbmcsIGRhdGEgdHJhbnNmZXJyaW5nLCBidWZmZXJpbmcsIGRlY29kaW5nIGFu ZCBkZW11bHRpcGxleGluZy4gVGhlIEluZm9ybWF0aW9uIGFjcXVpc2l0aW9uIGxhdGVuY3kgKHRo ZSB0aW1lIGl0IHRha2VzIHBlZXIgdG8gYWNxdWlyZSB0aGUgaW5mb3JtYXRpb24gZnJvbSB0cmFj a2VyKSBzaG91bGQgYmUgYWxzbyBpbiB0aGUgc2NvcGUgb2YgYmVnaW5uaW5nIGxhdGVuY3kuIExl dKGvcyBjb25zaWRlciBWb0lQIHVzZSBjYXNlLCBTSVAgcHJvY2VkdXJlIGlzIGFsc28gbmVjZXNz YXJ5IGJlZm9yZSB0aGUgVm9JUCBkYXRhIHRyYW5zZmVycmluZy4NCiANCkhvcGUgdGhpcyBleHBs YW5hdGlvbiBpcyB1c2VmdWwuDQogDQogDQpUaGFuayB5b3UNCiANCkppbndlaQ== ------=_001_NextPart251337061825_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
I reviewed the draft and raised the comments in the call. I would say= =20 basically I agree with Jianwei's opinion on the general impression of= the=20 draft .
Regarding the proposal of merging the messages, like CONNECT and JOIN= ,=20 several factors should be considered first:
1)Are these necessarily independent actions or can merged into o= ne=20 action from the users' perspective? Obviously peers can CONNECT a system w= ithout=20 JOIN action, i.e., Tom opened the PPLive software without clicking on ANY=20 programs.
2) The effect of the merger:  As a standard protocol, we need to= =20 balance between performance and compatibility with existing protocols. We = are=20 not facing a new problem even without proprietary solutions. Instead we ar= e=20 facing a problem with many existing solutions. We need to consider&nb= sp;how=20 to make it compatible with them while at the same time keeping i= t=20 efficient enough. We cannot focus on one side at the risk of neglecti= ng the=20 one. I think this is the baseline principle in the PPSP protocol design.
   So back to the latency problem, of course we need to con= sider=20 the efficiency issue. Convincing figures from references may be helpful to= make=20 people better understand the value of the merger or vice versa.
 
BR
Yunfei
 
zhangyunfei
 
From: Xiajinwei
Date: 2012-03-08 16:32
To: ppsp@ietf.org
Subject: [ppsp] comments on latency in tracker=20 protocol

Hi all,

 

Let=A1=AFs push this work=20 forward.

 

According to the discussion in the= =20 conference call, IMHO this 07 version has significant enhancement on quali= ty,=20 and its structure is much clearer compared to last version. For the latenc= y=20 concern raised in the call, I think latency indeed is an important element= which=20 impacts the user experience. Actually, user usually can=A1=AFt tolerate mu= ch latency=20 during multimedia playback, but be a little patient on the beginning of=20 multimedia playback. The beginning latency is mainly induced by a set of=20 components, such as multicast joining, data transferring, buffering, decod= ing=20 and demultiplexing. The Information acquisition latency (the time it takes= peer=20 to acquire the information from tracker) should be also in the scope of=20 beginning latency. Let=A1=AFs consider VoIP use case, SIP procedure is als= o necessary=20 before the VoIP data transferring.

 

Hope this explanation is=20 useful.

 

 

Thank you

 

Jinwei

------=_001_NextPart251337061825_=------ From zhangyunfei@chinamobile.com Thu Mar 8 23:57:22 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 C63A621F85E0 for ; Thu, 8 Mar 2012 23:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.949 X-Spam-Level: X-Spam-Status: No, score=-98.949 tagged_above=-999 required=5 tests=[AWL=1.568, BAYES_20=-0.74, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xannSBrfCa4 for ; Thu, 8 Mar 2012 23:57:21 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7C82D21F85D0 for ; Thu, 8 Mar 2012 23:57:21 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 7AF95E6B5 for ; Fri, 9 Mar 2012 15:57:18 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 6F44BE6B0 for ; Fri, 9 Mar 2012 15:57:18 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012030915571713-13739 ; Fri, 9 Mar 2012 15:57:17 +0800 Date: Fri, 9 Mar 2012 15:57:11 +0800 From: zhangyunfei To: ppsp References: <201203080945408662583@chinamobile.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012030915571141687755@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-09 15:57:17, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-09 15:57:18, Serialize complete at 2012-03-09 15:57:18 Content-Type: multipart/alternative; boundary="----=_001_NextPart773051071450_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18762.005 X-TM-AS-Result: No--27.871-7.0-31-10 X-imss-scan-details: No--27.871-7.0-31-10;No--27.871-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Prolonging the WebEx meeting discussion 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, 09 Mar 2012 07:57:23 -0000 This is a multi-part message in MIME format. ------=_001_NextPart773051071450_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" V2UgaGFkIGFsdG9nZXRoZXIgMTIgcGVvcGxlIGF0dGVuZGluZyB0aGUgV2ViRXggY2FsbCBvbiBX ZWQuIFRoZSBtYWluIGNvbW1lbnRzIGluY2x1ZGU6DQoxKSBUcmFja2VyIHByb3RvY29sIGlzc3Vl OiBXaGV0aGVyIG9yIG5vdCBtZXJnaW5nIHRoZSBtZXNzYWdlIG9mIEpPSU4gYW5kIENPTk5FQ1Qu IFNlZSBtb3JlIGRldGFpbHMgb24gdGhlIHByZXZpb3VzIGVtYWlsIGZyb20gSmlhbndlaS4gDQoy KSBQZWVyIHByb3RvY29sOiBJJ3ZlIHBvc3RlZCBteSBjb21tZW50cyBvbiB0aGUgcHJvdG9jb2wg ZHJhZnQgaW4gdGhlIGVhcmxpZXIgZW1haWwuIFBsZWFzZSBjaGVjayB0aGF0IGZvciB0aGUgZGV0 YWlsLg0KMykgU3VydmV5OiBBZGRpbmcgc29tZSBwYXJ0cyBjbG9zZWx5IGNvbm5lY3RlZCB0byB0 aGUgZGlzY3Vzc2lvbiBmb2N1cyBvbiB0aGUgdHJhY2tlciBhbmQgcGVlciBwcm90b2NvbCwgc2F5 LCB0aGUgbWVzc2FnZSBpbiB0cmFja2VyICh3aGV0aGVyIGN1cnJlbnQgcHJhY3RpY2VzIGhhdmUg dGhlIG1lcmdlciBhcyB3ZWxsLCBvciBob3cgYWJvdXQgdGhlaXIgY29uc2lkZXJhdGlvbnMgb24g dGhpcywgQ2h1bmtJRCBnZW5lcmF0aW9uIG1lYW5zLCBjb250ZW50IGludGVncml0eSBjaGVjayBt ZWFucywgZXRjKS4NCjQpIEEgZ2VuZXJhbCBxdWVzdGlvbjogQXMgSSBtZW50aW9uZWQgaW4gbXkg bGFzdCBlbWFpbCwgaG93IHRvIGJhbGFuY2UgYmV0d2VlbiBwZXJmb3JtYW5jZSBhbmQgY29tcGF0 aWJpbGl0eSB3aXRoIGV4aXN0aW5nIHByb3RvY29scyAgaW4gb3VyIHByb3RvY29sIGRlc2lnbi4g V2hhdCBzaG91bGQgd2UgcHV0IGluIHRoZSBmaXJzdCBwbGFjZT8gU2hvdWxkIHdlIGNvbnNpZGVy IGhvdyB0aGUgZWFzaWx5IGFuZCBzbW9vdGhseSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGNhbiB0 dXJuIGludG8gc3RhbmRhcmQgcHJvdG9jb2xzLCBlc3AuIGluIHRoZSBmdXR1cmUncyAgY29udGVu dCBjZW50cmljIG5ldHdvcmsgd2hlcmUgZXhpc3Rpbmcgc3lzdGVtcyBuZWVkIHRvIGNvbnNpZGVy IGhvdyBpdCBjby13b3JrcyB3aXRoIG90aGVyIHN5c3RlbXMvbmV0d29yayBkZXZpY2VzPw0KDQpX aXNoIHRvIGNvbnRpbnVlIG91ciBkaXNjdXNzaW9uIGluIHRoZSBtYWlsaW5nIGxpc3QuDQoNCkJS DQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogemhhbmd5dW5mZWkNCkRhdGU6 IDIwMTItMDMtMDggMDk6NDUNClRvOiBwcHNwDQpTdWJqZWN0OiBXZWJFeCByZWNvcmRpbmcgIlBQ U1AtMjAxMjAzMDcgMTAwNi0yIg0KSGkgYWxsLA0KICAgVGhlIGZvbGxvd2luZyBsaW5rIGlzIHRo ZSB3ZWJleCByZWNvcmRpbmcgZm9yIHllc3RlcmRheSdzIG1lZXRpbmcgZm9yIHlvdXIgcmVmZXJl bmNlLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoNCkZyb206IENpbmR5IE1v cmdhbg0KRGF0ZTogMjAxMi0wMy0wOCAwMDozNw0KVG86IHpoYW5neXVuZmVpDQpTdWJqZWN0OiBJ bnZpdGF0aW9uIHRvIHZpZXcgV2ViRXggcmVjb3JkaW5nICJQUFNQLTIwMTIwMzA3IDEwMDYtMiIN Ckkgd2FudCB0byBzaGFyZSB0aGUgZm9sbG93aW5nIFdlYkV4IHJlY29yZGluZyB3aXRoIHlvdS4g Q2xpY2sgdGhlIGxpbmsgYmVsb3cgdG8gcGxheSBpdDogDQoNCmh0dHBzOi8vaWV0Zi53ZWJleC5j b20vaWV0Zi9sZHIucGhwP0FUPXBiJlNQPU1DJnJJRD02MTM3NDg3JnJLZXk9ZWM0Y2RjMDBkNzAw OTAyNyANCg0KUFBTUC0yMDEyMDMwNyAxMDA2LTIgDQpNYXJjaCA3LCAyMDEyLCAzOjQ3IGFtIFNh biBGcmFuY2lzY28gVGltZSANCjEgaG91ciAzNCBtaW5zIA0KDQoNCg0KSWYgeW91IG5lZWQgYXNz aXN0YW5jZSwgeW91IGNhbiBjb250YWN0IG1lIGF0IGNtb3JnYW5AYW1zbC5jb20uIA0KDQpodHRw Oi8vd3d3LndlYmV4LmNvbSA= ------=_001_NextPart773051071450_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" =EF=BB=BF
We had altogether 12 people attending the WebEx call on Wed. The main= =20 comments include:
1) Tracker protocol issue: Whether or not merging the message of= JOIN=20 and CONNECT. See more details on the previous email from Jianwei. 
2) Peer protocol: I've posted my comments on the protocol draft in th= e=20 earlier email. Please check that for the detail.
3) Survey: Adding some parts closely connected to the discussion= focus=20 on the tracker and peer protocol, say, the message in tracker (w= hether=20 current practices have the merger as well, or how about their consideratio= ns on=20 this, ChunkID generation means, content integrity check means, etc).<= /DIV>
4) A general question: As I mentioned in my last email, how to balanc= e=20 between performance and compatibility with existing protocols  in our= =20 protocol design. What should we put in the first place? Should we con= sider=20 how the easily and smoothly the existing protocols can turn into stan= dard=20 protocols, esp. in the future's  content centric network where existi= ng=20 systems need to consider how it co-works with other systems/network=20 devices?
 
Wish to continue our discussion in the mailing list.
 
BR
Yunfei
 
zhangyunfei
 
From: zhangyunfei
Date: 2012-03-08 09:45
To: ppsp
Subject: WebEx recording "PPSP-20120307=20 1006-2"
Hi all,
   The following link is the webex recording for yesterday'= s=20 meeting for your reference.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-03-08 00:37
To: zhangyunfei
Subject: Invitation to view WebEx recording "PPSP-2012030= 7=20 1006-2"
I want to share the=20 following WebEx recording with you. Click the link below to play it:
<= BR>https://ietf.webex.com/ietf/ldr.php?AT=3Dpb&SP=3DMC&am= p;rID=3D6137487&rKey=3Dec4cdc00d7009027=20

PPSP-20120307 1006-2
March 7, 2012, 3:47 am San Francisco Time=
1=20 hour 34 mins



If you need assistance, you can contact me at= cmorgan@amsl.com.

http://www.webex.com=20
------=_001_NextPart773051071450_=------ From a.bakker@vu.nl Fri Mar 9 06:49:13 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D221F8575 for ; Fri, 9 Mar 2012 06:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.818 X-Spam-Level: X-Spam-Status: No, score=0.818 tagged_above=-999 required=5 tests=[AWL=-1.137, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_74=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 aGmj2V4VXKSI for ; Fri, 9 Mar 2012 06:49:13 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id D985921F8523 for ; Fri, 9 Mar 2012 06:49:09 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 9 Mar 2012 15:49:14 +0100 Received: from [192.168.0.106] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 9 Mar 2012 15:49:07 +0100 Message-ID: <4F5A1863.2070000@cs.vu.nl> Date: Fri, 9 Mar 2012 15:49:07 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] comments on latency in 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: Fri, 09 Mar 2012 14:49:13 -0000 On 08/03/2012 09:32, Xiajinwei wrote: > The Information acquisition latency (the > time it takes peer to acquire the information from tracker) should be > also in the scope of beginning latency. Let’s consider VoIP use case, > SIP procedure is also necessary before the VoIP data transferring. > Hi my objection is with the time it takes to obtain a list of peers from the tracker. Currently this requires the following interaction: HTTPS handshake CONNECT OK JOIN swarm OK + peers So the CONNECT adds an extra roundtrip delay to the process. I'd rather have some multiplexing: HTTPS handshake CONNECT+JOIN OK + peer As remarked by Yunfei, you may also want to leave open the option of not using HTTPS in benign environments, the HTTPS handshake is also expensive (2 round trips + crypto). I will post a more complete review later. CU, Arno From a.bakker@vu.nl Fri Mar 9 07:34:35 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F225021F863E for ; Fri, 9 Mar 2012 07:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.335 X-Spam-Level: X-Spam-Status: No, score=-0.335 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkHwwLaMycSD for ; Fri, 9 Mar 2012 07:34:34 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.19]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0B21F8624 for ; Fri, 9 Mar 2012 07:34:33 -0800 (PST) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.19) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 9 Mar 2012 16:34:28 +0100 Received: from [192.168.0.106] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 9 Mar 2012 16:34:32 +0100 Message-ID: <4F5A2308.8000309@cs.vu.nl> Date: Fri, 9 Mar 2012 16:34:32 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <2012030718362805471827@chinamobile.com> In-Reply-To: <2012030718362805471827@chinamobile.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Comments on peer 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: Fri, 09 Mar 2012 15:34:35 -0000 Hi all On 07/03/2012 11:36, zhangyunfei wrote: > Here is my personal comments on peer protocol for today's discussion: > 1)bin numbering: How to apply in existing p2p streaming systems? All of > them( to the best of my knowledge) use a same level( instead of > hierarchical) number to denote the chunkID (and scope); For systems that use a linear byte address space for assets, these can be directly mapped to bins, as the lowest bin layer just represents that linear address space. Conversely, any bin directly translates to an interval in that linear address space, so conversion is easy. > 2) Merkle hash tree: The way is good for checking content integrity. > However is it using too much effort to prevent malicious attacks?( It's > different from file downloading case, where the user can detect > receiving the wrong file only after it downloads all chunks or using the > merkle hash tree detection. But for the "click and play right now" > streaming, the user can discern the attack much earlier, right? I'm not quite sure I understand the issue, but yes, in a benign environment you could turn content-integrity checking off. However, imagine a speech by president Obama being broadcast via PPSPP and hackers replacing it with other content. > 3)PEX message reuse in tracker protocol: Should be discussed in tracker > protocol protocol or separate proposal; IMHO, they are discussed in the right place as the PEX_* messages are for decentralized tracking and are between peers. > 4) Signaling and data coupling: Obviously there are argument on this > point. Should give more evidence on the advantages; With coupling, the system requires just one socket per peer. With a single socket, you also need to run NAT/firewall traversal and authentication procedures only once. Furthermore, it makes the implementation simpler. For example, the content-integrity information can be transmitted with the chunk. What would be the advantages of decoupling? And where would we decouple data transmission to? There is rough consensus in the working group that HTTP is not a suitable protocol for peer-to-peer. That leaves TCP and RTP. For TCP, we would have to invent our own transfer protocol that supports symmetric retrieval, so then why not do it in one peer protocol together with signalling? For RTP, it would be cleaner to add P2P signalling, etc. as a profile of RTP, as currently described in Section 6.3 of the WG item. Whether the bundling with RTP makes sense is still an open issue (http://trac.tools.ietf.org/wg/ppsp/trac/ticket/24) that we need to discuss. > 5) Requirement: Should be merged in PS draft? > I imagine that any text on meeting the requirements will be removed from the WG item once we agree that they have been met, right? Have a nice weekend, Arno From riccardo.bernardini@uniud.it Fri Mar 9 09:28:18 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 B708A21F8682 for ; Fri, 9 Mar 2012 09:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_31=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 00qH1I6sF+rK for ; Fri, 9 Mar 2012 09:28:18 -0800 (PST) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id CD2D921F867F for ; Fri, 9 Mar 2012 09:28:17 -0800 (PST) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id 2EF91B72424 for ; Fri, 9 Mar 2012 18:28:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at talitha2.cc.uniud.it Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id YQExR5ssy03Z for ; Fri, 9 Mar 2012 18:28:15 +0100 (CET) Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 3B34AB0035 for ; Fri, 9 Mar 2012 18:28:14 +0100 (CET) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Fri, 09 Mar 2012 18:28:14 +0100 Message-ID: <20120309182814.18036pnbobmt5ub2@webmail.uniud.it> Date: Fri, 09 Mar 2012 18:28:14 +0100 From: Riccardo Bernardini To: ppsp@ietf.org References: <2012030915413217800633@chinamobile.com> In-Reply-To: <2012030915413217800633@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) Subject: Re: [ppsp] comments on latency in 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: Fri, 09 Mar 2012 17:28:18 -0000 zhangyunfei ha scritto: > I reviewed the draft and raised the comments in the call. I would > say basically I agree with Jianwei's opinion on the general > impression of the draft . > Regarding the proposal of merging the messages, like CONNECT and > JOIN, several factors should be considered first: > 1)Are these necessarily independent actions or can merged into one > action from the users' perspective? Obviously peers can CONNECT a > system without JOIN action, i.e., Tom opened the PPLive software > without clicking on ANY programs. > 2) The effect of the merger: As a standard protocol, we need to > balance between performance and compatibility with existing > protocols. We are not facing a new problem even without proprietary > solutions. Instead we are facing a problem with many existing > solutions. We need to consider how to make it compatible with them > while at the same time keeping it efficient enough. We cannot focus > on one side at the risk of neglecting the one. I think this is the > baseline principle in the PPSP protocol design. > So back to the latency problem, of course we need to consider the > efficiency issue. Convincing figures from references may be helpful > to make people better understand the value of the merger or vice > versa. > Just a few considerations about the latency issue. First, do we have some measurement about the actual delays? (Maybe it is what you call "convincing figures"?) Should I guess, I expect that the overall "connection setup + CONNECT + JOIN" will take an amount of time comparable to the time needed to access a web page via HTTPS with some images included (CONNECT would be the equivalent of the first GET and JOIN the equivalent of a GET done to get an image). However, this is just a guess of mine and having some figure it could be easier to decide if JOIN and CONNECT need to be merged. From another point of view, I like the flexibility of having them separated. As said above, maybe in some application one would like to do a CONNECT without JOIN. Also, is it possible that one JOINs more than one swarm at time? For example, if I want to implement something similar to the "exchange" button found on many remotes (that brings you back to the previous channel), it could make sense to remain JOINed to a swarm even when I "change channel." If the "multiple JOIN" scenario is reasonable, we should have at least a "CONNECT+JOIN" and a "simple JOIN". Let me throw in a proposal. Maybe a possible solution could be having more than one command in the same message. This could be achieved with just a little change of the proposed XML syntax: just make the command name an attribute of Request and let Request include all the request parameters. For example, instead of CONNECT 6543210 12345 .... use 6543210 12345 .... A similar change would apply also to the "Response" node. In this way one can include more than one request in the same transaction and the server will process them in order, as they were received in separate transactions. This will save one round-trip request-response time. The only possible drawback could be that with this change we lose compatibility with some other protocol (that I am not aware of). Riccardo > BR > Yunfei > > > > > zhangyunfei > > From: Xiajinwei > Date: 2012-03-08 16:32 > To: ppsp@ietf.org > Subject: [ppsp] comments on latency in tracker protocol > Hi all, > > Let?s push this work forward. > > According to the discussion in the conference call, IMHO this 07 > version has significant enhancement on quality, and its structure is > much clearer compared to last version. For the latency concern > raised in the call, I think latency indeed is an important element > which impacts the user experience. Actually, user usually can?t > tolerate much latency during multimedia playback, but be a little > patient on the beginning of multimedia playback. The beginning > latency is mainly induced by a set of components, such as multicast > joining, data transferring, buffering, decoding and demultiplexing. > The Information acquisition latency (the time it takes peer to > acquire the information from tracker) should be also in the scope of > beginning latency. Let?s consider VoIP use case, SIP procedure is > also necessary before the VoIP data transferring. > > Hope this explanation is useful. > > > Thank you > > Jinwei -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine From rui.cruz@ieee-pt.org Fri Mar 9 09:42:03 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7736821F86D5 for ; Fri, 9 Mar 2012 09:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZNYksRRMual for ; Fri, 9 Mar 2012 09:42:02 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA9D921E804D for ; Fri, 9 Mar 2012 09:42:01 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1305377wgb.13 for ; Fri, 09 Mar 2012 09:41:57 -0800 (PST) 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=vK4kJ98wESwnbsUpQXqbN1OeJLaYjqCdSa/iWNZ4SGs=; b=lrryqU8xcM5pXDtL8ToR5SZVHInh+yJG8L8c0fNNv1U/X2dn+6WU3yaf2ihBuawemY hF1ctAtYoMV7ggi5T0qqFEzPfgjO+l+sswSmJnj0m6sclcsgOWci1CL5XMAUXzBcmu+o huiaUKTqmyR/GyteEHXlXE4fI7Mo/siqCRe2ftFHsnTgK8MQF+BmcP+fyDdf6bndlJGo bAObEWeMdF4EgX7sWXRz6rVyOYd4axm6w8Pv4l9PnNclO+c+Yy2Ze/t97K0VJAXRDOx/ +eku4hM8lM9O75om+GNEwzXjh10Upfz6wLU+8QAiB8pSr1LgATQ8c8Y1IaBkH2kcHb91 8BBw== Received: by 10.180.93.4 with SMTP id cq4mr6704286wib.21.1331314917451; Fri, 09 Mar 2012 09:41:57 -0800 (PST) Received: from airia.casa (89-180-38-197.net.novis.pt. [89.180.38.197]) by mx.google.com with ESMTPS id bg3sm6719289wib.10.2012.03.09.09.41.54 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 09:41:56 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_90437626-EC73-4880-92AB-4F27765B5548" From: Rui Cruz In-Reply-To: <4F5A1863.2070000@cs.vu.nl> Date: Fri, 9 Mar 2012 17:41:54 +0000 Message-Id: References: <4F5A1863.2070000@cs.vu.nl> To: ppsp@ietf.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkHMca9yK49Kt5QeGNxmuxctGeT0R/kpsIE7LnHYlGR6Yrv2kwCAmOkMqou53zpaqww7xq2 Cc: Rui Cruz Subject: Re: [ppsp] comments on latency in 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: Fri, 09 Mar 2012 17:42:03 -0000 --Apple-Mail=_90437626-EC73-4880-92AB-4F27765B5548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Arno is right, as well as Jinwei and Yunfei in all viewpoints. And we have a pretty solution for it. It was not considered to be included in the revised draft, although = discussed, as its applicability needs to be very carefully addressed. Considering the following very common scenarios: a: User signs in to the Provider portal through his WebTV interface (a = STB or a Tablet or a PC), browses the available "shows" and selects one = to watch. Later, pauses and selects another show (while the first one = can be kept being shared in that swarm, although not being displayed, or = being displayed as a PIP window). b: User has been watching several shows but has to leave and power off = the device. But user wants to return and then resume all he was engaged = in, and continue watching the show he paused, even from the same moment = in the show timeline. For scenario a and b, in a first time, the Peer would just CONNECT to = the system while the User browses until deciding what to JOIN. = Subsequent JOINs (scenario a, later actions) get the Peer in different = swarms that the User can manage (DISCONNECT or re-JOIN). For scenario b, when resuming, the Peer CONNECTs but with specific JOIN = actions included in the same Request message. This involves a slight change in the CONNECT message semantics only, and = so, IMHO, addresses the latency concern in a very elegant way. = Independently of using more or less secure handshake methods. However, = the use of this special method should be carefully considered, not just = in terms of security. An example of the modified CONNECT message is the following, where the = Peer selects the desired swarms and specifies the corresponding PeerMode = (SEED or LEECH). The optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum: CONNECT 656164657221 1111 2222 5 12345 656164657221 SEED Comparing with the previous CONNECT message: CONNECT 656164657221 12345 656164657221 SEED 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 09/03/2012, at 14:49, Arno Bakker wrote: > On 08/03/2012 09:32, Xiajinwei wrote: >> The Information acquisition latency (the >> time it takes peer to acquire the information from tracker) should be >> also in the scope of beginning latency. Let=92s consider VoIP use = case, >> SIP procedure is also necessary before the VoIP data transferring. >>=20 >=20 > Hi >=20 > my objection is with the time it takes to obtain a list of peers from = the tracker. Currently this requires the following interaction: >=20 > HTTPS handshake > CONNECT > OK > JOIN swarm > OK + peers >=20 > So the CONNECT adds an extra roundtrip delay to the process. I'd = rather > have some multiplexing: >=20 > HTTPS handshake > CONNECT+JOIN > OK + peer >=20 > As remarked by Yunfei, you may also want to leave open the option of = not using HTTPS in benign environments, the HTTPS handshake is also = expensive (2 round trips + crypto). >=20 > I will post a more complete review later. >=20 > CU, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_90437626-EC73-4880-92AB-4F27765B5548 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

b: User has been watching several = shows but has to leave and power off the device. But user wants to = return and then resume all he was engaged in, and continue watching the = show he paused, even from the same moment in the show = timeline.

For scenario a and b, in a first = time, the Peer would just CONNECT to the system while the User browses = until deciding what to JOIN. Subsequent JOINs (scenario a, later = actions) get the Peer in different swarms that the User can manage = (DISCONNECT or re-JOIN).

For scenario b, = when resuming, the Peer CONNECTs but with specific JOIN actions included = in the same Request message.
This involves a slight change in = the CONNECT message semantics only, and so, IMHO, addresses the latency = concern in a very elegant way. Independently of using more or less = secure handshake methods. However, the use of this special method should = be carefully considered, not just in terms of = security.

An example of the modified CONNECT = message is the following, where the Peer selects the desired swarms and = specifies the corresponding PeerMode (SEED or LEECH).
The = optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum:

<PPSPTrackerProtocol = version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <!-- in CONNECT, SwarmID element can take = optional @action to JOIN a swarm. Additionally inform about the = corresponding @peerMode. -->
    <SwarmID = action=3D"JOIN" = peerMode=3D"SEED">1111</SwarmID>
    <SwarmID = action=3D"JOIN" = peerMode=3D"LEECH">2222</SwarmID>
    <!-- in CONNECT, with optional JOIN @action, = @abilityNAT values "STUN"|"TURN"|"PROXY" -->
    <PeerNum = abilityNAT=3D"STUN">5</PeerNum>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <PeerMode>SEED</PeerMode>
            <!-- @addrType = values "ipv4|ipv6", @type values "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress = addrType=3D"ipv4" = ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress = addrType=3D"ipv6" = ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Comparing with the previous CONNECT = message:

<PPSPTrackerProtocol version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <PeerMode>SEED</PeerMode>
            <!-- @addrType values "ipv4|ipv6", @type values = "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress addrType=3D"ipv4" ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress addrType=3D"ipv6" ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Regards,

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

On 09/03/2012, at 14:49, Arno Bakker wrote:

On = 08/03/2012 09:32, Xiajinwei wrote:
The = Information acquisition latency (the
time it takes peer to acquire the information from = tracker) should be
also in the = scope of beginning latency. Let=92s consider VoIP use = case,
SIP procedure is also = necessary before the VoIP data transferring.


Hi

my objection is with the = time it takes to obtain a list of peers from the tracker. Currently this = requires the following interaction:

HTTPS = handshake
CONNECT
OK
JOIN swarm
OK + peers

So the = CONNECT adds an extra roundtrip delay to the process. I'd rather
have = some multiplexing:

HTTPS handshake
CONNECT+JOIN
OK + = peer

As remarked by Yunfei, you may also want to leave open the = option of not using HTTPS in benign environments, the HTTPS handshake is = also expensive (2 round trips + crypto).

I will post a more = complete review later.

CU,
=    Arno
_______________________________________________<= br>ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

= --Apple-Mail=_90437626-EC73-4880-92AB-4F27765B5548-- From rui.cruz@ieee-pt.org Fri Mar 9 09:51: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 F35FA21F85F2 for ; Fri, 9 Mar 2012 09:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.148 X-Spam-Level: X-Spam-Status: No, score=-103.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nwIXP1i3kUm for ; Fri, 9 Mar 2012 09:51:19 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66B1021F85FC for ; Fri, 9 Mar 2012 09:51:18 -0800 (PST) Received: by werb10 with SMTP id b10so1581601wer.31 for ; Fri, 09 Mar 2012 09:51:16 -0800 (PST) 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=JUIPSR4kGdhRA0JTYxq4eXv8RcR/J+ayZ96L+/LLGjs=; b=Ld8OqFLHfbmCeeNAZajcKmZRWXK7/ADu36XXwNHEleo1tMU3KM/WCdIBoRk+s+NeM6 ng0K5s2g8U1X1xdeAwCSiQquc1ppxbfyjvZhy9+tUouRKvtAnQZVeONEFHDF5igiS8kZ 56BmynhAd/IHemCG8HOQHpNRdu49X9cAG67qXJUQPlF4tySIKT2DRpVDOA043IFDAbhJ px+5UJA2C4FErmdpUSWdln+9IkLNckKrt4yvqOp7EfmWio0Zuh+z4aX+tqPmCdgBfRim Fg/KhlrhhW4nVk0LeiQKg6BQejgZG78Xz40tdUfcieLnvUKmBd8p29ChaqMCHUfa/ljT TxvA== Received: by 10.216.137.100 with SMTP id x78mr2019742wei.72.1331315476736; Fri, 09 Mar 2012 09:51:16 -0800 (PST) Received: from airia.casa (89-180-38-197.net.novis.pt. [89.180.38.197]) by mx.google.com with ESMTPS id be4sm12872048wib.8.2012.03.09.09.51.14 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 09:51:15 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D0ADE15-6B4A-4105-9285-0A7BD2FB7B1F" From: Rui Cruz In-Reply-To: <4F5A1863.2070000@cs.vu.nl> Date: Fri, 9 Mar 2012 17:51:13 +0000 Message-Id: References: <4F5A1863.2070000@cs.vu.nl> To: ppsp@ietf.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlCHemgIkPAMhxmQXjRjvRy4sOQ7A3l4s22+luKUpY4qjJ0OWOf4imxfdUIdR77/oO3U3YN Cc: Rui Cruz Subject: Re: [ppsp] comments on latency in tracker protocol - corrected 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, 09 Mar 2012 17:51:20 -0000 --Apple-Mail=_7D0ADE15-6B4A-4105-9285-0A7BD2FB7B1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [CORRECTION: there was a wrong PeerMode line in the PeerInfo group of = previous example] Hi, Arno is right, as well as Jinwei and Yunfei in all viewpoints. And we have a pretty solution for it. It was not considered to be included in the revised draft, although = discussed, as its applicability needs to be very carefully addressed. Considering the following very common scenarios: a: User signs in to the Provider portal through his WebTV interface (a = STB or a Tablet or a PC), browses the available "shows" and selects one = to watch. Later, pauses and selects another show (while the first one = can be kept being shared in that swarm, although not being displayed, or = being displayed as a PIP window). b: User has been watching several shows but has to leave and power off = the device. But user wants to return and then resume all he was engaged = in, and continue watching the show he paused, even from the same moment = in the show timeline. For scenario a and b, in a first time, the Peer would just CONNECT to = the system while the User browses until deciding what to JOIN. = Subsequent JOINs (scenario a, later actions) get the Peer in different = swarms that the User can manage (DISCONNECT or re-JOIN). For scenario b, when resuming, the Peer CONNECTs but with specific JOIN = actions included in the same Request message. This involves a slight change in the CONNECT message semantics only, and = so, IMHO, addresses the latency concern in a very elegant way. = Independently of using more or less secure handshake methods. However, = the use of this special method should be carefully considered, not just = in terms of security. An example of the modified CONNECT message is the following, where the = Peer selects the desired swarms and specifies the corresponding PeerMode = (SEED or LEECH). The optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum: CONNECT 656164657221 1111 2222 5 12345 656164657221 Comparing with the previous CONNECT message: CONNECT 656164657221 12345 656164657221 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 09/03/2012, at 14:49, Arno Bakker wrote: > On 08/03/2012 09:32, Xiajinwei wrote: >> The Information acquisition latency (the >> time it takes peer to acquire the information from tracker) should be >> also in the scope of beginning latency. Let=92s consider VoIP use = case, >> SIP procedure is also necessary before the VoIP data transferring. >>=20 >=20 > Hi >=20 > my objection is with the time it takes to obtain a list of peers from = the tracker. Currently this requires the following interaction: >=20 > HTTPS handshake > CONNECT > OK > JOIN swarm > OK + peers >=20 > So the CONNECT adds an extra roundtrip delay to the process. I'd = rather > have some multiplexing: >=20 > HTTPS handshake > CONNECT+JOIN > OK + peer >=20 > As remarked by Yunfei, you may also want to leave open the option of = not using HTTPS in benign environments, the HTTPS handshake is also = expensive (2 round trips + crypto). >=20 > I will post a more complete review later. >=20 > CU, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_7D0ADE15-6B4A-4105-9285-0A7BD2FB7B1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

b: User has been watching several = shows but has to leave and power off the device. But user wants to = return and then resume all he was engaged in, and continue watching the = show he paused, even from the same moment in the show = timeline.

For scenario a and b, in a first = time, the Peer would just CONNECT to the system while the User browses = until deciding what to JOIN. Subsequent JOINs (scenario a, later = actions) get the Peer in different swarms that the User can manage = (DISCONNECT or re-JOIN).

For scenario b, = when resuming, the Peer CONNECTs but with specific JOIN actions included = in the same Request message.
This involves a slight change in = the CONNECT message semantics only, and so, IMHO, addresses the latency = concern in a very elegant way. Independently of using more or less = secure handshake methods. However, the use of this special method should = be carefully considered, not just in terms of = security.

An example of the modified CONNECT = message is the following, where the Peer selects the desired swarms and = specifies the corresponding PeerMode (SEED or LEECH).
The = optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum:

<PPSPTrackerProtocol = version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <!-- in CONNECT, SwarmID element can take = optional @action to JOIN a swarm. Additionally inform about the = corresponding @peerMode. -->
    <SwarmID = action=3D"JOIN" = peerMode=3D"SEED">1111</SwarmID>
    <SwarmID = action=3D"JOIN" = peerMode=3D"LEECH">2222</SwarmID>
    <!-- in CONNECT, with optional JOIN @action, = @abilityNAT values "STUN"|"TURN"|"PROXY" -->
    <PeerNum = abilityNAT=3D"STUN">5</PeerNum>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <!-- @addrType = values "ipv4|ipv6", @type values "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress = addrType=3D"ipv4" = ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress = addrType=3D"ipv6" = ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Comparing with the previous CONNECT = message:

<PPSPTrackerProtocol version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <!-- @addrType values "ipv4|ipv6", @type values = "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress addrType=3D"ipv4" ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress addrType=3D"ipv6" ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Regards,

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

On 09/03/2012, at 14:49, Arno Bakker wrote:

On = 08/03/2012 09:32, Xiajinwei wrote:
The = Information acquisition latency (the
time it takes peer to acquire the information from = tracker) should be
also in the = scope of beginning latency. Let=92s consider VoIP use = case,
SIP procedure is also = necessary before the VoIP data transferring.


Hi

my objection is with the = time it takes to obtain a list of peers from the tracker. Currently this = requires the following interaction:

HTTPS = handshake
CONNECT
OK
JOIN swarm
OK + peers

So the = CONNECT adds an extra roundtrip delay to the process. I'd rather
have = some multiplexing:

HTTPS handshake
CONNECT+JOIN
OK + = peer

As remarked by Yunfei, you may also want to leave open the = option of not using HTTPS in benign environments, the HTTPS handshake is = also expensive (2 round trips + crypto).

I will post a more = complete review later.

CU,
=    Arno
_______________________________________________<= br>ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/m= ailman/listinfo/ppsp

= --Apple-Mail=_7D0ADE15-6B4A-4105-9285-0A7BD2FB7B1F-- From rui.cruz@ieee-pt.org Fri Mar 9 11:13: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 531BA21E8088 for ; Fri, 9 Mar 2012 11:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.098 X-Spam-Level: X-Spam-Status: No, score=-103.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRA7IpR-hogK for ; Fri, 9 Mar 2012 11:13:53 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93D6D21E807B for ; Fri, 9 Mar 2012 11:13:52 -0800 (PST) Received: by werb10 with SMTP id b10so1639110wer.31 for ; Fri, 09 Mar 2012 11:13:51 -0800 (PST) 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=NsYFmnXxL+zeQYAKXS0ORkSvbDzJjS1W0F5+ITc5DwM=; b=ABpRRHuXHiAyMZGz8KFQo1hMJyHGuZgMg5p+9j5Pl7D0o9G2lsjtDBZbYXbY+tqz3N +6+1NfFAa2G8XAitXvc7DIxSLZ6gwdcownjJxiy2JQAT0wueIyKuBr8yJc5dSEpHPh/d Dan8R6XdEAAfNtXQUgO/60GYTs6p1aPuGQzmi06IiSE0uT84vaBSK+716XrSt5qWCQiY 8Qhd+lL2S5i1mJfCft+UQg7nHlXZmBfz+joa7Ux2r4AOrLBX9xyVIeu51R7odRp6eq7N o0+uOLsZMFUZGkMCUYjVGTis4XlkuqB7HVD6UYdYprm97Ny8SIlzcOj7t7CSqL3DzVpx O7lQ== Received: by 10.180.88.164 with SMTP id bh4mr7357776wib.22.1331320431674; Fri, 09 Mar 2012 11:13:51 -0800 (PST) Received: from airia.casa (89-180-38-197.net.novis.pt. [89.180.38.197]) by mx.google.com with ESMTPS id df3sm7398466wib.1.2012.03.09.11.13.48 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 11:13:50 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_DBE2FB1B-B8E4-44ED-9EBD-848B7C0A539A" From: Rui Cruz In-Reply-To: Date: Fri, 9 Mar 2012 19:13:48 +0000 Message-Id: <1A0E0D00-E5A9-4D28-98B9-D025AE201B4A@ieee.org> References: <4F5A1863.2070000@cs.vu.nl> To: ppsp@ietf.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl5WRhv+qKy6LYSwhA2hSQcgOBlReSTUxlO0i/HBmKkPxr7nq+Jd9FY2kkHvr7vfqhX4lBQ Cc: Rui Cruz Subject: Re: [ppsp] comments on latency in tracker protocol - corrected 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, 09 Mar 2012 19:13:54 -0000 --Apple-Mail=_DBE2FB1B-B8E4-44ED-9EBD-848B7C0A539A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The message sequence for the example I illustrated would be: CONNECT with implicit JOINs: +--------+ +--------+ +--------+ +---------+ +--------+ | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | +--------+ +--------+ +--------+ +---------+ +--------+ | | | | | |--Page request----------------->| | | |<--------------Page with links--| | | |--Select stream (MPD Request)-->| | | |<-----------------------OK+MPD--| | | |--MPD---------->|--CONNECT (join x, y)-------->| | |<-----------OK--|<----------OK+Peerlist(x, y)--| | | | | | |-- Get(Chunk) ->|<---------- (Peer protocol) ------------->| |<---- Chunk ----|<-------------------------------- Chunk --| : : : : : 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 09/03/2012, at 17:51, Rui Cruz wrote: > [CORRECTION: there was a wrong PeerMode line in the PeerInfo group of = previous example] >=20 > Hi, >=20 > Arno is right, as well as Jinwei and Yunfei in all viewpoints. >=20 > And we have a pretty solution for it. > It was not considered to be included in the revised draft, although = discussed, as its applicability needs to be very carefully addressed. >=20 > Considering the following very common scenarios: >=20 > a: User signs in to the Provider portal through his WebTV interface (a = STB or a Tablet or a PC), browses the available "shows" and selects one = to watch. Later, pauses and selects another show (while the first one = can be kept being shared in that swarm, although not being displayed, or = being displayed as a PIP window). >=20 > b: User has been watching several shows but has to leave and power off = the device. But user wants to return and then resume all he was engaged = in, and continue watching the show he paused, even from the same moment = in the show timeline. >=20 > For scenario a and b, in a first time, the Peer would just CONNECT to = the system while the User browses until deciding what to JOIN. = Subsequent JOINs (scenario a, later actions) get the Peer in different = swarms that the User can manage (DISCONNECT or re-JOIN). >=20 > For scenario b, when resuming, the Peer CONNECTs but with specific = JOIN actions included in the same Request message. > This involves a slight change in the CONNECT message semantics only, = and so, IMHO, addresses the latency concern in a very elegant way. = Independently of using more or less secure handshake methods. However, = the use of this special method should be carefully considered, not just = in terms of security. >=20 > An example of the modified CONNECT message is the following, where the = Peer selects the desired swarms and specifies the corresponding PeerMode = (SEED or LEECH). > The optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum: >=20 > > CONNECT > 656164657221 > > 1111 > 2222 > > 5 > 12345 > > > 656164657221 > > connection=3D"ADSL" asn=3D"64496"/> > connection=3D"3G" asn=3D"65536"/> > > > >=20 > Comparing with the previous CONNECT message: >=20 > > CONNECT > 656164657221 > 12345 > > > 656164657221 > > connection=3D"ADSL" asn=3D"64496"/> > connection=3D"3G" asn=3D"65536"/> > > > >=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 09/03/2012, at 14:49, Arno Bakker wrote: >=20 >> On 08/03/2012 09:32, Xiajinwei wrote: >>> The Information acquisition latency (the >>> time it takes peer to acquire the information from tracker) should = be >>> also in the scope of beginning latency. Let=92s consider VoIP use = case, >>> SIP procedure is also necessary before the VoIP data transferring. >>>=20 >>=20 >> Hi >>=20 >> my objection is with the time it takes to obtain a list of peers from = the tracker. Currently this requires the following interaction: >>=20 >> HTTPS handshake >> CONNECT >> OK >> JOIN swarm >> OK + peers >>=20 >> So the CONNECT adds an extra roundtrip delay to the process. I'd = rather >> have some multiplexing: >>=20 >> HTTPS handshake >> CONNECT+JOIN >> OK + peer >>=20 >> As remarked by Yunfei, you may also want to leave open the option of = not using HTTPS in benign environments, the HTTPS handshake is also = expensive (2 round trips + crypto). >>=20 >> I will post a more complete review later. >>=20 >> CU, >> Arno >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >=20 --Apple-Mail=_DBE2FB1B-B8E4-44ED-9EBD-848B7C0A539A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = message sequence for the example I illustrated would = be:

CONNECT with implicit = JOINs:

   +--------+ =      +--------+     +--------+   =  +---------+  +--------+
   | Player | =      | Peer 1 |     | Portal |    | = Tracker |  | Peer 2 |
   +--------+ =      +--------+     +--------+   =  +---------+  +--------+
      | =                |     =           |           =    |           = |
      |--Page = request----------------->|             =  |           |
      = |<--------------Page with links--|           =    |           = |
      |--Select stream (MPD = Request)-->|              |   =         |
      = |<-----------------------OK+MPD--|           =    |           = |
      |--MPD---------->|--CONNECT (join x, = y)-------->|           = |
      ||<----------OK+Peerlist(x, = y)--|   =         |
      | =                |     =                     =      |           = |
      |-- Get(Chunk) = ->|<---------- (Peer protocol) = ------------->|
      |<---- Chunk = ----|<-------------------------------- Chunk = --|
      :         =        :             =   :              :     =       :

Regards,

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

On 09/03/2012, at 17:51, Rui Cruz wrote:

[CORRECTION: there was a = wrong PeerMode line in the PeerInfo group of previous = example]

Hi,

Arno is right, as = well as Jinwei and Yunfei in all = viewpoints.

And we have a pretty solution for = it.
It was not considered to be included in the revised draft, = although discussed, as its applicability needs to be very carefully = addressed.

Considering the following very = common scenarios:

a: User signs in to the = Provider portal through his WebTV interface (a STB or a Tablet or a PC), = browses the available "shows" and selects one to watch. Later, pauses = and selects another show (while the first one can be kept being shared = in that swarm, although not being displayed, or being displayed as a PIP = window).

b: User has been watching several = shows but has to leave and power off the device. But user wants to = return and then resume all he was engaged in, and continue watching the = show he paused, even from the same moment in the show = timeline.

For scenario a and b, in a first = time, the Peer would just CONNECT to the system while the User browses = until deciding what to JOIN. Subsequent JOINs (scenario a, later = actions) get the Peer in different swarms that the User can manage = (DISCONNECT or re-JOIN).

For scenario b, = when resuming, the Peer CONNECTs but with specific JOIN actions included = in the same Request message.
This involves a slight change in = the CONNECT message semantics only, and so, IMHO, addresses the latency = concern in a very elegant way. Independently of using more or less = secure handshake methods. However, the use of this special method should = be carefully considered, not just in terms of = security.

An example of the modified CONNECT = message is the following, where the Peer selects the desired swarms and = specifies the corresponding PeerMode (SEED or LEECH).
The = optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum:

<PPSPTrackerProtocol = version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <!-- in CONNECT, SwarmID element can take = optional @action to JOIN a swarm. Additionally inform about the = corresponding @peerMode. -->
    <SwarmID = action=3D"JOIN" = peerMode=3D"SEED">1111</SwarmID>
    <SwarmID = action=3D"JOIN" = peerMode=3D"LEECH">2222</SwarmID>
    <!-- in CONNECT, with optional JOIN @action, = @abilityNAT values "STUN"|"TURN"|"PROXY" -->
    <PeerNum = abilityNAT=3D"STUN">5</PeerNum>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <!-- @addrType = values "ipv4|ipv6", @type values "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress = addrType=3D"ipv4" = ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress = addrType=3D"ipv6" = ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Comparing with the previous CONNECT = message:

<PPSPTrackerProtocol version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <!-- @addrType values "ipv4|ipv6", @type values = "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress addrType=3D"ipv4" ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress addrType=3D"ipv6" ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Regards,

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

On 09/03/2012, at 14:49, Arno Bakker wrote:

On = 08/03/2012 09:32, Xiajinwei wrote:
The = Information acquisition latency (the
time it takes peer to acquire the information from = tracker) should be
also in the = scope of beginning latency. Let=92s consider VoIP use = case,
SIP procedure is also = necessary before the VoIP data transferring.


Hi

my objection is with the = time it takes to obtain a list of peers from the tracker. Currently this = requires the following interaction:

HTTPS = handshake
CONNECT
OK
JOIN swarm
OK + peers

So the = CONNECT adds an extra roundtrip delay to the process. I'd rather
have = some multiplexing:

HTTPS handshake
CONNECT+JOIN
OK + = peer

As remarked by Yunfei, you may also want to leave open the = option of not using HTTPS in benign environments, the HTTPS handshake is = also expensive (2 round trips + crypto).

I will post a more = complete review later.

CU,
=    Arno
_______________________________________________<= br>ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/m= ailman/listinfo/ppsp


= --Apple-Mail=_DBE2FB1B-B8E4-44ED-9EBD-848B7C0A539A-- From rui.cruz@ieee-pt.org Fri Mar 9 11:17: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 2867D21E807B for ; Fri, 9 Mar 2012 11:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.073 X-Spam-Level: X-Spam-Status: No, score=-103.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2I9E4K3QcHZ for ; Fri, 9 Mar 2012 11:17:33 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71DCB21E8080 for ; Fri, 9 Mar 2012 11:17:32 -0800 (PST) Received: by werb10 with SMTP id b10so1641482wer.31 for ; Fri, 09 Mar 2012 11:17:31 -0800 (PST) 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=tJb+jNCfAHLexIwa58vlc3j7qSPCFjqvFDXe+b49eBc=; b=VsMWQDnummR9kEk9JG8b5hO4wE/0HHzTM+Mz4c2FJ0/nazz6BLEo9By7gW6wPw/0xk 0jZe9maaGvnqWbz/HNq1pjVVVmfb1X8MPguBgP8+tKuSB1fBnOoQFR2oO8rRZBvIR7OK wAFCwIQj1lU/pW5l0nCYILyyiF/MxMz0nVq3Wusi9ElmVf7yYSQS5ecRE3EZJeXuJ+oi +M9AuNYNKD3wTSIhrext+NXtdBbv/cXDE0Uli8jMsXvAoIokfGpBkSeV0l/Gx3RonGhd 92bb1yxW6gp3+ktayrgmBq8mxNR0WJA/CSpnoIdTYH5iACtipJ/JHHUHc1k9Wc1bF+eG lT3g== Received: by 10.216.139.156 with SMTP id c28mr2102607wej.57.1331320651606; Fri, 09 Mar 2012 11:17:31 -0800 (PST) Received: from airia.casa (89-180-38-197.net.novis.pt. [89.180.38.197]) by mx.google.com with ESMTPS id j3sm14008458wiw.1.2012.03.09.11.17.29 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 11:17:30 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B71822C3-88AA-4D00-AA1D-840EA272F6F0" From: Rui Cruz In-Reply-To: Date: Fri, 9 Mar 2012 19:17:29 +0000 Message-Id: References: <4F5A1863.2070000@cs.vu.nl> To: ppsp@ietf.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnhJF8UrUqiAjLlvMYxYAI+Sg/9aFaqDembSQxFs70OOG/ZTMjoRukKBolvmYyICjMOktQH Cc: Rui Cruz Subject: Re: [ppsp] comments on latency in tracker protocol - corrected again 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, 09 Mar 2012 19:17:34 -0000 --Apple-Mail=_B71822C3-88AA-4D00-AA1D-840EA272F6F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 [CORRECTION: just the resuming action is valid in this case] The message sequence for the example I illustrated would be: CONNECT with implicit JOINs: +--------+ +--------+ +--------+ +---------+ +--------+ | Player | | Peer 1 | | Portal | | Tracker | | Peer 2 | +--------+ +--------+ +--------+ +---------+ +--------+ | | | | | |--Resume------->|--CONNECT (join x, y)-------->| | |<-----------OK--|<----------OK+Peerlist(x, y)--| | | | | | |-- Get(Chunk) ->|<---------- (Peer protocol) ------------->| |<---- Chunk ----|<-------------------------------- Chunk --| : : : : : 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 09/03/2012, at 17:51, Rui Cruz wrote: > [CORRECTION: there was a wrong PeerMode line in the PeerInfo group of = previous example] >=20 > Hi, >=20 > Arno is right, as well as Jinwei and Yunfei in all viewpoints. >=20 > And we have a pretty solution for it. > It was not considered to be included in the revised draft, although = discussed, as its applicability needs to be very carefully addressed. >=20 > Considering the following very common scenarios: >=20 > a: User signs in to the Provider portal through his WebTV interface (a = STB or a Tablet or a PC), browses the available "shows" and selects one = to watch. Later, pauses and selects another show (while the first one = can be kept being shared in that swarm, although not being displayed, or = being displayed as a PIP window). >=20 > b: User has been watching several shows but has to leave and power off = the device. But user wants to return and then resume all he was engaged = in, and continue watching the show he paused, even from the same moment = in the show timeline. >=20 > For scenario a and b, in a first time, the Peer would just CONNECT to = the system while the User browses until deciding what to JOIN. = Subsequent JOINs (scenario a, later actions) get the Peer in different = swarms that the User can manage (DISCONNECT or re-JOIN). >=20 > For scenario b, when resuming, the Peer CONNECTs but with specific = JOIN actions included in the same Request message. > This involves a slight change in the CONNECT message semantics only, = and so, IMHO, addresses the latency concern in a very elegant way. = Independently of using more or less secure handshake methods. However, = the use of this special method should be carefully considered, not just = in terms of security. >=20 > An example of the modified CONNECT message is the following, where the = Peer selects the desired swarms and specifies the corresponding PeerMode = (SEED or LEECH). > The optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum: >=20 > > CONNECT > 656164657221 > > 1111 > 2222 > > 5 > 12345 > > > 656164657221 > > connection=3D"ADSL" asn=3D"64496"/> > connection=3D"3G" asn=3D"65536"/> > > > >=20 > Comparing with the previous CONNECT message: >=20 > > CONNECT > 656164657221 > 12345 > > > 656164657221 > > connection=3D"ADSL" asn=3D"64496"/> > connection=3D"3G" asn=3D"65536"/> > > > >=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 09/03/2012, at 14:49, Arno Bakker wrote: >=20 >> On 08/03/2012 09:32, Xiajinwei wrote: >>> The Information acquisition latency (the >>> time it takes peer to acquire the information from tracker) should = be >>> also in the scope of beginning latency. Let=92s consider VoIP use = case, >>> SIP procedure is also necessary before the VoIP data transferring. >>>=20 >>=20 >> Hi >>=20 >> my objection is with the time it takes to obtain a list of peers from = the tracker. Currently this requires the following interaction: >>=20 >> HTTPS handshake >> CONNECT >> OK >> JOIN swarm >> OK + peers >>=20 >> So the CONNECT adds an extra roundtrip delay to the process. I'd = rather >> have some multiplexing: >>=20 >> HTTPS handshake >> CONNECT+JOIN >> OK + peer >>=20 >> As remarked by Yunfei, you may also want to leave open the option of = not using HTTPS in benign environments, the HTTPS handshake is also = expensive (2 round trips + crypto). >>=20 >> I will post a more complete review later. >>=20 >> CU, >> Arno >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >=20 --Apple-Mail=_B71822C3-88AA-4D00-AA1D-840EA272F6F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 CONNECT with implicit = JOINs:

   +--------+ =      +--------+     +--------+   =  +---------+  +--------+
   | Player | =      | Peer 1 |     | Portal |    | = Tracker |  | Peer 2 |
   +--------+ =      +--------+     +--------+   =  +---------+  +--------+
      | =                |     =           |           =    |           = |
      |--Resume------->|--CONNECT (join x, = y)-------->|           = |
      ||<----------OK+Peerlist(x, = y)--|   =         |
      | =                |     =                     =      |           = |
      |-- Get(Chunk) = ->|<---------- (Peer protocol) = ------------->|
      |<---- Chunk = ----|<-------------------------------- Chunk = --|
      :         =        :             =   :              :     =       :

Regards,

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

On 09/03/2012, at 17:51, Rui Cruz wrote:

[CORRECTION: there was a = wrong PeerMode line in the PeerInfo group of previous = example]

Hi,

Arno is right, as = well as Jinwei and Yunfei in all = viewpoints.

And we have a pretty solution for = it.
It was not considered to be included in the revised draft, = although discussed, as its applicability needs to be very carefully = addressed.

Considering the following very = common scenarios:

a: User signs in to the = Provider portal through his WebTV interface (a STB or a Tablet or a PC), = browses the available "shows" and selects one to watch. Later, pauses = and selects another show (while the first one can be kept being shared = in that swarm, although not being displayed, or being displayed as a PIP = window).

b: User has been watching several = shows but has to leave and power off the device. But user wants to = return and then resume all he was engaged in, and continue watching the = show he paused, even from the same moment in the show = timeline.

For scenario a and b, in a first = time, the Peer would just CONNECT to the system while the User browses = until deciding what to JOIN. Subsequent JOINs (scenario a, later = actions) get the Peer in different swarms that the User can manage = (DISCONNECT or re-JOIN).

For scenario b, = when resuming, the Peer CONNECTs but with specific JOIN actions included = in the same Request message.
This involves a slight change in = the CONNECT message semantics only, and so, IMHO, addresses the latency = concern in a very elegant way. Independently of using more or less = secure handshake methods. However, the use of this special method should = be carefully considered, not just in terms of = security.

An example of the modified CONNECT = message is the following, where the Peer selects the desired swarms and = specifies the corresponding PeerMode (SEED or LEECH).
The = optional element in the CONNECT message is the SwarmID and = respective attributes, as well as the conditionally mandatory (depending = on the presence of element SwarmID) element PeerNum:

<PPSPTrackerProtocol = version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <!-- in CONNECT, SwarmID element can take = optional @action to JOIN a swarm. Additionally inform about the = corresponding @peerMode. -->
    <SwarmID = action=3D"JOIN" = peerMode=3D"SEED">1111</SwarmID>
    <SwarmID = action=3D"JOIN" = peerMode=3D"LEECH">2222</SwarmID>
    <!-- in CONNECT, with optional JOIN @action, = @abilityNAT values "STUN"|"TURN"|"PROXY" -->
    <PeerNum = abilityNAT=3D"STUN">5</PeerNum>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <!-- @addrType = values "ipv4|ipv6", @type values "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress = addrType=3D"ipv4" = ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress = addrType=3D"ipv6" = ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Comparing with the previous CONNECT = message:

<PPSPTrackerProtocol version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
            <PeerID>656164657221</PeerID>
            <!-- @addrType values "ipv4|ipv6", @type values = "HOST"|"REFLEXIVE"|"PROXY" -->
            <PeerAddress addrType=3D"ipv4" ip=3D"198.51.100.1" = port=3D"80" priority=3D"1" type=3D"HOST"
          =       connection=3D"ADSL" asn=3D"64496"/>
            <PeerAddress addrType=3D"ipv6" ip=3D"2001:db8::1" = port=3D"80" priority=3D"2" type=3D"HOST"
          =       connection=3D"3G" asn=3D"65536"/>
        </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>

Regards,

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

On 09/03/2012, at 14:49, Arno Bakker wrote:

On = 08/03/2012 09:32, Xiajinwei wrote:
The = Information acquisition latency (the
time it takes peer to acquire the information from = tracker) should be
also in the = scope of beginning latency. Let=92s consider VoIP use = case,
SIP procedure is also = necessary before the VoIP data transferring.


Hi

my objection is with the = time it takes to obtain a list of peers from the tracker. Currently this = requires the following interaction:

HTTPS = handshake
CONNECT
OK
JOIN swarm
OK + peers

So the = CONNECT adds an extra roundtrip delay to the process. I'd rather
have = some multiplexing:

HTTPS handshake
CONNECT+JOIN
OK + = peer

As remarked by Yunfei, you may also want to leave open the = option of not using HTTPS in benign environments, the HTTPS handshake is = also expensive (2 round trips + crypto).

I will post a more = complete review later.

CU,
=    Arno
_______________________________________________<= br>ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/m= ailman/listinfo/ppsp


= --Apple-Mail=_B71822C3-88AA-4D00-AA1D-840EA272F6F0-- From a.bakker@vu.nl Mon Mar 12 00:52:03 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B83221F8604 for ; Mon, 12 Mar 2012 00:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGGmzLyxHtnC for ; Mon, 12 Mar 2012 00:52:02 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 58AE221F8603 for ; Mon, 12 Mar 2012 00:52:02 -0700 (PDT) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 12 Mar 2012 08:52:05 +0100 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.1.218.12; Mon, 12 Mar 2012 08:52:00 +0100 Message-ID: <4F5DAB23.3010802@cs.vu.nl> Date: Mon, 12 Mar 2012 08:52:03 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rui Cruz References: <4F5A1863.2070000@cs.vu.nl> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp@ietf.org Subject: Re: [ppsp] comments on latency in tracker protocol - corrected 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, 12 Mar 2012 07:52:03 -0000 Rui Cruz wrote: > the Peer CONNECTs but with specific JOIN > actions included in the same Request message. Hi This multiplexing of instructions is indeed what we need to reduce latency. CU, Arno From zhangyunfei@chinamobile.com Mon Mar 12 02:22: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 33AC321F86DD for ; Mon, 12 Mar 2012 02:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.781 X-Spam-Level: X-Spam-Status: No, score=-97.781 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=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 4ZdQaev2TsFn for ; Mon, 12 Mar 2012 02:22:08 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 346DF21F8738 for ; Mon, 12 Mar 2012 02:22:07 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 92876E450; Mon, 12 Mar 2012 17:22:04 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 820DEE44F; Mon, 12 Mar 2012 17:22:04 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012031217220229-18009 ; Mon, 12 Mar 2012 17:22:02 +0800 Date: Mon, 12 Mar 2012 17:22:01 +0800 From: zhangyunfei To: "Riccardo Bernardini" , ppsp References: <2012030915413217800633@chinamobile.com>, <20120309182814.18036pnbobmt5ub2@webmail.uniud.it> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012031217220137862029@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-12 17:22:02, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-12 17:22:04, Serialize complete at 2012-03-12 17:22:04 Content-Type: multipart/alternative; boundary="----=_001_NextPart712777535428_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18768.005 X-TM-AS-Result: No--33.691-7.0-31-10 X-imss-scan-details: No--33.691-7.0-31-10;No--33.691-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] comments on latency in tracker protocol 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, 12 Mar 2012 09:22:09 -0000 This is a multi-part message in MIME format. ------=_001_NextPart712777535428_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SSB0aGluayB0aGlzIGlzIGEgZmVhc2libGUgd2F5IHRvIGFkZHJlc3MgdGhlIHByb2JsZW0uIEkg ZG9uJ3Qgc2VlIGluY29tcGF0aWJpbGl0eSB3aXRoIHNvbWUgb3RoZXIgcHJvdG9jb2xzIHRpbGwg bm93Lg0KDQpCUg0KWXVuZmVpIA0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBSaWNjYXJk byBCZXJuYXJkaW5pDQpEYXRlOiAyMDEyLTAzLTEwIDAxOjI4DQpUbzogcHBzcA0KU3ViamVjdDog UmU6IFtwcHNwXSBjb21tZW50cyBvbiBsYXRlbmN5IGluIHRyYWNrZXIgcHJvdG9jb2wNCnpoYW5n eXVuZmVpIDx6aGFuZ3l1bmZlaUBjaGluYW1vYmlsZS5jb20+IGhhIHNjcml0dG86DQoNCj4gSSBy ZXZpZXdlZCB0aGUgZHJhZnQgYW5kIHJhaXNlZCB0aGUgY29tbWVudHMgaW4gdGhlIGNhbGwuIEkg d291bGQgIA0KPiBzYXkgYmFzaWNhbGx5IEkgYWdyZWUgd2l0aCBKaWFud2VpJ3Mgb3BpbmlvbiBv biB0aGUgZ2VuZXJhbCAgDQo+IGltcHJlc3Npb24gb2YgdGhlIGRyYWZ0IC4NCj4gUmVnYXJkaW5n IHRoZSBwcm9wb3NhbCBvZiBtZXJnaW5nIHRoZSBtZXNzYWdlcywgbGlrZSBDT05ORUNUIGFuZCAg DQo+IEpPSU4sIHNldmVyYWwgZmFjdG9ycyBzaG91bGQgYmUgY29uc2lkZXJlZCBmaXJzdDoNCj4g MSlBcmUgdGhlc2UgbmVjZXNzYXJpbHkgaW5kZXBlbmRlbnQgYWN0aW9ucyBvciBjYW4gbWVyZ2Vk IGludG8gb25lICANCj4gYWN0aW9uIGZyb20gdGhlIHVzZXJzJyBwZXJzcGVjdGl2ZT8gT2J2aW91 c2x5IHBlZXJzIGNhbiBDT05ORUNUIGEgIA0KPiBzeXN0ZW0gd2l0aG91dCBKT0lOIGFjdGlvbiwg aS5lLiwgVG9tIG9wZW5lZCB0aGUgUFBMaXZlIHNvZnR3YXJlICANCj4gd2l0aG91dCBjbGlja2lu ZyBvbiBBTlkgcHJvZ3JhbXMuDQo+IDIpIFRoZSBlZmZlY3Qgb2YgdGhlIG1lcmdlcjogIEFzIGEg c3RhbmRhcmQgcHJvdG9jb2wsIHdlIG5lZWQgdG8gIA0KPiBiYWxhbmNlIGJldHdlZW4gcGVyZm9y bWFuY2UgYW5kIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZyAgDQo+IHByb3RvY29scy4gV2Ug YXJlIG5vdCBmYWNpbmcgYSBuZXcgcHJvYmxlbSBldmVuIHdpdGhvdXQgcHJvcHJpZXRhcnkgIA0K PiBzb2x1dGlvbnMuIEluc3RlYWQgd2UgYXJlIGZhY2luZyBhIHByb2JsZW0gd2l0aCBtYW55IGV4 aXN0aW5nICANCj4gc29sdXRpb25zLiBXZSBuZWVkIHRvIGNvbnNpZGVyIGhvdyB0byBtYWtlIGl0 IGNvbXBhdGlibGUgd2l0aCB0aGVtICANCj4gd2hpbGUgYXQgdGhlIHNhbWUgdGltZSBrZWVwaW5n IGl0IGVmZmljaWVudCBlbm91Z2guIFdlIGNhbm5vdCBmb2N1cyAgDQo+IG9uIG9uZSBzaWRlIGF0 IHRoZSByaXNrIG9mIG5lZ2xlY3RpbmcgdGhlIG9uZS4gSSB0aGluayB0aGlzIGlzIHRoZSAgDQo+ IGJhc2VsaW5lIHByaW5jaXBsZSBpbiB0aGUgUFBTUCBwcm90b2NvbCBkZXNpZ24uDQo+ICAgIFNv IGJhY2sgdG8gdGhlIGxhdGVuY3kgcHJvYmxlbSwgb2YgY291cnNlIHdlIG5lZWQgdG8gY29uc2lk ZXIgdGhlICANCj4gZWZmaWNpZW5jeSBpc3N1ZS4gQ29udmluY2luZyBmaWd1cmVzIGZyb20gcmVm ZXJlbmNlcyBtYXkgYmUgaGVscGZ1bCAgDQo+IHRvIG1ha2UgcGVvcGxlIGJldHRlciB1bmRlcnN0 YW5kIHRoZSB2YWx1ZSBvZiB0aGUgbWVyZ2VyIG9yIHZpY2UgIA0KPiB2ZXJzYS4NCj4NCg0KSnVz dCBhIGZldyBjb25zaWRlcmF0aW9ucyBhYm91dCB0aGUgbGF0ZW5jeSBpc3N1ZS4gIEZpcnN0LCBk byB3ZSBoYXZlICANCnNvbWUgbWVhc3VyZW1lbnQgYWJvdXQgdGhlIGFjdHVhbCBkZWxheXM/IChN YXliZSBpdCBpcyB3aGF0IHlvdSBjYWxsICANCiJjb252aW5jaW5nIGZpZ3VyZXMiPykgICBTaG91 bGQgSSBndWVzcywgSSBleHBlY3QgdGhhdCB0aGUgb3ZlcmFsbCAgDQoiY29ubmVjdGlvbiBzZXR1 cCArIENPTk5FQ1QgKyBKT0lOIiB3aWxsIHRha2UgYW4gYW1vdW50IG9mIHRpbWUgIA0KY29tcGFy YWJsZSB0byB0aGUgdGltZSBuZWVkZWQgdG8gYWNjZXNzIGEgd2ViIHBhZ2UgdmlhIEhUVFBTIHdp dGggc29tZSAgDQppbWFnZXMgaW5jbHVkZWQgKENPTk5FQ1Qgd291bGQgYmUgdGhlIGVxdWl2YWxl bnQgb2YgdGhlIGZpcnN0IEdFVCBhbmQgIA0KSk9JTiB0aGUgZXF1aXZhbGVudCBvZiBhIEdFVCBk b25lIHRvIGdldCBhbiBpbWFnZSkuICBIb3dldmVyLCB0aGlzIGlzICANCmp1c3QgYSBndWVzcyBv ZiBtaW5lIGFuZCBoYXZpbmcgc29tZSBmaWd1cmUgaXQgY291bGQgYmUgZWFzaWVyIHRvICANCmRl Y2lkZSBpZiBKT0lOIGFuZCBDT05ORUNUIG5lZWQgdG8gYmUgbWVyZ2VkLg0KDQogRnJvbSBhbm90 aGVyIHBvaW50IG9mIHZpZXcsIEkgbGlrZSB0aGUgZmxleGliaWxpdHkgb2YgaGF2aW5nIHRoZW0g IA0Kc2VwYXJhdGVkLiAgQXMgc2FpZCBhYm92ZSwgbWF5YmUgaW4gc29tZSBhcHBsaWNhdGlvbiBv bmUgd291bGQgbGlrZSB0byAgDQpkbyBhIENPTk5FQ1Qgd2l0aG91dCBKT0lOLiAgIEFsc28sIGlz IGl0IHBvc3NpYmxlIHRoYXQgb25lIEpPSU5zIG1vcmUgIA0KdGhhbiBvbmUgc3dhcm0gYXQgdGlt ZT8gRm9yIGV4YW1wbGUsIGlmIEkgd2FudCB0byBpbXBsZW1lbnQgc29tZXRoaW5nICANCnNpbWls YXIgdG8gdGhlICJleGNoYW5nZSIgYnV0dG9uIGZvdW5kIG9uIG1hbnkgcmVtb3RlcyAodGhhdCBi cmluZ3MgIA0KeW91IGJhY2sgdG8gdGhlIHByZXZpb3VzIGNoYW5uZWwpLCBpdCBjb3VsZCBtYWtl IHNlbnNlIHRvIHJlbWFpbiAgDQpKT0lOZWQgdG8gYSBzd2FybSBldmVuIHdoZW4gSSAiY2hhbmdl IGNoYW5uZWwuIiAgSWYgdGhlICJtdWx0aXBsZSAgDQpKT0lOIiBzY2VuYXJpbyBpcyByZWFzb25h YmxlLCB3ZSBzaG91bGQgaGF2ZSBhdCBsZWFzdCBhICJDT05ORUNUK0pPSU4iICANCmFuZCBhICJz aW1wbGUgSk9JTiIuDQoNCkxldCBtZSB0aHJvdyBpbiBhIHByb3Bvc2FsLiBNYXliZSBhIHBvc3Np YmxlIHNvbHV0aW9uIGNvdWxkIGJlIGhhdmluZyAgDQptb3JlIHRoYW4gb25lIGNvbW1hbmQgaW4g dGhlIHNhbWUgbWVzc2FnZS4gIFRoaXMgY291bGQgYmUgYWNoaWV2ZWQgIA0Kd2l0aCBqdXN0IGEg bGl0dGxlIGNoYW5nZSBvZiB0aGUgcHJvcG9zZWQgWE1MIHN5bnRheDoganVzdCBtYWtlIHRoZSAg DQpjb21tYW5kIG5hbWUgYW4gYXR0cmlidXRlIG9mIFJlcXVlc3QgYW5kIGxldCBSZXF1ZXN0IGlu Y2x1ZGUgYWxsIHRoZSAgDQpyZXF1ZXN0IHBhcmFtZXRlcnMuICBGb3IgZXhhbXBsZSwgaW5zdGVh ZCBvZg0KDQo8UFBTUFRyYWNrZXJQcm90b2NvbCB2ZXJzaW9uPSIxLjAiPg0KICAgIDxSZXF1ZXN0 PkNPTk5FQ1Q8L1JlcXVlc3Q+DQogICAgPFBlZXJJRD42NTQzMjEwPC9QZWVySUQ+DQogICAgPFRy YW5zYWN0aW9uSUQ+MTIzNDU8L1RyYW5zYWN0aW9uSUQ+DQogICAgLi4uLg0KPC9QUFNQVHJhY2tl clByb3RvY29sPg0KDQp1c2UNCg0KPFBQU1BUcmFja2VyUHJvdG9jb2wgdmVyc2lvbj0iMS4wIj4N CiAgICA8UmVxdWVzdCBhY3Rpb249IkNPTk5FQ1QiPg0KICAgICAgPFBlZXJJRD42NTQzMjEwPC9Q ZWVySUQ+DQogICAgICA8VHJhbnNhY3Rpb25JRD4xMjM0NTwvVHJhbnNhY3Rpb25JRD4NCiAgICAg IC4uLi4NCiAgICA8L1JlcXVlc3Q+DQo8L1BQU1BUcmFja2VyUHJvdG9jb2w+DQoNCkEgc2ltaWxh ciBjaGFuZ2Ugd291bGQgYXBwbHkgYWxzbyB0byB0aGUgIlJlc3BvbnNlIiBub2RlLiAgSW4gdGhp cyB3YXkgIA0Kb25lIGNhbiBpbmNsdWRlIG1vcmUgdGhhbiBvbmUgcmVxdWVzdCBpbiB0aGUgc2Ft ZSB0cmFuc2FjdGlvbiBhbmQgdGhlICANCnNlcnZlciB3aWxsIHByb2Nlc3MgdGhlbSBpbiBvcmRl ciwgYXMgdGhleSB3ZXJlIHJlY2VpdmVkIGluIHNlcGFyYXRlICANCnRyYW5zYWN0aW9ucy4gICBU aGlzIHdpbGwgc2F2ZSBvbmUgcm91bmQtdHJpcCByZXF1ZXN0LXJlc3BvbnNlIHRpbWUuICAgDQpU aGUgb25seSBwb3NzaWJsZSBkcmF3YmFjayBjb3VsZCBiZSB0aGF0IHdpdGggdGhpcyBjaGFuZ2Ug d2UgbG9zZSAgDQpjb21wYXRpYmlsaXR5IHdpdGggc29tZSBvdGhlciBwcm90b2NvbCAodGhhdCBJ IGFtIG5vdCBhd2FyZSBvZikuDQoNClJpY2NhcmRvDQoNCj4gQlINCj4gWXVuZmVpDQo+DQo+DQo+ DQo+DQo+IHpoYW5neXVuZmVpDQo+DQo+IEZyb206IFhpYWppbndlaQ0KPiBEYXRlOiAyMDEyLTAz LTA4IDE2OjMyDQo+IFRvOiBwcHNwQGlldGYub3JnDQo+IFN1YmplY3Q6IFtwcHNwXSBjb21tZW50 cyBvbiBsYXRlbmN5IGluIHRyYWNrZXIgcHJvdG9jb2wNCj4gSGkgYWxsLA0KPg0KPiBMZXQ/cyBw dXNoIHRoaXMgd29yayBmb3J3YXJkLg0KPg0KPiBBY2NvcmRpbmcgdG8gdGhlIGRpc2N1c3Npb24g aW4gdGhlIGNvbmZlcmVuY2UgY2FsbCwgSU1ITyB0aGlzIDA3ICANCj4gdmVyc2lvbiBoYXMgc2ln bmlmaWNhbnQgZW5oYW5jZW1lbnQgb24gcXVhbGl0eSwgYW5kIGl0cyBzdHJ1Y3R1cmUgaXMgIA0K PiBtdWNoIGNsZWFyZXIgY29tcGFyZWQgdG8gbGFzdCB2ZXJzaW9uLiBGb3IgdGhlIGxhdGVuY3kg Y29uY2VybiAgDQo+IHJhaXNlZCBpbiB0aGUgY2FsbCwgSSB0aGluayBsYXRlbmN5IGluZGVlZCBp cyBhbiBpbXBvcnRhbnQgZWxlbWVudCAgDQo+IHdoaWNoIGltcGFjdHMgdGhlIHVzZXIgZXhwZXJp ZW5jZS4gQWN0dWFsbHksIHVzZXIgdXN1YWxseSBjYW4/dCAgDQo+IHRvbGVyYXRlIG11Y2ggbGF0 ZW5jeSBkdXJpbmcgbXVsdGltZWRpYSBwbGF5YmFjaywgYnV0IGJlIGEgbGl0dGxlICANCj4gcGF0 aWVudCBvbiB0aGUgYmVnaW5uaW5nIG9mIG11bHRpbWVkaWEgcGxheWJhY2suIFRoZSBiZWdpbm5p bmcgIA0KPiBsYXRlbmN5IGlzIG1haW5seSBpbmR1Y2VkIGJ5IGEgc2V0IG9mIGNvbXBvbmVudHMs IHN1Y2ggYXMgbXVsdGljYXN0ICANCj4gam9pbmluZywgZGF0YSB0cmFuc2ZlcnJpbmcsIGJ1ZmZl cmluZywgZGVjb2RpbmcgYW5kIGRlbXVsdGlwbGV4aW5nLiAgDQo+IFRoZSBJbmZvcm1hdGlvbiBh Y3F1aXNpdGlvbiBsYXRlbmN5ICh0aGUgdGltZSBpdCB0YWtlcyBwZWVyIHRvICANCj4gYWNxdWly ZSB0aGUgaW5mb3JtYXRpb24gZnJvbSB0cmFja2VyKSBzaG91bGQgYmUgYWxzbyBpbiB0aGUgc2Nv cGUgb2YgIA0KPiBiZWdpbm5pbmcgbGF0ZW5jeS4gTGV0P3MgY29uc2lkZXIgVm9JUCB1c2UgY2Fz ZSwgU0lQIHByb2NlZHVyZSBpcyAgDQo+IGFsc28gbmVjZXNzYXJ5IGJlZm9yZSB0aGUgVm9JUCBk YXRhIHRyYW5zZmVycmluZy4NCj4NCj4gSG9wZSB0aGlzIGV4cGxhbmF0aW9uIGlzIHVzZWZ1bC4N Cj4NCj4NCj4gVGhhbmsgeW91DQo+DQo+IEppbndlaQ0KDQoNCg0KLS0gDQpSaWNjYXJkbyBCZXJu YXJkaW5pDQpESUVHTSAtLSBVbml2ZXJzaXR5IG9mIFVkaW5lDQp2aWEgZGVsbGUgU2NpZW56ZSAy MDgNCjMzMTAwIFVkaW5lDQpUZWw6ICszOS0wNDMyLTU1LTgyNzENCkZheDogKzM5LTA0MzItNTUt ODI1MQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTRU1FTCAoU0Vydml6aW8gZGkgTWVzc2FnaW5nIEVMZXR0 cm9uaWNvKSAtIEFJTkYsIFVuaXZlcnNpdGEnIGRpIFVkaW5lDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNw QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart712777535428_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
I think this is a feasible way to address the problem. I don't see=20 incompatibility with some other protocols till now.
 
BR
Yunfei 
 
zhangyunfei
 
Date: 2012-03-10 01:28
To: ppsp
Subject: Re: [ppsp] comments on latency in tracker=20 protocol
zhangyunfei <zhangyunfei@chinamobile.com> ha scr= itto:
 
> I reviewed the draft and raised&nb= sp;the comments in the call. I would &n= bsp;
> say basically I agree with Jianwei= 's opinion on the general  
> impression of the draft .
> Regarding the proposal of merging = the messages, like CONNECT and  
> JOIN, several factors should be co= nsidered first:
> 1)Are these necessarily independent act= ions or can merged into one  
> action from the users' perspective?&nbs= p;Obviously peers can CONNECT a  
> system without JOIN action, i.e., = Tom opened the PPLive software  
> without clicking on ANY programs.
> 2) The effect of the merger: =  As a standard protocol, we need to&nbs= p; 
> balance between performance and compati= bility with existing  
> protocols. We are not facing a&nbs= p;new problem even without proprietary  
> solutions. Instead we are facing a=  problem with many existing  
> solutions. We need to consider how=  to make it compatible with them  =
> while at the same time keeping&nbs= p;it efficient enough. We cannot focus  = ;
> on one side at the risk of&nb= sp;neglecting the one. I think this is = the  
> baseline principle in the PPSP pro= tocol design.
>    So back to the latenc= y problem, of course we need to conside= r the  
> efficiency issue. Convincing figures fr= om references may be helpful  
> to make people better understand t= he value of the merger or vice  
> versa.
>
 
Just a few considerations about the lat= ency issue.  First, do we have  
some measurement about the actual delays?&nb= sp;(Maybe it is what you call  
"convincing figures"?)   Should I guess= , I expect that the overall  
"connection setup + CONNECT + JOIN" wil= l take an amount of time  
comparable to the time needed to access=  a web page via HTTPS with some &n= bsp;
images included (CONNECT would be the e= quivalent of the first GET and  
JOIN the equivalent of a GET done = to get an image).  However, this is&nbs= p; 
just a guess of mine and having so= me figure it could be easier to  <= /DIV>
decide if JOIN and CONNECT need to = ;be merged.
 
 From another point of view, I lik= e the flexibility of having them  
separated.  As said above, maybe in&nbs= p;some application one would like to  <= /DIV>
do a CONNECT without JOIN.   Also,=  is it possible that one JOINs more&nbs= p; 
than one swarm at time? For example,&nb= sp;if I want to implement something  
similar to the "exchange" button found = on many remotes (that brings  
you back to the previous channel), it&n= bsp;could make sense to remain  
JOINed to a swarm even when I "cha= nge channel."  If the "multiple  
JOIN" scenario is reasonable, we should = ;have at least a "CONNECT+JOIN"  
and a "simple JOIN".
 
Let me throw in a proposal. Maybe = a possible solution could be having  
more than one command in the same = message.  This could be achieved  
with just a little change of the p= roposed XML syntax: just make the  
command name an attribute of Request an= d let Request include all the  
request parameters.  For example, instead&nb= sp;of
 
<PPSPTrackerProtocol version=3D"1.0">
    <Request>CONNECT</Request>
    <PeerID>6543210</PeerID>
    <TransactionID>12345</TransactionID&= gt;
    ....
</PPSPTrackerProtocol>
 
use
 
<PPSPTrackerProtocol version=3D"1.0">
    <Request action=3D"CONNECT">
      <PeerID>6543210</PeerID&= gt;
      <TransactionID>12345</Tr= ansactionID>
      ....
    </Request>
</PPSPTrackerProtocol>
 
A similar change would apply also to&nb= sp;the "Response" node.  In this way &n= bsp;
one can include more than one request&n= bsp;in the same transaction and the  
server will process them in order, as&n= bsp;they were received in separate  
transactions.   This will save one = ;round-trip request-response time.   
The only possible drawback could be tha= t with this change we lose  
compatibility with some other protocol (that=  I am not aware of).
 
Riccardo
 
> BR
> Yunfei
>
>
>
>
> zhangyunfei
>
> From: Xiajinwei
> Date: 2012-03-08 16:32
> To: ppsp@ietf.org
> Subject: [ppsp] comments on latency&nbs= p;in tracker protocol
> Hi all,
>
> Let?s push this work forward.
>
> According to the discussion in the=  conference call, IMHO this 07  
> version has significant enhancement on&= nbsp;quality, and its structure is  
> much clearer compared to last vers= ion. For the latency concern  
> raised in the call, I think l= atency indeed is an important element  =
> which impacts the user experience. = ;Actually, user usually can?t  
> tolerate much latency during multimedia=  playback, but be a little  
> patient on the beginning of multim= edia playback. The beginning  
> latency is mainly induced by a&nbs= p;set of components, such as multicast  = ;
> joining, data transferring, buffering, = decoding and demultiplexing.  
> The Information acquisition latency (th= e time it takes peer to  
> acquire the information from tracker)&n= bsp;should be also in the scope of &nbs= p;
> beginning latency. Let?s consider VoIP&= nbsp;use case, SIP procedure is  
> also necessary before the VoIP dat= a transferring.
>
> Hope this explanation is useful.
>
>
> Thank you
>
> Jinwei
 
 
 
-- 
Riccardo Bernardini
DIEGM -- University of Udine
via delle Scienze 208
33100 Udine
Tel: +39-0432-55-8271
Fax: +39-0432-55-8251
 
---------------------------------------------------------------------= -
SEMEL (SErvizio di Messaging ELettronico) -&= nbsp;AINF, Universita' di Udine
 
 
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart712777535428_=------ From zhangyunfei@chinamobile.com Mon Mar 12 02:25:57 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B228C21F86E1 for ; Mon, 12 Mar 2012 02:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.792 X-Spam-Level: X-Spam-Status: No, score=-97.792 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 aZXLmK3LJ04Q for ; Mon, 12 Mar 2012 02:25:56 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3807F21F86DF for ; Mon, 12 Mar 2012 02:25:56 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id D8EB6E44D; Mon, 12 Mar 2012 17:25:54 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id C0DD9E451; Mon, 12 Mar 2012 17:25:54 +0800 (CST) Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012031217255027-18150 ; Mon, 12 Mar 2012 17:25:50 +0800 Date: Mon, 12 Mar 2012 17:25:46 +0800 From: zhangyunfei To: "'Rui Cruz'" , ppsp References: <4F5A1863.2070000@cs.vu.nl>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012031217254598613033@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-12 17:25:50, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-12 17:25:54, Serialize complete at 2012-03-12 17:25:54 Content-Type: multipart/alternative; boundary="----=_001_NextPart265683554170_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18768.005 X-TM-AS-Result: No--30.161-7.0-31-10 X-imss-scan-details: No--30.161-7.0-31-10;No--30.161-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: 'Rui Cruz' Subject: Re: [ppsp] comments on latency in tracker protocol - corrected 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, 12 Mar 2012 09:25:57 -0000 This is a multi-part message in MIME format. ------=_001_NextPart265683554170_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SSB0aGluayB0aGlzIHByb3Bvc2FsIGlzIGluIGxpbmUgd2l0aCBSaWNjYXJkbydzIHByb3Bvc2Fs LiBTbyBib3RoIHNlZW0gb2theS4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0K DQpGcm9tOiBSdWkgQ3J1eg0KRGF0ZTogMjAxMi0wMy0xMCAwMTo1MQ0KVG86IHBwc3ANCkNDOiBS dWkgQ3J1ejsgYXJub0Bjcy52dS5ubCAoYXJub0Bjcy52dS5ubCk7IHpoYW5neXVuZmVpICh6aGFu Z3l1bmZlaUBjaGluYW1vYmlsZS5jb20pOyBYaWFqaW53ZWk7ICJN4XJpbyBTZXJhZmltIE51bmVz LCBFbmcuIg0KU3ViamVjdDogUmU6IFtwcHNwXSBjb21tZW50cyBvbiBsYXRlbmN5IGluIHRyYWNr ZXIgcHJvdG9jb2wgLSBjb3JyZWN0ZWQNCltDT1JSRUNUSU9OOiB0aGVyZSB3YXMgYSB3cm9uZyBQ ZWVyTW9kZSBsaW5lIGluIHRoZSBQZWVySW5mbyBncm91cCBvZiBwcmV2aW91cyBleGFtcGxlXQ0K DQoNCkhpLA0KDQoNCkFybm8gaXMgcmlnaHQsIGFzIHdlbGwgYXMgSmlud2VpIGFuZCBZdW5mZWkg aW4gYWxsIHZpZXdwb2ludHMuDQoNCg0KQW5kIHdlIGhhdmUgYSBwcmV0dHkgc29sdXRpb24gZm9y IGl0Lg0KSXQgd2FzIG5vdCBjb25zaWRlcmVkIHRvIGJlIGluY2x1ZGVkIGluIHRoZSByZXZpc2Vk IGRyYWZ0LCBhbHRob3VnaCBkaXNjdXNzZWQsIGFzIGl0cyBhcHBsaWNhYmlsaXR5IG5lZWRzIHRv IGJlIHZlcnkgY2FyZWZ1bGx5IGFkZHJlc3NlZC4NCg0KDQpDb25zaWRlcmluZyB0aGUgZm9sbG93 aW5nIHZlcnkgY29tbW9uIHNjZW5hcmlvczoNCg0KDQphOiBVc2VyIHNpZ25zIGluIHRvIHRoZSBQ cm92aWRlciBwb3J0YWwgdGhyb3VnaCBoaXMgV2ViVFYgaW50ZXJmYWNlIChhIFNUQiBvciBhIFRh YmxldCBvciBhIFBDKSwgYnJvd3NlcyB0aGUgYXZhaWxhYmxlICJzaG93cyIgYW5kIHNlbGVjdHMg b25lIHRvIHdhdGNoLiBMYXRlciwgcGF1c2VzIGFuZCBzZWxlY3RzIGFub3RoZXIgc2hvdyAod2hp bGUgdGhlIGZpcnN0IG9uZSBjYW4gYmUga2VwdCBiZWluZyBzaGFyZWQgaW4gdGhhdCBzd2FybSwg YWx0aG91Z2ggbm90IGJlaW5nIGRpc3BsYXllZCwgb3IgYmVpbmcgZGlzcGxheWVkIGFzIGEgUElQ IHdpbmRvdykuDQoNCg0KYjogVXNlciBoYXMgYmVlbiB3YXRjaGluZyBzZXZlcmFsIHNob3dzIGJ1 dCBoYXMgdG8gbGVhdmUgYW5kIHBvd2VyIG9mZiB0aGUgZGV2aWNlLiBCdXQgdXNlciB3YW50cyB0 byByZXR1cm4gYW5kIHRoZW4gcmVzdW1lIGFsbCBoZSB3YXMgZW5nYWdlZCBpbiwgYW5kIGNvbnRp bnVlIHdhdGNoaW5nIHRoZSBzaG93IGhlIHBhdXNlZCwgZXZlbiBmcm9tIHRoZSBzYW1lIG1vbWVu dCBpbiB0aGUgc2hvdyB0aW1lbGluZS4NCg0KDQpGb3Igc2NlbmFyaW8gYSBhbmQgYiwgaW4gYSBm aXJzdCB0aW1lLCB0aGUgUGVlciB3b3VsZCBqdXN0IENPTk5FQ1QgdG8gdGhlIHN5c3RlbSB3aGls ZSB0aGUgVXNlciBicm93c2VzIHVudGlsIGRlY2lkaW5nIHdoYXQgdG8gSk9JTi4gU3Vic2VxdWVu dCBKT0lOcyAoc2NlbmFyaW8gYSwgbGF0ZXIgYWN0aW9ucykgZ2V0IHRoZSBQZWVyIGluIGRpZmZl cmVudCBzd2FybXMgdGhhdCB0aGUgVXNlciBjYW4gbWFuYWdlIChESVNDT05ORUNUIG9yIHJlLUpP SU4pLg0KDQoNCkZvciBzY2VuYXJpbyBiLCB3aGVuIHJlc3VtaW5nLCB0aGUgUGVlciBDT05ORUNU cyBidXQgd2l0aCBzcGVjaWZpYyBKT0lOIGFjdGlvbnMgaW5jbHVkZWQgaW4gdGhlIHNhbWUgUmVx dWVzdCBtZXNzYWdlLg0KVGhpcyBpbnZvbHZlcyBhIHNsaWdodCBjaGFuZ2UgaW4gdGhlIENPTk5F Q1QgbWVzc2FnZSBzZW1hbnRpY3Mgb25seSwgYW5kIHNvLCBJTUhPLCBhZGRyZXNzZXMgdGhlIGxh dGVuY3kgY29uY2VybiBpbiBhIHZlcnkgZWxlZ2FudCB3YXkuIEluZGVwZW5kZW50bHkgb2YgdXNp bmcgbW9yZSBvciBsZXNzIHNlY3VyZSBoYW5kc2hha2UgbWV0aG9kcy4gSG93ZXZlciwgdGhlIHVz ZSBvZiB0aGlzIHNwZWNpYWwgbWV0aG9kIHNob3VsZCBiZSBjYXJlZnVsbHkgY29uc2lkZXJlZCwg bm90IGp1c3QgaW4gdGVybXMgb2Ygc2VjdXJpdHkuDQoNCg0KQW4gZXhhbXBsZSBvZiB0aGUgbW9k aWZpZWQgQ09OTkVDVCBtZXNzYWdlIGlzIHRoZSBmb2xsb3dpbmcsIHdoZXJlIHRoZSBQZWVyIHNl bGVjdHMgdGhlIGRlc2lyZWQgc3dhcm1zIGFuZCBzcGVjaWZpZXMgdGhlIGNvcnJlc3BvbmRpbmcg UGVlck1vZGUgKFNFRUQgb3IgTEVFQ0gpLg0KVGhlIG9wdGlvbmFsIGVsZW1lbnQgaW4gdGhlIENP Tk5FQ1QgbWVzc2FnZSBpcyB0aGUgU3dhcm1JRCBhbmQgcmVzcGVjdGl2ZSBhdHRyaWJ1dGVzLCBh cyB3ZWxsIGFzIHRoZSBjb25kaXRpb25hbGx5IG1hbmRhdG9yeSAoZGVwZW5kaW5nIG9uIHRoZSBw cmVzZW5jZSBvZiBlbGVtZW50IFN3YXJtSUQpIGVsZW1lbnQgUGVlck51bToNCg0KDQo8UFBTUFRy YWNrZXJQcm90b2NvbCB2ZXJzaW9uPSIxLjAiPg0KICAgIDxSZXF1ZXN0PkNPTk5FQ1Q8L1JlcXVl c3Q+DQogICAgPFBlZXJJRD42NTYxNjQ2NTcyMjE8L1BlZXJJRD4NCiAgICA8IS0tIGluIENPTk5F Q1QsIFN3YXJtSUQgZWxlbWVudCBjYW4gdGFrZSBvcHRpb25hbCBAYWN0aW9uIHRvIEpPSU4gYSBz d2FybS4gQWRkaXRpb25hbGx5IGluZm9ybSBhYm91dCB0aGUgY29ycmVzcG9uZGluZyBAcGVlck1v ZGUuIC0tPg0KICAgIDxTd2FybUlEIGFjdGlvbj0iSk9JTiIgcGVlck1vZGU9IlNFRUQiPjExMTE8 L1N3YXJtSUQ+DQogICAgPFN3YXJtSUQgYWN0aW9uPSJKT0lOIiBwZWVyTW9kZT0iTEVFQ0giPjIy MjI8L1N3YXJtSUQ+DQogICAgPCEtLSBpbiBDT05ORUNULCB3aXRoIG9wdGlvbmFsIEpPSU4gQGFj dGlvbiwgQGFiaWxpdHlOQVQgdmFsdWVzICJTVFVOInwiVFVSTiJ8IlBST1hZIiAtLT4NCiAgICA8 UGVlck51bSBhYmlsaXR5TkFUPSJTVFVOIj41PC9QZWVyTnVtPg0KICAgIDxUcmFuc2FjdGlvbklE PjEyMzQ1PC9UcmFuc2FjdGlvbklEPg0KICAgIDxQZWVyR3JvdXA+DQogICAgICAgIDxQZWVySW5m bz4NCiAgICAgICAgICAgIDxQZWVySUQ+NjU2MTY0NjU3MjIxPC9QZWVySUQ+DQogICAgICAgICAg ICA8IS0tIEBhZGRyVHlwZSB2YWx1ZXMgImlwdjR8aXB2NiIsIEB0eXBlIHZhbHVlcyAiSE9TVCJ8 IlJFRkxFWElWRSJ8IlBST1hZIiAtLT4NCiAgICAgICAgICAgIDxQZWVyQWRkcmVzcyBhZGRyVHlw ZT0iaXB2NCIgaXA9IjE5OC41MS4xMDAuMSIgcG9ydD0iODAiIHByaW9yaXR5PSIxIiB0eXBlPSJI T1NUIg0KICAgICAgICAgICAgICAgIGNvbm5lY3Rpb249IkFEU0wiIGFzbj0iNjQ0OTYiLz4NCiAg ICAgICAgICAgIDxQZWVyQWRkcmVzcyBhZGRyVHlwZT0iaXB2NiIgaXA9IjIwMDE6ZGI4OjoxIiBw b3J0PSI4MCIgcHJpb3JpdHk9IjIiIHR5cGU9IkhPU1QiDQogICAgICAgICAgICAgICAgY29ubmVj dGlvbj0iM0ciIGFzbj0iNjU1MzYiLz4NCiAgICAgICAgPC9QZWVySW5mbz4NCiAgICA8L1BlZXJH cm91cD4NCjwvUFBTUFRyYWNrZXJQcm90b2NvbD4NCg0KDQpDb21wYXJpbmcgd2l0aCB0aGUgcHJl dmlvdXMgQ09OTkVDVCBtZXNzYWdlOg0KDQoNCjxQUFNQVHJhY2tlclByb3RvY29sIHZlcnNpb249 IjEuMCI+DQogICAgPFJlcXVlc3Q+Q09OTkVDVDwvUmVxdWVzdD4NCiAgICA8UGVlcklEPjY1NjE2 NDY1NzIyMTwvUGVlcklEPg0KICAgIDxUcmFuc2FjdGlvbklEPjEyMzQ1PC9UcmFuc2FjdGlvbklE Pg0KICAgIDxQZWVyR3JvdXA+DQogICAgICAgIDxQZWVySW5mbz4NCiAgICAgICAgICAgIDxQZWVy SUQ+NjU2MTY0NjU3MjIxPC9QZWVySUQ+DQogICAgICAgICAgICA8IS0tIEBhZGRyVHlwZSB2YWx1 ZXMgImlwdjR8aXB2NiIsIEB0eXBlIHZhbHVlcyAiSE9TVCJ8IlJFRkxFWElWRSJ8IlBST1hZIiAt LT4NCiAgICAgICAgICAgIDxQZWVyQWRkcmVzcyBhZGRyVHlwZT0iaXB2NCIgaXA9IjE5OC41MS4x MDAuMSIgcG9ydD0iODAiIHByaW9yaXR5PSIxIiB0eXBlPSJIT1NUIg0KICAgICAgICAgICAgICAg IGNvbm5lY3Rpb249IkFEU0wiIGFzbj0iNjQ0OTYiLz4NCiAgICAgICAgICAgIDxQZWVyQWRkcmVz cyBhZGRyVHlwZT0iaXB2NiIgaXA9IjIwMDE6ZGI4OjoxIiBwb3J0PSI4MCIgcHJpb3JpdHk9IjIi IHR5cGU9IkhPU1QiDQogICAgICAgICAgICAgICAgY29ubmVjdGlvbj0iM0ciIGFzbj0iNjU1MzYi Lz4NCiAgICAgICAgPC9QZWVySW5mbz4NCiAgICA8L1BlZXJHcm91cD4NCjwvUFBTUFRyYWNrZXJQ cm90b2NvbD4NCg0KUmVnYXJkcywNCg0KDQpSdWkgQ3J1eg0KcnVpLmNydXpAaWVlZS5vcmcNCg0K DQpJU1QvSU5FU0MtSUQvSU5PViAtIExpc2JvbiwgUG9ydHVnYWwNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KcHBzcCBtYWlsaW5nIGxpc3QNCnBwc3BAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0KDQoNCk9uIDA5 LzAzLzIwMTIsIGF0IDE0OjQ5LCBBcm5vIEJha2tlciB3cm90ZToNCg0KDQpPbiAwOC8wMy8yMDEy IDA5OjMyLCBYaWFqaW53ZWkgd3JvdGU6DQoNClRoZSBJbmZvcm1hdGlvbiBhY3F1aXNpdGlvbiBs YXRlbmN5ICh0aGUNCg0KdGltZSBpdCB0YWtlcyBwZWVyIHRvIGFjcXVpcmUgdGhlIGluZm9ybWF0 aW9uIGZyb20gdHJhY2tlcikgc2hvdWxkIGJlDQoNCmFsc28gaW4gdGhlIHNjb3BlIG9mIGJlZ2lu bmluZyBsYXRlbmN5LiBMZXShr3MgY29uc2lkZXIgVm9JUCB1c2UgY2FzZSwNCg0KU0lQIHByb2Nl ZHVyZSBpcyBhbHNvIG5lY2Vzc2FyeSBiZWZvcmUgdGhlIFZvSVAgZGF0YSB0cmFuc2ZlcnJpbmcu DQoNCg0KDQoNCkhpDQoNCm15IG9iamVjdGlvbiBpcyB3aXRoIHRoZSB0aW1lIGl0IHRha2VzIHRv IG9idGFpbiBhIGxpc3Qgb2YgcGVlcnMgZnJvbSB0aGUgdHJhY2tlci4gQ3VycmVudGx5IHRoaXMg cmVxdWlyZXMgdGhlIGZvbGxvd2luZyBpbnRlcmFjdGlvbjoNCg0KSFRUUFMgaGFuZHNoYWtlDQpD T05ORUNUDQpPSw0KSk9JTiBzd2FybQ0KT0sgKyBwZWVycw0KDQpTbyB0aGUgQ09OTkVDVCBhZGRz IGFuIGV4dHJhIHJvdW5kdHJpcCBkZWxheSB0byB0aGUgcHJvY2Vzcy4gSSdkIHJhdGhlcg0KaGF2 ZSBzb21lIG11bHRpcGxleGluZzoNCg0KSFRUUFMgaGFuZHNoYWtlDQpDT05ORUNUK0pPSU4NCk9L ICsgcGVlcg0KDQpBcyByZW1hcmtlZCBieSBZdW5mZWksIHlvdSBtYXkgYWxzbyB3YW50IHRvIGxl YXZlIG9wZW4gdGhlIG9wdGlvbiBvZiBub3QgdXNpbmcgSFRUUFMgaW4gYmVuaWduIGVudmlyb25t ZW50cywgdGhlIEhUVFBTIGhhbmRzaGFrZSBpcyBhbHNvIGV4cGVuc2l2ZSAoMiByb3VuZCB0cmlw cyArIGNyeXB0bykuDQoNCkkgd2lsbCBwb3N0IGEgbW9yZSBjb21wbGV0ZSByZXZpZXcgbGF0ZXIu DQoNCkNVLA0KICAgQXJubw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart265683554170_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
I think this proposal is in line with Riccardo's proposal. So=20 both seem okay.
 
BR
Yunfei
 
zhangyunfei
 
From: Rui Cruz
Date: 2012-03-10 01:51
To: ppsp
CC: Rui Cruz; arno@cs.vu.nl (arno@cs.vu.nl); zhangyunfei=20 (zhangyunfei@chinamobile.com); Xiajinwei; "M=E1rio Serafim Nunes, Eng."
Subject: Re: [ppsp] comments on latency in tracker protoc= ol -=20 corrected
[CORRECTION: there was a wrong PeerMode line in the PeerInfo group of= =20 previous example]

Hi,

Arno is right, as well as Jinwei and Yunfei in all viewpoints.

And we have a pretty solution for it.
It was not considered to be included in the revised draft, although=20 discussed, as its applicability needs to be very carefully addressed.

Considering the following very common scenarios:

a: User signs in to the Provider portal through his WebTV interface (= a STB=20 or a Tablet or a PC), browses the available "shows" and selects one to wat= ch.=20 Later, pauses and selects another show (while the first one can be kept be= ing=20 shared in that swarm, although not being displayed, or being displayed as = a PIP=20 window).

b: User has been watching several shows but has to leave and power of= f the=20 device. But user wants to return and then resume all he was engaged in, an= d=20 continue watching the show he paused, even from the same moment in the sho= w=20 timeline.

For scenario a and b, in a first time, the Peer would just CONNECT to= the=20 system while the User browses until deciding what to JOIN. Subsequent JOIN= s=20 (scenario a, later actions) get the Peer in different swarms that the User= can=20 manage (DISCONNECT or re-JOIN).

For scenario b, when resuming, the Peer CONNECTs but with specific JO= IN=20 actions included in the same Request message.
This involves a slight change in the CONNECT message semantics only, = and=20 so, IMHO, addresses the latency concern in a very elegant way. Independent= ly of=20 using more or less secure handshake methods. However, the use of this spec= ial=20 method should be carefully considered, not just in terms of security.

An example of the modified CONNECT message is the following, where th= e Peer=20 selects the desired swarms and specifies the corresponding PeerMode (SEED = or=20 LEECH).
The optional element in the CONNECT message is the SwarmID and respective att= ributes,=20 as well as the conditionally mandatory (depending on the presence of eleme= nt=20 SwarmID) element PeerNum:

<PPSPTrackerProtocol version=3D= "1.0">
    <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <!-- in CONNECT, Swar= mID=20 element can take optional @action to JOIN a swarm. Additionally inform abo= ut the=20 corresponding @peerMode. -->
  &= nbsp;=20 <SwarmID action=3D<= /SPAN>"JOIN"=20 peerMode=3D"SEED">1111</SwarmID>
    <SwarmID= =20 action=3D"JOIN"=20 peerMode=3D"LEECH">2222</SwarmID>
    <!-- in CONNECT, with= =20 optional JOIN @action, @abilityNAT values "STUN"|"TURN"|"PROXY" -->
    <PeerNum= =20 abilityNAT=3D"STUN">5</PeerNum>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
        <PeerInfo>
           =20 <PeerID>656164657221</PeerID>
           =20 <!-- @addrType values "ipv4|ipv6", @type values=20 "HOST"|"REFLEXIVE"|"PROXY" -->
 =  =20         <PeerAddress=20 addrType=3D"ipv4" ip=3D"198.51.100.1"=20 port=3D"80"=20 priority=3D"1" type=3D"HOST"
  =  =20             connection=3D"ADSL" asn=3D"64496"/>
&n= bsp;=20           <PeerAddress=20 addrType=3D"ipv6" ip=3D"2001:db8::1"=3D"80"=20 priority=3D"2" type=3D"HOST"
  =  =20             connection=3D"3G" asn=3D"65536"/>
&n= bsp;=20       </PeerInfo>
    </PeerGroup>
</PPSPTrackerProtocol>
<= /DIV>

Comparing with the previous CONNECT message:

<PPSPTrackerProtocol version=3D= "1.0"> =20   <Request>CONNECT</Request>
    <PeerID>656164657221</PeerID>
    <TransactionID>12345</TransactionID>
    <PeerGroup>
       =20 <PeerInfo>
    &n= bsp;=20       <PeerID>656164657221</PeerID>
           =20 <!-- @addrType values "ipv4|ipv6"= , @type=20 values "HOST"|"REFLEXIVE"|"PROXY" -->
           =20 <PeerAddress addrType=3D"ipv4" ip=3D"198.51.100.1"=20 port=3D"80"=20 priority=3D"1" type=3D"HOST"
  =  =20             connection=3D"ADSL" asn=3D"64496"/>
           =20 <PeerAddress addrType=3D"ipv6" ip=3D"2001:db8::1"=3D"80"=20 priority=3D"2" type=3D"HOST"
  =  =20             connection=3D"3G" asn=3D"65536"/>
       =20 </PeerInfo>
   =20 </PeerGroup>
</PPSPTrackerProtocol>
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 09/03/2012, at 14:49, Arno Bakker wrote:
On 08/03/2012 09:32, Xiajinwei wrote:
The Information acquisition latency=20 (the
time it takes peer to acquire the information = from=20 tracker) should be
also in the scope of beginning latency. Let=A1= =AFs=20 consider VoIP use case,
SIP procedure is also necessary before the VoI= P data=20 transferring.


Hi

my objection is= with=20 the time it takes to obtain a list of peers from the tracker. Currently = this=20 requires the following interaction:

HTTPS=20 handshake
CONNECT
OK
JOIN swarm
OK + peers

So the CON= NECT=20 adds an extra roundtrip delay to the process. I'd rather
have some=20 multiplexing:

HTTPS handshake
CONNECT+JOIN
OK + peer
As=20 remarked by Yunfei, you may also want to leave open the option of not us= ing=20 HTTPS in benign environments, the HTTPS handshake is also expensive (2 r= ound=20 trips + crypto).

I will post a more complete review=20 later.

CU,
   Arno
_________________________= ______________________
ppsp=20 mailing list
ppsp@ietf.org
https://www.ietf.org= /mailman/listinfo/ppsp

------=_001_NextPart265683554170_=------ From rui.cruz@ieee-pt.org Mon Mar 12 02:26:31 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 A7B9E21F870A for ; Mon, 12 Mar 2012 02:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.358 X-Spam-Level: X-Spam-Status: No, score=-103.358 tagged_above=-999 required=5 tests=[AWL=0.240, 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 s-9nZVB5xCUh for ; Mon, 12 Mar 2012 02:26:31 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B337021F86DF for ; Mon, 12 Mar 2012 02:26:30 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2698072wib.13 for ; Mon, 12 Mar 2012 02:26:30 -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=u5ZWkGyx7x/MmvPqFkA61RJuDjGcksZ2N3DxLvp++tM=; b=YV/zk6CTQl97mzPSHUsSsNhdgJ5gBOn8g5t25MjGGXG97JcaXH7ClzgfrFRLqiUgs/ T3tkb/o3xkc1B1mQPI1ZpQzePVO22u1caj9Qz/nOryKneeN3vE80W8bljzyp0usVUazA Ije2jjlrH8IKJyV6qndfDF+pmHlt/QhZ47wqPjn1W5pso9celhnyjhbogezLAg7Ku0aK eCK97hL2lRU3UWd02bJ0UvkkgDSxo18KvYbbHf05r3Z6vAS8k3/BybfePt+DnODfGgWf 7pmnpavplelMl5lHXeXGaAlVQw2bMOPcWxI8HERcANQSLAZrZuKs3dQ9BsY+Fo7xLXz0 J6Sw== Received: by 10.216.133.19 with SMTP id p19mr6662240wei.118.1331544389883; Mon, 12 Mar 2012 02:26:29 -0700 (PDT) Received: from [192.168.1.70] (89-180-88-128.net.novis.pt. [89.180.88.128]) by mx.google.com with ESMTPS id o2sm32834402wiv.11.2012.03.12.02.26.27 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 02:26:28 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_4421CA68-38BB-454E-BF65-6F7A00662706" From: Rui Cruz In-Reply-To: <20120309182814.18036pnbobmt5ub2@webmail.uniud.it> Date: Mon, 12 Mar 2012 09:26:26 +0000 Message-Id: References: <2012030915413217800633@chinamobile.com> <20120309182814.18036pnbobmt5ub2@webmail.uniud.it> To: Riccardo Bernardini X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlQo9owEchHfrkqsosYqVW/jOd69Huxm8hwvCUAhzba4xHptshWHVnwk6WGwpX5E6cbZfAd Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] comments on latency in 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: Mon, 12 Mar 2012 09:26:31 -0000 --Apple-Mail=_4421CA68-38BB-454E-BF65-6F7A00662706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Riccardo, Read inline... 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 09/03/2012, at 17:28, Riccardo Bernardini wrote: >=20 > =46rom another point of view, I like the flexibility of having them = separated. As said above, maybe in some application one would like to = do a CONNECT without JOIN. Also, is it possible that one JOINs more = than one swarm at time? For example, if I want to implement something = similar to the "exchange" button found on many remotes (that brings you = back to the previous channel), it could make sense to remain JOINed to a = swarm even when I "change channel." If the "multiple JOIN" scenario is = reasonable, we should have at least a "CONNECT+JOIN" and a "simple = JOIN". That kind of scenario of a "resume"-like feature can be perfectly = addressed with the simple solution I have presented. >=20 > Riccardo --Apple-Mail=_4421CA68-38BB-454E-BF65-6F7A00662706 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Riccardo,

Read inline...

Regards,

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

On 09/03/2012, at 17:28, Riccardo Bernardini = wrote:

=46rom another = point of view, I like the flexibility of having them separated.  As = said above, maybe in some application one would like to do a CONNECT = without JOIN.   Also, is it possible that one JOINs more than = one swarm at time? For example, if I want to implement something similar = to the "exchange" button found on many remotes (that brings you back to = the previous channel), it could make sense to remain JOINed to a swarm = even when I "change channel."  If the "multiple JOIN" scenario is = reasonable, we should have at least a "CONNECT+JOIN" and a "simple = JOIN".

That kind of scenario of a = "resume"-like feature can be perfectly addressed with the simple = solution I have presented.

Riccardo

= --Apple-Mail=_4421CA68-38BB-454E-BF65-6F7A00662706-- From Martin.Stiemerling@neclab.eu Wed Mar 14 02:48:55 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBDC21F8566 for ; Wed, 14 Mar 2012 02:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.176, 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 S9Bo+0f1xiST for ; Wed, 14 Mar 2012 02:48:55 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4221F856F for ; Wed, 14 Mar 2012 02:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 31DFD1008C4 for ; Wed, 14 Mar 2012 10:49:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKqL4TbOlzTJ for ; Wed, 14 Mar 2012 10:49:20 +0100 (CET) Received: from METHONE.office.hd (unknown [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 16755100899 for ; Wed, 14 Mar 2012 10:49:15 +0100 (CET) Received: from [10.1.1.12] (10.1.1.12) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Mar 2012 10:48:47 +0100 Message-ID: <4F606981.60201@neclab.eu> Date: Wed, 14 Mar 2012 10:48:49 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.12] Subject: [ppsp] Draft Agenda for PPSP session at IETF#83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:48:56 -0000 Dear all, Here is the draft agenda for the upcoming session in Paris: Draft Agenda for the PPSP WG Revision: 20120314-00 83rd IETF meeting in Paris WEDNESDAY, March 28, 2012 0900-1130 Morning Session I Room: 252A Working Group Chairs: Yunfei Zhang Martin Stiemerling Charter/Drafts: https://datatracker.ietf.org/wg/ppsp/ Draft Agenda - Note Well - Agenda bashing (5 minutes) - Status of the WG (10 minutes) - Problem Statement/Requirement (10 minutes) (draft-ietf-ppsp-problem-statement-08) Presenter: TBD - Peer Protocol (45 minutes) (draft-ietf-ppsp-peer-protocol-01) Presenter: Arno Bakker - Tracker Protocol (40 minutes) (draft-gu-ppsp-tracker-protocol-07) Presenter: TBD - Implementers session (40 minutes) - swift - any other? ---- -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Martin.Stiemerling@neclab.eu Wed Mar 14 14:35: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 4598411E8087 for ; Wed, 14 Mar 2012 14:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 GZRbW3KCYh4Y for ; Wed, 14 Mar 2012 14:35:35 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 271C411E807F for ; Wed, 14 Mar 2012 14:35:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id AD7FF1008E5 for ; Wed, 14 Mar 2012 22:36:03 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UACQj7YAlKU for ; Wed, 14 Mar 2012 22:36:03 +0100 (CET) Received: from METHONE.office.hd (unknown [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 9638E1008E1 for ; Wed, 14 Mar 2012 22:35:58 +0100 (CET) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Mar 2012 22:35:27 +0100 Message-ID: <4F610F11.1010109@neclab.eu> Date: Wed, 14 Mar 2012 22:35:13 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [ppsp] IETF#83: Implementers session in the PPSP session 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, 14 Mar 2012 21:35:39 -0000 Dear all, We have a 40 minutes slot in the upcoming PPSP session for implementation reports and demos of prototypes. We have the swift/ppsp demo to be shown and would like to know if somebody else also wants to share PPSP implementation experiences? Let Yunfei and me know if you are interested until Tuesday, March 20th, 1pm CET. Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Martin.Stiemerling@neclab.eu Wed Mar 21 02:19: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 E833321F85CE for ; Wed, 21 Mar 2012 02:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 wZCBjNNEvdz0 for ; Wed, 21 Mar 2012 02:19:18 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2E84A21F84FB for ; Wed, 21 Mar 2012 02:19:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5ACCC1009F8 for ; Wed, 21 Mar 2012 10:20:52 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxrBbROJ6sB3 for ; Wed, 21 Mar 2012 10:20:52 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 3CDAF1009F4 for ; Wed, 21 Mar 2012 10:20:47 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Mar 2012 10:19:11 +0100 Message-ID: <4F699D0F.5050303@neclab.eu> Date: Wed, 21 Mar 2012 10:19:11 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: [ppsp] Due date for Presentations for PPSP session at upcoming IETF meeting X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ppsp-chairs@tools.ietf.org List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 09:19:19 -0000 Hi all presenters, You must submit a **draft** version of your presentation for the upcoming PPSP session at the IETF 83 meeting to the PPSP chairs (ppsp-chairs@tools.ietf.org) before *** Tuesday, March 27th, 11 am CET *** Just hit the reply button and attach your presentation to send your slides to the ppsp chairs. Your presentation can be removed from the agenda, if you miss the deadline. This is not to annoy the presenters, but to ensure that all participants have the chance to read the slides before the PPSP session on Wednesday. Have a good and safe trip to Paris! Thank you and see you in Paris Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From rui.cruz@ieee-pt.org Wed Mar 21 02:35: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 A393521F85F9 for ; Wed, 21 Mar 2012 02:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 9Ln1W5nf7NHC for ; Wed, 21 Mar 2012 02:35:24 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A2A3721F85EA for ; Wed, 21 Mar 2012 02:35:23 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so942891wib.13 for ; Wed, 21 Mar 2012 02:35:22 -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=NsbuXP9MVDimBXXGLTDw+UbKoVHosCpqPtvxbAfp93A=; b=lPR+TMdd4RV1XKmLoxXtXr4nLSULwydLqvJP0kmzzUmixuzTVKzxNszRkLSM5RlfWD XRm6r96VtecyA0vGWIb/o2VvIYn2tIa7EJ14SzEKi8EjMtjKjEZWC0BNFiVEDBRRZsGB OsJ1/gv9zDxwGTC8Jo9pJhbno76KSi5vwGKfgiHxM2XVmo7LfRrVRUyOFgpL4TcJAjK9 IHn5xR5K1elt8xPN/JLRSjVebTzHi9UFKGRun4HhWBwvpDwVb2DQssDVNDvtz4jhQP1x 4qR+tIbut6Z6gH9sflpsnUjRBDG0/QLAff2q221EgYkspG5OinynSM9vc23qf0SbC7vs w70A== Received: by 10.180.101.230 with SMTP id fj6mr36676779wib.13.1332322522771; Wed, 21 Mar 2012 02:35:22 -0700 (PDT) Received: from airoso.lan ([89.180.8.80]) by mx.google.com with ESMTPS id d7sm5311295wiz.6.2012.03.21.02.35.20 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 02:35:21 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_A5BD4B38-0A43-49D0-B372-0A98632A00DF" From: Rui Cruz In-Reply-To: <4F610F11.1010109@neclab.eu> Date: Wed, 21 Mar 2012 09:35:19 +0000 Message-Id: References: <4F610F11.1010109@neclab.eu> To: Martin Stiemerling X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQn0yAuWuroK6PrFvIjNVxuyTp1t+Dfo1B5ZsphKQRdT6Otj2Tf+LcV9ipFA8plF3cbpYw1D Cc: Rui Cruz , ppsp@ietf.org Subject: Re: [ppsp] IETF#83: Implementers session in the PPSP session 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, 21 Mar 2012 09:35:24 -0000 --Apple-Mail=_A5BD4B38-0A43-49D0-B372-0A98632A00DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Martin, We are interested in showing an implementation of the Tracker Protocol. 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 14/03/2012, at 21:35, Martin Stiemerling wrote: > Dear all, >=20 > We have a 40 minutes slot in the upcoming PPSP session for = implementation reports and demos of prototypes. >=20 > We have the swift/ppsp demo to be shown and would like to know if = somebody else also wants to share PPSP implementation experiences? >=20 > Let Yunfei and me know if you are interested until Tuesday, March = 20th, 1pm CET. >=20 > Martin >=20 > --=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_A5BD4B38-0A43-49D0-B372-0A98632A00DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Martin,

We are interested in showing an = implementation of the Tracker Protocol.

Regards,

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

On 14/03/2012, at 21:35, Martin Stiemerling = wrote:

Dear all,

We have a 40 minutes slot in the = upcoming PPSP session for implementation reports and demos of = prototypes.

We have the swift/ppsp demo to be shown and would = like to know if somebody else also wants to share PPSP implementation = experiences?

Let Yunfei and me know if you are interested until = Tuesday, March 20th, 1pm CET.

 Martin

--
martin.stiemerling@neclab.eu<= /a>

NEC Laboratories Europe - Network Research Division NEC = Europe Limited
Registered Office: NEC House, 1 Victoria Road, London = W3 6BL
Registered in England = 283
_______________________________________________
ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

= --Apple-Mail=_A5BD4B38-0A43-49D0-B372-0A98632A00DF-- From Martin.Stiemerling@neclab.eu Fri Mar 23 03:55: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 76B1221F851D for ; Fri, 23 Mar 2012 03:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.454 X-Spam-Level: X-Spam-Status: No, score=-102.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 wLZIMUJMuCzs for ; Fri, 23 Mar 2012 03:55:49 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4165321F851C for ; Fri, 23 Mar 2012 03:55:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 307FB100A4E; Fri, 23 Mar 2012 11:57:44 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D61yZsBfaxJE; Fri, 23 Mar 2012 11:57:44 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 181A3100A4A; Fri, 23 Mar 2012 11:57:34 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 11:55:38 +0100 Message-ID: <4F6C56A9.80503@neclab.eu> Date: Fri, 23 Mar 2012 11:55:37 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Rui Cruz References: <4F610F11.1010109@neclab.eu> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: ppsp@ietf.org Subject: Re: [ppsp] IETF#83: Implementers session in the PPSP session 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, 23 Mar 2012 10:55:53 -0000 Rui, Noted an the agenda. Is 10 minutes Ok, or do you need more time? Martin On 03/21/2012 10:35 AM, Rui Cruz wrote: > Dear Martin, > > We are interested in showing an implementation of the Tracker Protocol. > > 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 14/03/2012, at 21:35, Martin Stiemerling wrote: > >> Dear all, >> >> We have a 40 minutes slot in the upcoming PPSP session for >> implementation reports and demos of prototypes. >> >> We have the swift/ppsp demo to be shown and would like to know if >> somebody else also wants to share PPSP implementation experiences? >> >> Let Yunfei and me know if you are interested until Tuesday, March >> 20th, 1pm CET. >> >> Martin >> >> -- >> martin.stiemerling@neclab.eu >> >> NEC Laboratories Europe - Network Research Division NEC Europe Limited >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL >> Registered in England 283 >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Martin.Stiemerling@neclab.eu Fri Mar 23 03:56: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 7CBA221F851D for ; Fri, 23 Mar 2012 03:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 2jVlbanplouy for ; Fri, 23 Mar 2012 03:56:07 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3FBED21F851C for ; Fri, 23 Mar 2012 03:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8E2B4100A4F for ; Fri, 23 Mar 2012 11:58:02 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+k0YZi+7Z3F for ; Fri, 23 Mar 2012 11:58:02 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 72F7A100A4E for ; Fri, 23 Mar 2012 11:57:57 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 11:56:01 +0100 Message-ID: <4F6C56C1.5050805@neclab.eu> Date: Fri, 23 Mar 2012 11:56:01 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: [ppsp] Final agenda PPSP @ IETF 83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:56:11 -0000 Dear all, Please find here the final agenda for the PPSP session at the IETF 83 meeting: Final Agenda for the PPSP WG Revision: 20120323-00 83rd IETF meeting in Paris WEDNESDAY, March 28, 2012 0900-1130 Morning Session I Room: 252A Working Group Chairs: Yunfei Zhang Martin Stiemerling Charter/Drafts: https://datatracker.ietf.org/wg/ppsp/ Draft Agenda - Note Well - Agenda bashing (5 minutes) - Status of the WG (5 minutes) - Charter Update Discussion (10 minutes) - Problem Statement/Requirement (10 minutes) (draft-ietf-ppsp-problem-statement-08) Presenter: TBD - Peer Protocol (40 minutes) (draft-ietf-ppsp-peer-protocol-01) Presenter: Arno Bakker - Tracker Protocol (40 minutes) (draft-gu-ppsp-tracker-protocol-07) Presenter: TBD - Implementers session (40 minutes) - swift (Arno/Mark) (30 minutes) - implementation of the Tracker Protocol (Rui) (10 minutes) ---- -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From rui.cruz@ieee-pt.org Fri Mar 23 03:59:55 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A43E21F8564 for ; Fri, 23 Mar 2012 03:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 wnJDxMFU2PtG for ; Fri, 23 Mar 2012 03:59:51 -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 3C62021F846C for ; Fri, 23 Mar 2012 03:59:51 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1398700wgb.13 for ; Fri, 23 Mar 2012 03:59:50 -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=ibOjTvhbitXMkIJXREsNqpqZAyyqN0uq/DGPgSR46oE=; b=cpicjPNJhDhCBCrd08f72yp5EEva24/wzsoEnNXxavdsYLNdC5aAF1Dd80IifhK8cJ YrEhiF5CSp2Lj0z8c/hGnYfWgFz947/IAZftZRMnPP7bdXsdtptWY6PIbpPHDVjvCeCI NNmxc3gfctPUnPecLxf7lrOVw98u7gM+SYBE6x+81eE23XYe+EN5Td/9OeFKIGO99gZz uRQx/w8Kp1LvwEd4AYoVhMf5IRfGHTBPFg42/FVuFStJ6S5L+ShB4fX/rHYJv7+AyhuT zIG0g3nlctt7BPqqzcN9bBBmoiuZsyt2c0KF3CgnvLyHpha29nz1fVfGJ77ebG/Jp3iX x+lQ== Received: by 10.180.84.164 with SMTP id a4mr5543794wiz.2.1332500390259; Fri, 23 Mar 2012 03:59:50 -0700 (PDT) Received: from [192.168.1.210] ([89.180.148.200]) by mx.google.com with ESMTPS id ff2sm21527419wib.9.2012.03.23.03.59.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 03:59:49 -0700 (PDT) References: <4F610F11.1010109@neclab.eu> <4F6C56A9.80503@neclab.eu> In-Reply-To: <4F6C56A9.80503@neclab.eu> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <88991E58-7EAB-44A0-BE7B-A0303E2F6A3D@ieee-pt.org> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B176) From: Rui Cruz Date: Fri, 23 Mar 2012 10:59:45 +0000 To: Martin Stiemerling X-Gm-Message-State: ALoCoQmEN0Zvw8Wo6YnoH0kLlvc64B81rUO9U6AeiWHHMZpK85+mJP1Yg+rJPPdMshNGLUqJyzDE Cc: Rui Cruz , "" Subject: Re: [ppsp] IETF#83: Implementers session in the PPSP session 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, 23 Mar 2012 10:59:55 -0000 Hi Martin,=20 10 minutes will be enough. Cumprimentos/Regards, Rui Cruz Sent from my iPad2 On 23/03/2012, at 10:55, Martin Stiemerling w= rote: > Rui, >=20 > Noted an the agenda. >=20 > Is 10 minutes Ok, or do you need more time? >=20 > Martin >=20 > On 03/21/2012 10:35 AM, Rui Cruz wrote: >> Dear Martin, >>=20 >> We are interested in showing an implementation of the Tracker Protocol. >>=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 14/03/2012, at 21:35, Martin Stiemerling wrote: >>=20 >>> Dear all, >>>=20 >>> We have a 40 minutes slot in the upcoming PPSP session for >>> implementation reports and demos of prototypes. >>>=20 >>> We have the swift/ppsp demo to be shown and would like to know if >>> somebody else also wants to share PPSP implementation experiences? >>>=20 >>> Let Yunfei and me know if you are interested until Tuesday, March >>> 20th, 1pm CET. >>>=20 >>> Martin >>>=20 >>> -- >>> martin.stiemerling@neclab.eu >>>=20 >>> NEC Laboratories Europe - Network Research Division NEC Europe Limited >>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL >>> Registered in England 283 >>> _______________________________________________ >>> ppsp mailing list >>> ppsp@ietf.org >>> https://www.ietf.org/mailman/listinfo/ppsp >>=20 >=20 > --=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited > Registered Office: NEC House, 1 Victoria Road, London W3 6BL > Registered in England 283 From a.bakker@vu.nl Mon Mar 26 01:16:02 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAF021F8527 for ; Mon, 26 Mar 2012 01:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=1.404, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-aNgFhqySlh for ; Mon, 26 Mar 2012 01:16:00 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id E4C5521F851D for ; Mon, 26 Mar 2012 01:15:56 -0700 (PDT) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 26 Mar 2012 10:15:55 +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.1.218.12; Mon, 26 Mar 2012 10:15:54 +0200 Message-ID: <4F7025C4.4010201@cs.vu.nl> Date: Mon, 26 Mar 2012 10:16:04 +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 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: [ppsp] Tracker draft review 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, 26 Mar 2012 08:16:02 -0000 Hi all here is my review of the draft-gu-ppsp-tracker-protocol-07 proposal: p.5. Would the proposed usage guide not be a better place for the 1.1 + 1.2 tutorials? p.8. IMHO the draft should list the requirements for the enrollment certificates. p.8. Typo: "encoded alternative" -> "encoded alternatives" p.10. Peer-Peer messages. Please add a reference to the peer protocol WG item. p.12. "Each peer ... contacts the tracker to advertise which information it has available". This is not required for all trackers, just the ones that use this info to steer peer selection. See PPSP.TP.REQ-7. p.13. Typo: "5. Peer requests for" -> "5. Peer requests" p.14. Typo: "registers in the tracker" -> "registers with the tracker" p.15. Concept PeerMode type is used without introduction. p.15. Typo: "to request to the tracker" -> "to request from the tracker" p.15. IMHO one can remove the TERMINATED state. p.16. State machine: Does a peer need to be connected to a tracker all the time? p.20 "Content-Lenght" -> "Content-Length" p.23. What is the value of "Content-Type" for the tracker protocol? p.23. Concept PeerGroup is used without introduction. p.24. Elements like PeerMode, PeerGroup will not be used by all tracker implementations, so should be marked "MAY". p.25. What are the security implications of the PeerMode, uploadBWlevel, onlineTime elements? What if malicious peers claims to e.g. have high bandwidth, can they gain an advantage here that would allow them to eclipse or disrupt the service? p.26. What are the security implications of having a peer announce its own IP address, connection, ASN, etc. instead of the tracker gathering this information independently from the network? p.28. What are the security implications of a peer sending information about its available bandwidth? p.30. CONNECT: Please specify which fields are mandatory and which optional. E.g. link status. p.32. No PeerID in CONNECT response? p.34. Typo: "SUCCESSFULL" -> "SUCCESFUL" p.35. Why doesn't a peer in SEED mode connect to other peers? Especially in a world with NAT boxes it may be necessary for seeders to initiate the connection themselves. p.39. Typo: "START_REPORT" -> "STAT_REPORT" p.40. "If the length of the message does not matches the Content-Length" How will you know, given HTTP is run over TCP which is a byte stream? p.42. Peers may also refuse to servce content and put QoS at risk. p.42. Will the tracker protocol function today, without this global trust mechanism? p.46. Appendix B. Where do the MPDs play a role in the tracker protocol? The proposed usage guide may be a better place, and a reference to the ISO/IEC 23009-1 would suffice IMHO. p.50. - PPSP-REQ-6: What is the chunk addressing scheme used? Should support multiple. p.50. - PPSP.TP.REQ-7: ChunkMaps are optional. p.51. - PPSP.TP.REQ-8: BASE64-encoding is not compact, actually it takes more bytes than original data. I.e. no compression here. p.51. - PPSP.SEC.REQ-1: How does the tracker protocol support closed swarms? What's its role? p.51. - PPSP.SEC.REQ-2: What role does tracker play in content confidentiality? p.51. - PPSP.SEC.REQ-7: How does the design support distributed architectures like DHTs and gossip? p.52. - PPSP.SEC.REQ-9: Using MPDs for content integrity protection is only one particular scheme. Please allow for multiple. Regards, Arno From Martin.Stiemerling@neclab.eu Mon Mar 26 23:05: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 A958121F8782 for ; Mon, 26 Mar 2012 23:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 kWUX+DrTI8uw for ; Mon, 26 Mar 2012 23:05:54 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 169C721F8773 for ; Mon, 26 Mar 2012 23:05:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B6138100A8E; Tue, 27 Mar 2012 08:06:24 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+orA8J5SmeS; Tue, 27 Mar 2012 08:06:24 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 95C511004B7; Tue, 27 Mar 2012 08:06:14 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Mar 2012 08:05:32 +0200 Message-ID: <4F7158AB.2090705@neclab.eu> Date: Tue, 27 Mar 2012 08:05:31 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: , stefano previdi Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [ppsp] Upcoming change of the PPSP co-chair 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, 27 Mar 2012 06:05:54 -0000 Dear all, I will step down as PPSP co-chair at the PPSP session here in Paris. Stefano Previdi (sprevidi@cisco.com) will be the new chair. Thank you Stefano for agreeing to be the new co-chair! Yunfei will stay as co-chair. However, I won't be away as I will change roles and come in as your new Transport Area Director. Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Martin.Stiemerling@neclab.eu Tue Mar 27 01:09: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 591FD21F84F4 for ; Tue, 27 Mar 2012 01:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 RSkT2KjvfSWk for ; Tue, 27 Mar 2012 01:09:07 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 61D6621F87B8 for ; Tue, 27 Mar 2012 01:09:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 393DE100A93 for ; Tue, 27 Mar 2012 10:09:37 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqAm+F-Fpc1c for ; Tue, 27 Mar 2012 10:09:37 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 22AFD100A8C for ; Tue, 27 Mar 2012 10:09:32 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Mar 2012 10:08:38 +0200 Message-ID: <4F717584.9010508@neclab.eu> Date: Tue, 27 Mar 2012 10:08:36 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <4F699D0F.5050303@neclab.eu> In-Reply-To: <4F699D0F.5050303@neclab.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [ppsp] TODAY: Due date for Presentations for PPSP session at upcoming IETF meeting X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "ppsp-chairs@tools.ietf.org" List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:09:08 -0000 Hi all, I have received the peer protocol presentation but no the others until NOW. Chair's slides are there too, of course :) Please send them slides until *** Tuesday, March 27th, 11 am CET *** Martin On 03/21/2012 10:19 AM, Martin Stiemerling wrote: > Hi all presenters, > > You must submit a **draft** version of your presentation for the > upcoming PPSP session at the IETF 83 meeting to the PPSP chairs > (ppsp-chairs@tools.ietf.org) before > > *** Tuesday, March 27th, 11 am CET *** > > Just hit the reply button and attach your presentation to send your > slides to the ppsp chairs. > > Your presentation can be removed from the agenda, if you miss the deadline. > > This is not to annoy the presenters, but to ensure that all participants > have the chance to read the slides before the PPSP session on Wednesday. > > Have a good and safe trip to Paris! > > Thank you and see you in Paris > > Martin > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From zhangyunfei@chinamobile.com Tue Mar 27 02:28: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 74BB521F853B for ; Tue, 27 Mar 2012 02:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.112 X-Spam-Level: X-Spam-Status: No, score=-98.112 tagged_above=-999 required=5 tests=[AWL=0.511, 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 a5JqM93UjQnV for ; Tue, 27 Mar 2012 02:28:56 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9737521F84F3 for ; Tue, 27 Mar 2012 02:28:55 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 540B9E576; Tue, 27 Mar 2012 17:28:53 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 495FEE3C3; Tue, 27 Mar 2012 17:28:53 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012032717284967-17078 ; Tue, 27 Mar 2012 17:28:49 +0800 Date: Tue, 27 Mar 2012 17:28:34 +0800 From: zhangyunfei To: "Martin Stiemerling" , ppsp , "stefano previdi" References: <4F7158AB.2090705@neclab.eu> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012032717283485274124@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-27 17:28:51, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-27 17:28:53, Serialize complete at 2012-03-27 17:28:53 Content-Type: multipart/alternative; boundary="----=_001_NextPart410275768618_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18800.006 X-TM-AS-Result: No--19.664-7.0-31-10 X-imss-scan-details: No--19.664-7.0-31-10;No--19.664-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] Upcoming change of the PPSP co-chair 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, 27 Mar 2012 09:28:56 -0000 This is a multi-part message in MIME format. ------=_001_NextPart410275768618_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" VGhhbmtzIE1hcnRpbiBmb3IgdGhlIGdyZWF0IGVmZm9ydHMgb24gbW92aW5nIFBQU1AgZm9yd2Fy ZC4gQ3VycmVudGx5IHRoaW5ncyBoYXZlIGJlZW4gaW4gdGhlIHJpZ2h0IHRyYWNrLiBJIHRoaW5r IHlvdXIgcm9sZSBhcyB0aGUgcmVzcG9uc2libGUgQUQgd2lsbCBkZWZpbml0ZWx5IGJlIGhlbHBm dWwgdG8gUFBTUC4gDQpXZWxjb21lIFN0ZWZhbm8gZm9yIGNvLWNoYWlyaW5nIFBQU1AuIFN0ZWZh bm8gaXMgZXhwZXJpZW5jZWQgaW4gYm90aCBQMlAgdGVjaG5vbG9neSBhbmQgSUVURiBhY3Rpdml0 aWVzLiBIZSBpcyBjby1jaGFpcmluZyBQMlBSRyBpbiBJUlRGLiANCg0KQlINCll1bmZlaQ0KDQoN Cg0KDQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBNYXJ0aW4gU3RpZW1lcmxpbmcNCkRhdGU6IDIwMTIt MDMtMjcgMTQ6MDUNClRvOiBwcHNwQGlldGYub3JnOyBzdGVmYW5vIHByZXZpZGkNClN1YmplY3Q6 IFtwcHNwXSBVcGNvbWluZyBjaGFuZ2Ugb2YgdGhlIFBQU1AgY28tY2hhaXINCkRlYXIgYWxsLA0K DQpJIHdpbGwgc3RlcCBkb3duIGFzIFBQU1AgY28tY2hhaXIgYXQgdGhlIFBQU1Agc2Vzc2lvbiBo ZXJlIGluIFBhcmlzLg0KDQpTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpQGNpc2NvLmNvbSkgd2ls bCBiZSB0aGUgbmV3IGNoYWlyLg0KDQpUaGFuayB5b3UgU3RlZmFubyBmb3IgYWdyZWVpbmcgdG8g YmUgdGhlIG5ldyBjby1jaGFpciENCg0KWXVuZmVpIHdpbGwgc3RheSBhcyBjby1jaGFpci4NCg0K SG93ZXZlciwgSSB3b24ndCBiZSBhd2F5IGFzIEkgd2lsbCBjaGFuZ2Ugcm9sZXMgYW5kIGNvbWUg aW4gYXMgeW91ciBuZXcgDQpUcmFuc3BvcnQgQXJlYSBEaXJlY3Rvci4NCg0KICAgTWFydGluDQoN Ci0tIA0KbWFydGluLnN0aWVtZXJsaW5nQG5lY2xhYi5ldQ0KDQpORUMgTGFib3JhdG9yaWVzIEV1 cm9wZSAtIE5ldHdvcmsgUmVzZWFyY2ggRGl2aXNpb24gTkVDIEV1cm9wZSBMaW1pdGVkDQpSZWdp c3RlcmVkIE9mZmljZTogTkVDIEhvdXNlLCAxIFZpY3RvcmlhIFJvYWQsIExvbmRvbiBXMyA2QkwN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAyODMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart410275768618_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Thanks Martin for the great efforts on moving PPSP forward. Currently= =20 things have been in the right track. I think your role as the responsible = AD=20 will definitely be helpful to PPSP.
Welcome Stefano for co-chairing PPSP. Stefano is experienced in both = P2P=20 technology and IETF activities. He is co-chairing P2PRG in IRTF.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-03-27 14:05
To: ppsp@ietf.org; <= A=20 href=3D"mailto:sprevidi@cisco.com">stefano previdi
Subject: [ppsp] Upcoming change of the PPSP=20 co-chair
Dear all,
 
I will step down as PPSP co-chair = at the PPSP session here in Paris.
 
Stefano Previdi (sprevidi@cisco.com) will be = ;the new chair.
 
Thank you Stefano for agreeing to be&nb= sp;the new co-chair!
 
Yunfei will stay as co-chair.
 
However, I won't be away as I will=  change roles and come in as your = new 
Transport Area Director.
 
   Martin
 
-- 
martin.stiemerling@neclab.eu
 
NEC Laboratories Europe - Network Research&n= bsp;Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria&nbs= p;Road, London W3 6BL
Registered in England 283
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart410275768618_=------ From zhangyunfei@chinamobile.com Tue Mar 27 03:25:57 2012 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4682421E814D for ; Tue, 27 Mar 2012 03:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.204 X-Spam-Level: X-Spam-Status: No, score=-97.204 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_20=-0.74, 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 gXgbK+EO96fw for ; Tue, 27 Mar 2012 03:25:56 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 460CB21E8147 for ; Tue, 27 Mar 2012 03:25:56 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 7243EE56D; Tue, 27 Mar 2012 18:25:54 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 68F06E422; Tue, 27 Mar 2012 18:25:54 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012032718255091-19394 ; Tue, 27 Mar 2012 18:25:50 +0800 Date: Tue, 27 Mar 2012 18:25:41 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012032718254115633044@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-27 18:25:51, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-27 18:25:53, Serialize complete at 2012-03-27 18:25:53 Content-Type: multipart/alternative; boundary="----=_001_NextPart025848653733_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18800.006 X-TM-AS-Result: No--5.568-7.0-31-10 X-imss-scan-details: No--5.568-7.0-31-10;No--5.568-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] The meeting materials 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: Tue, 27 Mar 2012 10:25:57 -0000 This is a multi-part message in MIME format. ------=_001_NextPart025848653733_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgYWxsLA0KICAgIFRoZSBQUFNQIG1lZXRpbmcgbWF0ZXJpYWxzIGhhdmUgYmVlbiB1cGxvYWRl ZC4gUGxlYXNlIGZpbmQgaW4gdGhlIGZvbGxvd2luZyBsaW5rIGZvciB5b3VyIHJlZmVyZW5jZToN CiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvODMvbWF0ZXJpYWxzLmh0bWwg DQoNCkJSDQpZdW5mZWkNCg0KDQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart025848653733_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi all,
    The PPSP=20 meeting materials have been uploaded. Please find in t= he=20 following link for your reference:
 https://da= tatracker.ietf.org/meeting/83/materials.html=20
 
BR
Yunfei
 
zhangyunfei
------=_001_NextPart025848653733_=------ From Fabio.Picconi@technicolor.com Thu Mar 29 05:59: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 C889721F8AC2 for ; Thu, 29 Mar 2012 05:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLBoR-gDIj79 for ; Thu, 29 Mar 2012 05:59:29 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id E502B21F8AD9 for ; Thu, 29 Mar 2012 05:59:26 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKT3RcqZN3zWQY5XFsW6f6PIt/X6xF4Py3@postini.com; Thu, 29 Mar 2012 05:59:28 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 29 Mar 2012 14:56:26 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 29 Mar 2012 14:56:42 +0200 From: Picconi Fabio To: "arno@cs.vu.nl" , ppsp Date: Thu, 29 Mar 2012 14:56:41 +0200 Thread-Topic: [ppsp] Proposal to resolve Issue 10 + 13 Thread-Index: AczZrCPfmXywO/e3Tkm8C+Ad2MF7sAAH02LQDPabJnA= Message-ID: <320C4182454E96478DC039F2C481987204CCDC1870@MOPESMBX01.eu.thmulti.com> References: <4F16A1EF.4060501@cs.vu.nl> <320C4182454E96478DC039F2C481987204A4D07528@MOPESMBX01.eu.thmulti.com> <4F1D1F72.5040801@cs.vu.nl> <320C4182454E96478DC039F2C481987204C4170C2C@MOPESMBX01.eu.thmulti.com> In-Reply-To: <320C4182454E96478DC039F2C481987204C4170C2C@MOPESMBX01.eu.thmulti.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:59:29 -0000 Hi, So, a follow-up of what I said during the Paris meeting: 1) Regarding the content addressing mechanism, I think the mandatory soluti= on should be one which is as simple as possible without compromising effici= ency. Between bin numbering and the simpler list of ranges (e.g., run-lengt= h-style encoding), I would chose the second since implementing it takes 5 l= ines of code and the bandwidth overhead should be quite reasonable. So I wo= uld make bin numbering optional, unless you show that the bandwidth gain is= significant. 2) Regarding integrity checking, somebody mentioned that forcing implemente= rs to support a feature does not mean you have to use it in a given deploym= ent. I think that should be the case for integrity checking. Now, if integr= ity checking is mandatory, we have to chose an integrity mechanism. Paper [1] gives a nice comparison of four different mechanisms, and the tra= de-offs between CPU complexity, bandwidth, and delay. "Sign-all" has the best delay but worst CPU complexity, "Merkle trees" has = better CPU complexity at the expense of worse delay, and "sign-and-correct"= has better bandwidth efficiency than Merkle trees at the expense of an eve= n worse delay. The fourth mechanism is not so interesting as it increases b= andwidth overhead to achieve only a very small reduction of CPU. I think that "sign-all" and "merkle trees" are both good candidates, as the= re is a CPU/delay trade-off:=20 2.a) sign-all: better delay, worse CPU complexity 2.b) merkle-trees: better CPU complexity, worse delay Since sign-all is *significantly simpler to implement* that Merkle-trees, a= nd the group seemed headed towards making merkle-trees mandatory anyway, I = would suggest making support for both mandatory, thus supporting low-delay = applications. Cheers, Fabio [1] Pollution in P2P Live Video Streaming, by Prithula Dhungel, Xiaojun Hei= , Keith W. Ross1 and Nitesh Saxena. > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Picconi Fabio > Sent: lundi 23 janvier 2012 14:07 > To: arno@cs.vu.nl; ppsp > Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 >=20 >=20 > > -----Original Message----- > > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf > Of > > Arno Bakker > > Sent: lundi 23 janvier 2012 09:51 > > To: ppsp > > Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 > > > > On 19/01/2012 15:12, Picconi Fabio wrote: > > > Hi, and happy new 2012! > > > > > > The Content Addressing part looks good. > > > > > > As for the Content Integrity part, in the HINT message I would > rather > > > use a "chunk specification" instead of a "node specification", to > > > make it generic and thus consistent with the Content Addressing > data > > > types. > > > > > > > Hi > > > > I used a different name to convey that the chunk addressing needs > > "room" > > for node IDs if Merkle trees are used. So you propose not to use this > > textual trick, and just write down the requirement? >=20 >=20 > I meant that "node specification" sounds Merkle-specific, whereas > "chunk specification" sounds more generic. In the case of Merkle trees, > the chunk specification would consist of a node specification. >=20 >=20 > > > This defines the messages and data types. The question that remains > > > is *when* the HASH messages must be transmitted, as this may depend > > > on the specific integrity mechanism. > > > > > > > What do you mean exactly? The idea is that the HASH message is tied > to > > the Merkle hash trees, so if you chose that scheme you'll have HASH > > messages. Or do you want to have a generic HASH message that can also > > be > > used by other integrity protection schemes? >=20 > What I had in mind is a generic HASH message that can be used by other > mechanisms. It probably makes more sense to call it INTEGRITY (or > something like that) rather than HASH. >=20 > Fabio > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From zhangyunfei@chinamobile.com Thu Mar 29 07:13: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 E1D6E21F88D3 for ; Thu, 29 Mar 2012 07:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.116 X-Spam-Level: X-Spam-Status: No, score=-98.116 tagged_above=-999 required=5 tests=[AWL=0.507, 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 EVzIgdVywzZ5 for ; Thu, 29 Mar 2012 07:13:04 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BAC1E21E8137 for ; Thu, 29 Mar 2012 07:12:39 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 54B50E3D4; Thu, 29 Mar 2012 22:12:28 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 47769E3C4; Thu, 29 Mar 2012 22:12:28 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012032922122405-21533 ; Thu, 29 Mar 2012 22:12:24 +0800 Date: Thu, 29 Mar 2012 22:12:12 +0800 From: zhangyunfei To: "Picconi Fabio" , "arno@cs.vu.nl" , ppsp References: <4F16A1EF.4060501@cs.vu.nl> <320C4182454E96478DC039F2C481987204A4D07528@MOPESMBX01.eu.thmulti.com> <4F1D1F72.5040801@cs.vu.nl> <320C4182454E96478DC039F2C481987204C4170C2C@MOPESMBX01.eu.thmulti.com>, <320C4182454E96478DC039F2C481987204CCDC1870@MOPESMBX01.eu.thmulti.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012032922083877821549@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-29 22:12:25, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-29 22:12:28, Serialize complete at 2012-03-29 22:12:28 Content-Type: multipart/alternative; boundary="----=_001_NextPart035668432764_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18804.007 X-TM-AS-Result: No--34.384-7.0-31-10 X-imss-scan-details: No--34.384-7.0-31-10;No--34.384-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:13:05 -0000 This is a multi-part message in MIME format. ------=_001_NextPart035668432764_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgRmFiaW8sDQogICAgRm9yIHBvaW50MSwrMS4oU3BlYWtpbmcgaW5kaXZpZHVhbGx5KQ0KICAg IEZvciBwb2ludCAyLCBJIGZhaWwgdG8gZG93bmxvYWQgdGhlIHJlZmVyZW5jZSBwYXBlci4gQ2Fu IHlvdSBzYXkgbW9yZSB3b3JkcyBhYm91dCAic2lnbi1hbGwiPyBBbmQgaXMgdGhlcmUgcG9zc2li bGUgdGhhdCB3ZSBoYXZlIGEgd2F5IHRvIGJhbGFuY2UgYncgc2lnbi1hbGwgYW5kIG1lcmtsZSB0 cmVlPyBJdCB3b3VsZCBiZSBncmVhdCBpZiB3ZSBjYW4gZ2V0IHRoYXQuDQoNCkJSDQpZdW5mZWkN Cg0KDQoNCg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogUGljY29uaSBGYWJpbw0KRGF0ZTogMjAxMi0w My0yOSAyMDo1Ng0KVG86IGFybm9AY3MudnUubmw7IHBwc3ANClN1YmplY3Q6IFJlOiBbcHBzcF0g UHJvcG9zYWwgdG8gcmVzb2x2ZSBJc3N1ZSAxMCArIDEzDQpIaSwNCg0KU28sIGEgZm9sbG93LXVw IG9mIHdoYXQgSSBzYWlkIGR1cmluZyB0aGUgUGFyaXMgbWVldGluZzoNCg0KMSkgUmVnYXJkaW5n IHRoZSBjb250ZW50IGFkZHJlc3NpbmcgbWVjaGFuaXNtLCBJIHRoaW5rIHRoZSBtYW5kYXRvcnkg c29sdXRpb24gc2hvdWxkIGJlIG9uZSB3aGljaCBpcyBhcyBzaW1wbGUgYXMgcG9zc2libGUgd2l0 aG91dCBjb21wcm9taXNpbmcgZWZmaWNpZW5jeS4gQmV0d2VlbiBiaW4gbnVtYmVyaW5nIGFuZCB0 aGUgc2ltcGxlciBsaXN0IG9mIHJhbmdlcyAoZS5nLiwgcnVuLWxlbmd0aC1zdHlsZSBlbmNvZGlu ZyksIEkgd291bGQgY2hvc2UgdGhlIHNlY29uZCBzaW5jZSBpbXBsZW1lbnRpbmcgaXQgdGFrZXMg NSBsaW5lcyBvZiBjb2RlIGFuZCB0aGUgYmFuZHdpZHRoIG92ZXJoZWFkIHNob3VsZCBiZSBxdWl0 ZSByZWFzb25hYmxlLiBTbyBJIHdvdWxkIG1ha2UgYmluIG51bWJlcmluZyBvcHRpb25hbCwgdW5s ZXNzIHlvdSBzaG93IHRoYXQgdGhlIGJhbmR3aWR0aCBnYWluIGlzIHNpZ25pZmljYW50Lg0KDQoy KSBSZWdhcmRpbmcgaW50ZWdyaXR5IGNoZWNraW5nLCBzb21lYm9keSBtZW50aW9uZWQgdGhhdCBm b3JjaW5nIGltcGxlbWVudGVycyB0byBzdXBwb3J0IGEgZmVhdHVyZSBkb2VzIG5vdCBtZWFuIHlv dSBoYXZlIHRvIHVzZSBpdCBpbiBhIGdpdmVuIGRlcGxveW1lbnQuIEkgdGhpbmsgdGhhdCBzaG91 bGQgYmUgdGhlIGNhc2UgZm9yIGludGVncml0eSBjaGVja2luZy4gTm93LCBpZiBpbnRlZ3JpdHkg Y2hlY2tpbmcgaXMgbWFuZGF0b3J5LCB3ZSBoYXZlIHRvIGNob3NlIGFuIGludGVncml0eSBtZWNo YW5pc20uDQoNClBhcGVyIFsxXSBnaXZlcyBhIG5pY2UgY29tcGFyaXNvbiBvZiBmb3VyIGRpZmZl cmVudCBtZWNoYW5pc21zLCBhbmQgdGhlIHRyYWRlLW9mZnMgYmV0d2VlbiBDUFUgY29tcGxleGl0 eSwgYmFuZHdpZHRoLCBhbmQgZGVsYXkuDQoNCiJTaWduLWFsbCIgaGFzIHRoZSBiZXN0IGRlbGF5 IGJ1dCB3b3JzdCBDUFUgY29tcGxleGl0eSwgIk1lcmtsZSB0cmVlcyIgaGFzIGJldHRlciBDUFUg Y29tcGxleGl0eSBhdCB0aGUgZXhwZW5zZSBvZiB3b3JzZSBkZWxheSwgYW5kICJzaWduLWFuZC1j b3JyZWN0IiBoYXMgYmV0dGVyIGJhbmR3aWR0aCBlZmZpY2llbmN5IHRoYW4gTWVya2xlIHRyZWVz IGF0IHRoZSBleHBlbnNlIG9mIGFuIGV2ZW4gd29yc2UgZGVsYXkuIFRoZSBmb3VydGggbWVjaGFu aXNtIGlzIG5vdCBzbyBpbnRlcmVzdGluZyBhcyBpdCBpbmNyZWFzZXMgYmFuZHdpZHRoIG92ZXJo ZWFkIHRvIGFjaGlldmUgb25seSBhIHZlcnkgc21hbGwgcmVkdWN0aW9uIG9mIENQVS4NCg0KSSB0 aGluayB0aGF0ICJzaWduLWFsbCIgYW5kICJtZXJrbGUgdHJlZXMiIGFyZSBib3RoIGdvb2QgY2Fu ZGlkYXRlcywgYXMgdGhlcmUgaXMgYSBDUFUvZGVsYXkgdHJhZGUtb2ZmOiANCg0KMi5hKSBzaWdu LWFsbDogYmV0dGVyIGRlbGF5LCB3b3JzZSBDUFUgY29tcGxleGl0eQ0KMi5iKSBtZXJrbGUtdHJl ZXM6IGJldHRlciBDUFUgY29tcGxleGl0eSwgd29yc2UgZGVsYXkNCg0KU2luY2Ugc2lnbi1hbGwg aXMgKnNpZ25pZmljYW50bHkgc2ltcGxlciB0byBpbXBsZW1lbnQqIHRoYXQgTWVya2xlLXRyZWVz LCBhbmQgdGhlIGdyb3VwIHNlZW1lZCBoZWFkZWQgdG93YXJkcyBtYWtpbmcgbWVya2xlLXRyZWVz IG1hbmRhdG9yeSBhbnl3YXksIEkgd291bGQgc3VnZ2VzdCBtYWtpbmcgc3VwcG9ydCBmb3IgYm90 aCBtYW5kYXRvcnksIHRodXMgc3VwcG9ydGluZyBsb3ctZGVsYXkgYXBwbGljYXRpb25zLg0KDQpD aGVlcnMsDQoNCkZhYmlvDQoNClsxXSBQb2xsdXRpb24gaW4gUDJQIExpdmUgVmlkZW8gU3RyZWFt aW5nLCBieSBQcml0aHVsYSBEaHVuZ2VsLCBYaWFvanVuIEhlaSwgS2VpdGggVy4gUm9zczEgYW5k IE5pdGVzaCBTYXhlbmEuDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBwcHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZg0KPiBQaWNjb25pIEZhYmlvDQo+IFNlbnQ6IGx1bmRpIDIzIGphbnZpZXIgMjAx MiAxNDowNw0KPiBUbzogYXJub0Bjcy52dS5ubDsgcHBzcA0KPiBTdWJqZWN0OiBSZTogW3Bwc3Bd IFByb3Bvc2FsIHRvIHJlc29sdmUgSXNzdWUgMTAgKyAxMw0KPiANCj4gDQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBwcHNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpwcHNwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+IEFybm8gQmFra2Vy DQo+ID4gU2VudDogbHVuZGkgMjMgamFudmllciAyMDEyIDA5OjUxDQo+ID4gVG86IHBwc3ANCj4g PiBTdWJqZWN0OiBSZTogW3Bwc3BdIFByb3Bvc2FsIHRvIHJlc29sdmUgSXNzdWUgMTAgKyAxMw0K PiA+DQo+ID4gT24gMTkvMDEvMjAxMiAxNToxMiwgUGljY29uaSBGYWJpbyB3cm90ZToNCj4gPiA+ IEhpLCBhbmQgaGFwcHkgbmV3IDIwMTIhDQo+ID4gPg0KPiA+ID4gVGhlIENvbnRlbnQgQWRkcmVz c2luZyBwYXJ0IGxvb2tzIGdvb2QuDQo+ID4gPg0KPiA+ID4gQXMgZm9yIHRoZSBDb250ZW50IElu dGVncml0eSBwYXJ0LCBpbiB0aGUgSElOVCBtZXNzYWdlIEkgd291bGQNCj4gcmF0aGVyDQo+ID4g PiB1c2UgYSAiY2h1bmsgc3BlY2lmaWNhdGlvbiIgaW5zdGVhZCBvZiBhICJub2RlIHNwZWNpZmlj YXRpb24iLCB0bw0KPiA+ID4gbWFrZSBpdCBnZW5lcmljIGFuZCB0aHVzIGNvbnNpc3RlbnQgd2l0 aCB0aGUgQ29udGVudCBBZGRyZXNzaW5nDQo+IGRhdGENCj4gPiA+IHR5cGVzLg0KPiA+ID4NCj4g Pg0KPiA+IEhpDQo+ID4NCj4gPiBJIHVzZWQgYSBkaWZmZXJlbnQgbmFtZSB0byBjb252ZXkgdGhh dCB0aGUgY2h1bmsgYWRkcmVzc2luZyBuZWVkcw0KPiA+ICJyb29tIg0KPiA+IGZvciBub2RlIElE cyBpZiBNZXJrbGUgdHJlZXMgYXJlIHVzZWQuIFNvIHlvdSBwcm9wb3NlIG5vdCB0byB1c2UgdGhp cw0KPiA+IHRleHR1YWwgdHJpY2ssIGFuZCBqdXN0IHdyaXRlIGRvd24gdGhlIHJlcXVpcmVtZW50 Pw0KPiANCj4gDQo+IEkgbWVhbnQgdGhhdCAibm9kZSBzcGVjaWZpY2F0aW9uIiBzb3VuZHMgTWVy a2xlLXNwZWNpZmljLCB3aGVyZWFzDQo+ICJjaHVuayBzcGVjaWZpY2F0aW9uIiBzb3VuZHMgbW9y ZSBnZW5lcmljLiBJbiB0aGUgY2FzZSBvZiBNZXJrbGUgdHJlZXMsDQo+IHRoZSBjaHVuayBzcGVj aWZpY2F0aW9uIHdvdWxkIGNvbnNpc3Qgb2YgYSBub2RlIHNwZWNpZmljYXRpb24uDQo+IA0KPiAN Cj4gPiA+IFRoaXMgZGVmaW5lcyB0aGUgbWVzc2FnZXMgYW5kIGRhdGEgdHlwZXMuIFRoZSBxdWVz dGlvbiB0aGF0IHJlbWFpbnMNCj4gPiA+IGlzICp3aGVuKiB0aGUgSEFTSCBtZXNzYWdlcyBtdXN0 IGJlIHRyYW5zbWl0dGVkLCBhcyB0aGlzIG1heSBkZXBlbmQNCj4gPiA+IG9uIHRoZSBzcGVjaWZp YyBpbnRlZ3JpdHkgbWVjaGFuaXNtLg0KPiA+ID4NCj4gPg0KPiA+IFdoYXQgZG8geW91IG1lYW4g ZXhhY3RseT8gVGhlIGlkZWEgaXMgdGhhdCB0aGUgSEFTSCBtZXNzYWdlIGlzIHRpZWQNCj4gdG8N Cj4gPiB0aGUgTWVya2xlIGhhc2ggdHJlZXMsIHNvIGlmIHlvdSBjaG9zZSB0aGF0IHNjaGVtZSB5 b3UnbGwgaGF2ZSBIQVNIDQo+ID4gbWVzc2FnZXMuIE9yIGRvIHlvdSB3YW50IHRvIGhhdmUgYSBn ZW5lcmljIEhBU0ggbWVzc2FnZSB0aGF0IGNhbiBhbHNvDQo+ID4gYmUNCj4gPiB1c2VkIGJ5IG90 aGVyIGludGVncml0eSBwcm90ZWN0aW9uIHNjaGVtZXM/DQo+IA0KPiBXaGF0IEkgaGFkIGluIG1p bmQgaXMgYSBnZW5lcmljIEhBU0ggbWVzc2FnZSB0aGF0IGNhbiBiZSB1c2VkIGJ5IG90aGVyDQo+ IG1lY2hhbmlzbXMuIEl0IHByb2JhYmx5IG1ha2VzIG1vcmUgc2Vuc2UgdG8gY2FsbCBpdCBJTlRF R1JJVFkgKG9yDQo+IHNvbWV0aGluZyBsaWtlIHRoYXQpIHJhdGhlciB0aGFuIEhBU0guDQo+IA0K PiBGYWJpbw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBwcHNwIG1haWxpbmcgbGlzdA0KPiBwcHNwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnBwc3AgbWFpbGluZyBsaXN0DQpwcHNwQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bwc3A= ------=_001_NextPart035668432764_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Fabio,
    For point1,+1.(Speaking individually)
    For point 2, I fail to download the reference pape= r. Can=20 you say more words about "sign-all"? And is there possible that we have a = way to=20 balance bw sign-all and merkle tree? It would be great if we can get that.=
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-03-29 20:56
To: arno@cs.vu.nl; <= A=20 href=3D"mailto:ppsp@ietf.org">ppsp
Subject: Re: [ppsp] Proposal to resolve Issue 10 +=20 13
Hi,
 
So, a follow-up of what I said dur= ing the Paris meeting:
 
1) Regarding the content addressing mechanis= m, I think the mandatory solution should&nbs= p;be one which is as simple as possible=  without compromising efficiency. Between bin&nbs= p;numbering and the simpler list of ranges&n= bsp;(e.g., run-length-style encoding), I would ch= ose the second since implementing it takes&n= bsp;5 lines of code and the bandwidth o= verhead should be quite reasonable. So I&nbs= p;would make bin numbering optional, unless = you show that the bandwidth gain is sig= nificant.
 
2) Regarding integrity checking, somebody me= ntioned that forcing implementers to support = ;a feature does not mean you have to&nb= sp;use it in a given deployment. I thin= k that should be the case for integrity=  checking. Now, if integrity checking is&nbs= p;mandatory, we have to chose an integrity&n= bsp;mechanism.
 
Paper [1] gives a nice comparison of&nb= sp;four different mechanisms, and the trade-offs&= nbsp;between CPU complexity, bandwidth, and delay= .
 
"Sign-all" has the best delay but worst=  CPU complexity, "Merkle trees" has better&n= bsp;CPU complexity at the expense of worse&n= bsp;delay, and "sign-and-correct" has better band= width efficiency than Merkle trees at the&nb= sp;expense of an even worse delay. The = fourth mechanism is not so interesting as&nb= sp;it increases bandwidth overhead to achieve&nbs= p;only a very small reduction of CPU.
 
I think that "sign-all" and "merkle tre= es" are both good candidates, as there = is a CPU/delay trade-off: 
 
2.a) sign-all: better delay, worse CPU = complexity
2.b) merkle-trees: better CPU complexity, wo= rse delay
 
Since sign-all is *significantly simpler to&= nbsp;implement* that Merkle-trees, and the group&= nbsp;seemed headed towards making merkle-trees ma= ndatory anyway, I would suggest making suppo= rt for both mandatory, thus supporting low-d= elay applications.
 
Cheers,
 
Fabio
 
[1] Pollution in P2P Live Video Streami= ng, by Prithula Dhungel, Xiaojun Hei, Keith&= nbsp;W. Ross1 and Nitesh Saxena.
 
 
> -----Original Message-----
> From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@= ietf.org] On Behalf Of
> Picconi Fabio
> Sent: lundi 23 janvier 2012 14:07<= /DIV>
> To: arno@cs.vu.nl; ppsp
> Subject: Re: [ppsp] Proposal to re= solve Issue 10 + 13
> 
> 
> > -----Original Message-----
> > From: ppsp-bounces@ietf.org [mailto:pps= p-bounces@ietf.org] On Behalf
> Of
> > Arno Bakker
> > Sent: lundi 23 janvier 2012&n= bsp;09:51
> > To: ppsp
> > Subject: Re: [ppsp] Proposal = to resolve Issue 10 + 13
> >
> > On 19/01/2012 15:12, Picconi = Fabio wrote:
> > > Hi, and happy new 2= 012!
> > >
> > > The Content Addressing p= art looks good.
> > >
> > > As for the Content = Integrity part, in the HINT message I w= ould
> rather
> > > use a "chunk specificati= on" instead of a "node specification", to
> > > make it generic and = ;thus consistent with the Content Addressing
> data
> > > types.
> > >
> >
> > Hi
> >
> > I used a different name = to convey that the chunk addressing needs
> > "room"
> > for node IDs if Merkle t= rees are used. So you propose not to&nb= sp;use this
> > textual trick, and just write=  down the requirement?
> 
> 
> I meant that "node specification" = sounds Merkle-specific, whereas
> "chunk specification" sounds more gener= ic. In the case of Merkle trees,
> the chunk specification would consist&n= bsp;of a node specification.
> 
> 
> > > This defines the message= s and data types. The question that rem= ains
> > > is *when* the HASH = messages must be transmitted, as this may&nb= sp;depend
> > > on the specific integrit= y mechanism.
> > >
> >
> > What do you mean exactly?&nbs= p;The idea is that the HASH message is&= nbsp;tied
> to
> > the Merkle hash trees, so&nbs= p;if you chose that scheme you'll have = HASH
> > messages. Or do you want = ;to have a generic HASH message that ca= n also
> > be
> > used by other integrity prote= ction schemes?
> 
> What I had in mind is a = generic HASH message that can be used b= y other
> mechanisms. It probably makes more = ;sense to call it INTEGRITY (or
> something like that) rather than H= ASH.
> 
> Fabio
> _______________________________________________
> 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
------=_001_NextPart035668432764_=------ From Fabio.Picconi@technicolor.com Thu Mar 29 07:26: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 B894521E81B0 for ; Thu, 29 Mar 2012 07:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdTBoYpwI9+4 for ; Thu, 29 Mar 2012 07:26:46 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id C685021E80B2 for ; Thu, 29 Mar 2012 07:26:32 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKT3RxF1NpasR1ZzpfHE/k+3fVRiWFuzLh@postini.com; Thu, 29 Mar 2012 07:26:37 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 29 Mar 2012 16:22:50 +0200 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 29 Mar 2012 16:23:06 +0200 From: Picconi Fabio To: zhangyunfei , "arno@cs.vu.nl" , ppsp Date: Thu, 29 Mar 2012 16:23:05 +0200 Thread-Topic: Re: [ppsp] Proposal to resolve Issue 10 + 13 Thread-Index: Ac0NtfxgIou93EfkSEi24/Bkvy/AfQAAMqpA Message-ID: <320C4182454E96478DC039F2C481987204CCDC1B7F@MOPESMBX01.eu.thmulti.com> References: <4F16A1EF.4060501@cs.vu.nl> <320C4182454E96478DC039F2C481987204A4D07528@MOPESMBX01.eu.thmulti.com> <4F1D1F72.5040801@cs.vu.nl> <320C4182454E96478DC039F2C481987204C4170C2C@MOPESMBX01.eu.thmulti.com>, <320C4182454E96478DC039F2C481987204CCDC1870@MOPESMBX01.eu.thmulti.com> <2012032922083877821549@chinamobile.com> In-Reply-To: <2012032922083877821549@chinamobile.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_320C4182454E96478DC039F2C481987204CCDC1B7FMOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:26:50 -0000 --_000_320C4182454E96478DC039F2C481987204CCDC1B7FMOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yunfei, Here's the link to the paper : http://cis.poly.edu/~ross/papers/pollutionSt= reaming.pdf The "sign-all" means that the source signs every chunk and appends the sign= ature to the chunk contents. It's costly in CPU terms, but incurs no delay. Fabio From: zhangyunfei [mailto:zhangyunfei@chinamobile.com] Sent: jeudi 29 mars 2012 16:12 To: Picconi Fabio; arno@cs.vu.nl; ppsp Subject: Re: Re: [ppsp] Proposal to resolve Issue 10 + 13 Hi Fabio, For point1,+1.(Speaking individually) For point 2, I fail to download the reference paper. Can you say more w= ords about "sign-all"? And is there possible that we have a way to balance = bw sign-all and merkle tree? It would be great if we can get that. BR Yunfei ________________________________ zhangyunfei From: Picconi Fabio Date: 2012-03-29 20:56 To: arno@cs.vu.nl; ppsp Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 Hi, So, a follow-up of what I said during the Paris meeting: 1) Regarding the content addressing mechanism, I think the mandatory soluti= on should be one which is as simple as possible without compromising effici= ency. Between bin numbering and the simpler list of ranges (e.g., run-lengt= h-style encoding), I would chose the second since implementing it takes 5 l= ines of code and the bandwidth overhead should be quite reasonable. So I wo= uld make bin numbering optional, unless you show that the bandwidth gain is= significant. 2) Regarding integrity checking, somebody mentioned that forcing implemente= rs to support a feature does not mean you have to use it in a given deploym= ent. I think that should be the case for integrity checking. Now, if integr= ity checking is mandatory, we have to chose an integrity mechanism. Paper [1] gives a nice comparison of four different mechanisms, and the tra= de-offs between CPU complexity, bandwidth, and delay. "Sign-all" has the best delay but worst CPU complexity, "Merkle trees" has = better CPU complexity at the expense of worse delay, and "sign-and-correct"= has better bandwidth efficiency than Merkle trees at the expense of an eve= n worse delay. The fourth mechanism is not so interesting as it increases b= andwidth overhead to achieve only a very small reduction of CPU. I think that "sign-all" and "merkle trees" are both good candidates, as the= re is a CPU/delay trade-off: 2.a) sign-all: better delay, worse CPU complexity 2.b) merkle-trees: better CPU complexity, worse delay Since sign-all is *significantly simpler to implement* that Merkle-trees, a= nd the group seemed headed towards making merkle-trees mandatory anyway, I = would suggest making support for both mandatory, thus supporting low-delay = applications. Cheers, Fabio [1] Pollution in P2P Live Video Streaming, by Prithula Dhungel, Xiaojun Hei= , Keith W. Ross1 and Nitesh Saxena. > -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Picconi Fabio > Sent: lundi 23 janvier 2012 14:07 > To: arno@cs.vu.nl; ppsp > Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 > > > > -----Original Message----- > > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf > Of > > Arno Bakker > > Sent: lundi 23 janvier 2012 09:51 > > To: ppsp > > Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13 > > > > On 19/01/2012 15:12, Picconi Fabio wrote: > > > Hi, and happy new 2012! > > > > > > The Content Addressing part looks good. > > > > > > As for the Content Integrity part, in the HINT message I would > rather > > > use a "chunk specification" instead of a "node specification", to > > > make it generic and thus consistent with the Content Addressing > data > > > types. > > > > > > > Hi > > > > I used a different name to convey that the chunk addressing needs > > "room" > > for node IDs if Merkle trees are used. So you propose not to use this > > textual trick, and just write down the requirement? > > > I meant that "node specification" sounds Merkle-specific, whereas > "chunk specification" sounds more generic. In the case of Merkle trees, > the chunk specification would consist of a node specification. > > > > > This defines the messages and data types. The question that remains > > > is *when* the HASH messages must be transmitted, as this may depend > > > on the specific integrity mechanism. > > > > > > > What do you mean exactly? The idea is that the HASH message is tied > to > > the Merkle hash trees, so if you chose that scheme you'll have HASH > > messages. Or do you want to have a generic HASH message that can also > > be > > used by other integrity protection schemes? > > What I had in mind is a generic HASH message that can be used by other > mechanisms. It probably makes more sense to call it INTEGRITY (or > something like that) rather than HASH. > > Fabio > _______________________________________________ > 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_320C4182454E96478DC039F2C481987204CCDC1B7FMOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yunfei,

Here’s the link to the paper : http://cis= .poly.edu/~ross/papers/pollutionStreaming.pdf

The “sign-all” means that the source signs every= chunk and appends the signature to the chunk contents. It’s costly in CPU terms, but in= curs no delay.

Fabio

 

From: zhangyunfei [mailto:zhangyunfei@chinamobile.com]
Sent: jeudi 29 mars 2012 16:12
To: Picconi Fabio; arno@cs.vu.nl; ppsp
Subject: Re: Re: [ppsp] Proposal to resolve Issue 10 + 13=

 

Hi Fabio,

    For point1,+1.(Speaking individually)

    For point 2, I fail to download the reference paper. Can you say more words abo= ut "sign-all"? And is there possible that we have a way to balance b= w sign-all and merkle tree? It would be great if we can get that.<= /span>

 

BR

Yunfei

 

zhangyunfei

 

From: Picconi Fabio<= /span>

Date: 2012-03-29 20:56

Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13

Hi,

 

So, a follow-up of what I said during the Paris meeting:

 

1) Regarding the content addressing mechanism, I think the mandatory solution should be one which is as simple as possible without compromising efficiency. Between bin numbering and the simpler list of ranges (e.g., run-length-style encoding), I would chose the second since implementing it takes 5 lines of code and the bandwidth overhead should be quite reasonable. So I would make bin numbering optional, unless you show that the bandwidth gain is significant.

 

2) Regarding integrity checking, somebody mentioned that forcing implementers to support a feature does not mean you have to use it in a given deployment. I think that should be the case for integrity checking. Now, if integrity checking is mandatory, we have to chose an integrity mechanism.

 

Paper [1] gives a nice comparison of four different mechanisms, and the trade-offs between CPU complexity, bandwidth, and delay.

 

"Sign-all" has the best delay but worst CPU complexity, "Merkle trees" has better CPU complexity at the expense of worse delay, and "sign-and-correct" has better bandwidth efficiency than Merkle trees at the expense of an even worse delay. The fourth mechanism is not so interesting as it increases bandwidth overhead to achieve only a very small reduction of CPU.

 

I think that "sign-all" and "merkle trees" are both good candidates, as there is a CPU/delay trade-off: 

 

2.a) sign-all: better delay, worse CPU complexity

2.b) merkle-trees: better CPU complexity, worse delay

 

Since sign-all is *significantly simpler to implement* that Merkle-trees, and the group seemed headed towards making merkle-trees mandatory anyway, I would suggest making support for both mandatory, thus supporting low-delay applications.

 

Cheers,

 

Fabio

 

[1] Pollution in P2P Live Video Streaming, by Prithula Dhungel, Xiaojun Hei, Keith W. Ross1 and Nitesh Saxena.

 

 

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

> From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of

> Picconi Fabio

> Sent: lundi 23 janvier 2012 14:07

> To: arno@cs.vu.nl; ppsp

> Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13

> 

> 

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

> > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf

> Of

> > Arno Bakker

> > Sent: lundi 23 janvier 2012 09:51

> > To: ppsp

> > Subject: Re: [ppsp] Proposal to resolve Issue 10 + 13

> >

> > On 19/01/2012 15:12, Picconi Fabio wrote:

> > > Hi, and happy new 2012!

> > >

> > > The Content Addressing part looks good.

> > >

> > > As for the Content Integrity part, in the HINT message I would

> rather

> > > use a "chunk specification" instead of a "node specification", to

> > > make it generic and thus consistent with the Content Addressing

> data

> > > types.

> > >

> >

> > Hi

> >

> > I used a different name to convey that the chunk addressing needs

> > "room"

> > for node IDs if Merkle trees are used. So you propose not to use this

> > textual trick, and just write down the requirement?

> 

> 

> I meant that "node specification" sounds Merkle-specific, whereas

> "chunk specification" sounds more generic. In the case of Merkle trees,

> the chunk specification would consist of a node specification.

> 

> 

> > > This defines the messages and data types. The question that remains

> > > is *when* the HASH messages must be transmitted, as this may depend

> > > on the specific integrity mechanism.

> > >

> >

> > What do you mean exactly? The idea is that the HASH message is tied

> to

> > the Merkle hash trees, so if you chose that scheme you'll have HASH

> > messages. Or do you want to have a generic HASH message that can also

> > be

> > used by other integrity protection schemes?

> 

> What I had in mind is a generic HASH message that can be used by other

> mechanisms. It probably makes more sense to call it INTEGRITY (or

> something like that) rather than HASH.

> 

> Fabio

> _______________________________________________

> 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_320C4182454E96478DC039F2C481987204CCDC1B7FMOPESMBX01eut_-- From zhangyunfei@chinamobile.com Fri Mar 30 01:53: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 B08C221F88A6 for ; Fri, 30 Mar 2012 01:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.793 X-Spam-Level: X-Spam-Status: No, score=-95.793 tagged_above=-999 required=5 tests=[AWL=-1.854, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_63=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 jxHdzirQ-bsO for ; Fri, 30 Mar 2012 01:53:27 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 302A321F8851 for ; Fri, 30 Mar 2012 01:53:27 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id D36E8E679 for ; Fri, 30 Mar 2012 16:53:24 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id AFBECE3BA for ; Fri, 30 Mar 2012 16:53:24 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012033016532175-14943 ; Fri, 30 Mar 2012 16:53:21 +0800 Date: Fri, 30 Mar 2012 16:53:02 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012033016511639412036@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-30 16:53:22, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-30 16:53:24, Serialize complete at 2012-03-30 16:53:24 Content-Type: multipart/alternative; boundary="----=_001_NextPart801765336753_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18806.006 X-TM-AS-Result: No--14.806-7.0-31-10 X-imss-scan-details: No--14.806-7.0-31-10;No--14.806-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] re-charter issue discussion(cont'):transport mechanism 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, 30 Mar 2012 08:53:29 -0000 This is a multi-part message in MIME format. ------=_001_NextPart801765336753_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgYWxsLA0KICAgICBUbyBjb250aW51ZSB0aGUgcmUtY2hhcnRlciBkaXNjdXNzaW9uIGluIFBQ U1AgV0cgbWVldGluZywgSSB3b3VsZCBsaWtlIHRvIGRpc2N1c3MgbW9yZSBvbiB0aGUgdHJhbnNw b3J0IG1lY2hhbmlzbSBpc3N1ZS4NCiAgICAgSSBoYXBwZW4gdG8ga25vdyBpbiBSVENXZWIsIHRo ZSB0cmFuc3BvcnQgcHJvdG9jb2wgYmV0d2VlbiB0d28gcGVlciBicm93c2VycyBzZWVtcyB0byBi ZWVuIGRlY2lkZWQ6IEZvciBtZWRpYSBwYXJ0LCBzcnRwL3J0cCBvdmVyIFVEUChJIGFtIG5vdCBx dWl0ZSBzdXJlIG9mIGlmIGl0IGlzIGFjY3VyYXRlKS4gIEZvciBkYXRhIHRyYW5zbWl0LCBEYXRh Z3JhbXMgb3ZlciBTQ1RQIG92ZXIgRFRMUyBvdmVyIFVEUC4NCiAgICAgICBNeSBxdWVzdGlvbiBp czogSWYgdGhpcyByZWxhdGVkIHRvIFBQU1AgdHJhbnNwb3J0IG1lY2hhbmlzbT8gT3IgdG90YWxs eSB0d28gZGlmZmVyZW50IHRoaW5ncz9BbnkgZGlmZmVyZW50IHJlcXVpcmVtZW50cz8gSnVzdCB0 byBwcm92aWRlIHN1Y2ggaW5mbyB0byBpbmN1ciBkaXNjdXNzaW9uLg0KICAgICANCg0KQlINCll1 bmZlaQ0KDQoNCg0KDQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart801765336753_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi all,
     To continue t= he=20 re-charter discussion in PPSP WG meeting, I would like to discuss more on = the=20 transport mechanism issue.
     I happen to know i= n=20 RTCWeb, the transport protocol between two peer browsers seems to&nbs= p;been=20 decided: For media part, srtp/rtp over UDP(I am not quite sure of if it is= =20 accurate).  For data transmit, Datagrams over SCTP over= DTLS over=20 UDP.
       My quest= ion is: If this related to=20 PPSP transport mechanism? Or totally two different things?Any different=20 requirements? Just to provide such info to incur=20 discussion.
    
 
BR
Yunfei
 
 
zhangyunfei
------=_001_NextPart801765336753_=------ From zongning@huawei.com Fri Mar 30 02:52: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 1076721F8718 for ; Fri, 30 Mar 2012 02:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.557 X-Spam-Level: X-Spam-Status: No, score=-101.557 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_63=0.6, 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 t8eLpn+uk2eu for ; Fri, 30 Mar 2012 02:52:23 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 78E0D21F86E2 for ; Fri, 30 Mar 2012 02:52:23 -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 AEU96457; Fri, 30 Mar 2012 05:52:23 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 02:50:32 -0700 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 30 Mar 2012 02:49:40 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.151]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 17:50:25 +0800 From: ZongNing To: zhangyunfei , ppsp Thread-Topic: [ppsp] re-charter issue discussion(cont'):transport mechanism Thread-Index: AQHNDlLZRNbftRumhUes4L3O5m7lA5aClEKw Date: Fri, 30 Mar 2012 09:50:24 +0000 Message-ID: References: <2012033016511639412036@chinamobile.com> In-Reply-To: <2012033016511639412036@chinamobile.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: multipart/alternative; boundary="_000_B0D29E0424F2DE47A0B36779EC66677916CE724Cszxeml504mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [ppsp] re-charter issue discussion(cont'):transport mechanism 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, 30 Mar 2012 09:52:24 -0000 --_000_B0D29E0424F2DE47A0B36779EC66677916CE724Cszxeml504mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Yunfei, I think it is related if RTCWeb includes the scenario of one browser stream= ing video to others by using P2P way. Also start discussing P2P use case in RTCWeb (or discussing web-brower usag= e in PPSP) might be interesting. -Ning ________________________________ From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on behalf of zhangyunfe= i [zhangyunfei@chinamobile.com] Sent: Friday, March 30, 2012 4:53 PM To: ppsp Subject: [ppsp] re-charter issue discussion(cont'):transport mechanism Hi all, To continue the re-charter discussion in PPSP WG meeting, I would like= to discuss more on the transport mechanism issue. I happen to know in RTCWeb, the transport protocol between two peer br= owsers seems to been decided: For media part, srtp/rtp over UDP(I am not qu= ite sure of if it is accurate). For data transmit, Datagrams over SCTP ove= r DTLS over UDP. My question is: If this related to PPSP transport mechanism? Or tota= lly two different things?Any different requirements? Just to provide such i= nfo to incur discussion. BR Yunfei ________________________________ zhangyunfei --_000_B0D29E0424F2DE47A0B36779EC66677916CE724Cszxeml504mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, Yunfei,

 

I think it is related if RTCWeb includes the scenario of one browse= r streaming video to others by using P2P way.

Also start discussing P2P use case in RTCWeb (or discussing web-brower u= sage in PPSP) might be interesting.

 

-Ning

 

From: ppsp-bounces@ietf.org [ppsp-bounces@= ietf.org] on behalf of zhangyunfei [zhangyunfei@chinamobile.com]
Sent: Friday, March 30, 2012 4:53 PM
To: ppsp
Subject: [ppsp] re-charter issue discussion(cont'):transport mechani= sm

Hi all,
     To continue th= e re-charter discussion in PPSP WG meeting, I would like to discuss more on= the transport mechanism issue.
     I happen to know in= RTCWeb, the transport protocol between two peer browsers seems to&nbs= p;been decided: For media part, srtp/rtp over UDP(I am not quite sure of if= it is accurate).  For data transmit, Datagrams over SCTP over DTLS over UDP.
       My question is: If this related to PPSP transport mechanism? O= r totally two different things?Any different requirements? Just to provide = such info to incur discussion.
   &nbs= p;
 
BR
Yunfei
 
 
zhangyunfei
--_000_B0D29E0424F2DE47A0B36779EC66677916CE724Cszxeml504mbschi_-- From zhangyunfei@chinamobile.com Fri Mar 30 03:06:31 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 C4F4D21F898A for ; Fri, 30 Mar 2012 03:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.425 X-Spam-Level: X-Spam-Status: No, score=-95.425 tagged_above=-999 required=5 tests=[AWL=-2.086, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=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 uIV4MSoKgJUI for ; Fri, 30 Mar 2012 03:06:31 -0700 (PDT) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D278221F896D for ; Fri, 30 Mar 2012 03:06:30 -0700 (PDT) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id AB209E6A0; Fri, 30 Mar 2012 18:06:29 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id A0E45E3C9; Fri, 30 Mar 2012 18:06:29 +0800 (CST) Received: from zyf-PC ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012033018062556-17404 ; Fri, 30 Mar 2012 18:06:25 +0800 Date: Fri, 30 Mar 2012 18:06:12 +0800 From: zhangyunfei To: ZongNing , ppsp References: <2012033016511639412036@chinamobile.com>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201203301806120605785@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-30 18:06:26, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-03-30 18:06:29, Serialize complete at 2012-03-30 18:06:29 Content-Type: multipart/alternative; boundary="----=_001_NextPart866114037078_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18806.006 X-TM-AS-Result: No--18.064-7.0-31-10 X-imss-scan-details: No--18.064-7.0-31-10;No--18.064-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] re-charter issue discussion(cont'):transport mechanism 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, 30 Mar 2012 10:06:31 -0000 This is a multi-part message in MIME format. ------=_001_NextPart866114037078_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="iso-8859-1" SSB0aGluayBpbiBSVENXZWIgdGhleSBhcmUgaW5kZWVkIGRpc2N1c3NpbmcgdGhlIHBlZXIgYnJv d3NlciBzY2VuYXJpb3MuIEJ1dCBJIGd1ZXNzIHRoaXMgaXMgbm90IGEgbGFyZ2Ugc2NhbGUgUDJQ IHVzYWdlLCBha2EsIHNvbWUgdGVucyBpcyBhbHJlYWR5IGEgdmVyeSBsYXJnZSBhbW91bnQgaW4g UlRDd2ViKGxpa2UgY29uZmVyZW5jZW5pbmcpLg0KDQpCUg0KWXVuZmVpDQoNCg0KDQoNCnpoYW5n eXVuZmVpDQoNCkZyb206IFpvbmdOaW5nDQpEYXRlOiAyMDEyLTAzLTMwIDE3OjUwDQpUbzogemhh bmd5dW5mZWk7IHBwc3ANClN1YmplY3Q6IFJFOiBbcHBzcF0gcmUtY2hhcnRlciBpc3N1ZSBkaXNj dXNzaW9uKGNvbnQnKTp0cmFuc3BvcnQgbWVjaGFuaXNtDQpIaSwgWXVuZmVpLA0KDQpJIHRoaW5r IGl0IGlzIHJlbGF0ZWQgaWYgUlRDV2ViIGluY2x1ZGVzIHRoZSBzY2VuYXJpbyBvZiBvbmUgYnJv d3NlciBzdHJlYW1pbmcgdmlkZW8gdG8gb3RoZXJzIGJ5IHVzaW5nIFAyUCB3YXkuDQpBbHNvIHN0 YXJ0IGRpc2N1c3NpbmcgUDJQIHVzZSBjYXNlIGluIFJUQ1dlYiAob3IgZGlzY3Vzc2luZyB3ZWIt YnJvd2VyIHVzYWdlIGluIFBQU1ApIG1pZ2h0IGJlIGludGVyZXN0aW5nLiANCg0KLU5pbmcNCg0K DQoNCg0KRnJvbTogcHBzcC1ib3VuY2VzQGlldGYub3JnIFtwcHNwLWJvdW5jZXNAaWV0Zi5vcmdd IG9uIGJlaGFsZiBvZiB6aGFuZ3l1bmZlaSBbemhhbmd5dW5mZWlAY2hpbmFtb2JpbGUuY29tXQ0K U2VudDogRnJpZGF5LCBNYXJjaCAzMCwgMjAxMiA0OjUzIFBNDQpUbzogcHBzcA0KU3ViamVjdDog W3Bwc3BdIHJlLWNoYXJ0ZXIgaXNzdWUgZGlzY3Vzc2lvbihjb250Jyk6dHJhbnNwb3J0IG1lY2hh bmlzbQ0KDQoNCkhpIGFsbCwNCiAgICAgVG8gY29udGludWUgdGhlIHJlLWNoYXJ0ZXIgZGlzY3Vz c2lvbiBpbiBQUFNQIFdHIG1lZXRpbmcsIEkgd291bGQgbGlrZSB0byBkaXNjdXNzIG1vcmUgb24g dGhlIHRyYW5zcG9ydCBtZWNoYW5pc20gaXNzdWUuDQogICAgIEkgaGFwcGVuIHRvIGtub3cgaW4g UlRDV2ViLCB0aGUgdHJhbnNwb3J0IHByb3RvY29sIGJldHdlZW4gdHdvIHBlZXIgYnJvd3NlcnMg c2VlbXMgdG8gYmVlbiBkZWNpZGVkOiBGb3IgbWVkaWEgcGFydCwgc3J0cC9ydHAgb3ZlciBVRFAo SSBhbSBub3QgcXVpdGUgc3VyZSBvZiBpZiBpdCBpcyBhY2N1cmF0ZSkuICBGb3IgZGF0YSB0cmFu c21pdCwgRGF0YWdyYW1zIG92ZXIgU0NUUCBvdmVyIERUTFMgb3ZlciBVRFAuDQogICAgICAgTXkg cXVlc3Rpb24gaXM6IElmIHRoaXMgcmVsYXRlZCB0byBQUFNQIHRyYW5zcG9ydCBtZWNoYW5pc20/ IE9yIHRvdGFsbHkgdHdvIGRpZmZlcmVudCB0aGluZ3M/QW55IGRpZmZlcmVudCByZXF1aXJlbWVu dHM/IEp1c3QgdG8gcHJvdmlkZSBzdWNoIGluZm8gdG8gaW5jdXIgZGlzY3Vzc2lvbi4NCiAgICAg DQoNCkJSDQpZdW5mZWkNCg0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ== ------=_001_NextPart866114037078_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
I think in RTCWeb they are indeed discussing the peer browser scenari= os.=20 But I guess this is not a large scale P2P usage, aka, some tens is already= a=20 very large amount in RTCweb(like conferencening).
 
BR
Yunfei
 
zhangyunfei
 
From: ZongNing=
Date: 2012-03-30 17:50
To: zhangyunfei; ppsp
Subject: RE: [ppsp] re-charter issue=20 discussion(cont'):transport mechanism

Hi, Yunfei,

 

I think it is related if RTCWeb includes the scenario of one=20 browser streaming video to others by using P2P way.

Also start discussing P2P use case in RTCWeb (or discussing web-brower = usage=20 in PPSP) might be interesting.

 

-Ning

 

From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] o= n behalf=20 of zhangyunfei [zhangyunfei@chinamobile.com]
Sent: Friday, March= 30,=20 2012 4:53 PM
To: ppsp
Subject: [ppsp] re-charter issue= =20 discussion(cont'):transport mechanism

Hi all,
     To continue t= he=20 re-charter discussion in PPSP WG meeting, I would like to discuss more on = the=20 transport mechanism issue.
     I happen to know i= n=20 RTCWeb, the transport protocol between two peer browsers seems to&nbs= p;been=20 decided: For media part, srtp/rtp over UDP(I am not quite sure of if it is= =20 accurate).  For data transmit, Datagrams over SCTP over= DTLS over=20 UDP.
       My = question=20 is: If this related to PPSP transport mechanism? Or totally two different=20 things?Any different requirements? Just to provide such info to incur=20 discussion.
    =20
 
BR
Yunfei
 
 
zhangyunfei
------=_001_NextPart866114037078_=------ From yry@cs.yale.edu Fri Mar 30 11:52: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 95F1621F84C5 for ; Fri, 30 Mar 2012 11:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.804 X-Spam-Level: X-Spam-Status: No, score=0.804 tagged_above=-999 required=5 tests=[AWL=0.718, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=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 P3cQfAFXO7LA for ; Fri, 30 Mar 2012 11:52:23 -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 6FF8F21F84BF for ; Fri, 30 Mar 2012 11:52:23 -0700 (PDT) Received: from dhcp-128-36-59-108.central.yale.edu (dhcp-128-36-59-108.central.yale.edu [128.36.59.108]) (authenticated bits=0) by vm-emlprdomr-05.its.yale.edu (8.14.4/8.14.4) with ESMTP id q2UIqL4P000702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Mar 2012 14:52:21 -0400 Message-ID: <4F7600E5.4000301@cs.yale.edu> Date: Fri, 30 Mar 2012 14:52:21 -0400 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: ppsp@ietf.org References: <2012033016511639412036@chinamobile.com>, <201203301806120605785@chinamobile.com> In-Reply-To: <201203301806120605785@chinamobile.com> Content-Type: multipart/alternative; boundary="------------050400040105090808020809" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.146 Subject: Re: [ppsp] re-charter issue discussion(cont'):transport mechanism 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, 30 Mar 2012 18:52:24 -0000 This is a multi-part message in MIME format. --------------050400040105090808020809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, I consider browsers as one major platform for the deployment of P2P streaming clients. We have a browser (Flash based though) P2P streaming system, and recent large trial experiences are quite positive. So I support that if PPSP can use RTCWeb transport, it is a good plus. Richard On 3/30/12 6:06 AM, zhangyunfei wrote: > I think in RTCWeb they are indeed discussing the peer browser > scenarios. But I guess this is not a large scale P2P usage, aka, some > tens is already a very large amount in RTCweb(like conferencening). > BR > Yunfei > ------------------------------------------------------------------------ > zhangyunfei > *From:* ZongNing > *Date:* 2012-03-30 17:50 > *To:* zhangyunfei ; ppsp > > *Subject:* RE: [ppsp] re-charter issue discussion(cont'):transport > mechanism > > Hi, Yunfei, > > I think it is related if RTCWeb includes the scenario of one > browser streaming video to others by using P2P way. > > Also start discussing P2P use case in RTCWeb (or discussing web-brower > usage in PPSP) might be interesting. > > -Ning > > ------------------------------------------------------------------------ > *From:* ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on behalf of > zhangyunfei [zhangyunfei@chinamobile.com] > *Sent:* Friday, March 30, 2012 4:53 PM > *To:* ppsp > *Subject:* [ppsp] re-charter issue discussion(cont'):transport mechanism > > Hi all, > To continue the re-charter discussion in PPSP WG meeting, I would > like to discuss more on the transport mechanism issue. > I happen to know in RTCWeb, the transport protocol between two > peer browsers seems to been decided: For media part, srtp/rtp over > UDP(I am not quite sure of if it is accurate). For data transmit, > Datagrams over SCTP over DTLS over UDP. > My question is: If this related to PPSP transport mechanism? Or > totally two different things?Any different requirements? Just to > provide such info to incur discussion. > BR > Yunfei > ------------------------------------------------------------------------ > zhangyunfei > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --------------050400040105090808020809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

I consider browsers as one major platform for the deployment of P2P streaming clients. We have a browser (Flash based though) P2P streaming system, and recent large trial experiences are quite positive. So I support that if PPSP can use RTCWeb transport, it is a good plus.

Richard

On 3/30/12 6:06 AM, zhangyunfei wrote:
I think in RTCWeb they are indeed discussing the peer browser scenarios. But I guess this is not a large scale P2P usage, aka, some tens is already a very large amount in RTCweb(like conferencening).
 
BR
Yunfei
 
zhangyunfei
 
From: ZongNing
Date: 2012-03-30 17:50
Subject: RE: [ppsp] re-charter issue discussion(cont'):transport mechanism

Hi, Yunfei,

 

I think it is related if RTCWeb includes the scenario of one browser streaming video to others by using P2P way.

Also start discussing P2P use case in RTCWeb (or discussing web-brower usage in PPSP) might be interesting.

 

-Ning

 

From: ppsp-bounces@ietf.org [ppsp-bounces@ietf.org] on behalf of zhangyunfei [zhangyunfei@chinamobile.com]
Sent: Friday, March 30, 2012 4:53 PM
To: ppsp
Subject: [ppsp] re-charter issue discussion(cont'):transport mechanism

Hi all,
     To continue the re-charter discussion in PPSP WG meeting, I would like to discuss more on the transport mechanism issue.
     I happen to know in RTCWeb, the transport protocol between two peer browsers seems to been decided: For media part, srtp/rtp over UDP(I am not quite sure of if it is accurate).  For data transmit, Datagrams over SCTP over DTLS over UDP.
       My question is: If this related to PPSP transport mechanism? Or totally two different things?Any different requirements? Just to provide such info to incur discussion.
    
 
BR
Yunfei
 
 
zhangyunfei


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

--------------050400040105090808020809--