[RRG] Are we solving the wrong problem?

["Mark Handley" <M.Handley@cs.ucl.ac.uk>]

I've been mulling this around for a long time now, and I think we may
be trying to solve a number of problems at the wrong layer.

The routing problems we're trying to solve seem to stem primarily from
an inability to perform aggregation of routing information.  There are
a number of causes for this, including:

 - historical allocation policies (the swamp).
 - inappropriate information hiding in BGP.
 - multihoming.
 - traffic engineering.

The first is not a serious problem, though may become one when we run
out of IPv4 addresses.  The second is one that RRG might take a
serious look at.  I've made one attempt at this with HLP, but other
solutions are certainly possible too, even without replacing BGP.  But
the current concerns mostly seem to stem from multihoming and traffic
engineering.

I believe that if we are ever to make routing scale a great deal
better, we should not be attempting to solve these last two problems
primarily within the routing system.  Clearly if you present routing
people with a problem, we'll come up with routing solutions, but if
you take a broader view, we can probably do much much better (Frank
Kelly deserves credit for the original idea I'm going to suggest). I'm
slowly writing a more detailed document discussing what I think the
solution space should be, but I'll try and give the general idea with
the simple example of a site that is dual homed to two ISPs.

Current practice attempts to hide this dual homing behind a single IP
address for each host.  This then requires a long prefix to be
advertised via both ISPs, with appropriate AS prepending to balance
traffic.  If either edge-link goes down, on average half the Internet
gets to process the routing update.  Worse, this doesn't do a great
job of load balancing, so prefix splitting is sometimes performed to
better balance load, resulting in even more stress to the global
routing system.  In short, attempts at improving local robustness
create global stresses, and potentially global fragility, which is the
problem we're all concerned with.

So, what happens if we stop trying to hide the multihoming.  Take a
server at this multi-homed site and give it two IP addresses, one from
each provider's aggregated prefix.  Now we modify TCP to use both
addresses *simultaneously* - this isn't the same as SCTP, which
switches between the two.  The client sets up a connection to one
address, but in the handshake learns about the other address too.  Now
it runs two congestion control loops, one with each of the server's IP
addresses.  Packets are shared between the two addresses by the two
congestion control loops - if one congestion-controlled path goes
twice as fast as the other, twice as many packets go that way.

OK, so what is the emergent behaviour?  The traffic self-load balances
across the two links.  If one link becomes congested, the remaining
traffic moves to the other link automatically.  This is quite unlike
conventional congestion control, which merely spreads the traffic out
in time - this actually moves the traffic away from the congested path
towards the uncongested path.  Traffic engineering in this sort of
scenario just falls out for free without needing to involve routing at
all.  And more advanced traffic engineering is possible using local
rate-limiting on one path to move traffic away from that link towards
the other.  Again, this falls out without stressing routing.

Now, there's quite a bit more to it than this (for example, it's great
for mobile devices that want to use multiple radios simultaneously),
but there are also still quite a lot of unanswered questions.  For
example, how much does this solve backbone traffic engineering
problems?  The theory says it might.  I'm working on a document that
discusses these issues in more depth.  But I think the general idea
should be clear - with backwards-compatible changes to the transport
layer and using multiple aggregatable IP addresses for each
multi-homed system, we ought to be able to remove some of the main
drivers of routing stress from the Internet.  That would then leave us
to tackle the real routing issues in the routing protocols.

I hope this makes some sort of sense,

Mark

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