Subject: [rohc] ROHC-FN: Changing the behavior of the "let" encoding method

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 21 Oct 2004 13:40:50 +0200

Hi!

Here's a proposal for another change to the ROHC-FN to make it more clear to 
users. The last WIP draft has defined let as:

4.6  Let

    The reserved keyword "let" takes a boolean expression as a parameter.
    It can be used to assert that the expression has a specific value, in
    order to choose a particular packet format from a list of possible
    formats:

      let (<boolean expression>)

    When the boolean expression evaluates to false, the environment of
    the expression fails, i.e.  does not succeed.

What seems unclear is "the environment of the expression fails". What is "the 
environment"? I guess it's intention is to say that anything in the same scope 
as this let-statement fails. We suggest that "let" be allowed to provide its own 
scope:

Examples of such use:

uncompressed_format =	version,
			src,
			dst,
			let (version == 4) {
				ip_id,
				df,
			},
			let (version == 6) {
				flow_label,
			},
			....
As can be seen, this would form the uncompressed_format for co_baseheader 
(innermost IP header and TCP header).

The above would be useful for example to solve the definition of the 
uncompressed format for a protocol that has multiple versions (i.e. IPv4/v6)

Another example:

static_or_irreg32(flag) ===
{
   uncompressed_format = field;        %[ 32 ]

   let (flag == 1) {
      format_irreg =        field,     %[ 32 ]
      {
         field ::= irregular(32);
      }
   };
   let (flag == 0) {
      format_static =       field,     %[ 0 ]
      {
	field ::= static;
      }
   };
};

Example 3:

dummy_enc(flag) ===
{
	uncompressed_format =   field1,
				field2;
	format_fluffy =
	{
		let(flag == 0)	field1 ::= irregular(16);
		let(flag == 1)  field1 ::= static;
		field2 ::= irregular(912);
	}
}

So, by using enclosing braces, the "let" can provide its own scope. When not 
using braces, the let is scoped only to the statement it is a part of.

This modification will be an improvement for the following reasons:
- Allows "let" to provide its own scope, which means that less FN has to be written:
   * Example 3 would have to have two different format_ definitions with the 
"old" let encoding.

- Allows "let" to be used in uncompressed_format and default_methods section of 
the FN
   * Example 1 would require that both the uncompressed format for IPv4 and IPv6 be
   written separately. In the latest packet formats on the cvs repository, the 
packet format simply try to avoid spelling out the IP fields but it seems wrong.
   With this modification to "let", it is possible to still do it in a somewhat 
concise manner.

- Example 2 allows the let to be used just like an if statement, with a clear scope.

- Makes the definition unambiguous, since let provides a scope instead of having 
to interpret what the "environment" is. Also, with the old definition, 
statements appearing in the same scope, but before the let would also fail, 
which seems akward at best and more difficult to realize.

BR,
	Kristofer Sandlund, Effnet AB
	Ghyslain Pelletier, Ericsson

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2004 16:05:22 +0200

> Here's a proposal for another change to the ROHC-FN to make it more 
> clear to users. The last WIP draft has defined let as:

I'm not sure I want to change much at the current stage.
The notation seems to be expressive enough as it is, and already hard 
to "implement" (i.e., to write a checker or an execution engine for).
Last but not least, it is already somewhat hard to understand.
Adding concepts will not improve that situation.

> What seems unclear is "the environment of the expression fails". What 
> is "the environment"?

The packet format that the let is in (explicitly, or implicitly via 
default_methods).
Note that there is no way to "take back" a "let" that comes in via 
default_methods, which is a bit of a missing feature.
(Which I don't want to tackle at this stage -- you can always repeat 
the let in all other formats).

> As can be seen, this would form the uncompressed_format for 
> co_baseheader (innermost IP header and TCP header).

So, for version == 5, neither ip_id nor flow_label would be there?
Also, I'm not sure the example works very well because the whole format 
changes between 4 and 6; the existing spec solves this rather nicely 
(and compactly).

>      format_static =       field,     %[ 0 ]

This can be expresser shorter using the existing means.

If I wanted to do this, I'd write:

> 		{ let(flag == 0);
> 			field1 ::= irregular(16); }
> 		{ let(flag == 1);
> 			field1 ::= static; }

But then, I don't really want to.
Right now, the right way to do this is:

