draft-ietf-tcpm-rtorestart-06.txt   draft-ietf-tcpm-rtorestart-07.txt 
TCP Maintenance and Minor Extensions (tcpm) P. Hurtig TCP Maintenance and Minor Extensions (tcpm) P. Hurtig
Internet-Draft A. Brunstrom Internet-Draft A. Brunstrom
Intended status: Experimental Karlstad University Intended status: Experimental Karlstad University
Expires: October 10, 2015 A. Petlund Expires: October 22, 2015 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
April 8, 2015 April 20, 2015
TCP and SCTP RTO Restart TCP and SCTP RTO Restart
draft-ietf-tcpm-rtorestart-06 draft-ietf-tcpm-rtorestart-07
Abstract Abstract
This document describes a modified algorithm for managing the TCP and This document describes a modified sender-side algorithm for managing
SCTP retransmission timers that provides faster loss recovery when the TCP and SCTP retransmission timers that provides faster loss
there is a small amount of outstanding data for a connection. The recovery when there is a small amount of outstanding data for a
modification, RTO Restart (RTOR), allows the transport to restart its connection. The modification, RTO Restart (RTOR), allows the
retransmission timer more aggressively in situations where fast transport to restart its retransmission timer more aggressively in
retransmit cannot be used. This enables faster loss detection and situations where fast retransmit cannot be used. This enables faster
recovery for connections that are short-lived or application-limited. loss detection and recovery for connections that are short-lived or
application-limited.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2015. This Internet-Draft will expire on October 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 22 skipping to change at page 3, line 23
RTO slightly more aggressive when the number of outstanding segments RTO slightly more aggressive when the number of outstanding segments
is too small for fast retransmit to work, in an attempt to enable is too small for fast retransmit to work, in an attempt to enable
faster loss recovery for all segments while being robust to faster loss recovery for all segments while being robust to
reordering. While RTOR still conforms to the requirement in reordering. While RTOR still conforms to the requirement in
[RFC6298] that segments must not be retransmitted earlier than RTO [RFC6298] that segments must not be retransmitted earlier than RTO
seconds after their original transmission, it could increase the risk seconds after their original transmission, it could increase the risk
of spurious timeout. Spurious timeouts can degrade the performance of spurious timeout. Spurious timeouts can degrade the performance
of flows with multiple bursts of data, as a burst following a of flows with multiple bursts of data, as a burst following a
spurious timeout might not fit within the reduced congestion window spurious timeout might not fit within the reduced congestion window
(cwnd). There are, however, several techniques to mitigate the (cwnd). There are, however, several techniques to mitigate the
effects of such unnecessary retransmissions (cf. [RFC4015]). effects of such unnecessary retransmissions (cf. [RFC4015]). To
determine whether this modification is safe to deploy and enable by
default further experimentation is required. The experiments needed
to determine this are discussed in Section 5 and include evaluating
the modification in environments with highly varying RTTs, e.g.
mobile networks.
While this document focuses on TCP, the described changes are also While this document focuses on TCP, the described changes are also
valid for the Stream Control Transmission Protocol (SCTP) [RFC4960] valid for the Stream Control Transmission Protocol (SCTP) [RFC4960]
which has similar loss recovery and congestion control algorithms. which has similar loss recovery and congestion control algorithms.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 5, line 13 skipping to change at page 5, line 21
network is severely congested and no segments arrive RTO-based network is severely congested and no segments arrive RTO-based
recovery should be used. In this situation, the time to recover from recovery should be used. In this situation, the time to recover from
the loss(es) will not be the performance bottleneck. However, for the loss(es) will not be the performance bottleneck. However, for
connections that do not utilize enough capacity to enable fast connections that do not utilize enough capacity to enable fast
retransmit, RTO-based loss detection is the only choice and the time retransmit, RTO-based loss detection is the only choice and the time
required for this can become a performance bottleneck. required for this can become a performance bottleneck.
4. RTOR Algorithm 4. RTOR Algorithm
To enable faster loss recovery for connections that are unable to use To enable faster loss recovery for connections that are unable to use
fast retransmit, RTOR can be used. By resetting the timer to "RTO - fast retransmit, RTOR can be used. This section specifies the
modifications required to use RTOR. By resetting the timer to "RTO -
T_earliest", where T_earliest is the time elapsed since the earliest T_earliest", where T_earliest is the time elapsed since the earliest
outstanding segment was transmitted, retransmissions will always outstanding segment was transmitted, retransmissions will always
occur after exactly RTO seconds. This approach makes the RTO more occur after exactly RTO seconds. This approach makes the RTO more
aggressive than the standardized approach in [RFC6298] but still aggressive than the standardized approach in [RFC6298] but still
conforms to the requirement in [RFC6298] that segments must not be conforms to the requirement in [RFC6298] that segments must not be
retransmitted earlier than RTO seconds after their original retransmitted earlier than RTO seconds after their original
transmission. transmission.
This document specifies an OPTIONAL sender-only modification to TCP This document specifies an OPTIONAL sender-only modification to TCP
and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a
skipping to change at page 10, line 43 skipping to change at page 10, line 49
whereas a value of 0 encodes the disabling of RTO restart. whereas a value of 0 encodes the disabling of RTO restart.
sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART. sctp_opt_info() needs to be extended to support SCTP_RTO_RESTART.
8. IANA Considerations 8. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
9. Security Considerations 9. Security Considerations
This document discusses a change in how to set the retransmission This document specifies an experimental sender-only modification to
timer's value when restarted. Therefore, the security considerations TCP and SCTP. The modification introduces a change in how to set the
found in [RFC6298] apply to this document. No additional security retransmission timer's value when restarted. Therefore, the security
problems have been identified with RTO Restart at this time. considerations found in [RFC6298] apply to this document. No
additional security problems have been identified with RTO Restart at
this time.
10. Acknowledgements 10. Acknowledgements
The authors wish to thank Michael Tuexen for contributing the SCTP The authors wish to thank Michael Tuexen for contributing the SCTP
Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark
Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn,
Alexander Zimmermann, and Michael Scharf for commenting on the draft Alexander Zimmermann, and Michael Scharf for commenting on the draft
and the ideas behind it. and the ideas behind it.
All the authors are supported by RITE (http://riteproject.eu/ ), a All the authors are supported by RITE (http://riteproject.eu/ ), a
research project (ICT-317700) funded by the European Community under research project (ICT-317700) funded by the European Community under
its Seventh Framework Program. The views expressed here are those of its Seventh Framework Program. The views expressed here are those of
the author(s) only. The European Commission is not liable for any the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document. use that may be made of the information in this document.
11. Changes from Previous Versions 11. Changes from Previous Versions
RFC-Editor note: please remove this section prior to publication. RFC-Editor note: please remove this section prior to publication.
11.1. Changes from draft-ietf-...-05 to -06 11.1. Changes from draft-ietf-...-06 to -07
o Clarified, at multiple places in the document, that the
modification is sender-only.
o Added an explanation (in the introduction) to why the mechanism is
experimental and what experiments are missing.
o Added a sentence in Section 4 to clarify that the section is the
one describing the actual modification.
11.2. Changes from draft-ietf-...-05 to -06
o Added socket API considerations, after discussing the draft in o Added socket API considerations, after discussing the draft in
tsvwg. tsvwg.
11.2. Changes from draft-ietf-...-04 to -05 11.3. Changes from draft-ietf-...-04 to -05
o Introduced variable to track the number of previously unsent o Introduced variable to track the number of previously unsent
segments. segments.
o Clarified many concepts, e.g. extended the description on how to o Clarified many concepts, e.g. extended the description on how to
track outstanding and previously unsent segments. track outstanding and previously unsent segments.
o Added a reference to initial measurements on the effects of using o Added a reference to initial measurements on the effects of using
RTOR. RTOR.
o Improved wording throughout the document. o Improved wording throughout the document.
11.3. Changes from draft-ietf-...-03 to -04 11.4. Changes from draft-ietf-...-03 to -04
o Changed the algorithm to allow RTOR when there is unsent data o Changed the algorithm to allow RTOR when there is unsent data
available, but the cwnd does not allow transmission. available, but the cwnd does not allow transmission.
o Changed the algorithm to not trigger if RTOR <= 0. o Changed the algorithm to not trigger if RTOR <= 0.
o Made minor adjustments throughout the document to adjust for the o Made minor adjustments throughout the document to adjust for the
algorithmic change. algorithmic change.
o Improved the wording throughout the document. o Improved the wording throughout the document.
11.4. Changes from draft-ietf-...-02 to -03 11.5. Changes from draft-ietf-...-02 to -03
o Updated the document to use "RTOR" instead of "RTO Restart" when o Updated the document to use "RTOR" instead of "RTO Restart" when
refering to the modified algorithm. refering to the modified algorithm.
o Moved document terminology to a section of its own. o Moved document terminology to a section of its own.
o Introduced the rrthresh variable in the terminology section. o Introduced the rrthresh variable in the terminology section.
o Added a section to generalize the tracking of outstanding o Added a section to generalize the tracking of outstanding
segments. segments.
o Updated the algorithm to work when the number of outstanding o Updated the algorithm to work when the number of outstanding
segments is less than four and one segment is ready for segments is less than four and one segment is ready for
transmission, by restarting the timer when new data has been sent. transmission, by restarting the timer when new data has been sent.
o Clarified the relationship between fast retransmit and RTOR. o Clarified the relationship between fast retransmit and RTOR.
o Improved the wording throughout the document. o Improved the wording throughout the document.
11.5. Changes from draft-ietf-...-01 to -02 11.6. Changes from draft-ietf-...-01 to -02
o Changed the algorithm description in Section 3 to use formal RFC o Changed the algorithm description in Section 3 to use formal RFC
2119 language. 2119 language.
o Changed last paragraph of Section 3 to clarify why the RTO restart o Changed last paragraph of Section 3 to clarify why the RTO restart
algorithm is active when less than four segments are outstanding. algorithm is active when less than four segments are outstanding.
o Added two paragraphs in Section 4.1 to clarify why the algorithm o Added two paragraphs in Section 4.1 to clarify why the algorithm
can be turned on for all TCP traffic without having any negative can be turned on for all TCP traffic without having any negative
effects on traffic patterns that do not benefit from a modified effects on traffic patterns that do not benefit from a modified
timer restart. timer restart.
o Improved the wording throughout the document. o Improved the wording throughout the document.
o Replaced and updated some references. o Replaced and updated some references.
11.6. Changes from draft-ietf-...-00 to -01 11.7. Changes from draft-ietf-...-00 to -01
o Improved the wording throughout the document. o Improved the wording throughout the document.
o Removed the possibility for a connection limited by the receiver's o Removed the possibility for a connection limited by the receiver's
advertised window to use RTO restart, decreasing the risk of advertised window to use RTO restart, decreasing the risk of
spurious retransmission timeouts. spurious retransmission timeouts.
o Added a section that discusses the applicability of and problems o Added a section that discusses the applicability of and problems
related to the RTO restart mechanism. related to the RTO restart mechanism.
 End of changes. 14 change blocks. 
23 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/