idnits 2.17.1 draft-amend-iccrg-multipath-reordering-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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-amend-tsvwg-multipath-dccp-03 == Outdated reference: A later version (-02) exists of draft-bonaventure-iccrg-schedulers-01 == Outdated reference: A later version (-07) exists of draft-deconinck-quic-multipath-05 == Outdated reference: A later version (-08) exists of draft-huitema-quic-ts-03 == Outdated reference: A later version (-10) exists of draft-ietf-quic-datagram-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-32 == Outdated reference: A later version (-14) exists of draft-zhu-intarea-gma-07 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICCRG Working Group M. Amend 3 Internet-Draft D. von Hugo 4 Intended status: Experimental DT 5 Expires: 6 May 2021 2 November 2020 7 Multipath sequence maintenance 8 draft-amend-iccrg-multipath-reordering-01 10 Abstract 12 This document discusses the issue of packet re-ordering which occurs 13 as a specific problem in multi-path connections without reliable 14 transport protocols such as TCP. The topic is relevant for devices 15 connected via multiple accesses technologies towards the network as 16 is foreseen e.g. within Access Traffic Selection, Switching, and 17 Splitting (ATSSS) service of 3rd Generation Partnership Project 18 (3GPP) enabling fixed mobile converged (FMC) scenario. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 6 May 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. State of the Art . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Scheduling mechanisms . . . . . . . . . . . . . . . . . . . . 6 57 5. Resequencing mechanisms . . . . . . . . . . . . . . . . . . . 7 58 5.1. Passive . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 5.2. Exact . . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 5.3. Static Expiration . . . . . . . . . . . . . . . . . . . . 8 61 5.4. Adaptive Expiration . . . . . . . . . . . . . . . . . . . 8 62 5.5. Delay Equalization . . . . . . . . . . . . . . . . . . . 8 63 5.6. Fast Packet Loss Detection . . . . . . . . . . . . . . . 9 64 5.6.1. Connection sequencing . . . . . . . . . . . . . . . . 9 65 5.6.2. Per-path sequencing . . . . . . . . . . . . . . . . . 9 66 5.6.3. Combination connection and per-path sequencing . . . 9 67 6. Recovery mechanisms . . . . . . . . . . . . . . . . . . . . . 9 68 6.1. FEC (Forward Error Correction) . . . . . . . . . . . . . 9 69 6.2. Network Coding . . . . . . . . . . . . . . . . . . . . . 10 70 7. Retransmission mechanisms . . . . . . . . . . . . . . . . . . 10 71 7.1. Signalling . . . . . . . . . . . . . . . . . . . . . . . 10 72 7.2. Anticipated . . . . . . . . . . . . . . . . . . . . . . . 10 73 7.3. Flow-selection . . . . . . . . . . . . . . . . . . . . . 11 74 8. Informative References . . . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 Mobile end user devices nowadays are mostly equipped with multiple 80 network interfaces allowing to connect to more than one network at a 81 time and thus increase data throughput, reliability, coverage and so 82 on. Ideally the user data stream originating from the application at 83 the device is split between the available (here: N) paths at the 84 sender side and re-assembled at an intermediate aggregation node 85 before transmitted to the corresponding host in the network as 86 depicted in Figure 1. 88 ------------ 89 / \ 90 +---------| Access Net 1 |--+ 91 | \ / | 92 | ------------- | 93 | ------------ | 94 | / \ | 95 | +------| Access Net 2 |-+ | 96 | | \ / | | 97 | | ------------ | | 98 | | | | 99 | | | | 100 | | +-------+-+---+ 101 +--+-+-+ | | +------+ 102 |End | | Aggregation +----/.../--| Host | 103 |User | | Node | +------+ 104 |Device| | | 105 +--+-+-+ +-------+-+---+ 106 | | | | 107 | | -------------- | | 108 | | / \ | | 109 | +---| Access Net N-1 |--+ | 110 | \ / | 111 | -------------- | 112 | | 113 | ------------ | 114 | / \ | 115 +--------| Access Net N |---+ 116 \ / 117 ------------ 119 Figure 1: Reference Architecture for multi-path re-ordering 121 However, when several paths are utilized concurrently to transmit 122 user data between the sender and the receiver, different 123 characteristics of the paths in terms of bandwidth, delay, or error 124 proneness can impact the overall performance due to delayed packet 125 arrival and need for re-transmit in case of lost packets. Without 126 further arrangements the original order of packets at the sending UE 127 side is no longer maintained at the receiving host and a re-ordering 128 or re-arrangement has to occur before delivery to the application at 129 the far end site. This can be performed at earliest at the 130 aggregation node with a minimum additional delay due to re- 131 transmission requests or at latest either by the application on the 132 host itself or the transmission protocol. 134 It is a goal of the present document to collect and describe 135 mechanisms to maintain the sequence of split traffic over multiple 136 paths. These mechanisms are generic and not dedicated to a specific 137 multipath network protocol, but give clear guidance on requirements 138 and benefits to maintainers of multipath network protocols. 140 2. State of the Art 142 Regular TCP protocol [RFC0793] offers such mechanism with queues for 143 in-order and out-of order (including damaged, lost, duplicated) 144 arrival of packets. 146 This is also provided by MPTCP [RFC6824] as the first and successful 147 Multipath protocol which however also requires new methods as 148 sequence numbers both on (whole) data (stream) and subflow level to 149 ensure in-order delivery to the application layer on the receiver 150 side [RFC8684]. Moreover, careful design of buffer sizes and 151 interpretation of sequence numbers to distinguish between (delayed) 152 out-of-order packets and completely lost ones has to be considered. 154 [I-D.bonaventure-iccrg-schedulers] already reflects on proper packet 155 scheduling schemes (at the sender side) to reduce the effort for re- 156 assembly or even make such (time consuming) treatment unnecessary. 158 MP-QUIC [I-D.deconinck-quic-multipath] introduces the concept of 159 uniflows with own IDs claiming to get rid of additional sequence 160 numbers for re-ordering as required in Multipath TCP [RFC6824]. 161 Although [] admits that statistical performance information should 162 help a host in deciding on optimum packet scheduling and flow control 163 a dedicated packet scheduling policy is out of scope of that 164 document. A further improvement versus MPTCP can be achieved by 165 decoupling paths used for data transmission from those for sending 166 acknowledgments (ACKs) or claiming for re-transmission by NACKs to 167 not introduce further latency. 169 [I-D.ietf-quic-recovery] specifies algorithms for QUIC Loss Detection 170 and Congestion Control by using measurement of Round Trip Time (RTT) 171 to determine when packets should be retransmitted. Draft 172 [I-D.huitema-quic-ts] proposes to enable one way delay (1WD) 173 measurements in QUIC by defining a TIME_STAMP frame to carry the time 174 at which a packet is sent and combine the ACKs sent with a timestamp 175 field and thus allow for more precise estimation of the (one-way) 176 delay of each uniflow, assisting proper scheduling decisions. 178 Also other protocols as Multi-Access Management Services (MAMS) 179 [RFC8743] consider the need for re-ordering on User Plane level which 180 may be done at network and client level by introducing a new Multi- 181 Access (MX) Convergence Layer. [I-D.zhu-intarea-mams-user-protocol] 182 introduces accordingly Traffic Splitting Update (TSU) messages and 183 Packet Loss Report (PLR) messages including beside others Traffic 184 Splitting Parameters and an expected next (in-order) sequence number, 185 respectively. 187 [I-D.zhu-intarea-gma] on Generic Multi-Access (GMA) Convergence 188 Encapsulation Protocols introduces a trailer-based encapsulation 189 which carries one or multiple IP packets or fragments thereof in a 190 Protocol Data Unit (PDU). At receiver side PDUs with identical 191 Sequence Numbers (in the trailer) are to be placed in the relative 192 order indicated by a so-called Fragment Offset. 194 3. Problem Statement 196 Assuming for simplicity the minimum multipath scenario with two 197 separate paths for transmission of a flow of packets with sequence 198 numbers (SN) SN1 ... SM. In case the scheduling of packets is done 199 equally to both paths and path 2 exhibits a delay of the duration of 200 transmission time required for e.g. two packets (assuming fixed 201 packet size and same constant data for both paths) for an exemplary 202 App-originated sequence of packets as SN1 SN2 SN3 SN4 SN5 SN6 SN7 SN8 203 ... the resulting sequence of packets could look as depicted in 204 Figure 2 which of course depends on the queue processing and 205 buffering at the Aggregation Proxy. 207 APP UE Aggregation Node Host 208 | SN1 ... SN8 | | | 209 |-------------->|path 1 SN1 SN3 SN5 SN7...| | 210 | |------------------------>| | 211 | |path 2 SN2 SN4 SN6 SN8...| | 212 | |------------------------>| | 213 | | |SN1 SN3 SN2 SN5 SN4 SN7| 214 | | |======================>| 215 | | | | 217 Figure 2: Exemplary data transmission for a dual-path scenario 219 In such a case re-ordering at the Aggregation Node would be simple 220 and straight forward. It even could be avoided if the scheduling 221 would already take the expected different delays into account (e.g. 222 by pre-delaying the traffic on path 1 thus of course not leveraging 223 the lower delay). Different from this simplistic scenario in general 224 the data rate on both paths will vary in time and be not equal, also 225 different and variable latency (jitter) per path will be introduced 226 and in addition loss of packets as well as potential duplication may 227 occur making the situation much more complicated. In case of loss 228 detection after a threshold waiting time a retransmission could be 229 initiated by the Host or if possible already by the Aggregation Node. 231 Alternatively the UE could send redundant packets in advance coded in 232 such a way that it allows for derivation of e.g. one lost packet per 233 M correctly received ones or by a (real-time) application able to 234 survive singular lost packets. 236 Holding multiple queues and a large enough buffer both at UE and at 237 the Aggregation Node would be required to apply proper scheduling at 238 UE and reordering during re-assembly at Aggregation Node to mitigate 239 the sketched impact of multiple paths variable characteristics in 240 terms of transmission performance. 242 ... 244 4. Scheduling mechanisms 246 Scheduling mechanisms decide on sender side how traffic is 247 distributed over the paths of a multipath-setup. 248 [I-D.bonaventure-iccrg-schedulers] gives an overview of possible 249 distribution schemes. For this document it is assumed, that 250 schedulers are used, which simultaneously distribute traffic over 251 more than one path, whereas path characteristics differ between those 252 multiple paths (e.g. a latency difference exists). While on the one 253 hand, the traffic scheduling causes out-of-order multipath delivery 254 when simultaneously utilize heterogeneous paths, it can also be used 255 to mitigate this problem. Pre-delaying data on a fast path, 256 according to the latency difference of the slowest path is aimed e.g. 257 by OTIAS [OTIAS], DAPS [DAPS] and BLEST [BLEST]. However, the 258 success is much dependent on the accuracy of path information like 259 path latency, throughput and packet loss rate. In heterogeneous and 260 volatile environments most often such information have to be 261 estimated, e.g. using congestion control. That means, it takes at 262 least one RTT to gain first indications and probably several RTTs to 263 converge to a worthwhile accuracy. Changes of path characteristics 264 in sub-RTT time frames puts such a system to test. Dependent on the 265 demand on in-order delivery and/or the accuracy of the relevant path 266 information, scheduling might be an exclusive alternative or can be 267 applied in conjunction with other discussed mechanisms in this 268 document. 270 Scheduling will not help to overcome any degree of out-of-order 271 delivery, when the scheduling goal is different to this. For example 272 a strict cost prioritization of Wi-Fi over cellular access in a 273 mobile phone might be assumed counterproductive. 275 5. Resequencing mechanisms 277 Resequencing mechanism are responsible to modify the sequence of 278 received data split over multiple paths according to a sequencing 279 scheme. The degree of resequencing can reach from no measure up to 280 re-generating the exact order. 282 Typically at least one sequencing scheme, describing the order of how 283 data was generated on sender side is prerequisite. This is referred 284 to as "connection sequencing". Under certain circumstances an 285 additional sequencing scheme per path of the multi-path setup can be 286 leveraged, to optimize packet loss detection and is further 287 elaborated in Section 5.6. For most multipath protocols both 288 sequencing schemes are already available. Packet loss detection 289 becomes important when multipath protocols are applied which do not 290 guarantee successful transmission as TCP achieves by acknowledgement 291 of successful reception. For example 292 [I-D.amend-tsvwg-multipath-dccp] or the combination of 293 [I-D.deconinck-quic-multipath] and [I-D.ietf-quic-datagram] are 294 unreliable protocols in that sense. 296 For simplicity all the mechanism described in the following are 297 explained based on two paths but in principle would work with an 298 unlimited number though. 300 5.1. Passive 302 This approach includes no active change or reordering at the 303 transport level and purely re-combines the packet flows incoming from 304 both paths as is. All modification of the resulting sequence of 305 packets is left to the application at the end node. Here no 306 processing delay is added due to the resequencing but since no early 307 packet loss detection with subsequent re-transmission request on 308 transport level is possible the risk of a larger delay due to late 309 loss detection at the application will arise in case of lossy 310 connections. 312 5.2. Exact 314 This approach covers all mechanisms which attempt to re-generate the 315 original order of packets in the flow exactly, independent of the 316 expected or resulting delay due to waiting time for all packets on 317 all paths to arrive. In case of unreliable transport protocols this 318 may result in a large delay due to Head-of-Line blocking and for 319 actual packet loss in a remaining packet gap which causes a stand 320 still without an option to recover. For applications demanding near 321 real-time delivery of packets it should not be applied. 323 5.3. Static Expiration 325 This method to detect and decide on packet loss assumes a certain 326 fixed time threshold for the gap between packets within a sequence 327 after re-combination of both paths. Since a possible re-transmission 328 - either in the multipath system internal or based on the piggybacked 329 protocol/service - will possibly not be requested before this 330 threshold an additional delay in the overall latency budget this 331 simple approach is only recommended for non-time critical 332 applications. Every packet loss or simultaneous transmission of data 333 over the short and long latency path will cause spikes in the service 334 perceived latency. 336 5.4. Adaptive Expiration 338 Here the packet gap is assumed as packet loss after exceeding a 339 flexibly decided on time threshold which may be derived dynamically 340 from the differences between latencies both paths exhibit. As the 341 latency may vary due to propagation conditions or routing paths this 342 latency difference has to be monitored and statistically evaluated 343 (smoothed) which introduces additional effort. A possible solution 344 for this is the determination of the the one way latency as described 345 in [I-D.song-mptcp-owl] or sending available RTT information from the 346 sender from which the receiver can calculate the latency difference. 348 5.5. Delay Equalization 350 This is an ordering mechanism which delays data forwarding on the 351 faster path by the latency difference to the slower path. Ideally 352 the resequencing effort on the aggregated packet flow can be greatly 353 reduced up to no resequencing at all. Due to time variation in path 354 delays (jitter) and delay differences and required time for decision 355 and feedback on the delay some re-sequencing still remains to be 356 executed. Similar to Section 5.4, the latency difference is 357 required. Strictly speaking this method allows to avoid resequencing 358 based on sequencing information. However, the overall delay may be 359 larger since the advantage of the short-delay path is not exploited. 360 In combination with Section 5.3 or Section 5.4 resequencing can be 361 added with a presumably lower resequencing effort to scenarios 362 without delay equalization. The essence is a in-order stream with a 363 unified latency across the multiple paths. 365 5.6. Fast Packet Loss Detection 367 The following sections describe methods to achieve unambiguous 368 detection of packet loss independent from thresholds in Section 5.3 369 or Section 5.4. Furthermore, packet loss can be differentiated from 370 delayed delivery. The benefit is a much faster decision plane based 371 on monitoring the sequence space of consecutive packets. For that, 372 the sequencing coming along with the receiver based re-sequencing is 373 further leveraged. Two sequencing schemes are considered here, the 374 connection and the per-path sequencing. 376 5.6.1. Connection sequencing 378 Connection sequencing marks the outgoing packets in the order they 379 enter the multipath system and is independent from a particular 380 selected path for transmission. [to be continued...] 382 5.6.2. Per-path sequencing 384 Per-path sequencing is a path inherent sequencing mechanism valid in 385 the particular path domain only. [to be continued...] 387 5.6.3. Combination connection and per-path sequencing 389 While the benefits from the individual sequencing schemes above can 390 be combined, a further benefit crystallizes. [to be continued...] 392 6. Recovery mechanisms 394 Recovering packets, in particular lost packets or assumed lost 395 packets on receiver side avoids re-transmission and potentially 396 mitigates the resequencing process in respect to detecting packet 397 loss. Shorter latencies will be an expected outcome. Discussing the 398 complexity, computation overhead and reachable benefit is subject of 399 this section. 401 6.1. FEC (Forward Error Correction) 403 This approach is based on introduction of redundancy to user data to 404 detect errors and subsequently reconstruct data in case of a limited 405 number of bit or Byte errors. As such packet with corrupted data can 406 be recovered up to a certain degree but in case of a too high bit 407 error rate (BER) a packet is completely lost. However, in 408 combination with scrambling, i.e. the sequence of original data 409 stream is distributed over multiple packets and re-compiled 410 afterwards also data from lost packets could be recovered. As such 411 methods introduce additional delay and overhead it is mainly applied 412 in case of long re-transmission delays as e.g. is typical for 413 satellite transmission. FEC can be applied to each path separately 414 (e.g., if they exhibit deviating performance characteristics to not 415 degrade the 'better one') or in an overall FEC fashion before split 416 and recombination which would support scrambling and facilitate 417 recovery of completely lost packets on the 'worse path'. 418 Unsuccessful application of FEC may enable quick detection of 419 unrecoverable errors in a packet and thus trigger re-transmission 420 from the sender side before time-out. 422 6.2. Network Coding 424 In linear network coding (LNC) network nodes (or interfaces of a 425 device) do not simply relay the packets of information they receive, 426 but combine several packets together for transmission. After 427 reception of combined and separate packets the maximum possible 428 information flow in a network can be detected and throughput, 429 efficiency and scalability, as well as resilience to attacks and 430 eavesdropping can be improved. The method in general improves with 431 the number of paths in excess of two. According to [wikipedia] 432 drawback of LNC are high decoding computational complexity, high 433 transmission overhead, and linear dependency among coefficients 434 vectors for en- and decoding. Triangular network coding (TNC) 435 addresses the high encoding and decoding computational complexity 436 without degrading the throughput performance, with code rate 437 comparable to that of linear network coding. 439 7. Retransmission mechanisms 441 Re-transmission becomes interesting when it can help to reduce the 442 time spent on waiting for outstanding packets for re-sequencing. In 443 particular scenarios when for example a known path RTT (Round Trip 444 Time) lets expect a shorter time to re-transmit than wait for packet 445 loss detection, a likely scenario in e.g. Figure 1. It could also 446 avoid a potential late triggering of re-transmission by the end-to- 447 end service. 449 7.1. Signalling 451 Signal to the sender to re-transmit a missing packet. This requires 452 a send buffer which keeps information for a reasonable time, which 453 allows the beneficial use of this mechanism. [to be continued] 455 7.2. Anticipated 457 Re-transmit data without being notified from the receiver when packet 458 loss can be assumed, e.g. from lower layer information. [to be 459 continued] 461 7.3. Flow-selection 463 Repeating data on the same path is not always useful. In some 464 scenarios it make sense to re-transmit data on another path, e.g. 465 when the original path is broken or another path is known to be 466 faster. 468 * Requires path independent identification of data, e.g. the 469 connection sequencing 471 * Has to consider MTU discrepancies between paths 473 Flow selection for re-transmitting data can be combined with 474 Section 7.1 or Section 7.2. In certain scenarios data to be re- 475 transmitted can be duplicated across paths to increase reliability. 476 [to be continued] 478 8. Informative References 480 [BLEST] Ferlin, S., Alay, Oe., Mehani, O., and R. Boreli, "BLEST: 481 Blocking estimation-based MPTCP scheduler for 482 heterogeneous networks", IFIP Networking Conference , May 483 2014, 484 . 486 [DAPS] Kuhn, N., Lochin, E., Mifdaoui, A., Sarwar, G., Mehani, 487 O., and R. Boreli, "DAPS: Intelligent delay-aware packet 488 scheduling for multipath transport", ICC IEEE 489 International Conference on Communications, June 2014, 490 . 492 [I-D.amend-tsvwg-multipath-dccp] 493 Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and 494 V. Rakocevic, "DCCP Extensions for Multipath Operation 495 with Multiple Addresses", Work in Progress, Internet- 496 Draft, draft-amend-tsvwg-multipath-dccp-03, 4 November 497 2019, . 500 [I-D.bonaventure-iccrg-schedulers] 501 Bonaventure, O., Piraux, M., Coninck, Q., Baerts, M., 502 Paasch, C., and M. Amend, "Multipath schedulers", Work in 503 Progress, Internet-Draft, draft-bonaventure-iccrg- 504 schedulers-01, 9 September 2020, . 508 [I-D.deconinck-quic-multipath] 509 Coninck, Q. and O. Bonaventure, "Multipath Extensions for 510 QUIC (MP-QUIC)", Work in Progress, Internet-Draft, draft- 511 deconinck-quic-multipath-05, 20 August 2020, 512 . 515 [I-D.huitema-quic-ts] 516 Huitema, C., "Quic Timestamps For Measuring One-Way 517 Delays", Work in Progress, Internet-Draft, draft-huitema- 518 quic-ts-03, 10 August 2020, . 521 [I-D.ietf-quic-datagram] 522 Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable 523 Datagram Extension to QUIC", Work in Progress, Internet- 524 Draft, draft-ietf-quic-datagram-01, 24 August 2020, 525 . 528 [I-D.ietf-quic-recovery] 529 Iyengar, J. and I. Swett, "QUIC Loss Detection and 530 Congestion Control", Work in Progress, Internet-Draft, 531 draft-ietf-quic-recovery-32, 20 October 2020, 532 . 535 [I-D.song-mptcp-owl] 536 Song, F., Zhang, H., Chan, A., and A. Wei, "One Way 537 Latency Considerations for MPTCP", Work in Progress, 538 Internet-Draft, draft-song-mptcp-owl-06, 18 June 2019, 539 . 542 [I-D.zhu-intarea-gma] 543 Zhu, J. and S. Kanugovi, "Generic Multi-Access (GMA) 544 Encapsulation Protocol", Work in Progress, Internet-Draft, 545 draft-zhu-intarea-gma-07, 14 May 2020, 546 . 549 [I-D.zhu-intarea-mams-user-protocol] 550 Zhu, J., Seo, S., Kanugovi, S., and S. Peng, "User-Plane 551 Protocols for Multiple Access Management Service", Work in 552 Progress, Internet-Draft, draft-zhu-intarea-mams-user- 553 protocol-09, 4 March 2020, . 556 [OTIAS] Yang, F., Wang, Q., and P.D. Amer, "Out-of-Order 557 Transmission for In-Order Arrival Scheduling for Multipath 558 TCP", AINAW 28th International Conference on Advanced 559 Information Networking and Applications Workshops, May 560 2014, . 562 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 563 RFC 793, DOI 10.17487/RFC0793, September 1981, 564 . 566 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 567 "TCP Extensions for Multipath Operation with Multiple 568 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 569 . 571 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 572 Paasch, "TCP Extensions for Multipath Operation with 573 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 574 2020, . 576 [RFC8743] Kanugovi, S., Baboescu, F., Zhu, J., and S. Seo, "Multiple 577 Access Management Services Multi-Access Management 578 Services (MAMS)", RFC 8743, DOI 10.17487/RFC8743, March 579 2020, . 581 Authors' Addresses 583 Markus Amend 584 Deutsche Telekom 585 Deutsche-Telekom-Allee 9 586 64295 Darmstadt 587 Germany 589 Email: Markus.Amend@telekom.de 591 Dirk von Hugo 592 Deutsche Telekom 593 Deutsche-Telekom-Allee 9 594 64295 Darmstadt 595 Germany 597 Email: dirk.von-Hugo@telekom.de