draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03.txt   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-04.txt 
INTERNET-DRAFT R. Huang INTERNET-DRAFT R. Huang
Intended Status: Standard Huawei Intended Status: Standard Huawei
Expires: October 10, 2014 V. Singh Expires: December 25, 2014 V. Singh
Aalto University Aalto University
April 8, 2014 June 23, 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-03 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-04
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 2, line 15 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4 3 Post-Repair Loss Count Metrics Report Block . . . . . . . . . . 4
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . 6 6.1 New RTCP XR Block Type value . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
cost of higher overhead. When applications use multiple XR blocks, cost of higher overhead. When applications use multiple XR blocks,
the endpoints may require more 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 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. When comparing this metric with pre-repair loss repaired packet. In addition, another metric, repaired loss count,
metric of RTCP SR/RR, ambiguity may occur as noted in [RFC5725]: Some is also introduced in this report block for calculating the pre-
packets will not be repaired in current RTCP interval. Thus it is repair loss count during the this range, so that the RTP sender or a
RECOMMENDED that this report block should be generated for those third-party entity is able to evaluate the effectiveness of the
source packets that have no further chance of being repaired. But a repair methods used by the system. Note that the metrics in this
potential ambiguity may result from sequence number range report block MUST NOT be directly compared with the pre-repair loss
inconsistent. The sequence number range reported by RTCP SR/RR may metric of [RFC3550].
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 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 [KEYWORDS].
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 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]. These metrics defined in this the RTCP method described in [RFC3550]. When comparing this metric
report block are all interval metrics with an explicit sequence with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as
number range to indicate the measurement timing and the measurement noted in [RFC5725]: Some packets will not be repaired in current RTCP
of them is made at the RTP receiver. 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 as
the measurement timing. These metrics defined in this report block
are all interval metrics and the measurement of them is made at the
RTP receiver. The relationship between the 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 +
repaired loss count + to be repaired lost packet
"cumulative number of packets lost" is the metric from RTCP SR/RR.
"unrepaired loss count" and "repaired loss count" are the metrics
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:
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 6, line 32 skipping to change at page 6, line 40
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
mechanisms. Implementers should consider the guidance in [I-D.ietf- mechanisms. Implementers should consider the guidance in [RFC7202]
avtcore-srtp-not-mandatory] for using appropriate security for using appropriate security mechanisms, i.e., where security is a
mechanisms, i.e., where security is a concern, the implementation concern, the implementation should apply encryption and
should apply encryption and authentication to the report block. For authentication to the report block. For example, this can be achieved
example, this can be achieved by using the AVPF profile together with by using the AVPF profile together with the Secure RTP profile as
the Secure RTP profile as defined in [RFC3711]; an appropriate defined in [RFC3711]; an appropriate combination of the two profiles
combination of the two profiles (an "SAVPF") is specified in (an "SAVPF") is specified in [RFC5124]. However, other mechanisms
[RFC5124]. However, other mechanisms also exist (documented in [I- also exist (documented in [RFC7201]) and might be more suitable.
D.ietf-avtcore-rtp-security-options]) and might be more suitable.
6 IANA Considerations 6 IANA Considerations
New block types for RTCP XR are subject to IANA registration. For New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to general guidelines on IANA considerations for RTCP XR, refer to
[RFC3611]. [RFC3611].
6.1 New RTCP XR Block Type value 6.1 New RTCP XR Block Type value
This document assigns the block type value PRLR in the IANA "RTP This document assigns the block type value PRLR in the IANA "RTP
Control Protocol Extended Reports (RTCP XR) Block Type Registry" to Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
the "Post-Repair Loss Count Metrics Report Block". the "Post-Repair Loss Count Metrics Report Block".
skipping to change at page 8, line 15 skipping to change at page 8, line 23
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error [RFC5109] Li, A., Ed., "RTP Payload Format for Generic Forward Error
Correction", RFC 5109, December 2007. Correction", RFC 5109, December 2007.
[RFC7201] Westerlund, M. and C., Perkins, "Qptions for Securing RTP
Sessions", RFC 7201, April 2014.
[RFC7202] Perkins, C. and M., Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, April 2014.
8.2 Informative References 8.2 Informative References
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
October 2011. October 2011.
[RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
RTP Monitoring Framework", RFC 6792, November 2012. RTP Monitoring Framework", RFC 6792, November 2012.
Appendix A. Metrics Represented Using the Template from RFC 6390 Appendix A. Metrics Represented Using the Template from RFC 6390
 End of changes. 12 change blocks. 
38 lines changed or deleted 52 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/