[aprssig] APRS-IS and metadata

[Weston Bustraan]

Yes, I agree. Before we shove arbitrary data into packets, we need to step
back and ask what problem are we trying to solve and are there already
facilities in the protocol to do what we want?

It sounds like what is desired here is to understand network propagation
more thoroughly by gathering more information about the physical transport
layer. So, to draw a comparison to the "regular" internet, it sounds like
what you want to know is some statistics on what kind of network an IP
packet travels on. Or in other words, you want to know how many packets
travel via Wi-Fi vs Ethernet vs fiber optic, etc, but in this case, it
would be VHF vs UHF vs Lora?

Consider for a moment what this proposal would look like in TCP land? For
every TCP packet you would want to stuff some data about the Layer 2 Data
Link layer into the Layer 7 Application Layer? What happens when a packet
traverses several different kinds of data links, i.e it originates on Lora
and then is digipeated via VHF? Does the packet accumulate this "metadata"
all along the way?

We already have a (limited) version of this metadata, in the form of the
VIA path. Each hop is recorded in the packet.

I think Jason is on to something with the reference to ICMP and traceroute
tool. AX.25 packets already know what stations the packet traversed; if you
want to know what kind of link those stations represent, it could simply be
an APRS query to the IGate/digipeater. In this way, if you are doing
network propagation analysis, you only have to query the station once to
find out details, rather than adding bloat to every packet traversing the
network.

- Wes W8WJB


On Sun, Aug 20, 2023 at 11:10 AM Jason KG4WSV <kg4wsv at gmail.com> wrote:

> I understand the reasoning behind wanting the data, but I’ve gotta say
> this sounds like the mirror image of shoving application data down into
> layers 2/3 which resulted in a bit of a nightmare for APRS implementers.
> I’m not saying your proposal would be as problematic, but I will say I’m
> not sure it is the correct way to solve the problem.
>
> I think one place to supply this kind of data would be status text
> supplied by gateway devices themselves. Anyone interested in storing said
> data can pull it from the APRS-IS feed.
>
> What comes to my mind is the ICMP protocol that rides alongside IP to give
> use some basic data about the lower layers of the network stack
> (connectivity, latencies etc) that makes up our Internet infrastructure,
> usually via queries (using tools like ping or traceroute). My first thought
> is to put that work onto the LoRaGate by crafting queries using the APRS
> messaging protocol that the gateway would respond to, perhaps in addition
> to regular status text by the gateway.
>
> This approach doesn’t require infrastructure modification except on the
> components you want to keep track of.
>
> Just some thoughts that I admit aren’t thoroughly thought out. :)
>
> -Jason
> kg4wsv
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20230820/6c97943d/attachment.html>