draft-ietf-avt-post-repair-rtcp-xr-06.txt   draft-ietf-avt-post-repair-rtcp-xr-07.txt 
AVT A. Begen AVT A. Begen
Internet-Draft D. Hsu Internet-Draft D. Hsu
Intended status: Standards Track M. Lague Intended status: Standards Track M. Lague
Expires: April 18, 2010 Cisco Systems Expires: May 15, 2010 Cisco Systems
October 15, 2009 November 11, 2009
Post-Repair Loss RLE Report Block Type for RTCP XR Post-Repair Loss RLE Report Block Type for RTCP XR
draft-ietf-avt-post-repair-rtcp-xr-06 draft-ietf-avt-post-repair-rtcp-xr-07
Abstract
This document defines a new report block type within the framework of
RTP Control Protocol (RTCP) Extended Reports (XR). One of the
initial XR report block types is the Loss Run Length Encoding (RLE)
Report Block. This report conveys the information regarding the
individual Real-time Transport Protocol (RTP) packet receipt and loss
events experienced during the RTCP interval preceding the
transmission of the report. The new report, which is referred to as
the Post-repair Loss RLE Report, carries the information regarding
the remaining lost packets after all loss-repair methods are applied.
By comparing the RTP packet receipts/losses before and after the loss
repair is completed, one can determine the effectiveness of the loss-
repair methods in an aggregated fashion. This document also defines
the signaling of the Post-repair Loss RLE Report in the Session
Description Protocol (SDP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 18, 2010. This Internet-Draft will expire on May 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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 BSD License.
This document defines a new report block type within the framework of This document may contain material from IETF Documents or IETF
RTP Control Protocol (RTCP) Extended Reports (XR). One of the Contributions published or made publicly available before November
initial XR report block types is the Loss Run Length Encoding (RLE) 10, 2008. The person(s) controlling the copyright in some of this
Report Block. This report conveys the information regarding the material may not have granted the IETF Trust the right to allow
individual Real-time Transport Protocol (RTP) packet receipt and loss modifications of such material outside the IETF Standards Process.
events experienced during the RTCP interval preceding the Without obtaining an adequate license from the person(s) controlling
transmission of the report. The new report, which is referred to as the copyright in such materials, this document may not be modified
the Post-repair Loss RLE Report, carries the information regarding outside the IETF Standards Process, and derivative works of it may
the remaining lost packets after all loss-repair methods are applied. not be created outside the IETF Standards Process, except to format
By comparing the RTP packet receipts/losses before and after the loss it for publication as an RFC or to translate it into languages other
repair is completed, one can determine the effectiveness of the loss- than English.
repair methods in an aggregated fashion. This document also defines
the signaling of the Post-repair Loss RLE Report in the Session
Description Protocol (SDP).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4
3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . 5 3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4
4. Session Description Protocol Signaling . . . . . . . . . . . . 7 4. Session Description Protocol Signaling . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
RTP Control Protocol (RTCP) is the out-of-band control protocol for RTP Control Protocol (RTCP) is the out-of-band control protocol for
the applications that are using the Real-time Transport Protocol the applications that are using the Real-time Transport Protocol
(RTP) for media delivery and communications [RFC3550]. RTCP allows (RTP) for media delivery and communications [RFC3550]. RTCP allows
the RTP entities to monitor the data delivery and provides them the RTP entities to monitor the data delivery and provides them
minimal control functionality via sender and receiver reports as well minimal control functionality via sender and receiver reports as well
as other control packets. [RFC3611] expands the RTCP functionality as other control packets. [RFC3611] expands the RTCP functionality
further by introducing the RTCP Extended Reports (XR). further by introducing the RTCP Extended Reports (XR).
skipping to change at page 8, line 31 skipping to change at page 8, line 31
attacker that could not be similarly obtained by watching the RTP attacker that could not be similarly obtained by watching the RTP
packets fly by himself, performing the repair algorithms and packets fly by himself, performing the repair algorithms and
computing the desired output. computing the desired output.
An attacker may interfere with the repair process for an RTP stream. An attacker may interfere with the repair process for an RTP stream.
In that case, if the attacker is able to see the post-repair Loss In that case, if the attacker is able to see the post-repair Loss
RLEs, the attacker may infer whether the attack is effective or not, RLEs, the attacker may infer whether the attack is effective or not,
in which case the attacker may continue attacking or alter the in which case the attacker may continue attacking or alter the
attack. In practice, however, this does not pose a security risk. attack. In practice, however, this does not pose a security risk.
An attacker may put incorrect information in the regular pre-repair
and post-repair Loss RLE reports such that it impacts the proactive
decisions made by the sender in the repair process or the reactive
decisions when responding to the feedback messages coming from the
receiver. A sender application should be aware of such risks and
should take the necessary precautions to minimize the chances for (or
better eliminate) such attacks.
Similar to other RTCP XR reports, the post-repair Loss RLE reports Similar to other RTCP XR reports, the post-repair Loss RLE reports
MAY be protected by using SRTP and SRTCP [RFC3711]. MAY be protected by using SRTP and SRTCP [RFC3711].
6. IANA Considerations 6. IANA Considerations
New block types for RTCP XR are subject to IANA registration. For New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to general guidelines on IANA considerations for RTCP XR, refer to
[RFC3611]. [RFC3611].
This document assigns the block type value 10 in the RTCP XR Block This document assigns the block type value 10 in the RTCP XR Block
 End of changes. 8 change blocks. 
46 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/