draft-ietf-mptcp-api-05.txt   draft-ietf-mptcp-api-06.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: October 19, 2012 Cisco Expires: April 25, 2013 Cisco
April 17, 2012 October 22, 2012
MPTCP Application Interface Considerations MPTCP Application Interface Considerations
draft-ietf-mptcp-api-05 draft-ietf-mptcp-api-06
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 October 19, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 4, line 30 skipping to change at page 4, line 30
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
access to information of an MPTCP connection that would be possible access to information of an MPTCP connection that would be possible
with the standard TCP API on a regular TCP connection. with the standard TCP API on a regular TCP connection.
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. This document provides an abstract definition of MPTCP- interface [17]. This document provides an abstract definition of
specific extensions to this interface. These are operations that can MPTCP-specific extensions to this interface. These are operations
be used by an application to get or set additional MPTCP-specific that can be used by an application to get or set additional MPTCP-
information on a socket, in order to provide an equivalent level of specific information on a socket, in order to provide an equivalent
information and control over MPTCP as exists for an application using level of information and control over MPTCP as exists for an
regular TCP. It is up to the applications, high-level programming application using regular TCP. It is up to the applications, high-
languages, or libraries to decide whether to use these optional level programming languages, or libraries to decide whether to use
extensions. For instance, an application may want to turn on or off these optional extensions. For instance, an application may want to
the MPTCP mechanism for certain data transfers, or limit its use to turn on or off the MPTCP mechanism for certain data transfers, or
certain interfaces. The abstract specification is in line with the limit its use to certain interfaces. The abstract specification is
Posix standard [17] as much as possible. in line with the Posix standard [17] 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 a
brief, non-compulsory list of potential features of such an advanced brief, non-compulsory list of potential features of such an advanced
API. 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 socket interface extensions, which are discussed later in
this document. Some network stack implementations, specially on this document. Some network stack implementations, specially on
skipping to change at page 6, line 10 skipping to change at page 6, line 10
not provide a worse performing connection than would have existed not provide a worse performing connection than would have existed
through the use of single-path TCP. A corresponding congestion through the use of single-path TCP. A corresponding congestion
control algorithm is described in [7]. The following sections control algorithm is described in [7]. The following sections
summarize the performance impact of MPTCP as seen by an application. summarize the performance impact of MPTCP as seen by an application.
3.1.1. Throughput 3.1.1. Throughput
The most obvious performance improvement that will be gained with the The most obvious performance improvement that will be gained with the
use of MPTCP is an increase in throughput, since MPTCP will pool more use of MPTCP is an increase in throughput, since MPTCP will pool more
than one path (where available) between two endpoints. This will than one path (where available) between two endpoints. This will
provide greater bandwidth for an application. If there are shared provide as great or greater bandwidth for an application. If there
bottlenecks between the flows, then the congestion control algorithms are shared bottlenecks between the flows, then the congestion control
will ensure that load is evenly spread amongst regular and multipath algorithms will ensure that load is evenly spread amongst regular and
TCP sessions, so that no end user receives worse performance than if multipath TCP sessions, so that no end user receives worse
all were using single-path TCP. performance than if all were using single-path TCP.
This performance increase additionally means that an MPTCP session This performance increase additionally means that an MPTCP session
could achieve throughput that is greater than the capacity of a could achieve throughput that is greater than the capacity of a
single interface on the device. If any applications make assumptions single interface on the device. If any applications make assumptions
about interfaces due to throughput (or vice versa), they must take about interfaces due to throughput (or vice versa), they must take
this into account (although an MPTCP implementation must always this into account (although an MPTCP implementation must always
respect an application's request for a particular interface). respect an 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
skipping to change at page 7, line 51 skipping to change at page 7, line 51
middleboxes. Empirical evidence suggests that new TCP options can middleboxes. Empirical evidence suggests that new TCP options can
successfully be used on most paths in the Internet [18]. successfully be used on most paths in the Internet [18].
Nevertheless some middleboxes may still refuse to pass MPTCP messages Nevertheless some middleboxes may still refuse to pass MPTCP messages
due to the presence of TCP options, or they may strip TCP options. due to the presence of TCP options, or they may strip TCP options.
If this is the case, MPTCP falls back to regular TCP. Although this If this is the case, MPTCP falls back to regular TCP. Although this
will not create a problem for the application (its communication will will not create a problem for the application (its communication will
be set up either way), there may be additional (and indeed, user- be set 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 first (or apply a timeout on the MPTCP attempt, while having replies first in a similar fashion to the "Happy Eyeballs" mechanism
TCP SYN/ACK ready to reply to, thus reducing the setup delay by a for IPv6 [16]. On could also apply a shorter timeout on the MPTCP
RTT) in a similar fashion to the "Happy Eyeballs" mechanism for IPv6 attempt and thus reduce the setup delay if fallback to regular TCP is
[16]. 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]. the connection, is presented in [5].
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
skipping to change at page 16, line 37 skipping to change at page 16, line 37
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 1 shows a list of the abstract socket operations for the basic Table 1 shows a list of the abstract socket operations for the basic
configuration of MPTCP. The first column gives the symbolic name of configuration of MPTCP. The first column gives the symbolic name of
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. associated with this operation. In addition to IP addresses, an
application MAY also indicate TCP port numbers, as further detailed
+------------------------+-----+-----+----------------------------+ below.
| Name | Get | Set | Data type |
+------------------------+-----+-----+----------------------------+
| TCP_MULTIPATH_ENABLE | o | o | boolean |
| TCP_MULTIPATH_ADD | | o | list of addresses |
| TCP_MULTIPATH_REMOVE | | o | list of addresses |
| TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses |
| TCP_MULTIPATH_CONNID | o | | 32-bit integer |
+------------------------+-----+-----+----------------------------+
+------------------------+-----+-----+------------------------------+
| Name | Get | Set | Data type |
+------------------------+-----+-----+------------------------------+
| TCP_MULTIPATH_ENABLE | o | o | boolean |
| TCP_MULTIPATH_ADD | | o | list of addresses (and |
| | | | ports) |
| TCP_MULTIPATH_REMOVE | | o | list of addresses (and |
| | | | ports) |
| TCP_MULTIPATH_SUBFLOWS | o | | list of pairs of addresses |
| | | | (and ports) |
| TCP_MULTIPATH_CONNID | o | | 32-bit 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 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 both applied before
connection setup or during a connection. If used before, it connection setup or during a connection. If used before, it
skipping to change at page 22, line 21 skipping to change at page 22, line 27
[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-07 (work in progress), draft-ietf-mptcp-multiaddressed-09 (work in progress),
March 2012. June 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.
11.2. Informative References 11.2. Informative References
[8] Sarolahti, P., "Multi-address Interface in the Socket API", [8] Sarolahti, P., "Multi-address Interface in the Socket API",
draft-sarolahti-mptcp-af-multipath-01 (work in progress),
March 2010. March 2010.
[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
skipping to change at page 23, line 22 skipping to change at page 23, line 27
Interface Hosts", RFC 6419, November 2011. Interface Hosts", RFC 6419, November 2011.
[16] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [16] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[17] "IEEE Std. 1003.1-2008 Standard for Information Technology -- [17] "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.".
[18] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, [18] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley,
M., and H. Tokuda, "Is it Still Possible to Extend TCP?", M., and H. Tokuda, "Is it Still Possible to Extend TCP?", Proc.
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
 End of changes. 11 change blocks. 
40 lines changed or deleted 43 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/