Subject: RE: [Sip] SIP Compression

From: [email-masked]
Date: Tue, 24 Jul 2001 10:48:24 -0500

> RoHC works hop-to-hop, not end-to-end when there are multiple 
> hops between two ends. Does SIP Compression mechanisms also 
> have this constraint? If yes, why? 

I don't see the reasons for such constraint. In fact, if 
encryption is applied end-to-end, per-hop compression is 
not feasible. See 
http://www.ietf.org/internet-drafts/draft-le-sigcompr-requirements-00.tx
t
and http://www.ietf.org/internet-drafts/draft-liu-rohc-scribe-01.txt.

> Are those designed to work only on cellular link between 
> mobile terminal and fixed end of cellular link (hop-to-hop)?

No. SCRIBE and some of other schemes do not assume hop-to-hop.
They can tolerate packet loss, misordering and large round
trip time.

> Why those mechanisms are not designed for end-to-end 
> compression? (reduce large payloads ,whatever be the 
> link characteristics...)

I don't know which mechanisms you're referring to. At
least SCRIBE can work as end-to-end compression. However,
the open issue is whether it is needed in fixed-line 
network considering the benefit/cost ratio. It is 
clearly needed over cellular links.

Br,
Zhigang

> ---Aniruddha 

_______________________________________________
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: "Peter Barany" <[email-masked]>
Date: Wed, 25 Jul 2001 10:41:50 -0500

Hello colleagues,

We submitted a contribution to 3GPP TSG GERAN WG1 and SA WG2 about one year
ago discussing this subject. I attach it as a reference (GP-000508). This
contribution was one of the reasons that some sort of SIP compression was
deemed necessary for UMTS (both GERAN and UTRAN). A snapshot of the results
presented in this contribution can also be found in
"draft-hannu-rohc-signaling-cellular-01.txt", I believe.

For those who do not have time to wade through the details of the
contribution, I summarize some key points below:

(1) Typical post-dial delay (on average) for a GSM circuit-switched call
setup is around 3.5 to 4 seconds. This has proven to be acceptable to a
customer. Anything "consistently" beyond that number becomes
questionable/unacceptable in terms of quality of service.

(2) The analysis in contribution GP-000508 shows that (with an average
compression of 25% to 35% for individual SIP request methods and response
codes accompanied by TCP/IP or UDP/IP header compression), this post-dial
delay number of 3.5 to 4 seconds can only be achieved/approached with the
least robust channel coding schemes (i.e., the least amount of coding ...
including up to no coding at all). This analysis was done for GERAN
(GPRS/EGPRS connected to the UMTS Core Network). Similar results can be
shown for UTRAN (i.e., W-CDMA). Also, even if the customer is willing to
accept longer post-dial delays, we submitted an additional contribution to
3GPP illustrating that the as the duration of calls becomes shorter on
average, the number of calls that can be supported per busy hour in a cell
decreases rapidly vs. GSM circuit-switched as the post-dial delay increases.
Therefore, a greater SIP compression ratio is required (via some form of
delta-compression as discussed, for example, in ROGER (see
draft-hannu-rohc-roger-01.txt).

(3) The open issue is where to place the compressor/decompressor pair and
how to negotiate the SIP compression/decompression scheme. The
compressor/decompressor scheme can be place either in (1) the mobile
station/client and the SIP proxy server; or (2) the mobile station/client
and the radio network controller. NOTE: The terms mobile station and radio
network controller can be exchanged with link layer compression or
node-to-node compression for those who do not like the idea of a "cellular
specific" argument.

In the case of (2), encryption (among other things) becomes an issue.
Therefore, if possible, solution (1) would be preferred. If solution (1) is
agreed upon, then perhaps a new layer between SIP and TCP and/or UDP is a
viable approach to designing the negotiation mechanism (e.g., something
similar to what was done for https via SSL/TLS). The Internet draft
"draft-rosenberg-rohc-sip-udpcomp-00.txt" is a start in this direction (to
some degree) but it lacks the signaling necessary for context update,
context feedback, and context repair at this point in time. 

Regards,

Peter Barany
IP Multimedia Standards and Research
Nortel Networks
+1-972-685-2471 (Office)
+1-972-684-3775 (Fax)]
+1-972-467-8346 (Mobile) 

