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

[Mellia Marco]

I would not support this... basically you are suggesting to transmit
twice the last segment.
This means adding an overhead of 100% (tothe last segment), that would
be probably helpful only if the first copy get dropped by the network.
Even if the dropping probabilty is quite large, say 5%, you waste 95% of
the bandwidth ...
Probably not a smart choice...
Moreover, after the "last" segment, the server could send a FIN message,
that would cause eventual dup-acks to be generated... Allowing the
sender to immediately retransmit the last segment in case a dup-ack is
received, would do the job in a much more fair fashion...

Marco

> 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 
> <mailto: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
>     <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
>
>