Subject: RE: [rohc] ROHC-FN: Changing the behavior of the "let" encoding m ethod

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 22 Oct 2004 10:15:08 +0200

I agree with Kristofer here. Let's add the "if-else" conditional and leave the "let" statement as it is.

We can also add a clarification in the ROHC-FN draft about the environnement of the "let" failing.

/Ghyslain

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 22 oktober 2004 09:10
> To: Carsten Bormann
> Cc: Eilert Brinkmann; West, Mark; [email-masked]; Lars-Erik Jonsson
> (LU/EAB); Finking, Robert; Ghyslain Pelletier (LU/EAB)
> Subject: Re: [rohc] ROHC-FN: Changing the behavior of the 
> "let" encoding
> method
> 
> 
> 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
> 
> Carsten Bormann wrote:
> > 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
> > 
> > 
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: Eilert Brinkmann <[email-masked]>
Date: Fri, 22 Oct 2004 11:25:36 +0200

> leave the "let" statement as it is.

At least I like that more than changes to the old meaning of
let. However, I think the present problems can be solved even without
this addition, and especially without introducing conditionals in
field order lists.

In the specification I see three places where the proposed new "let"
syntax is used in a way that has no direct equivalent in the old
syntax. They are all distinctions between IPv4 und IPv6 in the
co_baseheader structure. One use is in default_methods:

   default_methods = 
   {
      [...]
      let (version:uncomp_value == 6) {
         flow_label                ::= static;
      };
      let (version:uncomp_value == 4) {
         header_length             ::= uncompressed_value (4,5);
         length                    ::= inferred_ip_v4_length;
         ip_id                     ::= irregular(16);
         rf                        ::= static;
         df                        ::= static;
         mf                        ::= static;
         frag_offset               ::= static;
         checksum                  ::= inferred_ip_checksum;
      };
      [...]
   };

I think, simply removing the conditions and defining the encodings
unconditionally wouldn't do any harm here. If a field is not present
in a format, encodings defined for this field remain unused.

Then in format_co_common there are these lines:

             let (version:uncomp_value == 4) {
                df              ::= irregular(1);
             }
             let (version:uncomp_value == 6) {
                df              ::= compressed_value(1,0);
             }

This could still be done the "old way", i.e. by using something like

             df ::= dont_fragment(version:uncomp_value);

and a structure which defines the two different formats:

   dont_fragment(version) ===
   {
           uncompressed_format = df;
   
           compressed_format_v4 = df,
           {
                   let (version == 4);
                   df ::= irregular(1);
           };
   
           compressed_format_v6 = df,
           {
                   let (version == 6);
                   df ::= compressed_value(1,0);
           };
   };

So the only remaining problem would be the selection between the two
uncompressed formats which you do by conditionals in the field order
list:

   uncompressed_format = version,
                         tos_tc,
                         ip_ecn_flags,
                         ttl_hopl,
                         next_header,
                         src_addr,
                         dest_addr,
                         let (version:uncomp_value == 6) {
                            flow_label,
                         },
                         let (version:uncomp_value == 4) {
                            header_length,
                            length,
                            ip_id,
                            rf,
                            df,
                            mf,
                            frag_offset,
                            checksum,
                         },
                         [...TCP part...];

By the way: The IPv6 payload length field is missing and this field
order list does not give the correct order of fields in uncompressed
IP headers -- neither for IPv4 nor for IPv6. Is this simply a mistake
or do I have missed anything here? And the current specification does
not bind version:uncomp_length.

Back to the original problem -- how about using two diffent
uncompressed formats instead of only one with conditional parts in
it's field order list? A question would be how to bind the value of
the version field according to the used uncompressed format. Maybe we
could extend the FN to allow the specification of let expressions (and
possibly field encodings, too?) in uncompressed formats in a sense
like "default methods specific to a single uncompressed format". I.e.,
unlike things defined in default_methods, which are included in all
compressed formats in every case, these would be included only when a
packet has the specific uncompressed format. So in the TCP case the
uncompressed formats could look like this:

	uncompressed_format_v4 = version,
			         header_length,
			         tos_tc,
			         ip_ecn_flags,
			         length,
			         ip_id,
			         df,
			         mf,
			         rf,
			         frag_offset,
			         ttl_hopl,
			         next_header,
			         checksum,
			         src_addr,
			         dest_addr,
			         [...TCP part...],
	{
		let (version:uncomp_value == 4);
	};

	uncompressed_format_v6 = version,
			         tos_tc,
			         ip_ecn_flags,
			         flow_label,
			         payload_length,
			         next_header,
			         ttl_hopl,
			         src_addr,
			         dest_addr,
			         [...TCP part...],
	{
		let (version:uncomp_value == 6);
	};

An alternative would be to deduce the version number from the presence
of version specific fields in the header. This might be possible even
without any extentions to the FN if we assume that for fields which
are not present in the uncompressed header
(fieldname:uncomp_value == null) is true.

> environnement of the "let" failing.

I would appreciate that, as well as an addition that allows let in
default_methods (meaning that this let expression will be added to all
compressed formats, but unlike default field encodings can not be
overridden).

Regards

Eilert

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 22 Oct 2004 13:18:29 +0200

Hi Eilert and thanks for your suggested solutions.

Some comments inline.

> in a format, encodings defined for this field remain unused.

Ok, I can live with that.

>                    df ::= compressed_value(1,0);

Ok that works for me.

> or do I have missed anything here? 

Crap, does the FN force order also in the uncompressed format? I thought it was 
only in the compressed formats. I can fix that since it makes no difference to me.

 > And the current specification does

Eh? Does it need to? (if it does, then please suggest text that fixes this to 
the FN-draft and mail it to Ghyslain)

> 		let (version:uncomp_value == 6);

This change would be ok with me. What kind of worries me is that currently, 
"uncompressed_format" is a reserved work, and now we'd have multiple different. 
Will this be a problem?
If we do this, we would have to update some FN text. Could you suggest some text 
for the "structures" section that would explain this?

> (fieldname:uncomp_value == null) is true.

This I don't like, so I think your previous suggestion is a lot better.

> compressed formats, but unlike default field encodings can not be

Again, please suggest some text, it doesn't have to be perfect just as long as 
it's good enough for getting out a draft on monday, so we can have some common 
ground to discuss from and show the rest of the list where we are right now.

I'll immediately update the tcp-pf with these suggestions and will check it into 
the CVS (we can always fall back to the old stuff).

BR,
	Kristofer Sandlund, Effnet AB

---

From: Eilert Brinkmann <[email-masked]>
Date: Fri, 22 Oct 2004 14:16:22 +0200

Kristofer Sandlund wrote:
> Crap, does the FN force order also in the uncompressed format? I
> thought it was only in the compressed formats. I can fix that since it
> makes no difference to me.

Well, these lists are called field order lists ;-) At the end of
section 3.2 the draft explicitly says that the list "indicates the
order of fields in the uncompressed header", the same in sections
4.9.1 and 4.9.1.1. Maybe the second paragraph in 4.9.1.1 does not
clear enough say that the notator is free to change the arrangement of
uncompressed fields regarding field boundaries, but not field order?

> Eh? Does it need to? (if it does, then please suggest text that fixes
> this to the FN-draft and mail it to Ghyslain)

My understanding was that a FN specification should specify everything
needed for the mapping between uncompressed and compressed headers,
which would include all information about involved packet formats like
order and length of fields in the compressed as well as the
uncompressed headers. Am I wrong with this?

> This change would be ok with me. What kind of worries me is that
> currently, "uncompressed_format" is a reserved work, and now we'd have
> multiple different. Will this be a problem?
> If we do this, we would have to update some FN text. Could you suggest
> some text for the "structures" section that would explain this?

This is already part of the "multiple formats" section, especially in
section 4.9.3.1:

|   Similarly, if multiple uncompressed formats are defined, they must be
|   defined using names beginning with "uncompressed_format".

