Introducing M4P: An Open Protocol for Delay-Tolerant Maritime Mesh Networking

[peter]

Introducing M4P: An Open Protocol for Delay-Tolerant Maritime Mesh Networking

I’m Peter Girard, a software engineer at Poseidon’s Forge, a young startup building AUVs with the goal of reducing the time and cost of going from idea to deployed in the water. One of the biggest barriers to that goal is the lack of a standard networking protocol that works over low-throughput communication links like acoustic modems. M4P aspires to be the open standard that fills that gap.

I’m sharing the draft specification for M4P (Multi-Modal Maritime Mesh Protocol), an open, hardware-agnostic networking protocol designed for environments where connectivity is intermittent, throughput is scarce, and topology is never fully known. I’m looking for feedback from anyone who works in this space or adjacent ones.

The full protocol specification is available on GitHub: Poseidons-Forge/m4p-spec

---

The Problem

Underwater and maritime platforms (autonomous vehicles, sensor buoys, surface relays, shore stations) increasingly need to cooperate as distributed systems. But the networking layer that every other domain takes for granted doesn’t exist here. Current options are proprietary, vendor-locked, or simply nonexistent. Every cross-platform integration ends up as a bespoke engineering effort.

The physical constraints make this harder than it sounds:

• Intermittent connectivity is the norm. Vehicles submerge, surface, drift out of range. Contact windows are irregular and unpredictable.
• Topology is unknown and constantly changing. Mobile nodes make global routing tables impossible to maintain.
• Throughput is extremely constrained. Some acoustic links carry payloads measured in tens of bytes. TCP/IP headers alone (40+ bytes) can exceed the entire payload budget.
• A vehicle might communicate acoustically while submerged, switch to radio on the surface, then relay through satellite to reach shore. A single message may traverse all three link types before arriving.

Conventional networking protocols, including the Bundle Protocol, were not designed for these constraints.

What M4P Does

M4P defines both a wire protocol and a middleware architecture. The wire protocol specifies compact packet formats, addressing, and encryption. The middleware specifies how nodes store, prioritize, and forward messages, discover peers, and resolve address conflicts. Together, they give applications a single networking layer that works across any combination of acoustic, radio, satellite, and IP links — without applications needing to know about the underlying transport.

It uses store-carry-forward delivery: nodes don’t assume end-to-end paths exist. A node stores messages locally and forwards them whenever a transmission opportunity arises on any available link. Messages propagate opportunistically until they reach their destination or expire.

This reflects a fundamental shift in optimization target. Traditional protocols ask “what is the best path to get this packet to its destination?” M4P operates without global routing tables or topology knowledge, so that question has no answer. Instead, on constrained links, nodes ask “given this one scarce transmission opportunity, what is the most valuable thing I can send to add the most new information to my neighborhood?” The goal is knowledge dispersion, not path optimality.

Architecture

The protocol has three layers:

• Transport handles packet formats, deduplication, Time-to-Live (TTL) expiration, fragmentation/reassembly, priority scheduling, and store-carry-forward forwarding.
• Network handles decentralized address assignment, conflict resolution, peer discovery, and fleet membership. No central authority required.
• DataLink Abstraction is a narrow interface that separates M4P from physical communication hardware. Each modem or radio implements a simple adapter: report when you can transmit and how many bytes you can carry. M4P handles everything above that line, which is what makes it hardware-agnostic.

Applications interact through four message classes: Status (periodic telemetry, latest-value-wins), Event (append-retained observations), and Request/Response (directed command-and-control with stateless correlation).

Highlights from the Spec

Rather than rehash the full spec here, a few design points worth calling out:

• Wire efficiency. A Status packet header is 8 bytes, compared to ~26 for Bundle Protocol and 40+ for TCP/IP. On a 64-byte acoustic payload, M4P leaves 56 bytes for mission data. TCP/IP leaves 24. On a 30-byte link, TCP/IP can’t fit its headers at all.
• Deduplication with zero wire overhead. Message Instance IDs are computed from fields already in the header (source address, timestamp, message counter), so deduplication doesn’t cost any additional bytes.
• Throughput-transparent applications. Applications produce messages without regard to link capacity. On a LAN, everything flows. On a constrained acoustic link, the scheduler selects the highest-value packets that fit the available payload budget and packs multiple packets into a single transmission. Applications don’t have to adapt to link conditions.
• Decentralized addressing. Nodes derive their own addresses via SHA-256 hash of identity + network ID. No pre-mission address planning. Conflicts are resolved deterministically so every node computes the same winner.
• Cross-modality fragmentation. A message arriving over a LAN link can be forwarded as fragments over a constrained acoustic link. Fragments propagate independently and are reassembled at the destination.
• Security. AES-256-CTR end-to-end encryption with zero ciphertext expansion. Nonces are derived from existing header fields, so no extra bytes on the wire and no nonce coordination. Optional CMAC authentication tags. A separate DataLink-layer encryption provides per-hop protection independent of the payload cipher.

