See inline [Song]. > -----Original Message----- > From: Roy, Radhika R Dr CTR USA USAMC [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 29, 2008 10:17 PM > Please see my inputs inline [RRR] > > I need to modify the second question to make it more clear. > > > > I think most proposals agree that one client can have multiple > > associatedpeers to keep the service continuity. The open issues are: > > > > (1) Should there be a primary associated peer? And when this peer > > fails, the > > client switches to another associated peer? I am not sure of about it. > > [RRR] I think the answer is none from the protocol point of view. However, if > clients wants to make something as its primary, secondary, etc., it should be > left for implementations. It is a different area how a client will these > choices.
[Song] Maybe it is left to the implementations to do the choice in my mind. If someone thinks there is a need for the choice to be communicated between a client and its associated peer in some scenarios, then it should be considered from the protocol point of view? > > (2)Should the client learn more peers information that can be the > > client'sassociated peers through its now associated peer? And when > > one of its > > associated peers fails, it joins another to keep enough associated > > peers for > > choice? I think probably this is what we needed. > [RRR] Yes, definitely. I guess that it is the beauty of the P2P protocol to > make as reliable as one can make. [Song] Yes, we need to provide reliable service to the clients in the overlay. I think the associated peer may notice the client with a few peers information regularly(must not very often if the churn rate of the overlay is low), and then the client can inquire these peers to make a good choice. I will add it to the SEP Client Protocol. Thanks. > > (3)Should there be a notification mechanism between a client and its > > associated peer? So the client can timely know the status of the > > associated peer, and avoid choosing the congested or busy peer to > > serve him? I think we > > do need it. > > [RRR] I think that the performance criteria for choosing a peer should be a > general one as it is the usual case in any communications networks. For example, > in the IP network, the routers also have some general criteria how to choose > the netxt hop router out of many neighboring routers. In the same token, the > P2P protocol should also follow the similar mechanisms that are obvious. [Song] I agree. There is no such a peer which is eternal powerful in the p2p overlay. It may be busy, or its bandwidth may get congested, or there is some device error which makes it go down. In SEP client protocol, we provide a NOTIFY message for the status notification between a client and its associated peer, but we don't provide the strict criteria when a NOTIFY should be sent, it is left to the implementation, or we can describe some general criterias here? > > Best Regards, > > Song Yongchao > > Email: [EMAIL PROTECTED] > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list [email protected] https://www1.ietf.org/mailman/listinfo/p2psip
