Subject: [rohc] ROHC-FN comments, section 1-3

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 13:25:33 +0200

While re-reading the ROHC-FN draft, I have noticed a few issues
that I would like to have resolved, with or without the chair
hat on.

1) [chair hat on] Authors list: Can the authors please discuss and
   propose a responsible editor for this document, and put that
   person on top of the authors list. Richard should of course
   stay as an author of this document, but he is for sure not
   the editor any longer. I'll leave it up to the authors to 
   agree on this, just let me know.

2) Update the draft according to the new boilerplate (3667/3668).

3) Please expand ROHC->"RObust Header Compression" in the abstract.

4) Abstracts should not include references.

5) In the IPv4 example, section 3.3, something seems incorrect
   with the opening and closing braces. There is one opening brace
   at the end of page 8, another one at the end of page 9, and one
   single closing brace at the top of page 11. 

6) Should there be a semi-colon at the end of dont_frag [ 1 ], last
   item in the compressed_format?

7) Why is the compressed_format at all needed??? The only reason I
   can se is to allow re-ordering of fields between uncompressed
   and compressed format, which I can not see the point of. 
   I believe compressed_format should be implicitly given by the
   uncompressed_format along with the encoding of all fields, right?
   Redundancy???

8) Related to 7) is the point of the first paragraph at page 10.
   Why should the order of the two be independent?

9) Why is _inferred_ipv4_checksum not defined by the notation. I
   can not think of any more common header than the IPv4 header,
   i.e. all IPv4-supporting profiles will use this encoding.

More comments will follow on the rest of the document, but let's
take these first.

/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc.
Senior Research Engineer
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]
Phone: +46 8 404 29 61
Fax: +46 920 996 21
Home: +46 920 999 57

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.  

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 15:25:32 +0200

Lars-Erik,

Comments in-line,

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Lars-Erik Jonsson (LU/EAB)
> Sent: den 28 september 2004 13:26
> To: [email-masked]'
> Subject: [rohc] ROHC-FN comments, section 1-3
> 
> 

Will do.
 
> 2) Update the draft according to the new boilerplate (3667/3668).

Will do.
 
> 3) Please expand ROHC->"RObust Header Compression" in the abstract.

Ok. I think that the RFC-editor normally does that anyway.
 
> 4) Abstracts should not include references.

Will remove.
 
>    single closing brace at the top of page 11. 

There is one closing brace missing. Will fix.
 
>    item in the compressed_format?

No, because of the opening bracket that follows meaning that the statement describing the encoding of the packet is not yet complete. See example in 3.2.2. "Note that we show all possible encodings of a packet as defined by a given profile, separated by semi-colons."
 
>    uncompressed_format along with the encoding of all fields, right?

This is not redundant at all. My understanding is that this is necessary to create the binding between representations of a field in the compressed format and the coding method used for that field in the specific format. I.e. this is actually where the specification of the bits on the wire is done! Also, for a single field, different packet formats may use different encoding and since we have earlier decided to remove the Huffman encoding which allowed the compressed format to be defined only once, then it is necessary to spell out the compressed_format for each packet type.

Regarding reordering of fields, this can be useful when trying to align compressed fields to octet boundaries whenever possible, and if desired. Finally, control fields that are sent as part of the compressed header but that do not exist in the uncompressed header needs a place to be defined, and this is done in the compressed_format.
 
>    Why should the order of the two be independent?

To perform alignment to the octet boundary?
 
>    i.e. all IPv4-supporting profiles will use this encoding.

I actually have a comment on this as well. It will come in a later mail, if I can finally go back to the FN. I also think that it should be part of the formal notation.
 
> More comments will follow on the rest of the document, but let's

Thanks!

---

From: "Finking, Robert" <[email-masked]>
Date: Tue, 28 Sep 2004 14:58:55 +0100

Lars-Erik, Ghyslain,

Comments in-line

Regards

Raffles

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB) [mailto:[email-masked]] 
Sent: Tuesday, September 28, 2004 2:26 PM
To: Lars-Erik Jonsson (LU/EAB); [email-masked]'
Subject: RE: [rohc] ROHC-FN comments, section 1-3

.> 7) Why is the compressed_format at all needed??? The only reason I
.>    can se is to allow re-ordering of fields between uncompressed
.>    and compressed format, which I can not see the point of. 
.>    I believe compressed_format should be implicitly given by the
.>    uncompressed_format along with the encoding of all fields, right?
.>    Redundancy???
<snip>
.Regarding reordering of fields, this can be useful when trying to align .compressed fields to octet boundaries whenever possible, and if desired. .Finally, control fields that are sent as part of the compressed header but that .do not exist in the uncompressed header needs a place to be defined, and this .is done in the compressed_format.

