Subject: [Sip] Encapsulating EPIC in UDPComp

From: "Price, Richard" <[email-masked]>
Date: Fri, 17 Aug 2001 16:58:23 +0100

Hi,

Attached is a (rather detailed) posting on the overhead of
encapsulating EPIC within UDPComp. The conclusion is that by adding
Huffman codes to UDPComp, the protocol overhead can be made very
low (just 5 bytes per message).

Comments are welcome!

Richard P

--------------------------------------------------------------------

This is a follow-up to my earlier posting on the performance of
various signaling compression algorithms. I mentioned that one of the
ideas of UDPComp is to make the compression algorithm a local
implementation decision at the compressor: this makes the protocol
very lightweight and flexible, but potentially reduces the compression
efficiency due to transmitting the semantics of the compression
algorithm in each packet.

As promised, here are some performance figures to illustrate this
overhead. We tested the EPIC algorithm encapsulated in UDPComp using
the "Simple SIP to SIP" flow from <draft-ietf-sip-call-flows-05.txt>.

We assume that the compressor and decompressor each contain a static
dictionary of text strings commonly used in SIP. This can be "learnt"
by compressing sufficient SIP messages, or alternatively can be fixed
a-priori. We also use a dynamic dictionary (i.e. compress relative to
previous messages in the flow).

Note that UDPComp offers significant flexibility in the choice of
"token" used to transmit text strings from the compressor to the
decompressor. Currently the scheme sends a fixed 1-2 byte index to
reference each text string, but additional tokens can easily be added
(for example tokens that use Huffman codes to reference text strings).
We have provided a range of performance figures using different types
of token to transmit the data.

For comparison, the compression ratio using only the existing UDPComp
tokens is given below:

EPIC algorithm with no encapsulation:                   9.78

UDPComp using existing tokens only:                     1.17

The decrease in compression ratio is caused by sending a 1-2 byte index
to reference each text string. In contrast, the EPIC algorithm usually
references a text string by sending a short Huffman code (typically
1 - 4 bits).

To improve the compression ratio it is possible to add Huffman codes to
UDPComp. In general this is straightforward: the only potential problem
is that the Huffman codes are chosen specifically for EPIC, and different
variants of Lempel-Ziv may need a different set of Huffman codes. Thus,
it may be necessary to download new sets of Huffman codes to the
decompressor depending on the choice of algorithm.

Adding Huffman codes to UDPComp can be done in several ways. Firstly
we have a choice between EPIC-LITE (which uses ordinary Huffman codes)
and EPIC (which uses a special version of Huffman encoding capable of
compressing text strings down to less than one bit - for example 3
common text strings in a row might together be indicated by sending a
single "0" bit).

Secondly, we have a choice between selecting a global set of Huffman
codes for all text strings, and using a different set for each dictionary
entry. In the latter case the Huffman code for each text string actually
changes depending on the previously received string. This improves the
compression ratio at a cost of higher memory requirements (which may be
a problem if we have to store the Huffman codes in working memory).

Compression ratios for each choice are given below:

UDPComp using EPIC-LITE with global Huffman codes:      5.90

UDPComp using EPIC-LITE with local Huffman codes:       6.29

UDPComp using EPIC with global Huffman codes:           6.85

UDPComp using EPIC with local Huffman codes:            8.24

Initial results are promising: if required we can make the overhead of
encapsulating EPIC within UDPComp negligible (essentially it is just
the 5 bytes of initial UDPComp header per message). I believe the next
step should be to check how other compression algorithms fit into the
UDPComp framework, and to decide on a "sweet spot" between compression
efficiency and standardizing the protocol in the given timeframe.

---

From: Jan Christoffersson <[email-masked]>
Date: Mon, 20 Aug 2001 15:31:47 +0200

Hi Richard,
I have a few comments to the performance figures when EPIC (or some other
compression algorithm) is encapsulated in UDPComp. As defined in the draft
UDPComp is unidirectional. This means that all messages from the "Simple SIP
to SIP" flow from <draft-ietf-sip-call-flows-05.txt> can't be used in the
dynamic dictionary, only previous messages sent in the same direction as the
current message. This would have significant impact on the performance
figures,  I believe.
Another thing which I think will have impact on the performance is the choice
of tokens. For example, the READ-token has nothing to do with dictionary/code
book management, it just says ''read from a certain place in the dictionary
and append this to the decompressed message''. But this is typically what the
references in  Lempel-Ziv compression algorithms mean. In practice this means
that we are using two tokens with the same meaning to read a string from the
dictionary, surely one token would be sufficient? I guess the there is room
for plenty of discussion on what types of tokens are needed to support both
the different compression algorithms that people would like to use and maybe
also to support the kind of dictionary/code book manipulations that are
desired.

Regards,
Jan Christoffersson

"Price, Richard" wrote:

>   ------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip