Re: ASAP Handle Resolution Option

Hi Thomas,

I do understand that the ID is simple, but I'm not sure if this
is really necessary to have for the things that are done *NOW*
using RSerPool.

If you think you need this, you can integrate this in your
implementation and choose the higher bits such that you can
at least interoperate with implementation not supporting your
extension.

So I support Magnus position to close the WG.

Best regards
Michael

On Nov 20, 2008, at 6:50 AM, Thomas Dreibholz wrote:

> 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.
>
>
> 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
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rserpool