Ghyslain is correct, however, it *is* true that despite the need for reordering there is still some redundancy here - we have two lists, one to specify order and another to specify encodings. We only actually need one list. So instead of:

    compressed_format =  src_addr       [ 32 ],
                         dest_addr      [ 32 ],
                         length         [ 16 ],
                         id             [ 16 ],
                         ttl            [  8 ],
                         protocol       [  8 ],
                         tos            [  6 ],
                         ecn            [  2 ],
                         dont_frag      [  1 ]
    {
      version             ::=   uncompressed_value (4, 4);
      header_length       ::=   uncompressed_value (4, 5);
      reserved            ::=   uncompressed_value (1, 0);
      more_fragments      ::=   uncompressed_value (1, 0);
      offset              ::=   uncompressed_value (13, 0);
      tos                 ::=   irregular (6);
      ecn                 ::=   irregular (2);
      length              ::=   irregular (16);
      id                  ::=   irregular (16);
      dont_frag           ::=   irregular (1);
      ttl                 ::=   irregular (8);
      protocol            ::=   irregular (8);
      src_addr            ::=   irregular (32);
      dest_addr           ::=   irregular (32);
      checksum            ::=   _inferred_ipv4_header_checksum;
    };
    
We could have:

    compressed_format =
    {  
      src_addr            ::=   irregular (32);
      dest_addr           ::=   irregular (32);
      length              ::=   irregular (16);
      id                  ::=   irregular (16);
      ttl                 ::=   irregular (8);
      protocol            ::=   irregular (8);
      tos                 ::=   irregular (6);
      ecn                 ::=   irregular (2);
      dont_frag           ::=   irregular (1);
      
      version             ::=   uncompressed_value (4, 4);
      header_length       ::=   uncompressed_value (4, 5);
      reserved            ::=   uncompressed_value (1, 0);
      more_fragments      ::=   uncompressed_value (1, 0);
      offset              ::=   uncompressed_value (13, 0);
      checksum            ::=   _inferred_ipv4_header_checksum;
    };

Which, apart from being more concise obviates the need for the annotation, removing another source of redundancy. However there is no proposal to switch over to this notation at this stage.
 
.> 9) Why is _inferred_ipv4_checksum not defined by the notation. I
.>    can not think of any more common header than the IPv4 header,
.>    i.e. all IPv4-supporting profiles will use this encoding.
.
.I actually have a comment on this as well. It will come in a later mail, if I .can finally go back to the FN. I also think that it should be part of the .formal notation.

Because ROHC-FN is a protocol independent notation. One of the main changes the FN has gone through in the last few months is a radical simplification process. We definitely do not want protocol specific features in a general notation.

I hope this is helpful.

Regards

Raffles

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 28 Sep 2004 16:23:33 +0200

> This is not redundant at all. My understanding is that this 
> is necessary to create the binding between representations of 
> a field in the compressed format and the coding method used 
> for that field in the specific format. I.e. this is actually 
> where the specification of the bits on the wire is done! 
> Also, for a single field, different packet formats may use 
> different encoding and since we have earlier decided to 
> remove the Huffman encoding which allowed the compressed 
> format to be defined only once, then it is necessary to spell 
> out the compressed_format for each packet type.

Yes, I think I get it now. However, the structures section 3.2.2
does not show the multiple formats side very well. Neither is it
clear from the pseudo structure how field1...n maps to field a...z.
The text should be clear about the former, and there should be
a more descriptive use of field a..., field 1..., etc.

Also, I do believe these could potentially be put together,
assuming that agree not to support reordering.

> Regarding reordering of fields, this can be useful when 
> trying to align compressed fields to octet boundaries 
> whenever possible, and if desired. Finally, control fields 
> that are sent as part of the compressed header but that do 
> not exist in the uncompressed header needs a place to be 
> defined, and this is done in the compressed_format.

I do not see the point of doing reordering to try to get some
octet alignment of individual fields, that approach
contradicts the idea of having flexible compressed formats.

When it comes to control fields, it should be possible to
capture also these in one format specification. See respons
to Roberts mail (will follow).

/L-E

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 29 Sep 2004 13:56:49 +0200

Ok, that was a clear answer, the only relation I could see.
Then, this should be clearly spelled out, and please 
explain the field names used in 3.2.2, there the fields
are different in uncompressed and compressed form. This
was actually the source of my confusion, as I tried to
understand the example of 3.3 in light of the previous
section, 3.2.2.

/L-E

> From: Carsten Bormann [mailto:[email-masked]]
> Sent: den 29 september 2004 13:47
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: Ghyslain Pelletier (LU/EAB); 'Finking, Robert'; Carsten Bormann;
> [email-masked]'
> Subject: Re: [rohc] ROHC-FN comments, section 1-3
> 
> 
> Right now, a field has a name.
> It has both a compressed and an uncompressed side.
> It has an encoding method (once a format is selected).
> We list the encoding method in the compressed format, as this is more 
> likely to have multiple variants than the uncompressed format.
> 
> Given this view, having two names for a field does not make 
> much sense.
> 
> Gruesse, Carsten
>

