RE: [rohc] Formal notation, combined thread

["Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>]

> > > As above, I can't see any reason to think of the
> > > discriminator encodings as "special", or to treat them
> > > differently in some way.  The distinction between the
> > > various types of encoding method that we made last year
> > > was only intended to clarify how the notation handles all
> > > of the different compression techniques needed by ROHC
> > > profiles.  From a technical perspective the notation has
> > > never given special treatment to the discriminator
> > > encodings, and I think that it would be confusing and
> > > unnecessarily restrictive to do so.
> > 
> > We obviously disagree here. I still believe it is important to
> > make this distinction.
> 
> I think that the distinction only makes sense for a very simple
> header which is encoded in exactly two steps: first compress each
> field using a choice of one or more field encodings, and then
> compress the choices that were made by applying a discriminator
> encoding.

I rather believe it is important to make even more distinctions,
as I agree with you that there are more "alternative" methods.

> In particular, the distinction only works when a single (unique)
> discriminator encoding is used to encode all of the discriminator
> flags for the header. There are a number of cases where this isn't
> the best solution - three that spring to mind are "list", "nbo"
> and "format".

Let's look at these three...
 
> The "list" encoding method works much like list encoding in 3095 -
> namely that it allows the various list items to turn up in any
> order, and thus needs some discriminator bits to send this order
> information to the decompressor. In theory it would be possible
> to generate these discriminator bits using EPIC-lite: in practice
> we would get too many packet formats due to the sheer number of
> possible list orderings. The alternative is just to allow list
> encoding to create its own discriminator bits, separately from
> the ones generated by EPIC-lite.

I agree with you, list encoding is rather special, it differs
significantly from normal field-based encoding, and should be
treated separately, but that has nothing to do with the usefulness
of clarifying the difference between field encoding methods and
discriminator encodings for the field methods.

> The "nbo" encoding method offers implementers a choice of whether
> to reverse the IP-ID before compressing it. We could encode the
> resulting choice using EPIC-lite, but this would be inefficient
> because we would always be sending the choice in every compressed
> packet. Much better to store an "NBO flag" entry in the context
> and to use this when deciding how the IP-ID has been encoded.

This is a tricky one, as it changes the packet format interpretation,
but if it is used, it is of course another special detail. Still,
it does not affect the concepts of field encoding vs. discriminator
encoding.

> The "format" encoding method is designed to create multiple sets
> of compressed packet formats. 

I really hope that when we define future profiles, we will be able
to agree to avoid changing packet format interpretation "on the
fly" within a profile, as it adds unnecessary profile complexity
and/or unreliability. But even if we define multiple sets, I can
not see why it should affect making a clear distinction between
field encoding and discriminator encoding.

 
> > All field encodings that can send compressed data in more than
> > one way calls a discriminator function, but any function could
> > be used, i.e. the notation for a profile can be written independent
> > of the actual discriminator function that is later chosen. 
> 
> I outlined three cases where the above assumption fails - i.e. you
> get a field encoding that can send compressed data in more than
> one way, but where the resulting choice needs to be encoded using
> a discriminator function other than EPIC-lite.
> 
> Currently this poses no problem for the notation, because we invoke
> EPIC-lite just like any other encoding method. Therefore we have
> control over when to encode the discriminator flags using EPIC-lite,
> and when a different encoding method would be more appropriate.
> 
> 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). 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. 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. 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.


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

Further, I strongly believe that there is a difference in how you
choose discriminator encoding, compared to how you pick field encoding
methods. The latter is (almost) purely based on field behavior, while
the former choice is not as obvious, it is a more subjective profile
designer choice.


> > > We originally used the term "EPIC-lite" to mean
> > > the entire notation-based solution, including
> > > the notation itself and the complete library of
> > > encoding methods.  The algorithm for generating
> > > the discriminator bits is actually nothing more than
> > > ordinary Huffman encoding, so perhaps we could
> > > just call it that instead?
> > 
> > Ok, "Ordinary Huffman" (OH), and "Hierarchical Huffman" (HH) then?
> 
> Sounds ok to me!

Fine, let's try to use those then.

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