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

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 [anna.brunstrom@kau.se]
Gesendet: Freitag, 23. Oktober 2015 23:49
An: Scharf, Michael (Michael); spencerdawkins.ietf@gmail.com
Cc: tcpm@ietf.org
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:tcpm-bounces@ietf.org] On Behalf Of Per Hurtig
>> Sent: Wednesday, October 21, 2015 9:55 AM
>> To: tcpm@ietf.org Extensions
>> Cc: bclaise@cisco.com; barryleiba@computer.org
>> 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, internet-drafts@ietf.org 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
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm