Subject: Compression Algorithms supported by CCP

From: "Buerkle Joachim (UC-ON/EMY2) *" <[email-masked]>
Date: Tue, 15 Feb 2000 10:22:54 +0100

Hi,

I have several questions about the different kind of Compression Algorithms
which are supported by CCP:

- Is there a comparison of these compression algorithms available?
- Which one is the most common one? MPPC?
- In July Vernon wrote:

>>The only special thing I can see about low speed PPP is compression (both
>>modem v.42bis and PPP CCP), which effectively makes the raw bandwidth of
>>a link appear to vary from about 90% to more than 400% of the nominal bit
>>rate.

  has somebody more details about these figures?

- In July there was discussion about "Guessing the link speed." on this
list.
  What was the result?

Thank You
Best Regards
Joachim

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---

From: James Carlson <[email-masked]>
Date: 15 Feb 2000 09:14:44 -0500

> - Is there a comparison of these compression algorithms available?

On what basis?  Number of implementations?  Market penetration?  IPR
restrictions?  Availability?  CPU cycles?  Compression ratios (best,
average, or worst-case)?  Prevalence of bugs in common
implementations?

There are a large number of ways to compare these things.

In a test I ran some time ago on Predictor, STAC, BSD Compress, and
Deflate, I got the highest compression ratios out of Deflate; about
1.5 times that of STAC.  It took about 5 times the CPU effort to
compress with Deflate, but was almost identical to STAC on
decompression.

> - Which one is the most common one? MPPC?

More likely, it's STAC.  Win9x supports both STAC and MPPC, and most
ISDN-based systems support either only STAC or a combination of STAC
and several other algorithms.  WinNT supports only MPPC, but there are
far fewer of those systems around.

For what it's worth, MPPC is a derivative of STAC.

>   has somebody more details about these figures?

Not really.  It depends *STRONGLY* on the data you have.  In
particular, GIF and JPEG images (which are already compressed) do not
compress well at all.  Some algorithms (notably BSD Compress and
Deflate) have zero-overhead mechanisms to avoid compressing
incompressible data.  Others do not.

Note that a significant amount of data passing over the link to a
web-surfing PC user is graphical and therefore incompressible.

> - In July there was discussion about "Guessing the link speed." on this

The list archives are at:

	ftp://ftp.merit.edu/mail.archives/ietf-ppp-archive/

The quick summary is that John Martz (IBM) posted a question about
finding the link speed for use in throughput comparisons.  Archie
Cobbs followed up to say that for ISDN you know the speed (it's either
64K or 56K per B channel) and that modems can report the DCE speed on
connection and that, if all else fails, you can measure it directly.
Karl Fox noted that modems are difficult -- actual throughput varies
over time.

There were several other follow-ups that digressed into how you
measure instantaneous speed, whether the link layer protocol matters,
and whether any of this is even useful information at all.  You'll
probably want to fetch a copy of ietf-ppplog.1999.07 and read it for
yourself.

The general answer is that your mileage will certainly vary ...

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp