Internet DRAFT - draft-zheng-xr-effective-loss-index

draft-zheng-xr-effective-loss-index







Network Working Group                                           H. Zheng
Internet-Draft                                                   R. Even
Intended status: Informational                                    Huawei
Expires: May 3, 2018                                    October 30, 2017


  RTP Control Protocol (RTCP) Extended Report (XR) Block for Effective
                          Loss Index Reporting
                 draft-zheng-xr-effective-loss-index-00

Abstract

   This document defines a new metric for RTP applications to measure
   the effectiveness of stream repair means, and an RTP Control Protocol
   (RTCP) Extended Report (XR) Block to report the metric.

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 May 3, 2018.

Copyright Notice

   Copyright (c) 2017 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.




Zheng & Even               Expires May 3, 2018                  [Page 1]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Effective Loss Index  . . . . . . . . . . . . . . . . . .   3
     1.2.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  RTCP and RTCP XR Reports  . . . . . . . . . . . . . . . .   4
     1.4.  Performance Metrics Framework . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Effective Loss Index Report Block . . . . . . . . . . . . . .   5
   4.  SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  SDP rtcp-xr-attrib Attribute Extension  . . . . . . . . .   6
     4.2.  Offer/Answer Usage  . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  New RTCP XR Block Type Value  . . . . . . . . . . . . . .   7
     6.2.  New RTCP XR SDP Parameter . . . . . . . . . . . . . . . .   7
     6.3.  Contact Information for Registrations . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Metric Represented Using the Template from RFC 6390   10
     A.1.  Effective Loss Index  . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   RTP applications often use stream repair means, e.g.  FEC (Forward
   Error Correction) [RFC5109] and/or retransmission [RFC4588] to
   improve the robustness of media streams.  With the presence of those
   stream repair means, a degree of packet loss can be recovered for a
   media stream.  In the past, some RTCP Extend Reports (XRs) were
   defined to reflect the situation of post-repair loss.  For example,
   [RFC5725] defines an XR block using Run Length Encoding (RLE) to
   report post-repair loss; [RFC7509] defines count metrics for post-
   repair loss.

   This document proposes a new metric Effective Loss Index (ELI) to
   measure the effectiveness of stream repair means.  The new metric
   provides a simpler view on the post-repair loss than the mechanisms
   documented in [RFC5725] and [RFC7509].  EFI is an index, so the
   values reported from different RTP sources can be compared directly,
   which makes it easier to rank the effectiveness of loss repair means.
   An example use case is to find endpoints whose ELI values are at
   bottom 10%. For those endpoints, more informative XR reports such as
   those in [RFC5725] and [RFC7509] can then be used to discover more
   details about the loss situations.




Zheng & Even               Expires May 3, 2018                  [Page 2]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


   This document also defines an XR block to report the metric, which
   can be found out in Section 3.

1.1.  Effective Loss Index

   Effective Loss Index (ELI) uses a simple model to measure the
   effectiveness of loss repair.  The model assumes that repair means
   are applied onto packets by batches of equal size.  Lower ELI means
   that the repair was more successful.  Specifically, a batch is
   identified by a range of RTP sequence numbers.  The size of a batch
   is number of packets.  An application can agree upon a default batch
   size, or use the SDP signaling defined in Section 4.1 to communicate
   one.

   An RTP endpoint is thought to process received packets and apply
   repair means batch by batch.  For each batch, if there is still some
   unrecoverable loss after having applied the repair means, then the
   repair means are deemed as ineffective.  The ineffectiveness is
   denoted by Effective Loss Factor (ELF), along with a parameter
   Effective Loss Threshold, showing below:

              if Post-Repair Loss > Effective Loss Threshold
                 Effective Loss Factor = 1
              else
                 Effective Loss Factor = 0
              endif

              Figure 1: Calculation of Effective Loss Factor

   The parameters in Figure 1 are explained below:

   o  Post-Repair Loss is the number of packet lost after repair in the
      batch.

   o  Effective Loss Threshold is in number of packets.

   The minimum value of Effective Loss Threshold is zero.  This document
   does not mandate any value for Effective Loss Threshold.
   Applications can prescribe a value for themselves without signaling.
   On the other hand, SDP signaling defined in Section 4.1 can be used
   to communicate the value.  Determining an Effective Loss Threshold
   value for use can be empirical, applications may have to try out and
   change the value from time to time, depending on their needs.

   Effective Loss Index is an integer derived by calculating the average
   Effective Loss Factor across a sequence of consecutive batches of RTP
   packets.  Let ELF(i) be the Effective Loss Factor calculated for i-th




