Subject: (IPng 7447) Re: simple source address selection

From: Richard Draves <[email-masked]>
Date: Thu, 29 Apr 1999 10:16:13 -0700

> I'm not 100% sure about this limitation of scope:
> 
> >    This document does not address the more general problem 
> of choosing
> >    the "best" destination address / source address pair for
> >    communication with another node, given a set of possible 
> destination
> >    addresses and a set of possible source addresses.
> 
> It really is a trivial extension to your draft to add a recommended
> rule for choosing the pair - i.e. run your rules for choosing the
> source across all destination addresses, and pick the final pair
> with 1. the smallest scope and 2. the longest match.

Yes, we could add such an extension but I don't think it would be useful.

MSR IPv6 is never in a situation where it needs to pick a destination
address. The destination address is always specified by an application. I
believe this is also true of other implementations.

So to support this would be a pretty major architectural change to how
applications & upper layers interact with the IP layer. I would want a
solution to address other issues, like if one dst/src pair doesn't work then
being able to switch to another dst/src pair. It's certainly worth thinking
about (and I am giving it thought), but it's so much more complicated that
it should be a separate proposal.

> I have a vested interest in this as it would take the special case
> out of 6to4, but I think it's of general utility.

I don't see why 6to4 needs a special case for destination/source address
selection.

Thanks,
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: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Apr 1999 12:15:57 +0100

Richard, this has got me very worried.

If site A is multihomed, and a host at site B is sending to it, 
B should choose the topologically "best" address for site A. That
is not something an entity above the network layer can decide,
and it is not independent of the choice of source address if
site B is also multihomed. On the contrary: they are linked.

The 6to4 case is just a special case of this.

  Brian

---

From: [email-masked]
Date: Fri, 30 Apr 1999 20:31:33 +0900

>site B is also multihomed. On the contrary: they are linked.

	No.  Normally B has no idea about topology at the destination,
	and B cannot really decide which is better or worse.  For example,
	I'm from 210.160.95.97 and I cannot really choose from two
	destinations:
		204.166.18.33 or 203.141.85.90 (just a random pick)
	Basically, there's nothing sender can do.

	If both address assignment and routing structure are tree-based,
	longest match may sometimes do the trick, however, this is just a
	heurestics.  Nothing more than that.  longest match can pick wrong
	address.

>The 6to4 case is just a special case of this.

	6to4 separates IPv6 ocean into two parts: 6to4 addresses and non-6to4
	addresses.  To use optimal route, packet toward 6to4 address 
	should have 6to4 source address.
	I believe this is why 6to4 is worrying about the source address
	selection.

itojun

---

From: Robert Elz <[email-masked]>
Date: Fri, 30 Apr 1999 21:46:09 +1000

Date:        Fri, 30 Apr 1999 12:15:57 +0100
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | If site A is multihomed, and a host at site B is sending to it, 
  | B should choose the topologically "best" address for site A.

If you have a method by which this can be accomplished, please do let us know.

  | That is not something an entity above the network layer can decide,

In general we're content with an address which works, and it is essentially
always chosen by the application, not the net layer.  In general, we don't
expect the net layer of a host to (necessarily) have much more information
than a list of (its own) addresses on local links (and their netmasks) and
addresses of routers on those links.   It is hard to see how, with this
information, the net layer could be expected to deduce anything at all
about which of several destination addresses might be best under any definition
of that term.   Further, the API we have so far has no method of informing
the net layer which particular definition of best might be appropriate for
this particular packet - nor for that matter of informing the net layer that
there might in fact be alternate addresses that might be equivalent.

Further, the net layer can't even really be expected to understand that the
addresses form part of connection identifiers for some packets, and hence
can't be altered, whereas for other packets, anything that reaches the
correct host will do (initial SYN for TCP, most UDP queries, etc).

I really don't think that asking the net layer to start making destination
address choices is going to succeed, anytime in the forseeable future.

  | and it is not independent of the choice of source address if
  | site B is also multihomed. On the contrary: they are linked

This we understand, what is what Richard's draft is addressing - how to
choose a source address given a particular destination address.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Apr 1999 17:48:58 +0100

[email-masked] wrote:
> >That is how I understand IPv6 aggregatable addresses (to a first
> >approximation; as you say it has a heuristic aspect). Obviously,
> >it would be a crazy idea for IPv4.
> 
>         I agree that address assignment is somewhat like tree (TLA, NLA, ...)
>         but I don't believe that the actual routing is "tree-based".
>         You will have several thousands of TLAs on the net (hopefully),
>         and they will perform peering arrangement, route filtering, and
>         sometimes they perform packet filtering at the borders (ugg).
> 
>         If you are in TLA1, and two candidate destinations are TLA2 and TLA3,
>         you can never understand how the packet will travel from TLA1->TLA2
>         and TLA1->TLA3.

