draft-ietf-mptcp-api-00.txt   draft-ietf-mptcp-api-01.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: June 2, 2011 Roke Manor Research Expires: September 15, 2011 Roke Manor Research
November 29, 2010 March 14, 2011
MPTCP Application Interface Considerations MPTCP Application Interface Considerations
draft-ietf-mptcp-api-00 draft-ietf-mptcp-api-01
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 June 2, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . 8
4.1. Overview of the MPTCP Network Stack . . . . . . . . . . . 8 4.1. Overview of the MPTCP Network Stack . . . . . . . . . . . 9
4.2. Address Issues . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Address Issues . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Specification of Addresses by Applications . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . 13 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 . . . . . . . . . 17
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 . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . 21 Appendix A. Requirements on a Future Advanced MPTCP API . . . . . 22
A.1. Design Considerations . . . . . . . . . . . . . . . . . . 21 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
Appendix B. Change History of the Document . . . . . . . . . . . 25 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,
in-order, byte-stream transport as TCP, and is designed to be in-order, byte-stream transport as TCP, and is designed to be
skipping to change at page 7, line 48 skipping to change at page 7, line 48
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 in order to pass through the majority of
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. Nevertheless successfully be used on most paths in the Internet. Nevertheless
some middleboxes may still refuse to pass MPTCP messages due to the some middleboxes may still refuse to pass MPTCP messages due to the
presence of TCP options, or they may strip TCP options. If this is presence of TCP options, or they may strip TCP options. If this is
the case, MPTCP should fall back to regular TCP. Although this will the case, MPTCP should fall back to regular TCP. Although this will
not create a problem for the application (its communication will be not create a problem for the application (its communication will be
set up either way), there may be additional (and indeed, user- set up either way), there may be additional (and indeed, user-
perceivable) delay while the first handshake fails. A detailed perceivable) delay while the first handshake fails. Therefore, an
discussion of the various fallback mechanisms, for failures occurring alternative approach could be to try both MPTCP and regular TCP
at different points in the connection, is presented in [5]. connection attempts at the same time, and respond to whichever
replies first (or apply a timeout on the MPTCP attempt, while having
TCP SYN/ACK ready to reply to, thus reducing the setup delay by a
RTT) in a similar fashion to the "Happy Eyeballs" proposal for IPv6
[17].
An MPTCP implementation can learn the rate of MPTCP connection
attempt successes or failures to particular hosts or networks, and on
particular interfaces, and could therefore learn heuristics of when
and when not to use MPTCP. A detailed discussion of the various
fallback mechanisms, for failures occurring at different points in
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
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 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
skipping to change at page 17, line 24 skipping to change at page 17, line 24
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. By extension, this operation will
also control the list of addresses that can be advertised to the peer also control the list of addresses that can be advertised to the peer
via MPTCP signalling. via MPTCP signalling.
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
one used by existing subflows. If no port number is provided by the
application, the port number is automatically selected by the MPTCP
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
connection can make use of, and which can be signalled to the peer. connection can make use of, and which can be signalled to the peer.
It should be noted that this signal is only a hint, and an MPTCP It should be noted that this signal is only a hint, and an MPTCP
implementation MAY only use a subset of the addresses. implementation MAY only use 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 (set of)
local addresses from an MPTCP connection. MPTCP MUST close any local addresses from an MPTCP connection. MPTCP MUST close any
corresponding subflows (i.e. those using the local address that is no corresponding subflows (i.e. those using the local address that is no
skipping to change at page 17, line 47 skipping to change at page 18, line 4
establish alternative subflows before undertaking the address establish alternative subflows before undertaking the address
removal. 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 by means of the read-only TCP_MULTIPATH_SUBFLOWS established subflows by means of the read-only TCP_MULTIPATH_SUBFLOWS
operation. The return value is a list of pairs of IP addresses. In operation. The return value is a list of pairs of tuples of IP
one pair, the first address refers to the local IP address, and the address and TCP port number. In one pair, the first tuple refers to
second one to the remote IP address used by the subflow. The list the local IP address and the local TCP port, and the second one to
MUST only include established subflows. Each address pair MUST be the remote IP address and remote TCP port used by the subflow. The
either a pair of IPv4 addresses or a pair of IPv6 addresses. list MUST only include established subflows. Both addresses in each
pair MUST be 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 is a 32-bit number, and SHOULD be the same as the local This is a 32-bit number, and SHOULD be the same as the local
connection identifier sent in the MPTCP handshake. connection identifier sent in the MPTCP handshake.
skipping to change at page 19, line 37 skipping to change at page 19, line 44
issues that are not specific to MPTCP, but have to be considered, issues that are not specific to MPTCP, but have to be considered,
too. These problems are summarized in [15]. too. These problems are summarized in [15].
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.
TODO: Elaborate on DNS
7. Security Considerations 7. Security Considerations
Will be added in a later version of this document. Will be added in a later version of this document.
8. IANA Considerations 8. IANA Considerations
No IANA considerations. No IANA considerations.
9. Conclusion 9. Conclusion
skipping to change at page 20, line 36 skipping to change at page 20, line 42
[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., 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-02 (work in progress), draft-ietf-mptcp-architecture-05 (work in progress),
October 2010. January 2011.
[5] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for [5] Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-02 (work in progress), draft-ietf-mptcp-multiaddressed-02 (work in progress),
October 2010. October 2010.
[6] Bagnulo, M., "Threat Analysis for Multi-addressed/Multi-path [6] Bagnulo, M., "Threat Analysis for TCP Extensions for Multi-path
TCP", draft-ietf-mptcp-threat-04 (work in progress), Operation with Multiple Addresses", draft-ietf-mptcp-threat-08
November 2010. (work in progress), January 2011.
[7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Multipath- [7] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion
Aware Congestion Control", draft-ietf-mptcp-congestion-00 (work Control for Multipath Transport Protocols",
in progress), July 2010. draft-ietf-mptcp-congestion-01 (work in progress),
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-13 (work in progress), draft-ietf-shim6-multihome-shim-api-16 (work in progress),
February 2010. February 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., Poon, K., Tuexen, M., Yasevich, V., and P. Lei, [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-23 (work in Protocol (SCTP)", draft-ietf-tsvwg-sctpsocket-27 (work in
progress), July 2010. progress), March 2011.
[15] Blanchet, M. and P. Seite, "Multiple Interfaces Problem [15] Blanchet, M. and P. Seite, "Multiple Interfaces and
Statement", draft-ietf-mif-problem-statement-04 (work in Provisioning Domains Problem Statement",
progress), May 2010. draft-ietf-mif-problem-statement-09 (work in progress),
October 2010.
[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-01 (work in Interface Hosts", draft-ietf-mif-current-practices-08 (work in
progress), June 2010. progress), February 2011.
[17] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards
Success with Dual-Stack Hosts",
draft-ietf-v6ops-happy-eyeballs-00 (work in progress),
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
future, advanced API could address further features of MPTCP and future, advanced API could address further features of MPTCP and
skipping to change at page 24, line 47 skipping to change at page 25, line 16
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 new subflow to would be a request for the establishment of a new subflow to
a provided destination, or a request for the termination of a a provided destination, or a request for the termination of a
specified, existing subflow. 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 form of a profile. e.g., in form of a profile.
REQ9: An application should be able to control the automatic REQ9: An application should be able to indicate communication
characteristics, e. g., the expected amount of data to be
sent, the expected duration of the connection, or the
expected rate at which data is provided. Applications may in
some cases be able to forecast such properties. If so, such
information could be an additional input parameter for
heuristics inside the MPTCP implementation, which could be
useful for example to decide when to set up additional
subflows.
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.
REQ10: 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
subflows as backup only.
REQ11: 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.
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
by other configuration mechanisms. These implementation details are
left for further study.
Appendix B. Change History of the Document Appendix B. Change History of the Document
Changes compared to version 03: 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/ o Removal of explicit references to "socket options" and getsockopt/
setsockopt. setsockopt.
o Change of TCP_MULTIPATH_BIND to TCP_MULTIPATH_ADD and o Change of TCP_MULTIPATH_BIND to TCP_MULTIPATH_ADD and
TCP_MULTIPATH_REMOVE. TCP_MULTIPATH_REMOVE.
o Mention of stability of bandwidth as another potential QoS o Mention of stability of bandwidth as another potential QoS
parameter for the advanced API. parameter for the advanced API.
o Address comments received from Philip Eardley: Explanation of the o Address comments received from Philip Eardley: Explanation of the
API terminology, more explicit statement concerning applications API terminology, more explicit statement concerning applications
that bind to a specific address, and some smaller editorial fixes that bind to a specific address, and some smaller editorial fixes
Changes compared to version 02: Changes compared to version draft-scharf-mptcp-api-02:
o Definition of the behavior of getpeername() and getsockname() when o Definition of the behavior of getpeername() and getsockname() when
being called by an MPTCP-aware application. being called by an MPTCP-aware application.
o Discussion of the possiblity that an MPTCP implementation could o Discussion of the possiblity that an MPTCP implementation could
support the SCTP API, as far as it is applicable to MPTCP. support the SCTP API, as far as it is applicable to MPTCP.
o Various editorial fixes. o Various editorial fixes.
Changes compared to version 01: Changes compared to version draft-scharf-mptcp-api-01:
o Second half of the document completely restructured o Second half of the document completely restructured
o Separation between a basic API and an advanced API: The focus of o Separation between a basic API and an advanced API: The focus of
the document is the basic API only; all text concerning a the document is the basic API only; all text concerning a
potential extended API is moved to the appendix potential extended API is moved to the appendix
o Several clarifications, e. g., concerning buffer sizeing and the o Several clarifications, e. g., concerning buffer sizeing and the
use of different scheduling strategies triggered by TCP_NODELAY use of different scheduling strategies triggered by TCP_NODELAY
o Additional references o Additional references
Changes compared to version 00: Changes compared to version draft-scharf-mptcp-api-00:
o Distinction between legacy and MPTCP-aware applications o Distinction between legacy and MPTCP-aware applications
o Guidance concerning default enabling, reaction to the shutdown of o Guidance concerning default enabling, reaction to the shutdown of
the first subflow, etc. the first subflow, etc.
o Reference to a potential use of AF_MULTIPATH o Reference to a potential use of AF_MULTIPATH
o Additional references to related work o Additional references to related work
 End of changes. 32 change blocks. 
50 lines changed or deleted 102 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/