-----Original Message-----
From: Aniruddha Kulkarni [mailto:[email-masked]]
Sent: Wednesday, July 25, 2001 6:45 AM
To: sean.olson; rohc; sip
Subject: [rohc] Re: [Sip] SIP Compression

If one has high latency link then nothing can be done about it. Compression
is not a solution for that.
If one has low bandwidth link and large data to send then Compression can be
the solution.
SIP messages take up only small portion of the available bandwidth (even on
Cellular links..). Then why use compression for SIP messages? Well..
cellular links have high BER, in this situation it is advisable to have
smaller packets to reduce error probability.. that is why use compression.
.. correct?

Still large number of connections to internet are over telephone modem links
with low bandwidth, comparable with latest cellular links. Isn't it useful
to have end-to-end SIP message compression in that situation?

How much the SIP compression schemes are dependant on RoHC? Could they have
in-built mechanism for configuration negotiation? Should they demand this
facility from lower layers? It seems to me that these schemes work more at
application level and should have configuration negotiation at that level
only. That way they could be easily extened for use on end-to-end rather
than limiting them to hop-to-hop (by depending on RoHC).

---Aniruddha

----- Original Message -----
From: <[email-masked]>
To: "'Aniruddha Kulkarni'" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, July 24, 2001 6:27 PM
Subject: RE: [Sip] SIP Compression

