idnits 2.17.1 draft-ietf-bmwg-dsmterm-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1684. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1697. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2006) is 6457 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) == Missing Reference: 'BR98' is mentioned on line 247, but not defined == Unused Reference: 'Br98' is defined on line 1558, but no explicit reference was found in the text == Unused Reference: 'Bl98' is defined on line 1579, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. 'Br91') ** Obsolete normative reference: RFC 2309 (ref. 'Br98') (Obsoleted by RFC 7567) ** 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: 7 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jerry Perser 2 INTERNET-DRAFT Veriwave 3 Expires in: August 2006 4 Scott Poretsky 5 Reef Point Systems 7 Shobha Erramilli 8 Qnetworx 10 Sumit Khurana 11 Telcordia 13 February 2006 15 Terminology for Benchmarking Network-layer 16 Traffic Control Mechanisms 18 20 Intellectual Property Rights (IPR) statement: 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Status of this Memo 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Copyright Notice 45 Copyright (C) The Internet Society (2006). 47 Abstract 48 This document describes terminology for the benchmarking of 49 devices that implement traffic control based on IP precedence or 50 diff-serv code point criteria. The terminology is to be applied 51 to measurements made on the data plane to evaluate IP traffic 52 control mechanisms. 54 Network-layer Traffic Control Mechanisms 56 Table of Contents 57 1. Introduction .............................................. 3 58 2. Existing definitions ...................................... 3 59 3. Term definitions............................................4 60 3.1 Configuration Terms 61 3.1.1 Classification.........................................4 62 3.1.2 Codepoint Set..........................................4 63 3.1.3 Forwarding Congestion..................................5 64 3.1.4 Congestion Management..................................6 65 3.1.5 Flow...................................................7 66 3.2 Measurement Terms 67 3.2.1 Forwarding Capacity....................................7 68 3.2.2 Conforming Packet......................................8 69 3.2.3 Nonconforming Packet...................................9 70 3.2.4 Forwarding Delay.......................................9 71 3.2.5 Jitter................................................11 72 3.2.6 Undifferentiated Response.............................11 73 3.3 Sequence Tracking 74 3.3.1 In-sequence Packet....................................12 75 3.3.2 Out-of-order Packet...................................12 76 3.3.3 Duplicate Packet......................................13 77 3.3.4 Stream................................................14 78 3.3.5 Test Sequence number .................................15 79 3.4 Vectors...................................................15 80 3.4.1 Intended Vector.......................................15 81 3.4.2 Offered Vector........................................16 82 3.4.3 Expected Vectors 83 3.4.3.1 Expected Forwarding Vector........................16 84 3.4.3.2 Expected Loss Vector..............................17 85 3.4.3.3 Expected Sequence Vector..........................18 86 3.4.3.4 Expected Instantaneous Delay Vector...............18 87 3.4.3.5 Expected Average Delay Vector.....................19 88 3.4.3.6 Expected Maximum Delay Vector.....................10 89 3.4.3.7 Expected Minimum Delay Vector.....................20 90 3.4.3.8 Expected Instantaneous Jitter Vector..............21 91 3.4.3.9 Expected Average Jitter Vector....................22 92 3.4.3.10 Expected Peak-to-peak Jitter Vector..............22 93 3.4.4 Output Vectors 94 3.4.4.1 Forwarding Vector.................................23 95 3.4.4.2 Loss Vector.......................................24 96 3.4.4.3 Sequence Vector...................................24 97 3.4.4.4 Instantaneous Delay Vector........................25 98 3.4.4.5 Average Delay Vector..............................26 99 3.4.4.6 Maximum Delay Vector..............................27 100 3.4.4.7 Minimum Delay Vector..............................28 101 3.4.4.8 Instantaneous Jitter Vector.......................28 102 3.4.4.9 Average Jitter Vector.............................29 103 3.4.4.10 Peak-to-peak Jitter Vector.......................30 104 4. IANA Considerations........................................31 105 5. Security Considerations....................................31 106 6. Acknowledgments............................................31 107 Network-layer Traffic Control Mechanisms 109 7. References.................................................32 110 8. Author's Address...........................................33 111 9. Full Copyright Statement...................................34 113 1. Introduction 115 New terminology is needed because most existing measurements 116 assume the absence of congestion and only a single per-hop- 117 behavior. This document introduces several new terms that will 118 allow measurements to be taken during periods of congestion. 120 Another key difference from existing terminology is the definition 121 of measurements as observed on egress as well as ingress of a 122 device/system under test. Again, the existence of congestion 123 requires the addition of egress measurements as well as those 124 taken on ingress; without observing traffic leaving a 125 device/system it is not possible to say whether traffic-control 126 mechanisms effectively dealt with congestion. 128 The principal measurements introduced in this document are vectors 129 for rate, delay, and jitter, all of which can be observed with or 130 without congestion of the DUT/SUT. 132 This document describes only those terms relevant to measuring 133 behavior of a device or a group of devices using one of these two 134 mechanisms. End-to-end and service-level measurements are beyond 135 the scope of this document. 137 2. Existing definitions 138 RFC 1242 "Benchmarking Terminology for Network Interconnect 139 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 140 Devices" SHOULD be consulted before attempting to make use of this 141 document. 143 RFC 2474 "Definition of the Differentiated Services Field (DS 144 Field) in the IPv4 and IPv6 Headers" section 2, contains 145 discussions of a number of terms relevant to network-layer traffic 146 control mechanisms and SHOULD also be consulted. 148 For the sake of clarity and continuity this RFC adopts the 149 template for definitions set out in Section 2 of RFC 1242. 150 Definitions are indexed and grouped together in sections for ease 151 of reference. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in BCP 14, RFC 2119 156 [Br97]. RFC 2119 defines the use of these key words to help make the 157 intent of standards track documents as clear as possible. While this 158 document uses these keywords, this document is not a standards track 159 document. 161 Network-layer Traffic Control Mechanisms 163 3. Term definitions 165 3.1 Configuration Terms 167 3.1.1 Classification 169 Definition: 170 Selection of packets based on the contents of packet header 171 according to defined rules. 173 Discussion: 174 Packets can be selected based on the DS field or IP 175 Precedence in the packet header. Classification can also be 176 based on Multi-Field (MF) criteria such as IP Source and 177 destination addresses, protocol and port number. 179 Classification determines the per-hop behaviors and traffic 180 conditioning functions such as shaping and dropping that are 181 to be applied to the packet. 183 Measurement units: n/a 185 See Also: None 187 3.1.2 Codepoint Set 189 Definition: 190 The set of all DS Code-points or IP precedence values used 191 during the test duration. 193 Discussion: 194 Describes all the code-point markings associated with packets 195 that are input to the DUT/SUT. For each entry in the 196 codepoint set, there are associated vectors describing the 197 rate of traffic, delay, loss, or jitter containing that 198 particular DSCP or IP precedence value. 200 The treatment that a packet belonging to a particular code- 201 point gets is subject to the DUT classifying packets to map 202 to the correct PHB. Moreover, the forwarding treatment in 203 general is also dependent on the complete set of offered 204 vectors. 206 Measurement Units: n/a 208 See Also: None 209 Network-layer Traffic Control Mechanisms 211 3.1.3 Forwarding Congestion 213 Definition: 214 A condition in which one or more egress interfaces are 215 offered more packets than are forwarded. 217 Discussion: 218 This condition is a superset of the overload definition 219 [Ma98]. Overload [Ma98] deals with overloading input and 220 output interfaces beyond the maximum transmission allowed by 221 the medium. Forwarding congestion does not assume ingress 222 interface overload as the only source of overload on output 223 interfaces. 225 Another difference between Forwarding Congestion and overload 226 occurs when the SUT comprises multiple elements, in that 227 Forwarding Congestion may occur at multiple points. Consider 228 a SUT comprising multiple edge devices exchanging traffic 229 with a single core device. Depending on traffic patterns, 230 the edge devices may induce Forwarding Congestion on multiple 231 egress interfaces on the core device. 233 Throughput [Br91] defines the lower boundary of Forwarding 234 Congestion. Throughput is the maximum offered rate with no 235 Forwarding Congestion. At offered rates above throughput, 236 the DUT/SUT is considered to be in a state of Forwarding 237 Congestion. 239 Packet Loss, not increased Forwarding Delay, is the 240 external observable metric used to indicate the condition 241 of Forwarding Congestion. Packet Loss is a deterministic 242 indicator of Forwarding Congestion. The condition of 243 increased Forwarding Delay without Packet Loss is an 244 indicator of Forwarding Congestion known as Incipient 245 Congestion. Incipient Congestion is a non-deterministic 246 indicator of Forwarding Congestion [Fl93]. As stated in 247 [Ec98], RED [BR98] detects incipient congestion before the 248 buffer overflows, but the current Internet environment is 249 limited to packet loss as the mechanism for indicating 250 congestion to the end-nodes. [Ra99] implies that it is 251 impractical to build a black-box test to observe Incipient 252 Congestion. [Ra99] instead introduces Explicit Congestion 253 Notification (ECN) as a deterministic Black-Box method for 254 observing Incipient Congestion. [Ra99] is an Experimental 255 RFC with limited deployment, so ECN is not used for this 256 particular methodology. For the purpose of "black-box" 257 testing a DUT/SUT, this methodology uses Packet Loss as the 258 indicator of Forwarding Congestion. 260 Network-layer Traffic Control Mechanisms 262 Ingress observations alone are not sufficient to cover all 263 cases in which Forwarding Congestion may occur. A device 264 with an infinite amount of memory could buffer an infinite 265 number of packets, and eventually forward all of them. 266 However, these packets may or may not be forwarded during 267 the test duration. Congestion Collapse [Na84] is defined 268 as the state in which buffers are full and all arriving 269 packets MUST be dropped across the network. Even though 270 ingress interfaces accept all packets without loss, 271 Forwarding Congestion is present in this hypothetical 272 device. 274 The definition presented here explicitly defines 275 Forwarding Congestion as an event observable on egress 276 interfaces. Regardless of internal architecture, any 277 device exhibiting Packet Loss on one or more egress 278 interfaces is experiencing 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 packets 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: None 309 Network-layer Traffic Control Mechanisms 311 3.1.5 Flow 313 Definition: 314 A flow is a one or more of packets sharing a common intended 315 pair of ingress and egress interfaces. 317 Discussion: 318 Packets are grouped by the ingress and egress interfaces they 319 use on a given DUT/SUT. 321 A flow can contain multiple source IP addresses and/or 322 destination IP addresses. All packets in a flow MUST enter 323 on the same ingress interface and exit on the same egress 324 interface, and have some common network layer content. 326 Microflows [Ni98] are a subset of flows. As defined in 327 [Ni98], microflows require application-to-application 328 measurement. In contrast, flows use lower-layer 329 classification criteria. Since this document focuses on 330 network-layer classification criteria, we concentrate here on 331 the use of network-layer identifiers in describing a flow. 332 Flow identifiers also may reside at the data-link, transport, 333 or application layers of the OSI model. However, identifiers 334 other than those at the network layer are out of scope for 335 this document. 337 A flow may contain a single code point/IP precedence value or 338 may contain multiple values destined for a single egress 339 interface. This is determined by the test methodology. 341 Measurement units: 342 n/a 344 See Also: 345 Microflow [Ni98] 346 Streams 348 3.2 Measurement Terms 350 3.2.1 Forwarding Capacity 352 Definition: 353 The number of packets per second that a device can be 354 observed to successfully transmit to the correct destination 355 interface in response to a specified offered load while the 356 device drops none of the offered packets. 358 Network-layer Traffic Control Mechanisms 360 Discussion: 361 Forwarding Capacity measures the packet rate at the egress 362 interface(s) of the DUT/SUT. In contrast, throughput as 363 defined in RFC 1242 measures the packet rate at the ingress 364 interface(s) of the DUT/SUT. 366 Ingress-based measurements do not account for queuing of the 367 DUT/SUT. Throughput rates can be higher than the Forwarding 368 Capacity because of queueing. The difference is dependent 369 upon test duration, packet rate, and queue size. Forwarding 370 Capacity, as an egress measurement, does take queuing into 371 account. 373 Understanding Forwarding Capacity is a necessary precursor to 374 any measurement involving Traffic Control Mechanisms. The 375 accompanying methodology document MUST take into 376 consideration Forwarding Capacity when determining the 377 expected forwarding vectors. When the sum of the expected 378 forwarding vectors on an interface exceeds the Forwarding 379 Capacity, the Forwarding Capacity will govern the forwarding 380 rate. 382 This measurement differs from forwarding rate at maximum 383 offered load (FRMOL) [Ma98] in that Forwarding Capacity 384 requires zero loss. 386 Measurement units: 387 N-octet packets per second 389 See Also: 390 Throughput [Br91] 391 Forwarding Rate at Maximum Offered Load [Ma98] 393 3.2.2 Conforming Packet 395 Definition: 396 Packets which lie within specific rate, delay, or jitter 397 bounds. 399 Discussion: 400 A DUT/SUT may be configured to allow a given traffic class to 401 consume a given amount of bandwidth, or to fall within 402 predefined delay or jitter boundaries. All packets that lie 403 within specified bounds are then said to be conforming, 404 whereas those outside the bounds are nonconforming. 406 Measurement units: 407 n/a 408 Network-layer Traffic Control Mechanisms 410 See Also: 411 Expected Vector 412 Forwarding Vector 413 Offered Vector 414 Nonconforming 416 3.2.3 Nonconforming Packet 418 Definition: 419 Packets that do not lie within specific rate, delay, or 420 jitter bounds. 422 Discussion: 423 A DUT/SUT may be configured to allow a given traffic class to 424 consume a given amount of bandwidth, or to fall within 425 predefined delay or jitter boundaries. All packets that do 426 not lie within these bounds are then said to be 427 nonconforming. 429 Measurement units: 430 n/a 432 See Also: 433 Expected Vector 434 Forwarding Vector 435 Offered Vector 436 Conforming 438 3.2.4 Forwarding Delay 440 Definition: 441 The time interval starting when the last bit of the input IP 442 packet is offered to the input port of the DUT/SUT and ending 443 when the last bit of the output IP packet is received from 444 the output port of the DUT/SUT. 446 Discussion: 447 The delay time interval MUST be externally observed. The 448 delay measurement MUST NOT include delays added by test bed 449 components other than the DUT/SUT, such as propagation time 450 introduced by cabling or non-zero delay added by the test 451 instrument. 453 Forwarding Delay differs from latency [Br91] and one-way 454 delay [Al99] in several key regards: 456 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 457 uses "store and forward" or "bit forwarding" technology. 458 Forwarding Delay is the same metric, measured the same way, 459 regardless of the architecture of the DUT/SUT. 461 Network-layer Traffic Control Mechanisms 463 2. Forwarding Delay is a last-in, last-out (LILO) 464 measurement, unlike the last-in, first-out method [Br91] or 465 the first-in, last-out method [Al99]. 467 The LILO method most closely simulates the way a network- 468 layer device actually processes an IP datagram. IP datagrams 469 are not passed up and down the stack unless they are 470 complete, and processing begins only once the last bit of the 471 IP datagram has been received. 473 Further, the LILO method has an additive property, where the 474 sum of the parts MUST equal the whole. This is a key 475 difference from [Br91] and [Al99]. For example, the delay 476 added by two DUTs MUST equal the sum of the delay of the 477 DUTs. This may or may not be the case with [Br91] and 478 [Al99]. 480 3. Forwarding Delay measures the IP datagram only, unlike 481 [Br91], which also includes link layer overhead. 483 A metric focused exclusively on the Internet protocol 484 relieves the tester from specifying the start/end for every 485 link layer protocol that IP runs on. This avoids the need to 486 determine whether the start/stop delimiters are included. It 487 also allows the use of heterogeneous link layer protocols in 488 a test. 490 4. Forwarding Delay can be measured at any offered load, 491 whereas the latency methodology [Br99] recommends measurement 492 at, and only at, the throughput level. Comparing the 493 Forwarding Delay below the throughput to Forwarding Delay 494 above the Forwarding Capacity will give insight to the 495 traffic control mechanisms. 497 For example, non-congested delay may be measured with an 498 offered load that does not exceed the Forwarding Capacity, 499 while congested delay may involve an offered load that 500 exceeds Forwarding Capacity. 502 Note: Forwarding Delay SHOULD NOT be used as an absolute 503 indicator of DUT/SUT Forwarding Congestion. While Forwarding 504 Delay may rise when offered load nears or exceeds Forwarding 505 Capacity, there is no universal point at which Forwarding 506 Delay can be said to indicate the presence or absence of 507 Forwarding Congestion. 509 Measurement units: 510 Seconds. 512 Network-layer Traffic Control Mechanisms 514 See Also: 515 Latency [Br91] 516 Latency [Al99] 517 One-way Delay [Br99] 519 3.2.5 Jitter 521 Definition: 522 The absolute value of the difference between the arrival 523 delay of two consecutive received packets belonging to the 524 same stream. 526 Discussion: 527 The Forwarding Delay fluctuation between two consecutive 528 received packets in a stream is reported as the Jitter. 529 Jitter can be expressed as |D(i) - D(i-1)| where D equals 530 the Forwarding Delay and i is the order the packets were 531 received. 533 Under loss, jitter can be measured between non-consecutive 534 test sequence numbers. When IP Traffic Control Mechanisms 535 are dropping packets, fluctuating Forwarding Delay may be 536 observed. Jitter MUST be able to benchmark the delay 537 variation independent of packet 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. Also, 543 IPDV is undefined when one packet from a pair is lost. 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 558 diff-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 packets 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), the tester can derive the 596 out-of-sequence 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 sequence number less than 612 the sequence number of a previously arriving packet. 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 Packet loss does not affect the Out-of-order Packet count. 631 Only packets that were not received in the order that they 632 were transmitted. 634 Measurement units: 635 Packet count 637 See Also: 638 Stream 639 Test Sequence number 640 Packet Reordering Metric for IPPM [Mo03] 642 3.3.3 Duplicate Packet 644 Definition: 645 A received packet with a Test Sequence number matching a 646 previously received packet. 648 Discussion: 649 A Duplicate Packet is a packet that the DUT/SUT has 650 successfully transmitted out an egress interface more than 651 once. The egress interface has previously forwarded this 652 packet. 654 A Duplicate Packet SHOULD be a bit for bit copy of an already 655 transmitted packet (including Test Sequence number). If the 656 Duplicate Packet traversed different paths through the 657 DUT/SUT, some fields (such as TTL or checksum) may have 658 changed. 660 Network-layer Traffic Control Mechanisms 662 A multicast packet is not a Duplicate Packet by definition. 663 For a given IP multicast group, a DUT/SUT SHOULD forward a 664 packet once on a given egress interface provided the path to 665 one or more multicast receivers is through that interface. 666 Several egress interfaces will transmit the same packet, but 667 only once per interface. 669 To detect a Duplicate Packet, each offered packet to the 670 DUT/SUT MUST contain a unique packet-by-packet identifier. 672 Measurement units: 673 Packet count 675 See Also: 676 Stream 677 Test Sequence number 679 3.3.4 Stream 681 Definition: 682 A group of packets tracked as a single entity by the traffic 683 receiver. A stream may share a common content such as type 684 (IP, UDP), packet size, or payload. 686 Discussion: 687 Streams are tracked by test sequence number or "unique 688 signature field" [Ma00]. Streams define how individual 689 packets statistic are grouped together to form an 690 intelligible summary. 692 Common stream groupings would be by egress interface, 693 destination address, source address, DSCP, or IP precedence. 694 A stream using test sequence numbers can track the ordering 695 of packets as they transverse the DUT/SUT. 697 Streams are not restricted to a pair of source and 698 destination interfaces as long as all packets are tracked as 699 a single entity. A multicast stream can be forwarded to 700 multiple destination interfaces. 702 Measurement units: 703 n/a 705 See Also: 706 Flow 707 Microflow [Ni98] 708 Test sequence number 709 Network-layer Traffic Control Mechanisms 711 3.3.5 Test Sequence number 713 Definition: 714 A field in the IP payload portion of the packet that is used 715 to verify the order of the packets on the egress of the 716 DUT/SUT. 718 Discussion: 719 The traffic generator sets the test sequence number value and 720 the traffic receiver checks the value upon receipt of the 721 packet. The traffic generator changes the value on each 722 packet transmitted based on an algorithm agreed to by the 723 traffic receiver. 725 The traffic receiver keeps track of the sequence numbers on a 726 per stream basis. In addition to number of received packets, 727 the traffic receiver may also report the number of 728 in-sequence packets, number of out-of-sequence packets, 729 number of duplicate packets, and number of reordered packets. 731 The RECOMMENDED algorithm to use to change the sequence 732 number on sequential packets is an incrementing value. 734 Measurement units: 735 n/a 737 See Also: 738 Stream 740 3.4 Vectors 741 A vector is a group of packets all containing a specific DSCP 742 or IP precedence value. Vectors are expressed as a pair of 743 numbers. The first is being the particular diff-serv value. 744 The second is the metric expressed as a rate, loss 745 percentage, Forwarding Delay, or Jitter. 747 3.4.1 Intended Vector 749 Definition: 750 A vector describing the attempted rate at which packets 751 having a specific code-point (or IP precedence) are 752 transmitted to a DUT/SUT by an external source. 754 Discussion: 755 Intended loads across the different code-point classes 756 determine the metrics associated with a specific code-point 757 traffic class. 759 Measurement Units: 760 N-octets packets per second 761 Network-layer Traffic Control Mechanisms 763 See Also: 764 Offered Vector 765 Expected Forwarding Vector 766 Expected Loss Vector 767 Expected Sequence Vector 768 Expected Delay Vector 769 Expected Jitter Vector 770 Forwarding Vector 771 Loss Vector 773 3.4.2 Offered Vector 775 Definition: 776 A vector describing the measured rate at which packets having 777 a specific DSCP or IP precedence value are offered to the 778 DUT/SUT. 780 Discussion: 781 Offered loads across the different code-point classes, 782 constituting a code-point set, determine the metrics 783 associated with a specific code-point traffic class. 785 Measurement Units: 786 N-octets packets per second 788 See Also: 789 Expected Forwarding Vector 790 Expected Loss Vector 791 Expected Sequence Vector 792 Expected Delay Vector 793 Expected Jitter Vector 794 Forwarding Vector 795 Codepoint Set 797 3.4.3 Expected Vectors 799 3.4.3.1 Expected Forwarding Vector 801 Definition: 802 A vector describing the expected output rate of packets 803 having a specific DSCP or IP precedence value. The value is 804 dependent on the set of offered vectors and configuration of 805 the DUT. 807 Network-layer Traffic Control Mechanisms 809 Discussion: 810 The DUT is configured in a certain way in order that service 811 differentiation occurs for a particular DSCP or IP precedence 812 value when a specific traffic mix consisting of multiple 813 DSCPs or IP precedence values are applied. This term 814 attempts to capture the expected forwarding behavior when 815 subjected to a certain offered vectors. 817 The actual algorithm or mechanism the DUT uses to achieve 818 service differentiation is not important in describing the 819 expected forwarding vector. 821 Measurement units: 822 N-octet packets per second 824 See Also: 825 Intended Vector 826 Offered Vector 827 Output Vectors 828 Expected Loss Vector 829 Expected Sequence Vector 830 Expected Delay Vector 831 Expected Jitter Vector 833 3.4.3.2 Expected Loss Vector 835 Definition: 836 A vector describing the percentage of packets, having a 837 specific DSCP or IP precedence value that SHOULD NOT be 838 forwarded. The value is dependent on the set of offered 839 vectors and configuration of the DUT. 841 Discussion: 842 The DUT is configured in a certain way in order that service 843 differentiation occurs for a particular DSCP or IP precedence 844 value when a specific traffic mix consisting of multiple 845 DSCPs or IP precedence values are applied. This term 846 attempts to capture the expected forwarding behavior when 847 subjected to a certain offered vector. 849 The actual algorithm or mechanism the DUT uses to achieve 850 service differentiation is not important in describing the 851 expected loss vector. 853 Measurement Units: 854 Percentage of intended packets that is expected to be 855 dropped. 857 Network-layer Traffic Control Mechanisms 859 See Also: 860 Intended Vector 861 Offered Vector 862 Expected Forwarding Vector 863 Expected Sequence Vector 864 Expected Delay Vector 865 Expected Jitter Vector 866 One-way Packet Loss Metric [Ka99] 868 3.4.3.3 Expected Sequence Vector 870 Definition: 871 A vector describing the expected in-sequence packets having a 872 specific DSCP or IP precedence value. The value is dependent 873 on the set of offered vectors and configuration of the DUT. 875 Discussion: 876 The DUT is configured in a certain way in order that service 877 differentiation occurs for a particular DSCP or IP precedence 878 value when a specific traffic mix consisting of multiple 879 DSCPs or IP precedence values are applied. This term 880 attempts to capture the expected forwarding behavior when 881 subjected to certain offered vectors. 883 The actual algorithm or mechanism the DUT uses to achieve 884 service differentiation is not important in describing the 885 expected sequence vector. 887 Measurement Units: 888 N-octet packets per second 890 See Also: 891 Intended Vector 892 Offered Vector 893 Output Vectors 894 Expected Loss Vector 895 Expected Forwarding Vector 896 Expected Delay Vector 897 Expected Jitter Vector 899 3.4.3.4 Expected Instantaneous Delay Vector 901 Definition: 902 A vector describing the expected Forwarding Delay for packets 903 having a specific DSCP or IP precedence value. The value is 904 dependent on the set of offered vectors and configuration of 905 the DUT. 907 Network-layer Traffic Control Mechanisms 909 Discussion: 910 The DUT is configured in a certain way in order that service 911 differentiation occurs for a particular DSCP or IP precedence 912 value when a specific traffic mix consisting of multiple 913 DSCPs or IP precedence values are applied. This term 914 attempts to capture the expected forwarding behavior when 915 subjected to a certain offered vectors. 917 The actual algorithm or mechanism the DUT uses to achieve 918 service differentiation is not important in describing the 919 expected delay vector. 921 Measurement units: 922 Seconds. 924 See Also: 925 Forwarding Delay 926 Intended Vector 927 Offered Vector 928 Output Vectors 929 Expected Loss Vector 930 Expected Sequence Vector 931 Expected Forwarding Vector 932 Expected Jitter Vector 934 3.4.3.5 Expected Average Delay Vector 936 Definition: 937 A vector describing the expected average Forwarding Delay for 938 packets having a specific DSCP or IP precedence value. The 939 value is dependent on the set of offered vectors and 940 configuration of the DUT. 942 Discussion: 943 The DUT is configured in a certain way in order that service 944 differentiation occurs for a particular DSCP or IP precedence 945 value when a specific traffic mix consisting of multiple 946 DSCPs or IP precedence values are applied. This term 947 attempts to capture the expected forwarding behavior when 948 subjected to certain offered vectors. 950 The actual algorithm or mechanism the DUT uses to achieve 951 service differentiation is not important in describing the 952 expected average delay vector. 954 Measurement units: 955 Seconds. 957 Network-layer Traffic Control Mechanisms 959 See Also: 960 Intended Vector 961 Offered Vector 962 Output Vectors 963 Expected Loss Vector 964 Expected Sequence Vector 965 Expected Forwarding Vector 966 Expected Jitter Vector 968 3.4.3.6 Expected Maximum Delay Vector 970 Definition: 971 A vector describing the expected maximum Forwarding Delay for 972 packets having a specific DSCP or IP precedence value. The 973 value is dependent on the set of offered vectors and 974 configuration of the DUT. 976 Discussion: 977 The DUT is configured in a certain way in order that service 978 differentiation occurs for a particular DSCP or IP precedence 979 value when a specific traffic mix consisting of multiple 980 DSCPs or IP precedence values are applied. This term 981 attempts to capture the expected forwarding behavior when 982 subjected to certain offered vectors. 984 The actual algorithm or mechanism the DUT uses to achieve 985 service differentiation is not important in describing the 986 expected maximum delay vector. 988 Measurement units: 989 Seconds. 991 See Also: 992 Intended Vector 993 Offered Vector 994 Output Vectors 995 Expected Loss Vector 996 Expected Sequence Vector 997 Expected Forwarding Vector 998 Expected Jitter Vector 1000 3.4.3.7 Expected Minimum Delay Vector 1002 Definition: 1003 A vector describing the expected minimum Forwarding Delay for 1004 packets having a specific DSCP or IP precedence value. The 1005 value is dependent on the set of offered vectors and 1006 configuration of the DUT. 1008 Network-layer Traffic Control Mechanisms 1010 Discussion: 1011 The DUT is configured in a certain way in order that service 1012 differentiation occurs for a particular DSCP or IP precedence 1013 value when a specific traffic mix consisting of multiple 1014 DSCPs or IP precedence values are applied. This term 1015 attempts to capture the expected forwarding behavior when 1016 subjected to certain offered vectors. 1018 The actual algorithm or mechanism the DUT uses to achieve 1019 service differentiation is not important in describing the 1020 expected minimum delay vector. 1022 Measurement units: 1023 Seconds. 1025 See Also: 1026 Intended Vector 1027 Offered Vector 1028 Output Vectors 1029 Expected Loss Vector 1030 Expected Sequence Vector 1031 Expected Forwarding Vector 1032 Expected Jitter Vector 1034 3.4.3.8 Expected Instantaneous Jitter Vector 1036 Definition: 1037 A vector describing the expected jitter between two 1038 consecutive packets arrival times having a specific DSCP or 1039 IP precedence value. The value is dependent on the set of 1040 offered vectors and configuration of the DUT. 1042 Discussion: 1043 Instantaneous Jitter is the absolute value of the difference 1044 between the Forwarding Delay measurement of two packets 1045 belonging to the same stream. 1047 The Forwarding Delay fluctuation between two consecutive 1048 packets in a stream is reported as the "Instantaneous 1049 Jitter". Instantaneous Jitter can be expressed as 1050 |D(i) - D(i-1)| where D equals the Forwarding Delay and i is 1051 the test sequence number. Packets lost are not counted in 1052 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 Forwarding 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 Forwarding Delay of packet arrival times for packets having 1099 a specific DSCP or IP precedence value. The value is 1100 dependent on the set of offered vectors and configuration 1101 of the DUT. 1103 Discussion: 1104 Peak-to-peak Jitter Vector is the maximum Forwarding Delay 1105 minus the minimum Forwarding Delay of the packets (in a 1106 vector) forwarded by the 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 Forwarding Delay for a packet containing a specific 1240 DSCP or IP precedence value that a device can be observed 1241 to successfully transmit to the correct destination 1242 interface in 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 1247 Forwarding Delay value combine to make a vector. 1249 The Instantaneous Delay Vector represents Forwarding Delay 1250 on its specific DSCP or IP precedence value. It is not 1251 necessarily based on a stream or flow. The Delay vector 1252 may be expressed as per port of the DUT/SUT. However, 1253 it MUST be consistent 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. Instantaneous Delay vector 1258 can be obtained at any offered load. It is RECOMMENDED to 1259 obtain this vector at or below the Forwarding Capacity in the 1260 absence of Forwarding Congestion. For congested Forwarding 1261 Delay, run 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 Forwarding 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 Forwarding Delay for packets containing a 1285 specific DSCP or IP precedence value that a device can be 1286 observed to successfully transmit to the correct 1287 destination interface in response to an offered vector. 1289 Discussion: 1290 Average Delay vector is expressed as pair of numbers. 1291 Both the specific DSCP (or IP precedence) value AND 1292 Forwarding Delay value combine to make a vector. 1294 The Delay Vector represents Forwarding Delay on its specific 1295 DSCP or IP precedence value. It is not necessarily based 1296 on a stream or flow. The Delay vector may be expressed as 1297 per port of the DUT/SUT. However, it MUST be consistent 1298 with the Expect 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 Forwarding Delay, run the 1310 offered load above the Forwarding Capacity. 1312 Measurement Units: 1313 Seconds 1314 Network-layer Traffic Control Mechanisms 1316 See Also: 1317 Forwarding 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 Forwarding Delay from all packets containing a 1329 specific DSCP or IP precedence value that a device can be 1330 observed to successfully transmit to the correct destination 1331 interface in 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 Forwarding 1336 Delay value combine to make a vector. 1338 The Maximum Delay Vector represents Forwarding Delay on its 1339 specific DSCP or IP precedence value. It is not necessarily 1340 based on a stream or flow. The Maximum Delay vector may be 1341 expressed as per port of the DUT/SUT. However, it MUST be 1342 consistent 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 Forwarding 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 Forwarding Delay from all packets containing a 1369 specific DSCP or IP precedence value that a device can be 1370 observed to successfully transmit to the correct destination 1371 interface in 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 Forwarding Delay 1376 value combine to make a vector. 1378 The Minimum Delay Vector represents Forwarding Delay on its 1379 specific DSCP or IP precedence value. It is not necessarily 1380 based on a stream or flow. The Minimum Delay vector may be 1381 expressed as per port of the DUT/SUT. However, it MUST be 1382 consistent 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 Forwarding Delay, run the 1394 offered load above the Forwarding Capacity. 1396 Measurement Units: 1397 Seconds 1399 See Also: 1400 Forwarding 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 1410 Definition: 1411 The jitter for two consecutive packets containing a specific 1412 DSCP or IP precedence value that a device can be observed to 1413 successfully transmit to the correct destination interface in 1414 response to an offered vector. 1416 Network-layer Traffic Control Mechanisms 1418 Discussion: 1419 Instantaneous Jitter is the absolute value of the difference 1420 between the Forwarding Delay measurement of two packets 1421 belonging to the same stream. 1423 Jitter vector is expressed as pair of numbers. Both the 1424 specific DSCP (or IP precedence) value AND jitter value 1425 combine to make a vector. 1427 The Forwarding Delay fluctuation between two consecutive packets 1428 in a stream is reported as the "Instantaneous Jitter". 1429 Instantaneous Jitter Vector can be expressed as |D(i) - D(i-1)| 1430 where D equals the Forwarding Delay and i is the test sequence 1431 number. Packets lost are not counted in the measurement. 1433 Instantaneous Jitter Vector is a per-hop measurement. The 1434 DUT/SUT may change the specific DSCP or IP precedence value 1435 for a multiple-hop measurement. 1437 Forwarding Vector may contain several Instantaneous Jitter 1438 Vectors. For n packets received in a Forwarding Vector, 1439 there are exactly (n-1) Instantaneous Jitter Vectors. 1441 Measurement units: 1442 Seconds 1444 See Also: 1445 Forwarding Delay 1446 Jitter 1447 Forwarding Vector 1448 Stream 1449 Expected Vectors 1450 Average Jitter Vector 1451 Peak-to-peak Jitter Vector 1453 3.4.4.9 Average Jitter Vector 1455 Definition: 1456 The average jitter for packets containing a specific DSCP or 1457 IP precedence value that a device can be observed to 1458 successfully transmit to the correct destination interface in 1459 response to an offered vector. 1461 Discussion: 1462 Average Jitter Vector is the average of all the Instantaneous 1463 Jitter Vectors of the same DSCP or IP precedence value, 1464 measured during the test duration. 1466 Average Jitter vector is expressed as pair of numbers. Both 1467 the specific DSCP (or IP precedence) value AND jitter value 1468 combine to make a vector. 1470 Network-layer Traffic Control Mechanisms 1472 Average Jitter vector is a per-hop measurement. The DUT/SUT 1473 may change the specific DSCP or IP precedence value for a 1474 multiple-hop measurement. 1476 Measurement units: 1477 Seconds 1479 See Also: 1480 Jitter 1481 Forwarding Vector 1482 Stream 1483 Expected Vectors 1484 Instantaneous Jitter Vector 1485 Peak-to-peak Jitter Vector 1487 3.4.4.10 Peak-to-peak Jitter Vector 1489 Definition: 1490 The maximum possible variation in the Forwarding Delay for 1491 packets containing a specific DSCP or IP precedence value 1492 that a device can be observed to successfully transmit to 1493 the correct destination interface in response to an 1494 offered vector. 1496 Discussion: 1497 Peak-to-peak Jitter Vector is the maximum Forwarding Delay 1498 minus the minimum Forwarding Delay of the packets (in a 1499 vector) forwarded by the DUT/SUT. 1501 Jitter vector is expressed as pair of numbers. Both the 1502 specific DSCP (or IP precedence) value AND jitter value 1503 combine to make a vector. 1505 Peak-to-peak Jitter is not derived from the Instantaneous 1506 Jitter Vector. Peak-to-peak Jitter is based upon all the 1507 packets during the test duration, not just two consecutive 1508 packets. 1510 Measurement units: 1511 Seconds 1513 See Also: 1514 Jitter 1515 Forwarding Vector 1516 Stream 1517 Expected Vectors 1518 Average Jitter Vector 1519 Peak-to-peak Jitter Vector 1520 Network-layer Traffic Control Mechanisms 1522 4. IANA Considerations 1524 This document requires no IANA considerations. 1526 5. Security Considerations 1528 Documents of this type do not directly affect the security of 1529 the Internet or of corporate networks as long as benchmarking 1530 is not performed on devices or systems connected to 1531 production networks. 1533 Packets with unintended and/or unauthorized DSCP or IP 1534 precedence values may present security issues. Determining 1535 the security consequences of such packets is out of scope for 1536 this document. 1538 6. Acknowledgments 1540 The authors gratefully acknowledge the contributions of the 1541 IETF's benchmarking working group members in reviewing this 1542 document. The authors would like to express our thanks to 1543 David Newman for his consistent and valuable assistance 1544 throughout the development of this document. The authors 1545 would also like to thank Al Morton (acmorton@att.com) and 1546 Kevin Dubray (kdubray@juniper.net) for their ideas and 1547 support. 1549 7. References 1550 7.1 Normative References 1552 [Br91] Bradner, S., "Benchmarking Terminology for Network 1553 Interconnection Devices", RFC 1242, July 1991. 1555 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 1556 Requirement Levels", RFC 2119, March 1997 1558 [Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., 1559 Deering, S., Estrin, D., Floyd, S., Jacobson, V., 1560 Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, 1561 K., Shenker, S., Wroclawski, J. and L. Zhang, 1562 "Recommendations on Queue Management and Congestion 1563 Avoidance in the Internet", RFC 2309, April 1998. 1565 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1566 Switching Devices", RFC 2285, July 1998. 1568 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1569 of the Differentiated Services Field (DS Field) in the 1570 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1572 Network-layer Traffic Control Mechanisms 1574 7.2 Informative References 1576 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 1577 Metric for IPPM", RFC 2679, September 1999 1579 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1580 Weiss, W., "An Architecture for Differentiated Services", 1581 RFC 2475, December 1998. 1583 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 1584 Network Interconnect Devices", RFC 2544, March 1999 1586 [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 1587 Metric for IPPM", RFC 3393, November 2002 1589 [Ec98] http://www3.ietf.org/proceedings/98mar/ 1590 98mar-edited-135.htm 1592 [Fl93] Floyd, S., and Jacobson, V., "Random Early Detection 1593 gateways for Congestion Avoidance", IEEE/ACM 1594 Transactions on Networking, V.1 N.4, August 1993, p. 1595 397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf". 1597 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 1598 Forwarding PHB", RFC 2598, June 1999 1600 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1601 Packet Loss Metric for IPPM", RFC 2680, September 1999 1603 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 1604 Survey", RFC 1254, August 1991 1606 [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 1607 LAN Switching Devices", RFC 2889, August 2000 1609 [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1610 S., Perser, J., "Packet Reordering Metric for IPPM", 1611 Work in Progress 1613 [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1614 RFC 896, January 1984. 1616 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1617 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1618 January 1999. 1620 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1621 "RTP: A Transport Protocol for Real-Time Applications", 1622 RFC 1889, January 1996 1623 Network-layer Traffic Control Mechanisms 1625 8. Authors' Addresses 1627 Jerry Perser 1628 Veriwave 1629 USA 1630 EMail: jperser@veriwave.com 1632 Scott Poretsky 1633 Reef Point Systems 1634 8 New England Executive Park 1635 Burlington, MA 01803 1636 USA 1638 Phone: + 1 508 439 9008 1639 EMail: sporetsky@reefpoint.com 1641 Shobha Erramilli 1642 QNetworx Inc 1643 1119 Campus Drive West 1644 Morganville, NJ 07751 1645 USA 1647 EMail: shobha@qnetworx.com 1649 Sumit Khurana 1650 Telcordia Technologies 1651 445 South Street 1652 Morristown, NJ 07960 1653 USA 1655 Phone: + 1 973 829 3170 1656 EMail: sumit@research.telcordia.com 1657 Network-layer Traffic Control Mechanisms 1659 Full Copyright Statement 1661 Copyright (C) The Internet Society (2006). 1663 This document is subject to the rights, licenses and restrictions 1664 contained in BCP 78, and except as set forth therein, the authors 1665 retain all their rights. 1667 This document and the information contained herein are provided on an 1668 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1669 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1670 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1671 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1672 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1673 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1675 Intellectual Property 1677 The IETF takes no position regarding the validity or scope of any 1678 Intellectual Property Rights or other rights that might be claimed to 1679 pertain to the implementation or use of the technology described in 1680 this document or the extent to which any license under such rights 1681 might or might not be available; nor does it represent that it has 1682 made any independent effort to identify any such rights. Information 1683 on the procedures with respect to rights in RFC documents can be 1684 found in BCP 78 and BCP 79. 1686 Copies of IPR disclosures made to the IETF Secretariat and any 1687 assurances of licenses to be made available, or the result of an 1688 attempt made to obtain a general license or permission for the use of 1689 such proprietary rights by implementers or users of this 1690 specification can be obtained from the IETF on-line IPR repository at 1691 http://www.ietf.org/ipr. 1693 The IETF invites any interested party to bring to its attention any 1694 copyrights, patents or patent applications, or other proprietary 1695 rights that may cover technology that may be required to implement 1696 this standard. Please address the information to the IETF at ietf- 1697 ipr@ietf.org. 1699 Acknowledgement 1700 Funding for the RFC Editor function is currently provided by the 1701 Internet Society.