[P2PSIP] Comments to draft-willis-p2psip-concepts-04

"Willekens, Marc" <Marc.Willekens@siemens.com> Wed, 07 March 2007 15:31 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 1HOy6i-00064n-Um; Wed, 07 Mar 2007 10:31:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOy6h-00064f-Aw for p2psip@ietf.org; Wed, 07 Mar 2007 10:31:11 -0500
Received: from mail-out.sbs.be ([193.109.72.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOy6d-0001lK-AJ for p2psip@ietf.org; Wed, 07 Mar 2007 10:31:11 -0500
Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l27FUrvl001903; Wed, 7 Mar 2007 16:30:54 +0100
Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l27FUqDd028914; Wed, 7 Mar 2007 16:30:52 +0100
Received: from BRU0038A.ww018.siemens.net ([193.210.175.64]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 16:30:51 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 07 Mar 2007 16:30:39 +0100
Message-ID: <67043E463DDBFD4A8087ED940BFF756B01424BD5@BRU0038A.ww018.siemens.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments to draft-willis-p2psip-concepts-04
Thread-Index: AcdgzXYRZ7vQEavIRVmv0r26ixGaVg==
From: "Willekens, Marc" <Marc.Willekens@siemens.com>
To: dean.willis@softarmor.com
X-OriginalArrivalTime: 07 Mar 2007 15:30:51.0608 (UTC) FILETIME=[96B0CD80:01C760CD]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Cc: p2psip@ietf.org
Subject: [P2PSIP] Comments to draft-willis-p2psip-concepts-04
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>
Content-Type: multipart/mixed; boundary="===============0369288121=="
Errors-To: p2psip-bounces@ietf.org

Hi Dean and other draft authors;
 
Some comments to your draft:
http://www.ietf.org/internet-drafts/draft-willis-p2psip-concepts-04.txt
 
1. General remark
Nice rework of this version! The high level description now indicates the scope of the P2PSIP which is not restricted to the typical SIP registrar functionality. Maybe, it's better to indicate this also in the abstract section which still indicates a more restrictive scope.

 

2. Specific remarks
[Page 4], 2 High Level Description, §5

"The distributed database may need to store information about services."

Shouldn't this be extended with the resources provided for these services? I can assume not all nodes will have the same kind of processing power, memory and transport bandwidth. This information is required to allow an optimal spreading of the information in the p2p overlay network. The distribution algorithm has to take this information into account.

 

[Page 4], 2 High Level Description, §6

Some discussion about the name for P2PSIP-peer and P2PSIP client:

The client gives the impression of a client/server concept which is in contradiction with the distributed p2p model. Of course, a client/server access architecture can be used to access the p2p network, but then, it's maybe better to talk about a normal SIP client because the P2PSIP overlay network is in fact unknown and invisible to the user.

When the scope is p2p and having a client which is not providing the resources in an active way to the p2p network, but when it is however making use of p2p functionality to get and put information in the overlay network, then we can start thinking about differentiating between active P2PSIP peers and passive P2PSIP peers.

 

[Page 5], 2 High Level Description, §10

I agree to the extension to different address spaces. I think it's a mandatory requirement to allow the p2p overlay network on a world-wide scale basis over different domain spaces. If it's bound to a specific address space only, then it are the end-users contributing to network resources without having a real additional benefit out of it. It only solves the problem of the domain owner to reduce its own OPEX and CAPEX by moving this towards the end-user.

However, when it works over different address spaces (domains), then a world-wide service provider can use the p2p concept in his own overlay network in a more optimal way and distribute the data in function of the location where it is needed the most.

 

[Page 13], 5.2 Using the distributed database, §1

Why have you taken out the examples from the -03 version?  In version 03, it was indicated who will setup the actual session after finding the location from the distributed database. For that version 03, I have the remark of one additional case which can also be considered, i.e. in §1.4.2, (P2PSIP client contacts P2PSIP Peer), the UA client C is setting up the session. The additional case could be the setup of the session by the Peer Q. In that way, the "passive" peer can take advantage of its "active" peer part in the network to execute the SIP invite protocol.

 

[Page 21], 6 Additional questions

The document indicates the use of a p2p network over different address spaces. However, there can still be many different separate p2p networks. Don't we have to think about inter-p2p domain communication? Can a user belong to different p2p overlay networks at the same time? What's the influence on very big p2p networks when end-users have a very dynamic behavior for enrolment and inserting their peer node in the network? What's the practical limit for the amount of peers? Does it really scale world-wide or do we have to think about smaller p2p networks interconnected with each other?
 
 
 
Best regards,
Marc Willekens
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip