Subject: [rohc] sigcomp issue lejo-8

From: "Price, Richard" <[email-masked]>
Date: Tue, 16 Apr 2002 14:33:26 +0100

> Strange UDVM lifetime
>
> Why is the UDVM kept alive during the application decision to supply a
> compartment ID?
>
> This defines a protracted multi-step interface, which tends
> to unnecessarily extend the UDVM lifetime.  While all this is a local
> implementation issue, the text should not give the impression the UDVM
> (and its memory) needs to be around longer than during its own runtime.

Hi,

The UDVM memory does need to be around until the session ID is returned
by the application. The state item that the UDVM wants to create needs to
be stored somewhere, and for simple algorithms (certainly all that I've
written so far) the state item is around 95% of the total UDVM memory.

We can't free up the per-message memory until a session ID is returned
(at which point we can use the per-session memory instead).

Regards,

Richard

P.S. I suppose that advanced implementations might be able to reclaim
part of the UDVM memory before the session ID is returned (namely whatever
is not being used to store the state item). However I think this will be
an obvious step for anyone writing a heavily optimized UDVM.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 4:05 PM
> To: [email-masked]
> Cc: Lars-Erik Jonsson (EPL); Price, Richard; 
> [email-masked]';
> Jan Christoffersson (EPL); Hans Hannu (EPL)
> Subject: Re: SigComp : draft-dependency...
> 
> 
> ROHCers,
> sigcomp authors,
> 
> a revised issues list, together with some random comments from me, as
> well as a working draft (in nroff form, with a makefile) are now at
> the sigcomp CVS site,
> 
> http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/udvm/
> 
> Note that the views expressed in the issues list and the "changes"
> random comments are my own, although I have stolen text liberally from
> Hans' list and from mailing list comments.
> 
> I do propose that we take the resolutions indicated in the issues
> list, and I also would like to resolve the issues I have marked
> "further discussion required" (which should not be too hard).
> 
> Gruesse, Carsten
>

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 16 Apr 2002 15:47:15 +0200

> written so far) the state item is around 95% of the total UDVM memory.

My (possibly slightly more abstract) mental model is that the output
message plus the parameters of the END-MESSAGE stay around while the
app is interrogated.  Not the UDVM.

Now, as an optimization, you may want to keep the UDVM core around to
avoid the copying, but I would not want that optimization in the
model.  In the model, the UDVM dies with END-MESSAGE.

Gruesse, Carsten

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