Summary

  • RFC 1553 compressed repeated IPX information by storing a complete header in matching sender and receiver slots. The missing bytes became shared state, not nothing.
  • A general IPX context needed a Confirmed Initial and a matching Confirm before later compressed frames were safe. Compressing the slot number itself required the decompressor to learn every receive error; after a discard, it had to reject implicit-slot packets until an explicit slot arrived.
  • The memo's approximate 2:1 figure was an illustrative calculation based on assumed packet sizes. Standards Track in 1993 and Historic today are documentary facts, not evidence of deployment, measured performance or application success.

One octet carried a history it did not contain

Imagine two tables facing each other across a low-speed WAN link. Slot 7 on the left holds a full IPX header: source and destination addresses, packet type, hop count, checksum convention and length context. Slot 7 on the right holds the same header. A later packet can carry a tiny CIPX header that says, in effect, “reuse what we already agreed.”

The packet is short because the relationship is long.

That is the operating idea in RFC 1553, Compressing IPX Headers Over WAN Media (CIPX). Its Datatracker record and RFC Editor information page identify a December 1993 Standards Track publication from the IETF Point-to-Point Protocol Extensions working group; the RFC Editor now marks it Historic. The plain-text edition preserves the same specification, while the errata surface is a documentary check.

Those records prove what was specified. They do not prove which products implemented it, how often it ran, what ratio a real workload achieved or whether any user saw an improvement.

RFC 1553's deeper historical value lies in the price of omission. A self-contained header repeats information. A compressed header saves bytes by making the receiver remember. The protocol therefore has to govern not only packet syntax but the distributed memory that gives an omitted field meaning.

Two compression strategies shared one dependency

The ordinary IPX header occupied thirty octets. RFC 1553 required two strategies. The general method could compress an IPX header to between one and seven octets without depending on the transport protocol. The second method targeted the combined thirty-six-octet NCP/IPX header for NCP request and reply types 0x2222 and 0x3333, reducing it to between one and eight octets.

Other NCP types did not receive the NCP-specific treatment. They could still use the general IPX method. The distinction mattered because NCP request/reply sequencing offered recovery evidence that a generic IPX datagram did not.

RFC 1553 also allowed header compression to coexist with data compression, but order was part of correctness. A sender compressed the header before compressing the data stream. A receiver decompressed the data before reconstructing the header. “Both algorithms enabled” was not an adequate record; the executed order was another receipt.

The method drew disclosed inspiration from Van Jacobson's RFC 1144, whose information page places TCP/IP header compression in the low-speed serial-link context. That relationship is prior-art context, not evidence that CIPX inherited every TCP recovery property or enjoyed the same deployment.

Compression was a pair of state machines

After negotiation, even a regular, uncompressed IPX packet carried a one-octet CIPX prefix. Compressor and decompressor maintained tables for connection state. A slot held the original header. The compressor compared a new packet with its stored copy to decide what had changed; the decompressor combined the transmitted differences with its copy to rebuild the original.

This means a packet capture containing one compressed frame cannot by itself prove the reconstructed header. An investigator also needs the selected slot, the slot generation, the Initial that installed it, every later field update, and the loss or discard history between that installation and the frame.

The smallest CIPX header could be only the flags octet. Optional bits determined whether the packet also carried a slot number, checksum, length or NCP task number. When a field was absent, the receiver applied a rule: use the last slot, assume the conventional 0xFFFF checksum, derive length from the lower layer, or reuse the previous task number.

Each omission therefore named an authority outside the packet. “Absent” meant “recover from this other evidence,” not “irrelevant.”

The first generic context required confirmation

RFC 1553 treated loss of a generic IPX Initial as a special problem. If that packet disappeared and the sender later emitted a compressed packet, the receiver lacked the header needed to reconstruct it. The ordinary IPX header did not contain sufficient information to identify retransmission and repair the association automatically.

The protocol answered with a Confirmed Initial packet. It carried the complete IPX packet plus a slot number and a one-octet ID. The receiver's Confirm echoed the slot and ID. Only after receiving that confirmation could the compressor begin sending compressed frames for the association.

Slot and ID together named a header generation. Reusing a slot for a different header required an incremented ID. The document did not define an eternal unique identifier; it required a combination unlikely to repeat during a “reasonably long period,” whose practical length depended on transmission speed, round-trip delay and load.

That bounded uniqueness matters. A slot number alone identifies storage, not which historical contents the storage should contain. An ID alone lacks the slot namespace. A Confirm proves receipt of a named association, not successful delivery of every later packet or application outcome.

The sender did not have to freeze while waiting. If more data arrived for the same header, it could send another Confirmed Initial with the same slot and ID. If a different header needed the slot, the sender could issue a new Confirmed Initial with an incremented ID. Efficiency remained possible, but the generation change had to stay observable.

NCP earned a narrower unconfirmed path

NCP request and reply packets had an extra property: their sequence number normally advanced by one, and normal transport behavior could retransmit a lost packet. RFC 1553 used that signal to permit an Unconfirmed Initial. After sending it, the compressor could immediately send compressed frames without waiting for a Confirm.

The permission was not a declaration that confirmation never mattered. It depended on a later discrepancy becoming visible. If the observed sequence was not exactly one greater than the previous one, the sender had to send a new Initial, even if it reused the same slot. A lost compressed packet could also surface through a meaningful checksum or a later retransmission.

