draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01.txt   draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02.txt 
XR Block Working Group V. Singh, Ed. XR Block Working Group V. Singh, Ed.
Internet-Draft J. Ott Internet-Draft J. Ott
Intended status: Standards Track Aalto University Intended status: Standards Track Aalto University
Expires: May 08, 2014 I. Curcio Expires: August 30, 2014 I. Curcio
Nokia Research Center Nokia Research Center
November 04, 2013 February 26, 2014
RTP Control Protocol (RTCP) Extended Report (XR) for Bytes Discarded RTP Control Protocol (RTCP) Extended Report (XR) for Bytes Discarded
Metric Metric
draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-02
Abstract Abstract
The RTP Control Protocol (RTCP) is used in conjunction with the Real- The RTP Control Protocol (RTCP) is used in conjunction with the Real-
time Transport Protocol (RTP) in to provide a variety of short-term time Transport Protocol (RTP) in to provide a variety of short-term
and long-term reception statistics. The available reporting may and long-term reception statistics. The available reporting may
include aggregate information across longer periods of time as well include aggregate information across longer periods of time as well
as individual packet reporting. This document specifies a report as individual packet reporting. This document specifies a report
computing the bytes discarded from the de-jitter buffer after computing the bytes discarded from the de-jitter buffer after
successful reception. successful reception.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 08, 2014. This Internet-Draft will expire on August 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. XR Bytes Discarded Report Block . . . . . . . . . . . . . . . 4 3. XR Bytes Discarded Report Block . . . . . . . . . . . . . . . 4
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 5
4.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 5 4.1. Reporting Node (Receiver) . . . . . . . . . . . . . . . . 5
4.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Media Sender . . . . . . . . . . . . . . . . . . . . . . 6
5. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SDP signaling . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7.1. XR Report Block Registration . . . . . . . . . . . . . . 7 7.1. XR Report Block Registration . . . . . . . . . . . . . . 8
7.2. SDP Parameter Registration . . . . . . . . . . . . . . . 7 7.2. SDP Parameter Registration . . . . . . . . . . . . . . . 8
7.3. Contact information for IANA registrations . . . . . . . 8 7.3. Contact information for IANA registrations . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Metrics represented using RFC6390 Template . . . . . 9 Appendix A. Metrics represented using RFC6390 Template . . . . . 10
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 10
B.1. changes in draft-singh-xrblock-rtcp-xr-bytes- B.1. changes in draft-singh-xrblock-rtcp-xr-bytes-
discarded-metric-00 . . . . . . . . . . . . . . . . . . . 10
B.2. changes in draft-ietf-xrblock-rtcp-xr-bytes-
discarded-metric-00 . . . . . . . . . . . . . . . . . . . 10
B.3. changes in draft-ietf-xrblock-rtcp-xr-bytes-
discarded-metric-01 . . . . . . . . . . . . . . . . . . . 10 discarded-metric-01 . . . . . . . . . . . . . . . . . . . 10
B.2. changes in draft-singh-xrblock-rtcp-xr-bytes-
discarded-metric-00 . . . . . . . . . . . . . . . . . . . 11
B.3. changes in draft-ietf-xrblock-rtcp-xr-bytes-
discarded-metric-00 . . . . . . . . . . . . . . . . . . . 11
B.4. changes in draft-ietf-xrblock-rtcp-xr-bytes-
discarded-metric-01 . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
RTP [RFC3550] provides a transport for real-time media flows such as RTP [RFC3550] provides a transport for real-time media flows such as
audio and video together with the RTP control protocol (RTCP) which audio and video together with the RTP control protocol (RTCP), which
provides periodic feedback about the media streams received in a provides periodic feedback about the media streams received in a
specific duration. In addition, RTCP can be used for timely feedback specific duration. In addition, RTCP can be used for timely feedback
about individual events to report (e.g., packet loss) [RFC4585]. about individual events to report (e.g., packet loss) [RFC4585].
Both long-term and short-term feedback enable a media sender to adapt Both long-term and short-term feedback enable a media sender to adapt
its media transmission and/or encoding dynamically to the observed its media transmission and/or encoding dynamically to the observed
path characteristics. path characteristics.
RFC3611 [RFC3611] defines RTCP Extended Reports as a detailed [RFC3611] defines RTCP Extended Reports as a detailed reporting
reporting framework to provide more than just the coarse Receiver framework to provide more than just the coarse Receiver Report (RR)
Report (RR) statistics. The detailed reporting may enable a media statistics. The detailed reporting may enable a media sender to
sender to react more appropriately to the observed networking react more appropriately to the observed networking conditions as
conditions as these can be characterized better, although at the these can be characterized better, although at the expense of extra
expense of extra overhead. overhead.
In addition to lost packets, RFC3611 defines the notion of In addition to lost packets, [RFC3611] defines the notion of
"discarded" packets: packets that were received but dropped from the "discarded" packets: packets that were received but dropped from the
de-jitter buffer because they were either too early (for buffering) de-jitter buffer because they were either too early (for buffering)
or too late (for playout). The "discard rate" metric is part of the or too late (for playout). The "discard rate" metric is part of the
VoIP metrics report block even though it is not just applicable to VoIP metrics report block even though it is not just applicable to
audio: it is specified as the fraction of discarded packets since the audio: it is specified as the fraction of discarded packets since the
beginning of the session. See section 4.7.1 of RFC3611 [RFC3611]. beginning of the session. See section 4.7.1 of [RFC3611]. The
The discard metric is believed to be applicable to a large class of discard metric is believed to be applicable to a large class of RTP
RTP applications which use a de-jitter buffer RFC5481 [RFC5481]. applications which use a de-jitter buffer [RFC5481].
Recently proposed extensions to the Extended Reports (XR) reporting Recently proposed extensions to the Extended Reports (XR) reporting
suggest enhancing this discard metric: suggest enhancing the discard metric:
o Reporting the number of discarded packets in a measurement o Reporting the number of discarded packets in a measurement
interval, i.e., during either the last reporting interval or since interval, i.e., during either the last reporting interval or since
the beginning of the session, as indicated by a flag in the the beginning of the session, as indicated by a flag in the
suggested XR report [RFC7002]. If an endpoint needs to report suggested XR report [RFC7002]. If an endpoint needs to report
packet discard due to other reasons than early- and late-arrival packet discard due to other reasons than early- and late-arrival
(for example, discard due to duplication, redundancy, etc.) then (for example, discard due to duplication, redundancy, etc.) then
it should consider using the Discarded Packets Report Block it should consider using the Discarded Packets Report Block
[RFC7002]. [RFC7002].
o Reporting gaps and bursts of discarded packets during a o Reporting gaps and bursts of discarded packets during a
measurement interval, i.e., the last reporting interval or the measurement interval, i.e., the last reporting interval or the
duration of the session [RFC7003]. duration of the session [RFC7003].
o Reporting run-length encoding of discarded packet during a o Reporting run-length encoding of discarded packet during a
measurement interval, i.e., between a set of sequence numbers measurement interval, i.e., between a set of sequence numbers
[I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics]. [RFC7097].
However, none of these metrics allow a receiver to report precisely However, none of these metrics allow a receiver to report precisely
the number of RTP payload bytes that were discarded. While this the number of RTP payload bytes that were discarded. While this
information could in theory be derived from high-frequency reporting information could in theory be derived from high-frequency reporting
on the number of discarded packets [RFC7002] or from the Discard RLE on the number of discarded packets [RFC7002] or from the Discard RLE
report [I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics], these two report [RFC7097], these two mechanisms do not appear feasible; the
mechanisms do not appear feasible: The former would require an unduly former would require an unduly high amount of reporting which still
high amount of reporting which still might not be sufficient due to might not be sufficient due to the non-deterministic scheduling of
the non-deterministic scheduling of RTCP packets. The latter incurs RTCP packets. The latter incurs significant complexity (by storing a
significant complexity (by storing a map of sequence numbers and map of sequence numbers and packet sizes) and reporting overhead.
packet sizes) and reporting overhead.
An XR block is defined in this document to indicate the number of RTP An XR block is defined in this document to indicate the number of RTP
payload bytes discarded, per interval or for the duration of the payload bytes discarded, per interval or for the duration of the
session, similar to other XR report blocks. session, similar to the other XR report blocks.
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 BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, [RFC2119].
[RFC2119].
The terminology defined in RTP [RFC3550] and in the extensions for XR The terminology defined in RTP [RFC3550] and in the extensions for XR
reporting [RFC3611] applies. reporting [RFC3611] applies.
3. XR Bytes Discarded Report Block 3. XR Bytes Discarded Report Block
The XR Bytes Discarded report block uses the following format which The XR Bytes Discarded report block uses the following format which
follows the model of the framework for performance metric development follows the model of the framework for performance metric development
[RFC6390]. [RFC6390].
skipping to change at page 5, line 29 skipping to change at page 5, line 32
The 'number of RTP payload bytes discarded' is a 32-bit unsigned The 'number of RTP payload bytes discarded' is a 32-bit unsigned
integer value indicating the total number of bytes discarded. Bytes integer value indicating the total number of bytes discarded. Bytes
discarded corresponds to the RTP payload size of every RTP packet discarded corresponds to the RTP payload size of every RTP packet
that is discarded (due to early or late arrival). Hence, the bytes that is discarded (due to early or late arrival). Hence, the bytes
discarded ignores the size of any RTP header extensions and the size discarded ignores the size of any RTP header extensions and the size
of the padding bits. Also the discarded packet is associated to the of the padding bits. Also the discarded packet is associated to the
interval in which it was discarded and not when it was expected. interval in which it was discarded and not when it was expected.
If Interval Metric flag (I=11) is set, the value in the field If Interval Metric flag (I=11) is set, the value in the field
indicates the number of RTP payload bytes discarded from the start of indicates the number of RTP payload bytes discarded from the start of
the session, if Interval Metric flag (I=01) is set, it indicates the the session, if Interval Metric flag (I=10) is set, it indicates the
number of bytes discarded since the last RTCP XR Byte Discarded Block number of bytes discarded in the most recent reporting interval.
was received.
If the XR block follows a measurement identity block [RFC6776] in the If the XR block follows a measurement identity block [RFC6776] in the
same RTCP compound packet then the cumulative (I=11) or the interval same RTCP compound packet then the cumulative (I=11) or the interval
(I=10) for this report block corresponds to the values of the (I=10) for this report block corresponds to the values of the
"measurement duration" in the measurement information block. "measurement duration" in the measurement information block.
If the receiver sends the Bytes Discarded Report Block without the If the receiver sends the Bytes Discarded Report Block without the
measurement identity block then the discard block MUST be sent in measurement identity block then the discard block MUST be sent in
conjunction with an RTCP Receiver Report (RR) as a compound RTCP conjunction with an RTCP Receiver Report (RR) as a compound RTCP
packet. packet.
4. Protocol Operation 4. Protocol Operation
This section describes the behavior of the reporting node (= media This section describes the behavior of the reporting node (= media
receiver) and the media sender. receiver) and the media sender.
4.1. Reporting Node (Receiver) 4.1. Reporting Node (Receiver)
The media receiver MAY send the Bytes Discard Reports as part of the
regularly scheduled RTCP packets as per RFC3550. It MAY also include
Bytes Discard Reports in immediate or early feedback packets as per
[RFC4585].
Transmission of RTCP XR Bytes Discarded Report is up to the Transmission of RTCP XR Bytes Discarded Report is up to the
discretion of the media receiver, as is the reporting granularity. discretion of the media receiver, as is the reporting granularity.
However, it is RECOMMENDED that the media receiver signals the bytes
discarded packets using the method defined in this document. When
reporting several metrics in a single RTCP packet, the reporting
intervals for the report blocks are synchronized, therefore the media
receiver may choose to additionally send the Discarded Packets
[RFC7002] or Discard RLE [RFC7097] Report Block to assist the media
sender in correlating the bytes discarded to the packets discarded in
that particular interval.
However, it is RECOMMENDED that the media receiver signals all If all packets over a reporting period were discarded, the media
discarded packets using the method defined in this document. If all receiver MAY use the Discarded Packets Report Block [RFC7002]
packets over a reporting period were discarded, the media receiver instead.
MAY use the Discard Report Block [RFC7002] instead.
The media receiver MAY send the Bytes Discard Reports as part of the
regularly scheduled RTCP packets as per RFC3550. It MAY also include
Bytes Discard Reports in immediate or early feedback packets as per
RFC4585.
4.2. Media Sender 4.2. Media Sender
The media sender MUST be prepared to operate without receiving any The media sender MUST be prepared to operate without receiving any
Bytes Discarded reports. If Bytes Discarded reports are generated by Bytes Discarded reports. If Bytes Discarded reports are generated by
the media receiver, the media sender cannot rely on all these reports the media receiver, the media sender cannot rely on all these reports
being received, nor can the media sender rely on a regular generation being received, nor can the media sender rely on a regular generation
pattern from the media receiver. pattern from the media receiver.
However, if the media sender receives any RTCP reports but no Bytes However, if the media sender receives any RTCP reports but no Bytes
Discard report blocks and is aware that the media receiver supports Discard report blocks and is aware that the media receiver supports
Bytes Discard report blocks, it MAY assume that no packets were Bytes Discard report blocks, it MAY assume that no packets were
discarded at the media receiver. discarded by the media receiver.
The media sender SHOULD accept the Bytes Discarded Report Block only The media sender SHOULD accept the Bytes Discarded Report Block only
if it is received in a compound RTCP receiver report or if it is if it is received in a compound RTCP receiver report or if it is
preceded by a measurement identity block [RFC6776]. Under all other preceded by a measurement identity block [RFC6776]. Under all other
circumstances it MUST ignore the block. circumstances it MUST ignore the block.
5. SDP signaling 5. SDP signaling
A participant of a media session MAY use SDP to signal its support A participant of a media session MAY use SDP to signal its support
for the report block specified in this document or use them without for the report block specified in this document or use them without
skipping to change at page 7, line 19 skipping to change at page 7, line 26
[RFC3611] for unilateral "rtcp-xr" attribute parameters applies (see [RFC3611] for unilateral "rtcp-xr" attribute parameters applies (see
section 5.2 of [RFC3611]). section 5.2 of [RFC3611]).
6. Security Considerations 6. Security Considerations
The Bytes Discarded block does not provide per-packet statistics, The Bytes Discarded block does not provide per-packet statistics,
hence the risk to confidentiality documented in Section 7, paragraph hence the risk to confidentiality documented in Section 7, paragraph
3 of [RFC3611] does not apply. In some situations, returning very 3 of [RFC3611] does not apply. In some situations, returning very
detailed error information (e.g., over-range measurement or detailed error information (e.g., over-range measurement or
measurement unavailable) using this report block can provide an measurement unavailable) using this report block can provide an
attacker with insight into the security processing. Implementers attacker with insight into the security processing. For example,
should consider the guidance in [I-D.ietf-avt-srtp-not-mandatory] for assume that the attacker sends a packet with a stale timestamp (i.e.,
using appropriate security mechanisms, i.e., where security is a time in the past) to the receiver. If the receiver now sends a
concern, the implementation should apply encryption and discard report with the same number of bytes as the payload of the
authentication to the report block. For example this can be achieved injected packet, the attacker can infer that no security processing
by using the AVPF profile together with the Secure RTP profile as was performed. If, on the other hand, the attacker does not receive
defined in [RFC3711]; an appropriate combination of the two profiles a discard report, it can equivalently assume that the security
(an "SAVPF") is specified in [RFC5124]. However, other mechanisms procedures were performed on the packet.
also exist (documented in [I-D.ietf-avtcore-rtp-security-options])
and might be more suitable.
Additionally, The security considerations of [RFC3550], [RFC3611], Implementers should therefore consider the guidance in
and [RFC4585] apply. [I-D.ietf-avt-srtp-not-mandatory] for using appropriate security
mechanisms, i.e., where security is a concern, the implementation
should apply encryption and authentication to the report block. For
example this can be achieved by using the AVPF profile together with
the Secure RTP profile as defined in [RFC3711]; an appropriate
combination of the two profiles (an "SAVPF") is specified in
[RFC5124]. However, other mechanisms also exist (documented in
[I-D.ietf-avtcore-rtp-security-options]) and might be more suitable.
The discarded bytes report is employed by the sender to perform
congestion control, typically, for calculating goodput. In these
cases an attacker MAY drive the endpoint to lower its sending rate
and under-utilised the link, therefore media senders should choose
appropriate security measures to mitigate such attacks.
Lastly, the security considerations of [RFC3550], [RFC3611], and
[RFC4585] apply.
7. IANA Considerations 7. 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].
7.1. XR Report Block Registration 7.1. XR Report Block Registration
This document extends the IANA "RTP Control Protocol Extended Reports This document extends the IANA "RTP Control Protocol Extended Reports
skipping to change at page 8, line 9 skipping to change at page 8, line 33
7.2. SDP Parameter Registration 7.2. SDP Parameter Registration
This document registers a new parameters for the Session Description This document registers a new parameters for the Session Description
Protocol (SDP), "discard-bytes" in the "RTP Control Protocol Extended Protocol (SDP), "discard-bytes" in the "RTP Control Protocol Extended
Reports (RTCP XR) Session Description Protocol (SDP) Parameters Reports (RTCP XR) Session Description Protocol (SDP) Parameters
Registry". Registry".
7.3. Contact information for IANA registrations 7.3. Contact information for IANA registrations
Varun Singh (varun.singh@iki.fi) RAI Area Directors: rai-ads@tools.ietf.org
Aalto University Comnet, Otakaari 5A, 02150 Espoo, Finland.
8. Acknowledgments 8. Acknowledgments
The authors would like to thank Alan Clark, Roni Even, Sam Hartman, The authors would like to thank Alan Clark, Benoit Claise, Roni Even,
Colin Perkins, Dan Romascanu, Dan Wing, and Qin Wu for providing Vijay Gurbani, Sam Hartman, Vinayak Hegde, Jeffrey Hutzelman, Barry
valuable feedback on earlier versions of this draft. Leiba, Colin Perkins, Dan Romascanu, Dan Wing, and Qin Wu for
providing valuable feedback on earlier versions of this draft.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] 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 9, line 15 skipping to change at page 9, line 35
[RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol [RFC7002] Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Discard Count Metric (RTCP) Extended Report (XR) Block for Discard Count Metric
Reporting", RFC 7002, September 2013. Reporting", RFC 7002, September 2013.
9.2. Informative References 9.2. Informative References
[RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Burst/Gap Discard (RTCP) Extended Report (XR) Block for Burst/Gap Discard
Metric Reporting", RFC 7003, September 2013. Metric Reporting", RFC 7003, September 2013.
[I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics] [RFC7097] Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol
Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol (RTCP) Extended Report (XR) for RLE of Discarded Packets",
(RTCP) Extended Reports (XR) for Run Length Encoding (RLE) RFC 7097, January 2014.
of Discarded Packets", draft-ietf-xrblock-rtcp-xr-discard-
rle-metrics-06 (work in progress), July 2013.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, March 2009. Applicability Statement", RFC 5481, March 2009.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
[I-D.ietf-avt-srtp-not-mandatory] [I-D.ietf-avt-srtp-not-mandatory]
Perkins, C. and M. Westerlund, "Securing the RTP Protocol Perkins, C. and M. Westerlund, "Securing the RTP Protocol
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", draft-ietf-avt-srtp-not-mandatory-13 Security Solution", draft-ietf-avt-srtp-not-mandatory-16
(work in progress), May 2013. (work in progress), January 2014.
[I-D.ietf-avtcore-rtp-security-options] [I-D.ietf-avtcore-rtp-security-options]
Westerlund, M. and C. Perkins, "Options for Securing RTP Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", draft-ietf-avtcore-rtp-security-options-04 Sessions", draft-ietf-avtcore-rtp-security-options-10
(work in progress), July 2013. (work in progress), January 2014.
Appendix A. Metrics represented using RFC6390 Template Appendix A. Metrics represented using RFC6390 Template
RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC RFC EDITOR NOTE: please change XXXX in [RFCXXXX] by the new RFC
number, when assigned. number, when assigned.
a. RTP Payload Bytes Discarded Metric a. RTP Payload Bytes Discarded Metric
* Metric Name: RTP Payload Bytes Discarded Metric * Metric Name: RTP Payload Bytes Discarded Metric
* Metric Description: Total number of RTP Payload bytes * Metric Description: Total number of RTP Payload bytes
discarded over the period covered by this report. discarded over the period covered by this report.
* Method of Measurement or Calculation: See section 4, number of * Method of Measurement or Calculation: See section 4, number of
bytes discarded definition in [RFCXXXX]. bytes discarded definition in [RFCXXXX].
* Units of Measurement: See section 4, number of RTP payload * Units of Measurement: See section 4, number of RTP payload
bytes discarded definition in [RFCXXXX]. bytes discarded definition in [RFCXXXX].
* Measurement Point(s) with Potential Measurement Domain: See * Measurement Point(s) with Potential Measurement Domain: See
skipping to change at page 10, line 29 skipping to change at page 10, line 46
* Use and applications: See section 1, paragraph 1 of [RFCXXXX]. * Use and applications: See section 1, paragraph 1 of [RFCXXXX].
* Reporting model: See RFC3611. * Reporting model: See RFC3611.
Appendix B. Change Log Appendix B. Change Log
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
B.1. changes in draft-singh-xrblock-rtcp-xr-bytes-discarded-metric-00 B.1. changes in draft-singh-xrblock-rtcp-xr-bytes-discarded-metric-01
o Bytes discarded metric split from o Address SEC-DIR and Gen-art review.
[I-D.ietf-xrblock-rtcp-xr-discard-rle-metrics].
B.2. changes in draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-00 o Incorporate IESG comments.
B.2. changes in draft-singh-xrblock-rtcp-xr-bytes-discarded-metric-00
o Bytes discarded metric split from [I-D.ietf-xrblock-rtcp-xr-
discard-rle-metrics] />.
B.3. changes in draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-00
o Submitted as a WG draft. o Submitted as a WG draft.
B.3. changes in draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01 B.4. changes in draft-ietf-xrblock-rtcp-xr-bytes-discarded-metric-01
o Editorial fixes: Updated references from drafts to RFCs. o Editorial fixes: Updated references from drafts to RFCs.
o Updated fields in the RFC6390 template. o Updated fields in the RFC6390 template.
o Changed 'number of bytes discarded' to 'number of RTP payload o Changed 'number of bytes discarded' to 'number of RTP payload
bytes discarded'. bytes discarded'.
Authors' Addresses Authors' Addresses
 End of changes. 35 change blocks. 
80 lines changed or deleted 103 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/