IPPM M. Cociglio Internet-Draft M. Nilo Intended status: Informational F. Bulgarella Expires: April 30, 2021 Telecom Italia (TIM) G. Fioccola Huawei Technologies October 27, 2020 User Devices Explicit Monitoring draft-cnbf-ippm-user-devices-explicit-monitoring-00 Abstract This document describes a methodology to monitor network performance exploiting user devices. This can be achieved using the Explicit Flow Measurement Techniques, protocol independent methods that employ few marking bits, inside the header of each packet, for loss and delay measurement. User devices and servers, marking the traffic, signal these metrics to intermediate network observers allowing them to measure connection performance, and to locate the network segment where impairments happen. In addition or in alternative to network observers, a probe can be installed on the user device with remarkable benefits in terms of hardware deployment and measurement scalability. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 30, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. Cociglio, et al. Expires April 30, 2021 [Page 1] Internet-Draft User Device Probe October 2020 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 2 3. Explicit Performance Open Issues . . . . . . . . . . . . . . 3 4. Explicit Performance Probes on User Devices . . . . . . . . . 3 5. Device Owner Activates Explicit Performance Measurement . . . 3 6. Who Will Handle the Performance Data? . . . . . . . . . . . . 4 7. The Explicit Performance App . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 5 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 5 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 14.1. Normative References . . . . . . . . . . . . . . . . . . 5 14.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Explicit Performance Monitoring enables a passive observer (a probe) to measure delay and loss just watching the marking (a few header bits) of live traffic packets. It works on client-server protocols: e.g. QUIC [QUIC-TRANSPORT], TCP [TCP]. The different methods are described in [EXPLICIT-FLOW-MEASUREMENTS]. This document explains how to employ the methods described in [EXPLICIT-FLOW-MEASUREMENTS] by proposing the user device as a convenient place for the Explicit Performance Observer. 2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Cociglio, et al. Expires April 30, 2021 [Page 2] Internet-Draft User Device Probe October 2020 3. Explicit Performance Open Issues There are some open issues to consider for the deployment of [EXPLICIT-FLOW-MEASUREMENTS]: - Who decides whether to mark traffic? Explicit measures only work if both the server and the client mark the production traffic. - What about scalability? Could network probes monitor all the connections? If they cannot, which ones to choose? - Which connections to monitor within the network? Network probes need an effective way to identify which connections really need to be monitored. - How to monitor both traffic directions? Not always possible for network probes (asymmetric connections). 4. Explicit Performance Probes on User Devices This document proposes the user device (e.g. mobile phones, PCs) as a convenient place where to put the Explicit Performance Observer. The placement of the observer on the user device helps to mitigate the issues reported in the previous section, in particular: - The device should decide whether to mark the traffic or not. - Regarding the scalability issue, on the user device there are few connections to monitor so it becomes less relevant. - Connections eligible for monitoring should be the impaired ones. User devices and network probes can cooperate to achieve this goal. It is possible to set alarm thresholds on the user device and to signal to the network probes only the sessions with impairments. This allows to segment the performance measurements and to locate the faults. In this way network probes, that could also be embedded into network nodes, have to monitor a limited number of connections. - Monitoring both directions is always possible on the user device. 5. Device Owner Activates Explicit Performance Measurement The decision whether to activate the marking (e.g. [SPIN-BIT], [ANRW19-PM-QUIC], [EXPLICIT-FLOW-MEASUREMENTS]) or not should be made by the device owner by properly configuring the applications (e.g. Cociglio, et al. Expires April 30, 2021 [Page 3] Internet-Draft User Device Probe October 2020 browsers) based on connection-oriented protocols that support explicit measurements (e.g. QUIC). All applications should provide the activation or deactivation of packet marking, for example by providing a user interface or exposing API. So, during the client-server handshake, the client will decide whether the marking is active or not within a session and notify its decision to the server. 6. Who Will Handle the Performance Data? Performance data are stored only on the user device or also sent to "external bodies" according to the will of the device owner. The main recipient would be the Internet Service Provider. Indeed, as explained in the previous section, this enables user device and network probes coordination that permits an improved performance measurement approach. Moreover these data could also be of interest for the national regulatory authorities or others authorized subjects. 7. The Explicit Performance App This methodology could be implemented with an "Explicit Performance App" installed on the user device. The App should perform the following tasks: - collect user preferences; - activate/deactivate marking on device Apps (e.g. browsers); - implement the observer; - show performances to the user; - send data to the "Explicit Performance Management Center"; - set performance thresholds. 8. Security Considerations TBD Cociglio, et al. Expires April 30, 2021 [Page 4] Internet-Draft User Device Probe October 2020 9. Privacy Considerations TBD 10. IANA Considerations This document makes no request of IANA. 11. Change Log TBD 12. Contributors TBD 13. Acknowledgements TBD 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . 14.2. Informative References [ANRW19-PM-QUIC] Bulgarella, F., Cociglio, M., Fioccola, G., Marchetto, G., and R. Sisto, "Performance measurements of QUIC communications", Proceedings of the Applied Networking Research Workshop, DOI 10.1145/3340301.3341127, July 2019. [EXPLICIT-FLOW-MEASUREMENTS] Cociglio, M., Fioccola, G., Nilo, M., Bulgarella, F., and R. Sisto, "Client-Server Explicit Performance Measurements", draft-cfb-ippm-spinbit-measurements-02 (work in progress), July 2020. Cociglio, et al. Expires April 30, 2021 [Page 5] Internet-Draft User Device Probe October 2020 [QUIC-TRANSPORT] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", draft-ietf-quic-transport-32 (work in progress), October 2020. [SPIN-BIT] Trammell, B., Vaere, P., Even, R., Fioccola, G., Fossati, T., Ihlar, M., Morton, A., and S. Emile, "Adding Explicit Passive Measurability of Two-Way Latency to the QUIC Transport Protocol", draft-trammell-quic-spin-03 (work in progress), May 2018. Authors' Addresses Mauro Cociglio Telecom Italia (TIM) Via Reiss Romoli, 274 Torino 10148 Italy EMail: mauro.cociglio@telecomitalia.it Massimo Nilo Telecom Italia (TIM) Via Reiss Romoli, 274 Torino 10148 Italy EMail: massimo.nilo@telecomitalia.it Fabio Bulgarella Telecom Italia (TIM) Via Reiss Romoli, 274 Torino 10148 Italy EMail: fabio.bulgarella@guest.telecomitalia.it Giuseppe Fioccola Huawei Technologies Riesstrasse, 25 Munich 80992 Germany EMail: giuseppe.fioccola@huawei.com Cociglio, et al. Expires April 30, 2021 [Page 6]