Subject: [rohc] RFC3095 TS wraparound issues not really resolved

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 2 Mar 2005 15:16:02 +0100

ROHCers,

I've found three old ROHC list threads, all related to TS wraparound,
which have not been fully resolved with clarifications for the ROHC
implementer's guide. The first one ended with a technical agreement
between Mark and Zhigang, but no clarifying text was generated, while
the second and third threads were left unresolved. I would appreciate
help with resolving these, including generating clear but concise text
for the implementer's guide. 

Wraparound detection thread:
http://www1.ietf.org/mail-archive/web/rohc/old-archive/msg02230.html

TS encoding at wraparound thread:
http://www1.ietf.org/mail-archive/web/rohc/current/msg01059.html

Interpretation interval at wraparound (including negative wrap):
http://www1.ietf.org/mail-archive/web/rohc/current/msg01571.html

Rgds,
/L-E

-----------------------------------
Lars-Erik Jonsson, M.Sc.
Senior Research Engineer
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit
Ericsson AB
Box 920, S-971 28 Luleå, Sweden
E-mail: [email-masked]                      /"\
Phone: +46 8 404 29 61                                      \ /
Fax: +46 920 996 21               ASCII Ribbon Campaign      X
Home: +46 920 999 57           against HTML email & vCards  / \

My opinions are my personal opinions and should not be considered
as the opinions of my employer, if not explicitly stated.

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

---

From: Haipeng Jin <[email-masked]>
Date: Wed, 02 Mar 2005 08:13:18 -0800

Here is another old post on the same topic, describing potential problems 
using an example:
http://www1.ietf.org/mail-archive/web/rohc/current/msg01840.html

Thanks,
Haipeng

---

From: Haipeng Jin <[email-masked]>
Date: Wed, 02 Mar 2005 13:17:37 -0800

Hi, All,

Here are some thoughts on this wraparound issue:

 From the old threads, there seems to be two problems to address. Suppose 
T1, T2 are unscaled values, and t1, t2 are the corresponding scaled values.

Problem 1. t2 is sent using WLSB and scaled interpretation interval. First, 
we need to make sure that t2 can be decompressed correctly using the number 
of bits sent. The examples given in 
http://www1.ietf.org/mail-archive/web/rohc/current/msg01840.html and 
http://www1.ietf.org/mail-archive/web/rohc/current/msg01067.html show that 
the scaled interpretation interval rule needs to be clarified/modified to 
ensure this. The root of the problem is that even though after scaling the 
number of bits needed is X bits, Y > X bits  may still be sent due to the 
packet format limitation. The interpretation interval corresponding to Y 
bits may actually give erroneous WLSB decoding.
Correct scaling of the interpretation interval also solves the problem 
mentioned in http://www1.ietf.org/mail-archive/web/rohc/current/msg01571.html.

Since the TS wraparound happens so infrequent (~150hr for 8khz audio and 
~13hr for 90khz video; on average, 75hr and 6.5hr, respectively, supposing 
TS starts with random value). Maybe the simplest solution is just to send 
the full scaled value on wraparound.

Problem 2. Even when we have the correct scaled value t2, there may still 
be ambiguity getting the correct value for T2 as pointed out in thread 
http://www1.ietf.org/mail-archive/web/rohc/old-archive/msg02230.html. The 
solution proposed by Mark and Zhigang works fine for positive wraparound. 
We just need to add the following formula for negative wraparound case:
         T2 = T1 + 2^n -  (local_tss_max -t2 + t1 +1) * TS_STRIDE, where n 
is the number of bits for an unscaled TS, for RTP it is 32.
         local_tss_max = TSS_MAX - 1, when r < (TS_STRIDE -1 - R)
         local_tss_max = TSS_MAX, otherwise

For example, borrowing Mark's example setup (TS_STRIDE = 6, TSS_MAX :

T1    248   249   250   251   252   253   254   255 0 1 2
t1     41    41    41    41    42    42    42    42 0 0 0
rem     2    3      4     5     0    1      2     3 0 1 2

Suppose T1 = 0 and T2 = 250 (TS_STRIDE = 6), then t2 = 41, at decompressor, 
r = 0 < (6 - 1 - 3), local_tss_max = 41, T2 = 0 + 256 - (41 -41 + 0 + 1)*6 
= 250.
Suppose T1 = 2 and T2 = 252, then t2 = 42 and at the decompressor, r = 2 = 
(6 - 1 -3) => local_tss_max = 42, T2 = 2 + 256 - (42 - 42 + 0 + 1)*6 = 252.

Thanks,
Haipeng

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 03 Mar 2005 16:57:45 +0100

Hi all,

after reading through the mail threads cited below and refreshing my memory on 
section 4.5.3 in 3095, I'm starting to wonder if this really makes sense. Is 
this really robust? Does this interoperate fully under losses or pre-link 
reordering? And how many "small patches" do we need to the algorithm before we 
know we've covered all possible cases?

This is an optimization for the case of TS-wraparound, and with a TS_STRIDE of 
160 like most voice codecs, wrap will happen every 25.843.546 (i.e. 25 million) 
packets. This seems like something that optimizes a few bytes in an extremely 
rare case at the cost of an algorithm that practically no one understands (refer 
to all the cited mail threads).

