Accurate Data Scheduling by Server in MPTCPHuaweiD2-03,Huawei Industrial BaseShenzhenChinakangjiao@huawei.comHuaweiNo. 207, Jiufeng 3rd Road, East Lake High-tech Development ZoneWuhanChinaliangqiandeng@huawei.com
Transport Area
TCP Maintenance and Minor ExtensionsmptcpThis document defines a new mechanism that enables MPTCP server to send requests to MPTCP client for data scheduling between specified subflows during a MPTCP session.IntroductionMPTCP protocol is being deployed in various networks. In most scenarios, MPTCP scheduling strategies for subflows are implemented on client considering RTT and congestion, or sending packets redundantly. MPTCP server does not participate in such decision-making.However, in actual deployment, MPTCP server is configured with multiple network interfaces and these network interfaces are from different operators. There are some scenarios in which MPTCP server wants to set scheduling algorithms on these network interfaces based on its own rules, network planning and operating policies. These scheduling algorithms need to be passed to the MPTCP client and executed on the client during a MPTCP session. Requirements for these use cases are described below:
Network fault prevention. Server tools can help detect quality of each deployed network interfaces including packet loss, delay and jitter. If key performance indicators (KPI) of one network interface becomes worse, MPTCP server hopes to instruct MPTCP client to switch the traffic into another network interface with better KPI.
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 existing traffic to this newly added network interface. One purpose is to test this 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 part of traffic of Operator A to Operator B. In this case, the network of Operator B is the target network.
Value-added services. This requirement comes from operating policies of operators. MPTCP server is required to help provide its customers with diversified services in order to satisfy individual demand. For example,it should be possible that MPTCP server can indicate MPTCP client to switch VIP users' traffic 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 of operators.
Currently, there are two implementations related to these requirements. defines REMOVE_ADDR Option to delete one address during a MPTCP session but it will close 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. 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.Typical flows for accurate data scheduling by serverAn accurate data scheduling mechanism for MPTCP server is proposed in this document. Two typical flows are illustrated in Figure 1 and Figure 2.For the use case of adding a new network interface to a MPTCP session for data shceduling, normal process of ADD_ADDR should be executed before traffic switching.If it is determined to cancel the data switching on a subflow, the client should delete the navigation information for it. Navigation information is generated by MPTCP 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 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. ExamplesTraffic switching to a newly-added network interfaceFour 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.Traffic switching to a network interface already in the sessionFour 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.MP_Navigation OptionMP_Navigation option is defined and sent from server to force client to switch traffic from the subflow over which the option was received to a target subflow, or to cancel traffic switching when it is not required. MP_Navigation option includes a Flag ‘R’ to distinguish this two functions. If it is set, the target subflow is determined through the Address ID of the target network interface in MP_Navigation option. MP_Navigation option can be sent in ACK.Noted that if MP_Navigation option is not supported by the MPTCP client, it should be omitted when received.Option FormatThe format of the MP_Navigation option is depicted in Figure 3: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, it means that the server wants to use this option to inform client of data scheduling 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 data scheduling policy on client and the client will delete corresponding navigation information to this 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).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 data transfer by its local strategies.Data scheduling on client when receiving MP_NavigationThis section will be finished later.IANA ConsiderationsIANA is requested to assign a MPTCP option subtype for the MP_Navigation option.Security ConsiderationsSince 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.ReferencesNormative ReferencesTCP Extensions for Multipath Operation with Multiple AddressesTCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and thus improve user experience through higher throughput and improved resilience to network failure.Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., a reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths.This document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC 6824, through clarifications and modifications primarily driven by deployment experience.