[ax25-layer2] 7-byte address proposal

[Samuel A. Falvo II]

On 8/1/06, scott at opentrac.org <scott at opentrac.org> wrote:
> I've been meaning to jump in, but haven't until now due to lack of time.
> Briefly... OpenTRAC's pretty compact and consistent.  I think some issues
> with element association need to be resolved before it sees wider
> deployment, though.  It needs to be possible to easily parse an OpenTRAC
> stream into an XML equivalent, with the nesting of the tags clear and
> orderly.  But it's a good start as-is.

I do not know what OpenTRAC is.

> As for AX.25... I guess my main question is, why stick with AX.25 at all?

Because it blows the ever-loving s--- out of TCP/IP over a noisy
connection.  TCP's end-to-end handshaking is death for noisy
connections, where hop-to-hop is overwhelmingly superior.  TCP becomes
utterly useless (to the point of connections closing due to timeouts)
with only 10% packet loss.  TCP also is grossly bandwidth inefficient.
 TCP + IP imposes 40 bytes of header overhead on top of the HDLC
headers, and this is just for IPv4.  IPv6 is way, way more.

To demonstrate the reliability issues involved with TCP, consider the
case where a packet has to go through (say) 13 hops to reach its
destination.  But, it gets corrupted on the 12th hop, and the 13th hop
drops the packet.  TCP has to retransmit the packet(s) from the 1st
hop, thus wasting the bandwidth of all previous hops (since they
already passed the traffic flawlessly before).  Note that each time
you retransmit, you're introducing more opportunities for corruption
due to noise bursts.  The situation is increasingly aggrevated when
you consider that TCP ACK packets must arrive intact across the full
path too.

Implementing reliability at layer 2 is clearly and demonstrably the
better choice.  Remember, this is precisely why X.25 was invented --
transmission of frames over *lossy* telephone lines.  AX.25 inherits
X.25's reliability.  Note also that HDLC semantics (on which both X.25
and AX.25 are based on) are also used in satellite communications,
including those that transport IP frames.

> Even if the IP layer is tweaked to accommodate amateur requirements, it'd
> still be way easier to adapt existing stacks than to write an AX.25 stack

I personally beg to differ.  The only reason I haven't hacked the
Linux kernel yet is because it's thoroughly indecipherable -- some of
the worst C coding in existance from a maintainability point of view.
BSD's isn't much better.

Meanwhile, I find uIP to be substantially easier to grok, but even
here, it's tough!  It's also a woefully minimal network stack (but at
least it works).

> from scratch.  I'll probably have to do that myself in the next six months,
> and I'm not looking forward to it!

Then instead of working alone, why not work in conjunction?  As
reported earlier, I'm interested in writing an AX.25 protocol
implementation that is, in the same spirit as uIP, completely OS
independent, and thus, completely portable.  I'm actually going
through some paper designs for the software now.

-- 
Samuel A. Falvo II