AVTEXT                                                      A. Fineberg
Internet Draft                                              vLine, Inc.
Intended status: Standards Track                           July 8, 2013
Expires: January 8, 2014



    A Real-Time Transport Protocol (RTP) Header Extension for VP8 Temporal Layer Information
                draft-fineberg-avtext-temporal-layer-ext-00


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), 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/ietf/1id-abstracts.txt

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

   This Internet-Draft will expire on December 9, 2013.

Copyright Notice

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



Fineberg               Expires January 8, 2014                 [Page 1]


Internet-Draft         VP8 Temporal Layer Information                July 2013


Abstract

   This document defines a mechanism by which packets of Real-Time
   Tranport Protocol (RTP) video streams encoded with the VP8 codec can
   indicate, in an RTP header extension, the temporal layer information
   about the frame encoded in the RTP packet.  This information can be
   used in a middlebox performing bandwidth management of streams
   without requiring it to decrypt the streams.

Table of Contents


   1.   Introduction.................................................2
   2.   Conventions used in this document............................3
   3.   Temporal Layer Information...................................3
   4.   Signaling (Setup) Information................................3
   5.   Considerations on Use........................................4
   6.   Security Considerations......................................4
   7.   IANA Considerations..........................................4
   8.   References...................................................5
      8.1.   Normative References....................................5
      8.2.   Informative References..................................5

1. Introduction

   In a centralized Real-Time Transport Protocol (RTP) [RFC3550] video
   conference, a video mixer or forwarder receives video streams from
   many or all of the conference participants.  It then selectively
   forwards some or all of the video streams to other participants in
   the conference.

   It is often necessary to manage the bandwidth usage when forwarding
   these streams.  One tool provided to manage the bandwidth usage when
   handling video streams that are encoded using the VP8 codec is the
   use of temporal scaling by selectively forwarding only the desired
   temporal layers.  These layers are defined by their temporal layer
   index.  The temporal layer information is encoded in the RTP payload
   format for VP8 video [draft-ietf-payload-vp8-08].

   It is desirable however in the case of Secure Real-Time Transport
   Protocol (SRTP) [RFC3711] to be able to manage the temporal scaling
   without having to decrypt the SRTP packets.

   As an alternative, this document defines an RTP header extension
   [RFC5285] through which senders of video packets can indicate the
   temporal layer information of the packets' payload, reducing the
   processing load for a server.


Fineberg               Expires January 9, 2013                 [Page 2]


Internet-Draft         VP8 Temporal Layer Information                July 2013


2. Conventions used in this document

   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. Temporal Layer Information

   The VP8 temporal layer information header extension carries the 2-bit
   temporal layer index (TID), layer sync bit (Y), and 15-bit running
   index of the frames (PictureID), as defined in [draft-ietf-payload-
   vp8-08], of the VP8 encoded video frame in the RTP [RFC3550] payload
   of the packet it is associated with.  This information is carried in
   an RTP header extension element as defined by the ''General Mechanism
   for RTP Header Extensions'' [RFC5285].

   The payload of the VP8 temporal layer information header extension
   element can be encoded using the one-byte header defined in
   [RFC5285].  Figure 1 shows a representative VP8 temporal layer
   information encoding.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID   | len=2 |  pad=0  |TID|Y|           PictureID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Figure 1 Representative VP8 temporal layer information encoding using
                        the one-byte header format

   Note that, as indicated in [RFC5285] length field in the one-byte
   header format takes the value 2 to indicate that 3 byte follows.

4. Signaling (Setup) Information

   The URI for declaring this header extension in an extmap attribute is
   "urn:ietf:params:rtp-hdrext:vp8tlinfo".  It does not contain any
   extension attributes.

   An example attribute line in the SDP, might look like:

      a=extmap:3 urn:ietf:params:rtp-hdrext:vp8tlinfo

   If this extension is signaled when the VP8 codec is not in use, it
   SHOULD be ignored and this header extension element SHOULD NOT be
   included in the RTP header.  If the header extension element is
   included in the RTP header when VP8 is not in use or when VP8 is in



