idnits 2.17.1 draft-ietf-quic-spin-exp-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2018) is 1983 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 324 -- Looks like a reference, but probably isn't: '2' on line 326 -- Looks like a reference, but probably isn't: '3' on line 328 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-15 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC B. Trammell, Ed. 3 Internet-Draft M. Kuehlewind 4 Intended status: Experimental ETH Zurich 5 Expires: April 26, 2019 October 23, 2018 7 The QUIC Latency Spin Bit 8 draft-ietf-quic-spin-exp-01 10 Abstract 12 This document specifies the addition of a latency spin bit to the 13 QUIC transport protocol and describes how to use it to measure end- 14 to-end latency. 16 Note to Readers 18 This document specifies an experimental delta to the QUIC transport 19 protocol. Specifically, this experimentation is intended to 20 determine: 22 o the impact of the addition of the latency spin bit on 23 implementation and specification complexity; and 25 o the accuracy and value of the information derived from spin bit 26 measurement on live network traffic. 28 The information generated by this experiment will be used by the QUIC 29 working group as input to a decision about the standardization of the 30 latency spin bit. Although this is a Working Group document, it is 31 currently NOT a Working Group deliverable. 33 Discussion of this draft takes place on the QUIC working group 34 mailing list (quic@ietf.org), which is archived at 35 https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. 37 Working Group information can be found at https://github.com/quicwg 38 [2]; source code and issues list for this draft can be found at 39 https://github.com/quicwg/base-drafts/labels/-spin [3]. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on April 26, 2019. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. The Spin Bit Mechanism . . . . . . . . . . . . . . . . . . . 3 77 2.1. Proposed Short Header Format Including Spin Bit . . . . . 3 78 2.2. Setting the Spin Bit on Outgoing Packets . . . . . . . . 4 79 2.3. Resetting Spin Value State . . . . . . . . . . . . . . . 4 80 3. Using the Spin Bit for Passive RTT Measurement . . . . . . . 4 81 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 82 5. Security and Privacy Considerations . . . . . . . . . . . . . 6 83 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 84 6.1. Since draft-ietf-spin-exp-00 . . . . . . . . . . . . . . 6 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 88 8.2. Informative References . . . . . . . . . . . . . . . . . 7 89 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 92 1. Introduction 94 The QUIC transport protocol [QUIC-TRANSPORT] uses Transport Layer 95 Security (TLS) [TLS] to encrypt most of its protocol internals. In 96 contrast to TCP where the sequence and acknowledgement numbers and 97 timestamps (if the respective option is in use) can be seen by on- 98 path observers and used to estimate end-to-end latency, QUIC's wire 99 image (see [WIRE-IMAGE]) currently does not expose any information 100 that can be used for passive latency measurement techniques that rely 101 on this information (e.g. [CACM-TCP], [TMA-QOF]). 103 This document adds an explicit signal for passive latency 104 measurability to the QUIC short header: a "spin bit". Passive 105 observation of the spin bit provides one RTT sample per RTT to 106 passive observers of QUIC traffic. This document describes the 107 mechanism, how it can be added to QUIC, and how it can be used by 108 passive measurement facilities to generate RTT samples. 110 2. The Spin Bit Mechanism 112 The latency spin bit enables latency monitoring from observation 113 points on the network path throughout the duration of a connection. 114 Since it is possible to measure handshake RTT without a spin bit, it 115 is sufficient to include the spin bit in the short packet header. 116 The spin bit therefore appears only after version negotiation and 117 connection establishment are completed. 119 2.1. Proposed Short Header Format Including Spin Bit 121 As of the current editor's version of [QUIC-TRANSPORT], this proposal 122 specifies using the sixth most significant bit (0x04) of the first 123 octet in the short header for the spin bit. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+ 128 |0|K|1|1|0|S|R R| 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Destination Connection ID (0..144) ... 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Packet Number (8/16/32) ... 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Protected Payload (*) ... 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 Figure 1: Short Header Format including proposed Spin Bit 139 S: The Spin bit is set 0 or 1 depending on the stored spin value that 140 is updated on packet reception as explained in Section 2.2. 142 R: Two additional bits are reserved for experimentation in the short 143 header. 145 2.2. Setting the Spin Bit on Outgoing Packets 147 Each endpoint, client and server, maintains a spin value, 0 or 1, for 148 each QUIC connection, and sets the spin bit in the short header to 149 the currently stored value when a packet with a short header is sent 150 out. The spin value is initialized to 0 at each endpoint, client and 151 server, at connection start. Each endpoint also remembers the 152 highest packet number seen from its peer on the connection. 154 The spin value is then determined at each endpoint within a single 155 connection as follows: 157 o When the server receives a packet from the client, if that packet 158 has a short header and if it increments the highest packet number 159 seen by the server from the client, the server sets the spin value 160 to the value observed in the spin bit in the received packet. 162 o When the client receives a packet from the server, if the packet 163 has a short header and if it increments the highest packet number 164 seen by the client from the server, it sets the spin value to the 165 opposite of the spin bit in the received packet. 167 This procedure will cause the spin bit to change value in each 168 direction once per round trip. Observation points can estimate the 169 network latency by observing these changes in the latency spin bit, 170 as described in Section 3. See [QUIC-SPIN] for further illustration 171 of this mechanism in action. 173 2.3. Resetting Spin Value State 175 Each client and server resets it spin value to zero when sending the 176 first packet of a given connection with a new connection ID. This 177 reduces the risk that transient spin bit state can be used to link 178 flows across connection migration or ID change. 180 3. Using the Spin Bit for Passive RTT Measurement 182 When a QUIC flow sends data continuously, the latency spin bit in 183 each direction changes value once per round-trip time (RTT). An on- 184 path observer can observe the time difference between edges (changes 185 from 1 to 0 or 0 to 1) in the spin bit signal in a single direction 186 to measure one sample of end-to-end RTT. 188 An observer can store the largest observed packet number per flow, 189 and reject edges that do not have a monotonically increasing packet 190 number (greater than the largest observed packet number). This will 191 avoid detecting spurious edges caused by reordering events that 192 include an edge, which would lead to very low RTT estimates if not 193 ignored. 195 If the spin bit edge occurs after a long packet number gap, it should 196 be ignored: this filters out high RTT estimates due to loss of an 197 actual edge in a burst of lost packets. 199 Note that this measurement, as with passive RTT measurement for TCP, 200 includes any transport protocol delay (e.g., delayed sending of 201 acknowledgements) and/or application layer delay (e.g., waiting for a 202 request to complete). It therefore provides devices on path a good 203 instantaneous estimate of the RTT as experienced by the application. 204 A simple linear smoothing or moving minimum filter can be applied to 205 the stream of RTT information to get a more stable estimate. 207 However, application-limited and flow-control-limited senders can 208 have application and transport layer delay, respectively, that are 209 much greater than network RTT. When the sender is application- 210 limited and e.g. only sends small amount of periodic application 211 traffic, where that period is longer than the RTT, measuring the spin 212 bit provides information about the application period, not the 213 network RTT. 215 Simple heuristics based on the observed data rate per flow or changes 216 in the RTT series can be used to reject bad RTT samples due to 217 application or flow control limitation; for example, QoF [TMA-QOF] 218 rejects component RTTs significantly higher than RTTs over the 219 history of the flow. These heuristics may use the handshake RTT as 220 an initial RTT estimate for a given flow. 222 An on-path observer that can see traffic in both directions (from 223 client to server and from server to client) can also use the spin bit 224 to measure "upstream" and "downstream" component RTT; i.e, the 225 component of the end-to-end RTT attributable to the paths between the 226 observer and the server and the observer and the client, 227 respectively. It does this by measuring the delay between a spin 228 edge observed in the upstream direction and that observed in the 229 downstream direction, and vice versa. 231 4. IANA Considerations 233 This document has no actions for IANA. 235 5. Security and Privacy Considerations 237 The spin bit is intended to expose end-to-end RTT to observers along 238 the path, so the privacy considerations for the latency spin bit are 239 essentially the same as those for passive RTT measurement in general. 240 It has been shown [PAM-RTT] that RTT measurements do not provide more 241 information for geolocation than is available in the most basic, 242 freely-available IP address based location databases. The risk of 243 exposure of per-flow network RTT to on-path devices is therefore 244 negligible. 246 6. Change Log 248 *RFC Editor's Note:* Please remove this section prior to 249 publication of a final version of this document. 251 6.1. Since draft-ietf-spin-exp-00 253 Nothing yet. 255 Acknowledgments 257 This document is derived from [QUIC-SPIN], which was the work of the 258 following authors in addition to the editor of this document: 260 o Piet De Vaere, ETH Zurich 262 o Roni Even, Huawei 264 o Giuseppe Fioccola, Telecom Italia 266 o Thomas Fossati, Nokia 268 o Marcus Ihlar, Ericsson 270 o Al Morton, AT&T Labs 272 o Emile Stephan, Orange 274 The QUIC Spin Bit was originally specified in a slightly different 275 form by Christian Huitema. 277 This work is partially supported by the European Commission under 278 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 279 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 280 for Education, Research, and Innovation under contract no. 15.0268. 281 This support does not imply endorsement. 283 8. References 285 8.1. Normative References 287 [QUIC-TRANSPORT] 288 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 289 Multiplexed and Secure Transport", draft-ietf-quic- 290 transport-15 (work in progress), October 2018. 292 8.2. Informative References 294 [CACM-TCP] 295 Strowes, S., "Passively Measuring TCP Round-Trip Times (in 296 Communications of the ACM)", October 2013. 298 [PAM-RTT] Trammell, B. and M. Kuehlewind, "Revisiting the Privacy 299 Implications of Two-Way Internet Latency Data (in Proc. 300 PAM 2018)", March 2018. 302 [QUIC-SPIN] 303 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 304 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 305 Passive Measurability of Two-Way Latency to the QUIC 306 Transport Protocol", draft-trammell-quic-spin-03 (work in 307 progress), May 2018. 309 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 310 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 311 . 313 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 314 Integrity Signals for Passive Measurement (in Proc. TMA 315 2014)", April 2014. 317 [WIRE-IMAGE] 318 Trammell, B. and M. Kuehlewind, "The Wire Image of a 319 Network Protocol", draft-trammell-wire-image-04 (work in 320 progress), April 2018. 322 8.3. URIs 324 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 326 [2] https://github.com/quicwg 328 [3] https://github.com/quicwg/base-drafts/labels/-spin 330 Authors' Addresses 332 Brian Trammell (editor) 333 ETH Zurich 335 Email: ietf@trammell.ch 337 Mirja Kuehlewind 338 ETH Zurich 340 Email: mirja.kuehlewind@tik.ee.ethz.ch