Jonathan Naylor wrote in a message to Mike Bilow:
JN> The reasoning for attaching a poll to the last I frame in a
JN> window was something me and John G8BPQ worked out (his code
JN> does it BTW). The idea behind it was to improve performance,
JN> normally the receiving station would wait T2 from last
JN> hearing a frame from the remote end, before replying with an
JN> RR. The logic we used goes a little further, if we have sent
JN> a full window and are therefore not going to send any more
JN> to him (except retries), why not remove T2 from the equation
JN> by asking for an immediate reply from the remote station.
JN> I don't actually see how it could break anything to be
JN> honest.
With respect to you and the other John, both very much no slouches as
programmers, I think I can suggest the schema for why this might be a bad idea.
In the case where there is a higher layer protocol running above the AX.25
link, such as TCP/IP, there may be timers working on estimating the round trip
time. In fact, this is essentially a requirement with TCP.
The underlying assumption of the TCP timer algorithms is that there will be
relatively consistent timing between successes and failures. If successes can
be realized much more quickly than failures, then we will miscompute our rtt
estimate and will recognize failures too early -- before they really should be
regarded as failures.
Consider the case where TCP is being passed over an AX.25 link in VC mode --
this obviously has no application in datagram mode, since AX.25 is then a best
effort protocol without retry. Say, for the sake of argument, that we have
been running successfully for a while, and that the rtt is quite low, about on
the order of a second. Then a frame is lost, and the recipient starts running
T2 at the AX.25 link layer. When T2 expires, the information recipient will
request a retry at the AX.25 level, and will most probably get a successful
retransmission. Unfortunately, at the same time the information recipient
begins running T2 at the AX.25 level, the information sender begins running the
TCP timer based upon the statistical history of the short rtt. In all
probability, the sender's TCP retry timer will expire before the recipient's
AX.25 T2 timer, and then the sender's TCP layer will reissue the packet and
queue it down to the AX.25 link. This creates a bottleneck where the data --
all of it redundant -- begins backing up inside the sender's queue.
JN> The original textual description of AX.25 was very hazy on
JN> that point and so we felt able to add a little :-) It is
JN> such issues that make me a strong believer in SDL diagrams.
JN> If anyone wants to read a bad textual description of a
JN> protocol, try the LAPB/X.25 specification from the CCITT. I
JN> managed to get a university dissertation out of that
JN> particular mess.
AX.25 was simply not designed for this. TCP was never intended to be run
across lower layer protocols which intend to guarantee delivery, either.
-- Mike, N1BEE
