Scott, >> 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.
Right. But what the border router has to do (e.g., keep two sets of prefixes) is different from what has to happen in the core of the Internet. In Mark's approach you would not have to push the multihoming problem and the individual organization's prefixes to the core; it would work with just provider aggregated addresses. So that is the cost saving in his approach (and the costs are elsewhere...) >> 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 ... ? I did not claim that the routing system would disrupt Mark's approach. My point was that a host based approach might theoretically have more information to base its decisions on than a router based design. And hence be better. But admittedly I was handwaving this. My rationale was that a host that has partial topology information (set of prefixes), congestion information, and application demand information could potentially do a better job than the routing system which traditionally has only the topology information and might have some amount of information about congestion. And hosts may have information beyond a single AS, such as when my laptop is connected to two different providers. But of course, the devil is in the details, so its not clear that host approach would win even in a theoretical comparison. First of all, the routing system may have mechanisms to at least locally react much better to congestion/load sharing than the hosts. And obviously, the routing system knows more about the topology than hosts. Jari -- to unsubscribe send a message to [EMAIL PROTECTED] 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
