idnits 2.17.1 draft-ietf-bmwg-dsmterm-09.txt: -(541): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(2212): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 12 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 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 (October 2003) is 7491 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 3239, 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: 4 errors (**), 0 flaws (~~), 5 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 4 Expires in: April 2004 Scott Poretsky 5 Quarry Technologies 6 Shobha Erramilli 7 Qnetworx 8 Sumit Khurana 9 Telcordia 11 October 2003 13 Terminology for Benchmarking Network-layer 14 Traffic Control Mechanisms 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 This document describes terminology for the benchmarking of 47 devices that implement traffic control based on IP precedence or 48 diff-serv code point criteria. 50 Network-layer Traffic Control Mechanisms 52 Table of Contents 54 1. Introduction .............................................. 3 55 2. Existing definitions ...................................... 3 56 3. Term definitions............................................4 57 3.1 Configuration Terms 58 3.1.1 Classification.........................................4 59 3.1.2 Codepoint Set..........................................4 60 3.1.3 Forwarding Congestion..................................5 61 3.1.4 Congestion Management..................................6 62 3.1.5 Flow...................................................7 63 3.2 Measurement Terms 64 3.2.1 Forwarding Capacity....................................7 65 3.2.2 Conforming Packet......................................8 66 3.2.3 Nonconforming Packet...................................9 67 3.2.4 Forwarding Delay.......................................9 68 3.2.5 Jitter................................................11 69 3.2.6 Undifferentiated Response.............................11 70 3.3 Sequence Tracking 71 3.3.1 In-sequence Packet....................................12 72 3.3.2 Out-of-order Packet...................................12 73 3.3.3 Duplicate Packet......................................13 74 3.3.4 Stream................................................14 75 3.3.5 Test Sequence number .................................15 76 3.4 Vectors...................................................15 77 3.4.1 Intended Vector.......................................15 78 3.4.2 Offered Vector........................................16 79 3.4.3 Expected Vectors 80 3.4.3.1 Expected Forwarding Vector........................16 81 3.4.3.2 Expected Loss Vector..............................17 82 3.4.3.3 Expected Sequence Vector..........................18 83 3.4.3.4 Expected Instantaneous Delay Vector...............18 84 3.4.3.5 Expected Average Delay Vector.....................19 85 3.4.3.6 Expected Maximum Delay Vector.....................10 86 3.4.3.7 Expected Minimum Delay Vector.....................20 87 3.4.3.8 Expected Instantaneous Jitter Vector..............21 88 3.4.3.9 Expected Average Jitter Vector....................22 89 3.4.3.10 Expected Peak-to-peak Jitter Vector..............22 90 3.4.4 Output Vectors 91 3.4.4.1 Forwarding Vector.................................23 92 3.4.4.2 Loss Vector.......................................24 93 3.4.4.3 Sequence Vector...................................24 94 3.4.4.4 Instantaneous Delay Vector........................25 95 3.4.4.5 Average Delay Vector..............................26 96 3.4.4.6 Maximum Delay Vector..............................27 97 3.4.4.7 Minimum Delay Vector..............................28 98 3.4.4.8 Instantaneous Jitter Vector.......................28 99 3.4.4.9 Average Jitter Vector.............................29 100 3.4.4.10 Peak-to-peak Jitter Vector.......................30 101 4. Acknowledgments............................................31 102 5. Security Considerations....................................31 103 6. Normative References.......................................31 104 Network-layer Traffic Control Mechanisms 106 7. Informative References.....................................32 107 8. Author's Address...........................................33 108 9. Full Copyright Statement...................................34 110 1. Introduction 112 New terminology is needed because most existing measurements 113 assume the absence of congestion and only a single per-hop- 114 behavior. This document introduces several new terms that will 115 allow measurements to be taken during periods of congestion. 117 Another key difference from existing terminology is the definition 118 of measurements as observed on egress as well as ingress of a 119 device/system under test. Again, the existence of congestion 120 requires the addition of egress measurements as well as those 121 taken on ingress; without observing traffic leaving a 122 device/system it is not possible to say whether traffic-control 123 mechanisms effectively dealt with congestion. 125 The principal measurements introduced in this document are vectors 126 for rate, delay, and jitter, all of which can be observed with or 127 without congestion of the DUT/SUT. 129 This document describes only those terms relevant to measuring 130 behavior of a device or a group of devices using one of these two 131 mechanisms. End-to-end and service-level measurements are beyond 132 the scope of this document. 134 2. Existing definitions 136 RFC 1242 "Benchmarking Terminology for Network Interconnect 137 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 138 Devices" should be consulted before attempting to make use of this 139 document. 141 RFC 2474 "Definition of the Differentiated Services Field (DS 142 Field) in the IPv4 and IPv6 Headers" section 2, contains 143 discussions of a number of terms relevant to network-layer traffic 144 control mechanisms and should also be consulted. 146 For the sake of clarity and continuity this RFC adopts the 147 template for definitions set out in Section 2 of RFC 1242. 148 Definitions are indexed and grouped together in sections for ease 149 of reference. 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 152 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in 154 RFC 2119 [Br97]. 156 Network-layer Traffic Control Mechanisms 158 3. Term definitions 160 3.1 Configuration Terms 162 3.1.1 Classification 164 Definition: 165 Selection of packets based on the contents of packet header 166 according to defined rules. 168 Discussion: 169 Packets can be selected based on the DS field or IP 170 Precedence in the packet header. Classification can also be 171 based on Multi-Field (MF) criteria such as IP Source and 172 destination addresses, protocol and port number. 174 Classification determines the per-hop behaviors and traffic 175 conditioning functions such as shaping and dropping that are 176 to be applied to the packet. 178 Measurement units: 179 n/a 181 See Also: 183 3.1.2 Codepoint Set 185 Definition: 186 The set of all DS Code-points or IP precedence values used 187 during the test duration. 189 Discussion: 190 Describes all the code-point markings associated with packets 191 that are input to the DUT/SUT. For each entry in the 192 codepoint set, there are associated vectors describing the 193 rate of traffic, delay, loss, or jitter containing that 194 particular DSCP or IP precedence value. 196 The treatment that a packet belonging to a particular code- 197 point gets is subject to the DUT classifying packets to map 198 to the correct PHB. Moreover, the forwarding treatment in 199 general is also dependent on the complete set of offered 200 vectors. 202 Measurement Units: 203 n/a 205 See Also: 207 Network-layer Traffic Control Mechanisms 209 3.1.3 Forwarding Congestion 211 Definition: 212 A condition in which one or more egress interfaces are 213 offered more packets than are forwarded. 215 Discussion: 216 This condition is a superset of the overload definition 217 [Ma98]. Overload [Ma98] deals with overloading input and 218 output interfaces beyond the maximum transmission allowed by 219 the medium. Forwarding congestion does not assume ingress 220 interface overload as the only source of overload on output 221 interfaces. 223 Another difference between Forwarding Congestion and overload 224 occurs when the SUT comprises multiple elements, in that 225 Forwarding Congestion may occur at multiple points. Consider 226 an SUT comprising multiple edge devices exchanging traffic 227 with a single core device. Depending on traffic patterns, 228 the edge devices may induce Forwarding Congestion on multiple 229 egress interfaces on the core device. 231 Packet Loss, not increased Delay, is the metric to indicate 232 the condition of Forwarding Congestion. Packet Loss is a 233 deterministic indicator of Forwarding Congestion. While 234 increased delay may be an indicator of Forwarding Congestion, 235 it is a non-deterministic indicator of Forwarding Congestion. 236 External observation of increased delay to indicate 237 congestion is in effect external observation of Incipient 238 Congestion. 240 [Ra99] implies that it is impractical to build a black-box 241 test to externally observe Incipient Congestion indicated by 242 increased delay in a router. [Ra99] introduces Explicit 243 Congestion Notification (ECN) as the externally observable, 244 deterministic method for indicating Incipient Congestion. 245 Because [Ra99] is an Experimental RFC with limited 246 deployment, ECN is not used for this particular methodology. 247 For the purpose of "black-box" testing a DUT/SUT, Packet Loss 248 as the indicator of Forwarding Congestion is used. 250 Throughput [Br91] defines the lower boundary of Forwarding 251 Congestion. Throughput is the maximum offered rate with no 252 Forwarding Congestion. At offered rates above throughput, 253 the DUT/SUT is considered to be in a state of Forwarding 254 Congestion. 256 Network-layer Traffic Control Mechanisms 258 Ingress observations alone are not sufficient to cover all 259 cases in which Forwarding Congestion may occur. A device 260 with an infinite amount of memory could buffer an infinite 261 number of packets, and eventually forward all of them. 262 However, these packets may or may not be forwarded during the 263 test duration. Even though ingress interfaces accept all 264 packets without loss, Forwarding Congestion is present in 265 this hypothetical device. 267 Forwarding Congestion, indicated by occurrence of packet 268 loss, is one type of congestion for a DUT/SUT. Congestion 269 Collapse [Na84] is defined as the state in which buffers are 270 full and all arriving packets must be dropped across the 271 network. Incipient Congestion [Ra99] is defined as 272 congestion that produces increased delay without packet loss. 274 The definition presented here explicitly defines Forwarding 275 Congestion as an event observable on egress interfaces. 276 Regardless of internal architecture, any device that cannot 277 forward packets on one or more egress interfaces is under 278 Forwarding Congestion. 280 Measurement units: 281 none 283 See Also: 284 Gateway Congestion Control Survey [Ma91] 286 3.1.4 Congestion Management 288 Definition: 289 An implementation of one or more per-hop-behaviors to avoid 290 or minimize the condition of congestion. 292 Discussion: 293 Congestion management may seek either to control congestion 294 or avoid it altogether. Such mechanisms classify packets 295 based upon IP Precedence or DSCP settings in a packet�s IP 296 header. 298 Congestion avoidance mechanisms seek to prevent congestion 299 before it actually occurs. 301 Congestion control mechanisms give one or more flows (with a 302 discrete IP Precedence or DSCP value) preferential treatment 303 over other classes during periods of congestion. 305 Measurement units: 306 n/a 308 See Also: 310 Network-layer Traffic Control Mechanisms 312 3.1.5 Flow 314 Definition: 315 A flow is a one or more of packets sharing a common intended 316 pair of source and destination interfaces. 318 Discussion: 319 Packets are grouped by the ingress and egress interfaces they 320 use on a given DUT/SUT. 322 A flow can contain multiple source IP addresses and/or 323 destination IP addresses. All packets in a flow must enter 324 on the same ingress interface and exit on the same egress 325 interface, and have some common network layer content. 327 Microflows [Ni98] are a subset of flows. As defined in 328 [Ni98], microflows require application-to-application 329 measurement. In contrast, flows use lower-layer 330 classification criteria. Since this document focuses on 331 network-layer classification criteria, we concentrate here on 332 the use of network-layer identifiers in describing a flow. 333 Flow identifiers also may reside at the data-link, transport, 334 or application layers of the OSI model. However, identifiers 335 other than those at the network layer are out of scope for 336 this document. 338 A flow may contain a single code point/IP precedence value or 339 may contain multiple values destined for a single egress 340 interface. This is determined by the test methodology. 342 Measurement units: 343 n/a 345 See Also: 346 Microflow [Ni98] 347 Streams 349 3.2 Measurement Terms 351 3.2.1 Forwarding Capacity 353 Definition: 354 The number of packets per second that a device can be 355 observed to successfully transmit to the correct destination 356 interface in response to a specified offered load while the 357 device drops none of the offered packets. 359 Network-layer Traffic Control Mechanisms 361 Discussion: 362 Forwarding Capacity measures the packet rate at the egress 363 interface(s) of the DUT/SUT. In contrast, throughput as 364 defined in RFC 1242 measures the frame rate at the ingress 365 interface(s) of the DUT/SUT. 367 Ingress-based measurements do not account for queuing of the 368 DUT/SUT. Throughput rates can be higher than the Forwarding 369 Capacity because of queuing. The difference is dependent 370 upon test duration, packet rate, and queue size. Forwarding 371 Capacity, as an egress measurement, does take queuing into 372 account. 374 Understanding Forwarding Capacity is a necessary precursor to 375 any measurement involving Traffic Control Mechanisms. The 376 accompanying methodology document MUST take into 377 consideration Forwarding Capacity when determining the 378 expected forwarding vectors. When the sum of the expected 379 forwarding vectors on an interface exceeds the Forwarding 380 Capacity, the Forwarding Capacity will govern the forwarding 381 rate. 383 This measurement differs from forwarding rate at maximum 384 offered load (FRMOL) [Ma98] in that Forwarding Capacity 385 requires zero loss. 387 Measurement units: 388 N-octet packets per second 390 See Also: 391 Throughput [Br91] 392 Forwarding Rate at Maximum Offered Load [Ma98] 394 3.2.2 Conforming Packet 396 Definition: 397 Packets which lie within specific rate, delay, or jitter 398 bounds. 400 Discussion: 401 A DUT/SUT may be configured to allow a given traffic class to 402 consume a given amount of bandwidth, or to fall within 403 predefined delay or jitter boundaries. All packets that lie 404 within specified bounds are then said to be conforming, 405 whereas those outside the bounds are nonconforming. 407 Measurement units: 408 n/a 409 Network-layer Traffic Control Mechanisms 411 See Also: 412 Expected Vector 413 Forwarding Vector 414 Offered Vector 415 Nonconforming 417 3.2.3 Nonconforming Packet 419 Definition: 420 Packets that do not lie within specific rate, delay, or 421 jitter bounds. 423 Discussion: 424 A DUT/SUT may be configured to allow a given traffic class to 425 consume a given amount of bandwidth, or to fall within 426 predefined delay or jitter boundaries. All packets that do 427 not lie within these bounds are then said to be 428 nonconforming. 430 Measurement units: 431 n/a 433 See Also: 434 Expected Vector 435 Forwarding Vector 436 Offered Vector 437 Conforming 439 3.2.4 Forwarding Delay 441 Definition: 442 The time interval starting when the last bit of the input IP 443 packet is offered to the input port of the DUT/SUT and ending 444 when the last bit of the output IP packet is received from 445 the output port of the DUT/SUT. 447 Discussion: 448 The delay time interval MUST be externally observed. The 449 delay measurement MUST NOT include delays added by test bed 450 components other than the DUT/SUT, such as propagation time 451 introduced by cabling or non-zero delay added by the test 452 instrument. 454 Forwarding Delay differs from latency [Br91] and one-way 455 delay [Al99] in several key regards: 457 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 458 uses "store and forward" or "bit forwarding" technology. 459 Forwarding Delay is the same metric, measured the same way, 460 regardless of the architecture of the DUT/SUT. 462 Network-layer Traffic Control Mechanisms 464 2. Forwarding Delay is a last-in, last-out (LILO) 465 measurement, unlike the last-in, first-out method [Br91] or 466 the first-in, last-out method [Al99]. 468 The LILO method most closely simulates the way a network- 469 layer device actually processes an IP datagram. IP datagrams 470 are not passed up and down the stack unless they are 471 complete, and processing begins only once the last bit of the 472 IP datagram has been received. 474 Further, the LILO method has an additive property, where the 475 sum of the parts MUST equal the whole. This is a key 476 difference from [Br91] and [Al99]. For example, the delay 477 added by two DUTs MUST equal the sum of the delay of the 478 DUTs. This may or may not be the case with [Br91] and 479 [Al99]. 481 3. Forwarding Delay measures the IP datagram only, unlike 482 [Br91], which also includes link layer overhead. 484 A metric focused exclusively on the Internet protocol 485 relieves the tester from specifying the start/end for every 486 link layer protocol that IP runs on. This avoids the need to 487 determine whether the start/stop delimiters are included. It 488 also allows the use of heterogeneous link layer protocols in 489 a test. 491 4. Forwarding Delay can be measured at any offered load, 492 whereas the latency methodology [Br99] recommends measurement 493 at, and only at, the throughput level. Comparing the 494 Forwarding Delay below the throughput to Forwarding Delay 495 above the Forwarding Capacity will give insight to the 496 traffic control mechanisms. 498 For example, non-congested delay may be measured with an 499 offered load that does not exceed the Forwarding Capacity, 500 while congested delay may involve an offered load that 501 exceeds Forwarding Capacity. 503 Note: Forwarding Delay SHOULD NOT be used as an absolute 504 indicator of DUT/SUT Forwarding Congestion. While Forwarding 505 Delay may rise when offered load nears or exceeds Forwarding 506 Capacity, there is no universal point at which Forwarding 507 Delay can be said to indicate the presence or absence of 508 Forwarding Congestion. 510 Measurement units: 511 Seconds. 513 Network-layer Traffic Control Mechanisms 515 See Also: 516 Latency [Br91] 517 Latency [Al99] 518 One-way Delay [Br99] 520 3.2.5 Jitter 522 Definition: 523 The absolute value of the difference between the arrival 524 delay of two consecutive received packets belonging to the 525 same stream. 527 Discussion: 528 The delay fluctuation between two consecutive received 529 packets in a stream is reported as the jitter. Jitter can be 530 expressed as |D(i) - D(i-1)| where D equals the delay and i 531 is the order the packets were received. 533 Under loss, jitter can be measured between non-consecutive 534 test sequence numbers. When Traffic Control Mechanisms are 535 losing packets, the Forwarding Delay may fluctuate as a 536 response. Jitter MUST be able to benchmark the delay 537 variation with or with out loss. 539 Jitter is related to the ipdv [De02] (IP Delay Variation) by 540 taking the absolute value of the ipdv. The two metrics will 541 produce different mean values. �Mean Jitter� will produce a 542 positive value, where the �mean ipdv� is typically zero. 544 Measurement units: 545 Seconds 547 See Also: 548 Forwarding Delay 549 Jitter variation [Ja99] 550 ipdv [De02] 551 interarrival jitter [Sc96] 553 3.2.6 Undifferentiated Response 555 Definition: 556 The vector(s) obtained when mechanisms used to support diff- 557 serv or IP precedence are disabled. 559 Discussion: 560 Enabling diff-serv or IP precedence mechanisms may impose 561 additional processing overhead for packets. This overhead 562 may degrade performance even when traffic belonging to only 563 one class, the best-effort class, is offered to the device. 565 Network-layer Traffic Control Mechanisms 567 Measurements with "undifferentiated response" should be made 568 to establish a baseline. 570 The vector(s) obtained with DSCP or IP precedence enabled can 571 be compared to the undifferentiated response to determine the 572 effect of differentiating traffic. 574 Measurement units: 575 n/a 577 3.3 Sequence Tracking 579 3.3.1 In-sequence Packet 581 Definition: 582 A received packet with the expected Test Sequence number. 584 Discussion: 585 In-sequence is done on a stream level. As packets are 586 received on a stream, each packet�s Test Sequence number is 587 compared with the previous packet. Only packets that match 588 the expected Test Sequence number are considered in-sequence. 590 Packets that do not match the expected Test Sequence number 591 are counted as "not in-sequence" or out-of-sequence. Every 592 packet that is received is either in-sequence or out-of- 593 sequence. Subtracting the in-sequence from the received 594 packets (for that stream) can derive the out-of-sequence 595 count. 597 Two types of events will prevent the in-sequence from 598 incrementing: packet loss and reordered packets. 600 Measurement units: 601 Packet count 603 See Also: 604 Stream 605 Test Sequence number 607 3.3.2 Out-of-order Packet 609 Definition: 610 A received packet with a Test Sequence number less than 611 expected. 613 Network-layer Traffic Control Mechanisms 615 Discussion: 616 As a stream of packets enters a DUT/SUT, they include a 617 Stream Test Sequence number indicating the order the packets 618 were sent to the DUT/SUT. On exiting the DUT/SUT, these 619 packets may arrive in a different order. Each packet that 620 was re-ordered is counted as an Out-of-order Packet. 622 Certain streaming protocol (such as TCP) require the packets 623 to be in a certain order. Packets outside this are dropped 624 by the streaming protocols even though there were properly 625 received by the IP layer. The type of reordering tolerated 626 by a streaming protocol varies from protocol to protocol, and 627 also by implementation. 629 Out-of-order Packet count is based on the worst case 630 streaming protocol. It allows for no reordering. 632 Packet loss does not affect the Out-of-order Packet count. 633 Only packets that were not received in the order that they 634 were transmitted. 636 Measurement units: 637 Packet count 639 See Also: 640 Stream 641 Test Sequence number 642 Packet Reordering Metric for IPPM [Mo03] 644 3.3.3 Duplicate Packet 646 Definition: 647 A received packet with a Test Sequence number matching a 648 previously received packet. 650 Discussion: 651 A Duplicate Packet is a packet that the DUT/SUT has 652 successfully transmitted out an egress interface more than 653 once. The egress interface has previously forwarded this 654 packet. 656 A Duplicate Packet SHOULD be a bit for bit copy of an already 657 transmitted packet (including Test Sequence number). If the 658 Duplicate Packet traversed different paths through the 659 DUT/SUT, some fields (such as TTL or checksum) may have 660 changed. 662 Network-layer Traffic Control Mechanisms 664 A multicast packet is not a Duplicate Packet by definition. 665 For a given IP multicast group, a DUT/SUT SHOULD forward a 666 packet once on a given egress interface provided the path to 667 one or more multicast receivers is through that interface. 668 Several egress interfaces will transmit the same packet, but 669 only once per interface. 671 To detect a Duplicate Packet, each offered packet to the 672 DUT/SUT MUST contain a unique packet-by-packet identifier. 674 Measurement units: 675 Packet count 677 See Also: 678 Stream 679 Test Sequence number 681 3.3.4 Stream 683 Definition: 684 A group of packets tracked as a single entity by the traffic 685 receiver. A stream may share a common content such as type 686 (IP, UDP), packet size, or payload. 688 Discussion: 689 Streams are tracked by test sequence number or "unique 690 signature field" [Ma00]. Streams define how individual 691 packets� statistic are grouped together to form an 692 intelligible summary. 694 Common stream groupings would be by egress interface, 695 destination address, source address, DSCP, or IP precedence. 696 A stream using test sequence numbers can track the ordering 697 of packets as they transverse the DUT/SUT. 699 Streams are not restricted to a pair of source and 700 destination interfaces as long as all packets are tracked as 701 a single entity. A mulitcast stream can be forward to 702 multiple destination interfaces. 704 Measurement units: 705 n/a 707 See Also: 708 Flow 709 Microflow [Ni98] 710 Test sequence number 711 Network-layer Traffic Control Mechanisms 713 3.3.5 Test Sequence number 715 Definition: 716 A field in the IP payload portion of the packet that is used 717 to verify the order of the packets on the egress of the 718 DUT/SUT. 720 Discussion: 721 The traffic generator sets the test sequence number value and 722 the traffic receiver checks the value upon receipt of the 723 packet. The traffic generator changes the value on each 724 packet transmitted based on an algorithm agreed to by the 725 traffic receiver. 727 The traffic receiver keeps track of the sequence numbers on a 728 per stream basis. In addition to number of received packets, 729 the traffic receiver may also report number of in-sequence 730 packets, number of out-sequence packets, number of duplicate 731 packets, and number of reordered packets. 733 The recommended algorithm to use to change the sequence 734 number on sequential packets is an incrementing value. 736 Measurement units: 737 n/a 739 See Also: 740 Stream 742 3.4 Vectors 743 A vector is a group of packets all containing a specific DSCP 744 or IP precedence value. Vectors are expressed as a pair of 745 numbers. The first is being the particular diff-serv value. 746 The second is the metric expressed as a rate, loss 747 percentage, delay, or jitter. 749 3.4.1 Intended Vector 751 Definition: 752 A vector describing the attempted rate at which packets 753 having a specific code-point (or IP precedence) are 754 transmitted to a DUT/SUT by an external source. 756 Discussion: 757 Intended loads across the different code-point classes 758 determine the metrics associated with a specific code-point 759 traffic class. 761 Measurement Units: 762 N-octets packets per second 763 Network-layer Traffic Control Mechanisms 765 See Also: 766 Offered Vector 767 Expected Forwarding Vector 768 Expected Loss Vector 769 Expected Sequence Vector 770 Expected Delay Vector 771 Expected Jitter Vector 772 Forwarding Vector 773 Loss Vector 775 3.4.2 Offered Vector 777 Definition: 778 A vector describing the measured rate at which packets having 779 a specific DSCP or IP precedence value are offered to the 780 DUT/SUT. 782 Discussion: 783 Offered loads across the different code-point classes, 784 constituting a code-point set, determine the metrics 785 associated with a specific code-point traffic class. 787 Measurement Units: 788 N-octets packets per second 790 See Also: 791 Expected Forwarding Vector 792 Expected Loss Vector 793 Expected Sequence Vector 794 Expected Delay Vector 795 Expected Jitter Vector 796 Forwarding Vector 797 Codepoint Set 799 3.4.3 Expected Vectors 801 3.4.3.1 Expected Forwarding Vector 803 Definition: 804 A vector describing the expected output rate of packets 805 having a specific DSCP or IP precedence value. The value is 806 dependent on the set of offered vectors and configuration of 807 the DUT. 809 Network-layer Traffic Control Mechanisms 811 Discussion: 812 The DUT is configured in a certain way in order that service 813 differentiation occurs for a particular DSCP or IP precedence 814 value when a specific traffic mix consisting of multiple 815 DSCPs or IP precedence values are applied. This term 816 attempts to capture the expected forwarding behavior when 817 subjected to a certain offered vectors. 819 The actual algorithm or mechanism the DUT uses to achieve 820 service differentiation is not important in describing the 821 expected forwarding vector. 823 Measurement units: 824 N-octet packets per second 826 See Also: 827 Intended Vector 828 Offered Vector 829 Output Vectors 830 Expected Loss Vector 831 Expected Sequence Vector 832 Expected Delay Vector 833 Expected Jitter Vector 835 3.4.3.2 Expected Loss Vector 837 Definition: 838 A vector describing the percentage of packets, having a 839 specific DSCP or IP precedence value, that should not be 840 forwarded. The value is dependent on the set of offered 841 vectors and configuration of the DUT. 843 Discussion: 844 The DUT is configured in a certain way in order that service 845 differentiation occurs for a particular DSCP or IP precedence 846 value when a specific traffic mix consisting of multiple 847 DSCPs or IP precedence values are applied. This term 848 attempts to capture the expected forwarding behavior when 849 subjected to a certain offered vector. 851 The actual algorithm or mechanism the DUT uses to achieve 852 service differentiation is not important in describing the 853 expected loss vector. 855 Measurement Units: 856 Percentage of intended packets that is expected to be 857 dropped. 859 Network-layer Traffic Control Mechanisms 861 See Also: 862 Intended Vector 863 Offered Vector 864 Expected Forwarding Vector 865 Expected Sequence Vector 866 Expected Delay Vector 867 Expected Jitter Vector 868 One-way Packet Loss Metric [Ka99] 870 3.4.3.3 Expected Sequence Vector 872 Definition: 873 A vector describing the expected in-sequence packets having a 874 specific DSCP or IP precedence value. The value is dependent 875 on the set of offered vectors and configuration of the DUT. 877 Discussion: 878 The DUT is configured in a certain way in order that service 879 differentiation occurs for a particular DSCP or IP precedence 880 value when a specific traffic mix consisting of multiple 881 DSCPs or IP precedence values are applied. This term 882 attempts to capture the expected forwarding behavior when 883 subjected to a certain offered vectors. 885 The actual algorithm or mechanism the DUT uses to achieve 886 service differentiation is not important in describing the 887 expected sequence vector. 889 Measurement Units: 890 N-octet packets per second 892 See Also: 893 Intended Vector 894 Offered Vector 895 Output Vectors 896 Expected Loss Vector 897 Expected Forwarding Vector 898 Expected Delay Vector 899 Expected Jitter Vector 901 3.4.3.4 Expected Instantaneous Delay Vector 903 Definition: 904 A vector describing the expected delay for packets having a 905 specific DSCP or IP precedence value. The value is dependent 906 on the set of offered vectors and configuration of the DUT. 908 Network-layer Traffic Control Mechanisms 910 Discussion: 911 The DUT is configured in a certain way in order that service 912 differentiation occurs for a particular DSCP or IP precedence 913 value when a specific traffic mix consisting of multiple 914 DSCPs or IP precedence values are applied. This term 915 attempts to capture the expected forwarding behavior when 916 subjected to a certain offered vectors. 918 The actual algorithm or mechanism the DUT uses to achieve 919 service differentiation is not important in describing the 920 expected delay vector. 922 Measurement units: 923 Seconds. 925 See Also: 926 Forwarding Delay 927 Intended Vector 928 Offered Vector 929 Output Vectors 930 Expected Loss Vector 931 Expected Sequence Vector 932 Expected Forwarding Vector 933 Expected Jitter Vector 935 3.4.3.5 Expected Average Delay Vector 937 Definition: 938 A vector describing the expected average delay for packets 939 having a specific DSCP or IP precedence value. The value is 940 dependent on the set of offered vectors and configuration of 941 the DUT. 943 Discussion: 944 The DUT is configured in a certain way in order that service 945 differentiation occurs for a particular DSCP or IP precedence 946 value when a specific traffic mix consisting of multiple 947 DSCPs or IP precedence values are applied. This term 948 attempts to capture the expected forwarding behavior when 949 subjected to a certain offered vectors. 951 The actual algorithm or mechanism the DUT uses to achieve 952 service differentiation is not important in describing the 953 expected average delay vector. 955 Measurement units: 956 Seconds. 958 Network-layer Traffic Control Mechanisms 960 See Also: 961 Intended Vector 962 Offered Vector 963 Output Vectors 964 Expected Loss Vector 965 Expected Sequence Vector 966 Expected Forwarding Vector 967 Expected Jitter Vector 969 3.4.3.6 Expected Maximum Delay Vector 971 Definition: 972 A vector describing the expected maximum delay for packets 973 having a specific DSCP or IP precedence value. The value is 974 dependent on the set of offered vectors and configuration of 975 the DUT. 977 Discussion: 978 The DUT is configured in a certain way in order that service 979 differentiation occurs for a particular DSCP or IP precedence 980 value when a specific traffic mix consisting of multiple 981 DSCPs or IP precedence values are applied. This term 982 attempts to capture the expected forwarding behavior when 983 subjected to a certain offered vectors. 985 The actual algorithm or mechanism the DUT uses to achieve 986 service differentiation is not important in describing the 987 expected maximum delay vector. 989 Measurement units: 990 Seconds. 992 See Also: 993 Intended Vector 994 Offered Vector 995 Output Vectors 996 Expected Loss Vector 997 Expected Sequence Vector 998 Expected Forwarding Vector 999 Expected Jitter Vector 1001 3.4.3.7 Expected Minimum Delay Vector 1003 Definition: 1004 A vector describing the expected minimum delay for packets 1005 having a specific DSCP or IP precedence value. The value is 1006 dependent on the set of offered vectors and configuration of 1007 the DUT. 1009 Network-layer Traffic Control Mechanisms 1011 Discussion: 1012 The DUT is configured in a certain way in order that service 1013 differentiation occurs for a particular DSCP or IP precedence 1014 value when a specific traffic mix consisting of multiple 1015 DSCPs or IP precedence values are applied. This term 1016 attempts to capture the expected forwarding behavior when 1017 subjected to a certain offered vectors. 1019 The actual algorithm or mechanism the DUT uses to achieve 1020 service differentiation is not important in describing the 1021 expected minimum delay vector. 1023 Measurement units: 1024 Seconds. 1026 See Also: 1027 Intended Vector 1028 Offered Vector 1029 Output Vectors 1030 Expected Loss Vector 1031 Expected Sequence Vector 1032 Expected Forwarding Vector 1033 Expected Jitter Vector 1035 3.4.3.8 Expected Instantaneous Jitter Vector 1037 Definition: 1038 A vector describing the expected jitter between two 1039 consecutive packets� arrival times having a specific DSCP or 1040 IP precedence value. The value is dependent on the set of 1041 offered vectors and configuration of the DUT. 1043 Discussion: 1044 Instantaneous Jitter is the absolute value of the difference 1045 between the delay measurement of two packets belonging to the 1046 same stream. 1048 The delay fluctuation between two consecutive packets in a 1049 stream is reported as the "Instantaneous Jitter". 1050 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 1051 where D equals the delay and i is the test sequence number. 1052 Packets lost are not counted in the measurement. 1054 Forwarding Vector may contain several Jitter Vectors. For n 1055 packets received in a Forwarding Vector, there is a total of 1056 (n-1) Instantaneous Jitter Vectors. 1058 Measurement units: 1059 Seconds 1060 Network-layer Traffic Control Mechanisms 1062 See Also: 1063 Delay 1064 Jitter 1065 Offered Vector 1066 Output Vectors 1067 Expected Average Jitter Vector 1068 Expected Peak-to-peak Jitter Vector 1069 Stream 1071 3.4.3.9 Expected Average Jitter Vector 1073 Definition: 1074 A vector describing the expected jitter in packet arrival 1075 times for packets having a specific DSCP or IP precedence 1076 value. The value is dependent on the set of offered vectors 1077 and configuration of the DUT. 1079 Discussion: 1080 Average Jitter Vector is the average of all the Instantaneous 1081 Jitter Vectors measured during the test duration for the same 1082 DSCP or IP precedence value. 1084 Measurement units: 1085 Seconds 1087 See Also: 1088 Intended Vector 1089 Offered Vector 1090 Output Vectors 1091 Expected Instantaneous Jitter Vector 1092 Expected Peak-to-peak Jitter Vector 1094 3.4.3.10 Expected Peak-to-peak Jitter Vector 1096 Definition: 1097 A vector describing the expected maximum variation in the 1098 delay of packet arrival times for packets having a specific 1099 DSCP or IP precedence value. The value is dependent on the 1100 set of offered vectors and configuration of the DUT. 1102 Discussion: 1103 Peak-to-peak Jitter Vector is the maximum delay minus the 1104 minimum delay of the packets (in a vector) forwarded by the 1105 DUT/SUT. 1107 Peak-to-peak Jitter is not derived from the Instantaneous 1108 Jitter Vector. Peak-to-peak Jitter is based upon all the 1109 packets during the test duration, not just two consecutive 1110 packets. 1112 Network-layer Traffic Control Mechanisms 1114 Measurement units: 1115 Seconds 1117 See Also: 1118 Intended Vector 1119 Offered Vector 1120 Output Vectors 1121 Expected Instantaneous Jitter Vector 1122 Expected Average Jitter Vector 1124 3.4.4 Output Vectors 1126 3.4.4.1 Forwarding Vector 1128 Definition: 1129 The number of packets per second for all packets containing a 1130 specific DSCP or IP precedence value that a device can be 1131 observed to successfully forward to the correct destination 1132 interface in response to an offered vector. 1134 Discussion: 1135 Forwarding Vector is expressed as pair of numbers. Both the 1136 specific DSCP (or IP precedence) value AND the packets per 1137 second value combine to make a vector. 1139 The Forwarding Vector represents packet rate based on its 1140 specific DSCP (or IP precedence) value. It is not 1141 necessarily based on a stream or flow. The Forwarding Vector 1142 may be expressed as per port of the DUT/SUT. However, it 1143 must be consistent with the Expected Forwarding Vector. 1145 Forwarding Vector is a per-hop measurement. The DUT/SUT may 1146 change the specific DSCP (or IP precedence) value for a 1147 multiple-hop measurement. 1149 Measurement units: 1150 N-octet packets per second 1152 See Also: 1153 Intended Vector 1154 Offered Vector 1155 Expected Vectors 1156 Loss Vector 1157 Sequence Vector 1158 Delay Vectors 1159 Network-layer Traffic Control Mechanisms 1161 3.4.4.2 Loss Vector 1163 Definition: 1164 The percentage of packets containing a specific DSCP or IP 1165 precedence value that a DUT/SUT did not transmit to the 1166 correct destination interface in response to an offered 1167 vector. 1169 Discussion: 1170 Loss Vector is expressed as pair of numbers. Both the 1171 specific DSCP (or IP precedence) value AND the percentage 1172 value combine to make a vector. 1174 The Loss Vector represents percentage based on a specific 1175 DSCP or IP precedence value. It is not necessarily based on 1176 a stream or flow. The Loss Vector may be expressed as per 1177 port of the DUT/SUT. However, it must be consistent with the 1178 Expected Loss Vector 1180 Loss Vector is a per-hop measurement. The DUT/SUT may change 1181 the specific DSCP or IP precedence value for a multiple-hop 1182 measurement. 1184 Measurement Units: 1185 Percentage of offered packets that is not forwarded. 1187 See Also: 1188 Intended Vector 1189 Offered Vector 1190 Expected Vectors 1191 Forwarding Vector 1192 Sequence Vector 1193 Delay Vectors 1194 One-way Packet Loss Metric [Ka99] 1196 3.4.4.3 Sequence Vector 1198 Definition: 1199 The number of packets per second for all packets containing a 1200 specific DSCP or IP precedence value that a device can be 1201 observed to transmit in sequence to the correct destination 1202 interface in response to an offered vector. 1204 Discussion: 1205 Sequence Vector is expressed as pair of numbers. Both the 1206 specific DSCP (or IP precedence) value AND the packets per 1207 second value combine to make a vector. 1209 Network-layer Traffic Control Mechanisms 1211 The Sequence Vector represents packet rate based on its 1212 specific DSCP or IP precedence value. It is not necessarily 1213 based on a stream or flow. The Sequence Vector may be 1214 expressed as per port of the DUT/SUT. However, it must be 1215 consistent with the Expected Sequence Vector. 1217 Sequence Vector is a per-hop measurement. The DUT/SUT may 1218 change the specific DSCP or IP precedence value for a 1219 multiple-hop measurement. 1221 Measurement Units: 1222 N-octet packets per second 1224 Issues: 1226 See Also: 1227 In-sequence Packet 1228 Intended Vector 1229 Offered Vector 1230 Expected Vectors 1231 Loss Vector 1232 Forwarding Vector 1233 Delay Vectors 1235 3.4.4.4 Instantaneous Delay Vector 1237 Definition: 1238 The delay for a packet containing a specific DSCP or IP 1239 precedence value that a device can be observed to 1240 successfully transmit to the correct destination interface in 1241 response to an offered vector. 1243 Discussion: 1244 Instantaneous Delay vector is expressed as pair of numbers. 1245 Both the specific DSCP (or IP precedence) value AND delay 1246 value combine to make a vector. 1248 The Instantaneous Delay Vector represents delay on its 1249 specific DSCP or IP precedence value. It is not necessarily 1250 based on a stream or flow. The Delay vector may be expressed 1251 as per port of the DUT/SUT. However, it must be consistent 1252 with the Expected Delay vectors. 1254 Instantaneous Delay Vector is a per-hop measurement. The 1255 DUT/SUT may change the specific DSCP or IP precedence value 1256 for a multiple-hop measurement. 1258 Instantaneous Delay vector can be obtained at any offered 1259 load. RECOMMEND at or below the Forwarding Capacity in the 1260 absence of forwarding congestion. For congested delay, run 1261 the offered load above the Forwarding Capacity. 1263 Network-layer Traffic Control Mechanisms 1265 Forwarding Vector may contain several Instantaneous Delay 1266 Vectors. For every packet received in a Forwarding Vector, 1267 there is a corresponding Instantaneous Delay Vector. 1269 Measurement Units: 1270 Seconds 1272 See Also: 1273 Delay 1274 Intended Vector 1275 Offered Vector 1276 Expected Delay Vectors 1277 Average Delay Vector 1278 Maximum Delay Vector 1279 Minimum Delay Vector 1281 3.4.4.5 Average Delay Vector 1283 Definition: 1284 The average delay for packets containing a specific DSCP or 1285 IP precedence value that a device can be observed to 1286 successfully transmit to the correct destination interface in 1287 response to an offered vector. 1289 Discussion: 1290 Average Delay vector is expressed as pair of numbers. Both 1291 the specific DSCP (or IP precedence) value AND delay value 1292 combine to make a vector. 1294 The Delay Vector represents delay on its specific DSCP or IP 1295 precedence value. It is not necessarily based on a stream or 1296 flow. The Delay vector may be expressed as per port of the 1297 DUT/SUT. However, it MUST be consistent with the Expected 1298 Delay vector. 1300 The Average Delay Vector is computed by averaging all the 1301 Instantaneous Delay Vectors for a given vector. 1303 Average Delay Vector is a per-hop measurement. The DUT/SUT 1304 may change the specific DSCP or IP precedence value for a 1305 multiple-hop measurement. 1307 Average Delay vector can be obtained at any offered load. 1308 Recommend at or below the Forwarding Capacity in the absence 1309 of congestion. For congested delay, run the offered load 1310 above the Forwarding Capacity. 1312 Measurement Units: 1313 Seconds 1314 Network-layer Traffic Control Mechanisms 1316 See Also: 1317 Delay 1318 Intended Vector 1319 Offered Vector 1320 Expected Delay Vectors 1321 Instantaneous Delay Vector 1322 Maximum Delay Vector 1323 Minimum Delay Vector 1325 3.4.4.6 Maximum Delay Vector 1327 Definition: 1328 The maximum delay from all packets containing a specific DSCP 1329 or IP precedence value that a device can be observed to 1330 successfully transmit to the correct destination interface in 1331 response to an offered vector. 1333 Discussion: 1334 Maximum Delay vector is expressed as pair of numbers. Both 1335 the specific DSCP (or IP precedence) value AND delay value 1336 combine to make a vector. 1338 The Maximum Delay Vector represents delay on its specific 1339 DSCP or IP precedence value. It is not necessarily based on 1340 a stream or flow. The Maximum Delay vector may be expressed 1341 as per port of the DUT/SUT. However, it must be consistent 1342 with the Expected Delay vector. 1344 Maximum Delay Vector is based upon the maximum Instantaneous 1345 Delay Vector of all packets in a Forwarding Vector. 1347 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1348 may change the specific DSCP or IP precedence value for a 1349 multiple-hop measurement. 1351 Measurement Units: 1352 Seconds 1354 See Also: 1355 Delay 1356 Intended Vector 1357 Offered Vector 1358 Expected Delay Vectors 1359 Instantaneous Delay Vector 1360 Forwarding Vector 1361 Average Delay Vector 1362 Minimum Delay Vector 1363 Network-layer Traffic Control Mechanisms 1365 3.4.4.7 Minimum Delay Vector 1367 Definition: 1368 The minimum delay from all packets containing a specific DSCP 1369 or IP precedence value that a device can be observed to 1370 successfully transmit to the correct destination interface in 1371 response to an offered vector. 1373 Discussion: 1374 Delay vector is expressed as pair of numbers. Both the 1375 specific DSCP (or IP precedence) value AND delay value 1376 combine to make a vector. 1378 The Minimum Delay Vector represents delay on its specific 1379 DSCP or IP precedence value. It is not necessarily based on 1380 a stream or flow. The Minimum Delay vector may be expressed 1381 as per port of the DUT/SUT. However, it must be consistent 1382 with the Expected Delay vector. 1384 Minimum Delay Vector is based upon the minimum Instantaneous 1385 Delay Vector of all packets in a Forwarding Vector. 1387 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1388 may change the specific DSCP or IP precedence value for a 1389 multiple-hop measurement. 1391 Minimum Delay vector can be obtained at any offered load. 1392 Recommend at or below the Forwarding Capacity in the absence 1393 of congestion. For congested delay, run the offered load 1394 above the Forwarding Capacity. 1396 Measurement Units: 1397 Seconds 1399 See Also: 1400 Delay 1401 Intended Vector 1402 Offered Vector 1403 Expected Delay Vectors 1404 Instantaneous Delay Vector 1405 Forwarding Vector 1406 Average Delay Vector 1407 Maximum Delay Vector 1409 3.4.4.8 Instantaneous Jitter Vector 1411 Definition: 1412 The jitter for two consecutive packets containing a specific 1413 DSCP or IP precedence value that a device can be observed to 1414 successfully transmit to the correct destination interface in 1415 response to an offered vector. 1417 Network-layer Traffic Control Mechanisms 1419 Discussion: 1420 Instantaneous Jitter is the absolute value of the difference 1421 between the delay measurement of two packets belonging to the 1422 same stream. 1424 Jitter vector is expressed as pair of numbers. Both the 1425 specific DSCP (or IP precedence) value AND jitter value 1426 combine to make a vector. 1428 The delay fluctuation between two consecutive packets in a 1429 stream is reported as the "Instantaneous Jitter". 1430 Instantaneous Jitter Vector can be expressed as |D(i) - D(i- 1431 1)| where D equals the delay and i is the test sequence 1432 number. Packets lost are not counted in the measurement. 1434 Instantaneous Jitter Vector is a per-hop measurement. The 1435 DUT/SUT may change the specific DSCP or IP precedence value 1436 for a multiple-hop measurement. 1438 Forwarding Vector may contain several Instantaneous Jitter 1439 Vectors. For n packets received in a Forwarding Vector, 1440 there are exactly (n-1) Instantaneous Jitter Vectors. 1442 Measurement units: 1443 Seconds 1445 See Also: 1446 Delay 1447 Jitter 1448 Forwarding Vector 1449 Stream 1450 Expected Vectors 1451 Average Jitter Vector 1452 Peak-to-peak Jitter Vector 1454 3.4.4.9 Average Jitter Vector 1456 Definition: 1457 The average jitter for packets containing a specific DSCP or 1458 IP precedence value that a device can be observed to 1459 successfully transmit to the correct destination interface in 1460 response to an offered vector. 1462 Discussion: 1463 Average Jitter Vector is the average of all the Instantaneous 1464 Jitter Vectors of the same DSCP or IP precedence value, 1465 measured during the test duration. 1467 Network-layer Traffic Control Mechanisms 1469 Average Jitter vector is expressed as pair of numbers. Both 1470 the specific DSCP (or IP precedence) value AND jitter value 1471 combine to make a vector. 1473 Average Jitter vector is a per-hop measurement. The DUT/SUT 1474 may change the specific DSCP or IP precedence value for a 1475 multiple-hop measurement. 1477 Measurement units: 1478 Seconds 1480 See Also: 1481 Jitter 1482 Forwarding Vector 1483 Stream 1484 Expected Vectors 1485 Instantaneous Jitter Vector 1486 Peak-to-peak Jitter Vector 1488 3.4.4.10 Peak-to-peak Jitter Vector 1490 Definition: 1491 The maximum possible variation in the delay for packets 1492 containing a specific DSCP or IP precedence value that a 1493 device can be observed to successfully transmit to the 1494 correct destination interface in response to an offered 1495 vector. 1497 Discussion: 1498 Peak-to-peak Jitter Vector is the maximum delay minus the 1499 minimum delay of the packets (in a vector) forwarded by the 1500 DUT/SUT. 1502 Jitter vector is expressed as pair of numbers. Both the 1503 specific DSCP (or IP precedence) value AND jitter value 1504 combine to make a vector. 1506 Peak-to-peak Jitter is not derived from the Instantaneous 1507 Jitter Vector. Peak-to-peak Jitter is based upon all the 1508 packets during the test duration, not just two consecutive 1509 packets. 1511 Measurement units: 1512 Seconds 1514 See Also: 1515 Jitter 1516 Forwarding Vector 1517 Stream 1518 Expected Vectors 1519 Average Jitter Vector 1520 Peak-to-peak Jitter Vector 1521 Network-layer Traffic Control Mechanisms 1523 4. Acknowledgments 1525 The authors gratefully acknowledge the contributions of the 1526 IETF's benchmarking working group members in reviewing this 1527 document. The authors would like to express our thanks to 1528 David Newman for his consistent and valuable assistance 1529 throughout the development of this document. The following 1530 individuals also made noteworthy contributions to the 1531 editors' understanding of the subject matter: John Dawson, 1532 Kevin Dubray, and Kathleen Nichols. 1534 5. Security Considerations 1536 Documents of this type do not directly affect the security of 1537 the Internet or of corporate networks as long as benchmarking 1538 is not performed on devices or systems connected to 1539 production networks. 1541 Packets with unintended and/or unauthorized DSCP or IP 1542 precedence values may present security issues. Determining 1543 the security consequences of such packets is out of scope for 1544 this document. 1546 6. Normative References 1548 [Br91] Bradner, S., "Benchmarking Terminology for Network 1549 Interconnection Devices", RFC 1242, July 1991. 1551 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 1552 Requirement Levels", RFC 2119, March 1997 1554 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1555 Switching Devices", RFC 2285, February 1998. 1557 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1558 of the Differentiated Services Field (DS Field) in the 1559 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1561 Network-layer Traffic Control Mechanisms 1563 7. Informative References 1565 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 1566 Metric for IPPM", RFC 2679, September 1999 1568 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1569 Weiss, W., "An Architecture for Differentiated Services", 1570 RFC 2475, December 1998. 1572 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 1573 Network Interconnect Devices", RFC 2544, March 1999 1575 [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 1576 Metric for IPPM", RFC 3393, November 2002 1578 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 1579 Forwarding PHB", RFC 2598, June 1999 1581 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1582 Packet Loss Metric for IPPM", RFC 2680, September 1999 1584 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 1585 Survey", RFC 1254, August 1991 1587 [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 1588 LAN Switching Devices", RFC 2889, August 2000 1590 [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1591 S., Perser, J., "Packet Reordering Metric for IPPM", 1592 Work in Progress 1594 [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1595 RFC 896, January 1984. 1597 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1598 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1599 January 1999. 1601 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1602 "RTP: A Transport Protocol for Real-Time Applications", 1603 RFC 1889, January 1996 1604 Network-layer Traffic Control Mechanisms 1606 8. Authors' Addresses 1608 Jerry Perser 1610 USA 1612 Phone: 1613 EMail: jerry@perser.org 1615 Scott Poretsky 1616 Quarry Technologies 1617 New England Executive Park 1618 Burlington, MA 01803 1619 USA 1621 Phone: + 1 781 359 5090 1622 EMail: sporetsky@quarrytech.com 1624 Shobha Erramilli 1625 QNetworx Inc 1626 1119 Campus Drive West 1627 Morganville, NJ 07751 1628 USA 1630 Phone: 1631 EMail: shobha@qnetworx.com 1633 Sumit Khurana 1634 Telcordia Technologies 1635 445 South Street 1636 Morristown, NJ 07960 1637 USA 1639 Phone: + 1 973 829 3170 1640 EMail: sumit@research.telcordia.com 1641 Network-layer Traffic Control Mechanisms 1643 9. Full Copyright Statement 1645 Copyright (C) The Internet Society (2003). All Rights 1646 Reserved. 1648 This document and translations of it may be copied and 1649 furnished to others, and derivative works that comment on or 1650 otherwise explain it or assist in its implementation may be 1651 prepared, copied, published and distributed, in whole or in 1652 part, without restriction of any kind, provided that the 1653 above copyright notice and this paragraph are included on all 1654 such copies and derivative works. However, this document 1655 itself may not be modified in any way, such as by removing 1656 the copyright notice or references to the Internet Society or 1657 other Internet organizations, except as needed for the 1658 purpose of developing Internet standards in which case the 1659 procedures for copyrights defined in the Internet Standards 1660 process must be followed, or as required to translate it into 1661 languages other than English. 1663 The limited permissions granted above are perpetual and will 1664 not be revoked by the Internet Society or its successors or 1665 assigns. This document and the information contained herein 1666 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1667 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1668 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1669 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1670 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1671 FITNESS FOR A PARTICULAR PURPOSE. 1673 Network Working Group Jerry Perser 1674 INTERNET-DRAFT 1675 Expires in: April 2004 Scott Poretsky 1676 Quarry Technologies 1677 Shobha Erramilli 1678 Qnetworx 1679 Sumit Khurana 1680 Telcordia 1682 October 2003 1684 Terminology for Benchmarking Network-layer 1685 Traffic Control Mechanisms 1687 1689 Status of this Memo 1691 This document is an Internet-Draft and is in full conformance with 1692 all provisions of Section 10 of RFC2026. 1694 Internet-Drafts are working documents of the Internet Engineering 1695 Task Force (IETF), its areas, and its working groups. Note that 1696 other groups may also distribute working documents as Internet- 1697 Drafts. 1699 Internet-Drafts are draft documents valid for a maximum of six 1700 months and may be updated, replaced, or obsoleted by other 1701 documents at any time. It is inappropriate to use Internet- 1702 Drafts as reference material or to cite them other than as "work 1703 in progress." 1705 The list of current Internet-Drafts can be accessed at 1706 http://www.ietf.org/ietf/1id-abstracts.txt 1708 The list of Internet-Draft Shadow Directories can be accessed at 1709 http://www.ietf.org/shadow.html. 1711 Copyright Notice 1713 Copyright (C) The Internet Society (2003). All Rights Reserved. 1715 Abstract 1717 This document describes terminology for the benchmarking of 1718 devices that implement traffic control based on IP precedence or 1719 diff-serv code point criteria. 1721 Network-layer Traffic Control Mechanisms 1723 Table of Contents 1725 1. Introduction .............................................. 3 1726 2. Existing definitions ...................................... 3 1727 3. Term definitions............................................4 1728 3.1 Configuration Terms 1729 3.1.1 Classification.........................................4 1730 3.1.2 Codepoint Set..........................................4 1731 3.1.3 Forwarding Congestion..................................5 1732 3.1.4 Congestion Management..................................6 1733 3.1.5 Flow...................................................7 1734 3.2 Measurement Terms 1735 3.2.1 Forwarding Capacity....................................7 1736 3.2.2 Conforming Packet......................................8 1737 3.2.3 Nonconforming Packet...................................9 1738 3.2.4 Forwarding Delay.......................................9 1739 3.2.5 Jitter................................................11 1740 3.2.6 Undifferentiated Response.............................11 1741 3.3 Sequence Tracking 1742 3.3.1 In-sequence Packet....................................12 1743 3.3.2 Out-of-order Packet...................................12 1744 3.3.3 Duplicate Packet......................................13 1745 3.3.4 Stream................................................14 1746 3.3.5 Test Sequence number .................................15 1747 3.4 Vectors...................................................15 1748 3.4.1 Intended Vector.......................................15 1749 3.4.2 Offered Vector........................................16 1750 3.4.3 Expected Vectors 1751 3.4.3.1 Expected Forwarding Vector........................16 1752 3.4.3.2 Expected Loss Vector..............................17 1753 3.4.3.3 Expected Sequence Vector..........................18 1754 3.4.3.4 Expected Instantaneous Delay Vector...............18 1755 3.4.3.5 Expected Average Delay Vector.....................19 1756 3.4.3.6 Expected Maximum Delay Vector.....................10 1757 3.4.3.7 Expected Minimum Delay Vector.....................20 1758 3.4.3.8 Expected Instantaneous Jitter Vector..............21 1759 3.4.3.9 Expected Average Jitter Vector....................22 1760 3.4.3.10 Expected Peak-to-peak Jitter Vector..............22 1761 3.4.4 Output Vectors 1762 3.4.4.1 Forwarding Vector.................................23 1763 3.4.4.2 Loss Vector.......................................24 1764 3.4.4.3 Sequence Vector...................................24 1765 3.4.4.4 Instantaneous Delay Vector........................25 1766 3.4.4.5 Average Delay Vector..............................26 1767 3.4.4.6 Maximum Delay Vector..............................27 1768 3.4.4.7 Minimum Delay Vector..............................28 1769 3.4.4.8 Instantaneous Jitter Vector.......................28 1770 3.4.4.9 Average Jitter Vector.............................29 1771 3.4.4.10 Peak-to-peak Jitter Vector.......................30 1772 4. Acknowledgments............................................31 1773 5. Security Considerations....................................31 1774 6. Normative References.......................................31 1775 Network-layer Traffic Control Mechanisms 1777 7. Informative References.....................................32 1778 8. Author's Address...........................................33 1779 9. Full Copyright Statement...................................34 1781 1. Introduction 1783 New terminology is needed because most existing measurements 1784 assume the absence of congestion and only a single per-hop- 1785 behavior. This document introduces several new terms that will 1786 allow measurements to be taken during periods of congestion. 1788 Another key difference from existing terminology is the definition 1789 of measurements as observed on egress as well as ingress of a 1790 device/system under test. Again, the existence of congestion 1791 requires the addition of egress measurements as well as those 1792 taken on ingress; without observing traffic leaving a 1793 device/system it is not possible to say whether traffic-control 1794 mechanisms effectively dealt with congestion. 1796 The principal measurements introduced in this document are vectors 1797 for rate, delay, and jitter, all of which can be observed with or 1798 without congestion of the DUT/SUT. 1800 This document describes only those terms relevant to measuring 1801 behavior of a device or a group of devices using one of these two 1802 mechanisms. End-to-end and service-level measurements are beyond 1803 the scope of this document. 1805 2. Existing definitions 1807 RFC 1242 "Benchmarking Terminology for Network Interconnect 1808 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 1809 Devices" should be consulted before attempting to make use of this 1810 document. 1812 RFC 2474 "Definition of the Differentiated Services Field (DS 1813 Field) in the IPv4 and IPv6 Headers" section 2, contains 1814 discussions of a number of terms relevant to network-layer traffic 1815 control mechanisms and should also be consulted. 1817 For the sake of clarity and continuity this RFC adopts the 1818 template for definitions set out in Section 2 of RFC 1242. 1819 Definitions are indexed and grouped together in sections for ease 1820 of reference. 1822 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 1823 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 1824 "OPTIONAL" in this document are to be interpreted as described in 1825 RFC 2119 [Br97]. 1827 Network-layer Traffic Control Mechanisms 1829 3. Term definitions 1831 3.1 Configuration Terms 1833 3.1.1 Classification 1835 Definition: 1836 Selection of packets based on the contents of packet header 1837 according to defined rules. 1839 Discussion: 1840 Packets can be selected based on the DS field or IP 1841 Precedence in the packet header. Classification can also be 1842 based on Multi-Field (MF) criteria such as IP Source and 1843 destination addresses, protocol and port number. 1845 Classification determines the per-hop behaviors and traffic 1846 conditioning functions such as shaping and dropping that are 1847 to be applied to the packet. 1849 Measurement units: 1850 n/a 1852 See Also: 1854 3.1.2 Codepoint Set 1856 Definition: 1857 The set of all DS Code-points or IP precedence values used 1858 during the test duration. 1860 Discussion: 1861 Describes all the code-point markings associated with packets 1862 that are input to the DUT/SUT. For each entry in the 1863 codepoint set, there are associated vectors describing the 1864 rate of traffic, delay, loss, or jitter containing that 1865 particular DSCP or IP precedence value. 1867 The treatment that a packet belonging to a particular code- 1868 point gets is subject to the DUT classifying packets to map 1869 to the correct PHB. Moreover, the forwarding treatment in 1870 general is also dependent on the complete set of offered 1871 vectors. 1873 Measurement Units: 1874 n/a 1876 See Also: 1878 Network-layer Traffic Control Mechanisms 1880 3.1.3 Forwarding Congestion 1882 Definition: 1883 A condition in which one or more egress interfaces are 1884 offered more packets than are forwarded. 1886 Discussion: 1887 This condition is a superset of the overload definition 1888 [Ma98]. Overload [Ma98] deals with overloading input and 1889 output interfaces beyond the maximum transmission allowed by 1890 the medium. Forwarding congestion does not assume ingress 1891 interface overload as the only source of overload on output 1892 interfaces. 1894 Another difference between Forwarding Congestion and overload 1895 occurs when the SUT comprises multiple elements, in that 1896 Forwarding Congestion may occur at multiple points. Consider 1897 an SUT comprising multiple edge devices exchanging traffic 1898 with a single core device. Depending on traffic patterns, 1899 the edge devices may induce Forwarding Congestion on multiple 1900 egress interfaces on the core device. 1902 Packet Loss, not increased Delay, is the metric to indicate 1903 the condition of Forwarding Congestion. Packet Loss is a 1904 deterministic indicator of Forwarding Congestion. While 1905 increased delay may be an indicator of Forwarding Congestion, 1906 it is a non-deterministic indicator of Forwarding Congestion. 1907 External observation of increased delay to indicate 1908 congestion is in effect external observation of Incipient 1909 Congestion. 1911 [Ra99] implies that it is impractical to build a black-box 1912 test to externally observe Incipient Congestion indicated by 1913 increased delay in a router. [Ra99] introduces Explicit 1914 Congestion Notification (ECN) as the externally observable, 1915 deterministic method for indicating Incipient Congestion. 1916 Because [Ra99] is an Experimental RFC with limited 1917 deployment, ECN is not used for this particular methodology. 1918 For the purpose of "black-box" testing a DUT/SUT, Packet Loss 1919 as the indicator of Forwarding Congestion is used. 1921 Throughput [Br91] defines the lower boundary of Forwarding 1922 Congestion. Throughput is the maximum offered rate with no 1923 Forwarding Congestion. At offered rates above throughput, 1924 the DUT/SUT is considered to be in a state of Forwarding 1925 Congestion. 1927 Network-layer Traffic Control Mechanisms 1929 Ingress observations alone are not sufficient to cover all 1930 cases in which Forwarding Congestion may occur. A device 1931 with an infinite amount of memory could buffer an infinite 1932 number of packets, and eventually forward all of them. 1933 However, these packets may or may not be forwarded during the 1934 test duration. Even though ingress interfaces accept all 1935 packets without loss, Forwarding Congestion is present in 1936 this hypothetical device. 1938 Forwarding Congestion, indicated by occurrence of packet 1939 loss, is one type of congestion for a DUT/SUT. Congestion 1940 Collapse [Na84] is defined as the state in which buffers are 1941 full and all arriving packets must be dropped across the 1942 network. Incipient Congestion [Ra99] is defined as 1943 congestion that produces increased delay without packet loss. 1945 The definition presented here explicitly defines Forwarding 1946 Congestion as an event observable on egress interfaces. 1947 Regardless of internal architecture, any device that cannot 1948 forward packets on one or more egress interfaces is under 1949 Forwarding Congestion. 1951 Measurement units: 1952 none 1954 See Also: 1955 Gateway Congestion Control Survey [Ma91] 1957 3.1.4 Congestion Management 1959 Definition: 1960 An implementation of one or more per-hop-behaviors to avoid 1961 or minimize the condition of congestion. 1963 Discussion: 1964 Congestion management may seek either to control congestion 1965 or avoid it altogether. Such mechanisms classify packets 1966 based upon IP Precedence or DSCP settings in a packet�s IP 1967 header. 1969 Congestion avoidance mechanisms seek to prevent congestion 1970 before it actually occurs. 1972 Congestion control mechanisms give one or more flows (with a 1973 discrete IP Precedence or DSCP value) preferential treatment 1974 over other classes during periods of congestion. 1976 Measurement units: 1977 n/a 1979 See Also: 1981 Network-layer Traffic Control Mechanisms 1983 3.1.5 Flow 1985 Definition: 1986 A flow is a one or more of packets sharing a common intended 1987 pair of source and destination interfaces. 1989 Discussion: 1990 Packets are grouped by the ingress and egress interfaces they 1991 use on a given DUT/SUT. 1993 A flow can contain multiple source IP addresses and/or 1994 destination IP addresses. All packets in a flow must enter 1995 on the same ingress interface and exit on the same egress 1996 interface, and have some common network layer content. 1998 Microflows [Ni98] are a subset of flows. As defined in 1999 [Ni98], microflows require application-to-application 2000 measurement. In contrast, flows use lower-layer 2001 classification criteria. Since this document focuses on 2002 network-layer classification criteria, we concentrate here on 2003 the use of network-layer identifiers in describing a flow. 2004 Flow identifiers also may reside at the data-link, transport, 2005 or application layers of the OSI model. However, identifiers 2006 other than those at the network layer are out of scope for 2007 this document. 2009 A flow may contain a single code point/IP precedence value or 2010 may contain multiple values destined for a single egress 2011 interface. This is determined by the test methodology. 2013 Measurement units: 2014 n/a 2016 See Also: 2017 Microflow [Ni98] 2018 Streams 2020 3.2 Measurement Terms 2022 3.2.1 Forwarding Capacity 2024 Definition: 2025 The number of packets per second that a device can be 2026 observed to successfully transmit to the correct destination 2027 interface in response to a specified offered load while the 2028 device drops none of the offered packets. 2030 Network-layer Traffic Control Mechanisms 2032 Discussion: 2033 Forwarding Capacity measures the packet rate at the egress 2034 interface(s) of the DUT/SUT. In contrast, throughput as 2035 defined in RFC 1242 measures the frame rate at the ingress 2036 interface(s) of the DUT/SUT. 2038 Ingress-based measurements do not account for queuing of the 2039 DUT/SUT. Throughput rates can be higher than the Forwarding 2040 Capacity because of queuing. The difference is dependent 2041 upon test duration, packet rate, and queue size. Forwarding 2042 Capacity, as an egress measurement, does take queuing into 2043 account. 2045 Understanding Forwarding Capacity is a necessary precursor to 2046 any measurement involving Traffic Control Mechanisms. The 2047 accompanying methodology document MUST take into 2048 consideration Forwarding Capacity when determining the 2049 expected forwarding vectors. When the sum of the expected 2050 forwarding vectors on an interface exceeds the Forwarding 2051 Capacity, the Forwarding Capacity will govern the forwarding 2052 rate. 2054 This measurement differs from forwarding rate at maximum 2055 offered load (FRMOL) [Ma98] in that Forwarding Capacity 2056 requires zero loss. 2058 Measurement units: 2059 N-octet packets per second 2061 See Also: 2062 Throughput [Br91] 2063 Forwarding Rate at Maximum Offered Load [Ma98] 2065 3.2.2 Conforming Packet 2067 Definition: 2068 Packets which lie within specific rate, delay, or jitter 2069 bounds. 2071 Discussion: 2072 A DUT/SUT may be configured to allow a given traffic class to 2073 consume a given amount of bandwidth, or to fall within 2074 predefined delay or jitter boundaries. All packets that lie 2075 within specified bounds are then said to be conforming, 2076 whereas those outside the bounds are nonconforming. 2078 Measurement units: 2079 n/a 2080 Network-layer Traffic Control Mechanisms 2082 See Also: 2083 Expected Vector 2084 Forwarding Vector 2085 Offered Vector 2086 Nonconforming 2088 3.2.3 Nonconforming Packet 2090 Definition: 2091 Packets that do not lie within specific rate, delay, or 2092 jitter bounds. 2094 Discussion: 2095 A DUT/SUT may be configured to allow a given traffic class to 2096 consume a given amount of bandwidth, or to fall within 2097 predefined delay or jitter boundaries. All packets that do 2098 not lie within these bounds are then said to be 2099 nonconforming. 2101 Measurement units: 2102 n/a 2104 See Also: 2105 Expected Vector 2106 Forwarding Vector 2107 Offered Vector 2108 Conforming 2110 3.2.4 Forwarding Delay 2112 Definition: 2113 The time interval starting when the last bit of the input IP 2114 packet is offered to the input port of the DUT/SUT and ending 2115 when the last bit of the output IP packet is received from 2116 the output port of the DUT/SUT. 2118 Discussion: 2119 The delay time interval MUST be externally observed. The 2120 delay measurement MUST NOT include delays added by test bed 2121 components other than the DUT/SUT, such as propagation time 2122 introduced by cabling or non-zero delay added by the test 2123 instrument. 2125 Forwarding Delay differs from latency [Br91] and one-way 2126 delay [Al99] in several key regards: 2128 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 2129 uses "store and forward" or "bit forwarding" technology. 2130 Forwarding Delay is the same metric, measured the same way, 2131 regardless of the architecture of the DUT/SUT. 2133 Network-layer Traffic Control Mechanisms 2135 2. Forwarding Delay is a last-in, last-out (LILO) 2136 measurement, unlike the last-in, first-out method [Br91] or 2137 the first-in, last-out method [Al99]. 2139 The LILO method most closely simulates the way a network- 2140 layer device actually processes an IP datagram. IP datagrams 2141 are not passed up and down the stack unless they are 2142 complete, and processing begins only once the last bit of the 2143 IP datagram has been received. 2145 Further, the LILO method has an additive property, where the 2146 sum of the parts MUST equal the whole. This is a key 2147 difference from [Br91] and [Al99]. For example, the delay 2148 added by two DUTs MUST equal the sum of the delay of the 2149 DUTs. This may or may not be the case with [Br91] and 2150 [Al99]. 2152 3. Forwarding Delay measures the IP datagram only, unlike 2153 [Br91], which also includes link layer overhead. 2155 A metric focused exclusively on the Internet protocol 2156 relieves the tester from specifying the start/end for every 2157 link layer protocol that IP runs on. This avoids the need to 2158 determine whether the start/stop delimiters are included. It 2159 also allows the use of heterogeneous link layer protocols in 2160 a test. 2162 4. Forwarding Delay can be measured at any offered load, 2163 whereas the latency methodology [Br99] recommends measurement 2164 at, and only at, the throughput level. Comparing the 2165 Forwarding Delay below the throughput to Forwarding Delay 2166 above the Forwarding Capacity will give insight to the 2167 traffic control mechanisms. 2169 For example, non-congested delay may be measured with an 2170 offered load that does not exceed the Forwarding Capacity, 2171 while congested delay may involve an offered load that 2172 exceeds Forwarding Capacity. 2174 Note: Forwarding Delay SHOULD NOT be used as an absolute 2175 indicator of DUT/SUT Forwarding Congestion. While Forwarding 2176 Delay may rise when offered load nears or exceeds Forwarding 2177 Capacity, there is no universal point at which Forwarding 2178 Delay can be said to indicate the presence or absence of 2179 Forwarding Congestion. 2181 Measurement units: 2182 Seconds. 2184 Network-layer Traffic Control Mechanisms 2186 See Also: 2187 Latency [Br91] 2188 Latency [Al99] 2189 One-way Delay [Br99] 2191 3.2.5 Jitter 2193 Definition: 2194 The absolute value of the difference between the arrival 2195 delay of two consecutive received packets belonging to the 2196 same stream. 2198 Discussion: 2199 The delay fluctuation between two consecutive received 2200 packets in a stream is reported as the jitter. Jitter can be 2201 expressed as |D(i) - D(i-1)| where D equals the delay and i 2202 is the order the packets were received. 2204 Under loss, jitter can be measured between non-consecutive 2205 test sequence numbers. When Traffic Control Mechanisms are 2206 losing packets, the Forwarding Delay may fluctuate as a 2207 response. Jitter MUST be able to benchmark the delay 2208 variation with or with out loss. 2210 Jitter is related to the ipdv [De02] (IP Delay Variation) by 2211 taking the absolute value of the ipdv. The two metrics will 2212 produce different mean values. �Mean Jitter� will produce a 2213 positive value, where the �mean ipdv� is typically zero. 2215 Measurement units: 2216 Seconds 2218 See Also: 2219 Forwarding Delay 2220 Jitter variation [Ja99] 2221 ipdv [De02] 2222 interarrival jitter [Sc96] 2224 3.2.6 Undifferentiated Response 2226 Definition: 2227 The vector(s) obtained when mechanisms used to support diff- 2228 serv or IP precedence are disabled. 2230 Discussion: 2231 Enabling diff-serv or IP precedence mechanisms may impose 2232 additional processing overhead for packets. This overhead 2233 may degrade performance even when traffic belonging to only 2234 one class, the best-effort class, is offered to the device. 2236 Network-layer Traffic Control Mechanisms 2238 Measurements with "undifferentiated response" should be made 2239 to establish a baseline. 2241 The vector(s) obtained with DSCP or IP precedence enabled can 2242 be compared to the undifferentiated response to determine the 2243 effect of differentiating traffic. 2245 Measurement units: 2246 n/a 2248 3.3 Sequence Tracking 2250 3.3.1 In-sequence Packet 2252 Definition: 2253 A received packet with the expected Test Sequence number. 2255 Discussion: 2256 In-sequence is done on a stream level. As packets are 2257 received on a stream, each packet�s Test Sequence number is 2258 compared with the previous packet. Only packets that match 2259 the expected Test Sequence number are considered in-sequence. 2261 Packets that do not match the expected Test Sequence number 2262 are counted as "not in-sequence" or out-of-sequence. Every 2263 packet that is received is either in-sequence or out-of- 2264 sequence. Subtracting the in-sequence from the received 2265 packets (for that stream) can derive the out-of-sequence 2266 count. 2268 Two types of events will prevent the in-sequence from 2269 incrementing: packet loss and reordered packets. 2271 Measurement units: 2272 Packet count 2274 See Also: 2275 Stream 2276 Test Sequence number 2278 3.3.2 Out-of-order Packet 2280 Definition: 2281 A received packet with a Test Sequence number less than 2282 expected. 2284 Network-layer Traffic Control Mechanisms 2286 Discussion: 2287 As a stream of packets enters a DUT/SUT, they include a 2288 Stream Test Sequence number indicating the order the packets 2289 were sent to the DUT/SUT. On exiting the DUT/SUT, these 2290 packets may arrive in a different order. Each packet that 2291 was re-ordered is counted as an Out-of-order Packet. 2293 Certain streaming protocol (such as TCP) require the packets 2294 to be in a certain order. Packets outside this are dropped 2295 by the streaming protocols even though there were properly 2296 received by the IP layer. The type of reordering tolerated 2297 by a streaming protocol varies from protocol to protocol, and 2298 also by implementation. 2300 Out-of-order Packet count is based on the worst case 2301 streaming protocol. It allows for no reordering. 2303 Packet loss does not affect the Out-of-order Packet count. 2304 Only packets that were not received in the order that they 2305 were transmitted. 2307 Measurement units: 2308 Packet count 2310 See Also: 2311 Stream 2312 Test Sequence number 2313 Packet Reordering Metric for IPPM [Mo03] 2315 3.3.3 Duplicate Packet 2317 Definition: 2318 A received packet with a Test Sequence number matching a 2319 previously received packet. 2321 Discussion: 2322 A Duplicate Packet is a packet that the DUT/SUT has 2323 successfully transmitted out an egress interface more than 2324 once. The egress interface has previously forwarded this 2325 packet. 2327 A Duplicate Packet SHOULD be a bit for bit copy of an already 2328 transmitted packet (including Test Sequence number). If the 2329 Duplicate Packet traversed different paths through the 2330 DUT/SUT, some fields (such as TTL or checksum) may have 2331 changed. 2333 Network-layer Traffic Control Mechanisms 2335 A multicast packet is not a Duplicate Packet by definition. 2336 For a given IP multicast group, a DUT/SUT SHOULD forward a 2337 packet once on a given egress interface provided the path to 2338 one or more multicast receivers is through that interface. 2339 Several egress interfaces will transmit the same packet, but 2340 only once per interface. 2342 To detect a Duplicate Packet, each offered packet to the 2343 DUT/SUT MUST contain a unique packet-by-packet identifier. 2345 Measurement units: 2346 Packet count 2348 See Also: 2349 Stream 2350 Test Sequence number 2352 3.3.4 Stream 2354 Definition: 2355 A group of packets tracked as a single entity by the traffic 2356 receiver. A stream may share a common content such as type 2357 (IP, UDP), packet size, or payload. 2359 Discussion: 2360 Streams are tracked by test sequence number or "unique 2361 signature field" [Ma00]. Streams define how individual 2362 packets� statistic are grouped together to form an 2363 intelligible summary. 2365 Common stream groupings would be by egress interface, 2366 destination address, source address, DSCP, or IP precedence. 2367 A stream using test sequence numbers can track the ordering 2368 of packets as they transverse the DUT/SUT. 2370 Streams are not restricted to a pair of source and 2371 destination interfaces as long as all packets are tracked as 2372 a single entity. A mulitcast stream can be forward to 2373 multiple destination interfaces. 2375 Measurement units: 2376 n/a 2378 See Also: 2379 Flow 2380 Microflow [Ni98] 2381 Test sequence number 2382 Network-layer Traffic Control Mechanisms 2384 3.3.5 Test Sequence number 2386 Definition: 2387 A field in the IP payload portion of the packet that is used 2388 to verify the order of the packets on the egress of the 2389 DUT/SUT. 2391 Discussion: 2392 The traffic generator sets the test sequence number value and 2393 the traffic receiver checks the value upon receipt of the 2394 packet. The traffic generator changes the value on each 2395 packet transmitted based on an algorithm agreed to by the 2396 traffic receiver. 2398 The traffic receiver keeps track of the sequence numbers on a 2399 per stream basis. In addition to number of received packets, 2400 the traffic receiver may also report number of in-sequence 2401 packets, number of out-sequence packets, number of duplicate 2402 packets, and number of reordered packets. 2404 The recommended algorithm to use to change the sequence 2405 number on sequential packets is an incrementing value. 2407 Measurement units: 2408 n/a 2410 See Also: 2411 Stream 2413 3.4 Vectors 2414 A vector is a group of packets all containing a specific DSCP 2415 or IP precedence value. Vectors are expressed as a pair of 2416 numbers. The first is being the particular diff-serv value. 2417 The second is the metric expressed as a rate, loss 2418 percentage, delay, or jitter. 2420 3.4.1 Intended Vector 2422 Definition: 2423 A vector describing the attempted rate at which packets 2424 having a specific code-point (or IP precedence) are 2425 transmitted to a DUT/SUT by an external source. 2427 Discussion: 2428 Intended loads across the different code-point classes 2429 determine the metrics associated with a specific code-point 2430 traffic class. 2432 Measurement Units: 2433 N-octets packets per second 2434 Network-layer Traffic Control Mechanisms 2436 See Also: 2437 Offered Vector 2438 Expected Forwarding Vector 2439 Expected Loss Vector 2440 Expected Sequence Vector 2441 Expected Delay Vector 2442 Expected Jitter Vector 2443 Forwarding Vector 2444 Loss Vector 2446 3.4.2 Offered Vector 2448 Definition: 2449 A vector describing the measured rate at which packets having 2450 a specific DSCP or IP precedence value are offered to the 2451 DUT/SUT. 2453 Discussion: 2454 Offered loads across the different code-point classes, 2455 constituting a code-point set, determine the metrics 2456 associated with a specific code-point traffic class. 2458 Measurement Units: 2459 N-octets packets per second 2461 See Also: 2462 Expected Forwarding Vector 2463 Expected Loss Vector 2464 Expected Sequence Vector 2465 Expected Delay Vector 2466 Expected Jitter Vector 2467 Forwarding Vector 2468 Codepoint Set 2470 3.4.3 Expected Vectors 2472 3.4.3.1 Expected Forwarding Vector 2474 Definition: 2475 A vector describing the expected output rate of packets 2476 having a specific DSCP or IP precedence value. The value is 2477 dependent on the set of offered vectors and configuration of 2478 the DUT. 2480 Network-layer Traffic Control Mechanisms 2482 Discussion: 2483 The DUT is configured in a certain way in order that service 2484 differentiation occurs for a particular DSCP or IP precedence 2485 value when a specific traffic mix consisting of multiple 2486 DSCPs or IP precedence values are applied. This term 2487 attempts to capture the expected forwarding behavior when 2488 subjected to a certain offered vectors. 2490 The actual algorithm or mechanism the DUT uses to achieve 2491 service differentiation is not important in describing the 2492 expected forwarding vector. 2494 Measurement units: 2495 N-octet packets per second 2497 See Also: 2498 Intended Vector 2499 Offered Vector 2500 Output Vectors 2501 Expected Loss Vector 2502 Expected Sequence Vector 2503 Expected Delay Vector 2504 Expected Jitter Vector 2506 3.4.3.2 Expected Loss Vector 2508 Definition: 2509 A vector describing the percentage of packets, having a 2510 specific DSCP or IP precedence value, that should not be 2511 forwarded. The value is dependent on the set of offered 2512 vectors and configuration of the DUT. 2514 Discussion: 2515 The DUT is configured in a certain way in order that service 2516 differentiation occurs for a particular DSCP or IP precedence 2517 value when a specific traffic mix consisting of multiple 2518 DSCPs or IP precedence values are applied. This term 2519 attempts to capture the expected forwarding behavior when 2520 subjected to a certain offered vector. 2522 The actual algorithm or mechanism the DUT uses to achieve 2523 service differentiation is not important in describing the 2524 expected loss vector. 2526 Measurement Units: 2527 Percentage of intended packets that is expected to be 2528 dropped. 2530 Network-layer Traffic Control Mechanisms 2532 See Also: 2533 Intended Vector 2534 Offered Vector 2535 Expected Forwarding Vector 2536 Expected Sequence Vector 2537 Expected Delay Vector 2538 Expected Jitter Vector 2539 One-way Packet Loss Metric [Ka99] 2541 3.4.3.3 Expected Sequence Vector 2543 Definition: 2544 A vector describing the expected in-sequence packets having a 2545 specific DSCP or IP precedence value. The value is dependent 2546 on the set of offered vectors and configuration of the DUT. 2548 Discussion: 2549 The DUT is configured in a certain way in order that service 2550 differentiation occurs for a particular DSCP or IP precedence 2551 value when a specific traffic mix consisting of multiple 2552 DSCPs or IP precedence values are applied. This term 2553 attempts to capture the expected forwarding behavior when 2554 subjected to a certain offered vectors. 2556 The actual algorithm or mechanism the DUT uses to achieve 2557 service differentiation is not important in describing the 2558 expected sequence vector. 2560 Measurement Units: 2561 N-octet packets per second 2563 See Also: 2564 Intended Vector 2565 Offered Vector 2566 Output Vectors 2567 Expected Loss Vector 2568 Expected Forwarding Vector 2569 Expected Delay Vector 2570 Expected Jitter Vector 2572 3.4.3.4 Expected Instantaneous Delay Vector 2574 Definition: 2575 A vector describing the expected delay for packets having a 2576 specific DSCP or IP precedence value. The value is dependent 2577 on the set of offered vectors and configuration of the DUT. 2579 Network-layer Traffic Control Mechanisms 2581 Discussion: 2582 The DUT is configured in a certain way in order that service 2583 differentiation occurs for a particular DSCP or IP precedence 2584 value when a specific traffic mix consisting of multiple 2585 DSCPs or IP precedence values are applied. This term 2586 attempts to capture the expected forwarding behavior when 2587 subjected to a certain offered vectors. 2589 The actual algorithm or mechanism the DUT uses to achieve 2590 service differentiation is not important in describing the 2591 expected delay vector. 2593 Measurement units: 2594 Seconds. 2596 See Also: 2597 Forwarding Delay 2598 Intended Vector 2599 Offered Vector 2600 Output Vectors 2601 Expected Loss Vector 2602 Expected Sequence Vector 2603 Expected Forwarding Vector 2604 Expected Jitter Vector 2606 3.4.3.5 Expected Average Delay Vector 2608 Definition: 2609 A vector describing the expected average delay for packets 2610 having a specific DSCP or IP precedence value. The value is 2611 dependent on the set of offered vectors and configuration of 2612 the DUT. 2614 Discussion: 2615 The DUT is configured in a certain way in order that service 2616 differentiation occurs for a particular DSCP or IP precedence 2617 value when a specific traffic mix consisting of multiple 2618 DSCPs or IP precedence values are applied. This term 2619 attempts to capture the expected forwarding behavior when 2620 subjected to a certain offered vectors. 2622 The actual algorithm or mechanism the DUT uses to achieve 2623 service differentiation is not important in describing the 2624 expected average delay vector. 2626 Measurement units: 2627 Seconds. 2629 Network-layer Traffic Control Mechanisms 2631 See Also: 2632 Intended Vector 2633 Offered Vector 2634 Output Vectors 2635 Expected Loss Vector 2636 Expected Sequence Vector 2637 Expected Forwarding Vector 2638 Expected Jitter Vector 2640 3.4.3.6 Expected Maximum Delay Vector 2642 Definition: 2643 A vector describing the expected maximum delay for packets 2644 having a specific DSCP or IP precedence value. The value is 2645 dependent on the set of offered vectors and configuration of 2646 the DUT. 2648 Discussion: 2649 The DUT is configured in a certain way in order that service 2650 differentiation occurs for a particular DSCP or IP precedence 2651 value when a specific traffic mix consisting of multiple 2652 DSCPs or IP precedence values are applied. This term 2653 attempts to capture the expected forwarding behavior when 2654 subjected to a certain offered vectors. 2656 The actual algorithm or mechanism the DUT uses to achieve 2657 service differentiation is not important in describing the 2658 expected maximum delay vector. 2660 Measurement units: 2661 Seconds. 2663 See Also: 2664 Intended Vector 2665 Offered Vector 2666 Output Vectors 2667 Expected Loss Vector 2668 Expected Sequence Vector 2669 Expected Forwarding Vector 2670 Expected Jitter Vector 2672 3.4.3.7 Expected Minimum Delay Vector 2674 Definition: 2675 A vector describing the expected minimum delay for packets 2676 having a specific DSCP or IP precedence value. The value is 2677 dependent on the set of offered vectors and configuration of 2678 the DUT. 2680 Network-layer Traffic Control Mechanisms 2682 Discussion: 2683 The DUT is configured in a certain way in order that service 2684 differentiation occurs for a particular DSCP or IP precedence 2685 value when a specific traffic mix consisting of multiple 2686 DSCPs or IP precedence values are applied. This term 2687 attempts to capture the expected forwarding behavior when 2688 subjected to a certain offered vectors. 2690 The actual algorithm or mechanism the DUT uses to achieve 2691 service differentiation is not important in describing the 2692 expected minimum delay vector. 2694 Measurement units: 2695 Seconds. 2697 See Also: 2698 Intended Vector 2699 Offered Vector 2700 Output Vectors 2701 Expected Loss Vector 2702 Expected Sequence Vector 2703 Expected Forwarding Vector 2704 Expected Jitter Vector 2706 3.4.3.8 Expected Instantaneous Jitter Vector 2708 Definition: 2709 A vector describing the expected jitter between two 2710 consecutive packets� arrival times having a specific DSCP or 2711 IP precedence value. The value is dependent on the set of 2712 offered vectors and configuration of the DUT. 2714 Discussion: 2715 Instantaneous Jitter is the absolute value of the difference 2716 between the delay measurement of two packets belonging to the 2717 same stream. 2719 The delay fluctuation between two consecutive packets in a 2720 stream is reported as the "Instantaneous Jitter". 2721 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 2722 where D equals the delay and i is the test sequence number. 2723 Packets lost are not counted in the measurement. 2725 Forwarding Vector may contain several Jitter Vectors. For n 2726 packets received in a Forwarding Vector, there is a total of 2727 (n-1) Instantaneous Jitter Vectors. 2729 Measurement units: 2730 Seconds 2731 Network-layer Traffic Control Mechanisms 2733 See Also: 2734 Delay 2735 Jitter 2736 Offered Vector 2737 Output Vectors 2738 Expected Average Jitter Vector 2739 Expected Peak-to-peak Jitter Vector 2740 Stream 2742 3.4.3.9 Expected Average Jitter Vector 2744 Definition: 2745 A vector describing the expected jitter in packet arrival 2746 times for packets having a specific DSCP or IP precedence 2747 value. The value is dependent on the set of offered vectors 2748 and configuration of the DUT. 2750 Discussion: 2751 Average Jitter Vector is the average of all the Instantaneous 2752 Jitter Vectors measured during the test duration for the same 2753 DSCP or IP precedence value. 2755 Measurement units: 2756 Seconds 2758 See Also: 2759 Intended Vector 2760 Offered Vector 2761 Output Vectors 2762 Expected Instantaneous Jitter Vector 2763 Expected Peak-to-peak Jitter Vector 2765 3.4.3.10 Expected Peak-to-peak Jitter Vector 2767 Definition: 2768 A vector describing the expected maximum variation in the 2769 delay of packet arrival times for packets having a specific 2770 DSCP or IP precedence value. The value is dependent on the 2771 set of offered vectors and configuration of the DUT. 2773 Discussion: 2774 Peak-to-peak Jitter Vector is the maximum delay minus the 2775 minimum delay of the packets (in a vector) forwarded by the 2776 DUT/SUT. 2778 Peak-to-peak Jitter is not derived from the Instantaneous 2779 Jitter Vector. Peak-to-peak Jitter is based upon all the 2780 packets during the test duration, not just two consecutive 2781 packets. 2783 Network-layer Traffic Control Mechanisms 2785 Measurement units: 2786 Seconds 2788 See Also: 2789 Intended Vector 2790 Offered Vector 2791 Output Vectors 2792 Expected Instantaneous Jitter Vector 2793 Expected Average Jitter Vector 2795 3.4.4 Output Vectors 2797 3.4.4.1 Forwarding Vector 2799 Definition: 2800 The number of packets per second for all packets containing a 2801 specific DSCP or IP precedence value that a device can be 2802 observed to successfully forward to the correct destination 2803 interface in response to an offered vector. 2805 Discussion: 2806 Forwarding Vector is expressed as pair of numbers. Both the 2807 specific DSCP (or IP precedence) value AND the packets per 2808 second value combine to make a vector. 2810 The Forwarding Vector represents packet rate based on its 2811 specific DSCP (or IP precedence) value. It is not 2812 necessarily based on a stream or flow. The Forwarding Vector 2813 may be expressed as per port of the DUT/SUT. However, it 2814 must be consistent with the Expected Forwarding Vector. 2816 Forwarding Vector is a per-hop measurement. The DUT/SUT may 2817 change the specific DSCP (or IP precedence) value for a 2818 multiple-hop measurement. 2820 Measurement units: 2821 N-octet packets per second 2823 See Also: 2824 Intended Vector 2825 Offered Vector 2826 Expected Vectors 2827 Loss Vector 2828 Sequence Vector 2829 Delay Vectors 2830 Network-layer Traffic Control Mechanisms 2832 3.4.4.2 Loss Vector 2834 Definition: 2835 The percentage of packets containing a specific DSCP or IP 2836 precedence value that a DUT/SUT did not transmit to the 2837 correct destination interface in response to an offered 2838 vector. 2840 Discussion: 2841 Loss Vector is expressed as pair of numbers. Both the 2842 specific DSCP (or IP precedence) value AND the percentage 2843 value combine to make a vector. 2845 The Loss Vector represents percentage based on a specific 2846 DSCP or IP precedence value. It is not necessarily based on 2847 a stream or flow. The Loss Vector may be expressed as per 2848 port of the DUT/SUT. However, it must be consistent with the 2849 Expected Loss Vector 2851 Loss Vector is a per-hop measurement. The DUT/SUT may change 2852 the specific DSCP or IP precedence value for a multiple-hop 2853 measurement. 2855 Measurement Units: 2856 Percentage of offered packets that is not forwarded. 2858 See Also: 2859 Intended Vector 2860 Offered Vector 2861 Expected Vectors 2862 Forwarding Vector 2863 Sequence Vector 2864 Delay Vectors 2865 One-way Packet Loss Metric [Ka99] 2867 3.4.4.3 Sequence Vector 2869 Definition: 2870 The number of packets per second for all packets containing a 2871 specific DSCP or IP precedence value that a device can be 2872 observed to transmit in sequence to the correct destination 2873 interface in response to an offered vector. 2875 Discussion: 2876 Sequence Vector is expressed as pair of numbers. Both the 2877 specific DSCP (or IP precedence) value AND the packets per 2878 second value combine to make a vector. 2880 Network-layer Traffic Control Mechanisms 2882 The Sequence Vector represents packet rate based on its 2883 specific DSCP or IP precedence value. It is not necessarily 2884 based on a stream or flow. The Sequence Vector may be 2885 expressed as per port of the DUT/SUT. However, it must be 2886 consistent with the Expected Sequence Vector. 2888 Sequence Vector is a per-hop measurement. The DUT/SUT may 2889 change the specific DSCP or IP precedence value for a 2890 multiple-hop measurement. 2892 Measurement Units: 2893 N-octet packets per second 2895 Issues: 2897 See Also: 2898 In-sequence Packet 2899 Intended Vector 2900 Offered Vector 2901 Expected Vectors 2902 Loss Vector 2903 Forwarding Vector 2904 Delay Vectors 2906 3.4.4.4 Instantaneous Delay Vector 2908 Definition: 2909 The delay for a packet containing a specific DSCP or IP 2910 precedence value that a device can be observed to 2911 successfully transmit to the correct destination interface in 2912 response to an offered vector. 2914 Discussion: 2915 Instantaneous Delay vector is expressed as pair of numbers. 2916 Both the specific DSCP (or IP precedence) value AND delay 2917 value combine to make a vector. 2919 The Instantaneous Delay Vector represents delay on its 2920 specific DSCP or IP precedence value. It is not necessarily 2921 based on a stream or flow. The Delay vector may be expressed 2922 as per port of the DUT/SUT. However, it must be consistent 2923 with the Expected Delay vectors. 2925 Instantaneous Delay Vector is a per-hop measurement. The 2926 DUT/SUT may change the specific DSCP or IP precedence value 2927 for a multiple-hop measurement. 2929 Instantaneous Delay vector can be obtained at any offered 2930 load. RECOMMEND at or below the Forwarding Capacity in the 2931 absence of forwarding congestion. For congested delay, run 2932 the offered load above the Forwarding Capacity. 2934 Network-layer Traffic Control Mechanisms 2936 Forwarding Vector may contain several Instantaneous Delay 2937 Vectors. For every packet received in a Forwarding Vector, 2938 there is a corresponding Instantaneous Delay Vector. 2940 Measurement Units: 2941 Seconds 2943 See Also: 2944 Delay 2945 Intended Vector 2946 Offered Vector 2947 Expected Delay Vectors 2948 Average Delay Vector 2949 Maximum Delay Vector 2950 Minimum Delay Vector 2952 3.4.4.5 Average Delay Vector 2954 Definition: 2955 The average delay for packets containing a specific DSCP or 2956 IP precedence value that a device can be observed to 2957 successfully transmit to the correct destination interface in 2958 response to an offered vector. 2960 Discussion: 2961 Average Delay vector is expressed as pair of numbers. Both 2962 the specific DSCP (or IP precedence) value AND delay value 2963 combine to make a vector. 2965 The Delay Vector represents delay on its specific DSCP or IP 2966 precedence value. It is not necessarily based on a stream or 2967 flow. The Delay vector may be expressed as per port of the 2968 DUT/SUT. However, it MUST be consistent with the Expected 2969 Delay vector. 2971 The Average Delay Vector is computed by averaging all the 2972 Instantaneous Delay Vectors for a given vector. 2974 Average Delay Vector is a per-hop measurement. The DUT/SUT 2975 may change the specific DSCP or IP precedence value for a 2976 multiple-hop measurement. 2978 Average Delay vector can be obtained at any offered load. 2979 Recommend at or below the Forwarding Capacity in the absence 2980 of congestion. For congested delay, run the offered load 2981 above the Forwarding Capacity. 2983 Measurement Units: 2984 Seconds 2985 Network-layer Traffic Control Mechanisms 2987 See Also: 2988 Delay 2989 Intended Vector 2990 Offered Vector 2991 Expected Delay Vectors 2992 Instantaneous Delay Vector 2993 Maximum Delay Vector 2994 Minimum Delay Vector 2996 3.4.4.6 Maximum Delay Vector 2998 Definition: 2999 The maximum delay from all packets containing a specific DSCP 3000 or IP precedence value that a device can be observed to 3001 successfully transmit to the correct destination interface in 3002 response to an offered vector. 3004 Discussion: 3005 Maximum Delay vector is expressed as pair of numbers. Both 3006 the specific DSCP (or IP precedence) value AND delay value 3007 combine to make a vector. 3009 The Maximum Delay Vector represents delay on its specific 3010 DSCP or IP precedence value. It is not necessarily based on 3011 a stream or flow. The Maximum Delay vector may be expressed 3012 as per port of the DUT/SUT. However, it must be consistent 3013 with the Expected Delay vector. 3015 Maximum Delay Vector is based upon the maximum Instantaneous 3016 Delay Vector of all packets in a Forwarding Vector. 3018 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 3019 may change the specific DSCP or IP precedence value for a 3020 multiple-hop measurement. 3022 Measurement Units: 3023 Seconds 3025 See Also: 3026 Delay 3027 Intended Vector 3028 Offered Vector 3029 Expected Delay Vectors 3030 Instantaneous Delay Vector 3031 Forwarding Vector 3032 Average Delay Vector 3033 Minimum Delay Vector 3034 Network-layer Traffic Control Mechanisms 3036 3.4.4.7 Minimum Delay Vector 3038 Definition: 3039 The minimum delay from all packets containing a specific DSCP 3040 or IP precedence value that a device can be observed to 3041 successfully transmit to the correct destination interface in 3042 response to an offered vector. 3044 Discussion: 3045 Delay vector is expressed as pair of numbers. Both the 3046 specific DSCP (or IP precedence) value AND delay value 3047 combine to make a vector. 3049 The Minimum Delay Vector represents delay on its specific 3050 DSCP or IP precedence value. It is not necessarily based on 3051 a stream or flow. The Minimum Delay vector may be expressed 3052 as per port of the DUT/SUT. However, it must be consistent 3053 with the Expected Delay vector. 3055 Minimum Delay Vector is based upon the minimum Instantaneous 3056 Delay Vector of all packets in a Forwarding Vector. 3058 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 3059 may change the specific DSCP or IP precedence value for a 3060 multiple-hop measurement. 3062 Minimum Delay vector can be obtained at any offered load. 3063 Recommend at or below the Forwarding Capacity in the absence 3064 of congestion. For congested delay, run the offered load 3065 above the Forwarding Capacity. 3067 Measurement Units: 3068 Seconds 3070 See Also: 3071 Delay 3072 Intended Vector 3073 Offered Vector 3074 Expected Delay Vectors 3075 Instantaneous Delay Vector 3076 Forwarding Vector 3077 Average Delay Vector 3078 Maximum Delay Vector 3080 3.4.4.8 Instantaneous Jitter Vector 3082 Definition: 3083 The jitter for two consecutive packets containing a specific 3084 DSCP or IP precedence value that a device can be observed to 3085 successfully transmit to the correct destination interface in 3086 response to an offered vector. 3088 Network-layer Traffic Control Mechanisms 3090 Discussion: 3091 Instantaneous Jitter is the absolute value of the difference 3092 between the delay measurement of two packets belonging to the 3093 same stream. 3095 Jitter vector is expressed as pair of numbers. Both the 3096 specific DSCP (or IP precedence) value AND jitter value 3097 combine to make a vector. 3099 The delay fluctuation between two consecutive packets in a 3100 stream is reported as the "Instantaneous Jitter". 3101 Instantaneous Jitter Vector can be expressed as |D(i) - D(i- 3102 1)| where D equals the delay and i is the test sequence 3103 number. Packets lost are not counted in the measurement. 3105 Instantaneous Jitter Vector is a per-hop measurement. The 3106 DUT/SUT may change the specific DSCP or IP precedence value 3107 for a multiple-hop measurement. 3109 Forwarding Vector may contain several Instantaneous Jitter 3110 Vectors. For n packets received in a Forwarding Vector, 3111 there are exactly (n-1) Instantaneous Jitter Vectors. 3113 Measurement units: 3114 Seconds 3116 See Also: 3117 Delay 3118 Jitter 3119 Forwarding Vector 3120 Stream 3121 Expected Vectors 3122 Average Jitter Vector 3123 Peak-to-peak Jitter Vector 3125 3.4.4.9 Average Jitter Vector 3127 Definition: 3128 The average jitter for packets containing a specific DSCP or 3129 IP precedence value that a device can be observed to 3130 successfully transmit to the correct destination interface in 3131 response to an offered vector. 3133 Discussion: 3134 Average Jitter Vector is the average of all the Instantaneous 3135 Jitter Vectors of the same DSCP or IP precedence value, 3136 measured during the test duration. 3138 Network-layer Traffic Control Mechanisms 3140 Average Jitter vector is expressed as pair of numbers. Both 3141 the specific DSCP (or IP precedence) value AND jitter value 3142 combine to make a vector. 3144 Average Jitter vector is a per-hop measurement. The DUT/SUT 3145 may change the specific DSCP or IP precedence value for a 3146 multiple-hop measurement. 3148 Measurement units: 3149 Seconds 3151 See Also: 3152 Jitter 3153 Forwarding Vector 3154 Stream 3155 Expected Vectors 3156 Instantaneous Jitter Vector 3157 Peak-to-peak Jitter Vector 3159 3.4.4.10 Peak-to-peak Jitter Vector 3161 Definition: 3162 The maximum possible variation in the delay for packets 3163 containing a specific DSCP or IP precedence value that a 3164 device can be observed to successfully transmit to the 3165 correct destination interface in response to an offered 3166 vector. 3168 Discussion: 3169 Peak-to-peak Jitter Vector is the maximum delay minus the 3170 minimum delay of the packets (in a vector) forwarded by the 3171 DUT/SUT. 3173 Jitter vector is expressed as pair of numbers. Both the 3174 specific DSCP (or IP precedence) value AND jitter value 3175 combine to make a vector. 3177 Peak-to-peak Jitter is not derived from the Instantaneous 3178 Jitter Vector. Peak-to-peak Jitter is based upon all the 3179 packets during the test duration, not just two consecutive 3180 packets. 3182 Measurement units: 3183 Seconds 3185 See Also: 3186 Jitter 3187 Forwarding Vector 3188 Stream 3189 Expected Vectors 3190 Average Jitter Vector 3191 Peak-to-peak Jitter Vector 3192 Network-layer Traffic Control Mechanisms 3194 4. Acknowledgments 3196 The authors gratefully acknowledge the contributions of the 3197 IETF's benchmarking working group members in reviewing this 3198 document. The authors would like to express our thanks to 3199 David Newman for his consistent and valuable assistance 3200 throughout the development of this document. The following 3201 individuals also made noteworthy contributions to the 3202 editors' understanding of the subject matter: John Dawson, 3203 Kevin Dubray, and Kathleen Nichols. 3205 5. Security Considerations 3207 Documents of this type do not directly affect the security of 3208 the Internet or of corporate networks as long as benchmarking 3209 is not performed on devices or systems connected to 3210 production networks. 3212 Packets with unintended and/or unauthorized DSCP or IP 3213 precedence values may present security issues. Determining 3214 the security consequences of such packets is out of scope for 3215 this document. 3217 6. Normative References 3219 [Br91] Bradner, S., "Benchmarking Terminology for Network 3220 Interconnection Devices", RFC 1242, July 1991. 3222 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 3223 Requirement Levels", RFC 2119, March 1997 3225 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 3226 Switching Devices", RFC 2285, February 1998. 3228 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 3229 of the Differentiated Services Field (DS Field) in the 3230 IPv4 and IPv6 Headers", RFC 2474, December 1998. 3232 Network-layer Traffic Control Mechanisms 3234 7. Informative References 3236 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 3237 Metric for IPPM", RFC 2679, September 1999 3239 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 3240 Weiss, W., "An Architecture for Differentiated Services", 3241 RFC 2475, December 1998. 3243 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 3244 Network Interconnect Devices", RFC 2544, March 1999 3246 [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 3247 Metric for IPPM", RFC 3393, November 2002 3249 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 3250 Forwarding PHB", RFC 2598, June 1999 3252 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 3253 Packet Loss Metric for IPPM", RFC 2680, September 1999 3255 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 3256 Survey", RFC 1254, August 1991 3258 [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 3259 LAN Switching Devices", RFC 2889, August 2000 3261 [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 3262 S., Perser, J., "Packet Reordering Metric for IPPM", 3263 Work in Progress 3265 [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 3266 RFC 896, January 1984. 3268 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 3269 Explicit Congestion Notification (ECN) to IP", RFC 2481, 3270 January 1999. 3272 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 3273 "RTP: A Transport Protocol for Real-Time Applications", 3274 RFC 1889, January 1996 3275 Network-layer Traffic Control Mechanisms 3277 8. Authors' Addresses 3279 Jerry Perser 3281 USA 3283 Phone: 3284 EMail: jerry@perser.org 3286 Scott Poretsky 3287 Quarry Technologies 3288 New England Executive Park 3289 Burlington, MA 01803 3290 USA 3292 Phone: + 1 781 359 5090 3293 EMail: sporetsky@quarrytech.com 3295 Shobha Erramilli 3296 QNetworx Inc 3297 1119 Campus Drive West 3298 Morganville, NJ 07751 3299 USA 3301 Phone: 3302 EMail: shobha@qnetworx.com 3304 Sumit Khurana 3305 Telcordia Technologies 3306 445 South Street 3307 Morristown, NJ 07960 3308 USA 3310 Phone: + 1 973 829 3170 3311 EMail: sumit@research.telcordia.com 3312 Network-layer Traffic Control Mechanisms 3314 9. Full Copyright Statement 3316 Copyright (C) The Internet Society (2003). All Rights 3317 Reserved. 3319 This document and translations of it may be copied and 3320 furnished to others, and derivative works that comment on or 3321 otherwise explain it or assist in its implementation may be 3322 prepared, copied, published and distributed, in whole or in 3323 part, without restriction of any kind, provided that the 3324 above copyright notice and this paragraph are included on all 3325 such copies and derivative works. However, this document 3326 itself may not be modified in any way, such as by removing 3327 the copyright notice or references to the Internet Society or 3328 other Internet organizations, except as needed for the 3329 purpose of developing Internet standards in which case the 3330 procedures for copyrights defined in the Internet Standards 3331 process must be followed, or as required to translate it into 3332 languages other than English. 3334 The limited permissions granted above are perpetual and will 3335 not be revoked by the Internet Society or its successors or 3336 assigns. This document and the information contained herein 3337 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 3338 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 3339 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 3340 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 3341 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3342 FITNESS FOR A PARTICULAR PURPOSE.