Hi Cullen, Thanks for your reply.
I agree that RELOAD have covered most of the functionalities of peers and clients. However, there is still a little different between clients and peers while connection is lost besides data replica. What I mean here is the Node ID. Because all the peers in the overlay are connected according to a strict overlay algorithm. The position of a peer in the overlay is decided by its Node ID. If a peer lost its position (disconnected) in the overlay because of moving and NAT, but still want to work as a peer, it must change its Node ID, which means it need do the enrollment again and rejoin the overlay. But, because a client can attach with an arbitrary peer. It is not necessary for a client to change its Node ID when it change its attaching peer. The most important thing here is that, this behavior make it possible for a client to keep session continuity while its attaching peer is switched. Considering to deploy RELOAD in reality, stable nodes are preferred to work as peers while mobile nodes can take the advantage of the client behavior mentioned above. Sessions can be kept with high mobility, as unique Node ID is maintained by clients. I'm not sure if RELOAD has considered this distinction of client, which help clients to be attached with the ovelay as long as it can build at least one connection to the overlay. Br Xiao, Lin -----Original Message----- From: ext Cullen Jennings [mailto:[email protected]] Sent: Friday, October 16, 2009 9:05 AM To: Xiao, Lin (NSN - CN/Beijing) Cc: P2PSIP WG Subject: Re: [P2PSIP] New versions of RELOAD and sip draft Thank you, few comments inline.... On Oct 10, 2009, at 2:20 AM, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi Cullen, > > I've had a quick review of these two drafts, and still not quite clear > with some Client related issues. > > I know Client is not the first-class concept in RELOAD, but as it has > been involved in the RELOAD protocol, RELOAD should give full support > to client anyhow, right? > > In the terminology chapter of RELOAD Base draft, the connection table > is defined as: > "The set of peers to which a node is directly connected. This > includes nodes with which Attach handshakes have been done but which > have not sent any Updates." > although, the second sentence implies that clients are also involved > in, I still suggest to replace the "peers" in the first sentence with > "nodes" to make it more clear that both peers and clients can be > maintained in the table. I agree. I changed this - thank you for the careful review to catch things like this. > > In my opinions, connection setup and maintenance between client and > its > connected peer (responsible peer or arbitrary peer) is a key issue for > client support in RELOAD. My question is: Does a peer in RELOAD > distinguish if the connection is to a peer or to a client? Because the > reaction of the peer could be different when the connection is lost. Reload does distinguish at some level but what do you think a node needs to do differently when a connection is lost if the connection when to a peer or client. Clearly how data replication is handled and some of the finger table stuff is handled differently but I think that is covered in the draft. If you see something specific missing, let me know. > > As a client could set up a connection only with an arbitrary peer. > Does > this peer distinguish such connection from those it is responsible to? I don't se the need to. > Should this peer inform the client's responsible peer about the > Destination List to the client? So that it can still be accessed by > other nodes. Or should the Destination List been stored with some > usage, > say SIP Usage? Yes, that is the approach to store destination lists where they are needed. > If so, the SIP usage must be extended to allow a > Destination list containing more than one Node IDs. agree that it needs to allow storing multiple Node IDs but I think it already does that. > In current SIP > usage draft, the SipRegistration structure only allow one address > being > stored in the Destination List, as: > " Destination destination_list<0..2^16-1>;" The destination_list here is an array of Destinations so it allows between 0 and 65K entries in the array. I agree the syntax for specifying arrays might seem a bit weird but I think the structure is what you are pointing out we need to have. > It should be replaced by: "Destination destination_list > [dest_list_length];" > to enable a longer list stored by arbitrary connected clients. > > Anyway, IMHO, RELOAD should make sure to cover all situations a client > could meet or at least clearly distinguish issues of clients, > especially > for arbitrary connected ones, which are left to be solved by other > drafts. Thanks. > > > Best Regards, > Xiao, Lin > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf > Of ext Cullen Jennings > Sent: Wednesday, October 07, 2009 1:53 AM > To: P2PSIP WG > Subject: [P2PSIP] New versions of RELOAD and sip draft > > > I just submitted > draft-ietf-p2psip-base-04 > and > draft-ietf-p2psip-sip-02 > > These contain technical changes but do not have a lot of editorial > changes. At some point we need to go and reorganize the documents with > editorial changes. > > Cullen <in my individual contributor role> > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
