idnits 2.17.1 draft-huitema-quic-ts-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 (February 24, 2020) is 1523 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-26 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-27 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 February 24, 2020 5 Expires: August 27, 2020 7 Quic Timestamps For Measuring One-Way Delays 8 draft-huitema-quic-ts-00 10 Abstract 12 The TimeStamp frame can be added to Quic packets when one way delay 13 measurements is useful. The timestamp is set to the number of 14 microseconds from the beginning of the connection to the time at 15 which the packet is sent. The draft defines the "enable_time_stamp" 16 transport parameter for negotiating the use of this extension frame, 17 and a new frame types for the time_stamped 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 August 27, 2020. 36 Copyright Notice 38 Copyright (c) 2020 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Measuring One-Way Delays . . . . . . . . . . . . . . . . . . 2 54 1.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 3 55 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Time Stamp frame format . . . . . . . . . . . . . . . . . . . 3 58 3.1. RTT Measurements . . . . . . . . . . . . . . . . . . . . 4 59 3.2. One-Way Delay Measurements . . . . . . . . . . . . . . . 4 60 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 7.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Measuring One-Way Delays 70 The QUIC Transport Protocol [I-D.ietf-quic-transport] provides a 71 secure, multiplexed connection for transmitting reliable streams of 72 application data. The algorithms for QUIC Loss Detection and 73 Congestion Control [I-D.ietf-quic-recovery] use measurement of Round 74 Trip Time (RTT) to determine when packets should be retransmitted. 75 RTT measurements are useful, but there are however many cases in 76 which more precise One-Way Delay (1WD) measurements enable more 77 efficient Loss Detection and Congestion Control. 79 An example would be the Low Extra Delay Background Transport (LEDBAT) 80 [RFC6817] which uses variations in transmission delay to detect 81 competition for transmission resource. Experience shows that while 82 LEDBAT may be implemented using RTT measurements, it is somewhat 83 inefficient because it will cause unnecessary slowdowns in case of 84 queues or delayed ACKs on the return path. Using 1WD solves these 85 issues. Similar argument can be made for most delay-based 86 algorithms. 88 We propose to enable one way delay measurements in QUIC by defining a 89 time_stamp frame carrying the time at which a packet is sent. The 90 use of this extension frame is negotiated with a transport parameter, 91 "enable_time_stamp". When the extension is negotiated by both 92 parties, this frame can be used in conjunction with other such as ACK 93 to measure one way delays. 95 1.1. Terms and Definitions 97 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Specification 105 The enable_time_stamp transport parameter used for negotiating the 106 use of the extension frame is defined in Section 2.1. The time_stamp 107 frame format is defined in Section 3. 109 2.1. Negotiation 111 The use of the time_stamp frame extension is negotiated using a 112 transport parameter: 114 o enable_time_stamp (TBD) 116 The enable time stamp transport parameter is included if the endpoint 117 accepts and sends time_stamp frames for this connection. This 118 parameter has a zero-length value. Negotiation is successful if both 119 peers support include this parameter in their transport parameter 120 message. Peers that receive a time_stamp frame in the absence of 121 successful negotiation MAY terminate the connection with a PROTOCOL 122 VIOLATION error. 124 If negotiation is successful the peers SHOULD add a time_stamp frame 125 to packets carrying an ACK frame. 127 3. Time Stamp frame format 129 Timestamped ACK are identified by the frame type: 131 o time_stamp (TBD) 133 Time stamp frames carry a single parameter, the time stamp. 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | Time Stamp (i) ... 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 Figure 1: ACK Frame Format with Time Stamp 143 The time stamp encodes the number of microseconds since the beginning 144 of the connection, as measured by the peer at the time at which the 145 packet is sent. It is encoded using the exponent selected by the 146 peer in the ack_delay_exponent. The exponent reduced time stamp is 147 encoded as a variable length integer. 149 3.1. RTT Measurements 151 RTT measurements are performed as specified in Section 4 of 152 [I-D.ietf-quic-recovery], without reference to the Timestamp 153 parameter of the Timestamped ACK frames. 155 3.2. One-Way Delay Measurements 157 An endpoint generates a One Way Delay Sample on receiving a packet 158 containing both a Time Stamp frame and an ACK frame that meets the 159 following two conditions: 161 o the largest acknowledged packet number is newly acknowledged, and 163 o at least one of the newly acknowledged packets was ack-eliciting. 165 The One Way Delay sample, latest_1wd, is generated as the time 166 elapsed since the largest acknowledged packet was sent, corrected for 167 the difference between local time at the sending peer and connection 168 time at the receiving peer, phase_shift. 170 latest_1wd = time_stamp - send_time_of_largest_acked - phase_shift 172 By convention, the phase_shift is estimated upon reception of the 173 first RTT sample, first_rtt. It is set to: 175 phase_shift = time_stamp - send_time_of_largest_acked - latest_rtt/2 177 In that formula, we assume that the local time are measured in 178 microseconds since the beginning of the connection. 180 We understand that clocks may drift over time, and that simply 181 estimating a phase shift at the beginning of a connection may be too 182 simplistic for long duration connections. Implementations MAY adopt 183 different strategies to reestimate the phase shift at appropriate 184 intervals. Specifying these strategies is beyond the scope of this 185 document. 187 4. Discussion 189 This document replaces an earlier proposal to modify the format of 190 the ACK frame by including a time stamp inside the modified frame. 191 The revised proposal encodes the time stamp independently of the ACK 192 frame, which requires slightly more overhead to encode the type of 193 the time stamp frame. 195 Defining an independent frame allows for more flexibility. This 196 draft defines the combination of time stamp with ACK frames, but they 197 could be combined with other frames as well. For example, adding a 198 time stamp to packets carrying a Path Response could allow measuring 199 one way delays before deciding to migrate to a new path. 201 5. Security Considerations 203 The Timestamp value in the Time Stamp frame is asserted by the sender 204 of the packet. Adversarial peers could chose values of the time 205 stamp designed to exercise side effects in congestion control 206 algorithms or other algorithms relying on the one-way delays. This 207 can be mitigated by running plausibility checks on the received 208 values. For example, each peer can maintain statistics not just on 209 the One Way Delays, but also on the differences between One Way 210 Delays and RTT, and detect outlier values. Peers can also compare 211 the differences between timestamps in packets carrying 212 acknowledgements and the differences between the sending times of 213 corresponding packets, and detect anomalies if the delays between 214 acknowledging packets appears shorter than the delays when sending 215 them. 217 6. IANA Considerations 219 This document registers a new value in the QUIC Transport Parameter 220 Registry: 222 Value: TBD (using value 0x7157 in early deployments) 224 Parameter Name: enable_time_stamp 226 Specification: Indicates that the connection should use TimeStamped 227 ACK frames 229 This document also registers a new value in the QUIC Frame Type 230 registry: 232 Value: TBD (using value 757 in early deployments) 234 Frame Name: Time Stamp 235 Specification: time stamp at the time packet was sent 237 7. References 239 7.1. Normative References 241 [I-D.ietf-quic-recovery] 242 Iyengar, J. and I. Swett, "QUIC Loss Detection and 243 Congestion Control", draft-ietf-quic-recovery-26 (work in 244 progress), February 2020. 246 [I-D.ietf-quic-transport] 247 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 248 and Secure Transport", draft-ietf-quic-transport-27 (work 249 in progress), February 2020. 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, 253 DOI 10.17487/RFC2119, March 1997, 254 . 256 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 257 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 258 May 2017, . 260 7.2. Informative References 262 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 263 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 264 DOI 10.17487/RFC6817, December 2012, 265 . 267 Author's Address 269 Christian Huitema 270 Private Octopus Inc. 271 427 Golfcourse Rd 272 Friday Harbor WA 98250 273 U.S.A 275 Email: huitema@huitema.net