doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

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 <rai-ads@ietf.org>
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [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, <http://www.rfc-editor.org/info/rfc3550>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3611>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc3711>.
+
+   [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, <http://www.rfc-editor.org/info/rfc5124>.
+
+   [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
+              Syntax Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [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, <http://www.rfc-editor.org/info/rfc5725>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+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,
+              <http://www.rfc-editor.org/info/rfc4588>.
+
+   [RFC5109]  Li, A., Ed., "RTP Payload Format for Generic Forward Error
+              Correction", RFC 5109, DOI 10.17487/RFC5109, December
+              2007, <http://www.rfc-editor.org/info/rfc5109>.
+
+   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
+              Performance Metric Development", BCP 170, RFC 6390,
+              DOI 10.17487/RFC6390, October 2011,
+              <http://www.rfc-editor.org/info/rfc6390>.
+
+   [RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
+              Considerations for Protocol Extensions", RFC 6709, DOI
+              10.17487/RFC6709, September 2012,
+              <http://www.rfc-editor.org/info/rfc6709>.
+
+   [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,
+              <http://www.rfc-editor.org/info/rfc6792>.
+
+   [RFC7201]  Westerlund, M. and C. Perkins, "Options for Securing RTP
+              Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
+              <http://www.rfc-editor.org/info/rfc7201>.
+
+   [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, <http://www.rfc-editor.org/info/rfc7202>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+