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

The 'stabilization factor' is a nice idea.
In a simple case, it would be a factor considered internally by each end
device to decide whether it should become a Peer or a Client (==Passive Peer
in your suggested term). Then it does not require any detailed
specification.

Thanks.

Eunsoo

On 3/7/07, Willekens, Marc <Marc.Willekens@siemens.com> 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:philip_matthews@magma.ca]
> 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
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>