Date: Thu, 11 Mar 93 04:30:13 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 #67
To: tcp-group-digest


TCP-Group Digest            Thu, 11 Mar 93       Volume 93 : Issue   67

Today's Topics:
          advanced-packet is not a substitute for tcp-group.
        advanced-packet list is open for discussion (13 msgs)
           CSMA/CD on radio ? (I see a way CD can be done)
       getting beaten up about having creating advanced-packet
             Hidden transmitters, full- and half-duplex.
                  In-Reply-To: RF Bits  Where next?
                         Is this necessary ?
                     lock files and mail churning
                    repairs at the physical layer

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, 10 Mar 1993 08:27:07 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: advanced-packet is not a substitute for tcp-group.
To: Brian Kantor <brian@UCSD.EDU>

On Tue, 9 Mar 1993, Brian Kantor wrote:
> Now that Bruce has the advanced-packet list running, I can stop running
> the advanced-packet list here, and since tcp-group no longer needs to
> exist, I can channel it into the usenet newsgroup rec.radio.amateur.packet.

Hm. Doesn't sound happy, does he?

Brian, I didn't mean to superscede tcp-group. I meant to create a forum
for discussions that don't seem to belong in "TCP" group, concerning the
implementation of new packet layers that not all of the tcp-group
subscribers seem to be interested in. At the same time, I don't mean
for advanced-packet to be a home for strictly TCP/IP issues.

If you feel tread upon, I'd be happy to back out.

    Bruce Perens

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

Date: Wed, 10 Mar 1993 14:55:48 +0200 (EET)
From: mea@Mea.cc.utu.fi ("Matti E. Aarnio [OH1MQK]")
Subject: advanced-packet list is open for discussion
To: brian@UCSD.EDU (Brian Kantor)

> Now that Bruce has the advanced-packet list running, I can stop running
> the advanced-packet list here, and since tcp-group no longer needs to
> exist, I can channel it into the usenet newsgroup rec.radio.amateur.packet.
> 
> Any objections or comments?
>  - Brian

  Count this as an objection  ( :)  )
Charter of advance-packet:
                ----------------
    This list is for the discussion
 of a possible replacement for AX.25 .
                ----------------

  Mayby KA9Q-NOS is not anymore anything very advanced ?  Has it become
so "standard issue" thing that it has fallen into AX.25/NETROM level in
its exoticity ?  (Now that there are books about NOS also..)

  In my opinnion:
 tcp-group@ucsd.edu  is needed for "production" and "minor"
  developement spinning around KA9Q & derivates, while
 advaced-packet@pixar.com   is for the packet technology of the
  next decade..  (Reaching the blue sky or its equivalent
  for the time beeing)

 /Matti Aarnio <mea@utu.fi> oh1mqk

PS: Advanced yesterday, commonplace today, obsolete tomorrow ?
 (FSK modems...)

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

Date: Wed, 10 Mar 93 14:38:21 GMT
From: Alan Cox <iiitac@pyramid.swansea.ac.uk>
Subject: advanced-packet list is open for discussion
To: brian@UCSD.EDU, mea@Mea.cc.utu.fi

Count this as a second objection. Various people are currently feeding
TCP-GROUP onto the radio network around europe. And tcp group provides
a lot of help and backup. If it became part of rec.amateur-radio.packet
it would be hard to filter and a lot of people would be barred from
forwarding it by the rules of people like UKNET and EUNET on forwarding news received via them.

I shall be glad to see adavanced packet move off tcp-group since it
doesnt belong there.

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

Date: Wed, 10 Mar 1993 09:17:46 PST
From: PMcAfee.El_Segundo@xerox.com
Subject: advanced-packet list is open for discussion
To: brian@ucsd.edu

As I remember, the purpose of the tcp-group is/was the discussion of advanced
packet / networking for the developers and others interested in the advancement
of the art. Correct me if I am wrong ! Maybe what should be done is to move the
"how do I set up my autoexec.net" off to the packet list and let the
development move on.  I did not understand the reason of bruce@pixar:com
setting up another list with the same purpose as the existing tcp-group. Lets
keep the tcp-group setup as originally intended, a forum for the doers. Move
the day-to-day FAQ "how do I" stuff to the packet list.

Just an observer,
Pete
kd6hr.el_segundo@xerox.com

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

Date: Wed, 10 Mar 93 10:03:20 PST
From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: advanced-packet list is open for discussion
To: brian@UCSD.EDU (Brian Kantor)

