One document matched: draft-scharf-mptcp-api-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC0793 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793">
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119">
<!ENTITY RFC3542 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3542">
<!ENTITY RFC4584 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4584">
<!ENTITY MPTCPARCH SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-architecture-01">
<!ENTITY MPTCP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-multiaddressed-01">
<!ENTITY MPTCPSEC SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-threat-03">
<!ENTITY MPTCPCC SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mptcp-congestion-00">
<!ENTITY SHIMAPI SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-shim6-multihome-shim-api-13">
<!ENTITY HIPAPI SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hip-native-api-12">
<!ENTITY SCTPAPI SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tsvwg-sctpsocket-23">
<!ENTITY MIFPRACTICE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-current-practices-01">
<!ENTITY MIFPROBLEM SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-problem-statement-04">
<!ENTITY AFMP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-sarolahti-mptcp-af-multipath-01">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="info" docName="draft-scharf-mptcp-api-03" ipr="trust200902">
<front>
<title abbrev="MPTCP API">MPTCP Application Interface Considerations</title>
<author fullname="Michael Scharf" initials="M." surname="Scharf">
<organization>Alcatel-Lucent Bell Labs</organization>
<address>
<postal>
<street>Lorenzstrasse 10</street>
<city>70435 Stuttgart</city>
<country>Germany</country>
</postal>
<email>michael.scharf@alcatel-lucent.com</email>
</address>
</author>
<author fullname="Alan Ford" initials="A." surname="Ford">
<organization>Roke Manor Research</organization>
<address>
<postal>
<street>Old Salisbury Lane</street>
<city>Romsey, Hampshire SO51 0ZN</city>
<country>UK</country>
</postal>
<phone>+44 1794 833 465</phone>
<email>alan.ford@roke.co.uk</email>
</address>
</author>
<date year="2010"/>
<area>Transport Area</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>MPTCP</keyword>
<keyword>TCP</keyword>
<abstract>
<t>Multipath TCP (MPTCP) adds the capability of using multiple
paths to a regular TCP session. Even though it is designed to be
totally backward compatible to applications, the data transport
differs compared to regular TCP, and there are several
additional degrees of freedom that applications may wish to
exploit. This document summarizes the impact that MPTCP may have
on applications, such as changes in performance. Furthermore,
it discusses compatibility issues of MPTCP in combination with
non-MPTCP-aware applications. Finally, the document describes a basic
application interface for MPTCP-aware applications that provides
access to multipath address information and a level of control
equivalent to regular TCP.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Multipath TCP adds the capability of using multiple
paths to a regular TCP session <xref target="RFC0793"/>. The
motivations for this extension include increasing throughput,
overall resource utilisation, and resilience to network failure,
and these motivations are discussed, along with high-level
design decisions, as part of the Multipath TCP architecture
<xref target="I-D.ietf-mptcp-architecture"/>. The MPTCP protocol
<xref target="I-D.ietf-mptcp-multiaddressed"/> offers the same
reliable, in-order, byte-stream transport as TCP, and is
designed to be backward compatible with both applications and
the network layer. It requires support inside the network stack
of both endpoints.</t>
<t>This document first presents the impacts that MPTCP may have
on applications, such as performance changes compared to regular
TCP. Second, it defines the interoperation of MPTCP and
applications that are unaware of the multipath transport. MPTCP
is designed to be usable without any application changes, but
some compatibility issues have to be taken into account. Third,
this memo specifies a basic Application Programming Interface
(API) for MPTCP-aware applications. The API presented here is an
extension to the regular TCP API to allow an MPTCP-aware
application the equivalent level of control and access to information
of an MPTCP connection that would be possible with the standard
TCP API on a regular TCP connection.</t>
<t>An advanced API for MPTCP is outside the scope of this
document. Such an advanced API could offer a more fine-grained
control over multipath transport functions and policies. The
appendix includes a brief, non-compulsory list of potential
features of such an advanced API.</t>
<t>The de facto standard API for TCP/IP applications is the
"sockets" interface. This document defines experimental
MPTCP-specific extensions, using additional socket
options. It is up to the applications, high-level programming
languages, or libraries to decide whether to use these optional
extensions. For instance, an application may want to turn on or
off the MPTCP mechanism for certain data transfers, or limit
its use to certain interfaces. The syntax and semantics of
the specification is in line with the Posix standard
<xref target="POSIX"/> as much as possible.</t>
<t>There are also various related extensions of the sockets
interface: <xref target="I-D.ietf-shim6-multihome-shim-api"/>
specifies sockets API extensions for a multihoming shim
layer. The API enables interactions between applications and the
multihoming shim layer for advanced locator management and for
access to information about failure detection and path
exploration. Experimental extensions to the sockets API are also
defined for the Host Identity Protocol (HIP)
<xref target="I-D.ietf-hip-native-api"/> in order to manage the
bindings of identifiers and locator. Further related API
extensions exist for IPv6 <xref target="RFC3542"/>, Mobile IP
<xref target="RFC4584"/>, and SCTP
<xref target="I-D.ietf-tsvwg-sctpsocket"/>. There can be
interactions or incompatibilities of these APIs with MPTCP,
which are discussed later in this document.</t>
<t>Some network stack implementations, specially on mobile
devices, have centralized connection managers or other
higher-level APIs to solve multi-interface issues, as surveyed
in <xref target="I-D.ietf-mif-current-practices"/>. Their
interaction with MPTCP is outside the scope of this note.</t>
<t>The target readers of this document are application
developers whose software may benefit
significantly from MPTCP. This document also provides the
necessary information for developers of MPTCP to implement the
API in a TCP/IP network stack.</t>
</section>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119"/>.</t>
<t>This document uses the terminology introduced in
<xref target="I-D.ietf-mptcp-multiaddressed"/>.</t>
</section>
<section title="Comparison of MPTCP and Regular TCP">
<!-- <section title="Impact of MPTCP on Applications"> -->
<t>This section discusses the impact that the use of MPTCP will
have on applications, in comparison to what may be expected from
the use of regular TCP.</t>
<section title="Performance Impact">
<t>One of the key goals of adding multipath capability to TCP
is to improve the performance of a transport connection by
load distribution over separate subflows across potentially
disjoint paths. Furthermore, it is an explicit goal of MPTCP
that it should not provide a worse performing connection that
would have existed through the use of single-path
TCP. A corresponding congestion control algorithm is described
in <xref target="I-D.ietf-mptcp-congestion"/>. The
following sections summarize the performance impact of MPTCP
as seen by an application.</t>
<section title="Throughput">
<t>The most obvious performance improvement that will be
gained with the use of MPTCP is an increase in throughput,
since MPTCP will pool more than one path (where available)
between two endpoints. This will provide greater bandwidth
for an application. If there are shared bottlenecks between
the flows, then the congestion control algorithms will
ensure that load is evenly spread amongst regular and
multipath TCP sessions, so that no end user receives
worse performance than single-path TCP.</t>
<t>This performance increase additionally means that an MPTCP session could
achieve throughput that is greater than the capacity of a
single interface on the device. If any applications make
assumptions about interfaces due to throughput (or vice
versa), they must take this into account (although an MPTCP
implementation must always respect an application's request
for a particular interface).</t>
<t>The transport of MPTCP signaling information results in a
small overhead. If multiple subflows share a same
bottleneck, this overhead slightly reduces the capacity that
is available for data transport. Yet, this potential
reduction of throughput will be neglectible in many usage
scenarios, and the protocol contains optimisations in its
design so that this overhead is minimal.</t>
</section>
<section title="Delay">
<t>If the delays on the constituent subflows of an MPTCP
connection differ, the jitter perceivable to an application
may appear higher as the data is spread across the
subflows. Although MPTCP will ensure in-order delivery to
the application, the application must be able to cope with
the data delivery being burstier than may be usual with
single-path TCP. Since burstiness is commonplace on the
Internet today, it is unlikely that applications will suffer
from such an impact on the traffic profile, but application
authors may wish to consider this in future development.</t>
<t>In addition, applications that make round trip time (RTT)
estimates at the application level may have some
issues. Whilst the average delay calculated will be
accurate, whether this is useful for an application will
depend on what it requires this information for. If a new
application wishes to derive such information, it should
consider how multiple subflows may affect its measurements,
and thus how it may wish to respond. In such a case, an
application may wish to express its scheduling preferences,
as described later in this document.</t>
</section>
<section title="Resilience">
<t>The use of multiple subflows simultaneously means that,
if one should fail, all traffic will move to the remaining
subflow(s), and additionally any lost packets can be
retransmitted on these subflows.</t>
<t>Subflow failure may be caused by issues within the
network, which an application would be unaware of, or
interface failure on the node. An application may, under
certain circumstances, be in a position to be aware of such
failure (e.g. by radio signal strength, or simply an interface
enabled flag), and so must not make assumptions of an MPTCP
flow's stablity based on this. An MPTCP implementation must never override an
application's request for a given interface, however, so the
cases where this issue may be applicable are limited.</t>
</section>
<!-- When mptcp-multiaddressed-02 comes out, it is likely that it will have full support for Backup Paths.
Therefore, we'll probably want to say something along the lines of:
The MPTCP protocol supports signalling to allow a receiver to inform a sender that it wishes a
subflow to be used as a 'backup' path only, i.e. only use it in the event of failure of the other
subflows. This is different from the default behaviour of using all subflows, and may be required
if a backup path costs more to use. Such choices are out of the scope of an application, however,
and it is expected that such settings will be controlled at the operating system level. -->
</section>
<section title="Potential Problems">
<section title="Impact of Middleboxes">
<t>MPTCP has been designed in order to pass through the
majority of middleboxes. Empirical evidence suggests that
new TCP options can successfully be used on most paths in
the Internet. Nevertheless some middleboxes may still refuse
to pass MPTCP messages due to the presence of TCP options,
or they may strip TCP options. If this is the case, MPTCP
should fall back to regular TCP. Although this will not
create a problem for the application (its communication will
be set up either way), there may be additional (and indeed,
user-perceivable) delay while the first handshake fails.
A detailed discussion of the various fallback mechanisms,
for failures occurring at different points in the connection,
is presented in <xref target="I-D.ietf-mptcp-multiaddressed"/>.</t>
<t>There may also be middleboxes that transparently change
the length of content. If such middleboxes are present,
MPTCP's reassembly of the byte stream in the receiver is
difficult. Still, MPTCP can detect such middleboxes and
then fall back to regular TCP. An overview of the impact
of middleboxes is presented in
<xref target="I-D.ietf-mptcp-architecture"/> and MPTCP's
mechanisms to work around these are presented and discussed
in <xref target="I-D.ietf-mptcp-multiaddressed"/>.</t>
<t>MPTCP can also have other unexpected implications. For
instance, intrusion detection systems could be
triggered. A full analysis of MPTCP's impact on such
middleboxes is for further study after deployment
experiments.</t>
</section>
<section title="Outdated Implicit Assumptions">
<t>In regular TCP, there is a one-to-one mapping of the
socket interface to a flow through a network. Since MPTCP can
make use of multiple flows, applications cannot implicitly
rely on this one-to-one mapping any more. Applications that
require the transport along a single path can disable the use
of MPTCP as described later in this document. Examples include
monitoring tools that want to measure the available
bandwidth on a path, or routing protocols such as BGP
that require the use of a specific link.</t>
</section>
<section title="Security Implications">
<t>The support for multiple IP addresses within one MPTCP
connection can result in additional security vulnerabilities,
such as possibilities for attackers to hijack
connections. The protocol design of MPTCP minimizes this
risk. An attacker on one of the paths can cause harm, but
this is hardly an additional security risk compared to
single-path TCP, which is vulnerable to man-in-the-middle
attacks, too. A detailed thread analysis of MPTCP is
published in <xref target="I-D.ietf-mptcp-threat"/>.</t>
</section>
</section>
</section>
<section title="Operation of MPTCP with Legacy Applications">
<!-- <section title="Implications of MPTCP on Existing Interfaces"> -->
<section title="Overview of the MPTCP Network Stack">
<t>MPTCP is an extension of TCP, but it is designed to be
backward compatible for legacy applications. TCP interacts
with other parts of the network stack by different
interfaces. The de facto standard API between TCP and
applications is the sockets interface. The position of MPTCP
in the protocol stack can be illustrated in
<xref target="fig_stack"/>.</t>
<?rfc needLines='15'?>
<figure title="MPTCP protocol stack" anchor="fig_stack" align="center">
<artwork align="center"><![CDATA[
+-------------------------------+
| Application |
+-------------------------------+
^ |
~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~
| v
+-------------------------------+
| MPTCP |
+ - - - - - - - + - - - - - - - +
| Subflow (TCP) | Subflow (TCP) |
+-------------------------------+
| IP | IP |
+-------------------------------+
]]></artwork>
</figure>
<t>In general, MPTCP can affect all interfaces that make
assumptions about the coupling of a TCP connection to a single
IP address and TCP port pair, to one sockets endpoint, to one
network interface, or to a given path through the network.</t>
<t>This means that there are two classes of applications:
<list style="symbols">
<t>Legacy applications: These applications are unaware of
MPTCP and use the existing API towards TCP without any
changes. This is the default case.</t>
<t>MPTCP-aware applications: These applications indicate
support for an enhance MPTCP interface. This document
specified a minimum set of API extensions for such
applications.</t>
</list>
In the following, it is discussed to which extent MPTCP
affects legacy applications using the existing sockets
API. The existing sockets API implies that applications deal
with data structures that store, amongst others, the IP
addresses and TCP port numbers of a TCP connection. A design
objective of MPTCP is that legacy applications can continue to
use the established sockets API without any changes. However,
in MPTCP there is a one-to-many mapping between the socket
endpoint and the subflows. This has several subtle
implications for legacy applications using sockets API
functions.</t>
</section>
<section title="Address Issues">
<section title="Specification of Addresses by Applications">
<t>During binding, an application can either select a
specific address, or bind to INADDR_ANY. Furthermore, on
some systems other socket options (e.g., SO_BINDTODEVICE)
can be used to bind to a specific interface. If an
application uses a specific address or binds to a specific
interface, then MPTCP MUST respect this and not interfere in
the application's choices. If an application binds to
INADDR_ANY, it is assumed that the application does not care
which addresses to use locally. In this case, a local policy
MAY allow MPTCP to automatically set up multiple subflows on
such a connection.</t>
<t>The basic sockets API of MPTCP-aware applications allows
to express further preferences in an MPTCP-compatible way
(e.g. bind to a subset of interfaces only).</t>
</section>
<section title="Querying of Addresses by Applications">
<t>Applications can use the getpeername() or getsockname()
functions in order to retrieve the IP address of the peer or
of the local socket. These functions can be used for various
purposes, including security mechanisms, geo-location, or
interface checks. The socket API was designed with an
assumption that a socket is using just one address, and
since this address is visible to the application, the
application may assume that the information provided by the
functions is the same during the lifetime of a
connection. However, in MPTCP, unlike in TCP, there is a
one-to-many mapping of a connection to subflows, and
subflows can be added and removed while the connections
continues to exist. Therefore, MPTCP cannot expose addresses
by getpeername() or getsockname() that are both valid and
constant during the connection's lifetime.</t>
<t>This problem is addressed as follows: If used by a legacy
application, the MPTCP stack MUST always return the
addresses of the first subflow of an MPTCP connection, in
all circumstances, even if that particular subflow is no
longer in use.</t>
<t>As this address may not be valid any more if the first
subflow is closed, the MPTCP stack MAY close the whole MPTCP
connection if the first subflow is closed (i.e. fate
sharing between the initial subflow and the MPTCP connection
as a whole). Whether to close the whole MPTCP connection by
default SHOULD be controlled by a local policy. Further
experiments are needed to investigate its implications.</t>
<t>The functions getpeername() and getsockname() SHOULD also
always return the addresses of the first subflow if the
socket is used by an MPTCP-aware application, in order to be
consistent with MPTCP-unaware applications, and, e. g., also
with SCTP. Instead of getpeername() or getsockname(),
MPTCP-aware applications can use new API calls, documented
later, in order to retrieve the full list of address pairs
for the subflows in use.</t>
<!-- (issue was discussed in Maastricht)
<t>TBD: If a socket is used by an MPTCP-aware application and
thus does not use the backward compatibility mode, the functions
getpeername() and getsockname() could fail with a new error code
EMULTIPATH. The motivation would be that an MPTCP-aware
application should not use these two functions due to their
ambiguity. Instead, the information about the addresses in use
should be accessed by the basic MPTCP sockets API, if needed.
The alternative would be to always returning the addresses of
the first subflow - which is the best option is currently
unspecified, and may be left to the implementation.</t>
-->
</section>
</section>
<section title="Socket Option Issues">
<section title="General Guideline">
<t>The existing sockets API includes options that modify the
behavior of sockets and their underlying communications
protocols. Various socket options exist on socket, TCP, and
IP level. The value of an option can usually be set by the
setsockopt() system function. The getsockopt() function gets
information. In general, the existing sockets interface
functions cannot configure each MPTCP subflow
individually. In order to be backward compatible, existing
APIs therefore SHOULD apply to all subflows within one
connection, as far as possible.</t>
</section>
<section title="Disabling of the Nagle Algorithm">
<t>One commonly used TCP socket option (TCP_NODELAY)
disables the Nagle algorithm as described in
<xref target="RFC1122"/>. This option is also specified in
the Posix standard <xref target="POSIX"/>. Applications can
use this option in combination with MPTCP exactly in the
same way. It then SHOULD disable the Nagle algorithm for the MPTCP
connection, i.e., all subflows.</t>
<t>In addition, the MPTCP protocol instance MAY use a
different path scheduler algorithm if TCP_NODELAY is
present. For instance, it could use an algorithm that is
optimized for latency-sensitive traffic. Specific
algorithms are outside the scope of this document.</t>
</section>
<section title="Buffer Sizing">
<t>Applications can explicitly configure send and receive
buffer sizes by the sockets API (SO_SNDBUF,
SO_RCVBUF). These socket options can also be used in
combination with MPTCP and then affect the buffer size of
the MPTCP connection. However, when defining buffer sizes,
application programmers should take into account that the
transport over several subflows requires a certain amount of
buffer for resequencing in the receiver. MPTCP may also
require more storage space in the sender, in particular, if
retransmissions are sent over more than one path. In
addition, very small send buffers may prevent MPTCP from
efficiently scheduling data over different
subflows. Therefore, it does not make sense to use MPTCP in
combination with small send or receive buffers.</t>
<t>An MPTCP implementation MAY set a lower bound for send
and receive buffers and treat a small buffer size request as
an implicit request not to use MPTCP.</t>
</section>
<section title="Other Socket Options">
<t>Some network stacks also provide other
implementation-specific socket options or interfaces that
affect TCP's behavior. If a network stack supports MPTCP, it
must be ensured that these options do not interfere.</t>
<!-- Non-standardized options:
Linux TCP socket options: TCP_CORK, TCP_DEFER_ACCEPT,
TCP_INFO, TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL,
TCP_LINGER2, TCP_MAXSEG, TCP_NODELAY, TCP_QUICKACK,
TCP_SYNCNT, TCP_WINDOW_CLAMP
Windows TCP socket options: TCP_BSDURGENT,
TCP_EXPEDITED_1122, TCP_NODELAY
-->
</section>
</section>
<!-- Other interfaces (e. g., ioctl)? -->
<section title="Default Enabling of MPTCP">
<t>It is up to a local policy at the end system whether a
network stack should automatically enable MPTCP for sockets
even if there is no explicit sign of MPTCP awareness of the
corresponding application. Such a choice may be under the
control of the user through system preferences.</t>
<t>The enabling of MPTCP, either by application or by system
defaults, does not necessarily mean that MPTCP will always
be used. Both endpoints must support MPTCP, and there must be
multiple addresses at at least one endpoint, for MPTCP to be
used. Even if those requirements are met, however, MPTCP may
not be immediately used on a connection. It may make sense for
multiple paths to be brought into operation only after a given
period of time, or if the connection is saturated.</t>
<!-- Protocol extensions to support signalling of this level of policy are included in the protocol specification <xref target="I-D.ietf-mptcp-multiaddressed"/> (TBD). -->
</section>
<section title="Summary of Advices to Application Developers">
<t><list style="symbols">
<t>Using the default MPTCP configuration: Like TCP, MPTCP is
designed to be efficient and robust in the default
configuration. Application developers should not explicitly
configure TCP (or MPTCP) features unless this is really
needed.</t>
<t>Socker buffet dimensioning: Multipath transport requires
larger buffers in the receiver for resequencing, as already
explained. Applications should use reasonably buffer sizes
(such as the operating system default values) in order to
fully benefit from MPTCP. A full discussion of buffer sizing
issues is given in <xref target="I-D.ietf-mptcp-multiaddressed"/>.</t>
<t>Facilitating stack-internal heuristics: The path
management and data scheduling by MPTCP is realized by
stack-internal algorithms that may implicitly try to
self-optimize their behavior according to assumed
application needs. For instance, an MPTCP implementation may
use heuristics to determine whether an application requires
delay-sensitive or bulk data transport, using for instance
port numbers, the TCP_NODELAY socket options, or the
application's read/write patterns as input parameters. An
application developer can facilitate the operation of such
heuristics by avoiding atypical interface use cases. For
instance, for long bulk data transfers, it does neither make
sense to enable the TCP_NODELAY socket option, nor is it
reasonable to use many small subsequent socket "send()"
calls with small amounts of data only.</t>
</list></t>
</section>
</section>
<section title="Basic API for MPTCP-aware Applications">
<section title="Design Considerations">
<t>While applications can use MPTCP with the unmodified
sockets API, multipath transport results in many degrees of
freedom. MPTCP manages the data transport over different
subflows automatically. By default, this is transparent to the
application, but an application could use an additional API to
interface with the MPTCP layer and to control important
aspects of the MPTCP implementation's behaviour.</t>
<t>This document describes a basic MPTCP API. The API uses
non-mandatory socket options and only includes a minimum set
of functions that provide an equivalent level of control and
information as exists for regular TCP. It maintains backward
compatibility with legacy applications.</t>
<t>An advanced MPTCP API is outside the scope of this
document. The basic API does not allow a sender or a receiver
to express preferences about the management of paths or the
scheduling of data, even if this can have a significant
performance impact and if an MPTCP implementation could
benefit from additional guidance by applications. A list of
potential further API extensions is provided in the
appendix. The specification of such an advanced API is for
further study and may partly be implementation-specific.</t>
<t>MPTCP mainly affects the sending of data. Therefore, the
basic API only affects the sender side of a data transfer. A
receiver may also have preferences about data transfer
choices, and it may have performance requirements, too. Yet,
the signaling of the receiver's needs is outside of the scope
of this document.</t>
<t>As this document specifies sockets API extensions, it is
written so that the syntax and semantics are in line with the
Posix standard <xref target="POSIX"/> as much as possible.</t>
</section>
<section title="Requirements on the Basic MPTCP API">
<t>Because of the importance of the sockets interface there
are several fundamental design objectives for the basic
interface between MPTCP and applications:
<list style="symbols">
<t>Consistency with existing sockets APIs must be
maintained as far as possible. In order to support the
large base of applications using the original API, a
legacy application must be able to continue to use
standard socket interface functions when run on a system
supporting MPTCP. Also, MPTCP-aware applications should be
able to access the socket without any major changes.</t>
<t>Sockets API extensions must be minimized and independent
of an implementation.</t>
<t>The interface should both handle IPv4 and IPv6.</t>
<!-- <t>TBD: An application should be able to use existing, similar
socket API extensions if they are applicable. Specifically,
an MPTCP aware application should also be able to use
SCTP's application interface functions
<xref target="I-D.ietf-tsvwg-sctpsocket"/>.</t> -->
</list>
</t>
<t>The following is a list of the core requirements for the
basic API:</t>
<t><list style="format REQ%d:" counter="reqs">
<t>Turn on/off MPTCP: An application should be able to
request to turn on or turn off the usage of MPTCP. This
means that an application should be able to explicitly
request the use of MPTCP if this is possible. Applications
should also be able to request not to enable MPTCP and to
use regular TCP transport instead. This can be implicit in
many cases, since MPTCP must disabled by the use of binding
to a specific address. MPTCP may also be enabled if an
application uses a dedicated multipath address family (such
as AF_MULTIPATH, <xref target="I-D.sarolahti-mptcp-af-multipath"/>).</t>
<t>An application should be able to restrict MPTCP to
binding to a given set of addresses.</t>
<t>An application should be able obtain information on the
addresses used by the MPTCP subflows.</t>
<t>An application should be able to extract a unique
identifier for the connection (per endpoint).</t>
</list></t>
<t>The first requirement is the most important one, since some
applications could benefit a lot from MPTCP, but there are
also cases in which it hardly makes sense. The existing
sockets API provides similar mechanisms to enable or disable
advanced TCP features. The second requirement corresponds to
the binding of addresses with the bind() socket call, or,
e.g., explicit device bindings with a SO_BINDTODEVICE
option. The third requirement ensures that there is an
equivalent to getpeername() or getsockname() that is able to
deal with more than one subflow. Finally, it should be
possible for the application to retrieve a unique connection
identifier (local to the endpoint on which it is running) for
the MPTCP connection. This is equivalent to using the
(address, port) pair for a connection identifier in single-path
TCP, which is no longer static in MPTCP.</t>
<t>An application can continue to use getpeername() or
getsockname() in addition to the basic MPTCP API. In that
case, both functions return the corresponding addresses of the
first subflow, as already explained.</t>
</section>
<section title="Sockets Interface Extensions by the Basic MPTCP API">
<section title="Overview">
<t>The basic MPTCP API consist of four new socket options
that are specific to MPTCP. All of these socket options are
defined at TCP level (IPPROTO_TCP).
<list style="symbols">
<t>TCP_MULTIPATH_ENABLE: Enable/disable MPTCP</t>
<t>TCP_MULTIPATH_BIND: Bind MPTCP to a set of given local
addresses</t>
<t>TCP_MULTIPATH_SUBFLOWS: Get the addresses currently used by
the MPTCP subflows</t>
<t>TCP_MULTIPATH_CONNID: Get the local connection identifier
for this MPTCP connection</t>
</list>
Table <xref target="tab_options"/> shows a list of the
socket options for the general configuration of MPTCP. The
first column gives the name of the option. The second and
third columns indicate whether the option can be handled by
the getsockopt() system call and/or by the setsockopt()
system call. The fourth column lists the type of data
structure specified along with the socket option.</t>
<texttable anchor="tab_options" title="Socket options for MPTCP">
<ttcol align='left'>Option name</ttcol>
<ttcol align='center'>Get</ttcol>
<ttcol align='center'>Set</ttcol>
<ttcol align='center'>Data type</ttcol>
<c>TCP_MULTIPATH_ENABLE</c>
<c>o</c>
<c>o</c>
<c>int</c>
<c>TCP_MULTIPATH_BIND</c>
<c></c>
<c>o</c>
<c>list of "struct sockaddr"</c>
<c>TCP_MULTIPATH_SUBFLOWS</c>
<c>o</c>
<c></c>
<c>list of pairs of "struct sockaddr"</c>
<c>TCP_MULTIPATH_CONNID</c>
<c>o</c>
<c></c>
<c>uint32</c>
</texttable>
<t>There are restrictions when these new socket options can be used:
<list style="symbols">
<t>TCP_MULTIPATH_ENABLE: This option SHOULD only be set
before the establishment of a TCP connection. Its value
SHOULD only be read after the establishment of a
connection.</t>
<t>TCP_MULTIPATH_BIND: This option MAY be both applied
before connection setup or during a connection. In the
latter case, it allows MPTCP to use a new address, if
there has been a restriction before connection setup.</t>
<!-- ALAN: I don't understand how this can work: or
it indicates that an address should not be used for the
establishment of further subflows (without affection
established ones).</t> -->
<t>TCP_MULTIPATH_SUBFLOWS: This option is read-only and
SHOULD only be used after connection setup.</t>
<t>TCP_MULTIPATH_CONNID: This option is read-only and
SHOULD only be used after connection setup.</t>
</list>
</t>
</section>
<section title="Enabling and Disabling of MPTCP">
<t>An application can explicitly indicate multipath
capability by setting the TCP_MULTIPATH_ENABLE option with a
value larger than 0. In this case, the MPTCP implementation
SHOULD try to negitiate MPTCP for that connection. Note that
multipath transport will not necessarily be enabled, as it
requires multiple addresses and support in the other
end-system and potentially also on middleboxes.</t>
<t>An application can disable MPTCP setting the option with
a value of 0. In that case, MPTCP MUST NOT be used on that
connection.</t>
<t>After connection establishment, an application can get
the value of the TCP_MULTIPATH_ENABLE option. A value of 0
then means lack of MPTCP support. Any value equal to or
larger than 1 means that MPTCP is supported.</t>
<t>As alternative to setting a socket option, an application
can also use a new, separate address family called
AF_MULTIPATH
<xref target="I-D.sarolahti-mptcp-af-multipath"/>. This
separate address family can be used to exchange multiple
addresses between an application and the standard sockets
API, and additionally acts as an explicit indication that an
application is MPTCP-aware, i.e., that it can deal with the
semantic changes of the sockets API, in particular
concerning getpeername() and getsockname(). The usage of
AF_MULTIPATH is also more flexible with respect to multipath
transport, either IPv4 or IPv6, or both in parallel
<xref target="I-D.sarolahti-mptcp-af-multipath"/>.</t>
</section>
<section title="Binding MPTCP to Specified Addresses">
<t>An application can set the TCP_MULTIPATH_BIND socket
option to announce a set of local IP addresses that MPTCP
may bind to. The parameter of the option is a list of data
structures of type "sockaddr". A MPTCP implementation must
iterate over this list since the length of the structures
may vary and will be deteremined by the address families.
By extension, this option will also control the list of
addresses that can be advertised to the peer via MPTCP
signalling.</t>
<t>If used during the lifetime of a connection, an application
MUST always provide the full list of addresses that MPTCP is
allowed to use. If the option is set, MPTCP MUST only establish
subflows using one of the addresses in that list as source
addresses. MPTCP MUST also use the list as the only set of
addresses it can signal to its peer. It should be noted that
this signal is only a hint, and an MPTCP implementation may
only use a subset of the addresses.</t>
<t>If an address is not present in the new list, MPTCP MUST
close any corresponding subflows (i.e. those using the local
address that is no longer present), and signal the removal
of the address to the peer. If alternative paths are available
using the supplied address list but MPTCP is not currently
using them, an MPTCP implementation SHOULD establish alternative
subflows before undertaking the address removal.</t>
<t>TBD: If it is unreasonable or difficult for an application
to keep track of addresses to provide full lists for every
time TCP_MULTIPATH_BIND is set, we could also provide separate
TCP_MULTIPATH_ADDR_ADD and TCP_MULTIPATH_ADDR_REMOVE options.
Would this be preferable? (The ADD option would provide the
same functionality as bind() before connection setup.)</t>
</section>
<section title="Querying the MPTCP Subflow Addresses">
<t>An application can get a list of the addresses used by
the currently established subflows by means of the
TCP_MULTIPATH_SUBFLOWS option, which cannot be set. The
return value is a list of pairs of "sockaddr" data
structures. In one pair, the first data structure refers to
the local IP address and the second one to the remote IP
address used by the subflow. The list MUST only include
established subflows.</t>
<t>The length of the data structure depends on the number of
subflows, and so an application must iterate over the list
for its length, determining the length of each "sockaddr" data
structure by its address family.</t>
</section>
<section title="Getting a Unique Connection Identifier">
<t>An application that wants a unique identifier for the
connection, analogous to an (address, port) pair in regular
TCP, can use the TCP_MULTIPATH_CONNID option to get a local
connection identifier for the MPTCP connection.</t>
<t>This is a 32-bit number, and SHOULD be the same as the
local connection identifier sent in the MPTCP handshake.</t>
</section>
</section>
<section title="Usage Examples">
<!--
<t>In this section, we describe the usage of the API using the
syntax of the C programming language. We limit the description
to the most important interfaces and data structures that are
either modified or completely new because the MPTCP's API is
otherwise identical to the sockets API
<xref target="POSIX"/>.</t>
-->
<t>TODO: Example C code for the API functions</t>
</section>
</section>
<section title="Other Compatibility Issues">
<!-- New section added as demanded in Maastricht -->
<section title="Usage of the SCTP Socket API">
<t>For dealing with multi-homing, several socket API
extensions have been defined for SCTP
<xref target="I-D.ietf-tsvwg-sctpsocket"/>. As MPTCP realizes
multipath transport from and to multi-homed endsystems, some
of these interface function calls are actually applicable to
MPTCP in a similar way.</t>
<!-- <t>Therefore, an MPTCP implementation SHOULD support the
following functions that are defined for SCTP:</t> -->
<t>The following functions that are defined for SCTP have similar
functionality to the MPTCP API extensions defined earlier:</t>
<list style="symbols">
<t>sctp_bindx()</t>
<t>sctp_connectx()</t>
<t>sctp_getladdrs()</t>
<t>sctp_getpaddrs()</t>
</list>
<t>The syntax and semantics of these functions are described in
<xref target="I-D.ietf-tsvwg-sctpsocket"/>.</t>
<!-- <t>An advantage of supporting the SCTP API is that
applications can use the same consistent interface both for
MPTCP and SCTP. -->
<t>API developers MAY wish to integrate SCTP and MPTCP calls to
provide a consistent interface to the application.
Yet, it must be emphasized that the transport
service provided by MPTCP is different to SCTP, and this is
why not all SCTP API functions can be mapped directly to
MPTCP. Furthermore, a network stack implementing MPTCP does
not necessarily support SCTP and its specific socket interface
extensions. This is why the basic API of MPTCP defines
additional socket options only, which are a backward
compatible extension of TCP's application interface.</t>
</section>
<section title="Incompatibilities with other Multihoming Solutions">
<t>The use of MPTCP can interact with various related sockets
API extensions. The use of a multihoming shim layer conflicts
with multipath transport such as MPTCP or SCTP
<xref target="I-D.ietf-shim6-multihome-shim-api"/>. Care
should be taken for the usage not to confuse with the
overlapping features of other APIs:
<list style="symbols">
<t>SHIM API
<xref target="I-D.ietf-shim6-multihome-shim-api"/>: This
API specifies sockets API extensions for the multihoming
shim layer.</t>
<t>HIP API <xref target="I-D.ietf-hip-native-api"/>: The
Host Identity Protocol (HIP) also results in a new
API.</t>
<t>API for Mobile IPv6 <xref target="RFC4584"/>: For Mobile
IPv6, a significantly extended socket API exists as well.</t>
</list>
In order to avoid any conflict, multiaddressed MPTCP SHOULD
NOT be enabled if a network stack uses SHIM6, HIP, or Mobile
IPv6. Furthermore, applications should not try to use both
the MPTCP API and another multihoming or mobility layer
API.</t>
<t>It is possible, however, that some of the MPTCP
functionality, such as congestion control, could be used in a
SHIM6 or HIP environment. Such operation is outside the scope
of this document.</t>
</section>
<section title="Interactions with DNS">
<t>In multihomed or multiaddressed environments, there are
various issues that are not specific to MPTCP, but have to be
considered, too. These problems are summarized in
<xref target="I-D.ietf-mif-problem-statement"/>.</t>
<t>Specifically, there can be interactions with DNS. Whilst
it is expected that an application will iterate over the list
of addresses returned from a call such as getaddrinfo(), MPTCP
itself MUST NOT make any assumptions about multiple A or AAAA
records from the same DNS query referring to the same host, as
it is very likely that multiple addresses refer to multiple
servers for load balancing purposes.</t>
<t>TODO: Elaborate on DNS</t>
</section>
</section>
<section title="Security Considerations">
<t>Will be added in a later version of this document.</t>
</section>
<section title="IANA Considerations">
<t>No IANA considerations.</t>
</section>
<section title="Conclusion">
<t>This document discusses MPTCP's application implications and
specifies a basic MPTCP API. For legacy applications, it is
ensured that the existing sockets API continues to work.
MPTCP-aware applications can use the basic MPTCP API that
provides some control over the transport layer equivalent to
regular TCP. A more fine-granular interaction between
applications and MPTCP requires an advanced MPTCP API, which is
not specified in this document.</t>
</section>
<section title="Acknowledgments">
<t>Authors sincerely thank to the following people for their
helpful comments to the document: Costin Raiciu</t>
<t>Michael Scharf is supported by the German-Lab project
(http://www.german-lab.de/) funded by the German Federal
Ministry of Education and Research (BMBF). Alan Ford is
supported by Trilogy (http://www.trilogy-project.org/), a
research project (ICT-216372) partially funded by the European
Community under its Seventh Framework Program. The views
expressed here are those of the author(s) only. The European
Commission is not liable for any use that may be made of the
information in this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC0793;
&RFC1122;
&RFC2119;
&MPTCPARCH;
&MPTCP;
&MPTCPSEC;
&MPTCPCC;
<reference anchor="POSIX">
<front>
<title>IEEE Std. 1003.1-2008 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 7, 2008.</title>
</front>
</reference>
</references>
<references title="Informative References">
&AFMP;
&RFC3542;
&RFC4584;
&SHIMAPI;
&HIPAPI;
&SCTPAPI;
&MIFPROBLEM;
&MIFPRACTICE;
</references>
<section title="Requirements on a Future Advanced MPTCP API">
<section title="Design Considerations">
<t>Multipath transport results in many degrees of freedom.
The basic MPTCP API only defines a minimum set of the sockets
API extensions for the interface between the MPTCP layer and
applications, which does not offer much control of the MPTCP
implementation's behaviour. A future, advanced API could
address further features of MPTCP and provide more
control.</t>
<t>Applications that use TCP may have different requirements
on the transport layer. While developers have become used to
the characteristics of regular TCP, new opportunities created
by MPTCP could allow the service provided to be optimised
further. An advanced API could enable MPTCP-aware
applications to specify preferences and control certain
aspects of the behavior, in addition to the simple control
provided by the basic interface. An advanced API could also
address aspects that are completely out-of-scope of the basic
API, for example, the question whether a receiving application
could influence the sending policy.</t>
<t>Furthermore, an advanced MPTCP API could be part of a new
overall interface between the network stack and applications
that addresses other issues as well, such as the split between
identifiers and locators. An API that does not use IP
addresses (but, instead e.g. a connectbyname() function) would
be useful for numerous purposes, independent of MPTCP.</t>
<t>This appendix documents a list of potential usage scenarios
and requirements for the advanded API. The specification and
implementation of a corresponding API is outside the scope
of this document.</t>
</section>
<section title="MPTCP Usage Scenarios and Application Requirements">
<t>There are different MPTCP usage scenarios. An application
that wishes to transmit bulk data will want MPTCP to provide a
high throughput service immediately, through creating and
maximising utilisation of all available subflows. This is the
default MPTCP use case.</t>
<t>But at the other extreme, there are applications that are
highly interactive, but require only a small amount of
throughput, and these are optimally served by low latency and
jitter stability. In such a situation, it would be preferable
for the traffic to use only the lowest latency subflow
(assuming it has sufficient capacity), maybe with one or two
additional subflows for resilience and recovery purposes. The
key challenge for such a strategy is that the delay on a path
may fluctuate significantly and that just always selecting the
path with the smallest delay might result in instability.</t>
<t>The choice between bulk data transport and
latency-sensitive transport affects the scheduler in terms of
whether traffic should be, by default, sent on one subflow or
across several ones. Even if the total bandwidth required is
less than that available on an individual path, it is
desirable to spread this load to reduce stress on potential
bottlenecks, and this is why this method should be the default
for bulk data transport. However, that may not be optimal for
applications that require latency/jitter stability.</t>
<t>In the case of the latter option, a further question
arises: Should additional subflows be used whenever the
primary subflow is overloaded, or only when the primary path
fails (hot-standby)? In other words, is latency stability or
bandwidth more important to the application? This results in
two different options: Firstly, there is the single path which
can overflow into an additional subflow; and secondly there is
single-path with hot-standby, whereby an application may want
an alternative backup subflow in order to improve resilience.
In case that data delivery on the first subflow fails, the
data transport could immediately be continued on the second
subflow, which is idle otherwise.</t>
<t>A further, mostly orthogonal question is whether data
should be duplicated over the different subflows, in
particular if there is spare capacity. This could improve both
the timeliness and reliability of data delivery.</t>
<t>In summary, there are at least three possible performance
objectives for multipath transport (not necessarily
disjoint):
<list style="numbers">
<t>High bandwidth</t>
<t>Low latency and jitter stability</t>
<t>High reliability</t>
</list>
In an advanced API, applications could provide high-level
guidance to the MPTCP implementation concerning these
performance requirements, for instance, which is considered to
be the most important one. The MPTCP stack would then use
internal mechanisms to fulfill this abstract indication of a
desired service, as far as possible. This would both affect
the assignment of data (including retransmissions) to existing
subflows (e.g., 'use all in parallel', 'use as overflow', 'hot
standby', 'duplicate traffic') as well as the decisions when
to set up additional subflows to which addresses. In both
cases different policies can exist, which can be expected to
be implementation-specific.</t>
<t>Therefore, an advanced API could provide a mechanism how
applications can specify their high-level requirements in an
implementation-independent way. One possibility would be to
select one "application profile" out of a number of choices
that characterize typical applications. Yet, as applications
today do not have to inform TCP about their communication
requirements, it requires further studies whether such an
approach would be realistic.</t>
<t>Of course, independent of an advanced API, such
functionality could also partly be achieved by MPTCP-internal
heuristics that infer some application preferences e.g. from
existing socket options, such as TCP_NODELAY. Whether this
would be reliable, and indeed appropriate, is for further
study, too.</t>
</section>
<section title="Potential Requirements on an Advanced MPTCP API">
<t>The following is a list of potential requirements for an
advanced MPTCP API beyond the features of the basic API. It is
included here for information only:</t>
<t><list style="format REQ%d:" counter="reqs">
<t>An application should be able to establish MPTCP
connections without using IP addresses as locators.</t>
<t>An application should be able obtain usage information
and statistics about all subflows (e.g., ratio of traffic
sent via this subflow).</t>
<t>An application should be able to request a change in the
number of subflows in use, thus triggering removal or
addition of subflows. An even finer control granularity
would be a request for the establishment of a new subflow to
a provided destination, or a request for the termination of
a specified, existing subflow.</t>
<t>An application should be able to inform the MPTCP
implementation about its high-level performance
requirements, e.g., in form of a profile.</t>
<t>An application should be able to control the automatic
establishment/termination of subflows. This would imply a
selection among different heuristics of the path manager,
e.g., 'try as soon as possible', 'wait until there is a
bunch of data', etc.</t>
<t>An application should be able to set preferred subflows
or subflow usage policies. This would result in a selection
among different configurations of the multipath
scheduler.</t>
<t>An application should be able to control the level of
redundancy by telling whether segments should be sent on
more than one path in parallel.</t>
</list></t>
<t>An advanced API fulfilling these requirements would allow
application developers to more specifically configure MPTCP.
It could avoid suboptimal decisions of internal, implicit
heuristics. However, it is unclear whether all of these
requirements would have a significant benefit to applications,
since they are going above and beyond what the existing API to
regular TCP provides.</t>
</section>
</section>
<!-- <section title="Other Basic API Design Alternatives">
<t>There are several alternatives to the recommendations of this
document. Some of them have been considered in earlier
versions. In the following, such alternatives are briefly
summarized and the rationals of not using them are
explained.</t>
</section> -->
<section title="Change History of the Document">
<t>Changes compared to version 02:</t>
<list style="symbols">
<t>Definition of the behavior of getpeername() and
getsockname() when being called by an MPTCP-aware
application.</t>
<t>Discussion of the possiblity that an MPTCP implementation
could support the SCTP API, as far as it is applicable to MPTCP.</t>
<t>Various editorial fixes.</t>
</list>
<t>Changes compared to version 01:</t>
<list style="symbols">
<t>Second half of the document completely restructured</t>
<t>Separation between a basic API and an advanced API: The
focus of the document is the basic API only; all text
concerning a potential extended API is moved to the
appendix</t>
<t>Several clarifications, e. g., concerning buffer sizeing
and the use of different scheduling strategies triggered by
TCP_NODELAY</t>
<t>Additional references</t>
</list>
<t>Changes compared to version 00:</t>
<list style="symbols">
<t>Distinction between legacy and MPTCP-aware applications</t>
<t>Guidance concerning default enabling, reaction to the shutdown of the first subflow, etc.</t>
<t>Reference to a potential use of AF_MULTIPATH</t>
<t>Additional references to related work</t>
</list>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:33:55 |