Notify–ACK Protocol

• Notify–ACK is an event-driven protocol that employs explicit notifications and detailed acknowledgments to enhance adaptive control across distributed systems.
• It integrates structured telemetry in domains like data center networking, sensor state estimation, and scholarly repository validation for real-time adjustments.
• The protocol design ensures verifiable, idempotent message flows and secure audit trails, facilitating efficient resource utilization and reliable system control.

The Notify–ACK protocol encompasses a family of architectures that leverage explicit notifications and acknowledgments for coordinated, event-driven feedback across distributed systems. The protocol exists in several domains including networking, large-scale scholarly repository integration, and wireless sensor state estimation. Central to Notify–ACK is its reliance on informative, structured acknowledgments—issued not simply to confirm receipt but to encode actionable telemetry, system state, or validation outcomes—enabling fine-grained adaptive control at the endpoints.

1. Protocol Fundamentals and Functional Overview

At its core, the Notify–ACK protocol is a bidirectional signaling mechanism where the sender issues notifications of events, actions, or observed phenomena, and the receiver processes these and responds with structured acknowledgments encoding validation, state changes, or telemetry. Unlike basic ACK/NACK signaling, the Notify–ACK protocol is invariably event-driven, its acknowledgments are contextually meaningful, and its payloads often encode application-specific metadata or telemetry.

In remote state estimation contexts, Notify–ACK enables sensors to adjust transmission strategies in real time, based on loss patterns detected at the estimator and flagged via an ACK channel, thus optimizing network resource consumption and estimation accuracy (Li et al., 2015). In ultra-low-latency data center networking, FNCC (Fast Notification Congestion Control) exploits Notify–ACK by embedding live in-network telemetry and congestion information in returning ACK packets, tightly coupling congestion monitoring to send-window adaptation on sub-round-trip time granularity (Xu et al., 2024). In scholarly communication, Notify–ACK (as realized in COAR-Notify) provides machine-actionable notifications and receipt-acknowledgments to support interoperable validation and dissemination of scholarly software assets across repository infrastructure (Cancellieri et al., 4 Aug 2025).

2. Design Patterns and Message-Flows

Notify–ACK protocols are best characterized by structured message exchange patterns, strict correlation of request and response using persistent identifiers, and event semantics. These principles facilitate verifiable, idempotent, and trackable communication.

Message Flow Example: Research Software Dissemination (COAR Notify)

1. Aggregator discovers an event (software mention) and posts an Offer notification (JSON-LD, ActivityStreams+COAR Notify context) to the target repository’s HTTP inbox.
2. The repository, acting upon the Offer, routes the notification for human-in-the-loop validation.
3. The validated outcome is returned as a ReviewAction ACK (Accept, TentativeAccept, Reject), referencing the initial notification via inReplyTo.
4. The aggregator processes the ReviewAction. On acceptance, it broadcasts an Announce notification to archive services (e.g., Software Heritage), completing the chain. All notifications and acknowledgments persist in inboxes, forming a verifiable audit trail (Cancellieri et al., 4 Aug 2025).

Message Flow Example: FNCC Networking

• ACKs from the data flow's receiver are augmented in-line at switches to encapsulate instantaneous queue, throughput, and flow count (acquired from per-port INT tables). The sender parses these Notify–ACKs to rapidly infer congestion locus and compute send-window adjustments (Xu et al., 2024).

Message Flow Example: Remote State Estimation

• The estimator tracks packet-loss events, emitting a flag-ACK only after a predetermined run of consecutive losses to trigger high-power retransmissions by the sensor, enabling energy efficiency while maintaining estimation fidelity (Li et al., 2015).

3. Protocol Realizations Across Domains

Domain	Notify–ACK Role	Distinctive Features
Research Repositories	Software asset validation/dissemination	JSON-LD, ActivityStreams, COAR Notify terms, HTTP inboxes
Data Center Networking	Sub-RTT congestion telemetry, windowing	INT in ACK, programmable switches, symmetric routing
Sensor Estimation	Online power scheduling vs. losses	Flag-ACK after z₀ losses, one-bit event detector, Markov modeling

In data center networks, Notify–ACK is instantiated in the FNCC protocol, where each ACK packet carries:

• N: number of concurrent congested flows (16 bits)
• B: bottleneck link bitrate code (4 bits)
• TS: timestamp/cycle for rate computation (24 bits)
• txBytes: bytes transmitted since last update (20 bits)
• qLen: queue occupancy in bytes (16 bits) This structure, inserted into ACK headers in-line at each switch egress, enables the sender to compute per-hop congestion coefficients and engage in sub-RTT congestion window adaptation (Xu et al., 2024).

In scholarly infrastructure (COAR Notify), data objects (software, manuscripts) and relationship actions (Offer, Announce, Review) are structured as JSON-LD with rich type metadata, and each message explicitly references prior ones via URNs, guaranteeing traceability and auditable correlation (Cancellieri et al., 4 Aug 2025).

In sensor networks for state estimation, Notify–ACK policy involves a shift-register encoding of recent packet success/failures at the estimator; only after a run of consecutive loss events is an explicit ACK (flag) returned. This minimizes control overhead and triggers adaptive energy usage at the sensor (Li et al., 2015).

4. Mathematical Formulation and Analysis

The Notify–ACK protocol enables control-theoretic and queueing analyses due to its event-driven, memoryful signaling structure.

Congestion Control (FNCC)

Sender computes the fair share as: $$W_i = \frac{B \times RTT}{c}, \qquad r_i = \frac{B}{c}$$ Where $B$ is the link capacity, $c$ the concurrent midpoint flows, and $RTT$ the round-trip time. Using per-port INT (queue, bytes, time), the congestion indicator is: $$U_j = \frac{\min(qLen_j, qLen_j^{prev})}{B_j \times RTT} + \frac{txBytes_j}{B_j}$$ Send-window update per-ACK: $$W = \begin{cases} \frac{W^c}{\,U_{\max}/\eta\,} + W_{AI}, & U_{\max}\ge\eta \ W^c + W_{AI}, & \text{otherwise} \end{cases}$$ For last-hop congestion, immediately reset: $W^c = \frac{B_{\rm last}\,RTT\,\beta}{N}$ This mechanism yields a provable sub-RTT feedback loop and demonstrably reduces latency, queue depth, and ensures fair bandwidth allocation (Xu et al., 2024).

Remote State Estimation Under Attack

Modeling the closed-loop as a finite-state Markov chain with states $S_k = (τ_k, σ_k)$ (time since last successful arrival, attack counter), a stationary distribution $\pi^*$ yields the long-run average error covariance: $$J(\tilde\theta_{on}) = \sum_i \pi^*_i \operatorname{Tr}\big(P(\epsilon_i)\big)$$ Bounds are explicit:

• No attack: $B$0
• All ACKs blocked: $B$1 and

$B$2

A threshold $B$3 is computed by solving $B$4; above it, switching to a static offline policy is optimal (Li et al., 2015).

5. Security, Robustness, and Failure Modes

Notify–ACK protocols, by exposing structured signaling channels, are subject to integrity and authenticity risks. In remote estimation, adversaries capable of blocking or forging a fraction $B$5 of flag-ACKs can degrade estimator performance. Mitigation involves empirical estimation of $B$6 by the sensor and safe switching to an offline policy if attack strength exceeds threshold $B$7, ensuring that estimation cost remains bounded (Li et al., 2015).

Networking deployments rely on ensuring that INT data in ACKs cannot be forged or replayed. Programmable switches and secure header formats are employed, but reliance on path symmetry and prompt ACK generation can be a limiting factor. The use of idempotent message identifiers and durable, append-only delivery inboxes in COAR Notify ensures reliable provenance and auditability but depends on persistent HTTP endpoint availability and system-level error handling (HTTP retries, back-off, durable queues) (Xu et al., 2024, Cancellieri et al., 4 Aug 2025).

6. Scalability, Performance, and Implementation

Notify–ACK protocols are inherently scalable when implemented with efficient queuing, batching, and endpoint message persistence.

In FNCC, embedding an 80-bit INT header on each ACK imposes negligible overhead in RDMA networks, and programmable switch tables per output port are required to maintain real-time queueing statistics. High-throughput evaluations demonstrate reductions in flow completion time by up to 88.9%, substantially shallower queue peaks, and improved pause-frame behavior compared to prior DCQCN and HPCC mechanisms.

In repository integration (COAR Notify), inbox endpoints are stateless HTTP URLs, facilitating interoperation between HAL, DSpace, Software Heritage, and other platforms with minimal bespoke development. Every notification/acknowledgment forms part of an immutable ActivityStreams object log, supporting high-volume, parallel processing. Batching at the aggregator (only sending notifications that exceed a confidence threshold) is used for performance management. Auditability is anchored by persistent identifiers (DOI, SWHID) (Cancellieri et al., 4 Aug 2025).

Sensor scheduling implementations exploit the minimal control bandwidth required by event-driven ACK production—one bit sent only after a rate-limited run of losses. Markov modeling underpins guarantees on resource usage and estimation error under both normal and adversarial conditions (Li et al., 2015).

7. Extensions, Trade-offs, and Domain-Specific Limitations

Domain-specific limitations and design trade-offs include:

• Data center implementations require programmable switch support and enforce symmetric routing (e.g., ECMP with mirrored hash tables). The 16-bit flow count field caps at 65k concurrent QPs, constraining extreme multi-tenancy (Xu et al., 2024).
• In scholarly repository networking, operational robustness relies on reliable HTTP infrastructure, and manual review bottlenecks may arise if validation is not batched or further automated (Cancellieri et al., 4 Aug 2025).
• In sensor estimation, significant attack on the ACK channel triggers a fallback to offline scheduling, ensuring estimator performance does not fall below a computed offline lower bound (Li et al., 2015).

Potential protocol evolution includes encapsulating INT in TCP options for non-RDMA transport, per-traffic-class adaptation of congestion thresholds, and embedding explicit packet-scheduling directives.

A plausible implication is that Notify–ACK protocols, by their structured, context-rich design, enable not only adaptive feedback-control in communication networks and estimation systems but also trustworthy, interoperable workflows in federated scholarly infrastructures. This generalizes their significance beyond simple acknowledgments into mediators of integrity, auditability, and system-level adaptability.