Mike Bilow wrote:
I've never understood the T2 waiting business anyway. If only
AX.25 and the channel access algorithm were coupled more tightly.
IMHO there's no need to do any waiting at all (or even use a poll bit)
in that situation. When the carrier goes off, you can be quite sure
that you are expected to send an ack, so there's no point in waiting.
This is more or less what FlexNet does.
> 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.
FlexNet "prunes" the send queue (i.e. looks for redundant packets).
Conceptually a bit ugly, but it works well.
> 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.
Granted. But should we use this as an excuse for inferior performance
in all eternity?
We need an ARQ scheme, otherwise we'll easily get 33% packet loss over
longer distances, which TCP can't cope with. The ARQ scheme will give us
higher rtt variance, granted (at least over short radio paths). But we
can fix these problems well.
Not being designed for was never a good excuse in the networking
business.
TCP/IP was never designed to be used by _that_ many hosts either, yet
it still works 8-)
Tom
