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

From: [email-masked]
Date: Wed, 15 Jan 2003 11:14:03 -0800

Thomas & James

Sorry, I have been too busy to reply to the last email from James.   The 
basic point of discussion is whether or not this ID should have the same 
sequence number and dictionary synchronization mechanisms that other PPP 
compression RFC's (like 1974, 1977, etc) have defined for those modes that 
require reliable, in-sequence delivery.

Firstly, this ID does not require that PPP Reliable Transport or LAPB be 
used, it just requires a reliable, in-sequence mechanism of some kind.  I 
can change the ID to make that more clear if necessary.

Secondly, if such a reliable, in-sequence mechanism is not already in 
place, or is too complex to implement just for compression then the other 
option is to use Datagram Mode as defined in the ID which does not require 
a reliable, in-sequence mechanism.  Albeit the compression ratio may not 
be quite as good.

I could add the sequence number and dictionary synchronization mechanisms 
used by RFC'c 1974, 1977, etc. but in my mind that brings up a host of 
issues that need to be addressed as follows:

- do real implementations of RFC 1974, for instance, use single or 
multiple compression history modes that require sequence numbers and 
dictionary sequencing?  Or do most real implementations just go with no 
history and compress each packet individually such that reliable, 
in-sequence delivery is not required. 

- 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.

- 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.

If the answer to these issues is that:

(1) yes, in real implementations of RFC 1974 single and multi compression 
histories are used, i.e. sequencing is used
(2) yes, rely on Reset-Request and Reset-Ack CCP packets or on 
renegotiation of the Compression Control Protocol and let the receiver 
discard packets in the meantime.  We don't want to use Datagram Mode 
instead.
(3) yes, we want the compression function to discard packets and let the 
higher layer worry about them, regardless of the possible affect on 
bandwidth.  We don't want to use Datagram Mode instead.

then end of discussion, I will add that same capability to the V.44 draft 
if that is what is needed to make sure V.44 is used over PPP in all of its 
operating modes.

If the answer to those issues is no, then I recommend we change the ID to 
make it clear that Datagram Mode should be used in the absence of a 
reliable transport.  V.44 gets excellent compression doesn't suffer as 
much as other algorithms when compressing one packet at a time.

regards
Jeff

Thomas Narten <[email-masked]>
01/15/2003 09:14 AM

        To:     [email-masked]
        cc:     James Carlson <[email-masked]>, Karl Fox 
<[email-masked]>, [email-masked]
        Subject:        Re: draft-heath-ppp-v44-02.txt

Just to clarify the status of this, I'm assuming that the document is
still under active discussion and I should continue to wait for more
followup? I.e., it's not quite ready for publication as an RFC yet?

Thomas

---

From: James Carlson <[email-masked]>
Date: Wed, 15 Jan 2003 14:31:40 -0500

> can change the ID to make that more clear if necessary.

OK, though that's still out of step with the other RFCs.  If an
implementation elects not to do LAP-B, does it know for certain that
the underlying transport is reliable and in-sequence?

> a reliable, in-sequence mechanism.  Albeit the compression ratio may not 

Understood, though that's not what the other RFCs do.

> in-sequence delivery is not required. 

All of the ones I've seen use a single history -- the multiple history
stuff is (mostly) unnecessary.  I haven't seen any taht default to
packet-by-packet mode.  It's too weak.

> packets received until dictionary sync between the transmitter and 

Right.  That mechanism is already defined by RFC 1962.  No extra work
is required here.

> without any mechanism to have them re-transmitted by the PPP link?

Yes.  PPP is generally a datagram service.  RFC 1662, for instance,
does not retransmit on a CRC error.  IP has a checksum and specifies
no recovery procedured.  I don't think this is necessarily different.

>  And 
> syncronization.

Right.  A smart implementation of *any* compression algorithm needs to
be able to disable compression (shutting down CCP) if it knows (by
configuration) or can find out (by monitoring statistics) that life is
going badly.

> histories are used, i.e. sequencing is used

Just single.

> discard packets in the meantime.  We don't want to use Datagram Mode 

Yes.

> bandwidth.  We don't want to use Datagram Mode instead.

More or less, yes.  It's not that there's "no worry," but rather that
the drop-everything-and-restart mechanism is intended to handle the
*occasional* error in a reasonable way such that the link doesn't just
fall apart.

Note that doing this is more robust for a number of reasons.  One of
these reasons is that "reliable" links are *not* perfect.  There are
occasional implementation flaws and unrecovered errors, no matter how
improbable.  If, for the single history mode, you don't have a way of
detecting unexpected problems, then the occasional DMA error (or some
such idiopathic problem) will cause the link to lock up solid -- it
will fail and not recover.  Mechanisms that can recover from failures
tend to be a little more stable in the field than ones that cannot.

Obviously, some implementations are bound to be better than others;
that's life.

> much as other algorithms when compressing one packet at a time.

I'd recommend adding *either* a one or two octet header for a sequence
number *or* a one or two octet trailer for some sort of check data
based on the uncompressed datagram.  Either of those will handle the
problem.

-- 
James Carlson, Solaris Networking         <[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: Vernon Schryver <[email-masked]>
Date: Wed, 15 Jan 2003 12:43:54 -0700 (MST)

> From: [email-masked]

> ...

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.

> 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]