[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05                                             
INTERNET-DRAFT                                                  R. Huang
Intended Status: Standards Track                                  Huawei
Expires: January 4, 2015                                    July 3, 2014


    RTCP XR Report Block for Loss Concealment Metrics Reporting on
                           Video Applications
                draft-huang-xrblock-rtcp-xr-video-lc-00


Abstract

   This draft defines a new video loss concealment block type to augment
   those defined in [RFC3611] and [i.d-ietf-xrblock-rtcp-xr-loss-
   concealment] for use in a range of RTP video 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents



<Huang>                 Expires January 4, 2015                 [Page 1]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


   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
     1.2 RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . .  3
     1.3 Performance Metrics Framework  . . . . . . . . . . . . . . .  3
     1.4 Applicability  . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Video Loss Concealment Methods  . . . . . . . . . . . . . . . .  3
   3.  Video Loss Concealment Report Block  . . . . . . . . . . . . .  5
   4 SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . .  7
     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  . . . . . . . . . . . . . . . . . . 10
   Appendix A. Metrics Represented Using the Template from RFC 6390 . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10




















<Huang>                 Expires January 4, 2015                 [Page 2]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


1  Introduction

   Multimedia applications often suffer from packet losses in IP
   networks. In order to get reasonable degree of quality in case of
   packet losses, it is necessary to have loss concealment mechanisms at
   the decoder. Video loss concealment is a technique to mask the
   effects of packet loss in video communications. Reporting the
   information of receivers applying video loss concealment could give
   monitors or senders accurate estimating of application QoE.

   This draft defines one new video loss concealment block types to
   augment those defined in [RFC3611] and [i.d-ietf-xrblock-rtcp-xr-
   loss-concealment] for use in a range of RTP video applications. The
   metrics defined in this draft belong to the class of transport-
   related terminal metrics defined in [RFC6792].

1.2 RTCP and RTCP XR Reports

   The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
   defines an extensible structure for reporting using an RTCP Extended
   Report (XR). This draft defines a new Extended Report block that MUST
   be used as defined in [RFC3550] and [RFC3611].

1.3 Performance Metrics Framework

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

1.4 Applicability

   These metrics are applicable to video applications of RTP and the
   video component of Audio/Video applications in which the packet loss
   concealment mechanisms are contained at the receiving end to mitigate
   the impact of network impairments to QoE.

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

3  Video Loss Concealment Methods

   In this draft, video loss concealment mechanisms are classified into



<Huang>                 Expires January 4, 2015                 [Page 3]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


   6 types as follow:

   a) Frame freeze

   The impaired video frame is not displayed, instead, the previously
   displayed frame is hence frozen for the duration of the loss event.

   b) Inter-frame extrapolation

   If an area of the video frame is damaged by loss, the same area from
   the previous frame(s) can be used to estimate what the missing pixels
   would have been. This can work well in a scene with no motion but can
   be very noticeable if there is significant movement from one frame to
   another. Simple decoders may simply re-use the pixels that were in
   the missing area while more complex decoders may try to use several
   frames to do a more complex extrapolation.

   c) Interpolation

   A decoder may user the undamaged pixels in the image to estimate what
   the missing block of image should have.

   d) Error Resilient

   The sender encodes their message in a redundant way so that receiver
   could correct the errors using the redundant information when the
   errors occurs. The redundant data useful for error resiliency
   performed at the decoder can be embedded into the compressed
   image/video bitstream. For example, the encoder chooses important
   area of an original video frame, extracts some important
   characteristics of this area, e.g., motion vector of each macroblock,
   and imperceptibly embeds them into other parts of the video frame.
   FEC is also one of error resilient methods.

   e) Interactive Repairs

   Interactive repairs need the communication between receiver and
   sender. The receiving side using interactive repairs usually provides
   feedback message to the sending side for specific help.
   Retransmission is an effective interactive packet loss recovery
   technique for real-time applications with relaxed delay bounds. The
   sender resends packets when the sender notices the packets have been
   either damaged or lost. Protocols which provide such technique use a
   combination of acknowledgments, retransmission of missing and/or
   damaged packets. For example, RTP retransmission [4588]. Besides
   retransmission, there are two major feedback messages for asking for
   sender side repair FIR (RFC5104) or PLI (RFC4585).




<Huang>                 Expires January 4, 2015                 [Page 4]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


3.  Video Loss Concealment Report Block

   This block reports the video loss concealment metrics to complement
   the audio metrics defined in [i.d-ietf-xrblock-rtcp-xr-loss-
   concealment]. This block 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].

   The video loss concealment report block has the following format:

    0               1               2               3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    BT=VLC     | I |    VLCM   |       block length=6          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         SSRC of Source                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Lossless Video Image Duration                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Loss Concealed Image Duration                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    DMBF       |    CMBF       |         Reserved              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 1: Format for the Video Loss Concealment Report Block

   Block Type (BT): 8 bits

      A Video Loss Concealment Report Block is identified by the
      constant VLC.

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

   Interval Metric Flag (I): 2 bits

      This field indicates whether the reported metric is an interval,
      cumulative, or sampled metric [RFC6792]:

         I=10: Interval Duration - the reported value applies to the
         most recent measurement interval duration between successive
         metrics reports.

         I=11: Cumulative Duration - the reported value applies to the
         accumulation period characteristic of cumulative measurements.

         I=01: Sampled Value - the reported value is a sampled
         instantaneous value.



