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

James

thanks for your comments.  I will change the ID to include the same type 
of sequence and recovery mechanisms used in other RFC's.

It seems like you are also saying that no one will use what I describe as 
"Individual Link Mode" which is multiple histories over a PPP link.  If 
that is true, do you think I should I just remove that mode. 

thanks
Jeff





James Carlson <james.d.carlson@xxxxxxxxxxxx>
01/15/2003 11:31 AM

 
        To:     jheath@xxxxxxx
        cc:     Thomas Narten <narten@xxxxxxxxxx>, border@xxxxxxx, Karl Fox 
<karlfox@xxxxxxxxxxxxxxx>, ietf-ppp@xxxxxxxxx
        Subject:        Re: draft-heath-ppp-v44-02.txt


jheath@xxxxxxx writes:
> 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.

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?

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

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

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

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.

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

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

> - do we really want the compression function to be discarding packets 
> 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 
> 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.

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.

> (1) yes, in real implementations of RFC 1974 single and multi 
compression 
> histories are used, i.e. sequencing is used

Just single.

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

Yes.

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

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.

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

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         <james.d.carlson@xxxxxxxxxxxx>
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