Date: Sat, 13 Nov 93 04:30:02 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 #295
To: tcp-group-digest
TCP-Group Digest Sat, 13 Nov 93 Volume 93 : Issue 295
Today's Topics:
Ham Emergency Service 20 Years From Now (3 msgs)
My apology
On the merits of KISS (4 msgs)
RDATE Server on the Internet
Three Things (3 msgs)
three things....
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: Fri, 12 Nov 93 15:23:21 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Ham Emergency Service 20 Years From Now
To: bob@ke9yq.ampr.org
I fully agree with Bob -- amateur radio's relevance to emergency
communications has been rapidly decreasing ever since the invention of
the cellular phone, and it will continue to decrease.
Amateur radio's chief remaining contribution will be educational.
It's a chance for people to learn about communications technology
through hands-on experience. This is still something that comes in
handy during an emergency.
Phil
------------------------------
Date: Fri, 12 Nov 93 17:44:11 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Ham Emergency Service 20 Years From Now
To: john@its.bt.co.uk
>needed...Why, because no matter what capacity was installed, it was just
>not sufficient to cope with the traffic. Its not the bandwidth which amateurs
>supply that is important, its the way in which its used. Public channels are
>just that and every man and his dog will try to use them. Hams carried
>essential messages because the regulated net provided an environment in
>which transmission was guaranteed. In 20 years time, I don't think things
A typical cellular site can carry a lot more simultaneous traffic than
a typical amateur repeater site, even for the present analog systems.
The new digital systems (i.e., ours) will do even better, by a factor
of 10-15x.
And the access protocols for cellular systems are pretty stable under
load, unlike most of those in ham radio. Sure, there's no guarantee
that you'll get through when you hit the SEND key, because you can't
carry more calls than you have channels. But you can hit the SEND key
all you want without bringing down the users who are already talking,
unlike those "helpful" hams who can't stay off the PTT switch in an
emergency.
And we all know how well conventional AX.25 works under heavy loading.
The telcos have implemented congestion control techniques for
emergency use that actually work quite well. Probably best known is
the blocking of incoming traffic to keep trunks clear for outbound
traffic. This worked very well after the Loma Prieta earthquake;
although it was almost impossible to call into the Bay Area, my friend
Patty had no trouble calling me on the east coast several times that
night. Since one call out of an emergency region can often take the
place of several calls in (the outbound call is much more likely to be
completed, and the information carried can be more easily passed on to
others), this is a good policy.
Hams like to think of themselves as somehow more reliable in
emergencies than commercial services. Even if this was true at one
time (possible), hams have stayed almost static in technology for the
past 25 years while the commercial world rushes on.
Phil
------------------------------
Date: Fri, 12 Nov 93 20:42:27 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: Ham Emergency Service 20 Years From Now
To: MUSCHINSKE%39A.decnet@sunman.chinalake.navy.mil
>Just imagine 20,000 people trying to access Iridium simultaneously! :-}
Just imagine 20,000 hams trying to access 146.34/146.94 simultaneously.
>Also, how many of these cellular sites are linked via light pipe? They
>tend to break just like water and gas pipes.
Many of the cell sites I've seen (though not all) have microwave dishes
halfway up the tower for the backhauls to the MTSO. And if one cell goes
down, you can often use a neighbor as the service areas usually overlap.
Phil
------------------------------
Date: Fri, 12 Nov 1993 17:08:36 -0100 (GMT-1:00)
From: andy@mimuw.edu.pl (Andrzej K. Brandt)
Subject: My apology
To: tcp-group@ucsd.edu
Hello,
I was two times asking lame questions on this group, and someone (don't
remember the name, sorry) told me, that I have already the best docs - the
sources - and that's where I should look for my answers. I took that advice,
and I should have done this first. Now I know what I wanted to know. I got
Phil's sources to compile and run (not so hard as I first thought), I even
added what I needed to add (encrypted encap) and I'm all happy...
Once more, sorry for asking questions without looking in the sources first.
--
73 de Andy SP5WCA
/-------------------+--------+-------------------+-------------------------\
I Andrzej K. Brandt I SP5WCA I andy@mimuw.edu.pl I sp5wca@sp5pbe.wa.pol.eu I
\-------------------+--------+-------------------+-------------------------/
------------------------------
Date: Fri, 12 Nov 1993 07:44:51 -0600 (CST)
From: Steve Sampson <ssampson@sabea-oc.af.mil>
Subject: On the merits of KISS
To: TCP-Group@UCSD.Edu
iiitac@pyramid.swansea.ac.uk writes:
>2. A SLIP TNC is overkill. Far more effective would be a DOS packetdriver akin
>to etherslip but doing etherax25 conversions. This would entail squashing
>ax.25 calls to 6 byte addresses (code is in the sun ax.25 driver already)
>and prepending AX.25 headers and LAPB UI followed by a protocol byte of either
>IP or ARP.
This is a kludge. AX.25 belongs in a box, not on the end machines. As others
have mentioned, the SLIP protocol is part of many TCP/IP packages. The only
reason that everyone puts AX.25 into NOS is that it's easier that way. That
is, writing code for a 640k PC Clone is easier than writing for a 64k Z-80.
But many are migrating to more powerful Operating Systems and re-implementing
AX.25 everytime is a not the best way to proceed.
>For someone with reasonable PC assembler skills (not me!) I can't see this
>being a horrific job.
Well I don't think any assembler code is needed on a PC, but certainly would
be useful for the Z-80 TNC. With the public domain C compiler for the Z-80,
I think it would probably do the job, as the Rose TNC code (TheNet probably
also) uses it for most routines.
---
Steve
------------------------------
Date: Fri, 12 Nov 93 15:36:15 GMT
From: Alan Cox <iiitac@pyramid.swansea.ac.uk>
Subject: On the merits of KISS
To: TCP-Group@UCSD.Edu, ssampson@sabea-oc.af.mil
I strongly disagree that it's a kludge. Why pay large amounts of money for
a tnc with its own processor (least of all a Z80 and all the other junk
instead of a 68HC11) when you should have your stack on board your pc as
a driver and programs able to use it.
I suppose the tcp/ip stack should be on your ethernet card too ?
The whole TNC buisness is a nasty piece of history. The TNC is the single
biggest obstacle to decent amateur comms.
In addition the SLIP idea is badly thought out and won't work very well.
SLIP is point to point - many kernels know this. SLIP has no provision
for setting TNC parameters. SLIP has no broadcast address.
Alan
------------------------------
Date: Fri, 12 Nov 93 11:54 PST
From: bruce@pixar.com (Bruce Perens)
Subject: On the merits of KISS
To: Steve Sampson <ssampson@sabea-oc.af.mil>
I disagree with your statement that AX.25 belongs in a "box",
presumably some firmware device outside of the computer like a TNC.
This assumes that we want to cast AX.25 in concrete. It is more likely
that we will discard it - there are better protocols with forward error
correction for HF, and for VHF TCP/IP users most of AX.25 is simply not
necessary.
Are you proposing to replace KISS with SLIP simply by deleting
the command byte, or by somehow performing AX-to-IP translation in the
TNC firmware? If it's the latter, I'll have that code in RAM, please - I
am constantly frustrated by buggy firmware that is difficult to change.
I have a TAPR 9600 board that I'm working on at the moment. This board
is a modem and (optional) clock circuit, and it plugs into a TNC which
supplies the HDLC chip and protocol firmware. I'm tempted to eliminate the
TNC entirely, and connect the modem to an SCC card on my PC's bus. That
way, I'll have all of the protocol software in RAM.
Bruce Perens KN6TH/AE
-
Bruce Perens KN6TH/AE Bruce@Pixar.com 510-215-3502
------------------------------
Date: Fri, 12 Nov 1993 16:04:43 -0800
From: brian@nothing.ucsd.edu (Brian Kantor)
Subject: On the merits of KISS
To: tcp-group@ucsd.edu
I'm using TAPR 9600 modems connected to DRSI cards in several places,
and no TNCs at all.
If you add a TAPR DCD state machine to a DRSI card, it makes a pretty
good 1200 bps/9600 bps dual interface for a PC.
It was my original intent to build a driver for the DRSI card in 386BSD
as well.
- Brian
------------------------------
Date: Sat, 13 Nov 93 02:15:05 CST
From: kf5mg@kf5mg.ampr.org
Subject: RDATE Server on the Internet
To: tcp-group@kf5mg.ampr.org
Does anyone know of a accurate or semi-accurate Time and Date server on
th
------------------------------
Date: Fri, 12 Nov 93 09:36:00 -0500
From: grebus@isis1.bxb.dec.com (Gary Grebus)
Subject: Three things
To: ron@chaos.eng.wayne.edu
>Date: Fri, 12 Nov 93 02:28:34 -0500
>From: us1rmc::ron@chaos.eng.wayne.edu (Ron Atkinson N8FOW)
>
> What about the backoff timers that are in NOS that aren't in various
>other TCP/IP programs? I too would like to run WinQVT, Linux, etc... over
>packet, but it's not designed for packet radio environment. That's part
>of the reason why people are putting NOS systems between their tnc's and
>their other TCP/IP programs.
In most cases it's because the TCP/IP implementation is hardwired to assume
Ethernet round-trip-times and reliability. Interposing a NOS system
as a router doesn't help much, since it's the endpoint that determines
the timing and retry behavior. At least one of the PC protocol stacks
(WATTCP) is distributed as source, so these problems might be fixable.
> Kinda curious, how does the AX.25 stuff for the Sun work? Does it
>work effectively in a heavily shared frequency like most major cities
>have to deal with? I know the way that pings are done in most Unix systems
>make it not very usable for packet and it seems to just key the transmitter
>for long periods of time.
I don't know about the Sun drivers. 386BSD and its derivatives allow
you to set an estimated round-trip time and mtu by route, which means
the same box can talk equally well over both Ethernet-only and
Ethernet-to-NOS-to-radio paths. It was also pretty trivial to make
a couple of kernel source changes to disable the retry-limit,
connection establishment timeouts, and "recalibrate" the backoff curve
a little. It runs fine in an environment with a reasonable number of
1200 baud hops, hidden transmitters, etc.
re: a TNC as an IP router
I think the latest version of TheNET X-1 supports SLIP out the serial
port. One drawback (I think) is that it can't do dynamic ARP...the
ARP table has to be maintained manually.
/gary
K8LT
Gary L. Grebus Voice: (508)264-5185
Digital Equipment Corporation FAX: (508)264-5014
grebus@bxb.dec.com
------------------------------
Date: Fri, 12 Nov 93 12:29:20 GMT
From: kf5mg@kf5mg.ampr.org
Subject: Three Things
To: tcp-group@ucsd.edu
I thought that the X1-H TNC had a NET/ROM port going out the RS-232 port...
not a SLIP port. I was under the impression that you could have NOS talk
to it if you said that it was a NetRom type TNC.
I was leaning towards an AX.25 Packet driver but as someone pointed out....
a SLIP TNC would support ANYTHING ( Operating System or Software ) that
supports a SLIP Link. That would probably be better in the long run.
Does anyone have any Public Domain Z-80 I/O routines? Those AND a Z-80 C
compiler might help someone port some existing SLIP code to a TNC.
73's de Jack - kf5mg ( running JNOS in a 735K - OS/2 2.1 Dos Box! )
Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14
AX25net - kf5mg@kf5mg.#dfw.tx.usa.noam - home (817) 488-4386
Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409
-------------------------------------------------------------------------
| "I am Homer of Borg.... Prepare to be assim.... oooo Donuts." |
-------------------------------------------------------------------------
------------------------------
Date: 12 Nov 1993 16:12:27 -0600 (cst)
From: jks@giskard.utmem.edu
Subject: Three Things
To: tcp-group@ucsd.edu
In reply to (Message-Id: <8318@kf5mg.ampr.org>)
> I thought that the X1-H TNC had a NET/ROM port going out the RS-232 port...
> not a SLIP port. I was under the impression that you could have NOS talk
> to it if you said that it was a NetRom type TNC.
Yahbut Jack!... the point was to leave NOS, NetWrong, etc. and just use other
apps over ax.25 ip link. It would not matter what software/OS is if the TNC did
the routing work! Be selfish! You could use your favorite TCP suite on your
favorite machine.
> I was leaning towards an AX.25 Packet driver but as someone pointed out....
> a SLIP TNC would support ANYTHING ( Operating System or Software ) that
> supports a SLIP Link. That would probably be better in the long run.
Brings up an answer to Alan (iitac.etc)... it aint dumb at all!... The slip
ought to be point-to-point twixt the tnc and the cpu box ONLY....
My thought would rather to let TNC translate SLIP, re-encapsulate packet as ip
over ax.25 and go!... Since ur only using the IP part of X1j, you are relying
on some external routing intelligence, so you dont have to establish a bunch of
virtual circuits and worry.... get it to the next X1j node and hope the
network and gateways are up! This kinda game would be helped mucho by >9600b/s
links to prevent timeout.... but even as is... if stack and software work
ok over slip, they'll probably work ok at 19,200... some servers might gag...
but many wont. 1200 is another-whole-story.
73's
*********************************************************************
* Dr. John Spitznagel * Sancho Panza Institute *
* Internet: jks@giskard.utmem.edu * for Advanced Studies *
* AMPRNet: kd4iz@kd4iz.ampr.org * Department of Bogometrics *
* CIS: 76044,476 * *
* Tel: (901) 528-6441 * (C) JKS, 1993 *
*********************************************************************
------------------------------
Date: 12 Nov 1993 10:27:23 -0600 (cst)
From: jks@giskard.utmem.edu
Subject: three things....
To: tcp-group@ucsd.edu
I want to second John's remarks and add OS/2 TCP/IP and MacTCP to the list!!
Sorry about the 2 aborted messages.... For some reason the local mailer did not
ACK the UCSD.edu daemon and abended the message before the contents were
sent..... I did not even know that the note header got there until I got it
back twice!
Jack,
Team OS/2
*********************************************************************
* Dr. John Spitznagel * Sancho Panza Institute *
* Internet: jks@giskard.utmem.edu * for Advanced Studies *
* AMPRNet: kd4iz@kd4iz.ampr.org * Department of Bogometrics *
* CIS: 76044,476 * *
* Tel: (901) 528-6441 * (C) JKS, 1993 *
*********************************************************************
------------------------------
End of TCP-Group Digest V93 #295
******************************
******************************