[e2e] Any Data on Fast Retransmit vs RTO Expiry Numbers?
pganti at gmail.com
Tue Dec 18 14:47:07 PST 2007
Thank you for the pointers.Your ICNP '07 is very good as it is exactly
looking at what I am proposing to do.
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).
On Dec 18, 2007 3:56 PM, Jasleen Kaur <jasleen at cs.unc.edu> wrote:
> 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.
> 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.
> We'd welcome any feedback.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the end2end-interest