idnits 2.17.1 draft-huitema-quic-ts-07.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (6 March 2022) is 779 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Private Octopus Inc. 4 Intended status: Experimental 6 March 2022 5 Expires: 7 September 2022 7 Quic Timestamps For Measuring One-Way Delays 8 draft-huitema-quic-ts-07 10 Abstract 12 The TIMESTAMP frame can be added to Quic packets when one way delay 13 measurements are useful. The timestamp is set to the number of 14 microseconds from the beginning of the node's epoch to the time at 15 which the packet is sent. The draft defines the "enable_timestamp" 16 transport parameter for negotiating the use of this extension frame, 17 and the TIMESTAMP frame. 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 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://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 7 September 2022. 36 Copyright Notice 38 Copyright (c) 2022 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 (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 3 54 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1.1. Zero RTT and Timestamp Option . . . . . . . . . . . . 4 57 2.2. Sending TIMESTAMP frames . . . . . . . . . . . . . . . . 4 58 2.3. TIMESTAMP frame format . . . . . . . . . . . . . . . . . 4 59 2.4. RTT Measurements . . . . . . . . . . . . . . . . . . . . 5 60 2.5. Choice of Epoch . . . . . . . . . . . . . . . . . . . . . 5 61 2.6. One-Way Delay Measurements . . . . . . . . . . . . . . . 6 62 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Management of Time . . . . . . . . . . . . . . . . . . . 7 64 3.2. Application to QUIC Multipath . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Introduction 75 The QUIC Transport Protocol [QUIC-TRANSPORT] provides a secure, 76 multiplexed connection for transmitting reliable streams of 77 application data. The algorithms for QUIC Loss Detection and 78 Congestion Control [QUIC-RECOVERY] use measurement of Round Trip Time 79 (RTT) to determine when packets should be retransmitted. RTT 80 measurements are useful, but there are however many cases in which 81 more precise One-Way Delay (1WD) measurements enable more efficient 82 Loss Detection and Congestion Control. 84 An example would be the Low Extra Delay Background Transport (LEDBAT) 85 [RFC6817] which uses variations in transmission delay to detect 86 competition for transmission resource. Experience shows that while 87 LEDBAT may be implemented using RTT measurements, it is somewhat 88 inefficient because it will cause unnecessary slowdowns in case of 89 queues or delayed ACKs on the return path. Using 1WD solves these 90 issues. Similar argument can be made for most delay-based 91 algorithms. 93 We propose to enable one way delay measurements in QUIC by defining a 94 TIMESTAMP frame carrying the time at which a packet is sent. The use 95 of this extension frame is negotiated with a transport parameter, 96 "enable_timestamp". When the extension is negotiated by both 97 parties, this frame can be used in conjunction with other such as ACK 98 to measure one way delays. 100 1.1. Terms and Definitions 102 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 2. Specification 110 The enable_timestamp transport parameter used for negotiating the use 111 of the extension frame is defined in Section 2.1. The timestamp 112 frame format is defined in Section 2.3. 114 2.1. Negotiation 116 The use of the timestamp frame extension is negotiated using a 117 transport parameter: 119 * enable_timestamp (TBD) 121 The enable timestamp transport parameter is included if the endpoint 122 wants to receive or accepts to send timestamp frames for this 123 connection. This parameter is encoded as a variable integer as 124 specified in section 16 of [QUIC-TRANSPORT]. It can take one of the 125 following three values: 127 1. I would like to receive TIMESTAMP frames 129 2. I am able to generate TIMESTAMP frames 131 3. I am able to generate TIMESTAMP frames and I would like to 132 receive them 134 Peers receiving another value SHOULD terminate the connection with a 135 TRANSPORT PARAMETER error. 137 A peer that advertises its capability of sending TIMESTAMP frames 138 using option values 2 or 3 MUST NOT send these frames if the other 139 peer does not announce advertise its desire to receive them by 140 sending the enable_timestamp TP with option 1 or 3. This condition 141 is described as "successful sending negotiation" in Section 2.2. 143 Peers that receive TIMESTAMP frames when they have not advertised 144 their desire to receive them MAY terminate the connection with a 145 PROTOCOL VIOLATION error. 147 2.1.1. Zero RTT and Timestamp Option 149 Implementations MUST NOT remember the value of the enable_timestamp 150 parameter and try to use it when attempting 0-RTT on subsequent 151 connections. This rules is in line with the suggestions in section 152 7.4.2 of [QUIC-TRANSPORT] to adopt conservative defaults and avoid 153 compatibility issues. It is also consistent with the specification 154 to only use TIMESTAMP frames in 1RTT packets, see Section 2.2. 156 2.2. Sending TIMESTAMP frames 158 Following successful sending negotiation, a peer SHOULD add a 159 timestamp frame to 1RTT packets carrying an ACK frame. This 160 specification does not impose a placement of TIMESTAMP frames in the 161 packet. They MAY be sent either before or after the ACK frame. 163 Implementations SHOULD NOT send more than one TIMESTAMP frame per 164 packet, but they MAY send more than one in rare circumstances. When 165 multiple TIMESTAMP frames are present in a packet, the receiver 166 retains the frame indicating the largest timestamp. 168 Implementations MUST NOT send the TIMESTAMP frame in Initial, 0-RTT 169 or Handshake packets, because there is a risk that the peer will 170 receive such packets before the negotiation completes. This 171 restriction may appear excessive because some Handshake packets are 172 typically sent after the negotiation completes, but restricting 173 TIMESTAMP frames to 1RTT packets is simpler and less error prone than 174 allowing the TIMESTAMP frame in just a fraction of Handshake packets. 176 2.3. TIMESTAMP frame format 178 TIMESTAMP frames are identified by the frame type: 180 * TIMESTAMP (TBD) 182 TIMESTAMP frames carry a single parameter, the timestamp. 184 0 1 2 3 185 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Timestamp (i) ... 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 Figure 1: TIMESTAMP Frame Format with Timestamp 192 The timestamp encodes the number of microseconds since the beginning 193 of the epoch, as measured by the peer at the time at which the packet 194 is sent. It is encoded using the exponent selected by the peer in 195 the ack_delay_exponent. The exponent reduced timestamp is encoded as 196 a variable length integer. 198 TIMESTAMP frames are not ack-eliciting. Their loss does not require 199 retransmission. 201 For congestion control, TIMESTAMP frames are treated like ACK frames. 202 Section 7 of [QUIC-RECOVERY] specifies that "packets containing only 203 ACK frames do not count towards bytes in flight and are not 204 congestion controlled". The same applies to packets containing only 205 TIMESTAMP frames, or a combination of ACK frames and TIMESTAMP 206 frames. 208 2.4. RTT Measurements 210 RTT measurements are performed as specified in Section 4 of 211 [QUIC-RECOVERY], without reference to the Timestamp parameter of the 212 Timestamped ACK frames. 214 2.5. Choice of Epoch 216 Each peer can chose its epoch as it sees fit, but it MUST remain 217 constant for the duration of the connection, and the resulting 218 timestamps MUST be positive integers. Plausible values for the epoch 219 could be: 221 * the beginning of the connection, i.e., the time at which the first 222 packet for that connection was sent or received. 224 * the time at which the first timestamp is sent. 226 Chosing values close to the beginning of the connection ensures that 227 the timestamps value will be at most equal to the duration of the 228 connection, which limits the amount of bytes required to encode the 229 timestamps. 231 2.6. One-Way Delay Measurements 233 An endpoint generates a One Way Delay Sample on receiving a packet 234 containing both a TIMESTAMP frame and an ACK frame that meets the 235 following two conditions: 237 * the largest acknowledged packet number is newly acknowledged, and 239 * at least one of the newly acknowledged packets was ack-eliciting. 241 The One Way Delay sample, latest_1wd, is generated as the time 242 elapsed since the largest acknowledged packet was sent, corrected for 243 the difference between local time at the sending peer and connection 244 time at the receiving peer, phase_shift. 246 latest_1wd = timestamp - send_time_of_largest_acked - phase_shift 248 By convention, the phase_shift is estimated upon reception of the 249 first RTT sample, first_rtt. It is set to: 251 phase_shift = timestamp - send_time_of_largest_acked - latest_rtt/2 253 In that formula, we assume that the local time are measured in 254 microseconds since the beginning of the connection. The formula does 255 not depend on the choice of epoch by each peer, but simply of the 256 hypothesis that delays on the data path and the return path are about 257 equal. 259 We understand that clocks may drift over time, and that simply 260 estimating a phase shift at the beginning of a connection may be too 261 simplistic for long duration connections. Implementations MAY adopt 262 different strategies to reestimate the phase shift at appropriate 263 intervals. Specifying these strategies is beyond the scope of this 264 document. 266 3. Discussion 268 This document replaces an earlier proposal to modify the format of 269 the ACK frame by including a timestamp inside the modified frame. 270 The revised proposal encodes the timestamp independently of the ACK 271 frame, which requires slightly more overhead to encode the type of 272 the TIMESTAMP frame. 274 Defining an independent frame allows for more flexibility. This 275 draft defines the combination of TIMESTAMP with ACK frames, but they 276 could be combined with other frames as well. For example, adding a 277 TIMESTAMP to packets carrying a Path Response could allow measuring 278 one way delays before deciding to migrate to a new path. 280 3.1. Management of Time 282 There are two known issues with deducing one way delays from RTT 283 measurements: clock drift and undefined phase difference. 285 The phase difference problem is easy to understand. We start from a 286 list of measurements associating the send time of packet number x 287 (s[x]), the receive time of the acknowledgement of packet (a[x]), and 288 the timestamp indicating when packet x was received by the peer 289 (p[x]). The peer's timestamp are expressed in the peer's clock. 291 Suppose that we model the peer's clock as local time plus phase 292 difference f, and that we model the rtt as the sum of two one way 293 delays, up (u[x]) and down (d[x]). We get: 295 u[x] = p[x] + f - s[x] 297 d[x] = a[x] - p[x] - f 299 Just looking at the equation shows that the value of f cannot be 300 determined from the a series of measurement (s[x], a[x], p[x]). You 301 can just add constraints that all u[x] and d[x] are positive numbers, 302 which gives a range of plausible values for f: max(s[x] - p[x]) < f < 303 min(a[x]-p[x]). In case you wonder, you get similar formulations in 304 a multipath scenario. The plausible range may narrow to the min rtt 305 of the shortest path, but no further. 307 The phase difference uncertainty is not a big issue in practice, 308 because control algorithms are much more interested in the variations 309 of the delays than by their absolute values. Suppose we want to 310 compare one way delays at measurement (x) and (y). We get: 312 u[x] = p[x] + f - s[x] 314 u[y] = p[y] + f - s[y] 316 u[x] - u[y] = p[x] - p[y] - s[x] + s[y] 318 The phase difference does not affect the measurement of variations in 319 the one way delay. 321 The clock drift is another matter. All the equations above assume 322 that the local clock and the remote clock have the same frequency. 323 This is an approximation. Clocks drift over time. Instead of just 324 considering a stable phase difference, one should consider the sum of 325 a phase difference and a time-varying drift component. Estimating 326 drift is a complex problem. This was studied in detail in the 327 development of the Network Time Protocol (NTP) [RFC5905]. In theory, 328 implementations of Quic could copy the algorithms of NTP to build a 329 model of the clocks used by the local node and the peer. That would 330 be very complex. 332 Fortunately, implementations of Quic no not need to implement 333 something as complex as NTP. Most time based algorithms are only 334 interested in variations of delays over a short horizon. Clock drift 335 happens at a slow pace, maybe 1 millisecond per minute. Time base 336 congestion control algorithms already have to cope with the potential 337 drift of the minimum RTT due to changing network conditions. They do 338 that by periodically restarting the measurement of the minimum RTT 339 after some delay, typically less than a minute. A simple 340 implementation of one way delay measurements could follow the same 341 approach, for example resetting the phase difference every 30 seconds 342 or so. 344 3.2. Application to QUIC Multipath 346 Time Stamps are very useful in multipath environments, as mentioned 347 in Section 5 of [MULTIPATH-QUIC]. 349 4. Security Considerations 351 The Timestamp value in the TIMESTAMP frame is asserted by the sender 352 of the packet. Adversarial peers could chose values of the timestamp 353 designed to exercise side effects in congestion control algorithms or 354 other algorithms relying on the one-way delays. This can be 355 mitigated by running plausibility checks on the received values. For 356 example, each peer can maintain statistics not just on the One Way 357 Delays, but also on the differences between One Way Delays and RTT, 358 and detect outlier values. Peers can also compare the differences 359 between timestamps in packets carrying acknowledgements and the 360 differences between the sending times of corresponding packets, and 361 detect anomalies if the delays between acknowledging packets appears 362 shorter than the delays when sending them. 364 5. IANA Considerations 366 This document registers a new value in the QUIC Transport Parameter 367 Registry: 369 Value: TBD (using value 0x7158 in early deployments) 371 Parameter Name: enable_timestamp 373 Specification: Indicates that the connection should use TimeStamped 374 ACK frames 375 This document also registers a new value in the QUIC Frame Type 376 registry: 378 Value: TBD (using value 757 in early deployments) 380 Frame Name: TIMESTAMP 382 Specification: Timestamp set at the time packet was sent 384 6. Acknowledgements 386 Thanks to Dmitri Tikhonov, Tal Misrahi, Watson Ladd, Martin Thomson 387 and Ian Swett for their reviews and suggestions. 389 7. References 391 7.1. Normative References 393 [QUIC-RECOVERY] 394 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 395 and Congestion Control", RFC 9002, 396 . 398 [QUIC-TRANSPORT] 399 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 400 Multiplexed and Secure Transport", RFC 9000, 401 . 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, 405 DOI 10.17487/RFC2119, March 1997, 406 . 408 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 409 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 410 May 2017, . 412 7.2. Informative References 414 [MULTIPATH-QUIC] 415 Liu, Y., Ed., Ma, Y., De Coninck, Q., Ed., Bonaventure, 416 O., Huitema, C., and M. Kuehlewind, Ed., "Multipath 417 Extension for QUIC", Work in Progress, Internet-Draft, 418 draft-ietf-quic-multipath, 419 . 422 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 423 "Network Time Protocol Version 4: Protocol and Algorithms 424 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 425 . 427 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 428 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 429 DOI 10.17487/RFC6817, December 2012, 430 . 432 Author's Address 434 Christian Huitema 435 Private Octopus Inc. 436 Email: huitema@huitema.net