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