SCTP Discussions

Text archives Help


[SCTP-Discussion] Implementation bugs?


Chronological Thread 
  • From: "Alberto Bellettato" <abell AT libero.it>
  • To: <discussion AT sctp.de>
  • Subject: [SCTP-Discussion] Implementation bugs?
  • Date: Sun Nov 25 17:42:00 2001
  • List-id: SCTP Discussions <discussion.sctp.de>

Hello all,
I'm developing an application for perfomance evaluation of SCTP using
SctpLib vers.14. I think having found 2 bugs in the implementation. I would
be grateful if you could confirm my suspects.

1) Under the following conditions I got a 'Segmentation fault' error.
An association has been established between 2 multihomed hosts (each one has
2 interfaces that are connected 2 by 2 through a direct cross-cable).
Initially both the 2 paths are active.
Then I disconnect the primary path (physically unplugging the cross cable).
BEFORE networkStatusChangeNotif() callback was called (i.e. before sctp
implementation consider the disconnected path inactive), I begin to send
some (for ex. 100) data messages with the same size, chosen in the interval
(600,1450) bytes. Each message is sent calling repetitively the function
sctp_send() after a constant delay value (for ex. 20ms), using the function
sctp_startTimer().
In this condition sctp implementation tries to send all messages on the
primary path, but it receives neither any SACK nor any HEARTBEAT_ACK,
because that path has been physically disconnected. So it is used the
retransmission algoritm for all messages, that begin to be transmitted
successfully on the secondary path.
After some (4 or 5) messages' receiving I get a 'Segmentation fault' error
on
the receiving machine (but sometimes it happens on the sending machine
first).
The strange fact is that this error happens only for messages sized with a
value in the interval (600,1450) bytes.
Using messages sized with other values results in a correct behavior
(slowing down connection because of retransmissions, until sctp
implementantion considers inactive the primary path and then it switches the
primary path to the secondary one).

2) sctp_startTimer() function has problems with small delays.
I use sctp_startTimer() to set throughput of the sent messages, adjusting
delay timing passed to this function. For example, in order to obtain a
2Mbit/s throughput using 1000bytes messages, I call a function containing
the sctp_send() every 4 milliseconds through the sctp_startTimer() function.
The problem is that sctp_startTimer() works good only passing delay values
>= 15milliseconds. If I pass a 4ms value, sctp_startTimer() assumes it as it
would be 20ms.
I thought it could depend on some clock's granularity, but sctp_startTimer()
strangely works good with values of 2ms and 3ms (but not with 6ms, 8ms...).

I am using Linux Redhat 6.2 on 2 pentium machines (128MB ram), and each one
has got 2 network interfaces connected through 2 cross cables.


Best regards,
Alberto Bellettato
University of Parma, on training at Siemens Information and Communication
Networks
Italy







Archive powered by MHonArc 2.6.19+.

Top of page