idnits 2.17.1 draft-zorn-xrblock-rtcp-xr-al-stat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2011) is 4714 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: 'I-D.ietf-avt-rtp-svc' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC2250' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'MEASIDENT' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'PMOL' is defined on line 559, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3357 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-00 == Outdated reference: A later version (-12) exists of draft-ietf-pmol-metrics-framework-08 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Network Zen 4 Intended status: Standards Track R. Schott 5 Expires: December 2, 2011 Deutsche Telekom 6 Q. Wu 7 R. Huang 8 Huawei 9 May 31, 2011 11 RTCP XR for Application Layer Statistics Metrics Reporting 12 draft-zorn-xrblock-rtcp-xr-al-stat-01 14 Abstract 16 This document defines an RTCP XR Report Block and associated SDP 17 parameters that allows the reporting of application layer summary, 18 loss discard and burst metrics for use in a range of RTP 19 applications. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 2, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 3 70 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Application Layer Metrics . . . . . . . . . . . . . . . . . . 3 72 4.1. Application Layer Statistics Summary Report Block . . . . 4 73 4.2. Application Layer Loss and Discard Metrics Block . . . . . 6 74 4.3. Application Layer Burst Metrics Block . . . . . . . . . . 8 75 5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 RFC 3611 [RFC3611] defines seven report block formats for network 88 management and quality monitoring. However, some of these metrics 89 are mostly for multicast inference of network characteristics (MINC) 90 or voice over IP (VoIP) monitoring and not widely applicable to other 91 applications, e.g., video quality monitoring. This document focuses 92 on specifying new additional report block types used to convey video 93 related parameters at application layer that are generically designed 94 for use in audio and video services. 96 The metrics belong to the class of application layer metrics defined 97 in [MONARCH] (work in progress). 99 2. Terminology 101 2.1. Standards Language 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 In addition, the following terms are defined: 109 Picture Type 111 Picture types used in the different video algorithms compose of 112 the key-frame and the Derivation frame. Key-frame is also called 113 a reference frame and used as a reference for predicting other 114 pictures. It is coded without prediction from other pictures. 115 The Derivation frame is derived from Key-frame using prediction 116 from the reference frame. 118 3. Applicability 120 The Metric Block defined in this document can be applied to any real 121 time applications that convey video related parameters at application 122 layer. 124 4. Application Layer Metrics 125 4.1. Application Layer Statistics Summary Report Block 127 This block reports statistics beyond the information carried in the 128 Statistics Summary Report Block RTCP packet specified in the section 129 4.6 of RFC 3611 [RFC3611]. Information is recorded about lost frames 130 ,duplicated frames, lost partial frames. Such information can be 131 useful for network management and video quality monitoring. 133 The Application Layer Statistics Summary Report Block has the 134 following format: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | BT=TBD | rsd. |T|P|rsd| block length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | begin_seq | end_seq | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Number of frames expected | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | lost_full_frames | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | dup_frames | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | lost_partial_frames | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Block type (BT): 8 bits 154 The Application Layer Statistics Summary Report Block is 155 identified by the constant . 157 Rsd.: 4 bits 159 This field is reserved for future definition. In the absence of 160 such a definition, the bits in this field MUST be set to zero and 161 MUST be ignored by the receiver. 163 Picture type indicator (T): 1 bit 165 Picture types used in the different video algorithms compose of 166 key-frame and derivation frame. This field is used to indicate 167 the frame type to be reported. Bits set to 0 if the lost_frames 168 field or dup_frames field contain a key_frame report or reference 169 frame report, 1 if the lost_frames field and dup_frames field 170 contain other derivation frame report. 172 P: 1 bit 174 Bit set to 1 if the partial_lost_frames field or the partial_dup_ 175 frames field contains a report, 0 otherwise. 177 Rsd.: 2 bits 179 This field is reserved for future definition. In the absence of 180 such a definition, the bits in this field MUST be set to zero and 181 MUST be ignored by the receiver. 183 Block length: 16 bits 185 The constant 5, in accordance with the definition of this field in 186 Section 3 of RFC 3611 [RFC3611]. 188 begin_seq: 16 bits 190 As defined in Section 4.1 of RFC 3611 [RFC3611]. 192 end_seq: 16 bits 194 As defined in Section 4.1 of RFC 3611 [RFC3611]. 196 number of frames expected:32bits 198 A count of the number of frames expected, estimated if necessary. 199 If no frames have been received then this count shall be set to 200 Zero. 202 lost_full_frames: 32 bits 204 If one frame is completely lost, this frame is regarded as one 205 lost full_frame. The lost_full_frames is equivalent to the number 206 of lost_full_frames in the above sequence number interval. 208 dup_frames: 32 bits 210 Number of dup_frames in the above sequence number interval. 212 lost_partial_frames: 32 bits 214 If one frame is partially lost, this frame is regarded as one lost 215 fractional frame. The lost_partial_frames is equivalent to the 216 number of lost_partial_frames in the above sequence number 217 interval. 219 4.2. Application Layer Loss and Discard Metrics Block 221 A frame shall be regarded as lost if it fails to arrive within an 222 implementation-specific time window. A frame that arrives within 223 this time window but is too early or late to be played out shall be 224 regarded as discarded. A frame shall be classified as one of 225 received (or OK), discarded or lost. 227 This block reports Loss and Discard metrics statistics beyond the 228 information carried in the standard RTCP packet format. The block 229 reports separately on packets lost on the IP channel, and those that 230 have been received but then discarded by the receiving jitter buffer. 232 It is very useful to distinguish between frames lost by the network 233 and those discarded due to jitter. Both have equal effect on the 234 quality of the video stream, however, having separate counts helps 235 identify the source of quality degradation. These fields MUST be 236 populated, and MUST be set to zero if no frames have been received. 238 The Loss and Discard metrics are determined after the effects of FEC, 239 redundancy (RFC2198) or other similar process. Implementations MUST 240 provide values for all the fields defined here. For certain metrics, 241 if the value is undefined or unknown, then the specified default or 242 unknown field value MUST be provided. 244 The block is encoded as six 32-bit words: 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | BT=TBD |I| rsv |T| rsv.| block length | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Frame Loss rate | Frame Discard rate | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 block type (BT): 8 bits 256 A Application Layer Metrics Report Block is identified by the 257 constant . 259 Interval Metric flag (I): 1 bit 261 This field is used to indicate whether the metrics block is an 262 Interval or a Cumulative report, 264 reserved: 3 bits 266 This field is reserved for future definition. In the absence of 267 such a definition, the bits in this field MUST be set to zero and 268 MUST be ignored by the receiver. 270 Picture type indicator (T): 1 bit 272 Picture types used in the different video algorithms compose of 273 key-frame and derivation frame. This field is used to indicate 274 the picture type to be reported. Bits set to 0 if the Loss rate 275 field and discard rate field contain a Key_frame report or 276 reference frame report, 1 if the Loss rate field and discard rate 277 field contain other derivation frame reports. 279 reserved: 3 bits 281 This field is reserved for future definition. In the absence of 282 such a definition, the bits in this field MUST be set to zero and 283 MUST be ignored by the receiver. 285 block length: 16 bits 287 The constant 1, in accordance with the definition of this field in 288 Section 3 of RFC 3611 [RFC3611]. 290 Frame Loss rate: 8 bits 292 The proportion of frames lost since the beginning of reception, 293 expressed as a fixed point number with the binary point at the 294 left edge of the field. This value is calculated by dividing the 295 total number of lost frames containing specified frame (e.g., Key 296 frame) (after the effects of applying any error protection such as 297 FEC) by the total number of frames expected, multiplying the 298 result of the division by 256, limiting the maximum value to 255 299 (to avoid overflow), and taking the integer part. The numbers of 300 duplicated frames and discarded frames do not enter into this 301 calculation. Since receivers cannot be required to maintain 302 unlimited buffers, a receiver MAY categorize late-arriving frames 303 as lost. The degree of lateness that triggers a loss SHOULD be 304 significantly greater than that which triggers a discard. 306 Frame Discard rate: 8 bits 308 The proportion of frames discarded since the beginning of 309 reception, due to late or early arrival, under-run or overflow at 310 the receiving jitter buffer. This value is expressed as a fixed 311 point number with the binary point at the left edge of the field. 313 It is calculated by dividing the total number of discarded frames 314 containing specified frame (e.g., Key Frame) (excluding duplicate 315 frames discards) by the total number of frames expected, 316 multiplying the result of the division by 256, limiting the 317 maximum value to 255 (to avoid overflow), and taking the integer 318 part. 320 4.3. Application Layer Burst Metrics Block 322 This block reports Burst metrics statistics beyond the information 323 carried in the standard RTCP packet format. It reports on the 324 combined effect of losses and discards, as both have equal effect on 325 video quality. 327 In order to properly assess the quality of a video stream, it is 328 desirable to consider the degree of burstiness of packet loss RFC 329 3357 [RFC3357]. Following the one-way loss pattern sample metrics 330 discussed in [RFC3357], a measure of the spacing between consecutive 331 network packet loss or error events, is a "loss distance". The loss 332 distance metric captures the spacing between the loss periods. The 333 duration of a loss or error event (e.g. and how many packets are lost 334 in that duration) is a "loss period", the loss period metric captures 335 the frequency and length (burstiness) of loss once it starts. Delay 336 reports include the transit delay between RTP end points and the end 337 system processing delays, both of which contribute to the user 338 perceived delay. 340 Implementations MUST provide values for all the fields defined here. 341 For certain metrics, if the value is undefined or unknown, then the 342 specified default or unknown field value MUST be provided. 344 The block is encoded as three 32-bit words: 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | BT=TBD |I| Rsv. | block length | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Loss Distance | Loss Period | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Threshold | Reserved. | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 block type (BT): 8 bits 358 Appliation Layer Metrics Report Block is identified by the 359 constant . 361 reserved: 8 bits 363 This field is reserved for future definition. In the absence of 364 such a definition, the bits in this field MUST be set to zero and 365 MUST be ignored by the receiver. 367 Interval Metric flag (I): 1 bit 369 This field is used to indicate whether the metrics block is an 370 Interval or a Cumulative report, 372 reserved: 7 bits 374 This field is reserved for future definition. In the absence of 375 such a definition, the bits in this field MUST be set to zero and 376 MUST be ignored by the receiver. 378 block length: 16 bits 380 The constant 2, in accordance with the definition of this field in 381 Section 3 of RFC 3611 [RFC3611]. 383 Loss Period: 16 bits 385 The average duration of a burst of lost and discarded frames. The 386 mean duration, expressed in milliseconds, of the loss intervals 387 that have occurred since the beginning of reception [DSLF]. The 388 duration of each loss period is calculated based upon the frame 389 packets that mark the beginning and end of that period. It is 390 equal to the timestamp of the end frame, plus the duration of the 391 end frame, minus the timestamp of the beginning frame. If the 392 actual values are not available, estimated values MUST be used. 393 If there have been no burst periods, the burst duration value MUST 394 be zero. 396 Loss Distance: 16 bits 398 The average duration of periods between bursts. The mean 399 duration, expressed in milliseconds, of the gap periods that have 400 occurred since the beginning of reception [DSLF]. The duration of 401 each period is calculated based upon the frame packets that marks 402 the end of the prior burst and the frame packet that marks the 403 beginning of the subsequent burst. It is equal to the timestamp 404 of the subsequent burst frame packet, minus the timestamp of the 405 prior burst frame packet, plus the duration of the prior burst 406 frame packet. If the actual values are not available, estimated 407 values MUST be used. In the case of a gap that occurs at the 408 beginning of reception, the sum of the timestamp of the prior 409 burst packet and the duration of the prior burst packet are 410 replaced by the reception start time. In the case of a gap that 411 occurs at the end of reception, the timestamp of the subsequent 412 burst packet is replaced by the reception end time. If there have 413 been no gap periods, the gap duration value MUST be zero. 415 Threshold: 16 bits 417 The maximum duration, expressed in milliseconds, of the loss 418 distance that have occurred since the beginning of reception. 420 Reserved: 16 bits 422 All bits SHALL be set to 0 by the sender and SHALL be ignored on 423 reception. 425 block length: 16 bits 427 The constant 2, in accordance with the definition of this field in 428 Section 3 of RFC 3611 [RFC3611]. 430 5. SDP Signaling 432 Three new parameter is defined for the six report blocks defined in 433 this document to be used with Session Description Protocol (SDP) 434 [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. 435 They have the following syntax within the "rtcp-xr" attribute 436 [RFC3611]: 438 rtcp-xr-attrib = "a=rtcp-xr:" 439 [xr-format *(SP xr-format)] CRLF 440 xr-format = 441 / application-loss-metrics 442 / application-burst-metrics 443 / application-stat-summary 445 application-burst-metrics = " application-burst-metrics" 446 ["=" max-size] 447 max-size = 1*DIGIT ; maximum block size in octets 449 application--loss-metrics = " application-loss-metrics" 450 ["=" stat-flag *("," stat-flag)] 451 stat-flag = "key Frame loss and duplication" 452 / "derivation Frame loss and duplication" 454 application-stat-summary = "application-stat-summary" 455 ["=" stat-flag *("," stat-flag)] 456 stat-flag = "key Frame loss and duplication" 457 / "derivation Frame loss and duplication" 459 Refer to Section 5.1 of RFC 3611 [RFC3611] for a detailed description 460 and the full syntax of the "rtcp-xr" attribute. 462 6. IANA Considerations 464 New report block types for RTCP XR are subject to IANA registration. 465 For general guidelines on IANA allocations for RTCP XR, refer to 466 Section 6.2 of [RFC3611]. 468 This document assigns three new block type value in the RTCP XR Block 469 Type Registry: 471 Name: ALSS 472 Long Name: Application Layer Statistics Summary 473 Value 474 Reference: Section 4.1 476 Name: ALLDM 477 Long Name: Application Layer Loss and Discard Metrics 478 Value 479 Reference: Section 4.2 480 Name: ALBM 481 Long Name: Application Layer Burst Metrics 482 Value 483 Reference: Section 4.3 484 This document also registers three new SDP [RFC4566] parameters for 485 the "rtcp-xr" attribute in the RTCP XR SDP Parameters Registry: 487 * "application-layer-loss-metrics" 488 * "application-layer -burst-metrics" 489 * "application-layer -stat-summary" 491 The contact information for the registrations is: 493 Glen Zorn 494 Network Zen 495 77/440 Soi Phoomjit, Rama IV Road 496 Phra Khanong, Khlong Toie 497 Bangkok 10110 498 Thailand 500 7. Security Considerations 502 The new RTCP XR report blocks proposed in this document introduces no 503 new security considerations beyond those described in [RFC3611]. 505 8. Acknowledgements 507 The authors would like to thank Bill Ver Steeg, David R Oran, Ali 508 Begen,Colin Perkins, Roni Even,Youqing Yang, Wenxiao Yu and Yinliang 509 Hu for their valuable comments and suggestions on this document. 511 9. References 513 9.1. Normative References 515 [I-D.ietf-avt-rtp-svc] 516 Wenger, S., Wang, Y., Schierl, T., and A. Eleftheriadis, 517 "RTP Payload Format for Scalable Video Coding", 518 draft-ietf-avt-rtp-svc-27 (work in progress), 519 February 2011. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 525 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 526 January 1998. 528 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 529 Metrics", RFC 3357, August 2002. 531 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 532 Jacobson, "RTP: A Transport Protocol for Real-Time 533 Applications", STD 64, RFC 3550, July 2003. 535 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 536 Protocol Extended Reports (RTCP XR)", RFC 3611, 537 November 2003. 539 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 540 Description Protocol", RFC 4566, July 2006. 542 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 543 Specifications: ABNF", STD 68, RFC 5234, January 2008. 545 9.2. Informative References 547 [DSLF] Rahrer, T., Ed., Fiandra, Ed., and Wright, Ed., "Triple- 548 play Services Quality of Experience (QoE) Requirements", 549 DSL Forum Technical Report TR-126, December 2006. 551 [MEASIDENT] 552 Hunt, G. and A. Clark, "RTCP XR Measurement Identifier 553 Block", ID draft-ietf-avt-rtcp-xr-meas-identity-02, 554 May 2009. 556 [MONARCH] Wu, Q., "Monitoring Architectures for RTP", 557 ID draft-ietf-avtcore-monarch-00, April 2011. 559 [PMOL] Clark, A., "Framework for Performance Metric Development", 560 ID draft-ietf-pmol-metrics-framework-08, January 2011. 562 Appendix A. Change Log 564 This document is separated from 565 draft-wu-xrblock-rtcp-xr-quality-monitoring-01 with a few editorial 566 changes and focuses on application layer summary, loss, discard, and 567 burst metrics. 569 Authors' Addresses 571 Glen Zorn 572 Network Zen 573 77/440 Soi Phoomjit, Rama IV Road 574 Phra Khanong, Khlong Toie 575 Bangkok 10110 576 Thailand 578 Phone: +66 (0) 87 502 4274 579 Email: gwz@net-zen.net 581 Roland Schott 582 Deutsche Telekom 583 Deutsche-Telekom-Allee 7 584 Darmstadt 64295 585 Germany 587 Email: Roland.Schott@telekom.de 589 Qin Wu 590 Huawei 591 101 Software Avenue, Yuhua District 592 Nanjing, Jiangsu 210012 593 China 595 Email: sunseawq@huawei.com 597 Rachel Huang 598 Huawei 599 101 Software Avenue, Yuhua District 600 Nanjing 210012 601 China 603 Email: Rachel@huawei.com