---

From: "Finking, Robert" <[email-masked]>
Date: Wed, 29 Sep 2004 14:12:30 +0100

L-E, All,

I've got a few outstanding updates I need to do to the document, and fortunately have a few cycles spare the latter half of this week, so I'll go ahead and do the fixes this week.

More in-line below

Regards

Raffles

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) [mailto:[email-masked]] 
Sent: Wednesday, September 29, 2004 12:20 PM
To: Finking, Robert; Ghyslain Pelletier (LU/EAB); [email-masked]'
Subject: RE: [rohc] ROHC-FN comments, section 1-3
<snip>

=]If we keep both uncompressed and compressed, I would instead
=]ask for a clearer coupling between the two, or actually between
=]fields from the two. Neither the compressed format list nor the
=]encoding of each field for a compressed format do formally create
=]a relation to an uncompressed field. The only coupling I can see
=]is the actual name, e.g. "tos", which is the same. If that is how
=]they are coupled together, that should be spelled out clearly.
=]The structure description in 3.2.2 does not make this clear, to
=]me it was just confusing. As Ghyslain pointed out to me, tos[6]
=]in the uncompressed_format is not the same as tos[6] in a
=]compressed_format. I get that, as the compressed version is of
=]course usually a smaller representation. Then I wonder, which
=]of the two is actually part of the "::=", or "is encoded as", 
=]listing, is it the uncompressed or the compressed. I would
=]rather say that u_tos->c_tos ::= irregular(6), or by other
=]means have a reference to both in the encoding description.

Yes, the coupling is the field name. But the coupling is defined in terms of attributes that actually are not so dissimilar to the "u_tos->c_tos" you specify. Each field has several values associated with it, called attributes. Two of the attributes are "uncompressed_value" and "compressed_value". The irregular encoding method provides a mapping between these two attributes. Not all encoding methods do this however. Others provide mappings between different attributes - it is not always as simple as just describing a relationship between a compressed and uncompressed value.

I'll add a bit to section 3.2.2, but please note that this section is *not* the section that describes structures. The whole of section 3 is a brief overview of the whole notation, such as you often get at the start of any programming language manual. As such 3.2.2. aims to convey the basic concept without going into any more detail than is necessary to get the picture across. However, I'll warrant that the fundamental multi-value nature of fields needs to be communicated effectively for this section to be much use!

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 29 Sep 2004 15:41:47 +0200

Ok, to clarify some more...

In 3.2.2, I had expected the list of fields in a compressed_format
to be a subset of the uncompressed_format list, potentially plus
control fields. I am not sure if the current field_1... vs
field_a... was supposed to be generic to cover all potential
cases, but to me it was hard to understand the relationship.

Maybe just some additional text about what is meant vith these
field_* and how compressed vs uncompressed maps to each other
would be sufficient.

I think the example in 3.3 is suitable where it appears in the
document, but I would hope a reader should be able to understand
it by just reading section 1 to 3.2.2. 

/L-E

> From: Finking, Robert [mailto:[email-masked]]
> Sent: den 29 september 2004 15:13
> To: Lars-Erik Jonsson (LU/EAB); Ghyslain Pelletier (LU/EAB);
> [email-masked]'
> I've got a few outstanding updates I need to do to the 
> document, and fortunately have a few cycles spare the latter 
> half of this week, so I'll go ahead and do the fixes this week.
> 
> More in-line below
> 
> Regards
> 
> Raffles
> 
> Yes, the coupling is the field name. But the coupling is 
> defined in terms of attributes that actually are not so 
> dissimilar to the "u_tos->c_tos" you specify. Each field has 
> several values associated with it, called attributes. Two of 
> the attributes are "uncompressed_value" and 
> "compressed_value". The irregular encoding method provides a 
> mapping between these two attributes. Not all encoding 
> methods do this however. Others provide mappings between 
> different attributes - it is not always as simple as just 
> describing a relationship between a compressed and uncompressed value.
> 
> I'll add a bit to section 3.2.2, but please note that this 
> section is *not* the section that describes structures. The 
> whole of section 3 is a brief overview of the whole notation, 
> such as you often get at the start of any programming 
> language manual. As such 3.2.2. aims to convey the basic 
> concept without going into any more detail than is necessary 
> to get the picture across. However, I'll warrant that the 
> fundamental multi-value nature of fields needs to be 
> communicated effectively for this section to be much use!
> 
> -- 
> 
> Visit our website at www.roke.co.uk
> 
> Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
> 
> The information contained in this e-mail and any attachments 
> is confidential to
> Roke Manor Research Ltd and must not be passed to any third 
> party without
> permission. This communication is for information only and 
> shall not create or
> change any contractual relationship.
>