Power Consumption Profiling for Programmable Network Devices
draft-pythia-bmwg-programmable-power-profiling-00

Benchmarking Methodology Working Group                           X. Chen
Internet-Draft                                                    L. Zhu
Intended status: Informational                                  L. Zheng
Expires: 28 January 2027                             Zhejiang University
                                                            27 July 2026

      Power Consumption Profiling for Programmable Network Devices
           draft-pythia-bmwg-programmable-power-profiling-00

Abstract

   A programmable network device can execute different packet-processing
   programs on the same hardware.  Device-level power measurements show
   the total input power but do not explain the power associated with a
   program's parser, match-action tables, and stateful or stateless
   actions.  Models designed for fixed-function switches do not directly
   describe these program-dependent operations.

   This document describes a power profiling methodology for
   programmable network devices.  The methodology decomposes packet
   processing into functional components, uses controlled calibration
   programs to derive target-specific parameters, and estimates the
   power of a data-plane program from its processing features and
   traffic.  It also specifies validation and reporting requirements
   that distinguish direct measurements from model-derived estimates.
   The methodology is based on implementation experience with an ASIC
   programmable switch and an FPGA-based programmable switch.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on 28 January 2027.

Chen, et al.             Expires 28 January 2027                [Page 1]
Internet-Draft        Programmable Power Profiling             July 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . .   3
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Profiling Framework . . . . . . . . . . . . . . . . . . . . .   4
   6.  Functional Power Model  . . . . . . . . . . . . . . . . . . .   5
     6.1.  Basic Power . . . . . . . . . . . . . . . . . . . . . . .   5
     6.2.  Packet-Processing Power . . . . . . . . . . . . . . . . .   6
     6.3.  Traffic, Packet Size, and Repeated Processing . . . . . .   6
   7.  Parameter Profiling and Calibration . . . . . . . . . . . . .   7
     7.1.  Calibration Program Design  . . . . . . . . . . . . . . .   7
     7.2.  Power Data Collection . . . . . . . . . . . . . . . . . .   7
     7.3.  Parameter Derivation  . . . . . . . . . . . . . . . . . .   8
   8.  Program Profiling and Power Estimation  . . . . . . . . . . .   8
   9.  Model Validation  . . . . . . . . . . . . . . . . . . . . . .   9
   10. Comparing Data-Plane Programs . . . . . . . . . . . . . . . .   9
   11. From One Device to a Network  . . . . . . . . . . . . . . . .  10
   12. Reporting Summary . . . . . . . . . . . . . . . . . . . . . .  10
   13. Implementation Experience . . . . . . . . . . . . . . . . . .  11
   14. Applicability and Limitations . . . . . . . . . . . . . . . .  12
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   17. Normative References  . . . . . . . . . . . . . . . . . . . .  12
   18. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Chen, et al.             Expires 28 January 2027                [Page 2]
Internet-Draft        Programmable Power Profiling             July 2026

1.  Introduction

   In-network computing moves functions such as aggregation,
   measurement, caching, classification, and security processing into
   programmable network devices.  The power used by these functions is
   relevant when selecting a program, comparing program versions, or
   estimating the power cost of deploying a function across many
   devices.

   An external power meter can measure the total input power of a
   device.  Repeating that measurement for every program and
   configuration is costly, and a total value does not identify which
   packet-processing operations account for a difference.  Existing
   models for fixed-function switches commonly use external variables
   such as port configuration and traffic load.  Those variables remain
   important, but they do not describe custom parsing, matching, and
   action logic.

   This document describes a component-oriented profiling methodology.
   It first builds a general functional model of programmable packet
   processing.  It then uses controlled calibration programs and power
   data to derive parameters for a specific target.  Once calibrated and
   validated, the target-specific model can estimate the power of other
   programs within the validated range.

   The methodology does not standardize one device's parameters or
   require disclosure of proprietary pipeline placement.  It
   standardizes the functional decomposition, calibration process,
   validation conditions, and information needed to interpret a result.

