Subject: Re: draft-heath-ppp-v44-02.txt

From: [email-masked]
Date: Wed, 15 Jan 2003 12:34:25 -0800

Vernon

I think  you are confusing V.44 compression with V.42bis compression. V.44 
compression (i.e. LZJH) is sufficiently different from LZW that no Unisys 
or other LZW variant license fees are required for it's use.

In answer to your question, V.44 in this environment gets anywhere from 
20% to 200% better compression than LZW, and thus BSD PPP, depending on 
the data.  For HTML, etc. type web pages it is closer to the 200%.  V.44 
also gets better compression than LZS by ~10%.   With faster execution 
times.

The substantial increase in compression ratios that LZJH gets over LZW is 
the reason the ITU adopted V.44 in the first place to replace V.42bis in 
modems.

If you send me a list of the minor problems you see in the text I can fix 
them before releasing a new version.

thanks
Jeff

Vernon Schryver <[email-masked]>
Sent by: [email-masked]
01/15/2003 11:43 AM

        To:     [email-masked]
        cc:     [email-masked], [email-masked], [email-masked]
        Subject:        Re: draft-heath-ppp-v44-02.txt

> From: [email-masked]

> ...
> - just adding a sequence number to each packet does not seem to resolve 
> the problem.  What does the peer decompression function do when it 
> receives an out of sequence packet?  It must somehow tell the peer 
> compressor function that transmitted the packet and try to get the 
> dictionary back into sync, which is why  RFC1977 and others rely on 
> Reset-Request and Reset-Ack CCP packets or on renegotiation of the 
> Compression Control Protocol to indicate loss of sync between 
transmitter 
> and receiver.  In the meantime the decompressor function must discard 
all 
> packets received until dictionary sync between the transmitter and 
> receiver is restored.

In practice that is not a problem.  If your PPP link is so lossy that
it causes significant CCP reset chatter, it also loses so many IP
packets that application performance is terrible.

> - do we really want the compression function to be discarding packets 
> without any mechanism to have them re-transmitted by the PPP link?  And 
> expect a higher layer like TCP to recover?  What if it is UDP? 
Compression 
> is supposed to save bandwidth, and in my mind the compression function 
> itself should not add to bandwidth usage by tossing out of sequence 
> packets and requiring feedback messages to indicate loss of dictionary 
> syncronization.  It seems that in that case Datagram Mode would be 
better 
> since even though the compression ratio may be slightly worse it may 
> improve bandwidth efficiency in the long run over a more complex , 
> potentially bandwidth wasting, mechanism.

That's the sort of question that deserves an engineering answer instead
of mere gut feelings.

A bigger issue concerns the need for a v.44 PPP compression scheme.
The problem with v.44 has always been the LZW patent and Unisys license
fees.  That has also been the problem with BSD PPP compression (RFC 1977),
because BSD PPP compression performs at least as well as the other
existing compresion schemes and better than those currently most
popular.  When that patent finally expires this year, an implementor
considering some sort of LZW PPP compression could choose RFC 1977 or
your varient of v.44.  Since RFC 1977 is already present in a non-trivial
number of implementations, why would someone choose your varient of
v.44?  How does your scheme perform on typical data (for some reasonable
definition of "typical")?

In other words, if the PPP compression RFCs were not all Informational
(due of terrible long ago actions by the IESG), it would be more
appropriate to ask which of them should be moved to "Historic" (possibly
including RFC 1977) than to consider adding to the CCP tower of babel.

There are many minor problems with the text.  For example, I can't tell
what section 2.3.6 should mean.  Is the necessary inflation of the LCP
MTU 2 or 4?

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 15 Jan 2003 13:55:45 -0700 (MST)

> or other LZW variant license fees are required for it's use.

oh.

> also gets better compression than LZS by ~10%.   With faster execution 

On which corpus was this measured and with which PPP implementations?
When comparing to LZW, what size dictionary was used, the typical,
barely useful 9 or 10-bit of v.42bis or something reasonable?

I ask because the archives of this mailing list have plenty of marketing
statements of compression performance (made up facts), although not as
many as in the open literature (trade rags).

I also ask because your numbers seem backwards.  LZS as it is in PPP is
a terrible compression scheme compared to others including LZW.  I cannot
imagine something bettering LZS by only 10% but LZW with a reasonable
dictionary by 200%.  For that matter, I cannot imagine anything beating
LZW with a reasonable dictionary size by 200%.  There simply is not that
much entropy in LZW output, unless you do something dishonest such as
using 9-bit codes or clearing the dictionary on every packet.

> the reason the ITU adopted V.44 in the first place to replace V.42bis in 

I don't want to offend anyone, but the ITU is at least as bad as any
other standards organization and frequently (or almost always) makes
decisions for one set of reasons (e.g. patent fees) while claiming to
have other reasons.  In a case like this, what the ITU thinks is
completely irrelevant.  What does matter is measured performance and
the recipes for evalutating and repeating those measurements.

The bigger question remains.  Is the de facto choice of LZS good enough,
bad as it is on compression effectiveness grounds?
Is v.44 enough better to justify adding to the CCP babel?  How many
implementations of v.44 PPP compression can reasonably be expected given
the market dominence of LZS?

Finally, I have a question about the expected status of a v.44 RFC.
It would be Informational, right?