[nos-bbs] Use of AX25 T2 to reduce transmitted datagram count

[(Skip) K8RRA]

Thanks for the RAPID and through response Jay.
I'm afraid you combined two issues in two separate mails from me. 
It is appropriate to separate them again into NOS and DRG...

On Thu, 2007-11-01 at 02:45 -0500, Jay Nugent wrote:
> Greetings Skip,
>>SNIP<< 
> 
>    This is refered to as the "Window", or "Sliding Window".  It is a
> maximum number of packets that can be sent within a 'window of time' with
> only ONE ack being returned (reflecting the sequence number of the highest
> frame number sucessfully received).
> 
>    So if we have a window of 7, and we send 5 frames, and the 4th frame
> fails CRC, then we ACK only the 3rd frame.  On the retry the sending
> station will know to start the next transmission with a repeat of frame #4
> and #5 and may add more frames to this transmission to fill the window to
> a max of 7.
It seems you have combined the MAXFRAME and T2 parms?

The standard for MI-DRG is to use MAXFRAME=1 meaning: send only one
frame then wait for a ACK.  If MAXFRAME were allowed to grow between 2
and 7 then your description above would apply.  

T2 on the other hand only creates a wait-to-ACK time.  Because both an
RR and an I frame carry the NR= data, it makes sense to put the NR= into
the longer I frame *when one is ready to send* than to inject the short
RR frame before the I frame to ACK the last good "window" packet as you
described.  The T2 timer is the optimization technique to remove
redundant traffic -- independent of "window" frame count.

There is a timing issue here.  From my example to NOS we can see that
the ACK did not transmit quickly enough to prevent the remote station
from retransmitting a formerly successfully received packet.

> > I have reduced T2 to 700, but this is not a comfortable solution.  I
> > have attached the trace [annotated by myself] to show the detail.  My
> > next step is to examine the system to find if my configuration has
> > impact on the 2-second delay between T2 expiration and "send" the next
> > "I" packet.  Any help from my peers will be very welcome!
> 
> 
>    Here is the crux of the problem.  We *need* to support the AX.25 only
> stations on the same frequency as the IP stations.  
I am very much on the same page as you are on this point.  

Beyond that:
Perhaps we differ on VC/Datagram issue?  It is my contention that VC is
an appropriate choice for weak links as found in hf, long links of vhf &
uhf where signal strength is no better than S-4(?), and where "hidden
transmitter" nodes are a major issue.  Where two nodes share a clean S-9
radio link then let's use Datagram.  With both choices, the AX.25
traffic needs to co-exist -- now we only need to focus on shared
bandwidth to make it a fair trade...

> If we tune the
> parameters for best throughput for IP, the first time an AX.25 user comes
> on frequency the IP stations back off so far that LITTLE OR NO traffic
> will flow!  This is precisely why Michigan reserved 147.56 as "IP Only"  
> back in the 90's.
While it is true that the VC-Datagram-IP choices may not coexist well
together if they are miss-configured, the basic issue remains: a 1200B
packet link in the middle of an Internet linked network is a major pain
in the rear.  You just can't get much data rate when the channel is
clear -- but when it is shared you need to get that next cup of coffee
while you wait.

My point in the DRG mail is the bad consequence of rapid retry is seen
as many retry packets that plug up the channel with garbage.  My point
in the NOS mail is that the T2 timer *appears* to have failed and the
consequence is again a retry packet.  >BUT: They are separate issues<

> 
>    If we allocate the frequency to IP-only, then we *should* use DATAGRAM
> only.  This would remove the double ACKS we see at both the LINK LAYER
> (AX.25) *AND* at the NETWORK LAYER (IP).  
Wait a minute -- double acks are a non-issue when T2 works.  Please
re-think what you have said.  It is true that both AX and IP *may* be
configured to ACK, but the acknowledgment data integrates into each
protocol in a way that *potentially* does not add to the packet count or
into the on-air time.  

When timers conflict then yes the result is as we have both argued.
   
> You have identified the problem
> where the AX.25 layer will retry a lost frame while an entirely different
> layer, IP, with an entirely different retry algorythm, will retry the IP
> packet as well. Resulting in duplicate frames/packets being sent due to a
> single noise hit.  Not good.
I am certainly not the first to run into the issue as you present it.
However there is higher level view that needs to be considered -- I did
that in my mail to MI-DRG and not here.

I am satisfied [as I presented in the DRG mail] that the DRG "Live
Station Monitor" is functioning only at an IP level and is configured
for fast Internet transaction and not adjusted for slow routes to my
station and perhaps some other out-lying RF connected nodes on the
network.  It has nothing to do with VC, Datagram, DSL, ethernet, AX.25
subnet, or any of the other link types in the network.  It has
everything to do with the lost packet feature driven by SRTT, MDEV,
RETRIES, MAXWAIT, and so forth in a long and [as you point out]
interrelated set of parms.

That issue needs to stay inside MI-DRG and not be part of the NOS set of
issues.  OK?

> 
>    But I appreciate your experiments.  It is quite possible the values we 
> are using could indeed be improved upon.  But when you get the link 
> performing the way you like (IP), throw a couple AX.25-ers in there and 
> see if the IP still moves packets.
Well - that is very much our situation here in Ottawa County on the
145.070mhz channel we use as our link to hamgate.ottawa.ampr.org because
our test bed is normally busy with AX stuff while we focus on our IP
stuff.  I don't find the situation as *dreadful* as you depict, at least
after tweaking the parms we have.

> 
>       --- Jay Nugent  WB8TKL
>  
Having written response to Jay, I hope the NOS community will appreciate
the separate and distinct issues that present themselves in similar
ways.

After reading Jays comments, and in considering how to respond, I opened
up trace.c to verify the source of trace data.  If "sent:" records come
from an echo produced by the TNC in KISS mode then the time stamp
reflects the moment the outgoing packet completes transmission thus the
two seconds of delay between T2 and "sent" may be explained by a busy
radio and a TNC waiting for a clear channel.  Well -- I'm not finished
following the chain of events yet and could still use some help to
interpret the trace time stamp.  There is still something strange about
T2.

Now please permit me to ask a new question related to DRG...  Picture
this:
  1) Your jnos node is midway between the source and destination for
traffic.  Your station does not originate nor terminate the route, it
just passes traffic on.
  2) Your jnos node on the left hand is connected fast and on the right
hand connected slow.
  3) the originating station somewhere on your left is rapidly filling
you up with retry frames because it has no ACK back from destination.
  4) the destination station somewhere on your right is active but is
taking only a little bit of data at a time and not completing much prior
to ACK.  Let's say you are convinced that the destination station will
eventually arrive at sending an ACK.

What is a responsible jnos node to do?  You can not ACK for the slow
station -- that is his responsibility.  You can not slow down the source
station -- that is his problem to detect a reasonable RTT.  I have seen
this happen in both IP and NET/ROM networks.

Has anyone considered simply verifying the retry is exactly identical
then dropping the retry?  This action would preserve the original packet
arriving at destination in tact and at the same time clear the channel
of much trash repeats?

Thanks so much!

73
de [George (Skip) VerDuin] K8RRA k