2.  Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Scope and Non-Goals

   This document applies to devices whose packet-processing behavior is
   defined in whole or in part by a loadable or compiled data-plane
   program.  The primary model is a reconfigurable match-action pipeline
   [RMT], but the procedure can be adapted to another architecture when
   its processing functions can be mapped to the components in
   Section 6.

   The methodology supports:

Chen, et al.             Expires 28 January 2027                [Page 3]
Internet-Draft        Programmable Power Profiling             July 2026

   *  profiling one program on one target;

   *  comparing programs or program versions on the same target;

   *  identifying packet-processing features associated with a power
      difference; and

   *  estimating program-level power after target-specific calibration.

   This document does not prescribe an energy-efficiency target, an
   acceptance threshold, a data-plane language, a compiler, or a single
   regression model.  It does not assert that parameters obtained from
   one device, compiler, or firmware version apply to another.  It also
   does not replace a direct measurement when a benchmark requires
   directly measured input power.

4.  Terminology

   Target:  The programmable device, architecture, and toolchain
      combination for which a power model is calibrated.

   Data-plane program:  The source, intermediate, or compiled artifact
      that defines the packet-processing behavior loaded on the target.

   Calibration program:  A controlled data-plane program constructed to
      expose the power behavior of one processing component or candidate
      factor.

   Reference program:  A documented program that provides the baseline
      packet-processing behavior for a calibration or comparison.

   Direct measurement:  A power value measured for the target under the
      stated program and traffic condition using an external power
      meter.

   Tool-derived power value:  A power value produced by an
      implementation or design tool, such as an FPGA post-implementation
      power report, rather than by an external meter.

   Model-derived estimate:  A value calculated by a calibrated power
      model for a program and traffic condition.

5.  Profiling Framework

   The profiling workflow has three stages:

   1.  Construct a general functional power model by decomposing the
       target's packet-processing path.

Chen, et al.             Expires 28 January 2027                [Page 4]
Internet-Draft        Programmable Power Profiling             July 2026

   2.  Run calibration programs, collect power data, identify
       influential factors, and derive parameters for the target.

   3.  Extract the corresponding features of a query program and use the
       target-specific model to estimate its power.

   The first stage is architecture-oriented.  It identifies functions
   that are common across a class of programmable devices.  The second
   stage is device-specific because the contribution of a function
   depends on the hardware, compiler, firmware, and implementation.  The
   third stage is valid only inside the range covered by calibration and
   validation.

   Calibration requires power data for a limited set of programs.  A
   query does not require a new direct measurement unless the estimate
   is being validated or the program lies outside the validated range.
   This distinction is the source of the method's lower measurement
   cost, but it also makes accurate reporting of the model boundary
   necessary.

6.  Functional Power Model

   The total power of a target under a program and traffic condition is
   represented as:

                P_total = P_basic + P_operation

   P_basic represents the power needed for the device's basic operation.
   P_operation represents the additional packet-processing activity of
   the loaded program.  This is a functional decomposition.  It does not
   imply that the physical hardware blocks are isolated or that every
   term is independently additive.

6.1.  Basic Power

   Basic power can be decomposed as:

                P_basic = P_idle + P_port + P_forwarding

   P_idle is the target's baseline power after startup.  P_port
   represents the contribution associated with connected and enabled
   ports.  P_forwarding represents basic packet forwarding under the
   stated traffic condition.  The report MUST identify the chassis,
   enabled and connected ports, interface types, and basic forwarding
   program used to derive these terms.

Chen, et al.             Expires 28 January 2027                [Page 5]
Internet-Draft        Programmable Power Profiling             July 2026

6.2.  Packet-Processing Power

   For a match-action pipeline, operational power is organized as:

                P_operation = P_parser + P_match + P_action

   P_parser includes parsing and deparsing.  Candidate explanatory
   variables include parsed header widths, the number and sequence of
   headers, and packet rate.

   P_match represents the execution of match-action tables.  Candidate
   variables include match kind, key fields or key width, configured
   rule capacity, populated rule count, number of tables, and packet
   rate.

   P_action represents operations executed after a match.  The model
   distinguishes stateful operations, such as register access, from
   stateless operations, such as field assignment or arithmetic.
   Candidate variables include operation category, operation count,
   operand width, number of tables executing the operation, and packet
   rate.

   A calibration experiment MUST determine which candidate factors have
   a measurable effect on its target.  A factor MUST NOT be retained in
   the target-specific model solely because it appears in the general
   functional model.

