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, . [RFC6356] Raiciu, C., Handly, M., and Wischikf, D., "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, . [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, . [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 . 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]