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 differentdesign tradeoffs. A routing system that hides multihoming and providerindependence 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 andTE 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 wouldbe cheaper -- but you are actually looking at removing some of thisinformation. I guess the main question is, can we substantially reducethe costs of the routing system while keeping the same amount ofinformation 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 ontransport 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