idnits 2.17.1 draft-ietf-bmwg-dsmterm-11.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 29. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1662. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1686. ** Found boilerplate matching RFC 3978, Section 5.1 (on line 23), which is fine, but *also* found old RFC 3667, Section 5.1 text on line 29. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1650), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 47. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (July 2005) is 6831 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: 'Bl98' is defined on line 1576, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. 'Br91') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. 'Ma98') -- Obsolete informational reference (is this intentional?): RFC 2679 (ref. 'Al99') (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2598 (ref. 'Ja99') (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 2680 (ref. 'Ka99') (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 896 (ref. 'Na84') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2481 (ref. 'Ra99') (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. 'Sc96') (Obsoleted by RFC 3550) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jerry Perser 2 INTERNET-DRAFT 3 Expires in: January 2006 Scott Poretsky 4 Reef Point Systems 6 Shobha Erramilli 7 Qnetworx 9 Sumit Khurana 10 Telcordia 12 July 2005 14 Terminology for Benchmarking Network-layer 15 Traffic Control Mechanisms 17 19 Intellectual Property Rights (IPR) statement: 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Status of this Memo 26 By submitting this Internet-Draft, I certify that any applicable 27 patent or other IPR claims of which I am aware have been disclosed, 28 and any of which I become aware will be disclosed, in accordance with 29 RFC 3668. 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 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Copyright Notice 47 Copyright (C) The Internet Society (2005). All Rights Reserved. 49 Abstract 50 This document describes terminology for the benchmarking of 51 devices that implement traffic control based on IP precedence or 52 diff-serv code point criteria. The terminology is to be applied 53 to measurements made on the data plane to evaluate IP traffic 54 control mechanisms. 56 Network-layer Traffic Control Mechanisms 58 Table of Contents 59 1. Introduction .............................................. 3 60 2. Existing definitions ...................................... 3 61 3. Term definitions............................................4 62 3.1 Configuration Terms 63 3.1.1 Classification.........................................4 64 3.1.2 Codepoint Set..........................................4 65 3.1.3 Forwarding Congestion..................................5 66 3.1.4 Congestion Management..................................6 67 3.1.5 Flow...................................................7 68 3.2 Measurement Terms 69 3.2.1 Forwarding Capacity....................................7 70 3.2.2 Conforming Packet......................................8 71 3.2.3 Nonconforming Packet...................................9 72 3.2.4 Forwarding Delay.......................................9 73 3.2.5 Jitter................................................11 74 3.2.6 Undifferentiated Response.............................11 75 3.3 Sequence Tracking 76 3.3.1 In-sequence Packet....................................12 77 3.3.2 Out-of-order Packet...................................12 78 3.3.3 Duplicate Packet......................................13 79 3.3.4 Stream................................................14 80 3.3.5 Test Sequence number .................................15 81 3.4 Vectors...................................................15 82 3.4.1 Intended Vector.......................................15 83 3.4.2 Offered Vector........................................16 84 3.4.3 Expected Vectors 85 3.4.3.1 Expected Forwarding Vector........................16 86 3.4.3.2 Expected Loss Vector..............................17 87 3.4.3.3 Expected Sequence Vector..........................18 88 3.4.3.4 Expected Instantaneous Delay Vector...............18 89 3.4.3.5 Expected Average Delay Vector.....................19 90 3.4.3.6 Expected Maximum Delay Vector.....................10 91 3.4.3.7 Expected Minimum Delay Vector.....................20 92 3.4.3.8 Expected Instantaneous Jitter Vector..............21 93 3.4.3.9 Expected Average Jitter Vector....................22 94 3.4.3.10 Expected Peak-to-peak Jitter Vector..............22 95 3.4.4 Output Vectors 96 3.4.4.1 Forwarding Vector.................................23 97 3.4.4.2 Loss Vector.......................................24 98 3.4.4.3 Sequence Vector...................................24 99 3.4.4.4 Instantaneous Delay Vector........................25 100 3.4.4.5 Average Delay Vector..............................26 101 3.4.4.6 Maximum Delay Vector..............................27 102 3.4.4.7 Minimum Delay Vector..............................28 103 3.4.4.8 Instantaneous Jitter Vector.......................28 104 3.4.4.9 Average Jitter Vector.............................29 105 3.4.4.10 Peak-to-peak Jitter Vector.......................30 106 4. IANA Considerations........................................31 107 5. Security Considerations....................................31 108 6. Acknowledgments............................................31 109 Network-layer Traffic Control Mechanisms 111 7. References.................................................32 112 8. Author's Address...........................................33 113 9. Full Copyright Statement...................................34 115 1. Introduction 117 New terminology is needed because most existing measurements 118 assume the absence of congestion and only a single per-hop- 119 behavior. This document introduces several new terms that will 120 allow measurements to be taken during periods of congestion. 122 Another key difference from existing terminology is the definition 123 of measurements as observed on egress as well as ingress of a 124 device/system under test. Again, the existence of congestion 125 requires the addition of egress measurements as well as those 126 taken on ingress; without observing traffic leaving a 127 device/system it is not possible to say whether traffic-control 128 mechanisms effectively dealt with congestion. 130 The principal measurements introduced in this document are vectors 131 for rate, delay, and jitter, all of which can be observed with or 132 without congestion of the DUT/SUT. 134 This document describes only those terms relevant to measuring 135 behavior of a device or a group of devices using one of these two 136 mechanisms. End-to-end and service-level measurements are beyond 137 the scope of this document. 139 2. Existing definitions 140 RFC 1242 "Benchmarking Terminology for Network Interconnect 141 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 142 Devices" SHOULD be consulted before attempting to make use of this 143 document. 145 RFC 2474 "Definition of the Differentiated Services Field (DS 146 Field) in the IPv4 and IPv6 Headers" section 2, contains 147 discussions of a number of terms relevant to network-layer traffic 148 control mechanisms and SHOULD also be consulted. 150 For the sake of clarity and continuity this RFC adopts the 151 template for definitions set out in Section 2 of RFC 1242. 152 Definitions are indexed and grouped together in sections for ease 153 of reference. 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in BCP 14, RFC 2119 158 [Br97]. RFC 2119 defines the use of these key words to help make the 159 intent of standards track documents as clear as possible. While this 160 document uses these keywords, this document is not a standards track 161 document. 163 Network-layer Traffic Control Mechanisms 165 3. Term definitions 167 3.1 Configuration Terms 169 3.1.1 Classification 171 Definition: 172 Selection of packets based on the contents of packet header 173 according to defined rules. 175 Discussion: 176 Packets can be selected based on the DS field or IP 177 Precedence in the packet header. Classification can also be 178 based on Multi-Field (MF) criteria such as IP Source and 179 destination addresses, protocol and port number. 181 Classification determines the per-hop behaviors and traffic 182 conditioning functions such as shaping and dropping that are 183 to be applied to the packet. 185 Measurement units: n/a 187 See Also: 189 3.1.2 Codepoint Set 191 Definition: 192 The set of all DS Code-points or IP precedence values used 193 during the test duration. 195 Discussion: 196 Describes all the code-point markings associated with packets 197 that are input to the DUT/SUT. For each entry in the 198 codepoint set, there are associated vectors describing the 199 rate of traffic, delay, loss, or jitter containing that 200 particular DSCP or IP precedence value. 202 The treatment that a packet belonging to a particular code- 203 point gets is subject to the DUT classifying packets to map 204 to the correct PHB. Moreover, the forwarding treatment in 205 general is also dependent on the complete set of offered 206 vectors. 208 Measurement Units: n/a 210 See Also: None 211 Network-layer Traffic Control Mechanisms 213 3.1.3 Forwarding Congestion 215 Definition: 216 A condition in which one or more egress interfaces are 217 offered more packets than are forwarded. 219 Discussion: 220 This condition is a superset of the overload definition 221 [Ma98]. Overload [Ma98] deals with overloading input and 222 output interfaces beyond the maximum transmission allowed by 223 the medium. Forwarding congestion does not assume ingress 224 interface overload as the only source of overload on output 225 interfaces. 227 Another difference between Forwarding Congestion and overload 228 occurs when the SUT comprises multiple elements, in that 229 Forwarding Congestion may occur at multiple points. Consider 230 an SUT comprising multiple edge devices exchanging traffic 231 with a single core device. Depending on traffic patterns, 232 the edge devices may induce Forwarding Congestion on multiple 233 egress interfaces on the core device. 235 Packet Loss, not increased Delay, is the metric to indicate 236 the condition of Forwarding Congestion. Packet Loss is a 237 deterministic indicator of Forwarding Congestion. While 238 increased delay may be an indicator of Forwarding Congestion, 239 it is a non-deterministic indicator of Forwarding Congestion. 240 External observation of increased delay to indicate 241 congestion is in effect external observation of Incipient 242 Congestion. 244 [Ra99] implies that it is impractical to build a black-box 245 test to externally observe Incipient Congestion indicated by 246 increased delay in a router. [Ra99] introduces Explicit 247 Congestion Notification (ECN) as the externally observable, 248 deterministic method for indicating Incipient Congestion. 249 Because [Ra99] is an Experimental RFC with limited 250 deployment, ECN is not used for this particular methodology. 251 For the purpose of "black-box" testing a DUT/SUT, Packet Loss 252 as the indicator of Forwarding Congestion is used. 254 Throughput [Br91] defines the lower boundary of Forwarding 255 Congestion. Throughput is the maximum offered rate with no 256 Forwarding Congestion. At offered rates above throughput, 257 the DUT/SUT is considered to be in a state of Forwarding 258 Congestion. 260 Network-layer Traffic Control Mechanisms 262 Ingress observations alone are not sufficient to cover all 263 cases in which Forwarding Congestion may occur. A device 264 with an infinite amount of memory could buffer an infinite 265 number of packets, and eventually forward all of them. 266 However, these packets may or may not be forwarded during the 267 test duration. Even though ingress interfaces accept all 268 packets without loss, Forwarding Congestion is present in 269 this hypothetical device. 271 Forwarding Congestion, indicated by occurrence of packet 272 loss, is one type of congestion for a DUT/SUT. Congestion 273 Collapse [Na84] is defined as the state in which buffers are 274 full and all arriving packets MUST be dropped across the 275 network. Incipient Congestion [Ra99] is defined as 276 congestion that produces increased delay without packet loss. 278 The definition presented here explicitly defines Forwarding 279 Congestion as an event observable on egress interfaces. 280 Regardless of internal architecture, any device that cannot 281 forward packets on one or more egress interfaces is under 282 Forwarding Congestion. 284 Measurement units: 285 none 287 See Also: 288 Gateway Congestion Control Survey [Ma91] 290 3.1.4 Congestion Management 292 Definition: 293 An implementation of one or more per-hop-behaviors to avoid 294 or minimize the condition of congestion. 296 Discussion: 297 Congestion management may seek either to control congestion 298 or avoid it altogether. Such mechanisms classify packets 299 based upon IP Precedence or DSCP settings in a packets IP 300 header. 302 Congestion avoidance mechanisms seek to prevent congestion 303 before it actually occurs. 305 Congestion control mechanisms give one or more flows (with a 306 discrete IP Precedence or DSCP value) preferential treatment 307 over other classes during periods of congestion. 309 Measurement units: 310 n/a 312 See Also: 314 Network-layer Traffic Control Mechanisms 316 3.1.5 Flow 318 Definition: 319 A flow is a one or more of packets sharing a common intended 320 pair of source and destination interfaces. 322 Discussion: 323 Packets are grouped by the ingress and egress interfaces they 324 use on a given DUT/SUT. 326 A flow can contain multiple source IP addresses and/or 327 destination IP addresses. All packets in a flow MUST enter 328 on the same ingress interface and exit on the same egress 329 interface, and have some common network layer content. 331 Microflows [Ni98] are a subset of flows. As defined in 332 [Ni98], microflows require application-to-application 333 measurement. In contrast, flows use lower-layer 334 classification criteria. Since this document focuses on 335 network-layer classification criteria, we concentrate here on 336 the use of network-layer identifiers in describing a flow. 337 Flow identifiers also may reside at the data-link, transport, 338 or application layers of the OSI model. However, identifiers 339 other than those at the network layer are out of scope for 340 this document. 342 A flow may contain a single code point/IP precedence value or 343 may contain multiple values destined for a single egress 344 interface. This is determined by the test methodology. 346 Measurement units: 347 n/a 349 See Also: 350 Microflow [Ni98] 351 Streams 353 3.2 Measurement Terms 355 3.2.1 Forwarding Capacity 357 Definition: 358 The number of packets per second that a device can be 359 observed to successfully transmit to the correct destination 360 interface in response to a specified offered load while the 361 device drops none of the offered packets. 363 Network-layer Traffic Control Mechanisms 365 Discussion: 366 Forwarding Capacity measures the packet rate at the egress 367 interface(s) of the DUT/SUT. In contrast, throughput as 368 defined in RFC 1242 measures the frame rate at the ingress 369 interface(s) of the DUT/SUT. 371 Ingress-based measurements do not account for queuing of the 372 DUT/SUT. Throughput rates can be higher than the Forwarding 373 Capacity because of queuing. The difference is dependent 374 upon test duration, packet rate, and queue size. Forwarding 375 Capacity, as an egress measurement, does take queuing into 376 account. 378 Understanding Forwarding Capacity is a necessary precursor to 379 any measurement involving Traffic Control Mechanisms. The 380 accompanying methodology document MUST take into 381 consideration Forwarding Capacity when determining the 382 expected forwarding vectors. When the sum of the expected 383 forwarding vectors on an interface exceeds the Forwarding 384 Capacity, the Forwarding Capacity will govern the forwarding 385 rate. 387 This measurement differs from forwarding rate at maximum 388 offered load (FRMOL) [Ma98] in that Forwarding Capacity 389 requires zero loss. 391 Measurement units: 392 N-octet packets per second 394 See Also: 395 Throughput [Br91] 396 Forwarding Rate at Maximum Offered Load [Ma98] 398 3.2.2 Conforming Packet 400 Definition: 401 Packets which lie within specific rate, delay, or jitter 402 bounds. 404 Discussion: 405 A DUT/SUT may be configured to allow a given traffic class to 406 consume a given amount of bandwidth, or to fall within 407 predefined delay or jitter boundaries. All packets that lie 408 within specified bounds are then said to be conforming, 409 whereas those outside the bounds are nonconforming. 411 Measurement units: 412 n/a 413 Network-layer Traffic Control Mechanisms 415 See Also: 416 Expected Vector 417 Forwarding Vector 418 Offered Vector 419 Nonconforming 421 3.2.3 Nonconforming Packet 423 Definition: 424 Packets that do not lie within specific rate, delay, or 425 jitter bounds. 427 Discussion: 428 A DUT/SUT may be configured to allow a given traffic class to 429 consume a given amount of bandwidth, or to fall within 430 predefined delay or jitter boundaries. All packets that do 431 not lie within these bounds are then said to be 432 nonconforming. 434 Measurement units: 435 n/a 437 See Also: 438 Expected Vector 439 Forwarding Vector 440 Offered Vector 441 Conforming 443 3.2.4 Forwarding Delay 445 Definition: 446 The time interval starting when the last bit of the input IP 447 packet is offered to the input port of the DUT/SUT and ending 448 when the last bit of the output IP packet is received from 449 the output port of the DUT/SUT. 451 Discussion: 452 The delay time interval MUST be externally observed. The 453 delay measurement MUST NOT include delays added by test bed 454 components other than the DUT/SUT, such as propagation time 455 introduced by cabling or non-zero delay added by the test 456 instrument. 458 Forwarding Delay differs from latency [Br91] and one-way 459 delay [Al99] in several key regards: 461 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 462 uses "store and forward" or "bit forwarding" technology. 463 Forwarding Delay is the same metric, measured the same way, 464 regardless of the architecture of the DUT/SUT. 466 Network-layer Traffic Control Mechanisms 468 2. Forwarding Delay is a last-in, last-out (LILO) 469 measurement, unlike the last-in, first-out method [Br91] or 470 the first-in, last-out method [Al99]. 472 The LILO method most closely simulates the way a network- 473 layer device actually processes an IP datagram. IP datagrams 474 are not passed up and down the stack unless they are 475 complete, and processing begins only once the last bit of the 476 IP datagram has been received. 478 Further, the LILO method has an additive property, where the 479 sum of the parts MUST equal the whole. This is a key 480 difference from [Br91] and [Al99]. For example, the delay 481 added by two DUTs MUST equal the sum of the delay of the 482 DUTs. This may or may not be the case with [Br91] and 483 [Al99]. 485 3. Forwarding Delay measures the IP datagram only, unlike 486 [Br91], which also includes link layer overhead. 488 A metric focused exclusively on the Internet protocol 489 relieves the tester from specifying the start/end for every 490 link layer protocol that IP runs on. This avoids the need to 491 determine whether the start/stop delimiters are included. It 492 also allows the use of heterogeneous link layer protocols in 493 a test. 495 4. Forwarding Delay can be measured at any offered load, 496 whereas the latency methodology [Br99] recommends measurement 497 at, and only at, the throughput level. Comparing the 498 Forwarding Delay below the throughput to Forwarding Delay 499 above the Forwarding Capacity will give insight to the 500 traffic control mechanisms. 502 For example, non-congested delay may be measured with an 503 offered load that does not exceed the Forwarding Capacity, 504 while congested delay may involve an offered load that 505 exceeds Forwarding Capacity. 507 Note: Forwarding Delay SHOULD NOT be used as an absolute 508 indicator of DUT/SUT Forwarding Congestion. While Forwarding 509 Delay may rise when offered load nears or exceeds Forwarding 510 Capacity, there is no universal point at which Forwarding 511 Delay can be said to indicate the presence or absence of 512 Forwarding Congestion. 514 Measurement units: 515 Seconds. 517 Network-layer Traffic Control Mechanisms 519 See Also: 520 Latency [Br91] 521 Latency [Al99] 522 One-way Delay [Br99] 524 3.2.5 Jitter 526 Definition: 527 The absolute value of the difference between the arrival 528 delay of two consecutive received packets belonging to the 529 same stream. 531 Discussion: 532 The delay fluctuation between two consecutive received 533 packets in a stream is reported as the jitter. Jitter can be 534 expressed as |D(i) - D(i-1)| where D equals the delay and i 535 is the order the packets were received. 537 Under loss, jitter can be measured between non-consecutive 538 test sequence numbers. When IP Traffic Control Mechanisms are 539 dropping packets, fluctuating Forwarding Delay may be observed. 540 Jitter MUST be able to benchmark the delay variation 541 independent of packet loss. 543 Jitter is related to the ipdv [De02] (IP Delay Variation) by 544 taking the absolute value of the ipdv. The two metrics will 545 produce different mean values. Mean Jitter will produce a 546 positive value, where the mean ipdv is typically zero. 548 Measurement units: 549 Seconds 551 See Also: 552 Forwarding Delay 553 Jitter variation [Ja99] 554 ipdv [De02] 555 interarrival jitter [Sc96] 557 3.2.6 Undifferentiated Response 559 Definition: 560 The vector(s) obtained when mechanisms used to support 561 diff-serv or IP precedence are disabled. 563 Discussion: 564 Enabling diff-serv or IP precedence mechanisms may impose 565 additional processing overhead for packets. This overhead 566 may degrade performance even when traffic belonging to only 567 one class, the best-effort class, is offered to the device. 569 Network-layer Traffic Control Mechanisms 571 Measurements with "undifferentiated response" SHOULD be made 572 to establish a baseline. 574 The vector(s) obtained with DSCP or IP precedence enabled can 575 be compared to the undifferentiated response to determine the 576 effect of differentiating traffic. 578 Measurement units: 579 n/a 581 3.3 Sequence Tracking 583 3.3.1 In-sequence Packet 585 Definition: 586 A received packet with the expected Test Sequence number. 588 Discussion: 589 In-sequence is done on a stream level. As packets are 590 received on a stream, each packets Test Sequence number is 591 compared with the previous packet. Only packets that match 592 the expected Test Sequence number are considered in-sequence. 594 Packets that do not match the expected Test Sequence number 595 are counted as "not in-sequence" or out-of-sequence. Every 596 packet that is received is either in-sequence or out-of- 597 sequence. Subtracting the in-sequence from the received 598 packets (for that stream) can derive the out-of-sequence 599 count. 601 Two types of events will prevent the in-sequence from 602 incrementing: packet loss and reordered packets. 604 Measurement units: 605 Packet count 607 See Also: 608 Stream 609 Test Sequence number 611 3.3.2 Out-of-order Packet 613 Definition: 614 A received packet with a Test Sequence number less than 615 expected. 617 Network-layer Traffic Control Mechanisms 619 Discussion: 620 As a stream of packets enters a DUT/SUT, they include a 621 Stream Test Sequence number indicating the order the packets 622 were sent to the DUT/SUT. On exiting the DUT/SUT, these 623 packets may arrive in a different order. Each packet that 624 was re-ordered is counted as an Out-of-order Packet. 626 Certain streaming protocol (such as TCP) require the packets 627 to be in a certain order. Packets outside this are dropped 628 by the streaming protocols even though there were properly 629 received by the IP layer. The type of reordering tolerated 630 by a streaming protocol varies from protocol to protocol, and 631 also by implementation. 633 Out-of-order Packet count is based on the worst case 634 streaming protocol. It allows for no reordering. 636 Packet loss does not affect the Out-of-order Packet count. 637 Only packets that were not received in the order that they 638 were transmitted. 640 Measurement units: 641 Packet count 643 See Also: 644 Stream 645 Test Sequence number 646 Packet Reordering Metric for IPPM [Mo03] 648 3.3.3 Duplicate Packet 650 Definition: 651 A received packet with a Test Sequence number matching a 652 previously received packet. 654 Discussion: 655 A Duplicate Packet is a packet that the DUT/SUT has 656 successfully transmitted out an egress interface more than 657 once. The egress interface has previously forwarded this 658 packet. 660 A Duplicate Packet SHOULD be a bit for bit copy of an already 661 transmitted packet (including Test Sequence number). If the 662 Duplicate Packet traversed different paths through the 663 DUT/SUT, some fields (such as TTL or checksum) may have 664 changed. 666 Network-layer Traffic Control Mechanisms 668 A multicast packet is not a Duplicate Packet by definition. 669 For a given IP multicast group, a DUT/SUT SHOULD forward a 670 packet once on a given egress interface provided the path to 671 one or more multicast receivers is through that interface. 672 Several egress interfaces will transmit the same packet, but 673 only once per interface. 675 To detect a Duplicate Packet, each offered packet to the 676 DUT/SUT MUST contain a unique packet-by-packet identifier. 678 Measurement units: 679 Packet count 681 See Also: 682 Stream 683 Test Sequence number 685 3.3.4 Stream 687 Definition: 688 A group of packets tracked as a single entity by the traffic 689 receiver. A stream may share a common content such as type 690 (IP, UDP), packet size, or payload. 692 Discussion: 693 Streams are tracked by test sequence number or "unique 694 signature field" [Ma00]. Streams define how individual 695 packets statistic are grouped together to form an 696 intelligible summary. 698 Common stream groupings would be by egress interface, 699 destination address, source address, DSCP, or IP precedence. 700 A stream using test sequence numbers can track the ordering 701 of packets as they transverse the DUT/SUT. 703 Streams are not restricted to a pair of source and 704 destination interfaces as long as all packets are tracked as 705 a single entity. A multicast stream can be forward to 706 multiple destination interfaces. 708 Measurement units: 709 n/a 711 See Also: 712 Flow 713 Microflow [Ni98] 714 Test sequence number 715 Network-layer Traffic Control Mechanisms 717 3.3.5 Test Sequence number 719 Definition: 720 A field in the IP payload portion of the packet that is used 721 to verify the order of the packets on the egress of the 722 DUT/SUT. 724 Discussion: 725 The traffic generator sets the test sequence number value and 726 the traffic receiver checks the value upon receipt of the 727 packet. The traffic generator changes the value on each 728 packet transmitted based on an algorithm agreed to by the 729 traffic receiver. 731 The traffic receiver keeps track of the sequence numbers on a 732 per stream basis. In addition to number of received packets, 733 the traffic receiver may also report number of in-sequence 734 packets, number of out-of-sequence packets, number of 735 duplicate packets, and number of reordered packets. 737 The RECOMMENDED algorithm to use to change the sequence 738 number on sequential packets is an incrementing value. 740 Measurement units: 741 n/a 743 See Also: 744 Stream 746 3.4 Vectors 747 A vector is a group of packets all containing a specific DSCP 748 or IP precedence value. Vectors are expressed as a pair of 749 numbers. The first is being the particular diff-serv value. 750 The second is the metric expressed as a rate, loss 751 percentage, delay, or jitter. 753 3.4.1 Intended Vector 755 Definition: 756 A vector describing the attempted rate at which packets 757 having a specific code-point (or IP precedence) are 758 transmitted to a DUT/SUT by an external source. 760 Discussion: 761 Intended loads across the different code-point classes 762 determine the metrics associated with a specific code-point 763 traffic class. 765 Measurement Units: 766 N-octets packets per second 767 Network-layer Traffic Control Mechanisms 769 See Also: 770 Offered Vector 771 Expected Forwarding Vector 772 Expected Loss Vector 773 Expected Sequence Vector 774 Expected Delay Vector 775 Expected Jitter Vector 776 Forwarding Vector 777 Loss Vector 779 3.4.2 Offered Vector 781 Definition: 782 A vector describing the measured rate at which packets having 783 a specific DSCP or IP precedence value are offered to the 784 DUT/SUT. 786 Discussion: 787 Offered loads across the different code-point classes, 788 constituting a code-point set, determine the metrics 789 associated with a specific code-point traffic class. 791 Measurement Units: 792 N-octets packets per second 794 See Also: 795 Expected Forwarding Vector 796 Expected Loss Vector 797 Expected Sequence Vector 798 Expected Delay Vector 799 Expected Jitter Vector 800 Forwarding Vector 801 Codepoint Set 803 3.4.3 Expected Vectors 805 3.4.3.1 Expected Forwarding Vector 807 Definition: 808 A vector describing the expected output rate of packets 809 having a specific DSCP or IP precedence value. The value is 810 dependent on the set of offered vectors and configuration of 811 the DUT. 813 Network-layer Traffic Control Mechanisms 815 Discussion: 816 The DUT is configured in a certain way in order that service 817 differentiation occurs for a particular DSCP or IP precedence 818 value when a specific traffic mix consisting of multiple 819 DSCPs or IP precedence values are applied. This term 820 attempts to capture the expected forwarding behavior when 821 subjected to a certain offered vectors. 823 The actual algorithm or mechanism the DUT uses to achieve 824 service differentiation is not important in describing the 825 expected forwarding vector. 827 Measurement units: 828 N-octet packets per second 830 See Also: 831 Intended Vector 832 Offered Vector 833 Output Vectors 834 Expected Loss Vector 835 Expected Sequence Vector 836 Expected Delay Vector 837 Expected Jitter Vector 839 3.4.3.2 Expected Loss Vector 841 Definition: 842 A vector describing the percentage of packets, having a 843 specific DSCP or IP precedence value that SHOULD not be 844 forwarded. The value is dependent on the set of offered 845 vectors and configuration of the DUT. 847 Discussion: 848 The DUT is configured in a certain way in order that service 849 differentiation occurs for a particular DSCP or IP precedence 850 value when a specific traffic mix consisting of multiple 851 DSCPs or IP precedence values are applied. This term 852 attempts to capture the expected forwarding behavior when 853 subjected to a certain offered vector. 855 The actual algorithm or mechanism the DUT uses to achieve 856 service differentiation is not important in describing the 857 expected loss vector. 859 Measurement Units: 860 Percentage of intended packets that is expected to be 861 dropped. 863 Network-layer Traffic Control Mechanisms 865 See Also: 866 Intended Vector 867 Offered Vector 868 Expected Forwarding Vector 869 Expected Sequence Vector 870 Expected Delay Vector 871 Expected Jitter Vector 872 One-way Packet Loss Metric [Ka99] 874 3.4.3.3 Expected Sequence Vector 876 Definition: 877 A vector describing the expected in-sequence packets having a 878 specific DSCP or IP precedence value. The value is dependent 879 on the set of offered vectors and configuration of the DUT. 881 Discussion: 882 The DUT is configured in a certain way in order that service 883 differentiation occurs for a particular DSCP or IP precedence 884 value when a specific traffic mix consisting of multiple 885 DSCPs or IP precedence values are applied. This term 886 attempts to capture the expected forwarding behavior when 887 subjected to a certain offered vectors. 889 The actual algorithm or mechanism the DUT uses to achieve 890 service differentiation is not important in describing the 891 expected sequence vector. 893 Measurement Units: 894 N-octet packets per second 896 See Also: 897 Intended Vector 898 Offered Vector 899 Output Vectors 900 Expected Loss Vector 901 Expected Forwarding Vector 902 Expected Delay Vector 903 Expected Jitter Vector 905 3.4.3.4 Expected Instantaneous Delay Vector 907 Definition: 908 A vector describing the expected delay for packets having a 909 specific DSCP or IP precedence value. The value is dependent 910 on the set of offered vectors and configuration of the DUT. 912 Network-layer Traffic Control Mechanisms 914 Discussion: 915 The DUT is configured in a certain way in order that service 916 differentiation occurs for a particular DSCP or IP precedence 917 value when a specific traffic mix consisting of multiple 918 DSCPs or IP precedence values are applied. This term 919 attempts to capture the expected forwarding behavior when 920 subjected to a certain offered vectors. 922 The actual algorithm or mechanism the DUT uses to achieve 923 service differentiation is not important in describing the 924 expected delay vector. 926 Measurement units: 927 Seconds. 929 See Also: 930 Forwarding Delay 931 Intended Vector 932 Offered Vector 933 Output Vectors 934 Expected Loss Vector 935 Expected Sequence Vector 936 Expected Forwarding Vector 937 Expected Jitter Vector 939 3.4.3.5 Expected Average Delay Vector 941 Definition: 942 A vector describing the expected average delay for packets 943 having a specific DSCP or IP precedence value. The value is 944 dependent on the set of offered vectors and configuration of 945 the DUT. 947 Discussion: 948 The DUT is configured in a certain way in order that service 949 differentiation occurs for a particular DSCP or IP precedence 950 value when a specific traffic mix consisting of multiple 951 DSCPs or IP precedence values are applied. This term 952 attempts to capture the expected forwarding behavior when 953 subjected to a certain offered vectors. 955 The actual algorithm or mechanism the DUT uses to achieve 956 service differentiation is not important in describing the 957 expected average delay vector. 959 Measurement units: 960 Seconds. 962 Network-layer Traffic Control Mechanisms 964 See Also: 965 Intended Vector 966 Offered Vector 967 Output Vectors 968 Expected Loss Vector 969 Expected Sequence Vector 970 Expected Forwarding Vector 971 Expected Jitter Vector 973 3.4.3.6 Expected Maximum Delay Vector 975 Definition: 976 A vector describing the expected maximum delay for packets 977 having a specific DSCP or IP precedence value. The value is 978 dependent on the set of offered vectors and configuration of 979 the DUT. 981 Discussion: 982 The DUT is configured in a certain way in order that service 983 differentiation occurs for a particular DSCP or IP precedence 984 value when a specific traffic mix consisting of multiple 985 DSCPs or IP precedence values are applied. This term 986 attempts to capture the expected forwarding behavior when 987 subjected to a certain offered vectors. 989 The actual algorithm or mechanism the DUT uses to achieve 990 service differentiation is not important in describing the 991 expected maximum delay vector. 993 Measurement units: 994 Seconds. 996 See Also: 997 Intended Vector 998 Offered Vector 999 Output Vectors 1000 Expected Loss Vector 1001 Expected Sequence Vector 1002 Expected Forwarding Vector 1003 Expected Jitter Vector 1005 3.4.3.7 Expected Minimum Delay Vector 1007 Definition: 1008 A vector describing the expected minimum delay for packets 1009 having a specific DSCP or IP precedence value. The value is 1010 dependent on the set of offered vectors and configuration of 1011 the DUT. 1013 Network-layer Traffic Control Mechanisms 1015 Discussion: 1016 The DUT is configured in a certain way in order that service 1017 differentiation occurs for a particular DSCP or IP precedence 1018 value when a specific traffic mix consisting of multiple 1019 DSCPs or IP precedence values are applied. This term 1020 attempts to capture the expected forwarding behavior when 1021 subjected to a certain offered vectors. 1023 The actual algorithm or mechanism the DUT uses to achieve 1024 service differentiation is not important in describing the 1025 expected minimum delay vector. 1027 Measurement units: 1028 Seconds. 1030 See Also: 1031 Intended Vector 1032 Offered Vector 1033 Output Vectors 1034 Expected Loss Vector 1035 Expected Sequence Vector 1036 Expected Forwarding Vector 1037 Expected Jitter Vector 1039 3.4.3.8 Expected Instantaneous Jitter Vector 1041 Definition: 1042 A vector describing the expected jitter between two 1043 consecutive packets arrival times having a specific DSCP or 1044 IP precedence value. The value is dependent on the set of 1045 offered vectors and configuration of the DUT. 1047 Discussion: 1048 Instantaneous Jitter is the absolute value of the difference 1049 between the delay measurement of two packets belonging to the 1050 same stream. 1052 The delay fluctuation between two consecutive packets in a 1053 stream is reported as the "Instantaneous Jitter". 1054 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 1055 where D equals the delay and is the test sequence number. 1056 Packets lost are not counted in the measurement. 1058 Forwarding Vector may contain several Jitter Vectors. For n 1059 packets received in a Forwarding Vector, there is a total of 1060 (n-1) Instantaneous Jitter Vectors. 1062 Measurement units: 1063 Seconds 1064 Network-layer Traffic Control Mechanisms 1066 See Also: 1067 Delay 1068 Jitter 1069 Offered Vector 1070 Output Vectors 1071 Expected Average Jitter Vector 1072 Expected Peak-to-peak Jitter Vector 1073 Stream 1075 3.4.3.9 Expected Average Jitter Vector 1077 Definition: 1078 A vector describing the expected jitter in packet arrival 1079 times for packets having a specific DSCP or IP precedence 1080 value. The value is dependent on the set of offered vectors 1081 and configuration of the DUT. 1083 Discussion: 1084 Average Jitter Vector is the average of all the Instantaneous 1085 Jitter Vectors measured during the test duration for the same 1086 DSCP or IP precedence value. 1088 Measurement units: 1089 Seconds 1091 See Also: 1092 Intended Vector 1093 Offered Vector 1094 Output Vectors 1095 Expected Instantaneous Jitter Vector 1096 Expected Peak-to-peak Jitter Vector 1098 3.4.3.10 Expected Peak-to-peak Jitter Vector 1100 Definition: 1101 A vector describing the expected maximum variation in the 1102 delay of packet arrival times for packets having a specific 1103 DSCP or IP precedence value. The value is dependent on the 1104 set of offered vectors and configuration of the DUT. 1106 Discussion: 1107 Peak-to-peak Jitter Vector is the maximum delay minus the 1108 minimum delay of the packets (in a vector) forwarded by the 1109 DUT/SUT. 1111 Peak-to-peak Jitter is not derived from the Instantaneous 1112 Jitter Vector. Peak-to-peak Jitter is based upon all the 1113 packets during the test duration, not just two consecutive 1114 packets. 1116 Network-layer Traffic Control Mechanisms 1118 Measurement units: 1119 Seconds 1121 See Also: 1122 Intended Vector 1123 Offered Vector 1124 Output Vectors 1125 Expected Instantaneous Jitter Vector 1126 Expected Average Jitter Vector 1128 3.4.4 Output Vectors 1130 3.4.4.1 Forwarding Vector 1132 Definition: 1133 The number of packets per second for all packets containing a 1134 specific DSCP or IP precedence value that a device can be 1135 observed to successfully forward to the correct destination 1136 interface in response to an offered vector. 1138 Discussion: 1139 Forwarding Vector is expressed as pair of numbers. Both the 1140 specific DSCP (or IP precedence) value AND the packets per 1141 second value combine to make a vector. 1143 The Forwarding Vector represents packet rate based on its 1144 specific DSCP (or IP precedence) value. It is not 1145 necessarily based on a stream or flow. The Forwarding Vector 1146 may be expressed as per port of the DUT/SUT. However, it 1147 MUST be consistent with the Expected Forwarding Vector. 1149 Forwarding Vector is a per-hop measurement. The DUT/SUT may 1150 change the specific DSCP (or IP precedence) value for a 1151 multiple-hop measurement. 1153 Measurement units: 1154 N-octet packets per second 1156 See Also: 1157 Intended Vector 1158 Offered Vector 1159 Expected Vectors 1160 Loss Vector 1161 Sequence Vector 1162 Delay Vectors 1163 Network-layer Traffic Control Mechanisms 1165 3.4.4.2 Loss Vector 1167 Definition: 1168 The percentage of packets containing a specific DSCP or IP 1169 precedence value that a DUT/SUT did not transmit to the 1170 correct destination interface in response to an offered 1171 vector. 1173 Discussion: 1174 Loss Vector is expressed as pair of numbers. Both the 1175 specific DSCP (or IP precedence) value AND the percentage 1176 value combine to make a vector. 1178 The Loss Vector represents percentage based on a specific 1179 DSCP or IP precedence value. It is not necessarily based on 1180 a stream or flow. The Loss Vector may be expressed as per 1181 port of the DUT/SUT. However, it MUST be consistent with the 1182 Expected Loss Vector 1184 Loss Vector is a per-hop measurement. The DUT/SUT may change 1185 the specific DSCP or IP precedence value for a multiple-hop 1186 measurement. 1188 Measurement Units: 1189 Percentage of offered packets that is not forwarded. 1191 See Also: 1192 Intended Vector 1193 Offered Vector 1194 Expected Vectors 1195 Forwarding Vector 1196 Sequence Vector 1197 Delay Vectors 1198 One-way Packet Loss Metric [Ka99] 1200 3.4.4.3 Sequence Vector 1202 Definition: 1203 The number of packets per second for all packets containing a 1204 specific DSCP or IP precedence value that a device can be 1205 observed to transmit in sequence to the correct destination 1206 interface in response to an offered vector. 1208 Discussion: 1209 Sequence Vector is expressed as pair of numbers. Both the 1210 specific DSCP (or IP precedence) value AND the packets per 1211 second value combine to make a vector. 1213 Network-layer Traffic Control Mechanisms 1215 The Sequence Vector represents packet rate based on its 1216 specific DSCP or IP precedence value. It is not necessarily 1217 based on a stream or flow. The Sequence Vector may be 1218 expressed as per port of the DUT/SUT. However, it MUST be 1219 consistent with the Expected Sequence Vector. 1221 Sequence Vector is a per-hop measurement. The DUT/SUT may 1222 change the specific DSCP or IP precedence value for a 1223 multiple-hop measurement. 1225 Measurement Units: 1226 N-octet packets per second 1228 Issues: 1230 See Also: 1231 In-sequence Packet 1232 Intended Vector 1233 Offered Vector 1234 Expected Vectors 1235 Loss Vector 1236 Forwarding Vector 1237 Delay Vectors 1239 3.4.4.4 Instantaneous Delay Vector 1241 Definition: 1242 The delay for a packet containing a specific DSCP or IP 1243 precedence value that a device can be observed to 1244 successfully transmit to the correct destination interface in 1245 response to an offered vector. 1247 Discussion: 1248 Instantaneous Delay vector is expressed as pair of numbers. 1249 Both the specific DSCP (or IP precedence) value AND delay 1250 value combine to make a vector. 1252 The Instantaneous Delay Vector represents delay on its 1253 specific DSCP or IP precedence value. It is not necessarily 1254 based on a stream or flow. The Delay vector may be expressed 1255 as per port of the DUT/SUT. However, it MUST be consistent 1256 with the Expected Delay vectors. 1258 Instantaneous Delay Vector is a per-hop measurement. The 1259 DUT/SUT may change the specific DSCP or IP precedence value 1260 for a multiple-hop measurement. 1262 Instantaneous Delay vector can be obtained at any offered 1263 load. RECOMMEND at or below the Forwarding Capacity in the 1264 absence of forwarding congestion. For congested delay, run 1265 the offered load above the Forwarding Capacity. 1267 Network-layer Traffic Control Mechanisms 1269 Forwarding Vector may contain several Instantaneous Delay 1270 Vectors. For every packet received in a Forwarding Vector, 1271 there is a corresponding Instantaneous Delay Vector. 1273 Measurement Units: 1274 Seconds 1276 See Also: 1277 Delay 1278 Intended Vector 1279 Offered Vector 1280 Expected Delay Vectors 1281 Average Delay Vector 1282 Maximum Delay Vector 1283 Minimum Delay Vector 1285 3.4.4.5 Average Delay Vector 1287 Definition: 1288 The average delay for packets containing a specific DSCP or 1289 IP precedence value that a device can be observed to 1290 successfully transmit to the correct destination interface in 1291 response to an offered vector. 1293 Discussion: 1294 Average Delay vector is expressed as pair of numbers. Both 1295 the specific DSCP (or IP precedence) value AND delay value 1296 combine to make a vector. 1298 The Delay Vector represents delay on its specific DSCP or IP 1299 precedence value. It is not necessarily based on a stream or 1300 flow. The Delay vector may be expressed as per port of the 1301 DUT/SUT. However, it MUST be consistent with the Expected 1302 Delay vector. 1304 The Average Delay Vector is computed by averaging all the 1305 Instantaneous Delay Vectors for a given vector. 1307 Average Delay Vector is a per-hop measurement. The DUT/SUT 1308 may change the specific DSCP or IP precedence value for a 1309 multiple-hop measurement. 1311 Average Delay vector can be obtained at any offered load. 1312 Recommend at or below the Forwarding Capacity in the absence 1313 of congestion. For congested delay, run the offered load 1314 above the Forwarding Capacity. 1316 Measurement Units: 1317 Seconds 1318 Network-layer Traffic Control Mechanisms 1320 See Also: 1321 Delay 1322 Intended Vector 1323 Offered Vector 1324 Expected Delay Vectors 1325 Instantaneous Delay Vector 1326 Maximum Delay Vector 1327 Minimum Delay Vector 1329 3.4.4.6 Maximum Delay Vector 1331 Definition: 1332 The maximum delay from all packets containing a specific DSCP 1333 or IP precedence value that a device can be observed to 1334 successfully transmit to the correct destination interface in 1335 response to an offered vector. 1337 Discussion: 1338 Maximum Delay vector is expressed as pair of numbers. Both 1339 the specific DSCP (or IP precedence) value AND delay value 1340 combine to make a vector. 1342 The Maximum Delay Vector represents delay on its specific 1343 DSCP or IP precedence value. It is not necessarily based on 1344 a stream or flow. The Maximum Delay vector may be expressed 1345 as per port of the DUT/SUT. However, it MUST be consistent 1346 with the Expected Delay vector. 1348 Maximum Delay Vector is based upon the maximum Instantaneous 1349 Delay Vector of all packets in a Forwarding Vector. 1351 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1352 may change the specific DSCP or IP precedence value for a 1353 multiple-hop measurement. 1355 Measurement Units: 1356 Seconds 1358 See Also: 1359 Delay 1360 Intended Vector 1361 Offered Vector 1362 Expected Delay Vectors 1363 Instantaneous Delay Vector 1364 Forwarding Vector 1365 Average Delay Vector 1366 Minimum Delay Vector 1367 Network-layer Traffic Control Mechanisms 1369 3.4.4.7 Minimum Delay Vector 1371 Definition: 1372 The minimum delay from all packets containing a specific DSCP 1373 or IP precedence value that a device can be observed to 1374 successfully transmit to the correct destination interface in 1375 response to an offered vector. 1377 Discussion: 1378 Delay vector is expressed as pair of numbers. Both the 1379 specific DSCP (or IP precedence) value AND delay value 1380 combine to make a vector. 1382 The Minimum Delay Vector represents delay on its specific 1383 DSCP or IP precedence value. It is not necessarily based on 1384 a stream or flow. The Minimum Delay vector may be expressed 1385 as per port of the DUT/SUT. However, it MUST be consistent 1386 with the Expected Delay vector. 1388 Minimum Delay Vector is based upon the minimum Instantaneous 1389 Delay Vector of all packets in a Forwarding Vector. 1391 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1392 may change the specific DSCP or IP precedence value for a 1393 multiple-hop measurement. 1395 Minimum Delay vector can be obtained at any offered load. 1396 Recommend at or below the Forwarding Capacity in the absence 1397 of congestion. For congested delay, run the offered load 1398 above the Forwarding Capacity. 1400 Measurement Units: 1401 Seconds 1403 See Also: 1404 Delay 1405 Intended Vector 1406 Offered Vector 1407 Expected Delay Vectors 1408 Instantaneous Delay Vector 1409 Forwarding Vector 1410 Average Delay Vector 1411 Maximum Delay Vector 1413 3.4.4.8 Instantaneous Jitter Vector 1414 Definition: 1415 The jitter for two consecutive packets containing a specific 1416 DSCP or IP precedence value that a device can be observed to 1417 successfully transmit to the correct destination interface in 1418 response to an offered vector. 1420 Network-layer Traffic Control Mechanisms 1422 Discussion: 1423 Instantaneous Jitter is the absolute value of the difference 1424 between the delay measurement of two packets belonging to the 1425 same stream. 1427 Jitter vector is expressed as pair of numbers. Both the 1428 specific DSCP (or IP precedence) value AND jitter value 1429 combine to make a vector. 1431 The delay fluctuation between two consecutive packets in a 1432 stream is reported as the "Instantaneous Jitter". 1433 Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)| 1434 where D equals the delay and i is the test sequence 1435 number. Packets lost are not counted in the measurement. 1437 Instantaneous Jitter Vector is a per-hop measurement. The 1438 DUT/SUT may change the specific DSCP or IP precedence value 1439 for a multiple-hop measurement. 1441 Forwarding Vector may contain several Instantaneous Jitter 1442 Vectors. For n packets received in a Forwarding Vector, 1443 there are exactly (n-1) Instantaneous Jitter Vectors. 1445 Measurement units: 1446 Seconds 1448 See Also: 1449 Delay 1450 Jitter 1451 Forwarding Vector 1452 Stream 1453 Expected Vectors 1454 Average Jitter Vector 1455 Peak-to-peak Jitter Vector 1457 3.4.4.9 Average Jitter Vector 1459 Definition: 1460 The average jitter for packets containing a specific DSCP or 1461 IP precedence value that a device can be observed to 1462 successfully transmit to the correct destination interface in 1463 response to an offered vector. 1465 Discussion: 1466 Average Jitter Vector is the average of all the Instantaneous 1467 Jitter Vectors of the same DSCP or IP precedence value, 1468 measured during the test duration. 1470 Average Jitter vector is expressed as pair of numbers. Both 1471 the specific DSCP (or IP precedence) value AND jitter value 1472 combine to make a vector. 1474 Network-layer Traffic Control Mechanisms 1476 Average Jitter vector is a per-hop measurement. The DUT/SUT 1477 may change the specific DSCP or IP precedence value for a 1478 multiple-hop measurement. 1480 Measurement units: 1481 Seconds 1483 See Also: 1484 Jitter 1485 Forwarding Vector 1486 Stream 1487 Expected Vectors 1488 Instantaneous Jitter Vector 1489 Peak-to-peak Jitter Vector 1491 3.4.4.10 Peak-to-peak Jitter Vector 1493 Definition: 1494 The maximum possible variation in the delay for packets 1495 containing a specific DSCP or IP precedence value that a 1496 device can be observed to successfully transmit to the 1497 correct destination interface in response to an offered 1498 vector. 1500 Discussion: 1501 Peak-to-peak Jitter Vector is the maximum delay minus the 1502 minimum delay of the packets (in a vector) forwarded by the 1503 DUT/SUT. 1505 Jitter vector is expressed as pair of numbers. Both the 1506 specific DSCP (or IP precedence) value AND jitter value 1507 combine to make a vector. 1509 Peak-to-peak Jitter is not derived from the Instantaneous 1510 Jitter Vector. Peak-to-peak Jitter is based upon all the 1511 packets during the test duration, not just two consecutive 1512 packets. 1514 Measurement units: 1515 Seconds 1517 See Also: 1518 Jitter 1519 Forwarding Vector 1520 Stream 1521 Expected Vectors 1522 Average Jitter Vector 1523 Peak-to-peak Jitter Vector 1524 Network-layer Traffic Control Mechanisms 1526 4. IANA Considerations 1528 This document requires no IANA considerations. 1530 5. Security Considerations 1532 Documents of this type do not directly affect the security of 1533 the Internet or of corporate networks as long as benchmarking 1534 is not performed on devices or systems connected to 1535 production networks. 1537 Packets with unintended and/or unauthorized DSCP or IP 1538 precedence values may present security issues. Determining 1539 the security consequences of such packets is out of scope for 1540 this document. 1542 6. Acknowledgments 1544 The authors gratefully acknowledge the contributions of the 1545 IETF's benchmarking working group members in reviewing this 1546 document. The authors would like to express our thanks to 1547 David Newman for his consistent and valuable assistance 1548 throughout the development of this document. The authors 1549 would also like to thank Al Morton (acmorton@att.com) and 1550 Kevin Dubray (kdubray@juniper.net) for their ideas and 1551 support. 1553 7. References 1554 7.1 Normative References 1556 [Br91] Bradner, S., "Benchmarking Terminology for Network 1557 Interconnection Devices", RFC 1242, July 1991. 1559 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 1560 Requirement Levels", RFC 2119, March 1997 1562 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1563 Switching Devices", RFC 2285, July 1998. 1565 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1566 of the Differentiated Services Field (DS Field) in the 1567 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1569 Network-layer Traffic Control Mechanisms 1571 7.2 Informative References 1573 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 1574 Metric for IPPM", RFC 2679, September 1999 1576 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1577 Weiss, W., "An Architecture for Differentiated Services", 1578 RFC 2475, December 1998. 1580 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 1581 Network Interconnect Devices", RFC 2544, March 1999 1583 [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 1584 Metric for IPPM", RFC 3393, November 2002 1586 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 1587 Forwarding PHB", RFC 2598, June 1999 1589 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1590 Packet Loss Metric for IPPM", RFC 2680, September 1999 1592 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 1593 Survey", RFC 1254, August 1991 1595 [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 1596 LAN Switching Devices", RFC 2889, August 2000 1598 [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1599 S., Perser, J., "Packet Reordering Metric for IPPM", 1600 Work in Progress 1602 [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1603 RFC 896, January 1984. 1605 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1606 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1607 January 1999. 1609 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1610 "RTP: A Transport Protocol for Real-Time Applications", 1611 RFC 1889, January 1996 1612 Network-layer Traffic Control Mechanisms 1614 8. Authors' Addresses 1616 Jerry Perser 1617 USA 1619 EMail: jerry@perser.org 1621 Scott Poretsky 1622 Reef Point Systems 1623 8 New England Executive Park 1624 Burlington, MA 01803 1625 USA 1627 Phone: + 1 508 439 9008 1628 EMail: sporetsky@reefpoint.com 1630 Shobha Erramilli 1631 QNetworx Inc 1632 1119 Campus Drive West 1633 Morganville, NJ 07751 1634 USA 1636 EMail: shobha@qnetworx.com 1638 Sumit Khurana 1639 Telcordia Technologies 1640 445 South Street 1641 Morristown, NJ 07960 1642 USA 1644 Phone: + 1 973 829 3170 1645 EMail: sumit@research.telcordia.com 1646 Network-layer Traffic Control Mechanisms 1648 Full Copyright Statement 1650 Copyright (C) The Internet Society (2005). 1652 This document is subject to the rights, licenses and restrictions 1653 contained in BCP 78, and except as set forth therein, the authors 1654 retain all their rights. 1656 This document and the information contained herein are provided on an 1657 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1658 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1659 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1660 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1661 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1662 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1664 Intellectual Property 1666 The IETF takes no position regarding the validity or scope of any 1667 Intellectual Property Rights or other rights that might be claimed to 1668 pertain to the implementation or use of the technology described in 1669 this document or the extent to which any license under such rights 1670 might or might not be available; nor does it represent that it has 1671 made any independent effort to identify any such rights. Information 1672 on the procedures with respect to rights in RFC documents can be 1673 found in BCP 78 and BCP 79. 1675 Copies of IPR disclosures made to the IETF Secretariat and any 1676 assurances of licenses to be made available, or the result of an 1677 attempt made to obtain a general license or permission for the use of 1678 such proprietary rights by implementers or users of this 1679 specification can be obtained from the IETF on-line IPR repository at 1680 http://www.ietf.org/ipr. 1682 The IETF invites any interested party to bring to its attention any 1683 copyrights, patents or patent applications, or other proprietary 1684 rights that may cover technology that may be required to implement 1685 this standard. Please address the information to the IETF at ietf- 1686 ipr@ietf.org. 1688 Acknowledgement 1690 Funding for the RFC Editor function is currently provided by the 1691 Internet Society.