Re: Extended sequence numbers for AX.25
- To: email@example.com
- Subject: Re: Extended sequence numbers for AX.25
- From: Phil Karn <firstname.lastname@example.org>
- Date: Mon, 13 Mar 1995 23:16:00 -0800
- Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, PG@tasma.han.de, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Jarkko.Vuori@hut.fi, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: <9503042135.AA03012@sys3.pe1chl.ampr.org> (email@example.com
Thanks for the note, and thanks for writing up your work.
Some years ago I did an analysis that concluded that the optimum
window size in AX.25 when used on terrestrial half duplex paths was 1
packet *provided* that sufficiently large packets could be sent when
the channel was "clean".
I found it was always more efficient to deal with the overhead due to
channel turnaround time by sending a single sufficiently large packet
than to send a series of smaller packets in each transmission.
This makes intuitive sense, since the go-back-N retransmission scheme
of plain AX.25/LAPB causes many perfectly good frames to be discarded.
Furthermore, there is considerably less link level overhead in a single
large AX.25 frame than in a collection of small frames.
If the problem is that your packets are too small, then perhaps what
we really need is a new encapsulation scheme that lets you send
multiple IP datagrams (or whatever) in a single AX.25 I-frame. This
could be done rather easily since AX.25 in the connected mode is a
"reliable" protocol; something as simple as protocol-length-contents
coding would work fine.
Yes, selective reject is better than go-back-N. But if you're having
to retransmit so many frames that it makes a major difference, then
perhaps it would be even better to do something below the ARQ layer to
improve its performance. Better modems, better links and FEC, for
example. Every frame that an ARQ protocol throws away is wasted energy
that an FEC scheme could have used more efficiently.