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

From: [email-masked]
Date: Tue, 20 Oct 2015 12:39:54 -0700

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/

---

From: Per Hurtig <[email-masked]>
Date: Wed, 21 Oct 2015 09:55:11 +0200

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:
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 23 Oct 2015 17:38:28 +0000

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

... 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,
>

---

From: Anna Brunstrom <[email-masked]>
Date: Fri, 23 Oct 2015 23:49:18 +0200

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

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Sat, 31 Oct 2015 00:49:19 +0000

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,

BR,
Anna