Summary

  • MPPC depended on both PPP peers maintaining the same 8192-byte sliding history; every MPPC packet carried a 12-bit coherency count so loss or disorder could be detected.
  • After a mismatch, the receiver dropped the packet and sent CCP Reset-Request. The sender flushed its compressor and marked its next data packet FLUSHED; that packet reset the receiver and supplied the new count, so RFC 2118 needed no Reset-Ack.
  • The resulting evidence is narrow. A FLUSHED packet proves a new MPPC history boundary, not recovery of missing data, reliable delivery, payload integrity, peer identity, authorization or application completion.

The acknowledgement that never came

Generic CCP recovery looks like a control transaction. In RFC 1962, a decompressor that reports failure sends Reset-Request, discards later compressed packets, and waits for a matching Reset-Ack before returning to an initial state. That exchange has an identifier and an expected reply.

RFC 2118 chose another receipt for MPPC. A receiver that sees the wrong coherency count drops the packet and sends Reset-Request. The compressor clears its history when that request arrives, then sets the FLUSHED bit on the next MPPC packet. When the receiver sees that marked packet, it clears its own history and adopts the packet’s count. Synchronization is restored without Reset-Ack.

The distinction is more than packet trivia. The operative evidence is running traffic: the next independently decodable packet carries the boundary that matters. But the boundary says only that the two compression histories can begin together again. The dropped packet remains dropped.

Option 18 opened a particular transform

MPPC was not implicit in PPP. Its six-octet CCP option used Type 18, with one supported bit indicating the desire to negotiate the algorithm. By default or ultimate disagreement, the link used no compression. The current IANA PPP registry still records CCP option 18 as Microsoft PPC.

After PPP reached the Network-Layer Protocol phase and CCP reached Opened, compressed datagrams used PPP Protocol 0x00FD. That value identifies the compressed-datagram path; it does not by itself name the algorithm, because CCP negotiation supplied that context. The control protocol itself used 0x80FD. Mixing the two numbers collapses negotiation and data into one imagined fact.

MPPC accepted PPP Protocol values from 0x0021 through 0x00FA. Other protocol values bypassed the compressor. Successful option negotiation therefore meant permission to use one transform in one established context—not proof that every packet was compressed or that either endpoint had completed useful work.

An 8192-byte memory made packets interdependent

The algorithm kept a continuous LZ history. After 8192 compressed bytes, it could draw on a full 8192-byte window unless history had been flushed. This saved bandwidth by letting a later packet refer to material learned from earlier packets, while making correct decoding depend on both peers preserving the same memory.

The packet header exposed three useful boundaries. Bit A, called FLUSHED, meant the sender initialized history before generating the packet, so the packet did not depend on an earlier epoch. Bit B moved the history pointer to the front and had to appear at least once per 8192 compressed bytes. Bit C stated whether the present data was compressed. These bits described compression state, not transport or application state.

Expansion created another reset boundary. If compression made data larger, the sender transmitted the original bytes in an uncompressed MPPC packet. Before compressing again, it flushed history and marked the next outgoing packet FLUSHED. Saving the current packet from expansion cost the accumulated context for later packets.

Twelve bits detected a gap, not its cause

Every MPPC packet carried a 12-bit coherency count. It began at zero, advanced once per packet and wrapped after 4095. The receiver compared the arriving value with the value it expected. A mismatch exposed a missing or misordered step in the MPPC stream.

That mechanism allowed RFC 2118 to say MPPC did not require a reliable link. RFC 1663 offered a reliable PPP mode, but RFC 2118 regarded its overhead as usually unnecessary for this purpose. The same section also said packets had to arrive in sequence for history resynchronization to occur. “No reliable link required” never meant that arbitrary reordering was harmless.

A matching count says nothing about byte integrity. Two peers could advance their counters while bad data, an implementation defect or a later delivery failure occurred. RFC 2118’s Security Considerations section simply says security issues are not discussed. Compression state supplies no confidentiality, cryptographic authentication, authorization or replay protection.

A historical licensed mechanism, not a universal promise

RFC 2118 was published in March 1997 as Informational, not as an Internet Standard. Its licensing section limited MPPC use to PPP products interoperating with MPPC/PPP implementations and pointed to licences from Stac Electronics. That record explains part of the mechanism’s historical operating surface; it is not evidence about present licences, current patent status or deployment.

The careful reading follows Heng Lu’s Running-Code Primacy and Minimum Initial Specification: preserve the smallest claim each running signal can verify. Option 18 records negotiated capability. 0x00FD classifies a data path. The count detects a sequence disagreement. Reset-Request asks for repair. The next FLUSHED packet establishes a new history epoch. None grants authority to assert the outcome of another layer.

Sources and evidence boundary

The primary record is the RFC Editor’s RFC 2118 HTML, text edition, information record and errata endpoint. Context comes from RFC 1962, PPP itself in RFC 1661, reliable PPP in RFC 1663 and the IANA PPP registry. The two Heng Lu essays guide interpretation rather than protocol history. These sources establish specified behavior and documentary status, not contemporary deployment, performance, licensing, security or a particular packet’s application outcome.