Re: ASAP Handle Resolution Option

--===============1717914621==
Content-Type: multipart/signed;
  boundary="nextPart2093286.l2gIzlP7cF";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

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

On Mittwoch 19 November 2008, Dirk Hoffstadt wrote:
> Dear all,
>
> What about the draft draft-dreibholz-rserpool-asap-hropt-03
> (http://tools.ietf.org/html/draft-dreibholz-rserpool-asap-hropt-03) on
> the ASAP Handle Resolution option to specify the requested number of PE
> entries to be selected? I think this is a quite useful extension and
> should also be moved forward.
>
> In our deployed RSerPool pool for SimProcTC, we do not need the PU-side
> handle resolution cache. Therefore, on a handle resolution, the ENRP
> server should exactly select one PE entry for the SimProcTC PU. ASAP as
> defined in RFC 5352 lacks of the possibility to specify this. The handle
> resolution option allows the PU to exactly tell this information to the
> ENRP server. So, the ENRP  server can exactly select the one PE entry
> for our SimProcPC PU -- while it can provide more entries to PUs
> actually making use of the PU-side cache. I see a clear need for
> standardization of such an option, since its functionality is IMHO
> mandatory for efficient handle resolution.

Dear Dirk,

yes, this option is indeed really useful and I also think it is mandatory f=
or=20
efficient RSerPool deployment (and therefore, RSPLIB has it built-in, of=20
course).

I did some intensive analysis and performance optimization research on the=
=20
RSerPool handlespace management. The results of this work can be found in t=
he=20
journal article "An Evalulation of the Pool Maintenance Overhead in Reliabl=
e=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 .

In summary: if the ENRP server has no knowledge on how many PE entries to=20
select upon a PU's request, it will use an - usually - too high fixed=20
setting. In my experience, the PU-side cache is mostly not used (i.e. only =
1=20
PE entry is needed by the PU) to use the most accurate PE state for adaptiv=
e=20
policies. But setting the default to 1, it would make the PU-cache useless.=
=20
Therefore, if any of the PUs makes use of its cache, an ENRP server's setti=
ng=20
must be larger than 1. This implies significant inefficiency for handle=20
resolutions by PUs needing only one entry (waste of ENRP server CPU time an=
d=20
waste of bandwidth). This problem will be overcome by the usage of the hand=
le=20
resolution option, which lets the PU specify its desired number of PE=20
entries.


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

--nextPart2093286.l2gIzlP7cF
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)

iD8DBQBJJCAF32BbsHYPLWURAjs2AJ9yq46znJ7ValwBcbgiYqoV+9t5ggCdFyLS
wyGscj2bQS5ZGRePGibJM9E=
=6PF6
-----END PGP SIGNATURE-----

--nextPart2093286.l2gIzlP7cF--

--===============1717914621==
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

--===============1717914621==--