[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OT] Moving "path selection" to the end hosts (was Re: On the use of multiple PA prefixes ...)



Pekka Nikander wrote:
Noel,

This starts to be off-topic for the multi6 list, but...

It is a bit, but "choose the new source/dest address pair" is one of those separable components in any multi6 solution. As in my previous message, I think we should concentrate on the interfaces between those components, since one size probably doesn't fit all, and topology maps won't appear overnight.

    Brian


Well, basically, I think we need to move the "path selection" function
out of the "network" (i.e. the routers), and let the hosts (or, if they
are lazy/stupid, an agent acting on their behalf) do it. To do this, they
obviously need more information, which I claim should be maps of network
topology.

...

Anyway, making this (admittedly major) architectural change kills about
17 dozen birds, of which the "how do I pick the best address for the
destination" is one.


... I'd like to hear what are some of these 17 dozen birds.

I'm admittedly a layman in routing, but thinking about the amount
of routing information and its stability, it appears to me that it
will anyway be necessary to provide aggregated versions of this
information at various levels.  Hence, it sounds reasonable to
assume that a host could have some better knowledge about the network
topology (and perhaps congestion state) "close" to it, but less
information, or more aggregated information, about what happens
further away.  Hence, any path selection performed by the end hosts
will be, at best, an approximation.

I could imagine that two (or a group of) communicating hosts could
jointly be able to make a fairly good approximation of the routing
state close to them, and thereby make a good selection about which
local paths to use among the available ones.  Combining this information
with upper layer RTT and bandwidth estimates, the hosts might be
able to create some kind of a local model about the traffic
characteristics of the paths, but only over time.  In the case of
site multi-homing, sharing this information with other hosts on the
site may make sense, just as a number of people have pointed out.

Based on this straw man analysis, I get the feeling that moving
path selection to the end hosts might be good because

  - the end hosts may use information from their peers to make
    better selections, and

  - the end hosts may more easily use dynamic upper layer
    congestion information to revise their choices on need

On the other hand, either network assistance or letting the network
to do the selection looks good because

  - the network may learn more from a number of end-hosts,
    thereby being able to create a more accurate model of
    the network condition

  - the network needs to have this topology information anyway,
    as we cannot expect the hosts to learn the topology without
    some help from the routers

The situation seems to be become more interesting if we assume that
there is a full blown id/loc split in place.  That would allow
the network to have more dynamic IP addresses, slowly changing the
addresses to better match the actual network topology.  Under such
conditions, it becomes an interesting exercise to figure out how
to represent the actual topology, as IP addresses cannot be directly
used to represent nodes, and identifiers are unlikely to be
directly aggregatable.

Anyway, I fail to clearly see the consequences of such a change,
i.e. moving "path selection" to end hosts, and would like to hear
more about your insights.

--Pekka Nikander