[rohc] Formal notation, combined thread

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

Hi all,

After last weeks discussions, I found it useful to let all new insights 
come to rest before answering again. Below, I have tried to group the 
issues, although they are of course all closely related to each other.

BR
/L-E


1. Specification vs. implementation

We have to separate specification from implementation. Even if
implementation is in the back of our heads when we specify our
protocols, the specification is not about how to implement it.
What we define for header compression are data structures
(compressed headers), as well as compression rules for what to put
in compressed headers and how to interpret what is sent. Even if
you would implement a ROHC profile using a "notation compiler",
what we do is to define the notation language, and in the profile
specification we will use it as a reference (we do not have to
redefine these for each case).

> RP: An "oracle" function is just a function which returns an
> implementation-specific value.  Whenever the compressed header
> formats offer a choice for implementers, the notation calls
> an oracle function to find out what choice the implementer
> wants to make.

The oracle functions is thus an implementation issue about
choosing proper compressed formats, so we do not even have to
mention these anywhere, right? We define the means to communicate
and how to interpret what is communicated, but not what to say.

> RP: From the notation's perspective the oracle function can be
> called just like any other function (e.g. the CRC).  When the
> notation is compiled, an implementation of each of these basic
> functions must of course be provided.

I guess you mean "when a profile specified using the notation
language is compiled...". The oracle functions is just an
implementation issue, as it is part of "compress" (i.e. not
specified). We must be careful and separate implementation from
specification.

> > LEJ: Note that the notation itself would not be something that
> > would be implementable.
>
> RP: I don't understand the above statement.  The notation is a
> language, so it's possible to implement a compiler which converts
> (say) a description of TCP/IP written in the notation into
> executable code.

Yes, you might do a compiler FOR specifications based on the notation.

> > LEJ: Of course, the various mechanisms described by the notation
> > could be implemented, but not the notation itself. The notation
> > is not a machine, it is a language.
>
> RP: Yes, which is why it's possible to implement a compiler for
> the notation.

Yes, and such a compiler could of course be a useful tool when
implementing profiles defined using that notation. But that is only
about implementation.

> > LEJ: The point is that, I believe the notation should be
> > about.........notating, nothing else.
>
> RP: Absolutely.  Would it be possible to point out any specific
> statements which seem to contradict the above (particularly if
> they're in the notation draft itself)?

Yes, for example section 4.2 in the notation draft, which talks about
"implementing the notation".


2. Field encoding vs. discriminator encoding

> > > RP: It shouldn't matter whether the function compresses a
> > > single field, a whole protocol header, or even the entire
> > > packet. Also, it shouldn't matter whether the function outputs
> > > compressed bits that are considered to lie in the
> > > "discriminator" or in the "compressed body" part of the
> > > header.
> >
> > LEJ: Here I would strongly disagree. I rather think we should
> > have a few different terms for the different kind of "encoding
> > methods", since I think that would heavily simplify
> > understanding, and make it easier to separate the various
> > pieces.
> 
> RP: However, a single term is still needed for the concept of an
> "encoding method" as a whole. 

Actually, I do not think we really need that. Encoding of fields is
a rather different thing than "discriminator encoding" (or maybe
"branch encoding"?), and we should make that clear in the notation.
A good name for these would be really useful, as "self-describing
values" as just another method does not say much about what it is
or how different the method really is. 

> > LEJ: Methods to use for generating the actual compressed header
> > formats, e.g. EPIC-lite, are rather different.
>
> RP: However, from the point of view of the notation language, is
> there any reason to treat EPIC-lite differently from the other
> encoding methods?

Yes, because there is a significant difference between these.
Normal encoding methods are chosen based on how fields behave, 
while it is a subjective profile specification decision to pick
a "discriminator encoding method" for the profile. 

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


3. Notating the content or the compressed formats

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

This is not what we discussed last year when we started the 
notation discussion and talked about field encoding versus
encoding the complete compressed headers. The notation was said
to capture only the first. I had not heard anything else so I 
assumed this was still the case. That absolutely caused some
confusion on my side.

> 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. I
think the notation should capture the field compression part and
provide all details useful for arbitrary "discriminator encodings",
as that would provide flexibility for profile specifications to use
the same general notation independent of which discriminator method
is then defined to be used for the profile.

> RP: The notation describes more than just the compressed header
> content - it describes the exact packet formats (i.e. bits on the
> wire). 

Now I get this, from the definition of "/". However, I do think the
"/" method should not be totally defined, only have defined
parameters, then the notated fields would look the same independent
of which discriminator method is used for the profile. A profile
might choose to use the current definition of "/", define it as
"EPIC-Lite", any other method, or define the actual formats by hand.
The generic "/" should have probability values as parameters, as
that is essential information independent of how the
discriminators/formats are defined (not for the simple per-branch
bit mask as the current "/" uses, but for any sophisticated method).

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

As explained above, I would like to make the notation a formal way
of defining what information to put in compressed headers, but not
include defining the actual headers (although a profile might choose
to define "/" formally to be used as you suggest). The difference is
basically that the "/" should just be an unspecified "branch" or 
"discriminator" method, which a profile specification defines the
meaning of (might be current "/" definition, "EPIC-L", or something
else).


4. Discriminators

> > LEJ: I followed you up to "single discriminator", but there you
> > lost me. Can you elaborate on this?

> RP: This last point is just talking about a specific feature of
> EPIC-lite, which is that it always generates a single
> discriminator for the *entire* packet (as opposed to RFC 3095,
> where there is usually a discriminator to indicate the overall
> packet format, as well as separate discriminators on the front
> of each individual compressed protocol header).

Do you mean like the bit mask we have in Ext3, which is an additional
discriminator for compressed header, on top of the "packet type"?


5. Notation "completeness"

I think we agree that we can not know that the notation will be
"complete" for all future needs, but it might have to be extended
in the future to capture new things we might want to do. However,
this is actually not a problem, but might even be a good thing,
as after accepting this we do not have to worry about the future 
at all. You can of course do a compiler for the notation (if that
is a preferred choice when implementing a profile), but that
compiler might have to be modified if new methods are defined and
used by future profile specifications. The point is that since a
"notation compiler" is just an implementation tool (in the same
way as the notation itself is a specification tool), having to
modify it when implementing new profiles should not be a concern.


6. Human-readable vs machine-readable

> RP: In the notation draft we have a specific section devoted to
> "list encoding methods" which handle lists of items.  However,
> the notation language itself doesn't treat these encoding methods
> differently from any others.

This is actually one of my main concerns. Everything is forced to
become "just another encoding method", and that does not make the
whole thing clearer. Just because it is possible to do, you do not
necessary have to do it that way.

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


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?


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