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

From: [email-masked]
Date: Thu, 21 Mar 2002 13:43:01 -0600

Hi,
     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). 

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? 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. In that case, we only need a bit to indicate that an uncompressed version of compressed message could be used as state reference.  

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?

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. 

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? 

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

thanks,
Narendra

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