idnits 2.17.1 draft-ietf-bmwg-dsmterm-06.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 Abstract section. ** 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 (April 2003) is 7654 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 1523, 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: 6 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: November 2003 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 QNetworx 10 Scott Poretsky 11 Avici Systems 12 April 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 Table of Contents 43 1. Introduction .............................................. 3 44 2. Existing definitions ...................................... 3 45 3. Term definitions ............................................4 46 3.1 Configuration Terms 47 3.1.1 Classification .........................................4 48 3.1.2 Codepoint Set ..........................................4 49 3.1.3 Forwarding Congestion ..................................5 50 3.1.4 Congestion Management ..................................6 51 3.1.5 Flow ...................................................6 52 3.2 Measurement Terms 53 Network-layer Traffic Control Mechanisms 55 3.2.1 Channel Capacity .......................................7 56 3.2.2 Conforming .............................................8 57 3.2.3 Nonconforming ..........................................8 58 3.2.4 Forwarding Delay .......................................9 59 3.2.5 Jitter ................................................10 60 3.2.6 Undifferentiated Response .............................11 61 3.3 Sequence Tracking 62 3.3.1 In-sequence Packet ....................................11 63 3.3.2 Out-of-order Packet ...................................12 64 3.3.3 Duplicate Packet ......................................13 65 3.3.4 Stream ................................................13 66 3.3.5 Test Sequence number .................................14 67 3.4 Vectors ...................................................14 68 3.4.1 Intended Vector .......................................14 69 3.4.2 Offered Vector ........................................15 70 3.4.3 Expected Vectors 71 3.4.3.1 Expected Forwarding Vector ........................15 72 3.4.3.2 Expected Loss Vector ..............................16 73 3.4.3.3 Expected Sequence Vector ..........................17 74 3.4.3.4 Expected Instantaneous Delay Vector ...............17 75 3.4.3.5 Expected Average Delay Vector .....................18 76 3.4.3.6 Expected Maximum Delay Vector .....................19 77 3.4.3.7 Expected Minimum Delay Vector .....................19 78 3.4.3.8 Expected Instantaneous Jitter Vector ..............20 79 3.4.3.9 Expected Average Jitter Vector ....................21 80 3.4.3.10 Expected Peak-to-peak Jitter Vector ..............21 81 3.4.4 Output Vectors 82 3.4.4.1 Forwarding Vector .................................22 83 3.4.4.2 Loss Vector .......................................23 84 3.4.4.3 Sequence Vector ...................................23 85 3.4.4.4 Instantaneous Delay Vector ........................24 86 3.4.4.5 Average Delay Vector ..............................25 87 3.4.4.6 Maximum Delay Vector ..............................26 88 3.4.4.7 Minimum Delay Vector ..............................27 89 3.4.4.8 Instantaneous Jitter Vector .......................27 90 3.4.4.9 Average Jitter Vector .............................28 91 3.4.4.10 Peak-to-peak Jitter Vector .......................29 92 4. Security Considerations ....................................30 93 5. Acknowledgments ............................................30 94 6. Normative References .......................................30 95 7. Informative References .....................................31 96 8. Author's Address ...........................................32 97 9. Full Copyright Statement ...................................33 98 Network-layer Traffic Control Mechanisms 100 1. Introduction 102 This document describes terminology for the benchmarking of 103 devices that implement traffic control based on IP precedence or 104 diff-serv code point criteria. 106 New terminology is needed because most existing measurements 107 assume the absence of congestion and only a single per-hop- 108 behavior. This document introduces several new terms that will 109 allow measurements to be taken during periods of congestion. 111 Another key difference from existing terminology is the definition 112 of measurements as observed on egress as well as ingress of a 113 device/system under test. Again, the existence of congestion 114 requires the addition of egress measurements as well as those 115 taken on ingress; without observing traffic leaving a 116 device/system it is not possible to say whether traffic-control 117 mechanisms effectively dealt with congestion. 119 The principal measurements introduced in this document are vectors 120 for rate, delay, and jitter, all of which can be observed with or 121 without congestion of the DUT/SUT. 123 This document describes only those terms relevant to measuring 124 behavior of a device or a group of devices using one of these two 125 mechanisms. End-to-end and service-level measurements are beyond 126 the scope of this document. 128 2. Existing definitions 130 RFC 1242 "Benchmarking Terminology for Network Interconnect 131 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 132 Devices" should be consulted before attempting to make use of this 133 document. 135 RFC 2474 "Definition of the Differentiated Services Field (DS 136 Field) in the IPv4 and IPv6 Headers" section 2, contains 137 discussions of a number of terms relevant to network-layer traffic 138 control mechanisms and should also be consulted. 140 For the sake of clarity and continuity this RFC adopts the 141 template for definitions set out in Section 2 of RFC 1242. 142 Definitions are indexed and grouped together in sections for ease 143 of reference. 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 146 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 RFC 2119. 150 Network-layer Traffic Control Mechanisms 152 3. Term definitions 154 3.1 Configuration Terms 156 3.1.1 Classification 158 Definition: 159 Selection of packets based on the contents of packet header 160 according to defined rules. 162 Discussion: 163 Packets can be selected based on the DS field or IP 164 Precedence in the packet header. Classification can also be 165 based on Multi-Field (MF) criteria such as IP Source and 166 destination addresses, protocol and port number. 168 Classification determines the per-hop behaviors and traffic 169 conditioning functions such as shaping and dropping that are 170 to be applied to the packet. 172 Measurement units: 173 n/a 175 See Also: 177 3.1.2 Codepoint Set 179 Definition: 180 The set of all DS Code-points or IP precedence values used 181 during the test duration. 183 Discussion: 184 Describes all the code-point markings associated with packets 185 that are input to the DUT/SUT. For each entry in the 186 codepoint set, there are associated vectors describing the 187 rate of traffic, delay, loss, or jitter containing that 188 particular DSCP or IP precedence value. 190 The treatment that a packet belonging to a particular code- 191 point gets is subject to the DUT classifying packets to map 192 to the correct PHB. Moreover, the forwarding treatment in 193 general is also dependent on the complete set of offered 194 vectors. 196 Measurement Units: 197 n/a 199 See Also: 201 Network-layer Traffic Control Mechanisms 203 3.1.3 Forwarding Congestion 205 Definition: 206 A condition in which one or more egress interfaces are 207 offered more packets than are forwarded. 209 Discussion: 211 This condition is a superset of the overload definition 212 [Ma98]. The overload discussion deals with how many input 213 interfaces are required to overload the output interfaces. 214 Forwarding congestion does not assume ingress interface 215 overload as the only source of overload on output interfaces. 217 Another difference between Forwarding Congestion and overload 218 occurs when the SUT comprises multiple elements, in that 219 Forwarding Congestion may occur at multiple points. Consider 220 an SUT comprising multiple edge devices exchanging traffic 221 with a single core device. Depending on traffic patterns, the 222 edge devices may induce Forwarding Congestion on multiple 223 egress interfaces on the core device. 225 Packet Loss, not increased Delay, is the metric to indicate 226 the condition of Forwarding Congestion. Packet Loss is a 227 deterministic indicator of Forwarding Congestion. While 228 increased delay may be an indicator of Forwarding Congestion, 229 it is a non-deterministic indicator of Forwarding Congestion. 230 External observation of increased delay to indicate 231 congestion is in effect external observation of Incipient 232 Congestion. [Ra99] states that it is impractical to build a 233 black-box test to externally observe Incipient Congestion in 234 a router. For the purpose of "black-box" testing a DUT/SUT, 235 Packet Loss as the indicator of Forwarding Congestion is 236 used. 238 Throughput [Br91] defines the lower boundary of Forwarding 239 Congestion. Throughput is the maximum offered rate with no 240 Forwarding Congestion. At offered rates above throughput, the 241 DUT/SUT is considered to be in a state of Forwarding 242 Congestion. 244 Ingress observations alone are not sufficient to cover all 245 cases in which Forwarding Congestion may occur. A device with 246 an infinite amount of memory could buffer an infinite amount 247 of packets, and eventually forward all of them. However, 248 these packets may or may not be forwarded during the test 249 duration. Even though ingress interfaces accept all packets 250 without loss, Forwarding Congestion is present in this 251 hypothetical device. 253 Network-layer Traffic Control Mechanisms 255 Forwarding Congestion, indicated by occurrence of packet 256 loss, is one type of congestion for a DUT/SUT. Congestion 257 Collapse [Na84] is defined as the state in which buffers are 258 full and all arriving packets must be dropped across the 259 network. Incipient Congestion [Ra99] is defined as 260 congestion that produces increased delay without packet loss. 262 The definition presented here explicitly defines Forwarding 263 Congestion as an event observable on egress interfaces. 264 Regardless of internal architecture, any device that cannot 265 forward packets on one or more egress interfaces is under 266 Forwarding Congestion. 268 Measurement units: 269 none 271 See Also: 272 Gateway Congestion Control Survey [Ma91] 274 3.1.4 Congestion Management 276 Definition: 277 An implementation of one or more per-hop-behaviors to avoid 278 or minimize the condition of congestion. 280 Discussion: 281 Congestion management may seek either to control congestion 282 or avoid it altogether. Such mechanisms classify packets 283 based upon IP Precedence or DSCP settings in a packet's IP 284 header. 286 Congestion avoidance mechanisms seek to prevent congestion 287 before it actually occurs. 289 Congestion control mechanisms gives one or flows (with a 290 discrete IP Precedence or DSCP value) preferential treatment 291 over other classes during periods of congestion. 293 Measurement units: 294 n/a 296 See Also: 298 3.1.5 Flow 300 Definition: 301 A flow is a one or more of packets sharing a common intended 302 pair of source and destination interfaces. 304 Discussion: 306 Network-layer Traffic Control Mechanisms 308 Packets are grouped by the ingress and egress interfaces they 309 use on a given DUT/SUT. 311 A flow can contain multiple source IP addresses and/or 312 destination IP addresses. All packets in a flow must enter 313 on the same ingress interface and exit on the same egress 314 interface, and have some common network layer content. 316 Microflows [Ni98] are a subset of flows. As defined in 317 [Ni98], microflows require application-to-application 318 measurement. In contrast, flows use lower-layer 319 classification criteria. Since this document focuses on 320 network-layer classification criteria, we concentrate here on 321 the use of network-layer identifiers in describing a flow. 322 Flow identifiers also may reside at the data-link, transport, 323 or application layers of the ISO model. However, identifiers 324 other than those at the network layer are out of scope for 325 this document. 327 A flow may contain a single code point/IP precedence value or 328 may contain multiple values destined for a single egress 329 interface. This is determined by the test methodology. 331 Measurement units: 332 n/a 334 See Also: 335 Microflow [Ni98] 336 Streams 338 3.2 Measurement Terms 340 3.2.1 Channel Capacity 342 Definition: 343 The maximum forwarding rate [Ma98] at which none of the 344 offered packets are dropped by the DUT/SUT. 346 Discussion: 347 Channel capacity measures the packet rate at the egress 348 interface(s) of the DUT/SUT. In contrast, throughput as 349 defined in RFC 1242 measures the packet rate at the ingress 350 interface(s) of the DUT/SUT. 352 Ingress-based measurements do not account for congestion of 353 the DUT/SUT. Channel capacity, as an egress measurement, does 354 take congestion into account. 356 Network-layer Traffic Control Mechanisms 358 Understanding channel capacity is a necessary precursor to 359 any measurement involving congestion. Throughput numbers can 360 be higher than channel capacity because of queueing. 362 This measurement differs from forwarding rate at maximum 363 offered load (FRMOL) [Ma98] in that it is intolerant of loss. 365 Measurement units: 366 N-octet packets per second 368 See Also: 369 Throughput [Br91] 370 Forwarding Rate at Maximum Offered Load [Ma98] 372 3.2.2 Conforming 374 Definition: 375 Packets which lie within specific rate, delay, or jitter 376 bounds. 378 Discussion: 379 A DUT/SUT may be configured to allow a given traffic class to 380 consume a given amount of bandwidth, or to fall within 381 predefined delay or jitter boundaries. All packets that lie 382 within specified bounds are then said to be conforming, 383 whereas those outside the bounds are nonconforming. 385 Measurement units: 386 n/a 388 See Also: 389 Expected Vector 390 Forwarding Vector 391 Offered Vector 392 Nonconforming 394 3.2.3 Nonconforming 396 Definition: 397 Packets that do not lie within specific rate, delay, or 398 jitter bounds. 400 Discussion: 401 A DUT/SUT may be configured to allow a given traffic class to 402 consume a given amount of bandwidth, or to fall within 403 predefined delay or jitter boundaries. All packets that do 404 not lie within these bounds are then said to be 405 nonconforming. 407 Network-layer Traffic Control Mechanisms 409 Measurement units: 410 n/a 412 See Also: 413 Expected Vector 414 Forwarding Vector 415 Offered Vector 416 Conforming 418 3.2.4 Forwarding Delay 420 Definition: 421 The time interval starting when the last bit of the input IP 422 packet is offered to the input port of the DUT/SUT and ending 423 when the last bit of the output IP packet is received from 424 the output port of the DUT/SUT. 426 Discussion: 427 The delay time interval MUST be externally observed. The 428 delay measurement MUST NOT include delays added by test bed 429 components other than the DUT/SUT, such as propagation time 430 introduced by cabling or non-zero delay added by the test 431 instrument. 433 Forwarding Delay differs from latency [Br91] and one-way 434 delay [Al99] in several key regards: 436 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 437 uses "store and forward" or "bit forwarding" technology. 438 Forwarding Delay is the same metric, measured the same way, 439 regardless of the architecture of the DUT/SUT. 441 2. Forwarding Delay is a last-in, last-out (LILO) 442 measurement, unlike the last-in, first-out method [Br91] or 443 the first-in, last-out method [Al99]. 445 The LILO method most closely simulates the way a network- 446 layer device actually processes an IP datagram. IP datagrams 447 are not passed up and down the stack unless they are 448 complete, and processing begins only once the last bit of the 449 IP datagram has been received. 451 Further, the LILO method has an additive property, where the 452 sum of the parts MUST equal the whole. This is a key 453 difference from [Br91] and [Al99]. For example, the delay 454 added by two DUTs MUST equal the sum of the delay of the 455 DUTs. This may or may not be the case with [Br91] and [Al99]. 457 3. Forwarding Delay measures the IP datagram only, unlike 458 [Br91], which also includes link layer overhead. 460 Network-layer Traffic Control Mechanisms 462 A metric focused exclusively on the Internet protocol 463 relieves the tester from specifying the start/end for every 464 link layer protocol that IP runs on. This avoids the need to 465 determine whether the start/stop delimiters are included. It 466 also allows the use of heterogeneous link layer protocols in 467 a test. 469 4. Forwarding Delay can be measured at any offered load, 470 whereas the latency methodology [Br99] recommends measurement 471 at, and only at, the throughput level. Comparing the 472 Forwarding Delay below the throughput to Forwarding Delay 473 above the channel capacity will give insight to the traffic 474 control mechanisms. 476 For example, non-congested delay may be measured with an 477 offered load that does not exceed the channel capacity, while 478 congested delay may involve an offered load that exceeds 479 channel capacity. 481 Note: Forwarding Delay SHOULD NOT be used as an absolute 482 indicator of DUT/SUT Forwarding Congestion. While Forwarding 483 Delay may rise when offered load nears or exceeds channel 484 capacity, there is no universal point at which Forwarding 485 Delay can be said to indicate the presence or absence of 486 Forwarding Congestion. 488 Measurement units: 489 Seconds. 491 See Also: 492 Latency [Br91] 493 Latency [Al99] 494 One-way Delay [Br99] 496 3.2.5 Jitter 498 Definition: 499 The absolute value of the difference between the arrival 500 delay of two consecutive received packets belonging to the 501 same stream. 503 Discussion: 504 The delay fluctuation between two consecutive received 505 packets in a stream is reported as the jitter. Jitter can be 506 expressed as |D(i) - D(i-1)| where D equals the delay and i 507 is the order the packets were received. 509 Under loss, jitter can be measured between non-consecutive 510 test sequence numbers. When Traffic Control Mechanisms are 511 losing packets, the Forwarding Delay may fluctuate as a 512 Network-layer Traffic Control Mechanisms 514 response. Jitter MUST be able to benchmark the delay 515 variation with or with out loss. 517 Jitter is related to the ipdv [De02] (IP Delay Variation) by 518 taking the absolute value of the ipdv. The two metrics will 519 produce different mean values. _Mean Jitter_ will produce a 520 positive value, where the _mean ipdv_ is typically zero. 522 Measurement units: 523 Seconds 525 See Also: 526 Forwarding Delay 527 Jitter variation [Ja99] 528 ipdv [De02] 529 interarrival jitter [Sc96] 531 3.2.6 Undifferentiated Response 533 Definition: 534 The vector(s) obtained when mechanisms used to support diff- 535 serv or IP precedence are disabled. 537 Discussion: 538 Enabling diff-serv or IP precedence mechanisms may impose 539 additional processing overhead for packets. This overhead may 540 degrade performance even when traffic belonging to only one 541 class, the best-effort class, is offered to the device. 543 Measurements with "undifferentiated response" should be made 544 to establish a baseline. 546 The vector(s) obtained with DSCPs or IP precedence enabled 547 can be compared to the undifferentiated response to determine 548 the effect of differentiating traffic. 550 Measurement units: 551 n/a 553 3.3 Sequence Tracking 555 3.3.1 In-sequence Packet 557 Definition: 558 A received packet with the expected Test Sequence number. 560 Discussion: 561 In-sequence is done on a stream level. As packets are 562 received on a stream, each packet's Test Sequence number is 563 Network-layer Traffic Control Mechanisms 565 compared with the previous packet. Only packets that match 566 the expected Test Sequence number are considered in-sequence. 568 Packets that do not match the expected Test Sequence number 569 are counted as _not in-sequence_ or out-of-sequence. Every 570 packet that is received is either in-sequence or out-of- 571 sequence. Subtracting the in-sequence from the received 572 packets (for that stream) can derive the out-of-sequence 573 count. 575 Two types of events will prevent the in-sequence from 576 incrementing: packet loss and reordered packets. 578 Measurement units: 579 Packet count 581 See Also: 582 Stream 583 Test Sequence number 585 3.3.2 Out-of-order Packet 587 Definition: 588 A received packet with a Test Sequence number less that 589 expected. 591 Discussion: 592 As a stream of packets enter a DUT/SUT, they include a Stream 593 Test Sequence number indicating the order the packets were 594 sent to the DUT/SUT. On exiting the DUT/SUT, these packets 595 may arrive in a different order. Each packet that was re- 596 ordered is counted as an Out-of-order Packet. 598 Certain streaming protocol (such as TCP) require the packets 599 to be in a certain order. Packets outside this are dropped 600 by the streaming protocols even though there were properly 601 received by the IP layer. The type of reordering tolerated 602 by a streaming protocol varies from protocol to protocol, and 603 also by implementation. 605 Out-of-order Packet count is based on the worst case 606 streaming protocol. It allows for no reordering. 608 Packet loss does not affect the Out-of-order Packet count. 609 Only packets that were not received in the order that they 610 were transmitted. 612 Measurement units: 613 Packet count 615 See Also: 617 Network-layer Traffic Control Mechanisms 619 Stream 620 Test Sequence number 622 3.3.3 Duplicate Packet 624 Definition: 625 A received packet with a Test Sequence number matching a 626 previously received packet. 628 Discussion: 630 Measurement units: 631 Packet count 633 See Also: 634 Stream 635 Test Sequence number 637 3.3.4 Stream 639 Definition: 640 A group of packets tracked as a single entity by the traffic 641 receiver. A stream may share a common content such as type 642 (IP, UDP), packet size, or payload. 644 Discussion: 645 Streams are tracked by test sequence number or "unique 646 signature field" [Ma00]. Streams define how individual 647 packet's statistics are grouped together to form an 648 intelligible summary. 650 Common stream groupings would be by egress interface, 651 destination address, source address, DSCP, or IP precedence. 652 A stream using test sequence numbers can track the ordering 653 of packets as they transverse the DUT/SUT. 655 Streams are not restricted to a pair of source and 656 destination interfaces as long as all packets are tracked as 657 a single entity. A mulitcast stream can be forward to 658 multiple destination interfaces. 660 Measurement units: 661 n/a 663 See Also: 664 Flow 665 MicroFlow [Ni98] 666 Test sequence number 667 Network-layer Traffic Control Mechanisms 669 3.3.6 Test Sequence number 671 Definition: 672 A field in the IP payload portion of the packet that is used 673 to verify the order of the packets on the egress of the 674 DUT/SUT. 676 Discussion: 677 The traffic generator sets the test sequence number value and 678 the traffic receiver checks the value upon receipt of the 679 packet. The traffic generator changes the value on each 680 packet transmitted based on an algorithm agreed to by the 681 traffic receiver. 683 The traffic receiver keeps track of the sequence numbers on a 684 per stream basis. In addition to number of received packets, 685 the traffic receiver may also report number of in-sequence 686 packets, number of out-sequence packets, number of duplicate 687 packets, and number of reordered packets. 689 The recommended algorithm to use to change the sequence 690 number on sequential packets is an incrementing value. 692 Measurement units: 693 n/a 695 See Also: 696 Stream 698 3.4 Vectors 699 A vector is a group of packets all containing a specific DSCP 700 or IP precedence value. Vectors are expressed as a pair of 701 numbers. The first is being the particular diff-serv value. 702 The second is the metric expressed as a rate, loss 703 percentage, delay, or jitter. 705 3.4.1 Intended Vector 707 Definition: 708 A vector describing the rate at which packets having a 709 specific code-point (or IP precedence) that an external 710 source attempts to transmit to a DUT/SUT. 712 Discussion: 713 Intended loads across the different code-point classes 714 determine the metrics associated with a specific code-point 715 traffic class. 717 Network-layer Traffic Control Mechanisms 719 Measurement Units: 720 N-octets packets per second 722 See Also: 723 Offered Vector 724 Expected Forwarding Vector 725 Expected Loss Vector 726 Expected Sequence Vector 727 Expected Delay Vector 728 Expected Jitter Vector 729 Forwarding Vector 730 Loss Vector 732 3.4.2 Offered Vector 734 Definition: 735 A vector describing the measured rate at which packets having 736 a specific DSCP or IP precedence value are offered to the 737 DUT/SUT. 739 Discussion: 740 Offered loads across the different code-point classes, 741 constituting a code-point set, determine the metrics 742 associated with a specific code-point traffic class. 744 Measurement Units: 745 N-octets packets per second 747 See Also: 748 Expected Forwarding Vector 749 Expected Loss Vector 750 Expected Sequence Vector 751 Expected Delay Vector 752 Expected Jitter Vector 753 Forwarding Vector 754 Codepoint Set 756 3.4.3 Expected Vectors 758 3.4.3.1 Expected Forwarding Vector 760 Definition: 761 A vector describing the expected output rate of packets 762 having a specific DSCP or IP precedence value. The value is 763 dependent on the set of offered vectors and configuration of 764 the DUT. 766 Network-layer Traffic Control Mechanisms 768 Discussion: 769 The DUT is configured in a certain way in order that service 770 differentiation occurs for a particular DSCP or IP precedence 771 value when a specific traffic mix consisting of multiple 772 DSCPs or IP precedence values are applied. This term attempts 773 to capture the expected forwarding behavior when subjected to 774 a certain offered vectors. 776 The actual algorithm or mechanism the DUT uses to achieve 777 service differentiation is not important in describing the 778 expected forwarding vector. 780 Measurement units: 781 N-octet packets per second 783 See Also: 784 Intended Vector 785 Offered Vector 786 Output Vectors 787 Expected Loss Vector 788 Expected Sequence Vector 789 Expected Delay Vector 790 Expected Jitter Vector 792 3.4.3.2 Expected Loss Vector 794 Definition: 795 A vector describing the percentage of packets, having a 796 specific DSCP or IP precedence value, that should not be 797 forwarded. The value is dependent on the set of offered 798 vectors and configuration of the DUT. 800 Discussion: 801 The DUT is configured in a certain way in order that service 802 differentiation occurs for a particular DSCP or IP precedence 803 value when a specific traffic mix consisting of multiple 804 DSCPs or IP precedence values are applied. This term attempts 805 to capture the expected forwarding behavior when subjected to 806 a certain offered vector. 808 The actual algorithm or mechanism the DUT uses to achieve 809 service differentiation is not important in describing the 810 expected loss vector. 812 Measurement Units: 813 Percentage of intended packets that are expected to be 814 dropped. 816 Network-layer Traffic Control Mechanisms 818 See Also: 819 Intended Vector 820 Offered Vector 821 Expected Forwarding Vector 822 Expected Sequence Vector 823 Expected Delay Vector 824 Expected Jitter Vector 825 One-way Packet Loss Metric [Ka99] 827 3.2.3.3 Expected Sequence Vector 829 Definition: 830 A vector describing the expected in-sequence packets having a 831 specific DSCP or IP precedence value. The value is dependent 832 on the set of offered 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 attempts 839 to capture the expected forwarding behavior when subjected to 840 a certain offered vectors. 842 The actual algorithm or mechanism the DUT uses to achieve 843 service differentiation is not important in describing the 844 expected sequence vector. 846 Measurement Units: 847 N-octet packets per second 849 See Also: 850 Intended Vector 851 Offered Vector 852 Output Vectors 853 Expected Loss Vector 854 Expected Forwarding Vector 855 Expected Delay Vector 856 Expected Jitter Vector 858 3.4.3.4 Expected Instantaneous Delay Vector 860 Definition: 861 A vector describing the expected delay for packets having a 862 specific DSCP or IP precedence value. The value is dependent 863 on the set of offered vectors and configuration of the DUT. 865 Network-layer Traffic Control Mechanisms 867 Discussion: 868 The DUT is configured in a certain way in order that service 869 differentiation occurs for a particular DSCP or IP precedence 870 value when a specific traffic mix consisting of multiple 871 DSCPs or IP precedence values are applied. This term attempts 872 to capture the expected forwarding behavior when subjected to 873 a certain offered vectors. 875 The actual algorithm or mechanism the DUT uses to achieve 876 service differentiation is not important in describing the 877 expected delay vector. 879 Measurement units: 880 Seconds. 882 See Also: 883 Forwarding Delay 884 Intended Vector 885 Offered Vector 886 Output Vectors 887 Expected Loss Vector 888 Expected Sequence Vector 889 Expected Forwarding Vector 890 Expected Jitter Vector 892 3.4.3.5 Expected Average Delay Vector 894 Definition: 895 A vector describing the expected average delay for packets 896 having a specific DSCP or IP precedence value. The value is 897 dependent on the set of offered vectors and configuration of 898 the DUT. 900 Discussion: 901 The DUT is configured in a certain way in order that service 902 differentiation occurs for a particular DSCP or IP precedence 903 value when a specific traffic mix consisting of multiple 904 DSCPs or IP precedence values are applied. This term attempts 905 to capture the expected forwarding behavior when subjected to 906 a certain offered vectors. 908 The actual algorithm or mechanism the DUT uses to achieve 909 service differentiation is not important in describing the 910 expected average delay vector. 912 Measurement units: 913 Seconds. 915 Network-layer Traffic Control Mechanisms 917 See Also: 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.6 Expected Maximum Delay Vector 928 Definition: 929 A vector describing the expected maximum 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 attempts 939 to capture the expected forwarding behavior when subjected to 940 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 maximum delay vector. 946 Measurement units: 947 Seconds. 949 See Also: 950 Intended Vector 951 Offered Vector 952 Output Vectors 953 Expected Loss Vector 954 Expected Sequence Vector 955 Expected Forwarding Vector 956 Expected Jitter Vector 958 3.4.3.7 Expected Minimum Delay Vector 960 Definition: 961 A vector describing the expected minimum delay for packets 962 having a specific DSCP or IP precedence value. The value is 963 dependent on the set of offered vectors and configuration of 964 the DUT. 966 Network-layer Traffic Control Mechanisms 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 attempts 973 to capture the expected forwarding behavior when subjected to 974 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 minimum 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.2.3.8 Expected Instantaneous Jitter Vector 994 Definition: 995 A vector describing the expected jitter between two 996 consecutive packets' arrival times having a specific DSCP or 997 IP precedence value. The value is dependent on the set of 998 offered vectors and configuration of the DUT. 1000 Discussion: 1001 Instantaneous Jitter is the absolute value of the difference 1002 between the delay measurement of two packets belonging to the 1003 same stream. 1005 The delay fluctuation between two consecutive packets in a 1006 stream is reported as the "Instantaneous Jitter". 1007 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 1008 where D equals the delay and i is the test sequence number. 1009 Packets lost are not counted in the measurement. 1011 Forwarding Vector may contain several Jitter Vectors. For n 1012 packets received in a Forwarding Vector, there is a total of 1013 (n-1) Instantaneous Jitter Vectors. 1015 Measurement units: 1016 Seconds 1017 Network-layer Traffic Control Mechanisms 1019 See Also: 1020 Delay 1021 Jitter 1022 Offered Vector 1023 Output Vectors 1024 Expected Average Jitter Vector 1025 Expected Peak-to-peak Jitter Vector 1026 Stream 1028 3.2.3.9 Expected Average Jitter Vector 1030 Definition: 1031 A vector describing the expected jitter in packet arrival 1032 times for packets having specific DSCP or IP precedence 1033 value. The value is dependent on the set of offered vectors 1034 and configuration of the DUT. 1036 Discussion: 1037 Average Jitter Vector is the average of all the Instantaneous 1038 Jitter Vectors measured during the test duration for the same 1039 DSCP or IP precedence value. 1041 Measurement units: 1042 Seconds 1044 See Also: 1045 Intended Vector 1046 Offered Vector 1047 Output Vectors 1048 Expected Instantaneous Jitter Vector 1049 Expected Peak-to-peak Jitter Vector 1051 3.2.3.10 Expected Peak-to-peak Jitter Vector 1053 Definition: 1054 A vector describing the expected maximum variation in the 1055 delay of packet arrival times for packets having specific 1056 DSCP or IP precedence value. The value is dependent on the 1057 set of offered vectors and configuration of the DUT. 1059 Discussion: 1060 Peak-to-peak Jitter Vector is the maximum delay minus the 1061 minimum delay of the packets (in a vector) forwarded by the 1062 DUT/SUT. 1064 Peak-to-peak Jitter is not derived from the Instantaneous 1065 Jitter Vector. Peak-to-peak Jitter is based upon all the 1066 Network-layer Traffic Control Mechanisms 1068 packets during the test duration, not just two consecutive 1069 packets. 1071 Measurement units: 1072 Seconds 1074 See Also: 1075 Intended Vector 1076 Offered Vector 1077 Output Vectors 1078 Expected Instantaneous Jitter Vector 1079 Expected Average Jitter Vector 1081 3.4.4 Output Vectors 1083 3.4.4.1 Forwarding Vector 1085 Definition: 1086 The number of packets per second for all packets containing a 1087 specific DSCP or IP precedence value that a device can be 1088 observed to successfully forward to the correct destination 1089 interface in response to an offered vector. 1091 Discussion: 1092 Forwarding Vector is expressed as pair of numbers. Both the 1093 specific DSCP (or IP precedence) value AND the packets per 1094 second value combine to make a vector. 1096 The Forwarding Vector represents packet rate based on its 1097 specific DSCP (or IP precedence) value. It is not 1098 necessarily based on a stream or flow. The Forwarding Vector 1099 may be expressed as per port of the DUT/SUT. However, it must 1100 be consistent with the Expected Forwarding Vector. 1102 Forwarding Vector is a per-hop measurement. The DUT/SUT may 1103 change the specific DSCP (or IP precedence) value for a 1104 multiple-hop measurement. 1106 Measurement units: 1107 N-octet packets per second 1109 See Also: 1110 Intended Vector 1111 Offered Vector 1112 Expected Vectors 1113 Loss Vector 1114 Sequence Vector 1115 Delay Vectors 1116 Network-layer Traffic Control Mechanisms 1118 3.4.4.2 Loss Vector 1120 Definition: 1121 The percentage of packets containing specific DSCP or IP 1122 precedence value that a DUT/SUT did not transmit to the 1123 correct destination interface in response to an offered 1124 vector. 1126 Discussion: 1127 Loss Vector is expressed as pair of numbers. Both the 1128 specific DSCP (or IP precedence) value AND the percentage 1129 value combine to make a vector. 1131 The Loss Vector represents percentage based on a specific 1132 DSCP or IP precedence value. It is not necessarily based on 1133 a stream or flow. The Loss Vector may be expressed as per 1134 port of the DUT/SUT. However, it must be consistent with the 1135 Expected Loss Vector 1137 Loss Vector is a per-hop measurement. The DUT/SUT may change 1138 the specific DSCP or IP precedence value for a multiple-hop 1139 measurement. 1141 Measurement Units: 1142 Percentage of offered packets that are not forwarded. 1144 See Also: 1145 Intended Vector 1146 Offered Vector 1147 Expected Vectors 1148 Forwarding Vector 1149 Sequence Vector 1150 Delay Vectors 1151 One-way Packet Loss Metric [Ka99] 1153 3.4.4.3 Sequence Vector 1155 Definition: 1156 The number of packets per second for all packets containing a 1157 specific DSCP or IP precedence value that a device can be 1158 observed to transmit in sequence to the correct destination 1159 interface in response to an offered vector. 1161 Discussion: 1162 Sequence Vector is expressed as pair of numbers. Both the 1163 specific DSCP (or IP precedence) value AND the packets per 1164 second value combine to make a vector. 1166 Network-layer Traffic Control Mechanisms 1168 The Sequence Vector represents packet rate based on its 1169 specific DSCP or IP precedence value. It is not necessarily 1170 based on a stream or flow. The Sequence Vector may be 1171 expressed as per port of the DUT/SUT. However, it must be 1172 consistent with the Expected Sequence Vector. 1174 Sequence Vector is a per-hop measurement. The DUT/SUT may 1175 change the specific DSCP or IP precedence value for a 1176 multiple-hop measurement. 1178 Measurement Units: 1179 N-octet packets per second 1181 Issues: 1183 See Also: 1184 In-sequence Packet 1185 Intended Vector 1186 Offered Vector 1187 Expected Vectors 1188 Loss Vector 1189 Forwarding Vector 1190 Delay Vectors 1192 3.4.4.4 Instantaneous Delay Vector 1194 Definition: 1195 The delay for a packet containing specific DSCP or IP 1196 precedence value that a device can be observed to 1197 successfully transmit to the correct destination interface in 1198 response to an offered vector. 1200 Discussion: 1201 Instantaneous Delay vector is expressed as pair of numbers. 1202 Both the specific DSCP (or IP precedence) value AND delay 1203 value combine to make a vector. 1205 The Instantaneous Delay Vector represents delay on its 1206 specific DSCP or IP precedence value. It is not necessarily 1207 based on a stream or flow. The Delay vector may be expressed 1208 as per port of the DUT/SUT. However, it must be consistent 1209 with the Expected Delay vectors. 1211 Instantaneous Delay Vector is a per-hop measurement. The 1212 DUT/SUT may change the specific DSCP or IP precedence value 1213 for a multiple-hop measurement. 1215 Network-layer Traffic Control Mechanisms 1217 Instantaneous Delay vector can be obtained at any offered 1218 load. Recommend at or below the channel capacity in the 1219 absence of congestion. For congested delay, run the offered 1220 load above the channel capacity. 1222 Forwarding Vector may contain several Instantaneous Delay 1223 Vectors. For every packet received in a Forwarding Vector, 1224 there is a corresponding Instantaneous Delay Vector. 1226 Measurement Units: 1227 Seconds 1229 See Also: 1230 Delay 1231 Intended Vector 1232 Offered Vector 1233 Expected Delay Vectors 1234 Average Delay Vector 1235 Maximum Delay Vector 1236 Minimum Delay Vector 1238 3.4.4.5 Average Delay Vector 1240 Definition: 1241 The average delay for packets containing specific DSCP or IP 1242 precedence value that a device can be observed to 1243 successfully transmit to the correct destination interface in 1244 response to an offered vector. 1246 Discussion: 1247 Average Delay vector is expressed as pair of numbers. Both 1248 the specific DSCP (or IP precedence) value AND delay value 1249 combine to make a vector. 1251 The Delay Vector represents delay on its specific DSCP or IP 1252 precedence value. It is not necessarily based on a stream or 1253 flow. The Delay vector may be expressed as per port of the 1254 DUT/SUT. However, it must be consistent with the Expected 1255 Delay vector. 1257 The Average Delay Vector is computed by averaging all the 1258 Instantaneous Delay Vectors for a given vector. 1260 Average Delay Vector is a per-hop measurement. The DUT/SUT 1261 may change the specific DSCP or IP precedence value for a 1262 multiple-hop measurement. 1264 Average Delay vector can be obtained at any offered load. 1265 Recommend at or below the channel capacity in the absence of 1266 congestion. For congested delay, run the offered load above 1267 the channel capacity. 1269 Network-layer Traffic Control Mechanisms 1271 Measurement Units: 1272 Seconds 1274 See Also: 1275 Delay 1276 Intended Vector 1277 Offered Vector 1278 Expected Delay Vectors 1279 Instantaneous Delay Vector 1280 Maximum Delay Vector 1281 Minimum Delay Vector 1283 3.4.4.6 Maximum Delay Vector 1285 Definition: 1286 The maximum delay from all packets containing specific DSCP 1287 or IP precedence value that a device can be observed to 1288 successfully transmit to the correct destination interface in 1289 response to an offered vector. 1291 Discussion: 1292 Maximum Delay vector is expressed as pair of numbers. Both 1293 the specific DSCP (or IP precedence) value AND delay value 1294 combine to make a vector. 1296 The Maximum Delay Vector represents delay on its specific 1297 DSCP or IP precedence value. It is not necessarily based on 1298 a stream or flow. The Maximum Delay vector may be expressed 1299 as per port of the DUT/SUT. However, it must be consistent 1300 with the Expected Delay vector. 1302 Maximum Delay Vector is based upon the maximum Instantaneous 1303 Delay Vector of all packets in a Forwarding Vector. 1305 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1306 may change the specific DSCP or IP precedence value for a 1307 multiple-hop measurement. 1309 Measurement Units: 1310 Seconds 1312 See Also: 1313 Delay 1314 Intended Vector 1315 Offered Vector 1316 Expected Delay Vectors 1317 Instantaneous Delay Vector 1318 Forwarding Vector 1319 Average Delay Vector 1320 Minimum Delay Vector 1321 Network-layer Traffic Control Mechanisms 1323 3.4.4.7 Minimum Delay Vector 1325 Definition: 1326 The minimum delay from all packets containing specific DSCP 1327 or IP precedence value that a device can be observed to 1328 successfully transmit to the correct destination interface in 1329 response to an offered vector. 1331 Discussion: 1332 Delay vector is expressed as pair of numbers. Both the 1333 specific DSCP (or IP precedence) value AND delay value 1334 combine to make a vector. 1336 The Minimum Delay Vector represents delay on its specific 1337 DSCP or IP precedence value. It is not necessarily based on 1338 a stream or flow. The Minimum Delay vector may be expressed 1339 as per port of the DUT/SUT. However, it must be consistent 1340 with the Expected Delay vector. 1342 Minimum Delay Vector is based upon the minimum Instantaneous 1343 Delay Vector of all packets in a Forwarding Vector. 1345 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1346 may change the specific DSCP or IP precedence value for a 1347 multiple-hop measurement. 1349 Minimum Delay vector can be obtained at any offered load. 1350 Recommend at or below the channel capacity in the absence of 1351 congestion. For congested delay, run the offered load above 1352 the channel capacity. 1354 Measurement Units: 1355 Seconds 1357 See Also: 1358 Delay 1359 Intended Vector 1360 Offered Vector 1361 Expected Delay Vectors 1362 Instantaneous Delay Vector 1363 Forwarding Vector 1364 Average Delay Vector 1365 Maximum Delay Vector 1367 3.4.4.8 Instantaneous Jitter Vector 1369 Definition: 1371 Network-layer Traffic Control Mechanisms 1373 The jitter for two consecutive packets containing specific 1374 DSCP or IP precedence value that a device can be observed to 1375 successfully transmit to the correct destination interface in 1376 response to an offered vector. 1378 Discussion: 1379 Instantaneous Jitter is the absolute value of the difference 1380 between the delay measurement of two packets belonging to the 1381 same stream. 1383 Jitter vector is expressed as pair of numbers. Both the 1384 specific DSCP (or IP precedence) value AND jitter value 1385 combine to make a vector. 1387 The delay fluctuation between two consecutive packets in a 1388 stream is reported as the "Instantaneous Jitter". 1389 Instantaneous Jitter Vector can be expressed as |D(i) - D(i- 1390 1)| where D equals the delay and i is the test sequence 1391 number. Packets lost are not counted in the measurement. 1393 Instantaneous Jitter Vector is a per-hop measurement. The 1394 DUT/SUT may change the specific DSCP or IP precedence value 1395 for a multiple-hop measurement. 1397 Forwarding Vector may contain several Instantaneous Jitter 1398 Vectors. For n packets received in a Forwarding Vector, 1399 there are exactly (n-1) Instantaneous Jitter Vectors. 1401 Measurement units: 1402 Seconds 1404 See Also: 1405 Delay 1406 Jitter 1407 Forwarding Vector 1408 Stream 1409 Expected Vectors 1410 Average Jitter Vector 1411 Peak-to-peak Jitter Vector 1413 3.4.4.9 Average Jitter Vector 1415 Definition: 1416 The average jitter for packets containing specific DSCP or IP 1417 precedence value that a device can be observed to 1418 successfully transmit to the correct destination interface in 1419 response to an offered vector. 1421 Discussion: 1423 Network-layer Traffic Control Mechanisms 1425 Average Jitter Vector is the average of all the Instantaneous 1426 Jitter Vectors of the same DSCP or IP precedence value, 1427 measured during the test duration. 1429 Average Jitter vector is expressed as pair of numbers. Both 1430 the specific DSCP (or IP precedence) value AND jitter value 1431 combine to make a vector. 1433 Average Jitter vector is a per-hop measurement. The DUT/SUT 1434 may change the specific DSCP or IP precedence value for a 1435 multiple-hop measurement. 1437 Measurement units: 1438 Seconds 1440 See Also: 1441 Jitter 1442 Forwarding Vector 1443 Stream 1444 Expected Vectors 1445 Instantaneous Jitter Vector 1446 Peak-to-peak Jitter Vector 1448 3.4.4.10 Peak-to-peak Jitter Vector 1450 Definition: 1451 The maximum possible variation in the delay for packets 1452 containing specific DSCP or IP precedence value that a device 1453 can be observed to successfully transmit to the correct 1454 destination interface in response to an offered vector. 1456 Discussion: 1457 Peak-to-peak Jitter Vector is the maximum delay minus the 1458 minimum delay of the packets (in a vector) forwarded by the 1459 DUT/SUT. 1461 Jitter vector is expressed as pair of numbers. Both the 1462 specific DSCP (or IP precedence) value AND jitter value 1463 combine to make a vector. 1465 Peak-to-peak Jitter is not derived from the Instantaneous 1466 Jitter Vector. Peak-to-peak Jitter is based upon all the 1467 packets during the test duration, not just two consecutive 1468 packets. 1470 Measurement units: 1471 Seconds 1473 See Also: 1474 Jitter 1475 Forwarding Vector 1476 Network-layer Traffic Control Mechanisms 1478 Stream 1479 Expected Vectors 1480 Average Jitter Vector 1481 Peak-to-peak Jitter Vector 1482 Network-layer Traffic Control Mechanisms 1484 4. Security Considerations 1486 Documents of this type do not directly affect the security of 1487 the Internet or of corporate networks as long as benchmarking 1488 is not performed on devices or systems connected to 1489 production networks. 1491 Packets with unintended and/or unauthorized DSCP or IP 1492 precedence values may present security issues. Determining 1493 the security consequences of such packets is out of scope for 1494 this document. 1496 5. Acknowledgments 1498 The editors gratefully acknowledge the contributions of the 1499 IETF's benchmarking working group members in reviewing this 1500 document. The following individuals also made noteworthy 1501 contributions to the editors' understanding of the subject 1502 matter: John Dawson, Kevin Dubray, and Kathleen Nichols. 1504 6. Normative References 1506 [Br91] Bradner, S., Editor, "Benchmarking Terminology for 1507 Network Interconnection Devices", RFC 1242, July 1991. 1509 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1510 Switching Devices", RFC 2285, February 1998. 1512 [Ni98] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of 1513 the Differentiated Services Field (DS Field) in the IPv4 1514 and IPv6 Headers", RFC 2474, December 1998. 1516 Network-layer Traffic Control Mechanisms 1518 7. Informative References 1520 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., _A One-way Delay 1521 Metric for IPPM_, RFC 2679, September 1999 1523 [Bl98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 1524 Weiss, "An Architecture for Differentiated Services", 1525 RFC 2475, December 1998. 1527 [Br99] Bradner, S., McQuaid, J. _Benchmarking Methodology for 1528 Network Interconnect Devices_, RFC 2544, March 1999 1530 [De02] C. Demichelis, P. Chimento, _IP Packet Delay Variation 1531 Metric for IPPM_, RFC 3393, November 2002 1533 [Ja99] V. Jacobson, K. Nichols, K. Poduri, _An Expedited 1534 Forwarding PHB_, RFC 2598, June 1999 1536 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., _A One-way 1537 Packet Loss Metric for IPPM_, RFC 2680, September 1999 1539 [Ma91] A. Mankin, K. Ramakrishnan, _Gateway Congestion Control 1540 Survey_, RFC 1254, August 1991 1542 [Ma00] R. Mandeville, J. Perser, _Benchmarking Methodology for 1543 LAN Switching Devices_, RFC 2889, August 2000 1545 [Na84] Nagle, John, "Congestion Control in IP/TCP 1546 Internetworks", RFC 896, January 1984. 1548 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1549 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1550 January 1999. 1552 [Sc96] H. Schulzrinne, GMD Fokus, S. Casner, R. Frederick, 1553 V. Jacobson, _RTP: A Transport Protocol for Real-Time 1554 Applications_, RFC 1889, January 1996 1555 Network-layer Traffic Control Mechanisms 1557 8. Authors' Address 1559 Jerry Perser 1560 Spirent Communications 1561 26750 Agoura Road 1562 Calabasas, CA 91302 1563 USA 1565 Phone: + 1 818 676 2300 1566 EMail: jerry.perser@spirentcom.com 1568 David Newman 1569 Network Test 1570 31324 Via Colinas, Suite 113 1571 Westlake Village, CA 91362 1572 USA 1574 Phone: + 1 818 889 0011, x10 1575 EMail: dnewman@networktest.com 1577 Sumit Khurana 1578 Telcordia Technologies 1579 445 South Street 1580 Morristown, NJ 07960 1581 USA 1583 Phone: + 1 973 829 3170 1584 EMail: sumit@research.telcordia.com 1586 Shobha Erramilli 1587 QNetworx Inc 1588 1119 Campus Drive West 1589 Morganville NJ 07751 1590 USA 1592 Phone: 1593 EMail: shobha@qnetworx.com 1595 Scott Poretsky 1596 Avici Systems 1597 101 Billerica Ave_Building #6 1598 N. Billerica, MA 01862 1599 USA 1601 Phone: + 1 978 964 2287 1602 EMail: sporetsky@avici.com 1603 Network-layer Traffic Control Mechanisms 1605 9. Full Copyright Statement 1607 Copyright (C) The Internet Society (1998). All Rights 1608 Reserved. 1610 This document and translations of it may be copied and 1611 furnished to others, and derivative works that comment on or 1612 otherwise explain it or assist in its implementation may be 1613 prepared, copied, published and distributed, in whole or in 1614 part, without restriction of any kind, provided that the 1615 above copyright notice and this paragraph are included on all 1616 such copies and derivative works. However, this document 1617 itself may not be modified in any way, such as by removing 1618 the copyright notice or references to the Internet Society or 1619 other Internet organizations, except as needed for the 1620 purpose of developing Internet standards in which case the 1621 procedures for copyrights defined in the Internet Standards 1622 process must be followed, or as required to translate it into 1623 languages other than English. 1625 The limited permissions granted above are perpetual and will 1626 not be revoked by the Internet Society or its successors or 1627 assigns. This document and the information contained herein 1628 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1629 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1630 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1631 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1632 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1633 FITNESS FOR A PARTICULAR PURPOSE.