[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-zheng-xr-effective-loss-index) 00 01 02

Network Working Group                                           H. Zheng
Internet-Draft                                                   R. Even
Intended status: Standard Track                                    Q. Wu
Expires: September 3, 2018                                        Huawei
                                                                   R. Gu
                                                            China Mobile
                                                                R. Huang
                                                                  Huawei
                                                           March 2, 2018

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

Abstract

   This document defines a new metric for RTP monitors to estimate 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) 2018 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



Zheng, et al.          Expires September 3, 2018                [Page 1]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1.  Effective Loss Index . . . . . . . . . . . . . . . . . . .  3
     1.2.  Applicability  . . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . .  5
     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 . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  New RTCP XR Block Type Value . . . . . . . . . . . . . . .  8
     6.2.  New RTCP XR SDP Parameter  . . . . . . . . . . . . . . . .  9
     6.3.  Contact Information for Registrations  . . . . . . . . . .  9
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Metric Represented Using the Template from RFC 6390 . 11
     A.1.  Effective Loss Index . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11


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
   estimate the effectiveness of stream repair means by calculating the
   probability of the post-repair losses. The new metric provides a
   simpler view on the post-repair loss than the mechanisms documented
   in [RFC5725] and [RFC7509].  ELI is an index, so the values reported
   from the monitors deployed in the different places in the network can



Zheng, et al.          Expires September 3, 2018                [Page 2]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


   be compared directly, which makes it easier to diagnose the network
   problem when delivering the RTP streams. A use case is to compare the
   ELI value reported by a monitor in the network with a certain
   reasonable threshold to see if there are any problems in the IPTV
   services. 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.

   This document also defines in section 3, an XR block to report the
   metric.

1.1.  Effective Loss Index

   Effective Loss Index (ELI) uses a simple model to measure the loss
   impact after applying loss repairsof loss repair. It is useful
   especially in the middleboxes which usually are passive observer and
   do not have the ability to recover the loss data.

   The model assumes that repair means are applied onto packets by
   batches of equal size.  Lower ELI means that loss impact is minimal.
   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 if the middlebox can see the SDP,
   or just configure it.

   An RTP endpoint is assumed 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 Loss
   Repair Threshold, showing below:

              if Loss Packets Number > Loss Repair 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  Loss Packets Number is the number of packet lost in the batch.

   o  Loss Repair Threshold indicates the maximum loss packets number
      that can be recovered.




Zheng, et al.          Expires September 3, 2018                [Page 3]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


   The minimum value of Loss Repair Threshold is zero, which means there
   is no loss repair. This document does not mandate any value for Loss
   Repair Threshold. Applications can prescribe a value for themselves
   without signaling. For example, it can be calculated by the batch
   size multiplied by the fixed redundancy ratio of the FEC algorithm;
   And when used in the retransmission case, it can be set to the
   maximum number of lost packets to be retransmitted in a batch. On the
   other hand, SDP signaling defined in Section 4.1 can be used to
   communicate the value.

   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
   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 =  -------------------------
                                             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 a batch is
   assumed to be 3, and the Loss Repair Threshold is assumed to be 1.
   The example processes a sequence of 9 RTP packets (x means lost) in 7
   batches.


             1xx4x6x89

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

                                     1+1+0+0+1+0+0
             Effective Loss Index = --------------- = 0.4285
                                         7

   This example provides fine grained estimation for loss recovery. It
   can detect the loss burst happening over batches. Implementations can
   also do coarse grained estimation by simply dividing total packets
   into several batches.



Zheng, et al.          Expires September 3, 2018                [Page 4]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


1.2.  Applicability

   The metric defined by this document is applicable to a range of RTP
   applications that send packets with stream repair means (e.g.,
   Forward Error Correction (FEC) [RFC5109] and/or retransmission
   [RFC4588]) applied on them. Note that this metric is only valuable
   for FECs where he redundant data are sent in a different RTP stream
   from the original media stream.

   This document does not mandate any value for the batch size.
   Applications can prescribe a value for themselves without signaling.
   For example, the batch size can be set to the number of packets
   containing source symbols in a source block in the case of FEC, and
   can be prescribed arbitrarily, e.g. 100, in the case of
   retransmission.

   The number of batches among which ELI is calculated should not be too
   few, otherwise the result may be biased. It is suggested to calculate
   it based on the total number of RTP packets during the measurement
   interval, as in the section 1.1 example:

   The number of batches = (The total number of RTP packets - the size
   of a batch) + 1.

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

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




Zheng, et al.          Expires September 3, 2018                [Page 5]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


   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:  The SSRC of the RTP data packet source
      being reported upon by this report block, as defined in Section
      4.1 of [RFC3611].

   Effective Loss Index: 16 bits:  The value of Effective Loss Index,
      equivalent to taking the integer part after multiplying the the
      calculated result of Effective Loss Index (as in Figure 2) by
      65535.

   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




Zheng, et al.          Expires September 3, 2018                [Page 6]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


   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:





























Zheng, et al.          Expires September 3, 2018                [Page 7]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


     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"

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".



Zheng, et al.          Expires September 3, 2018                [Page 8]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


      [[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".

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:
   Colin Perkins, Yanfang Zhang.

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>.






Zheng, et al.          Expires September 3, 2018                [Page 9]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


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

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




Zheng, et al.          Expires September 3, 2018               [Page 10]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


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

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
      applications, especially those that use loss-repair mechanisms.
      See Section 1 for details.

   o  Reporting Model: See RFC 3611.

Authors' Addresses

   Hui Zheng (Marvin)
   Individual

   Email: zh4ui@huawei.comoutlook.com


   Roni Even
   Huawei

   Email: roni.even@huawei.com




Zheng, et al.          Expires September 3, 2018               [Page 11]


Internet-Draft        RTCP XR Effective Loss Index         March 2, 2018


   Qin Wu
   Huawei

   Email: bill.wu@huawei.com


   Rong Gu
   China Mobile

   Email: gurong_cmcc@outlook.com

   Rachel Huang
   Huawei

   Email: rachel.huang@huawei.com




































Zheng, et al.          Expires September 3, 2018               [Page 12]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/