Subject: [Sipping] compression problems

From: Cullen Jennings <[email-masked]>
Date: Mon, 27 Dec 2004 13:59:03 -0700

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