Re: Network layer reqt? [was Re: Transport level multihoming]

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Greg;

You still are not saying reconnection is good enough.

So, let's have an extended multihomed TCP interoperable with current
TCP. It's just a SYN option.

Let end systems choose which TCP to use.

There is no need for reconnection.

							Masataka Ohta

> On Thu, 5 Apr 2001, Masataka Ohta wrote:
> 
> > > > You miss the point.
> > > > 
> > > > > > Most TCP applications are so stateful that they can not accept a
> > > > > > loss of bytes.
> > > > 
> > > > Neither SVC nor TCP reconnection restores lost data.
> > > 
> > > No. But today, connections with TCP/IPv4 and typical IP multi-homing get
> > > dropped and data gets lost when the prefered path fails. Traffic is lost
> > > until the routing reconverges which is usually long enough to back TCP off
> > > into oblivion.
> > 
> > You are not saying reconnection is good enough but saying reconnection
> > is unnecessary.
> > 
> > That's not a Brian's point.
> > 
> > Note also that you are assuming large, thus, slow to converge,
> > routing table.
> 
> Ideally the path failure would cause no visible change to the user.
> 
> Today, the IPv4 internet converges slowly enough that TCP sessions are
> often restarted. (Thats my expirence at least, anyone have any hard
> information on the current behavior?)
> 
> If it is acceptible for link failure to cause session restarts sometimes,
> then applications must handle it and I think it would likely be acceptible
> to users if IPv6 multi-homing caused legacy applications to always lose
> their session (people accept web 'load-balancers' which all have this
> properity). 
> 
> Obviously if application invisible failover can occure, then that is the
> desired behavior.
> 
> What I am saying is:
> 
> sufficient = Sufficient mulit-homing from the IPv6 client's perspective to
> remove the need for other IP level, aggregation busting,
> multi-homing methods. 
> 
> 1) Session failure is sufficient for legacy application support.
>    If better can be implemented for these applications: Great. 
> 2) We must have the capability for future applications to support more
>    robust multihoming, SCTP based applications for example.
> 
> We are looking to nail down requirements, not an implimentation. It may
> turn out that keeping sessions alive without API changes is easy and thats
> what should be implimented. It may turn out that keeping the session alive
> requires API changes and that should be left for the future.
>  
> 
> 
>