[rohc] Default Compression Algorithms

Kevan Hobbis <Kevan.Hobbis@hutchison3g.com> Wed, 27 February 2002 08:06 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 DAA13396 for <rohc-archive@odin.ietf.org>; Wed, 27 Feb 2002 03:06:54 -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 DAA00911; Wed, 27 Feb 2002 03:00:55 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00829 for <rohc@optimus.ietf.org>; Wed, 27 Feb 2002 03:00:49 -0500 (EST)
Received: from h3gshmsw1.hutchison3g.com (mail.hutchison3g.com [63.137.144.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13272 for <rohc@ietf.org>; Wed, 27 Feb 2002 03:00:45 -0500 (EST)
Received: from andromeda.h3guk.com (unverified) by h3gshmsw1.hutchison3g.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5953045f0e0af80e8271c@h3gshmsw1.hutchison3g.com> for <rohc@ietf.org>; Wed, 27 Feb 2002 08:01:24 +0000
Received: by andromeda.h3guk.com with Internet Mail Service (5.5.2653.19) id <FN9HTHTV>; Wed, 27 Feb 2002 08:01:30 -0000
Message-ID: <F3035F172B472247AED58C867616D0AB384799@RETICULUM.h3guk.com>
From: Kevan Hobbis <Kevan.Hobbis@hutchison3g.com>
To: rohc@ietf.org
Subject: [rohc] Default Compression Algorithms
Date: Wed, 27 Feb 2002 08:01:05 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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

Folks

I have been following this conversation and am not clear what the conclusion
was, but as one of the people who would like to see an ability to use a
default algorithm then I would like ask the following questions

1. An organisation could make their own decision on what the default
algorithm should be. It is not necessary to define it as part of sigcomp -
in fact my understanding is that sigcomp has no compression algorithms
defined within it anyway ?

2. Is there a compression algorithm that is not encumbered with IPR that
could be used as default ? Albeit that it might be simple and not as
effective as others.

3. 3GPP operators want to reduce the on-air traffic, and so acceptance of a
default algorithm would aid this, specifically if it required no negotiation
signalling i.e. a compressor can send a message compressed with the default
algorithm and indicate this in a header (or maybe if no indication is
received then the default is assumed) - the decompressor can then decompress
using the default. No negotiation or capability exchange is required. This
is how it would be a win for the radio interface. I got the impression that
this is possible within sigcomp, but it is not clear to me how it is done ?

4. If this is possible with the current specification then it is not clear -
at least not to me. In this respect, I think I saw a suggestion for a draft
that was an implementers guide that would explain such operation. This would
be very useful to me to aid my understanding, and wonder if it is something
that has merits for other reasons as well as default algorithm support ?

Thanks

Kevan Hobbis




_______________________________________________________________

If this email isn't for you then we'd be grateful if you could let our
helpdesk know there's been a mistake by putting 'received in 
error' in the subject box and sending it to helpdesk@hutchison3g.com. 
If it isn't for you, we're sure you'll understand that you're not 
allowed to copy, disclose or distribute any of its contents.  
This email is private and confidential and may also be privileged,
so if you shouldn't have received it, we'd be grateful if you could delete it.
Thanks.
________________________________________________________________


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc