Date: Mon, 22 Feb 93 04:30:10 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 #50
To: tcp-group-digest
TCP-Group Digest Mon, 22 Feb 93 Volume 93 : Issue 50
Today's Topics:
56k modems, P.I. cards, and authentication
ARRL Petition to "kill" AX.25 -- some factoids
FEC in amateur radio (2 msgs)
New ax25? (3 msgs)
new firmware?
Newsreader for KA9Q NOS on PC?
no keyboard, no monitor
Slow mail? (2 msgs)
UNSUBSCRIBE
what nos for a switch
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, 21 Feb 93 14:51:25 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: 56k modems, P.I. cards, and authentication
To: jmorriso@ee.ubc.ca, tcp-group@ucsd.edu
There's an effort underway in the IETF right now to specify an "IP
Security Protocol" that would allow encryption and/or authentication
of individual IP datagrams. That's the level where this function
belongs, in my opinion.
Phil
------------------------------
Date: Sun, 21 Feb 93 14:59:20 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: ARRL Petition to "kill" AX.25 -- some factoids
To: clark@tomcat.gsfc.nasa.gov
Tom,
The proposed changes in 97.109(e) would remove the ax.25 requirement for
third-party traffic on all frequencies. THIS IS GOOD! The discussions
re a "new" AX.25 which have shown up here and on the nos-bbs list I see
as an attempt to resurrect plans to update the protocol, which the "old"
DC worked on, but was unable to accomplish. This also is good. Some of
the discussions have been based on the DC's wording of "accepted
protocol" (which is different than "published protocol"), but the
proposed RM did not include that. The reference to digital codes as
permitted in 97.309(a) is a separate matter applying to the bands below
50 MHz and there have been some discussions as to whether some of the
techniques (e.g., CLOVER) comply with this.
The changes in the subband allocations from the Region 2 plan and/or the
DC recommendations is a concern, but the difficulties everyone faces here
are presumably well-understood by all, and future changes would be
expected.
Bob
Bob Nielsen W6SWE
ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org
amateur IP: 44.124.12.16 CIS: 71540,2364
------------------------------
Date: Sat, 20 Feb 93 13:11:24 -0800
From: Phil Karn <karn@qualcomm.com> (Phil Karn)
Subject: FEC in amateur radio
To: tcp-group@ucsd.edu
Glenn, I used to think as you did about FEC -- that it was something you did
as a last resort to patch up a bad radio channel, when you couldn't fix the
actual problem (e.g., by running more power.) But if I've learned anything
from the CDMA cellular project here at Qualcomm, it's that FEC is essential
in wringing maximum performance out of a radio system, even when you have
the option of increasing transmitter power or using a better antenna.
One good reason is spectral efficiency. Efficient spectrum use means a high
degree of geographic channel reuse (i.e., a cellular scheme), which implies
that the system is ultimately interference (not noise) limited. To pack
co-channel users as closely as possible, you want a modulation method with
the greatest possible resistance to interference. Even if this makes the
signal much wider, you're still better off in the end.
Spread spectrum is of course the way to do this, but FEC also plays
an important part. By reducing the average required transmitter power 5 dB
or so, FEC reduces the interference caused to other users by the same
amount,
and this turns directly into a 5dB system capacity increase.
So far this assumes gaussian "noise", which is a good model for the
interference one sees in spread spectrum. But FEC can *really* shine when
you're fighting
non-gaussian interference, especially radar. Here in Southern California we have
a serious, chronic problem with military radar on the 70cm band, and I am
now convinced that FEC is the only practical way to deal with it (without
simply abandoning large parts of the band to the radars).
Consider a typical military radar with a 400 Hz rep rate, a 8 Mhz bandwidth,
a 10 second antenna sweep rate, and a 20 microsecond pulse width (this
latter figure is the most uncertain, I estimated it with an HP spectrum
analyzer set in "zero span" mode with the fastest possible sweep, 50 us/div).
If the pulses were really short, i.e., on the order of 1/bandwidth, then
even at 56kb/s a simple pulse blanker would be very effective at dealing
with it. Unfortunately the radar pulses are much longer than they have to be
for the bandwidth they use, probably because of either pulse compression and/or
simple pulse broadening to increase target sensitivity. Because the pulse
durations are comparable to an entire bit time at 56 kilobits, a pulse blanker
would remove entire data bits along with the radar pulses.
Let's say that your link is otherwise reasonably well engineered, so most
of your channel bit errors are due to radar pulse hits. Let's also assume
that the radar pulses, when they occur, are much stronger than the data
bits themselves -- say by 40 dB or so. To overcome the radar QRM by brute
force, you'd have to make up that 40 dB by either turning up the wick by
that amount (probably not practical, as well as not legal, especially in
one of the 50W limit zones), or by using antennas with that much additional
gain and/or sidelobe suppression (difficult if not impossible when you
consider scattering.
Or you can use FEC. If the pulse rep rate is 400 Hz and your data rate is
56kb/s, then the radar will hit, at most, one or two data bits out of every
56000/400 = 140. That's a channel bit error rate of 1%, in round numbers,
which is much too high for good performance without FEC. And cranking up
the wick won't do anything to lower this error rate until you swamp the
radar's power, which we already know is impractical.
But it's *easy* to build FEC systems that handle channel bit error rates of 1%.
I've built a software sequential decoder using the Fano algorithm that decodes a
rate 1/2, constraint length 32 convolutional code. The exact decoding
throughput is a random number that depends on the channel error rate, but
at relatively low error rates like 1% it has no problem keeping up with a
56kb/s modem with time to spare on a 33 Mhz 486. The chances of an
uncorrected error at this rate
are nil for all practical purposes, so the effective coding gain in this case
is equal to the amount of power you'd have to run to get the same effect by
simply cranking up the wick -- 40 dB in this example. That's a pretty impressive
figure!
So this strongly suggests using a Fano decoder on packet channels that get
hit by radar QRM. A rate 1/2 code does decrease the user data rate by half,
so
you probably want an adaptive scheme that adds the FEC overhead only when
it is actually needed. So consider a hybrid ARQ/FEC scheme that works like this.
You choose a "systematic" convolutional code where the original data appears
in the coded output (every other channel bit is a user data bit, the others
are generated by the coder). When you first send a packet, you send just the
original data bits plus a CRC. If that checks out, you go on to the next
packet and not bother sending the FEC overhead. But if the CRC check fails,
you return a NAK (negative acknowledgement).
Now instead of simply retransmitting the original packet, the sender now
sends the second set of symbols from the convolutional encoder (the ones that
aren't just the original data bits). The receiver now combines *both* frames,
and runs them through the sequential decoder. If this works, it goes onto the
next packet. If not, you start the process over.
What's really neat about this is that both frames (the original one plus
the encoded one) can be riddled with errors, but as long as the rate isn't
higher than about 6 or 7%, the decoder will quickly recover good data from the
combination. This makes it *much* more efficient than simply resending the
unencoded frame over and over in the hope that it will get through without
any errors -- which is pretty unlikely if the average error rate is that high.
Phil (again sending over a CDMA connection from a mobile van, now back at the
hotel parking lot where we started...)
------------------------------
Date: Mon, 22 Feb 93 11:23:30 GMT
From: agodwin@acorn.co.uk (Adrian Godwin)
Subject: FEC in amateur radio
To: tcp-group@ucsd.edu
Phil Karn <karn@qualcomm.com> writes ..
>
> What's really neat about this is that both frames (the original one plus
> the encoded one) can be riddled with errors, but as long as the rate isn't
> higher than about 6 or 7%, the decoder will quickly recover good data from the
> combination. This makes it *much* more efficient than simply resending the
> unencoded frame over and over in the hope that it will get through without
> any errors -- which is pretty unlikely if the average error rate is that high.
But if the error rate is high enough for that to be useful, (i.e. most
packets have a few bits in error), you'll often have to send at least two
packets. So the user data rate will be halved anyway : you may as well send
a single, slow packet and avoid any additional overhead associated with keying,
syncing, CA or whatever.
If the error rate is low enough that not many packets _have_ to be
retransmitted, simple retransmission is probably almost as efficient.
Implementation might suit the characteristics of Hubmaster, but on anything
other than a point-to-point link retransmission would be an interesting
problem : retransmitted frames need to be correlated with earlier
transmissions, even though the main portion of the retransmitted packet
would have nothing in common with the original. I think this means that
you'd need some sort of robust header on each packet that isn't corrected
by the same mechanism, and is used to generate a sender-specific NAK.
Or virtual circuits at the link level ..
You really want to send twice only the bits that will be corrupted :-).
That isn't completely stupid : if you have such a specific interference
source that it's worth designing an error correction protocol with matching
characteristics, perhaps you should synchronise to the interference source
and transmit only in the gaps. Is there just one radar transmitter, or
several unsynchronised transmitters ?
-adrian, g7hwn
------------------------------
Date: Sun, 21 Feb 1993 16:31:43 -0500
From: chk@alias.com (C. Harald Koch)
Subject: New ax25?
To: Lyndon.Nerenberg@ns.unbc.edu (Lyndon Nerenberg)
> Well, the address only has to be unique within the subset of stations
> that can hear each other. I would use a 16 bit station address. When
24 bits allows you to use the low order 24 bits of an AMPR IP address... :-)
> a station comes on the air it picks a random value and broadcasts it
> out the appropriate port. If the address is already in use the existing
> address holder sends out a "sorry, try another one" reply, and the
> process repeats until a unique address is found. (Now where have I
> seen *that* before :-)
AppleTalk? There's a nice optimization there that's useful; the driver uses
the same address it used previously as a starting point; only if that
address is already un use does the host choose a new, random address.
However, the now famous hidden transmitter problem ensures that sooner or
later, two hosts will choose the same link-layer address, causing confusion
for the host than can hear both...
--
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: Mon, 22 Feb 93 00:58:39 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: New ax25?
To: Lyndon.Nerenberg@ns.unbc.edu, makinc@hhcs.gov.au, tcp-group@ucsd.edu
>Well, the callsign doesn't belong in every packet, either - it's extra
>overhead that just isn't needed. If you need to identify your transmitter
>to comply with regulations, send an ID packet whenever its require. This
>business to tying the callsign to the MAC address was a mistake.
I strongly disagree. Putting both callsigns into each frame was one
thing (and probably the only thing) AX.25 did right.
What are you trying to save by removing callsigns, and at what cost
and complexity? At best you will save a couple of bytes per frame,
but are a few bytes really that important when you consider all of the
other sources of per-packet overhead, such as channel contention,
keyup delay, modem synchronization, etc? And what of the overhead
and/or confusion generated by an "abbreviated" link address generation
or assignment scheme? It just isn't a good move.
If you really want to reduce overhead in a packet system, the secret
lies in educating the *upper layer* protocols to generate fewer and
larger packets whenever possible. I can think of all sorts of
examples: the Nagle algorithm in TCP (widely implemented) and Linemode
Telnet (unfortunately not yet very widely implemented) are two that
come immediately to mind. These techniques save you not only the link
level protocol overhead, but the TCP/IP header overhead as well. A
much bigger payoff, and with no extra complexity for a link protocol
that already has enough to do.
Phil
------------------------------
Date: Mon, 22 Feb 1993 05:20:24 -0600 (CST)
From: Chris Cox W0/G4JEC <chrisc@biggus.moron.vware.mn.org>
Subject: New ax25?
To: chk@alias.com (C. Harald Koch)
>
> 24 bits allows you to use the low order 24 bits of an AMPR IP address... :-)
>
That, however, then requires that you know our ip address prior to
setting a link address. rarp/bootp would not work then. I doubt it's
used very much over radio, however, it would be useful.
Is there any great reason why your callsign should not make up part of
the link address, or at least use it as seed for an address? It is useful
in that it is unique.
--
73 Chris Cox W0/G4JEC
chrisc@biggus.g4jec.tcman.ampr.org chrisc@biggus.moron.vware.mn.org
Eleventh Hour Contest Group - North American Chapter; Minneapolis, MN
Twin Cities Metro Area Network node (biggus.g4jec.tcman.ampr.org)
**** And lest they forget: ****
Packet radio fiends really enjoy playing with their bits...
------------------------------
Date: Mon, 22 Feb 93 00:47:09 -0800
From: karn@qualcomm.com (Phil Karn)
Subject: new firmware?
To: goldstein@carafe.tay2.dec.com, tcp-group@ucsd.edu
Reed Solomon coding (or block codes in general) are certainly another
option for amateur packet radio FEC at the link level. I tend to
lean towards convolutional codes, though, for a couple of reasons:
1. Block codes work well either for data in fixed sized blocks that
match the code's block size, or for semi-infinite streams of data
(e.g., digital audio), but they're somewhat less suitable for variable
length packets because of the internal fragmentation problem. I.e.,
if you used the CD's RS coding, you'd have to pad out the encoded packet
to a multiple of 32 bytes.
Convolutional codes, on the other hand, are well suited to variable
length data packets. You do have to "tail out" the end of the packet
with a constraint length or so of zeros, but this is no big deal.
2. Convolutional codes are easier to adapt to "soft decision"
decoding, where you quantize the channel to some modest number of
levels (e.g., 4 or 8) instead of hard-decoding the channel to a single
bit before decoding. This buys you about 2 dB in Eb/N0
(signal-to-noise) ratio, which is admittedly more important against
thermal noise than against the radar QRM I am most concerned about.
Of course, implementing soft decision decoding requires hardware
modifications to the demodulator, as the simple slicer would have to
be replaced with a small A/D converter. And while you're at it, the
demodulator itself should be coherent. The PSK satellite modems
already are, but the WA4DSY 56kb modem is a noncoherent FSK
discriminator. This loses another 3 dB.
These little 2-3 dB factors really start adding up. If you go from a
non-coded noncoherent demodulator to a coherent demodulator with a
well designed soft decision rate 1/2 FEC, you can easily save as much
as 8dB on transmitter power. This should be very attractive in some
places (like satellites). And as I said yesterday, the effective
coding gains against non-thermal noise such as radar pulses can be
far higher, even with relatively simple FEC.
Phil
------------------------------
Date: Sun, 21 Feb 93 13:44:05 GMT
From: jiml@eldorado.demon.co.uk (Jim Lambe)
Subject: Newsreader for KA9Q NOS on PC?
To: tcp-group@ucsd.edu
In article <199302190028.AA10981@leon.nrcps.ariadne-t.gr> you write:
> Subject: Newsreader for KA9Q NOS on PC?
> To: packet-radio@ucsd.edu
>
> axa12@po.CWRU.Edu (Ashok Aiyar) wrote:
> >
> >Can someone suggest a good news reader that can be used in conjunction
> >with NOS on a PC? I will be using PA0GRI NOS 911229 to contact the
> >NNTP server and download news. I am simply looking for a good system
> >to read and manage news with - i.e read news, expire articles, and
> >prepare articles for posting.
>
> Article: 2398 of news.software.readers
> From: nikki@trmphrst.demon.co.uk (Nikki Locke)
> Subject: News/mail reader for DOS
> Organization: Trumphurst Ltd.
> Lines: 33
> >From packet-radio-relay@UCSD.EDU Wed Oct 14 17:23:15 1992
> Date: Wed, 16 Sep 1992 18:32:41 +0000
> Message-ID: <716694839snx@trmphrst.demon.co.uk>
>
> [...]
>
> The connection software is based on Phil Karn's excellent KA9Q program,
> and the news reader is based on snews from John McCombs.
>
> I did not particularly like the user interface of snews, so I wrote my own
> combined newsreader and mailer. It is written in C++, and uses my own SAA
> compliant text mode user interface toolkit.
>
> If there are any other people out there who use DOS to access the news,
> and they would like to try my news program, the latest version is
> available for public ftp from :
>
> ftp.demon.co.uk:/pub/trumphurst/cppnws16.zip
>
Latest version is 1.31 available from ftp.demon.co.uk in
/pub/trumphurst/cppnews; files needed are cppnws31.zip and cppindex.zip
--
James V. Lambe: Tottenham, London, ENGLAND
Internet: jiml@eldorado.demon.co.uk
Telecom Gold: 10085:TJT674 ( 10085.TJT674@gateway-to-gold.interspan.gb )
Compuserve: 72037,152 ( 72036.152@compuserve.com )
Dog + Bone: (+44 81) 808 0625
------------------------------
Date: Mon, 22 Feb 93 11:09:52 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: no keyboard, no monitor
To: crompton@NADC.NAVY.MIL (D. Crompton)
> Date: Fri, 19 Feb 93 11:02:08 EST
> Message-Id: <9302191602.AA00541@NADC.NADC.NAVY.MIL>
>
> It works for CTTY and is at least a first step in a change that I think
> should be permanant to allow terminal operation.
CTTY: I noticed at least in old DOS 3.10 it works improperly, sometimes
it waits somethong to be put in keyboard buffer (presence of data in
the KB buffer is checked without BIOS by comparing 0x40:0x1A and 0x1C),
hanging forever if no keyboard data can arrive. The only workaround for
the bug I know: must have TSR servicing COM port interrupts which puts
received data in KB buffer, and services INT 14h.
> By the way I see little if any display speed difference here on a fast
> machine using DOS calls. I do however see a difference when using BIOS
> calls (-b) where a slight slowdown is seen. I wonder why this is. Is
> DOS calling direct video?
I suppose DOS itsel doesn't call it, but either NOS can use direct
video, or you have a device driver like (N)NANSI.SYS using it.
73's, JT
------------------------------
Date: Sun, 21 Feb 93 15:16:55 MST
From: rnielsen@tapr.ampr.org (Bob Nielsen)
Subject: Slow mail?
To: lcz@dptspd.sat.datapoint.com (Lee Ziegenhals)
I have noticed the same thing. It seems to be slowly catching up,
however.
Bob Nielsen W6SWE
ax.25: w6swe@wb7tpy.az.usa.na Internet: rnielsen@tapr.ampr.org
amateur IP: 44.124.12.16 CIS: 71540,2364
------------------------------
Date: Mon, 22 Feb 93 11:32:44 GMT
From: agodwin@acorn.co.uk (Adrian Godwin)
Subject: Slow mail?
To: TCP-Group@UCSD.Edu
I've had a three-or-four day lag that usually catches up at weekends - but this
is the digest, on 'Bulk' precedence, so that seems reasonable if ucsd is
handling a lot of mailing traffic.
-adrian
------------------------------
Date: Sun, 21 Feb 1993 09:28:25 -0800
From: atheist@Apocalypse.CAD.UCLA.EDU (Jim Small)
Subject: UNSUBSCRIBE
To: tcp-group@ucsd.edu
Sorry for extra traffic, but I've sent a message to the listserv to
unsubscribe me and I still keep getting this group
------------------------------
Date: Sun, 21 Feb 93 20:17 EST
From: gws@n8emr.cmhnet.org (Gary Sanders)
Subject: what nos for a switch
To: tcp-group@ucsd.edu
Any specific version of nos that works best as a switch?
Several of the locals are putting D4-10 online and will be using
it to route from in home ethernets to the radio world. I dont
need any services on the gateway only something that will talk
kiss, talk to a packet drivers for ethernet and talk to a pi card.
Gary W. Sanders gws@n8emr.cmhnet.org, 72277,1325
N8EMR @ N8JYV (ip addr) 44.70.0.1 [Ohio AMPR address coordinator]
HAM BBS 614-895-2553 (1200/2400/V.32/PEP) Voice: 614-895-2552 (eves/weekends)
------------------------------
End of TCP-Group Digest V93 #50
******************************
******************************