Sketch-INT Co-Design for Accurate Network Measurement: Applicability to Time-Variant Non-Terrestrial Networks

Introduction Network measurement collects traffic statistics, such as per-flow packet counts and per-hop metadata, from network devices. These data support applications including heavy-hitter detection, superspreader detection, flow-size distribution estimation, microburst detection, and congestion control. Both large and small flows matter. Volumetric applications often make decisions about large flows, while distribution estimation and troubleshooting applications can depend on accurate observations of small flows. A single measurement mechanism does not necessarily provide the best accuracy-resource trade-off for both populations. Sketches maintain approximate flow statistics in compact counter arrays. They are resource-efficient for large flows, but collisions can dominate the small counters associated with small flows. P4-based INT records selected metadata in packets and exports the observations at or after egress . Detailed per-packet observation improves small-flow visibility, but applying INT to all traffic can create substantial overhead. The framework described here exploits this complementarity. A flow is initially observed by both mechanisms. While it remains below a configured large-flow threshold, INT provides its detailed observations. After the sketch identifies it as a large flow, subsequent packets are measured by the sketch without INT. Under a skewed traffic distribution, most packets can therefore be handled by sketches while INT is reserved for the smaller packet population associated with small flows. The framework also addresses two deployment problems studied by the implementation that motivates this document: selecting measurement points when the exact paths of flows are not known, and collecting measurement data without congesting paths shared with normal traffic. These two problems are also relevant to time-variant NTNs. Links and adjacencies in satellite and integrated space-air-ground networks can change as a function of time, so a path model can be valid only for a particular topology state. On-board processing, inter-satellite links, and space-to-ground capacity can also limit where detailed telemetry is executed and how its reports are collected. TVR use cases describe the underlying time-dependent routing context . This document therefore treats an NTN as a concrete scenario for applying and evaluating the existing Sketch-INT co-design. It does not introduce schedule-aware measurement epochs, a satellite routing protocol, or a new report-reconciliation mechanism. The behavior described in the core framework remains the behavior implemented and evaluated in the motivating terrestrial system.

Scope and Non-Goals This document covers:

division of measurement work between sketches and INT according to flow size;
selection of programmable measurement points under incomplete routing knowledge;
estimation of the traffic generated by sketch dumps and INT reports;
selection of collection paths subject to link-load limits;
mapping of these mechanisms to a time-variant NTN evaluation scenario; and
implementation and result information needed for reproducible evaluation.

This document does not define a sketch data structure, large-flow threshold algorithm, INT packet format, INT metadata field, controller protocol, collection encapsulation, or routing protocol. It also does not require every device in a network to be programmable, and it does not define how a time-varying topology or contact schedule is distributed to measurement controllers. The data-plane realization that motivates this document uses programmable switches and P4-based INT. IOAM is a related IETF on-path telemetry mechanism, but P4 INT and IOAM are not treated as interchangeable in this document. Mapping the flow-selection and reporting behavior described here to a particular IOAM option and encapsulation requires separate specification and implementation work.

Terminology

Sketch:: A compact probabilistic data structure that maintains approximate traffic statistics. Count-Min Sketch and Count Sketch are examples .
In-band Network Telemetry (INT):: In this document, a programmable-data-plane mechanism that places selected measurement metadata in packets and makes the observations available to a collector.
Large Flow:: A flow whose sketch estimate has reached a configured large-flow threshold.
Small Flow:: A flow that has not reached the configured large-flow threshold.
Measurement Point:: A programmable device selected to execute a sketch, INT, or both.
Control-Plane Node:: A controller or server that receives measurement data and supports measurement applications.
OD Pair:: An origin-destination pair representing the ingress and egress associated with a flow.
Flow Coverage:: The fraction of the considered flows that can traverse at least one selected measurement point under the path model used by the selection algorithm.
Collection Window:: The interval after which a sketch is read or reset and its data are made available for collection.

Problem Statement

Sketch-Only Measurement Sketches provide bounded-memory measurement at line rate. For large flows, collision noise is often small relative to the measured count. For small flows, the same collision noise can be comparable to or larger than the true value. Increasing memory or using a more complex sketch can reduce error, but does not remove the accuracy-resource trade-off for all workloads and devices.

INT-Only Measurement INT can carry detailed information for an individual packet and the nodes it traverses. If INT is applied to every packet, however, its packet-size, processing, export-bandwidth, and collector costs grow with packet volume. Sampling or reducing metadata can lower these costs, but can also reduce the observations available for short or small flows.

Existing Sketch-INT Combinations Previous systems have combined sketches and INT in different ways. SketchINT constructs or transfers sketch information using INT data , while LightGuardian places compact sketch information in packets . These designs address different collection problems. The framework in this document instead assigns sketches and detailed INT observations to different flow-size populations and jointly considers where measurement runs and how its reports are collected.

Time-Variant NTN Measurement Scenario

Why the Scenario Is Relevant In a time-variant NTN, the set of usable links and the forwarding path between two endpoints can change even when no failure has occurred. A measurement deployment can therefore face incomplete or time-bounded path knowledge. At the same time, detailed per-packet telemetry can consume packet space, processing capacity, report bandwidth, and collector resources that are not uniformly available across satellite, airborne, gateway, and terrestrial nodes. These conditions do not by themselves require a new measurement mechanism. They provide a concrete setting for the two resource questions already addressed by the framework: which capable nodes should perform Sketch and INT measurement, and which available paths should carry the resulting measurement data. Prior work has studied in-band network-wide telemetry for topology-varying LEO satellite networks . This provides evidence that INT-based measurement in such a scenario is an existing research direction. The contribution considered here is not the general use of INT in a satellite network, but the applicability of the paper's large-flow/small-flow co-design and its placement and collection methods.

Mapping the Existing Framework The variables of the existing framework can be interpreted for an NTN evaluation without changing its data-plane behavior:

the candidate set P contains only satellite, airborne, gateway, or terrestrial nodes that can execute the selected Sketch and INT functions;
the set C identifies the ground or on-board control-plane nodes that can receive measurement data in the evaluated deployment;
each flow in F retains its OD-pair representation, while its candidate measurement points are derived from the topology and path model used for the evaluated interval; and
candidate collection paths and link capacities correspond to the network state supplied to the congestion-aware collection method.

At a selected measurement point, packet processing is unchanged: the packet updates the sketch; a flow below the large-flow threshold also activates INT; and subsequent packets stop activating INT after the flow reaches the threshold. No satellite-specific packet format or threshold rule is introduced. A placement or coverage result applies to the topology, candidate paths, and capability set supplied as input. If these inputs no longer describe the forwarding state, the result cannot be assumed to remain valid. This document does not define when updated inputs are distributed or when the optimization is rerun.

Assumptions Requiring Validation An NTN evaluation needs to verify rather than assume:

that the traffic has enough flow-size skew for the Sketch/INT division to reduce INT load;
that the selected nodes can execute the sketch update, threshold check, INT processing, and report export at the required rate;
that the selected INT metadata and encapsulation fit the packet and MTU constraints of the evaluated links;
that the topology and candidate-path model cover the forwarding behavior during the evaluated interval; and
that measurement data can be transported without violating the configured load limit on time-varying links.

Sketch-INT Co-Design

Allocation by Flow Size The framework assumes that the traffic distribution is sufficiently skewed for a small number of large flows to account for a substantial fraction of packets . This assumption needs to be checked for the target network and collection window. For each configured flow key, a sketch maintains an approximate count. Before the count reaches the large-flow threshold, the packet is also processed by the selected INT function. Once the threshold is reached, subsequent packets of that flow continue to update the sketch but do not activate INT. Thus, the sketch records the large-flow volume and INT retains detailed visibility for the packets observed while a flow is small. The threshold is an implementation parameter rather than a constant defined by this document. A lower threshold reduces INT traffic but can move more flows to approximate measurement. A higher threshold preserves more detailed observations but increases INT overhead.

Workflow

