Internet DRAFT - draft-bonaventure-mptcp-exp-option
draft-bonaventure-mptcp-exp-option
MPTCP Working Group O. Bonaventure
Internet-Draft B. Hesmans
Updates: 6824 (if approved) UCLouvain
Intended status: Experimental M. Boucadair
Expires: December 18, 2015 Orange
June 16, 2015
Experimental Multipath TCP option
draft-bonaventure-mptcp-exp-option-00
Abstract
This document proposes a generic format for an experimental Multipath
TCP option. This experimental option is expected to replace the
option type that was reserved for private use in [RFC6824].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bonaventure, et al. Expires December 18, 2015 [Page 1]
Internet-Draft Exp. MPTCP Option June 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Experimental Multipath TCP option . . . . . . . . . . . . 3
3. Security considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Multipath TCP is an extension to TCP [RFC0793] that was specified in
[RFC6824]. Like other TCP extensions, Multipath TCP relies on TCP
options to exchange information. To mitigate some forms of middlebox
interference, Multipath TCP uses only one TCP option identified by
Kind=30 [RFC6824]. TCP Option Kind=30 has a variable length and
includes a subtype field that can support up to 16 different
Multipath TCP options. As of this writing, 8 different Multipath TCP
options are defined [RFC6824] :
o subtype=0x0 : MP_CAPABLE
o subtype=0x1 : MP_JOIN
o subtype=0x2 : DSS
o subtype=0x3 : ADD_ADDR
o subtype=0x4 : REMOVE_ADDR
o subtype=0x5 : MP_PRIO
o subtype=0x6 : MP_FAIL
o subtype=0x7 : MP_FASTCLOSE
In addition, subtype=0x8 is already reserved for a new version of the
ADD_ADDR option [I-D.ietf-mptcp-rfc6824bis] and subtype=0xf is
reserved for use in private testbeds [RFC6824]. There are thus less
than six different Multipath TCP options that are available to extend
the protocol.
The Multipath TCP options defined above cover the basic
functionalities for Multipath TCP but previous experience with TCP
Bonaventure, et al. Expires December 18, 2015 [Page 2]
Internet-Draft Exp. MPTCP Option June 2015
indicates that it can be expected that Multipath TCP implementors
will propose new extensions that require a new option subtype. Some
authors have already proposed such extensions
[I-D.boucadair-mptcp-symmetric] [I-D.paasch-mptcp-syncookies]
[I-D.xu-mptcp-prmp]. Given the small number of available Multipath
TCP options, it will be difficult to officially reserve them for all
proposed utilisations even if experiments with these new Multipath
TCP options would probably be useful.
This document proposes a shared use of the Multipath TCP option
subtype=0xf following a similar approach as described in [RFC6994]
for TCP. This approach is efficient as it encourages conducting new
experiments while not consuming the limited option codepoint space.
2. The Experimental Multipath TCP option
The extensibility of TCP depends largely on the definition of new TCP
options. As of this writing, 30 different TCP options have been
assigned by the IANA among the 256 possible values. Two of these
option types (253 and 254) have been reserved as experimental options
in [RFC4727]. However, this document did not specify how these
experimental options should be used. [RFC6994] clarified the
situation by proposing two encodings for these experimental options
to support a shared use of the same option kind by different
experimental options. Basically, [RFC6994] proposes to use a 16 bits
experiment identifier in the first two bytes of the option as shown
in the figure below.
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| option contents...
+--------+--------+---...
[RFC6994] extends this format to support 32 bits identifiers where
the second 16 bits word is used to encode a magic number.
0 1 2 3
01234567 89012345 67890123 45678901
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
| ExID (con't) | option contents...
+--------+--------+--------+---
Bonaventure, et al. Expires December 18, 2015 [Page 3]
Internet-Draft Exp. MPTCP Option June 2015
The experimental TCP options defined in [RFC6994] could in theory be
used over any TCP connection, including the subflows used by
Multipath TCP. However, using them as such to support experimental
features on a Multipath TCP connection would cause two practical
problems. The first problem is that the utilisation of such an
option should be negotiated during the three-way handshake by adding
the experimental option in the SYN and SYN+ACK segments. Given the
limited space for the options in these segments when Multipath TCP is
used and other options are already used, this is not a valid
approach. Second, middleboxes could accept the Multipath TCP option
and drop or modify an experimental TCP option that is used to support
an experimental Multipath TCP feature. This would increase the
complexity of the middlebox handling algorithms inside a Multipath
TCP implementation.
For the above two reasons, we propose the utilisation of an
Experimental Multipath TCP option that is encoded as shown in the
figure below.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+
| Kind | Length |Subtype| Flags | Experiment |
+---------------+---------------+-------+-------+---------------+
| Id. (16 bits) | Subtype-specific data (variable length) ...
+----------------------------------------------------------- ...
Flags is a set of 4 flags:
+-+-+-+-+
|S|U|r|r|
+-+-+-+-+
where "rr" are for future assignment as additional flag bits. r bits
MUST each be sent as zero and MUST be ignored on receipt.
The Experimental Multipath TCP option has a variable length. It is
always of kind=30 and Subtype=0xf. The Experiment identifier is a 16
bits integer that shall be assigned by using the same procedure as
defined in [RFC6994]. [RFC6994] also supports the utilisation of 32
bits Experiment Identifiers. These 32 bits identifiers are composed
of a 16 bits identifier assigned on a FCFS basis and a 16 bits magic
number. At this stage, we propose that the Experimental Multipath
TCP option uses only the 16 bits Experiment Identifier.
The two high order flags that are included in the Experimental
Multipath TCP option have the following semantics :
Bonaventure, et al. Expires December 18, 2015 [Page 4]
Internet-Draft Exp. MPTCP Option June 2015
o "S" flag (highest order bit) : This is the synchronising bit.
When set to 1, it indicates that the host sending this option
expects a reply from the remote host with an option having the
same experiment identifier, but possibly containing other data.
o "U" flag (second highest order bit) : When set to 1, this flag
indicates that the experimental option was received by the sending
host but it was unable to parse it.
The two low order flags are currently reserved for further use. They
MUST be set to zero when sending and ignored upon reception.
To use the Experimental Multipath TCP option with a given experiment
identifier over a Multipath TCP connection, the sending host must
first verify the ability of the remote host to support this
particular Experimental option. For this, it first sends in any
valid TCP segment, including a duplicate acknowledgement, an
Experimental Multipath TCP option with the "S" flag set. Upon
reception of this option, the receiving host will verify whether it
supports it. If yes, it shall return a TCP segment that contains the
experimental option with the same identifier and the "S" and the "U"
flags reset. This option may contain additional data depending on
its semantics. If the receiving host does not recognise the
experimental option that it has received, it shall return a TCP
segment that contains the received experimental option with the "S"
flag set to 0 and the "U" flag set to 1. Upon reception of this
option, the sending host knows that the experimental option cannot be
used over this Multipath TCP connection.
Once the utilisation of a specific Experimental Multipath TCP option
has been negotiated over a Multipath TCP connection, both hosts can
use this experimental Multipath TCP option. If a host receives an
Experimental Multipath TCP option with the "U" flag set to 0 that it
does not support or contains information that it cannot parse, it
shall return the exact option that it received with the "U" flag set
to indicate the error to the remote host. If an invalid option is
received with the "U" flag set to 0, it must be silently discarded.
Future documents specifying new experimental MPTCP options should
specify the extract semantic of the Subtype-specific data and whether
additional validation operations are to be followed at both sides.
Note, data can be included in an experimental data concurrently with
the capability check (S/U).
As a side effect of the use of a shared codepoint, an overhead of the
2 octets will be consumed in the option space for each experimental
MPTCP option. This overhead should be taken into account when
drawing conclusions related to the co-existence of multiple MPTCP
Bonaventure, et al. Expires December 18, 2015 [Page 5]
Internet-Draft Exp. MPTCP Option June 2015
experimental options or, even worse, between experimental MPTCP
options and experimental TCP options.
3. Security considerations
This document does not modify the security considerations for
Multipath TCP.
4. IANA considerations
This document proposes to modify the Multipath TCP option subtype 0xf
that was reserved for utilisation in private testbed to support the
Experimental Multipath TCP option.
The same considerations as for [RFC6994] apply. IANA should create a
"Multipath TCP Experimental Option Identifiers (MPTCP ExIDs)"
registry. This registry contains the 16 bits ExIDs and a reference
(description, document pointer, or assignee name and e-mail contact)
for each entry. MPTCP ExIDs are assigned on a First Come, First
Served (FCFS) [RFC5226].
IANA will advise applicants of duplicate entries to select an
alternate value, as per typical FCFS processing.
IANA will record known duplicate uses to assist the community in both
debugging assigned uses as well as correcting unauthorized duplicate
uses.
IANA should impose no requirement on making a registration other than
indicating the desired codepoint and providing a point of contact. A
short description or acronym for the use is desired but should not be
required.
5. Conclusion
This document has proposed a new experimental Multipath TCP option
that is intended to replace the already defined, but apparently
currently unused, Multipath TCP option reserved for private testbed.
This new Experimental Multipath TCP option will enable implementors
to perform experiments with Multipath TCP options without using the
limited Multipath TCP option subtypes.
6. Acknowledgements
This work was partially supported by the FP7-Trilogy2 project. This
document was heavily inspired by [RFC6994].
Bonaventure, et al. Expires December 18, 2015 [Page 6]
Internet-Draft Exp. MPTCP Option June 2015
7. References
7.1. Normative References
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013.
7.2. Informative References
[I-D.boucadair-mptcp-symmetric]
Boucadair, M. and C. Jacquenet, "An Extension to MPTCP for
Symmetrical Sub-Flow Management", draft-boucadair-mptcp-
symmetric-02 (work in progress), March 2015.
[I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", draft-ietf-mptcp-rfc6824bis-04 (work in
progress), March 2015.
[I-D.paasch-mptcp-syncookies]
Paasch, C., Biswas, A., and D. Haas, "Making Multipath TCP
robust for stateless webservers", draft-paasch-mptcp-
syncookies-00 (work in progress), April 2015.
[I-D.xu-mptcp-prmp]
Xu, C., Huang, H., Zhang, H., Xiong, C., and L. Zhu,
"Multipath Transmission Control Protocol (MPTCP) Partial
Reliability Extension", draft-xu-mptcp-prmp-00 (work in
progress), April 2015.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC
6994, August 2013.
Bonaventure, et al. Expires December 18, 2015 [Page 7]
Internet-Draft Exp. MPTCP Option June 2015
Authors' Addresses
Olivier Bonaventure
UCLouvain
Email: Olivier.Bonaventure@uclouvain.be
Benjamin Hesmans
UCLouvain
Email: Benjamin.Hesmans@uclouvain.be
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Bonaventure, et al. Expires December 18, 2015 [Page 8]
