Re: [RRG] Are we solving the wrong problem?

["William Herrin" <bill@herrin.us>]

On Tue, Feb 19, 2008 at 12:35 AM, Mark Handley <M.Handley@cs.ucl.ac.uk> 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                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
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