Characterization and Benchmarking Methodology for Power in Networking Devices

Energy efficiency is becoming increasingly important in the operation of network infrastructure. Network devices are typically always on, but in some cases, they run at very low average utilization rates. Both network utilization and energy consumption of these devices can be improved, and that starts with a normalized characterization . The benchmarking methodology defined here will help operators to get a more accurate idea of the power drawn by their network and will also help vendors to test the energy efficiency of their devices . There is no standard mechanism to benchmark the power utilization of networking devices like routers or switches. started to analyze the issue. This document focuses on the mechanism to correctly characterize and benchmark the energy consumption of networking devices to better estimate and compare their power usage in order to assess the performance over a set of well-defined scenario.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Benchmarking can be understood to serve three related but different objectives: Assessing "which system performs best" over a set of well-defined scenarios. Measuring the contribution of sub-systems to the overall system's performance (also known as "micro-benchmark"). Evaluating the evolution of a system's energy consumption profile against its own historical baseline to assess the impact of software updates, feature activation, or operational aging (also known as "longitudinal" or "self-referential" benchmarking). Achieving any of these objectives requires a well-defined set of principles prescribing what must be measured, how must be measured, and which results must be reported. Providing those principles is the objective of this draft. These are simply called "the benchmark" in the rest of this draft. The benchmark aims to compare the energy efficiency for individual devices (routers and switches belonging to similar device classes). In addition, it aims to showcase the effectiveness of various energy optimization techniques for a given device and load type, with the objective of fostering improvements in the energy efficiency of future generations of devices.

Replicability is defined as achieving the same results with newly collected data. Formally, it is a pre-requisite for benchmarking. Benchmark results are meant to be compared, and this comparison is not sound if the individual results are not replicable. As discussed later in this draft, replicability in power measurements is complex as power is affected by a wide range of parameters, some of which are hard to control e.g., the room temperature. Striving for "perfect" replicability would lead to prescribe extremely precisely all the power-impacting factors in the test setup. We argue that this is unrealistic and counter-productive. An overly prescriptive benchmark becomes more complicated to perform. Furthermore, results would then be comparable only across benchmark results obtained under the exact same test conditions, which becomes increasingly less likely as we prescribe more and more. Instead, the benchmark described in this draft proposes to report on a number of power-impacting factors, but does not enforce specific values or settings for those. The aim is to make the benchmark easier to perform. The comparison between benchmark results MAY be somewhat less accurate or fair than with a more prescriptive benchmark, but the hope is to have many more comparison points available, which would ultimately provide a more robust image of the devices power demands and their evolution over time. In short: this draft argues it is better to have many benchmark results with a higher uncertainty than a few very precise but hardly comparable ones.

The total weighted capacity of the interfaces (T) is the weighted sum of all interface throughputs. Definition: T = B1*T1 +...+ Bi*Ti +...+ Bm*Tm Discussion: Ti is the total capacity of the interfaces for a fixed configuration model and traffic load (the sum of the interface bandwidths) Bi is the weighted multiplier for different traffic levels (note that B1+...+Bj+...+Bm = 1, weight multipliers MAY be specified for router, switch differently, 3 typical weighted multipliers are 0.1,0.8,0.1) m is the number of traffic load levels (if it is considered 100%, 30%, 0%; m = 3) Note that traffic load levels MAY be specified differently for router and switch, e.g., traffic level 100%,10%,0% for access router, traffic level 100%,30%,0% for core router and data center switch. Measurement units:Gbps. Issues The traffic loads and the weighted multipliers need to be clearly established a priori. It is unclear if the definition of the Ti is/should be linked to the traffic load levels. For a given port configuration (which may result in 50% of the total capacity a device can provide), one may be interested in traffic load of e.g., 5% or 10% or the total capacity (not only 50%). See Also:, ,.

The total weighted power (P) is the weighted sum of all power calculated for different traffic loads. Definition: P = B1*P1 +...+ Bi*Pi +...+ Bm*Pm Discussion: Pi is the Power of the equipment in each traffic load level (e.g. 100%, 30%, 0%) Bi is the weighted multiplier for different traffic levels (note that B1+...+Bj+...+Bm = 1) m is the number of traffic load levels (if it is considered 100%, 30%, 0%; m = 3) Measurement units:Watt. Issues: The traffic loads and the weighted multipliers need to be clearly established a priori. Importantly, the traffic MUST be forwarded of the correct port! It would be easy to cut power down by dropping all traffic, and, naturally, we do not want that. A tolerance on packet loss and/or forwarding error must be specified somehow. That tolerance could be zero for some benchmark problems (e.g., Non-Drop Rate (NDR) estimation), and non-zero for others. Tolerating some errors may be interesting to navigate the design space of energy saving techniques, such as approximate computing/routing. According to measurement procedure in section 6.5 of , the Equipment Under Test (EUT) should be able to return to full NDR load. Failure to do so disqualifies the test results. See Also:, ,.

