Subject: RE: [Sip] SIP Compression

From: [email-masked]
Date: Wed, 25 Jul 2001 17:26:42 +0300

Hi,

> -----Original Message-----
> 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:
> 
> > 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
> >> 
> > 
> > 
> > 
> > _______________________________________________
> > 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
> 
> 
> -- 
> 
> Suheel Hussain
> [email-masked]
> Cisco Work # (919) 392-2312
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: "Aniruddha Kulkarni" <[email-masked]>
Date: Wed, 25 Jul 2001 17:54:01 +0200

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

----- Original Message -----
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

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

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 25 Jul 2001 15:01:53 -0500

The problem is that hop-by-hop and end-to-end mean different things to
different people.

There are SIP hops and IP hops.

IP hops are between IP devices (hosts and routers) , and a stop at an
application node like a SIP proxy represents the start of an entirely
seperate IP route.

SIP hops are between SIP nodes like UAs and proxies.

So for example:

UA->rtr->rtr->rtr->proxy

is 4 IP hops and one SIP hop.

There's no reason for the routers to compress/decompress SIP information.
They do need to decompress IP headers to do IP routing, but they don't look
at the SIP stuff at all.

UA->rtr->proxy->rtr->ua is two SIP hops, each with two IP hops. Here, the
proxy in the middle needs to decompress the SIP in order to make a SIP-level
routing decision..

When an IP person says end-to-end, they mean the source UA compresses, the
proxy decompresses and recompresses, and the destination UA decompresses.

A SIP person says end-to-end, they mean the source UA compresses and the
destination UA decompresses. That only works if there is no proxy in the
middle.

So, the SIP-specific compression protocols under discussion (like
Rosenburg's) tend to be hop-by-hop at a SIP level, and end-to-end at an IP
level.

--
Dean