From: Guohan Lu (lguohan00@mails.tsinghua.edu.cn)
Date: 02/26/04
Message-ID: <277853331.21991@mails.tsinghua.edu.cn> Message-ID: <005701c3fce3$fa2e2610$6401a8c0@lyfnotebook> From: "Guohan Lu" <lguohan00@mails.tsinghua.edu.cn> Subject: Re: tcptrace Regarding RTO value of Linux TCP Date: Fri, 27 Feb 2004 11:44:11 +0800
In Linux version 2.4, the minimum value of RTO is 200 ms, and the retransmission timer
granularity is of 10ms in default.
See Pasi Sarolahti, Alexey Kuznetsov, "Congestion Control in Linux TCP", USENIX02
Guohan Lu
----- Original Message -----
From: "Liangping Ma" <lma@mail.eecis.udel.edu>
To: "Ruhai Wang" <wangnewton2000@yahoo.com>
Cc: "Juan Francisco Torreblanca" <juan.torreblanca@tartec.com>; <tcptrace@tcptrace.org>
Sent: Friday, February 27, 2004 9:39 AM
Subject: RE: tcptrace Regarding RTO value of Linux TCP
> Hi, all,
>
> I do not quite agree with several of the preceeding messages.
>
> I think RTOs are constant to some extent in current TCP
> implementations. True, the RTTs are dynamic, so are the RTOs.
> But in reality (see RFC 2988, http://www.faqs.org/rfcs/rfc2988.html), the
> computed RTOs are compared to a so-called minimum RTO. If the RTOs are
> less than the minimum RTO, then they are rounded to that minimum RTO.
> For example, if the computed RTOs are all less than 1 second, and if the
> minimum RTO is set to 1 second, then the RTOs, after this processing, will
> be all equal to 1 second.
>
> Liangping
>
>
> On Thu, 26 Feb 2004, Ruhai Wang wrote:
>
> > Juan:
> >
> > Thanks for the response. You did answer my question.
> >
> > I believe your understanding is correct.
> >
> > The question originally came from a discussion about
> > packets retransmissions. Please see the attached pdf
> > file which contains two TSG and one RTT plots. The
> > second TSG plot is the enlarged view of a
> > retransmission scenario in which four consecutive
> > packets are retransmitted as you can observe clearly.
> > The RTT is for the transmission which has two
> > retransmission scenarios occurred. The transmission
> > was done using Linux 7.4 TCP SACK over a CLEAN channel
> > (BER=0) with RTT around 270 ms in a lab. It appears
> > the retransmissions are caused by retransmission timer
> > out rather than bit error corruption since no bit
> > error is introduced to the channel. What do you think?
> >
> >
> > Wang
> >
> > --- Juan Francisco Torreblanca
> > <juan.torreblanca@tartec.com> wrote:
> > > RTO changes dynamically based on every measured RTT.
> > > As far as I know, RTO doesn't have a known value for
> > > any TCP implementation, are you referring to this or
> > > am I missing something?
> > >
> > > Rgds,
> > > Juan Torreblanca.
> > >
> > > -----Original Message-----
> > > From: Ruhai Wang [mailto:wangnewton2000@yahoo.com]
> > > Sent: s?ado, 21 de febrero de 2004 21:50
> > > To: tcptrace@tcptrace.org
> > > Subject: tcptrace Regarding RTO value of Linux TCP
> > >
> > > Does anyone know the specified value of
> > > Retransmission
> > > Time Out(RTO) for Red Hat Linux 7.4 TCP?
> > >
> > > Thanks!
> > >
> > > Wang
> > >
> > > __________________________________
> > > Do you Yahoo!?
> > > Yahoo! Mail SpamGuard - Read only the mail you want.
> > > http://antispam.yahoo.com/tools
> > >
> > ----------------------------------------------------------------------------
> > > To unsubscribe, send a message with body containing
> > > "unsubscribe tcptrace" to
> > > majordomo@tcptrace.org.
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Get better spam protection with Yahoo! Mail.
> > http://antispam.yahoo.com/tools
>
> ----------------------------------------------------------------------------
> To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
> majordomo@tcptrace.org.
>
----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.
This archive was generated by hypermail 2.1.7 : 02/27/04 EST