zfec usage on embedded microcontrollers

[Stuart Longland]

On 31/12/14 00:50, Greg Troxel wrote:
> Your project sounds interesting.  In thinking about coding schemes for
> radio, it's not immediately clear that zfec would be the right one.
> tahoe's need is to recover from some shares assuming whole shares are
> available, with nominally uncorrelated loss patterns.  With RF, loss is
> more complicated and more correlated.

This is true, I wouldn't use zfec for protecting streams of information
if I were doing all the DSP myself.

What I'm looking at is to basically treat an entire datagram as a file,
break it up into shares, and send the shares as individual packets ("UI"
frames in AX.25).

That way if a fade or interference were to cause one part to be lost,
the entire datagram can still be recovered.  AX.25 just checksums
packets, it does no correction and if a checksum doesn't match, the
entire frame is dropped.  This is done before any of my software would
see the frame, so performing error correction within a frame isn't possible.

FX.25 uses forward error correction, and is backward compatible, however
an AX.25 node simply ignores the error correction in an FX.25 frame.  We
have a large fleet of AX.25 TNCs that cannot be upgraded to FX.25 that
I'd like to make use of.

This isn't much different to the use case that Tahoe LAFS presents, in
that a file is broken into blocks and those erasure coded.  The block is
the unit of measurement from the erasure coding point of view.

AX.25 permits frames up to 256 bytes in length.  IPv4 requires a MTU of
576 bytes, IPv6 requires 1280 bytes.  So a IPv4 packet would need to be
sent in 3 AX.25 frames, an IPv6 datagram would need 6.

The chance of losing a single datagram increases each time I split it.
Some erasure coding protects against this: adding an extra frame or two
isn't going to hurt much, and will hurt less than re-sending the entire
datagram.

> Particularly for Amateur use, I think it's important to have a written
> protocol specification, rather than basing on-the-air protocols on
> particular code.  zfec may well be based on a specification, so I would
> encourage you to find it (or write it) and then write code for other
> platforms.
> 
> Actually, my comment about protocol specifications applies to
> tahoe-lafs, too.  Right now we seem to be in the situation where the
> protocol is defined by how the code behaves.

I can try but I won't promise anything.  I take it the actual ZFEC
algorithm is entirely described by the C code and that the Python API is
just a high-level wrapper?  (i.e. I should look at zfec.c/zfec.h as my
starting point?)

Regards,
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.