draft-ietf-tcpm-rtorestart-08.txt   draft-ietf-tcpm-rtorestart-09.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: December 20, 2015 A. Petlund Expires: April 22, 2016 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
June 18, 2015 October 20, 2015
TCP and SCTP RTO Restart TCP and SCTP RTO Restart
draft-ietf-tcpm-rtorestart-08 draft-ietf-tcpm-rtorestart-09
Abstract Abstract
This document describes a modified sender-side algorithm for managing This document describes a modified sender-side algorithm for managing
the TCP and SCTP retransmission timers that provides faster loss the TCP and SCTP retransmission timers that provides faster loss
recovery when there is a small amount of outstanding data for a recovery when there is a small amount of outstanding data for a
connection. The modification, RTO Restart (RTOR), allows the connection. The modification, RTO Restart (RTOR), allows the
transport to restart its retransmission timer so that the effective transport to restart its retransmission timer using a smaller delay,
RTO becomes more aggressive in situations where fast retransmit so that the effective RTO becomes more aggressive in situations where
cannot be used. This enables faster loss detection and recovery for fast retransmit cannot be used. This enables faster loss detection
connections that are short-lived or application-limited. 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 December 20, 2015. This Internet-Draft will expire on April 22, 2016.
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 2, line 23 skipping to change at page 2, line 26
TCP and SCTP use two almost identical mechanisms to detect and TCP and SCTP use two almost identical mechanisms to detect and
recover from data loss, specified in [RFC6298][RFC5681] (for TCP) and recover from data loss, specified in [RFC6298][RFC5681] (for TCP) and
[RFC4960] (for SCTP). First, if transmitted data is not acknowledged [RFC4960] (for SCTP). First, if transmitted data is not acknowledged
within a certain amount of time, a retransmission timeout (RTO) within a certain amount of time, a retransmission timeout (RTO)
occurs, and the data is retransmitted. While the RTO is based on occurs, and the data is retransmitted. While the RTO is based on
measured round-trip times (RTTs) between the sender and receiver, it measured round-trip times (RTTs) between the sender and receiver, it
also has a conservative lower bound of 1 second to ensure that also has a conservative lower bound of 1 second to ensure that
delayed data are not mistaken as lost. Second, when a sender delayed data are not mistaken as lost. Second, when a sender
receives duplicate acknowledgments, or similar information via receives duplicate acknowledgments, or similar information via
selective acknowledgments, the fast retransmit algorithm infers data selective acknowledgments, the fast retransmit algorithm suspects
loss and triggers a retransmission. Duplicate (and selective) data loss and can trigger a retransmission. Duplicate (and
acknowledgments are generated by a receiver when data arrives out-of- selective) acknowledgments are generated by a receiver when data
order. As both data loss and data reordering cause out-of-order arrives out-of-order. As both data loss and data reordering cause
arrival, fast retransmit waits for three out-of-order notifications out-of-order arrival, fast retransmit waits for three out-of-order
before considering the corresponding data as lost. In some notifications before considering the corresponding data as lost. In
situations, however, the amount of outstanding data is not enough to some situations, however, the amount of outstanding data is not
trigger three such acknowledgments, and the sender must rely on enough to trigger three such acknowledgments, and the sender must
lengthy RTOs for loss recovery. rely on lengthy RTOs for loss recovery.
The amount of outstanding data can be small for several reasons: The amount of outstanding data can be small for several reasons:
(1) The connection is limited by the congestion control when the (1) The connection is limited by the congestion control when the
path has a low total capacity (bandwidth-delay product) or the path has a low total capacity (bandwidth-delay product) or the
connection's share of the capacity is small. It is also limited connection's share of the capacity is small. It is also limited
by the congestion control in the first few RTTs of a connection by the congestion control in the first few RTTs of a connection
or after an RTO when the available capacity is probed using or after an RTO when the available capacity is probed using
slow-start. slow-start.
(2) The connection is limited by the receiver's available buffer (2) The connection is limited by the receiver's available buffer
space. space.
(3) The connection is limited by the application if the available (3) The connection is limited by the application if the available
capacity of the path is not fully utilized (e.g. interactive capacity of the path is not fully utilized (e.g. interactive
applications), or at the end of a transfer. applications), or at the end of a transfer.
While the reasons listed above are valid for any flow, the third While the reasons listed above are valid for any flow, the third
reason is most common for applications that transmit short flows, or reason is most common for applications that transmit short flows, or
use a bursty transmission pattern. A typical example of applications use a bursty transmission pattern. A typical example of applications
that produce short flows are web-based applications. [RJ10] shows that produce short flows are web-based applications. [RJ10] shows
that 70% of all web objects, found at the top 500 sites, are too that 70% of all web objects, found at the top 500 sites, are too
small for fast retransmit to work. [FDT13] shows that about 77% of small for fast retransmit to work. [FDT13] shows that about 77% of
all retransmissions sent by a major web service are sent after RTO all retransmissions sent by a major web service are sent after RTO
expiry. Applications with bursty transmission patterns often send expiry. Applications with bursty transmission patterns often send
skipping to change at page 5, line 42 skipping to change at page 5, line 46
(3) Restart the retransmission timer so that it will expire after (3) Restart the retransmission timer so that it will expire after
(for the current value of RTO): (for the current value of RTO):
(a) RTO - T_earliest, if RTO - T_earliest > 0. (a) RTO - T_earliest, if RTO - T_earliest > 0.
(b) RTO, otherwise. (b) RTO, otherwise.
The RECOMMENDED value of rrthresh is four, as this value will ensure The RECOMMENDED value of rrthresh is four, as this value will ensure
that RTOR is only used when fast retransmit cannot be triggered. that RTOR is only used when fast retransmit cannot be triggered.
This update needs TCP implementations to track the time elapsed since With this update, TCP implementations MUST track the time elapsed
the transmission of the earliest outstanding segment (T_earliest). since the transmission of the earliest outstanding segment
As RTOR is only used when the amount of outstanding and previously (T_earliest). As RTOR is only used when the amount of outstanding
unsent data is less than rrthresh segments, TCP implementations also and previously unsent data is less than rrthresh segments, TCP
need to track whether the amount of outstanding and previously unsent implementations also need to track whether the amount of outstanding
data is more, equal, or less than rrthresh segments. Although some and previously unsent data is more, equal, or less than rrthresh
packet-based TCP implementations (e.g. Linux TCP) already track both segments. Although some packet-based TCP implementations (e.g.
the transmission times of all segments and also the number of
outstanding segments, not all implementations do. Section 5.3 Linux TCP) already track both the transmission times of all segments
describes how to implement segment tracking for a general TCP and also the number of outstanding segments, not all implementations
implementation. To use RTOR, the calculated expiration time MUST be do. Section 5.3 describes how to implement segment tracking for a
positive (step 3(a) in the list above); this is required to ensure general TCP implementation. To use RTOR, the calculated expiration
that RTOR does not trigger retransmissions prematurely when time MUST be positive (step 3(a) in the list above); this is required
to ensure that RTOR does not trigger retransmissions prematurely when
previously retransmitted segments are acknowledged. previously retransmitted segments are acknowledged.
5. Discussion 5. Discussion
Although RTOR conforms to the requirement in [RFC6298] that segments Although RTOR conforms to the requirement in [RFC6298] that segments
must not be retransmitted earlier than RTO seconds after their must not be retransmitted earlier than RTO seconds after their
original transmission, RTOR makes the effective RTO more aggressive. original transmission, RTOR makes the effective RTO more aggressive.
In this section, we discuss the applicability and the issues related In this section, we discuss the applicability and the issues related
to RTOR. to RTOR.
5.1. Applicability 5.1. Applicability
The currently standardized algorithm has been shown to add at least The currently standardized algorithm has been shown to add at least
one RTT to the loss recovery process in TCP [LS00] and SCTP one RTT to the loss recovery process in TCP [LS00] and SCTP
[HB11][PBP09]. For applications that have strict timing requirements [HB11][PBP09]. For applications that have strict timing requirements
(e.g. interactive web) rather than throughput requirements, using (e.g. interactive web) rather than throughput requirements, using
RTOR could be beneficial because the RTT and also the delACK timer of RTOR could be beneficial because the RTT and also the delACK timer of
receivers are often large components of the effective loss recovery receivers are often large components of the effective loss recovery
time. Measurements in [HB11] have shown that the total transfer time time. Measurements in [HB11] have shown that the total transfer time
of a lost segment (including the original transmission time and the of a lost segment (including the original transmission time and the
loss recovery time) can be reduced by 35% using RTOR. These results loss recovery time) can be reduced by 35% using RTOR. These results
match those presented in [PGH06][PBP09], where RTOR is shown to match those presented in [PGH06][PBP09], where RTOR is shown to
significantly reduce retransmission latency. significantly reduce retransmission latency.
There are also traffic types that do not benefit from RTOR. One There are also traffic types that do not benefit from RTOR. One
example of such traffic is bulk transmission. The reason why bulk example of such traffic is bulk transmission. The reason why bulk
skipping to change at page 7, line 18 skipping to change at page 7, line 20
have a negative effect on the network as segments are transmitted have a negative effect on the network as segments are transmitted
needlessly. However, recent experiments do not show a significant needlessly. However, recent experiments do not show a significant
increase in network load for a number of realistic scenarios [RHB15]. increase in network load for a number of realistic scenarios [RHB15].
Another problem with spurious retransmissions is related to the Another problem with spurious retransmissions is related to the
performance of TCP/SCTP, as the congestion window is reduced to one performance of TCP/SCTP, as the congestion window is reduced to one
segment when timeouts occur [RFC5681]. This could be a potential segment when timeouts occur [RFC5681]. This could be a potential
problem for applications transmitting multiple bursts of data within problem for applications transmitting multiple bursts of data within
a single flow, e.g. web-based HTTP/1.1 and HTTP/2.0 applications. a single flow, e.g. web-based HTTP/1.1 and HTTP/2.0 applications.
However, results from recent experiments involving persistent web However, results from recent experiments involving persistent web
traffic [RHB15] revealed a net gain of using RTOR. Other types of traffic [RHB15] revealed a net gain of using RTOR. Other types of
flows, e.g. long-lived bulk flows, are not affected as the algorithm flows, e.g. long-lived bulk flows, are not affected as the algorithm
is only applied when the amount of outstanding and unsent segments is is only applied when the amount of outstanding and unsent segments is
less than rrthresh. Furthermore, short-lived and application-limited less than rrthresh. Furthermore, short-lived and application-limited
flows are typically not affected as they are too short to experience flows are typically not affected as they are too short to experience
the effect of congestion control or have a transmission rate that is the effect of congestion control or have a transmission rate that is
quickly attainable. quickly attainable.
While a slight increase in spurious timeouts has been observed using While a slight increase in spurious timeouts has been observed using
RTOR, it is not clear whether the effects of this increase mandate RTOR, it is not clear whether the effects of this increase mandate
any future algorithmic changes or not -- especially since most modern any future algorithmic changes or not -- especially since most modern
operating systems already include mechanisms to detect operating systems already include mechanisms to detect
[RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems [RFC3522][RFC3708][RFC5682] and resolve [RFC4015] possible problems
with spurious retransmissions. Further experimentation is needed to with spurious retransmissions. Further experimentation is needed to
determine this and thereby move this specification from experimental determine this and thereby move this specification from experimental
to proposed standard. For instance, RTOR has not been evaluated in to the standards track. For instance, RTOR has not been evaluated in
the context of mobile networks. Mobile networks often incur highly the context of mobile networks. Mobile networks often incur highly
variable RTTs (delay spikes), due to e.g. handovers, and would variable RTTs (delay spikes), due to e.g. handovers, and would
therefore be a useful scenario for further experimentation. therefore be a useful scenario for further experimentation.
5.3. Tracking Outstanding and Previously Unsent Segments 5.3. Tracking Outstanding and Previously Unsent Segments
The method of tracking outstanding and previously unsent segments The method of tracking outstanding and previously unsent segments
will probably differ depending on the actual TCP implementation. For will probably differ depending on the actual TCP implementation. For
packet-based TCP implementations, tracking outstanding segments is packet-based TCP implementations, tracking outstanding segments is
often straightforward and can be implemented using a simple counter. often straightforward and can be implemented using a simple counter.
skipping to change at page 11, line 15 skipping to change at page 11, line 23
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-...-07 to -08 11.1. Changed from draft-ietf-...-08 to -09
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.
11.2. Changes from draft-ietf-...-07 to -08
o Clarified, at multiple places in the document, that the o Clarified, at multiple places in the document, that the
modification only causes the effective RTO to be more aggressive, modification only causes the effective RTO to be more aggressive,
not the actual RTO. not the actual RTO.
o Removed information in the introduction that was too detailed, o Removed information in the introduction that was too detailed,
i.e., material that is hard to understand without knowing details i.e., material that is hard to understand without knowing details
of the algorithm. of the algorithm.
o Changed the name of Section 3 to more correctly capture the actual o Changed the name of Section 3 to more correctly capture the actual
skipping to change at page 11, line 40 skipping to change at page 12, line 17
o Moved text from the algorithm description (Section 4) to the o Moved text from the algorithm description (Section 4) to the
introduction of the discussion section (Section 5). The text was introduction of the discussion section (Section 5). The text was
discussing the possible effects of the algorithm more than discussing the possible effects of the algorithm more than
describing the actual algorithm. describing the actual algorithm.
o Clarified why the RECOMMENDED value of rrthresh is four. o Clarified why the RECOMMENDED value of rrthresh is four.
o Reworked the introduction to be suitable for both TCP and SCTP. o Reworked the introduction to be suitable for both TCP and SCTP.
11.2. Changes from draft-ietf-...-06 to -07 11.3. Changes from draft-ietf-...-06 to -07
o Clarified, at multiple places in the document, that the o Clarified, at multiple places in the document, that the
modification is sender-only. modification is sender-only.
o Added an explanation (in the introduction) to why the mechanism is o Added an explanation (in the introduction) to why the mechanism is
experimental and what experiments are missing. experimental and what experiments are missing.
o Added a sentence in Section 4 to clarify that the section is the o Added a sentence in Section 4 to clarify that the section is the
one describing the actual modification. one describing the actual modification.
11.3. Changes from draft-ietf-...-05 to -06 11.4. 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.4. Changes from draft-ietf-...-04 to -05 11.5. 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.5. Changes from draft-ietf-...-03 to -04 11.6. 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.6. Changes from draft-ietf-...-02 to -03 11.7. 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.7. Changes from draft-ietf-...-01 to -02 11.8. 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.8. Changes from draft-ietf-...-00 to -01 11.9. 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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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. DOI 10.17487/RFC3042, January 2001,
<http://www.rfc-editor.org/info/rfc3042>.
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
for TCP", RFC 3522, April 2003. for TCP", RFC 3522, DOI 10.17487/RFC3522, April 2003,
<http://www.rfc-editor.org/info/rfc3522>.
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions", RFC 3708, (TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004. DOI 10.17487/RFC3708, February 2004,
<http://www.rfc-editor.org/info/rfc3708>.
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
for TCP", RFC 4015, February 2005. for TCP", RFC 4015, DOI 10.17487/RFC4015, February 2005,
<http://www.rfc-editor.org/info/rfc4015>.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
4960, September 2007. RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>.
[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata,
"Forward RTO-Recovery (F-RTO): An Algorithm for Detecting "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP", RFC 5682, Spurious Retransmission Timeouts with TCP", RFC 5682,
September 2009. DOI 10.17487/RFC5682, September 2009,
<http://www.rfc-editor.org/info/rfc5682>.
[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,
DOI 10.17487/RFC5827, May 2010,
<http://www.rfc-editor.org/info/rfc5827>.
[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,
2011. DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>.
12.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
skipping to change at page 15, line 20 skipping to change at page 16, line 11
[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",
Multimedia Tools and Applications, 45(1-3), 2009. Springer 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. [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458, December 2011. Transmission Protocol (SCTP)", RFC 6458,
DOI 10.17487/RFC6458, December 2011,
<http://www.rfc-editor.org/info/rfc6458>.
[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/
http://code.google.com/speed/articles/web-metrics.html, 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,
"TCP Loss Probe (TLP): An Algorithm for Fast Recovery of "TCP Loss Probe (TLP): An Algorithm for Fast Recovery of
Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp- Tail Losses", Internet-draft draft-dukkipati-tcpm-tcp-
loss-probe-01.txt, February 2013. loss-probe-01.txt, February 2013.
Authors' Addresses Authors' Addresses
Per Hurtig Per Hurtig
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
Karlstad 651 88 Karlstad 651 88
Sweden Sweden
Phone: +46 54 700 23 35 Phone: +46 54 700 23 35
Email: per.hurtig@kau.se Email: per.hurtig@kau.se
Anna Brunstrom Anna Brunstrom
Karlstad University Karlstad University
Universitetsgatan 2 Universitetsgatan 2
Karlstad 651 88 Karlstad 651 88
Sweden Sweden
Phone: +46 54 700 17 95 Phone: +46 54 700 17 95
Email: anna.brunstrom@kau.se Email: anna.brunstrom@kau.se
Andreas Petlund Andreas Petlund
 End of changes. 35 change blocks. 
63 lines changed or deleted 97 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/