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

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

Carsten,

> I think what we came up with is a little different -- it
> describes the meaning of compressed headers in terms of
> the uncompressed headers.

Ok, how does the context(s) come into the picture?


> >        Which format to use when compressing a packet is
> >        further a separate issue. I believe that header
> >        formats that are generated by automatic means might
> >        provide simpler means to create compressed headers,
> >        but these two issues defining compressed formats and
> >        actually compressing headers) are still different
> >        parts of what we are discussing.
>
> In an implementation, yes.  In a formal notation, formally
> defining the structure of the compressed packets without
> defining their relationship to the uncompressed packets is
> not very useful (I'm repeating myself).  Once you describe
> this relationship formally, 
> ******** and find a way to compile the formal notation ********,
> you can build a compressor and a decompressor this way (modulo
> oracles, see below).

Yes, but "the way to compile" is not a "one single obvious way".


> >
> >     1) In Richards last e-mails, he seems to say that the
> >        notation itself gives the compressed formats (bits on
> >        the wire), and I do not buy that. How could that be
> >        possible?
> >
> I believe Richard's/Mark's idea is that the notation defines
> all the bits in the compressed packet (its "body"), apart from
> an initial discriminator.  This discriminator is what differs
> between EPIC and EPIC-Lite.  The discriminator carries all the
> information that is needed to parse the body.  The body carries
> information that is too big to carry in the discriminator;
> essentially orthogonally encodable information.  The notation
> supplies everything that is needed to go into the discriminator
> computation (values, probabilities).

Ok, maybe (someone still has to convince me about this) the
notation includes all that is needed to create discriminators,
but as you also indicate, there is not one single way to do this.
The notation does not dictate how to do it, it inly provides the
means to do it. It could be done by hand (as we did in 3095), or
it could be automated using some kind of algorithm, but this is
a decision that must be taken.


> >     2) Richard is confusing compressing headers with
> >        defining the candidate compressed header formats. 
> >
> Well, the compressed header formats are in some way related
> to the uncompressed packet. 

Sure, I would not expect otherwise...=)

> The notation captures this relationship.  The notation can
> use an oracle function to be able to derive more than one
> packet format based on the same uncompressed packet.

Ok, now we are getting somewhere. Can you elaborate a little
bit on the "oracle" issue? Actually, can you define exactly
what you mean with "oracle", maybe draw some parallel with
well known things, like 3095?


> In other words, the notation we define (i.e., the library
> of encoding rules) may favor packet formats that are
> different from the ones we finally decided to use in 3095.
> This is of course particularly true if we stick with a
> single discriminator for the whole packet (I believe that
> is a mistake and you need some form of cross-product
> generation of packet formats, which calls for separate
> discriminators -- something my proposal does not even start
> to address yet).

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


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