### 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 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 weak part of the 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
#WAPR2:W9XYZ-6 232 2 1
#WAPR3:W9XYZ-7 152 5 1

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 acknowledgement 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 acknowledgement 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.

On to Part 8 -  A Q&A concerning node usage

Back to Part 6  -  Part Two of a Green Bay to Milwaukee Packet journey

Back to the Using the Wisconsin Network Index  - Choose a different part to view