On Tue, Feb 19, 2008 at 12:35 AM, 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.
Mark, If you're feeling ambitious, change "two" to "many" and modify TCP so that during the SYN+SYN/ACK, both sides can exchange cryptographically signed connection IDs. The presence of these two IDs with a correct signature identifies subsequent packets associated with the connection, regardless of the source and destination addresses. Any such "TCP" packets can also contain an "address update" option which offers the other side a fresh list of addresses at which it can be reached as well as hints about priority and load balancing. Among other nifty things, this would allow you to completely dispense with the source port. If you wanted to, you could also change the destination port to a destination service name, since it need only appear in the original SYN packet. I suppose if you want to retain backwards compatibility, you would at least include the source and destination port numbers in the SYN packet and drop them later if the options returned in the SYN/ACK agreed to use your new TCP. If you're feeling *really* ambitious, exchange the hostname during the connection setup as well so that if all the connection's IP addresses change while the connection is idle, the next transmitter can find the other side by refreshing the address list with a DNS lookup. Require the DNS server to allow it's clients to update their hostname's list of IP addresses. Alternately, you could dispense with the cryptography and address update option and instead use a forward DNS lookup to refresh the connection's permitted address list any time you receive a packet from a source that isn't in the original list. Next, just to be clever, throw in an "on hold" TCP option which allows a mobile station that knows it will be unavailable for a while to instruct the folks with which it is currently communicating not to attempt communications on that connection for up to some number of seconds because it will be unavailable. If you do all of these and then succeed in deprecating old-style source port/dest port connections, this has some interesting implications for route aggregation. You'll find it becomes possible to create a fully automatic system to resize and reassign IP addresses at need which in turn allows the Internet as a whole to automatically achieve something near the optimum achievable aggregation through the kind of "emergent behavior" you talk about. Say, that's pretty neat. I had considered most of these ideas before, but it didn't occur to me to use a TCP protocol addition as the starting point so that deployment could be incremental and fully backwards compatible. If you don't write something up, maybe I will. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004 -- 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
