[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

El 04/03/2008, a las 18:12, Scott Brim escribió:


On 3/4/08 3:13 AM, Jari Arkko allegedly wrote:

In any case, what I find interesting in this space is the different
design tradeoffs. A routing system that hides multihoming and provider 
independence from the endpoints is easy for the endpoints and edge
networks. I.e., you do not have to change hosts in any way, every
network has a single prefix, renumbering is not necessary,
providers/network owners are in control of what kind of multihoming and 
TE is going on, etc.
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.

well, the nice thing about this approach is that the routers do have a  
knob for doing TE, which is basically increment the congestion  
perceived by the endpoint. If they do that, the endpoint will diverge  
its traffic to alternative paths and we actually achieve what the  
router seems to desire, i.e. moving the traffic towarda a different  
link, right?

regards, marcelo





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

Scott

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


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