[rohc] decompression code announcement (was RE: Default decompression algorithms)

[[e-mail]]

Hi,

Below is a quick write-up I promised earlier. Comments welcome.

BR,
Zhigang

=============================================================

Decompression code announcement
-------------------------------

During normal SigComp operation, a compressor needs to
send the decompression code consisting of UDVM instructions
to its peer decompressor before any message can be decompressed.
The overhead of sending the code may be undesirable in wireless
environment, which is the major application of SigComp.
Following outlines an optimization that reduces such overhead.

1) It is assumed that a compressor (or application) contacts 
its peer decompressor (or application) before applying SigComp
to compress messages, e.g., during negotiation of the use of
SigComp. (See note c).)

2) When the decompressor (or application) replies to the compressor,
it can piggyback in the message a list of hash values of the 
decompression codes it already has (see note b) below).

3) Upon receiving such a list, the compressor compares the hash
values in the list with the one of the decompression code it wants
the decompressor to use. If a match is found (i.e. it's a hit), the 
compressor no longer needs to upload the code to the decompressor. 
If no match is found or the compressor would rather use a different 
decompression code, it will upload the code to the decompressor.

4) The decompression code announcement may contain empty list. 

Notes:

a) The decompressor may have a piece of decompression code in different
ways. Case 1 is that a decompressor supports a set of well-know 
algorithms whose decompression codes are documented. It can store the 
codes locally hoping the peer compressor is likely to use one of them. 
Case 2 is that a decompressor (e.g. in P-CSCF in 3GPP) may actively engaged
with multiple compressors (e.g. in mobiles) that use the same decompression 
code. Therefore, once the decompressor acquires one copy of the code
from one compressor, it can use the code announcement to avoid redundant
code uploading from other compressors later.

b) The hash value could be the constructed using the first n bytes of
MD5 hash over the decompression code. n should be large enough so that
collision probability is negligible in practice.

c) For step 2 above, the decompression code announcement could be done
in other ways, e.g. out-of-band or in a pre-configured way. Basically, 
it can be bundled together with the SigComp negotiation/discovery 
mechanism to avoid additional round trip delay.

d) In any case, if compressor does not expect a message from its
peer decompressor as it is assumed in step 1, it should always 
follow the default procedure to upload the decompression code. 

e) Obviously, the mechanism gives benefits only when the hit probability
is high. If a decompressor is not confident about that, it can always
send empty list in the announcement or does not send the announcement
at all if the compressor does not expect its message.
=====================================================================

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