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

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 24 Mar 2004 10:04:55 +0100

Pawel and others,

As I was not deeply involved in designing the encoding parts of RFC 3095 I had
hoped someone else would answer this question, but since no one has responded
I thought I would have to take a look at it. After checking what 3095 actually
says, as well as looking for discussions on the mail list, my conclusion is that
here we really have some confusing text lines we will have to say something about.

What does 3095 say about slopes?
The word slope appears at 6 places in 3095, three in the R-mode logic and 3 in
the beginning of the packet format section. None of these provides any definitions
or descriptions in a normative way. Let's look at the text in 5.5.1.2:

   The compressor will transit to the SO state after it has determined
   the presence of a string (see section 2), while also being confident
   that the decompressor has the string parameters.  The confidence can
   be based on ACKs.  For example, in a typical case where the string
   pattern has the form of non-SN-field = SN * slope + offset, one ACK
   is enough if the slope has been previously established by the
   decompressor (i.e., only the new offset needs to be synchronized).
   Otherwise, two ACKs are required since the decompressor needs two
   headers to learn both the new slope and the new offset.  In the SO
   state, R-0* packets will be sent.

The first "slope" could be seen as just a constant in the informative
equation, and the second "slope" would then just describe this constant.
An example of such a non-SN-field would be TS with a slope TS_STRIDE.
So far, there is nothing that says anything about any implicitly established
slope values, but the third occurrence of "slope" in this text talks about
such implicit establishments of string parameters. However, this is the
ONLY place where the RFC talks about implicit establishments of slopes,
and I can not see how that could possibly be sufficient to imply principles
requiring a behaviour to be implemented that would obviously affect
interoperability. The only conclusion I can draw from this is that the
text is a rest that should had been rewritten when the 3095 specification
evolved.

The other 3 occurrences of "slope" (actually "default-slope") is on page 75,
where it defines default-slope(IP-ID offset)=0 [which is not even a parameter
to that encoding scheme], as well as default-slope(TS)=1 for scaled TS
encoding and  =value(TS_STRIDE) for "as-is encoding" [which comes as no
surprise as TS is scaled with TS_STRIDE]. 

There is no place in the RFC that normatively says a word about implicitly
updating the slope, so my conclusion is that there should be no such thing.
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

I'll put this to my list of things to clarify in the next version of the impl. guide.

BR
/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Pawel Szymanski
> Sent: den 16 mars 2004 14:31
> To: [email-masked]
> Subject: [rohc] Slope used to compress/decompress RTP Timestamp field
> 
> 
> 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

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.

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

---

From: "kamal deep singh" <[email-masked]>
Date: Wed, 24 Mar 2004 21:51:08 +0100

Hi,

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.

I understand the meaning of the slope to be as follows:
( please correct me if something is wrong?)

TS can be perfectly calculated at decompressor given TS_SCALED (and ofcourse
TS_STRIDE, TS_OFFSET that are constant most of time)

Very ideally TS_SCALED will increase like 1, 2, 3, 4, 5 with  SN
and can be said to have slope = 1. (as TS_SCALED = 1*SN + offset).
So here will be no need of sending TS_SCALED bits if slope = 1 is
established in decompressor.

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.

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)

 Need of this slope is that without it I do not find a way in which we can
