Subject: Re: [tcpm] a different scheme for reacting to spurious RTOs

From: Francesco Vacirca <[email-masked]>
Date: Thu, 20 Oct 2005 13:27:15 +0200

Maybe you are interested in this technical report:
TCP Spurious Timeout estimation in an operational GPRS/UMTS network

http://userver.ftw.at/~ziegler/FTW-TR-2005-008.pdf

We deployed an algorithm to estimate spurious timeout retransmissions by 
passive monitoring that it is based on similar assumptions of F-RTO and 
reported the results on several day traces. The report is based on 
measurements made in the UMTS and GPRS networks of Mobilkom Austria, EU.

regards,

Francesco

Pasi Sarolahti wrote:
> On Fri, 2005-08-26 at 13:29 -0400, ext Mark Allman wrote:
> 
>>We'd very much appreciate comments on the draft, which
>>is:
>>
>>    Mark Allman, Ethan Blanton, Josh Blanton.  Using Spurious
>>    Retransmissions to Adapt the Retransmission Timeout. August
>>    2005. Internet-Draft draft-allman-rto-backoff-00.txt (work in
>>    progress).
>>    http://www.icir.org/mallman/papers/draft-allman-rto-backoff-00.txt
> 
> 
> Thanks for writing this draft. I think it's good to have more
> alternatives for the response algorithm (at least until the WG can find
> a consensus on a standard way of doing the response), as implementors
> might have different criteria for selecting a suitable algorithm. Some
> comments and thoughts below.
> 
> I think there is one remarkable difference between the methods in RFC
> 4015 and this draft that needs to be emphasized more clearly in the
> introduction: In addition to restoring the sending rate, RFC 4015 also
> tries to avoid unnecessary go-back-N retransmissions after spurious
> timeout. This draft, on the other hand, does not change the
> retransmission sequence, and hence does not avoid unnecessary
> retransmissions in case a spurious timeout occurs. Actually, this
> might be something that could also be mentioned in the disadvantages
> section. It is not a disadvantage relative to the standard TCP, but it
> is a disadvantage when comparing this algorithm for example to RFC
> 4015.
> 
> How about considering possibility of bounding K somehow, rather than
> letting it increase indefinitely? While sometimes the blocked state
> can be really long, there also are occasions where RTO is really
> needed to recover from a bursty data loss, even with SACK in use ([1]
> is a nice paper describing observed behavior in GPRS network). So if
> there happened to be an exceptionally long delay spike, but also RTOs
> caused by packet losses, the total performance (from the sender's
> perspective) could be worse with this response than with TCP that does
> not detect spurious timeouts, even in environment that has motivated
> much of the spurious RTO work. I don't know what could be appropriate
> way to limit K: just a fixed, configurable value, or by some adaptive
> method.
> 
> Btw, there is an empty "[]" in the end of Section 1. I believe you
> have forgot to add a citation ref. there.
> 
> - Pasi
> 
> 
> [1] A. Gurtov, M. Passoja, O. Aalto, and M. Raitola. "Multi-Layer
> Protocol Tracing in a GPRS Network", In Proceedings of the IEEE
> Vehicular Technology Conference (Fall VTC2002), Vancouver, Canada,
> Sepember 2002.
> http://www.cs.helsinki.fi/u/gurtov/papers/vtc02.html
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm