From p2psip-bounces@ietf.org Tue Jun 05 03:13:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTE3-000589-5w; Tue, 05 Jun 2007 03:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvTE1-00057r-3w for p2psip@ietf.org; Tue, 05 Jun 2007 03:13:05 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvTDz-0004au-LN for p2psip@ietf.org; Tue, 05 Jun 2007 03:13:05 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ500JB8IOP25@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 05 Jun 2007 15:12:25 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ500LJ2IOOCZ@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 05 Jun 2007 15:12:25 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJ50019KIOLUN@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 05 Jun 2007 15:12:24 +0800 (CST) Date: Tue, 05 Jun 2007 15:12:20 +0800 From: JiangXingFeng To: p2psip@ietf.org Message-id: <000101c7a740$dbecc020$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcenQNuuvauvgN4DRzCnD+6vOtvD7g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [P2PSIP] STUN/TURN role in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, all: NAT traversal is a big problem for P2PSIP. From the statistics from http://illuminati.coralcdn.org/stats/, it shows that 73.81% of PCs are behind NAT. These NATed PCs have to find some STUN/TURN servers to help them communicate with other peers or clients in the overlay. Apparently it violates the advantages from the P2P technology, if some central STUN/TURN servers are to be used. One feasible method is to use peers with public address to play the STUN/TURN role for NATed peers or clients. But which type of peers or clients will contribute themselves to be STUN/TURN server? IMHO, the requirement for a Peer to be the STUN/TURN peers should be as low as possible because there are huge amounts of NATed PC need to be served. Maybe public address is enough. Could you please share your views on this topic? Another issue is: must all Peers and clients support STUN/TURN/ICE? Comments? -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 05 08:16:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXxm-0007hE-WF; Tue, 05 Jun 2007 08:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvXxl-0007g4-9e for p2psip@ietf.org; Tue, 05 Jun 2007 08:16:37 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvXx4-0001wd-ST for p2psip@ietf.org; Tue, 05 Jun 2007 08:15:56 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l55CFgJ9029100; Tue, 5 Jun 2007 15:15:47 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 15:15:42 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 15:15:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP Date: Tue, 5 Jun 2007 15:17:42 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> In-Reply-To: <000101c7a740$dbecc020$6905a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] STUN/TURN role in P2PSIP Thread-Index: AcenQNuuvauvgN4DRzCnD+6vOtvD7gAIws1g References: <000101c7a740$dbecc020$6905a40a@china.huawei.com> From: To: , X-OriginalArrivalTime: 05 Jun 2007 12:15:42.0616 (UTC) FILETIME=[3CC3E980:01C7A76B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Jiang, Everything depends on the case scenario and the type of NATs. Case scenarios: 1. The P2PSIP overlay may be operated by a service provider. In this case the service provider makes sure that there is enough peers with a public address and TURN/STUN server functionality in the overlay. Not all of the peers implement a TURN/STUn server.=20 2. In other scenario the service provider may outsource maintenance of TURN/STUN servers to other entity. In this scenario TURN/STUN servers are external to P2PSIP overlay. TURN/STUN server's IP/port is registered in DHT. 3. The last option assumes that P2PSIP software is only run in the end devices. In this case we may have problems with increased load on some peers due to media relaying. Concerning NATs I checked the statistics you sent us very quickly and I did not notice any information about what types of nats are we speaking about. We may have a problem if most of connections require media relaying. Besides, we may have different nats in enterprise and residential networks. Many residential wifi routers support UPnP IGD. Marcin >-----Original Message----- >From: ext JiangXingFeng [mailto:jiang.x.f@huawei.com]=20 >Sent: 05 June, 2007 10:12 >To: p2psip@ietf.org >Subject: [P2PSIP] STUN/TURN role in P2PSIP > >Hi, all: > >NAT traversal is a big problem for P2PSIP. From the statistics=20 >from http://illuminati.coralcdn.org/stats/, it shows that=20 >73.81% of PCs are behind NAT.=20 > >These NATed PCs have to find some STUN/TURN servers to help=20 >them communicate with other peers or clients in the overlay.=20 >Apparently it violates the advantages from the P2P technology,=20 >if some central STUN/TURN servers are to be used. > >One feasible method is to use peers with public address to=20 >play the STUN/TURN role for NATed peers or clients. But which=20 >type of peers or clients will contribute themselves to be=20 >STUN/TURN server? >IMHO, the requirement for a Peer to be the STUN/TURN peers=20 >should be as low as possible because there are huge amounts of=20 >NATed PC need to be served. >Maybe public address is enough. Could you please share your=20 >views on this topic?=20 > >Another issue is: must all Peers and clients support STUN/TURN/ICE?=20 > > >Comments? > >-- >Jiang XingFeng > > > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 05 11:51:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbJN-0007fH-QB; Tue, 05 Jun 2007 11:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbJL-0007dw-WF for p2psip@ietf.org; Tue, 05 Jun 2007 11:51:08 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbJJ-0000vK-77 for p2psip@ietf.org; Tue, 05 Jun 2007 11:51:07 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 1F54C14DDC70; Tue, 5 Jun 2007 23:50:57 +0800 (CST) Message-ID: <004301c7a788$f6ec7170$a507740a@DELLWEI> From: "Wei Gengyu" To: References: <000101c7a740$dbecc020$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP Date: Tue, 5 Jun 2007 23:48:29 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2002580879==" Errors-To: p2psip-bounces@ietf.org --===============2002580879== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQpIaSwgDQoNCldoYXQgeW91IHNhaWQgaXMgcmlnaHQsICAiRXZlcnl0aGluZyBkZXBlbmRzIG9u IHRoZSBjYXNlIHNjZW5hcmlvIGFuZCB0aGUgdHlwZSBvZiBOQVRzLiAiDQpUbyBtYWtlIGl0IGNv bmNyZXRlLCB3ZSBzZWUgdGhlIHR3byB3aWRlbHkgZGVwbG95ZWQgYXBwbGljYXRpb25zLCBTa3lw ZSBhbmQgQlQuDQpTa3lwZSBpcyBvcGVyYXRlZCBieSBhIHNlcnZpY2UgcHJvdmlkZXIgYW5kIG5l ZWRzIGNlbnRyYWxpemVkIHJlZ2lzdGF0aW9uLg0KQlQgc3VwcG9ydCBhbnkgdXNlciB0byBkZWxp dmVyIHRvcnJlbnQgZmlsZSB3aGlsZSBnaXZpbmcgdGhlIHNlZWQgYW5kIHRyYWNrZXIgYWRkcmVz c2VzLiANCg0KQ3VycmVudGx5LCB5b3UgY2FuIHVzZSB0aGVzZSB0d28gcDJwIGFwcGxpY2F0aW9z IGJ5IGRvd25sb2FkaW5nIGRpZmZlcmVudCBzb2Z0d2FyZXMsDQplYWNoIHNvZnR3YXJlIHdvdWxk IGhhdmUgaXRzIG93biBtZWNoYW5pc20gdG8gcHJvY2VzcyBOQVQuDQoNCkJ1ciAsIHRoZSBwcm9i bGVtcyBhcmU6IA0KKDEpIElzIGl0IG5lY2Vzc2FyeSB0byBtYWtlIFAyUFNJUCBkZWZpbmUgYW55 IG1lY2hhbmlzbXMgdG8gZmFjaWxpdGF0ZSBwcm9jZXNzaW5nIE5BVD8NCigyKSBTaGFsbCB3ZSBy ZWx5IG9uIGFwcGxpY2F0aW9uIHNvZnR3YXJlcyBqdXN0IGFzIG5vdy4gDQoNClJlZ2FyZHMsIA0K DQpHZW5neXUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxtYXJjaW4u bWF0dXN6ZXdza2lAbm9raWEuY29tPg0KVG86IDxqaWFuZy54LmZAaHVhd2VpLmNvbT47IDxwMnBz aXBAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBKdW5lIDA1LCAyMDA3IDg6MTcgUE0NClN1Ympl Y3Q6IFJFOiBbUDJQU0lQXSBTVFVOL1RVUk4gcm9sZSBpbiBQMlBTSVANCg0KDQoNCkhpIEppYW5n LA0KDQpFdmVyeXRoaW5nIGRlcGVuZHMgb24gdGhlIGNhc2Ugc2NlbmFyaW8gYW5kIHRoZSB0eXBl IG9mIE5BVHMuIENhc2UNCnNjZW5hcmlvczoNCjEuIFRoZSBQMlBTSVAgb3ZlcmxheSBtYXkgYmUg b3BlcmF0ZWQgYnkgYSBzZXJ2aWNlIHByb3ZpZGVyLiBJbiB0aGlzDQpjYXNlIHRoZSBzZXJ2aWNl IHByb3ZpZGVyIG1ha2VzIHN1cmUgdGhhdCB0aGVyZSBpcyBlbm91Z2ggcGVlcnMgd2l0aCBhDQpw dWJsaWMgYWRkcmVzcyBhbmQgVFVSTi9TVFVOIHNlcnZlciBmdW5jdGlvbmFsaXR5IGluIHRoZSBv dmVybGF5LiBOb3QNCmFsbCBvZiB0aGUgcGVlcnMgaW1wbGVtZW50IGEgVFVSTi9TVFVuIHNlcnZl ci4gDQoyLiBJbiBvdGhlciBzY2VuYXJpbyB0aGUgc2VydmljZSBwcm92aWRlciBtYXkgb3V0c291 cmNlIG1haW50ZW5hbmNlIG9mDQpUVVJOL1NUVU4gc2VydmVycyB0byBvdGhlciBlbnRpdHkuIElu IHRoaXMgc2NlbmFyaW8gVFVSTi9TVFVOIHNlcnZlcnMNCmFyZSBleHRlcm5hbCB0byBQMlBTSVAg b3ZlcmxheS4gVFVSTi9TVFVOIHNlcnZlcidzIElQL3BvcnQgaXMgcmVnaXN0ZXJlZA0KaW4gREhU Lg0KMy4gVGhlIGxhc3Qgb3B0aW9uIGFzc3VtZXMgdGhhdCBQMlBTSVAgc29mdHdhcmUgaXMgb25s eSBydW4gaW4gdGhlIGVuZA0KZGV2aWNlcy4gSW4gdGhpcyBjYXNlIHdlIG1heSBoYXZlIHByb2Js ZW1zIHdpdGggaW5jcmVhc2VkIGxvYWQgb24gc29tZQ0KcGVlcnMgZHVlIHRvIG1lZGlhIHJlbGF5 aW5nLg0KDQpDb25jZXJuaW5nIE5BVHMgSSBjaGVja2VkIHRoZSBzdGF0aXN0aWNzIHlvdSBzZW50 IHVzIHZlcnkgcXVpY2tseSBhbmQgSQ0KZGlkIG5vdCBub3RpY2UgYW55IGluZm9ybWF0aW9uIGFi b3V0IHdoYXQgdHlwZXMgb2YgbmF0cyBhcmUgd2Ugc3BlYWtpbmcNCmFib3V0LiBXZSBtYXkgaGF2 ZSBhIHByb2JsZW0gaWYgbW9zdCBvZiBjb25uZWN0aW9ucyByZXF1aXJlIG1lZGlhDQpyZWxheWlu Zy4gQmVzaWRlcywgd2UgbWF5IGhhdmUgZGlmZmVyZW50IG5hdHMgaW4gZW50ZXJwcmlzZSBhbmQN CnJlc2lkZW50aWFsIG5ldHdvcmtzLiBNYW55IHJlc2lkZW50aWFsIHdpZmkgcm91dGVycyBzdXBw b3J0IFVQblAgSUdELg0KDQoNCk1hcmNpbg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj5Gcm9tOiBleHQgSmlhbmdYaW5nRmVuZyBbbWFpbHRvOmppYW5nLnguZkBodWF3ZWkuY29tXSAN Cj5TZW50OiAwNSBKdW5lLCAyMDA3IDEwOjEyDQo+VG86IHAycHNpcEBpZXRmLm9yZw0KPlN1Ympl Y3Q6IFtQMlBTSVBdIFNUVU4vVFVSTiByb2xlIGluIFAyUFNJUA0KPg0KPkhpLCBhbGw6DQo+DQo+ TkFUIHRyYXZlcnNhbCBpcyBhIGJpZyBwcm9ibGVtIGZvciBQMlBTSVAuIEZyb20gdGhlIHN0YXRp c3RpY3MgDQo+ZnJvbSBodHRwOi8vaWxsdW1pbmF0aS5jb3JhbGNkbi5vcmcvc3RhdHMvLCBpdCBz aG93cyB0aGF0IA0KPjczLjgxJSBvZiBQQ3MgYXJlIGJlaGluZCBOQVQuIA0KPg0KPlRoZXNlIE5B VGVkIFBDcyBoYXZlIHRvIGZpbmQgc29tZSBTVFVOL1RVUk4gc2VydmVycyB0byBoZWxwIA0KPnRo ZW0gY29tbXVuaWNhdGUgd2l0aCBvdGhlciBwZWVycyBvciBjbGllbnRzIGluIHRoZSBvdmVybGF5 LiANCj5BcHBhcmVudGx5IGl0IHZpb2xhdGVzIHRoZSBhZHZhbnRhZ2VzIGZyb20gdGhlIFAyUCB0 ZWNobm9sb2d5LCANCj5pZiBzb21lIGNlbnRyYWwgU1RVTi9UVVJOIHNlcnZlcnMgYXJlIHRvIGJl IHVzZWQuDQo+DQo+T25lIGZlYXNpYmxlIG1ldGhvZCBpcyB0byB1c2UgcGVlcnMgd2l0aCBwdWJs aWMgYWRkcmVzcyB0byANCj5wbGF5IHRoZSBTVFVOL1RVUk4gcm9sZSBmb3IgTkFUZWQgcGVlcnMg b3IgY2xpZW50cy4gQnV0IHdoaWNoIA0KPnR5cGUgb2YgcGVlcnMgb3IgY2xpZW50cyB3aWxsIGNv bnRyaWJ1dGUgdGhlbXNlbHZlcyB0byBiZSANCj5TVFVOL1RVUk4gc2VydmVyPw0KPklNSE8sIHRo ZSByZXF1aXJlbWVudCBmb3IgYSBQZWVyIHRvIGJlIHRoZSBTVFVOL1RVUk4gcGVlcnMgDQo+c2hv dWxkIGJlIGFzIGxvdyBhcyBwb3NzaWJsZSBiZWNhdXNlIHRoZXJlIGFyZSBodWdlIGFtb3VudHMg b2YgDQo+TkFUZWQgUEMgbmVlZCB0byBiZSBzZXJ2ZWQuDQo+TWF5YmUgcHVibGljIGFkZHJlc3Mg aXMgZW5vdWdoLiBDb3VsZCB5b3UgcGxlYXNlIHNoYXJlIHlvdXIgDQo+dmlld3Mgb24gdGhpcyB0 b3BpYz8gDQo+DQo+QW5vdGhlciBpc3N1ZSBpczogbXVzdCBhbGwgUGVlcnMgYW5kIGNsaWVudHMg c3VwcG9ydCBTVFVOL1RVUk4vSUNFPyANCj4NCj4NCj5Db21tZW50cz8NCj4NCj4tLQ0KPkppYW5n IFhpbmdGZW5nDQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj5QMlBTSVAgbWFpbGluZyBsaXN0DQo+UDJQU0lQQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQo+DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQMlBTSVAgbWFpbGlu ZyBsaXN0DQpQMlBTSVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycHNpcA0K --===============2002580879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2002580879==-- From p2psip-bounces@ietf.org Wed Jun 06 05:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvrUj-0001v9-G1; Wed, 06 Jun 2007 05:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvrUh-0001v1-LX for p2psip@ietf.org; Wed, 06 Jun 2007 05:07:55 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvrUg-0002Bm-3B for p2psip@ietf.org; Wed, 06 Jun 2007 05:07:55 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ7004VGINR91@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 06 Jun 2007 17:07:03 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ70041WINQJY@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 06 Jun 2007 17:07:03 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJ700LJ8INKC4@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 06 Jun 2007 17:07:02 +0800 (CST) Date: Wed, 06 Jun 2007 17:06:55 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP In-reply-to: <004301c7a788$f6ec7170$a507740a@DELLWEI> To: 'Wei Gengyu' , marcin.matuszewski@nokia.com Message-id: <002501c7a81a$082902f0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AceniYEAsrlZdbmBQ7u1QYs5G4eLzAAja9fg X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Gengyu: > Bur , the problems are: > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing > NAT? It seems that rough consensus has been achieved in P2PSIP community that some methods defined in STUN/TURN/ICE specifications will be reused to address NAT traversal issues in P2PSIP. But personally I think P2PSIP should solve some issues to facilitate STUN/TURN/ICE's use. There are some concerns listed as follows: 1) How to discover STUN/TURN server in P2PSIP case 2) How to exchange candidates for ICE process between Peers Regards JiangXingfeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 06 05:40:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvrzq-0007lb-KP; Wed, 06 Jun 2007 05:40:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvrzp-0007lW-D2 for p2psip@ietf.org; Wed, 06 Jun 2007 05:40:05 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvrzo-0004m1-SB for p2psip@ietf.org; Wed, 06 Jun 2007 05:40:05 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ700ATXK5IR7@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 06 Jun 2007 17:39:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJ700KLAK5HQR@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 06 Jun 2007 17:39:18 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJ700LLPK5EC4@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 06 Jun 2007 17:39:17 +0800 (CST) Date: Wed, 06 Jun 2007 17:39:14 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP In-reply-to: <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> To: marcin.matuszewski@nokia.com, p2psip@ietf.org Message-id: <002601c7a81e$8b57c9a0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcenQNuuvauvgN4DRzCnD+6vOtvD7gAIws1gAC2LNbA= X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi: > Everything depends on the case scenario and the type of NATs. Case > scenarios: > 1. The P2PSIP overlay may be operated by a service provider. In this > case the service provider makes sure that there is enough peers with a > public address and TURN/STUN server functionality in the overlay. Not > all of the peers implement a TURN/STUn server. > 2. In other scenario the service provider may outsource maintenance of > TURN/STUN servers to other entity. In this scenario TURN/STUN servers > are external to P2PSIP overlay. TURN/STUN server's IP/port is registered > in DHT. > 3. The last option assumes that P2PSIP software is only run in the end > devices. In this case we may have problems with increased load on some > peers due to media relaying. I agree that different scenarios will choose how to deploy STUN/TURN server in their own environment. But equipping a peer or client having a public address with STUN/TURN functionalities and choosing them to serve for other peers will make full use of distributed processing power in the overlay. As for increased load on these peers due to media relaying, I think peers could accept or reject the service requests from other peers or clients according to their own processing capability. It will guarantee the communication quality as much as possible. Clients may be more appropriate being a STUN/TURN server than Peers. Peers should maintain overlay topology and route message what clients would not do this kind of work. > Concerning NATs I checked the statistics you sent us very quickly and I > did not notice any information about what types of nats are we speaking > about. We may have a problem if most of connections require media > relaying. Besides, we may have different nats in enterprise and > residential networks. Many residential wifi routers support UPnP IGD. Some peers behind NAT do not need other peer's help, for example in the case of NATs supporting UPnP IGD. But most of the existing NATs do not support similar functionality, so I think STUN/TURN/ICE is required when address NAT traversal issue at present. Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 08 10:27:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfRP-0003TS-TM; Fri, 08 Jun 2007 10:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwfRO-0003MQ-AS for p2psip@ietf.org; Fri, 08 Jun 2007 10:27:50 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwfRM-0004SJ-V0 for p2psip@ietf.org; Fri, 08 Jun 2007 10:27:50 -0400 Received: from [72.87.190.19] (helo=[192.9.200.1]) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1HwfRM-00070N-7d for p2psip@ietf.org; Fri, 08 Jun 2007 10:27:48 -0400 Message-ID: <46697608.7010603@idssoftware.com> Date: Fri, 08 Jun 2007 07:30:16 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: p2psip@ietf.org Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP References: <000101c7a740$dbecc020$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> <004301c7a788$f6ec7170$a507740a@DELLWEI> In-Reply-To: <004301c7a788$f6ec7170$a507740a@DELLWEI> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da94029e672e268b245365ae5e259250ef11e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.87.190.19 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, I agree that STUN/TURN/ICE should be left to the p2psip application instead of the standard for p2psip. What the standard body can do is to produce a recommendation for common practices in regarding NAT traversal. For example, you can recommend using the OpenDHT project to serve as a "centralized" location for UAs to communicate resources such as who can serve as a STUN server. --Michael Wei Gengyu wrote: > Hi, > > What you said is right, "Everything depends on the case scenario and the type of NATs. " > To make it concrete, we see the two widely deployed applications, Skype and BT. > Skype is operated by a service provider and needs centralized registation. > BT support any user to deliver torrent file while giving the seed and tracker addresses. > > Currently, you can use these two p2p applicatios by downloading different softwares, > each software would have its own mechanism to process NAT. > > Bur , the problems are: > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT? > (2) Shall we rely on application softwares just as now. > > Regards, > > Gengyu > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 08 10:42:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwffv-0005Ks-Lq; Fri, 08 Jun 2007 10:42:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwffu-0005Km-J1 for p2psip@ietf.org; Fri, 08 Jun 2007 10:42:50 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwfft-0001O5-8X for p2psip@ietf.org; Fri, 08 Jun 2007 10:42:50 -0400 Received: by py-out-1112.google.com with SMTP id a25so1917390pyi for ; Fri, 08 Jun 2007 07:42:48 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=TZABIdtZ7CNsnXNBBFFs/A3/jz8Xf7oPAZPU/RQ8RE9N1e1JzePfh93Bl0H1JyLZR1suS1+t3H34QkrkF5V5H+ly/gWYbs7F17ZW3pdhhGEdK9Mo0M6+QFjiEP1OwJGSAcb/9goI8EqE6pb63+NDLgpwvEYKr6dxkTiLAKLIvFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=uFgjXtEag+boPTGw8e5F+9BGm/wKkhlNyHTxYpDGHBRhu5ZkyK6dUN+pK4FFjf9bovF4p5kLpHwPF+Cq/uFk3GaZPfC1CwrHnCYJIe1XSic3uBmEV5mtuvwaSGxmgIt2Mlv+RODqg4q7SdtHMZTcAs09yRGJs54uc14TzPqzqw4= Received: by 10.35.76.9 with SMTP id d9mr3967999pyl.1181313768728; Fri, 08 Jun 2007 07:42:48 -0700 (PDT) Received: by 10.35.134.15 with HTTP; Fri, 8 Jun 2007 07:42:48 -0700 (PDT) Message-ID: <4d4304a00706080742s4f2ff74fmda513e720c1b77c7@mail.gmail.com> Date: Fri, 8 Jun 2007 10:42:48 -0400 From: "David A. Bryan" To: "Michael Chen" Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP In-Reply-To: <46697608.7010603@idssoftware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <000101c7a740$dbecc020$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> <004301c7a788$f6ec7170$a507740a@DELLWEI> <46697608.7010603@idssoftware.com> X-Google-Sender-Auth: 874285081629221e X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The problem with this approach is that it essentially means there is no way defined that two different implementers can both code to and be assured their systems would work together. Having a "common practice" (particularly the one proposed below that relies on a non-standardized service) isn't something that an implementer can use to guarantee their software will interoperate with another through NATs. So in my personal opinion, we should definitely be standardizing the mechanism for NAT traversal. We want to be able to have a P2PSIP cloud of devices from vendors X, Y, and Z, all of which together, and I don't see how we do that without explicitly standardizing the NAT traversal aspects. My 2 cents... David On 6/8/07, Michael Chen wrote: > Hi, > > I agree that STUN/TURN/ICE should be left to the p2psip application > instead of the standard for p2psip. What the standard body can do is to > produce a recommendation for common practices in regarding NAT traversal. > > For example, you can recommend using the OpenDHT project to serve as a > "centralized" location for UAs to communicate resources such as who can > serve as a STUN server. > > --Michael > > Wei Gengyu wrote: > > Hi, > > > > What you said is right, "Everything depends on the case scenario and the type of NATs. " > > To make it concrete, we see the two widely deployed applications, Skype and BT. > > Skype is operated by a service provider and needs centralized registation. > > BT support any user to deliver torrent file while giving the seed and tracker addresses. > > > > Currently, you can use these two p2p applicatios by downloading different softwares, > > each software would have its own mechanism to process NAT. > > > > Bur , the problems are: > > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT? > > (2) Shall we rely on application softwares just as now. > > > > Regards, > > > > Gengyu > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 08 14:28:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjBy-00029m-7p; Fri, 08 Jun 2007 14:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjBw-00029h-SN for p2psip@ietf.org; Fri, 08 Jun 2007 14:28:08 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjBv-0007bm-L2 for p2psip@ietf.org; Fri, 08 Jun 2007 14:28:08 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JJB009GKXYUEY@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 08 Jun 2007 11:28:07 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JJB002MAXYUND@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 08 Jun 2007 11:28:06 -0700 (PDT) Date: Fri, 08 Jun 2007 13:26:09 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP To: "David A. Bryan" , Michael Chen Message-id: <050601c7a9fa$7c495f90$6801a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000101c7a740$dbecc020$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> <004301c7a788$f6ec7170$a507740a@DELLWEI> <46697608.7010603@idssoftware.com> <4d4304a00706080742s4f2ff74fmda513e720c1b77c7@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just so the chair doesn't have to judge WG consensus based on his own postings - I agree with David and was preparing to send almost the same text verbatim. In addition, I would have added a reference to ad hoc P2PSIP DHTs, where your client simply joins whatever DHT is available - it's hard to know how that would work, if the application had all the NAT traversal intelligence. Thanks, Spencer > The problem with this approach is that it essentially means there is > no way defined that two different implementers can both code to and be > assured their systems would work together. Having a "common practice" > (particularly the one proposed below that relies on a non-standardized > service) isn't something that an implementer can use to guarantee > their software will interoperate with another through NATs. > > So in my personal opinion, we should definitely be standardizing the > mechanism for NAT traversal. We want to be able to have a P2PSIP cloud > of devices from vendors X, Y, and Z, all of which together, and I > don't see how we do that without explicitly standardizing the NAT > traversal aspects. > > My 2 cents... > > David _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 08 14:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjLr-00051B-9M; Fri, 08 Jun 2007 14:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjLq-0004th-3J for p2psip@ietf.org; Fri, 08 Jun 2007 14:38:22 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwjLo-0003yu-P5 for p2psip@ietf.org; Fri, 08 Jun 2007 14:38:22 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l58IcEKs008807 for ; Fri, 8 Jun 2007 14:38:14 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Jun 2007 14:37:32 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C593F30C@photon.objectworld.com> In-Reply-To: <050601c7a9fa$7c495f90$6801a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] STUN/TURN role in P2PSIP Thread-Index: Acep+sfddhfIZ5JRQd2o23iI3L0/oAAATzbw References: <000101c7a740$dbecc020$6905a40a@china.huawei.com><3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com><004301c7a788$f6ec7170$a507740a@DELLWEI><46697608.7010603@idssoftware.com><4d4304a00706080742s4f2ff74fmda513e720c1b77c7@mail.gmail.com> <050601c7a9fa$7c495f90$6801a8c0@china.huawei.com> From: "Michael Slavitch" To: "Spencer Dawkins" , "David A. Bryan" , "Michael Chen" X-Spam-Score: 0.70 () [Tag at 20.00] SPF(none,0.1),132(0.3),131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) Content-Disposition: inline X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm in full agreement with Spencer. 308 Legget Dr.=20 Ottawa Ontario=20 K2K 1Y6 Canada Michael Slavitch=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com PSTN:=20=20 +1.888.398.9698 x225 Fax: +1.613.599.7457 -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Friday, June 08, 2007 2:26 PM To: David A. Bryan; Michael Chen Cc: p2psip@ietf.org Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP Just so the chair doesn't have to judge WG consensus based on his own=20 postings - I agree with David and was preparing to send almost the same tex= t=20 verbatim. In addition, I would have added a reference to ad hoc P2PSIP DHTs, where=20 your client simply joins whatever DHT is available - it's hard to know how= =20 that would work, if the application had all the NAT traversal intelligence. Thanks, Spencer > The problem with this approach is that it essentially means there is > no way defined that two different implementers can both code to and be > assured their systems would work together. Having a "common practice" > (particularly the one proposed below that relies on a non-standardized > service) isn't something that an implementer can use to guarantee > their software will interoperate with another through NATs. > > So in my personal opinion, we should definitely be standardizing the > mechanism for NAT traversal. We want to be able to have a P2PSIP cloud > of devices from vendors X, Y, and Z, all of which together, and I > don't see how we do that without explicitly standardizing the NAT > traversal aspects. > > My 2 cents... > > David=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 08 14:39:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjNH-0006er-2K; Fri, 08 Jun 2007 14:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwjNF-0006em-Ld for p2psip@ietf.org; Fri, 08 Jun 2007 14:39:49 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HwjNE-0004f2-TO for p2psip@ietf.org; Fri, 08 Jun 2007 14:39:49 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 08 Jun 2007 11:39:43 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l58IdYWs020990; Fri, 8 Jun 2007 11:39:38 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l58IdW0e009158; Fri, 8 Jun 2007 11:39:33 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 11:39:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP Date: Fri, 8 Jun 2007 11:39:12 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22903C4D@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [P2PSIP] STUN/TURN role in P2PSIP Thread-Index: Acep4vILYnmuMVuAQQCDXJOKJ5jUHw== From: "Henry Sinnreich" To: "Michael Chen" , X-OriginalArrivalTime: 08 Jun 2007 18:39:32.0723 (UTC) FILETIME=[5B049C30:01C7A9FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1429915459==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1429915459== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A9FC.4F0F22CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A9FC.4F0F22CA Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Michael, =20 > For example, you can recommend using the OpenDHT project to serve as a > "centralized" location for UAs to communicate resources such as who can=20 > serve as a STUN server. =20 I love this approach as well, except the openDHT is a research project and unless there will be a similar commercial version, this is not yet practical.=20 =20 Folks out there on the list: Can you share any info about commercial initiatives along the line of the openDHT for a general purpose p2p overlay network? =20 Thanks, Henry =20 -----Original Message----- From: Michael Chen [mailto:michaelc@idssoftware.com]=20 Sent: Friday, June 08, 2007 10:30 AM To: p2psip@ietf.org Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP =20 Hi, =20 I agree that STUN/TURN/ICE should be left to the p2psip application=20 instead of the standard for p2psip. What the standard body can do is to=20 produce a recommendation for common practices in regarding NAT traversal. =20 For example, you can recommend using the OpenDHT project to serve as a=20 "centralized" location for UAs to communicate resources such as who can=20 serve as a STUN server. =20 --Michael =20 Wei Gengyu wrote: > Hi,=20 >=20 > What you said is right, "Everything depends on the case scenario and the type of NATs. " > To make it concrete, we see the two widely deployed applications, Skype and BT. > Skype is operated by a service provider and needs centralized registation. > BT support any user to deliver torrent file while giving the seed and tracker addresses.=20 >=20 > Currently, you can use these two p2p applicatios by downloading different softwares, > each software would have its own mechanism to process NAT. >=20 > Bur , the problems are:=20 > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT? > (2) Shall we rely on application softwares just as now.=20 >=20 > Regards,=20 >=20 > Gengyu >=20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 ------_=_NextPart_001_01C7A9FC.4F0F22CA Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Michael,

 

> For example, you can recommend using the OpenDHT project to = serve as a

> "centralized" location for UAs to communicate = resources such as who can

> serve as a STUN server.

 

I love this approach as well, except the openDHT is a research = project and unless there will be a similar commercial version, this is not yet practical.

 

Folks out there on the list: Can you share any info about = commercial initiatives along the line of the openDHT for a general purpose p2p = overlay network?

 

Thanks, Henry

 

-----Original Message-----

From: Michael Chen [mailto:michaelc@idssoftware.com] =

Sent: Friday, June 08, 2007 10:30 = AM

To: p2psip@ietf.org

Subject: Re: [P2PSIP] STUN/TURN role in = P2PSIP

 

Hi,

 

I agree that STUN/TURN/ICE should be left to the p2psip = application

instead of the standard for p2psip. What the standard body can = do is to

produce a recommendation for common practices in regarding NAT traversal.

 

For example, you can recommend using the OpenDHT project to = serve as a

"centralized" location for UAs to communicate = resources such as who can

serve as a STUN server.

 

--Michael

 

Wei Gengyu wrote:

> Hi,

>

> What you said is right,  "Everything depends on = the case scenario and the type of NATs. "

> To make it concrete, we see the two widely deployed = applications, Skype and BT.

> Skype is operated by a service provider and needs = centralized registation.

> BT support any user to deliver torrent file while giving = the seed and tracker addresses.

>

> Currently, you can use these two p2p applicatios by = downloading different softwares,

> each software would have its own mechanism to process = NAT.

>

> Bur , the problems are:

> (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT?

> (2) Shall we rely on application softwares just as now. =

>

> Regards,

>

> Gengyu

>

 

_______________________________________________=

P2PSIP mailing list

P2PSIP@ietf.org

https://www1.ietf.org/mailman/listinfo/p2psip=

 

 

------_=_NextPart_001_01C7A9FC.4F0F22CA-- --===============1429915459== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1429915459==-- From p2psip-bounces@ietf.org Fri Jun 08 15:32:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkC1-0004ON-Jr; Fri, 08 Jun 2007 15:32:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HwkBz-0004OH-6d for p2psip@ietf.org; Fri, 08 Jun 2007 15:32:15 -0400 Received: from canitpro.objectworld.com ([72.1.207.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HwkBw-00078N-VO for p2psip@ietf.org; Fri, 08 Jun 2007 15:32:15 -0400 Received: from photon.objectworld.com (photon.objectworld.com [10.10.8.2]) by canitpro.objectworld.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l58JW5BH010376 for ; Fri, 8 Jun 2007 15:32:05 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Jun 2007 15:31:17 -0400 Message-ID: <4E2DC1ACE541B94A946B8D8657E372C593F317@photon.objectworld.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22903C4D@namail5.corp.adobe.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] STUN/TURN role in P2PSIP Thread-Index: Acep4vILYnmuMVuAQQCDXJOKJ5jUHwAIFxug References: <24CCCC428EFEA2469BF046DB3C7A8D22903C4D@namail5.corp.adobe.com> From: "Michael Slavitch" To: "Henry Sinnreich" , "Michael Chen" , X-Spam-Score: 1.50 (*) [Tag at 20.00] EXTRA_MPART_TYPE, HTML_MESSAGE, SPF(none, 0.1), 132(0.3), 131(0.3) X-CanItPRO-Stream: outgoing (inherits from default) X-Scanned-By: CanIt (www . roaringpenguin . com) on 10.10.8.9 X-Spam-Score: 0.2 (/) X-Scan-Signature: ae94eee30e48a465014d0c9cbb0ac2ba Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1537631381==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1537631381== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7AA03.B1F1873C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7AA03.B1F1873C Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7AA03.B1F1873C" ------_=_NextPart_002_01C7AA03.B1F1873C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Done commercially it serves an alternative to root DNS servers. I can attest to knowing of some commercial interest in this area but not by my employer. To be successful it would need a considerably authoritative sponsor that need not be commercial or governmental. Finding that sponsor is the tough part. =20 Regards =20 M =20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20 =20 308 Legget Dr.=20 Ottawa Ontario=20 K2K 1Y6 Canada =20 =20 =20=09=20 Michael Slavitch=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Lead, Technology Initiatives slavitch@objectworld.com PSTN:=20=20 +1.888.398.9698 x225 Fax: +1.613.599.7457 =20 =20 =20 =20 =20 =20=09=20 =20 =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Friday, June 08, 2007 2:39 PM To: Michael Chen; p2psip@ietf.org Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP =20 Michael, =20 > For example, you can recommend using the OpenDHT project to serve as a > "centralized" location for UAs to communicate resources such as who can=20 > serve as a STUN server. =20 I love this approach as well, except the openDHT is a research project and unless there will be a similar commercial version, this is not yet practical.=20 =20 Folks out there on the list: Can you share any info about commercial initiatives along the line of the openDHT for a general purpose p2p overlay network? =20 Thanks, Henry =20 -----Original Message----- From: Michael Chen [mailto:michaelc@idssoftware.com]=20 Sent: Friday, June 08, 2007 10:30 AM To: p2psip@ietf.org Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP =20 Hi, =20 I agree that STUN/TURN/ICE should be left to the p2psip application=20 instead of the standard for p2psip. What the standard body can do is to=20 produce a recommendation for common practices in regarding NAT traversal. =20 For example, you can recommend using the OpenDHT project to serve as a=20 "centralized" location for UAs to communicate resources such as who can=20 serve as a STUN server. =20 --Michael =20 Wei Gengyu wrote: > Hi,=20 >=20 > What you said is right, "Everything depends on the case scenario and the type of NATs. " > To make it concrete, we see the two widely deployed applications, Skype and BT. > Skype is operated by a service provider and needs centralized registation. > BT support any user to deliver torrent file while giving the seed and tracker addresses.=20 >=20 > Currently, you can use these two p2p applicatios by downloading different softwares, > each software would have its own mechanism to process NAT. >=20 > Bur , the problems are:=20 > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT? > (2) Shall we rely on application softwares just as now.=20 >=20 > Regards,=20 >=20 > Gengyu >=20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 ________________________________ Spam =20 Not spam =20 Forget previous vote =20 -----------------------------------------------=0D =0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. =0D =0D Any views, opinions and content presented in this e-mail are solely those o= f the author and may not represent those of Objectworld Communications Corp= .=20 ------_=_NextPart_002_01C7AA03.B1F1873C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Done commercially it serves an alternative to root DNS servers= .   I can attest to knowing of some commercial interest in this area but not by= my employer.

To be successful it would need a considerably authoritative sponsor that need not be commercial or governmental.  Finding that spo= nsor is the tough part.

 

Regards

 

M

 

          =             &nb= sp;            =         

3D"corp_2colour"

 

308 Legget Dr.
Ottawa Ontario
K2K 1Y6 Canada

 

Michael Slavitch          &nb= sp;  

Lead, Technology Initiatives

slavitch@objectworld.com

PSTN: 

+1.888.398.9698

x225

Fax:

+1.613.599.7457

 

 

 

 

 

 

 

 

From: Henry Sinnrei= ch [mailto:hsinnrei@adobe.com]
Sent: Friday, June 08, 2007 2:39 PM
To: Michael Chen; p2psip@ietf.org
Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP

 

Michael,

 

> For example, you can recommend using the OpenD= HT project to serve as a

> "centralized" location for UAs to communicate resources such as who can

> serve as a STUN server.

 

I love this approach as well, except the openDHT is= a research project and unless there will be a similar commercial version, thi= s is not yet practical.

 

Folks out there on the list: Can you share any info= about commercial initiatives along the line of the openDHT for a general purpose = p2p overlay network?

 

Thanks, Henry

 

-----Original Message-----

From: Michael Chen [mailto:michaelc@idssoftware.com= ]

Sent: Friday, June 08, 2007 10:30 AM

To: p2psip@ietf.org

Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP=

 

Hi,

 

I agree that STUN/TURN/ICE should be left to the p2= psip application

instead of the standard for p2psip. What the standa= rd body can do is to

produce a recommendation for common practices in regarding NAT traversal.

 

For example, you can recommend using the OpenDHT pr= oject to serve as a

"centralized" location for UAs to communi= cate resources such as who can

serve as a STUN server.

 

--Michael

 

Wei Gengyu wrote:

> Hi,

>

> What you said is right,  "Everything depends on the case scenario and the type of NATs. "

> To make it concrete, we see the two widely dep= loyed applications, Skype and BT.

> Skype is operated by a service provider and ne= eds centralized registation.

> BT support any user to deliver torrent file wh= ile giving the seed and tracker addresses.

>

> Currently, you can use these two p2p applicati= os by downloading different softwares,

> each software would have its own mechanism to process NAT.

>

> Bur , the problems are:

> (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT?

> (2) Shall we rely on application softwares jus= t as now.

>

> Regards,

>

> Gengyu

>

 

_______________________________________________

P2PSIP mailing list

P2PSIP@ietf.org

https://www1.ietf.org/mailman/listinfo/p2psip

 

 

=0D

=0D This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.

=0D =0D

Any views, opinions and content presented in this e-mail are solely thos= e of the author and may not represent those of Objectworld Communications C= orp.

=0D ------_=_NextPart_002_01C7AA03.B1F1873C-- ------_=_NextPart_001_01C7AA03.B1F1873C Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg Content-Disposition: inline /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0N Dh0VFhEYIx8lJCIfIiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/ 2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAAqAO0DASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDIh8R6+0Eb NruoklASftLelNn8T65GhX+3tRDsDtAuGJzWZbTDyIFKOu5FAJHBOKbPNHEx lWYK4wpGMhueleLz1Oe12fc+wwyoqXKvuRtL4h1/aM65qGcc/wCkt/jUK+J9 clnAj17UWQKd3+kNjPb+tN/s+6bR21cRqbBZ/s5l3j7309OcZrNjnihmNuZ1 IVNy5I4HTFHNVW7YvZYOTSjGNk7PRbm1/wAJDrv/AEHNR/8AAlv8a9P8NWv/ AAkHgnTJNRlaebZJmWUB3Od69T7H9BXjMc7jY0wCq4yMA/KfQ17d8PiD4G0w joUb/wBDaurCObk+Z3PJziFGNODpxSd+1jV0rTRpds8Inecu+8u/XoB/ICr1 U9W1W00TSrjU76Qx29shdyBk/QD1PSuc8NfEbTvEWqpph0++0+4mi863F3GF E6eqnPpzXoHzp19FZniHXIPDmhXOr3McksNsoZkjxuOSBxn61ieHPiLpniHV V0s2V9p93LF50Md5Ft85MZypBOeOfwoA66iisTwv4otPFVlc3dpDNClvcvbM JQMllAJIwTxzQBt0Vynijx9a+GNYt9KfS9Qv7m4h85Fs4w5xkjpnPY1taFq3 9uaTFqH2K6svMJHkXSbJFwccigDRorlfFPj+w8MahHp32G81C8eIzNDaR7jH GM/M3Psa2tC1uy8RaPb6rp7l7ecZXcMFSDggj1BFAGhRXH+K/iLaeEdQFrea PqU6MqlbiGIGMs2cKGJHPHSt/QdX/tzSYtQ+w3Vj5hYeRdJskXBxyKANGisR vFNnH4qm8PSRSpPFZ/a/MONjJnBxznIrJi+JekzeF7bX47W6aG6vRZpDhd+8 n64x3oA7Gikrhf8AhbWif2p9n+x3/wBh+0/Zv7S8r9x5npnPSgDu6KQnAzXA 2fxg0W4nTz9N1O1tXn8gXkkIMIfPQsDQB39FJ1rF8N+KbTxMdQFrDNF9gumt pPNA+Zh3GD0oA26KiuJltraWdgSsSFyB1IAzXE6N8WtG1a7tIZNP1GxivZPK t7m4iAikfONu4E9+KAO7oqlqOojThCWtZ5/OkEY8kKcE9M5IrD1H4h6Hplta zzrdst1v2COAsV2NtO4duelAHjEUayWkIOeEUgg4IOK3vCOgJresJaC+jtPI 2zgOu5pcNkgcj05+tc7BLIkFv5gQK6qoweRx3qza6jJZX1rfwwq/2a4R1Lvg Ehv5V4sNKivtc+5xHv4ZqGkrdvI+hmtoHgMDwRtCRgxlAVP4V5T8StEs9O1m 1u7X7PGJ4vL+zRoFMe3J3YHY5x9a1tO+Ko+xXbapaRR3MaBrZIWbFwf7vIOD 059K4LXtZn1zxDc6gbOOJpkTKCbOMLjqQOOK7q9SEqej3PAy/C1qWJTmmkt+ vyK9ez/D/wD5EfTP9xv/AENq8Rjt2i2lHG/GHyCQx9a9u+H2f+EG0zPXY3T/ AH2rHBJKTszuzyTdKF1bX9Cj8Wf+Sbar9I//AEYtc/8A81H8C/8AYHP/AKLN d74l0OHxJ4evNInkMSXKbfMUZKEHIOO/IFcv4a8B6xZ+ILPV/EGtRX7aZbfZ rKOGLYFXGMse5wf/AK9ekfLl74p/8k31j/rmv/oa1xfhqXUW+IHhl/E0MVuf 7L2aV9m+ZJBs/jJOQdpP44r0nxdocniXwve6PFOsD3KhRIy5C4YHp+Fc5oHg DVLbXtP1bX9cTUDpUHk2UMUAjVBjbk+vFAHeV598G/8AkXtW/wCwvP8AySu1 1WK/m0u4j0u4jt71kxDLKu5Ub1I71j+BfCsnhHQnsp7sXdxPcPcTSKu1SzYH A9OBQByXjWXV4fi9oj6Fb29xfDTpNkdwxVCMvnJHtXpGntePp9u+oRxxXbRq Z0iOVV8cgH0zXKeKvB2tat4qsvEGiazDp1xaWxgBkg8zqWycHjo1dFoNtq1p paQ61qEd/eBmLTxxCMEZ4GB6CgDjMI3x4uRJjYdEw2T23DNdZ4Vs9CsdDjg8 OSRSaeHYo0U3mruJ5+bJ71heKfBWrX/iNPEHh7V49PvWtTaTCaLerIe49D/g K2/CHhuLwn4bttHimM5iyzyEY3MTknHYUAcz8ZP+RY0//sKQ/wAmr0Gua8ce FpvFmlWtlDdJbNBdpcFnUsCFB44+tdLQB5V8V7xvD/iGw1pQQLnTbuyJH94r 8n6t+lczodi9l4j0fwVKWfyNWi1Agjgr5Csf1Br1Lx54N/4TPT7K2FwsDWt0 sxZlzlcEMPxpG8Fg/EiPxYs6BEtPJ8jZzvwRuz6beKAOnl/1T/7prwX/AJoe P+w5/WvfCAQQehrzH/hVOqbv7I/t5P8AhHPtv2z7N5P73P8Ad3envn3xQB6W v+oH+7/SvnjT59S1Pw1a+FDaRQWGp60wXUHk/jBGV2joenPevorb8u0ccYrz ofC+5XwYNFXUoReQ6l9vt7nyzhD6YznpmgD0RFCIqDooArz34S/e8Uf9hmWv Qk3CNd5BfA3EdM159pPgXxXoWq3c2meJbaGzvL1rmaA2gYsC2SMnOOOOKAO4 1X/kEXn/AF7v/wCgmvEF/wCSSeEj3GuDH/fT17peQG5sp7cMFMsbICe2RivN 9H+FWqwJpdhquvx3Gk6ZcfaY7WG32lnznluuMk/nQB6TNbxXAQSru8tw689G HQ1lT+EdCuQBLYK2CSPnb0A9fYVtUUAfOEADWkQYAgxrwR7Usp2qsaorFzgB umKworm4ESATyYCj+M0j3M5KZnk4bj5zXjey97c+4WK/dr3e39bG/ChiiCEj Iz06D2qIq00wYKqrG+N38Rx1H0rI+1XH/PeT/vs0xLmcO+J5OW5+c+lCpbu4 5YlWUeXT1Oir2f4f/wDIj6Z/uN/6G1fPP2q4/wCe8n/fZr6C+HBJ8AaSSckx Nyf99q6cJDlkzyc5r+0hBWtqdPRRRXoHzgUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH//Z ------_=_NextPart_001_01C7AA03.B1F1873C Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.png Content-Location: image002.png Content-Disposition: inline iVBORw0KGgoAAAANSUhEUgAAAB0AAAAdCAIAAADZ8fBYAAAAAXNSR0IArs4c 6QAABd1JREFUSEt1VklvHEUU7n2ZrT2Og2PHWRwnImLJIpEIIRkOHDgAQgoX Dkgc4IbIf0DcuXCKhMQv4A8gESlYxCQE4oCUjQSvM97G09PT02ttfDU9scdO KD3Z1d31vnr1ve+9GlUIobxoUC62IvrXRjq/lt7dSJpBPulZF444b0255444 h13d0FWMF/ripfo8LhfKakC/nW+tdMXscff8uD09atcsNcrZapAtbGY/L2Yn PfXq5ZGpmvV/6Adxo5z/sNCZW0k/fsWbPVEyVSWmKuUcIaREy5hyqKRYmvhl Jf7xfvDuSfuTV6sV29S0g4Hvw23F4rtbrbJtvzdT8Rytlwn2jKWYKA9abLMn KpY+4qpnRjVH59cXu5Tmn1+s1Us2KBmmZQ8XkX5zo3V6rHRuvIQAhOD0GfOG qmxEYskXo656YkTF9ssd4bnatCce7iTNTvzlpdqICydtF3qAy7n4+oaM9LWX yrqq7MSsauujzl4ERdyapmDS6LInvnyuO9pUTdxvJQpLv3qjalnWLrRWJPSn p70HLT7tuUs+m1smf2/xOw26FTEuBGHSIA8YnjuZCIlyqq6OV9TlgK4EAl53 NsRCI2RslzZF4hLKr93pvH2ish2LZshzxhnnnYxtRywmIuciYwPDI05zrKZW TKUd4yvHenjB99pCliQJ54CWR5G4txpJyqFGvRnSMKcZ431jqqYi3pxJI1wa JtBGRsVKlzaQM8GwHl7w3cz0+9sZIYT3xaOB2Zsr0bGa3U64n7GU8pRJyygL M54QRR5fiISIpQ77rZH+uU7ubpA/mnlMOT5hPbzgC4R7zV6e54gXA7hsfi1z Tb0V8zhnGeUZkYZdH+2Qe1vZZoi5mjPlaZs8bJHlDtnsUTA+WEmlF3yB8PuW gngxwARw+aNWisjbSZ4QLuPtG6gIUvq4lc+vxdcXo6UOcQxJ3E4MXJLQ/sn6 Bi/44tO9Fu+DYnDJb0wVENfL+nBDhkdkxk/5kza5u55ahnZ50j4+Yo5XzBEH FfYsAsrhCwSwAVyoQvKLf2OurH0KErE527OCaLxElUzW9LGSVrW1M4ess4fN ixPOpaNlaL2XU0m0EEA4Xh0UkuQX2C97IsyJqiHd4PegRYRiTdnUBFehM4gB lvZrEdtQBXMoRyKcrQzEMNDZ7FG9nTCIHkxJivcbxL4ZZbcb8VIgSRzIjkEn HIIpUg1fIFyYLKHeikLTdF0/P1n5t42vkIDM8m5CdieEKRu9/HEr8VNZUcBB VhshRQXHuYAXfIHwei0rQFH+En7GU9+fTPwcPCoZZP+c4Xg5B9EK0liU32pA fl3trvdyrkgv+AKhbgnTNBFov5NommkYV06pW0GMGjUAvV8VxSPI6WQEPQ8+ a0F+c6271SNoQlgPL/gCQUKZprxF5FTTbbSxo97VmR2/l6C9mpoKlJzuN8b9 hHZTFqbiiZ9thOgiAiuxHl7wnbBJqVQCbh9axqsahuG4pQ/Ojn5YbwZhD1lG k0Q3QC53Ow44RZmshvl6j7QiWaxYg5VYf2W08c5R07QdDLTKfrx9fg3DxKtS pfrZhfqnY0t+p6Pq+pRne7Ze3C9IYCEDIKK0bEOZGnGwBiux/qPTjm5a5XLZ dV0EW0hi0NcppVEUBRh++/Y/ze8XK0/Z4Wqt6lkqPiH7UJuuq46BrOhBLsJu OKNvfzHdOzdVN2ynXq/XajXg2rZT3HUDXJwLhQdo3/fDoBN0OnNr6dy62syd rl5NtCpTTV0Ql4c1Fk5a6eyEeHPCdFzXcVyAVioVxDt8X+zdb4BGdaM3I+hu txvHUZZlfphsxyyIElDhGJpXdg+5qudahgkRGdUqoqwhXQAtFHbwfiv0XEQN aIwwDBF+miZAZ5IH2U0kC7oG/SBMYAERA2EORzoojQO/S2SPQxXkOWgFepqm RUsd3AJ9hRYDqcYGfUSEue+S3+O32GR3FIEDC+iY4G+x/UDxmgYSihIYvtuH EV7wO2oYHWg4wIEzFQJ9PsZh3P8A9OAgCrvQHUQAAAAASUVORK5CYII= ------_=_NextPart_001_01C7AA03.B1F1873C-- --===============1537631381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1537631381==-- From p2psip-bounces@ietf.org Sat Jun 09 16:40:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx7jB-0007Ss-6e; Sat, 09 Jun 2007 16:40:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hx7j9-0007Sf-Rd for p2psip@ietf.org; Sat, 09 Jun 2007 16:40:03 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hx7j9-0006rH-7a for p2psip@ietf.org; Sat, 09 Jun 2007 16:40:03 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l59Kdu7b001968; Sat, 9 Jun 2007 23:39:57 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 23:39:56 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 9 Jun 2007 23:39:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP Date: Sat, 9 Jun 2007 23:42:02 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04824FDC@esebe102.NOE.Nokia.com> In-Reply-To: <002601c7a81e$8b57c9a0$6905a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] STUN/TURN role in P2PSIP Thread-Index: AcenQNuuvauvgN4DRzCnD+6vOtvD7gAIws1gAC2LNbAArhURQA== References: <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> <002601c7a81e$8b57c9a0$6905a40a@china.huawei.com> From: To: , X-OriginalArrivalTime: 09 Jun 2007 20:39:56.0127 (UTC) FILETIME=[56EA56F0:01C7AAD6] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jiang, Comments inline..=20 >-----Original Message----- >From: ext JiangXingFeng [mailto:jiang.x.f@huawei.com]=20 >Sent: 06 June, 2007 12:39 >To: Matuszewski Marcin (Nokia-NRC/Helsinki); p2psip@ietf.org >Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP > >Hi: >> Everything depends on the case scenario and the type of NATs. Case >> scenarios: >> 1. The P2PSIP overlay may be operated by a service provider. In this=20 >> case the service provider makes sure that there is enough=20 >peers with a=20 >> public address and TURN/STUN server functionality in the=20 >overlay. Not=20 >> all of the peers implement a TURN/STUn server. >> 2. In other scenario the service provider may outsource=20 >maintenance of=20 >> TURN/STUN servers to other entity. In this scenario=20 >TURN/STUN servers=20 >> are external to P2PSIP overlay. TURN/STUN server's IP/port is=20 >> registered in DHT. >> 3. The last option assumes that P2PSIP software is only run=20 >in the end=20 >> devices. In this case we may have problems with increased=20 >load on some=20 >> peers due to media relaying. > >I agree that different scenarios will choose how to deploy=20 >STUN/TURN server in their own environment. But equipping a=20 >peer or client having a public address with STUN/TURN=20 >functionalities and choosing them to serve for other peers=20 >will make full use of distributed processing power in the=20 >overlay. As for increased load on these peers due to media=20 >relaying, I think peers could accept or reject the service=20 >requests from other peers or clients according to their own=20 >processing capability. It will guarantee the communication=20 >quality as much as possible.=20 > Agree, I just want to make sure that we do not require all peers/clients having a public address to support STUN/TURN server functionality. It is up to a developer to decide what a particular client/peer supports. >Clients may be more appropriate being a STUN/TURN server than=20 >Peers. Peers should maintain overlay topology and route=20 >message what clients would not do this kind of work.=20 We may also have dedicated STUN/TURN servers that use the client protocol to put their contact information to a DHT so other nodes (peers/clients) can locate them and use their services. This can be realized using a generic XML over HTTP client protocol that supports PUT/GET operations or/and we can create a new event package for SIP. =20 > >> Concerning NATs I checked the statistics you sent us very=20 >quickly and=20 >> I did not notice any information about what types of nats are we=20 >> speaking about. We may have a problem if most of connections require=20 >> media relaying. Besides, we may have different nats in=20 >enterprise and=20 >> residential networks. Many residential wifi routers support UPnP IGD. >Some peers behind NAT do not need other peer's help, for=20 >example in the case of NATs supporting UPnP IGD. But most of=20 >the existing NATs do not support similar functionality, so I=20 >think STUN/TURN/ICE is required when address NAT traversal=20 >issue at present.=20 Agree, but we should not forget about UPnP IGD. It is supported by many wifi routers.=20 Marcin > >Regards! >JiangXingFeng > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 10 21:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxZ24-0004nV-QQ; Sun, 10 Jun 2007 21:49:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxZ24-0004nQ-07 for p2psip@ietf.org; Sun, 10 Jun 2007 21:49:24 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxZ22-000873-I7 for p2psip@ietf.org; Sun, 10 Jun 2007 21:49:23 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJG00LCK7P223@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 11 Jun 2007 09:48:38 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJG00HTS7P1MA@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 11 Jun 2007 09:48:38 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJG00D7L7OYBC@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 11 Jun 2007 09:48:37 +0800 (CST) Date: Mon, 11 Jun 2007 09:48:33 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP In-reply-to: <4d4304a00706080742s4f2ff74fmda513e720c1b77c7@mail.gmail.com> To: "'David A. Bryan'" Message-id: <002701c7abca$9f013b30$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acep20yELVArg6aGS1yLqGzufcBYTAB7bpHw X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, David: > So in my personal opinion, we should definitely be standardizing the > mechanism for NAT traversal. We want to be able to have a P2PSIP cloud > of devices from vendors X, Y, and Z, all of which together, and I > don't see how we do that without explicitly standardizing the NAT > traversal aspects. In this respect, I can't agree with you any more. Because P2P overlay is a network whose underlying links are TCP/UDP or other connections in the IP network, NAT problem should be solved in order to make these connections active. Other than overlay connectivity, media connections should also address NAT problem in P2PSIP case. Regards! -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 10 22:01:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxZDi-0006iv-Gv; Sun, 10 Jun 2007 22:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxZDg-0006ii-RE for p2psip@ietf.org; Sun, 10 Jun 2007 22:01:24 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxZDf-0005Gn-CZ for p2psip@ietf.org; Sun, 10 Jun 2007 22:01:24 -0400 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 <0JJG00MGD890N3@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 11 Jun 2007 10:00:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJG00CA488ZU9@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 11 Jun 2007 10:00:36 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJG00D4S88VBC@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 11 Jun 2007 10:00:35 +0800 (CST) Date: Mon, 11 Jun 2007 10:00:31 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP In-reply-to: <3F18E76823C95E4795181D74BAC7664F04824FDC@esebe102.NOE.Nokia.com> To: marcin.matuszewski@nokia.com, p2psip@ietf.org Message-id: <002801c7abcc$4af9a020$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcenQNuuvauvgN4DRzCnD+6vOtvD7gAIws1gAC2LNbAArhURQAA+FmPw X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Marcin: See inline. Regards! -- Jiang XingFeng > Agree, I just want to make sure that we do not require all peers/clients > having a public address to support STUN/TURN server functionality. It is > up to a developer to decide what a particular client/peer supports. > Yes, Should we make it an option that Peers/clients having a public address supports STUN/TURN server in case NATed Peers/Clients really needs their help? > We may also have dedicated STUN/TURN servers that use the client > protocol to put their contact information to a DHT so other nodes > (peers/clients) can locate them and use their services. This can be > realized using a generic XML over HTTP client protocol that supports > PUT/GET operations or/and we can create a new event package for SIP. Yes, I like this style. But what key is their contact information under? A general mechanism is to encode the NAT traversal service and get a key by applying hash function to the encoded service. The resulting key K is an associated key with the service. By using this key, NATed Peers/Clients could get their contact information. But this will make the admitting peer for K overwhelmed with huge amounts of lookup requests and easily fail. Could you have any proposal for this issue in minde? > > > Agree, but we should not forget about UPnP IGD. It is supported by many > wifi routers. Yes, we should take it into consideration. If there are some others, we should consider them as well. > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 10 22:43:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxZsV-0003bH-JX; Sun, 10 Jun 2007 22:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxZsU-0003b9-Ei for p2psip@ietf.org; Sun, 10 Jun 2007 22:43:34 -0400 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxZsS-00067I-Uz for p2psip@ietf.org; Sun, 10 Jun 2007 22:43:34 -0400 Received: by nz-out-0506.google.com with SMTP id z31so1059227nzd for ; Sun, 10 Jun 2007 19:43:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=g1g2koz5QwhPjFBZKu7BSX5xX/oYgJwoSycFbJr7H6xe/W5bJNoSyWM3U6bZ9rs/YbtMgCBRMZOnJ1OcarwFM7EJFljsDVFSfs5xoLXjeO8XB4zbDIB0T9TmhWs9xfb4WzghHYMrP3VkSI0SuXVQioz5s7PYXDpzDABXC6zx8jw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=ijtAVc2UWkBlGumdhqKshCRe724thYXct62m8EtX9HYSYSIwL8jQoX9hMVOi3cmGtfnEUnNMaIgpwSiazys1OLPVa+H6FjTpNAIcHtRPO/gEx0N37RJbu9O/IW+wZL7mARQr7Mov6PlMwA0ZKNakjXfxiPobgGNryRd95gxHHVU= Received: by 10.115.33.1 with SMTP id l1mr5086131waj.1181529811533; Sun, 10 Jun 2007 19:43:31 -0700 (PDT) Received: by 10.114.171.10 with HTTP; Sun, 10 Jun 2007 19:43:31 -0700 (PDT) Message-ID: <894e079b0706101943qdcb3abq21f89b96fefa097f@mail.gmail.com> Date: Sun, 10 Jun 2007 22:43:31 -0400 From: "Medhavi Bhatia" To: "David A. Bryan" Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP In-Reply-To: <4d4304a00706080742s4f2ff74fmda513e720c1b77c7@mail.gmail.com> MIME-Version: 1.0 References: <000101c7a740$dbecc020$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com> <004301c7a788$f6ec7170$a507740a@DELLWEI> <46697608.7010603@idssoftware.com> <4d4304a00706080742s4f2ff74fmda513e720c1b77c7@mail.gmail.com> X-Google-Sender-Auth: 9e09d4c4e8e59b7d X-Spam-Score: 0.5 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1574521599==" Errors-To: p2psip-bounces@ietf.org --===============1574521599== Content-Type: multipart/alternative; boundary="----=_Part_68980_25461214.1181529811481" ------=_Part_68980_25461214.1181529811481 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I would agree. The nat traversal mechanism is actually part of the control protocol which the p2p protocol rides on (or over). It is impossible to implement an open p2p network w/o having an open standard nat traversal method. (BTW, there is a short article of interest (non promotional :) on http://www.3clogic.com/p2p-deploy.html). On 6/8/07, David A. Bryan wrote: > > The problem with this approach is that it essentially means there is > no way defined that two different implementers can both code to and be > assured their systems would work together. Having a "common practice" > (particularly the one proposed below that relies on a non-standardized > service) isn't something that an implementer can use to guarantee > their software will interoperate with another through NATs. > > So in my personal opinion, we should definitely be standardizing the > mechanism for NAT traversal. We want to be able to have a P2PSIP cloud > of devices from vendors X, Y, and Z, all of which together, and I > don't see how we do that without explicitly standardizing the NAT > traversal aspects. > > My 2 cents... > > David > > On 6/8/07, Michael Chen wrote: > > Hi, > > > > I agree that STUN/TURN/ICE should be left to the p2psip application > > instead of the standard for p2psip. What the standard body can do is to > > produce a recommendation for common practices in regarding NAT > traversal. > > > > For example, you can recommend using the OpenDHT project to serve as a > > "centralized" location for UAs to communicate resources such as who can > > serve as a STUN server. > > > > --Michael > > > > Wei Gengyu wrote: > > > Hi, > > > > > > What you said is right, "Everything depends on the case scenario and > the type of NATs. " > > > To make it concrete, we see the two widely deployed applications, > Skype and BT. > > > Skype is operated by a service provider and needs centralized > registation. > > > BT support any user to deliver torrent file while giving the seed and > tracker addresses. > > > > > > Currently, you can use these two p2p applicatios by downloading > different softwares, > > > each software would have its own mechanism to process NAT. > > > > > > Bur , the problems are: > > > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate > processing NAT? > > > (2) Shall we rely on application softwares just as now. > > > > > > Regards, > > > > > > Gengyu > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_68980_25461214.1181529811481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I would agree. The nat traversal mechanism is actually part of the control protocol which the p2p protocol rides on (or over). It is impossible to implement an open p2p network w/o having an open standard nat traversal method.

(BTW, there is a short article of interest (non promotional :) on http://www.3clogic.com/p2p-deploy.html).

On 6/8/07, David A. Bryan <dbryan@sipeerior.com> wrote:
The problem with this approach is that it essentially means there is
no way defined that two different implementers can both code to and be
assured their systems would work together. Having a "common practice"
(particularly the one proposed below that relies on a non-standardized
service) isn't something that an implementer can use to guarantee
their software will interoperate with another through NATs.

So in my personal opinion, we should definitely be standardizing the
mechanism for NAT traversal. We want to be able to have a P2PSIP cloud
of devices from vendors X, Y, and Z, all of which together, and I
don't see how we do that without explicitly standardizing the NAT
traversal aspects.

My 2 cents...

David

On 6/8/07, Michael Chen <michaelc@idssoftware.com> wrote:
> Hi,
>
> I agree that STUN/TURN/ICE should be left to the p2psip application
> instead of the standard for p2psip. What the standard body can do is to
> produce a recommendation for common practices in regarding NAT traversal.
>
> For example, you can recommend using the OpenDHT project to serve as a
> "centralized" location for UAs to communicate resources such as who can
> serve as a STUN server.
>
> --Michael
>
> Wei Gengyu wrote:
> > Hi,
> >
> > What you said is right,  "Everything depends on the case scenario and the type of NATs. "
> > To make it concrete, we see the two widely deployed applications, Skype and BT.
> > Skype is operated by a service provider and needs centralized registation.
> > BT support any user to deliver torrent file while giving the seed and tracker addresses.
> >
> > Currently, you can use these two p2p applicatios by downloading different softwares,
> > each software would have its own mechanism to process NAT.
> >
> > Bur , the problems are:
> > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT?
> > (2) Shall we rely on application softwares just as now.
> >
> > Regards,
> >
> > Gengyu
> >
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>


--
David A. Bryan
dbryan@SIPeerior.com
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_68980_25461214.1181529811481-- --===============1574521599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1574521599==-- From p2psip-bounces@ietf.org Sun Jun 10 23:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxac8-0005vs-La; Sun, 10 Jun 2007 23:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxac7-0005rP-RE for p2psip@ietf.org; Sun, 10 Jun 2007 23:30:43 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hxac5-0006KB-N1 for p2psip@ietf.org; Sun, 10 Jun 2007 23:30:43 -0400 Received: from DELLWEI (unknown [59.64.158.162]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 2202DAC2606 for ; Mon, 11 Jun 2007 11:30:28 +0800 (CST) Message-ID: <001201c7abd8$dcd28be0$a29e403b@DELLWEI> From: "Wei Gengyu" To: References: <002701c7abca$9f013b30$6905a40a@china.huawei.com> Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP Date: Mon, 11 Jun 2007 11:30:21 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1672431970==" Errors-To: p2psip-bounces@ietf.org --===============1672431970== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpQMlBTSVAgc2hvdWxkIGRlZmluZSBzdGFuZGFyZCBOQVQgdHJhbnZlcnNpbmcgYXJj aGl0ZWN0dXJlIGFuZCBtZWNoYW5pc20uIA0KDQpJICdkIGxpa2UgdG8gbWVudGlvbiAiVGhlIEVm ZmVjdCBvZiBOQVRzIG9uIFAyUCBTSVAgT3ZlcmxheSBBcmNoaXRlY3R1cmUgLS0gZHJhZnQtbWF0 dGhld3MtcDJwc2lwLW5hdHMtYW5kLW92ZXJsYXlzLTAwIg0KSSB0aGluayBpdCBzaG91bGQgYmUg YSBnb29kIHN0YXJ0IGZvdCBQMlBTSVAgdG8gZGVmaW5lIG1lY2hhbmlzbXMgb2YgTkFUIHRyYXZl cnNpbmcuDQoNCkluIHRoYXQgZHJhZnQtcmZjLCBpdCB3YXMgcmVjb21tZW5kZWQgdGhhdCBJQ0Ug Y2FuIGJlIHVzZWQgZm9yIHRoZSBleGNoYW5nZSBvZiBtZWRpYSBtZXNzYWdlcywgDQphbmQgIHRo ZSBwcm9ibGVtIG5lZWRzIHRvIHNvbHZlIGlzIHRvIGZpbmRpbmcgYSB3YXkgZm9yIHBlZXJzIHRv IGV4Y2hhbmdlIHNpZ25hbGluZyBtZXNzYWdlcy4NCg0KSSBhbHNvIHdvdWxkIGxpa2UgdG8ga25v dyBpZiB0aGVyZSBpcyBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQtcmZjIGFzIGl0IHdhcyBleHBp cmVkIG9uIEF1Z3VzdCAyOCwgMjAwNi4NCg0KUmVnYXJkcywNCg0KR2VuZ3l1DQoNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKaWFuZ1hpbmdGZW5nIiA8amlhbmcueC5m QGh1YXdlaS5jb20+DQpUbzogIidEYXZpZCBBLiBCcnlhbiciIDxkYnJ5YW5Ac2lwZWVyaW9yLmNv bT4NCkNjOiA8cDJwc2lwQGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBKdW5lIDExLCAyMDA3IDk6 NDggQU0NClN1YmplY3Q6IFJFOiBbUDJQU0lQXSBTVFVOL1RVUk4gcm9sZSBpbiBQMlBTSVANCg0K DQo+IEhpLCBEYXZpZDoNCj4gDQo+PiBTbyBpbiBteSBwZXJzb25hbCBvcGluaW9uLCB3ZSBzaG91 bGQgZGVmaW5pdGVseSBiZSBzdGFuZGFyZGl6aW5nIHRoZQ0KPj4gbWVjaGFuaXNtIGZvciBOQVQg dHJhdmVyc2FsLiBXZSB3YW50IHRvIGJlIGFibGUgdG8gaGF2ZSBhIFAyUFNJUCBjbG91ZA0KPj4g b2YgZGV2aWNlcyBmcm9tIHZlbmRvcnMgWCwgWSwgYW5kIFosIGFsbCBvZiB3aGljaCB0b2dldGhl ciwgYW5kIEkNCj4+IGRvbid0IHNlZSBob3cgd2UgZG8gdGhhdCB3aXRob3V0IGV4cGxpY2l0bHkg c3RhbmRhcmRpemluZyB0aGUgTkFUDQo+PiB0cmF2ZXJzYWwgYXNwZWN0cy4NCj4gDQo+IEluIHRo aXMgcmVzcGVjdCwgSSBjYW4ndCBhZ3JlZSB3aXRoIHlvdSBhbnkgbW9yZS4gQmVjYXVzZSBQMlAg b3ZlcmxheSBpcyBhDQo+IG5ldHdvcmsgd2hvc2UgdW5kZXJseWluZyBsaW5rcyBhcmUgVENQL1VE UCBvciBvdGhlciBjb25uZWN0aW9ucyBpbiB0aGUgSVANCj4gbmV0d29yaywgTkFUIHByb2JsZW0g c2hvdWxkIGJlIHNvbHZlZCBpbiBvcmRlciB0byBtYWtlIHRoZXNlIGNvbm5lY3Rpb25zDQo+IGFj dGl2ZS4gT3RoZXIgdGhhbiBvdmVybGF5IGNvbm5lY3Rpdml0eSwgbWVkaWEgY29ubmVjdGlvbnMg c2hvdWxkIGFsc28NCj4gYWRkcmVzcyBOQVQgcHJvYmxlbSBpbiBQMlBTSVAgY2FzZS4gDQo+IA0K PiBSZWdhcmRzIQ0KPiAtLQ0KPiBKaWFuZyBYaW5nRmVuZw0KPiANCj4gDQo+IA0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUDJQU0lQIG1h aWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcDJwc2lwDQo+ --===============1672431970== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1672431970==-- From p2psip-bounces@ietf.org Mon Jun 11 03:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdw4-0007ox-Ed; Mon, 11 Jun 2007 03:03:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hxdw2-0007os-Aj for p2psip@ietf.org; Mon, 11 Jun 2007 03:03:30 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hxdw0-00042B-Ae for p2psip@ietf.org; Mon, 11 Jun 2007 03:03:30 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 11 Jun 2007 00:03:25 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5B73MWs009335; Mon, 11 Jun 2007 00:03:23 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5B725I9010264; Mon, 11 Jun 2007 00:02:05 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jun 2007 00:03:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] STUN/TURN role in P2PSIP Date: Mon, 11 Jun 2007 00:02:54 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22949621@namail5.corp.adobe.com> In-Reply-To: <894e079b0706101943qdcb3abq21f89b96fefa097f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] STUN/TURN role in P2PSIP Thread-Index: Acer0mANFiwUwVN0S1WLFWFbxpjMZQAI1AAg References: <000101c7a740$dbecc020$6905a40a@china.huawei.com><3F18E76823C95E4795181D74BAC7664F047A403B@esebe102.NOE.Nokia.com><004301c7a788$f6ec7170$a507740a@DELLWEI><46697608.7010603@idssoftware.com><4d4304a00706080742s4f2ff74fmda513e720c1b77c7@mail.gmail.com> <894e079b0706101943qdcb3abq21f89b96fefa097f@mail.gmail.com> From: "Henry Sinnreich" To: "Medhavi Bhatia" , "David A. Bryan" X-OriginalArrivalTime: 11 Jun 2007 07:03:21.0450 (UTC) FILETIME=[98A36CA0:01C7ABF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c40ff0c70161549dbde2f89c7946385a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0785885791==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0785885791== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7ABF6.97DDA292" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7ABF6.97DDA292 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable >(BTW, there is a short article of interest (non promotional :) on http://www.3clogic.com/p2p-deploy.html). =20 This is an excellent article and should be promoted and also discussed, for example for these three items of interest for P2P SIP: =20 - Is Chord really the preferred solution for the DHT? - Why muddle the waters with SBCs? This is a design decision for CS VoIP networks. - CALEA for VoIP has not yet been voted on by Congress or accepted in the IETF for valid reasons. Is CALEA for VoIP just another attempt to create a market for more equipment? =20 Let the flames come :-) =20 Thanks, Henry =20 ________________________________ From: Medhavi Bhatia [mailto:mbhatia@3clogic.com]=20 Sent: Monday, June 11, 2007 4:44 AM To: David A. Bryan Cc: p2psip@ietf.org Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP =20 I would agree. The nat traversal mechanism is actually part of the control protocol which the p2p protocol rides on (or over). It is impossible to implement an open p2p network w/o having an open standard nat traversal method.=20 (BTW, there is a short article of interest (non promotional :) on http://www.3clogic.com/p2p-deploy.html). On 6/8/07, David A. Bryan wrote: The problem with this approach is that it essentially means there is no way defined that two different implementers can both code to and be assured their systems would work together. Having a "common practice"=20 (particularly the one proposed below that relies on a non-standardized service) isn't something that an implementer can use to guarantee their software will interoperate with another through NATs. So in my personal opinion, we should definitely be standardizing the=20 mechanism for NAT traversal. We want to be able to have a P2PSIP cloud of devices from vendors X, Y, and Z, all of which together, and I don't see how we do that without explicitly standardizing the NAT traversal aspects.=20 My 2 cents... David On 6/8/07, Michael Chen wrote: > Hi, > > I agree that STUN/TURN/ICE should be left to the p2psip application=20 > instead of the standard for p2psip. What the standard body can do is to > produce a recommendation for common practices in regarding NAT traversal. > > For example, you can recommend using the OpenDHT project to serve as a > "centralized" location for UAs to communicate resources such as who can > serve as a STUN server. > > --Michael > > Wei Gengyu wrote: > > Hi, > > > > What you said is right, "Everything depends on the case scenario and the type of NATs. "=20 > > To make it concrete, we see the two widely deployed applications, Skype and BT. > > Skype is operated by a service provider and needs centralized registation. > > BT support any user to deliver torrent file while giving the seed and tracker addresses.=20 > > > > Currently, you can use these two p2p applicatios by downloading different softwares, > > each software would have its own mechanism to process NAT. > > > > Bur , the problems are:=20 > > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT? > > (2) Shall we rely on application softwares just as now. > > > > Regards, > > > > Gengyu > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =20 ------_=_NextPart_001_01C7ABF6.97DDA292 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

>(BTW, there is a = short article of interest (non promotional :) on http://www.3clo= gic.com/p2p-deploy.html).

 

This is an excellent article and should be promoted and also = discussed, for example for these three items of interest for P2P = SIP:

 

-          Is Chord really the = preferred solution for the DHT?

-          Why muddle the waters with = SBCs? This is a design decision for CS VoIP networks.

-          CALEA for VoIP has not yet = been voted on by Congress or accepted in the IETF for valid reasons.  Is = CALEA for VoIP just another attempt to create a market for more = equipment?

 

Let the flames come J

 

Thanks, Henry

 

From: = Medhavi Bhatia [mailto:mbhatia@3clogic.com]
Sent: Monday, June 11, = 2007 4:44 AM
To: David A. Bryan
Cc: = p2psip@ietf.org
Subject: Re: [P2PSIP] = STUN/TURN role in P2PSIP

 

I would agree. = The nat traversal mechanism is actually part of the control protocol which the = p2p protocol rides on (or over). It is impossible to implement an open p2p = network w/o having an open standard nat traversal method.

(BTW, there is a short article of interest (non promotional :) on http://www.3clogic.com/p2= p-deploy.html).

On 6/8/07, David A. Bryan <dbryan@sipeerior.com> wrote:

The problem with this approach is that it essentially means = there is
no way defined that two different implementers can both code to and = be
assured their systems would work together. Having a "common = practice"
(particularly the one proposed below that relies on a = non-standardized
service) isn't something that an implementer can use to guarantee
their software will interoperate with another through NATs.

So in my personal opinion, we should definitely be standardizing the =
mechanism for NAT traversal. We want to be able to have a P2PSIP = cloud
of devices from vendors X, Y, and Z, all of which together, and I
don't see how we do that without explicitly standardizing the NAT
traversal aspects.

My 2 cents...

David

On 6/8/07, Michael Chen <michaelc@idssoftware.com>= wrote:
> Hi,
>
> I agree that STUN/TURN/ICE should be left to the p2psip application =
> instead of the standard for p2psip. What the standard body can do = is to
> produce a recommendation for common practices in regarding NAT = traversal.
>
> For example, you can recommend using the OpenDHT project to serve = as a
> "centralized" location for UAs to communicate resources = such as who can
> serve as a STUN server.
>
> --Michael
>
> Wei Gengyu wrote:
> > Hi,
> >
> > What you said is right,  "Everything depends on = the case scenario and the type of NATs. "
> > To make it concrete, we see the two widely deployed = applications, Skype and BT.
> > Skype is operated by a service provider and needs centralized registation.
> > BT support any user to deliver torrent file while giving the = seed and tracker addresses.
> >
> > Currently, you can use these two p2p applicatios by = downloading different softwares,
> > each software would have its own mechanism to process NAT.
> >
> > Bur , the problems are:
> > (1) Is it necessary to make P2PSIP define any mechanisms to facilitate processing NAT?
> > (2) Shall we rely on application softwares just as now.
> >
> > Regards,
> >
> > Gengyu
> >
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>


--
David A. Bryan
dbryan@SIPeerior.com
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

 

------_=_NextPart_001_01C7ABF6.97DDA292-- --===============0785885791== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0785885791==-- From p2psip-bounces@ietf.org Mon Jun 11 12:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxmRJ-000313-LB; Mon, 11 Jun 2007 12:08:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HxmRI-00030y-Gl for p2psip@ietf.org; Mon, 11 Jun 2007 12:08:20 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HxmRH-0001C4-K4 for p2psip@ietf.org; Mon, 11 Jun 2007 12:08:20 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1HxmRQ-0005RU-D7; Mon, 11 Jun 2007 12:08:28 -0400 In-Reply-To: <001201c7abd8$dcd28be0$a29e403b@DELLWEI> References: <002701c7abca$9f013b30$6905a40a@china.huawei.com> <001201c7abd8$dcd28be0$a29e403b@DELLWEI> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] STUN/TURN role in P2PSIP Date: Mon, 11 Jun 2007 12:08:24 -0400 To: Wei Gengyu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 10-Jun-07, at 23:30 , Wei Gengyu wrote: > Hi, > > P2PSIP should define standard NAT tranversing architecture and > mechanism. > > I 'd like to mention "The Effect of NATs on P2P SIP Overlay > Architecture -- draft-matthews-p2psip-nats-and-overlays-00" > I think it should be a good start fot P2PSIP to define mechanisms > of NAT traversing. > > In that draft-rfc, it was recommended that ICE can be used for the > exchange of media messages, > and the problem needs to solve is to finding a way for peers to > exchange signaling messages. > > I also would like to know if there is new version of the draft-rfc > as it was expired on August 28, 2006. > > Regards, > A new version of the document mentioned above was published just before the last IETF meeting in March: http://tools.ietf.org/html/draft-matthews-p2psip-nats-and-overlays-01 Also, two documents that together provide one way to realize this architecture using SIP were published at the same time: http://tools.ietf.org/html/draft-matthews-p2psip-bootstrap- mechanisms-00 http://tools.ietf.org/html/draft-matthews-p2psip-dsip-nat-traversal-00 We are doing some further work in this area which we hope to publish soon. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 12 17:18:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDl2-0007SJ-Qd; Tue, 12 Jun 2007 17:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyDl0-0007S1-Pl; Tue, 12 Jun 2007 17:18:30 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyDky-0000P4-Lq; Tue, 12 Jun 2007 17:18:30 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 2C6F4B5FA; Tue, 12 Jun 2007 23:18:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1CE2BB62D; Tue, 12 Jun 2007 23:18:23 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id ACD65B60B; Tue, 12 Jun 2007 23:18:16 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l5CLIFk18805; Tue, 12 Jun 2007 23:18:15 +0200 Received: from Musa (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 30CF26F58E; Tue, 12 Jun 2007 23:13:03 +0200 (CEST) From: "Kurt Tutschku" To: , , , , , , Date: Tue, 12 Jun 2007 23:18:09 +0200 Organization: Uni Wuerzburg Message-ID: <001801c7ad37$2dfefa80$6402a8c0@Musa> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 thread-index: AcetNyzzXBotQg1fS+u8FIIiBTXtcg== X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: "'Andersen, Frank-Uwe'" , csjcao@comp.polyu.edu.hk, ychu@ecn.purdue.edu, "'Maria G. Papadopouli'" , 'CeciliaMascolo' Subject: [P2PSIP] Advanced CfP MP2P'08: 5th IEEE International Workshop on Mobile Peer-to-Peer Computing (MP2P'08) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tutschku@informatik.uni-wuerzburg.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org --------------------------------------------------------------------- * Please, apologize for multiple copies --------------------------------------------------------------------- Advanced Call-for-Paper 5th IEEE International Workshop on Mobile Peer-to-Peer Computing = (MP2P'08) http://www-info3.informatik.uni-wuerzburg.de/mp2p2008 Hong Kong, March 17-21, 2008 In conjunction with the 6th IEEE International Conference on=20 Pervasive Computing and Communications (PerCom=9208) http://www.percom.org/ ---------------------------------------------------------------------- Peer-to-Peer (P2P) computing is a networking and distributed computing paradigm which allows the sharing of computing resources and services by direct, symmetric interaction between computers. The advance in mobile wireless communication technology and the increasing number of mobile = users, extend the arena of P2P computing to encompass mobile devices and = wireless networks. The special characteristics of mobile environments, such as highly variable connectivity, disconnection, location-dependency, = resource contraints, and diversity in wireless networks as well as carrier-grade performance requirements bring new challenges for research in mobile P2P communication and computing. MP2P=9208 is intended to serve as a continuing forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, and research results about all aspects of mobile = P2P computing and communications. It will address the challenges, = technologies, and architectures leading to real-world solutions that provide users = with direct access and control of their critical peer-based information and services, regardless of location or device. The principal theme of MP2P=9208 is the peer-to-peer paradigm as used in mobile ad hoc networks (MANETS), sensor networks, and large-scale heterogeneous overlays. Topics of particular interest include, but are = not limited to: - Peer-to-peer overlays for MANETs and sensor networks - Hybrid P2P architectures for integrated MANETs and wide-area networks - Large-scale heterogeneous P2P systems - Mobility in federated overlay architectures - Impact of network mobility on P2P systems and services (mobile IP / = MANET) - P2P-based information sensing and fusion - MP2P performance & measurement studies - Semantic routing & overlay routing in MP2P - Delay tolerant MP2P systems - Resource and service discovery in MP2P - Resource exchange mechanisms in MP2P - Peer access and control in mobile environment - Data exchange and rendering techniques for mobile P2P devices - Secure communication protocols for MP2P - Nature-inspired algorithms for MP2P - Novel MP2P applications & services - Theoretical issues on mobile information diffusion - MP2P SIP - MP2P messaging systems, monitoring systems, searching systems, games, = etc. - Location dependent MP2P services - MP2P over different bearer services: 2.5/3G (GPRS/UMTS) / 802.11 = (WLAN) - MP2P & operator/provider requirements - Reliability and carrier-grade performance of MP2P services Paper Submission:=20 ----------------- Papers must be written in English and should not exceed 5 pages in IEEE proceedings style.=20 =20 * Upload of the paper. Only in pdf format=20 Submission implies the willingness of at least one of the authors to register and present the paper. All submissions will be reviewed and selected based on their originality of the paper. Accepted papers must = be presented at the workshop and will appear in a combined PerCom 2008 = workshop proceedings published by IEEE Computer Society Press. Paper must not be submitted elsewhere. Authors that present a system in their paper are highly encouraged to demonstrate also the system in the demo session of the workshop. Important Dates: ---------------- Papers due: 5pm EST, September 29, 2007 Notification of acceptance November 25, 2007 Camera-ready papers due December 22, 2007 Organizing Committee, Program Co-chairs: ---------------------------------------- Kurt Tutschku, Department of Distributed Systems, University of = W=FCrzburg, Germany. John Buford, Avaya Labs, USA. Li Li, Communications Research Center Canada, Canada.=20 Steering Board -------------- - Frank-Uwe Andersen, Siemens Communications, Berlin, Germany. - Jiannong Cao, Department of Computing, Hong Kong Polytechnic = University. - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University=20 - Cecilia Mascolo, Department of Computer Science, University College = London - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill=20 Publicity Chair --------------- Kurt Tutschku, Department of Distributed Systems, University of = W=FCrzburg, Germany=20 Program Committee Members: -------------------------- - to be confirmed --- Dr. Kurt Tutschku, Assistant Professor University of Wuerzburg Department of Distributed Systems Institute of Computer Science Am Hubland 97074 Wuerzburg Germany Tel.: +49-931-8886641=20 FAX.: +49-931-8886632=20 mailto:tutschku@informatik.uni-wuerzburg.de=20 or=20 mailto:kurttutschku@hotmail.com=20 http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 13 15:56:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYwx-00089J-5K; Wed, 13 Jun 2007 15:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyYww-00089E-PK for p2psip@ietf.org; Wed, 13 Jun 2007 15:56:14 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyYwv-0004qZ-36 for p2psip@ietf.org; Wed, 13 Jun 2007 15:56:14 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1B335B685 for ; Wed, 13 Jun 2007 21:56:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0E6A3B689 for ; Wed, 13 Jun 2007 21:56:10 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E4BD7B685 for ; Wed, 13 Jun 2007 21:56:09 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l5DJu9k04088 for ; Wed, 13 Jun 2007 21:56:09 +0200 Received: from Musa (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id DCA356F58E for ; Wed, 13 Jun 2007 21:50:57 +0200 (CEST) From: "Kurt Tutschku" To: Date: Wed, 13 Jun 2007 21:56:04 +0200 Organization: Uni Wuerzburg Message-ID: <000501c7adf4$dffeed40$6402a8c0@Musa> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acet9N+tawmUifvYQ0WUxlK4L7K/GQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [P2PSIP] Advanced CfP MP2P'08: 5th IEEE International Workshop onMobile Peer-to-Peer Computing (MP2P'08) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: tutschku@informatik.uni-wuerzburg.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org --------------------------------------------------------------------- * Please, apologize for multiple copies --------------------------------------------------------------------- Advanced Call-for-Paper 5th IEEE International Workshop on Mobile Peer-to-Peer Computing = (MP2P'08) http://www-info3.informatik.uni-wuerzburg.de/mp2p2008 Hong Kong, March 17-21, 2008 In conjunction with the 6th IEEE International Conference on Pervasive Computing and Communications (PerCom=9208) http://www.percom.org/ ---------------------------------------------------------------------- Peer-to-Peer (P2P) computing is a networking and distributed computing paradigm which allows the sharing of computing resources and services by direct, symmetric interaction between computers. The advance in mobile wireless communication technology and the increasing number of mobile = users, extend the arena of P2P computing to encompass mobile devices and = wireless networks. The special characteristics of mobile environments, such as highly variable connectivity, disconnection, location-dependency, = resource contraints, and diversity in wireless networks as well as carrier-grade performance requirements bring new challenges for research in mobile P2P communication and computing. MP2P=9208 is intended to serve as a continuing forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, and research results about all aspects of mobile = P2P computing and communications. It will address the challenges, = technologies, and architectures leading to real-world solutions that provide users = with direct access and control of their critical peer-based information and services, regardless of location or device. The principal theme of MP2P=9208 is the peer-to-peer paradigm as used in mobile ad hoc networks (MANETS), sensor networks, and large-scale heterogeneous overlays. Topics of particular interest include, but are = not limited to: - Peer-to-peer overlays for MANETs and sensor networks - Hybrid P2P architectures for integrated MANETs and wide-area networks - Large-scale heterogeneous P2P systems - Mobility in federated overlay architectures - Impact of network mobility on P2P systems and services (mobile IP / = MANET) - P2P-based information sensing and fusion - MP2P performance & measurement studies - Semantic routing & overlay routing in MP2P - Delay tolerant MP2P systems - Resource and service discovery in MP2P - Resource exchange mechanisms in MP2P - Peer access and control in mobile environment - Data exchange and rendering techniques for mobile P2P devices - Secure communication protocols for MP2P - Nature-inspired algorithms for MP2P - Novel MP2P applications & services - Theoretical issues on mobile information diffusion - MP2P SIP - MP2P messaging systems, monitoring systems, searching systems, games, = etc. - Location dependent MP2P services - MP2P over different bearer services: 2.5/3G (GPRS/UMTS) / 802.11 = (WLAN) - MP2P & operator/provider requirements - Reliability and carrier-grade performance of MP2P services Paper Submission:=20 ----------------- Papers must be written in English and should not exceed 5 pages in IEEE proceedings style.=20 =20 * Upload of the paper. Only in pdf format=20 Submission implies the willingness of at least one of the authors to register and present the paper. All submissions will be reviewed and selected based on their originality of the paper. Accepted papers must = be presented at the workshop and will appear in a combined PerCom 2008 = workshop proceedings published by IEEE Computer Society Press. Paper must not be submitted elsewhere. Authors that present a system in their paper are highly encouraged to demonstrate also the system in the demo session of the workshop. Important Dates: ---------------- Papers due: 5pm EST, September 29, 2007 Notification of acceptance November 25, 2007 Camera-ready papers due December 22, 2007 Organizing Committee, Program Co-chairs: ---------------------------------------- Kurt Tutschku, Department of Distributed Systems, University of = W=FCrzburg, Germany. John Buford, Avaya Labs, USA. Li Li, Communications Research Center Canada, Canada.=20 Steering Board -------------- - Frank-Uwe Andersen, Siemens Communications, Berlin, Germany. - Jiannong Cao, Department of Computing, Hong Kong Polytechnic = University. - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University - Cecilia Mascolo, Department of Computer Science, University College = London - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill=20 Publicity Chair --------------- Kurt Tutschku, Department of Distributed Systems, University of = W=FCrzburg, Germany=20 Program Committee Members: -------------------------- - to be confirmed --- Dr. Kurt Tutschku, Assistant Professor University of Wuerzburg Department of Distributed Systems Institute of Computer Science Am Hubland 97074 Wuerzburg Germany Tel.: +49-931-8886641=20 FAX.: +49-931-8886632=20 mailto:tutschku@informatik.uni-wuerzburg.de=20 or=20 mailto:kurttutschku@hotmail.com=20 http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 13 18:50:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hybf1-0003iJ-QV; Wed, 13 Jun 2007 18:49:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hybf0-0003iB-Rx for p2psip@ietf.org; Wed, 13 Jun 2007 18:49:54 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hybez-0004Rs-Gh for p2psip@ietf.org; Wed, 13 Jun 2007 18:49:54 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Hybhg-0004Yf-Cl; Wed, 13 Jun 2007 17:52:40 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Wed, 13 Jun 2007 17:49:34 -0500 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Philip Matthews Subject: [P2PSIP] Concepts document: proposal for active/passive peer terminology X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm updating the concepts draft, and wanted to kick this around a little bit before I put it into the draft. We've sort of come up with three different sorts of nodes: 1) The "full peer" nodes that actively provide resources (like storage and transport) to the overlay and speak the P2SIP Peer Protocol. 2) Less-than-full peer nodes that either speak some subset of the P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or just natively access the distributed database, but that are lazy and do not contribute their own resources to the overlay. 3) "Clients", which are either #2 above, or just plain-old-SIP UAs depending on who you talk to. I hereby propose to client this up a bit, based on suggestions made on the list, by having two sorts of peers; "active" and "passive", SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including P2PSIP Client Protocol here. An "active peer" is one that contributes resources. A "passive peer" is one that doesn't. The choice of which mode to operate in could be a matter of implementation, or configuration, or could be a runtime decision based on the resources (memory, bandwidth, power, etc.) available to the peer. Peers advertise services that they are contributing with the distributed database. So a peer that has advertised any services at all could be said to be "active", and a peer that hasn't advertised any could be said to be "passive". Things like "transport", "storage", "STUN", "STUN Relay", "SIP Outbound Proxy" and the like would be "Services". Obviously, not all peers would offer all services. We'd expect that most would offer "transport" and "storage", but probably only specialized nodes would offer "SIP Outbound Proxy". I think this greatly simplifies the semantic morass in which we've been wading. How does it sound to you? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 13 19:00:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HybpP-0002Ih-27; Wed, 13 Jun 2007 19:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HybpO-0002Ib-Ou for p2psip@ietf.org; Wed, 13 Jun 2007 19:00:38 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210] helo=kevlar.softarmor.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HybpO-0008QQ-CW for p2psip@ietf.org; Wed, 13 Jun 2007 19:00:38 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by kevlar.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HybsC-00055U-3M for p2psip@ietf.org; Wed, 13 Jun 2007 18:03:32 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Dean Willis Date: Wed, 13 Jun 2007 18:00:24 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [P2PSIP] Concepts issue: Domains and Overlays X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Someone brought this up on the list, and I wanted to clarify the consensus here before nailing it down further in the concepts doc. We think of usernames as domain-scoped, like "joebob@example.com". One model of an overlay allows users to enroll names from many domains. In this model, there might be only one overlay serving every domain in the world, including (for example) "example.com" and "example.net". Clearly routing messages within this overlay is straightforward, and there's no need to talk to any other overlay. In another model, each overlay corresponds to one or more but not all domains, and we use RFC 3263 procedures to route between overlays. So "example.com" might be in one overlay, and "example.net" in another. Each overlay can look up the other in DNS to find it. This second model mostly precludes having one domain scattered across multiple overlays. Here's the deal: Assume we have overlays A and B. Alice@example.com enrolls with overlay A, and Bob@example.com enrolls with overlay B. Alice now wants to call Bob. She looks him up in her overlay, and he's not there. What to do? She can't just look up example.com in DNS, because it has been split across A and B and DNS just doesn't work that way. Now, if both A and B registered with some "upstream" lookup function (a meta-overlay), then Alice could perhaps look there. But this starts to get messy really quickly. So unless we want to solve the namespace-split-across-overlays problem (and that's not easy), we're much better off at this time having a model where each domain can be mapped onto only one overlay at a time. Y'all ok with that? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 13 20:04:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HycpF-0006ec-VN; Wed, 13 Jun 2007 20:04:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HycpE-0006eW-Hj for p2psip@ietf.org; Wed, 13 Jun 2007 20:04:32 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HycpE-0005f1-8A for p2psip@ietf.org; Wed, 13 Jun 2007 20:04:32 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5E04IX5025026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Jun 2007 20:04:22 -0400 (EDT) In-Reply-To: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Wed, 13 Jun 2007 20:04:13 -0400 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I generally agree with your train of thought until it derails in the last paragraph, I think. A slightly weaker requirement that also works and is useful is to require that each domain has a "default" overlay that one must register with if it is available. There is nothing wrong with registering in wild-card domains for special purposes. For example, this can occur when such an overlay is disconnected from the Internet at large. Would you want to set up a per-domain overlay for each and every AOR domain in that case? (I realize that detecting this case can get messy, but this largely depends on how we solve the overlay discovery problem.) Henning On Jun 13, 2007, at 7:00 PM, Dean Willis wrote: > > Someone brought this up on the list, and I wanted to clarify the > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many > domains. In this model, there might be only one overlay serving > every domain in the world, including (for example) "example.com" > and "example.net". Clearly routing messages within this overlay is > straightforward, and there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not > all domains, and we use RFC 3263 procedures to route between > overlays. So "example.com" might be in one overlay, and > "example.net" in another. Each overlay can look up the other in DNS > to find it. > > This second model mostly precludes having one domain scattered > across multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and > he's not there. What to do? She can't just look up example.com in > DNS, because it has been split across A and B and DNS just doesn't > work that way. Now, if both A and B registered with some "upstream" > lookup function (a meta-overlay), then Alice could perhaps look > there. But this starts to get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays > problem (and that's not easy), we're much better off at this time > having a model where each domain can be mapped onto only one > overlay at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 00:36:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyh3z-0002Bk-4o; Thu, 14 Jun 2007 00:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyh3y-0002Bc-5z for p2psip@ietf.org; Thu, 14 Jun 2007 00:36:02 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyh3w-0002ln-Rd for p2psip@ietf.org; Thu, 14 Jun 2007 00:36:02 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l5E4ZxuD023474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 13 Jun 2007 21:35:59 -0700 Received: from [76.102.225.135] (vpn-10-50-0-231.qualcomm.com [10.50.0.231]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l5E4Zrab007365 for ; Wed, 13 Jun 2007 21:35:59 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Wed, 13 Jun 2007 21:35:52 -0700 To: p2psip@ietf.org From: Ted Hardie Subject: Fwd: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org With Dean's encouragement, a suggestion for the terminology. Ted >From: Dean Willis >Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology >Date: Wed, 13 Jun 2007 19:35:41 -0500 >To: Ted Hardie > > >On Jun 13, 2007, at 6:00 PM, Ted Hardie wrote: > >>Not to the list, since it is just wordsmithing, but you seem to be using "contributing" >>fairly consistently to describe the actions here, but then switch to "active" and "passive". >>I think "contributing peer" would fit better. You could use "contributing peer", "peer", >>pretty easily, since every action of the "peer" is also an action of the "contributing peer". > >Works for me. I suggest taking to he list. > >-- >Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 05:45:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylsu-0000kU-VO; Thu, 14 Jun 2007 05:44:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hylss-0000kM-RK for p2psip@ietf.org; Thu, 14 Jun 2007 05:44:54 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hylss-0007NB-2Y for p2psip@ietf.org; Thu, 14 Jun 2007 05:44:54 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l5E9iqmQ107176 for ; Thu, 14 Jun 2007 09:44:52 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l5E9iqoc4124840 for ; Thu, 14 Jun 2007 11:44:52 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l5E9ipVx017157 for ; Thu, 14 Jun 2007 11:44:51 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l5E9ipWD017152; Thu, 14 Jun 2007 11:44:51 +0200 In-Reply-To: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> To: Dean Willis Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 From: Avshalom Houri Message-ID: Date: Thu, 14 Jun 2007 12:44:49 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 7.0.2HF71 | November 3, 2006) at 14/06/2007 12:44:50, Serialize complete at 14/06/2007 12:44:50 X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1544632441==" Errors-To: p2psip-bounces@ietf.org This is a multipart message in MIME format. --===============1544632441== Content-Type: multipart/alternative; boundary="=_alternative 00357F1BC22572FA_=" This is a multipart message in MIME format. --=_alternative 00357F1BC22572FA_= Content-Type: text/plain; charset="US-ASCII" Sounds good and simple. --Avshalom Dean Willis 14/06/2007 01:49 To P2PSIP Mailing List cc Philip Matthews Subject [P2PSIP] Concepts document: proposal for active/passive peer terminology I'm updating the concepts draft, and wanted to kick this around a little bit before I put it into the draft. We've sort of come up with three different sorts of nodes: 1) The "full peer" nodes that actively provide resources (like storage and transport) to the overlay and speak the P2SIP Peer Protocol. 2) Less-than-full peer nodes that either speak some subset of the P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or just natively access the distributed database, but that are lazy and do not contribute their own resources to the overlay. 3) "Clients", which are either #2 above, or just plain-old-SIP UAs depending on who you talk to. I hereby propose to client this up a bit, based on suggestions made on the list, by having two sorts of peers; "active" and "passive", SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including P2PSIP Client Protocol here. An "active peer" is one that contributes resources. A "passive peer" is one that doesn't. The choice of which mode to operate in could be a matter of implementation, or configuration, or could be a runtime decision based on the resources (memory, bandwidth, power, etc.) available to the peer. Peers advertise services that they are contributing with the distributed database. So a peer that has advertised any services at all could be said to be "active", and a peer that hasn't advertised any could be said to be "passive". Things like "transport", "storage", "STUN", "STUN Relay", "SIP Outbound Proxy" and the like would be "Services". Obviously, not all peers would offer all services. We'd expect that most would offer "transport" and "storage", but probably only specialized nodes would offer "SIP Outbound Proxy". I think this greatly simplifies the semantic morass in which we've been wading. How does it sound to you? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --=_alternative 00357F1BC22572FA_= Content-Type: text/html; charset="US-ASCII"
Sounds good and simple.

--Avshalom


Dean Willis <dean.willis@softarmor.com>

14/06/2007 01:49

To
P2PSIP Mailing List <p2psip@ietf.org>
cc
Philip Matthews <philip_matthews@magma.ca>
Subject
[P2PSIP] Concepts document: proposal for active/passive peer        terminology






I'm updating the concepts draft, and wanted to kick this around a  
little bit before I put it into the draft.

We've sort of come up with three different sorts of nodes:

1) The "full peer" nodes that actively provide resources (like  
storage and transport) to the overlay and speak the P2SIP Peer Protocol.

2) Less-than-full peer nodes that either speak some subset of the  
P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or  
just natively access the distributed database, but that are lazy and  
do not contribute their own resources to the overlay.

3) "Clients", which are either #2 above, or just plain-old-SIP UAs  
depending on who you talk to.

I hereby propose to client this up a bit, based on suggestions made  
on the list, by having two sorts of peers; "active" and "passive",  
SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including  
P2PSIP Client Protocol here.

An "active peer" is one that contributes resources. A "passive peer"  
is one that doesn't. The choice of which mode to operate in could be  
a matter of implementation, or configuration, or could be a runtime  
decision based on the resources (memory, bandwidth, power, etc.)  
available to the peer.

Peers advertise services that they are contributing with the  
distributed database. So a peer that has advertised any services at  
all could be said to be "active", and a peer that hasn't advertised  
any could be said to be "passive".

Things like "transport", "storage", "STUN", "STUN Relay", "SIP  
Outbound Proxy" and the like would be "Services". Obviously, not all  
peers would offer all services. We'd expect that most would offer  
"transport" and "storage", but probably only specialized nodes would  
offer "SIP Outbound Proxy".

I think this greatly simplifies the semantic morass in which we've  
been wading.

How does it sound to you?

--
Dean

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--=_alternative 00357F1BC22572FA_=-- --===============1544632441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1544632441==-- From p2psip-bounces@ietf.org Thu Jun 14 09:16:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypBG-0004bA-7D; Thu, 14 Jun 2007 09:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypBF-0004b2-J6 for p2psip@ietf.org; Thu, 14 Jun 2007 09:16:05 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HypBD-000779-U8 for p2psip@ietf.org; Thu, 14 Jun 2007 09:16:05 -0400 Received: by py-out-1112.google.com with SMTP id a25so1465356pyi for ; Thu, 14 Jun 2007 06:16:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HG3dvn4ZgnDgB1JmhhGWCLEE8pWh1DdXRierXADcBdjHJ9lp5hk9JEhSN8Sq7gQTyvE3M7KbhP1+382+8qxhpa1NTrW3vfoMNcpmkKgEm4pfq5OMxwN1+s+GxMNdOMr87lUuPRRczrBQOPWpnVYvpt578iWoeck2LR7nptkFdsA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=YwMHGJPB/mq9E1TgvBKGL95Qz7k6ALMZtD2/iHhBIKyZvwZBfhqamoZ3sWp/ayPeReYAzH6OTby7+tQF4LSiHTPt2sYfX7LrQWzIefZbfn9w+/pz5R+V5ksSooBLSqjANy4TGNSRXma1gXxEmvMPM6fOss94axkVVHlZuKrM2pc= Received: by 10.35.76.9 with SMTP id d9mr3140326pyl.1181826963590; Thu, 14 Jun 2007 06:16:03 -0700 (PDT) Received: by 10.35.65.4 with HTTP; Thu, 14 Jun 2007 06:16:03 -0700 (PDT) Message-ID: <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> Date: Thu, 14 Jun 2007 09:16:03 -0400 From: "David A. Bryan" To: "Avshalom Houri" Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology In-Reply-To: MIME-Version: 1.0 References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> X-Google-Sender-Auth: b77047286952f4a6 X-Spam-Score: 0.3 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1826240368==" Errors-To: p2psip-bounces@ietf.org --===============1826240368== Content-Type: multipart/alternative; boundary="----=_Part_3835_2725275.1181826963540" ------=_Part_3835_2725275.1181826963540 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline If I understand this right, not sure I like it. Do these "non-contributing peer" (I *do* like contributing better than active/passive) entities have a Peer-ID? In otherwords, are they part of the overlay at all? If so, for most DHTs, how do we allow you to be in the overlay and not store resources (not typical for most current DHT algorithms) My concern all along has been that I don't understand why something is a peer if it isn't doing anything other than talking to someone and making requests, hence why I supported client in the first place. I fail to see how something that isn't contributing anything, and instead talks to a peer to get resources, is in any way a peer. It seems completely not in keeping with the idea of P2P. I also worry it is likely to be very confusing since we've been using the other terminology for over a year now. Just looks like a souce of confusion. If we do go this way, there is one subtle point. If I join the overlay but don't happen to offer any services (other than maybe storage...depending on how we definie it, that might or might not be mandatory), would I be contributing? If joining the overlay (in the sense that we have a PeerID and we route traffic) doesn't require me to store, I could offer no services and still be a peer. How do we distinguish between this case and a "non-contributing peer" who isn't even part of the overlay (i.e., no Peer-ID) If we are so opposed to client for confusion with SIP UAs, lets pick a new name, but why some flavor of peer when it does nothing remotely peer like? David On 6/14/07, Avshalom Houri wrote: > > > Sounds good and simple. > > --Avshalom > > > > > > > *Dean Willis * > > 14/06/2007 01:49 > To > P2PSIP Mailing List cc > Philip Matthews Subject > [P2PSIP] Concepts document: proposal for active/passive peer > terminology > > > > > > > > I'm updating the concepts draft, and wanted to kick this around a > little bit before I put it into the draft. > > We've sort of come up with three different sorts of nodes: > > 1) The "full peer" nodes that actively provide resources (like > storage and transport) to the overlay and speak the P2SIP Peer Protocol. > > 2) Less-than-full peer nodes that either speak some subset of the > P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or > just natively access the distributed database, but that are lazy and > do not contribute their own resources to the overlay. > > 3) "Clients", which are either #2 above, or just plain-old-SIP UAs > depending on who you talk to. > > I hereby propose to client this up a bit, based on suggestions made > on the list, by having two sorts of peers; "active" and "passive", > SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including > P2PSIP Client Protocol here. > > An "active peer" is one that contributes resources. A "passive peer" > is one that doesn't. The choice of which mode to operate in could be > a matter of implementation, or configuration, or could be a runtime > decision based on the resources (memory, bandwidth, power, etc.) > available to the peer. > > Peers advertise services that they are contributing with the > distributed database. So a peer that has advertised any services at > all could be said to be "active", and a peer that hasn't advertised > any could be said to be "passive". > > Things like "transport", "storage", "STUN", "STUN Relay", "SIP > Outbound Proxy" and the like would be "Services". Obviously, not all > peers would offer all services. We'd expect that most would offer > "transport" and "storage", but probably only specialized nodes would > offer "SIP Outbound Proxy". > > I think this greatly simplifies the semantic morass in which we've > been wading. > > How does it sound to you? > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com ------=_Part_3835_2725275.1181826963540 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline If I understand this right, not sure I like it. Do these "non-contributing peer" (I *do* like contributing better than active/passive) entities have a Peer-ID? In otherwords, are they part of the overlay at all? If so, for most DHTs, how do we allow you to be in the overlay and not store resources (not typical for most current DHT algorithms)

My concern all along has been that I don't understand why something is a peer if it isn't doing anything other than talking to someone and making requests, hence why I supported client in the first place. I fail to see how something that isn't contributing anything, and instead talks to a peer to get resources, is in any way a peer. It seems completely not in keeping with the idea of P2P. I also worry it is likely to be very confusing since we've been using the other terminology for over a year now. Just looks like a souce of confusion.

If we do go this way, there is one subtle point. If I join the overlay but don't happen to offer any services (other than maybe storage...depending on how we definie it, that might or might not be mandatory), would I be contributing? If joining the overlay (in the sense that we have a PeerID and we route traffic) doesn't require me to store, I could offer no services and still be a peer. How do we distinguish between this case and a "non-contributing peer" who isn't even part of the overlay ( i.e., no Peer-ID)

If we are so opposed to client for confusion with SIP UAs, lets pick a new name, but why some flavor of peer when it does nothing remotely peer like?

David

On 6/14/07, Avshalom Houri <AVSHALOM@il.ibm.com> wrote:

Sounds good and simple.

--Avshalom


Dean Willis <dean.willis@softarmor.com >

14/06/2007 01:49

To
P2PSIP Mailing List <p2psip@ietf.org>
cc
Philip Matthews <philip_matthews@magma.ca>
Subject
[P2PSIP] Concepts document: proposal for active/passive peer        terminology








I'm updating the concepts draft, and wanted to kick this around a  
little bit before I put it into the draft.

We've sort of come up with three different sorts of nodes:

1) The "full peer" nodes that actively provide resources (like  
storage and transport) to the overlay and speak the P2SIP Peer Protocol.

2) Less-than-full peer nodes that either speak some subset of the  
P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or  
just natively access the distributed database, but that are lazy and  
do not contribute their own resources to the overlay.

3) "Clients", which are either #2 above, or just plain-old-SIP UAs  
depending on who you talk to.

I hereby propose to client this up a bit, based on suggestions made  
on the list, by having two sorts of peers; "active" and "passive",  
SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including  
P2PSIP Client Protocol here.

An "active peer" is one that contributes resources. A "passive peer"  
is one that doesn't. The choice of which mode to operate in could be  
a matter of implementation, or configuration, or could be a runtime  
decision based on the resources (memory, bandwidth, power, etc.)  
available to the peer.

Peers advertise services that they are contributing with the  
distributed database. So a peer that has advertised any services at  
all could be said to be "active", and a peer that hasn't advertised  
any could be said to be "passive".

Things like "transport", "storage", "STUN", "STUN Relay", "SIP  
Outbound Proxy" and the like would be "Services". Obviously, not all  
peers would offer all services. We'd expect that most would offer  
"transport" and "storage", but probably only specialized nodes would  
offer "SIP Outbound Proxy".

I think this greatly simplifies the semantic morass in which we've  
been wading.

How does it sound to you?

--
Dean

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip




--
David A. Bryan
dbryan@SIPeerior.com
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com ------=_Part_3835_2725275.1181826963540-- --===============1826240368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1826240368==-- From p2psip-bounces@ietf.org Thu Jun 14 09:33:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypSG-0008LT-7h; Thu, 14 Jun 2007 09:33:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HypSE-0008LK-Vv for p2psip@ietf.org; Thu, 14 Jun 2007 09:33:38 -0400 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HypSB-0007HL-Eb for p2psip@ietf.org; Thu, 14 Jun 2007 09:33:38 -0400 Received: from chundachunda.it.uc3m.es (chundachunda.it.uc3m.es [163.117.139.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id 68FB828713; Thu, 14 Jun 2007 15:33:34 +0200 (CEST) From: Isaias Martinez Yelmo Organization: Universidad Carlos III de Madrid To: p2psip@ietf.org Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 15:33:27 +0200 User-Agent: KMail/1.9.7 References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> In-Reply-To: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> MIME-Version: 1.0 Message-Id: <200706141533.33815.imyelmo@it.uc3m.es> X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Isaias Martinez Yelmo List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0937726724==" Errors-To: p2psip-bounces@ietf.org --===============0937726724== Content-Type: multipart/signed; boundary="nextPart2115110.Zi52RpjYjX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart2115110.Zi52RpjYjX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I agree with you, it has no sense to split a domain in two different overla= ys.=20 However, I'm not completely sure if it is a good idea to define an overlay= =20 per each p2psip domain and to use a hierarchical approach to interconnect a= ll=20 the domains with DNS. I think that the concept that you define as meta-overlay will be the way to= =20 interconnect the different p2psip domains and not to use the DNS=20 infrastructure. I am studyin my research topic on this line of work. Regards, Isaias On Thursday 14 June 2007 01:00:24 Dean Willis wrote: > Someone brought this up on the list, and I wanted to clarify the > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many > domains. In this model, there might be only one overlay serving every > domain in the world, including (for example) "example.com" and > "example.net". Clearly routing messages within this overlay is > straightforward, and there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not all > domains, and we use RFC 3263 procedures to route between overlays. So > "example.com" might be in one overlay, and "example.net" in another. > Each overlay can look up the other in DNS to find it. > > This second model mostly precludes having one domain scattered across > multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and > he's not there. What to do? She can't just look up example.com in > DNS, because it has been split across A and B and DNS just doesn't > work that way. Now, if both A and B registered with some "upstream" > lookup function (a meta-overlay), then Alice could perhaps look > there. But this starts to get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays > problem (and that's not easy), we're much better off at this time > having a model where each domain can be mapped onto only one overlay > at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip =2D-=20 Isaias Martinez Yelmo Universidad Carlos III de Madrid Departamento de Telem=E1tica http://www.it.uc3m.es/~imyelmo Asociaci=F3n de Tel=E9matica: http://www.telematica.ws http://www.netcoms.net --nextPart2115110.Zi52RpjYjX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGcUOtUfy5bBxA/JsRAnI2AJ4wuuL3SF2Uq7H7scpXIWpCfdVyuQCglIF+ BliqWA5lg14YoP+FlpIyHh0= =bi5K -----END PGP SIGNATURE----- --nextPart2115110.Zi52RpjYjX-- --===============0937726724== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0937726724==-- From p2psip-bounces@ietf.org Thu Jun 14 09:47:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hypfv-0006dQ-UK; Thu, 14 Jun 2007 09:47:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hypfu-0006dD-IE for p2psip@ietf.org; Thu, 14 Jun 2007 09:47:46 -0400 Received: from ik-out-1112.google.com ([66.249.90.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hypfs-0002r5-KK for p2psip@ietf.org; Thu, 14 Jun 2007 09:47:46 -0400 Received: by ik-out-1112.google.com with SMTP id b32so515212ika for ; Thu, 14 Jun 2007 06:47:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lw5XRddlX4FnHi9ltdnOShcZexBSUHhy7DPwLVsRQUWUvBPZ0mJUqImRKsWe46DOdCEP18sePJLiUAzv/rjg8lYnjfbA1mwEQZsEElS7HdEGoFyvSKa50RUdCSvXNlNAj6QF+/FME91W/YyhxOhmnfW20dOjWsfZ51tvAakOwJ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=X7IA3PsMzOXJK8y/tc/VEUSeKUGOmyUJZLk9TaWUaJL9i0Df2AAA/RX7lyyySBUBWTqjaoVpCmr0kDwg2R8jP7zItC4cAmbRBCpCNbrUHS16LLQ3oetBQCPxqdKTYpljUXh48cqtG1bUekjcBmbpdjDjhSJ6l0LtanJUJxHescw= Received: by 10.78.107.8 with SMTP id f8mr679760huc.1181828863744; Thu, 14 Jun 2007 06:47:43 -0700 (PDT) Received: by 10.78.165.12 with HTTP; Thu, 14 Jun 2007 06:47:43 -0700 (PDT) Message-ID: Date: Thu, 14 Jun 2007 09:47:43 -0400 From: "Bill Mccormick" To: "David A. Bryan" Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology In-Reply-To: <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> MIME-Version: 1.0 References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: Avshalom Houri , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530789763==" Errors-To: p2psip-bounces@ietf.org --===============1530789763== Content-Type: multipart/alternative; boundary="----=_Part_43978_14200722.1181828863716" ------=_Part_43978_14200722.1181828863716 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline It sounds like Dean is saying: an active peer is a fully participating node in the DHT. a passive peer can access the DHT "natively" but is not actually a DHT node a client is just a SIP UA client and it treats the DHT (more or less) as a proxy server. Is this correct? Bill McCormick Nortel On 6/14/07, David A. Bryan wrote: > > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so, for most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) > > My concern all along has been that I don't understand why something is a > peer if it isn't doing anything other than talking to someone and making > requests, hence why I supported client in the first place. I fail to see how > something that isn't contributing anything, and instead talks to a peer to > get resources, is in any way a peer. It seems completely not in keeping with > the idea of P2P. I also worry it is likely to be very confusing since we've > been using the other terminology for over a year now. Just looks like a > souce of confusion. > > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be > contributing? If joining the overlay (in the sense that we have a PeerID and > we route traffic) doesn't require me to store, I could offer no services and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay ( i.e., no > Peer-ID) > > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? > > David > > On 6/14/07, Avshalom Houri wrote: > > > > > > Sounds good and simple. > > > > --Avshalom > > > > > > > > > > > > > > *Dean Willis * > > > > 14/06/2007 01:49 > > To > > P2PSIP Mailing List cc > > Philip Matthews Subject > > [P2PSIP] Concepts document: proposal for active/passive peer > > terminology > > > > > > > > > > > > > > > > I'm updating the concepts draft, and wanted to kick this around a > > little bit before I put it into the draft. > > > > We've sort of come up with three different sorts of nodes: > > > > 1) The "full peer" nodes that actively provide resources (like > > storage and transport) to the overlay and speak the P2SIP Peer Protocol. > > > > 2) Less-than-full peer nodes that either speak some subset of the > > P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or > > just natively access the distributed database, but that are lazy and > > do not contribute their own resources to the overlay. > > > > 3) "Clients", which are either #2 above, or just plain-old-SIP UAs > > depending on who you talk to. > > > > I hereby propose to client this up a bit, based on suggestions made > > on the list, by having two sorts of peers; "active" and "passive", > > SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including > > P2PSIP Client Protocol here. > > > > An "active peer" is one that contributes resources. A "passive peer" > > is one that doesn't. The choice of which mode to operate in could be > > a matter of implementation, or configuration, or could be a runtime > > decision based on the resources (memory, bandwidth, power, etc.) > > available to the peer. > > > > Peers advertise services that they are contributing with the > > distributed database. So a peer that has advertised any services at > > all could be said to be "active", and a peer that hasn't advertised > > any could be said to be "passive". > > > > Things like "transport", "storage", "STUN", "STUN Relay", "SIP > > Outbound Proxy" and the like would be "Services". Obviously, not all > > peers would offer all services. We'd expect that most would offer > > "transport" and "storage", but probably only specialized nodes would > > offer "SIP Outbound Proxy". > > > > I think this greatly simplifies the semantic morass in which we've > > been wading. > > > > How does it sound to you? > > > > -- > > Dean > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- Bill McCormick ------=_Part_43978_14200722.1181828863716 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
It sounds like Dean is saying:
 
an active peer is a fully participating node in the DHT.
a passive peer can access the DHT "natively" but is not actually a DHT node
a client is just a SIP UA client and it treats the DHT (more or less) as a proxy server.
 
Is this correct?
 
Bill McCormick
Nortel
 
On 6/14/07, David A. Bryan <dbryan@sipeerior.com> wrote:
If I understand this right, not sure I like it. Do these "non-contributing peer" (I *do* like contributing better than active/passive) entities have a Peer-ID? In otherwords, are they part of the overlay at all? If so, for most DHTs, how do we allow you to be in the overlay and not store resources (not typical for most current DHT algorithms)

My concern all along has been that I don't understand why something is a peer if it isn't doing anything other than talking to someone and making requests, hence why I supported client in the first place. I fail to see how something that isn't contributing anything, and instead talks to a peer to get resources, is in any way a peer. It seems completely not in keeping with the idea of P2P. I also worry it is likely to be very confusing since we've been using the other terminology for over a year now. Just looks like a souce of confusion.

If we do go this way, there is one subtle point. If I join the overlay but don't happen to offer any services (other than maybe storage...depending on how we definie it, that might or might not be mandatory), would I be contributing? If joining the overlay (in the sense that we have a PeerID and we route traffic) doesn't require me to store, I could offer no services and still be a peer. How do we distinguish between this case and a "non-contributing peer" who isn't even part of the overlay ( i.e., no Peer-ID)

If we are so opposed to client for confusion with SIP UAs, lets pick a new name, but why some flavor of peer when it does nothing remotely peer like?

David


On 6/14/07, Avshalom Houri <AVSHALOM@il.ibm.com > wrote:

Sounds good and simple.

--Avshalom






Dean Willis <dean.willis@softarmor.com >

14/06/2007 01:49

To
 P2PSIP Mailing List <p2psip@ietf.org>
cc
 Philip Matthews <philip_matthews@magma.ca>
Subject
 [P2PSIP] Concepts document: proposal for active/passive peer        terminology





I'm updating the concepts draft, and wanted to kick this around a  
little bit before I put it into the draft.

We've sort of come up with three different sorts of nodes:

1) The "full peer" nodes that actively provide resources (like  
storage and transport) to the overlay and speak the P2SIP Peer Protocol.

2) Less-than-full peer nodes that either speak some subset of the  
P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) or  
just natively access the distributed database, but that are lazy and  
do not contribute their own resources to the overlay.

3) "Clients", which are either #2 above, or just plain-old-SIP UAs  
depending on who you talk to.

I hereby propose to client this up a bit, based on suggestions made  
on the list, by having two sorts of peers; "active" and "passive",  
SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including  
P2PSIP Client Protocol here.

An "active peer" is one that contributes resources. A "passive peer"  
is one that doesn't. The choice of which mode to operate in could be  
a matter of implementation, or configuration, or could be a runtime  
decision based on the resources (memory, bandwidth, power, etc.)  
available to the peer.

Peers advertise services that they are contributing with the  
distributed database. So a peer that has advertised any services at  
all could be said to be "active", and a peer that hasn't advertised  
any could be said to be "passive".

Things like "transport", "storage", "STUN", "STUN Relay", "SIP  
Outbound Proxy" and the like would be "Services". Obviously, not all  
peers would offer all services. We'd expect that most would offer  
"transport" and "storage", but probably only specialized nodes would  
offer "SIP Outbound Proxy".

I think this greatly simplifies the semantic morass in which we've  
been wading.

How does it sound to you?

--
Dean

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip




--
David A. Bryan
dbryan@SIPeerior.com
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip




--
Bill McCormick ------=_Part_43978_14200722.1181828863716-- --===============1530789763== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1530789763==-- From p2psip-bounces@ietf.org Thu Jun 14 10:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyq6z-0005bm-02; Thu, 14 Jun 2007 10:15:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyq6y-0005be-9B for p2psip@ietf.org; Thu, 14 Jun 2007 10:15:44 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyq6x-0000Ck-0a for p2psip@ietf.org; Thu, 14 Jun 2007 10:15:44 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5EEEmd4014204; Thu, 14 Jun 2007 09:14:49 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5EEEma13838; Thu, 14 Jun 2007 09:14:48 -0500 (CDT) Message-ID: <46714D58.7000408@alcatel-lucent.com> Date: Thu, 14 Jun 2007 09:14:48 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> In-Reply-To: <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henning Schulzrinne wrote: > I generally agree with your train of thought until it derails in the > last paragraph, I think. A slightly weaker requirement that also works > and is useful is to require that each domain has a "default" overlay > that one must register with if it is available. So, extrapolating from Dean's example and your thoughts above, Bob would register with overlay B and also with the "default" overlay for his domain (example.com). When Alice calls Bob, her peer first searches for Bob in overlay A (Alice's overlay), and not finding Bob there continues to search for him in the "default" overlay. Essentially, a peer would have to maintain and refresh two registrations -- one to their assigned overlay, and the other to the "default" overlay (and the other peers in the DHT would need to maintain and possibly replicate two registrations.) Yes? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 10:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyq9s-0007e0-1m; Thu, 14 Jun 2007 10:18:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyq9r-0007bE-5j for p2psip@ietf.org; Thu, 14 Jun 2007 10:18:43 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyq9q-0000nm-O8 for p2psip@ietf.org; Thu, 14 Jun 2007 10:18:43 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hyq9p-000290-2Z; Thu, 14 Jun 2007 10:18:42 -0400 In-Reply-To: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology Date: Thu, 14 Jun 2007 10:18:36 -0400 To: Dean Willis X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Two comments on this proposal: (1) This proposal makes a binary distinction between peers that are willing to store data for other peers and peers that are not willing to store data. However, what I think might reflect reality better is a measure of how much storage a peer is willing to offer. Consider for example a softphone running on a typical modern PC, vs a hardphone. The former has lots of disk to store data on, while the latter typically has a very limited amount of flash memory. In our deskphone product, for example, we use flash memory, and space in our flash is always at a premium. To be precise: Rather that a peer advertising "I am willing to store data", a peer might instead need to advertise "I am willing to store N KBytes of data". Now, if the amount of data that we want to store in the Distributed Database is small, then making this distinction is not important. If we store just contact information, then I think we can ignore this distinction. However, if we start using the Distributed Database to store other things, then I think this distinction will become important. (2) As I have said before, I really, really want to see good examples of why we want to make this distinctions between types of peers (or whatever we call them). Yes, we could design a system that allows for great flexibility in types of peers allowed, but I want to first understand why this flexibility is useful. To be concrete: I suggest having a section in the document that discusses these possibilities (and any others that people can think of), but I suggest holding off in giving them names and elevating them to formal "concepts" in the document until someone argues why one of these is of particular interest. To apply my own suggestion, I consider my comment (1) above to be a concept that is "waiting-in-the-wings". If I see people starting to suggest using the distributed database to store lots of different things, then I will bring this point up again and probably write an I- D that argues that we need to make this distinction. Until then, I am just keeping it in the back of my mind. - Philip On 13-Jun-07, at 18:49 , Dean Willis wrote: > > I'm updating the concepts draft, and wanted to kick this around a > little bit before I put it into the draft. > > We've sort of come up with three different sorts of nodes: > > 1) The "full peer" nodes that actively provide resources (like > storage and transport) to the overlay and speak the P2SIP Peer > Protocol. > > 2) Less-than-full peer nodes that either speak some subset of the > P2PSIP Peer Protocol (which we called the P2PSIP Client Protocol) > or just natively access the distributed database, but that are lazy > and do not contribute their own resources to the overlay. > > 3) "Clients", which are either #2 above, or just plain-old-SIP UAs > depending on who you talk to. > > I hereby propose to client this up a bit, based on suggestions made > on the list, by having two sorts of peers; "active" and "passive", > SIP UAs, P2PSIP Peer Protocol, and SIP. Note that I'm not including > P2PSIP Client Protocol here. > > An "active peer" is one that contributes resources. A "passive > peer" is one that doesn't. The choice of which mode to operate in > could be a matter of implementation, or configuration, or could be > a runtime decision based on the resources (memory, bandwidth, > power, etc.) available to the peer. > > Peers advertise services that they are contributing with the > distributed database. So a peer that has advertised any services at > all could be said to be "active", and a peer that hasn't advertised > any could be said to be "passive". > > Things like "transport", "storage", "STUN", "STUN Relay", "SIP > Outbound Proxy" and the like would be "Services". Obviously, not > all peers would offer all services. We'd expect that most would > offer "transport" and "storage", but probably only specialized > nodes would offer "SIP Outbound Proxy". > > I think this greatly simplifies the semantic morass in which we've > been wading. > > How does it sound to you? > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 10:24:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqFf-00079T-Gf; Thu, 14 Jun 2007 10:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqFe-000782-3i for p2psip@ietf.org; Thu, 14 Jun 2007 10:24:42 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyqFa-0002XN-Mq for p2psip@ietf.org; Thu, 14 Jun 2007 10:24:41 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HyqFU-0008OF-QN; Thu, 14 Jun 2007 09:24:33 -0500 From: "Brian Rosen" To: "'Dean Willis'" , "'P2PSIP Mailing List'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 10:24:35 -0400 Message-ID: <08a201c7ae8f$be7455c0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> Thread-Index: AceuDqjpj8wPwbXVQNKQK1kx4a58vQAgPLMw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Uh huh, that's the way I thought it worked. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Wednesday, June 13, 2007 7:00 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] Concepts issue: Domains and Overlays > > > Someone brought this up on the list, and I wanted to clarify the > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many > domains. In this model, there might be only one overlay serving every > domain in the world, including (for example) "example.com" and > "example.net". Clearly routing messages within this overlay is > straightforward, and there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not all > domains, and we use RFC 3263 procedures to route between overlays. So > "example.com" might be in one overlay, and "example.net" in another. > Each overlay can look up the other in DNS to find it. > > This second model mostly precludes having one domain scattered across > multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and > he's not there. What to do? She can't just look up example.com in > DNS, because it has been split across A and B and DNS just doesn't > work that way. Now, if both A and B registered with some "upstream" > lookup function (a meta-overlay), then Alice could perhaps look > there. But this starts to get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays > problem (and that's not easy), we're much better off at this time > having a model where each domain can be mapped onto only one overlay > at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 10:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqV5-0006qA-Gj; Thu, 14 Jun 2007 10:40:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqV4-0006nQ-KJ for p2psip@ietf.org; Thu, 14 Jun 2007 10:40:38 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyqV3-0001kw-7i for p2psip@ietf.org; Thu, 14 Jun 2007 10:40:38 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJM007RRRFNM2@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 14 Jun 2007 07:40:35 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJM0061BRFK2K@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 14 Jun 2007 07:40:35 -0700 (PDT) Date: Thu, 14 Jun 2007 09:37:56 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays To: P2PSIP Mailing List Message-id: <10f601c7ae91$99fd8c50$6901a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Much like Brian's response - Dean described the way I thought this worked. I do like Henning's suggestion, although I'm not sure we're ready for engineering yet - if you disconnect from the Internet at large, then set up special overlays based on being disconnected, then reconnect (ignoring the imprecision of "disconnecting from and reconnecting to the Internet), would we expect the special overlays to self-destruct? I'm not sure what our consensus is about going the other way - can three or four domains participate in a single overlay? Or did I miss a conversation? Thanks, Spencer From: "Henning Schulzrinne" >I generally agree with your train of thought until it derails in the last >paragraph, I think. A slightly weaker requirement that also works and is >useful is to require that each domain has a "default" overlay that one >must register with if it is available. There is nothing wrong with >registering in wild-card domains for special purposes. For example, this >can occur when such an overlay is disconnected from the Internet at large. >Would you want to set up a per-domain overlay for each and every AOR >domain in that case? (I realize that detecting this case can get messy, >but this largely depends on how we solve the overlay discovery problem.) > > Henning > > On Jun 13, 2007, at 7:00 PM, Dean Willis wrote: > >> >> Someone brought this up on the list, and I wanted to clarify the >> consensus here before nailing it down further in the concepts doc. >> >> We think of usernames as domain-scoped, like "joebob@example.com". >> >> One model of an overlay allows users to enroll names from many domains. >> In this model, there might be only one overlay serving every domain in >> the world, including (for example) "example.com" and "example.net". >> Clearly routing messages within this overlay is straightforward, and >> there's no need to talk to any other overlay. >> >> In another model, each overlay corresponds to one or more but not all >> domains, and we use RFC 3263 procedures to route between overlays. So >> "example.com" might be in one overlay, and "example.net" in another. >> Each overlay can look up the other in DNS to find it. >> >> This second model mostly precludes having one domain scattered across >> multiple overlays. >> >> Here's the deal: Assume we have overlays A and B. Alice@example.com >> enrolls with overlay A, and Bob@example.com enrolls with overlay B. >> >> Alice now wants to call Bob. She looks him up in her overlay, and he's >> not there. What to do? She can't just look up example.com in DNS, >> because it has been split across A and B and DNS just doesn't work that >> way. Now, if both A and B registered with some "upstream" lookup >> function (a meta-overlay), then Alice could perhaps look there. But this >> starts to get messy really quickly. >> >> So unless we want to solve the namespace-split-across-overlays problem >> (and that's not easy), we're much better off at this time having a model >> where each domain can be mapped onto only one overlay at a time. >> >> Y'all ok with that? >> >> -- >> Dean >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 10:55:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqjk-0002MY-4O; Thu, 14 Jun 2007 10:55:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqjj-0002MQ-14 for p2psip@ietf.org; Thu, 14 Jun 2007 10:55:47 -0400 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyqjh-0004sq-Nq for p2psip@ietf.org; Thu, 14 Jun 2007 10:55:47 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJM00LZ3S4MMV@tid.hi.inet> for p2psip@ietf.org; Thu, 14 Jun 2007 16:55:35 +0200 (MEST) Received: from matrix ([10.95.89.24]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJM00KMMS4LGX@tid.hi.inet> for p2psip@ietf.org; Thu, 14 Jun 2007 16:55:34 +0200 (MEST) Date: Thu, 14 Jun 2007 16:55:31 +0200 From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= Subject: RE: [P2PSIP] Concepts document: proposal for active/passive peerterminology In-reply-to: <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> To: 'Philip Matthews' , 'Dean Willis' Message-id: <057d01c7ae94$0f03f960$2d0bec20$@es> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es Content-transfer-encoding: 7BIT Thread-index: AceujvfWcRf1N4ZjQeyMa57K66V0CwABOxSQ References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > (2) As I have said before, I really, really want to see good examples > of why we want to make this distinctions between types of peers (or > whatever we call them). Yes, we could design a system that allows for > great flexibility in types of peers allowed, but I want to first > understand why this flexibility is useful. IMHO we only need to make the distinction between nodes which participate in the location of resources (participate in the DHT structure) and those who only make use of the resource location functions (sending PUT/GET requests). We need to make this distinction because Peers need a PeerID while for Clients this is not clear, because the protocol primitives implemented in Peers are different from those in Clients, because bootstrapping/joining procedures are different (clients don't need to be placed in the DHT structure) and because probably they also have different security requirements (it is more critical to authorize a peer than a client). Personally I like the names Peer and Client but If somebody feels that Client is a confuse name we only need to look for other term (not trying to create new concepts for nodes depending on the services provided). G. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:05:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqtU-0007CN-NI; Thu, 14 Jun 2007 11:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqtT-0007C4-Ji for p2psip@ietf.org; Thu, 14 Jun 2007 11:05:51 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyqtR-0007u7-KS for p2psip@ietf.org; Thu, 14 Jun 2007 11:05:51 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1HyqtZ-0002vt-Fn; Thu, 14 Jun 2007 11:05:58 -0400 In-Reply-To: <057d01c7ae94$0f03f960$2d0bec20$@es> References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <057d01c7ae94$0f03f960$2d0bec20$@es> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology Date: Thu, 14 Jun 2007 11:05:48 -0400 To: =?ISO-8859-1?Q?Gustavo_Garc=EDa?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 14-Jun-07, at 10:55 , Gustavo Garc=EDa wrote: >> (2) As I have said before, I really, really want to see good examples >> of why we want to make this distinctions between types of peers (or >> whatever we call them). Yes, we could design a system that allows for >> great flexibility in types of peers allowed, but I want to first >> understand why this flexibility is useful. > > IMHO we only need to make the distinction between nodes which =20 > participate in > the location of resources (participate in the DHT structure) and =20 > those who > only make use of the resource location functions (sending PUT/GET =20 > requests). > > We need to make this distinction because Peers need a PeerID while for > Clients this is not clear, because the protocol primitives =20 > implemented in > Peers are different from those in Clients, because bootstrapping/=20 > joining > procedures are different (clients don't need to be placed in the DHT > structure) and because probably they also have different security > requirements (it is more critical to authorize a peer than a client). I agree that clients might not need peer IDs, and might have a =20 different protocol stack, but why do you want clients? What motives you to write additional =20 software to support the concept of a client? - Philip= _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:10:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqxa-0005Sy-CI; Thu, 14 Jun 2007 11:10:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqxY-0005Mn-Qt for p2psip@ietf.org; Thu, 14 Jun 2007 11:10:04 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyqxX-0000Zn-AQ for p2psip@ietf.org; Thu, 14 Jun 2007 11:10:04 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJM007PWSSNM2@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 14 Jun 2007 08:10:00 -0700 (PDT) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJM00I63SSI31@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 14 Jun 2007 08:09:59 -0700 (PDT) Date: Thu, 14 Jun 2007 10:07:18 -0500 From: Spencer Dawkins Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology To: P2PSIP Mailing List Message-id: <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I want to agree with Philip, and provide a wake-up call... > (2) As I have said before, I really, really want to see good examples of > why we want to make this distinctions between types of peers (or whatever > we call them). Yes, we could design a system that allows for great > flexibility in types of peers allowed, but I want to first understand why > this flexibility is useful. > > To be concrete: I suggest having a section in the document that discusses > these possibilities (and any others that people can think of), but I > suggest holding off in giving them names and elevating them to formal > "concepts" in the document until someone argues why one of these is of > particular interest. >From the meeting minutes at http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html... P2PSIP Client Discussion, Spencer Dawkins What are Clients? Not garden variety SIP UACs, nor the equivalent of "peers." Issue: Clients as storage nodes. No credible use case so far; deferred. [ Discussion ensued at mic. Philip: Why do we need P2PSIP clients? The answer will drive whether or not we use them. Brian Rosen (as individual): I don't understand P2PSIP clients. We need to get rid of it and focus on normal SIP clients. Philip: Those that want P2PSIP Clients need to come up with a good use case by Chicago IETF. If they do not come up by then, the P2PSIP Clients go away. ] Hum - Should the wg work on the normal garden variety SIP UA connected to the DHT via some box (a SIP proxy coupled to a peer)? [ Hum indicated yes. Those that want a P2PSIP Client distinct from a normal SIP client need to get together and work on use cases. ] So - is this actually happening? Or are we trying to come up with a name for a concept we don't need/don't know WHY we need? Just curious... the 00 draft cutoff being Monday, July 2, and all that. Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:12:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqzy-00036A-Bw; Thu, 14 Jun 2007 11:12:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyqzx-00035w-Df for p2psip@ietf.org; Thu, 14 Jun 2007 11:12:33 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hyqzv-0005T5-2J for p2psip@ietf.org; Thu, 14 Jun 2007 11:12:33 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EF9mhC008401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 11:09:48 -0400 (EDT) In-Reply-To: <46714D58.7000408@alcatel-lucent.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 11:10:36 -0400 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We'd have to define a predictable ordering of what to do when presenting with a SIP URI, comprising at least - RFC 3263 - the domain-specific overlay - zero or more "generic" overlays - non-overlay mechanisms, such as Bonjour This doesn't seem to be too hard, as long as a single AOR is unique. bob@example.com should be one logical entity, although there is the practical issue that the set of devices associated with that AOR may well differ among the four resolution mechanisms. Henning On Jun 14, 2007, at 10:14 AM, Vijay K. Gurbani wrote: > Henning Schulzrinne wrote: >> I generally agree with your train of thought until it derails in >> the last paragraph, I think. A slightly weaker requirement that >> also works and is useful is to require that each domain has a >> "default" overlay that one must register with if it is available. > > So, extrapolating from Dean's example and your thoughts above, Bob > would register with overlay B and also with the "default" overlay > for his domain (example.com). When Alice calls Bob, her peer first > searches for Bob in overlay A (Alice's overlay), and not finding Bob > there continues to search for him in the "default" overlay. > > Essentially, a peer would have to maintain and refresh > two registrations -- one to their assigned overlay, and the other > to the "default" overlay (and the other peers in the DHT would need > to maintain and possibly replicate two registrations.) Yes? > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:26:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrDR-0003X9-9v; Thu, 14 Jun 2007 11:26:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrDP-0003SD-LU for p2psip@ietf.org; Thu, 14 Jun 2007 11:26:27 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyrDM-00064m-Rw for p2psip@ietf.org; Thu, 14 Jun 2007 11:26:26 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HyrDG-0004o0-A1; Thu, 14 Jun 2007 10:26:18 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Vijay K. Gurbani'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 11:26:19 -0400 Message-ID: <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> Thread-Index: Aceulm2S2aL0x1IBSIO2Z/tmSKxo9QAARtNA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm sorry, but my head is hurting. It does that when I'm completely clueless, as I am here. I'm sure most of you just looked at this and said "of course". I need to go back to first principals. Can we just forget clients for a sec? Alice has a full peer implementation in the example.com domain. What is Alice's AoR (what is the scheme for example? How does another peer resolve that AoR to the protocol, IP address, etc. needed to create a session with Alice? Assume that peer is very well connected and lives on multiple overlays, as well as several direct SIP C/S domains. I mean, if it's sip:alice@example.com, then the peer is going to do an SRV lookup at example.com for a sip server and try C/S, right? RFC3263 Are you expecting that to fail? Then what happens? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, June 14, 2007 11:11 AM > To: Vijay K. Gurbani > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > We'd have to define a predictable ordering of what to do when > presenting with a SIP URI, comprising at least > > - RFC 3263 > - the domain-specific overlay > - zero or more "generic" overlays > - non-overlay mechanisms, such as Bonjour > > This doesn't seem to be too hard, as long as a single AOR is unique. > bob@example.com should be one logical entity, although there is the > practical issue that the set of devices associated with that AOR may > well differ among the four resolution mechanisms. > > Henning > > On Jun 14, 2007, at 10:14 AM, Vijay K. Gurbani wrote: > > > Henning Schulzrinne wrote: > >> I generally agree with your train of thought until it derails in > >> the last paragraph, I think. A slightly weaker requirement that > >> also works and is useful is to require that each domain has a > >> "default" overlay that one must register with if it is available. > > > > So, extrapolating from Dean's example and your thoughts above, Bob > > would register with overlay B and also with the "default" overlay > > for his domain (example.com). When Alice calls Bob, her peer first > > searches for Bob in overlay A (Alice's overlay), and not finding Bob > > there continues to search for him in the "default" overlay. > > > > Essentially, a peer would have to maintain and refresh > > two registrations -- one to their assigned overlay, and the other > > to the "default" overlay (and the other peers in the DHT would need > > to maintain and possibly replicate two registrations.) Yes? > > > > Thanks, > > > > - vijay > > -- > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > > WWW: http://www.alcatel-lucent.com/bell-labs > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:27:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrEe-0000nk-5J; Thu, 14 Jun 2007 11:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrEa-0000kT-Vu for p2psip@ietf.org; Thu, 14 Jun 2007 11:27:40 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HyrEa-0006KW-8x for p2psip@ietf.org; Thu, 14 Jun 2007 11:27:40 -0400 Received: from source ([192.150.20.142]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Thu, 14 Jun 2007 08:27:34 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5EFRWWs016193; Thu, 14 Jun 2007 08:27:32 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5EFOKID004952; Thu, 14 Jun 2007 08:26:02 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 08:26:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts document: proposal for active/passivepeerterminology Date: Thu, 14 Jun 2007 08:21:57 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> In-Reply-To: <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts document: proposal for active/passivepeerterminology Thread-Index: AceulhwkQCxIQlnrRS+sRsFOteH9JwAALh5w References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> From: "Henry Sinnreich" To: "P2PSIP Mailing List" X-OriginalArrivalTime: 14 Jun 2007 15:26:10.0896 (UTC) FILETIME=[5644CD00:01C7AE98] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At this point, I would like to share some text edited by Marcin Matuszewski for a requirements I-D for the P2P SIP that we are still working on: .... One assumption of DHT networks on the Internet could be that the network nodes are homogenous, and they have enough processing power and memory to run DHT networks without any limits. This assumption does not hold however if we consider mobile devices such as mobile phones, PDAs, or WiFi phones. Mobile devices are heterogeneous. Low-end devices may have a little memory, a slow CPU and may not support fast packet radio interfaces. On the other hand, high-end devices may have significantly higher capabilities: Fast radio interfaces, more memory and faster CPU then they their less advanced counterparts. >From this reason we can classify network nodes into two categories: Mainly those that have enough CPU power, memory and fast network interface to run P2PSIP peer protocol and those that may not have enough capabilities to become P2PSIP peers. Besides, if we consider the issue of NAT traversal, a very powerful mobile device can be behind a restrictive NAT. This may require the device to establish a TCP or TLS connection towards a TURN server. If the connection has to be maintained for a long period, it may drain the device battery. From these reasons, not all battery powered devices though having enough capabilities to run the peer protocol will still not be able to become P2PSIP peers. Essentially, any DHT overlay network can support two basic operations: PUT and GET. In the P2PSIP overlay a PUT operation is used to insert, modify, or delete data in the overlay,such as user or resource records. A GET operation is used to retrieve data stored in the overlay. Clients should be able to store, modify, delete and retrieve user and resource records from the overlay; in the P2P language they must support PUT and GET operations. .... Note again that clients do not participate in the maintenance of the DHT, but may use the DHT for certain functions, such as storage and retrieval of data. Henry -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Thursday, June 14, 2007 5:07 PM To: P2PSIP Mailing List Subject: Re: [P2PSIP] Concepts document: proposal for active/passivepeerterminology I want to agree with Philip, and provide a wake-up call... > (2) As I have said before, I really, really want to see good examples of=20 > why we want to make this distinctions between types of peers (or whatever=20 > we call them). Yes, we could design a system that allows for great=20 > flexibility in types of peers allowed, but I want to first understand why=20 > this flexibility is useful. > > To be concrete: I suggest having a section in the document that discusses=20 > these possibilities (and any others that people can think of), but I=20 > suggest holding off in giving them names and elevating them to formal > "concepts" in the document until someone argues why one of these is of=20 > particular interest. >From the meeting minutes at=20 http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html... P2PSIP Client Discussion, Spencer Dawkins What are Clients? Not garden variety SIP UACs, nor the equivalent of "peers." Issue: Clients as storage nodes. No credible use case so far; deferred. [ Discussion ensued at mic. Philip: Why do we need P2PSIP clients? The answer will drive whether or not we use them. Brian Rosen (as individual): I don't understand P2PSIP clients. We need to get rid of it and focus on normal SIP clients. Philip: Those that want P2PSIP Clients need to come up with a good use case by Chicago IETF. If they do not come up by then, the P2PSIP Clients go away. ] Hum - Should the wg work on the normal garden variety SIP UA connected to the DHT via some box (a SIP proxy coupled to a peer)? [ Hum indicated yes. Those that want a P2PSIP Client distinct from a normal SIP client need to get together and work on use cases. ] So - is this actually happening? Or are we trying to come up with a name for=20 a concept we don't need/don't know WHY we need? Just curious... the 00 draft cutoff being Monday, July 2, and all that. Spencer=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:30:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrHL-0007wn-Js; Thu, 14 Jun 2007 11:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrHK-0007tl-Ma for p2psip@ietf.org; Thu, 14 Jun 2007 11:30:30 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyrHJ-00076j-D0 for p2psip@ietf.org; Thu, 14 Jun 2007 11:30:30 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EFUIb6024586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 11:30:22 -0400 (EDT) In-Reply-To: <10f601c7ae91$99fd8c50$6901a8c0@china.huawei.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <10f601c7ae91$99fd8c50$6901a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 11:31:06 -0400 To: Spencer Dawkins X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 14, 2007, at 10:37 AM, Spencer Dawkins wrote: > Much like Brian's response - Dean described the way I thought this > worked. > > I do like Henning's suggestion, although I'm not sure we're ready > for engineering yet - if you disconnect from the Internet at large, > then set up special overlays based on being disconnected, then > reconnect (ignoring the imprecision of "disconnecting from and > reconnecting to the Internet), would we expect the special overlays > to self-destruct? The special overlay may indeed go away if the nodes leave (or you may leave it). > > I'm not sure what our consensus is about going the other way - can > three or four domains participate in a single overlay? Or did I > miss a conversation? I think this is really a discovery problem. As long as we have a rule of how UAs proceed along a path of discovery and registration, the outcome should be predictable, with only minor complexity increase. We'll already have to deal with at least two ways to resolve an AOR, 3263 and overlay, plus likely a third, multicast-one. I don't see why two domains couldn't share the same overlay. They wouldn't seem to collide or even be visible to each other. If I know to look for alice@example.com on overlay A, and alice@foo.edu is also on overlay A, I don't really care. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:38:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrOo-0004VB-Vf; Thu, 14 Jun 2007 11:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrOn-0004V4-Fv for p2psip@ietf.org; Thu, 14 Jun 2007 11:38:13 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyrOm-0000QZ-3M for p2psip@ietf.org; Thu, 14 Jun 2007 11:38:13 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EFbkWZ015752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 11:37:46 -0400 (EDT) In-Reply-To: <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 11:38:33 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The AOR now takes on essentially two meanings: (1) something that gets fed into the 3263 algorithm, dissected into a user part and domain part, and then proceeds through a recursive resolution process (. -> com -> example.com, via NAPTR and SRV, etc.) (2) an identifier that only has to be unique and simply gets hashed. In theory, I wouldn't even care if example.com is a domain name. If it weren't for SIP URL syntax rules, using my postal address would work just about as well, as long as we can both agree on the format and ordering. (I'm not suggesting that we do anything except AORs, but wanted to highlight the distinction.) We do need to define the structure of the identifier that's input into the hash function. Is it sip:alice@example.com or just alice@example.com? What about various SIP URL parameters? Is sips:alice@example.com different from sip:alice@example.com? Thus, once (1) fails, you proceed to look up the identifier in all available overlays. There are two ways to do that: proceed until you find one mapping and then stop, or gather all candidate resources across all overlays and essentially "fork" the call across these. We have implemented a simple version of this in OpenWengo and it's not terribly hard. Henning On Jun 14, 2007, at 11:26 AM, Brian Rosen wrote: > I'm sorry, but my head is hurting. It does that when I'm completely > clueless, as I am here. I'm sure most of you just looked at this > and said > "of course". > > I need to go back to first principals. > > Can we just forget clients for a sec? Alice has a full peer > implementation > in the example.com domain. What is Alice's AoR (what is the scheme > for > example? How does another peer resolve that AoR to the protocol, IP > address, etc. needed to create a session with Alice? Assume that > peer is > very well connected and lives on multiple overlays, as well as several > direct SIP C/S domains. > > I mean, if it's sip:alice@example.com, then the peer is going to do > an SRV > lookup at example.com for a sip server and try C/S, right? RFC3263 > > Are you expecting that to fail? > > Then what happens? > > Brian > > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Thursday, June 14, 2007 11:11 AM >> To: Vijay K. Gurbani >> Cc: P2PSIP Mailing List >> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays >> >> We'd have to define a predictable ordering of what to do when >> presenting with a SIP URI, comprising at least >> >> - RFC 3263 >> - the domain-specific overlay >> - zero or more "generic" overlays >> - non-overlay mechanisms, such as Bonjour >> >> This doesn't seem to be too hard, as long as a single AOR is unique. >> bob@example.com should be one logical entity, although there is the >> practical issue that the set of devices associated with that AOR may >> well differ among the four resolution mechanisms. >> >> Henning >> >> On Jun 14, 2007, at 10:14 AM, Vijay K. Gurbani wrote: >> >>> Henning Schulzrinne wrote: >>>> I generally agree with your train of thought until it derails in >>>> the last paragraph, I think. A slightly weaker requirement that >>>> also works and is useful is to require that each domain has a >>>> "default" overlay that one must register with if it is available. >>> >>> So, extrapolating from Dean's example and your thoughts above, Bob >>> would register with overlay B and also with the "default" overlay >>> for his domain (example.com). When Alice calls Bob, her peer first >>> searches for Bob in overlay A (Alice's overlay), and not finding Bob >>> there continues to search for him in the "default" overlay. >>> >>> Essentially, a peer would have to maintain and refresh >>> two registrations -- one to their assigned overlay, and the other >>> to the "default" overlay (and the other peers in the DHT would need >>> to maintain and possibly replicate two registrations.) Yes? >>> >>> Thanks, >>> >>> - vijay >>> -- >>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) >>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} >>> WWW: http://www.alcatel-lucent.com/bell-labs >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:38:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrOs-0004Z9-BF; Thu, 14 Jun 2007 11:38:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrOq-0004XX-FH for p2psip@ietf.org; Thu, 14 Jun 2007 11:38:16 -0400 Received: from tidos.tid.es ([193.145.240.2] helo=correo.tid.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyrOq-0000Rl-3a for p2psip@ietf.org; Thu, 14 Jun 2007 11:38:16 -0400 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJM002BJU3PFR@tid.hi.inet> for p2psip@ietf.org; Thu, 14 Jun 2007 17:38:13 +0200 (MEST) Received: from matrix ([10.95.89.24]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJM002BDU3OFR@tid.hi.inet> for p2psip@ietf.org; Thu, 14 Jun 2007 17:38:13 +0200 (MEST) Date: Thu, 14 Jun 2007 17:38:10 +0200 From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= Subject: RE: [P2PSIP] Concepts document: proposal for active/passive peerterminology In-reply-to: To: 'Philip Matthews' Message-id: <059801c7ae9a$03f5b760$0be12620$@es> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: es Content-transfer-encoding: quoted-printable Thread-index: AceulYDxR3paH8WRSReU9ST3XHdINQAAYj6A References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <057d01c7ae94$0f03f960$2d0bec20$@es> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: jueves, 14 de junio de 2007 17:06 > To: Gustavo Garc=EDa > Cc: 'Dean Willis'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive > peerterminology >=20 >=20 > On 14-Jun-07, at 10:55 , Gustavo Garc=EDa wrote: >=20 > >> (2) As I have said before, I really, really want to see good > examples > >> of why we want to make this distinctions between types of peers (or > >> whatever we call them). Yes, we could design a system that allows > for > >> great flexibility in types of peers allowed, but I want to first > >> understand why this flexibility is useful. > > > > IMHO we only need to make the distinction between nodes which > > participate in > > the location of resources (participate in the DHT structure) and > > those who > > only make use of the resource location functions (sending PUT/GET > > requests). > > > > We need to make this distinction because Peers need a PeerID while > for > > Clients this is not clear, because the protocol primitives > > implemented in > > Peers are different from those in Clients, because bootstrapping/ > > joining > > procedures are different (clients don't need to be placed in the DHT > > structure) and because probably they also have different security > > requirements (it is more critical to authorize a peer than a = client). >=20 > I agree that clients might not need peer IDs, and might have a > different protocol stack, > but why do you want clients? What motives you to write additional > software to support > the concept of a client? I have a messenger like application in my mobile phone, and I don't want = to participate in the DHT to save the battery life. I could be a = "traditional" SIP UA and register and make calls using SIP proxy services in the = overlay, but how am I going to retrieve my buddy list stored in the overlay? Are = we going to have XCAP proxy services in the overlay? Are we going to have = a proxy service for each new "capability" needed? If you allow me to be a P2PSI Client I can put this kind of intelligence in my end device independently of the services provided in the overlay (I only need a = PUT/GET interface or something similar). =20 Best regards, G. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 11:42:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrSl-00051m-Sk; Thu, 14 Jun 2007 11:42:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyrSk-00051g-Qq for p2psip@ietf.org; Thu, 14 Jun 2007 11:42:18 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyrSi-0001Zu-SL for p2psip@ietf.org; Thu, 14 Jun 2007 11:42:18 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 17:42:15 +0200 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 17:42:14 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 17:42:14 +0200 Message-ID: <4671623C.8030701@telecomitalia.it> Date: Thu, 14 Jun 2007 17:43:56 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> In-Reply-To: <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> X-OriginalArrivalTime: 14 Jun 2007 15:42:14.0415 (UTC) FILETIME=[949221F0:01C7AE9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664696111==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0664696111== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030806070608040209030400" This is a cryptographically signed message in MIME format. --------------ms030806070608040209030400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Spencer Dawkins wrote: > So - is this actually happening? Or are we trying to come up with a name > for a concept we don't need/don't know WHY we need? As far as I recall, the only credible use case which justifies the existence of the "client" concept is that where a "non contributing" node wants to store/retrieve in the overlay something which can't be encoded in SIP (REGISTER?) messages (e.g. public keys, VM records...). Since such functionalities are not required to realize what the group has been chartered for (are they?) and perhaps they could be used in centralized environments too, well... I personally hope that it _is_ happening and that we get rid of "clients" before the next meeting. -- Ciao, Enrico --------------ms030806070608040209030400 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE0MTU0MzU2WjAjBgkqhkiG9w0BCQQxFgQUxVMVPnqQ v7zqieHJwSsJxy+km18wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBALZUGqMNON2wi0ikWUil3mdGnZRSJgt5o+WzTSF4lKVPDtR+1vrQVPnf gPdHXJyIdoNIatIlt17J9R43FlAzervaft2ELtEHX43CvU1QF9ivZj0PNX6guV3V4j+skTK6 bPNXaU6IlbHENVH9rPufi9CgAuMv5zXgYAOCi+myovLbpw+Bg+iRybJ0zcqjFHr99L/KK/b5 GoN597ZERQmQuMSrkeswvFkU2NBkE+INGX78sJFXyT/2PtxUSenAQQd4inSFBXTb7365glRs QuzRkQtT7Zd+EK5cugQ2RJ/+3My/2gSkyEObfJ1IREYi3t2uHQWyPPLU8NyP4N1FgGh9sxoA AAAAAAA= --------------ms030806070608040209030400-- --===============0664696111== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0664696111==-- From p2psip-bounces@ietf.org Thu Jun 14 12:28:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysB8-0002Qy-I1; Thu, 14 Jun 2007 12:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysB7-0002QB-OB for p2psip@ietf.org; Thu, 14 Jun 2007 12:28:09 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HysB6-0001Sw-8g for p2psip@ietf.org; Thu, 14 Jun 2007 12:28:09 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HysAz-0008Oq-1r; Thu, 14 Jun 2007 11:28:01 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 12:28:04 -0400 Message-ID: <090301c7aea0$fdee6d10$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Aceumf/oX4MMydJsQHCV0kqey/7ZXwABKgkQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Okay, so if I understand what you are saying, the idea is that we have this "if 3263 fails, try this" idea that maybe the user is on some random p2psip overlay, and the sending peer should blindly try any or all of them that it has access to see if it can get a message to Alice. That seems pretty dumb to me, but maybe I'm the weird one. I would think we would want to have some more definitive way to know which overlay(s), if any, the domain of the AoR was on. Frankly, I think example.com should say which overlays its domain may be resolved it, by some kind of DNS record. Further, it would be very annoying that you had a SIP AoR, with a domain, but there was no SRV that supplied a sip service in that domain. The domain DOES have a sip service, but its p2psip, not c/s sip. Somehow, I think we should be more explicit. My head is hurting less, but I don't like the answer much. Was everyone else thinking it works the way Henning describes it? I want to get back to the sip client idea, just blindly accepting the mechanism works as described. In the example above, Alice has credentials in the overlay. Now suppose Alice is C/S, connected to a proxy peer. Does Alice have credentials in the overlay? The proxy does, for sure. How do I address a message to Alice now? How does anyone figure out the identity of the proxy peer so the overlay can be used to contact it in order for it to relay sip messages to Alice? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, June 14, 2007 11:39 AM > To: Brian Rosen > Cc: 'Vijay K. Gurbani'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > The AOR now takes on essentially two meanings: > > (1) something that gets fed into the 3263 algorithm, dissected into a > user part and domain part, and then proceeds through a recursive > resolution process (. -> com -> example.com, via NAPTR and SRV, etc.) > > (2) an identifier that only has to be unique and simply gets hashed. > In theory, I wouldn't even care if example.com is a domain name. If > it weren't for SIP URL syntax rules, using my postal address would > work just about as well, as long as we can both agree on the format > and ordering. (I'm not suggesting that we do anything except AORs, > but wanted to highlight the distinction.) > > We do need to define the structure of the identifier that's input > into the hash function. Is it sip:alice@example.com or just > alice@example.com? What about various SIP URL parameters? Is > sips:alice@example.com different from sip:alice@example.com? > > Thus, once (1) fails, you proceed to look up the identifier in all > available overlays. There are two ways to do that: proceed until you > find one mapping and then stop, or gather all candidate resources > across all overlays and essentially "fork" the call across these. > > We have implemented a simple version of this in OpenWengo and it's > not terribly hard. > > Henning > > On Jun 14, 2007, at 11:26 AM, Brian Rosen wrote: > > > I'm sorry, but my head is hurting. It does that when I'm completely > > clueless, as I am here. I'm sure most of you just looked at this > > and said > > "of course". > > > > I need to go back to first principals. > > > > Can we just forget clients for a sec? Alice has a full peer > > implementation > > in the example.com domain. What is Alice's AoR (what is the scheme > > for > > example? How does another peer resolve that AoR to the protocol, IP > > address, etc. needed to create a session with Alice? Assume that > > peer is > > very well connected and lives on multiple overlays, as well as several > > direct SIP C/S domains. > > > > I mean, if it's sip:alice@example.com, then the peer is going to do > > an SRV > > lookup at example.com for a sip server and try C/S, right? RFC3263 > > > > Are you expecting that to fail? > > > > Then what happens? > > > > Brian > > > > > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Thursday, June 14, 2007 11:11 AM > >> To: Vijay K. Gurbani > >> Cc: P2PSIP Mailing List > >> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > >> > >> We'd have to define a predictable ordering of what to do when > >> presenting with a SIP URI, comprising at least > >> > >> - RFC 3263 > >> - the domain-specific overlay > >> - zero or more "generic" overlays > >> - non-overlay mechanisms, such as Bonjour > >> > >> This doesn't seem to be too hard, as long as a single AOR is unique. > >> bob@example.com should be one logical entity, although there is the > >> practical issue that the set of devices associated with that AOR may > >> well differ among the four resolution mechanisms. > >> > >> Henning > >> > >> On Jun 14, 2007, at 10:14 AM, Vijay K. Gurbani wrote: > >> > >>> Henning Schulzrinne wrote: > >>>> I generally agree with your train of thought until it derails in > >>>> the last paragraph, I think. A slightly weaker requirement that > >>>> also works and is useful is to require that each domain has a > >>>> "default" overlay that one must register with if it is available. > >>> > >>> So, extrapolating from Dean's example and your thoughts above, Bob > >>> would register with overlay B and also with the "default" overlay > >>> for his domain (example.com). When Alice calls Bob, her peer first > >>> searches for Bob in overlay A (Alice's overlay), and not finding Bob > >>> there continues to search for him in the "default" overlay. > >>> > >>> Essentially, a peer would have to maintain and refresh > >>> two registrations -- one to their assigned overlay, and the other > >>> to the "default" overlay (and the other peers in the DHT would need > >>> to maintain and possibly replicate two registrations.) Yes? > >>> > >>> Thanks, > >>> > >>> - vijay > >>> -- > >>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > >>> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > >>> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > >>> WWW: http://www.alcatel-lucent.com/bell-labs > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 12:37:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysK9-0005vo-Pd; Thu, 14 Jun 2007 12:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysK8-0005vf-Nr for p2psip@ietf.org; Thu, 14 Jun 2007 12:37:28 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HysK6-0003C0-DV for p2psip@ietf.org; Thu, 14 Jun 2007 12:37:28 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l5EGafkU024946; Thu, 14 Jun 2007 11:36:41 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l5EGafa07855; Thu, 14 Jun 2007 11:36:41 -0500 (CDT) Message-ID: <46716E99.4090809@alcatel-lucent.com> Date: Thu, 14 Jun 2007 11:36:41 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henning Schulzrinne wrote: > The AOR now takes on essentially two meanings: > > (1) something that gets fed into the 3263 algorithm, dissected into a > user part and domain part, and then proceeds through a recursive > resolution process (. -> com -> example.com, via NAPTR and SRV, etc.) > > (2) an identifier that only has to be unique and simply gets hashed. In > theory, I wouldn't even care if example.com is a domain name. If it > weren't for SIP URL syntax rules, using my postal address would work > just about as well, as long as we can both agree on the format and > ordering. (I'm not suggesting that we do anything except AORs, but > wanted to highlight the distinction.) [...] > Thus, once (1) fails, you proceed to look up the identifier in all > available overlays. There are two ways to do that: proceed until you > find one mapping and then stop, or gather all candidate resources > across all overlays and essentially "fork" the call across these. Shouldn't (2) happen first in a P2P network? In other words, ISTM that DNS et al. via rfc3263 should kick in *after* the overlay lookup has failed My model is that when a peer joins, it only knows its bootstrap node. The bootstrap node tells the peer the name of the overlay and other associated logistics (joining peer, other servers like STUN server, etc.) At this point, I really do not understand how the overlay name gets chosen and how it is represented -- flat? hierarchical? But, I will consider that a detail to be worked out later. If it is a pure P2PSIP peer and only interested in communicating with other peers in that overlay, it won't register anywhere else. If it is interested in also communicating with C/S SIP user agents, it will also register itself into the "default" overlay for its DNS domain, allowing C/S SIP clients from the same DNS domain or other DNS domains to look it up using rfc3263. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 12:54:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaI-00052W-M8; Thu, 14 Jun 2007 12:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HysaH-00052O-94 for p2psip@ietf.org; Thu, 14 Jun 2007 12:54:09 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HysaF-00065d-0h for p2psip@ietf.org; Thu, 14 Jun 2007 12:54:09 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EGs3qo016017 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 12:54:04 -0400 (EDT) In-Reply-To: <46716E99.4090809@alcatel-lucent.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <46716E99.4090809@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E6A62F3-C099-424D-8465-F32131653E3F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 12:54:51 -0400 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 14, 2007, at 12:36 PM, Vijay K. Gurbani wrote: > > Shouldn't (2) happen first in a P2P network? In other words, > ISTM that DNS et al. via rfc3263 should kick in *after* the > overlay lookup has failed > I don't much care about the order. Arguments can be made either way. For example, "stealing" somebody's registration is probably easier in P2P, but it is less attractive a target if the 3263 is followed first. > My model is that when a peer joins, it only knows its bootstrap > node. The bootstrap node tells the peer the name of the overlay There may not always be a single bootstrap node. Bootstrap could in some scenarios, such as a corporate network, rely on other service discovery mechanisms. Having a single bootstrap node means having a single point of failure. I think we need to have a broader discussion as to whether we assume a functioning DNS (and access to that). One of the applications we have talked about is usage during emergencies, where this is probably not a given. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 13:54:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytWV-0004A4-6q; Thu, 14 Jun 2007 13:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HytWT-00049z-W8 for p2psip@ietf.org; Thu, 14 Jun 2007 13:54:17 -0400 Received: from bay0-omc1-s15.bay0.hotmail.com ([65.54.246.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HytWT-00046r-E0 for p2psip@ietf.org; Thu, 14 Jun 2007 13:54:17 -0400 Received: from BAYC1-PASMTP04.CEZ.ICE ([65.54.191.164]) by bay0-omc1-s15.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Thu, 14 Jun 2007 10:54:16 -0700 X-Originating-IP: [216.13.42.68] X-Originating-Email: [eric_d_cooper@sympatico.ca] Received: from Ronin ([216.13.42.68]) by BAYC1-PASMTP04.CEZ.ICE over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2668); Thu, 14 Jun 2007 10:54:16 -0700 Message-ID: <000001c7aead$09d5cbd0$65500a0a@Ronin> From: "Eric Cooper" To: "P2PSIP Mailing List" , "Dean Willis" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 12:17:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 14 Jun 2007 17:54:16.0685 (UTC) FILETIME=[069C99D0:01C7AEAD] X-Spam-Score: 2.2 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm in favour of keeping it simple (one domain == one overlay), but I don't see a mechanism for enforcing it. As Henning mentioned, I think it all depends on how you locate overlays. Perhaps the mechanism for locating overlays could enforce the 1:1 mapping, but there's always the possibility that the overlay is disconnected from the mechanism. Best Regards, Eric. ----- Original Message ----- From: "Dean Willis" To: "P2PSIP Mailing List" Sent: Wednesday, June 13, 2007 7:00 PM Subject: [P2PSIP] Concepts issue: Domains and Overlays > > Someone brought this up on the list, and I wanted to clarify the > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many domains. > In this model, there might be only one overlay serving every domain in > the world, including (for example) "example.com" and "example.net". > Clearly routing messages within this overlay is straightforward, and > there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not all > domains, and we use RFC 3263 procedures to route between overlays. So > "example.com" might be in one overlay, and "example.net" in another. Each > overlay can look up the other in DNS to find it. > > This second model mostly precludes having one domain scattered across > multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and he's > not there. What to do? She can't just look up example.com in DNS, because > it has been split across A and B and DNS just doesn't work that way. Now, > if both A and B registered with some "upstream" lookup function (a > meta-overlay), then Alice could perhaps look there. But this starts to > get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays problem > (and that's not easy), we're much better off at this time having a model > where each domain can be mapped onto only one overlay at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 14:02:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyte5-0005m8-2s; Thu, 14 Jun 2007 14:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyte4-0005kt-AO for p2psip@ietf.org; Thu, 14 Jun 2007 14:02:08 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyte2-0005pw-Sp for p2psip@ietf.org; Thu, 14 Jun 2007 14:02:08 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EI1m90021620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2007 14:01:54 -0400 (EDT) Date: Thu, 14 Jun 2007 14:01:48 -0400 (EDT) From: Salman Abdul Baset To: Henry Sinnreich Subject: RE: [P2PSIP] Concepts document: proposal for active/passivepeerterminology In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> Message-ID: References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Further elaborating the point by Henry/Marcin on the usage 'clients' and the variety of 'peers': 1) A device's processing/connection capabilites are "limited" and particpating in a full blown DHT is a big hit on its resources such as limited battery-life or bandwidth. 2) The nodes are behind a "restricted NAT/firewall" and it might be feasible to leave them out of a DHT than to adopt the best NAT traversal solution that allows these nodes to fully participate in the DHT. Skype adopts this solution. 3) The concept of a 'client' easily lends itself to the creation of hierachical overlays. Peers perform the basic routing function but they can also have different capabilities. For concept draft purposes, I don't think we need to further disambiguate the peer concept based on the capabilities such as storage, CPU or b/w; that should be left to the overlay designer. -salman On Thu, 14 Jun 2007, Henry Sinnreich wrote: > At this point, I would like to share some text edited by Marcin > Matuszewski for a requirements I-D for the P2P SIP that we are still > working on: > .... > One assumption of DHT networks on the Internet could be that the network > nodes are homogenous, and they have enough processing power and memory > to run DHT networks without any limits. This assumption does not hold > however if we consider mobile devices such as mobile phones, PDAs, or > WiFi phones. Mobile devices are heterogeneous. Low-end devices may have > a little memory, a slow CPU and may not support fast packet radio > interfaces. On the other hand, high-end devices may have significantly > higher capabilities: Fast radio interfaces, more memory and faster CPU > then they their less advanced counterparts. > >> From this reason we can classify network nodes into two categories: > Mainly those that have enough CPU power, memory and fast network > interface to run P2PSIP peer protocol and those that may not have enough > capabilities to become P2PSIP peers. > > Besides, if we consider the issue of NAT traversal, a very powerful > mobile device can be behind a restrictive NAT. This may require the > device to establish a TCP or TLS connection towards a TURN server. If > the connection has to be maintained for a long period, it may drain the > device battery. From these reasons, not all battery powered devices > though having enough capabilities to run the peer protocol will still > not be able to become P2PSIP peers. > > Essentially, any DHT overlay network can support two basic operations: > PUT and GET. In the P2PSIP overlay a PUT operation is used to insert, > modify, or delete data in the overlay,such as user or resource records. > A GET operation is used to retrieve data stored in the overlay. Clients > should be able to store, modify, delete and retrieve user and resource > records from the overlay; in the P2P language they must support PUT and > GET operations. > .... > Note again that clients do not participate in the maintenance of the > DHT, but may use the DHT for certain functions, such as storage and > retrieval of data. > > Henry > > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Thursday, June 14, 2007 5:07 PM > To: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts document: proposal for > active/passivepeerterminology > > I want to agree with Philip, and provide a wake-up call... > >> (2) As I have said before, I really, really want to see good examples > of >> why we want to make this distinctions between types of peers (or > whatever >> we call them). Yes, we could design a system that allows for great >> flexibility in types of peers allowed, but I want to first understand > why >> this flexibility is useful. >> >> To be concrete: I suggest having a section in the document that > discusses >> these possibilities (and any others that people can think of), but I >> suggest holding off in giving them names and elevating them to formal > >> "concepts" in the document until someone argues why one of these is > of >> particular interest. > >> From the meeting minutes at > http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html... > > P2PSIP Client Discussion, Spencer Dawkins > > What are Clients? Not garden variety SIP UACs, nor the equivalent of > "peers." > > Issue: Clients as storage nodes. No credible use case so far; deferred. > > [ Discussion ensued at mic. > > Philip: Why do we need P2PSIP clients? The answer will drive whether > or > not we use them. > > Brian Rosen (as individual): I don't understand P2PSIP clients. We > need > to get rid of it and focus on normal SIP clients. > > Philip: Those that want P2PSIP Clients need to come up with a good use > case by Chicago IETF. If they do not come up by then, the P2PSIP > Clients > go away. ] > > Hum - Should the wg work on the normal garden variety SIP UA connected > to > the DHT via some box (a SIP proxy coupled to a peer)? > > [ Hum indicated yes. > Those that want a P2PSIP Client distinct from a normal SIP client need > to > get together and work on use cases. ] > > So - is this actually happening? Or are we trying to come up with a name > for > a concept we don't need/don't know WHY we need? > > Just curious... the 00 draft cutoff being Monday, July 2, and all that. > > Spencer > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 14:23:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hytz2-0002qS-QP; Thu, 14 Jun 2007 14:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hytz1-0002qK-6o for p2psip@ietf.org; Thu, 14 Jun 2007 14:23:47 -0400 Received: from [2001:470:1:1:230:48ff:fe74:fd02] (helo=bender-mail.tigertech.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hytyz-00039L-MJ for p2psip@ietf.org; Thu, 14 Jun 2007 14:23:47 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id DEA107DB9 for ; Thu, 14 Jun 2007 11:23:44 -0700 (PDT) Received: from JMHLap3.joelhalpern.com (pool-71-240-234-175.fred.east.verizon.net [71.240.234.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 15F307DDC for ; Thu, 14 Jun 2007 11:23:42 -0700 (PDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 14 Jun 2007 14:23:37 -0400 To: "P2PSIP Mailing List" From: "Joel M. Halpern" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: <000001c7aead$09d5cbd0$65500a0a@Ronin> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <000001c7aead$09d5cbd0$65500a0a@Ronin> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070614182342.15F307DDC@bender.tigertech.net> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=-2.8 tagged_above=-999.0 required=7.0 tests=ALL_TRUSTED X-Spam-Level: X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org While I have not thought on this as deeply as some, I think that the idea of randomly trying the variously overlays one knows of to look for party seems deeply flawed. It seems like there needs to be a way to go from an AoR to at least one likely candidate overlay, and a way to find an entry point to that overlay even if one normally doesn't participate in it. One can bend things in interesting ways if that location function is itself a function provided by ones preferred overlay. But it still has to happen, and happen in a way that is not dependent on the DHT functions themselves. (Please, let's not duplicate all of the global delegation infrastructure into the DHT.) It does seem that any given domain ought to be primarily handled by a some specific overlay. That overlay might handle several domains (so it is not 1:1.) The ability to create ad-hoc overlays is clearly required. And one would clearly prefer not to have to create domain names and AoRs just for that. However, the binding authentication gets MUCH more complicated. And one starts down the slope of having to try candidate overlays to see where someone is. Maybe some means of recording in ones home overlay that one is also in some specific other overlay would work? Yours, Joel M. Halpern At 12:17 PM 6/14/2007, Eric Cooper wrote: >I'm in favour of keeping it simple (one domain == one overlay), but >I don't see a mechanism for enforcing it. > >As Henning mentioned, I think it all depends on how you locate overlays. > >Perhaps the mechanism for locating overlays could enforce the 1:1 >mapping, but there's always the possibility that the overlay is >disconnected from the mechanism. > >Best Regards, > >Eric. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 15:06:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyueF-0000Mx-DJ; Thu, 14 Jun 2007 15:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyueE-0000Ms-MH for p2psip@ietf.org; Thu, 14 Jun 2007 15:06:22 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyueC-0002WM-VP for p2psip@ietf.org; Thu, 14 Jun 2007 15:06:22 -0400 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 21:06:19 +0200 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 21:06:19 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 21:06:18 +0200 Message-ID: <467192AE.6070800@telecomitalia.it> Date: Thu, 14 Jun 2007 21:10:38 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Salman Abdul Baset Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> In-Reply-To: X-OriginalArrivalTime: 14 Jun 2007 19:06:18.0539 (UTC) FILETIME=[16A32FB0:01C7AEB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1177101901==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1177101901== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090809090604080105080708" This is a cryptographically signed message in MIME format. --------------ms090809090604080105080708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Salman Abdul Baset wrote: > 1) A device's processing/connection capabilites are "limited" and > particpating in a full blown DHT is a big hit on its resources such as > limited battery-life or bandwidth. > > 2) The nodes are behind a "restricted NAT/firewall" and it might be > feasible to leave them out of a DHT than to adopt the best NAT traversal > solution that allows these nodes to fully participate in the DHT. Skype > adopts this solution. 100% agree; if a device doesn't want (or has not enough resources or is not welcome) to participate in an overlay, it can just use it, simply acting as a SIP user agent. I don't get why one should consider it a client, i.e. something more than a UA, but non really a peer. > 3) The concept of a 'client' easily lends itself to the creation of > hierachical overlays. Uh? Can you elaborate a little? > Peers perform the basic routing function but they can also have > different capabilities. For concept draft purposes, I don't think we > need to further disambiguate the peer concept based on the capabilities > such as storage, CPU or b/w; that should be left to the overlay designer. I agree on this too. -- Ciao, Enrico --------------ms090809090604080105080708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE0MTkxMDM4WjAjBgkqhkiG9w0BCQQxFgQUj97aB/+9 vKKpkRoVjLV/IljIFQwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAIQGBU8cSxSA6Lu5MBc+BI6W6uiyk6p19ypqXVRTuFjat+IhhtKvwTys Y9mZTkwTa4yxXg2V4mQqQAERyhQKFlHBjY/WQCqH5sinkKmrrm0qRXpQMDq6GTVx7ET8U1Ui BpFz1iT98jagYwzKM6AKpayqo06iZcq9bu753ENRhMYLtjLy5zoNHfLmxcuaR6MmyNOtxSI7 3rKiTKEiwFWMb8T1Vo3NPMUTEnq9M+BqzO5/Tqd6Tcroa+aUvxDnsOG8IWvZ+3kDlxFd6CR7 5/B58m5TPplXFJt/GDCidXDKVG2+rvW8QT4iWbt3cY+MjmYa/70LvkqHEjOyP1EovYAXUYwA AAAAAAA= --------------ms090809090604080105080708-- --===============1177101901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1177101901==-- From p2psip-bounces@ietf.org Thu Jun 14 15:08:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyug8-0001FO-IV; Thu, 14 Jun 2007 15:08:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyug7-0001FH-K4 for p2psip@ietf.org; Thu, 14 Jun 2007 15:08:19 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyug7-0003ZM-AD for p2psip@ietf.org; Thu, 14 Jun 2007 15:08:19 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Hyuft-0001QU-EO; Thu, 14 Jun 2007 14:08:06 -0500 In-Reply-To: <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <67D01DEA-27DA-4F93-ACF6-3A0551427944@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 14:07:46 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 13, 2007, at 7:04 PM, Henning Schulzrinne wrote: > I generally agree with your train of thought until it derails in > the last paragraph, I think. A slightly weaker requirement that > also works and is useful is to require that each domain has a > "default" overlay that one must register with if it is available. > There is nothing wrong with registering in wild-card domains for > special purposes. For example, this can occur when such an overlay > is disconnected from the Internet at large. Would you want to set > up a per-domain overlay for each and every AOR domain in that case? > (I realize that detecting this case can get messy, but this largely > depends on how we solve the overlay discovery problem.) In this case, I'd put everybody into one domain. The real problem happens when this disconnected overlay you are proposing suddenly regains connectivity to the Internet, or when it gains connectivity to another overlay. If we're routing between overlays based on the "domain parts" of names, then we're in a quandary whenever a given domain (aka namespace) exits in two or more discrete chunks, whether those be inside overlays or as partitions of a conventional domain. Let's revert back to thinking about conventional SIP for a moment. Presume we have domain "example.com", and users Alice and Bob, and two proxy/registrars A and B, both of which think they are the only proxy/registrars for "example.com". Therefore, example.com is partitioned. Alice registers at A, Bob registers at B. Alice can't call Bob, because the only proxy/registrar she knows about doesn't know Bob exists. Same for Bob, who can't call Alice. Sure, for the two-proxy problem, one proxy could always assume that any name it doesn't recognize is at the other proxy, but this quickly breaks down as the number of proxies increases. To make this work in the general n-partition case, we'd need a way for the proxies to discover each other and learn which part of the namespace is being held by each other. Further, we need to keep track of this topology as the connections between overlasy shift. Basically, we're talking dynamic routing on a per-name, not per-domain, basis. Note that conventional SIP doesn't have anything like this today, but good-old spanning tree ethernet does, and we understand the limits of that pretty clearly, and it's not reaching the kind of size/space/time constraints we're dealing with in large overlays. So unless you can convince folks that we're really prepared to develop a unified theory of per-name SIP dynamic routing that encompasses both conventional and client-server SIP, I strongly suggest we restrict ourselves to the cases in which namespaces are not partitioned and we can use RFC 3263 between namespaces. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 15:45:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvFp-0001i0-IS; Thu, 14 Jun 2007 15:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvFk-0001fF-Oc for p2psip@ietf.org; Thu, 14 Jun 2007 15:45:08 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvDC-0001HZ-O1 for p2psip@ietf.org; Thu, 14 Jun 2007 15:42:31 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HyvDB-0001S5-GM for p2psip@ietf.org; Thu, 14 Jun 2007 14:42:29 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Dean Willis Date: Thu, 14 Jun 2007 14:42:10 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [P2PSIP] Acitve/Passive vs Contributing/Non-contributing X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org It's been suggested we might classify the peers that contribute resources as "contributing peers", instead of "active peers", and the ones that don't as "non-contributing peers", rather than "passive peers." On further reflection, I think I like this nomenclature better than the previous proposal. And it avoids a vocabulary conflict with a soon-to-be published draft that somebody else brought to my attention. So does this sound okay to you folks for now? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 15:55:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvPR-0007FR-3N; Thu, 14 Jun 2007 15:55:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvPQ-0007FF-Mi for p2psip@ietf.org; Thu, 14 Jun 2007 15:55:08 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvPQ-000421-EU for p2psip@ietf.org; Thu, 14 Jun 2007 15:55:08 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EJt3CM001978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 15:55:04 -0400 (EDT) In-Reply-To: <67D01DEA-27DA-4F93-ACF6-3A0551427944@softarmor.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <67D01DEA-27DA-4F93-ACF6-3A0551427944@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4179B0D1-1A06-4D52-99A1-F6CA95B4C1A1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 15:55:51 -0400 To: Dean Willis X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I don't think the problem is as hard as you make it to be. I specified a reasonable set of steps that try out a, typically very small, number of possibilities. This isn't fundamentally different from trying different DNS record types, for example. My concern is that insisting on 3263 isn't likely to work in many applications where P2P actually matters beyond buzzword compliance, namely in infrastructure-challenged environments. Henning On Jun 14, 2007, at 3:07 PM, Dean Willis wrote: > > On Jun 13, 2007, at 7:04 PM, Henning Schulzrinne wrote: > >> I generally agree with your train of thought until it derails in >> the last paragraph, I think. A slightly weaker requirement that >> also works and is useful is to require that each domain has a >> "default" overlay that one must register with if it is available. >> There is nothing wrong with registering in wild-card domains for >> special purposes. For example, this can occur when such an overlay >> is disconnected from the Internet at large. Would you want to set >> up a per-domain overlay for each and every AOR domain in that >> case? (I realize that detecting this case can get messy, but this >> largely depends on how we solve the overlay discovery problem.) > > In this case, I'd put everybody into one domain. > > The real problem happens when this disconnected overlay you are > proposing suddenly regains connectivity to the Internet, or when it > gains connectivity to another overlay. > > If we're routing between overlays based on the "domain parts" of > names, then we're in a quandary whenever a given domain (aka > namespace) exits in two or more discrete chunks, whether those be > inside overlays or as partitions of a conventional domain. > > Let's revert back to thinking about conventional SIP for a moment. > Presume we have domain "example.com", and users Alice and Bob, and > two proxy/registrars A and B, both of which think they are the only > proxy/registrars for "example.com". Therefore, example.com is > partitioned. > > Alice registers at A, Bob registers at B. Alice can't call Bob, > because the only proxy/registrar she knows about doesn't know Bob > exists. Same for Bob, who can't call Alice. > > Sure, for the two-proxy problem, one proxy could always assume that > any name it doesn't recognize is at the other proxy, but this > quickly breaks down as the number of proxies increases. To make > this work in the general n-partition case, we'd need a way for the > proxies to discover each other and learn which part of the > namespace is being held by each other. Further, we need to keep > track of this topology as the connections between overlasy shift. > Basically, we're talking dynamic routing on a per-name, not per- > domain, basis. Note that conventional SIP doesn't have anything > like this today, but good-old spanning tree ethernet does, and we > understand the limits of that pretty clearly, and it's not reaching > the kind of size/space/time constraints we're dealing with in large > overlays. > > So unless you can convince folks that we're really prepared to > develop a unified theory of per-name SIP dynamic routing that > encompasses both conventional and client-server SIP, I strongly > suggest we restrict ourselves to the cases in which namespaces are > not partitioned and we can use RFC 3263 between namespaces. > > -- > Dean > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 16:01:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvVb-00009i-V2; Thu, 14 Jun 2007 16:01:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvVb-00009Z-Gt for p2psip@ietf.org; Thu, 14 Jun 2007 16:01:31 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvVa-0006BR-AB for p2psip@ietf.org; Thu, 14 Jun 2007 16:01:31 -0400 Received: by wr-out-0506.google.com with SMTP id 70so551759wra for ; Thu, 14 Jun 2007 13:01:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nOC9XKvG+S6o8lTht0K8GGC4GSeUpN7HO9jbg7g4EIuqDDJnz8ti+3SiMY5bQA+f9Ipg1Ljtyg/acrSSLPRMpypT0FVH74dLUbIzAiKB7GoCLGD4w+D1wqkRagrLF/eds0hwQMh1ZYljIaRLCU/MrZBIdHPcvMesAeNzJYKCpTw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fa8cUi7amyBqktxpKGBtWgHttuuYbIeKCk8NlKEP6zgQKoQEw4J4WOqwyWMBJOWXV3wGN/1ZyApmMVNklAcDclGeBmGc9pttm7Q6Oa88H+2/okd4JvRRqUpBaRviMDO4/TVo8KRsdGSUyS1CULwAH1VpBX0JkrfwWk6eqi+gU4o= Received: by 10.78.160.4 with SMTP id i4mr880512hue.1181851288951; Thu, 14 Jun 2007 13:01:28 -0700 (PDT) Received: by 10.78.165.12 with HTTP; Thu, 14 Jun 2007 13:01:28 -0700 (PDT) Message-ID: Date: Thu, 14 Jun 2007 16:01:28 -0400 From: "Bill Mccormick" To: "Dean Willis" Subject: Re: [P2PSIP] Acitve/Passive vs Contributing/Non-contributing In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org My 2 cents. I don't like it. In every DHT I've studied (Chord, Pastry and Kademlia) peers have to participate in the DHT. This means they have an overlay address in the DHT (this is usually the digest of the node's IP address) and they are routable in the DHT. Any node in the DHT with an overlay address has to be able to store information. Remember the rule for finding data in the DHT - the data is stored on the node(s) whose overlay address is closed to the digest of the key of the data. If there are non-contributing peers, how do you find data that's supposed to be stored on those peers? I think you're either a peer or you're not. If you're not a peer, you don't store data, and you don't participate in the DHT routing protocols. If you are a peer, then you store data and you are part of routing through the DHT. -- Bill McCormick _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 16:24:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvrW-0002bm-AY; Thu, 14 Jun 2007 16:24:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvrU-0002be-Uk for p2psip@ietf.org; Thu, 14 Jun 2007 16:24:08 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvrT-00015t-Oi for p2psip@ietf.org; Thu, 14 Jun 2007 16:24:08 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EKO404027710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2007 16:24:07 -0400 (EDT) Date: Thu, 14 Jun 2007 16:24:04 -0400 (EDT) From: Salman Abdul Baset To: Enrico Marocco Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology In-Reply-To: <467192AE.6070800@telecomitalia.it> Message-ID: References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> <467192AE.6070800@telecomitalia.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> 3) The concept of a 'client' easily lends itself to the creation of >> hierachical overlays. > > Uh? Can you elaborate a little? Imagine, there is an organization with a hierarchy and there is an overlay per hierarchy. There are at least two ways to connect such hierarhical overlays a) through peers that participate in both overlays b) peers in lower overlays act as clients to peers in higher overlays. >> Peers perform the basic routing function but they can also have >> different capabilities. For concept draft purposes, I don't think we >> need to further disambiguate the peer concept based on the capabilities >> such as storage, CPU or b/w; that should be left to the overlay designer. > > I agree on this too. > > -- > Ciao, > Enrico > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 16:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvvJ-0002u2-UZ; Thu, 14 Jun 2007 16:28:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyvvI-0002tL-Mc for p2psip@ietf.org; Thu, 14 Jun 2007 16:28:04 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyvvI-000255-8C for p2psip@ietf.org; Thu, 14 Jun 2007 16:28:04 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1Hyvv7-00056n-Vg; Thu, 14 Jun 2007 15:27:54 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Dean Willis'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><67D01DEA-27DA-4F93-ACF6-3A0551427944@softarmor.com> <4179B0D1-1A06-4D52-99A1-F6CA95B4C1A1@cs.columbia.edu> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 16:27:59 -0400 Message-ID: <09b301c7aec2$825addb0$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4179B0D1-1A06-4D52-99A1-F6CA95B4C1A1@cs.columbia.edu> Thread-Index: AceuveXAENJLc6QdRk+Os1lUb6F+qgAAxb4g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Okay, let's talk about those environments. I like them, and want p2psip to work in them. I assume we all are expecting that we don't have DNS. I assume that we have the IP Address (not a domain name) of one or more bootstrap peers. I assume we have credentials for the overlay, and furthermore that each peer can validate those credentials without needing some other service I assume we have our own IP address, and an AoR, which for this purpose is just a string we can hash. Where is the problem? Even if we started at 3263, that fails. We go to the bootstrap server, present our credentials and get admitted into the overlay. We try to connect to our buddy, and if he is on the overlay, we find him. What won't work without a lot of assumptions we don't want to make is proxy peers, and inter-overlay routing, and other stuff. But p2p will work, as long as the credentials are accepted in the absence of any kind of service to assist in validating them. I still think in more benign environments, we want more explicit declarations of what overlays a domain supports, and not a "try them all and see what happens" mechanism. Getting back to your message, I don't think it's necessarily a very small number. Just consider that I CURRENTLY have 7 or 8 active IM accounts. If they were all peer to peer, I could be broadcasting your AoR in all of them trying to find you. That seems silly, and not scaleable, because some of those overlays are very big, and I don't want lots of "try them all" messages zinging around. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, June 14, 2007 3:56 PM > To: Dean Willis > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > I don't think the problem is as hard as you make it to be. I > specified a reasonable set of steps that try out a, typically very > small, number of possibilities. This isn't fundamentally different > from trying different DNS record types, for example. > > My concern is that insisting on 3263 isn't likely to work in many > applications where P2P actually matters beyond buzzword compliance, > namely in infrastructure-challenged environments. > > Henning > > On Jun 14, 2007, at 3:07 PM, Dean Willis wrote: > > > > > On Jun 13, 2007, at 7:04 PM, Henning Schulzrinne wrote: > > > >> I generally agree with your train of thought until it derails in > >> the last paragraph, I think. A slightly weaker requirement that > >> also works and is useful is to require that each domain has a > >> "default" overlay that one must register with if it is available. > >> There is nothing wrong with registering in wild-card domains for > >> special purposes. For example, this can occur when such an overlay > >> is disconnected from the Internet at large. Would you want to set > >> up a per-domain overlay for each and every AOR domain in that > >> case? (I realize that detecting this case can get messy, but this > >> largely depends on how we solve the overlay discovery problem.) > > > > In this case, I'd put everybody into one domain. > > > > The real problem happens when this disconnected overlay you are > > proposing suddenly regains connectivity to the Internet, or when it > > gains connectivity to another overlay. > > > > If we're routing between overlays based on the "domain parts" of > > names, then we're in a quandary whenever a given domain (aka > > namespace) exits in two or more discrete chunks, whether those be > > inside overlays or as partitions of a conventional domain. > > > > Let's revert back to thinking about conventional SIP for a moment. > > Presume we have domain "example.com", and users Alice and Bob, and > > two proxy/registrars A and B, both of which think they are the only > > proxy/registrars for "example.com". Therefore, example.com is > > partitioned. > > > > Alice registers at A, Bob registers at B. Alice can't call Bob, > > because the only proxy/registrar she knows about doesn't know Bob > > exists. Same for Bob, who can't call Alice. > > > > Sure, for the two-proxy problem, one proxy could always assume that > > any name it doesn't recognize is at the other proxy, but this > > quickly breaks down as the number of proxies increases. To make > > this work in the general n-partition case, we'd need a way for the > > proxies to discover each other and learn which part of the > > namespace is being held by each other. Further, we need to keep > > track of this topology as the connections between overlasy shift. > > Basically, we're talking dynamic routing on a per-name, not per- > > domain, basis. Note that conventional SIP doesn't have anything > > like this today, but good-old spanning tree ethernet does, and we > > understand the limits of that pretty clearly, and it's not reaching > > the kind of size/space/time constraints we're dealing with in large > > overlays. > > > > So unless you can convince folks that we're really prepared to > > develop a unified theory of per-name SIP dynamic routing that > > encompasses both conventional and client-server SIP, I strongly > > suggest we restrict ourselves to the cases in which namespaces are > > not partitioned and we can use RFC 3263 between namespaces. > > > > -- > > Dean > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 16:38:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyw4t-00021e-Tg; Thu, 14 Jun 2007 16:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyw4s-00021Z-DB for p2psip@ietf.org; Thu, 14 Jun 2007 16:37:58 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyw4r-0004X3-45 for p2psip@ietf.org; Thu, 14 Jun 2007 16:37:58 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5EKbprk012915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Jun 2007 16:37:52 -0400 (EDT) Date: Thu, 14 Jun 2007 16:37:51 -0400 (EDT) From: Salman Abdul Baset To: Dean Willis Subject: Re: [P2PSIP] Acitve/Passive vs Contributing/Non-contributing In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org My concern is that can we differentiate types of peers when the resource definition is itself vague? Isn't it the case that a peer which *only* performs routing contributes some of its resources towards routing and overlay maintenance? Perhaps, you want to classify peers offering services in addition to routing and maintenance as contributing peers. The term 'contributing peer' is vague because what really a node is looking for is a peer offering a certain service such as storage or NAT traversal. -salman On Thu, 14 Jun 2007, Dean Willis wrote: > > It's been suggested we might classify the peers that contribute resources as > "contributing peers", instead of "active peers", and the ones that don't as > "non-contributing peers", rather than "passive peers." > > On further reflection, I think I like this nomenclature better than the > previous proposal. > > And it avoids a vocabulary conflict with a soon-to-be published draft that > somebody else brought to my attention. > > So does this sound okay to you folks for now? > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 16:57:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywNh-0004df-NH; Thu, 14 Jun 2007 16:57:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywNf-0004cQ-VZ for p2psip@ietf.org; Thu, 14 Jun 2007 16:57:23 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HywNe-0008AU-LA for p2psip@ietf.org; Thu, 14 Jun 2007 16:57:23 -0400 Received: by py-out-1112.google.com with SMTP id a25so1924150pyi for ; Thu, 14 Jun 2007 13:57:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=QtWQ7IW2DoY/apqxngJX7YhwoaC2Se98q3Ef8oSOdA0/E8cKv2gCeWraojdBpLvTic6ZcWZ58y0QplHSn01/3CEA/S24Dd2SgQhgoXaThQ+24DhJYwwK9aJRA9aKxNF8Z4ymbYJBlLjOnxyccY6GlwTRtJ5utAeh/mJAh7HXfFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Ekt5kRIgwHqoo/t6HBEA67N89isMGtlLkrWucEillmkcmMRvVA7Fd9XmaHCl0/JW7/jrbkpJzRbIZ3f91IxbIjNuG8x24F575EQ7lhfCGbaEY3pKz76DnpwNRmiRMBoXyLhmKwQ96LPSRJmm7ZWsVw7jBeMGG0MUEMLWCzTQSMU= Received: by 10.35.106.15 with SMTP id i15mr3861791pym.1181854640967; Thu, 14 Jun 2007 13:57:20 -0700 (PDT) Received: by 10.35.65.4 with HTTP; Thu, 14 Jun 2007 13:57:20 -0700 (PDT) Message-ID: <4d4304a00706141357q4834cf1bs9f697262abec8d44@mail.gmail.com> Date: Thu, 14 Jun 2007 16:57:20 -0400 From: "David A. Bryan" To: "Salman Abdul Baset" Subject: Re: [P2PSIP] Acitve/Passive vs Contributing/Non-contributing In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 1498c7b7561bf8a6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I want to agree with Bill here. I think if it doesn't route and doesn't have an ID, it just isn't a peer. Personally, I'd prefer we left the concepts draft the way it was. I don't see the need to change clients to "non-participating peers", and really think it is just going to add confusion. David On 6/14/07, Salman Abdul Baset wrote: > My concern is that can we differentiate types of peers when the resource > definition is itself vague? Isn't it the case that a peer which *only* > performs routing contributes some of its resources towards routing and > overlay maintenance? > > Perhaps, you want to classify peers offering services in addition to > routing and maintenance as contributing peers. The term 'contributing > peer' is vague because what really a node is looking for is a peer > offering a certain service such as storage or NAT traversal. > > -salman > > > On Thu, 14 Jun 2007, Dean Willis wrote: > > > > > It's been suggested we might classify the peers that contribute resources as > > "contributing peers", instead of "active peers", and the ones that don't as > > "non-contributing peers", rather than "passive peers." > > > > On further reflection, I think I like this nomenclature better than the > > previous proposal. > > > > And it avoids a vocabulary conflict with a soon-to-be published draft that > > somebody else brought to my attention. > > > > So does this sound okay to you folks for now? > > > > -- > > Dean > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 17:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywhN-0006np-5T; Thu, 14 Jun 2007 17:17:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HywhL-0006nW-Hf for p2psip@ietf.org; Thu, 14 Jun 2007 17:17:43 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HywhK-0007GU-7P for p2psip@ietf.org; Thu, 14 Jun 2007 17:17:43 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5ELHaGv019795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 17:17:40 -0400 (EDT) In-Reply-To: <09b301c7aec2$825addb0$9501a8c0@cis.neustar.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><67D01DEA-27DA-4F93-ACF6-3A0551427944@softarmor.com> <4179B0D1-1A06-4D52-99A1-F6CA95B4C1A1@cs.columbia.edu> <09b301c7aec2$825addb0$9501a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <289790EB-99B9-4302-8CDD-A36B89418798@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 17:18:24 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian, If I'm understanding you correctly, the difference between what you wrote and what I proposed is minor. You seem to propose ONE "wild card" (i.e., non-DNS) overlay that is contacted after the normal 3263 mechanism fails. I didn't specify the number of such overlays and I'm not sure that it needs to be exactly one and no more, but that seems to be more of a matter than degree than principle. (Practically speaking, I expect the number of such 'disconnected' overlays that are of interest to a client to be very small, as there's little gain in having a lot of them; they could occur "naturally" when mobile networks split and merge.) Henning On Jun 14, 2007, at 4:27 PM, Brian Rosen wrote: > Okay, let's talk about those environments. I like them, and want > p2psip to > work in them. > > I assume we all are expecting that we don't have DNS. > > I assume that we have the IP Address (not a domain name) of one or > more > bootstrap peers. > > I assume we have credentials for the overlay, and furthermore that > each peer > can validate those credentials without needing some other service > > I assume we have our own IP address, and an AoR, which for this > purpose is > just a string we can hash. > > Where is the problem? Even if we started at 3263, that fails. We > go to the > bootstrap server, present our credentials and get admitted into the > overlay. > We try to connect to our buddy, and if he is on the overlay, we > find him. > > What won't work without a lot of assumptions we don't want to make > is proxy > peers, and inter-overlay routing, and other stuff. But p2p will > work, as > long as the credentials are accepted in the absence of any kind of > service > to assist in validating them. > > I still think in more benign environments, we want more explicit > declarations of what overlays a domain supports, and not a "try > them all and > see what happens" mechanism. > > > Getting back to your message, I don't think it's necessarily a very > small > number. Just consider that I CURRENTLY have 7 or 8 active IM > accounts. If > they were all peer to peer, I could be broadcasting your AoR in all > of them > trying to find you. That seems silly, and not scaleable, because > some of > those overlays are very big, and I don't want lots of "try them all" > messages zinging around. > > Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 17:58:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxL6-0008L0-72; Thu, 14 Jun 2007 17:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyxL5-0008Kr-4E for p2psip@ietf.org; Thu, 14 Jun 2007 17:58:47 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyxL3-00068o-QH for p2psip@ietf.org; Thu, 14 Jun 2007 17:58:47 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HyxKt-0006wX-5J; Thu, 14 Jun 2007 16:58:35 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><67D01DEA-27DA-4F93-ACF6-3A0551427944@softarmor.com> <4179B0D1-1A06-4D52-99A1-F6CA95B4C1A1@cs.columbia.edu> <09b301c7aec2$825addb0$9501a8c0@cis.neustar.com> <289790EB-99B9-4302-8CDD-A36B89418798@cs.columbia.edu> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 17:58:42 -0400 Message-ID: <09cd01c7aecf$2db83a20$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <289790EB-99B9-4302-8CDD-A36B89418798@cs.columbia.edu> Thread-Index: AceuyWuVB8bTlEQ0RMaMYZ+fkVMyWQABRpIw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org If you have multiple sets of bootstrap servers, and multiple sets of credentials for multiple overlays, you can join as many as you like. I think that might be dozens for lots of users. I think the question is, are you broadcasting in all of them to look for a hit when contacting someone, or is there a more deterministic algorithm? I probably would not object to a broadcast in the case of an ad hoc network with no DNS. In that environment, while you may have several overlays you could join, there is likely to be only a couple you have addressability to in that environment. I would prefer to not use that in a more connected environment. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Thursday, June 14, 2007 5:18 PM > To: Brian Rosen > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > Brian, > > If I'm understanding you correctly, the difference between what you > wrote and what I proposed is minor. You seem to propose ONE "wild > card" (i.e., non-DNS) overlay that is contacted after the normal 3263 > mechanism fails. I didn't specify the number of such overlays and I'm > not sure that it needs to be exactly one and no more, but that seems > to be more of a matter than degree than principle. (Practically > speaking, I expect the number of such 'disconnected' overlays that > are of interest to a client to be very small, as there's little gain > in having a lot of them; they could occur "naturally" when mobile > networks split and merge.) > > Henning > > On Jun 14, 2007, at 4:27 PM, Brian Rosen wrote: > > > Okay, let's talk about those environments. I like them, and want > > p2psip to > > work in them. > > > > I assume we all are expecting that we don't have DNS. > > > > I assume that we have the IP Address (not a domain name) of one or > > more > > bootstrap peers. > > > > I assume we have credentials for the overlay, and furthermore that > > each peer > > can validate those credentials without needing some other service > > > > I assume we have our own IP address, and an AoR, which for this > > purpose is > > just a string we can hash. > > > > Where is the problem? Even if we started at 3263, that fails. We > > go to the > > bootstrap server, present our credentials and get admitted into the > > overlay. > > We try to connect to our buddy, and if he is on the overlay, we > > find him. > > > > What won't work without a lot of assumptions we don't want to make > > is proxy > > peers, and inter-overlay routing, and other stuff. But p2p will > > work, as > > long as the credentials are accepted in the absence of any kind of > > service > > to assist in validating them. > > > > I still think in more benign environments, we want more explicit > > declarations of what overlays a domain supports, and not a "try > > them all and > > see what happens" mechanism. > > > > > > Getting back to your message, I don't think it's necessarily a very > > small > > number. Just consider that I CURRENTLY have 7 or 8 active IM > > accounts. If > > they were all peer to peer, I could be broadcasting your AoR in all > > of them > > trying to find you. That seems silly, and not scaleable, because > > some of > > those overlays are very big, and I don't want lots of "try them all" > > messages zinging around. > > > > Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 14 19:47:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyz2Q-0005dz-8i; Thu, 14 Jun 2007 19:47:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyz2O-0005Us-QD for p2psip@ietf.org; Thu, 14 Jun 2007 19:47:36 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyz2N-0002Iy-Hm for p2psip@ietf.org; Thu, 14 Jun 2007 19:47:36 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5ENlNZ4012891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 14 Jun 2007 19:47:27 -0400 (EDT) In-Reply-To: <09cd01c7aecf$2db83a20$9501a8c0@cis.neustar.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><67D01DEA-27DA-4F93-ACF6-3A0551427944@softarmor.com> <4179B0D1-1A06-4D52-99A1-F6CA95B4C1A1@cs.columbia.edu> <09b301c7aec2$825addb0$9501a8c0@cis.neustar.com> <289790EB-99B9-4302-8CDD-A36B89418798@cs.columbia.edu> <09cd01c7aecf$2db83a20$9501a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B877EB0-129B-4A9B-9697-92830AB1F7ED@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Thu, 14 Jun 2007 19:47:16 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 14, 2007, at 5:58 PM, Brian Rosen wrote: > If you have multiple sets of bootstrap servers, and multiple sets of > credentials for multiple overlays, you can join as many as you > like. I > think that might be dozens for lots of users. > > I think the question is, are you broadcasting in all of them to > look for a > hit when contacting someone, or is there a more deterministic > algorithm? > You clearly don't want to have to go hunting around in some random collection of overlays, so the algorithm should be fairly deterministic. > I probably would not object to a broadcast in the case of an ad hoc > network > with no DNS. In that environment, while you may have several > overlays you > could join, there is likely to be only a couple you have > addressability to > in that environment. I would prefer to not use that in a more > connected > environment. I generally agree, but would add that a UA may not know which environment it finds itself in until it tests reachability. We presumably don't want to manually configure UAs. I think a reasonable algorithm is that a node tries 3263, discovers (a typically small) number of overlays and searches those, with the notion that all participants within the disconnected network will be using the same one or two. I don't see the need to go into great amounts of details for the initial discussion, but we shouldn't preclude this mode of operation. Henning > > Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 02:07:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4y1-0001wB-TG; Fri, 15 Jun 2007 02:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz4y0-0001vB-K0 for p2psip@ietf.org; Fri, 15 Jun 2007 02:07:28 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz4xz-0006qM-T4 for p2psip@ietf.org; Fri, 15 Jun 2007 02:07:28 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJN00735YAXR5@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 14:06:33 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJN005NRYAW83@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 14:06:33 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJN00I2CYASUX@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 14:06:32 +0800 (CST) Date: Fri, 15 Jun 2007 14:06:28 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Concepts document: proposal for active/passivepeerterminology In-reply-to: To: 'Philip Matthews' , =?ISO-8859-1?Q?'Gustavo_Garc=EDa'?= Message-id: <001e01c7af13$506627a0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AceulYIi0+QaIxhQQ9avemL5tLDOxAAfNuww X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Thursday, June 14, 2007 11:06 PM > To: Gustavo Garc=EDa > Cc: 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Concepts document: proposal for > active/passivepeerterminology >=20 >=20 > On 14-Jun-07, at 10:55 , Gustavo Garc=EDa wrote: >=20 > >> (2) As I have said before, I really, really want to see good = examples > >> of why we want to make this distinctions between types of peers (or > >> whatever we call them). Yes, we could design a system that allows = for > >> great flexibility in types of peers allowed, but I want to first > >> understand why this flexibility is useful. > > > > IMHO we only need to make the distinction between nodes which > > participate in > > the location of resources (participate in the DHT structure) and > > those who > > only make use of the resource location functions (sending PUT/GET > > requests). > > > > We need to make this distinction because Peers need a PeerID while = for > > Clients this is not clear, because the protocol primitives > > implemented in > > Peers are different from those in Clients, because bootstrapping/ > > joining > > procedures are different (clients don't need to be placed in the DHT > > structure) and because probably they also have different security > > requirements (it is more critical to authorize a peer than a = client). >=20 > I agree that clients might not need peer IDs, and might have a > different protocol stack, > but why do you want clients? What motives you to write additional > software to support > the concept of a client? Have we gotten rough consensus that we will use SIP protocol to = transport Peer protocol message. It is not the case, client may exist and client protocol may exist.=20 For SIP UA, the SIP message should be transported by the peers in the overlay which would modify the message according to the SIP protocol. If some peers on the path don't speak SIP, the message would be discarded = by these peers because of not speaking SIP. For example, there are some STUN/TURN servers which do not speak SIP and be willing to be a peer in = the overlay.=20 Am I missing something?=20 Regards JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 02:13:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz53o-0006F1-2F; Fri, 15 Jun 2007 02:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz53m-0006Ew-KN for p2psip@ietf.org; Fri, 15 Jun 2007 02:13:26 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz53l-0007dc-CV for p2psip@ietf.org; Fri, 15 Jun 2007 02:13:26 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hz52e-0002Gl-BC; Fri, 15 Jun 2007 01:12:16 -0500 Message-ID: <46722E6B.9060409@softarmor.com> Date: Fri, 15 Jun 2007 01:15:07 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Bill Mccormick Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Avshalom Houri , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bill Mccormick wrote: > It sounds like Dean is saying: > > an active peer is a fully participating node in the DHT. > a passive peer can access the DHT "natively" but is not actually a DHT node > a client is just a SIP UA client and it treats the DHT (more or less) as a > proxy server. > > Is this correct? That's certainly a reasonable way to look at it. I'm not sure that this means that the passive peer is not a DHT node -- I suspect that's an issue of the DHT protocol, not of the concept. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 02:19:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5A6-0005DV-PE; Fri, 15 Jun 2007 02:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5A5-0005DN-Dh for p2psip@ietf.org; Fri, 15 Jun 2007 02:19:57 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5A3-0000My-TI for p2psip@ietf.org; Fri, 15 Jun 2007 02:19:57 -0400 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 <0JJN006IMYVX80@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 14:19:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJN00DHGYVWCP@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 14:19:09 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJN00IA1YVSUX@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 14:19:08 +0800 (CST) Date: Fri, 15 Jun 2007 14:19:04 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Acitve/Passive vs Contributing/Non-contributing In-reply-to: <4d4304a00706141357q4834cf1bs9f697262abec8d44@mail.gmail.com> To: "'David A. Bryan'" Message-id: <001f01c7af15$12b711b0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AceuxqGF37ptSEQIR3mdWPJcnMfM+AATQv1A X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, David: Yes, I agree with David that a Peer must provide routing and storage service, otherwise it will break the existing DHT algorithms. -- Jiang XingFeng > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > Sent: Friday, June 15, 2007 4:57 AM > To: Salman Abdul Baset > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Acitve/Passive vs Contributing/Non-contributing > > I want to agree with Bill here. I think if it doesn't route and > doesn't have an ID, it just isn't a peer. > > Personally, I'd prefer we left the concepts draft the way it was. I > don't see the need to change clients to "non-participating peers", and > really think it is just going to add confusion. > > David > > On 6/14/07, Salman Abdul Baset wrote: > > My concern is that can we differentiate types of peers when the resource > > definition is itself vague? Isn't it the case that a peer which *only* > > performs routing contributes some of its resources towards routing and > > overlay maintenance? > > > > Perhaps, you want to classify peers offering services in addition to > > routing and maintenance as contributing peers. The term 'contributing > > peer' is vague because what really a node is looking for is a peer > > offering a certain service such as storage or NAT traversal. > > > > -salman > > > > > > On Thu, 14 Jun 2007, Dean Willis wrote: > > > > > > > > It's been suggested we might classify the peers that contribute resources as > > > "contributing peers", instead of "active peers", and the ones that don't as > > > "non-contributing peers", rather than "passive peers." > > > > > > On further reflection, I think I like this nomenclature better than the > > > previous proposal. > > > > > > And it avoids a vocabulary conflict with a soon-to-be published draft that > > > somebody else brought to my attention. > > > > > > So does this sound okay to you folks for now? > > > > > > -- > > > Dean > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 02:20:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5Ak-0005JB-4M; Fri, 15 Jun 2007 02:20:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5Aj-0005J6-A6 for p2psip@ietf.org; Fri, 15 Jun 2007 02:20:37 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5Ai-0000cH-UT for p2psip@ietf.org; Fri, 15 Jun 2007 02:20:37 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hz59o-0002Hp-EU; Fri, 15 Jun 2007 01:19:40 -0500 Message-ID: <46723027.9010902@softarmor.com> Date: Fri, 15 Jun 2007 01:22:31 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "David A. Bryan" Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> In-Reply-To: <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Avshalom Houri , P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so, for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something > is a peer if it isn't doing anything other than talking to someone > and making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes? > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service. > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the peer. > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 02:22:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5Cv-00067j-U0; Fri, 15 Jun 2007 02:22:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5Ct-000674-QD for p2psip@ietf.org; Fri, 15 Jun 2007 02:22:51 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5Cs-0001kM-J7 for p2psip@ietf.org; Fri, 15 Jun 2007 02:22:51 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hz5Cm-0002IL-W4; Fri, 15 Jun 2007 01:22:45 -0500 Message-ID: <467230E0.90306@softarmor.com> Date: Fri, 15 Jun 2007 01:25:36 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> In-Reply-To: <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Spencer Dawkins wrote: > [ Hum indicated yes. > Those that want a P2PSIP Client distinct from a normal SIP client need to > get together and work on use cases. ] > > So - is this actually happening? Or are we trying to come up with a name > for a concept we don't need/don't know WHY we need? > > Just curious... the 00 draft cutoff being Monday, July 2, and all that. > Well, that's part of what I'm working on. So far, I'm now leaning towards "client" being a modality of peer operation, meaning a peer that can't afford to contribute resources "right now", rather than being an entirely different thing from a peer. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 02:28:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5IW-0008WT-Vr; Fri, 15 Jun 2007 02:28:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5IW-0008WO-3m for p2psip@ietf.org; Fri, 15 Jun 2007 02:28:40 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5IU-0003JU-SL for p2psip@ietf.org; Fri, 15 Jun 2007 02:28:40 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Hz5HB-0002Iq-Sr; Fri, 15 Jun 2007 01:27:18 -0500 Message-ID: <467231F1.4080605@softarmor.com> Date: Fri, 15 Jun 2007 01:30:09 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> In-Reply-To: <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian Rosen wrote: > Can we just forget clients for a sec? Alice has a full peer implementation > in the example.com domain. What is Alice's AoR (what is the scheme for > example? How does another peer resolve that AoR to the protocol, IP > address, etc. needed to create a session with Alice? Assume that peer is > very well connected and lives on multiple overlays, as well as several > direct SIP C/S domains. > > I mean, if it's sip:alice@example.com, then the peer is going to do an SRV > lookup at example.com for a sip server and try C/S, right? RFC3263 > > Are you expecting that to fail? In my current worldview, if the peer knows it is participating in an overlay that addresses the namespace "example.com", the peer looks up Alice in its overlay. If not (or perhaps if the overlay lookup fails) it fails, then the peer either does a 3263 resolution itself, or finds a peer node offering "proxy service" to do the 3263 resolution for it. I believe Henning is implying a model where if the "local" overlay fails, we then repeat the lookup operation using either the "meta" overlay, or by asking a peer that does "meata proxy" to do it for us. Said "meta" lookup might then revert to RFC 3263. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 02:55:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5ib-0001rh-6F; Fri, 15 Jun 2007 02:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz5i0-0001Bd-Ab for p2psip@ietf.org; Fri, 15 Jun 2007 02:55:00 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz5fU-0007gP-Rr for p2psip@ietf.org; Fri, 15 Jun 2007 02:52:27 -0400 X-ClientAddr: 192.36.80.8 Received: from [127.0.0.1] (pwlan.lfv.se [192.36.80.8] (may be forged)) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5F6XDHg022608; Fri, 15 Jun 2007 08:33:13 +0200 Message-ID: <4672371D.9040609@teigre.com> Date: Fri, 15 Jun 2007 08:52:13 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Enrico Marocco Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> <4671623C.8030701@telecomitalia.it> In-Reply-To: <4671623C.8030701@telecomitalia.it> X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.5 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2122314874==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============2122314874== Content-Type: multipart/alternative; boundary="------------010401090007090902030907" This is a multi-part message in MIME format. --------------010401090007090902030907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm struggling a bit with an underlying issue that seems to only be implicitly addressed (or I confuse things up). To me it looks like people are talking about two different types of clients without not always specifying explicitly when they talk about which. I think all agree that the "client" does not have full peer capabilities. However, such a client can be aware of the overlay (as in routing or having some storage capability) and as such participate in the overlay as a "lesser peer" or it can be ignorant of the overlay, except that it knows that some entity offers GET/PUT. So, it needs to have a full peer, which acts as a "gateway" into the overlay. So, a first decision would be to decide whether a "lesser peer" should be supported or if only access through a "gateway" should be allowed. A second decision would be whether SIP should be used for communication between client and "gateway peer" or some other client protocol. g-) Enrico Marocco wrote: > Spencer Dawkins wrote: >> So - is this actually happening? Or are we trying to come up with a >> name for a concept we don't need/don't know WHY we need? > > As far as I recall, the only credible use case which justifies the > existence of the "client" concept is that where a "non contributing" > node wants to store/retrieve in the overlay something which can't be > encoded in SIP (REGISTER?) messages (e.g. public keys, VM records...). > Since such functionalities are not required to realize what the group > has been chartered for (are they?) and perhaps they could be used in > centralized environments too, well... I personally hope that it _is_ > happening and that we get rid of "clients" before the next meeting. > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --------------010401090007090902030907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm struggling a bit with an underlying issue that seems to only be implicitly addressed (or I confuse things up).  To me it looks like people are talking about two different types of clients without not always specifying explicitly when they talk about which. I think all agree that the "client" does not have full peer capabilities. However, such a client can be aware of the overlay (as in routing or having some storage capability) and as such participate in the overlay as a "lesser peer" or it can be ignorant of the overlay, except that it knows that some entity offers GET/PUT. So, it needs to have a full peer, which acts as a "gateway" into the overlay.

So, a first decision would be to decide whether a "lesser peer" should be supported or if only access through a "gateway" should be allowed. A second decision would be whether SIP should be used for communication between client and "gateway peer" or some other client protocol.
g-)

Enrico Marocco wrote:
Spencer Dawkins wrote:
So - is this actually happening? Or are we trying to come up with a name for a concept we don't need/don't know WHY we need?

As far as I recall, the only credible use case which justifies the existence of the "client" concept is that where a "non contributing" node wants to store/retrieve in the overlay something which can't be encoded in SIP (REGISTER?) messages (e.g. public keys, VM records...).
Since such functionalities are not required to realize what the group has been chartered for (are they?) and perhaps they could be used in centralized environments too, well... I personally hope that it _is_ happening and that we get rid of "clients" before the next meeting. 


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--------------010401090007090902030907-- --===============2122314874== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2122314874==-- From p2psip-bounces@ietf.org Fri Jun 15 04:05:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6nt-0001BP-S3; Fri, 15 Jun 2007 04:05:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz6nr-00016v-NJ for p2psip@ietf.org; Fri, 15 Jun 2007 04:05:07 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz6np-00045d-Vo for p2psip@ietf.org; Fri, 15 Jun 2007 04:05:07 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5F8434L016762; Fri, 15 Jun 2007 11:04:19 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:04:06 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:04:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts document: proposalfor active/passivepeerterminology Date: Fri, 15 Jun 2007 11:06:21 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F048C3D0C@esebe102.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts document: proposalfor active/passivepeerterminology Thread-Index: AceuriWOwJGOQtuuQA616edqiPorKgAdVZOQ References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca><117301c7ae95$b5379f70$6901a8c0@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> From: To: , X-OriginalArrivalTime: 15 Jun 2007 08:04:06.0460 (UTC) FILETIME=[BEE2CFC0:01C7AF23] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I fully agree with Salman. Marcin=20 >-----Original Message----- >From: ext Salman Abdul Baset [mailto:salman@cs.columbia.edu]=20 >Sent: 14 June, 2007 21:02 >To: Henry Sinnreich >Cc: P2PSIP Mailing List >Subject: RE: [P2PSIP] Concepts document: proposalfor=20 >active/passivepeerterminology > >Further elaborating the point by Henry/Marcin on the usage=20 >'clients' and the variety of 'peers': > >1) A device's processing/connection capabilites are "limited"=20 >and particpating in a full blown DHT is a big hit on its=20 >resources such as limited battery-life or bandwidth. > >2) The nodes are behind a "restricted NAT/firewall" and it=20 >might be feasible to leave them out of a DHT than to adopt the=20 >best NAT traversal solution that allows these nodes to fully=20 >participate in the DHT. Skype adopts this solution. > >3) The concept of a 'client' easily lends itself to the=20 >creation of hierachical overlays. > > >Peers perform the basic routing function but they can also=20 >have different=20 >capabilities. For concept draft purposes, I don't think we=20 >need to further=20 >disambiguate the peer concept based on the capabilities such=20 >as storage,=20 >CPU or b/w; that should be left to the overlay designer. > >-salman > >On Thu, 14 Jun 2007, Henry Sinnreich wrote: > >> At this point, I would like to share some text edited by Marcin >> Matuszewski for a requirements I-D for the P2P SIP that we are still >> working on: >> .... >> One assumption of DHT networks on the Internet could be that=20 >the network >> nodes are homogenous, and they have enough processing power=20 >and memory >> to run DHT networks without any limits. This assumption does not hold >> however if we consider mobile devices such as mobile phones, PDAs, or >> WiFi phones. Mobile devices are heterogeneous. Low-end=20 >devices may have >> a little memory, a slow CPU and may not support fast packet radio >> interfaces. On the other hand, high-end devices may have=20 >significantly >> higher capabilities: Fast radio interfaces, more memory and=20 >faster CPU >> then they their less advanced counterparts. >> >>> From this reason we can classify network nodes into two categories: >> Mainly those that have enough CPU power, memory and fast network >> interface to run P2PSIP peer protocol and those that may not=20 >have enough >> capabilities to become P2PSIP peers. >> >> Besides, if we consider the issue of NAT traversal, a very powerful >> mobile device can be behind a restrictive NAT. This may require the >> device to establish a TCP or TLS connection towards a TURN server. If >> the connection has to be maintained for a long period, it=20 >may drain the >> device battery. From these reasons, not all battery powered devices >> though having enough capabilities to run the peer protocol will still >> not be able to become P2PSIP peers. >> >> Essentially, any DHT overlay network can support two basic=20 >operations: >> PUT and GET. In the P2PSIP overlay a PUT operation is used to insert, >> modify, or delete data in the overlay,such as user or=20 >resource records. >> A GET operation is used to retrieve data stored in the=20 >overlay. Clients >> should be able to store, modify, delete and retrieve user=20 >and resource >> records from the overlay; in the P2P language they must=20 >support PUT and >> GET operations. >> .... >> Note again that clients do not participate in the maintenance of the >> DHT, but may use the DHT for certain functions, such as storage and >> retrieval of data. >> >> Henry >> >> -----Original Message----- >> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >> Sent: Thursday, June 14, 2007 5:07 PM >> To: P2PSIP Mailing List >> Subject: Re: [P2PSIP] Concepts document: proposal for >> active/passivepeerterminology >> >> I want to agree with Philip, and provide a wake-up call... >> >>> (2) As I have said before, I really, really want to see=20 >good examples >> of >>> why we want to make this distinctions between types of peers (or >> whatever >>> we call them). Yes, we could design a system that allows for great >>> flexibility in types of peers allowed, but I want to first =20 >understand >> why >>> this flexibility is useful. >>> >>> To be concrete: I suggest having a section in the document that >> discusses >>> these possibilities (and any others that people can think =20 >of), but I >>> suggest holding off in giving them names and elevating =20 >them to formal >> >>> "concepts" in the document until someone argues why one of these is >> of >>> particular interest. >> >>> From the meeting minutes at >> http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html... >> >> P2PSIP Client Discussion, Spencer Dawkins >> >> What are Clients? Not garden variety SIP UACs, nor the equivalent of >> "peers." >> >> Issue: Clients as storage nodes. No credible use case so=20 >far; deferred. >> >> [ Discussion ensued at mic. >> >> Philip: Why do we need P2PSIP clients? The answer will=20 >drive whether >> or >> not we use them. >> >> Brian Rosen (as individual): I don't understand P2PSIP clients. We >> need >> to get rid of it and focus on normal SIP clients. >> >> Philip: Those that want P2PSIP Clients need to come up with=20 >a good use >> case by Chicago IETF. If they do not come up by then, the P2PSIP >> Clients >> go away. ] >> >> Hum - Should the wg work on the normal garden variety SIP UA=20 >connected >> to >> the DHT via some box (a SIP proxy coupled to a peer)? >> >> [ Hum indicated yes. >> Those that want a P2PSIP Client distinct from a normal SIP=20 >client need >> to >> get together and work on use cases. ] >> >> So - is this actually happening? Or are we trying to come up=20 >with a name >> for >> a concept we don't need/don't know WHY we need? >> >> Just curious... the 00 draft cutoff being Monday, July 2,=20 >and all that. >> >> Spencer >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 04:25:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz77F-0008TO-Ib; Fri, 15 Jun 2007 04:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz77E-0008TG-AG for p2psip@ietf.org; Fri, 15 Jun 2007 04:25:08 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz77D-00018J-F5 for p2psip@ietf.org; Fri, 15 Jun 2007 04:25:08 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5F8OrSd029209; Fri, 15 Jun 2007 11:25:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:24:53 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:24:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts document: proposal foractive/passivepeerterminology Date: Fri, 15 Jun 2007 11:27:08 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> In-Reply-To: <001e01c7af13$506627a0$6905a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts document: proposal foractive/passivepeerterminology Thread-Index: AceulYIi0+QaIxhQQ9avemL5tLDOxAAfNuwwAAR6kPA= References: <001e01c7af13$506627a0$6905a40a@china.huawei.com> From: To: , , X-OriginalArrivalTime: 15 Jun 2007 08:24:52.0983 (UTC) FILETIME=[A5DF2070:01C7AF26] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Let's assume for a while that we have STUN/TURN servers that are = external to the overlay but may assist peers/SIP UA in NAT traversal. If = we get rid of the client protocol and clients how those servers can = register to the DHT and advertise their services? Are we planning to = force all of network entities to implement a SIP stack? Marcin=20 >-----Original Message----- >From: ext JiangXingFeng [mailto:jiang.x.f@huawei.com]=20 >Sent: 15 June, 2007 09:06 >To: 'Philip Matthews'; 'Gustavo Garc=EDa' >Cc: 'P2PSIP Mailing List' >Subject: RE: [P2PSIP] Concepts document: proposal=20 >foractive/passivepeerterminology > >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews@magma.ca] >> Sent: Thursday, June 14, 2007 11:06 PM >> To: Gustavo Garc=EDa >> Cc: 'P2PSIP Mailing List' >> Subject: Re: [P2PSIP] Concepts document: proposal for=20 >> active/passivepeerterminology >>=20 >>=20 >> On 14-Jun-07, at 10:55 , Gustavo Garc=EDa wrote: >>=20 >> >> (2) As I have said before, I really, really want to see good=20 >> >> examples of why we want to make this distinctions between=20 >types of=20 >> >> peers (or whatever we call them). Yes, we could design a system=20 >> >> that allows for great flexibility in types of peers=20 >allowed, but I=20 >> >> want to first understand why this flexibility is useful. >> > >> > IMHO we only need to make the distinction between nodes which=20 >> > participate in the location of resources (participate in the DHT=20 >> > structure) and those who only make use of the resource location=20 >> > functions (sending PUT/GET requests). >> > >> > We need to make this distinction because Peers need a PeerID while=20 >> > for Clients this is not clear, because the protocol primitives=20 >> > implemented in Peers are different from those in Clients, because=20 >> > bootstrapping/ joining procedures are different (clients=20 >don't need=20 >> > to be placed in the DHT >> > structure) and because probably they also have different security=20 >> > requirements (it is more critical to authorize a peer than=20 >a client). >>=20 >> I agree that clients might not need peer IDs, and might have a=20 >> different protocol stack, but why do you want clients? What motives=20 >> you to write additional software to support the concept of a client? > >Have we gotten rough consensus that we will use SIP protocol=20 >to transport Peer protocol message. It is not the case, client=20 >may exist and client protocol may exist.=20 >For SIP UA, the SIP message should be transported by the peers=20 >in the overlay which would modify the message according to the=20 >SIP protocol. If some peers on the path don't speak SIP, the=20 >message would be discarded by these peers because of not=20 >speaking SIP. For example, there are some STUN/TURN servers=20 >which do not speak SIP and be willing to be a peer in the overlay.=20 > >Am I missing something?=20 > >Regards >JiangXingFeng > > > > > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 04:32:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7EO-0000sC-4R; Fri, 15 Jun 2007 04:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7EN-0000s7-FE for p2psip@ietf.org; Fri, 15 Jun 2007 04:32:31 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz7EM-0002mc-5k for p2psip@ietf.org; Fri, 15 Jun 2007 04:32:31 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hz7EL-0004fW-2g; Fri, 15 Jun 2007 04:32:29 -0400 In-Reply-To: <059801c7ae9a$03f5b760$0be12620$@es> References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <057d01c7ae94$0f03f960$2d0bec20$@es> <059801c7ae9a$03f5b760$0be12620$@es> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <56F8ED43-FBD9-49C1-8CEF-74CEBE6BD67A@magma.ca> Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology Date: Fri, 15 Jun 2007 04:32:30 -0400 To: =?ISO-8859-1?Q?Gustavo_Garc=EDa?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 14-Jun-07, at 11:38 , Gustavo Garc=EDa wrote: >> >> I agree that clients might not need peer IDs, and might have a >> different protocol stack, >> but why do you want clients? What motives you to write additional >> software to support >> the concept of a client? > > I have a messenger like application in my mobile phone, and I don't =20= > want to > participate in the DHT to save the battery life. I could be a =20 > "traditional" > SIP UA and register and make calls using SIP proxy services in the =20 > overlay, > but how am I going to retrieve my buddy list stored in the =20 > overlay? Are we > going to have XCAP proxy services in the overlay? Are we going to =20 > have a > proxy service for each new "capability" needed? If you allow me to =20= > be a > P2PSI Client I can put this kind of intelligence in my end device > independently of the services provided in the overlay (I only need =20 > a PUT/GET > interface or something similar). Retrieving your buddy list is something that an ordinary SIP UA also =20 wants to do, so I don't think that P2PSIP should define a different way to do this =20= without a very good reason. I know almost nothing about XCAP, but if that is =20 considered the right way to do this on an ordinary SIP UA, then a P2PSIP peer =20 that is acting as a proxy should support this method of retrieving buddy lists. Hence, I don't see this as an argument for a client protocol that is =20 distinct from what an ordinary SIP UA would implement. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 04:32:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7EV-0000wP-Bj; Fri, 15 Jun 2007 04:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7ET-0000wK-QF for p2psip@ietf.org; Fri, 15 Jun 2007 04:32:37 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz7ET-0002gG-4e for p2psip@ietf.org; Fri, 15 Jun 2007 04:32:37 -0400 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 <0JJO00JPY50SAS@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 16:31:40 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJO00I8I50RWH@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 16:31:40 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJO00EVG50N4U@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 15 Jun 2007 16:31:39 +0800 (CST) Date: Fri, 15 Jun 2007 16:31:35 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Concepts document: proposal foractive/passivepeerterminology In-reply-to: <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> To: marcin.matuszewski@nokia.com, philip_matthews@magma.ca, ggb@tid.es Message-id: <000601c7af27$95f5ae80$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AceulYIi0+QaIxhQQ9avemL5tLDOxAAfNuwwAAR6kPAAALzZoA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Marcin: I fully agree with your point. Regards -- Jiang XingFeng > -----Original Message----- > From: marcin.matuszewski@nokia.com = [mailto:marcin.matuszewski@nokia.com] > Sent: Friday, June 15, 2007 4:27 PM > To: jiang.x.f@huawei.com; philip_matthews@magma.ca; ggb@tid.es > Cc: p2psip@ietf.org; marcin.matuszewski@nokia.com > Subject: RE: [P2PSIP] Concepts document: proposal > foractive/passivepeerterminology >=20 >=20 > Let's assume for a while that we have STUN/TURN servers that are = external to the > overlay but may assist peers/SIP UA in NAT traversal. If we get rid of = the client > protocol and clients how those servers can register to the DHT and advertise their > services? Are we planning to force all of network entities to = implement a SIP stack? >=20 > Marcin >=20 > >-----Original Message----- > >From: ext JiangXingFeng [mailto:jiang.x.f@huawei.com] > >Sent: 15 June, 2007 09:06 > >To: 'Philip Matthews'; 'Gustavo Garc=EDa' > >Cc: 'P2PSIP Mailing List' > >Subject: RE: [P2PSIP] Concepts document: proposal > >foractive/passivepeerterminology > > > >> -----Original Message----- > >> From: Philip Matthews [mailto:philip_matthews@magma.ca] > >> Sent: Thursday, June 14, 2007 11:06 PM > >> To: Gustavo Garc=EDa > >> Cc: 'P2PSIP Mailing List' > >> Subject: Re: [P2PSIP] Concepts document: proposal for > >> active/passivepeerterminology > >> > >> > >> On 14-Jun-07, at 10:55 , Gustavo Garc=EDa wrote: > >> > >> >> (2) As I have said before, I really, really want to see good > >> >> examples of why we want to make this distinctions between > >types of > >> >> peers (or whatever we call them). Yes, we could design a system > >> >> that allows for great flexibility in types of peers > >allowed, but I > >> >> want to first understand why this flexibility is useful. > >> > > >> > IMHO we only need to make the distinction between nodes which > >> > participate in the location of resources (participate in the DHT > >> > structure) and those who only make use of the resource location > >> > functions (sending PUT/GET requests). > >> > > >> > We need to make this distinction because Peers need a PeerID = while > >> > for Clients this is not clear, because the protocol primitives > >> > implemented in Peers are different from those in Clients, because > >> > bootstrapping/ joining procedures are different (clients > >don't need > >> > to be placed in the DHT > >> > structure) and because probably they also have different security > >> > requirements (it is more critical to authorize a peer than > >a client). > >> > >> I agree that clients might not need peer IDs, and might have a > >> different protocol stack, but why do you want clients? What motives > >> you to write additional software to support the concept of a = client? > > > >Have we gotten rough consensus that we will use SIP protocol > >to transport Peer protocol message. It is not the case, client > >may exist and client protocol may exist. > >For SIP UA, the SIP message should be transported by the peers > >in the overlay which would modify the message according to the > >SIP protocol. If some peers on the path don't speak SIP, the > >message would be discarded by these peers because of not > >speaking SIP. For example, there are some STUN/TURN servers > >which do not speak SIP and be willing to be a peer in the overlay. > > > >Am I missing something? > > > >Regards > >JiangXingFeng > > > > > > > > > > > > > >_______________________________________________ > >P2PSIP mailing list > >P2PSIP@ietf.org > >https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 04:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7S1-0003aN-50; Fri, 15 Jun 2007 04:46:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7Rz-0003aI-TB for p2psip@ietf.org; Fri, 15 Jun 2007 04:46:35 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz7Rz-0005Ru-Ei for p2psip@ietf.org; Fri, 15 Jun 2007 04:46:35 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Hz7Ru-0005Rz-2H; Fri, 15 Jun 2007 04:46:31 -0400 In-Reply-To: <3F18E76823C95E4795181D74BAC7664F048C3D0C@esebe102.NOE.Nokia.com> References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca><117301c7ae95$b5379f70$6901a8c0@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> <3F18E76823C95E4795181D74BAC7664F048C3D0C@esebe102.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88FB6BB7-4855-4EA3-B025-A540123F202D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposalfor active/passivepeerterminology Date: Fri, 15 Jun 2007 04:46:31 -0400 To: "marcin.matuszewski@nokia.com> X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org But do you agree with Enrico too that everything Salman wants can be achieved by simply having the mobile node act as an ordinary SIP UA? - Philip On 15-Jun-07, at 04:06 , wrote: > I fully agree with Salman. > > Marcin > >> -----Original Message----- >> From: ext Salman Abdul Baset [mailto:salman@cs.columbia.edu] >> Sent: 14 June, 2007 21:02 >> To: Henry Sinnreich >> Cc: P2PSIP Mailing List >> Subject: RE: [P2PSIP] Concepts document: proposalfor >> active/passivepeerterminology >> >> Further elaborating the point by Henry/Marcin on the usage >> 'clients' and the variety of 'peers': >> >> 1) A device's processing/connection capabilites are "limited" >> and particpating in a full blown DHT is a big hit on its >> resources such as limited battery-life or bandwidth. >> >> 2) The nodes are behind a "restricted NAT/firewall" and it >> might be feasible to leave them out of a DHT than to adopt the >> best NAT traversal solution that allows these nodes to fully >> participate in the DHT. Skype adopts this solution. >> >> 3) The concept of a 'client' easily lends itself to the >> creation of hierachical overlays. >> >> >> Peers perform the basic routing function but they can also >> have different >> capabilities. For concept draft purposes, I don't think we >> need to further >> disambiguate the peer concept based on the capabilities such >> as storage, >> CPU or b/w; that should be left to the overlay designer. >> >> -salman >> >> On Thu, 14 Jun 2007, Henry Sinnreich wrote: >> >>> At this point, I would like to share some text edited by Marcin >>> Matuszewski for a requirements I-D for the P2P SIP that we are still >>> working on: >>> .... >>> One assumption of DHT networks on the Internet could be that >> the network >>> nodes are homogenous, and they have enough processing power >> and memory >>> to run DHT networks without any limits. This assumption does not >>> hold >>> however if we consider mobile devices such as mobile phones, >>> PDAs, or >>> WiFi phones. Mobile devices are heterogeneous. Low-end >> devices may have >>> a little memory, a slow CPU and may not support fast packet radio >>> interfaces. On the other hand, high-end devices may have >> significantly >>> higher capabilities: Fast radio interfaces, more memory and >> faster CPU >>> then they their less advanced counterparts. >>> >>>> From this reason we can classify network nodes into two categories: >>> Mainly those that have enough CPU power, memory and fast network >>> interface to run P2PSIP peer protocol and those that may not >> have enough >>> capabilities to become P2PSIP peers. >>> >>> Besides, if we consider the issue of NAT traversal, a very powerful >>> mobile device can be behind a restrictive NAT. This may require the >>> device to establish a TCP or TLS connection towards a TURN >>> server. If >>> the connection has to be maintained for a long period, it >> may drain the >>> device battery. From these reasons, not all battery powered devices >>> though having enough capabilities to run the peer protocol will >>> still >>> not be able to become P2PSIP peers. >>> >>> Essentially, any DHT overlay network can support two basic >> operations: >>> PUT and GET. In the P2PSIP overlay a PUT operation is used to >>> insert, >>> modify, or delete data in the overlay,such as user or >> resource records. >>> A GET operation is used to retrieve data stored in the >> overlay. Clients >>> should be able to store, modify, delete and retrieve user >> and resource >>> records from the overlay; in the P2P language they must >> support PUT and >>> GET operations. >>> .... >>> Note again that clients do not participate in the maintenance of the >>> DHT, but may use the DHT for certain functions, such as storage and >>> retrieval of data. >>> >>> Henry >>> >>> -----Original Message----- >>> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >>> Sent: Thursday, June 14, 2007 5:07 PM >>> To: P2PSIP Mailing List >>> Subject: Re: [P2PSIP] Concepts document: proposal for >>> active/passivepeerterminology >>> >>> I want to agree with Philip, and provide a wake-up call... >>> >>>> (2) As I have said before, I really, really want to see >> good examples >>> of >>>> why we want to make this distinctions between types of peers (or >>> whatever >>>> we call them). Yes, we could design a system that allows for great >>>> flexibility in types of peers allowed, but I want to first >> understand >>> why >>>> this flexibility is useful. >>>> >>>> To be concrete: I suggest having a section in the document that >>> discusses >>>> these possibilities (and any others that people can think >> of), but I >>>> suggest holding off in giving them names and elevating >> them to formal >>> >>>> "concepts" in the document until someone argues why one of >>>> these is >>> of >>>> particular interest. >>> >>>> From the meeting minutes at >>> http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html... >>> >>> P2PSIP Client Discussion, Spencer Dawkins >>> >>> What are Clients? Not garden variety SIP UACs, nor the >>> equivalent of >>> "peers." >>> >>> Issue: Clients as storage nodes. No credible use case so >> far; deferred. >>> >>> [ Discussion ensued at mic. >>> >>> Philip: Why do we need P2PSIP clients? The answer will >> drive whether >>> or >>> not we use them. >>> >>> Brian Rosen (as individual): I don't understand P2PSIP clients. We >>> need >>> to get rid of it and focus on normal SIP clients. >>> >>> Philip: Those that want P2PSIP Clients need to come up with >> a good use >>> case by Chicago IETF. If they do not come up by then, the P2PSIP >>> Clients >>> go away. ] >>> >>> Hum - Should the wg work on the normal garden variety SIP UA >> connected >>> to >>> the DHT via some box (a SIP proxy coupled to a peer)? >>> >>> [ Hum indicated yes. >>> Those that want a P2PSIP Client distinct from a normal SIP >> client need >>> to >>> get together and work on use cases. ] >>> >>> So - is this actually happening? Or are we trying to come up >> with a name >>> for >>> a concept we don't need/don't know WHY we need? >>> >>> Just curious... the 00 draft cutoff being Monday, July 2, >> and all that. >>> >>> Spencer >>> >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 05:21:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7zs-0005q5-HI; Fri, 15 Jun 2007 05:21:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz7zr-0005oR-77 for p2psip@ietf.org; Fri, 15 Jun 2007 05:21:35 -0400 Received: from mailn.telecomitalia.it ([217.169.121.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz7zo-0005nb-K6 for p2psip@ietf.org; Fri, 15 Jun 2007 05:21:35 -0400 Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailn.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:21:31 +0200 Received: from ptpxch005rm001.idc.cww.telecomitalia.it ([156.54.205.167]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:21:30 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 11:21:30 +0200 Message-ID: <46725A81.50607@telecomitalia.it> Date: Fri, 15 Jun 2007 11:23:13 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: marcin.matuszewski@nokia.com Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology References: <001e01c7af13$506627a0$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> X-OriginalArrivalTime: 15 Jun 2007 09:21:30.0303 (UTC) FILETIME=[8ED504F0:01C7AF2E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: p2psip@ietf.org, philip_matthews@magma.ca X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017282859==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2017282859== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060908080507030707070209" This is a cryptographically signed message in MIME format. --------------ms060908080507030707070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit marcin.matuszewski@nokia.com wrote: > Let's assume for a while that we have STUN/TURN servers that are > external to the overlay but may assist peers/SIP UA in NAT traversal. If > we get rid of the client protocol and clients how those servers can > register to the DHT and advertise their services? Are we planning to > force all of network entities to implement a SIP stack? We probably need a mechanism to allow nodes to register resources other than SIP URIs; since such a mechanism will certainly be used by SIP UAs (why not in centralized or hybrid architectures too?) and since SIP already provides such a semantic, I'd really prefer to force network entities other than SIP UAs to implement the SIP REGISTER method (not a full stack) with the required TBD syntactic extensions, rather than force all nodes to implement a new protocol, or, even worse, to redundantly define a new protocol and then SIP extensions to avoid poor/weak/small SIP-aware devices to implement it! -- Ciao, Enrico --------------ms060908080507030707070209 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE1MDkyMzEzWjAjBgkqhkiG9w0BCQQxFgQUF5jFY3B3 uPvI/lJ3y2IL15dSGPwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAGc6D4Owi0qon4ObzPVR1YrpGCw/hWb+ErvLakBGqPtmcdmGepUjBLY8 YzR+XlyaLl5sY4FI1G0TZ3o58iY97mO7aIcuLFdc4mmyeAVG7uoG/O3wAKSZkoRGdBGZ7IzF 3dnijhUjxM6o4j18VAimd6RlnrNhlwYRNUN1hgKlDKMWoS3BPBcIgN19FYeESfSoRaBB1viD TzkaXQkvW50+EtYmyi++kl+D9ko8a2K0FIqeWeFwOZ3KOQWECu4ZTevSvNVStrGdf5RUazw/ xJKH3Pw1geNbac13M2yaApXjgxBKhew0FBdVIo1L9BXs34N8RfzrZ/odu5w5upnB/RbFZqcA AAAAAAA= --------------ms060908080507030707070209-- --===============2017282859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2017282859==-- From p2psip-bounces@ietf.org Fri Jun 15 06:34:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz98q-0000kj-RU; Fri, 15 Jun 2007 06:34:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz98p-0000kC-Ox for p2psip@ietf.org; Fri, 15 Jun 2007 06:34:55 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz98p-0006b0-Cg for p2psip@ietf.org; Fri, 15 Jun 2007 06:34:55 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5FAYlJn014957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Jun 2007 06:34:47 -0400 (EDT) Date: Fri, 15 Jun 2007 06:34:47 -0400 (EDT) From: Salman Abdul Baset To: Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposalfor active/passivepeerterminology In-Reply-To: <88FB6BB7-4855-4EA3-B025-A540123F202D@magma.ca> Message-ID: References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca><117301c7ae95$b5379f70$6901a8c0@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> <3F18E76823C95E4795181D74BAC7664F048C3D0C@esebe102.NOE.Nokia.com> <88FB6BB7-4855-4EA3-B025-A540123F202D@magma.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > But do you agree with Enrico too that everything Salman wants can be achieved > by simply having > the mobile node act as an ordinary SIP UA? Indeed, it can be done but this assumes SIP as the peer protocol. Is this the best design? Since we are P2PSIP WG, our goal is to design a peer protocol geared towards SIP. But as pointed by Jonathan Rosenberg a while back, this does not mean that we design a peer protocol which is so heavily geared towards SIP that it cannot be used for anything other than P2PSIP. We should not exclude the possibility that in the future some one can extend this protocol to applications such as p2p video streaming/on demand. -salman > - Philip > > On 15-Jun-07, at 04:06 , > wrote: > >> I fully agree with Salman. >> >> Marcin >> >>> -----Original Message----- >>> From: ext Salman Abdul Baset [mailto:salman@cs.columbia.edu] >>> Sent: 14 June, 2007 21:02 >>> To: Henry Sinnreich >>> Cc: P2PSIP Mailing List >>> Subject: RE: [P2PSIP] Concepts document: proposalfor >>> active/passivepeerterminology >>> >>> Further elaborating the point by Henry/Marcin on the usage >>> 'clients' and the variety of 'peers': >>> >>> 1) A device's processing/connection capabilites are "limited" >>> and particpating in a full blown DHT is a big hit on its >>> resources such as limited battery-life or bandwidth. >>> >>> 2) The nodes are behind a "restricted NAT/firewall" and it >>> might be feasible to leave them out of a DHT than to adopt the >>> best NAT traversal solution that allows these nodes to fully >>> participate in the DHT. Skype adopts this solution. >>> >>> 3) The concept of a 'client' easily lends itself to the >>> creation of hierachical overlays. >>> >>> >>> Peers perform the basic routing function but they can also >>> have different >>> capabilities. For concept draft purposes, I don't think we >>> need to further >>> disambiguate the peer concept based on the capabilities such >>> as storage, >>> CPU or b/w; that should be left to the overlay designer. >>> >>> -salman >>> >>> On Thu, 14 Jun 2007, Henry Sinnreich wrote: >>> >>>> At this point, I would like to share some text edited by Marcin >>>> Matuszewski for a requirements I-D for the P2P SIP that we are still >>>> working on: >>>> .... >>>> One assumption of DHT networks on the Internet could be that >>> the network >>>> nodes are homogenous, and they have enough processing power >>> and memory >>>> to run DHT networks without any limits. This assumption does not hold >>>> however if we consider mobile devices such as mobile phones, PDAs, or >>>> WiFi phones. Mobile devices are heterogeneous. Low-end >>> devices may have >>>> a little memory, a slow CPU and may not support fast packet radio >>>> interfaces. On the other hand, high-end devices may have >>> significantly >>>> higher capabilities: Fast radio interfaces, more memory and >>> faster CPU >>>> then they their less advanced counterparts. >>>> >>>>> From this reason we can classify network nodes into two categories: >>>> Mainly those that have enough CPU power, memory and fast network >>>> interface to run P2PSIP peer protocol and those that may not >>> have enough >>>> capabilities to become P2PSIP peers. >>>> >>>> Besides, if we consider the issue of NAT traversal, a very powerful >>>> mobile device can be behind a restrictive NAT. This may require the >>>> device to establish a TCP or TLS connection towards a TURN server. If >>>> the connection has to be maintained for a long period, it >>> may drain the >>>> device battery. From these reasons, not all battery powered devices >>>> though having enough capabilities to run the peer protocol will still >>>> not be able to become P2PSIP peers. >>>> >>>> Essentially, any DHT overlay network can support two basic >>> operations: >>>> PUT and GET. In the P2PSIP overlay a PUT operation is used to insert, >>>> modify, or delete data in the overlay,such as user or >>> resource records. >>>> A GET operation is used to retrieve data stored in the >>> overlay. Clients >>>> should be able to store, modify, delete and retrieve user >>> and resource >>>> records from the overlay; in the P2P language they must >>> support PUT and >>>> GET operations. >>>> .... >>>> Note again that clients do not participate in the maintenance of the >>>> DHT, but may use the DHT for certain functions, such as storage and >>>> retrieval of data. >>>> >>>> Henry >>>> >>>> -----Original Message----- >>>> From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] >>>> Sent: Thursday, June 14, 2007 5:07 PM >>>> To: P2PSIP Mailing List >>>> Subject: Re: [P2PSIP] Concepts document: proposal for >>>> active/passivepeerterminology >>>> >>>> I want to agree with Philip, and provide a wake-up call... >>>> >>>>> (2) As I have said before, I really, really want to see >>> good examples >>>> of >>>>> why we want to make this distinctions between types of peers (or >>>> whatever >>>>> we call them). Yes, we could design a system that allows for great >>>>> flexibility in types of peers allowed, but I want to first >>> understand >>>> why >>>>> this flexibility is useful. >>>>> >>>>> To be concrete: I suggest having a section in the document that >>>> discusses >>>>> these possibilities (and any others that people can think >>> of), but I >>>>> suggest holding off in giving them names and elevating >>> them to formal >>>> >>>>> "concepts" in the document until someone argues why one of these is >>>> of >>>>> particular interest. >>>> >>>>> From the meeting minutes at >>>> http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html... >>>> >>>> P2PSIP Client Discussion, Spencer Dawkins >>>> >>>> What are Clients? Not garden variety SIP UACs, nor the equivalent of >>>> "peers." >>>> >>>> Issue: Clients as storage nodes. No credible use case so >>> far; deferred. >>>> >>>> [ Discussion ensued at mic. >>>> >>>> Philip: Why do we need P2PSIP clients? The answer will >>> drive whether >>>> or >>>> not we use them. >>>> >>>> Brian Rosen (as individual): I don't understand P2PSIP clients. We >>>> need >>>> to get rid of it and focus on normal SIP clients. >>>> >>>> Philip: Those that want P2PSIP Clients need to come up with >>> a good use >>>> case by Chicago IETF. If they do not come up by then, the P2PSIP >>>> Clients >>>> go away. ] >>>> >>>> Hum - Should the wg work on the normal garden variety SIP UA >>> connected >>>> to >>>> the DHT via some box (a SIP proxy coupled to a peer)? >>>> >>>> [ Hum indicated yes. >>>> Those that want a P2PSIP Client distinct from a normal SIP >>> client need >>>> to >>>> get together and work on use cases. ] >>>> >>>> So - is this actually happening? Or are we trying to come up >>> with a name >>>> for >>>> a concept we don't need/don't know WHY we need? >>>> >>>> Just curious... the 00 draft cutoff being Monday, July 2, >>> and all that. >>>> >>>> Spencer >>>> >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 07:40:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAAA-0004uh-1P; Fri, 15 Jun 2007 07:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz9zL-000239-Jc for p2psip@ietf.org; Fri, 15 Jun 2007 07:29:11 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz9uZ-00060J-MX for p2psip@ietf.org; Fri, 15 Jun 2007 07:24:17 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5FBNldo032344; Fri, 15 Jun 2007 14:24:06 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:24:04 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:24:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts document: proposal for active/passive peer terminology Date: Fri, 15 Jun 2007 14:26:19 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F048C3F36@esebe102.NOE.Nokia.com> In-Reply-To: <46725A81.50607@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts document: proposal for active/passive peer terminology Thread-Index: AcevLpGG5XWxQQPER5m/XhfWxQrqbQACZ/aw References: <001e01c7af13$506627a0$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> <46725A81.50607@telecomitalia.it> From: To: , X-OriginalArrivalTime: 15 Jun 2007 11:24:03.0734 (UTC) FILETIME=[ADD18B60:01C7AF3F] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Enrico and Philip, Let me clarify this: Unmodified SIP UAs will communicate with the overlay using SIP. This requires that some of the peers are collocated with SIP proxy/registrar servers and implement SIP-DHT API. Not all of the peers and clients will speak SIP. We did not make any decision regarding using SIP as the peer protocol. Taking this into consideration many devices will not support the SIP protocol. We have to allow them to put/get information to/from a DHT. Widely deployed DHT networks such as PlanetLab use XML over HTTP based protocols to implement PUT/GET method. We should allow developers to extend their e.g. content sharing networks with real time communication functionality provided by P2PSIP. =20 =20 Guys, please do not try to push SIP to all of the internet devices. If you do so you will fail. Internet is not only about SIP! SIP is a session initiation protocol.=20 Marcin =20 >-----Original Message----- >From: ext Enrico Marocco [mailto:enrico.marocco@telecomitalia.it]=20 >Sent: 15 June, 2007 12:23 >To: Matuszewski Marcin (Nokia-NRC/Helsinki) >Cc: jiang.x.f@huawei.com; philip_matthews@magma.ca;=20 >ggb@tid.es; p2psip@ietf.org >Subject: Re: [P2PSIP] Concepts document: proposal for=20 >active/passive peer terminology > >marcin.matuszewski@nokia.com wrote: >> Let's assume for a while that we have STUN/TURN servers that are=20 >> external to the overlay but may assist peers/SIP UA in NAT=20 >traversal.=20 >> If we get rid of the client protocol and clients how those=20 >servers can=20 >> register to the DHT and advertise their services? Are we planning to=20 >> force all of network entities to implement a SIP stack? > >We probably need a mechanism to allow nodes to register=20 >resources other than SIP URIs; since such a mechanism will=20 >certainly be used by SIP UAs (why not in centralized or hybrid=20 >architectures too?) and since SIP already provides such a=20 >semantic, I'd really prefer to force network entities other=20 >than SIP UAs to implement the SIP REGISTER method (not a full=20 >stack) with the required TBD syntactic extensions, rather than=20 >force all nodes to implement a new protocol, or, even worse,=20 >to redundantly define a new protocol and then SIP extensions=20 >to avoid poor/weak/small SIP-aware devices to implement it! > >-- >Ciao, >Enrico > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 08:16:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAjV-0007NJ-4p; Fri, 15 Jun 2007 08:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAjU-0007IH-1S for p2psip@ietf.org; Fri, 15 Jun 2007 08:16:52 -0400 Received: from mailn.telecomitalia.it ([217.169.121.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAjS-0003AX-0j for p2psip@ietf.org; Fri, 15 Jun 2007 08:16:52 -0400 Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailn.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:16:17 +0200 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:16:17 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:16:16 +0200 Message-ID: <46728376.7050505@telecomitalia.it> Date: Fri, 15 Jun 2007 14:17:58 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Salman Abdul Baset Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca><117301c7ae95$b5379f70$6901a8c0@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> <3F18E76823C95E4795181D74BAC7664F048C3D0C@esebe102.NOE.Nokia.com> <88FB6BB7-4855-4EA3-B025-A540123F202D@magma.ca> In-Reply-To: X-OriginalArrivalTime: 15 Jun 2007 12:16:16.0453 (UTC) FILETIME=[F9108750:01C7AF46] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1133381817==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1133381817== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000503040707070904040804" This is a cryptographically signed message in MIME format. --------------ms000503040707070904040804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Salman Abdul Baset wrote: >> But do you agree with Enrico too that everything Salman wants can be >> achieved by simply having >> the mobile node act as an ordinary SIP UA? > > Indeed, it can be done but this assumes SIP as the peer protocol. Is > this the best design? Wait, wait wait. The fact that clients speak SIP with peers doesn't imply at all that the peer protocol is SIP. -- Ciao, Enrico --------------ms000503040707070904040804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE1MTIxNzU4WjAjBgkqhkiG9w0BCQQxFgQUi2C+/fkP jwl658an5xKvKxi9uEkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBADj5nbWh+xQQgnN4F1qfdCdS10KmdAmVTO4JP93jsP+khV2Id1MEXMLr Def2CK0neJuI4V/izmivVKa9QRkZxstTk7tm+BWhcJhiaQ/qjMOS8r6cC6cDI7ijtDtSt+DL 7jYdBmr+MK2L+4pHB4CpHAJTkwS2uwvEpgBGHDvtO6icBJNytcxsHkI3k+FiFglV2CKAsvxy niN2WvTIYkkd6DgMeylulD9Vzp2iuYr1szQ7hqtF9s5pLSNG5TDHfuubcNb/WqYB6qEIvTpC s3856MRIRIft4+XbjWoDWAQKB+4GL5Zj6BtI7K8g8DdUk4Y3/IaheGkr7YlKbkublNZUKHIA AAAAAAA= --------------ms000503040707070904040804-- --===============1133381817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1133381817==-- From p2psip-bounces@ietf.org Fri Jun 15 08:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAui-0005M9-Js; Fri, 15 Jun 2007 08:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAuh-0005M3-37 for p2psip@ietf.org; Fri, 15 Jun 2007 08:28:27 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAuf-0004r2-2v for p2psip@ietf.org; Fri, 15 Jun 2007 08:28:27 -0400 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:28:24 +0200 Received: from ptpxch004ba020.idc.cww.telecomitalia.it ([156.54.240.43]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:28:23 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 14:28:22 +0200 Message-ID: <4672864C.60005@telecomitalia.it> Date: Fri, 15 Jun 2007 14:30:04 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: marcin.matuszewski@nokia.com Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology References: <001e01c7af13$506627a0$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> <46725A81.50607@telecomitalia.it> <3F18E76823C95E4795181D74BAC7664F048C3F36@esebe102.NOE.Nokia.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F048C3F36@esebe102.NOE.Nokia.com> X-OriginalArrivalTime: 15 Jun 2007 12:28:22.0691 (UTC) FILETIME=[A9EFA730:01C7AF48] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: p2psip@ietf.org, philip_matthews@magma.ca X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0535759011==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0535759011== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030101070105020205070200" This is a cryptographically signed message in MIME format. --------------ms030101070105020205070200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit marcin.matuszewski@nokia.com wrote: > Enrico and Philip, > > Let me clarify this: > Unmodified SIP UAs will communicate with the overlay using SIP. This > requires that some of the peers are collocated with SIP proxy/registrar > servers and implement SIP-DHT API. Not all of the peers and clients will > speak SIP. We did not make any decision regarding using SIP as the peer > protocol. Taking this into consideration many devices will not support > the SIP protocol. We have to allow them to put/get information to/from a > DHT. Widely deployed DHT networks such as PlanetLab use XML over HTTP > based protocols to implement PUT/GET method. We should allow developers > to extend their e.g. content sharing networks with real time > communication functionality provided by P2PSIP. No, really, neither Philip nor I are proposing or pushing for SIP as the peer protocol. The problem is just to understand if there is real need for a _client_ protocol other than SIP, assuming that SIP will be supported anyway to let non-p2p clients to use the overlay, or if we can get rid of it (or, in other words, if we can say that the _client_ protocol is SIP). -- Ciao, Enrico --------------ms030101070105020205070200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE1MTIzMDA0WjAjBgkqhkiG9w0BCQQxFgQUrT/tizvd +wEveEHqXS+IcprulnEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAF3NxJ3lBdVJMq8P4gQ0acKuq48XzWeczHapzK6IXbwoRK9+jzneM7Ey jlX/fmCmxAmku+GgarOMPO6ktvzXiDiGWFp7IHkSOhtaTRhjcCUh8iqebUieMZ6b7VYAT4e4 HYki2zfbuJMWrJv3NUUn5m2b54jQMJf14/I4CzZc+4Cv3UtRimoCFphZfKVKq1Ibq7WsqHyj /fMYRAH2md8fHmbeTTwAuLyiYTg3RU+usvofOWcNwD9TvElVGnzrtofv6ZWaTrEmPN3lGHNo 89d/GoRYHlySjGzw9bIifCSmogK1hIrcxApAz4FeRTmX0oUTOYxnjEZuED4idhNKssNzweUA AAAAAAA= --------------ms030101070105020205070200-- --===============0535759011== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0535759011==-- From p2psip-bounces@ietf.org Fri Jun 15 09:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBsy-0007EU-7P; Fri, 15 Jun 2007 09:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzBsS-0006co-2y for p2psip@ietf.org; Fri, 15 Jun 2007 09:30:12 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzBoV-0003P3-Cu for p2psip@ietf.org; Fri, 15 Jun 2007 09:26:10 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5FD7107008779; Fri, 15 Jun 2007 15:07:01 +0200 Message-ID: <4672936B.50304@teigre.com> Date: Fri, 15 Jun 2007 15:26:03 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> In-Reply-To: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org While following this thread, I was trying to apply the various approaches to a use case Henry (Sinnreich) brought up during VON Europe: (from memory) "You go to the shop and buy a phone you like out of a selection the shop has. You plug it in when you come home using your family domain, and it just works." My elaboration: I assume that this use case implies that vendor A and vendor B each has a bootstrap server, which each device will connect to. This may imply one or two different overlays. I can easily see how people with the same domain in their email address can buy devices from different vendors (ex. company email address or maybe even gmail.com). Can we declare that a@company.com registering on a device from vendor A and b@company.com registering on a device from vendor B both should end up in the same overlay? Does that mean that the bootstrap servers of vendor A and vendor B need to direct each device to a different overlay? Is the overlay for a given domain in some way calculated and then registered if the domain doesn't already exist in an overlay? If not, and the two exist in two different overlays determined by (in this example) the vendor, I cannot see how we get out of it in a good way (without some kind of lookup). Is there something I don't see here?! Or is this use case something that should not be supported? g-) Dean Willis wrote: > > Someone brought this up on the list, and I wanted to clarify the > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many > domains. In this model, there might be only one overlay serving every > domain in the world, including (for example) "example.com" and > "example.net". Clearly routing messages within this overlay is > straightforward, and there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not all > domains, and we use RFC 3263 procedures to route between overlays. So > "example.com" might be in one overlay, and "example.net" in another. > Each overlay can look up the other in DNS to find it. > > This second model mostly precludes having one domain scattered across > multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and he's > not there. What to do? She can't just look up example.com in DNS, > because it has been split across A and B and DNS just doesn't work > that way. Now, if both A and B registered with some "upstream" lookup > function (a meta-overlay), then Alice could perhaps look there. But > this starts to get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays problem > (and that's not easy), we're much better off at this time having a > model where each domain can be mapped onto only one overlay at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 09:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCFZ-0006fB-8X; Fri, 15 Jun 2007 09:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzCFY-0006f4-Mu for p2psip@ietf.org; Fri, 15 Jun 2007 09:54:04 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzCFX-0000re-9I for p2psip@ietf.org; Fri, 15 Jun 2007 09:54:04 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1HzCFN-0002Yp-DB; Fri, 15 Jun 2007 08:53:53 -0500 From: "Brian Rosen" To: "'Greger V. Teigre'" , "'Enrico Marocco'" References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com><4671623C.8030701@telecomitalia.it> <4672371D.9040609@teigre.com> Subject: RE: [P2PSIP] Concepts document: proposalfor active/passive peerterminology Date: Fri, 15 Jun 2007 09:53:57 -0400 Message-ID: <0bac01c7af54$a0b88770$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4672371D.9040609@teigre.com> Thread-Index: AcevGi4NxyaMET3/SumKB9O6ij0spgANfBTQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think we can stomp this one hard. I think that, subject to someone coming up with a use case, the term =93client=94 is reserved for a SIP UA and nothing else. There were several attempts to define a client that wasn=92t a SIP UA, = but no one came up with a use case. We decided to leave the door open for a use case. No one has presented such. Therefore, at least until someone does, the word =93client=94 means a = SIP UA. We use the term "proxy peer" for the "gateway" you discuss below. We continue to debate the notion that there may be some variation in = "peers" (we don't yet agree on terminology for what is a peer) that usually have some variation on storage or network connectivity. Personally, I think attempts to work around limitations in storage = capacity are often fruitless unless we're talking gigabytes. I don't think we = are. Sometimes, we do need to be concerned with network bandwidth. I'm not = so sure we are in this case. I think that means that our choice for DHT needs to be reasonably = efficient in storage and bandwidth, but I doubt that is a revelation to anyone. = It would be fascinating to me to have someone take Chord, or one of the = other DHTs, scale it up to a typical mobile network size, and figure out what = each handset needs in storage and bandwidth to be a fully p2psip system. My = gut tells me it works. We're stuck with the NAT issue; there is no getting around that. I'd like to have more discussion on the above. Do we really, truly have = to worry about peers who can't store? Are we conflating the peers that = can't accept inbound from the peers that can't store -- that is, do we assume = a peer behind a NAT can't store? Is that an appropriate assumption? What ARE the storage requirements we are talking about? Probably, there = is a tradeoff between the size of the store and the bandwidth needed. Is = that actually relevant? Brian ________________________________________ From: Greger V. Teigre [mailto:greger@teigre.com]=20 Sent: Friday, June 15, 2007 2:52 AM To: Enrico Marocco Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Concepts document: proposalfor active/passive peerterminology I'm struggling a bit with an underlying issue that seems to only be implicitly addressed (or I confuse things up).=A0 To me it looks like = people are talking about two different types of clients without not always specifying explicitly when they talk about which. I think all agree that = the "client" does not have full peer capabilities. However, such a client = can be aware of the overlay (as in routing or having some storage capability) = and as such participate in the overlay as a "lesser peer" or it can be = ignorant of the overlay, except that it knows that some entity offers GET/PUT. = So, it needs to have a full peer, which acts as a "gateway" into the overlay. So, a first decision would be to decide whether a "lesser peer" should = be supported or if only access through a "gateway" should be allowed. A = second decision would be whether SIP should be used for communication between client and "gateway peer" or some other client protocol. g-) Enrico Marocco wrote:=20 Spencer Dawkins wrote:=20 So - is this actually happening? Or are we trying to come up with a name = for a concept we don't need/don't know WHY we need?=20 As far as I recall, the only credible use case which justifies the = existence of the "client" concept is that where a "non contributing" node wants to store/retrieve in the overlay something which can't be encoded in SIP (REGISTER?) messages (e.g. public keys, VM records...).=20 Since such functionalities are not required to realize what the group = has been chartered for (are they?) and perhaps they could be used in = centralized environments too, well... I personally hope that it _is_ happening and = that we get rid of "clients" before the next meeting.=20 ________________________________________ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 11:17:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDYc-0004RJ-Ar; Fri, 15 Jun 2007 11:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzDWC-0004AR-Cr for p2psip@ietf.org; Fri, 15 Jun 2007 11:15:21 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzDRh-0001RZ-Os for p2psip@ietf.org; Fri, 15 Jun 2007 11:10:43 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1HzDRq-0006fU-Cv; Fri, 15 Jun 2007 11:10:50 -0400 In-Reply-To: <3F18E76823C95E4795181D74BAC7664F048C3F36@esebe102.NOE.Nokia.com> References: <001e01c7af13$506627a0$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> <46725A81.50607@telecomitalia.it> <3F18E76823C95E4795181D74BAC7664F048C3F36@esebe102.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98A61432-091A-48BD-8596-531C688D899C@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology Date: Fri, 15 Jun 2007 11:10:42 -0400 To: "marcin.matuszewski@nokia.com> , Salman Abdul Baset X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I am actually quite sympathetic to the argument that P2PSIP should not just be about SIP. I do not think that SIP will be the only protocol used inside the overlay, and I now think that the peer protocol should be something other than SIP. But in your last few messages, you two seem to be proposing something different. It seems that you want the Distributed Database inside a P2PSIP overlay to be used for non-SIP-related data, and for this non-SIP-related data to be accessible via Puts/Gets from outside the overlay. I think this is a very interesting idea, but this is a new direction that I believe has not been suggested before. And I agree that supporting this strongly suggests that there should be a "database access" protocol that is distinct from SIP. - Philip On 15-Jun-07, at 07:26 , wrote: > Enrico and Philip, > > Let me clarify this: > Unmodified SIP UAs will communicate with the overlay using SIP. This > requires that some of the peers are collocated with SIP proxy/ > registrar > servers and implement SIP-DHT API. Not all of the peers and clients > will > speak SIP. We did not make any decision regarding using SIP as the > peer > protocol. Taking this into consideration many devices will not support > the SIP protocol. We have to allow them to put/get information to/ > from a > DHT. Widely deployed DHT networks such as PlanetLab use XML over HTTP > based protocols to implement PUT/GET method. We should allow > developers > to extend their e.g. content sharing networks with real time > communication functionality provided by P2PSIP. > > Guys, please do not try to push SIP to all of the internet devices. If > you do so you will fail. Internet is not only about SIP! SIP is a > session initiation protocol. > > Marcin > >> -----Original Message----- >> From: ext Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] >> Sent: 15 June, 2007 12:23 >> To: Matuszewski Marcin (Nokia-NRC/Helsinki) >> Cc: jiang.x.f@huawei.com; philip_matthews@magma.ca; >> ggb@tid.es; p2psip@ietf.org >> Subject: Re: [P2PSIP] Concepts document: proposal for >> active/passive peer terminology >> >> marcin.matuszewski@nokia.com wrote: >>> Let's assume for a while that we have STUN/TURN servers that are >>> external to the overlay but may assist peers/SIP UA in NAT >> traversal. >>> If we get rid of the client protocol and clients how those >> servers can >>> register to the DHT and advertise their services? Are we planning to >>> force all of network entities to implement a SIP stack? >> >> We probably need a mechanism to allow nodes to register >> resources other than SIP URIs; since such a mechanism will >> certainly be used by SIP UAs (why not in centralized or hybrid >> architectures too?) and since SIP already provides such a >> semantic, I'd really prefer to force network entities other >> than SIP UAs to implement the SIP REGISTER method (not a full >> stack) with the required TBD syntactic extensions, rather than >> force all nodes to implement a new protocol, or, even worse, >> to redundantly define a new protocol and then SIP extensions >> to avoid poor/weak/small SIP-aware devices to implement it! >> >> -- >> Ciao, >> Enrico >> > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 13:47:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFtZ-00028O-BZ; Fri, 15 Jun 2007 13:47:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFtY-00022V-6c for p2psip@ietf.org; Fri, 15 Jun 2007 13:47:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzFtW-0006cj-Ur for p2psip@ietf.org; Fri, 15 Jun 2007 13:47:36 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HzFtW-00039O-1t for p2psip@ietf.org; Fri, 15 Jun 2007 12:47:34 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Dean Willis Date: Fri, 15 Jun 2007 12:47:13 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [P2PSIP] Pointer to sipsec draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org If SIP is the fundamental protocol of our overlay (like with dSIP) and there are peer nodes acting as SIP proxies, then we will we need a way to protect sensitive information that is traversing those proxies. One approach that might work for this is outlined in: http://www.ietf.org/internet-drafts/draft-gurbani-sip-sipsec-01.txt -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 13:51:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFwt-0002JH-Qq; Fri, 15 Jun 2007 13:51:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzFws-0002JB-H0 for p2psip@ietf.org; Fri, 15 Jun 2007 13:51:02 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzFwr-00078z-9n for p2psip@ietf.org; Fri, 15 Jun 2007 13:51:02 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HzFwq-00039p-AK; Fri, 15 Jun 2007 12:51:00 -0500 In-Reply-To: <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> References: <001e01c7af13$506627a0$6905a40a@china.huawei.com> <3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Concepts document: proposal foractive/passivepeerterminology Date: Fri, 15 Jun 2007 12:50:39 -0500 To: X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 15, 2007, at 3:27 AM, wrote: > > Let's assume for a while that we have STUN/TURN servers that are > external to the overlay but may assist peers/SIP UA in NAT > traversal. If we get rid of the client protocol and clients how > those servers can register to the DHT and advertise their services? > Are we planning to force all of network entities to implement a SIP > stack? > well, if SIP is our P2P protocol, as in dSIP, then yes, we are planning to force all network entities that offer services to the overlay to either have a SIP stack or some other interface to an entity that does have a SIP Stack and can inform the overlay about those services. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 13:57:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG2r-0003bk-CV; Fri, 15 Jun 2007 13:57:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzG2p-0003bc-Oq for p2psip@ietf.org; Fri, 15 Jun 2007 13:57:11 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzG2o-00086B-HX for p2psip@ietf.org; Fri, 15 Jun 2007 13:57:11 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HzG2n-0003AM-Po; Fri, 15 Jun 2007 12:57:10 -0500 In-Reply-To: <0bac01c7af54$a0b88770$9501a8c0@cis.neustar.com> References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com><4671623C.8030701@telecomitalia.it> <4672371D.9040609@teigre.com> <0bac01c7af54$a0b88770$9501a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D8DC2A7-452C-47B1-AEBF-8B1866054BA6@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Concepts document: proposalfor active/passive peerterminology Date: Fri, 15 Jun 2007 12:56:50 -0500 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 15, 2007, at 8:53 AM, Brian Rosen wrote: > > I think that means that our choice for DHT needs to be reasonably > efficient > in storage and bandwidth, but I doubt that is a revelation to > anyone. It > would be fascinating to me to have someone take Chord, or one of > the other > DHTs, scale it up to a typical mobile network size, and figure out > what each > handset needs in storage and bandwidth to be a fully p2psip > system. My gut > tells me it works. Having recently seen a enormous data bill for light reading of mail on a Treo connected to a US GSM network, my gut tells me it might work but I don't want to pay for it. What part of $10 per megabyte do you not understand? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 15 15:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzH42-0005nd-Au; Fri, 15 Jun 2007 15:02:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzH40-0005nK-JC for p2psip@ietf.org; Fri, 15 Jun 2007 15:02:28 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HzH3z-0006jO-AJ for p2psip@ietf.org; Fri, 15 Jun 2007 15:02:28 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 38198175CD for ; Fri, 15 Jun 2007 19:01:57 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 15:01:57 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Jun 2007 15:01:55 -0400 Message-ID: <886DD03D15173C43BCE98EA662A0101A029B8F9D@stntexch12.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of p2psip mailing list for annoucements of non IETF meetings, symposiums, conferences, etc Thread-Index: Acevf6OrO19+MSn4Q8yOKDRyb8LSVg== From: "Rosen, Brian" To: "P2PSIP Mailing List" X-OriginalArrivalTime: 15 Jun 2007 19:01:57.0040 (UTC) FILETIME=[A52F5B00:01C7AF7F] X-Spam-Score: -2.8 (--) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [P2PSIP] Use of p2psip mailing list for annoucements of non IETF meetings, symposiums, conferences, etc X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org P2P is a big area of current research, and there is a lot of activity, and specifically conferences, symposiums and forums covering various aspects of peer to peer computing. p2psip is specific to establishing multimedia sessions using a peer to peer mechanism, and, although it uses more general purpose p2p mechanisms for its specific use, it has a fairly narrowly defined charter. We are seeing a relatively large number of meeting announcements on the list with agendas covering a very wide range of p2p research, and we have had some concerns raised. Accordingly, the chairs request that list members NOT post announcements of general peer to peer conferences, symposiums, workshops, etc. You are welcome to post announcements of meetings which are specific to multimedia session establishment using peer to peer techniques. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jun 16 00:07:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzPZe-0002H6-Hk; Sat, 16 Jun 2007 00:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzPZd-0002Gw-5D for p2psip@ietf.org; Sat, 16 Jun 2007 00:07:41 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzPZb-0002Ve-KY for p2psip@ietf.org; Sat, 16 Jun 2007 00:07:40 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 15 Jun 2007 21:07:33 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5G47VWs022185; Fri, 15 Jun 2007 21:07:31 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5G47K0c012528; Fri, 15 Jun 2007 21:07:30 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 21:07:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts document: proposal for active/passive peerterminology Date: Fri, 15 Jun 2007 21:07:16 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2299BDCC@namail5.corp.adobe.com> In-Reply-To: <98A61432-091A-48BD-8596-531C688D899C@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts document: proposal for active/passive peerterminology Thread-Index: AcevYGAQ2wVUviPpTiGi5KnFfDdFlAAaeUlQ References: <001e01c7af13$506627a0$6905a40a@china.huawei.com><3F18E76823C95E4795181D74BAC7664F048C3D4A@esebe102.NOE.Nokia.com><46725A81.50607@telecomitalia.it><3F18E76823C95E4795181D74BAC7664F048C3F36@esebe102.NOE.Nokia.com> <98A61432-091A-48BD-8596-531C688D899C@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , , "Salman Abdul Baset" X-OriginalArrivalTime: 16 Jun 2007 04:07:20.0160 (UTC) FILETIME=[D5AF3600:01C7AFCB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I am actually quite sympathetic to the argument that P2PSIP should =20 > not just be about SIP. Agree There is a lot of substance for both (1) the "client" argument and also (2) the "database" argument in the I-D that I recommend reading: > And I agree that supporting this strongly suggests that there should =20 > be a "database access" protocol that is distinct from SIP. Agree As for the recent discussions, there is a lot of substance for both (1) the "client" argument and also (2) the "database" argument in the I-D that I recommend reading: http://tools.ietf.org/id/draft-singh-p2p-sip-01.txt=20 I already regret going on vacation all next week and missing the fun :-) Thanks, Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Friday, June 15, 2007 5:11 PM To: marcin.matuszewski@nokia.com> Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzPcb-0006HM-9S; Sat, 16 Jun 2007 00:10:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzPca-0006Bv-GT for p2psip@ietf.org; Sat, 16 Jun 2007 00:10:44 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzPcY-0003Pp-4x for p2psip@ietf.org; Sat, 16 Jun 2007 00:10:44 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Fri, 15 Jun 2007 21:10:38 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5G4AaWs022257; Fri, 15 Jun 2007 21:10:37 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5G4AZ0c012584; Fri, 15 Jun 2007 21:10:36 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 21:10:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts document: proposal for active/passive peer terminology Date: Fri, 15 Jun 2007 21:10:29 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D2299BDCD@namail5.corp.adobe.com> In-Reply-To: <467192AE.6070800@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts document: proposal for active/passive peer terminology Thread-Index: AceutzC+1mK84aDhQPa+zSV1ZLLMNgBFOlXA References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> <467192AE.6070800@telecomitalia.it> From: "Henry Sinnreich" To: "Enrico Marocco" , "Salman Abdul Baset" X-OriginalArrivalTime: 16 Jun 2007 04:10:35.0766 (UTC) FILETIME=[4A465160:01C7AFCC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >I don't get why one should consider it a >client, i.e. something more than a UA, but non really a peer. For database functions and even for invoking the setup of a multicast tree. Henry -----Original Message----- From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it]=20 Sent: Thursday, June 14, 2007 9:11 PM To: Salman Abdul Baset Cc: Henry Sinnreich; P2PSIP Mailing List Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology Salman Abdul Baset wrote: > 1) A device's processing/connection capabilites are "limited" and > particpating in a full blown DHT is a big hit on its resources such as > limited battery-life or bandwidth. >=20 > 2) The nodes are behind a "restricted NAT/firewall" and it might be > feasible to leave them out of a DHT than to adopt the best NAT traversal > solution that allows these nodes to fully participate in the DHT. Skype > adopts this solution. 100% agree; if a device doesn't want (or has not enough resources or is not welcome) to participate in an overlay, it can just use it, simply acting as a SIP user agent. I don't get why one should consider it a client, i.e. something more than a UA, but non really a peer. > 3) The concept of a 'client' easily lends itself to the creation of > hierachical overlays. Uh? Can you elaborate a little? > Peers perform the basic routing function but they can also have > different capabilities. For concept draft purposes, I don't think we > need to further disambiguate the peer concept based on the capabilities > such as storage, CPU or b/w; that should be left to the overlay designer. I agree on this too. --=20 Ciao, Enrico _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jun 16 03:03:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzSJk-0002Tx-No; Sat, 16 Jun 2007 03:03:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzSJi-0002DT-1q for p2psip@ietf.org; Sat, 16 Jun 2007 03:03:26 -0400 Received: from mailn.telecomitalia.it ([217.169.121.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzSJg-00083e-6k for p2psip@ietf.org; Sat, 16 Jun 2007 03:03:26 -0400 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by mailn.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 09:03:23 +0200 Received: from ptpxch004rm001.idc.cww.telecomitalia.it ([156.54.205.166]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 09:03:22 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 09:03:21 +0200 Message-ID: <46738C40.4060403@telecomitalia.it> Date: Sat, 16 Jun 2007 09:07:44 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peer terminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D2294A1A8@namail5.corp.adobe.com> <467192AE.6070800@telecomitalia.it> <24CCCC428EFEA2469BF046DB3C7A8D2299BDCD@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D2299BDCD@namail5.corp.adobe.com> X-OriginalArrivalTime: 16 Jun 2007 07:03:22.0143 (UTC) FILETIME=[6D1DEAF0:01C7AFE4] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0176029329==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0176029329== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070400010400090401070406" This is a cryptographically signed message in MIME format. --------------ms070400010400090401070406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: >> I don't get why one should consider it a >> client, i.e. something more than a UA, but non really a peer. > > For database functions and even for invoking the setup of a multicast > tree. Yeah, that's definitely something hard to achieve with SIP. I don't know if advanced data management and multicast are what the group should focus on, at least in the beginning, but, if so, they certainly constitute a good use case to justify clients' existence. -- Ciao, Enrico --------------ms070400010400090401070406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE2MDcwNzQ0WjAjBgkqhkiG9w0BCQQxFgQUmRs22RKm QZpSKuhTLhXsH5qp/r0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBACx6HYXxmH/oh1OBLaGM5QxPeZBX8e1UmMbZW05jL9XLmlDX8ZrhHWG3 0ReuF3rLKJTuhgQSa98hqd/+Gz89Q0zMqh5DpXAn7u8aM7gQortCcy+rwP92QMnqTPTtYwf7 gzmIMNElb2YkcOT3rVTWo4+Yrnsx9SoO//1WIesK1SJU+lGtBBLPqCqkB8RDmEEBfcfGBrk5 6iOUhHN/pi4mhHVDjiEAL/tqIs+SUsA0e7E6jxv73A4HVj5HdiIUh7zoin0wBf1WVfDUY0N2 FHUM2mjXu2Y4TWZe2LwtOKdB+YWvxHkQsVQ99/jHeAEkWIaDq2MHp9+/AhlHSmmNPmr6c2oA AAAAAAA= --------------ms070400010400090401070406-- --===============0176029329== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0176029329==-- From p2psip-bounces@ietf.org Sat Jun 16 05:44:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUp6-0005Cy-CX; Sat, 16 Jun 2007 05:44:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzUp5-0005Cs-KK for p2psip@ietf.org; Sat, 16 Jun 2007 05:43:59 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzUp4-0008Hg-Ce for p2psip@ietf.org; Sat, 16 Jun 2007 05:43:59 -0400 Received: by wa-out-1112.google.com with SMTP id j5so1677769wah for ; Sat, 16 Jun 2007 02:43:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=p4XQ3mPECV7fyVVa2lyfyqV0FLDci8RZrVZ8PLeDQ8604StMIrO9ls5vuBcwC1hTGVTKlWHvOJXL/xNe7eeX4tF8d9cSdhiL0l/Ii4TCe2NQNTleKQxA0WbwlC9C4+ClDheulAU7p+aNg7Amoz6E1UdjBp8u7eqLzxD11jFnkjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pO3HQpneS7nBsm2AvqdCYUnhvk1vJoRIvMZssXKiXgMsFuEH1JDQOsMTeCRAYwgBcyt8TPs/23wfr8P/3Rq8IMZ49QvALJAod2zZvRhVruuKhTNFKY9qmtzmnzTnAKK3uMSON3F5CpzEVT1ILJYho/gjxXL9/Vh1aMIjIRYs5IY= Received: by 10.114.27.20 with SMTP id a20mr3997902waa.1181987037592; Sat, 16 Jun 2007 02:43:57 -0700 (PDT) Received: by 10.114.110.10 with HTTP; Sat, 16 Jun 2007 02:43:57 -0700 (PDT) Message-ID: <618e24240706160243u70dccc20t6d2c5f7c4459ac04@mail.gmail.com> Date: Sat, 16 Jun 2007 11:43:57 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [P2PSIP] p2psip state-of-the-art X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello, we are reading most drafts you submited and your work-in-progess in order to write a p2psip state-of-the-art and identify the key discussion and common open issues. Now, we are looking for p2psip-drafts applications, implementations, stacks... in order to evaluate what has been already done and what not. Please, could you send us some information about your p2psip developments? Thank you very much, Victor Pascual _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 04:47:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzqPk-00045A-RZ; Sun, 17 Jun 2007 04:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzqPj-000455-FK for p2psip@ietf.org; Sun, 17 Jun 2007 04:47:15 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzqPi-0006x7-PZ for p2psip@ietf.org; Sun, 17 Jun 2007 04:47:15 -0400 X-ClientAddr: 213.145.160.17 Received: from [127.0.0.1] (213-145-160-17.dd.nextgentel.com [213.145.160.17]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5H8Rom2006797; Sun, 17 Jun 2007 10:27:51 +0200 Message-ID: <4674F509.5010202@teigre.com> Date: Sun, 17 Jun 2007 10:47:05 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] Concepts document: proposalfor active/passive peerterminology References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <5AF67D05-FA10-4147-8B83-961E0B94DB34@magma.ca> <117301c7ae95$b5379f70$6901a8c0@china.huawei.com><4671623C.8030701@telecomitalia.it> <4672371D.9040609@teigre.com> <0bac01c7af54$a0b88770$9501a8c0@cis.neustar.com> In-Reply-To: <0bac01c7af54$a0b88770$9501a8c0@cis.neustar.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pontius.teigre.com id l5H8Rom2006797 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I have a use case I'm struggling to map onto the various terms, and I'm=20 also not sure where this working groups scope ends: Let's say we have a regular 3261 SIP proxy. It wants to proxy requests=20 into a number of overlays. Let's assume that AORs are distributed=20 according to their domain (and AORs with the same domain name cannot be=20 registered in several overlays). We can then implement the contact between the proxy's domain(s) and the=20 overlays in (at least) two ways: a. Forward an INVITE into the overlay and wait for the result b. Lookup the AOR in the overlay before proxying the INVITE and make=20 routing decision based on the response a does not require any coding in existing SIP proxyies, while b requires=20 the SIP proxy to implement some sort of lookup mechanism into the=20 overlay(s), either by being a peer in each overlay or by contacting a=20 "proxy peer" (or is it "adapter peer"?) using some sort of data access=20 protocol. If we add the possibility of AORs from the same domain being registered=20 in several overlays or if we want the proxy to route (or not) based on=20 presence, we really need to do b. I certainly don't want the data access protocol aka client protocol to=20 be SIP, because I would then get a SIP message back that is really not=20 part of initial INVITE transaction (or if it does not have the same=20 transaction id, my proxy needs to be a UAC). The XML-RPC Get method=20 described in http://tools.ietf.org/id/draft-singh-p2p-sip-01.txt seems=20 more promising. And btw, the alternative, requiring a SIP proxy to be a=20 peer in every overlay it wants to forward requests to sounds like the=20 best way to stop that kind of communication from being done. (a=20 side-note: from a SIP proxy implementation perspective, it is clearly a=20 preference not having to implement a special standalone local query node=20 that will registers as a peer and then offer a proprietary lookup=20 interface to the proxy) Finally, if we assume some kind of meta-lookup across overlays, we may=20 be better off, but this is starting to feel a bit enum'ish to me... g-) Brian Rosen wrote: > > > I think we can stomp this one hard. > > I think that, subject to someone coming up with a use case, the term > =93client=94 is reserved for a SIP UA and nothing else. > > There were several attempts to define a client that wasn=92t a SIP UA, = but no > one came up with a use case. > We decided to leave the door open for a use case. > No one has presented such. > > Therefore, at least until someone does, the word =93client=94 means a S= IP UA. > We use the term "proxy peer" for the "gateway" you discuss below. > > We continue to debate the notion that there may be some variation in "p= eers" > (we don't yet agree on terminology for what is a peer) that usually hav= e > some variation on storage or network connectivity. > > Personally, I think attempts to work around limitations in storage capa= city > are often fruitless unless we're talking gigabytes. I don't think we a= re. > > Sometimes, we do need to be concerned with network bandwidth. I'm not = so > sure we are in this case. > > I think that means that our choice for DHT needs to be reasonably effic= ient > in storage and bandwidth, but I doubt that is a revelation to anyone. = It > would be fascinating to me to have someone take Chord, or one of the ot= her > DHTs, scale it up to a typical mobile network size, and figure out what= each > handset needs in storage and bandwidth to be a fully p2psip system. My= gut > tells me it works. > > We're stuck with the NAT issue; there is no getting around that. > > I'd like to have more discussion on the above. Do we really, truly hav= e to > worry about peers who can't store? Are we conflating the peers that ca= n't > accept inbound from the peers that can't store -- that is, do we assume= a > peer behind a NAT can't store? Is that an appropriate assumption? > > What ARE the storage requirements we are talking about? Probably, ther= e is > a tradeoff between the size of the store and the bandwidth needed. Is = that > actually relevant? > > Brian > > ________________________________________ > From: Greger V. Teigre [mailto:greger@teigre.com]=20 > Sent: Friday, June 15, 2007 2:52 AM > To: Enrico Marocco > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts document: proposalfor active/passive > peerterminology > > I'm struggling a bit with an underlying issue that seems to only be > implicitly addressed (or I confuse things up). To me it looks like peo= ple > are talking about two different types of clients without not always > specifying explicitly when they talk about which. I think all agree tha= t the > "client" does not have full peer capabilities. However, such a client c= an be > aware of the overlay (as in routing or having some storage capability) = and > as such participate in the overlay as a "lesser peer" or it can be igno= rant > of the overlay, except that it knows that some entity offers GET/PUT. S= o, it > needs to have a full peer, which acts as a "gateway" into the overlay. > > So, a first decision would be to decide whether a "lesser peer" should = be > supported or if only access through a "gateway" should be allowed. A se= cond > decision would be whether SIP should be used for communication between > client and "gateway peer" or some other client protocol. > g-) > > Enrico Marocco wrote:=20 > Spencer Dawkins wrote:=20 > > So - is this actually happening? Or are we trying to come up with a nam= e for > a concept we don't need/don't know WHY we need?=20 > > As far as I recall, the only credible use case which justifies the exis= tence > of the "client" concept is that where a "non contributing" node wants t= o > store/retrieve in the overlay something which can't be encoded in SIP > (REGISTER?) messages (e.g. public keys, VM records...).=20 > Since such functionalities are not required to realize what the group h= as > been chartered for (are they?) and perhaps they could be used in centra= lized > environments too, well... I personally hope that it _is_ happening and = that > we get rid of "clients" before the next meeting.=20 > > > > ________________________________________ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 04:49:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzqRd-0004eU-SS; Sun, 17 Jun 2007 04:49:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzqRc-0004eE-Ja for p2psip@ietf.org; Sun, 17 Jun 2007 04:49:12 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzqRb-00078z-KM for p2psip@ietf.org; Sun, 17 Jun 2007 04:49:12 -0400 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 10:49:10 +0200 Received: from ptpxch004rm001.idc.cww.telecomitalia.it ([156.54.205.166]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 10:49:10 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Sun, 17 Jun 2007 10:49:09 +0200 Message-ID: <4674F5ED.9070000@telecomitalia.it> Date: Sun, 17 Jun 2007 10:50:53 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: P2PSIP Mailing List X-OriginalArrivalTime: 17 Jun 2007 08:49:09.0492 (UTC) FILETIME=[5ED84340:01C7B0BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Emil Ivov Subject: [P2PSIP] Peer protocol, DHT and running code X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087597225==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============2087597225== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000104090104000805020709" This is a cryptographically signed message in MIME format. --------------ms000104090104000805020709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Folks, Emil and I have just submitted two drafts specifying the peer protocol (XPP) and the overlay algorithm (CAN based) we have implemented in the last version of sipdht (http://sipdht.sourceforge.net/sipdht2/). Till they appear in the repository, you can find them at the following links (just s/txt/html/ or s/txt/xml/ if you prefer html or xml): http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-pcan-00.txt We hope this contribution will stimulate discussion on some key issues we've tried to address, among which: + transport and encoding for the peer protocol; + DHT algorithm; + peer joins. On the latter, we propose a mechanism to let nodes join the overlay only when they are explicitly invited by existing peers. Such a "passive" approach (yeah, Dean anticipated that the term was going to get overloaded) has some benefits which deserve to be investigated. Needless to say, any feedback is very very appreciated. -- Ciao, Enrico --------------ms000104090104000805020709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjE3MDg1MDUzWjAjBgkqhkiG9w0BCQQxFgQUMYZqfut2 HX6N0t5K6djByTJQrFowUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAAHxl+E0lBNBui+2OfJBseE7ebdgQGchFcKKg8um4SZhyoCSNMNFG0ka /Zv5e80IJoffDxZxKON4AsUuW8VI2zqdlmBzXc7GHKfMeUdep8+ce3HbL3uoKA4ADVj12Ewb 0Ifj37apVov9Gv/ny6x3DqxCslSHlOf7yTwblrSGjvpZ+n7cex6AdOgm/7A81hd82ehoLTbd Rk+E+gElweVJTPh8JCPSvkrwiyQGneme1jpVKgAIHW5omNl7HV06t5Nc6ud2E++QckialSxg ieTEVUqCZSbsu4FSofKvtAz7DtXRMSrns099aliStILjrHci3gGnBz0rTPY7qE59bxSoaZEA AAAAAAA= --------------ms000104090104000805020709-- --===============2087597225== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2087597225==-- From p2psip-bounces@ietf.org Sun Jun 17 09:15:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzubH-0006Qx-6j; Sun, 17 Jun 2007 09:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzubF-0006QY-UD for p2psip@ietf.org; Sun, 17 Jun 2007 09:15:25 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzubE-0004e2-Jv for p2psip@ietf.org; Sun, 17 Jun 2007 09:15:25 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1HzubE-0002Sy-1F; Sun, 17 Jun 2007 09:15:24 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sun, 17 Jun 2007 09:15:25 -0400 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Folks: Eric Cooper, Alan Johnston, and I have just written a draft that suggests what we think is an interesting direction for the P2PSIP working group. We argue that a P2PSIP overlay should use HIP (the Host Identity Protocol) to provide a number of the basic features in an overlay, namely: o Peer IDs; o Transporting messages around the overlay; o Signaling new overlay connections; o Supporting mobility and multi-homing of peers; o Providing message security. One of the reasons we really like this idea is because, using the approach described in the draft, many existing applications don't require any modifications and "just work" in an overlay. We describe this idea in a draft that has just been submitted. Until the draft appears in the archives, you can get a copy at http://www.magma.ca/~philip_matthews/draft-willis-p2psip- concepts-04.txt or for the html version http://www.magma.ca/~philip_matthews/draft-willis-p2psip- concepts-04.htm Here is the abstract from the draft: This document examines a P2PSIP architecture where the peer-to-peer (P2P) layer is separate from and lies below the SIP layer. We discuss the functions of the P2P layer in such an architecture, and focus in on the Distributed Transport function - the function that allows a peer to exchange messages with any other peer in the overlay, even in the presence of NATs. We list the features that the Distributed Transport function needs to provide, and observe that the Host Identity Protocol (HIP) already provides a number of these features. We then propose extensions to HIP that allow it to provide the missing features. We discuss how a complete P2PSIP architecture can be built around HIP, and contrast this approach with other approaches for implementing a P2P layer. Two of the advantages of HIP approach are that (a) most existing applications can run in an overlay without needing any changes and (b) peer mobility and NAT traversal are handled in a way that is transparent to most applications. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 09:39:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzuy9-0003VJ-8g; Sun, 17 Jun 2007 09:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzuy8-0003VC-D0 for p2psip@ietf.org; Sun, 17 Jun 2007 09:39:04 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hzuy6-0000MX-SQ for p2psip@ietf.org; Sun, 17 Jun 2007 09:39:04 -0400 X-VirusChecked: Checked X-Env-Sender: vm@motorola.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1182087541!13099894!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.7] Received: (qmail 15052 invoked from network); 17 Jun 2007 13:39:02 -0000 Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-15.tower-128.messagelabs.com with SMTP; 17 Jun 2007 13:39:02 -0000 Received: from az33exr01.mot.com ([10.64.251.231]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l5HDd1GD024642 for ; Sun, 17 Jun 2007 06:39:01 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5HDd0Mn022038 for ; Sun, 17 Jun 2007 08:39:00 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5HDcw6E022033 for ; Sun, 17 Jun 2007 08:38:59 -0500 (CDT) Received: from 10.177.8.42 ([10.177.8.42]) by ZMY16EXM70.ds.mot.com ([10.179.4.29]) with Microsoft Exchange Server HTTP-DAV ; Sun, 17 Jun 2007 13:38:57 +0000 Content-Type: text/plain; charset="iso-8859-1" thread-topic: P2PSIP Digest, Vol 6, Issue 19 thread-index: Acew5Nr0brkqPZXrR3iTgqN0yy7qdw== MIME-Version: 1.0 From: "V MARIAPPAN-a24097" Date: Sun, 17 Jun 2007 19:09:11 +0530 Message-ID: 3:1267 Importance: normal X-Priority: 3 To: X-Vontu: Pass X-Spam-Score: 2.6 (++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Subject: [P2PSIP] P2PSIP Digest, Vol 6, Issue 19 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 09:41:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzv0E-0004Iz-2P; Sun, 17 Jun 2007 09:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzv0C-0004Iq-Av for p2psip@ietf.org; Sun, 17 Jun 2007 09:41:12 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hzv09-0000k1-OU for p2psip@ietf.org; Sun, 17 Jun 2007 09:41:11 -0400 X-VirusChecked: Checked X-Env-Sender: vm@motorola.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1182087669!15383492!1 X-StarScan-Version: 5.5.12.11; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 4712 invoked from network); 17 Jun 2007 13:41:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 17 Jun 2007 13:41:09 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l5HDf8rd020753 for ; Sun, 17 Jun 2007 06:41:08 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l5HDf8Y7007832 for ; Sun, 17 Jun 2007 08:41:08 -0500 (CDT) Received: from ZMY16EXM70.ds.mot.com (zmy16exm70.ap.mot.com [10.179.4.29]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l5HDf6p5007827 for ; Sun, 17 Jun 2007 08:41:07 -0500 (CDT) Received: from 10.177.8.42 ([10.177.8.42]) by ZMY16EXM70.ds.mot.com ([10.179.4.29]) with Microsoft Exchange Server HTTP-DAV ; Sun, 17 Jun 2007 13:41:06 +0000 Content-Type: text/plain; charset="iso-8859-1" thread-topic: P2PSIP Digest, Vol 6, Issue 19 thread-index: Acew5SfIhNovQ2DSQtGEtGhvXMEDaQ== MIME-Version: 1.0 From: "V MARIAPPAN-a24097" Date: Sun, 17 Jun 2007 19:11:19 +0530 Message-ID: 3:1267 Importance: normal X-Priority: 3 To: X-Vontu: Pass X-Spam-Score: 2.6 (++) X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 Subject: [P2PSIP] P2PSIP Digest, Vol 6, Issue 19 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 14:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzzM2-0007Zs-UP; Sun, 17 Jun 2007 14:20:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzzLx-0007ZQ-DK for p2psip@ietf.org; Sun, 17 Jun 2007 14:19:57 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzzLv-0007P2-PR for p2psip@ietf.org; Sun, 17 Jun 2007 14:19:57 -0400 Received: by wa-out-1112.google.com with SMTP id j5so2187407wah for ; Sun, 17 Jun 2007 11:19:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lHlf/1uJtQ1ChdEB/znJSLeG19Lef+MHIAOXS0sI7kojWgou1MwiHypr1VuIoZDmJZzSQlQ4Qr04hevd3Yxf5NYzAlBMIZ91+6KVqbJ54BXNY9go1FX9ObU16EjC2fx/zMT6ylnk1dENRgbKhKBDJQ/X/a969sxxDNSRUULRRxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q3y9+hQ4pokhnW0SH78aTlXSyXRwMsEsDDahkrfE5X77mbbgy1yIHCHCURPC8swrA4HCs17ZoUkNN1Uq78RFhmvkFvnoF8zGotfBfDnwP14UV8hlkgQPr8zYd2Fq0TG10Z/RvYcZ7IDcmlGE00In3N03IV451792uWgxcsQ+EBM= Received: by 10.114.146.1 with SMTP id t1mr5400652wad.1182104394980; Sun, 17 Jun 2007 11:19:54 -0700 (PDT) Received: by 10.114.110.10 with HTTP; Sun, 17 Jun 2007 11:19:54 -0700 (PDT) Message-ID: <618e24240706171119j73283ebdl3d17dfcde5547ff0@mail.gmail.com> Date: Sun, 17 Jun 2007 20:19:54 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "Dean Willis" Subject: Re: [P2PSIP] Pointer to sipsec draft In-Reply-To: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello, On 15/06/07, Dean Willis wrote: > we will we need > a way to protect sensitive information that is traversing those proxies. Is signaling security in the scope of this WG? And media security? IMHO using security on signaling, media or both depends on using Stateless or Stateful proxies. Thanks in advance, Victor Pascual _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 14:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzzoY-0002t7-4L; Sun, 17 Jun 2007 14:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzzoX-0002t1-K2 for p2psip@ietf.org; Sun, 17 Jun 2007 14:49:29 -0400 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzzoV-00066a-A9 for p2psip@ietf.org; Sun, 17 Jun 2007 14:49:29 -0400 Received: by wa-out-1112.google.com with SMTP id j5so2195108wah for ; Sun, 17 Jun 2007 11:49:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jh6FqpKqxyFJfDmuQ3GtUXOk0W6JJc4Zq4pdVbMBXkjinF2BSwP5SBckKaMoDVXN+VxI1nWoEU7lDko/B4bUs6yNaybfLhJJHpV8HPxQ0BiY5CDYCphSxxN+u+bEtWDam+5PLS7++qzGUrn5TnS+cjBiAStA6/FPXb4/XoFaiQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EVHUx23sZwhotJaMmrlr0txseVlPWQuarnAtSYV79Q4ZnIks6ZRvyVTcyt1pUnlvCgbkvY3bvVymIhk/CthZOEjI+NPhxImup/X5GyL6OLXqC0FD3MJev6ateD/LhCmF9BsqfnchDeTVtPQF32X9p/dR5cAMrBZHGiZIaj770Rw= Received: by 10.114.135.1 with SMTP id i1mr5370598wad.1182106166495; Sun, 17 Jun 2007 11:49:26 -0700 (PDT) Received: by 10.114.110.10 with HTTP; Sun, 17 Jun 2007 11:49:26 -0700 (PDT) Message-ID: <618e24240706171149scce75dbo404e9bcac883ba27@mail.gmail.com> Date: Sun, 17 Jun 2007 20:49:26 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "Dean Willis" Subject: Re: [P2PSIP] Pointer to sipsec draft In-Reply-To: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello, On 15/06/07, Dean Willis wrote: > we will we need > a way to protect sensitive information that is traversing those proxies. Is signaling security in the scope of this WG? And media security? IMHO using security on signaling, media or both depends on using Stateless or Stateful proxies. Thanks in advance, Victor Pascual _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 15:07:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I006L-0006Uf-0W; Sun, 17 Jun 2007 15:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I006J-0006Ua-8s for p2psip@ietf.org; Sun, 17 Jun 2007 15:07:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I006H-0004Jn-QF for p2psip@ietf.org; Sun, 17 Jun 2007 15:07:51 -0400 Received: (qmail invoked by alias); 17 Jun 2007 19:07:48 -0000 Received: from p5498698D.dip.t-dialin.net (EHLO [192.168.1.3]) [84.152.105.141] by mail.gmx.net (mp037) with SMTP; 17 Jun 2007 21:07:48 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ZDeJRMzNZdVDu+osVAG8jSJknu5ix7gdl99+6xk aP0YAKSdOnAFrt Message-ID: <46758683.8050608@gmx.net> Date: Sun, 17 Jun 2007 21:07:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 References: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> In-Reply-To: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Phillip, you might also find these two documents of interest for you: Interaction between SIP and HIP http://www.tschofenig.com/svn/draft-tschofenig-hiprg-host-identities/draft-tschofenig-hiprg-host-identities-05.txt Using SRTP transport format with HIP http://www.tschofenig.com/svn/draft-tschofenig-hiprg-hip-srtp/draft-tschofenig-hiprg-hip-srtp-02.txt Ciao Hannes Philip Matthews wrote: > Folks: > > Eric Cooper, Alan Johnston, and I have just written a draft that > suggests what we think > is an interesting direction for the P2PSIP working group. > > We argue that a P2PSIP overlay should use HIP (the Host Identity > Protocol) > to provide a number of the basic features in an overlay, namely: > o Peer IDs; > o Transporting messages around the overlay; > o Signaling new overlay connections; > o Supporting mobility and multi-homing of peers; > o Providing message security. > > One of the reasons we really like this idea is because, using the > approach > described in the draft, many existing applications don't require any > modifications > and "just work" in an overlay. > > We describe this idea in a draft that has just been submitted. > Until the draft appears in the archives, you can get a copy at > http://www.magma.ca/~philip_matthews/draft-willis-p2psip-concepts-04.txt > > or for the html version > http://www.magma.ca/~philip_matthews/draft-willis-p2psip-concepts-04.htm > > > Here is the abstract from the draft: > This document examines a P2PSIP architecture where the peer-to-peer > (P2P) layer is separate from and lies below the SIP layer. We > discuss the functions of the P2P layer in such an architecture, and > focus in on the Distributed Transport function - the function that > allows a peer to exchange messages with any other peer in the > overlay, even in the presence of NATs. We list the features that the > Distributed Transport function needs to provide, and observe that the > Host Identity Protocol (HIP) already provides a number of these > features. We then propose extensions to HIP that allow it to provide > the missing features. We discuss how a complete P2PSIP architecture > can be built around HIP, and contrast this approach with other > approaches for implementing a P2P layer. Two of the advantages of > HIP approach are that (a) most existing applications can run in an > overlay without needing any changes and (b) peer mobility and NAT > traversal are handled in a way that is transparent to most > applications. > > - Philip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 18:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I02rd-00019x-Hu; Sun, 17 Jun 2007 18:04:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I02rb-00019n-T5 for p2psip@ietf.org; Sun, 17 Jun 2007 18:04:51 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I02ra-0002TD-Lq for p2psip@ietf.org; Sun, 17 Jun 2007 18:04:51 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I02ra-0007KB-5Q; Sun, 17 Jun 2007 17:04:50 -0500 In-Reply-To: <618e24240706171149scce75dbo404e9bcac883ba27@mail.gmail.com> References: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com> <618e24240706171149scce75dbo404e9bcac883ba27@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5E78BF77-E3A0-478B-9EC9-C291B62BFC49@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [P2PSIP] Pointer to sipsec draft Date: Sun, 17 Jun 2007 17:04:33 -0500 To: =?ISO-8859-1?Q?"Victor_Pascual_=C1vila"?= X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 17, 2007, at 1:49 PM, Victor Pascual =C1vila wrote: > Hello, > > On 15/06/07, Dean Willis wrote: >> we will we need >> a way to protect sensitive information that is traversing those =20 >> proxies. > > Is signaling security in the scope of this WG? And media security? > IMHO using security on signaling, media or both depends on using > Stateless or Stateful proxies. I believe signaling security is clearly in scope, and that media =20 security arguably is to the extent that we want to make sure our =20 stuff works with the media security layers developed elsewhere, such =20 as SRTP/DTLS and ZRTP. One of the big challenges we had to face in getting the group =20 chartered was assuring people that the security issues of P2P systems =20= could be resolved in an acceptable way. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 19:58:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04dM-0008Ad-74; Sun, 17 Jun 2007 19:58:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I04dK-0008AN-Bq for p2psip@ietf.org; Sun, 17 Jun 2007 19:58:14 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I04dI-0004xq-C7 for p2psip@ietf.org; Sun, 17 Jun 2007 19:58:13 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I04dH-00084L-KI for p2psip@ietf.org; Sun, 17 Jun 2007 19:58:12 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> References: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1241F709-8FFC-4CB6-86BC-28A2FBB8A8D1@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 Date: Sun, 17 Jun 2007 19:58:08 -0400 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Whoops! It was just pointed out to me that I gave the wrong links in the e- mail below. The correct links are: Text version: http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- hop-00.txt HTML version: http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip- hop-00.htm Sorry about that. - Philip PS. The links quoted in the original message were to the Concepts draft. I recommend reading that one too! :-) On 17-Jun-07, at 09:15 , Philip Matthews wrote: > Folks: > > Eric Cooper, Alan Johnston, and I have just written a draft that > suggests what we think > is an interesting direction for the P2PSIP working group. > > We argue that a P2PSIP overlay should use HIP (the Host Identity > Protocol) > to provide a number of the basic features in an overlay, namely: > o Peer IDs; > o Transporting messages around the overlay; > o Signaling new overlay connections; > o Supporting mobility and multi-homing of peers; > o Providing message security. > > One of the reasons we really like this idea is because, using the > approach > described in the draft, many existing applications don't require > any modifications > and "just work" in an overlay. > > We describe this idea in a draft that has just been submitted. > Until the draft appears in the archives, you can get a copy at > http://www.magma.ca/~philip_matthews/draft-willis-p2psip- > concepts-04.txt > or for the html version > http://www.magma.ca/~philip_matthews/draft-willis-p2psip- > concepts-04.htm > > Here is the abstract from the draft: > This document examines a P2PSIP architecture where the peer-to-peer > (P2P) layer is separate from and lies below the SIP layer. We > discuss the functions of the P2P layer in such an architecture, and > focus in on the Distributed Transport function - the function that > allows a peer to exchange messages with any other peer in the > overlay, even in the presence of NATs. We list the features > that the > Distributed Transport function needs to provide, and observe > that the > Host Identity Protocol (HIP) already provides a number of these > features. We then propose extensions to HIP that allow it to > provide > the missing features. We discuss how a complete P2PSIP > architecture > can be built around HIP, and contrast this approach with other > approaches for implementing a P2P layer. Two of the advantages of > HIP approach are that (a) most existing applications can run in an > overlay without needing any changes and (b) peer mobility and NAT > traversal are handled in a way that is transparent to most > applications. > > - Philip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 17 22:18:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I06oS-00022F-K7; Sun, 17 Jun 2007 22:17:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I06oQ-0001j4-Ge for p2psip@ietf.org; Sun, 17 Jun 2007 22:17:50 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I06oN-0006zM-LE for p2psip@ietf.org; Sun, 17 Jun 2007 22:17:50 -0400 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 <0JJT000PQ7OBBH@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 18 Jun 2007 10:16:59 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJT00DOG7O9DB@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 18 Jun 2007 10:16:59 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJT009407O5JP@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 18 Jun 2007 10:16:57 +0800 (CST) Date: Mon, 18 Jun 2007 10:16:53 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Concepts document: proposalfor active/passivepeerterminology In-reply-to: <0bac01c7af54$a0b88770$9501a8c0@cis.neustar.com> To: 'Brian Rosen' Message-id: <002701c7b14e$bceb4850$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcevGi4NxyaMET3/SumKB9O6ij0spgANfBTQAH9GiyA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org My two cents... Other than client and peer, there are some nodes having some other = service which would be helpful for the communication in the overlay, For = example, STUN or STUN relay service. At the same time, these service providers = MAY not speak SIP. How do we decide the role of this kind of nodes? client or peer? If we = treat them as clients, it SHOULD have access mechanism to the overlay to put = their service so that other peers or clients know where they are. If we treat them as peers, it could use GET/PUT operations of peer protocol to = achieve this. But one important work of these nodes as a peer is to maintain the overlay. If it is a peer and service other nodes may make it not stable, hence influence the stability of the overlay.=20 So we should not confine the location where these kinds of nodes lie. = Client role other ordinary SIP UA and client protocol other than SIP protocol = MAY be helpful.=20 Regards! -- Jiang XingFeng > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, June 15, 2007 9:54 PM > To: 'Greger V. Teigre'; 'Enrico Marocco' > Cc: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Concepts document: proposalfor > active/passivepeerterminology >=20 > >=20 > I think we can stomp this one hard. >=20 > I think that, subject to someone coming up with a use case, the term > =93client=94 is reserved for a SIP UA and nothing else. >=20 > There were several attempts to define a client that wasn=92t a SIP UA, = but no > one came up with a use case. > We decided to leave the door open for a use case. > No one has presented such. >=20 > Therefore, at least until someone does, the word =93client=94 means a = SIP UA. > We use the term "proxy peer" for the "gateway" you discuss below. >=20 > We continue to debate the notion that there may be some variation in "peers" > (we don't yet agree on terminology for what is a peer) that usually = have > some variation on storage or network connectivity. >=20 > Personally, I think attempts to work around limitations in storage capacity > are often fruitless unless we're talking gigabytes. I don't think we = are. >=20 > Sometimes, we do need to be concerned with network bandwidth. I'm not = so > sure we are in this case. >=20 > I think that means that our choice for DHT needs to be reasonably efficient > in storage and bandwidth, but I doubt that is a revelation to anyone. = It > would be fascinating to me to have someone take Chord, or one of the = other > DHTs, scale it up to a typical mobile network size, and figure out = what each > handset needs in storage and bandwidth to be a fully p2psip system. = My gut > tells me it works. >=20 > We're stuck with the NAT issue; there is no getting around that. >=20 > I'd like to have more discussion on the above. Do we really, truly = have to > worry about peers who can't store? Are we conflating the peers that = can't > accept inbound from the peers that can't store -- that is, do we = assume a > peer behind a NAT can't store? Is that an appropriate assumption? >=20 > What ARE the storage requirements we are talking about? Probably, = there is > a tradeoff between the size of the store and the bandwidth needed. Is that > actually relevant? >=20 > Brian >=20 > ________________________________________ > From: Greger V. Teigre [mailto:greger@teigre.com] > Sent: Friday, June 15, 2007 2:52 AM > To: Enrico Marocco > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts document: proposalfor active/passive > peerterminology >=20 > I'm struggling a bit with an underlying issue that seems to only be > implicitly addressed (or I confuse things up).=A0 To me it looks like = people > are talking about two different types of clients without not always > specifying explicitly when they talk about which. I think all agree = that the > "client" does not have full peer capabilities. However, such a client = can be > aware of the overlay (as in routing or having some storage capability) = and > as such participate in the overlay as a "lesser peer" or it can be ignorant > of the overlay, except that it knows that some entity offers GET/PUT. = So, it > needs to have a full peer, which acts as a "gateway" into the overlay. >=20 > So, a first decision would be to decide whether a "lesser peer" should = be > supported or if only access through a "gateway" should be allowed. A second > decision would be whether SIP should be used for communication between > client and "gateway peer" or some other client protocol. > g-) >=20 > Enrico Marocco wrote: > Spencer Dawkins wrote: >=20 > So - is this actually happening? Or are we trying to come up with a = name for > a concept we don't need/don't know WHY we need? >=20 > As far as I recall, the only credible use case which justifies the existence > of the "client" concept is that where a "non contributing" node wants = to > store/retrieve in the overlay something which can't be encoded in SIP > (REGISTER?) messages (e.g. public keys, VM records...). > Since such functionalities are not required to realize what the group = has > been chartered for (are they?) and perhaps they could be used in centralized > environments too, well... I personally hope that it _is_ happening and that > we get rid of "clients" before the next meeting. >=20 >=20 >=20 > ________________________________________ >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 18 00:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08t1-000307-4c; Mon, 18 Jun 2007 00:30:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08sz-0002zv-K1 for p2psip@ietf.org; Mon, 18 Jun 2007 00:30:41 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I08sx-0000v9-R0 for p2psip@ietf.org; Mon, 18 Jun 2007 00:30:41 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1165782ugf for ; Sun, 17 Jun 2007 21:30:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=RCUH8XFAn/yVMg7ymOzoekVqxGrZS0IbChsfHPRpRYrL34kq80fU+ewTi3/nW1fYSCQWV7eSYKXSQJatQZUBwYicEy/EBw56zTQ4ae0zbFda+r2tDw1H1SSKCm8VL3ai50tssfrMXBBprKYku/JL3MIjCwMnbkEa40ZUlbXNZjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EbWhlLubMHWyAIys9pF2d9wgwEqL0iWvWbez1sr6fwIkNDSUa1iQfqyPQwPh5uMhUD5QzVotQabEMamexMKtzcAzr9+C7i37+cXrvEVe+qkcrtjdQXARxVSq+Gyqm3pATBgBEwqcYeVLnjJ5FjaKo3E1yuWKu0z0sBnjGhnNWfw= Received: by 10.78.146.11 with SMTP id t11mr2099973hud.1182141039030; Sun, 17 Jun 2007 21:30:39 -0700 (PDT) Received: by 10.78.56.9 with HTTP; Sun, 17 Jun 2007 21:30:38 -0700 (PDT) Message-ID: <7b683f3f0706172130w44889957k30ae048d4ce092e3@mail.gmail.com> Date: Mon, 18 Jun 2007 00:30:38 -0400 From: "Eunsoo Shim" To: "Dean Willis" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: <467231F1.4080605@softarmor.com> MIME-Version: 1.0 References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1620956194==" Errors-To: p2psip-bounces@ietf.org --===============1620956194== Content-Type: multipart/alternative; boundary="----=_Part_61791_30021923.1182141038976" ------=_Part_61791_30021923.1182141038976 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline What Dean wrote in the initial email starting this thread has been what I thought. To put Henning's point in my way, the question is what we do if DNS is not available. For example, in a wireless ad-hoc network without connectivity to the Internet or DNS. How can alice@example.com talk to bob@example.net using p2psip if possible in such an environment? Even though I like the simplicity of 1:1 mapping between domain and overlay, such restriction does not look helpful in this case. So we'd better allow at least one overlay to support multiple domains (or allow nodes of multiple domains to participate in the same overlay). A node should be allowed to start a new overlay if it cannot discover any existing overlay it can use. This means a domain may split into multiple disconnected overlays. This is unavoidable if the nodes of the same domain are split into isolated networks. Then we would also need a mechanism to merge the nodes of the split domain into one overlay. This sounds somewhat scary. If we allow nodes to use only one "default" overlay in addition to their own "regular" overlay, things don't look so complex. Here the "regular" overlay means the overlay the nodes of the particular domain should try to participate in at their best (probably MUST if they have connectivity to the DNS). The "default" overlay means an overlay created and used whenever a node has no connectivity to the DNS. Thus nodes of any domain can participate in the "default" overlay. Since there can be many isolated networks, there may be many physically separated/disconnected "default" overlays. In this approach, a node will create or join its "regular" overlay if it has connectivity to the DNS. If not, then it will create or join a "default" overlay. That is, it won't create a new overlay that is limited to the node's own domain. This restriction removes my uncomfortable feeling about allowing nodes to create and participate in an arbitrary number of overlays or having a situation where there are many overlays for the same domain. Thanks. Eunsoo On 6/15/07, Dean Willis wrote: > > Brian Rosen wrote: > > Can we just forget clients for a sec? Alice has a full peer > implementation > > in the example.com domain. What is Alice's AoR (what is the scheme for > > example? How does another peer resolve that AoR to the protocol, IP > > address, etc. needed to create a session with Alice? Assume that peer > is > > very well connected and lives on multiple overlays, as well as several > > direct SIP C/S domains. > > > > I mean, if it's sip:alice@example.com, then the peer is going to do an > SRV > > lookup at example.com for a sip server and try C/S, right? RFC3263 > > > > Are you expecting that to fail? > > In my current worldview, if the peer knows it is participating in an > overlay that addresses the namespace "example.com", the peer looks up > Alice in its overlay. If not (or perhaps if the overlay lookup fails) it > fails, then the peer either does a 3263 resolution itself, or finds a > peer node offering "proxy service" to do the 3263 resolution for it. > > I believe Henning is implying a model where if the "local" overlay > fails, we then repeat the lookup operation using either the "meta" > overlay, or by asking a peer that does "meata proxy" to do it for us. > Said "meta" lookup might then revert to RFC 3263. > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_61791_30021923.1182141038976 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline What Dean wrote in the initial email starting this thread has been what I thought.
To put Henning's point in my way, the question is what we do if DNS is not available.
For example, in a wireless ad-hoc network without connectivity to the Internet or DNS.
How can alice@example.com talk to bob@example.net using p2psip if possible in such an environment?

Even though I like the simplicity of 1:1 mapping between domain and overlay, such restriction does not look helpful in this case. So we'd better allow at least one overlay to support multiple domains (or allow nodes of multiple domains to participate in the same overlay).

A node should be allowed to start a new overlay if it cannot discover any existing overlay it can use. This means a domain may split into multiple disconnected overlays. This is unavoidable if the nodes of the same domain are split into isolated networks. Then we would also need a mechanism to merge the nodes of the split domain into one overlay. This sounds somewhat scary.

If we allow nodes to use only one "default" overlay in addition to their own "regular" overlay, things don't look so complex.
Here the "regular" overlay means the overlay the nodes of the particular domain should try to participate in at their best (probably MUST if they have connectivity to the DNS).
The "default" overlay means an overlay created and used whenever a node has no connectivity to the DNS. Thus nodes of any domain can participate in the "default" overlay. Since there can be many isolated networks, there may be many physically separated/disconnected "default" overlays.

In this approach, a node will create or join its "regular" overlay if it has connectivity to the DNS. If not, then it will create or join a "default" overlay. That is, it won't create a new overlay that is limited to the node's own domain.

This restriction removes my uncomfortable feeling about allowing nodes to create and participate in an arbitrary number of overlays or having a situation where there are many overlays for the same domain.

Thanks.

Eunsoo

On 6/15/07, Dean Willis <dean.willis@softarmor.com> wrote:
Brian Rosen wrote:
> Can we just forget clients for a sec?  Alice has a full peer implementation
> in the example.com domain.  What is Alice's AoR (what is the scheme for
> example?  How does another peer resolve that AoR to the protocol, IP
> address, etc. needed to create a session with Alice?  Assume that peer is
> very well connected and lives on multiple overlays, as well as several
> direct SIP C/S domains.
>
> I mean, if it's sip:alice@example.com, then the peer is going to do an SRV
> lookup at example.com for a sip server and try C/S, right?  RFC3263
>
> Are you expecting that to fail?

In my current worldview, if the peer knows it is participating in an
overlay that addresses the namespace " example.com", the peer looks up
Alice in its overlay. If not (or perhaps if the overlay lookup fails) it
fails, then the peer either does a 3263 resolution itself, or finds a
peer node offering "proxy service" to do the 3263 resolution for it.

I believe Henning is implying a model where if the "local" overlay
fails, we then repeat the lookup operation using either the "meta"
overlay, or by asking a peer that does "meata proxy" to do it for us.
Said  "meta" lookup might then revert to RFC 3263.

--
Dean

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_61791_30021923.1182141038976-- --===============1620956194== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1620956194==-- From p2psip-bounces@ietf.org Mon Jun 18 07:05:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0F2z-0005P8-DT; Mon, 18 Jun 2007 07:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0F2x-0005P2-KD for p2psip@ietf.org; Mon, 18 Jun 2007 07:05:23 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0F2v-00042I-Fu for p2psip@ietf.org; Mon, 18 Jun 2007 07:05:23 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BDA9A206FF; Mon, 18 Jun 2007 13:05:20 +0200 (CEST) X-AuditID: c1b4fb3c-b067fbb0000007e1-ef-467666f04212 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9EBAC20410; Mon, 18 Jun 2007 13:05:20 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:05:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 13:05:19 +0200 Received: from [131.160.126.62] (rvi2-126-62.lmf.ericsson.se [131.160.126.62]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C21142715; Mon, 18 Jun 2007 14:05:19 +0300 (EEST) Message-ID: <467666F0.4050102@ericsson.com> Date: Mon, 18 Jun 2007 14:05:20 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 References: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> <1241F709-8FFC-4CB6-86BC-28A2FBB8A8D1@magma.ca> In-Reply-To: <1241F709-8FFC-4CB6-86BC-28A2FBB8A8D1@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2007 11:05:20.0042 (UTC) FILETIME=[8F4900A0:01C7B198] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, some comments on this draft (disclaimer: I read an earlier version of this document; some of my initial comments may have already been addressed in this version). In short, I like the concept of having a generic overlay; there has been work in the past to build HIP-based generic overlays (e.g., Hi3). Many readers will not be familiar with HIP. Thus, we would need to clarify a few fundamental concepts. The paper says that hosts can create HIs without accessing a central server. It would be good to clarify that this can be done when the hosts use opportunistic security (i.e., leap of faith). SIP people are familiar with that because of S/MIME; so, they will be able to draw a connection between SIP and HIP security. The draft claims that since HITs are "large enough", there are no collisions. I guess we should clarify that large HITs alone do not ensure that. That property also come from the fact that HITs are derived from HIs using a hash algorithm with low-collision properties. When talking about integrating HIP with existing applications and the fact that HITs look and feel like IPv6 addresses, it would be good to mention that there HIP WG is working on an API for HIP-aware applications and on how legacy applications (i.e., HIP-unaware applications) can use HIP. There are two drafts that we could reference in that context. We also need to talk about LSIs in the context of non-IPv6 applications. The paper is not clear on how a typical HIP connection looks like. We need to be clear that, after the initial four-way exchange, hosts exchange regular ESP-protected IP traffic. That is, the ESP-based security association between two hosts is a regular security association that even though was established by HIP, does not carry any HIP information. We should also say that, given that some applications do not want their traffic to be protected by ESP (e.g., applications using SRTP), there is work to support alternative protections. The draft talks about piggybacking regular traffic on HIP packets. Existing implementations do not support that. We should be aware that we would need to work on that a little more. The draft also talks about hop-by-hop routing. We have dome some work on HIP delegation in the past that could be used in such a context. In any case, we will need to work on it a little more as well, especially on the security implications. Cheers, Gonzalo Philip Matthews wrote: > Whoops! > It was just pointed out to me that I gave the wrong links in the e-mail > below. > > The correct links are: > Text version: > > http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip-hop-00.txt > HTML version: > > http://www.magma.ca/~philip_matthews/draft-matthews-p2psip-hip-hop-00.htm > > Sorry about that. > > - Philip > > PS. The links quoted in the original message were to the Concepts draft. > I recommend reading that one too! :-) > > > On 17-Jun-07, at 09:15 , Philip Matthews wrote: > >> Folks: >> >> Eric Cooper, Alan Johnston, and I have just written a draft that >> suggests what we think >> is an interesting direction for the P2PSIP working group. >> >> We argue that a P2PSIP overlay should use HIP (the Host Identity >> Protocol) >> to provide a number of the basic features in an overlay, namely: >> o Peer IDs; >> o Transporting messages around the overlay; >> o Signaling new overlay connections; >> o Supporting mobility and multi-homing of peers; >> o Providing message security. >> >> One of the reasons we really like this idea is because, using the >> approach >> described in the draft, many existing applications don't require any >> modifications >> and "just work" in an overlay. >> >> We describe this idea in a draft that has just been submitted. >> Until the draft appears in the archives, you can get a copy at >> http://www.magma.ca/~philip_matthews/draft-willis-p2psip-concepts-04.txt >> >> or for the html version >> http://www.magma.ca/~philip_matthews/draft-willis-p2psip-concepts-04.htm >> >> >> Here is the abstract from the draft: >> This document examines a P2PSIP architecture where the peer-to-peer >> (P2P) layer is separate from and lies below the SIP layer. We >> discuss the functions of the P2P layer in such an architecture, and >> focus in on the Distributed Transport function - the function that >> allows a peer to exchange messages with any other peer in the >> overlay, even in the presence of NATs. We list the features that the >> Distributed Transport function needs to provide, and observe that the >> Host Identity Protocol (HIP) already provides a number of these >> features. We then propose extensions to HIP that allow it to provide >> the missing features. We discuss how a complete P2PSIP architecture >> can be built around HIP, and contrast this approach with other >> approaches for implementing a P2P layer. Two of the advantages of >> HIP approach are that (a) most existing applications can run in an >> overlay without needing any changes and (b) peer mobility and NAT >> traversal are handled in a way that is transparent to most >> applications. >> >> - Philip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 18 10:32:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IHR-0004iA-W2; Mon, 18 Jun 2007 10:32:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0IHQ-0004hw-Lb for p2psip@ietf.org; Mon, 18 Jun 2007 10:32:32 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0IHP-0007Ry-6y for p2psip@ietf.org; Mon, 18 Jun 2007 10:32:32 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I0IHO-0007LY-Lo; Mon, 18 Jun 2007 10:32:30 -0400 In-Reply-To: <5E78BF77-E3A0-478B-9EC9-C291B62BFC49@softarmor.com> References: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com> <618e24240706171149scce75dbo404e9bcac883ba27@mail.gmail.com> <5E78BF77-E3A0-478B-9EC9-C291B62BFC49@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [P2PSIP] Pointer to sipsec draft Date: Mon, 18 Jun 2007 10:32:33 -0400 To: =?ISO-8859-1?Q?Victor_Pascual_=C1vila?= X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think that both are in scope in the sense that we have to figure =20 out mechanisms that work. It may be that the documents that standardize these mechanisms are =20 products of other working groups, but we need to select the mechanisms that we want, and be convinced =20 that they provide the security that we want. The SIPSEC solution is an example. This is a SIP WG item, and it was =20= created based on the situation that exists in Client-Server SIP. In P2PSIP, we can look at =20= it and decide if we want to go that route, or take a different path. - Philip On 17-Jun-07, at 18:04 , Dean Willis wrote: > > On Jun 17, 2007, at 1:49 PM, Victor Pascual =C1vila wrote: > >> Hello, >> >> On 15/06/07, Dean Willis wrote: >>> we will we need >>> a way to protect sensitive information that is traversing those =20 >>> proxies. >> >> Is signaling security in the scope of this WG? And media security? >> IMHO using security on signaling, media or both depends on using >> Stateless or Stateful proxies. > > I believe signaling security is clearly in scope, and that media =20 > security arguably is to the extent that we want to make sure our =20 > stuff works with the media security layers developed elsewhere, =20 > such as SRTP/DTLS and ZRTP. > > One of the big challenges we had to face in getting the group =20 > chartered was assuring people that the security issues of P2P =20 > systems could be resolved in an acceptable way. > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 18 11:26:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J79-0004uA-4a; Mon, 18 Jun 2007 11:25:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J77-0004u5-Pq for p2psip@ietf.org; Mon, 18 Jun 2007 11:25:57 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0J77-00047b-DI for p2psip@ietf.org; Mon, 18 Jun 2007 11:25:57 -0400 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l5IFPXZr026503; Mon, 18 Jun 2007 10:25:54 -0500 (CDT) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:25:53 -0500 Received: from DEEXC1U01.de.lucent.com ([135.248.187.27]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 17:25:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Pointer to sipsec draft Date: Mon, 18 Jun 2007 17:25:50 +0200 Message-ID: <5D1A7985295922448D5550C94DE2918001303510@DEEXC1U01.de.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Pointer to sipsec draft Thread-Index: AcextYhPXrswA7ZdSViQJ99S80MhDgABuALQ References: <36E290C0-552A-4E10-BB68-438CD59641AD@softarmor.com><618e24240706171149scce75dbo404e9bcac883ba27@mail.gmail.com><5E78BF77-E3A0-478B-9EC9-C291B62BFC49@softarmor.com> From: "DRAGE, Keith \(Keith\)" To: "Philip Matthews" , =?iso-8859-1?Q?Victor_Pascual_=C1vila?= X-OriginalArrivalTime: 18 Jun 2007 15:25:51.0203 (UTC) FILETIME=[F42EE330:01C7B1BC] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just to clarify that the sipsec draft is not yet a SIP WG item. It is = something SIP expects to look at and make a decision shortly. However you are entirely correct that P2PSIP should look at these things = and if necessary provide input to other groups. In particular the P2PSIP charter addressed this very point: "The work planned for the P2PSIP working group is distinct from, but requires close participation with other IETF WGs, particularly SIP, SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the=20 baseline SIP behavior, define a new version of SIP, or attempt to=20 produce a parallel protocol for session establishment. If the group=20 determines that any capabilities requiring an extension to SIP are=20 needed, the group will seek to define such extensions within the SIP=20 working group using the SIP change process (RFC 3427). Similarly,=20 existing tools developed in the BEHAVE and MMUSIC groups will be used=20 for NAT traversal, with extensions or changes desired to support P2PSIP presented to the BEHAVE or MMUSIC working groups." Regards Keith=20 > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 > Sent: Monday, June 18, 2007 3:33 PM > To: Victor Pascual =C1vila > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Pointer to sipsec draft >=20 > I think that both are in scope in the sense that we have to=20 > figure out mechanisms that work. > It may be that the documents that standardize these=20 > mechanisms are products of other working groups, but we need=20 > to select the mechanisms that we want, and be convinced that=20 > they provide the security that we want. >=20 > The SIPSEC solution is an example. This is a SIP WG item,=20 > and it was created based on the situation that exists in=20 > Client-Server SIP. In P2PSIP, we can look at it and decide if=20 > we want to go that route, or take a different path. >=20 > - Philip >=20 > On 17-Jun-07, at 18:04 , Dean Willis wrote: >=20 > > > > On Jun 17, 2007, at 1:49 PM, Victor Pascual =C1vila wrote: > > > >> Hello, > >> > >> On 15/06/07, Dean Willis wrote: > >>> we will we need > >>> a way to protect sensitive information that is traversing those=20 > >>> proxies. > >> > >> Is signaling security in the scope of this WG? And media security? > >> IMHO using security on signaling, media or both depends on using=20 > >> Stateless or Stateful proxies. > > > > I believe signaling security is clearly in scope, and that media=20 > > security arguably is to the extent that we want to make=20 > sure our stuff=20 > > works with the media security layers developed elsewhere, such as=20 > > SRTP/DTLS and ZRTP. > > > > One of the big challenges we had to face in getting the group=20 > > chartered was assuring people that the security issues of=20 > P2P systems=20 > > could be resolved in an acceptable way. > > > > -- > > Dean > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 18 12:23:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K0Z-0005JC-2A; Mon, 18 Jun 2007 12:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0K0X-0005Iu-Md for p2psip@ietf.org; Mon, 18 Jun 2007 12:23:13 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0K0V-0007bN-Vn for p2psip@ietf.org; Mon, 18 Jun 2007 12:23:13 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0K0V-0004XL-1s; Mon, 18 Jun 2007 12:23:11 -0400 In-Reply-To: <46758683.8050608@gmx.net> References: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> <46758683.8050608@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 Date: Mon, 18 Jun 2007 12:23:13 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hannes: Thanks for the references. From a quick read of your documents, it seems like they might form the basis of some extensions to our proposal. However, your document is talking about Client-Server SIP, while ours is talking about P2PSIP, and this seems to allow us to do things that you cannot do. For example, one of the things we like about our approach is that we can mostly hide the application the face that it is running in an overlay. In other words, we want to take existing applications that work in a non-overlay environment and make them work in a P2PSIP overlay without change. We are trying to do this by doing the HIP stuff behind existing APIs to the extent possible. We don't succeed in every case, but the degree to which we do succeed is interesting. - Philip On 17-Jun-07, at 15:07 , Hannes Tschofenig wrote: > Hi Phillip, > > you might also find these two documents of interest for you: > > Interaction between SIP and HIP > http://www.tschofenig.com/svn/draft-tschofenig-hiprg-host- > identities/draft-tschofenig-hiprg-host-identities-05.txt > > Using SRTP transport format with HIP > http://www.tschofenig.com/svn/draft-tschofenig-hiprg-hip-srtp/draft- > tschofenig-hiprg-hip-srtp-02.txt > > Ciao > Hannes > > Philip Matthews wrote: >> Folks: >> >> Eric Cooper, Alan Johnston, and I have just written a draft that >> suggests what we think >> is an interesting direction for the P2PSIP working group. >> >> We argue that a P2PSIP overlay should use HIP (the Host Identity >> Protocol) >> to provide a number of the basic features in an overlay, namely: >> o Peer IDs; >> o Transporting messages around the overlay; >> o Signaling new overlay connections; >> o Supporting mobility and multi-homing of peers; >> o Providing message security. >> >> One of the reasons we really like this idea is because, using the >> approach >> described in the draft, many existing applications don't require >> any modifications >> and "just work" in an overlay. >> >> We describe this idea in a draft that has just been submitted. >> Until the draft appears in the archives, you can get a copy at >> http://www.magma.ca/~philip_matthews/draft-willis-p2psip- >> concepts-04.txt >> or for the html version >> http://www.magma.ca/~philip_matthews/draft-willis-p2psip- >> concepts-04.htm >> >> Here is the abstract from the draft: >> This document examines a P2PSIP architecture where the peer-to- >> peer >> (P2P) layer is separate from and lies below the SIP layer. We >> discuss the functions of the P2P layer in such an architecture, >> and >> focus in on the Distributed Transport function - the function that >> allows a peer to exchange messages with any other peer in the >> overlay, even in the presence of NATs. We list the features >> that the >> Distributed Transport function needs to provide, and observe >> that the >> Host Identity Protocol (HIP) already provides a number of these >> features. We then propose extensions to HIP that allow it to >> provide >> the missing features. We discuss how a complete P2PSIP >> architecture >> can be built around HIP, and contrast this approach with other >> approaches for implementing a P2P layer. Two of the advantages of >> HIP approach are that (a) most existing applications can run in an >> overlay without needing any changes and (b) peer mobility and NAT >> traversal are handled in a way that is transparent to most >> applications. >> >> - Philip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 18 14:04:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Laf-0003ty-70; Mon, 18 Jun 2007 14:04:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Lae-0003qa-Mm for p2psip@ietf.org; Mon, 18 Jun 2007 14:04:36 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Lae-0000iO-6y for p2psip@ietf.org; Mon, 18 Jun 2007 14:04:36 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0LaS-0001j3-8b; Mon, 18 Jun 2007 13:04:24 -0500 From: "Brian Rosen" To: "'Dean Willis'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Mon, 18 Jun 2007 14:04:30 -0400 Message-ID: <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <467231F1.4080605@softarmor.com> Thread-Index: AcexzYt9w/0Nsbg/R0+9I9p5O8GPZAAAoCNA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Okay, so maybe there is a glimmer here I understand, but clearly not all. Let me ask this: can the domain of an AoR be in more than one overlay? If the answer is no, then maybe I see the way through the haze towards some kind of distributed database of domains in the DHT. If the answer is yes, then I hit brick walls. I'm still not really happy, because what I don't see is a definitive way to address a message to an arbitrary domain. With C/S, I can do that (3263). With p2psip, I really think I need to be able to do that. It seems hit or miss now. I also think that unless the number of domains in an overlay is small, that we have an intractable problem related to the above. In the extreme, there could be one domain per peer, or even worse, in which case the domain is meaningless. Is that the intention? Imagine a google service that offers to advertise your AoR, one at a time, on a proxy it runs. Just register with an AoR of your choice, and you're on the overlay. Domain doesn't matter, as long as the entire AoR is unique. Tens of millions of C/S clients on one proxy peer, with millions of domains, all resolving to one peer. Does that make sense? Then suppose Yahoo offers a competing service. Suppose you register with both (same AoR). Would that work? Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Friday, June 15, 2007 2:30 AM > To: Brian Rosen > Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > Brian Rosen wrote: > > Can we just forget clients for a sec? Alice has a full peer > implementation > > in the example.com domain. What is Alice's AoR (what is the scheme for > > example? How does another peer resolve that AoR to the protocol, IP > > address, etc. needed to create a session with Alice? Assume that peer > is > > very well connected and lives on multiple overlays, as well as several > > direct SIP C/S domains. > > > > I mean, if it's sip:alice@example.com, then the peer is going to do an > SRV > > lookup at example.com for a sip server and try C/S, right? RFC3263 > > > > Are you expecting that to fail? > > In my current worldview, if the peer knows it is participating in an > overlay that addresses the namespace "example.com", the peer looks up > Alice in its overlay. If not (or perhaps if the overlay lookup fails) it > fails, then the peer either does a 3263 resolution itself, or finds a > peer node offering "proxy service" to do the 3263 resolution for it. > > I believe Henning is implying a model where if the "local" overlay > fails, we then repeat the lookup operation using either the "meta" > overlay, or by asking a peer that does "meata proxy" to do it for us. > Said "meta" lookup might then revert to RFC 3263. > > -- > Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 18 14:05:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0LbX-0004wq-3n; Mon, 18 Jun 2007 14:05:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0LbV-0004ve-Os for p2psip@ietf.org; Mon, 18 Jun 2007 14:05:29 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0LbV-0000yz-CA for p2psip@ietf.org; Mon, 18 Jun 2007 14:05:29 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I0Lbd-0007uB-EX; Mon, 18 Jun 2007 14:05:37 -0400 In-Reply-To: <467666F0.4050102@ericsson.com> References: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> <1241F709-8FFC-4CB6-86BC-28A2FBB8A8D1@magma.ca> <467666F0.4050102@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <11944BE0-1E34-4BD0-8E08-FEEA1263E7D8@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 Date: Mon, 18 Jun 2007 14:05:32 -0400 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Gonzalo: May thanks for your comments. Replies inline. - Philip PS to others: The authors had asked Gonzalo, who is both a SIP expert as well as a HIP WG chair, to read and comment on an earlier version of the document. Unfortunately, he got locked away in a room in Brussels without Internet access for a while (is this inhuman torture, or what? :-) , and was unable to comment before we published. Thus some of his comments refer to things that got changed/ fixed in the published -00 version. On 18-Jun-07, at 07:05 , Gonzalo Camarillo wrote: > Hi, > > some comments on this draft (disclaimer: I read an earlier version > of this document; some of my initial comments may have already been > addressed in this version). > > In short, I like the concept of having a generic overlay; there has > been work in the past to build HIP-based generic overlays (e.g., Hi3). We are glad you like it. For the reasons we state in the draft, we now think a more generic approach is better as well. Others have been making similar comments on the P2PSIP list in the past few days. > > Many readers will not be familiar with HIP. Thus, we would need to > clarify a few fundamental concepts. The paper says that hosts can > create HIs without accessing a central server. It would be good to > clarify that this can be done when the hosts use opportunistic > security (i.e., leap of faith). SIP people are familiar with that > because of S/MIME; so, they will be able to draw a connection > between SIP and HIP security. The published -00 version says that Host Identities and HITs (= Peer IDs) might be allocated either (a) by a peer generating one on its own, or (b) by being allocated one from some external entity. The pros and cons of the two approaches need more investigation. > > The draft claims that since HITs are "large enough", there are no > collisions. I guess we should clarify that large HITs alone do not > ensure that. That property also come from the fact that HITs are > derived from HIs using a hash algorithm with low-collision properties. Yes, HITs (= Peer IDs) are generated from a SHA-1 hash of a Host Identity. This is similar to the way Chord generates peer IDs, and was one of the first things that got us thinking "Hmm ... HIP seems similar to P2PSIP". I think this is clearer now in the published -00 version, but will take a second look. > > When talking about integrating HIP with existing applications and > the fact that HITs look and feel like IPv6 addresses, it would be > good to mention that there HIP WG is working on an API for HIP- > aware applications and on how legacy applications (i.e., HIP- > unaware applications) can use HIP. There are two drafts that we > could reference in that context. We also need to talk about LSIs in > the context of non-IPv6 applications. Yes. we should add these in the next revision. To my mind, one of the exciting things about the proposal is that many existing applications don't need any changes to operate in an overlay. Thus the document on how legacy applications can use HIP is especially interesting. > > The paper is not clear on how a typical HIP connection looks like. > We need to be clear that, after the initial four-way exchange, > hosts exchange regular ESP-protected IP traffic. That is, the ESP- > based security association between two hosts is a regular security > association that even though was established by HIP, does not carry > any HIP information. We should also say that, given that some > applications do not want their traffic to be protected by ESP > (e.g., applications using SRTP), there is work to support > alternative protections. This is now discussed in much more detail. There is a section (5.4.2) that discusses both ESP transport and a proposal for an alternative transport for SRTP. > > The draft talks about piggybacking regular traffic on HIP packets. > Existing implementations do not support that. We should be aware > that we would need to work on that a little more. We see this happening only inside an overlay. Since the P2PSIP group controls these protocols, backwards compatibility is not a problem. > > The draft also talks about hop-by-hop routing. We have dome some > work on HIP delegation in the past that could be used in such a > context. In any case, we will need to work on it a little more as > well, especially on the security implications. There are two security issues here. One is the security of the HIP signaling messages when they go hop-by- hop. Here we think that the existing HIP mechanisms can be easily extended. The other is the security of data piggybacked on these packets. Here we think that TLS might be the appropriate approach. All this is discussed in section 5.5, which is new since the version you read. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 18 18:37:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Pql-0003IZ-2a; Mon, 18 Jun 2007 18:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0Pqj-0003IR-Ix for p2psip@ietf.org; Mon, 18 Jun 2007 18:37:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0Pqh-00073Q-LC for p2psip@ietf.org; Mon, 18 Jun 2007 18:37:29 -0400 Received: by ug-out-1314.google.com with SMTP id k3so1612238ugf for ; Mon, 18 Jun 2007 15:37:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aow4NrHr+2tMyciI9D2sxWOOPrrVepg2GjtwNREVrUMSaUOOV6dLge5NqEOdMGzNzCESoP4xpUb2eXOMMTR6YWy4Rl9BUv1iIUh0RMezqgXE1xkyelf0oqrarWJqnKdps/XZjT+l73d/Lon3u0oyJEqqdF+LjKgPdtEGgP8I6lI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uvK/gTEaGEm+RW8ficqJI9/oHfkoZZgC9g0BuYsl9goD7FxAf+CqK7kNHjbNbQAZQTIy27tYWR5p35e0lFEDVWz2KaWQHq6DAzWiMUUpFv87gD4SqcgGm1LusXfgwKDxs4GjLBhoFUP+9TPzQYpc2I8w9pXRPUwhGyklJvanc54= Received: by 10.78.204.7 with SMTP id b7mr2569913hug.1182206246531; Mon, 18 Jun 2007 15:37:26 -0700 (PDT) Received: by 10.78.56.9 with HTTP; Mon, 18 Jun 2007 15:37:26 -0700 (PDT) Message-ID: <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> Date: Mon, 18 Jun 2007 18:37:26 -0400 From: "Eunsoo Shim" To: "Brian Rosen" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> MIME-Version: 1.0 References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0840448110==" Errors-To: p2psip-bounces@ietf.org --===============0840448110== Content-Type: multipart/alternative; boundary="----=_Part_73227_24423531.1182206246472" ------=_Part_73227_24423531.1182206246472 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline My answers/comments are inline. On 6/18/07, Brian Rosen wrote: > > Okay, so maybe there is a glimmer here I understand, but clearly not all. > > Let me ask this: can the domain of an AoR be in more than one overlay? Yes. But there is a restriction. A node of an AoR should participate in its domain's "regular" overlay if possible. If not, it can participate in a "default" overlay. If the answer is no, then maybe I see the way through the haze towards some > kind of distributed database of domains in the DHT. If the answer is yes, > then I hit brick walls. > > I'm still not really happy, because what I don't see is a definitive way > to > address a message to an arbitrary domain. With C/S, I can do that (3263). > With p2psip, I really think I need to be able to do that. It seems hit or > miss now. I think the above restriction provides a definitive way to address a message to an arbitrary domain. If a node has connectivity to the DNS, it uses its local "regular" overlay (if the target domain is the same domain) or its local proxy that will use RFC3263. If a node has no connectivity to the DNS, it uses its local "default" overlay. Please notice that a node uses just one overlay in either case. There is no random poking into arbitrary overlays. I also think that unless the number of domains in an overlay is small, that > we have an intractable problem related to the above. I think the number of domains in an overlay does not matter. As long as you have a definitive way of mapping domain to overlay, you are fine. In the extreme, there > could be one domain per peer, or even worse, in which case the domain is > meaningless. With the proposed restriction, a node is allowed to create an overlay for its domain only when it does not have connectivity to the DNS and there is no existing "default" overlay. That is, it is the first node that wants to participate in P2PSIP in the isolated network. So in the world of P2PSIP I envision, there is one big "regular" overlay for a specific domain and many small "default" overlays where some of the nodes of the domain participate. Is that the intention? Imagine a google service that offers to advertise your AoR, one at a time, > on a proxy it runs. Just register with an AoR of your choice, and you're > on > the overlay. Domain doesn't matter, as long as the entire AoR is unique. This is not what I propose. If a node has connectivity to the DNS, it should participate in the overlay for the specific domain but not in the google overlay. Tens of millions of C/S clients on one proxy peer, with millions of domains, > all resolving to one peer. Does that make sense? > > Then suppose Yahoo offers a competing service. Suppose you register with > both (same AoR). Would that work? You are not going to register the AoR either in the google overlay or in the yahoo overlay. You will have to register the AoR in the overlay for the domain of the AoR. Thanks. Eunsoo > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Friday, June 15, 2007 2:30 AM > > To: Brian Rosen > > Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List' > > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > > > Brian Rosen wrote: > > > Can we just forget clients for a sec? Alice has a full peer > > implementation > > > in the example.com domain. What is Alice's AoR (what is the scheme > for > > > example? How does another peer resolve that AoR to the protocol, IP > > > address, etc. needed to create a session with Alice? Assume that peer > > is > > > very well connected and lives on multiple overlays, as well as several > > > direct SIP C/S domains. > > > > > > I mean, if it's sip:alice@example.com, then the peer is going to do an > > SRV > > > lookup at example.com for a sip server and try C/S, right? RFC3263 > > > > > > Are you expecting that to fail? > > > > In my current worldview, if the peer knows it is participating in an > > overlay that addresses the namespace "example.com", the peer looks up > > Alice in its overlay. If not (or perhaps if the overlay lookup fails) it > > fails, then the peer either does a 3263 resolution itself, or finds a > > peer node offering "proxy service" to do the 3263 resolution for it. > > > > I believe Henning is implying a model where if the "local" overlay > > fails, we then repeat the lookup operation using either the "meta" > > overlay, or by asking a peer that does "meata proxy" to do it for us. > > Said "meta" lookup might then revert to RFC 3263. > > > > -- > > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_73227_24423531.1182206246472 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline My answers/comments are inline.

On 6/18/07, Brian Rosen <br@brianrosen.net> wrote:
Okay, so maybe there is a glimmer here I understand, but clearly not all.

Let me ask this: can the domain of an AoR be in more than one overlay?

Yes.
But there is a restriction.
A node of an AoR should participate in its domain's "regular" overlay if possible.
If not, it can participate in a "default" overlay.

If the answer is no, then maybe I see the way through the haze towards some
kind of distributed database of domains in the DHT.  If the answer is yes,
then I hit brick walls.

I'm still not really happy, because what I don't see is a definitive way to
address a message to an arbitrary domain.  With C/S, I can do that (3263).
With p2psip, I really think I need to be able to do that.  It seems hit or
miss now.

I think the above restriction  provides a definitive way to address a message to an arbitrary domain. If a node has connectivity to the DNS, it uses its local "regular" overlay (if the target domain is the same domain) or its local proxy that will use RFC3263. If a node has no connectivity to the DNS, it uses its local "default" overlay. Please notice that a node uses just one overlay in either case. There is no random poking into arbitrary overlays.

I also think that unless the number of domains in an overlay is small, that
we have an intractable problem related to the above. 

I think the number of domains in an overlay does not matter. As long as you have a definitive way of mapping domain to overlay, you are fine.

 In the extreme, there
could be one domain per peer, or even worse, in which case the domain is
meaningless. 

With the proposed restriction, a node is allowed to create an overlay for its domain only when it does not have connectivity to the DNS and there is no existing "default" overlay. That is, it is the first node that wants to participate in P2PSIP in the isolated network.

So in the world of P2PSIP I envision, there is one big "regular" overlay for a specific domain and many small "default" overlays where some of the nodes of the domain participate.

 Is that the intention?



Imagine a google service that offers to advertise your AoR, one at a time,
on a proxy it runs.  Just register with an AoR of your choice, and you're on
the overlay.  Domain doesn't matter, as long as the entire AoR is unique.

This is not what I propose. If a node has connectivity to the DNS, it should participate in the overlay for the specific domain but not in the google overlay.

Tens of millions of C/S clients on one proxy peer, with millions of domains,
all resolving to one peer.  Does that make sense?

Then suppose Yahoo offers a competing service.  Suppose you register with
both (same AoR).  Would that work?

You are not going to register the AoR either in the google overlay or in the yahoo overlay. You will have to register the AoR in the overlay for the domain of the AoR.


Thanks.

Eunsoo

> -----Original Message-----
> From: Dean Willis [mailto: dean.willis@softarmor.com]
> Sent: Friday, June 15, 2007 2:30 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays
>
> Brian Rosen wrote:
> > Can we just forget clients for a sec?  Alice has a full peer
> implementation
> > in the example.com domain.  What is Alice's AoR (what is the scheme for
> > example?  How does another peer resolve that AoR to the protocol, IP
> > address, etc. needed to create a session with Alice?  Assume that peer
> is
> > very well connected and lives on multiple overlays, as well as several
> > direct SIP C/S domains.
> >
> > I mean, if it's sip:alice@example.com, then the peer is going to do an
> SRV
> > lookup at example.com for a sip server and try C/S, right?  RFC3263
> >
> > Are you expecting that to fail?
>
> In my current worldview, if the peer knows it is participating in an
> overlay that addresses the namespace " example.com", the peer looks up
> Alice in its overlay. If not (or perhaps if the overlay lookup fails) it
> fails, then the peer either does a 3263 resolution itself, or finds a
> peer node offering "proxy service" to do the 3263 resolution for it.
>
> I believe Henning is implying a model where if the "local" overlay
> fails, we then repeat the lookup operation using either the "meta"
> overlay, or by asking a peer that does "meata proxy" to do it for us.
> Said  "meta" lookup might then revert to RFC 3263.
>
> --
> Dean


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_73227_24423531.1182206246472-- --===============0840448110== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0840448110==-- From p2psip-bounces@ietf.org Tue Jun 19 00:34:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VQQ-00083W-JK; Tue, 19 Jun 2007 00:34:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0VQP-00083R-3p for p2psip@ietf.org; Tue, 19 Jun 2007 00:34:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0VQO-0006jy-7j for p2psip@ietf.org; Tue, 19 Jun 2007 00:34:41 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I0VQN-0000va-8s; Mon, 18 Jun 2007 23:34:39 -0500 In-Reply-To: <107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> References: <7730A258-ECB0-442D-AF82-12134DAFC0FA@cs.columbia.edu> <20d2bdfb0703210256k6b68a2d5k6b94e16194130348@mail.gmail.com> <4d4304a00703210357h30bb0f9bp7e8dd47e4cb14a48@mail.gmail.com> <107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <64DD17B3-7124-41BA-9509-540091AD0AD5@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Roles Date: Mon, 18 Jun 2007 23:34:21 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Philip Matthews , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Mar 22, 2007, at 8:51 AM, Henning Schulzrinne wrote: > The notion of separation is that of making a decision and providing > a token. I used the bouncer model intentionally: The bouncer checks > your driver's license and makes sure that you are of legal age and > that you aren't on the establishment's black lists of unwanted > guests, and then stamps your palm. The bar tender "admits" you to > the bar by checking the stamp. In a P2P sense, the admission > function may check a node's reputation, consult black lists, > perform return routability checks, CAPTCHA/turing tests and other > checks, and then hands a token, such as a signature, verifying that > the new node has passed these tests. Naturally, we wouldn't specify > any of the details of the tests, but they are separable. I'm struggling with integrating this into the concepts document. As I see it, the "enrollment" process provides the token. Once you've enrolled, you have a a set of credentials that can be checked by any of the "bouncers" (aka admitting peers) and by any of the service providing peers (aka "bartenders") from whom you might request service. I think this model is quite completely provided for in the current draft of the concepts model. So what am I missing? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 03:54:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0YXz-0001AN-73; Tue, 19 Jun 2007 03:54:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0YXy-0001AH-9d for p2psip@ietf.org; Tue, 19 Jun 2007 03:54:42 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0YXt-0004lW-7V for p2psip@ietf.org; Tue, 19 Jun 2007 03:54:41 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5J7YuAk020938; Tue, 19 Jun 2007 09:34:57 +0200 Message-ID: <46778BAE.5010504@teigre.com> Date: Tue, 19 Jun 2007 09:54:22 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Eunsoo Shim Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> In-Reply-To: <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0966879078==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0966879078== Content-Type: multipart/alternative; boundary="------------000909050404030508040601" This is a multi-part message in MIME format. --------------000909050404030508040601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit We have two choices as I see it: 1. Is the AoR supposed to be the equivalent of an email address where the whole domain must handled authoritatively by one entity, here overlay (which allows 3263 lookups) ? 2. Or is the AoR supposed to be the equivalent of "use your email address as username on my website"? If #1 is true, we can use language as the "AoR's default overlay". However, if #2 is true, a default overlay has no meaning. We must always identify the overlay as well. So, the AoR has turned from my@mycompany.com to me@mycompany.com@googlesoverlay (ref. Brian's example. I don't think we are able to do #1 and #2 at the same time. If we go for #1, we follow the Internet-model for authoritative domain handling. This means that I need several AoRs, one for each overlay I want to participate in. me@gmail.com, me@yahoo.com, and so on. Is this a problem? I have a feeling that some people really would like to create some universal id (AoR) that can be used across overlays and will have meaning regardless of which overlay(s) the AoR is connected to. The reality is that most people are used to having several email addresses, and I don't think they will have a problem with having several AoRs. g-) Eunsoo Shim wrote: > My answers/comments are inline. > > On 6/18/07, *Brian Rosen* > wrote: > > Okay, so maybe there is a glimmer here I understand, but clearly > not all. > > Let me ask this: can the domain of an AoR be in more than one overlay? > > > Yes. > But there is a restriction. > A node of an AoR should participate in its domain's "regular" overlay > if possible. > If not, it can participate in a "default" overlay. > > If the answer is no, then maybe I see the way through the haze > towards some > kind of distributed database of domains in the DHT. If the answer > is yes, > then I hit brick walls. > > I'm still not really happy, because what I don't see is a > definitive way to > address a message to an arbitrary domain. With C/S, I can do that > (3263). > With p2psip, I really think I need to be able to do that. It > seems hit or > miss now. > > > I think the above restriction provides a definitive way to address a > message to an arbitrary domain. If a node has connectivity to the DNS, > it uses its local "regular" overlay (if the target domain is the same > domain) or its local proxy that will use RFC3263. If a node has no > connectivity to the DNS, it uses its local "default" overlay. Please > notice that a node uses just one overlay in either case. There is no > random poking into arbitrary overlays. > > I also think that unless the number of domains in an overlay is > small, that > we have an intractable problem related to the above. > > > I think the number of domains in an overlay does not matter. As long > as you have a definitive way of mapping domain to overlay, you are fine. > > In the extreme, there > could be one domain per peer, or even worse, in which case the > domain is > meaningless. > > > With the proposed restriction, a node is allowed to create an overlay > for its domain only when it does not have connectivity to the DNS and > there is no existing "default" overlay. That is, it is the first node > that wants to participate in P2PSIP in the isolated network. > > So in the world of P2PSIP I envision, there is one big "regular" > overlay for a specific domain and many small "default" overlays where > some of the nodes of the domain participate. > > Is that the intention? > > > > > Imagine a google service that offers to advertise your AoR, one at > a time, > on a proxy it runs. Just register with an AoR of your choice, and > you're on > the overlay. Domain doesn't matter, as long as the entire AoR is > unique. > > > This is not what I propose. If a node has connectivity to the DNS, it > should participate in the overlay for the specific domain but not in > the google overlay. > > Tens of millions of C/S clients on one proxy peer, with millions > of domains, > all resolving to one peer. Does that make sense? > > Then suppose Yahoo offers a competing service. Suppose you > register with > both (same AoR). Would that work? > > > You are not going to register the AoR either in the google overlay or > in the yahoo overlay. You will have to register the AoR in the overlay > for the domain of the AoR. > > > Thanks. > > Eunsoo > > > -----Original Message----- > > From: Dean Willis [mailto: dean.willis@softarmor.com > ] > > Sent: Friday, June 15, 2007 2:30 AM > > To: Brian Rosen > > Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List' > > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > > > Brian Rosen wrote: > > > Can we just forget clients for a sec? Alice has a full peer > > implementation > > > in the example.com domain. What is > Alice's AoR (what is the scheme for > > > example? How does another peer resolve that AoR to the > protocol, IP > > > address, etc. needed to create a session with Alice? Assume > that peer > > is > > > very well connected and lives on multiple overlays, as well as > several > > > direct SIP C/S domains. > > > > > > I mean, if it's sip:alice@example.com > , then the peer is going to do an > > SRV > > > lookup at example.com for a sip server > and try C/S, right? RFC3263 > > > > > > Are you expecting that to fail? > > > > In my current worldview, if the peer knows it is participating in an > > overlay that addresses the namespace " example.com > ", the peer looks up > > Alice in its overlay. If not (or perhaps if the overlay lookup > fails) it > > fails, then the peer either does a 3263 resolution itself, or > finds a > > peer node offering "proxy service" to do the 3263 resolution for it. > > > > I believe Henning is implying a model where if the "local" overlay > > fails, we then repeat the lookup operation using either the "meta" > > overlay, or by asking a peer that does "meata proxy" to do it > for us. > > Said "meta" lookup might then revert to RFC 3263. > > > > -- > > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --------------000909050404030508040601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We have two choices as I see it:

1. Is the AoR supposed to be the equivalent of an email address where the whole domain must handled authoritatively by one entity, here overlay (which allows 3263 lookups) ?

2. Or is the AoR supposed to be the equivalent of "use your email address as username on my website"?

If #1 is true, we can use language as the "AoR's default overlay". However, if #2 is true, a default overlay has no meaning. We must always identify the overlay as well.  So, the AoR has turned from my@mycompany.com to me@mycompany.com@googlesoverlay (ref. Brian's example.

I don't think we are able to do #1 and #2 at the same time.  If we go for #1, we follow the Internet-model for authoritative domain handling. This means that I need several AoRs, one for each overlay I want to participate in. me@gmail.com, me@yahoo.com, and so on. Is this a problem? 

I have a feeling that some people really would like to create some universal id (AoR) that can be used across overlays and will have meaning regardless of which overlay(s) the AoR is connected to. The reality is that most people are used to having several email addresses, and I don't think they will have a problem with having several AoRs.
g-)


Eunsoo Shim wrote:
My answers/comments are inline.

On 6/18/07, Brian Rosen <br@brianrosen.net> wrote:
Okay, so maybe there is a glimmer here I understand, but clearly not all.

Let me ask this: can the domain of an AoR be in more than one overlay?

Yes.
But there is a restriction.
A node of an AoR should participate in its domain's "regular" overlay if possible.
If not, it can participate in a "default" overlay.

If the answer is no, then maybe I see the way through the haze towards some
kind of distributed database of domains in the DHT.  If the answer is yes,
then I hit brick walls.

I'm still not really happy, because what I don't see is a definitive way to
address a message to an arbitrary domain.  With C/S, I can do that (3263).
With p2psip, I really think I need to be able to do that.  It seems hit or
miss now.

I think the above restriction  provides a definitive way to address a message to an arbitrary domain. If a node has connectivity to the DNS, it uses its local "regular" overlay (if the target domain is the same domain) or its local proxy that will use RFC3263. If a node has no connectivity to the DNS, it uses its local "default" overlay. Please notice that a node uses just one overlay in either case. There is no random poking into arbitrary overlays.

I also think that unless the number of domains in an overlay is small, that
we have an intractable problem related to the above. 

I think the number of domains in an overlay does not matter. As long as you have a definitive way of mapping domain to overlay, you are fine.

 In the extreme, there
could be one domain per peer, or even worse, in which case the domain is
meaningless. 

With the proposed restriction, a node is allowed to create an overlay for its domain only when it does not have connectivity to the DNS and there is no existing "default" overlay. That is, it is the first node that wants to participate in P2PSIP in the isolated network.

So in the world of P2PSIP I envision, there is one big "regular" overlay for a specific domain and many small "default" overlays where some of the nodes of the domain participate.

 Is that the intention?



Imagine a google service that offers to advertise your AoR, one at a time,
on a proxy it runs.  Just register with an AoR of your choice, and you're on
the overlay.  Domain doesn't matter, as long as the entire AoR is unique.

This is not what I propose. If a node has connectivity to the DNS, it should participate in the overlay for the specific domain but not in the google overlay.

Tens of millions of C/S clients on one proxy peer, with millions of domains,
all resolving to one peer.  Does that make sense?

Then suppose Yahoo offers a competing service.  Suppose you register with
both (same AoR).  Would that work?

You are not going to register the AoR either in the google overlay or in the yahoo overlay. You will have to register the AoR in the overlay for the domain of the AoR.


Thanks.

Eunsoo

> -----Original Message-----
> From: Dean Willis [mailto: dean.willis@softarmor.com]
> Sent: Friday, June 15, 2007 2:30 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays
>
> Brian Rosen wrote:
> > Can we just forget clients for a sec?  Alice has a full peer
> implementation
> > in the example.com domain.  What is Alice's AoR (what is the scheme for
> > example?  How does another peer resolve that AoR to the protocol, IP
> > address, etc. needed to create a session with Alice?  Assume that peer
> is
> > very well connected and lives on multiple overlays, as well as several
> > direct SIP C/S domains.
> >
> > I mean, if it's sip:alice@example.com, then the peer is going to do an
> SRV
> > lookup at example.com for a sip server and try C/S, right?  RFC3263
> >
> > Are you expecting that to fail?
>
> In my current worldview, if the peer knows it is participating in an
> overlay that addresses the namespace " example.com", the peer looks up
> Alice in its overlay. If not (or perhaps if the overlay lookup fails) it
> fails, then the peer either does a 3263 resolution itself, or finds a
> peer node offering "proxy service" to do the 3263 resolution for it.
>
> I believe Henning is implying a model where if the "local" overlay
> fails, we then repeat the lookup operation using either the "meta"
> overlay, or by asking a peer that does "meata proxy" to do it for us.
> Said  "meta" lookup might then revert to RFC 3263.
>
> --
> Dean


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--------------000909050404030508040601-- --===============0966879078== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0966879078==-- From p2psip-bounces@ietf.org Tue Jun 19 08:15:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cc1-0000kv-ES; Tue, 19 Jun 2007 08:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0cbz-0000bN-0w for p2psip@ietf.org; Tue, 19 Jun 2007 08:15:07 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0cbx-00081k-KP for p2psip@ietf.org; Tue, 19 Jun 2007 08:15:07 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 14:14:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 19 Jun 2007 14:15:02 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B0059E2A88@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt Thread-Index: AceyKy7wEepkh7cSQXqN62igWefM/gAP5MPQ References: <7730A258-ECB0-442D-AF82-12134DAFC0FA@cs.columbia.edu><20d2bdfb0703210256k6b68a2d5k6b94e16194130348@mail.gmail.com><4d4304a00703210357h30bb0f9bp7e8dd47e4cb14a48@mail.gmail.com><107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> <64DD17B3-7124-41BA-9509-540091AD0AD5@softarmor.com> From: "BOUCADAIR Mohamed RD-CORE-CAE" To: X-OriginalArrivalTime: 19 Jun 2007 12:14:52.0087 (UTC) FILETIME=[706E4C70:01C7B26B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear authors, Below some comments about your draft: 1- The design goal of XPP have already been tackled in IAX specification protocol. Please refer to http://tools.ietf.org/id/draft-guy-iax-03.txt In order to avoid redundant work. IAX solves the problem of NAT traversal in a native way. It is also a binary protocol which implements reliability means because it is built upon UDP. Perhaps not all of IAX features are required in the context of P2P.. 2- If XPP supports means for NAT traversal why then you need ICE and STUN? If this is required, I don't understand the motivation for this specification.=20 3- You state in section 1.2 "P2PP has many things in common with XPP; mainly, it is binary and uses a very similar encoding for parameters based on type-length-value (TLV) fields. However, it misses a mechanism for simultaneously initiating sessions, which is one of XPP's most important features" Why not proposing that enhancement to authors of P2PP instead of specifying a new protocol? Cheers, Med _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 08:50:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0d9o-0007rq-QQ; Tue, 19 Jun 2007 08:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0d9o-0007ri-4s for p2psip@ietf.org; Tue, 19 Jun 2007 08:50:04 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0d9n-0006YQ-N6 for p2psip@ietf.org; Tue, 19 Jun 2007 08:50:04 -0400 Received: (qmail 8038 invoked for bounce); 19 Jun 2007 14:52:15 -0000 Received: from unknown (HELO ?130.79.90.87?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 19 Jun 2007 14:52:15 -0000 Message-ID: <4677D0F9.7020609@sip-communicator.org> Date: Tue, 19 Jun 2007 14:50:01 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: BOUCADAIR Mohamed RD-CORE-CAE Subject: Re: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt References: <7730A258-ECB0-442D-AF82-12134DAFC0FA@cs.columbia.edu><20d2bdfb0703210256k6b68a2d5k6b94e16194130348@mail.gmail.com><4d4304a00703210357h30bb0f9bp7e8dd47e4cb14a48@mail.gmail.com><107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> <64DD17B3-7124-41BA-9509-540091AD0AD5@softarmor.com> <6CF039C5B32037498B02251E11CDE6B0059E2A88@ftrdmel3.rd.francetelecom.fr> In-Reply-To: <6CF039C5B32037498B02251E11CDE6B0059E2A88@ftrdmel3.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello Mohamed (comments inline) BOUCADAIR Mohamed RD-CORE-CAE wrote: > Dear authors, > > Below some comments about your draft: > > 1- The design goal of XPP have already been tackled in IAX specification > protocol. Please refer to http://tools.ietf.org/id/draft-guy-iax-03.txt > In order to avoid redundant work. IAX solves the problem of NAT > traversal in a native way. Well not exactly. IAX handles both signaling and media transport which means that it doesn't need to take care of dynamic NAT bindings. In other words it doesn't really have the problem of NAT traversal. > It is also a binary protocol which implements > reliability means because it is built upon UDP. Perhaps not all of IAX > features are required in the context of P2P.. Thanks for the pointer. It might indeed be useful to borrow inspiration from IAX when dealing with transport problems that they have resolved. We'll keep this in mind. > 2- If XPP supports means for NAT traversal why then you need ICE and > STUN? If this is required, I don't understand the motivation for this > specification. ICE and STUN *are* the means that can be used during XPP session negotiation to handle NAT traversal. XPP alone is simply being friendly to such mechanisms as it allows for simultaneous session establishment. > 3- You state in section 1.2 "P2PP has many things in common with XPP; > mainly, it > is binary and uses a very similar encoding for parameters based on > type-length-value (TLV) fields. However, it misses a mechanism for > simultaneously initiating sessions, which is one of XPP's most > important features" > > Why not proposing that enhancement to authors of P2PP instead of > specifying a new protocol? Well actually, XPP is the outcome of the sipdht2 project (http://sipdht.sourceforge.net/sipdht2/). When we started sipdht2 p2pp was still in an early stage (it was called p2p-common at the time) so this explains the initial split. Both protocols have many similarities and they also have a few differences. Anyway, I agree that this is a reasonable suggestion so we are definitely interested in further discussing a possible synergy. Cheers Emil > > Cheers, > Med > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 09:04:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dNH-0007hZ-IN; Tue, 19 Jun 2007 09:03:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dNE-0007hF-S9 for p2psip@ietf.org; Tue, 19 Jun 2007 09:03:56 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0dNE-0001rE-E0 for p2psip@ietf.org; Tue, 19 Jun 2007 09:03:56 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 15:03:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt Date: Tue, 19 Jun 2007 15:03:48 +0200 Message-ID: <6CF039C5B32037498B02251E11CDE6B0059E2B26@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt Thread-Index: AceycFrgLn1JjIzHTNSlscP7jr6z/wAATW+g References: <7730A258-ECB0-442D-AF82-12134DAFC0FA@cs.columbia.edu><20d2bdfb0703210256k6b68a2d5k6b94e16194130348@mail.gmail.com><4d4304a00703210357h30bb0f9bp7e8dd47e4cb14a48@mail.gmail.com><107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> <64DD17B3-7124-41BA-9509-540091AD0AD5@softarmor.com> <6CF039C5B32037498B02251E11CDE6B0059E2A88@ftrdmel3.rd.francetelecom.fr> <4677D0F9.7020609@sip-communicator.org> From: "BOUCADAIR Mohamed RD-CORE-CAE" To: "Emil Ivov" X-OriginalArrivalTime: 19 Jun 2007 13:03:50.0300 (UTC) FILETIME=[47BE05C0:01C7B272] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Thanks for your answers. Just some clarifications regarding IAX, the NAT problem is avoided = thanks to the following design choices: - usage of a single UDP port (just like HTTP) - Utilisation of application-based identifiers to uniquely distinguish = sessions - IAX does not carry any IP addresses inside its messages - Once registration message is issued by a client, the server (or the = remote peer) uses the source information to reply. The answer will be = delivered whatever the type of intermediate NAT. Cheers, Med =20 -----Message d'origine----- De : Emil Ivov [mailto:emcho@sip-communicator.org]=20 Envoy=E9 : mardi 19 juin 2007 14:50 =C0 : BOUCADAIR Mohamed RD-CORE-CAE Cc : p2psip@ietf.org Objet : Re: [P2PSIP] COMMENTS on I-D = ACTION:draft-marocco-p2psip-xpp-00.txt Hello Mohamed (comments inline) BOUCADAIR Mohamed RD-CORE-CAE wrote: > Dear authors, >=20 > Below some comments about your draft: >=20 > 1- The design goal of XPP have already been tackled in IAX=20 > specification protocol. Please refer to=20 > http://tools.ietf.org/id/draft-guy-iax-03.txt > In order to avoid redundant work. IAX solves the problem of NAT=20 > traversal in a native way. Well not exactly. IAX handles both signaling and media transport which = means that it doesn't need to take care of dynamic NAT bindings.=20 In other words it doesn't really have the problem of NAT traversal. > It is also a binary protocol which implements reliability means=20 > because it is built upon UDP. Perhaps not all of IAX features are=20 > required in the context of P2P.. Thanks for the pointer. It might indeed be useful to borrow inspiration = from IAX when dealing with transport problems that they have resolved.=20 We'll keep this in mind. > 2- If XPP supports means for NAT traversal why then you need ICE and=20 > STUN? If this is required, I don't understand the motivation for this=20 > specification. ICE and STUN *are* the means that can be used during XPP session = negotiation to handle NAT traversal. XPP alone is simply being friendly = to such mechanisms as it allows for simultaneous session establishment. > 3- You state in section 1.2 "P2PP has many things in common with XPP;=20 > mainly, it > is binary and uses a very similar encoding for parameters based on > type-length-value (TLV) fields. However, it misses a mechanism for > simultaneously initiating sessions, which is one of XPP's most > important features" >=20 > Why not proposing that enhancement to authors of P2PP instead of=20 > specifying a new protocol? Well actually, XPP is the outcome of the sipdht2 project = (http://sipdht.sourceforge.net/sipdht2/). When we started sipdht2 p2pp = was still in an early stage (it was called p2p-common at the time) so = this explains the initial split. Both protocols have many similarities = and they also have a few differences. Anyway, I agree that this is a = reasonable suggestion so we are definitely interested in further = discussing a possible synergy. Cheers Emil >=20 > Cheers, > Med >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 09:40:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dwU-0007U6-UX; Tue, 19 Jun 2007 09:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0dwT-0007U0-Jy for p2psip@ietf.org; Tue, 19 Jun 2007 09:40:21 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0dwS-0004W0-At for p2psip@ietf.org; Tue, 19 Jun 2007 09:40:21 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I0dwR-0007kc-M1; Tue, 19 Jun 2007 09:40:19 -0400 In-Reply-To: <6CF039C5B32037498B02251E11CDE6B0059E2B26@ftrdmel3.rd.francetelecom.fr> References: <7730A258-ECB0-442D-AF82-12134DAFC0FA@cs.columbia.edu><20d2bdfb0703210256k6b68a2d5k6b94e16194130348@mail.gmail.com><4d4304a00703210357h30bb0f9bp7e8dd47e4cb14a48@mail.gmail.com><107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> <64DD17B3-7124-41BA-9509-540091AD0AD5@softarmor.com> <6CF039C5B32037498B02251E11CDE6B0059E2A88@ftrdmel3.rd.francetelecom.fr> <4677D0F9.7020609@sip-communicator.org> <6CF039C5B32037498B02251E11CDE6B0059E2B26@ftrdmel3.rd.francetelecom.fr> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89670105-6F7F-4AED-BE01-C890187FA88F@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt Date: Tue, 19 Jun 2007 09:40:17 -0400 To: BOUCADAIR Mohamed RD-CORE-CAE X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 19-Jun-07, at 09:03 , BOUCADAIR Mohamed RD-CORE-CAE wrote: > Thanks for your answers. > > > Just some clarifications regarding IAX, the NAT problem is avoided > thanks to the following design choices: > > - usage of a single UDP port (just like HTTP) > - Utilisation of application-based identifiers to uniquely > distinguish sessions > - IAX does not carry any IP addresses inside its messages > - Once registration message is issued by a client, the server (or > the remote peer) uses the source information to reply. The answer > will be delivered whatever the type of intermediate NAT. > > Cheers, > Med I would just like to point out that first three of these design choice, though good, do not allow IAX or any other protocol to avoid the NAT traversal problem. They simply get rid of extra distractions. Regarding the fourth, I don't understand this one. It sounds like the media flows via a proxy, but I cannot believe this. However, I will point out that there are two general choices. Either (a) the media has to flow via the proxy, or (b) the endpoints have to do UDP hole punching (using a protocol like ICE) to get the media to flow directly between the two peers. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 11:00:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fBl-0004px-BO; Tue, 19 Jun 2007 11:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0fBj-0004pp-Im for p2psip@ietf.org; Tue, 19 Jun 2007 11:00:11 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0fBg-0001ur-BU for p2psip@ietf.org; Tue, 19 Jun 2007 11:00:11 -0400 Received: by ug-out-1314.google.com with SMTP id k3so281138ugf for ; Tue, 19 Jun 2007 08:00:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=QoGJzOD1+t0M9ZbchOrnsuuHcWuQty8Ol0IG2pUXUyIYnxBNWusN5uQ8287eWguGAydnYBfo0jGmdETPYO6p0Y8kfOAyJ41wdcsC+cpHFCFHibBsOTf739FZ1/Va7u3dKCIP/9V8UPL64Nc9emJ1v3IyXpyS6oWhlSXHj1T8Awo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hgDQEZZmVciaTtwvT0mlUaIoSMxANhheik+mkISDsmO1GmkeiBTkAtqY7RMQOSNHiRGAEOszmUI/Y0hBOO/njrZKCaw5bXUKZU4h3kxjSPRLn6pvNB3IWWUeWkkMqaw6e32XacoRDdxOM/gV+R0Ebvx39/lgnWv6UhROGXn5pew= Received: by 10.78.159.7 with SMTP id h7mr2927577hue.1182265203778; Tue, 19 Jun 2007 08:00:03 -0700 (PDT) Received: by 10.78.56.9 with HTTP; Tue, 19 Jun 2007 08:00:03 -0700 (PDT) Message-ID: <7b683f3f0706190800n597ca85fm163182c336a46a16@mail.gmail.com> Date: Tue, 19 Jun 2007 11:00:03 -0400 From: "Eunsoo Shim" To: "Greger V. Teigre" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: <46778BAE.5010504@teigre.com> MIME-Version: 1.0 References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> <46778BAE.5010504@teigre.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1009268825==" Errors-To: p2psip-bounces@ietf.org --===============1009268825== Content-Type: multipart/alternative; boundary="----=_Part_80779_22168708.1182265203671" ------=_Part_80779_22168708.1182265203671 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline A good summary. I support #1. That's a simple way to support interoperation with C/S SIP. me@mycompany.com@overlay_1 is just another URI. If we do that, someone cannot print me@mycompany.com on her name card but should print me@mycompany.com@overlay_1, me@mycompany.overlay_2, and so on. overlay_1 and overlay_2 are just another domains. nothing much changes. Thanks. Charlie On 6/19/07, Greger V. Teigre wrote: > > We have two choices as I see it: > > 1. Is the AoR supposed to be the equivalent of an email address where the > whole domain must handled authoritatively by one entity, here overlay (which > allows 3263 lookups) ? > > 2. Or is the AoR supposed to be the equivalent of "use your email address > as username on my website"? > > If #1 is true, we can use language as the "AoR's default overlay". > However, if #2 is true, a default overlay has no meaning. We must always > identify the overlay as well. So, the AoR has turned from > my@mycompany.com to me@mycompany.com@googlesoverlay (ref. Brian's example. > > I don't think we are able to do #1 and #2 at the same time. If we go for > #1, we follow the Internet-model for authoritative domain handling. This > means that I need several AoRs, one for each overlay I want to participate > in. me@gmail.com, me@yahoo.com, and so on. Is this a problem? > > I have a feeling that some people really would like to create some > universal id (AoR) that can be used across overlays and will have meaning > regardless of which overlay(s) the AoR is connected to. The reality is that > most people are used to having several email addresses, and I don't think > they will have a problem with having several AoRs. > g-) > > > Eunsoo Shim wrote: > > My answers/comments are inline. > > On 6/18/07, Brian Rosen wrote: > > > > Okay, so maybe there is a glimmer here I understand, but clearly not > > all. > > > > Let me ask this: can the domain of an AoR be in more than one overlay? > > > Yes. > But there is a restriction. > A node of an AoR should participate in its domain's "regular" overlay if > possible. > If not, it can participate in a "default" overlay. > > If the answer is no, then maybe I see the way through the haze towards > > some > > kind of distributed database of domains in the DHT. If the answer is > > yes, > > then I hit brick walls. > > > > I'm still not really happy, because what I don't see is a definitive way > > to > > address a message to an arbitrary domain. With C/S, I can do that > > (3263). > > With p2psip, I really think I need to be able to do that. It seems hit > > or > > miss now. > > > I think the above restriction provides a definitive way to address a > message to an arbitrary domain. If a node has connectivity to the DNS, it > uses its local "regular" overlay (if the target domain is the same domain) > or its local proxy that will use RFC3263. If a node has no connectivity to > the DNS, it uses its local "default" overlay. Please notice that a node uses > just one overlay in either case. There is no random poking into arbitrary > overlays. > > I also think that unless the number of domains in an overlay is small, > > that > > we have an intractable problem related to the above. > > > I think the number of domains in an overlay does not matter. As long as > you have a definitive way of mapping domain to overlay, you are fine. > > In the extreme, there > > could be one domain per peer, or even worse, in which case the domain is > > > > meaningless. > > > With the proposed restriction, a node is allowed to create an overlay for > its domain only when it does not have connectivity to the DNS and there is > no existing "default" overlay. That is, it is the first node that wants to > participate in P2PSIP in the isolated network. > > So in the world of P2PSIP I envision, there is one big "regular" overlay > for a specific domain and many small "default" overlays where some of the > nodes of the domain participate. > > Is that the intention? > > > > > Imagine a google service that offers to advertise your AoR, one at a time, > > on a proxy it runs. Just register with an AoR of your choice, and > > you're on > > the overlay. Domain doesn't matter, as long as the entire AoR is > > unique. > > > This is not what I propose. If a node has connectivity to the DNS, it > should participate in the overlay for the specific domain but not in the > google overlay. > > Tens of millions of C/S clients on one proxy peer, with millions of > > domains, > > all resolving to one peer. Does that make sense? > > > > Then suppose Yahoo offers a competing service. Suppose you register > > with > > both (same AoR). Would that work? > > > You are not going to register the AoR either in the google overlay or in > the yahoo overlay. You will have to register the AoR in the overlay for the > domain of the AoR. > > > Thanks. > > Eunsoo > > > -----Original Message----- > > > From: Dean Willis [mailto: dean.willis@softarmor.com] > > > Sent: Friday, June 15, 2007 2:30 AM > > > To: Brian Rosen > > > Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List' > > > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > > > > > Brian Rosen wrote: > > > > Can we just forget clients for a sec? Alice has a full peer > > > implementation > > > > in the example.com domain. What is Alice's AoR (what is the scheme > > for > > > > example? How does another peer resolve that AoR to the protocol, IP > > > > address, etc. needed to create a session with Alice? Assume that > > peer > > > is > > > > very well connected and lives on multiple overlays, as well as > > several > > > > direct SIP C/S domains. > > > > > > > > I mean, if it's sip:alice@example.com, then the peer is going to do > > an > > > SRV > > > > lookup at example.com for a sip server and try C/S, right? RFC3263 > > > > > > > > Are you expecting that to fail? > > > > > > In my current worldview, if the peer knows it is participating in an > > > overlay that addresses the namespace " example.com", the peer looks up > > > Alice in its overlay. If not (or perhaps if the overlay lookup fails) > > it > > > fails, then the peer either does a 3263 resolution itself, or finds a > > > peer node offering "proxy service" to do the 3263 resolution for it. > > > > > > I believe Henning is implying a model where if the "local" overlay > > > fails, we then repeat the lookup operation using either the "meta" > > > overlay, or by asking a peer that does "meata proxy" to do it for us. > > > Said "meta" lookup might then revert to RFC 3263. > > > > > > -- > > > Dean > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > ------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.orghttps://www1.ietf.org/mailman/listinfo/p2psip > > ------=_Part_80779_22168708.1182265203671 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline A good summary.
I support #1.
That's a simple way to support interoperation with C/S SIP.

me@mycompany.com@overlay_1 is just another URI. If we do that, someone cannot print me@mycompany.com on her name card but should print me@mycompany.com@overlay_1, me@mycompany.overlay_2, and so on.
overlay_1 and overlay_2 are just another domains. nothing much changes.

Thanks.

Charlie


On 6/19/07, Greger V. Teigre <greger@teigre.com> wrote:
We have two choices as I see it:

1. Is the AoR supposed to be the equivalent of an email address where the whole domain must handled authoritatively by one entity, here overlay (which allows 3263 lookups) ?

2. Or is the AoR supposed to be the equivalent of "use your email address as username on my website"?

If #1 is true, we can use language as the "AoR's default overlay". However, if #2 is true, a default overlay has no meaning. We must always identify the overlay as well.  So, the AoR has turned from my@mycompany.com to me@mycompany.com@googlesoverlay (ref. Brian's example.

I don't think we are able to do #1 and #2 at the same time.  If we go for #1, we follow the Internet-model for authoritative domain handling. This means that I need several AoRs, one for each overlay I want to participate in. me@gmail.com, me@yahoo.com, and so on. Is this a problem? 

I have a feeling that some people really would like to create some universal id (AoR) that can be used across overlays and will have meaning regardless of which overlay(s) the AoR is connected to. The reality is that most people are used to having several email addresses, and I don't think they will have a problem with having several AoRs.
g-)


Eunsoo Shim wrote:
My answers/comments are inline.

On 6/18/07, Brian Rosen <br@brianrosen.net > wrote:
Okay, so maybe there is a glimmer here I understand, but clearly not all.

Let me ask this: can the domain of an AoR be in more than one overlay?

Yes.
But there is a restriction.
A node of an AoR should participate in its domain's "regular" overlay if possible.
If not, it can participate in a "default" overlay.

If the answer is no, then maybe I see the way through the haze towards some
kind of distributed database of domains in the DHT.  If the answer is yes,
then I hit brick walls.

I'm still not really happy, because what I don't see is a definitive way to
address a message to an arbitrary domain.  With C/S, I can do that (3263).
With p2psip, I really think I need to be able to do that.  It seems hit or
miss now.

I think the above restriction  provides a definitive way to address a message to an arbitrary domain. If a node has connectivity to the DNS, it uses its local "regular" overlay (if the target domain is the same domain) or its local proxy that will use RFC3263. If a node has no connectivity to the DNS, it uses its local "default" overlay. Please notice that a node uses just one overlay in either case. There is no random poking into arbitrary overlays.

I also think that unless the number of domains in an overlay is small, that
we have an intractable problem related to the above. 

I think the number of domains in an overlay does not matter. As long as you have a definitive way of mapping domain to overlay, you are fine.

 In the extreme, there
could be one domain per peer, or even worse, in which case the domain is
meaningless. 

With the proposed restriction, a node is allowed to create an overlay for its domain only when it does not have connectivity to the DNS and there is no existing "default" overlay. That is, it is the first node that wants to participate in P2PSIP in the isolated network.

So in the world of P2PSIP I envision, there is one big "regular" overlay for a specific domain and many small "default" overlays where some of the nodes of the domain participate.

 Is that the intention?



Imagine a google service that offers to advertise your AoR, one at a time,
on a proxy it runs.  Just register with an AoR of your choice, and you're on
the overlay.  Domain doesn't matter, as long as the entire AoR is unique.

This is not what I propose. If a node has connectivity to the DNS, it should participate in the overlay for the specific domain but not in the google overlay.

Tens of millions of C/S clients on one proxy peer, with millions of domains,
all resolving to one peer.  Does that make sense?

Then suppose Yahoo offers a competing service.  Suppose you register with
both (same AoR).  Would that work?

You are not going to register the AoR either in the google overlay or in the yahoo overlay. You will have to register the AoR in the overlay for the domain of the AoR.


Thanks.

Eunsoo

> -----Original Message-----
> From: Dean Willis [mailto: dean.willis@softarmor.com]
> Sent: Friday, June 15, 2007 2:30 AM
> To: Brian Rosen
> Cc: 'Henning Schulzrinne'; 'Vijay K. Gurbani'; 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays
>
> Brian Rosen wrote:
> > Can we just forget clients for a sec?  Alice has a full peer
> implementation
> > in the example.com domain.  What is Alice's AoR (what is the scheme for
> > example?  How does another peer resolve that AoR to the protocol, IP
> > address, etc. needed to create a session with Alice?  Assume that peer
> is
> > very well connected and lives on multiple overlays, as well as several
> > direct SIP C/S domains.
> >
> > I mean, if it's sip:alice@example.com, then the peer is going to do an
> SRV
> > lookup at example.com for a sip server and try C/S, right?  RFC3263
> >
> > Are you expecting that to fail?
>
> In my current worldview, if the peer knows it is participating in an
> overlay that addresses the namespace " example.com", the peer looks up
> Alice in its overlay. If not (or perhaps if the overlay lookup fails) it
> fails, then the peer either does a 3263 resolution itself, or finds a
> peer node offering "proxy service" to do the 3263 resolution for it.
>
> I believe Henning is implying a model where if the "local" overlay
> fails, we then repeat the lookup operation using either the "meta"
> overlay, or by asking a peer that does "meata proxy" to do it for us.
> Said  "meta" lookup might then revert to RFC 3263.
>
> --
> Dean


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_80779_22168708.1182265203671-- --===============1009268825== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1009268825==-- From p2psip-bounces@ietf.org Tue Jun 19 11:57:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g5G-0001vb-G8; Tue, 19 Jun 2007 11:57:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0g5E-0001sW-6P for p2psip@ietf.org; Tue, 19 Jun 2007 11:57:32 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0g5B-0000B5-JL for p2psip@ietf.org; Tue, 19 Jun 2007 11:57:32 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I0g5A-0001to-TB; Tue, 19 Jun 2007 10:57:28 -0500 In-Reply-To: <46778BAE.5010504@teigre.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> <46778BAE.5010504@teigre.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Tue, 19 Jun 2007 10:57:09 -0500 To: Greger V. Teigre X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote: > We have two choices as I see it: > > 1. Is the AoR supposed to be the equivalent of an email address > where the whole domain must handled authoritatively by one entity, > here overlay (which allows 3263 lookups) ? > > 2. Or is the AoR supposed to be the equivalent of "use your email > address as username on my website"? > I think #1 is the general solution, and there might reasonably be a fallback to behavior #2 under certain fully-disconnected scenarios that I don't really even want to think about right now because the overlay-discovery and authentication problems become very, very messy and make my head hurt. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 14:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0i6g-0002eb-F3; Tue, 19 Jun 2007 14:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0i6f-0002eW-Ef for p2psip@ietf.org; Tue, 19 Jun 2007 14:07:09 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0i6e-00069L-4R for p2psip@ietf.org; Tue, 19 Jun 2007 14:07:09 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0i6T-0004ae-4Y; Tue, 19 Jun 2007 13:06:57 -0500 From: "Brian Rosen" To: "'Dean Willis'" , "'Greger V. Teigre'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com><7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com><46778BAE.5010504@teigre.com> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Tue, 19 Jun 2007 14:07:00 -0400 Message-ID: <00c001c7b29c$a3f0d460$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AceyiouPAVAq9ekuRZCWvBvkkiGR+AAEfD5w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Okay. I like it. Is there a way I can look in the URI or the DNS entry for the domain in the URI and discover if this is p2p or c/s, or do I blindly try one and then the other? Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, June 19, 2007 11:57 AM > To: Greger V. Teigre > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > > On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote: > > > We have two choices as I see it: > > > > 1. Is the AoR supposed to be the equivalent of an email address > > where the whole domain must handled authoritatively by one entity, > > here overlay (which allows 3263 lookups) ? > > > > 2. Or is the AoR supposed to be the equivalent of "use your email > > address as username on my website"? > > > > I think #1 is the general solution, and there might reasonably be a > fallback to behavior #2 under certain fully-disconnected scenarios > that I don't really even want to think about right now because the > overlay-discovery and authentication problems become very, very messy > and make my head hurt. > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 15:30:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jP2-0000UT-0E; Tue, 19 Jun 2007 15:30:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jP0-0000UF-71 for p2psip@ietf.org; Tue, 19 Jun 2007 15:30:10 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0jOz-0003CK-OM for p2psip@ietf.org; Tue, 19 Jun 2007 15:30:10 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0jOz-0002s7-1j; Tue, 19 Jun 2007 15:30:09 -0400 In-Reply-To: <4674F5ED.9070000@telecomitalia.it> References: <4674F5ED.9070000@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Tue, 19 Jun 2007 15:30:07 -0400 To: Enrico Marocco , Emil Ivov X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Here are some questions and comments on draft-marocco-p2psip-xpp-00.txt I haven't read the other document yet, so my apologies if these questions are answered in the other document. 1) It seems that XPP is a transport protocol. That is, it provides reliable, in-order delivery of messages, along with segmentation and re-assembly so messages will fit within the Path MTU. However, unlike TCP which is stream-oriented, XPP seems to be message- oriented. In that regards, XPP seems more like SCTP. Though XPP runs over UDP, UDP seems to be just used for encapsulation, and XPP could run directly over IP if there are no NATs in the path. Is this correct? 2) It seems that an XPP session is intended to be set up using SIP signaling, in a way similar to how SIP can set up RTP sessions. That is, the SDP body of the SIP message, rather than specifying RTP, would specify XPP. Furthermore, it seems that you expect ICE to used with SIP to handle the NAT traversal aspects, including the selection of a transmission path. Is this correct? (I will assume "yes" in the rest of my questions below). 3) Why do you think we need XPP as a new transport protocol, rather than using TCP or SCTP? You argue that UDP is easier than TCP to set up through NATs, but Saikat Guha has shown that TCP connections can be reliably set up through NATs in about 90% of the time, and 100% of the time through common pairs of NATs, so I don't really buy this argument. Especially when the BEHAVE recommendations on TCP will be published as an RFC soon. Moreover, one can easily work around this problem if desired by running TCP over UDP, in the same way that you run XPP over UDP. 4) If XPP is set up using ICE, then why is a simultaneous session establishment important? If ICE has already handled the UDP hole-punching, then the simultaneous nature is unimportant. 5) If XPP is set up using ICE, then presumably the NAT bindings are kept alive using STUN indications as specified in ICE. Thus the keepalives in XPP are used for something other than keeping NAT bindings open. My guess is they are just there to make sure the far-end software is still alive. Am I correct? 6) XPP uses 16-bit endpoint identifiers. What are these? I am guessing that these are not peer IDs as described in the Concepts draft, since they are so short. Is this correct? How are these allocated? 7) Is an ACK a response to a request? Or must a response be something else? Say I wanted to transport a file from one endpoint to another (most IM clients today support the ability to transfer a file to the client that one is talking or IMing with) -- how would I do this? 8) Are you assuming that the security is handled by the signaling protocol (e.g., SIP), so there is no need to handle this at the XPP layer? 9) How and when do you see XPP sessions being set up? That is, say peer X and peer Y are behind (different) NATs and there is no XPP session between them? How does this session get set up? How do the signaling messages get transported from X to Y? 10) It seems that there is no provision in XPP for XPP messages to be transported hop-by-hop. That is, if peer X and peer Y want to transport a message using XPP, they have to first set up an XPP session. How do you see this working if X and Y just want a quick message exchange? Say X wants to send a short 40-byte request and get back an equally short answer. Does X have to set up an XPP session with Y first? It seems to me that session setup is a pretty heavy- weight operation (e.g., send one or more STUN requests and receive one or more STUN responses to gather ICE candidates, then send a SIP INVITE, get back a 100 TRYING, get back a 200 OK, send an ACK, send ICE connectivity checks to various addresses, receive ICE connectivity checks on various addresses, send and receive a XPP handshake, then finally send the 40-byte query and get back the 40-byte response). - Philip On 17-Jun-07, at 04:50 , Enrico Marocco wrote: > Folks, > > Emil and I have just submitted two drafts specifying the peer protocol > (XPP) and the overlay algorithm (CAN based) we have implemented in the > last version of sipdht (http://sipdht.sourceforge.net/sipdht2/). Till > they appear in the repository, you can find them at the following > links > (just s/txt/html/ or s/txt/xml/ if you prefer html or xml): > http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt > http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp- > pcan-00.txt > > We hope this contribution will stimulate discussion on some key issues > we've tried to address, among which: > > + transport and encoding for the peer protocol; > + DHT algorithm; > + peer joins. > > On the latter, we propose a mechanism to let nodes join the overlay > only > when they are explicitly invited by existing peers. Such a "passive" > approach (yeah, Dean anticipated that the term was going to get > overloaded) has some benefits which deserve to be investigated. > > Needless to say, any feedback is very very appreciated. > > -- > Ciao, > Enrico > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 17:13:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l12-0006ps-3y; Tue, 19 Jun 2007 17:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l11-0006pn-7n for p2psip@ietf.org; Tue, 19 Jun 2007 17:13:31 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0l0y-0004Z3-T4 for p2psip@ietf.org; Tue, 19 Jun 2007 17:13:31 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5JLDO8P015323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jun 2007 17:13:24 -0400 (EDT) Date: Tue, 19 Jun 2007 17:13:24 -0400 (EDT) From: Salman Abdul Baset To: Emil Ivov Subject: Re: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt In-Reply-To: <4677D0F9.7020609@sip-communicator.org> Message-ID: References: <7730A258-ECB0-442D-AF82-12134DAFC0FA@cs.columbia.edu><20d2bdfb0703210256k6b68a2d5k6b94e16194130348@mail.gmail.com><4d4304a00703210357h30bb0f9bp7e8dd47e4cb14a48@mail.gmail.com><107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> <64DD17B3-7124-41BA-9509-540091AD0AD5@softarmor.com> <6CF039C5B32037498B02251E11CDE6B0059E2A88@ftrdmel3.rd.francetelecom.fr> <4677D0F9.7020609@sip-communicator.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> 3- You state in section 1.2 "P2PP has many things in common with XPP; >> mainly, it >> is binary and uses a very similar encoding for parameters based on >> type-length-value (TLV) fields. However, it misses a mechanism for >> simultaneously initiating sessions, which is one of XPP's most >> important features" >> >> Why not proposing that enhancement to authors of P2PP instead of >> specifying a new protocol? > > Well actually, XPP is the outcome of the sipdht2 project > (http://sipdht.sourceforge.net/sipdht2/). When we started sipdht2 p2pp was > still in an early stage (it was called p2p-common at the time) so this > explains the initial split. Both protocols have many similarities and they > also have a few differences. Anyway, I agree that this is a reasonable > suggestion so we are definitely interested in further discussing a possible > synergy. If I understand correctly, 'simultaneous connections' is the same as 'parallel connections' which P2PP supports. -s _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 19 18:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m0c-0003o6-US; Tue, 19 Jun 2007 18:17:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0m0c-0003o1-66 for p2psip@ietf.org; Tue, 19 Jun 2007 18:17:10 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0m0a-0004CQ-NH for p2psip@ietf.org; Tue, 19 Jun 2007 18:17:10 -0400 Received: by wx-out-0506.google.com with SMTP id t5so1871821wxc for ; Tue, 19 Jun 2007 15:17:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=C8e0L9h3Qm+CqsZ8sbdi8uGrA+svt99oGFnkDfjz217HwF2qx5daNWPeuvDiXfi7h1dtHqxoi1ccLuKW37GgR4y5kdY34VS6v5Xd36tTBELfb6JW6j6+IX7uXUn2/j9+bRweP14nHUUa+k5aD0T3dk1Cxdzc5S0hVeK+kboiqfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Vcmqt2UzOW2zgR+Jzl2QBoibytTe5FkON4xn0M6GusMqCnxsjhHkyucoo36/TwqboTIDjtGJJE/LxZF8Xc/tYBDGTR5JeFaaVkmm9WAotq/1Y2W0AmMq54OI41djdtDcmWZIWtgtTtlslsRCw9HN/3gJ1yXvrNf++jDsF959mOo= Received: by 10.90.73.7 with SMTP id v7mr5751489aga.1182291427752; Tue, 19 Jun 2007 15:17:07 -0700 (PDT) Received: by 10.90.56.13 with HTTP; Tue, 19 Jun 2007 15:17:07 -0700 (PDT) Message-ID: Date: Tue, 19 Jun 2007 18:17:07 -0400 From: "Adam Fisk" To: "Enrico Marocco" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: <4674F5ED.9070000@telecomitalia.it> MIME-Version: 1.0 References: <4674F5ED.9070000@telecomitalia.it> X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Emil Ivov , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1265939612==" Errors-To: p2psip-bounces@ietf.org --===============1265939612== Content-Type: multipart/alternative; boundary="----=_Part_70291_22525339.1182291427697" ------=_Part_70291_22525339.1182291427697 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm wondering if you considered the "Reliable Data Protocol (RDP)" for the peer protocol. It's at http://www.faqs.org/rfcs/rfc1151.html. Seems like an oldie but a goodie with many of the same characteristics, although I don't believe there's the option to turn off reliability. Are you thinking something like XPP would be easier to implement? RDP at least has addressed all the thorny reliability details. It seems to me the session negotiation issues could be worked out for any of these since ICE is designed to be relatively transport agnostic with a little SDP fiddling. I agree the NAT hold punching is a little more straightforward with UDP since you just have more control over the timing of packets, making something along these lines worthwhile. -Adam On 6/17/07, Enrico Marocco wrote: > > Folks, > > Emil and I have just submitted two drafts specifying the peer protocol > (XPP) and the overlay algorithm (CAN based) we have implemented in the > last version of sipdht (http://sipdht.sourceforge.net/sipdht2/). Till > they appear in the repository, you can find them at the following links > (just s/txt/html/ or s/txt/xml/ if you prefer html or xml): > http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt > http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-pcan-00.txt > > We hope this contribution will stimulate discussion on some key issues > we've tried to address, among which: > > + transport and encoding for the peer protocol; > + DHT algorithm; > + peer joins. > > On the latter, we propose a mechanism to let nodes join the overlay only > when they are explicitly invited by existing peers. Such a "passive" > approach (yeah, Dean anticipated that the term was going to get > overloaded) has some benefits which deserve to be investigated. > > Needless to say, any feedback is very very appreciated. > > -- > Ciao, > Enrico > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > ------=_Part_70291_22525339.1182291427697 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'm wondering if you considered the "Reliable Data Protocol (RDP)" for the peer protocol.  It's at http://www.faqs.org/rfcs/rfc1151.html. 

Seems like an oldie but a goodie with many of the same characteristics, although I don't believe there's the option to turn off reliability.  Are you thinking something like XPP would be easier to implement?  RDP at least has addressed all the thorny reliability details. 

It seems to me the session negotiation issues could be worked out for any of these since ICE is designed to be relatively transport agnostic with a little SDP fiddling.

I agree the NAT hold punching is a little more straightforward with UDP since you just have more control over the timing of packets, making something along these lines worthwhile.

-Adam


On 6/17/07, Enrico Marocco < enrico.marocco@telecomitalia.it> wrote:
Folks,

Emil and I have just submitted two drafts specifying the peer protocol
(XPP) and the overlay algorithm (CAN based) we have implemented in the
last version of sipdht (http://sipdht.sourceforge.net/sipdht2/).  Till
they appear in the repository, you can find them at the following links
(just s/txt/html/ or s/txt/xml/ if you prefer html or xml):
http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt
http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-pcan-00.txt

We hope this contribution will stimulate discussion on some key issues
we've tried to address, among which:

+ transport and encoding for the peer protocol;
+ DHT algorithm;
+ peer joins.

On the latter, we propose a mechanism to let nodes join the overlay only
when they are explicitly invited by existing peers.  Such a "passive"
approach (yeah, Dean anticipated that the term was going to get
overloaded) has some benefits which deserve to be investigated.

Needless to say, any feedback is very very appreciated.

--
Ciao,
Enrico

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



------=_Part_70291_22525339.1182291427697-- --===============1265939612== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1265939612==-- From p2psip-bounces@ietf.org Tue Jun 19 20:06:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0niM-0000jd-D0; Tue, 19 Jun 2007 20:06:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0niK-0000jG-Pj for p2psip@ietf.org; Tue, 19 Jun 2007 20:06:24 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0niJ-0004BC-7B for p2psip@ietf.org; Tue, 19 Jun 2007 20:06:24 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I0niH-0001Cd-2m; Tue, 19 Jun 2007 20:06:22 -0400 In-Reply-To: References: <4674F5ED.9070000@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Tue, 19 Jun 2007 20:06:20 -0400 To: Adam Fisk X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Cc: Emil Ivov , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1709832758==" Errors-To: p2psip-bounces@ietf.org --===============1709832758== Content-Type: multipart/alternative; boundary=Apple-Mail-3--20166410 --Apple-Mail-3--20166410 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Adam: I was not familiar with RDP, but I took a quick look. From what I can see, RDP is an old protocol that who state is roughly comparable to the original specification of TCP. As such, it does not have all the enhancements that TCP has undergone over the years (congestion control, etc.). My guess is that the IESG would strongly urge us to look at TCP, SCTP, and DCCP (the latter two having been invented with all the existing TCP work in mind) before trying to resurrect RDP. Furthermore, using a transport protocol other that TCP or UDP means that we have to do all the work to define how SIP and other protocols get transported over this transport protocol. I don't think we should underestimate how much time that would take. - Philip On 19-Jun-07, at 18:17 , Adam Fisk wrote: > I'm wondering if you considered the "Reliable Data Protocol (RDP)" > for the peer protocol. It's at http://www.faqs.org/rfcs/rfc1151.html. > > Seems like an oldie but a goodie with many of the same > characteristics, although I don't believe there's the option to > turn off reliability. Are you thinking something like XPP would be > easier to implement? RDP at least has addressed all the thorny > reliability details. > > It seems to me the session negotiation issues could be worked out > for any of these since ICE is designed to be relatively transport > agnostic with a little SDP fiddling. > > I agree the NAT hold punching is a little more straightforward with > UDP since you just have more control over the timing of packets, > making something along these lines worthwhile. > > -Adam > > > On 6/17/07, Enrico Marocco < enrico.marocco@telecomitalia.it> wrote: > Folks, > > Emil and I have just submitted two drafts specifying the peer protocol > (XPP) and the overlay algorithm (CAN based) we have implemented in the > last version of sipdht (http://sipdht.sourceforge.net/sipdht2/). Till > they appear in the repository, you can find them at the following > links > (just s/txt/html/ or s/txt/xml/ if you prefer html or xml): > http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt > http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp- > pcan-00.txt > > We hope this contribution will stimulate discussion on some key issues > we've tried to address, among which: > > + transport and encoding for the peer protocol; > + DHT algorithm; > + peer joins. > > On the latter, we propose a mechanism to let nodes join the overlay > only > when they are explicitly invited by existing peers. Such a "passive" > approach (yeah, Dean anticipated that the term was going to get > overloaded) has some benefits which deserve to be investigated. > > Needless to say, any feedback is very very appreciated. > > -- > Ciao, > Enrico > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip --Apple-Mail-3--20166410 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Adam:

I was not familiar with = RDP, but I took a quick look.
=46rom what I can see, RDP is an = old protocol that who state is roughly comparable to the original = specification of TCP.
As such, it does not have all = the=A0enhancements that TCP has undergone over the years (congestion = control, etc.).
My guess is that the IESG would strongly urge = us to look at TCP, SCTP, and DCCP (the latter two having = been
invented with all the existing TCP work in mind) before = trying to=A0resurrect=A0RDP.

Furthermore, using a = transport protocol other that TCP or UDP means that we have to do all = the work to define
how SIP and other protocols get transported = over this transport protocol. I don't think we should = underestimate
how much time that would take.

- Philip


On 19-Jun-07, at = 18:17 , Adam Fisk wrote:

I'm = wondering if you considered the "Reliable Data Protocol (RDP)" for the = peer protocol.=A0 It's at = http://www.faqs.org/rfcs/rfc1151.html.=A0

Seems like an = oldie but a goodie with many of the same characteristics, although I = don't believe there's the option to turn off reliability.=A0 Are you = thinking something like XPP would be easier to implement?=A0 RDP at = least has addressed all the thorny reliability details.=A0

It = seems to me the session negotiation issues could be worked out for any = of these since ICE is designed to be relatively transport agnostic with = a little SDP fiddling.

I agree the NAT hold punching is a little = more straightforward with UDP since you just have more control over the = timing of packets, making something along these lines worthwhile. =

-Adam


On 6/17/07, Enrico Marocco < = enrico.marocco@telecomitalia.it> wrote:
Folks,

Emil = and I have just submitted two drafts specifying the peer = protocol
(XPP) and the overlay algorithm (CAN based) we have = implemented in the
last version of sipdht (http://sipdht.sourceforge.net/sipdh= t2/).=A0=A0Till
they appear in the repository, you can find them = at the following links
(just s/txt/html/ or s/txt/xml/ if you prefer = html or xml):
http://sipdht.sourceforge.net/draft= s/draft-marocco-p2psip-xpp-00.txt
= http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-pcan-00.txt<= /A>

We hope this contribution will stimulate discussion on some = key issues
we've tried to address, among which:

+ transport = and encoding for the peer protocol;
+ DHT algorithm;
+ peer = joins.

On the latter, we propose a mechanism to let nodes join = the overlay only
when they are explicitly invited by existing = peers.=A0=A0Such a "passive"
approach (yeah, Dean anticipated that = the term was going to get
overloaded) has some benefits which = deserve to be investigated.

Needless to say, any feedback is very = very = appreciated.

--
Ciao,
Enrico

_________________________= ______________________
P2PSIP mailing list
P2PSIP@ietf.org
= https://www1.ietf.org/mailman/listinfo/p2psip


=

P2PSIP mailing list
=

= --Apple-Mail-3--20166410-- --===============1709832758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1709832758==-- From p2psip-bounces@ietf.org Tue Jun 19 23:17:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0qh6-0003Z6-5k; Tue, 19 Jun 2007 23:17:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0qh4-0003Yu-MI for p2psip@ietf.org; Tue, 19 Jun 2007 23:17:18 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0qh2-0000NQ-PT for p2psip@ietf.org; Tue, 19 Jun 2007 23:17:18 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 19 Jun 2007 20:17:16 -0700 X-IronPort-AV: i="4.16,440,1175497200"; d="scan'208,217"; a="3860174:sNHT75522762" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l5K3HGGu003033; Tue, 19 Jun 2007 20:17:16 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5K3HB20024203; Wed, 20 Jun 2007 03:17:11 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 20:17:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Tue, 19 Jun 2007 20:18:02 -0700 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A0275AD4F@xmb-sjc-219.amer.cisco.com> In-Reply-To: <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Peer protocol, DHT and running code Thread-Index: AceyzuEllMlNgKNSQkOiOIBhVK7OngAGZsDw From: "Krishna Sankar \(ksankar\)" To: "Philip Matthews" , "Adam Fisk" X-OriginalArrivalTime: 20 Jun 2007 03:17:11.0389 (UTC) FILETIME=[7DF830D0:01C7B2E9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13561; t=1182309436; x=1183173436; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ksankar@cisco.com; z=From:=20=22Krishna=20Sankar=20\(ksankar\)=22=20 |Subject:=20RE=3A=20[P2PSIP]=20Peer=20protocol, =20DHT=20and=20running=20c ode |Sender:=20; bh=UuKFWpJ5S1kuKRhXp9aTwb0McyKvQ0zKTuvx7pPv/jk=; b=p2hedFln4iPdRh4CAtRgL7N7tnnkU6oeDr7rWQEnuz8AI3RAhFeVVdZYozIavWYYFwHfIIAw 0RKTKGJMwXkPcLJaLh8MEpq7Cbiv8DD3S/xVRiXEvCmcBPBYIH3hWE1K; Authentication-Results: sj-dkim-4; header.From=ksankar@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Cc: Emil Ivov , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0561073549==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0561073549== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B2E9.7DB87687" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B2E9.7DB87687 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yep, agreed. I would suggest SCTP which is relatively better in may ways.=20 =20 I am going to ask couple of stupid questions (as I didn't get enough time to go over all the nuances, summer time you know ;o)) =20 a) Enrico, are you using XPP to achieve reliable UDP ? b) Did you consider SCTP ? Any glaring problems ? c) Knowing that TCP is very well optimized in all the devices incl the NICs, why should we explore XPP/RDP et al ? d) What is our goal ? The perfect protocol or a "good-enough" one that has maximum co-existence ? =20 I am just asking, no judgment calls.=20 =20 Cheers ________________________________ From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, June 19, 2007 5:06 PM To: Adam Fisk Cc: Emil Ivov; P2PSIP Mailing List Subject: Re: [P2PSIP] Peer protocol, DHT and running code =09 =09 Adam: I was not familiar with RDP, but I took a quick look. From what I can see, RDP is an old protocol that who state is roughly comparable to the original specification of TCP. As such, it does not have all the enhancements that TCP has undergone over the years (congestion control, etc.). My guess is that the IESG would strongly urge us to look at TCP, SCTP, and DCCP (the latter two having been invented with all the existing TCP work in mind) before trying to resurrect RDP. Furthermore, using a transport protocol other that TCP or UDP means that we have to do all the work to define how SIP and other protocols get transported over this transport protocol. I don't think we should underestimate how much time that would take. - Philip On 19-Jun-07, at 18:17 , Adam Fisk wrote: I'm wondering if you considered the "Reliable Data Protocol (RDP)" for the peer protocol. It's at http://www.faqs.org/rfcs/rfc1151.html. =20 =09 Seems like an oldie but a goodie with many of the same characteristics, although I don't believe there's the option to turn off reliability. Are you thinking something like XPP would be easier to implement? RDP at least has addressed all the thorny reliability details. =20 =09 It seems to me the session negotiation issues could be worked out for any of these since ICE is designed to be relatively transport agnostic with a little SDP fiddling. =09 I agree the NAT hold punching is a little more straightforward with UDP since you just have more control over the timing of packets, making something along these lines worthwhile.=20 =09 -Adam =09 =09 =09 On 6/17/07, Enrico Marocco < enrico.marocco@telecomitalia.it > wrote:=20 Folks, =09 Emil and I have just submitted two drafts specifying the peer protocol (XPP) and the overlay algorithm (CAN based) we have implemented in the=20 last version of sipdht (http://sipdht.sourceforge.net/sipdht2/). Till they appear in the repository, you can find them at the following links=20 (just s/txt/html/ or s/txt/xml/ if you prefer html or xml):=20 =09 http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt=20 =09 http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-pcan-00.tx t =09 We hope this contribution will stimulate discussion on some key issues we've tried to address, among which: =09 + transport and encoding for the peer protocol;=20 + DHT algorithm; + peer joins. =09 On the latter, we propose a mechanism to let nodes join the overlay only when they are explicitly invited by existing peers. Such a "passive" approach (yeah, Dean anticipated that the term was going to get=20 overloaded) has some benefits which deserve to be investigated. =09 Needless to say, any feedback is very very appreciated. =09 -- Ciao, Enrico =09 _______________________________________________ P2PSIP mailing list=20 P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------_=_NextPart_001_01C7B2E9.7DB87687 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yep, agreed. I would suggest SCTP which is = relatively=20 better in may ways.
 
I am going to ask couple of stupid questions = (as I=20 didn't get enough time to go over all the nuances, summer time you know=20 ;o))
 
a)    Enrico, are you using XPP = to achieve=20 reliable UDP ?
b)    Did you consider SCTP = ? Any=20 glaring problems ?
c)    Knowing that TCP is = very well=20 optimized in all the devices incl the NICs, why should we explore = XPP/RDP et al=20 ?
d)    What is our goal ? The = perfect=20 protocol or a "good-enough" one that has maximum co-existence=20 ?
 
I am just asking, no judgment calls. =
 
Cheers
<k/>

From: Philip Matthews=20 [mailto:philip_matthews@magma.ca]
Sent: Tuesday, June 19, = 2007 5:06=20 PM
To: Adam Fisk
Cc: Emil Ivov; P2PSIP Mailing=20 List
Subject: Re: [P2PSIP] Peer protocol, DHT and running=20 code

Adam:

I was not familiar with RDP, but I took a quick look.
From what I can see, RDP is an old protocol that who state is = roughly=20 comparable to the original specification of TCP.
As such, it does not have all the enhancements that TCP has=20 undergone over the years (congestion control, etc.).
My guess is that the IESG would strongly urge us to look at TCP, = SCTP,=20 and DCCP (the latter two having been
invented with all the existing TCP work in mind) before trying=20 to resurrect RDP.

Furthermore, using a transport protocol other that TCP or UDP = means that=20 we have to do all the work to define
how SIP and other protocols get transported over this transport = protocol.=20 I don't think we should underestimate
how much time that would take.

- Philip


On 19-Jun-07, at 18:17 , Adam Fisk wrote:
I'm wondering if you considered the = "Reliable Data=20 Protocol (RDP)" for the peer protocol.  It's at http://www.faqs.org/rfcs/rfc1151.html.  =

Seems=20 like an oldie but a goodie with many of the same characteristics, = although I=20 don't believe there's the option to turn off reliability.  Are = you=20 thinking something like XPP would be easier to implement?  RDP = at least=20 has addressed all the thorny reliability details. 

It = seems to=20 me the session negotiation issues could be worked out for any of = these since=20 ICE is designed to be relatively transport agnostic with a little = SDP=20 fiddling.

I agree the NAT hold punching is a little more=20 straightforward with UDP since you just have more control over the = timing of=20 packets, making something along these lines worthwhile.=20

-Adam


On 6/17/07, Enrico=20 Marocco <=20 enrico.marocco@telecomitalia.it> wrote:=20
Folks,

Emil=20 and I have just submitted two drafts specifying the peer = protocol
(XPP)=20 and the overlay algorithm (CAN based) we have implemented in the =
last=20 version of sipdht (http://sipdht.sourceforge.net/sipdht2/).  T= ill
they=20 appear in the repository, you can find them at the following links =
(just s/txt/html/ or s/txt/xml/ if you prefer html or xml): =
http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip= -xpp-00.txt=20
http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip= -xpp-pcan-00.txt

We=20 hope this contribution will stimulate discussion on some key=20 issues
we've tried to address, among which:

+ transport = and=20 encoding for the peer protocol;
+ DHT algorithm;
+ peer=20 joins.

On the latter, we propose a mechanism to let nodes = join the=20 overlay only
when they are explicitly invited by existing=20 peers.  Such a "passive"
approach (yeah, Dean = anticipated=20 that the term was going to get
overloaded) has some benefits = which=20 deserve to be investigated.

Needless to say, any feedback = is very=20 very=20 = appreciated.

--
Ciao,
Enrico

________________________= _______________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

=

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

= ------_=_NextPart_001_01C7B2E9.7DB87687-- --===============0561073549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0561073549==-- From p2psip-bounces@ietf.org Wed Jun 20 02:41:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tsb-0003UX-Op; Wed, 20 Jun 2007 02:41:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0tsX-0003U9-UO for p2psip@ietf.org; Wed, 20 Jun 2007 02:41:22 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0tsW-0000WV-2F for p2psip@ietf.org; Wed, 20 Jun 2007 02:41:21 -0400 Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 08:41:19 +0200 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 08:41:18 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 08:41:18 +0200 Message-ID: <4678CC81.5050806@telecomitalia.it> Date: Wed, 20 Jun 2007 08:43:13 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Salman Abdul Baset Subject: Re: [P2PSIP] COMMENTS on I-D ACTION:draft-marocco-p2psip-xpp-00.txt References: <7730A258-ECB0-442D-AF82-12134DAFC0FA@cs.columbia.edu><20d2bdfb0703210256k6b68a2d5k6b94e16194130348@mail.gmail.com><4d4304a00703210357h30bb0f9bp7e8dd47e4cb14a48@mail.gmail.com><107BB2EB-82A5-45D4-9205-3C40452C9743@cs.columbia.edu> <64DD17B3-7124-41BA-9509-540091AD0AD5@softarmor.com> <6CF039C5B32037498B02251E11CDE6B0059E2A88@ftrdmel3.rd.francetelecom.fr> <4677D0F9.7020609@sip-communicator.org> In-Reply-To: X-OriginalArrivalTime: 20 Jun 2007 06:41:18.0137 (UTC) FILETIME=[0199A290:01C7B306] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1505862345==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1505862345== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030807090809020603070200" This is a cryptographically signed message in MIME format. --------------ms030807090809020603070200 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Salman Abdul Baset wrote: >>> 3- You state in section 1.2 "P2PP has many things in common with XPP; >>> mainly, it >>> is binary and uses a very similar encoding for parameters based on >>> type-length-value (TLV) fields. However, it misses a mechanism for >>> simultaneously initiating sessions, which is one of XPP's most >>> important features" >>> >>> Why not proposing that enhancement to authors of P2PP instead of >>> specifying a new protocol? >> >> Well actually, XPP is the outcome of the sipdht2 project >> (http://sipdht.sourceforge.net/sipdht2/). When we started sipdht2 p2pp >> was still in an early stage (it was called p2p-common at the time) so >> this explains the initial split. Both protocols have many similarities >> and they also have a few differences. Anyway, I agree that this is a >> reasonable suggestion so we are definitely interested in further >> discussing a possible synergy. > > If I understand correctly, 'simultaneous connections' is the same as > 'parallel connections' which P2PP supports. I don't think so. "Simultaneous" is the establishment, the handshake, not the connection; it means that, peers establishing a session, start sending packets simultaneously. P2PP doesn't have such a mechanism, does it? -- Ciao, Enrico --------------ms030807090809020603070200 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMDY0MzEzWjAjBgkqhkiG9w0BCQQxFgQUIppM9Tad +k9PwRkJdB78fFoL6nswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBALEwnMTWeG9/ECZlvFoDGoqFEOv15+kBEXLzRbEfiJKt7yvKu/+rrwu5 KFUAlGk/7CkxY71Ukx1ISV1x+Fsrw4MzA42q6Dmta+f/uxLL/NNGC6D5rgg/FOpCBr8AGWxA NvK5CtqvoVhg4nyDWNqNuD9TMCqiq2udWAVj/K73zf/mtoA2rx5uniIdtVz/k9eHjluBgSpc nvclGRVoBzqsaGuC563fkDE3lIwWAfyivDuOBAzDGOJ1QwEpU1srvtv02kX9AdqfMtx/VRPD O7Wq2iDgkIRQkSdwR7vkwxHdRk34Pbq/TOnU7ZsEOx0ST24zmuERSl3WWpmILVYQJs1RNxoA AAAAAAA= --------------ms030807090809020603070200-- --===============1505862345== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1505862345==-- From p2psip-bounces@ietf.org Wed Jun 20 04:33:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vcj-0004EU-UM; Wed, 20 Jun 2007 04:33:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0vci-0004CO-8f for p2psip@ietf.org; Wed, 20 Jun 2007 04:33:08 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0vch-0006jo-B5 for p2psip@ietf.org; Wed, 20 Jun 2007 04:33:08 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:33:06 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:33:06 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 10:33:05 +0200 Message-ID: <4678E6B4.8090000@telecomitalia.it> Date: Wed, 20 Jun 2007 10:35:00 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> In-Reply-To: <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> X-OriginalArrivalTime: 20 Jun 2007 08:33:05.0081 (UTC) FILETIME=[9F401290:01C7B315] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Emil Ivov , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0870007835==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0870007835== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080207050700040702020802" This is a cryptographically signed message in MIME format. --------------ms080207050700040702020802 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Philip, let me firstly answer the question which hits the main point separately. Inline. Philip Matthews wrote: > 3) Why do you think we need XPP as a new transport protocol, rather than > using TCP or SCTP? > You argue that UDP is easier than TCP to set up through NATs, but Saikat > Guha has shown > that TCP connections can be reliably set up through NATs in about 90% of > the time, and 100% > of the time through common pairs of NATs, so I don't really buy this > argument. Especially when > the BEHAVE recommendations on TCP will be published as an RFC soon. The problem with TCP is that the mechanism you need to establish a connection heavily depends on the environment. The simultaneous handshake, for example, is generally required to establish the connection if the two peers are behind NATs, but fails 50% of the times if one isn't (because the non-natted peer would send back a RST if it hasn't started sending SYNs yet) and ~100% of the times if none of them is (because most likely one of the peers would receive a SYN on an uninitialized socket). So, basically, it is true that ~88% of the times you can successfully establish a TCP connection between natted peers, but to do that you really need to implement something like ICE-TCP to find every time the effective way to do that. We decided to go for a compromise to keep ICE a "SHOULD", and defined the simultaneous establishment mechanism over UDP, which is supposed to work both if the peers are behind 4787-compliant NATs and if any of them has a public address. Note that the full XPP implementation (including session establishment, fragmentation, reliability and request-response matching) is just about 2500 lines of code. Then, using UDP it is possible to turn reliability off; although it sounds interesting especially in distributed overlays, I think it should be discussed separately. > Moreover, one can easily work around this problem if desired by running > TCP over UDP, > in the same way that you run XPP over UDP. I don't see XPP as a general purpose transport protocol; it is really conceived for executing DHT operations, and in this is similar to P2PP (we even came out with the same encoding). Finally, TCP over UDP would bring too much complexity, and too much unnecessary and redundant functionality, which contradicts our design goals. -- Ciao, Enrico --------------ms080207050700040702020802 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMDgzNTAwWjAjBgkqhkiG9w0BCQQxFgQU0ycSTwEH 8cVNfFViKCK8W0jLufAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAANsAAPtgvoYG5KocrT5pMDrkWQNQx7C4vPetbVhSFoA589y9ZUW5DnG xaH9hfzuyShXfLl6uotTa6p+zF9I3aNTi+DVs8uwPSY/YlibbvCbIpDbvtKmpBIUyS3ji0Ef mvn5cZGe8EccxOzsH1dg5/drR6RDgY8AjfsYeY8oJwD//6x/ehf1sYpYWEaNdSxv24IXskwi 39S6AAC6sGhnzWEqtqG5UgnLgZmsr3cS3WWhJkv8KxlrBI5h7ftazSnqWywiSraY59am2bZZ AVL1rTSwZKbpcWhBPABXpj3gJc1UoGKJrrGAX5aQa1VI/X4TFX/RsxxMxslHkc6IFGuVyoUA AAAAAAA= --------------ms080207050700040702020802-- --===============0870007835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0870007835==-- From p2psip-bounces@ietf.org Wed Jun 20 05:00:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0w3E-0005Pq-F3; Wed, 20 Jun 2007 05:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0w3D-0005Pi-Te for p2psip@ietf.org; Wed, 20 Jun 2007 05:00:31 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0w3B-000308-5G for p2psip@ietf.org; Wed, 20 Jun 2007 05:00:31 -0400 Received: from S4DE9JSAANO.ost.t-com.de (S4DE9JSAANO.ost.t-com.de [10.125.177.105]) by tcmail21.telekom.de with ESMTP; Wed, 20 Jun 2007 11:00:27 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 11:00:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 11:00:23 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7B1@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Peer protocol, DHT and running code Thread-Index: AceyzuRHnsGHeNptRcSYO8dlyZlcuQAR18AA From: "Beck01, Wolfgang" To: X-OriginalArrivalTime: 20 Jun 2007 09:00:25.0336 (UTC) FILETIME=[70EB1F80:01C7B319] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: emcho@emcho.com, philip_matthews@magma.ca X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip Matthews wrote: > My guess is that the IESG would strongly urge us to look at TCP, SCTP, and DCCP (the latter two having been > invented with all the existing TCP work in mind) before trying to resurrect RDP. I share Philip's reservations about inventing yet another UDP-based transport protocol. However, I'd guess that many firewalls out there don't know about SCTP and DCCP and will simply discard such packets.=20 What are our requirements? - transport of larger pieces of data; TCP shines here, but how much continuous traffic do P2P protocols create? - reliable session setup through all NAT (advantage UDP?) - measurement of the network's performance for peer selection; Linux apps can access the TCP parameters of a running session, do other OSs have a similar functionality? UDP-based transport could do this in a more portable way - ease of implementation getting segmentation and reliable transport right requires some work As much as I'd like to see a TCP-based solution, a UDP-based transport seems to have some important advantages. But please, either merge xpp with p2pp or drop one of the protocols. Wolfgang _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 05:21:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wMv-0002Rt-95; Wed, 20 Jun 2007 05:20:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0wMu-0002Rj-Dg for p2psip@ietf.org; Wed, 20 Jun 2007 05:20:52 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0wMr-00022G-CX for p2psip@ietf.org; Wed, 20 Jun 2007 05:20:50 -0400 Received: (qmail 17834 invoked for bounce); 20 Jun 2007 11:23:01 -0000 Received: from unknown (HELO ?130.79.90.87?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 20 Jun 2007 11:23:01 -0000 Message-ID: <4678F170.7030309@sip-communicator.org> Date: Wed, 20 Jun 2007 11:20:48 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: "Krishna Sankar (ksankar)" Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <9FA16888AD1BF64ABCE6C2532CCEB98A0275AD4F@xmb-sjc-219.amer.cisco.com> In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A0275AD4F@xmb-sjc-219.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello Krishna, Krishna Sankar (ksankar) wrote: > a) Enrico, are you using XPP to achieve reliable UDP ? Reliability is only one of the transport features that we'd need in an overlay maintenance protocol. We'd also like to be able to turn it off, make it handle fragmentation and remain as light as possible in the same time. > b) Did you consider SCTP ? Any glaring problems ? SCTP has a lot of functionality that we don't need, such as: recording paths, transporting multiple flows simultaneously, etc. Then, I am also wondering how many of the existing NATs and firewalls would let it pass. > c) Knowing that TCP is very well optimized in all the devices incl > the NICs, why should we explore XPP/RDP et al ? You may want to have a look at Enrico's reply to Philip, but here's a summary: We need it to behave as well as possible behind NATs. We'd like to be able to turn reliability off. We'd like it to remain a light and easy to implement solution. > d) What is our goal ? First, make sure that it would work in as many cases as possible. In other words we'd like to handle any NAT or firewall that would let UDP pass through. Second, keep it as lite and easy to implement as possible. Cheers Emil > The perfect protocol or a "good-enough" one > that has maximum co-existence ? > > I am just asking, no judgment calls. > > Cheers > > > ------------------------------------------------------------------------ > *From:* Philip Matthews [mailto:philip_matthews@magma.ca] > *Sent:* Tuesday, June 19, 2007 5:06 PM > *To:* Adam Fisk > *Cc:* Emil Ivov; P2PSIP Mailing List > *Subject:* Re: [P2PSIP] Peer protocol, DHT and running code > > Adam: > > I was not familiar with RDP, but I took a quick look. > From what I can see, RDP is an old protocol that who state is > roughly comparable to the original specification of TCP. > As such, it does not have all the enhancements that TCP has > undergone over the years (congestion control, etc.). > My guess is that the IESG would strongly urge us to look at TCP, > SCTP, and DCCP (the latter two having been > invented with all the existing TCP work in mind) before trying > to resurrect RDP. > > Furthermore, using a transport protocol other that TCP or UDP means > that we have to do all the work to define > how SIP and other protocols get transported over this transport > protocol. I don't think we should underestimate > how much time that would take. > > - Philip > > > On 19-Jun-07, at 18:17 , Adam Fisk wrote: > >> I'm wondering if you considered the "Reliable Data Protocol (RDP)" >> for the peer protocol. It's at >> http://www.faqs.org/rfcs/rfc1151.html. >> >> Seems like an oldie but a goodie with many of the same >> characteristics, although I don't believe there's the option to >> turn off reliability. Are you thinking something like XPP would >> be easier to implement? RDP at least has addressed all the thorny >> reliability details. >> >> It seems to me the session negotiation issues could be worked out >> for any of these since ICE is designed to be relatively transport >> agnostic with a little SDP fiddling. >> >> I agree the NAT hold punching is a little more straightforward >> with UDP since you just have more control over the timing of >> packets, making something along these lines worthwhile. >> >> -Adam >> >> >> On 6/17/07, *Enrico Marocco* < enrico.marocco@telecomitalia.it >> > wrote: >> >> Folks, >> >> Emil and I have just submitted two drafts specifying the peer >> protocol >> (XPP) and the overlay algorithm (CAN based) we have >> implemented in the >> last version of sipdht >> (http://sipdht.sourceforge.net/sipdht2/). Till >> they appear in the repository, you can find them at the >> following links >> (just s/txt/html/ or s/txt/xml/ if you prefer html or xml): >> http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-00.txt >> >> http://sipdht.sourceforge.net/drafts/draft-marocco-p2psip-xpp-pcan-00.txt >> >> We hope this contribution will stimulate discussion on some >> key issues >> we've tried to address, among which: >> >> + transport and encoding for the peer protocol; >> + DHT algorithm; >> + peer joins. >> >> On the latter, we propose a mechanism to let nodes join the >> overlay only >> when they are explicitly invited by existing peers. Such a >> "passive" >> approach (yeah, Dean anticipated that the term was going to get >> overloaded) has some benefits which deserve to be investigated. >> >> Needless to say, any feedback is very very appreciated. >> >> -- >> Ciao, >> Enrico >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 06:16:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xEO-0005dt-AL; Wed, 20 Jun 2007 06:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0xEM-0005dl-O0 for p2psip@ietf.org; Wed, 20 Jun 2007 06:16:06 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0xEK-0005CG-Uw for p2psip@ietf.org; Wed, 20 Jun 2007 06:16:06 -0400 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:16:03 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:16:02 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 12:16:01 +0200 Message-ID: <4678FED7.4040103@telecomitalia.it> Date: Wed, 20 Jun 2007 12:17:59 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> In-Reply-To: <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> X-OriginalArrivalTime: 20 Jun 2007 10:16:01.0692 (UTC) FILETIME=[00CC1DC0:01C7B324] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0148704696==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0148704696== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080605030801070500020701" This is a cryptographically signed message in MIME format. --------------ms080605030801070500020701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Philip Matthews wrote: > Furthermore, using a transport protocol other that TCP or UDP means that > we have to do all the work to define > how SIP and other protocols get transported over this transport > protocol. I don't think we should underestimate > how much time that would take. Actually, I don't think we really need to tunnel SIP over the peer protocol. In the PCAN draft (http://tools.ietf.org/id/draft-marocco-p2psip-xpp-pcan-00.txt) we address the issue of NAT traversal the following way: 1) clients that need to do so would keep sip-outbound connections with peers. 2) peers that handle sip-outbound flows for some clients would store routing records containing the full path to the client. Here's an example: imagine client C registers with peer B and establishes an outbound flow with it. C's routing record (inserted in the overlay by B) will contain two hops: B's contact and C's contact/gruu. In case B is also suffering restricted connectivity, this would mean that it too would have an outbound flow with another peer, say A. In this case (which is pretty unlikely, because if B is restricted it probably won't be able to receive REGISTER requests form C), C's routing record would contain three hops. Having said that, it's probably worth noting that we have not yet decided whether this approach is better compared to routing SIP messages inside the overlay. Both are easily implementable with XPP and XPP-PCAN so I guess we'd need to discuss this further before we really made up our minds. -- Ciao, Enrico --------------ms080605030801070500020701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMTAxNzU5WjAjBgkqhkiG9w0BCQQxFgQU9FFDQs1U eKexnZga7NzF+ZHc6JUwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAA2g/isBD4+vQm5FIbQX+boUdjPsHMkTzq77xuty36VeV1R7rKTWe3Y/ PClqx0t1ENL9aw8CMzmhDQwci1VDdknV4JjinO0WCWUiEfVrLByTeyyQbq4gvKDdwHrnaDaG CNSggr5gW1U1Vx1LAV+1VRT9im1TyvJjvZrpqEuFaMb9bsxmCqsXC08m35skxApmxHA22gEK CX5loydvNjfKLvnYw2JODTyi9a0+TuwgoqeIA6GBtFt7ghVIci6Yq1oKD9WfGhRTSG5sTF1V hbh0RcHVC3XUJHkO4DWBDBcoEZ0dnYTk2o76fRUVNyWqcQkSnV4B5xlpPX1nqbWrQlx4picA AAAAAAA= --------------ms080605030801070500020701-- --===============0148704696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0148704696==-- From p2psip-bounces@ietf.org Wed Jun 20 07:41:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yZM-00075t-P8; Wed, 20 Jun 2007 07:41:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0yZK-00075o-Sb for p2psip@ietf.org; Wed, 20 Jun 2007 07:41:50 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I0yZJ-0000g7-Dn for p2psip@ietf.org; Wed, 20 Jun 2007 07:41:50 -0400 Received: (qmail 18943 invoked for bounce); 20 Jun 2007 13:44:01 -0000 Received: from unknown (HELO ?130.79.90.87?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 20 Jun 2007 13:44:01 -0000 Message-ID: <4679127C.7020504@sip-communicator.org> Date: Wed, 20 Jun 2007 13:41:48 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: "Beck01, Wolfgang" Subject: Re: AW: [P2PSIP] Peer protocol, DHT and running code References: <1E4CCB2441C5C0409AD8A929482A09F31BB7B1@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB7B1@S4DE9JSAAIG.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello Wolfgang, Beck01, Wolfgang wrote: > As much as I'd like to see a TCP-based solution, a UDP-based transport > seems to have > some important advantages. But please, either merge xpp with p2pp or > drop one of the protocols. XPP, P2PP, and dSIP are all proposals made by contributors to this working group. The drafts that we submitted represent our take on the problem, based on our work on the SIPDHT2 project. We are, by no means, expecting that they would be adopted the way they are. We do hope, however, that the working group would find parts of them useful and we are, most certainly, willing to work together with other wg members/authors on a version combining the strengths of all proposed solutions. Cheers Emil > Wolfgang > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 08:51:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zeT-00011q-4P; Wed, 20 Jun 2007 08:51:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0zeR-00011P-SZ for p2psip@ietf.org; Wed, 20 Jun 2007 08:51:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0zeR-0005q6-0c for p2psip@ietf.org; Wed, 20 Jun 2007 08:51:11 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I0zeH-0005fY-VQ; Wed, 20 Jun 2007 07:51:02 -0500 From: "Brian Rosen" To: "'Enrico Marocco'" , "'Philip Matthews'" References: <4674F5ED.9070000@telecomitalia.it><7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 08:51:05 -0400 Message-ID: <037601c7b339$acaf35e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4678E6B4.8090000@telecomitalia.it> Thread-Index: AcezFaIudKp8jtfwSY+x3mOS8kS5NAAItb7Q X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Emil Ivov' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I am bothered by this discussion: > The problem with TCP is that the mechanism you need to establish a > connection heavily depends on the environment. .... > So, basically, it is true that ~88% of the times > you can successfully establish a TCP connection between natted peers, > but to do that you really need to implement something like ICE-TCP to > find every time the effective way to do that. > > We decided to go for a compromise to keep ICE a "SHOULD", and defined > the simultaneous establishment mechanism over UDP, which is supposed to > work both if the peers are behind 4787-compliant NATs and if any of them > has a public address. 88% of the time is going to be a WHOLE lot more that "any of them has a public address". I doubt 2% of a normal overlay will have peers with public addresses behind 4787 compliant NATs. To me, this is the biggest problem with p2psip; peers have non-public addresses behind very restrictive NATs. That is the way the Internet looks like these days. I am also bothered by ICE as a should. There is a whole lot of effort that was put into making ICE work in as many circumstances as possible, and I think the code size is not going to be much of an issue. It's going to be common to have ICE implementations with any SIP implementation. I don't think investing much effort in ICE-light is worthwhile. Brian _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 09:40:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10Q2-0001NT-J3; Wed, 20 Jun 2007 09:40:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10Q1-0001NL-In for p2psip@ietf.org; Wed, 20 Jun 2007 09:40:21 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10Py-0002eA-Hn for p2psip@ietf.org; Wed, 20 Jun 2007 09:40:21 -0400 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 15:40:16 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 15:40:16 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 15:40:15 +0200 Message-ID: <46792EB5.3070700@telecomitalia.it> Date: Wed, 20 Jun 2007 15:42:13 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it><7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <037601c7b339$acaf35e0$640fa8c0@cis.neustar.com> In-Reply-To: <037601c7b339$acaf35e0$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 20 Jun 2007 13:40:15.0638 (UTC) FILETIME=[88B7E360:01C7B340] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1332990405==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1332990405== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090904010409090202050509" This is a cryptographically signed message in MIME format. --------------ms090904010409090202050509 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Brian Rosen wrote: > I am bothered by this discussion: > >> The problem with TCP is that the mechanism you need to establish a >> connection heavily depends on the environment. .... >> So, basically, it is true that ~88% of the times >> you can successfully establish a TCP connection between natted peers, >> but to do that you really need to implement something like ICE-TCP to >> find every time the effective way to do that. >> >> We decided to go for a compromise to keep ICE a "SHOULD", and defined >> the simultaneous establishment mechanism over UDP, which is supposed to >> work both if the peers are behind 4787-compliant NATs and if any of them >> has a public address. > > 88% of the time is going to be a WHOLE lot more that "any of them has a > public address". I doubt 2% of a normal overlay will have peers with public > addresses behind 4787 compliant NATs. To me, this is the biggest problem > with p2psip; peers have non-public addresses behind very restrictive NATs. > That is the way the Internet looks like these days. I think I've been unclear. Obviously XPP is supposed to work when none, one or both peers are behind NATs compliant with RFC 4787 (clearly if they are behind a NAT, they don't have public addresses). > I am also bothered by ICE as a should. There is a whole lot of effort that > was put into making ICE work in as many circumstances as possible, and I > think the code size is not going to be much of an issue. It's going to be > common to have ICE implementations with any SIP implementation. I don't > think investing much effort in ICE-light is worthwhile. Yes, this is indeed a big question. I'm curious to see what people think about ICE; on one hand, it is pretty difficult to implement and to integrate with existing libraries, on the other hand, it is the most complete mechanism for NAT traversal. For the first version of our solution we tried to keep it optional and accepted a cheap compromise which should /often/ work (and which does not preclude ICE). It's a trade off... I would really like to get feedback on this. -- Ciao, Enrico --------------ms090904010409090202050509 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMTM0MjEzWjAjBgkqhkiG9w0BCQQxFgQURDk6T93O CY1pcTfnGYExp1ev0XYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAHJkLYQfIfDpTHoVqR8IhRnpVrh87eAtzxcQlpfxocqQPZ6150RMu0G5 WoqnpTlOTo2mUldU9FQhB5ezKqgXejBYWYsGEu3H6PRMCEDr1Q/zUa3H/DlAgVVhonwt0ibs rz3VA7R91IxHQDHWOYo6qIfSIaFigZsBf8XIHX/fDxrys9/QLDkXeh3LtE79aGi5MitAV0eu QQCoznxNBU3U7YR9CpichCQqUmq0/Y+4U1kFXNXP5rP6xdM2+eMExD+mNDOhlSrypC8H+CVw biqT+CzTSrk0Bu2lblwjR18Wl9UAMD7cIgN50W2yfEB+F9w7OVb2hD8lQDu6K9m4yr1eZe8A AAAAAAA= --------------ms090904010409090202050509-- --===============1332990405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1332990405==-- From p2psip-bounces@ietf.org Wed Jun 20 10:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10tQ-0002xV-Q9; Wed, 20 Jun 2007 10:10:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I10tP-0002r9-ED for p2psip@ietf.org; Wed, 20 Jun 2007 10:10:43 -0400 Received: from wr-out-0506.google.com ([64.233.184.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I10tO-0003v3-5U for p2psip@ietf.org; Wed, 20 Jun 2007 10:10:43 -0400 Received: by wr-out-0506.google.com with SMTP id 36so220281wra for ; Wed, 20 Jun 2007 07:10:40 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=daNsAkbFbZsjGWqFjwJspps2ubtQLEqMRToMb++W1x2O73MwvMjsxVCKM87sMnOuQ1QnC75nt44XZYTGCMRMFsHXotY51wDw1cCGST1RjdP5oPrVudSBWvTKbXIDRVoy9rCAR9WkR2t8FdnyrT/j2otu+n3uRs5NA5sltUEqVNU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=GdBlUkKB+iRCzLgPPUzYL0F3slOhuLNOCvKqQimnty4f9Xw8Sp1E0DM3QEsLVgQP5X+HFP5mr2MXsbw8DJ24G2PYmAePdLTKPYLJ5gp8XxMWmxxojb5AyearIIQY4EayHTCKK5eL/XOyOp5/LDaCbvaMzx7LeM51UJjFD6d3HfQ= Received: by 10.78.184.2 with SMTP id h2mr339267huf.1182348636738; Wed, 20 Jun 2007 07:10:36 -0700 (PDT) Received: by 10.78.56.9 with HTTP; Wed, 20 Jun 2007 07:10:36 -0700 (PDT) Message-ID: <7b683f3f0706200710v71421b75ne2521d58e9987653@mail.gmail.com> Date: Wed, 20 Jun 2007 10:10:36 -0400 From: "Eunsoo Shim" To: "Dean Willis" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: MIME-Version: 1.0 References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> <46778BAE.5010504@teigre.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0370083023==" Errors-To: p2psip-bounces@ietf.org --===============0370083023== Content-Type: multipart/alternative; boundary="----=_Part_91375_492362.1182348636290" ------=_Part_91375_492362.1182348636290 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > > We have two choices as I see it: > > > > 1. Is the AoR supposed to be the equivalent of an email address > > where the whole domain must handled authoritatively by one entity, > > here overlay (which allows 3263 lookups) ? > > > > 2. Or is the AoR supposed to be the equivalent of "use your email > > address as username on my website"? > > > > I think #1 is the general solution, and there might reasonably be a > fallback to behavior #2 under certain fully-disconnected scenarios Yes. that I don't really even want to think about right now because the > overlay-discovery and authentication problems become very, very messy > and make my head hurt. Authentication and encryption are optional with c/s sip. I think a similar principle should be applied to p2psip. That is, p2psip should be able to run with strong security measures or weak security measures depending on the choice of the overlay or the domain administrator or the participants. In some situations, just connectivity is too valuable to give up because of the lack/weakness of security. For example, an ad-hoc network in an emergency situation. p2psip can be very useful for such situations. And the fallback mechanism/overlay may be the right solution for some of the cases. Hope this view may soothe Dean's headache a little bit. Thanks. Eunsoo ------=_Part_91375_492362.1182348636290 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

> We have two choices as I see it:
>
> 1. Is the AoR supposed to be the equivalent of an email address
> where the whole domain must handled authoritatively by one entity,
> here overlay (which allows 3263 lookups) ?
>
> 2. Or is the AoR supposed to be the equivalent of "use your email
> address as username on my website"?
>

I think #1 is the general solution, and there might reasonably be a
fallback to behavior #2 under certain fully-disconnected scenarios

Yes.

that I don't really even want to think about right now because the
overlay-discovery and authentication problems become very, very messy
and make my head hurt.

Authentication and encryption are optional with c/s sip. I think a similar principle should be applied to p2psip. That is, p2psip should be able to run with strong security measures or weak security measures depending on the choice of the overlay or the domain administrator or the participants.
In some situations, just connectivity is too valuable to give up because of the lack/weakness of security. For example, an ad-hoc network in an emergency situation. p2psip can be very useful for such situations. And the fallback mechanism/overlay may be the right solution for some of the cases.
Hope this view may soothe Dean's headache a little bit.


Thanks.

Eunsoo
------=_Part_91375_492362.1182348636290-- --===============0370083023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0370083023==-- From p2psip-bounces@ietf.org Wed Jun 20 10:17:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I110I-0002Mj-12; Wed, 20 Jun 2007 10:17:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I110G-0002Me-ST for p2psip@ietf.org; Wed, 20 Jun 2007 10:17:48 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I110F-0007N3-7I for p2psip@ietf.org; Wed, 20 Jun 2007 10:17:48 -0400 Received: by ug-out-1314.google.com with SMTP id k3so888704ugf for ; Wed, 20 Jun 2007 07:17:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YDwBbSj0zyn3dVayWKEjbsWWCxp+4JgW9zaBlM//l/TL8uh+uF4P9uMovuROKiieAovOFPozFCeHD8Ze2w742J4xb/VuL9tL+XAGJtAbWBkZ3XAzBMi47gkBPCx+cFljKY7AbOQ6UtjPMD8FkUNgk2sVnyZOTohlAw7haqvKUvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nh1iyrg+U2RmoyRcGsIcOKtEnCk70M0AE74uudbp9HWePqbUWxA9D5/j8XQyqDQ7yLuHhSLsrtQmkX/2CWTWHEdPcHtmt5C72kZf53OhrWO+j0nvR0Xq+wUQxNjN4KxQ/zzckgpqCozSDt3zsZ2HbsVl7JguTbVRfRSp0/yyFco= Received: by 10.78.142.14 with SMTP id p14mr333007hud.1182349066216; Wed, 20 Jun 2007 07:17:46 -0700 (PDT) Received: by 10.78.56.9 with HTTP; Wed, 20 Jun 2007 07:17:46 -0700 (PDT) Message-ID: <7b683f3f0706200717yaadc328p2ef4124c117e89c9@mail.gmail.com> Date: Wed, 20 Jun 2007 10:17:46 -0400 From: "Eunsoo Shim" To: "Brian Rosen" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: <00c001c7b29c$a3f0d460$640fa8c0@cis.neustar.com> MIME-Version: 1.0 References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> <46778BAE.5010504@teigre.com> <00c001c7b29c$a3f0d460$640fa8c0@cis.neustar.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1053944692==" Errors-To: p2psip-bounces@ietf.org --===============1053944692== Content-Type: multipart/alternative; boundary="----=_Part_91471_26861865.1182349066147" ------=_Part_91471_26861865.1182349066147 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I think the URI would have not any explicit indicator whether the resource may be over c/s sip network or p2psip network at least the option #1. DNS is likely to be an important tool for discovery of the overlay for a specific domain and thus be able to indicate whether the resource is over c/s sip or p2psip network. This depends on the overlay discovery mechanisms we are going to use. In the architecture I envisioned, interoperation among nodes using c/s sip and p2psip are so seamless, each node does not have to really worry about whether the target resource is using c/s sip or p2psip. If a node is running over p2psip, it just uses the p2p mechanism to send a message to any destination. If a node is running over c/s sip, it uses the c/s sip mechanism. On 6/19/07, Brian Rosen wrote: > > Okay. I like it. > > Is there a way I can look in the URI or the DNS entry for the domain in > the > URI and discover if this is p2p or c/s, or do I blindly try one and then > the > other? > > Brian > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Tuesday, June 19, 2007 11:57 AM > > To: Greger V. Teigre > > Cc: P2PSIP Mailing List > > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > > > > > On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote: > > > > > We have two choices as I see it: > > > > > > 1. Is the AoR supposed to be the equivalent of an email address > > > where the whole domain must handled authoritatively by one entity, > > > here overlay (which allows 3263 lookups) ? > > > > > > 2. Or is the AoR supposed to be the equivalent of "use your email > > > address as username on my website"? > > > > > > > I think #1 is the general solution, and there might reasonably be a > > fallback to behavior #2 under certain fully-disconnected scenarios > > that I don't really even want to think about right now because the > > overlay-discovery and authentication problems become very, very messy > > and make my head hurt. > > > > -- > > Dean > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_91471_26861865.1182349066147 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I think the URI would have not any explicit indicator whether the resource may be over c/s sip network or p2psip network at least the option #1.
DNS is likely to be an important tool for discovery of the overlay for a specific domain and thus be able to indicate whether the resource is over c/s sip or p2psip network. This depends on the overlay discovery mechanisms we are going to use.
In the architecture I envisioned, interoperation among nodes using c/s sip and p2psip are so seamless, each node does not have to really worry about whether the target resource is using c/s sip or p2psip.
If a node is running over p2psip, it just uses the p2p mechanism to send a message to any destination. If a node is running over c/s sip, it uses the c/s sip mechanism.

On 6/19/07, Brian Rosen <br@brianrosen.net> wrote:
Okay.  I like it.

Is there a way I can look in the URI or the DNS entry for the domain in the
URI and discover if this is p2p or c/s, or do I blindly try one and then the
other?

Brian

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
> Sent: Tuesday, June 19, 2007 11:57 AM
> To: Greger V. Teigre
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays
>
>
> On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote:
>
> > We have two choices as I see it:
> >
> > 1. Is the AoR supposed to be the equivalent of an email address
> > where the whole domain must handled authoritatively by one entity,
> > here overlay (which allows 3263 lookups) ?
> >
> > 2. Or is the AoR supposed to be the equivalent of "use your email
> > address as username on my website"?
> >
>
> I think #1 is the general solution, and there might reasonably be a
> fallback to behavior #2 under certain fully-disconnected scenarios
> that I don't really even want to think about right now because the
> overlay-discovery and authentication problems become very, very messy
> and make my head hurt.
>
> --
> Dean
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_91471_26861865.1182349066147-- --===============1053944692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1053944692==-- From p2psip-bounces@ietf.org Wed Jun 20 10:21:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1142-0007s4-Pe; Wed, 20 Jun 2007 10:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1141-0007rz-Hs for p2psip@ietf.org; Wed, 20 Jun 2007 10:21:41 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1140-0000eJ-4k for p2psip@ietf.org; Wed, 20 Jun 2007 10:21:41 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I113q-0004tf-UU; Wed, 20 Jun 2007 09:21:31 -0500 From: "Brian Rosen" To: "'Eunsoo Shim'" , "'Dean Willis'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu><46714D58.7000408@alcatel-lucent.com><0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu><08d401c7ae98$5e945570$9501a8c0@cis.neustar.com><467231F1.4080605@softarmor.com><118801c7b1d3$2101a440$9501a8c0@cis.neustar.com><7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com><46778BAE.5010504@teigre.com> <7b683f3f0706200710v71421b75ne2521d58e9987653@mail.gmail.com> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Wed, 20 Jun 2007 10:21:36 -0400 Message-ID: <03a601c7b346$5109ae20$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7b683f3f0706200710v71421b75ne2521d58e9987653@mail.gmail.com> Thread-Index: AcezRMgf3tuJTNzvTNW9Y3BHon05FQAANf2w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0579949181==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0579949181== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A7_01C7B324.C9F80E20" This is a multi-part message in MIME format. ------=_NextPart_000_03A7_01C7B324.C9F80E20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Authentication and encryption are optional with c/s sip. I think a similar principle should be applied to p2psip. That is, p2psip should be able to run with strong security measures or weak security measures depending on the choice of the overlay or the domain administrator or the participants. In some situations, just connectivity is too valuable to give up because of the lack/weakness of security. For example, an ad-hoc network in an emergency situation. p2psip can be very useful for such situations. And the fallback mechanism/overlay may be the right solution for some of the cases. I'd like to strengthen this. I'd like EVERY implementation to ALWAYS try authentication and encryption. I'd like there to be policy on what ciphersuites are allowed, including fall back to none. I'd like it to be "fall back"; that is you try something stronger, and if you can't establish the connection, you try again with something weaker. I'd like an implementation that didn't implement the security mechanism to fail to interoperate with most implementations. I think that is the right choice for ad-hoc emergency. In MOST cases, the desire really is for secure communications in emergencies. Fallback when some part of the infrastructure fails is acceptable. Brian ------=_NextPart_000_03A7_01C7B324.C9F80E20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Authentication and encryption are optional with c/s sip. I think = a similar principle should be applied to p2psip. That is, p2psip should be = able to run with strong security measures or weak security measures depending = on the choice of the overlay or the domain administrator or the participants. =

In some situations, just connectivity is too valuable to give up because of the lack/weakness of security. For example, an ad-hoc network = in an emergency situation. p2psip can be very useful for such situations. And = the fallback mechanism/overlay may be the right solution for some of the = cases.
I’d like to = strengthen this.

 

I’d like EVERY implementation = to ALWAYS try authentication and encryption.  I’d like there to = be policy on what ciphersuites are allowed, including fall back to none.  = I’d like it to be “fall back”; that is you try something stronger, and = if you can’t establish the connection, you try again with something = weaker.  I’d like an implementation that didn’t implement the security = mechanism to fail to interoperate with most = implementations.

 

I think that is the right choice = for ad-hoc emergency.  In MOST cases, the desire really is for secure = communications in emergencies.  Fallback when some part of the infrastructure = fails is acceptable.

 

Brian

------=_NextPart_000_03A7_01C7B324.C9F80E20-- --===============0579949181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0579949181==-- From p2psip-bounces@ietf.org Wed Jun 20 10:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I117E-0000b6-2i; Wed, 20 Jun 2007 10:25:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I117C-0000UL-G8 for p2psip@ietf.org; Wed, 20 Jun 2007 10:24:58 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I117B-0001s8-TZ for p2psip@ietf.org; Wed, 20 Jun 2007 10:24:58 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I1172-00050K-Ab; Wed, 20 Jun 2007 09:24:48 -0500 From: "Brian Rosen" To: "'Eunsoo Shim'" References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> <46778BAE.5010504@teigre.com> <00c001c7b29c$a3f0d460$640fa8c0@cis.neustar.com> <7b683f3f0706200717yaadc328p2ef4124c117e89c9@mail.gmail.com> Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Wed, 20 Jun 2007 10:24:53 -0400 Message-ID: <03b601c7b346$c6b71b80$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <7b683f3f0706200717yaadc328p2ef4124c117e89c9@mail.gmail.com> Thread-Index: AcezRcOn1r4rXOicSaCzl5B95Ds17gAAKmog X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0526603183==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0526603183== Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B7_01C7B325.3FA57B80" This is a multi-part message in MIME format. ------=_NextPart_000_03B7_01C7B325.3FA57B80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Okay, I like this answer. Does that mean you thing the SRV for the sip service in the DNS will have something that says the domain supports a p2psip overlay? Would you agree with me that "both" (C/S and P2P) is a acceptable, and perhaps common case? Furthermore, does the overlay have some identity beyond the (set of) domains that are in it? If there is, is the identity in the DNS? Brian _____ From: Eunsoo Shim [mailto:eunsooshim@gmail.com] Sent: Wednesday, June 20, 2007 10:18 AM To: Brian Rosen Cc: Dean Willis; Greger V. Teigre; P2PSIP Mailing List Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays I think the URI would have not any explicit indicator whether the resource may be over c/s sip network or p2psip network at least the option #1. DNS is likely to be an important tool for discovery of the overlay for a specific domain and thus be able to indicate whether the resource is over c/s sip or p2psip network. This depends on the overlay discovery mechanisms we are going to use. In the architecture I envisioned, interoperation among nodes using c/s sip and p2psip are so seamless, each node does not have to really worry about whether the target resource is using c/s sip or p2psip. If a node is running over p2psip, it just uses the p2p mechanism to send a message to any destination. If a node is running over c/s sip, it uses the c/s sip mechanism. On 6/19/07, Brian Rosen wrote: Okay. I like it. Is there a way I can look in the URI or the DNS entry for the domain in the URI and discover if this is p2p or c/s, or do I blindly try one and then the other? Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Tuesday, June 19, 2007 11:57 AM > To: Greger V. Teigre > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > > On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote: > > > We have two choices as I see it: > > > > 1. Is the AoR supposed to be the equivalent of an email address > > where the whole domain must handled authoritatively by one entity, > > here overlay (which allows 3263 lookups) ? > > > > 2. Or is the AoR supposed to be the equivalent of "use your email > > address as username on my website"? > > > > I think #1 is the general solution, and there might reasonably be a > fallback to behavior #2 under certain fully-disconnected scenarios > that I don't really even want to think about right now because the > overlay-discovery and authentication problems become very, very messy > and make my head hurt. > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_03B7_01C7B325.3FA57B80 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Okay, I like this answer.  = Does that mean you thing the SRV for the sip service in the DNS will have something = that says the domain supports a p2psip overlay?  Would you agree with me that = “both” (C/S and P2P) is a acceptable, and perhaps common = case?

 

Furthermore, does the overlay have = some identity beyond the (set of) domains that are in it?  If there is, = is the identity in the DNS?

 

Brian

 

From: = Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: Wednesday, June 20, = 2007 10:18 AM
To: Brian Rosen
Cc: Dean Willis; Greger = V. Teigre; P2PSIP Mailing List
Subject: Re: [P2PSIP] = Concepts issue: Domains and Overlays

 

I think the = URI would have not any explicit indicator whether the resource may be over c/s sip network or p2psip network at least the option #1.
DNS is likely to be an important tool for discovery of the overlay for a specific domain and thus be able to indicate whether the resource is = over c/s sip or p2psip network. This depends on the overlay discovery mechanisms = we are going to use.
In the architecture I envisioned, interoperation among nodes using c/s = sip and p2psip are so seamless, each node does not have to really worry about = whether the target resource is using c/s sip or p2psip.
If a node is running over p2psip, it just uses the p2p mechanism to send = a message to any destination. If a node is running over c/s sip, it uses = the c/s sip mechanism.

On 6/19/07, Brian Rosen <br@brianrosen.net> wrote:

Okay.  I like it.

Is there a way I can look in the URI or the DNS entry for the domain in = the
URI and discover if this is p2p or c/s, or do I blindly try one and then = the
other?

Brian

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]<= br> > Sent: Tuesday, June 19, 2007 11:57 AM
> To: Greger V. Teigre
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays
>
>
> On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote:
>
> > We have two choices as I see it:
> >
> > 1. Is the AoR supposed to be the equivalent of an email = address
> > where the whole domain must handled authoritatively by one = entity,
> > here overlay (which allows 3263 lookups) ?
> >
> > 2. Or is the AoR supposed to be the equivalent of "use = your email
> > address as username on my website"?
> >
>
> I think #1 is the general solution, and there might reasonably be = a
> fallback to behavior #2 under certain fully-disconnected scenarios =
> that I don't really even want to think about right now because = the
> overlay-discovery and authentication problems become very, very = messy
> and make my head hurt.
>
> --
> Dean
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

 

------=_NextPart_000_03B7_01C7B325.3FA57B80-- --===============0526603183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0526603183==-- From p2psip-bounces@ietf.org Wed Jun 20 11:11:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11qD-0002lp-SJ; Wed, 20 Jun 2007 11:11:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I11qC-0002lU-6C for p2psip@ietf.org; Wed, 20 Jun 2007 11:11:28 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I11qB-0007aR-AG for p2psip@ietf.org; Wed, 20 Jun 2007 11:11:28 -0400 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 17:11:26 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 17:11:26 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 17:11:25 +0200 Message-ID: <46794413.7000205@telecomitalia.it> Date: Wed, 20 Jun 2007 17:13:23 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> In-Reply-To: <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> X-OriginalArrivalTime: 20 Jun 2007 15:11:25.0216 (UTC) FILETIME=[44D74200:01C7B34D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: Emil Ivov , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0155361387==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0155361387== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040800040508090209040003" This is a cryptographically signed message in MIME format. --------------ms040800040508090209040003 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Philip Matthews wrote: > 1) It seems that XPP is a transport protocol. > That is, it provides reliable, in-order delivery of messages, along with > segmentation > and re-assembly so messages will fit within the Path MTU. > However, unlike TCP which is stream-oriented, XPP seems to be > message-oriented. > In that regards, XPP seems more like SCTP. > Though XPP runs over UDP, UDP seems to be just used for encapsulation, > and XPP could run directly over IP if there are no NATs in the path. > Is this correct? In a way yes, probably. Right now we are only using UDP for encapsulation (and checksum), pretty much the same way RTP is using it. > 2) It seems that an XPP session is intended to be set up using SIP > signaling, > in a way similar to how SIP can set up RTP sessions. > That is, the SDP body of the SIP message, rather than specifying RTP, > would specify XPP. > Furthermore, it seems that you expect ICE to used with SIP to handle the > NAT > traversal aspects, including the selection of a transmission path. > Is this correct? (I will assume "yes" in the rest of my questions > below). Yes, XPP is negotiated just like RTP. Anyway, we don't want to mandate ICE; we recommend it, because it may help in many ways (especially to find best paths), but we want to specify something as simple as possible which could work in as many cases as possible. XPP without ICE is supposed to work when peers are behind firewalls and NATs compliant with RFC 4787 performing endpoint-dependent filtering. > 3) Why do you think we need XPP as a new transport protocol, rather than > using TCP or SCTP? > You argue that UDP is easier than TCP to set up through NATs, but Saikat > Guha has shown > that TCP connections can be reliably set up through NATs in about 90% of > the time, and 100% > of the time through common pairs of NATs, so I don't really buy this > argument. Especially when > the BEHAVE recommendations on TCP will be published as an RFC soon. > Moreover, one can easily work around this problem if desired by running > TCP over UDP, > in the same way that you run XPP over UDP. Answered separately. > 4) If XPP is set up using ICE, then why is a simultaneous session > establishment important? > If ICE has already handled the UDP hole-punching, then the simultaneous > nature > is unimportant. We wouldn't want to mandate ICE. Would you? (I'm quite curious to know what others think about this) > 5) If XPP is set up using ICE, then presumably the NAT bindings are kept > alive using > STUN indications as specified in ICE. Thus the keepalives in XPP are > used for something > other than keeping NAT bindings open. My guess is they are just there to > make sure the far-end > software is still alive. Am I correct? That, and keep NAT bindings alive if ICE is not used. > 6) XPP uses 16-bit endpoint identifiers. What are these? I am guessing > that these are not > peer IDs as described in the Concepts draft, since they are so short. > Is this correct? Yes, local and remote IDs have noting to do with peer IDs. They are used to identify XPP sessions. Think of them as the dialog tags in SIP. > How are these allocated? Locally, one per endpoint, the same way SIP dialog tags get generated. > 7) Is an ACK a response to a request? Or must a response be something else? An ACK is not a response. Requests and responses are messages which can be fragmented; each fragment is acked. > Say I wanted to transport a file from one endpoint to another > (most IM clients today support the ability to transfer a file to the > client that one is talking or IMing with) > -- how would I do this? Well, in such a case I'd establish an MSRP session with the other guy. There is no reason why this should be handled by the peer protocol. We could of course craft some way of doing it with XPP, but that would be unnecessary and redundant. Instead, we should simply be seeing file transfer as call sessions. > 8) Are you assuming that the security is handled by the signaling > protocol (e.g., SIP), > so there is no need to handle this at the XPP layer? No, not at all. Current proposal acknowledges the need to add support for DTLS, but security issues definitely require more investigation. > 9) How and when do you see XPP sessions being set up? That is, say peer > X and peer Y are > behind (different) NATs and there is no XPP session between them? How > does this session get > set up? How do the signaling messages get transported from X to Y? Sessions are initiated and negotiated with SIP, which, in the case of P2PSIP, is routed by the overlay. This is explained in detail in our other draft. > 10) It seems that there is no provision in XPP for XPP messages to be > transported hop-by-hop. > That is, if peer X and peer Y want to transport a message using XPP, > they have to first set up an > XPP session. > How do you see this working if X and Y just want a quick message > exchange? Say X wants to send > a short 40-byte request and get back an equally short answer. Does X > have to set up an XPP session > with Y first? It seems to me that session setup is a pretty > heavy-weight operation (e.g., send one or more > STUN requests and receive one or more STUN responses to gather ICE > candidates, then send a SIP INVITE, > get back a 100 TRYING, get back a 200 OK, send an ACK, send ICE > connectivity checks to various addresses, > receive ICE connectivity checks on various addresses, send and receive a > XPP handshake, > then finally send the 40-byte query and get back the 40-byte response). Hop-by-hop routing of requests and responses is supported, but is specified in XPP extensions (see e.g. PCAN) as it is generally specific to the implemented algorithm. -- Ciao, Enrico --------------ms040800040508090209040003 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMTUxMzIzWjAjBgkqhkiG9w0BCQQxFgQUgAupxllX sNC0xqZOCbqDneNezjgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAG0GXMWsdGCrXcX7YuochN8TVT4bGvfLSvfg4ROklBI94R0DEv7Z4c9N cFDY5AiV/bwHi/EwsmGnAsPYbrPO3wKhVV4blr9IKq299NoGjtOXOPrb7pNmNR60ANIudrCw 0MQcPNx6dw7hyaw+X9GGJHSK0nCVghmwqqrCmMT2gloWMqyXqrHg9nINGDREsbLTVp4m/nYm rDiDPJYsXkB8ljfxa7ImDdoG/WmSIlo20FeEr1nEIPpcZVVamShTWDRy6zmYE9sC7qqFVgwm FLrMH1+6NM4rkHmGyIdG0YQSRy5yxVpkPvdoeHozZ37Ljnw0IM86S3wBQijmgtMSg3xyUVgA AAAAAAA= --------------ms040800040508090209040003-- --===============0155361387== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0155361387==-- From p2psip-bounces@ietf.org Wed Jun 20 14:02:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14VJ-0007vh-Fb; Wed, 20 Jun 2007 14:02:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14VI-0007vc-0C for p2psip@ietf.org; Wed, 20 Jun 2007 14:02:04 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14VH-0002vh-LB for p2psip@ietf.org; Wed, 20 Jun 2007 14:02:03 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I14VH-0003Hr-03; Wed, 20 Jun 2007 14:02:03 -0400 In-Reply-To: <4678E6B4.8090000@telecomitalia.it> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 14:02:03 -0400 To: Enrico Marocco X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Emil Ivov , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Enrico: If we decide that TCP is the right way to go, then I would strongly suggest that we ALWAYS use ICE-TCP to set up the TCP connection, even if one or both peers have public addresses. If we did this, then the connection would be set up correctly even in these cases. I make this suggestion for the following reasons: a) In many many cases, it is difficult or impossible to know whether a node is "behind" a NAT or not. b) ICE-TCP has advantages other than NAT traversal. For example, it also allows you to select between an IPv4 and an IPv6 address. I agree that ICE is not a trivial protocol. But I think it is the right thing to do, because it solves an important problem, and attempts to make it a SHOULD will just lead to difficulties. One concern I have with XPP is similar to my concern with the suggestion to use RDP. There has be A LOT of work put into TCP, and it is a very well understood protocol. A lot of this work has since gone into SCTP and DCCP. Inventing a new transport protocol is not a trivial matter, and I think we will get strong push-back from the IESG if we try to propose a new one without looking hard at the existing choices. Though you think that XPP is simple right now, how much attention have you paid to all the corner cases? And what about things like congestion control, path MTU discovery, and the like? If our peer protocol becomes successful, then these are all things that it will need to have. After all, peer-to-peer traffic is a very large and growing part of Internet traffic today, and if we are successful, then we will likely capture a large part of this traffic. - Philip On 20-Jun-07, at 04:35 , Enrico Marocco wrote: > Philip, let me firstly answer the question which hits the main point > separately. Inline. > > Philip Matthews wrote: >> 3) Why do you think we need XPP as a new transport protocol, >> rather than >> using TCP or SCTP? >> You argue that UDP is easier than TCP to set up through NATs, but >> Saikat >> Guha has shown >> that TCP connections can be reliably set up through NATs in about >> 90% of >> the time, and 100% >> of the time through common pairs of NATs, so I don't really buy this >> argument. Especially when >> the BEHAVE recommendations on TCP will be published as an RFC soon. > > The problem with TCP is that the mechanism you need to establish a > connection heavily depends on the environment. The simultaneous > handshake, for example, is generally required to establish the > connection if the two peers are behind NATs, but fails 50% of the > times > if one isn't (because the non-natted peer would send back a RST if it > hasn't started sending SYNs yet) and ~100% of the times if none of > them > is (because most likely one of the peers would receive a SYN on an > uninitialized socket). So, basically, it is true that ~88% of the > times > you can successfully establish a TCP connection between natted peers, > but to do that you really need to implement something like ICE-TCP to > find every time the effective way to do that. > > We decided to go for a compromise to keep ICE a "SHOULD", and defined > the simultaneous establishment mechanism over UDP, which is > supposed to > work both if the peers are behind 4787-compliant NATs and if any of > them > has a public address. Note that the full XPP implementation > (including > session establishment, fragmentation, reliability and request-response > matching) is just about 2500 lines of code. > > Then, using UDP it is possible to turn reliability off; although it > sounds interesting especially in distributed overlays, I think it > should > be discussed separately. > >> Moreover, one can easily work around this problem if desired by >> running >> TCP over UDP, >> in the same way that you run XPP over UDP. > > I don't see XPP as a general purpose transport protocol; it is really > conceived for executing DHT operations, and in this is similar to P2PP > (we even came out with the same encoding). > > Finally, TCP over UDP would bring too much complexity, and too much > unnecessary and redundant functionality, which contradicts our > design goals. > > -- > Ciao, > Enrico _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 14:12:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14fI-0001uz-Ie; Wed, 20 Jun 2007 14:12:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14fH-0001uK-CJ for p2psip@ietf.org; Wed, 20 Jun 2007 14:12:23 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I14fF-0004aU-TJ for p2psip@ietf.org; Wed, 20 Jun 2007 14:12:23 -0400 Received: from lappy ([68.26.53.4]) by quinthar.com for ; Wed, 20 Jun 2007 11:12:14 -0700 From: "David Barrett" To: "'Enrico Marocco'" , "'Brian Rosen'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 11:12:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <46792EB5.3070700@telecomitalia.it> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcezQJOpIFjYZQZpQQ2b8MXhT6qDLQAJDxLw X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > Yes, this is indeed a big question. I'm curious to see what people > think about ICE; on one hand, it is pretty difficult to implement and > to integrate with existing libraries, on the other hand, it is the most > complete mechanism for NAT traversal. For the first version of our > solution we tried to keep it optional and accepted a cheap compromise > which should /often/ work (and which does not preclude ICE). It's a > trade off... I would really like to get feedback on this. I certainly agree with the first point. But has "most complete mechanism for NAT traversal" been really demonstrated yet? Are there any empirical studies (testing how good it "actually" is in the real world, rather than inferring how good it "should" be) that have studied ICE outside a limited lab environment? Furthermore, until it's been shown that multiple, separately-developed implementations actually interoperate, I'd be hesitant to even call ICE well-specified. So far as I can tell, there's a lot of optimism, hope, and hard work, but I've yet to see the real world confirmation. Can someone point me to this? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 14:16:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14ix-0006ih-Ux; Wed, 20 Jun 2007 14:16:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14iw-0006iH-UM for p2psip@ietf.org; Wed, 20 Jun 2007 14:16:10 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14iv-0005Pa-NQ for p2psip@ietf.org; Wed, 20 Jun 2007 14:16:10 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I14it-0007rA-1C; Wed, 20 Jun 2007 14:16:07 -0400 In-Reply-To: <4678F170.7030309@sip-communicator.org> References: <9FA16888AD1BF64ABCE6C2532CCEB98A0275AD4F@xmb-sjc-219.amer.cisco.com> <4678F170.7030309@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 14:16:07 -0400 To: Emil Ivov X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 20-Jun-07, at 05:20 , Emil Ivov wrote: > >> b) Did you consider SCTP ? Any glaring problems ? > > SCTP has a lot of functionality that we don't need, such as: > recording paths, transporting multiple flows simultaneously, etc. > Then, I am also wondering how many of the existing NATs and > firewalls would let it pass. I suspect that you are right in saying that many NATs and firewalls do not currently support SCTP traffic (this may change if P2PSIP selects SCTP as its transport protocol?). However, it is also true that many (all?) NATs and firewalls do not currently support XPP traffic. The solution that you adopted for XPP (= encapsulate it inside UDP) also works for SCTP. Furthermore, it would be possible to define an ICE-for-SCTP that would detect if the intervening NATs support SCTP, and eliminate the UDP encapsulation wherever that is possible. A similar idea is being investigated as part of the NAT Traversal for HIP work, which has a similar problem (= most NATs today don't support HIP). - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 14:29:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14vO-0007N5-Mf; Wed, 20 Jun 2007 14:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I14vN-0007LA-9D for p2psip@ietf.org; Wed, 20 Jun 2007 14:29:01 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I14vM-0000LG-W8 for p2psip@ietf.org; Wed, 20 Jun 2007 14:29:01 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I14vB-0007vO-7o; Wed, 20 Jun 2007 13:28:49 -0500 From: "Brian Rosen" To: "'David Barrett'" , "'Enrico Marocco'" References: <46792EB5.3070700@telecomitalia.it> Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 14:28:56 -0400 Message-ID: <047601c7b368$df0b2a10$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcezQJOpIFjYZQZpQQ2b8MXhT6qDLQAJDxLwAADqveA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org There is a fair amount of work on investigating the characteristics of deployed NATs, which then guided the ICE effort. It's a moving target. There are a number of commercial STUN servers out there, which is a big piece of ICE. I think the direct answer to your question is that there is not a lot of hard data on the effectiveness of ICE, but I would bet on that a whole lot more than any new, supposedly simpler set of NAT traversal techniques, even in more restricted use cases. Brian > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Wednesday, June 20, 2007 2:12 PM > To: 'Enrico Marocco'; 'Brian Rosen' > Cc: 'Emil Ivov'; 'Philip Matthews'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Peer protocol, DHT and running code > > > -----Original Message----- > > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > > > Yes, this is indeed a big question. I'm curious to see what people > > think about ICE; on one hand, it is pretty difficult to implement and > > to integrate with existing libraries, on the other hand, it is the most > > complete mechanism for NAT traversal. For the first version of our > > solution we tried to keep it optional and accepted a cheap compromise > > which should /often/ work (and which does not preclude ICE). It's a > > trade off... I would really like to get feedback on this. > > I certainly agree with the first point. But has "most complete mechanism > for NAT traversal" been really demonstrated yet? > > Are there any empirical studies (testing how good it "actually" is in the > real world, rather than inferring how good it "should" be) that have > studied > ICE outside a limited lab environment? > > Furthermore, until it's been shown that multiple, separately-developed > implementations actually interoperate, I'd be hesitant to even call ICE > well-specified. > > So far as I can tell, there's a lot of optimism, hope, and hard work, but > I've yet to see the real world confirmation. Can someone point me to > this? > > -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 14:38:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I154H-0002fe-8A; Wed, 20 Jun 2007 14:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I154G-0002fZ-RM for p2psip@ietf.org; Wed, 20 Jun 2007 14:38:12 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I154G-0001fa-Gq for p2psip@ietf.org; Wed, 20 Jun 2007 14:38:12 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I154E-0005hG-31; Wed, 20 Jun 2007 14:38:11 -0400 In-Reply-To: <4678FED7.4040103@telecomitalia.it> References: <4674F5ED.9070000@telecomitalia.it> <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> <4678FED7.4040103@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <71DB479B-70E1-4434-8F4A-EE70F8AFD9C8@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 14:38:11 -0400 To: Enrico Marocco X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 20-Jun-07, at 06:17 , Enrico Marocco wrote: > Philip Matthews wrote: >> Furthermore, using a transport protocol other that TCP or UDP >> means that >> we have to do all the work to define >> how SIP and other protocols get transported over this transport >> protocol. I don't think we should underestimate >> how much time that would take. First, a small correction. SCTP transport of SIP has already been defined: RFC 4168. Now on to the main discussion... > > Actually, I don't think we really need to tunnel SIP over the peer > protocol. In the PCAN draft > (http://tools.ietf.org/id/draft-marocco-p2psip-xpp-pcan-00.txt) we > address the issue of NAT traversal the following way: > > 1) clients that need to do so would keep sip-outbound connections with > peers. > 2) peers that handle sip-outbound flows for some clients would store > routing records containing the full path to the client. > > Here's an example: imagine client C registers with peer B and > establishes an outbound flow with it. C's routing record (inserted in > the overlay by B) will contain two hops: B's contact and C's > contact/gruu. In case B is also suffering restricted connectivity, > this > would mean that it too would have an outbound flow with another peer, > say A. In this case (which is pretty unlikely, because if B is > restricted it probably won't be able to receive REGISTER requests form > C), C's routing record would contain three hops. > > Having said that, it's probably worth noting that we have not yet > decided whether this approach is better compared to routing SIP > messages > inside the overlay. Both are easily implementable with XPP and XPP- > PCAN > so I guess we'd need to discuss this further before we really made up > our minds. I assume that your peers have public IP addresses. If so, this is "superpeer" approach that is discussed in the "NATs and Overlays" draft and in my NAT traversal presentation in Prague. Dean has also suggested a similar approach. We have had some discussions of the pros and cons of this approach vs the approach that Eric and I have been advocating of routing messages through a partial mesh of connections. The whole goal of draft-matthews-p2psip-nats-and-overlays-01 is to discuss these two approaches and their pros and cons. Feedback on that draft would be much appreciated, and would help the WG decide on a direction. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 14:45:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15Ay-0004Kg-AV; Wed, 20 Jun 2007 14:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15Aw-0004IE-R2 for p2psip@ietf.org; Wed, 20 Jun 2007 14:45:06 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15Aw-0002fb-FM for p2psip@ietf.org; Wed, 20 Jun 2007 14:45:06 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I15Au-0006hV-2t; Wed, 20 Jun 2007 14:45:05 -0400 In-Reply-To: <46792EB5.3070700@telecomitalia.it> References: <4674F5ED.9070000@telecomitalia.it><7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <037601c7b339$acaf35e0$640fa8c0@cis.neustar.com> <46792EB5.3070700@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E089E10-E740-4190-B4CD-1944AFEE49E3@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 14:45:04 -0400 To: Enrico Marocco X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'Emil Ivov' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 20-Jun-07, at 09:42 , Enrico Marocco wrote: > Brian Rosen wrote: >> I am also bothered by ICE as a should. There is a whole lot of >> effort that >> was put into making ICE work in as many circumstances as possible, >> and I >> think the code size is not going to be much of an issue. It's >> going to be >> common to have ICE implementations with any SIP implementation. I >> don't >> think investing much effort in ICE-light is worthwhile. > > Yes, this is indeed a big question. I'm curious to see what people > think about ICE; on one hand, it is pretty difficult to implement and > to integrate with existing libraries, on the other hand, it is the > most > complete mechanism for NAT traversal. For the first version of our > solution we tried to keep it optional and accepted a cheap compromise > which should /often/ work (and which does not preclude ICE). It's a > trade off... I would really like to get feedback on this. Personally, I think we should just use ICE. Yes, it is complex, but it is solving a complex problem, and the solution works well. The problem with other "cheaper" solutions is that they often break, and break unexpectedly. It might be useful to cite a recent post by Dan Wing to the BEHAVE list: http://www1.ietf.org/mail-archive/web/behave/current/msg02396.html Read the rest of the messages in the thread for more details. >>> 1. ICE works. This has been well demonstrated by its successful >>> deployment on the Internet by millions of endpoints. It works >>> without explicit support by subscriber's NATs or ISP's NATs. >>> >> >> Just curious, what statistics are available on ICE's >> real-world usage and NAT-penetration success rates? Specifically: >> >> - How did you come up with the "millions of endpoints" number? >> > > GoogleTalk's API, Google Talk itself, Microsoft's Windows Live > Messenger (formerly called MSN), and Yahoo Messenger all use > ICE. > > >> - What does "works" mean? (I'd suggest this be measured in >> "direct peer connectivity ratio" and "connection setup time", >> but any measure will do.) >> > > I found this, "Improving ICE Service Selection in a P2P System > using the Gradient Topology", > http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf > which includes the following quote: > > [...] Google's estimate that 8% of the GoogleTalk traffic > is routed using relay nodes. > > which cites > Google. Google talk, Accessed, Feb 22, 2007. > http://code.google.com/apis/talk/libjingle > > which leads one to: > http://code.google.com/apis/talk/libjingle/important_concepts.html - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 15:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15Yz-0007O7-3F; Wed, 20 Jun 2007 15:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15Yy-0007MK-Ae for p2psip@ietf.org; Wed, 20 Jun 2007 15:09:56 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15Yx-0007J8-IF for p2psip@ietf.org; Wed, 20 Jun 2007 15:09:56 -0400 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:09:54 +0200 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:09:54 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:09:53 +0200 Message-ID: <46797C8A.6070600@telecomitalia.it> Date: Wed, 20 Jun 2007 21:14:18 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> In-Reply-To: <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> X-OriginalArrivalTime: 20 Jun 2007 19:09:53.0632 (UTC) FILETIME=[95524600:01C7B36E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Emil Ivov , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1825508757==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1825508757== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040300090003010407000904" This is a cryptographically signed message in MIME format. --------------ms040300090003010407000904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Philip Matthews wrote: > If we decide that TCP is the right way to go, then I would strongly suggest > that we ALWAYS use ICE-TCP to set up the TCP connection, > even if one or both peers have public addresses. If we did this, > then the connection would be set up correctly even in these cases. I totally agree. If we chose TCP, then we would definitely need to mandate ICE-TCP. > I make this suggestion for the following reasons: > a) In many many cases, it is difficult or impossible to know whether a node > is "behind" a NAT or not. Yes, that's and issue especially for TCP. > b) ICE-TCP has advantages other than NAT traversal. For example, > it also allows you to select between an IPv4 and an IPv6 address. Yep. > I agree that ICE is not a trivial protocol. But I think it is the right > thing to do, > because it solves an important problem, and attempts to make it a SHOULD > will just lead to difficulties. Unfortunately I don't have such clear ideas. Maybe listing some of those difficulties may help me and others to better understand. > One concern I have with XPP is similar to my concern with the > suggestion to use RDP. > There has be A LOT of work put into TCP, and it is a very well > understood protocol. > A lot of this work has since gone into SCTP and DCCP. Inventing a new > transport > protocol is not a trivial matter, and I think we will get strong > push-back from the IESG if > we try to propose a new one without looking hard at the existing choices. > > Though you think that XPP is simple right now, how much attention have > you paid > to all the corner cases? And what about things like congestion control, > path MTU discovery, > and the like? If our peer protocol becomes successful, then these are > all things that it > will need to have. Well, path MTU discovery may be done using ICMP or the default 1500 value may be adopted, as for SIP. Congestion control is not an issue, because we send fragments one by one, only after the previous fragment has been acked. Yes, that's not much efficient, but if fits well in our restricted scope (i.e. for implementing DHTs). > After all, peer-to-peer traffic is a very large and > growing part > of Internet traffic today, and if we are successful, then we will likely > capture a large > part of this traffic. I agree here too. By the way, not that it really matter, but, IIRC some of the most popular p2p applications (emule and azureus) use UDP to maintain the internal DHT, don't they? -- Ciao, Enrico --------------ms040300090003010407000904 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMTkxNDE4WjAjBgkqhkiG9w0BCQQxFgQUefKwuUgN /6pJ4OmV+dfZ5L2U0lEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAHfPlWSeig5V9O9o1p46uA85fGKFEe4KQgre40lXaw38oj75c5SQkKOV CHudH/O3XbiM5S+I+RzfOlUs77Qj0heE6KvGrr5xbe4CW4+pmNrvWnlWe5HM6yy+wCzMKPSu yXSHcX0nc91DT9aVokkY6PCcaPIn7cDpSxRMzWDMg3wSZgFUx5fPHFOxnhzFCm4VkO6sVDI9 B0O0YBM0YcsEwf9uugXGzKnCaKugzIYkm9d9B7icGtEn7h8RxJ9Cf+JWQpIBGTi49ZVjll8j ORCtjJuK4X+TudiHFmN65pgNNvKUulTZrl01ns9cTm9u+hPFiQruaCcej0fLyJ4q0eGUa1sA AAAAAAA= --------------ms040300090003010407000904-- --===============1825508757== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1825508757==-- From p2psip-bounces@ietf.org Wed Jun 20 15:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15en-0002OW-NQ; Wed, 20 Jun 2007 15:15:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I15el-0002O9-R2 for p2psip@ietf.org; Wed, 20 Jun 2007 15:15:55 -0400 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I15el-0000da-1a for p2psip@ietf.org; Wed, 20 Jun 2007 15:15:55 -0400 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:15:53 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:15:53 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 21:15:52 +0200 Message-ID: <46797DF0.3010501@telecomitalia.it> Date: Wed, 20 Jun 2007 21:20:16 +0200 From: Enrico Marocco User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <67BCA82D-C9AD-47F2-B947-F0A93BA7FB00@magma.ca> <4678FED7.4040103@telecomitalia.it> <71DB479B-70E1-4434-8F4A-EE70F8AFD9C8@magma.ca> In-Reply-To: <71DB479B-70E1-4434-8F4A-EE70F8AFD9C8@magma.ca> X-OriginalArrivalTime: 20 Jun 2007 19:15:52.0559 (UTC) FILETIME=[6B422FF0:01C7B36F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0577040080==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0577040080== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010605030403090500040909" This is a cryptographically signed message in MIME format. --------------ms010605030403090500040909 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Philip Matthews wrote: >> Actually, I don't think we really need to tunnel SIP over the peer >> protocol. In the PCAN draft >> (http://tools.ietf.org/id/draft-marocco-p2psip-xpp-pcan-00.txt) we >> address the issue of NAT traversal the following way: >> >> 1) clients that need to do so would keep sip-outbound connections with >> peers. >> 2) peers that handle sip-outbound flows for some clients would store >> routing records containing the full path to the client. >> >> Here's an example: imagine client C registers with peer B and >> establishes an outbound flow with it. C's routing record (inserted in >> the overlay by B) will contain two hops: B's contact and C's >> contact/gruu. In case B is also suffering restricted connectivity, this >> would mean that it too would have an outbound flow with another peer, >> say A. In this case (which is pretty unlikely, because if B is >> restricted it probably won't be able to receive REGISTER requests form >> C), C's routing record would contain three hops. >> >> Having said that, it's probably worth noting that we have not yet >> decided whether this approach is better compared to routing SIP messages >> inside the overlay. Both are easily implementable with XPP and XPP-PCAN >> so I guess we'd need to discuss this further before we really made up >> our minds. > > I assume that your peers have public IP addresses. No, not all peers need to have public addresses. Restricted peers receive SIP requests on sip-outbound connections. > If so, this is "superpeer" approach that is discussed in the "NATs and > Overlays" draft > and in my NAT traversal presentation in Prague. Dean has also suggested > a similar approach. > > We have had some discussions of the pros and cons of this approach vs > the approach > that Eric and I have been advocating of routing messages through a > partial mesh of connections. > > The whole goal of draft-matthews-p2psip-nats-and-overlays-01 is to > discuss these two approaches > and their pros and cons. Feedback on that draft would be much > appreciated, and would help > the WG decide on a direction. Actually our proposal uses a partial mesh too. The difference is that SIP messages do not need to follow peer protocol paths. -- Ciao, Enrico --------------ms010605030403090500040909 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIwMTkyMDE2WjAjBgkqhkiG9w0BCQQxFgQUNglfxFqv hQSQly3Tp3ZynAHFuf4wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAIa72/J+iyCN9tkof+RQXJgMVuu/kkTHg5LKL8rdOh99mDxzrSFSPIom TDe3pSB57H8iofPpOUdcCMbGqZGxQFOwnC8jAvIP4df4JhfyUDOBgzUk6oP7aDDN6bP9guw4 2VewiSViticVDfMStcJoUh/dLC2ZLXNU3he6PEIamqlVU9Ul5wVRgIKNHAbcgKr5/KQh9kcu FWUOXUBGrIxFwNYxI6WI08w5plhRcvZOu0FvL0WUGzsLiL3PQ/MQRoreDm7qtykImWJnSzX1 BoDNkm4ya/Tb7VjrdV8ihTMyIv25ggkvyKXl+c+/WwolTYQJzrfoq5MA2o2e/XJIKkgJLvsA AAAAAAA= --------------ms010605030403090500040909-- --===============0577040080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0577040080==-- From p2psip-bounces@ietf.org Wed Jun 20 15:57:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16J6-000582-Tu; Wed, 20 Jun 2007 15:57:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16J5-00057x-Oo for p2psip@ietf.org; Wed, 20 Jun 2007 15:57:35 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I16J2-0000lG-3m for p2psip@ietf.org; Wed, 20 Jun 2007 15:57:35 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Wed, 20 Jun 2007 12:57:28 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Enrico Marocco'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 12:57:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcezayIzCcdWWOdYRmmL8OJaaHGMGgACPeTA In-Reply-To: <0E089E10-E740-4190-B4CD-1944AFEE49E3@magma.ca> X-Spam-Score: 0.5 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'Emil Ivov' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > On 20-Jun-07, at 09:42 , Enrico Marocco wrote: > > It might be useful to cite a recent post by Dan Wing to the BEHAVE list: > http://www1.ietf.org/mail-archive/web/behave/current/msg02396.html > Read the rest of the messages in the thread for more details. > > >>> 1. ICE works. This has been well demonstrated by its successful > >>> deployment on the Internet by millions of endpoints. It works > >>> without explicit support by subscriber's NATs or ISP's NATs. > >>> > >> > >> Just curious, what statistics are available on ICE's > >> real-world usage and NAT-penetration success rates? Specifically: > >> > >> - How did you come up with the "millions of endpoints" number? > > > > GoogleTalk's API, Google Talk itself, Microsoft's Windows Live > > Messenger (formerly called MSN), and Yahoo Messenger all use > > ICE. Don't forget later in the thread: [Dan] "ICE isn't finished, and early ICE versions are not compatible with each other. Thus, there isn't much hope those different networks would be compatible until until ICE has gone to RFC or if those networks had worked out a version of ICE they mutually agreed they would interoperate with (thus creating a defacto standard)." In other words, there are zero endpoints using the ICE protocol (because it doesn't even exist yet), and millions of endpoints that have protocols somewhat like some version of ICE. > >> - What does "works" mean? (I'd suggest this be measured in > >> "direct peer connectivity ratio" and "connection setup time", > >> but any measure will do.) > >> > > > > I found this, "Improving ICE Service Selection in a P2P System > > using the Gradient Topology", > > http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf > > which includes the following quote: > > > > [...] Google's estimate that 8% of the GoogleTalk traffic > > is routed using relay nodes. > > > > which cites > > Google. Google talk, Accessed, Feb 22, 2007. > > http://code.google.com/apis/talk/libjingle > > > > which leads one to: > > http://code.google.com/apis/talk/libjingle/important_concepts.html Likewise, later in that same thread: [Dan] "Google's analysis is based on their own (GoogleTalk) network, I would expect -- not GoogleTalk-to-something-else. I expect their 92% number is based on how often two users, each behind NATs with the 'Address and Port-Dependent Mapping' property (RFC4787) attempt to talk with each other (this property was formerly called 'symmetric NAT'). With ICE, since approximately ice-10, that is the only case that causes a media relay to be utilized." In other words, those numbers aren't measured, they're guesses. Which brings me back to my original point that ICE hasn't been standardized, and hasn't been measured in the real world. Thus it's reasonable to be skeptical of its claims until it's been demonstrated that the standard is sufficiently-well defined that a "clean" implementation will actually interoperate, and actually solve its intended job. So far as I can tell, neither of these have been proven, and until they have, it's reasonable to consider alternatives. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 16:09:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16Uu-0007FA-OB; Wed, 20 Jun 2007 16:09:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16Ut-0007F4-C8 for p2psip@ietf.org; Wed, 20 Jun 2007 16:09:47 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16Us-0003Pq-Ru for p2psip@ietf.org; Wed, 20 Jun 2007 16:09:47 -0400 Received: by wr-out-0506.google.com with SMTP id 36so335273wra for ; Wed, 20 Jun 2007 13:09:46 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=dfuG0luphi5/Q5JX9YI5S+ha6S3of6GaLOh6ZRPPTs9vygTjJ2yr+HWjBvXAOKGwN5WDOKiaL5IWF2lRxgyuNtGtcDezw0dHYOJcR8SehWZDQj8hTrpJznwQ3chMPd6ezfZsoAA0cC95fqsku1ooOlBEhn9wPCZlWPvEGtHUTIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=DTWMyrRIbN82bnK0RQiqDo8wAvEbmM+CUXvHq37wXwwnuh3rfKl3raHEvsfpkPH/013vuOItiE54sVMX54G35JdOI2gXj/nT8NsITqy2Jc4PShrn3DoIOJPeDEYwp+RopkKq4IBeq5F3lwmT59+HYaESkXCskyybVu1QxGHNKgg= Received: by 10.100.122.8 with SMTP id u8mr682747anc.1182370186045; Wed, 20 Jun 2007 13:09:46 -0700 (PDT) Received: by 10.100.106.17 with HTTP; Wed, 20 Jun 2007 13:09:45 -0700 (PDT) Message-ID: <20d2bdfb0706201309p414f4e49qe2c21bbd82d8386c@mail.gmail.com> Date: Wed, 20 Jun 2007 16:09:45 -0400 From: "Bruce Lowekamp" To: "Dean Willis" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <2D3D9B6B-55E8-4650-8D06-0F31304B23CB@cs.columbia.edu> <46714D58.7000408@alcatel-lucent.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> <46778BAE.5010504@teigre.com> X-Google-Sender-Auth: d60b45e657acc3c9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Catching up on this thread. Comments inline On 6/19/07, Dean Willis wrote: > > On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote: > > > We have two choices as I see it: > > > > 1. Is the AoR supposed to be the equivalent of an email address > > where the whole domain must handled authoritatively by one entity, > > here overlay (which allows 3263 lookups) ? > > > > 2. Or is the AoR supposed to be the equivalent of "use your email > > address as username on my website"? > > > > I think #1 is the general solution, and there might reasonably be a > fallback to behavior #2 under certain fully-disconnected scenarios > that I don't really even want to think about right now because the > overlay-discovery and authentication problems become very, very messy > and make my head hurt. I agree, although I think that dividing into just these two scenarios is a little bit restrictive. Consider a case where a company with an established conventional SIP installation is migrating over to a P2PSIP installation as hardware is replaced. They could expect for some period of time to have both systems, and are not likely to want to use different domain parts for the old and new phones (no one really should be aware of the difference other than IT). In this case, one good solution might be to have the p2p devices perform the lookup in the overlay and if it fails, contact the conventional proxy, only reporting failure if that fails. So in this case, there is an overlay, and the overlay should only contain one domain, but it's not authoritative. I can also see situations where you might have some Internet connectivity, but might still want a particular overlay to support multiple domain parts (e.g. a non-IETF conference might have hundreds of people who could participate in a p2psip overlay and would frequently be contacting each other, but not have ideal connectivity to the Internet). Again, I think the right answer here is to search the local overlay before going to the broader Internet. While I agree with the concern about being a part of 6 overlays and searching each of them everytime you make a call, I think this is something of an implementation (and usage) issue more than an issue we need to worry about right now. There are practical cases to support overlays that are authoritative for a single domainpart, practical cases where an overlay should have only one domain present but is not authoritative, and cases with mixed domains and no authoritative presence whatsoever. I also agree with Dean that my head hurts when thinking about how to handle authentication in the mixed domain case, since without involving an authoritative server for the domain, your security options are very different than in normal SIP. On 6/19/07, Brian Rosen wrote: > Okay. I like it. > > Is there a way I can look in the URI or the DNS entry for the domain in the > URI and discover if this is p2p or c/s, or do I blindly try one and then the > other? Does it matter whether a URI is backed by a p2p or conventional SIP installation? Unless you're going to join an overlay in order to send a message to anyone running one, I've been assuming that if you're sending a SIP message to a URI that is not supported by the overlay you're connected to, the resolution and message should follow the normal 3263 etc procedure. draft-marocco-p2psip-interwork-01 talks a bit about interworkings between conventional and p2p deployments and I don't think has been mentioned in this thread so far. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 16:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16ZY-00054b-AE; Wed, 20 Jun 2007 16:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16ZX-00054G-3s for p2psip@ietf.org; Wed, 20 Jun 2007 16:14:35 -0400 Received: from an-out-0708.google.com ([209.85.132.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16ZV-00049F-R6 for p2psip@ietf.org; Wed, 20 Jun 2007 16:14:35 -0400 Received: by an-out-0708.google.com with SMTP id c17so68553anc for ; Wed, 20 Jun 2007 13:14:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=IdM1gOrnISlH0B6I4fWlv2zKt3K7F53LyTwoZ+s/PKMCx/U4GVtuNJcSgnXkrtfesyv+HbidOkdQ3+MXOYrdoel8v3W5eu2hIWBC4Pk+MldX3LA5foGdTlb1zYl+1kNTdT+mWyPicZBNO3buqgOgvjc5lLi1M54Via0nhh0rF8o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=sTI6081SopdNLHiQe7JVCiM5F7NpDWXV+2Wb4V7P4SLdoa/u90hwJuIi5NTGnBE3H6ECsLy0dmfnSZEtfXtD1w0kPpc/59mLjoz6tLqGvSibsxauGX6a4FBvd0AOsHShSK3hIy7bzc7bQyh29u0uN9P63LjRstBgNJh0ECSERls= Received: by 10.100.136.8 with SMTP id j8mr706188and.1182370472089; Wed, 20 Jun 2007 13:14:32 -0700 (PDT) Received: by 10.100.106.17 with HTTP; Wed, 20 Jun 2007 13:14:32 -0700 (PDT) Message-ID: <20d2bdfb0706201314o6d51edc5g13fb3c40bc287f74@mail.gmail.com> Date: Wed, 20 Jun 2007 16:14:32 -0400 From: "Bruce Lowekamp" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 46707010fd0e8bd6 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [P2PSIP] new draft: draft-bryan-p2psip-reload-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We've just submitted a new draft: D. Bryan, M. Zangrilli, and B. Lowekamp, REsource LOcation And Discovery (RELOAD) (June 2007) draft-bryan-p2psip-reload-00 Until it is officially posted, it is available from http://www.p2psip.org/ietf.php We look forward to your comments and feedback. Abstract: This document outlines the motivation, requirements, and architectural design for a extensible and lightweight distributed REsource LOcation And Discovery (RELOAD) protocol. RELOAD is a Peer-to-Peer (P2P) based approach for registration and resource discovery using distributed hash tables maintained with binary messages. This design removes the need for central servers from SIP, while offering full backward compatibility with SIP, allowing reuse of existing clients, and allowing P2P enabled peers to communicate with conventional SIP entities. A basic introduction to the concepts of P2P is presented, backward compatibility issues addressed, and security considerations are discussed. RELOAD is one possible implementation of the protocols being discussed for creation in the P2PSIP WG. In the context of the work being proposed, this draft represents a concrete proposal for the P2PSIP Peer Protocol. RELOAD uses binary messages, derived as much as possible from the STUN protocol, as the underlying protocol. Note that in order to be as similar to STUN as possible, some text has been re-used verbatim from I-Ds and RFCs describing STUN. In this architecture, no P2PSIP Client Protocol is needed, rather unmodified SIP is used for access by non-peers. This protocol considers NAT traversal and fragmentation, supports storage of information other than registrations, allows for multiple DHT and hash algorithms, and provides hooks for multiple security schemes. The protocol described here derives from a fully implemented and commercially available system with running code. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 16:35:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16tY-00051n-R6; Wed, 20 Jun 2007 16:35:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I16tW-00051b-7a for p2psip@ietf.org; Wed, 20 Jun 2007 16:35:15 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I16tU-0001Eg-PJ for p2psip@ietf.org; Wed, 20 Jun 2007 16:35:14 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I16tH-0003xE-Ga; Wed, 20 Jun 2007 15:34:59 -0500 From: "Brian Rosen" To: "'David Barrett'" , "'Philip Matthews'" , "'Enrico Marocco'" References: <0E089E10-E740-4190-B4CD-1944AFEE49E3@magma.ca> Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 16:35:07 -0400 Message-ID: <04e301c7b37a$7fd1daf0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: AcezayIzCcdWWOdYRmmL8OJaaHGMGgACPeTAAAFZmgA= X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.5 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: 'Emil Ivov' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David It used to be that the IETF prided itself on "rough consensus and running code". We've lost the "running code" part of our process, but in its place, we have a lot of really good people who really look hard at the specs. Our experience over the last decade or so is that we are fair-to-middling good at writing specs that, with a reasonable amount of interoperability testing, work. ICE has had A LOT of very good eyeballs looking at it. Yep, it's complicated, and it's complicated because the world is complicated, and there have been enough good eyeballs on the spec to deal with the complications. It's ALWAYS possible that those eyeballs missed some not so obvious simplification. If you spot one, go tell them (in MMUSIC). But, I, for one, don't believe that we here in p2psip can make something that works as well as ICE for our problem. YMMV, but I don't want to waste a lot of my time looking at ideas unless there really is a big breakthrough. If there is, I'm interested. If you are in the "there must be a simpler way" state, by all means, keep trying, but until you get to a really big "aha" moment, I'd rather work on other parts of the problem and assume ICE. Brian > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Wednesday, June 20, 2007 3:57 PM > To: 'Philip Matthews'; 'Enrico Marocco' > Cc: 'Emil Ivov'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Peer protocol, DHT and running code > > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > > > On 20-Jun-07, at 09:42 , Enrico Marocco wrote: > > > > It might be useful to cite a recent post by Dan Wing to the BEHAVE list: > > http://www1.ietf.org/mail-archive/web/behave/current/msg02396.html > > Read the rest of the messages in the thread for more details. > > > > >>> 1. ICE works. This has been well demonstrated by its successful > > >>> deployment on the Internet by millions of endpoints. It works > > >>> without explicit support by subscriber's NATs or ISP's NATs. > > >>> > > >> > > >> Just curious, what statistics are available on ICE's > > >> real-world usage and NAT-penetration success rates? Specifically: > > >> > > >> - How did you come up with the "millions of endpoints" number? > > > > > > GoogleTalk's API, Google Talk itself, Microsoft's Windows Live > > > Messenger (formerly called MSN), and Yahoo Messenger all use > > > ICE. > > Don't forget later in the thread: > > [Dan] "ICE isn't finished, and early ICE versions are not compatible > with each other. Thus, there isn't much hope those different > networks would be compatible until until ICE has gone to RFC > or if those networks had worked out a version of ICE they > mutually agreed they would interoperate with (thus creating a > defacto standard)." > > In other words, there are zero endpoints using the ICE protocol (because > it > doesn't even exist yet), and millions of endpoints that have protocols > somewhat like some version of ICE. > > > > >> - What does "works" mean? (I'd suggest this be measured in > > >> "direct peer connectivity ratio" and "connection setup time", > > >> but any measure will do.) > > >> > > > > > > I found this, "Improving ICE Service Selection in a P2P System > > > using the Gradient Topology", > > > http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf > > > which includes the following quote: > > > > > > [...] Google's estimate that 8% of the GoogleTalk traffic > > > is routed using relay nodes. > > > > > > which cites > > > Google. Google talk, Accessed, Feb 22, 2007. > > > http://code.google.com/apis/talk/libjingle > > > > > > which leads one to: > > > http://code.google.com/apis/talk/libjingle/important_concepts.html > > Likewise, later in that same thread: > > [Dan] "Google's analysis is based on their own (GoogleTalk) network, I > would expect -- not GoogleTalk-to-something-else. I expect their > 92% number is based on how often two users, each behind > NATs with the 'Address and Port-Dependent Mapping' property > (RFC4787) attempt to talk with each other (this property was > formerly called 'symmetric NAT'). With ICE, since approximately > ice-10, that is the only case that causes a media relay to be > utilized." > > In other words, those numbers aren't measured, they're guesses. > > Which brings me back to my original point that ICE hasn't been > standardized, > and hasn't been measured in the real world. Thus it's reasonable to be > skeptical of its claims until it's been demonstrated that the standard is > sufficiently-well defined that a "clean" implementation will actually > interoperate, and actually solve its intended job. So far as I can tell, > neither of these have been proven, and until they have, it's reasonable to > consider alternatives. > > -david > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 17:12:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17TD-0006Wc-6L; Wed, 20 Jun 2007 17:12:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I17TC-0006WS-CT for p2psip@ietf.org; Wed, 20 Jun 2007 17:12:06 -0400 Received: from wr-out-0506.google.com ([64.233.184.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I17TA-0002IU-3p for p2psip@ietf.org; Wed, 20 Jun 2007 17:12:06 -0400 Received: by wr-out-0506.google.com with SMTP id 36so352507wra for ; Wed, 20 Jun 2007 14:12:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ow+3Y5W9UR/gVnGss6Fi7BNNRyHnE0/e8/sLkF2w+13ENBCLkM+OsufMLTOvX9zFwF+Y/iNlrjNakI9/A2PTV3w4Qs9hX828Y+X5jpYKRgZmypI1DdHFNUdVPJaR62YK18aT/1LcWA1wboeXV4fMFGVynzcO9V7YnuO46QwKad8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=i9M1zdFlHmb4sLrjtR3IG9lF3hmsBJf/w37RSFRvVJxWGYui4Do5PqN65ds+qVEk2rcd9/odUa4HA1eKXTDJdr3c7Ep6r6i6H+UUz3UGztmr4cJ0hbBqKLcPP4v/lbZH5lkBOssG5NIGWQXuYZnQh1dgJpzmJsUyTvqvsaPBA1I= Received: by 10.100.41.8 with SMTP id o8mr711676ano.1182373923559; Wed, 20 Jun 2007 14:12:03 -0700 (PDT) Received: by 10.100.106.17 with HTTP; Wed, 20 Jun 2007 14:12:03 -0700 (PDT) Message-ID: <20d2bdfb0706201412t31a4979dj4f0fb667745d98a1@mail.gmail.com> Date: Wed, 20 Jun 2007 17:12:03 -0400 From: "Bruce Lowekamp" To: "David Barrett" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46792EB5.3070700@telecomitalia.it> X-Google-Sender-Auth: aa348199d840c8b4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: P2PSIP Mailing List , Emil Ivov , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 6/20/07, David Barrett wrote: > > -----Original Message----- > > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > > > Yes, this is indeed a big question. I'm curious to see what people > > think about ICE; on one hand, it is pretty difficult to implement and > > to integrate with existing libraries, on the other hand, it is the most > > complete mechanism for NAT traversal. For the first version of our > > solution we tried to keep it optional and accepted a cheap compromise > > which should /often/ work (and which does not preclude ICE). It's a > > trade off... I would really like to get feedback on this. > > I certainly agree with the first point. But has "most complete mechanism > for NAT traversal" been really demonstrated yet? > > Are there any empirical studies (testing how good it "actually" is in the > real world, rather than inferring how good it "should" be) that have studied > ICE outside a limited lab environment? yes, although I'm not aware of any that are actually published/publishable. > > Furthermore, until it's been shown that multiple, separately-developed > implementations actually interoperate, I'd be hesitant to even call ICE > well-specified. > > So far as I can tell, there's a lot of optimism, hope, and hard work, but > I've yet to see the real world confirmation. Can someone point me to this? What has been shown is that previous attempts to solve almost the whole problem are frequently tricky and don't work as well as they should. Moreover, it doesn't really matter whether a solution supports 90% or even 99% of the cases. If it doesn't work with a potential user/customer's hardware (or that of the people they want to call) then it doesn't work. You're absolutely right in that ICE, and particular the interoperability, isn't as thoroughly tested as would be ideal. But I don't think that's an entirely reasonable standard to hold a brand-new protocol to, because it adds a chicken and egg problem to developing a new complicated protocol. Right now what we have is that it's the best that some of the best people in the world at working with NATs can develop to address the problem. It's finally in WGLC, so hopefully we will start to see interoperability tests soon. If it turns out that there are problems with it, I'm sure they will be addressed. If we want to support peers behind NATs (and as far as I'm concerned, that's most of the Internet right now, so I don't think we have a choice), ICE is our best hope at getting that to work. Anything else risks trying to reinvent ICE, anyway. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 18:24:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18bM-0004VT-TP; Wed, 20 Jun 2007 18:24:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18bM-0004VN-Cb for p2psip@ietf.org; Wed, 20 Jun 2007 18:24:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I18bL-0004Sn-4s for p2psip@ietf.org; Wed, 20 Jun 2007 18:24:36 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.43) id 1I18bK-0005Jz-KK; Wed, 20 Jun 2007 18:24:34 -0400 In-Reply-To: <200706201957.l5KJvVgr003530@in4.magma.ca> References: <200706201957.l5KJvVgr003530@in4.magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 18:24:29 -0400 To: David Barrett X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'Emil Ivov' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 20-Jun-07, at 15:57 , David Barrett wrote: > > Which brings me back to my original point that ICE hasn't been > standardized, > and hasn't been measured in the real world. Thus it's reasonable > to be > skeptical of its claims until it's been demonstrated that the > standard is > sufficiently-well defined that a "clean" implementation will actually > interoperate, and actually solve its intended job. So far as I can > tell, > neither of these have been proven, and until they have, it's > reasonable to > consider alternatives. Sure. The standard is not yet finished, so all measurements have been made on preliminary versions of the standard. And sure, it is reasonable to consider alternatives. Jonathan Rosenberg once started a draft that did a pros and cons comparison of the different proposed approaches (he dropped it after the -00 version). I proposed in the last BEHAVE meeting that the BEHAVE group should pick this up, but there so far no one has stepped forward to do the work. Personally, I have not heard of a proposal which I consider more compelling. But I have heard of lots of less-compelling proposals. Do you have a proposal for an alternative? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 20 18:46:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18wl-00046q-U5; Wed, 20 Jun 2007 18:46:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I18wl-00046l-K4 for p2psip@ietf.org; Wed, 20 Jun 2007 18:46:43 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I18wf-00040f-Qy for p2psip@ietf.org; Wed, 20 Jun 2007 18:46:43 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Wed, 20 Jun 2007 15:46:35 -0700 From: "David Barrett" To: "'Brian Rosen'" , "'Philip Matthews'" , "'Enrico Marocco'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Wed, 20 Jun 2007 15:46:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcezayIzCcdWWOdYRmmL8OJaaHGMGgACPeTAAAFZmgAAAgvgoA== In-Reply-To: <04e301c7b37a$7fd1daf0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: 'Emil Ivov' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: Well, my primary goal is to just push back on suggestions that ICE is a proven solution, when in fact it's largely untested (except for perhaps some private study hinted at by Bruce). I'll admit, I'm uncomfortable narrowing the field of choices to a single, unstandardized, largely-untested protocol, but I can understand the overall process. It's reasonable to say "NAT penetration is not part of our mandate, we're delegating this to ICE, and we'll accept whatever it produces -- it's not our job to investigate alternatives". I just wish there was some force pushing back on ICE to show measurable results. Again, I'm totally open to the possibility ICE is great. But I haven't seen the data yet. Indeed, the only data I do have is personal experience, which suggests ICE is an impossibly complex, ever-changing morass that cannot be implemented except in proprietary, non-standard subsets of obsolete drafts, cemented together with undocumented tricks and voodoo. I'd like to see data that shows otherwise, and I'm hoping I can rally the troops to raise the priority of obtaining such data. -david > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, June 20, 2007 1:35 PM > To: 'David Barrett'; 'Philip Matthews'; 'Enrico Marocco' > Cc: 'Emil Ivov'; 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Peer protocol, DHT and running code > > > David > > It used to be that the IETF prided itself on "rough consensus and running > code". We've lost the "running code" part of our process, but in its > place, > we have a lot of really good people who really look hard at the specs. > Our > experience over the last decade or so is that we are fair-to-middling good > at writing specs that, with a reasonable amount of interoperability > testing, > work. > > ICE has had A LOT of very good eyeballs looking at it. Yep, it's > complicated, and it's complicated because the world is complicated, and > there have been enough good eyeballs on the spec to deal with the > complications. > > It's ALWAYS possible that those eyeballs missed some not so obvious > simplification. If you spot one, go tell them (in MMUSIC). > > But, I, for one, don't believe that we here in p2psip can make something > that works as well as ICE for our problem. YMMV, but I don't want to > waste > a lot of my time looking at ideas unless there really is a big > breakthrough. > If there is, I'm interested. If you are in the "there must be a simpler > way" state, by all means, keep trying, but until you get to a really big > "aha" moment, I'd rather work on other parts of the problem and assume > ICE. > > Brian > > > -----Original Message----- > > From: David Barrett [mailto:dbarrett@quinthar.com] > > Sent: Wednesday, June 20, 2007 3:57 PM > > To: 'Philip Matthews'; 'Enrico Marocco' > > Cc: 'Emil Ivov'; 'P2PSIP Mailing List' > > Subject: RE: [P2PSIP] Peer protocol, DHT and running code > > > > > -----Original Message----- > > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > > > > > On 20-Jun-07, at 09:42 , Enrico Marocco wrote: > > > > > > It might be useful to cite a recent post by Dan Wing to the BEHAVE > list: > > > http://www1.ietf.org/mail-archive/web/behave/current/msg02396.html > > > Read the rest of the messages in the thread for more details. > > > > > > >>> 1. ICE works. This has been well demonstrated by its successful > > > >>> deployment on the Internet by millions of endpoints. It works > > > >>> without explicit support by subscriber's NATs or ISP's NATs. > > > >>> > > > >> > > > >> Just curious, what statistics are available on ICE's > > > >> real-world usage and NAT-penetration success rates? Specifically: > > > >> > > > >> - How did you come up with the "millions of endpoints" number? > > > > > > > > GoogleTalk's API, Google Talk itself, Microsoft's Windows Live > > > > Messenger (formerly called MSN), and Yahoo Messenger all use > > > > ICE. > > > > Don't forget later in the thread: > > > > [Dan] "ICE isn't finished, and early ICE versions are not compatible > > with each other. Thus, there isn't much hope those different > > networks would be compatible until until ICE has gone to RFC > > or if those networks had worked out a version of ICE they > > mutually agreed they would interoperate with (thus creating a > > defacto standard)." > > > > In other words, there are zero endpoints using the ICE protocol (because > > it > > doesn't even exist yet), and millions of endpoints that have protocols > > somewhat like some version of ICE. > > > > > > > >> - What does "works" mean? (I'd suggest this be measured in > > > >> "direct peer connectivity ratio" and "connection setup time", > > > >> but any measure will do.) > > > >> > > > > > > > > I found this, "Improving ICE Service Selection in a P2P System > > > > using the Gradient Topology", > > > > http://www.jimdowling.info/pubs/dowling-j_icep2p_saso07.pdf > > > > which includes the following quote: > > > > > > > > [...] Google's estimate that 8% of the GoogleTalk traffic > > > > is routed using relay nodes. > > > > > > > > which cites > > > > Google. Google talk, Accessed, Feb 22, 2007. > > > > http://code.google.com/apis/talk/libjingle > > > > > > > > which leads one to: > > > > http://code.google.com/apis/talk/libjingle/important_concepts.html > > > > Likewise, later in that same thread: > > > > [Dan] "Google's analysis is based on their own (GoogleTalk) network, I > > would expect -- not GoogleTalk-to-something-else. I expect their > > 92% number is based on how often two users, each behind > > NATs with the 'Address and Port-Dependent Mapping' property > > (RFC4787) attempt to talk with each other (this property was > > formerly called 'symmetric NAT'). With ICE, since approximately > > ice-10, that is the only case that causes a media relay to be > > utilized." > > > > In other words, those numbers aren't measured, they're guesses. > > > > Which brings me back to my original point that ICE hasn't been > > standardized, > > and hasn't been measured in the real world. Thus it's reasonable to be > > skeptical of its claims until it's been demonstrated that the standard > is > > sufficiently-well defined that a "clean" implementation will actually > > interoperate, and actually solve its intended job. So far as I can > tell, > > neither of these have been proven, and until they have, it's reasonable > to > > consider alternatives. > > > > -david > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 02:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1GEV-0007ZL-Pk; Thu, 21 Jun 2007 02:33:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1GEQ-0007Qo-Qk for p2psip@ietf.org; Thu, 21 Jun 2007 02:33:28 -0400 Received: from maill.telecomitalia.it ([217.169.121.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1GEO-0001Bl-Sr for p2psip@ietf.org; Thu, 21 Jun 2007 02:33:26 -0400 Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 08:33:23 +0200 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 08:33:23 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 08:33:22 +0200 Message-ID: <467A1C28.90007@telecomitalia.it> Date: Thu, 21 Jun 2007 08:35:20 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <46792EB5.3070700@telecomitalia.it> <047601c7b368$df0b2a10$640fa8c0@cis.neustar.com> In-Reply-To: <047601c7b368$df0b2a10$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 21 Jun 2007 06:33:22.0621 (UTC) FILETIME=[109566D0:01C7B3CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1524980885==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1524980885== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050107060106000401010703" This is a cryptographically signed message in MIME format. --------------ms050107060106000401010703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian Rosen wrote: > There is a fair amount of work on investigating the characteristics of > deployed NATs, which then guided the ICE effort. It's a moving target. > There are a number of commercial STUN servers out there, which is a big > piece of ICE. I think the direct answer to your question is that there is > not a lot of hard data on the effectiveness of ICE, but I would bet on that > a whole lot more than any new, supposedly simpler set of NAT traversal > techniques, even in more restricted use cases. Just to be clear, XPP does not introduce any _new_ NAT traversal technique. As it is UDP based (and it is UDP based not only for NAT traversal!), it has a NAT-friendly handshake mechanism. Which isn't new at all, as it is almost the same as symmetric RTP. And it doesn't preclude ICE either. -- Ciao, Enrico --------------ms050107060106000401010703 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIxMDYzNTIwWjAjBgkqhkiG9w0BCQQxFgQU9vI6UqLZ ZXLaVcX9+vhSnLC4fNswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBACtJ2h5pHyuzKQ6YTQ3o1DmGPAERLshCrehDuna2PNGJATqj/CWRdE1C +qFFFMmlK6JAul1k/8CaEQgsIaxOVTJepdlkYpKFj4ZjS9+hQuOV5b3bCBTg6cKF8yBGE9SC 1CHRyog4f5uiqEDvnXL4K/NpI++gGMZ2QwCoY5pu4eQJ7BKHDIxd+YoMlvy9WXnVo9AxI1Nu j2WrPqYVRKgRncjrk4OHrvYfqo/RTYrcN6s2yJE4OmdsHchm4u6hMeT4eIpYmj5H7qxItCQ3 3uXUfIMoL9E2MZTeWMmty6/LFNRTDoVgTiOQhGnUwpZXRlp6w8Telqh+5Os+FC4W5AicCYUA AAAAAAA= --------------ms050107060106000401010703-- --===============1524980885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1524980885==-- From p2psip-bounces@ietf.org Thu Jun 21 04:18:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1HsP-0005ei-UP; Thu, 21 Jun 2007 04:18:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1HsP-0005ed-Gs for p2psip@ietf.org; Thu, 21 Jun 2007 04:18:49 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1HsP-0000ux-0y for p2psip@ietf.org; Thu, 21 Jun 2007 04:18:49 -0400 Received: (qmail 30652 invoked for bounce); 21 Jun 2007 10:21:00 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 21 Jun 2007 10:21:00 -0000 Message-ID: <467A3466.3080203@sip-communicator.org> Date: Thu, 21 Jun 2007 10:18:46 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Enrico Marocco Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <46792EB5.3070700@telecomitalia.it> <047601c7b368$df0b2a10$640fa8c0@cis.neustar.com> <467A1C28.90007@telecomitalia.it> In-Reply-To: <467A1C28.90007@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'P2PSIP Mailing List' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello all, Some more on the subject. As Enrico mentioned, we are very ICE friendly and we are not trying to suggest a replacement technique. However, as some of you have already mentioned, ICE is big, complex and time consuming. Are we certain that we want it to be a MUST and call incompatible all implementations that are bypassing it? How about seamless mobility? Imagine a peer that moves from one subnet to another and needs to reconnect to the overlay as quickly as possible. Is it reasonable to impose the extra lag that comes with ICE? Then there are sensor (possibly IPv6 only )networks and other similar environments where the obligation to add an extra stack would simply preclude against using a specific solution. To sum it up, I am thinking that we might have a lot of cases where ICE would be undesirable so it might be a bit harsh to shun as "incompatible" implementations that won't be using it. Cheers Emil Enrico Marocco wrote: > Brian Rosen wrote: >> There is a fair amount of work on investigating the characteristics of >> deployed NATs, which then guided the ICE effort. It's a moving target. >> There are a number of commercial STUN servers out there, which is a big >> piece of ICE. I think the direct answer to your question is that there is >> not a lot of hard data on the effectiveness of ICE, but I would bet on that >> a whole lot more than any new, supposedly simpler set of NAT traversal >> techniques, even in more restricted use cases. > > Just to be clear, XPP does not introduce any _new_ NAT traversal > technique. As it is UDP based (and it is UDP based not only for NAT > traversal!), it has a NAT-friendly handshake mechanism. Which isn't new > at all, as it is almost the same as symmetric RTP. > > And it doesn't preclude ICE either. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 08:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1LYU-0003zN-7b; Thu, 21 Jun 2007 08:14:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1LYT-0003z6-DJ for p2psip@ietf.org; Thu, 21 Jun 2007 08:14:29 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1LYS-00050q-2R for p2psip@ietf.org; Thu, 21 Jun 2007 08:14:29 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I1LYP-000575-2s; Thu, 21 Jun 2007 08:14:26 -0400 In-Reply-To: <467A3466.3080203@sip-communicator.org> References: <46792EB5.3070700@telecomitalia.it> <047601c7b368$df0b2a10$640fa8c0@cis.neustar.com> <467A1C28.90007@telecomitalia.it> <467A3466.3080203@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Thu, 21 Jun 2007 08:14:23 -0400 To: Emil Ivov X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 21-Jun-07, at 04:18 , Emil Ivov wrote: > Hello all, > > Some more on the subject. > > As Enrico mentioned, we are very ICE friendly and we are not trying > to suggest a replacement technique. > > However, as some of you have already mentioned, ICE is big, complex > and time consuming. Are we certain that we want it to be a MUST and > call incompatible all implementations that are bypassing it? If the system you produce will only run in a single address space, then ICE is not needed. However, if either a client or a peer can be in a different address space (= behind a NAT), then ICE is needed, unless you always use a media relay. Otherwise, how do you set up a direct connection for the media when the destination is behind a NAT? > How about seamless mobility? Imagine a peer that moves from one > subnet to another and needs to reconnect to the overlay as quickly > as possible. Is it reasonable to impose the extra lag that comes > with ICE? > > Then there are sensor (possibly IPv6 only )networks and other > similar environments where the obligation to add an extra stack > would simply preclude against using a specific solution. Is this a code space problem? Or something else? I know how memory can be tight on embedded devices. However, I can say that by the time the P2PSIP specs are published as RFCs, the amount of memory on typical new embedded device will probably have doubled :-). In the meantime, stop programming in C++, or at least give up templates. :-). - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 08:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1MCD-00020C-Uk; Thu, 21 Jun 2007 08:55:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1MCC-0001vT-K0 for p2psip@ietf.org; Thu, 21 Jun 2007 08:55:32 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1MCB-0001Yk-79 for p2psip@ietf.org; Thu, 21 Jun 2007 08:55:32 -0400 Received: (qmail 595 invoked for bounce); 21 Jun 2007 14:57:42 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 21 Jun 2007 14:57:42 -0000 Message-ID: <467A7540.4090207@sip-communicator.org> Date: Thu, 21 Jun 2007 14:55:28 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <46792EB5.3070700@telecomitalia.it> <047601c7b368$df0b2a10$640fa8c0@cis.neustar.com> <467A1C28.90007@telecomitalia.it> <467A3466.3080203@sip-communicator.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > If the system you produce will only run in a single address space, > then ICE is not needed. This means you agree that "MUST use ICE" is too strong and SHOULD fits better. Right? > However, if either a client or a peer can be in a different address > space (= behind a NAT), then ICE is needed ICE is helpful but not absolutely needed. >, unless you always use a > media relay. Otherwise, how do you set up a direct connection for the > media when the destination is behind a NAT? Using only STUN (not TURN), you could still be successful in many many cases. Then, if you cannot establish some connections, hell, the overlay is designed to be robust: There will be more featured (and expensive) ICE-aware peers doing some work for you... >> How about seamless mobility? Imagine a peer that moves from one >> subnet to another and needs to reconnect to the overlay as quickly >> as possible. Is it reasonable to impose the extra lag that comes >> with ICE? >> >> Then there are sensor (possibly IPv6 only )networks and other >> similar environments where the obligation to add an extra stack >> would simply preclude against using a specific solution. > > Is this a code space problem? Or something else? > I know how memory can be tight on embedded devices. However, I can > say that by the time the P2PSIP specs are published as RFCs, the > amount of memory on typical new embedded device will probably have > doubled :-). And there will be smaller and cheaper devices with same amount resources (and is memory the only bottleneck on such devices?). > In the meantime, stop programming in C++, or at least > give up templates. :-). Now, isn't this a wise argument! :-) Cheers Emil > - Philip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 09:08:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1MOF-0004uT-R5; Thu, 21 Jun 2007 09:07:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1MOE-0004uM-HC for p2psip@ietf.org; Thu, 21 Jun 2007 09:07:58 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1MOC-0006Pu-Ly for p2psip@ietf.org; Thu, 21 Jun 2007 09:07:58 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:07:55 +0200 Received: from ptpxch004ba020.idc.cww.telecomitalia.it ([156.54.240.43]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:07:55 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 15:07:54 +0200 Message-ID: <467A78A2.6060904@telecomitalia.it> Date: Thu, 21 Jun 2007 15:09:54 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <0E089E10-E740-4190-B4CD-1944AFEE49E3@magma.ca> <04e301c7b37a$7fd1daf0$640fa8c0@cis.neustar.com> In-Reply-To: <04e301c7b37a$7fd1daf0$640fa8c0@cis.neustar.com> X-OriginalArrivalTime: 21 Jun 2007 13:07:54.0423 (UTC) FILETIME=[2E13BC70:01C7B405] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0164182859==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0164182859== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms050505090901070602080501" This is a cryptographically signed message in MIME format. --------------ms050505090901070602080501 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Brian Rosen wrote: > > David > > It used to be that the IETF prided itself on "rough consensus and running > code". We've lost the "running code" part of our process, but in its place, > we have a lot of really good people who really look hard at the specs. Some real life examples -- to name but a few: Jabber, Bonjour and arguably HTTP1.0 -- would probably make some people argue that the "running code" part is essential for protocols to be successful, probably more important than specs. Obviously, I don't completely agree with such an argument, for if I did, I wouldn't be discussing any more, but I still think that, especially for highly unpredictable decentralized systems as P2PSIP, running code is an extremely important part. I certainly hope I am not the only one left to believe this. -- Ciao, Enrico --------------ms050505090901070602080501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIxMTMwOTU0WjAjBgkqhkiG9w0BCQQxFgQUYdFN+Lkx TeB9l2nZOPh5PNn1GB8wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAFVzz+kTZMVVJsTmp0JkJqpHMV0+nFIy+gTsiPeyamf0FGggZ1THydeS PQpEJTt/G4lDud8955qSxENAprC/JktPp9dWQaq3/xEiyGkVI2jt8qXaeh2yxByMzAaWvnpf RoGSAq+TT9eolzX3p94Rf1UJSG4G6kTvk9qTcnvl9srmhbj/FL2/elBRE8Mnx5ZyAZg2eh4v s/6N94deYfmaY2S/g1w+6+2bp6WlUBsDJrB1xWaj84l4iAPidAP3qcfsbZFmaN3FLU18XBAr c6tQ00aIOE9PoDv9E0mrTkV1I/gWVbup8f/fqOdJj+XjLHCHiHQGEfZFW8WCW+AOQjFLaFYA AAAAAAA= --------------ms050505090901070602080501-- --===============0164182859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0164182859==-- From p2psip-bounces@ietf.org Thu Jun 21 15:48:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SdD-0001fS-Jt; Thu, 21 Jun 2007 15:47:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1SdC-0001fN-Hg for p2psip@ietf.org; Thu, 21 Jun 2007 15:47:50 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1SdC-0000r5-3O for p2psip@ietf.org; Thu, 21 Jun 2007 15:47:50 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Thu, 21 Jun 2007 12:47:42 -0700 From: "David Barrett" To: "'Enrico Marocco'" , "'Brian Rosen'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Thu, 21 Jun 2007 12:47:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0BVXCrIE817DwTG+h+/A4oofl+gALX4Mw In-Reply-To: <467A78A2.6060904@telecomitalia.it> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: Totally agree with you. > -----Original Message----- > From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] > Sent: Thursday, June 21, 2007 6:10 AM > To: Brian Rosen > Cc: 'David Barrett'; 'Philip Matthews'; 'Emil Ivov'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > Brian Rosen wrote: > > > > David > > > > It used to be that the IETF prided itself on "rough consensus and > running > > code". We've lost the "running code" part of our process, but in its > place, > > we have a lot of really good people who really look hard at the specs. > > Some real life examples -- to name but a few: Jabber, Bonjour and > arguably HTTP1.0 -- would probably make some people argue that the > "running code" part is essential for protocols to be successful, > probably more important than specs. Obviously, I don't completely agree > with such an argument, for if I did, I wouldn't be discussing any more, > but I still think that, especially for highly unpredictable > decentralized systems as P2PSIP, running code is an extremely important > part. > > I certainly hope I am not the only one left to believe this. > > -- > Ciao, > Enrico _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 17:55:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Uca-0000bW-5Z; Thu, 21 Jun 2007 17:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1UcX-0000Xc-7c for p2psip@ietf.org; Thu, 21 Jun 2007 17:55:17 -0400 Received: from wx-out-0506.google.com ([66.249.82.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1UcU-0006d0-Tq for p2psip@ietf.org; Thu, 21 Jun 2007 17:55:17 -0400 Received: by wx-out-0506.google.com with SMTP id t5so594344wxc for ; Thu, 21 Jun 2007 14:55:14 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=t8u1QpROL4G0jF8cGF9k08W3q3HGBHx8bRvAd6U5HmQtnSpvxgp427M3ac/0NrFZakFdUBNhb1XExQTDhPK0I8u3lytwxCbqnhRfWOOjk1IsxrfgdSfjGayfPcPJgvWUznzOYJI3Ormap60FJnNHhNrxd4xsLLB/gemRxXAqJjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uqq5Z1kOZlUiMy38v8M1SX+ZRuKI+Q2q8s8Icn9gfiWp2L2AtucfkAhX+uXdC6y0pRJCLDXdJ4fBlkxLL7+EroYZipTJ15IuFDkjlFOC7FPQ9dlHNSOyYSuciEGSmjZJA96PTPRELEkc2HKP+CoHrVPOJKjWqt3I+8u1mbvstGU= Received: by 10.90.94.2 with SMTP id r2mr2265518agb.1182462914573; Thu, 21 Jun 2007 14:55:14 -0700 (PDT) Received: by 10.90.117.8 with HTTP; Thu, 21 Jun 2007 14:55:14 -0700 (PDT) Message-ID: Date: Thu, 21 Jun 2007 17:55:14 -0400 From: "Adam Fisk" To: "Enrico Marocco" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: <46797C8A.6070600@telecomitalia.it> MIME-Version: 1.0 References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Emil Ivov , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1684836562==" Errors-To: p2psip-bounces@ietf.org --===============1684836562== Content-Type: multipart/alternative; boundary="----=_Part_98292_11918071.1182462914523" ------=_Part_98292_11918071.1182462914523 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > I totally agree. If we chose TCP, then we would definitely need to > mandate ICE-TCP. I think it would be mistake to choose only TCP. I have yet to see robustly-running code for NAT traversal in TCP. I have a lot of faith in Saikat and co., but I sure haven't been able to get it to work. I actually think TCP should be one option while also supporting a UDP-based solution. > Well, path MTU discovery may be done using ICMP or the default 1500 > value may be adopted, as for SIP. Congestion control is not an issue, > because we send fragments one by one, only after the previous fragment > has been acked. Yes, that's not much efficient, but if fits well in our > restricted scope (i.e. for implementing DHTs). Hmnn...I didn't notice that part of XPP (the lock-step approach), but it raises a red flag for me. If you're doing lock-step, why not just use TFTP (Trivial File Transfer Protocol). If you're looking for simplicity, that's the way to go! > I agree here too. By the way, not that it really matter, but, IIRC some > of the most popular p2p applications (emule and azureus) use UDP to > maintain the internal DHT, don't they? eMule and Asureus, as well as I believe LimeWire's new DHT, all are UDP-based. That's primarily because they're all based on Kademlia, though. None of them to anything with NAT traversal. -Adam ------=_Part_98292_11918071.1182462914523 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I totally agree.  If we chose TCP, then we would definitely need to
mandate ICE-TCP.

I think it would be mistake to choose only TCP.  I have yet to see robustly-running code for NAT traversal in TCP.  I have a lot of faith in Saikat and co., but I sure haven't been able to get it to work.  I actually think TCP should be one option while also supporting a UDP-based solution.


Well, path MTU discovery may be done using ICMP or the default 1500
value may be adopted, as for SIP.  Congestion control is not an issue,
because we send fragments one by one, only after the previous fragment
has been acked.  Yes, that's not much efficient, but if fits well in our
restricted scope (i.e. for implementing DHTs).

Hmnn...I didn't notice that part of XPP (the lock-step approach), but it raises a red flag for me.  If you're doing lock-step, why not just use TFTP (Trivial File Transfer Protocol).  If you're looking for simplicity, that's the way to go!

 
I agree here too.  By the way, not that it really matter, but, IIRC some
of the most popular p2p applications (emule and azureus) use UDP to
maintain the internal DHT, don't they?

eMule and Asureus, as well as I believe LimeWire's new DHT, all are UDP-based.  That's primarily because they're all based on Kademlia, though.  None of them to anything with NAT traversal.

-Adam

------=_Part_98292_11918071.1182462914523-- --===============1684836562== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1684836562==-- From p2psip-bounces@ietf.org Thu Jun 21 18:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Uny-00019E-JG; Thu, 21 Jun 2007 18:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Unx-000198-As for p2psip@ietf.org; Thu, 21 Jun 2007 18:07:05 -0400 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Unw-00089b-2T for p2psip@ietf.org; Thu, 21 Jun 2007 18:07:05 -0400 Received: by wx-out-0506.google.com with SMTP id t5so596699wxc for ; Thu, 21 Jun 2007 15:07:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=eSyKNe6KEkMktDDXM/fVPvAlMPZ29eAlixf6xtyGC7J0CfzsFDufCapE0qaUknkqM/W3l2oAiqv1xLjjK5n2Hl1MYUzfVWcfgU3xSyFlWY8zlNQsH4vobYwfsIf5vhmMS3peWvW/YD9oLaBo8f7bwj8soO00gQQWuFv3D3tnsqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZcieVHtiEfs0Ala7u60B22FgBJUuGnaq7vkZQ828yyDf9d9eIqyjabFhGHqbei4sCXedj4z/df/Pp9cjsKqHffYfswXwdCuyE5p/QxkUlqDxkCHXk/7u0SoEHY/kiUXaD5kbHTa8FaWWDgmxZdZW58IqtvMIsnCBKLdQjxg0xgQ= Received: by 10.90.25.3 with SMTP id 3mr2275646agy.1182463623808; Thu, 21 Jun 2007 15:07:03 -0700 (PDT) Received: by 10.90.117.8 with HTTP; Thu, 21 Jun 2007 15:07:03 -0700 (PDT) Message-ID: Date: Thu, 21 Jun 2007 18:07:03 -0400 From: "Adam Fisk" To: "Philip Matthews" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: MIME-Version: 1.0 References: <9FA16888AD1BF64ABCE6C2532CCEB98A0275AD4F@xmb-sjc-219.amer.cisco.com> <4678F170.7030309@sip-communicator.org> X-Spam-Score: 0.5 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0205310223==" Errors-To: p2psip-bounces@ietf.org --===============0205310223== Content-Type: multipart/alternative; boundary="----=_Part_98336_12783447.1182463623754" ------=_Part_98336_12783447.1182463623754 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline > > > The solution that you adopted for XPP (= encapsulate it inside UDP) > also works for SCTP. That's an interesting idea to me. SCTP doesn't make sense to me alone (since NAT traversal is undefined), but encapsulation in UDP for NAT traversal could make a lot of sense. That was the heart of my RDP suggestion -- use an existing transport for reliable UDP transmission. Like you, I don't like the idea of inventing another transport that combines much of the functionality of existing transports but that also crams in specialized DHT handling. I think we should choose existing protocols that solve the transport problem better than we should be thinking about here, and then focus on the peer messages themselves. I'm not too familiar with SCTP, though, so encapsulating it in UDP could be a huge task. -Adam ------=_Part_98336_12783447.1182463623754 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline


The solution that you adopted for XPP (= encapsulate it inside UDP)
also works for SCTP.

That's an interesting idea to me.  SCTP doesn't make sense to me alone (since NAT traversal is undefined), but encapsulation in UDP for NAT traversal could make a lot of sense.  That was the heart of my RDP suggestion -- use an existing transport for reliable UDP transmission. 

Like you, I don't like the idea of inventing another transport that combines much of the functionality of existing transports but that also crams in specialized DHT handling.  I think we should choose existing protocols that solve the transport problem better than we should be thinking about here, and then focus on the peer messages themselves.

I'm not too familiar with SCTP, though, so encapsulating it in UDP could be a huge task. 

-Adam

------=_Part_98336_12783447.1182463623754-- --===============0205310223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0205310223==-- From p2psip-bounces@ietf.org Thu Jun 21 18:12:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1UtI-0003wW-0u; Thu, 21 Jun 2007 18:12:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1UtG-0003pT-GP for p2psip@ietf.org; Thu, 21 Jun 2007 18:12:34 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1UtF-0001V5-6f for p2psip@ietf.org; Thu, 21 Jun 2007 18:12:34 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I1Ut0-0003ve-N3; Thu, 21 Jun 2007 17:12:18 -0500 From: "Brian Rosen" To: "'Adam Fisk'" , "'Enrico Marocco'" References: <4674F5ED.9070000@telecomitalia.it><7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca><4678E6B4.8090000@telecomitalia.it><23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca><46797C8A.6070600@telecomitalia.it> Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Thu, 21 Jun 2007 18:12:28 -0400 Message-ID: <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Ace0TteK3YMMX7BcTxyTd5TO2wVsLwAAZZbQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have a WHOLE LOT of experience with UDP and sip. It was a mistake. A big one. We should NEVER have defined sip on UDP. Henning told me he regrets not insisting on that way back when. Let's not make that mistake again. Fragmentation always gets you when you least expect it Reliable message passing always is needed, even when you think you don't Message order always is a pain to keep straight Connections really are helpful, and simulating your own is a pain And the big one Congestion control is required, don't ever believe that it isn't for = your protocol There is so much good engineering in TCP that, unlike ICE, is very well proven, and we should not re-invent it. We may not need some of TCP. It may get in the way a bit. It's MUCH = better than UDP for our purposes. Brian ________________________________________ From: Adam Fisk [mailto:adamfisk@gmail.com]=20 Sent: Thursday, June 21, 2007 5:55 PM To: Enrico Marocco Cc: Emil Ivov; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] Peer protocol, DHT and running code I totally agree.=A0=A0If we chose TCP, then we would definitely need to mandate ICE-TCP.=20 I think it would be mistake to choose only TCP.=A0 I have yet to see robustly-running code for NAT traversal in TCP.=A0 I have a lot of faith = in Saikat and co., but I sure haven't been able to get it to work.=A0 I = actually think TCP should be one option while also supporting a UDP-based = solution.=20 Well, path MTU discovery may be done using ICMP or the default 1500 value may be adopted, as for SIP.=A0=A0Congestion control is not an = issue,=20 because we send fragments one by one, only after the previous fragment has been acked.=A0=A0Yes, that's not much efficient, but if fits well in = our restricted scope (i.e. for implementing DHTs). Hmnn...I didn't notice that part of XPP (the lock-step approach), but it raises a red flag for me.=A0 If you're doing lock-step, why not just use = TFTP (Trivial File Transfer Protocol).=A0 If you're looking for simplicity, = that's the way to go!=20 =A0 I agree here too.=A0=A0By the way, not that it really matter, but, IIRC = some=20 of the most popular p2p applications (emule and azureus) use UDP to maintain the internal DHT, don't they? eMule and Asureus, as well as I believe LimeWire's new DHT, all are UDP-based.=A0 That's primarily because they're all based on Kademlia, = though.=A0 None of them to anything with NAT traversal.=20 -Adam _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 18:25:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V61-0003fm-HV; Thu, 21 Jun 2007 18:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1V5z-0003fb-Un for p2psip@ietf.org; Thu, 21 Jun 2007 18:25:43 -0400 Received: from wx-out-0506.google.com ([66.249.82.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1V5f-00046k-9C for p2psip@ietf.org; Thu, 21 Jun 2007 18:25:43 -0400 Received: by wx-out-0506.google.com with SMTP id t5so600199wxc for ; Thu, 21 Jun 2007 15:25:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cK402LZfsFn6xVAmNTZ9ZXcTpxMShGSkRfH4gxeyl6fLWLdQqnBEgMiYmHiwlxis541r10CPaQXhTYS8F/jAbU+vj4NpGqkS9DF1GJj+I4rR5oGz2RXhslYb6+8uvKUVt+idYJkf2zWZ4Z75eOd5m7B6o5wG5owlozK55nYNMBA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mJ47ZwLgqxSjtY8ogsbgLTuglLUN0gb5DWd6T/RS5g3g51Ne+jou8kB5mmYKlqH1KS9Odf0oVRx53v8MkGoyUeoP6VLWlbrpHzIBASrhao+7MON20MUhgRHZbTidAARVa4wDh0NiVw9Jny6h0HUxBt1cSB+f9FoIW9hwSsqcNco= Received: by 10.90.83.14 with SMTP id g14mr2288590agb.1182464722818; Thu, 21 Jun 2007 15:25:22 -0700 (PDT) Received: by 10.90.117.8 with HTTP; Thu, 21 Jun 2007 15:25:22 -0700 (PDT) Message-ID: Date: Thu, 21 Jun 2007 18:25:22 -0400 From: "Adam Fisk" To: "Brian Rosen" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> MIME-Version: 1.0 References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> X-Spam-Score: 0.3 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Emil Ivov , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0692638667==" Errors-To: p2psip-bounces@ietf.org --===============0692638667== Content-Type: multipart/alternative; boundary="----=_Part_98416_6319835.1182464722762" ------=_Part_98416_6319835.1182464722762 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree 100% UDP should never have been used for SIP, and I've had the same conversation with Henning. The key difference, though, is that SIP doesn't need to worry about NAT traversal in the same way we're talking about here because SIP proxy and registrars are on the public Internet. I agree reliable message passing makes sense for this purpose, and that's one of the reasons I was pointing to RDP. I think we're missing each other a little bit. The first question is: 1) Do we need NAT traversal for the Peer protocol? If the answer to that question is "yes", I think the peer protocol should be *a separate protocol* implemented over 2 transports: 1) TCP 2) some sort of reliable UDP. If the answer to that question is no, then yes, of course, just use TCP like should have always been done with SIP. -Adam On 6/21/07, Brian Rosen wrote: > > > We have a WHOLE LOT of experience with UDP and sip. > > It was a mistake. A big one. We should NEVER have defined sip on UDP. > Henning told me he regrets not insisting on that way back when. > > Let's not make that mistake again. > > Fragmentation always gets you when you least expect it > Reliable message passing always is needed, even when you think you don't > Message order always is a pain to keep straight > Connections really are helpful, and simulating your own is a pain > > And the big one > > Congestion control is required, don't ever believe that it isn't for your > protocol > > There is so much good engineering in TCP that, unlike ICE, is very well > proven, and we should not re-invent it. > We may not need some of TCP. It may get in the way a bit. It's MUCH > better > than UDP for our purposes. > > Brian > > > ________________________________________ > From: Adam Fisk [mailto:adamfisk@gmail.com] > Sent: Thursday, June 21, 2007 5:55 PM > To: Enrico Marocco > Cc: Emil Ivov; Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > > > I totally agree.If we chose TCP, then we would definitely need to > mandate ICE-TCP. > > I think it would be mistake to choose only TCP. I have yet to see > robustly-running code for NAT traversal in TCP. I have a lot of faith in > Saikat and co., but I sure haven't been able to get it to work. I actually > think TCP should be one option while also supporting a UDP-based solution. > > Well, path MTU discovery may be done using ICMP or the default 1500 > value may be adopted, as for SIP.Congestion control is not an issue, > because we send fragments one by one, only after the previous fragment > has been acked.Yes, that's not much efficient, but if fits well in our > restricted scope (i.e. for implementing DHTs). > > Hmnn...I didn't notice that part of XPP (the lock-step approach), but it > raises a red flag for me. If you're doing lock-step, why not just use TFTP > (Trivial File Transfer Protocol). If you're looking for simplicity, that's > the way to go! > > > I agree here too.By the way, not that it really matter, but, IIRC some > of the most popular p2p applications (emule and azureus) use UDP to > maintain the internal DHT, don't they? > > eMule and Asureus, as well as I believe LimeWire's new DHT, all are > UDP-based. That's primarily because they're all based on Kademlia, though. > None of them to anything with NAT traversal. > > -Adam > > > ------=_Part_98416_6319835.1182464722762 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree 100% UDP should never have been used for SIP, and I've had the same conversation with Henning.  The key difference, though, is that SIP doesn't need to worry about NAT traversal in the same way we're talking about here because SIP proxy and registrars are on the public Internet. 

I agree reliable message passing makes sense for this purpose, and that's one of the reasons I was pointing to RDP.

I think we're missing each other a little bit.  The first question is:

1) Do we need NAT traversal for the Peer protocol?

If the answer to that question is "yes", I think the peer protocol should be *a separate protocol* implemented over 2 transports:

1) TCP
2) some sort of reliable UDP.

If the answer to that question is no, then yes, of course, just use TCP like should have always been done with SIP.

-Adam


On 6/21/07, Brian Rosen <br@brianrosen.net> wrote:
<as individual>
We have a WHOLE LOT of experience with UDP and sip.

It was a mistake.  A big one.  We should NEVER have defined sip on UDP.
Henning told me he regrets not insisting on that way back when.

Let's not make that mistake again.

Fragmentation always gets you when you least expect it
Reliable message passing always is needed, even when you think you don't
Message order always is a pain to keep straight
Connections really are helpful, and simulating your own is a pain

And the big one

Congestion control is required, don't ever believe that it isn't for your
protocol

There is so much good engineering in TCP that, unlike ICE, is very well
proven, and we should not re-invent it.
We may not need some of TCP.  It may get in the way a bit.  It's MUCH better
than UDP for our purposes.

Brian


________________________________________
From: Adam Fisk [mailto:adamfisk@gmail.com]
Sent: Thursday, June 21, 2007 5:55 PM
To: Enrico Marocco
Cc: Emil Ivov; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] Peer protocol, DHT and running code



I totally agree.If we chose TCP, then we would definitely need to
mandate ICE-TCP.

I think it would be mistake to choose only TCP. I have yet to see
robustly-running code for NAT traversal in TCP. I have a lot of faith in
Saikat and co., but I sure haven't been able to get it to work. I actually
think TCP should be one option while also supporting a UDP-based solution.

Well, path MTU discovery may be done using ICMP or the default 1500
value may be adopted, as for SIP.Congestion control is not an issue,
because we send fragments one by one, only after the previous fragment
has been acked.Yes, that's not much efficient, but if fits well in our
restricted scope (i.e. for implementing DHTs).

Hmnn...I didn't notice that part of XPP (the lock-step approach), but it
raises a red flag for me. If you're doing lock-step, why not just use TFTP
(Trivial File Transfer Protocol). If you're looking for simplicity, that's
the way to go!


I agree here too.By the way, not that it really matter, but, IIRC some
of the most popular p2p applications (emule and azureus) use UDP to
maintain the internal DHT, don't they?

eMule and Asureus, as well as I believe LimeWire's new DHT, all are
UDP-based. That's primarily because they're all based on Kademlia, though.
None of them to anything with NAT traversal.

-Adam



------=_Part_98416_6319835.1182464722762-- --===============0692638667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0692638667==-- From p2psip-bounces@ietf.org Thu Jun 21 20:38:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XA1-0000oA-GC; Thu, 21 Jun 2007 20:38:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1X9z-0000mx-N1 for p2psip@ietf.org; Thu, 21 Jun 2007 20:37:59 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1X9z-0003kQ-C6 for p2psip@ietf.org; Thu, 21 Jun 2007 20:37:59 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I1X9i-0006uI-LA; Thu, 21 Jun 2007 19:37:42 -0500 From: "Brian Rosen" To: "'Adam Fisk'" References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Thu, 21 Jun 2007 20:37:54 -0400 Message-ID: <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Ace0Uwc7sL0Pnc2aQUObGNZRxS6u+AAD1wKA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Huh. I must not understand firewalls and UDP. I was told most firewalls, and especially enterprise firewalls did not = allow arbitrary incoming UDP. Some allow symmetric UDP with the outbound = traffic first. I know I can't run a SIP proxy behind my firewall at home = without configuring the firewall to have a wide open port, and I know what I'm doing. I know I can't get incoming or outgoin UDP in my office unless I have a really good reason to ask the IT guys to open a port. YMMV I = guess. I think reliable+congestion control+fragmentation control+nat traversal = UDP =3D TCP+ICE. =20 Brian ________________________________________ From: Adam Fisk [mailto:adamfisk@gmail.com]=20 Sent: Thursday, June 21, 2007 6:25 PM To: Brian Rosen Cc: Enrico Marocco; Emil Ivov; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] Peer protocol, DHT and running code I agree 100% UDP should never have been used for SIP, and I've had the = same conversation with Henning.=A0 The key difference, though, is that SIP = doesn't need to worry about NAT traversal in the same way we're talking about = here because SIP proxy and registrars are on the public Internet.=A0=20 I agree reliable message passing makes sense for this purpose, and = that's one of the reasons I was pointing to RDP. I think we're missing each other a little bit.=A0 The first question is: = 1) Do we need NAT traversal for the Peer protocol?=20 If the answer to that question is "yes", I think the peer protocol = should be *a separate protocol* implemented over 2 transports: 1) TCP 2) some sort of reliable UDP. If the answer to that question is no, then yes, of course, just use TCP = like should have always been done with SIP.=20 -Adam On 6/21/07, Brian Rosen wrote: We have a WHOLE LOT of experience with UDP and sip. It was a mistake.=A0=A0A big one.=A0=A0We should NEVER have defined sip = on UDP. Henning told me he regrets not insisting on that way back when.=20 Let's not make that mistake again. Fragmentation always gets you when you least expect it Reliable message passing always is needed, even when you think you don't Message order always is a pain to keep straight=20 Connections really are helpful, and simulating your own is a pain And the big one Congestion control is required, don't ever believe that it isn't for = your protocol There is so much good engineering in TCP that, unlike ICE, is very well=20 proven, and we should not re-invent it. We may not need some of TCP.=A0=A0It may get in the way a bit.=A0=A0It's = MUCH better than UDP for our purposes. Brian ________________________________________=20 From: Adam Fisk [mailto:adamfisk@gmail.com] Sent: Thursday, June 21, 2007 5:55 PM To: Enrico Marocco Cc: Emil Ivov; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] Peer protocol, DHT and running code=20 I totally agree.If we chose TCP, then we would definitely need to mandate ICE-TCP. I think it would be mistake to choose only TCP. I have yet to see robustly-running code for NAT traversal in TCP. I have a lot of faith in = Saikat and co., but I sure haven't been able to get it to work. I = actually think TCP should be one option while also supporting a UDP-based = solution. Well, path MTU discovery may be done using ICMP or the default 1500=20 value may be adopted, as for SIP.Congestion control is not an issue, because we send fragments one by one, only after the previous fragment has been acked.Yes, that's not much efficient, but if fits well in our=20 restricted scope (i.e. for implementing DHTs). Hmnn...I didn't notice that part of XPP (the lock-step approach), but it raises a red flag for me. If you're doing lock-step, why not just use = TFTP (Trivial File Transfer Protocol). If you're looking for simplicity, = that's=20 the way to go! I agree here too.By the way, not that it really matter, but, IIRC some of the most popular p2p applications (emule and azureus) use UDP to maintain the internal DHT, don't they? eMule and Asureus, as well as I believe LimeWire's new DHT, all are UDP-based. That's primarily because they're all based on Kademlia, = though. None of them to anything with NAT traversal. -Adam=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 20:38:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XAE-0001CF-1q; Thu, 21 Jun 2007 20:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XAC-00019j-2y for p2psip@ietf.org; Thu, 21 Jun 2007 20:38:12 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XAB-0003oK-4l for p2psip@ietf.org; Thu, 21 Jun 2007 20:38:11 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I1XA9-00069U-1S; Thu, 21 Jun 2007 20:38:09 -0400 In-Reply-To: <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> References: <4674F5ED.9070000@telecomitalia.it><7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca><4678E6B4.8090000@telecomitalia.it><23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca><46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <258DABAE-46AC-4AE8-8161-B9E89DD3B598@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Thu, 21 Jun 2007 20:38:06 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: 'Emil Ivov' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree, which another reason I like our proposal (draft-matthews-p2psip-hip-hop-00). It allows you to run SIP over TCP or run SIP over TLS . Or SIP over SCTP if you prefer that. It gives you all the existing transport protocols and application layer APIs that are used today, because the changes to work in an overlay happen (mostly) below this layer. Of the proposals published this week, it is the only one that leverages all the existing Internet protocols. - Philip On 21-Jun-07, at 18:12 , Brian Rosen wrote: > > We have a WHOLE LOT of experience with UDP and sip. > > It was a mistake. A big one. We should NEVER have defined sip on > UDP. > Henning told me he regrets not insisting on that way back when. > > Let's not make that mistake again. > > Fragmentation always gets you when you least expect it > Reliable message passing always is needed, even when you think you > don't > Message order always is a pain to keep straight > Connections really are helpful, and simulating your own is a pain > > And the big one > > Congestion control is required, don't ever believe that it isn't > for your > protocol > > There is so much good engineering in TCP that, unlike ICE, is very > well > proven, and we should not re-invent it. > We may not need some of TCP. It may get in the way a bit. It's > MUCH better > than UDP for our purposes. > > Brian > > > ________________________________________ > From: Adam Fisk [mailto:adamfisk@gmail.com] > Sent: Thursday, June 21, 2007 5:55 PM > To: Enrico Marocco > Cc: Emil Ivov; Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > > > I totally agree. If we chose TCP, then we would definitely need to > mandate ICE-TCP. > > I think it would be mistake to choose only TCP. I have yet to see > robustly-running code for NAT traversal in TCP. I have a lot of > faith in > Saikat and co., but I sure haven't been able to get it to work. I > actually > think TCP should be one option while also supporting a UDP-based > solution. > > Well, path MTU discovery may be done using ICMP or the default 1500 > value may be adopted, as for SIP. Congestion control is not an issue, > because we send fragments one by one, only after the previous fragment > has been acked. Yes, that's not much efficient, but if fits well > in our > restricted scope (i.e. for implementing DHTs). > > Hmnn...I didn't notice that part of XPP (the lock-step approach), > but it > raises a red flag for me. If you're doing lock-step, why not just > use TFTP > (Trivial File Transfer Protocol). If you're looking for > simplicity, that's > the way to go! > > > I agree here too. By the way, not that it really matter, but, IIRC > some > of the most popular p2p applications (emule and azureus) use UDP to > maintain the internal DHT, don't they? > > eMule and Asureus, as well as I believe LimeWire's new DHT, all are > UDP-based. That's primarily because they're all based on Kademlia, > though. > None of them to anything with NAT traversal. > > -Adam > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 20:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XIN-0005Y9-3g; Thu, 21 Jun 2007 20:46:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XIM-0005Y3-Ep for p2psip@ietf.org; Thu, 21 Jun 2007 20:46:38 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1XI7-000683-Pq for p2psip@ietf.org; Thu, 21 Jun 2007 20:46:38 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I1XIF-0004gq-Fh; Thu, 21 Jun 2007 20:46:31 -0400 In-Reply-To: References: <9FA16888AD1BF64ABCE6C2532CCEB98A0275AD4F@xmb-sjc-219.amer.cisco.com> <4678F170.7030309@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Thu, 21 Jun 2007 20:46:22 -0400 To: Adam Fisk X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 21-Jun-07, at 18:07 , Adam Fisk wrote: > > > > The solution that you adopted for XPP (= encapsulate it inside UDP) > also works for SCTP. > > That's an interesting idea to me. SCTP doesn't make sense to me > alone (since NAT traversal is undefined), but encapsulation in UDP > for NAT traversal could make a lot of sense. That was the heart of > my RDP suggestion -- use an existing transport for reliable UDP > transmission. > > Like you, I don't like the idea of inventing another transport that > combines much of the functionality of existing transports but that > also crams in specialized DHT handling. I think we should choose > existing protocols that solve the transport problem better than we > should be thinking about here, and then focus on the peer messages > themselves. > > I'm not too familiar with SCTP, though, so encapsulating it in UDP > could be a huge task. I couldn't find a reference quickly when I went looking yesterday, but I am under the impression that a UDP encapsulation for SCTP has already been defined. I have discovered recently that encapsulating a protocol in UDP for NAT traversal reasons is a pretty common trick. Here I am talking about a protocol that normally can run directly over IP. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 20:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XSH-000684-7l; Thu, 21 Jun 2007 20:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1XSF-00067i-AA for p2psip@ietf.org; Thu, 21 Jun 2007 20:56:51 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1XSD-0000q1-NN for p2psip@ietf.org; Thu, 21 Jun 2007 20:56:51 -0400 Received: from lappy ([70.0.116.189]) by quinthar.com for ; Thu, 21 Jun 2007 17:56:45 -0700 From: "David Barrett" To: "'Brian Rosen'" , "'Adam Fisk'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Thu, 21 Jun 2007 17:56:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0Uwc7sL0Pnc2aQUObGNZRxS6u+AAD1wKAAAEWnWA= In-Reply-To: <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Subject: RE: [P2PSIP] Peer protocol, DHT and running code > > Huh. > > I must not understand firewalls and UDP. > > I was told most firewalls, and especially enterprise firewalls did not > allow > arbitrary incoming UDP. The demographic for my clients is mostly home users, but I see less than 1% total UDP blockage overall. So it happens, but so far as I can tell, not often. Seems like a good candidate for a relay service, rather than justification for adoption of TCP. > Some allow symmetric UDP with the outbound > traffic > first. I know I can't run a SIP proxy behind my firewall at home without > configuring the firewall to have a wide open port, and I know what I'm > doing. I know I can't get incoming or outgoin UDP in my office unless I > have a really good reason to ask the IT guys to open a port. YMMV I > guess. To clarify, your enterprise network even blocks UDP outbound? Because that's the only thing that will stop a port-hopping UDP-based NAT-penetration protocol (other than deep packet inspection). > I think reliable+congestion control+fragmentation control+nat traversal > UDP > = TCP+ICE. It seems to me that congestion control only matters for bulk data delivery; not media streaming. For anything where throughput-maximization isn't an issue, you can safely skip congestion control and do something like TFTP (as Adam suggested). Anyway, I'm with Adam: UDP NAT traversal is hard enough. Even the proponents of TCP NAT traversal admit it's harder than with UDP, so it seems crazy to standardize on one of the highest risk, least-proven networking techniques to accommodate a small subset of the network. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 21 22:32:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1YwR-00055T-5R; Thu, 21 Jun 2007 22:32:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1YwQ-00055O-DR for p2psip@ietf.org; Thu, 21 Jun 2007 22:32:06 -0400 Received: from wr-out-0506.google.com ([64.233.184.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1YwQ-0004hU-2m for p2psip@ietf.org; Thu, 21 Jun 2007 22:32:06 -0400 Received: by wr-out-0506.google.com with SMTP id 36so741441wra for ; Thu, 21 Jun 2007 19:32:05 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=dYIuuct+p+/cVAVtwm75eAQ6h6kF/cLGEfi95lfdolO7w3EwGvgKF7z6oQjaMhbKl2Vj3XF4Qf1TcSuIOuXVbtSnNKzGOIfp64L17LCo/ZoxzaAcujG1yaB4EjNvoyuVqOhKYE9CYGlf1+gnpFRCG1bfYLhJQIQoAWWJuklCEWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=X/92Hqe41kpbW4Sl8TUHjg4te7WieWX3cVSBlx4vyjYWraUBDC4RohQZNDEoJdkeYC8YZtu8r3pSJPFRy0JFmmqZQZ/fWhLslXaoOR3uUC+M56tinMadrJnGeVsFht2JhMUrTEM4aOmDJ8auUAWrdrAGb6zTcUB+TCkKe8pvr9U= Received: by 10.90.102.20 with SMTP id z20mr2348210agb.1182479525786; Thu, 21 Jun 2007 19:32:05 -0700 (PDT) Received: by 10.90.117.8 with HTTP; Thu, 21 Jun 2007 19:32:05 -0700 (PDT) Message-ID: Date: Thu, 21 Jun 2007 22:32:05 -0400 From: "Adam Fisk" To: "Brian Rosen" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> X-Google-Sender-Auth: 28f0c390f66eb1cd X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Emil Ivov , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0508308794==" Errors-To: p2psip-bounces@ietf.org --===============0508308794== Content-Type: multipart/alternative; boundary="----=_Part_100018_23269155.1182479525702" ------=_Part_100018_23269155.1182479525702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Brian- > I was told most firewalls, and especially enterprise firewalls did not > allow > arbitrary incoming UDP. That's true in my experience as well. Some allow symmetric UDP with the outbound traffic > first. I know I can't run a SIP proxy behind my firewall at home without > configuring the firewall to have a wide open port, and I know what I'm > doing. That makes perfect sense as well. To run a SIP proxy, you need to have a public address in normal SIP land, as I'm sure you know better than me. With p2p SIP, we'd ideally like to be able to do what you're talking about without manually opening the port, although it's still not clear to me that's a requirement. I know I can't get incoming or outgoin UDP in my office unless I > have a really good reason to ask the IT guys to open a port. YMMV I > guess. Any firewall not allowing outgoing UDP is pretty darn strict. You're completely sure they disallow outgoing? I think reliable+congestion control+fragmentation control+nat traversal UDP > = TCP+ICE. I agree with that 100% except for the NAT traversal. The simplicity win of straight TCP+ICE = HUGE (win that is). I've had trouble getting the TCP traversal stuff to work reliably, though, and I know there are cases where UDP traversal works where TCP doesn't. If NAT traversal is a requirement, I think you'd want to be super robust there and allow both TCP traversal and UDP traversal using a reliable UDP layer. Maybe starting with only TCP traversal and just supporting ICE to allow for future extensions would make sense? I'd like to see more people getting really solid results with the TCP traversal stuff before betting that big on it though. I could never get Saikat's stuff to work, and I tried it with about 6 different NAT configurations. I fully admit the problem was probably on my end, and I could have stuck with it longer, but that was my experience. I also haven't tried their latest release, although it sounds awesome. -Adam ------=_Part_100018_23269155.1182479525702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Brian-


I was told most firewalls, and especially enterprise firewalls did not allow
arbitrary incoming UDP.  

That's true in my experience as well.
 

Some allow symmetric UDP with the outbound traffic
first.  I know I can't run a SIP proxy behind my firewall at home without
configuring the firewall to have a wide open port, and I know what I'm
doing.  

That makes perfect sense as well. To run a SIP proxy, you need to have a public address in normal SIP land, as I'm sure you know better than me.  With p2p SIP, we'd ideally like to be able to do what you're talking about without manually opening the port, although it's still not clear to me that's a requirement. 

I know I can't get incoming or outgoin UDP in my office unless I
have a really good reason to ask the IT guys to open a port.  YMMV I guess.

Any firewall not allowing outgoing UDP is pretty darn strict.  You're completely sure they disallow outgoing?

I think reliable+congestion control+fragmentation control+nat traversal UDP
= TCP+ICE.

I agree with that 100% except for the NAT traversal.  The simplicity win of straight TCP+ICE = HUGE (win that is).  I've had trouble getting the TCP traversal stuff to work reliably, though, and I know there are cases where UDP traversal works where TCP doesn't.  If NAT traversal is a requirement, I think you'd want to be super robust there and allow both TCP traversal and UDP traversal using a reliable UDP layer. 

Maybe starting with only TCP traversal and just supporting ICE to allow for future extensions would make sense?  I'd like to see more people getting really solid results with the TCP traversal stuff before betting that big on it though.  I could never get Saikat's stuff to work, and I tried it with about 6 different NAT configurations.  I fully admit the problem was probably on my end, and I could have stuck with it longer, but that was my experience.  I also haven't tried their latest release, although it sounds awesome.

-Adam

 


------=_Part_100018_23269155.1182479525702-- --===============0508308794== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0508308794==-- From p2psip-bounces@ietf.org Fri Jun 22 03:29:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dXL-0002FJ-ND; Fri, 22 Jun 2007 03:26:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1dXK-0002F6-Se for p2psip@ietf.org; Fri, 22 Jun 2007 03:26:30 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I1dXJ-0000cw-07 for p2psip@ietf.org; Fri, 22 Jun 2007 03:26:30 -0400 X-ClientAddr: 213.145.160.17 Received: from [127.0.0.1] (213-145-160-17.dd.nextgentel.com [213.145.160.17]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5M75XHG003442; Fri, 22 Jun 2007 09:05:33 +0200 Message-ID: <467B7957.40200@teigre.com> Date: Fri, 22 Jun 2007 09:25:11 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Adam Fisk Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> In-Reply-To: X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.5 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: P2PSIP Mailing List , Emil Ivov , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0668990657==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0668990657== Content-Type: multipart/alternative; boundary="------------060008020209040606010307" This is a multi-part message in MIME format. --------------060008020209040606010307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From my experience with enterprises (i.e. not SMBs with LinkSys and dlink etc) deploying ipsec and sip-based apps: They come mostly in two flavors, those who have an open attitude and those with a close-it-all attitude. In the first category, you will mostly expect outgoing UDP and TCP to work, but normally no incoming at all. In the second category, you should expect no outgoing UDP and TCP allowed expect those explicitly allowed (and no, p2p is normally not allowed...) You may also see web proxies and a full block, i.e. only outgoing and incoming goes through the web proxy and no connections go through the firewall directly from the personal computer. Finally, you may also see some deep packet inspection or even intrusion detection prevention (i.e. active dropping based on application-level logic). Financial companies tend to be in this last category, but also others ex. IPR-based companies, like engineering, oil&gas etc can be in this category. The close-it-all group is probably 5-10% of companies, but they tend to be big, so in terms of employees the percentage is larger. I have no numbers though. The tendency is towards closing down... So, one cannot solve the NAT/firewall-traversal without having IT department support. Thus, the solution should be something the IT guys find non-obtrusive and easy to understand. They understand UDP, they understand TCP, they know how to create rules to open ports based on inside-triggers. The rest of the acronyms in this thread is grouped under one word: scary, let's stop it. g-) Adam Fisk wrote: > Hi Brian- > > > I was told most firewalls, and especially enterprise firewalls did > not allow > arbitrary incoming UDP. > > > That's true in my experience as well. > > > Some allow symmetric UDP with the outbound traffic > first. I know I can't run a SIP proxy behind my firewall at home > without > configuring the firewall to have a wide open port, and I know what I'm > doing. > > > That makes perfect sense as well. To run a SIP proxy, you need to have > a public address in normal SIP land, as I'm sure you know better than > me. With p2p SIP, we'd ideally like to be able to do what you're > talking about without manually opening the port, although it's still > not clear to me that's a requirement. > > I know I can't get incoming or outgoin UDP in my office unless I > have a really good reason to ask the IT guys to open a port. YMMV > I guess. > > > Any firewall not allowing outgoing UDP is pretty darn strict. You're > completely sure they disallow outgoing? > > I think reliable+congestion control+fragmentation control+nat > traversal UDP > = TCP+ICE. > > > I agree with that 100% except for the NAT traversal. The simplicity > win of straight TCP+ICE = HUGE (win that is). I've had trouble > getting the TCP traversal stuff to work reliably, though, and I know > there are cases where UDP traversal works where TCP doesn't. If NAT > traversal is a requirement, I think you'd want to be super robust > there and allow both TCP traversal and UDP traversal using a reliable > UDP layer. > > Maybe starting with only TCP traversal and just supporting ICE to > allow for future extensions would make sense? I'd like to see more > people getting really solid results with the TCP traversal stuff > before betting that big on it though. I could never get Saikat's > stuff to work, and I tried it with about 6 different NAT > configurations. I fully admit the problem was probably on my end, and > I could have stuck with it longer, but that was my experience. I also > haven't tried their latest release, although it sounds awesome. > > -Adam > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --------------060008020209040606010307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >From my experience with enterprises (i.e. not SMBs with LinkSys and dlink etc) deploying ipsec and sip-based apps: They come mostly in two flavors, those who have an open attitude and those with a close-it-all attitude. In the first category, you will mostly expect outgoing UDP and TCP to work, but normally no incoming at all. In the second category, you should expect no outgoing UDP and TCP allowed expect those explicitly allowed (and no, p2p is normally not allowed...) You may also see web proxies and a full block, i.e. only outgoing and incoming goes through the web proxy and no connections go through the firewall directly from the personal computer. Finally, you may also see some deep packet inspection or even intrusion detection prevention (i.e. active dropping based on application-level logic). Financial companies tend to be in this last category, but also others ex. IPR-based companies, like engineering, oil&gas etc can be in this category.

The close-it-all group is probably 5-10% of companies, but they tend to be big, so in terms of employees the percentage is larger. I have no numbers though.  The tendency is towards closing down...
So, one cannot solve the NAT/firewall-traversal without having IT department support. Thus, the solution should be something the IT guys find non-obtrusive and easy to understand.  They understand UDP, they understand TCP, they know how to create rules to open ports based on inside-triggers. The rest of the acronyms in this thread is grouped under one word: scary, let's stop it.
g-)

Adam Fisk wrote:
Hi Brian-


I was told most firewalls, and especially enterprise firewalls did not allow
arbitrary incoming UDP.  

That's true in my experience as well.
 

Some allow symmetric UDP with the outbound traffic
first.  I know I can't run a SIP proxy behind my firewall at home without
configuring the firewall to have a wide open port, and I know what I'm
doing.  

That makes perfect sense as well. To run a SIP proxy, you need to have a public address in normal SIP land, as I'm sure you know better than me.  With p2p SIP, we'd ideally like to be able to do what you're talking about without manually opening the port, although it's still not clear to me that's a requirement. 

I know I can't get incoming or outgoin UDP in my office unless I
have a really good reason to ask the IT guys to open a port.  YMMV I guess.

Any firewall not allowing outgoing UDP is pretty darn strict.  You're completely sure they disallow outgoing?

I think reliable+congestion control+fragmentation control+nat traversal UDP
= TCP+ICE.

I agree with that 100% except for the NAT traversal.  The simplicity win of straight TCP+ICE = HUGE (win that is).  I've had trouble getting the TCP traversal stuff to work reliably, though, and I know there are cases where UDP traversal works where TCP doesn't.  If NAT traversal is a requirement, I think you'd want to be super robust there and allow both TCP traversal and UDP traversal using a reliable UDP layer. 

Maybe starting with only TCP traversal and just supporting ICE to allow for future extensions would make sense?  I'd like to see more people getting really solid results with the TCP traversal stuff before betting that big on it though.  I could never get Saikat's stuff to work, and I tried it with about 6 different NAT configurations.  I fully admit the problem was probably on my end, and I could have stuck with it longer, but that was my experience.  I also haven't tried their latest release, although it sounds awesome.

-Adam

 



_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--------------060008020209040606010307-- --===============0668990657== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0668990657==-- From p2psip-bounces@ietf.org Fri Jun 22 04:18:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eLe-0007cs-8i; Fri, 22 Jun 2007 04:18:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1eLd-0007ck-EE for p2psip@ietf.org; Fri, 22 Jun 2007 04:18:29 -0400 Received: from maill.telecomitalia.it ([217.169.121.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1eLb-00066h-Fa for p2psip@ietf.org; Fri, 22 Jun 2007 04:18:29 -0400 Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 10:18:26 +0200 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 10:18:25 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Jun 2007 10:18:25 +0200 Message-ID: <467B8648.5000409@telecomitalia.it> Date: Fri, 22 Jun 2007 10:20:24 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Adam Fisk Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> In-Reply-To: X-OriginalArrivalTime: 22 Jun 2007 08:18:25.0300 (UTC) FILETIME=[E7AFA540:01C7B4A5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: Emil Ivov , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1424158302==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1424158302== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060106090007020304020708" This is a cryptographically signed message in MIME format. --------------ms060106090007020304020708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Adam Fisk wrote: > Well, path MTU discovery may be done using ICMP or the default 1500 > value may be adopted, as for SIP. Congestion control is not an issue, > because we send fragments one by one, only after the previous fragment > has been acked. Yes, that's not much efficient, but if fits well in our > restricted scope (i.e. for implementing DHTs). > > > Hmnn...I didn't notice that part of XPP (the lock-step approach), but it > raises a red flag for me. If you're doing lock-step, why not just use > TFTP (Trivial File Transfer Protocol). If you're looking for > simplicity, that's the way to go! Actually it's not much stressed in the draft, but it's how we implemented it; you could get a clue in section 5.2 "Retransmissions". Thank you for pointing it out, we'll make it clearer. Anyway, XPP collects features which are present in several other protocols (TFTP, RDP, RTP, SCTP, DCCP, TCP...). Unfortunately, none of them has all those we think we need together: reliability, fragmentation, NAT-friendly session establishment, and, yes, unreliability too (i.e. a switch to turn reliability off). -- Ciao, Enrico --------------ms060106090007020304020708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjIyMDgyMDI0WjAjBgkqhkiG9w0BCQQxFgQUj05snXsD tb9klpXJhv802ONc17IwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAFR5SwDH+ietH8qUaehEMlCvRWEJgCUx/DCygC2TjNWXfB/uslVGxrmw OXW4LDEcb7pHpz4Dzh/9/R65LF2f7eDrd9Dn3wsqpL035I+Fgp6ELJsHrpRbAaQhD0WObpLM NMnGrsbb59o0Yy6yjPS62KVizoTaDoB5WS5nsiXFpaNV4i+bMBMI2CNYGLQlV/SKuyICBpQr eORfnz0125WHcSP+EFNHlSdLcczh58xpc7vU3mw0nJPV2nviHZZeKAUafcOUDG+zThvEEZio jjOVC5O8DHIc1pGjp3Tt0fjXWSTWCAE1OZRvpiiF5mPCKQTa5KCH1Mt+1r2W89Nq06zOPjEA AAAAAAA= --------------ms060106090007020304020708-- --===============1424158302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1424158302==-- From p2psip-bounces@ietf.org Fri Jun 22 08:27:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iEd-00019c-KM; Fri, 22 Jun 2007 08:27:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iEc-00019X-4c for p2psip@ietf.org; Fri, 22 Jun 2007 08:27:30 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1iEb-0006vg-Ba for p2psip@ietf.org; Fri, 22 Jun 2007 08:27:30 -0400 Received: from [24.139.16.154] (helo=[10.0.1.3]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I1iEj-0001Vn-Cy; Fri, 22 Jun 2007 08:27:37 -0400 In-Reply-To: <467B7957.40200@teigre.com> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467B7957.40200@teigre.com> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Fri, 22 Jun 2007 08:27:28 -0400 To: "Greger V. Teigre" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.6 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: Emil Ivov , P2PSIP Mailing List , Adam Fisk X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1682328631==" Errors-To: p2psip-bounces@ietf.org --===============1682328631== Content-Type: multipart/alternative; boundary=Apple-Mail-8-197102080 --Apple-Mail-8-197102080 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Regarding the choice of protocols (UDP vs TCP vs ...), here is my take: There are three aspects that we are discussing: 1) Which transport protocol provides the right transport layer features needed for our protocol? 2) Which protocol provides the best NAT traversal properties? 3) Which protocol provides the best Firewall traversal properties? Since I think our protocols have the possibility of being used very widely, I think it is important for us to make the right choice or choices for (1). If UDP offers the right semantics for (1), then we should use it, but if TCP or SCTP or DCCP or some other transport protocol offers the right semantics, then we should choose that instead. As Brian points out, SIP made the wrong choice for (1), and has been paying for it ever since. If the right choice for (1) is a poor choice for (2), then what do we do? Well, we first note that not every host in the world is behind a NAT (only about 80%), and we also note that NATs get replaced every few years (I have heard some figure for this, but sorry, no solid reference). So we do the right thing for (1), and if needed between two specific peers, we encapsulate our chosen protocol for (1) over UDP which most people think provides the best NAT traversal properties. To be more precise, we arrange our connectivity checks to first try sending sending protocol (1) un-encapsulated, and then try sending it encapsulated over UDP and see which makes it through. This is not something that ICE supports today, but it is not difficult to add. In this way, we use un-encapsulated traffic where that is possible, and we use encapsulated traffic where that is needed. If we are successful, and if we make sure that BEHAVE has published specs to say how NATs should handle protocol (1), then we can hope that NATs will be upgraded so that the un-encapsulated case works more and more often as times goes on. And what do we do about (3)? What if our choice for (1) is a poor choice for (3)? Well, one option is to say that we encapsulate (1) with TCP rather than UDP in these cases. That is, in our connectivity checks, we try protocol (1) encapsulated over TCP as well as the other two choices and see what gets through. However, we need to be a careful here, because (3) is about policy and doing this is trying to circumvent that policy. So I think I agree with Greger when he says that you need IT department support. If the applications we run over our overlays are compelling, then the IT departments will open up their firewalls to allow it to come through. And if they don't find it compelling, then that is their decision and we shouldn't be trying to circumvent that decision. - Philip On 22-Jun-07, at 03:25 , Greger V. Teigre wrote: > >From my experience with enterprises (i.e. not SMBs with LinkSys > and dlink etc) deploying ipsec and sip-based apps: They come mostly > in two flavors, those who have an open attitude and those with a > close-it-all attitude. In the first category, you will mostly > expect outgoing UDP and TCP to work, but normally no incoming at > all. In the second category, you should expect no outgoing UDP and > TCP allowed expect those explicitly allowed (and no, p2p is > normally not allowed...) You may also see web proxies and a full > block, i.e. only outgoing and incoming goes through the web proxy > and no connections go through the firewall directly from the > personal computer. Finally, you may also see some deep packet > inspection or even intrusion detection prevention (i.e. active > dropping based on application-level logic). Financial companies > tend to be in this last category, but also others ex. IPR-based > companies, like engineering, oil&gas etc can be in this category. > > The close-it-all group is probably 5-10% of companies, but they > tend to be big, so in terms of employees the percentage is larger. > I have no numbers though. The tendency is towards closing down... > So, one cannot solve the NAT/firewall-traversal without having IT > department support. Thus, the solution should be something the IT > guys find non-obtrusive and easy to understand. They understand > UDP, they understand TCP, they know how to create rules to open > ports based on inside-triggers. The rest of the acronyms in this > thread is grouped under one word: scary, let's stop it. > g-) > > Adam Fisk wrote: >> Hi Brian- >> >> >> I was told most firewalls, and especially enterprise firewalls did >> not allow >> arbitrary incoming UDP. >> >> That's true in my experience as well. >> >> >> Some allow symmetric UDP with the outbound traffic >> first. I know I can't run a SIP proxy behind my firewall at home >> without >> configuring the firewall to have a wide open port, and I know what >> I'm >> doing. >> >> That makes perfect sense as well. To run a SIP proxy, you need to >> have a public address in normal SIP land, as I'm sure you know >> better than me. With p2p SIP, we'd ideally like to be able to do >> what you're talking about without manually opening the port, >> although it's still not clear to me that's a requirement. >> >> I know I can't get incoming or outgoin UDP in my office unless I >> have a really good reason to ask the IT guys to open a port. YMMV >> I guess. >> >> Any firewall not allowing outgoing UDP is pretty darn strict. >> You're completely sure they disallow outgoing? >> >> I think reliable+congestion control+fragmentation control+nat >> traversal UDP >> = TCP+ICE. >> >> I agree with that 100% except for the NAT traversal. The >> simplicity win of straight TCP+ICE = HUGE (win that is). I've had >> trouble getting the TCP traversal stuff to work reliably, though, >> and I know there are cases where UDP traversal works where TCP >> doesn't. If NAT traversal is a requirement, I think you'd want to >> be super robust there and allow both TCP traversal and UDP >> traversal using a reliable UDP layer. >> >> Maybe starting with only TCP traversal and just supporting ICE to >> allow for future extensions would make sense? I'd like to see >> more people getting really solid results with the TCP traversal >> stuff before betting that big on it though. I could never get >> Saikat's stuff to work, and I tried it with about 6 different NAT >> configurations. I fully admit the problem was probably on my end, >> and I could have stuck with it longer, but that was my >> experience. I also haven't tried their latest release, although >> it sounds awesome. >> >> -Adam >> >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip --Apple-Mail-8-197102080 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Regarding the choice of = protocols (UDP vs TCP vs ...), here is my take:

There are three aspects = that we are discussing:
1) Which transport protocol provides = the right transport layer features needed for our protocol?
2) = Which protocol provides the best NAT traversal properties?
3) = Which protocol provides the best Firewall traversal = properties?

Since I think our protocols = have the possibility of being used very widely, I think it is important = for us to make the right choice or choices for (1). If UDP offers the = right semantics for (1), then we should use it, but if TCP or SCTP or = DCCP or some other transport protocol offers the right semantics, then = we should choose that instead. As Brian points out, SIP made the wrong = choice for (1), and has been paying for it ever since.

If the right choice for (1) = is a poor choice for (2), then what do we do? Well, we first note that = not every host in the world is behind a NAT (only about 80%), and we = also note that NATs get replaced every few years (I have heard some = figure for this, but sorry, no solid reference). So we do the right = thing for (1), and if needed between two specific peers, we encapsulate = our chosen protocol for (1) over UDP which most people think provides = the best NAT traversal properties. To be more precise, we arrange our = connectivity checks to first try sending sending protocol (1) = un-encapsulated, and then try sending it encapsulated over UDP and see = which makes it through. This is not something that ICE supports today, = but it is not difficult to add. In this way, we use un-encapsulated = traffic where that is possible, and we use encapsulated traffic where = that is needed. If we are successful, and if we make sure that BEHAVE = has published specs to say how NATs should handle protocol (1), then we = can hope that NATs will be upgraded so that the un-encapsulated case = works more and more often as times goes on.

And what do we do about = (3)?=A0 What if our choice for (1) is a poor choice for (3)? Well, one = option is to say that we encapsulate (1) with TCP rather than UDP in = these cases. That is, in our connectivity checks, we try protocol (1) = encapsulated over TCP as well as the other two choices and see what gets = through. However, we need to be a careful here, because (3) is about = policy and doing this is trying to circumvent that policy. So I think I = agree with Greger when he says that you need IT department support. If = the applications we run over our overlays are compelling, then the IT = departments will open up their firewalls to allow it to come through. = And if they don't find it compelling, then that is their decision and we = shouldn't be trying to circumvent that=A0 decision.=A0

- Philip



On 22-Jun-07, = at 03:25 , Greger V. Teigre wrote:

>=46rom = my experience with enterprises (i.e. not SMBs with LinkSys and dlink = etc) deploying ipsec and sip-based apps: They come mostly in two = flavors, those who have an open attitude and those with a close-it-all = attitude. In the first category, you will mostly expect outgoing UDP and = TCP to work, but normally no incoming at all. In the second category, = you should expect no outgoing UDP and TCP allowed expect those = explicitly allowed (and no, p2p is normally not allowed...) You may also = see web proxies and a full block, i.e. only outgoing and incoming goes = through the web proxy and no connections go through the firewall = directly from the personal computer. Finally, you may also see some deep = packet inspection or even intrusion detection prevention (i.e. active = dropping based on application-level logic). Financial companies tend to = be in this last category, but also others ex. IPR-based companies, like = engineering, oil&gas etc can be in this category.

The = close-it-all group is probably 5-10% of companies, but they tend to be = big, so in terms of employees the percentage is larger. I have no = numbers though.=A0 The tendency is towards closing down...
So, one = cannot solve the NAT/firewall-traversal without having IT department = support. Thus, the solution should be something the IT guys find = non-obtrusive and easy to understand.=A0 They understand UDP, they = understand TCP, they know how to create rules to open ports based on = inside-triggers. The rest of the acronyms in this thread is grouped = under one word: scary, let's stop it.
g-)

Adam Fisk wrote: =
Hi Brian-


I was told = most firewalls, and especially enterprise firewalls did not allow =
arbitrary incoming UDP.=A0=A0

That's true = in my experience as well.
=A0

Some allow = symmetric UDP with the outbound traffic
first.=A0=A0I know I can't = run a SIP proxy behind my firewall at home without
configuring the = firewall to have a wide open port, and I know what I'm
doing.=A0=A0 =

That makes perfect sense as well. To run a SIP = proxy, you need to have a public address in normal SIP land, as I'm sure = you know better than me.=A0 With p2p SIP, we'd ideally like to be able = to do what you're talking about without manually opening the port, = although it's still not clear to me that's a requirement.=A0
=

I know I can't get incoming or outgoin UDP in my office unless = I
have a really good reason to ask the IT guys to open a port.=A0=A0YM= MV I guess.

Any firewall not allowing outgoing = UDP is pretty darn strict.=A0 You're completely sure they disallow = outgoing?

I think reliable+congestion = control+fragmentation control+nat traversal UDP
=3D = TCP+ICE.

I agree with that 100% except for the = NAT traversal.=A0 The simplicity win of straight TCP+ICE =3D HUGE (win = that is).=A0 I've had trouble getting the TCP traversal stuff to work = reliably, though, and I know there are cases where UDP traversal works = where TCP doesn't.=A0 If NAT traversal is a requirement, I think you'd = want to be super robust there and allow both TCP traversal and UDP = traversal using a reliable UDP layer.=A0

Maybe starting with = only TCP traversal and just supporting ICE to allow for future = extensions would make sense?=A0 I'd like to see more people getting = really solid results with the TCP traversal stuff before betting that = big on it though.=A0 I could never get Saikat's stuff to work, and I = tried it with about 6 different NAT configurations.=A0 I fully admit the = problem was probably on my end, and I could have stuck with it longer, = but that was my experience.=A0 I also haven't tried their latest = release, although it sounds awesome.

-Adam

=A0
= 

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.o=
rg/mailman/listinfo/p2psip
P2PSIP mailing list
=

= --Apple-Mail-8-197102080-- --===============1682328631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1682328631==-- From p2psip-bounces@ietf.org Fri Jun 22 08:49:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iZu-0001FK-IL; Fri, 22 Jun 2007 08:49:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1iZt-0001FB-C5 for p2psip@ietf.org; Fri, 22 Jun 2007 08:49:29 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1iZq-00040n-I0 for p2psip@ietf.org; Fri, 22 Jun 2007 08:49:29 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I1iZh-00063h-9n; Fri, 22 Jun 2007 07:49:18 -0500 From: "Brian Rosen" To: "'Greger V. Teigre'" , "'Adam Fisk'" References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467B7957.40200@teigre.com> Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Fri, 22 Jun 2007 08:49:20 -0400 Message-ID: <083201c7b4cb$c2c6fcd0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <467B7957.40200@teigre.com> Thread-Index: Ace0nn5KrUeqO6kxQR6LBBKfDHxWZwALEoiQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4da339c42fe5be09fa120bb0fcc4a575 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0564875606==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0564875606== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0833_01C7B4AA.3BB55CD0" This is a multi-part message in MIME format. ------=_NextPart_000_0833_01C7B4AA.3BB55CD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Right, no incoming UDP (or TCP) in something like 80% of enterprise. That's what I thought. They usually have a DMZ and will allow incoming for several ports into specific servers in the DMZ. That's where the proxy goes. I have lived in the 20% side for a while (one company ago). They were really stingy about opening a port. They were more willing to open TCP ports than UDP ports. It's because the firewall has a better shot at spotting bad behavior with TCP than with UDP. Took me six months to get them to open 5060 to a specific server. Of course, as Greger said, if the firewall can be statefull for the protocol you want, then it's easier to get them to approve. Brian _____ From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Friday, June 22, 2007 3:25 AM To: Adam Fisk Cc: Brian Rosen; Emil Ivov; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] Peer protocol, DHT and running code >From my experience with enterprises (i.e. not SMBs with LinkSys and dlink etc) deploying ipsec and sip-based apps: They come mostly in two flavors, those who have an open attitude and those with a close-it-all attitude. In the first category, you will mostly expect outgoing UDP and TCP to work, but normally no incoming at all. In the second category, you should expect no outgoing UDP and TCP allowed expect those explicitly allowed (and no, p2p is normally not allowed...) You may also see web proxies and a full block, i.e. only outgoing and incoming goes through the web proxy and no connections go through the firewall directly from the personal computer. Finally, you may also see some deep packet inspection or even intrusion detection prevention (i.e. active dropping based on application-level logic). Financial companies tend to be in this last category, but also others ex. IPR-based companies, like engineering, oil&gas etc can be in this category. The close-it-all group is probably 5-10% of companies, but they tend to be big, so in terms of employees the percentage is larger. I have no numbers though. The tendency is towards closing down... So, one cannot solve the NAT/firewall-traversal without having IT department support. Thus, the solution should be something the IT guys find non-obtrusive and easy to understand. They understand UDP, they understand TCP, they know how to create rules to open ports based on inside-triggers. The rest of the acronyms in this thread is grouped under one word: scary, let's stop it. g-) Adam Fisk wrote: Hi Brian- I was told most firewalls, and especially enterprise firewalls did not allow arbitrary incoming UDP. That's true in my experience as well. Some allow symmetric UDP with the outbound traffic first. I know I can't run a SIP proxy behind my firewall at home without configuring the firewall to have a wide open port, and I know what I'm doing. That makes perfect sense as well. To run a SIP proxy, you need to have a public address in normal SIP land, as I'm sure you know better than me. With p2p SIP, we'd ideally like to be able to do what you're talking about without manually opening the port, although it's still not clear to me that's a requirement. I know I can't get incoming or outgoin UDP in my office unless I have a really good reason to ask the IT guys to open a port. YMMV I guess. Any firewall not allowing outgoing UDP is pretty darn strict. You're completely sure they disallow outgoing? I think reliable+congestion control+fragmentation control+nat traversal UDP = TCP+ICE. I agree with that 100% except for the NAT traversal. The simplicity win of straight TCP+ICE = HUGE (win that is). I've had trouble getting the TCP traversal stuff to work reliably, though, and I know there are cases where UDP traversal works where TCP doesn't. If NAT traversal is a requirement, I think you'd want to be super robust there and allow both TCP traversal and UDP traversal using a reliable UDP layer. Maybe starting with only TCP traversal and just supporting ICE to allow for future extensions would make sense? I'd like to see more people getting really solid results with the TCP traversal stuff before betting that big on it though. I could never get Saikat's stuff to work, and I tried it with about 6 different NAT configurations. I fully admit the problem was probably on my end, and I could have stuck with it longer, but that was my experience. I also haven't tried their latest release, although it sounds awesome. -Adam _____ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0833_01C7B4AA.3BB55CD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Right, no incoming UDP (or TCP) in something like 80% of enterprise.  That’s what I = thought.  They usually have a DMZ and will allow incoming for several ports into specific = servers in the DMZ.  That’s where the proxy = goes.

 

I have lived in the 20% side for a = while (one company ago).  They were really stingy about opening a port.  = They were more willing to open TCP ports than UDP ports.  It’s because the = firewall has a better shot at spotting bad behavior with TCP than with UDP.  Took = me six months to get them to open 5060 to  a specific server.  Of = course, as Greger said, if the firewall can be statefull for the protocol you want, then = it’s easier to get them to approve.

 

Brian

 

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Friday, June 22, = 2007 3:25 AM
To: Adam Fisk
Cc: Brian Rosen; Emil = Ivov; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] = Peer protocol, DHT and running code

 

From my experience with enterprises (i.e. not = SMBs with LinkSys and dlink etc) deploying ipsec and sip-based apps: They = come mostly in two flavors, those who have an open attitude and those with a close-it-all attitude. In the first category, you will mostly expect = outgoing UDP and TCP to work, but normally no incoming at all. In the second = category, you should expect no outgoing UDP and TCP allowed expect those = explicitly allowed (and no, p2p is normally not allowed...) You may also see web = proxies and a full block, i.e. only outgoing and incoming goes through the web = proxy and no connections go through the firewall directly from the personal = computer. Finally, you may also see some deep packet inspection or even intrusion detection prevention (i.e. active dropping based on application-level = logic). Financial companies tend to be in this last category, but also others = ex. IPR-based companies, like engineering, oil&gas etc can be in this = category.

The close-it-all group is probably 5-10% of companies, but they tend to = be big, so in terms of employees the percentage is larger. I have no numbers though.  The tendency is towards closing down...
So, one cannot solve the NAT/firewall-traversal without having IT = department support. Thus, the solution should be something the IT guys find = non-obtrusive and easy to understand.  They understand UDP, they understand TCP, = they know how to create rules to open ports based on inside-triggers. The = rest of the acronyms in this thread is grouped under one word: scary, let's stop = it.
g-)

Adam Fisk wrote:

Hi = Brian-


I was told most firewalls, and especially enterprise firewalls did not = allow
arbitrary incoming UDP.  


That's true in my experience as well.
 

 

Some allow symmetric UDP with the outbound = traffic
first.  I know I can't run a SIP proxy behind my firewall at = home without
configuring the firewall to have a wide open port, and I know what = I'm
doing.  


That makes perfect sense as well. To run a SIP proxy, you need to have a = public address in normal SIP land, as I'm sure you know better than me.  = With p2p SIP, we'd ideally like to be able to do what you're talking about = without manually opening the port, although it's still not clear to me that's a requirement. 

 

I know I can't get incoming or outgoin UDP in = my office unless I
have a really good reason to ask the IT guys to open a = port.  YMMV I guess.


Any firewall not allowing outgoing UDP is pretty darn strict.  = You're completely sure they disallow outgoing?

 

I think reliable+congestion = control+fragmentation control+nat traversal UDP
=3D TCP+ICE.


I agree with that 100% except for the NAT traversal.  The = simplicity win of straight TCP+ICE =3D HUGE (win that is).  I've had trouble = getting the TCP traversal stuff to work reliably, though, and I know there are cases = where UDP traversal works where TCP doesn't.  If NAT traversal is a = requirement, I think you'd want to be super robust there and allow both TCP traversal = and UDP traversal using a reliable UDP layer. 

Maybe starting with only TCP traversal and just supporting ICE to allow = for future extensions would make sense?  I'd like to see more people = getting really solid results with the TCP traversal stuff before betting that = big on it though.  I could never get Saikat's stuff to work, and I tried it = with about 6 different NAT configurations.  I fully admit the problem = was probably on my end, and I could have stuck with it longer, but that was = my experience.  I also haven't tried their latest release, although it = sounds awesome.

-Adam

 

 



 






 
______________________________________________=
_
P2PSIP mailing =
list
P2PSIP@ietf.org
https://www1.ietf.=
org/mailman/listinfo/p2psip
 
------=_NextPart_000_0833_01C7B4AA.3BB55CD0-- --===============0564875606== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0564875606==-- From p2psip-bounces@ietf.org Fri Jun 22 09:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jLW-0004Nj-D4; Fri, 22 Jun 2007 09:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1jLV-0004Ne-4L for p2psip@ietf.org; Fri, 22 Jun 2007 09:38:41 -0400 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1jLT-0001LR-Pa for p2psip@ietf.org; Fri, 22 Jun 2007 09:38:41 -0400 Received: by wr-out-0506.google.com with SMTP id 36so832138wra for ; Fri, 22 Jun 2007 06:38:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JAM/WpsClNMRDYLjpOI7CYFFoqKLuzxOXpUZ8MxDJsv/pbgdAjB/2RO1zpw6cMMxVbswhEJVUYC7jqCEac+kISQUS8vzRSheYpJRDRuHHFAWcWqVhU1DmyPtdafni2ankhnZeo/WRRADyn1QG7We8+kRWKCPsLplW9cSxzViE5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=h3hN6Av1LsEt2nRh7zRUzvI2Cy+hob3I3kc5GmLrUPJ2r/TzWNZ2fdXiW5JDbebI64XOjtClWzRcLuI/QGGq0jmXF8EXler5YQBHQSgz2c53KQ0kMA1Z5a6b7uCRyYIur4bUL3V+fKNGHwN8mnuu4jTr3OeyFD7l//KnBzpAugU= Received: by 10.100.42.7 with SMTP id p7mr1693069anp.1182519519490; Fri, 22 Jun 2007 06:38:39 -0700 (PDT) Received: by 10.100.106.1 with HTTP; Fri, 22 Jun 2007 06:38:39 -0700 (PDT) Message-ID: <20d2bdfb0706220638k54613a1ag240c7524c7e0792@mail.gmail.com> Date: Fri, 22 Jun 2007 09:38:39 -0400 From: "Bruce Lowekamp" To: "Brian Rosen" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> X-Google-Sender-Auth: fdaf18b40c2e0026 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: P2PSIP Mailing List , Emil Ivov , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We need to look carefully at the requirements for P2PSIP before we make a decision on transport protocol. TCP may have (I would vote would have) been a better choice for SIP than UDP. But that's not necessarily relevant. They're different protocols. SIP requires a large number of clients to connect with small numbers of well-provisioned (including well-networked) servers. P2PSIP requires large numbers of peers to connect with each other. There is no requirement (in many use cases) about the quality of provisioning for these peers. Typically a peer will establish log(N) connections in a routing table and may be in regular correspondence with some other number of peers based on the activity of the user. Given enough resources (I think someone in this or another thread recently mentioned using P2PSIP on motes, so it might be an issue) to establish and maintain that many TCP connections, and given that they are able to punch TCP through any intervening NATs and firewalls without resorting to a relay, I think TCP (or similar stream-based) is probably the right transport protocol for those connections. But there will be many, many cases where a UDP connection can be punched through and TCP can't. I don't think TCP is the right transport for iterative routing. It makes no more sense there than it does for DNS queries. Supporting multiple transport choices shouldn't be a problem for a peer protocol. Speaking for RELOAD, peers are able to advertise multiple PEER-IP-PORT attributes in their SOURCE-INFO, which means they can specify both a TCP and UDP port (or either if the peer doesn't want to or can't support both). When NAT traversal is required, the OPEN method includes an SDP attribute for ICE negotiation that can, of course, include both udp and tcp candidates. I think we need to look carefully at the requirements we have, but I personally think there are enough arguments for leaving UDP in that I don't think we should say anything stronger than SHOULD prefer TCP. Bruce On 6/21/07, Brian Rosen wrote: > > We have a WHOLE LOT of experience with UDP and sip. > > It was a mistake. A big one. We should NEVER have defined sip on UDP. > Henning told me he regrets not insisting on that way back when. > > Let's not make that mistake again. > > Fragmentation always gets you when you least expect it > Reliable message passing always is needed, even when you think you don't > Message order always is a pain to keep straight > Connections really are helpful, and simulating your own is a pain > > And the big one > > Congestion control is required, don't ever believe that it isn't for your > protocol > > There is so much good engineering in TCP that, unlike ICE, is very well > proven, and we should not re-invent it. > We may not need some of TCP. It may get in the way a bit. It's MUCH better > than UDP for our purposes. > > Brian > > > ________________________________________ > From: Adam Fisk [mailto:adamfisk@gmail.com] > Sent: Thursday, June 21, 2007 5:55 PM > To: Enrico Marocco > Cc: Emil Ivov; Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] Peer protocol, DHT and running code > > > > I totally agree.If we chose TCP, then we would definitely need to > mandate ICE-TCP. > > I think it would be mistake to choose only TCP. I have yet to see > robustly-running code for NAT traversal in TCP. I have a lot of faith in > Saikat and co., but I sure haven't been able to get it to work. I actually > think TCP should be one option while also supporting a UDP-based solution. > > Well, path MTU discovery may be done using ICMP or the default 1500 > value may be adopted, as for SIP.Congestion control is not an issue, > because we send fragments one by one, only after the previous fragment > has been acked.Yes, that's not much efficient, but if fits well in our > restricted scope (i.e. for implementing DHTs). > > Hmnn...I didn't notice that part of XPP (the lock-step approach), but it > raises a red flag for me. If you're doing lock-step, why not just use TFTP > (Trivial File Transfer Protocol). If you're looking for simplicity, that's > the way to go! > > > I agree here too.By the way, not that it really matter, but, IIRC some > of the most popular p2p applications (emule and azureus) use UDP to > maintain the internal DHT, don't they? > > eMule and Asureus, as well as I believe LimeWire's new DHT, all are > UDP-based. That's primarily because they're all based on Kademlia, though. > None of them to anything with NAT traversal. > > -Adam > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 22 10:21:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k0r-0001VH-T3; Fri, 22 Jun 2007 10:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1k0q-0001UJ-05 for p2psip@ietf.org; Fri, 22 Jun 2007 10:21:24 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1k0o-0003Xc-OZ for p2psip@ietf.org; Fri, 22 Jun 2007 10:21:23 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5MELI9e014502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 22 Jun 2007 10:21:22 -0400 (EDT) In-Reply-To: <20d2bdfb0706220638k54613a1ag240c7524c7e0792@mail.gmail.com> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <20d2bdfb0706220638k54613a1ag240c7524c7e0792@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D5C5129-0E47-4F5D-A38B-A06F38F361DE@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Fri, 22 Jun 2007 10:22:25 -0400 To: "Bruce Lowekamp" X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Since this canard seems to pop up again and again, without any basis in measurement: We've been running actual experiments, as opposed to hear-say, on large-volume TCP servers. We have tested up to 400,000 simultaneous connections on a Linux box. I don't think a P2P system is going to maintain that many - the NAT is going to run out of mappings looong before that... Motes aren't going to be limited by TCP connections; they are going to be energy-limited, which makes participation in large-scale P2P a rather dubious idea to begin with. On Jun 22, 2007, at 9:38 AM, Bruce Lowekamp wrote: > > Given enough resources (I think someone in this or another thread > recently mentioned using P2PSIP on motes, so it might be an issue) to > establish and maintain that many TCP connections, and given that they > are able to punch TCP through any intervening NATs and firewalls > without resorting to a relay, I think TCP (or similar stream-based) is > probably the right transport protocol for those connections. But > there will be many, many cases where a UDP connection can be punched > through and TCP can't. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 22 11:15:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kqn-0001fj-A3; Fri, 22 Jun 2007 11:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1kql-0001eV-QC for p2psip@ietf.org; Fri, 22 Jun 2007 11:15:03 -0400 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1kqk-0006HC-Ii for p2psip@ietf.org; Fri, 22 Jun 2007 11:15:03 -0400 Received: by wr-out-0506.google.com with SMTP id 36so863953wra for ; Fri, 22 Jun 2007 08:15:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=fNTF9UKiOjcegJVoN95V5ayEFtLWiYoxPG+hq3hJqKfTHLlgSdVUuR7Eb7t3YHwClyANExwUtYc0QOtcU4Jh2de32D58oatZTUdcRaR5DFprh2LYNOIcpRn+G0Jv8RjIlCWhG/of3bxllUG1JkD+Ve5Q3Gn0FzHyHFQCAv7iw40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=sjSHJwNZlUBzV0QDTKrcETpzgS4AHwUGacyLn9gYsElKmYpHz4Nb3hplT+o97CwVmcexVQn+OcQnyqBejzuK9fo8jJIgvQeae92JazMSjOp/9puCZMi5XMUyqER9cqtJwdp2Vyyz/rKsF3IdT4FfH6NyitJwtPSmTNCix61gBOU= Received: by 10.100.141.13 with SMTP id o13mr1798049and.1182525301939; Fri, 22 Jun 2007 08:15:01 -0700 (PDT) Received: by 10.100.106.1 with HTTP; Fri, 22 Jun 2007 08:15:01 -0700 (PDT) Message-ID: <20d2bdfb0706220815j35c5b364n2e42177b9a7aa7f@mail.gmail.com> Date: Fri, 22 Jun 2007 11:15:01 -0400 From: "Bruce Lowekamp" To: "Henning Schulzrinne" Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: <0D5C5129-0E47-4F5D-A38B-A06F38F361DE@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <20d2bdfb0706220638k54613a1ag240c7524c7e0792@mail.gmail.com> <0D5C5129-0E47-4F5D-A38B-A06F38F361DE@cs.columbia.edu> X-Google-Sender-Auth: f476ac80ef2ed7e7 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Speaking of canards, are you suggesting that all P2PSIP peers are going to be large-volume linux servers? Motes, cell phones, hardphones, etc are slightly different devices. Many, of course, can maintain more than enough TCP connections, but I fail to see how the large-volume TCP server capacity illustrates that. If there are published numbers on the cpu power, memory footprint, and power consumption requirements of udp vs tcp for periodic messaging on embedded devices, that would be very interesting. A comparison that included TLS and DTLS (or other secure protocols) would be even more interesting, as I suspect the cpu & power tradeoffs are different. None of this addresses the issues of iterative routing or NAT/firewall traversal that are also strong arguments that TCP cannot be the only transport protocol. Bruce On 6/22/07, Henning Schulzrinne wrote: > Since this canard seems to pop up again and again, without any basis > in measurement: We've been running actual experiments, as opposed to > hear-say, on large-volume TCP servers. We have tested up to 400,000 > simultaneous connections on a Linux box. I don't think a P2P system > is going to maintain that many - the NAT is going to run out of > mappings looong before that... Motes aren't going to be limited by > TCP connections; they are going to be energy-limited, which makes > participation in large-scale P2P a rather dubious idea to begin with. > > On Jun 22, 2007, at 9:38 AM, Bruce Lowekamp wrote: > > > > > Given enough resources (I think someone in this or another thread > > recently mentioned using P2PSIP on motes, so it might be an issue) to > > establish and maintain that many TCP connections, and given that they > > are able to punch TCP through any intervening NATs and firewalls > > without resorting to a relay, I think TCP (or similar stream-based) is > > probably the right transport protocol for those connections. But > > there will be many, many cases where a UDP connection can be punched > > through and TCP can't. > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 22 14:05:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nVQ-0004IO-P2; Fri, 22 Jun 2007 14:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1nVP-0004FP-Vt for p2psip@ietf.org; Fri, 22 Jun 2007 14:05:11 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I1nVO-0005Xf-IR for p2psip@ietf.org; Fri, 22 Jun 2007 14:05:11 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Fri, 22 Jun 2007 11:05:05 -0700 From: "David Barrett" To: "'Brian Rosen'" , "'Greger V. Teigre'" , "'Adam Fisk'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Fri, 22 Jun 2007 11:05:03 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <083201c7b4cb$c2c6fcd0$640fa8c0@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0nn5KrUeqO6kxQR6LBBKfDHxWZwALEoiQAAroH7A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 58a894dbf8d0c4c152ea0be9e8cd3d14 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1026184484==" Errors-To: p2psip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1026184484== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C7B4BD.30060CF0" This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C7B4BD.30060CF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That matches what I've seen in terms of UDP nat and firewalls: - 20% not firewalled, not natted - 13% natted with "full cone" behavior - 6% inbound-firewalled but not natted - 45% natted with "restricted cone" behavior - 16% natted with "symmetric" behavior (of some flavor) - 1% outbound-firewalled (unknown of they're also natted) The first two (comprising 33% of clients) can accept arbitrary incoming connections once the port is open, so all both are more or less globally available. The next 51% you can establish connections with using simultaneous connection. And the remaining 16% get trickier, but still work. I've only seen ~1% of the network truly blocked from using UDP, but there could be some "self-selection" going on that is skewing those results. -david _____ From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, June 22, 2007 5:49 AM To: 'Greger V. Teigre'; 'Adam Fisk' Cc: 'Emil Ivov'; 'Philip Matthews'; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] Peer protocol, DHT and running code Right, no incoming UDP (or TCP) in something like 80% of enterprise. That's what I thought. They usually have a DMZ and will allow incoming for several ports into specific servers in the DMZ. That's where the proxy goes. I have lived in the 20% side for a while (one company ago). They were really stingy about opening a port. They were more willing to open TCP ports than UDP ports. It's because the firewall has a better shot at spotting bad behavior with TCP than with UDP. Took me six months to get them to open 5060 to a specific server. Of course, as Greger said, if the firewall can be statefull for the protocol you want, then it's easier to get them to approve. Brian _____ From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Friday, June 22, 2007 3:25 AM To: Adam Fisk Cc: Brian Rosen; Emil Ivov; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] Peer protocol, DHT and running code >From my experience with enterprises (i.e. not SMBs with LinkSys and dlink etc) deploying ipsec and sip-based apps: They come mostly in two flavors, those who have an open attitude and those with a close-it-all attitude. In the first category, you will mostly expect outgoing UDP and TCP to work, but normally no incoming at all. In the second category, you should expect no outgoing UDP and TCP allowed expect those explicitly allowed (and no, p2p is normally not allowed...) You may also see web proxies and a full block, i.e. only outgoing and incoming goes through the web proxy and no connections go through the firewall directly from the personal computer. Finally, you may also see some deep packet inspection or even intrusion detection prevention (i.e. active dropping based on application-level logic). Financial companies tend to be in this last category, but also others ex. IPR-based companies, like engineering, oil&gas etc can be in this category. The close-it-all group is probably 5-10% of companies, but they tend to be big, so in terms of employees the percentage is larger. I have no numbers though. The tendency is towards closing down... So, one cannot solve the NAT/firewall-traversal without having IT department support. Thus, the solution should be something the IT guys find non-obtrusive and easy to understand. They understand UDP, they understand TCP, they know how to create rules to open ports based on inside-triggers. The rest of the acronyms in this thread is grouped under one word: scary, let's stop it. g-) Adam Fisk wrote: Hi Brian- I was told most firewalls, and especially enterprise firewalls did not allow arbitrary incoming UDP. That's true in my experience as well. Some allow symmetric UDP with the outbound traffic first. I know I can't run a SIP proxy behind my firewall at home without configuring the firewall to have a wide open port, and I know what I'm doing. That makes perfect sense as well. To run a SIP proxy, you need to have a public address in normal SIP land, as I'm sure you know better than me. With p2p SIP, we'd ideally like to be able to do what you're talking about without manually opening the port, although it's still not clear to me that's a requirement. I know I can't get incoming or outgoin UDP in my office unless I have a really good reason to ask the IT guys to open a port. YMMV I guess. Any firewall not allowing outgoing UDP is pretty darn strict. You're completely sure they disallow outgoing? I think reliable+congestion control+fragmentation control+nat traversal UDP = TCP+ICE. I agree with that 100% except for the NAT traversal. The simplicity win of straight TCP+ICE = HUGE (win that is). I've had trouble getting the TCP traversal stuff to work reliably, though, and I know there are cases where UDP traversal works where TCP doesn't. If NAT traversal is a requirement, I think you'd want to be super robust there and allow both TCP traversal and UDP traversal using a reliable UDP layer. Maybe starting with only TCP traversal and just supporting ICE to allow for future extensions would make sense? I'd like to see more people getting really solid results with the TCP traversal stuff before betting that big on it though. I could never get Saikat's stuff to work, and I tried it with about 6 different NAT configurations. I fully admit the problem was probably on my end, and I could have stuck with it longer, but that was my experience. I also haven't tried their latest release, although it sounds awesome. -Adam _____ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0087_01C7B4BD.30060CF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That matches what I’ve seen = in terms of UDP nat and firewalls:

 

-          20% not firewalled, not natted

-          13% natted with “full cone” = behavior

-          6% = inbound-firewalled but not natted

-          45% natted with “restricted cone” = behavior

-          16% natted with “symmetric” behavior (of some = flavor)

-          1% outbound-firewalled (unknown of they’re also = natted)

 

The first two (comprising 33% of = clients) can accept arbitrary incoming connections once the port is open, so all both = are more or less globally available.  The next 51% you can establish = connections with using simultaneous connection.  And the remaining 16% get = trickier, but still work.

 

I’ve only seen ~1% of the = network truly blocked from using UDP, but there could be some = “self-selection” going on that is skewing those results.

 

-david

 

From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Friday, June 22, = 2007 5:49 AM
To: 'Greger V. Teigre'; = 'Adam Fisk'
Cc: 'Emil Ivov'; 'Philip Matthews'; 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] = Peer protocol, DHT and running code

 

Right, no incoming UDP (or TCP) in something like 80% of enterprise.  That’s what I = thought.  They usually have a DMZ and will allow incoming for several ports into = specific servers in the DMZ.  That’s where the proxy = goes.

 

I have lived in the 20% side for a = while (one company ago).  They were really stingy about opening a = port.  They were more willing to open TCP ports than UDP ports.  = It’s because the firewall has a better shot at spotting bad behavior with TCP = than with UDP.  Took me six months to get them to open 5060 to  a = specific server.  Of course, as Greger said, if the firewall can be = statefull for the protocol you want, then it’s easier to get them to = approve.

 

Brian

 

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Friday, June 22, = 2007 3:25 AM
To: Adam Fisk
Cc: Brian Rosen; Emil = Ivov; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] = Peer protocol, DHT and running code

 

From my experience with enterprises (i.e. not = SMBs with LinkSys and dlink etc) deploying ipsec and sip-based apps: They = come mostly in two flavors, those who have an open attitude and those with a close-it-all attitude. In the first category, you will mostly expect = outgoing UDP and TCP to work, but normally no incoming at all. In the second = category, you should expect no outgoing UDP and TCP allowed expect those = explicitly allowed (and no, p2p is normally not allowed...) You may also see web = proxies and a full block, i.e. only outgoing and incoming goes through the web = proxy and no connections go through the firewall directly from the personal = computer. Finally, you may also see some deep packet inspection or even intrusion detection prevention (i.e. active dropping based on application-level = logic). Financial companies tend to be in this last category, but also others = ex. IPR-based companies, like engineering, oil&gas etc can be in this = category.

The close-it-all group is probably 5-10% of companies, but they tend to = be big, so in terms of employees the percentage is larger. I have no numbers though.  The tendency is towards closing down...
So, one cannot solve the NAT/firewall-traversal without having IT = department support. Thus, the solution should be something the IT guys find = non-obtrusive and easy to understand.  They understand UDP, they understand TCP, they = know how to create rules to open ports based on inside-triggers. The rest of = the acronyms in this thread is grouped under one word: scary, let's stop = it.
g-)

Adam Fisk wrote:

Hi = Brian-

=


I was told most firewalls, and especially enterprise firewalls did not = allow
arbitrary incoming UDP.  


That's true in my experience as well.
 

=

 

Some allow symmetric UDP with the outbound = traffic
first.  I know I can't run a SIP proxy behind my firewall at = home without
configuring the firewall to have a wide open port, and I know what = I'm
doing.  


That makes perfect sense as well. To run a SIP proxy, you need to have a = public address in normal SIP land, as I'm sure you know better than me.  = With p2p SIP, we'd ideally like to be able to do what you're talking about = without manually opening the port, although it's still not clear to me that's a requirement. 

=

 

I know I can't get incoming or outgoin UDP in = my office unless I
have a really good reason to ask the IT guys to open a = port.  YMMV I guess.


Any firewall not allowing outgoing UDP is pretty darn strict.  = You're completely sure they disallow outgoing?

=

 

I think reliable+congestion = control+fragmentation control+nat traversal UDP
=3D TCP+ICE.


I agree with that 100% except for the NAT traversal.  The = simplicity win of straight TCP+ICE =3D HUGE (win that is).  I've had trouble = getting the TCP traversal stuff to work reliably, though, and I know there are cases = where UDP traversal works where TCP doesn't.  If NAT traversal is a = requirement, I think you'd want to be super robust there and allow both TCP traversal = and UDP traversal using a reliable UDP layer. 

Maybe starting with only TCP traversal and just supporting ICE to allow = for future extensions would make sense?  I'd like to see more people = getting really solid results with the TCP traversal stuff before betting that = big on it though.  I could never get Saikat's stuff to work, and I tried it = with about 6 different NAT configurations.  I fully admit the problem = was probably on my end, and I could have stuck with it longer, but that was = my experience.  I also haven't tried their latest release, although it = sounds awesome.

-Adam

 

 

 

 
 
 






 
 
 
______________________________________________=
_
P2PSIP mailing =
list
P2PSIP@ietf.org
https://www1.ietf.=
org/mailman/listinfo/p2psip
 
------=_NextPart_000_0087_01C7B4BD.30060CF0-- --===============1026184484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1026184484==-- From p2psip-bounces@ietf.org Sat Jun 23 18:30:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2E78-0007eQ-Oz; Sat, 23 Jun 2007 18:29:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2E77-0007eL-64 for p2psip@ietf.org; Sat, 23 Jun 2007 18:29:53 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2E75-0005d6-VF for p2psip@ietf.org; Sat, 23 Jun 2007 18:29:53 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1I2E70-0007GJ-Io; Sat, 23 Jun 2007 17:29:46 -0500 Message-ID: <467D9FA2.4030404@softarmor.com> Date: Sat, 23 Jun 2007 17:33:06 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> In-Reply-To: <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'P2PSIP Mailing List' , 'Emil Ivov' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian Rosen wrote: > Huh. > > I must not understand firewalls and UDP. > > I was told most firewalls, and especially enterprise firewalls did not allow > arbitrary incoming UDP. Some allow symmetric UDP with the outbound traffic > first. I know I can't run a SIP proxy behind my firewall at home without > configuring the firewall to have a wide open port, and I know what I'm > doing. I know I can't get incoming or outgoin UDP in my office unless I > have a really good reason to ask the IT guys to open a port. YMMV I guess. > > Right. UDP hole-punching techniques do not, in general, work on enterprise firewalls, such as the one operated by the IT department of my most recent former employer. Said firewalls block all incoming UDP, except for certain allowed ports to certain allowed hosts (needed for DNS). On the other hand, Skype worked just fine from behind that same firewall. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jun 23 19:05:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Ef4-0001sZ-VG; Sat, 23 Jun 2007 19:04:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Ef3-0001sU-NX for p2psip@ietf.org; Sat, 23 Jun 2007 19:04:57 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2Ef2-0003vR-GV for p2psip@ietf.org; Sat, 23 Jun 2007 19:04:57 -0400 Received: from play.cs.columbia.edu (play.cs.columbia.edu [128.59.21.100]) (user=sa2086 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l5NN454T021182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Jun 2007 19:04:07 -0400 (EDT) Date: Sat, 23 Jun 2007 19:04:05 -0400 (EDT) From: Salman Abdul Baset To: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code In-Reply-To: <467D9FA2.4030404@softarmor.com> Message-ID: References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > Right. UDP hole-punching techniques do not, in general, work on > enterprise firewalls, such as the one operated by the IT department of > my most recent former employer. Said firewalls block all incoming UDP, > except for certain allowed ports to certain allowed hosts (needed for DNS). > > On the other hand, Skype worked just fine from behind that same firewall. Most likely it used TCP. > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jun 23 20:04:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Fad-0003Fr-EV; Sat, 23 Jun 2007 20:04:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2Fac-0003Fm-Ip for p2psip@ietf.org; Sat, 23 Jun 2007 20:04:26 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2Fab-00027i-5M for p2psip@ietf.org; Sat, 23 Jun 2007 20:04:26 -0400 Received: (qmail 29293 invoked for bounce); 24 Jun 2007 02:06:36 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 24 Jun 2007 02:06:36 -0000 Message-ID: <467DB508.6040108@sip-communicator.org> Date: Sun, 24 Jun 2007 02:04:24 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.0 (X11/20070601) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> In-Reply-To: <467D9FA2.4030404@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean Willis wrote: > Right. UDP hole-punching techniques do not, in general, work on > enterprise firewalls, such as the one operated by the IT department of > my most recent former employer. Said firewalls block all incoming UDP, > except for certain allowed ports to certain allowed hosts (needed for DNS). This probably means that the people administrating the firewall most likely did not want any media/voip traffic coming in and were explicitly blocking it. If this is really the case then I wonder whether we should be worried about it since the same people could very easily find ways to block media and voip even if they were transported by tcp. > On the other hand, Skype worked just fine from behind that same firewall. Are you certain that the reason for this was protocol related. Isn't it likely that this was either intentional or the firewall was not advanced enough and was not analyzing traffic any further beyond transport and port. In either case I doubt the phenomenon is something that TCP would always be a solution for. Cheers Emil > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 24 02:50:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2LvY-0002QW-97; Sun, 24 Jun 2007 02:50:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2LvX-0002QN-E5 for p2psip@ietf.org; Sun, 24 Jun 2007 02:50:27 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2LvU-0007Df-Ah for p2psip@ietf.org; Sun, 24 Jun 2007 02:50:27 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 0E9CBAC244F; Sun, 24 Jun 2007 14:50:20 +0800 (CST) Message-ID: <000a01c7b62b$eddd49e0$a507740a@DELLWEI> From: "Wei Gengyu" To: "Emil Ivov" References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com><467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Sun, 24 Jun 2007 14:50:15 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0878337856==" Errors-To: p2psip-bounces@ietf.org --===============0878337856== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpJZiB5b3UgdXNlIE1TIHdpbmRvd3MgeHAsIHlvdSBjYW4gc2VlIHlvdXIgd2lyZXdh bGwgY29uZmlndXJhdGlvbnMuIA0KVGhlIGFkbWluaXN0cmF0b3Igb2YgeW91ciBQQyBjYW4gbWFr ZSB3aGV0aGVyIHRvIGxldCBhbnkgdHJhZmZpYyBmbG93IGluLiANClRoZSBJVCBzdGFmZnMgY2Fu IGhhdmUgdGhlIGVudGVycHJpc2Ugd2lyZXdhbGxzIHdvcmsgaW4gdGhlIHNhbWUgd2F5Lg0KDQpI b3dldmVyLCBtb3N0IGVuZCB1c2VycyBkbyBub3Qga25vdyBvciBib3RoZXIgdG8gY2hhbmdlIHRo ZSBmaXJld2FsbCBjb25maWd1cmF0aW9ucy4NCkJ1dCBtb3N0IGVudGVycHJpc2UgSVQgc3RhZmZz IG9mdGVuIGNoZWNrIGFuZCBjaGFuZ2UgdGhhdCB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMgb2Yg dGhlaXIgY29tcGFueXMuDQoNCkluIGEgd29yZCwgcGVvcGxlIGNhbiBjb250cm9sIGZsb3dzIGF0 IGZpcmV3YWxsIGFjdGl2ZWx5LCBubyBtYXR0ZXIgd2hpY2ggcHJvdG9jb2xzIGFuZCBwb3J0cyB0 byBhZG9wdC4NCklmIHBlb3BsZSBsZXQgdGhlIGZpcmV3YWxsIGNvbmZpZ3VyYXRpb25zIGFzIGRl ZmF1bHQgdmFsdWVzLCBVRFAgaG9sZS1wdW5jaGluZyB0ZWNobmlxdWVzIGRvIHdvcmsgb2Z0ZW4u ICAgDQoNClJlZ2FyZHMsIA0KDQpHZW5neXUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSANCkZyb206ICJFbWlsIEl2b3YiIDxlbWNob0BzaXAtY29tbXVuaWNhdG9yLm9yZz4NClRvOiAi RGVhbiBXaWxsaXMiIDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPg0KQ2M6ICInUGhpbGlwIE1h dHRoZXdzJyIgPHBoaWxpcF9tYXR0aGV3c0BtYWdtYS5jYT47ICInUDJQU0lQIE1haWxpbmcgTGlz dCciIDxwMnBzaXBAaWV0Zi5vcmc+DQpTZW50OiBTdW5kYXksIEp1bmUgMjQsIDIwMDcgODowNCBB TQ0KU3ViamVjdDogUmU6IFtQMlBTSVBdIFBlZXIgcHJvdG9jb2wsIERIVCBhbmQgcnVubmluZyBj b2RlDQoNCg0KPiANCj4gDQo+IERlYW4gV2lsbGlzIHdyb3RlOg0KPj4gUmlnaHQuIFVEUCBob2xl LXB1bmNoaW5nIHRlY2huaXF1ZXMgZG8gbm90LCBpbiBnZW5lcmFsLCB3b3JrIG9uDQo+PiBlbnRl cnByaXNlIGZpcmV3YWxscywgc3VjaCBhcyB0aGUgb25lIG9wZXJhdGVkIGJ5IHRoZSBJVCBkZXBh cnRtZW50IG9mDQo+PiBteSBtb3N0IHJlY2VudCBmb3JtZXIgZW1wbG95ZXIuIFNhaWQgZmlyZXdh bGxzIGJsb2NrIGFsbCBpbmNvbWluZyBVRFAsDQo+PiBleGNlcHQgZm9yIGNlcnRhaW4gYWxsb3dl ZCBwb3J0cyB0byBjZXJ0YWluIGFsbG93ZWQgaG9zdHMgKG5lZWRlZCBmb3IgRE5TKS4NCj4gDQo+ IFRoaXMgcHJvYmFibHkgbWVhbnMgdGhhdCB0aGUgcGVvcGxlIGFkbWluaXN0cmF0aW5nIHRoZSBm aXJld2FsbCBtb3N0IA0KPiBsaWtlbHkgZGlkIG5vdCB3YW50IGFueSBtZWRpYS92b2lwIHRyYWZm aWMgY29taW5nIGluIGFuZCB3ZXJlIGV4cGxpY2l0bHkgDQo+IGJsb2NraW5nIGl0LiBJZiB0aGlz IGlzIHJlYWxseSB0aGUgY2FzZSB0aGVuIEkgd29uZGVyIHdoZXRoZXIgd2Ugc2hvdWxkIA0KPiBi ZSB3b3JyaWVkIGFib3V0IGl0IHNpbmNlIHRoZSBzYW1lIHBlb3BsZSBjb3VsZCB2ZXJ5IGVhc2ls eSBmaW5kIHdheXMgdG8gDQo+IGJsb2NrIG1lZGlhIGFuZCB2b2lwIGV2ZW4gaWYgdGhleSB3ZXJl IHRyYW5zcG9ydGVkIGJ5IHRjcC4NCj4gDQo+PiBPbiB0aGUgb3RoZXIgaGFuZCwgU2t5cGUgd29y a2VkIGp1c3QgZmluZSBmcm9tIGJlaGluZCB0aGF0IHNhbWUgZmlyZXdhbGwuDQo+IA0KPiBBcmUg eW91IGNlcnRhaW4gdGhhdCB0aGUgcmVhc29uIGZvciB0aGlzIHdhcyBwcm90b2NvbCByZWxhdGVk LiBJc24ndCBpdCANCj4gbGlrZWx5IHRoYXQgdGhpcyB3YXMgZWl0aGVyIGludGVudGlvbmFsIG9y IHRoZSBmaXJld2FsbCB3YXMgbm90IGFkdmFuY2VkIA0KPiBlbm91Z2ggYW5kIHdhcyBub3QgYW5h bHl6aW5nIHRyYWZmaWMgYW55IGZ1cnRoZXIgYmV5b25kIHRyYW5zcG9ydCBhbmQgDQo+IHBvcnQu IEluIGVpdGhlciBjYXNlIEkgZG91YnQgdGhlIHBoZW5vbWVub24gaXMgc29tZXRoaW5nIHRoYXQg VENQIHdvdWxkIA0KPiBhbHdheXMgYmUgYSBzb2x1dGlvbiBmb3IuDQo+IA0KPiBDaGVlcnMNCj4g RW1pbA0KPj4gDQo+PiAtLQ0KPj4gRGVhbg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPj4gUDJQ U0lQQGlldGYub3JnDQo+PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w MnBzaXANCj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPiBQMlBTSVBAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQo+ --===============0878337856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0878337856==-- From p2psip-bounces@ietf.org Sun Jun 24 18:46:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2aql-0005f1-85; Sun, 24 Jun 2007 18:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2aqk-0005ew-50 for p2psip@ietf.org; Sun, 24 Jun 2007 18:46:30 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2aqi-0001nn-Ls for p2psip@ietf.org; Sun, 24 Jun 2007 18:46:29 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Sun, 24 Jun 2007 15:46:21 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5OMkGWs024804; Sun, 24 Jun 2007 15:46:17 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5OMkF0c029467; Sun, 24 Jun 2007 15:46:15 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Jun 2007 15:46:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Sun, 24 Jun 2007 15:46:14 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D229E09E2@namail5.corp.adobe.com> In-Reply-To: <467A78A2.6060904@telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Peer protocol, DHT and running code Thread-Index: Ace0BTi9TQjyC6+IRmqM/py4xI5llgCrAssg References: <0E089E10-E740-4190-B4CD-1944AFEE49E3@magma.ca><04e301c7b37a$7fd1daf0$640fa8c0@cis.neustar.com> <467A78A2.6060904@telecomitalia.it> From: "Henry Sinnreich" To: "Enrico Marocco" , "Brian Rosen" X-OriginalArrivalTime: 24 Jun 2007 22:46:15.0037 (UTC) FILETIME=[787E7AD0:01C7B6B1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Emil Ivov , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I still think that, especially for highly unpredictable > decentralized systems as P2PSIP, running code is an extremely important > part. > I certainly hope I am not the only one left to believe this. Count me in as well and also add _measured performance_ on the network. Thanks, Henry -----Original Message----- From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it]=20 Sent: Thursday, June 21, 2007 3:10 PM To: Brian Rosen Cc: 'Emil Ivov'; 'Philip Matthews'; 'P2PSIP Mailing List' Subject: Re: [P2PSIP] Peer protocol, DHT and running code Brian Rosen wrote: > > David >=20 > It used to be that the IETF prided itself on "rough consensus and running > code". We've lost the "running code" part of our process, but in its place, > we have a lot of really good people who really look hard at the specs. Some real life examples -- to name but a few: Jabber, Bonjour and arguably HTTP1.0 -- would probably make some people argue that the "running code" part is essential for protocols to be successful, probably more important than specs. Obviously, I don't completely agree with such an argument, for if I did, I wouldn't be discussing any more, but I still think that, especially for highly unpredictable decentralized systems as P2PSIP, running code is an extremely important part. I certainly hope I am not the only one left to believe this. --=20 Ciao, Enrico _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 24 20:07:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2c6c-000617-L2; Sun, 24 Jun 2007 20:06:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2c6b-000612-Oy for p2psip@ietf.org; Sun, 24 Jun 2007 20:06:57 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2c6b-0000Ve-5o for p2psip@ietf.org; Sun, 24 Jun 2007 20:06:57 -0400 Received: from lappy ([70.6.26.74]) by quinthar.com for ; Sun, 24 Jun 2007 17:06:53 -0700 From: "David Barrett" To: "'Henry Sinnreich'" , "'Enrico Marocco'" , "'Brian Rosen'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Sun, 24 Jun 2007 17:06:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace0BTi9TQjyC6+IRmqM/py4xI5llgCrAssgAAIuB5A= In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D229E09E2@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Subject: RE: [P2PSIP] Peer protocol, DHT and running code > > > I still think that, especially for highly unpredictable > > decentralized systems as P2PSIP, running code is an extremely > important > > part. > > > I certainly hope I am not the only one left to believe this. > > Count me in as well and also add _measured performance_ on the network. So I think everyone would agree that running code is important. But where the rubber meets the road is when deciding what to do in the *absence* of running code. Personally, I believe the IETF should follow, not lead, the standardization process. So if there is no running code to measure and refine, then it's a sign that the IETF has gotten out ahead of the process. If this happens, rather than charging boldly ahead and designing in a vacuum, I think the priority should be on: 1) Document and instrument widely-deployed running code to be measurable 2) Help nascent running code grow to a point where it's widely-deployed. Right now it seems that ICE is in the (1) camp: code out there is widely deployed, but it's unclear exactly what it is, and it's not instrumented to generate the data we need (peer connectivity and connection setup latency). P2PSIP appears to be in the (2) camp: code is out there but it isn't used on a widespread basis and thus might not be really representative of the problem set it's designed to solve. In the latter case, we should ask ourselves "why aren't the current P2PSIP implementations being widely used, and what can we do to help?" In the former case, we should focus on "Who is behind these widespread implementations ICE (MSN, Google, etc) and can we have them share exactly what their doing and provide data on how well it works?" Regarding P2PSIP, at the very least, we could start "eating our own dogfood": we should get the code together in a central location, write all our drafts to be no more or less than what that code does, and then start using it. As we encounter real-world problems that prevent us from using it (the hardest one being "nobody I want to call is using it"), then we focus on solving *those* problems before any other. Regarding ICE, it seems that we could put together some sort of formal ambassador to approach these teams with a clear request for a specification of what they're doing and data on how well it works. We should understand what their concerns are about getting us that data (probably some engineering, intellectual property, and possibly privacy concerns), work to resolve those, and then base our standardization efforts on iterations of that. But if neither of these can be accomplished now, then I think a totally reasonable course of action is to simply wait until they can be. At least, I feel that's more reasonable than simply assuming measurable running code and real-world data aren't necessary to standardize these protocols. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jun 24 20:50:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2cn9-0001te-Lm; Sun, 24 Jun 2007 20:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2cn7-0001ns-LZ for p2psip@ietf.org; Sun, 24 Jun 2007 20:50:53 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2cn6-0007JT-Sh for p2psip@ietf.org; Sun, 24 Jun 2007 20:50:53 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sun, 24 Jun 2007 17:50:49 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5P0ncot014566; Sun, 24 Jun 2007 17:49:38 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5P0oe0c002406; Sun, 24 Jun 2007 17:50:41 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Jun 2007 17:50:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Sun, 24 Jun 2007 17:50:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D229E09F2@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Peer protocol, DHT and running code Thread-Index: Ace0BTi9TQjyC6+IRmqM/py4xI5llgCrAssgAAIuB5AAAfmHsA== References: <24CCCC428EFEA2469BF046DB3C7A8D229E09E2@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "David Barrett" , "Enrico Marocco" , "Brian Rosen" X-OriginalArrivalTime: 25 Jun 2007 00:50:40.0142 (UTC) FILETIME=[DA0B1AE0:01C7B6C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: Emil Ivov , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David, > But where the rubber meets the road is when deciding what to do in the > *absence* of running code. There is an abundance of running code and performance measurements for most DHTs, see for example openDHT.org, Chord, etc. What we don't have now is open source code for recent ICE specs (as far as I know) and most of all, measurements with ICE, even for CS SIP systems.=20 This has been mentioned by others on this list and makes me uneasy as well. IMHO standards that are not backed up by OS code may fail in spectacular ways. We don't need to mention here some examples :-) Thanks, Henry -----Original Message----- From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Monday, June 25, 2007 2:07 AM To: Henry Sinnreich; 'Enrico Marocco'; 'Brian Rosen' Cc: 'Emil Ivov'; 'Philip Matthews'; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] Peer protocol, DHT and running code > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Subject: RE: [P2PSIP] Peer protocol, DHT and running code >=20 > > I still think that, especially for highly unpredictable > > decentralized systems as P2PSIP, running code is an extremely > important > > part. >=20 > > I certainly hope I am not the only one left to believe this. >=20 > Count me in as well and also add _measured performance_ on the network. So I think everyone would agree that running code is important. But where the rubber meets the road is when deciding what to do in the *absence* of running code. Personally, I believe the IETF should follow, not lead, the standardization process. So if there is no running code to measure and refine, then it's a sign that the IETF has gotten out ahead of the process. If this happens, rather than charging boldly ahead and designing in a vacuum, I think the priority should be on: 1) Document and instrument widely-deployed running code to be measurable 2) Help nascent running code grow to a point where it's widely-deployed. Right now it seems that ICE is in the (1) camp: code out there is widely deployed, but it's unclear exactly what it is, and it's not instrumented to generate the data we need (peer connectivity and connection setup latency). P2PSIP appears to be in the (2) camp: code is out there but it isn't used on a widespread basis and thus might not be really representative of the problem set it's designed to solve. In the latter case, we should ask ourselves "why aren't the current P2PSIP implementations being widely used, and what can we do to help?" In the former case, we should focus on "Who is behind these widespread implementations ICE (MSN, Google, etc) and can we have them share exactly what their doing and provide data on how well it works?" Regarding P2PSIP, at the very least, we could start "eating our own dogfood": we should get the code together in a central location, write all our drafts to be no more or less than what that code does, and then start using it. As we encounter real-world problems that prevent us from using it (the hardest one being "nobody I want to call is using it"), then we focus on solving *those* problems before any other. Regarding ICE, it seems that we could put together some sort of formal ambassador to approach these teams with a clear request for a specification of what they're doing and data on how well it works. We should understand what their concerns are about getting us that data (probably some engineering, intellectual property, and possibly privacy concerns), work to resolve those, and then base our standardization efforts on iterations of that. But if neither of these can be accomplished now, then I think a totally reasonable course of action is to simply wait until they can be. At least, I feel that's more reasonable than simply assuming measurable running code and real-world data aren't necessary to standardize these protocols. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 01:33:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2hCd-00058d-CX; Mon, 25 Jun 2007 01:33:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2hCb-00058V-8A for p2psip@ietf.org; Mon, 25 Jun 2007 01:33:29 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2hCZ-0000sb-Q3 for p2psip@ietf.org; Mon, 25 Jun 2007 01:33:29 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Sun, 24 Jun 2007 22:33:15 -0700 From: "David Barrett" To: "'Henry Sinnreich'" , "'Enrico Marocco'" , "'Brian Rosen'" Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Sun, 24 Jun 2007 22:33:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Ace0BTi9TQjyC6+IRmqM/py4xI5llgCrAssgAAIuB5AAAfmHsAAJy0Qw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D229E09F2@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Emil Ivov' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Subject: RE: [P2PSIP] Peer protocol, DHT and running code > > David, > > > But where the rubber meets the road is when deciding what to do in the > > > *absence* of running code. > > There is an abundance of running code and performance measurements for > most DHTs, see for example openDHT.org, Chord, etc. > > What we don't have now is open source code for recent ICE specs (as far > as I know) and most of all, measurements with ICE, even for CS SIP > systems. > This has been mentioned by others on this list and makes me uneasy as > well. > > IMHO standards that are not backed up by OS code may fail in spectacular > ways. We don't need to mention here some examples :-) Heh, totally agree. I guess what I'd like us to do is choose our top use case and build/adopt an application for real-world use and testing. For example, I'd like to see "OpenSkype". Some complete, end-to-end implementation of P2PSIP, ICE, and STUN that demonstrates the combination does in fact produce effective results. Then, we can measure the hell of that thing and figure out where it's good and bad. And once it's been proven to be "good enough" in one area (ie, meeting the base requirements for a given use case), then we can discuss how to extend that to cover the next-highest-priority use case, and so on down the list. In this way we focus our energy on quantifying and solving real-world problems that affect actual users, reducing distractions and maximizing the use of our limited resources. Does anyone agree with this plan? Anybody know of a good OpenSkype to adopt? Or, if we can't do this plan, what an alternative plan? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 05:15:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kfd-0005l4-GF; Mon, 25 Jun 2007 05:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2kfc-0005kz-6v for p2psip@ietf.org; Mon, 25 Jun 2007 05:15:40 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2kfX-00082P-HN for p2psip@ietf.org; Mon, 25 Jun 2007 05:15:40 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5P8tIQp032414; Mon, 25 Jun 2007 10:55:18 +0200 Message-ID: <467F87A6.1070100@teigre.com> Date: Mon, 25 Jun 2007 11:15:18 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: In-Reply-To: X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: 'P2PSIP Mailing List' , 'Emil Ivov' , 'Henry Sinnreich' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1137531363==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1137531363== Content-Type: multipart/alternative; boundary="------------000100010909030204090901" This is a multi-part message in MIME format. --------------000100010909030204090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I share the concerns on the absence of running open-source code. In my understanding, there is (mostly) code for various pieces, but we are struggling in finding example systems (preferably open-source) that cover everything we want to cover. The risk is thus to over-engineer (design by committee) instead of standardizing based on experience about what works. IMHO, this has a lot to do with design-choices: If we strive to logically separate the various components from each other, we are in a better position to choose what is known to work, as well as more directly rely on other working groups' work (I think this point has been made earlier, but it is worth bringing up again). However, if we try to mix all functions together in a new P2PSIP protocol (stack?), we will struggle to adapt and integrate, and we have no running code we really can rely on, because measurements are no longer valid. Unless this working group points in a direction where the existing implementors of SIP-based p2p quickly can amend/change their implementation, I think we will go astray. g-) David Barrett wrote: >> -----Original Message----- >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Subject: RE: [P2PSIP] Peer protocol, DHT and running code >> >> David, >> >> >>> But where the rubber meets the road is when deciding what to do in the >>> >>> *absence* of running code. >>> >> There is an abundance of running code and performance measurements for >> most DHTs, see for example openDHT.org, Chord, etc. >> >> What we don't have now is open source code for recent ICE specs (as far >> as I know) and most of all, measurements with ICE, even for CS SIP >> systems. >> This has been mentioned by others on this list and makes me uneasy as >> well. >> >> IMHO standards that are not backed up by OS code may fail in spectacular >> ways. We don't need to mention here some examples :-) >> > > Heh, totally agree. > > I guess what I'd like us to do is choose our top use case and build/adopt an > application for real-world use and testing. For example, I'd like to see > "OpenSkype". Some complete, end-to-end implementation of P2PSIP, ICE, and > STUN that demonstrates the combination does in fact produce effective > results. > > Then, we can measure the hell of that thing and figure out where it's good > and bad. And once it's been proven to be "good enough" in one area (ie, > meeting the base requirements for a given use case), then we can discuss how > to extend that to cover the next-highest-priority use case, and so on down > the list. > > In this way we focus our energy on quantifying and solving real-world > problems that affect actual users, reducing distractions and maximizing the > use of our limited resources. > > Does anyone agree with this plan? Anybody know of a good OpenSkype to > adopt? > > Or, if we can't do this plan, what an alternative plan? > > -david > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > --------------000100010909030204090901 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I share the concerns on the absence of running open-source code. In my understanding, there is (mostly) code for various pieces, but we are struggling in finding example systems (preferably open-source) that cover everything we want to cover.  The risk is thus to over-engineer (design by committee) instead of standardizing based on experience about what works.

IMHO, this has a lot to do with design-choices: If we strive to logically separate the various components from each other, we are in a better position to choose what is known to work, as well as more directly rely on other working groups' work (I think this point has been made earlier, but it is worth bringing up again). However, if we try to mix all functions together in a new P2PSIP protocol (stack?), we will struggle to adapt and integrate, and we have no running code we really can rely on, because measurements are no longer valid.

Unless this working group points in a direction where the existing implementors of SIP-based p2p quickly can amend/change their implementation, I think we will go astray.
g-)

David Barrett wrote: 
-----Original Message-----
From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Subject: RE: [P2PSIP] Peer protocol, DHT and running code

David,

    
But where the rubber meets the road is when deciding what to do in the
      
*absence* of running code.
      
There is an abundance of running code and performance measurements for
most DHTs, see for example openDHT.org, Chord, etc.

What we don't have now is open source code for recent ICE specs (as far
as I know) and most of all, measurements with ICE, even for CS SIP
systems.
This has been mentioned by others on this list and makes me uneasy as
well.

IMHO standards that are not backed up by OS code may fail in spectacular
ways. We don't need to mention here some examples :-)
    

Heh, totally agree.

I guess what I'd like us to do is choose our top use case and build/adopt an
application for real-world use and testing.  For example, I'd like to see
"OpenSkype".  Some complete, end-to-end implementation of P2PSIP, ICE, and
STUN that demonstrates the combination does in fact produce effective
results.

Then, we can measure the hell of that thing and figure out where it's good
and bad.  And once it's been proven to be "good enough" in one area (ie,
meeting the base requirements for a given use case), then we can discuss how
to extend that to cover the next-highest-priority use case, and so on down
the list.

In this way we focus our energy on quantifying and solving real-world
problems that affect actual users, reducing distractions and maximizing the
use of our limited resources.

Does anyone agree with this plan?  Anybody know of a good OpenSkype to
adopt?

Or, if we can't do this plan, what an alternative plan?

-david



_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--------------000100010909030204090901-- --===============1137531363== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1137531363==-- From p2psip-bounces@ietf.org Mon Jun 25 06:06:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2lSX-0004sy-I4; Mon, 25 Jun 2007 06:06:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2lSU-0004rU-DR for p2psip@ietf.org; Mon, 25 Jun 2007 06:06:10 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2lMr-00040x-Dz for p2psip@ietf.org; Mon, 25 Jun 2007 06:00:21 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5P9e53w001901 for ; Mon, 25 Jun 2007 11:40:06 +0200 Message-ID: <467F9225.3020000@teigre.com> Date: Mon, 25 Jun 2007 12:00:05 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: P2PSIP Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [P2PSIP] Trying to grasp what we really are standardizing... X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org It seems to me (based on the drafts) that this working group has set out to standardize too much. However, I may be unable to see the big picture after reading the drafts... I'm trying to use a (simplistic) layered approach, please help me sort out my confusions... The logical starting point for me is the pure SIP UA (already out there). It will (hopefully) support sip-outbound and ice. It will thus expect to find a registrar, as well as a STUN and a STUN relay function. Using these mechanisms, the UA will happily REGISTER with the assigned registrar, establish the necessary sip-outbound flows and will negotiate using ice when setting up a dialog. For simplicity, let's say the registrar happens to be a P2PSIP peer physically residing on another device. This peer should have a SIP implementation, as well as a p2p implementation. This peer should be able to act as a registrar for the SIP UA, including ping-pongs, do routing, and offer STUN relay addresses when an INVITE goes through (contrary example, draft-marocco-p2psip-interwork-01 seems to indicate some p2psip-aware code in the SIP UA). In my mind, the P2P layer should offer the SIP-part of the peer an API where messages can be routed and relay function data retrieved, (draft-baset-p2psip-p2pcommon-01 seems to be closest, but concerns a protocol on the wire) however, implementing the API in the SIP code should be a fairly simple one-to-one mapping. The API should be standardized in this working group, so that any SIP implementor having implemented the P2PSIP API can plug in a new p2p implementation (or support several). These implementations could be different overlays or different libraries implementing the same overlays. Hopefully, all the various available p2p implementations will implement this API, thus ensuring that SIP UA implementations quickly will become p2p aware. So far so good, NAT has been handled on the SIP layer for both signaling and media, and the only thing we need is an implementation of the P2PSIP API that realizes the API functions... However, now I start to get a bit confused. We want to standardize to ensure interoperability. Well, with a well-designed P2PSIP API, we have come pretty far, I think. We have interoperability using all the SIP mechanisms, including 3263. SIP messages can flow across overlays on the SIP layer. So, what more do we want to ensure? That various implementations on the p2p layer can talk to each other? Why do we want that? Won't we just freeze innovation because we are not able to create a protocol between the peers that is agnostic to hash tables etc? I know the charter says we should standardize the protocol between the peers, but I feel that SIP and p2p is mixed together too much and I just don't get it. Ok, so people want interoperability between p2p peers, but I don't really see how we can avoid spending a lot of resources on just creating a default that probably quickly will be outdated?! (we're not standardizing a best practice that has emerged already) And I don't really see what we gain (unless the ambition is to create a world-wide p2p network where also non-SIP can be transported...). So, based on my lack of understanding of the above, pardon my lack of understanding on some other issues: - How NAT is handled on the p2p layer should have nothing to do with the SIP layer. One should be free to make any decision, right? - Whether to use SIP, binary, or some text-based protocol (if to be standardized) should really be based on facts: what works most efficiently from a *protocol standpoint*? Let's not get confused by the fact that SIP will be transported on top of the p2p protocol. - Choosing of transport-layer protocols: again, ignore SIP, what works? Of course, as both the SIP and p2p layers must solve NAT traversal, it is easy to mix them together and yes, I'm open to the possibility of collapsing the layers for optimization reasons. But I don't think we are there yet. And I also think that through some separation, the p2p guys (I'm not one of them) and the SIP guys can concentrate on what they are good at. If we mix, only people who are experts on both can a) implement b) have an opinion. Please,attack my arguments. g-) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 06:38:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2lxK-000813-Fd; Mon, 25 Jun 2007 06:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2lxJ-0007zL-9W for p2psip@ietf.org; Mon, 25 Jun 2007 06:38:01 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2lxH-0002xi-8f for p2psip@ietf.org; Mon, 25 Jun 2007 06:38:01 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 12:37:56 +0200 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 12:37:55 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 12:37:54 +0200 Message-ID: <467F9B82.4000906@telecomitalia.it> Date: Mon, 25 Jun 2007 12:40:02 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070618) MIME-Version: 1.0 To: "Greger V. Teigre" Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... References: <467F9225.3020000@teigre.com> In-Reply-To: <467F9225.3020000@teigre.com> X-OriginalArrivalTime: 25 Jun 2007 10:37:54.0846 (UTC) FILETIME=[E39043E0:01C7B714] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0957106035==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0957106035== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040007050800050809030406" This is a cryptographically signed message in MIME format. --------------ms040007050800050809030406 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greger V. Teigre wrote: > For simplicity, let's say the registrar happens to be a P2PSIP peer > physically residing on another device. This peer should have a SIP > implementation, as well as a p2p implementation. This peer should be > able to act as a registrar for the SIP UA, including ping-pongs, do > routing, and offer STUN relay addresses when an INVITE goes through > (contrary example, draft-marocco-p2psip-interwork-01 seems to indicate > some p2psip-aware code in the SIP UA). Actually, open issue #3 in the draft acknowledges that sometimes such a discovery must be done by peers on behalf of non p2p-aware UAs. What we wanted to stress is the fact that only some peers (proxy peers in the draft) can effectively do 3263 routing; in certain scenarios, nodes with limited connectivity can still become peers (it depends on the overlay algorithm), but cannot send messages to nodes on the Internet. We'll make it clearer in the next version. -- Ciao, Enrico --------------ms040007050800050809030406 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNjI1MTA0MDAyWjAjBgkqhkiG9w0BCQQxFgQUjKTaofjX qwMR82PmDw7FnGrnrygwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAAZdaShX5o3MlCLyrtLSlc+yGtBj9I9rykdq+NyrvJEqdgJ52FNPSV4t gyUVvSKfN9f1oSf0I3N0fG6lM41dD93t/d2nlKEViDhRWKPVG6jSyuSCEUJ73IDLXyqsuh+v H3XofAcjhFpY1yqGq/zE3vUUwUFwUrr++4HYTr7r8iMPX2zIL2H5UPRHlYrHaQjLLZF5DBuT QR3nQkQSbJ+DU5eGROCgQb/wn9YG6Lqz5jSRJy8uueKQJCgNT7cZT3aUhMMpSyuHnCH/RMJc 7D3LJUwvqvdjVAxM45Fp8LvPkRUpK7S3BHN4Nz8g3CGnzT0oGva+r6d0eGsh9kXmLMcLdO4A AAAAAAA= --------------ms040007050800050809030406-- --===============0957106035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0957106035==-- From p2psip-bounces@ietf.org Mon Jun 25 07:47:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n2I-0002nL-I6; Mon, 25 Jun 2007 07:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2n2H-0002nG-AE for p2psip@ietf.org; Mon, 25 Jun 2007 07:47:13 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2n2H-0005Bw-0c for p2psip@ietf.org; Mon, 25 Jun 2007 07:47:13 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2n2E-0004RH-2E; Mon, 25 Jun 2007 07:47:10 -0400 In-Reply-To: <467DB508.6040108@sip-communicator.org> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C9E737E-7091-4B54-A757-29EF763C5F56@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Mon, 25 Jun 2007 07:47:17 -0400 To: Emil Ivov X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Emil. - Philip On 23-Jun-07, at 20:04 , Emil Ivov wrote: > > > Dean Willis wrote: >> Right. UDP hole-punching techniques do not, in general, work on >> enterprise firewalls, such as the one operated by the IT >> department of >> my most recent former employer. Said firewalls block all incoming >> UDP, >> except for certain allowed ports to certain allowed hosts (needed >> for DNS). > > This probably means that the people administrating the firewall > most likely did not want any media/voip traffic coming in and were > explicitly blocking it. If this is really the case then I wonder > whether we should be worried about it since the same people could > very easily find ways to block media and voip even if they were > transported by tcp. > >> On the other hand, Skype worked just fine from behind that same >> firewall. > > Are you certain that the reason for this was protocol related. > Isn't it likely that this was either intentional or the firewall > was not advanced enough and was not analyzing traffic any further > beyond transport and port. In either case I doubt the phenomenon is > something that TCP would always be a solution for. > > Cheers > Emil >> -- >> Dean >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 09:06:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oHD-0002Sr-A6; Mon, 25 Jun 2007 09:06:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oHB-0002SQ-G0 for p2psip@ietf.org; Mon, 25 Jun 2007 09:06:41 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2oH9-0007IY-77 for p2psip@ietf.org; Mon, 25 Jun 2007 09:06:41 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1I2oHH-0004Sv-Di; Mon, 25 Jun 2007 09:06:47 -0400 In-Reply-To: <467F9225.3020000@teigre.com> References: <467F9225.3020000@teigre.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... Date: Mon, 25 Jun 2007 09:06:45 -0400 To: Greger V. Teigre X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 25-Jun-07, at 06:00 , Greger V. Teigre wrote: > So, based on my lack of understanding of the above, pardon my lack > of understanding on some other issues: > - How NAT is handled on the p2p layer should have nothing to do > with the SIP layer. One should be free to make any decision, right? It seems to me that you are talking about a P2P layer architecture like the one described in draft-matthews-p2psip-hip-hop-00 which talks about a P2P layer that sits below the SIP layer and provides three main functions: 1) Distributed Database 2) Overlay Maintenance 3) Distributed Transport (e.g., routing messages around the overlay) Is this correct? With the architecture above, I don't see how you can handle NAT traversal at the SIP layer for SIP signaling. The only proposal that I have seen that handles NAT traversal at the SIP layer for SIP signaling is dSIP, and dSIP does not have a separate P2P layer but does everything in SIP. If you are going to separate the P2P layer from the SIP layer, then I think you are pretty much forced to put NAT traversal logic in the P2P layer for both P2P messages and for SIP signaling. The only thing you could leave up at the SIP layer is NAT traversal for RTP packets. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 10:02:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2p8z-0007gW-Oy; Mon, 25 Jun 2007 10:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2p8y-0007gN-S7 for p2psip@ietf.org; Mon, 25 Jun 2007 10:02:16 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2p8w-0002W0-DY for p2psip@ietf.org; Mon, 25 Jun 2007 10:02:16 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5PDg7LU015099; Mon, 25 Jun 2007 15:42:07 +0200 Message-ID: <467FCAE0.3070506@teigre.com> Date: Mon, 25 Jun 2007 16:02:08 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... References: <467F9225.3020000@teigre.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip Matthews wrote: > > On 25-Jun-07, at 06:00 , Greger V. Teigre wrote: >> So, based on my lack of understanding of the above, pardon my lack of >> understanding on some other issues: >> - How NAT is handled on the p2p layer should have nothing to do with >> the SIP layer. One should be free to make any decision, right? > > It seems to me that you are talking about a P2P layer architecture > like the one described in > draft-matthews-p2psip-hip-hop-00 > which talks about a P2P layer that sits below the SIP layer and > provides three main functions: > 1) Distributed Database > 2) Overlay Maintenance > 3) Distributed Transport (e.g., routing messages around the overlay) > Is this correct? Well, I didn't really take a position on the actual layering, I was just trying to look at the functions that must be presented to the pure SIP UA. Unless I'm completely mistaken, a pure SIP UA should be able to contact a SIP UA using the p2p overlay in a completely transparent fashion. Those two UAs, one registered with a SIP registrar (c/s), the other in a p2p overlay should be able to use ice to set up the dialog. If a relay is needed, it really doesn't matter if a server in the c/s domain offers the relay or if the p2p overlay offers the relay as a service (or maybe both and the best is chosen). I would think that a pure SIP UA maybe could establish sip-outbound flows both to a SIP registrar (c/s) and to a peer in the overlay (acting as a registrar). This could enable emergency/disaster redundancy or even be useful for service providers. > With the architecture above, I don't see how you can handle NAT > traversal at the SIP layer for SIP signaling. The only proposal that I > have seen that handles NAT traversal at the SIP layer for SIP > signaling is dSIP, and dSIP does not have a separate P2P layer but > does everything in SIP. If you are going to separate the P2P layer > from the SIP layer, then I think you are pretty much forced to put NAT > traversal logic in the P2P layer for both P2P messages and for SIP > signaling. The only thing you could leave up at the SIP layer is NAT > traversal for RTP packets. My point is that NAT-traversal for SIP and NAT-traversal on the P2P layer really is logically two separate things, and they should be analyzed separately. It may well be that the underlying p2p layer can offer the SIP layer a non-NATed routing environment (indeed, it is probably desirable), but in theory the p2p layer can tackle it's own signaling NAT traversal without offering the SIP layer a non-NATed routing environment (leaving private IP addresses in SIP messages). g-) > > > > - Philip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 10:11:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pHz-0007B7-Nm; Mon, 25 Jun 2007 10:11:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pHx-0007B2-RA for p2psip@ietf.org; Mon, 25 Jun 2007 10:11:33 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2pHx-0004ui-Es for p2psip@ietf.org; Mon, 25 Jun 2007 10:11:33 -0400 Received: by an-out-0708.google.com with SMTP id c17so341089anc for ; Mon, 25 Jun 2007 07:11:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=r68IoxJK+rI7jdcj1hHj/yrKxbS5/xLmFBAuvZnR2bc5WSeaJP1VjTECJn9CuLO1pYBbKUVZmpuHWNhUPjKr6wlX31Cd7GpMWItaHguYaor1AKwYfRyiU0x0RgqdWmWRpmr0DVNlHucgV2E+WBFrmOP5vktKxPvI9UIP7QNOOBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=BtI+20xuinbGIQy/RwmUmBMt0lSZabaBEhxu5ls33okswC/PQjsCsJelJHrsYw3nqMlJLrgdN72YQt14ZU93IfDWzumX9URf5WrdP/SFf+agGRZLO/BGdbl6dsQ28dLZz7BmkBfeE7aW9FRiWA4cU+WhcgbrKyIGQ3kC1aEe+mk= Received: by 10.100.33.14 with SMTP id g14mr3175610ang.1182780690499; Mon, 25 Jun 2007 07:11:30 -0700 (PDT) Received: by 10.100.106.1 with HTTP; Mon, 25 Jun 2007 07:11:30 -0700 (PDT) Message-ID: <20d2bdfb0706250711t1c67195u379e3b15e12f8d62@mail.gmail.com> Date: Mon, 25 Jun 2007 10:11:30 -0400 From: "Bruce Lowekamp" To: "Greger V. Teigre" Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... In-Reply-To: <467FCAE0.3070506@teigre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <467F9225.3020000@teigre.com> <467FCAE0.3070506@teigre.com> X-Google-Sender-Auth: 27bcfc8d06647c44 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Greger, For your example, where you have a "pure SIP" UA contacting a fixed location registrar that happens to be backed by a P2PSIP overlay, I think you're right that you can regard the NAT traversal problems as distinct. But I think this comes out of the assumption that the registrar has an unfiltered public IP address such as any conventional registrar would have. This is one use case for P2PSIP, looking at Section 3 of p2psip-concepts, you assume that the world consists of SIP UAs (behind NATs) and Proxy Peers (not behind NATs). But for other use cases, such as with the UA Peers that are behind NATs, you can't make the assumption that SIP outbound NAT traversal will work. There is no registrar or proxy to contact. In this case, the overlay is providing connectivity between the peers, and it makes sense (to me) to use the overlay in some fashion to establish SIP sessions between different UA peers. At this point we've seen several proposals for how to accomplish this, but there's a fairly common thread that the overlay already has a means of performing NAT traversal that the SIP messages leverage. Bruce On 6/25/07, Greger V. Teigre wrote: > > > Philip Matthews wrote: > > > > On 25-Jun-07, at 06:00 , Greger V. Teigre wrote: > >> So, based on my lack of understanding of the above, pardon my lack of > >> understanding on some other issues: > >> - How NAT is handled on the p2p layer should have nothing to do with > >> the SIP layer. One should be free to make any decision, right? > > > > It seems to me that you are talking about a P2P layer architecture > > like the one described in > > draft-matthews-p2psip-hip-hop-00 > > which talks about a P2P layer that sits below the SIP layer and > > provides three main functions: > > 1) Distributed Database > > 2) Overlay Maintenance > > 3) Distributed Transport (e.g., routing messages around the overlay) > > Is this correct? > Well, I didn't really take a position on the actual layering, I was just > trying to look at the functions that must be presented to the pure SIP > UA. Unless I'm completely mistaken, a pure SIP UA should be able to > contact a SIP UA using the p2p overlay in a completely transparent > fashion. Those two UAs, one registered with a SIP registrar (c/s), the > other in a p2p overlay should be able to use ice to set up the dialog. > If a relay is needed, it really doesn't matter if a server in the c/s > domain offers the relay or if the p2p overlay offers the relay as a > service (or maybe both and the best is chosen). > > I would think that a pure SIP UA maybe could establish sip-outbound > flows both to a SIP registrar (c/s) and to a peer in the overlay (acting > as a registrar). This could enable emergency/disaster redundancy or even > be useful for service providers. > > With the architecture above, I don't see how you can handle NAT > > traversal at the SIP layer for SIP signaling. The only proposal that I > > have seen that handles NAT traversal at the SIP layer for SIP > > signaling is dSIP, and dSIP does not have a separate P2P layer but > > does everything in SIP. If you are going to separate the P2P layer > > from the SIP layer, then I think you are pretty much forced to put NAT > > traversal logic in the P2P layer for both P2P messages and for SIP > > signaling. The only thing you could leave up at the SIP layer is NAT > > traversal for RTP packets. > My point is that NAT-traversal for SIP and NAT-traversal on the P2P > layer really is logically two separate things, and they should be > analyzed separately. It may well be that the underlying p2p layer can > offer the SIP layer a non-NATed routing environment (indeed, it is > probably desirable), but in theory the p2p layer can tackle it's own > signaling NAT traversal without offering the SIP layer a non-NATed > routing environment (leaving private IP addresses in SIP messages). > g-) > > > > > > > > - Philip > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 10:23:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pT2-00075w-GY; Mon, 25 Jun 2007 10:23:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2pT0-00075U-Bq for p2psip@ietf.org; Mon, 25 Jun 2007 10:22:58 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I2pSr-0004Fs-2H for p2psip@ietf.org; Mon, 25 Jun 2007 10:22:58 -0400 Received: by py-out-1112.google.com with SMTP id f31so3438121pyh for ; Mon, 25 Jun 2007 07:22:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=LE6Yp4yNg6fBIXf4LjPhx//Ik1DzUBUjz1sG+0B9Zylbx+MX2NJ5RjQllwn3VB2Fxsv0tYxgHEXdUbPRIOu6+JOb1tru9zw2lpvDH7hmUXiAm5jF8HjElZNrjam1/omqUwvInpwrq9Iieadl9YmjRg5gydzAG0VGN02yYEvp/10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=QwBs+DBOYe198rKyXZURNUYA3BywxGmrccUyy/oSEq30fncQsnyNRSB3kJlm/mTBfhsMIfBuiSn0qyKSKE9Cl+CSR+LRTjHtJiwnfVQsHrMNL0oxbLM8r5s1oWiPUYzsDgKFXl2Ivx8NTogpgQtxI/Hp+DkOFhi+6ZgrdBMainI= Received: by 10.65.250.11 with SMTP id c11mr9253058qbs.1182781366839; Mon, 25 Jun 2007 07:22:46 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Mon, 25 Jun 2007 07:22:46 -0700 (PDT) Message-ID: <4d4304a00706250722s66d9e889o20d13461ac00dbbf@mail.gmail.com> Date: Mon, 25 Jun 2007 10:22:46 -0400 From: "David A. Bryan" To: "Greger V. Teigre" Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... In-Reply-To: <467FCAE0.3070506@teigre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <467F9225.3020000@teigre.com> <467FCAE0.3070506@teigre.com> X-Google-Sender-Auth: 6b9fcca424838774 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think there are several ways the NAT functions can be handled, just a few I have seen proposed are: * P2P layer == SIP layer, both use SIP functions to traverse NATs * P2P layer does its own NAT traversal, and is used to either negotiate openings or encapsulates the SIP layer traffic * SIP layer does the NAT traversal, and session and NAT traversal of the P2P is negotiated there (perhaps it is listed as an SDP stream) * The two layers are completely independent Also people have discussed if ICE is appropriate for the P2P protocol negotiation, assuming it is not SIP (no one is seriously (at least I hope not) proposing inventing something other than ICE for the NAT traversal on the SIP side...) I agree that we should probably analyze the two NAT traversal mechanisms seperately, but I personally think we will find ICE is the answer in each case, and I really don't like the idea of having to implement two different NAT traversal techniques and do NAT traversal two times for the two protocols. This group is about making a protocol for P2P *specifically* for SIP, we don't need to go out our way to make it function in other cases, so I think reuse of ICE makes the most sense. There may be an IETF group to do more generic P2P someday (I hope so), and hopefully it will grow from our work, but this group is sort of a baby-step that direction for the IETF -- try to see if a group can make a P2P protocol work in a narrow problem space like P2P specifically for SIP -- before deciding about more general P2P protocols. As far as why we are talking about standardizing the DHT between peers, I'll give you my take. The IETF goal is to allow implementations from different vendors to work together interchangably. The IETF doesn't define code APIs, they standardize the protocols that go over the wire. It isn't about an API that every SIP UA can implement to call a P2P library, it is about different P2P devices from different vendors, scattered across the internet or within an organization being able work together to form a serverless environment. To think similarly, we aren't saying "here is a set of code hooks a web browser can use, and underneath developers can write a library to access "their" proprietery web". Instead, we are making sure that all the P2PSIP devices across the internet, regardless of vendor, can be interchangably connected into a P2P overlay and work together. David On 6/25/07, Greger V. Teigre wrote: > > > Philip Matthews wrote: > > > > On 25-Jun-07, at 06:00 , Greger V. Teigre wrote: > >> So, based on my lack of understanding of the above, pardon my lack of > >> understanding on some other issues: > >> - How NAT is handled on the p2p layer should have nothing to do with > >> the SIP layer. One should be free to make any decision, right? > > > > It seems to me that you are talking about a P2P layer architecture > > like the one described in > > draft-matthews-p2psip-hip-hop-00 > > which talks about a P2P layer that sits below the SIP layer and > > provides three main functions: > > 1) Distributed Database > > 2) Overlay Maintenance > > 3) Distributed Transport (e.g., routing messages around the overlay) > > Is this correct? > Well, I didn't really take a position on the actual layering, I was just > trying to look at the functions that must be presented to the pure SIP > UA. Unless I'm completely mistaken, a pure SIP UA should be able to > contact a SIP UA using the p2p overlay in a completely transparent > fashion. Those two UAs, one registered with a SIP registrar (c/s), the > other in a p2p overlay should be able to use ice to set up the dialog. > If a relay is needed, it really doesn't matter if a server in the c/s > domain offers the relay or if the p2p overlay offers the relay as a > service (or maybe both and the best is chosen). > > I would think that a pure SIP UA maybe could establish sip-outbound > flows both to a SIP registrar (c/s) and to a peer in the overlay (acting > as a registrar). This could enable emergency/disaster redundancy or even > be useful for service providers. > > With the architecture above, I don't see how you can handle NAT > > traversal at the SIP layer for SIP signaling. The only proposal that I > > have seen that handles NAT traversal at the SIP layer for SIP > > signaling is dSIP, and dSIP does not have a separate P2P layer but > > does everything in SIP. If you are going to separate the P2P layer > > from the SIP layer, then I think you are pretty much forced to put NAT > > traversal logic in the P2P layer for both P2P messages and for SIP > > signaling. The only thing you could leave up at the SIP layer is NAT > > traversal for RTP packets. > My point is that NAT-traversal for SIP and NAT-traversal on the P2P > layer really is logically two separate things, and they should be > analyzed separately. It may well be that the underlying p2p layer can > offer the SIP layer a non-NATed routing environment (indeed, it is > probably desirable), but in theory the p2p layer can tackle it's own > signaling NAT traversal without offering the SIP layer a non-NATed > routing environment (leaving private IP addresses in SIP messages). > g-) > > > > > > > > - Philip > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 11:35:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qbM-0003JG-61; Mon, 25 Jun 2007 11:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2qbK-0003Im-UV for p2psip@ietf.org; Mon, 25 Jun 2007 11:35:38 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2qbJ-0002Ax-Ag for p2psip@ietf.org; Mon, 25 Jun 2007 11:35:38 -0400 Received: by py-out-1112.google.com with SMTP id f31so5133pyh for ; Mon, 25 Jun 2007 08:35:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=nzj/O+hPn6WWfU6V1nfjlM7C7CMkTcrRbpTE0RF4j24eh1U7KVseGABvnfv8h9rffM10vxWYbwEmx4MgvuQaPuzmjKggy61BOXBlj5e2/PTMN8buagyOv7IG5jexdvpOTd1d+vDYUzk/6HOwLZQI0Xm1OepyAr9u9irtaUaJg0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jBUHesTbmWjm5mgnmw8vgO8L4BkLYVWyt0hXoO849p4vBwiMfkba6aovCig/QETuuBr9/PmmvGay/BiA6M5RURZJyC2VNsQUUDh5ykBMDquK3deBdm1QP7JYjyQVuLIxamT55pu82p19sqONYeo2nO07qqz/e4dBlBRRg7LBt/A= Received: by 10.65.95.12 with SMTP id x12mr9362337qbl.1182785736340; Mon, 25 Jun 2007 08:35:36 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Mon, 25 Jun 2007 08:35:36 -0700 (PDT) Message-ID: <4d4304a00706250835i4395129ei5a6ba54478d41283@mail.gmail.com> Date: Mon, 25 Jun 2007 11:35:36 -0400 From: "David A. Bryan" To: "Eunsoo Shim" Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays In-Reply-To: <7b683f3f0706242252n1059e6c9m1b3aff67c6da6eb6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu> <08d401c7ae98$5e945570$9501a8c0@cis.neustar.com> <467231F1.4080605@softarmor.com> <118801c7b1d3$2101a440$9501a8c0@cis.neustar.com> <7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com> <46778BAE.5010504@teigre.com> <20d2bdfb0706201309p414f4e49qe2c21bbd82d8386c@mail.gmail.com> <7b683f3f0706242252n1059e6c9m1b3aff67c6da6eb6@mail.gmail.com> X-Google-Sender-Auth: a0096e959a5e0250 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I tend to agree local domain should be tried first, for a couple of reasons. First, the person you are trying to call is more likely there (using the "you call people in your company more than local people more than regional more than international" old rule of thumb. YMMV), and second, if the overlay is running in a small area (ad-hoc network, enterprise, local cluster), then the local domain search is likely to complete first in any case. David On 6/25/07, Eunsoo Shim wrote: > My comments are inline > > > On 6/20/07, Bruce Lowekamp wrote: > > Catching up on this thread. Comments inline > > > > On 6/19/07, Dean Willis wrote: > > > > > > On Jun 19, 2007, at 2:54 AM, Greger V. Teigre wrote: > > > > > > > We have two choices as I see it: > > > > > > > > 1. Is the AoR supposed to be the equivalent of an email address > > > > where the whole domain must handled authoritatively by one entity, > > > > here overlay (which allows 3263 lookups) ? > > > > > > > > 2. Or is the AoR supposed to be the equivalent of "use your email > > > > address as username on my website"? > > > > > > > > > > I think #1 is the general solution, and there might reasonably be a > > > fallback to behavior #2 under certain fully-disconnected scenarios > > > that I don't really even want to think about right now because the > > > overlay-discovery and authentication problems become very, very messy > > > and make my head hurt. > > > > I agree, although I think that dividing into just these two scenarios > > is a little bit restrictive. Consider a case where a company with an > > established conventional SIP installation is migrating over to a > > P2PSIP installation as hardware is replaced. They could expect for > > some period of time to have both systems, and are not likely to want > > to use different domain parts for the old and new phones (no one > > really should be aware of the difference other than IT). In this > > case, one good solution might be to have the p2p devices perform the > > lookup in the overlay and if it fails, contact the conventional proxy, > > only reporting failure if that fails. So in this case, there is an > > overlay, and the overlay should only contain one domain, but it's not > > authoritative. > > There is a quite straightforward way to allow interoperation of the c/s sip > devices and p2psip devices using the same domain name. The concept draft or > my old architecture draft describes it. The overlay can be the authoritative > overlay for the domain. > > > I can also see situations where you might have some Internet > > connectivity, but might still want a particular overlay to support > > multiple domain parts (e.g. a non-IETF conference might have hundreds > > of people who could participate in a p2psip overlay and would > > frequently be contacting each other, but not have ideal connectivity > > to the Internet). > > > > Again, I think the right answer here is to search > > the local overlay before going to the broader Internet. > > I am not quite sure I understand the benefit of doing this. > Are you concerned that the DNS thus the mechanism of RFC3263 may not work > very well because of poor Internet connectivity in this case? > > While I agree with the concern about being a part of 6 overlays and > > searching each of them everytime you make a call, I think this is > > something of an implementation (and usage) issue more than an issue we > > need to worry about right now. > > If we want interoperation of various implementations, we would need > agreement on what and how each peer/node will choose its own overlay(s) > because it will affect how a peer/node will find others. > > > There are practical cases to support > > overlays that are authoritative for a single domainpart, practical > > cases where an overlay should have only one domain present but is not > > authoritative, and cases with mixed domains and no authoritative > > presence whatsoever. > > > > I also agree with Dean that my head hurts when thinking about how to > > handle authentication in the mixed domain case, since without > > involving an authoritative server for the domain, your security > > options are very different than in normal SIP. > > Yes. So I believe we should accept the fact and be flexible about security > requirements. > Again I believe insecure connectivity may be better than no connectivity in > some situations. > > Thanks. > > Eunsoo > > > On 6/19/07, Brian Rosen wrote: > > > Okay. I like it. > > > > > > Is there a way I can look in the URI or the DNS entry for the domain in > the > > > URI and discover if this is p2p or c/s, or do I blindly try one and then > the > > > other? > > > > Does it matter whether a URI is backed by a p2p or conventional SIP > > installation? Unless you're going to join an overlay in order to send > > a message to anyone running one, I've been assuming that if you're > > sending a SIP message to a URI that is not supported by the overlay > > you're connected to, the resolution and message should follow the > > normal 3263 etc procedure. > > > > draft-marocco-p2psip-interwork-01 talks a bit about > interworkings > > between conventional and p2p deployments and I don't think has been > > mentioned in this thread so far. > > > > Bruce > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 12:17:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rFT-0008OE-IA; Mon, 25 Jun 2007 12:17:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rFS-0008Nx-9Z for p2psip@ietf.org; Mon, 25 Jun 2007 12:17:06 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rFO-0000ya-8v for p2psip@ietf.org; Mon, 25 Jun 2007 12:17:06 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 85C3244A49D for ; Tue, 26 Jun 2007 00:16:59 +0800 (CST) Message-ID: <003901c7b744$40225740$a507740a@DELLWEI> From: "Wei Gengyu" To: References: <467F9225.3020000@teigre.com> Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... Date: Tue, 26 Jun 2007 00:14:03 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0527729385==" Errors-To: p2psip-bounces@ietf.org --===============0527729385== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpJZiBQMlBTSVAgb3ZlcmxheSBpcyBpbnRlbmRlZCB0byBjb252ZXkgU0lQKDMyNjEs MzI2MykgbWVzc2FnZXMsIHRoZXJlIHdvdWxkIGJlIHNvbWUgY29udHJhZGljdGlvbnMuDQpTSVAo MzI2MSwzMjYzKSBpbiBuYXR1cmUgaXMgYmFzZWQgb24gY2xpZW50L3NlcnZlciBhcmNoaXRlY3R1 cmUuIEJ1dCBQMlAgb3ZlcmxheSBpcyBkaWZmZXJlbnQuDQoNClNvLCBQMlBTSVAgb3ZlcmxheSB3 aWxsIHRyYW5zZmVyIHNlc3Npb24gc2V0dXAgKGluaXRpYXRpb24pIG1lc3NhZ2VzIG9uIHBlZXIg dG8gcGVlciBvdmVybGF5IA0Kd2hpbGUgaXQgY2FuIGJlIHByb3h5IG9mIFNJUCAoMzI2MSBhbmQg MzI2MykganVzdCBmb3IgY29tcGF0aWJpbGl0eS4NCkkgIGRvIG5vdCBhZ3JlZSB0byBtYWtlIFNJ UCBvdmVyIFAyUCBhcyBhIG1haW4gcHVycG9zZS4gDQoNClAyUFNJUCBzaG91bGQgaGF2ZSBpdHMg b3duIGFyY2hpdGVjdHVyZSB0byBoYXZlIHNlc3Npb24gc2V0dXAgZnVuY3Rpb24gYW5kIHRvIHBy b2Nlc3MgTkFUICB0cmF2ZXJzYWwgb3IgZmlyZXdhbGwuIA0KDQpSZWdhcmRzLA0KDQpHZW5neXUN CiANCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiR3JlZ2VyIFYuIFRlaWdy ZSIgPGdyZWdlckB0ZWlncmUuY29tPg0KVG86ICJQMlBTSVAgTWFpbGluZyBMaXN0IiA8cDJwc2lw QGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBKdW5lIDI1LCAyMDA3IDY6MDAgUE0NClN1YmplY3Q6 IFtQMlBTSVBdIFRyeWluZyB0byBncmFzcCB3aGF0IHdlIHJlYWxseSBhcmUgc3RhbmRhcmRpemlu Zy4uLg0KDQoNCj4gSXQgc2VlbXMgdG8gbWUgKGJhc2VkIG9uIHRoZSBkcmFmdHMpIHRoYXQgdGhp cyB3b3JraW5nIGdyb3VwIGhhcyBzZXQgb3V0IA0KPiB0byBzdGFuZGFyZGl6ZSB0b28gbXVjaC4g SG93ZXZlciwgSSBtYXkgYmUgdW5hYmxlIHRvIHNlZSB0aGUgYmlnIHBpY3R1cmUgDQo+IGFmdGVy IHJlYWRpbmcgdGhlIGRyYWZ0cy4uLg0KPiANCj4gSSdtIHRyeWluZyB0byB1c2UgYSAoc2ltcGxp c3RpYykgbGF5ZXJlZCBhcHByb2FjaCwgcGxlYXNlIGhlbHAgbWUgc29ydCANCj4gb3V0IG15IGNv bmZ1c2lvbnMuLi4NCj4gDQo+IFRoZSBsb2dpY2FsIHN0YXJ0aW5nIHBvaW50IGZvciBtZSBpcyB0 aGUgcHVyZSBTSVAgVUEgKGFscmVhZHkgb3V0IA0KPiB0aGVyZSkuIEl0IHdpbGwgKGhvcGVmdWxs eSkgc3VwcG9ydCBzaXAtb3V0Ym91bmQgYW5kIGljZS4gIEl0IHdpbGwgdGh1cyANCj4gZXhwZWN0 IHRvIGZpbmQgYSByZWdpc3RyYXIsIGFzIHdlbGwgYXMgYSBTVFVOIGFuZCBhIFNUVU4gcmVsYXkg ZnVuY3Rpb24uIA0KPiBVc2luZyB0aGVzZSBtZWNoYW5pc21zLCB0aGUgVUEgd2lsbCBoYXBwaWx5 IFJFR0lTVEVSIHdpdGggdGhlIGFzc2lnbmVkIA0KPiByZWdpc3RyYXIsIGVzdGFibGlzaCB0aGUg bmVjZXNzYXJ5IHNpcC1vdXRib3VuZCBmbG93cyBhbmQgd2lsbCBuZWdvdGlhdGUgDQo+IHVzaW5n IGljZSB3aGVuIHNldHRpbmcgdXAgYSBkaWFsb2cuIA0KPiANCj4gRm9yIHNpbXBsaWNpdHksIGxl dCdzIHNheSB0aGUgcmVnaXN0cmFyIGhhcHBlbnMgdG8gYmUgYSBQMlBTSVAgcGVlciANCj4gcGh5 c2ljYWxseSByZXNpZGluZyBvbiBhbm90aGVyIGRldmljZS4gVGhpcyBwZWVyIHNob3VsZCBoYXZl IGEgU0lQIA0KPiBpbXBsZW1lbnRhdGlvbiwgYXMgd2VsbCBhcyBhIHAycCBpbXBsZW1lbnRhdGlv bi4gVGhpcyBwZWVyIHNob3VsZCBiZSANCj4gYWJsZSB0byBhY3QgYXMgYSByZWdpc3RyYXIgZm9y IHRoZSBTSVAgVUEsIGluY2x1ZGluZyBwaW5nLXBvbmdzLCBkbyANCj4gcm91dGluZywgYW5kIG9m ZmVyIFNUVU4gcmVsYXkgYWRkcmVzc2VzIHdoZW4gYW4gSU5WSVRFIGdvZXMgdGhyb3VnaCANCj4g KGNvbnRyYXJ5IGV4YW1wbGUsIGRyYWZ0LW1hcm9jY28tcDJwc2lwLWludGVyd29yay0wMSBzZWVt cyB0byBpbmRpY2F0ZSANCj4gc29tZSBwMnBzaXAtYXdhcmUgY29kZSBpbiB0aGUgU0lQIFVBKS4g IEluIG15IG1pbmQsIHRoZSBQMlAgbGF5ZXIgc2hvdWxkIA0KPiBvZmZlciB0aGUgU0lQLXBhcnQg b2YgdGhlIHBlZXIgYW4gQVBJIHdoZXJlIG1lc3NhZ2VzIGNhbiBiZSByb3V0ZWQgYW5kIA0KPiBy ZWxheSBmdW5jdGlvbiBkYXRhIHJldHJpZXZlZCwgKGRyYWZ0LWJhc2V0LXAycHNpcC1wMnBjb21t b24tMDEgc2VlbXMgdG8gDQo+IGJlIGNsb3Nlc3QsIGJ1dCBjb25jZXJucyBhIHByb3RvY29sIG9u IHRoZSB3aXJlKSBob3dldmVyLCBpbXBsZW1lbnRpbmcgDQo+IHRoZSBBUEkgaW4gdGhlIFNJUCBj b2RlIHNob3VsZCBiZSBhIGZhaXJseSBzaW1wbGUgb25lLXRvLW9uZSBtYXBwaW5nLg0KPiANCj4g VGhlIEFQSSBzaG91bGQgYmUgc3RhbmRhcmRpemVkIGluIHRoaXMgd29ya2luZyBncm91cCwgc28g dGhhdCBhbnkgU0lQIA0KPiBpbXBsZW1lbnRvciBoYXZpbmcgaW1wbGVtZW50ZWQgdGhlIFAyUFNJ UCBBUEkgY2FuIHBsdWcgaW4gYSBuZXcgcDJwIA0KPiBpbXBsZW1lbnRhdGlvbiAob3Igc3VwcG9y dCBzZXZlcmFsKS4gVGhlc2UgaW1wbGVtZW50YXRpb25zIGNvdWxkIGJlIA0KPiBkaWZmZXJlbnQg b3ZlcmxheXMgb3IgZGlmZmVyZW50IGxpYnJhcmllcyBpbXBsZW1lbnRpbmcgdGhlIHNhbWUgDQo+ IG92ZXJsYXlzLiBIb3BlZnVsbHksIGFsbCB0aGUgdmFyaW91cyBhdmFpbGFibGUgcDJwIGltcGxl bWVudGF0aW9ucyB3aWxsIA0KPiBpbXBsZW1lbnQgdGhpcyBBUEksIHRodXMgZW5zdXJpbmcgdGhh dCBTSVAgVUEgaW1wbGVtZW50YXRpb25zIHF1aWNrbHkgDQo+IHdpbGwgYmVjb21lIHAycCBhd2Fy ZS4NCj4gDQo+IFNvIGZhciBzbyBnb29kLCBOQVQgaGFzIGJlZW4gaGFuZGxlZCBvbiB0aGUgU0lQ IGxheWVyIGZvciBib3RoIHNpZ25hbGluZyANCj4gYW5kIG1lZGlhLCBhbmQgdGhlIG9ubHkgdGhp bmcgd2UgbmVlZCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgUDJQU0lQIA0KPiBBUEkgdGhh dCByZWFsaXplcyB0aGUgQVBJIGZ1bmN0aW9ucy4uLg0KPiANCj4gSG93ZXZlciwgbm93IEkgc3Rh cnQgdG8gZ2V0IGEgYml0IGNvbmZ1c2VkLiBXZSB3YW50IHRvIHN0YW5kYXJkaXplIHRvIA0KPiBl bnN1cmUgaW50ZXJvcGVyYWJpbGl0eS4gV2VsbCwgd2l0aCBhIHdlbGwtZGVzaWduZWQgUDJQU0lQ IEFQSSwgd2UgaGF2ZSANCj4gY29tZSBwcmV0dHkgZmFyLCBJIHRoaW5rLiBXZSBoYXZlIGludGVy b3BlcmFiaWxpdHkgdXNpbmcgYWxsIHRoZSBTSVAgDQo+IG1lY2hhbmlzbXMsIGluY2x1ZGluZyAz MjYzLiBTSVAgbWVzc2FnZXMgY2FuIGZsb3cgYWNyb3NzIG92ZXJsYXlzIG9uIHRoZSANCj4gU0lQ IGxheWVyLiBTbywgd2hhdCBtb3JlIGRvIHdlIHdhbnQgdG8gZW5zdXJlPyBUaGF0IHZhcmlvdXMg DQo+IGltcGxlbWVudGF0aW9ucyBvbiB0aGUgcDJwIGxheWVyIGNhbiB0YWxrIHRvIGVhY2ggb3Ro ZXI/IFdoeSBkbyB3ZSB3YW50IA0KPiB0aGF0PyAgV29uJ3Qgd2UganVzdCBmcmVlemUgaW5ub3Zh dGlvbiBiZWNhdXNlIHdlIGFyZSBub3QgYWJsZSB0byBjcmVhdGUgDQo+IGEgcHJvdG9jb2wgYmV0 d2VlbiB0aGUgcGVlcnMgdGhhdCBpcyBhZ25vc3RpYyB0byBoYXNoIHRhYmxlcyBldGM/IEkga25v dyANCj4gdGhlIGNoYXJ0ZXIgc2F5cyB3ZSBzaG91bGQgc3RhbmRhcmRpemUgdGhlIHByb3RvY29s IGJldHdlZW4gdGhlIHBlZXJzLCANCj4gYnV0IEkgZmVlbCB0aGF0IFNJUCBhbmQgcDJwIGlzIG1p eGVkIHRvZ2V0aGVyIHRvbyBtdWNoIGFuZCBJIGp1c3QgZG9uJ3QgDQo+IGdldCBpdC4NCj4gDQo+ IE9rLCBzbyBwZW9wbGUgd2FudCBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gcDJwIHBlZXJzLCBi dXQgSSBkb24ndCANCj4gcmVhbGx5IHNlZSBob3cgd2UgY2FuIGF2b2lkIHNwZW5kaW5nIGEgbG90 IG9mIHJlc291cmNlcyBvbiBqdXN0IGNyZWF0aW5nIA0KPiBhIGRlZmF1bHQgdGhhdCBwcm9iYWJs eSBxdWlja2x5IHdpbGwgYmUgb3V0ZGF0ZWQ/ISAod2UncmUgbm90IA0KPiBzdGFuZGFyZGl6aW5n IGEgYmVzdCBwcmFjdGljZSB0aGF0IGhhcyBlbWVyZ2VkIGFscmVhZHkpICBBbmQgSSBkb24ndCAN Cj4gcmVhbGx5IHNlZSB3aGF0IHdlIGdhaW4gKHVubGVzcyB0aGUgYW1iaXRpb24gaXMgdG8gY3Jl YXRlIGEgd29ybGQtd2lkZSANCj4gcDJwIG5ldHdvcmsgd2hlcmUgYWxzbyBub24tU0lQIGNhbiBi ZSB0cmFuc3BvcnRlZC4uLikuDQo+IA0KPiBTbywgYmFzZWQgb24gbXkgbGFjayBvZiB1bmRlcnN0 YW5kaW5nIG9mIHRoZSBhYm92ZSwgcGFyZG9uIG15IGxhY2sgb2YgDQo+IHVuZGVyc3RhbmRpbmcg b24gc29tZSBvdGhlciBpc3N1ZXM6DQo+IC0gSG93IE5BVCBpcyBoYW5kbGVkIG9uIHRoZSBwMnAg bGF5ZXIgc2hvdWxkIGhhdmUgbm90aGluZyB0byBkbyB3aXRoIHRoZSANCj4gU0lQIGxheWVyLiAg T25lIHNob3VsZCBiZSBmcmVlIHRvIG1ha2UgYW55IGRlY2lzaW9uLCByaWdodD8NCj4gLSBXaGV0 aGVyIHRvIHVzZSBTSVAsIGJpbmFyeSwgb3Igc29tZSB0ZXh0LWJhc2VkIHByb3RvY29sIChpZiB0 byBiZSANCj4gc3RhbmRhcmRpemVkKSBzaG91bGQgcmVhbGx5IGJlIGJhc2VkIG9uIGZhY3RzOiB3 aGF0IHdvcmtzIG1vc3QgDQo+IGVmZmljaWVudGx5IGZyb20gYSAqcHJvdG9jb2wgc3RhbmRwb2lu dCo/IExldCdzIG5vdCBnZXQgY29uZnVzZWQgYnkgdGhlIA0KPiBmYWN0IHRoYXQgU0lQIHdpbGwg YmUgdHJhbnNwb3J0ZWQgb24gdG9wIG9mIHRoZSBwMnAgcHJvdG9jb2wuDQo+IC0gQ2hvb3Npbmcg b2YgdHJhbnNwb3J0LWxheWVyIHByb3RvY29sczogYWdhaW4sIGlnbm9yZSBTSVAsIHdoYXQgd29y a3M/DQo+IA0KPiBPZiBjb3Vyc2UsIGFzIGJvdGggdGhlIFNJUCBhbmQgcDJwIGxheWVycyBtdXN0 IHNvbHZlIE5BVCB0cmF2ZXJzYWwsIGl0IA0KPiBpcyBlYXN5IHRvIG1peCB0aGVtIHRvZ2V0aGVy IGFuZCB5ZXMsIEknbSBvcGVuIHRvIHRoZSBwb3NzaWJpbGl0eSBvZiANCj4gY29sbGFwc2luZyB0 aGUgbGF5ZXJzIGZvciBvcHRpbWl6YXRpb24gcmVhc29ucy4gQnV0IEkgZG9uJ3QgdGhpbmsgd2Ug YXJlIA0KPiB0aGVyZSB5ZXQuIEFuZCBJIGFsc28gdGhpbmsgdGhhdCB0aHJvdWdoIHNvbWUgc2Vw YXJhdGlvbiwgdGhlIHAycCBndXlzIA0KPiAoSSdtIG5vdCBvbmUgb2YgdGhlbSkgYW5kIHRoZSBT SVAgZ3V5cyBjYW4gY29uY2VudHJhdGUgb24gd2hhdCB0aGV5IGFyZSANCj4gZ29vZCBhdC4gSWYg d2UgbWl4LCBvbmx5IHBlb3BsZSB3aG8gYXJlIGV4cGVydHMgb24gYm90aCBjYW4gYSkgaW1wbGVt ZW50IA0KPiBiKSBoYXZlIGFuIG9waW5pb24uDQo+IA0KPiBQbGVhc2UsYXR0YWNrIG15IGFyZ3Vt ZW50cy4NCj4gZy0pDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+IFAyUFNJUEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4= --===============0527729385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0527729385==-- From p2psip-bounces@ietf.org Mon Jun 25 12:28:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rQ4-0000ML-H5; Mon, 25 Jun 2007 12:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rQ3-0000MF-KV for p2psip@ietf.org; Mon, 25 Jun 2007 12:28:03 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rQ0-0005zr-VL for p2psip@ietf.org; Mon, 25 Jun 2007 12:28:03 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id BEFD014DDD54 for ; Tue, 26 Jun 2007 00:27:58 +0800 (CST) Message-ID: <004001c7b745$c918a350$a507740a@DELLWEI> From: "Wei Gengyu" To: References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com><0092E94C-85B7-4051-AA73-36E5FA8B1E59@cs.columbia.edu><08d401c7ae98$5e945570$9501a8c0@cis.neustar.com><467231F1.4080605@softarmor.com><118801c7b1d3$2101a440$9501a8c0@cis.neustar.com><7b683f3f0706181537o50cbad2dlb0661a41329cf0aa@mail.gmail.com><46778BAE.5010504@teigre.com><20d2bdfb0706201309p414f4e49qe2c21bbd82d8386c@mail.gmail.com><7b683f3f0706242252n1059e6c9m1b3aff67c6da6eb6@mail.gmail.com> <4d4304a00706250835i4395129ei5a6ba54478d41283@mail.gmail.com> Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Tue, 26 Jun 2007 00:27:55 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1640698049==" Errors-To: p2psip-bounces@ietf.org --===============1640698049== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIA0KQWxzbyBpbmNsdWRpbmcgc29tZSBkZWRpY2F0ZWQgbmV0d29ya3MuDQpCYXNlZCBvbiBQ MlAgdGVjaG5vbG9neSwgd2UgYXJlIHRyeWluZyB0byBnaXZlIGEgc29sdXRpb24gdG8gYW4gb3Bl cmF0b3IgZm9yIGl0cyBtb2JpbGl0eSBtYW5hZ2VtZW50Lg0KDQpSZWdhcmRzLA0KDQpHZW5neXUN Cg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJEYXZpZCBBLiBCcnlhbiIg PGRicnlhbkBzaXBlZXJpb3IuY29tPg0KVG86ICJFdW5zb28gU2hpbSIgPGV1bnNvb3NoaW1AZ21h aWwuY29tPg0KQ2M6ICJQMlBTSVAgTWFpbGluZyBMaXN0IiA8cDJwc2lwQGlldGYub3JnPg0KU2Vu dDogTW9uZGF5LCBKdW5lIDI1LCAyMDA3IDExOjM1IFBNDQpTdWJqZWN0OiBSZTogW1AyUFNJUF0g Q29uY2VwdHMgaXNzdWU6IERvbWFpbnMgYW5kIE92ZXJsYXlzDQoNCg0KPkkgdGVuZCB0byBhZ3Jl ZSBsb2NhbCBkb21haW4gc2hvdWxkIGJlIHRyaWVkIGZpcnN0LCBmb3IgYSBjb3VwbGUgb2YNCj4g cmVhc29ucy4gRmlyc3QsIHRoZSBwZXJzb24geW91IGFyZSB0cnlpbmcgdG8gY2FsbCBpcyBtb3Jl IGxpa2VseSB0aGVyZQ0KPiAodXNpbmcgdGhlICJ5b3UgY2FsbCBwZW9wbGUgaW4geW91ciBjb21w YW55IG1vcmUgdGhhbiBsb2NhbCBwZW9wbGUNCj4gbW9yZSB0aGFuIHJlZ2lvbmFsIG1vcmUgdGhh biBpbnRlcm5hdGlvbmFsIiBvbGQgcnVsZSBvZiB0aHVtYi4gWU1NViksDQo+IGFuZCBzZWNvbmQs IGlmIHRoZSBvdmVybGF5IGlzIHJ1bm5pbmcgaW4gYSBzbWFsbCBhcmVhIChhZC1ob2MgbmV0d29y aywNCj4gZW50ZXJwcmlzZSwgbG9jYWwgY2x1c3RlciksIHRoZW4gdGhlIGxvY2FsIGRvbWFpbiBz ZWFyY2ggaXMgbGlrZWx5IHRvDQo+IGNvbXBsZXRlIGZpcnN0IGluIGFueSBjYXNlLg0KPiANCj4g RGF2aWQNCj4gDQo+IE9uIDYvMjUvMDcsIEV1bnNvbyBTaGltIDxldW5zb29zaGltQGdtYWlsLmNv bT4gd3JvdGU6DQo+PiBNeSBjb21tZW50cyBhcmUgaW5saW5lDQo+Pg0KPj4NCj4+IE9uIDYvMjAv MDcsIEJydWNlIExvd2VrYW1wIDxsb3dla2FtcEBzaXBlZXJpb3IuY29tPiB3cm90ZToNCj4+ID4g Q2F0Y2hpbmcgdXAgb24gdGhpcyB0aHJlYWQuICBDb21tZW50cyBpbmxpbmUNCj4+ID4NCj4+ID4g T24gNi8xOS8wNywgRGVhbiBXaWxsaXMgPGRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb20+IHdyb3Rl Og0KPj4gPiA+DQo+PiA+ID4gT24gSnVuIDE5LCAyMDA3LCBhdCAyOjU0IEFNLCBHcmVnZXIgVi4g VGVpZ3JlIHdyb3RlOg0KPj4gPiA+DQo+PiA+ID4gPiBXZSBoYXZlIHR3byBjaG9pY2VzIGFzIEkg c2VlIGl0Og0KPj4gPiA+ID4NCj4+ID4gPiA+IDEuIElzIHRoZSBBb1Igc3VwcG9zZWQgdG8gYmUg dGhlIGVxdWl2YWxlbnQgb2YgYW4gZW1haWwgYWRkcmVzcw0KPj4gPiA+ID4gd2hlcmUgdGhlIHdo b2xlIGRvbWFpbiBtdXN0IGhhbmRsZWQgYXV0aG9yaXRhdGl2ZWx5IGJ5IG9uZSBlbnRpdHksDQo+ PiA+ID4gPiBoZXJlIG92ZXJsYXkgKHdoaWNoIGFsbG93cyAzMjYzIGxvb2t1cHMpID8NCj4+ID4g PiA+DQo+PiA+ID4gPiAyLiBPciBpcyB0aGUgQW9SIHN1cHBvc2VkIHRvIGJlIHRoZSBlcXVpdmFs ZW50IG9mICJ1c2UgeW91ciBlbWFpbA0KPj4gPiA+ID4gYWRkcmVzcyBhcyB1c2VybmFtZSBvbiBt eSB3ZWJzaXRlIj8NCj4+ID4gPiA+DQo+PiA+ID4NCj4+ID4gPiBJIHRoaW5rICMxIGlzIHRoZSBn ZW5lcmFsIHNvbHV0aW9uLCBhbmQgdGhlcmUgbWlnaHQgcmVhc29uYWJseSBiZSBhDQo+PiA+ID4g ZmFsbGJhY2sgdG8gYmVoYXZpb3IgIzIgdW5kZXIgY2VydGFpbiBmdWxseS1kaXNjb25uZWN0ZWQg c2NlbmFyaW9zDQo+PiA+ID4gdGhhdCBJIGRvbid0IHJlYWxseSBldmVuIHdhbnQgdG8gdGhpbmsg YWJvdXQgcmlnaHQgbm93IGJlY2F1c2UgdGhlDQo+PiA+ID4gb3ZlcmxheS1kaXNjb3ZlcnkgYW5k IGF1dGhlbnRpY2F0aW9uIHByb2JsZW1zIGJlY29tZSB2ZXJ5LCB2ZXJ5IG1lc3N5DQo+PiA+ID4g YW5kIG1ha2UgbXkgaGVhZCBodXJ0Lg0KPj4gPg0KPj4gPiBJIGFncmVlLCBhbHRob3VnaCBJIHRo aW5rIHRoYXQgZGl2aWRpbmcgaW50byBqdXN0IHRoZXNlIHR3byBzY2VuYXJpb3MNCj4+ID4gaXMg YSBsaXR0bGUgYml0IHJlc3RyaWN0aXZlLiAgQ29uc2lkZXIgYSBjYXNlIHdoZXJlIGEgY29tcGFu eSB3aXRoIGFuDQo+PiA+IGVzdGFibGlzaGVkIGNvbnZlbnRpb25hbCBTSVAgaW5zdGFsbGF0aW9u IGlzIG1pZ3JhdGluZyBvdmVyIHRvIGENCj4+ID4gUDJQU0lQIGluc3RhbGxhdGlvbiBhcyBoYXJk d2FyZSBpcyByZXBsYWNlZC4gIFRoZXkgY291bGQgZXhwZWN0IGZvcg0KPj4gPiBzb21lIHBlcmlv ZCBvZiB0aW1lIHRvIGhhdmUgYm90aCBzeXN0ZW1zLCBhbmQgYXJlIG5vdCBsaWtlbHkgdG8gd2Fu dA0KPj4gPiB0byB1c2UgZGlmZmVyZW50IGRvbWFpbiBwYXJ0cyBmb3IgdGhlIG9sZCBhbmQgbmV3 IHBob25lcyAobm8gb25lDQo+PiA+IHJlYWxseSBzaG91bGQgYmUgYXdhcmUgb2YgdGhlIGRpZmZl cmVuY2Ugb3RoZXIgdGhhbiBJVCkuICAgSW4gdGhpcw0KPj4gPiBjYXNlLCBvbmUgZ29vZCBzb2x1 dGlvbiBtaWdodCBiZSB0byBoYXZlIHRoZSBwMnAgZGV2aWNlcyBwZXJmb3JtIHRoZQ0KPj4gPiBs b29rdXAgaW4gdGhlIG92ZXJsYXkgYW5kIGlmIGl0IGZhaWxzLCBjb250YWN0IHRoZSBjb252ZW50 aW9uYWwgcHJveHksDQo+PiA+IG9ubHkgcmVwb3J0aW5nIGZhaWx1cmUgaWYgdGhhdCBmYWlscy4g IFNvIGluIHRoaXMgY2FzZSwgdGhlcmUgaXMgYW4NCj4+ID4gb3ZlcmxheSwgYW5kIHRoZSBvdmVy bGF5IHNob3VsZCBvbmx5IGNvbnRhaW4gb25lIGRvbWFpbiwgYnV0IGl0J3Mgbm90DQo+PiA+IGF1 dGhvcml0YXRpdmUuDQo+Pg0KPj4gVGhlcmUgaXMgYSBxdWl0ZSBzdHJhaWdodGZvcndhcmQgd2F5 IHRvIGFsbG93IGludGVyb3BlcmF0aW9uIG9mIHRoZSBjL3Mgc2lwDQo+PiBkZXZpY2VzIGFuZCBw MnBzaXAgZGV2aWNlcyB1c2luZyB0aGUgc2FtZSBkb21haW4gbmFtZS4gVGhlIGNvbmNlcHQgZHJh ZnQgb3INCj4+IG15IG9sZCBhcmNoaXRlY3R1cmUgZHJhZnQgZGVzY3JpYmVzIGl0LiBUaGUgb3Zl cmxheSBjYW4gYmUgdGhlIGF1dGhvcml0YXRpdmUNCj4+IG92ZXJsYXkgZm9yIHRoZSBkb21haW4u DQo+Pg0KPj4gPiBJIGNhbiBhbHNvIHNlZSBzaXR1YXRpb25zIHdoZXJlIHlvdSBtaWdodCBoYXZl IHNvbWUgSW50ZXJuZXQNCj4+ID4gY29ubmVjdGl2aXR5LCBidXQgbWlnaHQgc3RpbGwgd2FudCBh IHBhcnRpY3VsYXIgb3ZlcmxheSB0byBzdXBwb3J0DQo+PiA+IG11bHRpcGxlIGRvbWFpbiBwYXJ0 cyAoZS5nLiBhIG5vbi1JRVRGIGNvbmZlcmVuY2UgbWlnaHQgaGF2ZSBodW5kcmVkcw0KPj4gPiBv ZiBwZW9wbGUgd2hvIGNvdWxkIHBhcnRpY2lwYXRlIGluIGEgcDJwc2lwIG92ZXJsYXkgYW5kIHdv dWxkDQo+PiA+IGZyZXF1ZW50bHkgYmUgY29udGFjdGluZyBlYWNoIG90aGVyLCBidXQgbm90IGhh dmUgaWRlYWwgY29ubmVjdGl2aXR5DQo+PiA+IHRvIHRoZSBJbnRlcm5ldCkuDQo+Pg0KPj4NCj4+ ID4gQWdhaW4sIEkgdGhpbmsgdGhlIHJpZ2h0IGFuc3dlciBoZXJlIGlzIHRvIHNlYXJjaA0KPj4g PiB0aGUgbG9jYWwgb3ZlcmxheSBiZWZvcmUgZ29pbmcgdG8gdGhlIGJyb2FkZXIgSW50ZXJuZXQu DQo+Pg0KPj4gSSBhbSBub3QgcXVpdGUgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGJlbmVmaXQgb2Yg ZG9pbmcgdGhpcy4NCj4+ICBBcmUgeW91IGNvbmNlcm5lZCB0aGF0IHRoZSBETlMgdGh1cyB0aGUg bWVjaGFuaXNtIG9mIFJGQzMyNjMgbWF5IG5vdCB3b3JrDQo+PiB2ZXJ5IHdlbGwgYmVjYXVzZSBv ZiBwb29yIEludGVybmV0IGNvbm5lY3Rpdml0eSBpbiB0aGlzIGNhc2U/DQo+PiA+IFdoaWxlIEkg YWdyZWUgd2l0aCB0aGUgY29uY2VybiBhYm91dCBiZWluZyBhIHBhcnQgb2YgNiBvdmVybGF5cyBh bmQNCj4+ID4gc2VhcmNoaW5nIGVhY2ggb2YgdGhlbSBldmVyeXRpbWUgeW91IG1ha2UgYSBjYWxs LCBJIHRoaW5rIHRoaXMgaXMNCj4+ID4gc29tZXRoaW5nIG9mIGFuIGltcGxlbWVudGF0aW9uIChh bmQgdXNhZ2UpIGlzc3VlIG1vcmUgdGhhbiBhbiBpc3N1ZSB3ZQ0KPj4gPiBuZWVkIHRvIHdvcnJ5 IGFib3V0IHJpZ2h0IG5vdy4NCj4+DQo+PiBJZiB3ZSB3YW50IGludGVyb3BlcmF0aW9uIG9mIHZh cmlvdXMgaW1wbGVtZW50YXRpb25zLCB3ZSB3b3VsZCBuZWVkDQo+PiBhZ3JlZW1lbnQgb24gd2hh dCBhbmQgaG93IGVhY2ggcGVlci9ub2RlIHdpbGwgY2hvb3NlIGl0cyBvd24gb3ZlcmxheShzKQ0K Pj4gYmVjYXVzZSBpdCB3aWxsIGFmZmVjdCBob3cgYSBwZWVyL25vZGUgd2lsbCBmaW5kIG90aGVy cy4NCj4+DQo+PiA+ICAgVGhlcmUgYXJlIHByYWN0aWNhbCBjYXNlcyB0byBzdXBwb3J0DQo+PiA+ IG92ZXJsYXlzIHRoYXQgYXJlIGF1dGhvcml0YXRpdmUgZm9yIGEgc2luZ2xlIGRvbWFpbnBhcnQs IHByYWN0aWNhbA0KPj4gPiBjYXNlcyB3aGVyZSBhbiBvdmVybGF5IHNob3VsZCBoYXZlIG9ubHkg b25lIGRvbWFpbiBwcmVzZW50IGJ1dCBpcyBub3QNCj4+ID4gYXV0aG9yaXRhdGl2ZSwgYW5kIGNh c2VzIHdpdGggbWl4ZWQgZG9tYWlucyBhbmQgbm8gYXV0aG9yaXRhdGl2ZQ0KPj4gPiBwcmVzZW5j ZSB3aGF0c29ldmVyLg0KPj4gPg0KPj4gPiBJIGFsc28gYWdyZWUgd2l0aCBEZWFuIHRoYXQgbXkg aGVhZCBodXJ0cyB3aGVuIHRoaW5raW5nIGFib3V0IGhvdyB0bw0KPj4gPiBoYW5kbGUgYXV0aGVu dGljYXRpb24gaW4gdGhlIG1peGVkIGRvbWFpbiBjYXNlLCBzaW5jZSB3aXRob3V0DQo+PiA+IGlu dm9sdmluZyBhbiBhdXRob3JpdGF0aXZlIHNlcnZlciBmb3IgdGhlIGRvbWFpbiwgeW91ciBzZWN1 cml0eQ0KPj4gPiBvcHRpb25zIGFyZSB2ZXJ5IGRpZmZlcmVudCB0aGFuIGluIG5vcm1hbCBTSVAu DQo+Pg0KPj4gWWVzLiBTbyBJIGJlbGlldmUgd2Ugc2hvdWxkIGFjY2VwdCB0aGUgZmFjdCBhbmQg YmUgZmxleGlibGUgYWJvdXQgc2VjdXJpdHkNCj4+IHJlcXVpcmVtZW50cy4NCj4+IEFnYWluIEkg YmVsaWV2ZSAgaW5zZWN1cmUgY29ubmVjdGl2aXR5IG1heSBiZSBiZXR0ZXIgdGhhbiBubyBjb25u ZWN0aXZpdHkgaW4NCj4+IHNvbWUgc2l0dWF0aW9ucy4NCj4+DQo+PiBUaGFua3MuDQo+Pg0KPj4g RXVuc29vDQo+Pg0KPj4gPiBPbiA2LzE5LzA3LCBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5u ZXQ+IHdyb3RlOg0KPj4gPiA+IE9rYXkuICBJIGxpa2UgaXQuDQo+PiA+ID4NCj4+ID4gPiBJcyB0 aGVyZSBhIHdheSBJIGNhbiBsb29rIGluIHRoZSBVUkkgb3IgdGhlIEROUyBlbnRyeSBmb3IgdGhl IGRvbWFpbiBpbg0KPj4gdGhlDQo+PiA+ID4gVVJJIGFuZCBkaXNjb3ZlciBpZiB0aGlzIGlzIHAy cCBvciBjL3MsIG9yIGRvIEkgYmxpbmRseSB0cnkgb25lIGFuZCB0aGVuDQo+PiB0aGUNCj4+ID4g PiBvdGhlcj8NCj4+ID4NCj4+ID4gRG9lcyBpdCBtYXR0ZXIgd2hldGhlciBhIFVSSSBpcyBiYWNr ZWQgYnkgYSBwMnAgb3IgY29udmVudGlvbmFsIFNJUA0KPj4gPiBpbnN0YWxsYXRpb24/ICBVbmxl c3MgeW91J3JlIGdvaW5nIHRvIGpvaW4gYW4gb3ZlcmxheSBpbiBvcmRlciB0byBzZW5kDQo+PiA+ IGEgbWVzc2FnZSB0byBhbnlvbmUgcnVubmluZyBvbmUsIEkndmUgYmVlbiBhc3N1bWluZyB0aGF0 IGlmIHlvdSdyZQ0KPj4gPiBzZW5kaW5nIGEgU0lQIG1lc3NhZ2UgdG8gYSBVUkkgdGhhdCBpcyBu b3Qgc3VwcG9ydGVkIGJ5IHRoZSBvdmVybGF5DQo+PiA+IHlvdSdyZSBjb25uZWN0ZWQgdG8sIHRo ZSByZXNvbHV0aW9uIGFuZCBtZXNzYWdlIHNob3VsZCBmb2xsb3cgdGhlDQo+PiA+IG5vcm1hbCAz MjYzIGV0YyBwcm9jZWR1cmUuDQo+PiA+DQo+PiA+IGRyYWZ0LW1hcm9jY28tcDJwc2lwLWludGVy d29yay0wMSB0YWxrcyBhIGJpdCBhYm91dA0KPj4gaW50ZXJ3b3JraW5ncw0KPj4gPiBiZXR3ZWVu IGNvbnZlbnRpb25hbCBhbmQgcDJwIGRlcGxveW1lbnRzIGFuZCBJIGRvbid0IHRoaW5rIGhhcyBi ZWVuDQo+PiA+IG1lbnRpb25lZCBpbiB0aGlzIHRocmVhZCBzbyBmYXIuDQo+PiA+DQo+PiA+IEJy dWNlDQo+PiA+DQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4+ID4gUDJQU0lQQGlldGYub3JnDQo+ PiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPj4gPg0K Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPj4gUDJQU0lQQGlldGYub3JnDQo+PiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4+DQo+Pg0KPiANCj4gDQo+ IC0tIA0KPiBEYXZpZCBBLiBCcnlhbg0KPiBkYnJ5YW5AU0lQZWVyaW9yLmNvbQ0KPiArMS43NTcu NTY1LjAxMDEgeDEwMQ0KPiArMS43NTcuNTY1LjAwODggKGZheCkNCj4gd3d3LlNJUGVlcmlvci5j b20NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4gUDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPg== --===============1640698049== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1640698049==-- From p2psip-bounces@ietf.org Mon Jun 25 13:02:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rxL-0000zs-GR; Mon, 25 Jun 2007 13:02:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2rxK-0000y5-TC for p2psip@ietf.org; Mon, 25 Jun 2007 13:02:26 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2rxK-00078N-G9 for p2psip@ietf.org; Mon, 25 Jun 2007 13:02:26 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I2rxJ-0005In-1l; Mon, 25 Jun 2007 13:02:25 -0400 In-Reply-To: <20d2bdfb0706250711t1c67195u379e3b15e12f8d62@mail.gmail.com> References: <467F9225.3020000@teigre.com> <467FCAE0.3070506@teigre.com> <20d2bdfb0706250711t1c67195u379e3b15e12f8d62@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B97FDDD-BB37-4CAD-B5BD-3FE5B569E760@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... Date: Mon, 25 Jun 2007 13:02:32 -0400 To: Bruce Lowekamp X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Bruce. - Philip On 25-Jun-07, at 10:11 , Bruce Lowekamp wrote: > Greger, > > For your example, where you have a "pure SIP" UA contacting a fixed > location registrar that happens to be backed by a P2PSIP overlay, I > think you're right that you can regard the NAT traversal problems as > distinct. But I think this comes out of the assumption that the > registrar has an unfiltered public IP address such as any conventional > registrar would have. This is one use case for P2PSIP, looking at > Section 3 of p2psip-concepts, you assume that the world consists of > SIP UAs (behind NATs) and Proxy Peers (not behind NATs). But for > other use cases, such as with the UA Peers that are behind NATs, you > can't make the assumption that SIP outbound NAT traversal will work. > There is no registrar or proxy to contact. In this case, the overlay > is providing connectivity between the peers, and it makes sense (to > me) to use the overlay in some fashion to establish SIP sessions > between different UA peers. At this point we've seen several > proposals for how to accomplish this, but there's a fairly common > thread that the overlay already has a means of performing NAT > traversal that the SIP messages leverage. > > Bruce > > > On 6/25/07, Greger V. Teigre wrote: >> >> >> Philip Matthews wrote: >> > >> > On 25-Jun-07, at 06:00 , Greger V. Teigre wrote: >> >> So, based on my lack of understanding of the above, pardon my >> lack of >> >> understanding on some other issues: >> >> - How NAT is handled on the p2p layer should have nothing to do >> with >> >> the SIP layer. One should be free to make any decision, right? >> > >> > It seems to me that you are talking about a P2P layer architecture >> > like the one described in >> > draft-matthews-p2psip-hip-hop-00 >> > which talks about a P2P layer that sits below the SIP layer and >> > provides three main functions: >> > 1) Distributed Database >> > 2) Overlay Maintenance >> > 3) Distributed Transport (e.g., routing messages around the >> overlay) >> > Is this correct? >> Well, I didn't really take a position on the actual layering, I >> was just >> trying to look at the functions that must be presented to the pure >> SIP >> UA. Unless I'm completely mistaken, a pure SIP UA should be able to >> contact a SIP UA using the p2p overlay in a completely transparent >> fashion. Those two UAs, one registered with a SIP registrar (c/s), >> the >> other in a p2p overlay should be able to use ice to set up the >> dialog. >> If a relay is needed, it really doesn't matter if a server in the c/s >> domain offers the relay or if the p2p overlay offers the relay as a >> service (or maybe both and the best is chosen). >> >> I would think that a pure SIP UA maybe could establish sip-outbound >> flows both to a SIP registrar (c/s) and to a peer in the overlay >> (acting >> as a registrar). This could enable emergency/disaster redundancy >> or even >> be useful for service providers. >> > With the architecture above, I don't see how you can handle NAT >> > traversal at the SIP layer for SIP signaling. The only proposal >> that I >> > have seen that handles NAT traversal at the SIP layer for SIP >> > signaling is dSIP, and dSIP does not have a separate P2P layer but >> > does everything in SIP. If you are going to separate the P2P layer >> > from the SIP layer, then I think you are pretty much forced to >> put NAT >> > traversal logic in the P2P layer for both P2P messages and for SIP >> > signaling. The only thing you could leave up at the SIP layer is >> NAT >> > traversal for RTP packets. >> My point is that NAT-traversal for SIP and NAT-traversal on the P2P >> layer really is logically two separate things, and they should be >> analyzed separately. It may well be that the underlying p2p layer can >> offer the SIP layer a non-NATed routing environment (indeed, it is >> probably desirable), but in theory the p2p layer can tackle it's own >> signaling NAT traversal without offering the SIP layer a non-NATed >> routing environment (leaving private IP addresses in SIP messages). >> g-) >> > >> > >> > >> > - Philip >> > >> > >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 13:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sX2-000385-0l; Mon, 25 Jun 2007 13:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2sX0-00037s-Ll for p2psip@ietf.org; Mon, 25 Jun 2007 13:39:18 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2sX0-0004cw-4O for p2psip@ietf.org; Mon, 25 Jun 2007 13:39:18 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 25 Jun 2007 10:39:13 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5PHc0ot021595; Mon, 25 Jun 2007 10:38:04 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5PHci0i003374; Mon, 25 Jun 2007 10:39:02 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 10:38:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jun 2007 10:38:48 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com> In-Reply-To: <46723027.9010902@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: do we need a client protocol? Thread-Index: AcevFVALGwr2HnkmTgepau8qUTVjvAIKfluA References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> <46723027.9010902@softarmor.com> From: "Henry Sinnreich" To: "Dean Willis" , "David A. Bryan" X-OriginalArrivalTime: 25 Jun 2007 17:38:50.0226 (UTC) FILETIME=[B0F16D20:01C7B74F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Avshalom Houri , P2PSIP Mailing List , Philip Matthews Subject: [P2PSIP] do we need a client protocol? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and - Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so, for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something > is a peer if it isn't doing anything other than talking to someone=20 > and making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It=20 > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes? > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service. > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the peer. > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jun 25 14:16:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t7D-0000jY-FD; Mon, 25 Jun 2007 14:16:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2t7B-0000Ws-HT for p2psip@ietf.org; Mon, 25 Jun 2007 14:16:41 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I2t7B-0002xc-2K for p2psip@ietf.org; Mon, 25 Jun 2007 14:16:41 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 25 Jun 2007 11:16:36 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5PIFUot000065; Mon, 25 Jun 2007 11:15:31 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5PIGI18009584; Mon, 25 Jun 2007 11:16:33 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 11:16:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Peer protocol, DHT and running code Date: Mon, 25 Jun 2007 11:14:04 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D229E0BAE@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Peer protocol, DHT and running code Thread-Index: Ace0BTi9TQjyC6+IRmqM/py4xI5llgCrAssgAAIuB5AAAfmHsAAJy0QwABqFZ+A= References: <24CCCC428EFEA2469BF046DB3C7A8D229E09F2@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "David Barrett" , "Enrico Marocco" , "Brian Rosen" X-OriginalArrivalTime: 25 Jun 2007 18:16:32.0565 (UTC) FILETIME=[F566F650:01C7B754] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Emil Ivov , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David Barrett wrote: >Some complete, end-to-end implementation of P2PSIP, ICE, and STUN that >demonstrates the combination does in fact produce effective results. Completely agree!=20 Maybe the WG chairs could suggest a process to keep running code and P2P SIP Internet Drafts in sync; that is put a brake on drafts until someone catches up with code and measurements. As mentioned, there is ample code measurements and research reports for NAT-less P2P, such as Bamboo, etc., but the ICE part for P2P though conceptually OK as reported here may have some surprises.=20 How much time would a call setup take when routing over multiple hops with NATs in the way? This is a critical measurement objective IMHO. Question: Can the P2PSIP WG avoid the avalanche of code-less I-Ds seen in other SIP WGs? Or is this idea too outlandish :-) Henry -----Original Message----- From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Sunday, June 24, 2007 10:33 PM To: Henry Sinnreich; 'Enrico Marocco'; 'Brian Rosen' Cc: 'Emil Ivov'; 'Philip Matthews'; 'P2PSIP Mailing List' Subject: RE: [P2PSIP] Peer protocol, DHT and running code > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Subject: RE: [P2PSIP] Peer protocol, DHT and running code >=20 > David, >=20 > > But where the rubber meets the road is when deciding what to do in the >=20 > > *absence* of running code. >=20 > There is an abundance of running code and performance measurements for > most DHTs, see for example openDHT.org, Chord, etc. >=20 > What we don't have now is open source code for recent ICE specs (as far > as I know) and most of all, measurements with ICE, even for CS SIP > systems. > This has been mentioned by others on this list and makes me uneasy as > well. >=20 > IMHO standards that are not backed up by OS code may fail in spectacular > ways. We don't need to mention here some examples :-) Heh, totally agree. I guess what I'd like us to do is choose our top use case and build/adopt an application for real-world use and testing. For example, I'd like to see "OpenSkype". Some complete, end-to-end implementation of P2PSIP, ICE, and STUN that demonstrates the combination does in fact produce effective results. Then, we can measure the hell of that thing and figure out where it's good and bad. And once it's been proven to be "good enough" in one area (ie, meeting the base requirements for a given use case), then we can discuss how to extend that to cover the next-highest-priority use case, and so on down the list. In this way we focus our energy on quantifying and solving real-world problems that affect actual users, reducing distractions and maximizing the use of our limited resources. Does anyone agree with this plan? Anybody know of a good OpenSkype to adopt? Or, if we can't do this plan, what an alternative plan? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 26 16:26:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3HcJ-0003qw-BQ; Tue, 26 Jun 2007 16:26:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3HcI-0003qq-6j for p2psip@ietf.org; Tue, 26 Jun 2007 16:26:26 -0400 Received: from relay2.csie.ncu.edu.tw ([140.115.50.19]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3HcG-0000ib-Kx for p2psip@ietf.org; Tue, 26 Jun 2007 16:26:26 -0400 Received: from edfhc3v6vss9j3 (123-195-44-58.ethome-ip.ethome.com.tw [123.195.44.58]) (authenticated bits=0) by relay2.csie.ncu.edu.tw (8.13.8/8.13.8) with ESMTP id l5QKPigX078562 for ; Wed, 27 Jun 2007 04:25:48 +0800 (CST) From: "J.-R. Jiang" To: Date: Wed, 27 Jun 2007 04:25:39 +0800 Message-ID: <009401c7b830$2c6b9ee0$0202a8c0@edfhc3v6vss9j3> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Virus-Scanned: ClamAV version 0.90.2, clamav-milter version 0.90.2 on relay2.csie.ncu.edu.tw X-Virus-Status: Clean X-Spam-Status: No, score=-98.3 required=9.0 tests=HTML_MESSAGE, RCVD_IN_NJABL_DUL,USER_IN_WHITELIST autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on relay2.csie.ncu.edu.tw X-Spam-Score: 0.0 (/) X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97 Subject: [P2PSIP] Two week reminder: CFP -- P2PNVE 2007 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530807444==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1530807444== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0095_01C7B873.3A8EDEE0" This is a multi-part message in MIME format. ------=_NextPart_000_0095_01C7B873.3A8EDEE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to remind you that the paper submission deadline (July 10, 2007) = of the International Workshop on Peer-to-Peer Network Virtual Environments = 2007 (P2P-NVE 2007) is two weeks away. =20 We extend the topics of interest of the workshop to include the = following items: *Peer-to-Peer systems and infrastructures=20 *Applications of Peer-to-Peer systems=20 *Performance evaluation of Peer-to-Peer Systems=20 *Trust and security issues in Peer-to-Peer Systems=20 *Network support for Peer-to-Peer Systems=20 *Fault tolerance in Peer-to-Peer systems *Efficient Peer-to-Peer resource lookup *Distributed Hash Tables (DHT) and related issues *All aspects of Peer-to-Peer content, bandwidth, storage and computation power sharing =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL FOR PAPERS = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D P2P-NVE 2007 International Workshop on Peer-to-Peer Network Virtual Environments 2007 in conjunction with The 13th International Conference on Parallel and Distributed Systems (ICPADS 2007) December 5 -7, 2007 National Tsing Hua University, Hsinchu, Taiwan, R.O.C.=20 http://acnlab.csie.ncu.edu.tw/P2PNVE2007. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D About P2P-NVE 2007 The rapid growth and popularity of networked virtual environments (NVEs) such as Massively Multiplayer Online Games (MMOGs) in recent years have spawned a series of research interests in constructing such large-scale virtual environments. For increasing scalability and decreasing the cost = of management and deployment, more and more studies propose using = peer-to-peer (P2P) architectures to construct large-scale NVEs for games, multimedia virtual worlds and other applications. The goal of such research is to support an Earth-scale virtual environment or to make hosting virtual = worlds more affordable than existing client-server approaches. However, = existing solutions for consistency control, persistent data storage, multimedia = data dissemination, and cheat-prevention may not be straightforwardly adapted = to such new environments, novel ideas and designs thus are needed to = realize the potential of P2P-based NVEs. =20 The theme of this workshop is to solicit original and previously = unpublished new ideas on the construction and realization of P2P-based NVEs, with a focus to facilitate discussions and idea exchanges by both academics and practitioners. All papers accepted for the workshop will be included in = the IEEE Xplore Digital Library and will be included in the proceedings published by the IEEE Computer Society. =20 Topics of interest include, but are not limited to: =20 * Constructions of P2P overlays for NVEs * Multicast for P2P NVEs * P2P NVE content distribution * 3D streaming for P2P NVEs * Voice communication on P2P NVEs * Persistent storage for P2P NVEs * Security and cheat-prevention mechanisms for P2P games * Data structures and queries for P2P NVEs * Consistency control for P2P NVEs * Design considerations for P2P NVEs * P2P NVE applications on mobile devices * Prototype P2P virtual environment systems =20 Important Dates =20 Paper Submission: July 10, 2007 Author Notification: August 10, 2007 Camera Ready Copy Due: September 2, 2007 =20 Paper Submission=20 Authors are invited to submit an electronic version of original, = unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to = web site http://acnlab.csie.ncu.edu.tw/P2PNVE2007. Submitted papers should = be in be in PDF format in accordance with IEEE Computer Society guidelines (ftp://pubftp.computer.org/press/outgoing/proceedings). All submitted = papers will be refereed by reviewers in terms of originality, contribution, correctness, and presentation. =20 ------=_NextPart_000_0095_01C7B873.3A8EDEE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to remind you that the = paper submission deadline (July 10, 2007) of the International Workshop on Peer-to-Peer Network Virtual Environments 2007 (P2P-NVE 2007) is two = weeks away.

 

 We extend the topics of = interest of the workshop to include the following items:

*Peer-to-Peer systems and = infrastructures

*Applications of Peer-to-Peer = systems

*Performance evaluation of = Peer-to-Peer Systems

*Trust and security issues in = Peer-to-Peer Systems

*Network support for Peer-to-Peer = Systems

*Fault tolerance in Peer-to-Peer = systems

*Efficient Peer-to-Peer resource = lookup

*Distributed Hash Tables (DHT) and = related issues

*All aspects of Peer-to-Peer = content, bandwidth, storage and computation power sharing

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= CALL FOR PAPERS = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

P2P-NVE 2007

International Workshop on Peer-to-Peer Network = Virtual Environments 2007

in conjunction with

The 13th International Conference on Parallel = and Distributed Systems (ICPADS 2007)

December 5 -7, 2007

National = Tsing Hua University, Hsinchu, Taiwan, R.O.C.

http://acnlab.csie.ncu.= edu.tw/P2PNVE2007.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

About P2P-NVE 2007

The rapid growth and popularity of networked = virtual environments (NVEs) such as Massively Multiplayer Online Games (MMOGs) = in recent years have spawned a series of research interests in constructing = such large-scale virtual environments. For increasing scalability and = decreasing the cost of management and deployment, more and more studies propose using peer-to-peer (P2P) architectures to construct large-scale NVEs for = games, multimedia virtual worlds and other applications. The goal of such = research is to support an Earth-scale virtual environment or to make hosting virtual = worlds more affordable than existing client-server approaches. However, = existing solutions for consistency control, persistent data storage, multimedia = data dissemination, and cheat-prevention may not be straightforwardly adapted = to such new environments, novel ideas and designs thus are needed to = realize the potential of P2P-based NVEs.

 

The theme of this workshop is to solicit = original and previously unpublished new ideas on the construction and realization of P2P-based NVEs, with a focus to facilitate discussions and idea = exchanges by both academics and practitioners. All papers accepted for the workshop = will be included in the IEEE Xplore Digital Library and will be included in the proceedings published by the IEEE Computer Society.

 

Topics of interest include, but are not = limited to:

 

* Constructions of P2P overlays for = NVEs

* Multicast for P2P NVEs

* P2P NVE content = distribution

* 3D streaming for P2P NVEs

* Voice communication on P2P = NVEs

* Persistent storage for P2P = NVEs

* Security and cheat-prevention mechanisms for = P2P games

* Data structures and queries for P2P = NVEs

* Consistency control for P2P = NVEs

* Design considerations for P2P = NVEs

* P2P NVE applications on mobile = devices

* Prototype P2P virtual environment = systems

 

Important Dates

 

Paper Submission:          July 10, 2007

Author Notification:          August 10, 2007

Camera Ready Copy Due:    September = 2, 2007

 

Paper Submission

Authors are invited to submit an electronic = version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced = pages, to web site http://acnlab.csie.ncu.= edu.tw/P2PNVE2007. Submitted papers should be in be in PDF format in accordance with IEEE = Computer Society guidelines (ftp://pubft= p.computer.org/press/outgoing/proceedings). All submitted papers will be refereed by reviewers in terms of = originality, contribution, correctness, and presentation.

 

------=_NextPart_000_0095_01C7B873.3A8EDEE0-- --===============1530807444== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1530807444==-- From p2psip-bounces@ietf.org Tue Jun 26 19:06:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3K6s-0007J1-69; Tue, 26 Jun 2007 19:06:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3K6r-0007Iw-Be for p2psip@ietf.org; Tue, 26 Jun 2007 19:06:09 -0400 Received: from mail44.opentransfer.com ([76.162.254.44]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3K5q-00008W-R0 for p2psip@ietf.org; Tue, 26 Jun 2007 19:06:09 -0400 Received: (qmail 14038 invoked by uid 399); 26 Jun 2007 23:05:06 -0000 Received: from unknown (HELO ?192.168.0.40?) (24.107.197.43) by mail44.opentransfer.com with SMTP; 26 Jun 2007 23:05:06 -0000 Message-ID: <46819BA0.2030901@sipstation.com> Date: Tue, 26 Jun 2007 18:05:04 -0500 From: Alan Johnston User-Agent: Thunderbird 1.5.0.12 (Macintosh/20070509) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] do we need a client protocol? References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> <46723027.9010902@softarmor.com> <24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Philip Matthews , Avshalom Houri , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I've been giving this a lot of thought lately, thinking about the actual requirements. We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol, perhaps we just need levels of participation in the overlay peer protocol. For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can quickly and efficiently route requests within the overlay. Perhaps an energy-limited device could just minimize the number of peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff. Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that could be skipped by these energy-limited peers. Perhaps their requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest performance from it. Thoughts? Thanks, Alan Henry Sinnreich wrote: > Folks, > > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about the > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) entities >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store resources >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It certainly > seems that a peer that moves between contributing and non-contributing > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > >> My concern all along has been that I don't understand why something >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other >> terminology for over a year now. Just looks like a souce of confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth connection > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT models, > a minimally contributing node will route a request it receives. It might > ask nicely (perhaps a q-value mechanism) to not have to route requests, > but would probably mathematically still have to route something it gets. > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets pick a >> > new > >> name, but why some flavor of peer when it does nothing remotely peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore change > it service offering. > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jun 26 19:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KQh-0000yt-0P; Tue, 26 Jun 2007 19:26:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3KQf-0000lS-ED for p2psip@ietf.org; Tue, 26 Jun 2007 19:26:37 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3KPp-0006Z3-SF for p2psip@ietf.org; Tue, 26 Jun 2007 19:26:37 -0400 Received: by ug-out-1314.google.com with SMTP id k3so599617ugf for ; Tue, 26 Jun 2007 16:25:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MCkbAodQ658kj/qK+zYKFBVNWjrWDhZ8dNJNp5jORQUvch+JbAgM/ZHhGLiqeor2OBEDdh+qnjqGOcFRLiFogGr8/V/NRcEPrIisRITDYFr7niy9a8DifJ+ZCZt2wUBtuBaix2UggAWD6YsOBvE8S6qen0qStpdbWKUE13UsO7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=sVH+AoID4surgfCypBR3Xa7IsFnCRrfJsh35EAQFLpC7+0Z8H3IfsLSokEJsbrXmUQH7ORJAAQn7wpJC8JXM3c5n33pTm7vhP26manqKLShEFegV8r0TUt4VjQAkdq0Mkkm4r70gI1e27AE83xHZfdEh22qMT0mQqjIox7bB8DQ= Received: by 10.78.183.15 with SMTP id g15mr3415900huf.1182900344747; Tue, 26 Jun 2007 16:25:44 -0700 (PDT) Received: by 10.78.56.9 with HTTP; Tue, 26 Jun 2007 16:25:44 -0700 (PDT) Message-ID: <7b683f3f0706261625p70f76bd1s6ce2a92528213dae@mail.gmail.com> Date: Tue, 26 Jun 2007 19:25:44 -0400 From: "Eunsoo Shim" To: "Alan Johnston" Subject: Re: [P2PSIP] do we need a client protocol? In-Reply-To: <46819BA0.2030901@sipstation.com> MIME-Version: 1.0 References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> <46723027.9010902@softarmor.com> <24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com> <46819BA0.2030901@sipstation.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Henry Sinnreich , Avshalom Houri , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1530874636==" Errors-To: p2psip-bounces@ietf.org --===============1530874636== Content-Type: multipart/alternative; boundary="----=_Part_23221_28208786.1182900344669" ------=_Part_23221_28208786.1182900344669 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/26/07, Alan Johnston wrote: > > I've been giving this a lot of thought lately, thinking about the actual > requirements. > > We want to allow energy-limited devices to participate to some level in > P2PSIP. As such, perhaps instead of saying we need a client protocol, > perhaps we just need levels of participation in the overlay peer protocol. > > For example, a normal peer in the overlay will maintain peer protocol > connections with many (perhaps dozens) of peers. Why? So that it can > quickly and efficiently route requests within the overlay. Perhaps an energy-limited device could just minimize the number of peer > protocol connections it maintains, perhaps even down to a minimum of > two. This would result in slower routing of its requests through the > overlay, but that seems like a reasonable tradeoff. The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms. Also, perhaps there are some other peer protocol functions, such as data > replication (storage would still be done, but not replication), that > could be skipped by these energy-limited peers. Perhaps their requests > and responses could be routed over the overlay with a lower priority > than full peers. We need to manage the tradeoffs so that those peers > who contribute the least to the overlay also get the lowest performance > from it. I am not quite sure I understand the benefit of introducing such various levels of participation. Having a client protocol seems to be much simpler and easier than introducing these various levels of participation. Thanks. Eunsoo Henry Sinnreich wrote: > > Folks, > > > > Given the length of the discussion on "do we need a client protocol?" > > let me repeat the simple imperatives for the client: > > > > - Limited battery in mobile devices, and > > > > - Other uses besides SIP. Business planning folks may not care about the > > WG charter, but about the return on the investment. > > > > Thanks, Henry > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com] > > Sent: Thursday, June 14, 2007 11:23 PM > > To: David A. Bryan > > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive > > peerterminology > > > > David A. Bryan wrote: > > > >> If I understand this right, not sure I like it. Do these > >> > > "non-contributing > > > >> peer" (I *do* like contributing better than active/passive) entities > >> > > have a > > > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, > >> > > for > > > >> most > >> DHTs, how do we allow you to be in the overlay and not store resources > >> > > (not > > > >> typical for most current DHT algorithms) > >> > > > > Well, that certainly depends on the DHT algorithm involved. It certainly > > seems that a peer that moves between contributing and non-contributing > > might HAVE a peer ID, but whether it chooses to insert itself into the > > DHT "right now" might determine whether it is contributing "right now" > > or not. > > > > > >> My concern all along has been that I don't understand why something > >> is a peer if it isn't doing anything other than talking to someone > >> and making requests, hence why I supported client in the first place. > >> I fail to see how something that isn't contributing anything, and > >> instead talks to a peer to get resources, is in any way a peer. It > >> seems completely not in keeping with the idea of P2P. I also worry it > >> is likely to be very confusing since we've been using the other > >> terminology for over a year now. Just looks like a souce of confusion. > >> > > > > A node might sometimes have a high-bandwidth connection and wish to > > contribute resources, and sometimes not have a high-bandwidth connection > > and therefore not wish to offer resources. Does this modality make it > > two different nodes? > > > > > >> If we do go this way, there is one subtle point. If I join the overlay > >> > > but > > > >> don't happen to offer any services (other than maybe > >> > > storage...depending on > > > >> how we definie it, that might or might not be mandatory), would I be > >> contributing? If joining the overlay (in the sense that we have a > >> > > PeerID > > > >> and > >> we route traffic) doesn't require me to store, I could offer no > >> > > services > > > > That's "offer no other services", since routing is itself a service. > > > > > >> and > >> still be a peer. How do we distinguish between this case and a > >> "non-contributing peer" who isn't even part of the overlay (i.e., no > >> Peer-ID) > >> > > > > I think there's a range of "contributing" in play. For most DHT models, > > a minimally contributing node will route a request it receives. It might > > ask nicely (perhaps a q-value mechanism) to not have to route requests, > > but would probably mathematically still have to route something it gets. > > > > I think we distinguish based on the service advertisements from the > > peer. > > > > > >> If we are so opposed to client for confusion with SIP UAs, lets pick a > >> > > new > > > >> name, but why some flavor of peer when it does nothing remotely peer > >> > > like? > > > > Because in 15 minutes it might roam onto a WiFi net and therefore change > > it service offering. > > > > -- > > Dean > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_23221_28208786.1182900344669 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 6/26/07, Alan Johnston <alan@sipstation.com> wrote:
I've been giving this a lot of thought lately, thinking about the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer protocol.

For example, a normal peer in the overlay will maintain peer protocol
connections with many (perhaps dozens) of peers.  Why?  So that it can
quickly and efficiently route requests within the overlay.


Perhaps an energy-limited device could just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests through the
overlay, but that seems like a reasonable tradeoff.

The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms.

Also, perhaps there are some other peer protocol functions, such as data
replication (storage would still be done, but not replication), that
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that those peers
who contribute the least to the overlay also get the lowest performance
from it.


I am not quite sure I understand the benefit of introducing such various levels of participation.
Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.

Thanks.

Eunsoo


Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It certainly
> seems that a peer that moves between contributing and non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into the
> DHT "right now" might determine whether it is contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why something
>> is a peer if it isn't doing anything other than talking to someone
>> and making requests, hence why I supported client in the first place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. It
>> seems completely not in keeping with the idea of P2P. I also worry it
>>  is likely to be very confusing since we've been using the other
>> terminology for over a year now. Just looks like a souce of confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish to
> contribute resources, and sometimes not have a high-bandwidth connection
> and therefore not wish to offer resources. Does this modality make it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would I be
>> contributing? If joining the overlay (in the sense that we have a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer no
>>
> services
>
> That's "offer no other services", since routing is itself a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and a
>> "non-contributing peer" who isn't even part of the overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For most DHT models,
> a minimally contributing node will route a request it receives. It might
> ask nicely (perhaps a q-value mechanism) to not have to route requests,
> but would probably mathematically still have to route something it gets.
>
> I think we distinguish based on the service advertisements from the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_23221_28208786.1182900344669-- --===============1530874636== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1530874636==-- From p2psip-bounces@ietf.org Tue Jun 26 22:04:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Mt4-0006zh-HN; Tue, 26 Jun 2007 22:04:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Mt3-0006zZ-68 for p2psip@ietf.org; Tue, 26 Jun 2007 22:04:05 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Msx-00013W-1Q for p2psip@ietf.org; Tue, 26 Jun 2007 22:04:05 -0400 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 <0JK900BPIV10TU@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:03:00 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JK90080DV0ZI2@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:03:00 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JK900H2PV0WLS@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 27 Jun 2007 10:02:59 +0800 (CST) Date: Wed, 27 Jun 2007 10:02:56 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 In-reply-to: <7A7D2D13-9CE0-4F75-9D6A-BBA0899B0748@magma.ca> To: 'Philip Matthews' Message-id: <003a01c7b85f$47bd4a20$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acew4ZzpomBzIqHPRuWy47yMQWGj9QHfRjAQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org HI, Philip: In all, using HIP to deliver peer protocol message is an interesting topic. I give some comments below. Regards! 1. section 1.1 Note that SIP and other applications an access the Distributed Transport function directly without going through the other two functions. [JiangXingFeng]Do you want to make the distributed transported function so general that all application messages could be forwarded in the overlay? Let me show an example: Alice wants to call Bob? How does Alice send the Invite message? Send to Bob through the overlay or get the Bob's contact address first, later send to Bob directly? If Alice sends the invite message through the overlay, what does the admitting peer of Bob's key do? Forward the message to Bob's contact address? If it forwards the message, how does the admitting peer know the characteristic of the value under this key? 2. o Network layer: The ability to deliver a message to an arbitrary peer in the overlay. In our view, this involves adding a header to the message that specifies the destination peer ID and then routing that message along existing connections in the overlay to the destination peer. [JiangXingFeng] What does the network layer refer to? IP layer or overlay network layer? In my opinion, it refers to overlay network layer here. 3. Figure 2:Each peer in the network is behind its own NAT. What does this statement mean? 4. There are two ways to send a packet to another peer in the overlay: send it on a direct connection to the remote peer, or send it hop-by- hop through the overlay. A peer typically uses hop-by-hop routing when it has only a small amount of data to transfer to the remote peer (for example, a Distributed Database update or a SIP INVITE transaction), and sets up a direct connection when it has a larger amount of data to transfer (for example, an RTP session). In my opinion, only the peer protocol message should be routed hop-by-hop through the overlay? Like the comments in 1, how does the admitting peer process the application message? Maybe the peer does not recognize the specific application message? That Sending packets directly to destination peer, i think, is a problem arising from the usage of HIP, not in the scope of P2P, because in P2PSIP case, not all communications should be protected by IPSEC ESP. -- Jiang XingFeng > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Sunday, June 17, 2007 9:15 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 > > Folks: > > Eric Cooper, Alan Johnston, and I have just written a draft that > suggests what we think > is an interesting direction for the P2PSIP working group. > > We argue that a P2PSIP overlay should use HIP (the Host Identity > Protocol) > to provide a number of the basic features in an overlay, namely: > o Peer IDs; > o Transporting messages around the overlay; > o Signaling new overlay connections; > o Supporting mobility and multi-homing of peers; > o Providing message security. > > One of the reasons we really like this idea is because, using the > approach > described in the draft, many existing applications don't require any > modifications > and "just work" in an overlay. > > We describe this idea in a draft that has just been submitted. > Until the draft appears in the archives, you can get a copy at > http://www.magma.ca/~philip_matthews/draft-willis-p2psip- > concepts-04.txt > or for the html version > http://www.magma.ca/~philip_matthews/draft-willis-p2psip- > concepts-04.htm > > Here is the abstract from the draft: > This document examines a P2PSIP architecture where the peer-to-peer > (P2P) layer is separate from and lies below the SIP layer. We > discuss the functions of the P2P layer in such an architecture, and > focus in on the Distributed Transport function - the function that > allows a peer to exchange messages with any other peer in the > overlay, even in the presence of NATs. We list the features that > the > Distributed Transport function needs to provide, and observe that > the > Host Identity Protocol (HIP) already provides a number of these > features. We then propose extensions to HIP that allow it to > provide > the missing features. We discuss how a complete P2PSIP architecture > can be built around HIP, and contrast this approach with other > approaches for implementing a P2P layer. Two of the advantages of > HIP approach are that (a) most existing applications can run in an > overlay without needing any changes and (b) peer mobility and NAT > traversal are handled in a way that is transparent to most > applications. > > - Philip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 27 03:30:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Rz7-0006oI-6V; Wed, 27 Jun 2007 03:30:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3Rz5-0006Ym-HS for p2psip@ietf.org; Wed, 27 Jun 2007 03:30:39 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3Ryx-0001HL-1q for p2psip@ietf.org; Wed, 27 Jun 2007 03:30:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5R7UGfJ027604; Wed, 27 Jun 2007 10:30:24 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 10:30:13 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 10:30:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Wed, 27 Jun 2007 10:32:49 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F049E8BC7@esebe102.NOE.Nokia.com> In-Reply-To: <7b683f3f0706261625p70f76bd1s6ce2a92528213dae@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace4SXgaj2ZLzz95R0yk/2vR0eR/aAAP/Q4Q References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com><4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com><46723027.9010902@softarmor.com><24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com><46819BA0.2030901@sipstation.com> <7b683f3f0706261625p70f76bd1s6ce2a92528213dae@mail.gmail.com> From: To: , X-OriginalArrivalTime: 27 Jun 2007 07:30:13.0374 (UTC) FILETIME=[000781E0:01C7B88D] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 Cc: hsinnrei@adobe.com, AVSHALOM@il.ibm.com, philip_matthews@magma.ca, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1328755593==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1328755593== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B88C.FFBDD921" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B88C.FFBDD921 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the network). However there are also many entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and some accessing resources stored in DHT using a client protocol. Marcin ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] do we need a client protocol? =09 =09 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the actual requirements. =09 We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. Perhaps an energy-limited device could just minimize the number of peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms.=20 =09 Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest performance from it. I am not quite sure I understand the benefit of introducing such various levels of participation. Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =09 =09 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It certainly > seems that a peer that moves between contributing and non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > >> My concern all along has been that I don't understand why something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth connection=20 > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT models,=20 > a minimally contributing node will route a request it receives. It might > ask nicely (perhaps a q-value mechanism) to not have to route requests, > but would probably mathematically still have to route something it gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 ------_=_NextPart_001_01C7B88C.FFBDD921 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi,
 
We have wide variety of mobile = terminals. The=20 capabilities of mobile terminals are constantly improving e.g. even = now Nokia's N-series/E-series devices are very powerful. From = this=20 reason some of mobile terminals may become peers (depending on = the=20 case scenario: churn, size of the network). However there are=20 also many entry-level/low-end devices that have slow CPUs = and limited memory. 
Battery life is another issue. Most of the = mobile phone users=20 want long battery life. DHT maintenance and handling = searches=20 have impact on idle state that is more important from battery = life=20 perspective than the active state (e.g. when user is = calling/answering a=20 call).
    
I was considering a similar = solution to the=20 one that Alan proposed however as Eunsoo said it would be quite difficult to = control the=20 number of connections in DHT. We also have problems with handling=20 searches.
 
I assume that we will have some mobile terminals = taking part in=20 DHT and some accessing resources stored in DHT using a client=20 protocol.

Marcin
From: ext Eunsoo Shim=20 [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007=20 02:26
To: Alan Johnston
Cc: Henry Sinnreich; = Avshalom=20 Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: = [P2PSIP] do=20 we need a client protocol?



On 6/26/07, Alan=20 Johnston <alan@sipstation.com> = wrote:
I've=20 been giving this a lot of thought lately, thinking about the=20 actual
requirements.

We want to allow energy-limited = devices to=20 participate to some level in
P2PSIP.   As such, perhaps = instead=20 of saying we need a client protocol,
perhaps we just need levels = of=20 participation in the overlay peer protocol.

For example, a = normal=20 peer in the overlay will maintain peer protocol
connections with = many=20 (perhaps dozens) of peers.  Why?  So that it can =
quickly and efficiently route requests within the = overlay.


Perhaps=20 an energy-limited device could just minimize the number of = peer
protocol=20 connections it maintains, perhaps even down to a minimum=20 of
two.  This would result in slower routing of its = requests=20 through the
overlay, but that seems like a reasonable tradeoff.=20

The underling algorithm (e.g. a certain DHT algorithm) will = dictate=20 the number of connections even though there might be some room for = adjustment.=20 I don't think it is under complete control of individual peer in the = case of=20 known DHT algorithms.

Also,=20 perhaps there are some other peer protocol functions, such as=20 data
replication (storage would still be done, but not = replication), that=20
could be skipped by these energy-limited = peers.  Perhaps their=20 requests
and responses could be routed over the overlay with a = lower=20 priority
than full peers.  We need to manage the = tradeoffs so=20 that those peers
who contribute the least to the overlay also get = the=20 lowest performance
from it.


I am not quite sure I understand the benefit of = introducing such=20 various levels of participation.
Having a client protocol seems to = be much=20 simpler and easier than introducing these various levels of = participation.=20

Thanks.

Eunsoo


Henry=20 Sinnreich wrote:
> Folks,
>
> Given the length of = the=20 discussion on "do we need a client protocol?"
> let me repeat = the=20 simple imperatives for the client:
>
> - Limited battery = in=20 mobile devices, and
>
> - Other uses besides SIP. = Business=20 planning folks may not care about the
> WG charter, but about = the=20 return on the investment.
>
> Thanks, = Henry
>
>=20 -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com=20 ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: = David A.=20 Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip=20 Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal = for=20 active/passive
> peerterminology
>
> David A. = Bryan=20 wrote:
>
>> If I understand this right, not sure I = like it.=20 Do these
>>
> "non-contributing
>
>> = peer" (I=20 *do* like contributing better than active/passive) entities=20
>>
> have a
>
>> Peer-ID? In = otherwords, are=20 they part of the overlay at all? If so,
>>
>=20 for
>
>> most
>> DHTs, how do we allow you = to be in=20 the overlay and not store resources
>>
>=20 (not
>
>> typical for most current DHT=20 algorithms)
>>
>
> Well, that certainly depends = on the=20 DHT algorithm involved. It certainly
> seems that a peer that = moves=20 between contributing and non-contributing
> might HAVE a peer = ID, but=20 whether it chooses to insert itself into the
> DHT "right now" = might=20 determine whether it is contributing "right now"
> or=20 not.
>
>
>> My concern all along has been that = I don't=20 understand why something
>> is a peer if it isn't doing = anything=20 other than talking to someone
>> and making requests, hence = why I=20 supported client in the first place.
>>  I fail = to see=20 how something that isn't contributing anything, and
>> = instead=20 talks to a peer to get resources, is in any way a peer. = It
>> seems=20 completely not in keeping with the idea of P2P. I also worry=20 it
>>  is likely to be very confusing since we've = been=20 using the other
>> terminology for over a year now. Just = looks=20 like a souce of confusion.
>>
>
> A node might=20 sometimes have a high-bandwidth connection and wish to
> = contribute=20 resources, and sometimes not have a high-bandwidth connection =
> and=20 therefore not wish to offer resources. Does this modality make = it
>=20 two different nodes?
>
>
>> If we do go this = way, there=20 is one subtle point. If I join the overlay
>>
>=20 but
>
>> don't happen to offer any services (other = than=20 maybe
>>
> storage...depending on
>
>> = how we=20 definie it, that might or might not be mandatory), would I = be
>>=20 contributing? If joining the overlay (in the sense that we have=20 a
>>
> PeerID
>
>> and
>> we = route=20 traffic) doesn't require me to store, I could offer = no
>>
>=20 services
>
> That's "offer no other services", since = routing is=20 itself a service.
>
>
>> and
>> still = be a=20 peer. How do we distinguish between this case and a
>>=20 "non-contributing peer" who isn't even part of the overlay (i.e.,=20 no
>> Peer-ID)
>>
>
> I think there's = a range=20 of "contributing" in play. For most DHT models,
> a minimally = contributing node will route a request it receives. It might
> = ask=20 nicely (perhaps a q-value mechanism) to not have to route = requests,
>=20 but would probably mathematically still have to route something it = gets.=20
>
> I think we distinguish based on the service = advertisements=20 from the
> peer.
>
>
>> If we are so = opposed to=20 client for confusion with SIP UAs, lets pick a
>>
> = new=20
>
>> name, but why some flavor of peer when it does = nothing=20 remotely peer
>>
> like?
>
> Because in = 15=20 minutes it might roam onto a WiFi net and therefore change
> = it=20 service offering.
>
> --
> Dean
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


______= _________________________________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

------_=_NextPart_001_01C7B88C.FFBDD921-- --===============1328755593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1328755593==-- From p2psip-bounces@ietf.org Wed Jun 27 03:50:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3SIF-0008Bv-V2; Wed, 27 Jun 2007 03:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3SIE-0008Bp-6y for p2psip@ietf.org; Wed, 27 Jun 2007 03:50:26 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3SI4-0004xj-K8 for p2psip@ietf.org; Wed, 27 Jun 2007 03:50:26 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5R7TnDx000794; Wed, 27 Jun 2007 09:29:51 +0200 Message-ID: <468216AB.7010700@teigre.com> Date: Wed, 27 Jun 2007 09:50:03 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... References: <467F9225.3020000@teigre.com> <467FCAE0.3070506@teigre.com> <20d2bdfb0706250711t1c67195u379e3b15e12f8d62@mail.gmail.com> In-Reply-To: <20d2bdfb0706250711t1c67195u379e3b15e12f8d62@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Bruce, Yes, I don't think we disagree on "to use the overlay in some fashion to establish SIP sessions between different UA peers". My post was triggered by a concern over multiple suggested approaches taking different cuts at creating layers/abstraction, but without any overarching understanding of what the different logical layers really are. I started at (what I think is) the top-most layer, i.e a pure SIP UA using the overlay. I also found it useful to logically separate the SIP UA function of a p2psip client and the p2p function in the client. From a software design point of view, I would like to reuse any SIP code and keep it maintained separately from the p2p code, so it just makes sense to think that way. I also think that approaching the problem that way may provide some insights that easier can be discussed independent of approach taken (i.e. dSIP, hip-hop, xpp). I believe that analyzing in layers makes sense before you start joining functions and that doing so is not only an academic exercise. For example, you write "But for other use cases, such as with the UA Peers that are behind NATs, you can't make the assumption that SIP outbound NAT traversal will work." This statement is obviously based on several assumptions, the most important one about a tight integration of a peer UA and a SIP UA. If you analyze in layers, the peer UA can expose to the SIP UA any functionality it wants. For example, the peer UA can provide the SIP UA with one big ALG, provide STUN relay functions, or even expose a virtual non-NATed routing environment and removing any NAT issues. The local peer component can even provide the local SIP UA with a registrar functionality. I'm not saying that this is the way it should be implemented (the drafts have of course progressed deeper into implementations, and I may be behind here; however, I haven't found this discussion anywhere and I don't see it in the drafts or discussions). I'm just saying that talking about NAT handling in the p2p protocol as if it was the same problem as in SIP may prevent us from seeing some other ways of solving this. In fact, I'm still not decided on which implementation approach I favor. However, IMHO, I think the only way to secure widespread adoption of p2psip is to make sure that the SIP implementors can take a quick look at the spec and see where the SIP UA or proxy needs new functionality, and that p2psip functionality is deeply woven into the SIP stack (and that doesn't mean that the p2p peer functionality cannot leverage the SIP stack for its own functionality...) I'll try to elaborate further in my reply to David in this thread. g-) Bruce Lowekamp wrote: > Greger, > > For your example, where you have a "pure SIP" UA contacting a fixed > location registrar that happens to be backed by a P2PSIP overlay, I > think you're right that you can regard the NAT traversal problems as > distinct. But I think this comes out of the assumption that the > registrar has an unfiltered public IP address such as any conventional > registrar would have. This is one use case for P2PSIP, looking at > Section 3 of p2psip-concepts, you assume that the world consists of > SIP UAs (behind NATs) and Proxy Peers (not behind NATs). But for > other use cases, such as with the UA Peers that are behind NATs, you > can't make the assumption that SIP outbound NAT traversal will work. > There is no registrar or proxy to contact. In this case, the overlay > is providing connectivity between the peers, and it makes sense (to > me) to use the overlay in some fashion to establish SIP sessions > between different UA peers. At this point we've seen several > proposals for how to accomplish this, but there's a fairly common > thread that the overlay already has a means of performing NAT > traversal that the SIP messages leverage. > > Bruce > > > On 6/25/07, Greger V. Teigre wrote: >> >> >> Philip Matthews wrote: >> > >> > On 25-Jun-07, at 06:00 , Greger V. Teigre wrote: >> >> So, based on my lack of understanding of the above, pardon my lack of >> >> understanding on some other issues: >> >> - How NAT is handled on the p2p layer should have nothing to do with >> >> the SIP layer. One should be free to make any decision, right? >> > >> > It seems to me that you are talking about a P2P layer architecture >> > like the one described in >> > draft-matthews-p2psip-hip-hop-00 >> > which talks about a P2P layer that sits below the SIP layer and >> > provides three main functions: >> > 1) Distributed Database >> > 2) Overlay Maintenance >> > 3) Distributed Transport (e.g., routing messages around the >> overlay) >> > Is this correct? >> Well, I didn't really take a position on the actual layering, I was just >> trying to look at the functions that must be presented to the pure SIP >> UA. Unless I'm completely mistaken, a pure SIP UA should be able to >> contact a SIP UA using the p2p overlay in a completely transparent >> fashion. Those two UAs, one registered with a SIP registrar (c/s), the >> other in a p2p overlay should be able to use ice to set up the dialog. >> If a relay is needed, it really doesn't matter if a server in the c/s >> domain offers the relay or if the p2p overlay offers the relay as a >> service (or maybe both and the best is chosen). >> >> I would think that a pure SIP UA maybe could establish sip-outbound >> flows both to a SIP registrar (c/s) and to a peer in the overlay (acting >> as a registrar). This could enable emergency/disaster redundancy or even >> be useful for service providers. >> > With the architecture above, I don't see how you can handle NAT >> > traversal at the SIP layer for SIP signaling. The only proposal that I >> > have seen that handles NAT traversal at the SIP layer for SIP >> > signaling is dSIP, and dSIP does not have a separate P2P layer but >> > does everything in SIP. If you are going to separate the P2P layer >> > from the SIP layer, then I think you are pretty much forced to put NAT >> > traversal logic in the P2P layer for both P2P messages and for SIP >> > signaling. The only thing you could leave up at the SIP layer is NAT >> > traversal for RTP packets. >> My point is that NAT-traversal for SIP and NAT-traversal on the P2P >> layer really is logically two separate things, and they should be >> analyzed separately. It may well be that the underlying p2p layer can >> offer the SIP layer a non-NATed routing environment (indeed, it is >> probably desirable), but in theory the p2p layer can tackle it's own >> signaling NAT traversal without offering the SIP layer a non-NATed >> routing environment (leaving private IP addresses in SIP messages). >> g-) >> > >> > >> > >> > - Philip >> > >> > >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 27 06:04:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UO3-0001Bs-Pj; Wed, 27 Jun 2007 06:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3UO2-00016G-JU for p2psip@ietf.org; Wed, 27 Jun 2007 06:04:34 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3UNo-0004rw-Vv for p2psip@ietf.org; Wed, 27 Jun 2007 06:04:34 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5R9i1CK006982; Wed, 27 Jun 2007 11:44:03 +0200 Message-ID: <46823621.2000105@teigre.com> Date: Wed, 27 Jun 2007 12:04:17 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "David A. Bryan" Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... References: <467F9225.3020000@teigre.com> <467FCAE0.3070506@teigre.com> <4d4304a00706250722s66d9e889o20d13461ac00dbbf@mail.gmail.com> In-Reply-To: <4d4304a00706250722s66d9e889o20d13461ac00dbbf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David A. Bryan wrote: > I think there are several ways the NAT functions can be handled, just > a few I have seen proposed are: > > * P2P layer == SIP layer, both use SIP functions to traverse NATs > * P2P layer does its own NAT traversal, and is used to either > negotiate openings or encapsulates the SIP layer traffic > * SIP layer does the NAT traversal, and session and NAT traversal of > the P2P is negotiated there (perhaps it is listed as an SDP stream) > * The two layers are completely independent Thanks, good summary. My point is that it seems that NAT handling for p2p networks and SIP are different enough to justify a separate analysis (I think draft-matthews-p2psip-nats-and-overlays-01 does a good job there). My interpretation is that the type of p2p network has also an impact on NAT handling. So, using SIP concepts to solve NAT in p2p networks seems to me as a classic "if you have a hammer..." case. > > Also people have discussed if ICE is appropriate for the P2P protocol > negotiation, assuming it is not SIP (no one is seriously (at least I > hope not) proposing inventing something other than ICE for the NAT > traversal on the SIP side...) > What a relief! ;-) > I agree that we should probably analyze the two NAT traversal > mechanisms seperately, but I personally think we will find ICE is the > answer in each case, and I really don't like the idea of having to > implement two different NAT traversal techniques and do NAT traversal > two times for the two protocols. Well, ICE is clearly not the answer to all the NAT issues. ICE is about detecting, while NAT has detection element, a routing element, as well as a traversal complexity element (i.e. ALG/firewalls). It is made for offer/answer protocols and is suitable to solve NAT from that point of view. draft-matthews-p2psip-hip-hop-00 offers an alternative where NAT traversal is handled transparently. Deep in that draft and in the references, there is something interesting found (from the "analyze-in-layers" perspective"). Let me try to pull it forward and summarize from a NAT perspective (for the sake of discussion): IPsec has over the years had a lot of trouble with NAT traversal and ALGs. It has gone through all the pains and with UDP-encapsulation, NAT-T and port floating to port 4500, it has by now fairly good NAT traversal characteristics. Let's say each peer establishes IPsec tunnels with each peer, using their certificates in IKE, and calculating a virtual IP address (peerID). We know IPsec mostly as a network stack protocol, but why not implement it on the application layer? (ref. ongoing draft-nikander-esp-beet-mode-07) Implement p2p routing on top of it (HIP, dSIP, whatever you like), using the peerID/IP address, and you have a virtual network between all peers, all can establish tunnels with each other (and maybe negotiate dht to use etc), the p2p layer can provide the SIP UA with a non-NATed network. All signaling is secured and relaying can easily be offered as a service to the SIP layer. The benefit of layering is that you can reuse existing software implementations directly, you leverage years of NAT traversal experience, and you avoid that p2psip enabling of existing UAs turns into a large software implementation project with lots of uncertain characteristics. This is NOT intended as an argument in favor of hip-hop vs. dSIP, rather an example to show why I don't like the NAT discussion to be preempted as "ice will be the choice anyway." I'm afraid it will prevent us from looking at other approaches (or reducing ice to the subset we really need). > This group is about making a protocol > for P2P *specifically* for SIP, we don't need to go out our way to > make it function in other cases, so I think reuse of ICE makes the > most sense. Is that a shared understanding? It seems to me that there is a push to make it usable in non-SIP scenarios as well? > There may be an IETF group to do more generic P2P someday > (I hope so), and hopefully it will grow from our work, but this group > is sort of a baby-step that direction for the IETF -- try to see if a > group can make a P2P protocol work in a narrow problem space like P2P > specifically for SIP -- before deciding about more general P2P > protocols. > > As far as why we are talking about standardizing the DHT between > peers, I'll give you my take. The IETF goal is to allow > implementations from different vendors to work together > interchangably. The IETF doesn't define code APIs, they standardize > the protocols that go over the wire. It isn't about an API that every > SIP UA can implement to call a P2P library, it is about different P2P > devices from different vendors, scattered across the internet or > within an organization being able work together to form a serverless > environment. To think similarly, we aren't saying "here is a set of > code hooks a web browser can use, and underneath developers can write > a library to access "their" proprietery web". Instead, we are making > sure that all the P2PSIP devices across the internet, regardless of > vendor, can be interchangably connected into a P2P overlay and work > together. Yes, I'm sorry, the API example was confusing. I was trying to emphasize the possibility that we don't have a p2p aware SIP UA and a SIP-aware p2p client, and that trying to keep them apart would be good from an analysis point of view, because doing so may give us better answers than keeping both p2p and SIP in our heads at the same time. g-) > David > > On 6/25/07, Greger V. Teigre wrote: >> >> >> Philip Matthews wrote: >> > >> > On 25-Jun-07, at 06:00 , Greger V. Teigre wrote: >> >> So, based on my lack of understanding of the above, pardon my lack of >> >> understanding on some other issues: >> >> - How NAT is handled on the p2p layer should have nothing to do with >> >> the SIP layer. One should be free to make any decision, right? >> > >> > It seems to me that you are talking about a P2P layer architecture >> > like the one described in >> > draft-matthews-p2psip-hip-hop-00 >> > which talks about a P2P layer that sits below the SIP layer and >> > provides three main functions: >> > 1) Distributed Database >> > 2) Overlay Maintenance >> > 3) Distributed Transport (e.g., routing messages around the >> overlay) >> > Is this correct? >> Well, I didn't really take a position on the actual layering, I was just >> trying to look at the functions that must be presented to the pure SIP >> UA. Unless I'm completely mistaken, a pure SIP UA should be able to >> contact a SIP UA using the p2p overlay in a completely transparent >> fashion. Those two UAs, one registered with a SIP registrar (c/s), the >> other in a p2p overlay should be able to use ice to set up the dialog. >> If a relay is needed, it really doesn't matter if a server in the c/s >> domain offers the relay or if the p2p overlay offers the relay as a >> service (or maybe both and the best is chosen). >> >> I would think that a pure SIP UA maybe could establish sip-outbound >> flows both to a SIP registrar (c/s) and to a peer in the overlay (acting >> as a registrar). This could enable emergency/disaster redundancy or even >> be useful for service providers. >> > With the architecture above, I don't see how you can handle NAT >> > traversal at the SIP layer for SIP signaling. The only proposal that I >> > have seen that handles NAT traversal at the SIP layer for SIP >> > signaling is dSIP, and dSIP does not have a separate P2P layer but >> > does everything in SIP. If you are going to separate the P2P layer >> > from the SIP layer, then I think you are pretty much forced to put NAT >> > traversal logic in the P2P layer for both P2P messages and for SIP >> > signaling. The only thing you could leave up at the SIP layer is NAT >> > traversal for RTP packets. >> My point is that NAT-traversal for SIP and NAT-traversal on the P2P >> layer really is logically two separate things, and they should be >> analyzed separately. It may well be that the underlying p2p layer can >> offer the SIP layer a non-NATed routing environment (indeed, it is >> probably desirable), but in theory the p2p layer can tackle it's own >> signaling NAT traversal without offering the SIP layer a non-NATed >> routing environment (leaving private IP addresses in SIP messages). >> g-) >> > >> > >> > >> > - Philip >> > >> > >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jun 27 13:06:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ayH-0004GL-FS; Wed, 27 Jun 2007 13:06:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3ayG-0004Fz-C1 for p2psip@ietf.org; Wed, 27 Jun 2007 13:06:24 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3ayB-0004am-Ni for p2psip@ietf.org; Wed, 27 Jun 2007 13:06:24 -0400 Received: from lappy ([70.0.243.157]) by quinthar.com for ; Wed, 27 Jun 2007 10:05:56 -0700 From: "David Barrett" To: , , Subject: RE: [P2PSIP] do we need a client protocol? Date: Wed, 27 Jun 2007 10:05:37 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace4SXgaj2ZLzz95R0yk/2vR0eR/aAAP/Q4QABEXISA= In-reply-to: <3F18E76823C95E4795181D74BAC7664F049E8BC7@esebe102.NOE.Nokia.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7742ab7d8f94ae8c6013d3682e631edb Cc: hsinnrei@adobe.com, AVSHALOM@il.ibm.com, philip_matthews@magma.ca, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1340770654==" Errors-To: p2psip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1340770654== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01C7B8A2.C0BE05C0" This is a multi-part message in MIME format. ------=_NextPart_000_0049_01C7B8A2.C0BE05C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don=92t know anything about mobile application design vis-=E0-vis = battery life, but I=92m guessing power usage could be vastly oversimplified to something like: =20 Power =3D A + nB =20 Where A is the overall cost of just having the device powered on and listening to the radio, and B is the cost of sending a byte of data. = What I=92m wondering is, what is the ratio of A to B? Can anyone give = real-world data? =20 For example, I=92d accept that sending 200Mbps probably requires about = 2x the power 100Mbps: for a high enough value of =91n=92, then the constant A = gets marginalized. But what about 200Kbps or 200bps? For some low value of = =91n=92, then A dominates the power usage. =20 The reason I ask is I wonder if it=92s even useful to discuss power = usage for something like P2PSIP. It could be that even for a =93real=94 peer, = =91n=92 is so low that the power consumption is dominated by other factors, rendering = the entire discussion moot. =20 Can anybody give real-world data on this topic? =20 -david=20 =20 _____ =20 From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] = Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that have slow = CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and = some accessing resources stored in DHT using a client protocol. Marcin _____ =20 From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =20 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the actual requirements. We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer = protocol. For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. =20 =20 Perhaps an energy-limited device could just minimize the number of peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual peer in the case = of known DHT algorithms.=20 =20 Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest performance from it. I am not quite sure I understand the benefit of introducing such various levels of participation. Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.=20 Thanks. Eunsoo =20 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about = the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and non-contributing = > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > >> My concern all along has been that I don't understand why something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets pick = a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------=_NextPart_000_0049_01C7B8A2.C0BE05C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I don’t know anything about = mobile application design vis-=E0-vis battery life, but I’m guessing = power usage could be vastly oversimplified to something like:

 

Power =3D A + = nB

 

Where A is the overall cost of just = having the device powered on and listening to the radio, and B is the cost of = sending a byte of data.=A0 What I’m wondering is, what is the ratio of A = to B?=A0 Can anyone give real-world data?

 

For example, I’d accept that = sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough = value of ‘n’, then the constant A gets marginalized.=A0 But what = about 200Kbps or 200bps?=A0 For some low value of ‘n’, then A = dominates the power usage.

 

The reason I ask is I wonder if = it’s even useful to discuss power usage for something like P2PSIP.=A0 It = could be that even for a “real” peer, ‘n’ is so low that the = power consumption is dominated by other factors, rendering the entire = discussion moot.

 

Can anybody give real-world data on = this topic?

 

-david =

 

From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]
Sent: Wednesday, June 27, = 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

Hi,

 

We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices = are very powerful. From this reason some of mobile terminals may become = peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that = have slow CPUs and limited memory. 

Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is = calling/answering a call).

    

I was considering a similar = solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We = also have problems with handling searches.

 

I assume that we will = have some mobile terminals taking part in DHT and some accessing resources stored = in DHT using a client protocol.


Marcin

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; = Avshalom Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do = we need a client protocol?

 

On 6/26/07, Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought lately, thinking about = the actual
requirements.

We want to allow energy-limited devices to participate to some level = in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer = protocol.

For example, a normal peer in the overlay will maintain peer = protocol
connections with many (perhaps dozens) of = peers.  Why?  So that it can
quickly and efficiently route requests within the = overlay.

 

 

Perhaps an energy-limited device could just minimize the number = of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests = through the
overlay, but that seems like a reasonable tradeoff. =


The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for adjustment. I = don't think it is under complete control of individual peer in the case of = known DHT algorithms.

 

Also, perhaps there are some other peer protocol functions, such = as data
replication (storage would still be done, but not replication), that =
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that = those peers
who contribute the least to the overlay also get the lowest = performance
from it.



I am not quite sure I understand the benefit of introducing such various = levels of participation.
Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.

Thanks.

Eunsoo

 

Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care = about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than = active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If = so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store = resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It = certainly
> seems that a peer that moves between contributing and = non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into = the
> DHT "right now" might determine whether it is = contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why = something
>> is a peer if it isn't doing anything other than talking to = someone
>> and making requests, hence why I supported client in the first = place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. = It
>> seems completely not in keeping with the idea of P2P. I also = worry it
>>  is likely to be very confusing since we've been = using the other
>> terminology for over a year now. Just looks like a souce of = confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish = to
> contribute resources, and sometimes not have a high-bandwidth = connection
> and therefore not wish to offer resources. Does this modality make = it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the = overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would = I be
>> contributing? If joining the overlay (in the sense that we have = a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer = no
>>
> services
>
> That's "offer no other services", since routing is itself = a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and = a
>> "non-contributing peer" who isn't even part of the = overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For = most DHT models,
> a minimally contributing node will route a request it receives. It = might
> ask nicely (perhaps a q-value mechanism) to not have to route = requests,
> but would probably mathematically still have to route something it = gets.
>
> I think we distinguish based on the service advertisements from = the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets = pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely = peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore = change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

 

------=_NextPart_000_0049_01C7B8A2.C0BE05C0-- --===============1340770654== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1340770654==-- From p2psip-bounces@ietf.org Wed Jun 27 16:42:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eLI-00009A-Ah; Wed, 27 Jun 2007 16:42:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3eLH-000090-6f for p2psip@ietf.org; Wed, 27 Jun 2007 16:42:23 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3eL8-0000QB-UO for p2psip@ietf.org; Wed, 27 Jun 2007 16:42:23 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 27 Jun 2007 13:42:04 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5RKewot014629; Wed, 27 Jun 2007 13:40:58 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5RKeVI9022440; Wed, 27 Jun 2007 13:40:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jun 2007 13:42:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Wed, 27 Jun 2007 13:38:32 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D229E1498@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace4SXgaj2ZLzz95R0yk/2vR0eR/aAAP/Q4QABEXISAACzUmUA== References: <3F18E76823C95E4795181D74BAC7664F049E8BC7@esebe102.NOE.Nokia.com> From: "Henry Sinnreich" To: "David Barrett" , , , X-OriginalArrivalTime: 27 Jun 2007 20:42:03.0055 (UTC) FILETIME=[9E0183F0:01C7B8FB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2d34cc233f4c7d0e15c8dffb8d5df80e Cc: AVSHALOM@il.ibm.com, philip_matthews@magma.ca, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1077244291==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1077244291== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B8FB.7F378CA1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B8FB.7F378CA1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is more complicated than this. Under normal cell phone operation we have the talk time and the standby = time which is much longer. =20 Making a cell phone a full peer eliminates this distinction to a large = degree since the overlay maintenance messages keep the phone 'talking' = all the time. =20 Henry =20 ________________________________ From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Wednesday, June 27, 2007 10:06 AM To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 I don't know anything about mobile application design vis-=E0-vis = battery life, but I'm guessing power usage could be vastly = oversimplified to something like: =20 Power =3D A + nB =20 Where A is the overall cost of just having the device powered on and = listening to the radio, and B is the cost of sending a byte of data. = What I'm wondering is, what is the ratio of A to B? Can anyone give = real-world data? =20 For example, I'd accept that sending 200Mbps probably requires about 2x = the power 100Mbps: for a high enough value of 'n', then the constant A = gets marginalized. But what about 200Kbps or 200bps? For some low = value of 'n', then A dominates the power usage. =20 The reason I ask is I wonder if it's even useful to discuss power usage = for something like P2PSIP. It could be that even for a "real" peer, 'n' = is so low that the power consumption is dominated by other factors, = rendering the entire discussion moot. =20 Can anybody give real-world data on this topic? =20 -david=20 =20 ________________________________ From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] = Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile = terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of = mobile terminals may become peers (depending on the case scenario: = churn, size of the network). However there are also many = entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long = battery life. DHT maintenance and handling searches have impact on idle = state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number = of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and = some accessing resources stored in DHT using a client protocol. Marcin =09 ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =20 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the = actual requirements. =09 We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol, = perhaps we just need levels of participation in the overlay peer = protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. =20 =20 Perhaps an energy-limited device could just minimize the number of = peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 =09 The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual = peer in the case of known DHT algorithms.=20 =20 Also, perhaps there are some other peer protocol functions, such as = data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their = requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest = performance from it. =09 =09 I am not quite sure I understand the benefit of introducing such = various levels of participation. Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =20 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client = protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about = the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) = entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and = non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into = the > DHT "right now" might determine whether it is contributing "right = now" > or not. > > >> My concern all along has been that I don't understand why something = >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first = place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry = it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make = it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I = be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., = no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets = pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely = peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------_=_NextPart_001_01C7B8FB.7F378CA1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It is more complicated than = this.

Under normal cell phone operation = we have the talk time and the standby time which is much = longer.

 

Making a cell phone a full peer = eliminates this distinction to a large = degree since the overlay maintenance messages keep the phone = ‘talking’ all the time.

 

Henry

 

From: David = Barrett [mailto:dbarrett@quinthar.com]
Sent: Wednesday, June 27, = 2007 10:06 AM
To: = marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

I don’t know anything about = mobile application design vis-=E0-vis battery life, but I’m guessing = power usage could be vastly oversimplified to something = like:

 

Power =3D A + = nB

 

Where A is the overall cost of just = having the device powered on and listening to the radio, and B is the cost of = sending a byte of data.  What I’m wondering is, what is the ratio of = A to B?  Can anyone give real-world data?

 

For example, I’d accept that = sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough = value of ‘n’, then the constant A gets marginalized.  But what about 200Kbps or 200bps?  For some low value of = ‘n’, then A dominates the power usage.

 

The reason I ask is I wonder if = it’s even useful to discuss power usage for something like P2PSIP.  It = could be that even for a “real” peer, ‘n’ is so low that = the power consumption is dominated by other factors, rendering the entire discussion moot.

 

Can anybody give real-world data on = this topic?

 

-david =

 

From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]
Sent: Wednesday, June 27, = 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

Hi,

 

We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices = are very powerful. From this reason some of mobile terminals may become = peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that = have slow CPUs and limited memory. 

Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is = calling/answering a call).

    

I was considering a similar = solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We = also have problems with handling searches.

 

I assume that we will = have some mobile terminals taking part in DHT and some accessing resources stored = in DHT using a client protocol.


Marcin

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com] =
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; = Avshalom Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do = we need a client protocol?

 

On 6/26/07, Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought lately, thinking about = the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer = protocol.

For example, a normal peer in the overlay will maintain peer = protocol
connections with many (perhaps dozens) of = peers.  Why?  So that it can
quickly and efficiently route requests within the = overlay.

 

=

 

Perhaps an energy-limited device could just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests = through the
overlay, but that seems like a reasonable tradeoff. =


The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for adjustment. I = don't think it is under complete control of individual peer in the case of = known DHT algorithms.

=

 

Also, perhaps there are some other peer protocol functions, such = as data
replication (storage would still be done, but not replication), that =
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that = those peers
who contribute the least to the overlay also get the lowest = performance
from it.



I am not quite sure I understand the benefit of introducing such various = levels of participation.
Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.

Thanks.

Eunsoo

=

 

Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client = protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care = about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than = active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If = so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store = resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It = certainly
> seems that a peer that moves between contributing and = non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into = the
> DHT "right now" might determine whether it is = contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why = something
>> is a peer if it isn't doing anything other than talking to = someone
>> and making requests, hence why I supported client in the first = place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. = It
>> seems completely not in keeping with the idea of P2P. I also = worry it
>>  is likely to be very confusing since we've been = using the other
>> terminology for over a year now. Just looks like a souce of = confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish = to
> contribute resources, and sometimes not have a high-bandwidth = connection
> and therefore not wish to offer resources. Does this modality make = it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the = overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would = I be
>> contributing? If joining the overlay (in the sense that we have = a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer = no
>>
> services
>
> That's "offer no other services", since routing is itself = a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and = a
>> "non-contributing peer" who isn't even part of the = overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For = most DHT models,
> a minimally contributing node will route a request it receives. It = might
> ask nicely (perhaps a q-value mechanism) to not have to route = requests,
> but would probably mathematically still have to route something it = gets.
>
> I think we distinguish based on the service advertisements from = the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets = pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely = peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore = change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

 

------_=_NextPart_001_01C7B8FB.7F378CA1-- --===============1077244291== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1077244291==-- From p2psip-bounces@ietf.org Wed Jun 27 18:42:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3gDF-0001NF-2W; Wed, 27 Jun 2007 18:42:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3gDD-0001N9-91 for p2psip@ietf.org; Wed, 27 Jun 2007 18:42:11 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3gCl-00010R-50 for p2psip@ietf.org; Wed, 27 Jun 2007 18:42:11 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Wed, 27 Jun 2007 15:41:33 -0700 From: "David Barrett" To: "'Henry Sinnreich'" , , , Subject: RE: [P2PSIP] do we need a client protocol? Date: Wed, 27 Jun 2007 15:41:33 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace4SXgaj2ZLzz95R0yk/2vR0eR/aAAP/Q4QABEXISAACzUmUAAEQsoQ In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D229E1498@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 78a5a4a09549c7cc239b767c425e1a62 Cc: AVSHALOM@il.ibm.com, philip_matthews@magma.ca, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2044920179==" Errors-To: p2psip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============2044920179== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D2_01C7B8D1.A408E330" This is a multi-part message in MIME format. ------=_NextPart_000_00D2_01C7B8D1.A408E330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That makes sense. So my next question is: what are the capabilities of standby mode, and what triggers it going into =93talk=94 mode? =20 It must be listening to some sort of cell signal even in standby mode, = just so it can receive phone calls. Given this, when in standby mode, does = it also have access to the IP network? In other words, is it possible to = have a phone in low-power standby mode but (for example) listening for = incoming TCP connections or UDP packets? =20 -david =20 _____ =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 27, 2007 1:39 PM To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 It is more complicated than this. Under normal cell phone operation we have the talk time and the standby = time which is much longer. =20 Making a cell phone a full peer eliminates this distinction to a large degree since the overlay maintenance messages keep the phone = =91talking=92 all the time. =20 Henry =20 _____ =20 From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Wednesday, June 27, 2007 10:06 AM To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 I don=92t know anything about mobile application design vis-=E0-vis = battery life, but I=92m guessing power usage could be vastly oversimplified to something like: =20 Power =3D A + nB =20 Where A is the overall cost of just having the device powered on and listening to the radio, and B is the cost of sending a byte of data. = What I=92m wondering is, what is the ratio of A to B? Can anyone give = real-world data? =20 For example, I=92d accept that sending 200Mbps probably requires about = 2x the power 100Mbps: for a high enough value of =91n=92, then the constant A = gets marginalized. But what about 200Kbps or 200bps? For some low value of = =91n=92, then A dominates the power usage. =20 The reason I ask is I wonder if it=92s even useful to discuss power = usage for something like P2PSIP. It could be that even for a =93real=94 peer, = =91n=92 is so low that the power consumption is dominated by other factors, rendering = the entire discussion moot. =20 Can anybody give real-world data on this topic? =20 -david=20 =20 _____ =20 From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] = Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that have slow = CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and = some accessing resources stored in DHT using a client protocol. Marcin _____ =20 From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =20 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the actual requirements. We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer = protocol. For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. =20 =20 Perhaps an energy-limited device could just minimize the number of peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual peer in the case = of known DHT algorithms.=20 =20 Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest performance from it. I am not quite sure I understand the benefit of introducing such various levels of participation. Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.=20 Thanks. Eunsoo =20 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about = the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and non-contributing = > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > >> My concern all along has been that I don't understand why something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets pick = a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------=_NextPart_000_00D2_01C7B8D1.A408E330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

That makes sense.=A0 So my next = question is: what are the capabilities of standby mode, and what triggers it going = into “talk” mode?

 

It must be listening to some sort = of cell signal even in standby mode, just so it can receive phone calls.=A0 = Given this, when in standby mode, does it also have access to the IP network?=A0 In = other words, is it possible to have a phone in low-power standby mode but (for example) listening for incoming TCP connections or UDP = packets?

 

-david

 

From: Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 27, = 2007 1:39 PM
To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com
Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

It is more complicated than = this.

Under normal cell phone operation = we have the talk time and the standby time which is much = longer.

 

Making a cell phone a full peer = eliminates this distinction to a large = degree since the overlay maintenance messages keep the phone = ‘talking’ all the time.

 

Henry

 

From: David = Barrett [mailto:dbarrett@quinthar.com]
Sent: Wednesday, June 27, = 2007 10:06 AM
To: = marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

I don’t know anything about = mobile application design vis-=E0-vis battery life, but I’m guessing = power usage could be vastly oversimplified to something = like:

 

Power =3D A + = nB

 

Where A is the overall cost of just = having the device powered on and listening to the radio, and B is the cost of = sending a byte of data.  What I’m wondering is, what is the ratio of = A to B?  Can anyone give real-world data?

 

For example, I’d accept that = sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough = value of ‘n’, then the constant A gets marginalized.  But what about 200Kbps or 200bps?  For some low value of = ‘n’, then A dominates the power usage.

 

The reason I ask is I wonder if = it’s even useful to discuss power usage for something like P2PSIP.  It = could be that even for a “real” peer, ‘n’ is so low that = the power consumption is dominated by other factors, rendering the entire = discussion moot.

 

Can anybody give real-world data on = this topic?

 

-david =

 

From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]
Sent: Wednesday, June 27, = 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; = AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

Hi,

 

We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices = are very powerful. From this reason some of mobile terminals may become = peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that = have slow CPUs and limited memory. 

Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is = calling/answering a call).

    

I was considering a similar = solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We = also have problems with handling searches.

 

I assume that we will = have some mobile terminals taking part in DHT and some accessing resources stored = in DHT using a client protocol.


Marcin

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com] =
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; = Avshalom Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do = we need a client protocol?

 

On 6/26/07, Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought lately, thinking about = the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer = protocol.

For example, a normal peer in the overlay will maintain peer = protocol
connections with many (perhaps dozens) of = peers.  Why?  So that it can
quickly and efficiently route requests within the = overlay.

 

=

 

Perhaps an energy-limited device could just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests = through the
overlay, but that seems like a reasonable tradeoff. =


The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for adjustment. I = don't think it is under complete control of individual peer in the case of = known DHT algorithms.

=

 

Also, perhaps there are some other peer protocol functions, such = as data
replication (storage would still be done, but not replication), that =
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that = those peers
who contribute the least to the overlay also get the lowest = performance
from it.



I am not quite sure I understand the benefit of introducing such various = levels of participation.
Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.

Thanks.

Eunsoo

=

 

Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care = about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than = active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If = so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store = resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It = certainly
> seems that a peer that moves between contributing and = non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into = the
> DHT "right now" might determine whether it is = contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why = something
>> is a peer if it isn't doing anything other than talking to = someone
>> and making requests, hence why I supported client in the first = place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. = It
>> seems completely not in keeping with the idea of P2P. I also = worry it
>>  is likely to be very confusing since we've been = using the other
>> terminology for over a year now. Just looks like a souce of = confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish = to
> contribute resources, and sometimes not have a high-bandwidth = connection
> and therefore not wish to offer resources. Does this modality make = it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the = overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would = I be
>> contributing? If joining the overlay (in the sense that we have = a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer = no
>>
> services
>
> That's "offer no other services", since routing is itself = a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and = a
>> "non-contributing peer" who isn't even part of the = overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For = most DHT models,
> a minimally contributing node will route a request it receives. It = might
> ask nicely (perhaps a q-value mechanism) to not have to route = requests,
> but would probably mathematically still have to route something it = gets.
>
> I think we distinguish based on the service advertisements from = the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets = pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely = peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore = change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

 

------=_NextPart_000_00D2_01C7B8D1.A408E330-- --===============2044920179== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2044920179==-- From p2psip-bounces@ietf.org Wed Jun 27 22:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3k5z-0003FZ-EU; Wed, 27 Jun 2007 22:50:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3k5y-0003FU-0k for p2psip@ietf.org; Wed, 27 Jun 2007 22:50:58 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3k5M-0001EC-JU for p2psip@ietf.org; Wed, 27 Jun 2007 22:50:55 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 7FBC311DB6BB for ; Thu, 28 Jun 2007 10:50:09 +0800 (CST) Message-ID: <003801c7b92f$09ced5a0$a507740a@DELLWEI> From: "Wei Gengyu" To: References: Subject: Re: [P2PSIP] do we need a client protocol? Date: Thu, 28 Jun 2007 10:49:57 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: 935fcc3d6c448ae30077dce3cfc94471 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0606219145==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0606219145== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C7B972.1171CEF0" This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C7B972.1171CEF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpBIGNlbGwgcGhvbmUgaGF2ZSBmdWxsIHJlY2VpdmluZyBjYXBhYmlsaXRpZXMgaW4g c3RhbmRieSBtb2RlLg0KVGhlIGNlbGwgcGhvbmUgd2lsbCBlbnRlciB0aGUgYWN0aXZlIG1vZGUg KHlvdSBzYWlkICJ0YWxrIiBtb2RlKSANCmFmdGVyIHJlY2VpdmluZyBhIHBhZ2luZyBmcmFtZSBj b250YWluaW5nICJzZXR1cCIgbWVzc2FnZSBkZXN0aW5lZCB0byBpdC4gDQoNCkluIHN0YW5kYnkg bW9kZSwgaXQgY2FuIGxpc3RlbiBhbnkgbWVzc2FnZXMgb2Ygc2lnbmFsbGluZyBhbmQvb3IgSVAg cGFja2V0cy4NClNvLCB5ZXMgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSBhIHBob25lIGluIGxvdy1w b3dlciBzdGFuZGJ5IG1vZGUgYnV0IChmb3IgZXhhbXBsZSkgbGlzdGVuaW5nIGZvciBpbmNvbWlu ZyBUQ1AgY29ubmVjdGlvbnMgb3IgVURQIHBhY2tldHMuDQoNCkhvd2V2ZXIsIHRoZSBwb3dlciBj b25zdW1wdGlvbiB0byBzZW5kIG1lc3NhZ2VzIGlzIG1vc3RseSBjb252ZXJuZWQgd2hlbiB0aGUg Y2VsbCBwaG9uZSBpcyBpbiBhY3RpdmUgbW9kZS4gDQoNCkJ1dCwgSSBkbyBub3QgdGhpbmsgdGhp cyBzaG91bGQgYmUgZG9taW5hdGUgUDJQU0lQIG92ZXJsYXkgZGVzaWduIGluIHRoaXMgc3RhZ2Uu DQoNCg0KR2VuZ3l1DQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IERh dmlkIEJhcnJldHQgDQogIFRvOiAnSGVucnkgU2lubnJlaWNoJyA7IG1hcmNpbi5tYXR1c3pld3Nr aUBub2tpYS5jb20gOyBldW5zb29zaGltQGdtYWlsLmNvbSA7IGFsYW5Ac2lwc3RhdGlvbi5jb20g DQogIENjOiBBVlNIQUxPTUBpbC5pYm0uY29tIDsgcGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIDsg cDJwc2lwQGlldGYub3JnIA0KICBTZW50OiBUaHVyc2RheSwgSnVuZSAyOCwgMjAwNyA2OjQxIEFN DQogIFN1YmplY3Q6IFJFOiBbUDJQU0lQXSBkbyB3ZSBuZWVkIGEgY2xpZW50IHByb3RvY29sPw0K DQoNCiAgVGhhdCBtYWtlcyBzZW5zZS4gIFNvIG15IG5leHQgcXVlc3Rpb24gaXM6IHdoYXQgYXJl IHRoZSBjYXBhYmlsaXRpZXMgb2Ygc3RhbmRieSBtb2RlLCBhbmQgd2hhdCB0cmlnZ2VycyBpdCBn b2luZyBpbnRvICJ0YWxrIiBtb2RlPw0KDQogICANCg0KICBJdCBtdXN0IGJlIGxpc3RlbmluZyB0 byBzb21lIHNvcnQgb2YgY2VsbCBzaWduYWwgZXZlbiBpbiBzdGFuZGJ5IG1vZGUsIGp1c3Qgc28g aXQgY2FuIHJlY2VpdmUgcGhvbmUgY2FsbHMuICBHaXZlbiB0aGlzLCB3aGVuIGluIHN0YW5kYnkg bW9kZSwgZG9lcyBpdCBhbHNvIGhhdmUgYWNjZXNzIHRvIHRoZSBJUCBuZXR3b3JrPyAgSW4gb3Ro ZXIgd29yZHMsIGlzIGl0IHBvc3NpYmxlIHRvIGhhdmUgYSBwaG9uZSBpbiBsb3ctcG93ZXIgc3Rh bmRieSBtb2RlIGJ1dCAoZm9yIGV4YW1wbGUpIGxpc3RlbmluZyBmb3IgaW5jb21pbmcgVENQIGNv bm5lY3Rpb25zIG9yIFVEUCBwYWNrZXRzPw0KDQogICANCg0KICAtZGF2aWQNCg0KICAgDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgRnJvbTogSGVucnkgU2lubnJlaWNoIFttYWlsdG86 aHNpbm5yZWlAYWRvYmUuY29tXSANCiAgU2VudDogV2VkbmVzZGF5LCBKdW5lIDI3LCAyMDA3IDE6 MzkgUE0NCiAgVG86IERhdmlkIEJhcnJldHQ7IG1hcmNpbi5tYXR1c3pld3NraUBub2tpYS5jb207 IGV1bnNvb3NoaW1AZ21haWwuY29tOyBhbGFuQHNpcHN0YXRpb24uY29tDQogIENjOiBBVlNIQUxP TUBpbC5pYm0uY29tOyBwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2E7IHAycHNpcEBpZXRmLm9yZw0K ICBTdWJqZWN0OiBSRTogW1AyUFNJUF0gZG8gd2UgbmVlZCBhIGNsaWVudCBwcm90b2NvbD8NCg0K ICAgDQoNCiAgSXQgaXMgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoaXMuDQoNCiAgVW5kZXIgbm9y bWFsIGNlbGwgcGhvbmUgb3BlcmF0aW9uIHdlIGhhdmUgdGhlIHRhbGsgdGltZSBhbmQgdGhlIHN0 YW5kYnkgdGltZSB3aGljaCBpcyBtdWNoIGxvbmdlci4NCg0KICAgDQoNCiAgTWFraW5nIGEgY2Vs bCBwaG9uZSBhIGZ1bGwgcGVlciBlbGltaW5hdGVzIHRoaXMgZGlzdGluY3Rpb24gdG8gYSBsYXJn ZSBkZWdyZWUgc2luY2UgdGhlIG92ZXJsYXkgbWFpbnRlbmFuY2UgbWVzc2FnZXMga2VlcCB0aGUg cGhvbmUgJ3RhbGtpbmcnIGFsbCB0aGUgdGltZS4NCg0KICAgDQoNCiAgSGVucnkNCg0KICAgDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgRnJvbTogRGF2aWQgQmFycmV0dCBbbWFpbHRv OmRiYXJyZXR0QHF1aW50aGFyLmNvbV0gDQogIFNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyNywgMjAw NyAxMDowNiBBTQ0KICBUbzogbWFyY2luLm1hdHVzemV3c2tpQG5va2lhLmNvbTsgZXVuc29vc2hp bUBnbWFpbC5jb207IGFsYW5Ac2lwc3RhdGlvbi5jb20NCiAgQ2M6IEhlbnJ5IFNpbm5yZWljaDsg QVZTSEFMT01AaWwuaWJtLmNvbTsgcGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhOyBwMnBzaXBAaWV0 Zi5vcmcNCiAgU3ViamVjdDogUkU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9j b2w/DQoNCiAgIA0KDQogIEkgZG9uJ3Qga25vdyBhbnl0aGluZyBhYm91dCBtb2JpbGUgYXBwbGlj YXRpb24gZGVzaWduIHZpcy3gLXZpcyBiYXR0ZXJ5IGxpZmUsIGJ1dCBJJ20gZ3Vlc3NpbmcgcG93 ZXIgdXNhZ2UgY291bGQgYmUgdmFzdGx5IG92ZXJzaW1wbGlmaWVkIHRvIHNvbWV0aGluZyBsaWtl Og0KDQogICANCg0KICBQb3dlciA9IEEgKyBuQg0KDQogICANCg0KICBXaGVyZSBBIGlzIHRoZSBv dmVyYWxsIGNvc3Qgb2YganVzdCBoYXZpbmcgdGhlIGRldmljZSBwb3dlcmVkIG9uIGFuZCBsaXN0 ZW5pbmcgdG8gdGhlIHJhZGlvLCBhbmQgQiBpcyB0aGUgY29zdCBvZiBzZW5kaW5nIGEgYnl0ZSBv ZiBkYXRhLiAgV2hhdCBJJ20gd29uZGVyaW5nIGlzLCB3aGF0IGlzIHRoZSByYXRpbyBvZiBBIHRv IEI/ICBDYW4gYW55b25lIGdpdmUgcmVhbC13b3JsZCBkYXRhPw0KDQogICANCg0KICBGb3IgZXhh bXBsZSwgSSdkIGFjY2VwdCB0aGF0IHNlbmRpbmcgMjAwTWJwcyBwcm9iYWJseSByZXF1aXJlcyBh Ym91dCAyeCB0aGUgcG93ZXIgMTAwTWJwczogZm9yIGEgaGlnaCBlbm91Z2ggdmFsdWUgb2YgJ24n LCB0aGVuIHRoZSBjb25zdGFudCBBIGdldHMgbWFyZ2luYWxpemVkLiAgQnV0IHdoYXQgYWJvdXQg MjAwS2JwcyBvciAyMDBicHM/ICBGb3Igc29tZSBsb3cgdmFsdWUgb2YgJ24nLCB0aGVuIEEgZG9t aW5hdGVzIHRoZSBwb3dlciB1c2FnZS4NCg0KICAgDQoNCiAgVGhlIHJlYXNvbiBJIGFzayBpcyBJ IHdvbmRlciBpZiBpdCdzIGV2ZW4gdXNlZnVsIHRvIGRpc2N1c3MgcG93ZXIgdXNhZ2UgZm9yIHNv bWV0aGluZyBsaWtlIFAyUFNJUC4gIEl0IGNvdWxkIGJlIHRoYXQgZXZlbiBmb3IgYSAicmVhbCIg cGVlciwgJ24nIGlzIHNvIGxvdyB0aGF0IHRoZSBwb3dlciBjb25zdW1wdGlvbiBpcyBkb21pbmF0 ZWQgYnkgb3RoZXIgZmFjdG9ycywgcmVuZGVyaW5nIHRoZSBlbnRpcmUgZGlzY3Vzc2lvbiBtb290 Lg0KDQogICANCg0KICBDYW4gYW55Ym9keSBnaXZlIHJlYWwtd29ybGQgZGF0YSBvbiB0aGlzIHRv cGljPw0KDQogICANCg0KICAtZGF2aWQgDQoNCiAgIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQogIEZyb206IG1hcmNpbi5tYXR1c3pld3NraUBub2tpYS5jb20gW21haWx0bzptYXJjaW4u bWF0dXN6ZXdza2lAbm9raWEuY29tXSANCiAgU2VudDogV2VkbmVzZGF5LCBKdW5lIDI3LCAyMDA3 IDEyOjMzIEFNDQogIFRvOiBldW5zb29zaGltQGdtYWlsLmNvbTsgYWxhbkBzaXBzdGF0aW9uLmNv bQ0KICBDYzogaHNpbm5yZWlAYWRvYmUuY29tOyBBVlNIQUxPTUBpbC5pYm0uY29tOyBwaGlsaXBf bWF0dGhld3NAbWFnbWEuY2E7IHAycHNpcEBpZXRmLm9yZw0KICBTdWJqZWN0OiBSRTogW1AyUFNJ UF0gZG8gd2UgbmVlZCBhIGNsaWVudCBwcm90b2NvbD8NCg0KICAgDQoNCiAgSGksDQoNCiAgIA0K DQogIFdlIGhhdmUgd2lkZSB2YXJpZXR5IG9mIG1vYmlsZSB0ZXJtaW5hbHMuIFRoZSBjYXBhYmls aXRpZXMgb2YgbW9iaWxlIHRlcm1pbmFscyBhcmUgY29uc3RhbnRseSBpbXByb3ZpbmcgZS5nLiBl dmVuIG5vdyBOb2tpYSdzIE4tc2VyaWVzL0Utc2VyaWVzIGRldmljZXMgYXJlIHZlcnkgcG93ZXJm dWwuIEZyb20gdGhpcyByZWFzb24gc29tZSBvZiBtb2JpbGUgdGVybWluYWxzIG1heSBiZWNvbWUg cGVlcnMgKGRlcGVuZGluZyBvbiB0aGUgY2FzZSBzY2VuYXJpbzogY2h1cm4sIHNpemUgb2YgdGhl IG5ldHdvcmspLiBIb3dldmVyIHRoZXJlIGFyZSBhbHNvIG1hbnkgZW50cnktbGV2ZWwvbG93LWVu ZCBkZXZpY2VzIHRoYXQgaGF2ZSBzbG93IENQVXMgYW5kIGxpbWl0ZWQgbWVtb3J5LiANCg0KICBC YXR0ZXJ5IGxpZmUgaXMgYW5vdGhlciBpc3N1ZS4gTW9zdCBvZiB0aGUgbW9iaWxlIHBob25lIHVz ZXJzIHdhbnQgbG9uZyBiYXR0ZXJ5IGxpZmUuIERIVCBtYWludGVuYW5jZSBhbmQgaGFuZGxpbmcg c2VhcmNoZXMgaGF2ZSBpbXBhY3Qgb24gaWRsZSBzdGF0ZSB0aGF0IGlzIG1vcmUgaW1wb3J0YW50 IGZyb20gYmF0dGVyeSBsaWZlIHBlcnNwZWN0aXZlIHRoYW4gdGhlIGFjdGl2ZSBzdGF0ZSAoZS5n LiB3aGVuIHVzZXIgaXMgY2FsbGluZy9hbnN3ZXJpbmcgYSBjYWxsKS4NCg0KICAgICAgDQoNCiAg SSB3YXMgY29uc2lkZXJpbmcgYSBzaW1pbGFyIHNvbHV0aW9uIHRvIHRoZSBvbmUgdGhhdCBBbGFu IHByb3Bvc2VkIGhvd2V2ZXIgYXMgRXVuc29vIHNhaWQgaXQgd291bGQgYmUgcXVpdGUgZGlmZmlj dWx0IHRvIGNvbnRyb2wgdGhlIG51bWJlciBvZiBjb25uZWN0aW9ucyBpbiBESFQuIFdlIGFsc28g aGF2ZSBwcm9ibGVtcyB3aXRoIGhhbmRsaW5nIHNlYXJjaGVzLg0KDQogICANCg0KICBJIGFzc3Vt ZSB0aGF0IHdlIHdpbGwgaGF2ZSBzb21lIG1vYmlsZSB0ZXJtaW5hbHMgdGFraW5nIHBhcnQgaW4g REhUIGFuZCBzb21lIGFjY2Vzc2luZyByZXNvdXJjZXMgc3RvcmVkIGluIERIVCB1c2luZyBhIGNs aWVudCBwcm90b2NvbC4NCg0KDQogIE1hcmNpbg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ICAgIEZyb206IGV4dCBFdW5zb28gU2hpbSBbbWFpbHRvOmV1bnNvb3NoaW1AZ21haWwuY29tXSAN CiAgICBTZW50OiAyNyBKdW5lLCAyMDA3IDAyOjI2DQogICAgVG86IEFsYW4gSm9obnN0b24NCiAg ICBDYzogSGVucnkgU2lubnJlaWNoOyBBdnNoYWxvbSBIb3VyaTsgUGhpbGlwIE1hdHRoZXdzOyBQ MlBTSVAgTWFpbGluZyBMaXN0DQogICAgU3ViamVjdDogUmU6IFtQMlBTSVBdIGRvIHdlIG5lZWQg YSBjbGllbnQgcHJvdG9jb2w/DQoNCiAgICAgDQoNCiAgICBPbiA2LzI2LzA3LCBBbGFuIEpvaG5z dG9uIDxhbGFuQHNpcHN0YXRpb24uY29tPiB3cm90ZTogDQoNCiAgICBJJ3ZlIGJlZW4gZ2l2aW5n IHRoaXMgYSBsb3Qgb2YgdGhvdWdodCBsYXRlbHksIHRoaW5raW5nIGFib3V0IHRoZSBhY3R1YWwN CiAgICByZXF1aXJlbWVudHMuDQoNCiAgICBXZSB3YW50IHRvIGFsbG93IGVuZXJneS1saW1pdGVk IGRldmljZXMgdG8gcGFydGljaXBhdGUgdG8gc29tZSBsZXZlbCBpbg0KICAgIFAyUFNJUC4gICBB cyBzdWNoLCBwZXJoYXBzIGluc3RlYWQgb2Ygc2F5aW5nIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9j b2wsIA0KICAgIHBlcmhhcHMgd2UganVzdCBuZWVkIGxldmVscyBvZiBwYXJ0aWNpcGF0aW9uIGlu IHRoZSBvdmVybGF5IHBlZXIgcHJvdG9jb2wuDQoNCiAgICBGb3IgZXhhbXBsZSwgYSBub3JtYWwg cGVlciBpbiB0aGUgb3ZlcmxheSB3aWxsIG1haW50YWluIHBlZXIgcHJvdG9jb2wNCiAgICBjb25u ZWN0aW9ucyB3aXRoIG1hbnkgKHBlcmhhcHMgZG96ZW5zKSBvZiBwZWVycy4gIFdoeT8gIFNvIHRo YXQgaXQgY2FuIA0KICAgIHF1aWNrbHkgYW5kIGVmZmljaWVudGx5IHJvdXRlIHJlcXVlc3RzIHdp dGhpbiB0aGUgb3ZlcmxheS4NCg0KICAgICANCg0KICAgICAgIA0KDQogICAgICBQZXJoYXBzIGFu IGVuZXJneS1saW1pdGVkIGRldmljZSBjb3VsZCBqdXN0IG1pbmltaXplIHRoZSBudW1iZXIgb2Yg cGVlcg0KICAgICAgcHJvdG9jb2wgY29ubmVjdGlvbnMgaXQgbWFpbnRhaW5zLCBwZXJoYXBzIGV2 ZW4gZG93biB0byBhIG1pbmltdW0gb2YNCiAgICAgIHR3by4gIFRoaXMgd291bGQgcmVzdWx0IGlu IHNsb3dlciByb3V0aW5nIG9mIGl0cyByZXF1ZXN0cyB0aHJvdWdoIHRoZQ0KICAgICAgb3Zlcmxh eSwgYnV0IHRoYXQgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgdHJhZGVvZmYuIA0KDQoNCiAgICBU aGUgdW5kZXJsaW5nIGFsZ29yaXRobSAoZS5nLiBhIGNlcnRhaW4gREhUIGFsZ29yaXRobSkgd2ls bCBkaWN0YXRlIHRoZSBudW1iZXIgb2YgY29ubmVjdGlvbnMgZXZlbiB0aG91Z2ggdGhlcmUgbWln aHQgYmUgc29tZSByb29tIGZvciBhZGp1c3RtZW50LiBJIGRvbid0IHRoaW5rIGl0IGlzIHVuZGVy IGNvbXBsZXRlIGNvbnRyb2wgb2YgaW5kaXZpZHVhbCBwZWVyIGluIHRoZSBjYXNlIG9mIGtub3du IERIVCBhbGdvcml0aG1zLiANCg0KICAgICAgIA0KDQogICAgICBBbHNvLCBwZXJoYXBzIHRoZXJl IGFyZSBzb21lIG90aGVyIHBlZXIgcHJvdG9jb2wgZnVuY3Rpb25zLCBzdWNoIGFzIGRhdGENCiAg ICAgIHJlcGxpY2F0aW9uIChzdG9yYWdlIHdvdWxkIHN0aWxsIGJlIGRvbmUsIGJ1dCBub3QgcmVw bGljYXRpb24pLCB0aGF0IA0KICAgICAgY291bGQgYmUgc2tpcHBlZCBieSB0aGVzZSBlbmVyZ3kt bGltaXRlZCBwZWVycy4gIFBlcmhhcHMgdGhlaXIgcmVxdWVzdHMNCiAgICAgIGFuZCByZXNwb25z ZXMgY291bGQgYmUgcm91dGVkIG92ZXIgdGhlIG92ZXJsYXkgd2l0aCBhIGxvd2VyIHByaW9yaXR5 DQogICAgICB0aGFuIGZ1bGwgcGVlcnMuICBXZSBuZWVkIHRvIG1hbmFnZSB0aGUgdHJhZGVvZmZz IHNvIHRoYXQgdGhvc2UgcGVlcnMNCiAgICAgIHdobyBjb250cmlidXRlIHRoZSBsZWFzdCB0byB0 aGUgb3ZlcmxheSBhbHNvIGdldCB0aGUgbG93ZXN0IHBlcmZvcm1hbmNlDQogICAgICBmcm9tIGl0 Lg0KDQoNCg0KICAgIEkgYW0gbm90IHF1aXRlIHN1cmUgSSB1bmRlcnN0YW5kIHRoZSBiZW5lZml0 IG9mIGludHJvZHVjaW5nIHN1Y2ggdmFyaW91cyBsZXZlbHMgb2YgcGFydGljaXBhdGlvbi4NCiAg ICBIYXZpbmcgYSBjbGllbnQgcHJvdG9jb2wgc2VlbXMgdG8gYmUgbXVjaCBzaW1wbGVyIGFuZCBl YXNpZXIgdGhhbiBpbnRyb2R1Y2luZyB0aGVzZSB2YXJpb3VzIGxldmVscyBvZiBwYXJ0aWNpcGF0 aW9uLiANCg0KICAgIFRoYW5rcy4NCg0KICAgIEV1bnNvbw0KDQogICAgICAgDQoNCiAgICAgIEhl bnJ5IFNpbm5yZWljaCB3cm90ZToNCiAgICAgID4gRm9sa3MsDQogICAgICA+IA0KICAgICAgPiBH aXZlbiB0aGUgbGVuZ3RoIG9mIHRoZSBkaXNjdXNzaW9uIG9uICJkbyB3ZSBuZWVkIGEgY2xpZW50 IHByb3RvY29sPyINCiAgICAgID4gbGV0IG1lIHJlcGVhdCB0aGUgc2ltcGxlIGltcGVyYXRpdmVz IGZvciB0aGUgY2xpZW50Og0KICAgICAgPg0KICAgICAgPiAtIExpbWl0ZWQgYmF0dGVyeSBpbiBt b2JpbGUgZGV2aWNlcywgYW5kDQogICAgICA+DQogICAgICA+IC0gT3RoZXIgdXNlcyBiZXNpZGVz IFNJUC4gQnVzaW5lc3MgcGxhbm5pbmcgZm9sa3MgbWF5IG5vdCBjYXJlIGFib3V0IHRoZSANCiAg ICAgID4gV0cgY2hhcnRlciwgYnV0IGFib3V0IHRoZSByZXR1cm4gb24gdGhlIGludmVzdG1lbnQu DQogICAgICA+DQogICAgICA+IFRoYW5rcywgSGVucnkNCiAgICAgID4NCiAgICAgID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICAgID4gRnJvbTogRGVhbiBXaWxsaXMgW21haWx0bzpk ZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tIF0NCiAgICAgID4gU2VudDogVGh1cnNkYXksIEp1bmUg MTQsIDIwMDcgMTE6MjMgUE0NCiAgICAgID4gVG86IERhdmlkIEEuIEJyeWFuDQogICAgICA+IENj OiBBdnNoYWxvbSBIb3VyaTsgUDJQU0lQIE1haWxpbmcgTGlzdDsgUGhpbGlwIE1hdHRoZXdzDQog ICAgICA+IFN1YmplY3Q6IFJlOiBbUDJQU0lQXSBDb25jZXB0cyBkb2N1bWVudDogcHJvcG9zYWwg Zm9yIGFjdGl2ZS9wYXNzaXZlIA0KICAgICAgPiBwZWVydGVybWlub2xvZ3kNCiAgICAgID4NCiAg ICAgID4gRGF2aWQgQS4gQnJ5YW4gd3JvdGU6DQogICAgICA+DQogICAgICA+PiBJZiBJIHVuZGVy c3RhbmQgdGhpcyByaWdodCwgbm90IHN1cmUgSSBsaWtlIGl0LiBEbyB0aGVzZQ0KICAgICAgPj4N CiAgICAgID4gIm5vbi1jb250cmlidXRpbmcNCiAgICAgID4NCiAgICAgID4+IHBlZXIiIChJICpk byogbGlrZSBjb250cmlidXRpbmcgYmV0dGVyIHRoYW4gYWN0aXZlL3Bhc3NpdmUpIGVudGl0aWVz IA0KICAgICAgPj4NCiAgICAgID4gaGF2ZSBhDQogICAgICA+DQogICAgICA+PiBQZWVyLUlEPyBJ biBvdGhlcndvcmRzLCBhcmUgdGhleSBwYXJ0IG9mIHRoZSBvdmVybGF5IGF0IGFsbD8gSWYgc28s DQogICAgICA+Pg0KICAgICAgPiBmb3INCiAgICAgID4NCiAgICAgID4+IG1vc3QNCiAgICAgID4+ IERIVHMsIGhvdyBkbyB3ZSBhbGxvdyB5b3UgdG8gYmUgaW4gdGhlIG92ZXJsYXkgYW5kIG5vdCBz dG9yZSByZXNvdXJjZXMgDQogICAgICA+Pg0KICAgICAgPiAobm90DQogICAgICA+DQogICAgICA+ PiB0eXBpY2FsIGZvciBtb3N0IGN1cnJlbnQgREhUIGFsZ29yaXRobXMpDQogICAgICA+Pg0KICAg ICAgPg0KICAgICAgPiBXZWxsLCB0aGF0IGNlcnRhaW5seSBkZXBlbmRzIG9uIHRoZSBESFQgYWxn b3JpdGhtIGludm9sdmVkLiBJdCBjZXJ0YWlubHkNCiAgICAgID4gc2VlbXMgdGhhdCBhIHBlZXIg dGhhdCBtb3ZlcyBiZXR3ZWVuIGNvbnRyaWJ1dGluZyBhbmQgbm9uLWNvbnRyaWJ1dGluZyANCiAg ICAgID4gbWlnaHQgSEFWRSBhIHBlZXIgSUQsIGJ1dCB3aGV0aGVyIGl0IGNob29zZXMgdG8gaW5z ZXJ0IGl0c2VsZiBpbnRvIHRoZQ0KICAgICAgPiBESFQgInJpZ2h0IG5vdyIgbWlnaHQgZGV0ZXJt aW5lIHdoZXRoZXIgaXQgaXMgY29udHJpYnV0aW5nICJyaWdodCBub3ciDQogICAgICA+IG9yIG5v dC4NCiAgICAgID4NCiAgICAgID4NCiAgICAgID4+IE15IGNvbmNlcm4gYWxsIGFsb25nIGhhcyBi ZWVuIHRoYXQgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSBzb21ldGhpbmcgDQogICAgICA+PiBpcyBh IHBlZXIgaWYgaXQgaXNuJ3QgZG9pbmcgYW55dGhpbmcgb3RoZXIgdGhhbiB0YWxraW5nIHRvIHNv bWVvbmUNCiAgICAgID4+IGFuZCBtYWtpbmcgcmVxdWVzdHMsIGhlbmNlIHdoeSBJIHN1cHBvcnRl ZCBjbGllbnQgaW4gdGhlIGZpcnN0IHBsYWNlLg0KICAgICAgPj4gIEkgZmFpbCB0byBzZWUgaG93 IHNvbWV0aGluZyB0aGF0IGlzbid0IGNvbnRyaWJ1dGluZyBhbnl0aGluZywgYW5kIA0KICAgICAg Pj4gaW5zdGVhZCB0YWxrcyB0byBhIHBlZXIgdG8gZ2V0IHJlc291cmNlcywgaXMgaW4gYW55IHdh eSBhIHBlZXIuIEl0DQogICAgICA+PiBzZWVtcyBjb21wbGV0ZWx5IG5vdCBpbiBrZWVwaW5nIHdp dGggdGhlIGlkZWEgb2YgUDJQLiBJIGFsc28gd29ycnkgaXQNCiAgICAgID4+ICBpcyBsaWtlbHkg dG8gYmUgdmVyeSBjb25mdXNpbmcgc2luY2Ugd2UndmUgYmVlbiB1c2luZyB0aGUgb3RoZXIgDQog ICAgICA+PiB0ZXJtaW5vbG9neSBmb3Igb3ZlciBhIHllYXIgbm93LiBKdXN0IGxvb2tzIGxpa2Ug YSBzb3VjZSBvZiBjb25mdXNpb24uDQogICAgICA+Pg0KICAgICAgPg0KICAgICAgPiBBIG5vZGUg bWlnaHQgc29tZXRpbWVzIGhhdmUgYSBoaWdoLWJhbmR3aWR0aCBjb25uZWN0aW9uIGFuZCB3aXNo IHRvDQogICAgICA+IGNvbnRyaWJ1dGUgcmVzb3VyY2VzLCBhbmQgc29tZXRpbWVzIG5vdCBoYXZl IGEgaGlnaC1iYW5kd2lkdGggY29ubmVjdGlvbiANCiAgICAgID4gYW5kIHRoZXJlZm9yZSBub3Qg d2lzaCB0byBvZmZlciByZXNvdXJjZXMuIERvZXMgdGhpcyBtb2RhbGl0eSBtYWtlIGl0DQogICAg ICA+IHR3byBkaWZmZXJlbnQgbm9kZXM/DQogICAgICA+DQogICAgICA+DQogICAgICA+PiBJZiB3 ZSBkbyBnbyB0aGlzIHdheSwgdGhlcmUgaXMgb25lIHN1YnRsZSBwb2ludC4gSWYgSSBqb2luIHRo ZSBvdmVybGF5DQogICAgICA+Pg0KICAgICAgPiBidXQNCiAgICAgID4NCiAgICAgID4+IGRvbid0 IGhhcHBlbiB0byBvZmZlciBhbnkgc2VydmljZXMgKG90aGVyIHRoYW4gbWF5YmUNCiAgICAgID4+ DQogICAgICA+IHN0b3JhZ2UuLi5kZXBlbmRpbmcgb24NCiAgICAgID4NCiAgICAgID4+IGhvdyB3 ZSBkZWZpbmllIGl0LCB0aGF0IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBtYW5kYXRvcnkpLCB3b3Vs ZCBJIGJlDQogICAgICA+PiBjb250cmlidXRpbmc/IElmIGpvaW5pbmcgdGhlIG92ZXJsYXkgKGlu IHRoZSBzZW5zZSB0aGF0IHdlIGhhdmUgYQ0KICAgICAgPj4NCiAgICAgID4gUGVlcklEDQogICAg ICA+DQogICAgICA+PiBhbmQNCiAgICAgID4+IHdlIHJvdXRlIHRyYWZmaWMpIGRvZXNuJ3QgcmVx dWlyZSBtZSB0byBzdG9yZSwgSSBjb3VsZCBvZmZlciBubw0KICAgICAgPj4NCiAgICAgID4gc2Vy dmljZXMNCiAgICAgID4NCiAgICAgID4gVGhhdCdzICJvZmZlciBubyBvdGhlciBzZXJ2aWNlcyIs IHNpbmNlIHJvdXRpbmcgaXMgaXRzZWxmIGEgc2VydmljZS4NCiAgICAgID4NCiAgICAgID4NCiAg ICAgID4+IGFuZA0KICAgICAgPj4gc3RpbGwgYmUgYSBwZWVyLiBIb3cgZG8gd2UgZGlzdGluZ3Vp c2ggYmV0d2VlbiB0aGlzIGNhc2UgYW5kIGENCiAgICAgID4+ICJub24tY29udHJpYnV0aW5nIHBl ZXIiIHdobyBpc24ndCBldmVuIHBhcnQgb2YgdGhlIG92ZXJsYXkgKGkuZS4sIG5vDQogICAgICA+ PiBQZWVyLUlEKQ0KICAgICAgPj4NCiAgICAgID4NCiAgICAgID4gSSB0aGluayB0aGVyZSdzIGEg cmFuZ2Ugb2YgImNvbnRyaWJ1dGluZyIgaW4gcGxheS4gRm9yIG1vc3QgREhUIG1vZGVscywgDQog ICAgICA+IGEgbWluaW1hbGx5IGNvbnRyaWJ1dGluZyBub2RlIHdpbGwgcm91dGUgYSByZXF1ZXN0 IGl0IHJlY2VpdmVzLiBJdCBtaWdodA0KICAgICAgPiBhc2sgbmljZWx5IChwZXJoYXBzIGEgcS12 YWx1ZSBtZWNoYW5pc20pIHRvIG5vdCBoYXZlIHRvIHJvdXRlIHJlcXVlc3RzLA0KICAgICAgPiBi dXQgd291bGQgcHJvYmFibHkgbWF0aGVtYXRpY2FsbHkgc3RpbGwgaGF2ZSB0byByb3V0ZSBzb21l dGhpbmcgaXQgZ2V0cy4gDQogICAgICA+DQogICAgICA+IEkgdGhpbmsgd2UgZGlzdGluZ3Vpc2gg YmFzZWQgb24gdGhlIHNlcnZpY2UgYWR2ZXJ0aXNlbWVudHMgZnJvbSB0aGUNCiAgICAgID4gcGVl ci4NCiAgICAgID4NCiAgICAgID4NCiAgICAgID4+IElmIHdlIGFyZSBzbyBvcHBvc2VkIHRvIGNs aWVudCBmb3IgY29uZnVzaW9uIHdpdGggU0lQIFVBcywgbGV0cyBwaWNrIGENCiAgICAgID4+DQog ICAgICA+IG5ldyANCiAgICAgID4NCiAgICAgID4+IG5hbWUsIGJ1dCB3aHkgc29tZSBmbGF2b3Ig b2YgcGVlciB3aGVuIGl0IGRvZXMgbm90aGluZyByZW1vdGVseSBwZWVyDQogICAgICA+Pg0KICAg ICAgPiBsaWtlPw0KICAgICAgPg0KICAgICAgPiBCZWNhdXNlIGluIDE1IG1pbnV0ZXMgaXQgbWln aHQgcm9hbSBvbnRvIGEgV2lGaSBuZXQgYW5kIHRoZXJlZm9yZSBjaGFuZ2UNCiAgICAgID4gaXQg c2VydmljZSBvZmZlcmluZy4gDQogICAgICA+DQogICAgICA+IC0tDQogICAgICA+IERlYW4NCiAg ICAgID4NCiAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICAgID4gUDJQU0lQIG1haWxpbmcgbGlzdA0KICAgICAgPiBQMlBTSVBAaWV0Zi5v cmcNCiAgICAgID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lw DQogICAgICA+DQogICAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgICA+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCiAgICAgID4gUDJQU0lQQGll dGYub3JnDQogICAgICA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ay cHNpcA0KICAgICAgPg0KICAgICAgPg0KICAgICAgPg0KDQoNCiAgICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICBQMlBTSVAgbWFpbGluZyBs aXN0DQogICAgICBQMlBTSVBAaWV0Zi5vcmcNCiAgICAgIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KDQogICAgIA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCg0KICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KICBQMlBTSVAgbWFpbGluZyBsaXN0DQogIFAyUFNJUEBpZXRmLm9yZw0KICBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCg== ------=_NextPart_000_0035_01C7B972.1171CEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIiB4bWxu czp2ID0gDQoidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm8gPSANCiJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOncgPSANCiJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpzdDEgPSANCiJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVp dj1Db250ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0K PE1FVEEgY29udGVudD0iTVNIVE1MIDYuMDAuMjkwMC4zMTMyIiBuYW1lPUdFTkVSQVRPUj48IS0t W2lmICFtc29dPg0KPFNUWUxFPnZcOiogew0KCUJFSEFWSU9SOiB1cmwoI2RlZmF1bHQjVk1MKQ0K fQ0Kb1w6KiB7DQoJQkVIQVZJT1I6IHVybCgjZGVmYXVsdCNWTUwpDQp9DQp3XDoqIHsNCglCRUhB VklPUjogdXJsKCNkZWZhdWx0I1ZNTCkNCn0NCi5zaGFwZSB7DQoJQkVIQVZJT1I6IHVybCgjZGVm YXVsdCNWTUwpDQp9DQo8L1NUWUxFPg0KPCFbZW5kaWZdLS0+PG86U21hcnRUYWdUeXBlIG5hbWU9 IlBlcnNvbk5hbWUiIA0KbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpzbWFydHRhZ3MiPjwvbzpTbWFydFRhZ1R5cGU+PG86U21hcnRUYWdUeXBlIA0KbmFtZT0i cGxhY2UiIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21h cnR0YWdzIiANCmRvd25sb2FkdXJsPSJodHRwOi8vd3d3LjVpYW50bGF2YWxhbXAuY29tLyI+PC9v OlNtYXJ0VGFnVHlwZT48IS0tW2lmICFtc29dPg0KPFNUWUxFPg0Kc3QxXDoqe2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvU1RZTEU+DQo8IVtlbmRpZl0tLT4NCjxTVFlMRT4NCjwh LS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmlu aXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpBcmlhbDsNCglj b2xvcjpuYXZ5O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkFyaWFsOw0KCWNvbG9yOm5hdnk7fQ0KQHBhZ2UgU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1 aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9I RUFEPg0KPEJPRFkgbGFuZz1FTi1VUyB2TGluaz1ibHVlIGxpbms9Ymx1ZSBiZ0NvbG9yPSNmZmZm ZmY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+SGksIDwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5i c3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+QSBjZWxs IHBob25lIGhhdmUgZnVsbCByZWNlaXZpbmcgPEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAw ODA+Y2FwYWJpbGl0aWVzIGluIHN0YW5kYnkgbW9kZS48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPlRoZSBjZWxsIHBob25lJm5ic3A7 d2lsbCZuYnNwO2VudGVyIHRoZSBhY3RpdmUgDQptb2RlJm5ic3A7KHlvdSBzYWlkICJ0YWxrIiBt b2RlKSA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXpl PTI+YWZ0ZXIgcmVjZWl2aW5nIGEgcGFnaW5nIGZyYW1lIGNvbnRhaW5pbmcgInNldHVwIiANCm1l c3NhZ2UgZGVzdGluZWQgdG8gaXQuJm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5JbiBzdGFuZGJ5IG1vZGUsIGl0IGNhbiBsaXN0 ZW4gYW55IG1lc3NhZ2VzJm5ic3A7b2YgDQpzaWduYWxsaW5nIGFuZC9vciBJUCBwYWNrZXRzLjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5Tbywg eWVzPEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMDgwPiBpdCBpcyBwb3NzaWJsZSANCnRvIGhh dmUgYSBwaG9uZSBpbiBsb3ctcG93ZXIgc3RhbmRieSBtb2RlIGJ1dCAoZm9yIGV4YW1wbGUpIGxp c3RlbmluZyBmb3IgDQppbmNvbWluZyBUQ1AgY29ubmVjdGlvbnMgb3IgVURQIHBhY2tldHMuPC9G T05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBz aXplPTI+SG93ZXZlciwgPC9GT05UPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ dGhlIHBvd2VyIA0KY29uc3VtcHRpb24gdG8gc2VuZCBtZXNzYWdlcyBpcyBtPEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5vc3RseSA8L0ZPTlQ+Y29udmVybmVkIA0Kd2hlbiZuYnNw O3RoZSBjZWxsIHBob25lJm5ic3A7aXMgaW4mbmJzcDthY3RpdmUmbmJzcDttb2RlLiA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZu YnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjxTVFJP Tkc+QnV0LCBJIGRvIG5vdCB0aGluayB0aGlzIHNob3VsZCBiZSBkb21pbmF0ZSANClAyUFNJUCBv dmVybGF5IGRlc2lnbiBpbiB0aGlzIHN0YWdlLjwvU1RST05HPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkdlbmd5dTwvRk9OVD48 L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1M RUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xp ZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQzNTsm IzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHls ZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZvbnQt Y29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPWRiYXJyZXR0QHF1aW50aGFy LmNvbSBocmVmPSJtYWlsdG86ZGJhcnJldHRAcXVpbnRoYXIuY29tIj5EYXZpZCANCiAgQmFycmV0 dDwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48 Qj5Ubzo8L0I+IDxBIHRpdGxlPWhzaW5ucmVpQGFkb2JlLmNvbSANCiAgaHJlZj0ibWFpbHRvOmhz aW5ucmVpQGFkb2JlLmNvbSI+J0hlbnJ5IFNpbm5yZWljaCc8L0E+IDsgPEEgDQogIHRpdGxlPW1h cmNpbi5tYXR1c3pld3NraUBub2tpYS5jb20gDQogIGhyZWY9Im1haWx0bzptYXJjaW4ubWF0dXN6 ZXdza2lAbm9raWEuY29tIj5tYXJjaW4ubWF0dXN6ZXdza2lAbm9raWEuY29tPC9BPiA7IA0KICA8 QSB0aXRsZT1ldW5zb29zaGltQGdtYWlsLmNvbSANCiAgaHJlZj0ibWFpbHRvOmV1bnNvb3NoaW1A Z21haWwuY29tIj5ldW5zb29zaGltQGdtYWlsLmNvbTwvQT4gOyA8QSANCiAgdGl0bGU9YWxhbkBz aXBzdGF0aW9uLmNvbSANCiAgaHJlZj0ibWFpbHRvOmFsYW5Ac2lwc3RhdGlvbi5jb20iPmFsYW5A c2lwc3RhdGlvbi5jb208L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQz NTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1BVlNIQUxPTUBpbC5pYm0uY29tIA0KICBo cmVmPSJtYWlsdG86QVZTSEFMT01AaWwuaWJtLmNvbSI+QVZTSEFMT01AaWwuaWJtLmNvbTwvQT4g OyA8QSANCiAgdGl0bGU9cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIA0KICBocmVmPSJtYWlsdG86 cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIj5waGlsaXBfbWF0dGhld3NAbWFnbWEuY2E8L0E+IDsg PEEgDQogIHRpdGxlPXAycHNpcEBpZXRmLm9yZyBocmVmPSJtYWlsdG86cDJwc2lwQGlldGYub3Jn Ij5wMnBzaXBAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMy MzQzNTsmIzIwMzA3OyI+PEI+U2VudDo8L0I+IFRodXJzZGF5LCBKdW5lIDI4LCAyMDA3IDY6NDEg QU08L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPjxCPlN1 YmplY3Q6PC9CPiBSRTogW1AyUFNJUF0gZG8gd2UgbmVlZCBhIGNsaWVudCANCiAgcHJvdG9jb2w/ PC9ESVY+DQogIDxESVY+PEJSPjwvRElWPg0KICA8RElWIGNsYXNzPVNlY3Rpb24xPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlh bCI+VGhhdCBtYWtlcyANCiAgc2Vuc2UuJm5ic3A7IFNvIG15IG5leHQgcXVlc3Rpb24gaXM6IHdo YXQgYXJlIHRoZSBjYXBhYmlsaXRpZXMgb2Ygc3RhbmRieSANCiAgbW9kZSwgYW5kIHdoYXQgdHJp Z2dlcnMgaXQgZ29pbmcgaW50byCTdGFsa5QgDQptb2RlPzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9O VD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkg c2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9O VC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BB TiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBB cmlhbCI+SXQgbXVzdCBiZSBsaXN0ZW5pbmcgDQogIHRvIHNvbWUgc29ydCBvZiBjZWxsIHNpZ25h bCBldmVuIGluIHN0YW5kYnkgbW9kZSwganVzdCBzbyBpdCBjYW4gcmVjZWl2ZSBwaG9uZSANCiAg Y2FsbHMuJm5ic3A7IEdpdmVuIHRoaXMsIHdoZW4gaW4gc3RhbmRieSBtb2RlLCBkb2VzIGl0IGFs c28gaGF2ZSBhY2Nlc3MgdG8gdGhlIA0KICBJUCBuZXR3b3JrPyZuYnNwOyBJbiBvdGhlciB3b3Jk cywgaXMgaXQgcG9zc2libGUgdG8gaGF2ZSBhIHBob25lIGluIGxvdy1wb3dlciANCiAgc3RhbmRi eSBtb2RlIGJ1dCAoZm9yIGV4YW1wbGUpIGxpc3RlbmluZyBmb3IgaW5jb21pbmcgVENQIGNvbm5l Y3Rpb25zIG9yIFVEUCANCiAgcGFja2V0cz88bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0K ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48 U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0 eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPi1k YXZpZDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1T SVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8RElWIA0KICBzdHlsZT0iQk9SREVSLVJJR0hUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsg UEFERElORy1MRUZUOiA0cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IEJPUkRFUi1MRUZUOiBibHVl IDEuNXB0IHNvbGlkOyBQQURESU5HLVRPUDogMGluOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZSI+DQogIDxESVY+DQogIDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBj ZW50ZXIiIGFsaWduPWNlbnRlcj48Rk9OVCANCiAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl PTM+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+DQogIDxIUiB0YWJJbmRleD0tMSBhbGln bj1jZW50ZXIgd2lkdGg9IjEwMCUiIFNJWkU9Mj4NCiAgPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAg PFAgY2xhc3M9TXNvTm9ybWFsPjxCPjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48U1BBTiANCiAg c3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkOyBGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBU YWhvbWEiPkZyb206PC9TUEFOPjwvRk9OVD48L0I+PEZPTlQgDQogIGZhY2U9VGFob21hIHNpemU9 Mj48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBGT05ULUZBTUlMWTogVGFob21hIj4gSGVu cnkgDQogIFNpbm5yZWljaCBbbWFpbHRvOmhzaW5ucmVpQGFkb2JlLmNvbV0gPEJSPjxCPjxTUEFO IA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlNlbnQ6PC9TUEFOPjwvQj4gV2VkbmVzZGF5 LCBKdW5lIDI3LCAyMDA3IDE6MzkgDQogIFBNPEJSPjxCPjxTUEFOIHN0eWxlPSJGT05ULVdFSUdI VDogYm9sZCI+VG86PC9TUEFOPjwvQj4gRGF2aWQgQmFycmV0dDsgPEEgDQogIGhyZWY9Im1haWx0 bzptYXJjaW4ubWF0dXN6ZXdza2lAbm9raWEuY29tIj5tYXJjaW4ubWF0dXN6ZXdza2lAbm9raWEu Y29tPC9BPjsgDQogIDxBIGhyZWY9Im1haWx0bzpldW5zb29zaGltQGdtYWlsLmNvbSI+ZXVuc29v c2hpbUBnbWFpbC5jb208L0E+OyA8QSANCiAgaHJlZj0ibWFpbHRvOmFsYW5Ac2lwc3RhdGlvbi5j b20iPmFsYW5Ac2lwc3RhdGlvbi5jb208L0E+PEJSPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1X RUlHSFQ6IGJvbGQiPkNjOjwvU1BBTj48L0I+IDxBIA0KICBocmVmPSJtYWlsdG86QVZTSEFMT01A aWwuaWJtLmNvbSI+QVZTSEFMT01AaWwuaWJtLmNvbTwvQT47IDxBIA0KICBocmVmPSJtYWlsdG86 cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhIj5waGlsaXBfbWF0dGhld3NAbWFnbWEuY2E8L0E+OyA8 QSANCiAgaHJlZj0ibWFpbHRvOnAycHNpcEBpZXRmLm9yZyI+cDJwc2lwQGlldGYub3JnPC9BPjxC Uj48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48 L0I+IFJFOiBbUDJQU0lQXSBkbyB3ZSBuZWVkIGEgY2xpZW50IA0KICBwcm90b2NvbD88L1NQQU4+ PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5JdCBp cyBtb3JlIA0KICBjb21wbGljYXRlZCB0aGFuIHRoaXMuPG86cD48L286cD48L1NQQU4+PC9GT05U PjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBz aXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05U LUZBTUlMWTogQXJpYWwiPlVuZGVyIG5vcm1hbCBjZWxsIA0KICBwaG9uZSBvcGVyYXRpb24gd2Ug aGF2ZSB0aGUgdGFsayB0aW1lIGFuZCB0aGUgc3RhbmRieSB0aW1lIHdoaWNoIGlzIG11Y2ggDQog IGxvbmdlci48bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJz cDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPk1ha2luZyBhIGNlbGwgcGhvbmUg YSANCiAgZnVsbCBwZWVyIGVsaW1pbmF0ZXMgdGhpcyBkaXN0aW5jdGlvbiB0byBhIGxhPHN0MTpQ ZXJzb25OYW1lIA0KICB3OnN0PSJvbiI+cmc8L3N0MTpQZXJzb25OYW1lPmUgZGVncmVlIHNpbmNl IHRoZSBvdmVybGF5IG1haW50ZW5hbmNlIG1lc3NhZ2VzIA0KICBrZWVwIHRoZSBwaG9uZSCRdGFs a2luZ5IgYWxsIHRoZSB0aW1lLjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNs YXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0K ICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SGVucnk8bzpw PjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTBw dDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlhbCI+PG86cD4mbmJzcDs8L286cD48L1NQ QU4+PC9GT05UPjwvUD4NCiAgPERJVj4NCiAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRF WFQtQUxJR046IGNlbnRlciIgYWxpZ249Y2VudGVyPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4NCiAgPEhSIHRhYklu ZGV4PS0xIGFsaWduPWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICA8L1NQQU4+PC9GT05U PjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgRk9O VC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgZmFjZT1U YWhvbWEgc2l6ZT0yPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBU YWhvbWEiPiBEYXZpZCANCiAgQmFycmV0dCBbbWFpbHRvOmRiYXJyZXR0QHF1aW50aGFyLmNvbV0g PEJSPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlNlbnQ6PC9TUEFOPjwv Qj4gV2VkbmVzZGF5LCBKdW5lIDI3LCAyMDA3IDEwOjA2IA0KICBBTTxCUj48Qj48U1BBTiBzdHls ZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlRvOjwvU1BBTj48L0I+IA0KICBtYXJjaW4ubWF0dXN6ZXdz a2lAbm9raWEuY29tOyBldW5zb29zaGltQGdtYWlsLmNvbTsgDQogIGFsYW5Ac2lwc3RhdGlvbi5j b208QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5DYzo8L1NQQU4+PC9CPiBI ZW5yeSANCiAgU2lubnJlaWNoOyBBVlNIQUxPTUBpbC5pYm0uY29tOyBwaGlsaXBfbWF0dGhld3NA bWFnbWEuY2E7IA0KICBwMnBzaXBAaWV0Zi5vPHN0MTpQZXJzb25OYW1lIHc6c3Q9Im9uIj5yZzwv c3QxOlBlcnNvbk5hbWU+PEJSPjxCPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQi PlN1YmplY3Q6PC9TUEFOPjwvQj4gUkU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgDQog IHByb3RvY29sPzwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAg c3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwv UD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXpl PTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZB TUlMWTogQXJpYWwiPkkgZG9uknQga25vdyBhbnl0aGluZyANCiAgYWJvdXQgbW9iaWxlIGFwcGxp Y2F0aW9uIGRlc2lnbiB2aXMt4C12aXMgYmF0dGVyeSBsaWZlLCBidXQgSZJtIGd1ZXNzaW5nIHBv d2VyIA0KICB1c2FnZSBjb3VsZCBiZSB2YXN0bHkgb3ZlcnNpbXBsaWZpZWQgdG8gc29tZXRoaW5n IA0KICBsaWtlOjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 IlRFWFQtSU5ERU5UOiAwLjVpbiI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IA0KICBzaXpl PTI+PFNQQU4gc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZ OiBBcmlhbCI+UG93ZXIgPSANCiAgQSArIG5CPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlM WTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNz PU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5X aGVyZSBBIGlzIHRoZSANCiAgb3ZlcmFsbCBjb3N0IG9mIGp1c3QgaGF2aW5nIHRoZSBkZXZpY2Ug cG93ZXJlZCBvbiBhbmQgbGlzdGVuaW5nIHRvIHRoZSByYWRpbywgDQogIGFuZCBCIGlzIHRoZSBj b3N0IG9mIHNlbmRpbmcgYSBieXRlIG9mIGRhdGEuJm5ic3A7IFdoYXQgSZJtIHdvbmRlcmluZyBp cywgd2hhdCANCiAgaXMgdGhlIHJhdGlvIG9mIEEgdG8gQj8mbmJzcDsgQ2FuIGFueW9uZSBnaXZl IHJlYWwtd29ybGQgDQogIGRhdGE/PG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4g DQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJp YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05v cm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0i Rk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5Gb3IgZXhh bXBsZSwgSZJkIA0KICBhY2NlcHQgdGhhdCBzZW5kaW5nIDIwME1icHMgcHJvYmFibHkgcmVxdWly ZXMgYWJvdXQgMnggdGhlIHBvd2VyIDEwME1icHM6IGZvciANCiAgYSBoaWdoIGVub3VnaCB2YWx1 ZSBvZiCRbpIsIHRoZW4gdGhlIGNvbnN0YW50IEEgZ2V0cyBtYTxzdDE6UGVyc29uTmFtZSANCiAg dzpzdD0ib24iPnJnPC9zdDE6UGVyc29uTmFtZT5pbmFsaXplZC4mbmJzcDsgQnV0IHdoYXQgYWJv dXQgMjAwS2JwcyBvciANCiAgMjAwYnBzPyZuYnNwOyBGb3Igc29tZSBsb3cgdmFsdWUgb2YgkW6S LCB0aGVuIEEgZG9taW5hdGVzIHRoZSBwb3dlciANCiAgdXNhZ2UuPG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9 bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5 OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+ DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5hdnkgc2l6ZT0y PjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogbmF2eTsgRk9OVC1GQU1J TFk6IEFyaWFsIj5UaGUgcmVhc29uIEkgYXNrIGlzIEkgDQogIHdvbmRlciBpZiBpdJJzIGV2ZW4g dXNlZnVsIHRvIGRpc2N1c3MgcG93ZXIgdXNhZ2UgZm9yIHNvbWV0aGluZyBsaWtlIA0KICBQMlBT SVAuJm5ic3A7IEl0IGNvdWxkIGJlIHRoYXQgZXZlbiBmb3IgYSCTcmVhbJQgcGVlciwgkW6SIGlz IHNvIGxvdyB0aGF0IHRoZSANCiAgcG93ZXIgY29uc3VtcHRpb24gaXMgZG9taW5hdGVkIGJ5IG90 aGVyIGZhY3RvcnMsIHJlbmRlcmluZyB0aGUgZW50aXJlIA0KICBkaXNjdXNzaW9uIG1vb3QuPG86 cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEw cHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9T UEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPW5hdnkgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjog bmF2eTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5DYW4gYW55Ym9keSBnaXZlIA0KICByZWFsLXdvcmxk IGRhdGEgb24gdGhpcyB0b3BpYz88bzpwPjwvbzpwPjwvU1BBTj48L0ZPTlQ+PC9QPg0KICA8UCBj bGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1uYXZ5IHNpemU9Mj48U1BBTiAN CiAgc3R5bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IG5hdnk7IEZPTlQtRkFNSUxZOiBBcmlh bCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9y bWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJG T05ULVNJWkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPi1kYXZpZCAN CiAgPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxG T05UIGZhY2U9QXJpYWwgY29sb3I9bmF2eSBzaXplPTI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJ WkU6IDEwcHQ7IENPTE9SOiBuYXZ5OyBGT05ULUZBTUlMWTogQXJpYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxESVYgDQogIHN0eWxlPSJCT1JERVItUklHSFQ6IG1l ZGl1bSBub25lOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBQ QURESU5HLUxFRlQ6IDRwdDsgUEFERElORy1CT1RUT006IDBpbjsgQk9SREVSLUxFRlQ6IGJsdWUg MS41cHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25l Ij4NCiAgPERJVj4NCiAgPERJViBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9IlRFWFQtQUxJR046IGNl bnRlciIgYWxpZ249Y2VudGVyPjxGT05UIA0KICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4NCiAgPEhSIHRhYkluZGV4PS0xIGFsaWdu PWNlbnRlciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KICA8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8 UCBjbGFzcz1Nc29Ob3JtYWw+PEI+PEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxTUEFOIA0KICBz dHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRh aG9tYSI+RnJvbTo8L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6ZT0y PjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiBUYWhvbWEiPiANCiAg bWFyY2luLm1hdHVzemV3c2tpQG5va2lhLmNvbSBbbWFpbHRvOm1hcmNpbi5tYXR1c3pld3NraUBu b2tpYS5jb21dIA0KICA8QlI+PEI+PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TZW50 OjwvU1BBTj48L0I+IFdlZG5lc2RheSwgSnVuZSAyNywgDQogIDIwMDcgMTI6MzMgQU08QlI+PEI+ PFNQQU4gc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5Ubzo8L1NQQU4+PC9CPiANCiAgZXVuc29v c2hpbUBnbWFpbC5jb207IGFsYW5Ac2lwc3RhdGlvbi5jb208QlI+PEI+PFNQQU4gDQogIHN0eWxl PSJGT05ULVdFSUdIVDogYm9sZCI+Q2M6PC9TUEFOPjwvQj4gaHNpbm5yZWlAYWRvYmUuY29tOyAN CiAgQVZTSEFMT01AaWwuaWJtLmNvbTsgcGhpbGlwX21hdHRoZXdzQG1hZ21hLmNhOyBwMnBzaXBA aWV0Zi5vPHN0MTpQZXJzb25OYW1lIA0KICB3OnN0PSJvbiI+cmc8L3N0MTpQZXJzb25OYW1lPjxC Uj48Qj48U1BBTiANCiAgc3R5bGU9IkZPTlQtV0VJR0hUOiBib2xkIj5TdWJqZWN0OjwvU1BBTj48 L0I+IFJFOiBbUDJQU0lQXSBkbyB3ZSBuZWVkIGEgY2xpZW50IA0KICBwcm90b2NvbD88L1NQQU4+ PC9GT05UPjxvOnA+PC9vOnA+PC9QPjwvRElWPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5IaSw8 L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPWJsdWUgc2l6ZT0yPjxTUEFOIA0KICBzdHls ZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xPUjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5XZSBo YXZlIHdpZGUgDQogIHZhcmlldHkmbmJzcDtvZiBtb2JpbGUgdGVybWluYWxzLiZuYnNwO1RoZSBj YXBhYmlsaXRpZXMgb2YgbW9iaWxlIHRlcm1pbmFscyANCiAgYXJlJm5ic3A7Y29uc3RhbnRseSBp bXByb3ZpbmcgZS5nLiBldmVuIG5vdyZuYnNwO05va2lhJ3MgTi1zZXJpZXMvRS1zZXJpZXMgDQog IGRldmljZXMgYXJlJm5ic3A7dmVyeSBwb3dlcmZ1bC4gRnJvbSB0aGlzIHJlYXNvbiBzb21lIG9m Jm5ic3A7bW9iaWxlIA0KICB0ZXJtaW5hbHMmbmJzcDttYXkgYmVjb21lIHBlZXJzIChkZXBlbmRp bmcgb24gdGhlIGNhc2Ugc2NlbmFyaW86IGNodXJuLCBzaXplIA0KICBvZiB0aGUgbmV0d29yayku Jm5ic3A7SG93ZXZlciB0aGVyZSBhcmUgDQogIGFsc28mbmJzcDttYW55Jm5ic3A7ZW50cnktbGV2 ZWwvbG93LWVuZCBkZXZpY2VzIHRoYXQgaGF2ZSZuYnNwO3Nsb3cgQ1BVcyANCiAgYW5kJm5ic3A7 bGltaXRlZCBtZW1vcnkuJm5ic3A7PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgPFAg Y2xhc3M9TXNvTm9ybWFsPjxzdDE6cGxhY2UgdzpzdD0ib24iPjxGT05UIGZhY2U9QXJpYWwgY29s b3I9Ymx1ZSANCiAgc2l6ZT0yPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0OyBDT0xP UjogYmx1ZTsgRk9OVC1GQU1JTFk6IEFyaWFsIj5CYXR0ZXJ5PC9TUEFOPjwvRk9OVD48L3N0MTpw bGFjZT48Rk9OVCANCiAgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+IGxp ZmUgaXMgYW5vdGhlciANCiAgaXNzdWUuIE1vc3Qgb2YgdGhlIG1vYmlsZSBwaG9uZSB1c2VycyB3 YW50IGxvbmcgYmF0dGVyeSBsaWZlLiZuYnNwO0RIVCANCiAgbWFpbnRlbmFuY2UgYW5kIGhhbmRs aW5nIHNlYXJjaGVzIGhhdmUgaW1wYWN0IG9uIGlkbGUmbmJzcDtzdGF0ZSB0aGF0IGlzIG1vcmUg DQogIGltcG9ydGFudCBmcm9tJm5ic3A7YmF0dGVyeSBsaWZlIHBlcnNwZWN0aXZlJm5ic3A7dGhh biB0aGUgYWN0aXZlIHN0YXRlIChlLmcuIA0KICB3aGVuIHVzZXIgaXMgY2FsbGluZy9hbnN3ZXJp bmcgYSBjYWxsKS48L1NQQU4+PC9GT05UPjxvOnA+PC9vOnA+PC9QPg0KICA8UCBjbGFzcz1Nc29O b3JtYWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9 IkZPTlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD4NCiAgPERJVj4N CiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9Ymx1ZSBzaXplPTI+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlM WTogQXJpYWwiPkkmbmJzcDt3YXMgDQogIGNvbnNpZGVyaW5nIGEgc2ltaWxhciBzb2x1dGlvbiB0 byB0aGUgb25lIHRoYXQgQWxhbiBwcm9wb3NlZCBob3dldmVyIGFzIEV1bnNvbyANCiAgc2FpZCBp dCZuYnNwO3dvdWxkIGJlJm5ic3A7cXVpdGUgZGlmZmljdWx0IHRvIGNvbnRyb2wgdGhlIG51bWJl ciBvZiANCiAgY29ubmVjdGlvbnMgaW4gREhULiBXZSBhbHNvIGhhdmUgcHJvYmxlbXMgd2l0aCBo YW5kbGluZyANCiAgc2VhcmNoZXMuPC9TUEFOPjwvRk9OVD48bzpwPjwvbzpwPjwvUD48L0RJVj4N CiAgPERJVj4NCiAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biIgc2l6ZT0zPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvU1BBTj48L0ZPTlQ+PC9QPjwvRElWPg0KICA8RElWPg0KICA8UCBjbGFzcz1Nc29Ob3Jt YWw+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIHNpemU9Mj48U1BBTiANCiAgc3R5bGU9IkZP TlQtU0laRTogMTBwdDsgQ09MT1I6IGJsdWU7IEZPTlQtRkFNSUxZOiBBcmlhbCI+SSZuYnNwO2Fz c3VtZSANCiAgdGhhdCZuYnNwO3dlIHdpbGwgaGF2ZSBzb21lIG1vYmlsZSB0ZXJtaW5hbHMgdGFr aW5nIHBhcnQgaW4gREhUIGFuZCBzb21lIA0KICBhY2Nlc3NpbmcgcmVzb3VyY2VzIHN0b3JlZCBp biBESFQgdXNpbmcgYSBjbGllbnQgDQogIHByb3RvY29sLjwvU1BBTj48L0ZPTlQ+PG86cD48L286 cD48L1A+PC9ESVY+DQogIDxESVY+DQogIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+ PEJSPjwvU1BBTj48L0ZPTlQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj1ibHVlIA0KICBzaXplPTI+ PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IENPTE9SOiBibHVlOyBGT05ULUZBTUlM WTogQXJpYWwiPk1hcmNpbjwvU1BBTj48L0ZPTlQ+PG86cD48L286cD48L1A+PC9ESVY+DQogIDxC TE9DS1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1S SUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgUEFERElORy1MRUZUOiA0cHQ7IFBB RERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1cHQgMy43NXB0OyBCT1JERVItTEVG VDogYmx1ZSAxLjVwdCBzb2xpZDsgUEFERElORy1UT1A6IDBpbjsgQk9SREVSLUJPVFRPTTogbWVk aXVtIG5vbmUiPg0KICAgIDxESVYgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSJURVhULUFMSUdOOiBj ZW50ZXIiIGFsaWduPWNlbnRlcj48Rk9OVCANCiAgICBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNp emU9Mz48U1BBTiBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij4NCiAgICA8SFIgdGFiSW5kZXg9LTEg YWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpFPTI+DQogICAgPC9TUEFOPjwvRk9OVD48L0RJ Vj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxC PjxGT05UIGZhY2U9VGFob21hIA0KICAgIHNpemU9Mj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1X RUlHSFQ6IGJvbGQ7IEZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+RnJvbTo8 L1NQQU4+PC9GT05UPjwvQj48Rk9OVCANCiAgICBmYWNlPVRhaG9tYSBzaXplPTI+PFNQQU4gc3R5 bGU9IkZPTlQtU0laRTogMTBwdDsgRk9OVC1GQU1JTFk6IFRhaG9tYSI+IGV4dCANCiAgICA8c3Qx OlBlcnNvbk5hbWUgdzpzdD0ib24iPkV1bnNvbyBTaGltPC9zdDE6UGVyc29uTmFtZT4gDQogICAg W21haWx0bzpldW5zb29zaGltQGdtYWlsLmNvbV0gPEJSPjxCPjxTUEFOIA0KICAgIHN0eWxlPSJG T05ULVdFSUdIVDogYm9sZCI+U2VudDo8L1NQQU4+PC9CPiAyNyBKdW5lLCAyMDA3IDAyOjI2PEJS PjxCPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVdFSUdIVDogYm9sZCI+VG86PC9TUEFOPjwvQj4g QWxhbiBKb2huc3RvbjxCUj48Qj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6IGJvbGQi PkNjOjwvU1BBTj48L0I+IEhlbnJ5IFNpbm5yZWljaDsgQXZzaGFsb20gSG91cmk7IA0KICAgIFBo aWxpcCBNYXR0aGV3czsgUDJQU0lQIE1haWxpbmcgTGlzdDxCUj48Qj48U1BBTiANCiAgICBzdHls ZT0iRk9OVC1XRUlHSFQ6IGJvbGQiPlN1YmplY3Q6PC9TUEFOPjwvQj4gUmU6IFtQMlBTSVBdIGRv IHdlIG5lZWQgYSANCiAgICBjbGllbnQgcHJvdG9jb2w/PC9TUEFOPjwvRk9OVD48bzpwPjwvbzpw PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQi PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgDQogICAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAg PERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFNQQU4gY2xhc3M9Z21haWxxdW90ZT48Rk9O VCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIA0KICAgIHNpemU9Mz48U1BBTiBzdHlsZT0iRk9OVC1T SVpFOiAxMnB0Ij5PbiA2LzI2LzA3LCA8Qj48U1BBTiANCiAgICBzdHlsZT0iRk9OVC1XRUlHSFQ6 IGJvbGQiPkFsYW4gSm9obnN0b248L1NQQU4+PC9CPiAmbHQ7PEEgDQogICAgaHJlZj0ibWFpbHRv OmFsYW5Ac2lwc3RhdGlvbi5jb20iPmFsYW5Ac2lwc3RhdGlvbi5jb208L0E+Jmd0OyANCiAgICB3 cm90ZTo8L1NQQU4+PC9GT05UPjwvU1BBTj4gPG86cD48L286cD48L1A+DQogICAgPFAgY2xhc3M9 TXNvTm9ybWFsPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAg IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPkkndmUgYmVlbiBnaXZpbmcgdGhpcyBhIGxvdCBvZiB0 aG91Z2h0IGxhdGVseSwgDQogICAgdGhpbmtpbmcgYWJvdXQgdGhlIGFjdHVhbDxCUj5yZXF1aXJl bWVudHMuPEJSPjxCUj5XZSB3YW50IHRvIGFsbG93IA0KICAgIGVuZTxzdDE6UGVyc29uTmFtZSB3 OnN0PSJvbiI+cmc8L3N0MTpQZXJzb25OYW1lPnktbGltaXRlZCBkZXZpY2VzIHRvIA0KICAgIHBh cnRpY2lwYXRlIHRvIHNvbWUgbGV2ZWwgaW48QlI+UDJQU0lQLiZuYnNwOyZuYnNwOyBBcyBzdWNo LCBwZXJoYXBzIGluc3RlYWQgDQogICAgb2Ygc2F5aW5nIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9j b2wsIDxCUj5wZXJoYXBzIHdlIGp1c3QgbmVlZCBsZXZlbHMgb2YgDQogICAgcGFydGljaXBhdGlv biBpbiB0aGUgb3ZlcmxheSBwZWVyIHByb3RvY29sLjxCUj48QlI+Rm9yIGV4YW1wbGUsIGEgbm9y bWFsIA0KICAgIHBlZXIgaW4gdGhlIG92ZXJsYXkgd2lsbCBtYWludGFpbiBwZWVyIHByb3RvY29s PEJSPmNvbm5lY3Rpb25zIHdpdGggbWFueSANCiAgICAocGVyaGFwcyBkb3plbnMpIG9mIHBlZXJz LiZuYnNwOyZuYnNwO1doeT8mbmJzcDsmbmJzcDtTbyB0aGF0IGl0IGNhbiANCiAgICA8QlI+cXVp Y2tseSBhbmQgZWZmaWNpZW50bHkgcm91dGUgcmVxdWVzdHMgd2l0aGluIHRoZSANCiAgICBvdmVy bGF5LjxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAgPERJVj4NCiAgICA8UCBjbGFz cz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+PFNQQU4gDQog ICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05U PjwvUD48L0RJVj4NCiAgICA8QkxPQ0tRVU9URSANCiAgICBzdHlsZT0iQk9SREVSLVJJR0hUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsg UEFERElORy1MRUZUOiA2cHQ7IFBBRERJTkctQk9UVE9NOiAwaW47IE1BUkdJTjogNXB0IDBpbiA1 cHQgNC44cHQ7IEJPUkRFUi1MRUZUOiAjY2NjY2NjIDFwdCBzb2xpZDsgUEFERElORy1UT1A6IDBp bjsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmUiPg0KICAgICAgPFAgY2xhc3M9TXNvTm9ybWFs PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgICAgc3R5bGU9 IkZPTlQtU0laRTogMTJwdCI+PG86cD4mbmJzcDs8L286cD48L1NQQU4+PC9GT05UPjwvUD4NCiAg ICAgIDxQIGNsYXNzPU1zb05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9 Mz48U1BBTiANCiAgICAgIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPlBlcmhhcHMgYW4gZW5lPHN0 MTpQZXJzb25OYW1lIA0KICAgICAgdzpzdD0ib24iPnJnPC9zdDE6UGVyc29uTmFtZT55LWxpbWl0 ZWQgZGV2aWNlIGNvdWxkIGp1c3QgbWluaW1pemUgdGhlIA0KICAgICAgbnVtYmVyIG9mIHBlZXI8 QlI+cHJvdG9jb2wgY29ubmVjdGlvbnMgaXQgbWFpbnRhaW5zLCBwZXJoYXBzIGV2ZW4gZG93biB0 byANCiAgICAgIGEgbWluaW11bSBvZjxCUj50d28uJm5ic3A7Jm5ic3A7VGhpcyB3b3VsZCByZXN1 bHQgaW4gc2xvd2VyIHJvdXRpbmcgb2YgaXRzIA0KICAgICAgcmVxdWVzdHMgdGhyb3VnaCB0aGU8 QlI+b3ZlcmxheSwgYnV0IHRoYXQgc2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgDQogICAgICB0cmFk ZW9mZi4gPG86cD48L286cD48L1NQQU4+PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+DQogICAgPERJ Vj4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPTM+PFNQQU4gDQogICAgc3R5bGU9IkZPTlQtU0laRTogMTJwdCI+PEJSPlRoZSB1bmRlcmxp bmcgYWxnb3JpdGhtIChlLmcuIGEgY2VydGFpbiBESFQgDQogICAgYWxnb3JpdGhtKSB3aWxsIGRp Y3RhdGUgdGhlIG51bWJlciBvZiBjb25uZWN0aW9ucyBldmVuIHRob3VnaCB0aGVyZSBtaWdodCBi ZSANCiAgICBzb21lIHJvb20gZm9yIGFkanVzdG1lbnQuIEkgZG9uJ3QgdGhpbmsgaXQgaXMgdW5k ZXIgY29tcGxldGUgY29udHJvbCBvZiANCiAgICBpbmRpdmlkdWFsIHBlZXIgaW4gdGhlIGNhc2Ug b2Yga25vd24gREhUIGFsZ29yaXRobXMuIA0KICAgIDxvOnA+PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+PC9ESVY+DQogICAgPEJMT0NLUVVPVEUgDQogICAgc3R5bGU9IkJPUkRFUi1SSUdIVDogbWVk aXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVtIG5vbmU7IFBB RERJTkctTEVGVDogNnB0OyBQQURESU5HLUJPVFRPTTogMGluOyBNQVJHSU46IDVwdCAwaW4gNXB0 IDQuOHB0OyBCT1JERVItTEVGVDogI2NjY2NjYyAxcHQgc29saWQ7IFBBRERJTkctVE9QOiAwaW47 IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAgICAgIDxQIGNsYXNzPU1zb05vcm1hbD48 Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAgIHN0eWxlPSJG T05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+DQogICAg ICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPTM+ PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5BbHNvLCBwZXJoYXBzIHRoZXJl IGFyZSBzb21lIG90aGVyIHBlZXIgcHJvdG9jb2wgDQogICAgICBmdW5jdGlvbnMsIHN1Y2ggYXMg ZGF0YTxCUj5yZXBsaWNhdGlvbiAoc3RvcmFnZSB3b3VsZCBzdGlsbCBiZSBkb25lLCBidXQgDQog ICAgICBub3QgcmVwbGljYXRpb24pLCB0aGF0IDxCUj5jb3VsZCBiZSBza2lwcGVkIGJ5IHRoZXNl IGVuZTxzdDE6UGVyc29uTmFtZSANCiAgICAgIHc6c3Q9Im9uIj5yZzwvc3QxOlBlcnNvbk5hbWU+ eS1saW1pdGVkIHBlZXJzLiZuYnNwOyZuYnNwO1BlcmhhcHMgdGhlaXIgDQogICAgICByZXF1ZXN0 czxCUj5hbmQgcmVzcG9uc2VzIGNvdWxkIGJlIHJvdXRlZCBvdmVyIHRoZSBvdmVybGF5IHdpdGgg YSBsb3dlciANCiAgICAgIHByaW9yaXR5PEJSPnRoYW4gZnVsbCBwZWVycy4mbmJzcDsmbmJzcDtX ZSBuZWVkIHRvIG1hbmFnZSB0aGUgdHJhZGVvZmZzIHNvIA0KICAgICAgdGhhdCB0aG9zZSBwZWVy czxCUj53aG8gY29udHJpYnV0ZSB0aGUgbGVhc3QgdG8gdGhlIG92ZXJsYXkgYWxzbyBnZXQgdGhl IA0KICAgICAgbG93ZXN0IHBlcmZvcm1hbmNlPEJSPmZyb20gaXQuPG86cD48L286cD48L1NQQU4+ PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+DQogICAgPERJVj4NCiAgICA8UCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9Ik1BUkdJTi1CT1RUT006IDEycHQiPjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21h biIgDQogICAgc2l6ZT0zPjxTUEFOIHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxCUj48QlI+SSBh bSBub3QgcXVpdGUgc3VyZSBJIA0KICAgIHVuZGVyc3RhbmQgdGhlIGJlbmVmaXQgb2YgaW50cm9k dWNpbmcgc3VjaCB2YXJpb3VzIGxldmVscyBvZiANCiAgICBwYXJ0aWNpcGF0aW9uLjxCUj5IYXZp bmcgYSBjbGllbnQgcHJvdG9jb2wgc2VlbXMgdG8gYmUgbXVjaCBzaW1wbGVyIGFuZCANCiAgICBl YXNpZXIgdGhhbiBpbnRyb2R1Y2luZyB0aGVzZSB2YXJpb3VzIGxldmVscyBvZiBwYXJ0aWNpcGF0 aW9uLiANCiAgICA8QlI+PEJSPlRoYW5rcy48QlI+PEJSPkV1bnNvbzxvOnA+PC9vOnA+PC9TUEFO PjwvRk9OVD48L1A+PC9ESVY+DQogICAgPEJMT0NLUVVPVEUgDQogICAgc3R5bGU9IkJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogbWVkaXVt IG5vbmU7IFBBRERJTkctTEVGVDogNnB0OyBQQURESU5HLUJPVFRPTTogMGluOyBNQVJHSU46IDVw dCAwaW4gNXB0IDQuOHB0OyBCT1JERVItTEVGVDogI2NjY2NjYyAxcHQgc29saWQ7IFBBRERJTkct VE9QOiAwaW47IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lIj4NCiAgICAgIDxQIGNsYXNzPU1z b05vcm1hbD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9Mz48U1BBTiANCiAgICAg IHN0eWxlPSJGT05ULVNJWkU6IDEycHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48 L1A+DQogICAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PEZPTlQgZmFjZT0iVGltZXMgTmV3IFJvbWFu IiBzaXplPTM+PFNQQU4gDQogICAgICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0Ij5IZW5yeSBTaW5u cmVpY2ggd3JvdGU6PEJSPiZndDsgRm9sa3MsPEJSPiZndDsgDQogICAgICA8QlI+Jmd0OyBHaXZl biB0aGUgbGVuZ3RoIG9mIHRoZSBkaXNjdXNzaW9uIG9uICJkbyB3ZSBuZWVkIGEgY2xpZW50IA0K ICAgICAgcHJvdG9jb2w/IjxCUj4mZ3Q7IGxldCBtZSByZXBlYXQgdGhlIHNpbXBsZSBpbXBlcmF0 aXZlcyBmb3IgdGhlIA0KICAgICAgY2xpZW50OjxCUj4mZ3Q7PEJSPiZndDsgLSBMaW1pdGVkIGJh dHRlcnkgaW4gbW9iaWxlIGRldmljZXMsIA0KICAgICAgYW5kPEJSPiZndDs8QlI+Jmd0OyAtIE90 aGVyIHVzZXMgYmVzaWRlcyBTSVAuIEJ1c2luZXNzIHBsYW5uaW5nIGZvbGtzIG1heSANCiAgICAg IG5vdCBjYXJlIGFib3V0IHRoZSA8QlI+Jmd0OyBXRyBjaGFydGVyLCBidXQgYWJvdXQgdGhlIHJl dHVybiBvbiB0aGUgDQogICAgICBpbnZlc3RtZW50LjxCUj4mZ3Q7PEJSPiZndDsgVGhhbmtzLCBI ZW5yeTxCUj4mZ3Q7PEJSPiZndDsgLS0tLS1PcmlnaW5hbCANCiAgICAgIE1lc3NhZ2UtLS0tLTxC Uj4mZ3Q7IEZyb206IERlYW4gV2lsbGlzIFttYWlsdG86PEEgDQogICAgICBocmVmPSJtYWlsdG86 ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbSI+ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbSANCiAg ICAgIDwvQT5dPEJSPiZndDsgU2VudDogVGh1cnNkYXksIEp1bmUgMTQsIDIwMDcgMTE6MjMgUE08 QlI+Jmd0OyBUbzogRGF2aWQgQS4gDQogICAgICBCcnlhbjxCUj4mZ3Q7IENjOiBBdnNoYWxvbSBI b3VyaTsgUDJQU0lQIE1haWxpbmcgTGlzdDsgUGhpbGlwIA0KICAgICAgTWF0dGhld3M8QlI+Jmd0 OyBTdWJqZWN0OiBSZTogW1AyUFNJUF0gQ29uY2VwdHMgZG9jdW1lbnQ6IHByb3Bvc2FsIGZvciAN CiAgICAgIGFjdGl2ZS9wYXNzaXZlIDxCUj4mZ3Q7IHBlZXJ0ZXJtaW5vbG9neTxCUj4mZ3Q7PEJS PiZndDsgRGF2aWQgQS4gQnJ5YW4gDQogICAgICB3cm90ZTo8QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyBJ ZiBJIHVuZGVyc3RhbmQgdGhpcyByaWdodCwgbm90IHN1cmUgSSBsaWtlIGl0LiANCiAgICAgIERv IHRoZXNlPEJSPiZndDsmZ3Q7PEJSPiZndDsgIm5vbi1jb250cmlidXRpbmc8QlI+Jmd0OzxCUj4m Z3Q7Jmd0OyBwZWVyIiANCiAgICAgIChJICpkbyogbGlrZSBjb250cmlidXRpbmcgYmV0dGVyIHRo YW4gYWN0aXZlL3Bhc3NpdmUpIGVudGl0aWVzIA0KICAgICAgPEJSPiZndDsmZ3Q7PEJSPiZndDsg aGF2ZSBhPEJSPiZndDs8QlI+Jmd0OyZndDsgUGVlci1JRD8gSW4gb3RoZXJ3b3JkcywgDQogICAg ICBhcmUgdGhleSBwYXJ0IG9mIHRoZSBvdmVybGF5IGF0IGFsbD8gSWYgc28sPEJSPiZndDsmZ3Q7 PEJSPiZndDsgDQogICAgICBmb3I8QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyBtb3N0PEJSPiZndDsmZ3Q7 IERIVHMsIGhvdyBkbyB3ZSBhbGxvdyB5b3UgdG8gYmUgDQogICAgICBpbiB0aGUgb3ZlcmxheSBh bmQgbm90IHN0b3JlIHJlc291cmNlcyA8QlI+Jmd0OyZndDs8QlI+Jmd0OyANCiAgICAgIChub3Q8 QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyB0eXBpY2FsIGZvciBtb3N0IGN1cnJlbnQgREhUIA0KICAgICAg YWxnb3JpdGhtcyk8QlI+Jmd0OyZndDs8QlI+Jmd0OzxCUj4mZ3Q7IFdlbGwsIHRoYXQgY2VydGFp bmx5IGRlcGVuZHMgb24gDQogICAgICB0aGUgREhUIGFsZ29yaXRobSBpbnZvbHZlZC4gSXQgY2Vy dGFpbmx5PEJSPiZndDsgc2VlbXMgdGhhdCBhIHBlZXIgdGhhdCANCiAgICAgIG1vdmVzIGJldHdl ZW4gY29udHJpYnV0aW5nIGFuZCBub24tY29udHJpYnV0aW5nIDxCUj4mZ3Q7IG1pZ2h0IEhBVkUg YSBwZWVyIA0KICAgICAgSUQsIGJ1dCB3aGV0aGVyIGl0IGNob29zZXMgdG8gaW5zZXJ0IGl0c2Vs ZiBpbnRvIHRoZTxCUj4mZ3Q7IERIVCAicmlnaHQgDQogICAgICBub3ciIG1pZ2h0IGRldGVybWlu ZSB3aGV0aGVyIGl0IGlzIGNvbnRyaWJ1dGluZyAicmlnaHQgbm93IjxCUj4mZ3Q7IG9yIA0KICAg ICAgbm90LjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyZndDsgTXkgY29uY2VybiBhbGwgYWxvbmcg aGFzIGJlZW4gdGhhdCBJIA0KICAgICAgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgc29tZXRoaW5nIDxC Uj4mZ3Q7Jmd0OyBpcyBhIHBlZXIgaWYgaXQgaXNuJ3QgZG9pbmcgDQogICAgICBhbnl0aGluZyBv dGhlciB0aGFuIHRhbGtpbmcgdG8gc29tZW9uZTxCUj4mZ3Q7Jmd0OyBhbmQgbWFraW5nIHJlcXVl c3RzLCANCiAgICAgIGhlbmNlIHdoeSBJIHN1cHBvcnRlZCBjbGllbnQgaW4gdGhlIGZpcnN0IHBs YWNlLjxCUj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwO0kgDQogICAgICBmYWlsIHRvIHNlZSBob3cgc29t ZXRoaW5nIHRoYXQgaXNuJ3QgY29udHJpYnV0aW5nIGFueXRoaW5nLCBhbmQgDQogICAgICA8QlI+ Jmd0OyZndDsgaW5zdGVhZCB0YWxrcyB0byBhIHBlZXIgdG8gZ2V0IHJlc291cmNlcywgaXMgaW4g YW55IHdheSBhIA0KICAgICAgcGVlci4gSXQ8QlI+Jmd0OyZndDsgc2VlbXMgY29tcGxldGVseSBu b3QgaW4ga2VlcGluZyB3aXRoIHRoZSBpZGVhIG9mIFAyUC4gDQogICAgICBJIGFsc28gd29ycnkg aXQ8QlI+Jmd0OyZndDsmbmJzcDsmbmJzcDtpcyBsaWtlbHkgdG8gYmUgdmVyeSBjb25mdXNpbmcg DQogICAgICBzaW5jZSB3ZSd2ZSBiZWVuIHVzaW5nIHRoZSBvdGhlciA8QlI+Jmd0OyZndDsgdGVy bWlub2xvZ3kgZm9yIG92ZXIgYSB5ZWFyIA0KICAgICAgbm93LiBKdXN0IGxvb2tzIGxpa2UgYSBz b3VjZSBvZiBjb25mdXNpb24uPEJSPiZndDsmZ3Q7PEJSPiZndDs8QlI+Jmd0OyBBIA0KICAgICAg bm9kZSBtaWdodCBzb21ldGltZXMgaGF2ZSBhIGhpZ2gtYmFuZHdpZHRoIGNvbm5lY3Rpb24gYW5k IHdpc2ggdG88QlI+Jmd0OyANCiAgICAgIGNvbnRyaWJ1dGUgcmVzb3VyY2VzLCBhbmQgc29tZXRp bWVzIG5vdCBoYXZlIGEgaGlnaC1iYW5kd2lkdGggY29ubmVjdGlvbiANCiAgICAgIDxCUj4mZ3Q7 IGFuZCB0aGVyZWZvcmUgbm90IHdpc2ggdG8gb2ZmZXIgcmVzb3VyY2VzLiBEb2VzIHRoaXMgbW9k YWxpdHkgDQogICAgICBtYWtlIGl0PEJSPiZndDsgdHdvIGRpZmZlcmVudCBub2Rlcz88QlI+Jmd0 OzxCUj4mZ3Q7PEJSPiZndDsmZ3Q7IElmIHdlIGRvIA0KICAgICAgZ28gdGhpcyB3YXksIHRoZXJl IGlzIG9uZSBzdWJ0bGUgcG9pbnQuIElmIEkgam9pbiB0aGUgDQogICAgICBvdmVybGF5PEJSPiZn dDsmZ3Q7PEJSPiZndDsgYnV0PEJSPiZndDs8QlI+Jmd0OyZndDsgZG9uJ3QgaGFwcGVuIHRvIG9m ZmVyIA0KICAgICAgYW55IHNlcnZpY2VzIChvdGhlciB0aGFuIG1heWJlPEJSPiZndDsmZ3Q7PEJS PiZndDsgc3RvcmFnZS4uLmRlcGVuZGluZyANCiAgICAgIG9uPEJSPiZndDs8QlI+Jmd0OyZndDsg aG93IHdlIGRlZmluaWUgaXQsIHRoYXQgbWlnaHQgb3IgbWlnaHQgbm90IGJlIA0KICAgICAgbWFu ZGF0b3J5KSwgd291bGQgSSBiZTxCUj4mZ3Q7Jmd0OyBjb250cmlidXRpbmc/IElmIGpvaW5pbmcg dGhlIG92ZXJsYXkgDQogICAgICAoaW4gdGhlIHNlbnNlIHRoYXQgd2UgaGF2ZSBhPEJSPiZndDsm Z3Q7PEJSPiZndDsgDQogICAgICBQZWVySUQ8QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyBhbmQ8QlI+Jmd0 OyZndDsgd2Ugcm91dGUgdHJhZmZpYykgZG9lc24ndCANCiAgICAgIHJlcXVpcmUgbWUgdG8gc3Rv cmUsIEkgY291bGQgb2ZmZXIgbm88QlI+Jmd0OyZndDs8QlI+Jmd0OyANCiAgICAgIHNlcnZpY2Vz PEJSPiZndDs8QlI+Jmd0OyBUaGF0J3MgIm9mZmVyIG5vIG90aGVyIHNlcnZpY2VzIiwgc2luY2Ug cm91dGluZyANCiAgICAgIGlzIGl0c2VsZiBhIHNlcnZpY2UuPEJSPiZndDs8QlI+Jmd0OzxCUj4m Z3Q7Jmd0OyBhbmQ8QlI+Jmd0OyZndDsgc3RpbGwgYmUgDQogICAgICBhIHBlZXIuIEhvdyBkbyB3 ZSBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoaXMgY2FzZSBhbmQgYTxCUj4mZ3Q7Jmd0OyANCiAgICAg ICJub24tY29udHJpYnV0aW5nIHBlZXIiIHdobyBpc24ndCBldmVuIHBhcnQgb2YgdGhlIG92ZXJs YXkgKGkuZS4sIA0KICAgICAgbm88QlI+Jmd0OyZndDsgUGVlci1JRCk8QlI+Jmd0OyZndDs8QlI+ Jmd0OzxCUj4mZ3Q7IEkgdGhpbmsgdGhlcmUncyBhIA0KICAgICAgcmFuZ2Ugb2YgImNvbnRyaWJ1 dGluZyIgaW4gcGxheS4gRm9yIG1vc3QgREhUIG1vZGVscywgPEJSPiZndDsgYSBtaW5pbWFsbHkg DQogICAgICBjb250cmlidXRpbmcgbm9kZSB3aWxsIHJvdXRlIGEgcmVxdWVzdCBpdCByZWNlaXZl cy4gSXQgbWlnaHQ8QlI+Jmd0OyBhc2sgDQogICAgICBuaWNlbHkgKHBlcmhhcHMgYSBxLXZhbHVl IG1lY2hhbmlzbSkgdG8gbm90IGhhdmUgdG8gcm91dGUgDQogICAgICByZXF1ZXN0cyw8QlI+Jmd0 OyBidXQgd291bGQgcHJvYmFibHkgbWF0aGVtYXRpY2FsbHkgc3RpbGwgaGF2ZSB0byByb3V0ZSAN CiAgICAgIHNvbWV0aGluZyBpdCBnZXRzLiA8QlI+Jmd0OzxCUj4mZ3Q7IEkgdGhpbmsgd2UgZGlz dGluZ3Vpc2ggYmFzZWQgb24gdGhlIA0KICAgICAgc2VydmljZSBhZHZlcnRpc2VtZW50cyBmcm9t IHRoZTxCUj4mZ3Q7IHBlZXIuPEJSPiZndDs8QlI+Jmd0OzxCUj4mZ3Q7Jmd0OyANCiAgICAgIElm IHdlIGFyZSBzbyBvcHBvc2VkIHRvIGNsaWVudCBmb3IgY29uZnVzaW9uIHdpdGggU0lQIFVBcywg bGV0cyBwaWNrIA0KICAgICAgYTxCUj4mZ3Q7Jmd0OzxCUj4mZ3Q7IG5ldyA8QlI+Jmd0OzxCUj4m Z3Q7Jmd0OyBuYW1lLCBidXQgd2h5IHNvbWUgZmxhdm9yIA0KICAgICAgb2YgcGVlciB3aGVuIGl0 IGRvZXMgbm90aGluZyByZW1vdGVseSBwZWVyPEJSPiZndDsmZ3Q7PEJSPiZndDsgDQogICAgICBs aWtlPzxCUj4mZ3Q7PEJSPiZndDsgQmVjYXVzZSBpbiAxNSBtaW51dGVzIGl0IG1pZ2h0IHJvYW0g b250byBhIFdpRmkgbmV0IA0KICAgICAgYW5kIHRoZXJlZm9yZSBjaGFuZ2U8QlI+Jmd0OyBpdCBz ZXJ2aWNlIG9mZmVyaW5nLiA8QlI+Jmd0OzxCUj4mZ3Q7IA0KICAgICAgLS08QlI+Jmd0OyBEZWFu PEJSPiZndDs8QlI+Jmd0OyANCiAgICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPEJSPiZndDsgUDJQU0lQIG1haWxpbmcgDQogICAgICBsaXN0PEJSPiZn dDsgPEEgaHJlZj0ibWFpbHRvOlAyUFNJUEBpZXRmLm9yZyI+UDJQU0lQQGlldGYub3JnPC9BPjxC Uj4mZ3Q7IA0KICAgICAgPEEgDQogICAgICBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wMnBzaXAiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3AycHNpcDwvQT48QlI+Jmd0OzxCUj4mZ3Q7IA0KICAgICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+Jmd0OyBQMlBTSVAgbWFpbGluZyANCiAg ICAgIGxpc3Q8QlI+Jmd0OyA8QSBocmVmPSJtYWlsdG86UDJQU0lQQGlldGYub3JnIj5QMlBTSVBA aWV0Zi5vcmc8L0E+PEJSPiZndDsgDQogICAgICA8QSANCiAgICAgIGhyZWY9Imh0dHBzOi8vd3d3 MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcCI+aHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcDJwc2lwPC9BPjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OzxCUj48 QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJS PlAyUFNJUCANCiAgICAgIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWlsdG86UDJQU0lQQGll dGYub3JnIj5QMlBTSVBAaWV0Zi5vcmc8L0E+PEJSPjxBIA0KICAgICAgaHJlZj0iaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIj5odHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8L0E+PG86cD48L286cD48L1NQQU4+PC9GT05UPjwv UD48L0JMT0NLUVVPVEU+PC9ESVY+DQogICAgPFAgY2xhc3M9TXNvTm9ybWFsPjxGT05UIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0zPjxTUEFOIA0KICAgIHN0eWxlPSJGT05ULVNJWkU6IDEy cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9TUEFOPjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPjwvRElW PjwvRElWPjwvRElWPg0KICA8UD4NCiAgPEhSPg0KDQogIDxQPjwvUD5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5QMlBTSVAgbWFpbGluZyANCiAgbGlz dDxCUj5QMlBTSVBAaWV0Zi5vcmc8QlI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcDJwc2lwPEJSPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0035_01C7B972.1171CEF0-- --===============0606219145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0606219145==-- From p2psip-bounces@ietf.org Thu Jun 28 02:15:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nHy-0007h0-Ib; Thu, 28 Jun 2007 02:15:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3nHx-0007gs-TP for p2psip@ietf.org; Thu, 28 Jun 2007 02:15:33 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3nHg-0005n4-EM for p2psip@ietf.org; Thu, 28 Jun 2007 02:15:33 -0400 X-ClientAddr: 213.145.160.17 Received: from [127.0.0.1] (213-145-160-17.dd.nextgentel.com [213.145.160.17]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5S5sqqr031083; Thu, 28 Jun 2007 07:54:53 +0200 Message-ID: <468351F0.50404@teigre.com> Date: Thu, 28 Jun 2007 08:15:12 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Wei Gengyu Subject: Re: [P2PSIP] do we need a client protocol? References: <003801c7b92f$09ced5a0$a507740a@DELLWEI> In-Reply-To: <003801c7b92f$09ced5a0$a507740a@DELLWEI> X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f4ba062a597fb5300e05298a02d6f432 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0994363005==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0994363005== Content-Type: multipart/alternative; boundary="------------080203070201080508040608" This is a multi-part message in MIME format. --------------080203070201080508040608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pontius.teigre.com id l5S5sqqr031083 Well, it's a bit more complicated than that. For one thing, there's a=20 difference between mobile and WLAN. Even with the power-saving mode of=20 802.11g for example, there's still more power drain when connected to=20 WLAN, than mobile. And on mobile, you have many scenarios, just take the=20 GSM (which I know the best), you have GSM High-Speed, still used by many=20 roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data=20 connections. You can have three modes, each with different power=20 consumption: No connection (only voice), PDP context established, and=20 active connection. Real-life experimentation with various modes and=20 applications using these modes show that battery drainage is a real=20 problem. As an example: a native Symbian application that looks up incoming calls=20 (over 3G data connection) where caller-id is not found in the local=20 contact list needs to have an active connection (not only PDP context),=20 because in order to show the caller's data, the lookup must be almost=20 instantaneous. In reality, it takes about 1 second. This application is=20 pretty much useless if you actually make any calls, because at the end=20 of the day, you don't have battery left... BTW, the same holds for innovative mobile VoIP apps such as Fling. For a mobile unit to be a peer, we need a battery revolution. g-) Wei Gengyu wrote: > Hi, > =20 > A cell phone have full receiving capabilities in standby mode. > The cell phone will enter the active mode (you said "talk" mode) > after receiving a paging frame containing "setup" message destined to i= t.=20 > =20 > In standby mode, it can listen any messages of signalling and/or IP=20 > packets. > So, yes it is possible to have a phone in low-power standby mode but=20 > (for example) listening for incoming TCP connections or UDP packets. > =20 > However, the power consumption to send messages is mostly converned=20 > when the cell phone is in active mode. > =20 > *But, I do not think this should be dominate P2PSIP overlay design in=20 > this stage.* > =20 > =20 > Gengyu > > ----- Original Message ----- > *From:* David Barrett > *To:* 'Henry Sinnreich' ; > marcin.matuszewski@nokia.com > ; eunsooshim@gmail.com ; > alan@sipstation.com > *Cc:* AVSHALOM@il.ibm.com ; > philip_matthews@magma.ca ; > p2psip@ietf.org > *Sent:* Thursday, June 28, 2007 6:41 AM > *Subject:* RE: [P2PSIP] do we need a client protocol? > > That makes sense. So my next question is: what are the > capabilities of standby mode, and what triggers it going into > "talk" mode? > > =20 > > It must be listening to some sort of cell signal even in standby > mode, just so it can receive phone calls. Given this, when in > standby mode, does it also have access to the IP network? In > other words, is it possible to have a phone in low-power standby > mode but (for example) listening for incoming TCP connections or > UDP packets? > > =20 > > -david > > =20 > > -------------------------------------------------------------------= ----- > > *From:* Henry Sinnreich [mailto:hsinnrei@adobe.com] > *Sent:* Wednesday, June 27, 2007 1:39 PM > *To:* David Barrett; marcin.matuszewski@nokia.com > ; eunsooshim@gmail.com > ; alan@sipstation.com > > *Cc:* AVSHALOM@il.ibm.com ; > philip_matthews@magma.ca ; > p2psip@ietf.org > *Subject:* RE: [P2PSIP] do we need a client protocol? > > =20 > > It is more complicated than this. > > Under normal cell phone operation we have the talk time and the > standby time which is much longer. > > =20 > > Making a cell phone a full peer eliminates this distinction to a > large degree since the overlay maintenance messages keep the phone > 'talking' all the time. > > =20 > > Henry > > =20 > > -------------------------------------------------------------------= ----- > > *From:* David Barrett [mailto:dbarrett@quinthar.com] > *Sent:* Wednesday, June 27, 2007 10:06 AM > *To:* marcin.matuszewski@nokia.com; eunsooshim@gmail.com; > alan@sipstation.com > *Cc:* Henry Sinnreich; AVSHALOM@il.ibm.com; > philip_matthews@magma.ca; p2psip@ietf.org > *Subject:* RE: [P2PSIP] do we need a client protocol? > > =20 > > I don't know anything about mobile application design vis-=E0-vis > battery life, but I'm guessing power usage could be vastly > oversimplified to something like: > > =20 > > Power =3D A + nB > > =20 > > Where A is the overall cost of just having the device powered on > and listening to the radio, and B is the cost of sending a byte of > data. What I'm wondering is, what is the ratio of A to B? Can > anyone give real-world data? > > =20 > > For example, I'd accept that sending 200Mbps probably requires > about 2x the power 100Mbps: for a high enough value of 'n', then > the constant A gets marginalized. But what about 200Kbps or > 200bps? For some low value of 'n', then A dominates the power usag= e. > > =20 > > The reason I ask is I wonder if it's even useful to discuss power > usage for something like P2PSIP. It could be that even for a > "real" peer, 'n' is so low that the power consumption is dominated > by other factors, rendering the entire discussion moot. > > =20 > > Can anybody give real-world data on this topic? > > =20 > > -david > > =20 > > -------------------------------------------------------------------= ----- > > *From:* marcin.matuszewski@nokia.com > [mailto:marcin.matuszewski@nokia.com] > *Sent:* Wednesday, June 27, 2007 12:33 AM > *To:* eunsooshim@gmail.com; alan@sipstation.com > *Cc:* hsinnrei@adobe.com; AVSHALOM@il.ibm.com; > philip_matthews@magma.ca; p2psip@ietf.org > *Subject:* RE: [P2PSIP] do we need a client protocol? > > =20 > > Hi, > > =20 > > We have wide variety of mobile terminals. The capabilities of > mobile terminals are constantly improving e.g. even now Nokia's > N-series/E-series devices are very powerful. From this reason some > of mobile terminals may become peers (depending on the case > scenario: churn, size of the network). However there are > also many entry-level/low-end devices that have slow CPUs > and limited memory.=20 > > Battery life is another issue. Most of the mobile phone users want > long battery life. DHT maintenance and handling searches have > impact on idle state that is more important from battery life > perspective than the active state (e.g. when user is > calling/answering a call). > > =20 > > I was considering a similar solution to the one that Alan proposed > however as Eunsoo said it would be quite difficult to control the > number of connections in DHT. We also have problems with handling > searches. > > =20 > > I assume that we will have some mobile terminals taking part in > DHT and some accessing resources stored in DHT using a client > protocol. > > > Marcin > > ---------------------------------------------------------------= --------- > > *From:* ext Eunsoo Shim [mailto:eunsooshim@gmail.com] > *Sent:* 27 June, 2007 02:26 > *To:* Alan Johnston > *Cc:* Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP > Mailing List > *Subject:* Re: [P2PSIP] do we need a client protocol? > > =20 > > On 6/26/07, *Alan Johnston* > wrote: > > I've been giving this a lot of thought lately, thinking about > the actual > requirements. > > We want to allow energy-limited devices to participate to some > level in > P2PSIP. As such, perhaps instead of saying we need a client > protocol, > perhaps we just need levels of participation in the overlay > peer protocol. > > For example, a normal peer in the overlay will maintain peer > protocol > connections with many (perhaps dozens) of peers. Why? So > that it can > quickly and efficiently route requests within the overlay. > > =20 > > =20 > > Perhaps an energy-limited device could just minimize the > number of peer > protocol connections it maintains, perhaps even down to a > minimum of > two. This would result in slower routing of its requests > through the > overlay, but that seems like a reasonable tradeoff. > > > The underling algorithm (e.g. a certain DHT algorithm) will > dictate the number of connections even though there might be > some room for adjustment. I don't think it is under complete > control of individual peer in the case of known DHT algorithms. > > =20 > > Also, perhaps there are some other peer protocol > functions, such as data > replication (storage would still be done, but not > replication), that > could be skipped by these energy-limited peers. Perhaps > their requests > and responses could be routed over the overlay with a > lower priority > than full peers. We need to manage the tradeoffs so that > those peers > who contribute the least to the overlay also get the > lowest performance > from it. > > > > I am not quite sure I understand the benefit of introducing > such various levels of participation. > Having a client protocol seems to be much simpler and easier > than introducing these various levels of participation. > > Thanks. > > Eunsoo > > =20 > > Henry Sinnreich wrote: > > Folks, > > > > Given the length of the discussion on "do we need a > client protocol?" > > let me repeat the simple imperatives for the client: > > > > - Limited battery in mobile devices, and > > > > - Other uses besides SIP. Business planning folks may not > care about the > > WG charter, but about the return on the investment. > > > > Thanks, Henry > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@softarmor.com > ] > > Sent: Thursday, June 14, 2007 11:23 PM > > To: David A. Bryan > > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > > Subject: Re: [P2PSIP] Concepts document: proposal for > active/passive > > peerterminology > > > > David A. Bryan wrote: > > > >> If I understand this right, not sure I like it. Do these > >> > > "non-contributing > > > >> peer" (I *do* like contributing better than > active/passive) entities > >> > > have a > > > >> Peer-ID? In otherwords, are they part of the overlay at > all? If so, > >> > > for > > > >> most > >> DHTs, how do we allow you to be in the overlay and not > store resources > >> > > (not > > > >> typical for most current DHT algorithms) > >> > > > > Well, that certainly depends on the DHT algorithm > involved. It certainly > > seems that a peer that moves between contributing and > non-contributing > > might HAVE a peer ID, but whether it chooses to insert > itself into the > > DHT "right now" might determine whether it is > contributing "right now" > > or not. > > > > > >> My concern all along has been that I don't understand > why something > >> is a peer if it isn't doing anything other than talking > to someone > >> and making requests, hence why I supported client in the > first place. > >> I fail to see how something that isn't contributing > anything, and > >> instead talks to a peer to get resources, is in any way > a peer. It > >> seems completely not in keeping with the idea of P2P. I > also worry it > >> is likely to be very confusing since we've been using > the other > >> terminology for over a year now. Just looks like a souce > of confusion. > >> > > > > A node might sometimes have a high-bandwidth connection > and wish to > > contribute resources, and sometimes not have a > high-bandwidth connection > > and therefore not wish to offer resources. Does this > modality make it > > two different nodes? > > > > > >> If we do go this way, there is one subtle point. If I > join the overlay > >> > > but > > > >> don't happen to offer any services (other than maybe > >> > > storage...depending on > > > >> how we definie it, that might or might not be > mandatory), would I be > >> contributing? If joining the overlay (in the sense that > we have a > >> > > PeerID > > > >> and > >> we route traffic) doesn't require me to store, I could > offer no > >> > > services > > > > That's "offer no other services", since routing is itself > a service. > > > > > >> and > >> still be a peer. How do we distinguish between this case > and a > >> "non-contributing peer" who isn't even part of the > overlay (i.e., no > >> Peer-ID) > >> > > > > I think there's a range of "contributing" in play. For > most DHT models, > > a minimally contributing node will route a request it > receives. It might > > ask nicely (perhaps a q-value mechanism) to not have to > route requests, > > but would probably mathematically still have to route > something it gets. > > > > I think we distinguish based on the service > advertisements from the > > peer. > > > > > >> If we are so opposed to client for confusion with SIP > UAs, lets pick a > >> > > new > > > >> name, but why some flavor of peer when it does nothing > remotely peer > >> > > like? > > > > Because in 15 minutes it might roam onto a WiFi net and > therefore change > > it service offering. > > > > -- > > Dean > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > =20 > > -------------------------------------------------------------------= ----- > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -----------------------------------------------------------------------= - > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > =20 --------------080203070201080508040608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well, it's a bit more complicated than that. For one thing, there's a difference between mobile and WLAN. Even with the power-saving mode of 802.11g for example, there's still more power drain when connected to WLAN, than mobile. And on mobile, you have many scenarios, just take the GSM (which I know the best), you have GSM High-Speed, still used by many roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data connections. You can have three modes, each with different power consumption: No connection (only voice), PDP context established, and active connection. Real-life experimentation with various modes and applications using these modes show that battery drainage is a real problem.
As an example: a native Symbian application that looks up incoming calls (over 3G data connection) where caller-id is not found in the local contact list needs to have an active connection (not only PDP context), because in order to show the caller's data, the lookup must be almost instantaneous. In reality, it takes about 1 second.  This application is pretty much useless if you actually make any calls, because at the end of the day, you don't have battery left...
BTW, the same holds for innovative mobile VoIP apps such as Fling.

For a mobile unit to be a peer, we need a battery revolution.
g-)

Wei Gengyu wrote:
Hi,
 
A cell phone have full receiving capabilities in standby mode.
The cell phone will enter the active mode (you said "talk" mode)
after receiving a paging frame containing "setup" message destined to it. 
 
In standby mode, it can listen any messages of signalling and/or IP packets.
So, yes it is possible to have a phone in low-power standby mode but (for example) listening for incoming TCP connections or UDP packets.
 
However, the power consumption to send messages is mostly converned when the cell phone is in active mode.
 
But, I do not think this should be dominate P2PSIP overlay design in this stage.
 
 
Gengyu
----- Original Message -----
Sent: Thursday, June 28, 2007 6:41 AM
Subject: RE: [P2PSIP] do we need a client protocol?

That makes sense.  So my next question is: what are the capabilities of standby mode, and what triggers it going into “talk” mode?

 

It must be listening to some sort of cell signal even in standby mode, just so it can receive phone calls.  Given this, when in standby mode, does it also have access to the IP network?  In other words, is it possible to have a phone in low-power standby mode but (for example) listening for incoming TCP connections or UDP packets?

 

-david

 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 27, 2007 1:39 PM
To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

 

It is more complicated than this.

Under normal cell phone operation we have the talk time and the standby time which is much longer.

 

Making a cell phone a full peer eliminates this distinction to a large degree since the overlay maintenance messages keep the phone ‘talking’ all the time.

 

Henry

 

From: David Barrett [mailto:dbarrett@quinthar.com]
Sent: Wednesday, June 27, 2007 10:06 AM
To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

 

I don’t know anything about mobile application design vis-à-vis battery life, but I’m guessing power usage could be vastly oversimplified to something like:

 

Power = A + nB

 

Where A is the overall cost of just having the device powered on and listening to the radio, and B is the cost of sending a byte of data.  What I’m wondering is, what is the ratio of A to B?  Can anyone give real-world data?

 

For example, I’d accept that sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough value of ‘n’, then the constant A gets marginalized.  But what about 200Kbps or 200bps?  For some low value of ‘n’, then A dominates the power usage.

 

The reason I ask is I wonder if it’s even useful to discuss power usage for something like P2PSIP.  It could be that even for a “real” peer, ‘n’ is so low that the power consumption is dominated by other factors, rendering the entire discussion moot.

 

Can anybody give real-world data on this topic?

 

-david

 

From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]
Sent: Wednesday, June 27, 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

 

Hi,

 

We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the network). However there are also many entry-level/low-end devices that have slow CPUs and limited memory. 

Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is calling/answering a call).

    

I was considering a similar solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches.

 

I assume that we will have some mobile terminals taking part in DHT and some accessing resources stored in DHT using a client protocol.


Marcin

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007 02:26
To: Alan Johnston
Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do we need a client protocol?

 

On 6/26/07, Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought lately, thinking about the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer protocol.

For example, a normal peer in the overlay will maintain peer protocol
connections with many (perhaps dozens) of peers.  Why?  So that it can
quickly and efficiently route requests within the overlay.

 

 

Perhaps an energy-limited device could just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests through the
overlay, but that seems like a reasonable tradeoff.


The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms.

 

Also, perhaps there are some other peer protocol functions, such as data
replication (storage would still be done, but not replication), that
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that those peers
who contribute the least to the overlay also get the lowest performance
from it.



I am not quite sure I understand the benefit of introducing such various levels of participation.
Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.

Thanks.

Eunsoo

 

Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It certainly
> seems that a peer that moves between contributing and non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into the
> DHT "right now" might determine whether it is contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why something
>> is a peer if it isn't doing anything other than talking to someone
>> and making requests, hence why I supported client in the first place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. It
>> seems completely not in keeping with the idea of P2P. I also worry it
>>  is likely to be very confusing since we've been using the other
>> terminology for over a year now. Just looks like a souce of confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish to
> contribute resources, and sometimes not have a high-bandwidth connection
> and therefore not wish to offer resources. Does this modality make it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would I be
>> contributing? If joining the overlay (in the sense that we have a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer no
>>
> services
>
> That's "offer no other services", since routing is itself a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and a
>> "non-contributing peer" who isn't even part of the overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For most DHT models,
> a minimally contributing node will route a request it receives. It might
> ask nicely (perhaps a q-value mechanism) to not have to route requests,
> but would probably mathematically still have to route something it gets.
>
> I think we distinguish based on the service advertisements from the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

 

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--------------080203070201080508040608-- --===============0994363005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0994363005==-- From p2psip-bounces@ietf.org Thu Jun 28 07:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp4-0007pm-OG; Thu, 28 Jun 2007 07:06:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp4-0007ot-1T for p2psip@ietf.org; Thu, 28 Jun 2007 07:06:02 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3rp3-0004Ae-OQ for p2psip@ietf.org; Thu, 28 Jun 2007 07:06:01 -0400 Received: from vicinn.wightman.ca ([216.110.238.10] helo=[192.168.0.197]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I3rnT-00056h-1D; Thu, 28 Jun 2007 07:04:23 -0400 In-Reply-To: <46823621.2000105@teigre.com> References: <467F9225.3020000@teigre.com> <467FCAE0.3070506@teigre.com> <4d4304a00706250722s66d9e889o20d13461ac00dbbf@mail.gmail.com> <46823621.2000105@teigre.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80129EA8-8409-4339-80D0-B9213D4E9667@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... Date: Thu, 28 Jun 2007 05:52:21 -0400 To: Greger V. Teigre X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - vicinn.wightman.ca ([192.168.0.197]) [216.110.238.10] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 27-Jun-07, at 06:04 , Greger V. Teigre wrote: >> I agree that we should probably analyze the two NAT traversal >> mechanisms seperately, but I personally think we will find ICE is the >> answer in each case, and I really don't like the idea of having to >> implement two different NAT traversal techniques and do NAT traversal >> two times for the two protocols. > Well, ICE is clearly not the answer to all the NAT issues. ICE is > about detecting, while NAT has detection element, a routing > element, as well as a traversal complexity element (i.e. ALG/ > firewalls). It is made for offer/answer protocols and is suitable > to solve NAT from that point of view. > > draft-matthews-p2psip-hip-hop-00 offers an alternative where NAT > traversal is handled transparently. Deep in that draft and in the > references, there is something interesting found (from the "analyze- > in-layers" perspective"). Let me try to pull it forward and > summarize from a NAT perspective (for the sake of discussion): > > IPsec has over the years had a lot of trouble with NAT traversal > and ALGs. It has gone through all the pains and with UDP- > encapsulation, NAT-T and port floating to port 4500, it has by now > fairly good NAT traversal characteristics. Let's say each peer > establishes IPsec tunnels with each peer, using their certificates > in IKE, and calculating a virtual IP address (peerID). We know > IPsec mostly as a network stack protocol, but why not implement it > on the application layer? (ref. ongoing draft-nikander-esp-beet- > mode-07) > > Implement p2p routing on top of it (HIP, dSIP, whatever you like), > using the peerID/IP address, and you have a virtual network between > all peers, all can establiFrom p2psip-bounces@ietf.org Thu Jun 28 07:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp4-0007pm-OG; Thu, 28 Jun 2007 07:06:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp4-0007ot-1T for p2psip@ietf.org; Thu, 28 Jun 2007 07:06:02 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3rp3-0004Ae-OQ for p2psip@ietf.org; Thu, 28 Jun 2007 07:06:01 -0400 Received: from vicinn.wightman.ca ([216.110.238.10] helo=[192.168.0.197]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I3rnT-00056h-1D; Thu, 28 Jun 2007 07:04:23 -0400 In-Reply-To: <46823621.2000105@teigre.com> References: <467F9225.3020000@teigre.com> <467FCAE0.3070506@teigre.com> <4d4304a00706250722s66d9e889o20d13461ac00dbbf@mail.gmail.com> <46823621.2000105@teigre.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80129EA8-8409-4339-80D0-B9213D4E9667@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Trying to grasp what we really are standardizing... Date: Thu, 28 Jun 2007 05:52:21 -0400 To: Greger V. Teigre X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - vicinn.wightman.ca ([192.168.0.197]) [216.110.238.10] X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 27-Jun-07, at 06:04 , Greger V. Teigre wrote: >> I agree that we should probably analyze the two NAT traversal >> mechanisms seperately, but I personally think we will find ICE is the >> answer in each case, and I really don't like the idea of having to >> implement two different NAT traversal techniques and do NAT traversal >> two times for the two protocols. > Well, ICE is clearly not the answer to all the NAT issues. ICE is > about detecting, while NAT has detection element, a routing > element, as well as a traversal complexity element (i.e. ALG/ > firewalls). It is made for offer/answer protocols and is suitable > to solve NAT from that point of view. > > draft-matthews-p2psip-hip-hop-00 offers an alternative where NAT > traversal is handled transparently. Deep in that draft and in the > references, there is something interesting found (from the "analyze- > in-layers" perspective"). Let me try to pull it forward and > summarize from a NAT perspective (for the sake of discussion): > > IPsec has over the years had a lot of trouble with NAT traversal > and ALGs. It has gone through all the pains and with UDP- > encapsulation, NAT-T and port floating to port 4500, it has by now > fairly good NAT traversal characteristics. Let's say each peer > establishes IPsec tunnels with each peer, using their certificates > in IKE, and calculating a virtual IP address (peerID). We know > IPsec mostly as a network stack protocol, but why not implement it > on the application layer? (ref. ongoing draft-nikander-esp-beet- > mode-07) > > Implement p2p routing on top of it (HIP, dSIP, whatever you like), > using the peerID/IP address, and you have a virtual network between > all peers, all can establish tunnels with each other (and maybe > negotiate dht to use etc), the p2p layer can provide the SIP UA > with a non-NATed network. All signaling is secured and relaying can > easily be offered as a service to the SIP layer. > > The benefit of layering is that you can reuse existing software > implementations directly, you leverage years of NAT traversal > experience, and you avoid that p2psip enabling of existing UAs > turns into a large software implementation project with lots of > uncertain characteristics. > > This is NOT intended as an argument in favor of hip-hop vs. dSIP, > rather an example to show why I don't like the NAT discussion to be > preempted as "ice will be the choice anyway." I'm afraid it will > prevent us from looking at other approaches (or reducing ice to the > subset we really need). I agree with much of what you said above. However, I would like to make a comment. Even if we push NAT traversal down to a lower layer (as you mention, and as draft-matthews-p2psip-hip-hop proposes), there is still the question of how the connections at that layer are established. I think they will use something very ICE-like. It may not be exactly ICE, because ICE is officially an extension of SDP, but if we extract out the basic concepts, they are independent of SDP or SIP. There ARE totally different approaches: MIDCOM or Microsoft's Universal Plug-n-Play (UPnP), for example (and there are others). But right now, none of these different approaches look very compelling to me. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 28 07:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp2-0007oL-Ey; Thu, 28 Jun 2007 07:06:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp0-0007gb-O0 for p2psip@ietf.org; Thu, 28 Jun 2007 07:05:58 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3rp0-0004AT-E9 for p2psip@ietf.org; Thu, 28 Jun 2007 07:05:58 -0400 Received: from vicinn.wightman.ca ([216.110.238.10] helo=[192.168.0.197]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I3rnP-00056h-2N; Thu, 28 Jun 2007 07:04:19 -0400 In-Reply-To: <003a01c7b85f$47bd4a20$6905a40a@china.huawei.com> References: <003a01c7b85f$47bd4a20$6905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 Date: Thu, 28 Jun 2007 05:19:05 -0400 To: JiangXingFeng X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - vicinn.wightman.ca ([192.168.0.197]) [216.110.238.10] X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jiang XingFeng: Thanks very much for your questions and comments. We are pleased that you are interested in the general idea of using HIP for P2PSIP. I have responded in-line. On 26-Jun-07, at 22:02 , JiangXingFeng wrote:sh tunnels with each other (and maybe > negotiate dht to use etc), the p2p layer can provide the SIP UA > with a non-NATed network. All signaling is secured and relaying can > easily be offered as a service to the SIP layer. > > The benefit of layering is that you can reuse existing software > implementations directly, you leverage years of NAT traversal > experience, and you avoid that p2psip enabling of existing UAs > turns into a large software implementation project with lots of > uncertain characteristics. > > This is NOT intended as an argument in favor of hip-hop vs. dSIP, > rather an example to show why I don't like the NAT discussion to be > preempted as "ice will be the choice anyway." I'm afraid it will > prevent us from looking at other approaches (or reducing ice to the > subset we really need). I agree with much of what you said above. However, I would like to make a comment. Even if we push NAT traversal down to a lower layer (as you mention, and as draft-matthews-p2psip-hip-hop proposes), there is still the question of how the connections at that layer are established. I think they will use something very ICE-like. It may not be exactly ICE, because ICE is officially an extension of SDP, but if we extract out the basic concepts, they are independent of SDP or SIP. There ARE totally different approaches: MIDCOM or Microsoft's Universal Plug-n-Play (UPnP), for example (and there are others). But right now, none of these different approaches look very compelling to me. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 28 07:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp2-0007oL-Ey; Thu, 28 Jun 2007 07:06:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rp0-0007gb-O0 for p2psip@ietf.org; Thu, 28 Jun 2007 07:05:58 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3rp0-0004AT-E9 for p2psip@ietf.org; Thu, 28 Jun 2007 07:05:58 -0400 Received: from vicinn.wightman.ca ([216.110.238.10] helo=[192.168.0.197]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I3rnP-00056h-2N; Thu, 28 Jun 2007 07:04:19 -0400 In-Reply-To: <003a01c7b85f$47bd4a20$6905a40a@china.huawei.com> References: <003a01c7b85f$47bd4a20$6905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: draft-matthews-p2psip-hip-hop-00 Date: Thu, 28 Jun 2007 05:19:05 -0400 To: JiangXingFeng X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - vicinn.wightman.ca ([192.168.0.197]) [216.110.238.10] X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jiang XingFeng: Thanks very much for your questions and comments. We are pleased that you are interested in the general idea of using HIP for P2PSIP. I have responded in-line. On 26-Jun-07, at 22:02 , JiangXingFeng wrote: > > [JiangXingFeng]Do you want to make the distributed transported > function so > general that all application messages could be forwarded in the > overlay? Yes. In our proposal, the distributed transport function can transport many different application protocols, and is not limited to just SIP. We feel that, if P2PSIP is successful, then people will want to use it for other protocols. Take a look, for example, at the various IM services one has today (Skype, GoogleTalk, MSN Messenger, ...). In these services, not only can exchange voice and video, but one can also use it to push a file from one client to another. We feel that, if we limit ourselves to just SIP, then people will just use SIP to carry other protocols, something that we think is a bad idea (and the SIP group agrees with us). > > 2. o Network layer: The ability to deliver a message to an > arbitrary peer > in the overlay. In our view, this involves adding a header to the > message > that specifies the destination peer ID and then routing that > message along > existing connections in the overlay to the destination peer. > > [JiangXingFeng] What does the network layer refer to? IP layer or > overlay > network layer? > In my opinion, it refers to overlay network layer here. Yes. We used the term "network layer' because HIP plays a role in an overlay that is very similar to the role IP plays in IP routing. > > 4. There are two ways to send a packet to another peer in the > overlay: > send it on a direct connection to the remote peer, or send it > hop-by- > hop through the overlay. A peer typically uses hop-by-hop routing > when it has only a small amount of data to transfer to the remote > peer (for example, a Distributed Database update or a SIP INVITE > transaction), and sets up a direct connection when it has a larger > amount of data to transfer (for example, an RTP session). > > In my opinion, only the peer protocol message should be routed hop- > by-hop > through the overlay? Like the comments in 1, how does the admitting > peer > process the application message? Maybe the peer does not recognize the > specific application message? The question is: What do we do if peer X want to send an application message to peer Y, and there is no direct connection between peer X and peer Y. Does peer X first set up a direct connection, and then send the message, or does the application message get sent hop-by-hop through the overlay? In our proposal, both are possible, and we have not yet specified the details of how the choice would be made. For some protocols, sending hop-by-hop makes more sense, while for other protocols, first establishing a direct connection makes more sense. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > > [JiangXingFeng]Do you want to make the distributed transported > function so > general that all application messages could be forwarded in the > overlay? Yes. In our proposal, the distributed transport function can transport many different application protocols, and is not limited to just SIP. We feel that, if P2PSIP is successful, then people will want to use it for other protocols. Take a look, for example, at the various IM services one has today (Skype, GoogleTalk, MSN Messenger, ...). In these services, not only can exchange voice and video, but one can also use it to push a file from one client to another. We feel that, if we limit ourselves to just SIP, then people will just use SIP to carry other protocols, something that we think is a bad idea (and the SIP group agrees with us). > > 2. o Network layer: The ability to deliver a message to an > arbitrary peer > in the overlay. In our view, this involves adding a header to the > message > that specifies the destination peer ID and then routing that > message along > existing connections in the overlay to the destination peer. > > [JiangXingFeng] What does the network layer refer to? IP layer or > overlay > network layer? > In my opinion, it refers to overlay network layer here. Yes. We used the term "network layer' because HIP plays a role in an overlay that is very similar to the role IP plays in IP routing. > > 4. There are two ways to send a packet to another peer in the > overlay: > send it on a direct connection to the remote peer, or send it > hop-by- > hop through the overlay. A peer typically uses hop-by-hop routing > when it has only a small amount of data to transfer to the remote > peer (for example, a Distributed Database update or a SIP INVITE > transaction), and sets up a direct connection when it has a larger > amount of data to transfer (for example, an RTP session). > > In my opinion, only the peer protocol message should be routed hop- > by-hop > through the overlay? Like the comments in 1, how does the admitting > peer > process the application message? Maybe the peer does not recognize the > specific application message? The question is: What do we do if peer X want to send an application message to peer Y, and there is no direct connection between peer X and peer Y. Does peer X first set up a direct connection, and then send the message, or does the application message get sent hop-by-hop through the overlay? In our proposal, both are possible, and we have not yet specified the details of how the choice would be made. For some protocols, sending hop-by-hop makes more sense, while for other protocols, first establishing a direct connection makes more sense. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 28 07:06:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rpE-0000TA-Fr; Thu, 28 Jun 2007 07:06:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3rpC-0000I9-Lw for p2psip@ietf.org; Thu, 28 Jun 2007 07:06:10 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3rpC-0004EI-FQ for p2psip@ietf.org; Thu, 28 Jun 2007 07:06:10 -0400 Received: from vicinn.wightman.ca ([216.110.238.10] helo=[192.168.0.197]) by mail-05.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I3rnw-00056h-1X; Thu, 28 Jun 2007 07:04:52 -0400 In-Reply-To: <7b683f3f0706261625p70f76bd1s6ce2a92528213dae@mail.gmail.com> References: <0D364DEE-7B0C-4F6E-BF7B-39146071F0DE@softarmor.com> <4d4304a00706140616j6b172f45i14d2f5c62f1f2685@mail.gmail.com> <46723027.9010902@softarmor.com> <24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com> <46819BA0.2030901@sipstation.com> <7b683f3f0706261625p70f76bd1s6ce2a92528213dae@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] do we need a client protocol? Date: Wed, 27 Jun 2007 10:56:42 -0400 To: "Eunsoo Shim" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - vicinn.wightman.ca ([192.168.0.197]) [216.110.238.10] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Avshalom Houri , Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 26-Jun-07, at 19:25 , Eunsoo Shim wrote: > > The underling algorithm (e.g. a certain DHT algorithm) will dictate > the number of connections even though there might be some room for > adjustment. I don't think it is under complete control of > individual peer in the case of known DHT algorithms. In the case of Chord, though Chord specifies a connection pattern based on powers of two, the search and routing algorithm will still work with fewer connections. However, the efficiency of the search and routing algorithm will decrease. If just ONE peer does this, the efficiency will not decrease greatly, but if all do, then it will. > > Also, perhaps there are some other peer protocol functions, such as > data > replication (storage would still be done, but not replication), that > could be skipped by these energy-limited peers. Perhaps their > requests > and responses could be routed over the overlay with a lower priority > than full peers. We need to manage the tradeoffs so that those peers > who contribute the least to the overlay also get the lowest > performance > from it. > > > I am not quite sure I understand the benefit of introducing such > various levels of participation. > Having a client protocol seems to be much simpler and easier than > introducing these various levels of participation. There is a chance that we might need to do both. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jun 28 07:56:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sbY-0001bC-Bd; Thu, 28 Jun 2007 07:56:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3sbW-0001b6-FK for p2psip@ietf.org; Thu, 28 Jun 2007 07:56:06 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3sbU-00084V-7p for p2psip@ietf.org; Thu, 28 Jun 2007 07:56:06 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SBtIb9011569; Thu, 28 Jun 2007 14:55:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 14:55:18 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 14:55:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Thu, 28 Jun 2007 14:57:55 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04A470B8@esebe102.NOE.Nokia.com> In-Reply-To: <200706271706.l5RH6JOi001363@mgw-mx03.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace4SXgaj2ZLzz95R0yk/2vR0eR/aAAP/Q4QABEXISAAKTI/IA== References: <3F18E76823C95E4795181D74BAC7664F049E8BC7@esebe102.NOE.Nokia.com> <200706271706.l5RH6JOi001363@mgw-mx03.nokia.com> From: To: , , X-OriginalArrivalTime: 28 Jun 2007 11:55:17.0793 (UTC) FILETIME=[32370110:01C7B97B] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: c892b762daa2dd1ca407c1f421df8b92 Cc: hsinnrei@adobe.com, AVSHALOM@il.ibm.com, philip_matthews@magma.ca, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1602077170==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1602077170== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B97B.31F2AB31" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B97B.31F2AB31 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David, =20 It is more complex that your formula. The problem is with constant = background traffic that keeps a radio interface on. There are = differences between cellular and WLAN interfaces. The cellular = interfaces are more optimized for idle state than the WLAN. I cannot = send you a link to a document about power management in mobile = peer-to-peer networks but two guys from my team are writing a paper = about this topic. I will send the paper to the mailing list when it is = accepted to a conference. =20 For now I can tell that constant background traffic may reduce the = battery life to couple of hours. =20 I would appreciate any reference to a document presenting a traffic = model in P2PSIP networks. Are you aware of such a document? =20 Marcin =20 ________________________________ From: ext David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: 27 June, 2007 20:06 To: Matuszewski Marcin (Nokia-NRC/Helsinki); eunsooshim@gmail.com; = alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =09 =09 I don't know anything about mobile application design vis-=E0-vis = battery life, but I'm guessing power usage could be vastly = oversimplified to something like: =20 Power =3D A + nB =20 Where A is the overall cost of just having the device powered on and = listening to the radio, and B is the cost of sending a byte of data. = What I'm wondering is, what is the ratio of A to B? Can anyone give = real-world data? =20 For example, I'd accept that sending 200Mbps probably requires about 2x = the power 100Mbps: for a high enough value of 'n', then the constant A = gets marginalized. But what about 200Kbps or 200bps? For some low = value of 'n', then A dominates the power usage. =20 The reason I ask is I wonder if it's even useful to discuss power usage = for something like P2PSIP. It could be that even for a "real" peer, 'n' = is so low that the power consumption is dominated by other factors, = rendering the entire discussion moot. =20 Can anybody give real-world data on this topic? =20 -david=20 =20 =09 ________________________________ From: marcin.matuszewski@nokia.com = [mailto:marcin.matuszewski@nokia.com]=20 Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile = terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of = mobile terminals may become peers (depending on the case scenario: = churn, size of the network). However there are also many = entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long = battery life. DHT maintenance and handling searches have impact on idle = state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number = of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and = some accessing resources stored in DHT using a client protocol. =09 Marcin =09 ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =20 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the = actual requirements. =09 We want to allow energy-limited devices to participate to some level = in P2PSIP. As such, perhaps instead of saying we need a client = protocol,=20 perhaps we just need levels of participation in the overlay peer = protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can = quickly and efficiently route requests within the overlay. =20 =20 Perhaps an energy-limited device could just minimize the number of = peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 =09 The underling algorithm (e.g. a certain DHT algorithm) will dictate = the number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual = peer in the case of known DHT algorithms.=20 =20 Also, perhaps there are some other peer protocol functions, such as = data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their = requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest = performance from it. =09 =09 I am not quite sure I understand the benefit of introducing such = various levels of participation. Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =20 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client = protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care = about the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) = entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If = so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and = non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into = the > DHT "right now" might determine whether it is contributing "right = now" > or not. > > >> My concern all along has been that I don't understand why = something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first = place. >> I fail to see how something that isn't contributing anything, and = >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry = it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make = it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I = be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a = service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., = no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets = pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely = peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------_=_NextPart_001_01C7B97B.31F2AB31 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi David,
 
It is more complex that your formula. = The problem=20 is with constant background traffic that keeps a radio interface = on. There=20 are differences between cellular and WLAN interfaces. The cellular=20 interfaces are more optimized for idle state than the WLAN. I = cannot=20 send you a link to a document about power management = in=20 mobile peer-to-peer networks but two guys from my team are writing = a paper=20 about this topic. I will send the paper to the mailing list when it = is=20 accepted to a conference.
 
For now I can tell that constant = background traffic=20 may reduce the battery life to couple of hours.
 
I would appreciate any reference to a = document=20 presenting a traffic model in P2PSIP networks. Are you aware of = such a=20 document?
 
Marcin   

From: ext David Barrett=20 [mailto:dbarrett@quinthar.com]
Sent: 27 June, 2007=20 20:06
To: Matuszewski Marcin (Nokia-NRC/Helsinki);=20 eunsooshim@gmail.com; alan@sipstation.com
Cc: = hsinnrei@adobe.com;=20 AVSHALOM@il.ibm.com; philip_matthews@magma.ca;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I don=92t = know anything=20 about mobile application design vis-=E0-vis battery life, but I=92m = guessing power=20 usage could be vastly oversimplified to something=20 like:

 

Power =3D=20 A + nB

 

Where A is = the=20 overall cost of just having the device powered on and listening to the = radio,=20 and B is the cost of sending a byte of data.  What I=92m = wondering is, what=20 is the ratio of A to B?  Can anyone give real-world=20 data?

 

For = example, I=92d=20 accept that sending 200Mbps probably requires about 2x the power = 100Mbps: for=20 a high enough value of =91n=92, then the constant A gets = marginalized.  But=20 what about 200Kbps or 200bps?  For some low value of =91n=92, = then A=20 dominates the power usage.

 

The reason = I ask is I=20 wonder if it=92s even useful to discuss power usage for something like = P2PSIP.  It could be that even for a =93real=94 peer, =91n=92 is = so low that the=20 power consumption is dominated by other factors, rendering the entire=20 discussion moot.

 

Can anybody = give=20 real-world data on this topic?

 

-david=20

 

From:=20 marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]=20
Sent: Wednesday, = June 27,=20 2007 12:33 AM
To:=20 eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com;=20 AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a client=20 protocol?

 

Hi,

 

We have = wide=20 variety of mobile terminals. The capabilities of mobile = terminals=20 are constantly improving e.g. even now Nokia's = N-series/E-series=20 devices are very powerful. From this reason some of mobile=20 terminals may become peers (depending on the case scenario: = churn, size=20 of the network). However there are=20 also many entry-level/low-end devices that have slow = CPUs=20 and limited memory. 

Battery life is = another=20 issue. Most of the mobile phone users want long battery life. DHT = maintenance and handling searches have impact on idle state that = is more=20 important from battery life perspective than the active = state (e.g.=20 when user is calling/answering a call).

    

I was=20 considering a similar solution to the one that Alan proposed however = as Eunsoo=20 said it would be quite difficult to control the number of=20 connections in DHT. We also have problems with handling=20 searches.

 

I assume=20 that we will have some mobile terminals taking part in DHT and = some=20 accessing resources stored in DHT using a client=20 protocol.


Marcin

From: ext=20 Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; Avshalom = Houri;=20 Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do we = need a=20 client protocol?

 

On 6/26/07, Alan Johnston <alan@sipstation.com>=20 wrote:

I've been giving this a lot of thought = lately,=20 thinking about the actual
requirements.

We want to allow=20 energy-limited devices to participate to some level=20 in
P2PSIP.   As such, perhaps instead of saying we need = a=20 client protocol,
perhaps we just need levels of participation in = the=20 overlay peer protocol.

For example, a normal peer in the = overlay will=20 maintain peer protocol
connections with many (perhaps dozens) of=20 peers.  Why?  So that it can
quickly and = efficiently=20 route requests within the overlay.

 

 

Perhaps an energy-limited device could = just=20 minimize the number of peer
protocol connections it maintains, = perhaps=20 even down to a minimum of
two.  This would result in = slower=20 routing of its requests through the
overlay, but that seems = like a=20 reasonable tradeoff.


The underling algorithm (e.g. a = certain DHT=20 algorithm) will dictate the number of connections even though there = might be=20 some room for adjustment. I don't think it is under complete control = of=20 individual peer in the case of known DHT algorithms.=20

 

Also, perhaps there are some other peer = protocol=20 functions, such as data
replication (storage would still be = done, but=20 not replication), that
could be skipped by these = energy-limited=20 peers.  Perhaps their requests
and responses could be = routed=20 over the overlay with a lower priority
than full = peers.  We=20 need to manage the tradeoffs so that those peers
who contribute = the=20 least to the overlay also get the lowest performance
from=20 it.



I am not quite sure = I=20 understand the benefit of introducing such various levels of=20 participation.
Having a client protocol seems to be much simpler = and=20 easier than introducing these various levels of participation.=20

Thanks.

Eunsoo

 

Henry Sinnreich wrote:
> = Folks,
>=20
> Given the length of the discussion on "do we need a = client=20 protocol?"
> let me repeat the simple imperatives for the=20 client:
>
> - Limited battery in mobile devices,=20 and
>
> - Other uses besides SIP. Business planning = folks may=20 not care about the
> WG charter, but about the return on = the=20 investment.
>
> Thanks, Henry
>
> = -----Original=20 Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com=20 ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: = David A.=20 Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip=20 Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal = for=20 active/passive
> peerterminology
>
> David A. = Bryan=20 wrote:
>
>> If I understand this right, not sure I = like it.=20 Do these
>>
> "non-contributing
>
>> = peer"=20 (I *do* like contributing better than active/passive) entities=20
>>
> have a
>
>> Peer-ID? In = otherwords,=20 are they part of the overlay at all? If so,
>>
>=20 for
>
>> most
>> DHTs, how do we allow you = to be=20 in the overlay and not store resources
>>
>=20 (not
>
>> typical for most current DHT=20 algorithms)
>>
>
> Well, that certainly = depends on=20 the DHT algorithm involved. It certainly
> seems that a peer = that=20 moves between contributing and non-contributing
> might = HAVE a peer=20 ID, but whether it chooses to insert itself into the
> DHT = "right=20 now" might determine whether it is contributing "right = now"
> or=20 not.
>
>
>> My concern all along has been = that I=20 don't understand why something
>> is a peer if it isn't = doing=20 anything other than talking to someone
>> and making = requests,=20 hence why I supported client in the first = place.
>>  I=20 fail to see how something that isn't contributing anything, and=20
>> instead talks to a peer to get resources, is in any = way a=20 peer. It
>> seems completely not in keeping with the idea = of P2P.=20 I also worry it
>>  is likely to be very = confusing=20 since we've been using the other
>> terminology for over = a year=20 now. Just looks like a souce of = confusion.
>>
>
> A=20 node might sometimes have a high-bandwidth connection and wish = to
>=20 contribute resources, and sometimes not have a high-bandwidth = connection=20
> and therefore not wish to offer resources. Does this = modality=20 make it
> two different nodes?
>
>
>> = If we do=20 go this way, there is one subtle point. If I join the=20 overlay
>>
> but
>
>> don't happen = to offer=20 any services (other than maybe
>>
> = storage...depending=20 on
>
>> how we definie it, that might or might not = be=20 mandatory), would I be
>> contributing? If joining the = overlay=20 (in the sense that we have a
>>
>=20 PeerID
>
>> and
>> we route traffic) = doesn't=20 require me to store, I could offer no
>>
>=20 services
>
> That's "offer no other services", since = routing=20 is itself a service.
>
>
>> and
>> = still be=20 a peer. How do we distinguish between this case and a
>>=20 "non-contributing peer" who isn't even part of the overlay (i.e.,=20 no
>> Peer-ID)
>>
>
> I think = there's a=20 range of "contributing" in play. For most DHT models,
> a = minimally=20 contributing node will route a request it receives. It = might
> ask=20 nicely (perhaps a q-value mechanism) to not have to route=20 requests,
> but would probably mathematically still have to = route=20 something it gets.
>
> I think we distinguish based = on the=20 service advertisements from the
> = peer.
>
>
>>=20 If we are so opposed to client for confusion with SIP UAs, lets = pick=20 a
>>
> new
>
>> name, but why some = flavor=20 of peer when it does nothing remotely peer
>>
>=20 like?
>
> Because in 15 minutes it might roam onto a = WiFi net=20 and therefore change
> it service offering.
>
> = --
> Dean
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
>=20 https://www1.ietf.= org/mailman/listinfo/p2psip
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
>=20 https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


______= _________________________________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

=

 

------_=_NextPart_001_01C7B97B.31F2AB31-- --===============1602077170== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1602077170==-- From p2psip-bounces@ietf.org Thu Jun 28 08:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3spI-0000Yi-Dj; Thu, 28 Jun 2007 08:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3spH-0000WE-Qg for p2psip@ietf.org; Thu, 28 Jun 2007 08:10:19 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I3sp2-0000zj-Uw for p2psip@ietf.org; Thu, 28 Jun 2007 08:10:19 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5SCA0A2024921; Thu, 28 Jun 2007 15:10:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 15:09:45 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 15:09:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Thu, 28 Jun 2007 15:12:22 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04A470EE@esebe102.NOE.Nokia.com> In-Reply-To: <468351F0.50404@teigre.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace5S8Uw4KdrrjwxQa6JUgFfZvNK8QAMHhyg References: <003801c7b92f$09ced5a0$a507740a@DELLWEI> <468351F0.50404@teigre.com> From: To: X-OriginalArrivalTime: 28 Jun 2007 12:09:44.0901 (UTC) FILETIME=[370D2F50:01C7B97D] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 93d650243b45b29a5ce3eb511e99a1db Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1589338121==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1589338121== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B97D.36C4227B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B97D.36C4227B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Greger, =20 I agree with you that most of mobile terminals that are available on the = market cannot became peers. Actually it is not black and white they can = but everything depends on the size of a P2P network, used DHT and a = traffic model. We must remember that the standard will be ready in a = couple of years when we may have more devices that are peer capable.=20 =20 Marcin=20 ________________________________ From: ext Greger V. Teigre [mailto:greger@teigre.com]=20 Sent: 28 June, 2007 09:15 To: Wei Gengyu Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? =09 =09 Well, it's a bit more complicated than that. For one thing, there's a = difference between mobile and WLAN. Even with the power-saving mode of = 802.11g for example, there's still more power drain when connected to = WLAN, than mobile. And on mobile, you have many scenarios, just take the = GSM (which I know the best), you have GSM High-Speed, still used by many = roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data = connections. You can have three modes, each with different power = consumption: No connection (only voice), PDP context established, and = active connection. Real-life experimentation with various modes and = applications using these modes show that battery drainage is a real = problem.=20 As an example: a native Symbian application that looks up incoming = calls (over 3G data connection) where caller-id is not found in the = local contact list needs to have an active connection (not only PDP = context), because in order to show the caller's data, the lookup must be = almost instantaneous. In reality, it takes about 1 second. This = application is pretty much useless if you actually make any calls, = because at the end of the day, you don't have battery left... BTW, the same holds for innovative mobile VoIP apps such as Fling. =09 For a mobile unit to be a peer, we need a battery revolution. g-) =09 Wei Gengyu wrote:=20 Hi,=20 =20 A cell phone have full receiving capabilities in standby mode. The cell phone will enter the active mode (you said "talk" mode)=20 after receiving a paging frame containing "setup" message destined to = it.=20 =20 In standby mode, it can listen any messages of signalling and/or IP = packets. So, yes it is possible to have a phone in low-power standby mode but = (for example) listening for incoming TCP connections or UDP packets. =20 However, the power consumption to send messages is mostly converned = when the cell phone is in active mode.=20 =20 But, I do not think this should be dominate P2PSIP overlay design in = this stage. =20 =20 Gengyu ----- Original Message -----=20 From: David Barrett =20 To: 'Henry Sinnreich' ; = marcin.matuszewski@nokia.com ; eunsooshim@gmail.com ; = alan@sipstation.com=20 Cc: AVSHALOM@il.ibm.com ; philip_matthews@magma.ca ; p2psip@ietf.org=20 Sent: Thursday, June 28, 2007 6:41 AM Subject: RE: [P2PSIP] do we need a client protocol? That makes sense. So my next question is: what are the capabilities = of standby mode, and what triggers it going into "talk" mode? =09 It must be listening to some sort of cell signal even in standby = mode, just so it can receive phone calls. Given this, when in standby = mode, does it also have access to the IP network? In other words, is it = possible to have a phone in low-power standby mode but (for example) = listening for incoming TCP connections or UDP packets? =09 -david =09 =09 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 27, 2007 1:39 PM To: David Barrett; marcin.matuszewski@nokia.com; = eunsooshim@gmail.com; alan@sipstation.com Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =09 It is more complicated than this. Under normal cell phone operation we have the talk time and the = standby time which is much longer. =09 Making a cell phone a full peer eliminates this distinction to a = large degree since the overlay maintenance messages keep the phone = 'talking' all the time. =09 Henry =09 =09 ________________________________ From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Wednesday, June 27, 2007 10:06 AM To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =09 I don't know anything about mobile application design vis-=E0-vis = battery life, but I'm guessing power usage could be vastly = oversimplified to something like: =09 Power =3D A + nB =09 Where A is the overall cost of just having the device powered on and = listening to the radio, and B is the cost of sending a byte of data. = What I'm wondering is, what is the ratio of A to B? Can anyone give = real-world data? =09 For example, I'd accept that sending 200Mbps probably requires about = 2x the power 100Mbps: for a high enough value of 'n', then the constant = A gets marginalized. But what about 200Kbps or 200bps? For some low = value of 'n', then A dominates the power usage. =09 The reason I ask is I wonder if it's even useful to discuss power = usage for something like P2PSIP. It could be that even for a "real" = peer, 'n' is so low that the power consumption is dominated by other = factors, rendering the entire discussion moot. =09 Can anybody give real-world data on this topic? =09 -david=20 =09 =09 ________________________________ From: marcin.matuszewski@nokia.com = [mailto:marcin.matuszewski@nokia.com]=20 Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; = philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =09 Hi, =09 We have wide variety of mobile terminals. The capabilities of mobile = terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of = mobile terminals may become peers (depending on the case scenario: = churn, size of the network). However there are also many = entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on = idle state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number = of connections in DHT. We also have problems with handling searches. =09 I assume that we will have some mobile terminals taking part in DHT = and some accessing resources stored in DHT using a client protocol. =09 Marcin =09 ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =09 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the = actual requirements. =09 We want to allow energy-limited devices to participate to some level = in P2PSIP. As such, perhaps instead of saying we need a client = protocol,=20 perhaps we just need levels of participation in the overlay peer = protocol. =09 For example, a normal peer in the overlay will maintain peer = protocol connections with many (perhaps dozens) of peers. Why? So that it = can=20 quickly and efficiently route requests within the overlay. =09 =09 Perhaps an energy-limited device could just minimize the number of = peer protocol connections it maintains, perhaps even down to a minimum = of two. This would result in slower routing of its requests through = the overlay, but that seems like a reasonable tradeoff.=20 =09 The underling algorithm (e.g. a certain DHT algorithm) will dictate = the number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual = peer in the case of known DHT algorithms.=20 =09 Also, perhaps there are some other peer protocol functions, such as = data replication (storage would still be done, but not replication), = that=20 could be skipped by these energy-limited peers. Perhaps their = requests and responses could be routed over the overlay with a lower = priority than full peers. We need to manage the tradeoffs so that those = peers who contribute the least to the overlay also get the lowest = performance from it. =09 =09 I am not quite sure I understand the benefit of introducing such = various levels of participation. Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =09 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client = protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care = about the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) = entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If = so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and = non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself = into the > DHT "right now" might determine whether it is contributing "right = now" > or not. > > >> My concern all along has been that I don't understand why = something=20 >> is a peer if it isn't doing anything other than talking to = someone >> and making requests, hence why I supported client in the first = place. >> I fail to see how something that isn't contributing anything, = and=20 >> instead talks to a peer to get resources, is in any way a peer. = It >> seems completely not in keeping with the idea of P2P. I also = worry it >> is likely to be very confusing since we've been using the other = >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish = to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality = make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would = I be >> contributing? If joining the overlay (in the sense that we have = a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a = service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay = (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. = It might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something = it gets.=20 > > I think we distinguish based on the service advertisements from = the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets = pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely = peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 =09 ________________________________ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 =09 ________________________________ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------_=_NextPart_001_01C7B97D.36C4227B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Greger,
 
I agree with you that most of mobile terminals = that are=20 available on the market cannot became peers. Actually it is = not black=20 and white they can but everything depends on the size of a P2P = network, used DHT and a traffic model. We must remember that the = standard=20 will be ready in a couple of years when we may have more devices that = are peer=20 capable.
 
Marcin 

From: ext Greger V. Teigre=20 [mailto:greger@teigre.com]
Sent: 28 June, 2007 = 09:15
To:=20 Wei Gengyu
Cc: p2psip@ietf.org
Subject: Re: = [P2PSIP] do we=20 need a client protocol?

Well, it's a bit more complicated than that. For one thing, = there's=20 a difference between mobile and WLAN. Even with the power-saving mode = of=20 802.11g for example, there's still more power drain when connected to = WLAN,=20 than mobile. And on mobile, you have many scenarios, just take the GSM = (which=20 I know the best), you have GSM High-Speed, still used by many = roadwarriors in=20 many areas of the world, and you have GPRS/EDGE/3G data connections. = You can=20 have three modes, each with different power consumption: No connection = (only=20 voice), PDP context established, and active connection. Real-life=20 experimentation with various modes and applications using these modes = show=20 that battery drainage is a real problem.
As an example: a native = Symbian=20 application that looks up incoming calls (over 3G data connection) = where=20 caller-id is not found in the local contact list needs to have an = active=20 connection (not only PDP context), because in order to show the = caller's data,=20 the lookup must be almost instantaneous. In reality, it takes about 1=20 second.  This application is pretty much useless if you actually = make any=20 calls, because at the end of the day, you don't have battery = left...
BTW,=20 the same holds for innovative mobile VoIP apps such as = Fling.

For a=20 mobile unit to be a peer, we need a battery = revolution.
g-)

Wei=20 Gengyu wrote:=20
Hi,
 
A cell phone have full = receiving capabilities in standby mode.
The cell = phone will enter the active=20 mode (you said "talk" mode)
after receiving a paging = frame containing "setup"=20 message destined to it. 
 
In standby mode, it can = listen any=20 messages of signalling and/or IP packets.
So, yes it is=20 possible to have a phone in low-power standby mode but (for example) = listening for incoming TCP connections or UDP = packets.
 
However, the power=20 consumption to send messages is mostly converned=20 when the cell phone is in active mode. =
 
But, I do not = think this should be=20 dominate P2PSIP overlay design in this stage.
 
 
Gengyu
-----=20 Original Message ----- From:=20 David Barrett To:=20 'Henry Sinnreich' ; marcin.matuszewski@nokia.com ; eunsooshim@gmail.com ; alan@sipstation.com Cc:=20 AVSHALOM@il.ibm.com ; philip_matthews@magma.ca ; p2psip@ietf.org Sent:=20 Thursday, June 28, 2007 6:41 AM Subject:=20 RE: [P2PSIP] do we need a client protocol?

That = makes=20 sense.  So my next question is: what are the capabilities of = standby=20 mode, and what triggers it going into =93talk=94=20 mode?

It must = be=20 listening to some sort of cell signal even in standby mode, just = so it can=20 receive phone calls.  Given this, when in standby mode, does = it also=20 have access to the IP network?  In other words, is it = possible to=20 have a phone in low-power standby mode but (for example) listening = for=20 incoming TCP connections or UDP = packets?

-david

From:=20 Henry Sinnreich [mailto:hsinnrei@adobe.com]=20
Sent: = Wednesday, June=20 27, 2007 1:39 PM
To:=20 David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

It is = more=20 complicated than this.

Under = normal cell=20 phone operation we have the talk time and the standby time which = is much=20 longer.

Making = a cell=20 phone a full peer eliminates this distinction to a = large degree since the overlay = maintenance=20 messages keep the phone =91talking=92 all the=20 time.

Henry

From:=20 David Barrett [mailto:dbarrett@quinthar.com]=20
Sent: = Wednesday, June=20 27, 2007 10:06 AM
To: marcin.matuszewski@nokia.com= ;=20 eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

I = don=92t know=20 anything about mobile application design vis-=E0-vis battery life, = but I=92m=20 guessing power usage could be vastly oversimplified to something=20 like:

Power = =3D A +=20 nB

Where A = is the=20 overall cost of just having the device powered on and listening to = the=20 radio, and B is the cost of sending a byte of data.  What = I=92m=20 wondering is, what is the ratio of A to B?  Can anyone give=20 real-world data?

For = example, I=92d=20 accept that sending 200Mbps probably requires about 2x the power = 100Mbps:=20 for a high enough value of =91n=92, then the constant A gets = marginalized.  But what about = 200Kbps or=20 200bps?  For some low value of =91n=92, then A dominates the = power=20 usage.

The = reason I ask=20 is I wonder if it=92s even useful to discuss power usage for = something like=20 P2PSIP.  It could be that even for a =93real=94 peer, =91n=92 = is so low that=20 the power consumption is dominated by other factors, rendering the = entire=20 discussion moot.

Can = anybody give=20 real-world data on this topic?

-david=20

From: marcin.matuszewski@nokia.com= =20 [mailto:marcin.matuszewski@no= kia.com]=20
Sent: = Wednesday, June=20 27, 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,

We have = wide=20 variety of mobile terminals. The capabilities of mobile=20 terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason = some=20 of mobile terminals may become peers (depending on the = case=20 scenario: churn, size of the network). However there are=20 also many entry-level/low-end devices that = have slow CPUs=20 and limited memory. 

Battery life = is another=20 issue. Most of the mobile phone users want long battery = life. DHT=20 maintenance and handling searches have impact on idle state = that is=20 more important from battery life perspective than the = active=20 state (e.g. when user is calling/answering a=20 call).

    

I was=20 considering a similar solution to the one that Alan proposed = however as=20 Eunsoo said it would be quite difficult to control the = number of=20 connections in DHT. We also have problems with handling=20 searches.

I assume=20 that we will have some mobile terminals taking part in DHT = and some=20 accessing resources stored in DHT using a client=20 protocol.


Marcin

From:=20 ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20
Sent: 27 = June, 2007=20 02:26
To: = Alan=20 Johnston
Cc: = Henry=20 Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing=20 List
Subject: = Re:=20 [P2PSIP] do we need a client = protocol?

On 6/26/07, Alan Johnston <alan@sipstation.com>=20 wrote:

I've been giving this a lot of thought = lately,=20 thinking about the actual
requirements.

We want to = allow=20 energy-limited = devices to=20 participate to some level in
P2PSIP.   As such, = perhaps=20 instead of saying we need a client protocol,
perhaps we just = need=20 levels of participation in the overlay peer protocol.

For = example, a normal peer in the overlay will maintain peer=20 protocol
connections with many (perhaps dozens) of=20 peers.  Why?  So that it can
quickly and = efficiently route requests within the=20 overlay.

Perhaps an energy-limited device could just = minimize the=20 number of peer
protocol connections it maintains, perhaps = even down=20 to a minimum of
two.  This would result in slower = routing=20 of its requests through the
overlay, but that seems like a=20 reasonable tradeoff. =


The underling algorithm (e.g. a = certain DHT=20 algorithm) will dictate the number of connections even though = there=20 might be some room for adjustment. I don't think it is under = complete=20 control of individual peer in the case of known DHT algorithms.=20

Also, perhaps there are some other = peer=20 protocol functions, such as data
replication (storage would = still=20 be done, but not replication), that
could be skipped by = these=20 energy-limited=20 peers.  Perhaps their requests
and responses = could be=20 routed over the overlay with a lower priority
than full=20 peers.  We need to manage the tradeoffs so that = those=20 peers
who contribute the least to the overlay also get the = lowest=20 performance
from = it.



I am=20 not quite sure I understand the benefit of introducing such = various=20 levels of participation.
Having a client protocol seems to be = much=20 simpler and easier than introducing these various levels of=20 participation.=20

Thanks.

Eunsoo

Henry Sinnreich wrote:
> = Folks,
>=20
> Given the length of the discussion on "do we need a = client=20 protocol?"
> let me repeat the simple imperatives for = the=20 client:
>
> - Limited battery in mobile devices,=20 and
>
> - Other uses besides SIP. Business = planning folks=20 may not care about the
> WG charter, but about the = return on=20 the investment.
>
> Thanks, Henry
>
>=20 -----Original Message-----
> From: Dean Willis = [mailto:dean.willis@softarmor.com = ]
> Sent:=20 Thursday, June 14, 2007 11:23 PM
> To: David A. = Bryan
>=20 Cc: Avshalom Houri; P2PSIP Mailing List; Philip = Matthews
>=20 Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive=20
> peerterminology
>
> David A. Bryan=20 wrote:
>
>> If I understand this right, not = sure I like=20 it. Do these
>>
> = "non-contributing
>
>>=20 peer" (I *do* like contributing better than active/passive) = entities=20
>>
> have a
>
>> Peer-ID? In=20 otherwords, are they part of the overlay at all? If=20 so,
>>
> for
>
>> = most
>> DHTs,=20 how do we allow you to be in the overlay and not store = resources=20
>>
> (not
>
>> typical for most = current=20 DHT algorithms)
>>
>
> Well, that = certainly=20 depends on the DHT algorithm involved. It certainly
> = seems that=20 a peer that moves between contributing and non-contributing =
>=20 might HAVE a peer ID, but whether it chooses to insert itself = into=20 the
> DHT "right now" might determine whether it is = contributing=20 "right now"
> or not.
>
>
>> My = concern all=20 along has been that I don't understand why something =
>> is a=20 peer if it isn't doing anything other than talking to=20 someone
>> and making requests, hence why I supported = client=20 in the first place.
>>  I fail to see how = something=20 that isn't contributing anything, and
>> instead = talks to a=20 peer to get resources, is in any way a peer. It
>> = seems=20 completely not in keeping with the idea of P2P. I also worry=20 it
>>  is likely to be very confusing since = we've=20 been using the other
>> terminology for over a year = now.=20 Just looks like a souce of = confusion.
>>
>
> A=20 node might sometimes have a high-bandwidth connection and wish = to
> contribute resources, and sometimes not have a=20 high-bandwidth connection
> and therefore not wish to = offer=20 resources. Does this modality make it
> two different=20 nodes?
>
>
>> If we do go this way, there = is one=20 subtle point. If I join the overlay
>>
>=20 but
>
>> don't happen to offer any services = (other than=20 maybe
>>
> storage...depending = on
>
>>=20 how we definie it, that might or might not be mandatory), = would I=20 be
>> contributing? If joining the overlay (in the = sense that=20 we have a
>>
> PeerID
>
>>=20 and
>> we route traffic) doesn't require me to store, = I could=20 offer no
>>
> services
>
> That's = "offer no=20 other services", since routing is itself a=20 service.
>
>
>> and
>> still be = a peer.=20 How do we distinguish between this case and a
>>=20 "non-contributing peer" who isn't even part of the overlay = (i.e.,=20 no
>> Peer-ID)
>>
>
> I think = there's a=20 range of "contributing" in play. For most DHT models,
> = a=20 minimally contributing node will route a request it receives. = It=20 might
> ask nicely (perhaps a q-value mechanism) to not = have to=20 route requests,
> but would probably mathematically = still have=20 to route something it gets.
>
> I think we = distinguish=20 based on the service advertisements from the
>=20 peer.
>
>
>> If we are so opposed to = client for=20 confusion with SIP UAs, lets pick a
>>
> new=20
>
>> name, but why some flavor of peer when it = does=20 nothing remotely peer
>>
> = like?
>
>=20 Because in 15 minutes it might roam onto a WiFi net and = therefore=20 change
> it service offering.
>
> = --
>=20 Dean
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>


____________________________________= ___________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.=
org/mailman/listinfo/p2psip
------_=_NextPart_001_01C7B97D.36C4227B-- --===============1589338121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1589338121==-- From p2psip-bounces@ietf.org Thu Jun 28 08:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3szC-0004di-NW; Thu, 28 Jun 2007 08:20:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3szA-0004dY-GD for p2psip@ietf.org; Thu, 28 Jun 2007 08:20:32 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3sz7-0001EY-RX for p2psip@ietf.org; Thu, 28 Jun 2007 08:20:32 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5SBxYKe015848; Thu, 28 Jun 2007 13:59:34 +0200 Message-ID: <4683A764.3070708@teigre.com> Date: Thu, 28 Jun 2007 14:19:48 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: marcin.matuszewski@nokia.com Subject: Re: [P2PSIP] do we need a client protocol? References: <003801c7b92f$09ced5a0$a507740a@DELLWEI> <468351F0.50404@teigre.com> <3F18E76823C95E4795181D74BAC7664F04A470EE@esebe102.NOE.Nokia.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F04A470EE@esebe102.NOE.Nokia.com> X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 654d8dea790bc7609adc97f133706ab1 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1624208800==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1624208800== Content-Type: multipart/alternative; boundary="------------020504010302050004090706" This is a multi-part message in MIME format. --------------020504010302050004090706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by pontius.teigre.com id l5SBxYKe015848 Hi Marcin, Yes, I have a fairly practical (and pessimistic) point of view. Nothing=20 I have seen of developments indicate that the battery squeeze will be=20 over any time soon. Looking back a couple of years, I see mobile phones=20 having far longer standby times than today (remember the 6210/6310 ;-)=20 The trajectory of battery capacity does not seem to improve any time soon. Of course, there may be things you know that I don't ;-) Maybe you want=20 to share?! g-) marcin.matuszewski@nokia.com wrote: > Hi Greger, > =20 > I agree with you that most of mobile terminals that are available on=20 > the market cannot became peers. Actually it is not black and=20 > white they can but everything depends on the size of a P2P network,=20 > used DHT and a traffic model. We must remember that the standard will=20 > be ready in a couple of years when we may have more devices that are=20 > peer capable. > =20 > Marcin=20 > > -------------------------------------------------------------------= ----- > *From:* ext Greger V. Teigre [mailto:greger@teigre.com] > *Sent:* 28 June, 2007 09:15 > *To:* Wei Gengyu > *Cc:* p2psip@ietf.org > *Subject:* Re: [P2PSIP] do we need a client protocol? > > Well, it's a bit more complicated than that. For one thing, > there's a difference between mobile and WLAN. Even with the > power-saving mode of 802.11g for example, there's still more power > drain when connected to WLAN, than mobile. And on mobile, you have > many scenarios, just take the GSM (which I know the best), you > have GSM High-Speed, still used by many roadwarriors in many areas > of the world, and you have GPRS/EDGE/3G data connections. You can > have three modes, each with different power consumption: No > connection (only voice), PDP context established, and active > connection. Real-life experimentation with various modes and > applications using these modes show that battery drainage is a > real problem. > As an example: a native Symbian application that looks up incoming > calls (over 3G data connection) where caller-id is not found in > the local contact list needs to have an active connection (not > only PDP context), because in order to show the caller's data, the > lookup must be almost instantaneous. In reality, it takes about 1 > second. This application is pretty much useless if you actually > make any calls, because at the end of the day, you don't have > battery left... > BTW, the same holds for innovative mobile VoIP apps such as Fling. > > For a mobile unit to be a peer, we need a battery revolution. > g-) > > Wei Gengyu wrote: >> Hi, >> =20 >> A cell phone have full receiving capabilities in standby mode. >> The cell phone will enter the active mode (you said "talk" mode) >> after receiving a paging frame containing "setup" message >> destined to it.=20 >> =20 >> In standby mode, it can listen any messages of signalling and/or >> IP packets. >> So, yes it is possible to have a phone in low-power standby mode >> but (for example) listening for incoming TCP connections or UDP >> packets. >> =20 >> However, the power consumption to send messages is mostly >> converned when the cell phone is in active mode. >> =20 >> *But, I do not think this should be dominate P2PSIP overlay >> design in this stage.* >> =20 >> =20 >> Gengyu >> >> ----- Original Message ----- >> *From:* David Barrett >> *To:* 'Henry Sinnreich' ; >> marcin.matuszewski@nokia.com >> ; eunsooshim@gmail.com >> ; alan@sipstation.com >> >> *Cc:* AVSHALOM@il.ibm.com ; >> philip_matthews@magma.ca ; >> p2psip@ietf.org >> *Sent:* Thursday, June 28, 2007 6:41 AM >> *Subject:* RE: [P2PSIP] do we need a client protocol? >> >> That makes sense. So my next question is: what are the >> capabilities of standby mode, and what triggers it going into >> "talk" mode? >> >> It must be listening to some sort of cell signal even in >> standby mode, just so it can receive phone calls. Given >> this, when in standby mode, does it also have access to the >> IP network? In other words, is it possible to have a phone >> in low-power standby mode but (for example) listening for >> incoming TCP connections or UDP packets? >> >> -david >> >> --------------------------------------------------------------= ---------- >> >> *From:* Henry Sinnreich [mailto:hsinnrei@adobe.com] >> *Sent:* Wednesday, June 27, 2007 1:39 PM >> *To:* David Barrett; marcin.matuszewski@nokia.com >> ; eunsooshim@gmail.com >> ; alan@sipstation.com >> >> *Cc:* AVSHALOM@il.ibm.com ; >> philip_matthews@magma.ca ; >> p2psip@ietf.org >> *Subject:* RE: [P2PSIP] do we need a client protocol? >> >> It is more complicated than this. >> >> Under normal cell phone operation we have the talk time and >> the standby time which is much longer. >> >> Making a cell phone a full peer eliminates this distinction >> to a large degree since the overlay maintenance messages keep >> the phone 'talking' all the time. >> >> Henry >> >> --------------------------------------------------------------= ---------- >> >> *From:* David Barrett [mailto:dbarrett@quinthar.com] >> *Sent:* Wednesday, June 27, 2007 10:06 AM >> *To:* marcin.matuszewski@nokia.com; eunsooshim@gmail.com; >> alan@sipstation.com >> *Cc:* Henry Sinnreich; AVSHALOM@il.ibm.com; >> philip_matthews@magma.ca; p2psip@ietf.org >> *Subject:* RE: [P2PSIP] do we need a client protocol? >> >> I don't know anything about mobile application design >> vis-=E0-vis battery life, but I'm guessing power usage could b= e >> vastly oversimplified to something like: >> >> Power =3D A + nB >> >> Where A is the overall cost of just having the device powered >> on and listening to the radio, and B is the cost of sending a >> byte of data. What I'm wondering is, what is the ratio of A >> to B? Can anyone give real-world data? >> >> For example, I'd accept that sending 200Mbps probably >> requires about 2x the power 100Mbps: for a high enough value >> of 'n', then the constant A gets marginalized. But what >> about 200Kbps or 200bps? For some low value of 'n', then A >> dominates the power usage. >> >> The reason I ask is I wonder if it's even useful to discuss >> power usage for something like P2PSIP. It could be that even >> for a "real" peer, 'n' is so low that the power consumption >> is dominated by other factors, rendering the entire >> discussion moot. >> >> Can anybody give real-world data on this topic? >> >> -david >> >> --------------------------------------------------------------= ---------- >> >> *From:* marcin.matuszewski@nokia.com >> [mailto:marcin.matuszewski@nokia.com] >> *Sent:* Wednesday, June 27, 2007 12:33 AM >> *To:* eunsooshim@gmail.com; alan@sipstation.com >> *Cc:* hsinnrei@adobe.com; AVSHALOM@il.ibm.com; >> philip_matthews@magma.ca; p2psip@ietf.org >> *Subject:* RE: [P2PSIP] do we need a client protocol? >> >> Hi, >> >> We have wide variety of mobile terminals. The capabilities of >> mobile terminals are constantly improving e.g. even >> now Nokia's N-series/E-series devices are very powerful. From >> this reason some of mobile terminals may become peers >> (depending on the case scenario: churn, size of the >> network). However there are also many entry-level/low-end >> devices that have slow CPUs and limited memory.=20 >> >> Battery life is another issue. Most of the mobile phone users >> want long battery life. DHT maintenance and handling searches >> have impact on idle state that is more important from battery >> life perspective than the active state (e.g. when user is >> calling/answering a call). >> >> =20 >> >> I was considering a similar solution to the one that Alan >> proposed however as Eunsoo said it would be quite difficult >> to control the number of connections in DHT. We also have >> problems with handling searches. >> >> I assume that we will have some mobile terminals taking part >> in DHT and some accessing resources stored in DHT using a >> client protocol. >> >> >> Marcin >> >> ----------------------------------------------------------= -------------- >> >> *From:* ext Eunsoo Shim [mailto:eunsooshim@gmail.com] >> *Sent:* 27 June, 2007 02:26 >> *To:* Alan Johnston >> *Cc:* Henry Sinnreich; Avshalom Houri; Philip Matthews; >> P2PSIP Mailing List >> *Subject:* Re: [P2PSIP] do we need a client protocol? >> >> On 6/26/07, *Alan Johnston* > > wrote: >> >> I've been giving this a lot of thought lately, thinking >> about the actual >> requirements. >> >> We want to allow energy-limited devices to participate to >> some level in >> P2PSIP. As such, perhaps instead of saying we need a >> client protocol, >> perhaps we just need levels of participation in the >> overlay peer protocol. >> >> For example, a normal peer in the overlay will maintain >> peer protocol >> connections with many (perhaps dozens) of >> peers. Why? So that it can >> quickly and efficiently route requests within the overlay. >> >> Perhaps an energy-limited device could just minimize >> the number of peer >> protocol connections it maintains, perhaps even down >> to a minimum of >> two. This would result in slower routing of its >> requests through the >> overlay, but that seems like a reasonable tradeoff. >> >> >> The underling algorithm (e.g. a certain DHT algorithm) >> will dictate the number of connections even though there >> might be some room for adjustment. I don't think it is >> under complete control of individual peer in the case of >> known DHT algorithms. >> >> Also, perhaps there are some other peer protocol >> functions, such as data >> replication (storage would still be done, but not >> replication), that >> could be skipped by these energy-limited >> peers. Perhaps their requests >> and responses could be routed over the overlay with a >> lower priority >> than full peers. We need to manage the tradeoffs so >> that those peers >> who contribute the least to the overlay also get the >> lowest performance >> from it. >> >> >> >> I am not quite sure I understand the benefit of >> introducing such various levels of participation. >> Having a client protocol seems to be much simpler and >> easier than introducing these various levels of >> participation. >> >> Thanks. >> >> Eunsoo >> >> Henry Sinnreich wrote: >> > Folks, >> > >> > Given the length of the discussion on "do we need a >> client protocol?" >> > let me repeat the simple imperatives for the client: >> > >> > - Limited battery in mobile devices, and >> > >> > - Other uses besides SIP. Business planning folks >> may not care about the >> > WG charter, but about the return on the investment. >> > >> > Thanks, Henry >> > >> > -----Original Message----- >> > From: Dean Willis [mailto:dean.willis@softarmor.com >> ] >> > Sent: Thursday, June 14, 2007 11:23 PM >> > To: David A. Bryan >> > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matt= hews >> > Subject: Re: [P2PSIP] Concepts document: proposal >> for active/passive >> > peerterminology >> > >> > David A. Bryan wrote: >> > >> >> If I understand this right, not sure I like it. Do >> these >> >> >> > "non-contributing >> > >> >> peer" (I *do* like contributing better than >> active/passive) entities >> >> >> > have a >> > >> >> Peer-ID? In otherwords, are they part of the >> overlay at all? If so, >> >> >> > for >> > >> >> most >> >> DHTs, how do we allow you to be in the overlay and >> not store resources >> >> >> > (not >> > >> >> typical for most current DHT algorithms) >> >> >> > >> > Well, that certainly depends on the DHT algorithm >> involved. It certainly >> > seems that a peer that moves between contributing >> and non-contributing >> > might HAVE a peer ID, but whether it chooses to >> insert itself into the >> > DHT "right now" might determine whether it is >> contributing "right now" >> > or not. >> > >> > >> >> My concern all along has been that I don't >> understand why something >> >> is a peer if it isn't doing anything other than >> talking to someone >> >> and making requests, hence why I supported client >> in the first place. >> >> I fail to see how something that isn't >> contributing anything, and >> >> instead talks to a peer to get resources, is in any >> way a peer. It >> >> seems completely not in keeping with the idea of >> P2P. I also worry it >> >> is likely to be very confusing since we've been >> using the other >> >> terminology for over a year now. Just looks like a >> souce of confusion. >> >> >> > >> > A node might sometimes have a high-bandwidth >> connection and wish to >> > contribute resources, and sometimes not have a >> high-bandwidth connection >> > and therefore not wish to offer resources. Does this >> modality make it >> > two different nodes? >> > >> > >> >> If we do go this way, there is one subtle point. If >> I join the overlay >> >> >> > but >> > >> >> don't happen to offer any services (other than mayb= e >> >> >> > storage...depending on >> > >> >> how we definie it, that might or might not be >> mandatory), would I be >> >> contributing? If joining the overlay (in the sense >> that we have a >> >> >> > PeerID >> > >> >> and >> >> we route traffic) doesn't require me to store, I >> could offer no >> >> >> > services >> > >> > That's "offer no other services", since routing is >> itself a service. >> > >> > >> >> and >> >> still be a peer. How do we distinguish between this >> case and a >> >> "non-contributing peer" who isn't even part of the >> overlay (i.e., no >> >> Peer-ID) >> >> >> > >> > I think there's a range of "contributing" in play. >> For most DHT models, >> > a minimally contributing node will route a request >> it receives. It might >> > ask nicely (perhaps a q-value mechanism) to not have >> to route requests, >> > but would probably mathematically still have to >> route something it gets. >> > >> > I think we distinguish based on the service >> advertisements from the >> > peer. >> > >> > >> >> If we are so opposed to client for confusion with >> SIP UAs, lets pick a >> >> >> > new >> > >> >> name, but why some flavor of peer when it does >> nothing remotely peer >> >> >> > like? >> > >> > Because in 15 minutes it might roam onto a WiFi net >> and therefore change >> > it service offering. >> > >> > -- >> > Dean >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www1.ietf.org/mailman/listinfo/p2psip >> > >> > _______________________________________________ >> > P2PSIP mailing list >> > P2PSIP@ietf.org >> > https://www1.ietf.org/mailman/listinfo/p2psip >> > >> > >> > >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> --------------------------------------------------------------= ---------- >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> ------------------------------------------------------------------= ------ >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> =20 > --------------020504010302050004090706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Marcin,
Yes, I have a fairly practical (and pessimistic) point of view. Nothing I have seen of developments indicate that the battery squeeze will be over any time soon. Looking back a couple of years, I see mobile phones having far longer standby times than today (remember the 6210/6310 ;-) The trajectory of battery capacity does not seem to improve any time soon.
Of course, there may be things you know that I don't ;-) Maybe you want to share?!
g-)


marcin.matuszewski@nokia.com wrote:
Hi Greger,
 
I agree with you that most of mobile terminals that are available on the market cannot became peers. Actually it is not black and white they can but everything depends on the size of a P2P network, used DHT and a traffic model. We must remember that the standard will be ready in a couple of years when we may have more devices that are peer capable.
 
Marcin 

From: ext Greger V. Teigre [mailto:greger@teigre.com]
Sent: 28 June, 2007 09:15
To: Wei Gengyu
Cc: p2psip@ietf.org
Subject: Re: [P2PSIP] do we need a client protocol?

Well, it's a bit more complicated than that. For one thing, there's a difference between mobile and WLAN. Even with the power-saving mode of 802.11g for example, there's still more power drain when connected to WLAN, than mobile. And on mobile, you have many scenarios, just take the GSM (which I know the best), you have GSM High-Speed, still used by many roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data connections. You can have three modes, each with different power consumption: No connection (only voice), PDP context established, and active connection. Real-life experimentation with various modes and applications using these modes show that battery drainage is a real problem.
As an example: a native Symbian application that looks up incoming calls (over 3G data connection) where caller-id is not found in the local contact list needs to have an active connection (not only PDP context), because in order to show the caller's data, the lookup must be almost instantaneous. In reality, it takes about 1 second.  This application is pretty much useless if you actually make any calls, because at the end of the day, you don't have battery left...
BTW, the same holds for innovative mobile VoIP apps such as Fling.

For a mobile unit to be a peer, we need a battery revolution.
g-)

Wei Gengyu wrote:
Hi,
 
A cell phone have full receiving capabilities in standby mode.
The cell phone will enter the active mode (you said "talk" mode)
after receiving a paging frame containing "setup" message destined to it. 
 
In standby mode, it can listen any messages of signalling and/or IP packets.
So, yes it is possible to have a phone in low-power standby mode but (for example) listening for incoming TCP connections or UDP packets.
 
However, the power consumption to send messages is mostly converned when the cell phone is in active mode.
 
But, I do not think this should be dominate P2PSIP overlay design in this stage.
 
 
Gengyu
----- Original Message -----
Sent: Thursday, June 28, 2007 6:41 AM
Subject: RE: [P2PSIP] do we need a client protocol?

That makes sense.  So my next question is: what are the capabilities of standby mode, and what triggers it going into “talk” mode?

It must be listening to some sort of cell signal even in standby mode, just so it can receive phone calls.  Given this, when in standby mode, does it also have access to the IP network?  In other words, is it possible to have a phone in low-power standby mode but (for example) listening for incoming TCP connections or UDP packets?

-david

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 27, 2007 1:39 PM
To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

It is more complicated than this.

Under normal cell phone operation we have the talk time and the standby time which is much longer.

Making a cell phone a full peer eliminates this distinction to a large degree since the overlay maintenance messages keep the phone ‘talking’ all the time.

Henry

From: David Barrett [mailto:dbarrett@quinthar.com]
Sent: Wednesday, June 27, 2007 10:06 AM
To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

I don’t know anything about mobile application design vis-à-vis battery life, but I’m guessing power usage could be vastly oversimplified to something like:

Power = A + nB

Where A is the overall cost of just having the device powered on and listening to the radio, and B is the cost of sending a byte of data.  What I’m wondering is, what is the ratio of A to B?  Can anyone give real-world data?

For example, I’d accept that sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough value of ‘n’, then the constant A gets marginalized.  But what about 200Kbps or 200bps?  For some low value of ‘n’, then A dominates the power usage.

The reason I ask is I wonder if it’s even useful to discuss power usage for something like P2PSIP.  It could be that even for a “real” peer, ‘n’ is so low that the power consumption is dominated by other factors, rendering the entire discussion moot.

Can anybody give real-world data on this topic?

-david

From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]
Sent: Wednesday, June 27, 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

Hi,

We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the network). However there are also many entry-level/low-end devices that have slow CPUs and limited memory. 

Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is calling/answering a call).

    

I was considering a similar solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches.

I assume that we will have some mobile terminals taking part in DHT and some accessing resources stored in DHT using a client protocol.


Marcin

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007 02:26
To: Alan Johnston
Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do we need a client protocol?

On 6/26/07, Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought lately, thinking about the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer protocol.

For example, a normal peer in the overlay will maintain peer protocol
connections with many (perhaps dozens) of peers.  Why?  So that it can
quickly and efficiently route requests within the overlay.

Perhaps an energy-limited device could just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests through the
overlay, but that seems like a reasonable tradeoff.


The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms.

Also, perhaps there are some other peer protocol functions, such as data
replication (storage would still be done, but not replication), that
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that those peers
who contribute the least to the overlay also get the lowest performance
from it.



I am not quite sure I understand the benefit of introducing such various levels of participation.
Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.

Thanks.

Eunsoo

Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It certainly
> seems that a peer that moves between contributing and non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into the
> DHT "right now" might determine whether it is contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why something
>> is a peer if it isn't doing anything other than talking to someone
>> and making requests, hence why I supported client in the first place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. It
>> seems completely not in keeping with the idea of P2P. I also worry it
>>  is likely to be very confusing since we've been using the other
>> terminology for over a year now. Just looks like a souce of confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish to
> contribute resources, and sometimes not have a high-bandwidth connection
> and therefore not wish to offer resources. Does this modality make it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would I be
>> contributing? If joining the overlay (in the sense that we have a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer no
>>
> services
>
> That's "offer no other services", since routing is itself a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and a
>> "non-contributing peer" who isn't even part of the overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For most DHT models,
> a minimally contributing node will route a request it receives. It might
> ask nicely (perhaps a q-value mechanism) to not have to route requests,
> but would probably mathematically still have to route something it gets.
>
> I think we distinguish based on the service advertisements from the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--------------020504010302050004090706-- --===============1624208800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1624208800==-- From p2psip-bounces@ietf.org Thu Jun 28 13:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xum-0005hy-CE; Thu, 28 Jun 2007 13:36:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3xul-0005gN-Id for p2psip@ietf.org; Thu, 28 Jun 2007 13:36:19 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I3xuG-0002LT-GL for p2psip@ietf.org; Thu, 28 Jun 2007 13:36:19 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Thu, 28 Jun 2007 10:35:35 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5SHZTWs028192; Thu, 28 Jun 2007 10:35:34 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5SHZC18018008; Thu, 28 Jun 2007 10:35:29 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 10:35:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Thu, 28 Jun 2007 10:34:32 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A263DB@namail5.corp.adobe.com> In-Reply-To: <4683A764.3070708@teigre.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace5fsE5NJS2Q9aZREeQTMUOXCS5VgAKsHeA References: <003801c7b92f$09ced5a0$a507740a@DELLWEI><468351F0.50404@teigre.com><3F18E76823C95E4795181D74BAC7664F04A470EE@esebe102.NOE.Nokia.com> <4683A764.3070708@teigre.com> From: "Henry Sinnreich" To: "Greger V. Teigre" , X-OriginalArrivalTime: 28 Jun 2007 17:35:27.0456 (UTC) FILETIME=[B7526E00:01C7B9AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4b660ae3bd4ab91544f00dc9ece020b Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0410732377==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0410732377== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B9AA.96682BE0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B9AA.96682BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Nothing I have seen of developments indicate that the battery squeeze = will be over any time soon.=20 >Looking back a couple of years, I see mobile phones having far longer = standby times than today (remember the 6210/6310 ;-)=20 >The trajectory of battery capacity does not seem to improve any time = soon. =20 This is an excellent observation and resembles how increased fuel = efficiency of car engines is eaten up by people driving more mileage and = bigger cars. =20 Henry =20 ________________________________ From: Greger V. Teigre [mailto:greger@teigre.com]=20 Sent: Thursday, June 28, 2007 5:20 AM To: marcin.matuszewski@nokia.com Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? =20 Hi Marcin, Yes, I have a fairly practical (and pessimistic) point of view. Nothing = I have seen of developments indicate that the battery squeeze will be = over any time soon. Looking back a couple of years, I see mobile phones = having far longer standby times than today (remember the 6210/6310 ;-) = The trajectory of battery capacity does not seem to improve any time = soon. Of course, there may be things you know that I don't ;-) Maybe you want = to share?! g-) marcin.matuszewski@nokia.com wrote:=20 Hi Greger, =20 I agree with you that most of mobile terminals that are available on the = market cannot became peers. Actually it is not black and white they can = but everything depends on the size of a P2P network, used DHT and a = traffic model. We must remember that the standard will be ready in a = couple of years when we may have more devices that are peer capable.=20 =20 Marcin=20 =20 =09 ________________________________ From: ext Greger V. Teigre [mailto:greger@teigre.com]=20 Sent: 28 June, 2007 09:15 To: Wei Gengyu Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Well, it's a bit more complicated than that. For one thing, there's a = difference between mobile and WLAN. Even with the power-saving mode of = 802.11g for example, there's still more power drain when connected to = WLAN, than mobile. And on mobile, you have many scenarios, just take the = GSM (which I know the best), you have GSM High-Speed, still used by many = roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data = connections. You can have three modes, each with different power = consumption: No connection (only voice), PDP context established, and = active connection. Real-life experimentation with various modes and = applications using these modes show that battery drainage is a real = problem.=20 As an example: a native Symbian application that looks up incoming = calls (over 3G data connection) where caller-id is not found in the = local contact list needs to have an active connection (not only PDP = context), because in order to show the caller's data, the lookup must be = almost instantaneous. In reality, it takes about 1 second. This = application is pretty much useless if you actually make any calls, = because at the end of the day, you don't have battery left... BTW, the same holds for innovative mobile VoIP apps such as Fling. =09 For a mobile unit to be a peer, we need a battery revolution. g-) =09 Wei Gengyu wrote:=20 Hi,=20 =20 A cell phone have full receiving capabilities in standby mode. The cell phone will enter the active mode (you said "talk" mode)=20 after receiving a paging frame containing "setup" message destined to = it.=20 =20 In standby mode, it can listen any messages of signalling and/or IP = packets. So, yes it is possible to have a phone in low-power standby mode but = (for example) listening for incoming TCP connections or UDP packets. =20 However, the power consumption to send messages is mostly converned = when the cell phone is in active mode.=20 =20 But, I do not think this should be dominate P2PSIP overlay design in = this stage. =20 =20 Gengyu ----- Original Message -----=20 From: David Barrett =20 To: 'Henry Sinnreich' ; = marcin.matuszewski@nokia.com ; eunsooshim@gmail.com ; = alan@sipstation.com=20 Cc: AVSHALOM@il.ibm.com ; philip_matthews@magma.ca ; p2psip@ietf.org=20 Sent: Thursday, June 28, 2007 6:41 AM Subject: RE: [P2PSIP] do we need a client protocol? =20 That makes sense. So my next question is: what are the capabilities = of standby mode, and what triggers it going into "talk" mode? It must be listening to some sort of cell signal even in standby mode, = just so it can receive phone calls. Given this, when in standby mode, = does it also have access to the IP network? In other words, is it = possible to have a phone in low-power standby mode but (for example) = listening for incoming TCP connections or UDP packets? -david =09 =09 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 27, 2007 1:39 PM To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? It is more complicated than this. Under normal cell phone operation we have the talk time and the = standby time which is much longer. Making a cell phone a full peer eliminates this distinction to a large = degree since the overlay maintenance messages keep the phone 'talking' = all the time. Henry =09 =09 ________________________________ From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Wednesday, June 27, 2007 10:06 AM To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I don't know anything about mobile application design vis-=E0-vis = battery life, but I'm guessing power usage could be vastly = oversimplified to something like: Power =3D A + nB Where A is the overall cost of just having the device powered on and = listening to the radio, and B is the cost of sending a byte of data. = What I'm wondering is, what is the ratio of A to B? Can anyone give = real-world data? For example, I'd accept that sending 200Mbps probably requires about = 2x the power 100Mbps: for a high enough value of 'n', then the constant = A gets marginalized. But what about 200Kbps or 200bps? For some low = value of 'n', then A dominates the power usage. The reason I ask is I wonder if it's even useful to discuss power = usage for something like P2PSIP. It could be that even for a "real" = peer, 'n' is so low that the power consumption is dominated by other = factors, rendering the entire discussion moot. Can anybody give real-world data on this topic? -david=20 =09 =09 ________________________________ From: marcin.matuszewski@nokia.com = [mailto:marcin.matuszewski@nokia.com]=20 Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, We have wide variety of mobile terminals. The capabilities of mobile = terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of = mobile terminals may become peers (depending on the case scenario: = churn, size of the network). However there are also many = entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on = idle state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number = of connections in DHT. We also have problems with handling searches. I assume that we will have some mobile terminals taking part in DHT = and some accessing resources stored in DHT using a client protocol. =09 Marcin =09 ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the = actual requirements. =09 We want to allow energy-limited devices to participate to some level = in P2PSIP. As such, perhaps instead of saying we need a client = protocol,=20 perhaps we just need levels of participation in the overlay peer = protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it = can=20 quickly and efficiently route requests within the overlay. Perhaps an energy-limited device could just minimize the number of = peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through = the overlay, but that seems like a reasonable tradeoff.=20 =09 The underling algorithm (e.g. a certain DHT algorithm) will dictate = the number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual = peer in the case of known DHT algorithms.=20 Also, perhaps there are some other peer protocol functions, such as = data replication (storage would still be done, but not replication), that = could be skipped by these energy-limited peers. Perhaps their = requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those = peers who contribute the least to the overlay also get the lowest = performance from it. =09 =09 I am not quite sure I understand the benefit of introducing such = various levels of participation. Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client = protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care = about the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) = entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If = so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and = non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into = the > DHT "right now" might determine whether it is contributing "right = now" > or not. > > >> My concern all along has been that I don't understand why = something=20 >> is a peer if it isn't doing anything other than talking to = someone >> and making requests, hence why I supported client in the first = place. >> I fail to see how something that isn't contributing anything, = and=20 >> instead talks to a peer to get resources, is in any way a peer. = It >> seems completely not in keeping with the idea of P2P. I also = worry it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish = to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make = it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I = be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a = service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., = no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from = the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets = pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely = peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 =09 ________________________________ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 =09 =09 ________________________________ =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------_=_NextPart_001_01C7B9AA.96682BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>Nothing I have seen of developments = indicate that the battery squeeze will be over any time soon. =

>Looking back a couple of years, I see = mobile phones having far longer standby times than today (remember the = 6210/6310 ;-)

>The trajectory of battery capacity does = not seem to improve any time soon.

 

This is an excellent observation and = resembles how increased fuel efficiency of car engines is eaten up by people driving = more mileage and bigger cars.

 

Henry

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Thursday, June 28, = 2007 5:20 AM
To: = marcin.matuszewski@nokia.com
Cc: = p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a client protocol?

 

Hi Marcin,
Yes, I have a fairly practical (and pessimistic) point of view. Nothing = I have seen of developments indicate that the battery squeeze will be over any = time soon. Looking back a couple of years, I see mobile phones having far = longer standby times than today (remember the 6210/6310 ;-) The trajectory of = battery capacity does not seem to improve any time soon.
Of course, there may be things you know that I don't ;-) Maybe you want = to share?!
g-)


marcin.matuszewski@nokia.com= wrote:

Hi = Greger,

 

I agree with you that most of = mobile terminals that are available on the market cannot became peers. = Actually it is not black and white they can but everything depends on = the size of a P2P network, used DHT and a traffic model. We must = remember that the standard will be ready in a couple of years when we may have more = devices that are peer capable.

 

Marcin 

 

From: ext Greger V. Teigre [mailto:greger@teigre.com]
Sent: 28 June, 2007 = 09:15
To: Wei Gengyu
Cc: p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a client protocol?

Well, it's a bit more complicated than that. = For one thing, there's a difference between mobile and WLAN. Even with the = power-saving mode of 802.11g for example, there's still more power drain when = connected to WLAN, than mobile. And on mobile, you have many scenarios, just take the = GSM (which I know the best), you have GSM High-Speed, still used by many roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data connections. You can have three modes, each with different power = consumption: No connection (only voice), PDP context established, and active = connection. Real-life experimentation with various modes and applications using = these modes show that battery drainage is a real problem.
As an example: a native Symbian application that looks up incoming calls = (over 3G data connection) where caller-id is not found in the local contact = list needs to have an active connection (not only PDP context), because in = order to show the caller's data, the lookup must be almost instantaneous. In = reality, it takes about 1 second.  This application is pretty much useless if = you actually make any calls, because at the end of the day, you don't have = battery left...
BTW, the same holds for innovative mobile VoIP apps such as Fling.

For a mobile unit to be a peer, we need a battery revolution.
g-)

Wei Gengyu wrote:

Hi,

 

A cell phone have full receiving = capabilities in standby mode.

The cell phone will enter the = active mode (you said "talk" mode)

after receiving a paging frame containing "setup" message destined to = it. 

 

In standby mode, it can listen any = messages of signalling and/or IP packets.

So, yes it is possible to have a phone in low-power standby mode but (for example) = listening for incoming TCP connections or UDP = packets.

 

However, the power consumption to send = messages is mostly converned when the cell phone is = in active mode.

 

But, I do not think this = should be dominate P2PSIP overlay design in this = stage.

 

 

Gengyu

----- Original Message ----- =

Sent: Thursday, June 28, 2007 6:41 AM

Subject: RE: [P2PSIP] do we need a client protocol?

 

That makes sense.  So my next question is: what are the capabilities of standby mode, and what = triggers it going into “talk” = mode?

It must be listening to = some sort of cell signal even in standby mode, just so it can receive phone calls.  Given this, when in standby mode, does it also have access = to the IP network?  In other words, is it possible to have a phone in = low-power standby mode but (for example) listening for incoming TCP connections or = UDP packets?

-david<= /font>

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 27, = 2007 1:39 PM
To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

It is more complicated = than this.

Under normal cell phone operation = we have the talk time and the standby time which is much = longer.

Making a cell phone a = full peer eliminates this distinction to a large degree since the = overlay maintenance messages keep the phone ‘talking’ all the = time.

Henry

From: David Barrett [mailto:dbarrett@quinthar.com]
Sent: Wednesday, June 27, = 2007 10:06 AM
To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

I don’t know = anything about mobile application design vis-=E0-vis battery life, but I’m = guessing power usage could be vastly oversimplified to something = like:

Power = =3D A + nB

Where A is the overall = cost of just having the device powered on and listening to the radio, and B is = the cost of sending a byte of data.  What I’m wondering is, what is = the ratio of A to B?  Can anyone give real-world = data?

For example, I’d = accept that sending 200Mbps probably requires about 2x the power 100Mbps: for a = high enough value of ‘n’, then the constant A gets = marginalized.  But what = about 200Kbps or 200bps?  For some low value of ‘n’, then A dominates the power usage.

The reason I ask is I = wonder if it’s even useful to discuss power usage for something like = P2PSIP.  It could be that even for a “real” peer, ‘n’ is = so low that the power consumption is dominated by other factors, rendering the = entire discussion moot.

Can anybody give = real-world data on this topic?

-david =

From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com]
Sent: Wednesday, June 27, = 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

Hi,

We have wide = variety of mobile terminals. The capabilities of mobile terminals = are constantly improving e.g. even now Nokia's N-series/E-series devices = are very powerful. From this reason some of mobile terminals may become = peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that = have slow CPUs and limited = memory. 

Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is = calling/answering a call).

    

I was considering a similar = solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We = also have problems with handling = searches.

I assume = that we will have some mobile terminals taking part in DHT and some accessing = resources stored in DHT using a client = protocol.


Marcin<= /p>

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP = Mailing List
Subject: Re: [P2PSIP] do = we need a client protocol?

On 6/26/07, = Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought = lately, thinking about the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer = protocol.

For example, a normal peer in the overlay will maintain peer = protocol
connections with many (perhaps dozens) of = peers.  Why?  So that it can
quickly and efficiently route requests within the = overlay.

Perhaps an = energy-limited device could = just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests = through the
overlay, but that seems like a reasonable tradeoff. =


The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for adjustment. I = don't think it is under complete control of individual peer in the case of = known DHT algorithms.

Also, perhaps there are some other = peer protocol functions, such as data
replication (storage would still be done, but not replication), that =
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that = those peers
who contribute the least to the overlay also get the lowest = performance
from it.



I am not quite sure I understand the benefit of introducing such various = levels of participation.
Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.

Thanks.

Eunsoo

Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care = about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than = active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If = so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store = resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It = certainly
> seems that a peer that moves between contributing and = non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into = the
> DHT "right now" might determine whether it is = contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why = something
>> is a peer if it isn't doing anything other than talking to = someone
>> and making requests, hence why I supported client in the first = place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. = It
>> seems completely not in keeping with the idea of P2P. I also = worry it
>>  is likely to be very confusing since we've been = using the other
>> terminology for over a year now. Just looks like a souce of = confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish = to
> contribute resources, and sometimes not have a high-bandwidth = connection
> and therefore not wish to offer resources. Does this modality make = it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the = overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would = I be
>> contributing? If joining the overlay (in the sense that we have = a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer = no
>>
> services
>
> That's "offer no other services", since routing is itself = a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and = a
>> "non-contributing peer" who isn't even part of the = overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For = most DHT models,
> a minimally contributing node will route a request it receives. It = might
> ask nicely (perhaps a q-value mechanism) to not have to route = requests,
> but would probably mathematically still have to route something it = gets.
>
> I think we distinguish based on the service advertisements from = the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets = pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely = peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore = change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip<= br> >
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip<= br> >
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip<= o:p>

______________________________________________= _
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip<= o:p>







 
______________________________________________=
_
P2PSIP mailing =
list
P2PSIP@ietf.org
= 
https://www1.ietf.org/mailman/listinfo/p2psip<=
o:p>
=A0 =
------_=_NextPart_001_01C7B9AA.96682BE0-- --===============0410732377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0410732377==-- From p2psip-bounces@ietf.org Thu Jun 28 16:34:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40h3-0007V3-6L; Thu, 28 Jun 2007 16:34:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I40h1-0007Ub-LD for p2psip@ietf.org; Thu, 28 Jun 2007 16:34:19 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I40gW-0007do-07 for p2psip@ietf.org; Thu, 28 Jun 2007 16:34:19 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Thu, 28 Jun 2007 13:33:39 -0700 From: "David Barrett" To: "'Greger V. Teigre'" , "'Wei Gengyu'" Subject: RE: [P2PSIP] do we need a client protocol? Date: Thu, 28 Jun 2007 13:33:39 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace5S8RGTciuMw3LSQW/uBPCyz1W8wAdVFug In-reply-to: <468351F0.50404@teigre.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 91d17910d48ec26c363c3efd1d39af80 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0478479859==" Errors-To: p2psip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============0478479859== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EE_01C7B988.F05D0FB0" This is a multi-part message in MIME format. ------=_NextPart_000_01EE_01C7B988.F05D0FB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, so it seems fairly likely that a mobile unit can=92t be a true SIP = peer. But based on all this I question if it=92s even practical for a mobile = unit to be a SIP *client* because the simple of act of waiting for somebody to = call you will be prohibitively battery-draining. =20 First, Marcin, did I understand you correctly to say that simply being connected to a WLAN =96 even if you don=92t send any data =96 drains = your battery at a quick pace? This alone suggests that there can be no long-lived =93listening=94 client-app on a mobile unit (SIP included) due to = practical battery limitations. If this is true, then it makes the whole = discussion moot. =20 Second, assuming you can connect to and listen on a WLAN at all, then = it=92d only work if you have a non-NAT=92d, non-firewalled address (because = anything other is going to require constant NAT penetration/keepalive traffic). = 80% of real-world connections (and near 100% of actual WLANs) don=92t have = this property. So again, the discussion seems moot. =20 Third, assume it doesn=92t cost battery life to listen, and assume you = can somehow have a relevant class of users reliably get non-NAT=92d, non-firewalled IP addresses. With this sort of address you=92re going = to be subject to the whims of the internet, which is a pretty harsh place =96 = I=92d expect your phone would be undergoing almost constant scans from worms = and hackers, which would require it to constantly respond. So again, your = phone is going to need to actively reject the 99% of =93bad=94 traffic just to = get the =93good=94 incoming call. But the filtering is likely so expensive that = the battery life is unacceptable, and again, game over. =20 =20 None of this has anything to do with SIP. Unless I=92m misunderstanding = it, it=92s just not possible for a battery-conscious device to continuously = listen on an IP network at this point. What am I missing? =20 =20 -david =20 _____ =20 From: Greger V. Teigre [mailto:greger@teigre.com]=20 Sent: Wednesday, June 27, 2007 11:15 PM To: Wei Gengyu Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? =20 Well, it's a bit more complicated than that. For one thing, there's a difference between mobile and WLAN. Even with the power-saving mode of 802.11g for example, there's still more power drain when connected to = WLAN, than mobile. And on mobile, you have many scenarios, just take the GSM (which I know the best), you have GSM High-Speed, still used by many roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data connections. You can have three modes, each with different power consumption: No connection (only voice), PDP context established, and = active connection. Real-life experimentation with various modes and = applications using these modes show that battery drainage is a real problem.=20 As an example: a native Symbian application that looks up incoming calls (over 3G data connection) where caller-id is not found in the local = contact list needs to have an active connection (not only PDP context), because = in order to show the caller's data, the lookup must be almost = instantaneous. In reality, it takes about 1 second. This application is pretty much = useless if you actually make any calls, because at the end of the day, you don't have battery left... BTW, the same holds for innovative mobile VoIP apps such as Fling. For a mobile unit to be a peer, we need a battery revolution. g-) Wei Gengyu wrote:=20 Hi,=20 =20 A cell phone have full receiving capabilities in standby mode. The cell phone will enter the active mode (you said "talk" mode)=20 after receiving a paging frame containing "setup" message destined to = it.=20 =20 In standby mode, it can listen any messages of signalling and/or IP = packets. So, yes it is possible to have a phone in low-power standby mode but = (for example) listening for incoming TCP connections or UDP packets. =20 However, the power consumption to send messages is mostly converned when = the cell phone is in active mode.=20 =20 But, I do not think this should be dominate P2PSIP overlay design in = this stage. =20 =20 Gengyu ----- Original Message -----=20 From: David Barrett =20 To: 'Henry Sinnreich' ; marcin.matuszewski@nokia.com ; eunsooshim@gmail.com ; = alan@sipstation.com=20 Cc: AVSHALOM@il.ibm.com ; philip_matthews@magma.ca ; p2psip@ietf.org=20 Sent: Thursday, June 28, 2007 6:41 AM Subject: RE: [P2PSIP] do we need a client protocol? =20 That makes sense. So my next question is: what are the capabilities of standby mode, and what triggers it going into =93talk=94 mode? =20 It must be listening to some sort of cell signal even in standby mode, = just so it can receive phone calls. Given this, when in standby mode, does = it also have access to the IP network? In other words, is it possible to = have a phone in low-power standby mode but (for example) listening for = incoming TCP connections or UDP packets? =20 -david =20 _____ =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 27, 2007 1:39 PM To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 It is more complicated than this. Under normal cell phone operation we have the talk time and the standby = time which is much longer. =20 Making a cell phone a full peer eliminates this distinction to a large degree since the overlay maintenance messages keep the phone = =91talking=92 all the time. =20 Henry =20 _____ =20 From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Wednesday, June 27, 2007 10:06 AM To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 I don=92t know anything about mobile application design vis-=E0-vis = battery life, but I=92m guessing power usage could be vastly oversimplified to something like: =20 Power =3D A + nB =20 Where A is the overall cost of just having the device powered on and listening to the radio, and B is the cost of sending a byte of data. = What I=92m wondering is, what is the ratio of A to B? Can anyone give = real-world data? =20 For example, I=92d accept that sending 200Mbps probably requires about = 2x the power 100Mbps: for a high enough value of =91n=92, then the constant A = gets marginalized. But what about 200Kbps or 200bps? For some low value of = =91n=92, then A dominates the power usage. =20 The reason I ask is I wonder if it=92s even useful to discuss power = usage for something like P2PSIP. It could be that even for a =93real=94 peer, = =91n=92 is so low that the power consumption is dominated by other factors, rendering = the entire discussion moot. =20 Can anybody give real-world data on this topic? =20 -david=20 =20 _____ =20 From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] = Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that have slow = CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and = some accessing resources stored in DHT using a client protocol. Marcin _____ =20 From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =20 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the actual requirements. We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer = protocol. For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. =20 =20 Perhaps an energy-limited device could just minimize the number of peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual peer in the case = of known DHT algorithms.=20 =20 Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest performance from it. I am not quite sure I understand the benefit of introducing such various levels of participation. Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.=20 Thanks. Eunsoo =20 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about = the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and non-contributing = > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > >> My concern all along has been that I don't understand why something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets pick = a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 _____ =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 _____ =20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------=_NextPart_000_01EE_01C7B988.F05D0FB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ok, so it seems fairly likely that = a mobile unit can’t be a true SIP peer.=A0 But based on all this I = question if it’s even practical for a mobile unit to be a SIP *client* because the simple of act = of waiting for somebody to call you will be prohibitively = battery-draining.

 

First, Marcin, did I understand you correctly to say that simply being connected to a WLAN – even if = you don’t send any data – drains your battery at a quick pace?=A0 This alone = suggests that there can be no long-lived “listening” client-app on a = mobile unit (SIP included) due to practical battery limitations.=A0 If this is = true, then it makes the whole discussion moot.

 

Second, assuming you can connect to = and listen on a WLAN at all, then it’d only work if you have a = non-NAT’d, non-firewalled address (because anything other is going to require = constant NAT penetration/keepalive traffic).=A0 80% of real-world connections (and = near 100% of actual WLANs) don’t have this property.=A0 So again, the = discussion seems moot.

 

Third, assume it doesn’t cost = battery life to listen, and assume you can somehow have a relevant class of = users reliably get non-NAT’d, non-firewalled IP addresses.=A0 With this sort of = address you’re going to be subject to the whims of the internet, which is = a pretty harsh place – I’d expect your phone would be = undergoing almost constant scans from worms and hackers, which would require it to constantly respond.=A0 So again, your phone is going to need to actively = reject the 99% of “bad” traffic just to get the “good” incoming call.=A0 But the filtering is likely so expensive that the = battery life is unacceptable, and again, game over.

 

 

None of this has anything to do = with SIP.=A0 Unless I’m misunderstanding it, it’s just not possible for a battery-conscious device to continuously listen on an IP network at this = point.=A0 What am I missing?=A0

 

-david

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Wednesday, June 27, = 2007 11:15 PM
To: Wei Gengyu
Cc: p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a client protocol?

 

Well, it's a bit more complicated than that. = For one thing, there's a difference between mobile and WLAN. Even with the = power-saving mode of 802.11g for example, there's still more power drain when = connected to WLAN, than mobile. And on mobile, you have many scenarios, just take the = GSM (which I know the best), you have GSM High-Speed, still used by many roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data connections. You can have three modes, each with different power = consumption: No connection (only voice), PDP context established, and active = connection. Real-life experimentation with various modes and applications using = these modes show that battery drainage is a real problem.
As an example: a native Symbian application that looks up incoming calls = (over 3G data connection) where caller-id is not found in the local contact = list needs to have an active connection (not only PDP context), because in = order to show the caller's data, the lookup must be almost instantaneous. In = reality, it takes about 1 second.  This application is pretty much useless if = you actually make any calls, because at the end of the day, you don't have battery = left...
BTW, the same holds for innovative mobile VoIP apps such as Fling.

For a mobile unit to be a peer, we need a battery revolution.
g-)

Wei Gengyu wrote:

Hi,

 

A cell phone have full receiving = capabilities in standby mode.

The cell phone will enter the active = mode (you = said "talk" mode)

after receiving a paging frame containing "setup" message destined to it. 

 

In standby mode, it can listen any = messages of = signalling and/or IP packets.

So, yes it is possible to have a phone in low-power standby mode but (for example) = listening for incoming TCP connections or UDP = packets.

 

However, the power consumption to send = messages is mostly converned when the cell phone is in active mode. =

 

But, I do not think this = should be dominate P2PSIP overlay design in this = stage.

 

 

Gengyu

----- Original Message ----- =

Sent: Thursday, June 28, 2007 6:41 AM

Subject: RE: [P2PSIP] do we need a client protocol?

 

That makes sense.  So my next question is: what are the capabilities of standby mode, and what = triggers it going into “talk” = mode?

 

It must be listening to some sort = of cell signal even in standby mode, just so it can receive phone calls.  = Given this, when in standby mode, does it also have access to the IP = network?  In other words, is it possible to have a phone in low-power standby mode = but (for example) listening for incoming TCP connections or UDP = packets?

 

-david

 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 27, = 2007 1:39 PM
To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

It is more complicated than = this.

Under normal cell phone operation = we have the talk time and the standby time which is much = longer.

 

Making a cell phone a full peer = eliminates this distinction to a large degree since the overlay maintenance messages keep the phone = ‘talking’ all the time.

 

Henry

 

From: David Barrett [mailto:dbarrett@quinthar.com]
Sent: Wednesday, June 27, = 2007 10:06 AM
To: marcin.matuszewski@nokia.com= ; eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

I don’t know anything about = mobile application design vis-=E0-vis battery life, but I’m guessing = power usage could be vastly oversimplified to something = like:

 

Power =3D A + = nB

 

Where A is the overall cost of just = having the device powered on and listening to the radio, and B is the cost of = sending a byte of data.  What I’m wondering is, what is the ratio of = A to B?  Can anyone give real-world = data?

 

For example, I’d accept that = sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough = value of ‘n’, then the constant A gets marginalized.  But what about 200Kbps or 200bps?  For some low value of = ‘n’, then A dominates the power = usage.

 

The reason I ask is I wonder if = it’s even useful to discuss power usage for something like P2PSIP.  It = could be that even for a “real” peer, ‘n’ is so low that = the power consumption is dominated by other factors, rendering the entire discussion moot.

 

Can anybody give real-world data on = this topic?

 

-david =

 

From: marcin.matuszewski@nokia.com= [mailto:marcin.matuszewski@no= kia.com]
Sent: Wednesday, June 27, = 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

Hi,<= /o:p>

 

We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices = are very powerful. From this reason some of mobile terminals may become = peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that = have slow CPUs and limited = memory. 

Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is = calling/answering a call).

    

I was considering a similar = solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We = also have problems with handling = searches.

 

I assume that we will = have some mobile terminals taking part in DHT and some accessing resources stored = in DHT using a client protocol.


Marcin

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; = Avshalom Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do = we need a client protocol?

 

On 6/26/07, = Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought = lately, thinking about the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer = protocol.

For example, a normal peer in the overlay will maintain peer = protocol
connections with many (perhaps dozens) of = peers.  Why?  So that it can
quickly and efficiently route requests within the = overlay.

 

 

Perhaps an energy-limited device could just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests = through the
overlay, but that seems like a reasonable tradeoff. =


The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for adjustment. I = don't think it is under complete control of individual peer in the case of = known DHT algorithms.

 

Also, perhaps there are some other peer = protocol functions, such as data
replication (storage would still be done, but not replication), that =
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that = those peers
who contribute the least to the overlay also get the lowest = performance
from it.



I am not quite sure I understand the benefit of introducing such various = levels of participation.
Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.

Thanks.

Eunsoo

 

Henry Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care = about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than = active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If = so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store = resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It = certainly
> seems that a peer that moves between contributing and = non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into = the
> DHT "right now" might determine whether it is = contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why = something
>> is a peer if it isn't doing anything other than talking to = someone
>> and making requests, hence why I supported client in the first = place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. = It
>> seems completely not in keeping with the idea of P2P. I also = worry it
>>  is likely to be very confusing since we've been = using the other
>> terminology for over a year now. Just looks like a souce of = confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish = to
> contribute resources, and sometimes not have a high-bandwidth = connection
> and therefore not wish to offer resources. Does this modality make = it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the = overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would = I be
>> contributing? If joining the overlay (in the sense that we have = a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer = no
>>
> services
>
> That's "offer no other services", since routing is itself = a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and = a
>> "non-contributing peer" who isn't even part of the = overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For = most DHT models,
> a minimally contributing node will route a request it receives. It = might
> ask nicely (perhaps a q-value mechanism) to not have to route = requests,
> but would probably mathematically still have to route something it = gets.
>
> I think we distinguish based on the service advertisements from = the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets = pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely = peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore = change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip<= br> >
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip<= br> >
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip<= u1:p>

 

______________________________________________= _
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

 






 
______________________________________________=
_
P2PSIP mailing =
list
P2PSIP@ietf.org
https://www1.ietf.=
org/mailman/listinfo/p2psip
=A0
------=_NextPart_000_01EE_01C7B988.F05D0FB0-- --===============0478479859== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0478479859==-- From p2psip-bounces@ietf.org Thu Jun 28 19:46:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I43hL-0000dE-0V; Thu, 28 Jun 2007 19:46:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I43hJ-0000cp-RS for p2psip@ietf.org; Thu, 28 Jun 2007 19:46:49 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I43gd-0006cZ-KX for p2psip@ietf.org; Thu, 28 Jun 2007 19:46:49 -0400 Received: from source ([192.150.11.134]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Thu, 28 Jun 2007 16:45:59 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5SNilot021358; Thu, 28 Jun 2007 16:44:48 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5SNjm0g023415; Thu, 28 Jun 2007 16:45:51 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 16:45:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Thu, 28 Jun 2007 16:44:58 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A265AD@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace5S8RGTciuMw3LSQW/uBPCyz1W8wAdVFugAAc5A2A= References: <468351F0.50404@teigre.com> From: "Henry Sinnreich" To: "David Barrett" , "Greger V. Teigre" , "Wei Gengyu" X-OriginalArrivalTime: 28 Jun 2007 23:45:48.0663 (UTC) FILETIME=[74318870:01C7B9DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1ef0c72f26517e769d58032fa8e3d39 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0734070807==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0734070807== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B9DE.5A10DFE9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B9DE.5A10DFE9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, =20 >Unless I'm misunderstanding it, it's just not possible for a = battery-conscious device to continuously listen on an IP network at this = point. =20 >What am I missing?=20 =20 I believe you are not missing anything, and 2G/3G mobile phones are = listening only to L2 messages. Can someone from the mobile phone industry validate this? What about WiFi phones? =20 Thanks, Henry =20 ________________________________ From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Thursday, June 28, 2007 1:34 PM To: 'Greger V. Teigre'; 'Wei Gengyu' Cc: p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Ok, so it seems fairly likely that a mobile unit can't be a true SIP = peer. But based on all this I question if it's even practical for a = mobile unit to be a SIP *client* because the simple of act of waiting = for somebody to call you will be prohibitively battery-draining. =20 First, Marcin, did I understand you correctly to say that simply being = connected to a WLAN - even if you don't send any data - drains your = battery at a quick pace? This alone suggests that there can be no = long-lived "listening" client-app on a mobile unit (SIP included) due to = practical battery limitations. If this is true, then it makes the whole = discussion moot. =20 Second, assuming you can connect to and listen on a WLAN at all, then = it'd only work if you have a non-NAT'd, non-firewalled address (because = anything other is going to require constant NAT penetration/keepalive = traffic). 80% of real-world connections (and near 100% of actual WLANs) = don't have this property. So again, the discussion seems moot. =20 Third, assume it doesn't cost battery life to listen, and assume you can = somehow have a relevant class of users reliably get non-NAT'd, = non-firewalled IP addresses. With this sort of address you're going to = be subject to the whims of the internet, which is a pretty harsh place - = I'd expect your phone would be undergoing almost constant scans from = worms and hackers, which would require it to constantly respond. So = again, your phone is going to need to actively reject the 99% of "bad" = traffic just to get the "good" incoming call. But the filtering is = likely so expensive that the battery life is unacceptable, and again, = game over. =20 =20 None of this has anything to do with SIP. Unless I'm misunderstanding = it, it's just not possible for a battery-conscious device to = continuously listen on an IP network at this point. What am I missing? = =20 -david =20 ________________________________ From: Greger V. Teigre [mailto:greger@teigre.com]=20 Sent: Wednesday, June 27, 2007 11:15 PM To: Wei Gengyu Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? =20 Well, it's a bit more complicated than that. For one thing, there's a = difference between mobile and WLAN. Even with the power-saving mode of = 802.11g for example, there's still more power drain when connected to = WLAN, than mobile. And on mobile, you have many scenarios, just take the = GSM (which I know the best), you have GSM High-Speed, still used by many = roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data = connections. You can have three modes, each with different power = consumption: No connection (only voice), PDP context established, and = active connection. Real-life experimentation with various modes and = applications using these modes show that battery drainage is a real = problem.=20 As an example: a native Symbian application that looks up incoming calls = (over 3G data connection) where caller-id is not found in the local = contact list needs to have an active connection (not only PDP context), = because in order to show the caller's data, the lookup must be almost = instantaneous. In reality, it takes about 1 second. This application is = pretty much useless if you actually make any calls, because at the end = of the day, you don't have battery left... BTW, the same holds for innovative mobile VoIP apps such as Fling. For a mobile unit to be a peer, we need a battery revolution. g-) Wei Gengyu wrote:=20 Hi,=20 =20 A cell phone have full receiving capabilities in standby mode. The cell phone will enter the active mode (you said "talk" mode)=20 after receiving a paging frame containing "setup" message destined to = it.=20 =20 In standby mode, it can listen any messages of signalling and/or IP = packets. So, yes it is possible to have a phone in low-power standby mode but = (for example) listening for incoming TCP connections or UDP packets. =20 However, the power consumption to send messages is mostly converned when = the cell phone is in active mode.=20 =20 But, I do not think this should be dominate P2PSIP overlay design in = this stage. =20 =20 Gengyu ----- Original Message -----=20 From: David Barrett =20 To: 'Henry Sinnreich' ; = marcin.matuszewski@nokia.com ; eunsooshim@gmail.com ; = alan@sipstation.com=20 Cc: AVSHALOM@il.ibm.com ; philip_matthews@magma.ca ; p2psip@ietf.org=20 Sent: Thursday, June 28, 2007 6:41 AM Subject: RE: [P2PSIP] do we need a client protocol? =20 That makes sense. So my next question is: what are the capabilities of = standby mode, and what triggers it going into "talk" mode? =20 It must be listening to some sort of cell signal even in standby mode, = just so it can receive phone calls. Given this, when in standby mode, = does it also have access to the IP network? In other words, is it = possible to have a phone in low-power standby mode but (for example) = listening for incoming TCP connections or UDP packets? =20 -david =20 =09 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 27, 2007 1:39 PM To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 It is more complicated than this. Under normal cell phone operation we have the talk time and the standby = time which is much longer. =20 Making a cell phone a full peer eliminates this distinction to a large = degree since the overlay maintenance messages keep the phone 'talking' = all the time. =20 Henry =20 =09 ________________________________ From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Wednesday, June 27, 2007 10:06 AM To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 I don't know anything about mobile application design vis-=E0-vis = battery life, but I'm guessing power usage could be vastly = oversimplified to something like: =20 Power =3D A + nB =20 Where A is the overall cost of just having the device powered on and = listening to the radio, and B is the cost of sending a byte of data. = What I'm wondering is, what is the ratio of A to B? Can anyone give = real-world data? =20 For example, I'd accept that sending 200Mbps probably requires about 2x = the power 100Mbps: for a high enough value of 'n', then the constant A = gets marginalized. But what about 200Kbps or 200bps? For some low = value of 'n', then A dominates the power usage. =20 The reason I ask is I wonder if it's even useful to discuss power usage = for something like P2PSIP. It could be that even for a "real" peer, 'n' = is so low that the power consumption is dominated by other factors, = rendering the entire discussion moot. =20 Can anybody give real-world data on this topic? =20 -david=20 =20 =09 ________________________________ From: marcin.matuszewski@nokia.com = [mailto:marcin.matuszewski@nokia.com]=20 Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile = terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of = mobile terminals may become peers (depending on the case scenario: = churn, size of the network). However there are also many = entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long = battery life. DHT maintenance and handling searches have impact on idle = state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number = of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and = some accessing resources stored in DHT using a client protocol. =09 Marcin =09 ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =20 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the = actual requirements. =09 We want to allow energy-limited devices to participate to some level = in P2PSIP. As such, perhaps instead of saying we need a client = protocol,=20 perhaps we just need levels of participation in the overlay peer = protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can = quickly and efficiently route requests within the overlay. =20 =20 Perhaps an energy-limited device could just minimize the number of = peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 =09 The underling algorithm (e.g. a certain DHT algorithm) will dictate = the number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual = peer in the case of known DHT algorithms.=20 =20 Also, perhaps there are some other peer protocol functions, such as = data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their = requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest = performance from it. =09 =09 I am not quite sure I understand the benefit of introducing such = various levels of participation. Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =20 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client = protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care = about the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) = entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If = so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and = non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into = the > DHT "right now" might determine whether it is contributing "right = now" > or not. > > >> My concern all along has been that I don't understand why = something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first = place. >> I fail to see how something that isn't contributing anything, and = >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry = it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make = it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I = be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a = service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., = no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets = pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely = peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =09 ________________________________ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 =20 ________________________________ =20 =20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------_=_NextPart_001_01C7B9DE.5A10DFE9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

David,

 

>Unless I’m = misunderstanding it, it’s just not possible for a battery-conscious device to = continuously listen on an IP network at this point.  =

>What am I = missing? 

 

I believe you are not missing = anything, and 2G/3G mobile phones are listening only to L2 = messages.

Can someone from the mobile phone = industry validate this?

What about WiFi = phones?

 

Thanks, = Henry

 

From: David Barrett [mailto:dbarrett@quinthar.com]
Sent: Thursday, June 28, = 2007 1:34 PM
To: 'Greger V. Teigre'; = 'Wei Gengyu'
Cc: = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

Ok, so it seems fairly likely that = a mobile unit can’t be a true SIP peer.  But based on all this = I question if it’s even practical for a mobile unit to be a SIP = *client* because the simple of act = of waiting for somebody to call you will be prohibitively = battery-draining.

 

First, Marcin, did I understand you correctly to say that simply being connected to a WLAN – even if = you don’t send any data – drains your battery at a quick = pace?  This alone suggests that there can be no long-lived = “listening” client-app on a mobile unit (SIP included) due to practical battery limitations.  If this is true, then it makes the whole discussion = moot.

 

Second, assuming you can connect to = and listen on a WLAN at all, then it’d only work if you have a non-NAT’d, non-firewalled address (because anything other is going = to require constant NAT penetration/keepalive traffic).  80% of = real-world connections (and near 100% of actual WLANs) don’t have this property.  So again, the discussion seems = moot.

 

Third, assume it doesn’t cost battery life to listen, and assume you can somehow have a relevant class = of users reliably get non-NAT’d, non-firewalled IP addresses.  = With this sort of address you’re going to be subject to the whims of = the internet, which is a pretty harsh place – I’d expect your = phone would be undergoing almost = constant scans from worms and hackers, which would require it to constantly respond.  So again, your phone is going to need to actively reject = the 99% of “bad” traffic just to get the “good” incoming call.  But the filtering is likely so expensive that the battery = life is unacceptable, and again, game over.

 

 

None of this has anything to do = with SIP.  Unless I’m misunderstanding it, it’s just not = possible for a battery-conscious device to continuously listen on an IP network = at this point.  What am I missing? 

 

-david

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Wednesday, June 27, = 2007 11:15 PM
To: Wei Gengyu
Cc: = p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a client protocol?

 

Well, it's a bit more complicated than that. = For one thing, there's a difference between mobile and WLAN. Even with the = power-saving mode of 802.11g for example, there's still more power drain when = connected to WLAN, than mobile. And on mobile, you have many scenarios, just take the = GSM (which I know the best), you have GSM High-Speed, still used by many roadwarriors in many areas of the world, and you have GPRS/EDGE/3G data connections. You can have three modes, each with different power = consumption: No connection (only voice), PDP context established, and active = connection. Real-life experimentation with various modes and applications using = these modes show that battery drainage is a real problem.
As an example: a native Symbian application that looks up incoming calls = (over 3G data connection) where caller-id is not found in the local contact = list needs to have an active connection (not only PDP context), because in = order to show the caller's data, the lookup must be almost instantaneous. In = reality, it takes about 1 second.  This application is pretty much useless if = you actually make any calls, because at the end of the day, you don't have = battery left...
BTW, the same holds for innovative mobile VoIP apps such as Fling.

For a mobile unit to be a peer, we need a battery revolution.
g-)

Wei Gengyu wrote:

Hi,

 

A cell phone have full receiving = capabilities in standby mode.

The cell phone will enter the active = mode (you = said "talk" mode)

after receiving a paging frame containing "setup" message destined to it. 

 

In standby mode, it can listen any = messages of = signalling and/or IP packets.

So, yes it is possible to have a phone in low-power standby mode but (for example) listening = for incoming TCP connections or UDP packets.

 

However, the power consumption to send = messages is mostly converned when the cell phone is in active mode. =

 

But, I do not think this = should be dominate P2PSIP overlay design in this = stage.

 

 

Gengyu

----- Original Message ----- =

Sent: Thursday, June 28, 2007 6:41 AM

Subject: RE: [P2PSIP] do we need a client protocol?

 

That makes sense.  So my next question is: what are the capabilities of standby mode, and what = triggers it going into “talk” = mode?

 

It must be listening to some sort = of cell signal even in standby mode, just so it can receive phone calls.  = Given this, when in standby mode, does it also have access to the IP = network?  In other words, is it possible to have a phone in low-power standby mode = but (for example) listening for incoming TCP connections or UDP = packets?

 

-david

 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 27, = 2007 1:39 PM
To: David Barrett; marcin.matuszewski@nokia.com; eunsooshim@gmail.com; alan@sipstation.com
Cc: AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

It is more complicated than = this.

Under normal cell phone operation = we have the talk time and the standby time which is much = longer.

 

Making a cell phone a full peer = eliminates this distinction to a large degree since the overlay maintenance messages keep the phone ‘talking’ all the = time.

 

Henry

 

From: David Barrett [mailto:dbarrett@quinthar.com]
Sent: Wednesday, June 27, = 2007 10:06 AM
To: marcin.matuszewski@nokia.com= ; eunsooshim@gmail.com; alan@sipstation.com
Cc: Henry Sinnreich; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

I don’t know anything about = mobile application design vis-=E0-vis battery life, but I’m guessing = power usage could be vastly oversimplified to something = like:

 

Power =3D A + = nB

 

Where A is the overall cost of just = having the device powered on and listening to the radio, and B is the cost of = sending a byte of data.  What I’m wondering is, what is the ratio of = A to B?  Can anyone give real-world = data?

 

For example, I’d accept that = sending 200Mbps probably requires about 2x the power 100Mbps: for a high enough = value of ‘n’, then the constant A gets marginalized.  But what = about 200Kbps or 200bps?  For some low value of ‘n’, then A dominates the power usage.

 

The reason I ask is I wonder if = it’s even useful to discuss power usage for something like P2PSIP.  It = could be that even for a “real” peer, ‘n’ is so low that = the power consumption is dominated by other factors, rendering the entire discussion moot.

 

Can anybody give real-world data on = this topic?

 

-david =

 

From: marcin.matuszewski@nokia.com= [mailto:marcin.matuszewski@no= kia.com]
Sent: Wednesday, June 27, = 2007 12:33 AM
To: eunsooshim@gmail.com; alan@sipstation.com
Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a client protocol?

 

Hi,<= /o:p>

 

We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices = are very powerful. From this reason some of mobile terminals may become = peers (depending on the case scenario: churn, size of the = network). However there are also many entry-level/low-end devices that = have slow CPUs and limited = memory. 

Battery life is another issue. Most of the mobile phone users want = long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is = calling/answering a call).

    

I was considering a similar = solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We = also have problems with handling = searches.

 

I assume that we will = have some mobile terminals taking part in DHT and some accessing resources stored = in DHT using a client protocol.


Marcin

From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com] =
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP = Mailing List
Subject: Re: [P2PSIP] do = we need a client protocol?

 

On 6/26/07, = Alan Johnston <alan@sipstation.com> wrote:

I've been giving this a lot of thought = lately, thinking about the actual
requirements.

We want to allow energy-limited devices to participate to some level in
P2PSIP.   As such, perhaps instead of saying we need a client protocol,
perhaps we just need levels of participation in the overlay peer = protocol.

For example, a normal peer in the overlay will maintain peer = protocol
connections with many (perhaps dozens) of = peers.  Why?  So that it can
quickly and efficiently route requests within the = overlay.

 

 

Perhaps an energy-limited device could = just minimize the number of peer
protocol connections it maintains, perhaps even down to a minimum of
two.  This would result in slower routing of its requests = through the
overlay, but that seems like a reasonable tradeoff. =


The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for adjustment. I = don't think it is under complete control of individual peer in the case of = known DHT algorithms.

 

Also, perhaps there are some other peer = protocol functions, such as data
replication (storage would still be done, but not replication), that =
could be skipped by these energy-limited peers.  Perhaps their requests
and responses could be routed over the overlay with a lower priority
than full peers.  We need to manage the tradeoffs so that = those peers
who contribute the least to the overlay also get the lowest = performance
from it.



I am not quite sure I understand the benefit of introducing such various = levels of participation.
Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.

Thanks.

Eunsoo

 

Henry = Sinnreich wrote:
> Folks,
>
> Given the length of the discussion on "do we need a client protocol?"
> let me repeat the simple imperatives for the client:
>
> - Limited battery in mobile devices, and
>
> - Other uses besides SIP. Business planning folks may not care = about the
> WG charter, but about the return on the investment.
>
> Thanks, Henry
>
> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: David A. Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive
> peerterminology
>
> David A. Bryan wrote:
>
>> If I understand this right, not sure I like it. Do these
>>
> "non-contributing
>
>> peer" (I *do* like contributing better than = active/passive) entities
>>
> have a
>
>> Peer-ID? In otherwords, are they part of the overlay at all? If = so,
>>
> for
>
>> most
>> DHTs, how do we allow you to be in the overlay and not store = resources
>>
> (not
>
>> typical for most current DHT algorithms)
>>
>
> Well, that certainly depends on the DHT algorithm involved. It = certainly
> seems that a peer that moves between contributing and = non-contributing
> might HAVE a peer ID, but whether it chooses to insert itself into = the
> DHT "right now" might determine whether it is = contributing "right now"
> or not.
>
>
>> My concern all along has been that I don't understand why = something
>> is a peer if it isn't doing anything other than talking to = someone
>> and making requests, hence why I supported client in the first = place.
>>  I fail to see how something that isn't contributing anything, and
>> instead talks to a peer to get resources, is in any way a peer. = It
>> seems completely not in keeping with the idea of P2P. I also = worry it
>>  is likely to be very confusing since we've been = using the other
>> terminology for over a year now. Just looks like a souce of = confusion.
>>
>
> A node might sometimes have a high-bandwidth connection and wish = to
> contribute resources, and sometimes not have a high-bandwidth = connection
> and therefore not wish to offer resources. Does this modality make = it
> two different nodes?
>
>
>> If we do go this way, there is one subtle point. If I join the = overlay
>>
> but
>
>> don't happen to offer any services (other than maybe
>>
> storage...depending on
>
>> how we definie it, that might or might not be mandatory), would = I be
>> contributing? If joining the overlay (in the sense that we have = a
>>
> PeerID
>
>> and
>> we route traffic) doesn't require me to store, I could offer = no
>>
> services
>
> That's "offer no other services", since routing is itself = a service.
>
>
>> and
>> still be a peer. How do we distinguish between this case and = a
>> "non-contributing peer" who isn't even part of the = overlay (i.e., no
>> Peer-ID)
>>
>
> I think there's a range of "contributing" in play. For = most DHT models,
> a minimally contributing node will route a request it receives. It = might
> ask nicely (perhaps a q-value mechanism) to not have to route = requests,
> but would probably mathematically still have to route something it = gets.
>
> I think we distinguish based on the service advertisements from = the
> peer.
>
>
>> If we are so opposed to client for confusion with SIP UAs, lets = pick a
>>
> new
>
>> name, but why some flavor of peer when it does nothing remotely = peer
>>
> like?
>
> Because in 15 minutes it might roam onto a WiFi net and therefore = change
> it service offering.
>
> --
> Dean
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip<= br> >
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip<= br> >
>
>


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip<= o:p>

 

______________________________________________= _
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

 
 
 






 
 
 
______________________________________________=
_
P2PSIP mailing =
list
P2PSIP@ietf.org
https://www1.ietf.=
org/mailman/listinfo/p2psip
 
------_=_NextPart_001_01C7B9DE.5A10DFE9-- --===============0734070807== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0734070807==-- From p2psip-bounces@ietf.org Fri Jun 29 01:32:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I495k-0007DQ-C6; Fri, 29 Jun 2007 01:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I495j-0007C6-67 for p2psip@ietf.org; Fri, 29 Jun 2007 01:32:23 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I495c-0001Ay-Di for p2psip@ietf.org; Fri, 29 Jun 2007 01:32:23 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I495a-0000Fi-SZ; Fri, 29 Jun 2007 00:32:15 -0500 In-Reply-To: <467DB508.6040108@sip-communicator.org> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Fri, 29 Jun 2007 00:32:06 -0500 To: Emil Ivov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 23, 2007, at 7:04 PM, Emil Ivov wrote: > > > Dean Willis wrote: >> Right. UDP hole-punching techniques do not, in general, work on >> enterprise firewalls, such as the one operated by the IT >> department of >> my most recent former employer. Said firewalls block all incoming >> UDP, >> except for certain allowed ports to certain allowed hosts (needed >> for DNS). > > This probably means that the people administrating the firewall > most likely did not want any media/voip traffic coming in and were > explicitly blocking it. If this is really the case then I wonder > whether we should be worried about it since the same people could > very easily find ways to block media and voip even if they were > transported by tcp. > No, the inbound rule looks like "DISCARD UDP ANY ANY" unless a prior rule allowed DNS through to the DNS server. They weren't singling out "media" traffic. They were just using a large blunt object to club all UDP traffic into submission, because there's no good way to tell whether a node inside the firewall wants/ needs to receive arbitrary UDP traffic right now. This is a VERY common firewall policy for enterprises basing the firewalls on conventional router ACLs, Linux iptables, Cisco firewall feature set, and so on. And yes, I installed a large number of enterprise firewalls that did exactly this back when I was doing that for a living. >> On the other hand, Skype worked just fine from behind that same >> firewall. > > Are you certain that the reason for this was protocol related. > Isn't it likely that this was either intentional or the firewall > was not advanced enough and was not analyzing traffic any further > beyond transport and port. In either case I doubt the phenomenon is > something that TCP would always be a solution for. Huh? Yeah, it was protocol related. The firewall effectively blocked all UDP, and allowed TCP only when the connection was established from within the firewall. Again, this is pretty much standard for companies that don't restrict things further by only allowing HTTP traffic using an HTTP proxy in their firewall, and otherwise also blocking TCP. That's why applications that REALLY work through firewalls can do things like tunnel media over HTTP requests. As to whether this means the "firewall was not advanced enough", I suppose that's open to interpretation. But this IS what most enterprise firewalls do, and it was at a company that makes a large share of the enterprise firewalls in use today (so they ought to know) . . . and they're still using it now as far as I know. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 01:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I49UR-0005Sh-8Y; Fri, 29 Jun 2007 01:57:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I49UP-0005M2-6k for p2psip@ietf.org; Fri, 29 Jun 2007 01:57:53 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I49UO-00088w-QF for p2psip@ietf.org; Fri, 29 Jun 2007 01:57:53 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I49Tk-0000H1-Bx; Fri, 29 Jun 2007 00:57:12 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 00:57:04 -0500 To: David Barrett X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 28, 2007, at 3:33 PM, David Barrett wrote: > Ok, so it seems fairly likely that a mobile unit can=92t be a true =20 > SIP peer. But based on all this I question if it=92s even practical =20= > for a mobile unit to be a SIP *client* because the simple of act of =20= > waiting for somebody to call you will be prohibitively battery-=20 > draining. It all depends . . . on which radio network you are using, mostly. In some environments, the IP stack is effectively turned "off", and =20 there is no radio channel allocated for a device that's just =20 "waiting". Instead, the layer 2 switching device (aka PDSN or GGSN), =20 when it has a packet for the mobile, sends a "paging" message to the =20 mobile to wake it up. The mobile then sets up a layer 2 session, over =20= which it establishes an IP default route, and eventually receives the =20= "packet". This might take upwards of 10 seconds, and messes with many =20= IP applications badly. But it saves a lot of power. And if you're doing "outbound" style keepalive, you won't get this =20 sort of efficiency. And it's just not going to let that mobile be a =20 full DHT node. > > > First, Marcin, did I understand you correctly to say that simply =20 > being connected to a WLAN =96 even if you don=92t send any data =96 =20= > drains your battery at a quick pace? This alone suggests that =20 > there can be no long-lived =93listening=94 client-app on a mobile unit = =20 > (SIP included) due to practical battery limitations. If this is =20 > true, then it makes the whole discussion moot. This varies, but with today's chipsets and batteries, a typical PDA =20 device can run its WLAN in "listen" mode for only a few (perhaps up =20 to 6) hours. There are some proprietary tricks to extend this when =20 there's no active communication, some of which (especially if the PDA =20= and its access point collaborate) can run the standby time up to =20 several days, much like the standby time on a mobile phone network =20 (and pretty much using the same tricks). If the device is actively =20 transmitting, talk time plummets rapidly. Now, is 6 hours enough? It'll certainly get the floor boss of a =20 warehouse through a 4 hour shift using his PDA-phone. He changes =20 batteries on his lunch break, then works another 4 hours. =46rom an emergency responder perspective: 6 hours is a lot more time =20= than one might get from a Scott airpack: http://=20 www.scotthealthsafety.com/airpak.htm. You'll be back at the truck =20 recharging long before the battery goes dead from standby load. > Second, assuming you can connect to and listen on a WLAN at all, =20 > then it=92d only work if you have a non-NAT=92d, non-firewalled = address =20 > (because anything other is going to require constant NAT =20 > penetration/keepalive traffic). 80% of real-world connections (and =20= > near 100% of actual WLANs) don=92t have this property. So again, the =20= > discussion seems moot. Many of the mobile-operator networks are designed with no NATs and =20 firewalls between the mobile device and its upstream IP elements for =20 just this reason. Hence, no need for NAT-keepalive. > Third, assume it doesn=92t cost battery life to listen, and assume =20 > you can somehow have a relevant class of users reliably get non-=20 > NAT=92d, non-firewalled IP addresses. With this sort of address =20 > you=92re going to be subject to the whims of the internet, which is a =20= > pretty harsh place =96 I=92d expect your phone would be undergoing =20 > almost constant scans from worms and hackers, which would require =20 > it to constantly respond. So again, your phone is going to need to =20= > actively reject the 99% of =93bad=94 traffic just to get the =93good=94 = =20 > incoming call. But the filtering is likely so expensive that the =20 > battery life is unacceptable, and again, game over. There can certainly be firewalls and or NATs "further out", beyond =20 the upstream IP device. Again, this is typical in mobile operator =20 environments. > None of this has anything to do with SIP. Unless I=92m =20 > misunderstanding it, it=92s just not possible for a battery-conscious =20= > device to continuously listen on an IP network at this point. What =20= > am I missing? Details, mostly. Missing details. It's an ugly world out there, and =20 much of what we imagine to be the Internet isn't what we imagine it =20 to be. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 03:02:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4AV3-0007Ry-HV; Fri, 29 Jun 2007 03:02:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4AV2-0007JN-83 for p2psip@ietf.org; Fri, 29 Jun 2007 03:02:36 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4AUx-00070t-Ql for p2psip@ietf.org; Fri, 29 Jun 2007 03:02:36 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Fri, 29 Jun 2007 00:02:28 -0700 From: "David Barrett" To: "'Dean Willis'" Subject: RE: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 00:02:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace6EmM104qM95IuQwyLm4wViKLPNAABoZIg X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Subject: Re: [P2PSIP] do we need a client protocol? > > > None of this has anything to do with SIP. Unless I'm > > misunderstanding it, it's just not possible for a battery-conscious > > device to continuously listen on an IP network at this point. What > > am I missing? > > Details, mostly. Missing details. It's an ugly world out there, and > much of what we imagine to be the Internet isn't what we imagine it > to be. Good, thanks for those details. So: - Some mobile applications listen for a 'page' to fire up the IP stack - Some PDAs can go 4-6 hours in IP "listen" mode. - Many mobile IP devices have no NAT/FW . But they might have them "further out" These details seem to largely reaffirm that IP-based applications generally can't spend a long time in "listen" mode without high battery drain, and thus maybe it's a distraction to even spend energy discussing it in the context of P2PSIP. Until the whole IP network listen/battery-life thing has been worked out in a more general fashion (ie, one that doesn't require layer 2 tricks between the client and the network), it's probably premature to worry about. Do you agree, or did I misunderstand your conclusion? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 03:22:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ank-0006HE-Tv; Fri, 29 Jun 2007 03:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Anj-0006Df-KR for p2psip@ietf.org; Fri, 29 Jun 2007 03:21:55 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Anf-0004qN-3t for p2psip@ietf.org; Fri, 29 Jun 2007 03:21:55 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5T7LLqG003988; Fri, 29 Jun 2007 10:21:48 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 10:21:31 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 10:21:31 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 10:24:10 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04A473B1@esebe102.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace6EmM104qM95IuQwyLm4wViKLPNAABoZIgAADwhjA= References: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> From: To: , X-OriginalArrivalTime: 29 Jun 2007 07:21:31.0016 (UTC) FILETIME=[1D818080:01C7BA1E] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi David, Do I understand you correctly: According to your conclussion VoIP is not going to work on any battery powered device? We may forget about billions of phones out there, battery limitations, nat traversal and security issues - who cares about them. The world is perfect!=20 Marcin =20 >-----Original Message----- >From: ext David Barrett [mailto:dbarrett@quinthar.com]=20 >Sent: 29 June, 2007 10:02 >To: 'Dean Willis' >Cc: p2psip@ietf.org >Subject: RE: [P2PSIP] do we need a client protocol? > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Subject: Re: [P2PSIP] do we need a client protocol? >>=20 >> > None of this has anything to do with SIP. Unless I'm=20 >> > misunderstanding it, it's just not possible for a=20 >battery-conscious=20 >> > device to continuously listen on an IP network at this=20 >point. What=20 >> > am I missing? >>=20 >> Details, mostly. Missing details. It's an ugly world out there, and=20 >> much of what we imagine to be the Internet isn't what we=20 >imagine it to=20 >> be. > >Good, thanks for those details. So: > >- Some mobile applications listen for a 'page' to fire up the IP stack >- Some PDAs can go 4-6 hours in IP "listen" mode. >- Many mobile IP devices have no NAT/FW > . But they might have them "further out" > >These details seem to largely reaffirm that IP-based=20 >applications generally can't spend a long time in "listen"=20 >mode without high battery drain, and thus maybe it's a=20 >distraction to even spend energy discussing it in the context=20 >of P2PSIP. > >Until the whole IP network listen/battery-life thing has been=20 >worked out in a more general fashion (ie, one that doesn't=20 >require layer 2 tricks between the client and the network),=20 >it's probably premature to worry about. > >Do you agree, or did I misunderstand your conclusion? > >-david > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 03:34:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Azx-0005V9-1R; Fri, 29 Jun 2007 03:34:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Azv-0005Uy-Dr for p2psip@ietf.org; Fri, 29 Jun 2007 03:34:31 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Azn-0001PW-Rj for p2psip@ietf.org; Fri, 29 Jun 2007 03:34:31 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5T7Dstl001459; Fri, 29 Jun 2007 09:13:55 +0200 Message-ID: <4684B5F6.4080604@teigre.com> Date: Fri, 29 Jun 2007 09:34:14 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [P2PSIP] do we need a client protocol? References: <200706290642.l5T6gBWQ032615@pontius.teigre.com> In-Reply-To: <200706290642.l5T6gBWQ032615@pontius.teigre.com> X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.5 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1737876510==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1737876510== Content-Type: multipart/alternative; boundary="------------090306060905030908010204" This is a multi-part message in MIME format. --------------090306060905030908010204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Let me share some "running code" with you: Running SIP Express Router (http://iptel.org/) with OPTIONS ping from the server to a Nokia E70 every 30 seconds (as the E70 does not have any NAT traversal awareness, but it will respond 200 OK to the OPTIONS), the E70 will take you through a full work day (8+ hours), with a registration on WLAN (802.11g), as well as standard GSM on. Talk time about 1-1.5 hours. The WLAN access point is a standard <$100 device. The biggest problem has actually been the TCP/IP stack, where actually getting an IP address can be a problem. See http://www.iptel.org/config/nokia_e70 for more info. Add a Bluetooth headset to the mix and you got yourself less time, but it works surprisingly well... My experience is that an active 3G connection drains more battery than an active SIP registration with 30 sec pings over WLAN. I don't know mobile inner workings good enough to back that up, though... g-) David Barrett wrote: >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Subject: Re: [P2PSIP] do we need a client protocol? >> >> >>> None of this has anything to do with SIP. Unless I'm >>> misunderstanding it, it's just not possible for a battery-conscious >>> device to continuously listen on an IP network at this point. What >>> am I missing? >>> >> Details, mostly. Missing details. It's an ugly world out there, and >> much of what we imagine to be the Internet isn't what we imagine it >> to be. >> > > Good, thanks for those details. So: > > - Some mobile applications listen for a 'page' to fire up the IP stack > - Some PDAs can go 4-6 hours in IP "listen" mode. > - Many mobile IP devices have no NAT/FW > . But they might have them "further out" > > These details seem to largely reaffirm that IP-based applications generally > can't spend a long time in "listen" mode without high battery drain, and > thus maybe it's a distraction to even spend energy discussing it in the > context of P2PSIP. > > Until the whole IP network listen/battery-life thing has been worked out in > a more general fashion (ie, one that doesn't require layer 2 tricks between > the client and the network), it's probably premature to worry about. > > Do you agree, or did I misunderstand your conclusion? > > -david > > > --------------090306060905030908010204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Let me share some "running code" with you:
Running SIP Express Router (http://iptel.org/) with OPTIONS ping from the server to a Nokia E70 every 30 seconds (as the E70 does not have any NAT traversal awareness, but it will respond 200 OK to the OPTIONS), the E70 will take you through a full work day (8+ hours), with a registration on WLAN (802.11g), as well as standard GSM on. Talk time about 1-1.5 hours. The WLAN access point is a standard <$100 device.

The biggest problem has actually been the TCP/IP stack, where actually getting an IP address can be a problem. See http://www.iptel.org/config/nokia_e70 for more info.

Add a Bluetooth headset to the mix and you got yourself less time, but it works surprisingly well...

My experience is that an active 3G connection drains more battery than an active SIP registration with 30 sec pings over WLAN. I don't know mobile inner workings good enough to back that up, though...
g-)

David Barrett wrote: 
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Subject: Re: [P2PSIP] do we need a client protocol?

    
None of this has anything to do with SIP.  Unless I'm
misunderstanding it, it's just not possible for a battery-conscious
device to continuously listen on an IP network at this point.  What
am I missing?
      
Details, mostly. Missing details. It's an ugly world out there, and
much of what we imagine to be the Internet isn't what we imagine it
to be.
    

Good, thanks for those details.  So:

- Some mobile applications listen for a 'page' to fire up the IP stack
- Some PDAs can go 4-6 hours in IP "listen" mode.
- Many mobile IP devices have no NAT/FW
	. But they might have them "further out"

These details seem to largely reaffirm that IP-based applications generally
can't spend a long time in "listen" mode without high battery drain, and
thus maybe it's a distraction to even spend energy discussing it in the
context of P2PSIP.

Until the whole IP network listen/battery-life thing has been worked out in
a more general fashion (ie, one that doesn't require layer 2 tricks between
the client and the network), it's probably premature to worry about.

Do you agree, or did I misunderstand your conclusion?

-david
--------------090306060905030908010204-- --===============1737876510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1737876510==-- From p2psip-bounces@ietf.org Fri Jun 29 03:40:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4B5U-0002cP-8E; Fri, 29 Jun 2007 03:40:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4B5S-0002cG-Ox for p2psip@ietf.org; Fri, 29 Jun 2007 03:40:14 -0400 Received: from pontius.teigre.com ([213.225.78.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4B5G-0002yT-56 for p2psip@ietf.org; Fri, 29 Jun 2007 03:40:14 -0400 X-ClientAddr: 217.144.232.26 Received: from [127.0.0.1] ([217.144.232.26]) by pontius.teigre.com (8.12.11/8.12.11) with ESMTP id l5T7JUiY001663; Fri, 29 Jun 2007 09:19:30 +0200 Message-ID: <4684B745.3000608@teigre.com> Date: Fri, 29 Jun 2007 09:39:49 +0200 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: David Barrett Subject: Re: [P2PSIP] do we need a client protocol? References: <200706290642.l5T6gBWQ032615@pontius.teigre.com> In-Reply-To: <200706290642.l5T6gBWQ032615@pontius.teigre.com> X-teigrecom-MailScanner-Information: Please contact the ISP for more information X-teigrecom-MailScanner: Found to be clean X-MailScanner-From: greger@teigre.com X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0258748386==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0258748386== Content-Type: multipart/alternative; boundary="------------050001020101080201000504" This is a multi-part message in MIME format. --------------050001020101080201000504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To answer the question directly: I believe mobile devices over WLAN should be considered. There is also a category of tablet-type, battery-powered devices (when is it a mobile and when is it a PC?). With regards to mobile devices over 3G, I believe GET/PUT operations can be of interest to applications (if such operations are allowed, ref. opendht.org). IMHO, we cannot afford to not consider battery-constrained devices. g-) David Barrett wrote: >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Subject: Re: [P2PSIP] do we need a client protocol? >> >> >>> None of this has anything to do with SIP. Unless I'm >>> misunderstanding it, it's just not possible for a battery-conscious >>> device to continuously listen on an IP network at this point. What >>> am I missing? >>> >> Details, mostly. Missing details. It's an ugly world out there, and >> much of what we imagine to be the Internet isn't what we imagine it >> to be. >> > > Good, thanks for those details. So: > > - Some mobile applications listen for a 'page' to fire up the IP stack > - Some PDAs can go 4-6 hours in IP "listen" mode. > - Many mobile IP devices have no NAT/FW > . But they might have them "further out" > > These details seem to largely reaffirm that IP-based applications generally > can't spend a long time in "listen" mode without high battery drain, and > thus maybe it's a distraction to even spend energy discussing it in the > context of P2PSIP. > > Until the whole IP network listen/battery-life thing has been worked out in > a more general fashion (ie, one that doesn't require layer 2 tricks between > the client and the network), it's probably premature to worry about. > > Do you agree, or did I misunderstand your conclusion? > > -david > > > --------------050001020101080201000504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To answer the question directly: I believe mobile devices over WLAN should be considered. There is also a category of tablet-type, battery-powered devices (when is it a mobile and when is it a PC?). With regards to mobile devices over 3G, I believe GET/PUT operations can be of interest to applications (if such operations are allowed, ref. opendht.org).
IMHO, we cannot afford to not consider battery-constrained devices.
g-)

David Barrett wrote: 
-----Original Message-----
From: Dean Willis [mailto:dean.willis@softarmor.com]
Subject: Re: [P2PSIP] do we need a client protocol?

    
None of this has anything to do with SIP.  Unless I'm
misunderstanding it, it's just not possible for a battery-conscious
device to continuously listen on an IP network at this point.  What
am I missing?
      
Details, mostly. Missing details. It's an ugly world out there, and
much of what we imagine to be the Internet isn't what we imagine it
to be.
    

Good, thanks for those details.  So:

- Some mobile applications listen for a 'page' to fire up the IP stack
- Some PDAs can go 4-6 hours in IP "listen" mode.
- Many mobile IP devices have no NAT/FW
	. But they might have them "further out"

These details seem to largely reaffirm that IP-based applications generally
can't spend a long time in "listen" mode without high battery drain, and
thus maybe it's a distraction to even spend energy discussing it in the
context of P2PSIP.

Until the whole IP network listen/battery-life thing has been worked out in
a more general fashion (ie, one that doesn't require layer 2 tricks between
the client and the network), it's probably premature to worry about.

Do you agree, or did I misunderstand your conclusion?

-david
--------------050001020101080201000504-- --===============0258748386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0258748386==-- From p2psip-bounces@ietf.org Fri Jun 29 03:40:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4B63-00034w-NX; Fri, 29 Jun 2007 03:40:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4B63-00034o-57 for p2psip@ietf.org; Fri, 29 Jun 2007 03:40:51 -0400 Received: from esm2-mxsmtp.corp.vodafone.es ([212.166.209.29]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4B5q-00032X-LI for p2psip@ietf.org; Fri, 29 Jun 2007 03:40:51 -0400 Received: from esm2-mxsmtp04.vf-es.internal.vodafone.com ([195.232.228.172]) by esm2-mxsmtp.corp.vodafone.es with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 09:40:42 +0200 Received: from esm9-mxsmtp05.vf-es.internal.vodafone.com ([10.229.28.16]) by esm2-mxsmtp04.vf-es.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 09:41:07 +0200 Received: from ESM9-MXMB06.vf-es.internal.vodafone.com ([10.229.29.23]) by esm9-mxsmtp05.vf-es.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 09:40:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 09:40:25 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace6EmM104qM95IuQwyLm4wViKLPNAABoZIgAAEqGwAAAMiAYA== References: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> From: "Dominguez, Curro, VF-ES \(fdoming4\)" To: "David Barrett" , "Dean Willis" X-OriginalArrivalTime: 29 Jun 2007 07:40:26.0224 (UTC) FILETIME=[C2247F00:01C7BA20] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 Hi all,=20 I think most of you will find useful the details provided in this article= http://blogs.msdn.com/windowsmobile/archive/2006/08/04/689069.aspx I've been researching some time about the impact that applications have o= n battery life, but I have to say there's no much information. (So I'd be= willing to read the paper of Marcin's mates at Nokia).=20 In the meantime, my humild opinion is that, although important, it's not = something that P2PSIP group should worry about at the moment. I mean it's= a more general problem related to data connections and that is shared by= all the IP-based applications in the mobile phone, not only a P2PSIP cli= ent.=20 Best regards,=20 Curro Dom=EDnguez -----Mensaje original----- De: David Barrett [mailto:dbarrett@quinthar.com] Enviado el: viernes, 29 = de junio de 2007 9:02 Para: 'Dean Willis' CC: p2psip@ietf.org Asunto: RE: [P2PSIP] do we need a client protocol? > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Subject: Re: [P2PSIP] do we need a client protocol? >=20 > > None of this has anything to do with SIP. Unless I'm=20 > > misunderstanding it, it's just not possible for a battery-conscious=20= > > device to continuously listen on an IP network at this point. What=20= > > am I missing? >=20 > Details, mostly. Missing details. It's an ugly world out there, and=20 > much of what we imagine to be the Internet isn't what we imagine it to=20= > be. Good, thanks for those details. So: - Some mobile applications listen for a 'page' to fire up the IP stack - Some PDAs can go 4-6 hours in IP "listen" mode. - Many mobile IP devices have no NAT/FW . But they might have them "further out" These details seem to largely reaffirm that IP-based applications general= ly can't spend a long time in "listen" mode without high battery drain, a= nd thus maybe it's a distraction to even spend energy discussing it in th= e context of P2PSIP. Until the whole IP network listen/battery-life thing has been worked out = in a more general fashion (ie, one that doesn't require layer 2 tricks be= tween the client and the network), it's probably premature to worry about= =2E Do you agree, or did I misunderstand your conclusion? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip Confidencialidad=20 Este correo electr=F3nico y, en su caso, cualquier fichero anexo al mismo= , contiene informaci=F3n de car=E1cter confidencial exclusivamente dirigi= da a su destinatario o destinatarios y propiedad de Vodafone Espa=F1a. Qu= eda prohibida su divulgaci=F3n, copia o distribuci=F3n a terceros sin la = previa autorizaci=F3n escrita de Vodafone Espa=F1a, en virtud de la legis= laci=F3n vigente. En el caso de haber recibido este correo electr=F3nico = por error, se ruega notificar inmediatamente esta circunstancia mediante = reenv=EDo a la direcci=F3n electr=F3nica del remitente y la destrucci=F3n= del mismo. Confidentiality=20 The information in this e-mail and in any attachments is classified as Vo= dafone Espa=F1a Confidential and Proprietary Information and solely for t= he attention and use of the named addressee(s). You are hereby notified t= hat any dissemination, distribution or copy of this communication is proh= ibited without the prior written consent of Vodafone Espa=F1a and is s st= rictly prohibited by law. If you have received this communication in erro= r, please, notify the sender by reply e-mail . _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 04:02:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BRC-00023M-IN; Fri, 29 Jun 2007 04:02:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BRA-000232-RT for p2psip@ietf.org; Fri, 29 Jun 2007 04:02:40 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4BRA-0006ol-9h for p2psip@ietf.org; Fri, 29 Jun 2007 04:02:40 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5T81tMY024763; Fri, 29 Jun 2007 11:02:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:02:19 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 11:02:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 11:04:58 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04A47438@esebe102.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace6EmM104qM95IuQwyLm4wViKLPNAABoZIgAAEqGwAAAMiAYAAAWkRQ References: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> From: To: , X-OriginalArrivalTime: 29 Jun 2007 08:02:19.0859 (UTC) FILETIME=[D1214A30:01C7BA23] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Curro, I agree with you that it is not our goal to solve battery problems = however we are going to design peer and client protocols and select a = DHT. In the design process we should consider battery limitations, in a = similar way as NAT traversal and security issues. It is much more = efficient to make educated choices at the begging of the design process = than put a lot of effort redesigning broken protocols. Marcin =20 >-----Original Message----- >From: ext p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org]=20 >Sent: 29 June, 2007 10:40 >To: David Barrett; Dean Willis >Cc: p2psip@ietf.org >Subject: RE: [P2PSIP] do we need a client protocol? > >=20 >Hi all,=20 > >I think most of you will find useful the details provided in=20 >this article > >http://blogs.msdn.com/windowsmobile/archive/2006/08/04/689069.aspx > >I've been researching some time about the impact that=20 >applications have on battery life, but I have to say there's=20 >no much information. (So I'd be willing to read the paper of=20 >Marcin's mates at Nokia).=20 > >In the meantime, my humild opinion is that, although=20 >important, it's not something that P2PSIP group should worry=20 >about at the moment. I mean it's a more general problem=20 >related to data connections and that is shared by all the=20 >IP-based applications in the mobile phone, not only a P2PSIP client.=20 > >Best regards,=20 > >Curro Dom=EDnguez > >-----Mensaje original----- >De: David Barrett [mailto:dbarrett@quinthar.com] Enviado el:=20 >viernes, 29 de junio de 2007 9:02 >Para: 'Dean Willis' >CC: p2psip@ietf.org >Asunto: RE: [P2PSIP] do we need a client protocol? > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Subject: Re: [P2PSIP] do we need a client protocol? >>=20 >> > None of this has anything to do with SIP. Unless I'm=20 >> > misunderstanding it, it's just not possible for a=20 >battery-conscious=20 >> > device to continuously listen on an IP network at this=20 >point. What=20 >> > am I missing? >>=20 >> Details, mostly. Missing details. It's an ugly world out there, and=20 >> much of what we imagine to be the Internet isn't what we=20 >imagine it to=20 >> be. > >Good, thanks for those details. So: > >- Some mobile applications listen for a 'page' to fire up the IP stack >- Some PDAs can go 4-6 hours in IP "listen" mode. >- Many mobile IP devices have no NAT/FW > . But they might have them "further out" > >These details seem to largely reaffirm that IP-based=20 >applications generally can't spend a long time in "listen"=20 >mode without high battery drain, and thus maybe it's a=20 >distraction to even spend energy discussing it in the context=20 >of P2PSIP. > >Until the whole IP network listen/battery-life thing has been=20 >worked out in a more general fashion (ie, one that doesn't=20 >require layer 2 tricks between the client and the network),=20 >it's probably premature to worry about. > >Do you agree, or did I misunderstand your conclusion? > >-david > > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip >Confidencialidad >Este correo electr=F3nico y, en su caso, cualquier fichero anexo=20 >al mismo, contiene informaci=F3n de car=E1cter confidencial=20 >exclusivamente dirigida a su destinatario o destinatarios y=20 >propiedad de Vodafone Espa=F1a. Queda prohibida su divulgaci=F3n,=20 >copia o distribuci=F3n a terceros sin la previa autorizaci=F3n=20 >escrita de Vodafone Espa=F1a, en virtud de la legislaci=F3n=20 >vigente. En el caso de haber recibido este correo electr=F3nico=20 >por error, se ruega notificar inmediatamente esta=20 >circunstancia mediante reenv=EDo a la direcci=F3n electr=F3nica del=20 >remitente y la destrucci=F3n del mismo. > >Confidentiality >The information in this e-mail and in any attachments is=20 >classified as Vodafone Espa=F1a Confidential and Proprietary=20 >Information and solely for the attention and use of the named=20 >addressee(s). You are hereby notified that any dissemination,=20 >distribution or copy of this communication is prohibited=20 >without the prior written consent of Vodafone Espa=F1a and is s=20 >strictly prohibited by law. If you have received this=20 >communication in error, please, notify the sender by reply e-mail . > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 04:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BYT-0000r4-Lx; Fri, 29 Jun 2007 04:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4BYS-0000oV-Ks for p2psip@ietf.org; Fri, 29 Jun 2007 04:10:12 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4BY5-0003IP-Rv for p2psip@ietf.org; Fri, 29 Jun 2007 04:10:12 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Fri, 29 Jun 2007 01:09:45 -0700 From: "David Barrett" To: "'Greger V. Teigre'" Subject: RE: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 01:09:44 -0700 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4684B5F6.4080604@teigre.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace6H/YpIhyyfho8ReKObFjiNTaX7AABLcQw X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a331e4a192f4d33f18e6f8376287cf6 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1154880721==" Errors-To: p2psip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1154880721== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C7B9EA.2E633D50" This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C7B9EA.2E633D50 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Ah, that's encouraging. Also, I completely ignored the possibility of a SIP phone that only makes outgoing calls - it seems that this is certainly possible. -david _____ From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Friday, June 29, 2007 12:34 AM To: David Barrett Cc: 'Dean Willis'; 'Wei Gengyu'; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Let me share some "running code" with you: Running SIP Express Router (http://iptel.org/) with OPTIONS ping from the server to a Nokia E70 every 30 seconds (as the E70 does not have any NAT traversal awareness, but it will respond 200 OK to the OPTIONS), the E70 will take you through a full work day (8+ hours), with a registration on WLAN (802.11g), as well as standard GSM on. Talk time about 1-1.5 hours. The WLAN access point is a standard <$100 device. The biggest problem has actually been the TCP/IP stack, where actually getting an IP address can be a problem. See http://www.iptel.org/config/nokia_e70 for more info. Add a Bluetooth headset to the mix and you got yourself less time, but it works surprisingly well... My experience is that an active 3G connection drains more battery than an active SIP registration with 30 sec pings over WLAN. I don't know mobile inner workings good enough to back that up, though... g-) David Barrett wrote: -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Subject: Re: [P2PSIP] do we need a client protocol? None of this has anything to do with SIP. Unless I'm misunderstanding it, it's just not possible for a battery-conscious device to continuously listen on an IP network at this point. What am I missing? Details, mostly. Missing details. It's an ugly world out there, and much of what we imagine to be the Internet isn't what we imagine it to be. Good, thanks for those details. So: - Some mobile applications listen for a 'page' to fire up the IP stack - Some PDAs can go 4-6 hours in IP "listen" mode. - Many mobile IP devices have no NAT/FW . But they might have them "further out" These details seem to largely reaffirm that IP-based applications generally can't spend a long time in "listen" mode without high battery drain, and thus maybe it's a distraction to even spend energy discussing it in the context of P2PSIP. Until the whole IP network listen/battery-life thing has been worked out in a more general fashion (ie, one that doesn't require layer 2 tricks between the client and the network), it's probably premature to worry about. Do you agree, or did I misunderstand your conclusion? -david ------=_NextPart_000_0026_01C7B9EA.2E633D50 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Ah, that’s encouraging.  = Also, I completely ignored the possibility of a SIP phone that only makes = outgoing calls – it seems that this is certainly = possible.

 

-david

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Friday, June 29, = 2007 12:34 AM
To: David Barrett
Cc: 'Dean Willis'; 'Wei = Gengyu'; p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a client protocol?

 

Let me share some "running code" = with you:
Running SIP Express Router (http://iptel.org/) with OPTIONS ping from the server to a Nokia E70 every 30 seconds (as = the E70 does not have any NAT traversal awareness, but it will respond 200 OK to = the OPTIONS), the E70 will take you through a full work day (8+ hours), with = a registration on WLAN (802.11g), as well as standard GSM on. Talk time = about 1-1.5 hours. The WLAN access point is a standard <$100 device.

The biggest problem has actually been the TCP/IP stack, where actually = getting an IP address can be a problem. See http://www.iptel.org/confi= g/nokia_e70 for more info.

Add a Bluetooth headset to the mix and you got yourself less time, but = it works surprisingly well...

My experience is that an active 3G connection drains more battery than = an active SIP registration with 30 sec pings over WLAN. I don't know mobile = inner workings good enough to back that up, though...
g-)

David Barrett wrote: 

-----Original =
Message-----
From: Dean Willis [mailto:dean.willis@softarmor.co=
m]
Subject: Re: [P2PSIP] do we need a client =
protocol?
 
    =

None of this has anything to do with =
SIP.  Unless I'm
misunderstanding it, it's just not possible =
for a battery-conscious
device to continuously listen on an IP =
network at this point.  =
What
am I =
missing?
      =

Details, mostly. Missing details. It's an =
ugly world out there, and
much of what we imagine to be the Internet =
isn't what we imagine it
to =
be.
    =

 
Good, thanks for those details.  =
So:
 
- Some mobile applications listen for a =
'page' to fire up the IP stack
- Some PDAs can go 4-6 hours in IP =
"listen" mode.
- Many mobile IP devices have no =
NAT/FW
       . But =
they might have them "further =
out"
 
These details seem to largely reaffirm that =
IP-based applications generally
can't spend a long time in "listen" =
mode without high battery drain, =
and
thus maybe it's a distraction to even spend =
energy discussing it in the
context of =
P2PSIP.
 
Until the whole IP network =
listen/battery-life thing has been worked out =
in
a more general fashion (ie, one that doesn't =
require layer 2 tricks between
the client and the network), it's probably =
premature to worry about.
 
Do you agree, or did I misunderstand your =
conclusion?
 
-david
 
 
 
------=_NextPart_000_0026_01C7B9EA.2E633D50-- --===============1154880721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1154880721==-- From p2psip-bounces@ietf.org Fri Jun 29 05:35:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Csf-0003NE-3n; Fri, 29 Jun 2007 05:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Csc-00031v-FX; Fri, 29 Jun 2007 05:35:06 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4CsX-0007jW-8O; Fri, 29 Jun 2007 05:35:06 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKE00JMD58VSG@szxga02-in.huawei.com>; Fri, 29 Jun 2007 17:34:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKE002PW58TUG@szxga02-in.huawei.com>; Fri, 29 Jun 2007 17:34:07 +0800 (CST) Received: from s64081 ([10.164.5.72]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKE00INK58P5Y@szxml04-in.huawei.com>; Fri, 29 Jun 2007 17:34:05 +0800 (CST) Date: Fri, 29 Jun 2007 17:34:01 +0800 From: songyongchao In-reply-to: <20070629062330.E8061DEDD7@mail.orgltd.com> To: simple@ietf.org Message-id: <007801c7ba30$a0d1a980$4805a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lA= X-Spam-Score: 0.2 (/) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 Cc: p2psip@ietf.org Subject: [P2PSIP] Do we need to introduce SIMPLE into P2P to realize presence and IM services? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0876426121==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0876426121== Content-type: multipart/alternative; boundary="Boundary_(ID_LrprPQ1/pARWGeglEUdl5w)" This is a multi-part message in MIME format. --Boundary_(ID_LrprPQ1/pARWGeglEUdl5w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi! In draft "draft-rosenberg-simple-simple-00", Jonathan Rosenberg wrote: >SIMPLE provides for both presence and IM capabilities. Though both of these fit underneath the broad SIMPLE umbrella, they are well separated from each other and are supported by different sets of specifications. >RFC 4662 [4] defines an extension to RFC 3265 that allows a client to subscribe to a list of resources using a single subscription. The server, called a Resource List Server (RLS) will "expand" the subscription and subscribe to each individual member of the list. Its primary usage with presence is to allow subscriptions to "buddy lists". Without RFC 4662, a UA would need to subscribe to each presentity individually. With RFC 4662, they can have a single subscription to all buddies. A user can manage the entries in their buddy list using the provisioning mechanisms in Section 2.4. I come up with the idea that do we need to introduce SIMPLE into P2P or P2PSIP to realize presence and IM services? If so, how do we equip peers with SIMPLE? And do we need the central servers like RLS as defined in RFC4662 to realize list subscription and notification in P2P? Because list subscription and notification for a buddy list get the user free from frequently sending single SUBSCRIBE and processing of single NOTIFY message. If we don't want to introduce the servers like RLS into P2P, how can we distribute list subscription and notification method in P2P? Because P2P is very different fro C/S, there are a lot of questions to be discussed. --Boundary_(ID_LrprPQ1/pARWGeglEUdl5w) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi!

In draft “draft-rosenberg-simple-simple-00”, Jonathan Rosenberg wrote:

  

>SIMPLE provides for both presence and IM capabilities.  Though both

   of these fit underneath the broad SIMPLE umbrella, they are well

   separated from each other and are supported by different sets of

   specifications.

 

>RFC 4662 [4] defines an extension

      to RFC 3265 that allows a client to subscribe to a list of

      resources using a single subscription.  The server, called a

      Resource List Server (RLS) will "expand" the subscription and

      subscribe to each individual member of the list.  Its primary

      usage with presence is to allow subscriptions to "buddy lists".

      Without RFC 4662, a UA would need to subscribe to each presentity

      individually.  With RFC 4662, they can have a single subscription

      to all buddies.  A user can manage the entries in their buddy list

      using the provisioning mechanisms in Section 2.4.

 

 

I come up with the idea that do we need to introduce SIMPLE into P2P or P2PSIP

to realize presence and IM services?

If so, how do we equip peers with SIMPLE?

And do we need the central servers like RLS as defined in RFC4662

 to realize list subscription and notification in P2P?

 Because list subscription and notification for a buddy list get the user free from

 frequently sending single SUBSCRIBE and processing of single NOTIFY message.

If we don’t want to introduce the servers like RLS into P2P, how can we distribute

list subscription and notification method in P2P?

 

Because P2P is very different fro C/S, there are a lot of questions to be discussed.

--Boundary_(ID_LrprPQ1/pARWGeglEUdl5w)-- --===============0876426121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0876426121==-- From p2psip-bounces@ietf.org Fri Jun 29 06:17:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DXM-00057Z-AA; Fri, 29 Jun 2007 06:17:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DXL-00057I-6w for p2psip@ietf.org; Fri, 29 Jun 2007 06:17:11 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4DWV-0003iQ-Fu for p2psip@ietf.org; Fri, 29 Jun 2007 06:17:11 -0400 Received: (qmail 20876 invoked for bounce); 29 Jun 2007 12:18:30 -0000 Received: from unknown (HELO ?130.79.90.87?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 29 Jun 2007 12:18:30 -0000 Message-ID: <4684DBF1.4000203@sip-communicator.org> Date: Fri, 29 Jun 2007 12:16:17 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean Willis wrote: > No, the inbound rule looks like "DISCARD UDP ANY ANY" unless a prior > rule allowed DNS through to the DNS server. > > They weren't singling out "media" traffic. They were just using a > large blunt object to club all UDP traffic into submission And according to you what were they trying to achieve? I guess I did not express myself clearly. My point is that if someone does not want or does not care about UDP traffic, it's most probably because they don't want or do not care about real-time traffic. We should not try to find ways of circumventing firewall policies and cheat firewall administrators (... we couldn't do that reliably even if we wanted to). Almost all NATs/firewalls previewed for residential use allow responses to UDP traffic started from inside their network and therefore allow for hole punching. Enterprise firewalls on the other hand are strictly configured to comply with a predefined policy and it is not our business to care what protocols these policies include. The reasoning that we had while working on XPP was that it should work as easily and in as many network configurations as possible. That's why we chose UDP and we still believe it is the right way to go as it would greatly facilitate implementation and deployment. We are currently building a public overlay using SIPDHT2 (our current draft implementation available on http://sipdht.sourceforge.net/sipdht2/index.html). We should have it ready in a month and a couple of months later we should also have support inside SIP Communicator and thus a fully functional p2p real-time communications environment. We'll publish results as soon as we have them, but so far the situation is quite promising just as it is (using UDP). Still, it is most certainly up to the working group to make the decision and if there is consensus on using TCP (rather than UDP) and a MUST for ICE usage is a reasonable requirement to impose on implementors (rather than a SHOULD), then we would try to come up with a revised version that uses TCP as a transport. Cheers Emil >, because > there's no good way to tell whether a node inside the firewall wants/ > needs to receive arbitrary UDP traffic right now. > > This is a VERY common firewall policy for enterprises basing the > firewalls on conventional router ACLs, Linux iptables, Cisco firewall > feature set, and so on. > > And yes, I installed a large number of enterprise firewalls that did > exactly this back when I was doing that for a living. > >>> On the other hand, Skype worked just fine from behind that same >>> firewall. >> Are you certain that the reason for this was protocol related. >> Isn't it likely that this was either intentional or the firewall >> was not advanced enough and was not analyzing traffic any further >> beyond transport and port. In either case I doubt the phenomenon is >> something that TCP would always be a solution for. > > Huh? > > Yeah, it was protocol related. The firewall effectively blocked all > UDP, and allowed TCP only when the connection was established from > within the firewall. Again, this is pretty much standard for > companies that don't restrict things further by only allowing HTTP > traffic using an HTTP proxy in their firewall, and otherwise also > blocking TCP. That's why applications that REALLY work through > firewalls can do things like tunnel media over HTTP requests. > > As to whether this means the "firewall was not advanced enough", I > suppose that's open to interpretation. But this IS what most > enterprise firewalls do, and it was at a company that makes a large > share of the enterprise firewalls in use today (so they ought to > know) . . . and they're still using it now as far as I know. > > -- > Dean > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 09:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4GOG-0008IK-OV; Fri, 29 Jun 2007 09:20:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4GOF-0008Hj-DP for p2psip@ietf.org; Fri, 29 Jun 2007 09:19:59 -0400 Received: from [140.115.52.198] (helo=acnlab.csie.ncu.edu.tw) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I4GOE-0001h7-AG for p2psip@ietf.org; Fri, 29 Jun 2007 09:19:59 -0400 Received: from [140.115.52.194](140.115.52.194) by acnlab.csie.ncu.edu.tw with CMailServer 5.0 SMTP; Fri, 29 Jun 2007 21:19:13 +0800 Message-ID: <468506DB.3010308@acnlab.csie.ncu.edu.tw> Date: Fri, 29 Jun 2007 21:19:23 +0800 From: ACNLab User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: p2psip@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: e654cfa5e44bd623be3eb2c720858b05 Subject: [P2PSIP] Call for Papers -- P2PNVE 2007 (Submission deadline is approaching) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0978288253==" Errors-To: p2psip-bounces@ietf.org --===============0978288253== Content-Type: text/html; charset=big5 Content-Transfer-Encoding: 8bit This is to remind you that the paper submission deadline (July 10, 2007) of the International Workshop on Peer-to-Peer Network Virtual Environments 2007 (P2P-NVE 2007) is ten days away. Hope that you can submit your paper early and please note that the topics of interest have been extended to include the following items:

 

*Peer-to-Peer systems and infrastructures

*Applications of Peer-to-Peer systems

*Performance evaluation of Peer-to-Peer systems

*Trust and security issues in Peer-to-Peer systems

*Network support for Peer-to-Peer systems

*Fault tolerance in Peer-to-Peer systems

*Efficient Peer-to-Peer resource lookup

*Distributed hash tables (DHT) and related issues

*All aspects related to Peer-to-Peer content, bandwidth, storage and computation power sharing

 

================ CALL FOR PAPERS ================

P2P-NVE 2007

International Workshop on Peer-to-Peer Network Virtual Environments 2007

in conjunction with

The 13th International Conference on Parallel and Distributed Systems (ICPADS 2007)

December 5 -7, 2007

National Tsing Hua University, Hsinchu, Taiwan, R.O.C.

http://acnlab.csie.ncu.edu.tw/P2PNVE2007.

=================================================

About P2P-NVE 2007

The rapid growth and popularity of networked virtual environments (NVEs) such as Massively Multiplayer Online Games (MMOGs) in recent years have spawned a series of research interests in constructing such large-scale virtual environments. For increasing scalability and decreasing the cost of management and deployment, more and more studies propose using peer-to-peer (P2P) architectures to construct large-scale NVEs for games, multimedia virtual worlds and other applications. The goal of such research is to support an Earth-scale virtual environment or to make hosting virtual worlds more affordable than existing client-server approaches. However, existing solutions for consistency control, persistent data storage, multimedia data dissemination, and cheat-prevention may not be straightforwardly adapted to such new environments, novel ideas and designs thus are needed to realize the potential of P2P-based NVEs.

 

The theme of this workshop is to solicit original and previously unpublished new ideas on the construction and realization of P2P-based NVEs, with a focus to facilitate discussions and idea exchanges by both academics and practitioners. All papers accepted for the workshop will be included in the IEEE Xplore Digital Library and will be included in the proceedings published by the IEEE Computer Society.

 

Topics of interest include, but are not limited to:

 

* Constructions of P2P overlays for NVEs

* Multicast for P2P NVEs

* P2P NVE content distribution

* 3D streaming for P2P NVEs

* Voice communication on P2P NVEs

* Persistent storage for P2P NVEs

* Security and cheat-prevention mechanisms for P2P games

* Data structures and queries for P2P NVEs

* Consistency control for P2P NVEs

* Design considerations for P2P NVEs

* P2P NVE applications on mobile devices

* Prototype P2P virtual environment systems

 

Important Dates

 

Paper Submission:          July 10, 2007

Author Notification:          August 10, 2007

Camera Ready Copy Due:    September 2, 2007

 

Paper Submission

Authors are invited to submit an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to web site http://acnlab.csie.ncu.edu.tw/P2PNVE2007. Submitted papers should be in be in PDF format in accordance with IEEE Computer Society guidelines (ftp://pubftp.computer.org/press/outgoing/proceedings). All submitted papers will be refereed by reviewers in terms of originality, contribution, correctness, and presentation.

 

--===============0978288253== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0978288253==-- From p2psip-bounces@ietf.org Fri Jun 29 11:16:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ID2-0002rr-QS; Fri, 29 Jun 2007 11:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ID1-0002qW-JA for p2psip@ietf.org; Fri, 29 Jun 2007 11:16:31 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4ICb-0005aX-41 for p2psip@ietf.org; Fri, 29 Jun 2007 11:16:31 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I4ICU-00012x-Tw; Fri, 29 Jun 2007 10:15:59 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <92489DF0-AE49-49C7-872D-D378819E9410@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 10:07:20 -0500 To: David Barrett X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 29, 2007, at 2:02 AM, David Barrett wrote: > > Until the whole IP network listen/battery-life thing has been > worked out in > a more general fashion (ie, one that doesn't require layer 2 tricks > between > the client and the network), it's probably premature to worry about. > > Do you agree, or did I misunderstand your conclusion? Well, let's put it another way. A lot of folks are putting a whole lot of money into IP applications running on mobile devices, and into mobile devices designed to run IP applications. I was playing with a SIP client on my Nokia 770 last night, and it's already been obsoleted by the new 800. Folks are also putting a lot of money into better 802.11 chipsets, but we can't expect a "magic bullet" on that front that will turn a PDA into a data-center-class server. So the reality is, we're going to have a whole lot of boxes running in mobile configurations, and these boxes are not going to have all the capabilities of server-class machines, and that's just the way it is going to be for quite a long time. Now, do you want to pay attention to half the nodes on the Internet, or not? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 11:28:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4IO9-0004Tn-3E; Fri, 29 Jun 2007 11:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4IO8-0004Th-22 for p2psip@ietf.org; Fri, 29 Jun 2007 11:28:00 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4INk-0000To-3A for p2psip@ietf.org; Fri, 29 Jun 2007 11:28:00 -0400 Received: from [65.65.155.30] (helo=[192.168.1.3]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I4INj-000148-85; Fri, 29 Jun 2007 10:27:35 -0500 In-Reply-To: <4684DBF1.4000203@sip-communicator.org> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> <4684DBF1.4000203@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EC20206-306D-4E5F-BA1C-BC26919F5FEB@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Fri, 29 Jun 2007 10:27:27 -0500 To: Emil Ivov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 29, 2007, at 5:16 AM, Emil Ivov wrote: > > > Dean Willis wrote: >> No, the inbound rule looks like "DISCARD UDP ANY ANY" unless a >> prior rule allowed DNS through to the DNS server. >> They weren't singling out "media" traffic. They were just using >> a large blunt object to club all UDP traffic into submission > > And according to you what were they trying to achieve? A reasonable level of security. > I guess I did not express myself clearly. My point is that if > someone does not want or does not care about UDP traffic, it's most > probably because they don't want or do not care about real-time > traffic. We should not try to find ways of circumventing firewall > policies and cheat firewall administrators (... we couldn't do that > reliably even if we wanted to). It wasn't that they didn't want real-time traffic. It is a matter of simple expedience -- since UDP traffic is hard to manage, it gets blocked. If we could have come up with a reasonable way to allow RTP only when a node inside the network was expecting it, we'd have made that work. And no, coupling a SIP proxy to the firewall via a control protocol is NOT a reasonable solution in a large enterprise. > Almost all NATs/firewalls previewed for residential use allow > responses to UDP traffic started from inside their network and > therefore allow for hole punching. > True. It's a question of reach. Are you happy having only residential users? If you're happy, I'm happy for you. If that doesn't make you happy, then you might want to think about how to get to enterprise users, keeping in mind that their security people aren't evil -- just conservative, lazy, and using technology that might not be what you want them to use. -- dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 12:02:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4IvB-0004TU-8f; Fri, 29 Jun 2007 12:02:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Iv9-0004Os-Tr for p2psip@ietf.org; Fri, 29 Jun 2007 12:02:07 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4Iu7-0001mF-IM for p2psip@ietf.org; Fri, 29 Jun 2007 12:02:07 -0400 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Fri, 29 Jun 2007 08:59:57 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l5TFwkot029014; Fri, 29 Jun 2007 08:58:46 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l5TFxm0g027087; Fri, 29 Jun 2007 08:59:50 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 08:59:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 08:58:52 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A266A6@namail5.corp.adobe.com> In-Reply-To: <92489DF0-AE49-49C7-872D-D378819E9410@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace6YIV6bybOXvfbTvKsi0PkfkO61wABVZ2w References: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> <92489DF0-AE49-49C7-872D-D378819E9410@softarmor.com> From: "Henry Sinnreich" To: "Dean Willis" , "David Barrett" X-OriginalArrivalTime: 29 Jun 2007 15:59:48.0264 (UTC) FILETIME=[84E8FA80:01C7BA66] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org To bring the discussion back to the peer and client protocols, here is what the SIP-DHT interface has to support for the peer protocol (courtesy Salman Baset): * Join * Leave * Lookup * Publish * Remove And here what the client protocol would need to support IMHO, for those who want to use the client protocol: * Lookup * Publish * Remove Thanks, Henry -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, June 29, 2007 8:07 AM To: David Barrett Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? On Jun 29, 2007, at 2:02 AM, David Barrett wrote: > > Until the whole IP network listen/battery-life thing has been =20 > worked out in > a more general fashion (ie, one that doesn't require layer 2 tricks =20 > between > the client and the network), it's probably premature to worry about. > > Do you agree, or did I misunderstand your conclusion? Well, let's put it another way. A lot of folks are putting a whole lot of money into IP applications =20 running on mobile devices, and into mobile devices designed to run IP =20 applications. I was playing with a SIP client on my Nokia 770 last =20 night, and it's already been obsoleted by the new 800. Folks are also putting a lot of money into better 802.11 chipsets, =20 but we can't expect a "magic bullet" on that front that will turn a =20 PDA into a data-center-class server. So the reality is, we're going to have a whole lot of boxes running =20 in mobile configurations, and these boxes are not going to have all =20 the capabilities of server-class machines, and that's just the way it =20 is going to be for quite a long time. Now, do you want to pay attention to half the nodes on the Internet, =20 or not? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 12:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JgO-0003fn-Us; Fri, 29 Jun 2007 12:50:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4JgN-0003et-46 for p2psip@ietf.org; Fri, 29 Jun 2007 12:50:55 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Jg7-000052-T0 for p2psip@ietf.org; Fri, 29 Jun 2007 12:50:55 -0400 Received: from 74-51-33-189.telnetcommunications.com ([74.51.33.189]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I4Jg6-0003vq-1K; Fri, 29 Jun 2007 12:50:39 -0400 In-Reply-To: <3F18E76823C95E4795181D74BAC7664F04A47438@esebe102.NOE.Nokia.com> References: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> <3F18E76823C95E4795181D74BAC7664F04A47438@esebe102.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D011D60-6107-473F-A1D4-9DE118C0D8D6@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 12:10:15 -0400 To: X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - 74-51-33-189.telnetcommunications.com [74.51.33.189] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 29-Jun-07, at 04:04 , wrote: > > In the design process we should consider battery limitations, in a > similar way as NAT traversal and security issues. I am not against this idea, but I do have a concern. There has been quite a bit of work elsewhere in the IETF in NAT traversal and security. There are a number of basic tools available, and the group is mostly adapting tools developed in other groups to the P2PSIP context. There are also a number of people active in P2PSIP who are familiar with these tools. I am not sure the same can be said for battery limitations. Is there a working group somewhere which is studying the general problem of running IP on devices with battery limitations? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 13:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Khw-0004tN-5U; Fri, 29 Jun 2007 13:56:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4DdY-0002t7-Db; Fri, 29 Jun 2007 06:23:36 -0400 Received: from [125.21.188.69] (helo=mail.orgltd.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Dcf-0005Rj-Bm; Fri, 29 Jun 2007 06:23:36 -0400 Received: from orgvikas (unknown [219.91.223.66]) by mail.orgltd.com (Postfix) with ESMTP id 9153FDED81; Fri, 29 Jun 2007 14:59:28 +0530 (IST) From: "Vikas Tandon" To: "'songyongchao'" , Date: Fri, 29 Jun 2007 15:52:08 +0530 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4A== In-Reply-To: <007801c7ba30$a0d1a980$4805a40a@china.huawei.com> Message-Id: <20070629092928.9153FDED81@mail.orgltd.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a7d7b1ff9fdb39b8762b25bc5367e56 X-Mailman-Approved-At: Fri, 29 Jun 2007 13:56:34 -0400 Cc: p2psip@ietf.org Subject: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P to realize presence and IM services? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0496251704==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0496251704== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B4_01C7BA65.7E177C00" This is a multi-part message in MIME format. ------=_NextPart_000_00B4_01C7BA65.7E177C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Songyongchao, I'm not sure how well this goes with the SIMPLE concepts. However doing P2P will increase the traffic between the peers since every presence update needs to be sent to every buddy in the buddylist which is heavy on the mobile devices and networks. Also P2P will not help in having other services utilize presence information. Would be interesting to know more from other experts on the list. Regards, Vikas Tandon From: songyongchao [mailto:melodysong@huawei.com] Sent: Friday, June 29, 2007 3:04 PM To: simple@ietf.org Cc: p2psip@ietf.org Subject: [Simple] Do we need to introduce SIMPLE into P2P to realize presence and IM services? Hi! In draft "draft-rosenberg-simple-simple-00", Jonathan Rosenberg wrote: >SIMPLE provides for both presence and IM capabilities. Though both of these fit underneath the broad SIMPLE umbrella, they are well separated from each other and are supported by different sets of specifications. >RFC 4662 [4] defines an extension to RFC 3265 that allows a client to subscribe to a list of resources using a single subscription. The server, called a Resource List Server (RLS) will "expand" the subscription and subscribe to each individual member of the list. Its primary usage with presence is to allow subscriptions to "buddy lists". Without RFC 4662, a UA would need to subscribe to each presentity individually. With RFC 4662, they can have a single subscription to all buddies. A user can manage the entries in their buddy list using the provisioning mechanisms in Section 2.4. I come up with the idea that do we need to introduce SIMPLE into P2P or P2PSIP to realize presence and IM services? If so, how do we equip peers with SIMPLE? And do we need the central servers like RLS as defined in RFC4662 to realize list subscription and notification in P2P? Because list subscription and notification for a buddy list get the user free from frequently sending single SUBSCRIBE and processing of single NOTIFY message. If we don't want to introduce the servers like RLS into P2P, how can we distribute list subscription and notification method in P2P? Because P2P is very different fro C/S, there are a lot of questions to be discussed. ------=_NextPart_000_00B4_01C7BA65.7E177C00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Songyongchao,
 
I'm not sure how well this goes with the SIMPLE = concepts.=20 However doing P2P will increase the traffic between the peers since = every=20 presence update needs to be sent to every buddy in the buddylist which = is heavy=20 on the mobile devices and networks. Also P2P will not help in having = other=20 services utilize presence information.
 
Would be interesting to know more from other = experts on the=20 list.
 
Regards,
Vikas = Tandon

 
From: songyongchao [mailto:melodysong@huawei.com] =
Sent:=20 Friday, June 29, 2007 3:04 PM
To: = simple@ietf.org
Cc:=20 p2psip@ietf.org
Subject: [Simple] Do we need to introduce = SIMPLE into=20 P2P to realize presence and IM services?

Hi!

In draft=20 “draft-rosenberg-simple-simple-00”, Jonathan Rosenberg=20 wrote:

  =20

>SIMPLE = provides for=20 both presence and IM capabilities.  Though=20 both

   = of these=20 fit underneath the broad SIMPLE umbrella, they are=20 well

   = separated=20 from each other and are supported by different sets=20 of

  =20 specifications.

 

>RFC 4662 = [4] defines=20 an extension

     =20 to RFC 3265 that allows a client to subscribe to a list=20 of

     =20 resources using a single subscription.  The server, called=20 a

     =20 Resource List Server (RLS) will "expand" the subscription=20 and

     =20 subscribe to each individual member of the list.  Its=20 primary

     =20 usage with presence is to allow subscriptions to "buddy=20 lists".

     =20 Without RFC 4662, a UA would need to subscribe to each=20 presentity

     =20 individually.  With RFC 4662, they can have a single=20 subscription

     =20 to all buddies.  A user can manage the entries in their buddy=20 list

     =20 using the provisioning mechanisms in Section = 2.4.

 

 

I come up with = the idea=20 that do we need to introduce SIMPLE into P2P or=20 P2PSIP

to realize = presence and=20 IM services?

If so, how do = we equip=20 peers with SIMPLE?

And do we need = the=20 central servers like RLS as defined in = RFC4662

 to = realize list=20 subscription and notification in P2P?

 Because = list=20 subscription and notification for a buddy list get the user free=20 from

 frequently sending=20 single SUBSCRIBE and processing of single NOTIFY=20 message.

If we = don’t want to=20 introduce the servers like RLS into P2P, how can we=20 distribute

list = subscription and=20 notification method in P2P?

 

Because P2P is = very=20 different fro C/S, there are a lot of questions to be discussed.=20

------=_NextPart_000_00B4_01C7BA65.7E177C00-- --===============0496251704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0496251704==-- From p2psip-bounces@ietf.org Fri Jun 29 14:01:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Kmj-0006wU-IF; Fri, 29 Jun 2007 14:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Kmh-0006d0-MI for p2psip@ietf.org; Fri, 29 Jun 2007 14:01:31 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4Km6-0007Nb-EO for p2psip@ietf.org; Fri, 29 Jun 2007 14:01:31 -0400 Received: by py-out-1112.google.com with SMTP id f31so2337044pyh for ; Fri, 29 Jun 2007 11:00:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mWqiWd4+X7RFIU1Zcdh/2Yw6Ku5mzeOUJRF5bkBZd80vTAC77KcuNVWu6qJnBwXy/SIU8VBbzGV6u71gUzRx5H2C2z3JJA60b+rGW/BK7bEVUW0ZyggoeuC6wnxDeOSECtYZ/8AoqljGx6g51FUFPA6CJb+vVnes4QC9h/3ovrI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mxsrZ/vpXqdGETpfeA/tm73RWMbbcvil7dtgxignkGrLfrahoxdfiU1AxAP5GgTpLDPmCAgPLtbx6UUr9CrCWJsDHiDXN6sN2nQH/KnC2X5oMoThBVzhI1ujop4uEb/7KmHwUBJ6GEWyV4CqJeJF9WUxXeQp/zJaB7ne4b9kChA= Received: by 10.65.114.11 with SMTP id r11mr3478377qbm.1183140053106; Fri, 29 Jun 2007 11:00:53 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Fri, 29 Jun 2007 11:00:53 -0700 (PDT) Message-ID: <4d4304a00706291100gfe6b12exe17e95b924ce7a81@mail.gmail.com> Date: Fri, 29 Jun 2007 14:00:53 -0400 From: "David A. Bryan" To: ACNLab Subject: Re: [P2PSIP] Call for Papers -- P2PNVE 2007 (Submission deadline is approaching) In-Reply-To: <468506DB.3010308@acnlab.csie.ncu.edu.tw> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <468506DB.3010308@acnlab.csie.ncu.edu.tw> X-Google-Sender-Auth: 16815ff16fa8909e X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org A reminder to the list... Postings of conferences are only allowed if they are SPECIFICALLY related to P2PSIP. Please do not post announcements for general P2P conferences. The group is about work on the P2PSIP protocol, and there have been some complaints about too many calls for papers that are about P2P in general. David On 6/29/07, ACNLab wrote: > > This is to remind you that the paper submission deadline (July 10, 2007) of > the International Workshop on Peer-to-Peer Network Virtual Environments 2007 > (P2P-NVE 2007) is ten days away. Hope that you can submit your paper early > and please note that the topics of interest have been extended to include > the following items: > > > > > *Peer-to-Peer systems and infrastructures > > *Applications of Peer-to-Peer systems > > *Performance evaluation of Peer-to-Peer systems > > *Trust and security issues in Peer-to-Peer systems > > *Network support for Peer-to-Peer systems > > *Fault tolerance in Peer-to-Peer systems > > *Efficient Peer-to-Peer resource lookup > > *Distributed hash tables (DHT) and related issues > > *All aspects related to Peer-to-Peer content, bandwidth, storage and > computation power sharing > > > > ================ CALL FOR PAPERS ================ > > P2P-NVE 2007 > > International Workshop on Peer-to-Peer Network Virtual Environments 2007 > > in conjunction with > > The 13th International Conference on Parallel and Distributed Systems > (ICPADS 2007) > > December 5 -7, 2007 > > National Tsing Hua University, Hsinchu, Taiwan, R.O.C. > > http://acnlab.csie.ncu.edu.tw/P2PNVE2007. > > ================================================= > > About P2P-NVE 2007 > > The rapid growth and popularity of networked virtual environments (NVEs) > such as Massively Multiplayer Online Games (MMOGs) in recent years have > spawned a series of research interests in constructing such large-scale > virtual environments. For increasing scalability and decreasing the cost of > management and deployment, more and more studies propose using peer-to-peer > (P2P) architectures to construct large-scale NVEs for games, multimedia > virtual worlds and other applications. The goal of such research is to > support an Earth-scale virtual environment or to make hosting virtual worlds > more affordable than existing client-server approaches. However, existing > solutions for consistency control, persistent data storage, multimedia data > dissemination, and cheat-prevention may not be straightforwardly adapted to > such new environments, novel ideas and designs thus are needed to realize > the potential of P2P-based NVEs. > > > > The theme of this workshop is to solicit original and previously unpublished > new ideas on the construction and realization of P2P-based NVEs, with a > focus to facilitate discussions and idea exchanges by both academics and > practitioners. All papers accepted for the workshop will be included in the > IEEE Xplore Digital Library and will be included in the proceedings > published by the IEEE Computer Society. > > > > Topics of interest include, but are not limited to: > > > > * Constructions of P2P overlays for NVEs > > * Multicast for P2P NVEs > > * P2P NVE content distribution > > * 3D streaming for P2P NVEs > > * Voice communication on P2P NVEs > > * Persistent storage for P2P NVEs > > * Security and cheat-prevention mechanisms for P2P games > > * Data structures and queries for P2P NVEs > > * Consistency control for P2P NVEs > > * Design considerations for P2P NVEs > > * P2P NVE applications on mobile devices > > * Prototype P2P virtual environment systems > > > > Important Dates > > > > Paper Submission: July 10, 2007 > > Author Notification: August 10, 2007 > > Camera Ready Copy Due: September 2, 2007 > > > > Paper Submission > > Authors are invited to submit an electronic version of original, unpublished > manuscripts, not to exceed 8 double-columned, single-spaced pages, to web > site http://acnlab.csie.ncu.edu.tw/P2PNVE2007. Submitted > papers should be in be in PDF format in accordance with IEEE Computer > Society guidelines > (ftp://pubftp.computer.org/press/outgoing/proceedings). All > submitted papers will be refereed by reviewers in terms of originality, > contribution, correctness, and presentation. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 19:32:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4PwY-0005G6-H6; Fri, 29 Jun 2007 19:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4PwW-00052q-9v for p2psip@ietf.org; Fri, 29 Jun 2007 19:32:00 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4PwJ-00059L-CJ for p2psip@ietf.org; Fri, 29 Jun 2007 19:32:00 -0400 Received: (qmail 28124 invoked for bounce); 30 Jun 2007 01:33:57 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 30 Jun 2007 01:33:57 -0000 Message-ID: <46859661.3040300@sip-communicator.org> Date: Sat, 30 Jun 2007 01:31:45 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: P2PSIP Mailing List Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> <4684DBF1.4000203@sip-communicator.org> <0EC20206-306D-4E5F-BA1C-BC26919F5FEB@softarmor.com> In-Reply-To: <0EC20206-306D-4E5F-BA1C-BC26919F5FEB@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean Willis wrote: > On Jun 29, 2007, at 5:16 AM, Emil Ivov wrote: > >> >> Dean Willis wrote: >>> No, the inbound rule looks like "DISCARD UDP ANY ANY" unless a >>> prior rule allowed DNS through to the DNS server. They weren't >>> singling out "media" traffic. They were just using a large >>> blunt object to club all UDP traffic into submission >> And according to you what were they trying to achieve? > > A reasonable level of security. I am not so convinced since I don't see how allowing tcp connections is more secure than having UDP with address and port dependent filtering (which is what conntrack in iptables is doing for example). Can you please give us some references or describe the risks that this may be causing? I'd be more inclined to think that most of the enterprises unconditionally blocking UDP, do so in order to prevent their employees from using Internet access for purposes, not directly related to their work. Most such enterprises also tend to block all traffic other than http/https. >> I guess I did not express myself clearly. My point is that if >> someone does not want or does not care about UDP traffic, it's most >> probably because they don't want or do not care about real-time >> traffic. We should not try to find ways of circumventing firewall >> policies and cheat firewall administrators (... we couldn't do >> that reliably even if we wanted to). > > It wasn't that they didn't want real-time traffic. It is a matter of > simple expedience -- since UDP traffic is hard to manage, it gets > blocked. Implementing address and port specific filtering for UDP in a firewall is only slightly different from keeping track of TCP connections. As far as I know most firewall management interfaces allow users to do it. > If we could have come up with a reasonable way to allow RTP only when > a node inside the network was expecting it, we'd have made that work. > And no, coupling a SIP proxy to the firewall via a control protocol > is NOT a reasonable solution in a large enterprise. You really lost me here. Why is this a problem? And why do you need to have a SIP proxy on the firewall to do it? You can do this for UDP just as easily as you could for TCP. If this would help convince you, you might want to have a look at the following iptables example: iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT >> Almost all NATs/firewalls previewed for residential use allow >> responses to UDP traffic started from inside their network and >> therefore allow for hole punching. >> > True. It's a question of reach. Are you happy having only residential > users? If you're happy, I'm happy for you. > > If that doesn't make you happy, then you might want to think about > how to get to enterprise users, keeping in mind that their security > people aren't evil -- just conservative, lazy, and using technology > that might not be what you want them to use. Well even though I'd really like all enterprises in the world to contribute to our overlay, I know that I can spend the whole weekend thinking about it and I still won't be able to figure how to standardize a protocol in a way that would allow me to get enterprise users if they don't want me to get them. (Unless of course standardization includes physical intervention and violation of human rights :) ). Emil > > -- dean > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jun 29 20:52:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4RCn-0004KW-Cp; Fri, 29 Jun 2007 20:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4RCm-0004KL-BY for p2psip@ietf.org; Fri, 29 Jun 2007 20:52:52 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4RCW-0006YI-Ep for p2psip@ietf.org; Fri, 29 Jun 2007 20:52:52 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Fri, 29 Jun 2007 17:52:30 -0700 From: "David Barrett" To: "'Dean Willis'" Subject: RE: [P2PSIP] do we need a client protocol? Date: Fri, 29 Jun 2007 17:52:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <92489DF0-AE49-49C7-872D-D378819E9410@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace6YHESf12AKm++SP6I1baSAXefKwATbNUw X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Subject: Re: [P2PSIP] do we need a client protocol? > > Now, do you want to pay attention to half the nodes on the Internet, > or not? Heh, if half the nodes on the internet actually were mobile devices, maybe I'd agree. But in the real world, that number is far smaller. We're finding it hard enough to make P2PSIP relevant on the internet nodes that *do* exist, so let's stay focused on reality. Once we have proven P2PSIP actually works for real-world users on the real-world internet, then let's worry about possible future internets. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jun 30 00:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ULB-0002pG-Dq; Sat, 30 Jun 2007 00:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4ULA-0002pB-Al for p2psip@ietf.org; Sat, 30 Jun 2007 00:13:44 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4UL1-0005Iu-2k for p2psip@ietf.org; Sat, 30 Jun 2007 00:13:44 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKF00ER9L2MYW@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 29 Jun 2007 21:13:34 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKF006YSL2KHK@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 29 Jun 2007 21:13:34 -0700 (PDT) Received: from [172.24.1.24] (Forwarded-For: [10.164.5.123]) by szxmc04-in.huawei.com (mshttpd); Sat, 30 Jun 2007 12:13:32 +0800 Date: Sat, 30 Jun 2007 12:13:32 +0800 From: zongning 63316 Subject: =?gb2312?B?u9i4tA==?=:[P2PSIP] Call for Papers -- P2PNVE 2007 (Submission deadline is approaching) In-reply-to: <468506DB.3010308@acnlab.csie.ncu.edu.tw> To: peakli@huawei.com, hwllj@huawei.com Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: multipart/mixed; boundary="Boundary_(ID_MdKS5/pVqLghfuESIVvrzA)" Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal References: <468506DB.3010308@acnlab.csie.ncu.edu.tw> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_MdKS5/pVqLghfuESIVvrzA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline *********************************************************************= ********************* This email and its attachments contain confidential information from= HUAWEI, which is intended only for the person or entity whose addres= s is listed above. Any use of the information contained herein in any= way (including, but not limited to, total or partial disclosure, rep= roduction, or dissemination) by persons other than the intended recip= ient(s) is prohibited. If you receive this e-mail in error, please no= tify the sender by phone or em ail immediately and delete it! ********************************************************************= ********************* --Boundary_(ID_MdKS5/pVqLghfuESIVvrzA) Content-type: text/html; charset=big5 Content-transfer-encoding: QUOTED-PRINTABLE This is to remind you that the paper submission deadline (July 10, 2007) of the International Workshop on Peer-to-Pee= r Network Virtual Environments 2007 (P2P-NVE 2007) is ten days away. Hope that you can submit your paper early and please note that the topics of interest have bee= n extended to include the following items:

 

*Peer-to-Peer systems and infrastructures

*Applications of Peer-to-Pe= er systems

*Performance evaluation of Peer-to-Peer systems

*Trust and security issues = in Peer-to-Peer systems

*Network support for Peer-t= o-Peer systems

*Fault tolerance in Peer-to= -Peer systems

*Efficient Peer-to-Peer res= ource lookup

*Distributed hash tables (D= HT) and related issues

*All aspects related to Peer-to-Peer content, bandwidth, storage and computation power sharing

 <= /font>

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D CALL FOR PAPERS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

P2P-NVE 2007<= /p>

International Workshop on Peer-to-Peer Network Virtual Environments 2007

in conjunction with<= /font>

The 13th International Conf= erence on Parallel and Distributed Systems (ICPADS 2007)

December 5 -7, 2007<= /font>

National Tsing Hua University, Hsinchu, Taiwan, R.O.C.

http://acnlab.csie= .ncu.edu.tw/P2PNVE2007.=

=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

About P2P-NVE 2007

The rapid growth and popula= rity of networked virtual environments (NVEs) such as Massively Multiplayer Online Games (MMOGs= ) in recent years have spawned a series of research interests in constructing such large-scale virtual environments. For increasing scalability and decreasing the cost of management and deployment, more and more studies propose usin= g peer-to-peer (P2P) architectures to construct large-scale NVEs for games, multimedia virtual worlds and other applications. The goal of such research is to support an Earth-scale virtual environment or to make hosting virtual worlds more affordable than existing client-server approaches. However, existing solutions for consistency control, persistent data storage, multimedi= a data dissemination, and cheat-prevention may not be straightforwardly adapted to such new environments, novel ideas and designs thus are needed to realize the potential of P2P-based NVEs.

 

The theme of this workshop = is to solicit original and previously unpublished new ideas on the construction and realization = of P2P-based NVEs, with a focus to facilitate discussions and idea exchanges by both academics and practitioners. All papers accepted for the worksho= p will be included in the IEEE Xplore Digital Library and will be included in t= he proceedings published by the IEEE Computer Society.

 

Topics of interest include,= but are not limited to:

 

* Constructions of P2P over= lays for NVEs

* Multicast for P2P NVEs

* P2P NVE content distribut= ion

* 3D streaming for P2P NVEs=

* Voice communication on P2= P NVEs

* Persistent storage for P2= P NVEs

* Security and cheat-preven= tion mechanisms for P2P games

* Data structures and queri= es for P2P NVEs

* Consistency control for P= 2P NVEs

* Design considerations for= P2P NVEs

* P2P NVE applications on m= obile devices

* Prototype P2P virtual environment systems

 

Important Dates

 

Paper Submission:         = ; July 10, 2007

Author Notification:=           August 10, 2007

Camera Ready Copy Due:    September 2, 2007

 

Paper Submission

Authors are invited to subm= it an electronic version of original, unpublished manuscripts, not to exceed 8 double-columned, single-spaced pages, to web site http://acnlab.csie= .ncu.edu.tw/P2PNVE2007. Submitted papers should be in be in PDF format in accordance with IEE= E Computer Society guidelines (ftp://= pubftp.computer.org/press/outgoing/proceedings). All submitted papers will be refereed by reviewers in terms of originality, contribution, correctness, and presentation.

 

--Boundary_(ID_MdKS5/pVqLghfuESIVvrzA) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: QUOTED-PRINTABLE Content-disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_MdKS5/pVqLghfuESIVvrzA) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_MdKS5/pVqLghfuESIVvrzA)-- From p2psip-bounces@ietf.org Sat Jun 30 11:14:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4eeM-0002PB-KW; Sat, 30 Jun 2007 11:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4eeK-0002P4-PQ for p2psip@ietf.org; Sat, 30 Jun 2007 11:14:12 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4edW-00031G-4S for p2psip@ietf.org; Sat, 30 Jun 2007 11:14:12 -0400 Received: by py-out-1112.google.com with SMTP id f31so2955631pyh for ; Sat, 30 Jun 2007 08:13:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=QJCaZC/ZRRlijqPZdLiWJhx0RPZ7l0qoLggpeT2bHuo4VHp1oLaLVkRIDJNphQ+ONmjX+xWjR2xkBth1X1Fo8xcRH3iKK44j2F3ORzgEE3goceqfvrSl2sXk6cLJ7bzEusSY4pc/e6Kk9rqTZfDmGNcmCFFzaeKINYLxicNung4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=QIyaj/eXalwnkm5wSuOcqzWqKDF3l3y8g9UDetC+8s3AKYL8mz9mOZizP9hdSmbA05/AxyxoYCDZ1lJgzTyiuXkSpSd0AIxdkz9StAcmvkQMs3WUNzw0z2tbgZPTAEWICnuFMZ8T+no1dXIF9V2WwQC8C47B3fBva2sWfRz/pN0= Received: by 10.65.218.15 with SMTP id v15mr4362335qbq.1183216401067; Sat, 30 Jun 2007 08:13:21 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Sat, 30 Jun 2007 08:13:21 -0700 (PDT) Message-ID: <4d4304a00706300813t1ed212f4k92931774b596d41b@mail.gmail.com> Date: Sat, 30 Jun 2007 11:13:21 -0400 From: "David A. Bryan" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 1dd6a32641ea9cf1 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [P2PSIP] Draft deadlines and agenda time X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, As we start to think about an agenda for Chicago. I wanted to solicit requests for agenda time. Sending us a request is just that -- a request -- it doesn't mean you have time. The particular goal the group is moving toward right now, and the focus of agenda time, should be on the framework document (our only official WG item), resolving the open questions within it, and discussing concrete protocol proposals. NO AGENDA TIME will be granted for items that don't have an accompanying IETF draft that is current and was submitted correctly and on time. If we have many requests, those with significant list discussion will be selected. Remember that -00 drafts (that includes anything that was draft-something-sipping that is now in p2psip -- they start over at 00) must be submitted by Monday, July 2, and -01 and later must be submitted by Monday, July 9. If you submitted a -00 sipping, remember that an update to p2psip will be -00 and must be in by July 2. Please CHECK to make sure if you are submitting something as -01 or higher the -00 is there in the archive, there has been lots of confusion around the sipping/p2psip change. Thanks! David -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jun 30 12:14:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4faX-0001ze-8x; Sat, 30 Jun 2007 12:14:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4faV-0001zJ-GZ for p2psip@ietf.org; Sat, 30 Jun 2007 12:14:19 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4faQ-0003xL-Uj for p2psip@ietf.org; Sat, 30 Jun 2007 12:14:19 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I4faP-0002kA-QI; Sat, 30 Jun 2007 11:14:14 -0500 In-Reply-To: <46859661.3040300@sip-communicator.org> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> <4684DBF1.4000203@sip-communicator.org> <0EC20206-306D-4E5F-BA1C-BC26919F5FEB@softarmor.com> <46859661.3040300@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4F9C8C9A-0F3F-4123-B332-2617CBFBBB12@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Sat, 30 Jun 2007 11:14:03 -0500 To: Emil Ivov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 29, 2007, at 6:31 PM, Emil Ivov wrote: > Dean Willis wrote: >> On Jun 29, 2007, at 5:16 AM, Emil Ivov wrote: >>> Dean Willis wrote: >>>> No, the inbound rule looks like "DISCARD UDP ANY ANY" unless a >>>> prior rule allowed DNS through to the DNS server. They weren't >>>> singling out "media" traffic. They were just using a large >>>> blunt object to club all UDP traffic into submission >>> And according to you what were they trying to achieve? >> A reasonable level of security. > > I am not so convinced since I don't see how allowing tcp > connections is > more secure than having UDP with address and port dependent filtering > (which is what conntrack in iptables is doing for example). Can you > please give us some references or describe the risks that this may be > causing? It probably isn't any more secure, but historically (and currently) large-scale enterprise firewalls often don't do connection tracking for UDP. This probably has a lot to do with the problem of high-speed connection state replication across a large pool of firewalls. > > I'd be more inclined to think that most of the enterprises > unconditionally blocking UDP, do so in order to prevent their > employees > from using Internet access for purposes, not directly related to their > work. Most such enterprises also tend to block all traffic other than > http/https. > My experience differs, but certainly some enterprises do have such rules and that accounts for Skype and other successful applications use of tunneling over HTTP. Of course we're not going to standardize that in the IETF, but protocols need to be amenable to this sort of tunneling even if we don't standardize it. >>> I guess I did not express myself clearly. My point is that if >>> someone does not want or does not care about UDP traffic, it's most >>> probably because they don't want or do not care about real-time >>> traffic. We should not try to find ways of circumventing firewall >>> policies and cheat firewall administrators (... we couldn't do >>> that reliably even if we wanted to). >> It wasn't that they didn't want real-time traffic. It is a matter of >> simple expedience -- since UDP traffic is hard to manage, it gets >> blocked. > > Implementing address and port specific filtering for UDP in a firewall > is only slightly different from keeping track of TCP connections. As > far as I know most firewall management interfaces allow users to do > it. > But the FIREWALL doesn't keep track of TCP connections. It just looks at syn/ack to determine whether an incoming packet appears to be part of an established TCP flow. If it is an initial connection "opening" from outside, it gets discarded. This is completely stateless inspection on the firewall. It does leave one a bit open to SYN-flood DOS attacks, but there are other workarounds for that. >> If we could have come up with a reasonable way to allow RTP only when >> a node inside the network was expecting it, we'd have made that work. >> And no, coupling a SIP proxy to the firewall via a control protocol >> is NOT a reasonable solution in a large enterprise. > > You really lost me here. Why is this a problem? And why do you need to > have a SIP proxy on the firewall to do it? You can do this for UDP > just > as easily as you could for TCP. > > If this would help convince you, you might want to have a look at the > following iptables example: > > iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT > iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED -j ACCEPT > ok, now make this work on an enterprise that's multihomed 10 times, with 4 firewall engines in parallel on each access link to provide the needed capacity and reliability, and where any two-packet sequence of incoming UDP might hit either two different firewall engines or even appear on two entirely different access links. To make this work, you've got to have the entire state pool of the UDP connection tracking mechanism mirrored in real-time across a whole bunch of boxes, and the mirroring has to be fast enough to work between the first packet of a flow and the second packet of that flow. But given physics (186,000 miles an hour isn't just a good idea, it's the law, except maybe for quantum twinning), it's going to be very, vary hard to replicate that fast. That's why little residential/SOHO boxes can do things like uPNP, connection tracking for symmetric UDP, and so on, and big guys either can't or just can't afford too. Also, make it work for SIP early media, where a flow from the "outside" starts before the "inside" node sends a single UDP media packet and before the "outside" node has even returned a 200 OK indicating from where it will be listening (and note that it NEVER says from where it will be sending -- if it's polite enough to use symmetric RTP that will help, but we won't KNOW it's going to). Now if you can figure all this out, let me know and I'm sure I can find some startup money to make us both rich! -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jun 30 12:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4fnV-0003bV-J5; Sat, 30 Jun 2007 12:27:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4fnU-0003Si-0Z for p2psip@ietf.org; Sat, 30 Jun 2007 12:27:44 -0400 Received: from wa-out-1112.google.com ([209.85.146.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4fnT-0006Hs-OM for p2psip@ietf.org; Sat, 30 Jun 2007 12:27:43 -0400 Received: by wa-out-1112.google.com with SMTP id k17so1869013waf for ; Sat, 30 Jun 2007 09:27:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=SJOAwUTyYF1kFv1GstqIvWtg6aDmGhBRzP4H9ZqJ1AXHgIXSZx8BJwaCo2Hx236V84gWCJp87G17FePdY81khi2xvLYFJr2yvylRmReBefmQjrwOgODYNqxK7a56GZaGa5Y7Ia55tYF8xKIS2sANGQM5tgJPiKfxCm9rBTZbPEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=TeHfHuaAxaqz4wfu/q3Hqun5Je/1Cil56Yu+gjTIBsYjn37DRjzSYYVooh3axEo0KrYa1zLMktVDlFbpTrPo2w/G4WQ6MDcldIjegpMq5YyRVg5Xoli6Wcmk6MQXb+n2DJY0Wx3pBYzNS9LoNY2R8CldJPSMIWSSwgSWXN87lyc= Received: by 10.114.192.1 with SMTP id p1mr3619548waf.1183220837594; Sat, 30 Jun 2007 09:27:17 -0700 (PDT) Received: by 10.114.113.13 with HTTP; Sat, 30 Jun 2007 09:27:17 -0700 (PDT) Message-ID: <618e24240706300927j215d3272s773501b3999af520@mail.gmail.com> Date: Sat, 30 Jun 2007 18:27:17 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "P2PSIP Mailing List" MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [P2PSIP] Question on additional services X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0108581994==" Errors-To: p2psip-bounces@ietf.org --===============0108581994== Content-Type: multipart/alternative; boundary="----=_Part_89596_30611482.1183220837570" ------=_Part_89596_30611482.1183220837570 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, As far as I know, DHT is as a distributed database used to store the information required to provide the mapping between AoRs and Contact URIs. It is exepected that DHT may also store information required to provide other services required to form and operate or just enhance basic functionalities. Should these additional services be distributed? So that the loss of a peer does not result in the loss of a service. Thanks in advance, Victor Pascual ------=_Part_89596_30611482.1183220837570 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,
As far as I know, DHT is as a distributed database used to store the information required to provide the mapping between AoRs and Contact URIs.
It is exepected that DHT may also store information required to provide other services required to form and operate or just enhance basic functionalities.
Should these additional services be distributed? So that the loss of a peer does not result in the loss of a service.


Thanks in advance,
Victor Pascual
------=_Part_89596_30611482.1183220837570-- --===============0108581994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0108581994==-- From p2psip-bounces@ietf.org Sat Jun 30 20:25:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4nFq-00014I-HO; Sat, 30 Jun 2007 20:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4nFp-00014D-Uj for p2psip@ietf.org; Sat, 30 Jun 2007 20:25:29 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4nFl-00070i-Fc for p2psip@ietf.org; Sat, 30 Jun 2007 20:25:29 -0400 Received: (qmail 7235 invoked for bounce); 1 Jul 2007 02:27:35 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 1 Jul 2007 02:27:35 -0000 Message-ID: <4686F473.5020709@sip-communicator.org> Date: Sun, 01 Jul 2007 02:25:23 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: P2PSIP Mailing List , Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> <4684DBF1.4000203@sip-communicator.org> <0EC20206-306D-4E5F-BA1C-BC26919F5FEB@softarmor.com> <46859661.3040300@sip-communicator.org> <4F9C8C9A-0F3F-4123-B332-2617CBFBBB12@softarmor.com> In-Reply-To: <4F9C8C9A-0F3F-4123-B332-2617CBFBBB12@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean Willis wrote: > On Jun 29, 2007, at 6:31 PM, Emil Ivov wrote: > >> I am not so convinced since I don't see how allowing tcp >> connections is more secure than having UDP with address and port >> dependent filtering (which is what conntrack in iptables is doing >> for example). Can you please give us some references or describe >> the risks that this may be causing? > > It probably isn't any more secure, but historically (and currently) > large-scale enterprise firewalls often don't do connection tracking > for UDP. This probably has a lot to do with the problem of high-speed > connection state replication across a large pool of firewalls. Large scale enterprises are quite often behind NATs. Few companies today could get their hands on enough IPv4 addresses and this is even more so for the big ones (especially when outside the US). Therefore most of these are already capable of handling connection tracking. > My experience differs, but certainly some enterprises do have such > rules and that accounts for Skype and other successful applications > use of tunneling over HTTP. Of course we're not going to standardize > that in the IETF, Yes, and this is exactly the point I am trying to make here. > but protocols need to be amenable to this sort of tunneling even if > we don't standardize it. > > But the FIREWALL doesn't keep track of TCP connections. It just looks > at syn/ack to determine whether an incoming packet appears to be > part of an established TCP flow. If it is an initial connection > "opening" from outside, it gets discarded. This is completely > stateless inspection on the firewall. It does leave one a bit open to > SYN-flood DOS attacks, but there are other workarounds for that. Well, isn't it quite obvious that this kind of firewalls won't work for P2P even when TCP based because it won't allow for end-to-end simultaneous connection establishment? > Now if you can figure all this out, let me know and I'm sure I can > find some startup money to make us both rich! Heey, no problem. I am sure that if we start entangling photons right now in a month or two we'll be able to build a quantum firewall and it'll be doing all kinds of magic, so you better get that money ready! :-)) Emil > > -- Dean > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip