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

From: "Price, Richard" <[email-masked]>
Date: Thu, 6 Mar 2003 13:36:51 -0000

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

Hi,

More specifically, the notation defines a function whose inputs
are the uncompressed header and the context, and whose outputs
are the compressed header and an updated version of the context.

What might be confusing about this function is that it's
defined in terms of "oracles" - perhaps this is the source of
the confusion between defining the candidate compressed header
formats, and actually compressing the headers?

Oracle functions aren't too complicated - I've explained a
bit more about them below.

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

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.

A good example from 3095 is the implementation-specific choice
we make when selecting which packet format to use.  The three
steps that need to be taken are as follows:

1.  Pick which packet format to use.
2.  Output some indicator bits to tell the decompressor which
    choice you made.
3.  Compress the header using the chosen packet format.

Step 1 is an implementation-specific choice, so when we're
defining a set of packet formats using the formal notation, we
call an oracle function to tell us which choice to make.  We
then convert the output of the oracle function into bits and
stick it onto the front of the compressed header.

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.  For the CRC function you
(naturally) implement a CRC.  For the oracle function you can
write any code you like, since the output of the oracle doesn't
affect interoperability.

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

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

The EPIC-lite approach is more efficient than the 3095 approach,
so I don't know why Carsten thinks we need separate discriminators.
However, this is an issue with the EPIC-lite algorithm itself,
and we can always change it to generate separate discriminators
for each protocol if there's a good reason to do so.  The notation
will happily support either approach.

Regards,

Richard
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2003 16:07:49 +0100 (CET)

> so I don't know why Carsten thinks we need separate discriminators.

I'm not so interested in the separation, just in a way to control the
combinatorial explosion.  It would then become a matter of design to
control which indicators combine to form one discriminator (which is then
optimized based on the known probabilities of the possible values) and
which ones stay separate to reduce combinatorial explosion.  The latter
may be desirable when the designer knows that the case in which the
indicators are used is unlikely enough, and also when it is somehow clear
the values being separated from each other are sufficiently orthogonal
that there is little gain in the optimization.

All this is, of course, just a set of second-order considerations.

Gruesse, Carsten