Fineberg               Expires January 9, 2013                 [Page 3]


Internet-Draft         VP8 Temporal Layer Information                July 2013


   use but temporal layering is disabled, the value for the temporal
   layer index (TID) MUST be 0.

5. Considerations on Use

   This header extension makes no attempt to change the values already
   contained in the RTP Payload Format for VP8 [draft-ietf-payload-vp8].
   Therefore when this header extension is present, the values in the
   header extension MUST be faithful representations of the values
   contained in the RTP payload.  Any discrepancy between the values
   MUST be treated as an error.

6. Security Considerations

   A malicious endpoint could choose to set the values in this header
   extension falsely so as to claim a different encoding state.  It is
   not clear what could be gained by falsifying the encoding state as it
   would only impact the decoding of the senders video.  While this
   might not impact a receiving endpoint that chooses to use the values
   contained in the RTP payload instead of those in the RTP header
   extension, it could impact endpoints that rely solely on the values
   form the RTP header extension as well as adversely impact the work
   done on a middlebox.  As typically a middlebox will only use this
   information for bandwidth management (which includes in this context
   handling endpoints without the capability to decode a stream at full
   frame rate), this falsified data could convince the middlebox that
   every frame is a required frame and thereby implement a denial of
   service attack on an endpoint. Thus if a middlebox device relies on
   data from an untrusted endpoint, it SHOULD periodically audit the
   data to ensure the RTP payload values match those in the RTP header
   extension.

   In the Secure Real-Time Transport Protocol (SRTP) [RFC3711], RTP
   header extensions are authenticated but not encrypted.  When this
   header extension is used, VP8 temporal layer information is therefore
   visible on a packet-by-packet basis to an attacker passively
   observing the video stream.  As this information provides no insight
   into the contents of the video stream, it is not considered a high
   risk exposure.

7. IANA Considerations

   This document defines a new extension URI to the RTP Compact
   HeaderExtensions subregistry of the Real-Time Transport Protocol
   (RTP) Parameters registry, according to the following data:




Fineberg               Expires January 9, 2013                 [Page 4]


Internet-Draft         VP8 Temporal Layer Information                July 2013


   Extension URI:  urn:ietf:params:rtp-hdrext:vp8tlinfo
   Description: VP8 Temporal Layer Information
   Contact: fineberg@vline.com
   Reference: RFC XXXX

   Note to RFC Editor: please replace RFC XXXX with the number of this
   RFC.


8. References

8.1. Normative References

   [RFC2119] 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, RFC3550, July 2003.

   [RFC4301] Kent, S. and K. Seo, ''Security Architecture for the
             Internet Protocol'', RFC 4301, December 2005.

   [RFC5285] Singer, D. and H. Desineni, ''A General Mechanism for RTP
             Header Extensions'', RFC 5285, July 2008.

8.2. Informative References

   [I-D.ietf-payload-vp8-08]  Westin, P., Lundin, H., Glover, M.,Uberti,
             J., and F. Galligan, "RTP Payload Format for VP8 Video",
             (work in progress) January, 2013.

   [I-D.ietf-avtcore-srtp-encrypted-header-ext] Lennox, J., ''Encryption
             of Header Extensions in the Secure Real-Time Transport
             Protocol (SRTP)'' (work in progress) October, 2011.

   [RFC6386] Bankoski, J., Koleszar, J., Quillio, L., Salonen, J.,
             Wilkins, P., and Y. Xu, ''VP8 Data Format and Decoding
             Guide'', RFC 6386, November 2011.

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






Fineberg               Expires January 9, 2013                 [Page 5]


Internet-Draft         VP8 Temporal Layer Information                July 2013


Authors' Addresses

   Adam Fineberg
   vLine, Inc.
   116 Hamilton Ave
   Palo Alto, CA 94301

   Email: fineberg@vline.com









































Fineberg               Expires January 9, 2013                 [Page 6]