idnits 2.17.1 draft-huitema-quic-ts-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 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 (12 September 2021) is 956 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 12 September 2021 5 Expires: 16 March 2022 7 Quic Timestamps For Measuring One-Way Delays 8 draft-huitema-quic-ts-06 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 16 March 2022. 36 Copyright Notice 38 Copyright (c) 2021 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 Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . 5 62 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Management of Time . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 7.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The QUIC Transport Protocol [QUIC-TRANSPORT] provides a secure, 75 multiplexed connection for transmitting reliable streams of 76 application data. The algorithms for QUIC Loss Detection and 77 Congestion Control [QUIC-RECOVERY] use measurement of Round Trip Time 78 (RTT) to determine when packets should be retransmitted. RTT 79 measurements are useful, but there are however many cases in which 80 more precise One-Way Delay (1WD) measurements enable more efficient 81 Loss Detection and Congestion Control. 83 An example would be the Low Extra Delay Background Transport (LEDBAT) 84 [RFC6817] which uses variations in transmission delay to detect 85 competition for transmission resource. Experience shows that while 86 LEDBAT may be implemented using RTT measurements, it is somewhat 87 inefficient because it will cause unnecessary slowdowns in case of 88 queues or delayed ACKs on the return path. Using 1WD solves these 89 issues. Similar argument can be made for most delay-based 90 algorithms. 92 We propose to enable one way delay measurements in QUIC by defining a 93 TIMESTAMP frame carrying the time at which a packet is sent. The use 94 of this extension frame is negotiated with a transport parameter, 95 "enable_timestamp". When the extension is negotiated by both 96 parties, this frame can be used in conjunction with other such as ACK 97 to measure one way delays. 99 1.1. Terms and Definitions 101 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 2. Specification 109 The enable_timestamp transport parameter used for negotiating the use 110 of the extension frame is defined in Section 2.1. The timestamp 111 frame format is defined in Section 2.3. 113 2.1. Negotiation 115 The use of the timestamp frame extension is negotiated using a 116 transport parameter: 118 * enable_timestamp (TBD) 120 The enable timestamp transport parameter is included if the endpoint 121 wants to receive or accepts to send timestamp frames for this 122 connection. This parameter is encoded as a variable integer as 123 specified in section 16 of [QUIC-TRANSPORT]. It can take one of the 124 following three values: 126 1. I would like to receive TIMESTAMP frames 128 2. I am able to generate TIMESTAMP frames 130 3. I am able to generate TIMESTAMP frames and I would like to 131 receive them 133 Peers receiving another value SHOULD terminate the connection with a 134 TRANSPORT PARAMETER error. 136 A peer that advertises its capability of sending TIMESTAMP frames 137 using option values 2 or 3 MUST NOT send these frames if the other 138 peer does not announce advertise its desire to receive them by 139 sending the enable_timestamp TP with option 1 or 3. This condition 140 is described as "successful sending negotiation" in Section 2.2. 142 Peers that receive TIMESTAMP frames when they have not advertised 143 their desire to receive them MAY terminate the connection with a 144 PROTOCOL VIOLATION error. 146 2.1.1. Zero RTT and Timestamp Option 148 Implementations MUST NOT remember the value of the enable_timestamp 149 parameter and try to use it when attempting 0-RTT on subsequent 150 connections. This rules is in line with the suggestions in section 151 7.4.2 of [QUIC-TRANSPORT] to adopt conservative defaults and avoid 152 compatibility issues. It is also consistent with the specification 153 to only use TIMESTAMP frames in 1RTT packets, see Section 2.2. 155 2.2. Sending TIMESTAMP frames 157 Following successful sending negotiation, a peer SHOULD add a 158 timestamp frame to 1RTT packets carrying an ACK frame. This 159 specification does not impose a placement of TIMESTAMP frames in the 160 packet. They MAY be sent either before or after the ACK frame. 162 Implementations SHOULD NOT send more than one TIMESTAMP frame per 163 packet, but they MAY send more than one in rare circumstances. When 164 multiple TIMESTAMP frames are present in a packet, the receiver 165 retains the frame indicating the largest timestamp. 167 Implementations MUST NOT send the TIMESTAMP frame in Initial, 0-RTT 168 or Handshake packets, because there is a risk that the peer will 169 receive such packets before the negotiation completes. This 170 restriction may appear excessive because some Handshake packets are 171 typically sent after the negotiation completes, but restricting 172 TIMESTAMP frames to 1RTT packets is simpler and less error prone than 173 allowing the TIMESTAMP frame in just a fraction of Handshake packets. 175 2.3. TIMESTAMP frame format 177 TIMESTAMP frames are identified by the frame type: 179 * TIMESTAMP (TBD) 181 TIMESTAMP frames carry a single parameter, the timestamp. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Timestamp (i) ... 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Figure 1: TIMESTAMP Frame Format with Timestamp 191 The timestamp encodes the number of microseconds since the beginning 192 of the epoch, as measured by the peer at the time at which the packet 193 is sent. It is encoded using the exponent selected by the peer in 194 the ack_delay_exponent. The exponent reduced timestamp is encoded as 195 a variable length integer. 197 TIMESTAMP frames are not ack-eliciting. Their loss does not require 198 retransmission. 200 For congestion control, TIMESTAMP frames are treated like ACK frames. 201 Section 7 of [QUIC-RECOVERY] specifies that "packets containing only 202 ACK frames do not count towards bytes in flight and are not 203 congestion controlled". The same applies to packets containing only 204 TIMESTAMP frames, or a combination of ACK frames and TIMESTAMP 205 frames. 207 2.4. RTT Measurements 209 RTT measurements are performed as specified in Section 4 of 210 [QUIC-RECOVERY], without reference to the Timestamp parameter of the 211 Timestamped ACK frames. 213 2.5. Choice of Epoch 215 Each peer can chose its epoch as it sees fit, but it MUST remain 216 constant for the duration of the connection, and the resulting 217 timestamps MUST be positive integers. Plausible values for the epoch 218 could be: 220 * the beginning of the connection, i.e., the time at which the first 221 packet for that connection was sent or received. 223 * the time at which the first timestamp is sent. 225 Chosing values close to the beginning of the connection ensures that 226 the timestamps value will be at most equal to the duration of the 227 connection, which limits the amount of bytes required to encode the 228 timestamps. 230 2.6. One-Way Delay Measurements 232 An endpoint generates a One Way Delay Sample on receiving a packet 233 containing both a TIMESTAMP frame and an ACK frame that meets the 234 following two conditions: 236 * the largest acknowledged packet number is newly acknowledged, and 238 * at least one of the newly acknowledged packets was ack-eliciting. 240 The One Way Delay sample, latest_1wd, is generated as the time 241 elapsed since the largest acknowledged packet was sent, corrected for 242 the difference between local time at the sending peer and connection 243 time at the receiving peer, phase_shift. 245 latest_1wd = timestamp - send_time_of_largest_acked - phase_shift 247 By convention, the phase_shift is estimated upon reception of the 248 first RTT sample, first_rtt. It is set to: 250 phase_shift = timestamp - send_time_of_largest_acked - latest_rtt/2 252 In that formula, we assume that the local time are measured in 253 microseconds since the beginning of the connection. The formula does 254 not depend on the choice of epoch by each peer, but simply of the 255 hypothesis that delays on the data path and the return path are about 256 equal. 258 We understand that clocks may drift over time, and that simply 259 estimating a phase shift at the beginning of a connection may be too 260 simplistic for long duration connections. Implementations MAY adopt 261 different strategies to reestimate the phase shift at appropriate 262 intervals. Specifying these strategies is beyond the scope of this 263 document. 265 3. Discussion 267 This document replaces an earlier proposal to modify the format of 268 the ACK frame by including a timestamp inside the modified frame. 269 The revised proposal encodes the timestamp independently of the ACK 270 frame, which requires slightly more overhead to encode the type of 271 the TIMESTAMP frame. 273 Defining an independent frame allows for more flexibility. This 274 draft defines the combination of TIMESTAMP with ACK frames, but they 275 could be combined with other frames as well. For example, adding a 276 TIMESTAMP to packets carrying a Path Response could allow measuring 277 one way delays before deciding to migrate to a new path. 279 3.1. Management of Time 281 There are two known issues with deducing one way delays from RTT 282 measurements: clock drift and undefined phase difference. 284 The phase difference problem is easy to understand. We start from a 285 list of measurements associating the send time of packet number x 286 (s[x]), the receive time of the acknowledgement of packet (a[x]), and 287 the timestamp indicating when packet x was received by the peer 288 (p[x]). The peer's timestamp are expressed in the peer's clock. 290 Suppose that we model the peer's clock as local time plus phase 291 difference f, and that we model the rtt as the sum of two one way 292 delays, up (u[x]) and down (d[x]). We get: 294 u[x] = p[x] + f - s[x] 296 d[x] = a[x] - p[x] - f 298 Just looking at the equation shows that the value of f cannot be 299 determined from the a series of measurement (s[x], a[x], p[x]). You 300 can just add constraints that all u[x] and d[x] are positive numbers, 301 which gives a range of plausible values for f: max(s[x] - p[x]) < f < 302 min(a[x]-p[x]). In case you wonder, you get similar formulations in 303 a multipath scenario. The plausible range may narrow to the min rtt 304 of the shortest path, but no further. 306 The phase difference uncertainty is not a big issue in practice, 307 because control algorithms are much more interested in the variations 308 of the delays than by their absolute values. Suppose we want to 309 compare one way delays at measurement (x) and (y). We get: 311 u[x] = p[x] + f - s[x] 313 u[y] = p[y] + f - s[y] 315 u[x] - u[y] = p[x] - p[y] - s[x] + s[y] 317 The phase difference does not affect the measurement of variations in 318 the one way delay. 320 The clock drift is another matter. All the equations above assume 321 that the local clock and the remote clock have the same frequency. 322 This is an approximation. Clocks drift over time. Instead of just 323 considering a stable phase difference, one should consider the sum of 324 a phase difference and a time-varying drift component. Estimating 325 drift is a complex problem. This was studied in detail in the 326 development of the Network Time Protocol (NTP) [RFC5905]. In theory, 327 implementations of Quic could copy the algorithms of NTP to build a 328 model of the clocks used by the local node and the peer. That would 329 be very complex. 331 Fortunately, implementations of Quic no not need to implement 332 something as complex as NTP. Most time based algorithms are only 333 interested in variations of delays over a short horizon. Clock drift 334 happens at a slow pace, maybe 1 millisecond per minute. Time base 335 congestion control algorithms already have to cope with the potential 336 drift of the minimum RTT due to changing network conditions. They do 337 that by periodically restarting the measurement of the minimum RTT 338 after some delay, typically less than a minute. A simple 339 implementation of one way delay measurements could follow the same 340 approach, for example resetting the phase difference every 30 seconds 341 or so. 343 4. Security Considerations 345 The Timestamp value in the TIMESTAMP frame is asserted by the sender 346 of the packet. Adversarial peers could chose values of the timestamp 347 designed to exercise side effects in congestion control algorithms or 348 other algorithms relying on the one-way delays. This can be 349 mitigated by running plausibility checks on the received values. For 350 example, each peer can maintain statistics not just on the One Way 351 Delays, but also on the differences between One Way Delays and RTT, 352 and detect outlier values. Peers can also compare the differences 353 between timestamps in packets carrying acknowledgements and the 354 differences between the sending times of corresponding packets, and 355 detect anomalies if the delays between acknowledging packets appears 356 shorter than the delays when sending them. 358 5. IANA Considerations 360 This document registers a new value in the QUIC Transport Parameter 361 Registry: 363 Value: TBD (using value 0x7158 in early deployments) 365 Parameter Name: enable_timestamp 367 Specification: Indicates that the connection should use TimeStamped 368 ACK frames 370 This document also registers a new value in the QUIC Frame Type 371 registry: 373 Value: TBD (using value 757 in early deployments) 375 Frame Name: TIMESTAMP 377 Specification: Timestamp set at the time packet was sent 379 6. Acknowledgements 381 Thanks to Dmitri Tikhonov, Tal Misrahi, Watson Ladd, Martin Thomson 382 and Ian Swett for their reviews and suggestions. 384 7. References 386 7.1. Normative References 388 [QUIC-RECOVERY] 389 Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection 390 and Congestion Control", RFC 9002, 391 . 393 [QUIC-TRANSPORT] 394 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 395 Multiplexed and Secure Transport", RFC 9000, 396 . 398 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 399 Requirement Levels", BCP 14, RFC 2119, 400 DOI 10.17487/RFC2119, March 1997, 401 . 403 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 404 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 405 May 2017, . 407 7.2. Informative References 409 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 410 "Network Time Protocol Version 4: Protocol and Algorithms 411 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 412 . 414 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 415 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 416 DOI 10.17487/RFC6817, December 2012, 417 . 419 Author's Address 421 Christian Huitema 422 Private Octopus Inc. 424 Email: huitema@huitema.net