idnits 2.17.1 draft-cnbf-ippm-user-devices-explicit-monitoring-03.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 25, 2021) is 907 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 8321 (ref. 'AltMark') (Obsoleted by RFC 9341) == Outdated reference: A later version (-07) exists of draft-ietf-ippm-explicit-flow-measurements-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM M. Cociglio 3 Internet-Draft M. Nilo 4 Intended status: Informational F. Bulgarella 5 Expires: April 28, 2022 Telecom Italia - TIM 6 G. Fioccola 7 Huawei Technologies 8 October 25, 2021 10 User Devices Explicit Monitoring 11 draft-cnbf-ippm-user-devices-explicit-monitoring-03 13 Abstract 15 This document describes a methodology to monitor network performance 16 exploiting user devices. This can be achieved using the Explicit 17 Flow Measurement Techniques, protocol independent methods that employ 18 few marking bits, inside the header of each packet, for loss and 19 delay measurement. User devices and servers, marking the traffic, 20 signal these metrics to intermediate network observers allowing them 21 to measure connection performance, and to locate the network segment 22 where impairments happen. In addition or in alternative to network 23 observers, a probe can be installed on the user device with 24 remarkable benefits in terms of hardware deployment and measurement 25 scalability. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 28, 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 63 3. Explicit Performance Open Issues . . . . . . . . . . . . . . 3 64 4. Explicit Performance Probes on User Devices . . . . . . . . . 3 65 5. Device Owner Activates Explicit Performance Measurements . . 4 66 6. Who Will Handle the Performance Data? . . . . . . . . . . . . 4 67 7. The Explicit Performance App . . . . . . . . . . . . . . . . 5 68 8. Improvements of Explicit Flow Measurement Techniques Using 69 Probes on User Devices . . . . . . . . . . . . . . . . . . . 5 70 8.1. Hidden Delay Bit Considerations . . . . . . . . . . . . . 5 71 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 72 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 76 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 77 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 15.1. Normative References . . . . . . . . . . . . . . . . . . 6 79 15.2. Informative References . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 Explicit Performance Monitoring enables a passive observer (a probe) 85 to measure delay and loss just watching the marking (a few header 86 bits) of live traffic packets. It works on client-server protocols: 87 e.g. QUIC [QUIC-TRANSPORT], TCP [TCP]. The different methods are 88 described in [EXPLICIT-FLOW-MEASUREMENTS] and are inspired by 89 [AltMark]. 91 This document explains how to employ the methods described in 92 [EXPLICIT-FLOW-MEASUREMENTS] by proposing the user device as a 93 convenient place for the Explicit Performance Observer. 95 2. Notational Conventions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Explicit Performance Open Issues 103 There are some open issues to consider for the deployment of 104 [EXPLICIT-FLOW-MEASUREMENTS]: 106 - Who decides whether to mark traffic? Explicit measures only work 107 if both the server and the client mark the production traffic. 109 - What about scalability? Could network probes monitor all the 110 connections? If they cannot, which ones to choose? 112 - Which connections to monitor within the network? Network probes 113 need an effective way to identify which connections really need to 114 be monitored. 116 - How to monitor both traffic directions? Not always possible for 117 network probes (asymmetric connections). 119 4. Explicit Performance Probes on User Devices 121 This document proposes the user device (e.g. mobile phones, PCs) as a 122 convenient place where to put the Explicit Performance Observer. 124 The placement of the observer on the user device helps to mitigate 125 the issues reported in the previous section, in particular: 127 - The device should decide whether to mark the traffic or not. 129 - Regarding the scalability issue, on the user device there are few 130 connections to monitor so it becomes less relevant. 132 - Connections eligible for monitoring should be the impaired ones. 133 User devices and network probes can cooperate to achieve this 134 goal. It is possible to set alarm thresholds on the user device 135 and to signal to the network probes only the sessions with 136 impairments. This allows to segment the performance measurements 137 and to locate the faults. In this way network probes, that could 138 also be embedded into network nodes, have to monitor a limited 139 number of connections. 141 - Monitoring both directions is always possible on the user device. 143 5. Device Owner Activates Explicit Performance Measurements 145 The decision whether to activate the marking (e.g. [SPIN-BIT], 146 [ANRW19-PM-QUIC], [EXPLICIT-FLOW-MEASUREMENTS]) or not should be made 147 by the device owner by properly configuring the applications (e.g. 148 browsers) based on connection-oriented protocols that support 149 explicit measurements (e.g. QUIC). 151 All applications should provide the activation or deactivation of 152 packet marking, for example by providing an user interface or 153 exposing API. 155 So, during the client-server handshake, the client will decide 156 whether the marking is active or not within a session and notify its 157 decision to the server. 159 An example of a simple explicit marking agreement of a protocol is 160 the following. This works if the usage of each performance bit is 161 unique and predefined. An endpoint set to 0 all the explicit 162 performance measurement bits to indicate its intention not to mark. 163 Then: 165 - the client set at least one of its marking bits to 1 notifying the 166 server of its intention to use that/those marking bits; the server 167 adapts according to the client's will; 169 - the server set at least one of its marking bits to 1; if the 170 client does not start marking the same bit/bits, then the marking 171 for that/those bits is aborted. 173 The best would be if both client and server started using the same 174 marking bits from the beginning of the connection. In this case no 175 alignment between endpoints would be required. This mechanism works 176 best if, where possible, measurements start using 1 as the first 177 marking value. 179 6. Who Will Handle the Performance Data? 181 Performance data are stored only on the user device or also sent to 182 "external bodies" according to the will of the device owner. 184 The main recipient would be the Internet Service Provider. Indeed, 185 as explained in the previous section, this enables user device and 186 network probes coordination that permits an improved performance 187 measurement approach. 189 Moreover these data could also be of interest for the national 190 regulatory authorities or others authorized subjects. 192 7. The Explicit Performance App 194 This methodology could be implemented with an "Explicit Performance 195 App" installed on the user device. 197 The App should perform the following tasks: 199 - collect user preferences; 201 - activate/deactivate marking on device Apps (e.g. browsers); 203 - implement the observer; 205 - show performances to the user; 207 - send data to the "Explicit Performance Management Center"; 209 - set performance thresholds. 211 8. Improvements of Explicit Flow Measurement Techniques Using Probes on 212 User Devices 214 - Spin bit and Delay bit: the observer-server RTT component measured 215 on the user device is equivalent to the RTT, but without including 216 the client-side application delay and therefore more precise. 218 - sQuare bit: would measure the End-to-End loss rate in the download 219 direction instead of upstream loss rate. 221 - Loss event bit: would measure, as before, the End-to-End loss rate 222 in both directions. Moreover, in the upload direction, the signal 223 would be "clean" since it is captured at the origin and therefore 224 not affected by losses. 226 - Reflection square bit: would measure the RT loss rate instead of 227 three-quarters connection loss rate. 229 8.1. Hidden Delay Bit Considerations 231 The Explicit Flow Measurements draft introduces a new Delay Bit 232 feature capable of masking the RTT of the connection to the observers 233 on the network. To use this feature, the client must select an 234 Additional Delay used to delay the client-side reflection of marked 235 samples. Clearly, the introduction by the client of a reflection 236 delay makes the client-observer component of the RTT inaccurate. 238 Using this feature on a user device probe has several advantages: 240 - A system-wide Additional Delay can be selected and periodically 241 updated making it common to all applications installed on the 242 device. 244 - The hidden Delay Bit produces the same metrics of the Delay Bit 245 since the observer-server RTT, measured on the client, is equal to 246 the end-to-end RTT of the connection. 248 - The user device can easily communicate the Additional Delay to 249 network probes whenever an alarm threshold is triggered. In this 250 way, the observer can compute the e2e RTT of the connection. 252 9. Security Considerations 254 TBD 256 10. Privacy Considerations 258 TBD 260 11. IANA Considerations 262 This document makes no request of IANA. 264 12. Change Log 266 TBD 268 13. Contributors 270 TBD 272 14. Acknowledgements 274 TBD 276 15. References 278 15.1. Normative References 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, 282 DOI 10.17487/RFC2119, March 1997, 283 . 285 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 286 RFC 793, DOI 10.17487/RFC0793, September 1981, 287 . 289 15.2. Informative References 291 [AltMark] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 292 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 293 "Alternate-Marking Method for Passive and Hybrid 294 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 295 January 2018, . 297 [ANRW19-PM-QUIC] 298 Bulgarella, F., Cociglio, M., Fioccola, G., Marchetto, G., 299 and R. Sisto, "Performance measurements of QUIC 300 communications", Proceedings of the Applied Networking 301 Research Workshop, DOI 10.1145/3340301.3341127, July 2019. 303 [EXPLICIT-FLOW-MEASUREMENTS] 304 Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I., 305 Bulgarella, F., Hamchaoui, I., Nilo, M., Sisto, R., and D. 306 Tikhonov, "Explicit Flow Measurements Techniques", draft- 307 ietf-ippm-explicit-flow-measurements-00 (work in 308 progress), October 2021. 310 [QUIC-TRANSPORT] 311 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 312 Multiplexed and Secure Transport", RFC 9000, 313 DOI 10.17487/RFC9000, May 2021, 314 . 316 [SPIN-BIT] 317 Trammell, B., Vaere, P. D., Even, R., Fioccola, G., 318 Fossati, T., Ihlar, M., Morton, A., and E. Stephan, 319 "Adding Explicit Passive Measurability of Two-Way Latency 320 to the QUIC Transport Protocol", draft-trammell-quic- 321 spin-03 (work in progress), May 2018. 323 Authors' Addresses 325 Mauro Cociglio 326 Telecom Italia - TIM 327 Via Reiss Romoli, 274 328 Torino 10148 329 Italy 331 EMail: mauro.cociglio@telecomitalia.it 332 Massimo Nilo 333 Telecom Italia - TIM 334 Via Reiss Romoli, 274 335 Torino 10148 336 Italy 338 EMail: massimo.nilo@telecomitalia.it 340 Fabio Bulgarella 341 Telecom Italia - TIM 342 Via Reiss Romoli, 274 343 Torino 10148 344 Italy 346 EMail: fabio.bulgarella@guest.telecomitalia.it 348 Giuseppe Fioccola 349 Huawei Technologies 350 Riesstrasse, 25 351 Munich 80992 352 Germany 354 EMail: giuseppe.fioccola@huawei.com