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

On Thu, Oct 9, 2014 at 2:34 AM, Pasi Sarolahti <pasi.sarolahti@iki.fi> wrote:
> 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.

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.

>
> - Pasi
>
>
> On 08 Oct 2014, at 19:17, Yuchung Cheng <ycheng@google.com> wrote:
>
>> 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
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>