idnits 2.17.1 draft-song-mptcp-owl-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 27, 2016) is 2675 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPTCP Fei Song 2 Internet Draft Hongke Zhang 3 Intended status: Informational Beijing Jiaotong University 4 Expires: June 2017 December 27, 2016 6 One Way Latency Considerations for MPTCP 7 draft-song-mptcp-owl-01.txt 9 Abstract 11 This document discusses the One Way Latency (OWL) utilization for 12 enhancing multipath TCP (MPTCP) transmission, which is a potential 13 and beneficial technology in MPTCP Working Group (WG). Several 14 representative usages of OWL, such as retransmission policy, crucial 15 data scheduling, are analyzed. Two kind s of OWL measurement 16 approaches are also provided and compared. We believe that more 17 explorations related with OWL will be important for MPTCP. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute working 26 documents as Internet-Drafts. The list of current Internet-Drafts is 27 at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 27, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction ................................................ 2 54 2. Terminology ................................................. 3 55 3. Potential Usages of OWL in MPTCP............................. 3 56 3.1. Retransmission Policy................................... 3 57 3.2. Crucial Data Scheduling................................. 4 58 3.3. Congestion Control Mechanism............................ 4 59 3.4. Bandwidth Estimation.................................... 4 60 3.5. Shared Bottleneck Detection............................. 4 61 4. The Classification of OWL Measurement........................ 4 62 5. Security Considerations...................................... 5 63 6. IANA Considerations ......................................... 5 64 7. References .................................................. 5 65 7.1. Normative References.................................... 5 66 7.2. Informative References.................................. 5 67 8. Acknowledgments ............................................. 6 69 1. Introduction 71 As the basic elements of Internet, both the intermediate devices and 72 the end hosts have equipped more and more physical network 73 interfaces. 74 For the former, multiple interfaces had been widely used in packet 75 forwarding, traffic engineering, etc. For the latter, the importance 76 of these interfaces had been confirmed and utilized [RFC6419]. 77 Moreover, the capacity of multiple paths created by multiple 78 interfaces is leveraged to aggregate higher bandwidth, achieve lower 79 delay and provide better services. Different with traditional TCP 80 [RFC0793], many transport layer protocols enable the end hosts to 81 concurrently transfer data on top of multiple paths and greatly 82 increase the overall throughput, such as MPTCP [RFC6182][RFC6356]. 84 However, we believe that the performance of current practices of 85 MPTCP could be further improved by fully taking advantage of One Way 86 Latency (OWL) during the transmission. In single path transfer mode, 87 there is less benefits to achieve if one separates the OWL out of 88 Round Trip Time (RTT) because there are no other available paths to 89 choose. 91 Motivated by previous facts, we suggest discussing the necessary 92 considerations of OWL in MPTCP. The structure of this document is as 93 follows: Firstly, possible usages of OWL in MPTCP are analyzed. 94 Secondly, two kinds of OWL measurements are listed and compared. The 95 consideration related with security and IANA are given at the end. 97 The potential target readers of this document are application 98 programmer whose products may significantly benefit from MPTCP. This 99 document also provides the necessary information for the developers 100 of MPTCP to implement the new version API into the TCP/IP network 101 stack. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 The document makes extensive use of the terminology and definitions 110 inherited from Architectural Guidelines for Multipath TCP Development 111 [RFC6182] and TCP Extensions for Multipath Operation with Multiple 112 Addresses [RFC6824]. 114 3. Potential Usages of OWL in MPTCP 116 There are several potential usages of OWL when MPTCP is enabled by 117 the sender and receiver. Although only five significant aspects are 118 illustrated in this document, more explorations in this direction are 119 still needed. 121 3.1. Retransmission Policy 123 When packet is identified by triple duplicated acknowledgements or 124 timeout, the sender needs to select a suitable path for 125 retransmission. Due to the popular mechanisms of sequence control in 126 reliable transport protocols, outstanding packets on multiple paths 127 may reach to the destination disorderly and trigger Receive Buffer 128 Blocking (RBB) problem, which will further affect the transmission 129 performance. 131 By using the results of OWL measurement, the sender could quickly 132 determine the specific path with minimum forward latency. RBB could 133 be relieved as soon as the receiver obtains the most needed packet(s) 134 and submits them all to the upper layer. 136 3.2. Crucial Data Scheduling 138 During the transmission process, there are always some crucial data 139 need to be sent to the destination immediately. For example, the key 140 frame of multimedia, high priority chunk of emergency communication, 141 etc. One can not guarantee the arriving sequence if only RTTs of 142 multiple paths are utilized. 144 By using the results of OWL measurement, the sender could easily 145 select the fast path, in terms of forward latency, for crucial data 146 transmission. Moreover, the acknowledgements of these crucial data 147 could be sent on the path with minimum reverse latency. Piggyback is 148 also useful when duplex communication mode is adopted. 150 3.3. Congestion Control Mechanism 152 Current version of MPTCP includes different kinds of congestion 153 control mechanisms. By reasonably utilizing OWL, the network 154 congestion situation of single direction could be better described. 155 More information needs to be added. 157 3.4. Bandwidth Estimation 159 Understanding the bandwidth condition is beneficial for data packet 160 scheduling, load balancing, etc. OWL could be integrated with 161 bandwidth estimation approaches without interrupting the regular 162 packets sending. More information needs to be added. 164 3.5. Shared Bottleneck Detection 166 Fairness is critical especially when MPTCP and ordinary TCP coexist 167 at the same network. The sender could treat OWL measurements as the 168 sample process of shared bottleneck detection and accordingly adjust 169 the volume of data packet on multiple paths. More information needs 170 to be added. 172 4. The Classification of OWL Measurement 174 Two kinds of OWL measurement approaches are available in current 175 network: absolute value and relative value. 177 For the absolute value of OWL, the primary condition of measurement 178 is clock synchronization. By using Network Time Protocol (NTP) 179 [RFC5905], end hosts can unify the local time with remote NTP server. 180 The additional information or optional capabilities can be even added 181 via extension fields in standard NTP header [RFC7822]. The 182 calibration accuracy could reach to millisecond level in less 183 congested situation. Obvious burden is to persuade the end hosts to 184 initial NTP option. 186 For the relative value of OWL, in some circumstance, it is more than 187 enough to establish applications on top of it. For example, when 188 retransmission is required, the sender just cares about which path 189 minimum forward latency has. When bandwidth is being estimated, the 190 difference of forward latency (i.e. delta latency) among all 191 available paths is needed. By exchanging the local receiving and 192 sending timestamps with corresponding end host, both sides could 193 obtain the relative value of OWL. The matrix operations and algorithm 194 could accelerate the calculation process. 196 The concerns of the former one are extra protocol requirement and 197 synchronization accuracy. However, it is more convenient for its 198 applications. On the contrary, the latter one only needs to add 199 timestamps into original protocol stack and does not need to worry 200 about the accuracy. 202 5. Security Considerations 204 This document does not contain any security considerations. However, 205 future applications of OWL in MPTCP will definitely need to establish 206 relevant mechanisms for security improvement. 208 6. IANA Considerations 210 There are presently no IANA considerations with this document. 212 7. References 214 7.1. Normative References 216 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC793, 217 September 1981. 219 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 220 Requirement Levels", BCP 14, RFC 2119, March 1997. 222 7.2. Informative References 224 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 225 Multiple-Interface Hosts", RFC 6419, November 2011. 227 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and 228 J.Iyengar, "Architectural Guidelines for Multipath 229 TCP Development", RFC 6182, March 2011. 231 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 232 Congestion Control for Multipath Transport Protocols", 233 RFC6356, October 2011. 235 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 236 "TCP Extensions for Multipath Operation with Multiple 237 Addresses", RFC 6824, January 2013. 239 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 240 "Network Time Protocol Version 4: Protocol and Algorithms 241 Specification", RFC 5905, June 2010. 243 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 244 (NTPv4) Extension Fields", RFC 7822, March 2016. 246 8. Acknowledgments 248 Many thanks to the reviews of this document for their valuable 249 feedbacks and comments. 251 Authors' Addresses 253 Fei Song 254 Beijing Jiaotong University (BJTU) 255 Beijing, 100044, P. R. China 257 Email: fsong@bjtu.edu.cn 259 Hongke Zhang 260 Beijing Jiaotong University (BJTU) 261 Beijing, 100044, P. R. China 263 Email: hkzhang@bjtu.edu.cn