idnits 2.17.1 draft-ferrieuxhamchaoui-quic-lossbits-02.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 (November 3, 2019) is 1637 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-03) exists of draft-ferrieuxhamchaoui-tsvwg-lossbits-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-24 == Outdated reference: A later version (-21) exists of draft-ietf-tsvwg-transport-encrypt-09 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG A. Ferrieux, Ed. 3 Internet-Draft I. Hamchaoui, Ed. 4 Intended status: Informational Orange Labs 5 Expires: May 6, 2020 I. Lubashev, Ed. 6 Akamai Technologies 7 November 3, 2019 9 Packet Loss Signaling for Encrypted Protocols 10 draft-ferrieuxhamchaoui-quic-lossbits-02 12 Abstract 14 This draft adapts the general technique described in draft- 15 ferrieuxhamchaoui-tsvwg-lossbits draft-ferrieuxhamchaoui-tsvwg- 16 lossbits for QUIC using reserved bits in QUIC v1 header. It 17 describes a method that employs two bits to allow endpoints to signal 18 packet loss in a way that can be used by network devices to measure 19 and locate the source of the loss. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 6, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 57 3. Loss Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Setting the sQuare Bit on Outgoing Packets . . . . . . . 3 59 3.1.1. Q Period Selection . . . . . . . . . . . . . . . . . 4 60 3.2. Setting the Loss Event Bit on Outgoing Packets . . . . . 4 61 4. Using the Loss Bits for Passive Loss Measurement . . . . . . 4 62 4.1. End-To-End Loss . . . . . . . . . . . . . . . . . . . . . 5 63 4.2. Upstream Loss . . . . . . . . . . . . . . . . . . . . . . 5 64 4.3. Correlating End-to-End and Upstream Loss . . . . . . . . 6 65 4.4. Downstream Loss . . . . . . . . . . . . . . . . . . . . . 6 66 4.5. Observer Loss . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Ossification Considerations . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Since version 01 . . . . . . . . . . . . . . . . . . . . 8 72 8.2. Since version 00 . . . . . . . . . . . . . . . . . . . . 8 73 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 10.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Packet loss is a hard and pervasive problem of day-to-day network 82 operation, and proactively detecting, measuring, and locating it is 83 crucial to maintaining high QoS and timely resolution of crippling 84 end-to-end throughput issues. To this effect, in a TCP-dominated 85 world, network operators have been heavily relying on information 86 present in the clear in TCP headers: sequence and acknowledgment 87 numbers, and SACK when enabled. These allow for quantitative 88 estimation of packet loss by passive on-path observation. 89 Additionally, the lossy segment (upstream or downstream from the 90 observation point) can be quickly identified by moving the passive 91 observer around. 93 With QUIC, the equivalent transport headers are encrypted and passive 94 packet loss observation is not possible, as described in 95 [TRANSPORT-ENCRYPT]. 97 QUIC could be routed by the network differently and the fraction of 98 Internet traffic delivered using QUIC is increasing every year. 99 Therefore, is it imperative to measure packet loss experienced by 100 QUIC users directly instead of relying on measuring TCP loss between 101 similar endpoints. 103 Since explicit path signals are preferred by [RFC8558], this document 104 proposes adding two explicit loss bits to the clear portion of short 105 headers to restore network operators' ability to maintain high QoS 106 for QUIC users. 108 2. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Loss Bits 116 The proposal introduces two bits that are to be present in packets 117 with a short header. Therefore, only loss of short header packets is 118 reported using loss bits. Whenever this specification refers to 119 packets, it is referring only to packets with short headers. 121 - Q: The "sQuare signal" bit is toggled every N outgoing packets as 122 explained below in Section 3.1. 124 - L: The "Loss event" bit is set to 0 or 1 according to the 125 Unreported Loss counter, as explained below in Section 3.2. 127 Each endpoint maintains appropriate counters independently and 128 separately for each connection 4-tuple and destination Connection ID. 130 3.1. Setting the sQuare Bit on Outgoing Packets 132 The sQuare Value is initialized to the Initial Q Value (0 or 1) and 133 is reflected in the Q bit of every outgoing packet. The sQuare value 134 is inverted after sending every N packets (Q Period is 2*N), where N 135 is a parameter of the method, discussed below. 137 Observation points can estimate the upstream losses by counting the 138 number of packets during a half period of the square signal, as 139 described in Section 4. 141 3.1.1. Q Period Selection 143 The sender is expected to choose Q Period based on the expected 144 amount of loss and reordering on the path (see Section 4.2). The Q 145 Period value MUST be at least 128 and be a power of 2. This 146 requirement allows an Observer to infer the Q Period by obsering one 147 period of the square signal. It also allows the Observer to identify 148 flows that set the loss bits to arbitrary values (see Section 5). 150 If the sender does not have sufficient information to make an 151 informed decision about Q Period, the sender SHOULD use Q Period of 152 128. 154 3.2. Setting the Loss Event Bit on Outgoing Packets 156 The Unreported Loss counter is initialized to 0, and the L bit of 157 every outgoing packet indicates whether the Unreported Loss counter 158 is positive (L=1 if the counter is positive, and L=0 otherwise). The 159 value of the Unreported Loss counter is decremented every time a 160 packet with L=1 is sent. 162 The value of the Unreported Loss counter is incremented for every 163 packet that the protocol declares lost, using QUIC's existing loss 164 detection machinery. 166 This loss signaling is similar to loss signaling in [RFC7713], except 167 the Loss Event bit is reporting the exact number of lost packets, 168 whereas Echo Loss bit in [RFC7713] is reporting an approximate number 169 of lost bytes. 171 Observation points can estimate the end-to-end loss, as determined by 172 the upstream endpoint's loss detection machinery, by counting packets 173 in this direction with a L bit equal to 1, as described in Section 4. 175 4. Using the Loss Bits for Passive Loss Measurement 177 There are three sources of observable loss: 179 - _upstream loss_ - loss between the sender and the observation 180 point (Section 4.2) 182 - _downstream loss_ - loss between the observation point and the 183 destination (Section 4.4) 185 - _observer loss_ - loss by the observer itself that does not cause 186 downstream loss (Section 4.5) 188 The upstream and downstream loss together constitute _end-to-end 189 loss_ (Section 4.1). 191 The Q and L bits allow detection and measurement of the types of loss 192 listed above. 194 4.1. End-To-End Loss 196 The Loss Event bit allows an observer to calculate the end-to-end 197 loss rate by counting packets with L bit value of 0 and 1 for a given 198 connection. The end-to-end loss rate is the fraction of packets with 199 L=1. 201 The simplifying assumption here is that upstream loss affects packets 202 with L=0 and L=1 equally. This may be a simplification, if some loss 203 is caused by tail-drop in a network device. If the sender congestion 204 controller reduces the packet send rate after loss, there may be a 205 sufficient delay before sending packets with L=1 that they have a 206 greater chance of arriving at the observer. 208 4.2. Upstream Loss 210 Blocks of N (half of Q Period) consecutive packets are sent with the 211 same value of the Q bit, followed by another block of N packets with 212 inverted value of the Q bit. Hence, knowing the value of N, an on- 213 path observer can estimate the amount of loss after observing at 214 least N packets. The upstream loss rate is one minus the average 215 number of packets in a block of packets with the same Q value divided 216 by N. 218 The observer needs to be able to tolerate packet reordering that can 219 blur the edges of the square signal. 221 The observer also needs to differentiate packets as belonging to 222 different connections, since they use independent counters. 224 The choice of N strikes a compromise: the observation could become 225 too unreliable in case of packet reordering and loss if N is too 226 small; and when N is too large, short connections may not yield a 227 useful upstream loss measurement. 229 To leave some room for adaptation, we only constrain the sender to 230 select an N that is (1) constant for a given connection and (2) equal 231 to a power of two. The latter allows on-path observers to derive N 232 after a few periods. It is thus also acceptable for a simple 233 implementation to choose a global constant; N=64 has been extensively 234 tried in large-scale field tests and yielded good results. 236 4.3. Correlating End-to-End and Upstream Loss 238 Upstream loss is calculated by observing the actual packets that did 239 not suffer the upstream loss. End-to-end loss, however, is 240 calculated by observing subsequent packets after the sender's 241 protocol detected the loss. Hence, end-to-end loss is generally 242 observed with a delay of between 1 RTT (loss declared due to multiple 243 duplicate acknowledgments) and 1 RTO (loss declared due to a timeout) 244 relative to the upstream loss. 246 The connection RTT can sometimes be estimated by timing protocol 247 handshake messages. This RTT estimate can be greatly improved by 248 observing a dedicated protocol mechanism for conveying RTT 249 information, such as the Latency Spin bit of [QUIC-TRANSPORT]. 251 Whenever the observer needs to perform a computation that uses both 252 upstream and end-to-end loss rate measurements, it SHOULD use 253 upstream loss rate leading the end-to-end loss rate by approximately 254 1 RTT. If the observer is unable to estimate RTT of the connection, 255 it should accumulate loss measurements over time periods of at least 256 4 times the typical RTT for the observed connections. 258 If the calculated upstream loss rate exceeds the end-to-end loss rate 259 calculated in Section 4.1, then either the Q Period is too short for 260 the amount of packet reordering or there is observer loss, described 261 in Section 4.5. If this happens, the observer SHOULD adjust the 262 calculated upstream loss rate to match end-to-end loss rate. 264 4.4. Downstream Loss 266 Because downstream loss affects only those packets that did not 267 suffer upstream loss, the end-to-end loss rate ("e") relates to the 268 upstream loss rate ("u") and downstream loss rate ("d") as 269 "(1-u)(1-d)=1-e". Hence, "d=(e-u)/(1-u)". 271 4.5. Observer Loss 273 A typical deployment of a passive observation system includes a 274 network tap device that mirrors network packets of interest to a 275 device that performs analysis and measurement on the mirrored 276 packets. The observer loss is the loss that occurs on the mirror 277 path. 279 Observer loss affects upstream loss rate measurement since it causes 280 the observer to account for fewer packets in a block of identical Q 281 bit values (see {{upstreamloss)}). The end-to-end loss rate 282 measurement, however, is unaffected by the observer loss, since it is 283 a measurement of the fraction of packets with the set L bit value, 284 and the observer loss would affect all packets equally (see 285 Section 4.1). 287 The need to adjust the upstream loss rate down to match end-to-end 288 loss rate as described in Section 4.3 is a strong indication of the 289 observer loss, whose magnitude is between the amount of such 290 adjustment and the entirety of the upstream loss measured in 291 Section 4.2. 293 5. Ossification Considerations 295 Accurate loss information is not critical to the operation of any 296 protocol, though its presence for a sufficient number of connections 297 is important for the operation of the networks. 299 The loss bits are amenable to "greasing" described in [GREASE], if 300 the protocol designers are not ready to dedicate (and ossify) bits 301 used for loss reporting to this function. The greasing could be 302 accomplished similarly to the Latency Spin bit greasing in 303 [QUIC-TRANSPORT]. Namely, implementations could decide that a 304 fraction of connections should not encode loss information in the 305 loss bits and, instead, the bits would be set to arbitrary values. 306 The observers would need to be ready to ignore connections with loss 307 information more resembling noise than the expected signal. 309 6. Security Considerations 311 Passive loss observation has been a part of the network operations 312 for a long time, so exposing loss information to the network does not 313 add new security concerns. 315 7. Privacy Considerations 317 Guarding user's privacy is an important goal for modern protocols and 318 protocol extensions per [RFC7258]. While an explicit loss signal - a 319 preferred way to share loss information per [RFC8558] - helps to 320 minimize unintentional exposure of additional information, 321 implementations of loss reporting must ensure that loss information 322 does not compromise protocol's privacy goals. 324 For example, [QUIC-TRANSPORT] allows changing Connection IDs in the 325 middle of a connection to reduce the likelihood of a passive observer 326 linking old and new subflows to the same device. A QUIC 327 implementation would need to reset all counters when it changes 328 Connection ID used for outgoing packets. It would also need to avoid 329 incrementing Unreported Loss counter for loss of packets sent with a 330 different Connection ID. 332 8. IANA Considerations 334 This document makes no request of IANA. 336 8.1. Since version 01 338 - Add reference to RFC7713 340 8.2. Since version 00 342 - Rewrote to base this draft on [LOSSBITS] 344 9. Acknowledgments 346 The sQuare Bit was originally specified by Kazuho Oku in early 347 proposals for loss measurement and is an instance of the "alternate 348 marking" as defined in [RFC8321]. 350 10. References 352 10.1. Normative References 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, 356 DOI 10.17487/RFC2119, March 1997, 357 . 359 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 360 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 361 "Alternate-Marking Method for Passive and Hybrid 362 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 363 January 2018, . 365 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 366 RFC 8558, DOI 10.17487/RFC8558, April 2019, 367 . 369 10.2. Informative References 371 [GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", 372 draft-ietf-tls-grease-04 (work in progress), August 2019. 374 [LOSSBITS] 375 Ferrieux, A., Hamchaoui, I., and I. Lubashev, "Packet Loss 376 Signaling for Encrypted Protocols", draft- 377 ferrieuxhamchaoui-tsvwg-lossbits-01 (work in progress), 378 July 2019. 380 [QUIC-TRANSPORT] 381 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 382 and Secure Transport", draft-ietf-quic-transport-24 (work 383 in progress), September 2019. 385 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 386 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 387 2014, . 389 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 390 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 391 DOI 10.17487/RFC7713, December 2015, 392 . 394 [TRANSPORT-ENCRYPT] 395 Fairhurst, G. and C. Perkins, "The Impact of Transport 396 Header Confidentiality on Network Operation and Evolution 397 of the Internet", draft-ietf-tsvwg-transport-encrypt-09 398 (work in progress), August 2019. 400 Authors' Addresses 402 Alexandre Ferrieux (editor) 403 Orange Labs 405 EMail: alexandre.ferrieux@orange.com 407 Isabelle Hamchaoui (editor) 408 Orange Labs 410 EMail: isabelle.hamchaoui@orange.com 412 Igor Lubashev (editor) 413 Akamai Technologies 414 150 Broadway 415 Cambridge, MA 1122 416 USA 418 EMail: ilubashe@akamai.com