TAPS Working Group P. Tiesel Internet-Draft T. Enghardt Intended status: Informational TU Berlin Expires: April 29, 2018 October 26, 2017 Communication Units Granularity Considerations for Multi-Path Aware Transport Selection draft-tiesel-taps-communitgrany-01 Abstract This document provides guidelines how to reason about the composition of multi-path aware systems and how to compose the functionality needed by stacking existing protocols. It discusses fundamental mechanisms that are used in multi-path systems and the consequences of applying them to different granularities of communication units. This document is targeted as consideration basis for automation of destination selection, path selection, and transport protocol selection. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 29, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Tiesel & Enghardt Expires April 29, 2018 [Page 1] Internet-Draft Communication Units Granularity October 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Communication Units vs. Layering . . . . . . . . . . . . 3 2. Abstract Hierarchy of Communication Units . . . . . . . . . . 4 2.1. Message . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Stream . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Association, Flow . . . . . . . . . . . . . . . . . . . . 5 2.4. Association Set, Flow Set (Flow-Group) . . . . . . . . . 5 3. Mechanisms Used in Multi-Path Systems . . . . . . . . . . . . 5 3.1. Destination Selection . . . . . . . . . . . . . . . . . . 5 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 6 3.3. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Scheduling . . . . . . . . . . . . . . . . . . . . . . . 7 4. Cost of Transport Option Selection . . . . . . . . . . . . . 8 5. Involvement of On-Path Elements . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Informative References . . . . . . . . . . . . . . . . . . . 9 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . 10 A.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Today's Internet architecture faces a communication endpoint with a set of choices, including choosing a transport protocol and picking an IP protocol version. In many cases, e.g., when fetching data from a CDN, an endpoint has also the choice of which endpoint instance, [I-D.pauly-taps-guidelines] calls these instances "Derived Endpoint", to contact as DNS can return multiple alternative addresses. If endpoints want to take advantage of multiple available paths, there is another bunch of, partially interdependent, choices: o Which path(s) between the endpoints could be used? o Which path(s) between the endpoints should be used? o Should the paths be used in an active/active way or only as active/fallback? Tiesel & Enghardt Expires April 29, 2018 [Page 2] Internet-Draft Communication Units Granularity October 2017 o Which protocols or sets of protocols should be used? o Which role will other on-path elements, e.g. middle-boxes, take in servicing this flow? Implementing an heuristic or strategy for choosing from this overwhelming set of transport options by each application puts a huge burden on the application developer. Thus, the decisions regarding all transport options mentioned so far should be supported and, if requested by the application, automated within a the transport layer. In order to build such automatization, we need to be able to compare the product of all transport options (destinations, paths, transport protocols and protocol options) available to choose the most appropriate. As the protocols to be used are not known a priori and can differ depending on other transport options, this reasoning has to be independent of a specific protocol or implementation and allow to compare them even if they operate on different communication unit granularities. 1.1. Communication Units vs. Layering When reasoning about network systems, layering traditionally has been the main guidance on where functionality is placed. Looking at modern systems, the classical concept of layers and their mapping to protocols becomes blurry. Protocols can operate on different granularities of communication units, i.e., the semantic units such as messages that the protocols distinguish. These communication units often do not match the PDUs used by the protocols, e.g., TCP segments do not necessarily align with messages at the application layer. In this document, we do not want to take a protocol-centric perspective, but we focus on mechanisms a multi-access system is composed of and the communication units they operate on. This has several advantages: o We can much easier abstract from the protocols used and look at the composition itself. o By disseminate on which kind of communication unit these mechanisms can operate, we can reason about the overall design space. o If seeing the same mechanism multiple times within the same system composition, we can reason about possibly conflicting optimizations. Tiesel & Enghardt Expires April 29, 2018 [Page 3] Internet-Draft Communication Units Granularity October 2017 Overall, this perspective allows us to compare mechanism like distributing requests of an application among different paths, MPTCP and using bandwidth aggregation proxies (as discussed within the IETF in the BANANA working group) despite their different nature and layer of implementation. 2. Abstract Hierarchy of Communication Units These communication units definitions are primarily used for reasoning about automatic stack composition. Therefore, depending on the protocol stack instance, a communication unit can span multiple protocol instances. Some of these hierarchy levels correspond to objects in [I-D.gjessing-taps-minset], but in case of Association and Association Set, we have to split categories as they may indeed be separate on the transport. Note the naming confusion concerning the term "flow" deriving from different perspective. We also annotate the corresponding terminology used in [I-D.trammell-taps-post-sockets] if applicable. 2.1. Message An Message is a piece of data that has a meaning for the application. It is the smallest communication unit that we consider. [I-D.gjessing-taps-minset] correspondent: Message [I-D.trammell-taps-post-sockets] correspondent: Message Examples: o A HTTP-Request/Response-Header/Body for HTTP/2 o An XML message in XMPP 2.2. Stream A Stream is an ordered sequence of related Messages that should be treated the same by the transport system. [I-D.gjessing-taps-minset] correspondent: Flow [I-D.trammell-taps-post-sockets] correspondent: Stream Examples: Tiesel & Enghardt Expires April 29, 2018 [Page 4] Internet-Draft Communication Units Granularity October 2017 o A Stream in QUIC or SCTP o A TCP connection used as transport for XMPP 2.3. Association, Flow An Association multiplexes a set of Messages or Streams within the same Flow with common source and destination. Therefore these communication units become indistinguishable for the network. Association and flow describe the same concept, the former from the perspective of the application, the latter from the perspective of the network. [I-D.gjessing-taps-minset] correspondent: Flow-Group [I-D.trammell-taps-post-sockets] correspondent: Association Examples: o A TCP connection carrying HTTP/2 frames o A set of IP packets that carry TCP or UDP segments and share the same 5-tuple of src-address, dst-address, protocol, src-port, dest-port. 2.4. Association Set, Flow Set (Flow-Group) An Association Set or Flow Set is a set of Associations or Flows that belong together from an application point of view. [I-D.gjessing-taps-minset] correspondent: Flow-Group [I-D.trammell-taps-post-sockets] correspondent: Association Examples: o Two flows, one carrying RTP payloads and one used for RTCP control messages. 3. Mechanisms Used in Multi-Path Systems 3.1. Destination Selection Destination Selection refers to selecting one of multiple different destinations. This mechanism is applicable to any kind of communication unit and can occur on all layers. Typical cases for destination selection include: Tiesel & Enghardt Expires April 29, 2018 [Page 5] Internet-Draft Communication Units Granularity October 2017 o Choosing one address of a multi-homed server for an upcoming communication. o Choosing a server among a list of servers retuned by DNS, e.g for servers that host the same content as part of a CDN. o Choosing a backend server within a load balancer. In practice, destination address selection is often tied to name resolution. As name resolution relies on both local decisions on the endpoint as well as decisions within the DNS infrastructure, this mechanism spreads across different administrative domains which each independently contribute to the overall selection result. 3.2. Path Selection Path Selection refers to choosing which of the available paths to use. and can occur on the network layer and any layer below. o Within an end-host, path selection is usually realized by choosing the source IP address and thus choosing one of the local network interfaces for the communication to the remote endpoint. o Within a path layer traffic system like an MPTCP-Proxy or a BANANA-Box, path selection is usually realized by choosing the outer source and destination address. o In case of an ECMP router, path selection is usually done based on a 3- or 5-tupel and just determines the interface to the next hop. o Within MPTCP, each TCP segment has to be assigned to one or more subflows for transmission to the receiver. While path selection involves a choice of access network it does not need knowledge of or changes to the routing choices within the core network. When doing path selection on small communication units like TCP segments, it is not uncommon to split path selection into two subproblems: _Candidate Path Selection_ determines feasible and preferred choices, e.g., in case of MPTCP by establishing subflows. Afterwards, _Per-Chunk Path Selection_ selects among these alternatives for each chunk. Thus, the first can be more expensive while the latter should be easy to execute. TODO: Discuss difference between Multiple Provisioning Domains [RFC7556] or multiple access networks within the same provisioning Tiesel & Enghardt Expires April 29, 2018 [Page 6] Internet-Draft Communication Units Granularity October 2017 domain - especially when it comes to integrating 3GPP mechanisms like [RFC5555] or [RFC7864]. 3.3. Chunking Chunking refers to splitting an message, a stream or a set of associations into one or more parts. Typically, chunking splits only large messages or streams into multiple ones while keeping smaller entities untouched. Associations or Flows are typically not split, but sets of Associations or Flows might be partitioned. Once split into chunks, each chunk can be transferred individually over different transfer options. Chunking can and does occur at different layers within a system: o A Web site consists of multiple objects or files. Thus, the files can be seen as the natural chunks of a Web site. o TCP takes as input a byte stream and chunks it into segments. TCP chunking (segmentation) occurs at arbitrary byte ranges, thus it will most likely not align with boundaries of Messages that were multiplexed within an application layer Association on top of a TCP connection. In practice, chunking is often constrained in order to maintain certain properties that are desirable for the overall system. Examples such restrictions include the following: o Segmentation in TCP restrict the chunk size, i.e. TCP segment size, to the IP MTU or IP Path MTU to avoid fragmentation at the IP layer. o Equal cost multipath routing does not distribute packets, but Flows to avoid reordering. 3.4. Scheduling Scheduling refers to distributing chunks or sets of chunks across multiple pre-chosen path. Thus, depending on the objectives, it can make sense to see scheduling as is nothing else than per-chunk path selection as defined above. In other cases, e.g. when trying to balance traffic, it makes sense to look at scheduling as a concept itself that uses chunking and per-chunk path selection as sub- mechanisms. Examples of scheduling strategies include: Tiesel & Enghardt Expires April 29, 2018 [Page 7] Internet-Draft Communication Units Granularity October 2017 o Schedule all chunks on one path as long as this path is available, otherwise fall pack to another. o Distribute chunks based on path capacity. 4. Cost of Transport Option Selection Transport option selection mechanisms are often intertwined. Which mechanism is used by which layer or which network component depends on the transfer objectives as well as the state of the network, e.g., availability, path throughput, path RTT, server load. The cost and complexity of transport option selection depends on the network state used and the number of transfer options. If the transfer option selection only uses local state e.g., link availability, and the mechanism is predetermined and/or uses simple mechanisms, e.g., a simple hash function, the cost can even be negligible. An example where transfer option selection is cheap is ECMP within a router. In other cases, the cost can be non-trivial, e.g. when the selection involves queries to remote entities or even active network performance measurements. Such examples include DNS or DHT lookups, as used by some file sharing protocols, or network measurements like RTT and bandwidth estimations used by many video streaming applications. Indeed, costs may be prohibitive, e.g when requiring multiple DNS lookups for every 1 second chunk of a 20 minute video. 5. Involvement of On-Path Elements It may become necessary to take path layer components (middle-boxes) into account that interfere with the transport layer. While the classical "End-To-End Arguments in System Design" [End-To-End] advocates for a dumb network and placing functionality as close to the edge and up in the stack as possible, there are always tussles of moving functionality up or down the stack. This document does not argue against pushing some multi-path functionality down the stack, but advocates to maintain the control of the overall system composition at the end host. Functionality provided by a path can indeed be a reason to choose this path for a given communication unit. Some flow off-loading mechanisms that come in gestalt of of logical interfaces, e.g., [RFC7847]. These interfaces treat some association sets differently, which can be considered on-path functionality. Tiesel & Enghardt Expires April 29, 2018 [Page 8] Internet-Draft Communication Units Granularity October 2017 6. Security Considerations Security related transport service request must take priority over performance, therefore, transport options or stack compositions that don't provide the transport service requested should be ignored for transport option selection. Note: This discussion is not exhaustive - more considerations will be added in later versions of this draft. 7. IANA Considerations None 8. Acknowledgements This work has been supported by Leibniz Prize project funds of DFG - German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1). 9. Informative References [End-To-End] Saltzer, J., Reed, D., and D. Clark, "End-to-end arguments in system design", ACM Transactions on Computer Systems Vol. 2, pp. 277-288, DOI 10.1145/357401.357402, November 1984. [I-D.gjessing-taps-minset] Gjessing, S. and M. Welzl, "A Minimal Set of Transport Services for TAPS Systems", draft-gjessing-taps-minset-05 (work in progress), June 2017. [I-D.pauly-taps-guidelines] Pauly, T., "Guidelines for Racing During Connection Establishment", draft-pauly-taps-guidelines-01 (work in progress), October 2017. [I-D.trammell-taps-post-sockets] Trammell, B., Perkins, C., Pauly, T., Kuehlewind, M., and C. Wood, "Post Sockets, An Abstract Programming Interface for the Transport Layer", draft-trammell-taps-post- sockets-01 (work in progress), September 2017. [RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 2009, . Tiesel & Enghardt Expires April 29, 2018 [Page 9] Internet-Draft Communication Units Granularity October 2017 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, . [RFC7847] Melia, T., Ed. and S. Gundavelli, Ed., "Logical-Interface Support for IP Hosts with Multi-Access Support", RFC 7847, DOI 10.17487/RFC7847, May 2016, . [RFC7864] Bernardos, CJ., Ed., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", RFC 7864, DOI 10.17487/RFC7864, May 2016, . Appendix A. Changes A.1. Since -00 o Replaced granularity "Object" with "Message" to align with other TAPS documents. o Removed empty section on protocol instance selection - this topic will go into a separate document later. o Minor clarifications. o Removed definition of normative terms not needed for this document o Added acknowledgments and updated authors' affiliation (compliance). Authors' Addresses Philipp S. Tiesel TU Berlin Marchstr. 23 Berlin Germany Email: philipp@inet.tu-berlin.de Theresa Enghardt TU Berlin Marchstr. 23 Berlin Germany Email: theresa@inet.tu-berlin.de Tiesel & Enghardt Expires April 29, 2018 [Page 10]