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

From: [email-masked]
Date: Thu, 19 Jul 2001 14:28:09 -0500

> The draft talks about the encoder that learns "in some way" that the 
> message was received at the other end. Magic I can think of 
> here would either look very much like an (implicit) acknowledgement 
> mechanism, where the decoder and encoder on one side of the link
communicate 
> to confirm  message reception. Alternatively, message confirmation
might 
> depend on  direct signalling from the application layer to the 
> compression layer. However, since the SIP layer is not aware of the
encoder, I 
> don't think that's a valid approach. I'd be interested to how this is 
> perceived to work.

Or explicit acknowledgement, which can be either stand-lone or
piggybacked on the compressed message from the other direction.
This makes the compression layer independent of the upper layer
(e.g. SIP in this case). Of course, if there is some interface
between SIP and compression layer, we should not exclude the
use of such interface.
 
> By the way, I am not so much concerned with the pathological 
> case you've given above. If lower layers are dropping *all* 
> requests, a non-updated codebook is probably not my main worry. 
> But I'd agree that in the case of deteriorating network behavior, 
> e.g. ramping up towards an overload situation, non-updated 
> codebooks are going to worsen the problem.

This problem can be alleviated by the static and user-specific 
dictionary or codebook (see 
http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-00.txt,
a newer version has been submitted to ROHC WG and should appear
soon). That also allows good compression efficiency for the
first few messages in a session.

Br,
Zhigang

> Romeo
> 
> ---
> Mailing list for Robust Header Compression WG
> 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

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 20 Jul 2001 13:21:15 +0100

Hi,

We chose the "Successful Simple SIP to SIP" call flow from
Section 3.1.1 of <draft-ietf-sip-call-flows-05.txt> to
benchmark our own SIP compression scheme.

Initially the "dictionary" of previously received messages
is empty, but new messages can be compressed relative to all
previously received messages. This illustrates nicely how the
compression ratio goes up with a more comprehensive dictionary.

The results for our scheme are as follows:

Message Size	Compressed Size		Compression Ratio

	423			152				2.78
	189			6				31.50
	205			16				12.81
	420			28				15.00
	195			4				48.75
	214			8				26.75
	198			2				99.00

If anyone has an alternative set of SIP messages, we could provide
compression ratios for these also.

Regards,

Richard P

-----Original Message-----
From: Dr. Carsten Bormann [mailto:[email-masked]]
Sent: Friday, July 20, 2001 12:45 PM
To: Romeo Zwart; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP

> The version -00 SCRIBE draft does not show any examples or
> compression ratio assessments. Both the SIP compression draft
> and the ROGER draft have some very rough and hard to compare
> examples. Is there a draft that shows assessments of the
> achievable compression results with SCRIBE?

I have asked Hans Hannu to make his benchmarks available to the WG -- or if
anybody else has some, having them available would help.

Gruesse, Carsten

---

---

From: [email-masked]
Date: Fri, 20 Jul 2001 09:46:48 -0500

> From: ext Romeo Zwart [mailto:[email-masked]]
> The 3-way SCRIBE acknowledgement seems rather elaborate for 
> what it needs to do. The ROGER draft section 5.6 shows that 
> at least the third leg of the acknowledgement can be done
> implicitly too.

The 3-way acknowledgement is needed to handle message loss,
misordering, and concurrent updates initiated by both CD
entities (this is not an issue in "split mode", but an issue
in "shared mode"). SCRIBE-01 has some more detail on this.
(It was submitted on July 18, probably still in the queue.
I'll post it somewhere and let you know the URL.)

I haven't read the new ROGER draft. I'll check what you pointed
out.
 
> >Of course, if there is some interface
> My understanding of the SIP compression draft is that the
> interface is left unspecified. However, defining an internal
> mechanism to allow the application layer to keep track of the
> messages sent at the compression layer seems more complex than
> defining a simple acknowledgement scheme.  

I agree. As you can see, I favor an explicit independent acknowledgement
at compression layer. But to be fair, I can see that some application
may determine what message has been received by its peer (e.g. due to
request-response nature) and inform this to compression layer. However,
I think acknowledgement at compression layer is cleaner and better,
and should be the base of anything else.

> I agree a partially static/profile dependent dictionary would 
> be expected to show better results for the initial messages in 
> a series of messages. In the case of mid-session network 
> deterioration, a dynamic mechanism would add some additional 
> overhead trying to update the codebook, whereas a static 
> mechanism obviously would not, but I don't think that this 
> would push the overall scale to favour static dictionaries.

That is still an open question to me. What I can say now is
that it depends (e.g. what protocol is compressed, compressor
and decompressor's capability, how complex we want to go).
Static/profile can be the basic mechanism, then dynamic 
update can further boost the compression performance. 
We should have a flexible framework to adapt the needs. More
details can be find in SCRIBE-01.

> achievable compression results with SCRIBE? 

You will find performance data in SCRIBE-01.

Br,
Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Fri, 20 Jul 2001 16:51:23 +0100

Hi,

A nice property of "learning" EPIC is that we can always compress
any message, but the compression ratio is proportional to how much
we know about the message structure. If we know nothing at all about
the message structure then the scheme behaves in an identical manner
to conventional Lempel-Ziv (LZ-78).

This means that we can program the scheme for SIP compression and
obtain a very high compression ratio (double Lempel-Ziv) but we can
still compress all future extensions. The compression ratio will
gradually degrade until the programming is completely out-of-date,
in which case we are back to Lempel-Ziv.

Processing and memory requirements behave in the same manner: if EPIC
has complete knowledge of SIP then the working memory requirements are
extremely low (sub 100 bytes) since it discards all previously received
data except useful strings such as URLs. Memory requirements increase as
the knowledge of SIP degrades, since EPIC must store more in the dictionary
to ensure a good compression ratio.

I hope this alleviates your concern!

Best regards,

Richard P

-----Original Message-----
From: Romeo Zwart [mailto:[email-masked]]
Sent: Friday, July 20, 2001 4:03 PM
To: Price, Richard
Cc: [email-masked]'; [email-masked]'
Subject: RE: [Sip] RE: [rohc] New I-D on compression of SIP

Richard,

I think your draft is already in the IETF repository. I've glanced
over it just now, so maybe I missed some of the fine print, but
here's one comment.

The compression results of your protocol seem impresssive. However,
an immediate drawback of using a 'programmed' protocol like this,
is that this is a rather inflexible approach. E.g. compression
of new extensions popping up will not be supported until new
versions of the en/decoders have been distributed to all involved
nodes (network and endpoints). I think that is a practical problem
in many scenarios.

Romeo

At 03:55 PM 7/20/2001, Price, Richard wrote:
>Hi,
>
>Apologies to members of the SIP mailing list who haven't received
>my previous emails on the subject. The scheme in question is
>EPIC (Efficient Protocol-Independent Compression) which is a
>programmable compression scheme with a very high level of efficiency.
>
>There is also a "learning" version of EPIC that does not need to be
>programmed - we used this to obtain the results for SIP compression.
>
>The new EPIC draft is being published today - we will post a copy on
>our website and provide the link shortly.
>
>Regards,
>
>Richard P
>
>From: Romeo Zwart [mailto:[email-masked]]
>Sent: Friday, July 20, 2001 2:11 PM
>To: Price, Richard
>Hi Richard,
>Thanks for this info, results look impressive. I am a bit confused
>when you say "our own SIP compression scheme". So that's not SCRIBE
>or ROGER, is it? Has that scheme been documented anywhere?
>
>Romeo
>
>
>At 02:21 PM 7/20/2001, you wrote:
> >Hi,
> >

---

From: [email-masked]
Date: Fri, 20 Jul 2001 11:29:53 -0500

Hello,

Before SCRIBE-01 shows up in the IETF repository, you can
pick it up at
http://people.nokia.net/~patil/draft-liu-rohc-scribe-01.txt.

Some preliminary performance results can be found in Appendix A.
Only static/profile dictionary was used (no dynamic dictionary
update). 

Note that the draft focuses on a framework with necessary mechanisms 
to synchronize data used by compression/decompression (CD data). The 
framework is flexible to cover different synchronization scenarios 
with different complexity (and compression efficiency). Different 
compression algorithms can run on top of the synchronization 
chassis.

Your comments are welcome.

Br,
Zhigang

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Mon, 23 Jul 2001 09:19:38 +0100

There is a requirement to perform compression in 3GPP (and presumably in
3GPP2) between the  UAS and the first proxy (UE to P-CSCF in 3GPP). TS
24.228 shows the current flows for this (version 1.1.0 is at
ftp://ftp.3gpp.org/Specs/Latest_drafts/ ). Unfortunately this document only
partially populates the example fields, and relies on a shorthand notation
in order to identify the contents of remaining fields from the previous
tables - we are looking for someone to write a macro that will do this
population automatically before final publication).

We have yet to choose the compression scheme, and obviously would prefer
something that is IETF defined. Expect that some discussion on this should
take place in the SIPPING WG 2nd session in London.

One thing that should be born in mind is that there is also a requirement
for encryption on the above radio interface. The encryption mechanism to be
used is still under discussion. I assume that depending on whether the
encryption is performed before the compression or after will have a drastic
effect on the compression.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Price, Richard[SMTP:[email-masked]]
> Sent: 	20 July 2001 13:21
> To: 	'Dr. Carsten Bormann'; Romeo Zwart; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> <<File: RMRL-Disclaimer.txt.txt>>
> Hi,
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 25 Jul 2001 13:42:30 -0400

Megaco is a protocol with binary and text encodings.
The binary is BER encoded, and there are exactly equivalent
ASN.1 and ABNF descriptions of the encodings to match the
protocol text.  The results we have so far suggest that message
length of binary encoding is larger than the text encoding
for the same message.  This isn't speculation, it's what we
measure when you take an implementation that has both encodings
and look at the message lengths.

If you simply use binary encodings for the basic syntactic
constructs, you will get negative compression.  The compression
available comes from dealing with the contents of the
values, not the basic method/header constructs.

Brian

> From: Price, Richard [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 11:58 AM
> To: 'Christer Holmberg'; Jonathan Rosenberg
> Cc: 'Michel de Boer'; [email-masked]'; [email-masked]'
> Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP
> 
> 
> Hi,
> 
> Is compression so different from binary encoding?
> 
> Our own EPIC scheme uses the BNF description of a protocol to 
> "learn" a
> set of binary encodings for the protocol. The compressor then replaces
> each text string with its equivalent binary encoding.
> 
> It is feasible to write a SIP implementation that uses these binary
> encodings directly, missing out the text-based version of the message
> altogether. This is not a change to the core protocol, but rather a
> combined SIP stack/SIP compressor.
> 
> Normally this would be a big amount of effort for very little gain.
> However it certainly solves the concerns about processing requirements
> (as it doesn't have any!)
> 
> Regards,
> 
> Richard P
> 
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2001 3:26 PM
> To: Jonathan Rosenberg
> Cc: 'Michel de Boer'; [email-masked]'; [email-masked]'
> Subject: [rohc] Re: [Sip] New I-D on compression of SIP
> 
> 
> 
> Hi,
> 
> A few comments from me.
> 
> First, my personal opinion about the binary talk: let's skip 
> the binary
> talk. If we start talking about it, we will argue about it 
> for at least
> 6 months (I think the people who have been involved in the MEGACO work
> know what I'm talking about...) Then, IF we would decide to also go
> binary, experience (read: MEGACO) has shown that it's not that easy to
> define text- and binary rules that "match" 100%. Ok, SIP 
> would probably
> be a little easier than Megaco, since we don't have wildcard 
> values etc,
> but still. Then we would also have the encoding negotiation 
> problem, and
> the issue about which nodes MUST/SHALL/SHOULD support what... 
> And, which
> has been mentioned also by others, that we really don't transport that
> much information in SIP, so would the gain (not very much, I'd say) be
> worth the pain (very much, I'd say)?
> 
> Compression is more "flexible". For most 
> networks/architectures I don't
> think it will provide very much, but if peope want to use it they are
> free to do so - but it would not affect the core protocol.
> 
> Then, if we assume that we need compression, we have the other
> questions, which I think are more important to discuss:
> 
> 1. Hop-to-hop vs end-to-end
> 
> 2. Do we compress the whole message, or only parts of it (the message
> body, for example)
> 
> 3. Compression negotiation
> 
>    a) Do we use an external negotiation mechanism, and 
> negotiate before
> we start the SIP session. Since the             proxies in many cases
> also must be involved in this negotiation we would probably need some
> kind of 
>       "centralized" function for this.
> 
>    b) Do we send the initial INVITE uncompressed (or partly 
> compressed)
> with a Supported/Require/Proxy-Require   
>       header listing the supported compression algorithms. 
> And again, if
> the proxies must support the             compression, there must be a
> way for them to indicate it (can be done for example either by
> using             Proxy-Require, or some Record-Route parameter)
> 
>    c) Do we use "manual" configuration, either by hand or by 
> using some
> of the SIP extensions that have been       defined for remote
> configuration.
> 
> 
> My thoughts...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > > From: Michel de Boer [mailto:[email-masked]]
> > > Sent: Thursday, July 19, 2001 3:54 AM
> > > To: Jonathan Rosenberg
> > > Subject: Re: [Sip] New I-D on compression of SIP
> > >
> > >
> > > Jonathan,
> > >
> > > You state that one of the ways to achieve message size 
> reduction is to
> > > define a binary encoding, but that this introduces 
> interoperability
> > > problems.
> > >
> > > How can a compression scheme based on dynamically constructed
> > > codebooks
> > > be simpler?
> > 
> > Simpler, perhaps not (although if you're using PER or BER, 
> its not clear to
> > me that this is simpler, codewise). But, it totally breaks 
> compatibility
> > with the existing protocol. By pushing this into a 
> transport problem, it is
> > isolated to the two entities that need to worry about it.
> > 
> > > In my opinion this approach is more prone to
> > > interoperability
> > > issues.
> > 
> > Thats not clear at all. Either way, we would require new code in
> > implementations. For a new binary coding, we would be back 
> to square 1, so
> > that everyone would have to work out the kinks in their 
> encoder/decoders for
> > every element in the syntax. However, with a shim, we 
> leverage existing,
> > mature parsers and generators. We add a layer that is not 
> specific to SIP,
> > so it has no syntax or anything else to get wrong. Its 
> defined by a fairly
> > simple set of state machines, which should not be that hard 
> to get correct.
> > I would argue its easier to get that right than it is to 
> get a totally new
> > encoding of SIP right.
> > 
> > > Codebooks can get out of sync.
> > 
> > Yes, and that does need to be handled in the protocol.
> > 
> > > As codebooks are specific to a sender-
> > > receiver pair, an entity communicating with multiple other
> > > entities, i.e.
> > > a proxy talking to many UA's must manage multiple codebooks.
> > 
> > Well, the problem at hand is really a wireless phone 
> talking to its local
> > outbound proxy. THus, the phone has only one relationship, 
> and the proxy has
> > one with each phone it communicates with. This pushes the burden of
> > compression to the elements that benefit the most from it. 
> From this point
> > onwards, normal SIP would be used, and so its compatible 
> with existing
> > proxies and UAs.
> > 
> > >
> > > For trouble shooting one might want to monitor a network 
> interface and
> > > analyze SIP messages coming in. It's impossible to read a 
> compressed
> > > message.
> > 
> > The output of the decompressor would need to be monitored.
> > 
> > -Jonathan R.
> > 
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 26 Jul 2001 14:08:25 +0100

Hi,

The compression ratio depends on how the binary encodings are
obtained. BER is not designed for efficiency and will most
likely produce binary encodings that are even longer than their
text equivalents.

In contrast, schemes like EPIC and Lempel-Ziv are designed
specifically to convert text strings into shorter binary
equivalents. Both schemes use Huffman compression for this task,
which on its own would get a compression ratio of about 1.2:1.
Compression is further improved by introducing a new binary
encoding that means "text is same as a previous text string".

It's debatable whether this should be called "binary encoding" or
not. However I stick by my original point (that you can implement
a combined SIP stack/SIP compressor to lower the overall processing
requirements).

Out of curiosity, what was the motivation for doing MEGACO
as both text and binary?

Regards,

Richard P

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 6:43 PM
To: Price, Richard
Cc: [email-masked]'
Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP

Brian

---

From: "Price, Richard" <[email-masked]>
Date: Thu, 26 Jul 2001 10:17:29 +0100

Hi,

We solved the "new token" problem by having a binary version of every ASCII
character. If there is a binary version of the whole token then we send that,
otherwise we send the binary versions of each individual character.

Regards,

Richard P

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 9:07 PM
To: Price, Richard; 'Christer Holmberg'; Jonathan Rosenberg
Cc: 'Michel de Boer'; [email-masked]; [email-masked]
Subject: Re: [rohc] Re: [Sip] New I-D on compression of SIP

It seems like failure of this approach is assured if a new token (one not in
the BNF) is encountered. SIP has lots of those. In the "compression"
systems, the new token is still transported correctly, but may not be
optimally compressed.

--
Dean
----- Original Message -----
From: "Price, Richard" <[email-masked]>
To: "'Christer Holmberg'" <[email-masked]>; "Jonathan
Rosenberg" <[email-masked]>
Cc: "'Michel de Boer'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 25, 2001 10:58 AM
Subject: RE: [rohc] Re: [Sip] New I-D on compression of SIP

> Our own EPIC scheme uses the BNF description of a protocol to "learn" a
> First, my personal opinion about the binary talk: let's skip the binary
> talk. If we start talking about it, we will argue about it for at least
> define text- and binary rules that "match" 100%. Ok, SIP would probably
> be a little easier than Megaco, since we don't have wildcard values etc,
> but still. Then we would also have the encoding negotiation problem, and
> the issue about which nodes MUST/SHALL/SHOULD support what... And, which
> Compression is more "flexible". For most networks/architectures I don't
>    a) Do we use an external negotiation mechanism, and negotiate before
>    b) Do we send the initial INVITE uncompressed (or partly compressed)
>       header listing the supported compression algorithms. And again, if
>    c) Do we use "manual" configuration, either by hand or by using some
> > > You state that one of the ways to achieve message size reduction is to
> > > define a binary encoding, but that this introduces interoperability
> > > problems.
> > >
> > Simpler, perhaps not (although if you're using PER or BER, its not clear
to
> > me that this is simpler, codewise). But, it totally breaks compatibility
> > with the existing protocol. By pushing this into a transport problem, it
is
> > implementations. For a new binary coding, we would be back to square 1,
so
> > that everyone would have to work out the kinks in their encoder/decoders
for
> > every element in the syntax. However, with a shim, we leverage existing,
> > mature parsers and generators. We add a layer that is not specific to
SIP,
> > so it has no syntax or anything else to get wrong. Its defined by a
fairly
> > simple set of state machines, which should not be that hard to get
correct.
> > I would argue its easier to get that right than it is to get a totally
new
> > Well, the problem at hand is really a wireless phone talking to its
local
> > outbound proxy. THus, the phone has only one relationship, and the proxy
has
> > compression to the elements that benefit the most from it. From this
point
> > onwards, normal SIP would be used, and so its compatible with existing
> > proxies and UAs.
> >
> > >
> > > For trouble shooting one might want to monitor a network interface and
> > > analyze SIP messages coming in. It's impossible to read a compressed
> > > message.
> >

---

From: [email-masked]
Date: Thu, 26 Jul 2001 11:59:56 -0500

> 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. 

By "direct communication with another UA", do you
mean the compression is not done at the first hop
proxy, or some SIP messages may not go through
the proxy? We have been assuming that the first hop
proxy of a mobile UA (yes, I take cellular as an example) 
is on the path of all SIP messages sent by and to
the mobile UA. This is not true in general, but I
think it can be configured that way for the purpose
of compression.

Also, those numbers were measured without the use of
dynamic dictionary. Only static and user specific 
data are used. The former doesn't need any signaling. 
The latter only needs to be populated once (to wherever
the other compression point is). 

> 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.

That's our concerns too and that's why we also
used the very simple lzss.c for comparison. Just 
to highlight some quick facts (they can be found
in Appendix A in SCRIBE-01):

- Static dictionary: 243 bytes
- user specific dictionary: 640 bytes
- lzss.c: ring buffer = 2 KBytes, 
          pointer = (11-bit position, 5-bit length)

For such a humble configuration, a compression ratio
about 5:1 (compared to gzip 6.xx:1) is pretty good.

What we see is different capabilities of UAs (e.g.
a cell phone vs.. a laptop) as well as the proxy. 
SCRIBE tries to address the issue by a framework
that is scalable and flexible. It allows different 
compression algorithms and different compression
data synchronization mechanisms. I believe the static
and user-specific data, coupled with a simple compression
algorithm, is a good starting point. From there,
we can add dynamic and more powerful compression
algorithm if we can afford the complexity.

> And as always, introduction of state always
> reduces your flexibility since there's a higher
> energy barrier to surmount when moving. 

Yes, that's why we propose the SIP proxy as the
other compression point. The mobile UA won't change
its proxy often. Even if the state transfer is needed, 
the extra vost is not that high considering all the 
state queries/transfers already needed in current 
cellular networks. (And you're right, as a law
of physics, you need more energy to be moble. :-))

BR,
Zhgiang

---

From: [email-masked]
Date: Fri, 27 Jul 2001 15:12:26 +0300

Hi,

There are three wireless network scenarios I know of where SIP is intended
to be used and where compression is either helpful or even critical.

1) GPRS as discussed below, which already exists to some extent and will
probably start properly within the next 6 months, as handsets should be
available in volume.

As Christian says VoIP is probably out of question for GPRS, as GPRS causes
delay in addition to the theoretical bit transmission time, and the
realistic capacities will initially be around 10-20 kbps. However, things
like SIP-based presence and messaging should be completely doable for GPRS,
and any reduction of transmission time would be nice. And perhaps people
start to use some form of semi-real-time stuff as well, who knows.

=> So, this is mainly an optimization.

2) WCDMA (UMTS, 3GPP) and CDMA2000 (3GPP2) which will be available within
the next couple of years to some extent.

Here VoIP will be possible, what comes to available radio capacity and
latency, as long as IP QoS (DiffServ) can be mapped to the actual radio
bearers. As WCDMA is quite flexible the required amount of capacity can be
applied e.g. for SIP based on traditional IP traffic classification.
However, in my understanding it is not very nice to keep capacity allocated,
even though you are not using it (as would be with SIP, which is very bursty
in nature). Also call setup with PRACK and COMET (and Privacy-headers etc.)
is quite heavy and requires several round trips. Thus, it is desirable to
have as small messages as possible.

