Network Working Group Jerry Perser INTERNET-DRAFT Spirent Expires in:December 2001May 2002 David Newman Network Test Sumit Khurana Telcordia Shobha ErramilliTelcordiaQNetworx Scott Poretsky Avici SystemsJuneNovember 2001 Terminology for Benchmarking Network-layer Traffic Control Mechanisms<draft-ietf-bmwg-dsmterm-01.txt><draft-ietf-bmwg-dsmterm-02.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Table of Contents 1. Introduction............................................................................................. 2 2. Existing definitions............................................................................. 3 3. Termdefinitions.............................................3definitions ............................................3 3.1Channel Capacity..........................................3 3.2 Classification............................................4 3.3Configuration Terms 3.1.1 Classification .........................................3 3.1.2 CodepointSet.............................................4 3.4 Conforming................................................5 3.5 Congestion................................................5 3.6Set ..........................................4 3.1.3 CongestionManagement.....................................6 3.7 Delay.....................................................7 3.8 Expected Vector...........................................7.............................................4 3.1.4 Congestion Management ..................................5 3.2 Vectors ....................................................6 3.2.1 Intended Vector ........................................6 Network-layer Traffic Control Mechanisms3.9 Flow......................................................8 3.103.2.2 Offered Vector .........................................6 3.2.3 Expected Vectors 3.2.3.1 Expected Forwarding Vector.......................................9 3.11 Jitter...................................................9 3.12 Nonconforming...........................................10 3.13 Offered Vector..........................................11 3.14 Stream..................................................11 3.15 Tail dropping...........................................12 3.16...........................7 3.2.3.2 Expected Loss Vector .................................8 3.2.3.3 Expected Sequence Vector .............................8 3.2.3.4 Expected Delay Vector ................................9 3.2.3.5 Expected Jitter Vector ..............................10 3.2.4 Output Vectors 3.2.4.1 Forwarding Vector ...................................11 3.2.4.2 Loss Vector .........................................11 3.2.4.3 Sequence Vector .....................................12 3.2.4.4 Delay Vector ........................................13 3.2.4.5 Jitter Vector .......................................14 3.3 Measurement Terms 3.3.1 Channel Capacity ......................................15 3.3.2 Conforming ............................................15 3.3.3 Nonconforming .........................................16 3.3.4 Delay .................................................16 3.3.5 Flow ..................................................17 3.3.6 Stream ................................................18 3.3.7 Test Sequencenumber....................................12 3.17 Unburdened Response.....................................13number ..................................19 3.3.8 Undifferentiated Response .............................19 4. SecurityConsiderations.....................................13Considerations ....................................20 5.References..................................................14References .................................................20 6. Author'sAddress............................................14Address ...........................................21 7. Full CopyrightStatement....................................15Statement ...................................22 1. IntroductionDriven by Internet economics, service providers and enterprises alike have shown strong interest in adding traffic-control capabilities to network devices. These capabilities would enable network operators to define and deliver minimum or maximum levels of bandwidth, delay, and jitter for multiple classes of traffic. Perhaps more importantly, network operators would be able to set pricing according to the level of service delivered. Networking device manufacturers have responded with a wide variety of approaches for controlling network traffic. While there are numerous ôpolicy managementö and ôquality of serviceö frameworks, many of them rely on one of two network-layer mechanisms for the actual control of forwarding rate, delay, and jitter. These two mechanisms are the IP precedence setting in the IP header and the diff-serv code point (DSCP) defined in [3].This document describes terminology for thevarious terms to be used inbenchmarking of devices that implement traffic control based on IP precedence orDSCPdiff-serv code point criteria.This documentNew terminology isnarrowly focused, in that it describes only terms for measuring behavior of a device or a group of devices using one of these two mechanisms. End-to-end and service-levelneeded because most existing measurementsare beyondassume thescopeabsence ofthis document.congestion and only a single per-hop- behavior. This document introduces several new terms that will allow measurements to be taken during periods of congestion.New terminology is needed because most existing benchmarking terms assume the absence of congestion. For example, throughput is one of the most widely used measurements û- yet RFC 1242 defines throughput as a rate in the absence of loss. As a result, throughput is not a meaningful measurement where congestion exists.Another key difference from existingbenchmarkingterminology is the definition of measurements as observed on egress as well as ingress of a device/system under test. Again, the existence of congestion requires the addition of egress measurements as well as those takenNetwork-layer Traffic Control Mechanismson ingress; without observing traffic leaving adevicedevice/system it is not possible to say whether traffic-control mechanisms effectively dealt with congestion. The principal measurements introduced in this document arerate vectors,vectors for rate, delay, and jitter, all of which can be observed with or without congestion of the DUT/SUT.2. Existing definitions RFC 1242Network-layer Traffic Control Mechanisms This document describes only those terms relevant to measuring behavior of a device or a group of devices using one of these two mechanisms. End-to-end and service-level measurements are beyond the scope of this document. 2. Existing definitions RFC 1242 "Benchmarking Terminology for Network Interconnect Devices" and RFC 2285 "Benchmarking Terminology for LAN Switching Devices" should be consulted before attempting to make use of this document. RFC 2474 "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" section 2, contains discussions of a number of terms relevant to network-layer traffic control mechanisms and should also be consulted. For the sake of clarity and continuity this RFC adopts the template for definitions set out in Section 2 of RFC 1242. Definitions are indexed and grouped together in sections for ease of reference. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Term definitions 3.1Channel Capacity Definition: The maximum forwarding rate of a link or set of aggregated links at which none of the offered packets are dropped by the DUT/SUT. Discussion: Channel capacity measures the data rate at the egress interface(s) of the DUT/SUT. In contrast, throughput as defined in RFC 1242 measures the data rate is based on the ingress interface(s) of the DUT/SUT. Ingress-based measurements do not account for congestion of the DUT/SUT. Channel capacity, as an egress measurement, does take congestion into account. Understanding channel capacity is a necessary precursor to any measurement involving congestion. Throughput numbers can be higher than channel capacity because of queueing. Network-layer Traffic Control Mechanisms Measurement units: N-octet packets per second Issues: See Also: Throughput [1] 3.2Configuration Terms 3.1.1 Classification Definition: Selection of packets based on the contents of packet header according to defined rules. Discussion: Packets can be selected based on the DS field or IP Precedence in the packet header. Classification can also be based on Multi-Field (MF) criteria such as IP Source and destination addresses, protocol and port number. Classification determines the per-hop behaviors and traffic conditioning functions such as shaping and dropping that are to be applied to the packet. Measurement units: Network-layer Traffic Control Mechanisms n/a Issues: See Also:Rules 3.33.1.2 Codepoint Set Definition: The set of all DS Code-points or IP precedence values used during the test duration. Discussion: Describes all the code-point markings associated with packets that are input to the DUT/SUT. For each entry in the codepoint set, there are associated vectors describing the rate of traffic containing that particular DSCP or IP precedence value. The treatment that a packet belonging to a particular code- point gets is subject to the DUT classifying packets to map toNetwork-layer Traffic Control Mechanismsthe correct PHB. Moreover, the forwarding treatment in general is also dependent on the complete set of offered vectors. Measurement Units: n/a See Also:3.4 Conforming Definition: Packets that lie within the bounds specified by a traffic profile. Discussion: Rules may be configured that allow a given traffic class to consume only X bit/s of channel capacity and no more. All additional packets are dropped. All packets that constitute the first X bits/s measured over a period of time specified by the traffic profile, are then said to be conforming whereas those exceeding the bound are non conforming. In particular in a congestion scenario, some individual packets will be conforming and others will not. Measurement units: n/a Issues: See Also: Expected Vector Forwarding Vector Offered Vector 3.53.1.3 Congestion Definition: A condition in which one or more egress interfaces are offered more packets thancan beare forwarded at any given instant. Discussion: This condition is a superset of the overload definition [2].ThatThe overload definition assumes theoverloadcongestion is introduced strictly by the tester on ingress of a DUT/SUT. That may or may not be the case here.Network-layer Traffic Control MechanismsAnother difference is that with multiple-DUT measurements, congestion may occur at multiple points. For example, multiple edge devices collectively may congest a core device. In contrast, overload [1] deals only with overload on ingress. Network-layer Traffic Control Mechanisms Ingress observations alone are not sufficient to cover all cases in which congestion may occur. A device with an infinite amount of memory could buffer an infinite amount of packets, and eventually forward all of them. However, these packets may or may not be forwarded during the test duration. Even though ingress interfaces accept all packets without loss, this hypothetical device may still be congested. The definition presented here explicitly defines congestion as an event observable on egress interfaces. Regardless of internal architecture, any device that cannot forward packets on one or more egress interfaces is congested. Measurement units: n/a Issues: See Also:3.63.1.4 Congestion Management Definition: An implementation of one or more per-hop-behaviors to avoid or minimize the condition of congestion. Discussion: Congestion management may seek either to control congestion or avoid it altogether. Such mechanisms classify packets based upon IP Precedence or DSCP settings in apacketÆspacket's IP header. Congestion avoidance mechanisms seek to prevent congestion before it actually occurs. Congestion control mechanisms gives one or more service classes preferential treatment over other classes during periods of congestion. Measurement units: n/a Issues: See Also: Network-layer Traffic Control Mechanisms3.7 Delay Definition: The time interval starting when the last bit of the input IP packets reaches the input port of the DUT/SUT and ending when the last bit of the output IP packets is seen on the output port of the DUT/SUT. Discussion: Delay3.2 Vectors A vector ismeasured the same regardless of the type of DUT/SUT. Latency [1] require some knowledgea group ofwhether the DUT/SUT ispackets all containing a"store and forward"specific DSCP or IP precedence value. Vectors are expressed as a"bit forwarding" device. The fact that a DUT/SUT's technology has a lower delay than another technology should be visible.pair of numbers. Themeasurement point at the end is more like the way an internet datagram is processed. An internet datagramfirst isnot passed up or downbeing thestack unless itparticular diff-serv value. The second iscomplete. Completion occurs once the last bit of the IP packet has been received. Delay can be run at any offered load. Recommend at or belowthechannel capacity for non-congested delay. For congestedmetric expressed as a rate, loss percentage, delay,run the offered load above the channel capacity. Measurement units: Seconds. Issues: See Also: 3.8 Expectedor jitter. 3.2.1 Intended Vector Definition: A vector describing theexpected outputrateofat which packets having a specificcode-point. The value is dependent oncode-point (or IP precedence) that an external source attempts to transmit to a DUT/SUT. Discussion: Intended loads across theset of offered vectors and configuration ofdifferent code-point classes determine theDUT. Discussion: The DUT is configured inmetrics associated with acertain way in order that service discrimination happensspecific code-point traffic class. Measurement Units: N-octets packets per second Issues: See Also: Offered Vector Expected Forwarding Vector Expected Loss Vector Expected Sequence Vector Expected Delay Vector Expected Jitter Vector Forwarding Vector Loss Vector 3.2.2 Offered Vector Definition: A vector describing the measured rate at which packets having a specific DSCP or IP precedence value are offered to the DUT/SUT. Discussion: Offered loads across the different code-point classes, constituting a code-point set, determine the metrics associated with a specific code-point traffic class. Measurement Units: N-octets packets per second Network-layer Traffic Control Mechanisms Issues: Packet size. See Also: Expected Forwarding Vector Expected Loss Vector Expected Sequence Vector Expected Delay Vector Expected Jitter Vector Forwarding Vector Codepoint Set 3.2.3 Expected Vectors 3.2.3.1 Expected Forwarding Vector Definition: A vector describing the expected output rate of packets having a specific DSCP or IP precedence value. The value is dependent on the set of offered vectors and configuration of the DUT. Discussion: The DUT is configured in a certain way in order that service differentiation occurs for behavior aggregates when a specific traffic mix consisting of multiple behavior aggregates is applied. This term attempts to capture the expected forwarding behavior, for which the device is configured, when subjected to a certain offered load.Network-layer Traffic Control MechanismsThe actual algorithms or mechanism, that the DUT uses to achieve servicediscrimination,differentiation, is not important in describing the expected vector. Measurement units:N-octetsN-octet packets per second Issues: See Also:ForwardingIntended Vector Offered VectorCodepoint Set 3.9 FlowOutput Vectors Expected Loss Vector Expected Sequence Vector Expected Delay Vector Expected Jitter Vector Network-layer Traffic Control Mechanisms 3.2.3.2 Expected Loss Vector Definition: Aflow is a one or morevector describing the percentage ofpackets sharingpackets, having acommon intended pairspecific DSCP or IP precedence value, that should not be forwarded. The value is dependent on the set ofsourceoffered vectors anddestination interfaces. Discussion: Packets are groups byconfiguration of theingress and egress interfaces they use onDUT. Discussion: The DUT is configured in agiven DUT/SUT. A flow can containcertain way in order that service differentiation occurs for behavior aggregates when a specific traffic mix consisting of multiplesourcebehavior aggregates is applied. This term attempts to capture the expected loss behavior, for which the device is configured, when subjected to a certain offered load. The actual algorithms or mechanism, that the DUT uses to achieve service differentiation, is not important in describing the expected loss vector. Measurement Units: Percentage of intended packets that are expected to be dropped. Issues: See Also: Intended Vector Offered Vector Expected Forwarding Vector Expected Sequence Vector Expected Delay Vector Expected Jitter Vector 3.2.3.3 Expected Sequence Vector Definition: A vector describing the expected sequencing of packets having a specific DSCP or IP precedence value. The value is dependent on the set of offered vectors and configuration of the DUT. Discussion: The DUT is configured in a certain way in order that service differentiation occurs for behavior aggregates when a specific traffic mix consisting of multiple behavior aggregates is applied. This term attempts to capture the expected sequence behavior, for which the device is configured, when subjected to a certain offered load. Network-layer Traffic Control Mechanisms The actual algorithms or mechanism, that the DUT uses to achieve service differentiation, is not important in describing the expected vector. Measurement Units: N-octet packets per second Issues: See Also: Intended Vector Offered Vector Output Vectors Expected Loss Vector Expected Forwarding Vector Expected Delay Vector Expected Jitter Vector 3.2.3.4 Expected Delay Vector Definition: A vector describing the expected delay for packets having a specific DSCP or IP precedence value. The value is dependent on the set of offered vectors and configuration of the DUT. Discussion: The DUT is configured in a certain way in order that service differentiation occurs for behavior aggregates when a specific traffic mix consisting of multiple behavior aggregates is applied. This term attempts to capture the expected delay behavior, for which the device is configured, when subjected to a certain offered load. The actual algorithms or mechanism, that the DUT uses to achieve service differentiation, is not important in describing the expected delay vector. Measurement units: Seconds. Issues: See Also: Intended Vector Offered Vector Output Vectors Expected Loss Vector Expected Sequence Vector Expected Forwarding Vector Expected Jitter Vector Network-layer Traffic Control Mechanisms 3.2.3.5 Expected Jitter Vector Definition: A vector describing the expected variation in the delay of packet arrival times for packets having specific DSCP or IP precedence value. The value is dependent on the set of offered vectors and configuration of the DUT. Discussion: Jitter is the absolute value of the difference between the delay measurement of two packets belonging to the same stream. The jitter between two consecutive packets in a stream is reported as the "instantaneous jitter". Instantaneous jitter can be expressed as |D(i) - D(i-1)| where D equals the delay and i is the test sequence number. Packets lost are not counted in the jitter measurement. Average Jitter is the average of the instantaneous jitter measured during the test duration. Peak-to-peak jitter is the maximum delay minus the minimum delay of the packets forwarded by the DUT/SUT. Measurement units: Seconds (instantaneous) Seconds P-P (peak to peak) Seconds Avg (average) Issues: See Also: Intended Vector Offered Vector Output Vectors Expected Loss Vector Expected Sequence Vector Expected Delay Vector Expected Forwarding Vector 3.2.4 Output Vectors Network-layer Traffic Control Mechanisms 3.2.4.1 Forwarding Vector Definition: The number of packets per second for all packets containing a specific DSCP or IP precedence value that a device can be observed to successfully transmit to the correct destination interface in response to an offered vector. Discussion: Forwarding Vector is expressed as pair of numbers. Both the specific DSCP (or IP precedence) value AND the packets per second value combine to make a vector. The Forwarding Vector represents packet rate based on its specific DSCP (or IP precedence) value. It is not necessarily based on a stream or flow. The Forwarding Vector may be expressed as per port of the DUT/SUT. However, it must be consistent with the Expected Forwarding Vector. Forwarding Vector is a per-hop measurement. The DUT/SUT may change the specific DSCP (or IP precedence) value for a multiple-hop measurement. Measurement units: N-octet packets per second Issues: See Also: Intended Vector Offered Vector Expected Vectors Loss Vector Sequence Vector Delay Vector Jitter Vector 3.2.4.2 Loss Vector Definition: The percentage of packets containing specific DSCP or IP precedence value that a DUT/SUT did not transmit to the correct destination interface in response to an offered vector. Discussion: Loss Vector is expressed as pair of numbers. Both the specific DSCP (or IP precedence) value AND the percentage value combine to make a vector. Network-layer Traffic Control Mechanisms The Loss Vector represents percentage based on a specific DSCP or IP precedence value. It is not necessarily based on a stream or flow. The Loss Vector may be expressed as per port of the DUT/SUT. However, it must be consistent with the Expected Loss Vector Loss Vector is a per-hop measurement. The DUT/SUT may change the specific DSCP or IP precedence value for a multiple-hop measurement. Measurement Units: Percentage of offered packets that are not forwarded. Issues: See Also: Intended Vector Offered Vector Expected Vectors Forwarding Vector Sequence Vector Delay Vector Jitter Vector 3.2.4.3 Sequence Vector Definition: The number of packets per second for all packets containing a specific DSCP or IP precedence value that a device can be observed to transmit out of sequence to the correct destination interface in response to an offered vector. Discussion: Sequence Vector is expressed as pair of numbers. Both the specific DSCP (or IP precedence) value AND the packets per second value combine to make a vector. The Sequence Vector represents packet rate based on its specific DSCP or IP precedence value. It is not necessarily based on a stream or flow. The Sequence Vector may be expressed as per port of the DUT/SUT. However, it must be consistent with the Expected Sequence Vector. Sequence Vector is a per-hop measurement. The DUT/SUT may change the specific DSCP or IP precedence value for a multiple-hop measurement. Measurement Units: N-octet packets per second Issues: Network-layer Traffic Control Mechanisms See Also: Intended Vector Offered Vector Expected Vectors Loss Vector Forwarding Vector Delay Vector Jitter Vector 3.2.4.4 Delay Vector Definition: The delay for packets containing specific DSCP or IP precedence value that a device can be observed to successfully transmit to the correct destination interface in response to an offered vector. Discussion: Delay vector is expressed as pair of numbers. Both the specific DSCP (or IP precedence) value AND delay value combine to make a vector. The Delay Vector represents delay on its specific DSCP or IP precedence value. It is not necessarily based on a stream or flow. The Delay vector may be expressed as per port of the DUT/SUT. However, it must be consistent with the Expected Delay vector. Delay vector is measured similarly regardless of the type of DUT/SUT. Latency [1] require some knowledge of whether the DUT/SUT is a "store and forward" or a "bit forwarding" device. The fact that a DUT/SUT's technology has a lower delay than another technology should be visible. Delay Vector is a per-hop measurement. The DUT/SUT may change the specific DSCP or IPaddresses and/orprecedence value for a multiple-hop measurement. Delay vector can be obtained at any offered load. Recommend at or below the channel capacity in the absence of congestion. For congested delay, run the offered load above the channel capacity. Measurement Units: seconds Issues: See Also: Delay Network-layer Traffic Control Mechanisms Intended Vector Offered Vector Expected Delay Vector Loss Vector Forwarding Vector Jitter Vector 3.2.4.5 Jitter Vector Definition: The variation in the delay for packets containing specific DSCP or IP precedence value that a device can be observed to successfully transmit to the correct destination interface in response to an offered vector. Discussion: Jitter is the absolute value of the difference between the delay measurement of two packets belonging to the same stream. Jitter vector is expressed as pair of numbers. Both the specific DSCP (or IPaddresses. Allprecedence) value AND jitter value combine to make a vector. The jitter between two consecutive packets in a stream is reported as the "instantaneous jitter". Instantaneous jitter can be expressed as |D(i) - D(i-1)| where D equals the delay and i is the test sequence number. Packets lost are not counted in the jitter measurement. Jitter vector is a per-hop measurement. The DUT/SUT may change the specific DSCP or IP precedence value for a multiple-hop measurement. Average Jitter is the average of the instantaneous jitter measured during the test duration. Peak-to-peak Jitter is the maximum delay minus the minimum delay of the packetsin a flow must enter onforwarded by thesame ingress interface and exit onDUT/SUT. Measurement units: Seconds (instantaneous) Seconds P-P (peak to peak) Seconds Avg (average) Issues: See Also: Intended Vector Offered Vector Expected Vectors Network-layer Traffic Control Mechanisms Loss Vector Sequence Vector Delay Vector Forwarding Vector 3.3 Measurement Terms 3.3.1 Channel Capacity Definition: The maximum forwarding rate [2] at which none of thesame egress interface, and have some common network layer content. Microflows [3]offered packets area subsetdropped by the DUT/SUT. Discussion: Channel capacity measures the packet rate at the egress interface(s) offlows. As defined in [3], microflows require application-to-application measurement.the DUT/SUT. In contrast,flows use lower-layer classification criteria. Since this document focuses on network-layer classification criteria, we concentrate herethroughput as defined in RFC 1242 measures the packet rate is based on theuseingress interface(s) ofnetwork-layer identifiers in describing a flow. Flow identifiers also may reside atthedata-link, transport, or application layersDUT/SUT. Ingress-based measurements do not account for congestion of theISO model. However, identifiers otherDUT/SUT. Channel capacity, as an egress measurement, does take congestion into account. Understanding channel capacity is a necessary precursor to any measurement involving congestion. Throughput numbers can be higher thanthosechannel capacity because of queueing. This measurement differs from forwarding rate atthe network layer are outmaximum offered load (FRMOL) [2] in that it is intolerant ofscope for this document.loss. Measurement units: N-octet packets per second Issues: See Also: Throughput [1] Forwarding Rate at Maximum Offered Load [2] 3.3.2 Conforming Definition: Packets which lie within specific rate, delay, or jitter bounds. Discussion: AflowDUT/SUT maycontainbe configured to allow asingle code point/IP precedence value or may contain multiple values destined forgiven traffic class to consume asingle egress interface. This is determined bygiven amount of bandwidth, or to fall within Network-layer Traffic Control Mechanisms predefined delay or jitter boundaries. All packets that lie within specified bounds are then said to be conforming, whereas those outside thetest methodology.bounds are nonconforming. Measurement units: n/a Issues: See Also:Microflow [3] Network-layer Traffic Control Mechanisms Streams 3.10Expected Vector Forwarding Vector Offered Vector Nonconforming 3.3.3 Nonconforming Definition:The number of packets per second for all packets containing a single DSCP (or IP precedence)Packets thata device cando not lie within specific rate, delay, or jitter bounds. Discussion: A DUT/SUT may beobserved to successfully transmitconfigured tothe correct destination interface in responseallow a given traffic class toan offered vector. Discussion: Forwarding Vector is expressed as pairconsume a given amount ofnumbers. Both the codepoint (or IP precedence) value AND the packets per second value combinebandwidth, or tomake a vector. The forwarding vector represents packet rate based on their codepointfall within predefined delay orIP precedence value. It isjitter boundaries. All packets that do notnecessary based on stream or flow. The forwarding vector maylie within these bounds are then said to beexpresses as ôper portö or ôof the DUT/SUTö.nonconforming. Measurement units: n/a Issues: See Also: Expected Vector Forwarding Vectoris a per-hop measurement.Offered Vector Conforming 3.3.4 Delay Definition: The time interval starting when the last bit of the input IP packets reaches the input port of the DUT/SUTmay changeand ending when thecodepoint orlast bit of the output IPprecedence value for a multiple-hop measurement. Measurement units: N-octetpacketsper second Issues: See Also: Codepoint Set Expected Vector Offered Vector. 3.11 Jitter Definition: Variation in a stream's delay. Discussion: Jitteris seen on theabsolute valueoutput port of thedifference betweenDUT/SUT. Discussion: Network-layer Traffic Control Mechanisms Delay is measured thedelay measurementsame regardless oftwo packets belonging tothesame stream.type of DUT/SUT. Latency [1] require some knowledge of whether the DUT/SUT is a "store and forward" or a "bit forwarding" device. Thejitter between two consecutive packets infact that astream is reported asDUT/SUT's technology has a lower delay than another technology should be visible. By specifying the"instantaneous jitter". Instantaneous jitter canmetric to beexpressed as |D(i) û D(i+1)| where D equalsinside thedelay and iInternet protocol, the tester is relieved from specifying thetest sequence number. Packets loststart/end for every data link layer protocol that IP runs on. This avoids determining if the start/end delimiter arenot countedincluded in thejitter measurement. Network-layer Traffic Control Mechanisms Average Jitter is the average offrame. Also heterogeneous data link protocol can be used in a test. The measurement point at theinstantaneous jitter measured duringend is closely simulates thetest duration. Peak-to-peak jitterway an internet datagram is processed. An internet datagram is not passed up or down themaximum delay minusstack unless it is complete. Completion occurs once theminimum delaylast bit of thepackets forwarded byIP packet has been received. Delay can be run at any offered load. Recommend at or below theDUT/SUT. Measurement units: Seconds (instantaneous) Seconds P-P (peak to peak) Seconds avg (average)channel capacity for non-congested delay. For congested delay, run the offered load above the channel capacity. Measurement units: Seconds. Issues:Mean Standard Deviation Median 90th percentile Inter Quartile RangeSee Also:Stream 3.12 NonconformingLatency [1] 3.3.5 Flow Definition:Packets that lie outside the parameter boundsA flow is a one or more of packets sharing agiven traffic profile.common intended pair of source and destination interfaces. Discussion:Rules may be configured forPackets are grouped by the ingress and egress interfaces they use on a giventraffic class based on parameters, such as an upper bound on the rate of packet arrivals.DUT/SUT. A flow can contain multiple source IP addresses and/or destination IP addresses. All packetsthat lie outsidein a flow must enter on thebounds specified bysame ingress interface and exit on thetraffic profile, measured oversame egress interface, and have some common network layer content. Microflows [3] are aperiodsubset oftime specifiedflows. As defined inthe traffic profile, are said to be nonconforming. Measurement units: n/a Issues: See Also: Conforming 3.13 Offered Vector Definition:[3], microflows require application-to-application measurement. In contrast, flows use lower-layer classification criteria. Since this document focuses on network-layer classification Network-layer Traffic Control MechanismsA vector describingcriteria, we concentrate here on therate at which packets havinguse of network-layer identifiers in describing aspecific code-point are offered toflow. Flow identifiers also may reside at theDUT/SUT. Discussion: Offered loads acrossdata-link, transport, or application layers of thedifferent code-point classes, constituting a code-point set, determineISO model. However, identifiers other than those at themetrics associated withnetwork layer are out of scope for this document. A flow may contain aspecific code-point traffic class.single code point/IP precedence value or may contain multiple values destined for a single egress interface. This is determined by the test methodology. MeasurementUnits: N-octets packets per secondunits: n/a Issues:Packet size.See Also:Expected Vector Forwarding Vector Codepoint Set 3.14Microflow [3] Streams 3.3.6 Stream Definition: A group of packets tracked as a single entity by the traffic receiver. A streamsharesmay share a common content such as type (IP, UDP),framepacket size, or payload. Discussion: Streams are tracked by"sequence number"Test sequence number or "unique signature field" (RFC 2889). Streams define how individual packet's statistics are grouped together to form an intelligible summary. Common stream groupings would be by egress interface, destination address, source address, DSCP, or IP precedence. A stream using Test sequence numbers can track the ordering of packets as they transverse the DUT/SUT. Streams are not restricted to a pair of source and destination interfaces as long as all packets are tracked as a single entity. A mulitcast stream can be forward to multiple destination interfaces. Measurement units: n/a Issues: Network-layer Traffic Control Mechanisms See Also: Flow MicroFlow [3]Network-layer Traffic Control MechanismsTest sequence number3.15 Tail dropping Definition: The condition in which a congested DUT/SUT discards newly arriving packets. Discussion: Every DUT/SUT has a finite amount of traffic it can forward, beyond which congestion occurs. Once the offered load crosses the congestion threshold, the device may discard any additional traffic that arrives until congestion clears. Tail dropping is typically a function of offered load exceeding a DUT/SUTÆs buffer capacity, but other factors internal to the DUT/SUT may also come into play. In terms of what is externally observable, tail dropping can be said to occur only when offered load exceeds channel capacity. Since a DUT/SUT may buffer traffic on ingress, the actual threshold for tail dropping may be higher than channel capacity. Measurement units: n/a Issues: Some congestion management mechanisms seek to avoid tail dropping by discarding packets before offered load exceeds channel capacity. In the presence of such mechanisms, neither congestion nor tail dropping should occur. See Also: Channel capacity Congestion 3.163.3.7 Test Sequence number Definition: A field in the IP payload portion of the packet that is used to verify the order of the packets on the egress of the DUT/SUT. Discussion: The traffic generator sets the Test sequence number value and the traffic receiver checks the value upon receipt of the packet. The traffic generator changes the value on each packet transmitted based on an algorithm agreed to by the traffic receiver.Network-layer Traffic Control MechanismsThe traffic receiver keeps track of the sequence numbers on a per stream basis. In addition to number of received packets, the traffic receiver may also report number of in-sequence packets, number of out-sequencepackets andpackets, number of duplicate packets, and number of reordered packets. The recommended algorithm to use to change the sequence number on sequential packets is an incrementing value. Measurement units: n/a Issues: See Also: Stream3.17 Unburdened3.3.8 Undifferentiated Response Definition:A performance measureThe vector(s) obtained when mechanisms used to support diff- serv or IP precedenceand DiffServare disabled. Discussion: EnablingDiffservdiff-serv or IP precedence mechanismssuch as scheduling algorithmsmay imposeanadditional processing overhead forpackets, whichpackets. This overhead maycause the aggregate response to sufferdegrade performance even when traffic belonging to only one class, thebest effortbest-effort class, is offered to the device.ComparisonsNetwork-layer Traffic Control Mechanisms Measurements with"unburdened performance" may thus"undifferentiated response" should bein order when obtaining metricsmade toensure that enabling Diffserv mechanisms doesn't impose an excessive performance penalty.establish a baseline. The vector(s) obtained with DSCPs or IP precedence enabled can be compared to the undifferentiated response to determine the effect of differentiating traffic. Measurement units: n/a 4. Security Considerations Documents of this type do not directlyeffectaffect the security of the Internet or of corporate networks as long as benchmarking is not performed on devices or systems connected to operating networks. Packets with unintended and/or unauthorized DSCP or IP precedence values may present security issues. Determining the security consequences of such packets is out of scope for this document. 5. References [1] Bradner, S., Editor, "Benchmarking Terminology for NetworkNetwork-layer Traffic Control MechanismsInterconnection Devices", RFC 1242, July 1991. [2] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998. [3] K. Nichols, S. Blake, F. Baker, D. Black,"Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Network-layer Traffic Control Mechanisms 6.Author'sAuthors' Address Jerry Perser Spirent Communications 26750 Agoura Road Calabasas, CA 91302 USA Phone: + 1 818 676 2300 EMail: jerry.perser@spirentcom.com David Newman Network Test 31324 Via Colinas, Suite 113 Westlake Village, CA 91362 USA Phone: + 1 818 889 0011, x10 EMail: dnewman@networktest.com Sumit Khurana Telcordia Technologies 445 South Street Morristown, NJ 07960 USA Phone: + 1 973 829 3170 EMail: sumit@research.telcordia.com Shobha ErramilliTelcordia Technologies 331 Newman Springs Road, Navesink,QNetworx Inc 1119 Campus Drive West Morganville NJ0770107751 USANetwork-layer Traffic Control MechanismsPhone:+ 1 732 758 5508EMail:shobha@research.telcordia.comshobha@qnetworx.com Scott Poretsky Avici Systems 101 BillericaAveùBuildingAve_Building #6 N. Billerica, MA 01862 USA Phone: + 1 978 964 2287 EMail: sporetsky@avici.com Network-layer Traffic Control Mechanisms 7. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.