idnits 2.17.1 draft-amend-tsvwg-multipath-framework-mpdccp-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 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.) ** The abstract seems to contain references ([I-D.lhwxz-hybrid-access-network-architecture]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 08, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Tbd' is mentioned on line 322, but not defined == Outdated reference: A later version (-05) exists of draft-amend-tsvwg-multipath-dccp-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-18 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group M. Amend 3 Internet-Draft E. Bogenfeld 4 Intended status: Informational Deutsche Telekom 5 Expires: January 9, 2020 A. Brunstrom 6 A. Kassler 7 Karlstad University 8 V. Rakocevic 9 City University of London 10 July 08, 2019 12 A multipath framework for UDP traffic over heterogeneous access networks 13 draft-amend-tsvwg-multipath-framework-mpdccp-01 15 Abstract 17 More and more of today's devices are multi-homing capable, in 18 particular 3GPP user equipment like smartphones. In the current 19 standardization of the next upcoming mobile network generation 5G 20 Rel.16, this is especially targeted in the study group Access Traffic 21 Steering Switching Splitting [TR23.793]. ATSSS describes the 22 flexible selection or combination of 3GPP untrusted access like Wi-Fi 23 and cellular access, overcoming the single-access limitation of 24 today's devices and services. Another multi-connectivity scenario is 25 the Hybrid Access [I-D.lhwxz-hybrid-access-network-architecture][I-D. 26 muley-network-based-bonding-hybrid-access], providing multiple access 27 for CPEs, which extends the traditional way of single access 28 connectivity at home to dual-connectivity over 3GPP and fixed access. 29 A missing piece in the ATSSS and Hybrid Access is the access and path 30 measurement, which is required for efficient and beneficial traffic 31 steering decisions. This becomes particularly important in 32 heterogeneous access networks with a multitude of volatile access 33 paths. While MP-TCP has been proposed to be used within ATSSS, there 34 are drawbacks when being used to encapsulate unreliable traffic as it 35 blindly retransmits each lost frame leading to excessive delay and 36 potential head-of-line blocking. A decision for MP-TCP though leaves 37 the increasing share of UDP in today's traffic mix 38 () unconsidered. In this document, 39 a multi-access framework is proposed leveraging the MP-DCCP network 40 protocol, which enables flexible traffic steering, switching and 41 splitting also for unreliable traffic. A benefit is the support for 42 pluggable congestion control which enables our framework to be used 43 either independent or complementary to MP-TCP. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on January 9, 2020. 62 Copyright Notice 64 Copyright (c) 2019 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 81 3. IP compatible multipath framework based on MP-DCCP . . . . . 4 82 4. Application and placement . . . . . . . . . . . . . . . . . . 6 83 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 86 8. Informative References . . . . . . . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 Multi-connectivity access networks are evolving. Ongoing 92 standardization at 3GPP for 5G mobile networks [TR23.793] or the so 93 called Hybrid Access networks [I-D.lhwxz-hybrid-access-network-archit 94 ecture][I-D.muley-network-based-bonding-hybrid-access] already 95 provides or will enable in the near future the possibility to use 96 multi-connectivity for a very large number of mobile users. Multi- 97 connectivity solutions come with many user benefits including 98 superior resilience against network outages, higher capacities for 99 user traffic and network cost optimizations. Since multi- 100 connectivity architectures are almost mature, new network protocols 101 are required to fully exploit multi-connectivity and maximise its 102 potential. In the simplest case, multi-connectivity is used for 103 load-balancing decisions in order to balance the user flows over 104 multiple paths. However, this has no effect on resilience or 105 capacity gain on those load balanced individual flows. More complex 106 scenarios include the dynamic shifting of traffic flows seamlessly 107 between multiple paths or even aggregating those paths for leveraging 108 the available capacity of multiple individual paths. Like [TR23.793] 109 this document refers to the three distribution schemes Steering (load 110 balancing), Switching (seamlesshandover) and Splitting (capacity 111 aggregation). 113 MP-TCP [RFC6824] is a protocol, which can be applied in the above 114 mentioned use cases and supports load-balancing, traffic shifting 115 among the multiple paths and also capacity aggregation. Further, it 116 leverages the inherent congestion control from TCP which adapts the 117 sending rate by observing congestion signals from the network. By 118 design, MP-TCP is limited to TCP services as it blindly re-transmits 119 lost packets. Consequently, when MP-TCP is used as a framework for 120 ATSSS, it may re-transmit packets sent from unreliable services such 121 as e.g. UDP unnecessary. This may lead to head-of-line blocking and 122 increased latency, which is detremental to real-time services. As 123 future multi-connectivity systems must support latency sensitive 124 traffic that might be transported over unreliable transport, it is 125 not sufficient anymore to rely on supporting only TCP. The 126 increasing share of UDP traffic, mainly impacted by the QUIC 127 introduction, may significantly reduce the share from TCP. It might 128 be expected that with HTTP/3 carried over QUIC [I-D.ietf-quic-http], 129 the previous strong dominance of TCP will be challenged by UDP. 131 2. Requirements 133 A multiaccess framework shall meet the following requirements: 135 o IP compatibility: A multiaccess framework shall be able to 136 transport IP packets and not make any assumptions on which 137 transport protocol is encapsulated. 139 o Support for unreliable traffic: A multiaccess framework should 140 provide support for transporting unreliable traffic, such as QUIC 141 or UDP based flows. Therefore, unreliable transmission should 142 besupported. 144 o Support for flexible re-ordering: A multiaccess framework should 145 support flexible re-ordering of user traffic, including no re- 146 ordering at all. This requirements is important to support low 147 latency traffic, where the re-creation of packet order may 148 negatively impact delivery latency. 150 o Support for flexible congestion control: A multiaccess framework 151 should support flexible congestion control, including the 152 disabling of the congestion control, if the inner traffic is known 153 to be congestion controlled. 155 o Support for flexible packet scheduling: A multiaccess framework 156 should support different packet scheduling mechanisms, which 157 should be configurable from the control plane. Examples are 158 cheapest path first, or other more sophisticated schedulers. 160 o Lightweight: A multiaccess framework should be lightweight in 161 computational resources and limit the encapsulaton overhead. 163 To use QUIC as part of a multiaccess framework, by for example 164 providing multipath support for QUIC, it could be beneficial if 165 unreliable transmission is supported as well as being able to 166 influence or disable QUICs congestion control. In addition, it would 167 be beneficial if the encryption of QUIC can be disabled. This is 168 because for ATSSS, it is foreseen that the underlying tunnel from the 169 mobile over public WLANs is baseed on IPSec. 171 3. IP compatible multipath framework based on MP-DCCP 173 We propose a new multiaccess framework, which overcomes MP-TCP's 174 restriction to TCP services and provides IP compatibility in 175 Figure 1. The framework employs MP-DCCP 176 [I-D.amend-tsvwg-multipath-dccp] in combination with an encapsulation 177 scheme. For simplification, Figure 1 assumes a traffic direction 178 from the left (sender) to the right (receiver) and requires 179 application in each direction for bi-directional transmission. The 180 framework in Figure 1 can replace or complement MP-TCP to reach IP 181 compatibility. 183 Service |<- MP-DCCP >| Service 184 or Device or Device 185 +-------+ ___ +-----+ DCCP Flow 1 +------+ +--------+ 186 | | _ |Seq||Path |-------------|Re- | _ | | 187 | Sender|___| \__\ /_| | : |order |____/ |___|Receiver| 188 | | IP|_/ |Sched| : | | \_|IP | | 189 | | VNIF_in |uler |-------------|engine| VNIF_out | | 190 +-------+ +-----+ DCCP Flow n +------+ +--------+ 192 Figure 1: IP compatible multipath framework based on MP-DCCP 194 PDUs generated from the sender and travelling through the framework 195 in Figure 1 pass the components in the following order: 197 1. Sender: Generates any PDU based on the IP protocol. 199 2. VNIF_in: IP based Virtual Network Interface as entry point to the 200 multipath framework. A simple routing logic in front (between 201 (1)and (2)) can act as gatekeeper and decides upon redirecting 202 traffic through the VNIF or bypassing it. The VNIF adds an extra 203 IP header to reach the multi-connectivity termination point. 205 3. Seq: Sequencing of the PDUs passed through (2) depending on the 206 incoming order. Adds an incrementing number, which is later 207 added to the DCCP encapsulation in (4). 209 4. Path Scheduler: Decision logic for scheduling sequenced PDUs over 210 the individual connected DCCP flows for multipath transmission. 211 The path scheduler can use the information from the DCCP flows 212 (see (5)) inherent congestion control information like CWND, 213 packet loss, RTT, Jitter, etc.. After selection of a DCCP flow, 214 the PDU is encapsulated into the individual flow. Further 215 information, at least the sequencing, is added on top as DCCP 216 option. 218 5. DCCP Flow(s): Responsible to transmit the encapsulated PDUs to 219 the MP-DCCP exit point. 221 6. Reorder engine: Depending on the sequencing information of (3), a 222 re-assembly of the PDU stream can be applied. Different re-order 223 algorithms should be supported in a configurable way, including 224 no re-ordering. 226 7. VNIF_out: Releases PDUs that have passed the re-ordering engine 227 and strips the DCCP specific overhead. Again, routing is 228 responsible to deliver the PDUs to the receiver based on the 229 destination information in the PDU. 231 8. Receiver: Receive the PDU as generated in (1). 233 The simple enclosing of the MP-DCCP with Virtual Network Interface 234 (VNIF) provides the IP compatibility. However, a service or protocol 235 classifier between sender and VNIF can reduce the scope to particular 236 traffic, e.g. UDP, by simple routing decisions. The MP-DCCP takes 237 over responsibility for the multi-path transfer of the traffic, which 238 is directed through the VNIF_in. For possible re-assembly 239 operations, the IP packets may be stamped with a continuously 240 incremented sequence number. This is not mandatory, but assumed 241 required in most seamless handover and capacity aggregation use 242 cases. The path scheduler decides for each IP packet, which DCCP 243 flow it should use for encapsulation, based on a configurable 244 decision logic and supported by the congestion control information of 245 the DCCP flows available for transmission. A DCCP flow selection for 246 a PDU leads to its encapsulation into the respective DCCP flow and 247 adding extra information required for the multipath transmission, 248 e.g. the sequence number. Encapsulation also means, that a DCCP and 249 IP header is added to the original PDU to reach the multi- 250 connectivity end-point. When the encapsulated PDUs arrive at the 251 multi-path termination point, they are re-ordered depending on the 252 carried sequence number and a configurable logic. The re-ordering 253 engine may also include a logic in which packets are just forwarded 254 (no re-ordering). Re-ordering needs to be considered carefully since 255 any active intervention changes the latency responsiveness. The 256 multi-path termination is finally completed when the DCCP overhead is 257 stripped and the PDU leaves VNIF_out. Further routing depends again 258 on the IP layer of the original PDU. 260 4. Application and placement 262 The framework of Figure 1 is very flexible in applying multipath 263 support in different architectures and allows MP-DCCP to be applied 264 at any place between sender and receiver. Figure 2 to Figure 5 265 provide several architectural options for the deployment of the 266 framework. 268 Device Middlebox 1 Middlebox 2 Device 269 +------+ +-------------+ +------------+ +--------+ 270 |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver| 271 +------+ +-------------+ +------------+ +--------+ 273 Figure 2: Sender and receiver independent MP-DCCP 275 Device Middlebox Device 276 +----------------------+ +------------+ +--------+ 277 |Sender + MP-DCCP entry| -> |MP-DCCP exit| -> |Receiver| 278 +----------------------+ +------------+ +--------+ 280 Figure 3: Sender integrated but receiver independent MP-DCCP 282 Device Middlebox Device 283 +------+ +-------------+ +-----------------------+ 284 |Sender| -> |MP-DCCP entry| -> |MP-DCCP exit + Receiver| 285 +------+ +-------------+ +-----------------------+ 287 Figure 4: Sender independent and receiver integrated MP-DCCP 289 Device Device 290 +----------------------+ +-----------------------+ 291 |Sender + MP-DCCP entry| -> |MP-DCCP exit + Receiver| 292 +----------------------+ +-----------------------+ 294 Figure 5: Sender and receiver integrated MP-DCCP 296 5. Conclusion 298 The specified IP compatible multipath framework based on MP-DCCP in 299 this document comprises several benefits: 301 o Pure routing 303 o Inherent path estimation and measurement 305 o Imposes no constraints on reliability or in-order delivery of 306 application PDUs 308 o Modular re-ordering 310 o Modular scheduling 312 o IP compatible 314 o Based on the standardized DCCP. 316 Middle-box traversing, when the framework is applied in uncontrolled 317 environments, is addressed in [RFC6733] and 318 [I-D.amend-tsvwg-dccp-udp-header-conversion]. 320 6. Security Considerations 322 [Tbd] 324 7. Acknowledgments 326 8. Informative References 328 [I-D.amend-tsvwg-dccp-udp-header-conversion] 329 Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, 330 "Lossless and overhead free DCCP - UDP header conversion 331 (U-DCCP)", draft-amend-tsvwg-dccp-udp-header-conversion-01 332 (work in progress), July 2019. 334 [I-D.amend-tsvwg-multipath-dccp] 335 Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, 336 "DCCP Extensions for Multipath Operation with Multiple 337 Addresses", draft-amend-tsvwg-multipath-dccp-01 (work in 338 progress), March 2019. 340 [I-D.ietf-quic-http] 341 Bishop, M., "Hypertext Transfer Protocol Version 3 342 (HTTP/3)", draft-ietf-quic-http-18 (work in progress), 343 January 2019. 345 [I-D.lhwxz-hybrid-access-network-architecture] 346 Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. 347 Zhang, "Hybrid Access Network Architecture", draft-lhwxz- 348 hybrid-access-network-architecture-02 (work in progress), 349 January 2015. 351 [I-D.muley-network-based-bonding-hybrid-access] 352 Muley, P., Henderickx, W., Geng, L., Liu, H., Cardullo, 353 L., Newton, J., Seo, S., Draznin, S., and B. Patil, 354 "Network based Bonding solution for Hybrid Access", draft- 355 muley-network-based-bonding-hybrid-access-03 (work in 356 progress), October 2018. 358 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 359 Ed., "Diameter Base Protocol", RFC 6733, 360 DOI 10.17487/RFC6733, October 2012, 361 . 363 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 364 "TCP Extensions for Multipath Operation with Multiple 365 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 366 . 368 [TR23.793] 369 3GPP, "Study on access traffic steering, switch and 370 splitting support in the 5G System (5GS) architecture", 371 December 2018. 373 Authors' Addresses 375 Markus Amend 376 Deutsche Telekom 377 Deutsche-Telekom-Allee 7 378 64295 Darmstadt 379 Germany 381 Email: Markus.Amend@telekom.de 383 Eckard Bogenfeld 384 Deutsche Telekom 385 Deutsche-Telekom-Allee 7 386 64295 Darmstadt 387 Germany 389 Email: Eckard.Bogenfeld@telekom.de 391 Anna Brunstrom 392 Karlstad University 393 Universitetsgatan 2 394 651 88 Karlstad 395 Sweden 397 Email: anna.brunstrom@kau.se 399 Andreas Kassler 400 Karlstad University 401 Universitetsgatan 2 402 651 88 Karlstad 403 Sweden 405 Email: andreas.kassler@kau.se 406 Veselin Rakocevic 407 City University of London 408 Northampton Square 409 London 410 United Kingdom 412 Email: veselin.rakocevic.1@city.ac.uk