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