Re: Extended sequence numbers for AX.25

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

According to Phil Karn:
> >I know about that article, but I have always questioned its validity
> >when applied to real-world packet radio.
> >In practice, larger packets have a larger chance to be hit by a bit error,
> >and this means that with a certain (non-zero) bit error rate it is often
> >better to send smaller packets.
>
> My analysis did assume a non-zero bit error probability. Otherwise I would
> have concluded that you'd always want to send the biggest packet possible.
>
> My conclusions held for a very wide range of bit error rate. For any
> particular value of BER, there was an optimium transmission size that
> minimized the combined effects of header overhead and lost
> packets. Below this optimium value, header overhead reduced
> throughput.  Above it, packet loss reduced throughput. Yet over a very
> wide range of BER, throughput  was *always* maximized when the
> transmission consisted of one (properly sized) frame.
>
> I did assume randomly distributed errors, though.

Ok, I accept the validity of your analysis but my experience with packet
radio is that even with 256-byte packets the bit errors already start
to influence the results.  Probably this just means the BER is such that
the optimum is below 256 bytes.

> Your network tests are very interesting. You should publish them.  I
> note that the usual rule of thumb for pure ARQ protocols (e.g., TCP)
> is that the packet loss rate should not exceed 1% for good
> performance.

With TCP (which has no feedback about lost packets and always assumes
lost packets indicate congestion, not loss by transmission error) this
is very true.  That is a reason why most of our network uses VC mode for
IP traffic.  (actually, the current software automatically switches between
VC and datagram mode depending on the results it gets from the link quality
measurement)

AX.25 tends to work OK with much higher loss rates, of course with less
than ideal throughput.

> >- it is true that you discard perfectly good frames when using plain
> >  AX.25, but that is no worse than having to discard the single large
> >  frame that you propose.
>
> Yes it is, since there is more header overhead with the smaller frames.
> That's the sole reason for the better performance with larger frames.

I think the header overhead is only significant for small frames.
(i.e. I don't believe 16 bytes of overhead for 256 bytes of user data
is significant header overhead)

So, "use larger frames" will not bring you anything when just increasing
the PACLEN from 256 to 1024, as it won't help for frames that are smaller
than PACLEN anyway.
It could only help to pack multiple user data frames in a single link
frame, with only length+PID inbetween (which reduces the header overhead
from 16*n to 16+3*n bytes)

> >- it is not necessary to use complete go-back-N.  It is possible to save
> >  the out-of-sequence frames and use them later, as shown before in some
> >  Austrian and German papers.  Many European products do this.
> >  with modulo-128, this becomes much easier, as indicated in my paper.
>
> Is this really true? TCP does this, but without checking the LAPB rules
> I wouldn't be surprised if this causes problems.

Yes, it is really true.
For modulo-8 sequence numbers and unknown MAXFRAME at the sending side,
some extra protection is needed.  This takes the form of keeping a simple
checksum (1 byte) for the past 8 sequence numbers, and not keeping a new
frame in the resequencing queue when its checksum matches the value for
the previous frame with that same sequence number (from the previous series).
With modulo-128 this extra trick is not required as long as the MAXFRAME
is guaranteed to be below 64.

> >- the CRC check becomes weaker with large frames
>
> Also true, but if you have TCP/IP on top...

Please keep in mind for all suggestions and protocols proposed: while
TCP/IP is widely used, mostly by "power users", the vast majority of
traffic in the packet network (95% when I last checked) is pure AX.25
and NET/ROM.
The average HAM (at least in his first experiments), and *all* BBS and
DX Cluster traffic is AX.25, not using TCP/IP.  So this case has to be
covered well, at least for now.

> >- collisions between the link ends (the links are halfduplex, both sides
> >  can decide to transmit at the same time)
>
> This is another thing that a stop-and-wait protocol helps you
> with. LAPB was designed for a full duplex environment, but our
> channels are half duplex.  When you send a packet and unkey, you
> should at least wait for the expected link level ack before you key up
> with another packet. This happens automatically if you set maxframe=1.

My version of NET does this for maxframe >1 as well.  It does not key the
transmitter again to send more frames before the ACK has been received or
the T1 timer expires.
However, this does not solve the problem completely: when the link is
idle (everything ACKed) and both stations get data to transmit at the
same time, they can still collide.

> >The FEC scheme to be implemented needs to be well thought out to cope with
> >the kind of errors that really occur.
>
> Very true. As I said earlier, my original motivation for looking at it
> was radar QRM here on 70cm in San Diego. FEC is a natural for this, but
> it's also helpful with marginal links.

It looks good!

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