Chronological Thread 

< Chronological >      < Thread >

---

Dear Michael,

Thank you for your response. I have forgotten the rules you described below.

My next question is related to the multi-streaming feature. The original
terminal application sends data using only one stream. I have changed the
terminal application in such a manner that each time it sends a new data, it
changes the stream IDs, incrementing it by 1. But, this does not essentially
changes the behaviour, because I still have one stream per transmitted
chunk.
So, the question is, how to modify the terminal application, so that, every
time it sends data, it can create several chunks, allocate to them different
stream IDs and bundle them in one SCTP packet, thus achieving to have
several, simultaneously used, parallel streams?

Best regards,
Marjan


----- Original Message -----
From: "Michael Tüxen"
<Michael.Tuexen AT micmac.franken.de>
To:
<discussion AT sctp.de>
Sent: Friday, July 13, 2001 1:54 PM
Subject: Re: [SCTP-Discussion] Path failure management


> 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
>
>
> _______________________________________________
> 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
        • Re: [SCTP-Discussion] Path failure management, Andreas Jungmaier, 07/18/2001

---

Archive powered by MHonArc 2.6.19+.