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

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

Richard,

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


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


> Is it always the case that an encoding method compresses
> exactly one field?  What about list encoding from RFC 3095?

I would not call list compression itself an encoding method in
the sense of 3095, but others might have a different opinion in
that regard. List compression is a rather separate part of 3095,
while the encoding methods I would refer to are those that are
listed as encoding methods in section 4.5.
 

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


> 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 notation above, i.e. with probabilities,
seems to me to be a very generic approach that should be used in
the ROHC FN. 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. 

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


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