Nate Bargmann wrote in a message to Mike Bilow:
NB> Unfortunately, we HAD the users on our *current* network and
NB> they've already left. Why? I don't know. Blame the
NB> Internet, blame an unwillingness on the part of us node-ops
NB> and BBS ops to bankroll a highspeed network for a bunch of
NB> users that cared to do nothing more than to use the current
NB> system and then bitch about how slow it was rather than
NB> learn how packet actually works and show an interest in
NB> improving the network, but blame someone other than the
NB> users that have left, of course.
I'll probably have my head handed to me for this, but at least accept that
these comments are based on over 15 years of experience with packet.
I don't think it was the speed that led to most user dissatisfaction, but the
lack of basic functionality. First, the AX.25 protocol was badly designed from
the point of view of what was eventually done with it. Even the protocol
document itself constantly refers to "temporary" provisions that were supposed
to go away -- like digipeating. I understand very well that the original AX.25
had to be implemented in such a way as to fit inside a tolerable cost EPROM and
run on a tolerable cost 8-bit CPU by the standards of 1982, but that's no
excuse for having left it that way.
Second, node functionality stagnated. The basic BBS model for packet activity
was reasonable in the days when the idea was to share a Xerox 820 CP/M
computer, and it was a requirement that ordinary users be able to work from
dumb terminals rather than computers. Even very substantial technical
achievements, such as the F6FBB software, are coerced into this model. The
worst example is the DX Cluster network, which was without question the most
inefficient possible application for the BBS model. I don't mean to criticize
the demand for DX Cluster functionality, but that demand should have been
satisfied with a more intelligent and efficient architecture making use of both
simple techniques that have been known for decades, such as NAK-only datagram
protocols, and newer developmental techniques, such as multicasting.
Third, network functionality stagnated. By the time netrom was designed, it
was well understood that much of its underlying technology was a bad idea,
specifically directed-vector routing and virtual-circuit connectivity. As a
result, netrom became grossly unsuited to exactly the types of advanced
protocols which were demanded by DX Cluster and other applications, such as
multicasting. Furthermore, netrom was coerced into an EPROM and 8-bit CPU,
repeating the same mistakes of AX.25, rather than being computer-based and
expandable. Could one ever hope to move video, for example, over netrom?
Fourth, the physical layer stagnated. The original packet protocols were
chosen for no better reason than that someone got a good deal on a bunch of
surplus Bell 202 modems. As a result, we ended up stuck with a physical layer
that is essentially indistinguishable from 1940s RTTY, except for a wider
shift. Sure, we use synchronous timing, but that just makes it worse. The
failure to use even basic forward error correction has proven to have been
probably the greatest single mistake in packet. Of course, there's that 8-bit
CPU issue coming back again.
Fifth, and probably most damning, is that all of these engineering issues,
which were really just mistakes motivated either by shortsightedness or a
desire to get something rather than nothing, evolved into political issues.
Netrom enthusiasts, not understanding that they were being held hostage by the
inherent defects of their protocol, began forming guilds and kicking out anyone
who questioned the wisdom of their settings. DX Cluster enthusiasts, not
understanding that their protocol made them a bull in a china shop, just kept
right on knocking over the display cases and smashing the crystal. And BBS
sysops continued right on serving a user base that no longer exists.
NB> Heck, AX.25 must move forward or perhaps be scrapped and
NB> replaced altogether. That is what makes ham radio so great,
NB> we can *experiment* and learn what works and what doesn't.
I think we know that by now.
NB> What ham radio doesn't need is a variety of protocols, or
NB> even one for that matter, owned by corporations or
NB> organizations or individuals and available only under a Non
NB> Disclosure Agreement or any other restrictive agreement. I
NB> think all ham radio protocols should be Free (LGPL?) and
NB> available to anyone wishing to implement or attempt to
NB> improve them. If we could establish some sort of adhoc body
NB> to act as the standards organization for ham radio digital
NB> protocols then I think it would be one more step to
NB> fulfilling Amateur Radio's charter as a service based in
NB> technical investigation.
I suggested this years ago. I even offerred to serve as de facto secretary,
and asked that anyone interested contact me via e-mail. I received three
responses and scrapped the idea. If people are willing to try it again, I
think it would be a good project. There was some talk of TAPR facilitating
something similar, but I think that discussion may have died out, too.
However, I also have no sympathy for writing lots of nice papers about
protocols without actually trying to implement them. An unimplemented protocol
is obviously of no use to anyone, and it is impossible to know if it would even
work until someone at least attempts to implement it. Perhaps Linux is the key
to making this happen, since it provides a convenient and accessible platform
for developing new hardware and software in the open.
-- Mike, N1BEE
