Policy: Choosing Transport Options 4
Transport diversity is no advantage per se — it is an opportunity to optimize the transport service for the individual applications’ needs. To approach this problem, we first need to understand the design space, which is described in the previous chapters: Chapter 2 explores the dimension of transport diversity and characterizes what transport options this diversity provides and outlines how transport diversity manifests in Internet’s protocols. In Chapter 3, we demonstrate a way to formulate applications’ communication needs and introduce a mechanism to describe them. In this chapter, we finally discusshow to choose among transport options and present a generalizedpolicy framework to realize this.
As a general requirement, our policy framework should enable all relevant stake-holders in the system to express their preferences or constraints towards certain transport configurations. These stakeholders include the system administrator of an administrative domain, the user and system vendor of a specific device, the provisioning domain of a path, as well as application vendors. Examples for those interests include:
• A user prohibits the game “Fluffy Pufferfish” to use paths using cellular.
• A system vendor wants software updates larger than 256 KB to prefer paths that are “cheap”.
• An LTE network prefers IMS voice traffic using their platform to be routed via their LTE network.
• An application vendor wants the control traffic of its application to prefer SCTP or MPTCP over TCP.
• A company’s system administrator prohibits its CRM system to use any paths except the company’s VPN.
In order to explain the general structure of our policy framework, we start with a naïve approach that describes the basic four steps that are needed in order to perform transport option selection:
1. Determine the available transport options and their properties.
2. Eliminate transport options that are prohibited by policy entries.
3. Rank the remaining transport options based on the stakeholders’ interests and application’s needs.
4. Choose the best transport option.
In practice, this naïve four-step approach does not suffice. To reliably choose among transport options, we have to respect the dependencies between transport options.
Not all properties, e.g., path characteristics, are readily available and we cannot wait for results without impacting user experience. Therefore, we have to apply heuristic. Moreover, we want to try the best-ranked transport options in parallel to compensate for transport options that do not work and reduce the impact of imprecise heuristics.
The remainder of this chapter is structured as follows: To derive the requirements for the policy framework, we first discuss the dependencies that the transport option selection has to take into account when building and ranking transport configura-tions in Section 4.1. Most of these dependencies are latency related and result in the need to parallelize the selection process. Then, in Section 4.2, we explain how to represent transport configurations in a tree based structure. Next, to express the stakeholders’ interest towards transport option selection, we propose policy en-tries in Section 4.3. Policy entries are considered by our generic policy iff they match a transport option or transport configuration while their actions determine how to resolve trade-offs or purge depreciated transport configurations from the transport configuration tree. In Section 4.5, we use a generalized variant of Happy Eyeballs [49] to probe the most preferred transport configurations from the tree in parallel. Finally, we summarize our findings in Section 4.6.
The policy framework described in this chapter is based on the experiences from designing policies for our Multi-Access Prototype (Section 6.3.5) and for our Web Transfer Simulator (Section 5.2), Moreover, it has been shaped by discussions within the IETF Taps working group [70].
4.1 Policy Dependencies
To realize transport option selection within the OS, our policy framework has to interact with other components of the OS that provide input for the policy.
These inputs include characteristics of all available paths — e.g., delay, bandwidth, and packet loss, as described in Section 2.5 — the protocols available locally (see Section 2.8), and name resolution to determine the available endpoints (see Sec-tion 2.7).
Name Resolution
Session State
Destination Selection Path Selection Protocol Stack Composition
Caching
Figure 4.1: Dependencies between Transport options a Policy has to Respect.
4.1 Policy Dependencies Combining these components is non-trivial since there are dependencies between these mechanisms. Figure 4.1 gives an overview of the dependencies within trans-port option selection a policy has to respect. Most other parts of transtrans-port option selection depend on path selection because of the challenges and opportunities aris-ing from on-path network functions — This has been already discussed in detail in Section 2.5.4. In this section, we focus on the dependencies for caching and the re-use of session state. Both are crucial for the user experience to minimize the delay incurred by transport option selection and therefore become a dependency.
As we do not want to add delays to perform transport option selection, we have to parallelize the process. Therefore, we describe the dependencies and timing issues between the components that have to be addressed when parallelizing the process.
Name Resolution Name resolution depends on the path (see Section 2.7 for more discussion). Therefore, the endpoints derived through name resolution should only be used on the same path from which they were derived. In some cases, name resolution also requires input from protocol stack composition, e.g., for protocols that useSRVtype DNS records to determine endpoints1. Therefore, name resolution is constrained by the protocols available locally.
In addition, name resolution takes at least one RTT (of the path). Therefore, the delay cost of waiting for name resolution on all paths to finish is the RTT of the slowest path. Thus, if timeliness is essential for the given communication, name resolution should not delay endpoint selection using other paths.
Local Session State Local session state, e.g., the existence of open TCP con-nections, can influence transport option selection– especially if done at message or stream granularity. The possibility to send a message using an already established connection to save connection setup time and dramatically reduce the latency for the application. This principle can be extended to other protocol layers as well. For example, if confidentiality or integrity protection is needed, it is useful to check if there is an already established IPSEC association or cached TLS state that can be used to perform a 0-RTT handshake. Moving transport option selection from the application to the OS can also enable using these optimizations across application boundaries.
Caching Caching is crucial for name resolution performance and transport config-uration probing, especially when transport option selection is done for fine-grained communication units. Using cached results save at least one RTT of connection setup time each. If there are cached results for some transport options, the policy has to handle the trade-off between saving communication setup time and using the best transport option requiring non-cached state.
1 The DNS query for an SRV record already contains the protocol stack to be used — a name resolution failure already allows excluding this protocol stack composition.