Subject: [rohc] Regarding length of each state item

From: suman <[email-masked]>
Date: Wed, 21 Apr 2004 11:17:22 +0530

Section 6.2 of rfc 3320 states the following...

"   As well as storing the state items themselves, the state handler
   maintains a list of the state items created by a particular
   compartment and ensures that no compartment exceeds its allocated
   state_memory_size.  For the purpose of calculation, each state item
   is considered to cost (state_length + 64) bytes."

I am not able to get the significance of this magic number "64 bytes " ...

what is the purpose of adding these 64 bytes to the state length ?

could anybody throw light on this ?

thanks
suman

---

From: "Richard Price" <[email-masked]>
Date: Wed, 21 Apr 2004 17:57:32 +0100

Hi Suman,

The "magic number" of 64 bytes is referring to the amount
of state memory required to store each state item. This
defines the behaviour of the UDVM as it appears to the
outside world. For example, if the remote endpoint
requests 4 state items of size 400 bytes to be stored in
a compartment of 2048 bytes, then the amount of state
memory remaining must be 2048 - 4 x 464 = 192 bytes.

Since the UDVM is a *virtual* machine, there is no need
to have a 1-1 mapping between state memory and
physical memory. Each state item costs (state_length + 64)
bytes of state memory to store, as perceived by the
bytecode running on the UDVM; however, the actual
amount of physical memory used to store the state
may be different. The important point to make sure of
is that the UDVM behaves as documented in RFC 3320.

Regards,

Richard

>From: suman <[email-masked]>
>To: Richard Price <[email-masked]>, [email-masked]
>Subject: Re: [rohc] Regarding length of each state item
>Date: Wed, 21 Apr 2004 18:31:51 +0530
>
>Hi Richard,
>
>As per your explanation, it is clear that the magic number 64
>is implementation specific.( the way the state item is organized
>in the database.).
>
>so I think the rule stated in section 6.2 or rfc 3320 does not carry
>much weightage if the implementation has a different strategy.
>( 64 could be different for different implementations..)
>
>" If the state creation request needs more state memory than the
>       total state_memory_size for the compartment, the state handler
>       deletes all but the first (state_memory_size - 64) bytes from the
>       state_value.  It sets the state_length to (state_memory_size -
>       64), and recalculates the state_identifier as defined in Section
>       9.4.9."
>
>any comments on this  ?
>
>thanks
>suman
>----- Original Message -----
>From: "Richard Price" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Wednesday, April 21, 2004 5:57 PM
>Subject: RE: [rohc] Regarding length of each state item
>
>
> > Suman,
> >
> > The additional 64 bytes is to take into account the cost
> > of storing the state_identifier, state_length, state_address,
> > state_instruction and minimum_access_length which are also
> > required as part of a state item, as well as the cost of
> > storing some kind of hashing table to provide quick access
> > to the states.
> >
> > 64 bytes is a generous estimate of the additional cost of
> > storing each state item: efficient implementations may be
> > able to get away with less than this.
> >
> > Regards,
> >
> > Richard
> >
> >
> > >From: suman <[email-masked]>
> > >To: [email-masked]
> > >Subject: [rohc] Regarding length of each state item
> > >Date: Wed, 21 Apr 2004 11:17:22 +0530
> > >
> > _________________________________________________________________
> > Express yourself with cool emoticons - download MSN Messenger today!
> > http://www.msn.co.uk/messenger
> >
> >
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
>

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger

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