Re: SCTP failover

From: David Lehmann <lehmann@ulticom.com>
Date: Fri Feb 11 2005 - 14:33:41 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) David Lehmann wrote:
> Randall Stewart wrote:
>
>> In any event the only way to keep the network failover time
>> down is to set RTO.Max to a lower value.. that would make things
>> faster... To have a 1 second failover I would imagine that
>> Ulticom's stack is setting both RTO.Min and RTO.Max to a
>> lower value... aka that adds up to a total of 1 second..
>> I.e. something like 50ms RTO.Min and 400ms RTO.Max
>
>
> Nope. When the error count is greater than 0 on the
> primary destination, Ulticom uses an alternate destination,
> until the error is cleared on the primary destination.
> So, if the user is using the default values, the user
> will only see a blip for one second.
> (...assuming an RTO of 1 second)

I need to correct my former post. Assuming a steady flow
of data chunks, the switch-over with Ulticom's stack will
actually be in a fraction of a second since the FR will
notice the problem long before the RTO.

> IMHO, waiting around for 1 minute while data trickles through
> the association is not acceptable and does not give the user
> of a sense of transparent network redundancy.
>
> IMHO, the language in section 6.4 should be changed from:
> By default, an endpoint SHOULD always transmit to the primary path,
> unless the SCTP user explicitly specifies the destination transport
> address (and possibly source transport address) to use.
> to something like:
> By default, an endpoint SHOULD always transmit to the primary path,
> unless the error count on the destination is greater than zero or the
> SCTP user explicitly specifies the destination transport address (and
> possibly source transport address) to use.
>

-- 
David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

Received on Fri Feb 11 14:57:03 2005