[aprssig] Ideal Digipeater Behavior

[Kenneth Finnegan]

So I've been working on refactoring the Aprx digipeater engine, and I've
come to realize that I can't find any good body of examples of "packet in
-> packet out" behavior for the modern APRS digipeater. Being unemployed
this month, I decided to sit down and write something:

https://github.com/PhirePhly/aprs_notes/blob/master/digi_behavior.txt

Needless to say, I found it educational to try and write down all the
examples of a digipeater modifying a path.  I encourage everyone to read
the linked text document and reply quoting any in -> out pairs of
concern/confusion/disagreement.

A couple questions which I already have:

* The two places where the preempt RR bit is documented disagree with each
other. I think RR-bits.txt is correct.
http://www.aprs.org/aprs12/preemptive-digipeating.txt
http://www.aprs.org/aprs12/RR-bits.txt

* How should we be punishing excessively long paths? Drop the packet?
Digipeat it with all the hops consumed (my personal favorite)? Or Digipeat
it with the requested hops reduced to the local maximum? (This last one can
get pretty hairy to program for stuff like WIDE2-2,WIDE2-2,WIDE2-2)

* How should we punish malformed aliases? (i.e. WIDE1-2, WIDE2-3, etc)
Reject the premise and treat them as WIDE1-1,WIDE2-2, etc? Stop harping on
a dead concept and treat everything as WIDE1-1 or WIDE(!=1)-N?

* Should high level digipeaters preempt WIDE1-1 aliases? WIDE1-1,WIDE2-1
would then become WIDE1-1*,DIGIA-1* instead of DIGIA-1*,WIDE2-1

* Similarly, should digipeaters preempt to their callsigns in favor of any
aliases?

* When would we ever not want preemptive digipeating?

* Should the max hop count be configurable per alias in a digipeater
config? Do we still want to support the SS7-7 pipe dream? I'm out in
California so I really can't tell.
--
Kenneth Finnegan, W6KWF
Aprx maintainer
http://blog.thelifeofkenneth.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160824/54f655a2/attachment.html>