Date: Sun, 31 Oct 93 04:30:00 PST
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #282
To: tcp-group-digest
TCP-Group Digest Sun, 31 Oct 93 Volume 93 : Issue 282
Today's Topics:
AMPR gateways on Internet
Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.
Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".
We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party. Your mileage may vary. So there.
----------------------------------------------------------------------
Date: Sun, 31 Oct 93 04:52:10 GMT
From: ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW)
Subject: AMPR gateways on Internet
To: tcp-group@ucsd.edu
>> I see a possible trend in gateways that is bothering me somewhat.
>> That is using a "wired/commercial" network to pass AMPR traffic
>> WHEN an existing AMPR circuit either exists or could easily be made
>> to exist.
>
>There are those who feel even stronger that NO wireline links are
>spiritually correct.
There's nothing wrong with a few wireline links here and there. A lot of
places just plain can't get packet connectivity for various reasons and they
have no choice.
>> Certainly there is no argument for many of the circuits - I.E.
>> Australia to the US etc.
>
>Range shouldn't be a qualifier.
This is a hobby and not enough development has occured to make reliable
24 hour links via ham radio yet. This is where the Internet comes in handy
until such links can exist.
>> The problem is when you have two adjacent areas within the US that use
>> gatewaying when an AMPR radio cicuit exists.
>
>Range shouldn't be a qualifier.
Multiple gateways in the same area seem to be for various reasons. It could
be for reasons such as development of a better packet network, maybe someone
runs just TCP/IP and doesn't support NETROM or AXIP links on the gateway (like
we do here in Detroit) and someone wants to do BBS forwarding when it's not
allowed, maybe they want to experiment with better ways of doing things on
packet (like Tim AA5DF wants to do). But personally if you really look at it
and do some investigating, it will almost always come down to a packet war
in that area and someone is power hungry and wants their name in lights rather
than the other guy. More systems on the air is not always better (almost every
case too), they have to be strategically located to be effective. Many people
don't care about what is there if they aren't the ones running it.
>> We are Amateur Radio and RF is our "thing".
>
The problem with technology today is that many expect instant
>gratification. "Speed is life." Some want to have real-time
>data exchange over great range. But the technology to me is
>amazing that we can send a message in less than one day just
>about anywhere on the amateur map. I don't really see a need for
>anything faster than this. Hams don't really have a real-time
>data requirement. If speed or emergency is the object, maybe RF
Now this I seriously disagree with. You may be happy with a day, but a couple
hours to get anywhere on the earth is totally unacceptable to me. That is
WAY TOO SLOW. Packet has been around long enough to be far far more advanced
than where it is today and many of us do other things with it than just
connect up to a local BBS to read messages. I DO have needs to have real-time
connectivity around the world right now. There are others that need it far
more than me too and they currently have applications requiring it. I know
people that are doing things like running X windows, NFS, and other protocols
using Unix systems over packet. Usually they are limited to just some local
folks on secluded frequencies, and since this is what they want to do, and
there will be others too, the need MUST exist for real-time connectivity.
Maybe you don't need it, but others definitely do.
>data requirement. If speed or emergency is the object, maybe RF
>to the nearest available wireline should be used. This is
This is what the gateways are for. We don't have a good enough network right
now, so we hitch a ride on someone elses.
>> I am contemplating setting up a gateway. It will be my policy if and
>> when I do, to NOT pass traffic to areas which can be reached by RF.
>
>By inserting a wireline node into the system, no matter what the
>reason, you have decided that RF is not capable of meeting your
>needs and a crutch is needed to fill the gap. You could come up
Here's what I found about setting up a gateway. Packet can be unreliable
due to it being a hobby. Packet wars have a habit of taking complete networks
down too. When the hamgate went up here and the convers was linked it, people
flocked from all over the place just to connect to it. I see people connecting
over packet from New York, through Canada, to Detroit just to get on the
convers. We cover (entirely over packet too) the entire East half of Michigan,
a good portion of Ontario, Northwest Ohio, and Northeast Indiana. All of these
people want to work on links now to Detroit ever since the convers showed up.
Sometimes if you don't have a decent packet network all you have to do is
provide some kind of application that blows about everything else away (the
world-wide convers network is kinda like this) and people will suddenly want
a better packet network developed just so they can use that application. But
you can't put in too many gateways though (like what Doug is worried about) or
people won't need the packet links anymore. Besides, we have another gateway
near Detroit too (in Ann Arbor), but even though it's there people still get
on packet to connect over to my side of town (by the Detroit gateway) rather
than using the hamgates. We are also working on a better packet link between
these 2 cities too even though they both have gateways.
>Steve N5OWK
Ron N8FOW
------------------------------
End of TCP-Group Digest V93 #282
******************************
******************************