summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5725.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5725.txt')
-rw-r--r--doc/rfc/rfc5725.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc5725.txt b/doc/rfc/rfc5725.txt
new file mode 100644
index 0000000..afc15de
--- /dev/null
+++ b/doc/rfc/rfc5725.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Begen
+Request for Comments: 5725 D. Hsu
+Category: Standards Track M. Lague
+ISSN: 2070-1721 Cisco
+ February 2010
+
+
+
+ Post-Repair Loss RLE Report Block Type for
+ RTP Control Protocol (RTCP) Extended Reports (XRs)
+
+Abstract
+
+ This document defines a new report block type within the framework of
+ RTP Control Protocol (RTCP) Extended Reports (XRs). One of the
+ initial XR report block types is the Loss Run Length Encoding (RLE)
+ Report Block. This report conveys 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 information regarding the
+ packets that remain lost 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
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5725.
+
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 1]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+Copyright Notice
+
+ Copyright (c) 2010 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.
+
+ This document may contain material 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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 4
+ 3. Post-Repair Loss RLE Report Block . . . . . . . . . . . . . . . 4
+ 4. Session Description Protocol Signaling . . . . . . . . . . . . 6
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 2]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+1. Introduction
+
+ The RTP Control Protocol (RTCP) is the out-of-band control protocol
+ for applications that are using the Real-time Transport Protocol
+ (RTP) for media delivery and communications [RFC3550]. RTCP allows
+ RTP entities to monitor data delivery and provides them minimal
+ control functionality via sender and receiver reports as well as
+ other control packets. [RFC3611] expands the RTCP functionality
+ further by introducing the RTCP Extended Reports (XRs).
+
+ One of the initial XR report block types defined in [RFC3611] is the
+ Loss Run Length Encoding (RLE) Report Block. This report conveys
+ information regarding the individual RTP packet receipt and loss
+ events experienced during the RTCP interval preceding the
+ transmission of the report. However, the Loss RLE in an RTCP XR
+ report is usually collected only on the primary source stream before
+ any loss-repair method is applied. Once one or more loss-repair
+ methods, e.g., Forward Error Correction (FEC) [RFC5109] and/or
+ retransmission [RFC4588], are applied, some or all of the lost
+ packets on the primary source stream may be recovered. However, the
+ pre-repair Loss RLE cannot indicate which source packets were
+ recovered and which are still missing. Thus, the pre-repair Loss RLE
+ cannot specify how well the loss repair performed.
+
+ This issue can be addressed by generating an additional report block
+ (within the same or a different RTCP XR report), which reflects the
+ packet receipt/loss events after all loss-repair methods are applied.
+ This report block, which we refer to as the post-repair Loss RLE,
+ indicates the remaining missing, i.e., unrepairable, source packets.
+ When the pre-repair and post-repair Loss RLEs are compared, the RTP
+ sender or another third-party entity can evaluate the effectiveness
+ of the loss-repair methods in an aggregated fashion. To avoid any
+ ambiguity in the evaluation, it is RECOMMENDED that the post-repair
+ Loss RLE be generated for the source packets that have no further
+ chance of being repaired. If the loss-repair method(s) may still
+ recover one or more missing source packets, the post-repair Loss RLE
+ SHOULD NOT be sent until the loss-recovery process has been
+ completed. However, a potential ambiguity may result from sequence-
+ number wrapping in the primary source stream. Thus, the Post-repair
+ Loss RLE reports may not be delayed arbitrarily. In case of an
+ ambiguity in the incoming reports, it is the sender's or the
+ monitoring entity's responsibility to understand which packets the
+ Post-repair Loss RLE report is related to.
+
+ Similar to the pre-repair Loss RLE, the post-repair Loss RLE conveys
+ the receipt/loss events at the packet level and considers partially
+ repaired packets as unrepaired. Thus, the methods that can partially
+ recover the missing data SHOULD NOT be evaluated based on the
+
+
+
+Begen, et al. Standards Track [Page 3]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+ information provided by the Post-repair Loss RLE reports since such
+ information may underestimate the effectiveness of such methods.
+
+ Note that the idea of using pre-repair and post-repair Loss RLEs can
+ be further extended when multiple sequential loss-repair methods are
+ applied to the primary source stream. Reporting the Loss RLEs before
+ and after each loss-repair method can provide specific information
+ about the individual performances of these methods. However, it can
+ be a difficult task to quantify the specific contribution made by
+ each loss-repair method in hybrid systems, where different methods
+ collectively work together to repair the lost source packets. Thus,
+ in this specification we only consider reporting the Loss RLE after
+ all loss-repair methods have been applied.
+
+ This document registers a new report block type to cover the post-
+ repair Loss RLE within the framework of RTCP XR. Applications that
+ are employing one or more loss-repair methods MAY use Post-repair
+ Loss RLE reports for every packet they receive or for a set of
+ specific packets they have received. In other words, the coverage of
+ the post-repair Loss RLEs may or may not be contiguous.
+
+2. Requirements Notation
+
+ 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 [RFC2119].
+
+3. Post-Repair Loss RLE Report Block
+
+ The Post-repair Loss RLE Report Block is similar to the existing Loss
+ RLE Report Block defined in [RFC3611]. The report format is shown in
+ Figure 1. Using the same structure for reporting both pre-repair and
+ post-repair Loss RLEs allows the implementations to compare the Loss
+ RLEs very efficiently.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 4]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | BT=10 | rsvd. | T | block length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSRC of source |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | begin_seq | end_seq |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | chunk 1 | chunk 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ : ... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | chunk n-1 | chunk n |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Format for the Post-repair Loss RLE Report Block
+
+ o block type (BT): 8 bits
+ A Post-repair Loss RLE Report Block is identified by the constant
+ 10.
+
+ o rsvd.: 4 bits
+ This field is reserved for future definition. In the absence of
+ such definition, the bits in this field MUST be set to zero and
+ MUST be ignored by the receiver.
+
+ o thinning (T): 4 bits
+ The amount of thinning performed on the sequence-number space.
+ Only those packets with sequence numbers 0 mod 2^T are reported by
+ this block. A value of 0 indicates that there is no thinning and
+ all packets are reported. The maximum thinning is one packet in
+ every 32,768 (amounting to two packets within each 16-bit sequence
+ space).
+
+ If thinning is desired, it is RECOMMENDED to use the same thinning
+ value in the Pre-repair and Post-repair Loss RLE reports. This
+ will allow easier report processing and correlation. However,
+ based on the specific needs of the application or the monitoring
+ entity, different values of thinning MAY be used for Pre-repair
+ and Post-repair Loss RLE reports.
+
+ o block length: 16 bits
+ The length of this report block, including the header, in 32-bit
+ words minus one.
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 5]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+ o SSRC of source: 32 bits
+ The SSRC of the RTP data packet source being reported upon by this
+ report block.
+
+ o begin_seq: 16 bits
+ The first sequence number that this block reports on.
+
+ o end_seq: 16 bits
+ The last sequence number that this block reports on plus one.
+
+ o chunk i: 16 bits
+ There are three chunk types: run length, bit vector, and
+ terminating null. These are defined in Section 4 of [RFC3611].
+ If the chunk is all zeroes, then it is a terminating null chunk.
+ Otherwise, the left-most bit of the chunk determines its type: 0
+ for run length and 1 for bit vector.
+
+ Note that the sequence numbers that are included in the report refer
+ to the primary source stream.
+
+ When using Post-repair Loss RLE reports, the amount of bandwidth
+ consumed by the detailed reports should be considered carefully. The
+ bandwidth usage rules, as they are described in [RFC3611], apply to
+ Post-repair Loss RLE reports as well.
+
+4. Session Description Protocol Signaling
+
+ A new parameter is defined for the Post-repair Loss RLE Report Block
+ to be used with Session Description Protocol (SDP) [RFC4566] using
+ the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the
+ following syntax within the "rtcp-xr" attribute [RFC3611]:
+
+ pkt-loss-rle-post = "post-repair-loss-rle" ["=" max-size]
+
+ max-size = 1*DIGIT ; maximum block size in octets
+
+ Refer to Section 5.1 of [RFC3611] for a detailed description and the
+ full syntax of the "rtcp-xr" attribute. The "pkt-loss-rle-post"
+ parameter is compatible with the definition of "format-ext" in the
+ "rtcp-xr" attribute.
+
+5. Security Considerations
+
+ The security considerations of [RFC3611] apply in this document as
+ well. Additional security considerations are briefly mentioned
+ below.
+
+
+
+
+
+Begen, et al. Standards Track [Page 6]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+ An attacker who monitors the regular Pre-repair Loss RLE reports sent
+ by a group of receivers in the same multicast distribution network
+ may infer the network characteristics (Multicast Inference of Network
+ Characteristics). However, monitoring the Post-repair Loss RLE
+ reports will not reveal any further information about the network.
+ Without the regular Pre-repair Loss RLE reports, the Post-repair ones
+ will not be any use to attackers. Even when used with the regular
+ Pre-repair Loss RLE reports, the Post-repair Loss RLE reports only
+ reveal the effectiveness of the repair process. However, this does
+ not enable any new attacks, nor does it provide information to an
+ attacker that could not be similarly obtained by watching the RTP
+ packets fly by himself, performing the repair algorithms and
+ computing the desired output.
+
+ 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
+ RLEs, the attacker may infer whether or not the attack is effective.
+ If not, the attacker may continue attacking or alter the 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
+ MAY be protected by using the Secure RTP (SRTP) and Secure RTP
+ Control Protocol (SRTCP) [RFC3711].
+
+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].
+
+ This document assigns the block type value 10 in the RTCP XR Block
+ Type Registry to "Post-repair Loss RLE Report Block". This document
+ also registers the SDP [RFC4566] parameter "post-repair-loss-rle" for
+ the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry.
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 7]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+ The contact information for the registrations is:
+
+ Ali Begen
+ abegen@cisco.com
+
+ 170 West Tasman Drive
+ San Jose, CA 95134 USA
+
+7. Acknowledgments
+
+ The authors would like to thank the members of the VQE Team at Cisco
+ and Colin Perkins for their inputs and suggestions.
+
+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, RFC 3550, July 2003.
+
+ [RFC3611] Friedman, T., Caceres, R., and A. Clark, "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.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+8.2. Informative References
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+ [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+ Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+ July 2006.
+
+ [RFC5109] Li, A., "RTP Payload Format for Generic Forward Error
+ Correction", RFC 5109, December 2007.
+
+
+
+
+
+Begen, et al. Standards Track [Page 8]
+
+RFC 5725 Post-Repair Loss RLE Report Block Type February 2010
+
+
+Authors' Addresses
+
+ Ali Begen
+ Cisco
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ USA
+
+ EMail: abegen@cisco.com
+
+
+ Dong Hsu
+ Cisco
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ EMail: dohsu@cisco.com
+
+
+ Michael Lague
+ Cisco
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ EMail: mlague@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen, et al. Standards Track [Page 9]
+