MPTCP Fei Song Internet Draft Hongke Zhang Intended status: Informational Beijing Jiaotong University Expires: December 28, 2016 June 28, 2016 One Way Latency Considerations for MPTCP draft-song-mptcp-owl-00.txt Abstract This document discusses the One Way Latency (OWL) utilization for enhancing multipath TCP (MPTCP) transmission, which is a potential and beneficial technology in MPTCP Working Group (WG). Several representative usages of OWL, such as retransmission policy, crucial data scheduling, are analyzed. Two kinds of OWL measurement approaches are also provided and compared. We believe that more explorations related with OWL will be important for MPTCP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on December 28, 2016. Song, et al. Expires December 28, 2016 [Page 1] Internet-Draft One Way Latency Considerations June 2016 Copyright Notice Copyright (c) 2016 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 ................................................ 3 2. Terminology ................................................. 3 3. Potential Usages of OWL in MPTCP............................. 4 3.1. Retransmission Policy................................... 4 3.2. Crucial Data Scheduling................................. 4 3.3. Congestion Control Mechanism............................ 4 3.4. Bandwidth Estimation.................................... 4 3.5. Shared Bottleneck Detection............................. 5 4. The Classification of OWL Measurement........................ 5 5. Security Considerations...................................... 5 6. IANA Considerations ......................................... 6 7. References .................................................. 6 7.1. Normative References.................................... 6 7.2. Informative References.................................. 6 8. Acknowledgments ............................................. 6 Song, et al. Expires December 28, 2016 [Page 2] Internet-Draft One Way Latency Considerations June 2016 1. Introduction As the basic elements of Internet, both the intermediate devices and the end hosts have equipped more and more physical network interfaces. For the former, multiple interfaces had been widely used in packet forwarding, traffic engineering, etc. For the latter, the importance of these interfaces had been confirmed and utilized [RFC6419]. Moreover, the capacity of multiple paths created by multiple interfaces is leveraged to aggregate higher bandwidth, achieve lower delay and provide better services. Different with traditional TCP [RFC0793], many transport layer protocols enable the end hosts to concurrently transfer data on top of multiple paths and greatly increase the overall throughput, such as MPTCP [RFC6182][RFC6356]. However, we believe that the performance of current practices of MPTCP could be further improved by fully taking advantage of One Way Latency (OWL) during the transmission. In single path transfer mode, there is less benefits to achieve if one separates the OWL out of Round Trip Time (RTT) because there are no other available paths to choose. Motivated by previous facts, we suggest discussing the necessary considerations of OWL in MPTCP. The structure of this document is as follows: Firstly, possible usages of OWL in MPTCP are analyzed. Secondly, two kinds of OWL measurements are listed and compared. The consideration related with security and IANA are given at the end. The potential target readers of this document are application programmer whose products may significantly benefit from MPTCP. This document also provides the necessary information for the developers of MPTCP to implement the new version API into the TCP/IP network stack. 2. 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]. The document makes extensive use of the terminology and definitions inherited from Architectural Guidelines for Multipath TCP Development [RFC6182] and TCP Extensions for Multipath Operation with Multiple Addresses [RFC6824]. Song, et al. Expires December 28, 2016 [Page 3] Internet-Draft One Way Latency Considerations June 2016 3. Potential Usages of OWL in MPTCP There are several potential usages of OWL when MPTCP is enabled by the sender and receiver. Although only five significant aspects are illustrated in this document, more explorations in this direction are still needed. 3.1. Retransmission Policy When packet is identified by triple duplicated acknowledgements or timeout, the sender needs to select a suitable path for retransmission. Due to the popular mechanisms of sequence control in reliable transport protocols, outstanding packets on multiple paths may reach to the destination disorderly and trigger Receive Buffer Blocking (RBB) problem, which will further affect the transmission performance. By using the results of OWL measurement, the sender could quickly determine the specific path with minimum forward latency. RBB could be relieved as soon as the receiver obtains the most needed packet(s) and submits them all to the upper layer. 3.2. Crucial Data Scheduling During the transmission process, there are always some crucial data need to be sent to the destination immediately. For example, the key frame of multimedia, high priority chunk of emergency communication, etc. One can not guarantee the arriving sequence if only RTTs of multiple paths are utilized. By using the results of OWL measurement, the sender could easily select the fast path, in terms of forward latency, for crucial data transmission. Moreover, the acknowledgements of these crucial data could be sent on the path with minimum reverse latency. Piggyback is also useful when duplex communication mode is adopted. 3.3. Congestion Control Mechanism Current version of MPTCP includes different kinds of congestion control mechanisms. By reasonably utilizing OWL, the network congestion situation of single direction could be better described. More information needs to be added. 3.4. Bandwidth Estimation Understanding the bandwidth condition is beneficial for data packet scheduling, load balancing, etc. OWL could be integrated with Song, et al. Expires December 28, 2016 [Page 4] Internet-Draft One Way Latency Considerations June 2016 bandwidth estimation approaches without interrupting the regular packets sending. More information needs to be added. 3.5. Shared Bottleneck Detection Fairness is critical especially when MPTCP and ordinary TCP coexist at the same network. The sender could treat OWL measurements as the sample process of shared bottleneck detection and accordingly adjust the volume of data packet on multiple paths. More information needs to be added. 4. The Classification of OWL Measurement Two kinds of OWL measurement approaches are available in current network: absolute value and relative value. For the absolute value of OWL, the primary condition of measurement is clock synchronization. By using Network Time Protocol (NTP) [RFC5905], end hosts can unify the local time with remote NTP server. The additional information or optional capabilities can be even added via extension fields in standard NTP header [RFC7822]. The calibration accuracy could reach to millisecond level in less congested situation. Obvious burden is to persuade the end hosts to initial NTP option. For the relative value of OWL, in some circumstance, it is more than enough to establish applications on top of it. For example, when retransmission is required, the sender just cares about which path has minimum forward latency. When bandwidth is being estimated, the difference of forward latency (i.e. delta latency) among all available paths is needed. By exchanging the local receiving and sending timestamps with corresponding end host, both sides could obtain the relative value of OWL. The matrix operations and algorithm could accelerate the calculation process. The concerns of the former one are extra protocol requirement and synchronization accuracy. However, it is more convenient for its applications. On the contrary, the latter one only needs to add timestamps into original protocol stack and does not need to worry about the accuracy. 5. Security Considerations This document does not contain any security considerations. However, future applications of OWL in MPTCP will definitely need to establish relevant mechanisms for security improvement. Song, et al. Expires December 28, 2016 [Page 5] Internet-Draft One Way Latency Considerations June 2016 6. IANA Considerations There are presently no IANA considerations with this document. 7. References 7.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [RFC6419] Wasserman, M. and P. Seite, "Current Practices for Multiple-Interface Hosts", RFC 6419, November 2011. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011. [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, October 2011. [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 (NTPv4) Extension Fields", RFC 7822, March 2016. 8. Acknowledgments Many thanks to the reviews of this document for their valuable feedbacks and comments. Song, et al. Expires December 28, 2016 [Page 6] Internet-Draft One Way Latency Considerations June 2016 Authors' Addresses Fei Song Beijing Jiaotong University (BJTU) Beijing, 100044, P. R. China Email: fsong@bjtu.edu.cn Hongke Zhang Beijing Jiaotong University (BJTU) Beijing, 100044, P. R. China Email: hkzhang@bjtu.edu.cn Song, et al. Expires December 28, 2016 [Page 7]