Re: ASAP Handle Resolution Option

Thomas Dreibholz schrieb:
> On Mittwoch 19 November 2008, Randy Stewart wrote:
>> Magnus:
>>
>> I really don't understand the usefulness of this extension.
>>
>> What it does, in a nut shell, is allow the PU requester to
>> limit the number of responses he is getting...
>>
>> This can easily be done by:
>>   - configuring the ENRP server to limit the number of responses
> 
> Dear Randy,
> 
> this does not work for all pools. If there are PUs in the pool which require 
> only 1 PE entry and other PUs in the pool requiring up to 100, the setting 
> has to be 100.
> 
> 
>>   - configuring the requesting PU side to discard all but the number
>>     that he wants.
> 
> Then, the ENRP has to unnecessarily select entries, which wastes a lot of 
> processing power and network bandwidth. In summary, it is very inefficient. 
> For details, see the performance evaluation in the journal article "An 
> Evalulation of the Pool Maintenance Overhead in Reliable 
> Server Pooling Systems", which has been published in the International 
> Journal of Hybrid Information Technology (IJHIT), Volume 1, Number 2, April 
> 2008. This article is available online here: 
> http://www.sersc.org/journals/IJHIT/vol1_no2_2008/2%20pp%2017-32.pdf .

Dear Thomas, Randy,

Yes, this is exactly the point I mentioned in my mail yesterday. Such an
option is definitively necessary for efficient RSerPool deployment.



>> Either way works without changes to the protocol.
> 
> It works, but it is very inefficient. For a useful deployment of RSerPool, I 
> see this option as being absolutely necessary. Therefore, and since there are 
> multiple implementations and people are starting to actually use RSerPool, I 
> see the need for this document to also become RFC. This will avoid 
> incompatibilities among implementations.

I fully agree to this point. Without a standardized definition of this
option, each implementor/vendor will sooner or later add such a
functionality to provide efficient PE selection. This will cause
incompatibilities, which must be avoided.


-- 
Best regards,
Dirk Hoffstadt
------------------------------------------------------------------
M.Sc. Dirk Hoffstadt
DH Datentechnik
45219 Essen Germany
E-Mail: [email protected]
Internet: http://www.dhdt.de PGP-PublicKey:
https://dhdt.de/private/dirkhoffstadt_pubpgp.asc
------------------------------------------------------------------