Subject: [rohc] ROHCv2: co_repair revisited

From: "Kristofer Sandlund" <[email-masked]>
Date: Wed, 26 Sep 2007 09:24:42 +0200

Hi all,

we're finishing up the next revision of ROHCv2, and I
want it to contain a quite large change to how the co_repair 
format looks. The more I've worked on the draft, the closer this
format has become to contining a dynamic chain, so I have decided
to change this packet format to be
  <discriminator, CRC-7, CRC-3-control and a dynamic chain>
instead of its current co_common look-alike format.

This should simplify implementation of these profiles while not
really changing the protocol very much (also, co_common becomes
a bit simpler since we can get rid of the repair_flag from it).

If you wish to object, let me know ASAP before we submit the new
revision (of course, it can be reverted for a later rev. of the
draft if the WG objects, but it would be easier to do so now if
someone has reasons to object).

/Kristofer

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

---

From: Carl Knutsson <[email-masked]>
Date: Wed, 26 Sep 2007 10:34:47 +0200

Hi Kristofer,

I just want to point out that all not all control fields in dynamic
chain are covered by a crc for this packet. It differs from how these
fields are handled in co_common and IR.

- In co_common, they are protected by the crc verification because
depending fields are covered by the crc.
- In IR the control fields itself is covered by crc-8.

In this case since there are no crc8 over the field itself and depending
fields are sent irregular(uncompressed). So decompression may be
successful even with a broken decompressor context. The fields
'checksum_coverage' and 'ip_id_behavior' in outer header comes to mind.
I am not sure this will be a problem, in this case the next packet will
fail. Just keep it in mind, so that we don't make the same misstakes as
with the IR-DYN in rfc3095.

/Carl Knutsson

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Wed, 26 Sep 2007 10:39:48 +0200

Hi,

although not stated in my mail, we have revised the coverage of
the control_crc3 encoding. The text below is in the draft
right now, so I think we have already adressed your issue.

Let me know if you disagree.

/Kristofer

******************

6.6.11.  control_crc3_encoding

   The "control_crc3_encoding" method provides a CRC calculated over a
   number of control fields.  The definition of this encoding method is
   the same as for the "crc" encoding method specified in section 4.11.6
   of [RFC4997], with the difference that the data that is covered by
   the CRC is given by a concatenated list of control fields.

   In other words, the definition of the control_crc3_encoding method is
   equivalent to the following definition:

     control_crc_encoding(data_value, data_length)
     {
       UNCOMPRESSED {
       }

       COMPRESSED {
         control_crc3 =:=
           crc(3, 0x06, 0x07, ctrl_data_value, ctrl_data_length) [ 3 ];
       }
     }

   where the parameter "ctrl_data_value" binds to the concatenated
   values of the following control fields, in the order listed below:

   o  reorder_ratio, 2 bits padded by 6 MSB of zeroes
   o  ts_stride, 32 bits (applicable only for profiles 0x0101 and
      0x0107)
   o  time_stride, 32 bits (applicable only for profiles 0x0101 and
      0x0107)
   o  msn, 16 bits (not applicable for profiles 0x0101 and 0x0107, since
      the RTP Sequence Number is already verified as part of the
      uncompressed header)
   o  coverage_behavior, 2 bits padded by 6 MSB of zeroes, applicable
      only to profiles 0x0107 and 0x0108
   o  ip_id_behavior, one octet for each IP header in the compressible
      header chain starting from the outermost header.  Each octet
      consists of 2 bits padded by 6 MSBs of zeroes

   The "ctrl_data_length" binds to the sum of the length of the control
   field(s) that are applicable.

   A 3-bit CRC is used to validate the control fields that are updated
   by the co_common and co_repair packet types; it cannot verify the
   outcome of a decompression attempt.  The definition of this CRC comes
   from the fact that the decompression of a header that carries and
   updates control fields does not necessarily make use of these control
   fields, and the update to the control fields is thus not protected by
   the CRC-7 validation.

   For example, without a verification of the updates to the control
   fields, there would be a possibility that a decompression attempt
   succeeds for a co_common or for a co_repair packet for which the
   decompressor would send a positive feedback, even in the case where
   one of the control fields had been corrupted on the link between the
   compression endpoints. 

*********************

> -----Original Message-----
> From: Carl Knutsson [mailto:[email-masked]] 
> Sent: den 26 september 2007 10:35
> To: Kristofer Sandlund
> Cc: rohc
> Subject: Re: [rohc] ROHCv2: co_repair revisited & coverage
> 
> Hi Kristofer,
>