diff options
Diffstat (limited to 'doc/rfc/rfc7004.txt')
| -rw-r--r-- | doc/rfc/rfc7004.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc7004.txt b/doc/rfc/rfc7004.txt new file mode 100644 index 0000000..f66c6dd --- /dev/null +++ b/doc/rfc/rfc7004.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Zorn +Request for Comments: 7004 Network Zen +Category: Standards Track R. Schott +ISSN: 2070-1721 Deutsche Telekom + Q. Wu, Ed. + R. Huang + Huawei + September 2013 + + + RTP Control Protocol (RTCP) Extended Report (XR) Blocks + for Summary Statistics Metrics Reporting + +Abstract + + This document defines three RTP Control Protocol (RTCP) Extended + Report (XR) blocks that allow the reporting of loss, duplication, and + discard summary statistics metrics 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/rfc7004. + +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. + + + + +Zorn, et al. Standards Track [Page 1] + +RFC 7004 Summary Stats XR Blocks September 2013 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Summary Statistics Metrics .................................2 + 1.2. RTCP and RTCP Extended Reports .............................3 + 1.3. Performance Metrics Framework ..............................3 + 1.4. Applicability ..............................................3 + 2. Terminology .....................................................3 + 3. Transport-Related End-System Metrics ............................4 + 3.1. Burst/Gap Loss Summary Statistics Block ....................4 + 3.1.1. Report Block Structure ..............................5 + 3.1.2. Definition of Fields in Loss Summary + Statistics Block ....................................5 + 3.2. Burst/Gap Discard Summary Statistics Block .................7 + 3.2.1. Report Block Structure ..............................8 + 3.2.2. Definition of Fields in Burst/Gap Discard + Summary Statistics Block ............................8 + 4. Application-Level Metrics ......................................10 + 4.1. Frame Impairment Statistics Summary Block .................10 + 4.1.1. Report Block Structure .............................11 + 4.1.2. Definition of Fields in Frame Impairment + Statistics Summary Block ...........................11 + 5. SDP Signaling ..................................................13 + 5.1. SDP rtcp-xr Attribute Extension ...........................13 + 5.2. Offer/Answer Usage ........................................13 + 6. IANA Considerations ............................................13 + 6.1. New RTCP XR Block Type Values .............................13 + 6.2. New RTCP XR SDP Parameters ................................14 + 6.3. Contact Information for Registrations .....................14 + 7. Security Considerations ........................................14 + 8. Acknowledgements ...............................................14 + 9. References .....................................................14 + 9.1. Normative References ......................................14 + 9.2. Informative References ....................................15 + Appendix A. Metrics Represented Using the Template from RFC 6390 .16 + + + + + + + + + + + + + + + + +Zorn, et al. Standards Track [Page 2] + +RFC 7004 Summary Stats XR Blocks September 2013 + + +1. Introduction + +1.1. Summary Statistics Metrics + + This document defines three new block types to augment those defined + in [RFC3611] for use in a range of RTP applications: + + o Burst/Gap Loss Summary Statistics Block + + o Burst/Gap Discard Summary Statistics Block + + o Frame Impairment Statistics Summary Block + + The first two block types support the reporting of burst/gap loss and + burst/gap discard summary statistics including packet loss/discard + proportion, mean, and variance and belong to the class of transport- + related end-system metrics defined in [RFC6792]. These two blocks + are intended to be used in conjunction with information from the + Burst/Gap Loss Metrics Block [RFC6958] or Burst/Gap Discard Metrics + Block [RFC7003], on which these two blocks therefore depend. The + metrics in the Burst/Gap Loss Metrics Block and Burst/Gap Discard + Metrics Block are consistent with the definitions of "burst", "gap", + "loss", and "discard" in RTCP XR [RFC3611]. + + The third block supports the reporting of detailed video statistics + for each frame type, including the number of frames received, lost, + and discarded of each frame type in the Group of Pictures (GOP) and + additional data allowing the calculation of statistical parameters + (e.g., the proportion of each frame type impaired by packet loss and + discard). The metrics defined in this block belong to the class of + application-level 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 + + The RTP Monitoring Framework [RFC6792] provides guidelines for + reporting block format using RTCP XR. Metrics described in this + document are in accordance with the guidelines in [RFC6792]. + + + + + + + +Zorn, et al. Standards Track [Page 3] + +RFC 7004 Summary Stats XR Blocks September 2013 + + +1.4. Applicability + + These metrics are applicable to a wide range of RTP applications and + reflect transient IP problems that affect user experience. They can + be used to form an accurate assessment of users' quality of + experience and influence sender strategies to mitigate the problem. + +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]. + + In addition, the following term is defined: + + Frame Type + + In many cases, a video frame is compressed using different + algorithms. Frame type is used to identify different algorithms + for video frames. Two frame types used in the different video + algorithms are the Key frame and Derived frames. The Key frame is + independently coded without prediction from other pictures and + used as a reference frame for predicting other pictures. Derived + frames are predicatively coded and derived from a Key frame using + a prediction algorithm. If there is no video image compression, + all frames are Key frames. + +3. Transport-Related End-System Metrics + +3.1. Burst/Gap Loss Summary Statistics Block + + This block extends packet loss and discard metrics defined in + Section 4.7.1 of [RFC3611]. The metrics described here are intended + to be used as described in this section, in conjunction with + information from the Measurement Information Block [RFC6776] (which + MUST be present in the same RTCP packet as the Burst/Gap Loss Metrics + Block [RFC6958]) and also with the metric "cumulative number of + packets lost" provided in standard RTCP [RFC3550]. Instances of this + metrics block use the synchronization source (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 period in the + Measurement Information Block indicating the span of the report and + SHOULD be sent in the same compound RTCP packet as the Measurement + Information Block. If the measurement period is not received in the + same compound RTCP packet as this metrics block, this metrics block + MUST be discarded. + + + + +Zorn, et al. Standards Track [Page 4] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + The metrics carried in this metrics block provide information + relevant to statistical parameters, including Burst Loss Rate, Gap + Loss Rate, Burst Duration Mean, and Burst Duration Variance, and are + measured at the receiving end of the RTP stream using burst/gap loss + metrics defined in [RFC6958] and other information that is sent + together with this report block. + +3.1.1. Report Block Structure + + The structure of the Burst/Gap Loss Summary Statistics 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=17 | I | Reserved | Block Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SSRC of Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Burst Loss Rate | Gap Loss Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Burst Duration Mean | Burst Duration Variance | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.1.2. Definition of Fields in Loss Summary Statistics Block + + Block Type (BT): 8 bits + + A Burst/Gap Loss Summary Statistics Block is identified by the + constant 17. + + Interval Metric flag (I): 2 bits + + This field is used to indicate whether the burst/gap loss summary + statistics metrics are Sampled, Interval, or Cumulative metrics: + + 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 value I=00 is the reserved value and MUST + NOT be used. + + + +Zorn, et al. Standards Track [Page 5] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + Reserved: 6 bits + + This field is reserved for future definition. In the absence of + such a definition, the bits in this field MUST be set to zero and + ignored by the receiver (see [RFC6709], Section 4.2). + + Block Length: 16 bits + + The constant 3, in accordance with the definition of this field in + Section 3 of RFC 3611 [RFC3611]. + + SSRC of Source: 32 bits + + As defined in Section 4.1 of RFC 3611 [RFC3611]. + + Burst Loss Rate: 16 bits + + The fraction of packets lost during bursts since the beginning of + reception, expressed as a fixed point number with the binary point + immediately after the left-most bit. This value is calculated by + dividing Packets Lost in Bursts by Total Packets Expected in + Bursts, multiplying the result of the division by 32768 (0x8000), + and keeping only the integer part. The maximum value is thus + 0x8000. Representing this as a formula: + + integer-part( (Packets Lost in Bursts / Total Packets Expected in + Bursts) * 0x8000 ) + + If the measurement is unavailable, the value 0xFFFF MUST be + reported. + + Gap Loss Rate: 16 bits + + The fraction of packets lost during gaps since the beginning of + reception expressed as a fixed point number with the binary point + immediately after the left-most bit. This value is calculated by + dividing the difference between number of packets lost and Packets + Lost in Bursts by the difference between Packets Expected and + Total Packets Expected in Bursts, multiplying the result of the + division by 32768 (0x8000), and keeping only the integer part. + The maximum value is thus 0x8000. Representing this as a formula: + + integer-part ( (number of packets lost - Packets Lost in Bursts)/ + (Packets Expected - Total Packets Expected in Bursts) * 0x8000 ) + + where "number of packets lost" is obtained from standard RTCP + [RFC3550] and Packets Expected is calculated as the difference + between "extended last sequence number" and "extended first + + + +Zorn, et al. Standards Track [Page 6] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + sequence number" (Interval or Cumulative) provided in the + Measurement Identity and Information Block [RFC6776]. + + If the measurement is unavailable, the value 0xFFFF MUST be + reported. + + Note that if the metric is to be calculated on an Interval basis, + a difference must be taken between the current and preceding + values of "cumulative number of packets lost" in RTCP to obtain + the "number of packets lost" for the reporting interval. + + Burst Duration Mean: 16 bits + + The mean burst duration is obtained as the quotient: + + mean = Sum of Burst Durations / Number of Bursts + + where "Sum of Burst Durations" and "Number of Bursts" is obtained + from the RTCP XR Burst/Gap Loss Metrics Block [RFC6958]. + + If the measurement is unavailable, the value 0xFFFF MUST be + reported. + + Burst Duration Variance: 16 bits + + The variance of the burst duration is obtained using the standard + result: + + var = ( Sum of Squares of Burst Durations - Number of Bursts * + mean^2 ) / (Number of Bursts - 1) + + where "Sum of Squares of Burst Durations" and "Number of Bursts" + is obtained from the RTCP XR Burst/Gap Loss Metrics Block + [RFC6958]. + + If the measurement is unavailable, the value 0xFFFF MUST be + reported. + +3.2. Burst/Gap Discard Summary Statistics Block + + This block extends packet loss and discard metrics defined in + Section 4.7.1 of [RFC3611]. The metrics described here are intended + to be used as described in this section, in conjunction with + information from the Measurement Identity Block [RFC6776] (which MUST + be present in the same RTCP packet as the Burst/Gap Discard Summary + Statistics Block). + + + + + +Zorn, et al. Standards Track [Page 7] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + These metrics provide information relevant to statistical parameters, + including Burst Discard Rate and Gap Discard Rate, and are measured + at the receiving end of the RTP stream using burst/gap discard + metrics defined in [RFC7003] and other information that is sent + together with this report block. + + Instances of this metrics block use the synchronization source (SSRC) + to refer to the separate auxiliary Measurement Information block + [RFC6776] that describes measurement periods in use (see [RFC6776], + Section 4.2). This metrics block relies on the measurement period in + the Measurement Information Block indicating the span of the report + and SHOULD be sent in the same compound RTCP packet as the + measurement information block. If the measurement period is not + received in the same compound RTCP packet as this metrics block, this + metrics block MUST be discarded. + +3.2.1. Report Block Structure + + The structure of the Burst/Gap Discard Summary Statistics 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=18 | I | Reserved | Block Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SSRC of Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Burst Discard Rate | Gap Discard Rate | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.2.2. Definition of Fields in Burst/Gap Discard Summary Statistics + Block + + Block Type (BT): 8 bits + + A Burst/Gap Discard Summary Statistics Block is identified by the + constant 18. + + Interval Metric flag (I): 2 bits + + This field is used to indicate whether the burst/gap discard + summary statistics metrics are Sampled, Interval, or Cumulative + metrics: + + I=10: Interval Duration - the reported value applies to the + most recent measurement interval duration between successive + metrics reports. + + + +Zorn, et al. Standards Track [Page 8] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + 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 value I=00 is the reserved value and MUST + NOT be used. + + Reserved: 6 bits + + This field is reserved for future definition. In the absence of + such a definition, the bits in this field MUST be set to zero and + ignored by the receiver (see [RFC6709], Section 4.2). + + Block Length: 16 bits + + The constant 2, in accordance with the definition of this field in + Section 3 of RFC 3611 [RFC3611]. + + SSRC of Source: 32 bits + + As defined in Section 4.1 of RFC3611 [RFC3611]. + + Burst Discard Rate: 16 bits + + The fraction of packets discarded during bursts since the + beginning of reception, expressed as a fixed point number with the + binary point immediately after the left-most bit. This value is + calculated by dividing Packets Discarded in Bursts by Total + Packets Expected in Bursts, multiplying the result of the division + by 32768 (0x8000), and keeping only the integer part, according to + the formula: + + integer-part( (Packets Discarded in Bursts / Total Packets + Expected in Bursts) * 0x8000 ) + + If the measurement is unavailable, the value 0xFFFF MUST be + reported. + + Gap Discard Rate: 16 bits + + The fraction of packets discarded during gaps since the beginning + of reception expressed as a fixed point number with the binary + point immediately after the left-most bit. This value is + calculated by dividing the difference between number of packets + discarded and Packets Discarded in Bursts by the difference + between Packets Expected and Total Packets Expected in Bursts, + + + +Zorn, et al. Standards Track [Page 9] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + multiplying the result of the division by 32768 (0x8000), and + keeping only the integer part. The maximum value is thus 0x8000. + Representing this as a formula: + + integer-part( (number of packets discarded - Packets Discarded in + Bursts) /(Packets Expected - Total Packets Expected in Bursts) * + 0x8000 ) + + where "number of packets discarded" is obtained from the RTCP XR + Discard Count Block [RFC7002] and filled with the sum of packets + discarded due to early arrival (DT=1) and packets discarded due to + late arrival (DT=2) and Packets Expected is calculated as the + difference between "extended last sequence number" and "extended + first sequence number" (Interval or Cumulative) provided in the + Measurement Information Block [RFC6776]. In order for the Burst/ + Gap Discard Summary Statistics Block to be meaningful, 2 instances + of the Discard Count Block with DT=1 and DT=2 MUST be included in + the same RTCP XR packet as the Burst/Gap Discard Summary + Statistics Block. + + If the measurement is unavailable, the value 0xFFFF MUST be + reported. + +4. Application-Level Metrics + +4.1. Frame Impairment Statistics Summary Block + + This block extends the statistics summary report mechanism defined in + Section 4.6 of [RFC3611] and reports statistics on which frame types + were affected beyond the information carried in the Statistics + Summary Report Block RTCP packet specified in Section 4.6 of + [RFC3611]. Information is measured at the receiving end of the RTP + stream and recorded about the number of frames received, lost frames, + duplicated frames, and lost partial frames. Such information can be + useful for network management and video quality monitoring. + + + + + + + + + + + + + + + + +Zorn, et al. Standards Track [Page 10] + +RFC 7004 Summary Stats XR Blocks September 2013 + + +4.1.1. Report Block Structure + + The structure of the Frame Impairment Statistics Summary 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=19 |T| Reserved | Block Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SSRC of Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | begin_seq | end_seq | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | discarded_frames | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | dup_frames | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | full_lost_frames | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | partial_lost_frames | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1.2. Definition of Fields in Frame Impairment Statistics Summary + Block + + Block Type (BT): 8 bits + + A Frame Impairment Statistics Summary Block is identified by the + constant 19. + + Frame type indicator (T): 1 bit + + This field is used to indicate the frame type to be reported. The + bit is set to 0 if the full_lost_frames, partial_lost_frames, + dup_frames, and discarded_frames fields contain Key frame + (reference frame) counts or 1 if they contain Derived frame + counts. Note that if both the Key frame and Derivation frame + report are sent, they should be sent in the same RTCP compound + packet using two Frame Impairment Statistics Summary Blocks. + + Reserved: 7 bits + + This field is reserved for future definition. In the absence of + such a definition, the bits in this field MUST be set to zero and + ignored by the receiver (see [RFC6709], Section 4.2). + + + + + +Zorn, et al. Standards Track [Page 11] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + Block Length: 16 bits + + The constant 6, in accordance with the definition of this field in + Section 3 of RFC 3611 [RFC3611]. + + SSRC of Source: 32 bits + + As defined in Section 4.1 of RFC 3611 [RFC3611]. + + begin_seq: 16 bits + + As defined in Section 4.1 of RFC 3611 [RFC3611]. + + end_seq: 16 bits + + As defined in Section 4.1 of RFC 3611 [RFC3611]. + + Number of discarded frames (discarded_frames): 32 bits + + Number of frames discarded in the above sequence number interval. + + Number of duplicate frames (dup_frames): 32 bits + + Number of duplicate frames received in the above sequence number + interval. + + Number of full lost frames (full_lost_frames): 32 bits + + A frame is either split across multiple packets or carried in only + one packet. If the whole frame or all the packets of the frame + are lost, this frame is regarded as one full_lost_frame. The + full_lost_frames can be inferred from packet(s) that comprise the + frame. The full_lost_frames is equivalent to the number of full + lost frames in the above sequence number interval. + + Number of partial lost frames (partial_lost_frames): 32 bits + + When a frame is split across multiple packets and some packets of + the frame are lost, this frame is regarded as one + partial_lost_frame. The partial_lost_frames can be inferred from + packets that comprise the frame. The value of the + partial_lost_frames field is equivalent to the number of partial + lost frames in the above sequence number interval. + + + + + + + + +Zorn, et al. Standards Track [Page 12] + +RFC 7004 Summary Stats XR Blocks September 2013 + + +5. SDP Signaling + + RFC 3611 defines the use of SDP (Session Description Protocol) + [RFC4566] for signaling the use of XR blocks. However, XR blocks MAY + be used without prior signaling (see Section 5 of [RFC3611]). + +5.1. SDP rtcp-xr Attribute Extension + + This section augments the SDP [RFC4566] attribute "rtcp-xr" defined + in Section 5.1 of [RFC3611] by providing three additional values 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-bglss-block + / xr-bgdss-block + / xr-fiss-block + xr-bglss-block = "burst-gap-loss-stat" + xr-bgdss-block = "burst-gap-discard-stat" + xr-fiss-block = "frame-impairment-stat" + +5.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 + parameter, refer to section 5.2 of [RFC3611]. + +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 RFC + 3611. + +6.1. New RTCP XR Block Type Values + + This document assigns three new block type values in the "RTP Control + Protocol Extended Reports (RTCP XR) Block Type Registry": + + Name: BGLSS + Long Name: Burst/Gap Loss Summary Statistics Block + Value 17 + Reference: Section 3.1 + + Name: BGDSS + Long Name: Burst/Gap Discard Summary Statistics Block + Value 18 + Reference: Section 3.2 + + + + +Zorn, et al. Standards Track [Page 13] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + Name: FISS + Long Name: Frame Impairment Statistics Summary Block + Value 19 + Reference: Section 4.1 + +6.2. New RTCP XR SDP Parameters + + This document also registers three new SDP [RFC4566] parameters for + the "rtcp-xr" attribute in the "RTP Control Protocol Extended Reports + (RTCP XR) Session Description Protocol (SDP) Parameters Registry": + + * "burst-gap-loss-stat" + * "burst-gap-discard-stat" + * "frame-impairment-stat" + +6.3. Contact Information for Registrations + + The contact information for the registrations is: + + Qin Wu (sunseawq@huawei.com) + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + +7. Security Considerations + + The new RTCP XR blocks in this document do not introduce any new + security considerations beyond those described in [RFC3611]. + +8. Acknowledgements + + The authors would like to thank Bill Ver Steeg, David R. Oran, Ali + Begen, Colin Perkins, Roni Even, Youqing Yang, Wenxiao Yu, Yinliang + Hu, Jing Zhao, Ray van Brandenburg, Claire Bi, Dan Romascanu, Alfred + Morton, Jr., Klaas Wierenga, Barry Leiba, Robert Sparks, Ralph Droms, + and Benoit Claise for their valuable comments and suggestions on this + document. + +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. + + + +Zorn, et al. Standards Track [Page 14] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + [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. + + [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. + + [RFC6958] Clark, A., Zhang, S., Zhao, J., and Q. Wu, "RTP Control + Protocol (RTCP) Extended Report (XR) Block for Burst/Gap + Loss Metric Reporting", RFC 6958, May 2013. + + [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol + (RTCP) Extended Report (XR) Block for Discard Count Metric + Reporting", RFC 7002, September 2013. + + [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. + +9.2. Informative References + + [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New + Performance Metric Development", BCP 170, RFC 6390, + October 2011. + + [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, + September 2012. + + [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the + RTP Monitoring Framework", RFC 6792, November 2012. + + + + + + + + + + + + + +Zorn, et al. Standards Track [Page 15] + +RFC 7004 Summary Stats XR Blocks September 2013 + + +Appendix A. Metrics Represented Using the Template from RFC 6390 + + a. Burst Loss Rate Metric + + * Metric Name: RTP Burst Loss Rate + + * Metric Description: The fraction of packets lost during bursts + since the beginning of reception for RTP traffic. + + * Method of Measurement or Calculation: See Section 3.1.2, Burst + Loss Rate definition. + + * Units of Measurement: See Section 3.1.2, Burst Loss Rate + definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3.1, 2nd paragraph. + + * Measurement Timing: See Section 3.1, 1st paragraph for + measurement timing and Section 3.1.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + b. Gap Loss Rate Metric + + * Metric Name: RTP Gap Loss Rate + + * Metric Description: The fraction of packets lost during gaps + since the beginning of reception for RTP traffic. + + * Method of Measurement or Calculation: See Section 3.1.2, Gap + Loss Rate definition. + + * Units of Measurement: See Section 3.1.2, Gap Loss Rate + definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3.1, 2nd paragraph. + + * Measurement Timing: See Section 3.1, 1st paragraph for + measurement timing and Section 3.1.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + + + +Zorn, et al. Standards Track [Page 16] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + c. Burst Duration Mean Metric + + * Metric Name: RTP Burst Duration Mean + + * Metric Description: The mean duration of the burst periods + that have occurred since the beginning of reception for RTP + traffic. + + * Method of Measurement or Calculation: See Section 3.1.2, Burst + Loss Rate definition. + + * Units of Measurement: This metric is expressed in + milliseconds. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3.1, 2nd paragraph. + + * Measurement Timing: See Section 3.1, 1st paragraph for + measurement timing and Section 3.1.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + d. Burst Duration Variance Metric + + * Metric Name: RTP Burst Duration Variance + + * Metric Description: The variance duration of the burst periods + that have occurred since the beginning of reception for RTP + traffic. + + * Method of Measurement or Calculation: See Section 3.1.2, Burst + Duration Variance definition. + + * Units of Measurement: See Section 3.1.2, Burst Duration + Variance definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3.1, 2nd paragraph. + + * Measurement Timing: See Section 3.1, 1st paragraph for + measurement timing and Section 3.1.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + + + +Zorn, et al. Standards Track [Page 17] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + e. Burst Discard Rate Metric + + * Metric Name: RTP Burst Discard Rate + + * Metric Description: The fraction of packets discarded during + bursts since the beginning of reception for RTP traffic. + + * Method of Measurement or Calculation: See Section 3.2.2, Burst + Discard Rate definition. + + * Units of Measurement: See Section 3.2.2, Burst Discard Rate + definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3.2, 2nd paragraph. + + * Measurement Timing: See Section 3.2, 3rd paragraph for + measurement timing and Section 3.1.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + f. Gap Discard Rate Metric + + * Metric Name: RTP Gap Discard Rate + + * Metric Description: The fraction of packets discarded during + gaps since the beginning of reception for RTP traffic. + + * Method of Measurement or Calculation: See Section 3.2.2, Gap + Discard Rate definition. + + * Units of Measurement: See Section 3.2.2, Gap Discard Rate + definition. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 3.2, 2nd paragraph. + + * Measurement Timing: See Section 3.2, 3rd paragraph for + measurement timing and Section 3.1.2 for Interval Metric flag. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + + + + + +Zorn, et al. Standards Track [Page 18] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + g. Number of Discarded Frames Metric + + * Metric Name: Number of discarded frames in RTP + + * Metric Description: Number of frames discarded in a certain + sequence number interval for RTP traffic. + + * Method of Measurement or Calculation: See Section 4.1.2, + Number of discarded frames definition. This metric is + directly measured and can be inferred from packet(s) that + comprise the frame. + + * Units of Measurement: This metric is expressed as a 32-bit + unsigned integer value. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4.1, 1st paragraph. + + * Measurement Timing: See Section 4.1, Number of discarded + frames definition. This metric relies on the sequence number + interval and RTCP RR packet of [RFC3550] to determine + measurement timing. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + h. Number of Duplicate Frames Metric + + * Metric Name: Number of duplicate frames in RTP + + * Metric Description: Number of frames duplicated in a certain + sequence number interval for RTP traffic. + + * Method of Measurement or Calculation: See Section 4.1.2, + Number of duplicate frames definition. This metric is + directly measured and can be inferred from packet(s) that + comprise the frame. + + * Units of Measurement: This metric is expressed as a 32-bit + unsigned integer value. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4.1, 1st paragraph. + + * Measurement Timing: See Section 4.1, Number of duplicate + frames definition. This metric relies on the sequence number + interval to determine measurement timing. + + + +Zorn, et al. Standards Track [Page 19] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + i. Number of Full Lost Frames Metric + + * Metric Name: Number of full lost frames in RTP + + * Metric Description: A frame is either split across multiple + RTP packets or carried in only one RTP packet. If the whole + frame or all the packets of the frame is lost, this frame is + regarded as one full_lost_frame. + + * Method of Measurement or Calculation: See Section 4.1.2, + Number of full lost frames definition. + + * Units of Measurement: This metric is expressed as a 32-bit + unsigned integer value. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4.1, 1st paragraph. + + * Measurement Timing: See Section 4.1, Number of full lost + frames definition. This metric relies on the sequence number + interval to determine measurement timing. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + + j. Number of Partial Lost Frames Metric + + * Metric Name: Number of partial lost frames in RTP + + * Metric Description: When a frame is split across multiple RTP + packets and some RTP packets of the frame are lost, this frame + is regarded as one partial_lost_frame. + + * Method of Measurement or Calculation: See Section 4.1.2, + Number of partial lost frames definition. + + * Units of Measurement: This metric is expressed as a 32-bit + unsigned integer value. + + * Measurement Point(s) with Potential Measurement Domain: See + Section 4.1, 1st paragraph. + + + + + +Zorn, et al. Standards Track [Page 20] + +RFC 7004 Summary Stats XR Blocks September 2013 + + + * Measurement Timing: See Section 4.1, Number of partial lost + frames definition. This metric relies on the sequence number + interval to determine measurement timing. + + * Use and Applications: See Section 1.4. + + * Reporting Model: See RFC 3611. + +Authors' Addresses + + Glen Zorn + Network Zen + 227/358 Thanon Sanphawut + Bang Na, Bangkok 10260 + Thailand + + Phone: +66 (0) 909-201060 + EMail: glenzorn@gmail.com + + + Roland Schott + Deutsche Telekom + Deutsche-Telekom-Allee 7 + Darmstadt 64295 + Germany + + EMail: Roland.Schott@telekom.de + + + Qin Wu (editor) + Huawei + 101 Software Avenue, Yuhua District + Nanjing, Jiangsu 210012 + China + + EMail: sunseawq@huawei.com + + + Rachel Huang + Huawei + 101 Software Avenue, Yuhua District + Nanjing 210012 + China + + EMail: Rachel@huawei.com + + + + + + +Zorn, et al. Standards Track [Page 21] + |