RFC 2395

IP Payload Compression Using LZS

📅 published December 1998, from ietf

RFC 2395: IP Payload Compression Using LZS 🎀

okay bestie, RFC 2395 is called IP Payload Compression Using LZS 💖 It was written by Robert Friend and Robert Monsour, both from Hi/fn, Inc. It's labelled Informational, so it's giving "here's some info" energy, not an official Internet standard 🦋 It's dated December 1998. It doesn't say it obsoletes or updates any other document, so there's nothing listed there ✨

Status of This Memo 🌸

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract 🫶

This one describes a compression method based on the LZS compression algorithm. It defines how LZS gets applied to the IP Payload Compression Protocol [IPCOMP]. And [IPCOMP] is the one that defines a way to apply lossless compression to the payloads of Internet Protocol datagrams.

Table of Contents 🧚

   1. Introduction...................................................2
      1.1 General....................................................2
      1.2 Background of LZS Compression..............................2
      1.3 Licensing..................................................3
      1.4 Specification of Requirements..............................3
   2. Compression Process............................................3
      2.1 Compression History........................................3
      2.2 Compression Encoding Format................................3
      2.3 Padding....................................................4
   3. Decompression Process..........................................4
   4. IPComp Association (IPCA) Parameters...........................4
      4.1 ISAKMP Transform ID........................................5
      4.2 ISAKMP Security Association Attributes.....................5
      4.3 Manual configuration.......................................5
      4.4 Minimum packet size threshold..............................5
      4.5 Compressibility test.......................................5
   5. Security Considerations........................................5
   6. Acknowledgements...............................................5
   7. References.....................................................6
   8. Authors' Addresses.............................................7
   9. Appendix: Compression Efficiency versus Datagram Size..........8
   10. Full Copyright Statement......................................9

1. Introduction 🌈

1.1 General

This document is all about applying LZS compression, which is a lossless compression algorithm, to IP datagram payloads. You're meant to use it together with the IP Payload Compression Protocol [IPCOMP]. It also assumes you already have a really solid understanding of the IPComp protocol, so no pressure 💅

1.2 Background of LZS Compression

Okay so the story is that Hi/fn started with a sliding window compression history, similar to [LZ1], and then built a new, enhanced compression algorithm called LZS 🔥 LZS is a general purpose lossless compression algorithm that works on a wide variety of data types. Its encoding method is super efficient, and it can compress strings as short as two octets in length. Iconic.

LZS uses a sliding window of 2,048 bytes. When it compresses, redundant sequences of data get swapped out for tokens that stand in for those sequences. When it decompresses, the original sequences get put back in place of the tokens, so the original data comes back exactly. It's not like lossy algorithms, such as the ones often used for video compression, which don't reproduce the original data exactly 👑

The details of LZS compression can be found in [ANSI94] 📚

How well LZS does depends on how much redundancy the original data has. There's a table of compression ratios for the [Calgary] Corpus file set in the appendix in Section 7 🦋

1.3 Licensing

Hi/fn, Inc. holds patents on the LZS algorithm. Licences for a reference implementation are available for use in IPPCP, IPSec, TLS and PPP applications at no cost 💖 Source and object licences are available on a non-discriminatory basis. Hardware implementations are also available. If you want more info, contact Hi/fn at the address listed with the authors' addresses.

1.4 Specification of Requirements

Here's the key bit for requirement words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119] 🌸

2. Compression Process 💅

2.1 Compression History

The sender MUST reset the compression history prior to processing each datagram's payload. This makes sure each datagram's payload can be decompressed independently of any other, which is needed when datagrams arrive out of order 🙈

The sender MUST flush the compressor each time it transmits a compressed datagram. Flushing means all data going into the compressor gets included in the output, so no data is held back in the hope of getting better compression. Flushing is necessary to stop a datagram's data from spilling over into a later datagram ✨

2.2 Compression Encoding Format

The input to the payload compression algorithm is an IP datagram payload. The output is a new (and hopefully smaller) payload. The output payload holds the input payload's data in either compressed or uncompressed format. The input and output payloads are each an integral number of bytes in length 🍓

