Subject: [rohc] SigComp States

From: "John Smith" <[email-masked]>
Date: Sun, 02 Nov 2003 05:50:37 +0000

I'm studying now SigComp and wondering about some issues:

(1) Quoting from draft-ietf-roch-sigcomp-sip-00.txt (section 3): “Usually, 
any states created during the lifetime of a compartment will be "logically" 
deleted when the compartment is closed. A logical deletion becomes a 
physical one when all the compartments that created the (same) state are 
closed.”  When do compartments share the same state? When do different 
compartments become related to the same state?

(2) Quoting from RFC 3320 (section 6.2): “Each instance of the UDVM can pass 
up to four state creation requests to the state handler…” Why does a UDVM 
need more than a single allocated state item?

(3) Continuing the quote from the previous question: “When the state handler 
receives a state creation request from the UDVM it takes the following 
steps: …  3. If the state creation request contains a state_identifier that 
already exists…” Is there any clear example to this kind of situation?

I would appreciate any piece of information.

Thanks,
John.

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus

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

---

From: "West, Mark" <[email-masked]>
Date: Sun, 2 Nov 2003 22:12:10 +0000 (GMT Standard Time)

Hi John,

> compartments become related to the same state?

Think about bytecode or an implementation-specific dictionary -- all
instances of that particular implementation could create the same piece of
state or states.  (My bytecode might save itself; all end-points running
this code will do the same thing).

> need more than a single allocated state item?

Again, think about saving bytecode or some non-standard (but
cross-compartment) dictionary as well as the circular buffer.  It is easy
to consider examples where 2 or more states are created in response to a
single message.

You should also never lose sight of the fact that 3320 defines the
decompressor.  We neither know, nor particularly want to constrain, what
compression algorithms can be implemented.  4 state creation requests seem
to allow enough latitude...

> already exists…” Is there any clear example to this kind of situation?

If one instance of an endpoint has created a piece of state (e.g.
bytecode) the state will have a specific state identifier.  If another
instance creates the same piece of state it will have the same state
identifier (obviously).  This should be allowed to succeed (and will
create the 'multiple compartments referencing the same state' of your
first question).  However, if some endpoint created a different piece of
state that happened to have the same state identifier (i.e. a hash
collision), the state creation must fail (otherwise we would have an
ambiguity in accessing state).

Cheers,

Mark.

-- 
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433