Summary

  • RFC 1962 made PPP compression a pair of receiver-led bargains: one primary algorithm could be selected in each direction, different algorithms could coexist, and failure to agree left only that direction uncompressed.
  • Configure-Ack confirms an offered option set; 0x00FD marks a compressed datagram without naming its algorithm; Reset-Ack closes a matching reset exchange. None alone proves correct decompression, restored lost data, reliable transport, endpoint delivery or application success.

Imagine two desks joined by one cable. Each desk owns an inbox and an outbox, but the dictionaries used to shorten messages belong to the inboxes. The clerk on the left may be able to expand one shorthand; the clerk on the right may have memory for another. If the left inbox loses its place, there is no reason to burn the right inbox's still-valid dictionary.

That is the operating shape hidden inside RFC 1962. The memo did not define one universal compressor. It defined the Compression Control Protocol, or CCP: a way for the endpoints of a PPP link to configure, enable and disable compression methods, and to report a decompression failure reliably enough to restore synchronization. Published in June 1996 as Standards Track and later updated by RFC 2153's general vendor-extension mechanism, it was thin by design.

Capability points toward the receiver

CCP starts only after PPP has reached its Network-Layer Protocol phase. A control packet arriving earlier should be silently discarded. Compressed traffic must wait longer still: CCP itself must reach the Opened state.

The crucial sentence concerns the direction of an option. A CCP Configuration Option names an algorithm and parameters that the receiver is willing or able to use to decompress data sent by its peer. The receiver may offer several possibilities; negotiation selects one primary method for that direction. The other receiver conducts its own bargain for traffic travelling back.

This is why RFC 1962 can permit a different algorithm in each direction, or compression in only one. Speed, memory, implementation cost and licensing could be asymmetric. A low-memory device did not have to accept a decoding burden merely because its own transmitter could encode that format.

The refusal path matters as much as success. An unknown option receives Configure-Reject. A known method with unacceptable parameters receives Configure-Nak containing acceptable values. If every method is rejected, compression is disabled in that direction and the PPP link continues without it. Disagreement changes a local compatibility set; it does not automatically invalidate the connection.

What Configure-Ack actually acknowledges

CCP borrows the LCP exchange and state machine. Under RFC 1661, a valid Configure-Ack is a positive response to a specific Configure-Request. That is useful evidence: at that moment, the peer accepted that exact option encoding. It is not a permanent certificate for the link.

A later audit still needs the request, acknowledgement identifier, direction, option bytes, parameters, state transition and time. It also needs evidence that both automata reached Opened before compressed data appeared. A capture containing only an Ack cannot show that a later frame used the accepted implementation, that renegotiation did not intervene, or that a vendor-specific subtype was interpreted identically.

RFC 2153 sharpened the vendor-extension envelope after RFC 1962. RFC 1915 records the procedural variance used while patented compression work advanced. Neither record turns an OUI or an assigned option number into proof of compatible code. Numbers coordinate syntax; the decoder still has to run.

0x00FD says less than it appears to say

Once compression is open, a PPP Protocol field of 0x00FD identifies a Compressed Datagram. In the model where each physical link of a multilink connection has its own compression state, 0x00FB marks the individual-link compressed datagram and 0x80FB carries its control protocol. IANA still lists those assignments.

RFC 1962 is explicit that 0x00FD does not identify the compression algorithm. There is only one primary algorithm in a direction at a time, so the receiver interprets the frame by joining the marker to its current negotiated state. Remove the control transcript, the direction or the state epoch, and the same two bytes cannot tell an investigator whether the intended decoder was Predictor, LZS, a vendor method or something else.

Nor does the marker promise that compression made the frame smaller. An algorithm may expand some inputs. If the result exceeds the PPP Information-field limit, the sender may use the native uncompressed protocol or an algorithm-specific fragmentation method. “Compressed” here is a stateful framing class, not a measurement of savings.

Detecting loss is an algorithm's separate job

Stateful compression makes one missing or corrupted frame dangerous because the decompressor's future dictionary may diverge from the compressor's. The generic CCP header does not solve that. RFC 1962 requires an algorithm to provide a way to determine whether data is passing reliably, or to require a reliable transport such as RFC 1663's numbered mode. It strongly encourages validation of decompressed data or recognition of an out-of-sync pair.

The memo mentions periodic hashes and CRC checks as possibilities, not as one mandatory universal field. Algorithm profiles make the distinction concrete. RFC 1974's Stac LZS profile can use sequence numbers, a longitudinal check byte or CRC and can maintain more than one history. RFC 1967's LZS-DCP profile has its own packet bits and resynchronization rules. Those details cannot be reconstructed from a bare 0x00FD frame.

The evidence therefore has two separate questions. Was a frame classified under the negotiated compressor? Did the algorithm-specific sequence or integrity mechanism show that decompressed bytes remained synchronized? A yes to the first is not a yes to the second.

Reset contains the damage but does not reverse time

CCP adds Code 14 Reset-Request and Code 15 Reset-Ack so that decompression failure in one direction need not disturb traffic in the other. When a receiver detects failure, it sends Reset-Request. Until a valid matching Reset-Ack arrives, it discards subsequent compressed packets and may retransmit the same request identifier.

The peer that receives Reset-Request clears its transmitting compressor to an initial state and returns Reset-Ack with the copied identifier. The original receiver then resets its decompressor. Multiple acknowledgements may be in flight, which is why the expected identifier matters.

This exchange restores a common starting point; it does not restore the datagrams discarded while the request was outstanding. It does not show that the next compressed block passes its CRC, that a different history number was healthy, or that the reverse direction ever failed. Reset-Ack is a synchronization receipt, not a data-recovery receipt.

That distinction is visible in RFC 1974: after a receive failure, data for the affected history is discarded until the matching acknowledgement arrives, and the receiver is responsible for making the request/acknowledgement exchange reliable. The application may recover through retransmission at another layer, or it may not. CCP does not claim the result.

A historical lesson in narrow coordination

Heng Lu's Running-Code Primacy offers a disciplined way to read this old protocol. Publication, option assignment and acknowledgement matter because they coordinate running systems; none should be promoted into a larger authority than its executable transition. The minimum common layer names packet types, option handling and reset behaviour. Future choices—algorithm, parameters, memory trade-offs and whether to compress at all—remain local to the two receivers.

The evidence ladder should remain equally narrow: Network-Layer phase; direction-specific request; matching Ack; Opened state; selected compressor; compressed-frame marker; integrity or sequence validation; reset completion if needed; valid decompressed packet; next-hop receipt; endpoint receipt; application result. Each rung enables the next. None silently contains it.

The Internet did not gain resilience by declaring both directions healthy together. It gained resilience by making the boundary small enough that one direction could admit failure, discard unsafe state and begin again while the other continued to work.

Sources