Re: About NAROS

[Cedric de Launois <delaunois@info.ucl.ac.be>]

Le mer 25/06/2003 à 17:57, marcelo bagnulo a écrit :
> Ok. I guess that the response of the NAROS server could be used for
> adding an entry to the Policy table of the default address selections
> algorithm. So when a response from the NAROS server is obtained linking
> a given destination address (DA) with a source address (SA), the host
> can include an additional entry to the policy table with DA and SA and
> the same label. In this way, next packets for this DA will obtain a
> matching label and the default address selection algorithm can return a
> source address for DA.

You got the idea. A NAROS client can process a NAROS response by simply
filling the Policy table of the default address selections algorithm.
Moreover, if an API is available to manage this policy table, 
(and according to RFC3484, it should) then the NAROS client-side part
can be easily implemented in user-level.

I am already thinking about possible extensions to NAROS. One idea is to
add an option in a NAROS request to specify the type of service desired.
For example, a host could ask the NAROS server which is the best
link for video-conferencing or VoIP. The NAROS server could then reply
so that the fastest link with the lowest delay is used.


> > > An alternative option would be to define a new dhcp option to configure
> > > the policy table, so that when the hosts boots it obtains the policy
> > > table configuration from the dhcp server. The problem with this solution
> > > would be if the policy table is too large or too dynamic, in which case,
> > > i guess that using NAROS would provide better performance. Another
> > > option would be to use the NAROS server a single point for specifying
> > > policy and that the dhcp server obtain the policy table configuration
> > > from it. Have you considered any of these options?
> > 
> > Our starting point is quite different : we require TE capabilities.
> > So we need a system which can dynamically adapt to the situation
> > (failure, load unbalance, etc.). And the policy table seems to be both
> > too large and too dynamic for DHCP.
> 
> I am not sure of this. I guess this really depends on the case you are
> considering.
> 
> First of all, failure issues will have to be addressed by other means,
> because only the end hosts can perform the e2e path failure detection.

Agree again. The NAROS only gives hints about which addresses to use.
NAROS is used when the host has no information to choose between 
two or more addresses otherwise equivalents.
If a host knows (e.g. by a e2e path failure detection) that only 2 of
its 3 allocated addresses can be used to reach the destination, then the
host is free to asks the server to choose between the two remaining
addresses. This is also why a client must always put in the NAROS
request the source addresses it is willing to use.

> Then, about the policy table dynamics. I guess there may be site whose
> policy change very fast, but i would say that there are sites that have
> a somehow stable policy, that does not change everyday, so configuring
> the policy when the hosts boots (using dhcp) would be acceptable.

This is a solution if you prefer extending DHCP instead of
implementing the NAROS client. However, if a host is NAROS-aware,
it can automatically get the full content of the [small] policy
table by initiating connections using NAROS. We can simply put a large
lifetime in the NAROS response.

An advantage I see from the use of NAROS is that a host gets only the
part of the policy table it is interested in. If you use DHCP, you'll
have to transmit the full table. And maybe, only the half of this table
is useful for the host.

> About the size of the table, i would like to have more information about
> this. I mean some large site may have a very complex policy that has to
> be expressed in a way that can not be stored in hosts, but for these
> very large sites, would a multi-address solution be acceptable? I would
> say no, considering some comments made in this list.

Two parameters can be used to limit the number of NAROS requests while
keeping the number of entries in the hosts reasonable.
In the evaluation in
  http://www.info.ucl.ac.be/people/delaunoi/naros/
We show that if one policy is associated with each BGP prefix (i.e.
there are more than 100000 potential policy rules) and that
the lifetime used is 300s, then 90% of the hosts issue less than about
300 requests during the whole day. The resulting server load essentially
follows the traffic load and its average is 35 requests per second, for
a site with more than 7500 active hosts. The cache size remained below
100 entries during the whole day for 95% of the hosts.

Note that this evaluation is nearly a worst case : no filtering in
the site, lots of active p2p hosts, attacks from the web (port scans...)
factors that contribute to stress the NAROS system.

> So, as i see it, very large sites may have complex policies that require
> a very high dynamic and a lot of space to store it, but i am not sure
> whether these sites will use a multi-address solution.
> OTOH, sites that could use multi-address solutions are more medium small
> sites, which i am not sure if they have such complex policies.

You forget that we are using "dynamic policies" to perform traffic
engineering. And even small sites could need load-balancing.
However, I also think that other solutions can be imagined to perform
basic load-balancing for tiny multihomed sites (e.g. using policy
routing and/or router advertisement messages to tell the hosts how they
should balance the traffic...)

> In brief, i am just saying that i wouldn't discard dhcp yet, i think
> that both NAROS and dhcp could be used to configure the default address
> selection policy table. 

Ok. I'll be happy to discuss this point with you at the IETF meeting.

> I think that a mechanism for configuring the
> policy table other than manual will be needed.  

Agree.

Regards,

Cédric