INTERNET-DRAFT                                                  R. Huang
Intended Status: Standards Track                                  Huawei
Expires: July 25, August 19, 2015                                        V. Singh
                                                        Aalto University
                                                        January 21,
                                                       February 15, 2015

   RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair
                           Loss Count Metrics
          draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-09
          draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10

Abstract

   This document defines an RTP Control Protocol (RTCP) Extended Report
   (XR) Block that allows reporting of post-repair loss count metric for
   a range of RTP applications. In addition, another metric, repaired
   loss count, is also introduced in this report block for calculating
   the pre-repair loss count during this rage. when needed so that the RTP sender or a
   third-party entity is able to evaluate the effectiveness of the
   repair methods used by the system.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice

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

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Post-Repair Loss Count Metrics Report Block . . . . . . . . . .  4
     3.1  Report Block Structure  . . . . . . . . . . . . . . . . . .  5  4
     3.2  Report Block  Example Usage . . . . . . . . . . . . . . . .  6 . . . . . . .  5
   4  SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1  SDP rtcp-xr-attrib Attribute Extension  . . . . . . . . . .  7  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 . . . . . . . . . . . . . . . . .  8  7
     6.3  Contact Information for registrations . . . . . . . . . . .  8
   7  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .  8
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1  Normative References  . . . . . . . . . . . . . . . . . . .  8
     8.2  Informative References  . . . . . . . . . . . . . . . . . .  9  8
   Appendix A. Metrics Represented Using the Template from RFC 6390 .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

1  Introduction

   RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some
   rough statistics about the data received from the particular source
   indicated in that block. One of them is the cumulative number of
   packets lost, which is called pre-repair loss metric in this
   document. This metric conveys information regarding the total number
   of RTP data packets that have been lost since the beginning of the
   RTP session.

   However, this metric is measured on media stream before any loss
   repair mechanism, e.g., retransmission [RFC4588] or Forward Error
   Correction (FEC) [RFC5109], is applied. Using a repair mechanism
   usually results in recovering some or all of the lost packets. Hence,
   the sending endpoint cannot assess the performance of the repair
   mechanism by observing the change in fraction loss and the cumulative
   loss statistics from RTCP SR/RR [RFC3550].

   Consequently, [RFC5725] specifies a post-repair loss Run-length
   Encoding (RLE) XR report block to address this issue. The sending
   endpoint is able to infer which packets were repaired from the RLE
   report block, but the reporting overhead for the packet-by-packet
   report block is higher compared to other report blocks.

   When applications use multiple XR blocks, the endpoints may require
   more concise reporting to save bandwidth. This document defines a new
   XR block type to augment those defined in [RFC3611] and complement
   the report block defined in [RFC5725] for use in a range of RTP
   applications. This new block type reports the post-repair loss count
   metric which records the number of primary source RTP packets that
   are still lost after applying one or more loss repair mechanisms. In
   addition,  another metric, repaired loss count, is also introduced in
   this report block for calculating the pre-repair loss count during
   this range, so that the RTP sender or a third-party entity is able to
   evaluate the effectiveness of the repair methods used by the system.
   The metrics defined in this document are packet level rather than
   slice/picture level, which means the partial recovery of a packet
   will not be regarded as a repaired packet.

   The metrics defined in this document belong to the class of
   transport-related metrics defined in [RFC6792] and are specified in
   accordance with the guidelines in [RFC6390] and [RFC6792]. These
   metrics are applicable to any RTP application, especially those that
   use loss repair mechanisms.

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

   primary source RTP packet: The original RTP packet sent from the RTP
   sender for the first time. A lost primary source RTP packet may be
   repaired by some other RTP packets used in repair mechanisms like FEC
   or retransmission.

3  Post-Repair Loss Count Metrics Report Block

   This block reports the number of packets lost after applying repair
   mechanisms to complement (e.g., FEC).  It complements the RTCP XR metrics defined
   in [RFC5725].
   The sender of this XR report can ensure it match the SR/RR packet
   sent As noted in the same compound RTCP packet. When [RFC5725],  ambiguity may occur when
   comparing this metric with pre-repair loss metric of reported in an RTCP
   SR/RR, ambiguity may occur as
   noted in [RFC5725]: Some i.e., some packets will were not be repaired in the current RTCP
   interval, but could they may be repaired later.

   Accordingly, only packets that have no further chance of being
   repaired are included in Therefore, this report block. This block needs to
   specify its own measurement period to avoid ambiguity in calculating
   the post-repair loss count.

   The sequence number range reported by RTCP SR/RR may contain some
   sequence numbers of packets for which repair might still be possible.
   To avoid the ambiguity, we use uses
   a begin sequence number and an end sequence number to explicitly
   indicate the actual sequence number range that
   this RTCP XR report block reports on as the measurement timing. These
   metrics defined in this report block are all measured at the RTP
   receiver. The relationship between the metrics in reported by this report block
   and the pre-repair loss metric of RTCP RR could be expressed in the
   following formula:

      still to be repaired lost packet = cumulative number of XR.
   Accordingly, only packets
      lost - cumulative post-repair loss count -  cumulative repaired
      loss count

   "cumulative number that have no further chance of packets lost" is the metric from RTCP SR/RR.
   "cumulative post-repair loss count" being
   repaired and "cumulative that have been repaired loss
   count" could be obtained by the way introduced are included in the end of this
   section.

   It is also possible to send this XR report block and SR/RR with
   different intervals, in which case the "cumulative number of packets
   lost" can't be easily compared with the post-repair metrics defined
   in this draft. However, the endpoint could rely on the post-repair
   loss count and repaired loss count to calculate the efficiency of the
   error resilience algorithm.
   block.

3.1  Report Block Structure

   The post-repair loss count metrics 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=PRLR    |   Reserved    |      block length = 4         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       SSRC of Source                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       begin_seq               |          end_seq              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  post-repair loss count       |     repaired loss count       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Block Type (BT): 8 bits

      A Post-Repair Loss Count Metrics Report Block is identified by the
      constant PRLR.

      [Note to RFC Editor: Please replace PRLR with the IANA provided
      RTCP XR block type for this block.]

   Reserved: 8 bits

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

   block length: 16 bits

      This field is in accordance with the definition in [RFC3611]. In
      this report block, it MUST be set to 4. 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].

   begin_seq: 16 bits

      The first sequence number that this block reports on. It can
      remain fixed when calculating metrics over several RTCP reporting
      intervals.

   end_seq: 16 bits

      The last sequence number that this block reports on plus one.

   post-repair loss count: 16 bits

      Total number of packets finally lost after applying one or more
      loss-repair methods, e.g., FEC and/or retransmission, during the
      actual sequence number range indicated by begin_seq and end_seq.
      This metric MUST NOT count the lost packets for which repair might
      still be possible. Note that this metric MUST measure only primary
      source RTP packets.

   repaired loss count: 16 bits

      Total number of packets fully repaired after applying one or more
      loss-repair methods, e.g., FEC and/or retransmission, during the
      actual sequence number range indicated by begin_seq and end_seq.
      Note that this metric MUST measure only primary source RTP
      packets.

3.2  Report Block  Example Usage

   This

   The metrics defined in this report block could be reported by are all measured at the RTP
   receiver. However, the receiving endpoint can report the metrics in 2
   two different ways:

   1. Cumulative report

   In this case, implementations may set begin_seq to the first packet
   in the RTP session and it will remain fixed across all reports. In
   this case
   Hence, the "post-repair loss count" and "repaired loss count" count",
   respectively  will correspond to "cumulative post-repair loss count"
   and "cumulative repaired loss count" in this case. These cumulative
   metrics when combined with the cumulative loss metrics reported in an
   RTCP RR (pre-repair) assists in calculating the still to be repaired
   lost packets:

   in 6 still to be repaired lost packet = cumulative number of packets
   lost - cumulative post-repair loss count -  cumulative repaired loss
   count

   2. Interval report

   Some implementations may align the begin_seq and end_seq number with
   the last RTCP interval. If the reports are consecutive and there is
   no highest sequence number range overlap or numbers of consecutive RTCP XR RRs (RTCP interval).
   This is NOT RECOMMENDED as packets loss, "cumulative
   post-repair loss count" that are not yet repaired in this
   current RTCP interval and "cumulative may repaired loss count" can in the future will not be
   respectively calculated by sum of "post-repair loss count" and by sum
   of "repaired loss count".
   reported in subsequent reports.

   Alternatively, for providing better robustness against packet loss, implementations may choose the begin_seq and end_seq
   numbers covering that cover several RTCP intervals. Additionally, the reported
   range of sequence numbers may overlap with the previous report
   blocks, so that the packets that were not yet repaired in one
   interval but were subsequently repaired or deemed unrepairable were
   reported in subsequent intervals.

   In this case, the "cumulative number of packets lost" cannot be
   easily compared with the post-repair metrics. However, the sending
   endpoint can calculate the efficiency of the error resilience
   algorithm using the post-repair and repaired lost count,
   respectively.

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.

   xr-format =/ xr-prlr-block

   xr-prlr-block = "post-repair-loss-count"

4.2  Offer/Answer Usage

   When SDP is used in offer-answer context, the SDP Offer/Answer usage
   defined in [RFC3611] for 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 Post-Repair Loss
   Count reports, which will be affect the performance of loss repair
   mechanisms. 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 PRLR in the IANA "RTP
   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
   the "Post-Repair Loss Count Metrics Report Block".

   [Note to RFC Editor: please replace PRLR with the IANA provided RTCP
   XR block type for this block.]

6.2  New RTCP XR SDP Parameter

   This document also registers a new parameter "post-repair-loss-count"
   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 registration is :

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

7  Acknowledgments

   The author would like to thank Roni Even, Colin Perkins, and Qin Wu
   for giving valuable comments and suggestions.

8  References

8.1  Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3611]  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
              "RTP Control Protocol Extended Reports (RTCP XR)",
              RFC 3611, November 2003.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
              Real-time Transport Control Protocol (RTCP)-Based Feedback
              (RTP/SAVPF)", RFC 5124, February 2008.

   [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, February 2010.

8.2  Informative References

   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
              July 2006.

   [RFC5109]  Li, A., Ed., "RTP Payload Format for Generic Forward Error
              Correction", RFC 5109, December 2007.

   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
              Performance Metric Development", BCP 170, RFC 6390,
              October 2011.

   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
              Considerations for Protocol Extensions", RFC6709,
              September 2012.

   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
              RTP Monitoring Framework", RFC 6792, November 2012.

   [RFC7201]  Westerlund, M. and C., Perkins, "Qptions for Securing RTP
              Sessions", RFC 7201, April 2014.

   [RFC7202]  Perkins, C. and M., Westerlund, "Securing the RTP
              Framework: Why RTP Does Not Mandate a Single Media
              Security Solution", RFC 7202, April 2014.

Appendix A. Metrics Represented Using the Template from RFC 6390

   a. Post-Repair RTP Packet Loss Count Metric

      * Metric Name: Post-Repair RTP Packet Loss Count Metric.

      * Metric Description: Total number of RTP packets still lost after
      loss repair methods are applied

      * Method of Measurement or Calculation: See section 3.1, Post-
      Repair RTP Packet Loss Count Metric definition. It is directly
      measured and must be measured for the primary source RTP packets
      with no further chance of repair.

      * Units of Measurement: This metric is expressed as a 16-bit
      unsigned integer value giving the number of RTP packets.

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

      * Measurement Timing: This metric relies on the sequence number
      interval to determine measurement timing. See Section 3, 3rd
      paragraph, for details.

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

      * Reporting Model: See RFC3611.

   b. Repaired RTP Packet Loss Count Metric

      * Metric Name: Repaired RTP Packet Count Metric.

      * Metric Description: The number of RTP packets lost but repaired
      after applying loss repair methods

      * Method of Measurement or Calculation: See section 3.1, Repaired
      RTP Packet Loss Count Metric definition. It is directly measured
      and must be measured for the primary source RTP packets with no
      further chance of repair.

      * Units of Measurement: This metric is expressed as a 16-bit
      unsigned integer value giving the number of RTP packets.

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

      * Measurement Timing: This metric relies on the sequence number
      interval to determine measurement timing. See Section 3, 3rd
      paragraph, for details.

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

      * Reporting Model: See RFC3611.

Authors' Addresses

      Rachel Huang
      Huawei
      101 Software Avenue, Yuhua District
      Nanjing 210012
      China

      EMail: rachel.huang@huawei.com

      Varun Singh
      Aalto University
      School of Electrical Engineering
      Otakaari 5 A
      Espoo, FIN  02150
      Finland

      Email: varun@comnet.tkk.fi
      URI:   http://www.netlab.tkk.fi/~varun/