Negotiating the Maximum Number of Multipath TCP (MPTCP) Subflows

This document specifies a Multipath TCP (MPTCP) option that is meant to indicate to a remote peer the maximum number of subflows that can be established within a single MPTCP connection. If the remote peer honors the indication provided in this option, any performance degradation induced by a possibly abusive setup of additional subflows that exceed the said maximum becomes unlikely. This option mainly targets MPTCP deployments within a single administrative domain such as those MPTCP designs meant to achieve load-balancing, for example. The use of this option contributes to the harmonization of node configuration within an administrative domain, so that an optimal number of subflows is maintained by involved nodes independently of their actual performance capabilities. This option can be used in other deployment scenarios. It is out of scope of this document to identify what are such scenarios. Section 3.4 of includes a discussion on the MPTCP session manager issues.

Experiments based upon the MPTCP option described in this document are meant to help operators optimize their MPTCP design and operational procedures, by tweaking some MPTCP parameters such as the number of subflows to be associated with a given MPTCP connection. Experimenting with this MPTCP option should also help assess whether this option can be used to propagate MPTCP-related optimization parameters (derived from the number of concurrent subflows associated to each MPTCP connection) that can be configured in a node that is responsible for aggregating MPTCP connections established with upstream nodes.

The MP_MAXSUBFLOW option () follows the shared experimental format defined in .

The meaning of "Kind", "Length", "Subtype", and "Flags" (especially 'S' and 'U' flags) are exactly the same as defined in Section 3.7 of . Experiment ID MUST be set to 0xAA (see ). The "Maximum Subflows" field indicates the maximum number of concurrent subflows that can be maintained by a given MPTCP endpoint for each MPTCP connection established by or with this endpoint. The value of this field MUST be strictly greater than zero.

The MP_MAXSUBFLOW option may be used by a TCP endpoint to indicate to its corresponding peer the maximum number of subflows that it can maintain per MPTCP connection. How an MPTCP endpoint determines the maximum number of concurrent subflows it supports (i.e., the value it indicates in an MP_MAXSUBFLOW option) is implementation-specific. For example, an implementation may support a configuration parameter and/or use a default value. If two peers (T1 and T2) indicate the maximum number of concurrent subflows per connection they can maintain, then they MUST NOT maintain more than "MIN(MAX_SUBFLOW(T1), MAX_SUBFLOW(T2))" concurrent subflows. The absence of the MP_MAXSUBFLOW option in an MPTCP control message issued by a MPTCP endpoint is an indication that this endpoint can instantiate any number of subflows per MPTCP connection.

MPTCP-related security considerations are documented in and . Establishing a large number of subflows may exhaust the resources of an MPTCP implementation (especially, MPTCP servers). MPTCP implementations SHOULD rate-limit the number of concurrent subflows per MPTCP connection. This policy is meant to prevent DoS attacks that would result in creating additional subflows to exhaust the remote peer resources (typically, an MPTCP server).

This document uses the experiment Id (0xAA). This Id is not registered yet given that no registry is maintained by IANA for this purpose.