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

[Brian Dickson <briand@ca.afilias.info>]

Mark Handley wrote:
> 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.
>   
[snip]
> 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.
Me too, for what it's worth. There are many different directions from 
which to tackle the multihoming
problem, and the more we collectively attack it, the better the chances 
are we'll find a solution
that is good enough, scales well, and can be incrementally deployed.
>  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?

There are important issues to consider... packet loss can be caused by 
congestion, which responds
to back-off, or by errors, which does not, and in the extreme cases can 
drastically affect TCP.
(Think about error rates where 0.1% of packets have CRC errors, or 1%, 
or 30%.)

Edge links are often treated as duplex, but are really pairs of simplex 
links, with asymmetric properties,
including possibly speed (DSL is a good example), rate limits (cable), 
congestion, errors, etc.

Perhaps if the methods used for pushing bits over modems with multiple 
frequencies at the same time,
like telebit did with its trellis stuff, were used on the N x M 
"channels" in each direction, adaptively,
the desired (described) effect could be achieved.

However, a few other considerations are:
* Duration vs benefit - how long are flows compared to the time needed 
to reach "optimal" performance?
If the average flow is not long enough, and the behavior isn't common to 
all flows on a per-link basis,
this system may perform considerably below expected levels, or levels of 
other schemes.
* Congestion versus unreachable interfaces - if state is hidden by 
aggregation, start-up phase may be adversely
impacted. On the other hand, what is the cost of not hiding that state, 
and keeping/advertising that state information?

And there can be cases where the *client* is multihomed, and the server 
is not... and so on...

One philosophical aspect to the whole issue can be summarized by the phrase:
Routing sucks.
Advertisements of routes attract traffic, in other words.

So, TE issues should generally be controlled by the entity that controls 
routing advertisements.
This is something to consider when contemplating "solutions" which 
places TE into the mutual
control of both parties, rather than unilateral control of the announcer 
- it has the potential to upset
business models for how cost is attributed and/or controlled.
> I hope this makes some sort of sense,
>   
Yes, it is clear to me.

I hope it is also clear that we are all attacking the problem space, not 
each other. :-)

Brian Dickson

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