idnits 2.17.1 draft-ietf-bmwg-dsmterm-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 47 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 20 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document 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 (February 2002) is 8104 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 1484, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. 'Br91') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. 'Ma98') -- Obsolete informational reference (is this intentional?): RFC 2679 (ref. 'Al99') (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2598 (ref. 'Ja99') (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 2680 (ref. 'Ka99') (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 896 (ref. 'Na84') (Obsoleted by RFC 7805) -- Obsolete informational reference (is this intentional?): RFC 2481 (ref. 'Ra99') (Obsoleted by RFC 3168) -- Obsolete informational reference (is this intentional?): RFC 1889 (ref. 'Sc96') (Obsoleted by RFC 3550) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jerry Perser 3 INTERNET-DRAFT Spirent 4 Expires in: August 2003 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 QNetworx 10 Scott Poretsky 11 Avici Systems 12 February 2002 14 Terminology for Benchmarking Network-layer 15 Traffic Control Mechanisms 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- 32 Drafts as reference material or to cite them other than as "work 33 in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Table of Contents 43 1. Introduction .............................................. 3 44 2. Existing definitions ...................................... 3 45 3. Term definitions ............................................4 46 3.1 Configuration Terms 47 3.1.1 Classification .........................................4 48 3.1.2 Codepoint Set ..........................................4 49 3.1.3 Forwarding Congestion ..................................5 50 3.1.4 Congestion Management ..................................6 51 3.1.5 Flow ...................................................6 52 3.2 Measurement Terms 53 Network-layer Traffic Control Mechanisms 55 3.2.1 Channel Capacity .......................................7 56 3.2.2 Conforming .............................................8 57 3.2.3 Nonconforming ..........................................8 58 3.2.4 Delay ..................................................9 59 3.2.5 Jitter ................................................10 60 3.2.6 Undifferentiated Response .............................11 61 3.3 Sequence Tracking 62 3.3.1 In-sequence Packet ....................................11 63 3.3.2 Out-of-order Packet ...................................12 64 3.3.3 Duplicate Packet ......................................12 65 3.3.4 Stream ................................................13 66 3.3.5 Test Sequence number .................................13 67 3.4 Vectors ...................................................14 68 3.4.1 Intended Vector .......................................14 69 3.4.2 Offered Vector ........................................15 70 3.4.3 Expected Vectors 71 3.4.3.1 Expected Forwarding Vector ........................15 72 3.4.3.2 Expected Loss Vector ..............................16 73 3.4.3.3 Expected Sequence Vector ..........................16 74 3.4.3.4 Expected Instantaneous Delay Vector ...............17 75 3.4.3.5 Expected Average Delay Vector .....................18 76 3.4.3.6 Expected Maximum Delay Vector .....................18 77 3.4.3.7 Expected Minimum Delay Vector .....................19 78 3.4.3.8 Expected Instantaneous Jitter Vector ..............20 79 3.4.3.9 Expected Average Jitter Vector ....................21 80 3.4.3.10 Expected Peak-to-peak Jitter Vector ..............21 81 3.4.4 Output Vectors 82 3.4.4.1 Forwarding Vector .................................22 83 3.4.4.2 Loss Vector .......................................22 84 3.4.4.3 Sequence Vector ...................................23 85 3.4.4.4 Instantaneous Delay Vector ........................24 86 3.4.4.5 Average Delay Vector ..............................25 87 3.4.4.6 Maximum Delay Vector ..............................26 88 3.4.4.7 Minimum Delay Vector ..............................26 89 3.4.4.8 Instantaneous Jitter Vector .......................27 90 3.4.4.9 Average Jitter Vector .............................28 91 3.4.4.10 Peak-to-peak Jitter Vector .......................29 92 4. Security Considerations ....................................30 93 5. Normative References .......................................30 94 6. Informative References .....................................31 95 7. Author's Address ...........................................32 96 8. Full Copyright Statement ...................................33 97 Network-layer Traffic Control Mechanisms 99 1. Introduction 101 This document describes terminology for the benchmarking of 102 devices that implement traffic control based on IP precedence or 103 diff-serv code point criteria. 105 New terminology is needed because most existing measurements 106 assume the absence of congestion and only a single per-hop- 107 behavior. This document introduces several new terms that will 108 allow measurements to be taken during periods of congestion. 110 Another key difference from existing terminology is the definition 111 of measurements as observed on egress as well as ingress of a 112 device/system under test. Again, the existence of congestion 113 requires the addition of egress measurements as well as those 114 taken on ingress; without observing traffic leaving a 115 device/system it is not possible to say whether traffic-control 116 mechanisms effectively dealt with congestion. 118 The principal measurements introduced in this document are vectors 119 for rate, delay, and jitter, all of which can be observed with or 120 without congestion of the DUT/SUT. 122 This document describes only those terms relevant to measuring 123 behavior of a device or a group of devices using one of these two 124 mechanisms. End-to-end and service-level measurements are beyond 125 the scope of this document. 127 2. Existing definitions 129 RFC 1242 "Benchmarking Terminology for Network Interconnect 130 Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching 131 Devices" should be consulted before attempting to make use of this 132 document. 134 RFC 2474 "Definition of the Differentiated Services Field (DS 135 Field) in the IPv4 and IPv6 Headers" section 2, contains 136 discussions of a number of terms relevant to network-layer traffic 137 control mechanisms and should also be consulted. 139 For the sake of clarity and continuity this RFC adopts the 140 template for definitions set out in Section 2 of RFC 1242. 141 Definitions are indexed and grouped together in sections for ease 142 of reference. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 145 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 RFC 2119. 149 Network-layer Traffic Control Mechanisms 151 3. Term definitions 153 3.1 Configuration Terms 155 3.1.1 Classification 157 Definition: 158 Selection of packets based on the contents of packet header 159 according to defined rules. 161 Discussion: 162 Packets can be selected based on the DS field or IP 163 Precedence in the packet header. Classification can also be 164 based on Multi-Field (MF) criteria such as IP Source and 165 destination addresses, protocol and port number. 167 Classification determines the per-hop behaviors and traffic 168 conditioning functions such as shaping and dropping that are 169 to be applied to the packet. 171 Measurement units: 172 n/a 174 See Also: 176 3.1.2 Codepoint Set 178 Definition: 179 The set of all DS Code-points or IP precedence values used 180 during the test duration. 182 Discussion: 183 Describes all the code-point markings associated with packets 184 that are input to the DUT/SUT. For each entry in the 185 codepoint set, there are associated vectors describing the 186 rate of traffic, delay, loss, or jitter containing that 187 particular DSCP or IP precedence value. 189 The treatment that a packet belonging to a particular code- 190 point gets is subject to the DUT classifying packets to map 191 to the correct PHB. Moreover, the forwarding treatment in 192 general is also dependent on the complete set of offered 193 vectors. 195 Measurement Units: 196 n/a 198 See Also: 200 Network-layer Traffic Control Mechanisms 202 3.1.3 Forwarding Congestion 204 Definition: 205 A condition in which one or more egress interfaces are 206 offered more packets than are forwarded. 208 Discussion: 210 This condition is a superset of the overload definition 211 [Ma98]. The overload definition assumes the congestion is 212 introduced strictly by the tester on ingress of a DUT/SUT. 213 That may or may not be the case here. 215 Another difference between Forwarding Congestion and overload 216 occurs when the SUT comprises multiple elements, in that 217 Forwarding Congestion may occur at multiple points. Consider 218 an SUT comprising multiple edge devices exchanging traffic 219 with a single core device. Depending on traffic patterns, the 220 edge devices may induce congestion on multiple egress 221 interfaces on the core device. In contrast, overload [Br91] 222 deals only with overload on ingress. 224 Packet Loss, not increased Delay, is the metric to indicate 225 the condition of Forwarding Congestion. Packet Loss is a 226 deterministic indicator of Forwarding Congestion. While 227 increased delay may be an indicator of Forwarding Congestion, 228 it is a non-deterministic indicator of Forwarding Congestion. 229 External observation of increased delay to indicate 230 congestion is in effect external observation of Incipient 231 Congestion. [Ra99] states that it is impractical to build a 232 black-box test to externally observe Incipient Congestion in 233 a router. For the purpose of "black-box" testing a DUT/SUT, 234 Packet Loss as the indicator of Forwarding Congestion is 235 used. 237 Throughput [Br91] defines the lower boundary of Forwarding 238 Congestion. Throughput is the maximum offered rate with no 239 Forwarding Congestion. At offered rates above throughput, 240 the DUT/SUT is considered congested. 242 Ingress observations alone are not sufficient to cover all 243 cases in which Forwarding Congestion may occur. A device with 244 an infinite amount of memory could buffer an infinite amount 245 of packets, and eventually forward all of them. However, 246 these packets may or may not be forwarded during the test 247 duration. Even though ingress interfaces accept all packets 248 without loss, this hypothetical device may still be 249 congested. 251 Network-layer Traffic Control Mechanisms 253 Forwarding Congestion, indicated by occurrence of packet 254 loss, is one type of congestion for a DUT/SUT. Congestion 255 Collapse [Na84] is defined as the state in which buffers are 256 full and all arriving packets must be dropped across the 257 network. Incipient Congestion [Ra99] is defined as 258 congestion that produces increased delay without packet loss. 260 The definition presented here explicitly defines Forwarding 261 Congestion as an event observable on egress interfaces. 262 Regardless of internal architecture, any device that cannot 263 forward packets on one or more egress interfaces is under 264 Forwarding Congestion. 266 Measurement units: 267 none 269 See Also: 270 Gateway Congestion Control Survey [Ma91] 272 3.1.4 Congestion Management 274 Definition: 275 An implementation of one or more per-hop-behaviors to avoid 276 or minimize the condition of congestion. 278 Discussion: 279 Congestion management may seek either to control congestion 280 or avoid it altogether. Such mechanisms classify packets 281 based upon IP Precedence or DSCP settings in a packet's IP 282 header. 284 Congestion avoidance mechanisms seek to prevent congestion 285 before it actually occurs. 287 Congestion control mechanisms gives one or flows (with a 288 discrete IP Precedence or DSCP value) preferential treatment 289 over other classes during periods of congestion. 291 Measurement units: 292 n/a 294 See Also: 296 3.1.5 Flow 298 Definition: 299 A flow is a one or more of packets sharing a common intended 300 pair of source and destination interfaces. 302 Network-layer Traffic Control Mechanisms 304 Discussion: 305 Packets are grouped by the ingress and egress interfaces they 306 use on a given DUT/SUT. 308 A flow can contain multiple source IP addresses and/or 309 destination IP addresses. All packets in a flow must enter 310 on the same ingress interface and exit on the same egress 311 interface, and have some common network layer content. 313 Microflows [Ni98] are a subset of flows. As defined in 314 [Ni98], microflows require application-to-application 315 measurement. In contrast, flows use lower-layer 316 classification criteria. Since this document focuses on 317 network-layer classification criteria, we concentrate here on 318 the use of network-layer identifiers in describing a flow. 319 Flow identifiers also may reside at the data-link, transport, 320 or application layers of the ISO model. However, identifiers 321 other than those at the network layer are out of scope for 322 this document. 324 A flow may contain a single code point/IP precedence value or 325 may contain multiple values destined for a single egress 326 interface. This is determined by the test methodology. 328 Measurement units: 329 n/a 331 See Also: 332 Microflow [Ni98] 333 Streams 335 3.2 Measurement Terms 337 3.2.1 Channel Capacity 339 Definition: 340 The maximum forwarding rate [Ma98] at which none of the 341 offered packets are dropped by the DUT/SUT. 343 Discussion: 344 Channel capacity measures the packet rate at the egress 345 interface(s) of the DUT/SUT. In contrast, throughput as 346 defined in RFC 1242 measures the packet rate is based on the 347 ingress interface(s) of the DUT/SUT. 349 Ingress-based measurements do not account for congestion of 350 the DUT/SUT. Channel capacity, as an egress measurement, does 351 take congestion into account. 353 Network-layer Traffic Control Mechanisms 355 Understanding channel capacity is a necessary precursor to 356 any measurement involving congestion. Throughput numbers can 357 be higher than channel capacity because of queueing. 359 This measurement differs from forwarding rate at maximum 360 offered load (FRMOL) [Ma98] in that it is intolerant of loss. 362 Measurement units: 363 N-octet packets per second 365 See Also: 366 Throughput [Br91] 367 Forwarding Rate at Maximum Offered Load [Ma98] 369 3.2.2 Conforming 371 Definition: 372 Packets which lie within specific rate, delay, or jitter 373 bounds. 375 Discussion: 376 A DUT/SUT may be configured to allow a given traffic class to 377 consume a given amount of bandwidth, or to fall within 378 predefined delay or jitter boundaries. All packets that lie 379 within specified bounds are then said to be conforming, 380 whereas those outside the bounds are nonconforming. 382 Measurement units: 383 n/a 385 See Also: 386 Expected Vector 387 Forwarding Vector 388 Offered Vector 389 Nonconforming 391 3.2.3 Nonconforming 393 Definition: 394 Packets that do not lie within specific rate, delay, or 395 jitter bounds. 397 Discussion: 398 A DUT/SUT may be configured to allow a given traffic class to 399 consume a given amount of bandwidth, or to fall within 400 predefined delay or jitter boundaries. All packets that do 401 not lie within these bounds are then said to be 402 nonconforming. 404 Network-layer Traffic Control Mechanisms 406 Measurement units: 407 n/a 409 See Also: 410 Expected Vector 411 Forwarding Vector 412 Offered Vector 413 Conforming 415 3.2.4 Delay 417 Definition: 418 The time interval starting when the last bit of the input IP 419 packet reaches the input port of the DUT/SUT and ending when 420 the last bit of the output IP packet is seen on the output 421 port of the DUT/SUT. 423 Discussion: 424 Delay differs from latency [Br91] and one-way delay [Al99] in 425 several key regards: 427 1. Latency [Br91] assumes knowledge of whether the DUT/SUT 428 uses "store and forward" or "bit forwarding" technology. 429 Delay is delay, regardless of the technology being measured. 431 2. Delay is a last-in, last-out (LILO) measurement, unlike 432 the last-in, first-out method [Br91] or the first-in, last- 433 out method [Al99]. 435 The LILO method most closely simulates the way a network- 436 layer device actually processes an IP datagram. IP datagrams 437 are not passed up and down the stack unless they are 438 complete, and processing begins only once the last bit of the 439 IP datagram has been received. 441 Further, the LILO method has an additive property, where the 442 sum of the parts MUST equal the whole. This is a key 443 difference from [Br91] and [Al99]. For example, the delay 444 added by two DUTs MUST equal the sum of the delay of the 445 DUTs. This may or may not be the case with [Br91] and [Al99]. 447 3. Delay measures the IP datagram only, unlike [Br91], which 448 also includes link layer overhead. 450 A metric focused exclusively on the Internet protocol 451 relieves the tester from specifying the start/end for every 452 link layer protocol that IP runs on. This avoids the need to 453 determine whether the start/stop delimiters are included. It 454 also allows the use of heterogeneous link layer protocols in 455 a test. 457 Network-layer Traffic Control Mechanisms 459 4. Delay can be measured at any offered load, whereas latency 460 [Br99] is measured only at the throughput level. 462 For example, non-congested delay may be measured with an 463 offered load that does not exceed the channel capacity, while 464 congested delay may involve an offered load that exceeds 465 channel capacity. 467 5. Delay SHOULD NOT be used as an absolute indicator of 468 DUT/SUT Forwarding Congestion. While delay may rise when 469 offered load nears or exceeds channel capacity, there is no 470 universal point at which delay can be said to indicate the 471 presence or absence of Forwarding Congestion. 473 Measurement units: 474 Seconds. 476 See Also: 477 Latency [Br91] 478 Latency [Al99] 479 One-way Delay [Br99] 481 3.2.5 Jitter 483 Definition: 484 The absolute value of the difference between the arrival 485 delay of two consecutive packets belonging to the same 486 stream. 488 Discussion: 489 The delay fluctuation between two consecutive packets in a 490 stream is reported as the jitter. Jitter can be expressed as 491 |D(i) - D(i-1)| where D equals the delay and i is the test 492 sequence number. The measurement does not include lost 493 packets. 495 Jitter can be determined by the ipdv [De02] (IP Delay 496 Variation) by taking the absolute value of the ipdv. The two 497 metrics will produce different mean values. _Mean Jitter_ 498 will produce a positive value, where the _mean ipdv_ is 499 typically zero. 501 Measurement units: 502 Seconds 504 See Also: 505 Jitter variation [Ja99] 506 ipdv [De02] 507 interarrival jitter [Sc96] 508 Network-layer Traffic Control Mechanisms 510 3.2.6 Undifferentiated Response 512 Definition: 513 The vector(s) obtained when mechanisms used to support diff- 514 serv or IP precedence are disabled. 516 Discussion: 517 Enabling diff-serv or IP precedence mechanisms may impose 518 additional processing overhead for packets. This overhead may 519 degrade performance even when traffic belonging to only one 520 class, the best-effort class, is offered to the device. 522 Measurements with "undifferentiated response" should be made 523 to establish a baseline. 525 The vector(s) obtained with DSCPs or IP precedence enabled 526 can be compared to the undifferentiated response to determine 527 the effect of differentiating traffic. 529 Measurement units: 530 n/a 532 3.3 Sequence Tracking 534 3.3.1 In-sequence Packet 536 Definition: 537 A received packet with the expected Test Sequence number. 539 Discussion: 540 In-sequence is done on a stream level. As packets are 541 received on a stream, each packet's Test Sequence number is 542 compared with the previous packet. Only packets that match 543 the expected Test Sequence number are considered in-sequence. 545 Packets that do not match the expected Test Sequence number 546 are counted as _not in-sequence_ or out-of-sequence. Every 547 packet that is received is either in-sequence or out-of- 548 sequence. Subtracting the in-sequence from the received 549 packets (for that stream) can derive the out-of-sequence 550 count. 552 Two types of events will prevent the in-sequence from 553 incrementing: packet loss and reordered packets. 555 Measurement units: 556 Packet count 557 Network-layer Traffic Control Mechanisms 559 See Also: 560 Stream 561 Test Sequence number 563 3.3.2 Out-of-order Packet 565 Definition: 566 A received packet with a Test Sequence number less that 567 expected. 569 Discussion: 570 As a stream of packets enter a DUT/SUT, they include a Stream 571 Test Sequence number indicating the order the packets were 572 sent to the DUT/SUT. On exiting the DUT/SUT, these packets 573 may arrive in a different order. Each packet that was re- 574 ordered is counted as an Out-of-order Packet. 576 Certain streaming protocol (such as TCP) require the packets 577 to be in a certain order. Packets outside this are dropped 578 by the streaming protocols even though there were properly 579 received by the IP layer. The type of reordering tolerated 580 by a streaming protocol varies from protocol to protocol, and 581 also by implementation. 583 Out-of-order Packet count is based on the worst case 584 streaming protocol. It allows for no reordering. 586 Packet loss does not affect the Out-of-order Packet count. 587 Only packets that were not received in the order that they 588 were transmitted. 590 Measurement units: 591 Packet count 593 See Also: 594 Stream 595 Test Sequence number 597 3.3.3 Duplicate Packet 599 Definition: 600 A received packet with a Test Sequence number matching a 601 previously received packet. 603 Discussion: 605 Measurement units: 606 Packet count 607 Network-layer Traffic Control Mechanisms 609 See Also: 610 Stream 611 Test Sequence number 613 3.3.4 Stream 615 Definition: 616 A group of packets tracked as a single entity by the traffic 617 receiver. A stream may share a common content such as type 618 (IP, UDP), packet size, or payload. 620 Discussion: 621 Streams are tracked by test sequence number or "unique 622 signature field" (RFC 2889). Streams define how individual 623 packet's statistics are grouped together to form an 624 intelligible summary. 626 Common stream groupings would be by egress interface, 627 destination address, source address, DSCP, or IP precedence. 628 A stream using test sequence numbers can track the ordering 629 of packets as they transverse the DUT/SUT. 631 Streams are not restricted to a pair of source and 632 destination interfaces as long as all packets are tracked as 633 a single entity. A mulitcast stream can be forward to 634 multiple destination interfaces. 636 Measurement units: 637 n/a 639 See Also: 640 Flow 641 MicroFlow [Ni98] 642 Test sequence number 644 3.3.6 Test Sequence number 646 Definition: 647 A field in the IP payload portion of the packet that is used 648 to verify the order of the packets on the egress of the 649 DUT/SUT. 651 Discussion: 652 The traffic generator sets the test sequence number value and 653 the traffic receiver checks the value upon receipt of the 654 packet. The traffic generator changes the value on each 655 packet transmitted based on an algorithm agreed to by the 656 traffic receiver. 658 Network-layer Traffic Control Mechanisms 660 The traffic receiver keeps track of the sequence numbers on a 661 per stream basis. In addition to number of received packets, 662 the traffic receiver may also report number of in-sequence 663 packets, number of out-sequence packets, number of duplicate 664 packets, and number of reordered packets. 666 The recommended algorithm to use to change the sequence 667 number on sequential packets is an incrementing value. 669 Measurement units: 670 n/a 672 See Also: 673 Stream 675 3.4 Vectors 676 A vector is a group of packets all containing a specific DSCP 677 or IP precedence value. Vectors are expressed as a pair of 678 numbers. The first is being the particular diff-serv value. 679 The second is the metric expressed as a rate, loss 680 percentage, delay, or jitter. 682 3.4.1 Intended Vector 684 Definition: 686 A vector describing the rate at which packets having a 687 specific code-point (or IP precedence) that an external 688 source attempts to transmit to a DUT/SUT. 690 Discussion: 691 Intended loads across the different code-point classes 692 determine the metrics associated with a specific code-point 693 traffic class. 695 Measurement Units: 696 N-octets packets per second 698 See Also: 699 Offered Vector 700 Expected Forwarding Vector 701 Expected Loss Vector 702 Expected Sequence Vector 703 Expected Delay Vector 704 Expected Jitter Vector 705 Forwarding Vector 706 Loss Vector 707 Network-layer Traffic Control Mechanisms 709 3.4.2 Offered Vector 711 Definition: 712 A vector describing the measured rate at which packets having 713 a specific DSCP or IP precedence value are offered to the 714 DUT/SUT. 716 Discussion: 717 Offered loads across the different code-point classes, 718 constituting a code-point set, determine the metrics 719 associated with a specific code-point traffic class. 721 Measurement Units: 722 N-octets packets per second 724 See Also: 725 Expected Forwarding Vector 726 Expected Loss Vector 727 Expected Sequence Vector 728 Expected Delay Vector 729 Expected Jitter Vector 730 Forwarding Vector 731 Codepoint Set 733 3.4.3 Expected Vectors 735 3.4.3.1 Expected Forwarding Vector 737 Definition: 738 A vector describing the expected output rate of packets 739 having a specific DSCP or IP precedence value. The value is 740 dependent on the set of offered vectors and configuration of 741 the DUT. 743 Discussion: 744 The DUT is configured in a certain way in order that service 745 differentiation occurs for a particular DSCP or IP precedence 746 value when a specific traffic mix consisting of multiple 747 DSCPs or IP precedence values are applied. This term attempts 748 to capture the expected forwarding behavior when subjected to 749 a certain offered vectors. 751 The actual algorithm or mechanism the DUT uses to achieve 752 service differentiation is not important in describing the 753 expected forwarding vector. 755 Measurement units: 756 N-octet packets per second 757 Network-layer Traffic Control Mechanisms 759 See Also: 760 Intended Vector 761 Offered Vector 762 Output Vectors 763 Expected Loss Vector 764 Expected Sequence Vector 765 Expected Delay Vector 766 Expected Jitter Vector 768 3.4.3.2 Expected Loss Vector 770 Definition: 771 A vector describing the percentage of packets, having a 772 specific DSCP or IP precedence value, that should not be 773 forwarded. The value is dependent on the set of offered 774 vectors and configuration of the DUT. 776 Discussion: 777 The DUT is configured in a certain way in order that service 778 differentiation occurs for a particular DSCP or IP precedence 779 value when a specific traffic mix consisting of multiple 780 DSCPs or IP precedence values are applied. This term attempts 781 to capture the expected forwarding behavior when subjected to 782 a certain offered vectors. 784 The actual algorithm or mechanism the DUT uses to achieve 785 service differentiation is not important in describing the 786 expected loss vector. 788 Measurement Units: 789 Percentage of intended packets that are expected to be 790 dropped. 792 See Also: 793 Intended Vector 794 Offered Vector 795 Expected Forwarding Vector 796 Expected Sequence Vector 797 Expected Delay Vector 798 Expected Jitter Vector 799 One-way Packet Loss Metric [Ka99] 801 3.2.3.3 Expected Sequence Vector 803 Definition: 804 A vector describing the expected in-sequence packets having a 805 specific DSCP or IP precedence value. The value is dependent 806 on the set of offered vectors and configuration of the DUT. 808 Network-layer Traffic Control Mechanisms 810 Discussion: 811 The DUT is configured in a certain way in order that service 812 differentiation occurs for a particular DSCP or IP precedence 813 value when a specific traffic mix consisting of multiple 814 DSCPs or IP precedence values are applied. This term attempts 815 to capture the expected forwarding behavior when subjected to 816 a certain offered vectors. 818 The actual algorithm or mechanism the DUT uses to achieve 819 service differentiation is not important in describing the 820 expected sequence vector. 822 Measurement Units: 823 N-octet packets per second 825 See Also: 826 Intended Vector 827 Offered Vector 828 Output Vectors 829 Expected Loss Vector 830 Expected Forwarding Vector 831 Expected Delay Vector 832 Expected Jitter Vector 834 3.4.3.4 Expected Instantaneous Delay Vector 836 Definition: 837 A vector describing the expected delay for packets having a 838 specific DSCP or IP precedence value. The value is dependent 839 on the set of offered 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 attempts 846 to capture the expected forwarding behavior when subjected to 847 a certain offered vectors. 849 The actual algorithm or mechanism the DUT uses to achieve 850 service differentiation is not important in describing the 851 expected delay vector. 853 Measurement units: 854 Seconds. 856 Network-layer Traffic Control Mechanisms 858 See Also: 859 Intended Vector 860 Offered Vector 861 Output Vectors 862 Expected Loss Vector 863 Expected Sequence Vector 864 Expected Forwarding Vector 865 Expected Jitter Vector 867 3.4.3.5 Expected Average Delay Vector 869 Definition: 870 A vector describing the expected average delay for packets 871 having a specific DSCP or IP precedence value. The value is 872 dependent on the set of offered vectors and configuration of 873 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 attempts 880 to capture the expected forwarding behavior when subjected to 881 a 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 average delay vector. 887 Measurement units: 888 Seconds. 890 See Also: 891 Intended Vector 892 Offered Vector 893 Output Vectors 894 Expected Loss Vector 895 Expected Sequence Vector 896 Expected Forwarding Vector 897 Expected Jitter Vector 899 3.4.3.6 Expected Maximum Delay Vector 901 Definition: 902 A vector describing the expected maximum 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 attempts 914 to capture the expected forwarding behavior when subjected to 915 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 maximum delay vector. 921 Measurement units: 922 Seconds. 924 See Also: 925 Intended Vector 926 Offered Vector 927 Output Vectors 928 Expected Loss Vector 929 Expected Sequence Vector 930 Expected Forwarding Vector 931 Expected Jitter Vector 933 3.4.3.7 Expected Minimum Delay Vector 935 Definition: 936 A vector describing the expected minimum delay for packets 937 having a specific DSCP or IP precedence value. The value is 938 dependent on the set of offered vectors and configuration of 939 the DUT. 941 Discussion: 942 The DUT is configured in a certain way in order that service 943 differentiation occurs for a particular DSCP or IP precedence 944 value when a specific traffic mix consisting of multiple 945 DSCPs or IP precedence values are applied. This term attempts 946 to capture the expected forwarding behavior when subjected to 947 a certain offered vectors. 949 The actual algorithm or mechanism the DUT uses to achieve 950 service differentiation is not important in describing the 951 expected minimum delay vector. 953 Measurement units: 954 Seconds. 956 Network-layer Traffic Control Mechanisms 958 See Also: 959 Intended Vector 960 Offered Vector 961 Output Vectors 962 Expected Loss Vector 963 Expected Sequence Vector 964 Expected Forwarding Vector 965 Expected Jitter Vector 967 3.2.3.8 Expected Instantaneous Jitter Vector 969 Definition: 970 A vector describing the expected jitter between two 971 consecutive packets' arrival times having a specific DSCP or 972 IP precedence value. The value is dependent on the set of 973 offered vectors and configuration of the DUT. 975 Discussion: 976 Instantaneous Jitter is the absolute value of the difference 977 between the delay measurement of two packets belonging to the 978 same stream. 980 The delay fluctuation between two consecutive packets in a 981 stream is reported as the "Instantaneous Jitter". 982 Instantaneous Jitter can be expressed as |D(i) - D(i-1)| 983 where D equals the delay and i is the test sequence number. 984 Packets lost are not counted in the measurement. 986 Forwarding Vector may contain several Jitter Vectors. For n 987 packets received in a Forwarding Vector, there is a total of 988 (n-1) Instantaneous Jitter Vectors. 990 Measurement units: 991 Seconds 993 See Also: 994 Delay 995 Jitter 996 Offered Vector 997 Output Vectors 998 Expected Average Jitter Vector 999 Expected Peak-to-peak Jitter Vector 1000 Stream 1001 Network-layer Traffic Control Mechanisms 1003 3.2.3.9 Expected Average Jitter Vector 1005 Definition: 1006 A vector describing the expected jitter in packet arrival 1007 times for packets having specific DSCP or IP precedence 1008 value. The value is dependent on the set of offered vectors 1009 and configuration of the DUT. 1011 Discussion: 1012 Average Jitter Vector is the average of all the Instantaneous 1013 Jitter Vectors measured during the test duration for the same 1014 DSCP or IP precedence value. 1016 Measurement units: 1017 Seconds 1019 See Also: 1020 Intended Vector 1021 Offered Vector 1022 Output Vectors 1023 Expected Instantaneous Jitter Vector 1024 Expected Peak-to-peak Jitter Vector 1026 3.2.3.10 Expected Peak-to-peak Jitter Vector 1028 Definition: 1029 A vector describing the expected maximum variation in the 1030 delay of packet arrival times for packets having specific 1031 DSCP or IP precedence value. The value is dependent on the 1032 set of offered vectors and configuration of the DUT. 1034 Discussion: 1035 Peak-to-peak Jitter Vector is the maximum delay minus the 1036 minimum delay of the packets (in a vector) forwarded by the 1037 DUT/SUT. 1039 Peak-to-peak Jitter is not derived from the Instantaneous 1040 Jitter Vector. Peak-to-peak Jitter is based upon all the 1041 packets during the test duration, not just two consecutive 1042 packets. 1044 Measurement units: 1045 Seconds 1047 See Also: 1048 Intended Vector 1049 Offered Vector 1050 Output Vectors 1051 Expected Instantaneous Jitter Vector 1052 Expected Average Jitter Vector 1053 Network-layer Traffic Control Mechanisms 1055 3.4.4 Output Vectors 1057 3.4.4.1 Forwarding Vector 1059 Definition: 1060 The number of packets per second for all packets containing a 1061 specific DSCP or IP precedence value that a device can be 1062 observed to successfully forward to the correct destination 1063 interface in response to an offered vector. 1065 Discussion: 1066 Forwarding Vector is expressed as pair of numbers. Both the 1067 specific DSCP (or IP precedence) value AND the packets per 1068 second value combine to make a vector. 1070 The Forwarding Vector represents packet rate based on its 1071 specific DSCP (or IP precedence) value. It is not 1072 necessarily based on a stream or flow. The Forwarding Vector 1073 may be expressed as per port of the DUT/SUT. However, it must 1074 be consistent with the Expected Forwarding Vector. 1076 Forwarding Vector is a per-hop measurement. The DUT/SUT may 1077 change the specific DSCP (or IP precedence) value for a 1078 multiple-hop measurement. 1080 Measurement units: 1081 N-octet packets per second 1083 See Also: 1084 Intended Vector 1085 Offered Vector 1086 Expected Vectors 1087 Loss Vector 1088 Sequence Vector 1089 Delay Vectors 1091 3.4.4.2 Loss Vector 1093 Definition: 1094 The percentage of packets containing specific DSCP or IP 1095 precedence value that a DUT/SUT did not transmit to the 1096 correct destination interface in response to an offered 1097 vector. 1099 Discussion: 1100 Loss Vector is expressed as pair of numbers. Both the 1101 specific DSCP (or IP precedence) value AND the percentage 1102 value combine to make a vector. 1104 Network-layer Traffic Control Mechanisms 1106 The Loss Vector represents percentage based on a specific 1107 DSCP or IP precedence value. It is not necessarily based on 1108 a stream or flow. The Loss Vector may be expressed as per 1109 port of the DUT/SUT. However, it must be consistent with the 1110 Expected Loss Vector 1112 Loss Vector is a per-hop measurement. The DUT/SUT may change 1113 the specific DSCP or IP precedence value for a multiple-hop 1114 measurement. 1116 Measurement Units: 1117 Percentage of offered packets that are not forwarded. 1119 See Also: 1120 Intended Vector 1121 Offered Vector 1122 Expected Vectors 1123 Forwarding Vector 1124 Sequence Vector 1125 Delay Vectors 1126 One-way Packet Loss Metric [Ka99] 1128 3.4.4.3 Sequence Vector 1130 Definition: 1131 The number of packets per second for all packets containing a 1132 specific DSCP or IP precedence value that a device can be 1133 observed to transmit in sequence to the correct destination 1134 interface in response to an offered vector. 1136 Discussion: 1137 Sequence Vector is expressed as pair of numbers. Both the 1138 specific DSCP (or IP precedence) value AND the packets per 1139 second value combine to make a vector. 1141 The Sequence Vector represents packet rate based on its 1142 specific DSCP or IP precedence value. It is not necessarily 1143 based on a stream or flow. The Sequence Vector may be 1144 expressed as per port of the DUT/SUT. However, it must be 1145 consistent with the Expected Sequence Vector. 1147 Sequence Vector is a per-hop measurement. The DUT/SUT may 1148 change the specific DSCP or IP precedence value for a 1149 multiple-hop measurement. 1151 Measurement Units: 1152 N-octet packets per second 1154 Issues: 1156 Network-layer Traffic Control Mechanisms 1158 See Also: 1159 In-sequence Packet 1160 Intended Vector 1161 Offered Vector 1162 Expected Vectors 1163 Loss Vector 1164 Forwarding Vector 1165 Delay Vectors 1167 3.4.4.4 Instantaneous Delay Vector 1169 Definition: 1170 The delay for a packet containing specific DSCP or IP 1171 precedence value that a device can be observed to 1172 successfully transmit to the correct destination interface in 1173 response to an offered vector. 1175 Discussion: 1176 Instantaneous Delay vector is expressed as pair of numbers. 1177 Both the specific DSCP (or IP precedence) value AND delay 1178 value combine to make a vector. 1180 The Instantaneous Delay Vector represents delay on its 1181 specific DSCP or IP precedence value. It is not necessarily 1182 based on a stream or flow. The Delay vector may be expressed 1183 as per port of the DUT/SUT. However, it must be consistent 1184 with the Expected Delay vectors. 1186 Instantaneous Delay Vector is a per-hop measurement. The 1187 DUT/SUT may change the specific DSCP or IP precedence value 1188 for a multiple-hop measurement. 1190 Instantaneous Delay vector can be obtained at any offered 1191 load. Recommend at or below the channel capacity in the 1192 absence of congestion. For congested delay, run the offered 1193 load above the channel capacity. 1195 Forwarding Vector may contain several Instantaneous Delay 1196 Vectors. For every packet received in a Forwarding Vector, 1197 there is a corresponding Instantaneous Delay Vector. 1199 Measurement Units: 1200 Seconds 1202 See Also: 1203 Delay 1204 Intended Vector 1205 Offered Vector 1206 Expected Delay Vectors 1207 Average Delay Vector 1208 Maximum Delay Vector 1209 Minimum Delay Vector 1210 Network-layer Traffic Control Mechanisms 1212 3.4.4.5 Average Delay Vector 1214 Definition: 1215 The average delay for packets containing specific DSCP or IP 1216 precedence value that a device can be observed to 1217 successfully transmit to the correct destination interface in 1218 response to an offered vector. 1220 Discussion: 1221 Average Delay vector is expressed as pair of numbers. Both 1222 the specific DSCP (or IP precedence) value AND delay value 1223 combine to make a vector. 1225 The Delay Vector represents delay on its specific DSCP or IP 1226 precedence value. It is not necessarily based on a stream or 1227 flow. The Delay vector may be expressed as per port of the 1228 DUT/SUT. However, it must be consistent with the Expected 1229 Delay vector. 1231 The Average Delay Vector is computed by averaging all the 1232 Instantaneous Delay Vectors for a given vector. 1234 Average Delay Vector is a per-hop measurement. The DUT/SUT 1235 may change the specific DSCP or IP precedence value for a 1236 multiple-hop measurement. 1238 Average Delay vector can be obtained at any offered load. 1239 Recommend at or below the channel capacity in the absence of 1240 congestion. For congested delay, run the offered load above 1241 the channel capacity. 1243 Measurement Units: 1244 Seconds 1246 See Also: 1247 Delay 1248 Intended Vector 1249 Offered Vector 1250 Expected Delay Vectors 1251 Instantaneous Delay Vector 1252 Maximum Delay Vector 1253 Minimum Delay Vector 1254 Network-layer Traffic Control Mechanisms 1256 3.4.4.6 Maximum Delay Vector 1258 Definition: 1259 The maximum delay from all packets containing specific DSCP 1260 or IP precedence value that a device can be observed to 1261 successfully transmit to the correct destination interface in 1262 response to an offered vector. 1264 Discussion: 1265 Maximum Delay vector is expressed as pair of numbers. Both 1266 the specific DSCP (or IP precedence) value AND delay value 1267 combine to make a vector. 1269 The Maximum Delay Vector represents delay on its specific 1270 DSCP or IP precedence value. It is not necessarily based on 1271 a stream or flow. The Maximum Delay vector may be expressed 1272 as per port of the DUT/SUT. However, it must be consistent 1273 with the Expected Delay vector. 1275 Maximum Delay Vector is based upon the maximum Instantaneous 1276 Delay Vector of all packets in a Forwarding Vector. 1278 Maximum Delay Vector is a per-hop measurement. The DUT/SUT 1279 may change the specific DSCP or IP precedence value for a 1280 multiple-hop measurement. 1282 Measurement Units: 1283 Seconds 1285 See Also: 1286 Delay 1287 Intended Vector 1288 Offered Vector 1289 Expected Delay Vectors 1290 Instantaneous Delay Vector 1291 Forwarding Vector 1292 Average Delay Vector 1293 Minimum Delay Vector 1295 3.4.4.7 Minimum Delay Vector 1297 Definition: 1298 The minimum delay from all packets containing specific DSCP 1299 or IP precedence value that a device can be observed to 1300 successfully transmit to the correct destination interface in 1301 response to an offered vector. 1303 Discussion: 1304 Delay vector is expressed as pair of numbers. Both the 1305 specific DSCP (or IP precedence) value AND delay value 1306 combine to make a vector. 1308 Network-layer Traffic Control Mechanisms 1310 The Minimum Delay Vector represents delay on its specific 1311 DSCP or IP precedence value. It is not necessarily based on 1312 a stream or flow. The Minimum Delay vector may be expressed 1313 as per port of the DUT/SUT. However, it must be consistent 1314 with the Expected Delay vector. 1316 Minimum Delay Vector is based upon the minimum Instantaneous 1317 Delay Vector of all packets in a Forwarding Vector. 1319 Minimum Delay Vector is a per-hop measurement. The DUT/SUT 1320 may change the specific DSCP or IP precedence value for a 1321 multiple-hop measurement. 1323 Minimum Delay vector can be obtained at any offered load. 1324 Recommend at or below the channel capacity in the absence of 1325 congestion. For congested delay, run the offered load above 1326 the channel capacity. 1328 Measurement Units: 1329 Seconds 1331 See Also: 1332 Delay 1333 Intended Vector 1334 Offered Vector 1335 Expected Delay Vectors 1336 Instantaneous Delay Vector 1337 Forwarding Vector 1338 Average Delay Vector 1339 Maximum Delay Vector 1341 3.4.4.8 Instantaneous Jitter Vector 1343 Definition: 1344 The jitter for two consecutive packets containing specific 1345 DSCP or IP precedence value that a device can be observed to 1346 successfully transmit to the correct destination interface in 1347 response to an offered vector. 1349 Discussion: 1350 Instantaneous Jitter is the absolute value of the difference 1351 between the delay measurement of two packets belonging to the 1352 same stream. 1354 Jitter vector is expressed as pair of numbers. Both the 1355 specific DSCP (or IP precedence) value AND jitter value 1356 combine to make a vector. 1358 Network-layer Traffic Control Mechanisms 1360 The delay fluctuation between two consecutive packets in a 1361 stream is reported as the "Instantaneous Jitter". 1362 Instantaneous Jitter Vector can be expressed as |D(i) - D(i- 1363 1)| where D equals the delay and i is the test sequence 1364 number. Packets lost are not counted in the measurement. 1366 Instantaneous Jitter Vector is a per-hop measurement. The 1367 DUT/SUT may change the specific DSCP or IP precedence value 1368 for a multiple-hop measurement. 1370 Forwarding Vector may contain several Instantaneous Jitter 1371 Vectors. For n packets received in a Forwarding Vector, 1372 there are exactly (n-1) Instantaneous Jitter Vectors. 1374 Measurement units: 1375 Seconds 1377 See Also: 1378 Delay 1379 Jitter 1380 Forwarding Vector 1381 Stream 1382 Expected Vectors 1383 Average Jitter Vector 1384 Peak-to-peak Jitter Vector 1386 3.4.4.9 Average Jitter Vector 1388 Definition: 1389 The average jitter for packets containing specific DSCP or IP 1390 precedence value that a device can be observed to 1391 successfully transmit to the correct destination interface in 1392 response to an offered vector. 1394 Discussion: 1395 Average Jitter Vector is the average of all the Instantaneous 1396 Jitter Vectors of the same DSCP or IP precedence value, 1397 measured during the test duration. 1399 Average Jitter vector is expressed as pair of numbers. Both 1400 the specific DSCP (or IP precedence) value AND jitter value 1401 combine to make a vector. 1403 Average Jitter vector is a per-hop measurement. The DUT/SUT 1404 may change the specific DSCP or IP precedence value for a 1405 multiple-hop measurement. 1407 Measurement units: 1408 Seconds 1409 Network-layer Traffic Control Mechanisms 1411 See Also: 1412 Jitter 1413 Forwarding Vector 1414 Stream 1415 Expected Vectors 1416 Instantaneous Jitter Vector 1417 Peak-to-peak Jitter Vector 1419 3.4.4.10 Peak-to-peak Jitter Vector 1421 Definition: 1422 The maximum possible variation in the delay for packets 1423 containing specific DSCP or IP precedence value that a device 1424 can be observed to successfully transmit to the correct 1425 destination interface in response to an offered vector. 1427 Discussion: 1428 Peak-to-peak Jitter Vector is the maximum delay minus the 1429 minimum delay of the packets (in a vector) forwarded by the 1430 DUT/SUT. 1432 Jitter vector is expressed as pair of numbers. Both the 1433 specific DSCP (or IP precedence) value AND jitter value 1434 combine to make a vector. 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 Seconds 1444 See Also: 1445 Jitter 1446 Forwarding Vector 1447 Stream 1448 Expected Vectors 1449 Average Jitter Vector 1450 Peak-to-peak Jitter Vector 1451 Network-layer Traffic Control Mechanisms 1453 4. Security Considerations 1455 Documents of this type do not directly affect the security of 1456 the Internet or of corporate networks as long as benchmarking 1457 is not performed on devices or systems connected to 1458 production networks. 1460 Packets with unintended and/or unauthorized DSCP or IP 1461 precedence values may present security issues. Determining 1462 the security consequences of such packets is out of scope for 1463 this document. 1465 5. Normative References 1467 [Br91] Bradner, S., Editor, "Benchmarking Terminology for 1468 Network Interconnection Devices", RFC 1242, July 1991. 1470 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN 1471 Switching Devices", RFC 2285, February 1998. 1473 [Ni98] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of 1474 the Differentiated Services Field (DS Field) in the IPv4 1475 and IPv6 Headers", RFC 2474, December 1998. 1477 Network-layer Traffic Control Mechanisms 1479 6. Informative References 1481 [Al99] Almes, G., Kalidindi, S., Zekauskas, M., _A One-way Delay 1482 Metric for IPPM_, RFC 2679, September 1999 1484 [Bl98] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 1485 Weiss, "An Architecture for Differentiated Services", 1486 RFC 2475, December 1998. 1488 [Br99] Bradner, S., McQuaid, J. _Benchmarking Methodology for 1489 Network Interconnect Devices_, RFC 2544, March 1999 1491 [De02] C. Demichelis, P. Chimento, _IP Packet Delay Variation 1492 Metric for IPPM_, RFC 3393, November 2002 1494 [Ja99] V. Jacobson, K. Nichols, K. Poduri, _An Expedited 1495 Forwarding PHB_, RFC 2598, June 1999 1497 [Ka99] Almes, G., Kalidindi, S., Zekauskas, M., _A One-way 1498 Packet Loss Metric for IPPM_, RFC 2680, September 1999 1500 [Ma91] A. Mankin, K. Ramakrishnan, _Gateway Congestion Control 1501 Survey_, RFC 1254, August 1991 1503 [Na84] Nagle, John, "Congestion Control in IP/TCP 1504 Internetworks", RFC 896, January 1984. 1506 [Ra99] Ramakrishnan, K. and Floyd, S., "A Proposal to add 1507 Explicit Congestion Notification (ECN) to IP", RFC 2481, 1508 January 1999. 1510 [Sc96] H. Schulzrinne, GMD Fokus, S. Casner, R. Frederick, 1511 V. Jacobson, _RTP: A Transport Protocol for Real-Time 1512 Applications_, RFC 1889, January 1996 1513 Network-layer Traffic Control Mechanisms 1515 7. Authors' Address 1517 Jerry Perser 1518 Spirent Communications 1519 26750 Agoura Road 1520 Calabasas, CA 91302 1521 USA 1523 Phone: + 1 818 676 2300 1524 EMail: jerry.perser@spirentcom.com 1526 David Newman 1527 Network Test 1528 31324 Via Colinas, Suite 113 1529 Westlake Village, CA 91362 1530 USA 1532 Phone: + 1 818 889 0011, x10 1533 EMail: dnewman@networktest.com 1535 Sumit Khurana 1536 Telcordia Technologies 1537 445 South Street 1538 Morristown, NJ 07960 1539 USA 1541 Phone: + 1 973 829 3170 1542 EMail: sumit@research.telcordia.com 1544 Shobha Erramilli 1545 QNetworx Inc 1546 1119 Campus Drive West 1547 Morganville NJ 07751 1548 USA 1550 Phone: 1551 EMail: shobha@qnetworx.com 1553 Scott Poretsky 1554 Avici Systems 1555 101 Billerica Ave_Building #6 1556 N. Billerica, MA 01862 1557 USA 1559 Phone: + 1 978 964 2287 1560 EMail: sporetsky@avici.com 1561 Network-layer Traffic Control Mechanisms 1563 8. Full Copyright Statement 1565 Copyright (C) The Internet Society (1998). All Rights 1566 Reserved. 1568 This document and translations of it may be copied and 1569 furnished to others, and derivative works that comment on or 1570 otherwise explain it or assist in its implementation may be 1571 prepared, copied, published and distributed, in whole or in 1572 part, without restriction of any kind, provided that the 1573 above copyright notice and this paragraph are included on all 1574 such copies and derivative works. However, this document 1575 itself may not be modified in any way, such as by removing 1576 the copyright notice or references to the Internet Society or 1577 other Internet organizations, except as needed for the 1578 purpose of developing Internet standards in which case the 1579 procedures for copyrights defined in the Internet Standards 1580 process must be followed, or as required to translate it into 1581 languages other than English. 1583 The limited permissions granted above are perpetual and will 1584 not be revoked by the Internet Society or its successors or 1585 assigns. This document and the information contained herein 1586 is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 1587 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 1588 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1589 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1590 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1591 FITNESS FOR A PARTICULAR PURPOSE.