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

[Mellia Marco]

Your intuition is quite right... RTO kicks in much more often than FR...

There are a couple of papers/ideas/rfcs that try to address this problem.
You may have a look at this paper... in which we explicitely study the 
problem you mention, and compare our proposal to others'.

M. Mellia, M. Meo, C. Casetti
TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency
IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN: 
1063-6692, April 2005

http://www.tlc-networks.polito.it/mellia/papers/TNG-TCP-SF.ps

In addition, we are continously monitoring TCP retransmission using tstat.
Some measurements are available on-line from tstat web site
Http://www.tstat.polito.it


E.G.
http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&var=tcp_anomalies&dir=rrd_data/FW/LIVE&logscale=&bigpic=true&advopt=true&yauto=false&ymax=10&direction=both&advcmd=&describe=&hifreq=false&ymin=-10

Hope you find this useful.

Ciao,
Marco

> 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