=> It seems that compression would be a big optimization!

3) GERAN/GSM with header stripping

This means that it looks like VoIP (the core network is normal IP), but
actually the voice frames/packets are carried over the air as
circuit-switched, using the channel coding for the voice codec. SIP is
carried using the signalling channels originally provisioned for GSM
signaling, so they are quite narrow. Especially during the speech call
itself, part of the signalling capacity is obtained by stealing bits from
the speech channels.

These kind of hybrid systems are really complex, but they are also very
efficient, and a lot of legacy stuff in the radio can be utilized. 

=> It seems that in these kind of environments compression will be really
critical to get the call setup times tolerable.

Markus

> From: ext Christian Huitema [mailto:[email-masked]]
> Sent: 25 July, 2001 19:00
> To: Dean Willis; [email-masked]
> Subject: RE: [rohc] RE: [Sip] New I-D on compression of SIP
> 
> 
> > 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.
> 
> Dean, let's do a reality check. We are constantly receiving 
> requests to
> tweak our TCP stack in order to match the long delays of GPRS channels
> -- more than 600 ms is not uncommon. These delays seem to be intrinsic
> to the technology, probably due to a mix of contention on 
> access and low
> level retransmission. Do you really believe that you are going to
> conduct a meaningful VoIP conversation over this kind of channel?
> 
> -- Christian Huitema
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 30 Jul 2001 11:52:59 -0400