Zheng & Even               Expires May 3, 2018                  [Page 3]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


   batch, and N as number of batches in the sequence, then Effective
   Loss Index is calculated as:

                                 ELF(1)+ELF(2)+ ...+ELF(N)
         Effective Loss Index =  ------------------------- x 10000
                                             N

               Figure 2: Calculation of Effective Loss Index

   The following is an example of how to calculate Effective Loss Index.
   For simplicity and demonstration purpose, the size of batches is
   assumed to be 3, and the Effective Loss Threshold is assumed to be 1.
   The example processes a sequence of 9 RTP packets in 3 batches.

               Batch     Post-Repair    Effective
                         Loss           Loss Factor
             | 1 2 3 |   2, 3           1
             | 4 5 6 |   5              0
             | 7 8 9 |   7              0

                                     1 + 0 + 0
             Effective Loss Index = ----------- x 10000 = 3333
                                         3

1.2.  Applicability

   The metric defined by this document is applicable to a range of RTP
   applications that send packets in batches of equal length, probably
   with stream repair means (e.g., Forward Error Correction (FEC)
   [RFC5109] and/or retransmission [RFC4588]) applied on the batches.
   Note that in order to not interfere with the batches being protected,
   any additional packets generated by the stream repair means SHOULD be
   in a different RTP stream.

   The number of batches among which ELI is calculated should not be too
   few, otherwise the result may be too biased.  However, specifying a
   minimal number of batches seems unrealistic, due to the stream repair
   means used by applications can be quite different.  This document
   leaves it to applications to choose a suitable minimal value for the
   number of batches.

1.3.  RTCP and RTCP XR Reports

   The use of RTCP for reporting is defined in [RFC3550].  [RFC3611]
   defines an extensible structure for reporting by using an RTCP
   Extended Report (XR).  This document defines a new Extended Report
   block for use with [RFC3550] and [RFC3611].




Zheng & Even               Expires May 3, 2018                  [Page 4]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


1.4.  Performance Metrics Framework

   The Performance Metrics Framework [RFC6390] provides guidance on the
   definition and specification of performance metrics.  The "Guidelines
   for Use of the RTP Monitoring Framework" [RFC6792] provides
   guidelines for reporting block format using RTCP XR.  The Metrics
   Block described in this document is in accordance with the guidelines
   in [RFC6390] and [RFC6792].

2.  Terminology

   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.  Effective Loss Index Report Block

   The Effective Loss Index Report Block has the following format:

     0               1               2               3               4
     0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     BT=TBD    |   Reserved    |      Block length = 3         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       SSRC of Source                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Effective Loss Index       |          Padding              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Block Type (BT): 8 bits:  An Effect Loss Index Report Block is
      identified by the constant 'TBD'.

      [[Editor Note: should replace 'TBD' with assigned value]]

   Reserved: 8 bits:  These bits are reserved for future use.  They MUST
      be set to zero by senders and ignored by receivers (see
      Section 4.2 of [RFC6709]).

   Block length: 16 bits:  This field is in accordance with the
      definition in [RFC3611].  In this report block, it MUST be set to
      3.  The block MUST be discarded if the block length is set to a
      different value.

   SSRC of source: 32 bits:  As defined in Section 4.1 of [RFC3611].

   Effective Loss Index: 16 bits:  The value of this field SHOULD be set
      to the calculated result of Effective Loss Index (as in Figure 2).




Zheng & Even               Expires May 3, 2018                  [Page 5]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


   Padding: 16 bits:  These bits MUST be set to zero by senders and
      ignored by receivers.

4.  SDP Signaling

   [RFC3611] defines the use of SDP (Session Description Protocol) for
   signaling the use of RTCP XR blocks.  However, XR blocks MAY be used
   without prior signaling (see Section 5 of [RFC3611]).

4.1.  SDP rtcp-xr-attrib Attribute Extension

   This session augments the SDP attribute "rtcp-xr" defined in
   Section 5.1 of [RFC3611] by providing an additional value of "xr-
   format" to signal the use of the report block defined in this
   document.  The ABNF [RFC5234] syntax is as follows.

   xr-format =/ xr-eli-block

   xr-eli-block = "effective-loss-index"
                  [ ":" effective-loss-batch-size]
                  [ ">" effective-loss-threshold]

   effective-loss-batch-size  = 1*DIGIT
                                ; the batch size is in number of packets

   effective-loss-threshold   = 1*DIGIT
                                ; the threshold is in number of packets

   DIGIT = %x30-39

   The SDP attribute "xr-eli-block" is designed to contain two optional
   values, one for signaling the batch size, another for the Effective
   Loss Threshold.  Here are some examples:

     1. signaling both batch size (100) and Effective Loss Threshold (2)

     xr-eli-block = "effective-loss-index" : "100" > "2"

     2. signaling only batch size (100)

     xr-eli-block = "effective-loss-index" : "100"

     3. signaling only Effective Loss Threshold (2)

     xr-eli-block = "effective-loss-index" > "2"






Zheng & Even               Expires May 3, 2018                  [Page 6]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


4.2.  Offer/Answer Usage

   When SDP is used in offer/answer context, the SDP Offer/Answer usage
   defined in [RFC3611] for the unilateral "rtcp-xr" attribute
   parameters applies.  For detailed usage of Offer/Answer for
   unilateral parameters, refer to Section 5.2 of [RFC3611].

