Internet on Radio Revisited
MUNTS PHILLIP A
The consensus seems to be that I was all wet saying that the Internet
model was inappropriate for amateur packet radio. Obviously, I just don't
know how to use TCP/IP properly. So tell me...
How do I ftp or telnet through a store and forward satellite? Would
TCP/IP even work through a store and forward satellite? How about on HF?
(also essentially store and forward due to propagation, interference, and
low bandwidth.)
These are currently the only packet channels between Alaska and CONUS.
It is about 2500 road miles between Fairbanks and CONUS. A terrestrial
microwave relay system would require 50 stations if we could manage 50 miles
a hop on the average. What is the likelihood of installing and then
maintaining such a backbone? (Our 9600 bps intra-state BBS backbone is
piggybacked, I understand, on state owned microwave equipment.)
Vast areas of Canada, western U.S., South America, Asia, Australia,
Africa etc. have the same problem. High bandwidth backbones don't appear
from thin air just because the design requires it. A lot of the world is
going to be serviced by store and forward channels for a long time whether
we like it or not; my question still unanswered is TCP/IP appropriate for
that?
I read recently (IEEE Network I think) that one of the design criteria
for ARPANET and hence TCP/IP was 9600 bps effective between any two nodes
anywhere on the network. This was accomplished with long haul links at 230
Kbps links (no doubt much faster now). My observations have been that this
is barely enough at the best of times and totally inadequate during the
business day. What kind of radio network hardware do we need to provide this
level of service? With a couple orders of magnitude more nodes and much less
reliable long haul links?
Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks
Phil R. Karn
If I understand Phil Munts' argument, the TCP/IP architecture was
primarily designed for use over subnetworks with continuous,
ubiquitous, real time coverage. On the other hand, much of amateur
packet radio uses slow, part-time links that are suitable only for
handling store-and-forward traffic in non-real time.
Fair enough. The Internet protocols WERE originally designed for the
ARPANET, the first packet switching network. ARPANET used government
sponsored links, and sites that were on it enjoyed virtually
continuous connectivity with other sites. And of course TCP/IP and the
applications it supports are most "at home" in this kind of world.
But the Internet has grown far beyond the bounds of the original
ARPANET (which no longer exists, having been replaced with the NSF
Backbone Network). Not all of the links in the current far-flung
Internet are dedicated leased lines or highly reliable local area
networks. Some are commercial X.25 networks. Others are dialup phone
lines. And some are even amateur packet radio paths. In other words,
the Internet is no longer based on "continuous duty" facilities, and
it hasn't been for some time.
One place where this is especially true is electronic mail. The
Internet now reaches many other kinds of electronic mail networks,
many of whom do not use TCP/IP. Examples include UUCPNET, BITNET,
Compuserve, MCIMail, SPANNet, and even the amateur packet radio BBS
network. Now, strictly speaking, you could say that these other
networks are not really "on the Internet", because they don't
specifically speak TCP and IP. But what does "being on an internet"
really mean?
An internet (note lower case 'i') is usually defined as a set of of
connected networks that share a common set of upper layer protocols
and a global name space even though they may differ widely in their
lower layer protocols. What's interesting about Internet mail is that
even some networks that don't use TCP/IP have adopted the Internet's
electronic mail standards, either as their native tongue or as a
lingua franca. In a very real sense, we have built an
"inter-internet", and the new "inter-internet datagram" is the
electronic mail message. Some people have followed the Internet
client/server model even further by setting up "mail archive" servers
that accept mail messages requesting files that are automatically sent
back in return mail.
To be sure, the facilities of this inter-internet are not as
transparent, flexible, or as powerful as those of the "real" Internet,
because they are typically built on slower non-real-time facilities
that are better suited for store-and-forward traffic such as email.
But they work, and they do not deny those to do have the resources to
build a "real" TCP/IP Internet the opportunity to do so while
retaining the capability to exchange email with those who are not as
well endowed.
So, after that lengthy monologue, on to some of Phil's specific questions.
> How do I ftp or telnet through a store and forward satellite?
In theory, you could. You store each IP datagram as a separate message
in the satellite. After two passes over the client and one over the
server, you've completed your three-way TCP handshake, and now the
server's ready to send the FTP greeting....
Ah hem. Obviously, real time services like FTP and Telnet are not
appropriate THROUGH a non-real-time satellite like Microsat. But
there's no reason that you couldn't use them to talk TO the satellite,
using it as an FTP "staging area". People do the same thing all the
time on the ground, especially when their computers have only
intermittent connectivity to the Internet (portable laptops, for
example).
You might think the use of TCP/IP unnecessary if each user talks
directly to the satellite. But the use of TCP/IP on the satellite
could make it much easier for the users in a local community to share
a common satellite ground station. The TCP "end-points" would be on
the satellite at one end, and at the individual user stations at the
other. The shared ground station would just be a concentrating IP
router/gateway. By the way, there's much to be said for the gateway
approach to using satellites, aside from being able to share the cost
of the equipment. By funneling the users' uplink packets through a
common queue and transmitter, you avoid the contention between them
that would otherwise occur if they each transmitted to the satellite
directly.
> How about on HF?
> (also essentially store and forward due to propagation, interference, and
> low bandwidth.)
It depends. A satellite can have an onboard computer and memory, while
HF is just a propagation channel. If it's available and goes where you
want to go, there's no reason it couldn't be used in real time.
Otherwise it could be used in store-and-forward mode to handle email
or file transfer.
The point I've been trying to make all along is that TCP/IP does NOT
necessarily preclude store-and-forward operations or vice versa. The
popularity of the MX (mail exchanger) extensions to the domain system
prove this. The MX facility has dramatically improved the ability of
Internet users to communicate easily and transparently with off-net
sites, most of whom are joined only through slow and intermittent
store and forward paths -- just like amateur packet radio.
> I read recently (IEEE Network I think) that one of the design criteria
> for ARPANET and hence TCP/IP was 9600 bps effective between any two nodes
> anywhere on the network. This was accomplished with long haul links at 230
> Kbps links (no doubt much faster now).
Actually, the ARPANET backbone links were almost all 56kb/s. This
bandwidth had to be shared across all active users. Depending on how
many users there are and where they wanted to go, they might or might
not receive an effective throughput of 9600 bps. This had nothing to
do with the protocols, but with basic arithmetic -- no protocol can
cram ten pounds of users into a five pound network.
To be sure, there is still plenty of room for improvement in extending
the Internet model to cover less-than-ideal network paths. I believe
amateur packet radio has already made some contributions in this area;
a robust round time measurement algorithm that I invented several
years ago while trying to get TCP to perform better over amateur
packet radio was picked up by the Internet community and is now a
required part of the TCP standard. The protocol implementations
should also be tuned to accomplish more in fewer round-trip packet
exchanges. TCP allows data, acknowledgements and control messages to
be piggybacked in the same packet. For example, it's perfectly legal
for an FTP server to send its TCP SYN/ACK and initial banner all in
the same packet, but few do. Also, it's legal to "batch up" a series
of SMTP commands in the same packet in order to minimize the effect
of long round trip delays. NN2Z's SMTP sender does this.
We also need to devise application interfaces that are less dependent
on real time connectivity. FTP clients (including mine) are a classic
example. Why should a user have to sit there and manually log into a
remote server and interact with it even when he knows in advance
everything he will type? He ought to be able to tell his local machine
"get this file from that machine, and use the following user name and
password". His machine would then do everything automatically, even if
the remote system is momentarily unavailable when the user requests
the transaction. Similarly, I should be able to say "send this file
to user so-and-so" and have the rest occur automatically. The
interactive model has persisted on the Internet largely because there
has been little pressing need to fix it. But this doesn't mean that it
can't be. This is another way that amateur radio could give something
back to the Internet community.
I'm fond of telling non-amateur Internet groups that if we can make
TCP/IP work on ham radio, with its unbelievably brain-damaged links,
then we can make it work ANYWHERE. And with the phenomenal growth in
the Internet (it has been doubling roughly every 12-13 months for the
past 5 years) the problems ham radio encounters today could well be
those the real Internet will encounter several years in the future.
I'd like to think that this helps serve ham radio's reason for being.
Phil
C. Harald Koch
>We also need to devise application interfaces that are less dependent
>on real time connectivity. FTP clients (including mine) are a classic
>example. Why should a user have to sit there and manually log into a
>remote server and interact with it even when he knows in advance
>everything he will type? He ought to be able to tell his local machine
>"get this file from that machine, and use the following user name and
>password". His machine would then do everything automatically, even if
>the remote system is momentarily unavailable when the user requests
>the transaction. Similarly, I should be able to say "send this file
>to user so-and-so" and have the rest occur automatically. The
>interactive model has persisted on the Internet largely because there
>has been little pressing need to fix it. But this doesn't mean that it
>can't be. This is another way that amateur radio could give something
>back to the Internet community.
The Internet community already has a solution to this. Check out BFTP
(described in RFC 1068 and available from venera.isi.edu). It works very
well from my experience, especially recently (many people have upgraded to
new versions of the ftp daemon since the Morris worm).
There are also many sites out there who run 'shadow archives' by contacting
the official archive sites via FTP and retrieving all new files; this is also
all done automatically without user intervention.
Amateur Radio would be the ultimate stress-testing ground for these systems.
But they have already been invented, and there's no sense us re-inventing
them.
Improving them, on the other hand, would be worthwhile...
--
C. Harald Koch VE3TLA Alias Research, Inc., Toronto ON Canada
chk%al...@csri.utoronto.ca c...@gpu.utcs.toronto.edu c...@chk.mef.org
"Open the Zamboni! We're coming out!" - Kathrin Garland and Anson James, 2299