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

From: Anna Brunstrom <[email-masked]>
Date: Sat, 02 Nov 2013 01:12:45 +0100

Hi,

On 2013-10-30 16:14, Yuchung Cheng wrote:
> 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.

But the negative effect of an unwanted/spurious RTO is much larger and 
there is no gain to be made in this case.

>
> 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.

I agree that it is conceptually cleaner, but it will not work as well.

The RTO value is a trade-off between timely loss detection and 
triggering the timer unnecessarily. This trade-off is different when you 
have very few segments inflight. In this case you really need the timely 
loss detection.

When you have many segments inflight you do not want to detect loss 
through a RTO so having a larger value makes sense from a performance 
perspective. Here the RTO is only a very last resort in case you lose an 
entire window of packets. In this case you have big problems anyway.

> 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.

I doubt that the RTO restart issue is the main reason the RTO has been 
tightened.

Anyway, I think it is outside the scope of the RTO restart draft to 
modify the RTO formula.

BR,
Anna

>
>>
>> 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,
>>>
>>>      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]
>>>      <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.
>>>       >
>>>       >       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 <http://tools.ietf.org>.
>>>
>>>       >
>>>       > Internet-Drafts are also available by anonymous FTP at:
>>>       > ftp://ftp.ietf.org/internet-drafts/
>>>       >
>>>       > _______________________________________________
>>>       > tcpm mailing list
>>>       > [email-masked] <mailto:[email-masked]>
>>>
>>>       > https://www.ietf.org/mailman/listinfo/tcpm
>>>       >
>>>
>>>
>>>      --
>>>      Per Hurtig, PhD                Tel: +46 (0) 54 700 2335
>>>      <tel:%2B46%20%280%29%2054%20700%202335>
>>>
>>>      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] <mailto:[email-masked]>
>>>      https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>>

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 1 Nov 2013 17:49:14 -0700

On Fri, Nov 1, 2013 at 5:12 PM, Anna Brunstrom <[email-masked]> wrote:
> But the negative effect of an unwanted/spurious RTO is much larger and there
> is no gain to be made in this case.
>
>
>>
> The RTO value is a trade-off between timely loss detection and triggering
> the timer unnecessarily. This trade-off is different when you have very few
> segments inflight. In this case you really need the timely loss detection.
This makes no sense.

T0: send 6 packets P1, P2, ... P6
T100: got ACK of P1, adjust RTT, P2 should timeout at T100+rto
T105: got ACK of P2, adjust RTT, P3 should timeout at T200+rto
T110: got ACK of P3, adjust RTT, P4 should timeout at T0+rto because
         "hey we got only 3 packets inflight so I gotta be less patient"??

so maybe if I only 2 packets inflight I should do T-1 + rto.

>
> When you have many segments inflight you do not want to detect loss through
> a RTO so having a larger value makes sense from a performance perspective.
> Here the RTO is only a very last resort in case you lose an entire window of
> packets. In this case you have big problems anyway.
>
>
> Anyway, I think it is outside the scope of the RTO restart draft to modify
> the RTO formula.
I certainly not suggest modify the RTO formula in this draft.

---

From: Anna Brunstrom <[email-masked]>
Date: Sun, 03 Nov 2013 05:19:41 +0100

Hi,

>           "hey we got only 3 packets inflight so I gotta be less patient"??

The difference is that P4 can not be recovered by fast retransmit. If P4 
is lost we will rely on a timeout to recover the packet. In this case 
there is a potential gain to be made by reducing the timeout.

If we get an RTO when we have a sufficient number of ACKs on its way to 
trigger a fast retransmit it does not gain us anything. Consider this 
example. A packet is lost when you have 100 packets inflight and 
additional data queued for transmission. Would you prefer to recover 
this packet by fast retransmit or RTO?

If you prefer a fast retransmit why would you want to increase the 
likelihood of an RTO by reducing the timeout value in this case?

BR,
Anna