Subject: RE: [rohc] SigComp state creation and the state retention priorit y

From: "Surtees, Abigail" <[email-masked]>
Date: Wed, 20 Apr 2005 17:23:57 +0100

Hi  Jean-Pierre,
 
You are correct that a newer piece of low priority state can push out an older piece of high priority state.  It does indeed mean that a compressor must be careful with both priority and order of state creation requests.  I'm afraid I don't recall what the motivation for this was.
 
Best regards,
 
Abbie

-----Original Message-----
From: Lepine, Jean-Pierre [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2005 1:31 PM
To: [email-masked]
Subject: [rohc] SigComp state creation and the state retention priority

Hi everybody,
 
I sent the following email almost 2 weeks ago but I didn't get any feedback on it.
I would really appreciate a follow-up on this.
Thanks.
 
-----Message d'origine-----
De : Lepine, Jean-Pierre 
Envoyé : 31 mars, 2005 08:58
À : [email-masked]
Objet : SigComp state creation and the state retention priority

Hi all,
 
I would just like to confirm something regarding SigComp state creation and the state retention priority.
 
Initially, I thought that trying to create a state item in a compartment could NEVER push state items with a higher priority out of the compartment. In particular, suppose a compartment uses its full amount of SMS with state items of priority 1, I thought that trying to create a state item with priority 0 would fail without any effect on the compartment's content.
 
However, after reviewing RFC 3320, I now understand that for the above example, one or more state items of priority 1 MUST be pushed out of the compartment (freed) until enough memory is available to create the state item of priority 0. More generally, a state item with a given priority, even the highest, CAN be pushed out of a compartment by the creation of state items with lower priorities. In other words, a newer state item is considered more important than an older state item, even if the older one has a higher priority.
 
Am I right ?
 
If so, I guess there are some key motivations behind this design choice but I don't really see them. I find this to be not very practical as a compressor must be careful not only with the chosen state priorities, but also with the order of state creation requests. 

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