Subject: Re: [tcpm] Fwd: New Version Notification for draft-ietf-tcpm-rtorestart-03.txt

From: Yuchung Cheng <[email-masked]>
Date: Wed, 8 Oct 2014 09:17:40 -0700

Hi

I have been testing the RTO-restart in Linux (with my own
implementation) and noticed an interesting issue.

Section 4 says:

      (3)  Restart the retransmission timer so that it will expire after
           "RTO - T_earliest" seconds (for the current value of RTO).

 What if RTO - T_earliest <= 0? this implies the retransmission is
past due and we should timeout?

But consider this case:
T0: send 3 packets. RTO is 1s
T1000: timeout, retransmit packet 1. cwnd=1, rto=2000
T3000: timeout again. retransmit packet 2. cwn=1, rto=4000
T3050: receive ACK1

At this moment, if the connection uses TS-opt, we'll take a new RTT
sample and reset rto to 1s (for example).
Since T_earliest = 3050, RTO - T_earliest = -2050.

Without RTO-restart we'll slow start cwnd from 1 to 2 and retransmit
packet 2 and packet 3.
But with RTO-restart, if we timeout immediately, we'll reset cwnd to 1
and only retransmit packet 2 b/c cwnd is smaller.

I think a better response is to consider the first unacked packet is
lost, but not necessarily reset cwnd to 1. bc in this
case the connection is making forward progress, and the lost of packet
2 is really caused by a much older event.

We can tweak the example so that RTO - T_earliest is not negative but
a very small value, and the same issue may occur (e.g., resetting cwnd
while connection is making forward progress)

On Fri, Jul 4, 2014 at 5:10 AM, Per Hurtig <[email-masked]> wrote:
> Hi all,
>
> the newest version of the RTO restart (RTOR) draft address the issues
> pointed out in Alexander's review. A summary of changes is shown below.
>
> We've also performed a series of experiments to assess RTOR's performance.
> Results from these experiments can be found at:
>
> http://riteproject.eu/resources/rto-restart/#the-benefits
>
> o  Updated the document to use "RTOR" instead of "RTO Restart" when
>    refering to the modified algorithm.
>
> o  Moved document terminology to a section of its own.
>
> o  Introduced the rrthresh variable in the terminology section.
>
> o  Added a section to generalize the tracking of outstanding
>    segments.
>
> o  Updated the algorithm to work when the number of outstanding
>    segments is less than four and one segment is ready for
>    transmission, by restarting the timer when new data has been sent.
>
> o  Clarified the relationship between fast retransmit and RTOR.
>
> o  Improved the wording throughout the document.
>
>
> Cheers,
> Per
>
>
> -------- Original Message --------
> Subject: New Version Notification for draft-ietf-tcpm-rtorestart-03.txt
> Date: Fri, 04 Jul 2014 05:02:44 -0700
> From: [email-masked]
> To: Andreas Petlund <[email-masked]>, "Andreas Petlund"
> <[email-masked]>, "Michael Welzl" <[email-masked]>, Per Hurtig
> <[email-masked]>, Michael Welzl <[email-masked]>, "Per Hurtig"
> <[email-masked]>, Anna Brunstrom <[email-masked]>, "Anna
> Brunstrom" <[email-masked]>
>
>
> A new version of I-D, draft-ietf-tcpm-rtorestart-03.txt
> has been successfully submitted by Per Hurtig and posted to the
> IETF repository.
>
> Name:           draft-ietf-tcpm-rtorestart
> Revision:       03
> Title:          TCP and SCTP RTO Restart
> Document date:  2014-07-04
> Group:          tcpm
> Pages:          13
> URL: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rtorestart-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/
> Htmlized:       http://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-03
> Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-03
>
> 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, RTO Restart (RTOR), 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.
>
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 9 Oct 2014 12:34:14 +0300

Hi,

Thanks, Yuchung, for bringing this up. It reminds me of an old note I sent to the list quite a long while ago: I think it would be good if the algorithm was designed so that it cannot (even in theory) result in negative RTO values. The most straightforward way to fix this would be to include some kind of max(RTO - T_earliest, some_threshold) guard in the algorithm. It might not protect against spurious timeouts, but at least would keep the values in sensible range.

