Subject: RE: [rohc] RE: [Sip] SIP Compression

From: [email-masked]
Date: Thu, 2 Aug 2001 10:16:42 -0500

> How compression negotiation is done for SIP? 

It can be done either at SIP layer (by adding new 
headers/parameters) or at the compression layer
(transparent to SIP). The latter is more generic 
as the same compression can be applied to application 
layer protocols other than SIP.

> How does Proxy server know when to use compression 
> (as compression should be used only if there is cellular
> link between proxy and end node)? 

The compression entity at a mobile UA and the compression
entity at the proxy server need to initialize/negotiate
(see above) the compression context before compression 
happens. This can be done, for example, when a mobile
powers on or roaming to a new proxy server. After that,
the proxy server will compress messages sent from/to
the mobile.

> when proxy server wants to connect to other end user, it 
> is starting session, does it know about link characteristics 
> between itself and the other end?

No, it doesn't need to. The assumption is that each mobile 
pairs with a first-hop SIP proxy server (see above).

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: "Aniruddha Kulkarni" <[email-masked]>
Date: Thu, 2 Aug 2001 14:12:37 +0200

Hi

How compression negotiation is done for SIP? How does Proxy server know when
to use compression (as compression should be used only if there is cellular
link between proxy and end node)? When SIP user starts session, it is
obvious, when proxy server wants to connect to other end user, it is
starting session, does it know about link characteristics between itself and
the other end?

---Aniruddha

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 25, 2001 9:34 PM
Subject: RE: [rohc] RE: [Sip] SIP Compression

> 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
>
> > -----Original Message-----
> > 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
> >
> > ----- 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
> >
> >
> > > 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
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > --
> > > > Suheel Hussain
> > > > [email-masked]
> > > > Cisco Work # (919) 392-2312
> > > >
> > > >
> > > ---
> > > Mailing list for Robust Header Compression WG
> > > Archive: http://www.cdt.luth.se/rohc/
> > >
> >
> > ---
> > Mailing list for Robust Header Compression WG
> > Archive: http://www.cdt.luth.se/rohc/
> >
>

---

From: "Hans Hannu" <[email-masked]>
Date: Fri, 3 Aug 2001 09:06:48 +0200

>layer protocols other than SIP.

Is it not so that it could be the same compression scheme in both cases
(generic solution)? What would be different is how to  negotiate the usage
of the compression scheme in the first case.

BR
/Hans H

---

From: [email-masked]
Date: Fri, 3 Aug 2001 10:30:53 -0500

> Is it not so that it could be the same compression scheme in 
> both cases (generic solution)? What would be different is how to  
> negotiate the usage of the compression scheme in the first case.

By "compression" I mean the entire compression functions 
including the negotiation etc. The difference is that 
in the latter case, the application protocol need not know 
anything about the compression (except perhaps its mere
existence if encryption is an issue). Therefore, we
can just insert the compression layer without any change
to the application protocol above.

I guess by "compression scheme" you mean the core compression
engine *excluding* the negotiation part. In that case, I
certainly agree with you. It can and should be common. 

BR,
Zhigang

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 3 Aug 2001 14:09:31 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 03, 2001 11:31 AM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]

Well, the question is how one "just inserts" the compression layer in such a
way that both sides know about it. Remember, signaling compression is
between a wireless phone and proxy, for example, which is end-to-end at the
IP layer (hop-by-hop in the SIP meaning), so the sender has to know whether
to insert this compression layer before it sends its first message to the
receiver. My proposal for modeling this as a SIP transport handles this
case. I suspect that the usage of SRV records, a key piece of the SIP
approach, will also work fine for other application protocols, such as RTSP.

-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: [email-masked]
Date: Fri, 3 Aug 2001 15:06:51 -0500

Hi Jonathan,

> Well, the question is how one "just inserts" the compression 
> layer in such a way that both sides know about it. Remember, 
> signaling compression is between a wireless phone and proxy, 
> for example, which is end-to-end at the IP layer (hop-by-hop 
> in the SIP meaning), so the sender has to know whether
> to insert this compression layer before it sends its first 
> message to the receiver. 

Yes. But I don't see why this cannot be done at compression
layer (which is below the application protocol). The compression 
module at wireless phone can contact/negotiate with its peer
at the proxy to setup compression state. If this fails (e.g.
no response from peer or some other abnormal conditions), the 
local compression module simply passes any application message
transparently without applying compression (i.e. turn itself
off).

> My proposal for modeling this as a SIP transport handles this

As I said, negotiation at application layer is certainly an 
alternative. But it looks to me less generic in that it may 
require additions/modifications to the existing application 
protocols. And we have to do that one by one. Second, there are
some details in the compression state (e.g. compression algorithm)
which I'm not sure should be handled at application layer.
Also, negotiation at compression layer allows the procedure to
be finished even before the first message is generated by the 
application protocol (e.g. as soon as the wireless phone is 
powered on). That mitigates the surge in bandwidth requirement 
and gives a smoother jump start for the compression (especially
of the first message).

Br,
Zhigang

---

From: "Hans Hannu" <[email-masked]>
Date: Mon, 6 Aug 2001 07:59:09 +0200

>to the application protocol above.

Ok, good.

>certainly agree with you. It can and should be common. 

Yes. That was my meaning.