5.  Security Considerations

   This proposed RTCP XR block introduces no new security considerations
   beyond those described in [RFC3611]  This block does not provide per-
   packet statistics, so the risk to confidentiality documented in
   Section 7, paragraph 3 of [RFC3611] does not apply.

   An attacker may put incorrect information in the Effective Loss Index
   reports.  Implementers should consider the guidance in [RFC7202] for
   using appropriate security mechanisms, i.e., where security is a
   concern, the implementation should apply encryption and
   authentication to the report block.  For example, this can be
   achieved by using the AVPF profile together with the Secure RTP
   profile as defined in [RFC3711] an appropriate combination of the two
   profiles (an "SAVPF") is specified in [RFC5124]  However, other
   mechanisms also exist (documented in [RFC7201] and might be more
   suitable.

6.  IANA Considerations

   New block types for RTCP XR are subject to IANA registration.  For
   general guidelines on IANA considerations for RTCP XR, refer to
   [RFC3611].

6.1.  New RTCP XR Block Type Value

   This document assigns the block type value 'TBD' in the IANA "RTP
   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
   the "Post-Repair Loss Count Metrics Report Block".

      [[Editor Note: should replace 'TBD' with assigned value]]

6.2.  New RTCP XR SDP Parameter

   This document also registers a new parameter "effective-loss-index"
   in the "RTP Control Protocol Extended Reports (RTCP XR) Session
   Description Protocol (SDP) Parameters Registry".







Zheng & Even               Expires May 3, 2018                  [Page 7]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


6.3.  Contact Information for Registrations

   The contact information for the registrations is:

      RAI Area Directors <rai-ads@ietf.org>

7.  Acknowledgements

   This document has benefited greatly from the comments of various
   people.  The following individuals have contributed to this document:
   Rachel Huang, Colin Perkins, Yanfang Zhang, Lingyan Wu.

8.  References

8.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, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

8.2.  Informative References

   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
              "RTP Control Protocol Extended Reports (RTCP XR)",
              RFC 3611, DOI 10.17487/RFC3611, November 2003,
              <https://www.rfc-editor.org/info/rfc3611>.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, DOI 10.17487/RFC3711, March 2004,
              <https://www.rfc-editor.org/info/rfc3711>.

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              DOI 10.17487/RFC4588, July 2006, <https://www.rfc-
              editor.org/info/rfc4588>.

   [RFC5109]  Li, A., Ed., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, DOI 10.17487/RFC5109, December
              2007, <https://www.rfc-editor.org/info/rfc5109>.





Zheng & Even               Expires May 3, 2018                  [Page 8]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
              2008, <https://www.rfc-editor.org/info/rfc5124>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
              editor.org/info/rfc5234>.

   [RFC5725]  Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
              Report Block Type for RTP Control Protocol (RTCP) Extended
              Reports (XRs)", RFC 5725, DOI 10.17487/RFC5725, February
              2010, <https://www.rfc-editor.org/info/rfc5725>.

   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
              Performance Metric Development", BCP 170, RFC 6390,
              DOI 10.17487/RFC6390, October 2011, <https://www.rfc-
              editor.org/info/rfc6390>.

   [RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
              Considerations for Protocol Extensions", RFC 6709,
              DOI 10.17487/RFC6709, September 2012, <https://www.rfc-
              editor.org/info/rfc6709>.

   [RFC6792]  Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use
              of the RTP Monitoring Framework", RFC 6792,
              DOI 10.17487/RFC6792, November 2012, <https://www.rfc-
              editor.org/info/rfc6792>.

   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
              <https://www.rfc-editor.org/info/rfc7201>.

   [RFC7202]  Perkins, C. and M. Westerlund, "Securing the RTP
              Framework: Why RTP Does Not Mandate a Single Media
              Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
              2014, <https://www.rfc-editor.org/info/rfc7202>.

   [RFC7509]  Huang, R. and V. Singh, "RTP Control Protocol (RTCP)
              Extended Report (XR) for Post-Repair Loss Count Metrics",
              RFC 7509, DOI 10.17487/RFC7509, May 2015,
              <https://www.rfc-editor.org/info/rfc7509>.








Zheng & Even               Expires May 3, 2018                  [Page 9]

Internet-Draft        RTCP XR Effective Loss Index          October 2017


Appendix A.  Metric Represented Using the Template from RFC 6390

A.1.  Effective Loss Index

   o  Metric Name: RTP Effective Loss Index.

   o  Metric Description: The effectiveness of stream repair means
      applied on a sequence of RTP packets.

   o  Method of Measurement or Calculation: See the "Effective Loss
      Index" definition in Section 1.1.  It is directly measured and
      must be measured for the primary source RTP packets with no
      further chance of repair.

   o  Units of Measurement: This metric is expressed as a 16-bit
      unsigned integer value representing the effectiveness of stream
      repair means.

   o  Measurement Point(s) with Potential Measurement Domain: It is
      measured at the receiving end of the RTP stream.

   o  Measurement Timing: This metric relies on the sequence number
      interval to determine measurement timing.

   o  Use and Applications: These metrics are applicable to any RTP
      application, especially those that use loss-repair mechanisms.
      See Section 1 for details.

   o  Reporting Model: See RFC 3611.

Authors' Addresses

   Hui Zheng (Marvin)
   Huawei

   Email: marvin.zhenghui@huawei.com


   Roni Even
   Huawei

   Email: roni.even@huawei.com









Zheng & Even               Expires May 3, 2018                 [Page 10]