idnits 2.17.1 draft-amend-tsvwg-multipath-dccp-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 08, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'Tbd' is mentioned on line 301, but not defined == Unused Reference: 'I-D.muley-network-based-bonding-hybrid-access' is defined on line 345, but no explicit reference was found in the text -- 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: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 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: Experimental 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 DCCP Extensions for Multipath Operation with Multiple Addresses 13 draft-amend-tsvwg-multipath-dccp-02 15 Abstract 17 DCCP communication is currently restricted to a single path per 18 connection, yet multiple paths often exist between peers. The 19 simultaneous use of these multiple paths for a DCCP session could 20 improve resource usage within the network and, thus, improve user 21 experience through higher throughput and improved resilience to 22 network failure. 24 Multipath DCCP provides the ability to simultaneously use multiple 25 paths between peers. This document presents a set of extensions to 26 traditional DCCP to support multipath operation. The protocol offers 27 the same type of service to applications as DCCP and it provides the 28 components necessary to establish and use multiple DCCP flows across 29 potentially disjoint paths. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 9, 2020. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 1.1. Multipath DCCP in the Networking Stack . . . . . . . . . 3 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.3. MP-DCCP Concept . . . . . . . . . . . . . . . . . . . . . 3 69 1.4. Differences from Multipath TCP . . . . . . . . . . . . . 4 70 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 7 71 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 7 72 3. MP-DCCP Protocol . . . . . . . . . . . . . . . . . . . . . . 7 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 5. Interactions with Middleboxes . . . . . . . . . . . . . . . . 7 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 8. Informative References . . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 80 1. Introduction 82 Multipath DCCP (MP-DCCP) is a set of extensions to regular DCCP 83 [RFC4340], which enables a transport connection to operate across 84 multiple paths simultaneously. DCCP multipath operations is 85 suggested in the context of ongoing 3GPP work on 5G multi-access 86 solutions [I-D.amend-tsvwg-multipath-framework-mpdccp] and for hybrid 87 access networks [I-D.lhwxz-hybrid-access-network-architecture][I-D.mu 88 ley-network-based-bonding-hybrid-access]. It can be applied for 89 load-balancing, seamless session handover and aggregation purposes 90 (referred to as steering, switching and splitting in 3GPP terminology 91 [TR23.793]). 93 This document presents the protocol changes required to add multipath 94 capability to DCCP; specifically, those for signaling and setting up 95 multiple paths ("subflows"), managing these subflows, reassembly of 96 data, and termination of sessions. 98 1.1. Multipath DCCP in the Networking Stack 100 MP-DCCP operates at the transport layer and aims to be transparent to 101 both higher and lower layers. It is a set of additional features on 102 top of standard DCCP; Figure 1 illustrates this layering. MP-DCCP is 103 designed to be used by applications in the same way as DCCP with no 104 changes. 106 +-------------------------------+ 107 | Application | 108 +---------------+ +-------------------------------+ 109 | Application | | MP-DCCP | 110 +---------------+ + - - - - - - - + - - - - - - - + 111 | DCCP | |Subflow (DCCP) |Subflow (DCCP) | 112 +---------------+ +-------------------------------+ 113 | IP | | IP | IP | 114 +---------------+ +-------------------------------+ 116 Figure 1: Comparison of Standard DCCP and MP-DCCP Protocol Stacks 118 1.2. Terminology 120 [Tbd], could be similar to [RFC6824] 122 1.3. MP-DCCP Concept 124 Host A Host B 125 ------------------------ ------------------------ 126 Address A1 Address A2 Address B1 Address B2 127 ---------- ---------- ---------- ---------- 128 | | | | 129 | (DCCP flow setup) | | 130 |----------------------------------->| | 131 |<-----------------------------------| | 132 | | | | 133 | | (DCCP flow setup) | | 134 | |--------------------->| | 135 | |<---------------------| | 136 | merge individual DCCP flows to one multipath connection 137 | | | | 139 Figure 2: Example MP-DCCP Usage Scenario 141 1.4. Differences from Multipath TCP 143 Multipath DCCP is similar to Multipath TCP [RFC6824], in that it 144 extends the related basic DCCP transport protocol [RFC4340] with 145 multipath capabilities in the same way as Multipath TCP extends TCP 146 [RFC0793]. However, mainly dominated by the basic protocols TCP and 147 DCPP, the transport characteristics are different. 149 Table 1 compares the protocol characteristics of TCP and DCCP, which 150 are by nature inherited by their respective multipath extensions. A 151 major difference lies in the delivery of payload, which is for TCP an 152 exact copy of the generated byte-stream. DCCP behaves contrary and 153 does not guarantee to transmit any payload nor the order of delivery. 154 Since this is mainly affecting the receiving endpoint of a TCP or 155 DCCP communication, many similarities on sender side can be stated. 156 Both transport protocols share the 3-way initiation of a 157 communication and both exploit a congestion control to adapt to path 158 characteristics. 160 +----------------------+-----------------+--------------------------+ 161 | Feature | TCP | DCCP | 162 +----------------------+-----------------+--------------------------+ 163 | Full-Duplex | yes | yes | 164 +----------------------+-----------------+--------------------------+ 165 | Connection- Oriented | yes | yes | 166 +----------------------+-----------------+--------------------------+ 167 | Header option space | 40 bytes | < 1008 bytes or PMTU | 168 +----------------------+-----------------+--------------------------+ 169 | Data transfer | reliable | unreliable | 170 +----------------------+-----------------+--------------------------+ 171 | Packet-loss handling | re- | report only | 172 | | transmission | | 173 +----------------------+-----------------+--------------------------+ 174 | Ordered data | yes | no | 175 | delivery | | | 176 +----------------------+-----------------+--------------------------+ 177 | Sequence numbers | one per byte | one per PDU | 178 +----------------------+-----------------+--------------------------+ 179 | Flow control | yes | no | 180 +----------------------+-----------------+--------------------------+ 181 | Congestion control | yes | yes | 182 +----------------------+-----------------+--------------------------+ 183 | ECN support | yes | yes | 184 +----------------------+-----------------+--------------------------+ 185 | Selective ACK | yes | depends on congestion | 186 | | | control | 187 +----------------------+-----------------+--------------------------+ 188 | Fix message | no | yes | 189 | boundaries | | | 190 +----------------------+-----------------+--------------------------+ 191 | Path MTU discovery | yes | yes | 192 +----------------------+-----------------+--------------------------+ 193 | Fragmentation | yes | no | 194 +----------------------+-----------------+--------------------------+ 195 | SYN flood protection | yes | no | 196 +----------------------+-----------------+--------------------------+ 197 | Half-open | yes | no | 198 | connections | | | 199 +----------------------+-----------------+--------------------------+ 201 Table 1: TCP and DCCP protocol comparison 203 Consequently, the multipath features, shown in Table 2, are the same, 204 supporting volatile paths, session handover and path aggregation 205 capabilities. All of them profit by the existence of congestion 206 control. 208 +--------------------------+---------------------+------------------+ 209 | Feature | MP-TCP | MP-DCCP | 210 +--------------------------+---------------------+------------------+ 211 | Volatile paths | yes | yes | 212 +--------------------------+---------------------+------------------+ 213 | Robust session | no | yes | 214 | establishment | | | 215 +--------------------------+---------------------+------------------+ 216 | Data reassembly | yes | optional / | 217 | | | modular | 218 +--------------------------+---------------------+------------------+ 219 | Expandability | limited by TCP | flexible | 220 | | header | | 221 +--------------------------+---------------------+------------------+ 222 | Session handover | yes | yes | 223 +--------------------------+---------------------+------------------+ 224 | Path aggregation | yes | yes | 225 +--------------------------+---------------------+------------------+ 227 Table 2: MPTCP and MP-DCCP protocol comparison 229 Therefore the sender logic is not much different between MP-DCCP and 230 MPTCP, even if the multipath session initiation differs. MP-DCCP 231 inherits a robust session establishment feature, which guarantees 232 communication establishment if at least one functional path is 233 available. MP-TCP relies on an initial path, which has to work; 234 otherwise no communication can be established. 236 The receiver side for MP-DCCP has to deal with the unreliable 237 transport character of DCCP and a possible re-assembly of the data 238 stream. In practice, it is assumed that some sort of re-assembly has 239 to be applied, even if DCCP and the order of delivery is unreliable 240 by nature. Such re-assembly mechanisms have to account for the fact 241 that packet loss may occur for any of the DCCP subflows. Another 242 issue is the packet reordering introduced when a DCCP communication 243 is split across paths with disjoint latencies. In theory, 244 applications using DCCP certainly have to deal with packet 245 reordering, since DCCP has no mechanisms to prevent it. However, in 246 practice, without any multipath extension, packet reordering can be 247 assumed to be very limited. Therefore most services on top of DCCP 248 are not expecting massive packet reordering and degrades their 249 performance if it happens anyway. 251 The receiving process for MP-TCP is on the other hand a simple "just 252 wait" approach, since TCP guarantees reliable delivery. 254 1.5. Requirements Language 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in [RFC2119]. 260 2. Operation Overview 262 [Tbd], could be similar to [RFC6824] 264 3. MP-DCCP Protocol 266 [Tbd], could be similar to [RFC6824] 268 [Tbd] On top it requires particular considerations for: 270 o The minimum PMTU of the individual paths must be selected to 271 announce to the application. Changes of individual path PMTUs 272 must be re-announced to the application if they are lower than the 273 current announced PMTU. 275 o Overall sequencing for optional reassembly procedure 277 o Congestion control 279 o Robust MP-DCCP session establishment (no dependency on an initial 280 path setup) 282 4. Security Considerations 284 [Tbd] 286 5. Interactions with Middleboxes 288 [Tbd], should mention standardized technologies like [RFC5597] or 289 [RFC6773] and U-DCCP [I-D.amend-tsvwg-dccp-udp-header-conversion] 291 6. Acknowledgments 293 1. Notes 295 This document is inspired by Multipath TCP [RFC6824] and some text 296 passages for the -00 version of the draft are copied almost 297 unmodified. 299 7. IANA Considerations 301 [Tbd], must include options for: 303 o handshaking procedure to indicate MP support 305 o handshaking procedure to indicate JOINING of an existing MP 306 connection 308 o signaling of new or changed addresses 310 o setting handover or aggregation mode 312 o setting reordering on/off 314 should include options carrying: 316 o overall sequence number for restoring purposes 318 o sender time measurements for restoring purposes 320 o scheduler preferences 322 o reordering preferences 324 8. Informative References 326 [I-D.amend-tsvwg-dccp-udp-header-conversion] 327 Amend, M., Brunstrom, A., Kassler, A., and V. Rakocevic, 328 "Lossless and overhead free DCCP - UDP header conversion 329 (U-DCCP)", draft-amend-tsvwg-dccp-udp-header-conversion-01 330 (work in progress), July 2019. 332 [I-D.amend-tsvwg-multipath-framework-mpdccp] 333 Amend, M., Bogenfeld, E., Brunstrom, A., Kassler, A., and 334 V. Rakocevic, "A multipath framework for UDP traffic over 335 heterogeneous access networks", draft-amend-tsvwg- 336 multipath-framework-mpdccp-01 (work in progress), July 337 2019. 339 [I-D.lhwxz-hybrid-access-network-architecture] 340 Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. 341 Zhang, "Hybrid Access Network Architecture", draft-lhwxz- 342 hybrid-access-network-architecture-02 (work in progress), 343 January 2015. 345 [I-D.muley-network-based-bonding-hybrid-access] 346 Muley, P., Henderickx, W., Geng, L., Liu, H., Cardullo, 347 L., Newton, J., Seo, S., Draznin, S., and B. Patil, 348 "Network based Bonding solution for Hybrid Access", draft- 349 muley-network-based-bonding-hybrid-access-03 (work in 350 progress), October 2018. 352 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 353 RFC 793, DOI 10.17487/RFC0793, September 1981, 354 . 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 362 Congestion Control Protocol (DCCP)", RFC 4340, 363 DOI 10.17487/RFC4340, March 2006, 364 . 366 [RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) 367 Behavioral Requirements for the Datagram Congestion 368 Control Protocol", BCP 150, RFC 5597, 369 DOI 10.17487/RFC5597, September 2009, 370 . 372 [RFC6773] Phelan, T., Fairhurst, G., and C. Perkins, "DCCP-UDP: A 373 Datagram Congestion Control Protocol UDP Encapsulation for 374 NAT Traversal", RFC 6773, DOI 10.17487/RFC6773, November 375 2012, . 377 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 378 "TCP Extensions for Multipath Operation with Multiple 379 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 380 . 382 [TR23.793] 383 3GPP, "Study on access traffic steering, switch and 384 splitting support in the 5G System (5GS) architecture", 385 December 2018. 387 Authors' Addresses 388 Markus Amend 389 Deutsche Telekom 390 Deutsche-Telekom-Allee 7 391 64295 Darmstadt 392 Germany 394 Email: Markus.Amend@telekom.de 396 Eckard Bogenfeld 397 Deutsche Telekom 398 Deutsche-Telekom-Allee 7 399 64295 Darmstadt 400 Germany 402 Email: Eckard.Bogenfeld@telekom.de 404 Anna Brunstrom 405 Karlstad University 406 Universitetsgatan 2 407 651 88 Karlstad 408 Sweden 410 Email: anna.brunstrom@kau.se 412 Andreas Kassler 413 Karlstad University 414 Universitetsgatan 2 415 651 88 Karlstad 416 Sweden 418 Email: andreas.kassler@kau.se 420 Veselin Rakocevic 421 City University of London 422 Northampton Square 423 London 424 United Kingdom 426 Email: veselin.rakocevic.1@city.ac.uk