Options (was: RE: [rohc] RE: Default decompression algorithms)

> > 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.

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.

> 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.

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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc