Subject: RE: [Sip] New I-D on compression of SIP

From: [email-masked]
Date: Wed, 25 Jul 2001 11:46:33 -0500

> Hmm. I guess I have to wonder whether the marginal
> difference is actually worth much over the base
> Huffman encoding and whatever you manage to eek
> out with the dictionary across packets. It does
> come at the expense of quite a bit of extra shared
> state. If you're sold on that, maybe it would be
> best of all to just standardize a SIP specific
> dictionary :-)

That is definitely one thing we need to investigate.
To summarize, we have three kinds of data that can
be used for compression:

1) static and protocol specific
2) user specific
3) dynamic

I'm not sure the difference between using 1) only
and using all of them is marginal. At least the 
user specific part can boost compression efficiency
significantly. 

Below are some results copied from Appendix A of SCRIBE-01. 

Scenario A: each message is compressed individually
Scenario B: 2) is used
Scenario C: 1) and 2) are used

==================================================================
     Table 1.  The Average Compression Ratio in Different Scenarios.

                  Scenario A,         Scenario B,         Scenario C,
               Compression Ratio   Compression Ratio   Compression Ratio
                   (Average)           (Average)           (Average)
------------------------------------------------------------------------
LZSS, 12-bit
position, 4-bit      1.31                4.19                4.51
match length

LZSS, 11-bit
position, 5-bit      1.33                4.87                5.27
match length

Linux GZIP
compression          1.47                6.23                6.37
=======================================================================

Br,
Zhigang

_______________________________________________
Sip mailing list  http://www.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

---

From: Michael Thomas <[email-masked]>
Date: Thu, 26 Jul 2001 07:28:23 -0700 (PDT)

Thanks for the numbers. What needs to be taken
into account also is the recidivism rate. Sharing
state with a first hop proxy is quite likely to
get good compression, while direct communication
with another UA is more likely to degrade into the
individually compressed case since there won't be
that much signaling, typically. Also: there's an
interesting question of dictionary/window
sizes. Gzip, as I recall, uses a 32k window to do
its magic, which is a pretty hefty amount of
memory. I'd be worried about both the UA if it
needed quite a few of these, as well as large
proxies which need to subtend 10-100's of
thousands of UA's. You could, I suppose, set the
window size down, but I'm sure the ratios are
non-linear.  Guestimating with the two points on
the graph given your numbers (always a dangerous
thing to do :-), the sweet spot is still likely to
be in the 8k range, or so which is still a fair
amount of state to be dragging around.

And as always, introduction of state always
reduces your flexibility since there's a higher
energy barrier to surmount when moving. This, of
course, runs afoul of load balancing schemes
which like statelessness generally. Given security
state considerations, they may already be on the
losing end, but it's worth noting the cost.

	    Mike