From: Hong, Duke (dhong@akamai.com)
Date: 02/27/04
Date: Fri, 27 Feb 2004 09:39:55 -0800 Message-ID: <F05E952D5FF2DB47BE322C5795DEB3E07C8F94@usca1ex-priv1.sanmateo.corp.akamai.com> From: "Hong, Duke" <dhong@akamai.com>
RTO is not a fixed value. When a connection is initiated, it is normally set to iRTO of 3 seconds. RTO is more or less equal to 3*RTT based on a weighted average. Since the RTTs in your plot are in the 3-4 second range, RTO was likely much higher and jtb's assessment that the retrans was SACK initiated is accurate.
-- duke -----Original Message----- From: Joshua Blanton [mailto:jblanton@masaka.cs.ohiou.edu] Sent: Thursday, February 26, 2004 7:43 PM To: Ruhai Wang Cc: Juan Francisco Torreblanca; tcptrace@tcptrace.org Subject: Re: tcptrace Regarding RTO value of Linux TCP 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/28/04 EST