Subject: RE: Clarification on timer-based compression (was: Re: [rohc] New Draft for Support of Reordering and Constant IP-ID)

From: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Tue, 19 Apr 2005 15:02:08 +0200

Sounds good!

Thanks,
/L-E

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 19 april 2005 13:57
> To: Lars-Erik Jonsson (LU/EAB)
> Cc: Kapoor, Rohit; [email-masked]; [email-masked]
> Subject: Re: Clarification on timer-based compression (was: Re: [rohc]
> New Draft for Support of Reordering and Constant IP-ID)
> 
> 
> Hi L-E,
> 
> If we're going to provide clarifying text on this topic, I 
> think we should also 
> point out that the TIME_STRIDE cannot be set to a non-zero 
> value before the 
> clock resolution on the channel has been set by feedback. So, 
> maybe a change like:
> 
> OLD:
>  >    Whether to use timer-based compression or not is controlled by
>  >    the TIME_STRIDE control field, which can be set either by an IR,
>  >    an IR-DYN, or by a compressed packet with extension 3. Setting
>  >    TIME_STRIDE to a value > 0 enables timer-based compression.
> 
> NEW:
>       Whether to use timer-based compression or not is controlled by
>       the TIME_STRIDE and the decompressor's clock 
> resolution. A non-zero
>       TIME_STRIDE indicates timer-based compression is being used, but
>       setting TIME_STRIDE to a non-zero value can only be 
> done after the
>       decompressor has declared its clock resolution. The 
> clock resolution
>       is declared by sending a CLOCK feedback for any CID on 
> the channel.
>       After the resoution is known, the TIME_STRIDE can be set either
>       by an IR, an IR-DYN, or by a compressed packet with extension 3.
> 
> Or something along those lines, feel free to improve that, it 
> turned out to be 
> not-so-great text. But I think you know what I'm trying to say...
> 
> BR,
> 	Kristofer Sandlund, Effnet AB
> 
> Lars-Erik Jonsson (LU/EAB) wrote:
> > To follow up on this question, I suggest adding the 
> following section
> > to the implementer's guide:
> > 
> > 
> > 4.8. Using timer-based compression
> >    
> >    Timer-based compression of the RTP timestamp, as described in
> >    section 4.5.4, can be used to reduce the number of transmitted
> >    timestamp bits (bytes) needed when the timestamp can not be
> >    inferred from the SN. It should thus be noted that timer-based
> >    compression has no influence on decompression of packets where
> >    no timestamp bits are sent, in that case the timestamp is just
> >    linearly inferred from the SN (see section 4.2 of this document).
> > 
> >    Whether to use timer-based compression or not is controlled by
> >    the TIME_STRIDE control field, which can be set either by an IR,
> >    an IR-DYN, or by a compressed packet with extension 3. Setting
> >    TIME_STRIDE to a value > 0 enables timer-based compression.
> > 
> > 
> > Any comments on this?
> > 
> > /L-E
> > 
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>Lars-Erik Jonsson (LU/EAB)
> >>Sent: den 15 april 2005 09:03
> >>To: Kapoor, Rohit
> >>Cc: [email-masked]; [email-masked]
> >>Subject: RE: [rohc] New Draft for Support of Reordering and Constant
> >>IP-ID
> >>
> >>
> >>Rohit,
> >>
> >>I'll try to clarify, hopefully I have corrently understood 
> >>your question.
> >>
> >>First of all, timer-based compression has to be turned on by setting
> >>the TIME_STRIDE to a value > 0. So, if it is turned on, transmitted
> >>TS bits should always be interpreted as scaled TS bits, with the 
> >>assumption that the decompressor makes use of timer-based 
> estimation,
> >>i.e. the transmitted bits might not themselves be enough to 
> decompress
> >>the TS correctly (MSB requires a timer-based estimation).
> >>
> >>However, if NO BITS are transmitted, this means that TS do follow SN
> >>linearly as a function of TS_STRIDE, i.e.:
> >>   TS_SCALED(n) = TS_SCALED(n-1) + SN(n) - SN(n-1)
> >>
> >>Timer-based compression is used to be able to reduce the 
> >>number of extra
> >>bits (bytes) needed WHEN TS DOES NOT FOLLOW SN, i.e. 
> instead of having
> >>to send two or three extra bytes after a silence period, 
> one byte will
> >>be enough. When no TS bits are sent, timer-based compression has no
> >>impact on decompression.
> >>
> >>Did that answer the question? Interpretation two is thus correct!
> >>
> >>I guess it might make sense to write a few words about this in the
> >>implementer's guide, a new section 4.8 on timer-based compression?
> >>What do others think?
> >>
> >>BR
> >>/L-E
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Kapoor, Rohit [mailto:[email-masked]]
> >>>Sent: den 14 april 2005 21:26
> >>>To: Lars-Erik Jonsson (LU/EAB)
> >>>Cc: [email-masked]
> >>>Subject: RE: [rohc] New Draft for Support of Reordering 
> and Constant
> >>>IP-ID
> >>>
> >>>
> >>>Lars-Erik,
> >>>
> >>>Thanks.
> >>>
> >>>I also have a slight confusion in the interpretation of the 
> >>>RFC that you may be able to clarify. Assume that for some
> >>>time the compressor is using timer-based compression to
> >>>compress RTP timestamp and uses UO-1-TS packets. Now, if
> >>>the compressor decides to send a UO-0 packet, how does
> >>>the decompressor infer the RTP timestamp from this packet?
> >>>UO-0 could either mean that "jitter is 0" (since no
> >>>timestamp bits are present) or the decompressor could
> >>>infer timestamp from RTP SN. Which interpretation will
> >>>the decompressor follow? Or is sending a UO-0 packet not
> >>>"legal" when compressing TS using timer-based compression?
> >>>
> >>>The following paragraph in the RFC says something which seems 
> >>>to support the second interpretation.
> >>>
> >>>On page 58
> >>>   If RTP Timestamp and IP Identification fields are not 
> >>>   included in the received header, they are supposed to be
> >>>   calculated from the sequence number.  The IP Identifier
> >>>   usually increases by the same delta as the sequence number
> >>>   and the timestamp by the same delta times a fixed value. 
> >>>   See chapters 4.5.3 and 4.5.5 for details about how these
> >>>   fields are encoded in compressed headers.
> >>>
> >>>
> >>>Thanks,
> >>>Rohit
> >>
> >>_______________________________________________
> >>Rohc mailing list
> >>[email-masked]
> >>https://www1.ietf.org/mailman/listinfo/rohc
> >>
> > 
> > 
> > _______________________________________________
> > 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: "Lars-Erik Jonsson \(LU/EAB\)" <[email-masked]>
Date: Wed, 20 Apr 2005 09:21:50 +0200

