Subject: Re: [rohc] Use of UDVM registers 6 to 9

From: "Richard Price" <[email-masked]>
Date: Fri, 21 May 2004 12:10:25 +0100

Hi,

Yes, the first 32 bytes of the UDVM memory correspond to the bytecode
which will be loaded at the UDVM startup. The partial_state_id_length
and the state_length are used in the case where the bytecode is
loaded from a state: they are set to the length of the state ID used
to access the state, and to the length of the state which is accessed
respectively.

When the bytecode is uploaded as part of the SigComp message,
the partial_state_id_length and the state_length are both initialised
to 0.

Regards,

Richard

>From: sasidhar <[email-masked]>
>Reply-To: sasidhar <[email-masked]>
>To: Richard Price <[email-masked]>
>CC: [email-masked]
>Subject: Re: [rohc] Use of UDVM registers 6 to 9
>Date: Fri, 21 May 2004 10:51:27 +0530
>
>Hi,
>     If these first 32 bytes of the UDVM are set only at the startup, do 
>they correspond to the bytecode which will be loaded at the UDVM startup? 
>And then what is the use of the partial_state_ID_length and state_length.
>     Please clarify this.
>
>with regards,
>Sasidhar
>
>----- Original Message -----
>From: "Richard Price" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Cc: <[email-masked]>
>Sent: Thursday, May 20, 2004 9:57 PM
>Subject: RE: [rohc] Use of UDVM registers 6 to 9
>
>
> > Hi,
> >
> > The first 32 bytes are only set at UDVM startup; there is no
> > special significance to this memory area afterwards.  This
> > means that the UDVM bytecode is free to use these locations
> > for any other purpose a memory location might be used for; it
> > just has to be aware they are not necessarily initialized to zero.
> >
> > Regards,
> >
> > Richard
> >
> >
> > >From: suman <[email-masked]>
> > >To: [email-masked]
> > >CC: "Lajos Zaccomer (IJ/ETH)" <[email-masked]>
> > >Subject: [rohc] Use of UDVM registers 6 to 9
> > >Date: Thu, 20 May 2004 18:47:20 +0530
> > >
> > >Section 7.2 of rfc 3320 describes the format of the first 32 bytes in 
>UDVM
> > >memory.
> > >
> > >"  Addresses 6 to 9 are initialized to the length of the partial state
> > >    identifier, followed by the state_length from the retrieved state
> > >    item. "
> > >
> > >Does it mean that the state_length will be updated with the 
>state_length of
> > >the
> > >state item for which a STATE-ACCESS/STATE-CREATE instruction is 
>executed ?
> > >
> > >Just rephrasing the above statement with an example..
> > >
> > >if a STATE-CREATE instruction is executed for a state-item whose
> > >state-length is 300 bytes,
> > >will the value of registers, 8-9 in UDVM be loaded with 300. Will this 
>be
> > >done by state handler ??
> > >
> > >Please confirm,
> > >
> > >thanks
> > >suman
> > >
> > >
> > >_______________________________________________
> > >Rohc mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/rohc
> >
> > _________________________________________________________________
> > Want to block unwanted pop-ups? Download the free MSN Toolbar now!
> > http://toolbar.msn.co.uk/
> >
> >
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc

_________________________________________________________________
Get a FREE connection, FREE modem and one month's FREE line rental, plus a 
US or European flight when you sign up for BT Broadband!  
http://www.msn.co.uk/specials/btbroadband

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

---

From: sasidhar <[email-masked]>
Date: Fri, 21 May 2004 18:07:02 +0530

Hi,
    As per my understanding, this state_length is to effectively use the
UDVM memory, instead of fixing some part of it for the bytecode. So we can
start loading the states from the position at which the bytecode ends. This
is also useful to decide whether to save the bytecode or not.
    But as Suman said, it would have been very useful, if the state-length
of the accessed state is written at some reserved space in the UDVM. This
will avoid the burden of carrying the state-length in every compressed
message.

with regards,
Sasidhar

---

From: suman <[email-masked]>
Date: Sun, 23 May 2004 13:39:19 +0530

Hi,

the rules specified in 3320 for memory management in state handler seems a
bit confusing to me..

   Consider a scenario where a compartment has an allocated sms of 2048
bytes.
Currently there are 3 states with the following sizes.

state 1: (length -256 bytes), (state retention priority 65535)
state 2: (length -512 bytes), (state retention priority 1)
state 3: (length -512 bytes), (state retention priority 4)

Now if a new state create request is received whose length is 1536 bytes,
and
its state retention priority is 3, what is the expected result ??

case1: Delete  the states with priority 65535, 1, 2, and 4 to accomodate the
new state.

case 2: Delete only the states with priority 65535, 1 and 2 and check if the
memory
accomodates the new state creation request. if so, accept the STATE-CREATE
request,
else reject it.

which of the above two is the correct answer ??

please confirm,

thanks
suman

---

From: suman <[email-masked]>
Date: Sun, 23 May 2004 16:27:40 +0530

Hi,

There was some documentation error in my previous mail.
I am sending it again ...

   Consider a scenario where a compartment has an allocated sms of 2048
bytes.
Currently there are 3 states created by remote endpoint with the following
sizes.

case1: Delete  the states with priority 65535,  1 and 4 to accomodate the
new state with retention priority 3.

case 2: Delete only the states with priority 65535 and 1 and check if the
remaining
memory accomodates the new state creation request. if so, accept the
STATE-CREATE
request, else reject it.

if case 1, is the correct answer, does it mean that a new state creation
request with
higher statelength can replace all existing states although its retention
priority is less than
those of the existing states.

if case 2, is the correct answer, does it mean that a new state creation
request will be
accomodated only by replacing only the states of lower retention priority
...the existing
states with higher retention priority will be left untouched..

please confirm,

thanks
suman