## 4 In-Network Computing via ICN
### Proactive Executor Discovery  
Selection of service executors can be enhanced by proactively distributing information about the capabilities of network nodes. However, this requires additional signaling, which introduces extra overhead. Efficient dissemination strategies, such as broadcasting updates only when significant changes occur or by carefully managing the frequency and size of these updates, can minimized the overhead, while still enabling informed service executor selection. In the following, we revise some notable approaches in this context. In [48], a periodic resource discovery mechanism is proposed, where nodes share utilization information with their neighbors. The update interval ranges from 15 to 60 s, and messages are flooded within a hop-count scope of 2 to 4. In parallel, the routerscan solicit updates by generating Interest packets. As expected, simulation results show that increasing the scope and frequency of updates improves performance but at the cost of higher signaling traffic overhead. Similarly, the work in [67] proposes a proactive resource discovery mechanism based on Resource Headcrumbs (RBCs), which allows potential edge executor nodes to distribute information about their resource availability, such as CPU and memory status, using scoped flooding within the local network. Interest packets are then guided toward suitable nodes based on these breadcrumbs, ensuring that requests are directed to executors with sufficient capacity to handle them. Unlike [48], the resource status information is updated only when there are significant changes in the executor's resource availability (e.g., exceeding a threshold), making the process more efficient than periodic updates. Moreover, when receiving a service request, executors attach their updated resource statuses to response Data packets, reducing the need for separate signaling. Simulations demonstrate that this approach effectively reduces resource allocation failures and enhances resource utilization. In NFaaS [62], nodes leverage a routing protocol to proactively advertise the name prefixes of locally available functions, allowing Interests to be forwarded directly to an appropriate executor based on the service name. The decision regarding which functions to store and run locally is based on a combination of service popularity, as measured by historical demand, and service-specific requirements. For instance, latency-sensitive services are predominantly deployed closer to edge nodes, while bandwidth-intensive services are allocated to core nodes to optimize resource utilization and minimize network overhead. The routing fabric is updated in real time to reflect the location of moving functions and also supports load balancing by dynamically redirecting Interests to alternate execution points when the primary node is overloaded. This feature enables the network to distribute computational tasks evenly across available resources, improving overall system performance and resilience. The work in [68] enhances the NFN framework by introducing the State Vector Synchronization (SVS) protocol. This latter implements periodic and event-triggered notifications among NFN nodes to share updates on function availability and resource utilization. More specifically, nodes broadcast lightweight Interest packets to announce their presence. An hop limit can be set to avoid flooding the network, while loops are prevented through duplicate detection mechanisms. Receiver nodes send back Data packets containing static properties such as compute configurations (e.g., CPU, GPU, memory) and network configurations (e.g., hop distance, link status). Subsequently, nodes are grouped into clusters based on proximity (e.g., one-hop or three-hop distance) or other criteria such as compute capabilities or specialized roles. Within each synchronization group, nodes exchange updated state information. When a service needs to be executed, a node first leverages its neighborhood knowledge to determine if there is a potential executor owning the processing function.