draft-ietf-avt-post-repair-rtcp-xr-00.txt   draft-ietf-avt-post-repair-rtcp-xr-01.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: January 8, 2009 Cisco Systems Expires: February 7, 2009 Cisco Systems
July 7, 2008 August 6, 2008
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-00 draft-ietf-avt-post-repair-rtcp-xr-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 8, 2009. This Internet-Draft will expire on February 7, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines a new report block type within the framework of This document defines a new report block type within the framework of
RTP Control Protocol (RTCP) Extended Reports (XR). One of the RTP Control Protocol (RTCP) Extended Reports (XR). One of the
initial XR report block types is the Loss Run Length Encoding (RLE) initial XR report block types is the Loss Run Length Encoding (RLE)
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4
3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4 3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4
4. Session Description Protocol Signaling . . . . . . . . . . . . 5 4. Session Description Protocol Signaling . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 8
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).
One of the initial XR report block types defined in [RFC3611] is the One of the initial XR report block types defined in [RFC3611] is the
Loss Run Length Encoding (RLE) Report Block. This report conveys the Loss Run Length Encoding (RLE) Report Block. This report conveys the
information regarding the individual RTP packet receipt and loss information regarding the individual RTP packet receipt and loss
events experienced during the RTCP interval preceding the events experienced during the RTCP interval preceding the
transmission of the report. However, the Loss RLE in an RTCP XR transmission of the report. However, the Loss RLE in an RTCP XR
report is usually collected only on the primary source stream before report is usually collected only on the primary source stream before
any error-repair technique is applied. Once one or more error-repair any error-repair technique is applied. Once one or more error-repair
techniques, e.g., Forward Error Correction (FEC) techniques, e.g., Forward Error Correction (FEC) [RFC5109] and/or
[I-D.begen-fecframe-1d2d-parity-scheme] and/or retransmission retransmission [RFC4588], are applied, some or all of the lost
[RFC4588], are applied, some or all of the lost packets on the packets on the primary source stream may be recovered. However, the
primary source stream may be recovered. However, the pre-repair Loss pre-repair Loss RLE cannot indicate which source packets were
RLE cannot indicate which source packets were recovered and which are recovered and which are still missing. Thus, the pre-repair Loss RLE
still missing. Thus, the pre-repair Loss RLE cannot specify how well cannot specify how well the error repair performed.
the error repair performed.
This issue can be addressed by generating an additional report block This issue can be addressed by generating an additional report block
(within the same RTCP XR report), which reflects the packet receipt/ (within the same RTCP XR report), which reflects the packet receipt/
loss events after all error-repair techniques are applied. This loss events after all error-repair techniques are applied. This
report block, which we refer to as the Post-repair Loss RLE, report block, which we refer to as the Post-repair Loss RLE,
indicates the remaining missing, i.e., unrepairable, source packets. indicates the remaining missing, i.e., unrepairable, source packets.
When the pre- and post-repair Loss RLEs are compared, the RTP sender When the pre- and post-repair Loss RLEs are compared, the RTP sender
or another 3rd party entity can evaluate the effectiveness of the or another third party entity can evaluate the effectiveness of the
error-repair techniques in an aggregated fashion. error-repair techniques in an aggregated fashion.
Note that the idea of using pre- and post-repair Loss RLEs can be Note that the idea of using pre- and post-repair Loss RLEs can be
further extended when multiple sequential error-repair techniques are further extended when multiple sequential error-repair techniques are
applied to the primary source stream. Reporting the Loss RLEs before applied to the primary source stream. Reporting the Loss RLEs before
and after each error-repair technique can provide specific and after each error-repair technique can provide specific
information about the individual performances of these techniques. information about the individual performances of these techniques.
However, it can be a difficult task to quantify the specific However, it can be a difficult task to quantify the specific
contribution made by each error-repair technique in hybrid systems, contribution made by each error-repair technique in hybrid systems,
where different techniques collectively work together to repair the where different techniques collectively work together to repair the
skipping to change at page 4, line 20 skipping to change at page 4, line 20
3. Post-Repair Loss RLE Report Block 3. Post-Repair Loss RLE Report Block
The Post-repair Loss RLE Report Block is similar to the existing Loss The Post-repair Loss RLE Report Block is similar to the existing Loss
RLE Report Block defined in [RFC3611]. The report is formatted as RLE Report Block defined in [RFC3611]. The report is formatted as
sketched in Figure 1. sketched in Figure 1.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD | rsvd. | T | block length | | BT=10 | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source | | SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 | | chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... : : ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n | | chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the post-repair loss RLE report block Figure 1: Format for the post-repair loss RLE report block
o block type (BT): 8 bits o block type (BT): 8 bits
A Post-repair Loss RLE Report Block is identified by the constant A Post-repair Loss RLE Report Block is identified by the constant
TBD. 10.
o rsvd.: 4 bits o rsvd.: 4 bits
This field is reserved for future definition. In the absence of This field is reserved for future definition. In the absence of
such definition, the bits in this field MUST be set to zero and such definition, the bits in this field MUST be set to zero and
MUST be ignored by the receiver. MUST be ignored by the receiver.
o thinning (T): 4 bits o thinning (T): 4 bits
The amount of thinning performed on the sequence number space. The amount of thinning performed on the sequence number space.
Only those packets with sequence numbers 0 mod 2^T are reported on Only those packets with sequence numbers 0 mod 2^T are reported on
by this block. A value of 0 indicates that there is no thinning, by this block. A value of 0 indicates that there is no thinning,
skipping to change at page 5, line 45 skipping to change at page 5, line 45
rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF
xr-format = "post-repair-loss-rle" ["=" max-size] xr-format = "post-repair-loss-rle" ["=" max-size]
max-size = 1*DIGIT ; maximum block size in octets max-size = 1*DIGIT ; maximum block size in octets
DIGIT = %x30-39 DIGIT = %x30-39
CRLF = %d13.10 CRLF = %d13.10
Figure 2 Figure 2
Refer to Section 5.1 of [RFC3611] for a detailed description of the Refer to Section 5.1 of [RFC3611] for a detailed description and the
full syntax of the "rtcp-xr" attribute. full syntax of the "rtcp-xr" attribute.
5. Security Considerations 5. Security Considerations
The security considerations of [RFC3611] apply. The security considerations of [RFC3611] apply in this document as
well.
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 TBD in the RTCP XR Block This document assigns the block type value 10 in the RTCP XR Block
Type Registry to "Post-repair Loss RLE Report Block." This document Type Registry to "Post-repair Loss RLE Report Block." This document
also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for
the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry. the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry.
The contact information for the registrations is: The contact information for the registrations is:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
170 West Tasman Drive 170 West Tasman Drive
skipping to change at page 6, line 49 skipping to change at page 7, line 7
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003. November 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
8.2. Informative References 8.2. Informative References
[I-D.begen-fecframe-1d2d-parity-scheme] [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
Begen, A. and R. Asati, "1-D and 2-D Parity FEC Scheme for Correction", RFC 5109, December 2007.
FEC Framework", draft-begen-fecframe-1d2d-parity-scheme-00
(work in progress), February 2008.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
Authors' Addresses Authors' Addresses
Ali Begen Ali Begen
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
 End of changes. 12 change blocks. 
22 lines changed or deleted 20 lines changed or added

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