I agree that any text (or BER) protocol is compressible using
techniques that recognize repetition of sequences.  SIP is especially
sensitive to anything that detects repeated domain names.

Megaco has both text and binary because there were two camps
who could not agree.  The binary camp was convinced that 
their encoding would be significantly smaller and faster.
In order to avoid a split, and thus two close, but not identical
protocols, we compromised.  I actually proposed, and at one
point had agreement on a coin toss!  The coin was tossed,
and it came out text.  The binary folks succeeded in overturning
the agreement on the coin toss.  Thus we have both. Around 95%
of implementations so far are text only.

Brian

> Sent: Thursday, July 26, 2001 9:08 AM
> To: 'Rosen, Brian'
> Cc: [email-masked]'

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Jul 2001 17:49:40 -0400

> Sent: Friday, July 20, 2001 7:38 AM
> To: [email-masked]; [email-masked]; [email-masked];
> At 09:28 PM 7/19/2001, [email-masked] wrote:
> >> The draft talks about the encoder that learns "in some way" 
> >> that the message was received at the other end. Magic I can 
> >> think of here would either look very much like an (implicit) 
> >> acknowledgement mechanism, where the decoder and encoder on 
> >> one side of the link communicate to confirm  message reception. 
> >> Alternatively, message confirmation might depend on  direct 
> >> signalling from the application layer to the compression layer. 
> >> However, since the SIP layer is not aware of the encoder, I 
> >> don't think that's a valid approach. I'd be interested to 
> >> how this is perceived to work.
> 
> >(e.g. SIP in this case). 

The idea with the proposal (and, BTW, SIP Compression is a misnomer since
the mechanism, like everyone elses, is not application specific. I called
the draft Compression of SIP to draw the SIP community's attention to this
kind of approach as the preferred solution) is that the application layer
protocol already has its own reliability and handshake messages. So, there
would be some kind of API interface between the sip layer and the transport,
which the sip layer would use to inform the transport when a message has
been acknowledged.

The benefit is message overhead reduction and simplicity, at the cost of
requiring a small amount of support from the application (sip) to support
the transport. Is it worth it? Maybe, maybe not. I am not particularly
religious on this, and my goal was to just keep it simple.

James Undery wrote:
> "Lars-Erik Jonsson (EPL)" wrote:
> 
> > Hi Jonathan,
> >
> > First of all I have to say that I think it is good that we 
> now have several contributors to this discussion about 
> signaling compression, e.g. SIP compression. I have read your 
> draft and have a number of comments but before I take them 
> all I would like to ask you for some clarifications about how 
> you mean this new "protocol shim" is introduced in reality. 
> You say that it becomes a new alternate transport but it is 
> not clear how this is indicated. Is your intention to create 
> a new "UDP-compress" transport protocol (new protocol ID)?
> 
> I think by this Jonathan means to have a new transport 
> parameter for SIP URLs and position the encoding/decoding 
> just above the UDP "stack" code and below the SIP "stack" 
> code. 

