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

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 07 Sep 2005 12:55:47 +0300

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