draft-ietf-tcpm-cubic-04.txt   draft-ietf-tcpm-cubic-05.txt 
TCP Maintenance and Minor Extensions (TCPM) WG I. Rhee TCP Maintenance and Minor Extensions (TCPM) WG I. Rhee
Internet-Draft NCSU Internet-Draft NCSU
Intended status: Informational L. Xu Intended status: Informational L. Xu
Expires: August 8, 2017 UNL Expires: January 18, 2018 UNL
S. Ha S. Ha
Colorado Colorado
A. Zimmermann A. Zimmermann
L. Eggert L. Eggert
NetApp NetApp
R. Scheffenegger R. Scheffenegger
February 4, 2017 July 17, 2017
CUBIC for Fast Long-Distance Networks CUBIC for Fast Long-Distance Networks
draft-ietf-tcpm-cubic-04 draft-ietf-tcpm-cubic-05
Abstract Abstract
CUBIC is an extension to the current TCP standards. The protocol CUBIC is an extension to the current TCP standards. The protocol
differs from the current TCP standards only in the congestion window differs from the current TCP standards only in the congestion window
adjustment function in the sender side. In particular, it uses a adjustment function in the sender side. In particular, it uses a
cubic function instead of a linear window increase function of the cubic function instead of a linear window increase function of the
current TCP standards to improve scalability and stability under fast current TCP standards to improve scalability and stability under fast
and long distance networks. CUBIC and its predecessor algorithm have and long distance networks. CUBIC and its predecessor algorithm have
been adopted as default by Linux and have been used for many years. been adopted as default by Linux and have been used for many years.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 August 8, 2017. This Internet-Draft will expire on January 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 33 skipping to change at page 2, line 33
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Design principle of CUBIC . . . . . . . . . . . . . . . . . . 4 3. Design principle of CUBIC . . . . . . . . . . . . . . . . . . 4
4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5 4. CUBIC Congestion Control . . . . . . . . . . . . . . . . . . 5
4.1. Window growth function . . . . . . . . . . . . . . . . . 6 4.1. Window growth function . . . . . . . . . . . . . . . . . 6
4.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 7 4.2. TCP-friendly region . . . . . . . . . . . . . . . . . . . 7
4.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7 4.3. Concave region . . . . . . . . . . . . . . . . . . . . . 7
4.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Convex region . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 8 4.5. Multiplicative decrease . . . . . . . . . . . . . . . . . 8
4.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8 4.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 8
4.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.7. Timeout . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Slowstart . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 9 5.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 10
5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11 5.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 11
5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12 5.3. Difficult Environments . . . . . . . . . . . . . . . . . 12
5.4. Investigating a Range of Environments . . . . . . . . . . 12 5.4. Investigating a Range of Environments . . . . . . . . . . 12
5.5. Protection against Congestion Collapse . . . . . . . . . 12 5.5. Protection against Congestion Collapse . . . . . . . . . 13
5.6. Fairness within the Alternative Congestion Control 5.6. Fairness within the Alternative Congestion Control
Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 12 Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Performance with Misbehaving Nodes and Outside Attackers 12 5.7. Performance with Misbehaving Nodes and Outside Attackers 13
5.8. Behavior for Application-Limited Flows . . . . . . . . . 12 5.8. Behavior for Application-Limited Flows . . . . . . . . . 13
5.9. Responses to Sudden or Transient Events . . . . . . . . . 13 5.9. Responses to Sudden or Transient Events . . . . . . . . . 13
5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13 5.10. Incremental Deployment . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The low utilization problem of TCP in fast long-distance networks is The low utilization problem of TCP in fast long-distance networks is
well documented in [K03][RFC3649]. This problem arises from a slow well documented in [K03][RFC3649]. This problem arises from a slow
increase of congestion window following a congestion event in a increase of congestion window following a congestion event in a
network with a large bandwidth delay product (BDP). Our experience network with a large bandwidth delay product (BDP). Our experience
[HKLRX06] indicates that this problem is frequently observed even in [HKLRX06] indicates that this problem is frequently observed even in
the range of congestion window sizes over several hundreds of packets the range of congestion window sizes over several hundreds of packets
(each packet is sized around 1000 bytes) especially under a network (each packet is sized around 1000 bytes) especially under a network
path with over 100ms round-trip times (RTTs). This problem is path with over 100ms round-trip times (RTTs). This problem is
equally applicable to all Reno style TCP standards and their equally applicable to all Reno style TCP standards and their
variants, including TCP-RENO [RFC5681], TCP-NewReno [RFC6582], TCP- variants, including TCP-RENO [RFC5681], TCP-NewReno
SACK [RFC2018], SCTP [RFC4960], TFRC [RFC5348] that use the same [RFC6582][RFC6675], SCTP [RFC4960], TFRC [RFC5348] that use the same
linear increase function for window growth, which we refer to linear increase function for window growth, which we refer to
collectively as Standard TCP below. collectively as Standard TCP below.
CUBIC [HRX08] is a modification to the congestion control mechanism CUBIC [HRX08] is a modification to the congestion control mechanism
of Standard TCP, in particular, to the window increase function of of Standard TCP, in particular, to the window increase function of
Standard TCP senders, to remedy this problem. Specifically, it uses Standard TCP senders, to remedy this problem. Specifically, it uses
a cubic function instead of a linear window increase function of the a cubic function instead of a linear window increase function of the
Standrad TCP to improve scalability and stability under fast and long Standrad TCP to improve scalability and stability under fast and long
distance networks. distance networks.
skipping to change at page 6, line 10 skipping to change at page 6, line 10
4. CUBIC Congestion Control 4. CUBIC Congestion Control
The unit of all window sizes in this document is segments of the The unit of all window sizes in this document is segments of the
maximum segment size (MSS), and the unit of all times is seconds. maximum segment size (MSS), and the unit of all times is seconds.
4.1. Window growth function 4.1. Window growth function
CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by CUBIC maintains the acknowledgment (ACK) clocking of Standard TCP by
increasing congestion window only at the reception of ACK. The increasing congestion window only at the reception of ACK. The
protocol does not make any change to the fast recovery and retransmit protocol does not make any change to the fast recovery and retransmit
of TCP, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During of TCP, such as TCP-NewReno [RFC6582] [RFC6675]. During congestion
congestion avoidance after fast recovery, CUBIC changes the window avoidance after fast recovery, CUBIC changes the window update
update algorithm of Standard TCP. Suppose that W_max is the window algorithm of Standard TCP. Suppose that W_max is the window size
size before the window is reduced in the last fast retransmit and before the window is reduced in the last fast retransmit and
recovery. recovery.
The window growth function of CUBIC uses the following function: The window growth function of CUBIC uses the following function:
W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1) W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)
where C is a constant fixed to determine the aggressiveness of window where C is a constant fixed to determine the aggressiveness of window
growth in high BDP networks, t is the elapsed time from the last growth in high BDP networks, t is the elapsed time from the last
window reduction that is measured right after the fast recovery in window reduction that is measured right after the fast recovery in
response to duplicate ACKs or after the congestion window reduction response to duplicate ACKs or after the congestion window reduction
skipping to change at page 6, line 35 skipping to change at page 6, line 35
function takes to increase the current window size to W_max if there function takes to increase the current window size to W_max if there
is no further loss event and is calculated by using the following is no further loss event and is calculated by using the following
equation: equation:
K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2) K = cubic_root(W_max*(1-beta_cubic)/C) (Eq. 2)
where beta_cubic is the CUBIC multiplication decrease factor, that where beta_cubic is the CUBIC multiplication decrease factor, that
is, when a packet loss detected by duplicate ACKs or a network is, when a packet loss detected by duplicate ACKs or a network
congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its congestion detected by ECN-Echo ACKs occurs, CUBIC reduces its
current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how current window cwnd to W_cubic(0)=W_max*beta_cubic. We discuss how
we set C in the next Section in more details. we set beta_cubic in Section 4.5 and how we set C in Section 5.
Upon receiving an ACK during congestion avoidance, CUBIC computes the Upon receiving an ACK during congestion avoidance, CUBIC computes the
window growth rate during the next RTT period using Eq. 1. It sets window growth rate during the next RTT period using Eq. 1. It sets
W_cubic(t+RTT) as the candidate target value of congestion window, W_cubic(t+RTT) as the candidate target value of congestion window,
where RTT is the weithed average RTT calculated by the standard TCP. where RTT is the weithed average RTT calculated by the standard TCP.
Depending on the value of the current window size cwnd, CUBIC runs in Depending on the value of the current window size cwnd, CUBIC runs in
three different modes. First, if cwnd is less than the window size three different modes. First, if cwnd is less than the window size
that Standard TCP would reach at time t after the last loss event, that Standard TCP would reach at time t after the last loss event,
then CUBIC is in the TCP friendly region (we describe below how to then CUBIC is in the TCP friendly region (we describe below how to
skipping to change at page 7, line 34 skipping to change at page 7, line 34
(1.5/p)^0.5, as the Standard TCP is a special case of AIMD with (1.5/p)^0.5, as the Standard TCP is a special case of AIMD with
alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as alpha_aimd=1 and beta_aimd=0.5. Thus, for Eq. 3 to be the same as
that of Standard TCP, alpha_aimd must be equal to that of Standard TCP, alpha_aimd must be equal to
3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by 3*(1-beta_aimd)/(1+beta_aimd). As AIMD increases its window by
alpha_aimd per RTT, we can get the window size of AIMD in terms of alpha_aimd per RTT, we can get the window size of AIMD in terms of
the elapsed time t as follows: the elapsed time t as follows:
W_aimd(t) = W_max*beta_aimd + W_aimd(t) = W_max*beta_aimd +
[3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4) [3*(1-beta_aimd)/(1+beta_aimd)] * (t/RTT) (Eq. 4)
If W_cubic(t) is less than W_aimd(t), then the protocol is in the TCP If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd
is greater than or less than W_max), then the protocol is in the TCP
friendly region and cwnd SHOULD be set to W_aimd(t) at each reception friendly region and cwnd SHOULD be set to W_aimd(t) at each reception
of ACK. of ACK.
4.3. Concave region 4.3. Concave region
When receiving an ACK in congestion avoidance, if the protocol is not When receiving an ACK in congestion avoidance, if the protocol is not
in the TCP-friendly region and cwnd is less than W_max, then the in the TCP-friendly region and cwnd is less than W_max, then the
protocol is in the concave region. In this region, cwnd MUST be protocol is in the concave region. In this region, cwnd MUST be
incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK, incremented by (W_cubic(t+RTT) - cwnd)/cwnd for each received ACK,
where W_cubic(t+RTT) is calculated using Eq. 1. where W_cubic(t+RTT) is calculated using Eq. 1.
skipping to change at page 9, line 5 skipping to change at page 9, line 5
room for growth if the existing flows have been using all the room for growth if the existing flows have been using all the
bandwidth of the network. To increase this release of bandwidth by bandwidth of the network. To increase this release of bandwidth by
existing flows, the following mechanism called fast convergence existing flows, the following mechanism called fast convergence
SHOULD be implemented. SHOULD be implemented.
With fast convergence, when a loss event occurs, before a window With fast convergence, when a loss event occurs, before a window
reduction of congestion window, a flow remembers the last value of reduction of congestion window, a flow remembers the last value of
W_max before it updates W_max for the current loss event. Let us W_max before it updates W_max for the current loss event. Let us
call the last value of W_max to be W_last_max. call the last value of W_max to be W_last_max.
if (W_max < W_last_max){ // check downward trend if (W_max < W_last_max){ // should we make room for others
W_last_max = W_max; // remember the last W_max W_last_max = W_max; // remember the last W_max
W_max = W_max*(1+beta_cubic)/2; // further reduce W_max W_max = W_max*(1.0+beta_cubic)/2.0; // further reduce W_max
} else { // check upward trend } else {
W_last_max = W_max // remember the last W_max W_last_max = W_max // remember the last W_max
} }
This allows W_max to be slightly less than the original W_max. Since At a loss event, if the current value of W_max is less than
flows spend most of time around their W_max, flows with larger W_last_max, this indicates that the saturation point experienced by
bandwidth shares tend to spend more time around the plateau allowing this flow is getting reduced because of the change in available
more time for flows with smaller shares to increase their windows. bandwidth. Then we allow this flow to release more bandwidth by
reducing W_max further. This action effectively lengthens the time
for this flow to increase its window because the reduced W_max forces
the flow to have the plateau earlier. This allows more time for the
new flow to catch up its window size
The fast convergence is designed for network environments with
multiple CUBIC flows. In network environments with only a single
CUBIC flow and without any other traffic, the fast convergence SHOULD
be disabled.
4.7. Timeout 4.7. Timeout
In case of timeout, CUBIC follows the standard TCP to reduce cwnd, In case of timeout, CUBIC follows the standard TCP to reduce cwnd,
but sets ssthresh using beta_cubic (same as in Section 4.5). but sets ssthresh using beta_cubic (same as in Section 4.5).
4.8. Slowstart
CUBIC MUST employ a slow start algorithm, when the cwnd is no more
than ssthresh. Among the slow start algorithms, CUBIC MAY choose the
standard TCP slow start[RFC5681] in general networks, or the limited
slow start [RFC3742] or hybrid slow start [HR08] for high-bandwidth
and long-distance networks.
5. Discussion 5. Discussion
In this section, we further discuss the safety features of CUBIC In this section, we further discuss the safety features of CUBIC
following the guidelines specified in [RFC5033]. following the guidelines specified in [RFC5033].
With a deterministic loss model where the number of packets between With a deterministic loss model where the number of packets between
two successive lost events is always 1/p, CUBIC always operates with two successive lost events is always 1/p, CUBIC always operates with
the concave window profile which greatly simplifies the performance the concave window profile which greatly simplifies the performance
analysis of CUBIC. The average window size of CUBIC can be obtained analysis of CUBIC. The average window size of CUBIC can be obtained
by the following function: by the following function:
skipping to change at page 11, line 16 skipping to change at page 11, line 38
packets. If the packet size is 1500 bytes, then TCP can achieve an packets. If the packet size is 1500 bytes, then TCP can achieve an
average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4 average rate of 1.44 Gbps. In this case, CUBIC with C=0.04 or C=0.4
achieves exactly the same rate as Standard TCP, whereas HSTCP is achieves exactly the same rate as Standard TCP, whereas HSTCP is
about ten times more aggressive than Standard TCP. about ten times more aggressive than Standard TCP.
We can see that C determines the aggressiveness of CUBIC in competing We can see that C determines the aggressiveness of CUBIC in competing
with other protocols for the bandwidth. CUBIC is more friendly to with other protocols for the bandwidth. CUBIC is more friendly to
the Standard TCP, if the value of C is lower. However, we do not the Standard TCP, if the value of C is lower. However, we do not
recommend to set C to a very low value like 0.04, since CUBIC with a recommend to set C to a very low value like 0.04, since CUBIC with a
low C cannot efficiently use the bandwidth in long RTT and high low C cannot efficiently use the bandwidth in long RTT and high
bandwidth networks. Based on these observations, we find C=0.4 gives bandwidth networks. Based on these observations and our experiments,
a good balance between TCP-friendliness and aggressiveness of window we find C=0.4 gives a good balance between TCP-friendliness and
growth. Therefore, C SHOULD be set to 0.4. With C set to 0.4, Eq. 6 aggressiveness of window growth. Therefore, C SHOULD be set to 0.4.
is reduced to: With C set to 0.4, Eq. 6 is reduced to:
AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7) AVG_W_cubic = 1.054 * (RTT^0.75) / (p^0.75) (Eq. 7)
Eq. 7 is then used in the next subsection to show the scalability of Eq. 7 is then used in the next subsection to show the scalability of
CUBIC. CUBIC.
5.2. Using Spare Capacity 5.2. Using Spare Capacity
CUBIC uses a more aggressive window growth function than Standard TCP CUBIC uses a more aggressive window growth function than Standard TCP
under long RTT and high bandwidth networks. under long RTT and high bandwidth networks.
skipping to change at page 12, line 22 skipping to change at page 12, line 42
CUBIC is designed to remedy the poor performance of TCP in fast long- CUBIC is designed to remedy the poor performance of TCP in fast long-
distance networks. distance networks.
5.4. Investigating a Range of Environments 5.4. Investigating a Range of Environments
CUBIC has been extensively studied by using both NS-2 simulation and CUBIC has been extensively studied by using both NS-2 simulation and
test-bed experiments covering a wide range of network environments. test-bed experiments covering a wide range of network environments.
More information can be found in [HKLRX06]. More information can be found in [HKLRX06].
Same as Standard TCP, CUBIC is a loss-based congestion control Same as Standard TCP, CUBIC is a loss-based congestion control
algorithm. Therefore, CUBIC, which is designed to be more aggressive algorithm. Because CUBIC is designed to be more aggressive (due to
than Standard TCP in fast and long distance networks, can fill large faster window growth function and bigger multiplicative decrease
drop-tail buffers more quickly than Standard TCP. In this case, factor) than Standard TCP in fast and long distance networks, it can
proper queue sizing and management [RFC7567] could be used to reduce fill large drop-tail buffers more quickly than Standard TCP and
the packet queueing delay. increase the risk of a standing queue[KWAF16]. In this case, proper
queue sizing and management [RFC7567] could be used to reduce the
packet queueing delay.
5.5. Protection against Congestion Collapse 5.5. Protection against Congestion Collapse
With regard to the potential of causing congestion collapse, CUBIC With regard to the potential of causing congestion collapse, CUBIC
behaves like standard TCP since CUBIC modifies only the window behaves like standard TCP since CUBIC modifies only the window
adjustment algorithm of TCP. Thus, it does not modify the ACK adjustment algorithm of TCP. Thus, it does not modify the ACK
clocking and Timeout behaviors of Standard TCP. clocking and Timeout behaviors of Standard TCP.
5.6. Fairness within the Alternative Congestion Control Algorithm. 5.6. Fairness within the Alternative Congestion Control Algorithm.
skipping to change at page 12, line 52 skipping to change at page 13, line 29
link. link.
5.7. Performance with Misbehaving Nodes and Outside Attackers 5.7. Performance with Misbehaving Nodes and Outside Attackers
This is not considered in the current CUBIC. This is not considered in the current CUBIC.
5.8. Behavior for Application-Limited Flows 5.8. Behavior for Application-Limited Flows
CUBIC does not raise its congestion window size if the flow is CUBIC does not raise its congestion window size if the flow is
currently limited by the application instead of the congestion currently limited by the application instead of the congestion
window. In cases of idle periods, t in Eq. 1 MUST NOT include the window. In case of long periods when cwnd is not updated due to the
idle time; otherwise, W_cubic(t) might be very high after restarting application rate limit, such as idle periods, t in Eq. 1 MUST NOT
from a long idle time. include these periods; otherwise, W_cubic(t) might be very high after
restarting from these periods.
5.9. Responses to Sudden or Transient Events 5.9. Responses to Sudden or Transient Events
In case that there is a sudden congestion, a routing change, or a In case that there is a sudden congestion, a routing change, or a
mobility event, CUBIC behaves the same as Standard TCP. mobility event, CUBIC behaves the same as Standard TCP.
5.10. Incremental Deployment 5.10. Incremental Deployment
CUBIC requires only the change of TCP senders, and does not require CUBIC requires only the change of TCP senders, and does not require
any assistant of routers. any assistant of routers.
skipping to change at page 13, line 38 skipping to change at page 14, line 18
European Union's Horizon 2020 research and innovation program European Union's Horizon 2020 research and innovation program
2014-2018 under grant agreement No. 644866 (SSICLOPS). This document 2014-2018 under grant agreement No. 644866 (SSICLOPS). This document
reflects only the authors' views and the European Commission is not reflects only the authors' views and the European Commission is not
responsible for any use that may be made of the information it responsible for any use that may be made of the information it
contains. contains.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<http://www.rfc-editor.org/info/rfc2018>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows",
RFC 3649, DOI 10.17487/RFC3649, December 2003, RFC 3649, DOI 10.17487/RFC3649, December 2003,
<http://www.rfc-editor.org/info/rfc3649>. <http://www.rfc-editor.org/info/rfc3649>.
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
Congestion Windows", RFC 3742, DOI 10.17487/RFC3742, March
2004, <http://www.rfc-editor.org/info/rfc3742>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
[RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion
Control Algorithms", BCP 133, RFC 5033, Control Algorithms", BCP 133, RFC 5033,
DOI 10.17487/RFC5033, August 2007, DOI 10.17487/RFC5033, August 2007,
<http://www.rfc-editor.org/info/rfc5033>. <http://www.rfc-editor.org/info/rfc5033>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
skipping to change at page 14, line 28 skipping to change at page 15, line 5
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<http://www.rfc-editor.org/info/rfc5681>. <http://www.rfc-editor.org/info/rfc5681>.
[RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The
NewReno Modification to TCP's Fast Recovery Algorithm", NewReno Modification to TCP's Fast Recovery Algorithm",
RFC 6582, DOI 10.17487/RFC6582, April 2012, RFC 6582, DOI 10.17487/RFC6582, April 2012,
<http://www.rfc-editor.org/info/rfc6582>. <http://www.rfc-editor.org/info/rfc6582>.
[RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M.,
and Y. Nishida, "A Conservative Loss Recovery Algorithm
Based on Selective Acknowledgment (SACK) for TCP",
RFC 6675, DOI 10.17487/RFC6675, August 2012,
<http://www.rfc-editor.org/info/rfc6675>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<http://www.rfc-editor.org/info/rfc7567>. <http://www.rfc-editor.org/info/rfc7567>.
9.2. Informative References 9.2. Informative References
[CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic [CEHRX07] Cai, H., Eun, D., Ha, S., Rhee, I., and L. Xu, "Stochastic
Ordering for Internet Congestion Control and its Ordering for Internet Congestion Control and its
Applications", In Proceedings of IEEE INFOCOM , May 2007. Applications", In Proceedings of IEEE INFOCOM , May 2007.
skipping to change at page 15, line 5 skipping to change at page 15, line 35
[GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary [GV02] Gorinsky, S. and H. Vin, "Extended Analysis of Binary
Adjustment Algorithms", Technical Report TR2002-29, Adjustment Algorithms", Technical Report TR2002-29,
Department of Computer Sciences , The University of Texas Department of Computer Sciences , The University of Texas
at Austin , August 2002. at Austin , August 2002.
[HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step [HKLRX06] Ha, S., Kim, Y., Le, L., Rhee, I., and L. Xu, "A Step
toward Realistic Performance Evaluation of High-Speed TCP toward Realistic Performance Evaluation of High-Speed TCP
Variants", International Workshop on Protocols for Fast Variants", International Workshop on Protocols for Fast
Long-Distance Networks , February 2006. Long-Distance Networks , February 2006.
[HR08] Ha, S. and I. Rhee, "Hybrid Slow Start for High-Bandwidth
and Long-Distance Networks", International Workshop on
Protocols for Fast Long-Distance Networks , 2008.
[HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly [HRX08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A New TCP-Friendly
High-Speed TCP Variant", ACM SIGOPS Operating System High-Speed TCP Variant", ACM SIGOPS Operating System
Review , 2008. Review , 2008.
[K03] Kelly, T., "Scalable TCP: Improving Performance in [K03] Kelly, T., "Scalable TCP: Improving Performance in
HighSpeed Wide Area Networks", ACM SIGCOMM Computer HighSpeed Wide Area Networks", ACM SIGCOMM Computer
Communication Review , April 2003. Communication Review , April 2003.
[KWAF16] Khademi, N., Welzl, M., Armitage, G., and G. Fairhurst,
"TCP Alternative Backoff with ECN (ABE)", Internet-draft,
IETF work-in-progress draft-khademi-tcpm-
alternativebackoff-ecn-01 , October 2016.
[LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control [LS08] Leith, D. and R. Shorten, "H-TCP: TCP Congestion Control
for High Bandwidth-Delay Product Paths", Internet-draft for High Bandwidth-Delay Product Paths", Internet-draft
draft-leith-tcp-htcp-06 , April 2008. draft-leith-tcp-htcp-06 , April 2008.
[XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase [XHR04] Xu, L., Harfoush, K., and I. Rhee, "Binary Increase
Congestion Control for Fast, Long Distance Networks", In Congestion Control for Fast, Long Distance Networks", In
Proceedings of IEEE INFOCOM , March 2004. Proceedings of IEEE INFOCOM , March 2004.
Authors' Addresses Authors' Addresses
 End of changes. 25 change blocks. 
46 lines changed or deleted 82 lines changed or added

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