RE: [rohc] Formal notation, combined thread

["Price, Richard" <richard.price@roke.co.uk>]

Hi,

Apologies for the late reply - the Easter holiday got in the way ;-)
I've added some further comments inline.

Now that a complete implementation of the current ROHC-FN draft is
available, would it be worth collecting together all of the unresolved
issues related to the notation? This thread is discussing the "scope
and purpose" of the notation, but there are also some more technical
issues that still need to be ironed out, such as whether to keep the
temporary variables, whether to allow unbounded lists and so on.

Regards,

Richard

> > We'd run into difficulty if we had to use a single (unspecified)
> > discriminator function for every case where compressed data can be
> > sent in more than one way. We'd be forced to use a single method to
> > encode every discriminator, even for the special cases where a
> > different method is more memory efficient or gets a better
> > compression ratio.
> 
> I think you missed my point. The point was to have a notation where 
> you would have an unspecified (generic) function, but that would not
> out rule having other functions for some special cases, like context
> based choices (that might be another general method).

I think that having an unspecified "generic" encoding method that can
be defined later on is only possible if there are two or more methods
with the same purpose and inputs. I'm not currently aware of any
encoding methods that work like this.

> What I am after is that where you could choose to use OH (Ordinary
> Huffman), you could as well use HH (Hierarchical Huffman), or some
> other discriminator function with the same purpose and input.

The OH and HH algorithms have the same purpose, but their inputs are
actually somewhat different. Certain field encodings can be used in
conjunction with HH that can't be used with OH - an example is the
so-called Least Significant Part (LSP) encoding that was considered
briefly for use in 3095. Conversely, some encoding methods can be
used in conjunction with OH that can't be used with HH - for example
the "uncompressible" encoding method as defined in the notation draft.

> It is just about using a different algorithm, and the choice is in
> my mind a rather subjective one, made when one define a profile.

True. However, once this decision is made, a different set of field
encodings will be available to the profile designer depending on
whether OH or HH is used.

> I do not think a profile should use both OH, HH, and/or even more
> discriminator functions, but instead I would like to see a generic
> way of notating, and then the profile definition would state which
> discriminator function to actually use for those places where this
> generic method is called in the notation.

The only way to do this would be to restrict the set of field
encodings to ones that can work in conjunction with both OH and HH.
At present it's entirely up to the profile designer whether to do
this or not. For example, if we want to create two profiles for
TCP/IP - one using OH and one using HH - then we have two choices:
either create two profiles that use the same (restricted) set of
field encodings, or use the optimal set of field encodings for each
case (even though some field encodings only work for OH and others
only work for HH).

I think that both approaches have their merits - the first is
simpler, whilst the second will get a better compression ratio due
to having a wider range of field encodings available for each of
the profiles. What I'd like to avoid is forcing profile designers
to use only the generic approach, because we'll typically know the
discriminator encoding that the profile will use and can therefore
take advantage of this knowledge when selecting the field encodings.

> > This approach also makes the notation rather more simple than the
> > case where the discriminator flags are treated separately. Currently,
> > discriminator flags are treated exactly like any other data that
> > needs to be sent to the decompressor. In particular, we don't need
> > to worry about having new data structures to hold the discriminator
> > flags - they can be stored in the same data structures that we use
> > for the "ordinary" header fields (namely the labels and the context).
> > Moreover we don't have any special syntax for handling the
> > discriminator flags - we can compress them by applying our choice
> > of encoding method (e.g. EPIC-lite) just like we would apply LSB
> > encoding to compress a particular field.
> 
> Complexity is not just about implementation, but also about structured
> concepts. Functionally, discriminators might just be created by using
> "just another encoding method", but we should make the difference
> clear conceptually, when we outline this new approach for describing
> a header compression process.