[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



TCP Maintenance and Minor Extensions                        J. Kang, Ed.
Internet-Draft                                                  Q. Liang
Intended status: Informational                                    Huawei
Expires: 14 January 2021                                    13 July 2020


              Accurate Data Scheduling by Server in MPTCP
         draft-kang-tcpm-accurate-data-scheduling-by-server-00

Abstract

   This document defines a new mechanism that enables server to send
   request to client for data scheduling between the subflows during a
   MPTCP session.

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 14 January 2021.

Copyright Notice

   Copyright (c) 2020 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 the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.






Kang & Liang             Expires 14 January 2021                [Page 1]


Internet-Draft     Accurate Data Scheduling by Server          July 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Typical flows for accurate data scheduling by server  . . . .   3
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Traffic switching to a newly-added network interface  . .   5
     3.2.  Traffic switching to a network interface already in the
           session . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  MP_Navigation Option  . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Option Format . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   MPTCP protocol is now being deployed in more and more networks.  In
   most scenarios, MPTCP scheduling strategies for these subflows are
   implemented on client side considering RTT and congestion, or sending
   packets redundantly.  Application server cannot actively participate
   in such decision-making.

   However in real deployment, application server supports multiple
   network interfaces from different operators when MPTCP protocol is
   adopted.  There are such scenarios that the server wants to set
   scheduling to the client on these network interfaces based on server-
   side rules in a MPTCP session.  The requirements for these use cases
   are listed below:

   *  Network fault prevention.  Server tools can detect network quality
      of deployed network interfaces such as packet Loss, delay and
      jitter.  When the key performance indicators (KPI) become worse,
      the server hope to switch the traffic to a network interface with
      better KPI.

   *  Broadband entrances from different operators or the emergency
      entrance of 5G card are added.  This change is dynamic throughout
      the session and the operator hope to reduce the load on some
      subflows and lead them to the additional subflow, such as for
      test.  This is the trial operation scenario for new network.

   *  Value-added services.  Operator wants to provide customers with
      diversified services to satisfy individual demand.  For example,
      for VIP users, it should be possible to switch their traffic to
      network interface with better network KPIs.




Kang & Liang             Expires 14 January 2021                [Page 2]


Internet-Draft     Accurate Data Scheduling by Server          July 2020


   *  Another typical scenario is that operator hope to adjust traffic
      to a specific subflow for the changes in network cost, for
      example, the expiration of discounts.

   There are two related implementations.  RFC8684 defines REMOVE_ADDR
   Option to delete one address during a MPTCP session and it also
   closes all subflows bound to this address. draft-hoang-mptcp-sub-
   rate-limit-00 proposes a Subflow Rate Limit Option which can be used
   by sender to receiver for setting the rate of one subflow to zero.
   But for the use cases in this document, existing technologies are
   somewhat inadequate because they do not provide a clear indication of
   which subflow to switch to.

2.  Typical flows for accurate data scheduling by server

   This document proposes an accurate data scheduling mechanism for
   server.  Two typical flows are illustrated in Figure 1 and Figure 2.

          +--------+                            +--------+
          | Client |                            | Server |
          +--------+                            +--------+
              |                                      |
              |<----Session setup with subflows----->|
              |                                      |
              |                            Determine Address ID
              |                       for target network Interface
              |                                      |
              |<--Sending MP_Navigation for request--|
              |        on one ongoing subflow        |
              |                                      |
      Determine target subflow                       |
     by Address ID in MP_Navigation                  |
              |                                      |
      Traffic switching to                           |
      the target subflow                             |
              |                                      |
              |----Data transfer over the target---->|
              | subflow of target network interface  |
              |                                      |
              |                                      |

        Figure 1: Server request client to perform traffic switching









Kang & Liang             Expires 14 January 2021                [Page 3]


Internet-Draft     Accurate Data Scheduling by Server          July 2020


          +--------+                            +--------+
          | Client |                            | Server |
          +--------+                            +--------+
              |                                      |
              |<---Subflow with diverted traffic --->|
              |       is still kept alive            |
              |                                      |
              |                         Determine to cancel MP_Navigation
              |                            for target network Interface
              |                                      |
              |<----Sending MP_Navigation on the-----|
              |    subflow with diverted traffic     |
              |          for cancellation            |
              |                                      |
   Cancel traffic switching to                       |
    target network interface                         |
      on the MP_Navigation                           |
              |                                      |
              |-----Continue data transfer over----->|
              |   the subflow with diverted traffic  |
              |                                      |
              |                                      |

       Figure 2: Server sends a request to client to cancel previous
                             navigation setting

   For the use case of adding a new network interface to MPTCP session
   for navigation, normal process of ADD_ADDR should be executed before
   traffic switching.

   If it is determined to cancel the data switching on the subflow, the
   client should delete the navigation information.  The navigation
   information is generated by the client and is used to determine the
   target subflow for data switching based on the address ID of the
   target network interface.

   After data switching, if the subflow with diverted traffic is
   disconnected, the client should delete the navigation information and
   configuration information for it.  The navigation information is
   generated by the client and is used to determine the target subflow
   for data switching based on the address ID of the target network
   interface.

3.  Examples







Kang & Liang             Expires 14 January 2021                [Page 4]


Internet-Draft     Accurate Data Scheduling by Server          July 2020


3.1.  Traffic switching to a newly-added network interface

   Four subflows have been established between client and server that
   are <IP1, IP3>, <IP2, IP3>, <IP1, IP4> and <IP2, IP4>.  On the
   client, IP1 and IP2 are the address IDs for WiFi and a cellular
   network.  On the server, IP3 and IP4 are the address IDs for Ethernet
   and WiFi.  When a new 5G network is deployed on the server, the
   server can switch the data traffic on the subflow <IP2,IP4> to the
   destination IP5 corresponding to 5G.  In this case, the target
   network interface is IP5.

3.2.  Traffic switching to a network interface already in the session

   Four subflows have been established between client and server that
   are <IP1, IP3>, <IP2, IP3>, <IP1, IP4> and <IP2, IP4>.  On the
   client, IP1 and IP2 are the address IDs for WiFi and a cellular
   network.  On the server, IP3 and IP4 are the address IDs for Ethernet
   and WiFi.  Server tool detects that KPI for IP4 is better now so the
   server can switch data traffic on the subflow <IP1, IP3> to the
   destination IP4.

4.  MP_Navigation Option

   In this solution, a MP_Navigation option is defined and sent from
   server to forces client to switch traffic from the subflow over which
   the option was received to a target subflow or to cancel the traffic
   switching when it is not required, which is indicated by a flag 'R'.
   If it is set, the target subflow is determined through the Address ID
   of the target network interface in MP_Navigation option.

   This MP_Navigation Option can be sent in ACK.

   It is noted that if this option is not supported by the client, it
   should be omitted.

4.1.  Option Format

   The format of the MP_Navigation option is depicted in Figure 3:

                        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|r|R|E|B|   Address ID  |
     +---------------+---------------+-------+-------+---------------+

                       Figure 3: MP_Navigation Option





Kang & Liang             Expires 14 January 2021                [Page 5]


Internet-Draft     Accurate Data Scheduling by Server          July 2020


   Subtype: A new subtype should be allocated to indicate MP_Navigation
   Option.

   Address ID: Address ID in MP_Navigation Option is used to identify
   the address ID of target network Interface.

   The flag 'R', when set, define the content of this option, as
   follows:

   *  When value of 'R' is set to zero, server want to use this option
      to inform client of navigation policy and the client will perform
      traffic switching as requested by the server.  When value of 'R'
      is set to 1, the server requests to cancel current navigation
      policy in client and the client will delete corresponding
      navigation information to the Address ID.

   When the client receives the MP_Navigation Option, it will determine
   the target network interface by the Address ID.  Address ID may map
   to one or more ongoing subflows and the client will select one for
   each data transfer by its local strategies.

5.  IANA Considerations

   IANA is requested to assign a MPTCP option subtype for the
   MP_Navigation option.

6.  Security Considerations

   Since MP_Navigation Option is neither encrypted nor authenticated,
   on-path attackers and middleboxes could remove, add or modify the
   MP_Navigation Option on observed Multipath TCP connections.

7.  References

7.1.  Normative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <https://www.rfc-editor.org/info/rfc793>.

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







Kang & Liang             Expires 14 January 2021                [Page 6]


Internet-Draft     Accurate Data Scheduling by Server          July 2020


   [RFC8684]  Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
              2020, <https://www.rfc-editor.org/info/rfc8684>.

Authors' Addresses

   Jiao Kang (editor)
   Huawei
   D2-03,Huawei Industrial Base
   Shenzhen
   China

   Phone: +86 18520828326
   Email: kangjiao@huawei.com


   Qiandeng Liang
   Huawei
   No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
   Wuhan
   China

   Phone: +86 18651640216
   Email: liangqiandeng@huawei.com


























Kang & Liang             Expires 14 January 2021                [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/