Subject: RE: [Sipping] compression problems

From: Eric Burger <[email-masked]>
Date: Thu, 30 Dec 2004 18:23:38 -0500

This is exactly WHY lemonade is currently favoring the TLS w/ null cipher
(or, you can have your security, too :) approach.  We were looking at a ton
of ugly application-layer compression schemes, until we realized that we
could get the same or better results with TLS.

It is not a panacea for lemonade for exactly the reason TLS *is* a panacea
for SIP: in lemonade, one may be transmitting a LOT of pre-compressed data.
In that case, TLS gets you zero compression at the expense of CPU.  The
lemonade environment is a limited CPU environment, so that hurts.

In the SIP environment, virtually EVERYTHING is 7-bit ASCII text.  Yes, we
made a big effort to get people to realize that SIP is 8-bit binary, but the
reality is that MOST of the stuff people are shipping around is and will
remain a very small subset of the octet space.  TLS would get you a big
compression savings off the bat.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Monday, December 27, 2004 3:59 PM
> To: sipping
> Subject: [Sipping] compression problems
> 
> 
> 
> We seem to be doing a ton of weird things to SIP such as the recent
> even-throttle, events lists etc. all in the name of compression.
> 
> The issue is basically this, people want to put several SIP 
> messages that
> have a lot in common into one sip message for compression 
> reasons. Let's say
> all these messages have most of the header and body about the 
> same then a
> few parts change - it seems clear that they should not take much more
> bandwidth than one message plus the list of things that are 
> different in
> each message. 
> 
> I think we should go and solve this compression problem as a 
> root issue and
> then there would be less need for all kinds of weird things 
> that are being
> done in the name of compression. I think the end result would 
> work better
> and be easier to implement. One possible approach is just to run some
> approximation of arithmetic coding on the stream between and 
> edge proxy and
> UA - for example, TLS with compression negotiated would do 
> this. There are
> no doubt better approaches that take into account that SIP 
> can have encoding
> that is not bitwise exact and take into account structural 
> information and
> advanced context pool switches.
> 
> Let me make a clear example our of all this - I took the 
> example out of the
> lists URI draft with an INVITE with a list to invite three other
> participants - I call this message "mix" for when the list 
> plus the original
> requests were mixed together. Another way to do with would be 
> to send an
> INVITE to create the focus, then send 3 refers to the focus 
> to invite the
> other participants. I called these messages "inv", "ref1", 
> "ref2", "ref3",
> respectively. 
> 
> I don't have a sigcomp engine I can experiment with, but just 
> using gzip as
> something that will give a representative compression 
> approximation I get
> the compressed size of various messages as :
> 
> "mix"  644
> 
> independent compression of "inv+3ref" = 458 + 358 + 361 + 361 = 1538
> 
> compress of "all" 534
> 
> Note the key  factor here - putting what was simple for SIP INV plus 3
> refers though a standard compression scheme actually resulted 
> in better
> compression that the same compression scheme on list approach.
> 
> And both of these was way better than the in depended 
> compression approach
> which I think is more representative of how sigcomp works.
> 
> We have a bunch of drafts floating around that are motivated 
> by compression
> - and none of them discuss if they actually provide any compression or
> follow up with any results to show if they work one way or 
> anther. This is a
> silly way to design compression schemes.
> 
> Messages I used are attached. (and compressed in exactly the 
> wrong way)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 30 Dec 2004 17:56:53 -0600

Hi, Eric,

I happen to like the idea of compression using a 
lower-than-application-level compression mechanism, but doesn't 
relying on TLS-based compression overlook SIP-over-UDP (since TLS 
requires TCP, or something pretty close)?

Spencer

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Dec 2004 22:32:04 -0600

> requires TCP, or something pretty close)?

Well, there's DTLS, which runs over UDP...

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Dec 2004 22:38:09 -0600

Eric Burger wrote:

>for SIP...

Well, actually, it isn't. The place that compression is most needed is 
over wireless (i.e. cellular) data links. Unfortunately, the terminals 
involved aren't necessarily up to the task of running a compression 
algorithm as heavy as deflate (which, IIRC, is the only one currently 
registered for use with TLS). I've had real-world experience with such 
handsets running SIP. There are many much cheaper algorithms (I'll cite 
LZJH as an example -- compression takes about 1/6th the time as deflate, 
albeit with slightly larger messages as a result) that are perfectly 
appropriate for such low-end terminals.

So, for the time being, the approach that makes the most sense is the 
one that SigComp has taken: allow each implementation to determine what 
an appropriate level of complexity is for their operating environment.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 30 Dec 2004 22:58:31 -0600

From: "Adam Roach" <[email-masked]>
> Well, there's DTLS, which runs over UDP...

Adam,

Thanks for the pointer.

The ID tracker for draft-rescorla-dtls-02.txt shows it as Publication 
Requested with no IESG evaluation yet - have we heard anything else 
about its status?

Like I said - I like transport-level compression - so am trying not to 
read too much into an individual draft...

Spencer