[IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00
Paul Aitken <paitken@cisco.com> Fri, 03 August 2012 16:15 UTC
Return-Path: <paitken@cisco.com>
X-Original-To: ipfix@ietfa.amsl.com
Delivered-To: ipfix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A8F21F8D45 for <ipfix@ietfa.amsl.com>; Fri, 3 Aug 2012 09:15:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.841
X-Spam-Level:
X-Spam-Status: No, score=-8.841 tagged_above=-999 required=5 tests=[AWL=-1.608, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4ezONtwY2SY for <ipfix@ietfa.amsl.com>; Fri, 3 Aug 2012 09:15:04 -0700 (PDT)
Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 63B4621F8E47 for <ipfix@ietf.org>; Fri, 3 Aug 2012 09:15:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paitken@cisco.com; l=18770; q=dns/txt; s=iport; t=1344010501; x=1345220101; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=bORH8g9RT41VSXJiEdyXTEOouWbKGdeGvuvRO4HYHRs=; b=d6kSPw2xxi3syXlI6ecY/M9D5ai/dq+8VcKI4CY+sGikMexsukkqnoPK 0hq9GpUE+8/VZoAL+HnG49dCP6LafALRi7Gxa4SPRWUipERbM5xuJ2o6l nY9T5uBsFOz73csFRYDjhnamx4pqaK+M/ZZjWVICyUr++yQAYyFedfO+1 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAB34G1CQ/khL/2dsb2JhbAA/BrklgQeCIAEBAQMTASUPIBEBBQkUGhYYAwIBAgEJTwEFAgEBHodlBgucUpEFjx0Ei0Qmhl4DlUqBFIRHiEyBZoJggVcHHA
X-IronPort-AV: E=Sophos;i="4.77,707,1336348800"; d="scan'208";a="7105302"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-3.cisco.com with ESMTP; 03 Aug 2012 16:14:59 +0000
Received: from [10.55.81.154] (dhcp-10-55-81-154.cisco.com [10.55.81.154]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q73GExmG018580; Fri, 3 Aug 2012 16:14:59 GMT
Message-ID: <501BF904.6090401@cisco.com>
Date: Fri, 03 Aug 2012 17:15:00 +0100
From: Paul Aitken <paitken@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: hscholz@voipfuture.com
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF IPFIX Working Group <ipfix@ietf.org>
Subject: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00
X-BeenThere: ipfix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IPFIX WG discussion list <ipfix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipfix>, <mailto:ipfix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipfix>
List-Post: <mailto:ipfix@ietf.org>
List-Help: <mailto:ipfix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>, <mailto:ipfix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Aug 2012 16:15:07 -0000
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? > > 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: hscholz@voipfuture.com > URI: http://www.voipfuture.com/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scholz Expires January 10, 2013 [Page 10] >
- [IPFIX] review of draft-scholz-ipfix-rtp-audio-qu… Paul Aitken
- Re: [IPFIX] review of draft-scholz-ipfix-rtp-audi… Michael Krüger
- Re: [IPFIX] review of draft-scholz-ipfix-rtp-audi… Michael Krüger
- Re: [IPFIX] review of draft-scholz-ipfix-rtp-audi… Andrew Feren