[aprssig] Protocol translation - please no.

[Andrew P.]

Hi, Hessu.

I understand your concerns. Considering the redundant ways to express information in APRS (for example, 8 different message types [4 text, 4 MicE] for sending station positions, with 3 different encoding schemes for 4 of the types [plain text, plain text with DAO extended precision, compressed]), versus the standardized encoding in OpenTRAC, that alone would make it impossible to encode an APRS message into OpenTRAC and then convert it back accurately to its original APRS format. So, two translators that were out of direct contact with each other could create a loop if the APRS-to-OpenTRAC re-encoding of the degraded APRS->OpenTRAC->APRS message wasn't identical to the previous re-encoding (i.e., stable degradation).

I was assuming that:

a) OpenTRAC and APRS would not be transmitted on the same frequencies, so the translator would be functioning as a cross-frequency repeater;

b) the APRS-IS backbone would never carry native OpenTRAC packets (a separate backbone would be needed to carry the different binary packet format).

But you're right; a loop could still occur if two translators were "back-to-back" in the network (either over RF or via I-Gates on the APRS side), because translator#1 wouldn't recognize that the output of translator#2 was a previous input to translator#1 (even without the other issues you mentioned of digipeater/I-Gate mangling of packets).

Drat.

If stable (deterministic) degradation did occur, would this work if the translator checked for duplicates on the transmit side (i.e., if the packet translated to something already sent, don't re-send it) in addition to receive-side dup checking? Would it make sense to mark packets (at least on the OpenTRAC side) as having been translated so they wouldn't be translated back (i.e., an OpenTRAC translation or network relay flag attribute)?

Oh, well, nice idea while it lasted.....

Andrew KA2DDO

> Date: Wed, 26 Jun 2013 08:36:31 +0300
> From: hessu at hes.iki.fi
> To: aprssig at tapr.org
> Subject: Re: [aprssig] Fw: APRS-B? Protocol translation - please no.
> 
> On Tue, Jun 25, 2013 at 4:30 PM, Andrew P. <andrewemt at hotmail.com> wrote:
> > Would there be interest in a protocol-translating OpenTRAC-to-APRS digipeater (working both ways)?
> 
> Such digipeaters have been problematic before, and I would recommend
> to be very, very cautious about it. In the past there were some
> digipeaters which converted mic-e packets to plain APRS packets so
> that clients not understanding mic-e could receive mic-e packets.
> Sounds like a great idea, right?
> 
> The obvious problem is that then we had two different variants of the
> same packet on the network, which would both proceed through duplicate
> packet checking (different data contents: unique packets). Immediate
> double traffic on the channel.
> 
> The next problem is that when the protocol capabilities differ, you'll
> have degrade the packet contents, leave some fields out. And then you
> can't restore them when converting back to the original format.
> 
> You'll also soon have more than one variation of the translation,
> either due to you improving your converter, or another programming
> implementing a slightly different algorithm, or somebody using
> slightly floating point or integer data types and getting slightly
> different rounding for coordinates or speed, or something like that.
> Again, packet contents are going to be different, and duplicates will
> be hard or impossible to avoid.
> 
> Some systems (like my aprs.fi) are going to receive both the degraded
> translated versions and original packets, causing additional work to
> figure out how to discard the translated ones.
> 
> I would very strongly support improving network level elements
> (digipeaters, igates and such) to the direction where they keep the
> transported packet content as intact as possible, and leave content
> encoding/decoding to the endpoint applications. That would be a real
> improvement and better allow further protocol improvements. Currently
> a bigger problem is that digipeaters and igates corrupt packet
> contents, remove whitespace or modify unprintable characters.
> 
> The Internet works great, and new applications have been easily
> developed on top of it over the years, largely due to the fact that IP
> routers do not care what is inside the packet. We should follow the
> same approach.
> 
> - Hessu, OH7LZB
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20130626/21687332/attachment.html>