idnits 2.17.1 draft-akhter-opsawg-perfmon-method-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2012) is 4384 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: 'RFC5610' is defined on line 781, but no explicit reference was found in the text == Unused Reference: 'RFC5102' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pmol-metrics-framework' is defined on line 818, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Akhter 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track March 27, 2012 5 Expires: September 28, 2012 7 Methodology for Network Flow Performance Measurement 8 draft-akhter-opsawg-perfmon-method-02.txt 10 Abstract 12 There is a need to be able to quantify and report the performance of 13 network applications and the network service in handling user data. 14 This performance data provides information essential in validating 15 service level agreements, fault isolation as well as early warnings 16 of network greater problems. This document describes a generic 17 methodology for calculating metrics related to network based 18 applications. In addition, to the performance metrics, several 19 additional information elements are included to help provide greater 20 context to the reports. The measurements use audio/video 21 applications as base examples but are not restricted to these class 22 of applications. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 28, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 5 62 3.2. Service Level Agreemnt (SLA) Validation . . . . . . . . . 5 63 3.3. Fault Isolation and Troubleshooting . . . . . . . . . . . 5 64 4. New Information Elements . . . . . . . . . . . . . . . . . . . 6 65 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.1. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 6 67 4.1.2. perfPacketExpected . . . . . . . . . . . . . . . . . . 8 68 4.1.3. perfPacketLossRate . . . . . . . . . . . . . . . . . . 9 69 4.1.4. perfPacketLossEvent . . . . . . . . . . . . . . . . . 10 70 4.1.5. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 11 71 4.1.6. perfPacketInterArrivalJitterMin . . . . . . . . . . . 12 72 4.1.7. perfPacketInterArrivalJitterMax . . . . . . . . . . . 13 73 4.1.8. perfRoundTripNetworkDelay . . . . . . . . . . . . . . 13 74 4.2. User and Application Layer . . . . . . . . . . . . . . . . 14 75 4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 14 76 4.3. Contextual Elements . . . . . . . . . . . . . . . . . . . 15 77 4.3.1. mediaRTPSSRC . . . . . . . . . . . . . . . . . . . . . 15 78 4.3.2. mediaRTPPayloadType . . . . . . . . . . . . . . . . . 16 79 4.3.3. mimeType . . . . . . . . . . . . . . . . . . . . . . . 16 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 84 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 Today's networks support a multitude of highly demanding and 90 sensitive network applications. Network issues are readily apparent 91 by the users of these applications due to the sensitivity of these 92 applications to impaired network conditions. Examples of these 93 network applications include applications making use of IP based 94 audio, video, database transactions, virtual desktop interface (VDI), 95 online gaming, cloud services and many more. In some cases, the 96 impaired application translates directly to loss of revenue. In 97 other cases, there may be regulatory or contractual service level 98 agreements that motivate the network operator. Due to the 99 sensitivity of these types of applications to impaired service, it 100 leaves a poor impression of the network service on the user-- 101 regardless of the actual performance of the network itself. In the 102 case of an actual problem within the network service, monitoring the 103 performance may yield an early indicator of a much more serious 104 problem. 106 Due to the demanding and sensitive nature of these applications, 107 network operators have tried to engineer their networks towards 108 wringing better and differentiated performance. However, that same 109 differentiated design prevents network operators from extrapolating 110 observational data from one application to another, or from one set 111 of synthetic (active test) test traffic to actual application 112 performance. This gap highlights the importance of generic 113 measurements as well as the reliance on user traffic measurents-- 114 rather than synthetic tests. 116 Performance measurements on user data provide greater visibility not 117 only into the quality of experience of the end users but also 118 visibility into network health. With regards to network health, as 119 flow performance is being measured, there will be visibility into the 120 end to end performance which means that not only visibility into 121 local network health, but also viability into remote network health. 122 If these measurements are made at multiple points within the network 123 (or between the network and end device) then there is not only 124 identification that there might be an issue, but a span of area can 125 be established where the issue might be. The resolution of the fault 126 increases with the number of measurement points along the flow path. 128 The IP Flow Information Export Protocol (IPFIX) [RFC5101] provides 129 new levels of flexibility in reporting from measurement points across 130 the life cycle of a network based application. IPFIX can provide 131 granular results in terms of flow specificity as well as time 132 granularity. At the same time, IPFIX allows for summarization of 133 data along different types of boundaries for operators that are 134 unconcerned about specific sessions but about health of a service or 135 a portion of the network. This document details the methodlogy of 136 measurement, while an accompanying document describes the expression 137 of the measurements in IPFIX format. 139 Where possible, an attempt has been made to make use of existing 140 definitions of metrics ([RFC4710]) and if needed, clarify and expand 141 on them to widen their usage with additional applications, and 142 network devices. For example, the RTP measurments have generally 143 defined from the prespective of end systems rather than intermdiate 144 nodes which are not alwyas privy to the application context and may 145 have limited scaling properties. The methodology described in 146 [I-D.ietf-pmol-sip-perf-metrics] is used to describe the methodology 147 of measurement. 149 There has been related work in this area such as [RFC2321]. 150 [I-D.huici-ipfix-sipfix], and [VoIP-monitor]. This document is also 151 an attempt to generalize as well as standardize the reporting formats 152 and measurement methodology. 154 2. Terminology 156 Terms used in this document that are defined in the Terminology 157 section of the IPFIX Protocol [RFC5101] document are to be 158 interpreted as defined there. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 In addition, the information element definitions use the following 165 terms: 167 Name: Name of the information element 169 Description: Short description of what the information element is 170 trying to convey. 172 Observation Point: Where the measurement is meant to be performed. 173 Either at an intermediate system (for example, a router) or end 174 system. 176 Use and Applications An explanation of how this particular 177 information element would be used. 179 Calculation Method: In the case of metrics, this section describes 180 how the metric is calculated, as well as any special conditions. 182 Units of Measurement: In the case of metrics, what are the units of 183 measurement. The text here is expected to be wider and more 184 descriptive than in the IPFIX Element Units section. 186 Measurement Timing: Discussion on the acceptable range of timing and 187 sampling intervals. 189 3. General Usage 191 3.1. Quality of Service (QoS) Monitoring 193 The network operator needs to be able to gauge the end user's 194 satisfaction with the network service. While there are many 195 components of the satisfaction such as pricing, packaging, offering, 196 etc., a major component of satisfaction is delivering a consistent 197 service. The user builds trust on this consistency of the network 198 service and runs network applications with confidence-- which is of 199 course the end goal. Without the ability to deliver a consistent 200 service for end user network applications network operator will be 201 left dealing with price sensitive disgruntled users with very low 202 expectations and utilization (if they don't have choice of operator) 203 or abandonment (if they have choice). 205 3.2. Service Level Agreemnt (SLA) Validation 207 Similar to QoS and QoE validation, there might be contractual or 208 regulatory requirements that need to be met by the network operator. 209 Monitoring the performance of the flows allows the application 210 operator, network operator as well as the end user to validate if the 211 target service is being delivered. While there is quite a diversity 212 in the codification of network SLAs, the eventually involve some 213 measurement of network uptime, end to end latency, end to end jitter 214 and perhaps service response time. In the case of SLA violation, the 215 start and end times, nature and network scope of the violation needs 216 to be captured to allow for the most accurate settling of the SLA 217 violation. 219 3.3. Fault Isolation and Troubleshooting 221 It has been generally easier to troubleshoot and fix problems that 222 are binary in nature: it either works or does not work. The host is 223 pingable or not pingable. However, it is the much more difficult to 224 resolve transitory issues that move from location to location, are 225 not complete faiures and sometimes with unverfifiable end user 226 reports as the only indication of a problem. It is these 227 intermittent and seemingly inconsistent network impairments that 228 performance metrics can be extremely helpful with. Just the basic 229 timely detection that there is a problem (or an impending problem) 230 can give the operator provider the confidence that there is a real 231 problem that needs to be resolved. The next step would be to assist 232 the operator in a speedy resolution by providing information 233 regarding the network location and nature of the problem. 235 4. New Information Elements 237 The information elements are organized into two main groups: 239 Transport Layer: Metrics that might be calculated from observations 240 at higher layers but essentially provide information about the 241 network transport of user date. For example, the metrics related 242 to packet loss, latency and jitter would be defined here. 244 User and Application Layer: Metrics that are might be affected by 245 the network indirectly, but are ultimately related to user, end- 246 system and session states. For example, session setup time, 247 transaction rate and session duration would be defined here. 249 Contextual Elements: Information elements that provide further 250 context to the metrics. For example, media type, codec type, and 251 type of application would be defined here. 253 4.1. Transport Layer 255 4.1.1. perfPacketLoss 257 Name: perfPacketLoss 259 Description: The packet loss metric reports the number of individual 260 packets that were lost in the reporting interval. 262 Observation Point: The observation can be made anywhere along the 263 media path or on the endpoints them selves. The observation is 264 only relevant in a unidirectional sense. 266 Use and Applications The packet loss metric can be used to determine 267 if there is a network impairment that is causing packet loss 268 upstream of the measurement point. When there are observation 269 points on either side of the impairment location it is possible to 270 locate the impairment. With the location information the operator 271 can is able to perform quicker fault-isolation as well as shorten 272 time to resolution. Depending on implementation and operator 273 configuration, the granularity of contextual information can be 274 very specific. For example, these traffic loss statistics when 275 sent with IP subnet or DSCP information can provide visibilty into 276 QoS specific or network topology issues. 278 Calculation Method: This metric requires that each IP packet be 279 individually marked with a monotonically incrementing sequence 280 number. A number of encapsulations support this type of 281 sequencing: IPSec ESP [RFC4303], GRE [RFC2890] and RTP [RFC3550]. 282 An analysis of the sequence number field can yield the lost number 283 of packets. In certain cases, there might be an element of 284 discovery and synchronization of the flow itself before the 285 measurement can be made. An example of this can be found for RTP 286 flows running on ephemeral UDP port numbers. In these cases, 287 reporting 0 as packet loss would be misleading and the value 288 0xFFFFFFFF MUST be used in cases where the packet loss value 289 cannot be determined. In the case of a monitor interval where 290 synchronization was achieved mid-interval, the loss packet counter 291 MAY be used to represent the remainder of the interval. As this 292 metric is a deltaCounter, the number of loss packets only 293 represent the observation within the reporting interval. Due to 294 the dependency on the arrival of a packet with a sequence number 295 to calculate loss, the loss calculation may be indefinitely 296 delayed if no more packets arrive at all. For the case of RTP, in 297 addition to the 16 bit sequence number field in RFC3550, there is 298 also the additional 16-bit high-order sequence number field (for a 299 total of 32-bit seq number space) that is used in RFC3497 300 [RFC3497]. RFC3497 traffic runs at a very high rate and the 32- 301 bit field allow for additional time for wrapping (21 seconds). 302 So, a loss span of greater than 21 seconds measured only by the 303 16-bit field will lead to inaccurate reporting. In the case of 304 secure RTP [RFC3711], the relevant portion of the RTP header is in 305 the clear and lost packet counting can still be performed. It is 306 important to note that the sequence number space is unique per RTP 307 SSRC. Therefore it is important to track the high sequence number 308 seen on a per SSRC-5-tuple basis. There may be multiple SSRCs in 309 a single 5-tuple. Certain applications inject non-RTP traffic 310 into the same 5-tuple as the media stream. RTCP packets may be 311 seen in the same 5-tuple as the RTP stream [RFC5761], and STUN 312 [RFC5389] packets may also be seen. The loss detection should 313 ignore these packets. There may be spans within the network where 314 header compression schemes such as [RFC2508] are used. In cases 315 where the measurement device is terminating the compression, and 316 the measurement implementation does not support calculation of the 317 metric the value 0xFFFFFFFF MUST be reported. In other cases the 318 measurement point may be at a midpoint of the header compression 319 network span. Depending on the mechanics of header compression, 320 sequencing information may be present and it is possible to 321 calculate the metric. In such cases the implementation SHOULD 322 perform the calculation and report the metric. 324 Units of Measurement: packets 326 Measurment Timing To be able to calculate this metric a continuous 327 set of the flow's packets (as each would have an incrementing 328 sequence number) needs to be monitored. Therefore, per-packet 329 sampling would prevent this metric from being calculated. 330 However, there are other sampling methodologies that might be 331 usable. It is possible to generate sampled metrics by sampling 332 spans of continuous packets, however a portion of the span may 333 have to be utilized for resynchronization of the sequence number. 334 Another form of acceptable sampling would be at the flow level. 336 4.1.2. perfPacketExpected 338 Name: perfPacketExpected 340 Description: The number of packets there were expected within a 341 monitoring interval. 343 Observation Point: The observation can be made anywhere along the 344 media path or on the endpoints them selves. The observation is 345 only relevant in a unidirectional sense. 347 Use and Applications The perfPacketExpected is a mid-calculation 348 metric used in the generation of perfPacketLossRate. It is 349 equivilent to the highest received packet sequence number at the 350 time of measurement. As the value only increments when packets 351 are received, packet loss may be occouring at the time of 352 measurement but perfPacketExpected remains constant. 354 Calculation Method: The subtraction of the last sequence number from 355 the first sequence number in monitoring interval yields the 356 expected count. As discussed with perfPacketLost, there might be 357 a delay due to synchronization with the flow's sequence numbers 358 and in such times the value of the metric should be set to 359 0xFFFFFFFE. Care has to be taken to account for cases where the 360 packet's sequence number field wraps. For RTP, the expected count 361 calculation formula can be found in Appendix A.3 of [RFC3550]. 362 Refer to the perfPacketLoss metric regarding considerations for 363 header compression. The value 0xFFFF is used to represent cases 364 where the metric could not be calculated. 366 Units of Measurement: packets 368 Measurment Timing Same considerations as perfPacketLoss 370 4.1.3. perfPacketLossRate 372 Name: perfPacketLossPercentage 374 Description: Percentage of number of packets lost out of the total 375 set of packets sent. 377 Observation Point: The observation can be made anywhere along the 378 media path or on the endpoints them selves. The observation is 379 only relevant in a unidirectional sense. 381 Use and Applications The perfPacketLossRate metric can be used to 382 normalize the perfPacketLoss metric to handle cases where 383 different flows are running at different packet per second (PPS) 384 rates. Due to the normalization, comparisons can now be made 385 against thresholds (for creating alerts, etc.). In addition, the 386 percentage form of the metric allows for comparisons against other 387 flows at the same observation point to determine if there is an 388 equal bias for drops between the flows. Otherwise, the 389 perfoPacketLossRate is used in same way as perfPacketLoss. This 390 value can be derived from perfPacketExpected and perfPacketLoss 391 and is offered as a convenience to ease functions such as 392 thresholding, and pre-computed reporting. It shoudl be noted that 393 for large values of perfPacketExpected and perfPacketLoss it might 394 be preferable and more accurate for the conversion to percentage 395 to occour at a later stage where the accuracy can be controlled. 397 Calculation Method: The number of lost packets divided by the number 398 of expected packets in an interval period multiplied by 100. In 399 cases where perfPacketLoss is unknown (for example due to 400 synchronization issues), the perfPacketLossRate would also be 401 unknown. If there are multiple flows whose loss rate is being 402 aggregated, then the average of the individual flows is used. 403 Refer to the perfPacketLoss metric regarding considerations for 404 header compression. 406 Units of Measurement: percentage 408 Measurment Timing Same notes as perfPacketLossPercentage 410 4.1.4. perfPacketLossEvent 412 Name: perfPacketLossEvent 414 Description: The packet loss event metric reports the number of 415 continuous sets of packets that were lost in the reporting 416 interval. 418 Observation Point: The observation can be made anywhere along the 419 media path or on the endpoints them selves. The observation is 420 only relevant in a unidirectional sense. 422 Use and Applications The perfPacketLossEvent metric can provide loss 423 information for protocols that do not implement per packet 424 sequencing. Similarly to the perfPacketLoss metric, the packet 425 loss event metric can be used to determine if there is a network 426 impairment that is causing packet loss upstream of the measurement 427 point. In cases where both the perfPacketLoss and 428 perfPacketLossEvent metric are available, the ratio between the 429 packet loss and packet event count can provide the average loss 430 length. The average loss length provides additional information 431 regarding the cause of the loss. For example, a dirty fiber 432 connection might have a low average loss length, while a routing 433 protocol convergence will have a high loss length. 435 Calculation Method: This data value is a simplified version of the 436 Lost Packets metric. Whereas Lost Packets counts individual 437 packet loss, the 'loss event count' metric counts sets of packets 438 that are lost. For example, in the case of a sequence of packets: 439 1,3,6,7,10 the packets marked 2,4,5,8 and 9 are lost. So, a total 440 of 5 packets are lost. This same sequence translates to 3 loss 441 events: (2), (4,5) and (8,9). In the case of RTP, the sequence 442 number in the RTP header can be used to identify loss events. 443 Certain protocols such as TCP and UDP+MPEG2-TS encapsulation in IP 444 have sequencing information, but the sequence field is incremented 445 by individual IP packets. As a side note, in the case of UDP+ 446 MPEG2-TS encapsulation the simple use of RTP+MPEG2-TS via 447 [RFC2250] results in the avaliability of the more granular 448 perfPacketLoss metrics. In these cases, the perfPacketLoss metric 449 cannot be calculated but the perfPacketLossEvent can be calculated 450 and can provide detection of loss. The value 0xFFFFFFFF is used 451 to represent non-applicable cases such as lack of sequence number 452 synchronization. Many of the same considerations as for 453 perfPacketLoss apply to perfPacketLoss event. Please refer to the 454 Calculation Method section of the perfPacketLoss. 456 Units of Measurement: event counts 458 Measurment Timing Please refer to the measurement timing section of 459 perfPacketLoss. 461 4.1.5. perfPacketInterArrivalJitterAvg 463 Name: perfPacketInterArrivalJitterAvg 465 Description: This metric measures the absolute deviation of the 466 difference in packet spacing at the measurement point compared to 467 the packet spacing at the sender. 469 Observation Point: The observation can be made anywhere along the 470 media path or on the receiver. The observation is only relevant 471 in a unidirectional sense. 473 Use and Applications The inter arrival jitter data value can be used 474 be network operator to determine the network's impact to the 475 spacing in between a media stream's packets as they traverse the 476 network. For example, in the case of media applications, the 477 receiving end system is expecting these packets to come in at a 478 particular periodicity and large deviations may result in de- 479 jitter buffers adding excessive delay, or the media packets being 480 discarded. When the data is reported from multiple intermediate 481 nodes, the area of the network that is having a detrimental 482 contribution can be identified. On a non-media application level, 483 the inter arrival jitter metrics can be used for early indication 484 queuing contention within the network (which could lead to packet 485 loss). 487 Calculation Method: The inter arrival jitter value makes use of the 488 association of sending time with an IP packets and comparison of 489 the arrival time on the monitoring point. In certain protocols, a 490 representation of sending time is encoded into the header itself. 491 For example, in the case of RTP packets, the RTP header's 492 timestamps field represents encoder clock ticks-- which are 493 representations of time. Similarly, in the case of TCP options 494 encode absolute timestamps values. For RTP the calculation method 495 can be found in Appendix A of [RFC3550]. It should be noted that 496 the RFC3550 calculation is on the last 16 packets measured. The 497 most recent value calculated SHOULD be reported at the end of the 498 monitoring interval. The range of the jitter values during the 499 monitoring interval can be reported using 500 perfPacketInterArrivalJitterMin and 501 perfPacketInterArrivalJitterMax. Similarly to the perfPacketLoss 502 case there may be periods of time where the jitter value cannot be 503 calculated. In these cases, the 0xFFFFFFFF value should be used 504 to convey the lack of availability of the metric. As mentioned 505 earlier, the RTP header timestamps is actually a 'sample-stamp' 506 (ie clicks) from the encoder's clock. The frequency of the clock 507 is dependent on the codec. Some codecs (eg AAC-LD) support 508 multiple possible frequencies one of which is then selected for 509 the media-stream. The mapping to clock rate can be performed via 510 mapping from the static RTP payload type (RTP-PT), but newer 511 codecs are make use of the dynamic payload type range and the 512 RTP-PT (in the dynamic case) cannot be used to determine the clock 513 frequency. There are various methods by which the clock frequency 514 (deep packet inspection of the signalling, manual configuration, 515 etc.) can be associated to the calculation method. The frequency 516 should be locked in the metering layer to a unique combination of 517 the IP source, IP destination, IP protocol layer-4 ports, RTP-PT 518 and SSRC. By strict RFC3550 definition, the SSRC is set to a 519 specific encoder clock and it is the SSRC that should be tracked 520 rather than payload type. However, in recent discussions it has 521 been noted that there are RTP implementations that might change 522 the encoder clock frequency while maintaining the SSRC value. An 523 encoder frequency change will be accompanied by a different 524 RTP-PT. 526 Units of Measurement: microseconds 528 Measurment Timing Please refer to the measurement timing section of 529 perfPacketLoss. 531 4.1.6. perfPacketInterArrivalJitterMin 533 Name: perfPacketInterArrivalJitterMin 535 Description: This metric measures the minimum value the calculation 536 used for perfPacketInterArrivalJitterAvg within the monitoring 537 interval. 539 Observation Point: The observation can be made anywhere along the 540 media path or on the receiver. The observation is only relevant 541 in a unidirectional sense. 543 Use and Applications Please refer to the 'Use and Applications' 544 section of perfPacketInterArrivalJitterAvg. This specific metric, 545 along with perfPacketInterArrivalJitterMax, is to capture the 546 range of measurements observed within a monitoring interval as the 547 average function may hide extremes. 549 Calculation Method: Please see the perfPacketInterArrivalJitterAvg 550 section for general calculation section. The average calculation 551 is evaluated on a running basis over the last 16 packets and the 552 entire monitoring interval is not covered. In this metric, the 553 minimum value is taken over the entire monitoring interval. 555 Units of Measurement: microseconds 557 Measurment Timing Please refer to the measurement timing section of 558 perfPacketLoss. 560 4.1.7. perfPacketInterArrivalJitterMax 562 Name: perfPacketInterArrivalJitterMax 564 Description: This metric measures the maximum value the calculation 565 used for perfPacketInterArrivalJitterAvg within the monitoring 566 interval. 568 Observation Point: The observation can be made anywhere along the 569 media path or on the receiver. The observation is only relevant 570 in a unidirectional sense. 572 Use and Applications Please refer to the 'Use and Applications' 573 section of perfPacketInterArrivalJitterAvg. This specific metric, 574 along with perfPacketInterArrivalJitterMin, is to capture the 575 range of measurements observed within a monitoring interval as the 576 average function may hide extremes. 578 Calculation Method: Please see the perfPacketInterArrivalJitterAvg 579 section for general calculation section. The average calculation 580 is evaluated on a running basis over the last 16 packets and the 581 entire monitoring interval is not covered. In this metric, the 582 maximum value is taken over the entire monitoring interval. 584 Units of Measurement: microseconds 586 Measurment Timing Please refer to the measurement timing section of 587 perfPacketLoss. 589 4.1.8. perfRoundTripNetworkDelay 591 Name: perfRoundTripNetworkDelay 593 Description: This metric measures the network round trip time 594 between end stations for a flow. 596 Observation Point: The observation can be made anywhere along the 597 flow path as long as the bidirectional network delay is accounted 598 for. 600 Use and Applications The perfRoundTripNetworkDelay metric can be 601 used in multiple ways. If the applicaiton being monitored 602 provides interactive feedback to the user the 603 perfRoundTripNetworkDelay can be used to judge the 'liveliness' of 604 the application experience. Other use cases may involve 605 troubleshooting throughput issues where the transport protocol's 606 throughtput is affected by network delay. 608 Calculation Method: perfRoundTripNetworkDelay can estimated by 609 accounting for the network flight time between a transport 610 protocol request and response. In the case of TCP, this would the 611 time difference between the TCP SYN and ACK packets in the TCP 612 handshake. It should be noted that at times other than the TCP 613 handshake the time difference between TCP end station packet. For 614 RTP (RFC3550) based applications, the network round trip can be 615 calculated by analysis of hte RTCP sending and receive times. 617 Units of Measurement: microseconds 619 Measurment Timing Depending on the method used to calculate the 620 round trip time, the measurment may only be possible at specific 621 times during the session lifecycle. In time periods where the 622 metric is not current 'not calculated' SHOULD be reported. 624 4.2. User and Application Layer 626 4.2.1. perfSessionSetupDelay 628 Name: perfSessionSetupDelay 630 Description: The Session Setup Delay metric reports the time taken 631 from a request being initiated by a host/endpoint to the response 632 (or request indicator) to the request being observed. This metric 633 is defined in [RFC4710], however the units have been updated to 634 microseconds. 636 Observation Point: This metric needs to be calculated where both 637 request and response can be observed. This could be at network 638 choke points, application proxies, or within the end systems 639 themselves. 641 Use and Applications The session setup delay metric can measure the 642 end user initial wait experience as seen from the network 643 transaction level. The value will not only include the network 644 flight time, but also includes the server response time and may be 645 used to alert the operator in cases where the overall service is 646 overloaded and thus sluggish, or within normal operating values. 648 Calculation Method: Measure distance in time between the first bit 649 of request and the first bit of the response. For the case of 650 SIP, please see Section 4.3.1 of [I-D.ietf-pmol-sip-perf-metrics] 652 Units of Measurement: microseconds 654 Measurment Timing This measurement can be sampled on a session by 655 session basis. It may be advisable to set sample targets on a per 656 source range - to destination basis. Due to the nature of 657 measurement intervals, there may be a period of time (and thus 658 measurement reports) in which the perfSessionSetupDelay value has 659 not been calculated. In these cases the value 0xFFFFFFFE MUST be 660 used and can be interpreted to mean not applicable. For 661 measurement intervals after perfSessionSetupDelay has been 662 calculated and the existing calculated perfSessionSetupDelay value 663 SHOULD be sent if reporting only on that single session. However, 664 if multiple sessions are summarized in the report then the average 665 for perfSessionSetupDelay values calculated in the most recent 666 interval SHOULD be used. The intention with this behavior is to 667 acknowledge that the value has not bee calculated, and when it has 668 provide the freshest values available. 670 4.3. Contextual Elements 672 4.3.1. mediaRTPSSRC 674 Name: mediaRTPSSRC 676 Description: Value of the synchronization source (SSRC) field in the 677 RTP header of the flow. This field is defined in [RFC3550] 679 Observation Point: This metric can be gleaned from the RTP packets 680 directly, so the observation point needs to on the flow path or 681 within the endpoints. 683 Use and Applications The RTP SSRC value denotes a specific media 684 stream. As such when trying to differentiate media stream 685 problems between session participants the SSRC field is needed. 687 Calculation Method: Copy from RTP header's SSRC field as defined in 688 [RFC3550]. In the case of a non-RTP flow, or the time period in 689 which the flow has not been verified to be a RTP flow the value 690 0xFFFFFFFE MUST be reported. 692 Units of Measurement: identifier 694 Measurment Timing It is possible that the SSRC may have be 695 renegotiated mid-session due to collisions with other RTP senders. 697 4.3.2. mediaRTPPayloadType 699 Name: mediaRTPPayloadType 701 Description: The value of the RTP Payload Type Field as seen in the 702 RTP header of the flow. This field is defined in [RFC3550] 704 Observation Point: This metric can be gleaned from the RTP packets 705 directly, so the observation point needs to on the flow path or 706 within the endpoints. 708 Use and Applications The RTP PT conveys the payload format and media 709 encoding used in the RTP payload. For simple cases, where the RTP 710 PT is from the statically defined range this can lead to an 711 understanding of type of media codec used. With the knowledge of 712 the codec being used the degree of media impairment (given loss 713 values and jitter) can be estimated better. However, for more 714 recent codecs, the RTP dynamic range is used. In these cases the 715 RTP payload values are dynamically negotiated. In the case of a 716 non-RTP flow, or the time period in which the flow has not been 717 verified to be a RTP flow, the value 0xFFFF MUST be reported. 719 Calculation Method: Copy from RTP header's RTP-PT field as defined 720 in [RFC3550] 722 Units of Measurement: identifier 724 Measurment Timing 726 4.3.3. mimeType 728 Name: mimeType 730 Description: The mime type describes the content of the flow. 732 Observation Point: The ideal location of this metric is on the 733 application generators and consumers. However, given application 734 signalling inspection or static configuration it is possible that 735 intermediate nodes are able to generate mime type (eg. codec name) 736 information. 738 Use and Applications The mime type value conveys information 739 regarding the content of a flow. For example, in the case of 740 Audio/Video applications the name of the codec used to encode the 741 media in the flow. Simply reporting loss and jitter measurements 742 are useful for detection of network problems. However, judging 743 the degree of the impact on the audio/video experience needs 744 additional information. The most basic information is the codec 745 being used which when coupled with per-codec knowledge of 746 sensitivity to the transport metrics a better idea of the 747 experience can be gained. 749 Calculation Method: The valid values for the mime type are listed on 750 the IANA mime type registry. For Audio/Video codecs, there is a 751 specific media-types registry. Analysis of the RTP payload type 752 may lead to the determination of the media codec. However, with 753 the use of the RTP dynamic payload type range the media 754 information is not encoded into the data packet. For these cases, 755 intermediate nodes may need to perform inspection of the 756 signalling (SIP, H.323, RTSP, etc.). In cases where the 757 mediaCodec cannot be determined, the value 'unknown' MUST be used. 759 Units of Measurement: identifier 761 Measurment Timing 763 5. Security Considerations 765 The recommendations in this document do not introduce any additional 766 security issues to those already mentioned in [RFC5101] and [RFC5477] 768 6. Acknowledgements 770 The authors would like to thank Rahul Patel, Jan Novak, Al Morton, 771 Brad Fawcett, Doug Manley and Shingo Kashima for their invaluable 772 review and comments. Thank-you. 774 7. References 775 7.1. Normative References 777 [RFC5101] Claise, B., "Specification of the IP Flow Information 778 Export (IPFIX) Protocol for the Exchange of IP Traffic 779 Flow Information", RFC 5101, January 2008. 781 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 782 "Exporting Type Information for IP Flow Information Export 783 (IPFIX) Information Elements", RFC 5610, July 2009. 785 [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time 786 Application Quality-of-Service Monitoring (RAQMON) 787 Framework", RFC 4710, October 2006. 789 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 790 Meyer, "Information Model for IP Flow Information Export", 791 RFC 5102, January 2008. 793 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 794 Jacobson, "RTP: A Transport Protocol for Real-Time 795 Applications", STD 64, RFC 3550, July 2003. 797 [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP 798 Payload Format for Society of Motion Picture and 799 Television Engineers (SMPTE) 292M Video", RFC 3497, 800 March 2003. 802 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 803 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 804 October 2008. 806 [I-D.ietf-pmol-sip-perf-metrics] 807 Malas, D. and A. Morton, "Basic Telephony SIP End-to-End 808 Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07 809 (work in progress), September 2010. 811 [iana-ipfix-assignments] 812 Internet Assigned Numbers Authority, "IP Flow Information 813 Export Information Elements 814 (http://www.iana.org/assignments/ipfix/ipfix.xml)". 816 7.2. Informative References 818 [I-D.ietf-pmol-metrics-framework] 819 Clark, A. and B. Claise, "Guidelines for Considering New 820 Performance Metric Development", 821 draft-ietf-pmol-metrics-framework-12 (work in progress), 822 July 2011. 824 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 825 Headers for Low-Speed Serial Links", RFC 2508, 826 February 1999. 828 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 829 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 830 RFC 3711, March 2004. 832 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 833 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 834 January 1998. 836 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 837 RFC 2890, September 2000. 839 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 840 RFC 4303, December 2005. 842 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 843 Control Packets on a Single Port", RFC 5761, April 2010. 845 [I-D.huici-ipfix-sipfix] 846 Huici, F., Niccolini, S., and S. Anderson, "SIPFIX: Use 847 Cases and Problem Statement for VoIP Monitoring and 848 Exporting", draft-huici-ipfix-sipfix-00 (work in 849 progress), June 2009. 851 [nProbe] "nProbe - NetFlow/IPFIX Network Probe 852 (http://www.ntop.org/nProbe.html)". 854 [RFC2321] Bressen, A., "RITA -- The Reliable Internetwork 855 Troubleshooting Agent", RFC 2321, April 1998. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 861 Carle, "Information Model for Packet Sampling Exports", 862 RFC 5477, March 2009. 864 [VoIP-monitor] 865 L. Chang-Yong, H. Kim, K. Ko, J. Jim, and H. Jeong, "A 866 VoIP Traffic Monitoring System based on NetFlow v9, 867 International Journal of Advanced Science and Technology, 868 vol. 4, Mar. 2009". 870 Author's Address 872 Aamer Akhter 873 Cisco Systems, Inc. 874 7025 Kit Creek Road 875 RTP, NC 27709 876 USA 878 Email: aakhter@cisco.com