[e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers?
jasleen at cs.unc.edu
Tue Dec 18 12:56:54 PST 2007
You'll find our recent work on studying the performance of TCP loss
detection useful (please see the two citations below). One of the
data-sets we've used (ibi) is collected from a cluster of web-servers
--- however, this cluster also handles some fairly large file transfers.
The first paper below studies the impact of configuring RTO and FR/R
parameters on the durations of TCP connections.
We've found that RTOs are still pretty common (more than FR/R).
Interestingly, we've found that reconfiguring the parameters
associated with these can help improve the situation to some extent (the
overall impact on connection durations can sometimes
be quite significant).
S. Rewaskar, J. Kaur, and F.D. Smith, "A Performance Study of Loss
Detection/Recovery in Real-world TCP Implementations", in Proceedings of
the IEEE International Conference on Network Protocols (ICNP'07),
Beijing, China, Oct 2007.
Rewaskar, J. Kaur, and F.D. Smith, "A Passive State-Machine Approach for
Accurate Analysis of TCP Out-of-Sequence Segments", in ACM Computer
Communications Review (CCR), July 2006.
We'd welcome any feedback.
Paddy Ganti wrote:
> Hello e2e,
> Does anyone have some quantitative experimental data on what
> percentage of reliable packet delivery in TCP is done through Fast
> Retransmit versus that of a RTO expiry? Specifically I am looking at
> such data being available for HTTP class of traffic.
> Some raw issues that lead for such data to be interesting:
> (a) When the initial cwnd is less than 4 then there is a chance that
> initial SYN/SYNACK oss cannot be recovered using FastRetransmit (this
> is also worse than RTO expiry because of additional 3 seconds).Magic
> value of 4 seems to be from the paper Morris' /Scalable TCP
> Congestion Control/
> (b) The last packet isnt eligible for fast retransmit as well by the
> same logic albeit this time the recovert via RTO
> (c) In between (a) and (b) lets say we have a train of packets
> (dictated by the cwnd size or the application's PSH). If you imagine
> this flight of packets as a train, the last packet of such a burst
> cannot also be recovered using fast retransmit
> (d) Some other cases that I am not thinking of here.
> Given that HTTP traffic seems to be like small bursts of packet
> trains, there will be many last packets in a train and hence response
> time suffers on lossy/congested networks.
> -Paddy Ganti
More information about the end2end-interest