From: Joshua Blanton (jblanton@cs.ohiou.edu)
Date: 10/30/03
Date: Thu, 30 Oct 2003 08:49:47 -0500 From: Joshua Blanton <jblanton@cs.ohiou.edu> Subject: Re: tcptrace RTT time evolution; SACK in tcptrace Message-ID: <20031030134947.GA11898@dhcp-064-247-066-180.sg1.ohiou.edu>
When SACK is enabled, fast retransmits have a different definition (standards-
wise), and on top of that many senders don't follow the standard. :-)
According to RFC3517, when (1) at least 3SMSS bytes of data are SACKed or
(2) 3 discontiguous SACK blocks have been received from the receiver, the
sender is to trigger loss recovery (which is in effect a fast retransmit).
That said, many senders don't follow the standard (as it's quite new).
You might look at the SACK data and see, though, if that's the behavior
that you are observing.
As to what tcptrace does with SACK, I don't know offhand - but I'm sure
someone on the list could tell you faster than I. :-)
--jtb
Juan Francisco Torreblanca wrote:
> Regarding the question of retransmission due to RTO or packet loss
> detection, I've been checking tcptrace stats with the relative ethereal
> trace following Mani suggestion and they don't match: retrx packets 5,
> triple dupacks 2, but no more than 1 RTO has happened.
>
> Probably SACK option (which it is enabled) affects to this mismatching,
> looking into the traces I found that a retx happens with 3 dupacks
> (containing SACK) and in a short time a couple of retx happens only with
> 2 dupacks (containing SACK), I don't know how congestion control acts
> after a retx due to SACK, any hint? And also, does anyone know how
> tcptrace treats SACK? (Could it be known the number of retx due to
> SACK?)
----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.
This archive was generated by hypermail 2.1.7 : 10/30/03 EST