Table 2.2: Internet Protocols Performing Path Selection Layer Protocol Path Selection Granularity Location
Type Comm. Units
end-point on path
Application HTTP Type 2 message ✓ ✓prx
SIP Type 2 stream ✓ ✓prx
Transport MP-RTP Type 3 messageprf ✓
MPTCP Type 3 stream ✓ ✓
SCTP Type 2 message ✓
Network IP (routing) — no path selection — IP (policy r.) Type 1 assoc. set
IP (ECMP) Type 2/3 assoc. set ✓ ✓
Mobile IP Type 1 assoc. set
NEMO Type 2 assoc. set ✓
IFOM Type 2 assoc. set ✓ ✓
prxCan be done within a proxy.
prfDepends on content specific profiles.
2.6.1 Network Layer
Realizing path selection at the network layer enables an end host to use multiple paths without requiring a multi-path aware communication partner. We do not consider the regular routing in the Internet as path selection, but as a prerequisite to provide the paths we can choose from.
In contrast to regular routing, we identify policy-routing as Type 1 path selection, as it directs certain association sets to a specific path. Based on this differentiation, we also have to consider some Equal Cost Multi-Path Routing [43] (ECMP) routing strategies as performing path selection: If the ECMP path selection is done in a way that forwards all PDUs of an association or association set along the same path5, e.g., based on the 3-tuple or 5-tuple, we consider this as Type 2 granularity. If the ECMP path selection just uses a round-robin scheme, we consider this as Type 3 granularity. Note that ECMP path selection is not application-aware and therefore only included as a corner-case.
A particularly interesting case is Mobile IP. Mobile IP allows keeping an IP address even when leaving the access network and tunnel the traffic to the original access network. Therefore, it provides an addition path. The Mobile IP extensions NEMO6 and IFOM7 allow multiple paths to the same network and can do path selection through policy routing. In case of IFOM, where the mobile IP operation is executed by a virtual interface driver or a middle box, this path selection can even happen on a middle-box. The 3GPP assumes that rules for policy routing with IFOM are provided by the ANDSF.
5 This is usually done to prevent packet reordering which can cause major TCP performance degradation.
6Flow Bindings in Mobile IPv6 and Network Mobility [27]
7IP flow mobility for Proxy Mobile IPv6 [29]
2.6 Analysis: Path Selection Opportunities 2.6.2 Transport Layer
Path selection at the transport layer promises low overhead, but requires the collab-oration of the other endpoint. MPTCP allows adding additional endpoint addresses to an existing TCP connection. To enable a path candidate, the MPTCP path man-ager selects an appropriate source and destination addresses, establishes a new TCP connection over this paths, and links this TCP connection to the MPTCP connec-tion as a subflow. Each chunk of the MPTCP stream can then be assigned to one of these subflows; therefore, MPTCP provides Type 3 granularity. Retransmissions are be tried over the same subflow first, but can be performed using other subflows if needed. This per-chunk path selection can be tailored to enable diverse strate-gies, e.g., to do bandwidth aggregation or to allow fast fallback if one path becomes dysfunctional. As TCP is not protected against on-path modification, middle-boxes can convert regular TCP streams into MPTCP streams [42].
A proposed multipath extension for RTP [44] works in a similar fashion as MPTCP, but allows out-of-band address exchange using, e.g., using SDP in SIP. It works on the message granularity provided by the RTP profiles. Due to the complex interplay of external signaling and rate control, RTP cannot be converted to multipath RTP by middle-boxes. But similar functionality can be achieved using application layer proxies.
SCTP also allows the exchange of additional endpoint addresses. But by default, it uses only one primary path and uses additional addresses as a fallback. In theory, it is possible to assign each message or stream to one of the available paths by using an appropriate source and destination address when sending the object, which results in Type 3 granularity. To use additional paths, SCTP does not require an additional handshake, but it is advisable to check path functionality before using it. In practice, the BSD Socket API and the abstract SCTP API [45] do not expose or enable this functionality8.
2.6.3 Application Layer
Path selection at the application layer enables path selection at message level. But this comes at the cost of complexity and often requires additional expensive com-munication handshakes. We choose HTTP as representative of a message based application layer protocol that uses stream transport service and SIP as represen-tative of a signaling protocol that can be used in complex architectures like the IP Multimedia Subsystem (IMS).
8The abstract SCTP API defined in RFC6458 [45] only allows overriding the destination address for the packet, but not setting the source address or annotating additional attributes for path selection. The semitic of the bind() for SCTP sockets is slightly different form the semantic of TCP/UDP sockets to support fallback addresses, which prevents its use for path selection as described in Section 2.6.3. This limits path selection for SCTP to solely destination address and routing based fallback schemes.
The basic operation ofHTTPuses a stateless request/replay scheme9. Distributing the requests/messages is fairly straightforward by issuing the requests over a trans-port service bound to a certain path. As we can choose a path per request, we end up with Type 2 flow granularity. The underlying transport services, TCP or QUIC in case of HTTP, can be bound to a path, e.g., by appropriately choosing source and destination addresses for the IP PDUs. Adding a new path may induce signifi-cant overhead with regards to latency due to the handshakes. Usually, HTTP+TLS handshakes take at least 2-3 round-trip time (RTT)s, a QUIC handshake takes 1-3 RTTs (0 RTT is only possible for existing connections). In addition to the end host, an HTTP proxy can do the path selection as on-path network function.
SIP is a signaling protocol to negotiate media sessions (typically phone calls and streaming sessions, e.g., as part of the IP Multimedia Subsystem (IMS) used for Voice over LTE). It supports the concurrent use of multiple contact IP addresses for the (concurrent) registration of one endpoint, allowing the creation of multiple signaling paths to a single endpoint. In addition, this can be combined with the path selection features of SCTP or MPTCP.
On these signaling paths, signaling messages carry session description protocol (SDP) messaging to negotiate media streams (i.e., calls or streaming). SDP allows for the (re-)negotiation of the streams of one media session over multiple paths. In turn, this can be used to manage application layer path selection as described for HTTP. From this point of view, SIP can offer application layer multipath support with a Type 2 granularity. Other signaling protocols as XMPP/Jingle use or resem-ble SDP and, therefore, can be used in the same way to support application layer path selection.