Re: ASAP Name Resolution

Hi, Thomas,

Similar suggestions were made in the past but no consensus was reached. Part of the reason 
was that (if I remember it right), on the surface this is a simple change that is not hard 
to implement, but there are some fundamental implications to the current load balancing, 
redundancy/failover models. For example, how the NS is going to select the 1 or 2 PEs from 
the 100 PEs in the pool? What algorithm NS should use? How will this algorithm work with 
(instead of against) the load balance and redundancy policy of the pool? How will it work 
with (instead of against) the failover rules at the PU? Your intention is to save some CPU 
cycle at the NS. But you may end up with burning much more NS CPU cycles if this selection 
algorithm brings substantial implementation and processing complexity to the NS.

We can discuss about this more at the meeting.

regards,
-Qiaobing

Thomas Dreibholz wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear all,
> 
> for the ASAP NAME_RESOLUTION message, it would be useful if a PU could specify 
> an upper limit on how many PE entries the NS should reply. Consider an 
> example having a pool of 100 PEs. When a PU requires only one or two PEs as 
> answer to its name resolution, it does not make any sense to reply more. This 
> only wastes CPU cylces at the NS (selecting too many PEs from the pool) and 
> bandwidth.
> 
> Proposed NAME_RESOLUTION message definition:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   Type = 0x5  |0|0|0|0|0|0|0|0|        Message Length         |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Max Name Resolution Items    |           (unused)            |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    :                     Pool Handle Parameter                     :
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Max Name Resolution Items: 16 bit
> 
>     The NS SHOULD not reply more Pool Element Parameters in its
>     response than specified here.
> 
> 
> Best regards
> - -- 
> =======================================================================
>  Dipl.-Inform. Thomas Dreibholz
> 
>  University of Essen,                            Room ES210
>  Inst. for Experimental Mathematics              Ellernstraße 29
>  Computer Networking Technology Group            D-45326 Essen/Germany
> - -----------------------------------------------------------------------
>  E-Mail:     [email protected]
>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
> =======================================================================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFBAMQ632BbsHYPLWURAkdSAJ96SlMvte2+807W2HWLmXoiOEZ4uACfULJ+
> LcKxj3MEMNZm7szK7Rjdr+s=
> =0Spz
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> rserpool mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rserpool
>