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

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

Hi,

Just to see whether I've understood:

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

What does the decompressor do when it encounters the STATE-FREE instruction?
a) It MUST delete the indicated state?
b) It MAY delete the indicated state?

One more thing.
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" ?

BR
/Hans H

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: den 12 april 2002 23:09
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [rohc] sigcomp issue sugar-5/cabo-8
> 
> 
> > 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. 
> 
> 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
> 
> 

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

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 15 Apr 2002 17:14:05 +0200

"Hans Hannu (EPL)" <[email-masked]> writes:

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

... by this compressor (as identified by its session identifier on the
decompressor side).  This may be a fine point, but important.

[[There is an ugly little thing hiding here -- the compressors view of
the state memory consumed hinges on the ability of the decompressor's
application to separate sessions; the inverse is not a problem,
fortunately; so the app should err on the side of using too many
different session IDs, security permitting.  Worth noting.]]

> b) It MAY delete the indicated state?

It MAY delete the state (in particular, it may be in use in another
c-d pairing = session, think "reference counting").

> One more thing.
> 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" ?

Yes (which makes the "MAY" above a bit less "MAY" and more "MUST", of
course.)

Gruesse, Carsten