Summary
- RFC 2395 adapted a 2,048-byte LZS sliding window to IP by resetting history before every datagram and flushing every compressed result, so no packet depended on earlier compression state.
- A fixed end marker separated compressed data from padding, but it proved only bitstream closure; it did not authenticate the packet, certify useful compression or establish application success.
- The roughly 90-byte threshold and Calgary Corpus ratios were bounded measurements. Transform agreement named a decoder while packet use, size benefit, successful decompression and delivered work remained separate evidence.
A useful memory became a dangerous dependency
Compression begins with repetition. LZS kept a 2,048-byte sliding window, found byte strings it had already seen and replaced them with shorter offset-and-length tokens. The longer useful patterns survived in memory, the more opportunities the compressor could discover. On a continuous stream, yesterday's bytes could make tomorrow's bytes cheaper.
An IP network supplied the opposite condition. Datagram order was not guaranteed. A packet could vanish while the next one arrived intact. Two packets from the same source could take different paths and reach the receiver in reverse order. If the decoder needed the missing packet's dictionary, a single loss would corrupt not only one payload but every later payload whose tokens referred to the lost history.
RFC 2395 solved that problem by declining the apparent optimization. Before processing each datagram payload, the sender had to reset the LZS compression history. Before decoding a compressed datagram, the receiver had to reset the decompression history. The same algorithm still used a sliding window, but the window's lifetime was confined to one packet.
That choice deserves to be read as an architectural boundary, not merely an implementation instruction. The algorithm supplied a memory mechanism. The profile decided how long that memory was allowed to exercise authority. A shared algorithm name did not make state lifetime universal.
Flush meant nothing could wait for the next packet
Reset alone did not close the boundary. A stream compressor might accept all input and still retain a few bits or bytes, hoping that more data would produce a better encoding. That behaviour would make the current output depend on a future call.
RFC 2395 therefore required the sender to flush whenever it transmitted a compressed datagram. Every input byte for that datagram had to appear in that datagram's output. Nothing could be held back for a later packet. The rule prevented payload from spilling across the network's independent delivery units.
The distinction is precise. Flushing showed that the encoder had emitted all input into the current compressed stream. It did not show that the packet reached the receiver, that the receiver accepted it, that decompression succeeded, that a transport checksum passed, or that an application used the reconstructed bytes. An encoder receipt is not a delivery receipt.
This bounded design also separated RFC 2395 from PPP uses of LZS. RFC 1967's LZS-DCP could maintain numbered histories and defined explicit checks and reset exchanges. RFC 1974 likewise operated inside a link protocol with sequence and history choices. The IPComp profile chose packet independence instead. Those documents share an algorithm family, not an identical state contract.
The end marker closed bits, not trust
LZS emitted raw bytes or offset-and-length references, followed by a defined end marker. Because the compressed bitstream did not necessarily finish on an octet boundary, the payload could contain trailing padding bits or bytes. The marker told the decoder where meaningful compressed data ended; the whole transmitted payload still had to occupy an integral number of octets.
Without that closure, zeros used for alignment could be mistaken for compressed content. With it, a decoder could stop at the specified point and disregard trailing padding. This was a framing fact inside the transformation.
It was not an integrity mechanism. An end marker did not bind the data to an author, prevent deliberate modification, identify the original datagram, or prove that the decoded bytes matched an application expectation. It described where the LZS code stream ended. Authentication and encryption belonged to other layers and other receipts.
RFC 2407 placed the LZS transform identifier in the historical IPsec domain of interpretation. That association often tempts later readers to treat compression as a security property. The documents did not do so. Choosing IPCOMP_LZS told peers which transform to apply in an IP Compression Association. It did not make LZS cryptographic.
Agreement did not require use on every datagram
The general IPComp specification supplied a second boundary. A compression association created a shared context for a transform, but each datagram still stood on its own. If the compressed payload plus the IPComp header was not smaller than the original payload, the sender had to transmit the original form and omit the IPComp header.
RFC 3173 later preserved that non-expansion principle when it replaced RFC 2393. The result is operationally important: an established LZS association can coexist with uncompressed packets. Seeing an ordinary packet does not prove negotiation failure. Seeing protocol 108 and an IPComp header does not prove successful decompression or useful savings.
RFC 2395 added no adaptive compressibility test inside LZS. The transform did not learn that a traffic class was hopeless and decide to stop trying. An implementation could apply local heuristics before invoking it, but that policy was not the algorithm. Capability, selection policy and observed result therefore remained different layers.
Ninety bytes was an observation, not a law
The RFC reported informal tests against the Calgary Corpus. Payloads below roughly 90 bytes could expand on average, so an implementation might choose not to attempt LZS below that size. The appendix also showed compression ratios rising with datagram size: about 1.18 at 64 bytes and 2.14 at 16,384 bytes for that corpus.
Those numbers explained a mechanism. Resetting at every packet denied small datagrams the longer history available to large ones. Fixed markers and headers also consumed a larger share of a short payload. More bytes within one boundary gave the sliding window more repetition to exploit.
But the table was not a universal performance contract. The Calgary Corpus was a named test collection. Encrypted bytes, already-compressed images, short binary control messages, adversarial inputs and another language distribution could behave differently. The RFC itself described the 90-byte point as approximate and the tests as informal.
RFC 2394 supplied a parallel DEFLATE profile and its own implementation context. RFC 3051 later explained why reset cost mattered when adapting another dictionary algorithm to independent IP datagrams. Neither document converted one corpus into a network constant. Algorithm, workload, packetization and implementation jointly determined the outcome.
A historical licence was part of the adoption surface
RFC 2395 also disclosed that Hi/fn held patents on LZS at the time and described no-cost reference licensing for named protocol uses plus other licensing options. The paragraph was not packet syntax, yet it belonged to the real adoption surface. Operators and implementers could evaluate a transform only by combining technical fit with the legal and supply conditions surrounding an implementation.
That statement must remain historical. It does not establish who owns a right today, whether a patent remains enforceable, whether a licence is still available, or what any current product may do. A 1998 RFC can prove what it reported in 1998. It cannot silently update a legal state decades later.
This is the wider lesson of the profile. The shared specification was thin: reset here, flush here, terminate here, use this transform identity. Local actors still decided whether the workload justified compression, which threshold to try, whether licensing and hardware were acceptable, and whether running results supported continued use.
Independence was purchased by refusing inherited state
The most important achievement was negative. A receiver did not need packet N to decode packet N+1. Loss remained loss rather than becoming a dictionary catastrophe. Reordering did not require the network to imitate a reliable stream. The compressor accepted less opportunity in order to keep the failure domain aligned with the datagram.
That bargain is easy to reverse accidentally. An implementation that carries history across packets may improve ratios in a clean benchmark while creating an undeclared recovery dependency. A dashboard that reports an agreed LZS transform may count packets that were correctly left uncompressed as failures. A performance report may repeat the 90-byte guidance without preserving its corpus, header cost and reset conditions.
RFC 2395's durable contribution is the discipline to keep these facts apart: the algorithm available, the memory lifetime imposed by the profile, the packet actually transformed, the stream correctly closed, the payload successfully recovered and the application outcome observed. None can issue the others' receipt.
Sources
- RFC 2395 — IP Payload Compression Using LZS
- RFC Editor record for RFC 2395
- IETF Datatracker history for RFC 2395
- RFC Editor errata for RFC 2395
- RFC 2393 — IP Payload Compression Protocol
- RFC 3173 — IP Payload Compression Protocol
- RFC 1967 — PPP LZS-DCP Compression Protocol
- RFC 1974 — PPP Stac LZS Compression Protocol
- RFC 2394 — IP Payload Compression Using DEFLATE
- RFC 2407 — Internet IP Security Domain of Interpretation for ISAKMP
- RFC 3051 — IP Payload Compression Using ITU-T V.44 Packet Method
- RFC 3819 — Advice for Internet Subnetwork Designers
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Heng Lu — Reality Layers, Symbolic Power, and Clarity
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
