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

From: [email-masked]
Date: Mon, 29 Mar 2004 11:07:14 -0500

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Tue, 30 Mar 2004 09:54:14 +0200

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:
>>>>>>Zobacz niezwyk³y koncert: "Niemena Pamiêci Gdañski Rapsod"
>>>>>>Najwiêksze przeboje artysty w nowych zaskakuj±cych 
>>
>>aran¿acjach.
>>
>>>>£odzi± po Wi¶le - najciekawsze etiudy w Warszawie.

---

From: "kamal deep singh" <[email-masked]>
Date: Tue, 30 Mar 2004 22:25:54 +0200

Hi Kristofer,

I still have some problems regarding the method which you use
to compress Time Stamp (It may be because I do not know some points).

your method as I understand is as follows:
Also please read my comments (after the method) questioning its
interoperability.
And Please correct me if something is written wrong.

There seem to be 1 equation.

i) TS = SN * slope + offset;  (As written in your mail. And you intend to
use slope = TS_STRIDE)

COMPRESSOR SIDE:
------------------------
always TS_STRIDE = TS - TS_prev;

FO STATE: (choosing the smallest packet)
     1) Communicate TS_STRIDE L times if it changes and comes to a stable
          value.
     2) Communicate offset L times if it changes with respect to
          eq. i) and TS_STRIIDE in 1) above is not stable.
     3) If nothing changes then go to SO STATE:

SO STATE:
     1) If anything changes (TS_STRIDE , offset with respect to eq i),
......)
         then go to FO STATE.
      2) If nothing changes then send just SN (wlsb encoded)
          or UO_0.

DECOMPRESSOR SIDE:
---------------------------

    1) If Abs TS and TS_STRIDE are recieved then update them and
        also update offset = Abs TS%TS_STRIDE
    2) If no bits of TS are recieved then calculate
        TS = SN* TS_STRIDE + offset.

I have some problems with your method.
One is that equation i) which you use is nowhere given in the RFC
and instead , TS = TS_SCALED*TS_STRIDE + offset is mentioned.
I feel that RFC does not intend to use the equation i) and thus the method
will not
be interoperable.

Other is that you nowhere mention to use TS_SCALED and the equation
TS = TS_SCALED*TS_STRIDE + offset; in your method.
Variable TS_SCALED and this equation are the base to compress TS and are
explicitly given in RFC.
Thus, the method looks more interoperable to me.

Till now, I do not find your method interoperable.
Or please make your method a little more clear and it will be very helpful.

regards,
Kamal

----- Original Message -----
From: "Kristofer Sandlund" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Tuesday, March 30, 2004 9:54 AM
Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp field

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 31 Mar 2004 11:18:28 +0200

Hi Kamal & Zhigang

I have put both your mails below here (Zhigangs mail below), since you both 
discuss my "semi-constant TS example".

Comments inlined.

> to compress Time Stamp (It may be because I do not know some points).

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.

[email-masked] wrote:
 > 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.
 >

My comments are based around the assumption that "there is no slope", so I am 
not claiming that they are the same thing. TS_STRIDE is the delta in TS, so it 
is "_a_ slope of the TS", I did not mean the "slope" that you consider.

 >
 >>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.
 >

See above.

 >
 >>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?

Good point. This is something that we ran into at the interop in Berlin. Some 
testcase made some implementation set the TS_STRIDE to zero, 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. Now I realize that this has 
never been communicated to the list, so that was a mistake of me to assume it 
was (short memory :)

But even if we would use "slope", this would be an issue. There is nothing in 
the spec that stops a compressor from setting TS_STRIDE=0, which would lead to 
zero division, so this must be clarified whichever way we go. I.e we MUST define 
what "X mod 0" means in the ROHC spec, since it can happen!

Conceptually, I can't see a problem with the solution I outlined if the "modulus 
thing" is clarified, but I should probably have to look into exactly what the 
spec says before I can say for sure.

BR,

---

From: "kamal deep singh" <[email-masked]>
Date: Wed, 31 Mar 2004 20:18:00 +0200

Hi Kristofer,

   I seem to see the confusion. What we may be ignoring in our discussion is
the fact that TS can be compressed after scaling or can be compressed
without scaling. This is indicated by the variable "Tsc".  This variable is
important as it tells whether TS is scaled before compression or not.

(Note that Scaled RTP Timestamp encoding may just be called as "encoding"
and not compression as its name goes. and whenever it is used , it encodes
the TS value (downscale) "before" TS gets compressed. Zhigang has already
provided clarification for this point before)

When Tsc = 0 then TS is not scaled and is "compressed as is". Here, your
method
seems to get fit as there is no mention of TS_SCALED and "slope" indeed is
equal to TS_STRIDE in TS = SN*slope + offset. And fits "default-slope(TS) =
value(TS_STRIDE)." as given in section 5.7 of RFC :
     "
      If value(TIME_STRIDE) > 0, timer-based compression of the RTP
      Timestamp is used (see section 4.5.4).

      If value(Tsc) = 1, Scaled RTP Timestamp encoding is used before
      compression (see section 4.5.3), and default-slope(TS) = 1.

      If value(Tsc) = 0, the Timestamp value is compressed as-is, and
      default-slope(TS) = value(TS_STRIDE).
 "

But when Tsc = 1 then what could slope mean?

When Tsc = 1 or according to RFC "When using scaled RTP Timestamp encoding,
the TS is downscaled by a factor of TS_STRIDE before compression."
Here, TS is already downscaled by TS_STRIDE and hence there is "no more
scope" of another
downscaling by TS_STRIDE or TS_STRIDE_2 !  in the equation
TS (downscaled) = SN*slope + offset.
rather this slope will be 1 in normal cases and thus is specified in RFC as
"default-slope(TS) = 1" in section 5.7 as above. So, if one uses scaling
then one has to use slope too.

Hence, slope , delta or pattern parameter whatever we may choose its name,
is
required while using TS scaling and is also specified in RFC.

regards,
Kamal

----- Original Message -----
From: "Kristofer Sandlund" <[email-masked]>
To: "kamal deep singh" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, March 31, 2004 11:18 AM
Subject: Re: [rohc] Slope used to compress/decompress RTP Timestamp field