What M4P Doesn’t Do

Minimizing packet headers comes at a cost. The following features were deliberately left out of M4P:

• No guaranteed delivery. Requests are retransmitted and Responses serve as implicit end-to-end acknowledgments, but delivery is still best-effort. Messages may be dropped or time out.
• No message ordering. Packets arrive as connectivity allows, not in sequence. Applications can determine send order from header timestamps and message counters and can handle sequencing themselves.
• Limited address space. 8-bit (255 nodes) or 16-bit (65K nodes) maximum. M4P is designed for fleet-scale deployments, not internet-scale networks.

Related Work

M4P’s wire encoding draws on ideas from DCCL (Dynamic Compact Control Language), including compact type encoding, timestamp compression, and AES-CTR encryption with header-derived nonces. M4P is designed to complement DCCL — DCCL handles efficient payload serialization, while M4P handles networking, delivery, and multi-link coordination above it.

Current Status and What’s Next

The draft specification (v0.2) is on GitHub. The protocol has been validated in both software-in-the-loop and hardware-in-the-loop testing across acoustic, cellular, and Wi-Fi links. I’ll also be presenting M4P at Oceanology International on Tuesday March 10th (South Gallery Room 11 & 12, 12:20 - 13:40).

We’re planning to open-source a full middleware implementation of M4P soon, including DataLink adapters for LAN, MQTT, and Popoto acoustic modem, along with Rust and Python SDKs for writing your own drivers. We’re also developing a ROS2 bridge so M4P can integrate directly with existing ROS2-based systems.

Looking for Feedback

I’m primarily looking for people to read the spec and poke holes in it.

• Does the wire format make sense? Are there edge cases I’ve missed? Are the behavioral requirements clear enough for independent implementation?
• Does the DataLink abstraction draw the boundary in the right place? Does the addressing model hold up under scenarios I haven’t considered?
• If you work with underwater comms, maritime autonomy, DTN, or constrained-environment networking, does this solve a real problem for you? What’s missing?

Happy to answer questions or discuss any of this in the thread.

[toby]

Hi Peter! First, welcome to the forum and I really appreciate your comprehensive introduction of M4P. I am certainly keen to see how this works and will take a look shortly.

(minor admin note: I’ve moved this post into the Communications category as I think it’s a better fit).

[jordsmidr]

Hi Peter,

Thank you for publishing M4P and inviting feedback.

Before discovering M4P, we had begun drafting our own protocol concept for an open maritime communications grid. The immediate motivation was moving messages and synchronizing application data over intermittent, extremely constrained links, but we wanted the network layer to be useful beyond any single application.

Our concept envisioned independently administered vessels, shore stations, buoys, volunteer relays, and autonomous systems participating in a common store-carry-forward network without belonging to one preconfigured fleet. A node might communicate through local radio, connected HF links such as VARA, ARDOP, or PACTOR, acoustic modems, an IP connection when available, or several modalities at once.

The long-term goals included:

• Operation without continuous Internet connectivity or a central routing authority.

• Dynamic encounters and participation by previously unknown nodes.

• Store-carry-forward delivery across multiple physical modalities.

• Retention of messages for hours or days until useful contacts become available.

• Independent administration by different operators, manufacturers, applications, and service providers.

• Coexistence of different protocol and application versions.

• Dynamic discovery of service gateways rather than dependence on one fixed destination.

• Extremely low overhead on HF, acoustic, and other constrained links.

• Growth from small local groups to a much larger maritime ecosystem.

After reading the M4P specification, it became clear that M4P already provides most of the difficult foundation we were attempting to design: store-carry-forward transport, cross-modality forwarding, compact wire formats, deduplication, fragmentation and reassembly, priority scheduling, peer discovery, decentralized address assignment, forwarding suppression, and a clean DataLink abstraction.

I have also noticed the current draft work on knowledge-driven forwarding. Replacing separate Network Control propagation rules with a common knowledge model, spacing ladder, and per-type forwarding scopes looks like a significant improvement. In particular, it appears relevant to efficient dissemination of changing state without unnecessary repeated transmissions.

M4P is substantially more developed than our protocol concept, and we are very excited about it. Our preferred path is to build on standard M4P, contribute generally useful improvements upstream, and keep application-specific behavior in separate profiles. We would much rather help strengthen one open maritime protocol than continue developing a competing one.

The largest unresolved question for our intended use remains addressing.

The current design appears very strong for its stated target: a bounded fleet or deployment operating under severe byte constraints. Separating persistent NodeUIDs and ClientUIDs from compact 8- or 16-bit wire addresses is a valuable foundation.

However, I do not think the present deployment-scoped address model is sufficient by itself for a larger public network.

