Re: ASAP Handle Resolution Option

--===============1824144819==
Content-Type: multipart/signed;
  boundary="nextPart5231919.Ess5pXQa3c";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart5231919.Ess5pXQa3c
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 requir=
e=20
only 1 PE entry and other PUs in the pool requiring up to 100, the setting=
=20
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=20
processing power and network bandwidth. In summary, it is very inefficient.=
=20
=46or details, see the performance evaluation in the journal article "An=20
Evalulation of the Pool Maintenance Overhead in Reliable=20
Server Pooling Systems", which has been published in the International=20
Journal of Hybrid Information Technology (IJHIT), Volume 1, Number 2, April=
=20
2008. This article is available online here:=20
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. For a useful deployment of RSerPool, =
I=20
see this option as being absolutely necessary. Therefore, and since there a=
re=20
multiple implementations and people are starting to actually use RSerPool, =
I=20
see the need for this document to also become RFC. This will avoid=20
incompatibilities among implementations.


Best regards
=2D-=20
=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
=2D----------------------------------------------------------------------
 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

--nextPart5231919.Ess5pXQa3c
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBJJSKT32BbsHYPLWURApOOAKCbFNNmvRLx0079DluuntCqy9vG6QCgxlVZ
DyEEc1lPJoGnMND9sG8/jgo=
=x6GS
-----END PGP SIGNATURE-----

--nextPart5231919.Ess5pXQa3c--

--===============1824144819==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1824144819==--