Subject: [P2PSIP] new draft submissions for client promotion and one-hop algorithm

From: 邓灵莉/denglingli <[email-masked]>
Date: Fri, 8 Jul 2011 09:35:16 +0800

Dear all,

A draft is newly submitted, which proposes extensions to RELOAD to support
flexible client promotion and demotion modes. RELOAD aims at providing a
uniform protocol for both overlay clients and peers, where promotion of a
client to peer is triggered and completed at the client's pleasure. It is
proposed that RELOAD provide a more restrictive framework to enable passive
promotion and demotion, where decisions are made by the network rather than
individual user-owned nodes.

The mentioned submission entitled can be accessed at
http://datatracker.ietf.org/doc/draft-peng-p2psip-promotion/ 

Another submission for one-hop algorithm as an alternative for chord-reload
is also available and be welcome for comments:

http://datatracker.ietf.org/doc/draft-peng-p2psip-one-hop-plugin/  

Any comments are highly appreciated.

BR

Lingli Deng

---

From: Bruce Lowekamp <[email-masked]>
Date: Thu, 7 Jul 2011 22:28:07 -0400

Thanks for submitting the drafts.  A quick question on the promotion
draft.  Could this be implemented as a topology plugin?  The base
draft has always been vague on selecting peers vs clients, mostly in
hope that future extensions or topology plugins could implement their
own methods for peer promotion, etc.

Bruce

2011/7/7 邓灵莉/denglingli <[email-masked]>:
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>

---

From: 邓灵莉/denglingli <[email-masked]>
Date: Fri, 8 Jul 2011 10:50:12 +0800

Thank you Bruce.

Yes, we have noticed that and agree that the decision of peer promotion is basically dependent on the specific overlay algorithm. However, some general issues need to be addressed outside TP in order to enable such procedure, for instance:
o Who triggers the passive procedure? Either triggered independently by a single (e.g. overloading) peer; or triggered globally by the centralized overlay administration.
o How to collect candidate stats to make an informed decision? Either collected by self-reports; or involving kind of mutual evaluation.
o How to choose from qualified candidates? Randomly selected, or locally optimized, or even globally optimized choice.

Different answers to the above questions compose different practical solutions. However, RELOAD only needs to provide generic messaging interaction to support them. Above all, separate authorizations for peers and clients may be needed as well.

As an initial step, we may describe an illustrative scenario and discuss potential extensions to RELOAD in order to support it.
In our example, the passive client promotion procedure is triggered locally by an overloading peer. Candidacy collection is achieved by ProbeReq/Res messages, where the overloading peer seeks help from its directly connected clients through specially marked ProbeReq messages and interested clients binds its state report and peer certificate with ProbeRes. Promotion decision is made locally by the overloading peer and the selected client gets and explicit delegation signed by the local decision maker, where a new type of message would be employed. The selected client may initialize the normal peer joining procedure afterwards, where relevant JoinReq is accompanied by the correspondent signed delegation.

BR 
Lingli

-----邮件原件-----
发件人: Bruce Lowekamp [mailto:[email-masked]] 
发送时间: 2011年7月8日 10:28
收件人: 邓灵莉/denglingli
抄送: [email-masked]
主题: Re: [P2PSIP] new draft submissions for client promotion and one-hop algorithm

Thanks for submitting the drafts.  A quick question on the promotion draft.  Could this be implemented as a topology plugin?  The base draft has always been vague on selecting peers vs clients, mostly in hope that future extensions or topology plugins could implement their own methods for peer promotion, etc.

Bruce

2011/7/7 邓灵莉/denglingli <[email-masked]>:
>
>
> Dear all,
>
>
>
> A draft is newly submitted, which proposes extensions to RELOAD to 
> support flexible client promotion and demotion modes. RELOAD aims at 
> providing a uniform protocol for both overlay clients and peers, where 
> promotion of a client to peer is triggered and completed at the 
> client's pleasure. It is proposed that RELOAD provide a more 
> restrictive framework to enable passive promotion and demotion, where 
> decisions are made by the network rather than individual user-owned nodes.
>
>
>
> Another submission for one-hop algorithm as an alternative for 
> chord-reload is also available and be welcome for comments:
>

__________ Information from ESET NOD32 Antivirus, version of virus signature database 6268 (20110705) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com