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

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 <per.hurtig@kau.se> 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: internet-drafts@ietf.org
> To: Andreas Petlund <apetlund@simula.no>, "Andreas Petlund"
> <apetlund@simula.no>, "Michael Welzl" <michawe@ifi.uio.no>, Per Hurtig
> <per.hurtig@kau.se>, Michael Welzl <michawe@ifi.uio.no>, "Per Hurtig"
> <per.hurtig@kau.se>, Anna Brunstrom <anna.brunstrom@kau.se>, "Anna
> Brunstrom" <anna.brunstrom@kau.se>
>
>
> 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
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm