[aprssig] Ideal Digipeater Behavior

[Kenneth Finnegan]

>
> IMO all this is ridiculous. At best it will be partially implemented and
> the results will be useless.  Just like existing attempts at route tracing
> are at best unreliable, because there is no standard implementation and
> much of the OTA infrastructure is built on prehistoric hardware that won't
> get changed.


K... well there's now a bunch of us building digipeaters on Cortex ARM
cores or full Linux SBCs getting pretty frustrated that most of the
digipeater behavior documentation out there is a list of settings for
UNPROTO and BTEXT and whatever fields, which mean nothing to us youngins
who have never seen a TAPR TNC2.  I'm trying to move past all the
prehistoric infrastructure that exists and give us a better tool to frame
the future conversations on what behavior is right and which isn't.

you DON'T punish. You don't drop a packet out of spite.  If you find
> yourself using word like "punish", your next move will _not_ be a good
> network design decision.
> Feel free to fix/truncate/rewrite it to the locally acceptable maximum hop
> count path.


So I've got you down as one vote for "Punish by reducing the requested hops
to maxhop."

Perhaps punish is a bad word choice. Unfortunately, the term "QoS drop"
seems to also be a dirty word to many APRS elites.

Think about an IP TTL.  It will probably leave your system at 255, but the
> first router it passes through may drop it to 127 (I think I've seen that
> particular scenario). It most certainly would not be configured to drop the
> packet


I have most certainly never seen that scenario. RFC791 let you reduce TTL
by the number of seconds (LOL) it took you to process the packet, but
that's the only reference to anything except for TTL = TTL - 1 that I've
ever seen.

It's funny that you bring up IP TTL, because comparing APRS to how the TTL
field was meant to be used for multicast routing is very interesting.

when we get a real layer 3 network instead of this inconsistent patchwork
> of hacks? And creating such a thing would, IMO, be _easier_ than dealing
> with the hacks.
> [rant for a real APRS network deleted.  check the archives, i'm sure i've
> made it more than once.]


I am well aware of your incessant ranting on the topic. I downloaded the
APRSsig archives and read a large chunk of them for my thesis, so I've
gotten to read your rant MANY times. I've also gotten to read many other
rants on the topic in the last day in reply to my original email off-list.

When are you guys going to start actually building something and not just
discourage those of us trying to get something done? Go pick a new packet
frequency and let us know when you've got a working prototype of whatever
comes after APRS.
--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/

On Thu, Aug 25, 2016 at 7:42 AM, Jason KG4WSV <kg4wsv at gmail.com> wrote:

>
>
> On Wed, Aug 24, 2016 at 7:41 PM, Kenneth Finnegan <
> kennethfinnegan2007 at gmail.com> wrote:
>
>
>> * 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
>>
>
> IMO all this is ridiculous. At best it will be partially implemented and
> the results will be useless.  Just like existing attempts at route tracing
> are at best unreliable, because there is no standard implementation and
> much of the OTA infrastructure is built on prehistoric hardware that won't
> get changed.
>
>
>> * How should we be punishing excessively long paths
>>
>
> you DON'T punish. You don't drop a packet out of spite.  If you find
> yourself using word like "punish", your next move will _not_ be a good
> network design decision.
>
> Feel free to fix/truncate/rewrite it to the locally acceptable maximum hop
> count path.
>
> Think about an IP TTL.  It will probably leave your system at 255, but the
> first router it passes through may drop it to 127 (I think I've seen that
> particular scenario). It most certainly would not be configured to drop the
> packet.
>
>
>
>>
>> * When would we ever not want preemptive digipeating?
>>
>
>
> when we get a real layer 3 network instead of this inconsistent patchwork
> of hacks? And creating such a thing would, IMO, be _easier_ than dealing
> with the hacks.
>
>
> [rant for a real APRS network deleted.  check the archives, i'm sure i've
> made it more than once.]
>
> -Jason
> kg4wsv
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160825/def1f2f6/attachment.html>