Problem Statement of MPTCP Transmission Feature Negotiation
draft-nagesh-mptcp-feature-negotiation-ps-01

Document Type Active Internet-Draft (individual)
Last updated 2019-11-04
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
MPTCP                                                         N. Shamnur
Internet-Draft                                                    Z. Cao
Intended status: Informational                                    Huawei
Expires: May 7, 2020                                    November 4, 2019

      Problem Statement of MPTCP Transmission Feature Negotiation
              draft-nagesh-mptcp-feature-negotiation-ps-01

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 MPTCP.

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 7, 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 7, 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 7, 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 7, 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 7, 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 7, 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 7, 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 7, 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 7, 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 7, 2020                  [Page 9]