Subject: RE: [rohc] Where is the pair operation figure in Sigcomp-05 ??

From: "Price, Richard" <[email-masked]>
Date: Tue, 5 Mar 2002 15:21:27 -0000

> Hi Richard:
> 
> So I understand now that, at least, one of the possible ways that SigComp 
> may use to work is the one depicted in Figure 3 (sigcomp-04), although
> there may be other ways of operation.
> 
> If this is the case, I would like to understand how are those SigComp
> Request, SigComp Capabilities announcement and UDVM upload messages 
> distinguished from SigComp compressed messages. The SigComp message format
> in section 4.2 of Sigcomp-05 does not include any means to identify the
> message type. Or am I missing something?

Hi Miguel,

Good question! The reason that the message type is not included in the SigComp
message format is that in many cases it's useful for one message to fulfill
several tasks. For example, the UDVM Upload will often be sent in the same
message as the Capabilities Announcement for the reverse direction (e.g. the
P-CSCF can transmit some UDVM bytecode to the UE at the same time as
announcing its own capabilities).

Therefore, the basic SigComp header only distinguishes between an ordinary
SigComp message (which contains a state identifier to retrieve the correct
decompression algorithm) and a UDVM Upload message (which downloads a suitable
algorithm as bytecode).

The Capability Announcement information (as per Figure 5) is piggybacked
to a UDVM Upload message by sending a specific UDVM instruction. Of course,
it's always possible to send announcement information without also including
bytecode for a decompressor, just by sending the UDVM instruction for
capability announcement and no others.

The same applies to a SigComp Request message (it's invoked using a certain
UDVM instruction).

> On the other hand, I disagree with your statement:
> 
> > In fact, for the particular case of SIP the message flow of figure 3 is
> > wrong and cannot be used.
> 
> I believe that figure 3 can be used for SIP and any other protocol. I would like
> to understand what is wrong with the figure and why do you say that it does 
> not work with SIP. In my understanding, the first application compressed 
> message in figure 3 is the "Compressed messages" at the bottom of the figure.

My concern with figure 3 is just that it requires 3 messages to be sent before
compression can begin. If the signalling protocol sends fewer that 3 messages
during the registration phase then the time-critical portion of the signaling will
begin before the compression algorithm has been selected. Not a good situation to
be in.

If the signalling protocol sends 3 or more messages during its registration phase
then the message flow is OK.

> You mention also the security of the SigComp negotiation. SIP recommends to 
> authenticate the REGISTER message, and this is what we are doing in 3GPP.
> The first SIP REGISTER message is authenticated. Although this topic has not
> been discussed deeply, I believe some folks will prefer to postpone the 
> start of Sigcomp until the user is authenticated. In the case of 3GPP,
> the authentication procedure includes a dobule round trip (REGISTER, 401, 
> REGISTER, 200). These messages will probably be sent uncompressed, and
> afterwards, SigComp can be started and compressed message can be sent.

If SigComp is postponed until the user is authenticated then I presume that
security would be handled below SigComp?

If the lower layers already provide security then some of the restrictions
placed on SigComp operation can be lifted. For example it is no longer
necessary to ban standalone SigComp messages, so the message flow for
initialisation can be of arbitrary length without impacting the call setup
time. This means that the message flow of figure 3 is OK.

Regards,

Richard

---

From: Kevan Hobbis <[email-masked]>
Date: Tue, 5 Mar 2002 15:32:21 -0000

As I was probably one of the people giving Miguel this opinion then I
thought I ought to contribute to this discussion.

My requirements were to have the best of all worlds (I'm an operator so I am
allowed to have such requirements). I would like to compress the very first
REGISTER message, the one that triggers authentication. I do not want
network traffic to negotiate or announce the available compression
algorithms before this because the user would not be authenticated but
utilising network resources.

Hence what I proposed is :-

A well-known (by both ends) compression algorithm is used to send the very
first REGISTER. This can be guaranteed to be decompressed by the receiver as
it is an agreed well-known algorithm. No negotiation is needed, nor is any
transfer of code required. Until the user is authenticated these things
would be network traffic that e.g. I cannot bill for (if that is what I
intended to do), so I do not want them using up my radio bandwidth which is
very precious.

