idnits 2.17.1 draft-amend-tcpm-mptcp-robe-01.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 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 540: '...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 (22 February 2021) is 1158 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 849, but not defined == Missing Reference: 'Tbd' is mentioned on line 1052, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 3 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: 26 August 2021 Huawei 6 22 February 2021 8 Multipath TCP Extension for Robust Session Establishment 9 draft-amend-tcpm-mptcp-robe-01 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 26 August 2021. 64 Copyright Notice 66 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . 7 82 2. Implementation without MPTCP protocol adaptation . . . . . . 8 83 2.1. Re-transmission Timer(RobE_TIMER) . . . . . . . . . . . . 8 84 2.2. Simultaneous Initial Paths Simple Version (RobE_SIM) . . 9 85 2.3. Heuristic Initial Path Selection (RobE_IPS) . . . . . . . 10 86 2.3.1. Architecture . . . . . . . . . . . . . . . . . . . . 10 87 2.3.2. Typical Scenarios . . . . . . . . . . . . . . . . . . 11 88 2.3.3. Path decision information . . . . . . . . . . . . . . 14 89 2.3.4. Initial Path Selection use local RTT information . . 15 90 2.4. Combination of RobE_SIM and RobE_IPS . . . . . . . . . . 15 91 2.5. Combination of RobE_TIMER and RobE_IPS . . . . . . . . . 16 92 3. Implementation with Bi-directional MPTCP Support . . . . . . 17 93 3.1. Simultaneous Initial Paths Extended Version 94 (RobE_eSIM) . . . . . . . . . . . . . . . . . . . . . . . 18 96 3.1.1. RobE_eSIM implicit Negotiation and Procedure . . . . 18 97 3.1.2. RobE_eSIM explicit Negotiation and Procedure . . . . 20 98 3.1.3. Protocol Adaptation . . . . . . . . . . . . . . . . . 20 99 3.1.4. Fallback Mechanisms . . . . . . . . . . . . . . . . . 21 100 3.1.5. Comparison Robe_SIM and RobE_eSIM . . . . . . . . . . 23 101 3.1.6. Security Consideration . . . . . . . . . . . . . . . 24 102 3.2. Heuristic Initial Path Selection with remote RTT 103 Measurement . . . . . . . . . . . . . . . . . . . . . . . 24 104 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 24 105 3.2.2. Protocol Adaptation . . . . . . . . . . . . . . . . . 25 106 3.2.3. Fallback Mechanism . . . . . . . . . . . . . . . . . 26 107 3.2.4. Security Consideration . . . . . . . . . . . . . . . 26 108 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 109 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 110 5.1. Normative References . . . . . . . . . . . . . . . . . . 27 111 5.2. Informative References . . . . . . . . . . . . . . . . . 27 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 an 129 MP_CAPABLE exchanged first, followed when successfully 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 correspond to different access networks 166 such as cellular and WiFi. The path or network interface for 167 initiating the initial subflow setup is most often provided by the 168 operation system of the UE. For example, if both a cellular 169 connection and WiFi are present in a mobile phone, WiFi is usually 170 the interface offered to 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 externally 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 Introduction of RobE_SIM and RobE_eSIM aims to overcome the 192 limitations of [RFC6824] and [RFC8684], using one initial flow and 193 introduces the concept of multiple potential initial flows triggered 194 simultaneously.Potential initial flows give the freedom to use more 195 than one path to request multipath capability and select the initial 196 flow at a later point. Potential initial flow mechanisms and the 197 gain of robustness and performance over the traditional MPTCP 198 connection setup are evaluated in [RobE_slides] and [RobE_paper]. 199 RobE_SIM is a break-before-make mechanism, guaranteeing at least the 200 robust connection establishment, however the RobE_eSIM reuses every 201 potential initial flow request to combine it with less overhead and 202 accelerated multipath availability, leveraging a new MPTCP option 203 MP_JOIN_CAP. From a standardization perspective, the RobE_SIM is 204 fully compliant with [RFC6824] and [RFC8684] and is herein more of a 205 descriptive and procedural nature. The RobE_eSIM requires a new 206 MPTCP option but offers the potential to significantly improve the 207 MPTCP experience. 209 For the limitation of the default initial path, RobE_IPS makes no 210 changes to standard MPTCP procedure and improves the performance of 211 connection establishment by introducing an initial path selection 212 strategy and required algorithms. The input for strategy and 213 algorithms is the transmission status information which represents 214 the transmission performance of each available path or network 215 interface. The transmission status information is characterized by 216 at least one of the parameters: signal strength, throughput, round- 217 trip time (RTT), and link success rate. In this way, a path with 218 better transmission performance can be learned and determined and the 219 respective network interface can be used for connection 220 establishment. 222 The most simple approach for a robust MPTCP session establishment is 223 RobE_TIMER, iterating the process of initial path establishment over 224 all available paths, if the previous try has failed. Triggering a 225 new try on a next path is depending on an expiration timer, 226 preferably re-use TCP's in-built expiration timer. 228 Table 1 summarizes the impact of RobE_TIMER, RobE_SIM, RobE_eSIM, and 229 RobE_IPS compared to [RFC6824] and [RFC8684]. 231 +========+==========+============+==========+============+==========+ 232 |Scenario|MPTCP |RobE_TIMER |RobE_SIM |RobE_eSIM |RobE_IPS | 233 +========+==========+============+==========+============+==========+ 234 |IP |Delayed |In the scope|No impact |No impact |Delayed | 235 |packet |connection|of timer | | |connection| 236 |loss | | | | | | 237 +--------+----------+------------+----------+------------+----------+ 238 |IP |No |In the scope|No impact |No impact |No | 239 |broken |connection|of timer | | |connection| 240 +--------+----------+------------+----------+------------+----------+ 241 |IP setup|Default |Default |Fastest |Fastest path|Selected | 242 |duration|route |route (+ |path | |path | 243 |de- | |path 1..n) | | | | 244 |pendency| | | | | | 245 +--------+----------+------------+----------+------------+----------+ 246 |MP |MP_CAPABLE|sum_1..n( |MP_CAPABLE|max( |MP_CAPABLE| 247 |avail- |HS + |MP_CAPABLE_n|HS + |MP_CAPABLE_1|HS + | 248 |ability |MP_JOIN HS|HS) + |MP_JOIN HS|.. |MP_JOIN HS| 249 |duration| |MP_JOIN HS | |MP_CAPABLE_n| | 250 | | | | |HS) | | 251 +--------+----------+------------+----------+------------+----------+ 252 |Guaran- |Depends on|Yes |Yes |Yes |Depends on| 253 |teeing |the | | | |selection | 254 |session |default | | | | | 255 |setup |route | | | | | 256 +--------+----------+------------+----------+------------+----------+ 258 Table 1: Overview RobE features during initial connection setup 260 | IP: Initial Path; MP: Multi-Path; HS: Handshake 262 1.1. Terminology 264 This document makes use of a number of terms that are either MPTCP- 265 specific or have defined meaning in the context of MPTCP, as follows: 267 Path: A sequence of links between a sender and a receiver, defined 268 in this context by a 4-tuple of source and destination address/ 269 port pairs. 271 Subflow: A flow of TCP segments operating over an individual path, 272 which forms part of a larger MPTCP connection. A subflow is 273 started and terminated similar to a regular TCP connection. 275 2. Implementation without MPTCP protocol adaptation 277 RobE_TIMER, RobE_SIM, and RobE_IPS are compatible with the current 278 MPTCP protocol definitions in [RFC6824] and [RFC8684] but may lack of 279 the full optimization potential which requires protocol adaptation as 280 detailed in Section 3. Following sections will describe the newly 281 introduced mechanisms in detail. 283 2.1. Re-transmission Timer(RobE_TIMER) 285 In RobE_TIMER, a new connection is initiated by sending a 286 SYN+MP_CAPABLE along the initial path. If this path is functional, 287 the solution will perform in the same way as classic MPTCP: the 288 initial flow will be established, and subsequent flows can be created 289 afterwards. If however the initial path is faulty, the 290 retransmission will be triggered on another path. This path might 291 circumvent the dysfunctional network, and allow the client to create 292 an initial subflow. The first path is now seen as a subsequent path 293 and the client sends SYN+MP_JOIN messages to create a subsequent 294 flow. 296 In high latency networks, the initial SYN+MP_CAPABLE messages might 297 be delayed until the client retries sending them on another path. 298 Once the second SYN arrives at the server, it will try to complete 299 the three-way handshake. If the first SYN was delayed by more than 300 the retransmission time plus half a Round Trip Time (RTT) of the 301 second path, it will arrive at the server after the second SYN. The 302 server could now treat the segment as obsolete and drop it. 304 Host A Host B 305 ------------------------ ---------- 306 Address A1 Address A2 Address B1 307 ---------- ---------- ---------- 308 | | | 309 | SYN + MP_CAPABLE(Key-A[*]) | 310 |Timer---------------------------------------->| 311 | | SYN + MP_CAPABLE(Key-A'[*]) | 312 | |------------------------------->| 313 | | SYN/ACK+MP_CAPABLE(Key-B') | 314 | |<-------------------------------| 315 | | ACK + MP_CAPABLE(Key-A',Key-B')| 316 | |------------------------------->| 317 | | SYN + MP_JOIN(Token-B',R-A) | 318 |--------------------------------------------->| 319 | Subflow will be set up as normal MPTCP | 320 | | 322 [*] Key-A in the first MP-capable is related to 323 RFC6824 only and does not exist in RFC8684. 325 Figure 2: The RobE_TIMER Solution 327 Immediately after sending the final ACK of the initial handshake, 328 subflows are established on the remaining paths as defined in 329 [RFC6824] and [RFC8684] 331 [Notes: How to set the Timer is TBD. If there is the case that the 332 first SYN on default path arrives earlier than that from the second 333 path, the MPTCP connection will be initialized on the path of the 334 first SYN. The server could treat the second SYN as obsolete and 335 drop it.] 337 2.2. Simultaneous Initial Paths Simple Version (RobE_SIM) 339 RobE_SIM is a sender only implementation and no prior negotiation 340 with the receiver side is required. In RobE_SIM, the MPTCP 341 connection setup benefits from the fastest path. As shown in 342 Figure 3, host A initiates the connection handshake on more than one 343 path independently (SA1 and SA2). The paths selected for RobE_SIM 344 and referred to as potential initial flows, can belong to the number 345 of interfaces on the device or a subset selected on experience. When 346 Host A receives the first SYN/ACK back from Host B (SA3), the path 347 carrying this message is identified as the normal initial path. Host 348 A sends then immediately a TCP RST message (SA6.1) on any other path 349 used for simultaneous connection setup causing an immediate 350 termination of assigned flows (break-before-make). The terminated 351 ones are merged as subsequent subflows following the JOIN procedure 352 described in [RFC6824] and [RFC8684]. The process is equivalent to 353 any other scenario where the SYN/ACK arrives on an other path than 354 depicted in Figure 3. 356 Host A Host B 357 ------------------------ ---------- 358 Address A1 Address A2 Address B1 359 ---------- ---------- ---------- 360 | | | 361 | SYN + MP_CAPABLE(Key-A[*]) | 362 (SA1) |--------------------------------------------->| (SB1) 363 | | SYN + MP_CAPABLE(Key-A'[*]) | 364 (SA2) | |------------------------------->| (SB2) 365 | | | 366 (SA3) |<---------------------------------------------| (SB3) 367 | SYN/ACK + MP_CAPABLE(Key-B) | 368 (SA4) | |<-------------------------------| (SB4) 369 | | SYN/ACK + MP_CAPABLE(Key-B') | 370 | | | 371 | ACK + MP_CAPABLE(Key-A, Key-B) | 372 (SA5) |--------------------------------------------->| (SB5) 373 | | RST | 374 (SA6.1) | |------------------------------->| (SB6.1) 375 RobE SIM | | SYN + MP_JOIN(Token-B, R-A) | 376 (robust) | |------------------------------->| 377 | | MP_JOIN Process... | 379 [*] Key-A in the first MP-capable is related to 380 RFC6824 only and does not exist in RFC8684. 382 Figure 3: MPTCP RobE_SIM Connection Setup 384 2.3. Heuristic Initial Path Selection (RobE_IPS) 386 2.3.1. Architecture 388 Figure 4 provides the architecture for RobE_IPS and employs an 389 "Initial Path Selection" logic which can be integrated into the MPTCP 390 stack or exists as an isolated module in the terminal. The IPS logic 391 has access to a set of transmission status information for each 392 available path or its belonging network interfaces. When an 393 application starts a first communication, IPS selects based on the 394 available path transmission characteristics the path with the highest 395 probability to succeed. 397 +-------------------+ +-------------------+ 398 | Terminal | | Server | 399 | +-------------+ | | +-------------+ | 400 | |Application n| | | |Application n| | 401 | +-------------+ | | +-------------+ | 402 | | | | | | 403 | +-------------+ | | | | 404 | |Initial-path | |-------+ | | | 405 | | Selection | | | | | | 406 | +-------------+ | | | | | 407 | | | +--------+ | | | 408 | +-------------+ |--|Internet|--| +-------------+ | 409 | | MPTCP Stack | |--+--------+--| | MPTCP Stack | | 410 | +-------------+ | | +-------------+ | 411 +-------------------+ +-------------------+ 413 Figure 4: Architecture for Initial-path Selection 415 2.3.2. Typical Scenarios 417 Two typical RobE_IPS scenarios are presented in this section. 418 Figure 5 shows the "Initial Path Selection" logic executed for each 419 MPTCP connection establishment. On the other hand Figure 6 describes 420 that "Initial Path Selection" in case no path information is 421 available. Considering the fact that no heuristics are given before 422 a recent MPTCP connection was established, the default initial path 423 can be adopted. Further combinations and implementations with more 424 or less sophisticated heuristics are possible. 426 +---------------+ 427 | Application | 428 | Request | 429 +---------------+ 430 | 431 V 432 +---------------+ 433 +--->| Initial-path |<---+ 434 | | Selection | | 435 | +---------------+ | 436 | | | 437 | V |Info 438 | +---------------+ | 439 | | Set initial |----+ 440 | | path | 441 | | for MPTCP | 442 | +---------------+ 443 | | 444 | V 445 | +---------------+ 446 |No |Establish MPTCP| 447 +----| Connection | 448 +---------------+ 449 |Yes 450 V 452 Figure 5: RobE_IPS for each connection establishment 453 +--------------+ 454 | Application | 455 | Request | 456 +--------------+ 457 | 458 V 459 +--------------+Yes 460 | First |------------+ 461 | Connection? | | 462 +--------------+ | 463 |No | 464 V | 465 +--------------+ V 466 +----->| Initial-path |<-+ +-------+ 467 | | Selection | | |Default| 468 | +--------------+ | |initial| 469 | | | | path | 470 | | | +-------+ 471 | V |Info | 472 | +--------------+ | | 473 | | Set initial |--+ | 474 | | path | | 475 | | for MPTCP | | 476 | +--------------+ | 477 | | | 478 | V | 479 |No +--------------+ | 480 +------| Successful? |<-----------+ 481 +--------------+ 482 |Yes 483 V 485 Figure 6: RobE_IPS using default route when no meaningful 486 heuristic available 488 Figure 7 shows the process flow of "Initial Path Selection". Upon a 489 request from an application, the IPS logic will acquire transmission 490 status information which represents the transmission performance of 491 each available path or network interface and evaluate it. The 492 transmission status information is characterized by at least one of 493 the parameters: signal strength, throughput, round-trip time (RTT), 494 and link success rate. In this way, the path with the best 495 transmission performance can be determined and used for connection 496 establishment. 498 | 499 V 500 +---------------------------+ 501 |Acquire transmission status| 502 | info for available paths | 503 +---------------------------+ 504 | 505 V 506 +---------------------------+ 507 | Evaluating the status | 508 | for available paths | 509 +---------------------------+ 510 |No 511 V 512 +---------------------------+ 513 | Determining an available | 514 | path with better | 515 | transmission | 516 | performance | 517 +---------------------------+ 518 | 519 V 520 +---------------------------+ 521 | Using the network | 522 | interface | 523 |corresponding to the path | 524 | with better transmission | 525 |performance for connection | 526 | establishment | 527 +---------------------------+ 528 | 529 V 531 Figure 7: Implementation process for Initial Path Selection 533 2.3.3. Path decision information 535 The level of heuristic can be mainly divided into three layers: 536 application level, transport-layer level and link-layer level based 537 on the information acquisition method. For example, RTT can be 538 calculated for each path within an MPTCP connection and belongs 539 thereof to the transport-layer level. The transmission status 540 information for each available path SHOULD be characterized by at 541 least one of the parameters: signal strength, throughput, RTT, and 542 link success rate. Application level information are more seen for 543 statistical purposes. 545 * Application level: application name, domain name, port number, and 546 location. 548 * Transport-layer level: RTT, CWND, Error rate. 550 2.3.4. Initial Path Selection use local RTT information 552 Figure 8 presents an "Initial Path Selection" logic based on RTT, 553 e.g. assuming two paths over LTE and WiFi access. RTT calculation on 554 the transport layer usually reflects the time when an information is 555 sent and a related acknowledgment received. For an asymmetric usage 556 (e.g. download only) of a communication it might happen that recent 557 RTT calculation is only available on sender side which is possibly 558 not the side which employs the IPS logic. A solution for this can be 559 found in Section 3.2. Instead of using the most recent RTT value of 560 a path a filtered value consisting of several measured RTTs can be 561 used. A RTT can also be derived from link layer information but may 562 have a limited meaning only when it does not represent the end-to-end 563 latency. 565 +-------------------+ 566 | New Session | 567 +-------------------+ 568 | 569 V 570 +-------------------+ No 571 |Running Connections|-----------+ 572 |(LTE.RTT| Any data for | No 600 | | Initial Path |----------+ 601 | | Selection? | | 602 | +--------------+ | 603 | | | 604 | V V 605 | +--------------+ +--------+ 606 | | Initial-path | |RobE_SIM| 607 | | Selection |<-+ +--------+ 608 | +--------------+ | | 609 | | | | 610 | V |Info | 611 | +---------------+ | | 612 |No |Establish MPTCP|-+ | 613 +------| Connection |<--------+ 614 +---------------+ 615 | 616 V 617 No +---------------+ 618 <------| Successful ? | 619 Network+---------------+ 620 Problem |Yes 621 V 623 Figure 9: Combination of RobE_SIM and RobE_IPS 625 2.5. Combination of RobE_TIMER and RobE_IPS 627 Since RobE_IPS solely does not guarantee that a session can be set up 628 based on the selection of initial path, it can also be combined with 629 RobE_TIMER which generates less overhead compared to the combination 630 with RobE_SIM in Section 2.4 and guarantees session setup. 631 RobE_TIMER can be introduced to optimize the control of path 632 switching when the initial path selected by RobE_IPS is 633 dysfunctional. When the system enables RobE_IPS and uses the 634 selected initial path for session establishment, it sets the timer 635 for path switching. When timer is expired, the system will change to 636 another path to re-establish connection according to Section 2.1. 638 +---------------+ 639 | Application | 640 | Request | 641 +---------------+ 642 | 643 V 644 +---------------+ 645 | Initial Path | 646 |----->| Selection | 647 | | and Set Timer | 648 | +---------------+ 649 | | 650 | V 651 |Yes +---------------+ 652 +------| Timer is up? | 653 +---------------+ 654 |No 655 V 656 +---------------+ 657 |Establish MPTCP| 658 | Connection | 659 +---------------+ 660 | 661 V 662 No +---------------+ 663 <------| Successful? | 664 Network+---------------+ 665 Problem |Yes 666 V 668 Figure 10: Combination of RobE_Timer and RobE_IPS 670 3. Implementation with Bi-directional MPTCP Support 672 Solutions which requires bi-directional support between two MPTCP 673 hosts promise to have better and possibly more features. However, 674 they cannot be defined without extending current standards in 675 [RFC6824] and [RFC8684]. The RobE_SIM and RobE_IPS approach are both 676 capable of profiting from an explicit support of the remote end host 677 and will be defined within this section. 679 3.1. Simultaneous Initial Paths Extended Version (RobE_eSIM) 681 RobE_eSIM extends RobE_SIM by reusing the potential initial flows. 682 This eliminates the overhead from RobE_SIM by introducing a new 683 option MP_JOIN_CAP and accelerate the transmission speed by early 684 availability of multiple paths. Further it relaxes the dependency on 685 a reliable third ACK of the 3-way handshake in [RFC8684]. Remote 686 endpoint support can be negotiated in two ways, an implicit one 687 described in Section 3.1.1 or an explicit on which is described in 688 Section 3.1.2. 690 3.1.1. RobE_eSIM implicit Negotiation and Procedure 692 Similar to RobE_SIM in Section 2.2, the establishment process of 693 [RFC6824] or [RFC8684] is applied independently on multiple paths 694 simultaneously. In Figure 11 this is shown in SA1 and SA2. The 695 first path which returns a SYN/ACK (e.g. SA3) is selected as the 696 initial path and proceeds with the traditional establishment process 697 (SA5). Any other path which has to send the final ACK of the 3-way 698 handshake includes a new option MP_JOIN_CAP (see definition in 699 Section 3.1.3.2) instead of an MP_CAPABLE (SA6.2). 701 Host A Host B 702 ------------------------ ---------- 703 Address A1 Address A2 Address B1 704 ---------- ---------- ---------- 705 | | | 706 | SYN + MP_CAPABLE(Key-A[*]) | 707 (SA1) |--------------------------------------------->| (SB1) 708 | | SYN + MP_CAPABLE(Key-A'[*]) | 709 (SA2) | |------------------------------->| (SB2) 710 | | | 711 (SA3) |<---------------------------------------------| (SB3) 712 | SYN/ACK + MP_CAPABLE(Key-B) | 713 (SA4) | |<-------------------------------| (SB4) 714 | | SYN/ACK + MP_CAPABLE(Key-B') | 715 | | | 716 | ACK + MP_CAPABLE(Key-A, Key-B) | 717 (SA5) |--------------------------------------------->| (SB5) 718 | | | 719 (SA6.2) | | | (SB6.2) 720 RobE EXT | | ACK + MP_JOIN_CAP(Key-A, HMAC) | 721 (+fast) | |------------------------------->| 723 [*] Key-A in the first MP-capable is related to 724 RFC6824 only and does not exist in RFC8684. 726 Figure 11: MPTCP RobE_eSIM implicit Connection Setup 728 Following the possible process in Figure 11, two further 729 constellations are imaginable and elaborated below. 731 1. In the flow diagram Figure 11, A1<->B1 is assumed to be the 732 initial flow. A2<->B1 shall be recycled and the ACK is sent with 733 MP_JOIN_CAP. Furthermore, the MP_CAPABLE arrives first at Host B 734 (SB5) and the MP_JOIN_CAP afterwards (SB6.2). When the 735 MP_JOIN_CAP is received, Host B has to iterate over the 736 connection list once (like MP_JOIN) and check for Key-A 737 availability. If a Key-A connection is found, this one is 738 validated against the HMAC value. The validation has two 739 reasons: first, several Key-A can exist, because different hosts 740 may choose the same Key-A by accident. Furthermore, no one can 741 join a connection by just recording/brute-forcing Key-A and 742 duplicating the request. 744 2. Like above, but MP_JOIN_CAP arrives before last MP_CAPABLE at 745 Host B 747 * [RFC8684]; Based on Key-A, Host B will iterate over the 748 connection list, but it will not find a match, because Key-A 749 of the previous selected initial flow (SA3, SA5) has not 750 arrived yet. So it will continue with a fast iteration only 751 over the connections which are still in establishment phase 752 using the 10 bit Key-B fast hash (crc16(Key-B) & 0x3FF). If 753 it matches against a (precomputed) existing Key-B_fast_hash in 754 the connection list, it will validate the request using the 755 HMAC(Key-A+B+B') to ensure legitimation. If successful, both, 756 the initial flow and the MP_JOIN_CAP flow, can be immediately 757 established. This is true, because without the knowledge of 758 Key-B, Host A could not calculate the HMAC. So it is clear, 759 that Host A had received the SYN/ACK (SB3). This also 760 mitigates the exchange of a reliable ACK during the handshake 761 process. MPTCP sends the Key-A only with the last ACK and 762 therefore prevents subsequent flow establishment until 763 successful reception at Host B. Using RobE_EXT, the reception 764 of an MP_JOIN_CAP ([RFC8684]) is sufficient to establish both, 765 the path carrying Key-B and Key-B'. 767 * [RFC6824]; Can match based on Key-A, same effort as for an 768 MP_JOIN. 770 3. A2<->B1 is selected as initial flow, because the respective SYN/ 771 ACK returns earlier at Host A. It is the same as above, just the 772 other way round. 774 3.1.2. RobE_eSIM explicit Negotiation and Procedure 776 The process of an explicit negotiation of RobE_eSIM follows Figure 11 777 but uses the ROBE_eSIM_EN option Figure 13 additionally during the 778 handshake procedure. 780 Host A Host B 781 ------------------------ ---------- 782 Address A1 Address A2 Address B1 783 ---------- ---------- ---------- 784 | | | 785 | SYN+MP_CAPABLE+ROBE_eSIM_EN(Key-A[*]) | 786 |----------------------------------------------------->| 787 | | SYN+MP_CAPABLE+ROBE_eSIM_EN(Key-A'[*]) | 788 | |--------------------------------------->| 789 | SYN/ACK+MP_CAPABLE+ROBE_eSIM_EN(Key-B) | 790 |<---------------------------------------------------->| 791 | | SYN/ACK+MP_CAPABLE+ROBE_eSIM_EN(Key-B')| 792 | |<---------------------------------------| 793 | ACK+MP_CAPABLE(Key-A,Key-B) | 794 |----------------------------------------------------->| 795 | | | 796 | | ACK+MP_JOIN_CAP(Key-A,HMAC) | 797 | |--------------------------------------->| 798 | | | 800 [*] Key-A in the first MP-capable is related to 801 RFC6824 only and does not exist in RFC8684. 803 Figure 12: MPTCP RobE_eSIM explicit Connection Setup 805 3.1.3. Protocol Adaptation 807 3.1.3.1. ROBE_eSIM_EN Option 809 1 2 3 810 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 811 +---------------+---------------+-------+-------+---------------+ 812 | Kind | Length |Subtype| (reserved) | 813 +---------------+---------------+-------+-------+---------------+ 815 Figure 13: ROBE_eSIM_EN_OPTION 817 3.1.3.2. MP_JOIN_CAP Option 818 1 2 3 819 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 820 +---------------+---------------+-------+-------+---------------+ 821 | Kind | Length |Subtype| | ADDR_ID | 822 +---------------+---------------+-------+-------+---------------+ 823 | Sender's Key-A (64 bits) | 824 | | 825 | | 826 +---------------------------------------------------------------+ 827 | HMAC (>=96 bits) | 828 | | 829 | | 830 : : 831 +---------------------------------------------------------------+ 832 Key-B_fast_hash = crc16(Key-B) & 0x3FF -> (10bit) 833 HMAC_keys = HMAC(Key-A+Key-B+Key-B') -> (>=96bit) 834 HMAC = (HMAC_keys & ~0x3FF) | Key-B_fast_hash -> (size HMAC_keys) 836 Figure 14: MP_JOIN_CAP 838 Computational effort on receiver side is most often expected to be 839 the same as with MP_JOIN. Key-A ensures identification of related 840 flows Key-B_fast_hash enables MP session even when selected initial 841 flow is not fully established yet (slight computational overhead). 842 HMAC authenticates relationship of initial and potential initial 843 flows. 845 3.1.4. Fallback Mechanisms 847 3.1.4.1. Fallback mechanism for implicit RobE_eSIM 849 [TBD] 851 3.1.4.2. Fallback mechanism for explicit RobE_eSIM 853 This mechanism considers that both sides support MPTCP capability but 854 the receiver is not equipped with RobE_eSIM. MPTCP session with 855 RobE_eSIM negotiation will seamlessly fallback to normal MPTCP 856 process. 858 [Requires further check how an unaware Host B reacts on possible 859 ROBE_eSIM_EN; Ignore or RST? See also RFC6824 Sec. 3.6 "Should 860 fallback [...] the path does not support the MPTCP options"] 861 Host A Host B 862 ------------------------ ---------- 863 Address A1 Address A2 Address B1 864 ---------- ---------- ---------- 865 | | | 866 | SYN+MP_CAPABLE+ROBE_eSIM_EN | 867 |------------------------------------------>| 868 | | SYN+MP_CAPABLE+ROBE_eSIM_EN | 869 | |---------------------------->| 870 | SYN/ACK+MP_CAPABLE | 871 |<----------------------------------------->| 872 | | SYN/ACK+MP_CAPABLE | 873 | |<----------------------------| 874 | ACK+MP_CAPABLE | 875 |------------------------------------------>| 876 | | RST | 877 | |---------------------------->| 878 | | SYN+MP_JOIN | 879 | |---------------------------->| 880 | | MP_JOIN Process... | 881 | | | 883 Figure 15: Fallback to MPTCP when missing RobE_eSIM support 885 3.1.4.3. Fallback to regular TCP when missing MPTCP support 887 When the receiver is not MPTCP enabled, MPTCP session with RobE_eSIM 888 negotiation will seamlessly fallback to regular process which is 889 illustrated in this section. 891 Host A Host B 892 ------------------------ ---------- 893 Address A1 Address A2 Address B1 894 ---------- ---------- ---------- 895 | | | 896 | SYN+MP_CAPABLE+ROBE_eSIM_EN | 897 |------------------------------------------>| 898 | | SYN+MP_CAPABLE+ROBE_eSIM_EN | 899 | |---------------------------->| 900 | SYN/ACK | 901 |<----------------------------------------->| 902 | | SYN/ACK | 903 | |<----------------------------| 904 | ACK | 905 |------------------------------------------>| 906 | | RST | 907 | |---------------------------->| 908 | | Regular TCP Process... | 909 | | | 911 Figure 16: Fallback to TCP without MPTCP support 913 3.1.5. Comparison Robe_SIM and RobE_eSIM 915 Potential initial flows in RobE_SIM Section 2.2 and RobE_eSIM 916 Section 3.1 guarantee MPTCP session establishment if at least one 917 selected path for session establishment is functional. Figure 17 918 makes the differences between both approaches visible and points to 919 the latest decision possibility during session setup when RobE_SIM or 920 RobE_eSIM can be selected. Until SA5 in Figure 17 traditional MPTCP 921 connection setup is independently applied on multiple paths 922 simultaneously and offers to select the initial flow later (potential 923 initial flows). The final decision which path is selected as the 924 main one and the handling of the remaining flow(s) differs in SA6.1 925 when RobE_SIM is applied or instead SA6.2 RobE_eSIM. 927 Host A Host B 928 ------------------------ ---------- 929 Address A1 Address A2 Address B1 930 ---------- ---------- ---------- 931 | | | 932 | SYN + MP_CAPABLE(Key-A[*]) | 933 (SA1) |--------------------------------------------->| (SB1) 934 | | SYN + MP_CAPABLE(Key-A'[*]) | 935 (SA2) | |------------------------------->| (SB2) 936 | | | 937 (SA3) |<---------------------------------------------| (SB3) 938 | SYN/ACK + MP_CAPABLE(Key-B) | 939 (SA4) | |<-------------------------------| (SB4) 940 | | SYN/ACK + MP_CAPABLE(Key-B') | 941 | | | 942 | ACK + MP_CAPABLE(Key-A, Key-B) | 943 (SA5) |--------------------------------------------->| (SB5) 944 | | RST | 945 (SA6.1) | |------------------------------->| (SB6.1) 946 RobE SIM | | | 947 (robust) | | | 948 ------------------------------------------------------------------- 949 RobE EXT | | | 950 (+fast) | | ACK + MP_JOIN_CAP(Key-A, HMAC) | 951 (SA6.2) | |------------------------------->| (SB6.2) 953 [*] Key-A in the first MP-capable is related to 954 RFC6824 only and does not exist in RFC8684. 956 Figure 17: MPTCP RobE_SIM and RobE_eSIM connection setup 958 3.1.6. Security Consideration 960 [Tbd, however no differences to [RFC6824] and [RFC8684] are expected] 962 3.2. Heuristic Initial Path Selection with remote RTT Measurement 964 3.2.1. Description 966 Usually the path RTT can be determined by a time difference between 967 sending a package and receiving an ACK and is integrated into the TCP 968 protocol. For asymmetric transmission, the latest RTT for TCP flows 969 is calculated by the side which sends data at latest and possible 970 does not correspond to the site which employs RobE_IPS. This problem 971 is already elaborated in Section 2.3.4 and can be solved by 972 transmitting the RTT information per subflow. The negotiation 973 procedure is depicted in Figure 18 and uses the MPTCP option L_RTT_EN 974 defined in Section 3.2.2. 976 Host A Host B 977 ------------------------ ---------- 978 Address A1 Address A2 Address B1 979 ---------- ---------- ---------- 980 | | | 981 | SYN+MP_CAPABLE+L_RTT_EN | 982 |------------------------------------------>| 983 | SYN/ACK+MP_CAPABLE+L_RTT_EN | 984 |<------------------------------------------| 985 | ACK+MP_CAPABLE | 986 |------------------------------------------>| 987 | ACK+DSS+L_RTT_EN(latest RTT)+Data | 988 |<------------------------------------------| 989 | | SYN+MP_JOIN | 990 | |---------------------------->| 991 | | MP_JOIN Process... | 992 | | | 994 Figure 18: Negotiation procedure for RTT exchange 996 A successful negotiation allows the exchange of the measured RTT 997 value from one subflow of an MPTCP host to another using the "Latest 998 RTT" field within the L_RTT_EN option. 1000 3.2.2. Protocol Adaptation 1002 Calculating the "Latest RTT" by a remote host in an asymmetry 1003 transmission scenario should be transferred from remote host to the 1004 client running RobE_IPS. So a new MPTCP subtype option named 1005 L_RTT_EN is allocated for this function. During the three-way 1006 handshake L_RTT_EN is used for negotiation of remote RTT measurement 1007 capability between client and server (in Section 3.2.1). When both 1008 parts support the usage of remote RTT measurement, the "Latest RTT" 1009 field in L_RTT_EN is applied for carrying the value of latest RTT 1010 computed by the remote host. 1012 1 2 3 1013 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 1014 +---------------+---------------+-------+-------+---------------+ 1015 | Kind | Length |Subtype| (reserved) | 1016 +---------------+---------------+-------+-------+---------------+ 1017 | Latest RTT (32 bits) | 1018 | | 1019 | | 1020 +---------------------------------------------------------------+ 1022 Figure 19: ROBE_L_RTT_EN OPTION 1024 3.2.3. Fallback Mechanism 1026 When the receiver is not L_RTT_EN capable, MPTCP session with 1027 L_RTT_EN negotiation will seamlessly fallback to normal MPTCP 1028 process. 1030 [TBD, Need same checks as Section 3.1.4.2] 1032 Host A Host B 1033 ------------------------ ---------- 1034 Address A1 Address A2 Address B1 1035 ---------- ---------- ---------- 1036 | | | 1037 | SYN+MP_CAPABLE+L_RTT_EN | 1038 |------------------------------------------>| 1039 | SYN/ACK+MPTCP_CAPABLE | 1040 |<------------------------------------------| 1041 | ACK+MPTCP_CAPABLE | 1042 |------------------------------------------>| 1043 | | SYN+MP_JOIN | 1044 | |---------------------------->| 1045 | | MP_JOIN Process... | 1046 | | | 1048 Figure 20: Fallback to MPTCP without RobE_IPS 1050 3.2.4. Security Consideration 1052 [Tbd] 1054 4. IANA Considerations 1056 This document defines three new values to MPTCP Option Subtype as 1057 following. 1059 +=======+==============+=======================+=============+ 1060 | Value | Symbol | Name | Reference | 1061 +=======+==============+=======================+=============+ 1062 | TBD | ROBE_eSIM_EN | RobE_eSIM enabled | Section 3.1 | 1063 +-------+--------------+-----------------------+-------------+ 1064 | TBD | MP_JOIN_CAP | Join connection | Section 3.1 | 1065 | | | directly in RobE_eSIM | | 1066 +-------+--------------+-----------------------+-------------+ 1067 | TBD | L_RTT_EN | Server RTT enabled | Section 3.2 | 1068 +-------+--------------+-----------------------+-------------+ 1070 Table 2: RobE Option Subtypes 1072 5. References 1074 5.1. Normative References 1076 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1077 RFC 793, DOI 10.17487/RFC0793, September 1981, 1078 . 1080 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 1081 "TCP Extensions for Multipath Operation with Multiple 1082 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 1083 . 1085 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 1086 Paasch, "TCP Extensions for Multipath Operation with 1087 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 1088 2020, . 1090 5.2. Informative References 1092 [RobE_paper] 1093 Amend, M., Rakocevic, V., Matz, A.P., and E. Bogenfeld, 1094 "RobE: Robust Connection Establishment for Multipath TCP", 1095 ANRW '18 p. 76-82, 16 July 2018, 1096 . 1098 [RobE_slides] 1099 Amend, M., Matz, A.P., and E. Bogenfeld, "A proposal for 1100 MPTCP Robust session Establishment (MPTCP RobE)", IETF 1101 99 Multipath TCP WG session, 18 July 2017, 1102 . 1106 Authors' Addresses 1108 Markus Amend 1109 Deutsche Telekom 1110 Deutsche-Telekom-Allee 9 1111 64295 Darmstadt 1112 Germany 1114 Email: Markus.Amend@telekom.de 1116 Jiao Kang 1117 Huawei 1118 D2-03,Huawei Industrial Base 1119 Shenzhen 1120 Guangdong, 518129 1121 China 1123 Email: kangjiao@huawei.com