Problem Statement of MPTCP Transmission Feature Negotiation
draft-nagesh-mptcp-feature-negotiation-ps-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Nagesh Shamnur , Zhen Cao | ||
| Last updated | 2019-11-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-nagesh-mptcp-feature-negotiation-ps-00
MPTCP N. Shamnur
Internet-Draft Z. Cao
Intended status: Informational Huawei
Expires: May 6, 2020 November 3, 2019
Problem Statement of MPTCP Transmission Feature Negotiation
draft-nagesh-mptcp-feature-negotiation-ps-00
Abstract
Path manager and packet scheduler are two important components of
MPTCP protocol and associated implementations. Normally they are
implemented and configured statically. This draft discusses the
scenarios where statically configured path manager and packet
scheduler are not sufficient, and presents the cases that deserve the
negotiation of these multipath transmission features which are
currently not addressed by MTPCP.
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 https://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 May 6, 2020.
Copyright Notice
Copyright (c) 2019 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
(https://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
Shamnur & Cao Expires May 6, 2020 [Page 1]
Internet-Draft MPTCP feature negotiation ps November 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language and Terminology . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Current multipath transmission strategies . . . . . . . . 3
2.2. Current practice to overcome this limitation . . . . . . 4
2.3. Problems with current method of tranmission strategies
configuration . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Deployment scenario . . . . . . . . . . . . . . . . . . . 5
2.4.1. Scheduler deployment scenario . . . . . . . . . . . . 5
2.4.2. Path Manager deployment scenario . . . . . . . . . . 6
3. Requirements for multipath transmission negotiation
strategies . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Req#1: Flexiblity at each endpoint to implement
propreitary algorithms . . . . . . . . . . . . . . . . . 7
3.2. Req#2: Flexiblity to be configured based on deployment
network . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Req#3: Flexiblity to be configured based on application
used . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
MPTCP [RFC6824] [I-D.ietf-mptcp-rfc6824bis] 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
Shamnur & Cao Expires May 6, 2020 [Page 2]
Internet-Draft MPTCP feature negotiation ps November 2019
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 [RFC6824] 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 [RFC6824] 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.
1.1. Requirements Language and Terminology
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 [RFC2119].
This document also uses terminology described in [RFC6824].
2. Rationale
2.1. Current multipath transmission strategies
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.
Shamnur & Cao Expires May 6, 2020 [Page 3]
Internet-Draft MPTCP feature negotiation ps November 2019
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 [RFC6824] 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.
2.2. Current practice to overcome this limitation
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 [RFC3168]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 [minutes]. (it throttles the cwnd
size when the flow really needs it)
2.3. Problems with current method of tranmission strategies
configuration
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
Shamnur & Cao Expires May 6, 2020 [Page 4]
Internet-Draft MPTCP feature negotiation ps November 2019
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.
2.4. Deployment scenario
2.4.1. Scheduler deployment scenario
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.
Shamnur & Cao Expires May 6, 2020 [Page 5]
Internet-Draft MPTCP feature negotiation ps November 2019
(((......)))
((( )))
((( )))
((( )))
((( Cloud )))
((( Platform )))
((( )))
((( )))
((( )))
(((......)))
^ |v |
> > > > > > > > |v |
^ |v |
^ +--------------+v +--------------+
^ | v |
^ | < < < < < < < |
^ | v |
^ | v |
^ | v |
+---------+ +---------+
| 802.11 | | LTE |
+---------+ +---------+
Figure 1: Scheduler Deployment scenario
2.4.2. Path Manager deployment scenario
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 [mptcpd], which is quite align with the
scenario we have described. This will bring the path-manager
negotiation goal closer to reality.
Shamnur & Cao Expires May 6, 2020 [Page 6]
Internet-Draft MPTCP feature negotiation ps November 2019
+-----------+ +-----------+
| |+------+ +------+| |
| ||802.11| - - - - - - - - |802.11|| |
| |+------+ \ / +------+| |
| | \ / | |
| Client | x | Server |
| | / \ | |
| |+------+ / \ +------+| |
| || LTE | - - - - - - - - | LTE || |
| |+------+ +------+| |
+-----------+ +-----------+
Figure 2: Path Manager Deployment scenario
3. Requirements for multipath transmission negotiation strategies
3.1. Req#1: Flexiblity at each endpoint to implement propreitary
algorithms
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.
3.2. Req#2: Flexiblity to be configured based on deployment network
As mentioned in the earlier section Section 2.1 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.
3.3. Req#3: Flexiblity to be configured based on application used
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.
Shamnur & Cao Expires May 6, 2020 [Page 7]
Internet-Draft MPTCP feature negotiation ps November 2019
4. IANA Considerations
This specification contains no IANA considerations.
5. Security Considerations
TBD.
6. Normative References
[I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", draft-ietf-mptcp-rfc6824bis-18 (work
in progress), June 2019.
[minutes] 104, I., "https://tools.ietf.org/wg/mptcp/
minutes?item=minutes-104-mptcp-00.html", August 2019.
[mptcpd] mptcpd, "The Multipath TCP Daemon,
https://github.com/intel/mptcpd/", August 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<https://www.rfc-editor.org/info/rfc6824>.
Authors' Addresses
Nagesh Shamnur
Huawei
Kundalahalli Village, Whitefield,
Bangalore, Karnataka 560037
India
Phone: +91-080-49160700
Email: nagesh.shamnur@gmail.com
Shamnur & Cao Expires May 6, 2020 [Page 8]
Internet-Draft MPTCP feature negotiation ps November 2019
Zhen Cao
Huawei
Xinxi No.3
Beijing 100085
China
Email: zhencao.ietf@gmail.com
Shamnur & Cao Expires May 6, 2020 [Page 9]