Internet DRAFT - draft-zheng-xr-effective-loss-index
draft-zheng-xr-effective-loss-index
Network Working Group H. Zheng
Internet-Draft R. Even
Intended status: Informational Huawei
Expires: May 3, 2018 October 30, 2017
RTP Control Protocol (RTCP) Extended Report (XR) Block for Effective
Loss Index Reporting
draft-zheng-xr-effective-loss-index-00
Abstract
This document defines a new metric for RTP applications to measure
the effectiveness of stream repair means, and an RTP Control Protocol
(RTCP) Extended Report (XR) Block to report the metric.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 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.
Zheng & Even Expires May 3, 2018 [Page 1]
Internet-Draft RTCP XR Effective Loss Index October 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Effective Loss Index . . . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.3. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . 4
1.4. Performance Metrics Framework . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Effective Loss Index Report Block . . . . . . . . . . . . . . 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 . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Appendix A. Metric Represented Using the Template from RFC 6390 10
A.1. Effective Loss Index . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
RTP applications often use stream repair means, e.g. FEC (Forward
Error Correction) [RFC5109] and/or retransmission [RFC4588] to
improve the robustness of media streams. With the presence of those
stream repair means, a degree of packet loss can be recovered for a
media stream. In the past, some RTCP Extend Reports (XRs) were
defined to reflect the situation of post-repair loss. For example,
[RFC5725] defines an XR block using Run Length Encoding (RLE) to
report post-repair loss; [RFC7509] defines count metrics for post-
repair loss.
This document proposes a new metric Effective Loss Index (ELI) to
measure the effectiveness of stream repair means. The new metric
provides a simpler view on the post-repair loss than the mechanisms
documented in [RFC5725] and [RFC7509]. EFI is an index, so the
values reported from different RTP sources can be compared directly,
which makes it easier to rank the effectiveness of loss repair means.
An example use case is to find endpoints whose ELI values are at
bottom 10%. For those endpoints, more informative XR reports such as
those in [RFC5725] and [RFC7509] can then be used to discover more
details about the loss situations.
Zheng & Even Expires May 3, 2018 [Page 2]
Internet-Draft RTCP XR Effective Loss Index October 2017
This document also defines an XR block to report the metric, which
can be found out in Section 3.
1.1. Effective Loss Index
Effective Loss Index (ELI) uses a simple model to measure the
effectiveness of loss repair. The model assumes that repair means
are applied onto packets by batches of equal size. Lower ELI means
that the repair was more successful. Specifically, a batch is
identified by a range of RTP sequence numbers. The size of a batch
is number of packets. An application can agree upon a default batch
size, or use the SDP signaling defined in Section 4.1 to communicate
one.
An RTP endpoint is thought to process received packets and apply
repair means batch by batch. For each batch, if there is still some
unrecoverable loss after having applied the repair means, then the
repair means are deemed as ineffective. The ineffectiveness is
denoted by Effective Loss Factor (ELF), along with a parameter
Effective Loss Threshold, showing below:
if Post-Repair Loss > Effective Loss Threshold
Effective Loss Factor = 1
else
Effective Loss Factor = 0
endif
Figure 1: Calculation of Effective Loss Factor
The parameters in Figure 1 are explained below:
o Post-Repair Loss is the number of packet lost after repair in the
batch.
o Effective Loss Threshold is in number of packets.
The minimum value of Effective Loss Threshold is zero. This document
does not mandate any value for Effective Loss Threshold.
Applications can prescribe a value for themselves without signaling.
On the other hand, SDP signaling defined in Section 4.1 can be used
to communicate the value. Determining an Effective Loss Threshold
value for use can be empirical, applications may have to try out and
change the value from time to time, depending on their needs.
Effective Loss Index is an integer derived by calculating the average
Effective Loss Factor across a sequence of consecutive batches of RTP
packets. Let ELF(i) be the Effective Loss Factor calculated for i-th
Zheng & Even Expires May 3, 2018 [Page 3]
Internet-Draft RTCP XR Effective Loss Index October 2017
batch, and N as number of batches in the sequence, then Effective
Loss Index is calculated as:
ELF(1)+ELF(2)+ ...+ELF(N)
Effective Loss Index = ------------------------- x 10000
N
Figure 2: Calculation of Effective Loss Index
The following is an example of how to calculate Effective Loss Index.
For simplicity and demonstration purpose, the size of batches is
assumed to be 3, and the Effective Loss Threshold is assumed to be 1.
The example processes a sequence of 9 RTP packets in 3 batches.
Batch Post-Repair Effective
Loss Loss Factor
| 1 2 3 | 2, 3 1
| 4 5 6 | 5 0
| 7 8 9 | 7 0
1 + 0 + 0
Effective Loss Index = ----------- x 10000 = 3333
3
1.2. Applicability
The metric defined by this document is applicable to a range of RTP
applications that send packets in batches of equal length, probably
with stream repair means (e.g., Forward Error Correction (FEC)
[RFC5109] and/or retransmission [RFC4588]) applied on the batches.
Note that in order to not interfere with the batches being protected,
any additional packets generated by the stream repair means SHOULD be
in a different RTP stream.
The number of batches among which ELI is calculated should not be too
few, otherwise the result may be too biased. However, specifying a
minimal number of batches seems unrealistic, due to the stream repair
means used by applications can be quite different. This document
leaves it to applications to choose a suitable minimal value for the
number of batches.
1.3. RTCP and RTCP XR Reports
The use of RTCP for reporting is defined in [RFC3550]. [RFC3611]
defines an extensible structure for reporting by using an RTCP
Extended Report (XR). This document defines a new Extended Report
block for use with [RFC3550] and [RFC3611].
Zheng & Even Expires May 3, 2018 [Page 4]
Internet-Draft RTCP XR Effective Loss Index October 2017
1.4. Performance Metrics Framework
The Performance Metrics Framework [RFC6390] provides guidance on the
definition and specification of performance metrics. The "Guidelines
for Use of the RTP Monitoring Framework" [RFC6792] provides
guidelines for reporting block format using RTCP XR. The Metrics
Block described in this document is in accordance with the guidelines
in [RFC6390] and [RFC6792].
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].
3. Effective Loss Index Report Block
The Effective Loss Index 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=TBD | Reserved | Block length = 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Effective Loss Index | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Block Type (BT): 8 bits: An Effect Loss Index Report Block is
identified by the constant 'TBD'.
[[Editor Note: should replace 'TBD' with assigned value]]
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
3. 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].
Effective Loss Index: 16 bits: The value of this field SHOULD be set
to the calculated result of Effective Loss Index (as in Figure 2).
Zheng & Even Expires May 3, 2018 [Page 5]
Internet-Draft RTCP XR Effective Loss Index October 2017
Padding: 16 bits: These bits MUST be set to zero by senders and
ignored by receivers.
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-eli-block
xr-eli-block = "effective-loss-index"
[ ":" effective-loss-batch-size]
[ ">" effective-loss-threshold]
effective-loss-batch-size = 1*DIGIT
; the batch size is in number of packets
effective-loss-threshold = 1*DIGIT
; the threshold is in number of packets
DIGIT = %x30-39
The SDP attribute "xr-eli-block" is designed to contain two optional
values, one for signaling the batch size, another for the Effective
Loss Threshold. Here are some examples:
1. signaling both batch size (100) and Effective Loss Threshold (2)
xr-eli-block = "effective-loss-index" : "100" > "2"
2. signaling only batch size (100)
xr-eli-block = "effective-loss-index" : "100"
3. signaling only Effective Loss Threshold (2)
xr-eli-block = "effective-loss-index" > "2"
Zheng & Even Expires May 3, 2018 [Page 6]
Internet-Draft RTCP XR Effective Loss Index October 2017
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 Effective Loss Index
reports. 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 'TBD' in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
the "Post-Repair Loss Count Metrics Report Block".
[[Editor Note: should replace 'TBD' with assigned value]]
6.2. New RTCP XR SDP Parameter
This document also registers a new parameter "effective-loss-index"
in the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry".
Zheng & Even Expires May 3, 2018 [Page 7]
Internet-Draft RTCP XR Effective Loss Index October 2017
6.3. Contact Information for Registrations
The contact information for the registrations is:
RAI Area Directors <rai-ads@ietf.org>
7. Acknowledgements
This document has benefited greatly from the comments of various
people. The following individuals have contributed to this document:
Rachel Huang, Colin Perkins, Yanfang Zhang, Lingyan Wu.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://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, <https://www.rfc-editor.org/info/rfc3550>.
8.2. Informative References
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc3711>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
DOI 10.17487/RFC4588, July 2006, <https://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, <https://www.rfc-editor.org/info/rfc5109>.
Zheng & Even Expires May 3, 2018 [Page 8]
Internet-Draft RTCP XR Effective Loss Index October 2017
[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, <https://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, <https://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, <https://www.rfc-editor.org/info/rfc5725>.
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011, <https://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, <https://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, <https://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,
<https://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, <https://www.rfc-editor.org/info/rfc7202>.
[RFC7509] Huang, R. and V. Singh, "RTP Control Protocol (RTCP)
Extended Report (XR) for Post-Repair Loss Count Metrics",
RFC 7509, DOI 10.17487/RFC7509, May 2015,
<https://www.rfc-editor.org/info/rfc7509>.
Zheng & Even Expires May 3, 2018 [Page 9]
Internet-Draft RTCP XR Effective Loss Index October 2017
Appendix A. Metric Represented Using the Template from RFC 6390
A.1. Effective Loss Index
o Metric Name: RTP Effective Loss Index.
o Metric Description: The effectiveness of stream repair means
applied on a sequence of RTP packets.
o Method of Measurement or Calculation: See the "Effective Loss
Index" definition in Section 1.1. It is directly measured and
must be measured for the primary source RTP packets with no
further chance of repair.
o Units of Measurement: This metric is expressed as a 16-bit
unsigned integer value representing the effectiveness of stream
repair means.
o Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream.
o Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing.
o Use and Applications: These metrics are applicable to any RTP
application, especially those that use loss-repair mechanisms.
See Section 1 for details.
o Reporting Model: See RFC 3611.
Authors' Addresses
Hui Zheng (Marvin)
Huawei
Email: marvin.zhenghui@huawei.com
Roni Even
Huawei
Email: roni.even@huawei.com
Zheng & Even Expires May 3, 2018 [Page 10]