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

From: Song Yongchao <[email-masked]>
Date: Tue, 29 Jan 2008 18:55:28 +0800

Hi, all

I think most proposals agree that one client can have multiple associated
peers 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.

(2)Should the client learn more peers information that can be the client's
associated peers? And when one of its associated peer fails, it joins
another? I think probably this is what we needed.

(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.

Best Regards,
Song Yongchao
Email: [email-masked]

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Song Yongchao <[email-masked]>
Date: Tue, 29 Jan 2008 19:05:25 +0800

I need to modify the second question to make it more clear.

 
(2)Should the client learn more peers information that can be the client's
associated 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.

 Best Regards,
 Song Yongchao

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Tue, 29 Jan 2008 09:16:46 -0500

Please see my inputs inline [RRR]

----- Original Message -----
From: Song Yongchao 
Date: Tuesday, January 29, 2008 6:06
Subject: RE: [P2PSIP] Open issues with client has multiple associated peers
To: 'Song Yongchao' , 'P2PSIP Mailing List' 

> I think most proposals agree that one client can have multiple 
> associatedpeers to keep the service continuity. The open issues are:
> 

[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.

> (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

[RRR] Yes, definitely. I guess that it is the beauty of the P2P protocol to make as reliable as one can make.
> associated peer? So the client can timely know the status of the 
> associatedpeer, 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.

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 29 Jan 2008 22:25:20 +0800

sorry for mine cutting in,

> [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 differe…
[Hui] I have different image here, there could be client involvement for this,
for example, peer could say himself being a primary, who else being a secondary
through client protocl extension, make sense?

-Hui

---

From: "Roy, Radhika R Dr CTR USA USAMC" <[email-masked]>
Date: Tue, 29 Jan 2008 10:36:37 -0500

Hi Hu:

Here is the approach how to resolve it creating some uniform principles for the peer-to-peer protocol:

1. From P2P protocol point of view, there should be a uniform guideline what should be the primary, secnodary, and other criteria including the choosing the clients who cannot override the decision of the Peer entities.

2. What clients would do for implementing their criteria (e.g. policy, primary peer, or others) may depend on many things for which peer to peer protocol characteristics must not change.

To answer your question, item 1 will determine this if we think this is what we want. However, it has to come from the general principles of the P2P protocol, but not from the clinet-peer protocol.

Best regards,
Radhika

----- Original Message -----
From: Hui Deng 
Date: Tuesday, January 29, 2008 9:25
Subject: Re: RE: [P2PSIP] Open issues with client has multiple associated peers
To: "Roy, Radhika R Dr CTR USA USAMC" 
Cc: Song Yongchao , P2PSIP Mailing List 

> 2008/1/29, Roy, Radhika R Dr CTR USA USAMC 
> :> Please see my inputs inline [RRR]
> >
> > [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.

---

From: "Hui Deng" <[email-masked]>
Date: Tue, 29 Jan 2008 23:49:59 +0800

Hi, Radhika,

Thanks for your clarification.
I guess that from what you described below is that there exist the
concept of primary, secondary, et al. I will be happy if it is true.

Regarding to uniform principles, you listed peer side and client side,
you could enforce that uniform principle in peer side will dominate, but
I can't see why we stop Client having his own vision of the world.

thanks again.

-Hui

---

From: Song Yongchao <[email-masked]>
Date: Wed, 30 Jan 2008 10:37:23 +0800

See inline [Song].

> -----Original Message-----
> From: Roy, Radhika R Dr CTR USA USAMC [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2008 10:17 PM
> [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?

> [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.

> > 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?

---

From: Song Yongchao <[email-masked]>
Date: Wed, 30 Jan 2008 11:29:13 +0800

> From: Hui Deng [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2008 11:50 PM
 
> > Here is the approach how to resolve it creating some uniform principles
for
> the peer-to-peer protocol:
> >
> > 1. From P2P protocol point of view, there should be a uniform guideline
what
> should be the primary, secnodary, and other criteria including the
choosing
> the clients who cannot override the decision of the Peer entities.

[Song] Do you mean that the guideline and criteria should be included in the
P2P protocol, and the details are left to the implementation?

> > 2. What clients would do for implementing their criteria (e.g. policy,
primary
> peer, or others) may depend on many things for which peer to peer protocol
> characteristics must not change.

[Song] I am sure the criteria will not change peer protocol characteristics.
However, p2p protocol should provide communication method between clients
and associated peers to implement their criteria if needed.

> > To answer your question, item 1 will determine this if we think this is
what
> we want. However, it has to come from the general principles of the P2P
protocol,
> but not from the clinet-peer protocol.

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