Re: ASAP Handle Resolution Option

Dear Randy,

The point is that for many applications exactly one PE should be selected
out of a pool (containing many PEs) by the pool policy. That is, there
should be a way to tell the ENRP server to just select a single entry. For
other applications, there should be the possibility to tell the PE to select
more entries (e.g. to utilize the PU cache). If there is a fixed setting of
how many PE entries to reply upon a Handle Resolution Request, this is not
optimal for many applications while it is required for others.

Since RSerPool is intended to be "lightweight", I see the need to take care
of efficiency. Therefore, it is really useful to have this handle resolution
option.

Best regards

Michael Kohnen
-- =

Dipl.-Wirt.-Inf. Michael Kohnen
 =

Lehrstuhl f=FCr Technik der Rechnernetze
Institut f=FCr Experimentelle Mathematik und Institut f=FCr Informatik und
Wirtschaftsinformatik
Universit=E4t Duisburg-Essen, Campus Essen
Ellernstr. 29
45326 Essen
 =

Telefon: +49 (201) 183-7636
Fax: +49 (201) 183-7673
E-Mail: [email protected]
Homepage: http://www.uni-due.de/tdr/

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Randy Stewart
Sent: Thursday, November 20, 2008 1:27 PM
To: Thomas Dreibholz
Cc: [email protected]; Lyndon Ong
Subject: Re: [Rserpool] 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]




_______________________________________________
rserpool mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rserpool