idnits 2.17.1 draft-hunt-avt-rtcpxnq-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 336. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 342. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (August 23, 2007) is 6089 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-03) exists of draft-ietf-avt-rtcphr-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 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 August 23, 2007 5 Intended status: Standards Track 6 Expires: February 24, 2008 8 BT's eXtended Network Quality RTP Control Protocol Extended Reports 9 (RTCP XR XNQ) 10 draft-hunt-avt-rtcpxnq-01.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on February 24, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes an RTCP XR report block which reports packet 44 transport parameters. The report block was developed by BT for pre- 45 standards use in BT's next generation network. This document has 46 been produced to describe the report block in sufficient detail to 47 register the block type with IANA in accordance with the 48 Specification Required policy of [1]. This Specification does not 49 standardise the new report block for use outside BT's network. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 55 3. Extended Network Quality (XNQ) Report Block . . . . . . . . . 5 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 Intellectual Property and Copyright Statements . . . . . . . . . . 13 64 1. Introduction 66 A set of metrics of packet transport quality has been defined by BT 67 for pre-standards use in its network. These metrics are known as 68 "XNQ" for "eXtended Network Quality". This document defines an 69 RTCP-XR Report Block to transport the XNQ measures from an RTP end 70 system to its peer, using the extension mechanism defined in [1]. 72 The metrics are designed to supplement the packet loss metric in RTCP 73 [2] and the round-trip delay measurement provided by RTCP. They 74 provide metrics for IP packet delay variation based on the IPDV 75 metric defined in [3], metrics reporting the activity of the RTP end 76 system's receiver's jitter buffer, and metrics reporting "errored" 77 and "severely errored" seconds. 79 This document has been produced to describe the report block in 80 sufficient detail to register the block type with IANA in accordance 81 with the Specification Required policy of [1]. This Specification 82 does not standardise the new report block for use outside BT's 83 network. 85 Work in progress on RTCP HR [5] is likely to obsolete these metrics 86 and the RTCP-XR Report Block defined here. 88 2. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [4]. 94 3. Extended Network Quality (XNQ) Report Block 96 A set of metrics of packet transport quality has been defined by BT 97 for pre-standards use in its network. These metrics are known as 98 "XNQ" for "eXtended Network Quality". 100 This document defines an RTCP-XR Report Block using the extension 101 mechanism defined in [1]. The new Report Block provides transport of 102 the XNQ measures from an RTP end system to its peer. 104 The metrics are described in the following text. However, some 105 additional explanation is required for the metrics vmaxdiff, vrange, 106 vsum, and c which measure aspects of packet delay variation. The 107 metrics are based on the measure known as IP Packet Delay Variation 108 (IPDV) defined in [3]. The IPDV of a packet is the amount by which 109 the packet was delayed in the network, minus the amount a reference 110 packet was delayed in the network. The reference packet is usually 111 the first packet of the connection. IPDV is a signed quantity. 113 The metric vrange is the difference (longest minus shortest) between 114 the longest and shortest network packet delays seen over the duration 115 of the connection to date. The metric vrange is usually a positive 116 quantity, but may be zero if the packet delay is exactly constant 117 over the lifetime of the connection to date. 119 The metric vmaxdiff is found as follows. For each RTCP measurement 120 cycle, find the difference (longest minus shortest) between the 121 longest and shortest network packet delays within that measurement 122 cycle. These differences are usually all positive quantities, but a 123 difference may be zero if the packet delay is exactly constant 124 throughout the measurement cycle. Take the set of these differences 125 and find the maximum, which is vmaxdiff. The metric vmaxdiff is also 126 usually a positive quantity, but will be zero if all the members of 127 the set of per-cycle differences are zero. 129 The metric vsum is simply the sum of the per-RTCP-cycle differences, 130 which were obtained to find vmaxdiff as described above. The metric 131 c is the number of per-RTCP-cycle differences, that is, the 132 cardinality of the set of differences. The two metrics vsum and c 133 allow calculation of vsum/c, the average IPDV per RTCP measurement 134 cycle. 136 The format of the report is as shown in Figure 1. 138 0 1 2 3 139 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | BT=8 | reserved | block length = 8 | 142 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 143 | begin_seq | end_seq | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | vmaxdiff | vrange | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | vsum | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | c | jbevents | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | reserved | tdegnet | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | reserved | tdegjit | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | reserved | es | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | reserved | ses | 158 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 160 Figure 1 162 The report consists of an RTCP-XR block header and a single 8-word 163 sub-block. 165 block type (BT): 8 bits 167 An XNQ Metrics Report Block is identified by the constant 8. 169 reserved: 8 bits 171 These fields are reserved for future definition. In the absence 172 of such a definition, the bits in these fields MUST be set to zero 173 and MUST be ignored by the receiver. 175 block length: 16 bits 177 Defined in Section 3 of [1]. 179 begin_seq: 16 bits 181 As defined in Section 4.1 of [1]. 183 end_seq: 16 bits 184 As defined in Section 4.1 of [1]. 186 vmaxdiff: 16 bits unsigned 188 Largest IPDV difference seen to date within a single RTCP 189 measurement cycle, measured in RTP timestamp units. If the 190 measured value exceeds 0xFFFE, the value 0xFFFF should be reported 191 to indicate an over-range measurement. 193 vrange: 16 bits unsigned 195 Largest IPDV difference over the lifetime of the RTP flow to date, 196 measured in RTP timestamp units. If the measured value exceeds 197 0xFFFE, the value 0xFFFF should be reported to indicate an over- 198 range measurement. 200 vsum: 32 bits unsigned 202 Sum of the peak IPDV difference values within each RTCP cycle, 203 summed over RTCP cycles over the lifetime of the RTP flow to date. 204 If the measured value exceeds 0xFFFFFFFE, the value 0xFFFFFFFF 205 should be reported to indicate an over-range measurement. 207 c: 16 bits unsigned 209 Number of RTCP cycles over which vsum was accumulated. If the 210 measured value exceeds 0xFFFE, the value 0xFFFF should be reported 211 to indicate an over-range measurement. 213 jbevents: 16 bits unsigned 215 Cumulative number of jitter buffer adaptation events over the 216 lifetime of the RTP flow to date. If the measured value exceeds 217 0xFFFE, the value 0xFFFF should be reported to indicate an over- 218 range measurement. 220 tdegnet: 24 bits unsigned 222 The total time in sample periods affected either by packets 223 unavailable due to network loss, or late delivery of packets, 224 since the start of transmission. If the measured value exceeds 225 0xFFFFFE, the value 0xFFFFFF should be reported to indicate an 226 over-range measurement. 228 tdegjit: 24 bits unsigned 229 The total time in sample periods degraded by jitter buffer 230 adaptation events e.g. where the jitter buffer either plays out a 231 sample sequence not originating at the transmitter, repeats 232 samples, or chooses not to play out a sample sequence which was 233 sent by the transmitter. If the measured value exceeds 0xFFFFFE, 234 the value 0xFFFFFF should be reported to indicate an over-range 235 measurement. 237 es: 24 bits unsigned 239 cumulative seconds affected by "unavailable packet" events over 240 the lifetime of this ephemeral, to date. If the measured value 241 exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to 242 indicate an over-range measurement. 244 ses: 24 bits unsigned 246 cumulative seconds affected by severe "unavailable packet" events 247 over the lifetime of this ephemeral, to date. If the measured 248 value exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to 249 indicate an over-range measurement. 251 4. IANA Considerations 253 This document requests IANA to allocate the specific number 8 within 254 the registry "RTP Control Protocol Extended Reports (RTCP XR) Block 255 Types", http://www.iana.org/assignments/rtcp-xr-block-types, to the 256 RTCP XR report block described here. This registry is defined in 257 [1]. 259 5. Security Considerations 261 It is believed that this proposed RTCP XR report block introduces no 262 new security considerations beyond those described in [1]. Some of 263 the considerations in [1] do not apply to this report block. 264 Specifically, XNQ does not provide per-packet statistics so the risk 265 to confidentiality documented in Section 7 paragraph 3 of [1] does 266 not apply, and XNQ packets cannot be very large so the risk of denial 267 of service documented in Section 7 paragraph 7 of [1] does not apply. 269 6. References 271 6.1. Normative References 273 [1] Friedman, T., "RTP Control Protocol Extended Reports (RTCP XR)", 274 RFC 3611, November 2003. 276 [2] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 277 Applications", RFC 3550, July 2003. 279 [3] ITU-T, "Recommendation Y.1540, Internet protocol data 280 communication service -- IP packet transfer and availability 281 performance parameters", December 2002. 283 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 284 Levels", RFC 2119, BCP 14, March 1997. 286 6.2. Informative References 288 [5] Clark, A., "RTCP HR - High Resolution VoIP Metrics Report 289 Blocks", ID draft-ietf-avt-rtcphr-01, February 2007. 291 Author's Address 293 Geoff Hunt 294 BT 295 Orion 1 PP9 296 Adastral Park 297 Martlesham Heath 298 Ipswich, Suffolk IP5 3RE 299 United Kingdom 301 Phone: +44 1473 608325 302 Email: geoff.hunt@bt.com 304 Full Copyright Statement 306 Copyright (C) The IETF Trust (2007). 308 This document is subject to the rights, licenses and restrictions 309 contained in BCP 78, and except as set forth therein, the authors 310 retain all their rights. 312 This document and the information contained herein are provided on an 313 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 314 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 315 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 316 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 317 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 318 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 320 Intellectual Property 322 The IETF takes no position regarding the validity or scope of any 323 Intellectual Property Rights or other rights that might be claimed to 324 pertain to the implementation or use of the technology described in 325 this document or the extent to which any license under such rights 326 might or might not be available; nor does it represent that it has 327 made any independent effort to identify any such rights. Information 328 on the procedures with respect to rights in RFC documents can be 329 found in BCP 78 and BCP 79. 331 Copies of IPR disclosures made to the IETF Secretariat and any 332 assurances of licenses to be made available, or the result of an 333 attempt made to obtain a general license or permission for the use of 334 such proprietary rights by implementers or users of this 335 specification can be obtained from the IETF on-line IPR repository at 336 http://www.ietf.org/ipr. 338 The IETF invites any interested party to bring to its attention any 339 copyrights, patents or patent applications, or other proprietary 340 rights that may cover technology that may be required to implement 341 this standard. Please address the information to the IETF at 342 ietf-ipr@ietf.org. 344 Acknowledgment 346 Funding for the RFC Editor function is provided by the IETF 347 Administrative Support Activity (IASA).