HAM Radio 1/HamRadio.cdr/misc/pkthints/pd91036.txt

Internet Message Format | 1991-02-09 | 22.7 KB

From wang!elf.wang.com!ucsd.edu!packet-radio-relay Thu Feb  7 17:09:26 1991 remote from tosspot
Received: by tosspot (1.63/waf)
    via UUCP; Sat, 09 Feb 91 11:27:15 EST
    for lee
Received: from somewhere by elf.wang.com id aa16058; Thu, 7 Feb 91 17:09:25 GMT
Received: from ucsd.edu by uunet.uu.net (5.61/1.14) with SMTP
    id AA14800; Thu, 7 Feb 91 11:23:10 -0500
Received: by ucsd.edu; id AA20926
    sendmail 5.64/UCSD-2.1-sun
    Thu, 7 Feb 91 04:30:20 -0800 for hpbbrd!db0sao!dg4scv
Received: by ucsd.edu; id AA20911
    sendmail 5.64/UCSD-2.1-sun
    Thu, 7 Feb 91 04:30:09 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
Message-Id: <[e-mail]>
Date: Thu,  7 Feb 91 04:30:03 PST
From: Packet-Radio Mailing List and Newsgroup </dev/[e-mail]>
Reply-To: [e-mail]
Subject: Packet-Radio Digest V91 #36
To: [e-mail]


Packet-Radio Digest         Thu,  7 Feb 91       Volume 91 : Issue  36

Today's Topics:
                    'To:' field anarchy! (2 msgs)
         a few random thoughts about channel access (3 msgs)
  Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
                  Internet->packet Gateway (3 msgs)
                Painfully long FTP transfers (2 msgs)

Send Replies or notes for publication to: <[e-mail]>
Send subscription requests to: <[e-mail]>
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the Packet-Radio Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

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: 6 Feb 91 18:06:42 GMT
From: shelby![e-mail]  (paulf)
Subject: 'To:' field anarchy!
To: [e-mail]

In article <[e-mail]> [e-mail] (Steve Schallehn) writes:
>I feel this sort of 'segmentization' is going to be extremely important
>for message distribution continuing in packet radio.

I couldn't agree more.  The thing that differentiates netnews from mailing
lists is the existence of outstanding filter tools to get at what you
want, and to dump all the chad...

-=Paul Flaherty, N9FZX      | Without KILL files,
->[e-mail] | life itself would be impossible.

------------------------------

Date: 6 Feb 91 17:43:20 GMT
From: netnews.upenn.edu!platypus![e-mail]  (Bill Gunshannon)
Subject: 'To:' field anarchy!
To: [e-mail]

In article <[e-mail]>, [e-mail] (Steve Schallehn) writes:
> In the 9th Amateur Radio Networking Conference (Sorry, I don't remember the
> official name), there was a paper presented on using netnews for packet
> radio.

I suggested that right here in this group over 6 years ago.  I even tested
the idea of using UUCP 'g' protocol with TNC's.  It all worked really well.

Of course, I was told that the BBS concept worked perfectly well and there
was no need for anything like NEWS.  I think it would have been a lot easier
to change things before we had as many BBSes as we now do.

bill   KB3YV

--

     Bill Gunshannon          |        If this statement wasn't here,
     [e-mail]   |  This space would be left intentionally blank

------------------------------

Date: Wed, 6 Feb 91 08:00:56 -0800
From: brian (Brian Kantor)
Subject: a few random thoughts about channel access
To: packet-radio, tcp-group

Whilst having packet-radio nightmares again last night, a couple of
thought about channel access methods came to mind.  Here I go,
challenging assumptions again.

1. CSMA/CA is what we do to avoid collisions - we watch the channel and
wait until it's clear.  Most sophisticated people do it with
p-Persistance.  However, I think that a small variation in pP methods
would help throughput.

Simply, most of the pP implementations I've played with ALWAYS use
the roll-a-die-in-this-slot method - so when they go to transmit a
packet, they could conceivably wait one or more slottimes before they
transmit even though the channel is clear.  I think that if there is no
channel activity present the first time you have a packet ready to
transmit, you should simply go for it.  If the channel IS active, you
wait until it's clear, then you start doing the slot-delays.

This variation has the win that you'll never unnecessarily slot-delay
on a clear channel, but you will still gain the pP advantage of
avoiding the "lets all jump on the channel now that he's done" syndrome
which non-pP channel access methods exhibit.  Implicit in this is
that the generation of packets ready-to-transmit is somewhat random;
with maxframe set to one, even a high-volume data source like a BBS or
a sending FTP will exhibit this behaviour, since the next packet is, by
definition, not ready to transmit until the previous one has been
ack'd.

Problem with this one is implementing it; it probably means firmware
changes in everyone's TNC.  Arrgh.  Only the on-the-bus people can do
this in software.  Still, if you've got a DRSI card, you might give it
a shot and see if it helps.

2. Backoff.  Exponentially backing off when you don't get an ACK for a
packet has one tacit assumption that may be fatally flawed: that the
packet or its ack were lost due to congestion that can be cured by
reducing traffic density.  Yet on a packet radio network where packets
are lost randomly due to non-congestion-related causes (like static
crashes and passing Volkswagens), this assumption, if applied purely,
leads to backing off a lossy channel when in fact the right thing to do
is to be more aggressive!  (I recall one FTP session that had backed
off to an 8-hour retry time because I'd not limited backoff times and
it was a really lossy (50% or more dropped) channel.)

Some technique for noticing the degree of congestion and adjusting the
retry time is needed - perhaps something can be done along the lines of
noting other traffic on the channel and adjusting the exponent in the
backoff formula accordingly.  Algorithms which give greater weight to
the round trip time of successful (i.e., ack'd) packets are also a good
idea for combating the pathological-backoff problem that simpler
methods might generate.  Gotta think more on this one.

3. p-Persistance slottimes.  I'm wondering if we aren't really using
far too short a slottime.  On a network which has hidden stations (i.e,
90%+ of all ham packet radio networks), waiting a few milliseconds
because your coin didn't come heads-up in the current slot isn't going
to help - you're still going to stomp on the hidden station's packet
that he began transmitting those few milliseconds ago.  It seems to me
that you'd want the slottime to be more on the order of the
transmission time of the average packet, if indeed not of the
transmission time of the MAXIMUM packet.  That way, when you toss the
coin and lose in this slottime, the other guy gets a clear channel for
the whole packet, not just the beginning of it.  Implicit in the
use of short slottimes is the idea that you'll hear him and back off,
which simply isn't the case a really high proportion of the time.

Using slottimes on the order of one to five seconds (for a 1200 bps
channel) demands that you use technique #1 above; you'd really NOT want
to randomly wait some multiple of seconds on a clear channel.  It might
be smart to do this dynamically - if you're seeing packets but not
their acks, or acks but not the packets they're for, you've got hidden
stations and you should be using long slottimes.  Otherwise you're just
fine with slottimes on the order of the DCD response time of your
demodulator.  Again, this requires quite a bit of smarts, so the
on-the-bus people have an advantage, but the this one CAN be done with
KISS implementations, since the computer is getting all the packets and
can make the determination as to whether there are hidden stations
present or not, and adjust the TNC's slottime parameter accordingly.

Comments?
    - Brian

------------------------------

Date: 6 Feb 91 23:48:37 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: a few random thoughts about channel access
To: [e-mail]

Brian's first two points (decreasing p only when the channel is busy
and limiting backoffs) are well taken. It seems to me that both can be
set automatically by estimating the number of active stations on the
channel.  For example, if you see eight active stations on the
channel, then p should be 1/8 and the retransmission backoff should be
limited to 8.  Note that it's the number of active stations and not
the actual amount of traffic that matters.

There are two problems to be solved here. One is estimating the number
of hidden stations on the channel and the other is picking an interval
during which a station is considered to be "active". One possible way
to find hidden terminals is to watch destination as well as source
addresses on the channel.

As far as slot times go, I think it's best to keep them short. There's
really no way to detect hidden terminals by just listening to channel
activity - you have to interpret it. One way is to watch the control
fields in the packets themselves - if you see someone send an I frame,
you know that its recipient will be sending an ACK soon, even if you
can't hear it. This is the basis of the "prioritized ACK" scheme invented
by N7CL. I have devised a more general scheme of my own called CSMA/CA
(collision avoidance) that is based on the Apple Localtalk channel
access protocol; it was described in last year's ARRL conference proceedings.

Phil

------------------------------

Date: 7 Feb 91 00:52:45 GMT
From: [e-mail]  (Brian Kantor)
Subject: a few random thoughts about channel access
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>...  For example, if you see eight active stations on the
>channel, then p should be 1/8 and the retransmission backoff should be
>limited to 8.  Note that it's the number of active stations and not
>the actual amount of traffic that matters.

A quibble: I contend that it's the number of stations ready to transmit,
not the number of active stations.  Assuming point-to-point communications,
which is common, and no simultaneous data exchange in both directions,
which is rare, the actual number in your scenario would be 4, leading to
a pP of 1/4.
        - Brian

------------------------------

Date: 6 Feb 91 00:28:04 GMT
From: sdd.hp.com!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!fafnir.la.locus.com![e-mail]  (Dana H. Myers)
Subject: Has Part 97 changed THAT much? (was Re: PACKET->Internet Gateway)
To: [e-mail]

In article <[e-mail]> [e-mail] (Willis Marti) writes:
>----------------------------------------------------------------------------
>In article <[e-mail]>, [e-mail] (Jon Bloom) writes:
>
>|> repeater is explicitly allowed [see 97.205(d)].  In the case of the
>
>|> 97.109(e) allows packet stations operating above 50 MHz to pass third-
>|> party traffic under automatic control, but "The retransmitted messages
>|> must originate at a station that is being locally or remotely controlled."
>|> Even worse, messages originated by non-hams (where the notion of a control
>|> operator can't possibly be stretched to cover the originator) surely come
>|> under the requirements of 97.115(b) which states in part:
>|>
>|> (b) The third party may participate in stating the message where:
>|>    (1) The control operator is present at the control point and is
>|>        continuously *monitoring* and supervising the third party's

    [remainder deleted]


  My copy of Part 97 is in the ARRL "The FCC Rule Book". None of these
paragraphs (a) exist or (b) say the same thing. Has Part 97 really changed
that much since November 1, 1987?


--
 * Dana H. Myers KK6JQ         | Views expressed here are    *
 * [phone]         | mine and do not necessarily    *
 * [e-mail]        | reflect those of my employer    *

------------------------------

Date: 6 Feb 91 15:36:07 GMT
From: magnus.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!helios!photon![e-mail]  (Willis Marti)
Subject: Internet->packet Gateway
To: [e-mail]

Summary (for those quick with the 'n' key): More comments on Internet<->AMPR
connectivity, with quotes from a couple of postings.

(Jon Bloom) writes:
I think it is.  It has much the same characteristics as a phone patch, in
fact.  But it's not quite what I understood that people wanted.  To the
extent that hams are willing to accept those limitations, it seems like
a good approach to me.
(reply)
The 'limitations' mean that someone on the Internet can not *start* a
connection/session to AMPR.  For hams, there is little limitation.  When
I finish my 'munged' router, I'll have a way for me to initiate from the
Internet.
Also to clarify, I *don't* see AMPR being used to connect other Internet
sites to each other...

(Bruce Walker) writes:
Careful.  While it is quite possible to configure a router so that no one
can successfully inititate a connection to some or all TCP ports
(services), it isn't generally possible to configure a router to not
forward packets which look like part of an established connection but might
not be.  Such bogons would be discarded at their final destination, but if
they had already crossed the airwaves, the damage would have been done.
(reply)
Correct on the router capabilities.  Incorrect, I believe, on the second part.
See other comments below.

(-Sam, WB6RJH ) writes:
packet are a bit harder, as I guess that you'd have to make the
superuser of a particular machine (as designated by the IP address
of a packet) be considered the control operator; you'd want to
have control on that machine of just who was able to send IP
packets to the Internet->packet gateway, and the gateway would
have to restrict the routing of IP packets to radio links to those
from an approved list of ham-operated Internet hosts.  It looks
doable, but probably would be messy to implement.
(reply)
Interesting idea about superuser==control operator.  But you can't restrict
packets to those hosts with ham owners -- what if the ham initiates the
connection? Remember, gateways are (must be) two-way.  It doesn't make sense
to talk about "Internet->packet" instead of "Internet<->packet".
BTW, if you want to look at non-messy ways to implement some kind of access
control, look at cisco, inc.'s router manual.

In article <[e-mail]>, [e-mail] (Sam Sjogren) writes:
|> In article <[e-mail]>, [e-mail] (Brian Kantor) writes...
|> ><description of forging mail, encryption, etc included by reference>
|> >
|> >I would hope that it's only necessary to make a good-faith effort to
|> >ensure that the sender is a ham.  There is no way to be absolutely sure;
|> >it's only a question of how much effort you have to put forth to keep
|> >the pharisees happy.
|>
|> I'd love to be able to operate on this basis, in general.  I'm a
|> big fan of honour systems.  However, if the asshole bureaucrats
|> are going to be, well, assholes, it's good to know that you can
|> come up with the technology to allow connectivity to continue
|> despite the legal requirements.  We have the technology, let's
|> hope that we're not forced to use it.
|>
(reply)
To quote Brian, "There is no way to be absolutely sure;".  There are lots
of repeaters out there that can't guarantee non-hams are denied access. And
the ones that do restrict in some way are a lot less secure that any scheme
proposed so far.
And for both of y'all, remember there are other applications besides email
that people want & must be considered in gateway/access design.


Cheers,
 Willis Marti

------------------------------

Date: 6 Feb 91 18:28:49 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!cci632![e-mail]  (Just another hired gun (n2hkd))
Subject: Internet->packet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>big fan of honour systems.  However, if the asshole bureaucrats
                                             ^^^^^^^

Sorry, if this looks like I'm picking on someone, but
THIS is a prime example of why rec-ham.* can't be routed to
the packet system. I have devised ways of automatically handling
the list of BAD words and such, but then there's always the
doubting Thomas that says it won't happen here.

As in the case of this area, doing something new and experimenting
and prototyping, etc will not happen. All of those ideas and the
people who have them, don't want to take the risk of being wrong,
and therefore rather give lipservice than to attempt to fix the
problem.

Those of us who post here, might want to consider keeping soem of these
newsgroups as to the specification of the FCC, after all I might
be one of those automatic stations that is passing the traffic,
through the Radio system. It would be quite embarassing to get a
citation from Big brother and not even be able to figure out how
you deserved it :-).

As far as passing traffic I would consider having a call sign look
up function to match the addressor [ and  the addressee ] for
verification and thus putting the burden on the orginator.
The call sign info is available and should be deemed accurate,
afterall didn't the FCC have something to do with it?
other mail would be considered third part mail and be handled
separately...

yet another thought on this subject...
--

email:   [e-mail] or cb@cci632  or !rochester!kodak!n2hkd!curtis
Curtis Braun, N2HKD, Computronics, PO Box 1002 Fairport NY, 14450

------------------------------

Date: 6 Feb 91 23:32:56 GMT
From: usc!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu![e-mail]  (Meir)
Subject: Internet->packet Gateway
To: [e-mail]

In article <[e-mail]> [e-mail] (Gary A. Morris) writes:
>In <[e-mail]> [e-mail] (Sam Sjogren) writes:
>
>>In article <[e-mail]>, [e-mail] (Brian Kantor) writes...
>>>They way I plan ... to implement an
>>>internet<->packet mail gateway is actually rather simple:  ...
>>>...  Traffic from the internet to the ham side
>>>is filtered; it must be from a mailbox (i.e., contents of the FROM
>>>line) that is on my list of known hams, which is built by observation
>>>and registration.
>
>>It's terribly trivial to create fake mail.  I can send mail to you
>>with just about anything in the From: line, using SMTP over TCP.
>>Perhaps this would be a case where we'd need authenticated mail,
>
>Sounds like overkill to me.  Couldn't we just say that any unlicensed
>person who sends fake email is illegally operating a amateur radio
>transmitter without a license?
>--GaryM
>--
>Gary Morris                    Internet: lescsse![e-mail]
>Lockheed, Houston, Texas       UUCP:     lobster!lescsse!gamorris
>Space Station Freedom          Internet: [e-mail]
>N5QWC/W5RRR                    Phone:    [phone]

Yes;  But the FCC will accept this only if you have put a lock on your
system.  Some sort of authentification/verification is needed as well as
reasonable checks for illegal traffic.  Otherwise, get ready to read ALL of
the traffic first!

(yes; how many of us lock our cars but not our transmitters?
Maybe this is OK if the room gets locked :-)

 * * * * * * *  ======================= Meir Green
* * * * * * * * ======================= [e-mail]
 * * * * * * *  ======================= N2JPG

------------------------------

Date: 6 Feb 91 03:20:05 GMT
From: sdd.hp.com!samsung!munnari.oz.au!uniwa!vax7![e-mail]
Subject: Painfully long FTP transfers
To: [e-mail]

   I am running NOS version 900828 on an XT clone, and I find that FTP
sessions, long Telnet sessions and so on can be so slow that I'm likely
to be collecting the old-age pension before they finish.
   I tracked down one problem. I was running TNC2 ROM version 1.1.7 in
my TNC, and it seems that the KISS defaults in this version were
wrong. For example, SLOTTIME was set to 50: presumably meaning 500mS.
The KISS v4 source I have used 5 (50 mS). Changing mine to this value
meant that I actually transmitted a packet now and then on a mediumly
crowded channel (sometimes it would take up to 30 seconds on an uncrowded
channel. Is there a good way of determining how SLOTTIME and PERSISTENCE
should be set?
   That's not the whole of the problem, however. It seems that the
recovery timer can take ridiculous values. If something goes wrong (e.g.
the receiver misses a packet or the transmitter misses the ACK), it
can take ages before the transmitter polls the receiver. I was doing
a transfer last night, on a frequency with nobody else around, and
I had one timer value of five minutes. This means that absolutely nothing
happened for five minutes, and I'd just got a packet from the receiver
not long before.
   It seems to me that this is *FAR* too long. Have I set up something
wrong? Is there a default setting that I've missed? And how are these
values determined anyway (I could dive into the sources and find out,
but it's easier to ask someone who knows).
   Suggestions would be greatly appreciated. You might even save the
TCP/IP situation here in Perth!
....Ron

--
 Internet: [e-mail]                | "This brain is
 ACSnet: [e-mail]                      | intentionally
 Bitnet: [e-mail]    | left blank"
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ |

------------------------------

Date: 7 Feb 91 00:01:29 GMT
From: epic![e-mail]  (Phil R. Karn)
Subject: Painfully long FTP transfers
To: [e-mail]

If you're using AX.25 connected mode, try setting "ax25 blimit" to an
estimate of the number of active stations on the channel. Set the
kiss slottime to the keyup delay of the modem, and set the p value
to 256/n, where n is the estimate of active stations on the channel.

You might also set the ax25 irtt to a closer estimate in order to speed
convergence to the true round trip time.

Phil

------------------------------

End of Packet-Radio Digest
******************************