idnits 2.17.1 draft-cfb-ippm-spinbit-new-measurements-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 abstract seems to contain references ([I-D.trammell-ippm-spin]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 28, 2019) is 1882 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-18 ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group M. Cociglio 3 Internet-Draft Telecom Italia 4 Intended status: Experimental G. Fioccola 5 Expires: September 1, 2019 Huawei Technologies 6 F. Bulgarella 7 R. Sisto 8 Politecnico di Torino 9 February 28, 2019 11 New Spin bit enabled measurements with one or two more bits 12 draft-cfb-ippm-spinbit-new-measurements-00 14 Abstract 16 This document introduces additional measurements by using the same 17 spin bit signal as defined in [I-D.trammell-ippm-spin]. The spin bit 18 signal alone is not enough to evaluate correctly in every network 19 condition the RTT of a flow. In order to solve this problem, it is 20 theorized the possibility of introducing an additional validation 21 signal called delay bit, similar to what is done done by the Valid 22 Edge Counter (VEC), but using just one bit instead of two. An 23 alternative with two bits is also introduced with a so called loss 24 bit. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 1, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Spin bit and Delay bit mechanism . . . . . . . . . . . . . . 3 68 2.1. Delay Sample generation . . . . . . . . . . . . . . . . . 5 69 2.1.1. The recovery process . . . . . . . . . . . . . . . . 5 70 2.2. Delay Sample reflection . . . . . . . . . . . . . . . . . 6 71 3. Using the Spin bit and Delay bit for Hybrid RTT Measurement . 7 72 3.1. End-to-end RTT measurement . . . . . . . . . . . . . . . 7 73 3.2. Half-RTT measurement . . . . . . . . . . . . . . . . . . 7 74 3.3. Intra-domain RTT measurement . . . . . . . . . . . . . . 7 75 4. Observer's algorithm and Waiting Interval . . . . . . . . . . 8 76 5. Adding a Loss bit to Delay bit and Spin bit . . . . . . . . . 9 77 5.1. Round Trip Packet Loss measurement . . . . . . . . . . . 9 78 6. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 10.2. Informative References . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 [I-D.trammell-ippm-spin] defines an explicit per-flow transport-layer 92 signal for hybrid measurement of end-to-end RTT. This signal 93 consists of three bits: a spin bit, which oscillates once per end-to- 94 end RTT, and a two-bit Valid Edge Counter (VEC), which compensates 95 for loss and reordering of the spin bit to increase fidelity of the 96 signal in less than ideal network conditions. 98 In this document it is introduced the delay bit, that is a single bit 99 signal that can be used together with the spin bit by passive 100 observers to measure the RTT of a network flow, avoiding the spin bit 101 ambiguities that arise as soon as network conditions deteriorate. 102 Unlike the spin bit, which is actually set in every packet 103 transmitted on the network, the delay bit is set only once per round 104 trip. 106 This document defines a hybrid measurement RFC 7799 [RFC7799] path 107 signal to be embedded into a transport layer protocol, explicitly 108 intended for exposing end-to-end RTT to measurement devices on path. 110 The document introduces a mechanism applicable to any transport-layer 111 protocol, then explains how to bind the signal to a variety of IETF 112 transport protocols, and in particular to QUIC and TCP. 114 The application of the Spin bit to QUIC is described in 115 [I-D.ietf-quic-spin-exp] which adds the spin bit only (without the 116 VEC) to QUIC for experimentation purposes. 118 Note that both the spin bit and the delay bit are inspired by RFC 119 8321 [RFC8321]. This is also mentioned in [I-D.trammell-quic-spin]. 121 2. Spin bit and Delay bit mechanism 123 The main idea is to have a single packet, with a second marked bit 124 (the delay bit), that bounces between client and server during the 125 entire connection life. This single packet is called Delay Sample. 127 A simple observer placed in an intermediate point, tracking the delay 128 sample and the relative timestamp in every spin bit period, can 129 measure the end-to-end round trip delay of the connection. In the 130 same way as seen with the spin bit and the VEC, it is possible to 131 carry out other types of measurements. The next paragraphs give an 132 overview of the observer capabilities. 134 In order to describe the delay sample working mechanism in detail, we 135 have to distinguish two different phases which take part in the delay 136 bit lifetime: initialization and reflection. The initialization is 137 the generation of the delay sample, while the reflection realizes the 138 bounce behavior of this single packet between the two endpoints. 140 The next figure describes the Delay bit mechanism: the first bit is 141 the spin bit and the second one is the delay bit. 143 +--------+ -- -- -- -- -- +--------+ 144 | | -----------> | | 145 | Client | | Server | 146 | | <----------- | | 147 +--------+ -- -- -- -- -- +--------+ 149 (a) No traffic at beginning. 151 +--------+ 00 00 01 -- -- +--------+ 152 | | -----------> | | 153 | Client | | Server | 154 | | <----------- | | 155 +--------+ -- -- -- -- -- +--------+ 157 (b) The Client starts sending data and 158 sets the first packet as Delay Sample. 160 +--------+ 00 00 00 00 00 +--------+ 161 | | -----------> | | 162 | Client | | Server | 163 | | <----------- | | 164 +--------+ -- -- 01 00 00 +--------+ 166 (c) The Server starts sending data 167 and reflects the Delay Sample. 169 +--------+ 10 10 11 00 00 +--------+ 170 | | -----------> | | 171 | Client | | Server | 172 | | <----------- | | 173 +--------+ 00 00 00 00 00 +--------+ 175 (d) The Client inverts the spin bit and 176 reflects the Delay Sample. 178 +--------+ 10 10 10 10 10 +--------+ 179 | | -----------> | | 180 | Client | | Server | 181 | | <----------- | | 182 +--------+ 00 00 11 10 10 +--------+ 184 (e) The Server reflects the Delay Sample. 186 +--------+ 00 00 01 10 10 +--------+ 187 | | -----------> | | 188 | Client | | Server | 189 | | <----------- | | 190 +--------+ 10 10 10 10 10 +--------+ 191 (f) The client reverts the spin 192 bit and reflects the Delay Sample. 194 Figure 1: Spin bit and Delay bit 196 2.1. Delay Sample generation 198 During this first phase, endpoints play different roles. First of 199 all a single delay sample must be bouncing per round trip period (and 200 so per spin bit period). According to that statement and in order to 201 simplify the general algorithm, the delay sample generation is in 202 charge of just one of the two endpoints: 204 o the Client, when connection starts and spin bit is set to 0, 205 initializes the delay bit of the first packet to 1, so it becomes 206 the delay sample for that marking period. Only this packet is 207 marked with the delay bit set to 1 for this round trip period; the 208 other ones will carry only the spin bit; 210 o the server never initializes the delay bit to 1; its only task is 211 to reflect the incoming delay bit into the next outgoing packet 212 only if certain conditions occur. 214 Theoretically, in absence of network impairments, the delay sample 215 should bounce between client and server continuously, for the entire 216 duration of the connection. Actually, that is highly unlikely mainly 217 for two different reasons: 219 1) the packet carrying the delay bit might be lost during its journey 220 on the network which is unreliable by definition; 222 2) one of the two endpoints could stop or delay sending data because 223 the application is limiting the amount of traffic transmitted; 225 To deal with these problems, the algorithm provides a procedure to 226 regenerate the delay sample and to inform a possible observer that a 227 problem has occurred, and then the measurement has to be restarted. 229 2.1.1. The recovery process 231 In order to relieve the server from tasks that go beyond the mere 232 reflection of the sample, even in this case the recovery process 233 belongs to the client. A fundamental assumption is that a delay 234 sample is strictly related to its spin bit period. Considering this 235 rule, the client verifies that every spin bit period ends with its 236 delay sample. If that does not happen and a marking period 237 terminates without a delay sample, the client waits a further empty 238 period; then, in the following period, it reinitializes the mechanism 239 by setting the delay bit of the first outgoing packet to 1, making it 240 the new delay sample. The empty period is needed to inform the 241 intermediate points that there was an issue and a new delay 242 measurement session is starting. 244 2.2. Delay Sample reflection 246 The reflection is the process that enables the bouncing of the delay 247 sample between client and server. The behavior of the two endpoints 248 is slightly different. With the exception of the client that, as 249 previously exposed, generates a new delay sample, by default the 250 delay bit is set to 0. 252 Server side reflection: when a packet with the delay bit set to 1 253 arrives, the server marks the first packet in the opposite direction 254 as the delay sample, if it has the same spin bit value. While if it 255 has the opposite spin bit value this sample is considered lost. 257 Client side reflection: when a packet with delay bit set to 1 258 arrives, the client marks the first packet in the opposite direction 259 as the delay sample, if it has the opposite spin bit value. While if 260 it has the same spin bit value this sample is considered lost. 262 In both cases, if the outgoing marked packet is transmitted with a 263 delay greater than a predetermined threshold after the reception of 264 the incoming delay sample (1ms by default), reflection is aborted and 265 this sample is considered lost. 267 It is noteworthy that differently from what happens with the VEC for 268 which the reflection always concerns the edge of the period, in this 269 case reflection takes place for the packet that is carrying the delay 270 bit regardless of its position within the period. For this reason it 271 is necessary to introduce that condition of validation in order to 272 identify and discard those samples that, due to reordering, might 273 move to a contiguous period. Furthermore, by introducing a threshold 274 for the retransmission delay of the sample, it is possible to 275 eliminate all those measurements which, due to lack of traffic on the 276 endpoints, would be overestimated and not true. Thus, the maximum 277 estimation error, without considering any other delays due to flow 278 control, would amount to twice the threshold (e.g. 2ms) per 279 measurement, in the worst case. 281 3. Using the Spin bit and Delay bit for Hybrid RTT Measurement 283 Unlike what happens with the spin bit for which it is necessary to 284 validate or at least heuristically evaluate the goodness of an edge, 285 the delay sample can be used by an intermediate observer as a simple 286 demarcator between a period and the following one eliminating the 287 ambiguities on the calculation of the RTT found with the analysis of 288 the spin-bit only. The measurement types, that can be done from the 289 observation of the delay sample, are exactly the same achievable with 290 the spin bit only (with or without the VEC). 292 3.1. End-to-end RTT measurement 294 The delay sample generation process ensures that only one packet 295 marked with the delay bit set to 1 runs back and forth on the wire 296 between two endpoints per round trip time. Therefore, in order to 297 determine the end-to-end RTT measurement of a QUIC flow, an on-path 298 passive observer can simply compute the time difference between two 299 delay samples observed in a single direction. Note that a 300 measurement, to be valid, must take into account the difference in 301 time between the timestamps of two consecutive delay samples 302 belonging to adjacent spin-bit periods. For this reason, an 303 observer, in addition to intercepting and analyzing the packets 304 containing the delay bit set to 1, must maintain awareness of each 305 spin period in such a way as to be able to assign each delay sample 306 to its period and, at the same time, identifying those periods that 307 do not contain it. 309 3.2. Half-RTT measurement 311 An on-path passive observer that is sniffing traffic in both 312 directions -- from client to server and from server to client -- can 313 also use the delay sample to measure "upstream" and "downstream" RTT 314 components. Also known as the half-RTT measurement, it represents 315 the components of the end-to-end RTT concerning the paths between the 316 client and the observer (upstream), and the observer and the server 317 (downstream). It does this by measuring the delay between a delay 318 sample observed in the downstream direction and the one observed in 319 the upstream direction, and vice versa. Also in this case, it should 320 verify that the two delay samples belong to two adjacent periods, for 321 the upstream component, or to the same period for the downstream 322 component. 324 3.3. Intra-domain RTT measurement 326 Taking advantage of the half-RTT measurements it is also possible to 327 calculate the intra-domain RTT which is the portion of the entire RTT 328 used by a QUIC flow to traverse the network of a provider (or part of 329 it). To achieve this result two observers, able to watch traffic in 330 both directions, must be employed simultaneously at ingress and 331 egress of the network to be measured. At this point, to determine 332 the delay between the two observers, it is enough to subtract the two 333 computed upstream (or downstream) RTT components. 335 4. Observer's algorithm and Waiting Interval 337 Given below is a formal summary of the functioning of the observer 338 every time a delay sample is detected. A packet containing the delay 339 bit set to 1: 341 o if it has the same spin bit value of the current period and no 342 delay sample was detected in the previous period, then it can be 343 used as a left edge (i.e., to start measuring an RTT sample), but 344 not as a right edge (i.e., to complete and RTT measurement since 345 the last edge). If the observation point is symmetric (i.e., it 346 can see both upstream and downstream packets in the flow) and in 347 the current period a delay sample was detected in the opposite 348 direction (i.e., in the upstream direction), the packet can also 349 be used to compute the downstream RTT component. 351 o if it has the same spin bit value of the current period and a 352 delay sample was detected in the previous period, then it can be 353 used at the same time as a left or right edge, and to compute RTT 354 component in both directions. 356 Like stated previously, every time an empty period is detected, the 357 observer must restart the measurement process and consider the next 358 delay sample that will come as the beginning of a new measure, then 359 as a left edge. As a result, being able to assign the delay sample 360 to the corresponding spin period becomes a crucial factor for the 361 proper functioning of the entire algorithm. 363 Considering that the division into periods is realized by exploiting 364 the spin bit square wave, it is easy to understand that the presence 365 of spurious spin edges -- caused by packet reordering -- would 366 inevitably lead the observer to overestimate the amount of periods 367 actually present in the transmission. This results in a greater 368 number of empty periods detected and the consequent decrease of the 369 actual RTT samples achievable. Therefore, in order to maximize the 370 performance of the whole algorithm, the observer must implement a 371 mechanism to filter out spurious spin edges. 373 To face this problem the waiting interval has to be introduced. 374 Basically, every time a spin bit edge is detected, the observer sets 375 a time interval during which it rejects every potential spurious 376 edges observed on the wire. While, at the end of the interval it 377 starts again to accept changes in the spin bit value. This 378 guarantees a proper protection against the spurious edges in relation 379 to the size of the interval itself. For instance, an interval of 5ms 380 is able to filter out edges that have been reordered by a maximum of 381 5ms. Clearly, the mechanism does its job for intervals smaller than 382 the RTT of the observed connection (if RTT is smaller than the 383 waiting interval the observer can't measure the RTT). 385 5. Adding a Loss bit to Delay bit and Spin bit 387 It is possible to introduce a mechanism to evaluate also the packet 388 loss together with the delay measurement. In particular, the Client 389 can select and mark a train of packets for this purpose, by using a 390 loss bit, additionally to the spin bit and delay bit. 392 These packets bounce between Client and Server to complete two rounds 393 and an Observer counts the marked packets during the two rounds and 394 compares the counters to find Round Trip(RT) losses. 396 The problem to be solved is to choose the right number of packets to 397 mark to avoid marked packets congestion on the slowest traffic 398 direction. But the solution is simple, because it is enough to 399 choose the number of packets that transit on the slowest direction 400 during an RTT. 402 5.1. Round Trip Packet Loss measurement 404 The Client generates a train of marked packets (Packet Loss Samples) 405 by using the additional bit called Loss bit. The marked packets are 406 generated at the slowest direction rate (only when a packet arrives 407 the Client marks an outgoing packet). The Server reflects these 408 packets accordingly and, as a consequence, it could insert some not- 409 marked packets. Then the client reflects the marked packets and the 410 server reflects the marked packets again. The Client generates a new 411 train of marked packets and so on. 413 The Packet Loss calculation can be made after the comparison of 414 counters taken by the on-path passive observer. Indeed the Observer 415 in the middle (upstream or downstream) sees the packet train twice 416 and so it calculates the Observer Round Trip Packet Loss that, 417 statistically, will be equal to the end-to-end Round Trip Packet 418 Loss. So this measurement can be simply referred as Round Trip 419 Packet Loss (RTPL). 421 In addition, this methodology allows Half-RTPL measurement and Intra- 422 domain RTPL measurement, in the same way as described in the previous 423 Sections for RTT measurement. 425 The method allows the packet loss calculation for a portion of the 426 traffic but it is useful to perform RT Packet Loss measurement that 427 gives useful information coupled with RTT. 429 6. Protocols 431 6.1. QUIC 433 The binding of this signal to QUIC is partially described in 434 [I-D.ietf-quic-spin-exp], which adds the spin bit only to QUIC. 436 From an implementation point of view, the delay bit is placed in the 437 partially unencrypted (but authenticated) QUIC header, alongside the 438 spin bit, occupying one of the two bits left reserved for future 439 experiments. As things stand, according to 440 [I-D.ietf-quic-transport], the proposed scheme of the first header's 441 byte would be 01SDRKPP. 443 6.2. TCP 445 The signal can be added to TCP by defining bit 4 of bytes 13-14 of 446 the TCP header to carry the spin bit, and eventually bits 5 and 6 to 447 carry additional information, like the delay bit and the loss bit. 449 7. Security Considerations 451 The privacy considerations for the hybrid RTT measurement signal are 452 essentially the same as those for passive RTT measurement in general. 454 8. Acknowledgements 456 tbc 458 9. IANA Considerations 460 tbc 462 10. References 464 10.1. Normative References 466 [I-D.ietf-quic-spin-exp] 467 Trammell, B. and M. Kuehlewind, "The QUIC Latency Spin 468 Bit", draft-ietf-quic-spin-exp-01 (work in progress), 469 October 2018. 471 [I-D.ietf-quic-transport] 472 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 473 and Secure Transport", draft-ietf-quic-transport-18 (work 474 in progress), January 2019. 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 482 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 483 May 2016, . 485 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 486 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 487 "Alternate-Marking Method for Passive and Hybrid 488 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 489 January 2018, . 491 10.2. Informative References 493 [I-D.trammell-ippm-spin] 494 Trammell, B., "An Explicit Transport-Layer Signal for 495 Hybrid RTT Measurement", draft-trammell-ippm-spin-00 (work 496 in progress), January 2019. 498 [I-D.trammell-quic-spin] 499 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 500 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 501 Passive Measurability of Two-Way Latency to the QUIC 502 Transport Protocol", draft-trammell-quic-spin-03 (work in 503 progress), May 2018. 505 Authors' Addresses 507 Mauro Cociglio 508 Telecom Italia 509 Via Reiss Romoli, 274 510 Torino 10148 511 Italy 513 Email: mauro.cociglio@telecomitalia.it 514 Giuseppe Fioccola 515 Huawei Technologies 516 Riesstrasse, 25 517 Munich 80992 518 Germany 520 Email: giuseppe.fioccola@huawei.com 522 Fabio Bulgarella 523 Politecnico di Torino 525 Email: fabio.bulgarella@guest.telecomitalia.it 527 Riccardo Sisto 528 Politecnico di Torino 529 Corso Duca degli Abruzzi, 24 530 Torino 10129 531 Italy 533 Email: riccardo.sisto@polito.it