Using the Wisconsin Network - Part 7
		       by Andy Nemec, KB9ALN

      Part 6 of our series found us completing our journey from
 Green Bay to Milwaukee. We made a brief layover in Manitowoc, and
 discovered just how to plod along via a backbone. In the course of
 our travels, we have found how to identify these backbones, and
 have discovered just how to determine where they lead. Now, we
 find out how to make our connections both faster and more
 reliable.

      We have learned how the "Routes" command can give us the
 general layout of a nodestack, and how this is important in
 determining just how successful a link will be. Now we will
 discover a shortcut.

      First, let's remind ourselves of the nature of a network, and
 the basis of the network node. Remember that a network is
 esentially a collection of intellegent digipeaters. They try to
 get a packet to a particular destination, and try to verify that
 it has arrived. But a long path of networked nodes leads to an
 interesting situation. Consider the way in which a network of
 nodes actually operates in the example below.

      You are traveling through 5 nodes to get to your friend's
 station a long distance away. You probably realize that a network
 of backbone nodes is used in your connection, and they are.
 Because the Backbone Node aliases are prefaced by a # sign, you
 will not see them with the "N" command. Assume that his LAN node
 shows up on your LAN node's Node List. Here is the path:

 Your    ->  WAPR1 -> #WAPR2 -> #WAPR3 -> #WAPR4 -> WAPR5 -> Your
 Station      LAN    Backbone  Backbone  Backbone  LAN Node  Friend 

      Your logical course would be to tell your LAN node, WAPR1, to
 connect to your friend's LAN node, WAPR5. Then you would tell it
 to connect to your friend's station. The problem is, you are going
 through 5 nodes over a long distance. Worse yet, you really don't
 know that the Backbone nodes exist until you plod along with the
 Routes command, because they are "Hidden" backbone nodes.
 Normally, you would not worry about the backbone nodes, because
 most of the time, the connections are all "automatic".

      You have noticed, however, that your packets seem to take
 forever to reach your friend. All of the sudden, you have a keen
 interest in the path used. You want to see if there is a better
 path, or a more reliable way, to make the connection. Nodes try to
 make a connection over the best possible path, but are subject to
 all sorts of problems when they do. One of these problems is
 related to how a node makes a connection. Remember, a network of
 nodes is really a network of sophisticated Digipeaters, and that
 is how they maintain a connection over a long distance.

      When you connect up to your LAN Node, WAPR1 and tell it to
 connect to your friend's LAN Node, WAPR5, a lot of behind the
 scenes stuff goes on. First, your LAN node knows that the way to
 WAPR5 is through #WAPR2. It connects up to #WAPR2 and, in effect,
 says "I have a connect request for WAPR5 from a user at WAPR1".
 #WAPR2 knows the route to WAPR5 is through #WAPR3. #WAPR2 says "I
 have a connect request for WAPR5 from a user at WAPR1". #WAPR3
 knows that the route to WAPR5 is through #WAPR4. It says to
 #WAPR4, "I have a connect request for WAPR5 from a user at WAPR1."
 #WAPR4 knows how to get to WAPR5, and says that is has the connect
 request from a user at WAPR1. WAPR5 acknowleges, and sends the
 acknowlegement to #WAPR4. This acknowlegement is sent,
 "bucket-brigade" style, back to WAPR1. A "Circuit" is established,
 and each packet is sent in a numbered sequence to help keep track
 of it. This will make certain that each packet will arrive,
 theoretically.

      So far, so good. But there is a problem with the way that
 nodes are commonly networked. Each packet requires an "End-to-End
 Acknowlegement". Remember, in an effort to make sure that packet
 radio is "Error-Free", each packet must be "Acknowleged", verified
 that it has been received correctly. "End-to-End Acknowlegement"
 means that if one station does not hear a packet, it must be
 repeated from the originating station. This is very similar to raw
 digipeating. One end of the connection sends a packet, this packet
 is sent along through each node, and arrives at the other end. The
 acknowlegement packet is sent back to the originating node through
 each node that passed the original packet. To use our example, if
 #WAPR3 does not hear a packet from #WAPR2, WAPR1 will have to send
 the packet again if it does not get an acknowlegement within a
 certain amount of time.

      If one of the backbone-to-backbone node links is marginal, or
 perhaps subject to some interference, then the packets seem to
 take forever to get to their intended destination. This is because
 each packet has to be re-sent along the entire path. It also has
 to be acknowleged along the entire path. Even if the packet
 arrives, safe and sound, the originating node must know that it
 has arrived. Re-sending the acknowlegement wastes time, too.

      Now that we know why a particular node path might be bad, we
 can do something about it. By now you are familiar with the
 "Nodes" command. But you may not know you can use a variation of
 it to find out just how good of a connection is possible to a
 particular node "destination".

      The variation is simple. If you need to know the how WAPR1
 tries to get to WAPR5, just ask it by typing:
 
  N WAPR5
 
  You may see something like this:
 
       WAPR1:W9XYZ-5} Routes to WAPR5:W9XYZ-9
       232 2 0 #WAPR2:W9XYZ-6
       152 5 0 #WAPR3:W9XYZ-7

      What does it all mean? The first column of numbers (232 and
 152) indicate the route quality number - the higher the better.
 The second column is the "Obsolescence Count". This is a measure
 of how long ago a node broadcast was heard, and when it will be
 dropped from the node list. The third column is the "port" number.
 Port 0 is the direct radio port, port 1 is a wireline to another
 TNC on a node stack.

      You can find out, node by node, how the route quality is for
 each step of the journey from WAPR1 to WAPR5. You may wish to use
 the "Info" command to find out where each node is, and then plot
 your progress on a map. You may find, for some reason, that a
 route between two nodes is much weaker than the rest of the path.
 Here is where you can "Segment" the circuit.

      When you "segment" the circuit, you make a manual connection
 between 2 backbone nodes. Why? Because acknowlegement is made
 directly between nodes, along a node-to-node circuit. As the
 proverb goes, a chain is only as strong as it's weakest link. If
 you let the nodes at the weakest link acknowlege to each other,
 the weak acknowlegement is concentrated in one spot - the weak
 link is made stronger. Rather than having an acknowlegement repeat
 through 5 nodes, it is only repeated between 2. Fewer repeated
 packets means a quicker, and a more stable connection.

      Circuit segmenting is not a revoloutionary technique, but it
 will make your network connections better. Next month, we will
 discover some other useful node commands that will help you
 navigate through the network easier.
 
 *End of Part 7*