🚀 go-pugleaf

In article <1992Dec16.162940.10991@nosc.mil> gutman@nosc.mil (Lew Gutman) writes:
>I am looking for information on X.25 header compression for slow links.  Does 
>

I'm a little confused what you mean by a "link" here.  If you are using 
the packet layer of X.25 on a point-to-point link, and performance really
is an issue, using a null packet layer is the immediate first thought.

If the link provides access to a packet network, other considerations would
apply.  If the link is slow but relatively error-free, frame relay, with
translation to X.25 at the endpoints, comes to mind.  

If the slowness comes from delay in getting packet or frame acknowledgements,
and you have tuned the packet data size and window size, most pure 
X.25 tuning has been done.  In a RF or similar environment, I might then
consider a forward error correction code to reduce retransmissions.  

As long as you need true X.25 (i.e., you need direct access to a packet
network), the data packet headers are fairly compressed.  You could, I
suppose, strip out the first four bits of the GFID and make the modulus
default, but I'm not sure how much this would help.  

Another approach is to use a point-to-point link protocol, a null packet
layer, and have the endpoints examine higher-layer protocol addresses
(I assume you have some) to determine the packet layer address needed.


><gutman@nosc.mil>
>
>
>