Also section 4.9.5 contains an example with two different
uncompressed formats in one structure.

> This I don't like, so I think your previous suggestion is a lot better.

I agree.

Unfortunately I'm in a meeting now. I will try to write some
suggestions for text changes later.

Eilert

---

From: Kristofer Sandlund <[email-masked]>
Date: Fri, 22 Oct 2004 14:33:48 +0200

Comments inline

> uncompressed fields regarding field boundaries, but not field order?

You're right, but the text could be more clear. It does not clearly state that 
changing order is illegal, so an extra sentence there might make it even better. 
Ghyslain, can you fix that?

> uncompressed headers. Am I wrong with this?

Hmm... but (it might be that I'm misunderstanding you here) does any field get 
its length specified in uncompressed_format? So, I don't see why version should 
be an issue while the others would not be an issue. But if there's a problem 
then go ahead and fix it, I don't have to understand the exact details...

> uncompressed formats in one structure.

I clearly have some reading problems today. You're right. One less issue to 
worry about.

> suggestions for text changes later.

Sounds good.

/Kristofer

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 22 Oct 2004 14:35:44 +0200

On Oct 22 2004, at 14:33 Uhr, Kristofer Sandlund wrote:

> changing order is illegal

Well, changing the order of the uncompressed fields is certainly legal, 
it just means that you get a different uncompressed packet (i.e., your 
uncompressed packet is carved up into fields in a different way)...

Gruesse, Carsten

---

From: Eilert Brinkmann <[email-masked]>
Date: Fri, 22 Oct 2004 14:54:38 +0200

Kristofer Sandlund wrote:
> Hmm... but (it might be that I'm misunderstanding you here) does any
> field get its length specified in uncompressed_format? So, I don't see
> why version should be an issue while the others would not be an
> issue. But if there's a problem then go ahead and fix it, I don't have
> to understand the exact details...

In most cases the uncomp_length attributes are bound by the encoding
methods used for the fields, e.g.:

- static: same length as in context

- irregular: length specified by the method argument

- uncompressed_value: uncomp_length specified by argument , compressed
  side does not exist or has comp_length == 0

- compressed_value and crc: comp_length specified by argument,
  uncompressed field does not exist or has uncomp_length == 0

But the specification does not give a "normal" encoding method for
version and binds only uncomp_value using a let expression. So we
could add

  let (version:uncomp_length == 4);

or replace

with

  version ::= uncompressed_value(4, 4);

(assuming we can specify a field encoding in every place where let can
be used).

Eilert

---

From: Eilert Brinkmann <[email-masked]>
Date: Mon, 25 Oct 2004 09:32:57 +0200

Kristofer Sandlund wrote:
> Again, please suggest some text, it doesn't have to be perfect just as
> long as it's good enough for getting out a draft on monday, so we can
> have some common ground to discuss from and show the rest of the list
> where we are right now.

Sorry for being a bit late, but here are suggestions for a few text
changes regarding the topics discussed on friday. (I refer to
draft-ietf-rohc-formal-notation-04-V1-EPLGHPE-pa0-raf5.txt as this
seems to be the latest version I have.)

- Section 4.6 ("Let")

  Add the following clarification:

    A let-statement is always part of a field encodings list.

- Section 4.9.1.1 ("uncompressed_format")

  Add the following paragraph:

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

  To make clear that the length of fields in the uncompressed header
  must be defined by an FN specification, the following text could be
  inserted after the first paragraph of 4.9.1.1:

    (Note that it is not sufficient that the annotations say this --
    the encoding methods defined for the fields must define the
    uncomp_length attribute so there is an unambiguous mapping from
    the bits in the uncompressed header to the fields listed in the
    field order list.)

- Section 4.9.3.3 ("Default Encoding Methods - default_methods")

  Add the following paragraph:

    The field encodings list of default_methods may also contain
    let-statements. In this case every compressed format of the
    structure can only succeed if the specified expressions evaluate
    to true. Note that let-statements can not be overridden in
    compressed formats.

Regards

Eilert