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

From: "Price, Richard" <[email-masked]>
Date: Wed, 25 Jul 2001 09:53:07 +0100

Interesting. Any idea what kind of compression ratio we need to aim for, so
that we know how complicated we need to make the solution?

Regards,

Richard P

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 3:47 AM
To: Jonathan Rosenberg
Cc: 'Michael Thomas'; [email-masked]'; [email-masked]'
Subject: [rohc] RE: [Sip] New I-D on compression of SIP

Jonathan Rosenberg writes:
 > I believe that the IPSec compression mechanisms apply to each packet
 > independently. That is, there is no carryover of compression context from
 > one IP packet to the next. The problem is that a single SIP message only
 > compresses a little (maybe 2:1), but when you take advantage of previous
 > messages to build a compression context, it can be much, much bigger. Thats
 > the idea behind my draft, and also the others in the ROHC group - ROGER,
 > SCRIBE. So, I don't see them as solving the same problem.

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 :-)

Not that this actually has much to do with
original point...

		Mike
---
Mailing list for Robust Header Compression WG
Archive: http://www.cdt.luth.se/rohc/

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 25 Jul 2001 09:38:27 -0500

We can derive targets from an understanding of the constraints.

Assume a 9.6kbps single-channel GPRS link.

Assume that approximately 5kbps of that is used by a half-rate AMR
(Alternative Minimum Rate) codec. That gives us roughly 4.6kbps available
for processing signaling, such as a re-INVITE, BYE, or new INVITE arriving.

If we have a 1000-byte (8000 bit) messgae over that link, it takes just
under TWO SECONDS (8000/4600) to serialize. That's clearly too long, given
that there might be three messages (or more, with "manyfolks" QoS)  involved
in a call setup.

I haven't seen  a hard design goal for wireless, but I'd guess that a
transaction time of less than 1.5s would be a minimal goal. That means we
need to serialize in less than 500ms. This sets a target compressed message
size of (X/4600)=0.5, or 2300 bits, call it 250 bytes.

In wireline environments, I've seen goals as low as 100ms for three-message
setup. To reach that over GPRS in the above scenario, we'd need to shrink
average message size to  (X/4600)=0.035,  or about 20 bytes. Oddly enough,
this would be roughly equivalent to current GSM signaling.

SIP INVITES  in the Call Flows draft run from 300 to 600 bytes. I doubt
they're representative of real uses, especially with all the additional
stuff people want to put into signaling (cookies, state, cell-IDs,
auth-tokens, blah blah blah).

The three syntactic dictionary transforms (ROGER, SCRIBE, and Rosenburg)
we've seen published are getting on the order of 6 or 8 to 1 compressions,
so they're producing INVITES in the 50 byte range, probably approaching 100
bytes with "real world" messages. This might be good enough for general use.

The best work I've seen so far with LZ-based algorithms  provides roughly
3-1 compression, which might possibly be good enough if one is very terse
with one's messages.

--
Dean

----- Original Message -----
From: "Price, Richard" <[email-masked]>
To: "'Michael Thomas'" <[email-masked]>; "Jonathan Rosenberg"
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 25, 2001 3:53 AM
Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP

> Archive: http://www.cdt.luth.se/rohc/

_______________________________________________
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