[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