draft-ietf-tcpm-rtorestart-05.txt   draft-ietf-tcpm-rtorestart-06.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: September 10, 2015 A. Petlund Expires: October 10, 2015 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
March 9, 2015 April 8, 2015
TCP and SCTP RTO Restart TCP and SCTP RTO Restart
draft-ietf-tcpm-rtorestart-05 draft-ietf-tcpm-rtorestart-06
Abstract Abstract
This document describes a modified algorithm for managing the TCP and This document describes a modified algorithm for managing the TCP and
SCTP retransmission timers that provides faster loss recovery when SCTP retransmission timers that provides faster loss recovery when
there is a small amount of outstanding data for a connection. The there is a small amount of outstanding data for a connection. The
modification, RTO Restart (RTOR), allows the transport to restart its modification, RTO Restart (RTOR), allows the transport to restart its
retransmission timer more aggressively in situations where fast retransmission timer more aggressively in situations where fast
retransmit cannot be used. This enables faster loss detection and retransmit cannot be used. This enables faster loss detection and
recovery for connections that are short-lived or application-limited. recovery for connections that are short-lived or application-limited.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 10, 2015. This Internet-Draft will expire on October 10, 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 9, line 35 skipping to change at page 9, line 35
compared to RTOR [RHB15]. compared to RTOR [RHB15].
TLP is applicable in situations where RTOR does not apply, and it TLP is applicable in situations where RTOR does not apply, and it
could overrule (yielding a similar general behavior, but with a lower could overrule (yielding a similar general behavior, but with a lower
timeout) RTOR in cases where the number of outstanding segments is timeout) RTOR in cases where the number of outstanding segments is
smaller than four and no new segments are available for transmission. smaller than four and no new segments are available for transmission.
The PTO has the same inherent problem of restarting the timer on an The PTO has the same inherent problem of restarting the timer on an
incoming ACK, and could be combined with a strategy similar to RTOR's incoming ACK, and could be combined with a strategy similar to RTOR's
to offer more consistent timeouts. to offer more consistent timeouts.
7. Acknowledgements 7. SCTP Socket API Considerations
The authors wish to thank Godred Fairhurst, Yuchung Cheng, Mark This section describes how the socket API for SCTP defined in
Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn, [RFC6458] is extended to control the usage of RTO restart for SCTP.
Alexander Zimmermann, and Michael Scharf for commenting on the draft
and the ideas behind it.
All the authors are supported by RITE (http://riteproject.eu/ ), a Please note that this section is informational only.
research project (ICT-317700) funded by the European Community under
its Seventh Framework Program. The views expressed here are those of 7.1. Data Types
the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document. This section uses data types from [IEEE.1003-1G.1997]: uintN_t means
an unsigned integer of exactly N bits (e.g., uint16_t). This is the
same as in [RFC6458].
7.2. Socket Option for Controlling the RTO Restart Support
(SCTP_RTO_RESTART)
This socket option allows the enabling or disabling of RTO Restart
for SCTP associations.
Whether RTO Restart is enabled or not per default is implementation
specific.
This socket option uses IPPROTO_SCTP as its level and
SCTP_RTO_RESTART as its name. It can be used with getsockopt() and
setsockopt(). The socket option value uses the following structure
defined in [RFC6458]:
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, this parameter indicates upon which
association the user is performing an action. The special
sctp_assoc_t SCTP_{FUTURE|CURRENT|ALL}_ASSOC can also be used in
assoc_id for setsockopt(). For getsockopt(), the special value
SCTP_FUTURE_ASSOC can be used in assoc_id, but it is an error to
use SCTP_{CURRENT|ALL}_ASSOC in assoc_id.
assoc_value: A non-zero value encodes the enabling 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.
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 discusses a change in how to set the retransmission
timer's value when restarted. Therefore, the security considerations timer's value when restarted. Therefore, the security considerations
found in [RFC6298] apply to this document. No additional security found in [RFC6298] apply to this document. No additional security
problems have been identified with RTO Restart at this time. problems have been identified with RTO Restart at this time.
10. Changes from Previous Versions 10. Acknowledgements
The authors wish to thank Michael Tuexen for contributing the SCTP
Socket API considerations and Godred Fairhurst, Yuchung Cheng, Mark
Allman, Anantha Ramaiah, Richard Scheffenegger, Nicolas Kuhn,
Alexander Zimmermann, and Michael Scharf for commenting on the draft
and the ideas behind it.
All the authors are supported by RITE (http://riteproject.eu/ ), a
research project (ICT-317700) funded by the European Community under
its Seventh Framework Program. The views expressed here are those of
the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document.
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.
10.1. Changes from draft-ietf-...-04 to -05 11.1. Changes from draft-ietf-...-05 to -06
o Added socket API considerations, after discussing the draft in
tsvwg.
11.2. 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.
10.2. Changes from draft-ietf-...-03 to -04 11.3. 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.
10.3. Changes from draft-ietf-...-02 to -03 11.4. 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.
10.4. Changes from draft-ietf-...-01 to -02 11.5. 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.
10.5. Changes from draft-ietf-...-00 to -01 11.6. 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.
o Updated the text describing the relationship to TLP to reflect o Updated the text describing the relationship to TLP to reflect
updates made in this draft. updates made in this draft.
o Added acknowledgments. o Added acknowledgments.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042, TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001. January 2001.
skipping to change at page 13, line 5 skipping to change at page 14, line 5
September 2009. September 2009.
[RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and
P. Hurtig, "Early Retransmit for TCP and Stream Control P. Hurtig, "Early Retransmit for TCP and Stream Control
Transmission Protocol (SCTP)", RFC 5827, May 2010. Transmission Protocol (SCTP)", RFC 5827, May 2010.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, June "Computing TCP's Retransmission Timer", RFC 6298, June
2011. 2011.
11.2. Informative References 12.2. Informative References
[EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End- [EL04] Ekstroem, H. and R. Ludwig, "The Peak-Hopper: A New End-
to-End Retransmission Timer for Reliable Unicast to-End Retransmission Timer for Reliable Unicast
Transport", IEEE INFOCOM 2004, March 2004. Transport", IEEE INFOCOM 2004, March 2004.
[FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B., [FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B.,
Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett, Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett,
E., and R. Govindan, "Reducing Web Latency: the Virtue of E., and R. Govindan, "Reducing Web Latency: the Virtue of
Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013. Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013.
[HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely [HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely
message delivery?", Springer Telecommunication Systems 47 message delivery?", Springer Telecommunication Systems 47
(3-4), August 2011. (3-4), August 2011.
[IEEE.1003-1G.1997]
Institute of Electrical and Electronics Engineers,
"Protocol Independent Interfaces", IEEE Standard 1003.1G,
March 1997.
[LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission [LS00] Ludwig, R. and K. Sklower, "The Eifel retransmission
timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July timer", ACM SIGCOMM Comput. Commun. Rev., 30(3), July
2000. 2000.
[P09] Petlund, A., "Improving latency for interactive, thin- [P09] Petlund, A., "Improving latency for interactive, thin-
stream applications over reliable transport", Unipub PhD stream applications over reliable transport", Unipub PhD
Thesis, Oct 2009. Thesis, Oct 2009.
[PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz, [PBP09] Petlund, A., Beskow, P., Pedersen, J., Paaby, E., Griwodz,
C., and P. Halvorsen, "Improving SCTP Retransmission C., and P. Halvorsen, "Improving SCTP Retransmission
Delays for Time-Dependent Thin Streams", Springer Delays for Time-Dependent Thin Streams", Springer
Multimedia Tools and Applications, 45(1-3), 2009. Multimedia Tools and Applications, 45(1-3), 2009.
[PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen, [PGH06] Pedersen, J., Griwodz, C., and P. Halvorsen,
"Considerations of SCTP Retransmission Delays for Thin "Considerations of SCTP Retransmission Delays for Thin
Streams", IEEE LCN 2006, November 2006. Streams", IEEE LCN 2006, November 2006.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, December 2011.
[RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and [RHB15] Rajiullah, M., Hurtig, P., Brunstrom, A., Petlund, A., and
M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms M. Welzl, "An Evaluation of Tail Loss Recovery Mechanisms
for TCP", ACM SIGCOMM CCR 45 (1), January 2015. for TCP", ACM SIGCOMM CCR 45 (1), January 2015.
[RJ10] Ramachandran, S., "Web metrics: Size and number of [RJ10] Ramachandran, S., "Web metrics: Size and number of
resources", Google resources", Google
http://code.google.com/speed/articles/web-metrics.html, http://code.google.com/speed/articles/web-metrics.html,
May 2010. May 2010.
[TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis, [TLP] Dukkipati, N., Cardwell, N., Cheng, Y., and M. Mathis,
 End of changes. 18 change blocks. 
23 lines changed or deleted 83 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/