> SIP is not intended to transport large amounts of information.
> That plus the ratio of bandwidth used by signalling vs.
> the bandwidth used by the media, means that signalling compression
> for SIP is not in general a problem. It only really becomes a
> problem on low bandwidth, high latency *links* such as a cellular
> link where sometimes every byte counts.
>
> In short, I believe signalling compression is a hop-by-hop
> problem and not an end-to-end one. A hop-by-hop solution seems
> appropriate in this case.
>
> It should also be noted that you can always apply gzip compression
> to the MIME body of a SIP message to achieve some end-to-end
> compression. IMHO, this is not needed.
>
> I believe the compression techniques that have been
> described so far (ROGER, SCRIBE, EPIC, etc.) are
> fairly generic and would work well on a variety of
> link types. Some have been tailored with cellular
> in mind.
>
> Hopefully this addresses your concerns,
> Sean Olson
> Ericsson Inc.
>
> -----Original Message-----
> From: Aniruddha Kulkarni [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 8:30 AM
> To: [email-masked]; [email-masked]
> Subject: [Sip] SIP Compression
>
> RoHC works hop-to-hop, not end-to-end when there are multiple hops between
two ends.
> Does SIP Compression mechanisms also have this constraint? If yes, why?
> Are those designed to work only on cellular link between mobile terminal
and
> fixed end of cellular link (hop-to-hop) ? Why those mechanisms are not
designed
>  for end-to-end compression?
> (reduce large payloads ,whatever be the link characteristics...)
>
> ---Aniruddha
>

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

---

From: [email-masked]
Date: Wed, 25 Jul 2001 14:34:16 -0500

Hi,

Somehow, I feel we're drifting away from the real issue.
First of all, the need of SIP compression arises only 
because a SIP user is connected to the rest of world via 
a bandwidth limited link (e.g. cellular). Otherwise, we 
won't make all the mess to compress SIP, which negates
all the reasons why SIP is text based in the first place.

Therefore, I think a compression between the SIP user and
a SIP proxy on the other side of the low-bandwidth link
is a reasonable approach. Note that this is neither hop-by-hop,
nor end-to-end (I assume by e2e you mean the two end SIP 
users, not including the proxies).

This solves the problem where it arises, with no effect to
the rest of networks. Specifically, a "normal" SIP user with
fast connection does not need to have the compression function,
nor does it have to determine if the peer SIP user is a mobile
or not. 

As to the extra load on SIP proxy performing the compression, I 
don't think it is a problem as Markus indicated. Furthermore, the 
function needs to be there anyway since the proxy needs uncompressed
(at least part of) SIP messages.

Br,
Zhigang

> From: ext Aniruddha Kulkarni [mailto:[email-masked]]
> Sent: July 25, 2001 10:54 AM
> To: Isomaki Markus (NRC/Helsinki); [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [rohc] RE: [Sip] SIP Compression
> 
> 
> end-to-end compression seems more efficient as it doesn't 
> depend on link
> characterictics of link between each hop. A payload compression scheme
> should be designed considering worst link characteristics 
> that a packet may
> encounter in it's path.. cellular link is a good example for 
> this between
> two hops. The gain obtained on those poor links can be carried over to
> better links without any loss.
> end-to-end scheme becomes more attractive when two disjoint 
> hop-to-hop links
> are of poor characteristics.
> The processing time on hops could be a issue in hop-to-hop schemes. An
> intermediate hop serving multiple connections, if under load, 
> could affect
> all connected entities.e.g. a base station serving multiple phones.
> (Particularly in payload compression schemes an intermediate 
> hop need not
> decompress at all..)
> In end-to-end scheme, there is no such problem, resulting in a better
> overall performance.
> 
> 
> Definitely, this is not applicable in header compression 
> schemes but for
> completely different reason, header required for routing. 
> There hop-to-hop
> is the best scheme regardless of processing time issue on 
> base station or
> any other benefits of end-to-end compression.
> 
> ---Aniruddha
> 
> From: <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Wednesday, July 25, 2001 4:26 PM
> Subject: [rohc] RE: [Sip] SIP Compression
> 
> 
> > Hi,
> >
> > > From: ext Suheel Hussain [mailto:[email-masked]]
> > > Sent: 25 July, 2001 15:46
> > > To: Aniruddha Kulkarni
> > > Cc: [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: [Sip] SIP Compression
> > >
> > >
> > > I have nagging issue with SIP compression -- compressing and
> > > decompressing on
> > > each proxy server is going to slow down call processing on
> > > large networks.
> > > IMO, it (compression) is not scalable.
> > >
> >
> > Well, obviously you would only compress/decompress where it 
> makes sense.
> > This would usually be between UA in a cellular host and its outbound
> proxy.
> > There you may only have a few kilobits of capacity 
> available (and during
> the
> > actual voice call even less), so it is feasible to trade between
> > transmission delay and processing complexity. So it is a classical
> > optimization problem with two constraints. Between proxies, 
> where you
> > (should) have enoungh capacity, compression will probably 
> just slow down
> > things.
> >
> > > Even end-to-end can be a problem if either (or both) UAS and
> > > UAC service a
> > > number of attached SIP-unaware systems. For instance a
> > > SIP-PSTN gateway.
> > >
> >
> > Again, using compression between gateways/controllers 
> probably does not
> make
> > sense as the capacity limitations shouldn't be a problem.
> >
> > Regards,
> > Markus
> >
> > > Aniruddha Kulkarni wrote:
> > >
> > > > ... correct?
> > > mobile terminal
> > > --
> > > Suheel Hussain
> > > [email-masked]
> > > Cisco Work # (919) 392-2312
> > >
> > >

---

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

> Sent: Wednesday, July 25, 2001 7:45 AM
> To: [email-masked]; [email-masked]; [email-masked]

As Dean has indicated, its the latency that becomes an issue. The amount of
time it takes to send a large message can impact post dial delay and other
related metrics.

> to have end-to-end SIP message compression in that situation?

I think there is some confusion over e2e vs. hBh. The proposed compression
scheme is, based on the SIP meaning, hop by hop, because its between a SIP
client and its proxy. In the IP stack, this is end to end, since it occurs
between application entities that send messages directly to each other over
an IP network. The SIP compression proposal is NOT a link-layer compression
mechanism, as ROHC itself is.

> than limiting them to hop-to-hop (by depending on RoHC).

The proposed compression scheme does not depend on ROHC, nor does it depend
on lower layers (IP or below) in any way. Negotiation of usage of the scheme
is done at the SIP layer.

-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