idnits 2.17.1 draft-ietf-quic-spin-exp-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 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 (April 26, 2018) is 2185 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 319 -- Looks like a reference, but probably isn't: '2' on line 321 -- Looks like a reference, but probably isn't: '3' on line 323 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-12 == Outdated reference: A later version (-03) exists of draft-trammell-quic-spin-02 == Outdated reference: A later version (-03) exists of draft-trammell-quic-spin-02 -- Duplicate reference: draft-trammell-quic-spin, mentioned in 'QUIC-SPIN', was also mentioned in 'I-D.trammell-quic-spin'. Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: October 28, 2018 April 26, 2018 7 The QUIC Latency Spin Bit 8 draft-ietf-quic-spin-exp-00 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 October 28, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . 5 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 86 7.2. Informative References . . . . . . . . . . . . . . . . . 7 87 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 The QUIC transport protocol [QUIC-TRANSPORT] uses Transport Layer 93 Security (TLS) [TLS] to encrypt most of its protocol internals. In 94 contrast to TCP where the sequence and acknowledgement numbers and 95 timestamps (if the respective option is in use) can be seen by on- 96 path observers and used to estimate end-to-end latency, QUIC's wire 97 image (see [WIRE-IMAGE]) currently does not expose any information 98 that can be used for passive latency measurement techniques that rely 99 on this information (e.g. [CACM-TCP], [TMA-QOF]). 101 This document adds an explicit signal for passive latency 102 measurability to the QUIC short header: a "spin bit". Passive 103 observation of the spin bit provides one RTT sample per RTT to 104 passive observers of QUIC traffic. This document describes the 105 mechanism, how it can be added to QUIC, and how it can be used by 106 passive measurement facilities to generate RTT samples. 108 2. The Spin Bit Mechanism 110 The latency spin bit enables latency monitoring from observation 111 points on the network path throughout the duration of a connection. 112 Since it is possible to measure handshake RTT without a spin bit, it 113 is sufficient to include the spin bit in the short packet header. 114 The spin bit therefore appears only after version negotiation and 115 connection establishment are completed. 117 2.1. Proposed Short Header Format Including Spin Bit 119 As of the current editor's version of [QUIC-TRANSPORT], this proposal 120 specifies using the sixth most significant bit (0x04) of the first 121 octet in the short header for the spin bit. 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+ 126 |0|K|1|1|0|S|T T| 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Destination Connection ID (0..144) ... 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Packet Number (8/16/32) ... 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Protected Payload (*) ... 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 1: Short Header Format including proposed Spin Bit 137 S: The Spin bit is set 0 or 1 depending on the stored spin value that 138 is updated on packet reception as explained in Section 2.2. 140 2.2. Setting the Spin Bit on Outgoing Packets 142 Each endpoint, client and server, maintains a spin value, 0 or 1, for 143 each QUIC connection, and sets the spin bit in the short header to 144 the currently stored value when a packet with a short header is sent 145 out. The spin value is initialized to 0 at each endpoint, client and 146 server, at connection start. Each endpoint also remembers the 147 highest packet number seen from its peer on the connection. 149 The spin value is then determined at each endpoint within a single 150 connection as follows: 152 o When the server receives a packet from the client, if that packet 153 has a short header and if it increments the highest packet number 154 seen by the server from the client, the server sets the spin value 155 to the value observed in the spin bit in the received packet. 157 o When the client receives a packet from the server, if the packet 158 has a short header and if it increments the highest packet number 159 seen by the client from the server, it sets the spin value to the 160 opposite of the spin bit in the received packet. 162 This procedure will cause the spin bit to change value in each 163 direction once per round trip. Observation points can estimate the 164 network latency by observing these changes in the latency spin bit, 165 as described in Section 3. See [QUIC-SPIN] for further illustration 166 of this mechanism in action. 168 2.3. Resetting Spin Value State 170 Each client and server resets it spin value to zero when sending the 171 first packet of a given connection with a new connection ID. This 172 reduces the risk that transient spin bit state can be used to link 173 flows across connection migration or ID change. 175 3. Using the Spin Bit for Passive RTT Measurement 177 When a QUIC flow sends data continuously, the latency spin bit in 178 each direction changes value once per round-trip time (RTT). An on- 179 path observer can observe the time difference between edges (changes 180 from 1 to 0 or 0 to 1) in the spin bit signal in a single direction 181 to measure one sample of end-to-end RTT. 183 An observer can store the largest observed packet number per flow, 184 and reject edges that do not have a monotonically increasing packet 185 number (greater than the largest observed packet number). This will 186 avoid detecting spurious edges caused by reordering events that 187 include an edge, which would lead to very low RTT estimates if not 188 ignored. 190 If the spin bit edge occurs after a long packet number gap, it should 191 be ignored: this filters out high RTT estimates due to loss of an 192 actual edge in a burst of lost packets. 194 Note that this measurement, as with passive RTT measurement for TCP, 195 includes any transport protocol delay (e.g., delayed sending of 196 acknowledgements) and/or application layer delay (e.g., waiting for a 197 request to complete). It therefore provides devices on path a good 198 instantaneous estimate of the RTT as experienced by the application. 199 A simple linear smoothing or moving minimum filter can be applied to 200 the stream of RTT information to get a more stable estimate. 202 However, application-limited and flow-control-limited senders can 203 have application and transport layer delay, respectively, that are 204 much greater than network RTT. When the sender is application- 205 limited and e.g. only sends small amount of periodic application 206 traffic, where that period is longer than the RTT, measuring the spin 207 bit provides information about the application period, not the 208 network RTT. 210 Simple heuristics based on the observed data rate per flow or changes 211 in the RTT series can be used to reject bad RTT samples due to 212 application or flow control limitation; for example, QoF [TMA-QOF] 213 rejects component RTTs significantly higher than RTTs over the 214 history of the flow. These heuristics may use the handshake RTT as 215 an initial RTT estimate for a given flow. 217 An on-path observer that can see traffic in both directions (from 218 client to server and from server to client) can also use the spin bit 219 to measure "upstream" and "downstream" component RTT; i.e, the 220 component of the end-to-end RTT attributable to the paths between the 221 observer and the server and the observer and the client, 222 respectively. It does this by measuring the delay between a spin 223 edge observed in the upstream direction and that observed in the 224 downstream direction, and vice versa. 226 4. IANA Considerations 228 This document has no actions for IANA. 230 5. Security and Privacy Considerations 232 The spin bit is intended to expose end-to-end RTT to observers along 233 the path, so the privacy considerations for the latency spin bit are 234 essentially the same as those for passive RTT measurement in general. 236 It has been shown [PAM-RTT] that RTT measurements do not provide more 237 information for geolocation than is available in the most basic, 238 freely-available IP address based location databases. The risk of 239 exposure of per-flow network RTT to on-path devices is therefore 240 negligible. 242 6. Acknowledgments 244 This document is derived from [I-D.trammell-quic-spin], which was the 245 work of the following authors in addition to the editor of this 246 document: 248 o Piet De Vaere, ETH Zurich 250 o Roni Even, Huawei 252 o Giuseppe Fioccola, Telecom Italia 254 o Thomas Fossati, Nokia 256 o Marcus Ihlar, Ericsson 258 o Al Morton, AT&T Labs 260 o Emile Stephan, Orange 262 The QUIC Spin Bit was originally specified in a slightly different 263 form by Christian Huitema. 265 This work is partially supported by the European Commission under 266 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 267 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 268 for Education, Research, and Innovation under contract no. 15.0268. 269 This support does not imply endorsement. 271 7. References 273 7.1. Normative References 275 [QUIC-TRANSPORT] 276 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 277 Multiplexed and Secure Transport", draft-ietf-quic- 278 transport-12 (work in progress), April 2018. 280 7.2. Informative References 282 [CACM-TCP] 283 Strowes, S., "Passively Measuring TCP Round-Trip Times (in 284 Communications of the ACM)", October 2013. 286 [I-D.trammell-quic-spin] 287 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 288 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 289 Passive Measurability of Two-Way Latency to the QUIC 290 Transport Protocol", draft-trammell-quic-spin-02 (work in 291 progress), April 2018. 293 [PAM-RTT] Trammell, B. and M. Kuehlewind, "Revisiting the Privacy 294 Implications of Two-Way Internet Latency Data (in Proc. 295 PAM 2018)", March 2018. 297 [QUIC-SPIN] 298 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 299 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 300 Passive Measurability of Two-Way Latency to the QUIC 301 Transport Protocol", draft-trammell-quic-spin-02 (work in 302 progress), April 2018. 304 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 305 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 306 March 2018. 308 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 309 Integrity Signals for Passive Measurement (in Proc. TMA 310 2014)", April 2014. 312 [WIRE-IMAGE] 313 Trammell, B. and M. Kuehlewind, "The Wire Image of a 314 Network Protocol", draft-trammell-wire-image-04 (work in 315 progress), April 2018. 317 7.3. URIs 319 [1] https://mailarchive.ietf.org/arch/search/?email_list=quic 321 [2] https://github.com/quicwg 323 [3] https://github.com/quicwg/base-drafts/labels/-spin 325 Authors' Addresses 327 Brian Trammell (editor) 328 ETH Zurich 330 Email: ietf@trammell.ch 332 Mirja Kuehlewind 333 ETH Zurich 335 Email: mirja.kuehlewind@tik.ee.ethz.ch