< draft-song-mptcp-owl-05.txt   draft-song-mptcp-owl-06.txt >
MPTCP F. Song MPTCP F. Song
Internet Draft H. Zhang Internet Draft H. Zhang
Intended status: Informational Beijing Jiaotong University Intended status: Informational Beijing Jiaotong University
Expires: June 18, 2019 H. Chan Expires: Dec 18, 2019 H. Chan
A. Wei A. Wei
Huawei Technologies Huawei Technologies
Dec 18, 2018 June 19, 2019
One Way Latency Considerations for MPTCP One Way Latency Considerations for MPTCP
draft-song-mptcp-owl-05 draft-song-mptcp-owl-06
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 18, 2019. This Internet-Draft will expire on Dec 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
This document discusses the use of One Way Latency (OWL) for This document discusses the use of One Way Latency (OWL) for
enhancing multipath TCP (MPTCP). Several use cases of OWL, such as enhancing multipath TCP (MPTCP). Several usages of OWL, such as
retransmission policy and crucial data scheduling are analyzed. Two retransmission policy and crucial data scheduling are analyzed. Two
kinds of OWL measurement approaches are also provided and compared. kinds of OWL measurement approaches are also provided and compared.
More explorations related with OWL will be helpful to the More explorations related with OWL will be contribute to the
performance of MPTCP. performance of MPTCP.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
2. Conventions and Terminology.................................. 3 2. Conventions and Terminology.................................. 3
3. Potential Usages of OWL in MPTCP............................. 3 3. Potential Usages of OWL in MPTCP............................. 3
3.1. Crucial Data Scheduling................................. 4 3.1. Crucial Data Scheduling................................. 4
3.2. Congestion control...................................... 5 3.2. Congestion control...................................... 5
3.3. Packet Retransmission................................... 6 3.3. Packet Retransmission................................... 6
skipping to change at page 2, line 34 skipping to change at page 2, line 34
4. OWL Measurements in TCP...................................... 7 4. OWL Measurements in TCP...................................... 7
5. Security Considerations...................................... 8 5. Security Considerations...................................... 8
6. IANA Considerations ......................................... 8 6. IANA Considerations ......................................... 8
7. References .................................................. 8 7. References .................................................. 8
7.1. Normative References.................................... 8 7.1. Normative References.................................... 8
7.2. Informative Reference................................... 8 7.2. Informative Reference................................... 8
Authors' Addresses ............................................. 9 Authors' Addresses ............................................. 9
1. Introduction 1. Introduction
End hosts and the intermediate devices in the Internet both have The terminal hosts and the intermediate devices in the Internet both
basically been equipped with more and more physical network have been equipped with more and more physical networkinterfaces
interfaces. The efficiency of interfaces, which had been widely basically. The efficiency of interfaces, which had been widely
used in packet forwarding at the end hosts, had been confirmed and used in packet forwarding at the terminal hosts, had been confirmed
utilized [RFC6419]. Moreover,in oder to aggregate more bandwidths, and utilized [RFC6419]. In addition,in order to aggregate more
to decrease packet delay and to provide better services, the bandwidths,reduce packet delays, and provide better service, the
increased capacity provided by the multiple paths created by increased capacity provided by multiple paths created by multiple
multiple interfaces is leveraged. Unlike traditional TCP [RFC0793], interfaces is used. Unlike traditional TCP [RFC0793],
many transport layer protocols, such as MPTCP [RFC6182] [RFC6824] many transport layer protocols, such as MPTCP [RFC6182] [RFC6824]
enable the end hosts to concurrently transfer data on top of enable the terminal hosts to concurrently transfer data on top of
multiple paths to greatly increase the overall throughput. multiple paths to greatly increase the overall throughput.
Round-trip time (RTT) is commonly used in congestion control and Round-trip time (RTT) is commonly used in congestion control and
loss recovery mechanism for data transmission. Yet the key issue for loss recovery mechanism for data transmission. However,the key issue
data transmission is simply the delay of the data transmission along with data transmission is simply the delay in data transmission along
a path which does not include the return. It might be very different the path that does not include the return. The uplink and downlink
of the latency for uplink and downlink between two peers. RTT can be delays between two peers can be very different. RTT can be
easily influenced by the latency in the oppsite direction along a easily influenced by the latency in the oppsite direction along a
path, which cannot reflect the delay of the data transmission path, which does not accurately reflect the delay in data
along that path accurately. Therefore, the use of One Way Latency transmission along the path. Therefore, it is recommended to use
(OWL) is proposed to describe the exact latency from the time that One Way Latency (OWL) to describe the exact latency from sending data
data is sent to the time data is received. to receiving time data.
The performance of current practices of MPTCP can be further It is explained in this document that the full use of One Way Latency
improved by taking full advantage of One Way Latency (OWL) during (OWL) in the transmission process can further improve the performance
the transmission is explained in this document. It may be asymmetric of the current practice of MPTCP. It may be asymmetric
of the OWL components in the forward and reverse direction of a RTT of the OWL components in the forward and reverse direction of a RTT
so that it can provide a better measure to the user such as for so that it can provide a better measure to the user such as for
congestion control even with the regular TCP. It will be more congestion control even with the regular TCP. It will be more
benefits when there are multiple paths to choose. benefits when there are multiple paths to choose.
This document discusses the necessary considerations of OWL in MPTCP. The necessary considerations of OWL in MPTCP has been discussed in
The structure of this document is as follows: Firstly, it analyzed this document. The structure of this document is as follows: First,
several using cases of OWL in MPTCP. Secondly, two kinds of OWL the use cases of several OWLs in MPTCP are analyzed. Second, two
measurements are listed and compared. The considerations related OWL measurements are listed and compared. Finally, the precautions
with security and IANA are given at the end. related to security and IANA are given.
The application programmer whose products may be significantly The application programmers whose products may benefit from MPTCP
benefit from MPTCP will be the potential targeted audience of this will be potential target audiences for this document significantly.
document. The necessary information for the developers of MPTCP to This document also demonstrates the necessary information
implement the new version API into the TCP/IP network stack is also for MPTCP developers to implement the new version of the API in the
demonstrated in this document. TCP/IP network stack.
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
One Way Latency (OWL): the propagation delay between a sender and a One Way Latency (OWL): the propagation delay between a sender and a
receiver from the time a signal is sent to the time the signal is receiver from the time a signal is sent to the time the signal is
received. received.
3. Potential Usages of OWL in MPTCP 3. Potential Usages of OWL in MPTCP
There are a number of OWL use cases when MPTCP is enabled by the There are many OWL use cases when the sender and receiver enable
sender and receiver. Although, only 5 use cases are illustrated in MPTCP. Although, only 5 use cases are illustrated in
this document, more explorations are still needed. this document, more explorations are still needed.
3.1. Crucial Data Scheduling 3.1. Crucial Data Scheduling
During a transmission process, some essential data often need to be During the transfer process, it is usually necessary to send some
immediately sent to the destination. Examples of such data include basic data to the destination immediately. Examples of such data
the key frame of multimedia and high priority chunk of emergency include multimedia key frames and high priority appearance
communication. No one can guarantee the arrival sequence by using communication blocks. No one can guarantee the order of arrival
the RTTs alone with the multiple paths. by using an RTT with multiple paths alone.
The data rate in any given link can be asymmetric. In addition, The data rate in any given link can be asymmetric. In addition,
according to the amount of packet queue, the delay in a given the delay in a given direction can vary depending on the number
direction can change. Therefore, the same as that in the reverse of packet queues. Therefore, the same as the opposite direction
direction as exemplified in Figure 1, delay in a forward direction illustrated in Figure 1, the positive delay in the path is not
in a path is not important. important.
-------- OWL(s-to-c,path1)=16ms <-------- -------- OWL(s-to-c,path1)=16ms <--------
/ \ / \
| -----> OWL(c-to-s,path1)= 5ms ----- | | -----> OWL(c-to-s,path1)= 5ms ----- |
| / RTT(path1)=21ms \ | | / RTT(path1)=21ms \ |
| | | | | | | |
+------+ +------+ +------+ +------+
| |-----> OWL(c-to-s,path2)= 8ms -----| | | |-----> OWL(c-to-s,path2)= 8ms -----| |
|Client| |Server| |Client| |Server|
| |----- OWL(s-to-c,path2)= 8ms <-----| | | |----- OWL(s-to-c,path2)= 8ms <-----| |
skipping to change at page 4, line 44 skipping to change at page 4, line 44
RTT(path3)=18ms RTT(path3)=18ms
Figure 1. Example with 3 paths between the client and the server Figure 1. Example with 3 paths between the client and the server
with OWL as indicated in the figure. RTT information alone would with OWL as indicated in the figure. RTT information alone would
indicate to the client that the fastest path to the server is indicate to the client that the fastest path to the server is
path 2, followed by path 3, and then followed by path 1. Although path 2, followed by path 3, and then followed by path 1. Although
path 2 is the fastest, whereas OWL indicates to the client that the path 2 is the fastest, whereas OWL indicates to the client that the
fastest path to the server is path 1, followed by path 2, and then fastest path to the server is path 1, followed by path 2, and then
followed by path 3. followed by path 3.
The sender can easily choose the faster path by using the results of For critical data transfers, the sender can easily select a faster
OWL measurement, in terms of forward latency, for crucial data path by using OWL measurements (forward delay). In addition, the
transmission. Moreover, the acknowledgements of these crucial data confirmation of these critical data can be sent on the path with
could be sent on the path with minimum reverse latency. If duplex minimal reverse delay. If the duplex communication mode is adopted,
communication mode is adopted, piggyback will be also useful. the piggybacking is also useful.
3.2. Congestion control 3.2. Congestion control
Congestion in a given direction does not necessarily imply the Congestion in a given direction does not necessarily imply the
congestion in the reverse direction. congestion in the reverse direction.
-------- No congestion (path 1) <-------- -------- No congestion (path 1) <--------
/ \ / \
| -----> Congestion (path 1) ----- | | -----> Congestion (path 1) ----- |
| / \ | | / \ |
skipping to change at page 5, line 31 skipping to change at page 5, line 31
\ / \ /
-------- Congestion (path 2) <-------- -------- Congestion (path 2) <--------
Figure 2. Example of a congestion situation with 2 paths between Figure 2. Example of a congestion situation with 2 paths between
the client and the server. There is congestion from client to the client and the server. There is congestion from client to
server along both path 1 and path 2. RTT information alone will server along both path 1 and path 2. RTT information alone will
indicate congestion in both paths, whereas OWL information will indicate congestion in both paths, whereas OWL information will
show the client that path 2 is the more lightly loaded path to get show the client that path 2 is the more lightly loaded path to get
to the server. to the server.
It can be better described the network congestion in a given We can use OWL instead of RTT to better describe network congestion
direction using OWL rather than using RTT. Especially when the in a given direction. Especially when congestion can be the case in
congestion can be a situation in a unidirectional path, the a one-way path, congestion in the path from the client to the server
congestion in the path from a client to a server is different from is different from congestion in the path from the server to the
the congestion in the path from the server to the client. The delay client. The delay of interest for data transmission along a path
of interest for data transmission along a path cannot be cannot be reflected by the RTT accurately. For MPTCP, the client
reflected by the RTT accurately. For MPTCP, the client needs to needs to choose a more lightly loaded path to send packets [RFC6356].
choose a more lightly loaded path to send packets [RFC6356]. Instead Instead of comparing the RTT among different paths, it should use
of comparing the RTT among different paths, it should use OWL to OWL to compare among the paths.
compare among the paths.
Current version of MPTCP includes different kinds of congestion Current version of MPTCP includes different kinds of congestion
control mechanisms [RFC6356]. The network congestion situation in a control mechanisms [RFC6356]. The network congestion situation in a
single direction could be better described by reasonably utilizing single direction could be better described by reasonably utilizing
OWL. OWL.
3.3. Packet Retransmission 3.3. Packet Retransmission
Continuous Multipath Transmission (CMT) increases throughput by Continuous Multi-Path Transport (CMT) improves throughput by
concurrently transferring new data from a source to a destination simultaneously transmitting new data from the source to the target
host through multiple paths. However, the sender needs to select a host through multiple paths. However, when the packet is identified
suitable path for retransmission, when packet is identified as lost as lost by three repeated acknowledgments or timeouts, the sender
by triple duplicated acknowledgements or timeout. Outstanding needs to select the appropriate retransmission path. Outstanding
packets on multiple paths may reach to the destination disorderly packets on multiple paths may reach to the destination disorderly
and trigger Receive Buffer Blocking (RBB) problem (Figure 3), which and trigger Receive Buffer Blocking (RBB) problem (Figure 3), which
will further affect the transmission performance, due to the popular will further affect the transmission performance, due to the popular
mechanisms of sequence control in reliable transport protocols. mechanisms of sequence control in reliable transport protocols.
Packetwith octets sequence # 0- 499(lost) Packetwith octets sequence # 0- 499(lost)
---> Packetwith octets sequence #1000-1499(rcvd) ------ ---> Packetwith octets sequence #1000-1499(rcvd) ------
/ Packetwith octets sequence #2000-2499(rcvd) \ / Packetwith octets sequence #2000-2499(rcvd) \
| | | |
+------+ +--------+ +------+ +--------+
skipping to change at page 6, line 35 skipping to change at page 6, line 35
\ Packetwith octets sequence # 501- 999(lost) / \ Packetwith octets sequence # 501- 999(lost) /
-----> Packetwith octets sequence #1501-1999(lost) ----- -----> Packetwith octets sequence #1501-1999(lost) -----
Packetwith octets sequence #2501-2999(lost) Packetwith octets sequence #2501-2999(lost)
Figure 3. Example of Receive Buffer Blocking: The packet containing Figure 3. Example of Receive Buffer Blocking: The packet containing
octets 0-499 is lost. On the other hand the packets containing octets 0-499 is lost. On the other hand the packets containing
Octets 500-999, 1000-1499, 1500-1999, 2000-2499, and 2500-2999 have Octets 500-999, 1000-1499, 1500-1999, 2000-2499, and 2500-2999 have
all been received. The octets 500-2999 are then all buffered at the all been received. The octets 500-2999 are then all buffered at the
receiver, and are blocked by the missing octets 0-499. receiver, and are blocked by the missing octets 0-499.
The sender can quickly determine the specific path with minimum By using the results of the OWL measurements, the sender can quickly
latency in the forward direction by using the results of OWL determine the specific path of the positive minimum delay. Once the
measurement. As soon as the receiver obtains the most needed packet receiver gets the most needed packet, the RBB can be released and
(s), RBB can be relieved and be submitted to the upper layer. submitted to the upper layer.
3.4. Bandwidth Estimation 3.4. Bandwidth Estimation
It's crucial to understand the bandwidth condition for data packet Understanding bandwidth conditions such as packet scheduling and
scheduling, and load balancing, etc. OWL could be integrated with load balancing is critical. OWL can be integrated with bandwidth
bandwidth estimation approaches without interrupting the regular estimation methods without disrupting the regular transmission of
transmission of packets. packets.
3.5. Shared Bottleneck Detection 3.5. Shared Bottleneck Detection
Fairness is critical especially when MPTCP and ordinary TCP coexist Fairness is essential when MPTCP and normal TCP coexist in the same
in the same network. OWL measurements can be treated by sender as network. The sender can treat the OWL measurement as a sample
the sample process of shared bottleneck detection, and sender adjust process for shared bottleneck detection, and the sender adjusts the
the volume of data packet on multiple paths accordingly. amount of packets on multiple paths accordingly.
4. OWL Measurements in TCP 4. OWL Measurements in TCP
The timestamp option in TCP [RFC7323] may be invoked to estimate The timestamp option in TCP [RFC7323] may be invoked to estimate
latency. The time (TSval) of sending the data is provided in the latency. The time (TSval) of sending the data is provided in the
option when sending data. The receiver acknowledges the receipt of option when sending data. The receiver acknowledges the receipt of
this data by echoing this time (TSecr). And also the time (TSval) of this data by echoing this time (TSecr). And also the time (TSval) of
sending this acknowledgment is provided. Although there are two sending this acknowledgment is provided. Although there are two
problems, the difference of these times in the acknowledgment of problems, these differences in time when validating data from the
data from the sender can help to estimate the OWL from the sender to sender can help estimate the OWL from the sender to the receiver.
the receiver.
First, there may be delay from the time the receiver who has First, there may be a delay from the time the recipient of the data
received the data to the time when the acknowledgment is sent. Then, is received until the time the acknowledgment is sent. Then, the
the above value may be an upper bound of OWL. above value can be the upper limit of the OWL.
Second, the clocks between the sender and the receiver may not be Second, the clock between the sender and the receiver may not be
synchronized. Only if the clocks are synchronized, the OWL can be synchronized. OWL can only be displayed in different paths by the
showed in different paths by the above measure. The comparison of above measures when the clock is synchronized. The comparison of
OWLs among different paths is limited to showing the OWL differences OWL between different paths is limited to showing the OWL
among them without clock synchronization. difference between them without clock synchronization.
Two kinds of OWL measurement approaches are available: absolute Two kinds of OWL measurement approaches are available: absolute
value measurement and relative value measurement. value measurement and relative value measurement.
In order to obtain the absolute value of OWL, the primary condition In order to obtain the absolute value of OWL, the primary condition
of measurement is clock synchronization. End hosts can calibrate the of measurement is clock synchronization. End hosts can calibrate the
local clock with the remote NTP server by using network time local clock with the remote NTP server by using network time
protocol (NTP) [RFC5905]. The additional information or optional protocol (NTP) [RFC5905]. The additional information or optional
capabilities can even be added via extension fields in the standard capabilities can even be added via extension fields in the standard
NTP header [RFC7822]. The calibration accuracy can reach to the NTP header [RFC7822]. The calibration accuracy can reach to the
millisecond level in less congested situations. The obvious burden millisecond level in less congested situations. The obvious burden
here is to persuade the end hosts to initialize the NTP option. here is to persuade the end hosts to initialize the NTP option.
It's more than enough to obtain the relative value of OWL in some In some cases it is more than enough to get the relative value of
circumstances to establish applications on top of it. For instance, OWL to build an application on it. For example, the sender may only
the sender may only care about which path has the minimum forwarding care which path has the minimum forwarding delay when retransmission
latency when retransmission is needed. When bandwidth is being is required. When estimating bandwidth, the difference in forward
estimated, the difference of forward latency, i.e. delta latency, latency in all available paths is required, ie incremental latency.
among all available paths are needed. Both sides could obtain the
relative value of OWL by exchanging with correspondent end host the
local timestamps of receiving and sending the packets.
The overheads are the extra protocol requirement and synchronization Both sides could obtain therelative value of OWL by exchanging
accuracy, while absolute value measurement of OWL is more convenient with correspondent end host the local timestamps of receiving and
for the applications. On the contrary, it's no need for relative sending the packets.
value to worry about the accuracy whereas the overhead is to add
timestamps into the original protocol stack. Overhead is an additional protocol requirement and synchronization
accuracy, while OWL's absolute value measurement is more convenient
for the application. Instead, relative values are not needed to
worry about accuracy, and overhead is to add timestamps to the
original protocol stack.
5. Security Considerations 5. Security Considerations
This document does not contain any security considerations. However, This document does not contain any safety precautions. However, the
the relevant mechanisms definitely need to be established by future future application of OWL in MPTCP definitely needs to establish
applications of OWL in MPTCP to improve security. related mechanisms to improve security.
6. IANA Considerations 6. IANA Considerations
This document presents no IANA considerations. This document presents no IANA considerations.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 28 change blocks. 
106 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/