[rohc] Default decompression algorithms

["Price, Richard" <[e-mail]>]

> > In all cases in my previous posting, I was talking only about
> > ->DECOMPRESSION<- algorithm support (default or otherwise).
> > 
> > I had assumed that choosing a default decompression algorithm
> > was still ongoing - Is there strong disagreement that there
> > should be one (albeit *which* one is still under consideration)?

Hi Lars-Erik and Lawrence,

To help us decide whether "default" decompression algorithms should be
included within SigComp, we need to understand the advantages of the UDVM
approach and whether we would be negating them somehow by standardising
default algorithms.

The overall SigComp solution determines which compression algorithm to use
by the following process:

1   Decompressor announces its available resources to the compressor.

2   Compressor makes a choice about how best to use these resources.

In a typical compression scheme the "resources" offered by the decompressor
would be a list of supported algorithms; the compressor could then select
any algorithm supported by both itself and by the decompressor. Clearly a
mandatory default algorithm must be supported at both ends, so that at least
one algorithm is always available for the compressor to use.

With the UDVM approach the "resources" offered by the decompressor are its
available memory and processing power, the minimum acceptable compression
ratio etc. The compressor has freedom to use any algorithm it likes,
provided that it can be downloaded and run at the decompressor using only
the offered resources.

Of course, there is nothing to stop the decompressor from offering both types
of resources to the compressor (memory, processing power and a selection of
well-known algorithms). The compressor can then choose between downloading a
new algorithm and using one of the algorithms already available at the
decompressor.

> By defining the UDVM, we do not need to standardize the decompression
> algorithms, but if we start this over again I think we may start
> questioning the UDVM approach.

Making one or more of these well-known algorithms mandatory at the
decompressor doesn't contradict the UDVM approach because the decision on
which algorithm to use (or whether to download a new one) is still made by
the compressor. So we have a "win-win" situation; the compressor downloads
a new algorithm to the decompressor when it judges the overall performance
to be better than using one of the existing algorithms.

The cost of making an algorithm mandatory is that (read-only) memory needs
to be provided to store the code for the algorithm, plus any additional
IPR claims that are introduced by supporting the algorithm.

> The major argument for defining the UDVM was to avoid this discussion
> about decompressor algorithms.

In my opinion the major argument for the UDVM is its technical performance!
A downloaded UDVM algorithm can be tailored precisely to compress the
output of one particular SIP implementation, which gives a significantly
improved compression ratio compared to even an algorithm designed for
"generic SIP".

I certainly don't want to give the impression that the UDVM approach is a
compromise due to time pressure, or has inferior performance in any way to
the conventional approach of offering a list of well-known algorithms. I
would be very happy to include both approaches in the SigComp solution and
leave the decision on which to use to the compressor.

> Especially if we start to discuss requiring a "default algorithm", I
> think we are once again opening a can of worms.

The term "default decompression algorithm" is probably misleading, because
more than one algorithm can be supported as mandatory. I don't think that
this opens a can of worms since there is no need to favour one algorithm
over any other - the more we support at the decompressor the better.

One final thought: in the current SigComp draft the list of mandatory and
optional well-known algorithms is currently part of the "application-
defined parameters". Therefore we only need to make recommendations about
what this list should contain; the final decision is made by particular
applications such as SIP. So for the wireless environment 3GPP will be
able to choose their own list of mandatory and optional algorithms.

Regards,

Richard