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 protected]> 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 >> 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 > -- Best Regards, Bin Long
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
