MPTCP J. Zhu Internet Draft W. Liu Intended status: Informational J. Zuo Expires: September 6, 2018 Huawei March 5, 2018 A Path-aware Scheduling Scheme for Multipath Transport Protocols draft-zuo-mptcp-scheduler-00.txt Abstract The design of scheduling data amongst multiple asynchronous paths impacts the performance of multipath transport protocols. This draft proposes a path-aware scheduling scheme, which adaptively selects the most suitable scheduling scheme according to the path characteristics in a time-variant multipath transport scenario. When the path characteristics are unknown, the redundant mode is employed to achieve at least as good performance as that of the best single path. The condition for choosing the most suitable scheduling mode relies on the measured path characteristics and the application requirements. Especially, the path-aware scheduling scheme is designed in this draft in terms of of the delay difference of multiple paths, compared with a pre-defined delay threshold. 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 September 6, 2018 [Page 1] INTERNET-DRAFT MPTCP Scheduler March 5, 2018 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 New Path-Aware Scheduling Scheme . . . . . . . . . . . . . . 3 3.1. The Redundant/Non-Redundant modes . . . . . . . . . . . . . 4 3.2. The Mode-Selecting Condition . . . . . . . . . . . . . . . 4 3.3. The Path Characteristics Measurement . . . . . . . . . . . 4 4. Implementation Considerations . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction A suitable scheduling mode will influence the performance of multiple transport protocols[RFC6824] due to the asynchronous path characteristics. When the delays of the multiple paths differ, the packets with consecutive sequence number will arrive at the receiver at different time, causing the out-of-order problem. Some pre- scheduled schemes are proposed to pre-schedule the sending time of each packet ensuring they are delivered in order. Some other scheduling solutions are trying to re-inject the data in flight from the slow subflow to the fast subflow and reduce the cwnd size of the slow subflow[OppRetr]. However, all these methods require the knowledge of the accurate path characteristics. If the path characteristics are unknown, the scheduling schemes are arbitrary, while if the network environment varies violently, the scheduling schemes can not respond to the variant network in time and may become invalid. J. Zuo, et al Expires September 6, 2018 [Page 2] INTERNET-DRAFT MPTCP Scheduler March 5, 2018 The redundant scheduling mode[MPTCP.org] is useful if the latency is the primary goal, which will try to transmit the traffic on all available subflows in a redundant way no matter what the path characteristics is. However, it achieves the low latency by sacrificing the bandwidth. The min_RTT scheduling mode is the best known up to today, which will always first send data on the subflow with the lowest RTT until the cwnd is full. However, it depends on the accurate path characteristics measurement. If there is no data sent on one of the subflows, it can not get the subflow's current path characteristics. Therefore, a new path-aware scheduling scheme for multiple transport protocols is proposed to adaptively select the suitable scheduling mode according to the path characteristics. Specifically, if the characteristics of all paths are unknown, the redundant mode is the appropriate method to send data in all paths concurrently. Meanwhile, the path characteristics are measured during the redundant transmission in all the paths. Once the path characteristics are obtained, the scheduling mode is adaptively selected according to the measured path characteristics and the application requirements. This draft also defines the scheduling thresholds to judge the suitable scheduling mode at a certain scenario. The thresholds could be defined as the delay difference, the rate, etc., where their value could be decided by the experience or given by the applications requirements. It is intended that the scheduling scheme presented in this draft can be applied to other multipath transport protocols, such as alternative multipath extensions to TCP[RFC793], UDP, QUIC, or indeed any other multipath protocols. However, for the purposes of example, this document will, where appropriate, refer to the MPTCP[RFC6182]. 2. Acronyms and Terminology 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 New Path-Aware Scheduling Scheme The new path-aware scheduling scheme adaptively selects the most suitable scheduling mode according to the measured path characteristics compared with a pre-defined threshold. The redundant mode is employed when the path characteristics are unknown. In this draft, we take the latency-sensitive traffic as an example, which considers the delay difference as the mode-selecting condition. J. Zuo, et al Expires September 6, 2018 [Page 3] INTERNET-DRAFT MPTCP Scheduler March 5, 2018 3.1. The Redundant/Non-Redundant modes Two modes are defined: 1) The redundant mode sends the same data in all paths concurrently; 2)The non-redundant mode sends data in min_RTT mode or just the best single path. 3.2. The Mode-Selecting Condition For latency-sensitive traffic, the delay is the most important factor to make a scheduling decision. Hence, a delay difference is defined as the mode-selecting condition. Due to the asynchronous path characteristics, the RTT can not really reflect the delay of the data delivered to the receiver, the one-way-latency[OWL] is suggested as the condition, where the receiver calculates the delay with the arriving time and its corresponding sending time, shown as one-way latency (i) = receiving time (i) - sending time (i) . The one-way latency is fed back to the sender carried in the one-way latency (MP_OWL) Option, then the sender can calculate the delay difference, as delay difference (i) = |one-way latency (i) - one-way latency (j)|. According to the application requirements, a threshold is pre- configured and used to compare with the measured delay difference. When the delay difference is less than the threshold, the redundant mode is employed, otherwise the non-redundant mode is used. For example, when the non-redundant mode is selected, the path with the lowest one-way latency is used to send data. If the delay difference changes until that it is larger than the threshold, then the non- redundant mode switches back to the redundant mode. 3.3. The Path Characteristics Measurement As described above, the one-way latency is calculated at the receiver and fed back to the sender in the option of the acknowledgement packet, while the delay difference is calculated at the sender. If no data is scheduled in a certain path for a long time, it can not get the one-way latency in time, and the scheduling mode may become invalid. The phenomenon of no data scheduled in a certain path usually happens when the delay difference of the multiple paths is large while with limited receive buffer. It also happens when the application traffic generates in burst intermittently. During the initialization stage, the path characteristics are unknown, hence the redundant mode is used to measure the one-way J. Zuo, et al Expires September 6, 2018 [Page 4] INTERNET-DRAFT MPTCP Scheduler March 5, 2018 latency. Afterwards, if the selected scheduling mode only sends data in a certain path according to the measured delay difference, two alternative methods are designed to make the sender obtain the one- way latency of the other path, which are 1) Periodically switch to the redundant mode, which transmits the same data in all paths and measure the one-way latency; 2) Periodically send a signalling packet in the other path to measure the one-way latency, which reduce the network overhead compared to the method 1. 4. Implementation Considerations As described in Section 3.2, the delay difference is calculated according to the one-way latency of multiple paths. The one-way latency is carried in a new defined option, the one-way latency (MP_OWL) Option, and sent back to the sender. The format is shown as follows, where the value of the Subtype could be defined as '0x8'. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+----------------------+ | Kind | Length |Subtype| (reserved) | +---------------+---------------+-------+----------------------+ | One-way latency(4/8 octets, depending on flags) | +--------------------------------------------------------------+ Figure 1: One-way Latency (MP_OWL) Option 5. Security Considerations TBD. 7. Acknowledgements 8. References 8.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, . 8.2. Informative References [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC793, DOI 10.17487/RFC0793, September 1981, . [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, . [MPTCP.org] Multipath TCP - Linux Kernel Implementation, . [OppRetr] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O. and Handley, M., "How hard can it be? designing and implementing a deployable multipath TCP", April 2012, In Proceedings of the 9th USENIX conference on Networked Systems Design and Implementation (pp. 29-29). Author's Addresses Jianjian Zhu Huawei Technologies Bantian, Longgang District, Shenzhen 518129 P.R. China EMail: zhujianjian1@huawei.com Wei Liu Huawei Technologies Bantian, Longgang District, Shenzhen 518129 P.R. China EMail: liuwei57@huawei.com Jing Zuo Huawei Technologies Bantian, Longgang District, Shenzhen 518129 P.R. China EMail: jing.zuo@huawei.com J. Zuo, et al Expires September 6, 2018 [Page 6]