First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


Re(2): [SCTP-Discussion] Path failure management


Chronological Thread 
  • From: Michael Tüxen <Michael.Tuexen AT micmac.franken.de>
  • To: <discussion AT sctp.de>
  • Subject: Re(2): [SCTP-Discussion] Path failure management
  • Date: Sat Jul 14 16:14:00 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
Dear Marjan,

well, it does not make much sense for the terminal app to send data
on multiple streams, but for testing ...

So first of all I should say that the implementation does support
bundling only in a limited way. If you really want to implement it,
you need a timer which is started when a sctp_send is called and the
timer is not running yet. The user data is stored and not send.
If sctp_send is called when the timer is running, the user data is
also send. When the timer runs off, you really send the user data,
which means multiple DATA chunks bundled into one SCTP packet. This
bundling precedure is NOT implemented yet.

When does the implementation bundle?

- In case of retransmission multiple DATA chunks are bundled as described
in RFC 2960.
- If you call multiple times sctp_send within an callback function, for
example
the data_arrive_notification.
- In case of transmission, when it was not allowed to send out a SCTP packet
at the time sctp_send was called. So the userdata was stored and is send out
bundled later.

So if you want to have multiple DATA chunks belonging to different streams you
could modify the echo_server or echo_tool to send out DATA chunks on all
streams
when a DATA chunk is received. If you do this in the data_arrive_notification
you should see the behaviour you want to see. But I have to tested this
yet, but
I think it is a good idea and I will do this next week.

Best regards
Michael

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

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

>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
>>
>>
>
>_______________________________________________
>discussion mailing list
>discussion AT sctp.de
>http://www.sctp.de/mailman/listinfo/discussion




Archive powered by MHonArc 2.6.19+.

Top of page