idnits 2.17.1 draft-hunt-avt-monarch-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 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 (May 18, 2010) is 5084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Unexpected draft version: The latest known version of draft-ott-avt-rtcp-guidelines is -01, but you're referring to -03. -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working G. Hunt 3 Group P. Arden 4 Internet-Draft BT 5 Intended status: Informational May 18, 2010 6 Expires: November 19, 2010 8 Monitoring Architectures for RTP 9 draft-hunt-avt-monarch-01.txt 11 Abstract 13 This memo proposes an architecture for extending RTCP with a new RTCP 14 XR (RFC3611) block type to report new metrics regarding media 15 transmission or reception quality, as proposed in 16 draft-ietf-avt-rtcp-guidelines (work in progress [replace with RFC 17 number]). This memo suggests that a new block should contain a 18 single metric or a small number of metrics relevant to a single 19 parameter of interest or concern, rather than containing a number of 20 metrics which attempt to provide full coverage of all those 21 parameters of concern to a specific application. Applications may 22 then "mix and match" to create a set of blocks which covers their set 23 of concerns. Where possible, a specific block should be designed to 24 be re-usable across more than one application, for example, for all 25 of voice, streaming audio and video. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 19, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 63 3. Using small blocks . . . . . . . . . . . . . . . . . . . . . . 5 64 4. The identity block . . . . . . . . . . . . . . . . . . . . . . 6 65 5. An example of a metric block . . . . . . . . . . . . . . . . . 10 66 6. Application to translators . . . . . . . . . . . . . . . . . . 11 67 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 12 68 8. Expanding the RTCP XR block namespace . . . . . . . . . . . . 13 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 71 11. Informative References . . . . . . . . . . . . . . . . . . . . 16 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 74 1. Introduction 76 Any proliferation of metrics for transport and application quality 77 monitoring has been identified as a potential problem for RTP/RTCP 78 interoperability. Different applications layered on RTP may have 79 some monitoring requirements in common, which should be satisfied by 80 a common design. The objective here is to define an extensible 81 framework and a small number of re-usable metrics to reduce 82 implementation costs and to maximise inter-operability. Work-in- 83 progress on [GUIDELINES] has stated that, where RTCP is to be 84 extended with a new metric, the preferred mechanism is by the 85 addition of a new RTCP XR [RFC3611] block. This memo assumes that 86 any requirement for a new metric to be transported in RTCP will use a 87 new RTCP XR block. 89 [GUIDELINES] provides advice on when and how new metrics should be 90 introduced, including recommending that metrics are based on existing 91 standards whenever possible. 93 Section 3 describes the key proposal of this memo, the use of small 94 metrics blocks each of which addresses a single parameter of interest 95 which may be "mixed and matched", rather than providing a large block 96 to address all the parameters which might be of interest to a broad 97 class of applications (for example, all VoIP applications). 99 Section 4 describes an optimisation to avoid repetition of 100 identification information, which becomes desirable when small blocks 101 are used. 103 Section 5 provides an example of the application of these principles 104 to a specific case, that of a metric block to report packet delay 105 variation. 107 Section 6 draws attention to the guidance in [RFC3550] concerning 108 RTCP and translators. 110 Section 7 discusses the potential application of RTCP XR metrics 111 blocks to the conferencing topologies discussed in [RFC5117]. 113 Section 8 consists (in this draft) only of an "Editor's note" asking 114 whether the limited namespace available for RTCP XR blocks is a 115 concern, and if so whether it would be desirable to work on a 116 standardised means to expand it. 118 2. Requirements notation 120 This memo is informative and as such contains no normative 121 requirements. 123 3. Using small blocks 125 Different applications using RTP for media transport certainly have 126 differing requirements for metrics transported in RTCP to support 127 their operation. For many applications, the basic metrics for 128 transport impairments provided in RTCP SR and RR packets [RFC3550] 129 (together with source identification provided in RTCP SDES packets) 130 are sufficient. For other applications additional metrics may be 131 required or at least sufficiently useful to justify the overheads, 132 both of processing in endpoints and of increased session bandwidth. 133 For example an IPTV application using Forward Error Correction (FEC) 134 might use either a metric of post-repair loss or a metric giving 135 detailed information about pre-repair loss bursts to optimise payload 136 bandwidth and the strength of FEC required for changing network 137 conditions. However there are many metrics available. It is likely 138 that different applications or classes of applications will wish to 139 use different metrics. Any one application is likely to require 140 metrics for more than one parameter but if this is the case, 141 different applications will almost certainly require different 142 combinations of metrics. If larger blocks are defined containing 143 multiple metrics to address the needs of each application, it becomes 144 likely that many different such larger blocks are defined, which 145 becomes a danger to interoperability. 147 To avoid this pitfall, this memo proposes the use of small RTCP XR 148 metrics blocks each containing a very small number of individual 149 metrics characterising only one parameter of interest to an 150 application running over RTP. For example, at the RTP transport 151 layer, the parameter of interest might be packet delay variation, and 152 specifically the metric "IPDV" defined by [Y1540]. See Section 5 for 153 architectural considerations for a metrics block, using as an example 154 a metrics block to report packet delay variation. 156 4. The identity block 158 Any measurement must be identified. However if metrics are delivered 159 in small blocks there is a danger of inefficiency arising from 160 repeating this information in a number of metrics blocks within the 161 same RTCP packet, in cases where the same identification information 162 applies to multiple metrics blocks. 164 An instance of a metric must be identified using information which is 165 likely to include most of the following: 167 o the node at which it was measured, 169 o the source of the measured stream (for example, its CNAME), 171 o the SSRC of the measured stream, 173 o the sequence number of the first packet of the RTP session, 175 o the extended sequence numbers of the first packet of the current 176 measurement interval, and the last packet included in the 177 measurement, 179 o the duration of the most recent measurement interval and 181 o the duration of the interval applicable to cumulative measurements 182 (which may be the duration of the RTP session to date). 184 [Editor's note: this set of information overlaps with, but is more 185 extensive than, that in the union of similar information in RTCP RR 186 packets. Should we assume that RR information is always present if 187 XR is sent, and that measurement intervals are exactly coincident? 188 If so, state assumption and remove overlaps. What were the design 189 considerations which led to the additional information *not* being 190 present in RRs? The reason for the additional information here is 191 the perceived difficulty of "locating" the *start* of the RTP session 192 (sequence number of 1st packet, duration of interval applicable to 193 cumulative measurements) using only RR. Is this a misconception? It 194 leads to redundant information in this design because equivalent 195 information is provided multiple times, once in *every* 196 identification packet. Though this ensures immunity to packet loss, 197 the design is ugly and the overhead is not completely trivial.] 199 This section proposes an approach to minimise the inefficiency of 200 providing this identification information, assuming that an 201 architecture based on small blocks means that a typical RTCP packet 202 will contain more than one metrics block needing the same 203 identification. The choice of identification information to be 204 provided is discussed in [IDENTITY] (work in progress). 206 The approach is to define a stand-alone block containing only 207 identification information, and to tag this identification block with 208 a number which is unique within the scope of the containing RTCP XR 209 packet. The "containing RTCP XR packet" is defined here as the RTCP 210 XR header with PT=XR=207 defined in Section 2 of [RFC3611] and the 211 associated payload defined by the length field of this RTCP XR 212 header. The RTCP XR header itself includes the SSRC of the node at 213 which all of the contained metrics were measured, hence this SSRC 214 need not be repeated in the stand-alone identification block. A 215 single containing RTCP XR packet may contain multiple identification 216 blocks limited by the range of the tag field. Typically there will 217 be one identification block per monitored source SSRC, but the use of 218 more than one identification block for a single monitored source SSRC 219 within a single containing RTCP XR packet is not ruled out. 221 There will be zero or more metrics blocks dependent on each 222 identification block. The dependence of an instance of a metrics 223 block on an identification block is established by the metrics 224 block's having the same numeric value of the tag field as its 225 identification block (in the same containing RTCP XR packet). 227 Figure 1 below illustrates this principle using as an example an RTCP 228 XR packet containing four metrics blocks, reporting on streams from 229 two sources. The measurement identity information is provided in two 230 blocks with Block Type NMI, and tag values 0 and 1 respectively. 232 Note: in this example, RTCP XR block type values for four proposed 233 new block types (work in progress) are given as NMI, NPDV, NBGL and 234 NDEL. These represent numeric block type codepoints to be allocated 235 by IANA at the conclusion of the work. 237 Each of these two identity blocks will specify the SSRC of one of the 238 monitored streams, as well as information about the span of the 239 measurement. There are two metrics blocks with tag=0 indicating 240 their association with the measurement identity block which also has 241 tag=0. These are the two blocks following the identity block with 242 tag=0, though this positioning is not mandatory. There are also two 243 metrics blocks with tag=1 indicating their association with the 244 measurement identity block which also has tag=1, and these are the 245 two blocks following the identity block with tag=1. 247 [Editor's note: if we mandated that metrics blocks associated with an 248 identity block must always follow the identity block we could save 249 the tag field and possibly simplify processing. Is this preferable 250 to cross-referencing with a numeric tag?] 251 In the example, the block types of the metrics blocks associated with 252 tag=0 are BT=NPDV (a PDV metrics block) and BT=NBGL (a burst and gap 253 loss metrics block). The block types of the metrics blocks 254 associated with tag=1 are BT=NPDV (a second PDV metrics block) and 255 BT=NDEL (a delay metrics block). This illustrates that: 257 o multiple instances of the same metrics block may occur within a 258 containing RTCP XR packet, associated with different 259 identification information, and 261 o differing measurements may be made, and reported, for the 262 different streams arriving at an RTP system. 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |V=2|P|reserved | PT=XR=207 | length | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | SSRC of RTCP XR packet sender | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | BT=NMI |0|tag=0| resv | block length | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | SSRC of stream source 1 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 . ...measurement identity information, source 1... . 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | BT=NPDV |I|tag=0|pdvtyp | block length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 . ...PDV information for source 1... . 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | BT=NBGL |I|tag=0| resv | block length | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 . ...burst-gap-loss information for source 1... . 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | BT=NMI |0|tag=1| resv | block length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | SSRC of stream source 2 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 . ...measurement identity information, source 2... . 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | BT=NPDV |I|tag=1|pdvtyp | block length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 . ...PDV information for source 2... . 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | BT=NDEL |I|tag=1| resv | block length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 . ...delay information for source 2... . 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Figure 1: RTCP XR block with identity blocks 302 This approach of separating the identification information is more 303 costly than providing identification in each metrics block if only a 304 single metrics block is sent in an RTCP packet, but becomes 305 beneficial as soon as more than one metrics block shares common 306 identification. 308 5. An example of a metric block 310 This section uses the example of an existing proposed metrics block 311 to illustrate the application of the principles set out in Section 3. 313 The example [PDV] (work in progress) is a block to convey information 314 about packet delay variation (PDV) only, consistent with the 315 principle that a metrics block should address only one parameter of 316 interest. One simple metric of PDV is available in the RTCP RR 317 packet as the "jit" field. There are other PDV metrics which may be 318 more useful to certain applications. Two such metrics are the IPDV 319 metric ([Y1540], [RFC3393]) and the MAPDV2 metric [G1020]. Use of 320 these metrics is consistent with the principle in Section 5 of 321 [GUIDELINES] that metrics should usually be defined elsewhere, so 322 that RTCP standards define only the transport of the metric rather 323 than its nature. The purpose of this section is to illustrate the 324 architecure using the example of [PDV] (work in progress) rather than 325 to document the design of the PDV metrics block or to provide a 326 tutorial on PDV in general. 328 Given the availability of at least three metrics for PDV, there are 329 design options for the allocation of metrics to RTCP XR blocks: 331 o provide an RTCP XR block per metric 333 o provide a single RTCP XR block which contains all three metrics 335 o provide a single RTCP block to convey any one of the three 336 metrics, together with a identifier to inform the receiving RTP 337 system of the specific metric being conveyed 339 In choosing between these options, extensibility is important, 340 because additional metrics of PDV may well be standardised and 341 require inclusion in this framework. The first option is extensible 342 but only by use of additional RTCP XR blocks, which may consume the 343 limited namespace for RTCP XR blocks at an unacceptable rate. The 344 second option is not extensible, so could be rejected on that basis, 345 but in any case a single application is quite unlikely to require 346 transport of more than one metric for PDV. Hence the third option 347 was chosen. This implies the creation of a subsidiary namespace to 348 enumerate the PDV metrics which may be transported by this block, as 349 discussed further in [PDV] (work in progress). 351 6. Application to translators 353 Section 7.2 of [RFC3550] describes processing of RTCP by translators. 354 RTCP XR is within the scope of the recommendations of [RFC3550]. 355 Some RTCP XR metrics blocks may usefully be measured at, and reported 356 by, translators. As described in [RFC3550] this creates a 357 requirement for the translator to allocate an SSRC for itself so that 358 it may populate the SSRC in the RTCP XR packet header (although the 359 translator is not a Synchronisation Source in the sense of 360 originating RTP media packets). It must also supply this SSRC and 361 the corresponding CNAME in RTCP SDES packets. 363 In RTP sessions where one or more translators generate any RTCP 364 traffic towards their next-neighbour RTP system, other translators in 365 the session have a choice as to whether they forward a translator's 366 RTCP packets. Forwarding may provide additional information to other 367 RTP systems in the connection but increases RTCP bandwidth and may in 368 some cases present a security risk. RTP translators may have 369 forwarding behaviour based on local policy, which might differ 370 between different interfaces of the same translator. 372 [Editor's note: for bidirectional unicast, an RTP system may usually 373 detect RTCP from a translator by noting that the sending SSRC is not 374 present in any RTP media packet. However even for bidirectional 375 unicast there is a possibility of a source sending RTCP before it has 376 sent any RTP media (leading to transient mis-categorisation of an RTP 377 end system or RTP mixer as a translator), and for multicast sessions 378 - or unidirectional/streaming unicast - there is a possibility of a 379 receive-only end system being permanently mis-categorised as a 380 translator. Is there a need for a translator to declare itself 381 explicitly? Needs further thought.] 383 7. Application to RFC 5117 topologies 385 An RTP system (end system, mixer or translator) which originates, 386 terminates or forwards RTCP XR blocks is expected to handle RTCP, 387 including RTCP XR, as specified in [RFC3550] for that class of RTP 388 systems. Provided this expectation is met, an RTP system using RTCP 389 XR is architecturally no different from an RTP system of the same 390 class (end system, mixer, or translator) which does not use RTCP XR. 391 This statement applies to the topologies investigated in [RFC5117], 392 where they use RTP end systems, RTP mixers and RTP translators as 393 these classes are defined in [RFC3550]. 395 These topologies are specifically Topo-Point-to-Point, Topo- 396 Multicast, Topo-Translator (both variants, Topo-Trn-Translator and 397 Topo-Media-Translator, and combinations of the two), and Topo-Mixer. 399 The topologies based on systems which do not behave according to 400 [RFC3550], that is Topo-Video-Switch-MCU and Topo-RTCP-terminating- 401 MCU, suffer from the difficulties described in [RFC5117]. These 402 difficulties apply to systems sending, and expecting to receive, RTCP 403 XR blocks as much as to systems using other RTCP packet types. For 404 example, a participant RTP end system may send media to a video 405 switch MCU. If the media stream is not selected for forwarding by 406 the switch, neither RTCP RR packets nor RTCP XR blocks referring to 407 the end system's generated stream will be received at the RTP end 408 system. Strictly the RTP end system can only conclude that its RTP 409 has been lost in the network, though an RTP end system complying with 410 the robustness principle of [RFC1122] should survive with essential 411 functions unimpaired. 413 8. Expanding the RTCP XR block namespace 415 [Editor's note: the RTCP XR block namespace is limited by the 8-bit 416 block type field in the RTCP XR header (Section 3 of [RFC3611]). 417 IESG have noted that this is potentially restrictive. It would be 418 possible to standardise an expansion mechanism, probably based on use 419 of a new field near the start of the variable-length "type-specific 420 block contents" field. Clearly this could apply only to new block 421 types, so might be standardised to apply to some subrange of the 422 current 8-bit range, for example the range 128 through 191 might be 423 used. At time of writing, block types 12 to 254 are unassigned and 424 255 is reserved for future expansion. Is there a consensus for, or 425 against, work to allow expansion? One potential use is through 426 hierarchical control, where one or a few codepoints at the top level 427 are given to other SDOs who may then define a number of metrics 428 distinguished by values in the (so far hypothetical) new field.] 430 9. IANA Considerations 432 None. 434 10. Security Considerations 436 This document itself contains no normative text and hence should not 437 give rise to any new security considerations, to be confirmed. 439 11. Informative References 441 [G1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter 442 definitions for quality of speech and other voiceband 443 applications utilizing IP networks", July 2006. 445 [GUIDELINES] 446 Ott, J., "Guidelines for Extending the RTP Control 447 Protocol (RTCP)", ID draft-ott-avt-rtcp-guidelines-03, 448 February 2010. 450 [IDENTITY] 451 Hunt, G., "RTCP XR Report Block for Measurement Identity", 452 ID draft-ietf-avt-rtcp-xr-meas-identity-02, May 2009. 454 [PDV] Hunt, G., "RTCP XR Report Block for Packet Delay Variation 455 Metric Reporting", ID draft-ietf-avt-rtcp-xr-pdv-03, 456 May 2009. 458 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 459 Communication Layers", RFC 1122, October 1989. 461 [RFC3393] Demichelis, C., "IP Packet Delay Variation Metric for IP 462 Performance Metrics (IPPM)", RFC 3393, November 2002. 464 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 465 Applications", RFC 3550, July 2003. 467 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 468 XR)", RFC 3611, November 2003. 470 [RFC5117] Westerlund, M., "RTP Topologies", RFC 5117, January 2008. 472 [Y1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 473 availability performance parameters", November 2007. 475 Authors' Addresses 477 Geoff Hunt 478 BT 479 Orion 1 PP2 480 Adastral Park 481 Martlesham Heath 482 Ipswich, Suffolk IP5 3RE 483 United Kingdom 485 Phone: +44 1473 651704 486 Email: geoff.hunt@bt.com 488 Philip Arden 489 BT 490 Orion 3/7 PP4 491 Adastral Park 492 Martlesham Heath 493 Ipswich, Suffolk IP5 3RE 494 United Kingdom 496 Phone: +44 1473 644192 497 Email: philip.arden@bt.com