| Internet-Draft | Sketch-INT for TVR NTNs | July 2026 |
| Zhu, et al. | Expires 29 January 2027 | [Page] |
Network measurement supports management applications that need statistics about both large and small flows. Sketch-based techniques use compact data structures and are effective for large flows, but hash collisions can produce substantial relative errors for small flows. In-band Network Telemetry (INT) can provide detailed observations for individual packets, but applying it to every packet can consume significant packet, bandwidth, and collector resources.¶
This document describes a framework that uses sketches for large flows and INT for small flows. It also describes measurement-point selection when exact routing information is unavailable and congestion-aware collection of sketch and INT reports. The document identifies the information needed to describe and compare implementations. It does not define a new packet format, INT instruction, sketch algorithm, or routing protocol.¶
As a concrete applicability direction, the document considers time-variant non-terrestrial networks (NTNs), in which paths and available forwarding resources can change over time. It maps the existing Sketch-INT framework to this scenario and identifies the assumptions that require validation. It does not claim that the existing terrestrial implementation has been deployed or evaluated on satellite hardware.¶
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 29 January 2027.¶
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.¶
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 [INT-SPEC]. 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 [RFC9657].¶
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.¶
This document covers:¶
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 [RFC9197] 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.¶
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 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.¶
Previous systems have combined sketches and INT in different ways. SketchINT constructs or transfers sketch information using INT data [SKETCHINT], while LightGuardian places compact sketch information in packets [LIGHTGUARDIAN]. 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.¶
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 [LEO-INT]. 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.¶
The variables of the existing framework can be interpreted for an NTN evaluation without changing its data-plane behavior:¶
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.¶
An NTN evaluation needs to verify rather than assume:¶
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 [TRAFFIC-SKEW]. 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
A description intended to reproduce or compare an implementation should include:¶
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.¶
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.¶
Section 5 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.¶
IOAM provides IETF-defined data fields and procedures for collecting operational information inside a limited domain [RFC9197]. 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.¶
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.¶
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.¶
This document has no IANA actions.¶