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

[Philip Matthews <[e-mail]>]

Though I agree that the scalability question is very important,
I don't think it belongs in the Additional Questions section.

The scalability question I think is much more of a "usage  
scenarios" (or "use-cases") question.

- Philip


On 7-Mar-07, at 18:30 , Willekens, Marc wrote:

> Hi Philip,
> About the additional questions, I think the most important is the  
> scalability. These days, the p2p paradigm is seen as "the solution"  
> to solve the scalability problem. It's true for the processing  
> power and memory which is spread out over the p2p network, but the  
> cost is the additional traffic in the network. The big question is  
> the stability of the network, certainly when its completely under  
> control by the end-users. If they make use of unstable end-devices,  
> and when their p2p network connection is intermittent, then there  
> could be many required updates in the distributed hash tables.  
> Maybe we need a kind of "stabilization factor" for each end-device  
> in order to determine its activity role in the p2p network, i.e.  
> how much it is allowed to contribute its resources to the p2p  
> network. Do we need a kind of incentive system so that p2p networks  
> always strives to a certain optimum?
> Br,
> Marc.
>
>
> -----Original Message-----
> From: Philip Matthews [mailto:[e-mail]]
> Sent: woensdag 7 maart 2007 23:27
> To: Willekens, Marc
> Cc: Dean Willis; P2PSIP Mailing List
> Subject: Re: [P2PSIP] Comments to draft-willis-p2psip-concepts-04
>
> Marc:
>
> Thanks very much for your comments.
> Replies inline.
>
> - Philip
>
> On 7-Mar-07, at 10:30 , Willekens, Marc wrote:
>
>> 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.
>
> Thanks.
>>
>> 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.
>
> The wording here was intended to be vague on the details
> of what would be stored. There is a little bit more details later
> about services in section 5.1.
>
> Section 6.1 explicitly raises the issue of  how to select between
> multiple peers offering the same service. However, we do not
> specify a solution, since we don't think the WG has come to
> any consensus on this. In fact, one of the proposals is that
> the WG _not_ standardize how this is done.
>
>
>
>>
>> [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.
>
> Yup. Hence the document says (section 4)
>
>                                    Note
>        that the term client does not imply that this node is a SIP  
> UAC.
>        Some have suggested that the word 'client' be changed to
> something
>        else to avoid both this confusion and the implication of a
> client-
>        server relationship.
>
>> 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.
>
> Thanks for the terminology suggestion.
> Let's see what happens with the client  concept. If they are kept,
> then this might be a good terminology change.
>
>>
>> [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.
>
> OK.
>
>>
>> [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.
>
> The examples from the -03 version were removed because:
> a) They ignored the presence of NATs  (e.g., you usually cannot
> just send an INVITE to a peer that is directly behind a NAT), AND
> b) They all assumed the first option of section 5.2 and we wanted
> to talk about the other options, AND
> c) They all assumed the first alternative of section 5.5.
>
> The examples in the -04 version do not make these assumptions,
> and (in my opinion) give much more detail.
>
> What we gave up was examples about clients.
> As the person who wrote most of the text in this revision, I will say
> that it is REALLY REALLY difficult to say
> much about clients right now, since almost nothing is decided.
> Trying to write text about clients that is true under  all the
> alternative
> views of clients that have been proposed is very painful.
>
> I guess we could have added some examples in the  section that
> talks about  clients.
>
>>
>> [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?
>>
>
> Thanks for the questions.
> We will think about including some of them in the next revision.
>
> If we assume that we want to keep this section fairly important,
> then which questions do you think are the most important?
>
>
> - Philip
>
>
>
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
>


_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip