Subject: RE: [rohc] sigcomp issue rp-8

From: "Price, Richard" <[email-masked]>
Date: Tue, 23 Apr 2002 16:52:45 +0100

> One more question about STATE-CREATE:
> What is the sequence of events with respect to the application
> agreeing on the creation of the state?

Hi,

The application can't agree to create new state until the END-MESSAGE
instruction is reached, at which point the complete decompressed
message is available. All that can be done before this point is to
identify the areas of UDVM memory that will be saved as state, assuming
that permission is granted by the application.

> In other words, how does STATE-CREATE consume buffer size
> (decompression_memory_size)?
> We can't really have it consume state_memory_size, because we don't
> know the compartment ID yet at the time the UDVM still runs, so we
> don't know how much of that is left (and where to delete old state).
> Or is STATE-CREATE just leaving behind pointers into UDVM core that
> will be processed at END-MESSAGE time?

A new state item can be created by supplying the following 5 operands:

state_length
state_address
state_instruction
minimum_access_length
state_retention_priority

The total cost of storing this data is just 10 octets; the state_value
and the state_identifier do not need to be specified as operands
because they can be found in the UDVM memory at END-MESSAGE time.

A STATE-CREATE instruction would buffer the above 10 octets until the
message has been successfully decompressed, at which point the state_value
and the state_identifier can be obtained from the UDVM memory. So the cost
of buffering 4 STATE-CREATE instructions is just 40 octets; I don't
believe we need to subtract this from the decompression_memory_size
because 40 octets are negligible even for a memory-starved implementation.

> (BTW, you might get back the byte at the time the last message in a
> sequence gets compressed -- this may not have to create further state,
> saving the space for the pertinent parameters of END-MESSAGE.)

It's probably too late to update the END-MESSAGE instruction by then,
because all of the operands will have been uploaded to the receiving
endpoint and saved as state.

I believe that we should allow the END-MESSAGE instruction to create
one state item, and then use a specific STATE-CREATE instruction to
create extra state items up to a fixed maximum limit. This approach
nicely mirrors the situation for accessing state (we can access one
state item "for free" using the SigComp header, and can access further
state items by using a specific STATE-ACCESS instruction).

Regards,

Richard

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 23 Apr 2002 18:09:46 +0200

> because they can be found in the UDVM memory at END-MESSAGE time.

Sounds good to me (well, actually, 9 octets, but that's quibbling).

> state items by using a specific STATE-ACCESS instruction).

The purist in me doesn't like this too much, but then I probably don't 
care too much either.  So let's go forward with this.

Since you already wrote 80 % of what's needed:
Can you send me the text to put into the document?

Gruesse, Carsten

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