- From: Alberto Bellettato <Alberto.Bellettato AT icn.siemens.it>
- To: discussion AT sctp.de
- Subject: RE: [SCTP-Discussion] Path failure in multi-homing scenario
- Date: Wed Jan 23 16:57:01 2002
- List-id: SCTP Discussions <discussion.sctp.de>
Hello Michael, hello Brian,
1. I modified Path.Max.Retransmits to 3 and RTO.max to 3000 millisec
As Brian Bidulock explained, granularity is caused by RTO.min set to
default value of 1000 millisec. But I don't understand how delay for the first
retransmitted packets is only 0.5 sec (and not RTO.min).
As Brian suggested (thanks!), I tried to reduce RTO.min value. I found a
stable (no false retransmits) configuration setting RTO.min to 10 millisec
and Path.Max.Retransmit to 5. So I obtained this graph:
http://spazioweb.inwind.it/stazionebase/graphbetter.jpg
Changeover is reduced to about 400 milliseconds and peak delay value is only
about 80 millisec.
I can understand linear decrementing traits, only assuming that implementation
runs a single T3-rtx timer for all chunks present in the send queue; I mean
that, after RTO expiring, implementation retransmits all chunks present in the
send queue and it restarts a T3-rtx timer only for the next set of chunks (and
not for every chunk inserted in the queue). Could you confirm if I am right?
2. When a data message arrives to the upper layer of the receiving machine
(notification DataArriveNotify), it is sent back to the sender, without
any modification. When echoed message arrives to the sender, [(current
time)-(timestamped sending time)]/2
gives the delay time.
Best regards,
Alberto
On Tue, 22 Jan 2002, you wrote:
>
Hello Alberto,
>
>
thank you very much for the measurement. Before making more
>
detailed commetents on that I have two questions:
>
1. Have you modified SCTP timers? The delays have a 'granularity'
>
of 500 ms. This is something I do not understand.
>
2. How do you send back the packets with the timestamps?
>
>
Best regards
>
Michael
Archive powered by MHonArc 2.6.19+.