Date: Wed, 24 Feb 93 04:30:15 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 #52
To: tcp-group-digest
TCP-Group Digest Wed, 24 Feb 93 Volume 93 : Issue 52
Today's Topics:
Atari NOS
Death of AX.25
FEC in amateur radio (2 msgs)
Fred and Lyndon Agree!
Further proposals for AX.25 Replacement
looooooooooooooooooooooooooooooooooooong messages
netlite & desqview freezes system
New AX25 (2 msgs)
New ax25? (6 msgs)
New ax25?, point-to-point links, radio bandwidth cost (2 msgs)
NOS & MSC under Windows NT?
Open Squelch SCC
physical layer and FEC engineering
Riff-raff and the internet? (3 msgs)
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: Wed, 24 Feb 93 00:43:40 +0100
From: Henk Peek <henkp@paramount.nikhefk.nikhef.nl>
Subject: Atari NOS
To: Mario.Illgen@Informatik.TU-Chemnitz.DE, john@its.bt.co.uk
>> Why not use PE1CHL's scc card for your system. I don't see the point in
>> re-inventing the wheel.
>>
>That's my problem, I'm still looking for the wiring of this card and (if it
>exists) the board layout. Are these informations available (and where)?
I have ibmpc OptoPcScc boards. By changing the pal and a jumper it
can be interfaced to a 68000 bus. A long time ago I have made a pal
for the atari, but isn't tested! Only you must wire the OptoPcScc board
to the atari.
73 Henk, PA0HZP
ps: documentation and schematics of the can be ftp'd from ucsd.edu:
hamradio/packet/tcpip/pe1chl/sccprin5.arc
------------------------------
Date: 23 Feb 1993 08:52:54 -0600 (CST)
From: Jeffrey Austen <JRA1854@tntech.edu>
Subject: Death of AX.25
To: tcp-group@ucsd.edu
fred k1io writes (about the transmission of station identificaton):
> But I'd also like to allow rule 2c as an option:
>
> 2c) If using forward-error correction, identify in FEC-encoded
> ASCII, using a published FEC algorithm identified in the
> station log, and, if necessary, per rule 1) above.
The only problem with this is that to determine which station made the
transmission it is necessary to know which station made the transmission
so that the station log can be examined to determine how to decode the
transmission in order to determine which station made the transmission....
Enough said?
Jeff, k9ja
------------------------------
Date: Tue, 23 Feb 93 06:45:26 EDT
From: "William Allen Simpson" <bill.simpson@um.cc.umich.edu>
Subject: FEC in amateur radio
To: Phil Karn <karn@qualcomm.com> (Phil Karn)
OK, I'm convinced. But the devil is in the details.
> packet and not bother sending the FEC overhead. But if the CRC check fails,
> you return a NAK (negative acknowledgement).
>
What about the hidden transmitter problem? How do we get the NAK? What
if the NAK is trashed?
Wouldn't it be better to *start* with the FEC, and back off if there are
not re-transmissions from the higher layers? It wouldn't be that hard
to maintain link state for the (relatively) few systems talking directly
to each other.
As an alternative, we could come up with a better set of Hello protocols
which contain Link Quality information. The RSPF effort has already done
some work in this direction. (I'm working on some drafts for the SIP
future IP effort, which incorporate some LQ information for mobile-ip.)
Bill.Simpson@um.cc.umich.edu
------------------------------
Date: Tue, 23 Feb 93 10:34:29 CST
From: andyw@aspen.cray.com (Andy Warner)
Subject: FEC in amateur radio
To: tcp-group@ucsd.edu (TCP Group)
Bill wrote :-
> Wouldn't it be better to *start* with the FEC, and back off if there are
> not re-transmissions from the higher layers? It wouldn't be that hard
> to maintain link state for the (relatively) few systems talking directly
> to each other.
Or better, back off the power until FEC started to kick in ? That
way you ensure that since you're carrying the FEC overhead
anyway, at least it's useful, and you've won because of the
lower power ( => better spatial reuse).
> [...]
--
andyw. N0REN/G1XRL
andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
------------------------------
Date: Tue, 23 Feb 1993 12:11:15 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: Fred and Lyndon Agree!
To: tcp-group@ucsd.edu
[ Fred, the DEC mailers are spitting some rather incredible, and very
unreplyable headers - I'm forwarding this to tcp-group manually ]
Said Fred:
> But that's "kiddiecomms" Message/BBS networking!
I dare you to walk up to the second floor here and shout that out in public.
> Ayuh! But as you see, we're actually nearly in agreement on what people
> need;
Horrors! :-)
> A quick synopsis of Waterloo TCP/IP, including FTP location if it's
> available that way, would be appreciated! I'm not sure how well known
> it is "south of the border". Thanks,
Available (in source form, maybe some binaries - I don't recall offhand)
from sunee.uwaterloo.ca:pub/wattcp/*. Includes the TCP and IP layers
plus a few basic clients (telnet, ftp, bootp). Not too whizbang but
it's a good start.
--lyndon (who just ordered 103 copies of BWNFS with 10BaseT cards to match :-)
------------------------------
Date: Wed, 24 Feb 93 10:57:03 +1100
From: wkt@csadfa.cs.adfa.oz.au (Warren Toomey)
Subject: Further proposals for AX.25 Replacement
To: tcp-group@ucsd.edu
------------------------------
Date: Tue, 23 Feb 93 09:30:14 PST
From: beacker@tomahawk.asd.sgi.com
Subject: looooooooooooooooooooooooooooooooooooong messages
To: jackb@mdd.comm.mot.com (Jack Brindle)
>Isn't it amazing that the simplest things can cause controversy...
That statement is one I can agree with...
>I fully agree with the request to compress things that are so long.
>What I disagree with is the method. It appears that the most universal
>compression system is unix compress. This utility has been implemented
>across almost all systems. Unfortunately PKZip has not. So, please,
>if the file you wish to send is real long, use compress first...
The thought that unix compress is the most universal is really
unix-centric. The largest population of computers on this planet is
the PC-Clone, and the package in use on that platform is typically
PKZip.
Now just for your information there are a pair of packages,
unzip and zip, available for Unix systems. These will do the same
thing that PKZip will do, and allow people to transfer between these
platforms. These packages are readily available from simtel20.
Brad Eacker (beacker@sgi.com KB6FED)
------------------------------
Date: Tue, 23 Feb 93 18:02:38 GMT
From: pa3cpl@pa3cpl.ampr.org
Subject: netlite & desqview freezes system
To: tcp-group%pa2aga@pi8nos.UCSD.EDU
Adam,
spijtig te lezen van je set en de inbraak. Dat is wel jammer zeg.
Wat extra sloten etc. misschien? Want ik vermoed dat je daar wel meer
van waarde hebt staan.
Hier mijn bericht, voor tcpdigest alleen als reactie adrs heb ik alleen
ax25 adres. Of zal ik harry zijn adres erbij zetten?
reply to harry@igg.tno.nl (Internet).
Hi,
I'm trying to get a network running on my system: netlite 1.1
After starting lsl, ne2000, client and server (loading high with
QEMM), and starting desqview everything runs OK for 1 to approx.
100 minutes, then it crashes/freezes ec.
Sometimes DV hangs and the server is still running OK.
I excluded the RAM-area from the ethernet card in the QEMM-
statement.
After 2 weeks of experimenting I'm desperate.
Do you know what's going wrong?
Anyone working with netlite, NE2000 and desqview, pse send
me your config.sys & autoexec.bat.
System: 486/33, 256k cache, 8Mb, dos5, newest versions of
qemm/dv.
thanks, aart pa3cpl @ pi8awt (ax25 net)
or via harry@igg.tno.nl
------------------------------
Date: Tue, 23 Feb 1993 07:31:19 -0700
From: dennis@nebulus.ampr.ab.ca (Dennis Breckenridge VE6TCP)
Subject: New AX25
To: tcp-group@UCSD.EDU
How about publishing the IP addresses with your local FCC/DOC. The addresses
have to be coordinated anyways. Just attach a callsign to them. Does this
not meet the criteria?
--
-------------------------------------------------------------------------------
Dennis Breckenridge VE6TCP I prefer group activity because, even if it's
dennis@nebulus.ampr.ab.ca foolish, at least I'm not the only fool.
-------------------------------------------------------------------------------
------------------------------
Date: Tue, 23 Feb 1993 09:23:14 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: New AX25
To: dennis@nebulus.ampr.ab.ca, tcp-group@UCSD.EDU
>How about publishing the IP addresses with your local FCC/DOC. The addresses
>have to be coordinated anyways. Just attach a callsign to them. Does this
>not meet the criteria?
Doesn't scale too well if you run a protocol other than IP.
------------------------------
Date: Tue, 23 Feb 1993 08:54:57 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: New ax25?
To: tcp-group@ucsd.edu
Lyndon N. comments about AX.25-like addressing in frames,
>But why stop at the upper layers? The picture I have is of people
>running emacs over the radio. (Sick, or what? :-) At that point linemode
yes :-) ---^
>telnet doesn't help. It is the nature of the application to generate
>little tiny one or two character data packets that need to get to their
>destination fast. Why should I delay transmission of a single character
>packet by a factor of eight (assuming 32 bit address fields) just so I
>can include some verbose addressing information that I don't necessarily
>need to operate over the link? (Yes, the above numbers are a bit flawed -
>I'm not taking header sync bits into account. If I do the X8 decrease
>is reduced somewhat.)
This is one of the problems with using words like "LAN" too close to
a radio. This is NOT a LAN! Radio bandwidth is expensive. The product
of range * speed is pretty much treatable as a constant; go beyond the
range of a WaveLAN and you've got to slow down. But echoplex minigrams
are an inefficient use of bandwidth. Even if headers were minimized,
radio has propagation delays, processing delays, turnaround delays and
just plain too little bandwidth to act like it's an Ethernet.
That's probably the reason why the "inferior" BBSs are still more
popular than TCP/IP over the radio! They're ugly, but they are based
on message switching, which is more efficient of bandwidth than IP.
Their use of AX.25 (broken Aloha) almost makes up for it (by screwing up
the channel so badly) but most ham IP has, sensibly, not tried to act
like it's on an Ethernet.
Variable-length addresses in frame headers are not a bad idea. The
overhead is small if you're not doing tinygrams, and they add
robustness to the whole system, among other things.
fred k1io
------------------------------
Date: Tue, 23 Feb 1993 14:52:19 +0000 (GMT)
From: markw@icsbelf.co.uk (Mark Willis)
Subject: New ax25?
To: makinc@hhcs.gov.au
>>[callsign compression]
>... but the question is really
>why? Is it worth the hassle writing this to save up to 32 bytes?
>Especially as higher speed networks are becoming more common. I personally
>don't think so however I can see this becoming a religious war. :-(
Great, we haven't had a good Jehad on this list since before christmas :-)
I agree, especially on higher speed nets. Even at 1200 more throughput is
"wasted" by p-persist, key-up delay, etc. At 56k I doubt if it make a
noticeable difference.
>You wouldn't have all of California (for example) known at this
>"sub-network" layer. Just the "subnet" for the area you are in and the
>gateway out. Routing information could be sent "on demand" and
>periodically as well (just like RIP or NETROM) and needn't be huge.
I was thinking of each router having a table containing every ax25 address it
has heard, but if the network is geared towards IP, and since we have numbers
allocated on (roughly) geographical basis then the problem wouldn't occur.
>> The other problem is that such a network might only be capable of routing IP.
>
>Why are they excluded? We have AXIP, we can pass AX25 over IP as a worse
>case, or we can provide gateways (such as Nos does now) into an IP network.
I had a temporary loss of upper cerebral activity...
>Broadcasts are also mandatory and if we are building a new protocol we
>might as well include things like multicasts in NOW!
yes, but this might be tricky:
net> multicast 44.*.*.* 'hello'
(I'm being a bit picky, but I do think that we need a new protocol to sit
between layers 2 & 3, and soon. I also believe it should run on cheap hardware.
Thats netrom's best point)
-mark
--
Mark Willis Internet: markw@icsbelf.co.uk
ICS Computing Group Ltd. UUCP: ...uknet!icsbelf!markw
Northern Ireland Packet: GI0PEZ@GB7TED.#63.GBR.EU
Belfast AmprNet: gi0pez@gi0pez.ampr.org [44.131.15.3]
------------------------------
Date: Tue, 23 Feb 1993 12:24:32 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: New ax25?
To: tcp-group@ucsd.edu
Lyndon N. writes,
>Are you saying on-screen editing should be limited to 3270 style block
mode operation? It will work but I wonder who's going to write the software.
Not too many machines support this any more.
Well, no. Note 3270-style block mode. But let's step back.
Both echoplex and 3270-style block mode are vestiges of time-sharing.
In both cases, a multiuser computer is shared among many users. Is
this the model we're looking for? Should a packet radio be a dumb
terminal? That's the fundamental error of the TNC! That's what the
TCP-group is about fixing!
We're all going to use COMPUTERS. Now these may be hand-held (HP95-size)
or large, but they have intelligence. So text editing is a local matter.
If I want to send mail, I should compose it on my favorite local editor
(I use SEDT for small things and MS-Word-for-DOS for books; you can
pick your favorite).
Kiddiecomms BBSs are, indeed, time-sharing systems, and so are RBBSs.
That's how they support the C-64s with the TNCs. That crew will never
upgrade their protocols. It's not even interesting to try.
But as a data link for "advanced" packet radio, the target application
should be computer-to-computer with minimized bandwidth demands. It's
a client-server world out there, or a peer-peer world, but not a
terminal-host world. Thus there will be tinygrams (one character to
read next message in newsgroup, or short NNTP messages) when that's
all the information to be sent, but we'll do more locally than a VT100
and we'll do it more intelligently than a 3270.
<set soapbox=off>
fred k1io
------------------------------
Date: Tue, 23 Feb 1993 11:23:03 -0800
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: New ax25?
To: goldstein@carafe.enet.dec.com
> While RBBSs are crufty, the plain fact
> is that they're currently more functional to most packet radio users
> than TCP/IP is!
Not TCP/IP, NOS.
> They support two key applicatons: E-mail and shared
> messages. TCP/IP has E-mail but we don't have a single simple standard
> BBS-like discussion board function in NOS.
Sure we do: NNTP + (pick your favorite NNTP client - see later).
> And indeed, you're probably making a big mistake! Novell's protocols
> may be "ugly" to an internetter, but they're remarkably effective.
In certain contexts, yes.
> If they weren't, how come Novell now owns the trademark "Unix"?
And if IBM had bought up USL would that suddenly sanction SNA? By this
line of reasoning, MS-DOS would be considered superior to VMS and Ultrix :-)
> usually comes with peer-to-peer applications (FTP, SMTP, Telnet) that
> don't fit in too well for most PC users, since PCs aren't generally
> capable of multitasking.
Well, looking at it from the applications layer I see a lot of users
who perform the equivelent to telnet and ftp in a single-tasking DOS
environment (using Procomm, Kermit, what have you).
> Sure you can run "PC LAN" software over a
> hidden IP layer (I do it myself sometimes) which provides router WAN
> access, but that's not the same as flushing Novell in favor of "TCP/IP".
Why is "PC LAN" software different from any other LAN software? Novell,
as a WAN, sucks. It doesn't scale well to large networks (I'm talking about
adding another 400 PC's to the network over the next year), and it doesn't
help me when people ask "how do I {email,telnet,ftp} to host mumble." We have
outgrown Novell, both in size and functionality, so we're replacing it.
Enough digression ...
I very much agree with you that client/server is mandatory for IP based
radio LANs. The biggest complaint I hear about NOS is that "you have to
leave it on all the time." Not totally true, but true enough. And the
"user interface" is abhorrent to the people I'm trying to get involved
in IP packet networking.
So what's the solution? Scrap NOS for the end-user! Right now I am working
on a packet driver that does AX25/KISS framing rather then Ethernet.
This driver, sitting under the "free" Waterloo TCP package, will give
an end user the ability to use DOS commands like telnet, ftp, mail, nn,
etc., in the way they are used to using other DOS utilities. And if you
don't like WATTCP, run your favorite GUI based commercial software instead.
If it'll talk to a packet driver, it'll run. NOS can continue to run as
a server, but I prefer to use it strictly as a router and run the actual
servers on more suitable systems (Unix for one). There is a very important
benefit to doing it this way: we can reuse *existing* application software,
thus freeing up our time for more important things like replacing Nove ...
er, AX25.
I briefly described this project at a packet meeting in Edmonton a month
ago. I had 15 people salivating within seconds, and these were die-hard
NOS hacks! To me, that says a *lot* about the current state of NOS. (Sorry
Phil.)
So, do we continue to try to pound NOS into the '90s equivlent of VM/370
for the desktop, or do we catch up with the times? I know which way
I'm going!
[ Hmm ... this thread sure takes a lot of turns, doesn't it :-) Fred, I
hope you aren't getting the impression I'm trying to flame you or anything
since that's not the case. ]
--lyndon
------------------------------
Date: Tue, 23 Feb 1993 12:57:04 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: New ax25?
To: tcp-group@ucsd.edu
Okay, Lyndon, you got me started!
Clearly we want to wean users away from cruft, but we can't always
support crufty old applications in the process. Still, we have to
support what users want to do. While RBBSs are crufty, the plain fact
is that they're currently more functional to most packet radio users
than TCP/IP is! They support two key applicatons: E-mail and shared
messages. TCP/IP has E-mail but we don't have a single simple standard
BBS-like discussion board function in NOS. So to just sit around and
read up on ARRL bulletins, rig modification notes, flames, or what-
have-you, RBBSs are better. Even though the protocols are putrid.
Now what I'm started on: Let's recognize that there are different
meanings of "network" for different people, and what works for one
doesn't necessarily work for another. End users perceive six categories
of network (per an article I have submitted for publication to a small
Canadian journal), in order of invention:
1) Telephony/circuit; 2) Terminal/host; 3) Message switching/BBS;
4) Internets; 5) PC/Server; 6) Switched-topology/ATM.
My latest kick is to take a user application and FIRST assign it to one
of these categories. It always works. Then the protocol is one that
fits that category.
>Right now I'm going through
>this exact scenario at work: migrating 130 people from Novell to IP.
>They don't give a damn how much better the protocol stack is, just as
>long as they can still run Word Putrid and the WP Orifice Shell.
And indeed, you're probably making a big mistake! Novell's protocols
may be "ugly" to an internetter, but they're remarkably effective. If
they weren't, how come Novell now owns the trademark "Unix"? They're
a certifiable money machine. The so-called "PC LAN" is very different
form an Internet (which could be IP, DECnet or OSI; it's defined by peer
to peer host operation). A PC LAN expects user client PCs to be dumb,
servers to be smart, and bandwidth to be free. Novell understands that.
Likewise its competitors, LAN Manager, Vines, etc. These "networks" are
purpose-built to support dumb PC users, and while Word Perverse isn't my
favorite WPS either, it's number one on the charts so somebody must like
it. (Actually, it benefits from momentum. My wife, for instance, uses
it not because she likes it but because it's what lawyers always use, so
they can exchange documents.)
Where does IP fit into this? To a PC user, a "LAN" is an application
(layer 7) entity, providing disk/file, mail and print services. The
underlying protocols are hidden from users, and mainly irrelevant. TCP
usually comes with peer-to-peer applications (FTP, SMTP, Telnet) that
don't fit in too well for most PC users, since PCs aren't generally
capable of multitasking. Sure you can run "PC LAN" software over a
hidden IP layer (I do it myself sometimes) which provides router WAN
access, but that's not the same as flushing Novell in favor of "TCP/IP".
Most PC TCP/IP seems to be aimed at Unix users with desktop PCs. That's
a tiny subset of the PC world. It's a lot of THIS group, but not the
zillions of folks who have poured billions into Utah's economy via both
Word Perfect and Netware.
I think Packet Radio fits poorly into both the Internet model and the
PC/Server model. Both assume too much bandwidth. It's more likely to
succeed if we leave it in the more primitive Message switching/BBS
model, which features non-real-time store and forward of messages
and real-time communication sans routers. Why? Because message
switching evolved during the days of 300 bps modems, and is thus most
efficient of bandwidth! And on radio, that's precious. The IP world is
salivating over 45 Mbps backbones. The PC/Server world is moving
towards Personal Ethernet. Radio is fighting ever-increasing pressure
on spectrum space, so it's ever farther away from "wireline"
(glassline?) nets.
A Message switching/BBS system for packet radio can still use IP for its
underlying, not-quite-real-time transport. But it runs local
applications to edit and present messages. Big packets thus win out over
little ones. And user applications, still mired in the BBS world, can
improve in an evolutionary fashion, adding features like local editing
on the user client (which get them out of the terminal/host camp).
fred k1io
------------------------------
Date: Tue, 23 Feb 1993 14:41:47 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: New ax25?
To: tcp-group@ucsd.edu
Lyndon and I continue,
(about BBSs)
>Sure we do: NNTP + (pick your favorite NNTP client - see later).
That's the closest. And NNTPD is, of course, an IP adaptation of
UUCP News, which is a BBS-class application. But I would like
a recommendation on a NOS NNTP client! Or more on alternatives
to NOS. I'd actually like a Pathworks DECnet client too, for DOS or OS/2,
but that's asking a bit much.
>And if IBM had bought up USL would that suddenly sanction SNA? By this
>line of reasoning, MS-DOS would be considered superior to VMS and Ultrix :-)
Let's not bash SNA too hard. They cried all the way to the bank with
it. For its intended purpose (now obsolete, of course), it worked well.
It sold about a billion bucks a year. Very well. MS-DOS IS superior
to VMS and all flavors of Unix, if you have a $900 PC with 2M of memory,
a 40M HDD, and no computer skills. In every case, it's a matter of
market selection. Just because you and I aren't the target market
doesn't mean something's bad. Ditto for Joe Ham.
>Well, looking at it from the applications layer I see a lot of users
>who perform the equivelent to telnet and ftp in a single-tasking DOS
>environment (using Procomm, Kermit, what have you).
But that's "kiddiecomms" Message/BBS networking! They don't have
the IP layer. And they do have "servers" (BBSs). The end user gets the
necessary result, but it's an entirely different style of network.
What goes on the wire is very different.
>> Sure you can run "PC LAN" software over a
>> hidden IP layer (I do it myself sometimes) which provides router WAN
>> access, but that's not the same as flushing Novell in favor of "TCP/IP".
>
>Why is "PC LAN" software different from any other LAN software? Novell,
>as a WAN, sucks. It doesn't scale well to large networks (I'm talking about
>adding another 400 PC's to the network over the next year), and it doesn't
>help me when people ask "how do I {email,telnet,ftp} to host mumble." We have
>outgrown Novell, both in size and functionality, so we're replacing it.
PC LAN software is different because it doesn't scale!
But more seriously, the word "LAN" means totally different things to
them and to us. To us it means "orange hose". To them it means "Netware
server", and the hose is just like the line cord. Read "LAN magazine"
and you'll see what a different language the two worlds speak.
Not to be sounding like a plug, but Digital's Pathworks has a nice niche
market selling into LARGE PC environments that outgrow Netware. The
difference is that they started wth an application on an overly-minimal
network (local area only) base, and had trouble adding routing. We
started with a scalable network base (DECnet or IP, take your pick)
and added PC client/server applications (LAN Manger). So Pathworks
provides PC services over a WAN. Last week, while testing Pathworks for
ISDN in the ISDN lab, we connected to a server in France (via DECnet).
(The ISDN call was local, to a DECnet router.) Now, to the PC user,
Pathworks is a "LAN". To the network infrastructure, it's just another
set of nodes.
>Enough digression ...
Ayuh! But as you see, we're actually nearly in agreement on what people
need; it's the vocabulary that's confusing. I also have learned to
appreciate "crufty" competitive protocols when they eat my lunch. To
compete with them, we have to start on their own terms and remove the
cruft.
>So what's the solution? Scrap NOS for the end-user! Right now I am working
>on a packet driver that does AX25/KISS framing rather then Ethernet.
>This driver, sitting under the "free" Waterloo TCP package, will give
>an end user the ability to use DOS commands like telnet, ftp, mail, nn,
>etc., in the way they are used to using other DOS utilities. And if you
>don't like WATTCP, run your favorite GUI based commercial software instead.
A quick synopsis of Waterloo TCP/IP, including FTP location if it's
available that way, would be appreciated! I'm not sure how well known
it is "south of the border". Thanks,
fred k1io
------------------------------
Date: Tue, 23 Feb 1993 14:01:43 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: New ax25?, point-to-point links, radio bandwidth cost
To: goldstein@carafe.tay2.dec.com
> Radio bandwidth is expensive. The product of range * speed is
> pretty much treatable as a constant.
I think this is why Glenn Elmore is trying to push us to use point-to-point
links rather than treating radio as a broadcast medium. That is the only
way that we could support megabit-per-second throughput to the end user
for very many users. Of course this forces the network into the
message-switching paradigm, just like your telephone-BBS example.
Running Emacs on a radio "LAN" is only "sick" if your perspective is the
broadcast-TNC model. If we can come up with inexpensive microwave
equipment for the multitude, _and_good_routing_software_, this becomes a
lot more practical.
Bruce Perens KD6OTD
------------------------------
Date: Tue, 23 Feb 1993 18:13:51 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: New ax25?, point-to-point links, radio bandwidth cost
To: BrucePerens<bruce@pixar.com>, tcp-group@ucsd.edu
Glenn's microwave model is useful, but not as an access "LAN" medium.
It's the only way to fly for the stationary links between "nodes"
such as routers or message switches. But Joe Ham isn't going to trudge
up Mount Mozzarella with his own radio and feedhorn, and beg for a
slot on the Mount Mozzarella IP Association's router, just to be able
to read BBS mail.
Everything in its place....
------------------------------
Date: Tue, 23 Feb 93 10:23:58 EST
From: kz1f@RELAY.WESTBORO.LEGENT.COM
Subject: NOS & MSC under Windows NT?
To: jimh%kd4ldo.tcman.ampr.org@skeggi.vware.mn.org, tcp-group@ucsd.edu
> Porting the OS/2 app may not be the most straight forward for me; I'm used to
> DOS apps (and UNIX, to an extent), and am also one of the strange people who
> prefer a CL interface as opposed to a GUI. But that is a thought; in fact, I
Wll, its not so much because of the PM/Windows paradigm, its more a case of the
dispatcher changes completely. Now, one could re-invent the multitasking
dispatcher or take the one out of PMNOS. Furhter, because of some assumptions
Phil made that arent valid with the new dispatcher, there are several places
where the daemons had to be changed, particularly with regard to termination.
Again, one could re-invent this or use the PMNOS model. Further, there is the
issue of plain old bad pointers, in DOS nothing predictable happenes, a bad
pointer may be very benign, particularly if its readonly. Under a real OS a bad
pointer is fatal. To be sure, there are some still floating around in PMNOS,
thats why occationally people say it just disappeared...no, it crashed. However
these areas are probably in functions I either never used or never really
stressed. But for the average user PMNOS (that kernel) is rock solid, which is
more than I can say for when I first started. Again, you can leverage the work
I did for OS/2 against other platforms, the issues are identical. As dar as the
graphical interface, I personally prefer it, for tracing or having mutiple
sessions active but others may not. The code for the command line versions of
OS/2 nos are ttill there, just ifdefed out, in fact one could probably
recompile PMNOS without the -DPM and get most of the cl version compiled.
Atleast that was the initial intent although I'll be the first to say its
proobably not perfect.
> have considered getting a hold of the Windows NT
> DDK and writing an AX.25
> w/ TCP/IP encap driver to use with NOS; then I would be able to use all of
> the native utilities that come with NT.
Well, I think the thing to do here is write the NDIS shim program (DD) that
will function as the protocol stack. Next, wite MAC drivers for PI, SCC and
perhaps even the COM ports. By doing this, you automatically pick up the
various eithernet / token ring adaptors and greatly simplify the iface layer of
nos. NT is also designed to support the client side of tcp/ip, I am not
entirely convinced exactly what uSoft meant by that except that they were not
providing the daemons. Another possibility is just write the mac driver for
ax25 and use an off tthe shelf tcp/ip program like NetManage for NT. But that
kinda ruins the fun huh?.
> Of course, I have *no* idea how to write a
> device driver... :-)
This is a problem. Walt
------------------------------
Date: Tue, 23 Feb 93 13:39:18 GMT
From: A.D.S.Benham@bnr.co.uk
Subject: Open Squelch SCC
To: TCP-Group@UCSD.Edu
Several users of various flavours of NOS in the London area have asked me
whether it is possible to run their SCC cards with open squelch (software
DCD). The version of SCC.C that is included in most NOS versions (most of
us are running JNOS 108) doesn't allow this.
Has anyone done any work in this area?
At present a few people are using the G8BPQ switch code beneath NOS as this
=does= support open squelch for SCC cards- however this eats up 80k or so of
memory, and memory is one thing we don't exactly have spare!
My Pac-Comm TNC-220 has an 8530 SCC chip in it, and =that= can do software
DCD [ but not in KISS mode ;-( ].. what I'm looking for is a solution that
=doesn't= involve me disassembling 32k of Z80 code to see how it's done.
(I've looked in the 8530 Technical Manual, and I've an inkling of how to do
it, but I'm not a fan of re-inventing wheels).
73,
Andrew Benham
--------------------------------------------------------------------
adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA
+44 279 402372 Fax: +44 279 402100
Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB3XP
--------------------------------------------------------------------
------------------------------
Date: Tue, 23 Feb 1993 09:09:24 -0500
From: goldstein@carafe.tay2.dec.com (k1io, FN42jk)
Subject: physical layer and FEC engineering
To: tcp-group@ucsd.edu
We have to stop confusing transmission engineering with systems design.
Glenn Elmore's argument seems to be classically focused on the
transmission (layer 1, to some datacomm types) issues. To a
transmission engineer, it's of course possible to claim, as Glenn
does, that we're doing great when 99% of bits get through. But
to a datacomm user, an error rate of 10^-2 is pathetic and well
below unusable!
Interference IS the limiting factor on most ham packet radio.
While Glenn is playing in the stratosphere of X band, where vast
spaces of precious spectrum are virtually unused by hams (and
frankly unusable by most), most ham packet is on 145 and down.
We've been in near-perpetual congestion collapse on our popular
packet frequencies for years.
Phil's radar example is perfect: We can GUARANTEE that we'll lose
one bit out of every, say, 120 or 250 (depending on the radar and
data rate) or such. Since AX.25 and all other non-FEC data li nk
protocols require ZERO bits in error across the whole frame, we
can GUARANTEE that most frames won't get through without FEC!
99% isn't good enough when a frame has over 100 bits!
Simple convolutional coding isn't very CPU-intensive. I don't
know the procedures myself, but I'm sure it can be done on a
386 at packet radio speeds with no great effort.
------------------------------
Date: Tue, 23 Feb 1993 11:15:31 -0500
From: chk@alias.com (C. Harald Koch)
Subject: Riff-raff and the internet?
To: bruce@pixar.com (Bruce Perens)
> much so, in opinion). Since AMPRnet stations are official parts of the
> internet, what's the problem?
Could you define what you mean by "official parts of the internet"? Net 44
doesn't have connected status, and it isn't carried by the ANSNet backbone
routers. To me, this means that we *aren't* part of the internet, but
simply another IP based network...
--
Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON
action, there is an equal | chk@alias.com (work-related mail)
and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address)
program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet)
------------------------------
Date: Tue, 23 Feb 1993 13:51:49 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: Riff-raff and the internet?
To: "C. Harald Koch" <chk@alias.com>
On Tue, 23 Feb 1993, C. Harald Koch wrote:
> Could you define what you mean by "official parts of the internet"?
Brian Kantor seems to have a better grasp of the "official" situation
than I do. Apparently there are someone else's facilities that AMPRNET
is using _under_a_contract_. I don't understand if this contract applies
to the particular internet access provider used by the UCSD gateway, or
if it would apply to any access to the Internet that I could arrange
here in the S.F. Bay area.
Bruce Perens
------------------------------
Date: Tue, 23 Feb 93 19:06:34 HST
From: Antonio Querubin <tony@mpg.phys.hawaii.edu>
Subject: Riff-raff and the internet?
To: chk@alias.com (C. Harald Koch)
> > much so, in opinion). Since AMPRnet stations are official parts of the
> > internet, what's the problem?
>
> Could you define what you mean by "official parts of the internet"? Net 44
> doesn't have connected status, and it isn't carried by the ANSNet backbone
> routers. To me, this means that we *aren't* part of the internet, but
> simply another IP based network...
Net-44 does have connected 'status'. Unfortunately, not all subnets of
net-44 are connected into the Internet but we're working on it :-).
Tony
------------------------------
End of TCP-Group Digest V93 #52
******************************
******************************