send UO_0 packets (except when there is a long chain of TS  =  constant,  N
number of times(N being the width of sliding window). Except for this case
which is unikely(even in video!) with a normal N lets say = 14,   more than
0 bits of TS_SCALED will always be required to be sent. This is because if
TS_SCALED is encoded by W_LSB then, k (no of bits required to send according
to W_LSB) will always be >= 1 except when all values of TS_SCALED or TS are
same in the window.

And hence in this case(ofcourse I feel that choosing lesser values of N will
reduce robustness)
, according to RFC it will be impossible to send UO_0 packets!!
since they do no contain TS_SCALED bits.

Still I feel that sections on slope are confusing in the RFC and will lead
to problems in interoperability.
But, I also feel that neglecting it will reduce compression efficiency.

regards,
kamal

----- Original Message -----
From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
To: "'Pawel Szymanski'" <[email-masked]>; <[email-masked]>
Sent: Wednesday, March 24, 2004 10:04 AM
Subject: RE: [rohc] Slope used to compress/decompress RTP Timestamp field

> 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.h
tml
> 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: Paweł Szymański <[email-masked]>
Date: Thu, 25 Mar 2004 09:51:57 +0100

Hi,

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.

Regards

Pawel

> > As I was not deeply involved in designing the encoding parts 
of RFC 3095 I
> had
> > hoped someone else would answer this question, but since no 
one has
> responded
> > I thought I would have to take a look at it. After checking 
what 3095
> actually
> > says, as well as looking for discussions on the mail list, 
my conclusion
> is that
> > here we really have some confusing text lines we will have 
to say
> something about.
> > The word slope appears at 6 places in 3095, three in the R-
mode logic and
> 3 in
> > the beginning of the packet format section. None of these 
provides any
> definitions
> > So far, there is nothing that says anything about any 
implicitly
> established
> > and I can not see how that could possibly be sufficient to 
imply
> principles
> > The other 3 occurrences of "slope" (actually "default-
slope") is on page
> 75,
> > where it defines default-slope(IP-ID offset)=0 [which is not 
even a
> parameter
> > updating the slope, so my conclusion is that there should be 
no such
> thing.
> > principles, but the discussions point in the direction of 
giving up these
> > I'll put this to my list of things to clarify in the next 
version of the
> impl. guide.

----------------------------------------------------
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.html%3Fidn%3D874&sid=151

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 25 Mar 2004 11:34:49 +0100

Hi Pawel, Kamal & L-E!

I think we can all agree that 3095 creates confusion in this area by including 
the text about "slope" in a few places while not defining it.It's about time we 
clear this up, since there has been a number of discussions related to this 
topic on the list.

For this discussion, let us limit ourselves for a possible slope used by the TS 
field, since that's really what we are discussion here and not use the 
"non-SN-field" term too much.

I believe that as the specis written, there cannot be room for a slope that can 
be implicitly updated. 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.

* If there is an implicit update of the slope, then it is not defined anywhere 
how/when this would actually happen, which would create interoperability problems.

* 5.5.1.2.  Compression logic and packets used (R-mode)
     --non-SN-field = SN * slope + offset

I am convinced that this is just written to be general for possible future 
profiles (with other fields than TS being sent in a scaled fashion), 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.
As a side note, even if this text was meant to define a slope, this section ONLY 
applies to R-mode, so it would not impact the fact if we can use UO-0 packets or 
not on video streams with semi-constant TS.

********

 >> And in "above" case of audio slope will be 1 most of the time

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.
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.
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. This without 
ever having to change the TS_STRIDE. The sliding window depth should not impact 
here even if it is larger than the number of packets, we are in U/O-mode where 
we use the optimistic approach.

When we reach the later parts of Kamal's example (3,4,5,...), then the 
compressor will probably note that a change of 30 will be more frequent than the 
constant TS, and will after a while establish a TS_STRIDE of 30. If it does not, 
then it could update the offset as above wuthout causing extra packet losses.

Therefore, we do not need a slope to handle the case presented here (unless I'm 
proven wrong of course).

Best regards,
	Kristofer Sandlund, Effnet AB

---

From: "kamal deep singh" <[email-masked]>
Date: Thu, 25 Mar 2004 22:44:48 +0100

Hi,

I  seem to see two questions.

1) Which method will be most efficient (compression ratio wise)?
 The one which considers slope or the one which ignores slope?

My answer is that the method which considers slope of TS_SCALED, will be
most efficient. As the changes in TS can be communicated just by
communicating TS_SCALED
"lsb bits".  (And not by sending TS absolute and TS_STRIDE to update
TS_OFFSET, in contrast)

2) Which method is interoperable and never assumes anything outside the RFC?

If things can be made clear by using implementer's guide, then our obvious
choice should
be to use the most efficient method. But, if that is not the case, then
Kristofer's method of
ignoring slope looks favourable to me. However I want to discuss some points
regarding that
method.

find my comments below.

> how/when this would actually happen, which would create interoperability
problems.

It is said in RFC that all parameters of the SN functions should be updated.
Slope ( or
what ever name one can choose) is also a parameter and should be updated.

> clear that "slope" really means TS_STRIDE in this section.

TS = SN*slope + offset will not fit if we take slope = TS_STRIDE
and offset = TS modulo TS_STRIDE as given in

Section 4.5.3

" The following algorithm is used:
1. Initialization: The compressor sends to the decompressor the value
      of TS_STRIDE and the absolute value of one or several TS fields.
      The latter are used by the decompressor to initialize TS_OFFSET to
      (absolute value) modulo TS_STRIDE.  Note that TS_OFFSET is the
      same regardless of which absolute value is used, as long as the
      unscaled TS value does not wrap around; see 4) below.

   2. Compression: After initialization, the compressor no longer
      compresses the original TS values.  Instead, it compresses the
      downscaled values: TS_SCALED = TS / TS_STRIDE.  The compression
      method could be either W-LSB encoding or the timer-based encoding
      described in the next section.
"

> value 10, then we'd have this:

Here, I would like refine a bit. If TS_OFFSET has to be communicated then
absolute TS
and TS_STRIDE both should be sent (L times) if we follow RFC and according
to the section quoted above we come to initialisation phase (and go back to
FO state). So, we can add a TS_STRIDE field and there will be no problem in
above method.

One small point is that can TS module 0 create any problem like division by
zero? But, even if it creates problem it can still be assumed that if
TS_STRIDE = 0 then TS_OFFSET = TS.

Other point is that it is an impression from RFC that TS_STRIDE and
TS_OFFSET (especially) are parameters which remain stable and do not change.
but, we are updating them very frequently.

> we use the optimistic approach.

fine

> then it could update the offset as above wuthout causing extra packet
losses.

Here, I have problem with the method. Perhaps because I dont know more
details about the above method.

We communicate TS_STRIDE = 30 with Abs TS.
After sending them L times we are sure that decompressor has
TS_STRIDE = 30
and TS_OFFSET = TS/30 = 40 in above case.

Now, if TS continues the same pattern then
 in the equation TS = TS_SCALED * TS_STRIDE + TS_OFFSET

TS_SCALED will always be missing. Hence, decompressor will need it.

This can be done by sendign TS_SCALED "lsb bits".
But, as soon as we stop sending these bits(UO_0), the decompressor has no
clue about TS_SCALED. And diff decompreessors can show diff behaviours. For
e.g. one can assume TS_SCALED constant but, it will lead to incorrect
computation of TS.
Other decompressor can say that TS_SCALED was increasing with a delta of 1
with SN so decompresor can assume that if TS_SCALED was not send then it can
use TS_SCALED_PREV + 1 (per increase of 1 in SN).

BUT, that will also be called a "slope of TS_SCALED"

regards,
Kamal