Re: #2 Extended sequence numbers for AX.25

[rob@sys3.pe1chl.ampr.org (Rob Janssen)]

According to Mike Bilow:
> I think the issue is more than one of efficiency of implementation.  With a
> long window size of over 100 frames, the danger of receiver overrun is

Well, the limit I proposed is 63 frames.
In practice I am now running the links at EMAXFRAME 16, and I could imagine
using 32 for faster rates (like 56 kbps)

> substantial and possibly inevitable.  I can easily see implementations where
> the sender just dumps the maximum window size all the time, no matter how much
> the receiver drops on the floor, unless this is addressed at the beginning of
> the process.  The deficiencies in some implementations of existing AX.25 are,
I
> think, supporting evidence for my view.

It is true, but as already indicated in the introduction to my proposal,
it is mainly intended for fast half-duplex point-to-point links such as
found in a NET/ROM network.  In that case the EMAXFRAME can be set correctly
depending on the limitations of the receiving end.
When the receiving end is NET (and maybe NOS as well), received NET/ROM
packets are immediately routed and moved to the corresponding transmit
queue, even before they are acked.  This of course does not preclude the
overflow of those transmit queues or general memory pools, but those
overflows are not really related to the EMAXFRAME.  They are related to
a possible mismatch between input and output rate, an can occur even with
the current 7-frame window.

I agree that an (XID style) parameter negotiation has its place, but I
still think it is not directly related to the extended sequence number
option and should be taken up as a separate project.

This brings me to something else: there are many implementations of the
NET/ROM protocol around, and even more of AX.25.
Extensions are built by several groups, and in the case of NET/ROM there
already are mutually incompatible extensions in use (made by G8BPQ and
by the NORDLINK group).
It is difficult to distribute papers like the one I published yesterday,
and get them to the attention of a reasonable percentage of the software
developers.

I think it would be good to have some registry, maybe in the form of an
FTP site, where documents of protocol extensions are kept (like the RFC
documents), so that developers can easily collect information about what
others have done, and how it could be incompatible with what they write.
A mailinglist could be associated that distributes new entries when they
are received.

It should be done like the RFCs, i.e. only a publication of complete
proposals with the opportunity to post other, complete, proposals in
reaction.  Many developers have no time to keep up with longwinded
discussions about new features, which tend to evolve into flamewars.
The registry could also store things like PID values, multicast addresses
etc.

Maybe such a thing already exists and I have missed it (being out of
contact with groups like this for too long).  If not, maybe this could
be done on the TAPR or AMSAT sites?

Rob

pse CC, I am not subscribed to tcp-group
--
+------------------------------------+--------------------------------------+
| Rob Janssen         rob@knoware.nl | AMPRnet:   rob@pe1chl.ampr.org       |
| e-mail: pe1chl@wab-tis.rabobank.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
+------------------------------------+--------------------------------------+