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 > 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? > *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 > Best wishes, > Bin, Long > On Wed, Feb 11, 2009 at 5:17 PM, Minh Nguyen <[email protected]> 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 protected]] >>> Sent: Wednesday, February 11, 2009 4:50 AM >>> To: Xiao, Lin (NSN - CN/Beijing); [email protected] >>> 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 protected]] >>> Sent: Tuesday, February 10, 2009 1:09 AM >>> To: Das, Saumitra; [email protected] >>> 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 protected] [mailto:[email protected]] On Behalf >>> Of ext Das, Saumitra >>> Sent: Tuesday, February 10, 2009 2:55 PM >>> To: [email protected] >>> 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 protected] [mailto:[email protected]] 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 protected] >>> 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 protected] [mailto:[email protected]] 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 protected] >>> 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 protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> >> >> >> -- >> Minh Nguyen >> +33 6 65764460 >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > > > > -- Minh Nguyen +33 6 65764460
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
