idnits 2.17.1 draft-amend-tcpm-mptcp-robe-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 : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 533: '...h available path SHOULD be characteriz...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 July 2020) is 1389 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 841, but not defined == Missing Reference: 'Tbd' is mentioned on line 1044, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions M. Amend 3 Internet-Draft DT 4 Intended status: Experimental J. Kang 5 Expires: 8 January 2021 Huawei 6 7 July 2020 8 Multipath TCP Extension for Robust Session Establishment 9 draft-amend-tcpm-mptcp-robe-00 11 Abstract 13 Multipath TCP extends the plain, single-path limited, TCP towards the 14 capability of multipath transmission. This greatly improves the 15 reliability and performance of TCP communication. For backwards 16 compatibility reasons the Multipath TCP was designed to setup 17 successfully an initial path first, after which subsequent paths can 18 be added for multipath transmission. For that reason the Multipath 19 TCP has the same limitations as the plain TCP during connection 20 setup, in case the selected path is not functional. 22 This document proposes a set of implementations and possible 23 combinations thereof, that provide a more Robust Establishment (RobE) 24 of MPTCP sessions. It includes RobE_TIMER, RobE_SIM, RobE_eSIM and 25 RobE_IPS. 27 RobE_TIMER is designed to stay close to MPTCP in that standard 28 functionality is used wherever possible. Resiliency against network 29 outages is achieved by modifying the SYN retransmission timer: If one 30 path is defective, another path is used. 32 RobE_SIM and RobE_eSIM provides the ability to simultaneously use 33 multiple paths for connection setup. They ensure connectivity if at 34 least one functional path out of a bunch of paths is given and offers 35 beside that the opportunity to significantly improve loading times of 36 Internet services. 38 RobE_IPS provides a heuristic to select properly an initial path for 39 connection establishment with a remote host based on empirical data 40 derived from previous connection information. 42 In practice, these independent solutions can be complementary used. 43 This document also presents the design and protocol procedure for 44 those combinations in addition to the respective stand-alone 45 solutions. 47 Status of This Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at https://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on 8 January 2021. 64 Copyright Notice 66 Copyright (c) 2020 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 71 license-info) in effect on the date of publication of this document. 72 Please review these documents carefully, as they describe your rights 73 and restrictions with respect to this document. Code Components 74 extracted from this document must include Simplified BSD License text 75 as described in Section 4.e of the Trust Legal Provisions and are 76 provided without warranty as described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 82 2. Implementation without MPTCP protocol adaptation . . . . . . 7 83 2.1. Re-transmission Timer(RobE_TIMER) . . . . . . . . . . . . 7 84 2.2. Simultaneous Initial Paths Simple Version (RobE_SIM) . . 8 85 2.3. Heuristic Initial Path Selection (RobE_IPS) . . . . . . . 9 86 2.3.1. Architecture . . . . . . . . . . . . . . . . . . . . 9 87 2.3.2. Typical Scenarios . . . . . . . . . . . . . . . . . . 10 88 2.3.3. Path decision information . . . . . . . . . . . . . . 13 89 2.3.4. Initial Path Selection use local RTT information . . 14 90 2.4. Combination of RobE_SIM and RobE_IPS . . . . . . . . . . 14 91 2.5. Combination of RobE_TIMER and RobE_IPS . . . . . . . . . 15 92 3. Implementation with Bi-directional MPTCP Support . . . . . . 16 93 3.1. Simultaneous Initial Paths Extended Version 94 (RobE_eSIM) . . . . . . . . . . . . . . . . . . . . . . . 17 96 3.1.1. RobE_eSIM implicit Negotiation and Procedure . . . . 17 97 3.1.2. RobE_eSIM explicit Negotiation and Procedure . . . . 19 98 3.1.3. Protocol Adaptation . . . . . . . . . . . . . . . . . 19 99 3.1.4. Fallback Mechanisms . . . . . . . . . . . . . . . . . 20 100 3.1.5. Comparison Robe_SIM and RobE_eSIM . . . . . . . . . . 22 101 3.1.6. Security Consideration . . . . . . . . . . . . . . . 23 102 3.2. Heuristic Initial Path Selection with remote RTT 103 Measurement . . . . . . . . . . . . . . . . . . . . . . . 23 104 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 24 105 3.2.2. Protocol Adaptation . . . . . . . . . . . . . . . . . 24 106 3.2.3. Fallback Mechanism . . . . . . . . . . . . . . . . . 25 107 3.2.4. Security Consideration . . . . . . . . . . . . . . . 25 108 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 109 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 110 5.1. Normative References . . . . . . . . . . . . . . . . . . 26 111 5.2. Informative References . . . . . . . . . . . . . . . . . 26 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 114 1. Introduction 116 Multipath TCP Robust Session Establishment (MPTCP RobE) is a set of 117 extensions to regular MPTCP [RFC6824] and its next version [RFC8684], 118 which releases single path limitations during the initial connection 119 setup. Several scenarios require and benefit from a reliable and in 120 time connection setup which is not covered by [RFC6824] and [RFC8684] 121 so far. MPTCP was designed to be compliant with the TCP standard 122 [RFC0793] and introduced therefore the concept of an initial TCP flow 123 while adding subsequent flows after successful multipath negotiation 124 on the initial path. While fulfilling its purpose, MPTCP is however 125 fully dependent on the transmission characteristics of the 126 communication link selected for initiating MPTCP. 128 Figure 1 shows the traditional way of MPTCP handshaking with a 129 MP_CAPABLE exchanged first, followed when successful negotiated by 130 additional flows engaging MP_JOIN. [RFC6824] and the next MPTCP 131 [RFC8684] differ in that a Key-A is sent with the first MP_CAPABLE or 132 not. 134 Host A Host B 135 ------------------------ ---------- 136 Address A1 Address A2 Address B1 137 ---------- ---------- ---------- 138 | | | 139 | SYN + MP_CAPABLE(Key-A[*]) | 140 |--------------------------------------------->| 141 |<---------------------------------------------| 142 | SYN/ACK + MP_CAPABLE(Key-B) | 143 | | | 144 | ACK + MP_CAPABLE(Key-A, Key-B) | 145 |--------------------------------------------->| 146 | | | 147 | | SYN + MP_JOIN(Token-B, R-A) | 148 | |------------------------------->| 149 | |<-------------------------------| 150 | | SYN/ACK + MP_JOIN(HMAC-B, R-B) | 151 | | | 152 | | ACK + MP_JOIN(HMAC-A) | 153 | |------------------------------->| 154 | |<-------------------------------| 155 | | ACK | 157 [*] Key-A in the first MP-capable is related to 158 RFC6824 only and does not exist in RFC8684. 160 Figure 1: MPTCP connection setup 162 Multipath TCP itself enables hosts to exchange packets belonging to a 163 single connection over several paths. Implemented in mobile phones 164 (UEs), these paths are usually assigned to different network 165 interfaces within the UE and corresponds to different networks such 166 as cellular and WiFi. The path or network interface for initiating 167 the initial subflow setup is most often provided by the operation 168 system of the UE. For example, if a cellular connection and WiFi are 169 present in a mobile phone, WiFi is usually the interface offered to 170 initiate the MPTCP session. 172 This design falls short in situations where the default path does not 173 provide the best performance compared to other available paths. In a 174 worst case the default path is not even capable of setting up the 175 initial flow letting any other functional path unused. For example, 176 if the WiFi signal is weak, broken or cannot forward traffic to the 177 destination, the establishment of the subflow will be delayed or 178 impossible. This in turn, leads to a longer startup delay or no 179 communication at all for services using MPTCP even if other 180 functional paths are available. Even in scenarios where all paths 181 are functional but services would benefit from a setup over the path 182 with the lowest latency, MPTCP has no mean to support this demand. 184 It can be concluded, that sequential path establishment relying with 185 an initial path establishment over an external given default route 186 will result in experience reduction when using MPTCP. So this 187 document proposes solutions to overcome the aforementioned 188 limitations and provides a more robust connection setup compared to 189 traditional MPTCP. 191 RobE_SIM and RobE_eSIM aims to overcome the limitations of [RFC6824] 192 and [RFC8684], using one initial flow and introduces the concept of 193 potential initial flows triggered simultaneously. Potential initial 194 flows gives the freedom to use more than one path to request 195 multipath capability and select the initial flow at a later point. 196 Potential initial flow mechanisms and the gain of robustness and 197 performance over the traditional MPTCP connection setup are evaluated 198 in [RobE_slides] and [RobE_paper]. RobE_SIM is a break-before-make 199 mechanism, guaranteeing at least the robust connection establishment, 200 however the RobE_eSIM reuses every potential initial flow request to 201 combine it with less overhead and accelerated multipath availability, 202 leveraging a new MPTCP option MP_JOIN_CAP. From a standardization 203 perspective, the RobE_SIM is fully compliant with [RFC6824] and 204 [RFC8684] and is herein more of a descriptive and procedural nature. 205 The RobE_eSIM requires a new MPTCP option but with the potential to 206 significantly improve the MPTCP experience. 208 For the limitation of the default initial path, RobE_IPS makes no 209 changes to standard MPTCP procedure and improves the performance of 210 connection establishment by introducing an initial path selection 211 strategy and required algorithms. The input for strategy and 212 algorithms is the transmission status information which represents 213 the transmission performance of each available path or network 214 interface. The transmission status information is characterized by 215 at least one of the parameters: signal strength, throughput, round- 216 trip time (RTT) and link success rate. In this way, a path with 217 better transmission performance can be learned and determined and the 218 respective network interface can be used for connection 219 establishment. 221 The most simple approach for a robust MPTCP session establishment is 222 RobE_TIMER, iterating the process of initial path establishment over 223 all available paths, if the previous try has failed. Triggering a 224 new try on a next path is depending on an expiration timer, 225 preferably re-use TCP's in-built expiration timer. 227 Table 1 summarizes the impact of RobE_TIMER, RobE_SIM, RobE_eSIM and 228 RobE_IPS compared to [RFC6824] and [RFC8684]. 230 +============+==========+=====================+==========+================+==========+ 231 | Scenario | MPTCP | RobE_TIMER | RobE_SIM | RobE_eSIM | RobE_IPS | 232 +============+==========+=====================+==========+================+==========+ 233 | IP packet | Delayed |In the scope of timer|No impact | No impact | Delayed | 234 | loss |connection| | | |connection| 235 +------------+----------+---------------------+----------+----------------+----------+ 236 | IP broken | No |In the scope of timer|No impact | No impact | No | 237 | |connection| | | |connection| 238 +------------+----------+---------------------+----------+----------------+----------+ 239 | IP setup | Default |Default route (+ path| Fastest | Fastest path | Selected | 240 | duration | route | 1..n) | path | | path | 241 | dependency | | | | | | 242 +------------+----------+---------------------+----------+----------------+----------+ 243 | MP |MP_CAPABLE|sum_1..n(MP_CAPABLE_n|MP_CAPABLE|max(MP_CAPABLE_1|MP_CAPABLE| 244 |availability| HS + | HS) + MP_JOIN HS | HS + |.. MP_CAPABLE_n | HS + | 245 | duration |MP_JOIN HS| |MP_JOIN HS| HS) |MP_JOIN HS| 246 +------------+----------+---------------------+----------+----------------+----------+ 247 |Guaranteeing|Depends on| Yes | Yes | Yes |Depends on| 248 | session | the | | | |selection | 249 | setup | default | | | | | 250 | | route | | | | | 251 +------------+----------+---------------------+----------+----------------+----------+ 253 Table 1: Overview RobE features during initial connection setup 255 | IP: Initial Path; MP: Multi-Path; HS: Handshake 257 1.1. Terminology 259 This document makes use of a number of terms that are either MPTCP- 260 specific or have defined meaning in the context of MPTCP, as follows: 262 Path: A sequence of links between a sender and a receiver, defined 263 in this context by a 4-tuple of source and destination address/ 264 port pairs. 266 Subflow: A flow of TCP segments operating over an individual path, 267 which forms part of a larger MPTCP connection. A subflow is 268 started and terminated similar to a regular TCP connection. 270 2. Implementation without MPTCP protocol adaptation 272 RobE_TIMER, RobE_SIM and RobE_IPS are compatible with the current 273 MPTCP protocol definitions in [RFC6824] and [RFC8684] but may be lack 274 of the full optimization potential which require protocol adaptation 275 in Section 3. Following sections will describe them in detail. 277 2.1. Re-transmission Timer(RobE_TIMER) 279 In RobE_TIMER, a new connection is initiated by sending a 280 SYN+MP_CAPABLE along the initial path. If this path is functional, 281 the solution will perform identical to classic MPTCP: the initial 282 flow will be established, and subsequent flows can be created 283 afterwards. If however the initial path is faulty, the 284 retransmission will be triggered on another path. This path might 285 circumvent the dysfunctional network, and allow the client to create 286 an initial subflow. The first path is now seen as a subsequent path 287 and the client sends SYN+MP_JOIN messages to create a subsequent 288 flow. 290 In high latency networks, the initial SYN+MP_CAPABLE might be delayed 291 until the client retries on another path. Once the second SYN 292 arrives at the server, it will try to complete the three-way 293 handshake. If the first SYN was delayed by more than the 294 retransmission time plus half a Round Trip Time (RTT) of the second 295 path, it will arrive at the server after the second SYN. The server 296 could now treat the segment as obsolete and drop it. 298 Host A Host B 299 ------------------------ ---------- 300 Address A1 Address A2 Address B1 301 ---------- ---------- ---------- 302 | | | 303 | SYN + MP_CAPABLE(Key-A[*]) | 304 |Timer---------------------------------------->| 305 | | SYN + MP_CAPABLE(Key-A'[*]) | 306 | |------------------------------->| 307 | | SYN/ACK+MP_CAPABLE(Key-B') | 308 | |<-------------------------------| 309 | | ACK + MP_CAPABLE(Key-A',Key-B')| 310 | |------------------------------->| 311 | | SYN + MP_JOIN(Token-B',R-A) | 312 |--------------------------------------------->| 313 | Subflow will be set up as normal MPTCP | 314 | | 316 [*] Key-A in the first MP-capable is related to 317 RFC6824 only and does not exist in RFC8684. 319 Figure 2: The Robe_TIMER Solution 321 Immediately after sending the final ACK of the initial handshake, 322 subflows are established on the remaining paths as defined in 323 [RFC6824] and [RFC8684] 325 [Notes: How to set the Timer is TBD. If there is the case that the 326 first SYN on default path arrives earlier than that from the second 327 path, the MPTCP connection will be initialized on the path of the 328 first SYN. The server could treat the second SYN as obsolete and 329 drop it.] 331 2.2. Simultaneous Initial Paths Simple Version (RobE_SIM) 333 RobE_SIM is a sender only implementation and no negotiation is 334 required. In RobE_SIM, the MPTCP connection setup benefits from the 335 fastest path. As shown in Figure 3, host A initiates the connection 336 handshake on more than one path independently (SA1 and SA2). The 337 paths selected for RobE_SIM and referred to as potential initial 338 flows, can belong to the number of interfaces on the device or a 339 subset selected on experience. When Host A receives the first SYN/ 340 ACK back from Host B (SA3), the path carrying this message is 341 identified as the normal initial path. Host A sends then immediately 342 a TCP RST message (SA6.1) on any other path used for simultaneous 343 connection setup causing an immediate termination of assigned flows 344 (break-before-make). The terminated ones are merged as subsequent 345 subflows following the JOIN procedure described in [RFC6824] and 346 [RFC8684]. The process is equivalent to any other scenario where the 347 SYN/ACK arrives on an other path than depicted in Figure 3. 349 Host A Host B 350 ------------------------ ---------- 351 Address A1 Address A2 Address B1 352 ---------- ---------- ---------- 353 | | | 354 | SYN + MP_CAPABLE(Key-A[*]) | 355 (SA1) |--------------------------------------------->| (SB1) 356 | | SYN + MP_CAPABLE(Key-A'[*]) | 357 (SA2) | |------------------------------->| (SB2) 358 | | | 359 (SA3) |<---------------------------------------------| (SB3) 360 | SYN/ACK + MP_CAPABLE(Key-B) | 361 (SA4) | |<-------------------------------| (SB4) 362 | | SYN/ACK + MP_CAPABLE(Key-B') | 363 | | | 364 | ACK + MP_CAPABLE(Key-A, Key-B) | 365 (SA5) |--------------------------------------------->| (SB5) 366 | | RST | 367 (SA6.1) | |------------------------------->| (SB6.1) 368 RobE SIM | | SYN + MP_JOIN(Token-B, R-A) | 369 (robust) | |------------------------------->| 370 | | MP_JOIN Process... | 372 [*] Key-A in the first MP-capable is related to 373 RFC6824 only and does not exist in RFC8684. 375 Figure 3: MPTCP RobE_SIM Connection Setup 377 2.3. Heuristic Initial Path Selection (RobE_IPS) 379 2.3.1. Architecture 381 Figure 4 provides the architecture for RobE_IPS and employs an 382 "Initial Path Selection" logic which can be integrated into the MPTCP 383 stack or exists as an isolated module in the terminal. The IPS logic 384 has access to a set of transmission status information for each 385 available path or its belonging network interfaces. When an 386 application starts a first communication, IPS selects based on the 387 available path transmission characteristics the path with the highest 388 probability to succeed. 390 +-------------------+ +-------------------+ 391 | Terminal | | Server | 392 | +-------------+ | | +-------------+ | 393 | |Application n| | | |Application n| | 394 | +-------------+ | | +-------------+ | 395 | | | | | | 396 | +-------------+ | | | | 397 | |Initial-path | |-------+ | | | 398 | | Selection | | | | | | 399 | +-------------+ | | | | | 400 | | | +--------+ | | | 401 | +-------------+ |--|Internet|--| +-------------+ | 402 | | MPTCP Stack | |--+--------+--| | MPTCP Stack | | 403 | +-------------+ | | +-------------+ | 404 +-------------------+ +-------------------+ 406 Figure 4: Architecture for Initial-path Selection 408 2.3.2. Typical Scenarios 410 Two typical RobE_IPS scenarios are presented in this section. 411 Figure 5 shows that the "Initial Path Selection" logic executed for 412 each MPTCP connection establishment. On the other hand Figure 6 413 describes that "Initial Path Selection" in case no path information 414 are available. Considering the fact that no heuristics are given 415 before a recent MPTCP connection was established, the default initial 416 path can be adopted. Further combinations and implementations with 417 more or less sophisticated heuristics are possible. 419 +---------------+ 420 | Application | 421 | Request | 422 +---------------+ 423 | 424 V 425 +---------------+ 426 +--->| Initial-path |<---+ 427 | | Selection | | 428 | +---------------+ | 429 | | | 430 | V |Info 431 | +---------------+ | 432 | | Set initial |----+ 433 | | path | 434 | | for MPTCP | 435 | +---------------+ 436 | | 437 | V 438 | +---------------+ 439 |No |Establish MPTCP| 440 +----| Connection | 441 +---------------+ 442 |Yes 443 V 445 Figure 5: RobE_IPS for each connection establishment 446 +--------------+ 447 | Application | 448 | Request | 449 +--------------+ 450 | 451 V 452 +--------------+Yes 453 | First |------------+ 454 | Connection? | | 455 +--------------+ | 456 |No | 457 V | 458 +--------------+ V 459 +----->| Initial-path |<-+ +-------+ 460 | | Selection | | |Default| 461 | +--------------+ | |initial| 462 | | | | path | 463 | | | +-------+ 464 | V |Info | 465 | +--------------+ | | 466 | | Set initial |--+ | 467 | | path | | 468 | | for MPTCP | | 469 | +--------------+ | 470 | | | 471 | V | 472 |No +--------------+ | 473 +------| Successful? |<-----------+ 474 +--------------+ 475 |Yes 476 V 478 Figure 6: RobE_IPS using default route when no meaningful 479 heuristic available 481 Figure 7 shows the process flow of "Initial Path Selection". Upon a 482 request from an application, the IPS logic will acquire transmission 483 status information which represents the transmission performance of 484 each available path or network interface and evaluate it. The 485 transmission status information is characterized by at least one of 486 the parameters: signal strength, throughput, round-trip time (RTT) 487 and link success rate. In this way, the path with the best 488 transmission performance can be determined and used for connection 489 establishment. 491 | 492 V 493 +---------------------------+ 494 |Acquire transmission status| 495 | info for available paths | 496 +---------------------------+ 497 | 498 V 499 +---------------------------+ 500 | Evaluating the status | 501 | for available paths | 502 +---------------------------+ 503 |No 504 V 505 +---------------------------+ 506 | Determining an available | 507 | path with better | 508 | transmission | 509 | performance | 510 +---------------------------+ 511 | 512 V 513 +---------------------------+ 514 | Using the network | 515 | interface | 516 |corresponding to the path | 517 | with better transmission | 518 |performance for connection | 519 | establishment | 520 +---------------------------+ 521 | 522 V 524 Figure 7: Implementation process for Initial Path Selection 526 2.3.3. Path decision information 528 The level of heuristic can be mainly divided into three layer: 529 application level, transport-layer level and link-layer level based 530 on the information acquisition method. For example, RTT can be 531 calculated for each path within a MPTCP connection and belongs 532 thereof to the transport-layer level. The transmission status 533 information for each available path SHOULD be characterized by at 534 least one of the parameters: signal strength, throughput, RTT and 535 link success rate. Application level information are more seen for 536 statistical purposes. 538 * Application level: application name, domain name, port number and 539 location. 541 * Transport-layer level: RTT, CWND, Error rate. 543 2.3.4. Initial Path Selection use local RTT information 545 Figure 8 presents a "Initial Path Selection" logic based on RTT, e.g. 546 assuming two paths over LTE and WiFi access. RTT calculation on the 547 transport layer usually reflect the time when an information is sent 548 and an related acknowledgment received. For an asymmetric usage 549 (e.g. download only) of a communication it might happen that recent 550 RTT calculation is only available on sender side which is possibly 551 not the side which employs the IPS logic. A solution for this can be 552 found in Section 3.2. Instead of using the most recent RTT value of 553 a path a filtered value consisting of several measured RTTs can be 554 used. A RTT can also be derived from link layer information but may 555 has a limited meaning when it does not picture the end-to-end 556 latency. 558 +-------------------+ 559 | New Session | 560 +-------------------+ 561 | 562 V 563 +-------------------+ No 564 |Running Connections|-----------+ 565 |(LTE.RTT| Any data for | No 593 | | Initial Path |----------+ 594 | | Selection? | | 595 | +--------------+ | 596 | | | 597 | V V 598 | +--------------+ +--------+ 599 | | Initial-path | |RobE_SIM| 600 | | Selection |<-+ +--------+ 601 | +--------------+ | | 602 | | | | 603 | V |Info | 604 | +---------------+ | | 605 |No |Establish MPTCP|-+ | 606 +------| Connection |<--------+ 607 +---------------+ 608 | 609 V 610 No +---------------+ 611 <------| Successful ? | 612 Network+---------------+ 613 Problem |Yes 614 V 616 Figure 9: Combination of RobE_SIM and RobE_IPS 618 2.5. Combination of RobE_TIMER and RobE_IPS 620 Since RobE_IPS solely does not guarantee that session can be set up 621 on the selection of initial path, it can also be combined with 622 RobE_TIMER which generates less overhead compared to the combination 623 with RobE_SIM in Section 2.4 and guarantees session setup. 624 RobE_TIMER can be introduced to optimize the control of path 625 switching when the initial path selected by RobE_IPS is 626 dysfunctional. When the system enables RobE_IPS and uses the 627 selected initial path for session establishment,it sets the timer for 628 path switching. When timer is expired, the system will change to 629 another path to re-establish connection according to Section 2.1. 631 +---------------+ 632 | Application | 633 | Request | 634 +---------------+ 635 | 636 V 637 +---------------+ 638 | Initial Path | 639 |----->| Selection | 640 | | and Set Timer | 641 | +---------------+ 642 | | 643 | V 644 |Yes +---------------+ 645 +------| Timer is up? | 646 +---------------+ 647 |No 648 V 649 +---------------+ 650 |Establish MPTCP| 651 | Connection | 652 +---------------+ 653 | 654 V 655 No +---------------+ 656 <------| Successful? | 657 Network+---------------+ 658 Problem |Yes 659 V 661 Figure 10: Combination of RobE_Timer and RobE_IPS 663 3. Implementation with Bi-directional MPTCP Support 665 Solutions which requires bi-directional support between two MPTCP 666 hosts promise to have better and possibly more features. However, 667 they cannot be defined without extending current standards in 668 [RFC6824] and [RFC8684]. The RobE_SIM and RobE_IPS approach are both 669 capable of profit from an explicit support of the remote end host and 670 defined within this section. 672 3.1. Simultaneous Initial Paths Extended Version (RobE_eSIM) 674 RobE_eSIM extends RobE_SIM by reusing the potential initial flows. 675 This eliminates the overhead from RobE_SIM by introducing a new 676 option MP_JOIN_CAP and accelerate the transmission speed by early 677 availability of multiple paths. Further it relaxes the dependency on 678 a reliable third ACK of the 3-way handshake in [RFC8684]. Remote 679 endpoint support can be negotiated in two ways, an implicit in 680 Section 3.1.1 or explicit in Section 3.1.2. 682 3.1.1. RobE_eSIM implicit Negotiation and Procedure 684 Similar to RobE_SIM in Section 2.2, the establishment process of 685 [RFC6824] or [RFC8684] is applied independently on multiple path 686 simultaneously. In Figure 11 this is shown in SA1 and SA2. The 687 first path which returns a SYN/ACK (e.g. SA3) is selected as the 688 initial path and proceed with the traditional establishment process 689 (SA5). Any other path which has to send the final ACK of the 3-way 690 handshake includes a new option MP_JOIN_CAP (see definition in 691 Section 3.1.3.2) instead of a MP_CAPABLE (SA6.2). 693 Host A Host B 694 ------------------------ ---------- 695 Address A1 Address A2 Address B1 696 ---------- ---------- ---------- 697 | | | 698 | SYN + MP_CAPABLE(Key-A[*]) | 699 (SA1) |--------------------------------------------->| (SB1) 700 | | SYN + MP_CAPABLE(Key-A'[*]) | 701 (SA2) | |------------------------------->| (SB2) 702 | | | 703 (SA3) |<---------------------------------------------| (SB3) 704 | SYN/ACK + MP_CAPABLE(Key-B) | 705 (SA4) | |<-------------------------------| (SB4) 706 | | SYN/ACK + MP_CAPABLE(Key-B') | 707 | | | 708 | ACK + MP_CAPABLE(Key-A, Key-B) | 709 (SA5) |--------------------------------------------->| (SB5) 710 | | | 711 (SA6.2) | | | (SB6.2) 712 RobE EXT | | ACK + MP_JOIN_CAP(Key-A, HMAC) | 713 (+fast) | |------------------------------->| 715 [*] Key-A in the first MP-capable is related to 716 RFC6824 only and does not exist in RFC8684. 718 Figure 11: MPTCP RobE_eSIM implicit Connection Setup 720 Following the possible process in Figure 11, two further 721 constellations are imaginable and elaborated below. 723 1. In the flow diagram Figure 11, A1<->B1 is assumed to be the 724 initial flow. A2<->B1 shall be recycled and the ACK is sent with 725 MP_JOIN_CAP. Furthermore, the MP_CAPABLE arrives first at Host B 726 (SB5) and the MP_JOIN_CAP afterwards (SB6.2). When the 727 MP_JOIN_CAP is received, Host B has to iterate over the 728 connection list once (like MP_JOIN) and check for Key-A 729 availability. If a Key-A connection is found, this one is 730 validated against the HMAC value. The validation has two 731 reasons: first, several Key-A can exist, because different hosts 732 may choose the same Key-A by accident. Furthermore, no one can 733 join a connection by just recording/brute-forcing Key-A and 734 duplicating the request. 736 2. Like above, but MP_JOIN_CAP arrives before last MP_CAPABLE at 737 Host B 739 * [RFC8684]; Based on Key-A, Host B will iterate over the 740 connection list, but it will not find a match, because Key-A 741 of the previous selected initial flow (SA3, SA5) has not 742 arrived yet. So it will continue with a fast iteration only 743 over the connections which are still in establishment phase 744 using the 10 bit Key-B fast hash (crc16(Key-B) & 0x3FF). If 745 it matches against a (precomputed) existing Key-B_fast_hash in 746 the connection list, it will validate the request using the 747 HMAC(Key-A+B+B') to ensure legitimation. If successful, both, 748 the initial flow and the MP_JOIN_CAP flow, can be immediately 749 established. This is true, because without the knowledge of 750 Key-B, Host A could not calculate the HMAC. So it is clear, 751 that Host A had received the SYN/ACK (SB3). This also 752 mitigates the exchange of a reliable ACK during the handshake 753 process. MPTCP sends the Key-A only with the last ACK and 754 therefore prevents subsequent flow establishment until 755 successful reception at Host B. Using RobE_EXT, the reception 756 of a MP_JOIN_CAP ([RFC8684]) is sufficient to establish both, 757 the path carrying Key-B and Key-B'. 759 * [RFC6824]; Can match based on Key-A, same effort as for a MP 760 JOIN. 762 3. A2<->B1 is selected as initial flow, because the respective SYN/ 763 ACK returns earlier at Host A. It is the same as above, just the 764 other way round. 766 3.1.2. RobE_eSIM explicit Negotiation and Procedure 768 The process of an explicit negotiation of RobE_eSIM follows Figure 11 769 but uses the ROBE_eSIM_EN option Figure 13 additionally during the 770 handshake procedure. 772 Host A Host B 773 ------------------------ ---------- 774 Address A1 Address A2 Address B1 775 ---------- ---------- ---------- 776 | | | 777 | SYN+MP_CAPABLE+ROBE_eSIM_EN(Key-A[*]) | 778 |----------------------------------------------------->| 779 | | SYN+MP_CAPABLE+ROBE_eSIM_EN(Key-A'[*]) | 780 | |--------------------------------------->| 781 | SYN/ACK+MP_CAPABLE+ROBE_eSIM_EN(Key-B) | 782 |<---------------------------------------------------->| 783 | | SYN/ACK+MP_CAPABLE+ROBE_eSIM_EN(Key-B')| 784 | |<---------------------------------------| 785 | ACK+MP_CAPABLE(Key-A,Key-B) | 786 |----------------------------------------------------->| 787 | | | 788 | | ACK+MP_JOIN_CAP(Key-A,HMAC) | 789 | |--------------------------------------->| 790 | | | 792 [*] Key-A in the first MP-capable is related to 793 RFC6824 only and does not exist in RFC8684. 795 Figure 12: MPTCP RobE_eSIM explicit Connection Setup 797 3.1.3. Protocol Adaptation 799 3.1.3.1. ROBE_eSIM_EN Option 801 1 2 3 802 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 803 +---------------+---------------+-------+-------+---------------+ 804 | Kind | Length |Subtype| (reserved) | 805 +---------------+---------------+-------+-------+---------------+ 807 Figure 13: ROBE_eSIM_EN_OPTION 809 3.1.3.2. MP_JOIN_CAP Option 810 1 2 3 811 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 812 +---------------+---------------+-------+-------+---------------+ 813 | Kind | Length |Subtype| | ADDR_ID | 814 +---------------+---------------+-------+-------+---------------+ 815 | Sender's Key-A (64 bits) | 816 | | 817 | | 818 +---------------------------------------------------------------+ 819 | HMAC (>=96 bits) | 820 | | 821 | | 822 : : 823 +---------------------------------------------------------------+ 824 Key-B_fast_hash = crc16(Key-B) & 0x3FF -> (10bit) 825 HMAC_keys = HMAC(Key-A+Key-B+Key-B') -> (>=96bit) 826 HMAC = (HMAC_keys & ~0x3FF) | Key-B_fast_hash -> (size HMAC_keys) 828 Figure 14: MP_JOIN_CAP 830 Computational effort on receiver side is most often expected to be 831 the same as with MP_JOIN. Key-A ensures identification of related 832 flows Key-B_fast_hash enables MP session even when selected initial 833 flow is not fully established yet (slight computational overhead). 834 HMAC authenticates relationship of initial and potential initial 835 flows. 837 3.1.4. Fallback Mechanisms 839 3.1.4.1. Fallback mechanism for implicit RobE_eSIM 841 [TBD] 843 3.1.4.2. Fallback mechanism for explicit RobE_eSIM 845 This mechanism considers that both sides support MPTCP capability but 846 the receiver does not equipped with RobE_eSIM. MPTCP session with 847 RobE_eSIM negotiation will seamlessly fallback to normal MPTCP 848 process. 850 [Requires further check how an unaware Host B reacts on possible 851 ROBE_eSIM_EN; Ignore or RST? See also RFC6824 Sec. 3.6 "Should 852 fallback [...] the path does not support the MPTCP options"] 853 Host A Host B 854 ------------------------ ---------- 855 Address A1 Address A2 Address B1 856 ---------- ---------- ---------- 857 | | | 858 | SYN+MP_CAPABLE+ROBE_eSIM_EN | 859 |------------------------------------------>| 860 | | SYN+MP_CAPABLE+ROBE_eSIM_EN | 861 | |---------------------------->| 862 | SYN/ACK+MP_CAPABLE | 863 |<----------------------------------------->| 864 | | SYN/ACK+MP_CAPABLE | 865 | |<----------------------------| 866 | ACK+MP_CAPABLE | 867 |------------------------------------------>| 868 | | RST | 869 | |---------------------------->| 870 | | SYN+MP_JOIN | 871 | |---------------------------->| 872 | | MP_JOIN Process... | 873 | | | 875 Figure 15: Fallback to MPTCP when missing RobE_eSIM support 877 3.1.4.3. Fallback to regular TCP when missing MPTCP support 879 When the receiver is not MPTCP enabled, MPTCP session with RobE_eSIM 880 negotiation will seamlessly fallback to regular process which is 881 illustrated in this section. 883 Host A Host B 884 ------------------------ ---------- 885 Address A1 Address A2 Address B1 886 ---------- ---------- ---------- 887 | | | 888 | SYN+MP_CAPABLE+ROBE_eSIM_EN | 889 |------------------------------------------>| 890 | | SYN+MP_CAPABLE+ROBE_eSIM_EN | 891 | |---------------------------->| 892 | SYN/ACK | 893 |<----------------------------------------->| 894 | | SYN/ACK | 895 | |<----------------------------| 896 | ACK | 897 |------------------------------------------>| 898 | | RST | 899 | |---------------------------->| 900 | | Regular TCP Process... | 901 | | | 903 Figure 16: Fallback to TCP without MPTCP support 905 3.1.5. Comparison Robe_SIM and RobE_eSIM 907 Potential initial flows in RobE_SIM Section 2.2 and RobE_eSIM 908 Section 3.1 guarantee MPTCP session establishment if at least one 909 selected path for session establishment is functional. Figure 17 910 makes the differences between both approaches visible and points to 911 the latest decision possibility during session setup when RobE_SIM or 912 RobE_eSIM can be selected. Until SA5 in Figure 17 traditional MPTCP 913 connection setup is independently applied on multiple paths 914 simultaneously and offers to select the initial flow later (potential 915 initial flows). The final decision which path is selected as the 916 main one and the handling of the remaining flow(s) differs in SA6.1 917 when RobE_SIM is applied or instead SA6.2 RobE_eSIM. 919 Host A Host B 920 ------------------------ ---------- 921 Address A1 Address A2 Address B1 922 ---------- ---------- ---------- 923 | | | 924 | SYN + MP_CAPABLE(Key-A[*]) | 925 (SA1) |--------------------------------------------->| (SB1) 926 | | SYN + MP_CAPABLE(Key-A'[*]) | 927 (SA2) | |------------------------------->| (SB2) 928 | | | 929 (SA3) |<---------------------------------------------| (SB3) 930 | SYN/ACK + MP_CAPABLE(Key-B) | 931 (SA4) | |<-------------------------------| (SB4) 932 | | SYN/ACK + MP_CAPABLE(Key-B') | 933 | | | 934 | ACK + MP_CAPABLE(Key-A, Key-B) | 935 (SA5) |--------------------------------------------->| (SB5) 936 | | RST | 937 (SA6.1) | |------------------------------->| (SB6.1) 938 RobE SIM | | | 939 (robust) | | | 940 ------------------------------------------------------------------- 941 RobE EXT | | | 942 (+fast) | | ACK + MP_JOIN_CAP(Key-A, HMAC) | 943 (SA6.2) | |------------------------------->| (SB6.2) 945 [*] Key-A in the first MP-capable is related to 946 RFC6824 only and does not exist in RFC8684. 948 Figure 17: MPTCP RobE_SIM and RobE_eSIM connection setup 950 3.1.6. Security Consideration 952 [Tbd, however no differences to [RFC6824] and {{RFC8684} are 953 expected] 955 3.2. Heuristic Initial Path Selection with remote RTT Measurement 956 3.2.1. Description 958 Usually the path RTT can be determined by a time difference between 959 sending a package and an ACK and is integrated into the TCP protocol. 960 For asymmetric transmission, the latest RTT for TCP flows is 961 calculated by the side which sends data at latest and possible does 962 not correspond to the site which employs RobE_IPS. This problem is 963 already elaborated in Section 2.3.4 and can be solved by transmitting 964 the RTT information per subflow. The negotiation procedure is 965 depicted in Figure 18 and uses the MPTCP option L_RTT_EN defined in 966 Section 3.2.2. 968 Host A Host B 969 ------------------------ ---------- 970 Address A1 Address A2 Address B1 971 ---------- ---------- ---------- 972 | | | 973 | SYN+MP_CAPABLE+L_RTT_EN | 974 |------------------------------------------>| 975 | SYN/ACK+MP_CAPABLE+L_RTT_EN | 976 |<------------------------------------------| 977 | ACK+MP_CAPABLE | 978 |------------------------------------------>| 979 | ACK+DSS+L_RTT_EN(latest RTT)+Data | 980 |<------------------------------------------| 981 | | SYN+MP_JOIN | 982 | |---------------------------->| 983 | | MP_JOIN Process... | 984 | | | 986 Figure 18: Negotiation procedure for RTT exchange 988 A successful negotiation allows the exchange of the measured RTT 989 value from one subflow of a MPTCP host to another using the "Latest 990 RTT" field within the L_RTT_EN option. 992 3.2.2. Protocol Adaptation 994 Calculating the "Latest RTT" by a remote host in an asymmetry 995 transmission scenario should be transferred from remote host to the 996 client running RobE_IPS. So a new MPTCP subtype option named 997 L_RTT_EN is allocated for this function. During the three-way 998 handshake L_RTT_EN is used for negotiation of remote RTT measurement 999 capability between client and server (in Section 3.2.1). When both 1000 parts support the usage of remote RTT measurement, the "Latest RTT" 1001 field in L_RTT_EN is applied for carrying the value of latest RTT 1002 computed by the remote host. 1004 1 2 3 1005 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 1006 +---------------+---------------+-------+-------+---------------+ 1007 | Kind | Length |Subtype| (reserved) | 1008 +---------------+---------------+-------+-------+---------------+ 1009 | Latest RTT (32 bits) | 1010 | | 1011 | | 1012 +---------------------------------------------------------------+ 1014 Figure 19: ROBE_L_RTT_EN OPTION 1016 3.2.3. Fallback Mechanism 1018 When the receiver is not L_RTT_EN capable, MPTCP session with 1019 L_RTT_EN negotiation will seamlessly fallback to normal MPTCP 1020 process. 1022 [TBD, Need same checks as Section 3.1.4.2] 1024 Host A Host B 1025 ------------------------ ---------- 1026 Address A1 Address A2 Address B1 1027 ---------- ---------- ---------- 1028 | | | 1029 | SYN+MP_CAPABLE+L_RTT_EN | 1030 |------------------------------------------>| 1031 | SYN/ACK+MPTCP_CAPABLE | 1032 |<------------------------------------------| 1033 | ACK+MPTCP_CAPABLE | 1034 |------------------------------------------>| 1035 | | SYN+MP_JOIN | 1036 | |---------------------------->| 1037 | | MP_JOIN Process... | 1038 | | | 1040 Figure 20: Fallback to MPTCP without RobE_IPS 1042 3.2.4. Security Consideration 1044 [Tbd] 1046 4. IANA Considerations 1048 This document defines three new values to MPTCP Option Subtype as 1049 following. 1051 +=======+==============+=======================+=============+ 1052 | Value | Symbol | Name | Reference | 1053 +=======+==============+=======================+=============+ 1054 | TBD | ROBE_eSIM_EN | RobE_eSIM enabled | Section 3.1 | 1055 +-------+--------------+-----------------------+-------------+ 1056 | TBD | MP_JOIN_CAP | Join connection | Section 3.1 | 1057 | | | directly in RobE_eSIM | | 1058 +-------+--------------+-----------------------+-------------+ 1059 | TBD | L_RTT_EN | Server RTT enabled | Section 3.2 | 1060 +-------+--------------+-----------------------+-------------+ 1062 Table 2: RobE Option Subtypes 1064 5. References 1066 5.1. Normative References 1068 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1069 RFC 793, DOI 10.17487/RFC0793, September 1981, 1070 . 1072 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1073 "TCP Extensions for Multipath Operation with Multiple 1074 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1075 . 1077 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1078 Paasch, "TCP Extensions for Multipath Operation with 1079 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1080 2020, . 1082 5.2. Informative References 1084 [RobE_paper] 1085 Amend, M., Rakocevic, V., Matz, A.P., and E. Bogenfeld, 1086 "RobE: Robust Connection Establishment for Multipath TCP", 1087 ANRW '18 p. 76-82, 16 July 2018, 1088 . 1090 [RobE_slides] 1091 Amend, M., Matz, A.P., and E. Bogenfeld, "A proposal for 1092 MPTCP Robust session Establishment (MPTCP RobE)", IETF 1093 99 Multipath TCP WG session, 18 July 2017, 1094 . 1098 Authors' Addresses 1100 Markus Amend 1101 Deutsche Telekom 1102 Deutsche-Telekom-Alle 9 1103 64295 Darmstadt 1104 Germany 1106 Email: Markus.Amend@telekom.de 1108 Jiao Kang 1109 Huawei 1110 D2-03,Huawei Industrial Base 1111 Shenzhen 1112 Guangdong, 518129 1113 China 1115 Email: kangjiao@huawei.com