RE: [rohc] Role and approach of the ROHC formal notation

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

> > However, one point I'd like to clarify is that algorithms like
> > EPIC and EPIC-lite are for -generating- packet formats, whereas
> > the notation is for -describing- packet formats.  Another way of
> > generating packet formats is of course to design them by hand! 
> 
> Exactly, this is what I have been trying to say all the time.
> The notation itself is only for describing the content of compressed
> headers, it only provides a structured input to the process of
> generating compressed packet formats (by hand or by "automated" 
> means).

Hi,

Based on our recent discussions, I think that I now understand the
difference between our views on how the notation should be used.

In my view, a ROHC-FN description is a complete specification of
"bits on the wire" (assuming of course that all of the basic encoding
methods have been defined).  In particular, if the compressed header
formats are generated by EPIC-lite then the ROHC-FN description
invokes EPIC-lite, and provides all of the input needed by EPIC-lite
to generate the bits on the wire (which happens to be the content
of the compressed headers, plus a set of probability values).

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.

> > But even if we choose to do this, the notation can still be
> > used to capture the exact hand-crafted packet formats that we
> > want to use.
> 
> Yes, the notation should be useful in any case, to get a structured
> way of documenting the compressed header content.

The notation describes more than just the compressed header content -
it describes the exact packet formats (i.e. bits on the wire).  Even
if we design the packet formats by hand, they can still be described
formally using the notation.

> > > This is a very generic approach, but you do not get very 
> > > efficient formats.
> > 
> > Absolutely - all the original example tries to do is to 
> > demonstrate how the notation gives "bits on the wire".
> 
> This is where the inconsistency appears. The notation, as you 
> wrote above, does not generate the actual compressed formats.
> One use the notated information when generating the formats,
> but this is an additional process. Thus, by just notating the
> compressed header content, one will not get "bits on the wire".

As above, in my view the notation should describe the exact bits
on the wire (not just the compressed header content).

> > Let's try the above example using EPIC-lite.  We can replace
> > the old "self-describing values" discriminator (denoted by "/")
> > with a new discriminator generated by EPIC-lite (which we'll
> > denote using the symbol "|").
> >
> > mini_tcp_header   ::=   tcp_source_port
> >                         tcp_destination_port
> > 
> > tcp_source_port   ::=   static 90% | irregular (16) 10%
> 
> Do you mean that the current notation language is not providing
> enough information to use more sophisticated means to generate
> packet formats?

The probability values aren't part of the notation itself - they're
inputs that are needed by the EPIC-lite encoding method.  This
might be clearer if we avoid using the rather confusing symbol "|"
to denote EPIC-lite, and instead write it out explicitly as follows:

tcp_source_port   ::=   epic_lite (static, irregular (16), 90%, 10%)

This means that the TCP Source Port is compressed using EPIC-lite,
which in turn offers us a choice of two encoding methods (static
or irregular) for compressing the field.  After picking one of these
two encoding methods, EPIC-lite outputs a suitable discriminator to
tell the decompressor which choice has been made.

The probability values are just parameters that are needed by EPIC-
lite in order to work out which bits on the wire to send.

> The notation above, i.e. with probabilities, seems to me to be a
> very generic approach that should be used in the ROHC FN.

The probabilities aren't part of the notation - they're just the
parameters which EPIC-lite needs in order to calculate the bits on
the wire.  If the notation is describing hand-crafted packet formats,
then the probabilities aren't included (because they're not needed
to describe the packet formats).

> Even if we did not have a notation then, of course we did have
> such probability expectations in the back of our heads when we
> wrote 3095. 

However, if we generate the packet formats by hand then the
probability values would not be captured in the ROHC-FN description
of the compressed packet formats.  The description would capture
our hand-crafted packet formats instead.

> > In the above example (ignoring byte-alignment and reserving
> > the ROHC framework indicator bits), EPIC-lite calculates the
> > overall probability that each packet format will be needed,
> > and assigns shorter discriminators to the more common formats:
> 
> In principle, as we did in 3095 (but not by automatic means).
> 
> 
> > So, we get exactly the same set of packet formats as the ones
> > we designed by hand above, but generated automatically by the
> > EPIC-lite algorithm:
> 
> Yes, and therefore I also agree that we could potentially gain
> from using such automated means. If we still document the output
> in a human readible form, it would still be possible to make
> minor adjustments by hand, and the formats would be
> independently defined by the profile specification.

In my view of how the formal notation works, minor adjustments
to the packet formats would be made within the ROHC-FN description
itself.  We would invoke EPIC-lite to generate the packet formats,
and then we would modify the output of EPIC-lite by applying one
or more additional encoding methods to tweak the "bits on the wire".

The big advantage of making the adjustments within ROHC-FN is that
the description of the compressed packet formats remain machine-
readable, and can still be compiled into executable code without
needing any hand-made adjustments.

> > > Anyway, this was still a very good example, but things get
> > > much more complicated when we start addressing fields that
> > > are compressed together, and when we add context interaction.
> > 
> > Fields that are compressed together are easy to handle using
> > the appropriate encoding method.  For example, suppose that we
> > want to compress the IP-ID as an offset from the Master
> > Sequence Number.  We can write this in the notation as follows:
> > 
> > ip_id   ::=   inferred_offset (16, MSN)
> >               lsb (4, 0) / lsb (8, 0) / irregular (16)
> > 
> > Context interactions are also easy to describe using the
> > notation.  By default every encoding method automatically
> > updates the context - if we don't want this to be the case
> > for whatever reason then we can write the following:
> > 
> > tcp_source_port   ::=   no_update (static / irregular (16))
> 
> Looks ok!
> 
> /L-E
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc