[nos-bbs] A.X25 then, A.IP now ??? - thinking outloud (fwd)

Fri Jun 23 10:42:31 EDT 2006

Hey Maiko - you have a golden idea.
I'll see your "A.IP" and raise you one "A.?"
(That's poker talk?)

On Thu, 2006-06-22 at 11:40 -0500, maiko at pcs.mb.ca wrote:

> A bit of history first, to give you all an idea of where I'm leading ...

A bit more brief history to put spin on where I'm coming from (open to
accuracy checks):

X.25 began with the need to transport text packages across a network.
We grabbed the idea in ham radio and made it into AX.25 to satisfy RF
needs.
This has survived and expanded with IP encapsulation.
Throughout this process "overhead" remains a major issue with slow
speeds in some sectors of our hobby.

The DARPA folks found X.25 too limiting and introduced IP and Internet.
Earth shattering.
Recently, the address has grown from 32 to 64 bits and we can now
address more than whole earth.
And all this happens in a world of "blinding speeds" of fiber optics and
like technology.
Even the $ guys have grabbed on and US congress is struggling with
"neutral Internet" concepts.

> 

>SNIP<

> 
> That probably explains why packet radio (A.X25) grew on me.

It grew on me too - different history handled elsewhere.
Our hobby seems to work "best" in parallel with Internet, so your
"switch" concept is a key component.
Like a firewall it needs Internet connectivity, content management, and
ham usefulness to enable RF content transport.

> 

>SNIP<

> 
> Here's the main point I want to bring up !
> 
>  In the amateur radio field, A.X25 (packet radio) was created from
>  the X25 specification. I'm surprised that no one has come up with
>  an A.IP (ip over radio) spec to parallel the industry movement from
>  the X25 protocol to the IP protocol. Or has someone brought it up ?

The world is too big for me to understand if A.IP has hit the streets
anywhere in any form.
Here is where my view diverges from yours a bit - 
A.IP enables ham radio transport of TCP/IP traffic.
A.?  enables ham radio transport of (any?) traffic.

> 
> When things settle down, and winter starts, one of my projects is
> to perhaps implement an A.IP protocol (actually nothing more than
> raw IP with a SOURCE CALL and maybe ONE DIGI field). The nature of
> IP really only requires us to id ourselves I would think. That should
> make it legal, right ?

Simple & straight forward - most certainly.
Legal - most probably.
Yet do evaluate it in overhead bytes passed per ID cycle (ten minutes?)
requirements.
The gain with A.IP is to drop the AX.25 portion of overhead?
What % gain does that math demonstrate? [That's a rhetorical question -
I'll do the math for myself later]

> 
> Implementing it would be very easy. I should think we could continue
> to use EXISTING tncs, running either KISS or SMACK firmware, to make
> this work. KISS just delimits the data that the tnc is putting out or
> getting in, right ?

Perhaps - but the more important concept is that KISS passes decision
making from the TNC to the data processing computer.
KISS (etc) is a slick marketing tool to allow multiple application
environments for one hardware.

> 
> Of course A.IP would have to be on a dedicated non A.X25 frequency,
> unless there was agreement between the A.X25 spec and A.IP to have
> some type of flag at the very first byte of data.

I doubt it - A.IP traffic that passes KISS would be viewed as
non-qualifying-packets by AX.25.  
In other words QRM.
It may be degrading, but the decision is accurate.

> 
> Anyways, just some thoughts. It would be neat and alot more usefull
> with the modern days apps out there, to have literally raw IP going
> out and coming in a TNC. I think so anyways ...
> 
> I'd like to have comments on this, what do you all think ?

I'm in accord with your desire to create an RF path in ham radio for
digital content, and to that end I will place my energies behind such a
project.
I'm convinced that a new protocol can preserve existing architecture
like KISS while at the same time reduce overhead below existing levels.
I'm satisfied that hams are best served by one ham-only standard to
carry multiple existing protocols over RF paths.

For example - AX.25 includes ham calls into the overhead on each packet
to satisfy FCC call ID needs.  Yet in the US only once in ten minutes is
required of any transmitting station.  Consider for a moment what many
operating systems do for holding "temp" file data / they invent names
based on random numbers.  My contention is that a random 16bit (maybe
32?) number together with an intelligent switch can satisfy all ham
routing needs over RF.  Further, it matters little if the originating
protocol is X.25, AX.25, TCP/IP, A.IP, SCS-anything, or other, viewed
from the perspective of listening to RF in any band allocated to ham
use, the overhead of any protocol may be stripped before transmitting
and reinserted after receipt to complete a link using the 7-layer (maybe
less) model for net transport.

Today is not the day to argue the merits of random numbers, but only to
frame the environment into which a new protocol might fit.  It is my
request of you to consider more than TCP/IP in framing your objectives.
Also - it is only a request.  I do understand the utility of A.IP and
the attractiveness of taking smaller steps toward a larger goal.
Therefore we will all be better off no matter how you proceed.

If there is a way I can contribute to your project, please call.

> 
> Regards,
> 
> Maiko Langelaar / VE4KLM
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs

73
de Skip k8rra k

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20060623/8b147d06/attachment.html>