Subject: [rohc] sigcomp issue cabo-15

From: "Price, Richard" <[email-masked]>
Date: Fri, 15 Mar 2002 14:32:48 -0000

> cabo-15) How many values should there be for UDVM parameters?
> (e.g., fix six or seven values for UDVM size and use three bits in an
> announcement.)
> Memory size can be expressed in 3 bits:
> 1, 2, 4, 8, 16, 32, 64 K(1024)Bytes
> (1 is way low, but 3 bits allow you to say this)
> If this is too coarse, add a "and-a-half bit":
> 1, 1.5, 2, 3, 4, 6, 8, 12, 16, 24, 32, 48, 64
> Similar mickey-mouse floating point can be used for cycles-per-bit (3 bits
> give you 1 to 128) and cycles-per-message (5 bits give you 1 to 2 billion).

Hi,

On a similar note I'd like to remove cycles_per_message from the announcement
information.

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.

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!

Regards,

Richard

---

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

> 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.

> everyone to use a 64K UDVM then there's no need to announce the available

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).

Gruesse, Carsten

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