Subject: src addr sel (was: A6 unreliability) (fwd)

From: Mauro Tortonesi <[email-masked]>
Date: Sat, 20 Jan 2001 20:14:12 -0500 (EST)

On Thu, 18 Jan 2001 [email-masked] wrote:

> Also go look at the source address selection stuff where we now have kernel
> and user space hacking dns abstract types back and forth.  Another case of 
> excessive engineering insanity and architecture without consideration
> for performance.
> Its good work as a spec but I have my doubts about what it will do to the
> performance of end system **production** running code. 

i think that you are just right. such a complex stuff like source address
selection cannot be implemented in an easy way. this is from
draft-ietf-ipngwg-default-addr-select-02:

   The destination address selection algorithm needs information about
   potential source addresses. One possible implementation strategy is
   for getipnodebyname() and getaddrinfo() to call down to the IPv6
   network layer with a list of destination addresses, sort the list in
   the network layer with full current knowledge of available source
   addresses, and return the sorted list to getipnodebyname() or
   getaddrinfo(). This is simple and gives the best results but it
   introduces the overhead of another system call. One way to reduce
   this overhead is to cache the sorted address list in the resolver,
   so that subsequent calls for the same name do not need to resort the
   list.
 
imho this is not so simple to implement. it requires a tight coupling
between the network layer (kernel space) and the networking stuff of 
the C library (user space), and a very careful design of the caching
policy (especially if we have to handle temporary, preferred and
deprecated addresses). 

   Another implementation strategy is to call down to the network layer
   to retrieve source address information and then sort the list of
   addresses directly in the context of getipnodebyname() or
   getaddrinfo(). To reduce overhead in this approach, the source
   address information can be cached, amortizing the overhead of
   retrieving it across multiple calls to getipnodebyname() and
   getaddrinfo(). 

this is a simpler solution, as it requires only a minor interaction
between kernel- and user-space. but the complexity of the caching
algorithm is not reduced, and this implementation introduces another
problem:

   In this approach, the implementation may not have
   knowledge of the outgoing interface for each destination, so it MAY
   use a looser definition of the candidate set during destination
   address ordering.

and this is surely a negative point.
moreover, there are lots of other problems to be solved. in particular:

 1) performance. it cannot be allowed by using cached data, as caching
    is very difficult to do. and the spec says:

   In any case, if the implementation uses cached and possibly stale
   information in its implementation of destination address selection,
   or if the ordering of a cached list of destination addresses is
   possibly stale, then it should ensure that the destination address
   ordering returned to the application is no more than one second out
   of date. For example, an implementation might make a system call to
   check if any routing table entries or source address assignments
   that might affect these algorithms have changed.

    because cached data is valid for no more than 1 sec., and the
    implementation of a correct caching algorithm is VERY difficult, 
    caching is more a problem than a solution.

 2) handling the policy table. it should be kept in kernel-space, but 
    designing a simple and safe way to edit it is surely not a trivial
    task.

i wonder if there is a working implementation of dest/src address
selection that is fully conformant to this spec. i'd really like to 
know how the implementation issues have been solved. 

-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi			[email-masked]
Ferrara Linux User Group	http://www.ferrara.linux.it
Project6 - IPv6 for Linux	http://project6.ferrara.linux.it

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------