On Thu, 18 Jan 2001 [EMAIL PROTECTED] 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 PROTECTED]
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 PROTECTED]
--------------------------------------------------------------------
