draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-00.txt   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01.txt 
INTERNET-DRAFT R. Huang INTERNET-DRAFT R. Huang
Intended Status: Standard Huawei Intended Status: Standard Huawei
Expires: June 12, 2014 V. Singh Expires: August 17, 2014 V. Singh
Aalto University Aalto University
December 9, 2013 February 13, 2014
RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair
Loss Count Metrics Loss Count Metrics
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-00 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-01
Abstract Abstract
This document defines an RTP Control Protocol (RTCP) Extended Report This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) Block that allows reporting of post-repair loss count metrics (XR) Block that allows reporting of post-repair loss count metrics
for a range of RTP applications. for a range of RTP applications.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 5
4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 6
6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7
6.3 Contact Information for registrations . . . . . . . . . . . 7 6.3 Contact Information for registrations . . . . . . . . . . . 7
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . . 7
8.2 Informative References . . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Metrics Represented Using the Template from RFC 6390 . 8 Appendix A. Metrics Represented Using the Template from RFC 6390 . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1 Introduction 1 Introduction
RTCP SR/RR [RFC3550] contains some rough statistics about the data RTCP SR/RR [RFC3550] contains some rough statistics about the data
received from the particular source indicated in that block. One of received from the particular source indicated in that block. One of
them is the cumulative number of packet lost, which is called pre- them is the cumulative number of packet lost, which is called pre-
repair loss metric in this document. This metric conveys information repair loss metric in this document. This metric conveys information
regarding the total number of RTP data packets that have been lost regarding the total number of RTP data packets that have been lost
since the beginning of the RTP session. However, this metric is since the beginning of the RTP session. However, this metric is
measured on media stream before any loss repair mechanism, e.g., measured on media stream before any loss repair mechanism, e.g.,
retransmission [RFC4588] and Forward Error Correction (FEC) retransmission [RFC4588] and Forward Error Correction (FEC)
[RFC5109], is applied. Using a repair mechanism usually results in [RFC5109], is applied. Using a repair mechanism usually results in
recovering some or all of the lost packets. Hence, the sending recovering some or all of the lost packets. Hence, the sending
endpoint cannot assess the performance of the repair mechanism by endpoint cannot assess the performance of the repair mechanism by
observing the change in fraction loss and the cumulative loss observing the change in fraction loss and the cumulative loss
statistics. Consequently, [RFC5725] specifies a post-repair loss Run- statistics from RTCP SR/RR [RFC3550]. Consequently, [RFC5725]
length Encoding (RLE) XR report block to address this issue. The specifies a post-repair loss Run-length Encoding (RLE) XR report
sending endpoint is able to infer which packets were repaired from block to address this issue. The sending endpoint is able to infer
the RLE report block, but at the cost of higher overhead. When which packets were repaired from the RLE report block, but at the
applications use multiple XR blocks, the endpoints require more cost of higher overhead. When applications use multiple XR blocks,
concise reporting to save bandwidth. the endpoints may require more concise reporting to save bandwidth.
This document defines a new XR block type to augment those defined in This document defines a new XR block type to augment those defined in
[RFC3611] and complement the report block defined in [RFC5725] for [RFC3611] and complement the report block defined in [RFC5725] for
use in a range of RTP application. This new block type reports the use in a range of RTP application. This new block type reports the
number of RTP packets on the primary source stream that are still number of primary source RTP packets that are still lost after
lost after applying one or more loss repair mechanisms. When applying one or more loss repair mechanisms. When comparing this
comparing this metric with pre-repair loss metric of RTCP SR/RR, it metric with pre-repair loss metric of RTCP SR/RR, ambiguity may occur
may bring ambiguity as noted in [RFC5725]: Some packets will not be as noted in [RFC5725]: Some packets will not be repaired in current
repaired in current RTCP interval. So in [RFC5725] it is suggested to RTCP interval. Thus it is RECOMMENDED that this report block should
delay report block to wait for packets to be repaired. However, it is be generated for those source packets that have no further chance of
not wise to delay this report block arbitrarily until those packets being repaired. But a potential ambiguity may result from sequence
have been fully repaired. Thus it is RECOMMENDED that this report number range inconsistent. The sequence number range reported by RTCP
block should be generated for those source packets that have no SR/RR may contain some sequence numbers of packets for which repair
further chance of being repaired. But a potential ambiguity may might still be possible. To address this issue, we use begin sequence
result from sequence number range inconsistent. To address this number and end sequence number to explicitly indicate the actual
issue, we use begin sequence number and end sequence number to sequence number range that this RTCP XR report block reports on. In
explicitly indicate the actual sequence number range that the report addition, another metric, repaired loss count, is also introduced in
block reports on. In addition, another metric, repaired loss count, this report block for calculating the pre-repair loss count during
is also introduced in this report block for calculating the pre- the this range, so that the RTP sender or a third-party entity is
repair loss count during the this range. Note that the metrics in able to evaluate the effectiveness of the repair methods used by the
this report block MUST NOT be directly compared with the pre-repair system. Note that the metrics in this report block MUST NOT be
loss metric of RFC3550. directly compared with the pre-repair loss metric of [RFC3550].
The metrics defined in this document belongs to the class of The metrics defined in this document belongs to the class of
transport-related metrics defined in [RFC6792]. And it is in transport-related metrics defined in [RFC6792]. And it is in
accordance with the guidelines in [RFC6390] and [RFC6792]. These accordance with the guidelines in [RFC6390] and [RFC6792]. These
metrics are applicable to any RTP application, especially those that metrics are applicable to any RTP application, especially those that
use loss repair mechanisms. use loss repair mechanisms.
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. 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 3 Post-Repair Loss Count Metrics Report Block
This block describes the residual number of packets lost after This block reports the number of packets lost after applying repair
applying repair mechanisms. The report block is complementary to the mechanisms to complement the RTCP XR metrics defined in [RFC5725].
RTCP XR metrics defined in [RFC5725] as it uses a non-RLE format. 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 The post-repair loss count metrics report block has the following
format: format:
0 1 2 3 4 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 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 | | BT=PRLR | Reserved | block length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source | | SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq | | begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unrepaired loss count | | unrepaired loss count | repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| repaired loss count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for the Post-Repair Loss Count Metrics Report Figure 1: Format for the Post-Repair Loss Count Metrics Report
Block Block
Block Type (BT): 8 bits Block Type (BT): 8 bits
A Post-Repair Loss Count Metrics Report Block is identified by the A Post-Repair Loss Count Metrics Report Block is identified by the
constant PRLR. constant PRLR.
skipping to change at page 5, line 14 skipping to change at page 5, line 22
This field is in accordance with the definition in [RFC3611]. In This field is in accordance with the definition in [RFC3611]. In
this report block, it MUST be set to 4. The block MUST be this report block, it MUST be set to 4. The block MUST be
discarded if the block length is set to a different value. discarded if the block length is set to a different value.
SSRC of source: 32 bits SSRC of source: 32 bits
As defined in Section 4.1 of [RFC3611]. As defined in Section 4.1 of [RFC3611].
begin_seq: 16 bits begin_seq: 16 bits
The sequence number of the first packet in the session or the The first sequence number that this block reports on.
sequence number of the first packet fully repaired that this block
reports on.
end_seq: 16 bits end_seq: 16 bits
The sequence number of the last packet fully repaired that this The last sequence number that this block reports on plus one.
block reports on plus one.
unrepaired loss count: 32 bits unrepaired loss count: 16 bits
Total number of packets finally lost after one or more loss-repair Total number of packets finally lost after one or more loss-repair
methods, e.g., FEC and/or retransmission, during this interval. methods, e.g., FEC and/or retransmission, during this interval.
This metric MUST NOT count the lost packets that haven't finished This metric MUST NOT count the lost packets for which repair might
repairing. Note that this metric must be measured in the primary still be possible. Note that this metric must be measured in the
source stream. primary source RTP packets.
repaired loss count: 32 bits repaired loss count: 16 bits
Total number of packets fully repaired after one or more loss- Total number of packets fully repaired after one or more loss-
repair methods, e.g., FEC and/or retransmission, during this repair methods, e.g., FEC and/or retransmission, during this
interval. Note that this metric must be measured in the primary interval. Note that this metric must be measured in the primary
source stream. source RTP packets.
4 SDP Signaling 4 SDP Signaling
[RFC3611] defines the use of SDP (Session Description Protocol) for [RFC3611] defines the use of SDP (Session Description Protocol) for
signaling the use of RTCP XR blocks. However XR blocks MAY be used signaling the use of RTCP XR blocks. However XR blocks MAY be used
without prior signaling (see section 5 of [RFC3611]). without prior signaling (see section 5 of [RFC3611]).
4.1 SDP rtcp-xr-attrib Attribute Extension 4.1 SDP rtcp-xr-attrib Attribute Extension
This session augments the SDP attribute "rtcp-xr" defined in Section This session augments the SDP attribute "rtcp-xr" defined in Section
skipping to change at page 7, line 33 skipping to change at page 7, line 24
in this document: in this document:
Rachel Huang (rachel.huang@huawei.com) Rachel Huang (rachel.huang@huawei.com)
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
7 Acknowledgments 7 Acknowledgments
The author would like to thank Roni Even for giving valuable comments The author would like to thank Roni Even and Colin Perkins for giving
and suggestions. valuable comments and suggestions.
8 References 8 References
8.1 Normative References 8.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 8, line 30 skipping to change at page 8, line 21
Appendix A. Metrics Represented Using the Template from RFC 6390 Appendix A. Metrics Represented Using the Template from RFC 6390
a. Unrepaired RTP Packet Loss Count Metric a. Unrepaired RTP Packet Loss Count Metric
* Metric Name: Unrepaired RTP Packet Loss Count Metric * Metric Name: Unrepaired RTP Packet Loss Count Metric
* Metric Description: Total number of RTP packets still lost after * Metric Description: Total number of RTP packets still lost after
loss repair methods are applied loss repair methods are applied
* Method of Measurement or Calculation: It must be measured in the * Method of Measurement or Calculation: It must be measured for
primary source stream. It must be measured for the packets that the primary source RTP packets with no further chance of repair
have no further chance of being repaired.
* Units of Measurement: See section 3, unrepaired loss count * Units of Measurement: See section 3, unrepaired loss count
definition. definition
* Measurement Point(s) with Potential Measurement Domain: See * Measurement Point(s) with Potential Measurement Domain: See
section 3, 1st paragraph. section 3, 1st paragraph
* Measurement Timing: See Section 4 for measurement timing. * Measurement Timing: See Section 3, 1st paragraph, for
measurement timing
* Use and Applications: See Section 1 * Use and Applications: See Section 1
* Reporting Model: See RFC3611. * Reporting Model: See RFC3611
b. Repaired RTP Packet Loss Count Metric b. Repaired RTP Packet Loss Count Metric
* Metric Name: Repaired RTP Packet Count Metric * Metric Name: Repaired RTP Packet Count Metric
* Metric Description: The number of RTP packets lost but repaired * Metric Description: The number of RTP packets lost but repaired
after applying loss repair methods. after applying loss repair methods
* Method of Measurement or Calculation: It must be measured in the * Method of Measurement or Calculation: It must be measured for
primary source stream. the primary source RTP packets with no further chance of repair
* Units of Measurement: See section 3, repaired loss count * Units of Measurement: See section 3, repaired loss count
definition. definition
* Measurement Point(s) with Potential Measurement Domain: See * Measurement Point(s) with Potential Measurement Domain: See
section 3, 1st paragraph. section 3, 1st paragraph
* Measurement Timing: See Section 3, 1st paragraph, for
* Measurement Timing: See Section 4 for measurement timing. measurement timing
* Use and Applications: See Section 1 * Use and Applications: See Section 1
* Reporting Model: See RFC3611. * Reporting Model: See RFC3611
Authors' Addresses Authors' Addresses
Rachel Huang Rachel Huang
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing 210012 Nanjing 210012
China China
EMail: rachel.huang@huawei.com EMail: rachel.huang@huawei.com
 End of changes. 30 change blocks. 
66 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/