Subject: [rohc] sigcomp issue sugar-5/cabo-8

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Thu, 11 Apr 2002 14:19:07 +0200

Hi,

As Richard explains in his "action" to sugar-5. With the coming SigComp-06 a compressor is allocated a certain state_memory_size, and states are automatically deleted once the memory becomes full. The order in which the states are to be deleted can be set by a new parameter in the END-MESSAGE instruction called state_retention_priority and states with lower priority are deleted first. If there is a tie the state that was created first are deleted. 

As it is the decompressing side that assigns and announce the state_memory_size to the compressing endpoint it would not assign more memory than it can afford. So, the intention with the STATE-FREE instruction (let the compressor help the decompressor by freeing up state memory) are made somewhat "unnecessary".

I suggest that we close sugar-5 and cabo-8.

BR
/Hans H
	
> > 
> > 
> > Hi, 
> > 
> > The current sigcomp issue list can be found at:
> > 
> http://standards.ericsson.net/hanhan/SigComp-issue-list-10thMarch.htm
> > 
> > This is a cut and paste summary of the work that the authors 
> > have done when trying to close the issues.
> > Take a look and see what you think so that we can close the 
> > issues and submit the updated SigComp and SigComp-extended drafts.
> > 

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

---

From: [email-masked]
Date: Thu, 11 Apr 2002 09:36:22 -0500

Hi,

I think we still need STATE_FREE instruction. Once a
compressor assigns state_retention_priority to a state
and sends it out, there is no way to modify it. 
STATE_FREE allows the compressor to free a state
that wouldn't be freed by the assigned priority
(i.e. the lowest one).

Zhigang

> -----Original Message-----
> From: ext Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: April 11, 2002 7:19 AM
> To: [email-masked]'
> Subject: [rohc] sigcomp issue sugar-5/cabo-8
> 
> 
> Hi,
> 
> As Richard explains in his "action" to sugar-5. With the 
> coming SigComp-06 a compressor is allocated a certain 
> state_memory_size, and states are automatically deleted once 
> the memory becomes full. The order in which the states are to 
> be deleted can be set by a new parameter in the END-MESSAGE 
> instruction called state_retention_priority and states with 
> lower priority are deleted first. If there is a tie the state 
> that was created first are deleted. 
> 
> As it is the decompressing side that assigns and announce the 
> state_memory_size to the compressing endpoint it would not 
> assign more memory than it can afford. So, the intention with 
> the STATE-FREE instruction (let the compressor help the 
> decompressor by freeing up state memory) are made somewhat 
> "unnecessary".
>

---

From: [email-masked]
Date: Fri, 12 Apr 2002 11:09:35 +0200

Hi,

 Thanks for collecting the issues, it is much clearer this way. Some more comments on the STATE_FREE discussion...

Robert

> Sent: 11. April 2002 14:19
> To: [email-masked]'
> the memory becomes full.

	I do not see why we always have to use the full allocated memory when in fact we might not need that much all the time.

> The order in which the states are to 
> assign more memory than it can afford.
	
	In many cases memory handling is not that rigid. The decompressor can "afford" more memory if that boosts the compression, especially if they level off with the ones with smaller memory need (eg. in case of a SIP proxy). Some algorithms generally need more memory than others and announcements do not take that into account as the compression algorithm is chosen by the compressor and the memory size is chosen by the decompressor.

> So, the intention with 

	I agree with Zhigang that we still need STATE_FREE, especially because the compressor might not know in advance (when setting the priority) which states will be the most disposable ones.

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Fri, 12 Apr 2002 11:53:57 +0200

Hi,

> 	I do not see why we always have to use the full 
> allocated memory when in fact we might not need that much all 
> the time.

A compressor needs to know what state memory that is guaranteed to be available during the SigComp session. Otherwise the compressor cannot know when a state has been deleted and must not be used for compression anymore.  
 
> 	I agree with Zhigang that we still need STATE_FREE, 
> especially because the compressor might not know in advance 
> (when setting the priority) which states will be the most 
> disposable ones.

Hmm, so what you're after is a way to change the state_retention_priority and not explicitly tell the decompressor that "I'll not use this state anymore" but rather change the priority and let the deletion rule still be as it is. Then I think that this would not be a new instruction but rather an evolvement of the END-MESSAGE instruction. Hmm, such a feature could make it more complicated for a compressor to know what states that are actually established even when explicit acknowledgements are used as described in [extended]. However, I'm not sure how complex it would be it was just a feeling that I got.   

BR
/Hans H

---

From: "Jan Christoffersson (EPL)" <[email-masked]>
Date: Fri, 12 Apr 2002 11:54:22 +0200

Hi all,
some comments on the STATE_FREE discussion:

There seems to be no doubt that a STATE_FREE instruction would increase the flexibility of state management, since it would make it possible for the compressor to change the order in which the states are deleted once the state memory is full (perhaps because it realizes that the state about to be deleted is more useful than some other state further back in the deletion queue).

The important question is whether this flexibility is important enough to make changes in the draft. From my point of view this depends on how big the state memory is; can it store only three states then a STATE_FREE instruction would be very important. Can it store something like ten or more states then it is not very important.

Richard, would it require much changes in the draft to modify the END_MESSAGE instruction to change priority of an already saved state? (I assume this is the way to create a STATE_FREE instruction).

From my point of view I would prefer to have this possibility in SigComp.

Regards,
Jan C.

---

From: [email-masked]
Date: Fri, 12 Apr 2002 12:53:18 +0200

Hi,

> Hmm, so what you're after is a way to change the 
> state_retention_priority and not explicitly tell the 
> decompressor that "I'll not use this state anymore" but 
> rather change the priority and let the deletion rule still be 
> as it is. Then I think that this would not be a new 
> instruction but rather an evolvement of the END-MESSAGE 
> instruction. Hmm, such a feature could make it more 
> complicated for a compressor to know what states that are 
> actually established even when explicit acknowledgements are 
> used as described in [extended]. However, I'm not sure how 
> complex it would be it was just a feeling that I got.   

 Actually to the opposite :). It may have been brought up or even rejected earlier, but I could imagine state deletion like this: Compressor uses the STATE_FREE instruction whenever it thinks the state can be deleted. This way the memory does not have to fill up before removing any states, which would save some resources. As the compressor is aware of the state_memory_size it MUST NOT create a state that he knows it would not fit into the memory and remove some states beforehand. It may have some problem with message reordering and late acknowledgements (the comp. falsely thinks the memory is full/not full), but so does the other solution. In this case a cautious compressor could spare some memory for that purpose, but with automatic deletion the compressor must assume what could have happened at the other side. Correct me if I am wong.

 From the implementation point of view I feel it is more complicated to mirror the decompressor (even more if we change priorities) than telling it what to do.

 The effort to be change the draft: New instruction STATE_FREE, possibly removing the automatic state deletion, describing all this.

Regards,
Robert

---

From: [email-masked]
Date: Fri, 12 Apr 2002 15:19:51 -0500

> From my point 
> of view this depends on how big the state memory is; can it 
> store only three states then a STATE_FREE instruction would 
> be very important. Can it store something like ten or more 
> states then it is not very important.

Then that seems to say we need STATE_FREE at least for the
first case (e.g. for some low end terminals).
 
> Richard, would it require much changes in the draft to modify 
> the END_MESSAGE instruction to change priority of an already 
> saved state? (I assume this is the way to create a STATE_FREE 
> instruction).

Sorry, I don't get it. STATE_FREE instruction has nothing to
do with priority (how it is used together with priority is
another issue). It simply says "I'm not going to use this 
state anymore". The receiver of the instruction doesn't 
even look at the priority at all. What does it buy us
to change the state priority to the lowest value and then 
delete it instead of a straightforward STATE_FREE instruction?

Zhigang

---

From: [email-masked]
Date: Fri, 12 Apr 2002 16:09:23 -0500

> as it is. 

Hans,

Sorry, I wasn't clear. What I described is one example to use
STATE_FREE instruction. STATE_FREE does mean that "I'll not
use this state anymore". This is independent of state priority.

Robert already explained it pretty well: "This way the memory 
does not have to fill up before removing any states". The point
is that there is something a compressor can do with STATE_FREE,
but not with priority. Of course, a compressor can feel free
to consume all the memory allocated to it. But on the other
hand, we should give it a chance to be nicer (to the receiving
sigcomp) if it wants to. 

One additional point: I don't think priority approach and 
STATE_FREE is mutual exclusive. And I don't think they have
to be bundled together. Both have their own merit and we
should give implementer the freedom. Having said good words 
on STATE_FREE, the priority approach may be more efficient 
since you can use small amount of bits (for priority) 
per message to control the deletion. That can also be done
via STATE_FREE, but in a trickier way. E.g. you refer to one
state (cost you >= 6 bytes) that contains hash values
of other states; then in the sigcomp message, you only need 
to send a few bits to tell which one of the states you
want to apply STATE_FREE. This avoids sending additional
state_ID in the message, but needs a bit more complicated UDVM
code.

Zhigang

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Mon, 15 Apr 2002 12:14:12 +0200

> 
>  The effort to be change the draft: New instruction 
> STATE_FREE, possibly removing the automatic state deletion, 
> describing all this.

As a last resort in case of message loss/misordering SigComp should have the automatic state deletion.

BR
/Hans H

---

From: [email-masked]
Date: Mon, 15 Apr 2002 09:44:44 -0500

> The functionality of the STATE-FREE is: "The compressor using 
> the STATE-FREE instruction tells its remote decomressor that 
> this state will not be used anymore."

Correct.
 
> What does the decompressor do when it encounters the 
> STATE-FREE instruction?

Actually, it is the state handler that handles the request
(like the state creation request). It performs following steps:

1) check if the compressor has requested to create the 
state to be freed in the past. If not, invalid STATE_FREE,
stop.
2) deduct the size of the freed state from the state_memory
size for the compressor
3) decrement the counter associated with the freed state by 1. 
(Note, the counter of a state is incremented whenever a compressor
requests to create a state that has already been created)
4) if the counter reaches 0, physically delete the state.

BR,
Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Mon, 15 Apr 2002 17:08:34 +0100

> Should the STATE-FREE instruction also be taken to mean that: 
> "After deletion of the indicate state the decompressor's 
> allocated state_memory for the compressor is reduced with the 
> size of the deleted state" ?

Hi,

I believe that Hans has pinpointed the key issue when discussing
the STATE-FREE instruction. We need to decide how STATE-FREE is
intended to be used so that we can determine whether it is the
best tool for the job, or whether we can provide the same
functionality more efficiently and with fewer changes to the
draft.

So far, two reasons have been mentioned as to why we might need
STATE-FREE in SigComp-06:

1. A compressor could use STATE-FREE to replace a state that it
   no longer requires with a new state.

2. A compressor could indicate that it wishes to use less memory
   than the state_memory_size it has been allocated.

Both of the above may be useful in certain scenarios, although in
each case there are alternative mechanisms that could be used to
provide the same functionality with a higher compression ratio:

We can provide the functionality of 1 by using the state priority
mechanism (possibly adding the ability to change state priorities
on the fly). The compression ratio is higher than with STATE-FREE
because it is not necessary to send a 6-byte hash to explicitly
reference a state that needs to be deleted.

We can provide the functionality of 2 by allowing the compressor
to announce exactly how much state memory it wishes to use (up to
the maximum state_memory_size imposed by the decompressor). This
saves the 6-byte hash overhead as before.

I'd be interested to hear comments on this assessment of the
situation. Do the alternatives I mentioned provide the same level
of functionality as STATE-FREE, or is there another reason that
the instruction should be included?

Regards,

Richard

---

From: [email-masked]
Date: Mon, 15 Apr 2002 23:48:53 -0500

>    no longer requires with a new state.

STATE-FREE is simply to allow the compressor to say "I'm not going
to use a state I created before". The freed space may or may not
be used later by a new state. IMHO, STATE-FREE is simply the
natural brother of state creation, exactly like the pair we have 
for memory management: malloc() and free().
 
>    than the state_memory_size it has been allocated.

I'm not sure I understand "indicate" here. STATE-FREE is not to 
"indicate". It is not about changing the state_memmory_size. 
See above.

> reference a state that needs to be deleted.

That's not true. As I've pointed out my previous message, you don't 
need to send the 6-byte hash explicitly for STATE-FREE either. 

> the instruction should be included?

Well, with STATE-FREE, you can do something that you cannot do
with state priority. (Namely, you can free up some memory without
having to fill it up first.) It is not true in the other direction.  
I don't see STATE-FREE is anything less than state priority. 
Given this fact, I don't understand the strong objection here to 
include STATE-FREE. Did I miss anything?

BR,
Zhigang

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 16 Apr 2002 19:39:48 +0200

[Zhigang wrote:]
> be used later by a new state. 
...
> having to fill it up first.) 

Ok.

So my question is now do we need to specify what a reciever of a STATE-FREE request should do with this knowledge?
-If it does not affect the compressor in any way then I think not.
I.e. as Carsten put it "It MAY delete the state (in particular, it may be in use in another
c-d pairing = session, think "reference counting")".

BR
/Hans H

---

From: [email-masked]
Date: Tue, 16 Apr 2002 23:15:11 -0500

> So my question is now do we need to specify what a reciever 
> of a STATE-FREE request should do with this knowledge?

I answered this question in my email yesterday (see below). By
"reference counting", Carsten referst to the case where a compressor
request to create a state that already exists. It's a term
used in OOP to determin when a shared object can be safely physically
deleted.

(Note there is actually step 0 which is to authenticate the message
and find out which compressor sends the request. I omitted it as
it is common to a state creation request.)

BR,
Zhigang

----------------------

----------------------

---

From: [email-masked]
Date: Wed, 24 Apr 2002 17:53:46 -0500

> > 2) deduct the size of the freed state from the state_memory size for 
> > the compressor
> 
> This step, of course, is not executed if the state isn't still being
> referenced (maybe you meant this by "stop").

Yes (see below).

> Hmm, packet loss/retransmissions again.
> The counter should only be increased if the state has newly entered
> the set of state associated with this session/compartment.
> Repeated STATE-CREATE for the same session/compartment should 
> not count.

Good point. Now thinking along this line, perhaps counter is not a good
word to describe this. How about the following?

a) set(compartment-ID) = a set of states associated with this compartment

b) set(state-ID) = a set of compartment IDs that have requested to create
the state.

c) A valid request from compartment-ID cid to create state s will
trigger the following:   
    set(cid) <- set(cid) U {s}
    set(s) <- set(s) U {cid}

d) A valid request of STATE_FREE(s) from compartment-ID cid will 
trigger the following:
    set(cid) <- set(cid) - set(cid)^{s}
    set(s) <- set(s) - set(s)^{cid}

e) When set(s) is empty, the state s can be physically deleted.

Note: 'U' stands for union and '^' for intersection.

BR,
Zhigang