[nos-bbs] Tuning nos

[(Skip) K8RRA]

I think there is something very interesting in your example Jay.

On Sun, 2008-03-23 at 02:37 -0500, Jay Nugent wrote:
>>SNIP<<
>    Often times this can be caused by a known problem with the KISS 
> protocol.  It goes something like this:
> 
>    o JNOS sends a frame (over KISS) to the TNC.
>    o But the TNC hears something on the RF channel so it holds off 
>      transmitting until the channel is clear.
This of course is a GOOD thing, it leads to delay in delivery but does
not add to loss of data.

>    o The IP stack in JNOS doesn't see an ACK to the sent frame so the
>      T3(?) timer times out, it assumes the frame was lost, and sends 
>      a duplicate frame over the KISS link to the TNC.
Yes, and here is the crux of the issue -- *delay NOT loss*.  Now you
*might* need to admit that perhaps TCP is a bit impatient about hearing
an ACK?

>    o We now have TWO copies of the SAME frame in the buffer of the TNC.
Yes, and the duplicate amounts to clutter, and clutter further damages
the performance of a channel that is already stressed.  BAD!

>    o The IP stack times out yet again, and sends a THIRD frame, etc,
Yes -- but where does this duplicate originate?  My read is the TCP
source node and not at the node where the TNC is locked up [UNLESS it IS
the source which is not likely] duplicates the packet.  Now this gives
the view that there is nothing wrong with KISS!

SMTP could not be very reliable unless TCP is an end-to-end connection
to prevent some middle of the route node from collecting all the mail it
can't move across the link.

So this duplication needs to be re-cast as a problem thrust on jnos but
it may not be up to jnos to solve the problem.

SO -- what mechanism is available to differentiate between:
  A) data loss
  B) delivery delay
because clearly we should WAIT for delay and DUPLICATE for loss.

73
de [George (Skip) VerDuin] K8RRA k