Subject: RE: [rohc] sigcomp issue cabo-15

From: "Price, Richard" <[email-masked]>
Date: Fri, 15 Mar 2002 16:03:04 -0000

> > Allowing cycles_per_bit and cycles_per_message to be chosen independently by
> > the decompressor is an extra implementation option that we can do without. We
> > should just fix the ratio between cycles_per_bit and cycles_per_message, and
> > only leave the cycles_per_bit parameter to be varied by the decompressor.
> 
> We could simply define (in the standard) the "canonical per-message
> overhead" of e.g., 1000 bits.
> Then cycles_per_message would be cycles_per_bit * canonical_overhead.

Hi,

From a security perspective the canonical_overhead should match the actual per-
message overhead as closely as possible. If it is set too high then attackers
will favour short SigComp messages, and if set too low then they will favour long
SigComp messages.

Is 1000 bits sufficiently close to the per-message overhead of an arbitrary
signalling protocol? If so then we should just fix it in the standard. If not
then we should leave it as one of the (non-negotiable) application-defined
parameters.

> > For the remaining parameters it would be useful to get some 3GPP input on
> > the range of endpoints that will be implementing SigComp. If we can persuade
> > everyone to use a 64K UDVM then there's no need to announce the available
> > memory at all!
> 
> It may be important to clarify in the standard that the UDVM is entirely
> transient, i.e. (unless you have a multiprocessor) there is never a need to
> have more than one UDVM around.
> All effects of the UDVM are caused upon END-MESSAGE, so it is OK to buffer
> up any TCP input up to an 0xFFFF before starting the UDVM (and, since we are
> supposedly compressing, the input should not be too large either).

As part of the "UDVM user guide" I've been examining the total working memory
requirements of one endpoint implementing SigComp. 

For a request-response protocol such as SIP the endpoint only needs to store
2 copies of the UDVM memory as state for each remote sender. A similar amount
of memory is required by each compressor, so the total working memory for an
endpoint is roughly as follows:

total_working_memory  =  UDVM_memory_size * (1 + 4 * no_of_remote_endpoints)

So for 3GPP, a 64K UDVM translates to around 320K per UE and 256K * no_of_UEs
for the P-CSCF.

As well as the above, endpoints might choose to provide extra working memory
to e.g. buffer a complete SigComp message before decompressing, compile UDVM
bytecode, create a hash table for fast state access etc.

Any major contributions to the working memory that I've forgotten?

Regards,

Richard

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Fri, 15 Mar 2002 18:06:38 +0100

> will favour short SigComp messages, and if set too low then they

This is true.
On the other hand, we'll have to allow for some startup overhead for the
decompressor if we want to be able to work with small messages.
I have not timed it, but I could imagine my deflate table generator could
use about 1000 cycles just for setting up the tables.
Decompressors like this should be possible.

> then we should leave it as one of the (non-negotiable) application-defined

The per-message overhead becomes very small with ROHC compression of the
headers.
So this may not be the best guidance here.

> endpoint is roughly as follows:

I don't get it.  Why do you need to store a whole UDVM core for each remote
sender?
You'd store a circular buffer and some code, but 64K?

Gruesse, Carsten

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