Subject: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00

From: Paul Aitken <[email-masked]>
Date: Fri, 03 Aug 2012 17:15:00 +0100

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: [email-masked]
>     URI:   http://www.voipfuture.com/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Scholz                  Expires January 10, 2013               [Page 10]
>

---

From: Michael Krüger <[email-masked]>
Date: Mon, 06 Aug 2012 13:05:46 +0200

Hi Hendrik,

> suitable resolution (eg, milliseconds or microseconds) and export an
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

---

From: Michael Krüger <[email-masked]>
Date: Mon, 06 Aug 2012 14:14:29 +0200

Hi Hendrik,

> suggest to change the type to unsigned64.

I did some math and really believe this should be an unsigned 64-bit
value. Since the purpose of this IE is to provide an aggregation over
all flows carried e.g. over a SIP trunk / carrier-interconnection the
worst case would be potentially many millions of flows aggregated.
Reporting the quality like this for a single flow is possible, but
likely not the general application.
A 32-bit resolution to report quality distribution of full day would
only be sufficient for 49k flows or 24k bi-flows / calls. That doesn't
seem to be a lot for quality reporting on a daily basis on a
carrier-interconnection. Therefore unsigned64 with units = seconds seems
for me the way to go.

Regards,
Michael

---

From: Andrew Feren <[email-masked]>
Date: Mon, 06 Aug 2012 08:33:33 -0400

If in doubt just go with the unsigned64.  It is always possible for an 
implementation to use reduced length encoding and send fewer bytes if 
that implementation doesn't need all 8 bytes.

-Andrew

On 08/06/2012 08:14 AM, Michael Krüger wrote:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix