Named Function Networking (NFN)

• NFN is an extension of Named Data Networking that treats functions as named entities, enabling dynamic computations over data.
• The R2 system employs a two-phase distributed execution workflow where metadata retrieval informs optimal executor selection to minimize data movement.
• Experimental results show improved performance and resource utilization, with significant speedups for complex operator workloads in distributed environments.

Named Function Networking (NFN) is an architectural extension of Named Data Networking (NDN) in which functions—rather than only static data—are treated as first-class named entities within the network namespace. In the NFN model, clients can request the execution of named functions applied to named data, including parameterization, in a fully decentralized and name-driven manner. The R2 (“Request Result”) mechanism exemplifies NFN by enabling distributed remote function execution with integrated metadata for executor selection. Through a structured naming convention and a two-phase interaction, R2 efficiently allocates compute resources and minimizes data movement, resulting in lower end-to-end delays and improved resource utilization, especially for high-volume and complex operator workloads (Qi et al., 2021).

1. NFN Fundamentals and R2’s Naming Semantic

Named Function Networking generalizes the NDN paradigm from named data objects to include services and computational operators. In the R2 system, every NFN request is encoded within an Interest name structured as:

$M_{datasize}$9

The “/r2” prefix distinguishes function-oriented requests. The DataName follows NDN’s longest-prefix matching for routing, ensuring compatibility with the existing forwarding strategy, while the function’s semantics (name and parameters) are included as postfix components and conveyed both in the ApplicationParameters field and as out-of-band tags (MinCostMarker) during execution. This encoding enables purely name-based, registry-free forwarding for both data localization and executor discovery, unifying data and computation under the NDN namespace.

2. Two-Phase Distributed Execution Workflow

R2 introduces a two-stage protocol:

• Phase 1: Metadata Retrieval and Executor Selection The client issues a long-lived metadata-Interest (I1) using the structured R2 name. Intermediate nodes hosting Bolt (the R2 app-level logic) forward the Interest towards the data source, tracking traversals in an Interest-Trace Table (ITT). Upon reaching the producer $p$, a metadata Data packet $M$ is returned, including $M_{datasize}$, $M_{metasize}$, and optionally format, resolution, and I/O cost. Each intermediate node $v_i$ estimates:
  • Data transmission delay: $Te_d^{p,i} = \frac{M_{datasize}}{B^{p,i}}$
  • Execution delay: $$Ce_d^i = \frac{c \cdot \mathcal{O}(M_{datasize})}{f_i}$$
  • Combined cost: $\eta_i = Te_d^{p,i} + Ce_d^i$

The metadata packet carries and updates the minimum observed cost ($\minCost$) and associated node identity (MinCostMarker). When $M$ reaches the client, these annotations reveal the node $M$0 to serve as the best executor and the boundary node $M$1 where executor search stopped.

• Phase 2: Data Delivery, Function Execution, and Result Return The client issues a short-lived result-Interest (I2) with the same R2 semantics and the MinCostMarker. This is routed to $M$2, which retrieves the raw data, executes the requested function with parameters, and returns only the final result to the client. The Interest-Trace Table supports proper tracking and reassembly of result Data.

This design ensures minimal raw data traversals, with data flowing to the selected executor only once.

3. Metadata-Driven Cost Estimation and Executor Selection

Executor selection in R2 is fully distributed and metadata-driven. Nodes leverage information such as $M$3, available bandwidth $M$4, compute characteristics ($M$5, $M$6), and explicit function complexity ($M$7) to estimate the local execution cost. This allows a dynamic, context-sensitive decision:

• The minimum estimated cost and associated node (as a cryptographic hash over metadata and a node UUID) are propagated in the reverse data flow.
• The approach requires no centralized registry, instead leveraging opportunistic in-path evaluation, which adapts automatically to the localized state and network conditions.
• Function name and parameters are encapsulated in the Interest name and ApplicationParameters, ensuring a clean separation between naming/forwarding and computation.

A plausible implication is that this framework generalizes beyond specific data flows, potentially supporting arbitrary operator chains with per-path adaptation.

4. Early-Exit Stop Condition for Search Pruning

To prevent exhaustive traversal and cost estimation at every node, R2 introduces a formal stop condition. The search for optimal executor stops at node $M$8 if:

$M$9

Intuitively, once the accumulated data transmission delay to $M_{datasize}$0 equals or exceeds the maximum total cost (including computation) found so far on the path, downstream nodes cannot yield a lower-cost execution point. In store-and-forward networks (e.g., classic NDN), this reduces to:

$M_{datasize}$1

This ensures the intermediate compute node at which downstream transmission overtakes local execution time is always a locally optimal break point. The correctness and safety of this stop rule are established via proof and range analysis (Qi et al., 2021).

5. Bolt: Application-Level Processing and Modular Design

The Bolt module implements all R2 logic at the application layer within ndnSIM, avoiding any modification of core NDF functional blocks. Key features include:

• Interest-Trace Table (ITT): Maintains mappings between cloned Interests (I1, I2), extended lifetimes for persistent tracking, and reconstruction of responses.
• Custom Forwarding: R2 Interests are intercepted by the “/r2” prefix; the embedded DataName is extracted for forwarding, ensuring compatibility with forwarding tables while supporting NFN semantics.
• Modular Hooks: Bolt encapsulates executor selection, cost estimation, the stop condition, and result packetization in flexible hooks triggered on metadata and data receipt.

Any node can participate as a compute/test point simply by running Bolt, enabling scalable incremental deployment without dependent changes to underlying NDN infrastructure.

6. Experimental Evidence and Comparative Evaluation

R2 was evaluated in ndnSIM atop a Rocketfuel network topology comprising 282 nodes. Experiments compared R2 (OptAuto) to Local execution (computation at the client), Producer (computation at the data source), and OptOff (R2 without the pruning stop condition) for function complexities in $M_{datasize}$2, $M_{datasize}$3, and $M_{datasize}$4, with data sizes ranging from 100 B to 1 MiB. Key findings:

• For $M_{datasize}$5 KiB and $M_{datasize}$6 functions, OptAuto yielded a speedup ratio of 4.61 over Local.
• For $M_{datasize}$7 and $M_{datasize}$8, speedups at 100 KiB were 2.37 and 1.84, respectively.
• Hop-by-hop measurements confirmed that the pruning stop condition correctly selects the same executor as exhaustive scan (OptOff) while reducing protocol overhead.
• Compared to prior art (NFaaS, RICE, CFN, IoT-NCN, ICedge), R2’s innovation lies in explicit distribution of function invocation, explicit use of metadata for resource-aware executor selection, and a provable early-exit rule distinguishing it from approaches relying only on piggybacked cost metrics or naive path selection (Qi et al., 2021).

7. Context and Significance within NFN Research

R2 substantiates a systematic approach to in-network computation, advancing NFN by unifying naming, computation, and resource allocation in an end-to-end distributed framework. The encapsulation in Bolt demonstrates feasibility and easy deployment in current NDN-based testbeds and simulators. Prior solutions like NFaaS and RICE provide general service invocation but lack the dynamic, metadata-driven path-aware optimization R2 introduces. By bounding search via the early-exit rule, R2 ensures scalability and deployed efficiency for real-world edge and IoT data-intensive workloads. The generalized architecture supports future extensibility for chained computation, hierarchical function naming, and richer in-network workflow construction (Qi et al., 2021).