draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-09.txt   draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10.txt 
INTERNET-DRAFT R. Huang INTERNET-DRAFT R. Huang
Intended Status: Standards Track Huawei Intended Status: Standards Track Huawei
Expires: July 25, 2015 V. Singh Expires: August 19, 2015 V. Singh
Aalto University Aalto University
January 21, 2015 February 15, 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-09 draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10
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 during this rage. 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
repair methods used by the system.
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 20 skipping to change at page 2, line 21
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.1 Report Block Structure . . . . . . . . . . . . . . . . . . 4
3.2 Report Block Example Usage . . . . . . . . . . . . . . . . 6 3.2 Example Usage . . . . . . . . . . . . . . . . . . . . . . . 5
4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 7 4.1 SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . 8 6.2 New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . 9 8.2 Informative References . . . . . . . . . . . . . . . . . . 8
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 4, line 15 skipping to change at page 4, line 15
document are to be interpreted as described in [KEYWORDS]. 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 (e.g., FEC). It complements the RTCP XR metrics defined
The sender of this XR report can ensure it match the SR/RR packet in [RFC5725]. As noted in [RFC5725], ambiguity may occur when
sent in the same compound RTCP packet. When comparing this metric comparing this metric with pre-repair loss metric reported in an RTCP
with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as SR/RR, i.e., some packets were not repaired in the current RTCP
noted in [RFC5725]: Some packets will not be repaired in the current interval, but they may be repaired later. Therefore, this block uses
RTCP interval, but could be repaired later. a begin sequence number and an end sequence number to explicitly
indicate the actual sequence number range reported by this RTCP XR.
Accordingly, only packets that have no further chance of being Accordingly, only packets that have no further chance of being
repaired are included in this report block. This block needs to repaired and that have been repaired are included in this report
specify its own measurement period to avoid ambiguity in calculating block.
the post-repair loss count.
The sequence number range reported by RTCP SR/RR may contain some
sequence numbers of packets for which repair might still be possible.
To avoid the ambiguity, 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 measured at the RTP
receiver. The relationship between the metrics in this report block
and the pre-repair loss metric of RTCP RR could be expressed in the
following formula:
still to be repaired lost packet = cumulative number of packets
lost - cumulative post-repair loss count - cumulative repaired
loss count
"cumulative number of packets lost" is the metric from RTCP SR/RR.
"cumulative post-repair loss count" and "cumulative repaired loss
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 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 |
skipping to change at page 6, line 26 skipping to change at page 5, line 47
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 3.2 Example Usage
This block could be reported by the endpoint in 2 different ways: The metrics defined in this report block are all measured at the RTP
receiver. However, the receiving endpoint can report the metrics in
two different ways:
1. Cumulative report 1. Cumulative report
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 in the RTP session and it will remain fixed across all reports.
this case 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. and "cumulative repaired loss count" in this case. These cumulative
metrics when combined with the cumulative loss metrics reported in an
RTCP RR (pre-repair) assists in calculating the still to be repaired
lost packets:
in 6 still to be repaired lost packet = cumulative number of packets
lost - cumulative post-repair loss count - cumulative repaired 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 last RTCP interval. If the reports are consecutive and there is the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
no sequence number range overlap or RTCP XR packets loss, "cumulative This is NOT RECOMMENDED as packets that are not yet repaired in this
post-repair loss count" and "cumulative repaired loss count" can be current RTCP interval and may repaired in the future will not be
respectively calculated by sum of "post-repair loss count" and by sum reported in subsequent reports.
of "repaired loss count".
Alternatively, for providing better robustness against packet loss, Alternatively, implementations may choose the begin_seq and end_seq
implementations may choose begin_seq and end_seq numbers covering numbers that cover several RTCP intervals. Additionally, the reported
several RTCP intervals. range of sequence numbers may overlap with the previous report
blocks, so that the packets that were not yet repaired in one
interval but were subsequently repaired or deemed unrepairable were
reported in subsequent intervals.
In this case, the "cumulative number of packets lost" cannot be
easily compared with the post-repair metrics. However, the sending
endpoint can calculate the efficiency of the error resilience
algorithm using the post-repair and repaired lost count,
respectively.
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
 End of changes. 16 change blocks. 
58 lines changed or deleted 50 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/