Jasleen,<br><br>Thank you for the pointers.Your ICNP &#39;07 is very good as it is exactly looking at what I am proposing to do.<br><br>Speaking of feedback, I have a quick question on splicing your data further. I want to know what your data will look like if I were to eliminate the SYN packets and then the FIN packet (more precisely the last packet) .&nbsp; On Table V in the paper regarding dupack threshold I have seen implementations with 1 and an extra timer (both ends of the stack speak modified TCP and hence they could get away with it).
<br><br>-Paddy<br><br><div class="gmail_quote">On Dec 18, 2007 3:56 PM, Jasleen Kaur &lt;<a href="mailto:jasleen@cs.unc.edu">jasleen@cs.unc.edu</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>Paddy,<br><br>You&#39;ll find our recent work on studying the performance of TCP loss<br>detection useful (please see the two citations below). One of the<br>data-sets we&#39;ve used (ibi) is collected from a cluster of web-servers
<br>--- however, this cluster also handles some fairly large file transfers.<br><br>The first paper below studies the impact of configuring RTO and FR/R<br>parameters on the durations of TCP connections.<br>We&#39;ve found that RTOs are still pretty common (more than FR/R).
<br>Interestingly, we&#39;ve found that reconfiguring the parameters<br>associated with these can help improve the situation to some extent (the<br>overall impact on connection durations can sometimes<br>be quite significant).
<br><br>S. Rewaskar, J. Kaur, and F.D. Smith, &quot;A Performance Study of Loss<br>Detection/Recovery in Real-world TCP Implementations&quot;, in Proceedings of<br>the IEEE International Conference on Network Protocols (ICNP&#39;07),
<br>Beijing, China, Oct 2007.<br><a href="http://www.cs.unc.edu/%7Ejasleen/papers/icnp07.pdf" target="_blank">http://www.cs.unc.edu/~jasleen/papers/icnp07.pdf</a><br><br>Rewaskar, J. Kaur, and F.D. Smith, &quot;A Passive State-Machine Approach for
<br>Accurate Analysis of TCP Out-of-Sequence Segments&quot;, in ACM Computer<br>Communications Review (CCR), July 2006.<br><a href="http://www.cs.unc.edu/%7Ejasleen/papers/ccr06.pdf" target="_blank">http://www.cs.unc.edu/~jasleen/papers/ccr06.pdf
</a><br><br>We&#39;d welcome any feedback.<br><br>Thanks,<br><font color="#888888">Jasleen<br></font><div><div></div><div class="Wj3C7c"><br><br>Paddy Ganti wrote:<br>&gt; Hello e2e,<br>&gt;<br>&gt; Does anyone have some quantitative experimental data on what
<br>&gt; percentage of reliable packet delivery in TCP is done through Fast<br>&gt; Retransmit versus that of a RTO expiry? Specifically I am looking at<br>&gt; such data 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<br>&gt; Congestion 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<br>&gt; (dictated by the cwnd size or the application&#39;s PSH). If you imagine<br>
&gt; this flight of packets as a train, the last packet of such a burst<br>&gt; cannot also be 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
<br>&gt; trains, there will be many last packets in a train and hence &nbsp;response<br>&gt; time suffers on lossy/congested networks.<br>&gt;<br>&gt; -Paddy Ganti<br><br></div></div></blockquote></div><br>