Thomas Sailer wrote:
> I've never understood the T2 waiting business anyway. If only
> AX.25 and the channel access algorithm were coupled more tightly.
T2 is to optimize the ACK procedure (In fact Mike was refering to T1 I
think).
> 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.
In not DAMA mode it's good to wait before transmiting. T2 also helps on
that, but that's not its finality.
The scheme you say here is also good:
When the ax25 protocol receives the signal "PH_QUIET Indication", it
scans all the opened ax25 conections and send the ack for all who have
an ack pending.
AX25 v 2.2 specifies something similar: the data link machine ask for an
oportunity to transmit to the link multiplexer machine, and when it
receives the "OK" it transmits the pending acks. But it still uses T2,
because the data link machines are separated of the medium by the Link
Multiplexer and they don't receive information about the state of the
carrier (and that's maybe better that way, because the data link machine
is independent of the physical machines, i.e. you must no implement
diferent data link machines for full duplex and half-duplex).
> FlexNet "prunes" the send queue (i.e. looks for redundant packets).
> Conceptually a bit ugly, but it works well.
Yes, because maybe what is redundant for tcp/ip is not redundant for
other protocols. It's dangerous to touch whay you don't own :-)
> > 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.
I think IP was designed to be flexible, and TCP to allow a reliable end
to end comunication at a reasonable speed.
> 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-)
Because it is flexible !
> Tom
--
Saludos de Juli�n
-.-
