Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!OMNIGATE.CLARKSON.EDU!bkc
From: bkc@OMNIGATE.CLARKSON.EDU (Brad Clements)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Message compression
Message-ID: <9104091507.AA19555@ucbvax.Berkeley.EDU>
Date: 7 Apr 91 20:56:51 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 45

Regarding compressing TCP packets for serial transmission. I've developed an
extension to Jacobsons TCP header compression routines that will compress
the TCP data portion using Splay tree compression. This routine uses
'state trees' with a variable number of trees being assigned to each
active TCP connection (and depending on the major data direction of the stream).

The routine dynamically moves state trees to connections where it does the most
good, and can do so without entirely resetting the trees of existing connections
that gain or lose trees.

For example, I can support 32 state trees in about 32K of memory. This
gives me a 5 to 1 compression on 3278 type datastreams, 3  - 4 to 1 for
standard text.

The advantage of using state trees where two fold: 

	1. Low memory overhead in the kernel
	2. the ability to dynamically reconfigure memory usage
	    (in this case, moving trees between connections as needed)
  	   without having to dump 'all learned patterns' each time.

The routine automatically detects uncompressible data (for ftp's of
already compressed files, for example). etc etc.

Anyway, this is all quite experimental, runs on top of PPP for Sun OS,
and isn't yet available for general consumption (please don't ask for the
code yet).

I know that compressing modems are becoming more prevelant these days, but
this cheap solution gives my 2400 baud modem 5600 baud throughput
(best case). I have not had a chance to compare this method with 
compression of the entire datastream within the modem. However I think
even using splay trees (which are not as effective as adaptive LZW), I get
better compression on serial links which are supporting different TCP
sessions, since the compression state information is tracked by TCP
connection, and the TCP header data (already 'compressed' by VJC) is not
examined during the compression process.

Of course, when packets are dropped, VJ compression gives the splay routines
enough information to have both the compressor and decompressor reset their
trees.


| Brad Clements          bkc@omnigate.clarkson.edu        bkc@clutx.bitnet 
| Sr. Network Engineer   Clarkson University              (315)268-2292