Subject: RE: Simple dual homing experiment

From: "Tony Li" <[email-masked]>
Date: Wed, 19 Mar 2003 20:22:12 -0800

|    David and I wrote up a "simple dual homing" proposal, 
|    based on previous drafts and private conversations. This 
|    may be one of several ways of going forward in multi6.

Christian,

First, I don't believe that 3.5 is a real requirement.  It is
not a problem that is solved today in any technology short of
full blown traffic engineering.  While I agree that this would
be valuable, I don't see how this really cuts it as a requirement.

Of your other requirements, it would seem that they would all
be addressed as long as:

	1) routers which don't have a working exit don't advertise
         default
	2) hosts rotate their source (and destination) addresses
	   among the possible set

Further, I would argue that your requirement for 3.4 isn't strong
enough.  That the connection should NOT break.

Comments?

Tony

---

From: Coene Lode <[email-masked]>
Date: Thu, 20 Mar 2003 19:03:55 +0100

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Thursday, March 20, 2003 3:03 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: FW: Simple dual homing experiment
> 
> 
> Kurtis,
> 
> David and I wrote up a "simple dual homing" proposal, based 
> on previous drafts and private conversations. This may be one 
> of several ways of going forward in multi6.
> 
> -- Christian Huitema
> 
> 
>
issue 3.1 : egress filtering:

I would think that selecting the destination address  based on the source
address is a bit strange...
Transport protocols(SCTP in particular) selects a destination address, the
IP layer selects an outgoing interface, thus in order to have a msg with the
correct source address to get through egress filtering, the msg should
contain the IP address of the outgoing interface as this is the address the
interface got assigned by the provider upstream(and the provider would let
its own sourceaddresses/prefixes through, wouldn't it..??..)

issue 3.2:
some form of heatbeating per destination(as in SCTP) should do the trick...
no problem there

issue 3.3:
looks the same from the perspective of the transport layer.. use same
solutions as in 3.2
solve one, get a extra free with...

issue 3.4:
changeover to a active connection/path.. some transport protocols can do
that also.. no problem..

issue 3.5:
actually the only guy that could do optimisations is the endpoint itself: it
has the congestion information, it could know the load distribution between
the different paths/connections if she is smart enough.. 

basically the smart solution should not pose any problems.. atn least it
hasn't give us(=SCTP implementations) any problems up till now. And multiple
TCP connections(or something in that direction) would deliver the same
stuff...

yours sincerly,
Lode Coene

Siemens atea
atealaan 34          2200 Herentals, Belgium
E-mail: [email-masked]
Tel: +32-14-252081
Fax: +32-14-253212

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 20 Mar 2003 11:48:32 -0800

I agree that exit selection (3.5) is more of a "nice to have" -- the real requirement is, try to achieve some load sharing so we do not get a gross misuse of the resource.
 
The reason for "should not break" rather than "must not break" is that in a similar set up today (e.g. main connection backed up by a DSL line), turning on backup actually breaks connections. Also, I am not confident that we can make sure that no connection will ever break, so "must" may well be slightly out of the reach of engineering.
 
By the way, your general observation is correct: David an I believe that most of the solution is actually fairly easy to engineer.

________________________________

From: Tony Li [mailto:[email-masked]]
Sent: Wed 3/19/2003 8:22 PM
To: Christian Huitema; [email-masked]
Cc: [email-masked]
Subject: RE: Simple dual homing experiment

Christian, 

Comments? 

Tony

---

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Mar 2003 12:54:06 -0800

Perfectly reasonable.

I should point out that turning up an additional link today
breaks connections because the host isn't capable of trying
a different address.  You could, in theory, write a non-standard
TCP that had the right host behavior, even with IPv4 today.  But
it doesn't exist, AFAIK.

Now, does this test actually distinguish anything between any of
the proposals that have been discussed?

Tony

|    -----Original Message-----
|    From: Christian Huitema [mailto:[email-masked]] 
|    Sent: Thursday, March 20, 2003 11:49 AM
|    To: Tony Li; [email-masked]
|    Cc: [email-masked]
|    Subject: RE: Simple dual homing experiment
|    
|    
|    I agree that exit selection (3.5) is more of a "nice to 
|    have" -- the real requirement is, try to achieve some load 
|    sharing so we do not get a gross misuse of the resource.
|     
|    The reason for "should not break" rather than "must not 
|    break" is that in a similar set up today (e.g. main 
|    connection backed up by a DSL line), turning on backup 
|    actually breaks connections. Also, I am not confident that 
|    we can make sure that no connection will ever break, so 
|    "must" may well be slightly out of the reach of engineering.
|     
|    By the way, your general observation is correct: David an 
|    I believe that most of the solution is actually fairly 
|    easy to engineer.
|     
|     
|    
|    ________________________________
|    
|    From: Tony Li [mailto:[email-masked]]
|    Sent: Wed 3/19/2003 8:22 PM
|    To: Christian Huitema; [email-masked]
|    Cc: [email-masked]
|    Subject: RE: Simple dual homing experiment
|    
|    
|    
|    
|    |    David and I wrote up a "simple dual homing" proposal, 
|    |    based on previous drafts and private conversations. This 
|    |    may be one of several ways of going forward in multi6. 
|    
|    
|    Christian, 
|    
|    First, I don't believe that 3.5 is a real requirement.  It is 
|    not a problem that is solved today in any technology short of 
|    full blown traffic engineering.  While I agree that this would 
|    be valuable, I don't see how this really cuts it as a requirement. 
|    
|    Of your other requirements, it would seem that they would all 
|    be addressed as long as: 
|    
|            1) routers which don't have a working exit don't advertise 
|             default 
|            2) hosts rotate their source (and destination) addresses 
|               among the possible set 
|    
|    Further, I would argue that your requirement for 3.4 isn't strong 
|    enough.  That the connection should NOT break. 
|    
|    Comments? 
|    
|    Tony 
|    
|

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 20 Mar 2003 13:42:40 -0800

The idea is to build  to split the problem in pieces: how to solve ingress filtering, how to solve connection maintenance, etc., and then to agree on at least one good solution. Good = easy to deploy, minimal development, etc.

From: Tony Li [mailto:[email-masked]]
Sent: Thu 3/20/2003 12:54 PM
To: Christian Huitema; [email-masked]
Cc: [email-masked]
Subject: RE: Simple dual homing experiment

Perfectly reasonable.

Tony