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

From: Anton Mårtensson (EAB)<[email-masked]>
Date: Fri, 22 Nov 2002 10:06:48 +0100

Hi,
A question?
When the scaled TS is equal to TSS_MAX, what are you sending
to the decompressor? 
I got the impression that you are sending 0x00 instead of 0x28 (using 8 bits).
You should send the b LSBs of the actual scaled TSS_MAX and not with the 
a LSBs set to zero? Got it?

The reason to this is that each bitpattern of the 8 LSBs of the interpretation 
interval only are allowed to occur once, i.e. all patterns from 00000000 to
11111111 should be in the interval.

I hope this solves your problem!

 - Anton

> -----Original Message-----
> From: Stefan Hendrata [mailto:[email-masked]]
> Sent: den 21 november 2002 16:28
> To: Anton Mårtensson; 'Sarkar, Rajib'
> Cc: [email-masked]'
> Subject: Re: [rohc] Question about ROHC TS encoding at wrap around
> 
> 
> 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.
> >
> > 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
> > > 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
> >
> > _______________________________________________
> > Rohc mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Stefan Hendrata <[email-masked]>
Date: Fri, 22 Nov 2002 11:17:04 +0100

Hi Anton,

No, of course when the scaled TS value is equal to TSS_MAX I'm sending the 
LSBs of TSS_MAX which are (in general) not zeros. The problem occurs at the 
subsequent scaled TS value which is zero and compressed using the wraparound 
scheme.

Maybe you could try to go through the example I have given with your 
implementation of the TS wraparound scheme using rnd=0 in the context and 
thus sending 8 TS bits at wraparound (UOR-2-TS with extension 0).

Thanks and best regards,
Stefan Hendrata
- acticom GmbH -

On Friday 22 November 2002 10:06, Anton Mårtensson (EAB) wrote:
> I got the impression that you are sending 0x00 instead of 0x28 (using 8
> bits). You should send the b LSBs of the actual scaled TSS_MAX and not with
> the a LSBs set to zero? Got it?
>
> The reason to this is that each bitpattern of the 8 LSBs of the
> interpretation interval only are allowed to occur once, i.e. all patterns
> from 00000000 to 11111111 should be in the interval.
>