Multipath TCP Working Group K. Xu Internet-Draft Y. Zhang Intended status: Informational Tsinghua University Expires: June 3, 2017 M. Shen Beijing Institute of Technology Z. Ge X. Wang Tsinghua University November 30, 2016 Efficient Transmission in Virtual Multi-path TCP draft-zhang-virtual-multi-path-tcp-00 Abstract Traditional MPTCP [RFC6824] requires that at least one node in a pair should equipped more than one NIC, and this limits the deployment [RFC6182] of MPTCP. This document proposes the VMPTCP (Virtual Multi-Path TCP) and describes how to build TCP sub-connections in VMPTCP among nodes with just one NIC. 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 June 3, 2017. 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 Xu, et al. Expires June 3, 2017 [Page 1] Internet-Draft virtual multi-path TCP November 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. An application of VMPTCP in wireless LAN . . . . . . . . . . 4 3.1. Sub-connection 1: The first connection . . . . . . . . . 4 3.2. Sub-connection 2 and 3: The joint connection . . . . . . 5 3.3. Merge flows from multiple sub-connections together . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Dynamics Considerations . . . . . . . . . . . . . . . . . . . 5 5.1. Node failure . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction There are multiple pathes in Multi-path TCP [RFC6824]. To build more than one TCP sub-connections, MPTCP requires at least one node in the communication peer should be equipped with more than one NIC. [RFC6356] describes the use of MPTCP for congestion control, [RFC6181] and [RFC6824] describe the TCP extensions for multipath operation with multiple addresses. The TCP connections, SYN and ACK messages, and the session key are carried in TCP. However, this imposes restrictions on the deployment of MPTCP: o A node eqiupped with just one NIC cannot benifit from MPTCP, and it is expensive to embed extra NICs to network elments o MPTCP works as a one-to-one manner o The I/O resources on the NIC are reserved for a particular transmission. This results in less efficient bandwidth usage This document describes how to build virtualized TCP sub-connections among multiple single-NIC network elements. The main advantages of using VMPTCP in traditional network environment are as follows: Xu, et al. Expires June 3, 2017 [Page 2] Internet-Draft virtual multi-path TCP November 2016 o No inherent restrictions on the nodes, and every node (even with one single NIC) can adopt VMPTCP to accelerate its processing o No modification on the state-of-the-art commercial devices or network architecture o It allows more than two participants in one VMPTCP connection, so more efficient I/O usage is possible o Faster data transmission, more flexible connection establishment and better user experience through higher throughput o High resilience to network failure Taking these interface limitations into consideration like [RFC6879], [RFC6181] and [RFC7430] post the threat analysis and possible fixesfor multipath TCP. Note that the virtual multipath TCP has no extra requirements on specific communication peers, network elements with just one NIC can also benifit from multipath. The data transmission and connection establishment are not limited to two peers any more, and multiple nodes can participate in one VMPTCP. This makes high resource utilization on each node and improves application performance. The architecture which is described in this document can be implemented without any modifications on the state-of-the-art commercial devices or network architecture. For a single-path TCP connection between two single-NIC communication peers, if the transmission on this link cannot satisfy application requirements, VMPTCP allows other peers to join in. VMPTCP builds TCP sub- connections between the destination nodes and the newcome nodes, and these sub-connections would serve for applications together with the origin connection. 2. Terminology Terminology defined in [RFC6181] and [RFC6824] is used extensively throughout this document. Virtual TCP sub-connection: As there are more than one source for a particular data transmission, multiple source-destination address pairs coexist, and there is one connection between each source- destination pair. Each connection is a sub-connection and is responsible to transfer part of the required data. Xu, et al. Expires June 3, 2017 [Page 3] Internet-Draft virtual multi-path TCP November 2016 3. An application of VMPTCP in wireless LAN As shown in Figure 1, the wireless LAN consists of five nodes : Host 1, Host 2, Host 3, Destination and AP (Access Point). Note that these nodes are not necessarily required to be equipped with more than one NIC. One existing example is that when the destination node wants to download a data replica, the AP assign data sources for this download action according to VMPTCP. The advantages of VMPTCP is the multiple optional sources, and the connections establish process is also described below. ________ _________ __________ | | | | | | | Host 1 | | Host 2 | | Host 3 | |________| |_________| |__________| \ | / sub-connection 2 \ 1| / \ | / 3 \ v / / \ / \ / AP \ /_______\ | | _____v_____Merge all Flows together | | |Destination| |___________| The numbers corresponding to each of the flows are described in more detail below. Figure 1: VMPTCP with Multiple Sources 3.1. Sub-connection 1: The first connection This is the main connection that is established between two hosts by IP address and port. The establishment of this link should go through TCP three-way handshake and the 64-bit session key exchange. In the TCP segment, MPTCP uses MP_CAPABLE MP_JOIN and some other subtype fields under the "MPTCP Option Subtypes" [RFC6824]. Then Host 2 and the destination node generate a shared 32-bit hash key, thus, the two nodes have received an acknowledgement of this connection. Note that Host 2 just has one NIC, so it cannot establish extra Xu, et al. Expires June 3, 2017 [Page 4] Internet-Draft virtual multi-path TCP November 2016 pathes using MPTCP. 3.2. Sub-connection 2 and 3: The joint connection In the traditional potocols, this download action can only be executed between Host 2 and the destination node. Although there are extra I/O resources in the peers, MPTCP cannot work here due to the NIC limitation. To fully use the I/O and bandwidth resources, VMPTCP allows other hosts to join in the transmission. Note that Host 1 (or 3) has a different IP and mac from Host 2. The sub-connection between Host 1 (or 3) still use TCP SYN segment in MPTCP potocol to generate traffic. It obtains that shared 32-bit hash key from AP and write it to the MP_JOIN segment, making it associated with the origin connection (sub-connection 1). 3.3. Merge flows from multiple sub-connections together Once connection establishments are successfully completed, data transmission traffic would be auto adjusted among these sub- connections. Each sub-connection between host peers acts as one flow in MPTCP, and each source node (Host 1, 2, 3) acts as one NIC in the source node in the traditional MPTCP concept. There is a data sequence number and an acknowledment number in MPTCP [RFC6824] option field, so the destinition node can keep the received data in the original order and revert to the origin data. 4. Security Considerations Security considerations in [RFC6824] are also relevant here. As the connection establihment process in VMPTCP is the same as that in traditional MPTCP, each host should provide the secret key to join the multiplath transmission. In some cases, some malicious nodes would try to join the multipath transmission, so the AP in VMPTCP should deploy encryption algorithm to make node identification before sending the encrypted communication key to the node. 5. Dynamics Considerations Dynymic considerations in [RFC6824] are also relevant here. The traffic on these multiple sub-connections can be adjusted adaptively according to the MPTCP. Xu, et al. Expires June 3, 2017 [Page 5] Internet-Draft virtual multi-path TCP November 2016 5.1. Node failure In some wireless situations, nodes could move out of the communication range, breaking the connection. In this case, the AP would recalculate the residual completion time of that transmission, if the completion time exceeds the transmission deadline and there is still unused resources on the destination node, the AP will assign other source nodes to this download action. In sparticular, the newly assigned source-destination peer would join in the VMPTCP by establishing a new sub-connection. This process follows the above "joint connection" procedure. The dynamic model that is described in this document brings an additional calculation requirement to AP: It should maintain state information for all established connections. This is an extra overheard than traditional MPTCP, but ensures the high transmission efficiency. 6. IANA Considerations This document does not include an IANA request. 7. References 7.1. Normative References [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, . [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. Raiciu, "Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/RFC7430, July 2015, . Xu, et al. Expires June 3, 2017 [Page 6] Internet-Draft virtual multi-path TCP November 2016 7.2. Informative References [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6181, DOI 10.17487/RFC6181, March 2011, . [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, . Authors' Addresses Ke Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-13001081658 Email: xuke@mail.tsinghua.edu.cn Yuchao Zhang Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-18630500826 Email: zhangyc14@mails.tsinghua.edu.cn Meng Shen Beijing Institute of Technology Department of Computer Science Beijing 100084 P.R.China Phone: +86-15210362001 Email: shenmeng@bit.edu.cn Xu, et al. Expires June 3, 2017 [Page 7] Internet-Draft virtual multi-path TCP November 2016 Zhicheng Ge Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-18810543121 Email: gzc15@mails.tsinghua.edu.cn Xiangxiang Wanf Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China Phone: +86-18522247311 Email: wxx15@mails.tsinghua.edu.cn Xu, et al. Expires June 3, 2017 [Page 8]