standard_window_size.

standard_window_size.

[John Ronan]

Hi,

I've stumbled across a problem and I'm not sure where to look next.

I've been attempting to do some testing over ax25.  I've been using  
kiss mode on both ends.  Now, when I attempt to transfer data using a  
window size of 3, it seems that the kernel seems to think that the  
window size is still 2, even though I've set it to three.

In the example below I've connected using axcall -w 3 to a PTCIIex  
TNC's PMS (EI7IG-8)that has maxframe set to 3.  I've asked if I can  
read a message, it attempts to dump three packets, but this end  
replies after only 2.

1200: fm EI7IG to EI7IG-8 ctl I32^ pid=F0(Text) len 4 20:29:42
0000  r 1.
1200: fm EI7IG-8 to EI7IG ctl I33^ pid=F0(Text) len 49 20:29:44
0000  ..file: EI7IG  nr: 1  from: EI7IG  title: .-----.
1200: fm EI7IG-8 to EI7IG ctl I34^ pid=F0(Text) len 255 20:29:46
0000  test.OSCAR III [-]           ..1 01293U 65016F   07002.23646176
0040  -.00000070  00000-0 -98573-5 0  8666..2 01293  70.0715 309.6096
0080  0021217 281.7228  78.1502 14.04522134133852..AO-5 [-]
00C0       ..1 04321U 70008B   06364.97899830 -.00000031  00000-0  10
1200: fm EI7IG to EI7IG-8 ctl RR5v 20:29:47
1200: fm EI7IG-8 to EI7IG ctl I35^ pid=F0(Text) len 255 20:29:47
0000  000-3 0  8153..2 04321 102.0762 344.1977 0027719 242.8215 117.00
0040  30 12.52148418688218..AO-6 [-]                ..1 06236U 72082B
0080    07001.53324891 -.00000027  00000-0  10000-3 0  7711..2 06236 1
00C0  01.4761  37.7834 0004002 202.4746 157.6152 12.53069131564971..A
1200: fm EI7IG-8 to EI7IG ctl I35^ pid=F0(Text) len 255 20:29:50
0000  000-3 0  8153..2 04321 102.0762 344.1977 0027719 242.8215 117.00
0040  30 12.52148418688218..AO-6 [-]                ..1 06236U 72082B
0080    07001.53324891 -.00000027  00000-0  10000-3 0  7711..2 06236 1
00C0  01.4761  37.7834 0004002 202.4746 157.6152 12.53069131564971..A
1200: fm EI7IG to EI7IG-8 ctl REJ6v 20:29:50

If standard_window_size doesn't set the window size, where else can I  
do it?  I've tried several kernels and two TNC's at this stage.

Help appreciated,
de John
EI7IG

Re: standard_window_size.

[John Ronan]

Curiously,

No matter what I set it to, it remains at 2.

Thoughts appreciated.

de John
EI7IG

On 1 Dec 2008, at 20:32, John Ronan wrote:

> Hi,
>
> I've stumbled across a problem and I'm not sure where to look next.
>
> I've been attempting to do some testing over ax25.  I've been using  
> kiss mode on both ends.  Now, when I attempt to transfer data using  
> a window size of 3, it seems that the kernel seems to think that  
> the window size is still 2, even though I've set it to three.
>
> In the example below I've connected using axcall -w 3 to a PTCIIex  
> TNC's PMS (EI7IG-8)that has maxframe set to 3.  I've asked if I can  
> read a message, it attempts to dump three packets, but this end  
> replies after only 2.
>
> 1200: fm EI7IG to EI7IG-8 ctl I32^ pid=F0(Text) len 4 20:29:42
> 0000  r 1.
> 1200: fm EI7IG-8 to EI7IG ctl I33^ pid=F0(Text) len 49 20:29:44
> 0000  ..file: EI7IG  nr: 1  from: EI7IG  title: .-----.
> 1200: fm EI7IG-8 to EI7IG ctl I34^ pid=F0(Text) len 255 20:29:46
> 0000  test.OSCAR III [-]           ..1 01293U 65016F   07002.23646176
> 0040  -.00000070  00000-0 -98573-5 0  8666..2 01293  70.0715 309.6096
> 0080  0021217 281.7228  78.1502 14.04522134133852..AO-5 [-]
> 00C0       ..1 04321U 70008B   06364.97899830 -.00000031  00000-0  10
> 1200: fm EI7IG to EI7IG-8 ctl RR5v 20:29:47
> 1200: fm EI7IG-8 to EI7IG ctl I35^ pid=F0(Text) len 255 20:29:47
> 0000  000-3 0  8153..2 04321 102.0762 344.1977 0027719 242.8215 117.00
> 0040  30 12.52148418688218..AO-6 [-]                ..1 06236U 72082B
> 0080    07001.53324891 -.00000027  00000-0  10000-3 0  7711..2 06236 1
> 00C0  01.4761  37.7834 0004002 202.4746 157.6152 12.53069131564971..A
> 1200: fm EI7IG-8 to EI7IG ctl I35^ pid=F0(Text) len 255 20:29:50
> 0000  000-3 0  8153..2 04321 102.0762 344.1977 0027719 242.8215 117.00
> 0040  30 12.52148418688218..AO-6 [-]                ..1 06236U 72082B
> 0080    07001.53324891 -.00000027  00000-0  10000-3 0  7711..2 06236 1
> 00C0  01.4761  37.7834 0004002 202.4746 157.6152 12.53069131564971..A
> 1200: fm EI7IG to EI7IG-8 ctl REJ6v 20:29:50
>
> If standard_window_size doesn't set the window size, where else can  
> I do it?  I've tried several kernels and two TNC's at this stage.
>
> Help appreciated,
> de John
> EI7IG
> --
> To unsubscribe from this list: send the line "unsubscribe linux- 
> hams" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
John Ronan <jronan@tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org