As far as I understand the arguments :-

It may be that using a 'not-so-good' algorithm may cause the total number of
bytes transferred in the REGISTER plus Authenticate process to be more than
that used if a 'very good' algorithm with associated negotiation etc. is
used. But, I need to authenticate the user before I can allow the use of
network resources. Can a request for a better algortihm be piggy backed onto
the SIP messages from REGISTER onwards so that a new and better algorithm is
in use before the procedures have completed ?

Thanks

Kevan

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]]
Sent: 05 March 2002 14:36
To: Lawrence Conroy
Cc: Price, Richard; [email-masked]
Subject: Re: [rohc] Where is the pair operation figure in Sigcomp-05 ??

Lawrence:

As I said, the discussion on whether to compress and then authenticate,
or authenticate and then compress, or all together in one shot, has not
been debated yet. 

I am just saying that I heard opinions in favor of authenticating and 
then compressing. That is what I said.

/Miguel

Lawrence Conroy wrote:
> 
> At 3:34 pm +0200 5/3/02, Miguel A. Garcia wrote:
> >Hi Richard:
> ><snip>
> >start of Sigcomp until the user is authenticated.
> To which I reply:
> 
> Hi Miguel, folks,
> That's not quite my understanding of CN1's output;
>    I understood that other folks still wanted the bonus of compressed
> REGISTER messages; i.e. none of the contribs. were completely accepted.
> 
> I understood that the reason that some folks did not want compression for
> everything was a common (hey, it's 3GPP :) misunderstanding of the cost of
> compression/decompression versus authentication/message integrity.
> 
> Thus maybe compression will be allowed in the first REG message pair, and
> (more likely) the subsequent/successful REG message pair. It's also
possible
> that it won't be done at all for REG - basically, the horses are still
running.
> 
> all the best,
>     Lawrence
> --
> [email-masked]: +44 1794 833666::<my opinions>:

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

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

_______________________________________________________________

If this email isn't for you then we'd be grateful if you could let our
helpdesk know there's been a mistake by putting 'received in 
error' in the subject box and sending it to [email-masked]. 
If it isn't for you, we're sure you'll understand that you're not 
allowed to copy, disclose or distribute any of its contents.  
This email is private and confidential and may also be privileged,
so if you shouldn't have received it, we'd be grateful if you could delete it.
Thanks.
________________________________________________________________

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

---

From: "Price, Richard" <[email-masked]>
Date: Tue, 5 Mar 2002 17:24:48 -0000

Hi,

Whether to compress the first REGISTER message or not depends on what operators
consider to be the most valuable network resource: bandwidth or processing power?
Depending on the above, we can then work out the best message flow to negotiate/
download the SigComp compression algorithm.

If a REGISTER message is sent uncompressed then it consumes a large amount of
bandwidth but a small amount of processing power (just enough to authenticate the
user, after which billing can start). Compressing the first REGISTER message
requires more "free" processing cycles to be given away, but reduces the amount
of bandwidth consumed before the user can be authenticated.

In practice the amount of extra processing power needed depends on the strength
of the compression algorithm. A very simple algorithm can run as fast as the
authentication protocol used on the uncompressed message, but the compression
ratio will not be more than around 1.5 to 1. Powerful algorithms will need at
least an order of magnitude more processing power but will gain a compression
ratio of 5 to 1 or better.

Regards,

Richard

P.S. The above discussion only applies when authentication is done by the lower
layer (e.g. IPSec). If done on the application layer (e.g. HTTP message digest)
then we don't have a choice - all messages must be first decompressed by SigComp
before they are authenticated. So sending the REGISTER message uncompressed saves
us nothing in this case.

> From: Kevan Hobbis [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2002 3:32 PM
> To: 'Miguel A. Garcia'; Conroy, Lawrence (SMTP)
> Subject: RE: [rohc] Where is the pair operation figure in 
> Sigcomp-05 ??
> 
>