Yes, exactly. I am not proposing a new tranport protocol that needs to be
signaled within IP (peer to UDP, TCP), but rather something that SIP
considers a transport protocol. This means that we can have SRV records of
the form:

_sip._cudp.foo.com

which would identify servers for foo.com providing SIP over this transport
(Compressed UDP, or whatever we call it). We can also have a SIP URL
transport param:

sip:[email-masked];transport=cudp

which can be used in record-routing, for example.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Jul 2001 18:17:23 -0400

> Sent: Thursday, July 26, 2001 5:17 AM
> To: 'Dean Willis'; 'Christer Holmberg'; Jonathan Rosenberg

It seems like what you are really talking about is a static dictionary based
on a study of the BNF of the protocol. I suspect that you could probably
hand tune a static dictionary to be even better based on knowledge of what
actually comes in a SIP message in real scenarios. I still think a dynamic
dictionary ontop of a static one like you propose is even better, any my
initial tests gave me 8:1 compression, far better than anything reported
with pure static (and I will note that this was with an LZW variant; if you
pay the compute overhead of LZSS it will really rock, but I have not done
explicit tests.)

Is the improved efficiency of dynamic codebooks worth the cost of state
management that comes with dynamic codebooks? Indeed thats a good question,
and one which depends entirely on your view of whats important in the
system. It is not a cut-and-dry comparison.

-Jonathan R.

---

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 31 Jul 2001 12:52:19 +0100

Hi,

EPIC is not just a static dictionary for a Lempel-Ziv compressor: rather
it is a new compression algorithm proposed as an alternative to Lempel-Ziv.
The key difference between the algorithms is that all Lempel-Ziv variants
store the dictionary as a single text string, whereas EPIC stores the dictionary
as a set of named "fields" as defined by the BNF of the protocol.

EPIC includes the concept of a dynamic dictionary, since one of the binary
characters we can send means "field is same as previous instance of field". This
is optional though, depending on whether the bigger compression ratio is worth
the extra hassle of maintaining robustness.

We tested EPIC against several variants of Lempel-Ziv and found the compression
ratio to be around twice that even of LZSS. This seems to be independent of whether
we use a dynamic dictionary or not: without one we get a compression ratio of
2.8 vs 1.4 for LZSS, and with dynamic dictionaries we get 22.2 vs 10.6 for LZSS.

Perhaps more importantly, the memory requirements of EPIC are much lower than
Lempel-Ziv because it only keeps the fields which will reappear in the message flow
with high probability. The dynamic dictionary requirements of our implementation
are sub 100 bytes for the SIP flow tested above. Processing requirements are
lower too, just because there is less dictionary to search.

Questions and comments gratefully appreciated.

Richard P

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, July 30, 2001 11:17 PM
To: Price, Richard; 'Dean Willis'; 'Christer Holmberg'; Jonathan
Rosenberg

-Jonathan R.

---