Internet DRAFT - draft-zuo-mptcp-scheduler
draft-zuo-mptcp-scheduler
MPTCP J. Zuo
Internet Draft J. Zhu
Intended status: Informational W. Liu
Expires: September 22, 2018 Huawei
March 21, 2018
A Path-Aware Scheduling Scheme for Multipath Transport Protocols
draft-zuo-mptcp-scheduler-01.txt
Abstract
Scheduling schemes play a key role in the performance of multipath
transport protocols. A path-aware scheduling scheme for latency-
sensitive applications is proposed, which always schedules data in
the path with the lowest One-Way Latency (OWL). The OWLs of all paths
are obtained by employing the redundant transmission periodically.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of
J. Zuo, et al Expires September 22, 2018 [Page 1]
INTERNET-DRAFT MPTCP Scheduler March 21, 2018
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Acronyms and Terminology . . . . . . . . . . . . . . . . . . . 3
3. A New Path-Aware Scheduling Scheme . . . . . . . . . . . . . . 3
3.1 The definition of OWL . . . . . . . . . . . . . . . . . . . 3
3.2. The Operations of the Path-Aware Scheduling Scheme . . . . 4
3.2.1. Initialization . . . . . . . . . . . . . . . . . . . . 4
3.2.2. Data scheduling . . . . . . . . . . . . . . . . . . . . 4
3.2.3. Periodically Redundant Transmission . . . . . . . . . . 4
4. Implementation Considerations . . . . . . . . . . . . . . . . . 5
4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Negotiation . . . . . . . . . . . . . . . . . . . . . . . . 6
4.3 The Steps for OWL Calculation . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
For latency-sensitive applications, such as games, latency is the
primary goal to make the interactive data exchanged in time. A
suitable scheduling scheme will influence the latency performance of
multipath transport protocols [RFC6824], since the packets with
consecutive sequence numbers may arrive at the receiver out of order
due to the different RTTs of multiple paths. Lots of scheduling
schemes are proposed to select the path with the lowest latency to
send data. RTT is commonly used as the condition for scheduling.
However, it's found that the delays of the forward path and the
reverse path are usually different in many cases, such as the
asymmetric uplink delay and the downlink delay in wireless
environment. Especially, the congestion may not happen in the forward
path and the reverse path at the same time, resulting in the
different queue delays. Therefore, scheduling data on the path with
the lowest RTT cannot guarantee the lowest interactive latency
required by the latency-sensitive applications.
A new path-aware scheduling scheme for multiple transport protocols
J. Zuo, et al Expires September 22, 2018 [Page 2]
INTERNET-DRAFT MPTCP Scheduler March 21, 2018
is proposed, which considers the One-Way Latency (OWL) as a
scheduling condition. The data will be always sent in the path with
the lowest OWL.
It is intended that the scheduling scheme presented in this draft can
be applied to other multipath transport protocols, such as
alternative multipath extensions to TCP [RFC793], UDP, QUIC, or
indeed any other multipath protocols. However, for the purposes of
example, this document will, where appropriate, refer to the MPTCP
[RFC6182].
2. Acronyms 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].
3. A New Path-Aware Scheduling Scheme
A new path-aware scheduling scheme is proposed to always send data in
the path with the lowest OWL.
3.1 The definition of OWL
OWL is defined as the latency of a data successfully delivered from
the sender to the receiver, which is calculated as
OWL (i) = T_recv (i) - T_send (i),
where i means the i-th path, T_recv is the time when the data arrives
at the receiver and T_send is the time when the data is sent from the
sender.
Compared to the One-Way Delay (OWD) defined in [RFC7679], OWL can be
deemed as
OWL (i) = OWD (i) + dT,
where dT means the time difference caused by the absolute clock time
at the sender and the receiver. When the scheduler tries to select
the path with the lowest latency to send data, it will compare the
latencies of multiple paths. Take two paths for example,
dOWL = OWL (1) - OWL (2),
where dOWL indicates the OWL difference of path 1 and path 2. If dOWL
> 0, the path 2 is selected or else the path 1 is selected. We could
see that dT will not influence the value of dOWL, since it will be
J. Zuo, et al Expires September 22, 2018 [Page 3]
INTERNET-DRAFT MPTCP Scheduler March 21, 2018
subtracted when path 1 and path 2 are connected between the same
sender and the same receiver. Hence, OWL is more suitable than OWD as
the scheduling condition in multipath environment, since it does not
need to consider the issue of time synchronization.
3.2. The Operations of the Path-Aware Scheduling Scheme
3.2.1. Initialization
As in RFC6824, MPTCP first sets up the connection in the primary path
and then subsequentially sets up the connections of other paths.
After the handshake stage of the primary path, data is immediately
sent in this path. Then when the connection of the second path is
built up, the OWLs of these two paths could be obtained. The
following data could be scheduled in the path with the lowest OWL.
However, network is unstable at the moment, the value of the obtained
OWL may change in the next round of data transmission, especially
when there are other flows co-existed or packet loss is very high.
For avoiding the frequent switching amongst the multiple paths due to
the variant instant OWLs, the data are scheduled redundantly in the
multiple paths for a period of time [CONEXT17]. The redundant
scheduling means the same data are sent in all paths concurrently
[MPTCP.org]. A Smoothed OWL (SOWL) is defined as the effective OWL of
a path, as referred to the smoothed RTT, which is defined in
[RFC793]:
SOWL = ( ALPHA * SOWL ) + ((1-ALPHA) * OWL).
Alternatively, other methods which could calculate the effective OWL
during the period of time can be considered. The period of time could
be set to a fixed number, e.g. 1s, or max{200ms, SRTT}.
3.2.2. Data scheduling
After the effective OWLs of all paths are obtained, the sender will
schedule the following data from application to the path with the
lowest OWL.
3.2.3. Periodically Redundant Transmission
Once the path with the lowest OWL is selected to send the data
henceforth, and no data will be scheduled to the other paths. The
result is that there is no chance to know the future OWLs of the
other paths. For making the scheduling more responsive to the variant
network environment and always sending data in the path with the
lowest OWL, sending probe packets in other paths may be one of the
potential solutions. However, it introduces extra packets which
J. Zuo, et al Expires September 22, 2018 [Page 4]
INTERNET-DRAFT MPTCP Scheduler March 21, 2018
consume extra bandwidth of the path. Therefore, the periodically
redundant transmission is proposed, which sends data redundantly for
obtaining the effective OWLs of all paths every a certain period of
time (e.g. 10s). Figure 1 shows the process of the periodically
redundant transmission.
1s 10s 1s 10s
| | transmission in | | transmission in |
|-redundant -|-the path with -|-redundant -|-the path with -|-...
| transmission| the lowest OWL | transmission| the lowest OWL |
Figure 1: Periodically redundant transmission.
On the one hand, the periodically redundant transmission could obtain
the OWLs of all paths at the same time without introducing extra
packets; on the other hand, the same data are transmitted
concurrently in all the paths, which could guarantee the lowest
delivering time as long as the data arrives at the receiver no matter
in which path it is sent.
Once the OWLs of all paths are updated, the following data are
scheduled as described in Section 3.2.2. During the data transmission
in the path with the lowest OWL, the OWL of the selected path is
continually updated. Once the updated OWL has increased so much that
it may not the lowest OWL any more, the redundant transmission is
immediately activated to obtain the updated OWLs of all paths, as
shown in Figure 2.
1s 10s 1s 10s
| | transmission in | | transmission in |
|-redundant -|-the path with -|-redundant -|-the path with -|-...
| transmission| the lowest OWL | transmission| the lowest OWL |
| |
| |
the OWL of the |
selected path is not |
the lowest any more |
|_______________|
Figure 2: Redundant transmission activated
when the OWL of the selected path is not the lowest any more.
4. Implementation Considerations
4.1 Packet Format
As described in Section 3.1, the calculation of the OWL requires the
time when the data is sent from the sender and the time when the data
J. Zuo, et al Expires September 22, 2018 [Page 5]
INTERNET-DRAFT MPTCP Scheduler March 21, 2018
arrives at the receiver. Since the sender needs to compare the OWLs
of all the paths, the sender is assigned executing the OWL
calculation in this draft. A new MPTCP option, called as MP_OWL
Option, is defined to carry the timestamp of data receiving at the
receiver. The format of MP_OWL option is shown in Figure 3, where the
value of 'Kind' is '30' (decimal) [RFC6824].
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| (reserved) |
+---------------+---------------+-------+----------------------+
| Timestamp of receiving |
+--------------------------------------------------------------+
Figure 3: MP_OWL Option
The value of 'subtype' in MP_OWL option could be assigned as '0x8',
since '0x0' through '0x7' have been used [RFC5226]. Table 1 gives the
explanation of the value of '0x8'.
+-------+--------------+----------------------------+
| Value | Symbol | Name |
+-------+--------------+----------------------------+
| 0x8 | MP_OWL | One-Way Latency |
+-------+--------------+----------------------------+
Table 1: The Subtype of MP_OWL option
4.2 Negotiation
The sender and the receiver need to negotiate with each other to see
whether MP_OWL option is supported or not.
The details are to be defined.
4.3 The Steps for OWL Calculation
1) The sender sends each data and remember the sequence number as
well as the sending time T_send of the data;
2) When the receiver receives the data, it responses an ACK with an
MP_OWL option added, which carries the receiving time T_recv of the
data;
3) When ACK gets back to the sender, the sender fetches the receiving
time T_recv of the data from the ACK and subtracts the sending time
T_send it has remembered to get the value of OWL, where OWL = T_recv
- T_send.
J. Zuo, et al Expires September 22, 2018 [Page 6]
INTERNET-DRAFT MPTCP Scheduler March 21, 2018
5. Security Considerations
TBD.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March
1997, <http://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC793,
DOI 10.17487/RFC0793, September 1981, <http://www.rfc-
editor.org/info/rfc793>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and Bonaventure, O.,
"TCP Extensions for Multipath Operation with Multiple Addresses", RFC
6824, DOI 10.17487/RFC6824, January 2013, <http://www.rfc-
editor.org/info/rfc6824>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., Iyengar, J.,
"Architectural Guidelines for Multipath TCP Development", RFC 6182,
DOI 10.17487/RFC6182, March 2011, <http://www.rfc-
editor.org/info/rfc6182>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., Morton, A., "A
One-Way Delay Metric for IP Performance Metrics (IPPM)", RFC 7679,
DOI 10.17487/RFC7679, January 2016, <http://www.rfc-
editor.org/info/rfc7679>.
[RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May
2008, <http://www.rfc-editor.org/info/rfc5226>.
[MPTCP.org] Multipath TCP - Linux Kernel Implementation,
<http://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP>.
[CONEXT17] Coninck, Q. D., Bonaventure, O., "Multipath QUIC: Design
and Evaluation", December 2017, In Proceedings of CoNEXT'17: The 13th
International Conference on emerging Networking EXperiments and
Technologies.
Author's Addresses
J. Zuo, et al Expires September 22, 2018 [Page 7]
INTERNET-DRAFT MPTCP Scheduler March 21, 2018
Jing Zuo
Huawei Technologies
Bantian, Longgang District,
Shenzhen 518129 P.R. China
EMail: jing.zuo@huawei.com
Jianjian Zhu
Huawei Technologies
Bantian, Longgang District,
Shenzhen 518129 P.R. China
EMail: zhujianjian1@huawei.com
Wei Liu
Huawei Technologies
Bantian, Longgang District,
Shenzhen 518129 P.R. China
EMail: liuwei57@huawei.com
J. Zuo, et al Expires September 22, 2018 [Page 8]
