idnits 2.17.1 draft-chan-quic-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: ---------------------------------------------------------------------------- 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 (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-01 == Outdated reference: A later version (-06) exists of draft-song-mptcp-owl-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC H. Chan 3 Internet-Draft A. Wei 4 Intended status: Informational Huawei Technologies 5 Expires: September 14, 2017 F. Song 6 H. Zhang 7 Beijing Jiaotong University 8 March 13, 2017 10 One Way Latency Considerations for Multipath in QUIC 11 draft-chan-quic-owl-01 13 Abstract 15 This document discusses the use of One Way Latency (OWL) for 16 enhancing multipath transmission in QUIC. Several representative 17 usages of OWL, such as congestion control mechanism, retransmission 18 policy, crucial data scheduling are analyzed. Two kinds of OWL 19 measurement approaches are also provided and compared. More 20 explorations related with OWL will be researched to improve the 21 performance of QUIC. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 14, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 59 3. Potential Usages of OWL in QUIC . . . . . . . . . . . . . . . 3 60 3.1. Crucial Data Scheduling . . . . . . . . . . . . . . . . . 3 61 3.2. Congestion Control . . . . . . . . . . . . . . . . . . . 4 62 3.3. Packet Retransmission . . . . . . . . . . . . . . . . . . 5 63 4. OWL Measurement . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 7.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 Round-trip time (RTT) is commonly used in congestion control and loss 74 recovery mechanism for data transmission. Yet the key issue for data 75 transmission is simply the delay of the data transmission along a 76 path which does not include the return. The latency for uplink and 77 downlink between two peers may be very different. RTT, which cannot 78 accurately reflect the delay of the data transmission along a path, 79 can be easily influenced by the latency in the opposite direction 80 along that path. Therefore, the use of One Way Latency (OWL) 81 [I-D.song-mptcp-owl] is proposed to describe the exact latency from 82 the time that data is sent to the time data is received. 84 Using the timestamps information in the ACK Frame of QUIC 85 [I-D.ietf-quic-transport], the One Way Latency can be calculated in 86 absolute value or in relative value. As multipath will be supported 87 by QUIC, path selection based on One Way Latency can improve the 88 performance of multipath in QUIC in several situations, such as 89 congestion control, packet retransmission, crucial data scheduling, 90 etc. 92 We suggest discussing the necessary considerations of OWL in QUIC. 93 In the following, possible usages of OWL in QUIC are analyzed, and 94 then two kinds of OWL measurements are listed and compared. 96 2. Conventions and Terminology 98 The key words "MUST", "MUST NOT", "GLUIRED", "SHALL","SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 One Way Latency (OWL): the propagation delay between a sender and a 103 receiver from the time a signal is sent to the time the signal is 104 received. 106 3. Potential Usages of OWL in QUIC 108 There are a number of potential uses of OWL, especially for multipath 109 in QUIC. Although only 3 significant aspects are illustrated in this 110 document, more explorations are still needed. 112 3.1. Crucial Data Scheduling 114 During a transmission process, there are often some crucial data that 115 need to be sent to the destination immediately. Examples of such 116 crucial data are the key frame in multimedia, the high priority chunk 117 of emergency communication, etc. One cannot guarantee the sequence 118 of data arrival along multiple paths if only the RTTs of the multiple 119 paths are used. 121 The data rate in any given link can be asymmetric. In addition, the 122 delay in a given direction can change according to the amount of 123 packet queue. Therefore delay in a forward direction in a path is 124 not necessarily the same as that in the reverse direction as 125 exemplified in Figure 1. 127 -------- OWL(s-to-c,path1)=16ms <-------- 128 / \ 129 | -----> OWL(c-to-s,path1)= 5ms ----- | 130 | / RTT(path1)=21ms \ | 131 | | | | 132 +------+ +------+ 133 | |-----> OWL(c-to-s,path2)= 8ms -----| | 134 |Client| |Server| 135 | |----- OWL(s-to-c,path2)= 8ms <-----| | 136 +------+ RTT(path2)=16ms +------+ 137 | | | | 138 | \ / | 139 | -----> OWL(c-to-s,path3)=10ms ----- | 140 \ / 141 -------- OWL(s-to-c,path3)= 8ms <-------- 142 RTT(path3)=18ms 144 Figure 1. Example with 3 paths between the client and the server 145 with OWL as indicated in the figure. RTT information alone would 146 indicate to the client that the fastest path to the server is path 2, 147 followed by path 3, and then followed by path 1. path 2 is the 148 fastest, whereas OWL indicates to the client that the fastest path to 149 the server is path 1, followed by path 2, and then followed by path 150 3. 152 Using the results of OWL measurement, the sender can easily select 153 the faster path, in terms of the latency in the forward direction, 154 for crucial data transmission. Moreover, the acknowledgements of 155 these crucial data can be sent on the path with minimum latency in 156 the reverse direction. Piggyback is then also useful when in duplex 157 communication mode. 159 3.2. Congestion Control 161 Congestion in a given direction does not necessarily imply congestion 162 also in the reverse direction. 164 -------- No congestion (path 1) <-------- 165 / \ 166 | -----> Congestion (path 1) ----- | 167 | / \ | 168 | | | | 169 +------+ +------+ 170 |Client| |Server| 171 +------+ +------+ 172 | | | | 173 | \ / | 174 | -----> No congestion (path 2) ----- | 175 \ / 176 -------- Congestion (path 2) <-------- 178 Figure 2. Example of a congestion situation with 2 paths between the 179 client and the server. There is congestion from client to server 180 along path 1 and also from server to client along path 2. RTT 181 information alone will indicate congestion in both paths, whereas OWL 182 information will show the client that path 2 is the more lightly 183 loaded path to get to the server. 185 Network congestion in a given direction can be better described using 186 OWL rather than using RTT. Especially when the congestion can be a 187 situation in a unidirectional path, the congestion in the path from a 188 client to a server is different from the congestion in the path from 189 the server to the client. The RTT cannot accurately reflect the 190 delay of interest for data transmission along a path. For multipath 191 in QUIC, the client needs to choose a more lightly loaded path to 192 send packets [RFC6356]. It will then be unwise to compare the RTT 193 among different paths, and it should instead compare the OWL among 194 the paths. 196 3.3. Packet Retransmission 198 Continuous Multipath Transmission (CMT) increases throughput by 199 concurrently transferring new data from a source to a destination 200 host via multiple paths. However, when a packet is lost, Receive 201 Buffer Blocking (RBB) will occur as illustrated in Figure 3. 203 Stream 5, Offset 0, Length 500 (lost) 204 -----> Stream 5, Offset 1000, Length 500 (rcvd) ----- 205 / Stream 5, Offset 2000, Length 500 (rcvd) \ 206 | | 207 +------+ +--------+ 208 |Sender| |Receiver| 209 +------+ +--------+ 210 | | 211 \ Stream 5, Offset 500, Length 500 (rcvd) / 212 -----> Stream 5, Offset 1500, Length 500 (rcvd) ----- 213 Stream 5, Offset 2500, Length 500 (rcvd) 215 Figure 3. Example of Receive Buffer Blocking: The packet containing 216 octets 0-499 in Stream ID=5 is lost. On the other hand the packets 217 containing Octets 500-999, 1000-1499, 1500-1999, 2000-2499 in Stream 218 ID=5 have all been received. The octets 500-2000 are then all 219 buffered at the receiver, and are blocked by the missing octets 220 0-499. 222 Therefore, the sender needs to select a suitable path to retransmit 223 ASAP. Using the results of OWL measurement, the sender can quickly 224 determine the specific path with minimum forward latency. RBB can 225 then be relieved as soon as the receiver obtains the most needed 226 frames in the retransmitted packet(s) and submits them to the upper 227 layer. 229 4. OWL Measurement 231 Two kinds of OWL measurement approaches are available: absolute value 232 measurement and relative value measurement. 234 To obtain the absolute value of OWL, the primary condition of 235 measurement is clock synchronization. Using Network Time Protocol 236 (NTP) [RFC5905], end hosts can calibrate the local clock with the 237 remote NTP server. The additional information or optional 238 capabilities can even be added via extension fields in the standard 239 NTP header [RFC7822]. The calibration accuracy can reach to the 240 millisecond level in less congested situations. The obvious burden 241 here is to persuade the end hosts to initialize the NTP option. 243 Obtaining the relative value of OWL is more than enough in some 244 circumstances to establish applications on top of it. When 245 retransmission is needed, for example, the sender may only care about 246 which path has the minimum forward latency. When bandwidth is being 247 estimated, the difference of forward latency, i.e. delta latency, 248 among all available paths is needed. By exchanging with 249 correspondent end host the local timestamps of receiving and sending 250 the packets, both sides could obtain the relative value of OWL. 252 The considerations to obtain the absolute values are the extra 253 protocol requirement and synchronization accuracy. However, using 254 the absolute values is more convenient for its applications. On the 255 contrary, the relative measurement only needs to send timestamps in 256 the acknowledgment and there is no need to worry about the clock 257 synchronization. 259 5. Security Considerations 261 TBD 263 6. IANA Considerations 265 This document presents no IANA considerations. 267 7. References 269 7.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, 273 DOI 10.17487/RFC2119, March 1997, 274 . 276 7.2. Informative References 278 [I-D.ietf-quic-transport] 279 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 280 and Secure Transport", draft-ietf-quic-transport-01 (work 281 in progress), January 2017. 283 [I-D.song-mptcp-owl] 284 Song, F. and H. Zhang, "One Way Latency Considerations for 285 MPTCP", draft-song-mptcp-owl-01 (work in progress), 286 December 2016. 288 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 289 "Network Time Protocol Version 4: Protocol and Algorithms 290 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 291 . 293 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 294 Congestion Control for Multipath Transport Protocols", 295 RFC 6356, DOI 10.17487/RFC6356, October 2011, 296 . 298 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 299 (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, 300 March 2016, . 302 Authors' Addresses 304 H Anthony Chan 305 Huawei Technologies 306 5340 Legacy Dr. Building 3 307 Plano, TX 75024 308 USA 310 Email: h.a.chan@ieee.org 312 Anni Wei 313 Huawei Technologies 314 Xin-Xi Rd. No. 3, Haidian District 315 Beijing, 100095 316 P. R. China 318 Email: weiannig@huawei.com 320 Fei Song 321 Beijing Jiaotong University 322 Beijing, 100044 323 P. R. China 325 Email: fsong@bjtu.edu.cn 327 Hongke Zhang 328 Beijing Jiaotong University 329 Beijing, 100044 330 P. R. China 332 Email: hkzhang@bjtu.edu.cn