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

From: Paweł Szymański <[email-masked]>
Date: Tue, 16 Mar 2004 14:31:26 +0100

Hi all,

I've seen in the ROHC mailing list archive a discussion about 
using dynamic slope values by the compressor and decompressor 
while decompressing RTP Timestamp field from OU-0 packets (refer 
to mail: http://www.cdt.luth.se/rohc/msg00934.html). The idea is 
that decompressor starts with default_slope value and calculates 
new slope value at each arrival of a packet containing TS field.

The mechanism is not described in the standard. Only 
default_slope values are defined. Should compressor and 
decompressor use other slope values than the default_slope when 
they process UO-0 packets ? 

Regards

Pawel Szymanski

----------------------------------------------------
Już dziś zaplanuj wakacje.
Im szybciej tym większa zniżka - nawet do 12%.
http://klik.wp.pl/?adr=http%3A%2F%2Fturystyka.wp.pl%2Fwiadomosc.html%3Fwid%3D4843057&sid=140

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

---

From: [email-masked]
Date: Thu, 25 Mar 2004 15:33:57 -0500

Hi,

Please see my comments below. Sorry about being late on this issue (I was one of those who wrote the sections).

BR,
Zhigang

> I find the meaning of "slope" to be implicitly given in the RFC. And I
> believe it because of the following:
> 
> 1) If we stick to the equation
> SN_Non_field = SN*slope + offset given in RFC 3095.
> which is another form of SN_Non_field = SN_Non_field_ref + (SN -
> SN_ref)slope.
> Then one of the SN_Non_field will also be TS_SCALED and will 
> also have a slope.
> And significance of that I try to show later.
> 
> 2) Packets of FO state are said to update all parameters of 
> SN functions. And slope is also a part of any SN function. so, it is also implicitly
> stated to be updated.

Correct.

> But, in most of the cases TS_SCALED will show behaviour like
> 
> 1, 1 , 1, 1, 2, 2, 2, 2, 2, 2, 2, 3, 4, 5 in case of video.
> 
> 1, 2, 3, 4, 6, 7, 7, 8, 9, 10  possibly in case of audio
> 
> in "above" case of video slope will be 0 most of the time and 
> 1 sometimes. And in "above" case of audio slope will be 1 most of the time 
> for audio.

This is one of the reasons why we need a dynamically established slope.
Besides the different behaviour between media types,  a different slope
may appear even for the same media type or codec due to different
packetization. For example, a media may encapsulate two 20 ms
voice frames into one RTP packet. So the TS_SCALED could look
like 2, 4, 6, 8, 10, with a slope of 2 instead of 1.

> so, once this slope is established by L or ACK. There will be 
> no need to send TS_SCALED field
> and UO_0 (or other depending on  behaviour of other 
> fields)packets can be sent until there is a change.
> (Above also fits when TS is not scaled because then slope 
> will just get multiplied by TS_STRIDE)

Correct.

> Still I feel that sections on slope are confusing in the RFC 
> and will lead to problems in interoperability.

