[nos-bbs] Use of AX25 T2 to reduce transmitted datagram count
Jay Nugent
jjn at nuge.com
Thu Nov 1 03:45:46 EDT 2007
Greetings Skip,
On Thu, 1 Nov 2007, (Skip) K8RRA wrote:
> Hi again from Michigan...
> I have a pretty esoteric [or nit-pickin' ?] issue in hand.
> If it can be duplicated by others, I'd be interested.
>
> The use of AX25 T2 is intended to reduce traffic activity by delaying
> acknowledgment of datagram receipt in order to combine it with the next
> regular "I" datagram. The default value is 1000ms (1 second). In my
> recent cases, I set T2=2000 and that is a bit less than 50% of SRTT for
> the link I am studying. In theory, the net saving is one small packet
> including all the time required to dispatch such a packet. A reasonable
> design I think.
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.
> I now have many cases where I can show regular ack datagrams being sent
> over a months time at the time of AX25 T2 when no other traffic is ready
> to send. Thus I know the T2 timer is working.
>
> I now have some cases where I can show a missing ack datagram at T2 time
> when another "I" datagram is about to be sent. Thus I know that packet
> formation is considering the T2 timer while working to send a datagram.
>
> Here is the problem: I have a few cases where delay in sending the next
> packet after T2 expires is large enough to cause SRTT to expire on the
> remote station and thus initiate a retry. This results in receiving a
> duplicate datagram and next result is a REJ datagram sent by my station.
> The example is based on a VC connection. This is a great waste of time
> & a big retry bloat.
>
> Here are the times involved - based on the time stamp seen in the trace.
> a) The initial datagram NS=6 is received at time 0 seconds
> b) T2 expires but no ACK goes out at 2 seconds
> c) The next outgoing packet with NR=7 departs at time 4 seconds
> d) The duplicate datagram NS=6 is received at time 4 seconds
> e) The REJ is sent out at time 4 seconds
> Admittedly, the time resolution is a bit crude, but the sequence is OK.
>
> The concern I have is for the time lag between step b) and c) above. I
> argue that if a separate "RR NR=7" packet had gone out at step b) above
> there would have been enough time for the remote station to receive and
> process the information thus eliminating the duplicate at step d).
>
> The datagram sent at step c) is encapsulated TCP/IP. Specifically, the
> datagram in c) is in response to a duplicate previously sent by the IP
> network layer -- but that is another story completely.
>
> 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. 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.
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). 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.
But until we can allocate TWO access frequencies to each Hamgate, we
are somewhat stuck with our current configuration, to best serve both the
AX.25 users and the IP users. Neither being optimum.
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.
--- Jay Nugent WB8TKL
"Getting rid of terrorism is like getting rid of dandruff. It cannot
be done completely no matter how hard you try." -- Gore Vidal
+------------------------------------------------------------------------+
| Jay Nugent jjn at nuge.com (734)484-5105 (734)544-4326/Fax |
| Nugent Telecommunications [www.nuge.com] (734)649-0851/Cell |
| Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller |
| ISP Monitoring [www.ispmonitor.net] ISP & Modem Performance Monitoring |
| Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts|
| LinuxNIC, Inc. [www.linuxnic.net] Registrar of the .linux TLD |
+------------------------------------------------------------------------+
2:01am up 8 days, 2:14, 2 users, load average: 0.04, 0.03, 0.00
-------------- next part --------------
Wed Oct 31 14:50:48 2007 - vhf sent: >6>
KISS: Port 0 Data
AX25: K8RRA-1->WA8RSA I NR=6 NS=6 pid=IP
IP: len 40 44.102.132.20->44.102.1.250 ihl 20 ttl 124 prot TCP
TCP: 79->13314 Seq x7bd09001 Ack xaa25dc33 ACK Wnd 5840
Wed Oct 31 14:50:50 2007 - vhf recv: <6<
KISS: Port 0 Data
AX25: WA8RSA->K8RRA-1 I NR=6 NS=6 pid=IP
IP: len 80 44.102.132.1->44.102.132.20 ihl 20 ttl 224 prot TCP
TCP: 25->1025 Seq xb48b8001 Ack x786e2001 ACK PSH Wnd 2048 Data 40
0000 220 HamGate.Ottawa.ampr.org SMTP ready..
Wed Oct 31 14:50:50 2007 - vhf recv:
KISS: Port 0 Data
AX25: WA8RSA->K8RRA-1 RR NR=7
>>>>>>>>>>>>>>>>> Right here at 14:50:52 is a missing transmission?
AX25 T2 = 2001 is used to delay stand-alone response by 2 sec.
This appears to be about 50% of SRTT at the moment.
K8RRA should send "RR NR=7" by itself?
Instead, another 2 seconds elapse before NR=7 goes out as part of next:
Wed Oct 31 14:50:54 2007 - vhf sent: >7>
KISS: Port 0 Data
AX25: K8RRA-1->WA8RSA I NR=7 NS=7 pid=IP
IP: len 40 44.102.132.20->44.102.1.250 ihl 20 ttl 124 prot TCP
TCP: 79->13314 Seq x7bd09001 Ack xaa25dc33 ACK Wnd 5840
Wed Oct 31 14:50:54 2007 - vhf recv: <6<
KISS: Port 0 Data
AX25: WA8RSA->K8RRA-1 I(P) NR=7 NS=6 pid=IP <<< VC: AX.25 repeat
IP: len 80 44.102.132.1->44.102.132.20 ihl 20 ttl 224 prot TCP
TCP: 25->1025 Seq xb48b8001 Ack x786e2001 ACK PSH Wnd 2048 Data 40
0000 220 HamGate.Ottawa.ampr.org SMTP ready..
Wed Oct 31 14:50:54 2007 - vhf sent:
KISS: Port 0 Data
AX25: K8RRA-1->WA8RSA REJ(F) NR=7
>>>>>>>>>>>>>>>> Now you see that RRA has rejected NS=6 repeated by SRTT timer.
At least I believe SRTT is the most likely...:-)
Wed Oct 31 14:50:57 2007 - vhf recv:
KISS: Port 0 Data
AX25: WA8RSA->K8RRA-1 RR NR=0
Wed Oct 31 14:50:59 2007 - vhf sent: >0>
KISS: Port 0 Data
AX25: K8RRA-1->WA8RSA I NR=7 NS=0 pid=IP
IP: len 40 44.102.132.20->44.102.132.1 ihl 20 ttl 124 prot TCP
TCP: 1025->25 Seq x786e2001 Ack xb48b8001 ACK Wnd 5840
-------------- next part --------------
_______________________________________________
nos-bbs mailing list
nos-bbs at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs
More information about the nos-bbs
mailing list