Subject: RE: [rohc] Question about ROHC TS encoding at wrap around

From: Anton Mårtensson (EAB)<[email-masked]>
Date: Wed, 20 Nov 2002 11:29:42 +0100

Hi Rajib,
That is true that values from 1010 to 1111 in the interpretation interval will not be used (if you are using the same 
number of bits during the interval as before, 4 bits). That is why we have the wrap-around rule in
Section 4.5.3, point 5. If we want to keep the robustness during the wrap-around we need to send more
bits when TSS_MAX is in the interpretation interval. So how many bits do I need (please see the rule in point 5)?
a = 4
TSS_MAX LSBs = 10011001
Point 5 says that a (a=4) LSBs of TSS_MAX should be set to zero = 10010000
If you compare this value with 0 (00000000) you will get that you need to send
at least 5 bits during the wrap (since the 5th bit (from right) is the first bit set to 1.
 
Another example:
Assume that you are using 5 bits instead of 4 before the wrap (a=5). I this case we need to set 
the 5 LSBs of TSS_MAX to zero (10000000). If we compare it to 00000000 we get 
that we need to use 8 bits (the 8th bit from the right differs) during the wrap to keep the same robustness.
 
I hope this helped!
 - Anton

 -----Original Message-----
From: Sarkar, Rajib [mailto:[email-masked]]
Sent: den 19 november 2002 22:25
To: [email-masked]'
Subject: [rohc] Question about ROHC TS encoding at wrap around

Hi,

    I have a question about ROHC scaled TS encoding at wrap around (basically section 4.5.3, point 5)

    Lets say for scaled TS 26843545 I send last 4 bits (k=4) to the decompressor 1001. Also assume that TS_STRIDE=160. The next scaled TS is 2. Now do I need to do anything special or if still my k=4, I just send 0010? In that case values from 1010 to 1111 are still in interpretation interval, but never used.

Thanks

Rajib

---

From: Stefan Hendrata <[email-masked]>
Date: Thu, 21 Nov 2002 13:40:45 +0100

HI Anton, Hi Rajib ! 

Coincidentally, I'm also looking into our TS wraparound stuff for correctness 
and possible optimization and would like to share some of my results and 
problems.

From the RFC, I also understand the scheme of calculating the additional bits 
needed for the scaled TS in case of a wraparound in the same way as you 
described. But somehow, this doesn't work every time.

Let's take the following example (from one of our test cases):

Let TS_STRIDE be 0x64 and the last unscaled TS value before wraparound 

	T1 = 0xFFFFFFD7.

The scaled TS value before wraparound is thus

	t1 = 0xFFFFFFD7 / 0x64 = 0x28F5C28

which is equal to TSS_MAX = 0xFFFFFFFF / 0x64.

Now we have a wraparound with the new unscaled TS of

	T2 = 0x3B

which means an increase of one time TS_STRIDE. The new scaled TS is thus

	t2 = 0x00.

So we calculate the additional bits needed for coding of the scaled TS after 
wraparound: The number of LSBs needed if there was no wraparound is a=4 
(using our width of the sliding window for reference values). TSS_MAX with 
the last 4 LSBs set to zero is thus 0x28F5C20 and the number of bits to 
disambiguate it from zero is finally b=6.

Now, in the current context, there is no packet type with 6 TS bits available 
but one with 8 TS bits (UOR-2-TS with extension 0). So we are sending 8 TS 
bits of the new scaled TS value 0x00.

At the decompressor, the reference value for decompression of the TS bits is 
0x28F5C28 (scaled TS value before wraparound) and since we received 8 TS 
bits, the interpretation interval (with p = 2^(8-2)-1 = 63 = 0x3F) ranges from

	i_min = 0x28F5BE9	to
	i_max = 0x28F5CE8

and the decompressed scaled TS value becomes 0x28F5C00 which is within the 
interpretation interval and smaller than TSS_MAX but not equal to the 
original scaled TS value t2 = 0x00. Thus, the decompressed unscaled TS is 
wrong at the end.

The problem seems to be that there are still cases where the decompressor 
cannot distinguish between TSS_MAX with the k LSBs set to zero and zero in 
the interpretation interval upon reception of k zero TS bits.

Is there a flaw in the application of the wraparound scheme described above?

Best regards,
Stefan Hendrata
- acticom GmbH -

On Wednesday 20 November 2002 11:29, Anton Mårtensson (EAB) wrote:
> Hi Rajib,
> That is true that values from 1010 to 1111 in the interpretation interval
> will not be used (if you are using the same number of bits during the
> interval as before, 4 bits). That is why we have the wrap-around rule in
> Section 4.5.3, point 5. If we want to keep the robustness during the
> wrap-around we need to send more bits when TSS_MAX is in the interpretation
> interval. So how many bits do I need (please see the rule in point 5)? a =
> 4
> TSS_MAX LSBs = 10011001
> If you compare this value with 0 (00000000) you will get that you need to
> send at least 5 bits during the wrap (since the 5th bit (from right) is the
> first bit set to 1.
>
> Another example:
> Assume that you are using 5 bits instead of 4 before the wrap (a=5). I this
> case we need to set the 5 LSBs of TSS_MAX to zero (10000000). If we compare
> it to 00000000 we get that we need to use 8 bits (the 8th bit from the
> right differs) during the wrap to keep the same robustness.
>
> I hope this helped!
>  - Anton
>
>     Lets say for scaled TS 26843545 I send last 4 bits (k=4) to the
> decompressor 1001. Also assume that TS_STRIDE=160. The next scaled TS is 2.
> Now do I need to do anything special or if still my k=4, I just send 0010?
> In that case values from 1010 to 1111 are still in interpretation interval,
> but never used.
>
> Thanks
>
> Rajib
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Stefan Hendrata <[email-masked]>
Date: Thu, 21 Nov 2002 16:28:04 +0100

Hi again,

after some deeper investigation of this stuff I found the "flaw" in my 
application of the TS wraparound scheme as described in my previous mail.

The problem is that "rounding up" to the next available number of TS bits in 
a packet format does not always work for the wraparound scheme described in 
the RFC.

To come straight to the point:

The two lower bytes of the unscaled TS value (equal to TSS_MAX) from my 
previous example before wraparound are

	0x5C28 = 0101110000101000

If there was no wraparound, I would need need a=4 TS bits to be sent but with 
wraparound there are b=6 TS bits needed.

And now comes the "flaw": Since there is no packet format available with 6 TS 
bits, I use 8 TS bits ASSUMING that more bits are redundant as in the TS 
compression scheme without wraparound.

The wraparound scheme works if 6 TS bits were actually transmitted BUT when 
using 8 TS bits, the decompressor cannot distinguish between TSS_MAX with the 
8 LSBs set to zero and zero. The next "valid" number of TS bits for a 
successful wraparound would be 11 because the first "1"  in the binary 
presentation of TSS_MAX with the 8 LSBs set to zero is at offset 11 (from the 
right).

So the "flaw" is that the assumption adopted in the RFC of always being able 
to send more scaled and compressed TS bits than the minimum number needed is 
violated for the wraparound scheme.

Am I wrong?

Best regards,
Stefan Hendrata
- acticom GmbH -

On Thursday 21 November 2002 13:40, Stefan Hendrata wrote:
> HI Anton, Hi Rajib !
>
> Coincidentally, I'm also looking into our TS wraparound stuff for
> correctness and possible optimization and would like to share some of my
> results and problems.
>
> From the RFC, I also understand the scheme of calculating the additional
> bits needed for the scaled TS in case of a wraparound in the same way as
> you described. But somehow, this doesn't work every time.
>
> So we calculate the additional bits needed for coding of the scaled TS
> after wraparound: The number of LSBs needed if there was no wraparound is
> a=4 (using our width of the sliding window for reference values). TSS_MAX
> with the last 4 LSBs set to zero is thus 0x28F5C20 and the number of bits
> to disambiguate it from zero is finally b=6.
>
> Now, in the current context, there is no packet type with 6 TS bits
> available but one with 8 TS bits (UOR-2-TS with extension 0). So we are
> sending 8 TS bits of the new scaled TS value 0x00.
>
> At the decompressor, the reference value for decompression of the TS bits
> is 0x28F5C28 (scaled TS value before wraparound) and since we received 8 TS
> > wrap-around we need to send more bits when TSS_MAX is in the
> > interpretation interval. So how many bits do I need (please see the rule
> > in point 5)? a = 4
> > TSS_MAX LSBs = 10011001
> > Point 5 says that a (a=4) LSBs of TSS_MAX should be set to zero =
> > 10010000 If you compare this value with 0 (00000000) you will get that
> > you need to send at least 5 bits during the wrap (since the 5th bit (from
> > right) is the first bit set to 1.
> >
> > Another example:
> > Assume that you are using 5 bits instead of 4 before the wrap (a=5). I
> > this case we need to set the 5 LSBs of TSS_MAX to zero (10000000). If we
> > compare it to 00000000 we get that we need to use 8 bits (the 8th bit
> > from the right differs) during the wrap to keep the same robustness.
> >
> > I hope this helped!
> >  - Anton
> >
> > decompressor 1001. Also assume that TS_STRIDE=160. The next scaled TS is
> > 2. Now do I need to do anything special or if still my k=4, I just send
> > 0010? In that case values from 1010 to 1111 are still in interpretation
> > interval, but never used.
> >
> > Thanks
> >
> > Rajib
>