Hi Lin, Thanks for looking through the draft and sharing comments. The motivation to attach to an arbitrary peer may not only be driven by inability to attach to the OAP due to NAT problems - a node may choose to attach to a DAP due to proximity or even to use the same DAP to attach to multiple overlays, thereby providing significant power savings to a client. Of course, a node may choose to first attach as a regular client at the OAP and then decide to find a DAP if conditions change as well - the draft does not preclude that. But, in order to handle appropriate state at OAP and DAP and to set up the connections, we will need support for indicating the DAP to the OAP.
Also, we want the enrollment server to assign node ids randomly to all nodes. A node need not have a strict rule about always participating as a client or a peer - a node may start out as a peer and then switch to a client role later (say, when its battery is low). At the moment, even regular client behavior is not documented in the base draft. I had sent the authors some text a while ago for this. I will also forward that along to the mailing list for comments. Thanks, Vidya > -----Original Message----- > From: Xiao, Lin (NSN - CN/Beijing) [mailto:[email protected]] > Sent: Wednesday, July 01, 2009 2:51 AM > To: Narayanan, Vidya; [email protected] > Subject: RE: [P2PSIP] New draft on enhanced client operation for RELOAD > > Hi Vidya, > > It is really a good start to discuss the client mobility issues in > RELOAD. Using DAP and OAP seems a good solution for clients that > attached to arbitary peers. However, does eClient really need a > specific > bootstrapping different with that in RELOAD BASE? > > IMO, a client does not need to claim itselft an eClient or not when > joining in the overlay. A ordinary bootstrapping can work as if it is a > normal client. The node ID is allocated by bootstrap server. This > client > can use the Node ID to set up connection with OAP and neighbours as > normal overlay nodes do. If the bootstrap server used here has the > ability to consider a little bit physical network topology, the > allocated node ID, of cause, is quite close to its OAP. There should > no > problem to set up a direct connection between the client and OAP on the > overlay at the begining. Only when the client found that it is > impossible to directly connect to its OAP (most of time, it is due to > the client moving out of the OAD's reachability), it'll select a DAP > from its neighbours. This could keep your scheme more simpler and > accordant with RELOAD BASE. Right? > > Best Regards, > Lin > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf > Of ext Narayanan, Vidya > Sent: Wednesday, July 01, 2009 4:51 AM > To: [email protected] > Subject: [P2PSIP] New draft on enhanced client operation for RELOAD > > Hi, > We have submitted a draft on enhanced client operation for RELOAD. It > supports the attachment of clients to arbitrary peers without needing > application specific destination list population and it inherently > provides support for client mobility. > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-vidya-p2psip-eclients-00.txt. > Comments welcome. > > Thanks, > Vidya > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
