idnits 2.17.1 draft-ietf-bmwg-dsmterm-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2001) is 8464 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: '4' is defined on line 697, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1242 (ref. '1') ** Downref: Normative reference to an Informational RFC: RFC 2285 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 2001 David Newman 5 Network Test 6 Sumit Khurana 7 Telcordia 8 Shobha Erramilli 9 Telcordia 10 Scott Poretsky 11 Avici 12 February 2001 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 documents 31 at any time. It is inappropriate to use Internet- Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Table of Contents 42 1. Introduction ............................................... 2 43 2. Existing definitions ....................................... 3 44 3. Term definitions .............................................3 45 3.1 Channel Capacity ..........................................3 46 3.2 Classification ............................................4 47 3.3 Code Point Forwarding Rate ................................4 48 3.4 Conforming ................................................5 49 3.5 Congestion ................................................5 50 3.6 Congestion Management .....................................6 51 3.7 Delay .....................................................6 52 3.8 Expected Output Vector ....................................7 53 3.9 Flow ......................................................8 54 3.10 Jitter ...................................................8 55 3.11 Nonconforming ............................................9 56 3.12 Offered Load Vector .....................................10 57 3.13 Policy ..................................................10 58 3.14 Provision ...............................................11 59 3.15 Sequence number .........................................11 60 3.16 Shaping .................................................12 61 3.17 Stream ..................................................12 62 3.18 Tail dropping ...........................................13 63 3.19 Unburdened Response .....................................14 64 4. Security Considerations .....................................14 65 5. References ..................................................14 66 6. Author's Address ............................................15 67 7. Full Copyright Statement ....................................16 69 1. Introduction 71 Driven by Internet economics, service providers and enterprises 72 alike have shown strong interest in adding traffic-control 73 capabilities to network devices. These capabilities would enable 74 network operators to define and deliver minimum or maximum levels of 75 bandwidth, delay, and jitter for multiple classes of traffic. 76 Perhaps more importantly, network operators would be able to set 77 pricing according to the level of service delivered. 79 Networking device manufacturers have responded with a bewildering 80 array of mechanisms for controlling network traffic. While there are 81 numerous _policy management_ and _quality of service_ frameworks, 82 many of them rely on one of two network-layer mechanisms for the 83 actual control of forwarding rate, delay, and jitter. These two 84 mechanisms are the IP precedence setting in the IP header and the 85 diff-serve code point (DSCP) defined in [3]. 87 This document describes the various terms to be used in benchmarking 88 devices that implement traffic control based on IP precedence or 89 DSCP criteria. This document is narrowly focused, in that it 90 describes only terms for measuring behavior of a device or a group 91 of devices using one of these two mechanisms. End-to-end and 92 service-level measurements are beyond the scope of this document. 94 This document introduces several new terms that will allow 95 measurements to be taken during periods of congestion. New 96 terminology is needed because most existing benchmarking terms 97 assume the absence of congestion. For example, throughput is one of 98 the most widely used measurements _- yet RFC 1242 defines throughput 99 as a rate in the absence of loss. As a result, throughput is not a 100 meaningful measurement where congestion exists. 102 Another key difference from existing benchmarking terminology is the 103 definition of measurements as observed on egress as well as ingress 104 of a device/system under test. Again, the existence of congestion 105 requires the addition of egress measurements as well as those taken 106 on ingress; without observing traffic leaving a device it is not 107 possible to say whether traffic-control mechanisms effectively dealt 108 with congestion. 110 The principal measurements introduced in this document are 111 forwarding rate, latency, and jitter, all of which can be observed 112 with or without congestion of the DUT/SUT. 114 2. Existing definitions 116 RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" 117 and RFC 2285 " Benchmarking Terminology for LAN Switching Devices" 118 should be consulted before attempting to make use of this document. 120 RFC 2474 " Definition of the Differentiated Services Field (DS 121 Field) in the IPv4 and IPv6 Headers" section 2, contains discussions 122 of a number of terms relevant to network-layer traffic control 123 mechanisms and should also be consulted. 125 For the sake of clarity and continuity this RFC adopts the template 126 for definitions set out in Section 2 of RFC 1242. Definitions are 127 indexed and grouped together in sections for ease of reference. 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 131 this document are to be interpreted as described in RFC 2119. 133 3. Term definitions 135 3.1 Channel Capacity 137 Definition: 138 The maximum forwarding rate of a link or set of aggregated 139 links at which none of the offered packets are dropped by the 140 DUT/SUT. 142 Discussion: 143 Channel capacity measures the data rate at the egress 144 interface(s) of the DUT/SUT. In contrast, throughput as defined 145 in RFC 1242 measures the data rate is based on the ingress 146 interface(s) of the DUT/SUT. 148 Ingress-based measurements do not account for congestion of the 149 DUT/SUT. Channel capacity, as an egress measurement, does take 150 congestion into account. 152 Understanding channel capacity is a necessary precursor to any 153 measurement involving congestion. Throughput numbers can be 154 higher than channel capacity because of queueing. 156 Measurement units: 158 N-octet packets per second 160 Issues: 162 See Also: 163 Throughput [1] 165 3.2 Classification 167 Definition: 168 Local mapping of Policies to the IP Precedence or DSCP value in 169 each frame. 171 Discussion: 172 Could be based on the DS field or IP Precedence in the packet 173 header. Could be based on MF criteria such as IP Source and 174 destination addresses, protocol and port number. 176 Covers reclassification. A Hop does not know if a previous Hop 177 classified the packets. Since the scope of the document is a 178 per-hop-behavior, we avoid end-to-end discussions. 180 Classification should cover all cases defined in policy. This 181 may include rules mandating packet drops, not just forwarded 182 packets. 184 Measurement units: 186 n/a 188 Issues: 190 See Also: 192 3.3 Code Point Forwarding Rate 194 Definition: 195 The number of packets per second in for all packets containing 196 a single DSCP (or IP precedence) that a device can be observed 197 to successfully transmit to the correct destination interface 198 in response to a specified offered load. 200 Discussion: 201 - CP based, not port nor IP stream based. 202 - Per-hop measurement. A DUT may change the DSCP for a 203 multiple-hop measurement. 205 Measurement units: 207 N-octet packets per second 209 Issues: 211 See Also: 213 3.4 Conforming 215 Definition: 216 A packet meeting a certain policy. 218 Discussion: 219 Consider a policy that allows a given application to consume 220 only X bit/s of channel capacity and no more. 222 In a congestion scenario, some individual packets will be 223 conforming and others will not. 225 It cannot be said that an entire stream or flow is conforming, 226 since an offered load that exceeds policy boundaries will 227 necessarily carry some nonconforming traffic. 229 Measurement units: 231 n/a 233 Issues: 235 See Also: 237 3.5 Congestion 239 Definition: 240 A condition in which one or more egress interfaces are offered 241 more packets than can be forwarded at any given instant. 243 Discussion: 245 This condition is a superset of the overload definition [2]. 246 That definition assumes the overload is introduced by strictly 247 by the tester on ingress of a DUT/SUT. That may or may not be 248 the case here. 250 Another difference is that with multiple-DUT measurements, 251 congestion may occur at multiple points. For example, multiple 252 edge devices collectively may congest a core device. In 253 contrast, overload [1] deals only with overload on ingress. 255 Ingress observations alone are not sufficient to cover all 256 cases in which congestion may occur. A device with an infinite 257 amount of memory could buffer an infinite amount of packets, 258 and eventually forward all of them. However, these packets may 259 or may not be forwarded during the test duration. Even though 260 ingress interfaces accept all packets without loss, this 261 hypothetical device may still be congested. 263 The definition presented here explicitly defines congestion as 264 an event observable on egress interfaces. Regardless of 265 internal architecture, any device that cannot forward packets 266 on one or more egress interfaces is congested. 268 Measurement units: 270 n/a 272 Issues: 274 See Also: 276 3.6 Congestion Management 278 Definition: 279 An implementation of one or more per-hop-behaviors to avoid or 280 minimize the condition of congestion. 282 Discussion: 283 Congestion management may seek either to control congestion or 284 avoid it altogether. Such mechanisms classify packets based 285 upon IP Precedence or DSCP settings in a packet's IP header. 287 Congestion avoidance mechanisms seek to prevent congestion 288 before it actually occurs. 290 Congestion control mechanisms gives one or more service classes 291 preferential treatment over other classes during periods of 292 congestion. 294 Measurement units: 296 n/a 298 Issues: 300 See Also: 302 3.7 Delay 304 Definition: 306 The time interval starting when the last bit of the input frame 307 reaches the input port of the DUT/SUT and ending when the last 308 bit of the output frame is seen on the output port of the 309 DUT/SUT. 311 Discussion: 312 Delay measurement is measured the same regardless of the type 313 of DUT/SUT. Latency [1] require some knowledge of whether the 314 DUT/SUT is a "store and forward" or a "bit forwarding" device. 315 The fact that a DUT/SUT's technology has a lower delay than 316 another technology should be visible in the measurement. 318 The measurement point of the last bit is more like the way an 319 IP datagram is processed. A datagram is not passed up or down 320 the stack unless it is complete. Competition happens at the 321 last bit of the datagram. 323 Delay can be run at any offered load. Recommend at or below 324 the channel capacity for non-congested delay. For congested 325 delay, run the offered load above the channel capacity. 327 Measurement units: 329 Seconds. 331 Issues: 333 See Also: 335 3.8 Expected Output Vector 337 Definition: 338 A vector describing the expected output rate of packets having 339 a specific code-point for each code-point in the code-point set 340 depending on the offered load vector and device PHB 341 configurations of the DUT/SUT. 343 Discussion: 344 The DUT is configured in a certain way in order that service 345 discrimination happens for behavior aggregates when a specific 346 traffic mix consisting of multiple behavior aggregates is 347 applied. This term attempts to capture the expected behavior 348 for which the device is configured given a certain load. 350 The actual algorithms or mechanism, that the DUT uses to 351 achieve service discrimination, is not important in describing 352 the expected output vector. 354 Measurement units: 355 bits per second 356 N-octets per second 358 See Also: 359 Offered Load Vector 361 3.9 Flow 363 Definition: 364 A flow is a one or more of packets sharing a common intended 365 pair of source and destination interfaces. 367 Discussion: 368 Packets are grouped by which interface they ingress and egress 369 the DUT/SUT. 371 A flow can contain multiple source IP addresses and/or 372 destination IP addresses. All packets in a flow must enter on 373 the same ingress interface and exit on the same egress 374 interface, and have some common network layer content. 376 Microflows [3] are a subset of flows. As defined in [3], 377 microflows require application-to-application measurement. In 378 contrast, flows use lower-layer classification criteria. Since 379 this document focuses on network-layer classification criteria, 380 we concentrate here on the use of network-layer identifiers in 381 describing a flow. Flow identifiers also may reside at the 382 data-link, transport, or application layers of the ISO model. 383 However, identifiers other than those at the network layer are 384 out of scope for this document. 386 A flow may contain a single code point/IP precedence or may 387 contain multiple values destined for a single egress interface. 388 This is determined by the test methodology. 390 Measurement units: 392 n/a 394 Issues: 396 See Also: 397 Microflow [3] 398 Streams 400 3.10 Jitter 402 Definition: 403 Variation in delay. 405 Discussion: 407 Jitter as the absolute value of the difference between the 408 delay measurement of two adjacent packets |D(i) - D(i+1)|. The 409 jitter between two packets is reported as the "instantaneous 410 jitter". Packets lost are not counted in the jitter 411 measurement. 413 Average Jitter is the average of the instantaneous jitter 414 measured during the test duration. 416 Peak-to-peak jitter is the maximum delay minus the minimum 417 delay of the packets forwarded by the DUT/SUT. 419 Measurement units: 421 Seconds (instantaneous) 422 Seconds P-P (peak to peak) 423 Seconds avg (average) 425 Issues: 427 See Also: 429 3.11 Nonconforming 431 Definition: 432 A packet in violation of a given policy. 434 Discussion: 435 A packet can be said to be nonconforming when it violates the 436 terms of a given policy. For example, a policy may set an upper 437 bound on bandwidth for a given class of traffic. When a DUT/SUT 438 is offered packets of that class in excess of the terms allowed 439 by the policy, the DUT/SUT must discard some packets of that 440 class. The discarded packets are nonconforming to policy. 442 Note that the decision to drop or forward packets is 443 essentially time-based. Even though two packets may share a 444 common DSCP or IP precedence value, one may be forwarded and 445 one may be dropped depending on when the packets are offered to 446 the DUT. It is the combination of classification and policy 447 that determines whether packets are conforming or 448 nonconforming. 450 Measurement units: 452 n/a 454 Issues: 456 See Also: 458 3.12 Offered Load Vector 460 Definition: 461 A vector describing the rate at which packets having a specific 462 code-point are offered to the DUT/SUT, for each code-point in a 463 code-point set. 465 Discussion: 466 Offered loads across the different code-point classes, 467 constituting a code-point set, determine the metrics associated 468 with a specific code-point traffic class. 470 Measurement Units: 472 bits per second 473 N-octets per second 475 Issues: 476 Packet size. 477 Traffic descriptors such as peak rate, average rate etc. 479 See Also: 480 Expected output vector 482 3.13 Policy 484 Definition: 485 A rule or set of rules used to classify packets. 487 Discussion: 488 In the context of data networking, policies consist of one or 489 (usually) more rules to administer, manage, and control access 490 to network resources. These resources include applications, 491 devices, bandwidth, and any other elements attached to a common 492 network. 494 In the context of network devices, PHBs are the mechanisms by 495 which a policy may be enforced. Packets offered to a DUT/SUT 496 may be conforming or nonconforming to a given policy. A PHB may 497 cause some packets to be dropped or forwarded based on the 498 rules laid down by a given policy. 500 Measurement units: 502 n/a 504 Issues: 506 See Also: 508 Conforming 509 Nonconforming 510 PHB 512 3.14 Provision 514 Definition: 515 Configuration of the DUT/SUT to match a specified rule or rules 516 in the policy. 518 Discussion: 519 A DUT/SUT must be configured in accordance with the rules of a 520 policy for that policy's rules to be enforced. Provision may be 521 done on a dynamic or a static basis. 523 Measurement units: 525 n/a 527 Issues: 529 See Also: 530 Conforming 531 Nonconforming 532 PHB 533 Policy 535 3.15 Sequence number 537 Definition: 538 A field in the IP payload portion of the packet that is used to 539 verify the order of the packets on the egress of the DUT/SUT. 541 Discussion: 542 The traffic generator sets the sequence number value and the 543 traffic receiver checks the value upon receipt of the packet. 544 The traffic generator changes the value on each packet 545 transmitted based on an algorithm agreed to by the traffic 546 receiver. 548 The traffic receiver keeps track of the sequence numbers on a 549 per stream basis. In addition to number of received packets, 550 the traffic receiver may also report number of in-sequence 551 packets, number of out-sequence packets and number of duplicate 552 packets. 554 The recommended algorithm to use to change the sequence number 555 on sequential packets is an incrementing value. 557 Measurement units: 559 n/a 561 Issues: 563 See Also: 564 Stream 566 3.16 Shaping 568 Definition: 569 DUT/SUT control of code point forwarding rate so that a flow or 570 stream does not exceed or drop below a specified rate set in 571 the policy. 573 Discussion: 574 [3] defines a behavior aggregate in which a DUT/SUT performs a 575 specific forwarding treatment on a group of packets. Shaping is 576 one such treatment: A device may drop or forward packets within 577 a stream or flow depending on whether the packets are in or out 578 of the terms of the policy. 580 Measurement units: 582 n/a 584 Issues: 586 See Also: 587 Conforming 588 Nonconforming 589 Policy 591 3.17 Stream 593 Definition: 594 A group of packets tracked as a single entity by the traffic 595 receiver. A stream shares a common content such as type (IP, 596 UDP), frame size, or payload. 598 Discussion: 599 Streams are tracked by "sequence number" or "unique signature 600 field" (RFC 2889). Streams define how individual packet's 601 statistics are grouped together to form an intelligible 602 summary. 604 Common stream groupings would be by egress interface, 605 destination address, source address, DCSP, or IP precedence. A 606 stream using sequence numbers can track the ordering of packets 607 as they transverse the DUT/SUT. 609 Streams are not restricted to a pair of source and destination 610 interfaces as long as all packets are tracked as a single 611 entity. A mulitcast stream can be forward to multiple 612 destination interfaces. 614 Measurement units: 616 n/a 618 Issues: 620 See Also: 621 Flow 622 MicroFlow [3] 623 Sequence number 625 3.18 Tail dropping 627 Definition: 628 The condition in which a DUT/SUT discards newly arriving 629 packets. 631 Discussion: 632 Every DUT/SUT has a finite amount of traffic it can forward, 633 beyond which congestion occurs. Once the offered load crosses 634 the congestion threshold, the device may discard any additional 635 traffic that arrives until congestion clears. 637 Tail dropping is typically a function of offered load exceeding 638 a DUT/SUT's buffer capacity, but other factors internal to the 639 DUT/SUT may also come into play. In terms of what is externally 640 observable, tail dropping can be said to occur only when 641 offered load exceeds channel capacity. Since a DUT/SUT may 642 buffer traffic on ingress, the actual threshold for tail 643 dropping may be higher than channel capacity. 645 Measurement units: 647 n/a 649 Issues: 650 Some congestion management mechanisms seek to avoid tail dropping by 651 discarding packets before offered load exceeds channel capacity. In 652 the presence of such mechanisms, neither congestion nor tail 653 dropping should occur. 655 See Also: 656 Channel capacity 657 Congestion 659 3.19 Unburdened Response 661 Definition: 662 A performance measure obtained when mechanisms used to support 663 DiffServ are disabled. 665 Discussion: 666 Enabling Diffserv mechanisms such as scheduling algorithms may 667 impose an additional processing overhead for packets, which may 668 cause the aggregate response to suffer even when traffic 669 belonging to only one class, the best effort class, is offered 670 to the device. Comparisons with "unburdened performance" may 671 thus be in order when obtaining metrics to ensure that enabling 672 Diffserv mechanisms doesn't impose an excessive performance 673 penalty. 675 Measurement units: 676 TBD. 678 4. Security Considerations 680 Documents of this type do not directly effect the security of 681 the Internet or of corporate networks as long as benchmarking 682 is not performed on devices or systems connected to operating 683 networks. 685 5. References 687 [1] Bradner, S., Editor, "Benchmarking Terminology for Network 688 Interconnection Devices", RFC 1242, July 1991. 690 [2] Mandeville, R., "Benchmarking Terminology for LAN Switching 691 Devices", RFC 2285, February 1998. 693 [3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of the 694 Differentiated Services Field (DS Field) in the IPv4 and 695 IPv6 Headers", RFC 2474, December 1998. 697 [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 698 Weiss, "An Architecture for Differentiated Services", RFC 699 2475, December 1998. 701 6. Author's Address 703 Jerry Perser 704 Spirent Communications 705 26750 Agoura Road 706 Calabasas, CA 91302 707 USA 709 Phone: + 1 818 676 2300 710 EMail: jerry.perser@spirentcom.com 712 David Newman 713 Network Test 714 321 Newark St., Suite 301 715 Hoboken, NJ 07030 716 USA 718 Phone: + 1 201 798 9999 719 EMail: dnewman@networktest.com 721 Sumit Khurana 722 Telcordia Technologies 723 445 South Street 724 Morristown, NJ 07960 725 USA 727 Phone: + 1 973 829 3170 728 EMail: sumit@research.telcordia.com 730 Shobha Erramilli 731 Telcordia Technologies 732 331 Newman Springs Road, 733 Navesink, NJ 07701 734 USA 736 Phone: + 1 732 758 5508 737 EMail: shobha@research.telcordia.com 739 Scott Poretsky 740 Avici Systems 741 101 Billerica Ave_Building #6 742 N. Billerica, MA 01862 743 USA 745 Phone: + 1 978 964 2287 746 EMail: sporetsky@avici.com 748 7. Full Copyright Statement 750 Copyright (C) The Internet Society (1998). All Rights 751 Reserved. 753 This document and translations of it may be copied and 754 furnished to others, and derivative works that comment on or 755 otherwise explain it or assist in its implementation may be 756 prepared, copied, published and distributed, in whole or in 757 part, without restriction of any kind, provided that the above 758 copyright notice and this paragraph are included on all such 759 copies and derivative works. However, this document itself may 760 not be modified in any way, such as by removing the copyright 761 notice or references to the Internet Society or other Internet 762 organizations, except as needed for the purpose of developing 763 Internet standards in which case the procedures for copyrights 764 defined in the Internet Standards process must be followed, or 765 as required to translate it into languages other than English. 767 The limited permissions granted above are perpetual and will 768 not be revoked by the Internet Society or its successors or 769 assigns. This document and the information contained herein is 770 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 771 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 772 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 773 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 774 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 775 FOR A PARTICULAR PURPOSE.