Re: SCTP failover

From: Armando L. Caro, Jr. <me@armandocaro.net>
Date: Fri Feb 11 2005 - 15:20:34 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) On Fri, 11 Feb 2005, David Lehmann wrote:

> 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)
>
> 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.

I agree. I have simulation results that show that failing over on a single
timeout is best. The assumption is that a heartbeat is sent immediately to
the primary when a failover occurs. This way, if the primary is still
reachable, then the failover will be cancelled as soon as the heartbeat is
acked. If not, then useful data transfer can occur on the alternate until
a heartbeat sent to the primary gets acked.

www.armandocaro.net/papers/2004.TR2005-04.acaro.pdf

> 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.

I don't think the RFC needs to be changed at all for this. An
implementation can simply lower it's Path.Max.Retrans to 0.

~armando

0-- --0
| Armando L. Caro, Jr. | Protocol Engineering Lab |
| www.armandocaro.net | University of Delaware |
0-- --0
Received on Fri Feb 11 15:32:38 2005