idnits 2.17.1 draft-ietf-bmwg-dsmterm-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 24. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([Ni98], [Br91], [Ma98], [Bl98], [Ja99], [Ma91], [Br97], [Sc96], [Br99], [Al99], [Ra99], [Na84], [Ka99], [Ma00], [Mo03], [De02]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 541 has weird spacing: '... Jitter will ...' == Line 542 has weird spacing: '...an ipdv is ty...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Definition: A vector describing the percentage of packets, having a specific DSCP or IP precedence value that SHOULD not be forwarded. The value is dependent on the set of offered vectors and configuration of the DUT. -- 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 (February 2005) is 7002 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) -- Missing reference section? 'Br97' on line 1551 looks like a reference -- Missing reference section? 'Ma98' on line 1554 looks like a reference -- Missing reference section? 'Ra99' on line 1597 looks like a reference -- Missing reference section? 'Br91' on line 1548 looks like a reference -- Missing reference section? 'Na84' on line 1594 looks like a reference -- Missing reference section? 'Ma91' on line 1584 looks like a reference -- Missing reference section? 'Ni98' on line 1557 looks like a reference -- Missing reference section? 'Al99' on line 1565 looks like a reference -- Missing reference section? 'Br99' on line 1572 looks like a reference -- Missing reference section? 'De02' on line 1575 looks like a reference -- Missing reference section? 'Ja99' on line 1578 looks like a reference -- Missing reference section? 'Sc96' on line 1601 looks like a reference -- Missing reference section? 'Mo03' on line 1590 looks like a reference -- Missing reference section? 'Ma00' on line 1587 looks like a reference -- Missing reference section? 'Ka99' on line 1581 looks like a reference -- Missing reference section? 'Bl98' on line 1568 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jerry Perser 3 INTERNET-DRAFT 4 Expires in: October 2005 Scott Poretsky 5 Quarry Technologies 7 Shobha Erramilli 8 Qnetworx 10 Sumit Khurana 11 Telcordia 13 February 2005 15 Terminology for Benchmarking Network-layer 16 Traffic Control Mechanisms 18 20 Intellectual Property Rights (IPR) statement: 21 By submitting this Internet-Draft, I certify that any applicable 22 patent or other IPR claims of which I am aware have been disclosed, or 23 will be disclosed, and any of which I become aware will be disclosed, 24 in accordance with RFC 3668. 26 Status of this Memo 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other 38 documents at any time. It is inappropriate to use Internet-Drafts 39 as reference material or to cite them other than as "work in 40 progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Abstract 48 This document describes terminology for the benchmarking of 49 devices that implement traffic control based on IP precedence or 50 diff-serv code point criteria. The terminology is to be applied 51 to measurements made on the data plane to evaluate IP traffic 52 control meachanisms. 54 Network-layer Traffic Control Mechanisms 56 Table of Contents 57 1. Introduction .............................................. 3 58 2. Existing definitions ...................................... 3 59 3. Term definitions............................................4 60 3.1 Configuration Terms 61 3.1.1 Classification.........................................4 62 3.1.2 Codepoint Set..........................................4 63 3.1.3 Forwarding Congestion..................................5 64 3.1.4 Congestion Management..................................6 65 3.1.5 Flow...................................................7 66 3.2 Measurement Terms 67 3.2.1 Forwarding Capacity....................................7 68 3.2.2 Conforming Packet......................................8 69 3.2.3 Nonconforming Packet...................................9 70 3.2.4 Forwarding Delay.......................................9 71 3.2.5 Jitter................................................11 72 3.2.6 Undifferentiated Response.............................11 73 3.3 Sequence Tracking 74 3.3.1 In-sequence Packet....................................12 75 3.3.2 Out-of-order Packet...................................12 76 3.3.3 Duplicate Packet......................................13 77 3.3.4 Stream................................................14 78 3.3.5 Test Sequence number .................................15 79 3.4 Vectors...................................................15 80 3.4.1 Intended Vector.......................................15 81 3.4.2 Offered Vector........................................16 82 3.4.3 Expected Vectors 83 3.4.3.1 Expected Forwarding Vector........................16 84 3.4.3.2 Expected Loss Vector..............................17 85 3.4.3.3 Expected Sequence Vector..........................18 86 3.4.3.4 Expected Instantaneous Delay Vector...............18 87 3.4.3.5 Expected Average Delay Vector.....................19 88 3.4.3.6 Expected Maximum Delay Vector.....................10 89 3.4.3.7 Expected Minimum Delay Vector.....................20 90 3.4.3.8 Expected Instantaneous Jitter Vector..............21 91 3.4.3.9 Expected Average Jitter Vector....................22 92 3.4.3.10 Expected Peak-to-peak Jitter Vector..............22 93 3.4.4 Output Vectors 94 3.4.4.1 Forwarding Vector.................................23 95 3.4.4.2 Loss Vector.......................................24 96 3.4.4.3 Sequence Vector...................................24 97 3.4.4.4 Instantaneous Delay Vector........................25 98 3.4.4.5 Average Delay Vector..............................26 99 3.4.4.6 Maximum Delay Vector..............................27 100 3.4.4.7 Minimum Delay Vector..............................28 101 3.4.4.8 Instantaneous Jitter Vector.......................28 102 3.4.4.9 Average Jitter Vector.............................29 103 3.4.4.10 Peak-to-peak Jitter Vector.......................30 104 4. Acknowledgments............................................31 105 5. Security Considerations....................................31 106 6. Normative References.......................................31 107 Network-layer Traffic Control Mechanisms 109 7. Informative References.....................................32 110 8. Author's Address...........................................33 111 9. Full Copyright Statement...................................34 113 1. Introduction 115 New terminology is needed because most existing measurements 116 assume the absence of congestion and only a single per-hop- 117 behavior. This document introduces several new terms that will 118 allow measurements to be taken during periods of congestion. 120 Another key difference from existing terminology is the definition 121 of measurements as observed on egress as well as ingress of a 122 device/system under test. Again, the existence of congestion 123 requires the addition of egress measurements as well as those 124 taken on ingress; without observing traffic leaving a 125 device/system it is not possible to say whether traffic-control 126 mechanisms effectively dealt with congestion. 128 The principal measurements introduced in this document are vectors 129 for rate, delay, and jitter, all of which can be observed with or 130 without congestion of the DUT/SUT. 132 This document describes only those terms relevant to measuring 133 behavior of a device or a group of devices using one of these two 134 mechanisms. End-to-end and service-level measurements are beyond 135 the scope of this document. 137 2. Existing definitions 138 RFC 1242 "Benchmarking Terminology for Network Interconnect 139 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 140 Devices" SHOULD be consulted before attempting to make use of this 141 document. 143 RFC 2474 "Definition of the Differentiated Services Field (DS 144 Field) in the IPv4 and IPv6 Headers" section 2, contains 145 discussions of a number of terms relevant to network-layer traffic 146 control mechanisms and SHOULD also be consulted. 148 For the sake of clarity and continuity this RFC adopts the 149 template for definitions set out in Section 2 of RFC 1242. 150 Definitions are indexed and grouped together in sections for ease 151 of reference. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in BCP 14, RFC 2119 156 [Br97]. RFC 2119 defines the use of these key words to help make the 157 intent of standards track documents as clear as possible. While this 158 document uses these keywords, this document is not a standards track 159 document. 161 Network-layer Traffic Control Mechanisms 163 3. Term definitions 164 3.1 Configuration Terms 165 3.1.1 Classification 167 Definition: 168 Selection of packets based on the contents of packet header 169 according to defined rules. 171 Discussion: 172 Packets can be selected based on the DS field or IP 173 Precedence in the packet header. Classification can also be 174 based on Multi-Field (MF) criteria such as IP Source and 175 destination addresses, protocol and port number. 177 Classification determines the per-hop behaviors and traffic 178 conditioning functions such as shaping and dropping that are 179 to be applied to the packet. 181 Measurement units: n/a 183 See Also: 185 3.1.2 Codepoint Set 187 Definition: 188 The set of all DS Code-points or IP precedence values used 189 during the test duration. 191 Discussion: 192 Describes all the code-point markings associated with packets 193 that are input to the DUT/SUT. For each entry in the 194 codepoint set, there are associated vectors describing the 195 rate of traffic, delay, loss, or jitter containing that 196 particular DSCP or IP precedence value. 198 The treatment that a packet belonging to a particular code- 199 point gets is subject to the DUT classifying packets to map 200 to the correct PHB. Moreover, the forwarding treatment in 201 general is also dependent on the complete set of offered 202 vectors. 204 Measurement Units: n/a 206 See Also: None 207 Network-layer Traffic Control Mechanisms 209 3.1.3 Forwarding Congestion 211 Definition: 212 A condition in which one or more egress interfaces are 213 offered more packets than are forwarded. 215 Discussion: 216 This condition is a superset of the overload definition 217 [Ma98]. Overload [Ma98] deals with overloading input and 218 output interfaces beyond the maximum transmission allowed by 219 the medium. Forwarding congestion does not assume ingress 220 interface overload as the only source of overload on output 221 interfaces. 223 Another difference between Forwarding Congestion and overload 224 occurs when the SUT comprises multiple elements, in that 225 Forwarding Congestion may occur at multiple points. Consider 226 an SUT comprising multiple edge devices exchanging traffic 227 with a single core device. Depending on traffic patterns, 228 the edge devices may induce Forwarding Congestion on multiple 229 egress interfaces on the core device. 231 Packet Loss, not increased Delay, is the metric to indicate 232 the condition of Forwarding Congestion. Packet Loss is a 233 deterministic indicator of Forwarding Congestion. While 234 increased delay may be an indicator of Forwarding Congestion, 235 it is a non-deterministic indicator of Forwarding Congestion. 236 External observation of increased delay to indicate 237 congestion is in effect external observation of Incipient 238 Congestion. 240 [Ra99] implies that it is impractical to build a black-box 241 test to externally observe Incipient Congestion indicated by 242 increased delay in a router. [Ra99] introduces Explicit 243 Congestion Notification (ECN) as the externally observable, 244 deterministic method for indicating Incipient Congestion. 245 Because [Ra99] is an Experimental RFC with limited 246 deployment, ECN is not used for this particular methodology. 247 For the purpose of "black-box" testing a DUT/SUT, Packet Loss 248 as the indicator of Forwarding Congestion is used. 250 Throughput [Br91] defines the lower boundary of Forwarding 251 Congestion. Throughput is the maximum offered rate with no 252 Forwarding Congestion. At offered rates above throughput, 253 the DUT/SUT is considered to be in a state of Forwarding 254 Congestion. 256 Network-layer Traffic Control Mechanisms 258 Ingress observations alone are not sufficient to cover all 259 cases in which Forwarding Congestion may occur. A device 260 with an infinite amount of memory could buffer an infinite 261 number of packets, and eventually forward all of them. 262 However, these packets may or may not be forwarded during the 263 test duration. Even though ingress interfaces accept all 264 packets without loss, Forwarding Congestion is present in 265 this hypothetical device. 267 Forwarding Congestion, indicated by occurrence of packet 268 loss, is one type of congestion for a DUT/SUT. Congestion 269 Collapse [Na84] is defined as the state in which buffers are 270 full and all arriving packets MUST be dropped across the 271 network. Incipient Congestion [Ra99] is defined as 272 congestion that produces increased delay without packet loss. 274 The definition presented here explicitly defines Forwarding 275 Congestion as an event observable on egress interfaces. 276 Regardless of internal architecture, any device that cannot 277 forward packets on one or more egress interfaces is under 278 Forwarding Congestion. 280 Measurement units: 281 none 283 See Also: 284 Gateway Congestion Control Survey [Ma91] 286 3.1.4 Congestion Management 288 Definition: 289 An implementation of one or more per-hop-behaviors to avoid 290 or minimize the condition of congestion. 292 Discussion: 293 Congestion management may seek either to control congestion 294 or avoid it altogether. Such mechanisms classify packets 295 based upon IP Precedence or DSCP settings in a packets IP 296 header. 298 Congestion avoidance mechanisms seek to prevent congestion 299 before it actually occurs. 301 Congestion control mechanisms give one or more flows (with a 302 discrete IP Precedence or DSCP value) preferential treatment 303 over other classes during periods of congestion. 305 Measurement units: 306 n/a 308 See Also: 310 Network-layer Traffic Control Mechanisms 312 3.1.5 Flow 314 Definition: 315 A flow is a one or more of packets sharing a common intended 316 pair of source and destination interfaces. 318 Discussion: 319 Packets are grouped by the ingress and egress interfaces they 320 use on a given DUT/SUT. 322 A flow can contain multiple source IP addresses and/or 323 destination IP addresses. All packets in a flow MUST enter 324 on the same ingress interface and exit on the same egress 325 interface, and have some common network layer content. 327 Microflows [Ni98] are a subset of flows. As defined in 328 [Ni98], microflows require application-to-application 329 measurement. In contrast, flows use lower-layer 330 classification criteria. Since this document focuses on 331 network-layer classification criteria, we concentrate here on 332 the use of network-layer identifiers in describing a flow. 333 Flow identifiers also may reside at the data-link, transport, 334 or application layers of the OSI model. However, identifiers 335 other than those at the network layer are out of scope for 336 this document. 338 A flow may contain a single code point/IP precedence value or 339 may contain multiple values destined for a single egress 340 interface. This is determined by the test methodology. 342 Measurement units: 343 n/a 345 See Also: 346 Microflow [Ni98] 347 Streams 349 3.2 Measurement Terms 351 3.2.1 Forwarding Capacity 353 Definition: 354 The number of packets per second that a device can be 355 observed to successfully transmit to the correct destination 356 interface in response to a specified offered load while the 357 device drops none of the offered packets. 359 Network-layer Traffic Control Mechanisms 361 Discussion: 362 Forwarding Capacity measures the packet rate at the egress 363 interface(s) of the DUT/SUT. In contrast, throughput as 364 defined in RFC 1242 measures the frame rate at the ingress 365 interface(s) of the DUT/SUT. 367 Ingress-based measurements do not account for queuing of the 368 DUT/SUT. Throughput rates can be higher than the Forwarding 369 Capacity because of queuing. The difference is dependent 370 upon test duration, packet rate, and queue size. Forwarding 371 Capacity, as an egress measurement, does take queuing into 372 account. 374 Understanding Forwarding Capacity is a necessary precursor to 375 any measurement involving Traffic Control Mechanisms. The 376 accompanying methodology document MUST take into 377 consideration Forwarding Capacity when determining the 378 expected forwarding vectors. When the sum of the expected 379 forwarding vectors on an interface exceeds the Forwarding 380 Capacity, the Forwarding Capacity will govern the forwarding 381 rate. 383 This measurement differs from forwarding rate at maximum 384 offered load (FRMOL) [Ma98] in that Forwarding Capacity 385 requires zero loss. 387 Measurement units: 388 N-octet packets per second 390 See Also: 391 Throughput [Br91] 392 Forwarding Rate at Maximum Offered Load [Ma98] 394 3.2.2 Conforming Packet 396 Definition: 397 Packets which lie within specific rate, delay, or jitter 398 bounds. 400 Discussion: 401 A DUT/SUT may be configured to allow a given traffic class to 402 consume a given amount of bandwidth, or to fall within 403 predefined delay or jitter boundaries. All packets that lie 404 within specified bounds are then said to be conforming, 405 whereas those outside the bounds are nonconforming. 407 Measurement units: 408 n/a 409 Network-layer Traffic Control Mechanisms 411 See Also: 412 Expected Vector 413 Forwarding Vector 414 Offered Vector 415 Nonconforming 417 3.2.3 Nonconforming Packet 419 Definition: 420 Packets that do not lie within specific rate, delay, or 421 jitter bounds. 423 Discussion: 424 A DUT/SUT may be configured to allow a given traffic class to 425 consume a given amount of bandwidth, or to fall within 426 predefined delay or jitter boundaries. All packets that do 427 not lie within these bounds are then said to be 428 nonconforming. 430 Measurement units: 431 n/a 433 See Also: 434 Expected Vector 435 Forwarding Vector 436 Offered Vector 437 Conforming 439 3.2.4 Forwarding Delay 441 Definition: 442 The time interval starting when the last bit of the input IP 443 packet is offered to the input port of the DUT/SUT and ending 444 when the last bit of the output IP packet is received from 445 the output port of the DUT/SUT. 447 Discussion: 448 The delay time interval MUST be externally observed. The 449 delay measurement MUST NOT include delays added by test bed 450 components other than the DUT/SUT, such as propagation time 451 introduced by cabling or non-zero delay added by the test 452 instrument. 454 Forwarding Delay differs from latency [Br91] and one-way 455 delay [Al99] in several key regards: 457 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 458 uses "store and forward" or "bit forwarding" technology. 459 Forwarding Delay is the same metric, measured the same way, 460 regardless of the architecture of the DUT/SUT. 462 Network-layer Traffic Control Mechanisms 464 2. Forwarding Delay is a last-in, last-out (LILO) 465 measurement, unlike the last-in, first-out method [Br91] or 466 the first-in, last-out method [Al99]. 468 The LILO method most closely simulates the way a network- 469 layer device actually processes an IP datagram. IP datagrams 470 are not passed up and down the stack unless they are 471 complete, and processing begins only once the last bit of the 472 IP datagram has been received. 474 Further, the LILO method has an additive property, where the 475 sum of the parts MUST equal the whole. This is a key 476 difference from [Br91] and [Al99]. For example, the delay 477 added by two DUTs MUST equal the sum of the delay of the 478 DUTs. This may or may not be the case with [Br91] and 479 [Al99]. 481 3. Forwarding Delay measures the IP datagram only, unlike 482 [Br91], which also includes link layer overhead. 484 A metric focused exclusively on the Internet protocol 485 relieves the tester from specifying the start/end for every 486 link layer protocol that IP runs on. This avoids the need to 487 determine whether the start/stop delimiters are included. It 488 also allows the use of heterogeneous link layer protocols in 489 a test. 491 4. Forwarding Delay can be measured at any offered load, 492 whereas the latency methodology [Br99] recommends measurement 493 at, and only at, the throughput level. Comparing the 494 Forwarding Delay below the throughput to Forwarding Delay 495 above the Forwarding Capacity will give insight to the 496 traffic control mechanisms. 498 For example, non-congested delay may be measured with an 499 offered load that does not exceed the Forwarding Capacity, 500 while congested delay may involve an offered load that 501 exceeds Forwarding Capacity. 503 Note: Forwarding Delay SHOULD NOT be used as an absolute 504 indicator of DUT/SUT Forwarding Congestion. While Forwarding 505 Delay may rise when offered load nears or exceeds Forwarding 506 Capacity, there is no universal point at which Forwarding 507 Delay can be said to indicate the presence or absence of 508 Forwarding Congestion. 510 Measurement units: 511 Seconds. 513 Network-layer Traffic Control Mechanisms 515 See Also: 516 Latency [Br91] 517 Latency [Al99] 518 One-way Delay [Br99] 520 3.2.5 Jitter 522 Definition: 523 The absolute value of the difference between the arrival 524 delay of two consecutive received packets belonging to the 525 same stream. 527 Discussion: 528 The delay fluctuation between two consecutive received 529 packets in a stream is reported as the jitter. Jitter can be 530 expressed as |D(i) - D(i-1)| where D equals the delay and i 531 is the order the packets were received. 533 Under loss, jitter can be measured between non-consecutive 534 test sequence numbers. When Traffic Control Mechanisms are 535 losing packets, the Forwarding Delay may fluctuate as a 536 response. Jitter MUST be able to benchmark the delay 537 variation with or with out loss. 539 Jitter is related to the ipdv [De02] (IP Delay Variation) by 540 taking the absolute value of the ipdv. The two metrics will 541 produce different mean values. Mean Jitter will produce a 542 positive value, where the mean ipdv is typically zero. 544 Measurement units: 545 Seconds 547 See Also: 548 Forwarding Delay 549 Jitter variation [Ja99] 550 ipdv [De02] 551 interarrival jitter [Sc96] 553 3.2.6 Undifferentiated Response 555 Definition: 556 The vector(s) obtained when mechanisms used to support diff- 557 serv or IP precedence are disabled. 559 Discussion: 560 Enabling diff-serv or IP precedence mechanisms may impose 561 additional processing overhead for packets. This overhead 562 may degrade performance even when traffic belonging to only 563 one class, the best-effort class, is offered to the device. 565 Network-layer Traffic Control Mechanisms 567 Measurements with "undifferentiated response" SHOULD be made 568 to establish a baseline. 570 The vector(s) obtained with DSCP or IP precedence enabled can 571 be compared to the undifferentiated response to determine the 572 effect of differentiating traffic. 574 Measurement units: 575 n/a 577 3.3 Sequence Tracking 579 3.3.1 In-sequence Packet 581 Definition: 582 A received packet with the expected Test Sequence number. 584 Discussion: 585 In-sequence is done on a stream level. As packets are 586 received on a stream, each packets Test Sequence number is 587 compared with the previous packet. Only packets that match 588 the expected Test Sequence number are considered in-sequence. 590 Packets that do not match the expected Test Sequence number 591 are counted as "not in-sequence" or out-of-sequence. Every 592 packet that is received is either in-sequence or out-of- 593 sequence. Subtracting the in-sequence from the received 594 packets (for that stream) can derive the out-of-sequence 595 count. 597 Two types of events will prevent the in-sequence from 598 incrementing: packet loss and reordered packets. 600 Measurement units: 601 Packet count 603 See Also: 604 Stream 605 Test Sequence number 607 3.3.2 Out-of-order Packet 609 Definition: 610 A received packet with a Test Sequence number less than 611 expected. 613 Network-layer Traffic Control Mechanisms 615 Discussion: 616 As a stream of packets enters a DUT/SUT, they include a 617 Stream Test Sequence number indicating the order the packets 618 were sent to the DUT/SUT. On exiting the DUT/SUT, these 619 packets may arrive in a different order. Each packet that 620 was re-ordered is counted as an Out-of-order Packet. 622 Certain streaming protocol (such as TCP) require the packets 623 to be in a certain order. Packets outside this are dropped 624 by the streaming protocols even though there were properly 625 received by the IP layer. The type of reordering tolerated 626 by a streaming protocol varies from protocol to protocol, and 627 also by implementation. 629 Out-of-order Packet count is based on the worst case 630 streaming protocol. It allows for no reordering. 632 Packet loss does not affect the Out-of-order Packet count. 633 Only packets that were not received in the order that they 634 were transmitted. 636 Measurement units: 637 Packet count 639 See Also: 640 Stream 641 Test Sequence number 642 Packet Reordering Metric for IPPM [Mo03] 644 3.3.3 Duplicate Packet 646 Definition: 647 A received packet with a Test Sequence number matching a 648 previously received packet. 650 Discussion: 651 A Duplicate Packet is a packet that the DUT/SUT has 652 successfully transmitted out an egress interface more than 653 once. The egress interface has previously forwarded this 654 packet. 656 A Duplicate Packet SHOULD be a bit for bit copy of an already 657 transmitted packet (including Test Sequence number). If the 658 Duplicate Packet traversed different paths through the 659 DUT/SUT, some fields (such as TTL or checksum) may have 660 changed. 662 Network-layer Traffic Control Mechanisms 664 A multicast packet is not a Duplicate Packet by definition. 665 For a given IP multicast group, a DUT/SUT SHOULD forward a 666 packet once on a given egress interface provided the path to 667 one or more multicast receivers is through that interface. 668 Several egress interfaces will transmit the same packet, but 669 only once per interface. 671 To detect a Duplicate Packet, each offered packet to the 672 DUT/SUT MUST contain a unique packet-by-packet identifier. 674 Measurement units: 675 Packet count 677 See Also: 678 Stream 679 Test Sequence number 681 3.3.4 Stream 683 Definition: 684 A group of packets tracked as a single entity by the traffic 685 receiver. A stream may share a common content such as type 686 (IP, UDP), packet size, or payload. 688 Discussion: 689 Streams are tracked by test sequence number or "unique 690 signature field" [Ma00]. Streams define how individual 691 packets statistic are grouped together to form an 692 intelligible summary. 694 Common stream groupings would be by egress interface, 695 destination address, source address, DSCP, or IP precedence. 696 A stream using test sequence numbers can track the ordering 697 of packets as they transverse the DUT/SUT. 699 Streams are not restricted to a pair of source and 700 destination interfaces as long as all packets are tracked as 701 a single entity. A multicast stream can be forward to 702 multiple destination interfaces. 704 Measurement units: 705 n/a 707 See Also: 708 Flow 709 Microflow [Ni98] 710 Test sequence number 711 Network-layer Traffic Control Mechanisms 713 3.3.5 Test Sequence number 715 Definition: 716 A field in the IP payload portion of the packet that is used 717 to verify the order of the packets on the egress of the 718 DUT/SUT. 720 Discussion: 721 The traffic generator sets the test sequence number value and 722 the traffic receiver checks the value upon receipt of the 723 packet. The traffic generator changes the value on each 724 packet transmitted based on an algorithm agreed to by the 725 traffic receiver. 727 The traffic receiver keeps track of the sequence numbers on a 728 per stream basis. In addition to number of received packets, 729 the traffic receiver may also report number of in-sequence 730 packets, number of out-of-sequence packets, number of duplicate 731 packets, and number of reordered packets. 733 The RECOMMENDED algorithm to use to change the sequence 734 number on sequential packets is an incrementing value. 736 Measurement units: 737 n/a 739 See Also: 740 Stream 742 3.4 Vectors 743 A vector is a group of packets all containing a specific DSCP 744 or IP precedence value. Vectors are expressed as a pair of 745 numbers. The first is being the particular diff-serv value. 746 The second is the metric expressed as a rate, loss 747 percentage, delay, or jitter. 749 3.4.1 Intended Vector 751 Definition: 752 A vector describing the attempted rate at which packets 753 having a specific code-point (or IP precedence) are 754 transmitted to a DUT/SUT by an external source. 756 Discussion: 757 Intended loads across the different code-point classes 758 determine the metrics associated with a specific code-point 759 traffic class. 761 Measurement Units: 762 N-octets packets per second 763 Network-layer Traffic Control Mechanisms 765 See Also: 766 Offered Vector 767 Expected Forwarding Vector 768 Expected Loss Vector 769 Expected Sequence Vector 770 Expected Delay Vector 771 Expected Jitter Vector 772 Forwarding Vector 773 Loss Vector 775 3.4.2 Offered Vector 777 Definition: 778 A vector describing the measured rate at which packets having 779 a specific DSCP or IP precedence value are offered to the 780 DUT/SUT. 782 Discussion: 783 Offered loads across the different code-point classes, 784 constituting a code-point set, determine the metrics 785 associated with a specific code-point traffic class. 787 Measurement Units: 788 N-octets packets per second 790 See Also: 791 Expected Forwarding Vector 792 Expected Loss Vector 793 Expected Sequence Vector 794 Expected Delay Vector 795 Expected Jitter Vector 796 Forwarding Vector 797 Codepoint Set 799 3.4.3 Expected Vectors 801 3.4.3.1 Expected Forwarding Vector 803 Definition: 804 A vector describing the expected output rate of packets 805 having a specific DSCP or IP precedence value. The value is 806 dependent on the set of offered vectors and configuration of 807 the DUT. 809 Network-layer Traffic Control Mechanisms 811 Discussion: 812 The DUT is configured in a certain way in order that service 813 differentiation occurs for a particular DSCP or IP precedence 814 value when a specific traffic mix consisting of multiple 815 DSCPs or IP precedence values are applied. This term 816 attempts to capture the expected forwarding behavior when 817 subjected to a certain offered vectors. 819 The actual algorithm or mechanism the DUT uses to achieve 820 service differentiation is not important in describing the 821 expected forwarding vector. 823 Measurement units: 824 N-octet packets per second 826 See Also: 827 Intended Vector 828 Offered Vector 829 Output Vectors 830 Expected Loss Vector 831 Expected Sequence Vector 832 Expected Delay Vector 833 Expected Jitter Vector 835 3.4.3.2 Expected Loss Vector 837 Definition: 838 A vector describing the percentage of packets, having a 839 specific DSCP or IP precedence value that SHOULD not be 840 forwarded. The value is dependent on the set of offered 841 vectors and configuration of the DUT. 843 Discussion: 844 The DUT is configured in a certain way in order that service 845 differentiation occurs for a particular DSCP or IP precedence 846 value when a specific traffic mix consisting of multiple 847 DSCPs or IP precedence values are applied. This term 848 attempts to capture the expected forwarding behavior when 849 subjected to a certain offered vector. 851 The actual algorithm or mechanism the DUT uses to achieve 852 service differentiation is not important in describing the 853 expected loss vector. 855 Measurement Units: 856 Percentage of intended packets that is expected to be 857 dropped. 859 Network-layer Traffic Control Mechanisms 861 See Also: 862 Intended Vector 863 Offered Vector 864 Expected Forwarding Vector 865 Expected Sequence Vector 866 Expected Delay Vector 867 Expected Jitter Vector 868 One-way Packet Loss Metric [Ka99] 870 3.4.3.3 Expected Sequence Vector 872 Definition: 873 A vector describing the expected in-sequence packets having a 874 specific DSCP or IP precedence value. The value is dependent 875 on the set of offered vectors and configuration of the DUT. 877 Discussion: 878 The DUT is configured in a certain way in order that service 879 differentiation occurs for a particular DSCP or IP precedence 880 value when a specific traffic mix consisting of multiple 881 DSCPs or IP precedence values are applied. This term 882 attempts to capture the expected forwarding behavior when 883 subjected to a certain offered vectors. 885 The actual algorithm or mechanism the DUT uses to achieve 886 service differentiation is not important in describing the 887 expected sequence vector. 889 Measurement Units: 890 N-octet packets per second 892 See Also: 893 Intended Vector 894 Offered Vector 895 Output Vectors 896 Expected Loss Vector 897 Expected Forwarding Vector 898 Expected Delay Vector 899 Expected Jitter Vector 901 3.4.3.4 Expected Instantaneous Delay Vector 903 Definition: 904 A vector describing the expected delay for packets having a 905 specific DSCP or IP precedence value. The value is dependent 906 on the set of offered vectors and configuration of the DUT. 908 Network-layer Traffic Control Mechanisms 910 Discussion: 911 The DUT is configured in a certain way in order that service 912 differentiation occurs for a particular DSCP or IP precedence 913 value when a specific traffic mix consisting of multiple 914 DSCPs or IP precedence values are applied. This term 915 attempts to capture the expected forwarding behavior when 916 subjected to a certain offered vectors. 918 The actual algorithm or mechanism the DUT uses to achieve 919 service differentiation is not important in describing the 920 expected delay vector. 922 Measurement units: 923 Seconds. 925 See Also: 926 Forwarding Delay 927 Intended Vector 928 Offered Vector 929 Output Vectors 930 Expected Loss Vector 931 Expected Sequence Vector 932 Expected Forwarding Vector 933 Expected Jitter Vector 935 3.4.3.5 Expected Average Delay Vector 937 Definition: 938 A vector describing the expected average delay for packets 939 having a specific DSCP or IP precedence value. The value is 940 dependent on the set of offered vectors and configuration of 941 the DUT. 943 Discussion: 944 The DUT is configured in a certain way in order that service 945 differentiation occurs for a particular DSCP or IP precedence 946 value when a specific traffic mix consisting of multiple 947 DSCPs or IP precedence values are applied. This term 948 attempts to capture the expected forwarding behavior when 949 subjected to a certain offered vectors. 951 The actual algorithm or mechanism the DUT uses to achieve 952 service differentiation is not important in describing the 953 expected average delay vector. 955 Measurement units: 956 Seconds. 958 Network-layer Traffic Control Mechanisms 960 See Also: 961 Intended Vector 962 Offered Vector 963 Output Vectors 964 Expected Loss Vector 965 Expected Sequence Vector 966 Expected Forwarding Vector 967 Expected Jitter Vector 969 3.4.3.6 Expected Maximum Delay Vector 971 Definition: 972 A vector describing the expected maximum delay for packets 973 having a specific DSCP or IP precedence value. The value is 974 dependent on the set of offered vectors and configuration of 975 the DUT. 977 Discussion: 978 The DUT is configured in a certain way in order that service 979 differentiation occurs for a particular DSCP or IP precedence 980 value when a specific traffic mix consisting of multiple 981 DSCPs or IP precedence values are applied. This term 982 attempts to capture the expected forwarding behavior when 983 subjected to a certain offered vectors. 985 The actual algorithm or mechanism the DUT uses to achieve 986 service differentiation is not important in describing the 987 expected maximum delay vector. 989 Measurement units: 990 Seconds. 992 See Also: 993 Intended Vector 994 Offered Vector 995 Output Vectors 996 Expected Loss Vector 997 Expected Sequence Vector 998 Expected Forwarding Vector 999 Expected Jitter Vector 1001 3.4.3.7 Expected Minimum Delay Vector 1003 Definition: 1004 A vector describing the expected minimum delay for packets 1005 having a specific DSCP or IP precedence value. The value is 1006 dependent on the set of offered vectors and configuration of 1007 the DUT. 1009 Network-layer Traffic Control Mechanisms 1011 Discussion: 1012 The DUT is configured in a certain way in order that service 1013 differentiation occurs for a particular DSCP or IP precedence 1014 value when a specific traffic mix consisting of multiple 1015 DSCPs or IP precedence values are applied. This term 1016 attempts to capture the expected forwarding behavior when 1017 subjected to a certain offered vectors. 1019 The actual algorithm or mechanism the DUT uses to achieve 1020 service differentiation is not important in describing the 1021 expected minimum delay vector. 1023 Measurement units: 1024 Seconds. 1026 See Also: 1027 Intended Vector 1028 Offered Vector 1029 Output Vectors 1030 Expected Loss Vector 1031 Expected Sequence Vector 1032 Expected Forwarding Vector 1033 Expected Jitter Vector 1035 3.4.3.8 Expected Instantaneous Jitter Vector 1037 Definition: 1038 A vector describing the expected jitter between two 1039 consecutive packets arrival times having a specific DSCP or 1040 IP precedence value. The value is dependent on the set of 1041 offered vectors and configuration of the DUT. 1043 Discussion: 1044 Instantaneous Jitter is the absolute value of the difference 1045 between the delay measurement of two packets belonging to the 1046 same stream. 1048 The delay fluctuation between two consecutive packets in a 1049 stream is reported as the "Instantaneous Jitter". 1050 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 1051 where D equals the delay and is the test sequence number. 1052 Packets lost are not counted in the measurement. 1054 Forwarding Vector may contain several Jitter Vectors. For n 1055 packets received in a Forwarding Vector, there is a total of 1056 (n-1) Instantaneous Jitter Vectors. 1058 Measurement units: 1059 Seconds 1060 Network-layer Traffic Control Mechanisms 1062 See Also: 1063 Delay 1064 Jitter 1065 Offered Vector 1066 Output Vectors 1067 Expected Average Jitter Vector 1068 Expected Peak-to-peak Jitter Vector 1069 Stream 1071 3.4.3.9 Expected Average Jitter Vector 1073 Definition: 1074 A vector describing the expected jitter in packet arrival 1075 times for packets having a specific DSCP or IP precedence 1076 value. The value is dependent on the set of offered vectors 1077 and configuration of the DUT. 1079 Discussion: 1080 Average Jitter Vector is the average of all the Instantaneous 1081 Jitter Vectors measured during the test duration for the same 1082 DSCP or IP precedence value. 1084 Measurement units: 1085 Seconds 1087 See Also: 1088 Intended Vector 1089 Offered Vector 1090 Output Vectors 1091 Expected Instantaneous Jitter Vector 1092 Expected Peak-to-peak Jitter Vector 1094 3.4.3.10 Expected Peak-to-peak Jitter Vector 1096 Definition: 1097 A vector describing the expected maximum variation in the 1098 delay of packet arrival times for packets having a specific 1099 DSCP or IP precedence value. The value is dependent on the 1100 set of offered vectors and configuration of the DUT. 1102 Discussion: 1103 Peak-to-peak Jitter Vector is the maximum delay minus the 1104 minimum delay of the packets (in a vector) forwarded by the 1105 DUT/SUT. 1107 Peak-to-peak Jitter is not derived from the Instantaneous 1108 Jitter Vector. Peak-to-peak Jitter is based upon all the 1109 packets during the test duration, not just two consecutive 1110 packets. 1112 Network-layer Traffic Control Mechanisms 1114 Measurement units: 1115 Seconds 1117 See Also: 1118 Intended Vector 1119 Offered Vector 1120 Output Vectors 1121 Expected Instantaneous Jitter Vector 1122 Expected Average Jitter Vector 1124 3.4.4 Output Vectors 1126 3.4.4.1 Forwarding Vector 1128 Definition: 1129 The number of packets per second for all packets containing a 1130 specific DSCP or IP precedence value that a device can be 1131 observed to successfully forward to the correct destination 1132 interface in response to an offered vector. 1134 Discussion: 1135 Forwarding Vector is expressed as pair of numbers. Both the 1136 specific DSCP (or IP precedence) value AND the packets per 1137 second value combine to make a vector. 1139 The Forwarding Vector represents packet rate based on its 1140 specific DSCP (or IP precedence) value. It is not 1141 necessarily based on a stream or flow. The Forwarding Vector 1142 may be expressed as per port of the DUT/SUT. However, it 1143 MUST be consistent with the Expected Forwarding Vector. 1145 Forwarding Vector is a per-hop measurement. The DUT/SUT may 1146 change the specific DSCP (or IP precedence) value for a 1147 multiple-hop measurement. 1149 Measurement units: 1150 N-octet packets per second 1152 See Also: 1153 Intended Vector 1154 Offered Vector 1155 Expected Vectors 1156 Loss Vector 1157 Sequence Vector 1158 Delay Vectors 1159 Network-layer Traffic Control Mechanisms 1161 3.4.4.2 Loss Vector 1163 Definition: 1164 The percentage of packets containing a specific DSCP or IP 1165 precedence value that a DUT/SUT did not transmit to the 1166 correct destination interface in response to an offered 1167 vector. 1169 Discussion: 1170 Loss Vector is expressed as pair of numbers. Both the 1171 specific DSCP (or IP precedence) value AND the percentage 1172 value combine to make a vector. 1174 The Loss Vector represents percentage based on a specific 1175 DSCP or IP precedence value. It is not necessarily based on 1176 a stream or flow. The Loss Vector may be expressed as per 1177 port of the DUT/SUT. However, it MUST be consistent with the 1178 Expected Loss Vector 1180 Loss Vector is a per-hop measurement. The DUT/SUT may change 1181 the specific DSCP or IP precedence value for a multiple-hop 1182 measurement. 1184 Measurement Units: 1185 Percentage of offered packets that is not forwarded. 1187 See Also: 1188 Intended Vector 1189 Offered Vector 1190 Expected Vectors 1191 Forwarding Vector 1192 Sequence Vector 1193 Delay Vectors 1194 One-way Packet Loss Metric [Ka99] 1196 3.4.4.3 Sequence Vector 1198 Definition: 1199 The number of packets per second for all packets containing a 1200 specific DSCP or IP precedence value that a device can be 1201 observed to transmit in sequence to the correct destination 1202 interface in response to an offered vector. 1204 Discussion: 1205 Sequence Vector is expressed as pair of numbers. Both the 1206 specific DSCP (or IP precedence) value AND the packets per 1207 second value combine to make a vector. 1209 Network-layer Traffic Control Mechanisms 1211 The Sequence Vector represents packet rate based on its 1212 specific DSCP or IP precedence value. It is not necessarily 1213 based on a stream or flow. The Sequence Vector may be 1214 expressed as per port of the DUT/SUT. However, it MUST be 1215 consistent with the Expected Sequence Vector. 1217 Sequence Vector is a per-hop measurement. The DUT/SUT may 1218 change the specific DSCP or IP precedence value for a 1219 multiple-hop measurement. 1221 Measurement Units: 1222 N-octet packets per second 1224 Issues: 1226 See Also: 1227 In-sequence Packet 1228 Intended Vector 1229 Offered Vector 1230 Expected Vectors 1231 Loss Vector 1232 Forwarding Vector 1233 Delay Vectors 1235 3.4.4.4 Instantaneous Delay Vector 1237 Definition: 1238 The delay for a packet containing a specific DSCP or IP 1239 precedence value that a device can be observed to 1240 successfully transmit to the correct destination interface in 1241 response to an offered vector. 1243 Discussion: 1244 Instantaneous Delay vector is expressed as pair of numbers. 1245 Both the specific DSCP (or IP precedence) value AND delay 1246 value combine to make a vector. 1248 The Instantaneous Delay Vector represents delay on its 1249 specific DSCP or IP precedence value. It is not necessarily 1250 based on a stream or flow. The Delay vector may be expressed 1251 as per port of the DUT/SUT. However, it MUST be consistent 1252 with the Expected Delay vectors. 1254 Instantaneous Delay Vector is a per-hop measurement. The 1255 DUT/SUT may change the specific DSCP or IP precedence value 1256 for a multiple-hop measurement. 1258 Instantaneous Delay vector can be obtained at any offered 1259 load. RECOMMEND at or below the Forwarding Capacity in the 1260 absence of forwarding congestion. For congested delay, run 1261 the offered load above the Forwarding Capacity. 1263 Network-layer Traffic Control Mechanisms 1265 Forwarding Vector may contain several Instantaneous Delay 1266 Vectors. For every packet received in a Forwarding Vector, 1267 there is a corresponding Instantaneous Delay Vector. 1269 Measurement Units: 1270 Seconds 1272 See Also: 1273 Delay 1274 Intended Vector 1275 Offered Vector 1276 Expected Delay Vectors 1277 Average Delay Vector 1278 Maximum Delay Vector 1279 Minimum Delay Vector 1281 3.4.4.5 Average Delay Vector 1283 Definition: 1284 The average delay for packets containing a specific DSCP or 1285 IP precedence value that a device can be observed to 1286 successfully transmit to the correct destination interface in 1287 response to an offered vector. 1289 Discussion: 1290 Average Delay vector is expressed as pair of numbers. Both 1291 the specific DSCP (or IP precedence) value AND delay value 1292 combine to make a vector. 1294 The Delay Vector represents delay on its specific DSCP or IP 1295 precedence value. It is not necessarily based on a stream or 1296 flow. The Delay vector may be expressed as per port of the 1297 DUT/SUT. However, it MUST be consistent with the Expected 1298 Delay vector. 1300 The Average Delay Vector is computed by averaging all the 1301 Instantaneous Delay Vectors for a given vector. 1303 Average Delay Vector is a per-hop measurement. The DUT/SUT 1304 may change the specific DSCP or IP precedence value for a 1305 multiple-hop measurement. 1307 Average Delay vector can be obtained at any offered load. 1308 Recommend at or below the Forwarding Capacity in the absence 1309 of congestion. For congested delay, run the offered load 1310 above the Forwarding Capacity. 1312 Measurement Units: 1313 Seconds 1314 Network-layer Traffic Control Mechanisms 1316 See Also: 1317 Delay 1318 Intended Vector 1319 Offered Vector 1320 Expected Delay Vectors 1321 Instantaneous Delay Vector 1322 Maximum Delay Vector 1323 Minimum Delay Vector 1325 3.4.4.6 Maximum Delay Vector 1327 Definition: 1328 The maximum delay from all packets containing a specific DSCP 1329 or IP precedence value that a device can be observed to 1330 successfully transmit to the correct destination interface in 1331 response to an offered vector. 1333 Discussion: 1334 Maximum Delay vector is expressed as pair of numbers. Both 1335 the specific DSCP (or IP precedence) value AND delay value 1336 combine to make a vector. 1338 The Maximum Delay Vector represents delay on its specific 1339 DSCP or IP precedence value. It is not necessarily based on 1340 a stream or flow. The Maximum Delay vector may be expressed 1341 as per port of the DUT/SUT. However, it MUST be consistent 1342 with the Expected Delay vector. 1344 Maximum Delay Vector is based upon the maximum Instantaneous 1345 Delay Vector of all packets in a Forwarding Vector. 1347 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1348 may change the specific DSCP or IP precedence value for a 1349 multiple-hop measurement. 1351 Measurement Units: 1352 Seconds 1354 See Also: 1355 Delay 1356 Intended Vector 1357 Offered Vector 1358 Expected Delay Vectors 1359 Instantaneous Delay Vector 1360 Forwarding Vector 1361 Average Delay Vector 1362 Minimum Delay Vector 1363 Network-layer Traffic Control Mechanisms 1365 3.4.4.7 Minimum Delay Vector 1367 Definition: 1368 The minimum delay from all packets containing a specific DSCP 1369 or IP precedence value that a device can be observed to 1370 successfully transmit to the correct destination interface in 1371 response to an offered vector. 1373 Discussion: 1374 Delay vector is expressed as pair of numbers. Both the 1375 specific DSCP (or IP precedence) value AND delay value 1376 combine to make a vector. 1378 The Minimum Delay Vector represents delay on its specific 1379 DSCP or IP precedence value. It is not necessarily based on 1380 a stream or flow. The Minimum Delay vector may be expressed 1381 as per port of the DUT/SUT. However, it MUST be consistent 1382 with the Expected Delay vector. 1384 Minimum Delay Vector is based upon the minimum Instantaneous 1385 Delay Vector of all packets in a Forwarding Vector. 1387 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1388 may change the specific DSCP or IP precedence value for a 1389 multiple-hop measurement. 1391 Minimum Delay vector can be obtained at any offered load. 1392 Recommend at or below the Forwarding Capacity in the absence 1393 of congestion. For congested delay, run the offered load 1394 above the Forwarding Capacity. 1396 Measurement Units: 1397 Seconds 1399 See Also: 1400 Delay 1401 Intended Vector 1402 Offered Vector 1403 Expected Delay Vectors 1404 Instantaneous Delay Vector 1405 Forwarding Vector 1406 Average Delay Vector 1407 Maximum Delay Vector 1409 3.4.4.8 Instantaneous Jitter Vector 1411 Definition: 1412 The jitter for two consecutive packets containing a specific 1413 DSCP or IP precedence value that a device can be observed to 1414 successfully transmit to the correct destination interface in 1415 response to an offered vector. 1417 Network-layer Traffic Control Mechanisms 1419 Discussion: 1420 Instantaneous Jitter is the absolute value of the difference 1421 between the delay measurement of two packets belonging to the 1422 same stream. 1424 Jitter vector is expressed as pair of numbers. Both the 1425 specific DSCP (or IP precedence) value AND jitter value 1426 combine to make a vector. 1428 The delay fluctuation between two consecutive packets in a 1429 stream is reported as the "Instantaneous Jitter". 1430 Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)| 1431 where D equals the delay and i is the test sequence 1432 number. Packets lost are not counted in the measurement. 1434 Instantaneous Jitter Vector is a per-hop measurement. The 1435 DUT/SUT may change the specific DSCP or IP precedence value 1436 for a multiple-hop measurement. 1438 Forwarding Vector may contain several Instantaneous Jitter 1439 Vectors. For n packets received in a Forwarding Vector, 1440 there are exactly (n-1) Instantaneous Jitter Vectors. 1442 Measurement units: 1443 Seconds 1445 See Also: 1446 Delay 1447 Jitter 1448 Forwarding Vector 1449 Stream 1450 Expected Vectors 1451 Average Jitter Vector 1452 Peak-to-peak Jitter Vector 1454 3.4.4.9 Average Jitter Vector 1456 Definition: 1457 The average jitter for packets containing a specific DSCP or 1458 IP precedence value that a device can be observed to 1459 successfully transmit to the correct destination interface in 1460 response to an offered vector. 1462 Discussion: 1463 Average Jitter Vector is the average of all the Instantaneous 1464 Jitter Vectors of the same DSCP or IP precedence value, 1465 measured during the test duration. 1467 Average Jitter vector is expressed as pair of numbers. Both 1468 the specific DSCP (or IP precedence) value AND jitter value 1469 combine to make a vector. 1471 Network-layer Traffic Control Mechanisms 1473 Average Jitter vector is a per-hop measurement. The DUT/SUT 1474 may change the specific DSCP or IP precedence value for a 1475 multiple-hop measurement. 1477 Measurement units: 1478 Seconds 1480 See Also: 1481 Jitter 1482 Forwarding Vector 1483 Stream 1484 Expected Vectors 1485 Instantaneous Jitter Vector 1486 Peak-to-peak Jitter Vector 1488 3.4.4.10 Peak-to-peak Jitter Vector 1490 Definition: 1491 The maximum possible variation in the delay for packets 1492 containing a specific DSCP or IP precedence value that a 1493 device can be observed to successfully transmit to the 1494 correct destination interface in response to an offered 1495 vector. 1497 Discussion: 1498 Peak-to-peak Jitter Vector is the maximum delay minus the 1499 minimum delay of the packets (in a vector) forwarded by the 1500 DUT/SUT. 1502 Jitter vector is expressed as pair of numbers. Both the 1503 specific DSCP (or IP precedence) value AND jitter value 1504 combine to make a vector. 1506 Peak-to-peak Jitter is not derived from the Instantaneous 1507 Jitter Vector. Peak-to-peak Jitter is based upon all the 1508 packets during the test duration, not just two consecutive 1509 packets. 1511 Measurement units: 1512 Seconds 1514 See Also: 1515 Jitter 1516 Forwarding Vector 1517 Stream 1518 Expected Vectors 1519 Average Jitter Vector 1520 Peak-to-peak Jitter Vector 1521 Network-layer Traffic Control Mechanisms 1523 4. Acknowledgments 1525 The authors gratefully acknowledge the contributions of the 1526 IETF's benchmarking working group members in reviewing this 1527 document. The authors would like to express our thanks to 1528 David Newman for his consistent and valuable assistance 1529 throughout the development of this document. The following 1530 individuals also made noteworthy contributions to the 1531 editors' understanding of the subject matter: John Dawson, 1532 Kevin Dubray, and Kathleen Nichols. 1534 5. Security Considerations 1536 Documents of this type do not directly affect the security of 1537 the Internet or of corporate networks as long as benchmarking 1538 is not performed on devices or systems connected to 1539 production networks. 1541 Packets with unintended and/or unauthorized DSCP or IP 1542 precedence values may present security issues. Determining 1543 the security consequences of such packets is out of scope for 1544 this document. 1546 6. Normative References 1548 [Br91] Bradner, S., "Benchmarking Terminology for Network 1549 Interconnection Devices", RFC 1242, July 1991. 1551 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", RFC 2119, March 1997 1554 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1555 Switching Devices", RFC 2285, February 1998. 1557 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1558 of the Differentiated Services Field (DS Field) in the 1559 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1561 Network-layer Traffic Control Mechanisms 1563 7. Informative References 1565 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 1566 Metric for IPPM", RFC 2679, September 1999 1568 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1569 Weiss, W., "An Architecture for Differentiated Services", 1570 RFC 2475, December 1998. 1572 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 1573 Network Interconnect Devices", RFC 2544, March 1999 1575 [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 1576 Metric for IPPM", RFC 3393, November 2002 1578 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 1579 Forwarding PHB", RFC 2598, June 1999 1581 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1582 Packet Loss Metric for IPPM", RFC 2680, September 1999 1584 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 1585 Survey", RFC 1254, August 1991 1587 [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 1588 LAN Switching Devices", RFC 2889, August 2000 1590 [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1591 S., Perser, J., "Packet Reordering Metric for IPPM", 1592 Work in Progress 1594 [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1595 RFC 896, January 1984. 1597 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1598 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1599 January 1999. 1601 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1602 "RTP: A Transport Protocol for Real-Time Applications", 1603 RFC 1889, January 1996 1604 Network-layer Traffic Control Mechanisms 1606 8. Authors' Addresses 1608 Jerry Perser 1610 USA 1612 Phone: 1613 EMail: jerry@perser.org 1615 Scott Poretsky 1616 Quarry Technologies 1617 8 New England Executive Park 1618 Burlington, MA 01803 1619 USA 1621 Phone: + 1 508 439 9008 1622 EMail: sporetsky@quarrytech.com 1624 Shobha Erramilli 1625 QNetworx Inc 1626 1119 Campus Drive West 1627 Morganville, NJ 07751 1628 USA 1630 Phone: 1631 EMail: shobha@qnetworx.com 1633 Sumit Khurana 1634 Telcordia Technologies 1635 445 South Street 1636 Morristown, NJ 07960 1637 USA 1639 Phone: + 1 973 829 3170 1640 EMail: sumit@research.telcordia.com 1641 Network-layer Traffic Control Mechanisms 1643 Intellectual Property Statement 1645 The IETF takes no position regarding the validity or scope of any Intel- 1646 lectual Property Rights or other rights that might be claimed to pertain 1647 to the implementation or use of the technology described in this docu- 1648 ment or the extent to which any license under such rights might or might 1649 not be available; nor does it represent that it has made any independent 1650 effort to identify any such rights. Information on the procedures with 1651 respect to rights in RFC documents can be found in BCP 78 and BCP 79. 1652 Copies of IPR disclosures made to the IETF Secretariat and any 1653 assurances of licenses to be made available, or the result of an attempt 1654 made to obtain a general license or permission for the use of such 1655 proprietary rights by implementers or users of this specification can be 1656 obtained from the IETF on-line IPR repository at 1657 http://www.ietf.org/ipr. 1659 The IETF invites any interested party to bring to its attention any 1660 copyrights, patents or patent applications, or other proprietary rights 1661 that may cover technology that may be required to implement this stan- 1662 dard. Please address the information to the IETF at ietf-ipr@ietf.org. 1664 Disclaimer of Warranty 1666 This document and the information contained herein are provided on an 1667 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1668 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1669 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1670 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- 1671 TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1672 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1674 Copyright Statement 1676 Copyright (C) The Internet Society (2005). This document is subject to 1677 the rights, licenses and restrictions contained in BCP 78, and except as 1678 set forth therein, the authors retain all their rights.