idnits 2.17.1 draft-ietf-bmwg-dsmterm-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** 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.) ** There are 48 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 -- 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 (June 2003) is 7618 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 1556, 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: 5 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jerry Perser 3 INTERNET-DRAFT Spirent 4 Expires in: December 2003 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 QNetworx 10 Scott Poretsky 11 Avici Systems 12 June 2003 14 Terminology for Benchmarking Network-layer 15 Traffic Control Mechanisms 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- 32 Drafts as reference material or to cite them other than as "work 33 in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2003). All Rights Reserved. 45 Abstract 47 This document describes terminology for the benchmarking of 48 devices that implement traffic control based on IP precedence or 49 diff-serv code point criteria. 51 Network-layer Traffic Control Mechanisms 53 Table of Contents 55 1. Introduction .............................................. 3 56 2. Existing definitions ...................................... 3 57 3. Term definitions ............................................4 58 3.1 Configuration Terms 59 3.1.1 Classification .........................................4 60 3.1.2 Codepoint Set ..........................................4 61 3.1.3 Forwarding Congestion ..................................5 62 3.1.4 Congestion Management ..................................6 63 3.1.5 Flow ...................................................7 64 3.2 Measurement Terms 65 3.2.1 Channel Capacity .......................................7 66 3.2.2 Conforming Packet ......................................8 67 3.2.3 Nonconforming Packet ...................................9 68 3.2.4 Forwarding Delay .......................................9 69 3.2.5 Jitter ................................................11 70 3.2.6 Undifferentiated Response .............................11 71 3.3 Sequence Tracking 72 3.3.1 In-sequence Packet ....................................12 73 3.3.2 Out-of-order Packet ...................................12 74 3.3.3 Duplicate Packet ......................................13 75 3.3.4 Stream ................................................14 76 3.3.5 Test Sequence number .................................14 77 3.4 Vectors ...................................................15 78 3.4.1 Intended Vector .......................................15 79 3.4.2 Offered Vector ........................................16 80 3.4.3 Expected Vectors 81 3.4.3.1 Expected Forwarding Vector ........................16 82 3.4.3.2 Expected Loss Vector ..............................17 83 3.4.3.3 Expected Sequence Vector ..........................18 84 3.4.3.4 Expected Instantaneous Delay Vector ...............18 85 3.4.3.5 Expected Average Delay Vector .....................19 86 3.4.3.6 Expected Maximum Delay Vector .....................10 87 3.4.3.7 Expected Minimum Delay Vector .....................20 88 3.4.3.8 Expected Instantaneous Jitter Vector ..............21 89 3.4.3.9 Expected Average Jitter Vector ....................22 90 3.4.3.10 Expected Peak-to-peak Jitter Vector ..............22 91 3.4.4 Output Vectors 92 3.4.4.1 Forwarding Vector .................................23 93 3.4.4.2 Loss Vector .......................................24 94 3.4.4.3 Sequence Vector ...................................24 95 3.4.4.4 Instantaneous Delay Vector ........................25 96 3.4.4.5 Average Delay Vector ..............................26 97 3.4.4.6 Maximum Delay Vector ..............................27 98 3.4.4.7 Minimum Delay Vector ..............................28 99 3.4.4.8 Instantaneous Jitter Vector .......................28 100 3.4.4.9 Average Jitter Vector .............................29 101 3.4.4.10 Peak-to-peak Jitter Vector .......................30 102 4. Acknowledgments ............................................31 103 5. Security Considerations ....................................31 104 6. Normative References .......................................31 105 Network-layer Traffic Control Mechanisms 107 7. Informative References .....................................32 108 8. Author's Address ...........................................33 109 9. Full Copyright Statement ...................................34 111 1. Introduction 113 New terminology is needed because most existing measurements 114 assume the absence of congestion and only a single per-hop- 115 behavior. This document introduces several new terms that will 116 allow measurements to be taken during periods of congestion. 118 Another key difference from existing terminology is the definition 119 of measurements as observed on egress as well as ingress of a 120 device/system under test. Again, the existence of congestion 121 requires the addition of egress measurements as well as those 122 taken on ingress; without observing traffic leaving a 123 device/system it is not possible to say whether traffic-control 124 mechanisms effectively dealt with congestion. 126 The principal measurements introduced in this document are vectors 127 for rate, delay, and jitter, all of which can be observed with or 128 without congestion of the DUT/SUT. 130 This document describes only those terms relevant to measuring 131 behavior of a device or a group of devices using one of these two 132 mechanisms. End-to-end and service-level measurements are beyond 133 the scope of this document. 135 2. Existing definitions 137 RFC 1242 "Benchmarking Terminology for Network Interconnect 138 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 139 Devices" should be consulted before attempting to make use of this 140 document. 142 RFC 2474 "Definition of the Differentiated Services Field (DS 143 Field) in the IPv4 and IPv6 Headers" section 2, contains 144 discussions of a number of terms relevant to network-layer traffic 145 control mechanisms and should also be consulted. 147 For the sake of clarity and continuity this RFC adopts the 148 template for definitions set out in Section 2 of RFC 1242. 149 Definitions are indexed and grouped together in sections for ease 150 of reference. 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 153 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 RFC 2119 [Br97]. 157 Network-layer Traffic Control Mechanisms 159 3. Term definitions 161 3.1 Configuration Terms 163 3.1.1 Classification 165 Definition: 166 Selection of packets based on the contents of packet header 167 according to defined rules. 169 Discussion: 170 Packets can be selected based on the DS field or IP 171 Precedence in the packet header. Classification can also be 172 based on Multi-Field (MF) criteria such as IP Source and 173 destination addresses, protocol and port number. 175 Classification determines the per-hop behaviors and traffic 176 conditioning functions such as shaping and dropping that are 177 to be applied to the packet. 179 Measurement units: 180 n/a 182 See Also: 184 3.1.2 Codepoint Set 186 Definition: 187 The set of all DS Code-points or IP precedence values used 188 during the test duration. 190 Discussion: 191 Describes all the code-point markings associated with packets 192 that are input to the DUT/SUT. For each entry in the 193 codepoint set, there are associated vectors describing the 194 rate of traffic, delay, loss, or jitter containing that 195 particular DSCP or IP precedence value. 197 The treatment that a packet belonging to a particular code- 198 point gets is subject to the DUT classifying packets to map 199 to the correct PHB. Moreover, the forwarding treatment in 200 general is also dependent on the complete set of offered 201 vectors. 203 Measurement Units: 204 n/a 206 See Also: 208 Network-layer Traffic Control Mechanisms 210 3.1.3 Forwarding Congestion 212 Definition: 213 A condition in which one or more egress interfaces are 214 offered more packets than are forwarded. 216 Discussion: 217 This condition is a superset of the overload definition 218 [Ma98]. Overload [Ma98] deals with overloading input and 219 output interfaces beyond the maximum transmission allowed by 220 the medium. Forwarding congestion does not assume ingress 221 interface overload as the only source of overload on output 222 interfaces. 224 Another difference between Forwarding Congestion and overload 225 occurs when the SUT comprises multiple elements, in that 226 Forwarding Congestion may occur at multiple points. Consider 227 an SUT comprising multiple edge devices exchanging traffic 228 with a single core device. Depending on traffic patterns, 229 the edge devices may induce Forwarding Congestion on multiple 230 egress interfaces on the core device. 232 Packet Loss, not increased Delay, is the metric to indicate 233 the condition of Forwarding Congestion. Packet Loss is a 234 deterministic indicator of Forwarding Congestion. While 235 increased delay may be an indicator of Forwarding Congestion, 236 it is a non-deterministic indicator of Forwarding Congestion. 237 External observation of increased delay to indicate 238 congestion is in effect external observation of Incipient 239 Congestion. 241 [Ra99] implies that it is impractical to build a black-box 242 test to externally observe Incipient Congestion indicated by 243 increased delay in a router. [Ra99] introduces Explicit 244 Congestion Notification (ECN) as the externally observable, 245 deterministic method for indicating Incipient Congestion. 246 Because [Ra99] is an Experimental RFC with limited 247 deployment, ECN is not used for this particular methodology. 248 For the purpose of "black-box" testing a DUT/SUT, Packet Loss 249 as the indicator of Forwarding Congestion is used. 251 Throughput [Br91] defines the lower boundary of Forwarding 252 Congestion. Throughput is the maximum offered rate with no 253 Forwarding Congestion. At offered rates above throughput, 254 the DUT/SUT is considered to be in a state of Forwarding 255 Congestion. 257 Network-layer Traffic Control Mechanisms 259 Ingress observations alone are not sufficient to cover all 260 cases in which Forwarding Congestion may occur. A device 261 with an infinite amount of memory could buffer an infinite 262 number of packets, and eventually forward all of them. 263 However, these packets may or may not be forwarded during the 264 test duration. Even though ingress interfaces accept all 265 packets without loss, Forwarding Congestion is present in 266 this hypothetical device. 268 Forwarding Congestion, indicated by occurrence of packet 269 loss, is one type of congestion for a DUT/SUT. Congestion 270 Collapse [Na84] is defined as the state in which buffers are 271 full and all arriving packets must be dropped across the 272 network. Incipient Congestion [Ra99] is defined as 273 congestion that produces increased delay without packet loss. 275 The definition presented here explicitly defines Forwarding 276 Congestion as an event observable on egress interfaces. 277 Regardless of internal architecture, any device that cannot 278 forward packets on one or more egress interfaces is under 279 Forwarding Congestion. 281 Measurement units: 282 none 284 See Also: 285 Gateway Congestion Control Survey [Ma91] 287 3.1.4 Congestion Management 289 Definition: 290 An implementation of one or more per-hop-behaviors to avoid 291 or minimize the condition of congestion. 293 Discussion: 294 Congestion management may seek either to control congestion 295 or avoid it altogether. Such mechanisms classify packets 296 based upon IP Precedence or DSCP settings in a packet's IP 297 header. 299 Congestion avoidance mechanisms seek to prevent congestion 300 before it actually occurs. 302 Congestion control mechanisms gives one or flows (with a 303 discrete IP Precedence or DSCP value) preferential treatment 304 over other classes during periods of congestion. 306 Measurement units: 307 n/a 309 See Also: 311 Network-layer Traffic Control Mechanisms 313 3.1.5 Flow 315 Definition: 316 A flow is a one or more of packets sharing a common intended 317 pair of source and destination interfaces. 319 Discussion: 320 Packets are grouped by the ingress and egress interfaces they 321 use on a given DUT/SUT. 323 A flow can contain multiple source IP addresses and/or 324 destination IP addresses. All packets in a flow must enter 325 on the same ingress interface and exit on the same egress 326 interface, and have some common network layer content. 328 Microflows [Ni98] are a subset of flows. As defined in 329 [Ni98], microflows require application-to-application 330 measurement. In contrast, flows use lower-layer 331 classification criteria. Since this document focuses on 332 network-layer classification criteria, we concentrate here on 333 the use of network-layer identifiers in describing a flow. 334 Flow identifiers also may reside at the data-link, transport, 335 or application layers of the OSI model. However, identifiers 336 other than those at the network layer are out of scope for 337 this document. 339 A flow may contain a single code point/IP precedence value or 340 may contain multiple values destined for a single egress 341 interface. This is determined by the test methodology. 343 Measurement units: 344 n/a 346 See Also: 347 Microflow [Ni98] 348 Streams 350 3.2 Measurement Terms 352 3.2.1 Channel Capacity 354 Definition: 355 The maximum forwarding rate [Ma98] at which none of the 356 offered packets are dropped by the DUT/SUT. 358 Network-layer Traffic Control Mechanisms 360 Discussion: 361 Channel capacity measures the packet rate at the egress 362 interface(s) of the DUT/SUT. In contrast, throughput as 363 defined in RFC 1242 measures the packet rate at the ingress 364 interface(s) of the DUT/SUT. 366 Ingress-based measurements do not account for congestion of 367 the DUT/SUT. Channel capacity, as an egress measurement, 368 does take congestion into account. 370 Understanding channel capacity is a necessary precursor to 371 any measurement involving forwarding congestion. Throughput 372 numbers can be higher than channel capacity because of 373 queuing. 375 This measurement differs from forwarding rate at maximum 376 offered load (FRMOL) [Ma98] in that it is intolerant of loss. 378 Measurement units: 379 N-octet packets per second 381 See Also: 382 Throughput [Br91] 383 Forwarding Rate at Maximum Offered Load [Ma98] 385 3.2.2 Conforming Packet 387 Definition: 388 Packets which lie within specific rate, delay, or jitter 389 bounds. 391 Discussion: 392 A DUT/SUT may be configured to allow a given traffic class to 393 consume a given amount of bandwidth, or to fall within 394 predefined delay or jitter boundaries. All packets that lie 395 within specified bounds are then said to be conforming, 396 whereas those outside the bounds are nonconforming. 398 Measurement units: 399 n/a 401 See Also: 402 Expected Vector 403 Forwarding Vector 404 Offered Vector 405 Nonconforming 406 Network-layer Traffic Control Mechanisms 408 3.2.3 Nonconforming Packet 410 Definition: 411 Packets that do not lie within specific rate, delay, or 412 jitter bounds. 414 Discussion: 415 A DUT/SUT may be configured to allow a given traffic class to 416 consume a given amount of bandwidth, or to fall within 417 predefined delay or jitter boundaries. All packets that do 418 not lie within these bounds are then said to be 419 nonconforming. 421 Measurement units: 422 n/a 424 See Also: 425 Expected Vector 426 Forwarding Vector 427 Offered Vector 428 Conforming 430 3.2.4 Forwarding Delay 432 Definition: 433 The time interval starting when the last bit of the input IP 434 packet is offered to the input port of the DUT/SUT and ending 435 when the last bit of the output IP packet is received from 436 the output port of the DUT/SUT. 438 Discussion: 439 The delay time interval MUST be externally observed. The 440 delay measurement MUST NOT include delays added by test bed 441 components other than the DUT/SUT, such as propagation time 442 introduced by cabling or non-zero delay added by the test 443 instrument. 445 Forwarding Delay differs from latency [Br91] and one-way 446 delay [Al99] in several key regards: 448 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 449 uses "store and forward" or "bit forwarding" technology. 450 Forwarding Delay is the same metric, measured the same way, 451 regardless of the architecture of the DUT/SUT. 453 2. Forwarding Delay is a last-in, last-out (LILO) 454 measurement, unlike the last-in, first-out method [Br91] or 455 the first-in, last-out method [Al99]. 457 Network-layer Traffic Control Mechanisms 459 The LILO method most closely simulates the way a network- 460 layer device actually processes an IP datagram. IP datagrams 461 are not passed up and down the stack unless they are 462 complete, and processing begins only once the last bit of the 463 IP datagram has been received. 465 Further, the LILO method has an additive property, where the 466 sum of the parts MUST equal the whole. This is a key 467 difference from [Br91] and [Al99]. For example, the delay 468 added by two DUTs MUST equal the sum of the delay of the 469 DUTs. This may or may not be the case with [Br91] and 470 [Al99]. 472 3. Forwarding Delay measures the IP datagram only, unlike 473 [Br91], which also includes link layer overhead. 475 A metric focused exclusively on the Internet protocol 476 relieves the tester from specifying the start/end for every 477 link layer protocol that IP runs on. This avoids the need to 478 determine whether the start/stop delimiters are included. It 479 also allows the use of heterogeneous link layer protocols in 480 a test. 482 4. Forwarding Delay can be measured at any offered load, 483 whereas the latency methodology [Br99] recommends measurement 484 at, and only at, the throughput level. Comparing the 485 Forwarding Delay below the throughput to Forwarding Delay 486 above the channel capacity will give insight to the traffic 487 control mechanisms. 489 For example, non-congested delay may be measured with an 490 offered load that does not exceed the channel capacity, while 491 congested delay may involve an offered load that exceeds 492 channel capacity. 494 Note: Forwarding Delay SHOULD NOT be used as an absolute 495 indicator of DUT/SUT Forwarding Congestion. While Forwarding 496 Delay may rise when offered load nears or exceeds channel 497 capacity, there is no universal point at which Forwarding 498 Delay can be said to indicate the presence or absence of 499 Forwarding Congestion. 501 Measurement units: 502 Seconds. 504 See Also: 505 Latency [Br91] 506 Latency [Al99] 507 One-way Delay [Br99] 508 Network-layer Traffic Control Mechanisms 510 3.2.5 Jitter 512 Definition: 513 The absolute value of the difference between the arrival 514 delay of two consecutive received packets belonging to the 515 same stream. 517 Discussion: 518 The delay fluctuation between two consecutive received 519 packets in a stream is reported as the jitter. Jitter can be 520 expressed as |D(i) - D(i-1)| where D equals the delay and i 521 is the order the packets were received. 523 Under loss, jitter can be measured between non-consecutive 524 test sequence numbers. When Traffic Control Mechanisms are 525 losing packets, the Forwarding Delay may fluctuate as a 526 response. Jitter MUST be able to benchmark the delay 527 variation with or with out loss. 529 Jitter is related to the ipdv [De02] (IP Delay Variation) by 530 taking the absolute value of the ipdv. The two metrics will 531 produce different mean values. _Mean Jitter_ will produce a 532 positive value, where the _mean ipdv_ is typically zero. 534 Measurement units: 535 Seconds 537 See Also: 538 Forwarding Delay 539 Jitter variation [Ja99] 540 ipdv [De02] 541 interarrival jitter [Sc96] 543 3.2.6 Undifferentiated Response 545 Definition: 546 The vector(s) obtained when mechanisms used to support diff- 547 serv or IP precedence are disabled. 549 Discussion: 550 Enabling diff-serv or IP precedence mechanisms may impose 551 additional processing overhead for packets. This overhead 552 may degrade performance even when traffic belonging to only 553 one class, the best-effort class, is offered to the device. 555 Measurements with "undifferentiated response" should be made 556 to establish a baseline. 558 The vector(s) obtained with DSCP or IP precedence enabled can 559 be compared to the undifferentiated response to determine the 560 effect of differentiating traffic. 562 Network-layer Traffic Control Mechanisms 564 Measurement units: 565 n/a 567 3.3 Sequence Tracking 569 3.3.1 In-sequence Packet 571 Definition: 572 A received packet with the expected Test Sequence number. 574 Discussion: 575 In-sequence is done on a stream level. As packets are 576 received on a stream, each packet's Test Sequence number is 577 compared with the previous packet. Only packets that match 578 the expected Test Sequence number are considered in-sequence. 580 Packets that do not match the expected Test Sequence number 581 are counted as "not in-sequence" or out-of-sequence. Every 582 packet that is received is either in-sequence or out-of- 583 sequence. Subtracting the in-sequence from the received 584 packets (for that stream) can derive the out-of-sequence 585 count. 587 Two types of events will prevent the in-sequence from 588 incrementing: packet loss and reordered packets. 590 Measurement units: 591 Packet count 593 See Also: 594 Stream 595 Test Sequence number 597 3.3.2 Out-of-order Packet 599 Definition: 600 A received packet with a Test Sequence number less than 601 expected. 603 Discussion: 604 As a stream of packets enters a DUT/SUT, they include a 605 Stream Test Sequence number indicating the order the packets 606 were sent to the DUT/SUT. On exiting the DUT/SUT, these 607 packets may arrive in a different order. Each packet that 608 was re-ordered is counted as an Out-of-order Packet. 610 Network-layer Traffic Control Mechanisms 612 Certain streaming protocol (such as TCP) require the packets 613 to be in a certain order. Packets outside this are dropped 614 by the streaming protocols even though there were properly 615 received by the IP layer. The type of reordering tolerated 616 by a streaming protocol varies from protocol to protocol, and 617 also by implementation. 619 Out-of-order Packet count is based on the worst case 620 streaming protocol. It allows for no reordering. 622 Packet loss does not affect the Out-of-order Packet count. 623 Only packets that were not received in the order that they 624 were transmitted. 626 Measurement units: 627 Packet count 629 See Also: 630 Stream 631 Test Sequence number 632 Packet Reordering Metric for IPPM [Mo03] 634 3.3.3 Duplicate Packet 636 Definition: 637 A received packet with a Test Sequence number matching a 638 previously received packet. 640 Discussion: 641 A Duplicate Packet is a packet that the DUT/SUT has 642 successfully transmitted out an egress interface more than 643 once. The egress interface has previously forwarded this 644 packet. 646 A Duplicate Packet SHOULD be a bit for bit copy of an already 647 transmitted packet (including Test Sequence number). If the 648 Duplicate Packet traversed different paths through the 649 DUT/SUT, some fields (such as TTL or checksum) may have 650 changed. 652 A multicast packet is not a Duplicate Packet by definition. 653 For a given IP multicast group, a DUT/SUT SHOULD forward a 654 packet once on a given egress interface provided the path to 655 one or more multicast receivers is through that interface. 656 Several egress interfaces will transmit the same packet, but 657 only once per interface. 659 To detect a Duplicate Packet, each offered packet to the 660 DUT/SUT MUST contain a unique packet-by-packet identifier. 662 Network-layer Traffic Control Mechanisms 664 Measurement units: 665 Packet count 667 See Also: 668 Stream 669 Test Sequence number 671 3.3.4 Stream 673 Definition: 674 A group of packets tracked as a single entity by the traffic 675 receiver. A stream may share a common content such as type 676 (IP, UDP), packet size, or payload. 678 Discussion: 679 Streams are tracked by test sequence number or "unique 680 signature field" [Ma00]. Streams define how individual 681 packets' statistic are grouped together to form an 682 intelligible summary. 684 Common stream groupings would be by egress interface, 685 destination address, source address, DSCP, or IP precedence. 686 A stream using test sequence numbers can track the ordering 687 of packets as they transverse the DUT/SUT. 689 Streams are not restricted to a pair of source and 690 destination interfaces as long as all packets are tracked as 691 a single entity. A mulitcast stream can be forward to 692 multiple destination interfaces. 694 Measurement units: 695 n/a 697 See Also: 698 Flow 699 Microflow [Ni98] 700 Test sequence number 702 3.3.5 Test Sequence number 704 Definition: 705 A field in the IP payload portion of the packet that is used 706 to verify the order of the packets on the egress of the 707 DUT/SUT. 709 Network-layer Traffic Control Mechanisms 711 Discussion: 712 The traffic generator sets the test sequence number value and 713 the traffic receiver checks the value upon receipt of the 714 packet. The traffic generator changes the value on each 715 packet transmitted based on an algorithm agreed to by the 716 traffic receiver. 718 The traffic receiver keeps track of the sequence numbers on a 719 per stream basis. In addition to number of received packets, 720 the traffic receiver may also report number of in-sequence 721 packets, number of out-sequence packets, number of duplicate 722 packets, and number of reordered packets. 724 The recommended algorithm to use to change the sequence 725 number on sequential packets is an incrementing value. 727 Measurement units: 728 n/a 730 See Also: 731 Stream 733 3.4 Vectors 734 A vector is a group of packets all containing a specific DSCP 735 or IP precedence value. Vectors are expressed as a pair of 736 numbers. The first is being the particular diff-serv value. 737 The second is the metric expressed as a rate, loss 738 percentage, delay, or jitter. 740 3.4.1 Intended Vector 742 Definition: 743 A vector describing the attempted rate at which packets 744 having a specific code-point (or IP precedence) are 745 transmitted to a DUT/SUT by an external source. 747 Discussion: 748 Intended loads across the different code-point classes 749 determine the metrics associated with a specific code-point 750 traffic class. 752 Measurement Units: 753 N-octets packets per second 754 Network-layer Traffic Control Mechanisms 756 See Also: 757 Offered Vector 758 Expected Forwarding Vector 759 Expected Loss Vector 760 Expected Sequence Vector 761 Expected Delay Vector 762 Expected Jitter Vector 763 Forwarding Vector 764 Loss Vector 766 3.4.2 Offered Vector 768 Definition: 769 A vector describing the measured rate at which packets having 770 a specific DSCP or IP precedence value are offered to the 771 DUT/SUT. 773 Discussion: 774 Offered loads across the different code-point classes, 775 constituting a code-point set, determine the metrics 776 associated with a specific code-point traffic class. 778 Measurement Units: 779 N-octets packets per second 781 See Also: 782 Expected Forwarding Vector 783 Expected Loss Vector 784 Expected Sequence Vector 785 Expected Delay Vector 786 Expected Jitter Vector 787 Forwarding Vector 788 Codepoint Set 790 3.4.3 Expected Vectors 792 3.4.3.1 Expected Forwarding Vector 794 Definition: 795 A vector describing the expected output rate of packets 796 having a specific DSCP or IP precedence value. The value is 797 dependent on the set of offered vectors and configuration of 798 the DUT. 800 Network-layer Traffic Control Mechanisms 802 Discussion: 803 The DUT is configured in a certain way in order that service 804 differentiation occurs for a particular DSCP or IP precedence 805 value when a specific traffic mix consisting of multiple 806 DSCPs or IP precedence values are applied. This term 807 attempts to capture the expected forwarding behavior when 808 subjected to a certain offered vectors. 810 The actual algorithm or mechanism the DUT uses to achieve 811 service differentiation is not important in describing the 812 expected forwarding vector. 814 Measurement units: 815 N-octet packets per second 817 See Also: 818 Intended Vector 819 Offered Vector 820 Output Vectors 821 Expected Loss Vector 822 Expected Sequence Vector 823 Expected Delay Vector 824 Expected Jitter Vector 826 3.4.3.2 Expected Loss Vector 828 Definition: 829 A vector describing the percentage of packets, having a 830 specific DSCP or IP precedence value, that should not be 831 forwarded. The value is dependent on the set of offered 832 vectors and configuration of the DUT. 834 Discussion: 835 The DUT is configured in a certain way in order that service 836 differentiation occurs for a particular DSCP or IP precedence 837 value when a specific traffic mix consisting of multiple 838 DSCPs or IP precedence values are applied. This term 839 attempts to capture the expected forwarding behavior when 840 subjected to a certain offered vector. 842 The actual algorithm or mechanism the DUT uses to achieve 843 service differentiation is not important in describing the 844 expected loss vector. 846 Measurement Units: 847 Percentage of intended packets that is expected to be 848 dropped. 850 Network-layer Traffic Control Mechanisms 852 See Also: 853 Intended Vector 854 Offered Vector 855 Expected Forwarding Vector 856 Expected Sequence Vector 857 Expected Delay Vector 858 Expected Jitter Vector 859 One-way Packet Loss Metric [Ka99] 861 3.4.3.3 Expected Sequence Vector 863 Definition: 864 A vector describing the expected in-sequence packets having a 865 specific DSCP or IP precedence value. The value is dependent 866 on the set of offered vectors and configuration of the DUT. 868 Discussion: 869 The DUT is configured in a certain way in order that service 870 differentiation occurs for a particular DSCP or IP precedence 871 value when a specific traffic mix consisting of multiple 872 DSCPs or IP precedence values are applied. This term 873 attempts to capture the expected forwarding behavior when 874 subjected to a certain offered vectors. 876 The actual algorithm or mechanism the DUT uses to achieve 877 service differentiation is not important in describing the 878 expected sequence vector. 880 Measurement Units: 881 N-octet packets per second 883 See Also: 884 Intended Vector 885 Offered Vector 886 Output Vectors 887 Expected Loss Vector 888 Expected Forwarding Vector 889 Expected Delay Vector 890 Expected Jitter Vector 892 3.4.3.4 Expected Instantaneous Delay Vector 894 Definition: 895 A vector describing the expected delay for packets having a 896 specific DSCP or IP precedence value. The value is dependent 897 on the set of offered vectors and configuration of the DUT. 899 Network-layer Traffic Control Mechanisms 901 Discussion: 902 The DUT is configured in a certain way in order that service 903 differentiation occurs for a particular DSCP or IP precedence 904 value when a specific traffic mix consisting of multiple 905 DSCPs or IP precedence values are applied. This term 906 attempts to capture the expected forwarding behavior when 907 subjected to a certain offered vectors. 909 The actual algorithm or mechanism the DUT uses to achieve 910 service differentiation is not important in describing the 911 expected delay vector. 913 Measurement units: 914 Seconds. 916 See Also: 917 Forwarding Delay 918 Intended Vector 919 Offered Vector 920 Output Vectors 921 Expected Loss Vector 922 Expected Sequence Vector 923 Expected Forwarding Vector 924 Expected Jitter Vector 926 3.4.3.5 Expected Average Delay Vector 928 Definition: 929 A vector describing the expected average delay for packets 930 having a specific DSCP or IP precedence value. The value is 931 dependent on the set of offered vectors and configuration of 932 the DUT. 934 Discussion: 935 The DUT is configured in a certain way in order that service 936 differentiation occurs for a particular DSCP or IP precedence 937 value when a specific traffic mix consisting of multiple 938 DSCPs or IP precedence values are applied. This term 939 attempts to capture the expected forwarding behavior when 940 subjected to a certain offered vectors. 942 The actual algorithm or mechanism the DUT uses to achieve 943 service differentiation is not important in describing the 944 expected average delay vector. 946 Measurement units: 947 Seconds. 949 Network-layer Traffic Control Mechanisms 951 See Also: 952 Intended Vector 953 Offered Vector 954 Output Vectors 955 Expected Loss Vector 956 Expected Sequence Vector 957 Expected Forwarding Vector 958 Expected Jitter Vector 960 3.4.3.6 Expected Maximum Delay Vector 962 Definition: 963 A vector describing the expected maximum delay for packets 964 having a specific DSCP or IP precedence value. The value is 965 dependent on the set of offered vectors and configuration of 966 the DUT. 968 Discussion: 969 The DUT is configured in a certain way in order that service 970 differentiation occurs for a particular DSCP or IP precedence 971 value when a specific traffic mix consisting of multiple 972 DSCPs or IP precedence values are applied. This term 973 attempts to capture the expected forwarding behavior when 974 subjected to a certain offered vectors. 976 The actual algorithm or mechanism the DUT uses to achieve 977 service differentiation is not important in describing the 978 expected maximum delay vector. 980 Measurement units: 981 Seconds. 983 See Also: 984 Intended Vector 985 Offered Vector 986 Output Vectors 987 Expected Loss Vector 988 Expected Sequence Vector 989 Expected Forwarding Vector 990 Expected Jitter Vector 992 3.4.3.7 Expected Minimum Delay Vector 994 Definition: 995 A vector describing the expected minimum delay for packets 996 having a specific DSCP or IP precedence value. The value is 997 dependent on the set of offered vectors and configuration of 998 the DUT. 1000 Network-layer Traffic Control Mechanisms 1002 Discussion: 1003 The DUT is configured in a certain way in order that service 1004 differentiation occurs for a particular DSCP or IP precedence 1005 value when a specific traffic mix consisting of multiple 1006 DSCPs or IP precedence values are applied. This term 1007 attempts to capture the expected forwarding behavior when 1008 subjected to a certain offered vectors. 1010 The actual algorithm or mechanism the DUT uses to achieve 1011 service differentiation is not important in describing the 1012 expected minimum delay vector. 1014 Measurement units: 1015 Seconds. 1017 See Also: 1018 Intended Vector 1019 Offered Vector 1020 Output Vectors 1021 Expected Loss Vector 1022 Expected Sequence Vector 1023 Expected Forwarding Vector 1024 Expected Jitter Vector 1026 3.4.3.8 Expected Instantaneous Jitter Vector 1028 Definition: 1029 A vector describing the expected jitter between two 1030 consecutive packets' arrival times having a specific DSCP or 1031 IP precedence value. The value is dependent on the set of 1032 offered vectors and configuration of the DUT. 1034 Discussion: 1035 Instantaneous Jitter is the absolute value of the difference 1036 between the delay measurement of two packets belonging to the 1037 same stream. 1039 The delay fluctuation between two consecutive packets in a 1040 stream is reported as the "Instantaneous Jitter". 1041 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 1042 where D equals the delay and i is the test sequence number. 1043 Packets lost are not counted in the measurement. 1045 Forwarding Vector may contain several Jitter Vectors. For n 1046 packets received in a Forwarding Vector, there is a total of 1047 (n-1) Instantaneous Jitter Vectors. 1049 Measurement units: 1050 Seconds 1051 Network-layer Traffic Control Mechanisms 1053 See Also: 1054 Delay 1055 Jitter 1056 Offered Vector 1057 Output Vectors 1058 Expected Average Jitter Vector 1059 Expected Peak-to-peak Jitter Vector 1060 Stream 1062 3.4.3.9 Expected Average Jitter Vector 1064 Definition: 1065 A vector describing the expected jitter in packet arrival 1066 times for packets having a specific DSCP or IP precedence 1067 value. The value is dependent on the set of offered vectors 1068 and configuration of the DUT. 1070 Discussion: 1071 Average Jitter Vector is the average of all the Instantaneous 1072 Jitter Vectors measured during the test duration for the same 1073 DSCP or IP precedence value. 1075 Measurement units: 1076 Seconds 1078 See Also: 1079 Intended Vector 1080 Offered Vector 1081 Output Vectors 1082 Expected Instantaneous Jitter Vector 1083 Expected Peak-to-peak Jitter Vector 1085 3.4.3.10 Expected Peak-to-peak Jitter Vector 1087 Definition: 1088 A vector describing the expected maximum variation in the 1089 delay of packet arrival times for packets having a specific 1090 DSCP or IP precedence value. The value is dependent on the 1091 set of offered vectors and configuration of the DUT. 1093 Discussion: 1094 Peak-to-peak Jitter Vector is the maximum delay minus the 1095 minimum delay of the packets (in a vector) forwarded by the 1096 DUT/SUT. 1098 Peak-to-peak Jitter is not derived from the Instantaneous 1099 Jitter Vector. Peak-to-peak Jitter is based upon all the 1100 packets during the test duration, not just two consecutive 1101 packets. 1103 Network-layer Traffic Control Mechanisms 1105 Measurement units: 1106 Seconds 1108 See Also: 1109 Intended Vector 1110 Offered Vector 1111 Output Vectors 1112 Expected Instantaneous Jitter Vector 1113 Expected Average Jitter Vector 1115 3.4.4 Output Vectors 1117 3.4.4.1 Forwarding Vector 1119 Definition: 1120 The number of packets per second for all packets containing a 1121 specific DSCP or IP precedence value that a device can be 1122 observed to successfully forward to the correct destination 1123 interface in response to an offered vector. 1125 Discussion: 1126 Forwarding Vector is expressed as pair of numbers. Both the 1127 specific DSCP (or IP precedence) value AND the packets per 1128 second value combine to make a vector. 1130 The Forwarding Vector represents packet rate based on its 1131 specific DSCP (or IP precedence) value. It is not 1132 necessarily based on a stream or flow. The Forwarding Vector 1133 may be expressed as per port of the DUT/SUT. However, it 1134 must be consistent with the Expected Forwarding Vector. 1136 Forwarding Vector is a per-hop measurement. The DUT/SUT may 1137 change the specific DSCP (or IP precedence) value for a 1138 multiple-hop measurement. 1140 Measurement units: 1141 N-octet packets per second 1143 See Also: 1144 Intended Vector 1145 Offered Vector 1146 Expected Vectors 1147 Loss Vector 1148 Sequence Vector 1149 Delay Vectors 1150 Network-layer Traffic Control Mechanisms 1152 3.4.4.2 Loss Vector 1154 Definition: 1155 The percentage of packets containing a specific DSCP or IP 1156 precedence value that a DUT/SUT did not transmit to the 1157 correct destination interface in response to an offered 1158 vector. 1160 Discussion: 1161 Loss Vector is expressed as pair of numbers. Both the 1162 specific DSCP (or IP precedence) value AND the percentage 1163 value combine to make a vector. 1165 The Loss Vector represents percentage based on a specific 1166 DSCP or IP precedence value. It is not necessarily based on 1167 a stream or flow. The Loss Vector may be expressed as per 1168 port of the DUT/SUT. However, it must be consistent with the 1169 Expected Loss Vector 1171 Loss Vector is a per-hop measurement. The DUT/SUT may change 1172 the specific DSCP or IP precedence value for a multiple-hop 1173 measurement. 1175 Measurement Units: 1176 Percentage of offered packets that is not forwarded. 1178 See Also: 1179 Intended Vector 1180 Offered Vector 1181 Expected Vectors 1182 Forwarding Vector 1183 Sequence Vector 1184 Delay Vectors 1185 One-way Packet Loss Metric [Ka99] 1187 3.4.4.3 Sequence Vector 1189 Definition: 1190 The number of packets per second for all packets containing a 1191 specific DSCP or IP precedence value that a device can be 1192 observed to transmit in sequence to the correct destination 1193 interface in response to an offered vector. 1195 Discussion: 1196 Sequence Vector is expressed as pair of numbers. Both the 1197 specific DSCP (or IP precedence) value AND the packets per 1198 second value combine to make a vector. 1200 Network-layer Traffic Control Mechanisms 1202 The Sequence Vector represents packet rate based on its 1203 specific DSCP or IP precedence value. It is not necessarily 1204 based on a stream or flow. The Sequence Vector may be 1205 expressed as per port of the DUT/SUT. However, it must be 1206 consistent with the Expected Sequence Vector. 1208 Sequence Vector is a per-hop measurement. The DUT/SUT may 1209 change the specific DSCP or IP precedence value for a 1210 multiple-hop measurement. 1212 Measurement Units: 1213 N-octet packets per second 1215 Issues: 1217 See Also: 1218 In-sequence Packet 1219 Intended Vector 1220 Offered Vector 1221 Expected Vectors 1222 Loss Vector 1223 Forwarding Vector 1224 Delay Vectors 1226 3.4.4.4 Instantaneous Delay Vector 1228 Definition: 1229 The delay for a packet containing a specific DSCP or IP 1230 precedence value that a device can be observed to 1231 successfully transmit to the correct destination interface in 1232 response to an offered vector. 1234 Discussion: 1235 Instantaneous Delay vector is expressed as pair of numbers. 1236 Both the specific DSCP (or IP precedence) value AND delay 1237 value combine to make a vector. 1239 The Instantaneous Delay Vector represents delay on its 1240 specific DSCP or IP precedence value. It is not necessarily 1241 based on a stream or flow. The Delay vector may be expressed 1242 as per port of the DUT/SUT. However, it must be consistent 1243 with the Expected Delay vectors. 1245 Instantaneous Delay Vector is a per-hop measurement. The 1246 DUT/SUT may change the specific DSCP or IP precedence value 1247 for a multiple-hop measurement. 1249 Instantaneous Delay vector can be obtained at any offered 1250 load. RECOMMEND at or below the channel capacity in the 1251 absence of forwarding congestion. For congested delay, run 1252 the offered load above the channel capacity. 1254 Network-layer Traffic Control Mechanisms 1256 Forwarding Vector may contain several Instantaneous Delay 1257 Vectors. For every packet received in a Forwarding Vector, 1258 there is a corresponding Instantaneous Delay Vector. 1260 Measurement Units: 1261 Seconds 1263 See Also: 1264 Delay 1265 Intended Vector 1266 Offered Vector 1267 Expected Delay Vectors 1268 Average Delay Vector 1269 Maximum Delay Vector 1270 Minimum Delay Vector 1272 3.4.4.5 Average Delay Vector 1274 Definition: 1275 The average delay for packets containing a specific DSCP or 1276 IP precedence value that a device can be observed to 1277 successfully transmit to the correct destination interface in 1278 response to an offered vector. 1280 Discussion: 1281 Average Delay vector is expressed as pair of numbers. Both 1282 the specific DSCP (or IP precedence) value AND delay value 1283 combine to make a vector. 1285 The Delay Vector represents delay on its specific DSCP or IP 1286 precedence value. It is not necessarily based on a stream or 1287 flow. The Delay vector may be expressed as per port of the 1288 DUT/SUT. However, it MUST be consistent with the Expected 1289 Delay vector. 1291 The Average Delay Vector is computed by averaging all the 1292 Instantaneous Delay Vectors for a given vector. 1294 Average Delay Vector is a per-hop measurement. The DUT/SUT 1295 may change the specific DSCP or IP precedence value for a 1296 multiple-hop measurement. 1298 Average Delay vector can be obtained at any offered load. 1299 Recommend at or below the channel capacity in the absence of 1300 congestion. For congested delay, run the offered load above 1301 the channel capacity. 1303 Measurement Units: 1304 Seconds 1305 Network-layer Traffic Control Mechanisms 1307 See Also: 1308 Delay 1309 Intended Vector 1310 Offered Vector 1311 Expected Delay Vectors 1312 Instantaneous Delay Vector 1313 Maximum Delay Vector 1314 Minimum Delay Vector 1316 3.4.4.6 Maximum Delay Vector 1318 Definition: 1319 The maximum delay from all packets containing a specific DSCP 1320 or IP precedence value that a device can be observed to 1321 successfully transmit to the correct destination interface in 1322 response to an offered vector. 1324 Discussion: 1325 Maximum Delay vector is expressed as pair of numbers. Both 1326 the specific DSCP (or IP precedence) value AND delay value 1327 combine to make a vector. 1329 The Maximum Delay Vector represents delay on its specific 1330 DSCP or IP precedence value. It is not necessarily based on 1331 a stream or flow. The Maximum Delay vector may be expressed 1332 as per port of the DUT/SUT. However, it must be consistent 1333 with the Expected Delay vector. 1335 Maximum Delay Vector is based upon the maximum Instantaneous 1336 Delay Vector of all packets in a Forwarding Vector. 1338 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1339 may change the specific DSCP or IP precedence value for a 1340 multiple-hop measurement. 1342 Measurement Units: 1343 Seconds 1345 See Also: 1346 Delay 1347 Intended Vector 1348 Offered Vector 1349 Expected Delay Vectors 1350 Instantaneous Delay Vector 1351 Forwarding Vector 1352 Average Delay Vector 1353 Minimum Delay Vector 1354 Network-layer Traffic Control Mechanisms 1356 3.4.4.7 Minimum Delay Vector 1358 Definition: 1359 The minimum delay from all packets containing a specific DSCP 1360 or IP precedence value that a device can be observed to 1361 successfully transmit to the correct destination interface in 1362 response to an offered vector. 1364 Discussion: 1365 Delay vector is expressed as pair of numbers. Both the 1366 specific DSCP (or IP precedence) value AND delay value 1367 combine to make a vector. 1369 The Minimum Delay Vector represents delay on its specific 1370 DSCP or IP precedence value. It is not necessarily based on 1371 a stream or flow. The Minimum Delay vector may be expressed 1372 as per port of the DUT/SUT. However, it must be consistent 1373 with the Expected Delay vector. 1375 Minimum Delay Vector is based upon the minimum Instantaneous 1376 Delay Vector of all packets in a Forwarding Vector. 1378 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1379 may change the specific DSCP or IP precedence value for a 1380 multiple-hop measurement. 1382 Minimum Delay vector can be obtained at any offered load. 1383 Recommend at or below the channel capacity in the absence of 1384 congestion. For congested delay, run the offered load above 1385 the channel capacity. 1387 Measurement Units: 1388 Seconds 1390 See Also: 1391 Delay 1392 Intended Vector 1393 Offered Vector 1394 Expected Delay Vectors 1395 Instantaneous Delay Vector 1396 Forwarding Vector 1397 Average Delay Vector 1398 Maximum Delay Vector 1400 3.4.4.8 Instantaneous Jitter Vector 1402 Definition: 1403 The jitter for two consecutive packets containing a specific 1404 DSCP or IP precedence value that a device can be observed to 1405 successfully transmit to the correct destination interface in 1406 response to an offered vector. 1408 Network-layer Traffic Control Mechanisms 1410 Discussion: 1411 Instantaneous Jitter is the absolute value of the difference 1412 between the delay measurement of two packets belonging to the 1413 same stream. 1415 Jitter vector is expressed as pair of numbers. Both the 1416 specific DSCP (or IP precedence) value AND jitter value 1417 combine to make a vector. 1419 The delay fluctuation between two consecutive packets in a 1420 stream is reported as the "Instantaneous Jitter". 1421 Instantaneous Jitter Vector can be expressed as |D(i) - D(i- 1422 1)| where D equals the delay and i is the test sequence 1423 number. Packets lost are not counted in the measurement. 1425 Instantaneous Jitter Vector is a per-hop measurement. The 1426 DUT/SUT may change the specific DSCP or IP precedence value 1427 for a multiple-hop measurement. 1429 Forwarding Vector may contain several Instantaneous Jitter 1430 Vectors. For n packets received in a Forwarding Vector, 1431 there are exactly (n-1) Instantaneous Jitter Vectors. 1433 Measurement units: 1434 Seconds 1436 See Also: 1437 Delay 1438 Jitter 1439 Forwarding Vector 1440 Stream 1441 Expected Vectors 1442 Average Jitter Vector 1443 Peak-to-peak Jitter Vector 1445 3.4.4.9 Average Jitter Vector 1447 Definition: 1448 The average jitter for packets containing a specific DSCP or 1449 IP precedence value that a device can be observed to 1450 successfully transmit to the correct destination interface in 1451 response to an offered vector. 1453 Discussion: 1454 Average Jitter Vector is the average of all the Instantaneous 1455 Jitter Vectors of the same DSCP or IP precedence value, 1456 measured during the test duration. 1458 Network-layer Traffic Control Mechanisms 1460 Average Jitter vector is expressed as pair of numbers. Both 1461 the specific DSCP (or IP precedence) value AND jitter value 1462 combine to make a vector. 1464 Average Jitter vector is a per-hop measurement. The DUT/SUT 1465 may change the specific DSCP or IP precedence value for a 1466 multiple-hop measurement. 1468 Measurement units: 1469 Seconds 1471 See Also: 1472 Jitter 1473 Forwarding Vector 1474 Stream 1475 Expected Vectors 1476 Instantaneous Jitter Vector 1477 Peak-to-peak Jitter Vector 1479 3.4.4.10 Peak-to-peak Jitter Vector 1481 Definition: 1482 The maximum possible variation in the delay for packets 1483 containing a specific DSCP or IP precedence value that a 1484 device can be observed to successfully transmit to the 1485 correct destination interface in response to an offered 1486 vector. 1488 Discussion: 1489 Peak-to-peak Jitter Vector is the maximum delay minus the 1490 minimum delay of the packets (in a vector) forwarded by the 1491 DUT/SUT. 1493 Jitter vector is expressed as pair of numbers. Both the 1494 specific DSCP (or IP precedence) value AND jitter value 1495 combine to make a vector. 1497 Peak-to-peak Jitter is not derived from the Instantaneous 1498 Jitter Vector. Peak-to-peak Jitter is based upon all the 1499 packets during the test duration, not just two consecutive 1500 packets. 1502 Measurement units: 1503 Seconds 1505 See Also: 1506 Jitter 1507 Forwarding Vector 1508 Stream 1509 Expected Vectors 1510 Average Jitter Vector 1511 Peak-to-peak Jitter Vector 1512 Network-layer Traffic Control Mechanisms 1514 4. Acknowledgments 1516 The editors gratefully acknowledge the contributions of the 1517 IETF's benchmarking working group members in reviewing this 1518 document. The following individuals also made noteworthy 1519 contributions to the editors' understanding of the subject 1520 matter: John Dawson, Kevin Dubray, and Kathleen Nichols. 1522 5. Security Considerations 1524 Documents of this type do not directly affect the security of 1525 the Internet or of corporate networks as long as benchmarking 1526 is not performed on devices or systems connected to 1527 production networks. 1529 Packets with unintended and/or unauthorized DSCP or IP 1530 precedence values may present security issues. Determining 1531 the security consequences of such packets is out of scope for 1532 this document. 1534 6. Normative References 1536 [Br91] Bradner, S., "Benchmarking Terminology for Network 1537 Interconnection Devices", RFC 1242, July 1991. 1539 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 1540 Requirement Levels", RFC 2119, March 1997 1542 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1543 Switching Devices", RFC 2285, February 1998. 1545 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1546 of the Differentiated Services Field (DS Field) in the 1547 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1549 Network-layer Traffic Control Mechanisms 1551 7. Informative References 1553 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 1554 Metric for IPPM", RFC 2679, September 1999 1556 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1557 Weiss, W., "An Architecture for Differentiated Services", 1558 RFC 2475, December 1998. 1560 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 1561 Network Interconnect Devices", RFC 2544, March 1999 1563 [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 1564 Metric for IPPM", RFC 3393, November 2002 1566 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 1567 Forwarding PHB", RFC 2598, June 1999 1569 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1570 Packet Loss Metric for IPPM", RFC 2680, September 1999 1572 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 1573 Survey", RFC 1254, August 1991 1575 [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 1576 LAN Switching Devices", RFC 2889, August 2000 1578 [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1579 S., Perser, J., "Packet Reordering Metric for IPPM", 1580 Work in Progress 1582 [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1583 RFC 896, January 1984. 1585 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1586 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1587 January 1999. 1589 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1590 "RTP: A Transport Protocol for Real-Time Applications", 1591 RFC 1889, January 1996 1592 Network-layer Traffic Control Mechanisms 1594 8. Authors' Addresses 1596 Jerry Perser 1597 Spirent Communications 1598 26750 Agoura Road 1599 Calabasas, CA 91302 1600 USA 1602 Phone: + 1 818 676 2300 1603 EMail: jerry.perser@spirentcom.com 1605 David Newman 1606 Network Test 1607 31324 Via Colinas, Suite 113 1608 Westlake Village, CA 91362 1609 USA 1611 Phone: + 1 818 889 0011, x10 1612 EMail: dnewman@networktest.com 1614 Sumit Khurana 1615 Telcordia Technologies 1616 445 South Street 1617 Morristown, NJ 07960 1618 USA 1620 Phone: + 1 973 829 3170 1621 EMail: sumit@research.telcordia.com 1623 Shobha Erramilli 1624 QNetworx Inc 1625 1119 Campus Drive West 1626 Morganville, NJ 07751 1627 USA 1629 Phone: 1630 EMail: shobha@qnetworx.com 1632 Scott Poretsky 1633 Avici Systems 1634 101 Billerica Ave_Building #6 1635 N. Billerica, MA 01862 1636 USA 1638 Phone: + 1 978 964 2287 1639 EMail: sporetsky@avici.com 1640 Network-layer Traffic Control Mechanisms 1642 9. Full Copyright Statement 1644 Copyright (C) The Internet Society (2003). All Rights 1645 Reserved. 1647 This document and translations of it may be copied and 1648 furnished to others, and derivative works that comment on or 1649 otherwise explain it or assist in its implementation may be 1650 prepared, copied, published and distributed, in whole or in 1651 part, without restriction of any kind, provided that the 1652 above copyright notice and this paragraph are included on all 1653 such copies and derivative works. However, this document 1654 itself may not be modified in any way, such as by removing 1655 the copyright notice or references to the Internet Society or 1656 other Internet organizations, except as needed for the 1657 purpose of developing Internet standards in which case the 1658 procedures for copyrights defined in the Internet Standards 1659 process must be followed, or as required to translate it into 1660 languages other than English. 1662 The limited permissions granted above are perpetual and will 1663 not be revoked by the Internet Society or its successors or 1664 assigns. This document and the information contained herein 1665 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1666 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1667 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1668 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1669 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1670 FITNESS FOR A PARTICULAR PURPOSE.