home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.protocols.iso
- Path: sparky!uunet!spool.mu.edu!sdd.hp.com!caen!sol.ctr.columbia.edu!eff!world!hcb
- From: hcb@world.std.com (Howard C Berkowitz)
- Subject: Re: X.25 header compression
- Message-ID: <BzDHpB.K58@world.std.com>
- Organization: The World Public Access UNIX, Brookline, MA
- References: <1992Dec16.162940.10991@nosc.mil>
- Date: Wed, 16 Dec 1992 22:12:47 GMT
- Lines: 33
-
- 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>
- >
- >
- >
-
-
-
