Re: ASAP Handle Resolution Option
Dirk Hoffstadt <[email protected]> Thu, 20 Nov 2008 15:03:44 +0100
| Newsgroups | gmane.ietf.rserpool |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Dreibholz schrieb: > 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 ENRP > 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 > processing power it needs to select e.g. 100 PEs when e.g. actually only 1 > entry is really required. Why should the ENRP server need significantly more > CPU resources than necessary when it is so easy to fix this problem? The > handle resolution option is really simple (just 8 bytes containing a single > entry) and successfully fixes this problem. With a few lines of > implementation code, a significant performance gain can be achieved. Yes, I fully agree to that. The solution to solve the "number of PE entries to be selected" problem by the handle resolution option is really simple. Wasting resources should really be avoided, since this reduces deployment costs. - -- Best regards, Dirk Hoffstadt - ------------------------------------------------------------------ M.Sc. Dirk Hoffstadt DH Datentechnik 45219 Essen Germany E-Mail: [email protected] Internet: http://www.dhdt.de PGP-PublicKey: https://dhdt.de/private/dirkhoffstadt_pubpgp.asc - ------------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJJJW4/AAoJEAl0PP0XKTexStEIANm2uhUn0JHwHNg9xIBelyHV niqhi0zBOsiy36JtoanDLMgFLNd/uzGDBdViX/OLMJFSCuHmEXD3pjA6/avCzY0r qL6rHb5pr2yfq6ALqzpQ9yODUFdWH55XSWDQH3aIRhoD74n0L5NvuHHz7g9BNjv5 uWAiRAL1ljyWfsX6kbaE2iSpwVfg4RUPDCCcgsUcKoPxKR1Y9XFylc97ORWjYz7J hH2DkYApT5qIURnp7SU7FIeXRBb0ftXnZlqOdt6oQm4c9dTuojNeZr2XTpEnbQjz nMGBk7LmS/4beb2PdQPMl//VjCKh9FrzS4sZWYq0jEc9yCGuJQhg+R+/Qc3EM7g= =f1/2 -----END PGP SIGNATURE-----