idnits 2.17.1 draft-ferrieuxhamchaoui-tsvwg-lossbits-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 8, 2019) is 1753 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-20 == Outdated reference: A later version (-21) exists of draft-ietf-tsvwg-transport-encrypt-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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 9, 2020 I. Lubashev 6 Akamai Technologies 7 July 8, 2019 9 Packet Loss Signaling for Encrypted Protocols 10 draft-ferrieuxhamchaoui-tsvwg-lossbits-00 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 9, 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 . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 10.2. Informative References . . . . . . . . . . . . . . . . . 8 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 77 1. Introduction 79 Packet loss is a pervasive problem of day-to-day network operation, 80 and proactively detecting, measuring, and locating it is crucial to 81 maintaining high QoS and timely resolution of crippling end-to-end 82 throughput issues. To this effect, in a TCP-dominated world, network 83 operators have been heavily relying on information present in the 84 clear in TCP headers: sequence and acknowledgment numbers, and SACK 85 when enabled. These allow for quantitative estimation of packet loss 86 by passive on-path observation, and the lossy segment (upstream or 87 downstream from the observation point) can be quickly identified by 88 moving the passive observer around. 90 With encrypted protocols, the equivalent transport headers are 91 encrypted and passive packet loss observation is not possible, as 92 described in [TRANSPORT-ENCRYPT]. 94 Since encrypted protocols could be routed by the network differently, 95 and the fraction of Internet traffic delivered using encrypted 96 protocols is increasing every year, it is imperative to measure 97 packet loss experienced by encrypted protocol users directly instead 98 of relying on measuring TCP loss between similar endpoints. 100 Following the recommendation in [RFC8558] of making path signals 101 explicit, this document proposes adding two explicit loss bits to the 102 clear portion of the protocol headers to restore network operators' 103 ability to maintain high QoS for users of encrypted protocols. These 104 bits can be added to an unencrypted portion of a header belonging to 105 any protocol layer, e.g. two most significant its of the TTL field in 106 IP (see [IP]) and IPv6 (see [IPv6]) headers or reserved bits in a 107 QUIC v1 header (see [QUIC-TRANSPORT]). 109 2. Notational Conventions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 3. Loss Bits 117 The proposal introduces two bits that are to be present in every 118 packet capable of loss reporting. These are packets that include 119 protocol headers with the loss bits. Only loss of packets capable of 120 loss reporting is reported using loss bits. 122 Whenever this specification refers to packets, it is referring only 123 to packets capable of loss reporting. 125 - Q: The "sQuare signal" bit is toggled every N outgoing packets as 126 explained below in Section 3.1. 128 - L: The "Loss event" bit is set to 0 or 1 according to the 129 Unreported Loss counter, as explained below in Section 3.2. 131 Each endpoint maintains appropriate counters independently and 132 separately for each connection (each subflow for multipath 133 connections). 135 3.1. Setting the sQuare Bit on Outgoing Packets 137 The sQuare Value is initialized to the Initial Q Value (0 or 1) and 138 is reflected in the Q bit of every outgoing packet. The sQuare value 139 is inverted after sending every N packets (Q Period is 2*N). 141 The choice of the Initial Q Value and Q Period is determined by the 142 protocol containing Q and L bits. For example, the values can be 143 protocol constants (e.g "Initial Q Value" is 0, and "Q Period" is 144 128), or they can be set explicitly for each connection (e.g. 146 "Initial Q Value" is whatever value the initial packet has, and "Q 147 Period" is set per a dedicated TCP option on SYN and SYN/ACK). 149 Observation points can estimate the upstream losses by counting the 150 number of packets during a half period of the square signal, as 151 described in Section 4. 153 3.2. Setting the Loss Event Bit on Outgoing Packets 155 The Unreported Loss counter is initialized to 0, and L bit of every 156 outgoing packet indicates whether the Unreported Loss counter is 157 positive (L=1 if the counter is positive, and L=0 otherwise). 159 The 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 whatever loss detection 164 machinery the protocol employs. If the protocol is able to rescind 165 the loss determination later, the Unreported Loss counter SHOULD NOT 166 be decremented due to the rescission. 168 Observation points can estimate the end-to-end loss, as determined by 169 the upstream endpoint's loss detection machinery, by counting packets 170 in this direction with a L bit equal to 1, as described in Section 4. 172 4. Using the Loss Bits for Passive Loss Measurement 174 There are three sources of observable loss: 176 - _upstream loss_ - loss between the sender and the observation 177 point (Section 4.2) 179 - _downstream loss_ - loss between the observation point and the 180 destination (Section 4.4) 182 - _observer loss_ - loss by the observer itself that does not cause 183 downstream loss (Section 4.5) 185 The upstream and downstream loss together constitute _end-to-end 186 loss_ (Section 4.1). 188 The Q and L bits allow detection and measurement of the types of loss 189 listed above. 191 4.1. End-To-End Loss 193 The Loss Event bit allows an observer to calculate the end-to-end 194 loss rate by counting packets with L bit value of 0 and 1 for a given 195 connection. The end-to-end loss rate is the fraction of packets with 196 L=1. 198 The simplifying assumption here is that upstream loss affects packets 199 with L=0 and L=1 equally. This may be a simplification, if some loss 200 is caused by tail-drop in a network device. If the sender congestion 201 controller reduces the packet send rate after loss, there may be a 202 sufficient delay before sending packets with L=1 that they have a 203 greater chance of arriving at the observer. 205 4.2. Upstream Loss 207 Blocks of N (half of Q Period) consecutive packets are sent with the 208 same value of the Q bit, followed by another block of N packets with 209 inverted value of the Q bit. Hence, knowing the value of N, an on- 210 path observer can estimate the amount of loss after observing at 211 least N packets. The upstream loss rate is an average number of 212 packets in a block of packets with the same Q value divided by N. 214 The observer needs to be able to tolerate packet reordering that can 215 blur the edges of the square signal. 217 The Q Period needs to be chosen carefully, since the observation 218 could become too unreliable in case of packet reordering and loss if 219 Q Period is too small. However, when Q Period is too large, short 220 connections may not yield a useful upstream loss measurement. 222 The observer needs to differentiate packets as belonging to different 223 connections, since they use independent counters. 225 4.3. Correlating End-to-End and Upstream Loss 227 Upstream loss is calculated by observing the actual packets that did 228 not suffer the upstream loss. End-to-end loss, however, is 229 calculated by observing subsequent packets after the sender's 230 protocol detected the loss. Hence, end-to-end loss is generally 231 observed with a delay of between 1 RTT (loss declared due to multiple 232 duplicate acknowledgments) and 1 RTO (loss declared due to a timeout) 233 relative to the upstream loss. 235 The connection RTT can sometimes be estimated by timing protocol 236 handshake messages. This RTT estimate can be greatly improved by 237 observing a dedicated protocol mechanism for conveying RTT 238 information, such as the Latency Spin bit of [QUIC-TRANSPORT]. 240 Whenever the observer needs to perform a computation that uses both 241 upstream and end-to-end loss rate measurements, it SHOULD use 242 upstream loss rate leading the end-to-end loss rate by approximately 243 1 RTT. If the observer is unable to estimate RTT of the connection, 244 it should accumulate loss measurements over time periods of at least 245 4 times the typical RTT for the observed connections. 247 If the calculated upstream loss rate exceeds the end-to-end loss rate 248 calculated in Section 4.1, then either the Q Period is too short for 249 the amount of packet reordering or there is observer loss, described 250 in Section 4.5. If this happens, the observer SHOULD adjust the 251 calculated upstream loss rate to match end-to-end loss rate. 253 4.4. Downstream Loss 255 Because downstream loss affects only those packets that did not 256 suffer upstream loss, the end-to-end loss rate ("e") relates to the 257 upstream loss rate ("u") and downstream loss rate ("d") as 258 "(1-u)(1-d)=1-e". Hence, "d=(e-u)/(1-u)". 260 4.5. Observer Loss 262 A typical deployment of a passive observation system includes a 263 network tap device that mirrors network packets of interest to a 264 device that performs analysis and measurement on the mirrored 265 packets. The observer loss is the loss that occurs on the mirror 266 path. 268 Observer loss affects upstream loss rate measurement since it causes 269 the observer to account for fewer packets in a block of identical Q 270 bit values (see {{upstreamloss)}). The end-to-end loss rate 271 measurement, however, is unaffected by the observer loss, since it is 272 a measurement of the fraction of packets with the set L bit value, 273 and the observer loss would affect all packets equally (see 274 Section 4.1). 276 The need to adjust the upstream loss rate down to match end-to-end 277 loss rate as described in Section 4.3 is a strong indication of the 278 observer loss, whose magnitude is between the amount of such 279 adjustment and the entirety of the upstream loss measured in 280 Section 4.2. 282 5. Ossification Considerations 284 Accurate loss information is not critical to the operation of any 285 protocol, though its presence for a sufficient number of connections 286 is important for the operation of the networks. 288 The loss bits are amenable to "greasing" described in [GREASE], if 289 the protocol designers are not ready to dedicate (and ossify) bits 290 used for loss reporting to this function. The greasing could be 291 accomplished similarly to the Latency Spin bit greasing in 292 [QUIC-TRANSPORT]. Namely, implementations could decide that a 293 fraction of connections should not encode loss information in the 294 loss bits and, instead, the bits would be set to arbitrary values. 295 The observers would need to be ready to ignore connections with loss 296 information more resembling noise than the expected signal. 298 6. Security Considerations 300 Passive loss observation has been a part of the network operations 301 for a long time, so exposing loss information to the network does not 302 add new security concerns. 304 7. Privacy Considerations 306 Guarding user's privacy is an important goal for modern protocols and 307 protocol extensions per [RFC7285]. While an explicit loss signal - a 308 preferred way to share loss information per [RFC8558] - helps to 309 minimize unintentional exposure of additional information, 310 implementations of loss reporting must ensure that loss information 311 does not compromise protocol's privacy goals. 313 For example, [QUIC-TRANSPORT] allows changing Connection IDs in the 314 middle of a connection to reduce the likelihood of a passive observer 315 linking old and new subflows to the same device. A QUIC 316 implementation would need to reset all counters when it changes 317 Connection ID used for outgoing packets. It would also need to avoid 318 incrementing Unreported Loss counter for loss of packets sent with a 319 different Connection ID. 321 8. IANA Considerations 323 This document makes no request of IANA. 325 9. Acknowledgments 327 The sQuare Bit was originally specified by Kazuho Oku in early 328 proposals for loss measurement. 330 10. References 331 10.1. Normative References 333 [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, 334 DOI 10.17487/RFC0791, September 1981, 335 . 337 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 338 (IPv6) Specification", STD 86, RFC 8200, 339 DOI 10.17487/RFC8200, July 2017, 340 . 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", 348 RFC 8558, DOI 10.17487/RFC8558, April 2019, 349 . 351 10.2. Informative References 353 [GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", 354 draft-ietf-tls-grease-02 (work in progress), January 2019. 356 [QUIC-TRANSPORT] 357 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 358 and Secure Transport", draft-ietf-quic-transport-20 (work 359 in progress), April 2019. 361 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 362 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 363 "Application-Layer Traffic Optimization (ALTO) Protocol", 364 RFC 7285, DOI 10.17487/RFC7285, September 2014, 365 . 367 [TRANSPORT-ENCRYPT] 368 Fairhurst, G. and C. Perkins, "The Impact of Transport 369 Header Confidentiality on Network Operation and Evolution 370 of the Internet", draft-ietf-tsvwg-transport-encrypt-07 371 (work in progress), July 2019. 373 Authors' Addresses 375 Alexandre Ferrieux 376 Orange Labs 378 EMail: alexandre.ferrieux@orange.com 379 Isabelle Hamchaoui 380 Orange Labs 382 EMail: isabelle.hamchaoui@orange.com 384 Igor Lubashev 385 Akamai Technologies 386 150 Broadway 387 Cambridge, MA 1122 388 USA 390 EMail: ilubashe@akamai.com