Yes, I completely agree. I considered this approach in the TAMARA concept as "vectorized TCP". There is a strong reason to follow this path: as the internet is still a (broken) end-to-end network, only the end points may have exhaustive information on relative performance of different paths *for free*. More precisely, by end-points I mean the TCP code at the end-point hosts, because, obviously, it already does the calculations and keeps the data. Any entities in the middle may just guess. Finally, if end-point TCP stacks do some congestion control decisions why do not they do some routing decisions? This vectorized TCP / real SCTP approach complements prefix-bunch architectures well.
On 19/02/2008, Mark Handley <[EMAIL PROTECTED]> wrote: > > 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. > > OK, so what is the emergent behaviour? The traffic self-load balances > across the two links. If one link becomes congested, the remaining > traffic moves to the other link automatically. This is quite unlike > conventional congestion control, which merely spreads the traffic out > in time - this actually moves the traffic away from the congested path > towards the uncongested path. Traffic engineering in this sort of > scenario just falls out for free without needing to involve routing at > all. And more advanced traffic engineering is possible using local > rate-limiting on one path to move traffic away from that link towards > the other. Again, this falls out without stressing routing. > > Now, there's quite a bit more to it than this (for example, it's great > for mobile devices that want to use multiple radios simultaneously), > but there are also still quite a lot of unanswered questions. For > example, how much does this solve backbone traffic engineering > problems? The theory says it might. I'm working on a document that > discusses these issues in more depth. But I think the general idea > should be clear - with backwards-compatible changes to the transport > layer and using multiple aggregatable IP addresses for each > multi-homed system, we ought to be able to remove some of the main > drivers of routing stress from the Internet. That would then leave us > to tackle the real routing issues in the routing protocols. > > I hope this makes some sort of sense, > > 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 > -- Victor