Energy Efficiency Ratio (EER) is defined as the throughput forwarded by 1 watt and it is introduced in . A higher EER corresponds to a better energy efficiency. Definition: EER = T/P Discussion: T is the total weighted sum of all interface throughputs P is the weighted power for different traffic loads Measurement units:Gbps/Watt. Issues: The traffic loads and the weighted multipliers need to be clearly established a priori. Optionally the total capacity of the interfaces (T) can be used in replacement of the total weighted capacity of the interfaces. The former is the sum of all interface throughputs and is not linked to traffic load levels. This result EER is a scaled value proportional to the EER using the total weighted capacity of the interfaces (T) See Also:, ,.

The total power (Ptot) is the power of the entire equipment, measured as the sum the power drawn by all of the equipment's power supply units. Definition: Ptot = Pu1 +...+ Pui +...+ Pun Discussion: Pui is the power that is drawn by one power supply unit of the equipment n is the number of power supply units Measurement units:Watt. Issues: The total power depends on many different factors, including the running configuration, the number and type of transceiver connected, the forward traffic volume and pattern, the version of the operating system, the room temperature and humidity/other environmental dimensions, the aging of parts, etc. This metric does not allow to compare two equipments against each over, but it MAY be enough to assess the effect of a change on the same equipment; e.g., for optimizing the power draw by changing the running configuration. Importantly, the traffic MUST be forwarded of the correct port! It would be easy to cut power down by dropping all traffic, and we of course do not want that. A tolerance on packet loss and/or forwarding error MUST be specified somehow. That tolerance could be zero for some benchmark problems, and non-zero for others. Tolerating some errors MAY be interesting to navigate the design space of energy saving techniques, such as approximate computing/routing.

The maximum power drawn by a device does not accurately reflect the power under a normal workload. Indeed, the energy consumption of a networking device depends on its configuration, connected transceivers, and traffic load. Relying merely on the maximum rated power can overestimate the total energy of the networking devices. A network device consists of many components, each of which draws power (for example, it is possible to mention the power draw of the CPU, data forwarding ASIC, memory, fan, etc.). Therefore, it is important to formulate a consistent benchmarking method for network devices and consider the workload variation and test conditions. Enforcing controlled conditions on test conditions (e.g., Temperature) is important for test procedure to make sure test conditions repeatable . The measurement condition reported in and SHOULD be applied, e.g., the power measurements SHALL be performed in a laboratory environment under specific range of temperature, humidity and atmosphere pressure.

The test setup in general is compliant with . The Device Under Test (DUT) is connected to a Tester and a Power Meter. The Power Meter allows measurement of the device's energy consumption and can be used to measure power under various configurations and conditions. Tests MUST be done by running one or several of the predefined traffic traces, which are crafted to test different power-intensive tasks related to packet processing. The Tester is also a traffic generator that enables changing traffic conditions. It is OPTIONAL to choose a non-equal proportion for upstream and downstream traffic.

| |-------+ | +------->| DUT |---------+ | | +--------+ | | +----------+ | Power | | Meter | +----------+ ]]> It is worth mentioning that the DUT also dissipates significant heat. A part of the power is used for actual work while the rest is dissipated as heat. This heating can lead to more power drawn by fans/compressor for cooling the devices. The benchmarking methodology does not measure the power drawn by external cooling infrastructure. The Power Meter only measures the internal energy consumption of the device. Anyway, the device's temperature change MUST be known. It is useful to know whether device's heat management plays a role in the observed differences in energy efficiency and can be correlated to the amount of external power drawn to cool the device.

The traffic load supported by a device affects its energy consumption. Therefore, the benchmark MUST include different traffic loads. The traffic load MUST specify packet sizes, packet rates, and inter-packet delays, as all MAY affect the energy consumption of network devices . To enable replicable and comparable results, the benchmark can specify a set of well-defined traffic traces that MUST be used. There are different interface types on a network device and the power usage also depends on the kind of connector/transceiver used. The interface type used MUST also be specified. Power measurements SHOULD be performed only after the DUT and the applied traffic condition have reached a stable operating state. Stability in this context refers to the absence of transient effects associated with traffic changes, configuration updates, or device thermal and cooling behavior. The stabilization interval, defined as the time between applying a traffic load or configuration and the start of power measurement, MUST be reported. The measurement interval, defined as the averaging window over which input power is recorded, and the averaging method used MUST also be reported. This methodology does not mandate specific durations for stabilization or measurement intervals, as these MAY depend on device class, implementation, and test environment; however, reporting these intervals is required to support comparability of results.

The benchmark focuses on data that is either controllable (e.g., the number of active ports) or that can be externally measured (e.g., the total power). Factors that are not measurable externally (e.g., CPU load, PSU efficiency) are intentionally left out.
For the benchmarking tests, it MUST be specified.
For each test the total number of line cards and their types can be varied and MUST be specified.
For each test the number of enabled and disabled ports MUST be specified.
For each test the number of active and inactive ports MUST be specified.
For each test the port configuration and settings need to be specified.
For each test the port utilization of each port MUST be specified. The actual traffic load can use the information defined in . To characterize power consumption under realistic traffic conditions, the actual traffic load can use variable packet size distributions as specified in .
For each test, the traffic trace used (amongst those prescribed by the benchmark) MUST be specified.
For each test it MUST be specified. All power measurements are done in Watts.
For each power measurement, the stabilization interval and the measurement interval (averaging window) MUST be reported. The stabilization interval is the time between applying a traffic load or configuration and the start of power measurement. The measurement interval and the averaging method used to obtain the reported power value MUST also be specified. If these intervals differ by load level, the values per load level MUST be reported.

Objective:To determine the DUT throughput according to . And to characterize throughput under realistic traffic patterns using variable packet size distributions as specified in . Procedure:The test is done using a multi-port setup as specified in Section 16 and Section 26.1 of . To assess throughput under realistic Internet traffic conditions, the test is performed using the IMIX Genome packet size distributions specified in . Reporting format:The results of the throughput SHOULD be reported according to .

Objective:To determine the base power drawn by the network device in its factory settings. Procedure:The measurement is done with the device in its factory settings, after it finished booting, and without any transceiver plugged in. Reporting format:The results of the power measurement SHOULD be reported according to . Note:This measurement is useful to assess the energy efficiency of default settings.

Objective:To determine the power drawn by the network device in normal operation but without forwarding traffic. Procedure: The measurement is done with the device fully configured to forward traffic but without any traffic actually present. All interfaces MUST be up. Control-plane, management-plane, and background system functions MAY remain active during this measurement unless explicitly disabled for the purpose of the test. Examples include routing protocol adjacencies, control signaling, telemetry processes, and thermal management mechanisms. The operational state of these functions during the measurement MUST be reported, as they can influence the observed power consumption. Reporting format:The results of the power measurement SHOULD be reported according to . Note:This measurement is useful to assess the energy used to activate the internal components used by the device to forward traffic. It also captures the efficiency of the device at activating some "low-power mode" when there is no traffic to forward.

Objective:To determine the power drawn by the network device in normal operation with very small but non-zero traffic to forward. Procedure: The measurement is done with the device fully configured and the "minimum" traffic trace. Control-plane, management-plane, and background system functions MAY remain active during this measurement unless explicitly disabled for the purpose of the test. Examples include routing protocol adjacencies, control signaling, telemetry processes, and thermal management mechanisms. The operational state of these functions during the measurement MUST be reported, as they can influence the observed power consumption. Reporting format:The results of the power measurement SHOULD be reported according to . Note:The "minimum" traffic trace creates a bidirectional flow of 1 pps on all active interfaces. By comparison with the "Idle Power" measurement, this measurement captures the power cost of taking the device out of its "low-power mode."

Objective:To determine the power drawn by a device. The dynamic power, which is added to the idle+ power, SHOULD be proportional to its traffic load. Procedure: A specific number of packets at a specific rate is sent to specific ports/linecards of the DUT. All DUT ports must operate under a specific traffic load, which is a percentage of the maximum throughput. Power SHOULD be recorded only after the DUT and the offered load have reached a stable operating state. The stabilization interval and the measurement interval MUST be reported as described in . Reporting format:The results of the power measurement SHOULD be reported according to .

Objective:To determine the energy efficiency of the DUT. Procedure: Collect the data for all the traffic loads and apply the formula of . For example, with all DUT ports operating stably under a percentage of the maximum throughput (e.g. 100%, 30%, 0%), record the average input power and calculate the total weighted power P and then the EER. The stabilization interval and measurement interval used to obtain the recorded average input power MUST be reported as described in . Reporting format:The results of the energy efficiency ratio SHOULD be reported according to .

The benchmarking characterization described in this document is constrained to a controlled environment (as a laboratory) and includes controlled stimuli. The network under benchmarking MUST NOT be connected to production networks. Beyond these, there are no specific security considerations within the scope of this document.

This document has no IANA actions.

We wish to thank the authors of for their analysis and start on this topic.