Thanks Sherry for the examples, especially for mentioning the distinction between P2P and CS. Here is a use case: There is a nationwide/international event broadcast from a web site, such as a presidential election debate or an Olympic competition. The web site is voice enabled for friends to chat while watching the event. This generates a huge spike in voice traffic, roughly for the duration of the event. It would be impossible the design CS SIP networks to cope with such traffic spiking apps IMO. Only a P2P SIP network would make sense in such a scenario to cope with fast scalability.
Maybe using cloud computing for large scale CS SIP traffic events may also work, but we would need a new WG for SIP-RTP Cloud Computing... :-) Henry On 2/10/09 10:00 AM, "Wang, Sherry" <[email protected]> wrote: Henry, Agree: the type of mixed can be a candidate to study mobile P2PSIP. There would be cases where capacity and resources may not be limited while keeping a RF connection is a challenge by using the model of client/server of existing SIP, especially in terms of performance. For example, high-speed flying devices or moderate-speed ground vehicles for military use, etc. Your emergency rescue is another good example of the mixed type. Thanks, Sherry ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Henry Sinnreich Sent: Tuesday, February 10, 2009 10:00 AM To: [email protected] Subject: Re: [P2PSIP] mobile p2p in p2psip >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
