draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08.txt   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-09.txt 
INTERNET-DRAFT R. Huang INTERNET-DRAFT R. Huang
Intended Status: Standards Track Huawei Intended Status: Standards Track Huawei
Expires: July 8, 2015 V. Singh Expires: July 25, 2015 V. Singh
Aalto University Aalto University
January 4, 2015 January 21, 2015
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-08 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-09
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 metric for
for a range of RTP applications. a range of RTP applications. In addition, another metric, repaired
loss count, is also introduced in this report block for calculating
the pre-repair loss count during this rage.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4
3.1 Report Block Structure . . . . . . . . . . . . . . . . . . 5
3.2 Report Block Example Usage . . . . . . . . . . . . . . . . 6
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 7
4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 6 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 7
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7
6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 8
6.3 Contact Information for registrations . . . . . . . . . . . 7 6.3 Contact Information for registrations . . . . . . . . . . . 8
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . 7 8.1 Normative References . . . . . . . . . . . . . . . . . . . 8
8.2 Informative References . . . . . . . . . . . . . . . . . . 8 8.2 Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Metrics Represented Using the Template from RFC 6390 . 8 Appendix A. Metrics Represented Using the Template from RFC 6390 . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1 Introduction 1 Introduction
RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some RTCP Sender Reports (SR)/Receiver Reports (RR) [RFC3550] contain some
rough statistics about the data received from the particular source rough statistics about the data received from the particular source
indicated in that block. One of them is the cumulative number of indicated in that block. One of them is the cumulative number of
packets lost, which is called pre-repair loss metric in this packets lost, which is called pre-repair loss metric in this
document. This metric conveys information regarding the total number document. This metric conveys information regarding the total number
of RTP data packets that have been lost since the beginning of the of RTP data packets that have been lost since the beginning of the
skipping to change at page 3, line 38 skipping to change at page 3, line 38
When applications use multiple XR blocks, the endpoints may require When applications use multiple XR blocks, the endpoints may require
more concise reporting to save bandwidth. This document defines a new more concise reporting to save bandwidth. This document defines a new
XR block type to augment those defined in [RFC3611] and complement XR block type to augment those defined in [RFC3611] and complement
the report block defined in [RFC5725] for use in a range of RTP the report block defined in [RFC5725] for use in a range of RTP
applications. This new block type reports the post-repair loss count applications. This new block type reports the post-repair loss count
metric which records the number of primary source RTP packets that metric which records the number of primary source RTP packets that
are still lost after applying one or more loss repair mechanisms. In are still lost after applying one or more loss repair mechanisms. In
addition, another metric, repaired loss count, is also introduced in addition, another metric, repaired loss count, is also introduced in
this report block for calculating the pre-repair loss count during 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 this range, so that the RTP sender or a third-party entity is able to
able to evaluate the effectiveness of the repair methods used by the evaluate the effectiveness of the repair methods used by the system.
system. The metrics defined in this document are packet level rather The metrics defined in this document are packet level rather than
than slice/picture level, which means the partial recovery of a slice/picture level, which means the partial recovery of a packet
packet will not be regarded as a repaired packet. will not be regarded as a repaired packet.
The metrics defined in this document belong to the class of The metrics defined in this document belong to the class of
transport-related metrics defined in [RFC6792] and are specified 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",
skipping to change at page 4, line 16 skipping to change at page 4, line 16
primary source RTP packet: The original RTP packet sent from the RTP primary source RTP packet: The original RTP packet sent from the RTP
sender for the first time. A lost primary source RTP packet may be sender for the first time. A lost primary source RTP packet may be
repaired by some other RTP packets used in repair mechanisms like FEC repaired by some other RTP packets used in repair mechanisms like FEC
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 The sender of this XR report can ensure it match the SR/RR packet
RTCP packets and share the average reporting interval calculated by sent in the same compound RTCP packet. 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 the current noted in [RFC5725]: Some packets will not be repaired in the current
RTCP interval, but could be repaired later. RTCP interval, but could be repaired later.
Thus it is RECOMMENDED that this report block should be generated Accordingly, only packets that have no further chance of being
only for those source packets that have no further chance of being repaired are included in this report block. This block needs to
repaired and not for any other packets. This block needs to specify specify its own measurement period to avoid ambiguity in calculating
its own measurement period to avoid ambiguity in calculating the the post-repair loss count.
post-repair loss count.
The sequence number range reported by RTCP SR/RR may contain some The sequence number range reported by RTCP SR/RR may contain some
sequence numbers of packets for which repair might still be possible. sequence numbers of packets for which repair might still be possible.
To avoid the ambiguity, we use begin sequence number and end sequence To avoid the ambiguity, we use begin sequence number and end sequence
number to explicitly indicate the actual sequence number range that number to explicitly indicate the actual sequence number range that
this RTCP XR report block reports on as the measurement timing. These this RTCP XR report block reports on as the measurement timing. These
metrics defined in this report block are all interval metrics and the metrics defined in this report block are all measured at the RTP
measurement of them is made at the RTP receiver. The relationship receiver. The relationship between the metrics in this report block
between the metrics in this report block and the pre-repair loss and the pre-repair loss metric of RTCP RR could be expressed in the
metric of RTCP XR could be expressed in the following formula: following formula:
cumulative number of packets lost = post-repair loss count + still to be repaired lost packet = cumulative number of packets
repaired loss count + to be repaired lost packet lost - cumulative post-repair loss count - cumulative repaired
loss count
"cumulative number of packets lost" is the metric from RTCP SR/RR. "cumulative number of packets lost" is the metric from RTCP SR/RR.
"post-repair loss count" and "repaired loss count" are the metrics "cumulative post-repair loss count" and "cumulative repaired loss
defined in this draft. count" could be obtained by the way introduced in the end of this
section.
It is also possible to send this XR report block and SR/RR with
different intervals, in which case the "cumulative number of packets
lost" can't be easily compared with the post-repair metrics defined
in this draft. However, the endpoint could rely on the post-repair
loss count and repaired loss count to calculate the efficiency of the
error resilience algorithm.
3.1 Report Block Structure
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 |
skipping to change at page 5, line 39 skipping to change at page 5, line 48
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 first sequence number that this block reports on. The first sequence number that this block reports on. It can
remain fixed when calculating metrics over several RTCP reporting
intervals.
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.
post-repair loss count: 16 bits post-repair loss count: 16 bits
Total number of packets finally lost after applying one or more Total number of packets finally lost after applying one or more
loss-repair methods, e.g., FEC and/or retransmission, during the loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq. actual sequence number range indicated by begin_seq and end_seq.
skipping to change at page 6, line 14 skipping to change at page 6, line 26
source RTP packets. source RTP packets.
repaired loss count: 16 bits repaired loss count: 16 bits
Total number of packets fully repaired after applying one or more Total number of packets fully repaired after applying one or more
loss-repair methods, e.g., FEC and/or retransmission, during the loss-repair methods, e.g., FEC and/or retransmission, during the
actual sequence number range indicated by begin_seq and end_seq. actual sequence number range indicated by begin_seq and end_seq.
Note that this metric MUST measure only primary source RTP Note that this metric MUST measure only primary source RTP
packets. packets.
3.2 Report Block Example Usage
This block could be reported by the endpoint in 2 different ways:
1. Cumulative report
In this case, implementations may set begin_seq to the first packet
in the RTP session and it will remain fixed across all reports. In
this case the "post-repair loss count" and "repaired loss count"
respectively will correspond to "cumulative post-repair loss count"
and "cumulative repaired loss count" in this case.
2. Interval report
Some implementations may align the begin_seq and end_seq number with
the last RTCP interval. If the reports are consecutive and there is
no sequence number range overlap or RTCP XR packets loss, "cumulative
post-repair loss count" and "cumulative repaired loss count" can be
respectively calculated by sum of "post-repair loss count" and by sum
of "repaired loss count".
Alternatively, for providing better robustness against packet loss,
implementations may choose begin_seq and end_seq numbers covering
several RTCP intervals.
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
5.1 of [RFC3611] by providing an additional value of "xr-format" to 5.1 of [RFC3611] by providing an additional value of "xr-format" to
skipping to change at page 9, line 4 skipping to change at page 9, line 34
RTP Monitoring Framework", RFC 6792, November 2012. RTP Monitoring Framework", RFC 6792, November 2012.
[RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP [RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP
Sessions", RFC 7201, April 2014. Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP
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. Post-Repair RTP Packet Loss Count Metric a. Post-Repair RTP Packet Loss Count Metric
* Metric Name: Post-Repair RTP Packet Loss Count Metric. * Metric Name: Post-Repair 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: See section 3, Post-Repair * Method of Measurement or Calculation: See section 3.1, Post-
RTP Packet Loss Count Metric definition. It is directly measured Repair RTP Packet Loss Count Metric definition. It is directly
and must be measured for the primary source RTP packets with no measured and must be measured for the primary source RTP packets
further chance of repair. with no further chance of repair.
* Units of Measurement: This metric is expressed as a 16-bit * Units of Measurement: This metric is expressed as a 16-bit
unsigned integer value giving the number of RTP packets. unsigned integer value giving the number of RTP packets.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: This metric relies on the sequence number * Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing. See Section 3, 1st interval to determine measurement timing. See Section 3, 3rd
paragraph, for details. paragraph, for details.
* Use and Applications: These metrics are applicable to any RTP * Use and Applications: These metrics are applicable to any RTP
application, especially those that use loss repair mechanisms. See application, especially those that use loss repair mechanisms. See
Section 1 for details. Section 1 for details.
* 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: See section 3, Repaired * Method of Measurement or Calculation: See section 3.1, Repaired
RTP Packet Loss Count Metric definition. It is directly measured RTP Packet Loss Count Metric definition. It is directly measured
and must be measured for the primary source RTP packets with no and must be measured for the primary source RTP packets with no
further chance of repair. further chance of repair.
* Units of Measurement: This metric is expressed as a 16-bit * Units of Measurement: This metric is expressed as a 16-bit
unsigned integer value giving the number of RTP packets. unsigned integer value giving the number of RTP packets.
* Measurement Point(s) with Potential Measurement Domain: It is * Measurement Point(s) with Potential Measurement Domain: It is
measured at the receiving end of the RTP stream. measured at the receiving end of the RTP stream.
* Measurement Timing: This metric relies on the sequence number * Measurement Timing: This metric relies on the sequence number
interval to determine measurement timing. See Section 3, 1st interval to determine measurement timing. See Section 3, 3rd
paragraph, for details. paragraph, for details.
* Use and Applications: These metrics are applicable to any RTP * Use and Applications: These metrics are applicable to any RTP
application, especially those that use loss repair mechanisms. See application, especially those that use loss repair mechanisms. See
Section 1 for details. Section 1 for details.
* Reporting Model: See RFC3611. * Reporting Model: See RFC3611.
Authors' Addresses Authors' Addresses
 End of changes. 20 change blocks. 
44 lines changed or deleted 85 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/