Chronological Thread 

< Chronological >      < Thread >

---

Dear Marjan,
see my comments below.
Best regards
Michael

--
e-mail:
Michael.Tuexen AT micmac.franken.de

On Fri, Jul 13, 2001, Marjan Bozinovski
<marjanb AT cpk.auc.dk>
wrote:

>Hi,
>
>I have used SCTP pre-release 12 (including the patch issued by Andreas
>Jungmaier, in his reply on "Network status change in Pre 12", sent on the
>21st June) and deployed the following scenario:
>A dual-path communication between "terminal" and "echo_server", while
>simulating a network failure.
>The both sides were dual-homed and were connected via two LANs. After the
>association was established, the path 0 was declared as primary path. Then I
>sent several packets from the terminal to the echo server, whilst receiving
>SACKs and DATA, all the time using the primary path 0 for transmits and
>retransmits. After a while, I decided to provoke a failure of the path 0 by
>pulling out the cable from the hub. Immediately after the network failure, I
>created new data packets at the terminal side. The first data chunk after
>the network failure, was sent at the relative moment, approximately t = 15
>sec. Because the SCTP entity at the terminal side did not yet detect the
>path 0 failure, it continued to consider this path as primary and thus sent
>the packet through the path 0. But, the terminal did not receive an
>acknowledgement for the sent data chunk, and the terminal SCTP entity
>decided to retransmit the lost data chunk via the secondary path (i.e., path
>1). The moment of the retransmission of this chunk is approximately t = 16
>sec. Hence, the retransmission via path 1 occurred about 1 sec after the
>initial attempt to transmit the packet via path 0. The round-trip time
>seemed to be around 0.7 msec, thus more than 1000 times shorter.
>
>The questions are:
>Why was the retransmission via the secondary path so much delayed?
>Should it not occur, in principle, immediately after the retransmission
>timer expiration?
The behaviour ist OK. The retransmission time out is based on round
trip time measurements and exponential backoff. After that, the value
is modified to be in the interval [RTO_Min, RTO_Max]. This is described
in RFC 2960. The values suggested there are RTO_Min = 1 sec, RTO_Max= 60 sec.

So you should modify RTO_Min. This is possible through the API.
>What parameters does that 'failover-duration' depend on?
RTO_Min, RTO_Max, Max. number of retransmission per assoc, path.
Timer for delaying the SACKs, the 3 in the 3 SACKs rule.
>
>Best regards,
>Marjan Bozinovski
>
>_______________________________________________
>discussion mailing list
>discussion AT sctp.de
>http://www.sctp.de/mailman/listinfo/discussion

---

• RE: [SCTP-Discussion] Off Topic - M2UA/M2PA open source, Tuexen Michael, 07/13/2001
  • [SCTP-Discussion] Path failure management, Marjan Bozinovski, 07/13/2001
    • Re: [SCTP-Discussion] Path failure management, Michael Tüxen, 07/13/2001
      • Re: [SCTP-Discussion] Path failure management, Marjan Bozinovski, 07/14/2001
        • [SCTP-Discussion] Unclear statement, Marjan Bozinovski, 07/14/2001
          • Re: [SCTP-Discussion] Unclear statement, Michael Tüxen, 07/14/2001
            • Re: [SCTP-Discussion] Unclear statement, Marjan Bozinovski, 07/14/2001
              • Re(2): [SCTP-Discussion] Unclear statement, Michael Tüxen, 07/14/2001
              • Re: [SCTP-Discussion] Unclear statement, M. Mueller, 07/15/2001
              • Re(2): [SCTP-Discussion] Unclear statement, Michael Tüxen, 07/15/2001
              • Re: Re(2): [SCTP-Discussion] Unclear statement, M. Mueller, 07/16/2001
        • Re(2): [SCTP-Discussion] Path failure management, Michael Tüxen, 07/14/2001
      • Re: [SCTP-Discussion] Path failure management, Marjan Bozinovski, 07/18/2001

---

Archive powered by MHonArc 2.6.19+.