>Now that Bruce has the advanced-packet list running, I can stop running
>the advanced-packet list here, and since tcp-group no longer needs to
>exist, I can channel it into the usenet newsgroup rec.radio.amateur.packet.
>
>Any objections or comments?
>        - Brian

YES!  Why are we changing to his packet list when this one works perfectly
fine? I already subscribe to way too many lists. To be able to get the
breadth of discussion that this list affords, I would have to subscribe to
several of his. Instead of moving off to something else, lets just stay here
and continue with decent discussions.

Of course, if he wishes to implement a list that discusses coding the full
tcp/ip suite on Adams, C-64s, or TI-9900s, I have no objection to it ;-).

Jack Brindle                                                        
------------------------------------------------------------------------------
ham radio: wa4fib                             internet: jackb@mdd.comm.mot.com

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

Date: Wed, 10 Mar 93 11:38:09 MST
From: "Marvin Match" <match@[128.110.44.31]>
Subject: advanced-packet list is open for discussion
To: brian@UCSD.EDU, tcp-group@ucsd.edu

On Tue, 9 Mar 93 23:08:20 -0800, Brian Kantor wrote:

>Now that Bruce has the advanced-packet list running, I can stop running
>the advanced-packet list here, and since tcp-group no longer needs to
>exist, I can channel it into the usenet newsgroup rec.radio.amateur.packet.
>
>Any objections or comments?
> - Brian

Do I see a range war brewing? I don't mean to speak for anyone but myself,
but it seems to me there are two groups of people that follow this
newsgroup. One clan wants to play TCP-IP using existing stuff beit
NOS or whatever the flavor-of-the-month is. Another clan see's the
deficiencies in running what is basically a set of protocols made for
wires on radios and wants to decide what's going to to be the latest-
and-greatest stuff next year.

If the tchno-whizes move the discussions about how many bytes should be
allocated to the address header et. al. to another place, then that thread
needn't trouble the guy following this group that asks "I'm using <insert
version> NOS on <insert hardware description> and can't get <insert feature>
to work. What am I doing wrong?"

Please don't kill tcp-group.  -Just my opinion.

Marvin Match
KA7TPH
sto

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

Date: Wed, 10 Mar 1993 13:39:07 -0500
From: "Louis A. Mamakos" <louie@NI.umd.edu>
Subject: advanced-packet list is open for discussion 
To: brian@UCSD.EDU

I would like to object, in principle, to changing the list.  I was
just starting to get interested now that there's actually non-DOS
non-AX.25 BBS discussions starting on the mailing list.  Correct me if
I'm wrong, but I never thought that TCP-GROUP was here to exclusively
support NET/NOS.

> Count this as a second objection. Various people are currently feeding
> TCP-GROUP onto the radio network around europe. And tcp group provides
> a lot of help and backup. If it became part of rec.amateur-radio.packet
> it would be hard to filter and a lot of people would be barred from
> forwarding it by the rules of people like UKNET and EUNET on forwarding
> news received via them.

> I shall be glad to see adavanced packet move off tcp-group since it
> doesnt belong there.

Funny, I thought that TCP-GROUP was all about TCP/IP and other
advanced packet radio stuff.  I was surprised that another mailing
list would be necessary at all.

On the other hand, the original purpose of the mailing list seems to
have been long forgotten or ignored, so perhaps its just best to move
on and attempt to escape the AX.25 BBS cruft while the opportunity
presents itself.

louie
WA3YMH

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

Date: Wed, 10 Mar 93 12:19:37 MST
From: Lyndon Nerenberg <Lyndon.Nerenberg@ns.unbc.edu>
Subject: advanced-packet list is open for discussion 
To: PMcAfee.El_Segundo@xerox.com

Part of the problem with tcp-group is there is no "official" charter
(that I'm aware of, anyway). Brian, you would likely save yourself a lot
of grief is you wrote up a charter for the list and sent it out once per
month (and had the listserv send a copy with each new subscription
request). A gentle reminder every thirty days would do wonders towards
keeping discussions on track.

I don't see any overlap between the two lists. Look at the name: TCP-group.
This list is for discussion of TCP/IP networking over packet radio. The
charter of the advanced-packet list is to discuss new MAC and LLC layer
protocols and methodologies. The new list (in my interpretation) isn't
here to address transport layer issues. They seem to compliment each other
quite nicely.

--lyndon

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

Date: Wed, 10 Mar 93 13:01:43 PST
From: enge@almaden.ibm.com
Subject: advanced-packet list is open for discussion
To: TCP-GROUP@UCSD.EDU

The advanced-packet list has a major flaw right now.  Only people who
are subscribed can contribute.  What this means is that anyone sitting
on the other side of a different news distribution scheme (like
myself) can't send anything to the list.

Roy

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

Date: Wed, 10 Mar 93 17:54:03 EST
From: barry@dgbt.doc.ca (Barry McLarnon)
Subject: advanced-packet list is open for discussion
To: tcp-group@ucsd.edu

> 
> On Tue, 9 Mar 93 23:08:20 -0800, Brian Kantor wrote:
> 
> >Now that Bruce has the advanced-packet list running, I can stop running
> >the advanced-packet list here, and since tcp-group no longer needs to
> >exist, I can channel it into the usenet newsgroup rec.radio.amateur.packet.
> >
> >Any objections or comments?
> > - Brian
> 
> Do I see a range war brewing? I don't mean to speak for anyone but myself,
> but it seems to me there are two groups of people that follow this
> newsgroup. One clan wants to play TCP-IP using existing stuff beit
> NOS or whatever the flavor-of-the-month is. Another clan see's the
> deficiencies in running what is basically a set of protocols made for
> wires on radios and wants to decide what's going to to be the latest-
> and-greatest stuff next year.
> 
> If the tchno-whizes move the discussions about how many bytes should be
> allocated to the address header et. al. to another place, then that thread
> needn't trouble the guy following this group that asks "I'm using <insert
> version> NOS on <insert hardware description> and can't get <insert feature>
> to work. What am I doing wrong?"

It's deja vu all over again.  A couple of years ago a discussion like this
took place, and it was concluded at that time that 'how-to' stuff such as
you just described did *not* belong in tcp-group, but should be directed to
the packet radio list/r.r.r.p newsgroup.  The charter of tcp-group at that
time was reaffirmed as that of being the "amateur radio tcp/ip working group,
and discussions of other issues regarding advanced amateur radio networking".
In other words, issues that affected the ongoing development of NOS were
appropriate for this group, but questions on how to use it should go elsewhere.
Of course, as time went on, these guidelines were seldom stated explicitly,
so the 'how-to' stuff crept back in.

Last year, a good percentage of tcp-group traffic was becoming focused on
discussion of developing and using NOS as a BBS which could take part in
mail forwarding with conventional AX25 BBS's.  Since this is a minority
interest, and not exactly "advanced networking" :-), I decided to spin off
a mailing list called nos-bbs to handle it, and hopely help keep the
advanced techies from tuning out of tcp-group.  The nos-bbs list has
attracted quite a bit of the 'how-to' stuff too, but so far the SNR remains
fairly high.

More recently, some of us came to the conclusion that it would be a Good
Thing to spin off yet another mailing list to deal with physical-layer
issues like high-speed modems, modifying radios, etc.  I still think this
would be a pretty good idea.

The recent discussion of "replacing AX25", channel access protocols, et al,
on the other hand, fits squarely within the charter of tcp-group.  I see no
reason to create a new mailing list for it.

The only reservation I have about the tcp-group list is that its host is a
busy one, and turnaround time tends to be rather long.  Let's see how this
one goes...

> Marvin Match
> KA7TPH

Barry VE3JF

-- 
Barry McLarnon                  |  Internet: barry@dgbt.doc.ca
Communications Research Center  |  AMPRnet:  barry@bbs.ve3jf.ampr.org
Ottawa, Canada  K2H 8S2         |  PBBSnet:  ve3jf@ve3jf.#eon.on.can

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

Date: Wed, 10 Mar 93 16:34:48 CST
From: thomas@whitefish.rtsg.mot.com (Jim Thomas)
Subject: advanced-packet list is open for discussion
To: tcp-group@ucsd.edu

I second the need for a list to get help on the present NOS group and 
another list somewhere for the group who are discussing advances in protocols Where it is done is not important but very little on NOS is in rec.packet.
I myself am looking for the present NOS help (GRI 2.0M).
 Jim Thomas thomas@whitefish.rtsg.mot.com
 n9moo@n9moo.ampr.net [44.72.15.135]  

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

Date: Wed, 10 Mar 93 22:56:40 GMT
From: john@its.bt.co.uk
Subject: advanced-packet list is open for discussion
To: Brian Kantor <brian@UCSD.EDU>

Tue Mar 9: Brian Kantor <brian@UCSD.EDU> wrote:
> 
> Now that Bruce has the advanced-packet list running, I can stop running

Well I'm glad Bruce has said that his intention is not to supercede this
group because I, for one, would not be very happy.

> exist, I can channel it into the usenet newsgroup rec.radio.amateur.packet.

Oh no! I get that with my news feed in the office. It is by no means comparible!


For my 2 pence, I do believe there is a need to split the discussions but
it needs to be done carefully. The idea of publishing a charter monthly is
a good one as long as the message is short ie no more than 1 screen.
Possibly we are in need of a third list or a newsgroup...let me explain.

advanced-packet - discussion of low level protocols and novel network
topologies.

tcp-group - discussion of development/porting/bugs of NET/NOS implementations.
I would include in here the implementation of any new protocols from the
advanced-packet list.

nos-users - (for want of a better name) which would be for end users to
discuss configuration problems with their systems/networks. This could
be a newsgroup say rec.radio.amateur.tcpip or both.

 - John

-- 
Office: jvt@its.bt.co.uk
Home:   john@its.bt.co.uk || john@g4rev.ampr.org || G4REV @ GB7TCP.#16.GBR.EU

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

Date: Wed, 10 Mar 1993 15:03:51 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: advanced-packet list is open for discussion
To: enge@almaden.ibm.com

On Wed, 10 Mar 1993 enge@almaden.ibm.com wrote:
> The advanced-packet list has a major flaw right now.  Only people who
> are subscribed can contribute.  What this means is that anyone sitting
> on the other side of a different news distribution scheme (like
> myself) can't send anything to the list.
> 
> Roy

This should be fixed now for the four distribution sites I know about.
The server attempts to protect the list readers from error messages,
subscription requests, and other stuff they should not see. It can be
too restrictive about this - I am still tuning it. It will now, accept
any message from AMPR.ORG, and any message from the sites that do their
own distribution, and from any subscriber.

Regarding the reluctance to move some discussions off of TCP-GROUP, etc.
I really don't mind if they don't move off of TCP-GROUP. I started the
advanced-packet list because I thought I'd provide a home for a discussion
that didn't belong on TCP-GROUP. If enough people don't think that was
appropriate, the advanced-packet list will die, unlamented.

     Bruce

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

Date: Thu, 11 Mar 93 09:29:26 EST
From: dave@eram.esi.com.au (Dave Horsfall)
Subject: advanced-packet list is open for discussion
To: tcp-group@ucsd.edu

I see two distinct groups: one to discuss high-level protocols such as
TCP/IP, over packet radio; they don't care much about how it gets carried
(as long as RF in Amateur bands is involved).

The other wants to see a stake driven through the heart of AX.25; I'm sure
most people won't object, silly government restrictions in some countries
notwithstanding.  The replacement(s) will provide a general low-level
protocol for carrying other protocols, such as in the aforementioned group.

What's the problem?  Perhaps the name "advanced-packet" was an unfortunate
choice, and got someone's nose out of joint?

-- Dave

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

Date: Thu, 11 Mar 93 10:04:12 PST
From: "Jerzy Tarasiuk" <JT@zfja-gate.fuw.edu.pl>
Subject: CSMA/CD on radio ? (I see a way CD can be done)
To: tcp-group@ucsd.edu

After some thinking I realized what way CD can be done on radio: need
use two frequencies, one can be used by every station to send packets,
second is used to signal collisions; when receiving station detects
collision (sees data is unreadable, e.g. many decoding errors) it can
send "collision detect" signal on the second frequencies and both
sending stations should stop sending and backoff. Note the second
frequency don't need to use same BW as the primary used to send data.
Possible problem: receiving node hears only one of senders although
would hear the second if the first would quiet.

Is this approach efficient ?  At light load (especially when there are
only two stations talking) it allows to send more data than would be
possible with central controller (no need to wait for controller's
permission to send). At heavy load will get "collision" signal on most
of packets and central controller becomes much more efficient than CD.

Perhaps best is: CD at light load, switch to cental ctrlr at high ?
A switch signal can be "collision" signal sent by the controller
continuously when it detects air load is too high for CD scheme.
The signal can also carry some information: controller callsign, basic
information about protocols used by it, time marks from it.  73's, JT

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

Date: Wed, 10 Mar 1993 18:17:20 -0800 (PST)
From: Bruce Perens <bruce@pixar.com>
Subject: getting beaten up about having creating advanced-packet
To: Barry McLarnon <barry@dgbt.doc.ca>

> More recently, some of us came to the conclusion that it would be a Good
> Thing to spin off yet another mailing list to deal with physical-layer
> issues like high-speed modems, modifying radios, etc.  I still think this
> would be a pretty good idea.

I would have no objection to hosting such a list, along with individual
lists for all of those various NOS flavors so that you won't see traffic
you aren't interested in. I think that Brian has done a tremendous
service to Amateur Radio, and has in return gotten little more than
aggrivation. I am happy to offload some of the material that he
_doesn't_ want on tcp-group if he would like that. 

> The recent discussion of "replacing AX25", channel access protocols,
> et al, on the other hand, fits squarely within the charter of
> tcp-group.  I see no reason to create a new mailing list for it.

Brian didn't seem to object to the AX.25-replacement discussion going on
in advanced-packet (from personal communication). What he appears to
have objected to most was my calling it "advanced-packet", since he had
hoped that some of the advanced development would be going on in
tcp-group. I didn't see as significance in the name, and picked
"advanced-packet" because I didn't want the name to be over-specific or
something needlessly polarized against AX.25 like "AX.25-REPLACEMENT". 
 
> The only reservation I have about the tcp-group list is that its host is a
> busy one, and turnaround time tends to be rather long.  Let's see how this
> one goes...

On a busy day we move 500 mail messages at Pixar.com, compared to 35,000
at UCSD.edu . I have the advanced-packet list delivering at
"first-class" precedence, and it should take about two minutes for the
server to distribute the list to any sites with SMTP servers that it can
reach directly via the internet. I can maintain the fast service for the
implementor groups, and distribute "user" groups at bulk precedence which
should still be fast enough.

I created advanced-packet because I wanted a quickly-distributed list
where we could discuss the development of new packet radio protocols
without getting in the way of tcp-group. My intent was not to steal
anyone's thunder. I have little sympathy for those who profess a
reluctance to "subscribe to 50 different lists", since I am operating
the list for the contributors, not those who simply read the mail. I
_don't_ have to ask anyone's permission to create advanced-packet, just
as you don't have to post to or read the list if you don't like it.

If Brian will state the charter of tcp-group with some specificity, I
will be happy to host all of the discussions he _doesn't_ want via
listserv@pixar.
     Bruce

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

Date: Wed, 10 Mar 93 16:29:35 PST
From: djc@samisen.UVic.CA
Subject: Hidden transmitters, full- and half-duplex.
To: tcp-group@ucsd.edu

> From: carafe.tay2.dec.com!goldstein (k1io, FN42jk)
> 
> What we have here could be an instance of true CSMA/CD, where "CD" applies
> because everybody's listening even while they're transmitting. 

Is anyone actually USING CSMA/CD on the air?  If so I haven't heard
of it.  I don't know why not because it is relatively easy to do.
 

> This requires ALL stations to be full duplex.  This is easiest to do 
> crossband since it removes the need for cavities.  One station, in this 
> case the one on a big mountain, is a repeater; the others don't repeat.

Misleading.  You'll probably need cavities anyway unless you are the only
thing on the site.  But you only need cavities at the repeater.


> A somewhat less efficient scheme ... is CSMA. ...

CSMA/CD is supposed to be a big win over CSMA when there are lots of
contending stations, though I don't have the numbers.


> Anything with repeaters is going to be far, far superior to any new 
> contention scheme designed to run single-frequency.  All this stuff 
> about tokens and slots et al are basically fighting a losing game in
> the radio environment.  The voice guys had the answer (repeaters) a few 
> decades ago.

If you are talking about spectrum efficiency when you say "far, far
superior" you are just wrong.  The same spectrum that is used for one
full-duplex CSMA channel could be used for TWO simplex channels with a
central, high-altitude hub polling slave stations.  There is nothing
that makes master/slave rotation schemes inherently less efficient than
CSMA or CSMA/CD - so such a scheme would have to be pretty damn awful
before two simplex,  polling channels couldn't carry more traffic than
a single full-duplex CSMA channel under similar propagation conditions.

If you are talking about getting something on the air with typical ham
energy and resources then I would have to say, as the owner of a
full-duplex, crossband 56kbaud repeater, that full-dux CSMA is the way to
go at the present time for many reasons.

You MUST have a high site, though, either way.  Probably nothing can make
CSMA work without it due to the hidden stations.  

>    fred k1io

Thanks, Fred.

-- 
/\/\/\/\/\/
Doug Collinge, try: sol.uvic.ca!samisen!djc
  or:  samisen!djc@sol.uvic.ca
  or:  dcolling@ve7frg.ampr.org
VE7GNU  PBBS: VE7GNU@VE7VBB.#ISLAND.BC.CAN.NOAM

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

Date: Wed, 10 Mar 93 13:32:30 MDT
From: Karl Larsen <klarsen@mercury.arl.army.mil>
Subject: In-Reply-To: RF Bits  Where next?
To: tcp-group@ucsd.edu

> Date: 9 Mar 93 18:39:00 PST
> From: "39A::MUSCHINSKE" <MUSCHINSKE%39A.decnet@scfb.chinalake.navy.mil>
> Subject: RF Bits  Where next?
> To: "TCP-GROUP" <TCP-GROUP@UCSD.EDU>
>
> The FCC in its infinite wisdom has strictly restricted the
> implementation of over-the-air data transmission.  Like it or not,
> AX.25 is the bottom line mode right now.  Our ability to do code
> division spread spectrum is similarly limited.  This needs to be
> changed.  It will probably take some STAs, lobbying and some kind
> of nod to FCC monitoring needs.

     Don't pick on the FCC. They have, for some time now done what
the ARRL asks them to. But that may be changing and if you believe
that a new mode of digital commo is needed, write the FCC with
your proposal.
>
> Where does this discussion lead?  To the beginnings of a RF network
> concept.  The *minimum* network building block would be:
>          ____________      ______________      ____________
>   duplex |          |      |            |      |          | duplex
>   <----->| RF Modem |<---->|    Node    |<---->| RF Modem |<----->
>   High   |          |      | Controller |      |          | High
>   Speed  |__________|      |            |      |__________| Speed
>   Data                     |____________|                   Data
>   Link                           |                          Link
>                                  |
>                            --------------
>                  <-------->|    User    |<-------->
>                            |   Access   |
>                  <-------->|  RF Modem  |<-------->
>                            |____________|
>
> This would replace the current high level single node or node
> stack.  This can be expanded to more links and more user access

     This "network concept" is not new nor even state-of-the-art
Erich. We plan to put a Kantronics data engine running the
wonderful g8bpq switch software on the hill above El Paso, TX. The
"Node Controller" is the data engine. The "RF Modem" is the new
TAPR 19,200 baud job that will talk to the Arizona Link at 9600
from Silver City, NM and to the Albuquerque Link at Las Cruces (My
house). The "User Access RF Modem" is a tnc-2 at 1200 baud
connected to the data engine by a "kiss port".

     So by next fall we should have real data on how well a system
you are proposing works.

> nodes.  The node controller will have to be a lot smarter than the
> current Netrom stack.  The question is how to make this attractive
          ^^^^^^^^^^^^
     I disagree. The Netrom stack works quite well and we are
using them right now. They get away from the collision city
problems of a single tnc node. The inventor of Netrom stated in
his first information sheet that the plan HE had was for every
node to have at least 2 tnc's connected via the back plane (rs-232
style).

> enough to replace the current node system.  The price must be low
> enough that the added capability is worthwhile.
>
> None of the equipment in the diagram really exists today.  The
> development of these pieces is what I am trying to stimulate with
> this discussion.  Please post your comments.  I will even accept
> well reasoned flames! :->

     My FLAME Erich is that we already have this thing your trying
to get hams to use. The reason the data engine isn't in service
today is money. We need more. If your talking data rates of 1 mhz
then we need something different.

>
> Please send follow-ups to the advanced-packet list.  The remainder of my
> ruminations will appear there.


 ____________________________
 | Internet IP 155.148.6.2  |
 |     Fido 1:305/111       |
 |   k5di@k5di.nm.usa.na    |
 |    Ham IP 44.30.2.5      |
 | (505) 678-3145 weekdays  |
 |__________________________|

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

Date: Wed, 10 Mar 93 21:42:04 GMT
From: dave@toth.uwo.ca (David B. Toth)
Subject: Is this necessary ?
To: tcp-group@ucsd.edu

To Brian Kantor:
Brian - did someone ask that ANOTHER list be created ???
If the creation of this other list means stopping this one, then
it hardly makes sense ...
I personally am NOT going to subscribe to 50 bejeezus lists to get
the info I used to get from ONE ...
I sense you are annoyed ...
I don't blame you.

Dave
**************************************************************
* David B. Toth, MD    VE3GYQ                                *
*                                                            *
* INTERNET:       dave@toth.uwo.ca                           *
* AX25 (Packet):  ve3gyq @ ve3gyq.on.can.na                  *
*                                                            *
* "The opinions expressed are my own - No one else could     *
*  think fast enough to defend them ..."  - me               *
**************************************************************

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

Date: Wed, 10 Mar 93 13:32:02 PST  
From: "Erik Olson" <erik@marge.phys.washington.edu>
Subject: lock files and mail churning
To: tcp-group@ucsd.edu

I get the digest and it listed three messages regarding this subject today
(mail looping and .lck files), though the body of those messages did not
show up in the digest.

But since the subect is very near and dear to my heart these days (we run a
small ground-based mail server site based on nos), I can talk about my
experience with this:  If the lock files created for people's mailboxes by
SMTP (ie, erik.lck for me) are not deleted in the normal way (for instance,
you reboot while the lock is still open), the next time you run up NOS the
lock file will remain, erroneously informing SMTP that it cannot write to
the mailbox.  So SMTP requeues the message.  Blech.  There has got to be a
better way than this.

Interestingly, this situation can come up often with the most recent
releases of NOS (I beleive every release since the file I/O was reworked),
because there is a bug in the filesystem that causes the file table to fill
up once you've written 20 or so lockfiles.  (It is likely that you have to
reboot while a lock file still exists.)  I've sent off a report to Phil
about this so it'll be fixed.

   Erik
---
Erik Olson (at work)                     erik@marge.phys.washington.edu
University of Washington                      olson@phys.washington.edu
Cosmic Ray Lab, Phys. 405

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

Date: Wed, 10 Mar 93 10:03:09 PST
From: jackb@mdd.comm.mot.com (Jack Brindle)
Subject: repairs at the physical layer
To: Steve_Wright@kcbbs.gen.nz (Steve Wright)

>>From: jackb@mdd.comm.mot.com (Jack Brindle)  
>>Subject: hidden transmitter routing  
>  
>Message-Id: <9303092305.AA06616@kcbbs.gen.nz>
>Date: 9 Mar 93 23:05:40 EST (Tue)
>
>>  
>>All of these problems could be resolved by going to a central controller with
>>full duplex operation, and full duplex local node operations. The next best  
>>thing  
>>is a full duplex central controller with half duplex local operation.  
>  
>Great! but how to do this in the 70cm band without wiping out many, many  
>frequencies. This is the only band that 9600 baud gear is commercially  
>available, unless you're advocating 1200 baud (shudder.)  

As a now-misplaced GRAPES person active with 56K, I advocate neither 1200 or
9600 baud. 56K is the minimum! A full duplex setup with 56K modems uses 150 KHz
of bandwidth. This could be within a single band or split between two bands.
Probably the best place to put these things is up at 902 MHz. We need to do
it soon before the unlicensed spread-spectrum toys make the band unusable.
  
>The only  ways I can see is either use spread-spectrum multiple access at 38  
>or 64Kbit, or use individual gunnplexor modules for each user. Lotsa money  
>for a packeTen switch (or five!) but the microwave units are cheap!  Would be 
>able to run 1MBit without much problem. Wouldn't this go well ....The US hams 
>(most of you?) shoud be able to get a STA to run a meg on 10 GHz.  

This, of course, assumes no trees or other blockages around. Microwave is
notorious for these problems. That would be the right place to do high-speed
spread-spectrum, though, since ss requires LOTS of bandwidth for reasnable
spreads. Remember, at least with DS, the greater the spread, the better things
are for bit recovery. Also, microwave isn't that cheap. My 56K system cost me
far less in time, effort and money than the microwave system we are discussing
would... (Remember to include the digital side that pumps data in and out of
the computer at the 1 MB rate!)

However... I really believe the microwave approach is worth experimenting with,
and would encourage someone who knows what they are doing to persue it. That
is, after all, what this "hobby" is all about, experimentation!
  
>over to you.  

Tag, you're "it."   :-) :-) :-)

Jack Brindle                                                        
------------------------------------------------------------------------------
ham radio: wa4fib                             internet: jackb@mdd.comm.mot.com

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

End of TCP-Group Digest V93 #67
******************************
******************************