This is a very good point Henry. I have often thought that for a scenario like this, you probably just want to be a client...which could mean that a good behavior for a device (this wouldn't be specified in a protocol, just something an implementor does) would be to connect as a client and only switch to a peer after some period of time with a fixed IP address. I realize that is a simplistic way to do it, but it could solve the problem without extensive draft/protocol efforts. Now this raises the question of devices never being peers as a result (even if capable) and having no one willing to serve as a peer, but that is a whole different issue...
David (as individual) On Tue, Feb 10, 2009 at 10:00 AM, Henry Sinnreich <[email protected]> wrote: >>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. > > I believe this is a key new insight brought to the WG and should be > reflected in the WG documents. The laptop example is quite convincing in > such scenarios as opening the netbook for a quick call at the airport and > closing it it immediately afterwards. > > Henry > > -----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 > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
