Policy paper
3 views
Skip to first unread message
Bruce Perens
Mar 12, 2026, 3:28:21 PMMar 12
to emergency_co...@perens.com
Stuart Longland
Mar 12, 2026, 3:51:08 PMMar 12
to emergency_co...@perens.com
On 13/3/26 05:28, Bruce Perens wrote:
> https://github.com/BrucePerens/emergency_communications/blob/main/README.md
>
That policy seems fair.
I wouldn't rule out Winlink interoperability outright, there are still
times where it may in fact be useful, but I'm not going to prioritise it
either. End goal in my mind is to have a distributed, open system that
other systems can be linked into as need dictates.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
> https://github.com/BrucePerens/emergency_communications/blob/main/README.md
>
That policy seems fair.
I wouldn't rule out Winlink interoperability outright, there are still
times where it may in fact be useful, but I'm not going to prioritise it
either. End goal in my mind is to have a distributed, open system that
other systems can be linked into as need dictates.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
Bruce Perens
Mar 12, 2026, 4:13:11 PMMar 12
to Stuart Longland, emergency_co...@perens.com
Feel free to contribute additions, either as git pulls or just email.
--
You received this message because you are subscribed to the Google Groups "emergency_communications" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emergency_communic...@perens.com.
To view this discussion visit https://groups.google.com/a/perens.com/d/msgid/emergency_communications/20a7d716-e1ba-42eb-b591-785c50746971%40longlandclan.id.au.
Bruce Perens K6BP
Greg Troxel
Mar 13, 2026, 10:09:12 AMMar 13
to Bruce Perens, emergency_co...@perens.com
The policy document leans hard to both geographic routing (while not
really addressing geographic naming or the use of coordinates, including
the related privacy/OPSEC issues) and something that feels like link
state but over a longer averaging interval (e.g. if you check in once an
hour you are connected). That is broad brush, but I think it's a
sensible path.
I don't see any discussion of mobility. That bears on geographic names
if physically large. The other kind of mobility is changes in
connectivity topology. In general, one needs control traffic that is
fast enough to handle mobility, and slow links and high mobility don't
work well.
An interesting concept is "hazy-sighted link state", originally written
about in the context of connected networks. The core concept is to send
link state updates (rather than synchronize), and to send updates k hops
with relative frequency 2^-k. This minimizes the air time taken up by
the sum of control traffic and extra hops due to suboptimal routes.
https://www.cesarsantivanez.com/papers/TM1301.pdf
Other things to keep in mind are the ETX and ETT (estimated
transmission count and time) metrics. The key observation (ETX) is that
the best way to choose which links to use (all the same speed), assuming
link-level acks, is to mimimize the expected number of transmissions,
since the scarce resource is air time. ETT extends that to minimize
channel occupancy time (all of transmission, ack, guard times) instead
of count, choosing among link speeds.
http://nil.lcs.mit.edu/rtm/papers/etx.pdf
I have used ETX/ETT in ad hoc networks and having had that experience,
would do it again.
73 de n1dam
really addressing geographic naming or the use of coordinates, including
the related privacy/OPSEC issues) and something that feels like link
state but over a longer averaging interval (e.g. if you check in once an
hour you are connected). That is broad brush, but I think it's a
sensible path.
I don't see any discussion of mobility. That bears on geographic names
if physically large. The other kind of mobility is changes in
connectivity topology. In general, one needs control traffic that is
fast enough to handle mobility, and slow links and high mobility don't
work well.
An interesting concept is "hazy-sighted link state", originally written
about in the context of connected networks. The core concept is to send
link state updates (rather than synchronize), and to send updates k hops
with relative frequency 2^-k. This minimizes the air time taken up by
the sum of control traffic and extra hops due to suboptimal routes.
https://www.cesarsantivanez.com/papers/TM1301.pdf
Other things to keep in mind are the ETX and ETT (estimated
transmission count and time) metrics. The key observation (ETX) is that
the best way to choose which links to use (all the same speed), assuming
link-level acks, is to mimimize the expected number of transmissions,
since the scarce resource is air time. ETT extends that to minimize
channel occupancy time (all of transmission, ack, guard times) instead
of count, choosing among link speeds.
http://nil.lcs.mit.edu/rtm/papers/etx.pdf
I have used ETX/ETT in ad hoc networks and having had that experience,
would do it again.
73 de n1dam
Reply all
Reply to author
Forward
0 new messages