Internet-Draft Accurate Data Scheduling by Server July 2020
Kang & Liang Expires 14 January 2021 [Page]
Workgroup:
TCP Maintenance and Minor Extensions
Internet-Draft:
draft-kang-tcpm-accurate-data-scheduling-by-server-00
Published:
Intended Status:
Informational
Expires:
Authors:
J. Kang, Ed.
Huawei
Q. Liang
Huawei

Accurate Data Scheduling by Server in MPTCP

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.

Table of Contents

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:

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
       +--------+                            +--------+
       | 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

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

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 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, , <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, , <https://www.rfc-editor.org/info/rfc6824>.
[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, , <https://www.rfc-editor.org/info/rfc8684>.

Authors' Addresses

Jiao Kang (editor)
Huawei
D2-03,Huawei Industrial Base
Shenzhen
China
Qiandeng Liang
Huawei
No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone
Wuhan
China