Subject: [rohc] Question about ROHC FN

From: Haipeng Jin <[email-masked]>
Date: Wed, 05 Nov 2003 08:35:19 -0800

Hi,

I am reading ROHC FN draft 02 and get confused about the following definitions:

The "from_list" encoding method defined in 5.3.3 is used to extact the 
presence and order flags from a list of items encoded with the 
list_of_known_length encoding method. The order_flag and and presence_flag 
are all control fields defined in 5.4.3 to indicate whether there are 
changes of order and presence in the list_of_known_length. These are all clear.

However, I am confused about their usage in the example shown at the end of 
5.4.3. The relevant part of the example is copied as follows.

    list_eg               ::= single_packet_format,
    {
         ...
      order_flag          ::= control_field,
      {
        base_field        ::= same_as(list_eg.list_of_fields.order_flag),
        compressed_method ::= irregular(1)
      },

      presence_flag       ::= control_field,
      {
        base_field        ::= same_as
                                  (list_eg.list_of_fields.presence_flag),
        compressed_method ::= irregular(1)
      },

      list_of_fields      ::= list_of_known_length,
      {
        list_length       ::= constant(8),
        order_flag        ::= from_list(list_eg.order_flag),
        presence_flag     ::= from_list(list_eg.presence_flag),
           ...
      }
    }

This seems to be a circular definition. For example, list_eg.order_flag is 
same_as(list_eg.list_of_fields.order_flag), while 
list_eg.list_of_fields.order_flag is from_list(list_eg.order_flag). Could 
anyone please explain it to me? Have I misunderstood anything here?

Thank you very much.
Haipeng

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

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 7 Nov 2003 13:42:34 -0000

Jin,

Thanks for your question about "from_list" encoding. The whole of list encoding is certainly the most complicated aspect of the ROHC-FN proposal - thank you for taking the time to absorb it.

The answer is fairly straightforward; the notation covers both the information needed for encoding and that needed for decoding. The "from_list" encoding method looks at both the compressed and uncompressed packet to see which it knows. If  the uncompressed packet value (i.e. at the compressor), then the value is calculated from the uncompressed packet and associated context, as described in the FN draft. If the compressed packet value is known then the value is extracted directly from the compressed packet. This was not made explicit in the draft, thanks for highlighting the need for clarification on this point.

As an aside, this technique is also used elsewhere. If you look at the contemporary TCP profile (http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt), in section 6.5.2. Default encoding methods, you will see that the notation for encoding a sequence number uses a similar technique. The definition appears to be circular:

       tcp_seq_number             ::=   derived_value,
       { field_length             ::=   constant(32),
         field_value              ::=
                              expression(uncomp(tcp_seq_number_scaled) *
                              uncomp(tcp_payload_size)                 +
                              uncomp(tcp_seq_number_residue))
       },

	 ...

       tcp_seq_number_scaled        ::=   control_field,

       { base_field                 ::=
                           expression(uncomp(tcp_ip.tcp_seq_number) //
                           uncomp(tcp_ip.tcp_payload_size)),
         compressed_method          ::=   static
       },

       tcp_seq_number_residue       ::=   control_field,

       { base_field                 ::=
                           expression(uncomp(tcp_ip.tcp_seq_number) mod
                           uncomp(tcp_ip.tcp_payload_size)),
         compressed_method          ::=   static
       },
       ...

Here we have sequence number defined in terms of scaled value and residue. We also have scaled value and residue defined in terms of sequence number. This looks circular, however one is use for compression and the other for decompression. If the value of a field is known a priori, then there is no need to calculate it.

The obvious question is why this doesn't happen with all encoding techniques. The fact is that most of them are sufficiently simple that the two definitions of encoding and decoding behaviour are encapsulated within the encoding method. For example static encoding implicitly checks whether the field value in the uncompressed packet is known, if so, it doesn't need to do anything (since static encoding takes up zero bits in the compressed packet). If it doesn't know the uncompressed value of the field, then it is extracted from the context. The two behaviours are still there, they're just hidden to keep the notation simple.

I hope this answers your question.

Regards

Robert Finking

-----Original Message-----
From: Haipeng Jin [mailto:[email-masked]] 
Sent: Wednesday, November 05, 2003 4:35 PM
To: Rohc (E-mail)
Subject: [rohc] Question about ROHC FN

Hi,

Thank you very much.
Haipeng

---

From: Haipeng Jin <[email-masked]>
Date: Fri, 07 Nov 2003 10:25:58 -0800

Robert,

Thank you for your explanation, that is very clear.

I have another question about the encoding method "uncompressible".

In ROHC FN 5.5.1, the example shows

      test_uncompressible ::= single_packet_format,
      {
        uncompressed_data ::=   length,
                                data,

        compressed_data   ::=   data,

        length            ::=   value(4, 1),

        data              ::=   uncompressible
                                  (test_uncompressible.length, 2, 2, 4)
      }

I am wondering whether it actually should be

         data ::= uncompressible (test_uncompressible.length, 2, 2, -4).

The uncompressible size of data should be 
(uncomp(test_uncompressible.length)/2)*2 - 4 instead 
of  (uncomp(test_uncompressible.length)/2)*2 + 4, right?

