draft-ietf-tcpm-cubic-01.txt   draft-ietf-tcpm-cubic-02.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: July 21, 2016 UNL Expires: February 6, 2017 UNL
S. Ha S. Ha
Colorado Colorado
A. Zimmermann A. Zimmermann
L. Eggert L. Eggert
R. Scheffenegger R. Scheffenegger
NetApp NetApp
January 18, 2016 August 5, 2016
CUBIC for Fast Long-Distance Networks CUBIC for Fast Long-Distance Networks
draft-ietf-tcpm-cubic-01 draft-ietf-tcpm-cubic-02
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 of the current TCP cubic function instead of a linear window increase of the current TCP
standards to improve scalability and stability under fast and long standards to improve scalability and stability under fast and long
distance networks. BIC-TCP, a predecessor of CUBIC, has been a distance networks. BIC-TCP, a predecessor of CUBIC, has been a
default TCP adopted by Linux since year 2005 and has already been default TCP adopted by Linux since year 2005 and has already been
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 July 21, 2016. This Internet-Draft will expire on February 6, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 44 skipping to change at page 2, line 44
3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 7 3.6. Fast convergence . . . . . . . . . . . . . . . . . . . . 7
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 8 4.1. Fairness to standard TCP . . . . . . . . . . . . . . . . 8
4.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 10 4.2. Using Spare Capacity . . . . . . . . . . . . . . . . . . 10
4.3. Difficult Environments . . . . . . . . . . . . . . . . . 11 4.3. Difficult Environments . . . . . . . . . . . . . . . . . 11
4.4. Investigating a Range of Environments . . . . . . . . . . 11 4.4. Investigating a Range of Environments . . . . . . . . . . 11
4.5. Protection against Congestion Collapse . . . . . . . . . 11 4.5. Protection against Congestion Collapse . . . . . . . . . 11
4.6. Fairness within the Alternative Congestion Control 4.6. Fairness within the Alternative Congestion Control
Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 11 Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Performance with Misbehaving Nodes and Outside Attackers 11 4.7. Performance with Misbehaving Nodes and Outside Attackers 11
4.8. Responses to Sudden or Transient Events . . . . . . . . . 11 4.8. Behavior for Application-Limited Flows . . . . . . . . . 11
4.9. Incremental Deployment . . . . . . . . . . . . . . . . . 11 4.9. Responses to Sudden or Transient Events . . . . . . . . . 11
4.10. Incremental Deployment . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
skipping to change at page 5, line 35 skipping to change at page 5, line 35
3. CUBIC Congestion Control 3. 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.
3.1. Window growth function 3.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-NewReno [RFC6582] and TCP-SACK [RFC2018]. During congestion of TCP, such as TCP-NewReno [RFC6582] and TCP-SACK [RFC2018]. During
avoidance after fast recovery, CUBIC changes the window update congestion avoidance after fast recovery, CUBIC changes the window
algorithm of Standard TCP. Suppose that W_max is the window size update algorithm of Standard TCP. Suppose that W_max is the window
before the window is reduced in the last fast retransmit and size 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,and K is the time period that the above function window reduction (measured right after the fast recovery), and K is
takes to increase the current window size to W_max when there is no the time period that the above function takes to increase the current
further loss event and is calculated by using the following equation: window size to W_max if there is no further loss event and is
calculated by using the following 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 occurs, CUBIC reduces its current window cwnd is, when a packet loss occurs, CUBIC reduces its current window cwnd
to cwnd*beta_cubic. We discuss how we set C in the next Section in to cwnd*beta_cubic. We discuss how we set C in the next Section in
more details. more details.
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
skipping to change at page 6, line 27 skipping to change at page 6, line 29
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
determine this window size of Standard TCP in term of time t). determine this window size of Standard TCP in term of time t).
Otherwise, if cwnd is less than W_max, then CUBIC is the concave Otherwise, if cwnd is less than W_max, then CUBIC is the concave
region, and if cwnd is larger than W_max, CUBIC is in the convex region, and if cwnd is larger than W_max, CUBIC is in the convex
region. Below, we describe the exact actions taken by CUBIC in each region. Below, we describe the exact actions taken by CUBIC in each
region. region.
3.2. TCP-friendly region 3.2. TCP-friendly region
When receiving an ACK in congestion avoidance, we first check whether When receiving an ACK in congestion avoidance, we first check whether
the protocol is in the TCP region or not. This is done as follows. the protocol is in the TCP region or not. This is done by estimating
We can analyze the window size of a TCP-friendly AIMD in terms of the the average rate of the Standard TCP using a simple analysis
elapsed time t. Using a simple analysis in [FHP00], we can analyze described in [FHP00]. It considers the Standard TCP as a special
the average window size of additive increase and multiplicative case of an Additive Increase and Multiplicative Decrease algorithm
decrease (AIMD) with an additive factor alpha_aimd and a (AIMD), which has an additive factor alpha_aimd and a multiplicative
multiplicative factor beta_aimd with the following function: factor beta_aimd with the following function:
AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) / AVG_W_aimd = [ alpha_aimd * (1+beta_aimd) /
(2*(1-beta_aimd)*p) ]^0.5 (Eq. 3) (2*(1-beta_aimd)*p) ]^0.5 (Eq. 3)
By the same analysis, the average window size of Standard TCP is By the same analysis, the average window size of Standard TCP is
(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
skipping to change at page 11, line 38 skipping to change at page 11, line 38
in the same bottleneck links to an equal bandwidth share. When in the same bottleneck links to an equal bandwidth share. When
competing flows have different RTTs, their bandwidth shares are competing flows have different RTTs, their bandwidth shares are
linearly proportional to the inverse of their RTT ratios. This is linearly proportional to the inverse of their RTT ratios. This is
true independent of the level of statistical multiplexing in the true independent of the level of statistical multiplexing in the
link. link.
4.7. Performance with Misbehaving Nodes and Outside Attackers 4.7. Performance with Misbehaving Nodes and Outside Attackers
This is not considered in the current CUBIC. This is not considered in the current CUBIC.
4.8. Responses to Sudden or Transient Events 4.8. Behavior for Application-Limited Flows
CUBIC does not raise its congestion window size if the flow is
currently limited by the application instead of the congestion
window. In cases of idle periods, t in Eq. 1 should not include the
idle time; otherwise, W_cubic(t) might be very high after restarting
from a long idle time.
4.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.
4.9. Incremental Deployment 4.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.
5. Security Considerations 5. Security Considerations
This proposal makes no changes to the underlying security of TCP. This proposal makes no changes to the underlying security of TCP.
6. IANA Considerations 6. IANA Considerations
 End of changes. 11 change blocks. 
22 lines changed or deleted 31 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/