Marco,<br><br>Thank you for the live data pointer. Your paper looks very interesting (still need to digest all of whats being said though). I have one suggestion which you might have already thought about when proposing smart framing: Why not resend cloned packets of the last one after the last one? I mean,only for the first (send 2 SYNs spaced at 600ms0 and last packets, why cant we modify the stack to send 2 copies of the last packet for FR. Would this crash stacks? 
<br><br>-Paddy<br><br><br><div class="gmail_quote">On Dec 18, 2007 4:37 PM, Mellia Marco &lt;<a href="mailto:mellia@tlc.polito.it">mellia@tlc.polito.it</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Your intuition is quite right... RTO kicks in much more often than FR...<br><br>There are a couple of papers/ideas/rfcs that try to address this problem.<br>You may have a look at this paper... in which we explicitely study the
<br>problem you mention, and compare our proposal to others&#39;.<br><br>M. Mellia, M. Meo, C. Casetti<br>TCP Smart Framing: a Segmentation Algorithm to Reduce TCP latency<br>IEEE/ACM Transactions on Networking, Vol. 13, No. 2, pp. 316-329, ISSN:
<br>1063-6692, April 2005<br><br><a href="http://www.tlc-networks.polito.it/mellia/papers/TNG-TCP-SF.ps" target="_blank">http://www.tlc-networks.polito.it/mellia/papers/TNG-TCP-SF.ps</a><br><br>In addition, we are continously monitoring TCP retransmission using tstat.
<br>Some measurements are available on-line from tstat web site<br><a href="Http://www.tstat.polito.it" target="_blank">Http://www.tstat.polito.it</a><br><br><br>E.G.<br><a href="http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&amp;var=tcp_anomalies&amp;dir=rrd_data/FW/LIVE&amp;logscale=&amp;bigpic=true&amp;advopt=true&amp;yauto=false&amp;ymax=10&amp;direction=both&amp;advcmd=&amp;describe=&amp;hifreq=false&amp;ymin=-10" target="_blank">
http://tstat.tlc.polito.it/cgi-bin/tstat_rrd.cgi?template=normidx&amp;var=tcp_anomalies&amp;dir=rrd_data/FW/LIVE&amp;logscale=&amp;bigpic=true&amp;advopt=true&amp;yauto=false&amp;ymax=10&amp;direction=both&amp;advcmd=&amp;describe=&amp;hifreq=false&amp;ymin=-10
</a><br><br>Hope you find this useful.<br><br>Ciao,<br><font color="#888888">Marco<br></font><div><div></div><div class="Wj3C7c"><br>&gt; Hello e2e,<br>&gt;<br>&gt; Does anyone have some quantitative experimental data on what percentage
<br>&gt; of reliable packet delivery in TCP is done through Fast Retransmit<br>&gt; versus that of a RTO expiry? Specifically I am looking at such data<br>&gt; being available for HTTP class of traffic.<br>&gt;<br>&gt; Some raw issues that lead for such data to be interesting:
<br>&gt;<br>&gt; (a) When the initial cwnd is less than 4 then there is a chance that<br>&gt; initial SYN/SYNACK &nbsp;oss cannot be recovered using FastRetransmit (this<br>&gt; is also worse than RTO expiry because of additional 3 seconds).Magic
<br>&gt; value of 4 seems to be from the paper Morris&#39; &nbsp;/Scalable TCP Congestion<br>&gt; Control/<br>&gt;<br>&gt; (b) The last packet isnt eligible for fast retransmit as well by the<br>&gt; same logic albeit this time the recovert via RTO
<br>&gt;<br>&gt; (c) In between (a) and (b) lets say we have a train of packets (dictated<br>&gt; by the cwnd size or the application&#39;s PSH). If you imagine this flight<br>&gt; of packets as a train, the last packet of such a burst cannot also be
<br>&gt; recovered using fast retransmit<br>&gt;<br>&gt; (d) Some other cases that I am not thinking of here.<br>&gt;<br>&gt; Given that HTTP traffic seems to be like small bursts of packet trains,<br>&gt; there will be many last packets in a train and hence &nbsp;response time
<br>&gt; suffers on lossy/congested networks.<br>&gt;<br>&gt; -Paddy Ganti<br><br></div></div></blockquote></div><br>