idnits 2.17.1 draft-huitema-quic-1wd-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. 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 (January 3, 2020) is 1572 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-recovery-24 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-24 Summary: 1 error (**), 0 flaws (~~), 4 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 January 3, 2020 5 Expires: July 6, 2020 7 Quic ACK Timestamps For Measuring One-Way Delays 8 draft-huitema-quic-1wd-00 10 Abstract 12 The QUIC extension for one way delay mesurements adds a single 13 timestamp to the ACK frame. The timestamp is set to the number of 14 microseconds from the beginning of the connection to the time at 15 which the ACK frame is sent. The draft defines the 16 "enable_one_way_delay" transport parameter for negotiating the 17 extension, and two new frame types for timestamped ACK with or 18 without ECN counts. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 6, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Measuring One-Way Delays . . . . . . . . . . . . . . . . . . 2 55 1.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 3 56 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Timestamped ACK format . . . . . . . . . . . . . . . . . . . 3 59 3.1. RTT Measurements . . . . . . . . . . . . . . . . . . . . 4 60 3.2. One-Way Delay Measurements . . . . . . . . . . . . . . . 4 61 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Measuring One-Way Delays 71 The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a 72 secure, multiplexed connection for transmitting reliable streams of 73 application data. The algorithms for QUIC Loss Detection and 74 Congestion Control [I-D.ietf-quic-recovery] use measurement of Round 75 Trip Time (RTT) to determine when packets should be retransmitted. 76 RTT measurements are useful, but there are however many cases in 77 which more precise One-Way Delay (1WD) measurements enable more 78 efficient Loss Detection and Congestion Control. 80 An example would be the Low Extra Delay Background Transport (LEDBAT) 81 [RFC6817] which uses variations in transmission delay to detect 82 competition for transmission resource. Experience shows that while 83 LEDBAT may be implemented using RTT measurements, it is somewhat 84 inefficient because it will cause unnecessary slowdowns in case of 85 queues or delayed ACKs on the return path. Using 1WD solves these 86 issues. Similar argument can be made for most delay-based 87 algorithms. 89 We propose to enable one way delay measurements in QUIC by extending 90 the ACK or ACK-ECN format with a timestamp field. The use of this 91 extended format is negotiated with a transport parameter, 92 "enable_one_way_delay". When the extension is negotiated by both 93 parties, the format of the ACK and ACK ECN frames is extended with 94 the timestamp field. 96 1.1. Terms and Definitions 98 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 2. Specification 106 The enable_one_way_delay transport parameter used for negotiating the 107 extension is defined in Section 2.1. The Timestamped ACK frame 108 format is defined in Section 3. 110 2.1. Negotiation 112 The one way delay extension is negotiated using a transport 113 parameter: 115 enable_one_way_delay (TBD): The enable one-way delay transport 116 parameter is included if the endpoint support one way delay 117 measurements for this connection. This parameter has a zero- 118 length value. 120 Negotiation is successful if both peers support include this 121 parameter in their transport parameter message. If negotiation is 122 successful the peers MUST send Timestamped ACK instead of the 123 standard ACK frames in all 1RTT protected packets. The peers MUST 124 NOT send Timestamped ACK in packets of other types, such as Initial, 125 Handshake or 0RTT protected packet. 127 Receiving a Timestamped ACK frame when not expected MUST be treated 128 as a Protocol Error. Similarly, receiving a standard ACK frame when 129 a Timestamped ACK frame is expected MUST be treated as a Protocol 130 Error. 132 3. Timestamped ACK format 134 Timestamped ACK are identified by the frame type: 136 o Timestamped_ACK (TBD, TBD+1) 138 If the frame type is TBD+1, Timestamped ACK frames also contain the 139 sum of QUIC packets with associated ECN marks received on the 140 connection up until this point. 142 The format of the Timestamped ACK frames is similar to that of the 143 standard ACK Frames defined in section 19.3 of 145 [I-D.ietf-quic-transport], with the addition of the Time Stamp 146 parameter. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Largest Acknowledged (i) ... 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Time Stamp (i) ... 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | ACK Delay (i) ... 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | ACK Range Count (i) ... 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | First ACK Range (i) ... 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | ACK Ranges (*) ... 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | [ECN Counts] ... 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1: ACK Frame Format with Time Stamp 168 The timestamp encodes the number of microseconds since the beginning 169 of the connection, as measured by the peer at the time at which the 170 ACK is sent. It is encoded using the exponent selected by the peer 171 in the ack_delay_exponent. The exponent reduced time stamp is 172 encoded in the ACK frame as a variable length integer. 174 3.1. RTT Measurements 176 RTT measurements are performed as specified in Section 4 of 177 [I-D.ietf-quic-recovery], without reference to the Timestamp 178 parameter of the Timestamped ACK frames. 180 3.2. One-Way Delay Measurements 182 An endpoint generates a One Way Delay Sample on receiving a 183 TimeStamped ACK frame that meets the following two conditions: 185 o the largest acknowledged packet number is newly acknowledged, and 187 o at least one of the newly acknowledged packets was ack-eliciting. 189 The One Way Delay sample, latest_1wd, is generated as the time 190 elapsed since the largest acknowledged packet was sent, corrected for 191 the difference between local time at the sending peer and connection 192 time at the receiving peer, phase_shift. 194 latest_1wd = time_stamp - send_time_of_largest_acked - phase_shift 196 By convention, the phase_shift is estimated upon reception of the 197 first RTT sample, first_rtt. It is set to: 199 phase_shift = time_stamp - send_time_of_largest_acked - latest_rtt/2 201 In that formula, we assume that the local time are measured in 202 microseconds since the beginning of the connection. 204 We understand that clocks may drift over time, and that simply 205 estimating a phase shift at the beginning of a connection may be too 206 simplistic for long duration connections. Implementations MAY adopt 207 different strategies to reestimate the phase shift at appropriate 208 intervals. Specifying these strategies is beyond the scope of this 209 document. 211 4. Discussion 213 This document makes a series of choices in implementing one way delay 214 measurements. The two important choices are the decision to only 215 have one timestamp per Timestamped ACK frame, and to use new frame 216 types for the Timestamped ACK frames. 218 In theory, it would be possible to augment the ACK frame format and 219 document the delay of every frame received. The current proposal is 220 simpler, and creates less overhead. It is also sufficient for the 221 intended usage, which is to improve the efficiency of congestion 222 control protocols. 224 Once the extension is negotiated, it would be possible in theory to 225 reuse the existing ACK frame type and just associate it with the 226 timestamp format. This would spare us the need to reserve two frame 227 type numbers for the new format. However, this simplification would 228 introduce a dependency between the state of the parser and the state 229 of the connection. This dependency is hard to manage in off-line 230 usages such as parsing log files. 232 5. Security Considerations 234 The Timestamp value in the Timestamp ACK is asserted by the sender of 235 the ACK. Adversarial peers could chose values of the time stamp 236 designed to exercise side effects in congestion control algorithms or 237 other algorithms relying on the one-way delays. This can be 238 mitigated by running plausibility checks on the received values. For 239 example, each peer can maintain statistics not just on the One Way 240 Delays, but also on the differences between One Way Delays and RTT, 241 and detect outlier values. Peers can also compare the differences 242 between timestamps of successive acknowledgements and the differences 243 between the sending times of corresponding packets, and detect 244 anomalies if the delays between acknowledging packets appears shorter 245 than the delays when sending them. 247 6. IANA Considerations 249 This document registers a new value in the QUIC Transport Parameter 250 Registry: 252 Value: TBD (using value 0x10DE in early deployments) 254 Parameter Name: enable_one_way_delay 256 Specification: Indicates that the connection should use TimeStamped 257 ACK frames 259 This document also registers a new value in the QUIC Frame Type 260 registry: 262 Value: 0x34 and 0x35 (if this document is approved) 264 Frame Name: Timestamped ACK 266 Specification: ACK frames augmented with a timestamp 268 7. References 270 7.1. Normative References 272 [I-D.ietf-quic-recovery] 273 Iyengar, J. and I. Swett, "QUIC Loss Detection and 274 Congestion Control", draft-ietf-quic-recovery-24 (work in 275 progress), November 2019. 277 [I-D.ietf-quic-transport] 278 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 279 and Secure Transport", draft-ietf-quic-transport-24 (work 280 in progress), November 2019. 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 288 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 289 May 2017, . 291 7.2. Informative References 293 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 294 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 295 DOI 10.17487/RFC6817, December 2012, 296 . 298 Author's Address 300 Christian Huitema 301 Private Octopus Inc. 302 427 Golfcourse Rd 303 Friday Harbor WA 98250 304 U.S.A 306 Email: huitema@huitema.net