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

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

Robert, Lars-Erik,

More comments in-line,

///Ghyslain
> 
> 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.

I think that the current way of specifying this is more clear in terms of readability of the packet formats and bits on the wire.
  
> .> 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.

Actually, I will be discussing this point further when I send my comments. What I thought that we definitely did not want with the formal notation is to have encoding methods defined in english language. It seems that leaving out this encoding method and opening the door to methods not defined formally is inconsistent with the original objective of the notation itself...

   "Its definition is given in the English language part of the profile.
   To indicate this, the first character of its identifier is an
   underscore."

If _inferred_ipv4_checksum on the other hand is defined _formally_ into profiles, then it can be ok. But still, I think that this method would be useful enough to define in the ROHC-FN draft.

BTW, is it acceptable to "overload" a method in a profile instead?
In this way, we could define this method in the general library without preventing profiles to redefine it formally? Ah, maybe not a good idea after all...
 
> I hope this is helpful.
> 
> Regards
> 
> Raffles
> 
> -- 
> 
> 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.
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Sep 2004 18:18:05 +0200

On Sep 28 2004, at 16:16 Uhr, Ghyslain Pelletier (LU/EAB) wrote:

> I think that the current way of specifying this is more clear in terms 
> of readability of the packet formats and bits on the wire.

Also, leaving out the field list from the compressed format would 
remove the possibility to have fields that are not represented in the 
compressed packet.

Also, I believe the default_format mechanism is more useful for 
minimizing the amount of redundancy than removing the field list would 
be.

Gruesse, Carsten