If the uncompressed form is used, the output payload is identical to the input payload and the IPComp header is omitted. If the compressed form is used, the output payload is prepended with the IPComp header and encoded as defined in [ANSI94], which is repeated here for informational purposes ONLY.

   <Compressed Stream> := [<Compressed String>] <End Marker>
   <Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
   <Raw Byte> := <b><b><b><b><b><b><b><b>          (8-bit byte)
   <Compressed Bytes> := <Offset> <Length>
   <Offset> := 1 <b><b><b><b><b><b><b> |           (7-bit offset)
               0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
   <End Marker> := 110000000

   <b> := 1 | 0

   <Length> :=
   00        = 2     1111 0110      = 14
   01        = 3     1111 0111      = 15
   10        = 4     1111 1000      = 16
   1100      = 5     1111 1001      = 17
   1101      = 6     1111 1010      = 18
   1110      = 7     1111 1011      = 19
   1111 0000 = 8     1111 1100      = 20
   1111 0001 = 9     1111 1101      = 21
   1111 0010 = 10    1111 1110      = 22
   1111 0011 = 11    1111 1111 0000 = 23
   1111 0100 = 12    1111 1111 0001 = 24
   1111 0101 = 13     ...

2.3 Padding

A datagram payload compressed using LZS always ends with the last compressed data byte (also known as the <end marker>), and that's what's used to tell padding apart. So trailing bits as well as bytes can be treated as padding 🧚

The size of a compressed payload MUST be in whole octet units.

3. Decompression Process ✨

If the received datagram is compressed, the receiver MUST reset the decompression history before processing the datagram. This makes sure each datagram can be decompressed independently of any other, which is needed when datagrams arrive out of order 🫶 After resetting the decompression history, the receiver decompresses the Payload Data field according to the encoding specified in section 3.2 of [ANSI94].

If the received datagram is not compressed, the receiver doesn't need to do any decompression processing, and the Payload Data field of the datagram is ready for the next protocol layer 🌈

4. IPComp Association (IPCA) Parameters 👑

ISAKMP MAY be used to negotiate the use of the LZS compression method to establish an IPCA, as defined in [IPCOMP] 🌈

4.1 ISAKMP Transform ID

The LZS Transform ID is IPCOMP_LZS, as specified in The Internet IP Security Domain of Interpretation [SECDOI]. This value is used to negotiate the LZS compression algorithm under the ISAKMP protocol 💖

4.2 ISAKMP Security Association Attributes

There are no other parameters required for LZS compression negotiated under ISAKMP 🎀

4.3 Manual configuration

The CPI value IPCOMP_LZS is used for manually configured IPComp Compression Associations 🍓

4.4 Minimum packet size threshold

As stated in [IPCOMP], small packets may not compress well. Informal tests using the LZS algorithm over the Calgary Corpus data set show that the average payload size that may produce expanded data is approximately 90 bytes. Thus implementations may not want to attempt to compress payloads smaller than 90 bytes 🙈

4.5 Compressibility test

There is no adaptive algorithm embodied in the LZS algorithm for compressibility testing, as referenced in [IPCOMP] 🦋

Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒

Okay, so the vibe here is "share it, but don't mess with it" 💅 You're totally allowed to copy and hand this document out to your friends, and you can translate it too. You can also make derivative works that comment on or explain it, or help people actually implement it, and you can prepare, copy, publish and distribute those in whole or in part with no restriction of any kind 🦋. The one big condition is that the above copyright notice and this paragraph have to be included on every single copy and every derivative work 🫶

The catch is that this document itself may not be modified in any way 🙅‍♀️ That means no removing the copyright notice, and no deleting the references to the Internet Society or other Internet organizations. The only exceptions are if you need it for developing Internet standards, in which case the copyright procedures defined in the Internet Standards process must be followed, or if you need to translate it into languages other than English 🌈

These permissions are perpetual, which is giving forever 💖 They will not be revoked by the Internet Society or its successors or assigns ✨

Here's the legal disclaimer, and it's serious 🥺 This document and the information contained in it is provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
📦 where this page comes from