Subject: RE: IPv6 Src/Dst Address Pairing

From: Richard Draves <[email-masked]>
Date: Tue, 10 Aug 1999 09:17:50 -0700

> >About destination address ordering, to reiterate a point - 
> we are talking
> >about just changing the order in which getipnodebyname 
> returns addresses. So
> >this is just an implementation change, it involves no 
> changes to the API or
> >to applications.
> 
> Yes per Brian and my discussion it does if you use the workaround
> discussed, but not as the API works today.  

I don't understand this comment... The way the API works today, it returns a
list of addresses. This would not change. Applications would not change.

> ...  In fact there is an issue with 
> keeping the cache
> updated, and from what I know of most OS's mapping upward from kernel
> space to user space is more of a trick than the reverse.  It will have
> to read via an ioctl type call.
> 
> And the other issues I stated when a net utility changes the src
> addresses and the cache you speak of has not been updated.  

To review - we are talking about the getipnodebyname() implementation
caching in its user-level data structures some information about the node's
source addresses. I think cache update is very easy, just refresh the cache
if it is more than a second stale. If the node's addresses should happen to
change in that second, so what. The worst that can happen is that
getipnodebyname() briefly returns some addresses in one order instead of
another order. This is inconsequential compared to the coarse TTL
invalidation used by DNS name resolution.

The suggestion of mapping kernel memory was just an aside, dealing with how
to implement a fast get-current-time operation. Most operating systems have
a fast get-current-time operation that does not make a system call, and
often the underlying trick involves mapped memory. But that's an aside.

> Also another
> statement from your draft applies here:
> 
>    The rules specified in this document MUST NOT be construed to
>    override an application or upper-layer's explicit choice of source
>    address.
> 
> This blows away the entire idea to send the dst addresses in a sorted
> order if the src selected by the application choice of the source
> address is not the same as the one that would have been 
> selected by the
> kernel mode.

Yes certainly, if the application specifies a "bad" source address there's
nothing the implementation can do about it. However in my experience, most
applications do not specify a source address. Off hand, I think none of the
applications we have ported to v6 specify a source address.

> If the overhead is 2 seconds it is to much.  This has to be 
> measured and
> I will not guess what it is and then as I just told Brian when 1000
> getipnodenames are called from 1000 threads on a server each 
> of them may
> have to deal with this process and that needs to be checked too.
> Also don't forget the extra load, store, compare for each 
> address coming
> back from DNS this has a cost in the overhead too.

Suppose some busy process is doing 1000s of getipnodebynames. Then with the
caching that I suggest, there would be at most one extra system call per
second. This is negligible overhead. The cost of some compares/sorting would
also be negligible compared to the rest of the getipnodebyname overhead.

Rich
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 14:02:49 -0400

>list of addresses. This would not change. Applications would not change.

When I say API I am including the implementation behind the API and that
has to change, I agree the hostent structure is left unaltered.

Also there is another issue here.  BIND as a DNS implementation will
based on a config switch round robin the addresses returned based on
load balancing.  If the addresses are re-ordered then this breaks what
BIND has done.  I am just pointing this out.

>invalidation used by DNS name resolution.

DNS name resolution exists today and is done.  This is new
work and added complexity to host software to support multihoming.
The TTL argument above is a red herring and not relevant IMO.

>often the underlying trick involves mapped memory. But that's an aside.

Excuse me.  But the above is irrelevant too.  Mapping cache and getting
times are two different things all together.

>applications we have ported to v6 specify a source address.

So what that does not change the case when it happens. 
Maybe you have not ported enough applications.

>also be negligible compared to the rest of the getipnodebyname overhead.

I don't buy the caching you suggest but do agree that if I were to store
the results and then refresh in some manner it would reduce the overhead
for multiple accesses to locate the source addresses.  But the operation
still must be peformed N times.  

In the scheme of everything that happens with the implementation of
getipnodebyname such a new feature is negligible, but it adds additonal
work for the host and another place we have to support and it will cost
us money to do it.  Also another place we need to verify performance
issues.

Also I don't think prototype or research when I am working on this stuff
but product quality and product affect for IPv6.  

/jim

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Aug 1999 23:08:53 -0400

Rich,

Per mapping cache from kernel space to user space.  Not obvious to me
with a little checking.  But I will talk with our VM folks.
Vacation is playing havoc around here until September though and in the
IETF I am noticing.  I will be splitting myself soon for a bit.

p.s. If I were King we all would be using more of the features from CMUs
MACH 4.0 via R. Rachid.  This would be almost a no-brainer then in the
OS.

/jim