idnits 2.17.1 draft-trammell-quic-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 30, 2017) is 2337 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-13 == Outdated reference: A later version (-18) exists of draft-ietf-quic-manageability-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-07 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 == Outdated reference: A later version (-04) exists of draft-trammell-wire-image-00 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 QUIC B. Trammell, Ed. 3 Internet-Draft P. De Vaere 4 Intended status: Informational ETH Zurich 5 Expires: June 3, 2018 R. Even 6 Huawei 7 G. Fioccola 8 Telecom Italia 9 T. Fossati 10 Nokia 11 M. Ihlar 12 Ericsson 13 A. Morton 14 AT&T Labs 15 E. Stephan 16 Orange 17 November 30, 2017 19 The Addition of a Spin Bit to the QUIC Transport Protocol 20 draft-trammell-quic-spin-00 22 Abstract 24 This document summarizes work to date on the addition of a "spin 25 bit", intended for explicit measurability of end-to-end RTT on QUIC 26 flows. It proposes a detailed mechanism for the spin bit, describes 27 how to use it to measure end-to-end latency, discusses corner cases 28 and workarounds therefor in the measurement, describes experimental 29 evaluation of the mechanism done to date, and examines the utility 30 and privacy implications of the spin bit. As the overhead and risk 31 associated with the spin bit are negligible, and the utility of a 32 passive RTT measurement signal at higher resolution than once per 33 flow is clear, this document advocates for the addition of the spin 34 bit to the protocol. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on June 3, 2018. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. About This Document . . . . . . . . . . . . . . . . . . . 3 72 2. The Spin Bit Mechanism . . . . . . . . . . . . . . . . . . . 3 73 2.1. Proposed Short Header Format Including Spin Bit . . . . . 4 74 3. Using the Spin Bit for Passive RTT Measurement . . . . . . . 4 75 3.1. Limitations and Workarounds . . . . . . . . . . . . . . . 5 76 3.2. Alternate RTT Measurement Approaches for Diagnosing QUIC 77 flows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.3. Experimental Evaluation . . . . . . . . . . . . . . . . . 6 79 4. Use Cases for Passive RTT Measurement . . . . . . . . . . . . 8 80 4.1. Interdomain Troubleshooting . . . . . . . . . . . . . . . 8 81 5. Privacy and Security Considerations . . . . . . . . . . . . . 9 82 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 83 7. Informative References . . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 The QUIC transport protocol [QUIC-TRANS] is a UDP-encapsulated 89 protocol integrated with Transport Layer Security (TLS) [TLS] to 90 encrypt most of its protocol internals, beyond those handshake 91 packets needed to establish or resume a TLS session, and information 92 required to reassemble QUIC streams (the packet number) and to route 93 QUIC packets to the correct machine in a load-balancing situation 94 (the connection ID). In other words, in contrast to TCP, QUIC's wire 95 image (see [WIRE-IMAGE]) exposes much less information about 96 transport protocol state than TCP's wire image. Specifically, the 97 fact that sequence and acknowledgement numbers and timestamps cannot 98 be seen by on-path observes in QUIC as they can be in the TCP means 99 that passive TCP loss and latency measurement techniques that rely on 100 this information (e.g. [CACM-TCP], [TMA-QOF]) cannot be easily 101 ported to work with QUIC. 103 This document proposes a solution to this problem by adding a 104 "latency spin bit" to the QUIC short header. This bit is designed 105 solely for explicit passive measurability of the protocol. It 106 provides one RTT sample per RTT to passive observers of QUIC traffic. 107 It describes the mechanism, how it can be added to QUIC, and how it 108 can be used by passive measurement facilities to generate RTT 109 samples. It explores potential corner cases and shortcomings of the 110 mechanism and how they can be worked around. It summarizes 111 experimental results to date with an implementation of the spin bit 112 built atop a recent QUIC implementation. It additionally describes 113 use cases for passive RTT measurement at the resolution provided by 114 the spin bit. It further reviews findings on privacy risk researched 115 by the QUIC RTT Design Team, which was tasked by the IETF QUIC 116 Working Group to determine the risk/utility tradeoff for the spin 117 bit. 119 The spin bit has low overhead, presents negligible privacy risk, and 120 has clear utility in providing passive RTT measurability of QUIC that 121 is far superior to QUIC's measurability without the spin bit, and 122 equivalent to or better than TCP passive measurability. 124 1.1. About This Document 126 This document is maintained in the GitHub repository 127 https://github.com/britram/draft-trammell-quic-spin, and the editor's 128 copy is available online at https://britram.github.io/draft-trammell- 129 quic-spin. Current open issues on the document can be seen at 130 https://github.com/britram/draft-trammell-quic-spin/issues. Comments 131 and suggestions on this document can be made by filing an issue 132 there, or by contacting the editor. 134 2. The Spin Bit Mechanism 136 The latency spin bit enables latency monitoring from observation 137 points on the network path. The bit is set by the endpoints in the 138 following way: 140 o The server sets the spin bit value to the value of the spin bit in 141 the packet received from the client with the largest packet 142 number. 144 o The client sets the spin bit value to the opposite of the value 145 set in the packet received from the server with the largest packet 146 number, or to 0 if no packet as been received yet. 148 If packets are delivered in order, this procedure will cause the spin 149 bit to change value in each direction once per round trip. 150 Observation points can estimate the network latency by observing 151 these changes in the latency spin bit, as described in Section 3. 153 2.1. Proposed Short Header Format Including Spin Bit 155 Since it is possible to measure handshake RTT without a spin bit (see 156 Section 3.2), it is sufficient to include the spin bit in the short 157 packet header. This proposal suggests to ues the second most 158 significant bit (0x40) of the first octet in the short header for the 159 spin bit. 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+ 164 |0|S|C|K|Type(4)| 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | | 167 + [Connection ID (64)] + 168 | | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Packet Number (8/16/32) ... 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Protected Payload (*) ... 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1: Short Header Format including proposed Spin Bit 177 This will shift the Connection ID flag and the Key Phase Bit to 0x20 178 and 0x10 respectively, and will limit the number of available short 179 packet types to 16. 181 3. Using the Spin Bit for Passive RTT Measurement 183 When a QUIC flow is sending at full rate (i.e., neither application 184 nor flow control limited), the latency spin bit in each direction 185 changes value once per round-trip time (RTT). An on-path observer 186 can observe the time difference between edges in the spin bit signal 187 to measure one sample of end-to-end RTT. Note that this measurement, 188 as with passive RTT measurement for TCP, includes any transport 189 protocol delay (e.g., delayed sending of acknowledgements) and/or 190 application layer delay (e.g., waiting for a request to complete). 191 It therefore provides devices on path a good instantaneous estimate 192 of the RTT as experienced by the application. A simple linear 193 smoothing or moving minimum filter can be applied to the stream of 194 RTT information to get a more stable estimate. 196 We note that the Latency Spin Bit, and the measurements that can be 197 done with it, can be seen as an end-to-end extension of a special 198 case of the alternate marking method described in [ALT-MARK]. 200 3.1. Limitations and Workarounds 202 Application-limited and flow-control-limited senders can have 203 application and transport layer delay, respectively, that are much 204 greater than network RTT. Therefore, the spin bit provides network 205 latency information only when the sender is neither application nor 206 flow control limited. When the sender is application-limited by 207 periodic application traffic, where that period is longer than the 208 RTT, measuring the spin bit provides information about the 209 application period, not the RTT. Simple heuristics based on the 210 observed data rate per flow or changes in the RTT series can be used 211 to reject bad RTT samples due to application or flow control 212 limitation. 214 Since the spin bit logic at each endpoint considers only samples on 215 packets that advance the largest packet number seen, signal 216 generation itself is resistent to reordering. However, reordering 217 can cause problems at an observer by causing spurious edge detection 218 and therefore low RTT estimates. This can be probabilistically 219 mitigated by the observer tracking the low-order bits of the packet 220 number, and rejecting edges that appear out-of-order. 222 3.2. Alternate RTT Measurement Approaches for Diagnosing QUIC flows 224 There are two broad alternatives to explicit signaling for passive 225 RTT measurement for measuring the RTT experienced by QUIC flows. 227 The first of these is handshake RTT measurement. As described in 228 [QUIC-MGT], the packets of the QUIC handshake are distinguishable on 229 the wire in such a way that they can be used for one RTT measurement 230 sample per flow: the delay between the client initial and the server 231 cleartext packet can be used to measure "upstream" RTT (between the 232 observer and the server), and the delay between the server cleartext 233 packet and the next client cleartext packet can be used to measure 234 "downstream" RTT (between the client and the observer). When RTT 235 measurements are used in large aggregates (all flows traversing a 236 large link, for example), a methodology based on handshake RTT could 237 be used to generate sufficient samples for some purposes without the 238 spin bit. 240 However, this methodology would rely on the assumption that the 241 difference between handshake RTT and nominal in-flow RTT is 242 negligible. Specifically, (1) any additional delay required to 243 compute any cryptographic parameters must be negligible with respect 244 to network RTT; (2) any additional delay required to establish state 245 along the path must be negligible with respect to network RTT; and 246 (3) network treatment of initial packets in a flow must identical to 247 that of later packets in the flow. When these assumptions cannot be 248 shown to hold, spin-bit based RTT measurement is preferable to 249 handshake RTT measurement, even for applications for which handshake 250 RTT measurement would otherwise be suitable. 252 The second alternative is parallel active measurement: using ICMP 253 Echo Request and Reply [RFC0792] [RFC4433], a dedicated measurement 254 protocol like TWAMP [RFC5357], or a separate diagnostic QUIC flow to 255 measure RTT. Regardless of protocol, the active measurement must be 256 initiated by a client on the same network as the client of the QUIC 257 flow(s) of interest, or a network close by in the Internet topology, 258 toward the server. Note that there is no guarantee that ICMP flows 259 will receive the same network treatment as the flows under study, 260 both due to differential treatment of ICMP traffic and due to ECMP 261 routing (see e.g. [TOKYO-PING]). TWAMP and QUIC diagnostic flows, 262 though both use UDP, have similar issues regarding ECMP. However, in 263 situations where the entity doing the measurement can guarantee that 264 the active measurement traffic will traverse the subpaths of interest 265 (e.g. residential access network measurement under a network 266 architecture and business model where the network operator owns the 267 CPE), active measurement can be used to generate RTT samples at the 268 cost of at least two non-productive packets sent though the network 269 per sample. 271 3.3. Experimental Evaluation 273 We have evaluated the effectiveness of the spin bit in an emulated 274 network environment. The spin bit was added to a fork of [MINQ], 275 using the mechanism described in Section 2, but with the spin bit 276 appearing in a measurement byte added to the header for passive 277 measurability experiments. Spin bit measurement support was added to 278 [MOKUMOKUREN]. Full results of these ongoing experiments are 279 available online in [SPINBIT-REPORT], but we summarize our findings 280 here. 282 First, we confirm that the spin bit works as advertised: it provides 283 one useful RTT sample per RTT to any passive observer of the flow. 284 This sample tracks each sender's local instantaneous estimate of RTT 285 as well as the expected RTT (i.e., defined by the emulation) fairly 286 well. One surprising implication of this is that the spin bit 287 provides _more_ information than is available by local estimation to 288 an endpoint which is mostly receiving data frames and sending mainly 289 ACKs, and as such can also be useful in purely endpoint-local 290 observations of the RTT evolution during the flow. The spin bit also 291 works correctly under moderate to heavy packet loss and jitter. 293 Second, we confirm that the spin bit can be easily implemented 294 without requiring deep integration into a QUIC implementation. 295 Indeed, it could be implemented completely independently, as a shim, 296 aside from the requirement that the spin bit value be integrity- 297 protected along with the rest of the QUIC header. 299 Third, we performed experiments focused on the intermittent-sender 300 problem described in Section 3.1. We confirm that the spinbit does 301 not provide useful RTT samples after the handshake when packets are 302 only sent intermittently. Simple heuristics can be used to recognize 303 this situation, however, and to reject these RTT samples. We also 304 find that a simple sender-side heuristic can be used to determine 305 whether a sample will be useful. If a sender sends a packet more 306 than a specified delay (e.g. 1ms) after the last packet received by 307 the client, it knows that any latency spin observation of that packet 308 will be invalid. If a second "spin valid" bit were available, the 309 sender could then mark that packet "spin invalid". Our experiments 310 show that this simple heuristic and spin validity bit are succesful 311 in marking all packets whose RTT samples should be rejected. 313 Fourth, we performed experiments focused on the reordering problem 314 described in Section 3.1. We find that while reordering can cause 315 spurious samples at a naive observer, two simple approaches can be 316 used to reject spurious RTT samples due to reordering. First, a two- 317 bit spin signal that always advances in a single direction (e.g. 00 318 -> 01 -> 10 -> 11) successfully rejects all reordered samples, 319 including under amounts of reordering that render the transport 320 itself mostly useless. However, adding a bit is not necessary: 321 having the observer keep the least significant bits of the packet 322 number, and rejecting samples from packets that do not advance by 323 one, as suggested in Section 3.1, is essentially as successful as a 324 two-bit spin signal in mitigating the effects of reordering on RTT 325 measurement. 327 Fifth, we performed parallel active measurements using ping, as 328 described in Section 3.2. In our emulated network, the ICMP packets 329 and the QUIC packets traverse the same links with the same treatment, 330 and share queues at each link, which mitigates most of the issues 331 with ping. We find that while ping works as expected in measuring 332 end-to-end RTT, it does not track the sender's estimate of RTT, and 333 as such does not measure the RTT experienced by the application layer 334 as well as the spin bit does. 336 In summary, our experiments show that the spin bit is suitable for 337 purpose, can be implemented with minimal disruption, and that most of 338 the problems identified with it in specific corner cases can be 339 easily mitigated. See [SPINBIT-REPORT] for more. 341 4. Use Cases for Passive RTT Measurement 343 This section describes use cases for passive RTT measurement. Most 344 of these are currently achieved with TCP, i.e., the matching of 345 packets based on sequence and acknowledgment numbers, or timestamps 346 and timestamp echoes, in order to generate upstream and downstream 347 RTT samples which can be added to get end-to-end RTT. These use 348 cases could be achieved with QUIC by replacing sequence/ 349 acknowledgement and timestamp analysis with spin bit analysis, as 350 described in Section 3. 352 This section currently focuses one initial use case, interdomain 353 troubleshooting. Additional use cases will be added in future 354 revisions; see https://github.com/britram/draft-trammell-spin-bit/ 355 issues for use cases we are currently considering. 357 In any case, the measurement methodology follows one of a few basic 358 variants: 360 o The RTT evolution of a flow or a set of flows can be compared to 361 baseline or expected RTT measurements for flows with the same 362 characterisitcs in order to detect or localize latency issues in a 363 specific network. 365 o The RTT evolution of a single flow can also be examined in detail 366 to diagnose performance issues with that flow. 368 o The spin bit can be used to generate a large number of samples of 369 RTT for a flow aggregate (e.g., all flows between two given 370 networks) without regard to temporal evolution of the RTT, in 371 order to examine the distribution of RTTs for a group of flows 372 that should have similar RTT (e.g., because they should share the 373 same path(s)). 375 4.1. Interdomain Troubleshooting 377 Network access providers are often the first point of contact by 378 their customers when network problems impact the performance of 379 bandwidth-intensive and latency-sensitive applications such as video, 380 regardless of whether the root cause lies within the access 381 provider's network, the service provider's network, on the Internet 382 paths between them, or within the customer's own network. 384 Many residential networks use WiFi (802.11) on the last segment, and 385 WiFi signal strength degradation manifests in high first-hop delay, 386 due to the fact that the MAC layer will retransmit packets lost at 387 that layer. Measuring the RTT between endpoints on the customer 388 network and parts of the service provider's own infrastructure (which 389 have predictable delay characteristics) can be used to isolate this 390 cause of performance problems. 392 Comparing the evolution of passively-measured RTTs between a customer 393 network and selected other networks on the Internet to short- and 394 medium-term baseline measurements can similarly be used to isolate 395 high latency to specific networks or network segments. For example, 396 if the RTTs of all flows to a given content provider increase at the 397 same time, the problem likely exists between the access network and 398 the content provider, or in the content provider's network itself. 399 On the other hand, if the RTTs of all flows passing through the same 400 access provider infrastructure change together, then the change is 401 likely attributable to that infrastructure. 403 These measurements are particularly useful for traffic which is 404 latency sensitive, such as interactive video applications. However, 405 since high latency is often correlated with other network-layer 406 issues such as chronic interconnect congestion [IMC-CONGESTION], it 407 is useful for general troubleshooting of network layer issues in an 408 interdomain setting. 410 In this case, multiple RTT samples per flow are useful less for 411 observing intraflow behavior, and more for generating sufficient 412 samples for a given aggregate to make a high-quality measurement. 414 5. Privacy and Security Considerations 416 The privacy considerations for the latency spin bit are essentially 417 the same as those for passive RTT measurement in general. 419 A concern was raised during the discussion of this feature within the 420 QUIC working group and the QUIC RTT Design Team that high-resolution 421 RTT information might be usable for geolocation. However, an 422 evaluation based on RTT samples taken over 13,780 paths in the 423 Internet from RIPE Atlas anchoring measurements [TRILAT] shows that 424 the magnitude and uncertainty of RTT data render the resolution of 425 geolocation information that can be derived from Internet RTT is 426 limited to national- or continental-scale; i.e., less resolution than 427 is generally available from free, open IP geolocation databases. 429 One reason for the inaccuracy of geolocation from network RTT is that 430 Internet backbone transmission facilities do not follow the great- 431 circle path between major nodes. Instead, major geographic features 432 and the efficiency of connecting adjacent major cities influence the 433 facility routing. An evaluation of ~3500 measurements on a mesh of 434 25 backbone nodes in the continental United States shows that 85% had 435 RTT to great-circle error of 3ms or more, making location within US 436 State boundaries ambigous [CONUS]. 438 Therefore, in the general case, when an endpoint's IP address is 439 known, RTT information provides negligible additional information. 441 RTT information may be used to infer the occupancy of queues along a 442 path; indeed, this is part of its utility for performance measurement 443 and diagnostics. When a link on given path has excessive buffering 444 (on the order of hundreds of milliseconds or more; a situation 445 colloquially referred to as "bufferbloat"), such that the difference 446 in delay between an empty queue and a full queue dwarfs normal 447 variance and RTT along the path, RTT variance during the lifetime of 448 a flow can be used to infer the presence of traffic on the bottleneck 449 link. In practice, however, this is not a concern for passive 450 measurement of congestion-controlled traffic, since any observer in a 451 situation to observe RTT passively need not infer the presence of the 452 traffic, as it can observe it directly. 454 In addition, since RTT information contains application as well as 455 network delay, patterns in RTT variance from minimum, and therefore 456 application delay, can be used to infer or fingerprint application- 457 layer behavior. However, as with the case above, this is not a 458 concern with passive measurement, since the packet size and 459 interarrival time sequence, which is also directly observable, 460 carries more information than RTT variance sequence. 462 We therefore conclude that the high-resolution, per-flow exposure of 463 RTT for passive measurement as provided by the spin bit poses 464 negligible marginal risk to privacy. 466 As shown in Section 2, the spin bit can be implemented separately 467 from the rest of the mechanisms of the QUIC transport protocol, as it 468 requires no access to any state other than that observable in the 469 QUIC packet header itself. We recommend that implementations take 470 advantage of this property, to reduce the risk that a errors in the 471 implementation could leak private transport protocol state through 472 the spin bit. 474 Since the spin bit is disconnected from transport mechanics, a QUIC 475 endpoint implementing the spin bit that has a model of the actual 476 network RTT and a target RTT to expose can "lie" about its spin bit 477 transitions, even without coordination with and the collusion of the 478 other endpoint. This is not the case with TCP, which requires 479 coordination and collusion to expose false information via its 480 sequence and acknowledgment numbers and its timestamp option. When 481 passive measurement is used for purposes where one endpoint might 482 gain a material advantage by representing a false RTT, e.g. SLA 483 verification or enforcement of telecommunications regulations, this 484 situation raises a question about the trustworthiness of spin bit RTT 485 measurements. 487 This issue must be appreciated by users of spin bit information, but 488 mitigation is simple, as QUIC implementations designed to lie about 489 RTT through spin bit modification are subject to dynamic analysis 490 along paths with known RTTs. We consider the ease of verification of 491 lying in situations where this would be prohibited by regulation or 492 contract, combined with the consequences of violation of said 493 regulation or contract, to be a sufficient incentive in the general 494 case not to do it. 496 6. Acknowledgments 498 Many thanks to Christian Huitema, who originally proposed the spin 499 bit as pull request 609 on [QUIC-TRANS]. Thanks to the QUIC RTT 500 Design Team for discussions leading especially to the measurement 501 limitations and privacy and security considerations sections. 503 This work is partially supported by the European Commission under 504 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 505 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 506 for Education, Research, and Innovation under contract no. 15.0268. 507 This support does not imply endorsement. 509 7. Informative References 511 [ALT-MARK] 512 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 513 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 514 "Alternate Marking method for passive and hybrid 515 performance monitoring", draft-ietf-ippm-alt-mark-13 (work 516 in progress), October 2017. 518 [CACM-TCP] 519 Strowes, S., "Passively Measuring TCP Round-Trip Times (in 520 Communications of the ACM)", October 2013. 522 [CONUS] Morton, A., "Comparison of Backbone Node RTT and Great 523 Circle Distances (https://github.com/acmacm/FIXME-TBD)", 524 September 2017. 526 [IMC-CONGESTION] 527 Luckie, M., Dhamdhere, A., Clark, D., Huffaker, B., and k. 528 claffy, "Challenges in Inferring Internet Interdomain 529 Congestion (in Proc. ACM IMC 2014)", November 2014. 531 [MINQ] Rescorla, E., "MINQ, a simple Go implementation of QUIC 532 (https://github.com/ekr/minq)", November 2017. 534 [MOKUMOKUREN] 535 Trammell, B., "Mokumokuren, a lightweight flow meter using 536 gopacket (https://github.com/britram/mokumokuren)", 537 November 2017. 539 [QUIC-MGT] 540 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 541 Transport Protocol", draft-ietf-quic-manageability-01 542 (work in progress), October 2017. 544 [QUIC-TRANS] 545 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 546 and Secure Transport", draft-ietf-quic-transport-07 (work 547 in progress), October 2017. 549 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 550 RFC 792, DOI 10.17487/RFC0792, September 1981, 551 . 553 [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 554 Dynamic Home Agent (HA) Assignment", RFC 4433, 555 DOI 10.17487/RFC4433, March 2006, 556 . 558 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 559 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 560 RFC 5357, DOI 10.17487/RFC5357, October 2008, 561 . 563 [SPINBIT-REPORT] 564 De Vaere, P., "Latency Spinbit Implementation Experience", 565 November 2017. 567 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 568 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 569 July 2017. 571 [TMA-QOF] Trammell, B., Gugelmann, D., and N. Brownlee, "Inline Data 572 Integrity Signals for Passive Measurement (in Proc. TMA 573 2014)", April 2014. 575 [TOKYO-PING] 576 Pelsser, C., Cittadini, L., Vissicchio, S., and R. Bush, 577 "From Paris to Tokyo - On the Suitability of ping to 578 Measure Latency (ACM IMC 2014)", October 2014. 580 [TRILAT] Trammell, B., "On the Suitability of RTT Measurements for 581 Geolocation 582 (https://github.com/britram/trilateration/blob/paper-rev- 583 1/paper.ipynb)", August 2017. 585 [WIRE-IMAGE] 586 Trammell, B. and M. Kuehlewind, "The Wire Image of a 587 Network Protocol", draft-trammell-wire-image-00 (work in 588 progress), November 2017. 590 Authors' Addresses 592 Brian Trammell (editor) 593 ETH Zurich 595 Email: ietf@trammell.ch 597 Piet De Vaere 598 ETH Zurich 600 Email: piet@devae.re 602 Roni Even 603 Huawei 605 Email: roni.even@huawei.com 607 Giuseppe Fioccola 608 Telecom Italia 610 Email: giuseppe.fioccola@telecomitalia.it 612 Thomas Fossati 613 Nokia 615 Email: thomas.fossati@nokia.com 616 Marcus Ihlar 617 Ericsson 619 Email: marcus.ihlar@ericsson.com 621 Al Morton 622 AT&T Labs 624 Email: acmorton@att.com 626 Emile Stephan 627 Orange 629 Email: emile.stephan@orange.com