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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 7509

INTERNET-DRAFT                                                  R. Huang
Intended Status: Standard                                         Huawei
Expires: December 26, 2014                                      V. Singh
                                                        Aalto University
                                                           June 24, 2014


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


Abstract

   This document defines an RTP Control Protocol (RTCP) Extended Report
   (XR) Block that allows reporting of post-repair loss count metrics
   for a range of RTP applications.


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) 2014 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



<Singh&Huang>          Expires December 26, 2014                [Page 1]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


   (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
   4  SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . .  6
     4.1  SDP rtcp-xr-attrib Attribute Extension  . . . . . . . . . .  6
     4.2  Offer/Answer Usage  . . . . . . . . . . . . . . . . . . . .  6
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
     6.1  New RTCP XR Block Type value  . . . . . . . . . . . . . . .  6
     6.2  New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . .  7
     6.3  Contact Information for registrations . . . . . . . . . . .  7
   7  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .  7
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     8.1  Normative References  . . . . . . . . . . . . . . . . . . .  7
     8.2  Informative References  . . . . . . . . . . . . . . . . . .  8
   Appendix A. Metrics Represented Using the Template from RFC 6390 .  8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9






















<Singh&Huang>          Expires December 26, 2014                [Page 2]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


1  Introduction

   RTCP SR/RR [RFC3550] contains some rough statistics about the data
   received from the particular source indicated in that block. One of
   them is the cumulative number of packet 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] and 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 at the
   cost of higher overhead. 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 application. This new block type reports the
   number of primary source RTP packets that are still lost after
   applying one or more loss repair mechanisms. 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. In addition,  another metric, repaired loss count,
   is also introduced in this report block for calculating the pre-
   repair loss count during the 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 belongs to the class of
   transport-related metrics defined in [RFC6792]. And it is 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



<Singh&Huang>          Expires December 26, 2014                [Page 3]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


   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 the RTCP XR metrics defined in [RFC5725].
   This packet may be stacked with other RTCP packets to form compound
   RTCP packets and share the average reporting interval calculated by
   the RTCP method described in [RFC3550]. When comparing this metric
   with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as
   noted in [RFC5725]: Some packets will not be repaired in current RTCP
   interval. Thus it is RECOMMENDED that this report block should be
   generated for those source packets that have no further chance of
   being repaired. But a potential ambiguity may result from sequence
   number range inconsistent. The sequence number range reported by RTCP
   SR/RR may contain some sequence numbers of packets for which repair
   might still be possible. To address this issue, we use begin sequence
   number and 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 interval metrics and the measurement of them is made at the
   RTP receiver. The relationship between the metrics in this report
   block and the pre-repair loss metric of RTCP XR could be expressed in
   the following formula:

      cumulative number of packets lost = unrepaired loss count +
      repaired loss count + to be repaired lost packet

   "cumulative number of packets lost" is the metric from RTCP SR/RR.
   "unrepaired loss count" and "repaired loss count" are the metrics
   defined in this draft.

   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              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   unrepaired loss count       |     repaired loss count       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



<Singh&Huang>          Expires December 26, 2014                [Page 4]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


          Figure 1: Format for the Post-Repair Loss Count Metrics Report
          Block

   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.

   end_seq: 16 bits

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

   unrepaired loss count: 16 bits

      Total number of packets finally lost after one or more loss-repair
      methods, e.g., FEC and/or retransmission, during this interval.
      This metric MUST NOT count the lost packets for which repair might
      still be possible. Note that this metric must be measured in the
      primary source RTP packets.

   repaired loss count: 16 bits

      Total number of packets fully repaired after one or more loss-
      repair methods, e.g., FEC and/or retransmission, during this
      interval. Note that this metric must be measured in the primary
      source RTP packets.



<Singh&Huang>          Expires December 26, 2014                [Page 5]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


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
   parameter, refer to section 5.2 of [RFC3611].

5  Security Considerations

   It is believed that this 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 confidentially
   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



<Singh&Huang>          Expires December 26, 2014                [Page 6]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


   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 following contact information is provided for all registrations
   in this document:


   Rachel Huang (rachel.huang@huawei.com)

   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu 210012
   China


7  Acknowledgments

   The author would like to thank Roni Even and Colin Perkins 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.

   [RFC5725]  Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
              Report Block Type for RTP Control Protocol (RTCP) Extended



<Singh&Huang>          Expires December 26, 2014                [Page 7]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


              Reports (XRs)", RFC 5725, February 2010.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

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


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

8.2  Informative References


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

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


Appendix A. Metrics Represented Using the Template from RFC 6390

   a. Unrepaired RTP Packet Loss Count Metric

      * Metric Name: Unrepaired 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: It must be measured for
      the primary source RTP packets with no further chance of repair

      * Units of Measurement: See section 3, unrepaired loss count
      definition

      * Measurement Point(s) with Potential Measurement Domain: See
      section 3, 1st paragraph



<Singh&Huang>          Expires December 26, 2014                [Page 8]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


      * Measurement Timing: See Section 3, 1st paragraph, for
      measurement timing

      * Use and Applications: See Section 1

      * 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: It must be measured for
      the primary source RTP packets with no further chance of repair

      * Units of Measurement: See section 3, repaired loss count
      definition

      * Measurement Point(s) with Potential Measurement Domain: See
      section 3, 1st paragraph

      * Measurement Timing: See Section 3, 1st paragraph, for
      measurement timing

      * Use and Applications: See Section 1

      * 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



<Singh&Huang>          Expires December 26, 2014                [Page 9]


INTERNET DRAFT       Post-Repair Non-RLE loss Count        June 24, 2014


      Finland

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















































<Singh&Huang>          Expires December 26, 2014               [Page 10]


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