Subject: Re: [P2PSIP] Peer vs Client (mobile p2p in p2psip)

From: Bin Long <[email-masked]>
Date: Thu, 12 Feb 2009 12:13:43 +0800

Hi all,

It seems that a node with high mobility had better be a client other than a
peer considering the maintenace cost it brought to the overlay.Does anyone
can tell how much additional overhead it would result in? Are there any ways
to alleviate this a little?

I also have another question: From the fair perspective of the overlay, the
two roles of peer and client can bring potential risk in stableness. As we
can see, peers pay for what they get while clients just consume without
contributing. This is unfair to peers if they are not volunteers to do this,
and may lead to the result that the qualified nodes are willing to pretend
they are not competent and act as clients.   When the clients nodes
far overpass peer node, the overlay cannot be stable. Should we introduce
some incentive and punishing mechanisms to proportion the peers and clients
in the overlay?

Best wishes,
Bin, Long
On Wed, Feb 11, 2009 at 5:17 PM, Minh Nguyen <[email-masked]> wrote:

> Hi Xiao,
>
>
>
>> Using mobile nodes as peers highly increases the maintenance cost of the
>> overlay structure. The ideal P2P communication (from the point of mobility
>> feature) is using fixed peers to construct overlay with clients either fixed
>> or mobile.
>>
>
> I totally agree with you. A Peer who has high mobility should be come a
> Client to reduce the maintain cost of Overlay. On the other hand, Clients
> has 'qualified' and low movement can become a Peer. However, It probably
> depends on different context.
>
> Best regards,
> -Minh
>
>
>>
>>
>>
>> -----Original Message-----
>>  From: ext Das, Saumitra [mailto:[email-masked]]
>> Sent: Wednesday, February 11, 2009 4:50 AM
>> To: Xiao, Lin (NSN - CN/Beijing); [email-masked]
>> Subject: RE: [P2PSIP] mobile p2p in p2psip
>>
>> Hi Xiao,
>>
>>  I just put the MANET as an example that may need a different DHT plugin.
>> P2P mobility (nto MANET mobility) simply shows up as excessive churn and a
>> network with a lot of mobile peers would have to deal with such churn. As
>> long as the mobile peer can rejoin the network everything works. Dealing
>> with a failed network connection due to mobility or the node going down from
>> churn is similar.
>>
>> Best,
>> Saumitra
>>
>>
>> -----Original Message-----
>> From: Xiao, Lin (NSN - CN/Beijing) [mailto:[email-masked]]
>> Sent: Tuesday, February 10, 2009 1:09 AM
>> To: Das, Saumitra; [email-masked]
>> Subject: RE: [P2PSIP] mobile p2p in p2psip
>>
>> Hi Das,
>>
>> In my opinion, the P2P mobility addresses the issues like disconnection of
>> two connected nodes in the overlay structure caused by the route unreachable
>> in the network layer when nodes move. It's a different topic with
>> implemeting DHT on MANETs, where considers the disconnection of a route
>> caused by unreachable of a node on link level.  IP unreachable in mobile ad
>> hoc networks mean the destination node or source node is isolated because of
>> the limited radio access distance.
>>
>>
>> Best Regards,
>> Xiao Lin
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of ext Das, Saumitra
>> Sent: Tuesday, February 10, 2009 2:55 PM
>> To: [email-masked]
>> Subject: Re: [P2PSIP] mobile p2p in p2psip
>>
>> Handling mobile nodes can be done in the framework of the base draft. For
>> example, the DHT protocol itself can be different if the operating
>> conditions are such that there is a lot of moiblity. There are several
>> proposals for DHTs to operate efficiently on highly mobile networks such as
>> MANETs. These should be doable under the pluggability principle of RELOAD.
>>
>> The fact about who should be peer, client can be based on decisions of the
>> overlay deployer. Some overlays make not have such choices being made up
>> only of mobile nodes. There are various techniques to deal with excessive
>> churn due to mobility and the consequent need to replicate data which can
>> work under the framework of the base draft.
>>
>> New draft could focus on best practices or results on such choices.
>>
>> Best
>> Saumitra
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Xiao, Lin (NSN - CN/Beijing)
>> Sent: Monday, February 09, 2009 9:41 PM
>> To: ext Song Haibin; Henry Sinnreich; David Artu?edo Guillén; Victor
>> Pascual ávila
>> Cc: longbwe longbwe; Wang, Sherry; [email-masked]
>> Subject: Re: [P2PSIP] mobile p2p in p2psip
>>
>>
>> Hi Bruce and Haibin:
>>
>> I totally agree with you to further consider the mobility behavior
>> together with the status of the node (peer or client) in the overlay.
>>
>> Mobility could bring disconnection and reconnection which changes the
>> topology structure of a P2P overlay. Different influences are given to peers
>> and clients. Clients only need to reconnect with overlay simply, while peers
>> need do data migration and even more before changing connection. There is no
>> point to ask client to install a same complex protocol with peer, especially
>> in mobility scenario. Moreover, the frequent moving of peers could be a
>> disaster for structured overlay. Therefore, it is necessary to tell which
>> kind of devices could perform as peer and which should work as clients.
>>
>> Besides the peer/client definition mentioned in Reload base, the mobility
>> character should also be considered to separate them. In my opinion, there
>> could be three kinds of node in the overlay: fixed (e.g. desktop), mobile
>> (e.g. handset) and mixed (e.g. laptop). Fixed nodes are obviously good
>> candidates for peers of overlay, while mobile handsets should be limited in
>> client status considering not only their limited capability and resources
>> but also the highly mobile characteristic. Some devices like laptop could
>> perform either as peers or as clients depending on requirement. The peer
>> mobility issues are mainly brought by this kind of nodes.
>>
>> So, the overlay could be constructed by some relative static nodes as
>> peers for data storage and message routing. The highly mobility nodes, which
>> work only as clients, can not cause churn of the overlay topology structure.
>> It seems that we'd better consider the client mobility and peer mobility
>> separately to describe their behavior and to develop their protocols more
>> clearly.
>>
>>
>> Xiao Lin
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of ext Song Haibin
>> Sent: Tuesday, February 10, 2009 9:54 AM
>> To: 'Henry Sinnreich'; 'David Artu?edo Guillén'; 'Victor Pascual ávila'
>> Cc: 'longbwe longbwe'; 'Wang,Sherry'; [email-masked]
>> Subject: Re: [P2PSIP] mobile p2p in p2psip
>>
>> Hi Henry and Bin,
>> >>Frequent changes has to be managed in order to route messages
>> efficiently.
>>
>> >>It is not the same as churn, but it introduces similar challenges, IMHO.
>>
>> >>This makes sense and is the reason the present work in the P2P SIP WG
>> >>we have peer nodes and client nodes.
>>
>> >There was an I-D (now expired) on this:
>> >Pascual, V., Matuszewski, M., Shim, E., Zhang, H., and S. Yongchao,
>> >"P2PSIP Clients", <draft-pascual-p2psip-clients>
>>
>> >It was preceded and followed by many discussions on this topic, such as
>> >that frequent p2p protocol messages for peer nodes will quickly exhaust
>> >the battery.
>>
>> As the co-author of this I-D (use my previous name Song Yongchao), I
>> support that the mobile devices should be better to act as clients rather
>> than peers whenever possible. But I guess there are scenarios where only
>> mobile devices are available. In this case, more considerations need to be
>> given to the mobility of a "peer".
>>
>> Bin, I don't know if this is what you concern about.
>>
>> BR
>> Song Haibin
>>
>>
>> Just to be clear, clients are a fully integrated component of the base
>> reload protocol.  Motivation for them and some discussion of related issues
>> is in the p2psip-base appendix (and a much more extensive discussion in
>> pascual-clients and others), but the actual mechanisms to support them
>> should already be in the base draft.
>>
>> Discussion of further work identifying when a node should be a peer and
>> when it should be a client, or overlay algorithms optimized for specific
>> types of deployments, including "mobile", might be good topics for further
>> work in new drafts, of course.
>>
>> Bruce
>>
>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>> _______________________________________________
>> P2PSIP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/p2psip
>>
>
>
>
> --
>   Minh Nguyen
> +33 6 65764460
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: Minh Nguyen <[email-masked]>
Date: Sun, 15 Feb 2009 00:19:47 +0100

