draft-ietf-mptcp-api-01.txt   draft-ietf-mptcp-api-02.txt 
Internet Engineering Task Force M. Scharf Internet Engineering Task Force M. Scharf
Internet-Draft Alcatel-Lucent Bell Labs Internet-Draft Alcatel-Lucent Bell Labs
Intended status: Informational A. Ford Intended status: Informational A. Ford
Expires: September 15, 2011 Roke Manor Research Expires: December 9, 2011 Roke Manor Research
March 14, 2011 June 7, 2011
MPTCP Application Interface Considerations MPTCP Application Interface Considerations
draft-ietf-mptcp-api-01 draft-ietf-mptcp-api-02
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
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on December 9, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Comparison of MPTCP and Regular TCP . . . . . . . . . . . . . 5 3. Comparison of MPTCP and Regular TCP . . . . . . . . . . . . . 5
3.1. Performance Impact . . . . . . . . . . . . . . . . . . . . 6 3.1. Performance Impact . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Throughput . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Throughput . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Delay . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Resilience . . . . . . . . . . . . . . . . . . . . . . 7 3.1.3. Resilience . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Potential Problems . . . . . . . . . . . . . . . . . . . . 7 3.2. Potential Problems . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Impact of Middleboxes . . . . . . . . . . . . . . . . 7 3.2.1. Impact of Middleboxes . . . . . . . . . . . . . . . . 7
3.2.2. Outdated Implicit Assumptions . . . . . . . . . . . . 8 3.2.2. Outdated Implicit Assumptions . . . . . . . . . . . . 8
3.2.3. Security Implications . . . . . . . . . . . . . . . . 8 3.2.3. Security Implications . . . . . . . . . . . . . . . . 8
4. Operation of MPTCP with Legacy Applications . . . . . . . . . 8 4. Operation of MPTCP with Legacy Applications . . . . . . . . . 9
4.1. Overview of the MPTCP Network Stack . . . . . . . . . . . 9 4.1. Overview of the MPTCP Network Stack . . . . . . . . . . . 9
4.2. Address Issues . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Address Issues . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Specification of Addresses by Applications . . . . . . 10 4.2.1. Specification of Addresses by Applications . . . . . . 10
4.2.2. Querying of Addresses by Applications . . . . . . . . 10 4.2.2. Querying of Addresses by Applications . . . . . . . . 10
4.3. Socket Option Issues . . . . . . . . . . . . . . . . . . . 11 4.3. Socket Option Issues . . . . . . . . . . . . . . . . . . . 11
4.3.1. General Guideline . . . . . . . . . . . . . . . . . . 11 4.3.1. General Guideline . . . . . . . . . . . . . . . . . . 11
4.3.2. Disabling of the Nagle Algorithm . . . . . . . . . . . 11 4.3.2. Disabling of the Nagle Algorithm . . . . . . . . . . . 11
4.3.3. Buffer Sizing . . . . . . . . . . . . . . . . . . . . 11 4.3.3. Buffer Sizing . . . . . . . . . . . . . . . . . . . . 12
4.3.4. Other Socket Options . . . . . . . . . . . . . . . . . 12 4.3.4. Other Socket Options . . . . . . . . . . . . . . . . . 12
4.4. Default Enabling of MPTCP . . . . . . . . . . . . . . . . 12 4.4. Default Enabling of MPTCP . . . . . . . . . . . . . . . . 12
4.5. Summary of Advices to Application Developers . . . . . . . 12 4.5. Summary of Advices to Application Developers . . . . . . . 12
5. Basic API for MPTCP-aware Applications . . . . . . . . . . . . 13 5. Basic API for MPTCP-aware Applications . . . . . . . . . . . . 13
5.1. Design Considerations . . . . . . . . . . . . . . . . . . 13 5.1. Design Considerations . . . . . . . . . . . . . . . . . . 13
5.2. Requirements on the Basic MPTCP API . . . . . . . . . . . 14 5.2. Requirements on the Basic MPTCP API . . . . . . . . . . . 14
5.3. Sockets Interface Extensions by the Basic MPTCP API . . . 15 5.3. Sockets Interface Extensions by the Basic MPTCP API . . . 15
5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.2. Enabling and Disabling of MPTCP . . . . . . . . . . . 16 5.3.2. Enabling and Disabling of MPTCP . . . . . . . . . . . 16
5.3.3. Binding MPTCP to Specified Addresses . . . . . . . . . 17 5.3.3. Binding MPTCP to Specified Addresses . . . . . . . . . 17
5.3.4. Querying the MPTCP Subflow Addresses . . . . . . . . . 17 5.3.4. Querying the MPTCP Subflow Addresses . . . . . . . . . 18
5.3.5. Getting a Unique Connection Identifier . . . . . . . . 18 5.3.5. Getting a Unique Connection Identifier . . . . . . . . 18
6. Other Compatibility Issues . . . . . . . . . . . . . . . . . . 18 6. Other Compatibility Issues . . . . . . . . . . . . . . . . . . 18
6.1. Usage of the SCTP Socket API . . . . . . . . . . . . . . . 18 6.1. Usage of the SCTP Socket API . . . . . . . . . . . . . . . 18
6.2. Incompatibilities with other Multihoming Solutions . . . . 19 6.2. Incompatibilities with other Multihoming Solutions . . . . 19
6.3. Interactions with DNS . . . . . . . . . . . . . . . . . . 19 6.3. Interactions with DNS . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Requirements on a Future Advanced MPTCP API . . . . . 22 Appendix A. Requirements on a Future Advanced MPTCP API . . . . . 22
A.1. Design Considerations . . . . . . . . . . . . . . . . . . 22 A.1. Design Considerations . . . . . . . . . . . . . . . . . . 22
A.2. MPTCP Usage Scenarios and Application Requirements . . . . 22 A.2. MPTCP Usage Scenarios and Application Requirements . . . . 22
A.3. Potential Requirements on an Advanced MPTCP API . . . . . 24 A.3. Potential Requirements on an Advanced MPTCP API . . . . . 24
A.4. Integration with the SCTP Socket API . . . . . . . . . . . 25
Appendix B. Change History of the Document . . . . . . . . . . . 26 Appendix B. Change History of the Document . . . . . . . . . . . 26
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 utilisation, 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]. The MPTCP protocol [5] offers the same reliable,
skipping to change at page 8, line 38 skipping to change at page 8, line 38
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 socket interface
to a flow through a network. Since MPTCP can make use of multiple to a flow through a network. Since MPTCP can make use of multiple
subflows, applications cannot implicitly rely on this one-to-one subflows, applications cannot implicitly rely on this one-to-one
mapping any more. Applications that require the transport along a mapping any more. Applications that require the transport along a
single path can disable the use of MPTCP as described later in this single path 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.
Furthermore, an implementation may choose to persist an MPTCP
connection even if an IP address is not allocated any more to a host,
depending on the policy concerning the first subflow (fate-sharing,
see Section 4.2.2). In this case, the IP address exposed to an
MPTCP-unaware application can differ to the addresses actually been
used by MPTCP. It is even possible that an IP address gets assigned
to another host during the lifetime of an MPTCP connection.
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-
path TCP, which is vulnerable to man-in-the-middle attacks, too. A path TCP, which is vulnerable to man-in-the-middle attacks, too. A
detailed thread analysis of MPTCP is published in [6]. detailed thread analysis of MPTCP is published in [6].
skipping to change at page 15, line 36 skipping to change at page 15, line 45
existing calls such as setsockopt() and getsockopt(), or could be existing calls such as setsockopt() and getsockopt(), or could be
implemented as entirely new function calls. This implementation implemented as entirely new function calls. This implementation
decision is out of scope for this document. The following list decision is out of scope for this document. The following list
presents symbolic names for these MPTCP socket settings. presents symbolic names for these 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 new local address to an existing MPTCP connection or add a new local address to an existing MPTCP connection
o TCP_MUTLIPATH_REMOVE: Remove a local address from a MPTCP o TCP_MULTIPATH_REMOVE: Remove a local address from an MPTCP
connection connection
o TCP_MULTIPATH_SUBFLOWS: Get the pairs of addresses currently used o TCP_MULTIPATH_SUBFLOWS: Get the pairs of addresses currently used
by the MPTCP subflows by the MPTCP subflows
o TCP_MULTIPATH_CONNID: Get the local connection identifier for this o TCP_MULTIPATH_CONNID: Get the local connection identifier for this
MPTCP connection MPTCP connection
Table Table 1 shows a list of the abstract socket operations for the Table Table 1 shows a list of the abstract socket operations for the
basic configuration of MPTCP. The first column gives the symbolic basic configuration of MPTCP. The first column gives the symbolic
skipping to change at page 16, line 29 skipping to change at page 16, line 36
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 both applied before
connection setup or during a connection. If used before, it connection setup or 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 only has meaning after o TCP_MULTIPATH_REMOVE: This operation can be both applied before
connection setup. connection setup or during a connection. In both cases, it
removes an address from the list of local addresses that may be
used by subflows.
o TCP_MULTIPATH_SUBFLOWS: This value is read-only and SHOULD only be o TCP_MULTIPATH_SUBFLOWS: This value is read-only and SHOULD 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 a value larger than 0. In this case, setting TCP_MULTIPATH_ENABLE to a value larger than 0. In this case,
the MPTCP implementation SHOULD try to negitiate MPTCP for that the MPTCP implementation SHOULD try to negitiate 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 multiple addresses and support in the other enabled, as it requires multiple addresses and support in the other
end-system and potentially also on middleboxes. end-system and potentially also on middleboxes.
An application can disable MPTCP setting TCP_MUTLIPATH_ENABLE to a An application can disable MPTCP setting TCP_MULTIPATH_ENABLE to a
value of 0. In that case, MPTCP MUST NOT be used on that connection. value of 0. In that case, MPTCP MUST NOT be used on that 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 0 then means lack of MPTCP support. TCP_MULTIPATH_ENABLE. A value of 0 then means lack of MPTCP support.
Any value equal to or larger than 1 means that MPTCP is supported. Any value equal to or larger than 1 means that MPTCP is supported.
As alternative to setting an explicit value, an application could As alternative to setting an explicit value, an application could
also use a new, separate address family called AF_MULTIPATH [9]. also use a new, separate address family called AF_MULTIPATH [9].
This separate address family can be used to exchange multiple This separate address family can be used to exchange multiple
addresses between an application and the standard sockets API, and addresses between an application and the standard sockets API, and
skipping to change at page 17, line 20 skipping to change at page 17, line 29
MPTCP-aware, i.e., that it can deal with the semantic changes of the MPTCP-aware, i.e., that it can deal with the semantic changes of the
sockets API, in particular concerning getpeername() and sockets API, in particular concerning getpeername() and
getsockname(). The usage of AF_MULTIPATH is also more flexible with getsockname(). The usage of AF_MULTIPATH is also more flexible with
respect to multipath transport, either IPv4 or IPv6, or both in respect to multipath transport, either IPv4 or IPv6, or both in
parallel [9]. parallel [9].
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
TCP_MULTIPATH_ADD socket option to indicate a set of local IP TCP_MULTIPATH_ADD socket option to indicate a set of local IP
addresses that MPTCP may bind to. By extension, this operation will addresses that MPTCP may bind to. The parameter of the function is a
also control the list of addresses that can be advertised to the peer list of addresses in a corresponding data structure. By extension,
via MPTCP signalling. this operation will also control the list of addresses that can be
advertised to the peer via MPTCP signalling.
An application MAY also indicate a TCP port number that MPTCP should An application MAY also indicate a TCP port number that MPTCP should
bind to for a given address. The port number MAY be different to the bind to for a given address. The port number MAY be different to the
one used by existing subflows. If no port number is provided by the one used by existing subflows. If no port number is provided by the
application, the port number is automatically selected by the MPTCP application, the port number is automatically selected by the MPTCP
implementation, and will usually be the same across all subflows. implementation, and will usually be 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
skipping to change at page 18, line 30 skipping to change at page 18, line 41
6. Other Compatibility Issues 6. Other Compatibility Issues
6.1. Usage of the SCTP Socket API 6.1. Usage of the SCTP Socket API
For dealing with multi-homing, several socket API extensions have For dealing with multi-homing, several socket API extensions have
been defined for SCTP [14]. As MPTCP realizes multipath transport been defined for SCTP [14]. As MPTCP realizes multipath transport
from and to multi-homed endsystems, some of these interface function from and to multi-homed endsystems, 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.
The following functions that are defined for SCTP have similar
functionality to the MPTCP API extensions defined earlier:
o sctp_bindx()
o sctp_connectx()
o sctp_getladdrs()
o sctp_getpaddrs()
The syntax and semantics of these functions are described in [14].
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 to SCTP, and this is why not all SCTP API functions can be mapped
directly to MPTCP. Furthermore, a network stack implementing MPTCP directly to MPTCP. Furthermore, a network stack implementing MPTCP
does not necessarily support SCTP and its specific socket interface does not necessarily support SCTP and its specific socket interface
extensions. This is why the basic API of MPTCP defines additional extensions. This is why the basic API of MPTCP defines additional
socket options only, which are a backward compatible extension of socket options only, which are a backward compatible extension of
TCP's application interface. TCP's application interface. An integration with the SCTP API is
outside the scope of the basic API.
6.2. Incompatibilities with other Multihoming Solutions 6.2. 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 [12]. Care should be taken multipath transport such as MPTCP or SCTP [12]. Care should be taken
for the usage not to confuse with the overlapping features of other for the usage not to confuse with the overlapping features of other
APIs: APIs:
o SHIM API [12]: This API specifies sockets API extensions for the o SHIM API [12]: This API specifies sockets API extensions for the
skipping to change at page 20, line 18 skipping to change at page 20, line 18
specifies a basic MPTCP API. For legacy applications, it is ensured specifies a basic MPTCP API. For legacy applications, it is ensured
that the existing sockets API continues to work. MPTCP-aware that the existing sockets API continues to work. MPTCP-aware
applications can use the basic MPTCP API that provides some control applications can use the basic MPTCP API that provides some control
over the transport layer equivalent to regular TCP. A more fine- over the transport layer equivalent to regular TCP. A more fine-
granular interaction between applications and MPTCP requires an granular interaction between applications and MPTCP requires an
advanced MPTCP API, which is not specified in this document. advanced MPTCP API, which is not specified in this document.
10. Acknowledgments 10. Acknowledgments
Authors sincerely thank to the following people for their helpful Authors sincerely thank to the following people for their helpful
comments to the document: Costin Raiciu, Philip Eardley comments and reviews of the document: Costin Raiciu, Philip Eardley,
Javier Ubillos, and Michael Tuexen.
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 is supported by Trilogy Education and Research (BMBF). Alan Ford is supported by Trilogy
(http://www.trilogy-project.org/), a research project (ICT-216372) (http://www.trilogy-project.org/), a research project (ICT-216372)
partially funded by the European Community under its Seventh partially funded by the European Community under its Seventh
Framework Program. The views expressed here are those of the Framework Program. The views expressed here are those of the
author(s) only. The European Commission is not liable for any use author(s) only. The European Commission is not liable for any use
that may be made of the information in this document. that may be made of the information in this document.
skipping to change at page 20, line 44 skipping to change at page 20, line 45
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",
draft-ietf-mptcp-architecture-05 (work in progress), RFC 6182, March 2011.
January 2011.
[5] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for [5] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
Multipath Operation with Multiple Addresses", Extensions for Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-02 (work in progress), draft-ietf-mptcp-multiaddressed-03 (work in progress),
October 2010. March 2011.
[6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multi-path [6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses", draft-ietf-mptcp-threat-08 Operation with Multiple Addresses", RFC 6181, March 2011.
(work in progress), January 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", Control for Multipath Transport Protocols",
draft-ietf-mptcp-congestion-01 (work in progress), draft-ietf-mptcp-congestion-03 (work in progress), April 2011.
January 2011.
[8] "IEEE Std. 1003.1-2008 Standard for Information Technology -- [8] "IEEE Std. 1003.1-2008 Standard for Information Technology --
Portable Operating System Interface (POSIX). Open Group Portable Operating System Interface (POSIX). Open Group
Technical Standard: Base Specifications, Issue 7, 2008.". Technical Standard: Base Specifications, Issue 7, 2008.".
11.2. Informative References 11.2. Informative References
[9] Sarolahti, P., "Multi-address Interface in the Socket API", [9] Sarolahti, P., "Multi-address Interface in the Socket API",
draft-sarolahti-mptcp-af-multipath-01 (work in progress), draft-sarolahti-mptcp-af-multipath-01 (work in progress),
March 2010. March 2010.
[10] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced [10] 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.
[11] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for [11] Chakrabarti, S. and E. Nordmark, "Extension to Sockets API for
Mobile IPv6", RFC 4584, July 2006. Mobile IPv6", RFC 4584, July 2006.
[12] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket [12] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket
Application Program Interface (API) for Multihoming Shim", Application Program Interface (API) for Multihoming Shim",
draft-ietf-shim6-multihome-shim-api-16 (work in progress), draft-ietf-shim6-multihome-shim-api-17 (work in progress),
February 2011. April 2011.
[13] Komu, M. and T. Henderson, "Basic Socket Interface Extensions [13] Komu, M. and T. Henderson, "Basic Socket Interface Extensions
for Host Identity Protocol (HIP)", draft-ietf-hip-native-api-12 for Host Identity Protocol (HIP)", draft-ietf-hip-native-api-12
(work in progress), January 2010. (work in progress), January 2010.
[14] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, [14] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich,
"Sockets API Extensions for Stream Control Transmission "Sockets API Extensions for Stream Control Transmission
Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-27 (work in Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-29 (work in
progress), March 2011. progress), April 2011.
[15] Blanchet, M. and P. Seite, "Multiple Interfaces and [15] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-09 (work in progress), draft-ietf-mif-problem-statement-15 (work in progress),
October 2010. May 2011.
[16] Wasserman, M. and P. Seite, "Current Practices for Multiple [16] Wasserman, M. and P. Seite, "Current Practices for Multiple
Interface Hosts", draft-ietf-mif-current-practices-08 (work in Interface Hosts", draft-ietf-mif-current-practices-11 (work in
progress), February 2011. progress), April 2011.
[17] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards [17] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards
Success with Dual-Stack Hosts", Success with Dual-Stack Hosts",
draft-ietf-v6ops-happy-eyeballs-00 (work in progress), draft-ietf-v6ops-happy-eyeballs-01 (work in progress),
March 2011. March 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 behaviour. A offer much control of the MPTCP implementation's behaviour. A
skipping to change at page 26, line 5 skipping to change at page 25, line 47
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 this 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
The advanced API may also integrate or use the SCTP Socket API. The
following functions that are defined for SCTP have a similar
functionality like the basic MPTCP API:
o sctp_bindx()
o sctp_connectx()
o sctp_getladdrs()
o sctp_getpaddrs()
o sctp_freeladdrs()
o sctp_freepaddrs()
The syntax and semantics of these functions are described in [14].
A potential objective for the advanced API is to provide a consistent
MPTCP and SCTP interface to the application. This is left for
further study in this document.
Appendix B. Change History of the Document Appendix B. Change History of the Document
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: Changes compared to version draft-ietf-mptcp-api-00:
o Explicitly specify that the TCP_MULTIPATH_SUBFLOWS function o Explicitly specify that the TCP_MULTIPATH_SUBFLOWS function
returns port numbers, too. Furthermore, add a new comment that returns port numbers, too. Furthermore, add a new comment that
TCP_MULTIPATH_ADD permits the specification of a port number. TCP_MULTIPATH_ADD permits the specification of a port number.
o Mention possible additional extended API functions for the o Mention possible additional extended API functions for the
indication of application characterstics and for backup paths, indication of application characterstics and for backup paths,
based on comments received from the community. based on comments received from the community.
 End of changes. 26 change blocks. 
49 lines changed or deleted 85 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/