RE: [rohc] Formal notation, combined thread

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

> > > > RP: The notation language itself shouldn't make a distinction
> > > > between EPIC-lite and any other encoding method.
> > > 
> > > As I have said above, I think it is important to make a clear
> > > distinction between these, as they are so different. That is also
> > > what we said last year, when we talked about field encoding vs.
> > > compressed header encoding.
> > 
> > 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.

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

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.

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.

The "format" encoding method is designed to create multiple sets
of compressed packet formats. For example, if we wanted to have
separate packet formats for UO-mode and for R-mode then we would
write the following:

example_packet_formats   ::=   format(uo_mode, r_mode)

We could encode the choice of packet formats using EPIC-lite, but
we'd lose efficiency because we'd end up sending the choice in
every compressed packet. The solution is to create a new context
entry to store the choice of packet formats instead.

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

> > > > RP: If the compressed header formats are created manually then the
> > > > ROHC-FN description captures the exact hand-crafted packet
> > > > formats - not just the content of the compressed headers, but the
> > > > hand-crafted "discriminator" bits as well.
> > > 
> > > OK, but then we would not even need the notation as a tool, if
> > > the actual formats (in written form) would just mean the same.
> > 
> > The notation provides a really useful benefit even when
> > describing hand-crafted compressed headers, which is the
> > extra implementation option of writing a "notation compiler"
> > to automatically convert a notated description of the
> > packet formats into running code.
> 
> First of all, I think it would be useful to have the notation to
> describe what to put in hand made formats, i.e. as a tool in such
> a process. Further, I think we would make a mistake if we tried to
> make the notation capable of describing hand made formats, as that
> would make the notation unnecessary complex,

I disagree with the above - in general, there's no relation between
the expressive power of a language and its complexity.

The current notation is powerful enough to describe hand-crafted
packet formats, as we can compress the discriminator bits using any
encoding method we like. We can apply EPIC-lite to the whole header
or we can use separate discriminator encoding methods for each field
(or any combination of the two).

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.

> while the reason does not really make sense in my mind. 

Having a formal description of the packet formats is a huge saving
in terms of implementation effort, because it eliminates all of the
confusion and misunderstandings that occur when trying to code a
complicated set of packet formats by hand.

> > > > RP: The big advantage of making the adjustments within ROHC-FN
> > > > is that the description of the compressed packet formats remain
> > > > machine-readable
> > > 
> > > We are defining standards, which should be human-readable. There 
> > > are probably disagreements in this regard, but personally I think
> > > human-readability is more important than machine-readability.
> > 
> > I agree that human-readability is at least as
> > important as machine-readability.  However, in
> > my opinion a notated set of packet formats is
> > actually rather more human-readable than a set
> > of packet formats drawn out pictorially.  
> 
> Well, protocol headers are usually drawn out pictorially, so that is
> what protocol folks are more used to. 

Pictorial descriptions are generally restricted to simple protocol
headers. For more complex protocols it's usual to define the headers
via a formal notation, such as ABNF for SIP or ASN.1 for H.323.

> > > 7. EPIC-Lite 
> > >  
> > > The EPIC and EPIC-Lite terms have been overloaded several times by
> > > now, and they actually do not say much about what they really do.
> > > If we want to use the "EPIC-Lite" method for "discriminator
> > > encoding" and potentially define it in the general notation
> > > document, we should come up with a name that tells us what it does. 
> > > 
> > > Any ideas?
> > 
> > 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!

Regards,

Richard
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc