idnits 2.17.00 (12 Aug 2021) /tmp/idnits40297/draft-tiesel-taps-communitgrany-03.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 (November 03, 2018) is 1288 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-taps-interface' is defined on line 503, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-taps-arch-02 == Outdated reference: A later version (-15) exists of draft-ietf-taps-interface-02 == Outdated reference: draft-ietf-taps-minset has been published as RFC 8923 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TAPS Working Group P. Tiesel 3 Internet-Draft T. Enghardt 4 Intended status: Informational TU Berlin 5 Expires: May 7, 2019 November 03, 2018 7 Communication Units Granularity Considerations for Multi-Path Aware 8 Transport Selection 9 draft-tiesel-taps-communitgrany-03 11 Abstract 13 This document provides an approach how to reason about the 14 composition of multi-path aware transport stacks. It discusses how 15 to compose the functionality needed by stacking existing internet 16 protocols and the fundamental mechanisms that are used in multi-path 17 systems and the consequences of applying them to different 18 granularities of communication units, e.g, on a message or stream 19 granularity. This document is targeted as guidance for automation of 20 destination selection, path selection, and transport protocol 21 selection. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 7, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Communication Units vs. Layering . . . . . . . . . . . . 3 59 2. Abstract Hierarchy of Communication Units . . . . . . . . . . 4 60 2.1. Message . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Stream . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Association / Connection Group . . . . . . . . . . . . . 5 63 2.4. Association Set / Flow-Group . . . . . . . . . . . . . . 5 64 3. Mechanisms Used in Multi-Path Systems . . . . . . . . . . . . 5 65 3.1. Destination Selection . . . . . . . . . . . . . . . . . . 6 66 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.4. Scheduling . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Cost of Transport Option Selection . . . . . . . . . . . . . 8 70 5. Involvement of On-Path Elements . . . . . . . . . . . . . . . 8 71 6. Overview of Mechanisms provided by selected IETF Protocols . 9 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 73 8. Informative References . . . . . . . . . . . . . . . . . . . 11 74 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 12 75 A.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 12 76 A.2. Since -01 . . . . . . . . . . . . . . . . . . . . . . . . 12 77 A.3. Since -02 . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Today's Internet architecture faces a communication endpoint with a 83 set of choices, including choosing a transport protocol and picking 84 an IP protocol version. In many cases, e.g., when fetching data from 85 a CDN, an endpoint has also the choice of which endpoint instance, 86 [I-D.brunstrom-taps-impl] calls these instances "Derived Endpoint", 87 to contact as DNS can return multiple alternative addresses. 89 If endpoints want to take advantage of multiple available paths, 90 there is another bunch of, partially interdependent, choices: 92 o Which path(s) between the endpoints could be used? 94 o Which path(s) between the endpoints should be used? 95 o Should the paths be used in an active/active way or only as 96 active/fallback? 98 o Which protocols or sets of protocols should be used? 100 o Which role will other on-path elements, e.g. middle-boxes, take in 101 servicing this flow? 103 Implementing an heuristic or strategy for choosing from this 104 overwhelming set of transport options by each application puts a huge 105 burden on the application developer. Thus, the decisions regarding 106 all transport options mentioned so far should be supported and, if 107 requested by the application, automated within a the transport layer. 108 In order to build such automatization, we need to be able to compare 109 the product of all transport options (destinations, paths, transport 110 protocols and protocol options) available to choose the most 111 appropriate. 113 As the protocols to be used are not known a priori and can differ 114 depending on other transport options, this reasoning has to be 115 independent of a specific protocol or implementation and allow to 116 compare them even if they operate on different communication unit 117 granularities. 119 1.1. Communication Units vs. Layering 121 When reasoning about network systems, layering traditionally has been 122 the main guidance on where functionality is placed. Looking at 123 modern systems, the classical concept of layers and their mapping to 124 protocols becomes blurry. Protocols can operate on different 125 granularities of communication units, i.e., the semantic units such 126 as messages that the protocols distinguish. These communication 127 units often do not match the PDUs used by the protocols, e.g., TCP 128 segments do not necessarily align with messages at the application 129 layer. 131 In this document, we do not want to take a protocol-centric 132 perspective, but we focus on mechanisms a multi-access system is 133 composed of and the communication units they operate on. This has 134 several advantages: 136 o We can much easier abstract from the protocols used and look at 137 the composition itself. 139 o By disseminate on which kind of communication unit these 140 mechanisms can operate, we can reason about the overall design 141 space. 143 o If seeing the same mechanism multiple times within the same system 144 composition, we can reason about possibly conflicting 145 optimizations. 147 Overall, this perspective allows us to compare mechanism like 148 distributing requests of an application among different paths, MPTCP 149 and using bandwidth aggregation proxies (as discussed within the IETF 150 in the BANANA working group) despite their different nature and layer 151 of implementation. 153 2. Abstract Hierarchy of Communication Units 155 These communication units definitions are primarily used for 156 reasoning about automatic stack composition. Therefore, depending on 157 the protocol stack instance, a communication unit can span multiple 158 protocol instances. 160 Some of these hierarchy levels correspond to objects in 161 [I-D.ietf-taps-minset], but in case of Association and Association 162 Set, we have to split categories as they may indeed be separate on 163 the transport. Note the naming confusion concerning the term "flow" 164 deriving from different perspective. 166 We also annotate the corresponding terminology used in 167 [I-D.ietf-taps-arch] if it differs from the one used in this 168 document. 170 2.1. Message 172 An Message is a piece of data that has a meaning for the application. 173 It is the smallest communication unit that we consider. 175 [I-D.ietf-taps-minset] correspondent: Message 177 Examples: 179 o A HTTP-Request/Response-Header/Body for HTTP/2 181 o An XML message in XMPP 183 2.2. Stream 185 A Stream is an ordered sequence of related Messages that should be 186 treated the same by the transport system. 188 [I-D.ietf-taps-minset] correspondent: Flow 190 Examples: 192 o A Stream in QUIC or SCTP 194 o A TCP connection used as transport for XMPP 196 2.3. Association / Connection Group 198 An Association multiplexes a set of Messages or Streams within the 199 same Flow with common source and destination. Therefore these 200 communication units become indistinguishable for the network. 201 Association and flow describe the same concept, the former from the 202 perspective of the application, the latter from the perspective of 203 the network. 205 [I-D.ietf-taps-minset] correspondent: Flow-Group 207 [I-D.ietf-taps-arch] correspondent: Connection Group 209 Examples: 211 o A TCP connection carrying HTTP/2 frames 213 o A set of IP packets that carry TCP or UDP segments and share the 214 same 5-tuple of src-address, dst-address, protocol, src-port, 215 dest-port. 217 2.4. Association Set / Flow-Group 219 An Association Set or Flow Set is a set of Associations or Flows that 220 belong together from an application point of view. 222 [I-D.ietf-taps-minset] correspondent: Flow-Group 224 Examples: 226 o Two flows, one carrying RTP payloads and one used for RTCP control 227 messages. 229 3. Mechanisms Used in Multi-Path Systems 231 Transport protocols on the Internet provide a large variety of 232 functionality. While the functionality of simple protocols like UDP 233 is easy to describe (multiplexing streams of messages), describing 234 the functionality of complex protocols such as QUIC, MPTCP or SCTP is 235 manyfold as these protocols provide a set of commonly used 236 functionality. Also, the same functionality can be provided at many 237 places throughout the whole stack. In the following, we explore the 238 set of functionality that can be provided by transport protocols. 240 3.1. Destination Selection 242 Destination Selection refers to selecting one of multiple different 243 destinations. This mechanism is applicable to any kind of 244 communication unit and can occur on all layers. 246 Typical cases for destination selection include: 248 o Choosing one address of a multi-homed server for an upcoming 249 communication. 251 o Choosing a server among a list of servers retuned by DNS, e.g for 252 servers that host the same content as part of a CDN. 254 o Choosing a backend server within a load balancer. 256 In practice, destination address selection is often tied to name 257 resolution. As name resolution relies on both local decisions on the 258 endpoint as well as decisions within the DNS infrastructure, this 259 mechanism spreads across different administrative domains which each 260 independently contribute to the overall selection result. 262 3.2. Path Selection 264 Path Selection refers to choosing which of the available paths to 265 use. and can occur on the network layer and any layer below. 267 o Within an end-host, path selection is usually realized by choosing 268 the source IP address and thus choosing one of the local network 269 interfaces for the communication to the remote endpoint. 271 o Within a path layer traffic system like an MPTCP-Proxy or a 272 BANANA-Box, path selection is usually realized by choosing the 273 outer source and destination address. 275 o In case of an ECMP router, path selection is usually done based on 276 a 3- or 5-tupel and just determines the interface to the next hop. 278 o Within MPTCP, each TCP segment has to be assigned to one or more 279 subflows for transmission to the receiver. 281 While path selection involves a choice of access network it does not 282 need knowledge of or changes to the routing choices within the core 283 network. 285 When doing path selection on small communication units like TCP 286 segments, it is not uncommon to split path selection into two 287 subproblems: _Candidate Path Selection_ determines feasible and 288 preferred choices, e.g., in case of MPTCP by establishing subflows. 289 Afterwards, _Per-Chunk Path Selection_ selects among these 290 alternatives for each chunk. Thus, the first can be more expensive 291 while the latter should be easy to execute. 293 TODO: Discuss difference between Multiple Provisioning Domains 294 [RFC7556] or multiple access networks within the same provisioning 295 domain - especially when it comes to integrating 3GPP mechanisms like 296 [RFC5555] or [RFC7864]. 298 3.3. Chunking 300 Chunking refers to splitting an message, a stream or a set of 301 associations into one or more parts. Typically, chunking splits only 302 large messages or streams into multiple ones while keeping smaller 303 entities untouched. Associations or Flows are typically not split, 304 but sets of Associations or Flows might be partitioned. Once split 305 into chunks, each chunk can be transferred individually over 306 different transfer options. 308 Chunking can and does occur at different layers within a system: 310 o A Web site consists of multiple objects or files. Thus, the files 311 can be seen as the natural chunks of a Web site. 313 o TCP takes as input a byte stream and chunks it into segments. TCP 314 chunking (segmentation) occurs at arbitrary byte ranges, thus it 315 will most likely not align with boundaries of Messages that were 316 multiplexed within an application layer Association on top of a 317 TCP connection. 319 In practice, chunking is often constrained in order to maintain 320 certain properties that are desirable for the overall system. 321 Examples such restrictions include the following: 323 o Segmentation in TCP restrict the chunk size, i.e. TCP segment 324 size, to the IP MTU or IP Path MTU to avoid fragmentation at the 325 IP layer. 327 o Equal cost multipath routing does not distribute packets, but 328 Flows to avoid reordering. 330 3.4. Scheduling 332 Scheduling refers to distributing chunks or sets of chunks across 333 multiple pre-chosen path. Thus, depending on the objectives, it can 334 make sense to see scheduling as is nothing else than per-chunk path 335 selection as defined above. In other cases, e.g. when trying to 336 balance traffic, it makes sense to look at scheduling as a concept 337 itself that uses chunking and per-chunk path selection as sub- 338 mechanisms. 340 Examples of scheduling strategies include: 342 o Schedule all chunks on one path as long as this path is available, 343 otherwise fall pack to another. 345 o Distribute chunks based on path capacity. 347 4. Cost of Transport Option Selection 349 Transport option selection mechanisms are often intertwined. Which 350 mechanism is used by which layer or which network component depends 351 on the transfer objectives as well as the state of the network, e.g., 352 availability, path throughput, path RTT, server load. 354 The cost and complexity of transport option selection depends on the 355 network state used and the number of transfer options. If the 356 transfer option selection only uses local state e.g., link 357 availability, and the mechanism is predetermined and/or uses simple 358 mechanisms, e.g., a simple hash function, the cost can even be 359 negligible. An example where transfer option selection is cheap is 360 ECMP within a router. In other cases, the cost can be non-trivial, 361 e.g. when the selection involves queries to remote entities or even 362 active network performance measurements. Such examples include DNS 363 or DHT lookups, as used by some file sharing protocols, or network 364 measurements like RTT and bandwidth estimations used by many video 365 streaming applications. Indeed, costs may be prohibitive, e.g when 366 requiring multiple DNS lookups for every 1 second chunk of a 20 367 minute video. 369 5. Involvement of On-Path Elements 371 It may become necessary to take path layer components (middle-boxes) 372 into account that interfere with the transport layer. 374 While the classical "End-To-End Arguments in System Design" 375 [End-To-End] advocates for a dumb network and placing functionality 376 as close to the edge and up in the stack as possible, there are 377 always tussles of moving functionality up or down the stack. This 378 document does not argue against pushing some multi-path functionality 379 down the stack, but advocates to maintain the control of the overall 380 system composition at the end host. Functionality provided by a path 381 can indeed be a reason to choose this path for a given communication 382 unit. 384 Some flow off-loading mechanisms that come in gestalt of of logical 385 interfaces, e.g., [RFC7847]. These interfaces treat some association 386 sets differently, which can be considered on-path functionality. 388 6. Overview of Mechanisms provided by selected IETF Protocols 390 +-----+-----+-----+------+------+--------+-------+-------+----------+ 391 | Pro | Con | Ord | Reli | Inte | Confid | Authe | Chunk | Multiple | 392 | toc | ges | eri | abil | grit | ential | ntici | ing | xing | 393 | ol | tio | ng | ity | y P. | ity P. | ty P. | | | 394 | | n C | | | | | | | | 395 | | ont | | | | | | | | 396 | | rol | | | | | | | | 397 +-----+-----+-----+------+------+--------+-------+-------+----------+ 398 | HTT | r | r | r | | | | bytes | requests | 399 | P | | | | | | | | | 400 | | | | | | | | | | 401 | HTT | r | r | r | r | r | r | bytes | requests | 402 | PS | | | | | | | | | 403 | | | | | | | | | | 404 | XMP | r | r | r | (r) | (r) | (r) | | messages | 405 | P | | | | | | | | | 406 | | | | | | | | | | 407 | SIP | | | + | (r) | (r) | (r) | | messages | 408 | | | | | | | | | | 409 | DTL | | | | + | + | + | | services | 410 | S | | | | | | | | ,name | 411 | | | | | | | | | | 412 | TLS | | r | r | + | + | + | | services | 413 | | | | | | | | | ,name | 414 | | | | | | | | | | 415 | RTP | +(p | +(p | | | | | messa | messages | 416 | | rf) | rf) | | | | | ges(p | | 417 | | | | | | | | rf) | | 418 | | | | | | | | | | 419 | SRT | +(p | +(p | | + | + | r(sig | messa | messages | 420 | P | rf) | rf) | | | | ) | ges(p | | 421 | | | | | | | | rf) | | 422 | | | | | | | | | | 423 | QUI | + | + | + | + | + | +(tls | bytes | connecti | 424 | C | | | | | | ) | | on-id,+( | 425 | | | | | | | | | tls) | 426 | | | | | | | | | | 427 | UDP | | | | | | | | ports | 428 | | | | | | | | | | 429 | DCC | + | | | | | | | ports | 430 | P | | | | | | | | | 431 | | | | | | | | | | 432 | TCP | + | + | + | | | | bytes | ports | 433 | | | | | | | | | | 434 | MPT | + | + | + | | | | bytes | ports | 435 | CP | | | | | | | | | 436 | | | | | | | | | | 437 | SCT | + | + | + | | | | bytes | ports,st | 438 | P | | | | | | | | reams | 439 | | | | | | | | | | 440 | IPs | | | | + | + | r(ike | | spi | 441 | ec | | | | | | ) | | ,next- | 442 | (ES | | | | | | | | header | 443 | P) | | | | | | | | | 444 | | | | | | | | | | 445 | IPs | | | | + | | r(ike | | spi | 446 | ec | | | | | | ) | | ,next- | 447 | (AH | | | | | | | | header | 448 | ) | | | | | | | | | 449 | | | | | | | | | | 450 | IP | | (+( | | | | | (frag | address | 451 | | | fr) | | | | | ments | ,next- | 452 | | | ) | | | | | ) | header | 453 | | | | | | | | | | 454 | NEM | | | | | r | r | assoc | | 455 | O/I | | | | | | | . | | 456 | FOM | | | | | | | | | 457 +-----+-----+-----+------+------+--------+-------+-------+----------+ 459 Legend: 461 r: Protocol requires transport service. 463 +: Protocol provides transport service. 465 prf: Realized by content specific profiles. 467 tls: Uses TLSv1.3 as sub-protocol; imports authenticity protection 468 and multiplexing from TLS. 470 ike: Realized externally by external protocol IKE/IKEv2. 472 sig: Realized externally by external signaling protocol (e.g., SIP, 473 XMPP, WebRTC). 475 fr: :Only when fragmentation is used and only to re-assemble IP PUDs 477 7. Acknowledgements 479 This work has been supported by Leibniz Prize project funds of DFG - 480 German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ 481 FE 570/4-1). 483 8. Informative References 485 [End-To-End] 486 Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments 487 in system design", ACM Transactions on Computer 488 Systems Vol. 2, pp. 277-288, DOI 10.1145/357401.357402, 489 November 1984. 491 [I-D.brunstrom-taps-impl] 492 Brunstrom, A., Pauly, T., Enghardt, T., Grinnemo, K., 493 Jones, T., Tiesel, P., Perkins, C., and M. Welzl, 494 "Implementing Interfaces to Transport Services", draft- 495 brunstrom-taps-impl-00 (work in progress), March 2018. 497 [I-D.ietf-taps-arch] 498 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 499 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 500 Transport Services", draft-ietf-taps-arch-02 (work in 501 progress), October 2018. 503 [I-D.ietf-taps-interface] 504 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 505 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 506 Abstract Application Layer Interface to Transport 507 Services", draft-ietf-taps-interface-02 (work in 508 progress), October 2018. 510 [I-D.ietf-taps-minset] 511 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 512 Services for End Systems", draft-ietf-taps-minset-11 (work 513 in progress), September 2018. 515 [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack 516 Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 517 2009, . 519 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 520 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 521 . 523 [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface 524 Support for IP Hosts with Multi-Access Support", RFC 7847, 525 DOI 10.17487/RFC7847, May 2016, 526 . 528 [RFC7864] Bernardos, CJ., Ed., "Proxy Mobile IPv6 Extensions to 529 Support Flow Mobility", RFC 7864, DOI 10.17487/RFC7864, 530 May 2016, . 532 Appendix A. Changes 534 A.1. Since -00 536 o Replaced granularity "Object" with "Message" to align with other 537 TAPS documents. 539 o Removed empty section on protocol instance selection - this topic 540 will go into a separate document later. 542 o Minor clarifications. 544 o Removed definition of normative terms not needed for this document 546 o Added acknowledgments and updated authors' affiliation 547 (compliance). 549 A.2. Since -01 551 o Updated drafts references 553 o Added Overview of Mechanisms provided by selected IETF Protocols 555 o Minor clarifications 557 o Removed superfluous IANA and Security Considerations section 559 A.3. Since -02 561 o Prevent expirary (minor formatting fixes) 563 Authors' Addresses 564 Philipp S. Tiesel 565 TU Berlin 566 Marchstr. 23 567 Berlin 568 Germany 570 Email: philipp@inet.tu-berlin.de 572 Theresa Enghardt 573 TU Berlin 574 Marchstr. 23 575 Berlin 576 Germany 578 Email: theresa@inet.tu-berlin.de