Subject: RE: The state of IPv6 multihoming development

From: "Michel Py" <[email-masked]>
Date: Sun, 27 Oct 2002 19:45:47 -0800

Christian,

> Christian Kuhtz wrote:
> maybe i got this all wrong, but...

You got it right. Let's keep something in mind: the kind of traffic
engineering we are talking about is egress: you have a big honkin'
server farm serving a boatload of customers wherever. The bulk of the
traffic is return traffic, let's say http traffic.

Here's the scenario: the home/soho host that is multihomed with cable
and dsl makes a choice on which of its own addresses (the cable one, or
the dsl one) to use. This choice will dictate on which pipe the return
traffic from the web server to the requesting host goes.

This is what we really are talking about here: Joe-six-pack's PC thinks
the ping to the cable default gateway is better than the ping to the dsl
default gateway and chooses its own source address to be the cable's
one.

And this, gentlemen, is *not* what I call traffic engineering.

Michel.

---

From: Peter Tattam <[email-masked]>
Date: Mon, 28 Oct 2002 15:19:42 +1100 (EST)

> And this, gentlemen, is *not* what I call traffic engineering.

And precisely the reason why I am thinking of using the flow label to collect
RTT information for each path.  The traffic engineering decisions should be
based on something a little more reaslistic thatn the size fo the various liks
or local routing policies.

Frankly I have experienced some very serious traffic engineering problems using
regular BGP with a mix of different media and suppliers. Try as I might I just
could not direct incoming traffic the way I wanted it.

There is not going to be any easy solution as to who controls traffic flow
policies.  There will always be conflicts between the sender, the receiver and
the people in between.

> Michel.

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Oct 2002 11:32:39 +0100 (CET)

> traffic from the web server to the requesting host goes.

Actually it doesn't, twice.

First of all, in order to really be multihomed, both addresses must be
viable. So if the HTTP farm decides to direct its traffic to the other
address, Joe can't really stop them, other than not advertise this
address in the first place.

Also, presumably, both of Joe's addresses are reachable over both of the
HTTP farm's uplinks. If the HTTP farm is smart enough to be able to
direct outgoing traffic depening on the traffic engineering needs rather
than simply the destination address, they can route each of Joe's
addresses over either of their uplinks as desired. And even if they
don't have this capability, it's still 50% chance that both of Joe's
addresses are routed over the same uplink so which address they use to
reach Joe doesn't matter for traffic engineering purposes.

> And this, gentlemen, is *not* what I call traffic engineering.

So what's your definition?

The Right Thing for Joe's PC would be to measure the end-to-end delay,
packet loss and bandwidth over both links and use the one that best
suits his application. However, this is complex enough to NOT solve this
at this stage. We may want to provide some hooks so people can do this
later, though.