idnits 2.17.1 draft-ferrieuxhamchaoui-tsvwg-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 (July 20, 2019) is 1740 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-tls-grease-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-22 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-21) exists of draft-ietf-tsvwg-transport-encrypt-07 == Outdated reference: A later version (-32) exists of draft-ietf-tsvwg-udp-options-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG A. Ferrieux 3 Internet-Draft I. Hamchaoui 4 Intended status: Informational Orange Labs 5 Expires: January 21, 2020 I. Lubashev 6 Akamai Technologies 7 July 20, 2019 9 Packet Loss Signaling for Encrypted Protocols 10 draft-ferrieuxhamchaoui-tsvwg-lossbits-01 12 Abstract 14 This document describes a protocol-independent method that employs 15 two bits to allow endpoints to signal packet loss in a way that can 16 be used by network devices to measure and locate the source of the 17 loss. The signaling method applies to all protocols with a protocol- 18 specific way to identify packet loss. The method is especially 19 valuable when applied to protocols that encrypt transport header and 20 do not allow an alternative method for loss detection. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 21, 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 58 3. Loss Bits . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Setting the sQuare Bit on Outgoing Packets . . . . . . . 3 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 . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 7 71 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9.1. Since version 00 . . . . . . . . . . . . . . . . . . . . 8 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 11.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 Packet loss is a pervasive problem of day-to-day network operation, 82 and proactively detecting, measuring, and locating it is crucial to 83 maintaining high QoS and timely resolution of crippling end-to-end 84 throughput issues. To this effect, in a TCP-dominated world, network 85 operators have been heavily relying on information present in the 86 clear in TCP headers: sequence and acknowledgment numbers and SACKs 87 when enabled (see [RFC8517]). These allow for quantitative 88 estimation of packet loss by passive on-path observation, and the 89 lossy segment (upstream or downstream from the observation point) can 90 be quickly identified by moving the passive observer around. 92 With encrypted protocols, the equivalent transport headers are 93 encrypted and passive packet loss observation is not possible, as 94 described in [TRANSPORT-ENCRYPT]. 96 Since encrypted protocols could be routed by the network differently, 97 and the fraction of Internet traffic delivered using encrypted 98 protocols is increasing every year, it is imperative to measure 99 packet loss experienced by encrypted protocol users directly instead 100 of relying on measuring TCP loss between similar endpoints. 102 Following the recommendation in [RFC8558] of making path signals 103 explicit, this document proposes adding two explicit loss bits to the 104 clear portion of the protocol headers to restore network operators' 105 ability to maintain high QoS for users of encrypted protocols. These 106 bits can be added to an unencrypted portion of a header belonging to 107 any protocol layer, e.g. IP (see [IP]) and IPv6 (see [IPv6]) headers 108 or extensions, UDP surplus space (see [UDP-OPTIONS] and 109 [UDP-SURPLUS]), reserved bits in a QUIC v1 header (see 110 [QUIC-TRANSPORT]). 112 2. Notational Conventions 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Loss Bits 120 The proposal introduces two bits that are to be present in every 121 packet capable of loss reporting. These are packets that include 122 protocol headers with the loss bits. Only loss of packets capable of 123 loss reporting is reported using loss bits. 125 Whenever this specification refers to packets, it is referring only 126 to packets capable of loss reporting. 128 - Q: The "sQuare signal" bit is toggled every N outgoing packets as 129 explained below in Section 3.1. 131 - L: The "Loss event" bit is set to 0 or 1 according to the 132 Unreported Loss counter, as explained below in Section 3.2. 134 Each endpoint maintains appropriate counters independently and 135 separately for each connection (each subflow for multipath 136 connections). 138 3.1. Setting the sQuare Bit on Outgoing Packets 140 The sQuare Value is initialized to the Initial Q Value (0 or 1) and 141 is reflected in the Q bit of every outgoing packet. The sQuare value 142 is inverted after sending every N packets (Q Period is 2*N). The Q 143 bit represents "packet color" as defined by [RFC8321]. 145 The choice of the Initial Q Value and Q Period is determined by the 146 protocol containing Q and L bits. For example, the values can be 147 protocol constants (e.g "Initial Q Value" is 0, and "Q Period" is 148 128), or they can be set explicitly for each connection (e.g. 149 "Initial Q Value" is whatever value the initial packet has, and "Q 150 Period" is set per a dedicated TCP option on SYN and SYN/ACK). 152 Observation points can estimate the upstream losses by counting the 153 number of packets during a half period of the square signal, as 154 described in Section 4. 156 3.2. Setting the Loss Event Bit on Outgoing Packets 158 The Unreported Loss counter is initialized to 0, and L bit of every 159 outgoing packet indicates whether the Unreported Loss counter is 160 positive (L=1 if the counter is positive, and L=0 otherwise). 162 The value of the Unreported Loss counter is decremented every time a 163 packet with L=1 is sent. 165 The value of the Unreported Loss counter is incremented for every 166 packet that the protocol declares lost, using whatever loss detection 167 machinery the protocol employs. If the protocol is able to rescind 168 the loss determination later, the Unreported Loss counter SHOULD NOT 169 be decremented due to the rescission. 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 upstream loss after 214 observing at least N packets. If "p" is the average number of 215 packets in a block of packets with the same Q value, then the 216 upstream loss is "1-p/N". 218 The observer needs to be able to tolerate packet reordering that can 219 blur the edges of the square signal. 221 The Q Period needs to be chosen carefully, since the observation 222 could become too unreliable in case of packet reordering and loss if 223 Q Period is too small. However, when Q Period is too large, 224 connections that send fewer than half Q Period packets do not yield a 225 useful upstream loss measurement. 227 The observer needs to differentiate packets as belonging to different 228 connections, since they use independent counters. 230 4.3. Correlating End-to-End and Upstream Loss 232 Upstream loss is calculated by observing the actual packets that did 233 not suffer the upstream loss. End-to-end loss, however, is 234 calculated by observing subsequent packets after the sender's 235 protocol detected the loss. Hence, end-to-end loss is generally 236 observed with a delay of between 1 RTT (loss declared due to multiple 237 duplicate acknowledgments) and 1 RTO (loss declared due to a timeout) 238 relative to the upstream loss. 240 The connection RTT can sometimes be estimated by timing protocol 241 handshake messages. This RTT estimate can be greatly improved by 242 observing a dedicated protocol mechanism for conveying RTT 243 information, such as the Latency Spin bit of [QUIC-TRANSPORT]. 245 Whenever the observer needs to perform a computation that uses both 246 upstream and end-to-end loss rate measurements, it SHOULD use 247 upstream loss rate leading the end-to-end loss rate by approximately 248 1 RTT. If the observer is unable to estimate RTT of the connection, 249 it should accumulate loss measurements over time periods of at least 250 4 times the typical RTT for the observed connections. 252 If the calculated upstream loss rate exceeds the end-to-end loss rate 253 calculated in Section 4.1, then either the Q Period is too short for 254 the amount of packet reordering or there is observer loss, described 255 in Section 4.5. If this happens, the observer SHOULD adjust the 256 calculated upstream loss rate to match end-to-end loss rate. 258 4.4. Downstream Loss 260 Because downstream loss affects only those packets that did not 261 suffer upstream loss, the end-to-end loss rate ("e") relates to the 262 upstream loss rate ("u") and downstream loss rate ("d") as 263 "(1-u)(1-d)=1-e". Hence, "d=(e-u)/(1-u)". 265 4.5. Observer Loss 267 A typical deployment of a passive observation system includes a 268 network tap device that mirrors network packets of interest to a 269 device that performs analysis and measurement on the mirrored 270 packets. The observer loss is the loss that occurs on the mirror 271 path. 273 Observer loss affects upstream loss rate measurement since it causes 274 the observer to account for fewer packets in a block of identical Q 275 bit values (see {{upstreamloss)}). The end-to-end loss rate 276 measurement, however, is unaffected by the observer loss, since it is 277 a measurement of the fraction of packets with the set L bit value, 278 and the observer loss would affect all packets equally (see 279 Section 4.1). 281 The need to adjust the upstream loss rate down to match end-to-end 282 loss rate as described in Section 4.3 is a strong indication of the 283 observer loss, whose magnitude is between the amount of such 284 adjustment and the entirety of the upstream loss measured in 285 Section 4.2. 287 5. Ossification Considerations 289 Accurate loss information is not critical to the operation of any 290 protocol, though its presence for a sufficient number of connections 291 is important for the operation of the networks. 293 The loss bits are amenable to "greasing" described in [GREASE], if 294 the protocol designers are not ready to dedicate (and ossify) bits 295 used for loss reporting to this function. The greasing could be 296 accomplished similarly to the Latency Spin bit greasing in 297 [QUIC-TRANSPORT]. Namely, implementations could decide that a 298 fraction of connections should not encode loss information in the 299 loss bits and, instead, the bits would be set to arbitrary values. 300 The observers would need to be ready to ignore connections with loss 301 information more resembling noise than the expected signal. 303 6. Security Considerations 305 Passive loss observation has been a part of the network operations 306 for a long time, so exposing loss information to the network does not 307 add new security concerns. 309 7. Privacy Considerations 311 Guarding user's privacy is an important goal for modern protocols and 312 protocol extensions per [RFC7285]. While an explicit loss signal - a 313 preferred way to share loss information per [RFC8558] - helps to 314 minimize unintentional exposure of additional information, 315 implementations of loss reporting must ensure that loss information 316 does not compromise protocol's privacy goals. 318 For example, [QUIC-TRANSPORT] allows changing Connection IDs in the 319 middle of a connection to reduce the likelihood of a passive observer 320 linking old and new subflows to the same device. A QUIC 321 implementation would need to reset all counters when it changes the 322 destination (IP address or UDP port) or the Connection ID used for 323 outgoing packets. It would also need to avoid incrementing 324 Unreported Loss counter for loss of packets sent to a different 325 destinatoin or with a different Connection ID. 327 8. IANA Considerations 329 This document makes no request of IANA. 331 9. Change Log 333 9.1. Since version 00 335 - Addressed review comments 337 - Improved guidelines for privacy protections for QIUC 339 10. Acknowledgments 341 The sQuare bit was originally suggested by Kazuho Oku in early 342 proposals for loss measurement. 344 11. References 346 11.1. Normative References 348 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 349 DOI 10.17487/RFC0791, September 1981, 350 . 352 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 353 (IPv6) Specification", STD 86, RFC 8200, 354 DOI 10.17487/RFC8200, July 2017, 355 . 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 363 RFC 8558, DOI 10.17487/RFC8558, April 2019, 364 . 366 11.2. Informative References 368 [GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", 369 draft-ietf-tls-grease-02 (work in progress), January 2019. 371 [QUIC-TRANSPORT] 372 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 373 and Secure Transport", draft-ietf-quic-transport-22 (work 374 in progress), July 2019. 376 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 377 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 378 "Application-Layer Traffic Optimization (ALTO) Protocol", 379 RFC 7285, DOI 10.17487/RFC7285, September 2014, 380 . 382 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 383 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 384 "Alternate-Marking Method for Passive and Hybrid 385 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 386 January 2018, . 388 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 389 Jacquenet, "An Inventory of Transport-Centric Functions 390 Provided by Middleboxes: An Operator Perspective", 391 RFC 8517, DOI 10.17487/RFC8517, February 2019, 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-07 398 (work in progress), July 2019. 400 [UDP-OPTIONS] 401 Touch, J., "Transport Options for UDP", draft-ietf-tsvwg- 402 udp-options-07 (work in progress), March 2019. 404 [UDP-SURPLUS] 405 Herbert, T., "UDP Surplus Header", draft-herbert-udp- 406 space-hdr-01 (work in progress), July 2019. 408 Authors' Addresses 410 Alexandre Ferrieux 411 Orange Labs 413 EMail: alexandre.ferrieux@orange.com 415 Isabelle Hamchaoui 416 Orange Labs 418 EMail: isabelle.hamchaoui@orange.com 419 Igor Lubashev 420 Akamai Technologies 421 150 Broadway 422 Cambridge, MA 1122 423 USA 425 EMail: ilubashe@akamai.com