Skip to main content

One Way Latency Considerations for MPTCP
draft-song-mptcp-owl-01

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 Fei Song , Hong-Ke Zhang
Last updated 2016-12-27 (Latest revision 2016-06-30)
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-song-mptcp-owl-01
MPTCP                                                        Fei Song
Internet Draft                                            Hongke Zhang
Intended status: Informational               Beijing Jiaotong University
Expires: June 2017                                     December 27, 2016

                 One Way Latency Considerations for MPTCP
                        draft-song-mptcp-owl-01.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 kind s 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 June 27, 2017.

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

Song, et al.            Expires June 27, 2017                 [Page 1]

Internet-Draft      One Way Latency Considerations        December 2016

   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. Terminology ................................................. 3
   3. Potential Usages of OWL in MPTCP............................. 3
      3.1. Retransmission Policy................................... 3
      3.2. Crucial Data Scheduling................................. 4
      3.3. Congestion Control Mechanism............................ 4
      3.4. Bandwidth Estimation.................................... 4
      3.5. Shared Bottleneck Detection............................. 4
   4. The Classification of OWL Measurement........................ 4
   5. Security Considerations...................................... 5
   6. IANA Considerations ......................................... 5
   7. References .................................................. 5
      7.1. Normative References.................................... 5
      7.2. Informative References.................................. 5
   8. Acknowledgments ............................................. 6

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.

Song, et al.            Expires June 27, 2017                 [Page 2]

Internet-Draft      One Way Latency Considerations        December 2016

   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].

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.

Song, et al.            Expires June 27, 2017                 [Page 3]

Internet-Draft      One Way Latency Considerations        December 2016

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
   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

Song, et al.            Expires June 27, 2017                 [Page 4]

Internet-Draft      One Way Latency Considerations        December 2016

   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
   minimum forward latency has. 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.

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, RFC793,
             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.

Song, et al.            Expires June 27, 2017                 [Page 5]

Internet-Draft      One Way Latency Considerations        December 2016

   [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
             Congestion Control for Multipath Transport Protocols",
             RFC6356, 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.

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 June 27, 2017                 [Page 6]