Subject: [rohc] Expressing scaaled compression of fields in ROHC-FN.

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 21 Apr 2005 14:58:20 +0200

Hi all!

The main obstacle remaining in expressing the TCP packet formats in ROHC-FN 
seems to be the one related to the scaled sequence and ack numbers (previously 
discussed on the list a number of times regarind division by zero etc).

And for a packet with an unscaled sequence number (for example co_format_rnd_1), 
we would need to have some kind of if-statement so that we can say (because of 
the zero-divison issue):
    if (payload_size == 0)
        let (seq_number_residue:uncomp_value == seq_number:uncomp_value);
        let (seq_number_scaled:uncomp_value == 0);
    else
       let (seq_number_residue:uncomp_value ==
                mod(seq_number:uncomp_value, payload_size));
       let (seq_number:uncomp_value ==
            seq_number_scaled:uncomp_value * payload_size +
            seq_number_residue:uncomp_value);

Currently, these expressions are placed in the control_fields of co_baseheader 
like this:

    control_fields  =
    {
       let (seq_number_scaled:uncomp_value ==
                seq_number:uncomp_value / payload_size);
       let (seq_number_residue:uncomp_value ==
                mod(seq_number:uncomp_value, payload_size));
    };

But, as anyone can see, the payload of zero will fail to bind for all packet 
formats with this. So, we thought about having two different control_field 
definitions like this:

   control_fields_no_payload =
   {
     let(payload_size == 0);
     let (seq_number_residue:uncomp_value ==
          seq_number:uncomp_value);

     let (seq_number_scaled:uncomp_value == 0);
   };

   control_fields_with_payload =
   {
     let(payload_size != 0);
     let(seq_number_residue:uncomp_value ==
         mod(seq_number:uncomp_value, payload_size));
     let(seq_number:uncomp_value ==
        seq_number_scaled:uncomp_value * payload_size +
        seq_number_residue:uncomp_value);
   };

But, this approach does NOT scale. Since we have two fields to handle (seq/ack), 
then we're up to 4 control_fields definitions and one more field takes us to 8, 
so no, this is not going to scale in a way that makes FN usable.

Therefore, we need to be able to express if-statements in ROHC-FN. Yes, I know 
we've had this discussion multiple times before and gotten around it, but we 
can't just keep patching things when we all the time get back to the fact that 
if-statements will make this easier! I've discussed this with both Robert and 
Ghyslain offline, and we got no further than to if-statements. So, the syntax we 
would like to add is:

control_fields =
{
     let(payload_size == 0)
     {
           let (seq_number_residue:uncomp_value == seq_number:uncomp_value);
           let (seq_number_scaled:uncomp_value == 0);
     }
     let(payload_size != 0)
     {
           let(seq_number_residue:uncomp_value ==
               mod(seq_number:uncomp_value, payload_size));
           let(seq_number:uncomp_value ==
               seq_number_scaled:uncomp_value * payload_size +
               seq_number_residue:uncomp_value);
     }

}

So that each let _can_ contain a block-statement and we can bind to one of these 
. If that wrecks havc with the FN syntax, We just replace the "conditional let" 
with "if", which I guess would be reasonably easy to define.

Feedback, please. With this addition, I think we would be done with the FN draft 
and the TCP packet formats will be syntactically finished (even if the content 
can still be discussed).

BR,
	Kristofer Sandlund, Effnet AB

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

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 21 Apr 2005 14:22:35 +0100

Hi Kris,

Thanks for posting on this. Comments inline below:

Raffles

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]] 
<snip>
>                seq_number_residue:uncomp_value);

A couple of things, first a tiny one. I'm thinking of it syntactically
as the encodings-list being part of the let-statement (same as other
encodings lists are part of their parents), so that would mean that the
semi-colon associated with the let would appear after the close brace.

Second, there is no reason we should restrict the condition to being a
let statement, we could use any binding as a condition. E.g. we could
do:

{
   foo ::= uncompressed_value(6,4)
   {
     blah
   };

   foo ::= lsb(3,0)
   {
     blah
   };

   foo ::= irregular(6)
   {
     blah
   };
}

However we see a problem with the above, which is also an issue with let
statements, though less obviously so: you may want to make two (or more)
alternatives mutually exclusive. In the above, the irregular form will
always succeed, so what happens if lsb also succeeds? We need syntax to
list alternatives. Your earlier if-else syntax seems to fit the bill
(did I hear a cheer from L-E?):

{
   if foo ::= uncompressed_value(6,4)
   {
     blah
   }
   elsif foo ::= lsb(3,0)
   {
     blah
   }
   else
   {
     foo ::= irregular(6)
     blah
   };
};

Maybe this is overkill though?

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 21 Apr 2005 14:45:37 +0100

Hi Ghyslain,

Just to clarify what you mean, to rewrite my example in your syntax:

{
   {

   {
     foo ::= lsb(3,0)
     blah
   };

   {
     foo ::= irregular(6)
     blah
   };
}

Here, each of the items in braces would fail if either the encoding of
foo failed or blah failed (in which case all would fail as they all
contain blah).

Is that what you mean?

Thanks

Raffles
> From: Ghyslain Pelletier (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 2:34 PM
> To: Kristofer Sandlund; [email-masked]
> Subject: RE: [rohc] Expressing scaaled compression of fields 
> in ROHC-FN.
> 
> 
> Kristoffer,
> 
> I rethought about this. The issue is not about having a 
> conditional, but rather an issue on scoping. I think the 
> "let" statement that "fails" the entire scope of the packet 
> format is needed and shouldn't be changed. What you are after 
> is to assert one part of the scope of a packet format without 
> "failing" the entire format.
> 
> I suggest instead that we allow the use of a scoping 
> operater, e.g. the braces "{" and "}" that we already use 
> could be used to add one scoping level to englobe the let as 
> a conditional that does not fail the entire scope of the 
> packet format.
> 
> Thoughts?
> 
> /Ghyslain 
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Kristofer Sandlund
> > Sent: den 21 april 2005 14:58
> > To: [email-masked]
> > Subject: [rohc] Expressing scaaled compression of fields in ROHC-FN.
> > 
> > 
> > Hi all!
> >

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 21 Apr 2005 15:41:21 +0100

Hej =)

Looks like we both posted at the same time, but since we both have the
same understanding, I'll assume we got it right. I like this syntax as
it is simple and requires nothing more than allowing nesting of
encodings lists. However... inline

Regards

Raffles

> Sent: Thursday, April 21, 2005 2:43 PM
> To: Ghyslain Pelletier (LU/EAB)
> Cc: [email-masked]
> Subject: Re: [rohc] Expressing scaaled compression of fields 
> in ROHC-FN.
> 
> 
> Hej!
> 
> If I understand you correctly you suggest syntax like:
> 
> co_format_example
> {
>      {
>         let(value == 0)
>         blah ::= static;
>      }
>      {
>         let(value != 0)
>         blah ::= irregular;
>      }
> }
> 
> If so, that seems to work.
> I'd _like_ for it to be more explicit on when things are 
> mutually exclusive and 
> when both can match, since more complex conditions will 
> probably be easy to mess 
> up for the profile writer. 

I heartily agree. It's not just the writer either, but the reader of the
profile who needs to be able to see the intent clearly. I'd like to
suggest a very subtle change of syntax to allow mutual exclusivity to be
communicated.

At the structure level, we currently use a collection of labels which
start with the same prefix (e.g. "co_format"). Instead of having a
collection of separate items, why not make them into a single list of
items? This means
  1. they must follow one after another, instead of allowing e.g.
     "default_methods" to appear half way through the list
  2. only one semi-colon is needed at the very end of the list.

To give an example from the TCP-PF:

variable_length_16_enc(flag) ===
{
        uc_format = field; %[ 16 ]

        co_format_not_present = field, %[ 0 ]
        {
           let(flag == 0);
           field ::= static;
        }
        co_format_8_bit = field, %[ 8 ]
        {
           let(flag == 1);
           field ::= lsb(8, 63);
        }
        co_format_16_bit = field, %[ 16 ]
        {
           let(flag == 2);
           field ::= irregular(16);
        };
};

All that has happened here is that the three individual encoding methods
for 0 bit, 8 bit and 16 bit, have become a list of encoding methods.
Using Ghyslain's modification (allowing nesting) on Kris' example, if we
want to indicate explicitly that they're mutually exclusive:

 co_format_example
 {
      alternative_1 =
      {
         let(value == 0)
         blah ::= static;
      }
      alternative 2 =
      {
         let(value != 0)
         blah ::= irregular;
      };
 }

If they're not mutually exclusive:

 co_format_example
 {
      alternative_1 =
      {
         let(value == 0)
         blah ::= static;
      };

      alternative 2 =
      {
         let(value2 != 0)
         blah ::= irregular;
      };
 }

PS nice to see others using "blah" far superior to "bar" =)

How does this sit with everyone? (incidentally I much prefer it to my
own previous suggestion)

Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 21 Apr 2005 15:47:43 +0100

Apologies, correction to my final example (note the labels don't share a
prefix):

 co_format_example
 {
      a_block =
      {
         let(value == 0)
         blah ::= static;
      };

      different_block =
      {
         let(value2 != 0)
         blah ::= irregular;
      };
 }

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 21 Apr 2005 15:55:23 +0100

Carsten, 

Feel free to note also the missing parameters for irregular encoding and missing final semi-colon if you're feeling extra nitpicky today! ;-)

Without Kris and I rewriting our running example with field lists, do you think you could see past the minor imperfections in the to the question being asked?

Or does the lack of field order lists impact the example in some way that I've missed? - that was a serious question by the way; I'm perfectly capable of major imperfections as well as minor ones ;-)

Regards

Raffles

> From: Carsten Bormann [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 3:46 PM
> To: Finking, Robert
> Cc: Carsten Bormann
> On Apr 21 2005, at 16:41 Uhr, Finking, Robert wrote:
> 
> > How does this sit with everyone?
> 
> Your examples are missing the field lists.
> 
> Gruesse, Carsten
>

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 21 Apr 2005 16:39:30 +0100

Hi,

You're right, it wasn't entirely obvious that it wasn't entirely
obvious. I guess the fact that I needed to clarify that it wasn't
entirely obvious that it wasn't entirely obvious, means that from your
point of view it wasn't entirely obvious that it wasn't entirely obvious
that it wasn't entirely obvious =)

You're asking do we have this:

 co_format_example = blah
 {
      a_block =
      {
         let(value == 0)
         blah ::= static;
      };

      different_block =
      {
         let(value2 != 0)
         blah ::= irregular;
      };
 };

or this:

 co_format_example =
 {
      a_block = blah
      {
         let(value == 0)
         blah ::= static;
      };

      different_block = blah
      {
         let(value2 != 0)
         blah ::= irregular;
      };
 };

? I have assumed the former, otherwise, where do we put the field order
info for stuff in the following example:

 co_format_example = 
 {
      a_block = blah
      {
         let(value == 0)
         blah ::= static;
      };

      different_block = blah
      {
         let(value2 != 0)
         blah ::= irregular;
      };

      stuff ::= lsb(9,9);
 };

? I guess you could do it recursively:

 co_format_example = stuff,
                     a_block,
                     different_block
 {
      a_block = blah
      {
         let(value == 0)
         blah ::= static;
      };

      different_block = blah
      {
         let(value2 != 0)
         blah ::= irregular;
      };

      stuff ::= lsb(9,9);
 };

And if you had a list of alternatives you then give the prefix of the
list as the label, which would be nice because it would mean you'd
declared the label prefix somewhere:

 co_format_example = stuff,
                     a_block
 {
      a_block_1 = blah
      {
         let(value == 0)
         blah ::= static;
      }
      a_block_2 = blah
      {
         let(value2 != 0)
         blah ::= irregular;
      };

      stuff ::= lsb(9,9);
 };

now that I like! Simple and powerfully expressive. What does everyone
else think?

Raffles

> Sent: Thursday, April 21, 2005 4:01 PM
> To: Finking, Robert
> Cc: Carsten Bormann
> On Apr 21 2005, at 16:55 Uhr, Finking, Robert wrote:
> 
> > does the lack of field order lists impact the example in 
> some way that 
> > I've missed
> 
> I'd just like to know where you want to put them (in case it's not 
> obvious, this is not entirely obvious).
> (The semicola I can place :-)
> 
> Gruesse, Carsten
>

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 22 Apr 2005 10:24:45 +0200

Hi Robert,

I could like the idea of this being solved in a similar fashion as for lists, by using the prefix of the block name to make things mutually exclusive. But I don't understand what you meant by "doing it recursively".

However, I thought that we only needed to fix scoping for let statements, why do we want to add the notion of mutually exclusive - is this necessary?

Another question, is this instead of the earlier proposal of using brackets to scope the "let" so that only the alternative fails and not the entire format?

/Ghyslain

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Finking, Robert
> Sent: den 21 april 2005 17:40
> To: [email-masked]

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 22 Apr 2005 12:49:41 +0100

Hi Ghyslain,

Thanks for the reply. Answers in-line =)

Raffles

> Sent: Friday, April 22, 2005 9:25 AM
> To: Finking, Robert; [email-masked]
> I could like the idea of this being solved in a similar 
> fashion as for lists, by using the prefix of the block name 
> to make things mutually exclusive. But I don't understand 
> what you meant by "doing it recursively".

All I meant was, being able to use the packet format syntax inside a
packet format. That way we don't have to define special notation to
handle the fixed scoping of let statements - we use the existing
notation instead.

> 
> However, I thought that we only needed to fix scoping for let 
> statements, why do we want to add the notion of mutually 
> exclusive - is this necessary?

Well strictly speaking no, we could just about get away without it for
the TCP profile. However, the profile should be clearer if we can notate
explicitly that two blocks are mutually exclusive: e.g. you can't have a
packet that has a payload and doesn't have one.

> 
> Another question, is this instead of the earlier proposal of 
> using brackets to scope the "let" so that only the 
> alternative fails and not the entire format?
> 

Yes, it's an enhancement of it. Your excellent suggestion was so similar
to the syntax that we use to group packet formats, why don't we use that
syntax for this too? That way we don't need to have any special notation
for this AND it gives us the ability to notate mutual exclusion for
free.

My idea of using lists was just a nicety, we could stick with the exact
same syntax we have now. Here is the last example of my previous mail,
rewritten with current packet format syntax (i.e. not using lists):

      a_block_2 = blah
      {
         let(value2 != 0)
         blah ::= irregular;
      };

      stuff ::= lsb(9,9);
 };

Does that answer your question? It is slightly more verbose than your
example, but since it uses the full packet format syntax, it is also
more powerful, and yet simpler in that it just reuses part of the
notation that already exists.

Raffles