draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06.txt   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07.txt 
INTERNET-DRAFT R. Huang INTERNET-DRAFT R. Huang
Intended Status: Standards Track Huawei Intended Status: Standards Track Huawei
Expires: June 5, 2015 V. Singh Expires: June 15, 2015 V. Singh
Aalto University Aalto University
December 2, 2014 December 12, 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-06 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
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 3, line 7 skipping to change at page 3, line 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 . . . . . . . . . . . . . . . . . . 8
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 Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contains
received from the particular source indicated in that block. One of some rough statistics about the data received from the particular
them is the cumulative number of packet lost, which is called pre- source indicated in that block. One of them is the cumulative number
repair loss metric in this document. This metric conveys information of packets lost, which is called pre- repair loss metric in this
regarding the total number of RTP data packets that have been lost document. This metric conveys information regarding the total number
since the beginning of the RTP session. However, this metric is of RTP data packets that have been lost since the beginning of the
measured on media stream before any loss repair mechanism, e.g., RTP session. However, this metric is measured on media stream before
retransmission [RFC4588] and Forward Error Correction (FEC) any loss repair mechanism, e.g., retransmission [RFC4588] and Forward
[RFC5109], is applied. Using a repair mechanism usually results in Error Correction (FEC) [RFC5109], is applied. Using a repair
recovering some or all of the lost packets. Hence, the sending mechanism usually results in recovering some or all of the lost
endpoint cannot assess the performance of the repair mechanism by packets. Hence, the sending endpoint cannot assess the performance of
observing the change in fraction loss and the cumulative loss the repair mechanism by observing the change in fraction loss and the
statistics from RTCP SR/RR [RFC3550]. Consequently, [RFC5725] cumulative loss statistics from RTCP SR/RR [RFC3550]. Consequently,
specifies a post-repair loss Run-length Encoding (RLE) XR report [RFC5725] specifies a post-repair loss Run-length Encoding (RLE) XR
block to address this issue. The sending endpoint is able to infer report block to address this issue. The sending endpoint is able to
which packets were repaired from the RLE report block, but at the infer which packets were repaired from the RLE report block, but at
cost of higher overhead. When applications use multiple XR blocks, the cost of higher overhead. When applications use multiple XR
the endpoints may require more concise reporting to save bandwidth. blocks, 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 applications. This new block type reports the
number of primary source RTP packets that are still lost after number of primary source RTP packets that are still lost after
applying one or more loss repair mechanisms. The metrics defined in applying one or more loss repair mechanisms. The metrics defined in
this document are packet level rather than slice/picture level, which this document are packet level rather than slice/picture level, which
means the partial recovery of a packet will not be regarded as a means the partial recovery of a packet will not be regarded as a
repaired packet. In addition, another metric, repaired loss count, repaired packet. In addition, another metric, repaired loss count,
is also introduced in this report block for calculating the pre- 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 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 third-party entity is able to evaluate the effectiveness of the
repair methods used by the system. repair methods used by the system.
The metrics defined in this document belongs to the class of The metrics defined in this document belong to the class of
transport-related metrics defined in [RFC6792]. And it is in transport-related metrics defined in [RFC6792] and are specified 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 [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
skipping to change at page 4, line 15 skipping to change at page 4, line 16
or retransmission. or retransmission.
3 Post-Repair Loss Count Metrics Report Block 3 Post-Repair Loss Count Metrics Report Block
This block reports the number of packets lost after applying repair This block reports the number of packets lost after applying repair
mechanisms to complement the RTCP XR metrics defined in [RFC5725]. mechanisms to complement the RTCP XR metrics defined in [RFC5725].
This packet may be stacked with other RTCP packets to form compound This packet may be stacked with other RTCP packets to form compound
RTCP packets and share the average reporting interval calculated by RTCP packets and share the average reporting interval calculated by
the RTCP method described in [RFC3550]. When comparing this metric the RTCP method described in [RFC3550]. When comparing this metric
with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as 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 noted in [RFC5725]: Some packets will not be repaired in the current
interval. Thus it is RECOMMENDED that this report block should be RTCP interval. Thus it is RECOMMENDED that this report block should
generated for those source packets that have no further chance of be generated only for those source packets that have no further
being repaired. But a potential ambiguity may result from sequence chance of being repaired and not for any other packets. This block
number range inconsistent. The sequence number range reported by RTCP needs to specify its own measurement period to avoid ambiguity in
SR/RR may contain some sequence numbers of packets for which repair calculating the post-repair loss count. The sequence number range
might still be possible. To address this issue, we use begin sequence reported by RTCP SR/RR may contain some sequence numbers of packets
number and end sequence number to explicitly indicate the actual for which repair might still be possible. To avoid the ambiguity, we
sequence number range that this RTCP XR report block reports on as use begin sequence number and end sequence number to explicitly
the measurement timing. These metrics defined in this report block indicate the actual sequence number range that this RTCP XR report
are all interval metrics and the measurement of them is made at the block reports on as the measurement timing. These metrics defined in
RTP receiver. The relationship between the metrics in this report this report block are all interval metrics and the measurement of
block and the pre-repair loss metric of RTCP XR could be expressed in them is made at the RTP receiver. The relationship between the
the following formula: metrics in this report block and the pre-repair loss metric of RTCP
XR could be expressed in the following formula:
cumulative number of packets lost = unrepaired loss count + cumulative number of packets lost = unrepaired loss count +
repaired loss count + to be repaired lost packet repaired loss count + to be repaired lost packet
"cumulative number of packets lost" is the metric from RTCP SR/RR. "cumulative number of packets lost" is the metric from RTCP SR/RR.
"unrepaired loss count" and "repaired loss count" are the metrics "unrepaired loss count" and "repaired loss count" are the metrics
defined in this draft. defined in this draft.
The post-repair loss count metrics report block has the following The post-repair loss count metrics report block has the following
format: format:
skipping to change at page 5, line 43 skipping to change at page 5, line 46
end_seq: 16 bits end_seq: 16 bits
The last sequence number that this block reports on plus one. The last sequence number that this block reports on plus one.
unrepaired loss count: 16 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 for which repair might This metric MUST NOT count the lost packets for which repair might
still be possible. Note that this metric must be measured in the still be possible. Note that this metric MUST measure only primary
primary source RTP packets. source RTP packets.
repaired loss count: 16 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 measure only primary source
source RTP packets. 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 6, line 26 skipping to change at page 7, line 26
xr-format =/ xr-prlr-block xr-format =/ xr-prlr-block
xr-prlr-block = "post-repair-loss-count" xr-prlr-block = "post-repair-loss-count"
4.2 Offer/Answer Usage 4.2 Offer/Answer Usage
When SDP is used in offer-answer context, the SDP 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 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters
applies. For detailed usage of Offer/Answer for unilateral applies. For detailed usage of Offer/Answer for unilateral
parameter, refer to section 5.2 of [RFC3611]. parameters, refer to section 5.2 of [RFC3611].
5 Security Considerations 5 Security Considerations
It is believed that this RTCP XR block introduces no new security It is believed that this RTCP XR block introduces no new security
considerations beyond those described in [RFC3611]. This block does considerations beyond those described in [RFC3611]. This block does
not provide per-packet statistics, so the risk to confidentially not provide per-packet statistics, so the risk to confidentially
documented in Section 7, paragraph 3 of [RFC3611] does not apply. documented in Section 7, paragraph 3 of [RFC3611] does not apply.
An attacker may put incorrect information in the Post-Repair Loss An attacker may put incorrect information in the Post-Repair Loss
Count reports, which will be affect the performance of loss repair Count reports, which will be affect the performance of loss repair
skipping to change at page 7, line 19 skipping to change at page 8, line 19
XR block type for this block.] XR block type for this block.]
6.2 New RTCP XR SDP Parameter 6.2 New RTCP XR SDP Parameter
This document also registers a new parameter "post-repair-loss-count" This document also registers a new parameter "post-repair-loss-count"
in the "RTP Control Protocol Extended Reports (RTCP XR) Session in the "RTP Control Protocol Extended Reports (RTCP XR) Session
Description Protocol (SDP) Parameters Registry". Description Protocol (SDP) Parameters Registry".
6.3 Contact Information for registrations 6.3 Contact Information for registrations
The following contact information is provided for all registrations The contact information for the registration is :
in this document:
Rachel Huang (rachel.huang@huawei.com)
101 Software Avenue, Yuhua District RAI Area Directors <rai-ads@tools.ietf.org>
Nanjing, Jiangsu 210012
China
7 Acknowledgments 7 Acknowledgments
The author would like to thank Roni Even and Colin Perkins for giving The author would like to thank Roni Even, Colin Perkins, and Qin Wu
valuable comments and suggestions. for giving 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 48 skipping to change at page 9, line 41
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, April 2014. Security Solution", RFC 7202, April 2014.
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 for * Method of Measurement or Calculation: See section 3, Unrepaired
the primary source RTP packets with no further chance of repair RTP Packet Loss Count Metric definition. It is directly measured
* Units of Measurement: See section 3, unrepaired loss count and must be measured for the primary source RTP packets with no
definition further chance of repair.
* Measurement Point(s) with Potential Measurement Domain: See * Units of Measurement: This metric is expressed as a 16-bit
section 3, 1st paragraph unsigned integer value.
* Measurement Timing: See Section 3, 1st paragraph, for * Measurement Point(s) with Potential Measurement Domain: It is
measurement timing measured at the receiving end of the RTP stream.
* Use and Applications: See Section 1 * Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing. See Section 3, 1st
paragraph, for details.
* Reporting Model: See RFC3611 * 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 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 for * Method of Measurement or Calculation: See section 3, Repaired
the primary source RTP packets with no further chance of repair RTP Packet Loss Count Metric definition. It is directly measured
and must be measured for the primary source RTP packets with no
further chance of repair.
* Units of Measurement: See section 3, repaired loss count * Units of Measurement: This metric is expressed as a 16-bit
definition unsigned integer value.
* Measurement Point(s) with Potential Measurement Domain: See * Measurement Point(s) with Potential Measurement Domain: It is
section 3, 1st paragraph measured at the receiving end of the RTP stream.
* Measurement Timing: See Section 3, 1st paragraph, for * Measurement Timing: This metric relies on the sequence number
measurement timing interval to determine measurement timing. See Section 3, 1st
paragraph, for details.
* Use and Applications: See Section 1 * 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 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
Varun Singh Varun Singh
Aalto University Aalto University
School of Electrical Engineering School of Electrical Engineering
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 Espoo, FIN 02150
Finland Finland
Email: varun@comnet.tkk.fi Email: varun@comnet.tkk.fi
URI: http://www.netlab.tkk.fi/~varun/ URI: http://www.netlab.tkk.fi/~varun/
 End of changes. 28 change blocks. 
75 lines changed or deleted 83 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/