Subject: RE: delayed multihoming/mobility set-up

From: "Christian Huitema" <[email-masked]>
Date: Mon, 1 Dec 2003 09:18:39 -0800

> > IvB>  The reason that BGP
> > IvB> rerouting can take so long is that the RFC mandates a 90 second
> hold
> > IvB> time,
> 
> And a 90 second hold time is already too long.

... which is why I am convinced that the solution to preserving existing
communication is closest to "transport protocols" than "routing
protocols". The time scale of transport protocols is the RTT; the time
scale of routing protocols is the minute. If we wait for a routing event
to be somehow signaled to the transport stack, the connection will be
gone. The natural solution is to use a transport event, e.g. a
retransmission timer. This event can trigger an end-to-end "connection
rehoming" exchange.

My preferred time-line would be:

1) Start a communication using one of the available pairs of src/dest
addresses.
2) If the communication is determined to be worth it (i.e. last long
enough), engage in "multi-homing signaling" to obtain a "set of
equivalent addresses"
3) On a transport event such as retransmission time-out, probe alternate
pairs of src/dest addresses, and pick a "better one" if available.

I would note that a lot of the communication we have today do not meet
the "worth it" requirement. The top applications in the Internet today
are web pages, which mostly consist of a large number of very short
exchanges, and p2p file sharing, which includes its own application
level tools to deal with multi-homing. 

-- Christian Huitema

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Dec 2003 04:48:00 +0900

Christian;

> protocols".

As you say "preserving", you really are talking about "connection",
not "communication" in general.

The proper argument is that

	preserving existing connection is a function of not the
	connectionless Internetworking layer but the transport
	layer (or above)

But, note that your argument is insufficient ignoring simple UDP
query-response type communication such as that of DNS.

> The time scale of transport protocols is the RTT; the time
> gone.

The role of routing protocol is to try to keep the Internet
connected at the connectinless Internetworking layer, which
has nothing to do with connection of connection oriented
protocols.

In other types of network, routing protocols may operate both
at L2, L3 and L4 to take care of keep preserving L4 connection.
But, it is not the case with the Internet.

> level tools to deal with multi-homing.

You are connection oriented.

The difficulty is not in "preserving". See above for a UDP example.

							Masataka Ohta

---

From: Dave Crocker <[email-masked]>
Date: Mon, 1 Dec 2003 12:09:47 -0800

>> And a 90 second hold time is already too long.

CH> ... which is why I am convinced that the solution to preserving existing
CH> communication is closest to "transport protocols" than "routing
CH> protocols".

Many scenarios do not require the fast switchover that is being
discussed here.  For them, the IP-Endpoint (shim) module works fine,
for mobility an for multihoming that is used for fall-back
reliability.

For highly responsive fail-over, multiple locator-pairs must already
be fully functioning before they are needed.  Otherwise, the concern
about being overly responsive sets in, with the usual, attendant
problem of thrashing the choice of path.  For this scenario, I too
believe that transport is the place to put the mechanism, because
transport is where the congestion response information is assessed.

However the Endpoint module still has quite a bit of utility.  First,
it is useful for unmodifie transport modules, such as classic TCP.
Second, it can support the common Address Locator Pool.  That's the
idea behind SLAP.

CH> 1) Start a communication using one of the available pairs of src/dest
CH> addresses.
CH> 2) If the communication is determined to be worth it (i.e. last long
CH> enough), engage in "multi-homing signaling" to obtain a "set of
CH> equivalent addresses"
CH> 3) On a transport event such as retransmission time-out, probe alternate
CH> pairs of src/dest addresses, and pick a "better one" if available.

CH> I would note that a lot of the communication we have today do not meet
CH> the "worth it" requirement.

Yes.  This was an interesting point that came out of the discussion
the Pekka S.  and I had, that he reported.

What I had not appreciated was that the asyncrhonous control exchange
that MAST does permits exactly this sort of long deferral of the
control exchange, meaning that it often will not be done at all.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Dec 2003 11:01:13 +0900

Dave;
 
> discussed here.  For them, the IP-Endpoint (shim) module works fine,

You implicitely assume TCP and its defact default timing, which
is no good for various applications. Such senario MUST be taken
care of not at the IP but at the TCP layer.

> for mobility an for multihoming that is used for fall-back

Mixing timing for mobility and multhoming only confuses everything.

For example, mobility needs mobility, not fall-back reliability.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 2 Dec 2003 11:13:26 +0100

> retransmission timer. This event can trigger an end-to-end "connection

I don't necessarily agree that routing protocols by their nature can't 
do better than the minute timescale, but today BGP lives around that 
timescale and depending on routing has other downsides, such as the 
fact that a routing protocol has little information about which path is 
really better and they don't allow the use of multiple paths in a 
useful way. So I agree that we need to handle this end-to-end.

> enough), engage in "multi-homing signaling" to obtain a "set of

