Summary

  • RFC 1967 gives each LZS history its own order, error-checking state and reset exchange; packets on different History Numbers need not be ordered against one another.
  • C/U=0 says the current data is uncompressed, not that compression state stayed unchanged: under Process-Uncompressed, both peers update the named history from those bytes.
  • Sequence numbers, LCB and Reset-Ack answer different questions. None restores a lost datagram or proves that a reconstructed PPP packet reached its application.

A plain packet with a hidden consequence

The easiest packet to misread in RFC 1967 is the one that is not compressed. Its DCP header carries C/U=0, and the Data field contains the original datagram. A capture label may therefore say “uncompressed” and invite the conclusion that the compression engine was irrelevant.

That conclusion depends on Process Mode. If the peers selected Process-Uncompressed, the transmitter and receiver both feed those plain bytes into the specified history. No bandwidth was saved on this packet, yet the dictionary has moved. The next compressed packet may depend on material learned from it. If Process Mode is None, the receiver does not alter history from an uncompressed packet; a transmitter that modified history before choosing native output must clear that history before processing the next datagram.

The C/U bit describes representation. Process Mode decides state. The distinction is the article's centre because it prevents a familiar operational mistake: treating “not compressed” as “not part of the compression protocol.”

Why DCP was added

RFC 1967, published in August 1996 as Informational, describes Stac LZS for PPP with a Data Compression Protocol header. The RFC Editor record and IETF Datatracker establish its identity and status. It built on the non-DCP Stac LZS profile later published as RFC 1974.

The enhancement put three choices onto the data path. The header says whether the payload is compressed; it carries Reset-Request and Reset-Ack as bits rather than relying on generic CCP reset packets; and it can combine a per-history sequence number with a longitudinal check byte. Those choices let a failed history be repaired without suspending unrelated histories or the reverse direction, and let useful data travel in the same packet as reset signalling.

This is not a new analysis of RFC 1962. CCP's phase, directional option negotiation and generic reset codes are prerequisites owned by earlier coverage. RFC 1967 begins where a negotiated LZS-DCP data packet has a particular header and history.

One link, several independent memory lanes

History Count controls the number of state partitions. Zero selects connectionless operation: one buffer is cleared at the beginning of every datagram, and every outgoing datagram carries R-A. The compressor no longer depends on the previous packet or on cross-packet order. That makes loss and reordering easier to contain, at the price of the compression gain a stream can provide.

A count of one keeps one continuing history. Counts from two through 65535 allow separate histories. With multiple histories, the receiver maintains a buffer, check state and signalling state for each. Order must be preserved within a History Number, while packets belonging to different histories need no common order.

The field itself changes size with the negotiated count. It is absent below two histories, one octet for 2–255 and two octets from 256 upward. If either direction uses multiple histories, every compressed and uncompressed packet in both directions carries the field, sized to the larger directional count.

RFC 1967 says a history could represent a logical connection. “Could” matters. The wire number selects a negotiated compression buffer. It does not identify a subscriber, business transaction, application, five-tuple or durable service flow. That richer mapping belongs to an implementation log, not to the field.

Anti-expansion is a decision about present and future bandwidth

Stac LZS can expand data by as much as 12.5%. A link can negotiate an MRU large enough to carry the expansion, but when compressed output plus its header would exceed the peer's Information-field MRU, the sender must use an uncompressed LZS-DCP packet.

With Process Mode None, an expanding input offers a choice. Send the expanded representation and retain the history, accepting current overhead in hope of future compression; or send native bytes and clear the history, protecting today's packet size while sacrificing context for tomorrow. Process-Uncompressed adds a third route: send native bytes, update both histories and keep the future context.

“Anti-expansion” therefore does not mean “bypass.” It means selecting which cost to pay: present bytes, a reset of learned state, or synchronized processing of uncompressed data. This mechanism is distinct from the LZW and CLEAR behavior of RFC 1977, which another commission owns.

Two checkers, two different questions

Check Mode may use an LCB, a sequence number, or both; None is allowed only when no continuing history is maintained. The sequence field is one octet and advances modulo 256 on data-bearing packets within its own history. A gap or unexpected order creates a receive failure for that history. It does not compare content.

The LCB compares content differently. It XORs 0xFF with every octet of the original uncompressed datagram, and the receiver repeats the calculation after decompression. It appears only on compressed-data packets when the selected mode includes it; RFC 1967 forbids it on uncompressed packets. One octet of XOR is useful fault detection, not cryptographic integrity. Different byte patterns can collide.

A link FCS has yet another scope, and RFC 1663 defines a reliable numbered mode. Sequence, LCB, FCS and reliable transport cannot be collapsed into a single “valid” flag. The IANA PPP registry records the assigned PPP values, but a registry entry says nothing about a particular packet's state or delivery.

Reset travels with the next useful packet

On a receive failure, the receiver sends R-R for the failed History Number. It may attach data waiting in its own outgoing direction, or send a reset request without sequence, data or LCB. The peer processes R-R first, clears its compressor for that history, and must eventually send R-A with a non-empty Data field. If no data is ready, it waits.

R-A has an unusually precise meaning: the named history was clear immediately before the data in that R-A packet went through the compression transformation. The receiving side handles the reset indication and then processes the packet's data. The transmitter's sequence counter is not reset; the receiver resynchronizes its expected sequence reference from the R-A packet.

During the wait, packets for the failed history are discarded until R-A arrives. The receiver owns the reliability of the exchange and may need to send R-R again. Other histories can continue. So can the opposite direction.

This is bounded recovery, not time travel. RFC 1967 explicitly says decompression cannot recover dropped, erroneous or misordered datagrams. Reset returns two copies of one history to a common initial state. It does not refill the hole.

The evidence chain continues after decompression

A defensible record starts with negotiated History Count, Check Mode and Process Mode. It then records History Number, C/U, R-R/R-A and the actual state transition; sequence and LCB results remain separate. For C/U=1 it records decompression. For C/U=0 with Process-Uncompressed it records the history update even though no decompression occurred.

Only afterward can the PPP receiver attest that it accepted and handed off the reconstructed Protocol ID and Information field under RFC 1661. An endpoint or application must supply the final receipt. Successful decoding establishes neither.

RFC 1990 is another boundary: its multilink fragment sequence, B/E flags and bundle reassembly solve a different ordering problem. An LZS History Number is not a multilink fragment number.

The RFC Editor's errata endpoint yielded no usable body during this review, so this article does not claim an empty errata set. It also makes no claim about present deployment, implementation quality or incident history. RFC 1967 itself says security issues are not discussed.

Heng Lu's Running-Code Primacy provides the editorial discipline: specified behavior and observed operation are separate. Minimum Initial Specification keeps a field's meaning within its verifiable function. Reality Layers warns against turning a protocol symbol into an outcome, while Reality, Not Advocacy calls for describing structure without inventing villains. These essays guide the reading; they are not sources for the protocol's history.