idnits 2.17.1 draft-song-mptcp-owl-06.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: ---------------------------------------------------------------------------- No issues found here. 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 has text resembling RFC 2119 boilerplate text. -- The document date (June 19, 2019) is 1773 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPTCP F. Song 2 Internet Draft H. Zhang 3 Intended status: Informational Beijing Jiaotong University 4 Expires: Dec 18, 2019 H. Chan 5 A. Wei 6 Huawei Technologies 7 June 19, 2019 9 One Way Latency Considerations for MPTCP 10 draft-song-mptcp-owl-06 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF). Note that other groups may also distribute 19 working documents as Internet-Drafts. The list of current Internet- 20 Drafts is at http://datatracker.ietf.org/drafts/current/. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 This Internet-Draft will expire on Dec 18, 2019. 29 Copyright Notice 31 Copyright (c) 2017 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with 39 respect to this document. Code Components extracted from this 40 document must include Simplified BSD License text as described in 41 Section 4.e of the Trust Legal Provisions and are provided without 42 warranty as described in the Simplified BSD License. 44 Abstract 46 This document discusses the use of One Way Latency (OWL) for 47 enhancing multipath TCP (MPTCP). Several usages of OWL, such as 48 retransmission policy and crucial data scheduling are analyzed. Two 49 kinds of OWL measurement approaches are also provided and compared. 50 More explorations related with OWL will be contribute to the 51 performance of MPTCP. 53 Table of Contents 55 1. Introduction ................................................ 2 56 2. Conventions and Terminology.................................. 3 57 3. Potential Usages of OWL in MPTCP............................. 3 58 3.1. Crucial Data Scheduling................................. 4 59 3.2. Congestion control...................................... 5 60 3.3. Packet Retransmission................................... 6 61 3.4. Bandwidth Estimation.................................... 6 62 3.5. Shared Bottleneck Detection............................. 7 63 4. OWL Measurements in TCP...................................... 7 64 5. Security Considerations...................................... 8 65 6. IANA Considerations ......................................... 8 66 7. References .................................................. 8 67 7.1. Normative References.................................... 8 68 7.2. Informative Reference................................... 8 69 Authors' Addresses ............................................. 9 71 1. Introduction 73 The terminal hosts and the intermediate devices in the Internet both 74 have been equipped with more and more physical networkinterfaces 75 basically. The efficiency of interfaces, which had been widely 76 used in packet forwarding at the terminal hosts, had been confirmed 77 and utilized [RFC6419]. In addition,in order to aggregate more 78 bandwidths,reduce packet delays, and provide better service, the 79 increased capacity provided by multiple paths created by multiple 80 interfaces is used. Unlike traditional TCP [RFC0793], 81 many transport layer protocols, such as MPTCP [RFC6182] [RFC6824] 82 enable the terminal hosts to concurrently transfer data on top of 83 multiple paths to greatly increase the overall throughput. 85 Round-trip time (RTT) is commonly used in congestion control and 86 loss recovery mechanism for data transmission. However,the key issue 87 with data transmission is simply the delay in data transmission along 88 the path that does not include the return. The uplink and downlink 89 delays between two peers can be very different. RTT can be 90 easily influenced by the latency in the oppsite direction along a 91 path, which does not accurately reflect the delay in data 92 transmission along the path. Therefore, it is recommended to use 93 One Way Latency (OWL) to describe the exact latency from sending data 94 to receiving time data. 96 It is explained in this document that the full use of One Way Latency 97 (OWL) in the transmission process can further improve the performance 98 of the current practice of MPTCP. It may be asymmetric 99 of the OWL components in the forward and reverse direction of a RTT 100 so that it can provide a better measure to the user such as for 101 congestion control even with the regular TCP. It will be more 102 benefits when there are multiple paths to choose. 104 The necessary considerations of OWL in MPTCP has been discussed in 105 this document. The structure of this document is as follows: First, 106 the use cases of several OWLs in MPTCP are analyzed. Second, two 107 OWL measurements are listed and compared. Finally, the precautions 108 related to security and IANA are given. 110 The application programmers whose products may benefit from MPTCP 111 will be potential target audiences for this document significantly. 112 This document also demonstrates the necessary information 113 for MPTCP developers to implement the new version of the API in the 114 TCP/IP network stack. 116 2. Conventions and Terminology 118 The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 One Way Latency (OWL): the propagation delay between a sender and a 123 receiver from the time a signal is sent to the time the signal is 124 received. 126 3. Potential Usages of OWL in MPTCP 128 There are many OWL use cases when the sender and receiver enable 129 MPTCP. Although, only 5 use cases are illustrated in 130 this document, more explorations are still needed. 132 3.1. Crucial Data Scheduling 134 During the transfer process, it is usually necessary to send some 135 basic data to the destination immediately. Examples of such data 136 include multimedia key frames and high priority appearance 137 communication blocks. No one can guarantee the order of arrival 138 by using an RTT with multiple paths alone. 140 The data rate in any given link can be asymmetric. In addition, 141 the delay in a given direction can vary depending on the number 142 of packet queues. Therefore, the same as the opposite direction 143 illustrated in Figure 1, the positive delay in the path is not 144 important. 146 -------- OWL(s-to-c,path1)=16ms <-------- 147 / \ 148 | -----> OWL(c-to-s,path1)= 5ms ----- | 149 | / RTT(path1)=21ms \ | 150 | | | | 151 +------+ +------+ 152 | |-----> OWL(c-to-s,path2)= 8ms -----| | 153 |Client| |Server| 154 | |----- OWL(s-to-c,path2)= 8ms <-----| | 155 +------+ RTT(path2)=16ms +------+ 156 | | | | 157 | \ / | 158 | -----> OWL(c-to-s,path3)=10ms ----- | 159 \ / 160 -------- OWL(s-to-c,path3)= 8ms <-------- 161 RTT(path3)=18ms 163 Figure 1. Example with 3 paths between the client and the server 164 with OWL as indicated in the figure. RTT information alone would 165 indicate to the client that the fastest path to the server is 166 path 2, followed by path 3, and then followed by path 1. Although 167 path 2 is the fastest, whereas OWL indicates to the client that the 168 fastest path to the server is path 1, followed by path 2, and then 169 followed by path 3. 171 For critical data transfers, the sender can easily select a faster 172 path by using OWL measurements (forward delay). In addition, the 173 confirmation of these critical data can be sent on the path with 174 minimal reverse delay. If the duplex communication mode is adopted, 175 the piggybacking is also useful. 177 3.2. Congestion control 179 Congestion in a given direction does not necessarily imply the 180 congestion in the reverse direction. 182 -------- No congestion (path 1) <-------- 183 / \ 184 | -----> Congestion (path 1) ----- | 185 | / \ | 186 | | | | 187 +------+ +------+ 188 |Client| |Server| 189 +------+ +------+ 190 | | | | 191 | \ / | 192 | -----> No congestion (path 2) ----- | 193 \ / 194 -------- Congestion (path 2) <-------- 196 Figure 2. Example of a congestion situation with 2 paths between 197 the client and the server. There is congestion from client to 198 server along both path 1 and path 2. RTT information alone will 199 indicate congestion in both paths, whereas OWL information will 200 show the client that path 2 is the more lightly loaded path to get 201 to the server. 203 We can use OWL instead of RTT to better describe network congestion 204 in a given direction. Especially when congestion can be the case in 205 a one-way path, congestion in the path from the client to the server 206 is different from congestion in the path from the server to the 207 client. The delay of interest for data transmission along a path 208 cannot be reflected by the RTT accurately. For MPTCP, the client 209 needs to choose a more lightly loaded path to send packets [RFC6356]. 210 Instead of comparing the RTT among different paths, it should use 211 OWL to compare among the paths. 213 Current version of MPTCP includes different kinds of congestion 214 control mechanisms [RFC6356]. The network congestion situation in a 215 single direction could be better described by reasonably utilizing 216 OWL. 218 3.3. Packet Retransmission 220 Continuous Multi-Path Transport (CMT) improves throughput by 221 simultaneously transmitting new data from the source to the target 222 host through multiple paths. However, when the packet is identified 223 as lost by three repeated acknowledgments or timeouts, the sender 224 needs to select the appropriate retransmission path. Outstanding 225 packets on multiple paths may reach to the destination disorderly 226 and trigger Receive Buffer Blocking (RBB) problem (Figure 3), which 227 will further affect the transmission performance, due to the popular 228 mechanisms of sequence control in reliable transport protocols. 230 Packetwith octets sequence # 0- 499(lost) 231 ---> Packetwith octets sequence #1000-1499(rcvd) ------ 232 / Packetwith octets sequence #2000-2499(rcvd) \ 233 | | 234 +------+ +--------+ 235 |Sender| |Receiver| 236 +------+ +--------+ 237 | | 238 \ Packetwith octets sequence # 501- 999(lost) / 239 -----> Packetwith octets sequence #1501-1999(lost) ----- 240 Packetwith octets sequence #2501-2999(lost) 242 Figure 3. Example of Receive Buffer Blocking: The packet containing 243 octets 0-499 is lost. On the other hand the packets containing 244 Octets 500-999, 1000-1499, 1500-1999, 2000-2499, and 2500-2999 have 245 all been received. The octets 500-2999 are then all buffered at the 246 receiver, and are blocked by the missing octets 0-499. 248 By using the results of the OWL measurements, the sender can quickly 249 determine the specific path of the positive minimum delay. Once the 250 receiver gets the most needed packet, the RBB can be released and 251 submitted to the upper layer. 253 3.4. Bandwidth Estimation 255 Understanding bandwidth conditions such as packet scheduling and 256 load balancing is critical. OWL can be integrated with bandwidth 257 estimation methods without disrupting the regular transmission of 258 packets. 260 3.5. Shared Bottleneck Detection 262 Fairness is essential when MPTCP and normal TCP coexist in the same 263 network. The sender can treat the OWL measurement as a sample 264 process for shared bottleneck detection, and the sender adjusts the 265 amount of packets on multiple paths accordingly. 267 4. OWL Measurements in TCP 269 The timestamp option in TCP [RFC7323] may be invoked to estimate 270 latency. The time (TSval) of sending the data is provided in the 271 option when sending data. The receiver acknowledges the receipt of 272 this data by echoing this time (TSecr). And also the time (TSval) of 273 sending this acknowledgment is provided. Although there are two 274 problems, these differences in time when validating data from the 275 sender can help estimate the OWL from the sender to the receiver. 277 First, there may be a delay from the time the recipient of the data 278 is received until the time the acknowledgment is sent. Then, the 279 above value can be the upper limit of the OWL. 281 Second, the clock between the sender and the receiver may not be 282 synchronized. OWL can only be displayed in different paths by the 283 above measures when the clock is synchronized. The comparison of 284 OWL between different paths is limited to showing the OWL 285 difference between them without clock synchronization. 287 Two kinds of OWL measurement approaches are available: absolute 288 value measurement and relative value measurement. 290 In order to obtain the absolute value of OWL, the primary condition 291 of measurement is clock synchronization. End hosts can calibrate the 292 local clock with the remote NTP server by using network time 293 protocol (NTP) [RFC5905]. The additional information or optional 294 capabilities can even be added via extension fields in the standard 295 NTP header [RFC7822]. The calibration accuracy can reach to the 296 millisecond level in less congested situations. The obvious burden 297 here is to persuade the end hosts to initialize the NTP option. 299 In some cases it is more than enough to get the relative value of 300 OWL to build an application on it. For example, the sender may only 301 care which path has the minimum forwarding delay when retransmission 302 is required. When estimating bandwidth, the difference in forward 303 latency in all available paths is required, ie incremental latency. 305 Both sides could obtain therelative value of OWL by exchanging 306 with correspondent end host the local timestamps of receiving and 307 sending the packets. 309 Overhead is an additional protocol requirement and synchronization 310 accuracy, while OWL's absolute value measurement is more convenient 311 for the application. Instead, relative values are not needed to 312 worry about accuracy, and overhead is to add timestamps to the 313 original protocol stack. 315 5. Security Considerations 317 This document does not contain any safety precautions. However, the 318 future application of OWL in MPTCP definitely needs to establish 319 related mechanisms to improve security. 321 6. IANA Considerations 323 This document presents no IANA considerations. 325 7. References 327 7.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, DOI 331 10.17487/RFC2119, March 1997, . 334 7.2. Informative Reference 336 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 337 793, DOI 10.17487/RFC0793, September 1981, 338 . 340 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 341 "Network Time Protocol Version 4: Protocol and Algorithms 342 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 343 . 345 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 346 Iyengar, "Architectural Guidelines for Multipath TCP 347 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 348 . 350 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 351 Congestion Control for Multipath Transport Protocols", RFC 352 6356, DOI 10.17487/RFC6356, October 2011, . 355 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 356 Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419, 357 November 2011, . 359 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 360 "TCP Extensions for Multipath Operation with Multiple 361 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 362 . 364 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, 365 Ed., "TCP Extensions for High Performance", RFC 7323, DOI 366 10.17487/RFC7323, September 2014, . 369 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 370 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 371 March 2016, . 373 Authors' Addresses 375 Fei Song 376 Beijing Jiaotong University 377 Beijing, 100044 378 P.R. China 380 Email: fsong@bjtu.edu.cn 382 Hongke Zhang 383 Beijing Jiaotong University 384 Beijing, 100044 385 P.R. China 387 Email: hkzhang@bjtu.edu.cn 388 H Anthony Chan 389 Huawei Technologies 390 5340 Legacy Dr. Building 3 391 Plano, TX 75024 392 USA 394 Email: h.a.chan@ieee.org 396 Anni Wei 397 Huawei Technologies 398 Xin-Xi Rd. No. 3, Haidian District 399 Beijing, 100095 400 P.R. China 402 Email: weiannig@huawei.com