Re: Quick Failover Algorithm in SCTP - question for the WG

[Thomas Dreibholz <[e-mail]>]

Dear all,

On Dienstag 25 Januar 2011, David Lehmann wrote:
> IMHO, there are a few reasons to move forward with Quick Failover.
> (1) Quick Failover seems to be less complex, which will allow more
> timely approval/implementation. As Kacheong pointed out, "Doing it does
> not require co-operation from the receiver side.  There is not much side
> effect (should not introduce congestion for example)...".
> (2) Although the current spec may allow quick failover, it implies an
> unacceptably long wait time before failover.  I don't think Solaris or
> Linux has quick failover.  Let's say that one does implement it. Now we
> have two major implementations with quite noticeable behavior
> differences.  IMHO, users should expect consistent behavior across all
> SCTP implementations.

Significant difference in implementation behaviour is a very bad thing. The 
experience from RSPLIB (i.e. the RSerPool implementation, see 
http://tdrwww.exp-math.uni-essen.de/dreibholz/rserpool/) which supports 
multiple operating systems and therefore different SCTP stacks, is that 
actually the application has to detect that there is no real transmission 
progress in case of a path failure -- and either wait for SCTP to switch the 
primary path (which takes unacceptably long for this kind of application) or 
trigger a session failover (expensive). From the application writer's 
perspective, a consistent behaviour of the underlying SCTP implementations 
would make things a lot easier.


> (3) As Dr. Dreibholz noted, CMT will also benefit from Quick Failover.
> The CMT spec can reference Quick Failover.

This is currently done in draft-tuexen-tsvwg-multipath-sctp-01.


Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     [e-mail]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=======================================================================