Jasleen,<br><br>Thank you for the pointers.Your ICNP '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) . 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 <<a href="mailto:jasleen@cs.unc.edu">jasleen@cs.unc.edu</a>> 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'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'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've found that RTOs are still pretty common (more than FR/R).
<br>Interestingly, we'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, "A Performance Study of Loss<br>Detection/Recovery in Real-world TCP Implementations", in Proceedings of<br>the IEEE International Conference on Network Protocols (ICNP'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, "A Passive State-Machine Approach for
<br>Accurate Analysis of TCP Out-of-Sequence Segments", 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'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>> Hello e2e,<br>><br>> Does anyone have some quantitative experimental data on what
<br>> percentage of reliable packet delivery in TCP is done through Fast<br>> Retransmit versus that of a RTO expiry? Specifically I am looking at<br>> such data being available for HTTP class of traffic.<br>>
<br>> Some raw issues that lead for such data to be interesting:<br>><br>> (a) When the initial cwnd is less than 4 then there is a chance that<br>> initial SYN/SYNACK oss cannot be recovered using FastRetransmit (this
<br>> is also worse than RTO expiry because of additional 3 seconds).Magic<br>> value of 4 seems to be from the paper Morris' /Scalable TCP<br>> Congestion Control/<br>><br>> (b) The last packet isnt eligible for fast retransmit as well by the
<br>> same logic albeit this time the recovert via RTO<br>><br>> (c) In between (a) and (b) lets say we have a train of packets<br>> (dictated by the cwnd size or the application's PSH). If you imagine<br>
> this flight of packets as a train, the last packet of such a burst<br>> cannot also be recovered using fast retransmit<br>><br>> (d) Some other cases that I am not thinking of here.<br>><br>> Given that HTTP traffic seems to be like small bursts of packet
<br>> trains, there will be many last packets in a train and hence response<br>> time suffers on lossy/congested networks.<br>><br>> -Paddy Ganti<br><br></div></div></blockquote></div><br>