RE: RE: [P2PSIP] Open issues with client has multiple associated peers

See inline [Song].

> -----Original Message-----
> From: Roy, Radhika R Dr CTR USA USAMC [mailto:radhika.r.roy@us.army.mil]
> 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: melodysong@huawei.com
> >
> >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > P2PSIP@ietf.org
> > https://www1.ietf.org/mailman/listinfo/p2psip
> >

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip