Network Working Group Khiem Le
INTERNET-DRAFT Zhigang Liu
Date: 7 June 2001 Christopher Clanton
Expires: 7 December 2001 Ka Cheong Leung
Nokia Research Center
Requirements for Compression of Signaling Protocol Messages
<draft-le-sigcompr-requirements-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is an individual submission to the IETF ROHC WG.
Comments should be directed to its mailing list, rohc@cdt.luth.se.
Abstract
This document contains requirements for robust compression of
signaling protocol messages, such as SIP messages. It is intended to
be input material to the official working group requirements draft.
Le, Liu, Clanton, and Leung [Page i]
INTERNET-DRAFT Requirements for Compression 7 June 2001
Table of Contents
Status of This Memo . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2.1. Impact on Protocols and Internet Intrastructure . . . . . . 1
2.2. Coexistence with Other Schemes . . . . . . . . . . . . . . . 2
2.3. Robustness . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.4. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 3
2.5. Compression Efficiency . . . . . . . . . . . . . . . . . . . 4
3. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
Le, Liu, Clanton, and Leung [Page ii]
INTERNET-DRAFT Requirements for Compression 7 June 2001
1. Introduction
The following requirements are intended to guide the design and
specification of robust compression of signaling protocol messages,
such as SIP messages. Robust refers to resilience against message
loss, message corruption and message misordering between the
compressor and decompressor.
2. Requirements
2.1. Impact on Protocols and Internet Intrastructure
a) Transparency
When a message is compressed and then decompressed, the resulting
message must be bit-wise identical to the original message.
Justification: The compression/decompression process must not
alter the original protocol message because no assumption can be
made about the syntax and semantics of the protocol message.
Note: It is assumed that the compressed message is not subject to
undetected error(s). The issue of errors is dealt with by the
resilience against residual errors requirement (see section 2.3).
b) Ubiquity
Must not require modifications to the protocol being compressed.
In particular, must not assume any traffic pattern of the protocol
to be compressed.
Justification: Needed for genericity of the compression scheme.
c) Delay
The scheme must not contribute significantly to system delay
budget.
Justification: Needed for genericity of the compression scheme.
Le, Liu, Clanton, and Leung [Page 1]
INTERNET-DRAFT Requirements for Compression 7 June 2001
2.2. Coexistence with Other Schemes
a) Header Compression
Must be able to use the message compression scheme in conjunction
with any header compression schemes, in particular the ones
defined in ROHC.
Justification: Protocol compression is used because there is a
need to conserve bandwidth usage. In that case, header
compression will likely be needed too.
Note: This requirement does not necessarily imply that the
protocol message compression/decompression entity is co-located
with the header compression/decompression entity.
b) Encryption
Must be able to use the message compression scheme in conjunction
with message encryption schemes which can be end-to-end, and the
compression ratio must not be degraded when encryption is present.
Justification: There will likely be cases where both message
compression and message encryption are required.
Note: This requirement does not necessarily imply that the
protocol message compression/decompression entity is co-located
with the encryption entity.
2.3. Robustness
a) Resilience against message loss between compressor and
decompressor
When such message loss happens, the decompressor must still be
able to decompress correctly messages which are subsequently
received without errors.
Justification: A primary case of application is in cellular
systems, where the path between the compressor and decompressor
includes a cellular link. Message loss on the cellular link can
be non-negligible.
Note: It is assumed that the compressed message is not subject to
undetected error(s). The issue of errors is dealt with in the
Le, Liu, Clanton, and Leung [Page 2]
INTERNET-DRAFT Requirements for Compression 7 June 2001
next item.
b) Resilience against residual errors between compressor and
decompressor
The scheme must be resilient against errors undetected by the
lower layers, i.e. the probability of incorrect decompression
caused by such undetected errors is low. The probability should be
adjustable by a design parameter.
Justification: A primary case of application is in cellular
systems, where the path between the compressor and decompressor
includes a cellular link. Undetected errors can happen on the
cellular link.
c) Resilience against message misordering between compressor and
decompressor
The decompressor must still decompress correctly a message
delivered out-of-sequence. A maximum degree of misordering is
assumed, and the maximum degree of misordering that the scheme can
cope with should be adjustable by a design parameter.
Justification: The protocol can be carried over transport such as
UDP, which do not guarantee in-order delivery.
Note: It is assumed that the compressed message is not subject to
undetected error(s). See item b) above.
2.4. Scalability
a) Memory scalability
The scheme must be scalable to accommodate a range of
compressors/decompressors with varying storage capabilities. A
more capable compressor must be able to interoperate with a less
capable decompressor, and vice-versa.
Justification: A primary case of application is in cellular
systems, where one end of compression/decompression is at a mobile
terminal, likely with limited memory.
b) Processing scalability
The scheme must be scalable to accommodate a range of
compressors/decompressors with varying processing capabilities. A
Le, Liu, Clanton, and Leung [Page 3]
INTERNET-DRAFT Requirements for Compression 7 June 2001
more capable compressor must be able to interoperate with a less
capable decompressor, and vice-versa.
Justification: A primary case of application is in cellular
systems, where one end of compression/decompression is at a mobile
terminal, likely with limited processing power.
c) Compression scalability
The scheme should allow one to use additional mechanisms and/or
more advanced compression methods to boost the compression
efficiency, when permitted by memory and processing capabilities.
An example of such a mechanism is the pre-population and
downloading of the dictionary.
2.5. Compression Efficiency
a) Average ratio
Must provide highest compression ratio under the constraints that
the above requirements are met.
b) Compression efficiency should not be affected by handover, i.e.
compression ratio is the same as if handover had not occurred.
Justification: A primary case of application is in cellular
systems, where handovers are part of normal operation. One or
more handovers can happen during the life of a protocol session.
Le, Liu, Clanton, and Leung [Page 4]
INTERNET-DRAFT Requirements for Compression 7 June 2001
3. Authors' Addresses
Khiem Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4882
Fax: +1 972 894-4589
E-mail: khiem.le@nokia.com
Zhigang Liu
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-5935
Fax: +1 972 894-4589
E-mail: zhigang.liu@nokia.com
Christopher Clanton
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 894-4886
Fax: +1 972 894-4589
E-mail: christopher.clanton@nokia.com
Ka Cheong Leung
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Phone: +1 972 374-0630
Fax: +1 972 894-4589
E-mail: kacheong.leung@nokia.com
Le, Liu, Clanton, and Leung [Page 5]