Internet DRAFT - draft-zheng-xrblock-effective-loss-index
draft-zheng-xrblock-effective-loss-index
Network Working Group H. Zheng
Internet-Draft R. Even
Intended status: Standard Track Q. Wu
Expires: September 3, 2018 Huawei
R. Gu
China Mobile
R. Huang
Huawei
March 2, 2018
RTP Control Protocol (RTCP) Extended Report (XR) Block for Effective
Loss Index Reporting
draft-zheng-xrblock-effective-loss-index-02
Abstract
This document defines a new metric for RTP monitors to estimate 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) 2018 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
Zheng, et al. Expires September 3, 2018 [Page 1]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Effective Loss Index . . . . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
1.3. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. New RTCP XR Block Type Value . . . . . . . . . . . . . . . 8
6.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 9
6.3. Contact Information for Registrations . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Metric Represented Using the Template from RFC 6390 . 11
A.1. Effective Loss Index . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
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
estimate the effectiveness of stream repair means by calculating the
probability of the post-repair losses. The new metric provides a
simpler view on the post-repair loss than the mechanisms documented
in [RFC5725] and [RFC7509]. ELI is an index, so the values reported
from the monitors deployed in the different places in the network can
Zheng, et al. Expires September 3, 2018 [Page 2]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
be compared directly, which makes it easier to diagnose the network
problem when delivering the RTP streams. A use case is to compare the
ELI value reported by a monitor in the network with a certain
reasonable threshold to see if there are any problems in the IPTV
services. 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.
This document also defines in section 3, an XR block to report the
metric.
1.1. Effective Loss Index
Effective Loss Index (ELI) uses a simple model to measure the loss
impact after applying loss repairsof loss repair. It is useful
especially in the middleboxes which usually are passive observer and
do not have the ability to recover the loss data.
The model assumes that repair means are applied onto packets by
batches of equal size. Lower ELI means that loss impact is minimal.
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 if the middlebox can see the SDP,
or just configure it.
An RTP endpoint is assumed 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 Loss
Repair Threshold, showing below:
if Loss Packets Number > Loss Repair 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 Loss Packets Number is the number of packet lost in the batch.
o Loss Repair Threshold indicates the maximum loss packets number
that can be recovered.
Zheng, et al. Expires September 3, 2018 [Page 3]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
The minimum value of Loss Repair Threshold is zero, which means there
is no loss repair. This document does not mandate any value for Loss
Repair Threshold. Applications can prescribe a value for themselves
without signaling. For example, it can be calculated by the batch
size multiplied by the fixed redundancy ratio of the FEC algorithm;
And when used in the retransmission case, it can be set to the
maximum number of lost packets to be retransmitted in a batch. On the
other hand, SDP signaling defined in Section 4.1 can be used to
communicate the value.
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
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 = -------------------------
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 a batch is
assumed to be 3, and the Loss Repair Threshold is assumed to be 1.
The example processes a sequence of 9 RTP packets (x means lost) in 7
batches.
1xx4x6x89
Batch Loss Effective Loss Factor
| 1 2 3 | 2, 3 1
| 2 3 4 | 2, 3 1
| 3 4 5 | 3 0
| 4 5 6 | 5 0
| 5 6 7 | 5, 7 1
| 6 7 8 | 7 0
| 7 8 9 | 7 0
1+1+0+0+1+0+0
Effective Loss Index = --------------- = 0.4285
7
This example provides fine grained estimation for loss recovery. It
can detect the loss burst happening over batches. Implementations can
also do coarse grained estimation by simply dividing total packets
into several batches.
Zheng, et al. Expires September 3, 2018 [Page 4]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
1.2. Applicability
The metric defined by this document is applicable to a range of RTP
applications that send packets with stream repair means (e.g.,
Forward Error Correction (FEC) [RFC5109] and/or retransmission
[RFC4588]) applied on them. Note that this metric is only valuable
for FECs where he redundant data are sent in a different RTP stream
from the original media stream.
This document does not mandate any value for the batch size.
Applications can prescribe a value for themselves without signaling.
For example, the batch size can be set to the number of packets
containing source symbols in a source block in the case of FEC, and
can be prescribed arbitrarily, e.g. 100, in the case of
retransmission.
The number of batches among which ELI is calculated should not be too
few, otherwise the result may be biased. It is suggested to calculate
it based on the total number of RTP packets during the measurement
interval, as in the section 1.1 example:
The number of batches = (The total number of RTP packets - the size
of a batch) + 1.
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].
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
Zheng, et al. Expires September 3, 2018 [Page 5]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
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: The SSRC of the RTP data packet source
being reported upon by this report block, as defined in Section
4.1 of [RFC3611].
Effective Loss Index: 16 bits: The value of Effective Loss Index,
equivalent to taking the integer part after multiplying the the
calculated result of Effective Loss Index (as in Figure 2) by
65535.
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
Zheng, et al. Expires September 3, 2018 [Page 6]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
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:
Zheng, et al. Expires September 3, 2018 [Page 7]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
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"
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".
Zheng, et al. Expires September 3, 2018 [Page 8]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
[[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".
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:
Colin Perkins, Yanfang Zhang.
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>.
Zheng, et al. Expires September 3, 2018 [Page 9]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
[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>.
[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>.
Zheng, et al. Expires September 3, 2018 [Page 10]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
[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>.
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
applications, especially those that use loss-repair mechanisms.
See Section 1 for details.
o Reporting Model: See RFC 3611.
Authors' Addresses
Hui Zheng (Marvin)
Individual
Email: zh4ui@huawei.comoutlook.com
Roni Even
Huawei
Email: roni.even@huawei.com
Zheng, et al. Expires September 3, 2018 [Page 11]
Internet-Draft RTCP XR Effective Loss Index March 2, 2018
Qin Wu
Huawei
Email: bill.wu@huawei.com
Rong Gu
China Mobile
Email: gurong_cmcc@outlook.com
Rachel Huang
Huawei
Email: rachel.huang@huawei.com
Zheng, et al. Expires September 3, 2018 [Page 12]
