Subject: ppp compression

From: [email-masked]
Date: Wed, 6 Jun 2001 13:04:47 -0400

Hello,

We have developed a new technique that improves the performance
of PPP's CCP compression protocol when packets are lost or
corrupted.  This technique can be used with many compression
algorithms and does not require changes to CCP.  We are considering
writing an draft RFC describing this idea, but first we wanted to
get this list's opinion if there would be interest in this.

Previous approaches to packet compression either assume
the packets arrive reliably and reset the compression state
when an error has occurred, like PPP's CCP "streaming compression",
or don't use inter-packet compression, like IPComp's "stateless
compression". Streaming compression has poor performance when
packets are lost, but achieves greater compression, and has better
performance when most packets are correctly received.

In our method, the sender knows which packets have been received and
only uses these for compressing future packets.  In this way, when a
packet is received it can be decompressed, even if other packets
have been lost. The receiver updates the sender by piggybacking
acknowledgements in packets traveling in the reverse direction;
the acks are only used to inform the compressor of successfully
received packets, not for retransmission.

Our method combines the error resiliency of stateless compression
with inter-packet compression.  It performs comparably
to streaming compression with low error rates, and comparably to
stateless compression with high error rates.

We have a prototype PPP CCP implementation of our algorithm,
and experimental results comparing TCP performance when run
over PPP with varying error rates, using our algorithm and
stateless and streaming compression methods. A slightly out
of date paper is available at
http://www.cs.bell-labs.com/who/seanq/pub.html#comp.
This paper doesn't include the PPP and TCP results, but gives
more details about the technique.

Sean Dorward and Sean Quinlan
[email-masked], [email-masked]

---

From: James Carlson <[email-masked]>
Date: Wed, 6 Jun 2001 15:26:39 -0400 (EDT)

> received packets, not for retransmission.

I've just read through your paper quickly.  It's a useful idea, but I
was a little surprised to see no mention at all of the ROHC work
that's been done.  I seem to recall that several similar schemes were
proposed there (GEHCO, perhaps) and that all of these have IPR issues.

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Pete McCann <[email-masked]>
Date: Wed, 6 Jun 2001 16:48:47 -0500 (CDT)

James Carlson <[email-masked]> (JC) writes:

JC> I've just read through your paper quickly.  It's a useful idea, but I
JC> was a little surprised to see no mention at all of the ROHC work
JC> that's been done.  I seem to recall that several similar schemes were
JC> proposed there (GEHCO, perhaps) and that all of these have IPR issues.

Just for the record, GEHCO has no IPR associated with it.  The basic
idea is simple, and we were not the first to propose it.

-Pete