Hm, this is problematic. Simply exchanging addresses isn't good enough, 
as this allows for redirection attacks. So the addresses must be 
validated by using them in a way that can't be spoofed by a third 
party. I.e., one side must contact the other using a new address and 
include authentication information that tells the correspondent it's 
still talking to the same party. If we're doing this anyway there is 
little need to exchange the addresses beforehand. Depending on the type 
of rehoming authentication used it may be necessary to set up 
authentication state before rehoming happens.

> pairs of src/dest addresses, and pick a "better one" if available.

Agree.

Question: do we want to do this on a per transport session basis, or do 
we move an address and all transports running over it in one go when a 
rehoming event occurs?

> level tools to deal with multi-homing.

Even though it's probably not worth the trouble to protect the 
individual TCP sessions towards a web server (but protecting large 
downloads over HTTP would be very useful), it would still be good to 
have fairly seamless failover to another address when a web address 
fails. I'm sure Amazon or Ebay wouldn't want to run the risk of losing 
customers because of reachability issues by depending on web browsers 
to do the right thing. But this assumes the protection is active at the 
IP address level rather than the transport protocol level.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Dec 2003 06:45:17 -0600

Just a couple of notes here...

Spencer

----- Original Message ----- 
From: "Iljitsch van Beijnum" <[email-masked]>
To: "Christian Huitema" <[email-masked]>
Cc: "Multi6 Mailing List" <[email-masked]>
Sent: Tuesday, December 02, 2003 4:13 AM
Subject: Re: delayed multihoming/mobility set-up

> little need to exchange the addresses beforehand. Depending on the
type

Well, the GPRS RTT on networks I've measured *is* around one second,
so if we didn't have to wait until our WLAN address lost its
connectivity to exchange addresses, that could be lovely...

> we move an address and all transports running over it in one go when
a

Well, someone got up in Minneapolis and said, "don't bother rehoming
my e-mail connection, because I would rather keep retrieving e-mail
over my WWAN connection than interrupt retrievals every time I lost my
WLAN connection". If these seems desireable, it's probably
per-transport-session; if not, it's probably per-address, unless we
want to go down the ToS/CoS path.

> IP address level rather than the transport protocol level.

Christian's opinion is true for per-object HTTP connections, a little
less true for persistent HTTP connections, little less true for
persistent HTTP connections to a proxy, and a little less true for
persistent HTTP connections when the browser is using pipelining. It's
a pity that we can't include some notion of "this is a large object"
in HTML, of course.

Spencer

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 2 Dec 2003 14:51:38 +0100

Hi Christian,

> My preferred time-line would be:

I agree with most of this outline, just a question...

> enough), engage in "multi-homing signaling" to obtain a "set of

Wouldn't be possible to exchange additional information once that the outage
has been detected?
This sound a bit strange, i know...
But suppose we are using something like SIM
We start the communication using the AID a one locator without any kind of
validation of the AID
If no outage occurs, the communication continues and no extra overhead is
introduced.
If an outage occurs, the endpoints detect it (for instance helped by the
transport or application layer)
At that time, they start using different source addresses and see if they
reach the other end (this packet has to contain also some validation
information, linking the initial AID with the new source locator)
Now, when the other end receives a packet with a different source address
(and validation information), it starts sending to this new address.

This approach allows to avoid any additional packet exchange until an outage
occurs (when it is needed)

Do you think this may work?

regards, marcelo

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 03 Dec 2003 00:53:26 +0900

Iljitsch;

> validated by using them in a way that can't be spoofed by a third party. 
> I.e., one side must contact the other using a new address and include 
> authentication information that tells the correspondent it's still 
> talking to the same party. If we're doing this anyway there is little 
> need to exchange the addresses beforehand.

Redirection is inherent to the Internet and is no issue.

The approach is simply wrong, because it is connection oriented.

> Depending on the type of 
> rehoming authentication used it may be necessary to set up 

Rehoming has nothing to do with multihoming.

A singly homed host can rehome. A dual homed host may keep using
the homes forever without rehoming.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 06 Dec 2003 16:54:02 +0100

One of our current objectives is to start architectural breakdown
and analysis. It seems to me there is an architectural boundary
right in this thread - something to do with separating the detection
of an address dropout (the address in use is suddenly no good)
from fixing it (fast recovery a la SCTP if we care, or waiting for
network layer and routing to select a new address if we are not
in a hurry).

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 07 Dec 2003 07:48:55 +0900

Brian;

> and analysis.

Huh? At Minneapolis, you denied my proposal to have architectural
document, because most of us can 't do it.

Why and how have you changed your mind?

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Dec 2003 10:26:23 +0100

Ohta-san, we decided to start with the "additionl goals" draft that
Eliot is writing, and to examine the various proposals for their common
architectural features. This does not meaning immediately writing a draft.

   Brian