Download History of Data Compression

Telecommunications Industry Association
(TIA)
TR-30.1/00-03-22
Newport Beach, CA Nov 22, 2000
COMMITTEE CONTRIBUTION
Technical Committee TR-30 Meetings
SOURCE:
Hughes Network Systems
CONTACT:
Jeff Heath
Hughes Network Systems
10450 Pacific Center Court
San Diego, CA 92121
Phone:
(619) 452-4826
Fax:
(619) 597-8979
E-mail:
[email protected]
TITLE:
Proposal for V.44 Operation in Packet Networks
PROJECT:
PN-xxxx
DISTRIBUTION:
Members of TR-30 and TR-30.1 and meeting attendees
ABSTRACT
This paper presents the options available for V.44 operation in Frame Relay, IP packet networks,
and general packet networks.
Copyright Statement
The contributor grants a free, irrevocable license to the Telecommunications Industry Association
(TIA) to incorporate text contained in this contribution and any modifications thereof in the creation
of a TIA standards publication; to copyright in TIA's name any TIA standards publication even
though it may include portions of this contribution; and at TIA's sole discretion to permit others to
reproduce in whole or in part the resulting TIA standards publication.
Intellectual Property Statement
The individual preparing this contribution knows of patents, the use of which may be essential to a
standard resulting in whole or in part from this contribution.
1.
Introduction and Background
It has been agreed that the proposed V.44 Recommendation for data compression includes the
preferred method for operation in Frame Relay and/or packet networks. It is assumed that this
operation differs from the primary operation of V.44 in modems using V.42 error correction
procedures. The primary reason for a difference in the operation of V.44 in Frame Relay, packet
networks, etc. is that, unlike modems, the network device or terminal has knowledge of packet
and/or frame boundaries. Thus, instead of processing a continuous stream of unframed data, a
network terminal is capable of identifying and processing a complete Frame Relay frame, IP
packet, Network Protocol Data Unit (N-PDU), or similar block of protocol data.
Throughout the remainder of this proposal the term “packet network” is used to describe any
network that handles frames, packets, blocks, IP packets, N-PDU’s, etc. The term “packet” is
used to describe a frame, packet, IP packet, N-PDU, etc. The term “segment” is used to describe
a portion of a packet that is segmented for transmission over a link whose maximum block size is
less than the maximum packet size.
2.
Modes of Operation
In packet networks there is two basic modes of operation over data links; acknowledged mode
and unacknowledged mode. These modes of operation are quite different which may require that
V.44 operate differently while processing similar packet types.
Within these two basic modes of operation there are also modes of operation for data
compression that the designer of a packet network may or may not want to incorporate into V.44
operation.
2.1.
Acknowledged Mode
Acknowledged mode is similar to modem operation using V.42 error correction procedures in that
packets are partitioned, as necessary, into segments that are transmitted to the peer over a
reliable link and acknowledged by the peer. If the peer does not correctly receive a segment, it is
re-transmitted by the transmitting device. The only difference is that, in modem operation, data is
partitioned into V.42 segments without any regard for packet framing. Conversely, in packet
networks, the segment is typically a whole packet or a segment of a packet received by the
network. LAPM, TCP, and PPP are protocols that operate in acknowledge mode.
2.2.
Unacknowledged Mode
Unacknowledged mode does not provide any retransmission of data. A device transmits a
segment to another device without any feedback or acknowledgement from the receiver that the
segment arrived successfully. Typically there is a mechanism that insures that the receiver has
correctly received all segments of a packet. If one or more segments of a packet is lost, the
receiver discards the packet. A link that operates in unacknowledged mode typically relies upon
the higher layer protocol (i.e. TCP) to recover from lost packets. Frame Relay and UDP operate
in unacknowledged mode. The SNDCP layer of GSM GPRS has an option to use
unacknowledged mode.
2.3.
Transparent Data Mode
Transparent Data Mode within V.44 during modem operation is essential since the modem
processes a constant stream of data that sometimes expands during compression. However,
Transparent Data Mode is not necessary in packet networks where a packet that has been
compressed can be transmitted in its original form if the compression resulted in expansion of the
packet.
2.4.
Packet (Frame) Mode
Packet Mode is the compression of one packet at a time where both the encoder and decoder reinitialized the dictionary in between packets. In this mode, each packet can be correctly decoded
even if some packets are lost on the link. Packet Mode must be used in a packet network for
packets transmitted using Unacknowledged Mode. For various reasons, a network designer may
also want to use Packet Mode even for packets transmitted using Acknowledged Mode. One
such reason is that LZJH does not require a history buffer for packet mode. Another is that it is
easier to handle multiple instances of Acknowledged Mode streams using Packet Mode since
dictionaries and history buffers do not need to be maintained for each instance. The latter is very
important for hubs or satellite server nodes that must serve hundreds or thousands of terminals
(i.e. a GSM SGSN serving GPRS mobile stations).
3.
Data Compression in Packet Networks
As mentioned earlier, operation in packet networks differs from operation between modems
primarily because the packet network device that does data compression can identify complete
packets and packet boundaries. In fact networks that process IP packets are able to identify the
IP packet header and often use VJ IP Header Compression on the header and data compression
on the data portion of the packet. Important features of data compression in packet networks are:
 Negotiation of data compression algorithm and/or data compression parameters
takes place prior to data transfer within a protocol layer above data compression, i.e.
the link layer.
 Packets are compressed and transmitted as a unit. Thus a “FLUSH” is performed
after the last data byte of the packet is passed into the data compression encoder to
complete the compression such that the compressed packet can be transmitted at
one time.
 If operating in Unacknowledged Mode the data compression encoder and decoder
both reset the dictionary between packets (i.e. Packet Mode).
 Typically a bit or other indication in the packet header is used to indicate if the packet
is compressed or not. Thus, if the data expands beyond the boundaries of the packet
during compression, the original data can be transmitted instead of the larger
compressed data.
 Packet networks utilizing a bit to indicate if compression is successful may not want to
implement a Transparent Data Mode.
The operational options for data compression in packet networks can be summarized as follows:
 Acknowledged mode vs unacknowledged mode.
 Support of data expansion.
 Support of Transparent Data Mode.
 Support of packet mode for acknowledged mode data.
Some networks support multiple options, GSM GPRS supports both acknowledged and
unacknowledged mode within the same SNDCP link depending upon the type of Network Packet
Data Unit being transmitted.
4.
Proposed V.44 Operation in Packet Networks
Since there are several possible operational modes for packet networks it is proposed that
additional negotiable parameters be provided in V.44 to make it applicable to the various packet
networks. Negotiable parameters for packet networks are:
 Transparent Data Mode (disabled/enabled). Allows the data compression peers to not
provide support for transparent data. A network that provides a bit in the link header to
indicate if the data portion of the packet is compressed or not may choose not to support
transparent data. The network could, however, support the proposed negotiation of data


compression parameters in Transparent Mode between the compression peers. Note that
this parameter determines capability only, the encoder function could decide never to enter
Transparent Data Mode even if both peers have the capability.
Packet Mode (enabled/disabled). The support of multiple packets as a stream of data
requires each V.44 data compression peer to have a history buffer of a negotiated size. A
history buffer is not required when compressing one packet at a time and re-initializing the
dictionary between each packet. This parameter allows V.44 peers to compress one packet at
a time even when operating in Acknowledgement Mode. V.44 peers operating in
Unacknowledged Mode must compress one packet at a time.
Data Offset (value 0 – 255). Indicates where the compressed data starts in the packet. This
allows the data compression function to bypass the IP Header, etc. and start data
compression at a fixed location within each packet.
In addition to the above parameters unique to packet networks it is proposed that the maximum
string length parameter be hard coded to 255 and not negotiated. The maximum string length
places no memory or CPU burden on either the LZJH encoder or decoder and since there are no
delay issues with packet based compression the string length should be 255 for best performance
in packet networks.