The administrator supplies the topology, candidate programmable devices, control-plane nodes, OD pairs, sketch configuration, INT configuration, flow key, collection window, and large-flow threshold.
The framework selects measurement points using the method in .
At a selected measurement point, each packet updates the sketch. According to the configured comparison order and threshold rule, INT is applied while the flow is classified as small. Otherwise, the packet is forwarded without activating INT for this framework.
Sketch data are emitted at the configured collection window, and INT observations are made available by the configured INT collection method.
The framework estimates the generated measurement traffic and selects collection paths as described in .

Threshold and State Consistency Implementations need to state whether a threshold decision is based on packet count, byte count, or another statistic; whether the current packet is included before the comparison; and when sketch state is reset. These choices determine which packets are described by INT and are necessary when reproducing a result. Because the threshold decision can use an approximate sketch estimate, collision-induced overestimation can classify a flow as large and stop INT earlier than ground truth would. An evaluation needs to report this transition error or otherwise show how the implementation prevents it from invalidating the claimed small-flow visibility. Where a flow can traverse multiple measurement points, their sketch states and threshold decisions are not assumed to be identical. Results therefore need to identify the measurement point that produced each sketch result or INT observation. This document does not introduce a protocol for synchronizing sketch state between devices.

Measurement-Point Selection

Inputs and Objectives The selection problem uses a topology G = (V, E), a subset P of programmable devices, a set C of control-plane nodes, and a set F of flows represented by OD pairs. When the exact forwarding path is unknown, the candidate set for a flow consists of programmable devices on the shortest paths considered possible between its origin and destination. The framework balances two objectives: increasing flow coverage and reducing the distance from selected measurement points to their assigned control-plane nodes. A configurable weight expresses the relative importance of the objectives. The path model, distance metric, candidate paths, and objective weight are part of the experiment or deployment configuration.

Selection Method The combined coverage and assignment problem is NP-hard. The implementation motivating this document applies Lagrangian relaxation to the coverage constraints. The relaxed problem can be decomposed into per-device decisions using a penalty derived from the flows that a device can cover and the cost of assigning that device to a control-plane node. The multipliers are updated using subgradient optimization, and the best feasible solution found across iterations is retained. Weak duality supplies a bound with which to evaluate the resulting solution. This document describes this method as part of the framework; it does not require other implementations to use the same optimizer. An alternative optimizer needs to report its objectives, constraints, stopping condition, running time, and achieved coverage.

Limits of the Path Model Coverage computed from candidate shortest paths is predicted coverage rather than proof that a flow traversed a selected device. Policy routing, equal-cost multipath, failures, and topology changes can produce other paths. Evaluations need to distinguish coverage predicted by the input model from coverage observed in packet traces or device reports.

Congestion-Aware Measurement Data Collection

Worst-Case Rate Estimation For a sketch of size S bytes and collection window T seconds, the framework estimates a sketch-data sending rate of S/T bytes per second when the full sketch state is emitted once per window. For INT data at measurement point p, the implementation estimates the maximum packet rate of traffic that remains below the large-flow threshold and multiplies it by the INT report size. In the implementation motivating this document, the packet rate is estimated from link capacity, the maximum fraction of traffic attributed to small flows, and the average packet size of those flows. The total estimated measurement rate at a point is the sum of its sketch and INT rates. These estimates are conservative inputs to path selection, not guarantees: traffic distributions, packet sizes, compression, batching, and losses can change the observed rate.

Dynamic Path Selection The framework constructs candidate collection paths from each measurement point to its control-plane node. At each decision interval, it considers current data-plane load, queue depth, candidate-path link capacities, and the estimated measurement rates. It selects paths and splitting ratios while limiting combined normal and measurement traffic to a configured fraction of link capacity. The implementation motivating this document formulates the task as a constrained Markov decision process and uses reinforcement learning for path selection. If a proposed allocation exceeds the configured safety limit, its splitting ratios are scaled before deployment. This document does not standardize the learning algorithm. A deployment needs to report how the policy is trained, the observation and action intervals, the safety limit, and the behavior when no feasible collection path is available.

Configuration and Result Reporting A description intended to reproduce or compare an implementation should include:

topology, candidate measurement points, control-plane nodes, candidate paths, OD pairs, routing knowledge, distance metric, and the interval or topology state for which the path model applies;
flow key, collection window, offered load, packet-size distribution, and observed flow-size distribution;
sketch type, dimensions, memory, update rule, reset behavior, query method, and known error properties;
large-flow statistic, threshold, comparison order, and behavior for the packet that crosses the threshold;
INT specification and version, metadata fields, packet-selection rule, encapsulation, report format, and collector behavior;
measurement-point selection objectives, constraints, optimizer, stopping condition, running time, predicted coverage, and observed coverage;
sketch and INT rate-estimation inputs, collection-path candidates, decision interval, safety limit, and overload behavior;
measurement-data bandwidth, packet overhead, device state, processing cost, collector load, report loss, and collection latency; and
ground-truth method and application-specific accuracy metric.

Results from two implementations are not directly comparable if their flow definitions, thresholds, collection windows, traffic distributions, path knowledge, or INT metadata differ without being reported.

Applicability

Measurement Applications The framework is applicable when an operator needs both approximate statistics for high-volume flows and detailed observations for small flows. Examples evaluated by the motivating implementation include heavy-hitter and superspreader detection, per-flow counting, flow-size distribution and entropy estimation, microburst detection, and congestion control. Its expected advantage depends on traffic skew, available programmable-device resources, collection capacity, and the accuracy needs of the application. It is not expected to improve a workload in which flow size does not provide a useful basis for assigning the two measurement mechanisms.

NTN Validation Status and Open Questions makes the NTN scenario explicit, but the current implementation and evaluation use programmable terrestrial switches. They do not establish deployability on satellite hardware and do not evaluate scheduled handovers, inter-satellite links, disrupted control connectivity, or a satellite routing protocol. Consequently, this document makes no performance or deployment claim for an NTN. The first evaluation questions are whether the flow-size distribution still provides the expected reduction in INT reports, whether predicted measurement coverage remains close to observed coverage as paths change, and whether the collection policy can respect its load limit when available paths and capacities vary. Answering these questions requires NTN emulation or implementation evidence and is future work.

Relationship to IOAM IOAM provides IETF-defined data fields and procedures for collecting operational information inside a limited domain . It may provide a path for future standardization of the detailed measurement component. However, an IOAM realization would need to specify how packets are selected before and after the large-flow threshold, which IOAM option and data fields are used, how reports are exported, and how the result is associated with the sketch state. This version does not specify or evaluate that mapping.

Implementation Considerations The motivating implementation separates optimization, controller, and programmable-data-plane components. Measurement-point selection is solved off the data path. A controller translates the selected sketch, INT, and collection-path decisions into switch configuration. The data plane performs sketch updates, threshold checks, INT activation, and forwarding at line rate. The implementation has been evaluated on programmable switches in a terrestrial testbed. This demonstrates the feasibility of the evaluated terrestrial prototype; it does not imply support on every programmable target or on non-terrestrial hardware. Target-specific parser, pipeline-stage, memory, metadata, and traffic manager limits need to be reported.

Security Considerations The framework inherits the security and privacy considerations of the selected sketch, INT mechanism, encapsulation, collection transport, and controller. Measurement data can reveal traffic volumes, communication relationships, paths, and device state. Access to configuration and collected data needs to be restricted to authorized components. An adversary can split traffic across many flow identifiers to keep it below the large-flow threshold and increase INT processing and reporting load. Implementations need resource limits and overload behavior that prevent measurement traffic from exhausting packet, device, link, or collector capacity. Manipulated topology, OD-pair, traffic-load, or queue information can affect measurement-point and collection-path decisions. Control inputs and reports therefore need source authentication and integrity protection appropriate to the deployment. A missing report must not be interpreted as a measured zero.

Changes from Version 00

Added Qiang Wu as a co-author.
Clarified scope and non-goals, including the distinction between the evaluated P4-based INT mechanism and a possible IOAM mapping.
Clarified the per-flow threshold decision and state needed to reproduce the division between sketch and INT measurement.
Distinguished predicted coverage under incomplete routing knowledge from observed coverage.
Added configuration and result information for comparing implementations.
Added time-variant non-terrestrial networks as a potential target scenario, mapped the existing framework variables to that scenario, and stated the assumptions requiring validation without claiming satellite implementation or performance.

IANA Considerations This document has no IANA actions.