[e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers?

[Jasleen Kaur]

Paddy,

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.
http://www.cs.unc.edu/~jasleen/papers/icnp07.pdf

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.
http://www.cs.unc.edu/~jasleen/papers/ccr06.pdf

We'd welcome any feedback.

Thanks,
Jasleen


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