Communication Units Granularity Considerations for Multi-Path Aware Transport Selection
draft-tiesel-taps-communitgrany-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Philipp S. Tiesel , Reese Enghardt | ||
| Last updated | 2017-06-27 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tiesel-taps-communitgrany-00
TAPS Working Group P. Tiesel
Internet-Draft T. Enghardt
Intended status: Informational Berlin Institute of Technology
Expires: December 29, 2017 June 27, 2017
Communication Units Granularity Considerations for Multi-Path Aware
Transport Selection
draft-tiesel-taps-communitgrany-00
Abstract
This document provides an abstract framework to reason about the
composition of multi-path aware systems in a protocol-independent
fashion. It discusses basic mechanisms that are used in multi-path
systems and their applicability to different granularities of
communication units. This document is targeted as consideration
basis for automation of destination, path and transport protocol
selection within the transport layer.
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 http://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 December 29, 2017.
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
(http://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
to this document. Code Components extracted from this document must
Tiesel & Enghardt Expires December 29, 2017 [Page 1]
Internet-Draft Communication Units Granularity June 2017
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. Conventions and Definitions . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Communication Units vs. Layering . . . . . . . . . . . . 3
3. Abstract Hierarchy of Communication Units . . . . . . . . . . 4
3.1. Object . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Stream . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Association, Flow . . . . . . . . . . . . . . . . . . . . 5
3.4. Association Set, Flow Set (Flow-Group) . . . . . . . . . 5
4. Mechanisms Used in Multi-Path Systems . . . . . . . . . . . . 5
4.1. Destination Selection . . . . . . . . . . . . . . . . . . 5
4.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 6
4.3. Chunking . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Scheduling . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Transport Protocol Stack Instance Selection . . . . . . . 8
5. Cost of Transport Option Selection . . . . . . . . . . . . . 8
6. Involvement of On-Path Elements . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Conventions and Definitions
The words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", and
"MAY" are used in this document. It's not shouting; when these words
are capitalized, they have a special meaning as defined in [RFC2119].
2. 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?
Tiesel & Enghardt Expires December 29, 2017 [Page 2]
Internet-Draft Communication Units Granularity June 2017
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?
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.
2.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.
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 December 29, 2017 [Page 3]
Internet-Draft Communication Units Granularity June 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.
3. 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.
3.1. Object
An Object 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
3.2. Stream
A Stream is an ordered sequence of related Objects 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 December 29, 2017 [Page 4]
Internet-Draft Communication Units Granularity June 2017
o A Stream in QUIC or SCTP
o A TCP connection used as transport for XMPP
3.3. Association, Flow
An Association multiplexes a set of Objects 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.
3.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.
4. Mechanisms Used in Multi-Path Systems
4.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 December 29, 2017 [Page 5]
Internet-Draft Communication Units Granularity June 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.
4.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 December 29, 2017 [Page 6]
Internet-Draft Communication Units Granularity June 2017
domain - especially when it comes to integrating 3GPP mechanisms like
IFOM/ [RFC5555].
4.3. Chunking
Chunking refers to splitting an object, a stream or a set of
associations into one or more parts. Typically, chunking splits only
large objects 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 Objects 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.
4.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 December 29, 2017 [Page 7]
Internet-Draft Communication Units Granularity June 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.5. Transport Protocol Stack Instance Selection
TODO - There are many examples in TAPS - still unsure what will go
here or will be cited here.
5. 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.
6. 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.
Especially in the 3GPP context, a lot of off-loading mechanisms have
been specified that are implemented as path level components, within
virtual network adapters.
Tiesel & Enghardt Expires December 29, 2017 [Page 8]
Internet-Draft Communication Units Granularity June 2017
7. 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.
8. IANA Considerations
None
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
9.2. 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., "Software Guidelines for Protocol Evolution",
draft-pauly-taps-guidelines-00 (work in progress),
February 2017.
[I-D.trammell-taps-post-sockets]
Trammell, B., Perkins, C., Pauly, T., and M. Kuehlewind,
"Post Sockets, An Abstract Programming Interface for the
Transport Layer", draft-trammell-taps-post-sockets-00
(work in progress), March 2017.
Tiesel & Enghardt Expires December 29, 2017 [Page 9]
Internet-Draft Communication Units Granularity June 2017
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack
Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June
2009, <http://www.rfc-editor.org/info/rfc5555>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain
Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015,
<http://www.rfc-editor.org/info/rfc7556>.
Authors' Addresses
Philipp S. Tiesel
Berlin Institute of Technology
Marchstr. 23
Berlin
Germany
Email: philipp@inet.tu-berlin.de
Theresa Enghardt
Berlin Institute of Technology
Marchstr. 23
Berlin
Germany
Email: theresa@inet.tu-berlin.de
Tiesel & Enghardt Expires December 29, 2017 [Page 10]