draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10.txt   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11.txt 
INTERNET-DRAFT R. Huang INTERNET-DRAFT R. Huang
Intended Status: Standards Track Huawei Intended Status: Standards Track Huawei
Expires: August 19, 2015 V. Singh Expires: August 23, 2015 V. Singh
Aalto University Aalto University
February 15, 2015 February 19, 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-10 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-11
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 metric for (XR) Block that allows reporting of post-repair loss count metric for
a range of RTP applications. In addition, another metric, repaired a range of RTP applications. In addition, another metric, repaired
loss count, is also introduced in this report block for calculating loss count, is also introduced in this report block for calculating
the pre-repair loss count when needed so that the RTP sender or a the pre-repair loss count when needed 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.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . . . 4 3.1 Report Block Structure . . . . . . . . . . . . . . . . . . 4
3.2 Example Usage . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Example Usage . . . . . . . . . . . . . . . . . . . . . . . 5
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 7
4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 7 4.2 Offer/Answer Usage . . . . . . . . . . . . . . . . . . . . 7
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . 8 6.3 Contact Information for registrations . . . . . . . . . . . 8
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References . . . . . . . . . . . . . . . . . . . 8 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 . 9 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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
In this case, implementations may set begin_seq to the first packet 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 the RTP session and it will remain fixed across all reports.
Hence, the "post-repair loss count" and "repaired loss count", Hence, the "post-repair loss count" and "repaired loss count",
respectively will correspond to "cumulative post-repair loss count" respectively will correspond to "cumulative post-repair loss count"
and "cumulative repaired loss count" in this case. These cumulative and "cumulative repaired loss count" in this case. These cumulative
metrics when combined with the cumulative loss metrics reported in an metrics when combined with the cumulative loss metrics reported in an
RTCP RR (pre-repair) assists in calculating the still to be repaired RTCP RR (pre-repair) assists in calculating the still to be repaired
lost packets: lost packets:
in 6 still to be repaired lost packet = cumulative number of packets still to be repaired lost packet = cumulative number of packets
lost - cumulative post-repair loss count - cumulative repaired loss lost - cumulative post-repair loss count - cumulative repaired
count loss count
2. Interval report 2. Interval report
Some implementations may align the begin_seq and end_seq number with Some implementations may align the begin_seq and end_seq number with
the highest sequence numbers of consecutive RTCP RRs (RTCP interval). the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
This is NOT RECOMMENDED as packets that are not yet repaired in this This is NOT RECOMMENDED as packets that are not yet repaired in this
current RTCP interval and may repaired in the future will not be current RTCP interval and may be repaired in the subsequent intervals
reported in subsequent reports. will not be reported. It is illustrated in the following example:
Interval A: The extended highest sequence number received in RTCP
RR is 20. Begin_seq is 10 and end_seq is 20.
Interval B: The extended highest sequence number received in RTCP
RR is 30. Begin_seq is 20 and end_seq is 30.
If packets 17 and 19 are lost and not yet repaired in interval A and
subsequently repaired in interval B, they will not then be reported
because their sequence numbers do not belong in the interval B.
Therefore, if implementations want these packets to be reported as
repaired, they MUST NOT align the begin_seq and end_seq to the RTCP
intervals.
Alternatively, implementations may choose the begin_seq and end_seq Alternatively, implementations may choose the begin_seq and end_seq
numbers that cover several RTCP intervals. Additionally, the reported numbers that cover several RTCP intervals. Additionally, the reported
range of sequence numbers may overlap with the previous report range of sequence numbers may overlap with the previous report
blocks, so that the packets that were not yet repaired in one blocks, so that the packets that were not yet repaired in one
interval but were subsequently repaired or deemed unrepairable were interval but were subsequently repaired or deemed unrepairable were
reported in subsequent intervals. reported in subsequent intervals.
In this case, the "cumulative number of packets lost" cannot be In this case, the "cumulative number of packets lost" cannot be
easily compared with the post-repair metrics. However, the sending easily compared with the post-repair metrics. However, the sending
 End of changes. 8 change blocks. 
12 lines changed or deleted 25 lines changed or added

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