I think the spec should have been a lot better off saying "at wraparound of the 
TS, the compressor MUST send unscaled timestamps until it is confident that the 
decompressor has received the new TS_OFFSET". That would cost a few bytes on 
2-10 packets (depending on robustness configuration) every 25M packets. To me, 
this seems like a negligible loss of efficiency for assuring interoperability. 
Since it is an issue that has yet to be fully clarified, it would be nice if we 
could have the implementer's guide override bullets 4-5 in 4.5.3, otherwise I 
think we should at least make this change for 3095-bis.

BR,
	Kristofer Sandlund, Effnet AB

Haipeng Jin wrote:
>  From the old threads, there seems to be two problems to address. 
> Suppose T1, T2 are unscaled values, and t1, t2 are the corresponding 
> scaled values.
> 
> Problem 1. t2 is sent using WLSB and scaled interpretation interval. 
> First, we need to make sure that t2 can be decompressed correctly using 
> the number of bits sent. The examples given in 
> http://www1.ietf.org/mail-archive/web/rohc/current/msg01067.html show 
> that the scaled interpretation interval rule needs to be 
> clarified/modified to ensure this. The root of the problem is that even 
> though after scaling the number of bits needed is X bits, Y > X bits  
> may still be sent due to the packet format limitation. The 
> interpretation interval corresponding to Y bits may actually give 
> erroneous WLSB decoding.
> mentioned in 
> http://www1.ietf.org/mail-archive/web/rohc/current/msg01571.html.
> 
> ~13hr for 90khz video; on average, 75hr and 6.5hr, respectively, 
> supposing TS starts with random value). Maybe the simplest solution is 
> just to send the full scaled value on wraparound.
> 
> Problem 2. Even when we have the correct scaled value t2, there may 
> still be ambiguity getting the correct value for T2 as pointed out in 
> thread 
> http://www1.ietf.org/mail-archive/web/rohc/old-archive/msg02230.html. 
> The solution proposed by Mark and Zhigang works fine for positive 
> wraparound. We just need to add the following formula for negative 
> wraparound case:
>         T2 = T1 + 2^n -  (local_tss_max -t2 + t1 +1) * TS_STRIDE, where 
> n is the number of bits for an unscaled TS, for RTP it is 32.
> Suppose T1 = 0 and T2 = 250 (TS_STRIDE = 6), then t2 = 41, at 
> decompressor, r = 0 < (6 - 1 - 3), local_tss_max = 41, T2 = 0 + 256 - 
> (41 -41 + 0 + 1)*6 = 250.
> Suppose T1 = 2 and T2 = 252, then t2 = 42 and at the decompressor, r = 2 
> = (6 - 1 -3) => local_tss_max = 42, T2 = 2 + 256 - (42 - 42 + 0 + 1)*6 = 
> 252.
> 
> 
> Thanks,
> Haipeng
> 
>> Here is another old post on the same topic, describing potential 
>> problems using an example:
> ------------------------------------------------------------------------
>

---

From: Haipeng Jin <[email-masked]>
Date: Thu, 03 Mar 2005 08:56:29 -0800

Please see comments inline.

At 07:57 AM 3/3/2005, Kristofer Sandlund wrote:
>Hi all,
>
>after reading through the mail threads cited below and refreshing my 
>memory on section 4.5.3 in 3095, I'm starting to wonder if this really 
>makes sense. Is this really robust? Does this interoperate fully under 
>losses or pre-link reordering? And how many "small patches" do we need to 
>the algorithm before we know we've covered all possible cases?
>
>This is an optimization for the case of TS-wraparound, and with a 
>TS_STRIDE of 160 like most voice codecs, wrap will happen every 25.843.546 
>(i.e. 25 million) packets. This seems like something that optimizes a few 
>bytes in an extremely rare case at the cost of an algorithm that 
>practically no one understands (refer to all the cited mail threads).

Definitely agree with your points here.

>I think the spec should have been a lot better off saying "at wraparound 
>of the TS, the compressor MUST send unscaled timestamps until it is 
>confident that the decompressor has received the new TS_OFFSET". That 
>would cost a few bytes on 2-10 packets (depending on robustness 
>configuration) every 25M packets. To me, this seems like a negligible loss 
>of efficiency for assuring interoperability. Since it is an issue that has 
>yet to be fully clarified, it would be nice if we could have the 
>implementer's guide override bullets 4-5 in 4.5.3, otherwise I think we 
>should at least make this change for 3095-bis.

It would be the best if we can do this.

Regards,
Haipeng

>>may still be sent due to the packet format limitation. The interpretation 
>>interval corresponding to Y bits may actually give erroneous WLSB decoding.
>>decompressor, r = 0 < (6 - 1 - 3), local_tss_max = 41, T2 = 0 + 256 - (41 
>>-41 + 0 + 1)*6 = 250.
>>= (6 - 1 -3) => local_tss_max = 42, T2 = 2 + 256 - (42 - 42 + 0 + 1)*6 = 252.
>>
>>Thanks,
>>Haipeng