Chronological Thread 

< Chronological >      < Thread >

---

Alberto,

Actually, a decrementing graph is to be expected. The initial packets
suffer the worst delay because they are being sent to a failed destination.
Only once a sufficient number of RTO timeouts occur will the sender switch
to the alternate destination. When packets are sent to the alternate
destination, the alternate destination still has a narrow congestion window.
Because packets acknowledged on retransmission cannot contribute to RTT
calculations, they cannot be used for expanding the congestion window on
the alternate destination either.

What you observe is a staircase with 0.5 or 1.0 second steps. These steps
correspond to the RTO.min of 1 second when adjusted in the RTT calculations
for setting RTO. Along the X axis you can see the doubling effect of
doubling RTO with each T3-rtx expiry. The diagonal line on each step
come from the implementation running a single T3-rtx timer. Upon expiry
the earliest message has been delayed the most and the latest message has
been delayed the least. Because retransmission is rapid and successful,
each packet is delay proprotional to its sending time and thus the linear
relationship between timeouts (vertical lines).

The result is the observed dismal changover performance.

Altering values of RTO min and max and Path.Max.Retrans one can obtain far
better changeover performance. The test results at the end of
http://www.openss7.org/strsctp/test/log.sctp_n shows that by placing RTO.min
to 0 and Path.Max.Retrans to 0 can yield 8ms changeover times instead of the
dismal 10 second changeovers you see with "recommended" values. Setting these
values to zero does not compromise the congestion algorithms.

I you want to look more closely at what is cause each timeout and is
contributing to the magnitude of the delay at each point, you need to
correlate the packet traces (e.g., Ethereal) with the resulting waveform.
At each step you will find that a retransmission occurs and that another
decision is being made regarding the destination to which DATA and SACKs
are being sent.

It is especially brutal on an SCTP implementation to send data in one
direction only. This is because the receiving implementation only has
heartbeat acknowledgements (and DUPs) upon which to make decisions.

Alterations and heuristics applied to the changeover from primary to secondary
destinations can yeild better response in a narrow range of circumstances.

--brian

On Tue, 22 Jan 2002, Alberto Bellettato wrote:

> Hello all,
> I am testing sctp behavior in the following multihoming configuration:
> 2 Linux PCs, each pc has got 2 NICs, and these interfaces are connected 2
> by 2
> through 2 crossed cables (a scheme is present at
> http://spazioweb.inwind.it/stazionebase/graphs.jpg). I
> established an association and I began to transmit fixed sized data chunks
> (250
> bytes), one every 2 milliseconds (for ex.). Some seconds after
> transmission's
> beginning, I physically disconnected the primary path (disconnecting one
> crossed cable). In this situation, as I had expected, I experienced
> retransmission on the secondary path and then notification of inactive
> primary
> path, and conseguent path's switching.
> My test program calculates delay time for every data message transmitted
> from
> upper layer (through echo of timestamped messages). As result I expected a
> graph
> following a "step shaping", i.e. a standard delay value at the beginning
> (both
> paths active) and at the end (secondary path has become the primary one),
> and an
> incremented delay value between primary path physically disconnecting and
> path's switching.
> Instead I obtained a decrementing graph shaping (see image at
> http://spazioweb.inwind.it/stazionebase/graphs.jpg). I would
> want to understand why the graph is decrementing and why there so many
> steps.
> Could anyone explain to me the implementation's behavior in this
> situation?
> Thank you very much in advance.
>
> Best regards,
>
>
> Alberto Bellettato
> Developing thesis on SCTP at Univ. of Parma (Italy)
> On stage at Siemens I.C.N. Italy
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock AT 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 ¦

---

• [SCTP-Discussion] Path failure in multi-homing scenario, Alberto Bellettato, 01/22/2002
  • Re: [SCTP-Discussion] Path failure in multi-homing scenario, Brian F. G. Bidulock, 01/22/2002
  • <Possible follow-up(s)>
  • RE: [SCTP-Discussion] Path failure in multi-homing scenario, Tuexen Michael, 01/22/2002
    • RE: [SCTP-Discussion] Path failure in multi-homing scenario, Alberto Bellettato, 01/23/2002
      • Re: [SCTP-Discussion] Path failure in multi-homing scenario, Michael Tuexen, 01/23/2002
  • RE: [SCTP-Discussion] Path failure in multi-homing scenario, Tuexen Michael, 01/25/2002

---

Archive powered by MHonArc 2.6.19+.