idnits 2.17.1 draft-trammell-tsvwg-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 (July 02, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-iab-path-signals-00 == Outdated reference: A later version (-01) exists of draft-ietf-quic-spin-exp-00 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-13 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG B. Trammell, Ed. 3 Internet-Draft ETH Zurich 4 Intended status: Experimental July 02, 2018 5 Expires: January 3, 2019 7 A Transport-Independent Explicit Signal for Hybrid RTT Measurement 8 draft-trammell-tsvwg-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 January 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 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. Binding the Hybrid RTT Measurement Signal to Transport 61 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Why the transport layer? . . . . . . . . . . . . . . . . 9 66 6. Privacy and Security Considerations . . . . . . . . . . . . . 10 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 70 10. Informative References . . . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 Latency is a key metric to understanding network operation and 76 performance, and passive measurability of round trip times (RTT) is a 77 useful and important, if generally unintentional, feature of many 78 transport protocols. Passive measurement allows inspection of 79 latency on productive traffic, avoiding problems with different 80 treatment of productive and measurement traffic, and enables 81 opportunistic measurement of latency without active measurement 82 overhead. 84 However, since these features are largely accidental, methods for 85 passive latency measurement are transport-dependent, and different 86 heuristics for deriving metrics from these accidental signals may 87 lead to non-comparable values. For example, methods applicable can 88 be exclusively based on the TCP timestamp option [RFC7373] (see 89 [CACM-TCP]), leverage both timestamps and matching sequence and 90 acknowledgment numbers (see [TMA-QOF]), or rely on ACK-clocking in 91 flows transmitting at a stable rate (see [CARRA-RTT]). In addition, 92 they rely on features that may change or have undesirable side 93 effects. For example, [CARRA-RTT] makes implicit assumptions about 94 congestion control and pacing that may not hold for all senders, and 95 timestamp-based methods require the TCP timestamp option to operate 96 effectively, which adds 10 bytes of overhead to every packet and 97 provides a relatively large amount of information for sender 98 fingerprinting [ZANDER-TS]. 100 This document defines a hybrid measurement [RFC7799] path signal 101 [PATH-SIGNALS] to be embedded into a transport layer protocol, 102 explicitly intended for exposing end-to-end RTT to measurement 103 devices on path, following the principles elaborated in [IPIM]. This 104 signal consists of three bits: a spin bit, which oscillates once per 105 end-to-end RTT, and a two-bit Valid Edge Counter (VEC), which 106 compensates for loss and reordering of the spin bit to increase 107 fidelity of the signal in less than ideal network conditions. 109 The document starts with a mechanism applicable to any transport- 110 layer protocol, then explains how to bind the signal to a variety of 111 IETF transport protocols, and describes a measurement methdology for 112 deriving RTT samples from the signal. 114 2. Signal Generation Mechanism 116 The hybrid RTT measurement signal consists of two parts: 118 o a spin bit, which oscillates once per end-to-end RTT. Measuring 119 the time between observed edges in the spin bit therefore provides 120 an RTT sample. 122 o a valid edge counter (VEC), which serves to reject edges in the 123 spin bit signal which are invalid, due to loss, reordering, or 124 delay. 126 This signal is encoded as three bits in the transport-layer header, 127 or as a transport-layer option or extension, and the mechanism for 128 generating these bits consists of a receive-side procedure for 129 updating signal state, and a send-side procedure for encoding the 130 signal on a packet. 132 On receiving a packet on a given connection, the receiver: 134 1. checks to see whether the packet is the latest packet for the 135 connection. If not, it does not update any signal state. The 136 method for determining whether a packet is the latest packet in a 137 connection is necessarily transport-dependent. 139 2. takes the spin bit from the incoming packet and updates its 140 NEXT_SPIN value for the connection. If the receiver was the 141 responder (server) of the connection, it sets NEXT_SPIN to the to 142 the spin bit on the incoming packet. If the receiver was the 143 initiator (client) of the connection, it sets NEXT_SPIN to the 144 inverse of the spin bit on the incoming packet. 146 3. updates its NEXT_VEC value for the connection as follows. If the 147 incoming spin bit value is the same as LAST_SPIN (see below), it 148 sets NEXT_VEC to 0. Otherwise, if the incoming VEC value is 3, 149 it sets NEXT_VEC to 3. Otherwise, it sets NEXT_VEC to the 150 incoming VEC value plus 1. 152 4. stores the value of the incoming spin bit as LAST_RECV_SPIN for 153 subsequent VEC generation. 155 5. stores the time at which this packet was received as RECV_TIME. 157 On sending a packet on a given connection, the sender: 159 1. sets the outgoing spin bit to NEXT_SPIN 161 2. sets the outgoing VEC to 0 if NEXT_SPIN is the same as 162 LAST_SENT_SPIN. Otherwise, it compares the current system time 163 to RECV_TIME. If more than a configurable delay has passed since 164 RECV_TIME, it sets the outgoing VEC to max(NEXT_VEC, 1). 165 Otherwise, it sets the outgoing VEC to NEXT_VEC 167 This mechanism causes the spin bit to oscillate once per round trip 168 time, and the VEC to count up to 3 and hold on each edge on the spin 169 bit signal, in the absence of lost or reordered edges. Delays in 170 sending an edge due to quiescence cause the VEC to reset to 1. 171 Observation points can therefore estimate the end-to-end latency by 172 observing these edges, as described in Section 3. See Section 2.1, 173 below, for an illustration of this mechanism in action. 175 2.1. Illustrating the Mechanism 177 To illustrate the operation of this signal, we consider a simplified 178 model of a single bidirectional path between client and server as a 179 queue with slots for five packets, and assume that both client and 180 server sent packets at a constant rate. If each packet moves one 181 slot in the queue per clock tick, note that this network has a RTT of 182 10 ticks. In the figures below, the signal is shown as two 183 characters. The first denotes the value of the spin bit (^ = 1, v = 184 0), the second the value of the VEC (0-3). - means no packet in 185 flight. 187 Initially, no packets are in flight, so there is no signal, as shown 188 in Figure 1. 190 +--------+ -- -- -- -- -- +--------+ 191 | | -----------> | | 192 | Client | | Server | 193 | | <----------- | | 194 +--------+ -- -- -- -- -- +--------+ 196 Figure 1: Initial state, no packets between client and server 198 The client begins sending packets with the spin bit and VEC set to 199 zero, as shown in Figure 2. 201 +--------+ v0 v0 v0 -- -- +--------+ 202 | | -----------> | | 203 | Client | | Server | 204 | | <----------- | | 205 +--------+ -- -- -- -- -- +--------+ 207 Figure 2: Client begins sending packets 209 The first packet arrives at the server five ticks later. It reflects 210 the spin bit, and increments the VEC on its first packet, as shown in 211 Figure 3. 213 +--------+ v0 v0 v0 v0 v0 +--------+ 214 | | -----------> | | 215 | Client | | Server | 216 | | <----------- | | 217 +--------+ -- -- v1 v0 v0 +--------+ 219 Figure 3: Server reflects first packet, sets edge 221 When the client receives this edge, again five ticks later, it 222 inverts the spin bit and increments the VEC, as shown in Figure 4. 223 In this way, the spin signal begins to oscillate around the path, 224 with one edge in flight at any given time. 226 +--------+ ^0 ^0 ^2 v0 v0 +--------+ 227 | | -----------> | | 228 | Client | | Server | 229 | | <----------- | | 230 +--------+ v0 v0 v0 v0 v0 +--------+ 232 Figure 4: Client inverts spin bit, increments edge 234 And in turn, when this edge reaches the server, the VEC increments 235 again, reaching its stable value of 3, as shown in Figure 5. 237 observation 238 points X Y 239 +--------+ ^0 ^0 ^0 ^0 ^0 +--------+ 240 | | -----------> | | 241 | Client | | Server | 242 | | <----------- | | 243 +--------+ v0 v0 ^3 ^0 ^0 +--------+ 244 Y 246 Figure 5: Server reflects edge, increments VEC 248 Here we can also see how measurement works. An observer watching the 249 signal at single observation point X in Figure 5 will see an edge 250 every 10 ticks, i.e. once per RTT. An observer watching the signal 251 at a symmetric observation point Y in Figure 5 will see a server- 252 client edge 4 ticks after the client-server edge, and a client-server 253 edge 6 ticks after the server-client edge, allowing it to compute the 254 components of RTT between itself and the client and between itself 255 and the server. 257 +--------+ v0 v0 v0 v0 v0 +--------+ 258 | | -----------> | | 259 | Client | | Server | 260 | | <----------- | | 261 +--------+ ^0 v3 ^0 v0 v0 +--------+ 262 packet A C B D E 264 Figure 6: How the VEC detects reordering 266 Figure 6 shows how this mechanism works in the presence of 267 reordering. Here, we assume the transport provides some form of 268 packet sequencing (such as QUIC [QUIC-TRANSPORT] packet numbers or 269 TCP [RFC0793] sequence numbers). Packet C carries the spin edge, and 270 packet B is reordered on the way to the client. In this case, the 271 client will begin sending spin 1 after the arrival of packet C, and 272 ignore the spin bit flip to 1 on packet B, since B < C; i.e. it does 273 not increment the highest packet number seen. An on-path ovserver 274 can also reject the spurious edges carried by packets B and D, even 275 without knowledge of the transport protocol's sequence numbering (or, 276 as is the case with QUIC, when the transport protocol's sequence 277 numbering is encrypted), since the VEC is 0 on these packets. 279 3. Using the Signal for Hybrid RTT Measurement 281 When at least one sender is sending packets at full rate (i.e., is 282 neither application nor flow-control limited), and the other sender 283 is sending at least one packet per RTT (e.g. as is the case with the 284 TCP acknowledgment-only packets on), the spin bit oscillates once per 285 RTT, and the VEC counts up to 3 and holds on the edges in the spin 286 bit (the first packet carrying a new spin bit value in each 287 direction). An on-path observer can observe the time difference 288 between these edges in the spin bit signal in a single direction to 289 measure one sample of end-to-end RTT. Note that this measurement, as 290 with transport-specific passive RTT measurement, includes any 291 transport protocol delay (e.g., delayed sending of acknowledgements) 292 and/or application layer delay (e.g., waiting for a request to 293 complete). These RTT samples can be used 295 The VEC can be used by observers to determine whether an edge in the 296 spin bit signal is valid or not, as follows: 298 o A packet containing an apparent edge in the spin signal with a VEC 299 of 0 is not a valid edge, but may be have been caused by 300 reordering or loss, or was marked as delayed by the sender. It 301 should therefore be ignored. 303 o A packet containing an apparent edge in the spin signal with a VEC 304 of 1 can be used as a left edge (i.e., to start measuring an RTT 305 sample), but not as a right edge (i.e., to take an RTT sample 306 since the last edge). 308 o A packet containing an apparent edge in the spin signal with a VEC 309 of 2 can be used as a left edge, but not as a right edge. If the 310 observation point is symmetric (i.e, it can see both upstream and 311 downstream packets in the flow), the packet can also be used to 312 take a component RTT sample on the segment of the path between the 313 observation point and the direction in which the previous VEC 1 314 edge was seen. 316 o A packet containing an apparent edge in the spin signal with a VEC 317 of 3 can be used as a left edge or right edge, and can be used to 318 compute component RTT in either direction. 320 Taking only valid samples ensures that the RTT estimate provided is 321 accurate. However, in some situations, it may result in a low sample 322 rate. Since the VEC resets to one when a sender determines that its 323 edge is delayed, bursty traffic on one side of the connection will 324 cause the VEC not to count up to 3 very often. Likewise, a 325 connection on which many edges are lost (because the connection 326 itself is very lossy) will cause many samples to be rejected as well. 327 Observers may choose to use heuristics in addition to VEC analysis to 328 increase the sample rate in challenging network or traffic 329 environments. 331 4. Binding the Hybrid RTT Measurement Signal to Transport Protocols 333 The following subsections define how to bind the spin bit to various 334 IETF transport protocols. As of this writing, bindings are specified 335 for QUIC and TCP. 337 4.1. QUIC 339 This signal was originally specified for the QUIC transport protocol 340 [QUIC-TRANSPORT], as the encrypted design of that protocol makes 341 passive RTT measurement impossible. The binding of this signal to 342 QUIC is partially described in [QUIC-SPIN-EXP], which adds the spin 343 bit only (without the VEC) to QUIC for experimentation purposes. 345 The full signal can be added to QUIC by adding the VEC mechanism to 346 the spin bit mechanism already defined in [QUIC-SPIN-EXP], encoding 347 the VEC into QUIC short packet headers using the three bits reserved 348 for that purpose, as shown in Figure 7. 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+ 353 |0|K|1|1|0|S|VEC| 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Destination Connection ID (0..144) ... 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Packet Number (8/16/32) ... 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Protected Payload (*) ... 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 7: QUIC short packet header with spin bit S and VEC 364 The "latest packet" determination for QUIC is made using the QUIC 365 packet number: only packets which have a packet number greater than 366 the highest packet number seen are considered when generating the 367 signal. 369 Note that, when used with QUIC, the signal only appears on short 370 header packets; long header packets are ignored for the purposes of 371 generating the signal. Since either the client or the server may 372 start sending short header packets first, both sides initialize their 373 NEXT_SPIN value to 0. 375 4.2. TCP 377 The signal can be added to TCP by defining bit 4 of bytes 13-14 of 378 the TCP header to carry the spin bit, and bits 5 and 6 to carry the 379 VEC, as shown in Figure 8. 381 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 382 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 383 | | | | R | C | E | U | A | P | R | S | F | 384 | Header Length | S | VEC | s | W | C | R | C | S | S | Y | I | 385 | | | | v | R | E | G | K | H | T | N | N | 386 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 388 Figure 8: Definition bytes 13 and 14 of TCP header with spin bit S 389 and VEC 391 The "latest packet" determination for TCP is made using the TCP 392 sequence and acknowledgment numbers: only packets which have a 393 sequence number greater than highest sequence number seen, accounting 394 for wraparound, or which have a sequence number equal to the last 395 sequence number seen and an acknowledgment number higher than the 396 highest acknowledgment number seen, accounting for wraparound, are 397 considered when generating the signal. 399 Since use of the reserved bits may cause connectivity issues in 400 situations where overzealous interpretation by devices on path of 401 "must be zero" for the reserved bits in byte 13 of the TCP header 402 [RFC0793], the addition of the signal to TCP includes a simple 403 fallback mechanism. The client sets NEXT_SPIN to 1 and NEXT_VEC to 0 404 on its initial SYN. If this SYN is lost, the client disables 405 generation of the signal for the life of the connection. 407 5. Discussion 409 This signal is the result of work carried out in various BoFs and 410 working groups in the IETF. This section attempts to answer 411 questions that have been posed in those contexts about approaches 412 such as that outlined in this document. 414 Additional discussion of privacy and security relevant questions is 415 given in Section 6. 417 5.1. Why the transport layer? 419 As this path signal is (by definition) designed for consumption by 420 devices on the path, and the transport layer is designed for end-to- 421 end operation, an obvious question presents itself: isn't this a 422 layer violation? The answer is both "not really" and "it doesn't 423 matter". 425 The signal defined in this document is designed to measure per- 426 connection, end-to-end RTT. The per-connection nature of the signal 427 leverages the assumption that all packets of a given connection 428 (n-tuple flow, including transport layer ports) will be routed over 429 the same path over a given time interval (on the scale of multiple 430 RTTs) to ensure observability at all points along the path. As it is 431 necessarily a per-connection signal, it is best carried at the 432 transport layer. In addition, the need to reject retransmitted or 433 duplicated packets in the generated signal implies the need for 434 sequence or packet numbering, which is also inherently per- 435 connection, and therefore a transport-layer function. 437 In any case, adding this signal to network layer protocols is 438 unlikely to prove deployable. IPv6 hop-by-hop and destination 439 options [RFC8200] do not work on a significant minority of measured 440 network paths [RFC7872], and IPv4 [RFC0791] options are even less 441 usable. 443 6. Privacy and Security Considerations 445 The privacy considerations for the hybrid RTT measurement signal are 446 essentially the same as those for passive RTT measurement in general. 448 A question was raised during the discussion of this signal within the 449 QUIC working group and the QUIC RTT Design Team: does passive RTT 450 measurement pose a privacy risk? The short answer is no 451 [PAM-RTT-PRIVACY]. Normal variations in Internet RTT are great 452 enough that RTT measurements are not useful for geolocation of an 453 endpoint beyond the resolution and error avaiable with even low- 454 quality, freely-available IP address geolocation. In the event that 455 the true endpoint address is not known (for example, in the case of 456 anonymity networks), latency information could be used for 457 deanonymization. However, in this case, the signal will not carry 458 end-to-end RTT, rather exit-to-public-end RTT, as these networks 459 typically terminate transport-layer connections. 461 RTT information may be used to infer the occupancy of queues along a 462 path; indeed, this is part of its utility for performance measurement 463 and diagnostics. When a link on a given path has excessive buffering 464 (on the order of hundreds of milliseconds or more), such that the 465 difference in delay between an empty queue and a full queue dwarfs 466 normal variance and RTT along the path, RTT variance during the 467 lifetime of a flow can be used to infer the presence of traffic on 468 the bottleneck link. In practice, however, this is not a concern for 469 hybrid measurement of congestion-controlled traffic, since any 470 observer in a situation to observe RTT passively need not infer the 471 presence of the traffic, as it can observe it directly. 473 In addition, since RTT information contains application as well as 474 network delay, patterns in RTT variance from minimum, and therefore 475 application delay, can be used to infer or fingerprint application- 476 layer behavior. However, as with the case above, this is not a 477 concern with passive measurement, since the packet size and 478 interarrival time sequence, which is also directly observable, 479 carries more information than RTT variance sequence. 481 We therefore conclude that the high-resolution, per-flow exposure of 482 RTT for passive measurement as provided by this signal poses 483 negligible marginal risk to privacy. 485 Since the hybrid RTT measurement signal is disconnected from 486 transport mechanics, an endpoint implementing the signal that has a 487 model of the actual network RTT and a target RTT to expose can "lie" 488 about its spin bit edges, by anticipating or delaying observed edges, 489 even without coordination with and the collusion of the other 490 endpoint. When passive measurement is used for purposes where one 491 endpoint might gain a material advantage by representing a false RTT, 492 e.g. SLA verification or enforcement of telecommunications 493 regulations, this situation raises a question about the 494 trustworthiness of the RTT measurements produced from this signals 496 This issue must be appreciated by users of information produced from 497 sampling the hybrid RTT measurement signal. In the case of TCP, 498 mitigation is trivial as existing passive measurement methods can be 499 used to verify the operation of the signal. The case of QUIC is 500 harder, as in the general case it is impossible to verify explicit 501 path signals with two complicit endpoints connected via an encrypted 502 channel (see [WIRE-IMAGE]). However, here there are also 503 verification methods possible. A lying server could be contacted by 504 an honest client under the control of a verifying party, and the 505 client's RTT estimate compared with the spin-bit exposed estimate. A 506 server/client pair that collaborate to lie may be subject to dynamic 507 analysis along paths with known RTTs. We consider the ease of 508 verification of lying in situations where this would be prohibited by 509 regulation or contract, combined with the consequences of violation 510 of said regulation or contract, to be a sufficient incentive in the 511 general case not to do it. 513 7. IANA Considerations 515 This document, if published as an RFC, would request the following 516 assignments in the TCP Header Flags registry for the purposes of this 517 experiment: 519 o Bit 4: Hybrid RTT Measurement Spin Bit, as defined in this 520 document 522 o Bit 5: Hybrid RTT Measurement Valid Edge Counter, high-order bit, 523 as defined in this document 525 o Bit 6: Hybrid RTT Measurement Valid Edge Counter, low-order bit, 526 as defined in this document 528 8. Contributors 530 This work is based in part on [QUIC-SPIN], of which it is a 531 generalization. In addition to the editor(s) and author(s) of this 532 document, [QUIC-SPIN] was the work of Piet De Vaere, Roni Even, 533 Giuseppe Fioccola, Thomas Fossati, Marcus Ihlar, Al Morton, and Emile 534 Stephan. 536 9. Acknowledgments 538 Many thanks to Christian Huitema, who originally proposed the spin 539 bit as pull request 609 on [QUIC-TRANSPORT]. Thanks to Tobias 540 Buehler for feedback on the draft, and for Alexandre Ferrieux for 541 input on the Valid Edge Counter. Special thanks to the QUIC RTT 542 Design Team for discussions leading especially to the privacy and 543 security considerations section. 545 This work is partially supported by the European Commission under 546 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 547 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 548 for Education, Research, and Innovation under contract no. 15.0268. 549 This support does not imply endorsement. 551 10. Informative References 553 [CACM-TCP] 554 Strowes, S., "Passively Measuring TCP Round-Trip Times (in 555 Communications of the ACM)", October 2013. 557 [CARRA-RTT] 558 Carra, D., Avrachenkov, K., Alouf, S., Blanc, A., Nain, 559 P., and G. Post, "Passive Online RTT Estimation for Flow- 560 Aware Routers Using One-Way Traffic (NETWORKING 2010, LNCS 561 6091, pp. 109-121)", 2010. 563 [IPIM] Allman, M., Beverly, R., and B. Trammell, "Principles for 564 Measurability in Protocol Design (ACM CCR 47(2), pp. 565 2-12)", April 2017. 567 [PAM-RTT-PRIVACY] 568 Trammell, B. and M. Kuehlewind, "Revisiting the Privacy 569 Implications of Two-Way Internet Latency Data (PAM 2018, 570 LNCS 10771, pp. 73-84)", March 2018. 572 [PATH-SIGNALS] 573 Hardie, T., "Path Signals", draft-iab-path-signals-00 574 (work in progress), May 2018. 576 [QUIC-SPIN] 577 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 578 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 579 Passive Measurability of Two-Way Latency to the QUIC 580 Transport Protocol", draft-trammell-quic-spin-03 (work in 581 progress), May 2018. 583 [QUIC-SPIN-EXP] 584 Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 585 Bit", draft-ietf-quic-spin-exp-00 (work in progress), 586 April 2018. 588 [QUIC-TRANSPORT] 589 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 590 and Secure Transport", draft-ietf-quic-transport-13 (work 591 in progress), June 2018. 593 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 594 DOI 10.17487/RFC0791, September 1981, 595 . 597 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 598 RFC 793, DOI 10.17487/RFC0793, September 1981, 599 . 601 [RFC7373] Trammell, B., "Textual Representation of IP Flow 602 Information Export (IPFIX) Abstract Data Types", RFC 7373, 603 DOI 10.17487/RFC7373, September 2014, 604 . 606 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 607 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 608 May 2016, . 610 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 611 "Observations on the Dropping of Packets with IPv6 612 Extension Headers in the Real World", RFC 7872, 613 DOI 10.17487/RFC7872, June 2016, 614 . 616 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 617 (IPv6) Specification", STD 86, RFC 8200, 618 DOI 10.17487/RFC8200, July 2017, 619 . 621 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 622 Integrity Signals for Passive Measurement (in Proc. TMA 623 2014)", April 2014. 625 [WIRE-IMAGE] 626 Trammell, B. and M. Kuehlewind, "The Wire Image of a 627 Network Protocol", draft-trammell-wire-image-04 (work in 628 progress), April 2018. 630 [ZANDER-TS] 631 Zander, S. and S. Murdoch, "An Improved Clock-skew 632 Measurement Technique for Revealing Hidden Services 633 (USENIX Security 2008, pp. 211-225)", 2008. 635 Author's Address 637 Brian Trammell (editor) 638 ETH Zurich 640 Email: ietf@trammell.ch