Hello everyone,
as part of the Irdest project [1] we are working on a LoRa driver for
long-range, low-power, low-bandwidth uses.
Lora was implemented with the goals of providing an ultra low power,
long range, radio link for IoT devices in free to access radio bands.
Lora is particularly suitable for use in the Irdest project as it will
enable our users to set up peer to peer radio communications without the
need for ground station infrastructure or the requirement for users to
be licensed radio operators.
LoRa, along with its accompanying de-facto link layer protocol, LoraWAN,
is governed by the LoRa Alliance, with further restrictions enforced by
regional radio regulators. The unlicensed nature of the Lora band, and
its low power design goals unfortunately means that very little
bandwidth is available to peers operating in the LoRa band. To permit
fair and reliable access to the band limitations on Lora packet lengths
and radio transmit duty cycles. These restrictions are implemented at
the regulatory level.
Due to the variable bit-rate of the LoRa physical layer protocol MTU's
for Lora messages defined per region and bit-rate, to prevent the
broadcast of messages more than a few milliseconds to prevent a handful
of stations from tying up the entire band. In the best case Lora's MTU
is 242 bytes. In the worst case it is only 19 bytes. Lora operates at no
more than 27Kbit/s and most regions enforce station broadcast limits of
<1% duty cycle.
In the best case Lora radio environment in the case of attempting to
transmit a standard 1KB ERIS frame over Lora using reasonable framing
and the maximum permissible 242byte MTU, frame transmission would
require being split over 5 Lora Messages, which must be separated by (at
minimum) 2 seconds each. This would require at least 10 seconds to
transmit any Ratman message regardless of actual size.
These restrictions are built into the physical and legal layers of the
protocol, as such Irdest cannot bypass them. Because of this we must
request a modification to the ERIS spec.
Currently ERIS frames are padded to the nearest 1K block size before
encrypting. We wish for smaller power of 2 padding options of 512, 256,
128 and 64 bytes be made available at the point of packet construction
or later slicing, to allow for us to make efficient use of the limited
radio spectrum available to us. With this change it will be possible for
Irdest to offer medium to long range fully encrypted mesh networking for
simple communication payloads to anyone without the requirement of using
licensed radio bands.
Cheers,
- Katharina Fey
- Lauren Brown <SEGFAULT>
[1]: https://irde.st
Hi!
I'm a keen follower of the Irdest project and personally interested in
LoRa. Thanks for your mail!
Katharina Fey <kookie@spacekookie.de> writes:
> In the best case Lora radio environment in the case of attempting to
> transmit a standard 1KB ERIS frame over Lora using reasonable framing
> and the maximum permissible 242byte MTU, frame transmission would
> require being split over 5 Lora Messages, which must be separated by
> (at minimum) 2 seconds each. This would require at least 10 seconds to
> transmit any Ratman message regardless of actual size.
What is the relation between ERIS blocks and Ratman messages?
Just to clarify terminology: We don't use the term "frame" in the ERIS
specification. I assume that by frame you mean some content that is
padded by ERIS to block size (1KiB or 32KiB).
> Currently ERIS frames are padded to the nearest 1K block size before
> encrypting. We wish for smaller power of 2 padding options of 512,
> 256, 128 and 64 bytes
64 bytes will not work as in order to be able to build a tree a ERIS
node needs to hold references to at least two children. A reference to a
child node has size 64 byte. With block size 64 byte we will not be able
to encode content larger than 63 bytes.
Also, ERIS encodes some arbirtrary sized content into uniform sized
blocks (currently all either 1 KiB or all 32 KiB) and a read capability
that can be encoded into 66 bytes (or as a URN). In order to decode the
content one needs access to all the blocks AND the read capability.
So to transfer some content smaller than 64 bytes you would need to
transfer 64 bytes of block plus and additional 66 bytes for the read
capability. That's an overhead of over 100%. The argument holds for any
small block sizes with relatively smaller, but still considerable,
overhead.
Security-wise there is also an argument against small block sizes (or
small pieces of content in general). When using convergent encryption
and when the entropy of the encoded content is low, an attacker can
potentially learn the content by simply brute-forcing. This is known as
the Learn-The-Remaining-Information Attack [1;2].
Finally, the block sizes in ERIS were chosen based on common sizes of
content. 32 KiB for large content and 1 KiB for small pieces of
meta-data or annotations. The goal of ERIS is to make such content
available robustly over many transport protocols. ERIS also provides
identifiers for content that are stable over transport protocols and
applications. Using different block sizes for the same content results
in multiple identifiers for the same content. I don't think content
identifiers should be subject to fluctuations at the transport layer.
Imho, a valid argumentation for a smaller block size would be more along
the lines (just an example - It might not make any sense with respects
to Ratman): "Ratman routing tables are encoded with ERIS as they persist
for many hours/days and having persistent identifiers as well as the
ability to distribute them content-addressably (and possibly using other
non-Irdest transports) is important. However, for the most common sized
networks the routing table is about 500 bytes large. It's a considerable
overhead to use almost 100% padding - an ERIS block size of 512 bytes
would be an optimization for such a case."
I think it would be good to understand better how you are using ERIS in
Irdest/Ratman.
Cheers,
pukkamustard
[1] http://purl.org/eris#name-known-attacks-on-convergent
[2] https://tahoe-lafs.org/hacktahoelafs/drew_perttula.html