idnits 2.17.1 draft-ietf-avt-rtcp-xr-jb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2008) is 5659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 253, but no explicit reference was found in the text -- No information found for draft-ietf-avt-rtcp-xr-measid - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEASIDENT' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-12) exists of draft-ietf-pmol-metrics-framework-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working G. Hunt 3 Group BT 4 Internet-Draft A. Clark 5 Intended status: Standards Track Telchemy 6 Expires: April 28, 2009 October 25, 2008 8 RTCP XR Report Block for Jitter Buffer Metric Reporting 9 draft-ietf-avt-rtcp-xr-jb-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 28, 2009. 36 Abstract 38 This document defines an RTCP XR Report Block that allows the 39 reporting of Jitter Buffer metrics for a range of RTP applications. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1. Jitter Buffer Metrics Block . . . . . . . . . . . . . . . 3 45 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 46 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 47 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Jitter Buffer Metrics Block . . . . . . . . . . . . . . . . . 4 49 2.1. Report Block Structure . . . . . . . . . . . . . . . . . . 4 50 2.2. Definition of Fields in Jitter Buffer Metrics Block . . . 4 51 3. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 7 52 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 54 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 56 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 57 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 59 Intellectual Property and Copyright Statements . . . . . . . . . . 13 61 1. Introduction 63 1.1. Jitter Buffer Metrics Block 65 This draft defines a new block type to augment those defined in 66 [RFC3611], for use in a range of RTP applications. 68 The new block type provides information on jitter buffer 69 configuration and performance. 71 The metric belongs to the class of transport-related terminal metrics 72 defined in [MONARCH] (work in progress). 74 Instances of this Metrics Block refer by tag to the separate 75 auxiliary Measurement Identity block [MEASIDENT] which contains 76 information such as the SSRC of the measured stream, and RTP sequence 77 numbers and time intervals indicating the span of the report. 79 1.2. RTCP and RTCP XR Reports 81 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 82 defined an extensible structure for reporting using an RTCP Extended 83 Report (XR). This draft defines a new Extended Report block that 84 MUST be used as defined in [RFC3550] and [RFC3611]. 86 1.3. Performance Metrics Framework 88 The Performance Metrics Framework [PMOLFRAME] provides guidance on 89 the definition and specification of performance metrics. Metrics 90 described in this draft either reference external definitions or 91 define metrics generally in accordance with the guidelines in 92 [PMOLFRAME]. 94 1.4. Applicability 96 These metrics are applicable to a range of RTP applications. 98 2. Jitter Buffer Metrics Block 100 This block describes the configuration and operating parameters of 101 the jitter buffer in the receiver of the RTP end system or RTP mixer 102 which sends the report. 104 2.1. Report Block Structure 106 JB Metrics Block 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | BT=NJB |I| tag |jb cfg | block length=2 | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | JB nominal | JB maximum | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | JB high water mark | JB low water mark | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 Figure 1: Report Block Structure 119 2.2. Definition of Fields in Jitter Buffer Metrics Block 121 block type (BT): 8 bits 123 A Jitter Buffer Metrics Report Block is identified by the constant 124 NJB. 126 [Note to RFC Editor: please replace NJB with the IANA provided RTCP 127 XR block type for this block.] 129 Interval Metric flag (I): 1 bit 131 This field is used to indicate whether the Jitter Buffer Metrics 132 block is an Interval or a Cumulative report, that is, whether the 133 reported values apply to the most recent measurement interval 134 duration between successive metrics reports (I=1) (the Interval 135 Duration) or to the accumulation period characteristic of 136 cumulative measurements (I=0) (the Cumulative Duration). 137 Numerical values for both these intervals are provided in the 138 Measurement Identifier block referenced by the tag field below. 140 Measurement Identifier association (tag): 3 bits 142 This field is used to identify the Measurement Identifier block 143 [MEASIDENT] which describes this measurement. The relevant 144 Measurement Identifier block has the same tag value as the Jitter 145 Buffer Metrics block. Note that there may be more than one 146 Measurement Identifier block per RTCP packet. 148 Jitter Buffer Configuration (jb cfg): 4 bits 150 This field is used to identify the jitter buffer method in use at 151 the receiver, according to the following code: 153 bits 014-017 154 0 = Fixed jitter buffer 155 1 = Adaptive jitter buffer 156 Other values reserved 158 block length: 16 bits 160 The length of this report block in 32-bit words, minus one. For 161 the Jitter Buffer block, the block length is equal to 2. 163 jitter buffer nominal delay (JB nominal): 16 bits 165 This is the current nominal jitter buffer delay in milliseconds, 166 which corresponds to the nominal jitter buffer delay for packets 167 that arrive exactly on time. This parameter MUST be provided for 168 both fixed and adaptive jitter buffer implementations. 170 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 171 reported to indicate an over-range measurement. If the 172 measurement is unavailable, the value 0xFFFF SHOULD be reported. 174 jitter buffer maximum delay (JB maximum): 16 bits 176 This is the current maximum jitter buffer delay in milliseconds 177 which corresponds to the earliest arriving packet that would not 178 be discarded. In simple queue implementations this may correspond 179 to the nominal size. In adaptive jitter buffer implementations, 180 this value may dynamically. This parameter MUST be provided for 181 both fixed and adaptive jitter buffer implementations. 183 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 184 reported to indicate an over-range measurement. If the 185 measurement is unavailable, the value 0xFFFF SHOULD be reported. 187 jitter buffer high water mark (JB high water mark): 16 bits 188 This is the highest value of the jitter buffer nominal delay which 189 occurred at any time during the reporting interval. 191 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 192 reported to indicate an over-range measurement. If the 193 measurement is unavailable, the value 0xFFFF SHOULD be reported. 195 jitter buffer low water mark (JB low water mark): 16 bits 197 This is the lowest value of the jitter buffer nominal delay which 198 occurred at any time during the reporting interval. 200 If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be 201 reported to indicate an over-range measurement. If the 202 measurement is unavailable, the value 0xFFFF SHOULD be reported. 204 3. SDP Signaling 206 [RFC3611] defines the use of SDP (Session Description Protocol) 207 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 208 without prior signaling. 210 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 211 in [RFC3611] by providing an additional value of "xr-format" to 212 signal the use of the report block defined in this document. 214 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 216 (defined in [RFC3611]) 218 xr-format = xr-format / xr-jb-block 220 xr-jb-block = "xr-jb" 222 4. IANA Considerations 224 This document creates a new block type within the IANA "RTCP XR Block 225 Type Registry" called the Jitter Buffer Metrics Block, and a new 226 parameter xr-jb within the "RTCP XR SDP Parameters Registry". 228 5. Security Considerations 230 It is believed that this proposed RTCP XR report block introduces no 231 new security considerations beyond those described in [RFC3611]. 232 This block does not provide per-packet statistics so the risk to 233 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 234 does not apply. 236 6. Contributors 238 The authors gratefully acknowledge the comments and contributions 239 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 240 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 241 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 242 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 243 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada. 245 7. References 247 7.1. Normative References 249 [MEASIDENT] 250 Hunt, G., "RTCP XR Measurement Identifier Block", 251 ID draft-ietf-avt-rtcp-xr-measid-00, August 2008. 253 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", RFC 2119, BCP 14, March 1997. 256 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 257 Applications", RFC 3550, July 2003. 259 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 260 XR)", RFC 3611, November 2003. 262 [RFC4566] Handley, M., "SDP: Session Description Protocol", 263 RFC 4566, July 2006. 265 7.2. Informative References 267 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 268 ID draft-hunt-avt-monarch-01, August 2008. 270 [PMOLFRAME] 271 Clark, A., "Framework for Performance Metric Development", 272 ID draft-ietf-pmol-metrics-framework-00, July 2008. 274 Authors' Addresses 276 Geoff Hunt 277 BT 278 Orion 1 PP9 279 Adastral Park 280 Martlesham Heath 281 Ipswich, Suffolk IP4 2TH 282 United Kingdom 284 Phone: +44 1473 608325 285 Email: geoff.hunt@bt.com 287 Alan Clark 288 Telchemy Incorporated 289 2905 Premiere Parkway, Suite 280 290 Duluth, GA 30097 291 USA 293 Email: alan.d.clark@telchemy.com 295 Full Copyright Statement 297 Copyright (C) The IETF Trust (2008). 299 This document is subject to the rights, licenses and restrictions 300 contained in BCP 78, and except as set forth therein, the authors 301 retain all their rights. 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Intellectual Property 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org.