[P2PSIP] FW: some comments on P2PP protocol
JiangXingFeng <jiang.x.f@huawei.com> Tue, 17 July 2007 11:00 UTC
Return-path: <p2psip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAknY-0003De-NB; Tue, 17 Jul 2007 07:00:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAknX-0003DT-5C for p2psip@ietf.org; Tue, 17 Jul 2007 07:00:55 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAknT-0001sJ-EU for p2psip@ietf.org; Tue, 17 Jul 2007 07:00: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 <0JLB005Y3L7VMB@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 18:59:55 +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 <0JLB00F9SL7U9W@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 18:59:55 +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 <0JLB006O1L7ROP@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 18:59:54 +0800 (CST)
Date: Tue, 17 Jul 2007 18:59:51 +0800
From: JiangXingFeng <jiang.x.f@huawei.com>
To: 'P2PSIP WG' <p2psip@ietf.org>
Message-id: <000101c7c861$997fc920$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: AcfIYYLSvKDsow29RZyy+786PsVDAAAAAgcg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Subject: [P2PSIP] FW: some comments on P2PP protocol
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org
Sorry, forget to copy the P2PSIP community. -- Jiang XingFeng > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Tuesday, July 17, 2007 6:59 PM > To: 'Salman Abdul Baset'; 'hgs@cs.columbia.edu' > Subject: some comments on P2PP protocol > > Hi, > Some comments on draft-baset-p2psip-p2pp-00 are followed. > > 1. In section 4.1, the draft says that Client and peers communicate using the same > protocol as peers do, i.e., there is no distinct protocol for client-to-peer and > peer-to-peer communication. > > Does it mean that Publish, lookupObject, RemoveObject could be used by clients in > the same way as the peer uses them? If it does, how do clients fill the peer-info field > in these messages? After all, clients have no peer ID which peers have. > > 2. In section 5.2.1, it seems that peer will add copy of its routing table and neighbor > table in both directions, not only during forwarding request, but also during > forwarding response. It will add the copy two times and it is enough to do the > operation in either direction. > > 3. In the draft, when a peer receives a request, it will look up the routing table and > find out whether it could give the definitive answer for this request. What does the > definitive answer mean? Does it mean that P2PP protocol will check whether the > peer is the destination peer, then look up in the resource table to get a resource > object keyed by the resource ID? Most of the P2P systems give the definitive > answer according to the above rule. > > But if there are some caches of the resource in the overlay, maybe it could be > incorporated into the resource table and it could be used to answer the request. But > this method may destroy the DHT rule, i,e, peers which are not the resource's root > could give the response. What about your opinions? > > 4. As for Peer-info, how about adding a field to identify which add-on services the > peer supports? In P2PSIP, peers must support routing and storage service. But > maybe some peers may have additional services, for example, STUN or TURN, > which could be used by the other peers. By carrying the service which the peer > supports may facilitate the discovery of these services in the overlay? Comments? > > > > Regards > -- > Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip
- [P2PSIP] FW: some comments on P2PP protocol JiangXingFeng