Subject: [Sip] RE: [rohc] Reduced processing overhead for SIP compression

From: "Price, Richard" <[email-masked]>
Date: Tue, 14 Aug 2001 15:05:48 +0100

Hi,

I raised this issue to allay concerns that SIP compression
would be a significant resource drain on the proxy. If we
choose this implementation strategy then compression has no
processing overhead at all.

Only requirement on the standard is that it should be lightweight
enough not to preclude this implementation strategy!

Regards,

Richard P

-----Original Message-----
From: Dr. Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 2:15 PM
To: Price, Richard; [email-masked]; [email-masked]
Cc: 'Jonathan Rosenberg'
Subject: RE: [rohc] Reduced processing overhead for SIP compression

> Now that the ROHC WG is looking at SIP compression between the
> mobile and the proxy,

Just as a careful wording reminder:
We aren't officially chartered yet to do this.
The WG chairs have seen some "general hallway nods" (can I patent this
term?) from the ADs, but until the charter is written, they can't say "yes".
This shouldn't stop us all from working on this, of course.

> If we are performing compression
> in the mobile and the SIP proxy then we can miss out the text
> phase altogether

This is an implementation strategy question, not a question about the
interoperability of the standard (or do you think it is a
requirement/nice-to-have on the standard to allow this implementation
strategy?).
The strategy may make sense depending on a lot of factors, including
make-or-buy decisions on the SIP stack.

Gruesse, Carsten

---

From: Lawrence Conroy <[email-masked]>
Date: Tue, 14 Aug 2001 15:27:03 +0100

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

To which I reply,
   (In the hypothetical case that SIP/Whatever Compression is chartered
    in time to be used for GERAN R5:)
Yup; It *is* an implementation issue. However, if someone can buy
in a stack (or develop one) that reduces the compression processing
requirements a lot, then this is going to be favourably received
by mobile phone manufacturers.

As Carsten points out, it is a "nice-to-have" to allow this
implementation option, and I'd be uncomfortable losing it.

The protocol and compression scheme will work regardless of
implementation option chosen, but it may calm some unhappy
people if we don't add a new feature requiring X Mips to
implement (for a change, they tell me :).

BR,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

_______________________________________________
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

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 14 Aug 2001 16:59:51 +0100

Hi,

Yes, this is still compression because the output of a combined SIP
stack/SIP compressor is identical to the output of a standalone
compressor. Key difference between this and making SIP binary is that
the Huffman binary codes are made up by the compressor and do not
need to be standardized by the SIP WG: thus we avoid all of the
problems synchronizing between the text and binary encodings for SIP.

Regards,

Richard P

-----Original Message-----
From: Hans Hannu [mailto:[email-masked]]
Sent: Tuesday, August 14, 2001 3:38 PM
To: Price, Richard; [email-masked]; [email-masked]
Cc: 'Jonathan Rosenberg'
Subject: RE: [rohc] Reduced processing overhead for SIP compression

> A "SIP-aware" compression algorithm such as EPIC performs the
> compression by parsing a SIP message, converting text strings
> to their Huffman equivalents. If we are performing compression
> phase altogether, writing a SIP stack capable of reading and
> outputting Huffman characters directly.

Is this really compression anymore? To be it sounds like making SIP binary.

/Hans H

> 
> Motivation for combining the SIP compressor with the SIP stack
> is that the processing overhead of compression is negligible,
> or perhaps even negative (as Huffman characters are shorter
> than their text equivalents, so there is less to read/output).
> 
> Comments on this suggestion would be appreciated, particularly
> to check that it fits with the "protocol shim" for carrying
> compressed SIP messages as proposed by Jonathan Rosenberg.
> 
> Regards,
> 
> Richard P
> 
> --------------------------------------------------------------
> -----------
> Richard Price
> Internet Applications & Mobility
> Roke Manor Research Ltd.
> Old Salisbury Lane
> Romsey, Hants
> SO51 0ZN, UK.
> Telephone: +44 1794 833681
> E-mail: [email-masked]
> --------------------------------------------------------------
> -----------
>