idnits 2.17.1 draft-trammell-ippm-spin-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 : ---------------------------------------------------------------------------- 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 date (January 09, 2019) is 1896 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-17 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Measurement WG B. Trammell, Ed. 3 Internet-Draft ETH Zurich 4 Intended status: Experimental January 09, 2019 5 Expires: July 13, 2019 7 An Explicit Transport-Layer Signal for Hybrid RTT Measurement 8 draft-trammell-ippm-spin-00 10 Abstract 12 This document defines an explicit per-flow transport-layer signal for 13 hybrid measurement of end-to-end RTT. This signal consists of three 14 bits: a spin bit, which oscillates once per end-to-end RTT, and a 15 two-bit Valid Edge Counter (VEC), which compensates for loss and 16 reordering of the spin bit to increase fidelity of the signal in less 17 than ideal network conditions. It describes the algorithm for 18 generating the signal, approaches for observing it to passively 19 measure end-to-end latency, and proposes methods for adding it to a 20 variety of IETF transport protocols. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 13, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Signal Generation Mechanism . . . . . . . . . . . . . . . . . 3 58 2.1. Illustrating the Mechanism . . . . . . . . . . . . . . . 4 59 3. Using the Signal for Hybrid RTT Measurement . . . . . . . . . 6 60 4. Using Only the Spin Bit . . . . . . . . . . . . . . . . . . . 8 61 5. Binding the Hybrid RTT Measurement Signal to Transport 62 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 5.1. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.1. Why the transport layer? . . . . . . . . . . . . . . . . 9 67 7. Privacy and Security Considerations . . . . . . . . . . . . . 10 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 11. Informative References . . . . . . . . . . . . . . . . . . . 12 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 Latency is a key metric to understanding network operation and 77 performance, and passive measurability of round trip times (RTT) is a 78 useful and important, if generally unintentional, feature of many 79 transport protocols. Passive measurement allows inspection of 80 latency on productive traffic, avoiding problems with different 81 treatment of productive and measurement traffic, and enables 82 opportunistic measurement of latency without active measurement 83 overhead. 85 However, since these features are largely accidental, methods for 86 passive latency measurement are transport-dependent, and different 87 heuristics for deriving metrics from these accidental signals may 88 lead to non-comparable values. For example, methods applicable can 89 be exclusively based on the TCP timestamp option [RFC7373] (see 90 [CACM-TCP]), leverage both timestamps and matching sequence and 91 acknowledgment numbers (see [TMA-QOF]), or rely on ACK-clocking in 92 flows transmitting at a stable rate (see [CARRA-RTT]). In addition, 93 they rely on features that may change or have undesirable side 94 effects. For example, [CARRA-RTT] makes implicit assumptions about 95 congestion control and pacing that may not hold for all senders, and 96 timestamp-based methods require the TCP timestamp option to operate 97 effectively, which adds 10 bytes of overhead to every packet and 98 provides a relatively large amount of information for sender 99 fingerprinting [ZANDER-TS]. 101 This document defines a hybrid measurement [RFC7799] path signal 102 [PATH-SIGNALS] to be embedded into a transport layer protocol, 103 explicitly intended for exposing end-to-end RTT to measurement 104 devices on path, following the principles elaborated in [IPIM]. This 105 signal consists of three bits: a spin bit, which oscillates once per 106 end-to-end RTT, and a two-bit Valid Edge Counter (VEC), which 107 compensates for loss and reordering of the spin bit to increase 108 fidelity of the signal in less than ideal network conditions. An 109 evaluation of the spin bit and VEC mechanism in a variety of 110 simulated and Internet testbed environments is given in [IMC-SPIN]. 112 The document starts with a mechanism applicable to any transport- 113 layer protocol, then explains how to bind the signal to a variety of 114 IETF transport protocols, and describes a measurement methdology for 115 deriving RTT samples from the signal. 117 2. Signal Generation Mechanism 119 The hybrid RTT measurement signal consists of two parts: 121 o a spin bit, which oscillates once per end-to-end RTT. Measuring 122 the time between observed edges in the spin bit therefore provides 123 an RTT sample. 125 o a valid edge counter (VEC), which serves to reject edges in the 126 spin bit signal which are invalid, due to loss, reordering, or 127 delay. 129 This signal is encoded as three bits in the transport-layer header, 130 or as a transport-layer option or extension, and the mechanism for 131 generating these bits consists of a receive-side procedure for 132 updating signal state, and a send-side procedure for encoding the 133 signal on a packet. 135 On receiving a packet on a given connection, the receiver: 137 1. checks to see whether the packet is the latest packet for the 138 connection. If not, it does not update any signal state. The 139 method for determining whether a packet is the latest packet in a 140 connection is necessarily transport-dependent. 142 2. takes the spin bit from the incoming packet and updates its 143 NEXT_SPIN value for the connection. If the receiver was the 144 responder (server) of the connection, it sets NEXT_SPIN to the to 145 the spin bit on the incoming packet. If the receiver was the 146 initiator (client) of the connection, it sets NEXT_SPIN to the 147 inverse of the spin bit on the incoming packet. 149 3. updates its NEXT_VEC value for the connection as follows. If the 150 incoming spin bit value is the same as LAST_SPIN (see below), it 151 sets NEXT_VEC to 0. Otherwise, if the incoming VEC value is 3, 152 it sets NEXT_VEC to 3. Otherwise, it sets NEXT_VEC to the 153 incoming VEC value plus 1. 155 4. stores the value of the incoming spin bit as LAST_RECV_SPIN for 156 subsequent VEC generation. 158 5. stores the time at which this packet was received as RECV_TIME. 160 On sending a packet on a given connection, the sender: 162 1. sets the outgoing spin bit to NEXT_SPIN 164 2. sets the outgoing VEC to 0 if NEXT_SPIN is the same as 165 LAST_SENT_SPIN. Otherwise, it compares the current system time 166 to RECV_TIME. If more than a configurable delay has passed since 167 RECV_TIME, it sets the outgoing VEC to max(NEXT_VEC, 1). 168 Otherwise, it sets the outgoing VEC to NEXT_VEC 170 This mechanism causes the spin bit to oscillate once per round trip 171 time, and the VEC to count up to 3 and hold on each edge on the spin 172 bit signal, in the absence of lost or reordered edges. Delays in 173 sending an edge due to quiescence cause the VEC to reset to 1. 174 Observation points can therefore estimate the end-to-end latency by 175 observing these edges, as described in Section 3. See Section 2.1, 176 below, for an illustration of this mechanism in action. 178 2.1. Illustrating the Mechanism 180 To illustrate the operation of this signal, we consider a simplified 181 model of a single bidirectional path between client and server as a 182 queue with slots for five packets, and assume that both client and 183 server sent packets at a constant rate. If each packet moves one 184 slot in the queue per clock tick, note that this network has a RTT of 185 10 ticks. In the figures below, the signal is shown as two 186 characters. The first denotes the value of the spin bit (^ = 1, v = 187 0), the second the value of the VEC (0-3). - means no packet in 188 flight. 190 Initially, no packets are in flight, so there is no signal, as shown 191 in Figure 1. 193 +--------+ -- -- -- -- -- +--------+ 194 | | -----------> | | 195 | Client | | Server | 196 | | <----------- | | 197 +--------+ -- -- -- -- -- +--------+ 199 Figure 1: Initial state, no packets between client and server 201 The client begins sending packets with the spin bit and VEC set to 202 zero, as shown in Figure 2. 204 +--------+ v0 v0 v0 -- -- +--------+ 205 | | -----------> | | 206 | Client | | Server | 207 | | <----------- | | 208 +--------+ -- -- -- -- -- +--------+ 210 Figure 2: Client begins sending packets 212 The first packet arrives at the server five ticks later. It reflects 213 the spin bit, and increments the VEC on its first packet, as shown in 214 Figure 3. 216 +--------+ v0 v0 v0 v0 v0 +--------+ 217 | | -----------> | | 218 | Client | | Server | 219 | | <----------- | | 220 +--------+ -- -- v1 v0 v0 +--------+ 222 Figure 3: Server reflects first packet, sets edge 224 When the client receives this edge, again five ticks later, it 225 inverts the spin bit and increments the VEC, as shown in Figure 4. 226 In this way, the spin signal begins to oscillate around the path, 227 with one edge in flight at any given time. 229 +--------+ ^0 ^0 ^2 v0 v0 +--------+ 230 | | -----------> | | 231 | Client | | Server | 232 | | <----------- | | 233 +--------+ v0 v0 v0 v0 v0 +--------+ 235 Figure 4: Client inverts spin bit, increments edge 237 And in turn, when this edge reaches the server, the VEC increments 238 again, reaching its stable value of 3, as shown in Figure 5. 240 observation 241 points X Y 242 +--------+ ^0 ^0 ^0 ^0 ^0 +--------+ 243 | | -----------> | | 244 | Client | | Server | 245 | | <----------- | | 246 +--------+ v0 v0 ^3 ^0 ^0 +--------+ 247 Y 249 Figure 5: Server reflects edge, increments VEC 251 Here we can also see how measurement works. An observer watching the 252 signal at single observation point X in Figure 5 will see an edge 253 every 10 ticks, i.e. once per RTT. An observer watching the signal 254 at a symmetric observation point Y in Figure 5 will see a server- 255 client edge 4 ticks after the client-server edge, and a client-server 256 edge 6 ticks after the server-client edge, allowing it to compute the 257 components of RTT between itself and the client and between itself 258 and the server. 260 +--------+ v0 v0 v0 v0 v0 +--------+ 261 | | -----------> | | 262 | Client | | Server | 263 | | <----------- | | 264 +--------+ ^0 v3 ^0 v0 v0 +--------+ 265 packet A C B D E 267 Figure 6: How the VEC detects reordering 269 Figure 6 shows how this mechanism works in the presence of 270 reordering. Here, we assume the transport provides some form of 271 packet sequencing (such as QUIC [QUIC-TRANSPORT] packet numbers or 272 TCP [RFC0793] sequence numbers). Packet C carries the spin edge, and 273 packet B is reordered on the way to the client. In this case, the 274 client will begin sending spin 1 after the arrival of packet C, and 275 ignore the spin bit flip to 1 on packet B, since B < C; i.e. it does 276 not increment the highest packet number seen. An on-path ovserver 277 can also reject the spurious edges carried by packets B and D, even 278 without knowledge of the transport protocol's sequence numbering (or, 279 as is the case with QUIC, when the transport protocol's sequence 280 numbering is encrypted), since the VEC is 0 on these packets. 282 3. Using the Signal for Hybrid RTT Measurement 284 When at least one sender is sending packets at full rate (i.e., is 285 neither application nor flow-control limited), and the other sender 286 is sending at least one packet per RTT (e.g. as is the case with the 287 TCP acknowledgment-only packets on), the spin bit oscillates once per 288 RTT, and the VEC counts up to 3 and holds on the edges in the spin 289 bit (the first packet carrying a new spin bit value in each 290 direction). An on-path observer can observe the time difference 291 between these edges in the spin bit signal in a single direction to 292 measure one sample of end-to-end RTT. Note that this measurement, as 293 with transport-specific passive RTT measurement, includes any 294 transport protocol delay (e.g., delayed sending of acknowledgements) 295 and/or application layer delay (e.g., waiting for a request to 296 complete). These RTT samples can be used 298 The VEC can be used by observers to determine whether an edge in the 299 spin bit signal is valid or not, as follows: 301 o A packet containing an apparent edge in the spin signal with a VEC 302 of 0 is not a valid edge, but may be have been caused by 303 reordering or loss, or was marked as delayed by the sender. It 304 should therefore be ignored. 306 o A packet containing an apparent edge in the spin signal with a VEC 307 of 1 can be used as a left edge (i.e., to start measuring an RTT 308 sample), but not as a right edge (i.e., to take an RTT sample 309 since the last edge). 311 o A packet containing an apparent edge in the spin signal with a VEC 312 of 2 can be used as a left edge, but not as a right edge. If the 313 observation point is symmetric (i.e, it can see both upstream and 314 downstream packets in the flow), the packet can also be used to 315 take a component RTT sample on the segment of the path between the 316 observation point and the direction in which the previous VEC 1 317 edge was seen. 319 o A packet containing an apparent edge in the spin signal with a VEC 320 of 3 can be used as a left edge or right edge, and can be used to 321 compute component RTT in either direction. 323 Taking only valid samples ensures that the RTT estimate provided is 324 accurate. However, in some situations, it may result in a low sample 325 rate. Since the VEC resets to one when a sender determines that its 326 edge is delayed, bursty traffic on one side of the connection will 327 cause the VEC not to count up to 3 very often. Likewise, a 328 connection on which many edges are lost (because the connection 329 itself is very lossy) will cause many samples to be rejected as well. 330 Observers may choose to use heuristics in addition to VEC analysis to 331 increase the sample rate in challenging network or traffic 332 environments. 334 4. Using Only the Spin Bit 336 Note that, in the absence of loss and reordering, the single spin bit 337 on its own suffices to provide one accurate RTT sample per RTT to on- 338 path observers. Instead of using two additional bits for the VEC to 339 reject bad samples caused by less than ideal network conditions, 340 protocol designers can instead opt to add only the spin bit to the 341 protocol, and shift the burden of correcting the RTT sample stream to 342 observers, in keeping with the third principle elaborated in [IPIM]: 343 the cost of deriving measurements from measurable protocols should be 344 shifted from the participants to the measurement consumers where 345 possible. Indeed, this is the approach followed by QUIC when adding 346 the spin signal to the protocol (see Section 5.1). 348 5. Binding the Hybrid RTT Measurement Signal to Transport Protocols 350 The following subsections define how to bind the spin bit to various 351 IETF transport protocols. As of this writing, bindings are specified 352 for QUIC and TCP. 354 5.1. QUIC 356 This signal was originally specified for the QUIC transport protocol 357 [QUIC-TRANSPORT], as the encrypted design of that protocol makes 358 passive RTT measurement impossible. The binding of this signal to 359 QUIC is partially described in [QUIC-SPIN-EXP], which adds the spin 360 bit only (without the VEC) to QUIC for experimentation purposes. 362 The "latest packet" determination for QUIC is made using the QUIC 363 packet number: only packets which have a packet number greater than 364 the highest packet number seen are considered when generating the 365 signal. 367 Note that, when used with QUIC, the signal only appears on short 368 header packets; long header packets are ignored for the purposes of 369 generating the signal. Since either the client or the server may 370 start sending short header packets first, both sides initialize their 371 NEXT_SPIN value to 0. 373 5.2. TCP 375 The signal can be added to TCP by defining bit 4 of bytes 13-14 of 376 the TCP header to carry the spin bit, and bits 5 and 6 to carry the 377 VEC, as shown in Figure 7. 379 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 380 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 381 | | | | R | C | E | U | A | P | R | S | F | 382 | Header Length | S | VEC | s | W | C | R | C | S | S | Y | I | 383 | | | | v | R | E | G | K | H | T | N | N | 384 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 386 Figure 7: Definition of bytes 13 and 14 of TCP header with spin bit S 387 and VEC 389 The "latest packet" determination for TCP is made using the TCP 390 sequence and acknowledgment numbers: only packets which have a 391 sequence number greater than highest sequence number seen, accounting 392 for wraparound, or which have a sequence number equal to the last 393 sequence number seen and an acknowledgment number higher than the 394 highest acknowledgment number seen, accounting for wraparound, are 395 considered when generating the signal. 397 Since use of the reserved bits may cause connectivity issues in 398 situations where overzealous interpretation by devices on path of 399 "must be zero" for the reserved bits in byte 13 of the TCP header 400 [RFC0793], the addition of the signal to TCP includes a simple 401 fallback mechanism. The client sets NEXT_SPIN to 1 and NEXT_VEC to 0 402 on its initial SYN. If this SYN is lost, the client disables 403 generation of the signal for the life of the connection. 405 A cursory initial evaluation presented in [IMC-SPIN] suggests that 406 the deployability of a latency spin signal in the reserved bits of 407 TCP is on the order of equivalent to the deployability of a latency 408 spin signal carried in a newly-defined experimental TCP option 409 [RFC6694]. 411 6. Discussion 413 This signal is the result of work carried out in various BoFs and 414 working groups in the IETF. This section attempts to answer 415 questions that have been posed in those contexts about approaches 416 such as that outlined in this document. 418 Additional discussion of privacy and security relevant questions is 419 given in Section 7. 421 6.1. Why the transport layer? 423 As this path signal is (by definition) designed for consumption by 424 devices on the path, and the transport layer is designed for end-to- 425 end operation, an obvious question presents itself: isn't this a 426 layer violation? The answer is both "not really" and "it doesn't 427 matter". 429 The signal defined in this document is designed to measure per- 430 connection, end-to-end RTT. The per-connection nature of the signal 431 leverages the assumption that all packets of a given connection 432 (n-tuple flow, including transport layer ports) will be routed over 433 the same path over a given time interval (on the scale of multiple 434 RTTs) to ensure observability at all points along the path. As it is 435 necessarily a per-connection signal, it is best carried at the 436 transport layer. In addition, the need to reject retransmitted or 437 duplicated packets in the generated signal implies the need for 438 sequence or packet numbering, which is also inherently per- 439 connection, and therefore a transport-layer function. 441 In any case, adding this signal to network layer protocols is 442 unlikely to prove deployable. IPv6 hop-by-hop and destination 443 options [RFC8200] do not work on a significant minority of measured 444 network paths [RFC7872], and IPv4 [RFC0791] options are even less 445 usable. 447 7. Privacy and Security Considerations 449 The privacy considerations for the hybrid RTT measurement signal are 450 essentially the same as those for passive RTT measurement in general. 452 A question was raised during the discussion of this signal within the 453 QUIC working group and the QUIC RTT Design Team: does passive RTT 454 measurement pose a privacy risk? The short answer is no 455 [PAM-RTT-PRIVACY]. Normal variations in Internet RTT are great 456 enough that RTT measurements are not useful for geolocation of an 457 endpoint beyond the resolution and error avaiable with even low- 458 quality, freely-available IP address geolocation. In the event that 459 the true endpoint address is not known (for example, in the case of 460 anonymity networks), latency information could be used for 461 deanonymization. However, in this case, the signal will not carry 462 end-to-end RTT, rather exit-to-public-end RTT, as these networks 463 typically terminate transport-layer connections. 465 RTT information may be used to infer the occupancy of queues along a 466 path; indeed, this is part of its utility for performance measurement 467 and diagnostics. When a link on a given path has excessive buffering 468 (on the order of hundreds of milliseconds or more), such that the 469 difference in delay between an empty queue and a full queue dwarfs 470 normal variance and RTT along the path, RTT variance during the 471 lifetime of a flow can be used to infer the presence of traffic on 472 the bottleneck link. In practice, however, this is not a concern for 473 hybrid measurement of congestion-controlled traffic, since any 474 observer in a situation to observe RTT passively need not infer the 475 presence of the traffic, as it can observe it directly. 477 In addition, since RTT information contains application as well as 478 network delay, patterns in RTT variance from minimum, and therefore 479 application delay, can be used to infer or fingerprint application- 480 layer behavior. However, as with the case above, this is not a 481 concern with passive measurement, since the packet size and 482 interarrival time sequence, which is also directly observable, 483 carries more information than RTT variance sequence. 485 We therefore conclude that the high-resolution, per-flow exposure of 486 RTT for passive measurement as provided by this signal poses 487 negligible marginal risk to privacy. 489 Since the hybrid RTT measurement signal is disconnected from 490 transport mechanics, an endpoint implementing the signal that has a 491 model of the actual network RTT and a target RTT to expose can "lie" 492 about its spin bit edges, by anticipating or delaying observed edges, 493 even without coordination with and the collusion of the other 494 endpoint. When passive measurement is used for purposes where one 495 endpoint might gain a material advantage by representing a false RTT, 496 e.g. SLA verification or enforcement of telecommunications 497 regulations, this situation raises a question about the 498 trustworthiness of the RTT measurements produced from this signals 500 This issue must be appreciated by users of information produced from 501 sampling the hybrid RTT measurement signal. In the case of TCP, 502 mitigation is trivial as existing passive measurement methods can be 503 used to verify the operation of the signal. The case of QUIC is 504 harder, as in the general case it is impossible to verify explicit 505 path signals with two complicit endpoints connected via an encrypted 506 channel (see [WIRE-IMAGE]). However, here there are also 507 verification methods possible. A lying server could be contacted by 508 an honest client under the control of a verifying party, and the 509 client's RTT estimate compared with the spin-bit exposed estimate. A 510 server/client pair that collaborate to lie may be subject to dynamic 511 analysis along paths with known RTTs. We consider the ease of 512 verification of lying in situations where this would be prohibited by 513 regulation or contract, combined with the consequences of violation 514 of said regulation or contract, to be a sufficient incentive in the 515 general case not to do it. 517 8. IANA Considerations 519 This document has no current actions for IANA. 521 Should consensus emerge that deployment of the spin bit in TCP is 522 worth pursuing, a companion document submitted to the TCP Maintenance 523 and Minor Extensions (TCPM) Working Group would need to request the 524 following assignments in the IANA TCP Header Flags registry for the 525 purposes of carrying the Spin Bit and Valid Edge Counter on TCP 526 packets: 528 o Bit 4: Hybrid RTT Measurement Spin Bit, as defined in this 529 document 531 o Bit 5: Hybrid RTT Measurement Valid Edge Counter, high-order bit, 532 as defined in this document 534 o Bit 6: Hybrid RTT Measurement Valid Edge Counter, low-order bit, 535 as defined in this document 537 9. Contributors 539 This work is based in part on [QUIC-SPIN], of which it is a 540 generalization. In addition to the editor(s) and author(s) of this 541 document, [QUIC-SPIN] was the work of Piet De Vaere, Roni Even, 542 Giuseppe Fioccola, Thomas Fossati, Marcus Ihlar, Al Morton, and Emile 543 Stephan. 545 10. Acknowledgments 547 Many thanks to Christian Huitema, who originally proposed the spin 548 bit as pull request 609 on [QUIC-TRANSPORT]. Thanks to Tobias 549 Buehler for feedback on the draft, and for Alexandre Ferrieux for 550 input on the Valid Edge Counter. Special thanks to the QUIC RTT 551 Design Team for discussions leading especially to the privacy and 552 security considerations section. 554 This work is partially supported by the European Commission under 555 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 556 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 557 for Education, Research, and Innovation under contract no. 15.0268. 558 This support does not imply endorsement. 560 11. Informative References 562 [CACM-TCP] 563 Strowes, S., "Passively Measuring TCP Round-Trip Times (in 564 Communications of the ACM)", October 2013. 566 [CARRA-RTT] 567 Carra, D., Avrachenkov, K., Alouf, S., Blanc, A., Nain, 568 P., and G. Post, "Passive Online RTT Estimation for Flow- 569 Aware Routers Using One-Way Traffic (NETWORKING 2010, LNCS 570 6091, pp. 109-121)", 2010. 572 [IMC-SPIN] 573 De Vaere, P., Buehler, T., Kuehlewind, M., and B. 574 Trammell, "Three Bits Suffice - Explicit Support for 575 Passive Measurement of Internet Latency in QUIC and TCP 576 (ACM IMC 2018)", November 2018. 578 [IPIM] Allman, M., Beverly, R., and B. Trammell, "Principles for 579 Measurability in Protocol Design (ACM CCR 47(2), pp. 580 2-12)", April 2017. 582 [PAM-RTT-PRIVACY] 583 Trammell, B. and M. Kuehlewind, "Revisiting the Privacy 584 Implications of Two-Way Internet Latency Data (PAM 2018, 585 LNCS 10771, pp. 73-84)", March 2018. 587 [PATH-SIGNALS] 588 Hardie, T., "Transport Protocol Path Signals", draft-iab- 589 path-signals-03 (work in progress), January 2019. 591 [QUIC-SPIN] 592 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 593 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 594 Passive Measurability of Two-Way Latency to the QUIC 595 Transport Protocol", draft-trammell-quic-spin-03 (work in 596 progress), May 2018. 598 [QUIC-SPIN-EXP] 599 Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 600 Bit", draft-ietf-quic-spin-exp-01 (work in progress), 601 October 2018. 603 [QUIC-TRANSPORT] 604 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 605 and Secure Transport", draft-ietf-quic-transport-17 (work 606 in progress), December 2018. 608 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 609 DOI 10.17487/RFC0791, September 1981, 610 . 612 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 613 RFC 793, DOI 10.17487/RFC0793, September 1981, 614 . 616 [RFC6694] Moonesamy, S., Ed., "The "about" URI Scheme", RFC 6694, 617 DOI 10.17487/RFC6694, August 2012, 618 . 620 [RFC7373] Trammell, B., "Textual Representation of IP Flow 621 Information Export (IPFIX) Abstract Data Types", RFC 7373, 622 DOI 10.17487/RFC7373, September 2014, 623 . 625 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 626 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 627 May 2016, . 629 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 630 "Observations on the Dropping of Packets with IPv6 631 Extension Headers in the Real World", RFC 7872, 632 DOI 10.17487/RFC7872, June 2016, 633 . 635 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 636 (IPv6) Specification", STD 86, RFC 8200, 637 DOI 10.17487/RFC8200, July 2017, 638 . 640 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 641 Integrity Signals for Passive Measurement (in Proc. TMA 642 2014)", April 2014. 644 [WIRE-IMAGE] 645 Trammell, B. and M. Kuehlewind, "The Wire Image of a 646 Network Protocol", draft-trammell-wire-image-04 (work in 647 progress), April 2018. 649 [ZANDER-TS] 650 Zander, S. and S. Murdoch, "An Improved Clock-skew 651 Measurement Technique for Revealing Hidden Services 652 (USENIX Security 2008, pp. 211-225)", 2008. 654 Author's Address 656 Brian Trammell (editor) 657 ETH Zurich 659 Email: ietf@trammell.ch