Re: #2 Extended sequence numbers for AX.25

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

According to Mike Bilow:
> On a quick read, your idea looks very good.  I never thought of initiating the
> connection with something different from SABM, but it is a very elegant method
.

Note that this is just the standard HDLC way of doing it.

> However, if we are going to make such a change, I think we could get a number
> of other problems solved by implementing some more fields and extensions,
> especially during the connection negotiation phase.

HDLC does this using XID frames, for which there is a standard as well.

> As a minimum, I think that there should be some sort of window size negotiated
> to prevent overrunning the receiver, and that such window size should be
> renegotiated for each connection.

This is part of the standardized XID frame described in ISO 8885.
All the usual parameters can be negotiated, and class of service (e.g.
support of extended sequence option) can be indicated.

Addition of XID capability to AX.25 is completely independent of my
extended sequence number proposal, and I think it should not be mixed.
It will not solve the compatability issues described in the document, as
implementations that don't react to SABME(P) will probably ignore XID(P)
as well.

When there is interest in an XID subset standard addition to AX.25, it
can be taken on as a separate project.

> Essentially, this would allow setting
> EMAXFRAME dynamically on a per-connection basis.  This sort of thing was never
> a problem with old AX.25, where the maximum window was 7 frames of 256 bytes,
> or less than 2 KB.  Error recovery and congestion variations should be taken
> into account, as in the TCP/IP model.

Well, of course the usual RNR generation and handling is done.  It would
be inefficient when the sender has a structurally larger window than the
receiver can handle, but this is not a problem in NET and probably not in
NOS either.  Those programs use a dynamic pool of memory which is not
committed to a single connection, and thus it would be difficult to
specify a maximum window that can always be handled.
Common-sense setting of EMAXFRAME should solve most problems (I use 16 for
now)

The document I posted describes only the technical details (frame formats)
and some hints at implementation.  In reality, the AX.25 handling in
NETCHL is more sophisticated than that.  (e.g., it has variable setting of
MAXFRAME depending on the error rate and RNR reports)
I did not feel those elements should be in the document, as other AX.25
implementations do things differently, and would work with extended
sequence number option as well.  However, you are right to note that
those factors are important for an efficient implementation.
(howcome that so many AX.25 implementations still send a full MAXFRAME-
sized window of packets after they received an REJ?  this usually is a
waste...  look at some station with a bad link connected to the local BBS
and you know what I mean)

Rob

--
+------------------------------------+--------------------------------------+
| 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 |
+------------------------------------+--------------------------------------+