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
