Subject: RE: [rohc] SigComp Compartments Memory Managment

From: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
Date: Wed, 28 Jan 2004 13:23:32 +0100

Hi,

In the second example, S1 (64000 bytes) would empty (delete S0) the state memory regardless its priority that affects only the order in which the already saved states should be removed. So the statements are true, but a little confusing, in my opinion.

Though these examples, no doubt, will help in understanding the state removal meschanism, they don't say anything about the purpose and usage of the truncation. I can give you a fairly straightforward example:

If you're going to save a state whithout knowing the state memory size of the other endpoint, with state truncation, you have the chance trying to save a state bigger than the default state memory size. Together with the acknowledgment of this state or even before, the other endpoint might advertise its parameters, and you can decide how much of your state was actually saved. (As parameter advertisement is optional, you may end up with an ack but not knowing the remote state memory size. In such a case, you should not use the saved state at all, as an ack in itself doesn't mean successful state save. If you should refer to an invalid state ID later, that means decompression failure, which you must avoid!) Without this feature, a big state would not be saved at all, and you should wait for a message from the other endpoint before saving anything there, causing a latency in the compression efficiency improvement (supposing we can compress a message better with a state than wit!
 hout, which is not always true ;-).

BR/Zacco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Pekka Pessi
Sent: Wednesday, January 28, 2004 11:41 AM
To: John Smith
Cc: [email-masked]
Subject: Re: [rohc] SigComp Compartments Memory Managment

John Smith <[email-masked]> writes:
>What does it mean? It seems to make no sense by itself?
>How is it used? For what purpose?
>Does it have to do with some specific mechanism of memory book-keeping in
>the compressor ?

Only thing I can imagine is to make sure that there are no state
items with higher priority in the compartment. 

So, if you have a sms=8192, you have state item S0 size=4000
priority=100 and you insert a state item S2 size=3000 p=10, then
state item S3 s=2000 p=10, the S3 pushes away S2. If you insert S1
size=64000 priority=0 before S2, S3 pushes away S1, not S2.

--Pekka

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

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