Subject: [rohc] RE: sdvl() in *-rohcv2-profiles-00.txt

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Mon, 18 Dec 2006 16:38:34 +0100

Hi Calle,

you're right that there are bugs in the SDVL-related code in the draft,
and you pointed out _some_ of them, but we're still at -00 of the draft,
so that is to be expected :)

- I agree that "stride" should not use LSB-encoding, it should use "pure
LSB",
i.e. only compress away leading zeros. Therefore, I have made a new
encoding
method for optional_stride (see below).
- Regarding other SDVL-encoded values (SN, scaled TS, unscaled TS),
these are
used in co_common. And since we no longer have an IR-DYN packet in these
profiles, the co_common needs to be able to send the full 32-bit values
of
the TS when used for repair. Therefore, the SDVL in v2 is no longer the
exact same one as in the framework draft (and rfc3095), instead the 4th
format
is 28 bits long, and there is a 32-bit irregular coded format that has
an
8-bit discriminator (so I change the name to sdvl_lsb). This applies to
both
forms of SDVL. I guess it could be possible to add extra discriminators
at
the top level to avoid having an 8-bit discriminator here, so I'll but
that
on my TODO-list and maybe I'll get back to it in the future.
- The LSB offset (the so-called p-value) for SDVL is changed to be 50%
of the
interval.

New suggested FN code for the draft (replacement for sdvl and
optional_stride):

sdvl_lsb(field_width)
{
  UNCOMPRESSED {
    field [ field_width ];
  }

  COMPRESSED lsb7 {
    discriminator =:= '0'      [ 1 ];
    field =:= lsb(7, 2^6 - 1)  [ 7 ];
  }

  COMPRESSED lsb14 {
    discriminator =:= '10'      [  2 ];
    field =:= lsb(14, 2^13 - 1) [ 14 ];
  }

  COMPRESSED lsb21 {
    discriminator =:= '110'     [  3 ];
    field =:= lsb(21, 2^20 - 1) [ 21 ];
  }

  COMPRESSED lsb28 {
    discriminator =:= '1110'    [  4 ];
    field =:= lsb(28, 2^27 - 1) [ 28 ];
  }

  COMPRESSED lsb32 {
    discriminator =:= '11111111' [  8 ];
    field =:= irregular(32)      [ 32 ];
  }
}

optional_stride(flag)
{
  UNCOMPRESSED {
    field [ 32 ];
  }

  COMPRESSED present_7bit {
    discriminator =:= '0' [ 1 ];
    ENFORCE(flag == 1);
    ENFORCE(field.UVALUE < 2^7);
    ENFORCE(field.CVALUE == field.UVALUE);
    field  [ 7 ];
  }

  COMPRESSED present_14bit {
    discriminator =:= '10'   [ 2 ];
    ENFORCE(flag == 1);
    ENFORCE(field.UVALUE < 2^14);
    ENFORCE(field.CVALUE == field.UVALUE);
    field  [ 14 ];
  }

  COMPRESSED present_21bit {
    discriminator =:= '110'  [ 3 ];
    ENFORCE(flag == 1);
    ENFORCE(field.UVALUE < 2^21);
    ENFORCE(field.CVALUE == field.UVALUE);
    field  [ 21 ];
  }

  COMPRESSED present_28bit {
    discriminator =:= '1110'  [ 4 ];
    ENFORCE(flag == 1);
    ENFORCE(field.UVALUE < 2^28);
    ENFORCE(field.CVALUE == field.UVALUE);
    field  [ 28 ];
  }

  COMPRESSED present_32bit {
    discriminator =:= '11111111'  [ 8 ];
    ENFORCE(flag == 1);
    ENFORCE(field.CVALUE == field.UVALUE);
    field  [ 32 ];
  }
  
  COMPRESSED not_present {
    field =:= static;
    ENFORCE(flag == 0);
  }
}

And the latter encoding method is called from optional_stride, while the
former one is called from optional_[un]scaled_timestamp and from where
the
sequence number is encoded in the co_common formats.

Does this seem like the correct fix for this?

/Kristofer

Carl Knutsson <mailto:[email-masked]> wrote on den 14 december 2006
13:20 :