Re: standard_window_size.

[Bent]

Hi John

I decided to take a closer look at your trace, and I interpret it this way:

   EI7IG            EI7IG-8

I  ->  N(R) = 3
                      N(S) = 3  <-  I
                      N(S) = 4  <-  I
RR ->  N(R) = 5
                      N(S) = 5  <-  I
                      N(S) = 5  <-  I
REJ ->  N(R) = 6

In words: EI7IG sends a frame that tells that the next frame expected
is no. 3. EI7IG-8 sends frames no. 3 and 4 and they are acked by
EI7IG. EI7IG-8 now sends frame no. 5 and 3 seconds later it resends it
for reasons unknown. This second no. 5 frame is rejected by EI7IG
which expect frame no. 6. having received the first frame no.5.

As far as I can see this does not have much to do with window size.
Why the second frame 5 is not received - and acked - by EI7IG should
probably be answered first.

Please tell if you agree with my interpretation of the exchange.

Best 73 de Bent/OZ6BL

RE: standard_window_size.

[Bob Donnell]

A suggestion too for troubleshooting this, is to have a 3rd station/TNC
monitoring the activity, and logging that information.  That will show the
sequence of actual on-air transmissions.  

One of the generalized problems with using KISS and/or queues that are
isolated from knowing that multi-frame transmissions are occuring is that
the station receiving the I frames usually generates an ack for that single
I frame, and puts it in the transmit queue - without waiting to see if an
additional I frame (or more) in the same sequence that the information
sending station is sending is following.  So when the I frame receiving
station is finally granted access to the channel, all of the individual
queued ack packets (acking one I frame at a time) are transmitted.  The I
frame sending station gets the first ack, notes that it's only acking the
first I frame of a multi-frame window.  It's not any more clever than the
receiving station, and doesn't wait to see if more ack packets are coming,
so it immediately queues up a replacement 2nd (and perhaps more) I frame.
There's no way to flush that queue, so using a larger window size - which
can make things a lot more efficient, has the behavior of a lot of
duplicated frames.

This whole layer 2 acknowledgement problem is one of the reasons that when
we had a very active IP network in the Seattle area, we used datagram mode,
with UI frames at the AX.25 level, almost exclusively.  This moved the retry
timing up to the IP level, where the timing is adaptive, and fairly quickly
the sender learns enough about the channel to not expect ack packets
instantly for each frame.

The real root of the problem is that the AX.25 driver is (in most air
interfaces) too decoupled from the activity on the RF channel.  One of the
ideas I had for trying to address this in the AX.25 stack was to make the
AX.25 driver aware of the channel speed, so that it could adopt sensible
timers for retries and generating ack packets.  That approach could work in
the absence of any information on whether the channel is busy.  

As a more advanced option for serial-port-interfaced TNC's is that I know
that some TNC's can be configured to provide CD information, usually on the
CD line.  That information could be used by the AX.25 driver to pause
timers, as an alternate AX.25 driver attachment option.

This is one of the areas where the 6PACK interface choice shines - almost
all of the intellegence is removed from the TNC, even more so than KISS, and
made a function of the AX.25 driver, providing tight coupling.  The same
should be true of the AX.25 HDLC card driver, but I if I remember right it
too has been decoupled from the AX.25 stack, so it doesn't perform much
better in AX.25 connected mode than a KISS TNC. 

Assuming that the AX.25 driver has actually been modified to ignore
window_size, this decoupled operation might be why a driver maintainer might
have made that choice.

Some of my observations date back to when I was running an W0RLI/G8BPQ BBS
in the early '90's, and discovered that on a very busy channel, I had to set
AX.25 frame acknowledgement timers to as long as 40 seconds, otherwise the
scenario I described would happen, just moving the data from the PBBS to the
NET/ROM node - and it would be a cascading problem, as more packets got
queued up in the TNC for transmission.  If I was present, the whole thing
could be "fixed" temporarily by rebooting the TNC, so it dropped all of the
packets it had queued.

I hope what I've suggested and explained makes sense.

73, Bob, KD7NM

-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Bent
Sent: Tuesday, December 02, 2008 1:51 PM
To: John Ronan
Cc: John Ronan; Linux-Hams
Subject: Re: standard_window_size.

Hi John

I decided to take a closer look at your trace, and I interpret it this way:

   EI7IG            EI7IG-8

I  ->  N(R) = 3
                      N(S) = 3  <-  I
                      N(S) = 4  <-  I
RR ->  N(R) = 5
                      N(S) = 5  <-  I
                      N(S) = 5  <-  I
REJ ->  N(R) = 6

In words: EI7IG sends a frame that tells that the next frame expected is no.
3. EI7IG-8 sends frames no. 3 and 4 and they are acked by EI7IG. EI7IG-8 now
sends frame no. 5 and 3 seconds later it resends it for reasons unknown.
This second no. 5 frame is rejected by EI7IG which expect frame no. 6.
having received the first frame no.5.

As far as I can see this does not have much to do with window size.
Why the second frame 5 is not received - and acked - by EI7IG should
probably be answered first.

Please tell if you agree with my interpretation of the exchange.

Best 73 de Bent/OZ6BL
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: standard_window_size.

[cathrynham]

Bob Donnell wrote:
>
> As a more advanced option for serial-port-interfaced TNC's is that I know
> that some TNC's can be configured to provide CD information, usually on the
> CD line.  That information could be used by the AX.25 driver to pause
> timers, as an alternate AX.25 driver attachment option.
>   

This sounds like a good idea.  If CD is available we only queue the packets
when CD transitions from 1 to 0, indicating that the sending station is 
done transmitting
and only after the stack has processed its entire receive queue.

Maybe not ideal, I was thinking the ax25 code could wait for 'nothing has
been received for XX time' as a way to hackily detect the 'end of 
transmission'
on a half-duplex channel.


I'm not sure how you get that 'CD' bit all the way from the TNC up to the
Linux ax25 stack.  It would be a hideous hack, but could we just
write a file to '/proc/net/ax25/ax0/CD and set that to 0 or 1?

Re: standard_window_size.

[John Ronan]

On 2 Dec 2008, at 23:12, Bob Donnell wrote:

> A suggestion too for troubleshooting this, is to have a 3rd station/ 
> TNC
> monitoring the activity, and logging that information.  That will  
> show the
> sequence of actual on-air transmissions.
>
Good idea, hadn't though of that.

> One of the generalized problems with using KISS and/or queues that are
> isolated from knowing that multi-frame transmissions are occuring  
> is that
> the station receiving the I frames usually generates an ack for  
> that single
> I frame, and puts it in the transmit queue - without waiting to see  
> if an
> additional I frame (or more) in the same sequence that the information
> sending station is sending is following.  So when the I frame  
> receiving
> station is finally granted access to the channel, all of the  
> individual
> queued ack packets (acking one I frame at a time) are transmitted.   
> The I
> frame sending station gets the first ack, notes that it's only  
> acking the
> first I frame of a multi-frame window.  It's not any more clever  
> than the
> receiving station, and doesn't wait to see if more ack packets are  
> coming,
> so it immediately queues up a replacement 2nd (and perhaps more) I  
> frame.
> There's no way to flush that queue, so using a larger window size -  
> which
> can make things a lot more efficient, has the behavior of a lot of
> duplicated frames.
>
Ok, but if the window is set to 7, shouldn't it wait until it sees 7  
frames  or  N Frames + T2

> This whole layer 2 acknowledgement problem is one of the reasons  
> that when
> we had a very active IP network in the Seattle area, we used  
> datagram mode,
> with UI frames at the AX.25 level, almost exclusively.  This moved  
> the retry
> timing up to the IP level, where the timing is adaptive, and fairly  
> quickly
> the sender learns enough about the channel to not expect ack packets
> instantly for each frame.
>
> The real root of the problem is that the AX.25 driver is (in most air
> interfaces) too decoupled from the activity on the RF channel.  One  
> of the
> ideas I had for trying to address this in the AX.25 stack was to  
> make the
> AX.25 driver aware of the channel speed, so that it could adopt  
> sensible
> timers for retries and generating ack packets.  That approach could  
> work in
> the absence of any information on whether the channel is busy.
>
ok...

> As a more advanced option for serial-port-interfaced TNC's is that  
> I know
> that some TNC's can be configured to provide CD information,  
> usually on the
> CD line.  That information could be used by the AX.25 driver to pause
> timers, as an alternate AX.25 driver attachment option.
>
> This is one of the areas where the 6PACK interface choice shines -  
> almost
> all of the intellegence is removed from the TNC, even more so than  
> KISS, and
> made a function of the AX.25 driver, providing tight coupling.  The  
> same
> should be true of the AX.25 HDLC card driver, but I if I remember  
> right it
> too has been decoupled from the AX.25 stack, so it doesn't perform  
> much
> better in AX.25 connected mode than a KISS TNC.
>
> Assuming that the AX.25 driver has actually been modified to ignore
> window_size, this decoupled operation might be why a driver  
> maintainer might
> have made that choice.
>
> Some of my observations date back to when I was running an W0RLI/ 
> G8BPQ BBS
> in the early '90's, and discovered that on a very busy channel, I  
> had to set
> AX.25 frame acknowledgement timers to as long as 40 seconds,  
> otherwise the
> scenario I described would happen, just moving the data from the  
> PBBS to the
> NET/ROM node - and it would be a cascading problem, as more packets  
> got
> queued up in the TNC for transmission.  If I was present, the whole  
> thing
> could be "fixed" temporarily by rebooting the TNC, so it dropped  
> all of the
> packets it had queued.
>
> I hope what I've suggested and explained makes sense.
>
Yes, very educational (though I'm sure I'll have to read it a few  
times to fully understand it all).

Now, I did some more testing

Node 1 (EI7IG-8) (either in Kiss or with minicom in converse mode)  
can connect to Node 2 (EI7IG funny one) and when I ask for a long  
file, I get the full 7 packets before node 1 sends the   ack.

I'm beginning to think its a kernel issue as EI7IG is running an  
older kernel, EI7IG-8 is running a fairly new kernel.  I've been slow  
to upgrade EI7IG because I've been unable to get my serial ports (pci  
card) working right on the newer kernels. I guess now is time to do it!

John

Re: standard_window_size.

[John Ronan]

Ok,

Now I'm even more baffled, and I think digging in the code is going  
to have to be the answer here.

Kernel updated to be the same on both (2.6.24.3), my serial ports are  
working. Now, both ends are behaving the same protocol wise. That is  
after the data source sends two packets, the sink sends a RR.

both sides have standard_window_size set to 7, and in axports &  
ax25d.conf, the window is set to 7

However the behaviour is different on both ends, let me try and explain
NodeA  sends the RR1 after 2 packets, RR2 after next 2, RR3 after  
next 2 and RR4 after next 2 (looking at axlisten -t -a on the host)

Node B sees RR1 & RR4

NodeB sends RR1 after 2 packets, transmitting over NodeA, etc as I've  
already described (even though the TNC isn't in full-duplex mode as  
far as I can tell).

Thoughts appreciated. Tomorrow I'll rebuild the kernel on one side  
with the default window size set to 7 to see what happens.

Cheers
de John
EI7IG

--
John Ronan <jronan@tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org

Re: standard_window_size.

[John Ronan]

Morning,

I tested over the weekend (and I though I had posted it already).

After changing the kernel header to have the standard window size =  
3. This was verified when I booted the machine as the entry in /proc  
was 3.  However, once I connected to it and started passing data, it  
again behaved as though it was set to 2.

RR after every second packet

Suggestions as to where to look next appreciated.

Regards
de John
EI7IG

On 3 Dec 2008, at 22:33, John Ronan wrote:

> Ok,
>
> Now I'm even more baffled, and I think digging in the code is going  
> to have to be the answer here.
>
> Kernel updated to be the same on both (2.6.24.3), my serial ports  
> are working. Now, both ends are behaving the same protocol wise.  
> That is after the data source sends two packets, the sink sends a RR.
>

--
John Ronan <jronan@tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org

Re: standard_window_size.

[Dave Platt]

John Ronan wrote:
> 
> Morning,
> 
> I tested over the weekend (and I though I had posted it already).
> 
> After changing the kernel header to have the standard window size = 3. 
> This was verified when I booted the machine as the entry in /proc was 
> 3.  However, once I connected to it and started passing data, it again 
> behaved as though it was set to 2.
> 
> RR after every second packet
> 
> Suggestions as to where to look next appreciated.

I think I'd start by using a third packet station, to monitor the whole
connection and see if there's any protocol negotiation taking place
between the two systems (and, if so, what protocol parameters are being
negotiated).

It's been a while since I looked at AX.25 in detail, but here are some
thoughts:

[1] Negotiation between the two peers can result in different parameters
     being used than you may have programmed in.  I believe that the
     maximum window size will be the *smaller* of (a) what the sender
     decides it should send and (b) what the receiver says that it's
     willing/able to accept during the (optional?) protocol negotiation.
     You may need to snoop the channel (or use Ethereal or a similar
     software protocol sniffer on one peer) to see all the details.

[2] I think that the number of packets that the sender will transmit
     before it drops carrier and waits for an RR may depend (in some
     implementations at least) on the value of the T1 timer and the
     channel baud rate, as well as on the (fixed or negotiated) window
     size.  If I recall correctly, the T1 timer is the amount of time
     that the sender is willing to wait for an RR, after the packet is
     transmitted, before it will decide that the packet was lost and
     will retransmit it.  If this is set too low it may cause the sender
     to reduce the effective window size, to guarantee that the channel
     will be cleared for an RR before the first packet's T1 timer
     expires.

As an example:  let's assume a 1200-baud channel (roughly 100 bytes per
second counting overhead?) and 256-byte packets.  Let's also assume a
three-second T1 timer, and a 7-packet window (hard-set or negotiated,
I don't think it matters).

Sender puts packet 1 into the transmit channel.  It takes a couple of
seconds to transmit.  When it has been transmitted, its T1 starts.
Packet 2 goes into the transmit channel, and is successfully transmitted
about two seconds later... and *its* T1 starts.

Even if the sender still has packets queued up, and "window room"
for them, it probably doesn't want to send packet 3 without
dropping carrier and giving its peer time to respond.  Why?  Because,
if it did, it would still be using the channel (and blocking the
peer from transmitting the RR) for long enough that the first packet's
T1 timer would expire, and T1 would assume to be lost.  This would
lead to unnecessary packet retransmissions.  A "smart" sender would
adjust the number of packets sent back-to-back, based on the
T1 timer limit and the size of the packets and the effective baud
rate of the channel, in order to avoid these undesirable timer
expirations and re-transmitted packets.

If you're increasing the window size, and are sending relatively
long packets, you may need to increase your T1 timer value to
somewhat over [packet transmission time] * [window size].

However, if you do, you may hurt your connection's ability to
recover from lost packets, in at least two ways:

-  If the last/only packet in a burst is lost or corrupted,
    you'll have to wait for the (longer) T1 timer to expire
    before your node will resend it, and

-  If a packet in the middle of a long burst is lost or
    corrupted, you'll have to retransmit not only this one
    packet but all after it in the burst (either when T1 expires
    or when you get an SREJ frame from the receiver).

So, whether a long window increases or decreases your effective
throughput is going to depend not only on the window size and
the link turnaround time, but also on the error characteristics
of the channel.  If the connection is relatively noisy, a smaller
window size and T1 may actually give you better throughput.

You should also check your T107 setting (the "channel hog" timer),
as this is specifically intended to keep one station from monopolizing
the channel.

Best of luck in your investigation!

73,

	Dave AE6EO

RE: standard_window_size.

[Bob Donnell]

There is no provision in the AX.25 protocol for the negotiation of
connected-mode window size, only for the AX.25 version supported by the
connection.  The receiving window size is (or at least should be) assumed to
be 7.  Of course, not all TNC's support connected mode, and not all of those
that do actually have enough buffer space to support 7 frames - but neither
type would be considered AX.25 compliant either.  The significant
enhancement of a version 2 connection is that a station having sent
information packets, but having failed to receive an acknowledgement, will
poll the remote station, asking what the next packet is that the remote
station is expecting to receive, providing implied acknowledgement of all
earlier packet.  Then the sender can queue the next round of information
packets for transmission.

Part of the problem with [2] in the kernel is that the T1 timer operation is
very decoupled from when the transmission is actually made.  It's one of the
reasons I suggested that at the very least, the on-air data rate needs to be
known so that the time required to actually transmit the data can be added
to the T1 timer value, for each packet.  Additionally (or alternatively), if
channel DCD can be tested by the AX.25 stack, it can be used to hold (or
significantly slow) the T1 counter when the channel is busy, since with the
channel being busy, it's impossible for the queued packets to be sent.  The
channel-busy indication could also be used to prevent the queuing of the
acknowledgement packet to the air interface until the channel has become
clear, allowing the stack to generate a single implied acknowledgement for
all of the correctly received frames, instead of one per frame.  So it's
more efficient of air time.  Further, for working with clients that don't
work this way, information packets shouldn't be queued to the air interface,
until the after the T1 timer expires, or if any acknowledgement packets have
been received, until the channel-busy indication goes false, so that no
acknowledged frames are retransmitted.

I'm sorry to say I currently have zero familiarity with the AX.25 kernel
code itself, but infer a lot of the internal functionality based on observed
behavior, with the kernel, and with other programs that use air interface
drivers that are decoupled from the protocol stack, vs. hardware TNC's,
running in their native mode as the AX.25 protocol processor, which show all
the signs of doing this processing internally.  

The conclusion below that the TNC would "want" to unkey after 2 frames makes
several invalid assumptions.
	In hardware TNCs, there's one T1 timer per connection - not per
packet.
	The T1 timer is started when the transmission is complete.  This
makes T1 independent of number of frames sent to the receiving station.  In
a multi-connect environment, it also makes the T1 timeout independent of
packets being sent to multiple stations.  That technically might be a minor
mistake, since now acknowledgements might have to be received from 2 or more
stations.
	If digipeating is being used, the T1 setting used by the timer is
the T1 mulitplied by the number of digipeating hops.

One assumption that should be made when people are configuring AX.25 to use
more than 1 or 2 frames is that if retries are happening due to poor paths
or busy channels, they shouldn't be using a setup that causes long
transmissions.  If only 2 stations are on the channel, and the bit error
rate is such that sending 7 frames of 256 bytes only results in retries less
than 5% of the time, then using the maximum settings is justified.  If you
can't get 95% of each block of transmissions through without retries, using
fewer frames of smaller size is a performance tuning option that is
required.  No matter what the reason.

One of the best features I recall from the MSYS PBBS software was that it
adaptively adjusted T1 value, packet size and number of frames, based on the
retry rate it had on each connected link it was sending data to.  This
allowed it to be self-adaptable to the channel baud rate, much along the
lines of how TCP adjusts its window size and retry timer to match the
channel.  It may also have kept track of the number of stations recently
received on the channel to adjust the supporting KISS TNC Persistence
setting.  I don't recall the later detail with regard to MSYS clearly.
There was a Dutch version of the KA9Q NET software that also did this.  It
kept track of how many individual stations (call/SSID) had been heard on the
channel for the last 5 or 10 minutes, used it to calculate the correct
Persistence setting, and updated the TNC when that value changed, so it did
adaptive channel sharing computation and correction.  It was possible to see
changes being made on the fly in both of these programs.

73, Bob, KD7NM

-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of Dave Platt
Sent: Tuesday, December 09, 2008 10:12 AM
To: Linux-Hams
Subject: Re: standard_window_size.

John Ronan wrote:
> 
> Morning,
> 
> I tested over the weekend (and I though I had posted it already).
> 
> After changing the kernel header to have the standard window size = 3. 
> This was verified when I booted the machine as the entry in /proc was 
> 3.  However, once I connected to it and started passing data, it again 
> behaved as though it was set to 2.
> 
> RR after every second packet
> 
> Suggestions as to where to look next appreciated.

I think I'd start by using a third packet station, to monitor the whole
connection and see if there's any protocol negotiation taking place between
the two systems (and, if so, what protocol parameters are being negotiated).

It's been a while since I looked at AX.25 in detail, but here are some
thoughts:

[1] Negotiation between the two peers can result in different parameters
     being used than you may have programmed in.  I believe that the
     maximum window size will be the *smaller* of (a) what the sender
     decides it should send and (b) what the receiver says that it's
     willing/able to accept during the (optional?) protocol negotiation.
     You may need to snoop the channel (or use Ethereal or a similar
     software protocol sniffer on one peer) to see all the details.

[2] I think that the number of packets that the sender will transmit
     before it drops carrier and waits for an RR may depend (in some
     implementations at least) on the value of the T1 timer and the
     channel baud rate, as well as on the (fixed or negotiated) window
     size.  If I recall correctly, the T1 timer is the amount of time
     that the sender is willing to wait for an RR, after the packet is
     transmitted, before it will decide that the packet was lost and
     will retransmit it.  If this is set too low it may cause the sender
     to reduce the effective window size, to guarantee that the channel
     will be cleared for an RR before the first packet's T1 timer
     expires.

As an example:  let's assume a 1200-baud channel (roughly 100 bytes per
second counting overhead?) and 256-byte packets.  Let's also assume a
three-second T1 timer, and a 7-packet window (hard-set or negotiated, I
don't think it matters).

Sender puts packet 1 into the transmit channel.  It takes a couple of
seconds to transmit.  When it has been transmitted, its T1 starts.
Packet 2 goes into the transmit channel, and is successfully transmitted
about two seconds later... and *its* T1 starts.

Even if the sender still has packets queued up, and "window room"
for them, it probably doesn't want to send packet 3 without dropping carrier
and giving its peer time to respond.  Why?  Because, if it did, it would
still be using the channel (and blocking the peer from transmitting the RR)
for long enough that the first packet's
T1 timer would expire, and T1 would assume to be lost.  This would lead to
unnecessary packet retransmissions.  A "smart" sender would adjust the
number of packets sent back-to-back, based on the
T1 timer limit and the size of the packets and the effective baud rate of
the channel, in order to avoid these undesirable timer expirations and
re-transmitted packets.

If you're increasing the window size, and are sending relatively long
packets, you may need to increase your T1 timer value to somewhat over
[packet transmission time] * [window size].

However, if you do, you may hurt your connection's ability to recover from
lost packets, in at least two ways:

-  If the last/only packet in a burst is lost or corrupted,
    you'll have to wait for the (longer) T1 timer to expire
    before your node will resend it, and

-  If a packet in the middle of a long burst is lost or
    corrupted, you'll have to retransmit not only this one
    packet but all after it in the burst (either when T1 expires
    or when you get an SREJ frame from the receiver).

So, whether a long window increases or decreases your effective throughput
is going to depend not only on the window size and the link turnaround time,
but also on the error characteristics of the channel.  If the connection is
relatively noisy, a smaller window size and T1 may actually give you better
throughput.

You should also check your T107 setting (the "channel hog" timer), as this
is specifically intended to keep one station from monopolizing the channel.

Best of luck in your investigation!

73,

	Dave AE6EO

--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: standard_window_size.

[Dave Platt]

Bob Donnell wrote:
> There is no provision in the AX.25 protocol for the negotiation of
> connected-mode window size, only for the AX.25 version supported by the
> connection.  The receiving window size is (or at least should be) assumed to
> be 7.  Of course, not all TNC's support connected mode, and not all of those
> that do actually have enough buffer space to support 7 frames - but neither
> type would be considered AX.25 compliant either.

It appears to me that parameter negotiation was added in AX.25
version 2.2.  The station which is initiating negotiation (which
can take place at any time) sends an XID command frame.  The station
receiving it sends back an XID response frame... or, if it's running
AX.25 versions prior to 2.2, it sends back an FRMR reject frame, and
the peer which sent the XID command frame abandons the attempt to
negotiate and uses a default set of parameters.

The XID negotiation can apparently set the half/full-duplex modes,
selective-rejection modes, modulo-8 or modulo-128 modes, I field
length, window size receive, acknowledgement timer (T1), and
retries.

The details are on pages 24-25 and 37-38 of the AX.25 2.2 spec at TAPR.

I don't know whether the Linux kernel AX.25 implementation is up to
AX.25 2.2 or whether it's a prior version.  Ditto for "hard" TNCs.

> Part of the problem with [2] in the kernel is that the T1 timer operation is
> very decoupled from when the transmission is actually made.  It's one of the
> reasons I suggested that at the very least, the on-air data rate needs to be
> known so that the time required to actually transmit the data can be added
> to the T1 timer value, for each packet.

That would certainly help... although, as you say, the underlying problem
is that the timer management and packet transmission are decoupled.  If
the network layer assumes that actual air transmission starts when the link
layer is told to transmit it, it'll be wrong much of the time (especially
on a congested channel).  Adding the transmission time to the timer value
will help reduce the magnitude of the problem but won't eliminate it.

I imagine that the only way to really fix this particular problem would
be have the link layer send back a positive "OK, packet N sent" when it
has actually been transmitted.  Unfortunately, the KISS protocol
has no such acknowledgment capability... there is no feedback or flow
control at all in either direction.

Either a per-packet handshake from the KISS termination (TNC), or
some way of polling the packet buffer, would be required.

> 	In hardware TNCs, there's one T1 timer per connection - not per
> packet.
> 	The T1 timer is started when the transmission is complete.  This
> makes T1 independent of number of frames sent to the receiving station.

Right you are, thanks for the correction.  The spec says that T1 is to be
started at the end of the transmission of a packet, if it's not already
running... and if it is running, it's to be restarted.  This is in effect
the same thing as what you wrote.

> One assumption that should be made when people are configuring AX.25 to use
> more than 1 or 2 frames is that if retries are happening due to poor paths
> or busy channels, they shouldn't be using a setup that causes long
> transmissions.  If only 2 stations are on the channel, and the bit error
> rate is such that sending 7 frames of 256 bytes only results in retries less
> than 5% of the time, then using the maximum settings is justified.  If you
> can't get 95% of each block of transmissions through without retries, using
> fewer frames of smaller size is a performance tuning option that is
> required.  No matter what the reason.

I agree with you in the case of AX.25 prior to the introduction of the
SREJ frame (which I think came in with 2.2), since a single lost or
corrupted packet will require that packet, plus all subsequent ones in
the window to be retransmitted.

With the use of SREJ, I believe one can afford to run large windows
over a somewhat noisier link, as you can recover from a lost or
corrupted packet in the middle of the window by sending an SREJ naming
that one packet.  The sender needs only retransmit that one packet,
and may immediately continue sending other (not-yet-transmitted) packets
within the range allowed by the window.

> One of the best features I recall from the MSYS PBBS software was that it
> adaptively adjusted T1 value, packet size and number of frames, based on the
> retry rate it had on each connected link it was sending data to.  This
> allowed it to be self-adaptable to the channel baud rate, much along the
> lines of how TCP adjusts its window size and retry timer to match the
> channel. 

Nice!

I suspect that a large part of the difficulty with AX.25 is that it
was derived from a protocol which was largely intended to work on
point-to-point links with rather low error rates.  Dealing with a
shared medium with high noise/collision/corruption rates wasn't
really engineered in from the beginning.

73,

	Dave AE6EO

Re: standard_window_size.

[John Ronan]

On 9 Dec 2008, at 19:42, Bob Donnell wrote:

> There is no provision in the AX.25 protocol for the negotiation of
>
[bigsip]
Bob, Dave, thanks for your detailed replies (I didn't get Dave's  
directly, only saw it on Bob's reply). I've printed off the email as  
it is going to require a few readings to fully understand it. MSYS's  
negotiation does sound like the business.

That said, the post put me on the right track. There isn't any  
protocol negotiation taking place.

The culprit was, in fact me, or at leas my understanding of AX25  
(call it dumbness if you like), which, I have to say is still spotty,  
and I must apologise to the list for wasting the bandwidth.

The T2 Timer is what I was missing.  I went and read the spec and  
came to
http://www.tapr.org/pub_ax25.html#2.4.7.4

The default T2 timer value of 3 seconds is just about perfect for two  
255 byte packets (which makes sense given the default window size is  
2). That is what was causing the replies to occur when they were.

FYI I'm just testing some DTN software (an AX25 convergence layer for  
the DTN Reference implementation developed by Darren Long G0HHW) vs  
raw ax25 connections (use axcall to connect to host, look at large  
file, time it, repeat etc). So I'm testing on point to point links  
and via a digipeater.  Bob, your comments have already given us some  
more ideas as to how to improve the current DTN convergence layer.

Once I get these tests complete I might look at getting IP to run  
efficiently over the same links, but that's another days work.

Thanks for the help and suggestions everyone.

Regards
de John
EI7IG
--
John Ronan <jronan@tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org

RE: standard_window_size.

[Bob Donnell]

Hi John, and all

I see that you've referred to the AX.25 v2.2 specification.  Please be aware
that you may be doing original work, as to the best of my knowledge, no
hardware TNCs implement the additions defined in version 2.2, vs. the well
established v2.0 specification.  Using v2.2 in any way other than with
another matching client, directly connected or probably via a digipeater, is
likely to be recognized by any efforts outside what you're working on.

As far as using TCP/IP, the approach we used here in the Pacific Northwest
was to create LANs that were hidden-transmitter-syndrome-free (HTS-free),
and establish gateway stations for packets traveling from one LAN to
another.  These were generally at the home of a well located station, one
that was able to provide HTS-free support for 2 or more LANs, so they could
act as effective routers.  This was helped along in our area by creating a
number of full-duplex packet repeaters - for 1200 bps, that could be nothing
more than a stripped-down voice repeater.  For 9600 bps operation, the
no-longer-available TAPR 9600 bps modem, with the bit-regeneration hardware,
tied to a receiver and transmitter made or modified to have a low bit-error
rate at 9600 bps worked very well.  Even better for 1200 bps would be a bit
regenerator well matched to an appropriate modem.  I'm not aware of any
currently implemented bit regenerator hardware for 1200 bps - though I'm
trying to convince N1VG to create a firmware load for his OpenTracker2
product to accomplish this.

Further, we used AX.25 UI frames, with the maximum AX.25 frame size and the
maximum TCP window size adjusted to cause a less-than-5% packet loss, on a
quiet channel.  On LANs with a low bit-error rate, this could mean UI frames
as large or larger than 1024 bytes per frame.  We let TCP (within limits)
adjust its window size and retry timer, based on its perception of packet
loss.  About the only real change was to modify the TCP retry timer
adjustment algorithm to add to the retry timer, instead of multiplying it.
With the latter strategy, if a gateway station was off the air temporarily,
the TCP retry timer for a link that used that station could fairly quickly
grow to hours or days.  The additive approach usually resulted in a link
that started to function again allowing the sender to recover and get on
with transferring data in less time.  This is more important if the link
quality (bit error rate) won't support a less than 5% packet loss, since at
regularly higher rates, the TCP retry timer will still climb excessively.

Each LAN was assigned a pool of IP addresses, to create a subnet, and
allowing a primary gateway to be assigned.  Later we implemented RSPF, which
didn't work well, because the table was complicated, and an XT-class
computer would take 5-10 minutes to recompute the table, during which,
having no valid routing table, it would not be able to route packets.  After
living through that bottle-neck, we changed to using RIP, for which routing
table computations can be completed more quickly, and as I recall, the
implementation keeps the current routing table until an update is completed,
and then switches to the new table - so packets can be routed (perhaps
sub-optimally, or in error) while an update is being processed.

Making TCP/IP over amateur packet radio is "all about" managing the
bit-error rate to eliminate as many reasons for retries as possible.  Coming
up with hardware/software that could be installed in existing TNCs and would
accept KISS frames and encode them into FX.25 (AX.25 with an FEC wrapper) is
worthy of effort.  Many existing older TNCs won't support this without other
hardware modifications, if indeed they have the horsepower to do the job,
because many of them depend on hardware HDLC controller chips, of one
variety or another, to send and receive the bit streams and manage the bit
stuffing.  And the FEC data can't or shouldn't be bit-stuffed.

So, some food for thought, further along the journey!

73, Bob, KD7NM

-----Original Message-----
From: linux-hams-owner@vger.kernel.org
[mailto:linux-hams-owner@vger.kernel.org] On Behalf Of John Ronan
Sent: Thursday, December 11, 2008 12:50 AM
To: Linux-Hams
Subject: Re: standard_window_size.


On 9 Dec 2008, at 19:42, Bob Donnell wrote:

> There is no provision in the AX.25 protocol for the negotiation of
>
[bigsip]
Bob, Dave, thanks for your detailed replies (I didn't get Dave's directly,
only saw it on Bob's reply). I've printed off the email as it is going to
require a few readings to fully understand it. MSYS's negotiation does sound
like the business.

That said, the post put me on the right track. There isn't any protocol
negotiation taking place.

The culprit was, in fact me, or at leas my understanding of AX25 (call it
dumbness if you like), which, I have to say is still spotty, and I must
apologise to the list for wasting the bandwidth.

The T2 Timer is what I was missing.  I went and read the spec and came to
http://www.tapr.org/pub_ax25.html#2.4.7.4

The default T2 timer value of 3 seconds is just about perfect for two
255 byte packets (which makes sense given the default window size is 2).
That is what was causing the replies to occur when they were.

FYI I'm just testing some DTN software (an AX25 convergence layer for the
DTN Reference implementation developed by Darren Long G0HHW) vs raw ax25
connections (use axcall to connect to host, look at large file, time it,
repeat etc). So I'm testing on point to point links and via a digipeater.
Bob, your comments have already given us some more ideas as to how to
improve the current DTN convergence layer.

Once I get these tests complete I might look at getting IP to run
efficiently over the same links, but that's another days work.

Thanks for the help and suggestions everyone.

Regards
de John
EI7IG
--
John Ronan <jronan@tssg.org>, +353-51-302938 Telecommunications Software &
Systems Group,  http://www.tssg.org



--
To unsubscribe from this list: send the line "unsubscribe linux-hams" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html