A Path-aware Scheduling Scheme for Multipath Transport Protocols
draft-zuo-mptcp-scheduler-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jianjian Zhu , Wei Liu , Jing Zuo | ||
| Last updated | 2018-03-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-zuo-mptcp-scheduler-00
MPTCP J. Zhu
Internet Draft W. Liu
Intended status: Informational J. Zuo
Expires: September 6, 2018 Huawei
March 5, 2018
A Path-aware Scheduling Scheme for Multipath Transport Protocols
draft-zuo-mptcp-scheduler-00.txt
Abstract
The design of scheduling data amongst multiple asynchronous paths
impacts the performance of multipath transport protocols. This draft
proposes a path-aware scheduling scheme, which adaptively selects the
most suitable scheduling scheme according to the path characteristics
in a time-variant multipath transport scenario. When the path
characteristics are unknown, the redundant mode is employed to
achieve at least as good performance as that of the best single path.
The condition for choosing the most suitable scheduling mode relies
on the measured path characteristics and the application
requirements. Especially, the path-aware scheduling scheme is
designed in this draft in terms of of the delay difference of
multiple paths, compared with a pre-defined delay threshold.
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
J. Zuo, et al Expires September 6, 2018 [Page 1]
INTERNET-DRAFT MPTCP Scheduler March 5, 2018
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
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 Redundant/Non-Redundant modes . . . . . . . . . . . . . 4
3.2. The Mode-Selecting Condition . . . . . . . . . . . . . . . 4
3.3. The Path Characteristics Measurement . . . . . . . . . . . 4
4. Implementation Considerations . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
A suitable scheduling mode will influence the performance of multiple
transport protocols[RFC6824] due to the asynchronous path
characteristics. When the delays of the multiple paths differ, the
packets with consecutive sequence number will arrive at the receiver
at different time, causing the out-of-order problem. Some pre-
scheduled schemes are proposed to pre-schedule the sending time of
each packet ensuring they are delivered in order. Some other
scheduling solutions are trying to re-inject the data in flight from
the slow subflow to the fast subflow and reduce the cwnd size of the
slow subflow[OppRetr]. However, all these methods require the
knowledge of the accurate path characteristics. If the path
characteristics are unknown, the scheduling schemes are arbitrary,
while if the network environment varies violently, the scheduling
schemes can not respond to the variant network in time and may become
invalid.
J. Zuo, et al Expires September 6, 2018 [Page 2]
INTERNET-DRAFT MPTCP Scheduler March 5, 2018
The redundant scheduling mode[MPTCP.org] is useful if the latency is
the primary goal, which will try to transmit the traffic on all
available subflows in a redundant way no matter what the path
characteristics is. However, it achieves the low latency by
sacrificing the bandwidth. The min_RTT scheduling mode is the best
known up to today, which will always first send data on the subflow
with the lowest RTT until the cwnd is full. However, it depends on
the accurate path characteristics measurement. If there is no data
sent on one of the subflows, it can not get the subflow's current
path characteristics.
Therefore, a new path-aware scheduling scheme for multiple transport
protocols is proposed to adaptively select the suitable scheduling
mode according to the path characteristics. Specifically, if the
characteristics of all paths are unknown, the redundant mode is the
appropriate method to send data in all paths concurrently. Meanwhile,
the path characteristics are measured during the redundant
transmission in all the paths. Once the path characteristics are
obtained, the scheduling mode is adaptively selected according to the
measured path characteristics and the application requirements. This
draft also defines the scheduling thresholds to judge the suitable
scheduling mode at a certain scenario. The thresholds could be
defined as the delay difference, the rate, etc., where their value
could be decided by the experience or given by the applications
requirements.
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
The new path-aware scheduling scheme adaptively selects the most
suitable scheduling mode according to the measured path
characteristics compared with a pre-defined threshold. The redundant
mode is employed when the path characteristics are unknown. In this
draft, we take the latency-sensitive traffic as an example, which
considers the delay difference as the mode-selecting condition.
J. Zuo, et al Expires September 6, 2018 [Page 3]
INTERNET-DRAFT MPTCP Scheduler March 5, 2018
3.1. The Redundant/Non-Redundant modes
Two modes are defined: 1) The redundant mode sends the same data in
all paths concurrently; 2)The non-redundant mode sends data in
min_RTT mode or just the best single path.
3.2. The Mode-Selecting Condition
For latency-sensitive traffic, the delay is the most important factor
to make a scheduling decision. Hence, a delay difference is defined
as the mode-selecting condition. Due to the asynchronous path
characteristics, the RTT can not really reflect the delay of the data
delivered to the receiver, the one-way-latency[OWL] is suggested as
the condition, where the receiver calculates the delay with the
arriving time and its corresponding sending time, shown as
one-way latency (i) = receiving time (i) - sending time (i) .
The one-way latency is fed back to the sender carried in the one-way
latency (MP_OWL) Option, then the sender can calculate the delay
difference, as
delay difference (i) = |one-way latency (i) - one-way latency (j)|.
According to the application requirements, a threshold is pre-
configured and used to compare with the measured delay difference.
When the delay difference is less than the threshold, the redundant
mode is employed, otherwise the non-redundant mode is used. For
example, when the non-redundant mode is selected, the path with the
lowest one-way latency is used to send data. If the delay difference
changes until that it is larger than the threshold, then the non-
redundant mode switches back to the redundant mode.
3.3. The Path Characteristics Measurement
As described above, the one-way latency is calculated at the receiver
and fed back to the sender in the option of the acknowledgement
packet, while the delay difference is calculated at the sender. If no
data is scheduled in a certain path for a long time, it can not get
the one-way latency in time, and the scheduling mode may become
invalid. The phenomenon of no data scheduled in a certain path
usually happens when the delay difference of the multiple paths is
large while with limited receive buffer. It also happens when the
application traffic generates in burst intermittently.
During the initialization stage, the path characteristics are
unknown, hence the redundant mode is used to measure the one-way
J. Zuo, et al Expires September 6, 2018 [Page 4]
INTERNET-DRAFT MPTCP Scheduler March 5, 2018
latency. Afterwards, if the selected scheduling mode only sends data
in a certain path according to the measured delay difference, two
alternative methods are designed to make the sender obtain the one-
way latency of the other path, which are 1) Periodically switch to
the redundant mode, which transmits the same data in all paths and
measure the one-way latency; 2) Periodically send a signalling packet
in the other path to measure the one-way latency, which reduce the
network overhead compared to the method 1.
4. Implementation Considerations
As described in Section 3.2, the delay difference is calculated
according to the one-way latency of multiple paths. The one-way
latency is carried in a new defined option, the one-way latency
(MP_OWL) Option, and sent back to the sender. The format is shown as
follows, where the value of the Subtype could be defined as '0x8'.
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) |
+---------------+---------------+-------+----------------------+
| One-way latency(4/8 octets, depending on flags) |
+--------------------------------------------------------------+
Figure 1: One-way Latency (MP_OWL) Option
5. Security Considerations
TBD.
7. Acknowledgements
8. References
8.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>.
8.2. Informative References
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC793,
DOI 10.17487/RFC0793, September 1981, <http://www.rfc-
J. Zuo, et al Expires September 6, 2018 [Page 5]
INTERNET-DRAFT MPTCP Scheduler March 5, 2018
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>.
[MPTCP.org] Multipath TCP - Linux Kernel Implementation,
<http://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP>.
[OppRetr] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M.,
Duchene, F., Bonaventure, O. and Handley, M., "How hard can it be?
designing and implementing a deployable multipath TCP", April 2012,
In Proceedings of the 9th USENIX conference on Networked Systems
Design and Implementation (pp. 29-29).
Author's Addresses
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
Jing Zuo
Huawei Technologies
Bantian, Longgang District,
Shenzhen 518129 P.R. China
EMail: jing.zuo@huawei.com
J. Zuo, et al Expires September 6, 2018 [Page 6]