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

From: [email-masked]
Date: Fri, 11 Feb 2005 12:52:02 -0800 (PST)

Armando L. Caro, Jr. wrote:
> 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)
>>
>>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.
> 
> Hmm... I think that is getting too aggressive. This behavior could
> cause reordering and induce false fast retransmits. Why would you do that?

I don't like to wait! :-)   It seems to work well.

-- 

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

---

From: Janardhan Iyengar <[email-masked]>
Date: Fri, 11 Feb 2005 16:20:03 -0500 (EST)

Hi David,

> I don't like to wait! :-)   It seems to work well.

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.

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.

regards,
jana

---------------------------------------------------------------
Janardhan R. Iyengar           http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab  --   CIS   --  University Of Delaware
---------------------------------------------------------------

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Fri, 11 Feb 2005 16:50:46 -0500 (EST)

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

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

~armando

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

---

From: Janardhan Iyengar <[email-masked]>
Date: Fri, 11 Feb 2005 16:59:13 -0500 (EST)

> even improve failover time.

Yeah, good point. In fact, turning that reasoning around: when an FR
does occur, since an ack clock exists, the ack clock demonstrates that
there is no failure!

To clarify, an FR occurs only when there are acks coming back; meaning
data is getting through and so are acks. Therefore, failure couldn't have
happened if an FR happens!

regards,
jana

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Feb 2005 15:09:01 -0700

Armando,

> 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

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ 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 ¦

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 11 Feb 2005 15:28:54 -0700

Janardhan,

Except in the CMT case.  Success on a good path detects failure on a bad path.

--brian

---

From: David Lehmann <[email-masked]>
Date: Fri, 11 Feb 2005 17:35:55 -0500

> happened if an FR happens!

Well, we tested it with a real failure.  To be honest, I have not looked
at that code in a long time. So maybe my follow-up comment was wrong.
I have to look into it.

Nonetheless, I do know that the switch-over occurs after the error count
on the primary is greater than zero, which gives better switch-over
performance.  The lk-sctp switch-over time is unacceptable, IMHO.

--

---

From: David Lehmann <[email-masked]>
Date: Mon, 14 Feb 2005 11:05:32 -0500

> at that code in a long time. So maybe my follow-up comment was wrong.

OK.  As a clarification... FR only causes faster retransmission, but should
not cause the error count to increase nor the RTO to be adjusted...
Correct?

--

---

From: Janardhan Iyengar <[email-masked]>
Date: Mon, 14 Feb 2005 11:33:20 -0500 (EST)

Hi David,

> not cause the error count to increase nor the RTO to be adjusted...

I think that is correct. Only an RTO increases the error count.

regards,
jana

---

From: Randall Stewart <[email-masked]>
Date: Mon, 14 Feb 2005 14:57:45 -0500

> I think that is correct. Only an RTO increases the error count.
Or a missed heartbeat..

But FR's do not effect the error count or RTO

R

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Mon, 14 Feb 2005 13:58:56 -0700

Randall,

But FR does affect cwnd, so if one is doing CMT considering cwnd then
the traffic will be weighted towards the other destinations.

--brian

---

From: David Lehmann <[email-masked]>
Date: Mon, 14 Feb 2005 15:54:30 -0500

> But FR's do not effect the error count or RTO

Thanks.  I don't think that is clear in the spec, especially
since that data chunk could be acting as a HB on the primary
path.

--

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Thu, 17 Feb 2005 12:20:56 -0500 (EST)

> since that data chunk could be acting as a HB on the primary

It is clear. Section 8.2, paragraph 2, sentence 1 says:

   Each time the T3-rtx timer expires on any address, or when a
   HEARTBEAT sent to an idle address is not acknowledged within a RTO,
   the error counter of that destination address will be incremented.

~armando

0--                                              --0