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