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

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

On Feb 19, 2008 6:17 AM, Brian Dickson <briand@ca.afilias.info> wrote:
> >  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.
> >
> >
> I think one difficulty is when you extended that for connections between
> two boxes,
> with respectively N and M addresses. What do you do? N x M connections,
> or something else?

Yes, I gave a deliberately simple example,  as email isn't the best
place to reason design complexities.

Of course you want to support multi-homed clients and servers, so you
have the NxM issue, plus both N and M will be dynamic if both ends are
mobile (which I expect they increasingly will be).  The fluid flow
models would say use all NxM, because that gives you the best traffic
engineering.  My gut feeling is that that's probably unnecessary,
though it will require research to know for sure.

As a rule of thumb, I think you need to separate TE for inbound
multihoming from that for outbound links.  The former is a global
problem if you involve routing, whereas the latter is always purely
local, so easier to solve.

One option is to use only one of your active source addresses at a
time in packets you send, so essentially you have N subflows one way
and M the other.  If you do this, the outbound traffic engineering is
a local routing problem and the inbound is a congestion management
problem.

Another option is to simply pair up addresses from the two sides, and
use source-address-based routing locally to reach the right exit
router from the sending site.  Then you don't get the full
flexibility, but likely its enough to do a reasonable job of TE at
both sides without involving routing.

Overall, I think we're in some sort of agreement.  Anyway, my point
isn't that we know the _best _ way to do this, but that there is a
whole space of techniques that should be able to lessen the stresses
on global routing.  Then we can get back to solving routing problems
with routing protocols and traffic management problems with traffic
management protocols.

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