Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field

From: [email-masked]
Date: Tue, 30 Mar 2004 12:18:35 -0500

Hi Kristofer,

I don't know if you have read my reply to your earlier email:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02042.html.
Please let me know if you agree with my comments on your observations, 
on which you based your conclusion "there cannot be room for a slope ...".

Also, it seems to me that two different issues are discussed here:
a) Does RFC 3095 describe slope clear enough?
b) Is the slope needed?

For a), if the conclusion is that it's not clear enough in RFC3095, it can 
be clarified in implementation guide.

For b), if the conclusion is that it is not needed, we can create a new 
profile excluding it.

I'd suggest to keep the two issues separate in order to have a well-pointed
discussion.

BR,
Zhigang

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Kristofer Sandlund
> Sent: 30 March, 2004 01:54 AM
> To: Liu Zhigang.C (Nokia-NRC/Dallas)
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp
> field
> 
> 
> Hi Zhigang and others!
> 
> I'm not yet convinced of the slope as described here, so I'll 
> outline why.
> 
> 1) It is not well defined in the spec (at least U/O-mode).
> 
> For example, the definition of the timestamp stride (section 
> 2.0) is as follows:
>     Timestamp stride
> 
>        The timestamp stride (TS_STRIDE) is the expected 
> increase in the
>        timestamp value between two RTP packets with 
> consecutive sequence
>        numbers.
> 
> In the two examples taken so far (one semi-static TS for 
> video, and the other 
> "2,4,6" increase of the TS), the assumption used has been 
> that the TS_STRIDE is 
> set to "the difference in TS between two FRAMES", and not the 
> difference between 
> two PACKETS as defined above. According to the definition 
> above, the TS_STRIDE 
> should be 0 in the semi-static case (see my last mail how I 
> felt the sloution 
> can be) and "2" in the other case, and then, no slope is 
> needed for these 
> specific cases.
> 
> Zhigang wrote:
>  >Although the question was raised due to TS, I'd like to emphasize
>  >that the concept of slope is not only for TS. As Kamal pointed out,
>  >slope is one parameter of the function (see text below from 
> section 3.4).
>  >
>  >   The way ROHC RTP compression operates, then, is to first 
> establish
>  >   functions from SN to the other fields, and then reliably 
> communicate
>  >   the SN.  Whenever a function from SN to another field 
> changes, i.e.,
>  >   the existing function gives a result which is different from the
>  >   field in the header to be compressed, additional 
> information is sent
>  >   to update the parameters of that function.
> 
> This text can as well be interpreted as if the function is simply the 
> scaling/offset scheme of the TS and that the IPID offset 
> encoding is this 
> function for IPID. The slope itself is not mentioned in this 
> section, so I can't 
> see this as a "proof" for slope.
> 
> (see my previous mail for some more comments on why I don't 
> think it is defined)
> 
> 2) The updating of the slope in U/O-mode is inconsistent with 
> the definition of 
> these modes.
> 
> Every time the decompressor sees a packet in U/O-modes, the 
> context is updated 
> for all fields in the compressed packet and those inferred 
> from them. If slope 
> is to be used, suddenly we need two consecutive packets to 
> update this context 
> value. Since this is neither clear from the spec (there is no 
> definition in 3095 
> that says that U/O-mode should only update slope after two 
> packets seen), and 
> the fact that it is different from all other updating, this 
> is bound to cause 
> interoperability problems.
> Note: I am aware that sending "2*L" UO-1 packets can yield 
> larger compression 
> efficiency than ("L" UO-1-ID-ext3 + "L" UO-0), but see below 
> for other reasons 
> of why I think this tradeoff is worth it.
> 
> 3) Slow convergence time
> 
> a) U/O-mode
> Due to the need for sending "more than L" packets to update 
> the context, it will 
> take longer time to update the context at the decompressor 
> than it would to 
> update the TS_STRIDE (or TS_OFFSET for that matter), which 
> means I will have to 
> send a larger number of non-SO packets. Therefore, if we see 
> frequent changes in 
> the pattern, the scheme using slope will have a harder time 
> to ever get to use 
> UO-0 packets than a scheme without slope.
> 
> b) R-mode
> Note: For R-mode, the updating of the slope is almost defined 
> (5.5.1.2), so it 
> actually makes slightly sense to have a slope in R-mode than 
> in U/O-modes when 
> reading the spec.
> In R-mode, two ACKs are required to update the slope. 
> Considering the sparse ACK 
> mechanism, the compressor is likely to have to wait quite a 
> long time before he 
> knows that the slope has been updated, and therefore, the new 
> slope value cannot 
> be used very soon. Since the slope is supposed to be used in 
> situations where 
> the TS-delta changes "frequently", it is likely that it has 
> changed "again" 
> before the time that I have seen two ACKs. If not using slope 
> (changing the 
> TS_STRIDE or offset) would only have required one ACK meaning 
> a faster 
> convergence time to SO.
> 
> 4) Complexity
> As I have written above, the slope will have a very different 
> updating property 
> that other fields, so it will cause quite a bit of extra 
> complexity to handle 
> this. Since the "common case" is a more stable pattern of the 
> timestamp change, 
> my personal opinion is that it is not worth optimizing with 
> the slope, since it 
> can be made to work with just the stride/offset.
> 
> 
> I also read up in the mail archive, and the last time the 
> slope came up on the 
> list was:
> http://www1.ietf.org/mail-archive/working-groups/rohc/current/
> msg01502.html
> And then, the conclusion seems to have been that there was no 
> slope (for IPID at 
> least) in the spec.
> 
> So as a summary, I would like to see an addition to the 
> implementer's guide that 
> says that there "is no slope" (but feel free to convince me 
> that slope is a good 
> thing). At the very least, I feel quite strongly that 
> U/O-mode should not have 
> one since there's a lack of a firm definition of it in 3095.
> 
> Best regards,
>       Kristofer Sandlund, Effnet AB
> 
> 
> [email-masked] wrote:
> > It's not specified in RFC 3095. So, it's an implementation choice.
> > 
> > 5.3.1.1.1.  Optimistic approach, upwards transition
> > 
> >    [snip]
> > 
> >    The compressor normally obtains its confidence about decompressor
> >    status by sending several packets with the same 
> information according
> >    to the lower compression state.  If the decompressor 
> receives any of
> >    these packets, it will be in sync with the compressor.  
> The number of
> >    consecutive packets to send for confidence is not defined in this
> >    document.
> > 
> > BR,
> > Zhigang
> > 
> > 
> >>-----Original Message-----
> >>From: ext kamal deep singh [mailto:[email-masked]]
> >>Sent: 27 March, 2004 09:23 AM
> >>To: Liu Zhigang.C (Nokia-NRC/Dallas); [email-masked]
> >>Cc: [email-masked]; 
> >>[email-masked]; [email-masked]
> >>Subject: Re: [rohc] Slope used to compress/decompress RTP 
> >>Timestamp field
> >>
> >>
> >>
> >>Hi,
> >>
> >>I have one question below.
> >>
> >>
> >>>Actually for robustness, the compressor must make sure that 
> >>
> >>at least two
> >>("FO") packets with TS >field have been received by the 
> >>decompressor before
> >>it can transit to SO state and send Type-0 >packets. It will 
> >>ensure that the
> >>decompressor acquires both slope and offset of the function 
> >>from >SN to TS.
> >>
> >>In U and O mode, how will compressor base its confidence?
> >>By sending L + 1 or 2L packets?
> >>
> >>Or should it be left as an implementation choice?
> >>
> >>
> >>regards,
> >>Kamal
> >>
> >>
> >>
> >>
> >>
> >>>4.3.1.3.  Second Order (SO) State
> >>>
> >>>   This is the state where compression is optimal.  The compressor
> >>>   enters the SO state when the header to be compressed is 
> >>
> >>completely
> >>
> >>>   predictable given the SN (RTP Sequence Number) and the 
> >>
> >>compressor is
> >>
> >>>   sufficiently confident that the decompressor has acquired all
> >>>   parameters of the functions from SN to other fields
> >>>
> >>>BR,
> >>>Zhigang
> >>>
> >>>
> >>>>Hi Zighang,
> >>>>
> >>>>I wonder how decompressor should behave if it receives only
> >>>>one packet with TS
> >>>>field between two packets without TS ( for example when it
> >>>>receives UO-0
> >>>>packet, next UO-1-TS and next again UO-0 packet).
> >>>>
> >>>>I can see two options:
> >>>>
> >>>>1. The decompressor uses the old slope value (e.g. the 
> >>
> >>one it used to
> >>
> >>>>decompress the first UO-0 packet) to calculate timestamp for
> >>>>the second UO-0  packet. Here we assume that single TS 
> >>
> >>communicates
> >>change in
> >>
> >>>>the offset.
> >>>>
> >>>>2. It calculates a new slope basing on the timestamp values
> >>>>decompressed from  the first UO-0 packet and the UO-1 
> >>
> >>packet and next it
> >>uses
> >>
> >>>>the new slope to calculate the timestamp for the second 
> >>
> >>UO-0 packet.
> >>
> >>>>Which of the above is correct ?
> >>>>
> >>>>Regards
> >>>>
> >>>>Pawel
> >>>>
> >>>>
> >>>>>Hi Pawel,
> >>>>>
> >>>>>Yes, your understanding is correct. It's basically the
> >>>>
> >>>>geometry: two points
> >>>>determine a line. Besides the slope, two TS values also give
> >>>>you the offset.
> >>>>
> >>>>>No, RFC 3095 does not assume floating point. All
> >>>>
> >>>>encoding/decoding operations
> >>>>are integer based.
> >>>>
> >>>>>Zhigang
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: ext Pawel Szymanski [mailto:[email-masked]]
> >>>>>>Sent: 26 March, 2004 02:33 AM
> >>>>>>To: Liu Zhigang.C (Nokia-NRC/Dallas)
> >>>>>>Cc: [email-masked]; [email-masked];
> >>>>>>[email-masked]; [email-masked]
> >>>>>>Subject: RE: [rohc] Slope used to compress/decompress RTP
> >>>>>>Timestamp field
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>Hi Zhigang,
> >>>>>>
> >>>>>>
> >>>>>>>>I base this on the following observations:
> >>>>>>>>
> >>>>>>>>* 4.5.3. Scaled RTP Timestamp encoding
> >>>>>>>>    3. Decompression: When receiving the 
> >>
> >>compressed value of
> >>
> >>>>>>>>TS_SCALED,
> >>>>>>>>       the decompressor first derives the value of
> >>>>
> >>>>the original
> >>>>
> >>>>>>>>       TS_SCALED.  The original RTP TS is then
> >>>>
> >>>>calculated as TS =
> >>>>
> >>>>>>>>       TS_SCALED * TS_STRIDE + TS_OFFSET.
> >>>>>>>>
> >>>>>>>>If there acutally was a slope, it should have been in
> >>>>>>
> >>>>>>this formula.
> >>>>>>
> >>>>>>>This is a misunderstanding. Note that there are two
> >>>>
> >>>>*separate* steps
> >>>>
> >>>>>>>involved. The formula is for the second step: deriving TS
> >>>>>>
> >>>>>>from TS_SCALED.
> >>>>>>
> >>>>>>>The slope plays a role in the first step: "the decompressor
> >>>>>>
> >>>>>>first derives
> >>>>>>
> >>>>>>>the value of the original TS_SCALED". I thought this is
> >>>>
> >>>>clear from
> >>>>
> >>>>>>>section 4.5.3. More clarifications below.
> >>>>>>
> >>>>>>I think that the decompressor uses slope when it receives
> >>>>>>packets without TS
> >>>>>>field (for example UO-0 packets).
> >>>>>>
> >>>>>>In this case it uses the formula to calculate new scaled
> >>>>>>timestamp value:
> >>>>>>
> >>>>>>   new_scaled_timestamp = old_scaled_timestamp + (new_SN -
> >>>>>>old_SN)*slope
> >>>>>>
> >>>>>>Next it calculates the unscaled timestamp using the
> >>>>
> >>>>formula from 4.5.3
> >>>>
> >>>>>>When the decompressor receives a packet with TS field, it
> >>>>>>does not use slope.
> >>>>>>It decompresses the new scaled timestamp value using LSB
> >>>>>>method. Next it uses
> >>>>>>the formula from 4.5.3 to calculate the unscaled timestamp.
> >>>>>>
> >>>>>>When the decompressor receives two or more packets containing
> >>>>>>TS value in raw,
> >>>>>>it can calculate a new slope value, for example using 
> >>
> >>the formula:
> >>
> >>>>>>  new_slope = (new_scaled_timestamp - old_scaled_timestamp) /
> >>>>>>(new_SN - old_SN)
> >>>>>>
> >>>>>>Am I correct ?
> >>>>>>
> >>>>>>An additional question is whether the slope is an integer
> >>>>>>number or could it be
> >>>>>>a floating point number ?
> >>>>>>
> >>>>>>Regards
> >>>>>>
> >>>>>>Pawel
> >>>>>>
> >>>>>>
> >>>>>>----------------------------------------------------
> >>>>>>Zobacz niezwyk³y koncert: "Niemena Pamiêci Gdañski Rapsod"
> >>>>>>Najwiêksze przeboje artysty w nowych zaskakuj±cych 
> >>
> >>aran¿acjach.
> >>
> >>>>>>http://klik.wp.pl/?adr=http%3A%2F%2Fmuzyka.wp.pl%2Fimprezy.htm
> >>>>>
> >>>>>l%3Fidn%3D874&sid=151
> >>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>Rohc mailing list
> >>>>>[email-masked]
> >>>>>https://www1.ietf.org/mailman/listinfo/rohc
> >>>>>
> >>>>
> >>>>----------------------------------------------------
> >>>>£odzi± po Wi¶le - najciekawsze etiudy w Warszawie.
> >>>>http://klik.wp.pl/?adr=http%3A%2F%2Ffilm.wp.pl%2Fp%2Fwiadomosc
> >>>
> >>>.html%3Fid%3D55832&sid=152
> >>>
> >>>
> >>>
> >>
> >>
> 
> 
> _______________________________________________
> 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: Kristofer Sandlund <[email-masked]>
Date: Wed, 31 Mar 2004 11:15:05 +0200

Hi Zhigang.

Comments inlined.

> on which you based your conclusion "there cannot be room for a slope ...".

Let me first clarify:
I never meant that slope can never be made to work, a slope scheme that is fully 
specified _should_ be able to interop. The problem to me is that IF there is a 
slope defined, then it contradicts a lot of places in the other text (such as 
the definition of TS_STRIDE in section 2.0).

> a) Does RFC 3095 describe slope clear enough?

I would say that the questions would be:
a) Does slope exist in 3095?

    if the answer to a) is yes, then
      a2) Is the slope needed?
         if a2) is yes then a3) How do we specify it more clearly?
         if a2) is no, what do we do instead?

    if the answer to a) is no, then
      a4) What do we do instead and how do we specify that (if needed)?

The questions you have written assume that the slope is defined in 3095, and 
both myself (and it seems L-E does as well) doubt that this is what one can read 
from the spec.

BR,