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

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

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

Well, now this proposal is here...=)
Something like this was what I asked for. However, I've seen the
points raised by Ghyslain and Carsten and those arguments makes
sense.

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.

Thus, I miss some glue here...

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

Well it is generic to some degree, but it is not supposed to be
used for *any* purpose. It is defined for ROHC profile definition,
which means we always have IP to compress, i.e. as long as
profiles are defined for both v4 and v6 (as done so far), ALL
profiles will use this encoding method. I would not call this
profile specific. The simplification process worries me in its
objective, which seems to deviate from the goal of creating a
useful tool for ROHC profile specification.

/L-E

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Sep 2004 13:46:45 +0200

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