MPTCP Fei Song
Internet Draft Hongke Zhang
Intended status: Informational Beijing Jiaotong University
Expires: December 28, 2016 June 28, 2016
One Way Latency Considerations for MPTCP
draft-song-mptcp-owl-00.txt
Abstract
This document discusses the One Way Latency (OWL) utilization for
enhancing multipath TCP (MPTCP) transmission, which is a potential
and beneficial technology in MPTCP Working Group (WG). Several
representative usages of OWL, such as retransmission policy, crucial
data scheduling, are analyzed. Two kinds of OWL measurement
approaches are also provided and compared. We believe that more
explorations related with OWL will be important for MPTCP.
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 http://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 December 28, 2016.
Song, et al. Expires December 28, 2016 [Page 1]
Internet-Draft One Way Latency Considerations June 2016
Copyright Notice
Copyright (c) 2016 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 ................................................ 3
2. Terminology ................................................. 3
3. Potential Usages of OWL in MPTCP............................. 4
3.1. Retransmission Policy................................... 4
3.2. Crucial Data Scheduling................................. 4
3.3. Congestion Control Mechanism............................ 4
3.4. Bandwidth Estimation.................................... 4
3.5. Shared Bottleneck Detection............................. 5
4. The Classification of OWL Measurement........................ 5
5. Security Considerations...................................... 5
6. IANA Considerations ......................................... 6
7. References .................................................. 6
7.1. Normative References.................................... 6
7.2. Informative References.................................. 6
8. Acknowledgments ............................................. 6
Song, et al. Expires December 28, 2016 [Page 2]
Internet-Draft One Way Latency Considerations June 2016
1. Introduction
As the basic elements of Internet, both the intermediate devices and
the end hosts have equipped more and more physical network interfaces.
For the former, multiple interfaces had been widely used in packet
forwarding, traffic engineering, etc. For the latter, the importance
of these interfaces had been confirmed and utilized [RFC6419].
Moreover, the capacity of multiple paths created by multiple
interfaces is leveraged to aggregate higher bandwidth, achieve lower
delay and provide better services. Different with traditional TCP
[RFC0793], many transport layer protocols enable the end hosts to
concurrently transfer data on top of multiple paths and greatly
increase the overall throughput, such as MPTCP [RFC6182][RFC6356].
However, we believe that the performance of current practices of
MPTCP could be further improved by fully taking advantage of One Way
Latency (OWL) during the transmission. In single path transfer mode,
there is less benefits to achieve if one separates the OWL out of
Round Trip Time (RTT) because there are no other available paths to
choose.
Motivated by previous facts, we suggest discussing the necessary
considerations of OWL in MPTCP. The structure of this document is as
follows: Firstly, possible usages of OWL in MPTCP are analyzed.
Secondly, two kinds of OWL measurements are listed and compared. The
consideration related with security and IANA are given at the end.
The potential target readers of this document are application
programmer whose products may significantly benefit from MPTCP. This
document also provides the necessary information for the developers
of MPTCP to implement the new version API into the TCP/IP network
stack.
2. 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].
The document makes extensive use of the terminology and definitions
inherited from Architectural Guidelines for Multipath TCP Development
[RFC6182] and TCP Extensions for Multipath Operation with Multiple
Addresses [RFC6824].
Song, et al. Expires December 28, 2016 [Page 3]
Internet-Draft One Way Latency Considerations June 2016
3. Potential Usages of OWL in MPTCP
There are several potential usages of OWL when MPTCP is enabled by
the sender and receiver. Although only five significant aspects are
illustrated in this document, more explorations in this direction are
still needed.
3.1. Retransmission Policy
When packet is identified by triple duplicated acknowledgements or
timeout, the sender needs to select a suitable path for
retransmission. Due to the popular mechanisms of sequence control in
reliable transport protocols, outstanding packets on multiple paths
may reach to the destination disorderly and trigger Receive Buffer
Blocking (RBB) problem, which will further affect the transmission
performance.
By using the results of OWL measurement, the sender could quickly
determine the specific path with minimum forward latency. RBB could
be relieved as soon as the receiver obtains the most needed packet(s)
and submits them all to the upper layer.
3.2. Crucial Data Scheduling
During the transmission process, there are always some crucial data
need to be sent to the destination immediately. For example, the key
frame of multimedia, high priority chunk of emergency communication,
etc. One can not guarantee the arriving sequence if only RTTs of
multiple paths are utilized.
By using the results of OWL measurement, the sender could easily
select the fast path, in terms of forward latency, for crucial data
transmission. Moreover, the acknowledgements of these crucial data
could be sent on the path with minimum reverse latency. Piggyback is
also useful when duplex communication mode is adopted.
3.3. Congestion Control Mechanism
Current version of MPTCP includes different kinds of congestion
control mechanisms. By reasonably utilizing OWL, the network
congestion situation of single direction could be better described.
More information needs to be added.
3.4. Bandwidth Estimation
Understanding the bandwidth condition is beneficial for data packet
scheduling, load balancing, etc. OWL could be integrated with
Song, et al. Expires December 28, 2016 [Page 4]
Internet-Draft One Way Latency Considerations June 2016
bandwidth estimation approaches without interrupting the regular
packets sending. More information needs to be added.
3.5. Shared Bottleneck Detection
Fairness is critical especially when MPTCP and ordinary TCP coexist
at the same network. The sender could treat OWL measurements as the
sample process of shared bottleneck detection and accordingly adjust
the volume of data packet on multiple paths. More information needs
to be added.
4. The Classification of OWL Measurement
Two kinds of OWL measurement approaches are available in current
network: absolute value and relative value.
For the absolute value of OWL, the primary condition of measurement
is clock synchronization. By using Network Time Protocol (NTP)
[RFC5905], end hosts can unify the local time with remote NTP server.
The additional information or optional capabilities can be even added
via extension fields in standard NTP header [RFC7822]. The
calibration accuracy could reach to millisecond level in less
congested situation. Obvious burden is to persuade the end hosts to
initial NTP option.
For the relative value of OWL, in some circumstance, it is more than
enough to establish applications on top of it. For example, when
retransmission is required, the sender just cares about which path
has minimum forward latency. When bandwidth is being estimated, the
difference of forward latency (i.e. delta latency) among all
available paths is needed. By exchanging the local receiving and
sending timestamps with corresponding end host, both sides could
obtain the relative value of OWL. The matrix operations and algorithm
could accelerate the calculation process.
The concerns of the former one are extra protocol requirement and
synchronization accuracy. However, it is more convenient for its
applications. On the contrary, the latter one only needs to add
timestamps into original protocol stack and does not need to worry
about the accuracy.
5. Security Considerations
This document does not contain any security considerations. However,
future applications of OWL in MPTCP will definitely need to establish
relevant mechanisms for security improvement.
Song, et al. Expires December 28, 2016 [Page 5]
Internet-Draft One Way Latency Considerations June 2016
6. IANA Considerations
There are presently no IANA considerations with this document.
7. References
7.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, November 2011.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, March 2011.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols", RFC
6356, October 2011.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
Extensions for Multipath Operation with Multiple Addresses",
RFC 6824, January 2013.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, March 2016.
8. Acknowledgments
Many thanks to the reviews of this document for their valuable
feedbacks and comments.
Song, et al. Expires December 28, 2016 [Page 6]
Internet-Draft One Way Latency Considerations June 2016
Authors' Addresses
Fei Song
Beijing Jiaotong University (BJTU)
Beijing, 100044, P. R. China
Email: fsong@bjtu.edu.cn
Hongke Zhang
Beijing Jiaotong University (BJTU)
Beijing, 100044, P. R. China
Email: hkzhang@bjtu.edu.cn
Song, et al. Expires December 28, 2016 [Page 7]