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