TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
draft-ietf-tcpm-rtorestart-10

[Ballot comment]
A comment to Benoît's comment that quotes the opsdir review saying, 'I believe that it should be "provide" singular and not plural.'  No, "provides" goes with "algorithm", and is correct as written.

[Ballot comment]
Here is Tim's OPS DIR review:

This document describes an experimental modification to the TCP Retransmission Timeout (RTO) to act more aggressivly in connections that are short-lived or application limited.  It's well written.

The document is for both TCP and SCTCP, though primarily the TCP implementation is discussed. This is fine as it is experimental.

I found one thing in the introduction:

  This document describes a modified sender-side algorithm for managing
  the TCP and SCTP retransmission timers that provides faster loss
  recovery

I believe that it should be "provide" singular and not plural.

In section 4, there is this text:

  The RECOMMENDED value of rrthresh is four, as this value will ensure
  that RTOR is only used when fast retransmit cannot be triggered.
  This update needs TCP implementations to track the time elapsed since
  the transmission of the earliest outstanding segment (T_earliest).

The text is saying the implementation track time elapsed, so should it say:

"With this update, TCP implementations MUST track the time elapsed..."?

[Ballot comment]
Thanks for producing this. It looks helpful.

I had a few comments you might consider.

Overall - I'm reading "restart the RTO timer" and its variations as an action that would *increase* the delay before retransmission, but that's backwards - RTOR is an action that can *decrease* the delay before retransmission. I suspect I'm not the only reader who would be confused on this. The word "restart" is pervasive in this document (I counted 48 occurances, including page headers), so I can't reasonably ask about using a different term, but I'm wondering if it would be clearer if the abstract said something like

OLD

The modification, RTO Restart (RTOR), allows the
  transport to restart its retransmission timer so that the effective
  RTO becomes more aggressive in situations where fast retransmit
  cannot be used.
 
NEW

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.

In the Introduction,

  Second, when a sender
  receives duplicate acknowledgments, or similar information via
  selective acknowledgments, the fast retransmit algorithm infers data
  loss and triggers a retransmission.
 
this is describing retransmission without any conditions. A couple of sentences later, the text describes the conditions that trigger a retransmission, so the paragraph gets it right in total, but it might be clearer if this sentence said something like

  Second, when a sender
  receives duplicate acknowledgments, or similar information via
  selective acknowledgments, the fast retransmit algorithm suspects data
  loss and can trigger a retransmission.
 
In this sentence,

  Further experimentation is needed to
  determine this and thereby move this specification from experimental
  to proposed standard.
 
if you make other text changes, you might consider s/to proposed standard/to the standards track/. In a perfect world, the specification might advance beyond proposed standard, given deployment experience ...

[Ballot comment]
Thanks for producing this. It looks helpful.

I had a few comments you might consider.

Overall - I'm reading "restart the RTO timer" and its variations as an action that would *increase* the delay before retransmission, but that's backwards - RTOR is an action that can *decrease* the delay before retransmission. I suspect I'm not the only reader who would be confused on this. The word "restart" is pervasive in this document (I counted 48 occurances, including page headers), so I can't reasonably ask about using a different term, but I'm wondering if it would be clearer if the abstract said something like

OLD

The modification, RTO Restart (RTOR), allows the
  transport to restart its retransmission timer so that the effective
  RTO becomes more aggressive in situations where fast retransmit
  cannot be used.
 
NEW

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.

In the Introduction,

  Second, when a sender
  receives duplicate acknowledgments, or similar information via
  selective acknowledgments, the fast retransmit algorithm infers data
  loss and triggers a retransmission.
 
this is describing retransmission without any conditions. A couple of sentences later, the text describes the conditions that trigger a retransmission, so the paragraph gets it right in total, but it might be clearer if this sentence said something like

  Second, when a sender
  receives duplicate acknowledgments, or similar information via
  selective acknowledgments, the fast retransmit algorithm suspects data
  loss and can trigger a retransmission.
 
In this sentence,

  Further experimentation is needed to
  determine this and thereby move this specification from experimental
  to proposed standard.
 
if you make other text changes, you might consider s/to proposed standard/to the standards track/. In a perfect world, the specification might advance beyond proposed standard, given deployment experience ...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tcpm-rtorestart-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TCP and SCTP RTO Restart) to Experimental RFC


The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'TCP and SCTP RTO Restart'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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 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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ballot/


No IPR declarations have been submitted directly on this I-D.

TCP and SCTP RTO Restart - Essay Style Document Writeup

1. Summary

The document shepherd is Michael Scharf . The responsible Area Director is Martin Stiemerling .

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 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 TCPM working group requests publication of this document as Experimental RFC to enable and encourage further experimentation. Experiments are needed e.g. to evaluate the tradeoff between performance improvements and the risk of spurious timeouts, as discussed in Section 5 of the document.


2. Review and Consensus

It is the consensus of the TCPM working group to document this alternative algorithm, given the potential performance benefit. The work has mostly been driven by the authors, but the document has been reviewed in detail by several experts and the content has been modified accordingly. Performance experiments in simulations and testbeds have been performed and published by the authors and the experimental results have been reviewed in several TCPM meetings. At the time of writing, there is only limited deployment experience.

Two issues have been discussed extensively in the working group. First, any reduction of the retransmission timeout duration inherently comes along with a risk of negative impact on TCP performance, e.g. in mobile networks with highly variable RTT. The current understanding is that this risk is low and that the algorithm is conservative and relatively robust, but further experimentation has to confirm this. Second, the Linux operation system uses the "Tail Loss Probe" method discussed in Section 6, which is similar but more complex. This method was not adopted in TCPM since it depends on FACK error recovery method, which has not been standardizes so far.

This document was also last called in TSVWG, since it specifies an algorithm that can be applied both to TCP and SCTP. As a result of WGLC comments the applicability to SCTP has been better explained, including the SCTP API. One issue is that TCP and SCTP use slightly different terminology for comparable concepts. In order to keep the document simple, it was decided not to add another, duplicated description of the algorithm using SCTP terminology.


3. Intellectual Property

Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. There are no IPR disclosures regarding this document.


4. Other Points

None