idnits 2.17.1 draft-cnbf-ippm-user-devices-explicit-monitoring-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2020) is 1277 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 30, 2021 Telecom Italia (TIM) 6 G. Fioccola 7 Huawei Technologies 8 October 27, 2020 10 User Devices Explicit Monitoring 11 draft-cnbf-ippm-user-devices-explicit-monitoring-00 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 30, 2021. 44 Copyright Notice 46 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . 2 63 3. Explicit Performance Open Issues . . . . . . . . . . . . . . 3 64 4. Explicit Performance Probes on User Devices . . . . . . . . . 3 65 5. Device Owner Activates Explicit Performance Measurement . . . 3 66 6. Who Will Handle the Performance Data? . . . . . . . . . . . . 4 67 7. The Explicit Performance App . . . . . . . . . . . . . . . . 4 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 70 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 73 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 14.1. Normative References . . . . . . . . . . . . . . . . . . 5 76 14.2. Informative References . . . . . . . . . . . . . . . . . 5 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 Explicit Performance Monitoring enables a passive observer (a probe) 82 to measure delay and loss just watching the marking (a few header 83 bits) of live traffic packets. It works on client-server protocols: 84 e.g. QUIC [QUIC-TRANSPORT], TCP [TCP]. The different methods are 85 described in [EXPLICIT-FLOW-MEASUREMENTS]. 87 This document explains how to employ the methods described in 88 [EXPLICIT-FLOW-MEASUREMENTS] by proposing the user device as a 89 convenient place for the Explicit Performance Observer. 91 2. Notational Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Explicit Performance Open Issues 99 There are some open issues to consider for the deployment of 100 [EXPLICIT-FLOW-MEASUREMENTS]: 102 - Who decides whether to mark traffic? Explicit measures only work 103 if both the server and the client mark the production traffic. 105 - What about scalability? Could network probes monitor all the 106 connections? If they cannot, which ones to choose? 108 - Which connections to monitor within the network? Network probes 109 need an effective way to identify which connections really need to 110 be monitored. 112 - How to monitor both traffic directions? Not always possible for 113 network probes (asymmetric connections). 115 4. Explicit Performance Probes on User Devices 117 This document proposes the user device (e.g. mobile phones, PCs) as a 118 convenient place where to put the Explicit Performance Observer. 120 The placement of the observer on the user device helps to mitigate 121 the issues reported in the previous section, in particular: 123 - The device should decide whether to mark the traffic or not. 125 - Regarding the scalability issue, on the user device there are few 126 connections to monitor so it becomes less relevant. 128 - Connections eligible for monitoring should be the impaired ones. 129 User devices and network probes can cooperate to achieve this 130 goal. It is possible to set alarm thresholds on the user device 131 and to signal to the network probes only the sessions with 132 impairments. This allows to segment the performance measurements 133 and to locate the faults. In this way network probes, that could 134 also be embedded into network nodes, have to monitor a limited 135 number of connections. 137 - Monitoring both directions is always possible on the user device. 139 5. Device Owner Activates Explicit Performance Measurement 141 The decision whether to activate the marking (e.g. [SPIN-BIT], 142 [ANRW19-PM-QUIC], [EXPLICIT-FLOW-MEASUREMENTS]) or not should be made 143 by the device owner by properly configuring the applications (e.g. 145 browsers) based on connection-oriented protocols that support 146 explicit measurements (e.g. QUIC). 148 All applications should provide the activation or deactivation of 149 packet marking, for example by providing a user interface or exposing 150 API. 152 So, during the client-server handshake, the client will decide 153 whether the marking is active or not within a session and notify its 154 decision to the server. 156 6. Who Will Handle the Performance Data? 158 Performance data are stored only on the user device or also sent to 159 "external bodies" according to the will of the device owner. 161 The main recipient would be the Internet Service Provider. Indeed, 162 as explained in the previous section, this enables user device and 163 network probes coordination that permits an improved performance 164 measurement approach. 166 Moreover these data could also be of interest for the national 167 regulatory authorities or others authorized subjects. 169 7. The Explicit Performance App 171 This methodology could be implemented with an "Explicit Performance 172 App" installed on the user device. 174 The App should perform the following tasks: 176 - collect user preferences; 178 - activate/deactivate marking on device Apps (e.g. browsers); 180 - implement the observer; 182 - show performances to the user; 184 - send data to the "Explicit Performance Management Center"; 186 - set performance thresholds. 188 8. Security Considerations 190 TBD 192 9. Privacy Considerations 194 TBD 196 10. IANA Considerations 198 This document makes no request of IANA. 200 11. Change Log 202 TBD 204 12. Contributors 206 TBD 208 13. Acknowledgements 210 TBD 212 14. References 214 14.1. Normative References 216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 217 Requirement Levels", BCP 14, RFC 2119, 218 DOI 10.17487/RFC2119, March 1997, 219 . 221 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 222 RFC 793, DOI 10.17487/RFC0793, September 1981, 223 . 225 14.2. Informative References 227 [ANRW19-PM-QUIC] 228 Bulgarella, F., Cociglio, M., Fioccola, G., Marchetto, G., 229 and R. Sisto, "Performance measurements of QUIC 230 communications", Proceedings of the Applied Networking 231 Research Workshop, DOI 10.1145/3340301.3341127, July 2019. 233 [EXPLICIT-FLOW-MEASUREMENTS] 234 Cociglio, M., Fioccola, G., Nilo, M., Bulgarella, F., and 235 R. Sisto, "Client-Server Explicit Performance 236 Measurements", draft-cfb-ippm-spinbit-measurements-02 237 (work in progress), July 2020. 239 [QUIC-TRANSPORT] 240 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 241 and Secure Transport", draft-ietf-quic-transport-32 (work 242 in progress), October 2020. 244 [SPIN-BIT] 245 Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, 246 T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit 247 Passive Measurability of Two-Way Latency to the QUIC 248 Transport Protocol", draft-trammell-quic-spin-03 (work in 249 progress), May 2018. 251 Authors' Addresses 253 Mauro Cociglio 254 Telecom Italia (TIM) 255 Via Reiss Romoli, 274 256 Torino 10148 257 Italy 259 EMail: mauro.cociglio@telecomitalia.it 261 Massimo Nilo 262 Telecom Italia (TIM) 263 Via Reiss Romoli, 274 264 Torino 10148 265 Italy 267 EMail: massimo.nilo@telecomitalia.it 269 Fabio Bulgarella 270 Telecom Italia (TIM) 271 Via Reiss Romoli, 274 272 Torino 10148 273 Italy 275 EMail: fabio.bulgarella@guest.telecomitalia.it 277 Giuseppe Fioccola 278 Huawei Technologies 279 Riesstrasse, 25 280 Munich 80992 281 Germany 283 EMail: giuseppe.fioccola@huawei.com