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
