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

From: [email-masked]
Date: Mon, 30 Dec 2002 16:52:46 -0800

James

Thanks for your comment on draft-heath-ppp-v44-02.txt. In answer to your concern that the draft contains modes that require 
sequencing without specifying a sequencing header as part of the V.44 
compression protocol, I have included below some sections of RFC1663, 
RFC1967, and RFC1993.   It is my impression that RFC1663 is designed to 
provide a reliable link and thus maintain sequencing for compression 
protocols over PPP.   RFC's 1967 and 1993 are examples of  two other 
compression protocols that also have modes that require sequencing, also 
do not provide a sequencing header, and also reference RFC1663 as one 
method of providing the required reliable transmission and sequencing.

I considered such a sequencing header for the V.44 compression protocol 
but when I looked at some RFC's like 1974 that made use of such a header 
and the methods used to keep the dictionaries synchronized I thought these 
sequencing methods were far too complex and conflicted with the basic 
premise of compression, which is to reduce the number of bytes being 
transmitted.  I think is much better to leave it to each network architect 
to determine the type of reliable transport that is used to maintain any 
packet sequencing and data integrity that is required for compression or 
other features.  I also think that the compression function and the 
reliable transport/data integrity functions should be kept separate to 
allow maximum flexibility in where and how they are implemented within 
protocol stacks. 

Certainly compression, regardless of the packet sequencing issue, requires 
that the data passed to the de-compressor be uncorrupted and free of link 
errors.  But since compression is often not the only protocol component 
that requires error free data I don't think the compression function needs 
it's own checksum independent of other CRC's or checksums that are 
appended to network datagrams.

I am not that familiar with all the most common implementations of PPP, so 
if it is the case that RFC1663, PPP Reliable Transport, is not widely used 
and in real PPP networks using PPP compression it is much more desirable 
that the compression protocol provide internal methods to maintain any 
required sequencing then I can revisit this issue.  But I would prefer 
that the methods used to maintain sequencing and insure the integrity of 
compressed data be kept separate from the V.44 compression protocol in 
PPP.

regards
Jeff Heath

RFC1663   PPP Reliable Transmission

   Generally, serial link reliability is not a major issue.  The
   architecture of protocols used in datagram networking presume
   best-effort non-sequential delivery.  When errors are detected,
   datagrams are discarded.

   However, in certain circumstances, it is advisable to provide a
   reliable link, at least for a subset of the messages.  The most
   obvious case is when the link is compressed.  Since the dictionary
   is recovered from the compressed data stream, and a lost datagram
   corrupts the dictionary, datagrams must not be lost.  Not all
   compression types will require a reliable data stream, since the
   cost to detect and reset a corrupt dictionary is small.

RFC 1967   PPP LZS-DCP Compression Protocol (LZS-DCP)

      When using one or more compression histories, the implementation
      MUST rely on either a lower layer reliable link protocol (RFC
      1663), use a technique to keep the compressor and decompressor
      histories in synchronization, or both.  The LZS-DCP protocol
      provides the Request-Req and Request-Ack bits in the DCP header
      for this purpose.  Since this synchronization is done on a per
      history basis, the history number fields are required to be the
      same size in both directions of the link.  Any data contained in
      the packet is processed after the signaling bits are processed.

RFC1993   PPP Gandalf FZA Compression Protocol

Reliability and Sequencing

      The FZA algorithm expects a reliable link, as described in "PPP
      Reliable Transmission" [6].

      FZA expects the packets to be delivered in sequence.

James Carlson <[email-masked]> writes:

> My comments are probably arriving way too late, but I'm vaguely
> uncomfortable with a compression protocol that has modes requiring
> sequencing and that (unlike all of the other CCP algorithms defined to
> date) includes no sequencing header.

> I'd certainly prefer either a one or two octet header before the
> compressed data, as has been done with RFCs 1974, 1975, 1977, 1979,
> 2118, or a trailing checksum as with 1978.

> -- 
> 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: James Carlson <[email-masked]>
Date: Tue, 31 Dec 2002 12:53:52 -0500

[email-masked] writes:
> RFC1967, and RFC1993.

Yes, I'm familar with those.  RFC 1663 is LAP-B, which isn't just
error detection, but also error *correction*.  I recommend looking
over RFC 3366 ("Advice to link designers on link Automatic Repeat
reQuest (ARQ)") section 2.1 for a discussion of the sorts of
upper-level problems this can cause.

>   It is my impression that RFC1663 is designed to 
> protocols over PPP.

It might be appropriate to use 1663 for a single link-layer hop that
has non-negligible error rate, such as (say) a synchronous link.  One
could imagine, for instance, running RFC 1663 PPP over the raw
synchronous interface provided by V.{34,90,...}, and using V.44
compression in PPP rather than V.42bis.  However, I think it's hard to
say that use of 1663 is generally a good idea in *all* cases or even
in *many* cases.

If you want to require implementation of RFC 1663 for some proprietary
compression scheme, I suppose that's fine.  It will likely limit the
cases in which the compression mode can be used, since 1663 is
somewhat rare (I know that Cisco has it; any others?), but that's by
definition not a problem for anyone else.

If, however, this is for a non-proprietary scheme, then I think it
would be best to follow the precedent established by the commonly-used
compression algorithms for PPP.  These are:

	- RFC 1974 STAC LZS Compression Protocol
	- RFC 1977 BSD Compression Protocol
	- RFC 1979 PPP Deflate Protocol
	- RFC 2118 Microsoft Point-To-Point Compression (MPPC) Protocol

All of these use embedded check bytes to validate synchronization,
rather than requiring the underlying layer to be perfectly reliable.

>   RFC's 1967 and 1993 are examples of  two other 

RFC 1967 does *not* require the use of RFC 1663.  Section 2.3 says:

      When using one or more compression histories, the implementation
      MUST rely on either a lower layer reliable link protocol (RFC
      1663), use a technique to keep the compressor and decompressor
      histories in synchronization, or both.  [...]

However, if you look at section 2.5, you'll see that the packet header
has provisions for both sequence numbers and LCB for error detection:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          PPP Protocol         |   DCP-Header  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       (History Number)        |  (Seq Num)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     (LCB)     |
   +-+-+-+-+-+-+-+-+

(Cisco has a 1967 implementation; I don't know of any others.  I've
never seen it used in practice.)

You're right that RFC 1993 does require a reliable underlying link
(and suggests RFC 1663 as one way to achieve that).  It's a stand-out
in this area, and is a proprietary protocol.  I don't know of any
implementations, though I'd be interested to hear about them.

> transmitted.

I agree that RFC 1974 is over the top.  How about the simple sequence
numbering used in RFC 1977 or RFC 1979?

>  I think is much better to leave it to each network architect 

I mostly agree with that philosophy, except that I think it would
require an overhaul of RFC 1663 to give it characteristics similar to
the simple error detection (without retransmission) already used in
most PPP compression implementations.

> appended to network datagrams.

There are varying levels of "error free" available here.  PPP assumes
that the underlying transport delivers frames in-order, and little
else.  It typically runs over protocols (such as RFC 1662 framing)
that provide only error detection -- meaning that the upper levels of
PPP see only error-free frames, not necessarily *all* frames.  Frames
with errors are discarded rather than retransmitted.

I do recommend looking through the PILC RFCs.

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