Re: ASAP Handle Resolution Option

On Nov 20, 2008, at 3:40 AM, Thomas Dreibholz wrote:

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

In this case you can configure it on the PU... its not that big of deal.
Besides if you only want one response, why are you even bothering
to use RSERPOOL. Its just as easy to use either a configured
host or DNS to lookup the single guy you wish to talk to.

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

This is rather silly in my mind. B/W on a network where rserpool
is running is not going to be that much of a problem IMO. Processing
power is a moot point with multi-gig-hz machines and Gig's of memory
being the common environment. If you are not in that environment
your NOT going to have 100's of PE's so I see NO need for this.

Also your argument here is in direct conflict to the argument above.



>
> 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 .
>
>
>> Either way works without changes to the protocol.
>
> It works, but it is very inefficient.


Here I strongly disagree with you. If you have large numbers
of pools your network and processing capacity will always be
greater than if you have a small rserpool deployment. Being
one of the folks that have truly deployed rserpool back in
99 at Motorola I can tell you that we had NO problem with
either network or bandwidth. And thats not theory but
analysis of a true production system running rserpool....

We DO NOT need this IMO!

IMO I STRONGLY think the WG needs to be closed. And from
what I can see from Magnus's statement:

----
The current plan is to shutdown the WG. It has been clear for quite some
long time that the energy level is very low. I intended to keep with the
plan to shutdown the WG. I was seriously considering closing the WG
already before finishing the MIB.
----

He agrees with me... I am all for this plan... finish the MIB and close
the WG.

IF problems arise and there is significant usage in REAL production  =

networks
of rserpool that warrant updates to the documents, we can deal with that
on a "as need" basis....


R

> 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.
>
>
> Best regards
> -- =

> =3D =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Dr. Thomas Dreibholz
>
> University of Duisburg-Essen,                   Room ES210
> Inst. for Experimental Mathematics              Ellernstra=DFe 29
> Computer Networking Technology Group            D-45326 Essen/Germany
> -----------------------------------------------------------------------
> E-Mail:     [email protected]
> Homepage:   http://www.iem.uni-due.de/~dreibh
> =3D =

> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

-----
Randall Stewart
[email protected]