Re: ASAP Handle Resolution Option

--===============1952948120==
Content-Type: multipart/signed;
  boundary="nextPart13821230.KLLDdIuYfW";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

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

On Donnerstag 20 November 2008, Randy Stewart wrote:
> 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.

Dear Randy,

the idea is to configure the number on the PU. But the PU has to tell the E=
NRP=20
server how many PE entries it actually needs.


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

Bandwidth it not really the problem. The actual problem is the unnecessary=
=20
processing power it needs to select e.g. 100 PEs when e.g. actually only 1=
=20
entry is really required. Why should the ENRP server need significantly mor=
e=20
CPU resources than necessary when it is so easy to fix this problem? The=20
handle resolution option is really simple (just 8 bytes containing a single=
=20
entry) and successfully fixes this problem. With a few lines of=20
implementation code, a significant performance gain can be achieved.


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

--nextPart13821230.KLLDdIuYfW
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)

iD8DBQBJJV0J32BbsHYPLWURAvehAJ9zGzX2J7n3xuU7CShirwKeZwnzHgCeKnMJ
UnUPIhK3b8Xa3AUXiRt3DYc=
=5USJ
-----END PGP SIGNATURE-----

--nextPart13821230.KLLDdIuYfW--

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

--===============1952948120==--