<Huang>                 Expires January 4, 2015                 [Page 5]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


      However, video loss concealment metrics defined in this report
      block could not be sampled. So in this document, the value I=01,
      indicating a sampled value, MUST NOT be sent, and MUST be
      discarded when received. In addition, I=00 is reserved for future
      use and also MUST NOT be send, and MUST be discarded when
      received.

   Video Loss Concealment Method Type (VLCM): 6 bits

      This field is used to identify the video loss concealment method
      type used at the receiver. Each bit indicate one method type, as
      follow:

        bit 014 - Frame freeze
        bit 015 - Inter-frame extrapolation
        bit 016 - Interpolation
        bit 017 - Error Resilient
        bit 018 - Interactive Repairs
        bit 019 - Reserved

      Setting the bit means corresponding type of mechanisms are used.
      Multiple types of method are allowed to use together. For example,
      Applications could use RTP retransmission to recovery some lost
      packets and use noise insertion to conceal some losses that could
      not be fixed.

   block length: 16 bits

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

   Lossless Video Image Duration: 32 bits

      The total time length, expressed in units of millisecond, of no
      loss video pictures without applying loss concealment methods.

      Two values are reserved: A value of 0xFFFFFFFE indicates out of
      range (that is, a measured value exceeding 0xFFFFFFFD) and a value
      of 0xFFFFFFFF indicates that the measurement is unavailable.

   Loss Concealed Image Duration: 32 bits

      The total time length, expressed in units of millisecond, of



<Huang>                 Expires January 4, 2015                 [Page 6]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


      concealed damaged video pictures, which have already applied loss
      concealment methods corresponding to VLCM. The duration of damaged
      video pictures only partial of which is repaired is also
      considered in this metric.

      Two values are reserved: A value of 0xFFFFFFFE indicates out of
      range (that is, a measured value exceeding 0xFFFFFFFD) and a value
      of 0xFFFFFFFF indicates that the measurement is unavailable.

   Average Damaged Microblock Fraction(DMBF): 8 bits

      Average Damaged Microblock Fraction is the mean fraction of
      microblocks damaged in a damaged video frame over the measurement
      period.  If a video frame is totally lost, the Damaged Microblock
      Fraction of this frame is set to 100. If the frame has no damage,
      the Damaged Microblock Fraction of this frame is set to 0.

      One values are reserved: A value of 0xFFFF indicates that the
      measurement is unavailable.

   Average Concealed Micro Block Fraction(CMBF): 8 bits

      Average Concealed Microblock Fraction is the mean fraction of
      concealed microblocks comparing to  in a damaged video frame over
      the measurement period.  If a video frame is totally lost and
      totally concealed, the Concealed Microblock Fraction of this frame
      is set to 100; If the frame has no damage, the Concealed
      Microblock Fraction of this frame is set to 0; If no concealed
      microblocks in a damaged video frame, the Concealed Microblock
      Fraction of this frame is equal to Damaged Microblock Fraction.

      One values are reserved: A value of 0xFFFF indicates that the
      measurement is unavailable.

   Reserved: 16 bits

      These bits are reserved.  They MUST be set to zero by senders and
      ignored by receivers (See [RFC6709] section 4.2).



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



<Huang>                 Expires January 4, 2015                 [Page 7]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


   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-vlc-block

   xr-vlc-block = "video-loss-concealment"

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 Video Loss
   Concealment reports, which will be affect the estimation of video
   loss concealment mechanisms performance and QoE of users.
   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 VLC in the IANA "RTP
   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
   the "Video Loss Concealment Metrics Report Block".

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



<Huang>                 Expires January 4, 2015                 [Page 8]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


6.2 New RTCP XR SDP Parameter

   This document also registers a new parameter "video-loss-concealment"
   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 Acknowledgements

   TBD.

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.

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

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

   [RFC5104]  Wenger, S., Chandra, U., Westerlund, M., and B. Burman,



<Huang>                 Expires January 4, 2015                 [Page 9]


INTERNET DRAFT       <Video LC Metrics for RTCP XR>         July 3, 2014


              "Codec Control Messages in the RTP Audio-Visual Profile
              with Feedback (AVPF)", RFC 5104, February 2008.

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

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

   [i.d-ietf-xrblock-rtcp-xr-loss-concealment] Clark, A., Zorn, G., Bi,
              C. and Q., Wu, "RTCP XR Report Block for Concealment
              Metrics Reporting on Audio Applications", 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

   TBD.

Authors' Addresses


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

   EMail: rachel.huang@huawei.com









<Huang>                 Expires January 4, 2015                [Page 10]