SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] SCTP failover (path changeover) problem


Chronological Thread 
  • From: Shefiroth Tsai <shefiroth AT gmail.com>
  • To: Michael Tuexen <Michael.Tuexen AT micmac.franken.de>
  • Cc: discussion AT sctp.de
  • Subject: Re: [SCTP-Discussion] SCTP failover (path changeover) problem
  • Date: Thu Nov 3 19:32:02 2005
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=HO43Qp9fWxWf78UrFDJmzGGzd6BIfQzKafvz5JQsxS4L2Q9d9Iy6bGnIweTfbLbSDs7n47Tt3pVyA5zIf5NJvNIpdgE55+9+PxcqGDml/aAc4pyR0PTHPpc/ueDYYzYcSFYxvvhV8HHVITv4rA7h5wULyzufcH18PTWNjUN7lyc=
  • List-id: SCTP Discussions <discussion.sctp.de>

Sorry for my unclear _expression_.
Since I am not very familiar with the retransmission control of SCTP, can you kindly help me correct the following retransmission scenarios if necessary?
I would very appreciate!
For the following scenarios, I assume there are 2 paths (path-1: primary; path-2: alternate) between the server and the client, and the RTO is 1 sec initially.
The scenario that the SCTP association failovers after 63 secs:
1. Server sends TSN 1 through path-1.
2. The user unplugs the network cable.
3. Server sends TSN 2 through path-1
4. After 1 sec, the server retransmit TSN 2 through path-2,
and sends HB on path-1. The RTO is set to 2 secs now.
5. Server sends TSN 3 through path-1
6. After 2 secs, the server retransmit TSN 3 through path-2,
and continuouly sends HB on paht-1. The RTO is set to 4 secs now.
7. Server sends TSN 4 through path-1
8. .......
9. .......
Thus in this scenario, the time needed for failover is 1+2+4+8+16+32=63, if Path_max_retrans = 5, right?
 
Let's consider the following scenario, which the server can sends 3 packets within a second:
1. Server sends TSN 1,2,3 throuth  path-1.
2. The user unplugs the network cable.
3. Server sends TSN 4,5,6 throuth path-1.
TSN 4 sent at 1.33 sec, TSN 5 sent at 1.66 sec, and TSN 6 sent at 1.99 sec.
4.  After 1 sec (at 2.33 sec), the server retransmits TSN 4 through path-2,
and sends HB on path-1. The RTO is set to 2 secs now.
And almost at the same time, the server sends TSN 7.
Therefore, the RTO of TSN 7 is 2 secs.
5. At 2.66 sec, the server retransmits TSN 5 through path-2,
and sends HB on path-1. The RTO is set to 4 secs now.
And almost at the same time, the server sends TSN 8.
Therefore, the RTO of TSN 8 is 4 secs.
6. At 2.99 sec, the server retransmits TSN 6 through path-2,
and sends HB on path-1. The RTO is set to 16 secs now.
And almost at the same time, the server sends TSN 9.
Therefore, the RTO of TSN 9 is 8 secs.
7. Server sends TSN 10, 11, and 12 at 3.33, 3.66, and 3.99 sec.
And their RTOs are 8 secs.
8. At 4.33 sec, the server retransmits TSN 7 through path-2,
and sends HB on path-1. The RTO is set to 32 secs now.
And almost at the same time, the server sends TSN 13.
Therefore, the RTO of TSN 13 is 32 secs.
9. Server sends TSN 14 and 15 at 4.66 and 4.99 sec with RTO = 32.
10. Server sends TSN 16, 17, and 18 at 5.33, 5.66, and 5.99 sec with RTO=32.
11. Server sends TSN 19 at 6.33 with RTO=32.
12. At 6.66 sec, the server retransmits TSN 8 through path-2.
................................
1x. At 10.99 sec, the server retransmits TSN 9 through path-2.
Since the number of retransmissions (6) exceeds Path_max_retrans (5),
SCTP failover happens.
 
Therefore, for the SCTP association that can transmit 3 packets within 1 second only needs about 11 secs to failover, right?
 
I look forward to your opinions.
Thank you!

 
On 11/3/05, Michael Tuexen <Michael.Tuexen AT micmac.franken.de> wrote:
If you are continuously sending packets the calculation you made is
correct.
I'm not sure what is going on. That is why I asked for trace. Are you
sure that
the routing table is not changed when plug out the cable?

If you have only one packet, it would be retransmitted after 1 second
over the
second path and you would need the HB procedure to detect the path
failure which
would take longer due to the HB.Interval.

Best regards
Michael

On Nov 3, 2005, at 13:46 Uhr, Shefiroth Tsai wrote:

> Sorry I am not able to provide the message trace now.
> My program is an SCTP streaming application.
> I think the reason is that my application continuously transmit
> packets from the server to the client.
> Thus, several TSNs may have the same RTO, right?
> Assue that when the network wire is pulled out, the ongoing TSN is 60.
> Then TSN #61, #62, and #63, might have the same RTO because the server
> was continuously sending packets.
> Therefore, the time consumed to failover can be reduced because the
> number of retransmissions will increase faster.
>
> What I mean is:
> The minimum value (63 seconds)for an SCTP association to failover is
> for the situation that only one packet is sent.
> If packets are continuouly transmitted from the server to the client,
> the time consumed to failover can be reduced, right?
>
>
>
> On 11/3/05, Michael Tuexen < Michael.Tuexen AT micmac.franken.de> wrote:
> Hi,
>>
>> can you provide a message trace in libpcap format for both networks?
>>
>> Best regards
>> Michael
>>
>> On Nov 3, 2005, at 3:18 AM, Shefiroth Tsai wrote:
>>
>> > Hi,
>> >
>> > I have implemented a program using the sctplib to test the time
>> > consumed for an SCTP association to failover.
>> > The client and then server both have two NICs.
>> > Under the test, I setup the association between the client and the
>> > server.
>> > Then I just pulled out one of the network wire of the client.
>> > Theoretically, it should take at least 1+2+4+8+16+32=63 seconds to
>> > failover with the standard configuration.
>> > (RTO.mix=1 sec, RTO.max=60 secs, PATH_MAX_RETRANS=5)
>> > However, in my tests, it surprisingly usually only took about 20
>> > seconds to failover.
>> > Why shall this happen?
>> > Can somebody explain the reason for me?
>> > Thanks a lot!
>>
>> _______________________________________________
>> discussion mailing list
>> discussion AT sctp.de
>>  http://www.sctp.de/mailman/listinfo/discussion





Archive powered by MHonArc 2.6.19+.

Top of page