Internet DRAFT - draft-zuo-mptcp-degradation
draft-zuo-mptcp-degradation
MPTCP Working Group F. Wang
Internet-Draft J. Zuo
Intended Status: Standards Track Z. Cao
Expires: April 29, 2018 K. Zheng
Huawei
October 30, 2017
A Proactive Approach to Avoid Performance Degradation of MPTCP
draft-zuo-mptcp-degradation-00
Abstract
One of the goals for MPTCP is utilizing multiple paths to perform at
least as well as the best path in terms of throughput. However, this
goal might not be arrived at because of the path asymmetry, which is
called as the performance-degradation problem of MPTCP in this draft.
Some existing methods focus on this problem, such as penalizing and
opportunistic retransmission, which reactively responds to the head-
of-line blocking for trying their best to send data across all paths.
In order to efficiently utilize the capabilities of the multiple
paths, this draft proposes an approach that proactively selects the
best path(s) to send data instead of always bonding all paths
together.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
J. Zuo, et al Expires April 29, 2018 [Page 1]
INTERNET-DRAFT October 30, 2017
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3
3. A Proactive Approach to Avoid MPTCP Performance Degradation . . 3
3.1 Throughput Measurement . . . . . . . . . . . . . . . . . . . 4
3.2 Path Selection Strategy . . . . . . . . . . . . . . . . . . 5
4. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Slow-Start Stage . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Congestion-Avoidance Stage . . . . . . . . . . . . . . . . . 6
4.2.1 Redundant Transmission Mode . . . . . . . . . . . . . . 6
4.2.2 Multipath Transmission Mode . . . . . . . . . . . . . . 7
4.2.3 Throughput Comparison . . . . . . . . . . . . . . . . . 7
4.2.4 Indicator Timer Timeout . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
MultiPath TCP (MPTCP) enables a transport connection across multiple
paths simultaneously [RFC6824]. According to [RFC6356], one of the
MPTCP's goals is improving throughput: a multipath flow should
perform at least as well as a single path flow would on the best of
the path available to it. However, this goal cannot be always
achieved due to the head-of-line blocking caused by the path
asymmetry, e.g. WiFi and LTE in smart phones. To be convenient, this
phenomenon (that MPTCP performs worse than the best path) is called
as the performance-degradation problem in this draft.
The direct solution for this problem is allocating a large enough
receive buffer. As in [RFC6182], `The RECOMMENDED receive buffer is
J. Zuo, et al Expires April 29, 2018 [Page 2]
INTERNET-DRAFT October 30, 2017
2*sum(BW_i)*RTT_max, which `ensures subflows do not stall when fast
retransmit is triggered on any subflow'. However, the buffer size can
be very large to cover all the possible scenarios. In other words,
the buffer size can be limited and the performance-degradation
problem is possible to exist. Therefore, it needs a solution for
MPTCP protocol that can solve this problem. On this issue, some
reactive methods have been proposed, such as penalizing and
opportunistic retransmission. They take actions after the head-of-
line blocking occurring and their purpose is to send data across all
paths as possible as they can. Experiments show that even with these
methods, the capabilities of the multiple paths may not be
efficiently utilized. Meanwhile, instead of bonding all paths
together, [RFC6182] indicates that it would be better `to only use
some of the fastest available paths for the MPTCP connection in
extreme cases'.
This draft focuses on this problem and proposes a proactive approach,
which dynamically employs part or all of the paths for higher
utilization efficiency. In particular, this approach first measures
the aggregated throughput of the multiple paths and the throughput of
the best single path in real time. Then, if the performance-
degradation phenomenon is derived through the throughput comparison,
only the best path is used to send data.
2. Acronyms and Terminology
MPTCP: Multiple Path Transport Control Protocol
RTT: Round-robin Transmit Time
PLR: Packet Loss Ratio
BW: BandWidth
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. A Proactive Approach to Avoid MPTCP Performance Degradation
This section introduces the basic principles of the proposed
approach: 1) how to efficiently measure the characteristics of
multiple paths; 2) how to select the path(s). More details regarding
to this approach can be found in Section 4. Briefly, through
measuring and comparing the path characteristics, the best path(s) is
selected to satisfy a special purpose, such as the high throughput or
J. Zuo, et al Expires April 29, 2018 [Page 3]
INTERNET-DRAFT October 30, 2017
low RTT. In theory, path characteristics can be RTT, throughput,
congestion window, etc., while only throughput is considered in this
draft for a case study. As shown in Figure 1, the proposed approach
is implemented in the Performance-Degradation-Free Module of the MP
layer.
3.1 Throughput Measurement
This section describes the method of the throughput measurement for
multipath transmissions. As shown in [CMT-SCTP], one possible method
is modeling the aggregated throughput of multiple paths and measuring
the related path characteristics, i.e. buffer size, PLR, BW and RTT.
However, it is hard to accurately model the throughput, since 1)
lacking of BW evaluation methods, 2) and the small PLR can be
obtained only after a huge number of data exchanging.
This draft proposes a method that directly measures the multipath and
best-single-path throughputs, in order to avoid the measurements of
BW and PLR. At first, two modes are defined for the throughput
measurement:
1) Redundant transmission mode: Multiple paths transmit the same
data;
2) MultiPath (MP) transmission mode: Multiple paths transmit
different data with using a MPTCP scheduling scheme, such as minRTT
(the default scheduling method) in version 0.92. By the way, the
opportunistic retransmission and penalization mechanisms can be
enabled in MP mode.
The redundant transmission mode is a kind of scheduling scheme in
MPTCP v0.92, which is usually used to achieve lower packet delay than
that of a single path. Because of wasting bandwidth (BW), the
redundant transmission mode is ignored when MPTCP aggregates the BWs
of multiple paths. However, this draft utilizes the redundant
transmission mode to measure the throughputs of each path and the
best single path, while using the multipath transmission mode to
measure the aggregated throughput. To be convenient, the redundant/MP
transmission mode is also called as the redundant/MP mode in the
following part of this draft. Moreover, the throughput measurement is
executed during the data transmission without introducing extra
packets, and is periodic for self-adapting to the dynamic network
environment.
The Figure 1 briefly shows the relationship between the two
transmission modes and our Performance-Degradation-Free Module in MP
layer.
J. Zuo, et al Expires April 29, 2018 [Page 4]
INTERNET-DRAFT October 30, 2017
+---------------------------------------+
| APP |
+---------------------------------------+
| MP Layer |
| +- - - - - - - - - - - - - - - - - -+ |
| |Performance-Degradation-Free Module| |
| +- - - - - - - - -+- - - - - - - - -+ |
| | Redundant Mode | MP Mode | |
| +- - - - - - - - -+- - - - - - - - -+ |
+-------------------+-------------------+
| Path 1 | Path 2 |
+---------------------------------------+
Figure 1: The performance-degradation-free module in the MP layer.
3.2 Path Selection Strategy
All these paths or the best one of them are used to send data
depending on the corresponding throughput.
4. Operation Overview
Section 3 presents the main principles, i.e. throughput measurement
and path selection. This section introduces how the proposed approach
works in details. According to different congestion-control schemes,
the proposed approach may have slow-start stage and congestion-
control stage. At the first stage, the approach ensures that the slow
start of the scheme has been finished. At the second stage, the
approach periodically measures the average throughputs of multiple
paths and the best path, and employs the suitable path(s) through
throughput comparisons.
4.1 Slow-Start Stage
During the slow-start stage, MPTCP schedules the data in the
redundant mode, where the same data are transmitted across multiple
paths. After each round, we get a measured throughput from the view
of MP layer, where the round time could be from sending a packet
until receiving its responsive ACK. The throughput (defined as
`B_rd') is calculated by dividing the total number of delivered data
with the time period of this round. We define a threshold `h', where
h belongs to (0,1), e.g. h=0.2. As shown in Figure 2, if the measured
throughput is h times larger than the last measured value (i.e.
B_rd(i) >= h * B_rd(i-1) ) , keep the redundant mode and set the
round counter Nr as 0, or else increase the round counter (defined as
Nr) by 1.
J. Zuo, et al Expires April 29, 2018 [Page 5]
INTERNET-DRAFT October 30, 2017
4.2 Congestion-Avoidance Stage
If the round counter Nr > N (e.g. N = 3), then the transmission
switches to the congestion-avoidance stage, as shown in Figure 2. Two
timers are set to decide when we need measure the throughputs of the
redundant and MP modes again. Two indicators of updating the
redundant and MP measurement values, Indicator_Redundant and
Indicator_MP, are both set as 1. The indicator timers for the
redundant mode and MP modes are set as REDUNDANT_MODE_TIMER and
MP_MODE_TIMER, separately. The timeout of both timers is set as a
period of time TIMEOUT (e.g. 10s).
At first, the redundant mode is used to measure the throughput.
+-------------------------------------+
| |
v +---------------------------+
Nr <= N | If B_rd(i)= h*B_rd(i-1) |
+----------------+ | Nr++; |
|Slow-Start Stage+--------------> | Else |
+----------------+ | Nr=0; |
Nr > N | +---------------------------+
|
+---------v----------------+
|Congestion-Avoidance Stage|
+--------------------------+
Figure 2: Stage transition from slow start to congestion avoidance.
4.2.1 Redundant Transmission Mode
As shown in Figure 3, when running the redundant mode, MP layer and
each path would calculate the average throughputs during a period of
time (e.g. 1s). Meanwhile, the timer REDUNDANT_MODE_TIMER is reset
and the variable Indicator_Redundant is set as 0. Before sending each
segment, if Indicator_MP = 1, the redundant mode is switched to the
MP mode to measure the throughput, as described in Section 4.2.2.
Otherwise, the two throughputs obtained from the redundant and MP
modes are compared, which is introduced in Section 4.2.3.
J. Zuo, et al Expires April 29, 2018 [Page 6]
INTERNET-DRAFT October 30, 2017
+--------------------------------+ +-------------------------+
| Redundant Mode | | MP Mode |
+--------------------------------+ +-------------------------+
| +-------------------+ | Indicator_MP = 1 | +-------------------+ |
| | after a period of| +-------------------------> | after a period of| |
| | time (e.g. 1s) | | | | time (e.g. 1s) | |
| +---------+---------+ | | +--------+----------+ |
| | <-------------------------+ | |
| +--------------v-------------+ | Indicator_Redundant = 1 | +---------v------------ |
| | Indicator_Redundant = 0; | | | | Indicator_MP = 0; | |
| | Reset REDUNDANT_MODE_TIMER | | | | Reset MP_MODE_TIMER | |
| +----------------------------+ | | +---------------------- |
| | | |
+--------+------+----------------+ +-----------+----^-----^--+
^ | | | |
| | +---------------------------------------+ | | |
| +--------> <-----+ | |
| | Comparison of the Measured Throughput | | |
| | +----------+ |
| +-------------------+-------------------+ select MP mode |
| | |
| select redundant mode | |
| +--------v--------+ |
| |transmit data | |
+--------------------------+in the best path +---------------------------+
Indicator_Redundant = 1 +-----------------+ Indicator_MP = 1
Figure 3: The redundant-and-MP mode transition when the corresponding indicator is equal to 1.
4.2.2 Multipath Transmission Mode
As shown in Figure 3, when running the MP mode, MP layer would
calculate its average throughput during a period of time (e.g. 1s).
Meanwhile, the timer MP_MODE_TIMER is reset and the variable
Indicator_MP is set as 0. Before sending each segment, if
Indicator_Redundant = 1, the MP mode is switched to the redundant
mode to measure the throughputs (refer to Section 4.2.1). Otherwise,
the two throughputs obtained from the redundant and MP modes are
compared (see Section 4.2.3).
4.2.3 Throughput Comparison
By comparing the throughputs measured by the redundant and MP modes,
a transmission mode corresponding to the larger throughput would be
selected.
If the redundant mode (described in Section 4.2.1) is selected, the
J. Zuo, et al Expires April 29, 2018 [Page 7]
INTERNET-DRAFT October 30, 2017
path with the highest throughput is employed for data transmission.
Before sending each segment, if Indicator_redundant = 1 or
Indicator_MP = 1, we will go back to the redundant mode or the MP
mode to measure the corresponding throughput(s). If both of the
indicators are 0, keep transmitting data at the best path.
If the MP mode (described in Section 4.2.2) is selected, the multiple
paths are bonded together to achieve the aggregated throughput.
4.2.4 Indicator Timer Timeout
During data transmission, if the timer for the redundant/MP mode is
timeout, set Indicator_Redundant/Indicator_MP = 1 and reset the timer
of the redundant/MP mode.
5. Security Considerations
TBD.
6. IANA Considerations
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC6356] Raiciu, C., Handly, M., and Wischikf, D., "Coupled
Congestion Control for Multipath Transport Protocols", RFC
6356, DOI 10.17487/RFC6356, October 2011, <https://rfc-
editor.org/rfc/rfc6356.txt>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and Bonaventure, O.,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., Iyengar, J.,
"Architectural Guidelines for Multipath TCP Development",
RFC 6182, DOI 10.17487/RFC6182, March 2011,
J. Zuo, et al Expires April 29, 2018 [Page 8]
INTERNET-DRAFT October 30, 2017
<http://www.rfc-editor.org/info/rfc6182>.
7.2. Informative References
[CMT-SCTP] Yang, W., Li, H., Li, F., Wu, Q., & Wu, J., "RPS: range-
based path selection method for concurrent multipath
transfer", June 2010, In Proceedings of the 6th
International Wireless Communications and Mobile Computing
Conference (pp. 944-948). ACM.
Author's Addresses
Fanzhao Wang
Huawei Technologies
Bantian, Longgang District,
Shenzhen 518129 P.R. China
EMail: wangfanzhao@huawei.com
Jing Zuo
Huawei Technologies
Bantian, Longgang District,
Shenzhen 518129 P.R. China
EMail: jing.zuo@huawei.com
Zhen Cao
Huawei Technologies
No.156 Beiqing Rd. Haidian District,
Beijing 100095 P.R. China
EMail: zhencao.ietf@gmail.com
Kai Zheng
Huawei Technologies
No.156 Beiqing Rd. Haidian District,
Beijing 100095 P.R. China
EMail: kai.zheng@huawei.com
J. Zuo, et al Expires April 29, 2018 [Page 9]
