idnits 2.17.1 draft-ietf-bmwg-dsmterm-03.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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 45 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2002) is 7985 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: '4' is defined on line 1388, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 2002 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 QNetworx 10 Scott Poretsky 11 Avici Systems 12 June 2002 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 .............................................. 2 44 2. Existing definitions ...................................... 3 45 3. Term definitions ............................................3 46 3.1 Configuration Terms 47 3.1.1 Classification .........................................3 48 3.1.2 Codepoint Set ..........................................4 49 3.1.3 Congestion .............................................4 50 3.1.4 Congestion Management ..................................5 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 .............................................7 57 3.2.3 Nonconforming ..........................................8 58 3.2.4 Delay ..................................................8 59 3.2.6 Undifferentiated Response ................................9 60 3.3 Sequence Tracking 61 3.3.1 In-sequence Packet .....................................9 62 3.3.2 Out-of-order Packet ...................................10 63 3.3.3 Duplicate Packet ......................................11 64 3.3.4 Stream ................................................11 65 3.3.5 Test Sequence number .................................12 66 3.4 Vectors ...................................................12 67 3.4.1 Intended Vector .......................................12 68 3.4.2 Offered Vector ........................................13 69 3.4.3 Expected Vectors 70 3.4.3.1 Expected Forwarding Vector ........................13 71 3.4.3.2 Expected Loss Vector ..............................14 72 3.4.3.3 Expected Sequence Vector ..........................14 73 3.4.3.4 Expected Instantaneous Delay Vector ...............15 74 3.4.3.5 Expected Average Delay Vector .....................16 75 3.4.3.6 Expected Maximum Delay Vector .....................17 76 3.4.3.7 Expected Minimum Delay Vector .....................17 77 3.4.3.8 Expected Instantaneous Delay Variation Vector .....18 78 3.4.3.9 Expected Average Delay Variation Vector ...........19 79 3.4.3.10 Expected Peak-to-peak Delay Variation Vector .....19 80 3.4.4 Output Vectors 81 3.4.4.1 Forwarding Vector .................................20 82 3.4.4.2 Loss Vector .......................................20 83 3.4.4.3 Sequence Vector ...................................21 84 3.4.4.4 Instantaneous Delay Vector ........................22 85 3.4.4.5 Average Delay Vector ..............................23 86 3.4.4.6 Maximum Delay Vector ..............................23 87 3.4.4.7 Minimum Delay Vector ..............................24 88 3.4.4.8 Instantaneous Delay Variation Vector ..............25 89 3.4.4.9 Average Delay Variation Vector ....................26 90 3.4.4.10 Peak-to-peak Delay Variation Vector ..............27 91 4. Security Considerations ....................................28 92 5. References .................................................28 93 6. Author's Address ...........................................29 94 7. Full Copyright Statement ...................................30 96 1. Introduction 98 This document describes terminology for the benchmarking of 99 devices that implement traffic control based on IP precedence or 100 diff-serv code point criteria. 102 New terminology is needed because most existing measurements 103 assume the absence of congestion and only a single per-hop- 104 behavior. This document introduces several new terms that will 105 allow measurements to be taken during periods of congestion. 107 Network-layer Traffic Control Mechanisms 109 Another key difference from existing terminology is the definition 110 of measurements as observed on egress as well as ingress of a 111 device/system under test. Again, the existence of congestion 112 requires the addition of egress measurements as well as those 113 taken on ingress; without observing traffic leaving a 114 device/system it is not possible to say whether traffic-control 115 mechanisms effectively dealt with congestion. 117 The principal measurements introduced in this document are vectors 118 for rate, delay, and jitter, all of which can be observed with or 119 without congestion of the DUT/SUT. 121 This document describes only those terms relevant to measuring 122 behavior of a device or a group of devices using one of these two 123 mechanisms. End-to-end and service-level measurements are beyond 124 the scope of this document. 126 2. Existing definitions 128 RFC 1242 "Benchmarking Terminology for Network Interconnect 129 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 130 Devices" should be consulted before attempting to make use of this 131 document. 133 RFC 2474 "Definition of the Differentiated Services Field (DS 134 Field) in the IPv4 and IPv6 Headers" section 2, contains 135 discussions of a number of terms relevant to network-layer traffic 136 control mechanisms and should also be consulted. 138 For the sake of clarity and continuity this RFC adopts the 139 template for definitions set out in Section 2 of RFC 1242. 140 Definitions are indexed and grouped together in sections for ease 141 of reference. 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 144 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in 146 RFC 2119. 148 3. Term definitions 150 3.1 Configuration Terms 152 3.1.1 Classification 154 Definition: 155 Selection of packets based on the contents of packet header 156 according to defined rules. 158 Network-layer Traffic Control Mechanisms 160 Discussion: 161 Packets can be selected based on the DS field or IP 162 Precedence in the packet header. Classification can also be 163 based on Multi-Field (MF) criteria such as IP Source and 164 destination addresses, protocol and port number. 166 Classification determines the per-hop behaviors and traffic 167 conditioning functions such as shaping and dropping that are 168 to be applied to the packet. 170 Measurement units: 171 n/a 173 See Also: 175 3.1.2 Codepoint Set 177 Definition: 178 The set of all DS Code-points or IP precedence values used 179 during the test duration. 181 Discussion: 182 Describes all the code-point markings associated with packets 183 that are input to the DUT/SUT. For each entry in the 184 codepoint set, there are associated vectors describing the 185 rate of traffic, delay, loss, or jitter containing that 186 particular DSCP or IP precedence value. 188 The treatment that a packet belonging to a particular code- 189 point gets is subject to the DUT classifying packets to map 190 to the correct PHB. Moreover, the forwarding treatment in 191 general is also dependent on the complete set of offered 192 vectors. 194 Measurement Units: 195 n/a 197 See Also: 199 3.1.3 Congestion 201 Definition: 202 A condition in which one or more egress interfaces are 203 offered more packets than are forwarded at any given instant. 205 Discussion: 206 This condition is a superset of the overload definition [2]. 207 The overload definition assumes the congestion is introduced 208 Network-layer Traffic Control Mechanisms 210 strictly by the tester on ingress of a DUT/SUT. That may or 211 may not be the case here. 213 Another difference between congestion and overload occurs 214 when the SUT comprises multiple elements, in that congestion 215 may occur at multiple points. Consider an SUT comprising 216 multiple edge devices exchanging traffic with a single core 217 device. Depending on traffic patterns, the edge devices may 218 induce congestion on multiple egress interfaces on the core 219 device. In contrast, overload [1] deals only with overload on 220 ingress. 222 Ingress observations alone are not sufficient to cover all 223 cases in which congestion may occur. A device with an 224 infinite amount of memory could buffer an infinite amount of 225 packets, and eventually forward all of them. However, these 226 packets may or may not be forwarded during the test duration. 227 Even though ingress interfaces accept all packets without 228 loss, this hypothetical device may still be congested. 230 The definition presented here explicitly defines congestion 231 as an event observable on egress interfaces. Regardless of 232 internal architecture, any device that cannot forward packets 233 on one or more egress interfaces is congested. 235 Measurement units: 236 n/a 238 See Also: 240 3.1.4 Congestion Management 242 Definition: 243 An implementation of one or more per-hop-behaviors to avoid 244 or minimize the condition of congestion. 246 Discussion: 247 Congestion management may seek either to control congestion 248 or avoid it altogether. Such mechanisms classify packets 249 based upon IP Precedence or DSCP settings in a packet's IP 250 header. 252 Congestion avoidance mechanisms seek to prevent congestion 253 before it actually occurs. 255 Congestion control mechanisms gives one or flows (with a 256 discrete IP Precedence or DSCP value) preferential treatment 257 over other classes during periods of congestion. 259 Measurement units: 260 n/a 261 Network-layer Traffic Control Mechanisms 263 See Also: 265 3.1.5 Flow 267 Definition: 268 A flow is a one or more of packets sharing a common intended 269 pair of source and destination interfaces. 271 Discussion: 272 Packets are grouped by the ingress and egress interfaces they 273 use on a given DUT/SUT. 275 A flow can contain multiple source IP addresses and/or 276 destination IP addresses. All packets in a flow must enter 277 on the same ingress interface and exit on the same egress 278 interface, and have some common network layer content. 280 Microflows [3] are a subset of flows. As defined in [3], 281 microflows require application-to-application measurement. In 282 contrast, flows use lower-layer classification criteria. 283 Since this document focuses on network-layer classification 284 criteria, we concentrate here on the use of network-layer 285 identifiers in describing a flow. Flow identifiers also may 286 reside at the data-link, transport, or application layers of 287 the ISO model. However, identifiers other than those at the 288 network layer are out of scope for this document. 290 A flow may contain a single code point/IP precedence value or 291 may contain multiple values destined for a single egress 292 interface. This is determined by the test methodology. 294 Measurement units: 295 n/a 297 See Also: 298 Microflow [3] 299 Streams 300 Network-layer Traffic Control Mechanisms 302 3.2 Measurement Terms 304 3.2.1 Channel Capacity 306 Definition: 307 The maximum forwarding rate [2] at which none of the offered 308 packets are dropped by the DUT/SUT. 310 Discussion: 311 Channel capacity measures the packet rate at the egress 312 interface(s) of the DUT/SUT. In contrast, throughput as 313 defined in RFC 1242 measures the packet rate is based on the 314 ingress interface(s) of the DUT/SUT. 316 Ingress-based measurements do not account for congestion of 317 the DUT/SUT. Channel capacity, as an egress measurement, does 318 take congestion into account. 320 Understanding channel capacity is a necessary precursor to 321 any measurement involving congestion. Throughput numbers can 322 be higher than channel capacity because of queueing. 324 This measurement differs from forwarding rate at maximum 325 offered load (FRMOL) [2] in that it is intolerant of loss. 327 Measurement units: 328 N-octet packets per second 330 See Also: 331 Throughput [1] 332 Forwarding Rate at Maximum Offered Load [2] 334 3.2.2 Conforming 336 Definition: 337 Packets which lie within specific rate, delay, or jitter 338 bounds. 340 Discussion: 341 A DUT/SUT may be configured to allow a given traffic class to 342 consume a given amount of bandwidth, or to fall within 343 predefined delay or jitter boundaries. All packets that lie 344 within specified bounds are then said to be conforming, 345 whereas those outside the bounds are nonconforming. 347 Measurement units: 348 n/a 350 See Also: 351 Expected Vector 352 Network-layer Traffic Control Mechanisms 354 Forwarding Vector 355 Offered Vector 356 Nonconforming 358 3.2.3 Nonconforming 360 Definition: 361 Packets that do not lie within specific rate, delay, or 362 jitter bounds. 364 Discussion: 365 A DUT/SUT may be configured to allow a given traffic class to 366 consume a given amount of bandwidth, or to fall within 367 predefined delay or jitter boundaries. All packets that do 368 not lie within these bounds are then said to be 369 nonconforming. 371 Measurement units: 372 n/a 374 See Also: 375 Expected Vector 376 Forwarding Vector 377 Offered Vector 378 Conforming 380 3.2.4 Delay 382 Definition: 383 The time interval starting when the last bit of the input IP 384 packet reaches the input port of the DUT/SUT and ending when 385 the last bit of the output IP packet is seen on the output 386 port of the DUT/SUT. 388 Discussion: 389 Delay is measured the same regardless of the type of DUT/SUT. 390 Latency [1] require some knowledge of whether the DUT/SUT is 391 a "store and forward" or a "bit forwarding" device. The fact 392 that a DUT/SUT's technology has a lower delay than another 393 technology should be visible. 395 By specifying the metric to be inside the Internet protocol, 396 the tester is relieved from specifying the start/end for 397 every data link layer protocol that IP runs on. This avoids 398 determining if the start/end delimiters are included in the 399 frame. Also heterogeneous data link protocol can be used in 400 a test. 402 The measurement point at the end closely simulates the way an 403 internet datagram is processed. An internet datagram is not 404 Network-layer Traffic Control Mechanisms 406 passed up or down the stack unless it is complete. 407 Completion occurs once the last bit of the IP packet has been 408 received. 410 Delay can be run at any offered load. Recommend at or below 411 the channel capacity for non-congested delay. For congested 412 delay, run the offered load above the channel capacity. 414 Measurement units: 415 Seconds. 417 See Also: 418 Latency [1] 420 3.2.6 Undifferentiated Response 422 Definition: 423 The vector(s) obtained when mechanisms used to support diff- 424 serv or IP precedence are disabled. 426 Discussion: 427 Enabling diff-serv or IP precedence mechanisms may impose 428 additional processing overhead for packets. This overhead may 429 degrade performance even when traffic belonging to only one 430 class, the best-effort class, is offered to the device. 432 Measurements with "undifferentiated response" should be made 433 to establish a baseline. 435 The vector(s) obtained with DSCPs or IP precedence enabled 436 can be compared to the undifferentiated response to determine 437 the effect of differentiating traffic. 439 Measurement units: 440 n/a 442 3.3 Sequence Tracking 444 3.3.1 In-sequence Packet 446 Definition: 447 A received packet with the expected Test Sequence number. 449 Discussion: 450 In-sequence is done on a stream level. As packets are 451 received on a stream, each packet's Test Sequence number is 452 compared with the previous packet. Only packets that match 453 the expected are considered in-sequence. 455 Network-layer Traffic Control Mechanisms 457 Packets that do not match the expected Test Sequence number 458 are counted as _not in-sequence_ or out-of-sequence. Every 459 packet that is received is either in-sequence or out-of- 460 sequence. Subtracting the in-sequence from the received 461 packets (for that stream) can derive the out-of-sequence 462 count. 464 Two types of events will prevent the in-sequence from 465 incrementing: packet loss and reordered packets. 467 Measurement units: 468 Packet count 470 See Also: 471 Stream 472 Test Sequence number 474 3.3.2 Out-of-order Packet 476 Definition: 477 A received packet with a Test Sequence number less that 478 expected. 480 Discussion: 481 As a stream of packets enter a DUT/SUT, they include a Stream 482 Test Sequence number indicating the order the packets were 483 sent to the DUT/SUT. On exiting the DUT/SUT, these packets 484 may arrive in a different order. Each packet that was re- 485 ordered is counted as an Out-of-order Packet. 487 Certain streaming protocol (such as TCP) require the packets 488 to be in a certain order. Packets outside this are dropped 489 by the streaming protocols even though there were properly 490 received by the IP layer. The type of reordering tolerated 491 by a streaming protocol varies from protocol to protocol, and 492 also by implementation. 494 Out-of-order Packet count is based on the worst case 495 streaming protocol. It allows for no reordering. 497 Packet loss does not affect the Out-of-order Packet count. 498 Only packets that were not received in the order that they 499 were transmitted. 501 Measurement units: 502 Packet count 504 See Also: 505 Stream 506 Test Sequence number 507 Network-layer Traffic Control Mechanisms 509 3.3.3 Duplicate Packet 511 Definition: 512 A received packet with a Test Sequence number matching a 513 previously received packet. 515 Discussion: 517 Measurement units: 518 Packet count 520 See Also: 521 Stream 522 Test Sequence number 524 3.3.4 Stream 526 Definition: 527 A group of packets tracked as a single entity by the traffic 528 receiver. A stream may share a common content such as type 529 (IP, UDP), packet size, or payload. 531 Discussion: 532 Streams are tracked by test sequence number or "unique 533 signature field" (RFC 2889). Streams define how individual 534 packet's statistics are grouped together to form an 535 intelligible summary. 537 Common stream groupings would be by egress interface, 538 destination address, source address, DSCP, or IP precedence. 539 A stream using test sequence numbers can track the ordering 540 of packets as they transverse the DUT/SUT. 542 Streams are not restricted to a pair of source and 543 destination interfaces as long as all packets are tracked as 544 a single entity. A mulitcast stream can be forward to 545 multiple destination interfaces. 547 Measurement units: 548 n/a 550 See Also: 551 Flow 552 MicroFlow [3] 553 Test sequence number 554 Network-layer Traffic Control Mechanisms 556 3.3.6 Test Sequence number 558 Definition: 559 A field in the IP payload portion of the packet that is used 560 to verify the order of the packets on the egress of the 561 DUT/SUT. 563 Discussion: 564 The traffic generator sets the test sequence number value and 565 the traffic receiver checks the value upon receipt of the 566 packet. The traffic generator changes the value on each 567 packet transmitted based on an algorithm agreed to by the 568 traffic receiver. 570 The traffic receiver keeps track of the sequence numbers on a 571 per stream basis. In addition to number of received packets, 572 the traffic receiver may also report number of in-sequence 573 packets, number of out-sequence packets, number of duplicate 574 packets, and number of reordered packets. 576 The recommended algorithm to use to change the sequence 577 number on sequential packets is an incrementing value. 579 Measurement units: 580 n/a 582 See Also: 583 Stream 585 3.4 Vectors 586 A vector is a group of packets all containing a specific DSCP 587 or IP precedence value. Vectors are expressed as a pair of 588 numbers. The first is being the particular diff-serv value. 589 The second is the metric expressed as a rate, loss 590 percentage, delay, or jitter. 592 3.4.1 Intended Vector 594 Definition: 596 A vector describing the rate at which packets having a 597 specific code-point (or IP precedence) that an external 598 source attempts to transmit to a DUT/SUT. 600 Discussion: 601 Intended loads across the different code-point classes 602 determine the metrics associated with a specific code-point 603 traffic class. 605 Network-layer Traffic Control Mechanisms 607 Measurement Units: 608 N-octets packets per second 610 See Also: 611 Offered Vector 612 Expected Forwarding Vector 613 Expected Loss Vector 614 Expected Sequence Vector 615 Expected Delay Vector 616 Expected Jitter Vector 617 Forwarding Vector 618 Loss Vector 620 3.4.2 Offered Vector 622 Definition: 623 A vector describing the measured rate at which packets having 624 a specific DSCP or IP precedence value are offered to the 625 DUT/SUT. 627 Discussion: 628 Offered loads across the different code-point classes, 629 constituting a code-point set, determine the metrics 630 associated with a specific code-point traffic class. 632 Measurement Units: 633 N-octets packets per second 635 See Also: 636 Expected Forwarding Vector 637 Expected Loss Vector 638 Expected Sequence Vector 639 Expected Delay Vector 640 Expected Jitter Vector 641 Forwarding Vector 642 Codepoint Set 644 3.4.3 Expected Vectors 646 3.4.3.1 Expected Forwarding Vector 648 Definition: 649 A vector describing the expected output rate of packets 650 having a specific DSCP or IP precedence value. The value is 651 dependent on the set of offered vectors and configuration of 652 the DUT. 654 Discussion: 656 Network-layer Traffic Control Mechanisms 658 The DUT is configured in a certain way in order that service 659 differentiation occurs for a particular DSCP or IP precedence 660 value when a specific traffic mix consisting of multiple 661 DSCPs or IP precedence values are applied. This term attempts 662 to capture the expected forwarding behavior when subjected to 663 a certain offered vectors. 665 The actual algorithm or mechanism the DUT uses to achieve 666 service differentiation is not important in describing the 667 expected forwarding vector. 669 Measurement units: 670 N-octet packets per second 672 See Also: 673 Intended Vector 674 Offered Vector 675 Output Vectors 676 Expected Loss Vector 677 Expected Sequence Vector 678 Expected Delay Vector 679 Expected Jitter Vector 681 3.4.3.2 Expected Loss Vector 683 Definition: 684 A vector describing the percentage of packets, having a 685 specific DSCP or IP precedence value, that should not be 686 forwarded. The value is dependent on the set of offered 687 vectors and configuration of the DUT. 689 Discussion: 690 The DUT is configured in a certain way in order that service 691 differentiation occurs for a particular DSCP or IP precedence 692 value when a specific traffic mix consisting of multiple 693 DSCPs or IP precedence values are applied. This term attempts 694 to capture the expected forwarding behavior when subjected to 695 a certain offered vectors. 697 The actual algorithm or mechanism the DUT uses to achieve 698 service differentiation is not important in describing the 699 expected loss vector. 701 Measurement Units: 702 Percentage of intended packets that are expected to be 703 dropped. 705 See Also: 706 Intended Vector 707 Offered Vector 708 Expected Forwarding Vector 709 Network-layer Traffic Control Mechanisms 711 Expected Sequence Vector 712 Expected Delay Vector 713 Expected Jitter Vector 715 3.2.3.3 Expected Sequence Vector 717 Definition: 718 A vector describing the expected in-sequence packets having a 719 specific DSCP or IP precedence value. The value is dependent 720 on the set of offered vectors and configuration of the DUT. 722 Discussion: 723 The DUT is configured in a certain way in order that service 724 differentiation occurs for a particular DSCP or IP precedence 725 value when a specific traffic mix consisting of multiple 726 DSCPs or IP precedence values are applied. This term attempts 727 to capture the expected forwarding behavior when subjected to 728 a certain offered vectors. 730 The actual algorithm or mechanism the DUT uses to achieve 731 service differentiation is not important in describing the 732 expected sequence vector. 734 Measurement Units: 735 N-octet packets per second 737 See Also: 738 Intended Vector 739 Offered Vector 740 Output Vectors 741 Expected Loss Vector 742 Expected Forwarding Vector 743 Expected Delay Vector 744 Expected Jitter Vector 746 3.4.3.4 Expected Instantaneous Delay Vector 748 Definition: 749 A vector describing the expected delay for packets having a 750 specific DSCP or IP precedence value. The value is dependent 751 on the set of offered vectors and configuration of the DUT. 753 Discussion: 754 The DUT is configured in a certain way in order that service 755 differentiation occurs for a particular DSCP or IP precedence 756 value when a specific traffic mix consisting of multiple 757 DSCPs or IP precedence values are applied. This term attempts 758 to capture the expected forwarding behavior when subjected to 759 a certain offered vectors. 761 Network-layer Traffic Control Mechanisms 763 The actual algorithm or mechanism the DUT uses to achieve 764 service differentiation is not important in describing the 765 expected delay vector. 767 Measurement units: 768 Seconds. 770 See Also: 771 Intended Vector 772 Offered Vector 773 Output Vectors 774 Expected Loss Vector 775 Expected Sequence Vector 776 Expected Forwarding Vector 777 Expected Jitter Vector 779 3.4.3.5 Expected Average Delay Vector 781 Definition: 782 A vector describing the expected average delay for packets 783 having a specific DSCP or IP precedence value. The value is 784 dependent on the set of offered vectors and configuration of 785 the DUT. 787 Discussion: 788 The DUT is configured in a certain way in order that service 789 differentiation occurs for a particular DSCP or IP precedence 790 value when a specific traffic mix consisting of multiple 791 DSCPs or IP precedence values are applied. This term attempts 792 to capture the expected forwarding behavior when subjected to 793 a certain offered vectors. 795 The actual algorithm or mechanism the DUT uses to achieve 796 service differentiation is not important in describing the 797 expected average delay vector. 799 Measurement units: 800 Seconds. 802 See Also: 803 Intended Vector 804 Offered Vector 805 Output Vectors 806 Expected Loss Vector 807 Expected Sequence Vector 808 Expected Forwarding Vector 809 Expected Jitter Vector 810 Network-layer Traffic Control Mechanisms 812 3.4.3.6 Expected Maximum Delay Vector 814 Definition: 815 A vector describing the expected maximum delay for packets 816 having a specific DSCP or IP precedence value. The value is 817 dependent on the set of offered vectors and configuration of 818 the DUT. 820 Discussion: 821 The DUT is configured in a certain way in order that service 822 differentiation occurs for a particular DSCP or IP precedence 823 value when a specific traffic mix consisting of multiple 824 DSCPs or IP precedence values are applied. This term attempts 825 to capture the expected forwarding behavior when subjected to 826 a certain offered vectors. 828 The actual algorithm or mechanism the DUT uses to achieve 829 service differentiation is not important in describing the 830 expected maximum delay vector. 832 Measurement units: 833 Seconds. 835 See Also: 836 Intended Vector 837 Offered Vector 838 Output Vectors 839 Expected Loss Vector 840 Expected Sequence Vector 841 Expected Forwarding Vector 842 Expected Jitter Vector 844 3.4.3.7 Expected Minimum Delay Vector 846 Definition: 847 A vector describing the expected minimum delay for packets 848 having a specific DSCP or IP precedence value. The value is 849 dependent on the set of offered vectors and configuration of 850 the DUT. 852 Discussion: 853 The DUT is configured in a certain way in order that service 854 differentiation occurs for a particular DSCP or IP precedence 855 value when a specific traffic mix consisting of multiple 856 DSCPs or IP precedence values are applied. This term attempts 857 to capture the expected forwarding behavior when subjected to 858 a certain offered vectors. 860 The actual algorithm or mechanism the DUT uses to achieve 861 service differentiation is not important in describing the 862 expected minimum delay vector. 864 Network-layer Traffic Control Mechanisms 866 Measurement units: 867 Seconds. 869 See Also: 870 Intended Vector 871 Offered Vector 872 Output Vectors 873 Expected Loss Vector 874 Expected Sequence Vector 875 Expected Forwarding Vector 876 Expected Jitter Vector 878 3.2.3.8 Expected Instantaneous Delay Variation Vector 880 Definition: 881 A vector describing the expected variation in the delay of 882 two consecutive packets' arrival times having a specific DSCP 883 or IP precedence value. The value is dependent on the set of 884 offered vectors and configuration of the DUT. 886 Discussion: 887 Instantaneous Delay Variation is the absolute value of the 888 difference between the delay measurement of two packets 889 belonging to the same stream. 891 The delay fluctuation between two consecutive packets in a 892 stream is reported as the "Instantaneous Delay Variation". 893 Instantaneous Delay Variation can be expressed as |D(i) - 894 D(i-1)| where D equals the delay and i is the test sequence 895 number. Packets lost are not counted in the measurement. 897 Forwarding Vector may contain several Instantaneous Delay 898 Variation Vectors. For n packets received in a Forwarding 899 Vector, there is n-1 several Instantaneous Delay Variation 900 Vectors. 902 Measurement units: 903 Seconds 905 See Also: 906 Delay 907 Offered Vector 908 Output Vectors 909 Expected Average Delay Variation Vector 910 Expected Peak-to-peak Delay Variation Vector 911 Stream 912 Network-layer Traffic Control Mechanisms 914 3.2.3.9 Expected Average Delay Variation Vector 916 Definition: 917 A vector describing the expected average variation in the 918 delay of packet arrival times for packets having specific 919 DSCP or IP precedence value. The value is dependent on the 920 set of offered vectors and configuration of the DUT. 922 Discussion: 923 Average Delay Variation is the average of all the 924 Instantaneous Delay Variation Vectors measured during the 925 test duration. 927 Measurement units: 928 Seconds 930 See Also: 931 Intended Vector 932 Offered Vector 933 Output Vectors 934 Expected Instantaneous Delay Variation Vector 935 Expected Peak-to-peak Delay Variation Vector 937 3.2.3.10 Expected Peak-to-peak Delay Variation Vector 939 Definition: 940 A vector describing the expected maximum variation in the 941 delay of packet arrival times for packets having specific 942 DSCP or IP precedence value. The value is dependent on the 943 set of offered vectors and configuration of the DUT. 945 Discussion: 946 Peak-to-peak Delay Variation Vector is the maximum delay 947 minus the minimum delay of the packets (in a vector) 948 forwarded by the DUT/SUT. 950 Peak-to-peak Delay Variation is not derived from the 951 Instantaneous Delay Variation Vector. Peak-to-peak Delay 952 Variation is based upon all the packets during the test 953 duration, not just two consecutive packets. 955 Measurement units: 956 Seconds 958 See Also: 959 Intended Vector 960 Offered Vector 961 Output Vectors 962 Expected Instantaneous Delay Variation Vector 963 Expected Average Delay Variation Vector 964 Network-layer Traffic Control Mechanisms 966 3.4.4 Output Vectors 968 3.4.4.1 Forwarding Vector 970 Definition: 971 The number of packets per second for all packets containing a 972 specific DSCP or IP precedence value that a device can be 973 observed to successfully forward to the correct destination 974 interface in response to an offered vector. 976 Discussion: 977 Forwarding Vector is expressed as pair of numbers. Both the 978 specific DSCP (or IP precedence) value AND the packets per 979 second value combine to make a vector. 981 The Forwarding Vector represents packet rate based on its 982 specific DSCP (or IP precedence) value. It is not 983 necessarily based on a stream or flow. The Forwarding Vector 984 may be expressed as per port of the DUT/SUT. However, it must 985 be consistent with the Expected Forwarding Vector. 987 Forwarding Vector is a per-hop measurement. The DUT/SUT may 988 change the specific DSCP (or IP precedence) value for a 989 multiple-hop measurement. 991 Measurement units: 992 N-octet packets per second 994 See Also: 995 Intended Vector 996 Offered Vector 997 Expected Vectors 998 Loss Vector 999 Sequence Vector 1000 Delay Vectors 1002 3.4.4.2 Loss Vector 1004 Definition: 1005 The percentage of packets containing specific DSCP or IP 1006 precedence value that a DUT/SUT did not transmit to the 1007 correct destination interface in response to an offered 1008 vector. 1010 Discussion: 1011 Loss Vector is expressed as pair of numbers. Both the 1012 specific DSCP (or IP precedence) value AND the percentage 1013 value combine to make a vector. 1015 Network-layer Traffic Control Mechanisms 1017 The Loss Vector represents percentage based on a specific 1018 DSCP or IP precedence value. It is not necessarily based on 1019 a stream or flow. The Loss Vector may be expressed as per 1020 port of the DUT/SUT. However, it must be consistent with the 1021 Expected Loss Vector 1023 Loss Vector is a per-hop measurement. The DUT/SUT may change 1024 the specific DSCP or IP precedence value for a multiple-hop 1025 measurement. 1027 Measurement Units: 1028 Percentage of offered packets that are not forwarded. 1030 See Also: 1031 Intended Vector 1032 Offered Vector 1033 Expected Vectors 1034 Forwarding Vector 1035 Sequence Vector 1036 Delay Vectors 1038 3.4.4.3 Sequence Vector 1040 Definition: 1041 The number of packets per second for all packets containing a 1042 specific DSCP or IP precedence value that a device can be 1043 observed to transmit in sequence to the correct destination 1044 interface in response to an offered vector. 1046 Discussion: 1047 Sequence Vector is expressed as pair of numbers. Both the 1048 specific DSCP (or IP precedence) value AND the packets per 1049 second value combine to make a vector. 1051 The Sequence Vector represents packet rate based on its 1052 specific DSCP or IP precedence value. It is not necessarily 1053 based on a stream or flow. The Sequence Vector may be 1054 expressed as per port of the DUT/SUT. However, it must be 1055 consistent with the Expected Sequence Vector. 1057 Sequence Vector is a per-hop measurement. The DUT/SUT may 1058 change the specific DSCP or IP precedence value for a 1059 multiple-hop measurement. 1061 Measurement Units: 1062 N-octet packets per second 1064 Issues: 1066 See Also: 1067 In-sequence Packet 1068 Network-layer Traffic Control Mechanisms 1070 Intended Vector 1071 Offered Vector 1072 Expected Vectors 1073 Loss Vector 1074 Forwarding Vector 1075 Delay Vectors 1077 3.4.4.4 Instantaneous Delay Vector 1079 Definition: 1080 The delay for a packet containing specific DSCP or IP 1081 precedence value that a device can be observed to 1082 successfully transmit to the correct destination interface in 1083 response to an offered vector. 1085 Discussion: 1086 Instantaneous Delay vector is expressed as pair of numbers. 1087 Both the specific DSCP (or IP precedence) value AND delay 1088 value combine to make a vector. 1090 The Instantaneous Delay Vector represents delay on its 1091 specific DSCP or IP precedence value. It is not necessarily 1092 based on a stream or flow. The Delay vector may be expressed 1093 as per port of the DUT/SUT. However, it must be consistent 1094 with the Expected Delay vectors. 1096 Instantaneous Delay Vector is a per-hop measurement. The 1097 DUT/SUT may change the specific DSCP or IP precedence value 1098 for a multiple-hop measurement. 1100 Instantaneous Delay vector can be obtained at any offered 1101 load. Recommend at or below the channel capacity in the 1102 absence of congestion. For congested delay, run the offered 1103 load above the channel capacity. 1105 Forwarding Vector may contain several Instantaneous Delay 1106 Vectors. For every packet received in a Forwarding Vector, 1107 there is a corresponding Instantaneous Delay Vector. 1109 Measurement Units: 1110 Seconds 1112 See Also: 1113 Delay 1114 Intended Vector 1115 Offered Vector 1116 Expected Delay Vectors 1117 Average Delay Vector 1118 Maximum Delay Vector 1119 Minimum Delay Vector 1120 Network-layer Traffic Control Mechanisms 1122 3.4.4.5 Average Delay Vector 1124 Definition: 1125 The average delay for packets containing specific DSCP or IP 1126 precedence value that a device can be observed to 1127 successfully transmit to the correct destination interface in 1128 response to an offered vector. 1130 Discussion: 1131 Average Delay vector is expressed as pair of numbers. Both 1132 the specific DSCP (or IP precedence) value AND delay value 1133 combine to make a vector. 1135 The Delay Vector represents delay on its specific DSCP or IP 1136 precedence value. It is not necessarily based on a stream or 1137 flow. The Delay vector may be expressed as per port of the 1138 DUT/SUT. However, it must be consistent with the Expected 1139 Delay vector. 1141 The Average Delay Vector is computed by averaging all the 1142 Instantaneous Delay Vectors for a given vector. 1144 Average Delay Vector is a per-hop measurement. The DUT/SUT 1145 may change the specific DSCP or IP precedence value for a 1146 multiple-hop measurement. 1148 Average Delay vector can be obtained at any offered load. 1149 Recommend at or below the channel capacity in the absence of 1150 congestion. For congested delay, run the offered load above 1151 the channel capacity. 1153 Measurement Units: 1154 Seconds 1156 See Also: 1157 Delay 1158 Intended Vector 1159 Offered Vector 1160 Expected Delay Vectors 1161 Instantaneous Delay Vector 1162 Maximum Delay Vector 1163 Minimum Delay Vector 1165 3.4.4.6 Maximum Delay Vector 1167 Definition: 1168 The maximum delay from all packets containing specific DSCP 1169 or IP precedence value that a device can be observed to 1170 successfully transmit to the correct destination interface in 1171 response to an offered vector. 1173 Network-layer Traffic Control Mechanisms 1175 Discussion: 1176 Maximum Delay vector is expressed as pair of numbers. Both 1177 the specific DSCP (or IP precedence) value AND delay value 1178 combine to make a vector. 1180 The Maximum Delay Vector represents delay on its specific 1181 DSCP or IP precedence value. It is not necessarily based on 1182 a stream or flow. The Maximum Delay vector may be expressed 1183 as per port of the DUT/SUT. However, it must be consistent 1184 with the Expected Delay vector. 1186 Maximum Delay Vector is based upon the maximum Instantaneous 1187 Delay Vector of all packets in a Forwarding Vector. 1189 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1190 may change the specific DSCP or IP precedence value for a 1191 multiple-hop measurement. 1193 Measurement Units: 1194 Seconds 1196 See Also: 1197 Delay 1198 Intended Vector 1199 Offered Vector 1200 Expected Delay Vectors 1201 Instantaneous Delay Vector 1202 Forwarding Vector 1203 Average Delay Vector 1204 Minimum Delay Vector 1206 3.4.4.7 Minimum Delay Vector 1208 Definition: 1209 The minimum delay from all packets containing specific DSCP 1210 or IP precedence value that a device can be observed to 1211 successfully transmit to the correct destination interface in 1212 response to an offered vector. 1214 Discussion: 1215 Delay vector is expressed as pair of numbers. Both the 1216 specific DSCP (or IP precedence) value AND delay value 1217 combine to make a vector. 1219 The Minimum Delay Vector represents delay on its specific 1220 DSCP or IP precedence value. It is not necessarily based on 1221 a stream or flow. The Minimum Delay vector may be expressed 1222 as per port of the DUT/SUT. However, it must be consistent 1223 with the Expected Delay vector. 1225 Network-layer Traffic Control Mechanisms 1227 Minimum Delay Vector is based upon the minimum Instantaneous 1228 Delay Vector of all packets in a Forwarding Vector. 1230 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1231 may change the specific DSCP or IP precedence value for a 1232 multiple-hop measurement. 1234 Minimum Delay vector can be obtained at any offered load. 1235 Recommend at or below the channel capacity in the absence of 1236 congestion. For congested delay, run the offered load above 1237 the channel capacity. 1239 Measurement Units: 1240 Seconds 1242 See Also: 1243 Delay 1244 Intended Vector 1245 Offered Vector 1246 Expected Delay Vectors 1247 Instantaneous Delay Vector 1248 Forwarding Vector 1249 Average Delay Vector 1250 Maximum Delay Vector 1252 3.4.4.8 Instantaneous Delay Variation Vector 1254 Definition: 1255 The variation in the delay for two consecutive packets 1256 containing specific DSCP or IP precedence value that a device 1257 can be observed to successfully transmit to the correct 1258 destination interface in response to an offered vector. 1260 Discussion: 1261 Instantaneous Delay Variation is the absolute value of the 1262 difference between the delay measurement of two packets 1263 belonging to the same stream. 1265 Jitter vector is expressed as pair of numbers. Both the 1266 specific DSCP (or IP precedence) value AND jitter value 1267 combine to make a vector. 1269 The delay fluctuation between two consecutive packets in a 1270 stream is reported as the "Instantaneous Delay Variation". 1271 Instantaneous Delay Variation can be expressed as |D(i) - 1272 D(i-1)| where D equals the delay and i is the test sequence 1273 number. Packets lost are not counted in the measurement. 1275 Network-layer Traffic Control Mechanisms 1277 Instantaneous Delay Variation Vector is a per-hop 1278 measurement. The DUT/SUT may change the specific DSCP or IP 1279 precedence value for a multiple-hop measurement. 1281 Forwarding Vector may contain several Instantaneous Delay 1282 Variation Vectors. For n packets received in a Forwarding 1283 Vector, there is n-1 several Instantaneous Delay Variation 1284 Vectors. 1286 Measurement units: 1287 Seconds 1289 See Also: 1290 Delay 1291 Forwarding Vector 1292 Stream 1293 Expected Vectors 1294 Average Delay Variation Vector 1295 Peak-to-peak Delay Variation Vector 1297 3.4.4.9 Average Delay Variation Vector 1299 Definition: 1300 The average variation in the delay for packets containing 1301 specific DSCP or IP precedence value that a device can be 1302 observed to successfully transmit to the correct destination 1303 interface in response to an offered vector. 1305 Discussion: 1306 Average Delay Variation is the average of all the 1307 Instantaneous Delay Variation Vectors measured during the 1308 test duration. 1310 Average Delay Variation vector is expressed as pair of 1311 numbers. Both the specific DSCP (or IP precedence) value AND 1312 jitter value combine to make a vector. 1314 Average Delay Variation vector is a per-hop measurement. The 1315 DUT/SUT may change the specific DSCP or IP precedence value 1316 for a multiple-hop measurement. 1318 Measurement units: 1319 Seconds 1321 See Also: 1322 Delay 1323 Forwarding Vector 1324 Stream 1325 Expected Vectors 1326 Instantaneous Delay Variation Vector 1327 Peak-to-peak Delay Variation Vector 1328 Network-layer Traffic Control Mechanisms 1330 3.4.4.10 Peak-to-peak Delay Variation Vector 1332 Definition: 1333 The maximum possible variation in the delay for packets 1334 containing specific DSCP or IP precedence value that a device 1335 can be observed to successfully transmit to the correct 1336 destination interface in response to an offered vector. 1338 Discussion: 1339 Peak-to-peak Delay Variation Vector is the maximum delay 1340 minus the minimum delay of the packets (in a vector) 1341 forwarded by the DUT/SUT. 1343 Delay Variation vector is expressed as pair of numbers. Both 1344 the specific DSCP (or IP precedence) value AND jitter value 1345 combine to make a vector. 1347 Peak-to-peak Delay Variation is not derived from the 1348 Instantaneous Delay Variation Vector. Peak-to-peak Delay 1349 Variation is based upon all the packets during the test 1350 duration, not just two consecutive packets. 1352 Measurement units: 1353 Seconds 1355 See Also: 1356 Delay 1357 Forwarding Vector 1358 Stream 1359 Expected Vectors 1360 Average Delay Variation Vector 1361 Peak-to-peak Delay Variation Vector 1362 Network-layer Traffic Control Mechanisms 1364 4. Security Considerations 1366 Documents of this type do not directly affect the security of 1367 the Internet or of corporate networks as long as benchmarking 1368 is not performed on devices or systems connected to 1369 production networks. 1371 Packets with unintended and/or unauthorized DSCP or IP 1372 precedence values may present security issues. Determining 1373 the security consequences of such packets is out of scope for 1374 this document. 1376 5. References 1378 [1] Bradner, S., Editor, "Benchmarking Terminology for 1379 Network Interconnection Devices", RFC 1242, July 1991. 1381 [2] Mandeville, R., "Benchmarking Terminology for LAN 1382 Switching Devices", RFC 2285, February 1998. 1384 [3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of 1385 the Differentiated Services Field (DS Field) in the IPv4 1386 and IPv6 Headers", RFC 2474, December 1998. 1388 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 1389 Weiss, "An Architecture for Differentiated Services", RFC 1390 2475, December 1998. 1392 Network-layer Traffic Control Mechanisms 1394 6. Authors' Address 1396 Jerry Perser 1397 Spirent Communications 1398 26750 Agoura Road 1399 Calabasas, CA 91302 1400 USA 1402 Phone: + 1 818 676 2300 1403 EMail: jerry.perser@spirentcom.com 1405 David Newman 1406 Network Test 1407 31324 Via Colinas, Suite 113 1408 Westlake Village, CA 91362 1409 USA 1411 Phone: + 1 818 889 0011, x10 1412 EMail: dnewman@networktest.com 1414 Sumit Khurana 1415 Telcordia Technologies 1416 445 South Street 1417 Morristown, NJ 07960 1418 USA 1420 Phone: + 1 973 829 3170 1421 EMail: sumit@research.telcordia.com 1423 Shobha Erramilli 1424 QNetworx Inc 1425 1119 Campus Drive West 1426 Morganville NJ 07751 1427 USA 1429 Phone: 1430 EMail: shobha@qnetworx.com 1432 Scott Poretsky 1433 Avici Systems 1434 101 Billerica Ave_Building #6 1435 N. Billerica, MA 01862 1436 USA 1438 Phone: + 1 978 964 2287 1439 EMail: sporetsky@avici.com 1440 Network-layer Traffic Control Mechanisms 1442 7. Full Copyright Statement 1444 Copyright (C) The Internet Society (1998). All Rights 1445 Reserved. 1447 This document and translations of it may be copied and 1448 furnished to others, and derivative works that comment on or 1449 otherwise explain it or assist in its implementation may be 1450 prepared, copied, published and distributed, in whole or in 1451 part, without restriction of any kind, provided that the 1452 above copyright notice and this paragraph are included on all 1453 such copies and derivative works. However, this document 1454 itself may not be modified in any way, such as by removing 1455 the copyright notice or references to the Internet Society or 1456 other Internet organizations, except as needed for the 1457 purpose of developing Internet standards in which case the 1458 procedures for copyrights defined in the Internet Standards 1459 process must be followed, or as required to translate it into 1460 languages other than English. 1462 The limited permissions granted above are perpetual and will 1463 not be revoked by the Internet Society or its successors or 1464 assigns. This document and the information contained herein 1465 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1466 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1467 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1468 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1469 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1470 FITNESS FOR A PARTICULAR PURPOSE.