draft-ietf-tcpm-rtorestart-01.txt   draft-ietf-tcpm-rtorestart-02.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: March 21, 2014 A. Petlund Expires: August 18, 2014 A. Petlund
Simula Research Laboratory AS Simula Research Laboratory AS
M. Welzl M. Welzl
University of Oslo University of Oslo
September 17, 2013 February 14, 2014
TCP and SCTP RTO Restart TCP and SCTP RTO Restart
draft-ietf-tcpm-rtorestart-01 draft-ietf-tcpm-rtorestart-02
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 allows the transport to restart its retransmission timer modification allows the transport to restart its retransmission timer
more aggressively in situations where fast retransmit cannot be used. more aggressively in situations where fast retransmit cannot be used.
This enables faster loss detection and recovery for connections that This enables faster loss detection and recovery for connections that
are short-lived or application-limited. 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 March 21, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 33 skipping to change at page 2, line 33
and segment reordering cause out-of-order arrival, fast retransmit and segment reordering cause out-of-order arrival, fast retransmit
waits for three duplicate acknowledgments before considering the waits for three duplicate acknowledgments before considering the
segment as lost. In some situations, however, the number of segment as lost. In some situations, however, the number of
outstanding segments is not enough to trigger three duplicate outstanding segments is not enough to trigger three duplicate
acknowledgments, and the sender must rely on lengthy RTOs for loss acknowledgments, and the sender must rely on lengthy RTOs for loss
recovery. recovery.
The number of outstanding segments can be small for several reasons: The number of outstanding segments 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 or by the congestion control in the first few RTTs of a connection
after an RTO when the available capacity is probed using slow- or after an RTO when the available capacity is probed using
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 common for applications that transmit short flows, or use a reason is common for applications that transmit short flows, or use a
low transmission rate. Typical examples of applications that produce low transmission rate. Typical examples of applications that produce
short flows are web servers. [RJ10] shows that 70% of all web short flows are web servers. [RJ10] shows that 70% of all web
objects, found at the top 500 sites, are too small for fast objects, found at the top 500 sites, are too small for fast
retransmit to work. [BPS98] shows that about 56% of all retransmit to work. [FDT13] shows that about 77% of all
retransmissions sent by a busy web server are sent after RTO expiry. retransmissions sent by a major web service are sent after RTO
While the experiments were not conducted using SACK [RFC2018], only expiry. Applications have a low transmission rate when data is sent
4% of the RTO-based retransmissions could have been avoided. in response to actions, or as a reaction to real life events.
Applications have a low transmission rate when data is sent in Typical examples of such applications are stock trading systems,
response to actions, or as a reaction to real life events. Typical remote computer operations and online games. What is special about
examples of such applications are stock trading systems, remote this class of applications is that they are time-dependant, and extra
computer operations and online games. What is special about this
class of applications is that they are time-dependant, and extra
latency can reduce the application service level [P09]. Although latency can reduce the application service level [P09]. Although
such applications may represent a small amount of data sent on the such applications may represent a small amount of data sent on the
network, a considerable number of flows have such properties and the network, a considerable number of flows have such properties and the
importance of low latency is high. importance of low latency is high.
The RTO restart approach outlined in this document makes the RTO The RTO restart approach outlined in this document makes the RTO
slightly more aggressive when the number of outstanding segments is slightly more aggressive when the number of outstanding segments is
small, in an attempt to enable faster loss recovery for all segments small, in an attempt to enable faster loss recovery for all segments
while being robust to reordering. While it still conforms to the while being robust to reordering. While it still conforms to the
requirement in [RFC6298] that segments must not be retransmitted requirement in [RFC6298] that segments must not be retransmitted
skipping to change at page 3, line 50 skipping to change at page 3, line 48
The RTO management algorithm described in [RFC6298] recommends that The RTO management algorithm described in [RFC6298] recommends that
the retransmission timer is restarted when an acknowledgment (ACK) the retransmission timer is restarted when an acknowledgment (ACK)
that acknowledges new data is received and there is still outstanding that acknowledges new data is received and there is still outstanding
data. The restart is conducted to guarantee that unacknowledged data. The restart is conducted to guarantee that unacknowledged
segments will be retransmitted after approximately RTO seconds. segments will be retransmitted after approximately RTO seconds.
However, by restarting the timer on each incoming acknowledgment, However, by restarting the timer on each incoming acknowledgment,
retransmissions are not typically triggered RTO seconds after their retransmissions are not typically triggered RTO seconds after their
previous transmission but rather RTO seconds after the last ACK previous transmission but rather RTO seconds after the last ACK
arrived. The duration of this extra delay depends on several factors arrived. The duration of this extra delay depends on several factors
but is in most cases approximately one RTT. Hence, in most but is in most cases approximately one RTT. Hence, in most
situations the time before a retransmission is triggered is equal to situations, the time before a retransmission is triggered is equal to
"RTO + RTT". "RTO + RTT".
The extra delay can be significant, especially for applications that The extra delay can be significant, especially for applications that
use a lower RTOmin than the standard of 1 second and/or in use a lower RTOmin than the standard of 1 second and/or in
environments with high RTTs, e.g. mobile networks. The restart environments with high RTTs, e.g. mobile networks. The restart
approach is illustrated in Figure 1 where a TCP sender transmits approach is illustrated in Figure 1 where a TCP sender transmits
three segments to a receiver. The arrival of the first and second three segments to a receiver. The arrival of the first and second
segment triggers a delayed ACK [RFC1122], which restarts the RTO segment triggers a delayed ACK [RFC1122], which restarts the RTO
timer at the sender. RTO restart is performed approximately one RTT timer at the sender. RTO restart is performed approximately one RTT
after the transmission of the third segment. Thus, if the third after the transmission of the third segment. Thus, if the third
skipping to change at page 4, line 48 skipping to change at page 4, line 48
in [EL04] to act as a "safety margin" that compensates for some of in [EL04] to act as a "safety margin" that compensates for some of
the problems that the authors have identified with the standard RTO the problems that the authors have identified with the standard RTO
calculation. Notably, the authors of [EL04] also state that "this calculation. Notably, the authors of [EL04] also state that "this
safety margin does not exist for highly interactive applications safety margin does not exist for highly interactive applications
where often only a single packet is in flight." where often only a single packet is in flight."
Although fast retransmit is preferrable there are situations where Although fast retransmit is preferrable there are situations where
timeouts are appropriate, or the only choice. For example, if the timeouts are appropriate, or the only choice. For example, if the
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. Furthermore, the loss(es) will not be the performance bottleneck. However, for
for connections that do not utilize enough capacity to enable fast connections that do not utilize enough capacity to enable fast
retransmit, RTO is the only choice. The time needed for loss retransmit, RTO-based loss detection is the only choice and the time
detection in such scenarios can become a serious performance required for this can become a serious performance bottleneck.
bottleneck.
3. RTO Restart Algorithm 3. RTO Restart 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, an alternative RTO restart can be used. By fast retransmit, an alternative restart can be used. By resetting
resetting the timer to "RTO - T_earliest", where T_earliest is the the timer to "RTO - T_earliest", where T_earliest is the time elapsed
time elapsed since the earliest outstanding segment was transmitted, since the earliest outstanding segment was transmitted,
retransmissions will always occur after exactly RTO seconds. This retransmissions will always occur after exactly RTO seconds. This
approach makes the RTO more aggressive than the standardized approach approach makes the RTO more aggressive than the standardized approach
in [RFC6298] but still conforms to the requirement in [RFC6298] that in [RFC6298] but still conforms to the requirement in [RFC6298] that
segments must not be retransmitted earlier than RTO seconds after segments must not be retransmitted earlier than RTO seconds after
their original transmission. their original transmission.
This document specifies a sender-only modification to TCP and SCTP This document specifies an OPTIONAL sender-only modification to TCP
which updates step 5.3 in Section 5 of [RFC6298] (and a similar and SCTP which updates step 5.3 in Section 5 of [RFC6298] (and a
update in Section 6.3.2 of [RFC4960] for SCTP): similar update in Section 6.3.2 of [RFC4960] for SCTP). A sender
that implements this method MUST follow the algorithm below:
When an ACK is received that acknowledges new data: When an ACK is received that acknowledges new data:
(1) Set T_earliest = 0. (1) Set T_earliest = 0.
(2) If the following two conditions hold: (2) If the following two conditions hold:
(a) The number of outstanding segments is less than four. (a) The number of outstanding segments is less than a RTO
restart threshold (rrthresh). The rrthresh SHOULD be
set to four.
(b) There is no unsent data ready for transmission. (b) There is no unsent data ready for transmission.
set T_earliest to the time elapsed since the earliest set T_earliest to the time elapsed since the earliest
outstanding segment was sent. outstanding segment was sent.
(3) Restart the retransmission timer so that it will expire after (3) Restart the retransmission timer so that it will expire after
"RTO - T_earliest" seconds (for the current value of RTO). "RTO - T_earliest" seconds (for the current value of RTO).
The update requires TCP implementations to track the time elapsed This update needs TCP implementations to track the time elapsed since
since the transmission of the earliest outstanding segment the transmission of the earliest outstanding segment (T_earliest).
(T_earliest). As the alternative restart is used only when the The modified restart is only necessary to conduct when fast
number of outstanding segments is less than four only four segments retransmit cannot be triggered, i.e., when there are less than four
need to be tracked. Furthermore, some implementations of TCP (e.g. segments outstanding. Therefore, only four segments need to be
Linux TCP) already track the transmission times of all segments. tracked by the TCP implementation. Furthermore, some implementations
of TCP (e.g. Linux TCP) already track the transmission times of all
segments.
4. Discussion 4. Discussion
In this section, we discuss the applicability and a number of issues In this section, we discuss the applicability and a number of issues
surrounding the modified RTO restart. surrounding the modified RTO restart.
4.1. Applicability 4.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
[HB08][PBP09]. For applications that have strict timing requirements [HB11][PBP09]. For applications that have strict timing requirements
(e.g. interactive web and gaming) rather than throughput (e.g. interactive web and gaming) rather than throughput
requirements, the modified restart approach could be important requirements, the modified restart approach could be important
because the RTT and also the delayed ACK timer of receivers are often because the RTT and also the delayed ACK timer of receivers are often
large components of the effective loss recovery time. Measurements large components of the effective loss recovery time. Measurements
in [HB08] have shown that the total transfer time of a lost segment in [HB11] have shown that the total transfer time of a lost segment
(including the original transmission time and the loss recovery time) (including the original transmission time and the loss recovery time)
can be reduced by 35% using the suggested approach. These results can be reduced by 35% using the suggested approach. These results
match those presented in [PGH06][PBP09], where the modified restart match those presented in [PGH06][PBP09], where the modified restart
approach is shown to significantly reduce retransmission latency. approach is shown to significantly reduce retransmission latency.
There are also traffic types that do not benefit from a modified
restart behavior of the timer. One example of such traffic is bulk
transmission. The reason why bulk traffic does not benefit from RTO
restart is related to the number of outstanding segments that such
flows usually have. Fast retransmit [RFC5681], the preferred loss
recovery mechanism, is triggered whenever three duplicate
acknowledgments arrive at a TCP sender. Duplicate acknowledgments
are generated by a receiver when out-of-order segments arrive. As
both segment loss and segment reordering cause out-of-order arrival,
fast retransmit waits for three duplicate acknowledgments before
regarding the segment as lost. Considering this, bulk flows will
mostly use fast retransmit as they often have three or more
outstanding segments. Moreover, as the modified restart behavior is
not activated when there are four, or more, segments outstanding
there is no increased risk of recovering loss using timeouts instead
of fast retransmits.
Given RTO restart's ability to only work when it is beneficial for
the loss recovery process, it is suitable as a system-wide default
mechanism for TCP traffic.
4.2. Spurious Timeouts 4.2. Spurious Timeouts
This document describes a modified RTO restart behavior that, in some This document describes a modified RTO restart behavior that, in some
situations, reduces the loss detection time and thereby increases the situations, reduces the loss detection time and thereby increases the
risk of spurious timeouts. In theory, the retransmission timer has a risk of spurious timeouts. In theory, the retransmission timer has a
lower bound of 1 second [RFC6298], which limits the risk of having lower bound of 1 second [RFC6298], which limits the risk of having
spurious timeouts. However, in practice most implementations use a spurious timeouts. However, in practice most implementations use a
significantly lower value. Initial measurements, conducted by the significantly lower value. Initial measurements, conducted by the
authors, show slight increases in the number of spurious timeouts authors, show slight increases in the number of spurious timeouts
when such lower values are used. However, further experiments, in when such lower values are used. However, further experiments, in
skipping to change at page 7, line 39 skipping to change at page 8, line 10
for fast retransmit (dupthresh), based on the number of outstanding for fast retransmit (dupthresh), based on the number of outstanding
segments, a smaller number of duplicate acknowledgments are needed to segments, a smaller number of duplicate acknowledgments are needed to
trigger a retransmission. In some situations, however, the algorithm trigger a retransmission. In some situations, however, the algorithm
is of no use or might not work properly. First, if a single segment is of no use or might not work properly. First, if a single segment
is outstanding, and lost, it is impossible to use early retransmit. is outstanding, and lost, it is impossible to use early retransmit.
Second, if ACKs are lost, the early retransmit cannot help. Third, Second, if ACKs are lost, the early retransmit cannot help. Third,
if the network path reorders segments, the algorithm might cause more if the network path reorders segments, the algorithm might cause more
unnecessary retransmissions than fast retransmit. unnecessary retransmissions than fast retransmit.
Following the fast retransmit mechanism standardized in [RFC5681] Following the fast retransmit mechanism standardized in [RFC5681]
this draft assumes a value of 3 for dupthresh. However, by this draft assumes a value of 3 for dupthresh, which is used as basis
considering a dynamic value for dupthresh a tighter integration with for rrthresh. However, by considering a dynamic value for dupthresh
early retransmit (or other experimental algorithms) could also be a tighter integration with early retransmit (or other experimental
possible. algorithms) could also be possible.
Tail Loss Probe [TLP] is a proposal to send up to two "probe Tail Loss Probe [TLP] is a proposal to send up to two "probe
segments" when a timer fires which is set to a value smaller than the segments" when a timer fires which is set to a value smaller than the
RTO. A "probe segment" is a new segment if new data is available, RTO. A "probe segment" is a new segment if new data is available,
else a retransmission. The intention is to compensate for sluggish else a retransmission. The intention is to compensate for sluggish
RTO behavior in situations where the RTO greatly exceeds the RTT, RTO behavior in situations where the RTO greatly exceeds the RTT,
which, according to measurements reported in [TLP], is not uncommon. which, according to measurements reported in [TLP], is not uncommon.
The Probe timeout (PTO) is normally two RTTs, and a spurious PTO is The Probe timeout (PTO) is normally two RTTs, and a spurious PTO is
less risky than a spurious RTO because it would not have the same less risky than a spurious RTO because it would not have the same
negative effects (clearing the scoreboard and restarting with slow- negative effects (clearing the scoreboard and restarting with slow-
start). In contrast, RTO restart is a small sender-only modification start). In contrast, RTO restart is trying to make the RTO more
of the RTO management algorithm and does not require an additional appropriate in cases where there is no need to be overly cautious.
timer or the use of SACK.
TLP is applicable in situations where RTO restart does not apply, and TLP is applicable in situations where RTO restart does not apply, and
it could overrule (yielding a similar general behavior, but with a it could overrule (yielding a similar general behavior, but with a
lower timeout) RTO restart in cases where the number of outstanding lower timeout) RTO restart in cases where the number of outstanding
segments is smaller than four and no new segments are available for segments is smaller than four and no new segments are available for
transmission. The PTO has the same inherent restart problems as the transmission. The PTO has the same inherent problem of restarting
RTO timer and could be combined with the modified restart approach to the timer on an incoming ACK, and could be combined with the modified
offer more consistent timeouts. restart approach to offer more consistent timeouts.
6. Acknowledgements 6. Acknowledgements
The authors wish to thank Godred Fairhurst, Yuchung Cheng, Mark The authors wish to thank Godred Fairhurst, Yuchung Cheng, Mark
Allman, Anantha Ramaiah and Richard Scheffenegger for commenting the Allman, Anantha Ramaiah, Richard Scheffenegger, and Nicolas Kuhn for
draft and the ideas behind it. commenting the draft and the ideas behind it.
All the authors are funded by the European Community under its All the authors are supported by RITE (http://riteproject.eu/ ), a
Seventh Framework Programme through the Reducing Internet Transport research project (ICT-317700) funded by the European Community under
Latency (RITE) project (ICT-317700). The views expressed are solely its Seventh Framework Program. The views expressed here are those of
those of the author(s). the author(s) only. The European Commission is not liable for any
use that may be made of the information in this document.
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Security Considerations 8. 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. This change does not raise any new timer's value when restarted. This change does not raise any new
security issues with TCP or SCTP. security issues with TCP or SCTP.
9. Changes from Previous Versions 9. Changes from Previous Versions
9.1. Changes from draft-ietf-...-00 to -01 9.1. Changes from draft-ietf-...-01 to -02
o Changed the algorithm description in Section 3 to use formal RFC
2119 language.
o Changed last paragraph of Section 3 to clarify why the RTO restart
algorithm is active when less than four segments are outstanding.
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
effects on traffic patterns that do not benefit from a modified
timer restart.
o Improved the wording throughout the document.
o Replaced and updated some references.
9.2. 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.
skipping to change at page 9, line 14 skipping to change at page 10, line 5
o Added acknowledgments. o Added acknowledgments.
10. References 10. References
10.1. Normative References 10.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.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[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.
[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, April 2003.
skipping to change at page 10, line 11 skipping to change at page 10, line 45
[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.
10.2. Informative References 10.2. Informative References
[BPS98] Balakrishnan, H., Padmanabhan, V., Seshan, S., Stemm, M.,
and R. Katz, "TCP Behavior of a Busy Web Server: Analysis
and Improvements", Proc. IEEE INFOCOM Conf., March 1998.
[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.
[HB08] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely [FDT13] Flach, T., Dukkipati, N., Terzis, A., Raghavan, B.,
message delivery?", Springer Telecommunication Systems, Cardwell, N., Cheng, Y., Jain, A., Hao, S., Katz-Bassett,
May 2010. E., and R. Govindan, "Reducing Web Latency: the Virtue of
Gentle Aggression", Proc. ACM SIGCOMM Conf., August 2013.
[HB11] Hurtig, P. and A. Brunstrom, "SCTP: designed for timely
message delivery?", Springer Telecommunication Systems 47
(3-4), August 2011.
[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,
skipping to change at page 10, line 48 skipping to change at page 11, line 34
Streams", IEEE LCN 2006, November 2006. Streams", IEEE LCN 2006, November 2006.
[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,
"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-00.txt, July 2012. 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. 33 change blocks. 
76 lines changed or deleted 114 lines changed or added

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