[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]
>