fluff1(flag) === {
	uncompressed_format = f1;
	co_1 = {
		let(flag == 0);
		f1 ::= irregular(16);
	}
	co_2 = {
		let(flag == 1);
		f1 ::= static;
	}
}

dummy_enc(flag) ===
{
		field1 ::= fluff1(flag);

More verbose, yes; but (given reasonable names that suggest an 
abstraction like "optional32") even more readable.
(Note that these abstractions are often reusable in more than one 
place.)

>   * Example 3 would have to have two different format_ definitions 
> with the "old" let encoding.

Yes, see above.

> - Makes the definition unambiguous, since let provides a scope instead 
> of having to interpret what the "environment" is.

See above.

> Also, with the old definition, statements appearing in the same scope, 
> but before the let would also fail, which seems akward at best and 
> more difficult to realize.

I don't think we need the concept of "statements", only encoding 
methods and formats, so I don't think that is a problem.

Gruesse, Carsten

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 21 Oct 2004 16:24:02 +0200

I have to disagree with you.
The "base header" can either be (IPv4 + TCP) or (IPv6 + TCP) and we have ~20 
different compressed formats for base headers, where the non-sequential packets 
are common for both. With the old syntax, we'd have to define all those 
10-something packets twice, since you cannot put a "let" in uncompressed_format 
or default_methods.

More comments inline.

> I'm not sure I want to change much at the current stage.

Agree, but we have to make this work. So far we've had lots of different 
versions that "ignores some tricky details", and there's been no input form 
anyone to solve this, so we had to take some form of path to solve this.

> The notation seems to be expressive enough as it is, and already hard to 
> "implement" (i.e., to write a checker or an execution engine for).

Yes, but then again the checker is not a part of the requirements for this, but 
that it works definitely is :)

> Adding concepts will not improve that situation.

I belive it will. The current concept is hard to understand.

> (Which I don't want to tackle at this stage -- you can always repeat the 
> let in all other formats).
> 
> (and compactly)

Nope. It does not. In the last version of the packet formats, I tried something 
with the ip_hdr structures, but Eilert added a FIXME since the fields did not 
appear explicitly in the uncompresed_format. And earlier versions just ignored 
IPv6 completely in the base headers, so those did not solve anything.

.
> (Note that these abstractions are often reusable in more than one place.)
> 

Again, no agreement from me. The definition of "let" is ambiguous in its use of 
"environment", so that would have to be redefined anyway.

>> with the "old" let encoding.

Having to define ~10 compressed headers twice would be a source for errors, and 
a reader will see this and say "wow, 30 packet formats! I don't like this". If 
we're forced to define the same things twice, then the FN is lacking.

> I don't think we need the concept of "statements", only encoding methods 
> and formats, so I don't think that is a problem.
> 

Whatever we call it. By statement I meant "one line of FN definition" but I 
still consider it an ambiguity to see "let" in the middle of a format that makes 
the previous lines fail.

/Kristofer

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2004 16:47:18 +0200

On Oct 21 2004, at 16:24 Uhr, Kristofer Sandlund wrote:

> since you cannot put a "let" in uncompressed_format or default_methods

Then we should fix that (rather easy, I think).
(I thought we could, but then I have a somewhat simplified view of 
what's in the FN draft.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2004 16:54:30 +0200

On Oct 21 2004, at 16:24 Uhr, Kristofer Sandlund wrote:

> that makes the previous lines fail

Lines don't fail, formats do (and, if there is no format combination, 
the method fails).

4.9.3.2:
>    More formally, the compressor can choose any combination of an
>    uncompressed format and a compressed format for which all fields
>    "succeed", i.e.  the encoding methods succeed and there are 
> solutions
>    for all the let-statements (see Section 4.6).  If there is no such
>    combination, the encoding method defined by the structure "fails".

Gruesse, Carsten

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 22 Oct 2004 09:10:20 +0200

So, if it is that important to keep the "let" unmodified, then what if we just 
add a normal "if-else" construct that works the way _I_ want the "let" to work 
and we both get what we want?
That should solve the problem of uncompressed_format/default_methods having 
variable appearance as well as the problem of having to duplicate everything in 
infinity. Anyone who are likely to ever read the spec will know how this work, 
so defining it should be easy!

I could change back the packet formats very quickly to using "let" like you want 
it and use "if" to solve my remaining issues.

/Kristofer Sandlund, Effnet AB