idnits 2.17.1 draft-zhang-virtual-multi-path-tcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6824], [RFC6182]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 30, 2016) is 2703 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multipath TCP Working Group K. Xu 3 Internet-Draft Y. Zhang 4 Intended status: Informational Tsinghua University 5 Expires: June 3, 2017 M. Shen 6 Beijing Institute of Technology 7 Z. Ge 8 X. Wang 9 Tsinghua University 10 November 30, 2016 12 Efficient Transmission in Virtual Multi-path TCP 13 draft-zhang-virtual-multi-path-tcp-00 15 Abstract 17 Traditional MPTCP [RFC6824] requires that at least one node in a pair 18 should equipped more than one NIC, and this limits the deployment 19 [RFC6182] of MPTCP. This document proposes the VMPTCP (Virtual 20 Multi-Path TCP) and describes how to build TCP sub-connections in 21 VMPTCP among nodes with just one NIC. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 3, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. An application of VMPTCP in wireless LAN . . . . . . . . . . 4 60 3.1. Sub-connection 1: The first connection . . . . . . . . . 4 61 3.2. Sub-connection 2 and 3: The joint connection . . . . . . 5 62 3.3. Merge flows from multiple sub-connections together . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 5. Dynamics Considerations . . . . . . . . . . . . . . . . . . . 5 65 5.1. Node failure . . . . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 7.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 There are multiple pathes in Multi-path TCP [RFC6824]. To build more 75 than one TCP sub-connections, MPTCP requires at least one node in the 76 communication peer should be equipped with more than one NIC. 78 [RFC6356] describes the use of MPTCP for congestion control, 79 [RFC6181] and [RFC6824] describe the TCP extensions for multipath 80 operation with multiple addresses. The TCP connections, SYN and ACK 81 messages, and the session key are carried in TCP. 83 However, this imposes restrictions on the deployment of MPTCP: 85 o A node eqiupped with just one NIC cannot benifit from MPTCP, and 86 it is expensive to embed extra NICs to network elments 88 o MPTCP works as a one-to-one manner 90 o The I/O resources on the NIC are reserved for a particular 91 transmission. This results in less efficient bandwidth usage 93 This document describes how to build virtualized TCP sub-connections 94 among multiple single-NIC network elements. The main advantages of 95 using VMPTCP in traditional network environment are as follows: 97 o No inherent restrictions on the nodes, and every node (even with 98 one single NIC) can adopt VMPTCP to accelerate its processing 100 o No modification on the state-of-the-art commercial devices or 101 network architecture 103 o It allows more than two participants in one VMPTCP connection, so 104 more efficient I/O usage is possible 106 o Faster data transmission, more flexible connection establishment 107 and better user experience through higher throughput 109 o High resilience to network failure 111 Taking these interface limitations into consideration like [RFC6879], 112 [RFC6181] and [RFC7430] post the threat analysis and possible 113 fixesfor multipath TCP. 115 Note that the virtual multipath TCP has no extra requirements on 116 specific communication peers, network elements with just one NIC can 117 also benifit from multipath. The data transmission and connection 118 establishment are not limited to two peers any more, and multiple 119 nodes can participate in one VMPTCP. This makes high resource 120 utilization on each node and improves application performance. 122 The architecture which is described in this document can be 123 implemented without any modifications on the state-of-the-art 124 commercial devices or network architecture. For a single-path TCP 125 connection between two single-NIC communication peers, if the 126 transmission on this link cannot satisfy application requirements, 127 VMPTCP allows other peers to join in. VMPTCP builds TCP sub- 128 connections between the destination nodes and the newcome nodes, and 129 these sub-connections would serve for applications together with the 130 origin connection. 132 2. Terminology 134 Terminology defined in [RFC6181] and [RFC6824] is used extensively 135 throughout this document. 137 Virtual TCP sub-connection: As there are more than one source for a 138 particular data transmission, multiple source-destination address 139 pairs coexist, and there is one connection between each source- 140 destination pair. Each connection is a sub-connection and is 141 responsible to transfer part of the required data. 143 3. An application of VMPTCP in wireless LAN 145 As shown in Figure 1, the wireless LAN consists of five nodes : Host 146 1, Host 2, Host 3, Destination and AP (Access Point). Note that 147 these nodes are not necessarily required to be equipped with more 148 than one NIC. One existing example is that when the destination node 149 wants to download a data replica, the AP assign data sources for this 150 download action according to VMPTCP. The advantages of VMPTCP is the 151 multiple optional sources, and the connections establish process is 152 also described below. 154 ________ _________ __________ 155 | | | | | | 156 | Host 1 | | Host 2 | | Host 3 | 157 |________| |_________| |__________| 158 \ | / 159 sub-connection 2 \ 1| / 160 \ | / 3 161 \ v / 162 / \ 163 / \ 164 / AP \ 165 /_______\ 166 | 167 | 168 _____v_____Merge all Flows together 169 | | 170 |Destination| 171 |___________| 173 The numbers corresponding to each of the flows are described in more 174 detail below. 176 Figure 1: VMPTCP with Multiple Sources 178 3.1. Sub-connection 1: The first connection 180 This is the main connection that is established between two hosts by 181 IP address and port. 183 The establishment of this link should go through TCP three-way 184 handshake and the 64-bit session key exchange. In the TCP segment, 185 MPTCP uses MP_CAPABLE MP_JOIN and some other subtype fields under the 186 "MPTCP Option Subtypes" [RFC6824]. Then Host 2 and the destination 187 node generate a shared 32-bit hash key, thus, the two nodes have 188 received an acknowledgement of this connection. 190 Note that Host 2 just has one NIC, so it cannot establish extra 191 pathes using MPTCP. 193 3.2. Sub-connection 2 and 3: The joint connection 195 In the traditional potocols, this download action can only be 196 executed between Host 2 and the destination node. Although there are 197 extra I/O resources in the peers, MPTCP cannot work here due to the 198 NIC limitation. 200 To fully use the I/O and bandwidth resources, VMPTCP allows other 201 hosts to join in the transmission. Note that Host 1 (or 3) has a 202 different IP and mac from Host 2. 204 The sub-connection between Host 1 (or 3) still use TCP SYN segment in 205 MPTCP potocol to generate traffic. It obtains that shared 32-bit 206 hash key from AP and write it to the MP_JOIN segment, making it 207 associated with the origin connection (sub-connection 1). 209 3.3. Merge flows from multiple sub-connections together 211 Once connection establishments are successfully completed, data 212 transmission traffic would be auto adjusted among these sub- 213 connections. Each sub-connection between host peers acts as one flow 214 in MPTCP, and each source node (Host 1, 2, 3) acts as one NIC in the 215 source node in the traditional MPTCP concept. 217 There is a data sequence number and an acknowledment number in MPTCP 218 [RFC6824] option field, so the destinition node can keep the received 219 data in the original order and revert to the origin data. 221 4. Security Considerations 223 Security considerations in [RFC6824] are also relevant here. 225 As the connection establihment process in VMPTCP is the same as that 226 in traditional MPTCP, each host should provide the secret key to join 227 the multiplath transmission. 229 In some cases, some malicious nodes would try to join the multipath 230 transmission, so the AP in VMPTCP should deploy encryption algorithm 231 to make node identification before sending the encrypted 232 communication key to the node. 234 5. Dynamics Considerations 236 Dynymic considerations in [RFC6824] are also relevant here. The 237 traffic on these multiple sub-connections can be adjusted adaptively 238 according to the MPTCP. 240 5.1. Node failure 242 In some wireless situations, nodes could move out of the 243 communication range, breaking the connection. In this case, the AP 244 would recalculate the residual completion time of that transmission, 245 if the completion time exceeds the transmission deadline and there is 246 still unused resources on the destination node, the AP will assign 247 other source nodes to this download action. 249 In sparticular, the newly assigned source-destination peer would join 250 in the VMPTCP by establishing a new sub-connection. This process 251 follows the above "joint connection" procedure. 253 The dynamic model that is described in this document brings an 254 additional calculation requirement to AP: It should maintain state 255 information for all established connections. This is an extra 256 overheard than traditional MPTCP, but ensures the high transmission 257 efficiency. 259 6. IANA Considerations 261 This document does not include an IANA request. 263 7. References 265 7.1. Normative References 267 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 268 Congestion Control for Multipath Transport Protocols", 269 RFC 6356, DOI 10.17487/RFC6356, October 2011, 270 . 272 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 273 "TCP Extensions for Multipath Operation with Multiple 274 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 275 . 277 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 278 Network Renumbering Scenarios, Considerations, and 279 Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013, 280 . 282 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 283 Raiciu, "Analysis of Residual Threats and Possible Fixes 284 for Multipath TCP (MPTCP)", RFC 7430, 285 DOI 10.17487/RFC7430, July 2015, 286 . 288 7.2. Informative References 290 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 291 Multipath Operation with Multiple Addresses", RFC 6181, 292 DOI 10.17487/RFC6181, March 2011, 293 . 295 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 296 Iyengar, "Architectural Guidelines for Multipath TCP 297 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 298 . 300 Authors' Addresses 302 Ke Xu 303 Tsinghua University 304 Department of Computer Science, Tsinghua University 305 Beijing 100084 306 P.R.China 308 Phone: +86-13001081658 309 Email: xuke@mail.tsinghua.edu.cn 311 Yuchao Zhang 312 Tsinghua University 313 Department of Computer Science, Tsinghua University 314 Beijing 100084 315 P.R.China 317 Phone: +86-18630500826 318 Email: zhangyc14@mails.tsinghua.edu.cn 320 Meng Shen 321 Beijing Institute of Technology 322 Department of Computer Science 323 Beijing 100084 324 P.R.China 326 Phone: +86-15210362001 327 Email: shenmeng@bit.edu.cn 328 Zhicheng Ge 329 Tsinghua University 330 Department of Computer Science, Tsinghua University 331 Beijing 100084 332 P.R.China 334 Phone: +86-18810543121 335 Email: gzc15@mails.tsinghua.edu.cn 337 Xiangxiang Wanf 338 Tsinghua University 339 Department of Computer Science, Tsinghua University 340 Beijing 100084 341 P.R.China 343 Phone: +86-18522247311 344 Email: wxx15@mails.tsinghua.edu.cn