Eliot Lear wrote:
Mark, In reverse order:So, what happens if we stop trying to hide the multihoming. 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.You're certainly challenging the orthodox notion that the routing system provides you the best path to get from one point to another.
I can't see that Eliot - it seems close to Shim6 in some ways, although here Mark is advocating a "shim' at the session / transport level of the protocol stack rather than at the IP level. I have my concerns at the robustness and effeciency of a session level approach and see more merit at the IP level, but thats a personal perspective. But thats orthogonal to the properties of a routing system.
(By the way I don't necessarily believe that the routing system necessarily provides the "best" path. A routing system is a distributed computation environment whose aim is to provide a consistent outcome for all forwarding elements.)
I don't see anything wrong with that. But I also don't see anything wrong with improving the routing system to provide the same function.
I just re-read section 7 of RFC 3221 (Architectural approaches to a scalable Exterior Routing Protocol, dating from 2001). I honestly don;t think we've poushed much beyond the state described then. Personally I think Mark is right to question the scaleability of "monolithic" nature of inter-domain routing when a single distributed computation is applied across the cross product of topology and policy, and whether you attempt to delay some of the computation, or partition it I'm not sure that the total information processing load has altered thereby.
Geoff -- 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