idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-pdv-04.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 date (August 24, 2012) is 4260 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. 'G.1020' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-10) exists of draft-ietf-xrblock-rtcp-xr-meas-identity-06 == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-13 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group G. Hunt 3 Internet-Draft Unaffiliated 4 Intended status: Standards Track A. Clark 5 Expires: February 25, 2013 Telchemy 6 Q. Wu 7 Huawei 8 August 24, 2012 10 RTCP XR Report Block for Packet Delay Variation Metric Reporting 11 draft-ietf-xrblock-rtcp-xr-pdv-04.txt 13 Abstract 15 This document defines an RTCP XR Report Block that allows the 16 reporting of Packet Delay Variation metrics for a range of RTP 17 applications. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 25, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Packet Delay Variation Metrics Block . . . . . . . . . . . 3 55 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 56 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 57 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Packet Delay Variation Metrics Block . . . . . . . . . . . . . 5 62 3.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 63 3.2. Definition of Fields in PDV Metrics Block . . . . . . . . 5 64 3.3. Guidance on use of PDV metrics . . . . . . . . . . . . . . 8 65 3.4. Examples of use . . . . . . . . . . . . . . . . . . . . . 9 66 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 12 69 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 12 70 5.3. Contact information for registrations . . . . . . . . . . 12 71 5.4. New registry of PDV types . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 77 A.1. draft-ietf-xrblock-rtcp-xr-pdv-03 . . . . . . . . . . . . 16 78 A.2. draft-ietf-xrblock-rtcp-xr-pdv-02 . . . . . . . . . . . . 16 79 A.3. draft-ietf-xrblock-rtcp-xr-pdv-01 . . . . . . . . . . . . 16 80 A.4. draft-ietf-xrblock-rtcp-xr-pdv-00 . . . . . . . . . . . . 16 81 A.5. draft-ietf-avt-rtcp-xr-pdv-03 . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 1.1. Packet Delay Variation Metrics Block 88 This draft defines a new block type to augment those defined in 89 [RFC3611], for use in a range of RTP applications. 91 The new block type provides information on Packet Delay Variation 92 using one of several standard metrics. 94 The metrics belong to the class of transport metrics defined in 95 [MONARCH] . 97 1.2. RTCP and RTCP XR Reports 99 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 100 defined an extensible structure for reporting using an RTCP Extended 101 Report (XR). This draft defines a new Extended Report block that 102 must be used in accordance with [RFC3550] and [RFC3611]. 104 1.3. Performance Metrics Framework 106 The Performance Metrics Framework [RFC6390] provides guidance on the 107 definition and specification of performance metrics. The RTP 108 Monitoring Architectures [MONARCH] provides guideline for reporting 109 block format using RTCP XR. The XR Block described in this document 110 are in accordance with the guidelines in [RFC6390] and [MONARCH]. 112 1.4. Applicability 114 These metrics are applicable to a wide range of RTP applications in 115 which the application streams are sensitive to delay variation 116 [RFC5481]. 118 2. Terminology 120 2.1. Standards Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2.2. Notations 128 This report block makes use of binary fractions. The terminology 129 used is 131 Numeric formats S X:Y 133 where S indicates a two's complement signed representation, X 134 the number of bits prior to the decimal place and Y the number 135 of bits after the decimal place. 137 Hence 8:8 represents an unsigned number in the range 0.0 to 138 255.996 with a granularity of 0.0039. S7:8 would represent the 139 range -127.996 to +127.996. 0:16 represents a proper binary 140 fraction with range 142 0.0 to 1 - 1/65536 = 0.9999847 144 though note that use of flag values at the top of the numeric 145 range slightly reduces this upper limit. For example, if the 146 16- bit values 0xfffe and 0xffff are used as flags for "over- 147 range" and "unavailable" conditions, a 0:16 quantity has range 149 0.0 to 1 - 3/65536 = 0.9999542 151 3. Packet Delay Variation Metrics Block 153 Metrics in this block report on packet delay variation in the stream 154 arriving at the RTP system. Instances of this Metrics Block refer by 155 Synchronization source (SSRC) to the separate auxiliary Measurement 156 Information block [MEASI] which contains measurement intervals. This 157 metric block relies on the measurement interval in the Measurement 158 Information block indicating the span of the report and SHOULD be 159 sent in the same compound RTCP packet as the measurement information 160 block. If the measurement interval is not received for this metric 161 block, this metric block SHOULD be discarded. 163 3.1. Report Block Structure 165 PDV metrics block 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | BT=NPDV | I |pdvtyp |Rsv| block length=3 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | SSRC of Source | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Pos PDV Threshold/Peak | Pos PDV Percentile | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Neg PDV Threshold/Peak | Neg PDV Percentile | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Mean PDV | unused | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 Figure 1: Report Block Structure 183 3.2. Definition of Fields in PDV Metrics Block 185 Block type (BT): 8 bits 187 A Packet Delay Variation Metrics Report Block is identified by the 188 constant NPDV. 190 [Note to RFC Editor: please replace NPDV with the IANA provided 191 RTCP XR block type for this block.] 193 Interval Metric flag (I): 2 bit 195 This field is used to indicate whether the Packet Delay variation 196 metrics are Sampled, Interval or Cumulative metrics, that is, 197 whether the reported values applies to the most recent measurement 198 interval duration between successive metrics reports (I=10) (the 199 Interval Duration) or to the accumulation period characteristic of 200 cumulative measurements (I=11) (the Cumulative Duration) or is a 201 sampled instantaneous value (I=01) (Sampled Value). 203 Packet Delay Variation Metric Type (pdvtyp): 4 bits 205 Packet Delay Variation Metric Type is of type enumerated and 206 should be interpreted as Integer. This field is used to identify 207 the Packet Delay Variation Metric Type used in this report block, 208 according to the following code: 210 bits 014-011 212 0: MAPDV2, Clause 6.2.3.2 of [G.1020], 214 1: 2-point PDV, Clause 6.2.4 of [Y.1540]. 216 Rsv.: 2 bits 218 This field is reserved for future definition. In the absence of 219 such a definition, the bits in this field SHOULD be set to zero 220 and MUST be ignored by the receiver. 222 Block Length: 16 bits 224 The length of this report block in 32-bit words, minus one. For 225 the Packet Delay Variation Metrics block, the block length is 226 equal to 4. 228 SSRC of source: 32 bits 230 As defined in Section 4.1 of [RFC3611]. 232 Positive PDV Threshold/Peak: 16 bits 234 This field is associated with the Positive PDV percentile and 235 expressed in Milliseconds with numeric format S11:4. The term 236 Positive represents that the packets are arriving later than the 237 expected time. 239 If the measured value is more negative than -2047.9375 (the value 240 which would be coded as 0x8001), the value 0x8000 SHOULD be 241 reported to indicate an over-range negative measurement. If the 242 measured value is more positive than +2047.8125 (the value which 243 would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to 244 indicate an over-range positive measurement. If the measurement 245 is unavailable, the value 0x7FFF MUST be reported. 247 Positive PDV Percentile: 16 bits 249 The percentages of packets in the RTP stream for which individual 250 packet delays were less than the Positive PDV Threshold. It is 251 expressed in numeric format 8:8 with values from 0 to 100th 252 percentile. 254 If the measurement is unavailable, the value 0xFFFF MUST be 255 reported. 257 Negative PDV Threshold/Peak: 16 bits 259 This field is associated with the Negative PDV percentile and 260 expressed in Milliseconds with numeric format S11:4. The term 261 Negative represents that the packets are arriving earlier than the 262 expected time. 264 If the measured value is more negative than -2047.9375 (the value 265 which would be coded as 0x8001), the value 0x8000 SHOULD be 266 reported to indicate an over-range negative measurement. If the 267 measured value is more positive than +2047.8125 (the value which 268 would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to 269 indicate an over-range positive measurement. If the measurement 270 is unavailable, the value 0x7FFF MUST be reported. 272 Negative PDV Percentile: 16 bits 274 The percentages of packets in the RTP stream for which individual 275 packet delays were more than the Negative PDV Threshold. It is 276 expressed in numeric format 8:8 with values from 0 to 100th 277 percentile. 279 If the measurement is unavailable, the value 0xFFFF MUST be 280 reported. 282 If the PDV Type indicated is 2-point PDV and the Positive and 283 Negative PDV Percentiles are set to 100.0 then the Positive and 284 Negative Threshold/Peak PDV values are the peak values measured 285 during the reporting interval (which may be from the start of the 286 call for cumulative reports). In this case, the difference 287 between the Positive and Negative Threshold/Peak values defines 288 the range of 2-point PDV. 290 Mean PDV: 16 bits 292 The mean PDV value of data packets is expressed in milliseconds 293 with Numeric format S11:4 format. 295 For MAPDV2 this value is generated according to Clause 6.2.3.2 of 296 [G.1020]. For interval reports the MAPDV2 value is reset at the 297 start of the interval. 299 For 2-point PDV, the value reported is the mean of per-packet 300 2-point PDV values. This metric indicates the arrival time of the 301 first media packet of the session with respect to the mean of the 302 arrival times of every packet of the session. A single value of 303 the metric (for a single session) may not be useful by itself, but 304 its average over a number of sessions may be useful in diagnosing 305 media delay at session startup. For example, this might occur if 306 media packets are often delayed behind signalling packets due to 307 head-of-line blocking. 309 If the measured value is more negative than -2047.9375 (the value 310 which would be coded as 0x8001), the value 0x8000 SHOULD be 311 reported to indicate an over-range negative measurement. If the 312 measured value is more positive than +2047.8125 (the value which 313 would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to 314 indicate an over-range positive measurement. If the measurement 315 is unavailable, the value 0x7FFF MUST be reported. 317 Reserved: 16 bits 319 These bits are reserved for future definition. They SHOULD be set 320 to zero by the sender and MUST be ignored by the receiver. 322 3.3. Guidance on use of PDV metrics 324 This subsection provides informative guidance on when it might be 325 appropriate to use each of the PDV metric types. 327 MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous 328 (per-packet) delay when compared to the short term moving average 329 delay. This metric could be useful in determining residual 330 impairment when an RTP end system uses an adaptive de-jitter buffer 331 which tracks the average delay variation, provided the adaptive de- 332 jitter buffer have similar averaging behaviour as the MAPDV2 333 algorithm. 335 2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay 336 variation with respect to a defined reference packet transfer delay . 337 Note that the reference packet is generally selected as the packet 338 with minimum delay based on the most common criterion (See section 1 339 and section 5.1 of [RFC5481] ). In an RTP context, the two "points" 340 are at the sender (the synchronization source which applies RTP 341 timestamps) and at the receiver. The value of this metric for the 342 packet with index j is identical to the quantity D(i,j) defined in 343 Section 6.4.1 of [RFC3550] and the packet index i should be set equal 344 to the index of the reference packet for the metric in practice. The 345 metric includes the effect of the frequency offsets of clocks in both 346 the sender and receiver end systems, so it is useful mainly in 347 network where synchronisation is distributed. As well as measuring 348 packet delay variation in such networks, it may be used to ensure 349 that synchronisation is effective, for example where the network 350 carries ISDN data traffic over RTP [RFC4040]. The metric is likely 351 to be useful in networks which use fixed de-jitter buffering, because 352 it may be used to determine the length of the required de-jitter 353 buffer, or to determine if network performance has deteriorated such 354 that existing de-jitter buffers are too small to accommodate the 355 observed delay variation. 357 3.4. Examples of use 359 (b) To report MAPDV2 [G.1020]: 361 Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV 362 Threshold = 50.0 (note this implies -50ms); Neg PDV Percentile 363 = 98.4; PDV type = 1 (MAPDV2) 365 causes average MAPDV2 to be reported in the Mean PDV field. 367 Note that implementations may either fix the reported 368 percentile and calculate the associated PDV level or may fix a 369 threshold PDV level and calculate the associated percentile. 370 From a practical implementation perspective it is simpler to 371 use the second of these approaches (except of course in the 372 extreme case of a 100% percentile). 374 (b) To report 2-point PDV [Y.1540]: 376 Pos PDV Threshold = 60 (note this implies +60ms); Pos PDV 377 Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile = 378 0; PDV type = 1 (2-point PDV) 380 causes 2-point PDV to be reported in the Mean PDV field. 382 2-point PDV, according to [Y.1540] is the difference in delay 383 between the current packet and the referenced packet of the 384 stream. If the sending and receiving clocks are not 385 synchronized, this metric includes the effect of relative 386 timing drift. 388 4. SDP Signaling 390 [RFC3611] defines the use of SDP (Session Description Protocol) 391 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 392 without prior signaling. 394 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 395 in [RFC3611] by providing an additional value of "xr-format" to 396 signal the use of the report block defined in this document. 398 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 400 (defined in [RFC3611]) 402 xr-format =/ xr-pdv-block 404 xr-pdv-block = "pkt-dly-var" [ "," pdvtype ] [ "," nspec "," pspec ] 406 pdvtype = "pdv=" "0" ; MAPDV2 ITU-T G.1020 407 / "1" ; 2-point PDV ITU-T Y.1540 408 / 1*2DIGIT ;Value 2~15 are valid and 409 ;reserved for future use 410 nspec = "nthr=" fixpoint ; negative PDV threshold (ms) 411 / "npc=" fixpoint ; negative PDV percentile 412 pspec = "pthr=" fixpoint ; positive PDV threshold (ms) 413 / "ppc=" fixpoint ; positive PDV percentile 415 fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal 416 DIGIT = %x30-39 418 When SDP is used in offer-answer, a system sending SDP may request a 419 specific type of PDV measurement. In addition, they may state a 420 specific percentile or threshold value, and expect to receive the 421 corresponding threshold or percentile metric, respectively. The 422 system receiving the SDP SHOULD send the PDV metrics requested, but 423 if the metric is not available, the system receiving the SDP MUST 424 send the metric block with the flag value indicating that the metric 425 is unavailable. 427 5. IANA Considerations 429 New block types for RTCP XR are subject to IANA registration. For 430 general guidelines on IANA considerations for RTCP XR, refer to 431 [RFC3611]. 433 5.1. New RTCP XR Block Type value 435 This document assigns the block type value NPDV in the IANA "RTCP XR 436 Block Type Registry" to the "Packet Delay Variation Metrics Block". 438 [Note to RFC Editor: please replace NPDV with the IANA provided RTCP 439 XR block type for this block.] 441 5.2. New RTCP XR SDP Parameter 443 This document also registers a new parameter "pkt-dly-var" in the 444 "RTCP XR SDP Parameters Registry". 446 5.3. Contact information for registrations 448 The contact information for the registrations is: 450 Qin Wu (sunseawq@huawei.com) 452 101 Software Avenue, Yuhua District 453 Nanjing, Jiangsu 210012 454 China 456 5.4. New registry of PDV types 458 This document creates a new registry to be called "RTCP XR PDV block 459 - PDV type" as a sub-registry of the "RTP Control Protocol Extended 460 Reports (RTCP XR) Block Type Registry". Policies for this new 461 registry are as follows: 463 o The information required to support an assignment is an 464 unambiguous definition of the new metric, covering the base 465 measurements and how they are processed to generate the reported 466 metric. This should include the units of measurement, how values 467 of the metric are reported in the three 16-bit fields "Pos PDV 468 Threshold/Peak", "Neg PDV Threshold/Peak" and "Mean PDV" within 469 the report block, and how the metric uses the two 16-bit fields 470 "Pos PDV Percentile" and "Neg PDV Percentile". 472 o The review process for the registry is "Specification Required" as 473 described in Section 4.1 of [RFC5226]. 475 o Entries in the registry are integers. The valid range is 0 to 15 476 corresponding to the 4-bit field "pdvtyp" in the block. Values 477 are to be recorded in decimal. 479 o Initial assignments are as follows: 481 * 0: MAPDV2, Clause 6.2.3.2 of [G.1020], 483 * 1: 2-point PDV, Clause 6.2.4 of [Y.1540] 485 6. Security Considerations 487 It is believed that this proposed RTCP XR report block introduces no 488 new security considerations beyond those described in [RFC3611]. 489 This block does not provide per-packet statistics so the risk to 490 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 491 does not apply. 493 7. References 495 7.1. Normative References 497 [G.1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter 498 definitions for quality of speech and other voiceband 499 applications utilizing IP networks", July 2006. 501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 502 Requirement Levels", March 1997. 504 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 505 Applications", RFC 3550, July 2003. 507 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 508 Protocol Extended Reports (RTCP XR)", November 2003. 510 [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s 511 Transparent Call", April 2005. 513 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 514 Description Protocol", July 2006. 516 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 517 Section in RFCs", May 2008. 519 BCP 26 521 [Y.1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 522 availability performance parameters", November 2007. 524 7.2. Informative References 526 [MEASI] Hunt, G., "Measurement Identity and information Reporting 527 using SDES item and XR Block", 528 ID draft-ietf-xrblock-rtcp-xr-meas-identity-06, 529 April 2012. 531 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 532 ID draft-ietf-avtcore-monarch-13, May 2012. 534 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 535 Applicability Statement", RFC 5481, March 2009. 537 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 538 Development", RFC 6390, October 2011. 540 Appendix A. Change Log 542 Note to the RFC-Editor: please remove this section prior to 543 publication as an RFC. 545 A.1. draft-ietf-xrblock-rtcp-xr-pdv-03 547 The following are the major changes to previous version 548 draft-ietf-xrblock-rtcp-xr-pdv-02: 550 o Make definition of pdvtype get alignment with IANA section. 552 o Make Guidance on use of PDV metrics get alignment with RFC5481. 554 o Other Editorial changes. 556 A.2. draft-ietf-xrblock-rtcp-xr-pdv-02 558 The following are the major changes to previous version 559 draft-ietf-xrblock-rtcp-xr-pdv-01: 561 o Updated references. 563 o Allocate one more bit for Interval metric flag to indicate sampled 564 metric can be used. 566 o Add a few clarification text for failure mode. 568 A.3. draft-ietf-xrblock-rtcp-xr-pdv-01 570 The following are the major changes to previous version 571 draft-ietf-xrblock-rtcp-xr-pdv-00: 573 o Fix typos or nits in the definition of Negative PDV Threshold/ 574 Peak. 576 o Fix nits in Numeric format S7:8. 578 o remove the text that is relevant to tag field. 580 o Add text in SDP signaling section to clarify indicationof metric 581 unavailable. 583 A.4. draft-ietf-xrblock-rtcp-xr-pdv-00 585 The following are the major changes to previous version 586 draft-ietf-avt-rtcp-xr-pdv-03: 588 o Updated references. 590 A.5. draft-ietf-avt-rtcp-xr-pdv-03 592 The following are the major changes to previous version : 594 o Changed BNF for SDP following Christian Groves' and Tom Taylor's 595 comments (4th and 5th May 2009). 597 o Updated references. 599 Authors' Addresses 601 Geoff Hunt 602 Unaffiliated 604 Email: r.geoff.hunt@gmail.com 606 Alan Clark 607 Telchemy Incorporated 608 2905 Premiere Parkway, Suite 280 609 Duluth, GA 30097 610 USA 612 Email: alan.d.clark@telchemy.com 614 Qin Wu 615 Huawei 616 101 Software Avenue, Yuhua District 617 Nanjing, Jiangsu 210012 618 China 620 Email: sunseawq@huawei.com