- Pasi

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 9 Oct 2014 10:32:24 -0700

> Thanks, Yuchung, for bringing this up. It reminds me of an old note I sent to the list quite a long while ago: I think it would be good if the algorithm was designed so that it cannot (even in theo…

This would work but it might reduce the benefit (and adding yet
another magic threshold). A negative value is a
strong signal that the first unacked packet is lost. The problem in my
case is the reaction is not appropriate (reset cwnd again) because we
have just make some forward progress.

IMO cwnd should be reset if nothing has been delivered (no (s)acks)
for the whole RTO. It's similar philosophy like fast recovery and tail
loss probe.

---

From: Pasi Sarolahti <[email-masked]>
Date: Thu, 9 Oct 2014 21:49:13 +0300

> have just make some forward progress.

Right, magic numbers are not nice (but it could be 0, just to prevent negatives). Or then the draft should otherwise discuss handling of negative values, and make it clear if there might be such. Some implementations might define RTO as unsigned, in which case a negative value becomes very large value…

- Pasi

---

From: Per Hurtig <[email-masked]>
Date: Mon, 13 Oct 2014 10:48:02 +0200

Hi all,

I agree that we should formalize what to do if the timeout becomes
negative due to RTOR. In our current implementation we don't invoke RTOR
at all if the resulting value (RTO - T_earliest) is <= 0. That is, it
has to be a positive number.

I think this is a fair trade-off, and could be included in the coming
internet-draft. Do you think it's too conservative?

Cheers,
Per

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 13 Oct 2014 09:20:04 -0700

On Mon, Oct 13, 2014 at 1:48 AM, Per Hurtig <[email-masked]> wrote:
>>>> Thanks, Yuchung, for bringing this up. It reminds me of an old note I
>>>> sent to the list quite a long while ago: I think it would be good if the
>>>> algorithm was designed so that it cannot (even in theory) result in negative
>>>> RTO values. The most straightforward way to fix this would be to include
>>>> some kind of max(RTO - T_earliest, some_threshold) guard in the algorithm.
>>>> It might not protect against spurious timeouts, but at least would keep the
>>>> values in sensible range.
>>>
>>>
>> Right, magic numbers are not nice (but it could be 0, just to prevent
>> negatives). Or then the draft should otherwise discuss handling of negative
>> values, and make it clear if there might be such. Some implementations might
>> define RTO as unsigned, in which case a negative value becomes very large
>> value…
>>
>> - Pasi
>>
>
> Hi all,
>
It's not conservative. It's just awkward.

If RTO - T_earliest is 1 ms, we retransmit almost right away. If it's
past due (<= 0), we wait another RTO. The fix would work, it just
sound like a hack. Sorry I try to be polite but I couldn't find a
better word...

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 17 Oct 2014 19:00:00 +0200

> sound like a hack. Sorry I try to be polite but I couldn't find a
I agree it is not conservative, but I do not think it is so awkward.  
When you have a retransmission the ACK will arrive after RTO+RTT. And if 
you sent multiple packets to start with, then the calculated value of 
(RTO - T_earliest) will (most likely) be negative. This was the example 
that started this discussion and as pointed out, you do not want to use 
RTOR in this case as the segment will be immediately retransmitted 
anyway. Not invoking RTOR for negative values captures this case. From 
an algorithmic standpoint I cannot think of another scenario without 
retransmission where the value would be negative. (If we can come up 
with one, or one exists that we cannot think of, it may still be safe to 
not use RTOR.)

If you tweak the send pattern in the example with the retransmission you 
can also get a small value. In theory this should not matter as the RTO 
will be reset anyway when the segment is retransmitted in response to 
the ACK. You can however also get small values during normal 
transmission, where you want to use RTOR, and this is the reason to use 
RTOR for positive values.

So from an algorithmic standpoint I think not invoking RTOR when (RTO - 
T_earliest) is <= 0 captures the behavior we want. Maybe in practice 
there is some possibility to rearm and have the RTO fire before the 
retransmission in response to the ACK will happen though? If so, this 
retransmission would better be avoided.

A perhaps better alternative could be to state that RTOR is not used for 
ACKs that acknowledge retransmitted (and previously unacknowledged) 
segments. That is what we want to avoid anyway.

Cheers,
Anna