On Feb 19, 2008 6:17 AM, Brian Dickson <[EMAIL PROTECTED]> wrote: > > 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?
Yes, I gave a deliberately simple example, as email isn't the best place to reason design complexities. Of course you want to support multi-homed clients and servers, so you have the NxM issue, plus both N and M will be dynamic if both ends are mobile (which I expect they increasingly will be). The fluid flow models would say use all NxM, because that gives you the best traffic engineering. My gut feeling is that that's probably unnecessary, though it will require research to know for sure. As a rule of thumb, I think you need to separate TE for inbound multihoming from that for outbound links. The former is a global problem if you involve routing, whereas the latter is always purely local, so easier to solve. One option is to use only one of your active source addresses at a time in packets you send, so essentially you have N subflows one way and M the other. If you do this, the outbound traffic engineering is a local routing problem and the inbound is a congestion management problem. Another option is to simply pair up addresses from the two sides, and use source-address-based routing locally to reach the right exit router from the sending site. Then you don't get the full flexibility, but likely its enough to do a reasonable job of TE at both sides without involving routing. Overall, I think we're in some sort of agreement. Anyway, my point isn't that we know the _best _ way to do this, but that there is a whole space of techniques that should be able to lessen the stresses on global routing. Then we can get back to solving routing problems with routing protocols and traffic management problems with traffic management protocols. Cheers, Mark -- 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
