INTERNET-DRAFT R. Huang
Intended Status: Standard Huawei
Expires: August 17, 2014 V. Singh
Aalto University
February 13, 2014
RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair
Loss Count Metrics
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01
Abstract
This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block that allows reporting of post-repair loss count metrics
for a range of RTP applications.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 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
<Singh&Huang> Expires August 17, 2014 [Page 1]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
(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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 5
4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 6
6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7
6.3 Contact Information for registrations . . . . . . . . . . . 7
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Metrics Represented Using the Template from RFC 6390 . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
<Singh&Huang> Expires August 17, 2014 [Page 2]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
1 Introduction
RTCP SR/RR [RFC3550] contains some rough statistics about the data
received from the particular source indicated in that block. One of
them is the cumulative number of packet lost, which is called 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 media stream before any loss repair mechanism, e.g.,
retransmission [RFC4588] and Forward Error Correction (FEC)
[RFC5109], is applied. Using a repair mechanism usually results in
recovering some or all of the lost packets. Hence, the sending
endpoint cannot assess the performance of the repair mechanism by
observing the change in fraction loss and the cumulative loss
statistics from RTCP SR/RR [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 at the
cost of higher overhead. 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 application. This new block type reports the
number of primary source RTP packets that are still lost after
applying one or more loss repair mechanisms. When comparing this
metric with pre-repair loss metric of RTCP SR/RR, ambiguity may occur
as noted in [RFC5725]: Some packets will not be repaired in current
RTCP interval. Thus it is RECOMMENDED that this report block should
be generated for those source packets that have no further chance of
being repaired. But a potential ambiguity may result from sequence
number range inconsistent. The sequence number range reported by RTCP
SR/RR may contain some sequence numbers of packets for which repair
might still be possible. To address this issue, we use begin sequence
number and end sequence number to explicitly indicate the actual
sequence number range that this RTCP XR report block reports on. In
addition, another metric, repaired loss count, is also introduced in
this report block for calculating the pre-repair loss count during
the 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. Note that the metrics in this report block MUST NOT be
directly compared with the pre-repair loss metric of [RFC3550].
The metrics defined in this document belongs to the class of
transport-related metrics defined in [RFC6792]. And it is in
accordance with the guidelines in [RFC6390] and [RFC6792]. These
metrics are applicable to any RTP application, especially those that
use loss repair mechanisms.
<Singh&Huang> Expires August 17, 2014 [Page 3]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
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].
primary source RTP packet: the original RTP packet sent from the RTP
sender for the first time. A primary source RTP packet may be lost
when transporting. The lost one can be repaired by 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 to complement the RTCP XR metrics defined in [RFC5725].
This packet may be stacked with other RTCP packets to form compound
RTCP packets and share the average reporting interval calculated by
the RTCP method described in [RFC3550]. These metrics defined in this
report block are all interval metrics and the measurement of them is
made at the receiving end of the RTP stream.
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=PRLR | Reserved | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unrepaired loss count | repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the Post-Repair Loss Count Metrics Report
Block
Block Type (BT): 8 bits
A Post-Repair Loss Count Metrics Report Block is identified by the
constant PRLR.
[Note to RFC Editor: Please replace PRLR with the IANA provided
RTCP XR block type for this block.]
<Singh&Huang> Expires August 17, 2014 [Page 4]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
Reserved: 8 bits
These bits are reserved for future use. They MUST be set to zero
by senders and ignored by receivers (see [RFC6709], Section 4.2).
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.
end_seq: 16 bits
The last sequence number that this block reports on plus one.
unrepaired loss count: 16 bits
Total number of packets finally lost after one or more loss-repair
methods, e.g., FEC and/or retransmission, during this interval.
This metric MUST NOT count the lost packets for which repair might
still be possible. Note that this metric must be measured in the
primary source RTP packets.
repaired loss count: 16 bits
Total number of packets fully repaired after one or more loss-
repair methods, e.g., FEC and/or retransmission, during this
interval. Note that this metric must be measured in the primary
source RTP packets.
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
<Singh&Huang> Expires August 17, 2014 [Page 5]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
5.1 of [RFC3611] by providing an additional value of "xr-format" to
signal the use of the report block defined in this document.
xr-format =/ xr-prlr-block
xr-prlr-block = "post-repair-loss-count"
4.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].
5 Security Considerations
It is believed that this 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 confidentially
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 be affect the performance of loss repair
mechanisms. Implementers should consider the guidance in [I-D.ietf-
avtcore-srtp-not-mandatory] 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 [I-
D.ietf-avtcore-rtp-security-options]) 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 PRLR in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
the "Post-Repair Loss Count Metrics Report Block".
[Note to RFC Editor: please replace PRLR with the IANA provided RTCP
XR block type for this block.]
<Singh&Huang> Expires August 17, 2014 [Page 6]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
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 following contact information is provided for all registrations
in this document:
Rachel Huang (rachel.huang@huawei.com)
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
7 Acknowledgments
The author would like to thank Roni Even and Colin Perkins for giving
valuable comments and suggestions.
8 References
8.1 Normative References
[KEYWORDS] 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.
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed.,
"RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, November 2003.
[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, February 2010.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
8.2 Informative References
<Singh&Huang> Expires August 17, 2014 [Page 7]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390,
October 2011.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012.
Appendix A. Metrics Represented Using the Template from RFC 6390
a. Unrepaired RTP Packet Loss Count Metric
* Metric Name: Unrepaired 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: It must be measured for
the primary source RTP packets with no further chance of repair
* Units of Measurement: See section 3, unrepaired loss count
definition
* Measurement Point(s) with Potential Measurement Domain: See
section 3, 1st paragraph
* Measurement Timing: See Section 3, 1st paragraph, for
measurement timing
* Use and Applications: See Section 1
* Reporting Model: See RFC3611
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: It must be measured for
the primary source RTP packets with no further chance of repair
* Units of Measurement: See section 3, repaired loss count
definition
* Measurement Point(s) with Potential Measurement Domain: See
section 3, 1st paragraph
<Singh&Huang> Expires August 17, 2014 [Page 8]
INTERNET DRAFT Post-Repair Non-RLE loss Count February 13, 2014
* Measurement Timing: See Section 3, 1st paragraph, for
measurement timing
* Use and Applications: See Section 1
* Reporting Model: See RFC3611
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> Expires August 17, 2014 [Page 9]
