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

[Paddy Ganti]

Marco,

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?

-Paddy


On Dec 18, 2007 4:37 PM, Mellia Marco <mellia at tlc.polito.it> wrote:

>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20071218/025cfdc0/attachment.html