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.