Subject: RE: [rohc] Avoiding Shared Identifier (Sigcomp Extended -02)

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Thu, 21 Mar 2002 23:00:49 +0100

Hi, 

see inline,

> I assume from the definition of shared identifier that 
> two sigcomp entities could share a state while 
> compressing/decompressing a message. The example in the 
> extended draft-02 specifies a format for sending shared id as 
> well as ack id (through s,a,r,b bits). 

A compressor may save a state corresponding to the uncompressed 
version of the application message that is next to be 
compressed and sent. This is referred to as the shared state in 
shared compression.
 
> Q1)  When a compressor1  on one end sends a compressed 
> message , m,  to the other side (decompressor2) by setting s 
> bit (shared compression), i assume that shared identifier is 
> calculated over the uncompressed version of message 'M' 
> through some hash function. If that is the case, do we really 
> need to send shared identifier to decompressor2? 

No, this is not the way it should be done either. 
Compressor_A should set the 'r-bit' to indicate to endpoint_B that
an uncompressed version of this message is saved at endpoint_A and
can be retrieved by the UDVM at endpoint_A. 

The 's-bit' in the example header is set to indicate to the remote
UDVM that a shared_id is included in the message. A compressor should
only include the shared_id if it has used it for compression of the
current SigComp message. Thus, the shared_id is only a reference to 
a state that the UDVM will include in the decompression process using 
e.g. the STATE-REFERENCE instruction.

See also the slides from the ROHC-meeting-IETF53, slide: 59 - 67 explains 
this. The 'r-bit' is the "I was remember indication". 
The 's-bit' is merely a way for helping the UDVM to parse the message. 
It is up to your implementation to define how your SigComp messages will 
look like after the first few bytes that are defined in SigComp basic.

> Can't the 
> decompressor2 calculate the shared identifier from the 
> decompressed message and inform compressor2 about the new 
> state which intun could use it if required. 

Yes, this is the way it is supposed to be done, and will be explained in 
more detail in SigComp-extended-03.

> In that case, we 
> only need a bit to indicate that an uncompressed version of 
> compressed message could be used as state reference.  

Yes, this is why we have the example of the 'r-bit'

> Q2) How does the compressor1 know that an uncompressed 
> version of compressed message could be used as shared state. 
> Does the application inform the sigcomp?

SigComp does not define anything about the compressor operation. It
is up to your implementation. Your implementation must of course be sure
that a shared state can be retrieved by the corresponding UDVM before
sending the indication.
 
> Q3) Also, the draft doesn't specify how long the states 
> created by the compressor and not yet acknowledged by the 
> decompressor should be saved. 

There are two answers to this question depending on which states
you refer to. So, if I may I'll ask them:

Q3-1) How long will a state-handler keep an "ordinary" state, 
i.e. not shared state, which is saved by the compressor?

A3-1: This is up to your implementation. As deletion of these types of
states saved by the compressor will not effect the robustness of the 
scheme. If a compressor receives an acknowledgement for a state it has
deleted, then too bad. The only effect this may have is a non-increase
of the compression ratio.

Q3-2) How long will a state-handler keep a shared state?

A3-2: My simple answer, a compressor should not save more shared states
than it has memory for to avoid decompression failure. However,
as there will be a STATE-FREE instruction in the next version of SigComp
(version- 06), this instruction may be used by the remote compressor to 
indicate that some shared states may be deleted as it will no longer make 
use of them. 

> Q4) Does the max_state_size application defined parameter has 
> any effect on the shared identifier? 
> I mean how long the 
> compressor1 has to store the new state for sharing? 

No, at least not for how SigComp works. It will of course put a 
constrain on how much memory that is available for the compressor to save
states.

> Q5) Do we have any limit on the maximum shared size ?

No.
It is strictly up to your implementation how much memory it will allocate
for the compressor to save states.

BR
/Hans H

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

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

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 21 Mar 2002 23:10:36 +0100

> for the compressor to save states.

Well, first of all, the size of one piece of state is limited by the UDVM
size (64K max).

But I actually read the question differently: "How can I limit the amount of
state that the other guy burdens me with?".

In Minneapolis, we proposed adding a "maximum state size" announcement
parameter which would be used to define that limit.

Gruesse, Carsten