RE: [rohc] Default decompression algorithms

"Price, Richard" <richard.price@roke.co.uk> Thu, 21 February 2002 18:01 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26872 for <rohc-archive@odin.ietf.org>; Thu, 21 Feb 2002 13:01:30 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15249; Thu, 21 Feb 2002 12:58:51 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA15222 for <rohc@optimus.ietf.org>; Thu, 21 Feb 2002 12:58:49 -0500 (EST)
Received: from rsys000a.roke.co.uk (rsys000a.roke.co.uk [193.118.201.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26704 for <rohc@ietf.org>; Thu, 21 Feb 2002 12:58:47 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1S9WNNRX>; Thu, 21 Feb 2002 17:56:51 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4186F9FD4@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Abbie Barbir'" <abbieb@nortelnetworks.com>, "'Lars-Erik Jonsson (EPL)'" <Lars-Erik.Jonsson@epl.ericsson.se>, "Conroy, Lawrence (SMTP)" <lwc@roke.co.uk>
Cc: rohc@ietf.org
Subject: RE: [rohc] Default decompression algorithms
Date: Thu, 21 Feb 2002 17:56:50 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Sender: rohc-admin@ietf.org
Errors-To: rohc-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Robust Header Compression <rohc.ietf.org>
X-BeenThere: rohc@ietf.org

------------------- SNIP SNIP 
> 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. 
> 
-------------- 
> Can you suggest how this would be done (implemented) from the compressor end. 
> abbie

Hi,

There are quite a few issues that the compressor will need to consider when
judging overall performance, including some or all of the following metrics:

1   Compression ratio

2   Processing efficiency

3   Memory efficiency

4   Implementation effort

5   IPR considerations

The IPR considerations are particularly important, since encumbered algorithms
tend to substantially outperform unencumbered algorithms in terms of metrics
1, 2, and 3.

So if a compressor has licensed the bytecode for an encumbered algorithm, it
is usually preferable to download this bytecode to a decompressor that does
not support the encumbered algorithm, rather than picking one of the weaker
unencumbered algorithms already available at the decompressor.

Regards,

Richard Price