Re: [NAILS REQUESTED PREVIEW]: Re: SCTP failover

From: Brian F. G. Bidulock <bidulock@openss7.org>
Date: Fri Feb 11 2005 - 17:09:01 EST
('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) Armando,

On Fri, 11 Feb 2005, Armando L. Caro, Jr. wrote:

> On Fri, 11 Feb 2005, Janardhan Iyengar wrote:
>
> > SCTP (and TCP) increase their cwnds until a sender observes loss. An SCTP
> > sender *has* to see loss to cut its cwnd. Even at equilibrium, an SCTP
> > sender will keep seeing loss. Which means that your sender will keep
> > moving back and forth among the different destinations all the time.
>
> To clarify, even in a "no loss" scenario... a TCP/SCTP sender will
> eventually see loss if it continues to send and increase its cwnd. In
> fact, that first loss is how the sender enters congestion avoidance mode.
> That loss will most likely be detected by the fast rtx algorithm.
>
> > Switching over to an alternate on an FR may give you really good failover,
> > but will likely hurt performance when there's no failure (the common
> > case). Optimizing for the common case makes sense.
>
> Actually, if a failure occurs, you will not be able to fast rtx because
> the ack clock will be lost. So switching to an alternate on an FR won't
> even improve failover time.

That's where CMT helps, because the ack clock keeps running (on the other path(s)).
The FR can be used to penalize the original transmit transport address, thus
shifting traffic on the fly to better performing paths.

--brian

>
> ~armando
>
> 0-- --0
> | Armando L. Caro, Jr. | Protocol Engineering Lab |
> | www.armandocaro.net | University of Delaware |
> 0-- --0

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock@openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦
Received on Fri Feb 11 17:15:18 2005

This archive was generated by hypermail 2.1.8 : Mon Mar 13 2006 - 15:22:23 EST