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

Communications
3

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.