Subject: RE: [rohc] SigComp and SIP

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jun 2002 11:22:25 -0400

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> 
> If folks think that it is OK that two proxies that support 
> SigComp MUST
> always exhange compressed messages, I will be glad to simplify the
> draft. If people feel that compressing when it is not really needed is
> unacceptable, we will keep the current Record-Route inspection
> mechanism.

This is *NOT* acceptable. The performance impacts of any realistic
compression algorithm are substantial. Over the air, the decreased
throughput (and ultimately increased hardware costs) is justified
by decreased latency. Between nodes operating on a wired network,
it's merely a losing proposition.

/a

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Tue, 25 Jun 2002 21:49:07 +0200

> > SigComp MUST always exchange compressed messages, I will be glad
> > to simplify the draft. If people feel that compressing when it
> > is not really needed is unacceptable, we will keep the current
> > Record-Route inspection mechanism.
> 
> From: Adam Roach [mailto:[email-masked]]

I tend to agree with Adam, it should not be mandatory for a proxy to
use compression just because compression is supported.

/L-E

---

From: [email-masked]
Date: Tue, 25 Jun 2002 11:48:24 +0300

Looking at Gonzalo's example:

UAC----P1-----P2-----UAS

If P2 wants to receive compressed requests, then it adds comp=sigcomp in the RR header. If P2 does not want to receive compressed requests, then it does not include the param.

Now, if UAC wants to compress, it looks at the record-route header and finds out if the next hop (P2) wants to receive compressed data or not. In the case above, P2 did not want to receive compressed data, so UAC can't override P2's wish by sending it compressed data.

If you view the param comp=sigcomp and as an indication of willingness rather than capability, then doing it as described above makes sense.

If a UAC refuses to send uncompressed data, then perhaps a proxy-require: sigcomp (or something similar) can be sent.

Regards,
Hisham

> From: ext Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Tuesday, June 25, 2002 11:20 AM
> To: Jonathan Rosenberg
> Cc: sip; rohc
> Subject: [Sip] Re: [rohc] SigComp and SIP
> 
> 
> Hello,
> 
> Jonathan Rosenberg wrote:
> > Well, you are trying to achieve the (somewhat odd) goal of 
> allowing the
> > proxy to indicate that it would prefer not to use sigcomp, unless
> > someone around it doesn't record-route, so that sigcomp 
> would be needed
> > in order to avoid unidirectional compression. Is there a reason for
> > supporting this case? For any individual dialog, either a proxy
> > indicates it can do compression, or it doesn't. I don't see 
> the need for
> > this case, and it complicates what is otherwise a fairly simple and
> > elegant solution.
> > 
> 
> The trade-off we have is the following:
> 
> If we go for the simplest mechanism, every time two adjacent proxies
> support SigComp, they will exchange compressed messages. This 
> means that
> when two wireless terminals exchange SIP signalling thru a set of
> SigComp capable proxies, all the messages will be compressed, even
> between proxies.
> 
> We can avoid this and make that compression is used only over the air
> interface (i.e., not between the proxies in our example), but 
> we have to
> have proxies inspect Record-Route header fields.
> 
> 
> Personally, if nobody has big concerns about performance of precessing
> power, I would suggest that we simplify the mechanism and make it
> mandatory the use of compression for all entities that support SigComp
> (as suggested by Jonathan).
> 
> Regards,
> 
> Gonzalo
> 
> Sip mailing list  https://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: "George Foti (LMC)" <[email-masked]>
Date: Tue, 25 Jun 2002 08:12:46 -0400

> (as suggested by Jonathan).

Compression between proxies that support SIGCOMP cannot be a MUST. 
Not only does the processing power become an issue which will increase the
cost of the equipment without any *real value* added. The call set up delay
can be seriously impacted when you have 5 or 6 proxies to traverse in a
typical 3G-3G call.

Furthermore, when we talk about simplification what are we really
simplifying, the RR needs to be examined anyway for potential rewrites. 

So, I would stick to the original proposal. It must be an option and a local
policy to SIGCOMP or not.

Rggds/gf

---

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jun 2002 16:30:30 -0400

> This covers the following scenario:
> 
> UAC----P1-----P2-----UAS
> 
> The UAC sends an INITE to UAS. P2 records route, but P1 does not.
> When the 200 OK for the INVITE reaches P2, the contact and RR header
> fields will look like this:
> 
> Contact: [email-masked];comp=sigcomp
> RR: P2
> 
> If P2 does not add comp=sigcomp to his entry in the RR, UAC 
> will be able
> to receive compressed traffic (the contact has comp=sigcomp), but will
> be unable to send compress traffic (the RR entry for P2 does not have
> it).
> 
> Making P2 add comp=sigcomp resolves this asymmetry

I would argue that any network that uses compression like this
will almost certainly have a compression/decompression node (P1
in your example) in the path, and record-routing. I don't beleive
the extra complexity you describe is worth the effort of what
amounts to trying to work around poorly-designed networks.

/a