idnits 2.17.1 draft-ietf-ippm-explicit-flow-measurements-01.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 (May 5, 2022) is 714 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-18 == Outdated reference: A later version (-03) exists of draft-ietf-ippm-rfc8321bis-01 == Outdated reference: A later version (-17) exists of draft-ietf-6man-ipv6-alt-mark-14 == Outdated reference: A later version (-18) exists of draft-ietf-quic-manageability-16 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-18 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM M. Cociglio 3 Internet-Draft Telecom Italia - TIM 4 Intended status: Informational A. Ferrieux 5 Expires: November 6, 2022 Orange Labs 6 G. Fioccola 7 Huawei Technologies 8 I. Lubashev 9 Akamai Technologies 10 F. Bulgarella 11 Telecom Italia - TIM 12 I. Hamchaoui 13 Orange Labs 14 M. Nilo 15 Telecom Italia - TIM 16 R. Sisto 17 Politecnico di Torino 18 D. Tikhonov 19 LiteSpeed Technologies 20 May 5, 2022 22 Explicit Flow Measurements Techniques 23 draft-ietf-ippm-explicit-flow-measurements-01 25 Abstract 27 This document describes protocol independent methods called Explicit 28 Flow Measurement Techniques that employ few marking bits, inside the 29 header of each packet, for loss and delay measurement. The 30 endpoints, marking the traffic, signal these metrics to intermediate 31 observers allowing them to measure connection performance, and to 32 locate the network segment where impairments happen. Different 33 alternatives are considered within this document. These signaling 34 methods apply to all protocols but they are especially valuable when 35 applied to protocols that encrypt transport header and do not allow 36 traditional methods for delay and loss detection. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on November 6, 2022. 55 Copyright Notice 57 Copyright (c) 2022 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Latency Bits . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Spin Bit . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2.2. Delay Bit . . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.2.1. Generation Phase . . . . . . . . . . . . . . . . . . 8 77 2.2.2. Reflection Phase . . . . . . . . . . . . . . . . . . 8 78 2.2.3. T_Max Selection . . . . . . . . . . . . . . . . . . . 9 79 2.2.4. Delay Measurement Using Delay Bit . . . . . . . . . . 10 80 2.2.4.1. RTT Measurement . . . . . . . . . . . . . . . . . 10 81 2.2.4.2. Half-RTT Measurement . . . . . . . . . . . . . . 10 82 2.2.4.3. Intra-Domain RTT Measurement . . . . . . . . . . 11 83 2.2.5. Observer's Algorithm . . . . . . . . . . . . . . . . 12 84 2.2.6. Two Bits Delay Measurement: Spin Bit + Delay Bit . . 13 85 2.2.7. Hidden Delay Bit - Delay Bit with Privacy Protection 13 86 3. Loss Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 3.1. T Bit - Round Trip Loss Bit . . . . . . . . . . . . . . . 14 88 3.1.1. Round Trip Loss . . . . . . . . . . . . . . . . . . . 15 89 3.1.2. Setting the Round Trip Loss Bit on Outgoing Packets . 16 90 3.1.3. Observer's Logic for Round Trip Loss Signal . . . . . 18 91 3.1.4. Loss Coverage and Signal Timing . . . . . . . . . . . 18 92 3.2. Q Bit - sQuare Bit . . . . . . . . . . . . . . . . . . . 19 93 3.2.1. Q Block Length Selection . . . . . . . . . . . . . . 19 94 3.2.2. Upstream Loss . . . . . . . . . . . . . . . . . . . . 20 95 3.2.3. Identifying Q Block Boundaries . . . . . . . . . . . 20 96 3.2.3.1. Improved Resilience to Burst Losses . . . . . . . 21 97 3.3. L Bit - Loss Event Bit . . . . . . . . . . . . . . . . . 21 98 3.3.1. End-To-End Loss . . . . . . . . . . . . . . . . . . . 22 99 3.3.1.1. Loss Profile Characterization . . . . . . . . . . 22 100 3.3.2. L+Q Bits - Loss Measurement Using L and Q Bits . . . 22 101 3.3.2.1. Correlating End-to-End and Upstream Loss . . . . 23 102 3.3.2.2. Downstream Loss . . . . . . . . . . . . . . . . . 23 103 3.3.2.3. Observer Loss . . . . . . . . . . . . . . . . . . 24 104 3.4. R Bit - Reflection Square Bit . . . . . . . . . . . . . . 24 105 3.4.1. Enhancement of R Block Length Computation . . . . . . 25 106 3.4.2. Improved Resilience to Packet Reordering . . . . . . 26 107 3.4.2.1. Improved Resilience to Burst Losses . . . . . . . 26 108 3.4.3. R+Q Bits - Loss Measurement Using R and Q Bits . . . 26 109 3.4.3.1. Three-Quarters Connection Loss . . . . . . . . . 27 110 3.4.3.2. End-To-End Loss in the Opposite Direction . . . . 27 111 3.4.3.3. Half Round-Trip Loss . . . . . . . . . . . . . . 28 112 3.4.3.4. Downstream Loss . . . . . . . . . . . . . . . . . 29 113 3.5. E Bit - ECN-Echo Event Bit . . . . . . . . . . . . . . . 29 114 3.5.1. Setting the ECN-Echo Event Bit on Outgoing Packets . 29 115 3.5.2. Using E Bit for Passive ECN-Reported Congestion 116 Measurement . . . . . . . . . . . . . . . . . . . . . 30 117 4. Summary of Delay and Loss Marking Methods . . . . . . . . . . 30 118 5. Protocol Ossification Considerations . . . . . . . . . . . . 32 119 6. Examples of Application . . . . . . . . . . . . . . . . . . . 33 120 6.1. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 33 121 6.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 122 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 123 7.1. Optimistic ACK Attack . . . . . . . . . . . . . . . . . . 35 124 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 125 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 126 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 127 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 128 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 129 12.1. Normative References . . . . . . . . . . . . . . . . . . 36 130 12.2. Informative References . . . . . . . . . . . . . . . . . 37 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 133 1. Introduction 135 Packet loss and delay are hard and pervasive problems of day-to-day 136 network operation. Proactively detecting, measuring, and locating 137 them is crucial to maintaining high QoS and timely resolution of 138 crippling end-to-end throughput issues. To this effect, in a TCP- 139 dominated world, network operators have been heavily relying on 140 information present in the clear in TCP headers: sequence and 141 acknowledgment numbers and SACKs when enabled (see [RFC8517]). These 142 allow for quantitative estimation of packet loss and delay by passive 143 on-path observation. Additionally, the problem can be quickly 144 identified in the network path by moving the passive observer around. 146 With encrypted protocols, the equivalent transport headers are 147 encrypted and passive packet loss and delay observations are not 148 possible, as described in [RFC9065]. 150 Measuring TCP loss and delay between similar endpoints cannot be 151 relied upon to evaluate encrypted protocol loss and delay. Different 152 protocols could be routed by the network differently, and the 153 fraction of Internet traffic delivered using protocols other than TCP 154 is increasing every year. It is imperative to measure packet loss 155 and delay experienced by encrypted protocol users directly. 157 This document defines Explicit Flow Measurement Techniques. These 158 hybrid measurement path signals (see [IPM-Methods]) are to be 159 embedded into a transport layer protocol and are explicitly intended 160 for exposing RTT and loss rate information to on-path measurement 161 devices. They are designed to facilitate network operations and 162 management and are "beneficial" for maintaining the quality of 163 service (see [RFC9065]). These measurement mechanisms are applicable 164 to any transport-layer protocol, and, as an example, the document 165 describes QUIC and TCP bindings. 167 The Explicit Flow Measurement Techniques described in this document 168 can be used alone or in combination with other Explicit Flow 169 Measurement Techniques. Each technique uses a small number of bits 170 and exposes a specific measurement. 172 Following the recommendation in [RFC8558] of making path signals 173 explicit, this document proposes adding a small number of dedicated 174 measurement bits to the clear portion of the protocol headers. These 175 bits can be added to an unencrypted portion of a header belonging to 176 any protocol layer, e.g. IP (see [IP]) and IPv6 (see [IPv6]) headers 177 or extensions, such as [IPv6AltMark], UDP surplus space (see 178 [UDP-OPTIONS] and [UDP-SURPLUS]), reserved bits in a QUIC v1 header, 179 as already done with the latency Spin bit (see [QUIC-TRANSPORT]). 181 The measurements are not designed for use in automated control of the 182 network in environments where signal bits are set by untrusted hosts. 183 Instead, the signal is to be used for troubleshooting individual 184 flows as well as for monitoring the network by aggregating 185 information from multiple flows and raising operator alarms if 186 aggregate statistics indicate a potential problem. 188 The Spin bit, Delay bit and loss bits explained in this document are 189 inspired by [AltMark], [SPIN-BIT], [I-D.trammell-tsvwg-spin] and 190 [I-D.trammell-ippm-spin]. 192 Additional details about the Performance Measurements for QUIC are 193 described in the paper [ANRW19-PM-QUIC]. 195 2. Latency Bits 197 This section introduces bits that can be used for round trip latency 198 measurements. Whenever this section of the specification refers to 199 packets, it is referring only to packets with protocol headers that 200 include the latency bits. 202 [QUIC-TRANSPORT] introduces an explicit per-flow transport-layer 203 signal for hybrid measurement of RTT. This signal consists of a Spin 204 bit that toggles once per RTT. [SPIN-BIT] discusses an additional 205 two-bit Valid Edge Counter (VEC) to compensate for loss and 206 reordering of the Spin bit and increase fidelity of the signal in 207 less than ideal network conditions. 209 This document introduces a stand-alone single-bit delay signal that 210 can be used by passive observers to measure the RTT of a network 211 flow, avoiding the Spin bit ambiguities that arise as soon as network 212 conditions deteriorate. 214 2.1. Spin Bit 216 This section is a small recap of the Spin bit working mechanism. For 217 a comprehensive explanation of the algorithm, please see [SPIN-BIT]. 219 The Spin bit is an alternate marking [AltMark] generated signal, 220 where the size of the alternation changes with the flight size each 221 RTT. 223 The latency Spin bit is a single bit signal that toggles once per 224 RTT, enabling latency monitoring of a connection-oriented 225 communication from intermediate observation points. 227 A "spin period" is a set of packets with the same Spin bit value sent 228 during one RTT time interval. A "spin period value" is the value of 229 the Spin bit shared by all packets in a spin period. 231 The client and server maintain an internal per-connection spin value 232 (i.e. 0 or 1) used to set the Spin bit on outgoing packets. Both 233 endpoints initialize the spin value to 0 when a new connection 234 starts. Then: 236 - when the client receives a packet with the packet number larger 237 than any number seen so far, it sets the connection spin value to 238 the opposite value contained in the received packet; 240 - when the server receives a packet with the packet number larger 241 than any number seen so far, it sets the connection spin value to 242 the same value contained in the received packet. 244 The computed spin value is used by the endpoints for setting the spin 245 bit on outgoing packets. This mechanism allows the endpoints to 246 generate a square wave such that, by measuring the distance in time 247 between pairs of consecutive edges observed in the same direction, a 248 passive on-path observer can compute the round trip delay of that 249 network flow. 251 Spin bit enables round trip latency measurement by observing a single 252 direction of the traffic flow. 254 Note that packet reordering can cause spurious edges that require 255 heuristics to correct. The Spin bit performance deteriorates as soon 256 as network impairments arise as explained in Section 2.2. 258 2.2. Delay Bit 260 The Delay bit has been designed to overcome accuracy limitations 261 experienced by the Spin bit under difficult network conditions: 263 - packet reordering leads to generation of spurious edges and errors 264 in delay estimation; 266 - loss of edges causes wrong estimation of spin periods and 267 therefore wrong RTT measurements; 269 - application-limited senders cause the Spin bit to measure the 270 application delays instead of network delays. 272 Unlike the Spin bit, which is set in every packet transmitted on the 273 network, the Delay bit is set only once per round trip. 275 When the Delay bit is used, a single packet with a marked bit (the 276 Delay bit) bounces between a client and a server during the entire 277 connection lifetime. This single packet is called "delay sample". 279 An observer placed at an intermediate point, observing a single 280 direction of traffic, tracking the delay sample and the relative 281 timestamp, can measure the round trip delay of the connection. 283 The delay sample lifetime is comprised of two phases: initialization 284 and reflection. The initialization is the generation of the delay 285 sample, while the reflection realizes the bounce behavior of this 286 single packet between the two endpoints. 288 The next figure describes the elementary Delay bit mechanism. 290 +--------+ - - - - - +--------+ 291 | | -----------> | | 292 | Client | | Server | 293 | | <----------- | | 294 +--------+ - - - - - +--------+ 296 (a) No traffic at beginning. 298 +--------+ 0 0 1 - - +--------+ 299 | | -----------> | | 300 | Client | | Server | 301 | | <----------- | | 302 +--------+ - - - - - +--------+ 304 (b) The Client starts sending data and 305 sets the first packet as Delay Sample. 307 +--------+ 0 0 0 0 0 +--------+ 308 | | -----------> | | 309 | Client | | Server | 310 | | <----------- | | 311 +--------+ - - - 1 0 +--------+ 313 (c) The Server starts sending data 314 and reflects the Delay Sample. 316 +--------+ 0 1 0 0 0 +--------+ 317 | | -----------> | | 318 | Client | | Server | 319 | | <----------- | | 320 +--------+ 0 0 0 0 0 +--------+ 322 (d) The Client reflects the Delay Sample. 324 +--------+ 0 0 0 0 0 +--------+ 325 | | -----------> | | 326 | Client | | Server | 327 | | <----------- | | 328 +--------+ 0 0 0 1 0 +--------+ 330 (e) The Server reflects the Delay Sample 331 and so on. 333 Delay bit mechanism 335 2.2.1. Generation Phase 337 Only client is actively involved in the generation phase. It 338 maintains an internal per-flow timestamp variable ("ds_time") updated 339 every time a delay sample is transmitted. 341 When connection starts, the client generates a new delay sample 342 initializing the Delay bit of the first outgoing packet to 1. Then 343 it updates the "ds_time" variable with the timestamp of its 344 transmission. 346 The server initializes the Delay bit to 0 at the beginning of the 347 connection, and its only task during the connection is described in 348 Section 2.2.2. 350 In absence of network impairments, the delay sample should bounce 351 between client and server continuously, for the entire duration of 352 the connection. That is highly unlikely for two reasons: 354 1. the packet carrying the Delay bit might be lost; 356 2. an endpoint could stop or delay sending packets because the 357 application is limiting the amount of traffic transmitted. 359 To deal with these problems, the client generates a new delay sample 360 if more than a predetermined time ("T_Max") has elapsed since the 361 last delay sample transmission (including reflections). Note that 362 "T_Max" should be greater than the max measurable RTT on the network. 363 See Section 2.2.3 for details. 365 2.2.2. Reflection Phase 367 Reflection is the process that enables the bouncing of the delay 368 sample between a client and a server. The behavior of the two 369 endpoints is almost the same. 371 - Server side reflection: when a delay sample arrives, the server 372 marks the first packet in the opposite direction as the delay 373 sample. 375 - Client side reflection: when a delay sample arrives, the client 376 marks the first packet in the opposite direction as the delay 377 sample. It also updates the "ds_time" variable when the outgoing 378 delay sample is actually forwarded. 380 In both cases, if the outgoing delay sample is being transmitted with 381 a delay greater than a predetermined threshold after the reception of 382 the incoming delay sample (1ms by default), the delay sample is not 383 reflected, and the outgoing Delay bit is kept at 0. 385 By doing so, the algorithm can reject measurements that would 386 overestimate the delay due to lack of traffic on the endpoints. 387 Hence, the maximum estimation error would amount to twice the 388 threshold (e.g. 2ms) per measurement. 390 2.2.3. T_Max Selection 392 The internal "ds_time" variable allows a client to identify delay 393 sample losses. Considering that a lost delay sample is regenerated 394 at the end of an explicit time ("T_Max") since the last generation, 395 this same value can be used by an observer to reject a measure and 396 start a new one. 398 In other words, if the difference in time between two delay samples 399 is greater or equal than "T_Max", then these cannot be used to 400 produce a delay measure. Therefore the value of "T_Max" must also be 401 known to the on-path network probes. 403 There are two alternatives to select the "T_Max" value so that both 404 client and observers know it. The first one requires that "T_Max" is 405 known a priori ("T_Max_p") and therefore set within the protocol 406 specifications that implements the marking mechanism (e.g. 1 second 407 which usually is greater than the max expectable RTT). The second 408 alternative requires a dynamic mechanism able to adapt the duration 409 of the "T_Max" to the delay of the connection ("T_Max_c"). 411 For instance, client and observers could use the connection RTT as a 412 basis for calculating an effective "T_Max". They should use a 413 predetermined initial value so that "T_Max = T_Max_p" (e.g. 1 second) 414 and then, when a valid RTT is measured, change "T_Max" accordingly so 415 that "T_Max = T_Max_c". In any case, the selected "T_Max" should be 416 large enough to absorb any possible variations in the connection 417 delay. 419 "T_Max_c" could be computed as two times the measured "RTT" plus a 420 fixed amount of time ("100ms") to prevent low "T_Max" values in case 421 of very small RTTs. The resulting formula is: "T_Max_c = 2RTT + 422 100ms". If "T_Max_c" is greater than "T_Max_p" then "T_Max_c" is 423 forced to "T_Max_p" value. 425 Note that the observer's "T_Max" should always be less than or equal 426 to the client's "T_Max" to avoid considering as a valid measurement 427 what is actually the client's "T_Max". To obtain this result, the 428 client waits for two consecutive incoming samples and computes the 429 two related RTTs. Then it takes the largest of them as the basis of 430 the "T_Max_c" formula. At this point, observers have already 431 measured a valid RTT and then computed their "T_Max_c". 433 2.2.4. Delay Measurement Using Delay Bit 435 When the Delay bit is used, a passive observer can use delay samples 436 directly and avoid inherent ambiguities in the calculation of the RTT 437 as can be seen in Spin bit analysis. 439 2.2.4.1. RTT Measurement 441 The delay sample generation process ensures that only one packet 442 marked with the Delay bit set to 1 runs back and forth between two 443 endpoints per round trip time. To determine the RTT measurement of a 444 flow, an on-path passive observer computes the time difference 445 between two delay samples observed in a single direction. 447 To ensure a valid measurement, the observer must verify that the 448 distance in time between the two samples taken into account is less 449 than "T_Max". 451 =======================|======================> 452 = ********** -----Obs----> ********** = 453 = * Client * * Server * = 454 = ********** <------------ ********** = 455 <============================================== 457 (a) client-server RTT 459 ==============================================> 460 = ********** ------------> ********** = 461 = * Client * * Server * = 462 = ********** <----Obs----- ********** = 463 <======================|======================= 465 (b) server-client RTT 467 Round-trip time (both direction) 469 2.2.4.2. Half-RTT Measurement 471 An observer that is able to observe both forward and return traffic 472 directions can use the delay samples to measure "upstream" and 473 "downstream" RTT components, also known as the half-RTT measurements. 474 It does this by measuring the time between a delay sample observed in 475 one direction and the delay sample previously observed in the 476 opposite direction. 478 As with RTT measurement, the observer must verify that the distance 479 in time between the two samples taken into account is less than 480 "T_Max". 482 Note that upstream and downstream sections of paths between the 483 endpoints and the observer, i.e. observer-to-client vs client-to- 484 observer and observer-to-server vs server-to-observer, may have 485 different delay characteristics due to the difference in network 486 congestion and other factors. 488 =======================> 489 = ********** ------|-----> ********** 490 = * Client * Obs * Server * 491 = ********** <-----|------ ********** 492 <======================= 494 (a) client-observer half-RTT 496 =======================> 497 ********** ------|-----> ********** = 498 * Client * Obs * Server * = 499 ********** <-----|------ ********** = 500 <======================= 502 (b) observer-server half-RTT 504 Half Round-trip time (both direction) 506 2.2.4.3. Intra-Domain RTT Measurement 508 Intra-domain RTT is the portion of the entire RTT used by a flow to 509 traverse the network of a provider. To measure intra-domain RTT, two 510 observers capable of observing traffic in both directions must be 511 employed simultaneously at ingress and egress of the network to be 512 measured. Intra-domain RTT is difference between the two computed 513 upstream (or downstream) RTT components. 515 =========================================> 516 = =====================> 517 = = ********** ---|--> ---|--> ********** 518 = = * Client * Obs Obs * Server * 519 = = ********** <--|--- <--|--- ********** 520 = <===================== 521 <========================================= 523 (a) client-observer RTT components (half-RTTs) 525 ==================> 526 ********** ---|--> ---|--> ********** 527 * Client * Obs Obs * Server * 528 ********** <--|--- <--|--- ********** 529 <================== 531 (b) the intra-domain RTT resulting from the 532 subtraction of the above RTT components 534 Intra-domain Round-trip time (client-observer: upstream) 536 2.2.5. Observer's Algorithm 538 An on-path observer maintains an internal per-flow variable to keep 539 track of time at which the last delay sample has been observed. 541 A unidirectional observer, upon detecting a delay sample: 543 - if a delay sample was also detected previously in the same 544 direction and the distance in time between them is less than 545 "T_Max - K", then the two delay samples can be used to calculate 546 RTT measurement. "K" is a protection threshold to absorb 547 differences in "T_Max" computation and delay variations between 548 two consecutive delay samples (e.g. "K = 10% T_Max"). 550 If the observer can observe both forward and return traffic flows, 551 and it is able to determine which direction contains the client and 552 the server (e.g. by observing the connection handshake), upon 553 detecting a delay sample: 555 - if a delay sample was also detected in the opposite direction and 556 the distance in time between them is less than "T_Max - K", then 557 the two delay samples can be used to measure the observer-client 558 half-RTT or the observer-server half-RTT, according to the 559 direction of the last delay sample observed. 561 2.2.6. Two Bits Delay Measurement: Spin Bit + Delay Bit 563 Spin and Delay bit algorithms work independently. If both marking 564 methods are used in the same connection, observers can choose the 565 best measurement between the two available: 567 - when a precise measurement can be produced using the Delay bit, 568 observers choose it; 570 - when a Delay bit measurement is not available, observers choose 571 the approximate Spin bit one. 573 2.2.7. Hidden Delay Bit - Delay Bit with Privacy Protection 575 Theoretically, delay measurements can be used to roughly evaluate the 576 distance of the client from the server (using the RTT) or from any 577 intermediate observer (using the client-observer half-RTT). To 578 protect users' privacy, the Delay bit algorithm can be slightly 579 modified to mask the RTT of the connection to an intermediate 580 observer. This result can be achieved by, for example, delaying the 581 client-side reflection of the delay sample by a fixed randomly chosen 582 time value. This would lead an intermediate observer to measure a 583 delay greater than the real one. 585 This Additional Delay should be randomly selected by the client and 586 kept constant for a certain amount of time across multiple 587 connections. This ensures that the client-server jitter remains the 588 same as if no Additional Delay had been inserted. For example, a new 589 Additional Delay value could be generated whenever the client's IP 590 address changes. 592 Using this technique, despite the Additional Delay introduced, it is 593 still possible to correctly measure the right component of RTT 594 (observer-server) and all the intra-domain measurements used to 595 distribute the delay in the network. Furthermore, differently from 596 the Delay bit, the hidden Delay bit makes the use of the client 597 reflection threshold (1ms) redundant. Removing this threshold leads 598 to the further advantage of increasing the number of valid 599 measurements produced by the algorithm. 601 3. Loss Bits 603 This section introduces bits that can be used for loss measurements. 604 Whenever this section of the specification refers to packets, it is 605 referring only to packets with protocol headers that include the loss 606 bits - the only packets whose loss can be measured. 608 - T: the "round Trip loss" bit is used in combination with the Spin 609 bit to measure round-trip loss. See Section 3.1. 611 - Q: the "sQuare signal" bit is used to measure upstream loss. See 612 Section 3.2. 614 - L: the "Loss event" bit is used to measure end-to-end loss. See 615 Section 3.3. 617 - R: the "Reflection square signal" bit is used in combination with 618 Q bit to measure end-to-end loss. See Section 3.1. 620 Loss measurements enabled by T, Q, and L bits can be implemented by 621 those loss bits alone (T bit requires a working Spin bit). Two-bit 622 combinations Q+L and Q+R enable additional measurement opportunities 623 discussed below. 625 Each endpoint maintains appropriate counters independently and 626 separately for each separately identifiable flow (each sub-flow for 627 multipath connections). 629 Since loss is reported independently for each flow, all bits (except 630 for L bit) require a certain minimum number of packets to be 631 exchanged per flow before any signal can be measured. Therefore, 632 loss measurements work best for flows that transfer more than a 633 minimal amount of data. 635 3.1. T Bit - Round Trip Loss Bit 637 The round Trip loss bit is used to mark a variable number of packets 638 exchanged twice between the endpoints realizing a two round-trip 639 reflection. A passive on-path observer, observing either direction, 640 can count and compare the number of marked packets seen during the 641 two reflections, estimating the loss rate experienced by the 642 connection. The overall exchange comprises: 644 - the client selects, generates and consequently transmits a first 645 train of packets, by setting the T bit to 1; 647 - the server, upon receiving each packet included in the first 648 train, reflects to the client a respective second train of packets 649 of the same size as the first train received, by setting the T bit 650 to 1; 652 - the client, upon receiving each packet included in the second 653 train, reflects to the server a respective third train of packets 654 of the same size as the second train received, by setting the T 655 bit to 1; 657 - the server, upon receiving each packet included in the third 658 train, finally reflects to the client a respective fourth train of 659 packets of the same size as the third train received, by setting 660 the T bit to 1. 662 Packets belonging to the first round trip (first and second train) 663 represent the Generation Phase, while those belonging to the second 664 round trip (third and fourth train) represent the Reflection Phase. 666 A passive on-path observer can count and compare the number of marked 667 packets seen during the two round trips (i.e. the first and third or 668 the second and the fourth trains of packets, depending on which 669 direction is observed) and estimate the loss rate experienced by the 670 connection. This process is repeated continuously to obtain more 671 measurements as long as the endpoints exchange traffic. These 672 measurements can be called Round Trip losses. 674 Since packet rates in two directions may be different, the number of 675 marked packets in the train is determined by the direction with the 676 lowest packet rate. See Section 3.1.2 for details on packet 677 generation. 679 3.1.1. Round Trip Loss 681 Since the measurements are performed on a portion of the traffic 682 exchanged between the client and the server, the observer calculates 683 the end-to-end Round Trip Packet Loss (RTPL) that, statistically, 684 will correspond to the loss rate experienced by the connection along 685 the entire network path. 687 =======================|======================> 688 = ********** -----Obs----> ********** = 689 = * Client * * Server * = 690 = ********** <------------ ********** = 691 <============================================== 693 (a) client-server RTPL 695 ==============================================> 696 = ********** ------------> ********** = 697 = * Client * * Server * = 698 = ********** <----Obs----- ********** = 699 <======================|======================= 701 (b) server-client RTPL 703 Round-trip packet loss (both direction) 705 This methodology also allows the Half-RTPL measurement and the Intra- 706 domain RTPL measurement in a way similar to RTT measurement. 708 =======================> 709 = ********** ------|-----> ********** 710 = * Client * Obs * Server * 711 = ********** <-----|------ ********** 712 <======================= 714 (a) client-observer half-RTPL 716 =======================> 717 ********** ------|-----> ********** = 718 * Client * Obs * Server * = 719 ********** <-----|------ ********** = 720 <======================= 722 (b) observer-server half-RTPL 724 Half Round-trip packet loss (both direction) 726 =========================================> 727 =====================> = 728 ********** ---|--> ---|--> ********** = = 729 * Client * Obs Obs * Server * = = 730 ********** <--|--- <--|--- ********** = = 731 <===================== = 732 <========================================= 734 (a) observer-server RTPL components (half-RTPLs) 736 ==================> 737 ********** ---|--> ---|--> ********** 738 * Client * Obs Obs * Server * 739 ********** <--|--- <--|--- ********** 740 <================== 742 (b) the intra-domain RTPL resulting from the 743 subtraction of the above RTPL components 745 Intra-domain Round-trip packet loss (observer-server) 747 3.1.2. Setting the Round Trip Loss Bit on Outgoing Packets 749 The round Trip loss signal requires a working Spin-bit signal to 750 separate trains of marked packets (packets with T bit set to 1). A 751 "pause" of at least one empty spin-bit period between each phase of 752 the algorithm serves as such separator for the on-path observer. 754 The client maintains a "generation token" count that is set to zero 755 at the beginning of the session and is incremented every time a 756 packet is received (marked or unmarked). The client also maintains a 757 "reflection counter" that starts at zero at the beginning of the 758 session. 760 The client is in charge of launching trains of marked packets and 761 does so according to the algorithm: 763 1. Generation Phase. The client starts generating marked packets 764 for two consecutive spin-bit periods; when the client transmits a 765 packet and a "generation token" is available, the client marks 766 the packet and retires a "generation token". If no token is 767 available, the outgoing packet is transmitted unmarked. At the 768 end of the first spin-bit period spent in generation, the 769 reflection counter is unlocked to start counting incoming marked 770 packets that will be reflected later; 772 2. Pause Phase. When the generation is completed, the client pauses 773 till it has observed one entire Spin bit period with no marked 774 packets. That Spin bit period is used by the observer as a 775 separator between generated and reflected packets. During this 776 marking pause, all the outgoing packets are transmitted with T 777 bit set to 0. The reflection counter is still incremented every 778 time a marked packet arrives; 780 3. Reflection Phase. The client starts transmitting marked packets, 781 decrementing the reflection counter for each transmitted marked 782 packet until the reflection counter reached zero. The 783 "generation token" method from the generation phase is used 784 during this phase as well. At the end of the first spin-period 785 spent in reflection, the reflection counter is locked to avoid 786 incoming reflected packets incrementing it; 788 4. Pause Phase 2. The pause phase is repeated after the reflection 789 phase and serves as a separator between the reflected packet 790 train and a new packet train. 792 The generation token counter should be capped to limit the effects of 793 a subsequent sudden reduction in the other endpoint's packet rate 794 that could prevent that endpoint from reflecting collected packets. 795 The most conservative cap value is "1". 797 A server maintains a "marking counter" that starts at zero and is 798 incremented every time a marked packet arrives. When the server 799 transmits a packet and the "marking counter" is positive, the server 800 marks the packet and decrements the "marking counter". If the 801 "marking counter" is zero, the outgoing packet is transmitted 802 unmarked. 804 Note that a choice of 2-RTT (two spin periods) for the generation 805 phase is a tradeoff between the percentage of marked packets (i.e. 806 the percentage of traffic monitored) and the measurement delay. 807 Using this value the algorithm produces a measurement approximately 808 every 6-RTT ("2" generation, "~2" reflection, "2" pauses), marking 809 "~1/3" of packets exchanged in the slower direction (see 810 Section 3.1.4). Choosing a generation phase of 1-RTT, we would 811 produce measurements every 4-RTT, monitoring just "~1/4" of packets 812 in the slower direction. 814 3.1.3. Observer's Logic for Round Trip Loss Signal 816 The on-path observer counts marked packets and separates different 817 trains by detecting spin-bit periods (at least one) with no marked 818 packets. The Round Trip Packet Loss (RTPL) is the difference between 819 the size of the Generation train and the Reflection train. 821 In the following example, packets are represented by two bits (first 822 one is the Spin bit, second one is the round Trip loss bit): 824 Generation Pause Reflection Pause 825 ____________________ ______________ ____________________ ________ 826 | | | | | 827 01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10 829 Round Trip Loss signal example 831 Note that 5 marked packets have been generated of which 4 have been 832 reflected. 834 3.1.4. Loss Coverage and Signal Timing 836 A cycle of the round Trip loss signaling algorithm contains 2 RTTs of 837 Generation phase, 2 RTTs of Reflection phase, and two Pause phases at 838 least 1 RTT in duration each. Hence, the loss signal is delayed by 839 about 6 RTTs since the loss events. 841 The observer can only detect loss of marked packets that occurs after 842 its initial observation of the Generation phase and before its 843 subsequent observation of the Reflection phase. Hence, if the loss 844 occurs on the path that sends packets at a lower rate (typically ACKs 845 in such asymmetric scenarios), "2/6" ("1/3") of the packets will be 846 sampled for loss detection. 848 If the loss occurs on the path that sends packets at a higher rate, 849 "lowPacketRate/(3*highPacketRate)" of the packets will be sampled for 850 loss detection. For protocols that use ACKs, the portion of packets 851 sampled for loss in the higher rate direction during unidirectional 852 data transfer is "1/(3*packetsPerAck)", where the value of 853 "packetsPerAck" can vary by protocol, by implementation, and by 854 network conditions. 856 3.2. Q Bit - sQuare Bit 858 The sQuare bit (Q bit) takes its name from the square wave generated 859 by its signal. Every outgoing packet contains the Q bit value, which 860 is initialized to the 0 and inverted after sending N packets (a 861 sQuare Block or simply Q Block). Hence, Q Period is 2*N. The Q bit 862 represents "packet color" as defined by [AltMark]. 864 Observation points can estimate upstream losses by watching a single 865 direction of the traffic flow and counting the number of packets in 866 each observed Q Block, as described in Section 3.2.2. 868 3.2.1. Q Block Length Selection 870 The length of the block must be known to the on-path network probes. 871 There are two alternatives to selecting the Q Block length. The 872 first one requires that the length is known a priori and therefore 873 set within the protocol specifications that implements the marking 874 mechanism. The second requires the sender to select it. 876 In this latter scenario, the sender is expected to choose N (Q Block 877 length) based on the expected amount of loss and reordering on the 878 path. The choice of N strikes a compromise - the observation could 879 become too unreliable in case of packet reordering and/or severe loss 880 if N is too small, while short flows may not yield a useful upstream 881 loss measurement if N is too large (see Section 3.2.2). 883 The value of N should be at least 64 and be a power of 2. This 884 requirement allows an Observer to infer the Q Block length by 885 observing one period of the square signal. It also allows the 886 Observer to identify flows that set the loss bits to arbitrary values 887 (see Section 5). 889 If the sender does not have sufficient information to make an 890 informed decision about Q Block length, the sender should use N=64, 891 since this value has been extensively tried in large-scale field 892 tests and yielded good results. Alternatively, the sender may also 893 choose a random power-of-2 N for each flow, increasing the chances of 894 using a Q Block length that gives the best signal for some flows. 896 The sender must keep the value of N constant for a given flow. 898 3.2.2. Upstream Loss 900 Blocks of N (Q Block length) consecutive packets are sent with the 901 same value of the Q bit, followed by another block of N packets with 902 an inverted value of the Q bit. Hence, knowing the value of N, an 903 on-path observer can estimate the amount of upstream loss after 904 observing at least N packets. The upstream loss rate ("uloss") is 905 one minus the average number of packets in a block of packets with 906 the same Q value ("p") divided by N ("uloss=1-avg(p)/N"). 908 The observer needs to be able to tolerate packet reordering that can 909 blur the edges of the square signal, as explained in Section 3.2.3. 911 =====================> 912 ********** -----Obs----> ********** 913 * Client * * Server * 914 ********** <------------ ********** 916 (a) in client-server channel (uloss_up) 918 ********** ------------> ********** 919 * Client * * Server * 920 ********** <----Obs----- ********** 921 <===================== 923 (b) in server-client channel (uloss_down) 925 Upstream loss 927 3.2.3. Identifying Q Block Boundaries 929 Packet reordering can produce spurious edges in the square signal. 930 To address this, the observer should look for packets with the 931 current Q bit value up to X packets past the first packet with a 932 reverse Q bit value. The value of X, a "Marking Block Threshold", 933 should be less than "N/2". 935 The choice of X represents a trade-off between resiliency to 936 reordering and resiliency to loss. A very large Marking Block 937 Threshold will be able to reconstruct Q Blocks despite a significant 938 amount of reordring, but it may erroneously coalesce packets from 939 multiple Q Blocks into fewer Q Blocks, if loss exceeds 50% for some Q 940 Blocks. 942 3.2.3.1. Improved Resilience to Burst Losses 944 Burst losses can affect Q measurements accuracy. Generally, burst 945 losses can be absorbed and correctly measured if smaller than the 946 established Q Block length. If entire Q Block length of packets get 947 lost in a burst, however, the observer may be left completely unaware 948 of the loss. 950 To improve burst loss resilience, an observer may consider a received 951 Q Block larger than the selected Q Block length as an indication of a 952 burst loss event. The observer would then compute the loss as three 953 times Q Block length minus the measured block length. By doing so, 954 the observer can detect burst losses of less than two blocks (e.g., 955 less than 128 packets for Q Block length of 64 packets). A burst 956 loss of two or more consecutive periods would still remain unnoticed 957 by the observer (or underestimated if a period longer than Q Block 958 length were formed). 960 3.3. L Bit - Loss Event Bit 962 The Loss Event bit uses an Unreported Loss counter maintained by the 963 protocol that implements the marking mechanism. To use the Loss 964 Event bit, the protocol must allow the sender to identify lost 965 packets. This is true of protocols such as QUIC, partially true for 966 TCP and SCTP (losses of pure ACKs are not detected) and is not true 967 of protocols such as UDP and IP/IPv6. 969 The Unreported Loss counter is initialized to 0, and L bit of every 970 outgoing packet indicates whether the Unreported Loss counter is 971 positive (L=1 if the counter is positive, and L=0 otherwise). 973 The value of the Unreported Loss counter is decremented every time a 974 packet with L=1 is sent. 976 The value of the Unreported Loss counter is incremented for every 977 packet that the protocol declares lost, using whatever loss detection 978 machinery the protocol employs. If the protocol is able to rescind 979 the loss determination later, a positive Unreported Loss counter may 980 be decremented due to the rescission, but it should not become 981 negative due to the rescission. 983 This loss signaling is similar to loss signaling in [ConEx], except 984 the Loss Event bit is reporting the exact number of lost packets, 985 whereas Echo Loss bit in [ConEx] is reporting an approximate number 986 of lost bytes. 988 For protocols, such as TCP ([TCP]), that allow network devices to 989 change data segmentation, it is possible that only a part of the 990 packet is lost. In these cases, the sender must increment Unreported 991 Loss counter by the fraction of the packet data lost (so Unreported 992 Loss counter may become negative when a packet with L=1 is sent after 993 a partial packet has been lost). 995 Observation points can estimate the end-to-end loss, as determined by 996 the upstream endpoint, by counting packets in this direction with the 997 L bit equal to 1, as described in Section 3.3.1. 999 3.3.1. End-To-End Loss 1001 The Loss Event bit allows an observer to estimate the end-to-end loss 1002 rate by counting packets with L bit value of 0 and 1 for a given 1003 flow. The end-to-end loss rate is the fraction of packets with L=1. 1005 The assumption here is that upstream loss affects packets with L=0 1006 and L=1 equally. If some loss is caused by tail-drop in a network 1007 device, this may be a simplification. If the sender's congestion 1008 controller reduces the packet send rate after loss, there may be a 1009 sufficient delay before sending packets with L=1 that they have a 1010 greater chance of arriving at the observer. 1012 3.3.1.1. Loss Profile Characterization 1014 The Loss Event bit allows an observer to characterize loss profile, 1015 since the distribution of observed packets with L bit set to 1 1016 roughly corresponds to the distribution of packets lost between 1 RTT 1017 and 1 RTO before (see Section 3.3.2.1). Hence, observing random 1018 single instances of L bit set to 1 indicates random single packet 1019 loss, while observing blocks of packets with L bit set to 1 indicates 1020 loss affecting entire blocks of packets. 1022 3.3.2. L+Q Bits - Loss Measurement Using L and Q Bits 1024 Combining L and Q bits allows a passive observer watching a single 1025 direction of traffic to accurately measure: 1027 - upstream loss: sender-to-observer loss (see Section 3.2.2) 1029 - downstream loss: observer-to-receiver loss (see Section 3.3.2.2) 1031 - end-to-end loss: sender-to-receiver loss on the observed path (see 1032 Section 3.3.1) with loss profile characterization (see 1033 Section 3.3.1.1) 1035 3.3.2.1. Correlating End-to-End and Upstream Loss 1037 Upstream loss is calculated by observing packets that did not suffer 1038 the upstream loss (Section 3.2.2). End-to-end loss, however, is 1039 calculated by observing subsequent packets after the sender's 1040 protocol detected the loss. Hence, end-to-end loss is generally 1041 observed with a delay of between 1 RTT (loss declared due to multiple 1042 duplicate acknowledgments) and 1 RTO (loss declared due to a timeout) 1043 relative to the upstream loss. 1045 The flow RTT can sometimes be estimated by timing protocol handshake 1046 messages. This RTT estimate can be greatly improved by observing a 1047 dedicated protocol mechanism for conveying RTT information, such as 1048 the Spin bit (see Section 2.1) or Delay bit (see Section 2.2). 1050 Whenever the observer needs to perform a computation that uses both 1051 upstream and end-to-end loss rate measurements, it should use 1052 upstream loss rate leading the end-to-end loss rate by approximately 1053 1 RTT. If the observer is unable to estimate RTT of the flow, it 1054 should accumulate loss measurements over time periods of at least 4 1055 times the typical RTT for the observed flows. 1057 If the calculated upstream loss rate exceeds the end-to-end loss rate 1058 calculated in Section 3.3.1, then either the Q Period is too short 1059 for the amount of packet reordering or there is observer loss, 1060 described in Section 3.3.2.3. If this happens, the observer should 1061 adjust the calculated upstream loss rate to match end-to-end loss 1062 rate, unless the following applies. 1064 In case of a protocol, such as TCP or SCTP, that does not track 1065 losses of pure ACK packets, observing a direction of traffic 1066 dominated by pure ACK packets could result in measured upstream loss 1067 that is higher than measured end-to-end loss, if said pure ACK 1068 packets are lost upstream. Hence, if the measurement is applied to 1069 such protocols, and the observer can confirm that pure ACK packets 1070 dominate the observed traffic direction, the observer should adjust 1071 the calculated end-to-end loss rate to match upstream loss rate. 1073 3.3.2.2. Downstream Loss 1075 Because downstream loss affects only those packets that did not 1076 suffer upstream loss, the end-to-end loss rate ("eloss") relates to 1077 the upstream loss rate ("uloss") and downstream loss rate ("dloss") 1078 as "(1-uloss)(1-dloss)=1-eloss". Hence, "dloss=(eloss- 1079 uloss)/(1-uloss)". 1081 3.3.2.3. Observer Loss 1083 A typical deployment of a passive observation system includes a 1084 network tap device that mirrors network packets of interest to a 1085 device that performs analysis and measurement on the mirrored 1086 packets. The observer loss is the loss that occurs on the mirror 1087 path. 1089 Observer loss affects upstream loss rate measurement, since it causes 1090 the observer to account for fewer packets in a block of identical Q 1091 bit values (see Section 3.2.2). The end-to-end loss rate 1092 measurement, however, is unaffected by the observer loss, since it is 1093 a measurement of the fraction of packets with the L bit value of 1, 1094 and the observer loss would affect all packets equally (see 1095 Section 3.3.1). 1097 The need to adjust the upstream loss rate down to match end-to-end 1098 loss rate as described in Section 3.3.2.1 is an indication of the 1099 observer loss, whose magnitude is between the amount of such 1100 adjustment and the entirety of the upstream loss measured in 1101 Section 3.2.2. Alternatively, a high apparent upstream loss rate 1102 could be an indication of significant packet reordering, possibly due 1103 to packets belonging to a single flow being multiplexed over several 1104 upstream paths with different latency characteristics. 1106 3.4. R Bit - Reflection Square Bit 1108 R bit requires a deployment alongside Q bit. Unlike the square 1109 signal for which packets are transmitted in blocks of fixed size, the 1110 number of packets in Reflection square signal blocks (also an 1111 alternate marking signal) varies according to these rules: 1113 - when the transmission of a new block starts, its size is set equal 1114 to the size of the last Q Block whose reception has been 1115 completed; 1117 - if, before transmission of the block is terminated, the reception 1118 of at least one further Q Block is completed, the size of the 1119 block is updated to be the average size of the further received Q 1120 Blocks. 1122 The Reflection square value is initialized to 0 and is applied to the 1123 R bit of every outgoing packet. The Reflection square value is 1124 toggled for the first time when the completion of a Q Block is 1125 detected in the incoming square signal (produced by the other 1126 endpoint using the Q bit). The number of packets detected within 1127 this first Q Block ("p"), is used to generate a reflection square 1128 signal that toggles every "M=p" packets (at first). This new signal 1129 produces blocks of M packets (marked using the R bit) and each of 1130 them is called "Reflection Block" (R Block). 1132 The M value is then updated every time a completed Q Block in the 1133 incoming square signal is received, following this formula: 1134 "M=round(avg(p))". 1136 The parameter "avg(p)", the average number of packets in a marking 1137 period, is computed based on all the Q Blocks received since the 1138 beginning of the current R Block. 1140 The transmission of an R Block is considered complete (and the signal 1141 toggled) when the number of packets transmitted in that block is at 1142 least the latest computed M value. 1144 To ensure a proper computation of the M value, endpoints implementing 1145 the R bit must identify the boundaries of incoming Q Blocks. The 1146 same approach described in Section 3.2.3 should be used. 1148 Looking at the R bit, unidirectional observation points have an 1149 indication of loss experienced by the entire unobserved channel plus 1150 the loss on the path from the sender to them. 1152 Since the Q Block is sent in one direction, and the corresponding 1153 reflected R Block is sent in the opposite direction, the reflected R 1154 signal is transmitted with the packet rate of the slowest direction. 1155 Namely, if the observed direction is the slowest, there can be 1156 multiple Q Blocks transmitted in the unobserved direction before a 1157 complete R Block is transmitted in the observed direction. If the 1158 unobserved direction is the slowest, the observed direction can be 1159 sending R Blocks of the same size repeatedly before it can update the 1160 signal to account for a newly-completed Q Block. 1162 3.4.1. Enhancement of R Block Length Computation 1164 The use of the rounding function used in the M computation introduces 1165 errors that can be minimized by storing the rounding applied each 1166 time M is computed, and using it during the computation of the M 1167 value in the following R Block. 1169 This can be achieved introducing the new "r_avg" parameter in the 1170 computation of M. The new formula is "Mr=avg(p)+r_avg; M=round(Mr); 1171 r_avg=Mr-M" where the initial value of "r_avg" is equal to 0. 1173 3.4.2. Improved Resilience to Packet Reordering 1175 When a protocol implementing the marking mechanism is able to detect 1176 when packets are received out of order, it can improve resilience to 1177 packet reordering beyond what is possible using methods described in 1178 Section 3.2.3. 1180 This can be achieved by updating the size of the current R Block 1181 while it is being transmitted. The reflection block size is then 1182 updated every time an incoming reordered packet of the previous Q 1183 Block is detected. This can be done if and only if the transmission 1184 of the current reflection block is in progress and no packets of the 1185 following Q Block have been received. 1187 3.4.2.1. Improved Resilience to Burst Losses 1189 Burst losses can affect R measurements accuracy similarly to how they 1190 affect Q measurements accuracy. Therefore, recommendations in 1191 section Section 3.2.3.1 apply equally to improving burst loss 1192 resilience for R measurements. 1194 3.4.3. R+Q Bits - Loss Measurement Using R and Q Bits 1196 Since both sQuare and Reflection square bits are toggled at most 1197 every N packets (except for the first transition of the R bit as 1198 explained before), an on-path observer can count the number of 1199 packets of each marking block and, knowing the value of N, can 1200 estimate the amount of loss experienced by the connection. An 1201 observer can calculate different measurements depending on whether it 1202 is able to observe a single direction of the traffic or both 1203 directions. 1205 Single directional observer: 1207 - upstream loss in the observed direction: the loss between the 1208 sender and the observation point (see Section 3.2.2) 1210 - "three-quarters" connection loss: the loss between the receiver 1211 and the sender in the unobserved direction plus the loss between 1212 the sender and the observation point in the observed direction 1214 - end-to-end loss in the unobserved direction: the loss between the 1215 receiver and the sender in the opposite direction 1217 Two directions observer (same metrics seen previously applied to both 1218 direction, plus): 1220 - client-observer half round-trip loss: the loss between the client 1221 and the observation point in both directions 1223 - observer-server half round-trip loss: the loss between the 1224 observation point and the server in both directions 1226 - downstream loss: the loss between the observation point and the 1227 receiver (applicable to both directions) 1229 3.4.3.1. Three-Quarters Connection Loss 1231 Except for the very first block in which there is nothing to reflect 1232 (a complete Q Block has not been yet received), packets are 1233 continuously R-bit marked into alternate blocks of size lower or 1234 equal than N. Knowing the value of N, an on-path observer can 1235 estimate the amount of loss occurred in the whole opposite channel 1236 plus the loss from the sender up to it in the observation channel. 1237 As for the previous metric, the "three-quarters" connection loss rate 1238 ("tqloss") is one minus the average number of packets in a block of 1239 packets with the same R value ("t") divided by "N" 1240 ("tqloss=1-avg(t)/N"). 1242 =======================> 1243 = ********** -----Obs----> ********** 1244 = * Client * * Server * 1245 = ********** <------------ ********** 1246 <============================================ 1248 (a) in client-server channel (tqloss_up) 1250 ============================================> 1251 ********** ------------> ********** = 1252 * Client * * Server * = 1253 ********** <----Obs----- ********** = 1254 <======================= 1256 (b) in server-client channel (tqloss_down) 1258 Three-quarters connection loss 1260 The following metrics derive from this last metric and the upstream 1261 loss produced by the Q bit. 1263 3.4.3.2. End-To-End Loss in the Opposite Direction 1265 End-to-end loss in the unobserved direction ("eloss_unobserved") 1266 relates to the "three-quarters" connection loss ("tqloss") and 1267 upstream loss in the observed direction ("uloss") as 1268 "(1-eloss_unobserved)(1-uloss)=1-tqloss". Hence, 1269 "eloss_unobserved=(tqloss-uloss)/(1-uloss)". 1271 ********** -----Obs----> ********** 1272 * Client * * Server * 1273 ********** <------------ ********** 1274 <========================================== 1276 (a) in client-server channel (eloss_down) 1278 ==========================================> 1279 ********** ------------> ********** 1280 * Client * * Server * 1281 ********** <----Obs----- ********** 1283 (b) in server-client channel (eloss_up) 1285 End-To-End loss in the opposite direction 1287 3.4.3.3. Half Round-Trip Loss 1289 If the observer is able to observe both directions of traffic, it is 1290 able to calculate two "half round-trip" loss measurements - loss from 1291 the observer to the receiver (in a given direction) and then back to 1292 the observer in the opposite direction. For both directions, "half 1293 round-trip" loss ("hrtloss") relates to "three-quarters" connection 1294 loss ("tqloss_opposite") measured in the opposite direction and the 1295 upstream loss ("uloss") measured in the given direction as 1296 "(1-uloss)(1-hrtloss)=1-tqloss_opposite". Hence, 1297 "hrtloss=(tqloss_opposite-uloss)/(1-uloss)". 1299 =======================> 1300 = ********** ------|-----> ********** 1301 = * Client * Obs * Server * 1302 = ********** <-----|------ ********** 1303 <======================= 1305 (a) client-observer half round-trip loss (hrtloss_co) 1307 =======================> 1308 ********** ------|-----> ********** = 1309 * Client * Obs * Server * = 1310 ********** <-----|------ ********** = 1311 <======================= 1313 (b) observer-server half round-trip loss (hrtloss_os) 1315 Half Round-trip loss (both direction) 1317 3.4.3.4. Downstream Loss 1319 If the observer is able to observe both directions of traffic, it is 1320 able to calculate two downstream loss measurements using either end- 1321 to-end loss and upstream loss, similar to the calculation in 1322 Section 3.3.2.2 or using "half round-trip" loss and upstream loss in 1323 the opposite direction. 1325 For the latter, "dloss=(hrtloss-uloss_opposite)/(1-uloss_opposite)". 1327 =====================> 1328 ********** ------|-----> ********** 1329 * Client * Obs * Server * 1330 ********** <-----|------ ********** 1332 (a) in client-server channel (dloss_up) 1334 ********** ------|-----> ********** 1335 * Client * Obs * Server * 1336 ********** <-----|------ ********** 1337 <===================== 1339 (b) in server-client channel (dloss_down) 1341 Downstream loss 1343 3.5. E Bit - ECN-Echo Event Bit 1345 While the primary focus of this draft is on exposing packet loss and 1346 delay, modern networks can report congestion before they are forced 1347 to drop packets, as described in [ECN]. When transport protocols 1348 keep ECN-Echo feedback under encryption, this signal cannot be 1349 observed by the network operators. When tasked with diagnosing 1350 network performance problems, knowledge of a congestion downstream of 1351 an observation point can be instrumental. 1353 If downstream congestion information is desired, this information can 1354 be signaled with an additional bit. 1356 - E: The "ECN-Echo Event" bit is set to 0 or 1 according to the 1357 Unreported ECN Echo counter, as explained below in Section 3.5.1. 1359 3.5.1. Setting the ECN-Echo Event Bit on Outgoing Packets 1361 The Unreported ECN-Echo counter operates identically to Unreported 1362 Loss counter (Section 3.3), except it counts packets delivered by the 1363 network with CE markings, according to the ECN-Echo feedback from the 1364 receiver. 1366 This ECN-Echo signaling is similar to ECN signaling in [ConEx]. ECN- 1367 Echo mechanism in QUIC provides the number of packets received with 1368 CE marks. For protocols like TCP, the method described in 1369 [ConEx-TCP] can be employed. As stated in [ConEx-TCP], such feedback 1370 can be further improved using a method described in [ACCURATE]. 1372 3.5.2. Using E Bit for Passive ECN-Reported Congestion Measurement 1374 A network observer can count packets with CE codepoint and determine 1375 the upstream CE-marking rate directly. 1377 Observation points can also estimate ECN-reported end-to-end 1378 congestion by counting packets in this direction with a E bit equal 1379 to 1. 1381 The upstream CE-marking rate and end-to-end ECN-reported congestion 1382 can provide information about downstream CE-marking rate. Presence 1383 of E bits along with L bits, however, can somewhat confound precise 1384 estimates of upstream and downstream CE-markings in case the flow 1385 contains packets that are not ECN-capable. 1387 4. Summary of Delay and Loss Marking Methods 1389 This section summarizes the marking methods described in this draft. 1391 For the Delay measurement, it is possible to use the Spin bit and/or 1392 the delay bit. A unidirectional or bidirectional observer can be 1393 used. 1395 +---------------+----+------------------------+--------------------+ 1396 | Method |# of| Available | | # of | 1397 | |bits| Delay Metrics | Impairments | meas.| 1398 | | +------------+-----------+ Resiliency | | 1399 | | | UniDir | BiDir | | | 1400 | | | Observer | Observer | | | 1401 +---------------+----+------------+-----------+-------------+------+ 1402 |S: Spin Bit | 1 | RTT | x2 | low | very | 1403 | | | | Half RTT | | high | 1404 +---------------+----+------------+-----------+-------------+------+ 1405 |D: Delay Bit | 1 | RTT | x2 | high |medium| 1406 | | | | Half RTT | | | 1407 +---------------+----+------------+-----------+-------------+------+ 1408 |D^: Hidden | 1 | RTT^ | x2 | high | high | 1409 | Delay Bit | | | Left Half^| | | 1410 | | | | Right Half| | | 1411 +---------------+----+------------+-----------+-------------+------+ 1412 |SD: Spin Bit & | 2 | RTT | x2 | high | very | 1413 | Delay Bit *| | | Half RTT | | high | 1414 +---------------+----+------------+-----------+-------------+------+ 1416 x2 Same metric for both directions 1417 * Both bits work independently; an observer could use less accurate 1418 Spin bit measurements when Delay bit ones are unavailable 1419 ^ Masked metric (real value can be calculated only by those who 1420 know the Additional Delay) 1422 Figure 1: Delay Comparison 1424 For the Loss measurement, each row in the table of Figure 2 1425 represents a loss marking method. For each method the table 1426 specifies the number of bits required in the header, the available 1427 metrics using an unidirectional or bidirectional observer, applicable 1428 protocols, measurement fidelity and delay. 1430 +-------------+-+-----------------------+-+------------------------+ 1431 | Method |B| Available |P| Measurement Aspects | 1432 | |i| Loss Metrics |r+------------+-----------+ 1433 | |t| UniDir | BiDir |t| Fidelity | Delay | 1434 | |s| Observer | Observer |o| | | 1435 +-------------+-+-----------+-----------+-+------------+-----------+ 1436 |T: Round Trip|$| RT | x2 | | Rate by | ~6 RTT | 1437 | Loss Bit |1| | Half RT |*| sampling +-----------+ 1438 | | | | | | 1/3 to 1/(3*ppa) of | 1439 | | | | | | pkts over 2 RTT | 1440 +-------------+-+-----------+-----------+-+------------+-----------+ 1441 |Q: sQuare Bit|1| Upstream | x2 |*| Rate over | N pkts | 1442 | | | | | | N pkts | (e.g. 64) | 1443 | | | | | | (e.g. 64) | | 1444 +-------------+-+-----------+-----------+-+------------+-----------+ 1445 |L: Loss Event|1| E2E | x2 |#| Loss shape | Min: RTT | 1446 | Bit | | | | | (and rate) | Max: RTO | 1447 +-------------+-+-----------+-----------+-+------------+-----------+ 1448 |QL: sQuare + |2| Upstream | x2 | | -> see Q | Up: see Q | 1449 | Loss Ev. | | Downstream| x2 |#| -> see Q|L | Others: | 1450 | Bits | | E2E | x2 | | -> see L | see L | 1451 +-------------+-+-----------+-----------+-+------------+-----------+ 1452 |QR: sQuare + |2| Upstream | x2 | | Rate over | Up: see Q | 1453 | Ref. Sq. | | 3/4 RT | x2 | | N*ppa pkts | Others: | 1454 | Bits | | !E2E | E2E |*| (see Q bit | N*ppa pk | 1455 | | | | Downstream| | for N) | (see Q | 1456 | | | | Half RT | | | for N) | 1457 +-------------+-+-----------+-----------+-+------------+-----------+ 1459 * All protocols 1460 # Protocols employing loss detection 1461 (with or without pure ACK loss detection) 1462 $ Require a working Spin bit 1463 ! Metric relative to the opposite channel 1464 x2 Same metric for both directions 1465 ppa Packets-Per-Ack 1466 Q|L See Q if Upstream loss is significant; L otherwise 1468 Figure 2: Loss Comparison 1470 5. Protocol Ossification Considerations 1472 Accurate loss and delay information is not critical to the operation 1473 of any protocol, though its presence for a sufficient number of flows 1474 is important for the operation of networks. 1476 The delay and loss bits are amenable to "greasing" described in 1477 [RFC8701], if the protocol designers are not ready to dedicate (and 1478 ossify) bits used for loss reporting to this function. The greasing 1479 could be accomplished similarly to the Latency Spin bit greasing in 1480 [QUIC-TRANSPORT]. Namely, implementations could decide that a 1481 fraction of flows should not encode loss and delay information and, 1482 instead, the bits would be set to arbitrary values. The observers 1483 would need to be ready to ignore flows with delay and loss 1484 information more resembling noise than the expected signal. 1486 6. Examples of Application 1488 6.1. QUIC 1490 The binding of a delay signal to QUIC is partially described in 1491 [QUIC-TRANSPORT], which adds the Spin bit to the first byte of the 1492 short packet header, leaving two reserved bits for future use. 1494 To implement the additional signals discussed in this document, the 1495 first byte of the short packet header can be modified as follows: 1497 - the Delay bit (D) can be placed in the first reserved bit (i.e. 1498 the fourth most significant bit _0x10_) while the round trip loss 1499 bit (T) in the second reserved bit (i.e. the fifth most 1500 significant bit _0x08_); the proposed scheme is: 1502 0 1 2 3 4 5 6 7 1503 +-+-+-+-+-+-+-+-+ 1504 |0|1|S|D|T|K|P|P| 1505 +-+-+-+-+-+-+-+-+ 1507 Scheme 1 1509 - alternatively, a two bits loss signal (QL or QR) can be placed in 1510 both reserved bits; the proposed schemes, in this case, are: 1512 0 1 2 3 4 5 6 7 1513 +-+-+-+-+-+-+-+-+ 1514 |0|1|S|Q|L|K|P|P| 1515 +-+-+-+-+-+-+-+-+ 1517 Scheme 2A 1519 0 1 2 3 4 5 6 7 1520 +-+-+-+-+-+-+-+-+ 1521 |0|1|S|Q|R|K|P|P| 1522 +-+-+-+-+-+-+-+-+ 1524 Scheme 2B 1526 A further option would be to substitute the Spin bit with the Delay 1527 bit (or hidden Delay bit), leaving the two reserved bits for loss 1528 detection. The proposed schemes are: 1530 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1531 +-+-+-+-+-+-+-+-+ +-+-+--+-+-+-+-+-+ 1532 |0|1|D|Q|L|K|P|P| OR |0|1|D^|Q|L|K|P|P| 1533 +-+-+-+-+-+-+-+-+ +-+-+--+-+-+-+-+-+ 1535 Scheme 3A 1537 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1538 +-+-+-+-+-+-+-+-+ +-+-+--+-+-+-+-+-+ 1539 |0|1|D|Q|R|K|P|P| OR |0|1|D^|Q|R|K|P|P| 1540 +-+-+-+-+-+-+-+-+ +-+-+--+-+-+-+-+-+ 1542 Scheme 3B 1544 6.2. TCP 1546 The signals can be added to TCP by defining bit 4 of byte 13 of the 1547 TCP header to carry the Spin bit or the Delay bit, and possibly bits 1548 5 and 6 to carry additional information, like the Delay bit and the 1549 round-trip loss bit (DT), or a two bits loss signal (QL or QR). 1551 7. Security Considerations 1553 Passive loss and delay observations have been a part of the network 1554 operations for a long time, so exposing loss and delay information to 1555 the network does not add new security concerns for protocols that are 1556 currently observable. 1558 In the absence of packet loss, Q and R bits signals do not provide 1559 any information that cannot be observed by simply counting packets 1560 transiting a network path. In the presence of packet loss, Q and R 1561 bits will disclose the loss, but this is information about the 1562 environment and not the endpoint state. The L bit signal discloses 1563 internal state of the protocol's loss detection machinery, but this 1564 state can often be gleamed by timing packets and observing congestion 1565 controller response. 1567 Hence, loss bits do not provide a viable new mechanism to attack data 1568 integrity and secrecy. 1570 The described techniques can generally apply to different 1571 communication protocols operating in different security environments. 1572 An implementation of these techniques for a particular protocol must 1573 consider specifics of the protocol and its expected operating 1574 environment. For example, security considerations for QUIC, 1575 discussed in [QUIC-TRANSPORT] and [QUIC-TLS], consider a possibility 1576 of active and passive attackers in the network as well as attacks on 1577 specific QUIC mechanisms. 1579 7.1. Optimistic ACK Attack 1581 A defense against an Optimistic ACK Attack, described in 1582 [QUIC-TRANSPORT], involves a sender randomly skipping packet numbers 1583 to detect a receiver acknowledging packet numbers that have never 1584 been received. The Q bit signal may inform the attacker which packet 1585 numbers were skipped on purpose and which had been actually lost (and 1586 are, therefore, safe for the attacker to acknowledge). To use the Q 1587 bit for this purpose, the attacker must first receive at least an 1588 entire Q Block of packets, which renders the attack ineffective 1589 against a delay-sensitive congestion controller. 1591 A protocol that is more susceptible to an Optimistic ACK Attack with 1592 the loss signal provided by Q bit and uses a loss-based congestion 1593 controller, should shorten the current Q Block by the number of 1594 skipped packets numbers. For example, skipping a single packet 1595 number will invert the square signal one outgoing packet sooner. 1597 Similar considerations apply to the R bit, although a shortened R 1598 Block along with a matching skip in packet numbers does not 1599 necessarily imply a lost packet, since it could be due to a lost 1600 packet on the reverse path along with a deliberately skipped packet 1601 by the sender. 1603 8. Privacy Considerations 1605 To minimize unintentional exposure of information, loss bits provide 1606 an explicit loss signal - a preferred way to share information per 1607 [RFC8558]. 1609 New protocols commonly have specific privacy goals, and loss 1610 reporting must ensure that loss information does not compromise those 1611 privacy goals. For example, [QUIC-TRANSPORT] allows changing 1612 Connection IDs in the middle of a connection to reduce the likelihood 1613 of a passive observer linking old and new sub-flows to the same 1614 device. A QUIC implementation would need to reset all counters when 1615 it changes the destination (IP address or UDP port) or the Connection 1616 ID used for outgoing packets. It would also need to avoid 1617 incrementing Unreported Loss counter for loss of packets sent to a 1618 different destination or with a different Connection ID. 1620 9. IANA Considerations 1622 This document makes no request of IANA. 1624 10. Contributors 1626 The following people provided valuable contributions to this 1627 document: 1629 - Marcus Ihlar, Ericsson, marcus.ihlar@ericsson.com 1631 - Jari Arkko, Ericsson, jari.arkko@ericsson.com 1633 - Emile Stephan, Orange, emile.stephan@orange.com 1635 11. Acknowledgements 1637 The authors would like to thank the QUIC WG for their contributions, 1638 Christian Huitema for implementing Q and L bits in his picoquic 1639 stack, and Ike Kunze for providing constructive reviews and helpful 1640 suggestions. 1642 12. References 1644 12.1. Normative References 1646 [ConEx] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 1647 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 1648 DOI 10.17487/RFC7713, December 2015, 1649 . 1651 [ConEx-TCP] 1652 Kuehlewind, M., Ed. and R. Scheffenegger, "TCP 1653 Modifications for Congestion Exposure (ConEx)", RFC 7786, 1654 DOI 10.17487/RFC7786, May 2016, 1655 . 1657 [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1658 of Explicit Congestion Notification (ECN) to IP", 1659 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1660 . 1662 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 1663 DOI 10.17487/RFC0791, September 1981, 1664 . 1666 [IPM-Methods] 1667 Morton, A., "Active and Passive Metrics and Methods (with 1668 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1669 May 2016, . 1671 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1672 (IPv6) Specification", STD 86, RFC 8200, 1673 DOI 10.17487/RFC8200, July 2017, 1674 . 1676 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 1677 RFC 8558, DOI 10.17487/RFC8558, April 2019, 1678 . 1680 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 1681 RFC 793, DOI 10.17487/RFC0793, September 1981, 1682 . 1684 12.2. Informative References 1686 [ACCURATE] 1687 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 1688 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 1689 ecn-18 (work in progress), March 2022. 1691 [AltMark] Fioccola, G., Cociglio, M., Mirsky, G., Mizrahi, T., and 1692 T. Zhou, "Alternate-Marking Method", draft-ietf-ippm- 1693 rfc8321bis-01 (work in progress), April 2022. 1695 [ANRW19-PM-QUIC] 1696 Bulgarella, F., Cociglio, M., Fioccola, G., Marchetto, G., 1697 and R. Sisto, "Performance measurements of QUIC 1698 communications", Proceedings of the Applied Networking 1699 Research Workshop, DOI 10.1145/3340301.3341127, July 2019. 1701 [I-D.trammell-ippm-spin] 1702 Trammell, B., "An Explicit Transport-Layer Signal for 1703 Hybrid RTT Measurement", draft-trammell-ippm-spin-00 (work 1704 in progress), January 2019. 1706 [I-D.trammell-tsvwg-spin] 1707 Trammell, B., "A Transport-Independent Explicit Signal for 1708 Hybrid RTT Measurement", draft-trammell-tsvwg-spin-00 1709 (work in progress), July 2018. 1711 [IPv6AltMark] 1712 Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. 1713 Pang, "IPv6 Application of the Alternate Marking Method", 1714 draft-ietf-6man-ipv6-alt-mark-14 (work in progress), April 1715 2022. 1717 [QUIC-TLS] 1718 Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure 1719 QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, 1720 . 1722 [QUIC-TRANSPORT] 1723 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 1724 Multiplexed and Secure Transport", RFC 9000, 1725 DOI 10.17487/RFC9000, May 2021, 1726 . 1728 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1729 Jacquenet, "An Inventory of Transport-Centric Functions 1730 Provided by Middleboxes: An Operator Perspective", 1731 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1732 . 1734 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1735 Sustain Extensibility (GREASE) to TLS Extensibility", 1736 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1737 . 1739 [RFC9065] Fairhurst, G. and C. Perkins, "Considerations around 1740 Transport Header Confidentiality, Network Operations, and 1741 the Evolution of Internet Transport Protocols", RFC 9065, 1742 DOI 10.17487/RFC9065, July 2021, 1743 . 1745 [SPIN-BIT] 1746 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 1747 Transport Protocol", draft-ietf-quic-manageability-16 1748 (work in progress), April 2022. 1750 [UDP-OPTIONS] 1751 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 1752 udp-options-18 (work in progress), March 2022. 1754 [UDP-SURPLUS] 1755 Herbert, T., "UDP Surplus Header", draft-herbert-udp- 1756 space-hdr-01 (work in progress), July 2019. 1758 Authors' Addresses 1760 Mauro Cociglio 1761 Telecom Italia - TIM 1762 Via Reiss Romoli, 274 1763 Torino 10148 1764 Italy 1766 EMail: mauro.cociglio@telecomitalia.it 1768 Alexandre Ferrieux 1769 Orange Labs 1771 EMail: alexandre.ferrieux@orange.com 1773 Giuseppe Fioccola 1774 Huawei Technologies 1775 Riesstrasse, 25 1776 Munich 80992 1777 Germany 1779 EMail: giuseppe.fioccola@huawei.com 1781 Igor Lubashev 1782 Akamai Technologies 1784 EMail: ilubashe@akamai.com 1786 Fabio Bulgarella 1787 Telecom Italia - TIM 1788 Via Reiss Romoli, 274 1789 Torino 10148 1790 Italy 1792 EMail: fabio.bulgarella@guest.telecomitalia.it 1794 Isabelle Hamchaoui 1795 Orange Labs 1797 EMail: isabelle.hamchaoui@orange.com 1798 Massimo Nilo 1799 Telecom Italia - TIM 1800 Via Reiss Romoli, 274 1801 Torino 10148 1802 Italy 1804 EMail: massimo.nilo@telecomitalia.it 1806 Riccardo Sisto 1807 Politecnico di Torino 1809 EMail: riccardo.sisto@polito.it 1811 Dmitri Tikhonov 1812 LiteSpeed Technologies 1814 EMail: dtikhonov@litespeedtech.com