Subject: [rohc] RE: Default decompression algorithms

From: "Price, Richard" <[email-masked]>
Date: Thu, 21 Feb 2002 17:43:18 -0000

> > So for the wireless environment 3GPP will be
> > able to choose their own list of mandatory and optional algorithms.
> 
> Yes, they use to do it that way, but why should WE make any algorithm
> mandatory at the decompressor.

We shouldn't - in my opinion it would be a mistake for the ROHC Working
Group to do more than standardise the algorithms themselves. The final
decision on whether algorithms are mandatory or optional should be made
in the context of a particular application.

The ability to make certain algorithms mandatory is available "for free"
as part of the secure state reference mechanism, so no additional
standardisation is required on our part.

> As you say yourself, the decompressor can announce what resources it has,
> and the compressor decides what to use based on that, but the decompressor
> does not have to announce any available algorithms. If it does not, the
> compressor just do not have any other choice than to download its own
> algorithm.

We should leave the decision as to whether or not mandatory algorithms are
required to particular applications (e.g. 3GPP can decide this for SIP in
the mobile environment).

> > I would be very happy to include both approaches in the SigComp
> > solution and leave the decision on which to use to the compressor.
> 
> Simple and well defined solutions with few options are usually
> preferable when making standards, at least in the IETF. 

With the UDVM approach the SigComp solution can certainly be simple and
well-defined, but few options is one thing that we won't have! A compressor
with the ability to download bytecode already has complete flexibility to
choose any algorithm it likes; in my opinion this is a strength of SigComp
rather than a weakness.

The ability to announce a list of supported algorithms at the decompressor
does not introduce more flexibility but instead just saves downloading the
chosen algorithm when it is already available at the decompressor.

Regards,

Richard

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Fri, 22 Feb 2002 08:55:56 +0100

> choose any algorithm it likes; in my opinion this is a strength of SigComp

Richard,

when we talk about "options" at the IETF we talk about additional code
that configures in or configures out particular logic based on some
negotiation or other agreement.
The general observation after decades of protocol design is that options
often cost more than just making logic mandatory in the first place.
Even if they don't just from an implementation point of view, they reduce
the usefulness of the protocol:
If it is likely that different implementations implement different sets of
options, interoperability becomes unlikely (unless there is a base
configuration as in PPP).
Finally, interoperability testing an implementation with lots of options is
nearly impossible.

So what we need to avoid is negotiation that causes implementations to
behave
different.

Let me give you an example:
The X11 protocol allows to choose whether fields are sent MSB first or LSB
first, ostensibly because it is more efficient to send them LSB first if
both sides use LSB first natively.
This is not the Internet way, we always use MSB first, removing one
potential
"option".

Options != flexibility.
I believe the UDVM concept removes a lot of potential options and gives
implementors lots of flexibility, which is good.
Let's stick with that path.

Now on to the subject of avoiding options in Sigcomp:
I'm not sure that the current set of implementation parameters is a good
idea.
I'd rather freeze most of these at a single value.
This does remove flexibility, but I think in most cases this is unwanted
flexibility (= "options").

We just need to be decisive enough to leave out things.
One of the more serious OSI diseases was to standardize lots of options,
and then later generate "profiles" that would reduce these options to
(more or less) manageable proportions.  Of course, then there are "PICS"
(profile implementation conformance statements), so you find out which of
the options someone has done from a nice little tome of paper.

Why standardize stuff that is never going to be used anyway?
In many cases, this is just an expression of lack of technical direction
in a standardization body.

> chosen algorithm when it is already available at the decompressor.

Right.  I still don't know why this cannot be done using state claims
(please explain).
And I haven't caught what this business about "standardizing compression
algorithms" is about.
We don't.

One final observation: Negotiation takes time.
It is the objective of Sigcomp to save time.
Can we define Sigcomp in such a way that we don't need to expend that time?
(I know, it might be mitigated by moving it to the registration phase, but
it's still latency that will be perceived by the user.)

Gruesse, Carsten

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