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

From: Per Hurtig <[email-masked]>
Date: Sun, 1 Nov 2015 18:09:54 +0100

Hi,

if there are no objections we’d go for “timeout duration”?

Cheers,
Per
> On 31 Oct 2015, at 01:49, Scharf, Michael (Michael) <[email-masked]> wrote:
> 
> Maybe the authors could propose an alternative phrasing on the mailing list, picking one of the potential alternative wordings, and update the draft if there is no objection?
> 
> Since this is in the abstract, this seems to me better than waiting for the RFC editor.
> 
> Michael
> 
> ________________________________________
> Von: Anna Brunstrom [[email-masked]]
> Gesendet: Freitag, 23. Oktober 2015 23:49
> An: Scharf, Michael (Michael); [email-masked]
> Cc: [email-masked]
> Betreff: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-09.txt
> 
> Hi Michael,
> 
> I am not a native speaker either, but I agree with you that "timeout
> duration" or "timeout value" sounds more clear.
> 
> BR,
> Anna
> 
> On 2015-10-23 19:38, Scharf, Michael (Michael) wrote:
>> Sorry for speaking up late... Just to cross-check with others. Is the new wording in the abstract...
>> 
>>    The modification, RTO Restart (RTOR), allows the
>>    transport to restart its retransmission timer using a smaller delay,
>>    so that the effective RTO becomes more aggressive in situations where
>>    fast retransmit cannot be used.  This enables faster loss detection
>>    and recovery for connections that are short-lived or application-
>>    limited.
>> 
>> ... indeed clear to everybody? To me (as a non-native speaker) this use of "delay" in the context of the RTO is a bit confusing.
>> 
>> To me, a wording like replacing "delay" by "timeout duration", "timeout value", etc. would sound more familiar. I'd rather use "delay" as a measure between packet (re) transmissions, etc.
>> 
>> For instance, to me the following wording would fit a bit better ...
>> 
>>    The modification, RTO Restart (RTOR), allows the
>>    transport to restart its retransmission timer using a smaller timeout duration,
>>    so that the effective RTO becomes more aggressive in situations where
>>    fast retransmit cannot be used.  This smaller delay before the retransmission enables faster loss detection
>>    and recovery for connections that are short-lived or application-
>>    limited.
>> 
>> But I am not a native speaker. Any thoughts?
>> 
>> (I guess the RFC editor could just review that.)
>> 
>> Michael
>> 
>> 
>>> -----Original Message-----
>>> From: tcpm [mailto:[email-masked]] On Behalf Of Per Hurtig
>>> Sent: Wednesday, October 21, 2015 9:55 AM
>>> To: [email-masked] Extensions
>>> Cc: [email-masked]; [email-masked]
>>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-09.txt
>>> 
>>> Hi,
>>> 
>>> the new draft on RTO restart address the following comments from the
>>> IESG (thanks for the feedback):
>>> 
>>> o  Clarified, in the abstract, that the modified restart causes a
>>> smaller retransmission delay in total.
>>> 
>>> o  Clarified, in the introduction, that the fast retransmit algorithm
>>> may cause retransmissions upon
>>>     receiving duplicate acknowledgments, not that it unconditionally
>>> does so.
>>> 
>>> o  Changed wording from "to proposed standard" to "to the standards
>>> track".
>>> 
>>> o  Changed algorithm description so that a TCP sender MUST track the
>>> time elapsed since the
>>>     transmission of the earliest outstanding segment. This was not
>>> explicitly stated in previous
>>>     versions of the draft.
>>> 
>>> 
>>> Cheers,
>>> Per
>>> 
>>>> On 20 Oct 2015, at 21:39, [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
>>>>        Authors         : Per Hurtig
>>>>                          Anna Brunstrom
>>>>                          Andreas Petlund
>>>>                          Michael Welzl
>>>>    Filename        : draft-ietf-tcpm-rtorestart-09.txt
>>>>    Pages           : 17
>>>>    Date            : 2015-10-20
>>>> 
>>>> Abstract:
>>>>   This document describes a modified sender-side 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 using a smaller
>>> delay,
>>>>   so that the effective RTO becomes more aggressive 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:
>>>> https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-09
>>>> 
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-09
>>>> 
>>>> 
>>>> 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
>> _______________________________________________
>> tcpm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/tcpm
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm