Jonathan Naylor wrote:
> He's referring to the extended AX.25 specification published by Rob PE1CHL
> many years ago.
Uh oh indeed, I just forgot the existance of Robs proposal, sorry.
> I am sure the frame collector is wonderful but since nobody seems to send
> these specs outside of Germany, don't blame the Americans for not
Maybe the problem is because it is conceptually so simple noone bothered
to write a formal spec. It actually works by _removing_ a restriction
of ax25 v2.1 and letting the protocol elements have their natural
meaning. I'll make an example:
If a station receives frames number 1 3 4 5, according to v2.1
it is _obliged_ to throw away frames number 3 4 5 and send REJ2.
After it receives frame number 2, it has to respond with RR3
(since it threw away 3 4 5).
With the frame collector, it MAY however decide to store 3 4 and 5,
but nevertheless sends REJ2. After receiving frame number 2,
it can respond with RR6 if it stored 3, 4 and 5.
One drawback of the scheme is that you can't signal a list
of outstanding frames, the REJ cycle has to be repeated
for every outstanding frame.
But how AX.25 is used here mostly, this drawback has a welcome
side effect. Direct connects are very seldom here, most users
work through a backbone node. The relatively slow recovery from
multiple lost frames (but not inefficient, frames are only
transmitted as often until one copy makes it through) gives
the users an incentive to improve the receiving capability
of their station (not to increase their transmit power, that
doesn't help them), or to switch to another backbone node
which is nearer to them. This is also wanted, as it makes
the network more "cellular" and thus more bandwidth efficient
by making it easier to reuse frequencies. Thats probably
why noone bothered so far to rectify that shortcomming.
If you're doing NET/Rom though, where all the traffic
between two nodes goes through one AX.25 circuit, then
you need extended sequence numbers and a possibility
to signal a list of outstanding frames, no question
about that.
But the TAPR spec doesn't rectify this too, it can also
only signal one outstanding frame.
> That was uncalled for. I used SDL diagrams for all of the protocols in the
> kernel and I found it to be a huge advantage. You can say the same thing
I didn't claim SDL was useless, I claimed it has two likely pitfalls:
1. Don't choose one method over another just because it's easier
to do in SDL. I've seen people doing this and getting hurt
terribly by this.
2. When the SDL simulation works, your job is _NOT_ done. You can't
just "push the button" and hope the C code it produces is
useful for a real world implementation. You HAVE to produce
an implementation from scratch to show the adequacy of the protocol.
The authors of the spec seem to have fallen into trap number 2.
Also, SDL diagrams in an appendix are fine, but the spec should
be understandable and unambiguous even without that. v2.2 isn't,
there are several ambiguities.
> Excuse me but in the "real world" neither of these two bodies are that
> important. Inside central Europe they are, but outside they are small bear
> to say the least. Nordlink are known outside of the German speaking world
Yes we are important, both in terms of installed base and
stability of the network! We're certainly not going to scrap
our working network just because TAPR thinks we should, just
because of a protocol revision with unclear benefits to
say the least!
So, who else is important? Linux? Have you or Matthias been
contacted?
Has anyone of the TNC manufacturers been contacted (other
than TAPR, that is)? From the rumours I've heard, Kantronics
is at least as unhappy about that standard as we are...
Tom
