From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7509.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc7509.txt (limited to 'doc/rfc/rfc7509.txt') diff --git a/doc/rfc/rfc7509.txt b/doc/rfc/rfc7509.txt new file mode 100644 index 0000000..29c725d --- /dev/null +++ b/doc/rfc/rfc7509.txt @@ -0,0 +1,619 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Huang +Request for Comments: 7509 Huawei +Category: Standards Track V. Singh +ISSN: 2070-1721 Aalto University + May 2015 + + + RTP Control Protocol (RTCP) Extended Report (XR) + for Post-Repair Loss Count Metrics + +Abstract + + This document defines an RTP Control Protocol (RTCP) Extended Report + (XR) block that allows reporting of a post-repair loss count metric + for a range of RTP applications. In addition, another metric, + repaired loss count, is also introduced in this report block for + calculating the pre-repair loss count when needed, so that the RTP + sender or a third-party entity is able to evaluate the effectiveness + of the repair methods used by the system. + +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/rfc7509. + +Copyright Notice + + Copyright (c) 2015 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. + + + +Singh & Huang Standards Track [Page 1] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................3 + 3. Post-Repair Loss Count Metrics Report Block .....................3 + 3.1. Report Block Structure .....................................4 + 3.2. Example Usage ..............................................5 + 4. SDP Signaling ...................................................6 + 4.1. SDP rtcp-xr-attrib Attribute Extension .....................6 + 4.2. Offer/Answer Usage .........................................7 + 5. Security Considerations .........................................7 + 6. IANA Considerations .............................................7 + 6.1. New RTCP XR Block Type Value ...............................7 + 6.2. New RTCP XR SDP Parameter ..................................7 + 6.3. Contact Information for Registrations ......................7 + 7. References ......................................................8 + 7.1. Normative References .......................................8 + 7.2. Informative References .....................................9 + Appendix A. Metrics Represented Using the Template from RFC 6390 ..10 + Acknowledgments ...................................................11 + Authors' Addresses ................................................11 + +1. Introduction + + RTCP Sender Reports (SRs) / Receiver Reports (RRs) [RFC3550] contain + some rough statistics about the data received from the particular + source indicated in that block. One of them is the cumulative number + of packets lost, which is called the pre-repair loss metric in this + document. This metric conveys information regarding the total number + of RTP data packets that have been lost since the beginning of the + RTP session. + + However, this metric is measured on the media stream before any loss- + repair mechanism, e.g., retransmission [RFC4588] or Forward Error + Correction (FEC) [RFC5109], is applied. Using a repair mechanism + usually results in recovering some or all of the lost packets. The + recovery process does not reduce the values reported by the two loss + metrics in RTCP RR [RFC3550] -- namely, the fraction lost and the + cumulative loss. Hence, the sending endpoint cannot infer the + performance of the repair mechanism based on the aforementioned + metrics in [RFC3550]. + + Consequently, [RFC5725] specifies a post-repair loss Run-Length + Encoding (RLE) XR report block to address this issue. The sending + endpoint is able to infer which packets were repaired from the RLE + report block, but the reporting overhead for the packet-by-packet + report block is higher compared to other report blocks. + + + + +Singh & Huang Standards Track [Page 2] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + + When applications use multiple XR blocks, the endpoints may require + more concise reporting to save bandwidth. This document defines a + new XR block type to augment those defined in [RFC3611] and + complement the report block defined in [RFC5725] for use in a range + of RTP applications. This new block type reports the post-repair + loss count metric, which records the number of primary source RTP + packets that are still lost after applying one or more loss-repair + mechanisms. In addition, another metric, repaired loss count, is + also introduced in this report block for calculating the pre-repair + loss count during this range, so that the RTP sender or a third-party + entity is able to evaluate the effectiveness of the repair methods + used by the system. The metrics defined in this document are packet + level rather than slice/picture level; this means the partial + recovery of a packet will not be regarded as a repaired packet. + + The metrics defined in this document belong to the class of + transport-related metrics defined in [RFC6792] and are specified in + accordance with the guidelines in [RFC6390] and [RFC6792]. These + metrics are applicable to any RTP application, especially those that + use loss-repair mechanisms. + +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 [KEYWORDS]. + + primary source RTP packet: The original RTP packet sent from the RTP + sender for the first time. A lost primary source RTP packet may + be repaired by some other RTP packets used in repair mechanisms + like FEC or retransmission. + +3. Post-Repair Loss Count Metrics Report Block + + This block reports the number of packets lost after applying repair + mechanisms (e.g., FEC). It complements the RTCP XR metrics defined + in [RFC5725]. As noted in [RFC5725], ambiguity may occur when + comparing this metric with a pre-repair loss metric reported in an + RTCP SR/RR, i.e., some packets were not repaired in the current RTCP + interval, but they may be repaired later. Therefore, this block uses + a begin sequence number and an end sequence number to explicitly + indicate the actual sequence number range reported by this RTCP XR. + Accordingly, only packets that have no further chance of being + repaired and that have been repaired are included in this report + block. + + + + + + +Singh & Huang Standards Track [Page 3] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + +3.1. Report Block Structure + + The Post-Repair Loss Count Metrics Report Block has the following + format: + + 0 1 2 3 4 + 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | BT=33 | Reserved | Block length = 4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SSRC of Source | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | begin_seq | end_seq | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Post-repair loss count | Repaired loss count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Block Type (BT): 8 bits + + A Post-Repair Loss Count Metrics Report Block is identified by the + constant 33. + + Reserved: 8 bits + + These bits are reserved for future use. They MUST be set to zero + by senders and ignored by receivers (see Section 4.2 of + [RFC6709]). + + Block length: 16 bits + + This field is in accordance with the definition in [RFC3611]. In + this report block, it MUST be set to 4. 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]. + + begin_seq: 16 bits + + The first sequence number that this block reports on. It can + remain fixed when calculating metrics over several RTCP reporting + intervals. + + end_seq: 16 bits + + The last sequence number that this block reports on plus one. + + + + +Singh & Huang Standards Track [Page 4] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + + Post-repair loss count: 16 bits + + Total number of packets finally lost after applying one or more + loss-repair methods, e.g., FEC and/or retransmission, during the + actual sequence number range indicated by begin_seq and end_seq. + This metric MUST NOT count the lost packets for which repair might + still be possible. Note that this metric MUST measure only + primary source RTP packets. + + Repaired loss count: 16 bits + + Total number of packets fully repaired after applying one or more + loss-repair methods, e.g., FEC and/or retransmission, during the + actual sequence number range indicated by begin_seq and end_seq. + Note that this metric MUST measure only primary source RTP + packets. + +3.2 Example Usage + + The metrics defined in this report block are all measured at the RTP + receiver. However, the receiving endpoint can report the metrics in + two different ways: + + 1) Cumulative report + + In this case, implementations may set begin_seq to the first packet + in the RTP session, and it will remain fixed across all reports. + Hence, the "Post-repair loss count" and "Repaired loss count", + respectively, will correspond to "Cumulative post-repair loss count" + and "Cumulative repaired loss count" in this case. These cumulative + metrics when combined with the cumulative loss metrics reported in an + RTCP RR (pre-repair) assist in calculating the "Still-to-be-repaired + lost packets": + + Still-to-be-repaired lost packets = + Cumulative number of packets lost - + Cumulative post-repair loss count - + Cumulative repaired loss count + + 2) Interval report + + Some implementations may align the begin_seq and end_seq number with + the highest sequence numbers of consecutive RTCP RRs (RTCP interval). + This is NOT RECOMMENDED as packets that are not yet repaired in this + current RTCP interval and may be repaired in the subsequent intervals + will not be reported. An interval report is illustrated in the + following example: + + + + +Singh & Huang Standards Track [Page 5] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + + Interval A: The extended highest sequence number received in RTCP + RR is 20. Begin_seq is 10 and end_seq is 20. + + Interval B: The extended highest sequence number received in RTCP + RR is 30. Begin_seq is 20 and end_seq is 30. + + If packets 17 and 19 are lost and not yet repaired in interval A and + subsequently repaired in interval B, they will not be reported + because their sequence numbers do not belong in interval B. + Therefore, if implementations want these packets to be reported as + repaired, they MUST NOT align the begin_seq and end_seq to the RTCP + intervals. + + Alternatively, implementations may choose the begin_seq and end_seq + numbers that cover several RTCP intervals. Additionally, the + reported range of sequence numbers may overlap with the previous + report blocks, so that the packets that were not yet repaired in one + interval, but were subsequently repaired or deemed unrepairable, were + reported in subsequent intervals. + + In this case, the "Cumulative number of packets lost" cannot be + easily compared with the post-repair metrics. However, the sending + endpoint can calculate the efficiency of the error resilience + algorithm using the post-repair and repaired loss count, + respectively. + +4. SDP Signaling + + [RFC3611] defines the use of SDP (Session Description Protocol) for + signaling the use of RTCP XR blocks. However, XR blocks MAY be used + without prior signaling (see Section 5 of [RFC3611]). + +4.1. SDP rtcp-xr-attrib Attribute Extension + + This session augments the SDP attribute "rtcp-xr" defined in Section + 5.1 of [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-prlr-block + + xr-prlr-block = "post-repair-loss-count" + + + + + + + + + +Singh & Huang Standards Track [Page 6] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + +4.2. Offer/Answer Usage + + When SDP is used in offer/answer context, the SDP Offer/Answer usage + defined in [RFC3611] for the unilateral "rtcp-xr" attribute + parameters applies. For detailed usage of Offer/Answer for + unilateral parameters, refer to Section 5.2 of [RFC3611]. + +5. Security Considerations + + This proposed 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. + + An attacker may put incorrect information in the Post-Repair Loss + Count reports, which will affect the performance of loss-repair + mechanisms. Implementers should consider the guidance in [RFC7202] + for using appropriate security mechanisms, i.e., where security is a + concern, the implementation should apply encryption and + authentication to the report block. For example, this can be + achieved by using the AVPF profile together with the Secure RTP + profile as defined in [RFC3711]; an appropriate combination of the + two profiles (an "SAVPF") is specified in [RFC5124]. However, other + mechanisms also exist (documented in [RFC7201]) and might be more + suitable. + +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]. + +6.1. New RTCP XR Block Type Value + + This document assigns the block type value 33 in the IANA "RTP + Control Protocol Extended Reports (RTCP XR) Block Type Registry" to + the "Post-Repair Loss Count Metrics Report Block". + +6.2. New RTCP XR SDP Parameter + + This document also registers a new parameter "post-repair-loss-count" + in the "RTP Control Protocol Extended Reports (RTCP XR) Session + Description Protocol (SDP) Parameters Registry". + +6.3. Contact Information for Registrations + + The contact information for the registrations is: + RAI Area Directors + + + +Singh & Huang Standards Track [Page 7] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + +7. References + +7.1. Normative References + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, + July 2003, . + + [RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., + "RTP Control Protocol Extended Reports (RTCP XR)", + RFC 3611, DOI 10.17487/RFC3611, November 2003, + . + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, DOI 10.17487/RFC3711, March 2004, + . + + [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for + Real-time Transport Control Protocol (RTCP)-Based Feedback + (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February + 2008, . + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + . + + [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, DOI 10.17487/RFC5725, February + 2010, . + + + + + + + + + + + + + +Singh & Huang Standards Track [Page 8] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + +7.2. Informative References + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + DOI 10.17487/RFC4588, July 2006, + . + + [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error + Correction", RFC 5109, DOI 10.17487/RFC5109, December + 2007, . + + [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New + Performance Metric Development", BCP 170, RFC 6390, + DOI 10.17487/RFC6390, October 2011, + . + + [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, DOI + 10.17487/RFC6709, September 2012, + . + + [RFC6792] Wu, Q., Ed., Hunt, G., and P. Arden, "Guidelines for Use + of the RTP Monitoring Framework", RFC 6792, + DOI 10.17487/RFC6792, November 2012, + . + + [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP + Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, + . + + [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP + Framework: Why RTP Does Not Mandate a Single Media + Security Solution", RFC 7202, DOI 10.17487/RFC7202, April + 2014, . + + + + + + + + + + + + + + + + + +Singh & Huang Standards Track [Page 9] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + +Appendix A. Metrics Represented Using the Template from RFC 6390 + + a. Post-Repair RTP Packet Loss Count Metric + + * Metric Name: Post-Repair RTP Packet Loss Count Metric. + + * Metric Description: Total number of RTP packets still lost + after loss-repair methods are applied. + + * Method of Measurement or Calculation: See the "Post-repair + loss count" definition in Section 3.1. It is directly + measured and must be measured for the primary source RTP + packets with no further chance of repair. + + * Units of Measurement: This metric is expressed as a 16-bit + unsigned integer value giving the number of RTP packets. + + * Measurement Point(s) with Potential Measurement Domain: It is + measured at the receiving end of the RTP stream. + + * Measurement Timing: This metric relies on the sequence number + interval to determine measurement timing. See the Cumulative + and Interval reports defined in Section 3.2. + + * Use and Applications: These metrics are applicable to any RTP + application, especially those that use loss-repair mechanisms. + See Section 1 for details. + + * Reporting Model: See RFC 3611. + + b. Repaired RTP Packet Loss Count Metric + + * Metric Name: Repaired RTP Packet Count Metric. + + * Metric Description: The number of RTP packets lost but + repaired after applying loss-repair methods. + + * Method of Measurement or Calculation: See the "Repaired loss + count" in Section 3.1. It is directly measured and must be + measured for the primary source RTP packets with no further + chance of repair. + + * Units of Measurement: This metric is expressed as a 16-bit + unsigned integer value giving the number of RTP packets. + + * Measurement Point(s) with Potential Measurement Domain: It is + measured at the receiving end of the RTP stream. + + + + +Singh & Huang Standards Track [Page 10] + +RFC 7509 Post-Repair Non-RLE Loss Count May 2015 + + + * Measurement Timing: This metric relies on the sequence number + interval to determine measurement timing. See the Cumulative + and Interval reports defined in Section 3.2. + + * Use and Applications: These metrics are applicable to any RTP + application, especially those that use loss-repair mechanisms. + See Section 1 for details. + + * Reporting Model: See RFC 3611. + +Acknowledgments + + The authors would like to thank Roni Even, Colin Perkins, and Qin Wu + for giving valuable comments and suggestions. + +Authors' Addresses + + Rachel Huang + Huawei + 101 Software Avenue, Yuhua District + Nanjing 210012 + China + + EMail: rachel.huang@huawei.com + + + Varun Singh + Aalto University + School of Electrical Engineering + Otakaari 5 A + Espoo, FIN 02150 + Finland + + EMail: varun@comnet.tkk.fi + URI: http://www.netlab.tkk.fi/~varun/ + + + + + + + + + + + + + + + + +Singh & Huang Standards Track [Page 11] + -- cgit v1.2.3