[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
TCP Maintenance and Minor Extensions J. Kang, Ed.
Internet-Draft Q. Liang
Intended status: Informational Huawei
Expires: 6 May 2021 2 November 2020
Accurate Data Scheduling by Server in MPTCP
draft-kang-tcpm-accurate-data-scheduling-by-server-01
Abstract
This document defines a new mechanism that enables MPTCP server to
send request to MPTCP client for data scheduling between specified
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 6 May 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 6 May 2021 [Page 1]
Internet-Draft Accurate Data Scheduling by Server November 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Typical flows for accurate data scheduling by server . . . . 3
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . 6
4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 6
5. Data Scheduling on client when receiving MP_Navigation . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
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 considering RTT and congestion, or sending
packets redundantly. MPTCP server cannot participate in such
decision-making.
However, in actual deployment, MPTCP server is configured with
multiple network interfaces from different operators. There are some
scenarios that MPTCP server wants to set scheduling on these network
interfaces to MPTCP client based on its own rules, network planning
and operating policies during a MPTCP session. Requirements for
these use cases are listed below:
* Network fault prevention. Server tools can help detect quality of
deployed network interfaces such as packet loss, delay and jitter.
If key performance indicators (KPI) of one network interface
becomes worse, MPTCP server hopes to indicate MPTCP client to
switch the traffic into another network interface with better KPI.
Kang & Liang Expires 6 May 2021 [Page 2]
Internet-Draft Accurate Data Scheduling by Server November 2020
* A new entrance is deployed or an emergency entrance of 5G card is
added during a MPTCP session. In this case, MPTCP server may hope
to lead the traffic on some subflows to the additional network
interface. One purpose is to test new network in trial operation.
Other purposes include avoiding congestion and improving
transmission reliability on existing networks. For example, MPTCP
server is using network of Operator A for data transmission and a
network of operator B is added when data traffic increases. At
this time, MPTCP server wants to arrange traffic from network of
Operator A to Operator B. In this case, network of Operator B is
the target network.
* Value-added services. This requirement comes from the operating
policies. MPTCP server is required to help provide customers with
diversified services in order to satisfy individual demand. For
example,it should be possible that MPTCP server indicates MPTCP
client to switch the traffic of VIP users to a network interface
with better KPIs.
* Another typical scenario is that MPTCP server hopes to adjust
traffic to a specific subflow because of the changes in network
cost, for example, the expiration of discounts. This requirement
also comes from the operating policies.
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.
Kang & Liang Expires 6 May 2021 [Page 3]
Internet-Draft Accurate Data Scheduling by Server November 2020
+--------+ +--------+
| 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 |
| |
| |
Kang & Liang Expires 6 May 2021 [Page 4]
Internet-Draft Accurate Data Scheduling by Server November 2020
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.
Kang & Liang Expires 6 May 2021 [Page 5]
Internet-Draft Accurate Data Scheduling by Server November 2020
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.
Flag 'r': reserved for future usage.
Flag 'R': when set, defines 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.
Flag 'E': exists to provide reliability for this option (like that in
"ADD_ADDR").
Flag 'B': indicates whether the subflow over which the option is
received is a backup one (that is compatiable with the value by
MP_PRIO).
Kang & Liang Expires 6 May 2021 [Page 6]
Internet-Draft Accurate Data Scheduling by Server November 2020
Address ID: Address ID in MP_Navigation Option is used to identify
the address ID of target network Interface.
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. Data Scheduling on client when receiving MP_Navigation
This section will be finished later.
6. IANA Considerations
IANA is requested to assign a MPTCP option subtype for the
MP_Navigation option.
7. 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.
8. References
8.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>.
[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
Kang & Liang Expires 6 May 2021 [Page 7]
Internet-Draft Accurate Data Scheduling by Server November 2020
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 6 May 2021 [Page 8]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/