RE: [rohc] Default decompression algorithms

"Price, Richard" <richard.price@roke.co.uk> Thu, 21 February 2002 14:28 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 JAA18223 for <rohc-archive@odin.ietf.org>; Thu, 21 Feb 2002 09:28:27 -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 JAA24438; Thu, 21 Feb 2002 09:23:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA24400 for <rohc@optimus.ietf.org>; Thu, 21 Feb 2002 09:23:36 -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 JAA18109 for <rohc@ietf.org>; Thu, 21 Feb 2002 09:23:31 -0500 (EST)
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2653.19) id <1S9WNNBC>; Thu, 21 Feb 2002 14:21:43 -0000
Message-ID: <76C92FBBFB58D411AE760090271ED4186F9FCE@rsys002a.roke.co.uk>
From: "Price, Richard" <richard.price@roke.co.uk>
To: "'Dr. Carsten Bormann'" <cabo@tzi.org>, "'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 14:21:42 -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

> To me it seems the current draft is about twice as complex as it needs to be.
> We need real time to fix all the small details in that complexity.
> Complexity grows at least with some polynomial of the feature set.

Hi Carsten,

Is the additional complexity that you are worried about mainly due to the
technical mechanisms of the draft, or the informative explanation of how the
mechanisms can be used? There is quite a bit of the latter, and whilst it is
very useful for implementers it is non-normative and could easily be omitted
from the RFC.

Perhaps we could shrink the size of the SigComp RFC by moving some of the text
into a "SigComp implementer's guide" draft? This text could remain at draft
status for now; we could put it into the SigComp RFC at a later stage (perhaps
when we reach Draft Standard).

If you believe that any technical mechanism could be omitted from SigComp
without reducing the performance too badly then please let us know!

> If we want to finish in time, we need to focus on removing, not about
> adding.
> 
> Since anybody can "profile" SigComp to include certain state ab initio, I
> would like to propose that we end this discussion now.

As you mention above, the mechanisms needed to provide algorithm negotiation
are available already as part of the state reference mechanism. However, the
reason that Lawrence began this discussion in the first place is as follows:

[LWC]  We have the facilities within SigComp to minimise or even remove the need
for downloads, so the whacky contrib or three to the CN1 meeting is just a case
of this group and CN1 being slightly out of phase.

The "wacky contributions" were in fact proposals to add a separate algorithm
negotiation mechanism externally to SigComp, despite the fact that one is already
available within SigComp itself. More text is required somewhere to make this
clear, although it is an implementation issue only and so does not need to be
standardised as part of the base RFC for now.

Regards,

Richard