Van Jacobsen himself is still around, and still working in conjestion control, for TCP and IP in general, as well as huge amounts of work in performance measuring.
Header compression is still a good idea for bulk data transfer - it's simply that the overall gains might not be so big, since the packet payload size is likely to be around 1460 (Assuming MTU/MRU of 1500).
However, shuffle enough data about, and the amount of overhead you're sending is still quite high, even if it's a lower percentage, and with things like FTP and even HTTP, there's enough 'small packets' required to setup the dataflow itself that these are worth VJ on their own. FTP's control connection benefits enormously, for instance, especially considering it's a non-pipelinable protocol (Officially, although many clients try to pipeline...).
Where VJ compression fails to make any ground is when large numbers of TCP flows are in progress, such as on serial links used by a large networks on both sides. It'll only work at all on point-to-point links since otherwise the compression (An indexing compression) is too complex to manage, and the actual VJ algorithm fails.
There are other compressions used by PPP - however, these tend to be used either on Linux, or else on other things, such as Cisco's and the like. There's unfortunately very little common ground in compression technologies between the Linux/*BSD world and the purpose-built router world, which has caused me much sobbing over the years.
Dave.
-----Original Message-----
From: James McGill [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 27, 1999 4:42 PM
To: Jacob Joseph
Cc: [EMAIL PROTECTED]
Subject: Re: Repost of "A quick Qestion"
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 26 Oct 1999, Jacob Joseph wrote:
> "Hey, with the ppp_compress modules, what do they actually do? Do I get
> software compression out of them or what? If so, how do I know the
> compression average?
This is Van Jacobsen Compression, same as CSLIP.
If you use the TCP protocol, you should thank Van Jacobsen, since he
pretty much invented it. I hope he's still around. He was awarded
the USENIX lifetime acheivement award in 1994 for "Making TCP
Industrial Strength."
It compresses the TCP Header, not the data.
You might be interested in rfc1144 and rfc1332 for details.
Basically, the problem v-j compression solves is this.
On an interactive sessuibm with a user typing on a terminal,
for instance, the TCP and IP headers for a single byte add
up to 40 bytes. So you are sending 41 bytes for 1 character
(worst case, but not uncommon!). 4000% overhead...
V-J can reduce the overhead for the packet header down to maybe
300%. This was absolutely essential for 2400 baud, and still
a very good thing for any serial link, even now.
I'm not certain whether the net effect of V-J is still a gain
if all one does is bulk data transfer, since it was designed to
bring down the keystroke-echo latency on serial links.
- --
James McGill VOX: (972) 481-5735 (Dallas)
MindSpring Enterprises, Inc. PCS: (214) 641-4458
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
iQA/AwUBOBcdUE+lqQeHSnJYEQLacwCfcf2prlhiWfPW4o5LG0+0HunC8FgAoJpF
/dTBwX8CV/zWx+ofJ0ksxVoC
=9lgw
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-diald" in
the body of a message to [EMAIL PROTECTED]
