Subject: (multi6) control / load balancing of ingress traffic.

From: "Michel Py" <[email-masked]>
Date: Tue, 8 Jan 2002 21:53:55 -0800

Masataka and Tony,

> Masataka Ohta wrote:
> Assume that a site is connected to ISP A and B.
> If the site negotiate with ISP A and B individually, egress routing
> is fully controlled by the site.

Not necessarily, see below. Or maybe, this might be true as of today
but the multihoming solution we want for IPv6 is not what we have
today for v4.

> Otherwise, ISP A and B must cooperate for the welfare of the site
> even if they are hostile competiters.

Not necessarily either, see below.

>>>> Tony Hain wrote:
>>>> The other point is that for inbound load balancing, the receiving
site
>>>> only has control as long as it does not conflict with origin site
>>>> policy, or the topology is deep enough that an intermediary
abstracts
>>>> out the differences.
>>> Masataka Ohta wrote:
>>> Again, I agree with you.
>> Michel Py wrote:
>> I disagree with both of you here as well. The receiving site does not
>> have much control over the traffic it receives, but let's not forget
>> that a solution includes BOTH the sender and the receiver, which
means
>> that indeed inbound load balancing can be controlled, not by the
receiver
>> but by the sender.

> Tony Hain wrote:
> This makes no sense.

See below if it does.

> Masataka Ohta wrote:
> Are you saying "EITHER"?

Yes, see just below.

Let me try to explain this.
- Site S is multihomed to providers A,B and C.
- Site S has received aggregatable PA addresses from all three
providers.
- The multihoming solution is a multi-address one, which means that each
host on site S has several addresses, one for each provider and possibly
a PI address as well.
- In the cloud, during the transport of the packet, one of the PA
addresses
is going to be used. This effectively assures load balancing among the
different providers by the choice of the destination address by the
source.
- So, the provider used at the destination is controlled by the source
when
the multihoming protocol chooses among the different possible
destinations.
- If that multihoming protocol bases its decisions on info provided by
the
destination, you can truly says that the destination controls its own
ingress traffic. DESTINATION ADDRESS SELECTION is the key here, not
routing.

So, the ingress traffic to a given site can be controlled by the source,
or by the destination site itself if if the multihoming protocol feeds
the source with the correct info, or by both.

Note that my model calls for selection of the path by the destination,
in most cases, which is, indeed, load balancing for ingress traffic.

Tony, this is not a routing decision but a destination address
selection decision.

> Tony Hain wrote:
> I am sorry, but there is no way I am going to allow a destination site
to
> dictate that I send my traffic over my highest cost path.

I am sorry to say it, but there is nothing you can do about that. If
the host or router on your site picks a PA address that goes over
your highest cost path, though.

> It is unfortunate that BGP has fostered the complete fantasy that a
site
> can control the traffic towards itself. The holder of the packet is
always
> in control of where it gets sent, and that is true for each hop along
the
> path.

As of today, it is a fantasy because hosts have only one address. In a
multi-address multihoming scenario, this becomes true. Christian,
correct
me if I'm wrong, but your draft is all about host selection among
multiple
possible choices.
Like it or not, part of the multihoming solution is a multiple PA
address
without a PI that this company in Redmond, WA and some other people are
working on.

Bottom line is: multiple-address solutions do not give a hoot to
routing.
I don't like the idea because of the added complexity, but multi-address
solutions are, IMHO, unavoidable especially dealing with the kind of
scalability that multihomes cable and DSL personal setups.

The point I am trying to make here is that we collectively need to
unlearn
the fact that a host has only one address that does not change.

> Masataka Ohta wrote:
> "very" is not a proper wording to discuss scalability.
> "very scalable" = "poorly scalable"

My english is not very scalable, I'm afraid :-)

>> Gentlemen,
> I'm not. I'm not a lady, either. :-)

Hehe. Looks like me. I am fully reassured, now.

Michel.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 9 Jan 2002 10:11:46 -0800

> but the multihoming solution we want for IPv6 is not what we have

I get the impression from comments on the list that there are different
opinions on what the goal is. Some people want exactly what they have
today, some people want a network / centrally managed approach, some
people want a host / distributed approach, and others want a mix of the
above. The current requirements draft tries to give each group what they
want, even though the totally network centric and the totally host
centric approaches are mutually exclusive. Until we have agreement on
what we want for an IPv6 solution, no progress will be made.

> ingress traffic. DESTINATION ADDRESS SELECTION is the key here, not

Are you proposing to tie the DNS response to a system which keeps track
of probable paths from the current requestor and current load
distribution policy so the source can only pick the destination address
you want??? In any case routing is part of the key, and destination
address only plays a role for those parts of the infrastructure that
route on that rather than a default. If a source site defaults to a
particular ISP which the destination is also connected to, there is
nothing in the destination address selection that will change the way
traffic flows.

> without a PI that this company in Redmond, WA and some other

I happen to be one of the people that believes that host address
selection is part of the answer to the long term problem. That does not
mean that a destination site can micro-manage its incoming load
balancing though, unless there is a connection to the DNS response which
limits the sources choices to current load balancing policy and the
concept of a default route is completely removed from the system.

> Bottom line is: multiple-address solutions do not give a hoot to

Yes they do, they are just a mechanism to try and 'best-guess' what the
routing system will be doing. While it is possible for policy to say
select from any available address, most implementations will default to
longest matching between available source and available destination
addresses, because that approach is most likely to take the shortest
path through the infrastructure. In any case once the packet leaves the
host it is the routing system that determines the packet path, not
address selection.

Maybe the problem is the assumption that a single approach can be found
for very different functional requirements. If a site multi-homes for
resiliency, host based address selection approaches are appropriate,
while if a site multi-homes with the intent of micro-managed load
balancing, those are inappropriate and route injection mechanisms make
more sense (but I still maintain that a destination has limited control
over the absolute path).

Tony

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 11 Jan 2002 09:06:06 +0859 ()

Michel;

> ingress traffic. DESTINATION ADDRESS SELECTION is the key here, not

Looking at your proposal, I feel we should add one more
requirement that:

	A proposal must be for large scale policy rich Internet with
	highly assymmetric routing.

	Namely, routing informaion at a source gives no information
	or hint about how or whether the source can be reached from
	destination.

							Masataka Ohta