idnits 2.17.1 draft-ietf-bmwg-dsmterm-13.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 1601. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1625. ** 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 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 (December 2006) is 6339 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 1510, 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'St91' -- Obsolete informational reference (is this intentional?): RFC 2679 (ref. 'Al99') (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2598 (ref. 'Ja99') (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 2680 (ref. 'Ka99') (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 896 (ref. 'Na84') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2481 (ref. 'Ra99') (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. 'Sc96') (Obsoleted by RFC 3550) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Scott Poretsky 2 INTERNET-DRAFT Reef Point Systems 3 Expires in: December 2006 4 Jerry Perser 5 Veriwave 7 Shobha Erramilli 8 Telcordia 10 Sumit Khurana 11 Telcordia 13 June 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 using packet classification 50 based on defined criteria. The terminology is to be applied to 51 measurements made on the data plane to evaluate IP traffic control 52 mechanisms. Rules for packet classification can be based on any 53 field in the IP header, such as DSCP, or field in the packet 54 payload, such as port number. 56 Network-layer Traffic Control Mechanisms 58 Table of Contents 59 1. Introduction .............................................. 3 60 2. Existing definitions ...................................... 3 61 3. Term definitions............................................4 62 3.1 Configuration Terms 63 3.1.1 Classification.........................................4 64 3.1.2 Codepoint Set..........................................4 65 3.1.3 Forwarding Congestion..................................5 66 3.1.4 Congestion Management..................................6 67 3.1.5 Flow...................................................7 68 3.2 Measurement Terms 69 3.2.1 Forwarding Capacity....................................7 70 3.2.2 Conforming Packet......................................8 71 3.2.3 Nonconforming Packet...................................9 72 3.2.4 Forwarding Delay.......................................9 73 3.2.5 Jitter................................................11 74 3.2.6 Undifferentiated Response.............................11 75 3.3 Sequence Tracking 76 3.3.1 In-sequence Packet....................................12 77 3.3.2 Out-of-order Packet...................................12 78 3.3.3 Duplicate Packet......................................13 79 3.3.4 Stream................................................14 80 3.3.5 Test Sequence number .................................15 81 3.4 Vectors...................................................15 82 3.4.1 Intended Vector.......................................15 83 3.4.2 Offered Vector........................................16 84 3.4.3 Expected Vectors......................................16 85 3.4.4 Output Vectors........................................23 86 4. IANA Considerations........................................31 87 5. Security Considerations....................................31 88 6. Acknowledgments............................................31 89 7. References.................................................32 90 8. Author's Address...........................................33 91 9. Full Copyright Statement...................................34 93 1. Introduction 95 New terminology is needed because most existing measurements 96 assume the absence of congestion and only a single per-hop- 97 behavior. This document introduces several new terms that will 98 allow measurements to be taken during periods of congestion. 100 Another key difference from existing terminology is the definition 101 of measurements as observed on egress as well as ingress of a 102 device/system under test. Again, the existence of congestion 103 requires the addition of egress measurements as well as those 104 taken on ingress; without observing traffic leaving a 105 device/system it is not possible to say whether traffic-control 106 mechanisms effectively dealt with congestion. 108 Network-layer Traffic Control Mechanisms 110 The principal measurements introduced in this document are vectors 111 for rate, delay, and jitter, all of which can be observed with or 112 without congestion of the Device Under Test (DUT)/ System Under 113 Test (SUT). This document describes only those terms relevant to 114 measuring behavior of a DUT or SUT at the Egress during periods of 115 congestion. End-to-end and service-level measurements are beyond 116 the scope of this document. 118 2. Existing definitions 119 RFC 1224 "Techniques for Managing Asynchronously Generated Alerts" 120 [St91] is used for 'Time with fine enough units to distinguish 121 between two events' 123 RFC 1242 "Benchmarking Terminology for Network Interconnect 124 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 125 Devices" should be consulted before attempting to make use of this 126 document. 128 RFC 2474 "Definition of the Differentiated Services Field (DS 129 Field) in the IPv4 and IPv6 Headers" section 2, contains 130 discussions of a number of terms relevant to network-layer traffic 131 control mechanisms and should also be consulted. 133 For the sake of clarity and continuity this RFC adopts the 134 template for definitions set out in Section 2 of RFC 1242. 135 Definitions are indexed and grouped together in sections for ease 136 of reference. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP 14, RFC 2119 141 [Br97]. RFC 2119 defines the use of these key words to help make the 142 intent of standards track documents as clear as possible. While this 143 document uses these keywords, this document is not a standards track 144 document. 146 2.1 Frequently Used Acronyms 147 DA Destination Address 148 DS DiffServ 149 DSCP DiffServ Code Point 150 DUT Device Under Test 151 IP Internet Protocol 152 PHB Per Hop Behavior 153 SA Source Address 154 SUT System Under Test 155 Network-layer Traffic Control Mechanisms 157 3. Term definitions 159 3.1 Configuration Terms 161 3.1.1 Classification 163 Definition: 164 Selection of packets according to defined rules. 166 Discussion: 167 Classification determines the per-hop behaviors and traffic 168 conditioning functions such as shaping and dropping that 169 are to be applied to the packet. 171 Classification of packets can be made based on the DS field 172 or IP Precedence in the packet header. Classification can 173 be based on other IP header fields such as IP Source 174 Address (SA), Destination Address (DA), and protocol, or 175 fields in the packet payload such as port number. 176 Classification can also be based on ingress interface. 177 It is possible to classify based on Multi-Field (MF) 178 criteria such as IP source and destination addresses, 179 protocol and port number. 181 Measurement units: n/a 183 See Also: None 185 3.1.2 Codepoint Set 187 Definition: 188 The set of all DS Code-points or IP precedence values used 189 during the test duration. 191 Discussion: 192 Describes all the code-point markings associated with packets 193 that are input to the DUT/SUT. For each entry in the 194 codepoint set, there are associated vectors describing the 195 rate of traffic, delay, loss, or jitter containing that 196 particular DSCP or IP precedence value. 198 The treatment that a packet belonging to a particular code- 199 point gets is subject to the DUT classifying packets to map 200 to the correct PHB. Moreover, the forwarding treatment in 201 general is also dependent on the complete set of offered 202 vectors. 204 Measurement Units: n/a 206 See Also: None 207 Network-layer Traffic Control Mechanisms 209 3.1.3 Forwarding Congestion 211 Definition: 212 A condition in which one or more egress interfaces are 213 offered more packets than are forwarded. 215 Discussion: 216 This condition is a superset of the overload definition 217 [Ma98]. Overload [Ma98] deals with overloading input and 218 output interfaces beyond the maximum transmission allowed by 219 the medium. Forwarding congestion does not assume ingress 220 interface overload as the only source of overload on output 221 interfaces. 223 Another difference between Forwarding Congestion and overload 224 occurs when the SUT comprises multiple elements, in that 225 Forwarding Congestion may occur at multiple points. Consider 226 a SUT comprising multiple edge devices exchanging traffic 227 with a single core device. Depending on traffic patterns, 228 the edge devices may induce Forwarding Congestion on multiple 229 egress interfaces on the core device. 231 Throughput [Br91] defines the lower boundary of Forwarding 232 Congestion. Throughput is the maximum offered rate with no 233 Forwarding Congestion. At offered rates above throughput, 234 the DUT/SUT is considered to be in a state of Forwarding 235 Congestion. 237 Packet Loss, not increased Forwarding Delay, is the 238 external observable metric used to indicate the condition 239 of Forwarding Congestion. Packet Loss is a deterministic 240 indicator of Forwarding Congestion. The condition of 241 increased Forwarding Delay without Packet Loss is an 242 indicator of Forwarding Congestion known as Incipient 243 Congestion. Incipient Congestion is a non-deterministic 244 indicator of Forwarding Congestion [Fl93]. As stated in 245 [Ec98], RED [Br98] detects incipient congestion before the 246 buffer overflows, but the current Internet environment is 247 limited to packet loss as the mechanism for indicating 248 congestion to the end-nodes. [Ra99] implies that it is 249 impractical to build a black-box test to observe Incipient 250 Congestion. [Ra99] instead introduces Explicit Congestion 251 Notification (ECN) as a deterministic Black-Box method for 252 observing Incipient Congestion. [Ra99] is an Experimental 253 RFC with limited deployment, so ECN is not used for this 254 particular methodology. For the purpose of "black-box" 255 testing a DUT/SUT, this methodology uses Packet Loss as the 256 indicator of Forwarding Congestion. 258 Network-layer Traffic Control Mechanisms 260 Ingress observations alone are not sufficient to cover all 261 cases in which Forwarding Congestion may occur. A device 262 with an infinite amount of memory could buffer an infinite 263 number of packets, and eventually forward all of them. 264 However, these packets may or may not be forwarded during 265 the test duration. Congestion Collapse [Na84] is defined 266 as the state in which buffers are full and all arriving 267 packets MUST be dropped across the network. Even though 268 ingress interfaces accept all packets without loss, 269 Forwarding Congestion is present in this hypothetical 270 device. 272 The definition presented here explicitly defines 273 Forwarding Congestion as an event observable on egress 274 interfaces. Regardless of internal architecture, any 275 device exhibiting Packet Loss on one or more egress 276 interfaces is experiencing Forwarding Congestion. 278 Measurement units: 279 None 281 See Also: 282 Gateway Congestion Control Survey [Ma91] 284 3.1.4 Congestion Management 286 Definition: 287 An implementation of one or more per-hop-behaviors to avoid 288 or minimize the condition of congestion. 290 Discussion: 291 Congestion management may seek either to control congestion 292 or avoid it altogether through Classification. 294 Congestion avoidance mechanisms seek to prevent congestion 295 before it actually occurs. 297 Congestion control mechanisms give one or more flows (with a 298 discrete IP Precedence or DSCP value) preferential treatment 299 over other classes during periods of congestion. 301 Measurement units: 302 n/a 304 See Also: 305 Classification 306 Network-layer Traffic Control Mechanisms 308 3.1.5 Flow 310 Definition: 311 A flow is a one or more of packets sharing a common intended 312 pair of ingress and egress interfaces. 314 Discussion: 315 Packets are grouped by the ingress and egress interfaces they 316 use on a given DUT/SUT. 318 A flow can contain multiple source IP addresses and/or 319 destination IP addresses. All packets in a flow MUST enter 320 on the same ingress interface and exit on the same egress 321 interface, and have some common network layer content. 323 Microflows [Ni98] are a subset of flows. As defined in 324 [Ni98], microflows require application-to-application 325 measurement. In contrast, flows use lower-layer 326 classification criteria. Since this document focuses on 327 network-layer classification criteria, we concentrate here on 328 the use of network-layer identifiers in describing a flow. 329 Flow identifiers also may reside at the data-link, transport, 330 or application layers of the OSI model. However, identifiers 331 other than those at the network layer are out of scope for 332 this document. 334 A flow may contain a single code point/IP precedence value or 335 may contain multiple values destined for a single egress 336 interface. This is determined by the test methodology. 338 Measurement units: 339 n/a 341 See Also: 342 Microflow [Ni98] 343 Streams 345 3.2 Measurement Terms 347 3.2.1 Forwarding Capacity 349 Definition: 350 The number of packets per second that a device can be 351 observed to successfully transmit to the correct destination 352 interface in response to a specified offered load while the 353 device drops none of the offered packets. 355 Discussion: 356 Forwarding Capacity measures the packet rate at the egress 357 interface(s) of the DUT/SUT. In contrast, throughput as 358 defined in RFC 1242 measures the packet rate at the ingress 359 interface(s) of the DUT/SUT. 361 Network-layer Traffic Control Mechanisms 363 Ingress-based measurements do not account for queuing of the 364 DUT/SUT. Throughput rates can be higher than the Forwarding 365 Capacity because of queueing. The difference is dependent 366 upon test duration, packet rate, and queue size. Forwarding 367 Capacity, as an egress measurement, does take queuing into 368 account. 370 Understanding Forwarding Capacity is a necessary precursor to 371 any measurement involving Traffic Control Mechanisms. The 372 accompanying methodology document MUST take into 373 consideration Forwarding Capacity when determining the 374 expected forwarding vectors. When the sum of the expected 375 forwarding vectors on an interface exceeds the Forwarding 376 Capacity, the Forwarding Capacity will govern the forwarding 377 rate. 379 This measurement differs from forwarding rate at maximum 380 offered load (FRMOL) [Ma98] in that Forwarding Capacity 381 requires zero loss. 383 Measurement units: 384 N-octet packets per second 386 See Also: 387 Throughput [Br91] 388 Forwarding Rate at Maximum Offered Load [Ma98] 390 3.2.2 Conforming Packet 392 Definition: 393 Packets which lie within specific rate, delay, or jitter 394 bounds. 396 Discussion: 397 A DUT/SUT may be configured to allow a given traffic class to 398 consume a given amount of bandwidth, or to fall within 399 predefined delay or jitter boundaries. All packets that lie 400 within specified bounds are then said to be conforming, 401 whereas those outside the bounds are nonconforming. 403 Measurement units: 404 n/a 406 See Also: 407 Expected Vector 408 Forwarding Vector 409 Offered Vector 410 Nonconforming 411 Network-layer Traffic Control Mechanisms 413 3.2.3 Nonconforming Packet 415 Definition: 416 Packets that do not lie within specific rate, delay, or 417 jitter bounds. 419 Discussion: 420 A DUT/SUT may be configured to allow a given traffic class to 421 consume a given amount of bandwidth, or to fall within 422 predefined delay or jitter boundaries. All packets that do 423 not lie within these bounds are then said to be 424 nonconforming. 426 Measurement units: 427 n/a 429 See Also: 430 Expected Vector 431 Forwarding Vector 432 Offered Vector 433 Conforming 435 3.2.4 Forwarding Delay 437 Definition: 438 The time interval starting when the last bit of the input IP 439 packet is offered to the input port of the DUT/SUT and ending 440 when the last bit of the output IP packet is received from 441 the output port of the DUT/SUT. 443 Discussion: 444 The delay time interval MUST be externally observed. The 445 delay measurement MUST NOT include delays added by test bed 446 components other than the DUT/SUT, such as propagation time 447 introduced by cabling or non-zero delay added by the test 448 instrument. Forwarding Delay differs from latency [Br91] 449 and one-way delay [Al99] in several key regards: 451 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 452 uses "store and forward" or "bit forwarding" technology. 453 Forwarding Delay is the same metric, measured the same way, 454 regardless of the architecture of the DUT/SUT. 456 2. Forwarding Delay is a last-in, last-out (LILO) 457 measurement, unlike the last-in, first-out method [Br91] or 458 the first-in, last-out method [Al99]. 460 The LILO method most closely simulates the way a network- 461 layer device actually processes an IP datagram. IP datagrams 462 are not passed up and down the stack unless they are 463 complete, and processing begins only once the last bit of the 464 IP datagram has been received. 466 Network-layer Traffic Control Mechanisms 468 Further, the LILO method has an additive property, where the 469 sum of the parts MUST equal the whole. This is a key 470 difference from [Br91] and [Al99]. For example, the delay 471 added by two DUTs MUST equal the sum of the delay of the 472 DUTs. This may or may not be the case with [Br91] and 473 [Al99]. 475 3. Forwarding Delay measures the IP datagram only, unlike 476 [Br91], which also includes link layer overhead. 478 A metric focused exclusively on the Internet protocol 479 relieves the tester from specifying the start/end for every 480 link layer protocol that IP runs on. This avoids the need to 481 determine whether the start/stop delimiters are included. It 482 also allows the use of heterogeneous link layer protocols in 483 a test. 485 4. Forwarding Delay can be measured at any offered load, 486 whereas the latency methodology [Br99] recommends measurement 487 at, and only at, the throughput level. Comparing the 488 Forwarding Delay below the throughput to Forwarding Delay 489 above the Forwarding Capacity will give insight to the 490 traffic control mechanisms. 492 For example, non-congested delay may be measured with an 493 offered load that does not exceed the Forwarding Capacity, 494 while congested delay may involve an offered load that 495 exceeds Forwarding Capacity. 497 Note: Forwarding Delay SHOULD NOT be used as an absolute 498 indicator of DUT/SUT Forwarding Congestion. While Forwarding 499 Delay may rise when offered load nears or exceeds Forwarding 500 Capacity, there is no universal point at which Forwarding 501 Delay can be said to indicate the presence or absence of 502 Forwarding Congestion. 504 Measurement units: 505 milliseconds 507 See Also: 508 Latency [Br91] 509 Latency [Al99] 510 One-way Delay [Br99] 511 Network-layer Traffic Control Mechanisms 513 3.2.5 Jitter 515 Definition: 516 The absolute value of the difference between the arrival 517 delay of two consecutive received packets belonging to the 518 same stream. 520 Discussion: 521 The Forwarding Delay fluctuation between two consecutive 522 received packets in a stream is reported as the Jitter. 523 Jitter can be expressed as |D(i) - D(i-1)| where D equals 524 the Forwarding Delay and i is the order the packets were 525 received. 527 Under loss, jitter can be measured between non-consecutive 528 test sequence numbers. When IP Traffic Control Mechanisms 529 are dropping packets, fluctuating Forwarding Delay may be 530 observed. Jitter MUST be able to benchmark the delay 531 variation independent of packet loss. 533 Jitter is related to the IPDV [De02] (IP Delay Variation) by 534 taking the absolute value of the ipdv. The two metrics will 535 produce different mean values. Mean Jitter will produce a 536 positive value, where the mean ipdv is typically zero. Also, 537 IPDV is undefined when one packet from a pair is lost. 539 Measurement units: 540 milliseconds 542 See Also: 543 Forwarding Delay 544 Jitter variation [Ja99] 545 ipdv [De02] 546 interarrival jitter [Sc96] 548 3.2.6 Undifferentiated Response 550 Definition: 551 The vector(s) obtained when mechanisms used to support 552 diff-serv or IP precedence are disabled. 554 Discussion: 555 Enabling diff-serv or IP precedence mechanisms may impose 556 additional processing overhead for packets. This overhead 557 may degrade performance even when traffic belonging to only 558 one class, the best-effort class, is offered to the device. 559 Measurements with "undifferentiated response" SHOULD be made 560 to establish a baseline. 562 Network-layer Traffic Control Mechanisms 564 The vector(s) obtained with DSCP or IP precedence enabled can 565 be compared to the undifferentiated response to determine the 566 effect of differentiating traffic. 568 Measurement units: 569 n/a 571 3.3 Sequence Tracking 573 3.3.1 In-sequence Packet 575 Definition: 576 A received packet with the expected Test Sequence number. 578 Discussion: 579 In-sequence is done on a stream level. As packets are 580 received on a stream, each packets Test Sequence number is 581 compared with the previous packet. Only packets that match 582 the expected Test Sequence number are considered in-sequence. 584 Packets that do not match the expected Test Sequence number 585 are counted as "not in-sequence" or out-of-sequence. Every 586 packet that is received is either in-sequence or out-of- 587 sequence. Subtracting the in-sequence from the received 588 packets (for that stream), the tester can derive the 589 out-of-sequence count. 591 Two types of events will prevent the in-sequence from 592 incrementing: packet loss and reordered packets. 594 Measurement units: 595 Packet count 597 See Also: 598 Stream 599 Test Sequence number 601 3.3.2 Out-of-order Packet 603 Definition: 604 A received packet with a sequence number less than 605 the sequence number of a previously arriving packet. 607 Network-layer Traffic Control Mechanisms 609 Discussion: 610 As a stream of packets enters a DUT/SUT, they include a 611 Stream Test Sequence number indicating the order the packets 612 were sent to the DUT/SUT. On exiting the DUT/SUT, these 613 packets may arrive in a different order. Each packet that 614 was re-ordered is counted as an Out-of-order Packet. 616 Certain streaming protocol (such as TCP) require the packets 617 to be in a certain order. Packets outside this are dropped 618 by the streaming protocols even though there were properly 619 received by the IP layer. The type of reordering tolerated 620 by a streaming protocol varies from protocol to protocol, and 621 also by implementation. 623 Packet loss does not affect the Out-of-order Packet count. 624 Only packets that were not received in the order that they 625 were transmitted. 627 Measurement units: 628 packets 630 See Also: 631 Stream 632 Test Sequence number 633 Packet Reordering Metric for IPPM [Mo03] 635 3.3.3 Duplicate Packet 637 Definition: 638 A received packet with a Test Sequence number matching a 639 previously received packet. 641 Discussion: 642 A Duplicate Packet is a packet that the DUT/SUT has 643 successfully transmitted out an egress interface more than 644 once. The egress interface has previously forwarded this 645 packet. 647 A Duplicate Packet SHOULD be a bit for bit copy of an already 648 transmitted packet (including Test Sequence number). If the 649 Duplicate Packet traversed different paths through the 650 DUT/SUT, some fields (such as TTL or checksum) may have 651 changed. 653 A multicast packet is not a Duplicate Packet by definition. 654 For a given IP multicast group, a DUT/SUT SHOULD forward a 655 packet once on a given egress interface provided the path to 656 one or more multicast receivers is through that interface. 657 Several egress interfaces will transmit the same packet, but 658 only once per interface. 660 Network-layer Traffic Control Mechanisms 662 To detect a Duplicate Packet, each offered packet to the 663 DUT/SUT MUST contain a unique packet-by-packet identifier. 665 Measurement units: 666 Packet count 668 See Also: 669 Stream 670 Test Sequence number 672 3.3.4 Stream 674 Definition: 675 A group of packets tracked as a single entity by the traffic 676 receiver. A stream MUST share common content such as type 677 (IP, UDP), IP SA/DA, packet size, or payload. 679 Discussion: 680 Streams are tracked by test sequence number or "unique 681 signature field" [Ma00]. Streams define how individual 682 packets statistic are grouped together to form an 683 intelligible summary. 685 Common stream groupings would be by egress interface, 686 destination address, source address, DSCP, or IP precedence. 687 A stream using test sequence numbers can track the ordering 688 of packets as they traverse the DUT/SUT. 690 Streams are not restricted to a pair of source and 691 destination interfaces as long as all packets are tracked as 692 a single entity. A multicast stream can be forwarded to 693 multiple destination interfaces. 695 Measurement units: 696 n/a 698 See Also: 699 Flow 700 Microflow [Ni98] 701 Test sequence number 702 Network-layer Traffic Control Mechanisms 704 3.3.5 Test Sequence Number 705 Definition: 706 A field in the IP payload portion of the packet that is used 707 to verify the order of the packets on the egress of the 708 DUT/SUT. 710 Discussion: 711 The traffic generator sets the test sequence number value and 712 the traffic receiver checks the value upon receipt of the 713 packet. The traffic generator changes the value on each 714 packet transmitted based on an algorithm agreed to by the 715 traffic receiver. 717 The traffic receiver keeps track of the sequence numbers on a 718 per stream basis. In addition to number of received packets, 719 the traffic receiver may also report the number of 720 in-sequence packets, number of out-of-sequence packets, 721 number of duplicate packets, and number of reordered packets. 722 The RECOMMENDED algorithm to use to change the sequence 723 number on sequential packets is an incrementing value. 725 Measurement units: 726 n/a 728 See Also: 729 Stream 731 3.4 Vectors 732 A vector is a group of packets all matching a specific 733 classification criteria, such as DSCP. Vectors are 734 identified by the classification criteria and benchmarking 735 metrics such as a Forwarding Capacity, Forwarding Delay, 736 or Jitter. 738 3.4.1 Intended Vector 739 Definition: 740 A description of the configuration on an external source 741 for the attempted rate of a stream transmitted to a DUT/SUT 742 matching specific classification rules. 744 Discussion: 745 The Intended Vector of a stream influences the benchmark 746 measurements. The Intended Vector is described by the 747 classification criteria and attempted rate. 749 Measurement Units: 750 N-bytes packets per second 752 See Also: 753 Stream 754 Offered Vector 755 Forwarding Vector 756 Network-layer Traffic Control Mechanisms 758 3.4.2 Offered Vector 760 Definition: 761 A description for the attempted rate of a stream offered to 762 a DUT/SUT matching specific classification rules. 764 Discussion: 765 The Offered Vector of a stream influences the benchmark 766 measurements. The Offered Vector is described by the 767 classification criteria and offered rate. 769 Measurement Units: 770 N-bytes packets per second 772 See Also: 773 Stream 774 Intended Vector 775 Forwarding Vector 777 3.4.3 Expected Vectors 778 3.4.3.1 Expected Forwarding Vector 780 Definition: 781 A description of the expected output rate of packets 782 matching a specific classification, such as DSCP. 784 Discussion: 785 The value of the Expected Minimum Delay Vector is dependent 786 on the set of offered vectors and Classification 787 configuration on the DUT/SUT. The DUT is configured in a 788 certain way in order that classification occurs when a 789 traffic mix consisting of multiple streams is applied. 791 This term captures the expected forwarding behavior from the 792 DUT receiving multiple Offered Vectors. The actual algorithm 793 or mechanism the DUT uses to achieve service differentiation 794 is implementation specific and not important when describing 795 the Expected Forwarding Vector. 797 Measurement units: 798 N-octet packets per second 800 See Also: 801 Classification 802 Stream 803 Intended Vector 804 Offered Vector 805 Network-layer Traffic Control Mechanisms 807 3.4.3.2 Expected Loss Vector 809 Definition: 810 A description of the percentage of packets, having a 811 specific classification that SHOULD NOT be forwarded. 813 Discussion: 814 The value of the Expected Minimum Delay Vector is dependent 815 on the set of offered vectors and Classification 816 configuration on the DUT/SUT. The DUT is configured in a 817 certain way in order that classification occurs when a 818 traffic mix consisting of multiple streams is applied. 820 This term captures the expected forwarding behavior from the 821 DUT receiving multiple Offered Vectors. The actual algorithm 822 or mechanism the DUT uses to achieve service differentiation 823 is implementation specific and not important when describing 824 the Expected Loss Vector. 826 Measurement Units: 827 Percentage of intended packets that is expected to be 828 dropped. 830 See Also: 831 Classification 832 Stream 833 Intended Vector 834 Offered Vector 835 One-way Packet Loss Metric [Ka99] 837 3.4.3.3 Expected Sequence Vector 839 Definition: 840 A description of the expected in-sequence packets matching 841 a specific classification, such as DSCP. 843 Discussion: 844 The value of the Expected Minimum Delay Vector is dependent 845 on the set of offered vectors and Classification 846 configuration on the DUT/SUT. The DUT is configured in a 847 certain way in order that classification occurs when a 848 traffic mix consisting of multiple streams is applied. 850 This term captures the expected forwarding behavior from the 851 DUT receiving multiple Offered Vectors. The actual algorithm 852 or mechanism the DUT uses to achieve service differentiation 853 is implementation specific and not important when describing 854 the Expected Sequence Vector. 856 Network-layer Traffic Control Mechanisms 858 Measurement Units: 859 N-octet packets per second 861 See Also: 862 Classification 863 Stream 864 In-Sequence Packet 865 Intended Vector 866 Offered Vector 868 3.4.3.4 Expected Delay Vector 870 Definition: 871 A description of the expected instantaneous Forwarding 872 Delay for packets matching a specific classification, such 873 as DSCP. 875 Discussion: 876 The value of the Expected Minimum Delay Vector is dependent 877 on the set of offered vectors and Classification 878 configuration on the DUT/SUT. The DUT is configured in a 879 certain way in order that classification occurs when a 880 traffic mix consisting of multiple streams is applied. 882 This term captures the expected forwarding behavior from the 883 DUT receiving multiple Offered Vectors. The actual algorithm 884 or mechanism the DUT uses to achieve service differentiation 885 is implementation specific and not important when describing 886 the Expected Delay Vector. 888 Measurement units: 889 milliseconds 891 See Also: 892 Classification 893 Stream 894 Forwarding Delay 895 Intended Vector 896 Offered Vector 898 3.4.3.5 Expected Average Delay Vector 900 Definition: 901 A description of the expected average Forwarding Delay 902 for packets matching a specific classification, such as 903 DSCP. 905 Network-layer Traffic Control Mechanisms 907 Discussion: 908 The value of the Expected Minimum Delay Vector is dependent 909 on the set of offered vectors and Classification 910 configuration on the DUT/SUT. The DUT is configured in a 911 certain way in order that classification occurs when a 912 traffic mix consisting of multiple streams is applied. 914 This term captures the expected forwarding behavior from the 915 DUT receiving multiple Offered Vectors. The actual algorithm 916 or mechanism the DUT uses to achieve service differentiation 917 is implementation specific and not important when describing 918 the Expected Average Delay Vector. 920 Measurement units: 921 milliseconds 923 See Also: 924 Classification 925 Stream 926 Forwarding Delay 927 Intended Vector 928 Offered Vector 929 Expected Delay Vector 931 3.4.3.6 Expected Maximum Delay Vector 933 Definition: 934 A description of the expected maximum Forwarding Delay 935 for packets matching a specific classification, such as 936 DSCP. 938 Discussion: 939 The value of the Expected Minimum Delay Vector is dependent 940 on the set of offered vectors and Classification 941 configuration on the DUT/SUT. The DUT is configured in a 942 certain way in order that classification occurs when a 943 traffic mix consisting of multiple streams is applied. 945 This term captures the expected forwarding behavior from the 946 DUT receiving multiple Offered Vectors. The actual algorithm 947 or mechanism the DUT uses to achieve service differentiation 948 is implementation specific and not important when describing 949 the Expected Maximum Delay Vector. 951 Measurement units: 952 milliseconds 953 Network-layer Traffic Control Mechanisms 955 See Also: 956 Classification 957 Stream 958 Forwarding Delay 959 Intended Vector 960 Offered Vector 961 Expected Delay Vector 963 3.4.3.7 Expected Minimum Delay Vector 965 Definition: 966 A description of the expected minimum Forwarding Delay 967 for packets matching a specific classification, such as 968 DSCP. 970 Discussion: 971 The value of the Expected Minimum Delay Vector is dependent 972 on the set of offered vectors and Classification 973 configuration on the DUT/SUT. The DUT is configured in a 974 certain way in order that classification occurs when a 975 traffic mix consisting of multiple streams is applied. 977 This term captures the expected forwarding behavior from the 978 DUT receiving multiple Offered Vectors. The actual algorithm 979 or mechanism the DUT uses to achieve service differentiation 980 is implementation specific and not important when describing 981 the Expected Minimum Delay Vector. 983 Measurement units: 984 milliseconds 986 See Also: 987 Classification 988 Stream 989 Forwarding Delay 990 Intended Vector 991 Offered Vector 992 Expected Delay Vector 994 3.4.3.8 Expected Instantaneous Jitter Vector 996 Definition: 997 A description of the expected instantaneous jitter between two 998 consecutive packets arrival times matching a specific 999 classification, such as DSCP. 1001 Discussion: 1002 Instantaneous Jitter is the absolute value of the difference 1003 between the Forwarding Delay measurement of two packets 1004 belonging to the same stream. 1006 Network-layer Traffic Control Mechanisms 1008 The Forwarding Delay fluctuation between two consecutive 1009 packets in a stream is reported as the "Instantaneous 1010 Jitter". Instantaneous Jitter can be expressed as 1011 |D(i) - D(i-1)| where D equals the Forwarding Delay and i is 1012 the test sequence number. Packets lost are not counted in 1013 the measurement. 1015 Forwarding Vector may contain several Jitter Vectors. For n 1016 packets received in a Forwarding Vector, there is a total of 1017 (n-1) Instantaneous Jitter Vectors. 1019 Measurement units: 1020 milliseconds 1022 See Also: 1023 Classification 1024 Stream 1025 Jitter 1026 Intended Vector 1027 Offered Vector 1029 3.4.3.9 Expected Average Jitter Vector 1031 Definition: 1032 A description of the expected average jitter for packets 1033 arriving in a stream matching a specific classification, such 1034 as DSCP. 1036 Discussion: 1037 Average Jitter Vector is the average of all the Instantaneous 1038 Jitter Vectors measured during the test duration for the same 1039 stream. 1041 The value of the Expected Average Jitter Vector is dependent 1042 on the set of offered vectors and Classification 1043 configuration on the DUT/SUT. The DUT is configured in a 1044 certain way in order that classification occurs when a 1045 traffic mix consisting of multiple streams is applied. 1047 This term captures the expected forwarding behavior from the 1048 DUT receiving multiple Offered Vectors. The actual algorithm 1049 or mechanism the DUT uses to achieve service differentiation 1050 is implementation specific and not important when describing 1051 the Expected Average Jitter Vector. 1053 Measurement units: 1054 milliseconds 1055 Network-layer Traffic Control Mechanisms 1057 See Also: 1058 Classification 1059 Stream 1060 Jitter 1061 Intended Vector 1062 Offered Vector 1063 Expected Instantaneous Jitter Vector 1065 3.4.3.10 Expected Peak-to-peak Jitter Vector 1067 Definition: 1068 A description of the expected maximum variation in the 1069 Forwarding Delay of packet arrival times for packets 1070 arriving in a stream matching a specific classification, 1071 such as DSCP. 1073 Discussion: 1074 Peak-to-peak Jitter Vector is the maximum Forwarding Delay 1075 minus the minimum Forwarding Delay of the packets (in a 1076 vector) forwarded by the DUT/SUT. 1078 Peak-to-peak Jitter is not derived from the Instantaneous 1079 Jitter Vector. Peak-to-peak Jitter is based upon all the 1080 packets during the test duration, not just two consecutive 1081 packets. 1083 The value of the Expected Peak-to-peak Jitter Vector is 1084 dependent on the set of offered vectors and Classification 1085 configuration on the DUT/SUT. The DUT is configured in a 1086 certain way in order that classification occurs when a 1087 traffic mix consisting of multiple streams is applied. 1089 This term captures the expected forwarding behavior from the 1090 DUT receiving multiple Offered Vectors. The actual algorithm 1091 or mechanism the DUT uses to achieve service differentiation 1092 is implementation specific and not important when describing 1093 the Expected Peak-to-peak Jitter Vector. 1095 Measurement units: 1096 milliseconds 1098 See Also: 1099 Classification 1100 Stream 1101 Jitter 1102 Intended Vector 1103 Offered Vector 1104 Expected Instantaneous Jitter Vector 1105 Expected Average Jitter Vector 1106 Network-layer Traffic Control Mechanisms 1108 3.4.4 Output Vectors 1109 3.4.4.1 Forwarding Vector 1110 Definition: 1111 The number of packets per second for a stream matching a 1112 specific classification, such as DSCP, that a DUT/SUT 1113 is measured to successfully forward to the correct 1114 destination interface in response to an offered vector. 1116 Discussion: 1117 Forwarding Vector is expressed as a combination of values: 1118 the classification rules AND the measured packets per 1119 second for the stream matching the classification rules. 1120 Forwarding Vector is a per-hop measurement. The DUT/SUT 1121 MAY remark the specific DSCP (or IP precedence) value for 1122 a multi-hop measurement. The stream remains the same. 1124 Measurement units: 1125 N-octet packets per second 1127 See Also: 1128 Classification 1129 Stream 1130 Forwarding Capacity 1131 Intended Vector 1132 Offered Vector 1133 Expected Vector 1135 3.4.4.2 Loss Vector 1136 Definition: 1137 The percentage of packets per second for a stream 1138 matching a specific classification, such as DSCP, that 1139 a DUT/SUT is measured to not transmit to the correct 1140 destination interface in response to an offered vector. 1142 Discussion: 1143 Loss Vector is expressed as a combination of values: 1144 the classification rules AND the measured percentage 1145 value of packet loss. Loss Vector is a per-hop 1146 measurement. The DUT/SUT MAY remark the specific DSCP 1147 or IP precedence value for a multi-hop measurement. 1148 The stream remains the same. 1150 Measurement Units: 1151 Percentage of packets 1153 See Also: 1154 Classification 1155 Stream 1156 Intended Vector 1157 Offered Vector 1158 Expected Vector 1159 One-way Packet Loss Metric [Ka99] 1160 Network-layer Traffic Control Mechanisms 1162 3.4.4.3 Sequence Vector 1163 Definition: 1164 The number of packets per second for all packets in a 1165 stream matching a specific classification, such as DSCP, 1166 that a DUT/SUT is measured to transmit in sequence to the 1167 correct destination interface in response to an offered 1168 vector. 1170 Discussion: 1171 Sequence Vector is expressed as a combination of values: 1172 the classification rules AND the number of packets per 1173 second that are in-sequence. 1175 Sequence Vector is a per-hop measurement. The DUT/SUT 1176 MAY remark the specific DSCP or IP precedence value for 1177 a multi-hop measurement. The stream remains the same. 1179 Measurement Units: 1180 N-octet packets per second 1182 See Also: 1183 Classification 1184 Stream 1185 In-sequence Packet 1186 Intended Vector 1187 Offered Vector 1188 Expected Vector 1190 3.4.4.4 Instantaneous Delay Vector 1191 Definition: 1192 The instantaneous Forwarding Delay for a packet in a 1193 stream matching a specific classification, such as DSCP, 1194 that a DUT/SUT is measured to successfully transmit to the 1195 correct destination interface in response to an offered 1196 vector. 1198 Discussion: 1199 Instantaneous Delay Vector is expressed as a combination 1200 of values: the classification rules AND Forwarding Delay. 1201 For every packet received in a Forwarding Vector, there 1202 is a corresponding Instantaneous Delay Vector. 1204 Instantaneous Delay Vector is a per-hop measurement. The 1205 DUT/SUT MAY remark the specific DSCP or IP precedence value 1206 for a multi-hop measurement. The stream remains the same. 1208 Instantaneous Delay Vector can be obtained at any offered 1209 load. It is RECOMMENDED to obtain this vector at or below 1210 the Forwarding Capacity in the absence of Forwarding 1211 Congestion. For congested Forwarding Delay, run the 1212 offered load above the Forwarding Capacity. 1214 Network-layer Traffic Control Mechanisms 1216 Measurement Units: 1217 milliseconds 1219 See Also: 1220 Classification 1221 Stream 1222 Forwarding Capacity 1223 Forwarding Delay 1224 Intended Vector 1225 Offered Vector 1226 Expected Delay Vector 1228 3.4.4.5 Average Delay Vector 1230 Definition: 1231 The average Forwarding Delay for packets in a stream 1232 matching a specific classification, such as DSCP, that 1233 a DUT/SUT is measured to successfully transmit to the 1234 correct destination interface in response to an offered 1235 vector. 1237 Discussion: 1238 Average Delay Vector is expressed as combination of values: 1239 the classification rules AND average Forwarding Delay. 1241 The average Forwarding Delay is computed by averaging all 1242 the Instantaneous Delay Vectors for a given stream. 1244 Average Delay Vector is a per-hop measurement. The DUT/SUT 1245 MAY remark the specific DSCP or IP precedence value for a 1246 multi-hop measurement. The stream remains the same. 1248 Average Delay Vector can be obtained at any offered load. 1249 Recommend at or below the Forwarding Capacity in the 1250 absence of congestion. For congested Forwarding Delay, run 1251 the offered load above the Forwarding Capacity. 1253 Measurement Units: 1254 milliseconds 1256 See Also: 1257 Classification 1258 Stream 1259 Forwarding Capacity 1260 Forwarding Delay 1261 Intended Vector 1262 Offered Vector 1263 Expected Delay Vector 1264 Instantaneous Delay Vector 1265 Network-layer Traffic Control Mechanisms 1267 3.4.4.6 Maximum Delay Vector 1268 Definition: 1269 The maximum Forwarding Delay for packets in a stream 1270 matching a specific classification, such as DSCP, that 1271 a DUT/SUT is measured to successfully transmit to the 1272 correct destination interface in response to an offered 1273 vector. 1275 Discussion: 1276 Maximum Delay Vector is expressed as combination of values: 1277 the classification rules AND maximum Forwarding Delay. 1279 The maximum Forwarding Delay is computed by selecting the 1280 highest value from the Instantaneous Delay Vectors for a 1281 given stream. 1283 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1284 MAY remark the specific DSCP or IP precedence value for a 1285 multi-hop measurement. The stream remains the same. 1287 Maximum Delay Vector can be obtained at any offered load. 1288 Recommend at or below the Forwarding Capacity in the 1289 absence of congestion. For congested Forwarding Delay, run 1290 the offered load above the Forwarding Capacity. 1292 Measurement Units: 1293 milliseconds 1295 See Also: 1296 Classification 1297 Stream 1298 Forwarding Capacity 1299 Forwarding Delay 1300 Intended Vector 1301 Offered Vector 1302 Expected Delay Vector 1303 Instantaneous Delay Vector 1305 3.4.4.7 Minimum Delay Vector 1306 Definition: 1307 The minimum Forwarding Delay for packets in a stream 1308 matching a specific classification, such as DSCP, that 1309 a DUT/SUT is measured to successfully transmit to the 1310 correct destination interface in response to an offered 1311 vector. 1313 Discussion: 1314 Minimum Delay Vector is expressed as a combination of 1315 values: the classification rules AND maximum Forwarding 1316 Delay. The minimum Forwarding Delay is computed by 1317 selecting the highest value from the Instantaneous Delay 1318 Vectors for a given stream. 1320 Network-layer Traffic Control Mechanisms 1322 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1323 MAY remark the specific DSCP or IP precedence value for a 1324 multi-hop measurement. The stream remains the same. 1326 Minimum Delay Vector can be obtained at any offered load. 1327 Recommend at or below the Forwarding Capacity in the 1328 absence of congestion. For congested Forwarding Delay, run 1329 the offered load above the Forwarding Capacity. 1331 Measurement Units: 1332 milliseconds 1334 See Also: 1335 Classification 1336 Stream 1337 Forwarding Capacity 1338 Forwarding Delay 1339 Intended Vector 1340 Offered Vector 1341 Expected Delay Vector 1343 3.4.4.8 Instantaneous Jitter Vector 1344 Definition: 1345 The jitter for two consecutive packets in a 1346 stream matching a specific classification, such as DSCP, 1347 that a DUT/SUT is measured to successfully transmit to the 1348 correct destination interface in response to an offered 1349 vector. 1351 Discussion: 1352 Instantaneous Jitter is the absolute value of the difference 1353 between the Forwarding Delay measurement of two packets 1354 belonging to the same stream. 1356 Jitter vector is expressed as pair of numbers. Both the 1357 specific DSCP (or IP precedence) value AND jitter value 1358 combine to make a vector. 1360 The Forwarding Delay fluctuation between two consecutive 1361 packets in a stream is reported as the "Instantaneous Jitter". 1362 Instantaneous Jitter Vector can be expressed as 1363 |D(i) - D(i-1)| where D equals the Forwarding Delay and i is 1364 the test sequence number. Packets lost are not counted in 1365 the measurement. 1367 Instantaneous Jitter Vector is a per-hop measurement. The 1368 DUT/SUT MAY remark the specific DSCP or IP precedence value 1369 for a multi-hop measurement. The stream remains the same. 1371 There may be several Instantaneous Jitter Vectors for a 1372 single stream. For n packets measured, there may be (n-1) 1373 Instantaneous Jitter Vectors. 1375 Network-layer Traffic Control Mechanisms 1377 Measurement units: 1378 milliseconds 1380 See Also: 1381 Classification 1382 Stream 1383 Forwarding Delay 1384 Jitter 1385 Forwarding Vector 1386 Expected Vectors 1388 3.4.4.9 Average Jitter Vector 1390 Definition: 1391 The average jitter for packets in a stream matching a 1392 specific classification, such as DSCP, that a DUT/SUT is 1393 measured to successfully transmit to the correct 1394 destination interface in response to an offered vector. 1396 Discussion: 1397 Average jitter is calculated by the average of all the 1398 Instantaneous Jitter Vectors of the same stream measured 1399 during the test duration. Average Jitter Vector is 1400 expressed as a combination of values: the 1401 classification rules AND average Jitter. 1403 Average Jitter vector is a per-hop measurement. The 1404 DUT/SUT MAY remark the specific DSCP or IP precedence value 1405 for a multi-hop measurement. The stream remains the same. 1407 Measurement units: 1408 milliseconds 1410 See Also: 1411 Classification 1412 Stream 1413 Jitter 1414 Forwarding Vector 1415 Expected Vector 1416 Instantaneous Jitter Vector 1418 3.4.4.10 Peak-to-peak Jitter Vector 1420 Definition: 1421 The maximum possible variation in the Forwarding Delay for 1422 packets in a stream matching a specific classification, 1423 such as DSCP, that a DUT/SUT is measured to successfully 1424 transmit to the correct destination interface in response 1425 to an offered vector. 1427 Network-layer Traffic Control Mechanisms 1429 Discussion: 1430 Peak-to-peak Jitter Vector is calculated by subtracting 1431 the maximum Forwarding Delay from the minimum Forwarding 1432 Delay of the packets forwarded by the DUT/SUT. Jitter 1433 vector is expressed as a combination of values: the 1434 classification rules AND peak-to-peak Jitter. 1436 Peak-to-peak Jitter is not derived from the Instantaneous 1437 Jitter Vector. Peak-to-peak Jitter is based upon all the 1438 packets during the test duration, not just two consecutive 1439 packets. 1441 Measurement units: 1442 milliseconds 1444 See Also: 1445 Jitter 1446 Forwarding Vector 1447 Stream 1448 Expected Vectors 1449 Instantaneous Jitter Vector 1450 Average Jitter Vector 1452 4. IANA Considerations 1454 This document requires no IANA considerations. 1456 5. Security Considerations 1458 Documents of this type do not directly affect the security of 1459 the Internet or of corporate networks as long as benchmarking 1460 is not performed on devices or systems connected to 1461 production networks. 1463 Packets with unintended and/or unauthorized DSCP or IP 1464 precedence values may present security issues. Determining 1465 the security consequences of such packets is out of scope for 1466 this document. 1468 6. Acknowledgments 1470 The authors gratefully acknowledge the contributions of the 1471 IETF's benchmarking working group members in reviewing this 1472 document. The authors would like to express our thanks to 1473 David Newman for his consistent and valuable assistance 1474 throughout the development of this document. The authors 1475 would also like to thank Al Morton (acmorton@att.com) and 1476 Kevin Dubray (kdubray@juniper.net) for their ideas and 1477 support. 1479 Network-layer Traffic Control Mechanisms 1481 7. References 1482 7.1 Normative References 1483 [Br91] Bradner, S., "Benchmarking Terminology for Network 1484 Interconnection Devices", RFC 1242, July 1991. 1486 [Br97] Bradner, S., "Key words for use in RFCs to Indicate 1487 Requirement Levels", RFC 2119, March 1997 1489 [Br98] Braden, B., Clark, D., Crowcroft, J., Davie, B., 1490 Deering, S., Estrin, D., Floyd, S., Jacobson, V., 1491 Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, 1492 K., Shenker, S., Wroclawski, J. and L. Zhang, 1493 "Recommendations on Queue Management and Congestion 1494 Avoidance in the Internet", RFC 2309, April 1998. 1496 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1497 Switching Devices", RFC 2285, July 1998. 1499 [Ni98] Nichols, K., Blake, S., Baker, F., Black, D., "Definition 1500 of the Differentiated Services Field (DS Field) in the 1501 IPv4 and IPv6 Headers", RFC 2474, December 1998. 1503 [St91] Steinberg, L., "Techniques for Managing Asynchronously 1504 Generated Alerts", RC 1224, May 1991. 1506 7.2 Informative References 1507 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way Delay 1508 Metric for IPPM", RFC 2679, September 1999 1510 [Bl98] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1511 Weiss, W., "An Architecture for Differentiated Services", 1512 RFC 2475, December 1998. 1514 [Br99] Bradner, S., McQuaid, J. "Benchmarking Methodology for 1515 Network Interconnect Devices", RFC 2544, March 1999 1517 [De02] Demichelis, C., Chimento, P., "IP Packet Delay Variation 1518 Metric for IPPM", RFC 3393, November 2002 1520 [Ec98] http://www3.ietf.org/proceedings/98mar/ 1521 98mar-edited-135.htm 1523 [Fl93] Floyd, S., and Jacobson, V., "Random Early Detection 1524 gateways for Congestion Avoidance", IEEE/ACM 1525 Transactions on Networking, V.1 N.4, August 1993, p. 1526 397-413. URL "ftp://ftp.ee.lbl.gov/papers/early.pdf". 1528 [Ja99] Jacobson, V., Nichols, K., Poduri, K., "An Expedited 1529 Forwarding PHB", RFC 2598, June 1999 1531 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1532 Packet Loss Metric for IPPM", RFC 2680, September 1999 1533 Network-layer Traffic Control Mechanisms 1535 [Ma91] Mankin, A., Ramakrishnan, K., "Gateway Congestion Control 1536 Survey", RFC 1254, August 1991 1538 [Ma00] Mandeville, R., Perser, J., "Benchmarking Methodology for 1539 LAN Switching Devices", RFC 2889, August 2000 1541 [Mo03] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1542 S., Perser, J., "Packet Reordering Metric for IPPM", 1543 Work in Progress 1545 [Na84] Nagle, J., "Congestion Control in IP/TCP Internetworks", 1546 RFC 896, January 1984. 1548 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1549 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1550 January 1999. 1552 [Sc96] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., 1553 "RTP: A Transport Protocol for Real-Time Applications", 1554 RFC 1889, January 1996 1556 8. Authors' Addresses 1558 Jerry Perser 1559 Veriwave 1560 USA 1561 EMail: jperser@veriwave.com 1563 Scott Poretsky 1564 Reef Point Systems 1565 8 New England Executive Park 1566 Burlington, MA 01803 1567 USA 1568 Phone: + 1 508 439 9008 1569 EMail: sporetsky@reefpoint.com 1571 Shobha Erramilli 1572 Telcordia Technologies 1573 331 Newman Springs Road 1574 Red Bank, New Jersey 07701 1575 USA 1576 Email: shobha@research.telcordia.com 1578 Sumit Khurana 1579 Telcordia Technologies 1580 445 South Street 1581 Morristown, NJ 07960 1582 USA 1583 Phone: + 1 973 829 3170 1584 EMail: sumit@research.telcordia.com 1585 Network-layer Traffic Control Mechanisms 1587 Full Copyright Statement 1589 Copyright (C) The Internet Society (2006). 1591 This document is subject to the rights, licenses and restrictions 1592 contained in BCP 78, and except as set forth therein, the authors 1593 retain all their rights. 1595 This document and the information contained herein are provided on an 1596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1598 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1599 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1600 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1601 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1603 Intellectual Property 1605 The IETF takes no position regarding the validity or scope of any 1606 Intellectual Property Rights or other rights that might be claimed to 1607 pertain to the implementation or use of the technology described in 1608 this document or the extent to which any license under such rights 1609 might or might not be available; nor does it represent that it has 1610 made any independent effort to identify any such rights. Information 1611 on the procedures with respect to rights in RFC documents can be 1612 found in BCP 78 and BCP 79. 1614 Copies of IPR disclosures made to the IETF Secretariat and any 1615 assurances of licenses to be made available, or the result of an 1616 attempt made to obtain a general license or permission for the use of 1617 such proprietary rights by implementers or users of this 1618 specification can be obtained from the IETF on-line IPR repository at 1619 http://www.ietf.org/ipr. 1621 The IETF invites any interested party to bring to its attention any 1622 copyrights, patents or patent applications, or other proprietary 1623 rights that may cover technology that may be required to implement 1624 this standard. Please address the information to the IETF at ietf- 1625 ipr@ietf.org. 1627 Acknowledgement 1628 Funding for the RFC Editor function is currently provided by the 1629 Internet Society.