This is a localized recovery rule. Generic IPX did not acquire it merely because NCP had it. Nor did the existence of a sequence field prove that every loss had already been detected. The record needs to show which compression strategy applied, what sequence the decompressor expected, which packet broke the progression and which Initial restored context.

Saving the slot octet demanded better observability

By default, compressed packets included enough information to select their slot. RFC 1553 offered a further optimization: omit the slot identifier and tell the receiver to use the same slot as the preceding packet.

One more octet disappeared. One more piece of state became implicit.

The specification therefore imposed a strict precondition. Slot compression could be enabled only where the receiver could account for all erroneous and discarded packets. On a PPP link, the link layer had to communicate a reception error to the decompression module. Without that signal, losing the packet that changed the active slot would leave the decompressor unable to know which slot a later implicit reference meant.

Once a discard occurred, the receiver was not permitted to guess. It had to discard subsequent packets that omitted the slot number until a packet carrying an explicit slot arrived.

That refusal can look wasteful in a throughput graph. It is actually evidence preservation. Delivering bytes reconstructed from an unknown context would turn a detectable gap into silent corruption. RFC 1553 chose temporary loss of availability over an invented header.

The lesson extends beyond this protocol without pretending that every modern compressor is CIPX. If an optimization removes an identifier because “it is the same as last time,” its safety depends on observing every event that can change what “last time” means.

Regular, restart and Reject paths kept disagreement visible

Not every packet deserved a slot. RFC 1553 retained a Regular packet for traffic that could not be compressed, for memory shortage, for sporadic flows not worth table setup, and for future IPX changes that might defeat the algorithm. A good efficiency mechanism needed a truthful non-efficient path.

It also protected an important restart boundary. The flags octet could never be 0xFF, because an ordinary IPX header often began with the 0xFFFF checksum value. If one endpoint failed and restarted on a medium such as an X.25 permanent virtual circuit, it might send normal IPX without a CIPX prefix while the other endpoint still believed compression active. The receiver had to recognize the ordinary header and renegotiate, not reinterpret it through stale compression state.

Finally, a Reject packet let the decompressor report an unsupported packet form or dependent flag. Recognized parts could be cleared from the returned flag value so that the remaining bits identified the rejected feature. Future extension was not permission to guess unknown semantics.

Regular, restart recognition and Reject were three different exits. Regular meant the sender deliberately carried a full packet inside the negotiated framing. Restart recognition meant the live peer state contradicted the negotiated assumption. Reject meant the framing was recognized but a feature was not. Collapsing them into “uncompressed traffic” would erase the repair decision.

Negotiation had more than one shape

On PPP, compression was disabled by default. The IPXCP option advertised the ability to receive compressed packets, and each endpoint had to request it separately if bidirectional compression was wanted. RFC 1552 and its status record provide the neighboring IPXCP context. The preceding History commission owns its conditional Opened and IPX-WAN completion problem; this Article does not retell it.

IPX-WAN could also negotiate CIPX. In that path, compression was symmetric: both ends used the same slot count and options, with the accepted Timer Response limited to a subset of what had been requested. An operator therefore cannot infer directionality from the word “CIPX” alone. The receipt must name the negotiation path and the actual agreed values.

The contemporary RFC 1548 and later RFC 1661, together with their 1548 and 1661 information pages, bound the PPP architecture around the mechanism. The IANA PPP Numbers registry preserves coordinated identifiers. None of those sources proves that a pair of endpoints negotiated the same slot table or rebuilt one real packet correctly.

The attractive ratio was an assumption ledger

RFC 1553 said CIPX could produce roughly a 2:1 ratio including header and data for normal IPX traffic. Its performance section showed how the figure was formed: an assumed average data length of twenty-six octets, an uncompressed header of thirty and an assumed two-octet compressed header.

That is a useful design calculation. It is not a measured fleet result.

Actual gain depended on packet sizes, number of active connections, number of available slots, slot reuse, regular fallbacks, Initial and Confirm traffic, errors, retransmissions, link characteristics and any additional data compression. A counter of transmitted bytes could show wire savings; it could not alone show decompression correctness or application latency.

The Security Considerations paragraph said CIPX did not significantly alter the basic security of IPX. That statement records the memo's analysis boundary. It is neither a modern security assurance nor a basis for inventing a vulnerability absent evidence.

Heng Lu's Running-Code Primacy helps keep the compression ratio, executed decoder and observed result in different layers. Minimum Initial Specification, Localized Future Decision and Voluntary Adoption illuminates the split between a shared packet contract and local decisions such as slot allocation or fallback. His reality-layer discipline prevents a registered identifier, negotiated option, stored context, reconstructed packet and user-visible outcome from impersonating one another. These later essays are a disclosed analytical lens, not evidence of the RFC authors' private intentions.

The missing bytes had owners

RFC 1553's smallest header was impressive because it relied on work already performed elsewhere. A compressor had selected a slot. An Initial had installed a complete header. A Confirm or protocol-specific recovery property had authorized omission. The link layer had made losses visible enough for the chosen optimization. The decompressor had preserved the same history.

The responsible operational record is correspondingly larger than the packet: negotiation owner and direction; accepted options and slot count; slot allocation and generation ID; complete Initial header; Confirm where required; link-error notification; discarded-packet sequence; explicit or implicit slot selection; checksum and length authority; reconstructed header hash; decompressor action; transport recovery; and application result.

Only that chain can explain why a one-octet header was sufficient. Compression did not abolish information. It reassigned custody.

Sources