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
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip