NODE LISTS

One of the nice features with "Net" type nodes is one can connect to his
local node and get a listing of other available nodes in the network.  The
command for this is (often overused) (N)odes.  Implicit in the NODES listing
is the fact that the user should be able to make a successful single connect
to any of the nodes listed.

In the ideal world the users SHOULD be able to make a single connect to
distant nodes.  However this is often not the case.  The primary cause for
direct distant node connect failures (assuming all RF links are in good order)
is due to circuit congestion.  Portions of the RF network may be busy either
with local server to user activity, or with server forwarding.  If this
activity is severe enough, node to node retries may be in progress.  Should
a distant node connect request arrive while this is happening, there will be
delay in it being processed.

Each "Net" type node has a store-and-forward capability.  Depending on an
associated node parameter setting, the node can buffer (store) incoming
packets until they can be delivered to the next node in line to the ultimate
destination.  Due to hardware memory limitations, the typical node usually
buffers four frames.  If circuit congestion conditions cause the buffer to
overflow, a circuit busy (choke) message is sent towards the originator.

The first node from the choke point receives the message and proceeds to
halt outgoing frames and starts to buffer them.  This process is repeated
up the line until the circuit is either cleared or disconnected by being
retried, or timed out.

Each node has various "circuit timers" associated with them.  One purpose
of these timers is to disconnect inactive (presumably unneeded) circuits,
thus allowing active circuit requests to be processed.  (Net type nodes
have a table allocation limit, usually 25, on circuits that can be
simultaneously handled.)  Depending upon the type of circuit, the timers
also affect the retry rate cycle.  Each node has a parameter which defines
the maximum number of retries between adjacent nodes in the circuit path.
Typically the retry counter is set for 10 tries upon which time it reports
a circuit failure.  Another timer affects end-to-end circuit acknowledgements.

Thus delay due to congestion on just one RF link in the network can adversely
impact a "long" direct connect to a distant node.  It can either prevent the
connect from being accomplished, or prematurely disconnect an established
circuit.  For this reason users will find a greater probability of success
if they limit their direct connects to no more than three hops at a time.  This
allows the level 4 (end-to-end) timers more latitude to respond to congested
conditions.

Due to the above network situation, we question whether NodeOps who regularly
maintain a huge listing of "unconnectable" nodes in their nodes listing are
providing a useful service.  Inexperienced users attempting distant node
connects are apt to become discouraged with packet and drop out.  This is a
lose-lose situation.  They take away from the server user base as well as
a possible resource for network upgrades.  Additionally they pass word of
mouth to other potential new packet users, that packet "don't work".

To counteract the above possibility, we suggest all NodeOps set their nodes'
"Minimum Quality to Broadcast" parameter to a higher value which will limit
direct connect requests to "solid" nodes.  Some experimentation will be
necessary to determine which nodes in the listing are the most reliable to
connect with.  This is due to each network having its own individual
reliability characteristics.  Once large node lists are pruned down to solid
routes, don't be suprised if the network congestion level is reduced.  For
every node removed from the listing, an accomulative amount of overhead is
reduced all up and down the system.