Subject: [rohc] ROHC-FN uncompressed field encodings list

From: "Finking, Robert" <[email-masked]>
Date: Fri, 5 Nov 2004 11:34:27 -0000

Hi Guys,

just doing a bit of catching up. I just read the following new paragraph (in
section 4.11.1.2 uncompressed_format):

An uncompressed format may contain a field encodings list. Encoding methods
specified therein are used whenever a packet with this uncompressed format
is being encoded, regardless of the selected compressed format. If an
uncompressed format contains let-statements, the encoding of a packet with
this uncompressed format can only succeed if the specified expressions
evaluate to true (see Section [TBA]).

So I guess this means you can have structures like this:

  foo ===
  {
    uncompressed_format_1 = field_1,
                            field_2
    {
      let(some condition);
      field2 ::= some encoding method;
    }

    uncompressed_format_2 = field_1,
                            field_3
    {
      let(some condition);
      field3 ::= some encoding method;
    }

    default_encodings =
    {
      field_1 ::= some encoding method;
    }
  }

I quite like this, but I'm not sure I get it entirely! I guess the idea is
that you can specify e.g. that a version field has a set value, by
specifying an uncompressed_value encoding for that field? It's probably
worth adding at this point that I think the last sentence of 4.11.1.2 is too
weak. We need to make the same statements about uncompressed format
encodings as we do compressed format encodings - that the whole format fails
if any of it's component parts fail - whether they are let statements or
encoding methods.

There's something that troubles me here. It's about the way these encodings
interact with the compressed format encodings and also the default
encodings. (I'm also a bit nervous about what exactly is allowed inside the
uncompressed field encodings list. For example you could easily encode
field_2 in the example above using compressed_value encoding, which wouldn't
make any sense would it?)

Anyway, here's the issue. You could easily do something like this:

  foo ===
  {
    uncompressed_format_1 = version,
                            field_1
                            field_2
    {
      let(version:uncomp_value == 3);
    }

    uncompressed_format_2 = version,
                            field_2,
                            field_3,
                            field_4
    {
      let(version:uncomp_value == 4);
    }

    :
    :
    :
  }

But there's a big problem here: the value of the version field depends on
its length, which in this case, is not defined by the uncompressed field
encodings. The choice of which compressed formats can be used is obviously
going to depend on which uncompressed format is selected, so you end up with
a mutual dependency between the compressed and uncompressed formats. This is
just an example that springs to mind immediately, but the root of the
problem is allowing the two simultaneous definitions of the field encodings.
It's more explicit that the way we already had of doing this, which is good,
but also more dangerous I think.

Out of interest, what was wrong with the old way of doing it?

Cheers

Raffles

PS I've purposely not read the TCP profile yet to avoid getting
preconceptions in my mind!

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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 6 Nov 2004 12:11:18 -0500

> So I guess this means you can have structures like this:

There is no compressed_format, so this can never succeed.
The compressed_format could reduce to a simple field list in this case.

> if any of it's component parts fail - whether they are let statements 

True.

> make any sense would it?)

Well, it would mean you have a discriminator that is being determined 
from the uncompressed_format.
(As the field is zero length on the uncompressed side, it doesn't 
influence the uncompressed side too much.)
Not really senseless at all.

> but also more dangerous I think.

I don't see a problem with dependencies.
Conceptually, a structure is an alternative between all possible 
combinations of uncompressed and compressed formats.
Whether something (field definition or let-statement) is written down 
in an uncompressed_format or a compressed_format is just an issue of 
convenience.

> Out of interest, what was wrong with the old way of doing it?

Convenience.  The specs are long enough at they are.
(But then, I have no idea what "old way" you have in mind.)

Gruesse, Carsten