> Kristofer, Ghyslain, rohcers,
> 
> The svdl encoding method uses reference based lsb encoding. Not all of
> the encoding methods that use sdvl encoding needs to be
> lsb-encoded using
> the context as a reference. For example optional_stride uses
> sdvl. This
> may be okey in compressed packets, but I don't like the idea
> to compress
> the ts_stride using the context ts_stride as reference when
> decompressing a dynamic chain.
> 
> 1. I suggest to always use zero as reference and a p-value of 0 for
> lsb-encoding the ts_stride. (the ts_stride is always positive?). I
> think we need to add a new encoding method for this.
> 
> 2. My second proposal is to remove the lsb-encoding from the sdvl
> encoding method or to have an argument for p value (none,
> quarter, half,
> three quarters). To enable fields to be sdvl-encoded with different p
> values. 
> 
> 3. The p-values needs to be changed in the sdvl-encoding
> method. At least
> the compressed format lsb7 (field =:= lsb(14, 16383)), since
> it can only
> encode the field to smaller values than the current
> reference. Compressed
> formats lsb21 and lsb29 use the same p-value. If my
> suggestion 2 is not
> accepted I propose a change use 2^k/-1 for all p-values.
> 
> field =:= lsb(7, 63)  [ 7 ];
> field =:= lsb(14, 8191) [ 14 ];
> field =:= lsb(21, 1048575) [ 21 ];
> field =:= lsb(29, 268435456) [ 29 ];
> 
> *-profiles-00.txt (old values):
> field =:= lsb(7, 63)  [ 7 ];
> field =:= lsb(14, 16383) [ 14 ];
> field =:= lsb(21, 65535) [ 21 ];
> field =:= lsb(29, 65535) [ 29 ];
> 
> rgds,
> /Carl Knutsson

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

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 19 Dec 2006 11:41:00 +0100

Hi Kristofer,

comments inline..

> so that is to be expected :)

Agreed.

> - I agree that "stride" should not use LSB-encoding, it should use "pure LSB",
> i.e. only compress away leading zeros. Therefore, I have made a new encoding
> these are used in co_common. And since we no longer have an IR-DYN packet in these
> profiles, the co_common needs to be able to send the full 32-bit values of
> exact same one as in the framework draft (and rfc3095), instead the 4th format
> an 8-bit discriminator (so I change the name to sdvl_lsb). This applies to
> both forms of SDVL. I guess it could be possible to add extra discriminators
> at the top level to avoid having an 8-bit discriminator here, so I'll but
> that on my TODO-list and maybe I'll get back to it in the future.

Agreed.

Since we don't have the IR-DYN packet any more, it is important to be able to TS in
full in co_common. It is also important to be able to send for IPv4 identification
and the sequence number in full too. Since the fields are sdvl encoded, I believe the
comment of the co_common packet format should be changed to reflect this for the
RTP-profiles.

  ip_id =:= optional_ip_id_lsb(ip_id_behavior.UVALUE,
                               ip_id_indicator.UVALUE)   [0, 8, 16, 24];
  sequence_number =:= sdvl_lsb(sequence_number.ULENGTH)  [8, 16, 24];

If the format fail when lsb is larger than the field? In that case maybe we should
change the last compressed format in sdvl_lsb:

From:
  COMPRESSED lsb32 {

To:
  COMPRESSED lsb32 {
    discriminator =:= '11111111'     [ 8 ];
    field =:= irregular(field_width) [ field_width ];
  }

> of the interval.

Agreed.

> former one is called from optional_[un]scaled_timestamp and from where the

Yes. (but maybe 28 bits is sufficient for the ts_stride).

/Calle

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Tue, 19 Dec 2006 11:52:18 +0100

Hi Calle,

some comments inline.

Carl Knutsson <mailto:[email-masked]> wrote on den 19 december
2006 11:41 :

<snip>

>                                ip_id_indicator.UVALUE)   [0, 8, 16,
>   24]; sequence_number =:= sdvl_lsb(sequence_number.ULENGTH)  [8, 16,
> 24]; 

I don't think the IP-ID is relevant here, it does not use SDVL, and
already provides an "Uncompressed format", but I agree on the SN, see
below.

>     field =:= irregular(field_width) [ field_width ];   }

