PACKET RADIO: Network Node Level Three Timing
(This text from the W8IZ packet radio bulletin
board. It's formatted to fit a 80 character screen.)
Fellow Node Sysops:
I see some of you are making the same mistake that I was making not too
long ago with Net/Rom parameters. Parameter 9, transport timeout, should be
larger than the maximum number of seconds required to move a packet from one
end of the network to the other and back again. I see some of the nodes still
have this parameter set to less than a minute. Our network is not that good!!
Level 3, the transport layer, implements the "end to end" acknowledgement
that was taken away from level 2 when we got rid of the digipeaters. If the
end to end timeout is too low, then one end of the link (consisting of many
hops) will retransmit a bunch of packets (up to the transport requested window
size, parameter 13) before the first bunch of packets has had time to
propagate to the other end of the network and an acknowledgment return.
Retransmitting too soon doesn't help at all, and just adds to the congestion.
For example, I connect level 2, AX.25 to CMH from my home station. Then
I connect Level 3, Net/Rom to MTG, and then to MFD. I level 3 link has 6
hops, CMH to #CMHU1, #CMHU1 to #MTGU, #MTGU to MTG, MTG to #MTGU, #MTGU to
#MANU, and #MANU to MFD. Each of those hops consists of a Level 2 link that
is Level 2 acknowledged across each link. If I type "I <cr>" on my
terminal,
CMH encases my data (the "I <cr>") in a Level 3 packet and in turn encases
that in a level 2 packet and it to #CMHU1, the first hop. #CMHU1 does a level
2 ack to CMH across the RS232 connection. Then #CMHU1 sends the Level 3
packet encased in a level 2 packet to #MANU. #MANU sends a level 2 ack to
#CMHU1, and the cycle repeats until my data arrives at MFD. If my packet gets
to MFD, MFD will responds using the same scheme above. MFD's response will
include the level 3 end to end acknowledgement, along with the results of my
"I" command. If that reponse gets back to CMH before the "transport
timeout"
expires, then CMH will not need to retansmit. If, however, the response from
MFD does not get to CMH before the "transport timeout" expires, CMH will again
transmit my initial "I <cr>" encased in a level 3 packet encased in a
level 2
packet, and the cycle would begin anew.
The reason that end to end acknowledgement is required even though we
have "error free" level 2 links, is that there are valid corcumstances when a
node may discard a packet. The most frequent circumstance is congestion, the
nodes buffers are full because the node can't transmit because the channel is
already occupied. The end to end timeout guarantees that the network will try
again after allowing a reasonable chance for Level 2 to do its job.
The downside of making the end to end timeout too long, is a long delay
to recover from discarded packets. However, if we don't do Level 3 retries
too often, maybe we won't have as many instances of discarded packets. And as
I said above, making the end to end timeout too short merely increases network
overhead without making anything faster.
I've set the CMH nodes end to end timeout at 300 seconds (5 minutes).
Since making this change, the amount of traffic on the CMH to MTG link has
noticably decreased. Previously, when I had the Level 3 timeout set to 40
seconds, I saw the same exact data transmitted (and acknowledged by #MTGU)
repeatedly.
I'd like to hear comments from the other node Sysops as to whether my
explanation is clear or not, and whether you agree with my conclusion or not.
I have been digging around in the TheNet code, as well as studying
networking in general in relation to my other job as a systems programmer.
Hopefully, more networking hints and kinks will emerge.
Next time: the results of a comparison between TheNet 1.01 and TheNet
1.1-E.
73, Vic, K1LT @ W8CQK
Return to Packet FAQuette Index