[nos-bbs] JNOS use of the poll/final bit in I-frames - comments ?

[maiko at pcsinternet.ca]

With permission from Dave Platt, AE6EO (openTNC project) ...

Comments from anyone ? This is quite technical, would like to hear from
those well versed in this stuff please ?

1. Let me preface this with a correction he sent to me afterwards

did find one mistake in what I'd told you.  The T2 timer is controlled 
by
the RESPTIME setting, not FRACK.  I've just checked the TASCO modem in 
my
TS-2000, and its RESPTIME is set to 5, so it should be acknowledging 
I-frames
by itself... but it doesn't do so, while my TNC-2 does (and, of course, 
so
does OpenTNC).

2. Mentions an aspect of JNOS's use of AX.25 which seems a bit odd.

it's different than any other TNC I've studied, and (unfortunately) it
can "tickle" a bug/shortfall in certain other TNCs.

It has to do with the use of the poll/final bit in I-frames.

If one sets the P/F bit in an I-frame, it's a request to the peer to
send back an RR/RNR/REJ at the earliest possible opportunity, to advance
the transmit window (the RR/RNR/REJ is supposed to be sent back with the
P/F bit set).  It's also (implicitly) an indication that "This is it for
now, no further frames are coming during this transmission".

Most TNCs will do this, setting the P/F bit in the last I-frame in a
series that they're sending (i.e. the one which fills up the MAXFRAME
window).  This causes the peer to acknowledge the received I-frames
immediately, without having to wait for the peer's T2 "I have packets to
acknowledge" timer to expire.  As far as I can tell this is not a
mandatory "SHALL" part of the protocol, but it does seem to be very
common practice, as it leads to a speedier connection.

I stumbled across this issue when using our county's emergency-service
JNOS BBS system, with my Kenwood TS-2000 and its internal TNC (which is
reported a single-chip design by TASCO).  When downloading files and
messages, the transmission was extremely slow:

  	* JNOS sends two I-frames
  	* TS-2000 just sits there.
  	* Several seconds pass.
  	* JNOS sends an RR with P/F set.
  	* TS-2000 sends back an RR with P/F set,
             acknowledging successful reception of both I-frames.
  	* JNOS sends two more I-frames
  	* Lather, rinse, repeat.

If I switched from the internal TASCO modem to an MFJ-1270 (a TNC clone)
or a KPC-3 (or the Linux AX.25 stack) there were no such delays... the
exchange would go directly from step 1 to step 5.

What I've concluded is that the TASCO modem simply doesn't implement the
T2 protocol timer at all!  It implements the FRACK command which is
supposed to control T2, but this command doesn't actually affect
operation.  The TASCO won't acknowledge inbound frames unless explicitly
polled.  Really sloppy of them.

If I use the TS-2000/TASCO combination to connect to a different TNC
(something other than JNOS), the problem isn't evident, because the
other TNCs I've tested do set the P/F bit in the last I-frame in each
burst.  The TASCO immediately responds to this by sending an RR with P/F
set, and the data transfer continues immediately.

I've skimmed through the JNOS code, and as far as I can tell, it doesn't
seem to have any logic which allows it to set P/F on an I-frame it
transmits.

What's more, it has an optimization for unacknowledged short I-frames -
rather than polling to see if the other station got them, it just
retransmits them verbatim.  I believe that this can cause a connection
to hang forever, if it occurs when transmitting to a buggy TASCO modem,
since the TASCO will never voluntarily acknowledge the short frame since
there's no P/F bit set on it.

So... it would be nice if JNOS could (perhaps optionally/selectively)
set the P/F bit on the last I-frame in each sequence it sends.  That
would fix the bug with TASCO modems (which I believe are used in quite a
few Kenwood radio models) and would probably increase the speed of
transfers to other TNCs by eliminating the need for a T2 timeout during
each send-and-acknowledge cycle.

I'll spend a bit more time looking at how the AX25/LAPB code in JNOS
handles the transmission of I-frames, and see if I can come up with a
possible fix [snip] ..

Best regards,

     Dave AE6EO