Haipeng and Kristofer,

I believe Kristofer is correct in that the enabling of timer-based
compression as a two-step process involving initiatives from both
decompressor and compressor also serves the purpose of making timer-
based compression an optional mechanism. We have always considered
timer-based as an optional mechanism, requiring CLOCK-OPTION +
enabling from the compressor before it can be used. That was the
purpose when writing it and that is what has always been the
assumption, even if 3095 (as often) is not very clear on this. We
see this being reflected in the example implementation structure
described in 6.5.1, where clock resolution is initially set to 0.

To summarize, I believe the requirement to have received a CLOCK
feedback option before timer-based compression can be turned on,
is correct.

I made a minor re-write of the text, making it more compact. The
result became as follows:

----------------------------------------------------------------
4.8. Using timer-based compression
   
  Timer-based compression of the RTP timestamp, as described in section
  4.5.4, may be used to reduce the number of transmitted timestamp bits
  (bytes) needed when the timestamp can not be inferred from the SN. It
  should thus be noted that timer-based compression has no influence on
  decompression of packets where no timestamp bits are sent, in that
  case the timestamp is just linearly inferred from the SN (see section
  4.2 of this document).

  Whether to use timer-based compression or not is controlled by the
  TIME_STRIDE control field, which can be set either by an IR, an IR-
  DYN, or by a compressed packet with extension 3. The compressor turns
  on timer-based compression by setting TIME_STRIDE to a value > 0, but
  that can be done first after the decompressor has declared its clock
  resolution, which is done by sending a CLOCK feedback option for any
  CID on the channel. 
-----------------------------------------------------------------

Rgds,
/L-E

> Sent: den 20 april 2005 08:43
> To: Jin, Haipeng
> Cc: Lars-Erik Jonsson (LU/EAB); [email-masked]; [email-masked]
> Hi Haipeng,
> comments inline.
> Jin, Haipeng wrote:
> > Hi, Lars-Erik and Kristofer,
> > 
> > The proposed text does not allow setting TIME_STRIDE to 
> non-zero value
> > before receiving CLOCK feedback in the case where the compressor has
> > advanced knowledge of the decompressor's clock resolution. 
> Can we append
> > the following sentence after the text proposed by Kristofer?
> > 
> > ----START--------
> > However, if the compressor has learned the clock resolution of the
> > decompressor from external means (e.g., when both compressor and
> > decompressor are synchronized to the same timing source), then
> > TIME_STRIDE can be set to non-zero value even when no CLOCK 
> feedback is
> > received. 
> > -----END---------
> 
> This change would be in violation of 3095 (section 6.5.1, 
> which specifies that 
> the initial value of the clock resolution is set to 0).
> It is a big advantage to have the timer-based compression 
> specified this way, 
> since BOTH compressor and decompressor must make an explicit 
> action to start 
> using timer-based compression, and your proposed text would 
> make it mandatory 
> for the decompressor to support timer-based compression.
> 
> The point of the implementer's guide is to clarify things 
> without changing 
> intended behavior, so I'm going to have to oppose the text 
> suggested above.
> 
> BR,
> > Haipeng