Re: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00
Michael Krüger <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Organization | VOIPFUTURE |
| Message-ID | <[email protected]> |
Hi Hendrik, Am 03.08.12 18:15, schrieb Paul Aitken: > Hendrik, > > >> >> Network Working Group H. Scholz >> Internet-Draft VOIPFUTURE GmbH >> Intended status: Informational July 9, 2012 >> Expires: January 10, 2013 >> >> >> RTP Stream Quality Information Export using IPFIX >> draft-scholz-ipfix-rtp-audio-quality-00 >> >> Abstract >> >> This draft defines a set of Information Elements and matching > > Remove "matching" > > >> Templates to convey RTP media stream quality information in IPFIX >> packets. The Information Elements describe the RTP quality using the >> R-factor and Mean Opinion score (MOS) for the entire duration of a >> monitored stream or for a smaller time slice thereof. >> >> 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 http://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 January 10, 2013. >> >> Copyright Notice >> >> Copyright (c) 2012 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://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. >> >> >> >> Scholz Expires January 10, 2013 [Page 1] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> This document may contain material from IETF Documents or IETF >> Contributions published or made publicly available before November >> 10, 2008. The person(s) controlling the copyright in some of this >> material may not have granted the IETF Trust the right to allow >> modifications of such material outside the IETF Standards Process. >> Without obtaining an adequate license from the person(s) controlling >> the copyright in such materials, this document may not be modified >> outside the IETF Standards Process, and derivative works of it may >> not be created outside the IETF Standards Process, except to format >> it for publication as an RFC or to translate it into languages other >> than English. >> >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 1.1.1. Quality of Service (QoS) Monitoring . . . . . . . . . 3 >> 1.1.2. Service Level Agreement (SLA) . . . . . . . . . . . . 3 >> 1.1.3. Troubleshooting . . . . . . . . . . . . . . . . . . . 3 >> 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3. MOS measurement . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3.1. rtpMOSCAlg . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 3.2. rtpMOSClass1 . . . . . . . . . . . . . . . . . . . . . . . 5 >> 3.3. rtpMOSClass2 . . . . . . . . . . . . . . . . . . . . . . . 5 >> 3.4. rtpMOSClass3 . . . . . . . . . . . . . . . . . . . . . . . 5 >> 3.5. rtpMOSClass4 . . . . . . . . . . . . . . . . . . . . . . . 6 >> 3.6. rtpMOSClass5 . . . . . . . . . . . . . . . . . . . . . . . 6 >> 3.7. rtpMinMOS . . . . . . . . . . . . . . . . . . . . . . . . 6 >> 3.8. rtpAvgMOS . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.9. rtpMaxMOS . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.10. rtpMinRFactor . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.11. rtpAvgRFactor . . . . . . . . . . . . . . . . . . . . . . 7 >> 3.12. rtpMaxRFactor . . . . . . . . . . . . . . . . . . . . . . 8 >> 4. Recommended Templates . . . . . . . . . . . . . . . . . . . . 8 >> 4.1. Entire stream . . . . . . . . . . . . . . . . . . . . . . 8 >> 4.2. Time slice . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 >> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 >> 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 >> 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 >> 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 >> 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 >> Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 2] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 1. Introduction >> >> IPFIX [RFC5101] and [RFC5102] define a framework allowing to export > > NB these references will need to be updated to -bis. > > "the export of arbitrary data". > > >> arbitrary data from so called IPFIX exporters. One type of IPFIX > > Why "so called"? They *are* IPFIX exporters! > > >> exporter may be co-located with Session Initiation Protocol (SIP) > > At least, the IPFIX Device's Metering Process is co-located with the SIP > devices / calls. The Exporting Process may be remote; you don't care. > > >> [RFC3261] based VoIP entities or passively observe SIP based VoIP >> calls. The signaling messages can be exported using >> [I-D.trammell-ipfix-sip-msg] and Real Time Protocol (RTP) [RFC3550] >> media streams are covered in [I-D.akhter-ipfix-perfmon]. Media >> quality is out of the scope of both these documents. This document >> defines a set of additional IPFIX Information Elements (IEs) to >> describe RTP audio stream quality. >> >> 1.1. Use Cases >> >> RTP stream flow information contained in IPFIX flow records can be >> used for various tasks such as Quality of Service (QoS) monitoring, >> Service Level Agreement (SLA) validation and general troubleshooting >> of VoIP networks. >> >> 1.1.1. Quality of Service (QoS) Monitoring >> >> Aggregated to higher-level metrics the in-depth information provided >> by the RTP (and optionally SIP) flow records allow service providers >> to gauge the overall quality of their network in terms of the quality >> of experience (QoE). On this level an individual call is less >> important but the overall quality (e.g. amount of minutes meeting >> certain quality standards) can be used to get a quick overview on the >> network and service performance. >> >> 1.1.2. Service Level Agreement (SLA) >> >> SLAs are typically used as part of contracts between two network >> operators. The requirements on the reliability of the data may be >> higher compared to QoS Monitoring as the failure to meet >> contractually agreed quality standards often has a direct commercial >> impact. >> >> 1.1.3. Troubleshooting >> >> An active network component (SIP proxy, B2BUA, media server) may not >> have the capabilities to store session related information for a long >> time to facilitate troubleshooting capabilities (e.g. due to missing >> hard-disk). Such a system or a group of systems may run the metering >> process and export the data to a collector for processing or > > say "run a Metering Process and export IPFIX to a Collecting Process for > ...", since MP and CP are 5101 terms. > > >> troubleshooting purposes. > > You might want to have a terminology section here, if only to refer > readers to 5101. See how the other IPFIX drafts do this. > > >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 3] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 2. 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 RFC 2119 [RFC2119]. >> >> >> 3. MOS measurement >> >> A multitude of Mean Opinion Score (MOS) assessment algorithms have >> been defined of which only one or few may be available to an IPFIX >> Metering Process. The quality (i.e. accuracy) of these algorithms > > Technically it's not an "IPFIX Metering Process" - it's a SIP Metering > Process connected to an IPFIX Exporting Process. > For simplicity, just say "available to the Metering Process". > > >> varies and has to be noted when transporting MOS values. >> >> An IPFIX Metering Process may use these Information Elements to >> convey information on the duration of the stream in which the quality >> fell into the respective category as well as the measurement >> algorithm used to obtain the information. >> >> 3.1. rtpMOSCAlg >> >> The values carried in this IE are taken from the "RTCP XR QoE metric >> block - Calculation Algorithm" sub-registry of the "RTP Control >> Protocol Extended Reports (RTCP XR) Block Type Registry" as defined >> in [I-D.wu-xrblock-rtcp-xr-quality-monitoring]. >> >> Even when an algorithm other than G.107 is used the rtpMOSClassN >> Information Elements use the R-Factor based classes as defined in the >> G.107 documentation. >> >> Description: The calculation algorithm (CAlg) used by the Metering >> Process to calculate the MOS value. >> >> 0: undefined: The algorithm is not known/specified. >> >> 1: ITU-T P.564 >> >> 2: G.107 >> >> 3: G.107 / ETSI TS 101 329-5 Annex E >> >> 4: ITU-T P.NAMS >> >> 5: ITU-T P.NBAMS >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 4] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 6: RTCP - Real Time Control Protocol (not fefined in registry!) > > Typo: "defined". > > >> >> Data Type: unsigned8 >> >> Data Type Semantics: identifier >> >> PEN (provisional): tbd > > Don't specify PEN numbers. > > >> >> ElementId (provisional): tbd > > You might want to number these, eg TBD1, TBD2, ... > > >> >> The MOS values calculated are separated into MOS classes based on the >> ITU-T G.107 classes. >> >> 3.2. rtpMOSClass1 >> >> Description: Number of seconds the monitored stream had a MOS >> quality lower than 3.10 >> >> Data Type: float32 > > It's unusual to represent time as a float in IPFIX. Could you pick a > suitable resolution (eg, milliseconds or microseconds) and export an > integer? > The purpose of these IE items is to report the amount of full seconds VoIP streams have been in either one of these 5 MOS classes. So I suggest to change the type to unsigned64. Regards, Michael > >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.3. rtpMOSClass2 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 3.10 and lower than 3.60 >> >> Data Type: float32 >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.4. rtpMOSClass3 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 3.60 and lower than 4.03 >> >> Data Type: float32 >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 5] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.5. rtpMOSClass4 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 4.03 and lower than 4.34 >> >> Data Type: float32 >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.6. rtpMOSClass5 >> >> Description: Number of seconds the monitored stream had a MOS >> quality larger than or equal 4.34 >> >> Data Type: float32 >> >> Data Type Semantics: deltaCounter >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.7. rtpMinMOS >> >> Description: Minimum MOS value measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 6] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 3.8. rtpAvgMOS >> >> Description: Average MOS value measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.9. rtpMaxMOS >> >> Description: Maximum MOS value measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.10. rtpMinRFactor >> >> Description: Minimum R-Factor measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> 3.11. rtpAvgRFactor >> >> Description: Average R-Factor measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 7] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> ElementId (provisional): tbd >> >> 3.12. rtpMaxRFactor >> >> Description: Maximum R-Factor measured in the monitoring interval. >> >> Data Type: float32 >> >> Data Type Semantics: quantity >> >> PEN (provisional): tbd >> >> ElementId (provisional): tbd >> >> >> 4. Recommended Templates >> >> The defined RTP stream IPFIX templates must support both IPv4 and >> IPv6 transport. They need to carry either flow information regarding >> the entire duration of an RTP stream or specific to a shorter >> observation interval. >> >> The template incorporates IEs from [I-D.akhter-ipfix-perfmon] to >> describe the RTP stream. >> >> In order to correlate the RTP quality information with signaling >> information (e.g. subscriber IDs) a correlation ID may be added to >> the template. Note that this ID has yet to be defined and is outside >> the scope of this document. > > Lots of TBD's from here on... > > P. > >> 4.1. Entire stream >> >> tbd >> >> 4.2. Time slice >> >> tbd, based on previous template. Split a single RTP stream in three >> flow records as example including (empty) 'RTP stream ended' flow >> record. >> >> >> 5. Examples >> >> tbd >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 8] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> 6. Acknowledgements >> >> tbd >> >> >> 7. IANA Considerations >> >> tbd >> >> >> 8. Security Considerations >> >> tbd >> >> >> 9. References >> >> 9.1. Normative References >> >> [I-D.wu-xrblock-rtcp-xr-quality-monitoring] >> Hunt, G., Clark, A., Wu, W., Schott, R., and G. Zorn, >> "RTCP XR Blocks for QoE metric reporting", >> draft-wu-xrblock-rtcp-xr-quality-monitoring-06 (work in >> progress), December 2011. >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, March 1997. >> >> [RFC5101] Claise, B., "Specification of the IP Flow Information >> Export (IPFIX) Protocol for the Exchange of IP Traffic >> Flow Information", RFC 5101, January 2008. >> >> [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. >> Meyer, "Information Model for IP Flow Information Export", >> RFC 5102, January 2008. >> >> 9.2. Informative References >> >> [I-D.akhter-ipfix-perfmon] >> Akhter, A., "Information Elements for Flow Performance >> Measurement", draft-akhter-ipfix-perfmon-00 (work in >> progress), October 2010. >> >> [I-D.trammell-ipfix-sip-msg] >> Claise, B., Trammell, B., Kaplan, H., and S. Niccolini, >> "SIP Message Information Export using IPFIX", >> draft-trammell-ipfix-sip-msg-02 (work in progress), >> October 2011. >> >> >> >> Scholz Expires January 10, 2013 [Page 9] >> >> Internet-Draft RTP Streams in IPFIX July 2012 >> >> >> [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, >> A., Peterson, J., Sparks, R., Handley, M., and E. >> Schooler, "SIP: Session Initiation Protocol", RFC 3261, >> June 2002. >> >> [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. >> Jacobson, "RTP: A Transport Protocol for Real-Time >> Applications", STD 64, RFC 3550, July 2003. >> >> >> Author's Address >> >> Hendrik Scholz >> VOIPFUTURE GmbH >> Wendenstrasse 4 >> Hamburg 20097 >> Germany >> >> Phone: +49 40 688 900 100 >> Email: [email protected] >> URI: http://www.voipfuture.com/ >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Scholz Expires January 10, 2013 [Page 10] >> > _______________________________________________ IPFIX mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipfix