Chronological Thread 

< Chronological >      < Thread >

---

Dear Alberto,

I think the 0.5 seconds can be a result of the following behaviour.

You are disconnecting the upper cable. After 1 second the packets are
retransmitted on the lower cable. The receiver uses the lower cable
(as primary path) to send the chunk back. So the round trip time is
1 second. Since you are calculating the one way delay by dividing
the rounf trip time by 2 you get 0.5 seconds, which is wrong.

You can use Ethereal to verify this assumption.

This is one example of problems you can have by not directly measuring
the value you want to measure... So it is interistig work.

Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Alberto Bellettato
> [SMTP:Alberto.Bellettato AT icn.siemens.it]
> Sent: Wednesday, January 23, 2002 3:20 PM
> To:
> discussion AT sctp.de
> Subject: RE: [SCTP-Discussion] Path failure in multi-homing scenario
>
> 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
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• [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+.