It could have been described clearer in RFC 3095. We were short of time and different 
authors have different opinion on how much/explicit is just enough without being 
verbose. You feel the pressure when the document becomes 168 pages long. :-(

Anyway, a clarification on this in the implementer's I-D would help.

> But, I also feel that neglecting it will reduce compression efficiency.

I cannot agree more, not to mention the flexibility of ROHC. We cannot simply predict
the slope for different header fields for all kinds of RTP flows.

---

From: [email-masked]
Date: Thu, 25 Mar 2004 16:21:11 -0500

> I agree with Kamal that the notion of slope is required to use 
> UO-0 packets.
> However, the RFC 3095 does not says clearly whether the 
> decompressor should decompress UO-0 packets using fixed value of 
> slope equal to the default-slope defined in section 5.7 or it 
> should calculate the slope dynamically basing on TS field values 
> received in UO-1*, UOR*, IR and IR-DYN packets.  
> 
> If the letter case is valid, I would expect that the 
> implementation guide will describe this in detatils.

The intension of RFC 3095 is the latter case. That's why "default-slope" has a prefix "default". 

Implementation guide would be a good place to clarify.

BR,
Zhigang

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 30 Mar 2004 10:16:39 +0200

Hi all,

I was just about to send my comments on this thread, but as 
Kristofer has already expressed similar arguments, I will just
conclude that I agree to all of them. We have to be very careful
with "over interpreting" things in our specifications. It is
clear to me that RFC 3095 really does not specify slopes in a
normative way, which would be needed for interoperability. The
implicit slope update procedure would only buy us something if
a compressor could assume the decompressor will do such updates
(and how). That would require such procedures to be normatively
defined (MUSTs, REQUIREDs, etc), which is not the case in 3095.

Further, I also agree with the questioning of its technical
merits.

/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kristofer Sandlund
> Sent: den 30 mars 2004 09:54
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Lars-Erik Jonsson
> (LU/EAB); [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
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 30 Mar 2004 10:17:34 +0200

Agreed, good point!

/L-E

> [email-masked];
> > > > > > 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
> > > Ł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
> >
> >
> >
> 
>

---

From: [email-masked]
Date: Tue, 30 Mar 2004 15:47:56 -0500

Hi,

As I replied earlier, Kamal's understanding is correct. Now that I 
have time looking at the following interpretation, it is 
- unfortunately - even beyond "over interpreting" (quote from 
Lars-Erik). It is incorrect.

Please see detailed comments below.

BR,
Zhigang

[Kristofer wrote:]

> Let's say that the unscaled TS in the video example will be 
> 30 and the starting value 10, then we'd have this:
> 
> 10, 10, 10, 10, 40, 40, 40, 40, 40, 40, 40, 70, 100, 130
> 
> As you observe, the "video slope will be 0 most of the time". 
> This is the observation that your compressor also should make, and 
> therefore use a TS_STRIDE of 0.

I'm really confused. How come TS_STRIDE is same as slope? What
do you mean by a scaling by a factor of 0? This is certainly not
what RFC 3095 says.

> What we can do when the TS changes from 10 to 40 is that we 
> can interpret this as a change of TS_OFFSET instead of saying
> that TS_STRIDE (or slope) changes.

Again, TS_STRIDE != slope.

> So we keep the TS_STRIDE as 0, but change TS_OFFSET from 10 
> to 40, which we do by sending some UOR-2-ext3 with an unscaled
> timestamp according to the optimistic approach, and then move 
> back to sending UO-0 packets. 

How could this be possible? As specified in RFC 3095, TS_OFFSET 
calculated locally as TS modulo TS_STRIDE. Don't you have problem
of division by zero?

---

From: [email-masked]
Date: Wed, 31 Mar 2004 10:11:42 -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 ...".
> > 
> 
> 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).

Please, read my email above and tell me straight if you agree or not.

In that email, I've explained why your observations are incorrect. 
Please let me know if you disagree.

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

This becomes hair-splitting. But as one of the authors for encoding 
(section 4.5), I can tell you it does. And it is described in many 
places in RFC 3095. 

On the other hand, it may not be described clear enough. We thought 
the text on FO and SO and function from SN to non-SN-field is 
sufficient (I personally wanted to add more text in RFC 3095 but it 
was not agreed by other authors). Either way, it can be clarified 
more in the implementation I-D. 

BR,
Zhigang

---

From: [email-masked]
Date: Wed, 31 Mar 2004 11:25:19 -0500

> One comment is that the method that I described was something 
> I whipped while writing that mail, since it seemed like the 
> logical interpretation. Therefore, I described the principle 
> of how I understood it to work than the exact method to use it. 
> It might need some further analysis of how it can work. I'll 
> try to look at that later this week.

I thought you have been "convinced" that "there cannot be room 
for a slope" because of this?  

It looks to me that you are now *developing* your understanding.
Do we fall into the trap that if one can develop a different
method than what is described in RFC 3095, then it proves that 
slope does not exist in RFC 3095?

> My comments are based around the assumption that "there is no 
> slope", so I am not claiming that they are the same thing. 

Sorry, have you said the following in your earlier email?
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg02033.html

"if we narrow this down to TS, then we get TS = SN * slope + offset.
Compare this to the formula in 4.5.3 (quoted above), then suddenly
it becomes clear that "slope" really means TS_STRIDE in this section."

> TS_STRIDE is the delta in TS, so it is "_a_ slope of the TS", 
> I did not mean the "slope" that you consider.

Please, use TS_STRIDE as described in RFC 3095, which is a scale
factor, and use slope as what it means in mathematics for a line,
i.e., non-SN-field = SN * slope + offset. It will help a lot
for the discussion.

> Some testcase made some implementation set the TS_STRIDE to zero, 

This is simply an incorrect implementation (see section 4.5.3).

It also demonstrated again the fundamental difference between
slope and TS_STRIDE. The former can be zero, while the latter
cannot.

> and some of us discussed how this should be handled and I 
> think we said that "if STRIDE=0 then TS_OFFSET = TS", since 
> that seems logaical enough. 

This is NOT logical and NOT what RFC 3095 says. Again, please
read section 4.5.3.

> we MUST define what "X mod 0" means in the ROHC spec, 

It means division by zero, as it means in basic mathematics.
Do we have to redefine every operation in mathematics?
I'm becoming speechless ... 

BR,
Zhigang

---

From: [email-masked]
Date: Wed, 31 Mar 2004 13:19:01 -0500

> The mail list discussions indicates that there were proposals 
> to have such principles, but the discussions point in the direction of 
> giving up these ideas.
> http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00953.html

That is not true. 

If you read the emails below, you can see my proposal for the decompressor
to learn slope was agreed upon. 

http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00934.html
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00935.html
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00952.html
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00953.html
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00957.html
http://www1.ietf.org/mail-archive/working-groups/rohc/old-archive/msg00960.html

The email you mentioned above is a discussion on only one logic branch in my
proposal, i.e., whether the default-slope or the previous learned slope ("old_slope") 
should be used by the decompressor when it receives only one context update. 
It is NOT about the slope learning itself, which has already been agreed. In the 
end, you can see that my proposal to use "old_slope" in the case of one "FO" 
update was also agreed. 

BR,
Zhigang