Also since you are mentioning ROHC-TCP, there seems  to be an inconsistent 
in using "uncompressible" in the ROHC FN draft and ROHC TCP draft. Again, 
ROHC FN 5.5.1 says

    The encoding method takes four parameters. The first parameter gives
    the base value for calculating the length of the data, whilst the
    next three parameters specify a divisor, multiplier and offset which
    scale the variable so that it specifies the size of the
    uncompressible field in bits.

So the uncompressible method is defined as uncompressible (base, divisor, 
multiplier, offset). While in ROHC-TCP 6.5.3, the generic format for 
compressing TCP option is given as:

        generic                   ::=   single_packet_format,

        { uncompressed_data       ::=   kind,                   %  8 bits
                                        length,                 %  8 bits
                                        data_item,     %  data_size bits

          compressed_data         ::=   data_item,

          kind                    ::=   static,
          length                  ::=   static,
          data_item               ::=
             uncompressible(tcp_ip.tcp_options.generic.length, 8, 1, -16)
        }
      }
    }
    }.

If we use the definition for uncompressible in ROHC-FN, the data_item size 
will be (tcp_ip.tcp_options.generic.length)/8 - 16, but the actual size in 
bits should be (tcp_ip. ... .length)*8 - 16. Right?

Thanks,

Haipeng

At 01:42 PM 11/7/2003 +0000, Finking, Robert wrote:
>Jin,
>
>Thanks for your question about "from_list" encoding. The whole of list 
>encoding is certainly the most complicated aspect of the ROHC-FN proposal 
>- thank you for taking the time to absorb it.
>
>The answer is fairly straightforward; the notation covers both the 
>information needed for encoding and that needed for decoding. The 
>"from_list" encoding method looks at both the compressed and uncompressed 
>packet to see which it knows. If  the uncompressed packet value (i.e. at 
>the compressor), then the value is calculated from the uncompressed packet 
>and associated context, as described in the FN draft. If the compressed 
>packet value is known then the value is extracted directly from the 
>compressed packet. This was not made explicit in the draft, thanks for 
>highlighting the need for clarification on this point.
>
>As an aside, this technique is also used elsewhere. If you look at the 
>contemporary TCP profile 
>(http://www.ietf.org/internet-drafts/draft-ietf-rohc-tcp-05.txt), in 
>section 6.5.2. Default encoding methods, you will see that the notation 
>for encoding a sequence number uses a similar technique. The definition 
>appears to be circular:
>
>Here we have sequence number defined in terms of scaled value and residue. 
>We also have scaled value and residue defined in terms of sequence number. 
>This looks circular, however one is use for compression and the other for 
>decompression. If the value of a field is known a priori, then there is no 
>need to calculate it.
>
>The obvious question is why this doesn't happen with all encoding 
>techniques. The fact is that most of them are sufficiently simple that the 
>two definitions of encoding and decoding behaviour are encapsulated within 
>the encoding method. For example static encoding implicitly checks whether 
>the field value in the uncompressed packet is known, if so, it doesn't 
>need to do anything (since static encoding takes up zero bits in the 
>compressed packet). If it doesn't know the uncompressed value of the 
>field, then it is extracted from the context. The two behaviours are still 
>there, they're just hidden to keep the notation simple.
>

---

From: "Richard Price" <[email-masked]>
Date: Tue, 11 Nov 2003 14:39:40 +0000

Haipeng,

The "uncompressible" encoding method is something of an
anachronism. We included it as a quick hack for handling
variable-length uncompressible fields, way back in the very
first version of the formal notation, and it has somehow
managed to survive unchanged ever since.

As your email makes clear, trying to use the "uncompressible"
encoding method can result in a serious headache. The
source of the confusion is the large selection of mysterious
parameters that follow the encoding method - it's difficult
to remember what the parameters are for, and the order
in which they're supposed to occur.

In more recent versions of the formal notation, we've tried
to reduce the reliance on magic numbers by converting the
potentially confusing parameters into proper, named fields
in their own right. We could easily do this for the
uncompressible encoding method as well, e.g:

foo ::= uncompressible
{
   base_length ::= same_as(some_other_field)
   multiplier ::= 8
   divisor ::= 1
   offset ::= 16
}

Even better, why not put the expression for deriving the
length of the uncompressible field straight into the formal
notation? This would look something like:

foo ::= uncompressible
{
   field_length ::= expression(uncomp(some_other_field) * 8 + 16)
}

Either of the above would help to avoid confusion about
what the parameters following the "uncompressible"
encoding method are actually for.

Regards,

Richard Price

P.S. Regarding the specific points raised below, I think that
the example in the ROHC-FN draft is correct - the length of
the uncompressible data is intended to be:

(uncomp(test_uncompressible.length)/2)*2 + 4

However, the use of "uncompressible" encoding in the
TCP profile is wrong - the parameters for the multiplier
and the divisor are the wrong way round. Giving each
parameter an explicit name would help to avoid this ;-)

>>----------
>>From: 	Haipeng Jin[SMTP:[email-masked]]
>>Sent: 	Friday, November 07, 2003 6:25:58 PM
>>To: 	Finking, Robert; [email-masked]'
>>Subject: 	Re: [rohc] RE: Question about ROHC FN
>>Auto forwarded by a Rule
>>
>Robert,
>
>(uncomp(test_uncompressible.length)/2)*2 - 4 instead of  
>(uncomp(test_uncompressible.length)/2)*2 + 4, right?
>

_________________________________________________________________
Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile