Integrating with software modems for HF band

[rafael2k]

Hi all,
I'm planning to create an interface of Reticulum to software modems (like FreeDATA and Ardop), but most of these software modems just support point-to-point. Is there a problem of this in working with Reticulum?

Eg. of how a network operating in HF with UUCP works today: open a connection to host XX, sync the data, close connection, open a connection to host YY, sync the data, close connection... and so on. Is this model ok to work with Reticulum?

My plan is to use UUCP over Reticulum. Can anyone see a problem with it?

[markqvist]

There should not be any issues with this. Reticulum supports using any physical/virtual device as:

• A point-to-point medium
• A point-to-multipoint medium
• A multipoint-to-multipoint medium (this one sounds weird, since it is so rarely used, but it is not a mistake)

Any of those can also have intermittency without causing problems (other than the syncing being unavailable sometimes, of course). You don't have to configure anything in these regards, Reticulum will figure it out automatically.

There are similarities to this in how LXMF works, so there should not be any problems as such.

[rafael2k]

Thanks!
A last question - I see Fernet works only with base64. Is there any way this overhead can be removed so LXMF messages can go as is, without being converted to base64?

[markqvist]

Yes! this already happens by default :) Reticulum uses a slightly modified version of the Fernet spec, since converting everything to Base64 would be incredibly wasteful on bandwidth. Reticulum has always used pure binary Fernet tokens. More details of the specific implementation can be found here.

[rafael2k]

Perfect. Thanks Mark!

[rafael2k]

Where can I find the current overhead of Reticulum and the needed Tx/Rx switches for connection establishment and actual packets transmission. Do you think a stream cypher like ChaCha20 could be helpful in reducing the overhead of block cyphers?
I'm setting up a test environment with two HF radios in dummy loads, but it is not ready yet.

[markqvist]

These sections of the manaul are a good place to start in regards to understanding total overhead:

• Resources
• Link Establishment in Detail
• Wire Format

In general, the most efficient way to transfer more data amounting to more than around 1.000 bytes is to use the Resource API over a Link.

The raw over-the-wire cost of establishing a Link in Reticulum is 3 packets totalling 297 bytes. Resources transfers use the block cipher over the entire data stream to be transferred, so overhead is completely neglible for anything more than what would fit in a single packet, which you could just send in a single packet anyway ;)

Overhead of Reticulum is extremely low compared to all other protocols currently in existence. If you start looking at protocols with link establishment that achieve the same levels of encryption, security and functionality as Reticulum, it just becomes absurd.

Reticulum is more than 25 times as efficient as TLS 1.3 in establishing an encrypted link that is ready to transfer data. A typical TLS1.3 link establishment over TCP needs 12-16 packets sent back and forth, and will use more than 8.000 bytes of bandwidth.

To get started with the bare minimum of establishing a link and sending data back and forth, take a look at the following code examples:

• Link example code
• File server/client example.

If you want to start with just verifying your physical and software setup, you can try using the rncp utility to copy some files between two systems over your Reticulum network. Here is the relevant manual section:

• The rncp utility

[markqvist]

Oh, forgot about ChaCha. It's not going to make any real impact on overhead due to the way Reticulum is already designed to use AES. Extreme care was taken everywhere to ensure Reticulum is as frugal with bandwidth as is physically possible within the design constraints of the system.

I will definitely look into changing the cipher suite before the non-beta release of Reticulum, and ChaCha is an interesting contender for several other reasons than overhead, but for now, it is not a priority.

[rafael2k]

Thanks a lot Mark, I'll carefully read the documentation you points out. Indeed, the payload will always be bigger than 1kB, as it consists basically of batched e-mails in the UUCP queue. I'm evaluating if it would be interesting to do some tight integration between UUCP low level packets (I use UUCP protocol 'y' with which I can control packet size and other low level tunables) and Reticulum packets.

[rafael2k]

Just realized the rncp and rnx commands really resemble the uucp and uux commands! Do do think it is in the scope of Reticulum to add queue management and asynchronous communication support? Or as I thought previously, may be use Reticulum as the transport for UUCP, which already provides all queue management and asynchronous communication logic.

[markqvist]

Just realized the rncp and rnx commands really resemble the uucp and uux commands!

Yes, that is probably not a total coincidence ;)

Do do think it is in the scope of Reticulum to add queue management and asynchronous communication support?

Yes, but it will probably be a little while before that functionality is included with the standard utils, and I haven't yet settled on the exact format and methods to do this. Utilities providing such functions will be coming though. Hopefully sooner rather than later :)

[zenith777777]

I would be very interested in something like this as well. I initially used the Reticulum TCP interface with the Direwolf AX.25 software modem but found it to be too inconsistent over HF channels. The FreeDATA project uses the FreeDV data spec which I think would be a very good starting point for a software modem and I would love to see a Reticulum interface for it.

[rafael2k]

As the HF band has very strict requirements and specialties, I changed the topic to be more precise about our discussion.

[markqvist]

Good call. I will be following this topic closely. I believe most HF software modems for HF allow controlling them via KISS over TCP on the local computer. This should already be supported and usable with the Reticulum TCPClientInterface in KISS mode, but if there is anything we can add to make setup easier, or if it somehow would be more suitable with a specific interface type for this, let me know.