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

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Fri, 4 Mar 2005 07:51:03 +0100

After having spent a couple of hours trying to understand and 
convince myself that what is in the wraparound text of 4.5.3 
really works, can be made interoperable, and robust, I must say
that I fully agree with you. What could had been solved with a
clear a simple principle that would without doubt had solved
the problem, has instead been addressed with a complex and
unclear logic that not even those who have been living with
3095 for years can fully understand, make work, and trust. And
the reason for having this complexity is to optimize
compression for a few packets every 100 hours or so, that is
indeed insane when you look at it with fresh eyes.
 
So, the solution to outline in the implementer's guide would
be to say that the compressor must send unscaled TS at TS
wraparound, as in point 1 of 4.5.3, to reinitialize TS_OFFSET.
This principle would replace 4-5 of 4.5.3. 

Doing so is in my mind completely ok, as:
* Introducing that compressor principle does not make such
  a compressor incompatible with a decompressor trying to
  detect and cope with wraparound.
* It is clear from the mails on this subject that what is in
  point 5 of 4.5.3 is not unambiguously written, neither is
  it clear whether the logic can ever be made work. We would
  thus have to fix it anyway, but we have not seen a clear
  and simple solution that would work.
* Due to the extremely low probability of this to happen, I
  do not think it is a catastrophe if decompression fails
  and calls for a resynchronization, which is what could happen
  if a decompressor ignoring the "detect and cope with wraparound"
  principle would communicate with a compressor not implemented 
  according to what we outline in the implementer's guide.

Cheers,
/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Haipeng Jin
> Sent: den 3 mars 2005 17:56
> To: [email-masked]
> Subject: Re: [rohc] RFC3095 TS wraparound issues not really resolved
> 
> 
> 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
> 
> >BR,
> >         Kristofer Sandlund, Effnet AB
> >
> >Haipeng Jin wrote:
> >>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/msg02
> 230.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
> >>At 08:13 AM 3/2/2005, Haipeng Jin wrote:
> >>
> >>>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
> >>>
> >>>At 06:16 AM 3/2/2005, Lars-Erik Jonsson \(LU/EAB\) wrote:
> >>>
> >>>>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/msg
02230.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

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

---

From: "West, Mark" <[email-masked]>
Date: Sat, 5 Mar 2005 00:56:48 +0000 (GMT)

Hi all,

I too think that this is a pragmatic solution (to a problem that I'd
completely forgotten about, until seeing Lars-Erik's mail!)  So it also
avoids me having to try and struggle through the details of understanding
what was previously written on this subject...

The only thing that I'd like to be happy that we've got nice and
unambiguous is what we mean by "at wraparound", for the compressor.  Given
Haipeng's concerns about the interpretation interval and the desire to
support re-ordering, are we happy that we've defined *when* the compressor
must send unscaled TS bits?  (The answer may well be 'yes', but I'd just
like to check...)

Cheers,

Mark.

--
Mark A. West, Senior Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

On Fri, 4 Mar 2005, Lars-Erik Jonsson (LU/EAB) wrote:

> Date: Fri, 4 Mar 2005 07:51:03 +0100
> From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
> To: [email-masked]
> Subject: RE: [rohc] RFC3095 TS wraparound issues not really resolved
>