Re: [RRG] Are we solving the wrong problem?

[Jari Arkko <jari.arkko@piuha.net>]

Scott,

>> But it also makes the routing system more expensive, because it has to
>> maintain a lot of information. Many of the RRG people are searching for
>> a better organization of this information so that its maintenance would
>> be cheaper -- but you are actually looking at removing some of this
>> information. I guess the main question is, can we substantially reduce
>> the costs of the routing system while keeping the same amount of
>> information and functionality in it? I'm not sure I know the answer yet.
>
> The problem, as usual, is all the policy stuff, e.g. the various kinds
> of traffic engineering.  I do not see that adding capability to
> endpoints will reduce what you have to do at the border router
> significantly.  In Mark's approach the host uses multiple addresses
> intelligently but the border router still has to advertise
> reachability for them, manage what traffic takes which path, and so on.

Right. But what the border router has to do (e.g., keep two sets of
prefixes) is different from what has to happen in the core of the
Internet. In Mark's approach you would not have to push the multihoming
problem and the individual organization's prefixes to the core; it would
work with just provider aggregated addresses. So that is the cost saving
in his approach (and the costs are elsewhere...)

>> Another drawback of the hiding approach is that it might be ultimately
>> less capable, if you consider things like hosts being able to react on
>> transport layer timescales to congestion and their own communication
>> demands.
>
> Could you be more specific?  We have Mark's approach, with load
> balancing according to experienced throughput.  The only thing routing
> could do to disrupt that would be to dramatically change routing
> frequently.  Or are you thinking of "vertical coupling" approaches
> where something up at session layer can ask the network for changes in
> QoS, routing or virtual topology?  Or ... ?

I did not claim that the routing system would disrupt Mark's approach.
My point was that a host based approach might theoretically have more
information to base its decisions on than a router based design. And
hence be better.

But admittedly I was handwaving this. My rationale was that a host that
has partial topology information (set of prefixes), congestion
information, and application demand information could potentially do a
better job than the routing system which traditionally has only the
topology information and might have some amount of information about
congestion. And hosts may have information beyond a single AS, such as
when my laptop is connected to two different providers.

But of course, the devil is in the details, so its not clear that host
approach would win even in a theoretical comparison. First of all, the
routing system may have mechanisms to at least locally react much better
to congestion/load sharing than the hosts. And obviously, the routing
system knows more about the topology than hosts.

Jari



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg