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/