6.3.  Traffic, Packet Size, and Repeated Processing

   Packet-processing work depends on the number of packets as well as
   the number of bits.  A profile MUST report both packet rate and bit
   rate, together with the packet-size distribution.  At a fixed bit
   rate, smaller packets increase the packet rate and can therefore
   increase the number of parser, table, and action executions.

   Recirculation causes a packet to traverse the pipeline again.  If
   each recirculated pass performs processing equivalent to an external
   packet, an effective packet rate can be expressed as:

                r_effective = r_external * (1 + k)

   Here, k is the number of recirculations per packet or a traffic-
   weighted average when packets have different recirculation counts.
   If later passes execute a different path, the passes MUST be
   described separately rather than represented only by r_effective.
   Resubmit, cloning, and multicast SHOULD be reported when they change
   the amount of packet processing.

Chen, et al.             Expires 28 January 2027                [Page 6]
Internet-Draft        Programmable Power Profiling             July 2026

7.  Parameter Profiling and Calibration

7.1.  Calibration Program Design

   A calibration program SHOULD isolate one candidate factor while
   holding unrelated factors constant.  A calibration set begins with a
   reference program and adds a series of programs or configurations
   that vary a controlled parameter.

   Examples include varying:

   *  connected and enabled ports;

   *  packet rate at fixed packet size and processing behavior;

   *  parsed header width or header count;

   *  match kind, rule count, or table count;

   *  stateful reads and writes;

   *  stateless assignment or arithmetic operations; and

   *  the number of recirculations or processing passes.

   A generated program MUST be checked to confirm that the compiler did
   not remove the operation under test.  The report SHOULD record
   compiler resource output when it is available.  If varying one source
   construct changes placement or other resources, that interaction MUST
   be reported.

7.2.  Power Data Collection

   For a deployed hardware target, each calibration point MUST use an
   external power meter.  The report MUST state the meter type and
   accuracy, target and toolchain versions, environmental condition,
   stabilization interval, measurement interval, averaging method, and
   number of repetitions.

   For a target that is not available as a measurable hardware
   implementation, a design-tool power report MAY be used for model
   development.  Such a value MUST be labeled tool-derived and MUST NOT
   be presented as an external input-power measurement.

Chen, et al.             Expires 28 January 2027                [Page 7]
Internet-Draft        Programmable Power Profiling             July 2026

   The calibration program, port state, table population, state
   initialization, traffic, and any control-plane updates during the
   measurement MUST be recorded.  The packet-processing result SHOULD be
   checked so that a low-power value caused by unintended drops or a
   failed program is not accepted as a valid calibration point.

7.3.  Parameter Derivation

   For each candidate factor, the profiler compares the power values
   obtained while that factor is varied.  A target-specific relationship
   can be linear, range-based, logarithmic, or another form supported by
   the calibration data.  This document does not prescribe the fitting
   method.

   When a factor produces no stable measurable difference over the
   calibrated range, the target-specific model SHOULD omit that factor
   or represent it as an uncertainty term.  When the effect of two
   factors cannot be separated, the model SHOULD use a joint term rather
   than claiming independent component contributions.

   Every parameter set MUST be versioned and bound to the target,
   toolchain, calibration programs, traffic range, and measurement or
   tool-derived power-data source used to obtain it.

8.  Program Profiling and Power Estimation

   To profile a query program, the profiler extracts the program
   features used by the target-specific model.  These features can come
   from program analysis, compiler output, run-time configuration, or a
   combination of them.

   The query record MUST include:

   *  program identifier and version;

   *  compiler, target, options, SDK, firmware, and runtime versions;

   *  parser, match-table, stateful-action, and stateless-action
      features required by the model;

   *  configured and populated table state;

   *  packet rate, bit rate, packet-size distribution, and repeated
      processing; and

   *  the parameter-set version used for the estimate.

Chen, et al.             Expires 28 January 2027                [Page 8]
Internet-Draft        Programmable Power Profiling             July 2026

   The estimated total power MUST be labeled model-derived.  A profiler
   MAY additionally report a basic-power term and operational terms, but
   it MUST state whether those terms are measured, independently
   calibrated, or inferred from a combined model.

   If the query program contains a feature or traffic condition outside
   the calibration range, the result MUST be labeled an extrapolation.
   A new calibration or direct measurement is RECOMMENDED instead of
   extrapolation when the omitted feature can activate a different
   hardware resource or execution path.

9.  Model Validation

   A target-specific model MUST be validated using programs or
   configurations that were not used to derive its parameters.
   Validation programs SHOULD cover different combinations of parser,
   table, register, action, and traffic features within the intended
   operating range.

   The validation report MUST provide:

   *  the calibration and validation program sets;

   *  the directly measured or tool-derived value and the estimate for
      each validation case;

   *  the error definition;

   *  a central error value and the worst observed error;

   *  the validated ranges for traffic and program features; and

   *  known interactions or target limitations.

   A model MUST be revalidated after a change to the hardware target,
   compiler behavior, firmware, or another part of the toolchain that
   can alter pipeline mapping or power behavior.

10.  Comparing Data-Plane Programs

   Two programs can be compared directly on the same target by keeping
   the chassis, ports, toolchain, environment, traffic, table state,
   stabilization interval, and measurement method unchanged.  If P_A and
   P_B are direct power measurements, the program-associated difference
   is:

                Delta_P(A,B) = P_B - P_A

Chen, et al.             Expires 28 January 2027                [Page 9]
Internet-Draft        Programmable Power Profiling             July 2026

   The report MUST include P_A and P_B as well as Delta_P(A,B).  If the
   programs implement different functions or produce different
   forwarding results, the report MUST describe the difference and MUST
   NOT present Delta_P(A,B) as an efficiency comparison for equivalent
   behavior.

   A component model can help explain the difference, but a model-
   derived attribution MUST be reported separately from the direct
   difference.

11.  From One Device to a Network

   For a single device, the program and the local traffic condition are
   sufficient inputs to a target-specific model.  For a network of
   programmable devices, traffic distribution and forwarding paths also
   affect power because they determine the packet rate processed by each
   device.

   A network-level estimate MUST identify the program and traffic rate
   at each device.  It MUST also state whether links, transceivers, and
   other devices outside the programmable targets are included.
   Applying one device's model to every device is valid only when their
   targets, toolchains, configurations, and validated operating ranges
   are equivalent.

   This document does not specify a routing or traffic-engineering
   algorithm.  It only records that network-level profiling requires the
   traffic distribution and forwarding strategy in addition to the per-
   device program model.

12.  Reporting Summary

             +============+==================================+
             | Group      | Required information             |
             +============+==================================+
             | Target     | Device, architecture, compiler,  |
             |            | SDK, firmware, runtime           |
             +------------+----------------------------------+
             | Program    | Identifier, version, function,   |
             |            | compiled artifact                |
             +------------+----------------------------------+
             | Basic      | Idle state, ports, interfaces,   |
             | state      | basic forwarding                 |
             +------------+----------------------------------+
             | Parser     | Headers, widths, count or depth  |
             |            | used by the model                |
             +------------+----------------------------------+
             | Match      | Match kinds, keys, rules,        |

Chen, et al.             Expires 28 January 2027               [Page 10]
Internet-Draft        Programmable Power Profiling             July 2026

             |            | tables, populated state          |
             +------------+----------------------------------+
             | Action     | Stateful and stateless           |
             |            | operations used by the model     |
             +------------+----------------------------------+
             | Traffic    | Packet rate, bit rate, sizes,    |
             |            | recirculation or other passes    |
             +------------+----------------------------------+
             | Power data | Direct measurement or tool-      |
             |            | derived source and procedure     |
             +------------+----------------------------------+
             | Model      | Parameter version, calibration   |
             |            | set and range                    |
             +------------+----------------------------------+
             | Validation | Cases, measured or tool-derived  |
             |            | values, estimates, errors        |
             +------------+----------------------------------+
             | Result     | Direct, tool-derived, estimated, |
             |            | or extrapolated label            |
             +------------+----------------------------------+

                      Table 1: Power Profiling Report

13.  Implementation Experience

   The methodology is based on an implementation named Pythia.  Pythia
   constructs an RMT-oriented power model and uses calibration programs
   to derive parameters for a target.

   On an Intel Tofino programmable switch, Pythia used an external
   wattmeter for calibration.  It examined the effects of port state,
   basic forwarding, parser configuration, match-action tables, stateful
   and stateless actions, traffic rate, packet size, and recirculation.
   In that implementation, packet rate was the dominant run-time factor;
   several program-structure factors had only a small measurable effect
   on the evaluated target.

   The Tofino model was evaluated with 14 real-world data-plane programs
   covering different numbers of headers, match-action tables,
   registers, and action executions.  For those experiments, the power
   range estimated by the model was reported to be within five percent
   of the direct measurement.

   Pythia was also adapted to an FPGA-based programmable switch.  That
   evaluation focused on matching because of the available
   implementation resources and considered match kind, rule count, and
   table count.  Its power values came from post-implementation reports
   generated by the FPGA design tool, not from an external power meter.

Chen, et al.             Expires 28 January 2027               [Page 11]
Internet-Draft        Programmable Power Profiling             July 2026

   These results support the feasibility of target-specific, component-
   oriented profiling.  They do not establish a universal model form or
   accuracy guarantee.  In particular, the Tofino findings about traffic
   rate and the FPGA findings about matching MUST NOT be assumed for
   another target without calibration and validation.

14.  Applicability and Limitations

   The functional model maps directly to RMT-like pipelines.  A non-RMT
   target requires a justified mapping between its execution model and
   the components in Section 6.  If such a mapping is not available, the
   profiler SHOULD define a target-specific decomposition rather than
   forcing the target into parser, match, and action terms.

   Compiler placement, shared resources, standby power, memory
   technology, clocking, and thermal control can hide or couple
   component effects.  A functional term is therefore an explanatory
   model term, not necessarily the power of a physically isolated block.

   A model can reduce repeated measurement cost only after the target
   has been calibrated.  It does not eliminate the need for direct
   measurements during calibration and validation, and it does not make
   unlike targets automatically comparable.

15.  Security Considerations

   Profiling SHOULD be performed in an isolated laboratory environment.
   Calibration programs can exhaust table or stateful memory, create
   high packet-processing load, or introduce a recirculation loop.  A
   tester SHOULD validate each program at a limited rate before applying
   the full traffic condition and SHOULD retain a way to stop traffic or
   unload the program.

   Program source, compiler output, resource reports, and pipeline
   placement can contain proprietary information.  A report MAY use
   coarse feature categories, but it MUST state which information is
   withheld so that readers can assess the limit on reproducibility.

16.  IANA Considerations

   This document has no IANA actions.

17.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

Chen, et al.             Expires 28 January 2027               [Page 12]
Internet-Draft        Programmable Power Profiling             July 2026

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

18.  Informative References

   [RMT]      Bosshart, P., Gibb, G., Kim, H., Varghese, G., McKeown,
              N., Izzard, M., Mujica, F., and M. Horowitz, "Forwarding
              Metamorphosis: Fast Programmable Match-Action Processing
              in Hardware for SDN", DOI 10.1145/2486001.2486011, August
              2013, <https://doi.org/10.1145/2486001.2486011>.

Authors' Addresses

   Xiang Chen
   Zhejiang University
   Hangzhou
   Zhejiang,
   China
   Email: wasdnsxchen@gmail.com

   Longlong Zhu
   Zhejiang University
   Hangzhou
   Zhejiang,
   China
   Email: pocofo@foxmail.com

   Linying Zheng
   Zhejiang University
   Hangzhou
   Zhejiang,
   China
   Email: zhenglinying0106@gmail.com

Chen, et al.             Expires 28 January 2027               [Page 13]