Absolutely correct. But if the prefixes match down to say /40
you know you are pretty close in the topology.

   Brian

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 30 Apr 1999 14:44:38 -0400

(note subject change).

This is a problem I butted heads with in a previous job (in a
client-server context, which shows through in my terminology).

I'll summarize the problem as:
     "given a set of <names,addresses> for different replicas of the
      same service, tell me what order to try them in".

Information relevant to how to do this is scattered throughout the
stack.

The application layer really isn't in a good position to pick among a
set of possible destinations.  You can manually configure preferences,
and keep track of recent history, but often apps aren't particularly
long-lived.

I've seen this code turn into a real swamp in some applications.  It
would be helpful if there were some semi-standard primitives out there
to help an app make these distinctions.

The network layer isn't in a much better position.  It can prefer
things based on some coarse-grained heuristics:
	- same host vs different host
        - directly connected net vs via a router
        - directly connected via fast link vs directly connected via
	  slow link

In some (LAN-oriented) applications, even this can be a big win, but
it doesn't help you pick between a server two hops away vs one twenty
hops away.

The transport layer, on the other hand (at least for TCP):
	- is relatively long-lived and can keep state.
	- knows which hosts it's already talking to, and some of the ones
it's talked to recently.
	- is measuring round trip times, so it's in a decent place to
know which replicas are more or less close, and have some idea of
which aren't responding at all..

I think this becomes more criticial with IPv6, since, what with
link-local and site-local addresses, just about everything's going to
have multiple addresses, even if they are all on a single interface.

					- Bill

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Apr 1999 15:56:14 +0100

itojun,

   Brian

---

From: [email-masked]
Date: Sat, 01 May 1999 01:16:16 +0900

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Apr 1999 15:45:04 +0100

kre,

> If you have a method by which this can be accomplished, please do let us know.

I've already suggested an algorithm: match each potential source address
against each potential destination address; choose the pairs with
smallest common scope; among those, choose the pair with longest
prefix match.

In an aggregated address space this will come very close to the
topologically best answer. And I'm only suggesting it as a default
mechanism.

> In general we're content with an address which works, 

Not true. We put up with it, but we know that it doesn't
produce least-hops routes.

> ...and it is essentially
> of that term.   

Well, maybe my suggestion above is unreasonable but it seems to me
that in an aggregated address space thing are fundamentally
different and we do have some knowledge just by looking at addresses.

> ...Further, the API we have so far has no method of informing

Indeed. The second point is bothering me.

> correct host will do (initial SYN for TCP, most UDP queries, etc).

I don't see why this is relevant - there's no reason why the
address selection would change during the lifetime of a session.
> address choices is going to succeed, anytime in the forseeable future.

So where is it specified how to choose when DNS returns multiple
addresses? If this isn't specified we don't have a chance of a
comprehensible solution for multihoming.

> choose a source address given a particular destination address.

I understand that his draft solves that problem.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Apr 1999 17:48:58 +0100

Brian

---

From: Robert Elz <[email-masked]>
Date: Sat, 01 May 1999 12:07:17 +1000

Date:        Fri, 30 Apr 1999 17:48:58 +0100
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | Absolutely correct. But if the prefixes match down to say /40
  | you know you are pretty close in the topology.

/40?  Maybe not.  /48 then yes, probably.   At least with current
address allocation plans.

But we absolutely do not want to start building any assumptions related
to prefix lengths into applications, or anywhere in hosts.  That is, I
would say that hosts MUST NOT base interface or address selection upon
any notion of specific prefix lengths (longest match is different, and OK).

In an earlier message you said ...

it shouldn't (given that addresses form connection identifiers), obviously.
But a net level address selection algorithm could easily do that, unless
the whole network environment remains static - and there are way too many
cases that are all too plausible where that would not remain true.

The obvious one is where a new link comes up during the life of an
application (or a connection), which is not at all infrequent.

Then there's mobile hosts, which will be getting new local addresses, including
new local site addresses, quite frequently potentially.

And then there's the simple case of a local prefix reassignment - the likely
case of this will have the new address starting to be advertised by the
routers (along with the old), then the DNS being updated to switch from old
to new address schemes, (and then the rest of it all).   A connection that
starts after the new addresses have been advertised (I know my new address)
but before the DNS update has filtered through (I don't know the new address
of that other guy on the adjacent hub port yet) then it is entirely possible
to imagine learning of a new (and "better") destination address during the
life of a connection.

The point is that if you leave all this to the net layer to decide, then
it doesn't really have enough information to know what addresses ought to
be being assigned, and when it is safe to start choosing new ones.

Whether the applications really ought be doing this, or whether there is some 
better choice between application and net layer I'm not sure - we only really
have much experience with the applications doing destination address selection.

kre