RFC 3051

IP Payload Compression Using ITU-T V.44 Packet Method

📅 published January 2001, from ietf

IP Payload Compression Using ITU-T V.44 Packet Method 🎀

Okay bestie, so this one is RFC 3051 and it's all about squeezing IP payloads with V.44 💅 It came out in January 2001 from the Network Working Group, written by J. Heath and J. Border of Hughes Network Systems ✨ It's labelled Informational, which means it's here to inform the Internet community and does not specify an Internet standard of any kind 🫶 The header doesn't list anything it obsoletes or updates, so no drama there 🌸

Status of this Memo 📜

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

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

Abstract 🦋

So this doc describes a compression method based on the data compression algorithm from International Telecommunication Union (ITU-T) Recommendation V.44 🌈 V.44 is a modem standard, but Annex B, Clause B.1, of the recommendation describes how V.44 gets implemented in packet networks (that's the V.44 Packet Method) 💜 This document defines how the V.44 Packet Method gets applied to the Internet Protocol (IP) Payload Compression Protocol (RFC 2393). RFC 2393 defines a way to apply lossless compression to the payload portion of IP datagrams ✨

The V.44 Packet Method is based on the LZJH data compression algorithm. For the rest of the document, V.44 Packet Method and LZJH mean the exact same thing 👑

Table of Contents 🧚

    1. Introduction...................................................2
       1.1 General....................................................2
       1.2 Background of LZJH Data Compression........................2
       1.3 Intellectual Property Rights...............................3
       1.4 Specification of Requirements..............................4
    2. Compression Process............................................4
       2.1 Encoder Dictionary.........................................4
       2.2 Encoder Output.............................................4
       2.3 Padding....................................................4
    3. Decompression Process..........................................5
       3.1 Compressed Datagram........................................5
       3.2 Original Uncompressed Datagram.............................5
    4. IPComp Association (IPCA) Parameters...........................5
       4.1 Transform ID...............................................5
       4.2 Security Association Attributes............................5
       4.3 Manual configuration.......................................5
       4.4 Minimum packet size threshold..............................6
       4.5 Compressibility test.......................................6
    5. Security Considerations........................................6
    6. IANA Considerations............................................6
    7. Acknowledgements...............................................6
    8. References.....................................................6
    9. Authors' Addresses.............................................7
   10. Full Copyright Statement.......................................8

1. Introduction ✨

1.1 General

Okay so this doc specifies how LZJH data compression gets applied to IP datagram payloads 💖 LZJH is a lossless data compression algorithm, and it's meant to be used together with the IP Payload Compression Protocol (IPComp) [RFC2393] 🫶 The whole doc assumes you already understand IPComp, so bestie, go brush up on that first 🍓

1.2 Background of LZJH Data Compression

LZJH is similar to the algorithm described in [LZ78], but it also has aspects that are similar to the algorithm described in [LZ77] 🔥 So basically it gets the execution speed and low memory requirements of [LZ78] with compression ratios that are better than [LZ77] 😭 It was originally developed for the satellite industry to compress IP datagrams independently, which makes it ideal for IPComp 🛰️ The LZJH algorithm was then modified to compress a continuous stream of data for a modem environment, and that modified version is the basis for Recommendation V.44 💅 LZJH is an adaptive, general purpose, lossless data compression algorithm 🌸 The ITU-T picked it as the basis for V.44 because it performs well across a wide variety of data types, especially web HTML's, and because of its compression ratio characteristics, per MIP and memory utilized (compared to other candidate algorithms) 👑 Its encoder is extremely efficient and can encode a two character string with 3 bits the second time that string is encountered in the data 🤯

A typical [LZ78] compression algorithm, such as V.42bis, is not suitable for IPComp because it takes too long to build up its dictionary 🙈 That results in poor compression ratios on IP datagrams that get compressed independently 😬 It also needs too many cycles to reset an [LZ78] dictionary between datagrams, which hurts execution times 💀

A typical [LZ77] compression algorithm also struggles in IPComp because of poor execution times 😩 Hash tables help execution times when you're compressing continuous data, but they may cause execution times to deteriorate in an IPComp application, since they have to be reset to an initial state between each datagram 🌧️

LZJH not only has superior execution times when encoding or decoding packet data, but also resetting its dictionary between IP datagrams is trivial 🧚 The encoder only needs to initialize a 256 word array and a handful of variables, and the decoder only needs to initialize a handful of variables 🫶

The LZJH algorithm uses a dictionary of 1525 entries, which is only 16K of dictionary memory for the IPComp application ✨ During encoding, unmatched characters are encoded as ordinals, and matched redundant strings of characters are encoded as codewords or string-extension lengths that represent those redundant strings 🦋 During decoding, the ordinals, codewords, and string-extension lengths get interpreted to re-create the original datagram payload exactly 💜

The details of LZJH data compression can be found in [V44] 📖

1.3 Intellectual Property Rights

The IETF has been notified of intellectual property rights claimed in regard to some or all of the specifications in this document 🎀 For more information, check the online list of claimed rights ⭐

1.4 Specification of Requirements

Okay this part is important, so pay attention 👀 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 [RFC2119] 🔥

2. Compression Process 💅

The compression of datagrams is performed by a function called the Encoder 🌈

2.1 Encoder Dictionary

The transmitting entity MUST reset the encoder dictionary prior to processing each datagram's payload, as specified in clause 7.5.1 of [V44] 🧹 This makes sure each datagram's payload can be correctly decompressed on its own, which is needed in an environment where datagrams may be lost or received out of order 🫶

The transmitting entity MUST flush unprocessed encoder data after the last byte of the datagram has been passed into the encoder, so the compressed datagram can be transmitted as a unit 🎁 The flush makes sure all data is processed and included in the output. In other words, the compressed datagram is complete, and no data from the current datagram gets processed along with the next datagram 🙌

2.2 Encoder Output

The input to the payload compression algorithm is an IP datagram payload 📦 The output is a new (and hopefully smaller) payload 🤞 The output payload contains 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 gets the IPComp header prepended and is encoded as defined in clause 6.3 of [V44] 💖

2.3 Padding

A datagram payload compressed using LZJH always ends with a FLUSH codeword in the last one or two compressed data bytes 🏁 The FLUSH codeword may start in the 2nd to the last compressed data byte and end in the last compressed data byte, or it may be totally within the last data byte 🌙 The FLUSH codeword is used to signal the end of the compressed data and to tell compressed data apart from padding 🔍 Any bits or bytes beyond the FLUSH codeword within the compressed payload are to be considered padding 🫧

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

3. Decompression Process 🌸

The decompression of datagrams is performed by a function called the Decoder 🧠

3.1 Compressed Datagram

If the received datagram is compressed, the receiver MUST reset the decoder dictionary prior to processing the datagram 🧼 This makes sure each datagram can be decoded on its own, even if datagrams get lost or arrive out of order 🌊 Starting with the decoder dictionary in the initial state, as specified in clause 7.5.2 of [V44], the receiver decodes the payload data field of the datagram according to the procedure specified in clause 6.4 of [V44] 💜

3.2 Original Uncompressed Datagram

If the received datagram is not compressed, the receiver doesn't do any compression decoding. It just passes the payload data field of the datagram, unaltered, up to the next protocol layer 🫶

8. References ✨

Okay bestie, here's every source this doc leans on 📚

  • [LZ77] Lempel, A., and Ziv, J., "A Universal Algorithm for Sequential Data Compression", IEEE Transactions On Information Theory, Vol. IT-23, No. 3, May 1977. 🧠
  • [LZ78] Lempel, A., and Ziv, J., "Compression of Individual Sequences via Variable Rate Coding", IEEE Transactions On Information Theory, Vol. IT-24, No. 5, Sep 1978. 💅
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 👑
  • [RFC2393] Shacham, A., "IP Payload Compression Protocol (IPComp)", RFC 2393, December 1998. 🦋
  • [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998. 🌸
  • [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November, 1998. 🔐
  • [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange", RFC 2409, November 1998. 🗝️
  • [V44] ITU Telecommunication Standardization Sector (ITU-T) Recommendation V.44 "Data Compression Procedures", November 2000. 🎀

9. Authors' Addresses ✨

Here's where to find the two people who wrote this, iykyk 🙈

Jeff Heath
Hughes Network Systems
10450 Pacific Center Ct.
San Diego, CA  92121

Phone: 858-452-4826
Fax:   858-597-8979
EMail: jheath@hns.com


John Border
Hughes Network Systems
11717 Exploration Lane
Germantown, MD  20876

Phone: 301-601-4099
Fax:   301-601-4275
EMail: border@hns.com

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

Okay, the legal bit, but make it cute 🎀 Anyone can copy and share this document and translations of it, and make derivative works that comment on or explain it or help with implementing it. Those can be published and distributed, in whole or in part, with no restrictions of any kind, as long as the above copyright notice and this paragraph are on every copy and derivative work. The document itself, though, can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed to develop Internet standards (then the procedures for copyrights in the Internet Standards process must be followed) or when it's translated into languages other than English. 🌈

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns. Forever and ever, no take-backs 💜

Also, this document and the information in it is provided "AS IS", 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. No guarantees from the organizers, zero drama 🫠

Acknowledgement 🙏

Big thank-you energy to whoever keeps the lights on for this whole operation ✨ Funding for the RFC Editor function is currently provided by the Internet Society. 🫶

📦 where this page comes from