draft-ietf-mptcp-api-07.txt   rfc6897.txt 
Internet Engineering Task Force M. Scharf Internet Engineering Task Force (IETF) M. Scharf
Internet-Draft Alcatel-Lucent Bell Labs Request for Comments: 6897 Alcatel-Lucent Bell Labs
Intended status: Informational A. Ford Category: Informational A. Ford
Expires: July 23, 2013 Cisco ISSN: 2070-1721 Cisco
January 19, 2013 March 2013
MPTCP Application Interface Considerations Multipath TCP (MPTCP) Application Interface Considerations
draft-ietf-mptcp-api-07
Abstract Abstract
Multipath TCP (MPTCP) adds the capability of using multiple paths to Multipath TCP (MPTCP) adds the capability of using multiple paths to
a regular TCP session. Even though it is designed to be totally a regular TCP session. Even though it is designed to be totally
backward compatible to applications, the data transport differs backward compatible to applications, the data transport differs
compared to regular TCP, and there are several additional degrees of compared to regular TCP, and there are several additional degrees of
freedom that applications may wish to exploit. This document freedom that applications may wish to exploit. This document
summarizes the impact that MPTCP may have on applications, such as summarizes the impact that MPTCP may have on applications, such as
changes in performance. Furthermore, it discusses compatibility changes in performance. Furthermore, it discusses compatibility
issues of MPTCP in combination with non-MPTCP-aware applications. issues of MPTCP in combination with non-MPTCP-aware applications.
Finally, the document describes a basic application interface which Finally, the document describes a basic application interface that is
is a simple extension of TCP's interface for MPTCP-aware a simple extension of TCP's interface for MPTCP-aware applications.
applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 23, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6897.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology .....................................................4
3. Comparison of MPTCP and Regular TCP . . . . . . . . . . . . . 5 3. Comparison of MPTCP and Regular TCP .............................5
3.1. Effect on Performance . . . . . . . . . . . . . . . . . . 5 3.1. Effect on Performance ......................................5
3.1.1. Throughput . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Throughput ..........................................5
3.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Delay ...............................................6
3.1.3. Resilience . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3. Resilience ..........................................7
3.2. Potential Problems . . . . . . . . . . . . . . . . . . . . 8 3.2. Potential Problems .........................................8
3.2.1. Impact of Middleboxes . . . . . . . . . . . . . . . . 8 3.2.1. Impact of Middleboxes ...............................8
3.2.2. Dealing with Multiple Addresses Inside Applications . 9 3.2.2. Dealing with Multiple Addresses inside
3.2.3. Security Implications . . . . . . . . . . . . . . . . 10 Applications ........................................9
4. Operation of MPTCP with Legacy Applications . . . . . . . . . 10 3.2.3. Security Implications ..............................10
4.1. Overview of the MPTCP Network Stack . . . . . . . . . . . 10 4. Operation of MPTCP with Legacy Applications ....................10
4.2. Address Issues . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Overview of the MPTCP Network Stack .......................10
4.2.1. Specification of Addresses by Applications . . . . . . 11 4.2. Address Issues ............................................11
4.2.2. Querying of Addresses by Applications . . . . . . . . 12 4.2.1. Specification of Addresses by Applications .........11
4.3. MPTCP Connection Management . . . . . . . . . . . . . . . 13 4.2.2. Querying of Addresses by Applications ..............12
4.3.1. Reaction to Close Call by Application . . . . . . . . 13 4.3. MPTCP Connection Management ...............................13
4.3.2. Other Connection Management Functions . . . . . . . . 13 4.3.1. Reaction to Close Call by Application ..............13
4.4. Socket Option Issues . . . . . . . . . . . . . . . . . . . 13 4.3.2. Other Connection Management Functions ..............13
4.4.1. General Guideline . . . . . . . . . . . . . . . . . . 13 4.4. Socket Option Issues ......................................13
4.4.2. Disabling of the Nagle Algorithm . . . . . . . . . . . 14 4.4.1. General Guideline ..................................13
4.4.3. Buffer Sizing . . . . . . . . . . . . . . . . . . . . 14 4.4.2. Disabling of the Nagle Algorithm ...................13
4.4.4. Other Socket Options . . . . . . . . . . . . . . . . . 14 4.4.3. Buffer Sizing ......................................14
4.5. Default Enabling of MPTCP . . . . . . . . . . . . . . . . 15 4.4.4. Other Socket Options ...............................14
4.6. Summary of Advice to Application Developers . . . . . . . 15 4.5. Default Enabling of MPTCP .................................14
5. Basic API for MPTCP-aware Applications . . . . . . . . . . . . 16 4.6. Summary of Advice to Application Developers ...............15
5.1. Design Considerations . . . . . . . . . . . . . . . . . . 16
5.2. Requirements on the Basic MPTCP API . . . . . . . . . . . 16 5. Basic API for MPTCP-Aware Applications .........................15
5.3. Sockets Interface Extensions by the Basic MPTCP API . . . 17 5.1. Design Considerations .....................................15
5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Requirements on the Basic MPTCP API .......................16
5.3.2. Enabling and Disabling of MPTCP . . . . . . . . . . . 19 5.3. Sockets Interface Extensions by the Basic MPTCP API .......17
5.3.3. Binding MPTCP to Specified Addresses . . . . . . . . . 20 5.3.1. Overview ...........................................17
5.3.4. Querying the MPTCP Subflow Addresses . . . . . . . . . 20 5.3.2. Enabling and Disabling of MPTCP ....................19
5.3.5. Getting a Unique Connection Identifier . . . . . . . . 21 5.3.3. Binding MPTCP to Specified Addresses ...............19
6. Other Compatibility Issues . . . . . . . . . . . . . . . . . . 21 5.3.4. Querying the MPTCP Subflow Addresses ...............20
6.1. Usage of TLS over MPTCP . . . . . . . . . . . . . . . . . 21 5.3.5. Getting a Unique Connection Identifier .............20
6.2. Usage of the SCTP Socket API . . . . . . . . . . . . . . . 21 6. Other Compatibility Issues .....................................21
6.3. Incompatibilities with other Multihoming Solutions . . . . 22 6.1. Usage of TLS over MPTCP ...................................21
6.4. Interactions with DNS . . . . . . . . . . . . . . . . . . 22 6.2. Usage of the SCTP Sockets API .............................21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6.3. Incompatibilities with Other Multihoming Solutions ........21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 6.4. Interactions with DNS .....................................22
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations ........................................22
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 8. Conclusion .....................................................23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Acknowledgments ................................................23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10. References ....................................................24
11.2. Informative References . . . . . . . . . . . . . . . . . . 25 10.1. Normative References .....................................24
Appendix A. Requirements on a Future Advanced MPTCP API . . . . . 26 10.2. Informative References ...................................24
A.1. Design Considerations . . . . . . . . . . . . . . . . . . 26 Appendix A. Requirements on a Future Advanced MPTCP API ...........26
A.2. MPTCP Usage Scenarios and Application Requirements . . . . 27 A.1. Design Considerations ......................................26
A.3. Potential Requirements on an Advanced MPTCP API . . . . . 29 A.2. MPTCP Usage Scenarios and Application Requirements .........27
A.4. Integration with the SCTP Socket API . . . . . . . . . . . 30 A.3. Potential Requirements on an Advanced MPTCP API ............29
Appendix B. Change History of the Document . . . . . . . . . . . 31 A.4. Integration with the SCTP Sockets API ......................30
1. Introduction 1. Introduction
Multipath TCP adds the capability of using multiple paths to a Multipath TCP adds the capability of using multiple paths to a
regular TCP session [1]. The motivations for this extension include regular TCP session [1]. The motivations for this extension include
increasing throughput, overall resource utilisation, and resilience increasing throughput, overall resource utilization, and resilience
to network failure, and these motivations are discussed, along with to network failure, and these motivations are discussed, along with
high-level design decisions, as part of the Multipath TCP high-level design decisions, as part of the multipath TCP
architecture [4]. The MPTCP protocol [5] offers the same reliable, architecture [4]. MPTCP [5] offers the same reliable, in-order,
in-order, byte-stream transport as TCP, and is designed to be byte-stream transport as TCP and is designed to be backward
backward compatible with both applications and the network layer. It compatible with both applications and the network layer. It requires
requires support inside the network stack of both endpoints. support inside the network stack of both endpoints.
This document first presents the effects that MPTCP may have on This document first presents the effects that MPTCP may have on
applications, such as performance changes compared to regular TCP. applications, such as performance changes compared to regular TCP.
Second, it defines the interoperation of MPTCP and applications that Second, it defines the interoperation of MPTCP and applications that
are unaware of the multipath transport. MPTCP is designed to be are unaware of the multipath transport. MPTCP is designed to be
usable without any application changes, but some compatibility issues usable without any application changes, but some compatibility issues
have to be taken into account. Third, this memo specifies a basic have to be taken into account. Third, this memo specifies a basic
Application Programming Interface (API) for MPTCP-aware applications. Application Programming Interface (API) for MPTCP-aware applications.
The API presented here is an extension to the regular TCP API to The API presented here is an extension to the regular TCP API to
allow an MPTCP-aware application the equivalent level of control and allow an MPTCP-aware application the equivalent level of control and
skipping to change at page 4, line 38 skipping to change at page 4, line 17
The de facto standard API for TCP/IP applications is the "sockets" The de facto standard API for TCP/IP applications is the "sockets"
interface [8]. This document provides an abstract definition of interface [8]. This document provides an abstract definition of
MPTCP-specific extensions to this interface. These are operations MPTCP-specific extensions to this interface. These are operations
that can be used by an application to get or set additional MPTCP- that can be used by an application to get or set additional MPTCP-
specific information on a socket, in order to provide an equivalent specific information on a socket, in order to provide an equivalent
level of information and control over MPTCP as exists for an level of information and control over MPTCP as exists for an
application using regular TCP. It is up to the applications, high- application using regular TCP. It is up to the applications, high-
level programming languages, or libraries to decide whether to use level programming languages, or libraries to decide whether to use
these optional extensions. For instance, an application may want to these optional extensions. For instance, an application may want to
turn on or off the MPTCP mechanism for certain data transfers, or turn on or off the MPTCP mechanism for certain data transfers or
limit its use to certain interfaces. The abstract specification is limit its use to certain interfaces. The abstract specification is
in line with the Posix standard [8] as much as possible. in line with the Portable Operating System Interface (POSIX) standard
[8] as much as possible.
An advanced API for MPTCP is outside the scope of this document. An advanced API for MPTCP is outside the scope of this document.
Such an advanced API could offer a more fine-grained control over Such an advanced API could offer a more fine-grained control over
multipath transport functions and policies. The appendix includes a multipath transport functions and policies. The appendix includes
brief, non-compulsory list of potential features of such an advanced a brief, non-compulsory list of potential features of such an
API. advanced API.
There can be interactions or incompatibilities of MPTCP with other There can be interactions or incompatibilities of MPTCP with other
APIs or socket interface extensions, which are discussed later in APIs or sockets interface extensions, which are discussed later in
this document. Some network stack implementations, specially on this document. Some network stack implementations, especially on
mobile devices, have centralized connection managers or other higher- mobile devices, have centralized connection managers or other
level APIs to solve multi-interface issues, as surveyed in [15]. higher-level APIs to solve multi-interface issues, as surveyed in
[15]. Their interaction with MPTCP is outside the scope of this
Their interaction with MPTCP is outside the scope of this note. document.
The target readers of this document are application developers whose The target readers of this document are application developers whose
software may benefit significantly from MPTCP. This document also software may benefit significantly from MPTCP. This document also
provides the necessary information for developers of MPTCP to provides the necessary information for developers of MPTCP to
implement the API in a TCP/IP network stack. implement the API in a TCP/IP network stack.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 5, line 33 skipping to change at page 5, line 18
o Legacy API: The interface towards TCP that is currently used by o Legacy API: The interface towards TCP that is currently used by
applications. This document explains the effect of MPTCP for such applications. This document explains the effect of MPTCP for such
applications, as well as resulting issues. applications, as well as resulting issues.
o Basic API: A simple extension of TCP's interface for applications o Basic API: A simple extension of TCP's interface for applications
that are aware of MPTCP. This document abstractly describes this that are aware of MPTCP. This document abstractly describes this
interface, which provides access to multipath address information interface, which provides access to multipath address information
and a level of control equivalent to regular TCP. and a level of control equivalent to regular TCP.
o Advanced API: An API that offers more fine-grained control over o Advanced API: An API that offers more fine-grained control over
the MPTCP behavior. Its specification is outside scope of this the behavior of MPTCP. Its specification is outside the scope of
document. this document.
3. Comparison of MPTCP and Regular TCP 3. Comparison of MPTCP and Regular TCP
This section discusses the effect of MPTCP on performance as seen by This section discusses the effect of MPTCP on performance as seen by
an application, in comparison to what may be expected from the use of an application, in comparison to what may be expected from the use of
regular TCP. regular TCP.
3.1. Effect on Performance 3.1. Effect on Performance
One of the key goals of adding multipath capability to TCP is to One of the key goals of adding multipath capability to TCP is to
skipping to change at page 6, line 35 skipping to change at page 6, line 19
(although an MPTCP implementation must always respect an (although an MPTCP implementation must always respect an
application's request for a particular interface). application's request for a particular interface).
Furthermore, the flexibility of MPTCP to add and remove subflows as Furthermore, the flexibility of MPTCP to add and remove subflows as
paths change availability could lead to a greater variation, and more paths change availability could lead to a greater variation, and more
frequent change, in connection bandwidth. Applications that adapt to frequent change, in connection bandwidth. Applications that adapt to
available bandwidth (such as video and audio streaming) may need to available bandwidth (such as video and audio streaming) may need to
adjust some of their assumptions to most effectively take this into adjust some of their assumptions to most effectively take this into
account. account.
The transport of MPTCP signalling information results in a small The transport of MPTCP signaling information results in a small
overhead. The use of MPTCP instead of a single TCP connection overhead. The use of MPTCP instead of a single TCP connection
therefore results in a smaller goodput. Also, if multiple subflows therefore results in a smaller goodput. Also, if multiple subflows
share a same bottleneck, this overhead slightly reduces the capacity share a same bottleneck, this overhead slightly reduces the capacity
that is available for data transport. Yet, this potential reduction that is available for data transport. Yet, this potential reduction
of throughput will be negligible in many usage scenarios, and the of throughput will be negligible in many usage scenarios, and the
protocol contains optimisations in its design so that this overhead protocol contains optimizations in its design so that this overhead
is minimal. is minimal.
3.1.2. Delay 3.1.2. Delay
The benefits of MPTCP regarding throughput and resilience may come at The benefits of MPTCP regarding throughput and resilience may come at
some cost regarding data delivery delay and delay jitter. some cost regarding data delivery delay and delay jitter.
If the delays on the constituent subflows of an MPTCP connection If the delays on the constituent subflows of an MPTCP connection
differ, the jitter perceivable to an application may appear higher as differ, the jitter perceivable to an application may appear higher as
the data are spread across the subflows. Although MPTCP will ensure the data are spread across the subflows. Although MPTCP will ensure
in-order delivery to the application, the data delivery could be more in-order delivery to the application, the data delivery could be more
bursty than may be usual with single-path TCP, in particular on bursty than may be usual with single-path TCP, in particular on
highly asymmetric paths. highly asymmetric paths.
Applications with high real-time requirements might be affected by Applications with high real-time requirements might be affected by
that. One possibly remedy is to disable MPTCP for such jitter- such a scenario. One possible remedy is to disable MPTCP for such
sensitive application, either by using the Basic API defined in this jitter-sensitive applications, either by using the basic API defined
document, or by other means, such as system policies. in this document, or by other means, such as system policies.
However, the actual delay and jitter of data transport over MPTCP However, the actual delay and jitter of data transport over MPTCP
depends on the scheduling and congestion control algorithms used for depend on the scheduling and congestion control algorithms used for
sending data, as well as the heuristics to establish and shutdown sending data, as well as the heuristics to establish and shut down
subflows. A sender can implement strategies to minimize the delay subflows. A sender can implement strategies to minimize the delay
jitter seen by applications, but this requires an accurate estimation jitter seen by applications, but this requires an accurate estimation
of the path characteristics. If the scheduling decisions are of the path characteristics. If the scheduling decisions are
suboptimal or if assumptions about the path characteristics turn out suboptimal or if assumptions about the path characteristics turn out
to be wrong, delay jitter may be increased and affect delay-sensitive to be wrong, delay jitter may be increased and affect delay-sensitive
applications. In general, for a delay-sensitive application, it applications. In general, for a delay-sensitive application, it
would be desirable to select an appropriate congestion control would be desirable to select an appropriate congestion control
algorithm for its traffic needs. algorithm for its traffic needs.
Alternatively, MPTCP could be used in high reliability, rather than Alternatively, MPTCP could be used in high-reliability, rather than
high throughput, modes of operation, such as by mirroring traffic on high-throughput, modes of operation, such as by mirroring traffic on
subflows, or by only using additional subflows for hot standby. subflows, or by only using additional subflows for hot standby.
These methods of traffic scheduling would not cause delay variation These methods of traffic scheduling would not cause delay variation
in the same way. These additional modes, and the selection of in the same way. These additional modes, and the selection of
alternative scheduling algorithms, would need to be indicated by an alternative scheduling algorithms, would need to be indicated by an
advanced API, the specification of which requires further analysis advanced API, the specification of which requires further analysis
and is outside the scope of this document. and is outside the scope of this document.
If data transport on one subflow fails, the retransmissions inside If data transport on one subflow fails, the retransmissions inside
MPTCP could affect the delivery delay to the application. Yet, MPTCP could affect the delivery delay to the application. Yet,
without MPTCP that data or the whole connection might have been lost, without MPTCP that data or the whole connection might have been lost,
and other reliability mechanisms (e.g. application-level recovery) and other reliability mechanisms (e.g., application-level recovery)
would likely have an even larger delay impact. would likely have an even larger delay impact.
In addition, applications that make round trip time (RTT) estimates In addition, applications that make round-trip time (RTT) estimates
at the application level may have some issues. Whilst the average at the application level may have some issues. Whilst the average
delay calculated will be accurate, whether this is useful for an delay calculated will be accurate, whether this is useful for an
application will depend on what it requires this information for. If application will depend on what it requires this information for. If
a new application wishes to derive such information, it should a new application wishes to derive such information, it should
consider how multiple subflows may affect its measurements, and thus consider how multiple subflows may affect its measurements and thus
how it may wish to respond. In such a case, an application may wish how it may wish to respond. In such a case, an application may wish
to express its scheduling preferences, as described later in this to express its scheduling preferences, as described later in this
document. document.
3.1.3. Resilience 3.1.3. Resilience
Another performance improvement through the use of MPTCP is better Another performance improvement through the use of MPTCP is better
resilience. The use of multiple subflows simultaneously means that, resilience. The use of multiple subflows simultaneously means that
if one should fail, all traffic will move to the remaining if one should fail, all traffic will move to the remaining
subflow(s), and additionally any lost packets can be retransmitted on subflow(s), and additionally any lost packets can be retransmitted on
these subflows. these subflows.
As one special case, the MPTCP protocol can be used with only one As one special case, MPTCP can be used with only one active subflow
active subflow at a given point in time. In that case, resilience at a given point in time. In that case, resilience compared to
compared to single-path TCP is improved. MPTCP also supports make- single-path TCP is improved. MPTCP also supports make-before-break
before-break and break-before-make handovers between subflows. In and break-before-make handovers between subflows. In both cases, the
both cases, the MPTCP connection can survive an unavailability or MPTCP connection can survive an unavailability or change of an IP
change of an IP address (e.g., due to shutdown of an interface or address (e.g., due to shutdown of an interface or handover). MPTCP
handover). MPTCP close or resets the MPTCP connection separately closes or resets the MPTCP connection separately from the individual
from the individual subflows, as described in [5]. subflows, as described in [5].
Subflow failure may be caused by issues within the network, which an Subflow failure may be caused by issues within the network, which an
application would be unaware of, or interface failure on the node. application would be unaware of, or interface failure on the node.
An application may, under certain circumstances, be in a position to 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 be aware of such failure (e.g., by radio signal strength, or simply
interface enabled flag), and so must not make assumptions of an MPTCP an interface enabled flag), and so must not make assumptions of an
flow's stability based on this. An MPTCP implementation must never MPTCP flow's stability based on this. An MPTCP implementation must
override an application's request for a given interface, however, so never override an application's request for a given interface,
the cases where this issue may be applicable are limited. however, so the cases where this issue may be applicable are limited.
3.2. Potential Problems 3.2. Potential Problems
3.2.1. Impact of Middleboxes 3.2.1. Impact of Middleboxes
MPTCP has been designed in order to pass through the majority of MPTCP has been designed to pass through the majority of middleboxes.
middleboxes. Empirical evidence suggests that new TCP options can Empirical evidence suggests that new TCP options can successfully be
successfully be used on most paths in the Internet [22]. used on most paths in the Internet [22]. Nevertheless, some
Nevertheless some middleboxes may still refuse to pass MPTCP messages middleboxes may still refuse to pass MPTCP messages due to the
due to the presence of TCP options, or they may strip TCP options. presence of TCP options, or they may strip TCP options. If this is
If this is the case, MPTCP falls back to regular TCP. Although this the case, MPTCP falls back to regular TCP. Although this will not
will not create a problem for the application (its communication will create a problem for the application (its communication will be set
be set up either way), there may be additional (and indeed, user- up either way), there may be additional (and indeed, user-
perceivable) delay while the first handshake fails. Therefore, an perceivable) delay while the first handshake fails. Therefore, an
alternative approach could be to try both MPTCP and regular TCP alternative approach could be to try both MPTCP and regular TCP
connection attempts at the same time, and respond to whichever connection attempts at the same time and respond to whichever replies
replies first in a similar fashion to the "Happy Eyeballs" mechanism first, in a fashion similar to the "Happy Eyeballs" mechanism for
for IPv6 [16]. One could also apply a shorter timeout on the MPTCP IPv6 [16]. One could also apply a shorter timeout on the MPTCP
attempt and thus reduce the setup delay if fallback to regular TCP is attempt and thus reduce the setup delay if fallback to regular TCP is
needed. needed.
An MPTCP implementation can learn the rate of MPTCP connection An MPTCP implementation can learn the rate of MPTCP connection
attempt successes or failures to particular hosts or networks, and on attempt successes or failures to particular hosts or networks, and on
particular interfaces, and could therefore learn heuristics of when particular interfaces, and could therefore learn heuristics of when
and when not to use MPTCP. A detailed discussion of the various and when not to use MPTCP. A detailed discussion of the various
fallback mechanisms, for failures occurring at different points in fallback mechanisms, for failures occurring at different points in
the connection, is presented in [5]. It must be emphasized that all the connection, is presented in [5]. It must be emphasized that all
such heuristics could also fail, and learning can be difficult in such heuristics could also fail, and learning can be difficult in
certain environements, e.g., if the host is mobile. certain environments, e.g., if the host is mobile.
There may also be middleboxes that transparently change the length of There may also be middleboxes that transparently change the length of
content. If such middleboxes are present, MPTCP's reassembly of the content. If such middleboxes are present, MPTCP's reassembly of the
byte stream in the receiver is difficult. Still, MPTCP can detect byte stream in the receiver is difficult. Still, MPTCP can detect
such middleboxes and then fall back to regular TCP. An overview of such middleboxes and then fall back to regular TCP. An overview of
the impact of middleboxes is presented in [4] and MPTCP's mechanisms the impact of middleboxes is presented in [4], and MPTCP's mechanisms
to work around these are presented and discussed in [5]. to work around these issues are presented and discussed in [5].
MPTCP can also have other unexpected implications. For instance, MPTCP can also have other unexpected implications. For instance,
intrusion detection systems could be triggered. A full analysis of intrusion detection systems could be triggered. A full analysis of
MPTCP's impact on such middleboxes is for further study after MPTCP's impact on such middleboxes is for further study after
deployment experiments. deployment experiments.
3.2.2. Dealing with Multiple Addresses Inside Applications 3.2.2. Dealing with Multiple Addresses inside Applications
In regular TCP, there is a one-to-one mapping of the socket interface In regular TCP, there is a one-to-one mapping of the sockets
to a flow through a network. Since MPTCP can make use of multiple interface to a flow through a network. Since MPTCP can make use of
subflows, applications cannot implicitly rely on this one-to-one multiple subflows, applications cannot implicitly rely on this
mapping any more. one-to-one mapping any more.
Whilst this doesn't matter for most applications, some applications Whilst this doesn't matter for most applications, some applications
may need to adapt to the presence of multiple addresses, because may need to adapt to the presence of multiple addresses, because
implicit assumptions are outdated. In the following, selected implicit assumptions are outdated. In this section, selected
examples for resulting issues are discussed. The question whether examples for resulting issues are discussed. The question of whether
such implicit assumptions matter is an application-level decision, such implicit assumptions matter is an application-level decision,
and this document only provides general guidance and a basic API to and this document only provides general guidance and a basic API to
retrieve relevant information. retrieve relevant information.
A few applications require the transport to be along a single path; A few applications require the transport to be along a single path;
they can disable the use of MPTCP as described later in this they can disable the use of MPTCP as described later in this
document. Examples include monitoring tools that want to measure the document. Examples include monitoring tools that want to measure the
available bandwidth on a path, or routing protocols such as BGP that available bandwidth on a path, or routing protocols such as BGP that
require the use of a specific link. require the use of a specific link.
skipping to change at page 10, line 10 skipping to change at page 9, line 40
interface to the network stack. This implies that an MPTCP-unaware interface to the network stack. This implies that an MPTCP-unaware
application will track the IP addresses of the first subflow only. application will track the IP addresses of the first subflow only.
IP addresses used by follow-up subflows will be ignored. Second, an IP addresses used by follow-up subflows will be ignored. Second, an
MPTCP-aware application can use the basic API described in this MPTCP-aware application can use the basic API described in this
document to monitor the IP addresses of all subflows, e.g., for document to monitor the IP addresses of all subflows, e.g., for
logging mechanisms. If an MPTCP connection uses several subflows, logging mechanisms. If an MPTCP connection uses several subflows,
this will possibly imply that data structures have to be adapted and this will possibly imply that data structures have to be adapted and
that the amount of data that has to be logged and stored per that the amount of data that has to be logged and stored per
connection will increase. connection will increase.
A MPTCP implementation may choose to maintain an MPTCP connection An MPTCP implementation may choose to maintain an MPTCP connection
even if the IP address of the original subflow is no longer allocated even if the IP address of the original subflow is no longer allocated
to a host, depending on the policy concerning the first subflow to a host, depending on the policy concerning the first subflow
(fate-sharing, see Section 4.2.2). In this case, the IP address (fate-sharing; see Section 4.2.2). In this case, the IP address
exposed to an MPTCP-unaware application can differ to the addresses exposed to an MPTCP-unaware application can differ from the addresses
actually being used by MPTCP. It is even possible that the IP actually being used by MPTCP. It is even possible that the IP
address gets assigned to another host during the lifetime of an MPTCP address gets assigned to another host during the lifetime of an MPTCP
connection. As further discussed below, this could be an issue if connection. As further discussed below, this could be an issue if
the IP addresses are exchanged by applications, e.g., inside the the IP addresses are exchanged by applications, e.g., inside the
application protocol. This issue can be addressed by enabling fate application protocol. This issue can be addressed by enabling fate-
sharing, at the cost of resilience, because the MPTCP connection then sharing, at the cost of resilience, because the MPTCP connection then
cannot close the initial subflow. cannot close the initial subflow.
3.2.3. Security Implications 3.2.3. Security Implications
The support for multiple IP addresses within one MPTCP connection can The support for multiple IP addresses within one MPTCP connection can
result in additional security vulnerabilities, such as possibilities result in additional security vulnerabilities, such as possibilities
for attackers to hijack connections. The protocol design of MPTCP for attackers to hijack connections. The protocol design of MPTCP
minimizes this risk. An attacker on one of the paths can cause harm, minimizes this risk. An attacker on one of the paths can cause harm,
but this is hardly an additional security risk compared to single- but this is hardly an additional security risk compared to single-
skipping to change at page 10, line 41 skipping to change at page 10, line 23
A detailed threat analysis of MPTCP is published in [6]. A detailed threat analysis of MPTCP is published in [6].
Impact on Transport Layer Security (TLS) is discussed in Section 6.1. Impact on Transport Layer Security (TLS) is discussed in Section 6.1.
4. Operation of MPTCP with Legacy Applications 4. Operation of MPTCP with Legacy Applications
4.1. Overview of the MPTCP Network Stack 4.1. Overview of the MPTCP Network Stack
MPTCP is an extension of TCP, but it is designed to be backward MPTCP is an extension of TCP, but it is designed to be backward
compatible for legacy (MPTCP-unaware) applications. TCP interacts compatible for legacy (MPTCP-unaware) applications. TCP interacts
with other parts of the network stack by different interfaces. The with other parts of the network stack via different interfaces. The
de facto standard API between TCP and applications is the sockets de facto standard API between TCP and applications is the sockets
interface. The position of MPTCP in the protocol stack is interface. The position of MPTCP in the protocol stack is
illustrated in Figure 1. illustrated in Figure 1.
+-------------------------------+ +-------------------------------+
| Application | | Application |
+-------------------------------+ +-------------------------------+
^ | ^ |
~~~~~~~~~~~|~Socket Interface|~~~~~~~~~~~ ~~~~~~~~~~|~Sockets Interface|~~~~~~~~~
| v | v
+-------------------------------+ +-------------------------------+
| MPTCP | | MPTCP |
+ - - - - - - - + - - - - - - - + + - - - - - - - + - - - - - - - +
| Subflow (TCP) | Subflow (TCP) | | Subflow (TCP) | Subflow (TCP) |
+-------------------------------+ +-------------------------------+
| IP | IP | | IP | IP |
+-------------------------------+ +-------------------------------+
Figure 1: MPTCP protocol stack Figure 1: MPTCP Protocol Stack
In general, MPTCP can affect all interfaces that make assumptions In general, MPTCP can affect all interfaces that make assumptions
about the coupling of a TCP connection to a single IP address and TCP 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 port pair, to one socket endpoint, to one network interface, or to a
given path through the network. given path through the network.
This means that there are two classes of applications: This means that there are two classes of applications:
o Legacy applications: These applications are unaware of MPTCP and o Legacy applications: These applications are unaware of MPTCP and
use the existing API towards TCP without any changes. This is the use the existing API towards TCP without any changes. This is the
default case. default case.
o MPTCP-aware applications: These applications indicate support for o MPTCP-aware applications: These applications indicate support for
an enhanced MPTCP interface. This document specifies a minimum an enhanced MPTCP interface. This document specifies a minimum
set of API extensions for such applications. set of API extensions for such applications.
In the following, it is discussed to what extent MPTCP affects legacy In the following sections, it is discussed to what extent MPTCP
applications using the existing sockets API. The existing sockets affects legacy applications using the existing sockets API. The
API implies that applications deal with data structures that store, existing sockets API implies that applications deal with data
amongst others, the IP addresses and TCP port numbers of a TCP structures that store, amongst others, the IP addresses and TCP port
connection. A design objective of MPTCP is that legacy applications numbers of a TCP connection. A design objective of MPTCP is that
can continue to use the established sockets API without any changes. legacy applications can continue to use the established sockets API
However, in MPTCP there is a one-to-many mapping between the socket without any changes. However, in MPTCP there is a one-to-many
endpoint and the subflows. This has several subtle implications for mapping between the socket endpoint and the subflows. This has
legacy applications using sockets API functions. several subtle implications for legacy applications using sockets API
functions.
4.2. Address Issues 4.2. Address Issues
4.2.1. Specification of Addresses by Applications 4.2.1. Specification of Addresses by Applications
During binding, an application can either select a specific address, During binding, an application can either select a specific address
or bind to INADDR_ANY. Furthermore, on some systems other socket or bind to INADDR_ANY. Furthermore, on some systems other socket
options (e.g., SO_BINDTODEVICE) can be used to bind to a specific 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 interface. If an application uses a specific address or binds to a
specific interface, then MPTCP MUST respect this and not interfere in specific interface, then MPTCP MUST respect this and not interfere in
the application's choices. The binding to a specific address or the application's choices. The binding to a specific address or
interface implies that the application is not aware of MPTCP and will interface implies that the application is not aware of MPTCP and will
disable the use of MPTCP on this connection. An application that disable the use of MPTCP on this connection. An application that
wishes to bind to a specific set of addresses with MPTCP must use wishes to bind to a specific set of addresses with MPTCP must use
multipath-aware calls to achieve this (as described in multipath-aware calls to achieve this (as described in
Section 5.3.3). Section 5.3.3).
If an application binds to INADDR_ANY, it is assumed that the If an application binds to INADDR_ANY, it is assumed that the
application does not care which addresses to use locally. In this application does not care which addresses are used locally. In this
case, a local policy MAY allow MPTCP to automatically set up multiple case, a local policy MAY allow MPTCP to automatically set up multiple
subflows on such a connection. subflows on such a connection.
The basic sockets API of MPTCP-aware applications allows to express The basic sockets API of MPTCP-aware applications allows the
further preferences in an MPTCP-compatible way (e.g. bind to a subset expression of further preferences in an MPTCP-compatible way (e.g.,
of interfaces only). binding to a subset of interfaces only).
4.2.2. Querying of Addresses by Applications 4.2.2. Querying of Addresses by Applications
Applications can use the getpeername() or getsockname() functions in Applications can use the getpeername() or getsockname() functions in
order to retrieve the IP address of the peer or of the local socket. order to retrieve the IP address of the peer or of the local socket.
These functions can be used for various purposes, including security These functions can be used for various purposes, including security
mechanisms, geo-location, or interface checks. The socket API was mechanisms, geo-location, or interface checks. The sockets API was
designed with an assumption that a socket is using just one address, designed with an assumption that a socket is using just one address,
and since this address is visible to the application, the application and since this address is visible to the application, the application
may assume that the information provided by the functions is the same may assume that the information provided by the functions is the same
during the lifetime of a connection. However, in MPTCP, unlike in 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 TCP, there is a one-to-many mapping of a connection to subflows, and
subflows can be added and removed while the connection continues to subflows can be added and removed while the connection continues to
exist. Since the subflow addresses can change, MPTCP cannot expose exist. Since the subflow addresses can change, MPTCP cannot expose
addresses by getpeername() or getsockname() that are both valid and addresses by getpeername() or getsockname() that are both valid and
constant during the connection's lifetime. constant during the connection's lifetime.
This problem is addressed as follows: If used by a legacy This problem is addressed as follows: If used by a legacy
application, the MPTCP stack MUST always return the addresses and application, the MPTCP stack MUST always return the addresses and
port numbers of the first subflow of an MPTCP connection, in all port numbers of the first subflow of an MPTCP connection, in all
circumstances, even if that particular subflow is no longer in use. circumstances, even if that particular subflow is no longer in use.
As the addresses may not be valid any more if the first subflow is As the addresses may not be valid any more if the first subflow is
closed, the MPTCP stack MAY close the whole MPTCP connection if the closed, the MPTCP stack MAY close the whole MPTCP connection if the
first subflow is closed (i.e. fate sharing between the initial first subflow is closed (i.e., fate-sharing between the initial
subflow and the MPTCP connection as a whole). This fate-sharing subflow and the MPTCP connection as a whole). This fate-sharing
avoids that the pair of IP addresses and ports are reused while a avoids the reuse of the pair of IP addresses and ports while an MPTCP
MPTCP connection is still in progress, but at the cost of reducing connection is still in progress, but at the cost of reducing the
the utility of MPTCP if IP addresses of the first subflow are not utility of MPTCP if IP addresses of the first subflow are not
available any more (e.g., mobility events). Whether to close the available any more (e.g., mobility events). Whether to close the
whole MPTCP connection by default SHOULD be controlled by a local whole MPTCP connection by default SHOULD be controlled by a local
policy. Further experiments are needed to investigate its policy. Further experiments are needed to investigate its
implications. implications.
The functions getpeername() and getsockname() SHOULD also always The functions getpeername() and getsockname() SHOULD also always
return the addresses of the first subflow if the socket is used by an 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 MPTCP-aware application, in order to be consistent with MPTCP-unaware
applications, and, e.g., also with Stream Control Transmission applications, and, e.g., also with the Stream Control Transmission
Protocol (SCTP). Instead of getpeername() or getsockname(), MPTCP- Protocol (SCTP). Instead of getpeername() or getsockname(),
aware applications can use new API calls, documented later, in order MPTCP-aware applications can use new API calls, described in
to retrieve the full list of address pairs for the subflows in use. Section 5.3, in order to retrieve the full list of address pairs for
the subflows in use.
4.3. MPTCP Connection Management 4.3. MPTCP Connection Management
4.3.1. Reaction to Close Call by Application 4.3.1. Reaction to Close Call by Application
As described in [5], MPTCP distinguishes between the closing of As described in [5], MPTCP distinguishes between the closing of
subflows (by TCP FIN) and closing the whole MPTCP conncetion (by DATA subflows (by TCP FIN) and closing the whole MPTCP connection
FIN). (by Data FIN).
When an application closes a socket, e.g., by calling the close() When an application closes a socket, e.g., by calling the close()
function, this indicates that the application has no more data to function, this indicates that the application has no more data to
send, like for single-path TCP. MPTCP will then close the MPTCP send, like for single-path TCP. MPTCP will then close the MPTCP
connection by DATA FIN messages. This is completely transparent for connection via Data FIN messages. This is completely transparent for
an application. an application.
In summary, the semantics of the close() interface for applications In summary, the semantics of the close() interface for applications
are not changed compared to TCP. are not changed compared to TCP.
4.3.2. Other Connection Management Functions 4.3.2. Other Connection Management Functions
In general, an MPTCP connection is maintained separately from In general, an MPTCP connection is maintained separately from
individual subflows. The MPTCP protocol therefore has internal individual subflows. MPTCP therefore has internal mechanisms to
mechanisms to establish, close, or reset the MPTCP connection [5]. establish, close, or reset the MPTCP connection [5]. These
They provide equivalent functions like single-path TCP and can be mechanisms provide equivalent functions like single-path TCP and can
mapped accordingly. Therefore, these MPTCP internals do not affect be mapped accordingly. Therefore, these MPTCP internals do not
the application interface. affect the application interface.
4.4. Socket Option Issues 4.4. Socket Option Issues
4.4.1. General Guideline 4.4.1. General Guideline
The existing sockets API includes options that modify the behavior of The existing sockets API includes options that modify the behavior of
sockets and their underlying communications protocols. Various sockets and their underlying communications protocols. Various
socket options exist on the socket, TCP, and IP level. The value of socket options exist on the socket, TCP, and IP level. The value of
an option can usually be set by the setsockopt() system function. an option can usually be set by the setsockopt() system function.
The getsockopt() function gets information. In general, the existing The getsockopt() function gets information. In general, the existing
sockets interface functions cannot configure each MPTCP subflow sockets interface functions cannot configure each MPTCP subflow
individually. In order to be backward compatible, existing APIs individually. In order to be backward compatible, existing APIs
therefore SHOULD apply to all subflows within one connection, as far therefore SHOULD apply to all subflows within one connection, as far
as possible. as possible.
4.4.2. Disabling of the Nagle Algorithm 4.4.2. Disabling of the Nagle Algorithm
One commonly used TCP socket option (TCP_NODELAY) disables the Nagle One commonly used TCP socket option (TCP_NODELAY) disables the Nagle
algorithm as described in [2]. This option is also specified in the algorithm as described in [2]. This option is also specified in the
Posix standard [8]. Applications can use this option in combination POSIX standard [8]. Applications can use this option in combination
with MPTCP exactly in the same way. It then SHOULD disable the Nagle with MPTCP in exactly the same way. It then SHOULD disable the Nagle
algorithm for the MPTCP connection, i.e., all subflows. algorithm for the MPTCP connection, i.e., all subflows.
In addition, the MPTCP protocol instance MAY use a different path In addition, the MPTCP protocol instance MAY use a different path
scheduler algorithm if TCP_NODELAY is present. For instance, it scheduler algorithm if TCP_NODELAY is present. For instance, it
could use an algorithm that is optimized for latency-sensitive could use an algorithm that is optimized for latency-sensitive
traffic (for instance only transmitting on one path). Specific traffic (for instance, only transmitting on one path). Specific
algorithms are outside the scope of this document. algorithms are outside the scope of this document.
4.4.3. Buffer Sizing 4.4.3. Buffer Sizing
Applications can explicitly configure send and receive buffer sizes Applications can explicitly configure send and receive buffer sizes
by the sockets API (SO_SNDBUF, SO_RCVBUF). These socket options can via the sockets API (SO_SNDBUF, SO_RCVBUF). These socket options can
also be used in combination with MPTCP and then affect the buffer also be used in combination with MPTCP and then affect the buffer
size of the MPTCP connection. However, when defining buffer sizes, size of the MPTCP connection. However, when defining buffer sizes,
application programmers should take into account that the transport application programmers should take into account that the transport
over several subflows requires a certain amount of buffer for over several subflows requires a certain amount of buffer for
resequencing in the receiver. MPTCP may also require more storage resequencing in the receiver. MPTCP may also require more storage
space in the sender, in particular, if retransmissions are sent over space in the sender, in particular, if retransmissions are sent over
more than one path. In addition, very small send buffers may prevent more than one path. In addition, very small send buffers may prevent
MPTCP from efficiently scheduling data over different subflows. MPTCP from efficiently scheduling data over different subflows.
Therefore, it does not make sense to use MPTCP in combination with Therefore, it does not make sense to use MPTCP in combination with
small send or receive buffers. small send or receive buffers.
An MPTCP implementation MAY set a lower bound for send and receive An MPTCP implementation MAY set a lower bound for send and receive
buffers and treat a small buffer size request as an implicit request buffers and treat a small buffer size request as an implicit request
not to use MPTCP. not to use MPTCP.
4.4.4. Other Socket Options 4.4.4. Other Socket Options
TCP features the ability to send "Urgent" data, but its use is not TCP features the ability to send "Urgent" data, but its use is not
recommended in general, and specifically not with MPTCP [4]. recommended in general, and specifically not with MPTCP [4].
Some network stacks also provide other implementation-specific socket Some network stacks may provide additional implementation-specific
options or interfaces that affect TCP's behavior. If a network stack socket options or interfaces that affect TCP's behavior. In such
supports MPTCP, it must be ensured that these options do not cases, implementers must ensure that these options do not interfere
interfere. with the MPTCP interface.
4.5. Default Enabling of MPTCP 4.5. Default Enabling of MPTCP
It is up to a local policy at the end system whether a network stack 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 should automatically enable MPTCP for sockets even if there is no
explicit sign of MPTCP awareness of the corresponding application. explicit sign of MPTCP awareness of the corresponding application.
Such a choice may be under the control of the user through system Such a choice may be under the control of the user through system
preferences. preferences.
The enabling of MPTCP, either by application or by system defaults, The enabling of MPTCP, either by application or by system defaults,
skipping to change at page 15, line 40 skipping to change at page 15, line 26
buffers in the receiver for resequencing, as already explained. buffers in the receiver for resequencing, as already explained.
Applications should use reasonable buffer sizes (such as the Applications should use reasonable buffer sizes (such as the
operating system default values) in order to fully benefit from operating system default values) in order to fully benefit from
MPTCP. A full discussion of buffer sizing issues is given in [5]. MPTCP. A full discussion of buffer sizing issues is given in [5].
o Facilitating stack-internal heuristics: The path management and o Facilitating stack-internal heuristics: The path management and
data scheduling by MPTCP is realized by stack-internal algorithms data scheduling by MPTCP is realized by stack-internal algorithms
that may implicitly try to self-optimize their behavior according that may implicitly try to self-optimize their behavior according
to assumed application needs. For instance, an MPTCP to assumed application needs. For instance, an MPTCP
implementation may use heuristics to determine whether an implementation may use heuristics to determine whether an
application requires delay-sensitive or bulk data transport, using application requires delay-sensitive or bulk data transport,
for instance port numbers, the TCP_NODELAY socket options, or the using, for instance, port numbers, the TCP_NODELAY socket options,
application's read/write patterns as input parameters. An or the application's read/write patterns as input parameters. An
application developer can facilitate the operation of such application developer can facilitate the operation of such
heuristics by avoiding atypical interface use cases. For heuristics by avoiding atypical interface use cases. For
instance, for long bulk data transfers, it neither makes sense to instance, for long bulk data transfers, it does not make sense to
enable the TCP_NODELAY socket option, nor is it reasonable to use enable the TCP_NODELAY socket option, nor is it reasonable to use
many small socket send() calls each with small amounts of data many small socket send() calls each with small amounts of data
only. only.
5. Basic API for MPTCP-aware Applications 5. Basic API for MPTCP-Aware Applications
5.1. Design Considerations 5.1. Design Considerations
While applications can use MPTCP with the unmodified sockets API, While applications can use MPTCP with the unmodified sockets API,
multipath transport results in many degrees of freedom. MPTCP multipath transport results in many degrees of freedom. MPTCP
manages the data transport over different subflows automatically. By manages the data transport over different subflows automatically. By
default, this is transparent to the application, but an application default, this is transparent to the application, but an application
could use an additional API to interface with the MPTCP layer and to could use an additional API to interface with the MPTCP layer and to
control important aspects of the MPTCP implementation's behavior. control important aspects of the MPTCP implementation's behavior.
skipping to change at page 16, line 32 skipping to change at page 16, line 16
basic API does not allow a sender or a receiver to express basic API does not allow a sender or a receiver to express
preferences about the management of paths or the scheduling of data, preferences about the management of paths or the scheduling of data,
even if this can have a significant performance impact and if an even if this can have a significant performance impact and if an
MPTCP implementation could benefit from additional guidance by MPTCP implementation could benefit from additional guidance by
applications. A list of potential further API extensions is provided applications. A list of potential further API extensions is provided
in the appendix. The specification of such an advanced API is for in the appendix. The specification of such an advanced API is for
further study and may partly be implementation-specific. further study and may partly be implementation-specific.
MPTCP mainly affects the sending of data. But a receiver may also MPTCP mainly affects the sending of data. But a receiver may also
have preferences about data transfer choices, and it may have have preferences about data transfer choices, and it may have
performance requirements as well. A receiver may also have performance requirements as well. Yet, the configuration of such
preferences about data transfer choices, and it may have performance preferences is outside of the scope of the basic API.
requirements, too. Yet, the configuration of such preferences is
outside of the scope of the basic API.
5.2. Requirements on the Basic MPTCP API 5.2. Requirements on the Basic MPTCP API
Because of the importance of the sockets interface there are several Because of the importance of the sockets interface there are several
fundamental design objectives for the basic interface between MPTCP fundamental design objectives for the basic interface between MPTCP
and applications: and applications:
o Consistency with existing sockets APIs must be maintained as far o Consistency with existing sockets APIs must be maintained as far
as possible. In order to support the large base of applications as possible. In order to support the large base of applications
using the original API, a legacy application must be able to using the original API, a legacy application must be able to
continue to use standard socket interface functions when run on a continue to use standard sockets interface functions when run on a
system supporting MPTCP. Also, MPTCP-aware applications should be system supporting MPTCP. Also, MPTCP-aware applications should be
able to access the socket without any major changes. able to access the socket without any major changes.
o Sockets API extensions must be minimized and independent of an o Sockets API extensions must be minimized and independent of an
implementation. implementation.
o The interface should handle both IPv4 and IPv6. o The interface should handle both IPv4 and IPv6.
The following is a list of the core requirements for the basic API: The following is a list of the core requirements for the basic API:
REQ1: Turn on/off MPTCP: An application should be able to request to REQ1: 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 turn on or turn off the usage of MPTCP. This means that an
application should be able to explicitly request the use of application should be able to explicitly request the use of
MPTCP if this is possible. Applications should also be able MPTCP if this is possible. Applications should also be able
to request not to enable MPTCP and to use regular TCP to request not to enable MPTCP and to use regular TCP
transport instead. This can be implicit in many cases, since transport instead. This can be implicit in many cases, since
MPTCP must be disabled by the use of binding to a specific MPTCP must be disabled by the use of binding to a specific
address. MPTCP may also be enabled if an application uses a address. MPTCP may also be enabled if an application uses a
dedicated multipath address family (such as AF_MULTIPATH, dedicated multipath address family (such as AF_MULTIPATH
[20]). [20]).
REQ2: An application should be able to restrict MPTCP to binding to REQ2: An application should be able to restrict MPTCP to binding to
a given set of addresses. a given set of addresses.
REQ3: An application should be able obtain information on the pairs REQ3: An application should be able to obtain information on the
of addresses used by the MPTCP subflows. pairs of addresses used by the MPTCP subflows.
REQ4: An application should be able to extract a unique identifier REQ4: An application should be able to extract a unique identifier
for the connection (per endpoint). for the connection (per endpoint).
The first requirement is the most important one, since some The first requirement is the most important one, since some
applications could benefit a lot from MPTCP, but there are also cases applications could benefit a lot from MPTCP, but there are also cases
in which it hardly makes sense. The existing sockets API provides in which it hardly makes sense. The existing sockets API provides
similar mechanisms to enable or disable advanced TCP features. The similar mechanisms to enable or disable advanced TCP features. The
second requirement corresponds to the binding of addresses with the second requirement corresponds to the binding of addresses with the
bind() socket call, or, e.g., explicit device bindings with a bind() socket call, or, e.g., explicit device bindings with a
skipping to change at page 18, line 4 skipping to change at page 17, line 35
An application can continue to use getpeername() or getsockname() in An application can continue to use getpeername() or getsockname() in
addition to the basic MPTCP API. Both functions return the addition to the basic MPTCP API. Both functions return the
corresponding addresses of the first subflow, as already explained. corresponding addresses of the first subflow, as already explained.
5.3. Sockets Interface Extensions by the Basic MPTCP API 5.3. Sockets Interface Extensions by the Basic MPTCP API
5.3.1. Overview 5.3.1. Overview
The abstract, basic MPTCP API consists of a set of new values that The abstract, basic MPTCP API consists of a set of new values that
are associated with an MPTCP socket. Such values may be used for are associated with an MPTCP socket. Such values may be used for
changing properties of an MPTCP connection, or retrieving changing properties of an MPTCP connection or retrieving information.
information. These values could be accessed by new symbols on These values could be accessed by new symbols on existing calls such
existing calls such as setsockopt() and getsockopt(), or could be as setsockopt() and getsockopt() or could be implemented as entirely
implemented as entirely new function calls. This implementation new function calls. This implementation decision is out of scope for
decision is out of scope for this document. The following list this document. The following list presents symbolic names for these
presents symbolic names for these MPTCP socket settings. MPTCP socket settings.
o TCP_MULTIPATH_ENABLE: Enable/disable MPTCP o TCP_MULTIPATH_ENABLE: Enable/disable MPTCP
o TCP_MULTIPATH_ADD: Bind MPTCP to a set of given local addresses, o TCP_MULTIPATH_ADD: Bind MPTCP to a set of given local addresses,
or add a set of new local addresses to an existing MPTCP or add a set of new local addresses to an existing MPTCP
connection connection
o TCP_MULTIPATH_REMOVE: Remove a local address from an MPTCP o TCP_MULTIPATH_REMOVE: Remove a local address from an MPTCP
connection connection
skipping to change at page 18, line 38 skipping to change at page 18, line 23
the operation. The second and third columns indicate whether the the operation. The second and third columns indicate whether the
operation provides values to be read ("Get") or takes values to operation provides values to be read ("Get") or takes values to
configure ("Set"). The fourth column lists the type of data configure ("Set"). The fourth column lists the type of data
associated with this operation. The data types are listed for associated with this operation. The data types are listed for
information only. In addition to IP addresses, an application MAY information only. In addition to IP addresses, an application MAY
also indicate TCP port numbers, as further detailed below. also indicate TCP port numbers, as further detailed below.
+------------------------+-----+-----+------------------------------+ +------------------------+-----+-----+------------------------------+
| Name | Get | Set | Data type | | Name | Get | Set | Data type |
+------------------------+-----+-----+------------------------------+ +------------------------+-----+-----+------------------------------+
| TCP_MULTIPATH_ENABLE | o | o | boolean | | TCP_MULTIPATH_ENABLE | o | o | boolean |
| TCP_MULTIPATH_ADD | | o | list of addresses (and | | TCP_MULTIPATH_ADD | | o | list of addresses |
| | | | ports) | | | | | (and ports) |
| TCP_MULTIPATH_REMOVE | | o | list of addresses (and | | TCP_MULTIPATH_REMOVE | | o | list of addresses |
| | | | ports) | | | | | (and ports) |
| TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses | | TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses |
| | | | (and ports) | | | | | (and ports) |
| TCP_MULTIPATH_CONNID | o | | integer | | TCP_MULTIPATH_CONNID | o | | integer |
+------------------------+-----+-----+------------------------------+ +------------------------+-----+-----+------------------------------+
Table 1: MPTCP Socket Operations Table 1: MPTCP Socket Operations
There are restrictions when these new socket operations can be used: There are restrictions on when these new socket operations can be
used:
o TCP_MULTIPATH_ENABLE: This value should only be set before the o TCP_MULTIPATH_ENABLE: This value should only be set before the
establishment of a TCP connection. Its value should only be read establishment of a TCP connection. Its value should only be read
after the establishment of a connection. after the establishment of a connection.
o TCP_MULTIPATH_ADD: This operation can be both applied before o TCP_MULTIPATH_ADD: This operation can be applied both before
connection setup or during a connection. If used before, it connection setup and during a connection. If used before, it
controls the local addresses that an MPTCP connection can use. In controls the local addresses that an MPTCP connection can use. In
the latter case, it allows MPTCP to use an additional local the latter case, it allows MPTCP to use an additional local
address, if there has been a restriction before connection setup. address, if there has been a restriction before connection setup.
o TCP_MULTIPATH_REMOVE: This operation can be both applied before o TCP_MULTIPATH_REMOVE: This operation can be applied both before
connection setup or during a connection. In both cases, it connection setup and during a connection. In both cases, it
removes an address from the list of local addresses that may be removes an address from the list of local addresses that may be
used by subflows. used by subflows.
o TCP_MULTIPATH_SUBFLOWS: This value is read-only and can only be o TCP_MULTIPATH_SUBFLOWS: This value is read-only and can only be
used after connection setup. used after connection setup.
o TCP_MULTIPATH_CONNID: This value is read-only and should only be o TCP_MULTIPATH_CONNID: This value is read-only and should only be
used after connection setup. used after connection setup.
5.3.2. Enabling and Disabling of MPTCP 5.3.2. Enabling and Disabling of MPTCP
An application can explicitly indicate multipath capability by An application can explicitly indicate multipath capability by
setting TCP_MULTIPATH_ENABLE to the value "true". In this case, the setting TCP_MULTIPATH_ENABLE to the value "true". In this case, the
MPTCP implementation SHOULD try to negotiate MPTCP for that MPTCP implementation SHOULD try to negotiate MPTCP for that
connection. Note that multipath transport will not necessarily be connection. Note that multipath transport will not necessarily be
enabled, as it requires support at both end systems, no middleboxes enabled, as it requires support at both end systems, no middleboxes
on the path that would prevent any additional signalling, and at on the path that would prevent any additional signaling, and at least
least one endpoint with multiple addresses. one endpoint with multiple addresses.
Building on the backwards-compatibility specified in Section 4.2.1, Building on the backward compatibility specified in Section 4.2.1, if
if an application enables MPTCP but binds to a specific address or an application enables MPTCP but binds to a specific address or
interface, MPTCP MUST be enabled, but MPTCP MUST respect the interface, MPTCP MUST be enabled, but MPTCP MUST respect the
application's choice and only use addresses that are explicitly application's choice and only use addresses that are explicitly
provided by the application. Note that it would be possible for an provided by the application. Note that it would be possible for an
application to use the legacy bindings, and then expand on them by application to use the legacy bindings and then expand on them by
using TCP_MULTIPATH_ADD. Note also that it is possible for more than using TCP_MULTIPATH_ADD. Note also that it is possible for more than
one local address to be initially available to MPTCP in this case, if one local address to be initially available to MPTCP in this case, if
an application has bound to a specific interface with multiple an application has bound to a specific interface with multiple
addresses. addresses.
An application can disable MPTCP by setting TCP_MULTIPATH_ENABLE to a An application can disable MPTCP by setting TCP_MULTIPATH_ENABLE to a
value of "false". In that case, MPTCP MUST NOT be used on that value of "false". In that case, MPTCP MUST NOT be used on that
connection. connection.
After connection establishment, an application can get the value of After connection establishment, an application can get the value of
TCP_MULTIPATH_ENABLE. A value of "false" then means lack of MPTCP TCP_MULTIPATH_ENABLE. A value of "false" then means lack of MPTCP
support. A value of "true" means that MPTCP is supported. support. A value of "true" means that MPTCP is supported.
5.3.3. Binding MPTCP to Specified Addresses 5.3.3. Binding MPTCP to Specified Addresses
Before connection establishment, an application can use Before connection establishment, an application can use the
TCP_MULTIPATH_ADD function to indicate a set of local IP addresses TCP_MULTIPATH_ADD function to indicate a set of local IP addresses
that MPTCP may bind to. The parameter of the function is a list of that MPTCP may bind to. The parameter of the function is a list of
addresses in a corresponding data structure. By extension, this addresses in a corresponding data structure. By extension, this
operation will also control the list of addresses that can be operation will also control the list of addresses that can be
advertised to the peer via MPTCP signalling. advertised to the peer via MPTCP signaling.
If an application binds to a specific address or interface, it is not If an application binds to a specific address or interface, it is not
required to use the TCP_MULTIPATH_ADD operation for that address. As required to use the TCP_MULTIPATH_ADD operation for that address. As
explained in Section 5.3.2, MPTCP MUST only use the explicitly explained in Section 5.3.2, MPTCP MUST only use the explicitly
specified addresses in that case. specified addresses in that case.
An application MAY also indicate a TCP port number that, if An application MAY also indicate a TCP port number that, if
specified, MPTCP MUST attempt to bind to. The port number MAY be specified, MPTCP MUST attempt to bind to. The port number MAY be
different to the one used by existing subflows. If no port number is different than the one used by existing subflows. If no port number
provided by the application, the port number is automatically is provided by the application, the port number is automatically
selected by the MPTCP implementation, and it is RECOMMENDED that it selected by the MPTCP implementation, and it is RECOMMENDED that it
is the same across all subflows. is the same across all subflows.
This operation can also be used to modify the address list in use This operation can also be used to modify the address list in use
during the lifetime of an MPTCP connection. In this case, it is used during the lifetime of an MPTCP connection. In this case, it is used
to indicate a set of additional local addresses that the MPTCP to indicate a set of additional local addresses that the MPTCP
connection can make use of, and which can be signalled to the peer. connection can make use of and that can be signaled to the peer. It
It should be noted that this signal is only a hint, and an MPTCP should be noted that this signal is only a hint, and an MPTCP
implementation MAY select only a subset of the addresses. implementation MAY select only a subset of the addresses.
The TCP_MULTIPATH_REMOVE operation can be used to remove a (set of) The TCP_MULTIPATH_REMOVE operation can be used to remove a local
local addresses from an MPTCP connection. MPTCP MUST close any address, or a set of local addresses, from an MPTCP connection.
corresponding subflows (i.e. those using the local address that is no MPTCP MUST close any corresponding subflows (i.e., those using the
longer present), and signal the removal of the address to the peer. local address that is no longer present) and signal the removal of
If alternative paths are available using the supplied address list the address to the peer. If alternative paths are available using
but MPTCP is not currently using them, an MPTCP implementation SHOULD the supplied address list but MPTCP is not currently using them, an
establish alternative subflows before undertaking the address MPTCP implementation SHOULD establish alternative subflows before
removal. undertaking the address removal.
It should be remembered that these operations SHOULD support both It should be remembered that these operations SHOULD support both
IPv4 and IPv6 addresses, potentially in the same call. IPv4 and IPv6 addresses, potentially in the same call.
5.3.4. Querying the MPTCP Subflow Addresses 5.3.4. Querying the MPTCP Subflow Addresses
An application can get a list of the addresses used by the currently An application can get a list of the addresses used by the currently
established subflows in an MPTCP connection by means of the read-only established subflows in an MPTCP connection by means of the read-only
TCP_MULTIPATH_SUBFLOWS operation. TCP_MULTIPATH_SUBFLOWS operation.
skipping to change at page 21, line 19 skipping to change at page 20, line 51
include established subflows. Both addresses in each pair MUST be include established subflows. Both addresses in each pair MUST be
either IPv4 or IPv6. either IPv4 or IPv6.
5.3.5. Getting a Unique Connection Identifier 5.3.5. Getting a Unique Connection Identifier
An application that wants a unique identifier for the connection, An application that wants a unique identifier for the connection,
analogous to an (address, port) pair in regular TCP, can query the analogous to an (address, port) pair in regular TCP, can query the
TCP_MULTIPATH_CONNID value to get a local connection identifier for TCP_MULTIPATH_CONNID value to get a local connection identifier for
the MPTCP connection. the MPTCP connection.
This SHOULD be an integer number, and SHOULD be locally unique (e.g., This SHOULD be an integer number and SHOULD be locally unique (e.g.,
the MPTCP token). the MPTCP token).
6. Other Compatibility Issues 6. Other Compatibility Issues
6.1. Usage of TLS over MPTCP 6.1. Usage of TLS over MPTCP
Transport Layer Security (TLS) [17] may be used over MPTCP's Basic Transport Layer Security (TLS) [17] may be used over MPTCP's basic
API. When TLS compares any addresses used by MPTCP against names or API. When TLS compares any addresses used by MPTCP against names or
addresses present in X.509 certificates [18] [19], it MUST only addresses present in X.509 certificates [18] [19], it MUST only
compare them with the address that MPTCP used to start the initial compare them with the address that MPTCP used to start the initial
subflow as presented to TLS. The addresses used for subsequent subflow as presented to TLS. The addresses used for subsequent
subflows need not to be compared against any TLS certificate subflows need not to be compared against any TLS certificate
information. Finer-grained control would require an Advanced API or information. Finer-grained control would require an advanced API or
proactive subflow management via the Basic API. proactive subflow management via the basic API.
6.2. Usage of the SCTP Socket API 6.2. Usage of the SCTP Sockets API
For dealing with multi-homing, several socket API extensions have For dealing with multihoming, several sockets API extensions have
been defined for SCTP [13]. As MPTCP realizes multipath transport been defined for SCTP [13]. As MPTCP realizes multipath transport
from and to multi-homed endsystems, some of these interface function from and to multihomed end systems, some of these interface function
calls are actually applicable to MPTCP in a similar way. calls are actually applicable to MPTCP in a similar way.
API developers may wish to integrate SCTP and MPTCP calls to provide API developers may wish to integrate SCTP and MPTCP calls to provide
a consistent interface to the application. Yet, it must be a consistent interface to the application. Yet, it must be
emphasized that the transport service provided by MPTCP is different emphasized that the transport service provided by MPTCP is different
to SCTP, and this is why not all SCTP API functions can be mapped than that of SCTP, and this is why not all SCTP API functions can be
directly to MPTCP. Furthermore, a network stack implementing MPTCP mapped directly to MPTCP. Furthermore, a network stack implementing
does not necessarily support SCTP and its specific socket interface MPTCP does not necessarily support SCTP and its specific sockets
extensions. This is why the basic API of MPTCP defines additional interface extensions. This is why the basic API of MPTCP defines
socket options only, which are a backward compatible extension of additional socket options only, which are a backward-compatible
TCP's application interface. An integration with the SCTP API is extension of TCP's application interface. Integration with the SCTP
outside the scope of the basic API. API is outside the scope of the basic API.
6.3. Incompatibilities with other Multihoming Solutions 6.3. Incompatibilities with Other Multihoming Solutions
The use of MPTCP can interact with various related sockets API The use of MPTCP can interact with various related sockets API
extensions. The use of a multihoming shim layer conflicts with extensions. The use of a multihoming shim layer conflicts with
multipath transport such as MPTCP or SCTP [11]. Care should be taken multipath transport such as MPTCP or SCTP [11]. Care should be taken
for the usage not to confuse with the overlapping features of other that the use of MPTCP not conflict with the overlapping features of
APIs: other APIs:
o SHIM API [11]: This API specifies sockets API extensions for the o SHIM API [11]: This API specifies sockets API extensions for the
multihoming shim layer. multihoming shim layer.
o HIP API [12]: The Host Identity Protocol (HIP) also results in a o HIP API [12]: The Host Identity Protocol (HIP) also results in a
new API. new API.
o API for Mobile IPv6 [10]: For Mobile IPv6, a significantly o API for Mobile IPv6 [10]: For Mobile IPv6, a significantly
extended socket API exists as well (in addition to API extensions extended sockets API exists as well (in addition to API extensions
for IPv6 [9]). for IPv6 [9]).
In order to avoid any conflict, multiaddressed MPTCP SHOULD NOT be In order to avoid any conflict, multiaddressed MPTCP SHOULD NOT be
enabled if a network stack uses SHIM6, HIP, or Mobile IPv6. enabled if a network stack uses SHIM6, HIP, or Mobile IPv6.
Furthermore, applications should not try to use both the MPTCP API Furthermore, applications should not try to use both the MPTCP API
and another multihoming or mobility layer API. and another multihoming or mobility layer API.
It is possible, however, that some of the MPTCP functionality, such It is possible, however, that some of the MPTCP functionality, such
as congestion control, could be used in a SHIM6 or HIP environment. as congestion control, could be used in a SHIM6 or HIP environment.
Such operation is for further study. Such operation is for further study.
6.4. Interactions with DNS 6.4. Interactions with DNS
In multihomed or multiaddressed environments, there are various In multihomed or multiaddressed environments, there are various
issues that are not specific to MPTCP, but have to be considered as issues that are not specific to MPTCP but have to be considered as
well. These problems are summarized in [14]. well. These problems are summarized in [14].
Specifically, there can be interactions with DNS. Whilst it is Specifically, there can be interactions with DNS. Whilst it is
expected that an application will iterate over the list of addresses expected that an application will iterate over the list of addresses
returned from a call such as getaddrinfo(), MPTCP itself MUST NOT returned from a call such as getaddrinfo(), MPTCP itself MUST NOT
make any assumptions about multiple A or AAAA records from the same make any assumptions about multiple A or AAAA records from the same
DNS query referring to the same host, as it is possible that multiple DNS query referring to the same host, as it is possible that multiple
addresses refer to multiple servers for load balancing purposes. addresses refer to multiple servers for load-balancing purposes.
7. Security Considerations 7. Security Considerations
This document first defines the behavior of the standard TCP/IP API This document first defines the behavior of the standard TCP/IP API
for MPTCP-unaware applications. In general, enabling MPTCP has some for MPTCP-unaware applications. In general, enabling MPTCP has some
security implications for applications, which are introduced in security implications for applications, which are introduced in
Section 5.3.3, and these threats are further detailed in [6]. The Section 5.3.3, and these threats are further detailed in [6]. The
protocol specification of MPTCP [5] defines several mechanisms to protocol specification of MPTCP [5] defines several mechanisms to
protect MPTCP against those attacks. protect MPTCP against those attacks.
The syntax and semantics of the API for MPTCP-unaware application The syntax and semantics of the API for MPTCP-unaware applications
does not change. However, assumptions that non-MPTCP-aware does not change. However, assumptions that non-MPTCP-aware
applications may make on the data retrieved by the backwards- applications may make on the data retrieved by the backward-
compatible API are discussed in Section 4.2.2. System administrators compatible API are discussed in Section 4.2.2. System administrators
may wish to disable MPTCP for certain applications that signal may wish to disable MPTCP for certain applications that signal
addresses, or make security decisions (e.g. opening firewall holes), addresses, or make security decisions (e.g., opening firewall holes),
based on responses to such queries. based on responses to such queries.
In addition, the basic MPTCP API for MPTCP-aware applications defines In addition, the basic MPTCP API for MPTCP-aware applications defines
functions that provide an equivalent level of control and information functions that provide an equivalent level of control and information
as exists for regular TCP. This document does not mandate a specific as exists for regular TCP. This document does not mandate a specific
implementation of the basic MPTCP API. The implementation should be implementation of the basic MPTCP API. The implementation should be
designed not to affect memory management assumptions in existing designed not to affect memory management assumptions in existing
code. Implementors should take into account that data structures code. Implementors should take into account that data structures
will be more complex than for standard TCP, e.g., when multiple will be more complex than for standard TCP, e.g., when multiple
subflow addresses have to be stored. When dealing with such data subflow addresses have to be stored. When dealing with such data
skipping to change at page 23, line 45 skipping to change at page 23, line 29
visible otherwise. visible otherwise.
Use of different addresses should not be assumed to lead to use of Use of different addresses should not be assumed to lead to use of
different paths, especially for security purposes. different paths, especially for security purposes.
MPTCP-aware applications should also take care when querying and MPTCP-aware applications should also take care when querying and
using information about the addresses used by subflows using information about the addresses used by subflows
(TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close (TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close
subflows, a list of addresses queried once can get outdated during subflows, a list of addresses queried once can get outdated during
the lifetime of an MPTCP connection. Then, the list may contain the lifetime of an MPTCP connection. Then, the list may contain
invalid entries, i.e. addresses that are not used any more, or that invalid entries, i.e., addresses that are not used any more or that
might not even be assigned to that host any more. Applications that might not even be assigned to that host any more. Applications that
want to ensure that MPTCP only uses a certain set of addresses should want to ensure that MPTCP only uses a certain set of addresses should
explicitly bind to those addresses. explicitly bind to those addresses.
One specific example is the use TLS on top of MPTCP. Corresponding One specific example is the use TLS on top of MPTCP. Corresponding
guidance can be found in Section 6.1. guidance can be found in Section 6.1.
8. IANA Considerations 8. Conclusion
This document has no IANA actions. This document only defines an
abstract API and therefore does not request the reservation of
identifiers or names.
9. Conclusion
This document discusses MPTCP's implications and its performance This document discusses MPTCP's implications and its performance
impact on applications. In addition, it specifies a basic MPTCP API. impact on applications. In addition, it specifies a basic MPTCP API.
For legacy applications, it is ensured that the existing sockets API For legacy applications, it is ensured that the existing sockets API
continues to work. MPTCP-aware applications can use the basic MPTCP continues to work. MPTCP-aware applications can use the basic MPTCP
API that provides some control over the transport layer equivalent to API that provides some control over the transport layer equivalent to
regular TCP. regular TCP.
10. Acknowledgments 9. Acknowledgments
Authors sincerely thank to the following people for their helpful The authors sincerely thank the following people for their helpful
comments and reviews of the document: Philip Eardley, Lavkesh comments and reviews of the document: Philip Eardley, Lavkesh
Lahngir, John Leslie, Costin Raiciu, Michael Tuexen, and Javier Lahngir, John Leslie, Costin Raiciu, Michael Tuexen, and Javier
Ubillos. Ubillos.
Michael Scharf is supported by the German-Lab project Michael Scharf is supported by the German-Lab project
(http://www.german-lab.de/) funded by the German Federal Ministry of (http://www.german-lab.de/) funded by the German Federal Ministry of
Education and Research (BMBF). Alan Ford was previously supported by Education and Research (BMBF). Alan Ford was previously supported by
Roke Manor Research and by Trilogy (http://www.trilogy-project.org/), Roke Manor Research and by Trilogy (http://www.trilogy-project.org/),
a research project (ICT-216372) partially funded by the European a research project (ICT-216372) partially funded by the European
Community under its Seventh Framework Program. Community under its Seventh Framework Program.
11. References 10. References
11.1. Normative References 10.1. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[2] Braden, R., "Requirements for Internet Hosts - Communication [2] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, [4] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar,
"Architectural Guidelines for Multipath TCP Development", "Architectural Guidelines for Multipath TCP Development",
RFC 6182, March 2011. RFC 6182, March 2011.
[5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP [5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
Extensions for Multipath Operation with Multiple Addresses", Extensions for Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-12 (work in progress), RFC 6824, January 2013.
October 2012.
[6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath [6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses", RFC 6181, March 2011. Operation with Multiple Addresses", RFC 6181, March 2011.
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion [7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion
Control for Multipath Transport Protocols", RFC 6356, Control for Multipath Transport Protocols", RFC 6356,
October 2011. October 2011.
[8] "IEEE Std. 1003.1-2008 Standard for Information Technology -- [8] "IEEE Standard for Information Technology -- Portable Operating
Portable Operating System Interface (POSIX). Open Group System Interface (POSIX) Base Specifications, Issue 7", IEEE
Technical Standard: Base Specifications, Issue 7, 2008.". Std. 1003.1-2008, 2008.
11.2. Informative References 10.2. Informative References
[9] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced [9] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced
Sockets Application Program Interface (API) for IPv6", Sockets Application Program Interface (API) for IPv6",
RFC 3542, May 2003. RFC 3542, May 2003.
[10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for [10] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for
Mobile IPv6", RFC 4584, July 2006. Mobile IPv6", RFC 4584, July 2006.
[11] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets [11] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Sockets
Application Program Interface (API) for Multihoming Shim", Application Program Interface (API) for Multihoming Shim",
skipping to change at page 26, line 15 skipping to change at page 25, line 41
Certificate and Certificate Revocation List (CRL) Profile", Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008. RFC 5280, May 2008.
[19] Saint-Andre, P. and J. Hodges, "Representation and Verification [19] Saint-Andre, P. and J. Hodges, "Representation and Verification
of Domain-Based Application Service Identity within Internet of Domain-Based Application Service Identity within Internet
Public Key Infrastructure Using X.509 (PKIX) Certificates in Public Key Infrastructure Using X.509 (PKIX) Certificates in
the Context of Transport Layer Security (TLS)", RFC 6125, the Context of Transport Layer Security (TLS)", RFC 6125,
March 2011. March 2011.
[20] Sarolahti, P., "Multi-address Interface in the Socket API", [20] Sarolahti, P., "Multi-address Interface in the Socket API",
March 2010. Work in Progress, March 2010.
[21] Khalili, R., Gast, N., Popovic, M., and J. Le Boudec, [21] Khalili, R., Gast, N., Popovic, M., and J. Le Boudec,
"Performance Issues with MPTCP", March 2010. "Performance Issues with MPTCP", Work in Progress,
February 2013.
[22] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, [22] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley,
M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proc. M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proc.
ACM Internet Measurement Conference (IMC), November 2011. ACM Internet Measurement Conference (IMC), November 2011.
Appendix A. Requirements on a Future Advanced MPTCP API Appendix A. Requirements on a Future Advanced MPTCP API
A.1. Design Considerations A.1. Design Considerations
Multipath transport results in many degrees of freedom. The basic Multipath transport results in many degrees of freedom. The basic
MPTCP API only defines a minimum set of the API extensions for the MPTCP API only defines a minimum set of the API extensions for the
interface between the MPTCP layer and applications, which does not interface between the MPTCP layer and applications, which does not
offer much control of the MPTCP implementation's behavior. A future, offer much control of the MPTCP implementation's behavior. A future,
advanced API could address further features of MPTCP and provide more advanced API could address further features of MPTCP and provide more
control. control.
Applications that use TCP may have different requirements on the Applications that use TCP may have different requirements on the
transport layer. While developers have become used to the transport layer. While developers have become used to the
characteristics of regular TCP, new opportunities created by MPTCP characteristics of regular TCP, new opportunities created by MPTCP
could allow the service provided to be optimised further. An could allow the service provided to be optimized further. An
advanced API could enable MPTCP-aware applications to specify advanced API could enable MPTCP-aware applications to specify
preferences and control certain aspects of the behavior, in addition preferences and control certain aspects of the behavior, in addition
to the simple control provided by the basic interface. An advanced to the simple control provided by the basic interface. An advanced
API could also address aspects that are completely out-of-scope of API could also address aspects that are completely out of scope of
the basic API, for example, the question whether a receiving the basic API, for example, the question of whether a receiving
application could influence the sending policy. A better integration application could influence the sending policy. A better integration
with TLS could be another relevant objective (cf. Section 6.1) that with TLS could be another relevant objective (cf. Section 6.1) that
requires further work. requires further work.
Furthermore, an advanced MPTCP API could be part of a new overall Furthermore, an advanced MPTCP API could be part of a new overall
interface between the network stack and applications that addresses interface between the network stack and applications that addresses
other issues as well, such as the split between identifiers and 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 locators. An API that does not use IP addresses (but instead uses,
connectbyname() function) would be useful for numerous purposes, e.g., the connectbyname() function) would be useful for numerous
independent of MPTCP. purposes, independent of MPTCP.
It has also been suggested to use a separate address family called It has also been suggested that a separate address family called
AF_MULTIPATH [20]. This separate address family could be used to AF_MULTIPATH [20] be used. This separate address family could be
exchange multiple addresses between an application and the standard used to exchange multiple addresses between an application and the
sockets API, but it would be a more fundamental change compared to standard sockets API, but it would be a more fundamental change
the basic API described in this document. compared to the basic API described in this document.
This appendix documents a list of potential usage scenarios and This appendix documents a list of potential usage scenarios and
requirements for the advanced API. The specification and requirements for the advanced API. The specification and
implementation of a corresponding API is outside the scope of this implementation of a corresponding API are outside the scope of this
document. document.
A.2. MPTCP Usage Scenarios and Application Requirements A.2. MPTCP Usage Scenarios and Application Requirements
There are different MPTCP usage scenarios. An application that There are different MPTCP usage scenarios. An application that
wishes to transmit bulk data will want MPTCP to provide a high wishes to transmit bulk data will want MPTCP to provide a high-
throughput service immediately, through creating and maximising throughput service immediately, through creating and maximizing
utilisation of all available subflows. This is the default MPTCP use utilization of all available subflows. This is the default MPTCP use
case. case.
But at the other extreme, there are applications that are highly But at the other extreme, there are applications that are highly
interactive, but require only a small amount of throughput, and these interactive but require only a small amount of throughput, and these
are optimally served by low latency and jitter stability. In such a are optimally served by low latency and jitter stability. In such a
situation, it would be preferable for the traffic to use only the situation, it would be preferable for the traffic to use only the
lowest latency subflow (assuming it has sufficient capacity), maybe lowest-latency subflow (assuming it has sufficient capacity), maybe
with one or two additional subflows for resilience and recovery with one or two additional subflows for resilience and recovery
purposes. The key challenge for such a strategy is that the delay on purposes. The key challenge for such a strategy is that the delay on
a path may fluctuate significantly and that just always selecting the a path may fluctuate significantly and that just always selecting the
path with the smallest delay might result in instability. path with the smallest delay might result in instability.
The choice between bulk data transport and latency-sensitive The choice between bulk data transport and latency-sensitive
transport affects the scheduler in terms of whether traffic should transport affects the scheduler in terms of whether traffic should
be, by default, sent on one subflow or across several ones. Even if be, by default, sent on one subflow or across several subflows. Even
the total bandwidth required is less than that available on an if the total bandwidth required is less than that available on an
individual path, it is desirable to spread this load to reduce stress individual path, it is desirable to spread this load to reduce stress
on potential bottlenecks, and this is why this method should be the on potential bottlenecks, and this is why this method should be the
default for bulk data transport. However, that may not be optimal default for bulk data transport. However, that may not be optimal
for applications that require latency/jitter stability. for applications that require latency/jitter stability.
In the case of the latter option, a further question arises: Should In the case of the latter option, a further question arises: Should
additional subflows be used whenever the primary subflow is additional subflows be used whenever the primary subflow is
overloaded, or only when the primary path fails (hot-standby)? In overloaded, or only when the primary path fails (hot standby)? In
other words, is latency stability or bandwidth more important to the other words, is latency stability or bandwidth more important to the
application? This results in two different options: Firstly, there application? This results in two different options: Firstly, there
is the single path which can overflow into an additional subflow; and is the single path that can overflow into an additional subflow; and
secondly there is single-path with hot-standby, whereby an secondly, there is the single path with hot standby, whereby an
application may want an alternative backup subflow in order to application may want an alternative backup subflow in order to
improve resilience. In case that data delivery on the first subflow improve resilience. In case data delivery on the first subflow
fails, the data transport could immediately be continued on the fails, the data transport could immediately be continued on the
second subflow, which is idle otherwise. second subflow, which is idle otherwise.
Yet another complication is introduced with the potential that MPTCP Yet another complication is introduced with the potential that MPTCP
introduces for changes in available bandwidth as the number of introduces for changes in available bandwidth as the number of
available subflows changes. Such jitter in bandwidth may prove available subflows changes. Such jitter in bandwidth may prove
confusing for some applications such as video or audio streaming that confusing for some applications, such as video or audio streaming,
dynamically adapt codecs based on available bandwidth. Such that dynamically adapt codecs based on available bandwidth. Such
applications may prefer MPTCP to attempt to provide a consistent applications may prefer MPTCP to attempt to provide a consistent
bandwidth as far as is possible, and avoid maximising the use of all bandwidth as far as is possible and avoid maximizing the use of all
subflows. subflows.
A further, mostly orthogonal question is whether data should be A further, mostly orthogonal question is whether data should be
duplicated over the different subflows, in particular if there is duplicated over the different subflows, in particular if there is
spare capacity. This could improve both the timeliness and spare capacity. This could improve both the timeliness and
reliability of data delivery. reliability of data delivery.
In summary, there are at least three possible performance objectives In summary, there are at least three possible performance objectives
for multipath transport: for multipath transport:
1. High bandwidth 1. High bandwidth
2. Low latency and jitter stability 2. Low latency and jitter stability
3. High reliability 3. High reliability
These are not necessarily disjoint, since there are also broadband These are not necessarily disjoint, since there are also broadband
interactive applications that both require high-speed bulk data interactive applications that require both high-speed bulk data
traffic and a low latency and jitter. traffic and a low latency and jitter.
In an advanced API, applications could provide high-level guidance to In an advanced API, applications could provide high-level guidance to
the MPTCP implementation concerning these performance requirements, the MPTCP implementation concerning these performance requirements,
for instance, which is considered to be the most important one. The for instance, which requirement is considered to be the most
MPTCP stack would then use internal mechanisms to fulfill this important. The MPTCP stack would then use internal mechanisms to
abstract indication of a desired service, as far as possible. This fulfill this abstract indication of a desired service, as far as
would both affect the assignment of data (including retransmissions) possible. This would affect the assignment of data (including
to existing subflows (e.g., 'use all in parallel', 'use as overflow', retransmissions) to existing subflows (e.g., 'use all in parallel',
'hot standby', 'duplicate traffic') as well as the decisions when to 'use as overflow', 'hot standby', 'duplicate traffic') as well as the
set up additional subflows to which addresses. In both cases decisions regarding when to set up additional subflows to which
different policies can exist, which can be expected to be addresses. In both cases, different policies can exist, which can be
implementation-specific. expected to be implementation-specific.
Therefore, an advanced API could provide a mechanism how applications Therefore, an advanced API could provide a mechanism for how
can specify their high-level requirements in an implementation- applications can specify their high-level requirements in an
independent way. One possibility would be to select one "application implementation-independent way. One possibility would be to select
profile" out of a number of choices that characterize typical one "application profile" out of a number of choices that
applications. Yet, as applications today do not have to inform TCP characterize typical applications. Yet, as applications today do not
about their communication requirements, it requires further studies have to inform TCP about their communication requirements, it
whether such an approach would be realistic. requires further studies as to whether such an approach would be
realistic.
Of course, independent of an advanced API, such functionality could Of course, independent of an advanced API, such functionality could
also partly be achieved by MPTCP-internal heuristics that infer some also partly be achieved by MPTCP-internal heuristics that infer some
application preferences e.g. from existing socket options, such as application preferences, e.g., from existing socket options, such as
TCP_NODELAY. Whether this would be reliable, and indeed appropriate, TCP_NODELAY. Whether this would be reliable, and indeed appropriate,
is for further study. is for further study.
A.3. Potential Requirements on an Advanced MPTCP API A.3. Potential Requirements on an Advanced MPTCP API
The following is a list of potential requirements for an advanced The following is a list of potential requirements for an advanced
MPTCP API beyond the features of the basic API. It is included here MPTCP API beyond the features of the basic API. It is included here
for information only: for information only:
REQ5: An application should be able to establish MPTCP connections REQ5: An application should be able to establish MPTCP connections
without using IP addresses as locators. without using IP addresses as locators.
REQ6: An application should be able obtain usage information and REQ6: An application should be able to obtain usage information and
statistics about all subflows (e.g., ratio of traffic sent statistics about all subflows (e.g., ratio of traffic sent
via this subflow). via this subflow).
REQ7: An application should be able to request a change in the REQ7: An application should be able to request a change in the
number of subflows in use, thus triggering removal or number of subflows in use, thus triggering removal or
addition of subflows. An even finer control granularity addition of subflows. An even finer control granularity
would be a request for the establishment of a specific would be a request for the establishment of a specific
subflow to a provided destination, or a request for the subflow to a provided destination or a request for the
termination of a specified, existing subflow. termination of a specified, existing subflow.
REQ8: An application should be able to inform the MPTCP REQ8: An application should be able to inform the MPTCP
implementation about its high-level performance requirements, implementation about its high-level performance requirements,
e.g., in the form of a profile. e.g., in the form of a profile.
REQ9: An application should be able to indicate communication REQ9: An application should be able to indicate communication
characteristics, e.g., the expected amount of data to be characteristics, e.g., the expected amount of data to be
sent, the expected duration of the connection, or the sent, the expected duration of the connection, or the
expected rate at which data is provided. Applications may in expected rate at which data is provided. Applications may in
some cases be able to forecast such properties. If so, such some cases be able to forecast such properties. If so, such
information could be an additional input parameter for information could be an additional input parameter for
heuristics inside the MPTCP implementation, which could be heuristics inside the MPTCP implementation, which could be
useful for example to decide when to set up additional useful, for example, to decide when to set up additional
subflows. subflows.
REQ10: An application should be able to control the automatic REQ10: An application should be able to control the automatic
establishment/termination of subflows. This would imply a establishment/termination of subflows. This would imply a
selection among different heuristics of the path manager, selection among different heuristics of the path manager,
e.g., 'try as soon as possible', 'wait until there is a bunch e.g., 'try as soon as possible', 'wait until there is a bunch
of data', etc. of data', etc.
REQ11: An application should be able to set preferred subflows or REQ11: An application should be able to set preferred subflows or
subflow usage policies. This would result in a selection subflow usage policies. This would result in a selection
among different configurations of the multipath scheduler. among different configurations of the multipath scheduler.
For instance, an application might want to use certain For instance, an application might want to use certain
subflows as backup only. subflows as backup only.
REQ12: An application should be able to control the level of REQ12: An application should be able to control the level of
redundancy by telling whether segments should be sent on more redundancy by telling whether segments should be sent on more
than one path in parallel. than one path in parallel.
REQ13: An application should be able to control the use of fate REQ13: An application should be able to control the use of fate-
sharing of the MPTCP connection and the initial subflow, sharing of the MPTCP connection and the initial subflow,
e.g., to overwrite system policies. e.g., to overwrite system policies.
REQ14: An application should be able to register for callbacks to be REQ14: An application should be able to register for callbacks to be
informed of changes to subflows on an MPTCP connection. This informed of changes to subflows on an MPTCP connection. This
"push" interface would allow the application to make timely "push" interface would allow the application to make timely
logging and configuration changes, if required, and would logging and configuration changes, if required, and would
avoid frequent polling of information. avoid frequent polling of information.
An advanced API fulfilling these requirements would allow application An advanced API fulfilling these requirements would allow application
developers to more specifically configure MPTCP. It could avoid developers to more specifically configure MPTCP. It could avoid
suboptimal decisions of internal, implicit heuristics. However, it suboptimal decisions of internal, implicit heuristics. However, it
is unclear whether all of these requirements would have a significant is unclear whether all of these requirements would have a significant
benefit to applications, since they are going above and beyond what benefit to applications, since they are going above and beyond what
the existing API to regular TCP provides. the existing API to regular TCP provides.
A subset of this functions might also be implemented system wide or A subset of these functions might also be implemented system-wide or
by other configuration mechanisms. These implementation details are by other configuration mechanisms. These implementation details are
left for further study. left for further study.
A.4. Integration with the SCTP Socket API A.4. Integration with the SCTP Sockets API
The advanced API may also integrate or use the SCTP Socket API. The The advanced API may also integrate or use the SCTP sockets API. The
following functions that are defined for SCTP have a similar following functions that are defined for SCTP have functionality
functionality like the basic MPTCP API: similar to the basic MPTCP API:
o sctp_bindx() o sctp_bindx()
o sctp_connectx() o sctp_connectx()
o sctp_getladdrs() o sctp_getladdrs()
o sctp_getpaddrs() o sctp_getpaddrs()
o sctp_freeladdrs() o sctp_freeladdrs()
o sctp_freepaddrs() o sctp_freepaddrs()
The syntax and semantics of these functions are described in [13]. The syntax and semantics of these functions are described in [13].
A potential objective for the advanced API is to provide a consistent A potential objective for the advanced API is to provide a consistent
MPTCP and SCTP interface to the application. This is left for MPTCP and SCTP interface to the application. This is left for
further study. further study.
skipping to change at page 31, line 14 skipping to change at page 31, line 5
o sctp_freeladdrs() o sctp_freeladdrs()
o sctp_freepaddrs() o sctp_freepaddrs()
The syntax and semantics of these functions are described in [13]. The syntax and semantics of these functions are described in [13].
A potential objective for the advanced API is to provide a consistent A potential objective for the advanced API is to provide a consistent
MPTCP and SCTP interface to the application. This is left for MPTCP and SCTP interface to the application. This is left for
further study. further study.
Appendix B. Change History of the Document
Note to RFC Editor: Remove this section before publication
Changes compared to version draft-ietf-mptcp-api-06:
o IETF last call and IESG review comments
Changes compared to version draft-ietf-mptcp-api-05:
o More explicitly mention port numbers in addition to IP addresses
o Better reference to socket API specification
o Better explanation of fall-back to regular TCP
Changes compared to version draft-ietf-mptcp-api-04:
o Slightly changed abstract (comment by Philip Eardley)
o Removel of redundant text from intro (comment by Philip Eardley)
o New text on the lack of interface differences to regular TCP
regarding closing the connection, also in the resilience
discussion (comment by Philip Eardley)
o Moved AF_MULTIPATH to appendix (comment by Philip Eardley)
o Update of text on connection identifier to align with latest
protocol specification (comment by Lavkesh Lahngir)
o Numerous small editorial changes
Changes compared to version draft-ietf-mptcp-api-03:
o Security consideration section
o Better explanation of the implications of explicitly specified
addresses, most notably during the bind call
o Editorial changes
Changes compared to version draft-ietf-mptcp-api-02:
o Updated references
o Editorial changes
Changes compared to version draft-ietf-mptcp-api-01:
o Additional text on outdated assumptions if an MPTCP application
does not use fate sharing.
o The appendix explicitly mentions an integration of the advanced
MPTCP API and the SCTP API as a potential objective, which is left
for further study for the basic API.
o A short additional explanation of the parameters of the abstract
functions TCP_MULTIPATH_ADD and TCP_MULTIPATH_REMOVE.
o Better explanation when TCP_MULTIPATH_REMOVE may be used.
Changes compared to version draft-ietf-mptcp-api-00:
o Explicitly specify that the TCP_MULTIPATH_SUBFLOWS function
returns port numbers, too. Furthermore, add a new comment that
TCP_MULTIPATH_ADD permits the specification of a port number.
o Mention possible additional extended API functions for the
indication of application characterstics and for backup paths,
based on comments received from the community.
o Mentions alternative approaches for avoiding non-MPTCP-capable
paths to reduce impact on applications.
Changes compared to version draft-scharf-mptcp-api-03:
o Removal of explicit references to "socket options" and getsockopt/
setsockopt.
o Change of TCP_MULTIPATH_BIND to TCP_MULTIPATH_ADD and
TCP_MULTIPATH_REMOVE.
o Mention of stability of bandwidth as another potential QoS
parameter for the advanced API.
o Address comments received from Philip Eardley: Explanation of the
API terminology, more explicit statement concerning applications
that bind to a specific address, and some smaller editorial fixes
Changes compared to version draft-scharf-mptcp-api-02:
o Definition of the behavior of getpeername() and getsockname() when
being called by an MPTCP-aware application.
o Discussion of the possiblity that an MPTCP implementation could
support the SCTP API, as far as it is applicable to MPTCP.
o Various editorial fixes.
Changes compared to version draft-scharf-mptcp-api-01:
o Second half of the document completely restructured
o 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
o Several clarifications, e.g., concerning buffer sizeing and the
use of different scheduling strategies triggered by TCP_NODELAY
o Additional references
Changes compared to version draft-scharf-mptcp-api-00:
o Distinction between legacy and MPTCP-aware applications
o Guidance concerning default enabling, reaction to the shutdown of
the first subflow, etc.
o Reference to a potential use of AF_MULTIPATH
o Additional references to related work
Authors' Addresses Authors' Addresses
Michael Scharf Michael Scharf
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
Lorenzstrasse 10 Lorenzstrasse 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
EMail: michael.scharf@alcatel-lucent.com EMail: michael.scharf@alcatel-lucent.com
Alan Ford Alan Ford
Cisco Cisco
Ruscombe Business Park Ruscombe Business Park
Ruscombe, Berkshire RG10 9NN Ruscombe, Berkshire RG10 9NN
UK UK
EMail: alanford@cisco.com EMail: alanford@cisco.com
 End of changes. 130 change blocks. 
462 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/