ACK. I will fix this, I had forgotten that this was used for 16-bit
fields
as well.

<snip>

> Yes. (but maybe 28 bits is sufficient for the ts_stride).

Well, I'd guess that 14 or at most 21 should be enough in any realistic
case,
but I don't see an extra cost in having a 32-bit format to catch any
"stupid" case, since the implementation cost for that is minimal.

/Kristofer

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 21 Dec 2006 11:17:24 +0100

Hi Kristofer,

I agree on all changes...

Now we will be to send TS, TS_STRIDE and SN can be sent in full in co_common.

One question, can a 16-bit field be encoded with the formats lsb21 and lsb24 in
encoding method sdvl? Or will the two formats fail if the lsb is larger than
encoded field? What happens when a decompression results in larger number than can
be described in the original field? I couldn't find the answer in the definition
of lsb encoding method.

God Jul och Gott Nytt År,
/Calle

> Carl Knutsson <mailto:[email-masked]> wrote on den 19 december

My mistake...

> ACK. I will fix this, I had forgotten that this was used for 16-bit

Good!

> "stupid" case, since the implementation cost for that is minimal.
I agree, it is foolproof and the implementation cost is minimal.

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Thu, 21 Dec 2006 13:27:35 +0100

Carl Knutsson <mailto:[email-masked]> wrote on den 21 december
2006 11:17 :

> One question, can a 16-bit field be encoded with the formats lsb21
> and lsb24 in encoding method sdvl? Or will the two formats fail if
> the lsb is larger than encoded field? What happens when a
> decompression results in larger number than can be described in the
> original field? I couldn't find the 
> answer in the definition
> of lsb encoding method.
> 

Calle,
my view is that (as in 3095) it should be legal that "k" can be larger 
than the uncompressed field length, but not that the value in the
compressed
field can be larger than the highest possible uncompressed value. 

Or better said:
- CLENGTH > ULENGTH   => ok (as long as MSBs are zero-padding)
- CVALUE >= 2^ULENGTH => impossible at the compressor, discard at
decompressor

But, I agree that after reading the definition in the FN draft, I'm not
sure
how the first of these two conditions is to be interpreted.

Raffles and/or Ghyslain, do you know how to interpret this from the FN
spec? 
Should we add some clarification during AUTH-48 or is this covered by
the
current FN spec?

/Kristofer

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Dec 2006 14:36:18 +0100

> how the first of these two conditions is to be interpreted.

Well, that's a reason why the library encoding methods should be  
formally specified as far as possible.
Unfortunately, we don't have a way to talk about the context and the  
resulting interpretation intervals in FN: this is why static and lsb  
are not formally specified.

The text says that:
1  The parameter "num_lsbs_param" binds with the "CLENGTH" attribute,

2  The value of
    the "ULENGTH" can be derived from the information stored in the
    context.

3  the "UVALUE" attribute binds to the value within the interval whose
    least significant bits match the "CVALUE" attribute.

which to me seems consistent with your interpretation above, even if  
the term "least significant bits" is a bit confusing.
1 and 3 leave all the freedom that is needed.
Re 2: CVALUE and UVALUE have the interesting property that they bind  
to bit strings in a modulo/zero extending fashion [1].
So, during decompression, excess bits in the UVALUE will be discarded  
at the decompressor.
If there are excess leading zero bits in the field(s) that contribute  
to the CVALUE, this does not matter, as the FN is in terms of  
positive integers and not in terms of bit strings.
If they are non-zero, the CVALUE will be out of bounds and the match  
3 talks about won't happen (which I would read as "the format fails").

I'm not sure this will be the last observation about a boundary case  
in the FN.
Instead of tweaking the FN document until that no longer happens, I'd  
rather do what has been successfully done in ROHC before: keep  
running User Guide/Implementor Guide documents (as I-Ds first and as  
RFCs a couple of years later) that document the common view about the  
boundary cases.

Gruesse, Carsten

[1]
3.2.1, last para:
    The bit string is the
    binary representation of the value attribute of the field, modulo
    "2^length", where "length" is the length attribute of the field.
See also 4.4.2.
I'm not a big fan of this implicit conversion approach, see my review  
comments, but this is the way it is, and in this case it happens to  
help.