Problem Statement of MPTCP Transmission Feature Negotiation

MPTCP specifies the procedure of establishing multiple subflows to a connection and it also explains the procedures for path management. There are various types of path manager that can be configured. The selection of a particular path manager algorithm is however decided based on the deployment scenario and hence multiple options for the same are available. Each end of the MPTCP connection needs to configure a path manager algorithm that would be used for a particular connection in isolation and would thus wouldn't know the path manager chosen on the remote side. In certain cases, a combination of different types of configuration would be required to suit a particular deployment scenario. This limitiation is also true in the case of the scheduler as well. Since for every connection server based on its local policies selects a particular scheduler and the client would select its own based on it's own local policies for data transmission to a remote endpoint. A particular scheduler type thus selected at the server would suit a connection to a particular client but the same might not be optimal in case of another client. This intelligence will have to be provisioned at the server using offline methods and server would not be updated in time about any changes that happen on the client-side and so limits server from switching to the optimal scheduler to attain the best possible network bandwidth usage. MPTCP does not standardises the rules for selection of either of path manager or scheduler that needs to be configured at each endpoint of the MPTCP connection and leaves it to implementors` choice. Many factors influence the choice of path manager and scheduler method that needs to be applied on each side. Linux Kernel implements 4 different path managers - default, full-mesh, ndiffports and binder. It also implements 3 different schedulers - default (minRTT), round-robin and redundant. In reality, though not adopted by the current open source MPTCP, tens of schedulers are implemented, experimented and adapted by various people and institutions based on the deployment scenarios. This document explains the set of problem associated with the current MTPCP with respect to rules for choosing and selecting the path manager and scheduler that needs to be configured and the problem it creates due to the absence of synchronisation mechanism which hinders the subflows from achieving the best results for path aggregation, optimal bandwidth utilization and reap the benefits of switching to MPTCP from TCP. This document also discusses and emphasizes the needs for a procedure to exchange the capabilities during the connection establishment as well as during the lifetime of the connection.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. This document also uses terminology described in .

Before establishing an MPTCP connection between the desiring peers, at each end of the connection endpoint, a choice of scheduler and path manager needs to be made based on the deployment strategy and the quality of the heterogeneous link(s) on which connection gets established. Once selected, the same needs to be statically provisioned and the connection establishment procedure follows. Both Scheduler and Path Manager are features which are not standardized by IETF and is implementation-dependent. Various factors including deployment scenario influence the choice of scheduler/path manager that would be applied for every connection. One size fits all approach hence cannot be applied. Either of Client or Server can choose any of the publicly available standards implementation or can have its own implementation of a scheduler and path manager. At the same time, it can also expect the far endpoint of the connection to configure the scheduler and path manager to be configured in a certain way so as to achieve the desired result for both upstream and downstream data. MPTCP doesn't explains how the schedulers/path managers are configured on each side of the connection and how it would be synchronized at the time of connection setup. Absence of such a mechanism forces endpoints to negotiate them offline and also it would not be easy to change it in the deployed systems. This in turn inhibits MPTCP to deploy application and preference aware schedulers and path managers. Moreover, it would not permit to change the schedulers and path managers that are configured at each endpoint and synchronize them between client and servers, if the network conditions change.

Schedulers and Path Managers are statically provisioned at each end of the endpoint and in a specific way. Client and server configure Schedulers/path managers in isolation and may or may not be synchronized with each other. For synchronization out of band, method can be used which would not be discussed as a part of this document. Path aggregation results might vary in each direction of the connection due to this difference in configuration between server and client. ECN can help acheive the goal of scheduler to a fair extent by setting the CE mark. However, this solution has some limitations per a brief discussion at IETF104 . (it throttles the cwnd size when the flow really needs it)

Both server and client needs to negotiate the capabilities that will be configured on each side offline and cannot be discovered dynamically when the connection is initiated by the client. A wrong configuration decision can have a substantial impact on protocol performance. A wrong decision may render the advantage of additional paths useless or even reduce the overall performance by introducing issues like head-of-line blocking. Clients having proprietary implementation cannot expect to have the desired result for both upstream and downstream data without setting the configuration on the far end of the connection. Also, it might not be viable to patch or provision a new scheduler and/or path manager on server-side for every new client that connects to it might have already been deployed. A server cannot configure differentiated schedulers/path managers based on a different client that connects to it.

In one typical deployment scenario, the mptcp is used between a smartphone and a cloud server. There are two subflows in the connnection, one over the 802.11 path, and the other one via the cellular path. The application running on top of mptcp would like to optimize its performance in terms of latency and throughput. However, the smartphone user would like to use the toll-free 802.11 link as much as possible, and only overflow to cellular link when necessary. For the upstream traffic, the smartphone can control the user expectation based on its own scheduler. However the server does not know which path is preferred and which one is not, since the path characteristics have not been informed to the server. In this sense, the mptcp scheduler on the server is not able to schedule the packet according to the service requirement.

> > > > > > > |v | ^ |v | ^ +--------------+v +--------------+ ^ | v | ^ | < < < < < < < | ^ | v | ^ | v | ^ | v | +---------+ +---------+ | 802.11 | | LTE | +---------+ +---------+ ]]>

A bit different to the previous scenario, the smartphone is connected to the server over a mptcp connection via a 802.11 path and a cellular link. However the server also has two IP addresses from two ISPs. Ideally, the client path manager needs to avoid the creation of sub-flow on the cross path since cross paths are deemed to be less efficient in terms of bandwidth availability and latency. This scheme needs to be realized by setting the path manager on the client-side to proprietary and default mode on the server-side, so that only the client initiates the sub-flow creation and avoids creating cross-path sub-flows to server. This, however, can only be cooridinated manually in the current mptcp design. Most recently, the mptcp upstream project has put the user space path manager into the roadmap , which is quite align with the scenario we have described. This will bring the path-manager negotiation goal closer to reality.

Each endpoint of the connection should be equipped to implement proprietary implementation of scheduler and path manager. The same also should be allowed to be commissioned dynamically and can be synchronized with the peer endpoint on a per-connection basis. This would increase the flexibility to deploy MPTCP under various heterogeneous network conditions without the need to recompile the kernel/implementation.

As mentioned in the earlier section there is no universal method which satisfies all the various heterogeneous networks in which MPTCP gets deployed and so different network scenario demands different implementation for scheduler and path manager. At the server, a system need to support commissioning of different methods for schedulers and path managers based on the client which connects to it.

Multipath TCP scheduling and path manager is configured in isolation and application bear no impact on the choice of scheduler and path manager that gets configured in the MPTCP layer. Different applications will demand different selection of these capabilities and thus the monolithic configuration of the same severely restricts the advantages of deploying MPTCP. Application-aware selection of these methods would thus push MPTCP beyond throughput optimization and thus can be deployed in a wide range of applications.

This specification contains no IANA considerations.

TBD.