Subject: [rohc] sigcomp issue cabo-6

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 16 Apr 2002 20:01:32 +0200

Hi,

> The original idea in the proposed resolution was to be able to put the
> code behind all the data.  This is no longer possible. Bug/Feature?

Why is this not possible? 
To me the SigComp-05a approach and the approach in the issues list are similar except in the way the code start address is worked out.

SigComp-05a: code start address equals: the destination field * 64.
Issues list: code start address equals: 2^(destination field?) - code length.

BR
/Hans H

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

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 22 Apr 2002 16:20:27 +0100

> To me the SigComp-05a approach and the approach in the issues 
> list are similar except in the way the code start address is 
> worked out.
> 

Hi,

The new encoding for the destination field is (I hope) a feature rather
than a bug! The encoding has been updated to reflect the minimum size of
the UDVM memory.

In the first message of the session the decompression_memory_size of the
receiver is not yet known, so for safety it must be assumed that it is the
minimum value of 2048 octets. Up to 1024 octets will be reserved for the
compressed message itself, leaving a remainder of 1024 octets for the UDVM
memory.

Fortunately, 1024 octets is sufficient to store the bytecode, tables and
variables of an algorithm such as DEFLATE, together with a small circular
buffer for the previously received text strings. If more than 1024 octets
of UDVM memory happens to be available at the receiver then the algorithm
can make use of this extra memory just by increasing the size of the
circular buffer.

This means that the UDVM memory will typically be divided into 3 sections:
variables first (because they are cheaper to store in low UDVM memory),
followed by the UDVM bytecode and then by the circular buffer (which can
change size depending on the total amount of memory available to the UDVM).

The upshot of this argument is that I expect almost all bytecode uploaded
to the UDVM will be stored in the first 1024 octets of memory. Since the
SigComp header has a 4-bit destination field, it seems appropriate just to
multiply by 64 and allow the UDVM bytecode to start at any block of 64
octets up to Address 960.

Regards,

Richard