Hi  Bin,

> some incentive and punishing mechanisms to proportion the peers and clients

*IMHO, MobileP2P (e.g Ad hoc) is a endpoint-oriented networks by itself.
Hence, Users (Peer or Client) need to be willing to cooperate to each other.
It may depends on our design.*

Best Regards,
-Minh

>>> In my opinion, the P2P mobility addresses the issues like disconnection
>>> of two connected nodes in the overlay structure caused by the route
>>> unreachable in the network layer when nodes move. It's a different topic
>>> with implemeting DHT on MANETs, where considers the disconnection of a route
>>> The fact about who should be peer, client can be based on decisions of
>>> the overlay deployer. Some overlays make not have such choices being made up

-- 
  Minh Nguyen
+33 6 65764460

---

From: Bin Long <[email-masked]>
Date: Mon, 16 Feb 2009 14:37:10 +0800

yes, it may be more of business concerns with respect to incentive
mechanism.

On Sun, Feb 15, 2009 at 7:19 AM, Minh Nguyen <[email-masked]> wrote:

>
> Hi  Bin,
>
>
>> I also have another question: From the fair perspective of the overlay,
>> the two roles of peer and client can bring potential risk in stableness. As
>> we can see, peers pay for what they get while clients just consume without
>>>>  I just put the MANET as an example that may need a different DHT
>>>> plugin. P2P mobility (nto MANET mobility) simply shows up as excessive churn
>>>> and a network with a lot of mobile peers would have to deal with such churn.
>>>> As long as the mobile peer can rejoin the network everything works. Dealing
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of ext Das, Saumitra
>>>> Handling mobile nodes can be done in the framework of the base draft.
>>>> For example, the DHT protocol itself can be different if the operating
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Xiao, Lin (NSN - CN/Beijing)
>>>> Besides the peer/client definition mentioned in Reload base, the
>>>> mobility character should also be considered to separate them. In my
>>>> opinion, there could be three kinds of node in the overlay: fixed (e.g.
>>>> desktop), mobile (e.g. handset) and mixed (e.g. laptop). Fixed nodes are
>>>> obviously good candidates for peers of overlay, while mobile handsets should
>>>> be limited in client status considering not only their limited capability
>>>> and resources but also the highly mobile characteristic. Some devices like
>>>> laptop could perform either as peers or as clients depending on requirement.
>>>> The peer mobility issues are mainly brought by this kind of nodes.
>>>>
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of ext Song Haibin

-- 
Best Regards,
Bin Long