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

[Greg Maxwell <gmaxwell@martin.fl.us>]

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.