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/