Subject: Re: Transport level multihoming

From: Peter Tattam <[email-masked]>
Date: Sat, 4 Aug 2001 11:33:40 +1000 (EST)

It has been on my mind for some time to elevate this proposal (and the
subsequent discussions in Tokyo) to I-D level, but getting it to the right
printing format is beyond me.  Can someone point me to some tools that might
help me translate this into IETF acceptable format?

My apologies for not getting to it sooner.  I have had an incredibily full
schedule with the release of our new operating system over the past year or so.

My analysis of multihoming and the widespread criticism of Ipv6 "outside the
Ipv6 fold", indicated that host-based multihoming was probably the only thing
that was going to fly.

I put the idea together after much discussion on the ipng mailing list.  The
preconditions were that strong aggregation and multi numbering were an inherent
part of the multihoming brief for Ipv6, and that it was not possible to change 
the rules to suit my needs (e.g. GSE).  Also part of my brief was to consider
that the routing infrastructure was made up of a number of entities in a mutal
love/hate relationship implying that they would be unwilling to do much more
than forward packets to each other (ruling out any kind of friendly tunneling
proposals).

If there is sufficient interest, I believe the proposal (at the suggestion of
Steve durin the Tokyo meeting) can be extended outside the initial TCP scope
for which it was intended.   I have since determined the fundamental principles
of the proposal so that they can be applied to a more general proposal.

Peter

On Wed, 4 Apr 2001, Steve Deering wrote:

> If this group is to pursue host-based or transport-layer multihoming,
> you might want to look at some of the material presented at the Tokyo
> interim meeting of the IPng working group in Sept/Oct 1999, fetchable
> from <http://playground.sun.com/ipng/meetings.html>.  For example,
> my "Overview of IP(v6) Multihoming Issues" is one attempt to
> characterize the problem space and list a range of (increasingly
> ambitious) goals one could set for host-based multihoming, and the
> presentation from Peter Tattam entitled "Preserving Active TCP
> Sessions" was one stab at enhancing TCP for multihoming.
> 
> Steve
> 
> 

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 4 Aug 2001 16:02:10 +0859 ()

Peter;

> subsequent discussions in Tokyo) to I-D level,

That is not a useful thing to do.

Transport layer is not the last layer to solve the problem.

> I have read
> 
> draft-ietf-multi6-multihoming-requirements-01
> and
> draft-ietf-multi6-v4-multihoming-00
> 
> What else should I read?

	draft-ohta-e2e-multihoming-01.txt

							Masataka Ohta

---

From: "Ben Black" <[email-masked]>
Date: Sat, 4 Aug 2001 00:27:20 -0700

>That is not a useful thing to do.

Peter,

The working group would welcome your contributions.

Ben

---

From: Peter Tattam <[email-masked]>
Date: Sat, 4 Aug 2001 17:43:22 +1000 (EST)

ok.  I'm getting a mixed signal here.

I've reformatted my draft to be IETF compatible and added some more recent
thoughts and discussion of implications.

Until I get it published via the I-D editor, here's a URL to it.

http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt

Peter

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Sat, 4 Aug 2001 03:15:18 -0500 (CDT)

Ignore the mixed signals, Peter.  We are always open to at least hearing
new ideas.  While some parties may or may not agree with your standpoint,
the IETF's motto is rough consensus and running code.  Our many viewpoints
are our strength.

-Jon

On Sat, 4 Aug 2001, Peter Tattam wrote:

> Date: Sat, 4 Aug 2001 17:43:22 +1000 (EST)
> From: Peter Tattam <[email-masked]>
> To: Ben Black <[email-masked]>
> Cc: Masataka Ohta <[email-masked]>,
>      Multi6 Working Group <[email-masked]>
> Subject: RE: Transport level multihoming
> 

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989

---

From: "Jon (Taz) Mischo" <[email-masked]>
Date: Sat, 4 Aug 2001 03:51:58 -0500 (CDT)

Well, okay...Sean hath laid the smack down :)  So listen to him :)  Just
ignore the man behind the curtain.

-Jon

On Sat, 4 Aug 2001, Jon (Taz) Mischo wrote:

> Date: Sat, 4 Aug 2001 03:15:18 -0500 (CDT)
> From: "Jon (Taz) Mischo" <[email-masked]>
> To: Peter Tattam <[email-masked]>
> Cc: Ben Black <[email-masked]>,
>      Masataka Ohta <[email-masked]>,

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 8 Aug 2001 17:00:00 +0100

> http://jazz-1.trumpet.com.au/ipv6-draft/preserve-tcp.txt

Maybe I missed something, I have no problem with the address exchange, but how is a host supposed to know which of its addresses the correspondent will be able to reply to? If the prefix required for the SYN/ACK drops after connection establishment, won't the host need to be snooping the routing system to know which of its addresses to use as the source of the next packet? If both hosts are snooping, wouldn't they be in a position to try and bias the end-to-end path by switching the destination address to one on the list provided in the SYN/ACK?

Tony

---

From: Peter Tattam <[email-masked]>
Date: Thu, 9 Aug 2001 10:38:15 +1000 (EST)

On Wed, 8 Aug 2001, Tony Hain wrote:

> Maybe I missed something, I have no problem with the address exchange, but
> how is a host supposed to know which of its addresses the correspondent will
> be able to reply to? If the prefix required for the SYN/ACK drops after
> connection establishment, won't the host need to be snooping the routing
> system to know which of its addresses to use as the source of the next
> packet? If both hosts are snooping, wouldn't they be in a position to try and
> bias the end-to-end path by switching the destination address to one on the
> list provided in the SYN/ACK? 

This is the difficult bit alluded to in the draft.

In the BSD implementation, the address switch is based on the TCP retry
mechanism (I think after so many retries).  It cycles sequentially thorugh the
list supplied.

This is the tricky bit in the whole idea.  Making the first quess (for the SYN
exchange) is the hardest.  Switching to change addresses is not quite as
difficult as the list returned by the peer can be ordered to make the
subsequent guesses more accurate.

The thesis that accompanies the BSD implementation has an analysis of these
aspects.  It is worth reading.

My next step is to suggest ways that nodes can cache important information
regarding the state of forward routing so that it can make the appropriate
decisions.  It need not be tied to the routing system, just learnt as it goes.

> Tony

I'm sorry it looks like hand waving.  This is new for us all.

Peter