From: Joshua Blanton (jblanton@masaka.cs.ohiou.edu)
Date: 02/26/04
Date: Thu, 26 Feb 2004 22:42:37 -0500 From: Joshua Blanton <jblanton@masaka.cs.ohiou.edu> Subject: Re: tcptrace Regarding RTO value of Linux TCP Message-ID: <20040227034237.GA31148@dhcp-064-247-066-180.sg1.ohiou.edu>
Your assumption that no packets were lost does not really correspond
with the plot that you sent... Right around 59ish seconds, there are
a ton of duplicate acknowledgements, that all carry SACK data for
later segments. This implies (both to the sender and to me) that you
lost four segments. I suspect that if you had a dump on the receiver
side, you would see that you did indeed lose 4 packets along the path -
though I can't particularly prove that. However, I can say that if the
packets were not lost, they were at least delayed by many seconds (until
after the retransmission timer fired and re-sent those four packets).
I don't see any RTOs happening in that plot - the retransmissions look
like SACK recovery. I'm not sure why the sender went into recovery on
the first dupack - but it may have seen that >3*SMSS packets were
missing before the first SACK block and assumed them all to be missing.
--jtb
Ruhai Wang wrote:
> 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?
>
> <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?
-- Those who beat their swords into plowshares usually end up plowing for those who didn't. -- Ben Franklin
----------------------------------------------------------------------------
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