summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7002.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7002.txt')
-rw-r--r--doc/rfc/rfc7002.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc7002.txt b/doc/rfc/rfc7002.txt
new file mode 100644
index 0000000..26860e1
--- /dev/null
+++ b/doc/rfc/rfc7002.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Clark
+Request for Comments: 7002 Telchemy
+Category: Standards Track G. Zorn
+ISSN: 2070-1721 Network Zen
+ Q. Wu
+ Huawei
+ September 2013
+
+
+ RTP Control Protocol (RTCP) Extended Report (XR) Block
+ for Discard Count Metric Reporting
+
+Abstract
+
+ This document defines an RTP Control Protocol (RTCP) Extended Report
+ (XR) block that allows the reporting of a simple discard count metric
+ for use in a range of RTP applications.
+
+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/rfc7002.
+
+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.
+
+
+
+
+
+Clark, et al. Standards Track [Page 1]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Discard Count Report Block . . . . . . . . . . . . . . . 2
+ 1.2. RTCP and RTCP Extended Reports . . . . . . . . . . . . . 3
+ 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3
+ 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Discard Count Metrics Block . . . . . . . . . . . . . . . . . 4
+ 3.1. Report Block Structure . . . . . . . . . . . . . . . . . 5
+ 3.2. Definition of Fields in the Discard Count Metrics Block . 5
+ 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 4.1. SDP rtcp-xr Attribute Extension . . . . . . . . . . . . . 7
+ 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . 7
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . 8
+ 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 8
+ 5.3. Contact Information for Registrations . . . . . . . . . . 8
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 10
+ Appendix A. Metrics Represented Using the Template from RFC 6390 11
+
+1. Introduction
+
+1.1. Discard Count Report Block
+
+ This document defines a new block type to augment those defined in
+ [RFC3611] for use in a range of RTP applications. The new block type
+ supports the reporting of the number of packets that are received
+ correctly but are never played out, typically because they arrive too
+ late (buffer underflow) or too early (buffer overflow) to be played
+ out. The metric is applicable both to systems that use packet loss
+ repair techniques (such as forward error correction [RFC5109] or
+ retransmission [RFC4588]) and to those that do not.
+
+ This metric is useful for identifying the existence, and
+ characterizing the severity, of packet transport problems that may
+ affect users' perceptions of a service delivered over RTP.
+
+ This block may be used in conjunction with [RFC7003], which provides
+ additional information on the pattern of discarded packets. However,
+ the metric in [RFC7003] may be used independently of the metrics in
+ this block.
+
+
+
+
+Clark, et al. Standards Track [Page 2]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+ When a Discard Count Metrics Block is sent together with a Burst/Gap
+ Discard Metrics Block (defined in [RFC7003]) to the media sender or
+ RTP-based network management system, the information carried in the
+ Discard Count Metrics Block and the Burst/Gap Discard Metrics Block
+ allows systems receiving the blocks to calculate burst/gap summary
+ statistics (e.g., the gap discard rate).
+
+ The metric belongs to the class of transport-related end-system
+ metrics defined in [RFC6792].
+
+1.2. RTCP and RTCP Extended Reports
+
+ The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
+ defined an extensible structure for reporting using an RTCP Extended
+ Report (XR). This document defines a new Extended Report block for
+ use with [RFC3550] and [RFC3611].
+
+1.3. Performance Metrics Framework
+
+ "Guidelines for Considering New Performance Metric Development"
+ [RFC6390] provides guidance on the definition and specification of
+ performance metrics. "Guidelines for Use of the RTP Monitoring
+ Framework" [RFC6792] provides guidance for reporting block format
+ using RTCP XR. The metrics block described in this document is in
+ accordance with the guidelines in [RFC6390] and [RFC6792].
+
+1.4. Applicability
+
+ This metric is believed to be applicable to a large class of RTP
+ applications that use a de-jitter buffer [RFC5481].
+
+ Discards due to late or early arriving packets affect user
+ experience. The reporting of discards alerts senders and other
+ receivers to the need to adjust their transmission or reception
+ strategies. The reports allow network managers to diagnose these
+ user experience problems.
+
+ The ability to detect duplicate packets can be used by managers to
+ detect network layer or sender behavior, which may indicate network
+ or device issues. Based on the reports, these issues may be
+ addressed prior to any impact on user experience.
+
+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 RFC 2119 [RFC2119].
+
+
+
+
+Clark, et al. Standards Track [Page 3]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+ In addition, the following terms are defined:
+
+ Received, Lost, and Discarded
+
+ A packet shall be regarded as lost if it fails to arrive within an
+ implementation-specific time window. A packet that arrives within
+ this time window but is either too early or too late to be played
+ out or is thrown away before playout due to packet duplication or
+ redundancy shall be regarded as discarded. A packet shall not be
+ regarded as discarded if it arrives within this time window but is
+ dropped during decoding by some higher layer decoder, e.g., due to
+ a decoding error. A packet shall be classified as one of the
+ following: received (or OK), discarded, or lost. The discard
+ count metric counts only discarded packets. The metric
+ "cumulative number of packets lost" defined in [RFC3550] reports a
+ count of packets lost from the media stream (single
+ synchronization source (SSRC) within a single RTP session).
+ Similarly, the metric "number of packets discarded" reports a
+ count of packets discarded from the media stream (single SSRC
+ within a single RTP session) arriving at the receiver. Another
+ metric defined in [RFC5725] is available to report on packets that
+ are not recovered by any repair techniques that may be in use.
+
+3. Discard Count Metrics Block
+
+ Metrics in this block report on the number of packets discarded in
+ the stream arriving at the RTP end system. The measurement of these
+ metrics is made at the receiving end of the RTP stream. Instances of
+ this metrics block use the SSRC to refer to the separate auxiliary
+ Measurement Information Block [RFC6776], which describes measurement
+ periods in use (see [RFC6776], Section 4.2). This metrics block
+ relies on the measurement interval in the Measurement Information
+ Block indicating the span of the report and MUST be sent in the same
+ compound RTCP packet as the Measurement Information Block. If the
+ measurement interval is not received in the same compound RTCP packet
+ as this metrics block, this metrics block MUST be discarded.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 4]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+3.1. Report Block Structure
+
+ The structure of the Discard Count Metrics Block is as follows.
+
+ 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=24 | I |DT | resv | Block Length = 2 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSRC of Source |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Discard Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Report Block Structure
+
+3.2. Definition of Fields in the Discard Count Metrics Block
+
+ Block Type (BT): 8 bits
+
+ A Discard Count Metrics Block is identified by the constant 24.
+
+ 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.
+
+ In this document, the discard count metric can only be measured
+ over definite intervals and cannot be sampled. Accordingly, the
+ value I=01, indicating a sampled value, MUST NOT be sent, and MUST
+ be discarded when received. In addition, the value I=00 is
+ reserved and also MUST NOT be sent, and MUST be discarded when
+ received.
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 5]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+ Discard Type (DT): 2 bits
+
+ This field is used to identify the discard type used in this
+ report block. The discard type is defined as follows:
+
+ 00: Report packet discarded or being thrown away before playout
+ due to packet duplication.
+
+ 01: Report packet discarded due to too early to be played out.
+
+ 10: Report packet discarded due to too late to be played out.
+
+ The value DT=11 is reserved for future definition and MUST NOT be
+ sent, and MUST be discarded when received.
+
+ An endpoint MAY report any combination of discard types in each
+ reporting interval by including several Discard Count Metrics
+ Blocks in a single RTCP XR packet.
+
+ Some systems send duplicate RTP packets for robustness or error
+ resilience. This is NOT RECOMMENDED since it breaks RTCP packet
+ statistics. If duplication is desired for error resilience, the
+ mechanism described in [RTPDUP] can be used, since this will not
+ cause breakage of RTP streams or RTCP statistics.
+
+ Reserved (resv): 4 bits
+
+ These bits are reserved. They MUST be set to zero by senders and
+ ignored by receivers (see [RFC6709], Section 4.2).
+
+ Block Length: 16 bits
+
+ The length of this report block in 32-bit words, minus one, in
+ accordance with the definition in [RFC3611]. This field MUST be
+ set to 2 to match the fixed length of the report block. 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].
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 6]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+ Discard Count
+
+ Number of packets discarded over the period (Interval or
+ Cumulative) covered by this report.
+
+ The measured value is an unsigned value. If the measured value
+ exceeds 0xFFFFFFFD, the value 0xFFFFFFFE MUST be reported to
+ indicate an over-range measurement. If the measurement is
+ unavailable, the value 0xFFFFFFFF MUST be reported.
+
+ Note that the number of packets expected in the period associated
+ with this metric (whether Interval or Cumulative) is available
+ from the difference between a pair of extended sequence numbers in
+ the Measurement Information Block [RFC6776], so it need not be
+ repeated in this block.
+
+4. SDP Signaling
+
+ [RFC3611] defines the use of the Session Description Protocol (SDP)
+ [RFC4566] for signaling the use of XR blocks. However, XR blocks MAY
+ be used without prior signaling (see Section 5 of RFC 3611).
+
+4.1. SDP rtcp-xr Attribute Extension
+
+ This section augments the SDP [RFC4566] attribute "rtcp-xr" defined
+ in [RFC3611] by providing an additional value of "xr-format" to
+ signal the use of the report block defined in this document. The
+ ABNF [RFC5234] syntax is as follows.
+
+ xr-format =/ xr-pdc-block
+ xr-pdc-block = "pkt-discard-count"
+
+
+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
+ parameters, refer to Section 5.2 of [RFC3611].
+
+5. 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].
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 7]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+5.1. New RTCP XR Block Type Value
+
+ This document assigns the block type value 24 in the IANA "RTP
+ Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
+ the "Discard Count Metrics Block".
+
+5.2. New RTCP XR SDP Parameter
+
+ This document also registers a new parameter "pkt-discard-count" in
+ the "RTP Control Protocol Extended Reports (RTCP XR) Session
+ Description Protocol (SDP) Parameters Registry".
+
+5.3. Contact Information for Registrations
+
+ The following contact information is provided for all registrations
+ in this document:
+
+ Qin Wu (sunseawq@huawei.com)
+ 101 Software Avenue, Yuhua District
+ Nanjing, Jiangsu 210012
+ China
+
+6. Security Considerations
+
+ In some situations, returning very detailed error information (e.g.,
+ over-range measurement or measurement unavailable) using this report
+ block can provide an attacker with insight into the security
+ processing. Where this is a concern, the implementation should apply
+ encryption and authentication to this report block. For example,
+ this can be achieved by using the Audio-Visual Profile with Feedback
+ (AVPF) profile together with the Secure RTP profile, as defined in
+ [RFC3711]; an appropriate combination of those two profiles ("SAVPF")
+ is specified in [RFC5124].
+
+ Besides this, 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
+ confidentiality documented in Section 7, paragraph 3 of [RFC3611]
+ does not apply.
+
+7. Contributors
+
+ Geoff Hunt wrote the initial draft of this document.
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 8]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+8. Acknowledgments
+
+ The authors gratefully acknowledge reviews and feedback provided by
+ Bruce Adams, Philip Arden, Amit Arora, Claire Bi, Bob Biskner,
+ Gonzalo Camarillo, Benoit Claise, Kevin Connor, Claus Dahm, Spencer
+ Dawkins, Randy Ethier, Roni Even, Stephen Farrel, Jim Frauenthal,
+ Kevin Gross, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones,
+ Rajesh Kumar, Keith Lantz, Jonathan Lennox, Mohamed Mostafa, Amy
+ Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Dan Romascanu,
+ Albrecht Schwarz, Varun Singh, Tom Taylor, Dan Wing, and Hideaki
+ Yamada.
+
+9. References
+
+9.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.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [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.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design
+ Considerations for Protocol Extensions", RFC 6709,
+ September 2012.
+
+ [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and Information
+ Reporting Using a Source Description (SDES) Item and an
+ RTCP Extended Report (XR) Block", RFC 6776, October 2012.
+
+
+
+Clark, et al. Standards Track [Page 9]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+9.2. Informative References
+
+ [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.
+
+ [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
+ Applicability Statement", RFC 5481, March 2009.
+
+ [RFC5725] Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
+ Report Block Type for RTP Control Protocol (RTCP) Extended
+ Reports (XRs)", RFC 5725, February 2010.
+
+ [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.
+
+ [RFC7003] Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control
+ Protocol(RTCP) Extended Report (XR) Block for Burst/Gap
+ Discard Metric Reporting", RFC 7003, September 2013.
+
+ [RTPDUP] Begen, A. and C. Perkins, "Duplicating RTP Streams", Work
+ in Progress, March 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 10]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+Appendix A. Metrics Represented Using the Template from RFC 6390
+
+ a. Number of Packets Discarded Metric
+
+ * Metric Name: Number of RTP packets discarded.
+
+ * Metric Description: Number of RTP packets discarded over the
+ period covered by this report.
+
+ * Method of Measurement or Calculation: See Section 3.2, Discard
+ Count definition.
+
+ * Units of Measurement: See Section 3.2, Discard Count
+ definition.
+
+ * Measurement Point(s) with Potential Measurement Domain: See
+ Section 3, 1st paragraph.
+
+ * Measurement Timing: See Section 3, 1st paragraph for
+ measurement timing and Section 3.2 for Interval Metric flag.
+
+ * Use and Applications: See Section 1.4.
+
+ * Reporting Model: See RFC 3611.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 11]
+
+RFC 7002 RTCP XR Discard September 2013
+
+
+Authors' Addresses
+
+ Alan Clark
+ Telchemy Incorporated
+ 2905 Premiere Parkway, Suite 280
+ Duluth, GA 30097
+ USA
+
+ EMail: alan.d.clark@telchemy.com
+
+
+ Glen Zorn
+ Network Zen
+ 227/358 Thanon Sanphawut
+ Bang Na, Bangkok 10260
+ Thailand
+
+ Phone: +66 (0) 8-1000-4155
+ EMail: glenzorn@gmail.com
+
+
+ Qin Wu
+ Huawei
+ 101 Software Avenue, Yuhua District
+ Nanjing, Jiangsu 210012
+ China
+
+ EMail: sunseawq@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al. Standards Track [Page 12]
+