Subject: [rohc] sigcomp issue cabo-11

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 16 Apr 2002 19:18:28 +0200

Hi,

> It would be possible to put the message size in low memory,
> as we do with state_length.

> Action

> (decide whether to use low memory)

Would the suggested action cause any problems? 
If not why not just go ahead and use the lower memory if that would avoid a loop.

BR
/Hans H

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

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Wed, 17 Apr 2002 09:28:21 +0200

> Actually, I believe all remnants of text about UDVMs staying active
> while waiting for external events should be removed from the document.
> (Ceterum censeo...)

Does this imply anything to the "SigComp solution" or is the current text regarding this (see also sigcomp issue lejo-8) just there to optimise implementations?

> PS.: Oh, the name INPUT-BYTECODE has become quite misleading now.
> How about INPUT-BYTES?
> (Or INPUT-OCTETS, if it must be :-)

I think INPUT-OCTETS would be clearer.

BR
/Hans H

---

From: [email-masked]
Date: Wed, 17 Apr 2002 10:28:00 -0500

> I think INPUT-OCTETS would be clearer.

Me too. (It seems at least we're able to reach consensus 
on this name since Richard is fine with either one.)

Sorry for dragging on this kind of trivial issues, but should 
we then change the "INPUT-FIXED" to "INPUT-BITS"? Or
there is a reason to have "FIXED" there?

Zhigang

---

From: "Jan Christoffersson (EPL)" <[email-masked]>
Date: Tue, 23 Apr 2002 16:12:41 +0200

Carsten,
from (part of) Richards answer to your suggestion in cabo-11 it seems as this issue can be closed. Is this correct or are there still outstanding questions with this issue?
/Jan

> > We could bridge the gap by providing a "push" delimiter in the record
> > marking scheme; this would make it clear that the compressor relies on
> > the "persistent UDVM" model and that the UDVM needs to be started with
> > the data up to the push.

> I believe that the functionality of a "push" delimiter can already be
> provided using the INPUT instructions.

---

From: [email-masked]
Date: Wed, 24 Apr 2002 12:15:00 -0500

> My current assumption is that this will depend on the 
> application security mechanism. If security is provided by the 
> application itself then I expect one SigComp session to map onto 
> exactly one application session (snip)

Why? According to your proposed text, states will be deleted 
(well, if the reference_count == 0) at the end of a SigComp 
session. So, the above means that the states created by one
application session cannot be used later in another application
session.

Actually, this is one reason I don't like the introduction of 
term "session" in pre-06 text. Its introduction leads to the
additions of "per-session" text everywhere, which IMO is 
implementation issue and need not be specified in SigComp.

I prefer the term "compartment" as proposed by Carsten which
captures precisely the issues here, i.e. memory management
and identifying the receiver of a feedback. More important,
its meaning is confined to space dimension and does not spill 
over to the time dimension (which again looks an implementation 
issue to me).

BR,
Zhigang