Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-01.txt

From: Yuchung Cheng <[email-masked]>
Date: Wed, 23 Oct 2013 06:57:15 -0700

On Tue, Sep 17, 2013 at 1:44 AM, Per Hurtig <[email-masked]> wrote:

> Hi all,
>
> A revised draft of the RTO restart mechanism has just been submitted
> with the details, below.
>
> The main changes between this and previous drafts are:
>
> * Improved wording throughout the document.
>
> * Removed the possibility for a connection limited by the receiver's
> advertised window to use RTO restart, decreasing the risk of spurious
> timeouts.
>
> * A new section that discusses the applicability of and problems related
> to the RTO restart mechanism.
>
> * Updates to the text that describe RTO restart's relation to TLP.
>
> * Acknowledgments added.
>
>
> We're happy to receive any feedback!
>
I suggest removing the constraint in (2) of section 3. RTO re-arm should
account for the time elapsed since the SND.UNA was last (re)transmitted,
either cwnd is 1 or 10000. There is always risk for spurious timeout but
that's another bug on RTT estimation.

>
> Per
>
>
>
> On 09/17/2013 10:36 AM, [email-masked] wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the TCP Maintenance and Minor Extensions
> Working Group of the IETF.
> >
> >       Title           : TCP and SCTP RTO Restart
> >       Author(s)       : Per Hurtig
> >                           Anna Brunstrom
> >                           Andreas Petlund
> >                           Michael Welzl
> >       Filename        : draft-ietf-tcpm-rtorestart-01.txt
> >       Pages           : 11
> >       Date            : 2013-09-17
> >
> > Abstract:
> >    This document describes a modified algorithm for managing the TCP and
> >    SCTP retransmission timers that provides faster loss recovery when
> >    there is a small amount of outstanding data for a connection.  The
> >    modification allows the transport to restart its retransmission timer
> >    more aggressively in situations where fast retransmit cannot be used.
> >    This enables faster loss detection and recovery for connections that
> >    are short-lived or application-limited.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-01
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-01
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
>
>
> --
> Per Hurtig, PhD                Tel: +46 (0) 54 700 2335
> Datavetenskap                  Kontor: 21F-422 (Hus Vanern)
> Karlstads universitet          PGP 0x8C4FFCF6
> SE-651 88 Karlstad             http://www.kau.se/forskare/per-hurtig
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Anna Brunstrom <[email-masked]>
Date: Sat, 26 Oct 2013 01:31:09 +0200

Hi Yuchung,

Removing the constraint has been discussed before and the very first 
draft we put together for RTO restart actually worked like that. After 
some off-list discussions with Mark Allman and others, the constraint 
was put in.

Even if it is conceptually simpler to remove the constraint, it would be 
a disadvantage to reduce the RTO in situations where we have a 
continuous flow of data and do not want the RTO to fire even if there is 
a packet loss. In these cases it is better if a fast retransmit is 
triggered.

Thanks,
Anna

On 2013-10-23 15:57, Yuchung Cheng wrote:
>
>
>
> On Tue, Sep 17, 2013 at 1:44 AM, Per Hurtig <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     On 09/17/2013 10:36 AM, [email-masked]
>     <mailto:[email-masked]> wrote:
>      >
>      > A New Internet-Draft is available from the on-line
>     Internet-Drafts directories.
>      >  This draft is a work item of the TCP Maintenance and Minor
>     Extensions Working Group of the IETF.
>      >
>      > until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>      >
>      > [email-masked] <mailto:[email-masked]>
>     <tel:%2B46%20%280%29%2054%20700%202335>
>     [email-masked] <mailto:[email-masked]>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 30 Oct 2013 08:14:36 -0700

On Fri, Oct 25, 2013 at 4:31 PM, Anna Brunstrom <[email-masked]> wrote:
> Hi Yuchung,
>
> Removing the constraint has been discussed before and the very first draft
> we put together for RTO restart actually worked like that. After some
> off-list discussions with Mark Allman and others, the constraint was put in.
>
> Even if it is conceptually simpler to remove the constraint, it would be a
> disadvantage to reduce the RTO in situations where we have a continuous flow
> of data and do not want the RTO to fire even if there is a packet loss. In
> these cases it is better if a fast retransmit is triggered.
if inflight is large than spurious timeout is even less a concern b/c
we expect plenty of acks to refresh the estimator.

Step back a bit: what's RTO? isn't it the max time we expect the ack
to come back for first unacked packet (SND.UNA)?

The starting time should always be the last (re)transmission of that
packet (as in rto-restart). Conceptually and practically it has
nothing to do w/ number of packets I sent after (inflight). Why keep
tweaking things based on cwnd or inflight. In fact many other
transport protocols implement rto-restart natually, because that's how
timer should be re-armed.

The real concern is that RTO has been re-armed in the wrong way for a
quarter of century, so the formula has been tighten up for faster
timeout (e.g., Linux 200ms min-RTO). But IMO it's wrong to patch up
one thing for the other. Let's do rto-restart always, and fix the RTO
formula too.