A future open maritime network could include unrelated recreational and commercial vessels, shore stations, volunteer relays, buoys, and autonomous systems. Any individual radio, acoustic, or HF neighborhood might contain relatively few active participants, but the total population could greatly exceed the 16-bit address space. More importantly, those participants would be independently administered and could encounter one another without prior coordination or shared provisioning.

The problem is therefore not simply the number of available addresses. It is how address scope, persistent identity, discovery, and federation work when there is no single deployment operator.

The current specification uses a shared static network_id, common addressing mode, and other coordinated network-wide configuration. That works well for a mission fleet, but a public network raises several questions:

• If everyone participates in one worldwide network_id, how far must address claims and UID mappings propagate?

• Can address state remain local to the region in which a node is currently reachable, or must every short address remain globally unique and converged?

• How are conflicts handled when long-separated network partitions later encounter one another?

• If the ecosystem uses separate network_id realms, how does a message cross between them without losing its original identity, deduplication state, or security context?

• How does a previously unknown node participate safely without advance provisioning by the same administrator?

• How can a sender address a recipient or service that is not currently present in its local address scope?

Reticulum provides useful prior art for this particular problem. It uses persistent 128-bit identity-derived destination hashes, destination announcements, and path requests. This provides a large decentralized namespace and lets independently operated nodes discover destinations and paths without a central address allocator.

I do not think placing a 16-byte destination into every M4P packet would be the right solution. That would undermine one of M4P’s most important advantages on highly constrained links.

A more promising direction may be a two-level model:

• A persistent, cryptographically derived global identity used for discovery, trust, and communication across independently administered networks.

• Compact 8- or 16-bit addresses used as temporary aliases within a local address scope, neighborhood, or contact session.

The longer identity might appear only during announcements, address establishment, exceptional resolution traffic, or communication between scopes. Once peers establish the mapping, ordinary traffic could continue using M4P’s compact addresses.

This seems compatible with the distinction M4P already makes between UIDs and wire addresses, but it would require additional rules. A relay or gateway crossing address scopes would need to preserve the original identities, Message Instance ID, deduplication semantics, and encryption context. Simply rewriting a Client Address may not be sufficient because address fields participate in message identity and nonce construction.

Does a scoped or federated address model fit M4P’s intended direction? Alternatively, is network_id intended to remain a firm boundary, with communication between separate M4P networks implemented entirely above the protocol?

I recognize that M4P explicitly targets fleet-scale rather than Internet-scale networks. I am not suggesting that the existing fleet model be replaced. Ideally, independently administered public participation could be an additional profile or operating mode while configured fleets retain their simpler and more efficient behavior.

Several related questions remain from our earlier protocol design:

• Mixed-version interoperability: The new draft work is encouraging because it specifies bounded store-and-forward carriage of unknown Network Control types. That provides a useful form of mixed-fleet compatibility for additive control records. A public network may eventually need broader rules for protocol evolution when independently administered nodes cannot upgrade together. Could the unknown-record approach become the foundation for that, or would changes to packet framing still require coordinated deployment-wide upgrades?

• Message lifetime: The approximately 7.4-hour maximum TTL is understandable given the compact 24-hour timestamp. Some maritime store-carry-forward paths may have contact gaps measured in days. This might require an optional extended-lifetime representation or a defined application-layer method for refreshing long-lived objects without breaking identity and deduplication.

• Message Type coordination: Application Message Type IDs are assigned per deployment. Independently developed applications would need a registry, namespace, or interoperable profile catalog. This may be solvable outside the core protocol without adding per-packet overhead.

• Public participation and trust: A network of unrelated operators cannot assume that every participant shares one deployment secret or administrative authority. Persistent cryptographic identities may provide a basis for authenticating claims while still permitting open relaying.

• Connected HF links: VARA HF, ARDOP, and PACTOR commonly create reliable point-to-point ARQ sessions. M4P’s transmission-opportunity and byte-budget abstraction remains useful, but an adapter may also need to identify the connected peer associated with a particular session or transmission opportunity.

• Gateway and service discovery: Many messages need to reach any suitable gateway offering a service rather than one predetermined physical node. Our concept included short-lived service advertisements, reachability information, suppression of redundant advertisements, and rapid decay of stale information.

The new knowledge-driven forwarding model may already provide much of the generic dissemination and redundant-transmission suppression needed for service advertisements. Gateway meaning, selection, reachability scoring, and service-specific policy could then remain in application-defined Status, Request, and Response messages rather than becoming part of M4P’s core routing behavior.

The principal capability we hope M4P can eventually provide is a path from compact, fleet-scale deployments to a larger, independently administered maritime ecosystem without sacrificing the wire efficiency that makes M4P valuable.

If that direction is compatible with your goals, we would be glad to contribute detailed use cases, specification work, simulations, interoperability tests, and open HF DataLink adapters. We are very enthusiastic about M4P and would like to help extend it rather than continue developing a parallel protocol.